Registro, el control que muere en silencio.
ISO 27001:2022 A.8.15 (registro) exige que los eventos relevantes para la seguridad (inicios de sesión, errores, fallos, acceso a datos sensibles) se registren, se conserven durante un período definido y se protejan contra manipulaciones. Es fundamental para A.8.16 (monitoreo) y para cualquier investigación posterior: no se puede detectar ni reconstruir lo que nunca se registró. Y es fácil debilitarlo sin darse cuenta, porque una línea de registro es el tipo de línea que suele eliminarse al limpiar el código.
The shapes the same control failure takes.
A.8.15 rara vez se rompe con un cambio dramático. Se rompe cuando un evento relevante para la seguridad deja de registrarse. Las formas recurrentes:
Se elimina un registro de seguridad
Una llamada de registro para un evento de autenticación, un cambio de privilegios o acceso a datos sensibles se borra durante una limpieza porque parecía ruidosa.
El nivel de registro baja por debajo del de producción
Un evento de seguridad se mueve a un nivel (debug) que no se emite en producción, por lo que deja de registrarse silenciosamente donde importa.
El actor se omite del registro
Un registro sigue disparándose, pero deja de incluir quién lo realizó, por lo que el evento ya no puede atribuirse durante una investigación.
Una nueva acción privilegiada se envía sin registro
Se añade una nueva operación de administrador o destructiva sin ningún registro de auditoría, por lo que no hay nada que muestrear después.
Se acorta el período de retención
La retención o rotación de un registro se reduce por debajo de lo que exige el control, por lo que el registro desaparece antes de que alguien lo necesite.
Fallas de autenticación eliminadas por debajo del nivel de registro de producción.
Los registros de fallos de autenticación son ruidosos en desarrollo, por lo que un cambio los mueve de advertencia a nivel debug. En producción, el nivel de registro está configurado en info, por lo que esos fallos ahora desaparecen por completo del registro, justo los eventos que más se necesitan al investigar una intrusión.
if (!valid) {- logger.warn("auth.failed", { userId, ip })+ logger.debug("auth.failed", { userId, ip }) return unauthorized()}Con el nivel de producción en info, reducir los fallos de autenticación a debug significa que ya no se registran en producción. A.8.15 exige que los eventos relevantes para la seguridad, incluidos los fallos de autenticación, se registren y conserven, y A.8.16 (monitoreo) depende de ellos. Manténgalos en advertencia o rediríjalos al registro de seguridad en lugar de silenciararlos en producción.
El registro se verifica con eventos reales.
Un auditor comprueba que los eventos relevantes para la seguridad realmente se registren, se conserven durante el período que establece su política y se protejan contra manipulaciones, y muestreará tipos de eventos específicos (inicios de sesión, cambios de privilegios, acceso a datos sensibles). Un cambio que silenciosamente dejó de emitir uno de esos eventos, ya sea eliminándolo o reduciéndolo por debajo del nivel de producción, es el vacío que encuentran. El cambio que lo introdujo solía ser una pull request ordinaria que parecía una reducción de ruido.
Una revisión, no su SIEM.
heygrc marca los cambios que afectan a A.8.15 y cita el control para que la corrección ocurra en la pull request. No ejecuta su canalización de registros ni su monitoreo. Detecta el momento en que un evento de seguridad deja de registrarse, en el diff.