ISO 27001:2022 aborda el registro y la monitorización principalmente a través de tres controles del Annex A: 8.15 (registro), 8.16 (actividades de monitorización) y 8.17 (sincronización de relojes). En conjunto, exigen registrar los eventos relevantes para la seguridad, proteger esos registros, vigilar los sistemas en busca de comportamientos anómalos y mantener la fiabilidad de las marcas de tiempo. Los auditores no quieren saber qué herramienta usas. Quieren demostrar que decidiste qué registrar, que alguien lo revisa y que se actúa sobre lo que se observa.
Esta guía explica cada control en términos sencillos, muestra las evidencias que un auditor suele solicitar y propone un orden de implantación adecuado para un equipo de seguridad pequeño.
En Resumen
- El control 8.15 trata de producir, proteger y revisar los registros. El control 8.16 trata de vigilar activamente en busca de anomalías. Superar uno no implica superar el otro.
- Define primero el alcance: qué sistemas, qué eventos, quién revisa, con qué frecuencia y cuánto tiempo se conservan los registros. Documéntalo y demuestra que funciona.
- Centraliza los registros y mantén los relojes sincronizados (8.17), o no podrás reconstruir un incidente entre distintos sistemas.
- Separa funciones siempre que sea posible: quienes administran un sistema no deberían ser los únicos que revisen sus registros.
- Presupuesta el esfuerzo con antelación. Las herramientas de registro y el tiempo de revisión son partidas de coste reales en un proyecto de ISO 27001.
Índice
- Cómo encajan los tres controles
- Control 8.15: un registro que supera una auditoría
- Control 8.16: una monitorización que detecta algo
- Control 8.17: el silencioso que rompe las investigaciones
- Evidencias que pedirá ver un auditor
- Un orden de implantación que funciona
- Notas sectoriales: finanzas y datos de pago
- Errores habituales
- Nuestra perspectiva
- Estima el esfuerzo antes de comprometerte
- Preguntas frecuentes
- Fuentes
Cómo encajan los tres controles
Imagina una cadena. El control 8.15 crea y protege la materia prima. El control 8.17 hace que las marcas de tiempo de esa materia prima sean comparables. El control 8.16 la convierte en detección.
| Control | Qué exige | Evidencias típicas |
|---|---|---|
| 8.15 Registro | Producir, almacenar, proteger y analizar registros de actividades, excepciones, fallos y otros eventos relevantes | Estándar de registro, registros de muestra, configuración de retención, restricciones de acceso al almacén de registros |
| 8.16 Actividades de monitorización | Monitorizar redes, sistemas y aplicaciones en busca de comportamientos anómalos y responder adecuadamente | Reglas de alerta, registros de revisión, tickets abiertos a partir de alertas, cadena de escalado |
| 8.17 Sincronización de relojes | Mantener los relojes de los sistemas de tratamiento de información alineados con fuentes horarias aprobadas | Configuración NTP, captura de pantalla o exportación que muestre hora consistente en todos los sistemas |
Un hallazgo de auditoría habitual es el de una empresa que registra todo pero no revisa nada. Los registros almacenados en un repositorio son, como mucho, evidencia del control 8.15. Una forma de recordarlo: el registro responde a "qué ocurrió"; la monitorización responde a "¿hay algo mal ahora mismo?".
Control 8.15: un registro que supera una auditoría
Parte del riesgo, no de la herramienta. Tu evaluación de riesgos debe indicarte qué sistemas son críticos, y tu estándar de registro debe derivarse de ello.
Qué registrar
Una línea base defendible cubre:
- Eventos de autenticación: inicios de sesión correctos y fallidos, cambios en MFA, restablecimientos de contraseña.
- Actividad privilegiada: acciones de administrador, cambios de roles, uso de cuentas de acceso de emergencia.
- Acceso a datos sensibles y modificaciones en los derechos de acceso.
- Cambios en los sistemas: cambios de configuración, nuevos servicios, despliegues.
- Salidas de herramientas de seguridad: protección de endpoints, cortafuegos, detección de intrusiones, resultados del escáner de vulnerabilidades.
- Fallos y excepciones: copias de seguridad fallidas, caídas de servicios, apagados inesperados.
No es necesario registrar todos los sistemas con el mismo nivel de detalle. Una base de datos de clientes y una impresora no deben tener la misma carga de registro, y un auditor esperará ver ese razonamiento en tu tratamiento de riesgos.
Proteger los propios registros
Los registros solo son evidencia si nadie puede modificarlos discretamente. Medidas prácticas:
- Envía los registros a un almacén central separado del sistema que los generó.
- Restringe los derechos de escritura y eliminación a un grupo reducido, y registra el acceso al almacén de registros.
- Usa almacenamiento inmutable o de una sola escritura para los registros de alto valor cuando tu plataforma lo permita.
- Establece un período de retención que se ajuste a las necesidades legales, contractuales e investigadoras, y documenta el motivo de tu elección.
- Trata los registros que contengan datos personales como datos personales: limita quién puede verlos y evita capturar más de lo necesario.
Retención: elige, justifica y aplica
ISO 27001 no te impone un número de días. Tú decides en función de tus obligaciones. En función de tu país y sector, esto puede incluir normativas sectoriales o contratos con clientes, así que comprueba qué dicen tus propios acuerdos antes de fijar un período. Aplícalo después de forma coherente. Un auditor comparará tu política escrita con la configuración real de tu plataforma de registros, y una discrepancia es una no conformidad fácil de evitar.
Control 8.16: una monitorización que detecta algo
La monitorización es donde muchos implantadores por primera vez fallan. El control exige vigilar comportamientos anómalos y evaluar posibles incidentes. Eso requiere casos de uso definidos, un responsable y una vía de respuesta.
Empieza con una lista corta de alertas
Diez alertas bien ajustadas superan a doscientas ignoradas. Buenos candidatos para empezar:
- Múltiples inicios de sesión fallidos seguidos de uno exitoso.
- Una cuenta nueva añadida a un grupo de administradores.
- Inicio de sesión desde un país inusual o desplazamiento imposible entre ubicaciones.
- Desactivación de la protección de endpoints o de los agentes de registro.
- Grandes transferencias salientes desde un sistema sensible.
- Acceso a datos de producción fuera del horario habitual por parte de alguien que normalmente no lo hace.
Para cada alerta, escribe quién la recibe, con qué rapidez debe revisarla y qué se considera un incidente. Este último punto vincula la monitorización con tu proceso de gestión de incidentes. Nuestra guía sobre los cinco controles de incidentes que verifican los auditores muestra cómo una alerta se convierte en un evento registrado y en un incidente evaluado.
Hacer que las alertas sean útiles para la respuesta
Las lecciones aprendidas de CISA en un ejercicio de respuesta a incidentes plantean el registro como una prueba de si los responsables de respuesta pueden utilizarlo. Generar una alerta no es suficiente: el equipo necesita pasar de la alerta a los registros correlacionados de identidad, endpoint y nube para reconstruir los eventos, y aquí es donde un SIEM centralizado resulta útil. Puedes aplicar esa prueba a tu propio programa. Toma una alerta reciente y comprueba si alguien podría, en menos de una hora, rastrear la cuenta implicada en tu proveedor de identidad, el equipo afectado y tu consola cloud.
Para los equipos que deseen una visión más detallada de la arquitectura, la Arquitectura de Referencia de Registro de CISA describe un registro orientado a la detección oportuna, la búsqueda de amenazas, la respuesta a incidentes y la forense, no solo a la recopilación y retención. Está redactada para agencias federales, pero los principios son aplicables a empresas privadas.
Si ejecutas aplicaciones propias, la monitorización a nivel de aplicación también es relevante. Esta visión general sobre buenas prácticas de monitorización de aplicaciones es un complemento útil para los ingenieros que necesitan conectar la monitorización de errores y rendimiento con las alertas de seguridad.
Independencia en la revisión
La separación de funciones se aplica también a la monitorización. El Manual de Examen TI del FFIEC, elaborado para entidades financieras, indica que el personal que administra sistemas o seguridad no debería ser el mismo que monitoriza los registros de actividad de esos sistemas. ISO 27001 no es una norma bancaria, pero la lógica es la misma para cualquier organización: si el administrador puede actuar y revisar, el uso indebido puede pasar desapercibido.
Los equipos pequeños a menudo no pueden separar completamente estas funciones. En ese caso, documenta el control compensatorio. Por ejemplo, una segunda persona, un responsable o un proveedor externalizado recibe un resumen periódico de la actividad privilegiada. La guía del FFIEC sobre proveedores de servicios de seguridad gestionados describe la gestión de registros de eventos y las alertas como un servicio que puede externalizarse, una opción válida para equipos reducidos. Si externalizas, recuerda que los controles del proveedor entran en tu alcance; consulta nuestra explicación sobre la gestión de proveedores en ISO 27001.
Control 8.17: el silencioso que rompe las investigaciones
La sincronización de relojes parece trivial hasta que intentas correlacionar un registro de cortafuegos, un registro de portátil y un registro de auditoría en la nube que difieren en varios minutos. Apunta los sistemas a fuentes horarias acordadas (normalmente NTP), estandariza en una única zona horaria para los registros de seguridad (muchos equipos eligen UTC) y conserva un registro de la configuración. Incluye una verificación de la deriva. Los auditores suelen aceptar una captura de pantalla o una exportación de configuración de una muestra de sistemas.
Evidencias que pedirá ver un auditor
Prepara una carpeta, física o digital, con estos elementos antes de la auditoría de Fase 2:
- Política o estándar de registro y monitorización, aprobado por la dirección.
- Una lista de fuentes de registro en alcance, con sus responsables.
- Configuración de retención, concordante con la política.
- Lista de acceso a la plataforma de registros, con una revisión reciente.
- Reglas de alerta y el razonamiento que las sustenta.
- Prueba de revisión: registros de revisión con fecha, exportaciones de tickets o un informe del panel de monitorización.
- Al menos un ejemplo en que una alerta derivó en una investigación y su resultado.
- Configuración de sincronización horaria de una muestra de sistemas.
- Actas de revisión por la dirección que mencionen los resultados de la monitorización.
El punto 7 es el más importante. Si no has tenido ningún incidente real, realiza un ejercicio de mesa o una alerta de prueba y documéntala. Un control que nunca se ha activado es difícil de demostrar.
Un orden de implantación que funciona
Semanas 1 a 2: decidir y documentar
Enumera los sistemas críticos a partir del inventario de activos y la evaluación de riesgos. Define las fuentes de registro, los eventos mínimos, la retención y los responsables de revisión. Mantén la política lo suficientemente breve como para que la gente la lea.
Semanas 3 a 6: recopilar y proteger
Activa el registro de auditoría en tu proveedor de identidad, cuentas en la nube, endpoints y herramientas SaaS clave. Envíalos a una ubicación central. Restringe el acceso y corrige la configuración horaria.
Semanas 7 a 10: detectar y responder
Crea las primeras diez alertas, asigna responsables y pruébalas. Conéctalas al flujo de trabajo de tickets de incidentes.
De forma continua: revisar y mejorar
Programa una revisión periódica, traslada los hallazgos a la revisión por la dirección y ajusta las reglas de alerta tras cada incidente o casi incidente. Para el calendario general de este trabajo, consulta nuestro cronograma de implantación de ISO 27001. La secuencia anterior es un ejemplo de planificación, no un requisito fijo. Tu ritmo depende de las herramientas, el personal y la madurez de partida.
Notas sectoriales: finanzas y datos de pago
Las entidades financieras afrontan expectativas adicionales porque reguladores e inspectores leen los registros como evidencia de control. Si también gestionas datos de tarjetas, PCI DSS tiene sus propios requisitos de registro, y una única capacidad puede servir con frecuencia a ambos programas. Nuestro artículo sobre el mapeo de PCI DSS v4.0.1 en ISO 27001 muestra cómo reducir el trabajo de auditoría duplicado. Para escenarios de brechas, la guía de respuesta a brechas de datos para el sector financiero y la guía de respuesta a incidentes en banca muestran cómo los registros alimentan la respuesta.
Errores habituales
- Registrar todo, revisar nada. El volumen no es control. Delimita lo que puedes revisar realmente.
- Guardar los registros en el mismo host. Un atacante con derechos de administrador puede borrarlos.
- Retención no documentada. Una configuración que difiere de la política es un hallazgo fácil.
- Sin responsable nominal para las alertas. Una alerta enviada a una bandeja de entrada compartida suele ser una alerta que nadie lee.
- Tratar el SIEM como el control. La herramienta apoya el control. El proceso de revisión y respuesta es el control.
- Ignorar SaaS y la nube. Muchos incidentes comienzan en un proveedor de identidad o una consola cloud, no en un servidor.
Si quieres un modelo sobre cómo un proveedor describe sus propias prácticas de seguridad, una página como la descripción general de seguridad de WorldEye muestra cómo un servicio puede presentar públicamente sus medidas de protección. Usa ese tipo de página como referencia sobre lo que tus propios clientes podrían preguntar acerca de tu gestión de registros.
Nuestra perspectiva
Elaboramos estimaciones de coste y esfuerzo para proyectos de ISO 27001, y el registro y la monitorización es la partida que más sorprende a la gente. La licencia de una plataforma de registro rara vez es el mayor coste. Lo es el tiempo: ajustar las alertas, establecer la rutina de revisión y tener a alguien responsable mes tras mes. Los equipos que presupuestan solo la herramienta acaban con un costoso repositorio de registros sin leer.
Nuestro consejo es dimensionar este control primero en horas-persona. Pregúntate cuántos sistemas conectarás, cuántas alertas puede gestionar alguien de forma realista por semana y si necesitas un proveedor externo para cubrir noches y fines de semana. Después compara tus cifras con valores de referencia del modelo para saber si estás planificando con demasiado margen o de forma insuficiente. Un equipo que afronta esto por primera vez en un sector regulado debería esperar invertir más aquí que una startup de software de diez personas, porque el listón de evidencias y el número de sistemas son más altos.
También creemos que los auditores valoran la honestidad. Un conjunto reducido de alertas en funcionamiento con registros de revisión fechados supera a un diseño ambicioso que solo existe en una presentación.
— Martin
Estima el esfuerzo antes de comprometerte
Si estás planificando una auditoría y quieres ver cómo el registro, la monitorización y los demás controles del Annex A afectan al coste y al calendario, prueba la calculadora de costes de ISO 27001. Ofrece estimaciones según el tamaño de la empresa, el sector y la madurez en seguridad, y puedes empezar sin registrarte. ¿No sabes dónde estás? La evaluación gratuita de preparación en 2 minutos te da una primera lectura rápida, y la evaluación de preparación completa va dominio por dominio. Cuando estés elaborando tu plan completo, la lista de verificación de certificación en 80 pasos te ayuda a situar el trabajo de registro entre las demás tareas.
Preguntas frecuentes
¿Es obligatorio el registro para la certificación ISO 27001?
En la práctica, sí. El control 8.15 del Annex A cubre el registro, y si lo excluyes en tu Declaración de Aplicabilidad necesitas una justificación sólida, algo difícil de aportar para cualquier organización con sistemas TI. Los auditores esperan ver registros de los sistemas dentro de tu alcance.
¿Cuál es la diferencia entre el control 8.15 y el 8.16?
El control 8.15 trata de producir, proteger y analizar registros. El control 8.16 trata de monitorizar redes, sistemas y aplicaciones en busca de comportamientos anómalos y responder a ellos. Necesitas ambos: el primero te proporciona el registro y el segundo te proporciona la detección.
¿Necesito un SIEM para cumplir con ISO 27001?
La norma no nombra ninguna herramienta. Un SIEM o un servicio de detección gestionado facilitan enormemente la correlación y la revisión, y las directrices de CISA señalan la correlación centralizada como una ayuda para la respuesta. Una empresa pequeña puede cumplir los controles con registros centralizados, unas pocas alertas fiables y revisiones documentadas.
¿Cuánto tiempo debo conservar los registros?
ISO 27001 no establece un período fijo. Elige un tiempo de retención basado en obligaciones legales, contratos con clientes y el tiempo que necesitas para investigar incidentes, recógelo en tu política y asegúrate de que la configuración de tu plataforma coincide.
¿Puede una misma configuración de registro satisfacer tanto ISO 27001 como PCI DSS?
Con frecuencia sí, cuando se diseña teniendo en cuenta ambos, ya que los dos exigen actividad registrada y revisada. Mapea los requisitos lado a lado y confirma los detalles con tu evaluador. Nuestro artículo sobre el mapeo de PCI DSS e ISO 27001 explica el enfoque.
Fuentes
- CISA: lecciones aprendidas de un ejercicio de respuesta a incidentes
- CISA: Arquitectura de Referencia de Registro
- Manual TI del FFIEC: operaciones informáticas y de red de soporte a transferencias de fondos
- Manual TI del FFIEC: proveedores de servicios de seguridad gestionados