Auditoría y reportes en IGA: evidencia que se sostiene y reportes que alguien usa

El requerimiento que llega todos los años

En algún momento del tercer trimestre llega un correo de los auditores externos. Quieren la lista de todas las personas que pudieron registrar asientos en el libro mayor en cualquier momento entre enero y junio. Quieren la evidencia de aprobación de 25 personas que van a elegir de esa lista. Quieren a cada empleado que se fue en el primer semestre, con la fecha en que se le retiró el acceso al ERP, al portal bancario y a la herramienta de consolidación. Y quieren los resultados de las dos últimas revisiones trimestrales de acceso de esos sistemas, con la prueba de que las revocaciones se ejecutaron.

En una empresa, responder ese correo lleva seis semanas. Alguien exporta las listas de usuarios de cada sistema, pero las exportaciones muestran quién tiene acceso hoy, no en marzo. Las aprobaciones están repartidas entre comentarios de tickets e hilos de correo. Las fechas de baja salen de RR. HH., y las de retiro, de la memoria de tres administradores distintos. Los resultados de las revisiones existen como hojas de cálculo con las respuestas de los jefes pegadas, y nadie puede demostrar que las revocaciones ocurrieron.

En otra, lleva dos días, porque todo lo de este módulo se diseñó para dejar un registro, y esos registros están conectados. De esa diferencia trata este artículo. Cierra el módulo de componentes core de IGA porque todos los demás componentes, las solicitudes, las certificaciones, los roles, las políticas y el aprovisionamiento, producen registros, y la auditoría y los reportes son el lugar donde esos registros suman algo o no.

Qué registrar

Un programa de IGA tiene que poder responder, sobre cualquier acceso que alguien haya tenido alguna vez: quién lo recibió, por qué vía, quién lo decidió, cuándo llegó y cuándo y por qué se fue. Eso implica registrar varios tipos de eventos, cada uno con el contexto suficiente para sostenerse por sí solo.

Primero, los cambios de acceso. Cada otorgamiento y cada retiro, con la identidad, el entitlement o rol, el sistema destino, la hora, la vía por la que llegó (una solicitud, una regla, una certificación, un otorgamiento manual detectado por la reconciliación) y la referencia a lo que lo autorizó.

Después, las decisiones. Las aprobaciones y rechazos de solicitudes, con quien aprobó y su comentario. Las decisiones de certificación, elemento por elemento. Las excepciones de SoD, con su control compensatorio y su fecha de vencimiento. Cada una debería registrar quién tomó la decisión y en calidad de qué, porque una aprobación hecha por una persona delegada no es el mismo hecho que una aprobación del owner.

Los cambios de política necesitan el mismo trato. Cada cambio en una regla de asignación, una regla de SoD, el contenido de un rol o un paquete birthright, con la versión anterior y la nueva, quién lo cambió, quién lo aprobó y desde cuándo rige. Sin esto, la plataforma puede decir que una regla otorgó un acceso, pero no qué decía la regla en ese momento.

Las operaciones de aprovisionamiento y los resultados de la reconciliación cierran el círculo: qué operaciones corrieron, cuáles fallaron y se reintentaron, qué deriva se encontró y qué se decidió sobre ella.

Y por último, las acciones de quienes administran la propia plataforma de IGA. Esas personas pueden cambiar reglas, en algunas configuraciones aprobar en nombre de otros y editar datos de identidad. Sus acciones están entre las más importantes de registrar y entre las que más se olvidan.

Los logs todavía no son evidencia

Cada uno de esos registros sirve por sí solo, pero un auditor rara vez pregunta por un evento suelto. Pregunta si un control funcionó, y eso exige seguir una cadena. La aprobación que autorizó un otorgamiento. La operación de aprovisionamiento que lo ejecutó. La reconciliación que confirmó que existía en el sistema. Más adelante, la certificación que lo revisó, la decisión de revocarlo, la operación que lo quitó y la reconciliación que confirmó que ya no estaba.

flowchart LR
  accTitle: La cadena de registros que forma la evidencia de acceso
  accDescr: El owner de un entitlement aprueba una solicitud, lo que produce un registro de aprobación. La aprobación dispara una operación de aprovisionamiento que otorga el acceso en el sistema destino. Una reconciliación posterior lee el sistema destino y confirma que el acceso existe. Cada registro hace referencia al anterior, de modo que un auditor puede partir de cualquier acceso confirmado en el sistema y rastrearlo hasta la decisión que lo autorizó.
  D[Decisión<br/>aprobación, regla, certificación] --> O[Operación<br/>aprovisionamiento o retiro]
  O --> C[Confirmación<br/>reconciliación]
  C --> E[Evidencia que un auditor<br/>puede rastrear en ambos sentidos]

Cuando esos registros viven en sistemas distintos, sin un identificador común, armar la cadena significa que alguien empareje números de ticket con líneas de log y filas de hoja de cálculo a mano, con un plazo encima, para cada elemento de la muestra. Ahí se van las seis semanas. Cuando la plataforma de IGA los enlaza, con cada operación guardando el identificador de la decisión que la causó y cada hallazgo de reconciliación ligado a la operación que confirma, la cadena sale como un reporte.

La cadena debería funcionar en los dos sentidos. Partiendo de una decisión, tienes que poder mostrar lo que provocó. Partiendo de un acceso encontrado en un sistema, tienes que poder mostrar qué lo autorizó, o mostrar que nada lo autorizó, lo cual ya es un hallazgo.

Cómo prueban en realidad los auditores

Saber cómo se hacen las pruebas facilita mucho diseñar para ellas. Casi todas las pruebas de controles de acceso, sean de controles generales de TI de SOX, de SOC 2 o de PCI DSS, siguen el mismo patrón.

El auditor parte de una población: todas las bajas del periodo, todos los usuarios con un entitlement sensible, todo el acceso otorgado en el periodo, todos los cambios a una regla crítica. Elige una muestra, a menudo 25 elementos para un control que opera muchas veces y menos para controles trimestrales. Para cada elemento busca la evidencia de que el control funcionó: la aprobación existía antes del otorgamiento, quien aprobó era la persona adecuada, el acceso de la persona dada de baja se retiró dentro del plazo definido, la decisión de certificación se ejecutó. También puede hacer un recorrido (walkthrough), siguiendo de punta a punta un caso del proceso con las personas que lo llevan.

Lo importante es que la población la entrega la organización. Y eso convierte a la población misma en algo que el auditor tiene que probar.

Auditorías distintas, prioridades distintas

El patrón de prueba se parece en todas partes, pero cada auditoría se fija en cosas distintas, y conviene saber para cuál te preparas.

Una auditoría de controles generales de TI de SOX se concentra en los sistemas que alimentan los reportes financieros. Los auditores quieren ver que el acceso a esos sistemas se aprueba, se revisa y se retira, y que los cambios en ellos están controlados. Prueban si cada control está bien diseñado y si funcionó durante todo el año, y prestan especial atención al acceso privilegiado y a quien pudiera modificar datos financieros o los sistemas que los guardan.

Una auditoría SOC 2 depende de lo que la empresa les ha prometido a sus clientes. Un informe Tipo I revisa el diseño de los controles en una fecha concreta; un Tipo II revisa que funcionaron durante un periodo, normalmente de seis a doce meses, lo que exige evidencia de todo el periodo y no solo del final.

Una evaluación de PCI DSS, que hace un evaluador de seguridad cualificado (QSA), es muy concreta en sus requisitos: quién puede acceder a los datos de titulares de tarjeta, cómo se gestionan las cuentas, cuánto tiempo se guardan los logs. Suele perdonar menos la evidencia faltante, porque los requisitos dicen exactamente qué tiene que existir.

Una auditoría de certificación ISO/IEC 27001 mira el sistema de gestión en su conjunto: si el control de acceso está definido en una política, si la política se cumple y si los registros lo muestran. Le importa tanto el proceso documentado y su revisión como las muestras sueltas.

La auditoría interna, por último, suele probar los mismos controles antes que los auditores externos, y es la mejor aliada que tiene un programa de IGA. Un hallazgo de auditoría interna en marzo es la oportunidad de arreglar algo antes de que se convierta en un hallazgo externo en septiembre.

El reporte también es evidencia

Los auditores la llaman IPE, información producida por la entidad: cualquier reporte, consulta o extracción que la organización entrega como base de las pruebas. Si a la lista de bajas le faltan las personas que se fueron de una filial, la muestra no puede incluirlas y la prueba no demuestra nada sobre ellas. Por eso los auditores verifican que el reporte sea completo y exacto antes de apoyarse en él.

En la práctica, eso significa que querrán entender cómo se genera un reporte (la consulta, sus filtros, sus parámetros), verlo correr o ver evidencia de que se corrió con los parámetros correctos, y comparar sus totales con otra fuente, como el conteo de bajas del propio sistema de RR. HH. Un reporte que alguien arma a mano cada año en una hoja de cálculo es difícil de defender. Un reporte estándar, generado por la plataforma con una lógica documentada y un registro de cuándo y cómo se corrió, es mucho más fácil.

Preguntas sobre una fecha pasada

El correo del principio preguntaba quién pudo registrar asientos en cualquier momento entre enero y junio. No es la misma pregunta que quién puede registrarlos hoy, y es una de las cosas que más a menudo no pueden responder los programas de IGA.

Responderla requiere historia. O la plataforma guarda cada asignación con su fecha de inicio y de fin, para poder reconstruir el estado de cualquier día pasado, o toma fotos periódicas del acceso y las conserva. Las exportaciones que se sacan hoy de los sistemas destino no sirven, porque no aparecen las personas que tuvieron el acceso en marzo y lo perdieron en mayo, que a menudo son justo las que le interesan al auditor.

Lo mismo vale para reglas y roles. “¿Qué contenía el rol Auxiliar de CxP el 1 de abril?” y “¿qué decía la regla de asignación CxP-02 cuando otorgó este acceso?” son preguntas legítimas, y la respuesta depende de que el versionado ya existiera en ese momento. Diseñar para las preguntas sobre fechas pasadas desde el principio es barato; reconstruir una historia que nunca se guardó es imposible.

Cinco preguntas que le hacen a todo programa

La mayoría de los requerimientos de auditoría, y de las preguntas de una investigación de seguridad o de un owner de negocio, resultan ser variantes de las mismas cinco. Vale la pena comprobar, antes de que alguien pregunte, si el programa puede responder cada una con sus propios registros.

La tercera columna es la lista de pendientes. Cada hueco es un lugar donde hoy habría que responder a un auditor, a un investigador o a un owner de negocio pidiéndole a alguien que se acuerde. Cerrar esos huecos uno a uno, empezando por los sistemas que más importan, es una forma razonable de planificar la parte de reportes de un programa de IGA.

Reportes para lectores distintos

Una plataforma de IGA puede producir cientos de reportes. Los útiles se diseñan para un lector concreto que hará algo concreto con ellos, y suelen caer en cuatro grupos.

Los reportes operativos son para quienes llevan los procesos, muchas veces a diario. Operaciones de aprovisionamiento fallidas y su antigüedad. Aprobaciones que llevan más de su nivel de servicio. Tareas manuales vencidas. Conectores que no han completado una agregación recientemente. Estos reportes existen para trabajarlos hasta vaciarlos.

Los reportes de cumplimiento muestran que los controles funcionaron, normalmente durante un periodo. Campañas de certificación terminadas a tiempo, con sus tasas de revocación y la remediación confirmada. Bajas con su hora de baja y la hora en que se retiró el acceso de cada sistema dentro del alcance. Acceso otorgado en el periodo con su aprobación. Son los reportes que se convierten en IPE.

Los reportes de riesgo muestran la exposición, haya fallado o no algún control. Quién tiene acceso privilegiado y cómo evoluciona ese número. Cuentas huérfanas y cuentas de servicio sin owner. Cuentas sin uso en 90 días. Excepciones de SoD, sus controles compensatorios y cuántas están vencidas. Son para los owners y para el área de seguridad, y deberían llevar a decisiones.

El reporte ejecutivo es un conjunto breve de cifras de tendencia para el foro de gobierno del artículo de roles del programa y para la dirección: un puñado de las métricas de cada artículo de este módulo, mostradas como tendencias y no como valores sueltos, con una frase sobre qué cambió y por qué.

Un reporte con el que nadie hace nada es ruido, y el ruido enseña a la gente a ignorar los reportes. Antes de crear uno, conviene escribir quién lo lee, cada cuánto y qué se espera que haga cuando una cifra se mueve. Si la última pregunta no tiene respuesta, probablemente el reporte no necesita existir.

Tableros que no engañan

Las mismas cifras pueden contar historias muy distintas según cómo se definan. Un reporte de certificación que dice “97% completado” suena sano hasta que descubres que el 3% que falta es la parte de acceso privilegiado, la única que de verdad importaba. Un promedio de “dos horas para retirar el acceso de las bajas” puede esconder a una persona cuyo acceso al portal bancario siguió activo un mes.

Unos pocos hábitos mantienen honestos los reportes. Cada métrica debería tener una definición escrita, incluido qué cuenta en el denominador y qué queda fuera. Las cifras que mezclan niveles de riesgo deberían separarse por nivel, porque el tramo privilegiado suele ser el que le importa a la gente y el que más fácilmente queda escondido en un promedio. Los promedios deberían ir acompañados de los peores casos, o de percentiles, para que un solo caso largo se vea. Y cada reporte debería mostrar cuándo se actualizaron sus datos por última vez, porque un tablero que se alimenta de un conector que dejó de agregar la semana pasada seguirá mostrando, tan tranquilo, las cifras sanas de la semana pasada.

Reportar un control que falló

Tarde o temprano, un control no funciona como estaba diseñado. Una persona dada de baja conserva el acceso una semana porque se olvidó una tarea manual. Una campaña de certificación cierra tarde. Se descubre que una aprobación la dio alguien sin autoridad para darla.

Cómo lo maneja el programa importa mucho. La peor respuesta es esperar que nadie se dé cuenta. Los auditores muestrean, y una desviación que encuentran por su cuenta, sin explicación, siembra dudas sobre todos los demás controles. La mejor respuesta es tratar la desviación como un registro en sí: qué pasó, cómo se detectó, la causa raíz, el impacto (¿la persona llegó a usar el acceso?), el arreglo inmediato y qué cambia para que no se repita. Una desviación que el programa encontró, explicó y corrigió antes de que llegara el auditor suele tomarse como prueba de que el monitoreo funciona. La misma desviación encontrada por el auditor, sin ningún registro, a menudo se convierte en un hallazgo.

Probar los controles de forma continua

Casi todas las pruebas que un auditor hace una vez al año las puede hacer el programa todos los días. Si el control es “el acceso de las bajas se retira en un día hábil”, una consulta diaria que liste a cada persona dada de baja en los últimos 30 días que conserve algún acceso pasadas 24 horas es la misma prueba, hecha de forma continua y sobre toda la población en lugar de una muestra. La idea sirve igual para las aprobaciones (cualquier acceso otorgado en el último día sin una aprobación enlazada), para SoD (cualquier conflicto nuevo sin una excepción aprobada) y para los grupos privilegiados (cualquier miembro que no se otorgó a través del programa).

A esto se le suele llamar monitoreo continuo de controles, y cambia la relación con la auditoría. Los problemas se encuentran en un día y no meses después. La auditoría anual pasa a ser una revisión de si el monitoreo corrió y qué encontró, en lugar de una investigación desde cero. Y las métricas del programa dejan de ser afirmaciones propias, porque las mismas consultas que las producen son las que podrían correr los auditores.

Lo mejor es empezar en pequeño: elegir los dos o tres controles que los auditores prueban cada año, escribir cada prueba como una consulta programada con un responsable de revisar sus resultados y dejar que la evidencia de esas ejecuciones se vaya acumulando. Al cabo de un año, el programa tiene doce meses de evidencia de que los controles funcionaron, producida casi sin esfuerzo adicional.

Un calendario de evidencia

Hay evidencia que no se puede producir después, cuando se pide. Una revisión trimestral necesita la foto de su alcance tomada el día que empieza la campaña. Un reporte sobre una fecha pasada necesita una historia que se haya estado guardando durante ese periodo. Un periodo de SOC 2 Tipo II necesita evidencia de su primera semana tanto como de la última.

Un calendario de evidencia lista, para cada control, qué evidencia produce, cuándo y dónde se guarda, y asigna a alguien que compruebe cada trimestre que esa evidencia existe. Es un documento poco vistoso, y marca la diferencia entre ir juntando la evidencia a medida que ocurre e intentar reconstruirla con el plazo encima.

Proteger la pista de auditoría

Los registros solo son evidencia si no se pueden cambiar en silencio. Una pista de auditoría que puede editar un administrador de IGA es una pista que no demuestra nada sobre lo que hicieron los administradores de IGA.

Lo básico está bien establecido. Los registros de auditoría deberían poder agregarse pero no modificarse ni borrarse, e idealmente enviarse en el momento en que se crean a un sistema aparte que el equipo de IGA no administre, a menudo la plataforma de gestión de eventos e información de seguridad (SIEM) de la organización. La hora de todos los sistemas involucrados debería estar sincronizada, porque una cadena que depende de comparar marcas de tiempo entre sistemas se desarma cuando los relojes difieren en minutos. Y el acceso a los propios registros de auditoría debería estar limitado y registrado.

Quienes administran la plataforma de IGA merecen atención especial. Pueden cambiar reglas, ajustar el enrutamiento de aprobaciones, a veces otorgar acceso directamente y corregir datos de identidad. Sus acciones deberían registrarse en detalle y revisarse con regularidad por alguien de fuera del equipo de IAM, a menudo seguridad o auditoría interna, con alertas para las acciones más delicadas, como cambios en reglas de SoD, aprobaciones hechas en nombre de otra persona u otorgamientos directos que se saltan el proceso de solicitud. Aquí es también donde retoma el hilo el dominio de detección de amenazas de identidad, más adelante en el sitio: los registros de IGA son una de las fuentes más ricas de señales sobre el mal uso de identidades.

Cuánto tiempo conservarla

La retención la fija el requisito más estricto que aplique, equilibrado con la preferencia de las leyes de privacidad por no guardar datos personales más tiempo del necesario.

PCI DSS exige al menos doce meses de historial de logs, con los tres meses más recientes disponibles de inmediato para su análisis. La regla de seguridad de HIPAA exige conservar seis años las políticas, procedimientos y documentación de seguridad relacionada. Las organizaciones sujetas a SOX suelen conservar la evidencia de acceso el tiempo necesario para auditar periodos anteriores, a menudo varios años, con la orientación de su área legal. En sentido contrario, las leyes de privacidad como el RGPD y sus equivalentes latinoamericanas esperan que los datos personales, que los registros de auditoría contienen, se guarden solo mientras haya un propósito para ello.

La respuesta práctica es un calendario de retención escrito para los registros de IGA, acordado con legal y cumplimiento, que diga cuánto tiempo se guarda cada tipo de registro, dónde y cómo se borra al final. Guardarlo todo para siempre no es una política, y tampoco lo es guardar lo que la plataforma conserve por defecto.

Ejemplo trabajado: un requerimiento de SOX en una empresa industrial

Una empresa industrial que cotiza en bolsa recibe el requerimiento del principio de este artículo. Hace dos años, responderlo llevó seis semanas. Este año, el equipo de IAM corre cuatro reportes estándar.

Para el acceso a asientos contables, el equipo corre el reporte de acceso a una fecha para el entitlement ERP.GLJournal.Post, para cada día entre el 1 de enero y el 30 de junio. Aparecen 61 personas que lo tuvieron en algún momento, 9 de las cuales ya no lo tienen. La lógica del reporte se les explicó a los auditores en febrero, y su total se contrasta con el propio registro de cambios del ERP para ese entitlement. Los auditores toman 25, y para cada una la plataforma produce la cadena: el rol o la solicitud que otorgó el acceso, su aprobación, la operación de aprovisionamiento y la reconciliación que lo confirmó. Dos de las 25 recibieron el acceso a través de un rol; para ellas, la evidencia es la regla de asignación, su versión en ese momento y su aprobación.

Para las bajas, el reporte de retiro lista las 214 bajas del periodo según RR. HH., con la hora de baja y la hora de retiro confirmado en cada uno de los tres sistemas dentro del alcance. Los auditores comparan el conteo con el reporte de bajas del propio RR. HH. y luego toman 25. A veinticuatro se les retiró el acceso dentro de la ventana de cuatro horas en los despidos y de un día en los demás casos. A una se le retiró el acceso al portal bancario a los tres días porque la tarea manual estaba vencida; el reporte muestra el escalamiento, y el equipo ya lo había documentado como excepción con su causa raíz.

Para las revisiones de acceso, el reporte de certificación muestra las dos campañas trimestrales de los tres sistemas: el alcance generado a partir del estado de los sistemas, cada decisión con su revisor y su hora, y la confirmación por reconciliación de cada revocación.

Toda la respuesta se entrega en dos días. Los auditores dedican su tiempo a probar y no a esperar datos, y la única excepción llega ya explicada.

Un ejemplo más corto: el primer SOC 2 Tipo II de una startup

Una empresa de software de 150 personas se prepara para su primera auditoría SOC 2 Tipo II, que cubre un periodo de observación de seis meses. Una auditoría Tipo I solo comprueba que los controles estén bien diseñados en una fecha; la Tipo II comprueba que funcionaron durante todo el periodo, lo que exige evidencia de los seis meses completos.

El IGA de la empresa es liviano: un proveedor de identidad con SCIM hacia sus principales aplicaciones SaaS, las solicitudes de acceso en una herramienta de tickets y las revisiones trimestrales en hojas de cálculo. Sus asesores le sugieren tres cambios antes de que empiece el periodo. Las solicitudes de acceso pasan a un formulario que registra el entitlement, quien aprueba y la fecha de fin como campos estructurados, para poder sacar reportes. Las revisiones trimestrales siguen en hojas de cálculo, pero se generan a partir de la exportación del proveedor de identidad en una fecha fija y se guardan con la firma del revisor y el ticket de cada revocación. Y los logs del proveedor de identidad se envían a un almacén aparte con doce meses de retención, para poder mostrar los tiempos de las bajas de cualquier día del periodo.

Cuando llegan los auditores, terminado el periodo, cada muestra que eligen tiene su evidencia en uno de esos tres lugares, y el informe sale sin excepciones en los controles de acceso.

Nada de esto exige una plataforma de IGA. Exige decidir, antes de que empiece el periodo, qué evidencia producirá cada control y dónde se guardará.

Errores frecuentes

Armar la respuesta de auditoría a mano cada año es el patrón más caro, y casi nunca mejora, porque el saber de cómo se hizo se va con quien lo hizo.

Guardar solo el estado actual deja sin respuesta las preguntas sobre fechas pasadas. Los reportes sin lógica documentada no pasan la prueba de IPE del auditor, y una población que resulta incompleta puede invalidar semanas de trabajo.

Los registros de auditoría que pueden editar los administradores de IGA, o que solo viven dentro de la plataforma de IGA, no pueden demostrar nada sobre las personas que controlan la plataforma.

Dejar la retención en los valores por defecto hace que los registros ya no estén cuando se necesitan o que se guarden mucho después de que dejaron de tener propósito.

Y los reportes operativos sin responsable se acumulan sin leer, hasta que el que importaba, una cola creciente de retiros fallidos, lo descubre el auditor y no el equipo.

Qué medir

Unas pocas cifras describen si la auditoría y los reportes están en buena forma. El tiempo para producir una respuesta de auditoría estándar, desde el requerimiento hasta la entrega, es la más directa; debería bajar de semanas a días a medida que el programa madura. El número de hallazgos de auditoría relacionados con el acceso, y cuántos de ellos ya conocía el programa antes de que los encontrara el auditor, muestra si los reportes propios funcionan. La proporción de sistemas dentro del alcance con historial para consultar fechas pasadas muestra cuántas preguntas puede responder el programa. Y la proporción de elementos de los reportes operativos atendidos dentro de su nivel de servicio muestra si esos reportes se usan de verdad.

Otras dos cobran sentido cuando el monitoreo continuo está en marcha. Una es el número de controles clave con una prueba diaria automatizada, comparado con el número de controles que los auditores prueban cada año; cuanto más se acercan esas dos cifras, menos depende la auditoría anual de reconstruir. La otra es la proporción entre las desviaciones que encontró el propio programa y las que encontró primero un auditor. Un programa que encuentra la mayoría de sus propios problemas es un programa cuyos reportes merecen confianza, y a eso apunta, al final, todo este artículo.

Cómo se relaciona con los estándares

La familia de auditoría de la NIST SP 800-53 Rev. 5 encaja casi punto por punto con este artículo: AU-2 y AU-3 definen qué eventos registrar y qué debe contener cada registro, AU-6 cubre la revisión y los reportes, AU-9 la protección de la información de auditoría, también frente a usuarios privilegiados, AU-11 la retención, y AC-2(4) exige auditar de forma automática las acciones sobre cuentas. PCI DSS v4.0 pone el registro y el monitoreo del acceso en el requisito 10, con el 10.5.1 pidiendo conservar los logs de auditoría al menos doce meses, tres de ellos disponibles de inmediato. ISO/IEC 27001:2022, en los controles 8.15 de registro de eventos y 5.33 de protección de los registros de su Anexo A, exige producir, proteger y analizar los logs, y proteger los registros contra la pérdida y la falsificación. Un informe SOC 2 Tipo II prueba cómo funcionaron los controles de acceso durante todo un periodo, algo imposible sin evidencia como la que describe este artículo. Y para SOX, los auditores prueban los controles generales de TI, el acceso entre ellos, según la PCAOB AS 2201, el estándar de las auditorías del control interno sobre la información financiera, que es de donde sale el correo del principio de este artículo.

Cerrando el módulo

Este módulo recorrió los componentes core de un programa de IGA: la solicitud que deja entrar el acceso, la certificación que lo revisa, los roles que lo empaquetan, las políticas que lo asignan solas, el aprovisionamiento que lo hace realidad y, ahora, los registros que demuestran que todo eso ocurrió. Cada componente por separado es un proceso. Juntos, con sus registros enlazados, son un programa capaz de explicar cualquier acceso que gobierna.

Resumen

Un programa de IGA tiene que registrar cada cambio de acceso y cada decisión que lo respalda, incluidas las versiones de las políticas, los resultados del aprovisionamiento, los hallazgos de la reconciliación y lo que hacen sus propios administradores. Esos registros solo se convierten en evidencia cuando forman una cadena de la decisión a la operación y a la confirmación que se puede seguir en los dos sentidos; los logs que alguien tiene que unir a mano son materia prima. Los auditores prueban una muestra sacada de una población que tú les das, y prueban también el reporte que generó esa población, así que su lógica debe estar documentada y acordada con ellos desde el principio. Hay que guardar la historia para poder decir qué acceso existía en una fecha pasada, y versionar reglas y roles para poder decir qué decían en ese momento. Cada reporte se diseña para un lector y una acción, operativo, de cumplimiento, de riesgo o ejecutivo, con cada métrica definida, separada por nivel de riesgo y con la fecha de frescura de sus datos. El programa hace por su cuenta las pruebas del auditor, de forma continua, y registra los controles fallidos con su causa y su arreglo antes de que otro los encuentre. Y la pista de auditoría se protege frente a quienes administran la plataforma y se conserva durante un plazo acordado con legal y cumplimiento. Con todo eso, el correo anual se responde en dos días y no en seis semanas.

Tres preguntas para ponerte a prueba

1. Un auditor pide a todas las personas que tuvieron acceso de administrador al sistema de pagos en algún momento del trimestre pasado. Tu plataforma solo reporta el acceso actual. ¿Qué faltará en tu respuesta y qué tendrías que haber estado haciendo para responderla completa?
2. ¿Por qué un auditor prueba el reporte que le das, y no solo los elementos que muestrea de él? Da un ejemplo de un error en el reporte que invalidaría la prueba.
3. Tus administradores de IGA pueden aprobar solicitudes en nombre de aprobadores ausentes. ¿Qué registrarías, quién lo revisaría y sobre qué alertarías?

Ejercicio práctico

Toma un control de acceso que conozcas, como el retiro en las bajas, una revisión trimestral o la aprobación de acceso privilegiado.

1. Escribe el requerimiento probable del auditor: la población, el tamaño de la muestra y lo que buscará en cada elemento.
2. Enumera cada registro necesario para responderlo, el sistema donde vive y el identificador que los enlaza.
3. Describe cómo demostrarías que el reporte de la población está completo.
4. Decide cuánto tiempo debería conservarse cada registro y justifícalo con al menos una regulación o estándar.