Logs y trazabilidad: qué exige el ENS y cómo implementarlo
Requisitos de trazabilidad del ENS: qué eventos registrar, con qué retención, cómo proteger la integridad de los logs y cómo usarlos en auditoría.
La trazabilidad es una de las cinco dimensiones de seguridad del ENS. En el Anexo II se concreta sobre todo en las medidas op.exp.8 (Registro de actividad de los usuarios), op.exp.9 (Registro de la actividad de los administradores) y op.mon.3 (Sistema de métricas). La auditoría pone mucho foco aquí: es fácil detectar a un vistazo si la organización mira sus logs o solo los acumula.
Qué eventos hay que registrar
Como mínimo, los logs deben capturar:
Actividad de usuarios
- Autenticaciones (éxito y fallo).
- Cambios de privilegios.
- Accesos a información sensible.
- Exportación o descarga masiva.
- Operaciones críticas de negocio.
Actividad de administradores
- Inicios de sesión administrativos.
- Cambios de configuración en sistemas, aplicaciones y red.
- Creación, modificación y borrado de cuentas.
- Otorgamiento de permisos elevados.
- Ejecución de comandos con privilegios (sudo, RunAs).
- Accesos a consolas de gestión cloud.
Eventos de seguridad
- Alertas de EDR, antivirus, SIEM, IDS/IPS.
- Cambios en reglas de firewall.
- Actualizaciones de software críticas.
- Intentos de intrusión.
- Fallos de integridad.
Eventos de aplicación relevantes
- Transacciones críticas.
- Cambios de datos maestros.
- Invalidaciones de caché o rollbacks.
- Envío de comunicaciones externas (emails, integraciones).
Qué información debe contener cada evento
Un log útil tiene, como mínimo:
- Timestamp en UTC o con zona horaria explícita (milisegundos si es posible).
- Origen (host, aplicación, servicio).
- Usuario / identidad (cuenta o servicio).
- IP / dispositivo / sesión.
- Acción realizada.
- Resultado (éxito / fallo).
- Contexto adicional (recurso afectado, versión, parámetros relevantes).
Un log que dice solo “Error” no sirve. Un log que incluye todos los campos anteriores es oro.
Retención
El ENS no fija un plazo universal de retención, pero las buenas prácticas y la interpretación común del auditor son:
| Tipo | Retención mínima |
|---|---|
| Logs de autenticación | 1 año |
| Logs de admin y seguridad | 2 años |
| Logs de aplicaciones críticas | Según normativa sectorial (sanidad, financiero pueden pedir más) |
| Logs relacionados con incidentes | Hasta cierre + 5 años |
Si hay datos personales en los logs (frecuente), hay que conjugar retención con principio de minimización del RGPD.
Protección de la integridad
Los logs son útiles solo si son confiables. Medidas:
- Centralización en un sistema al que los servidores solo pueden enviar, no modificar (logs write-only desde el origen).
- Almacenamiento inmutable (WORM, S3 object lock, Append-only).
- Firma o hash periódico de los bloques de logs.
- Separación de roles: quien opera el sistema no puede borrar sus logs.
- Controles de acceso estrictos al sistema de logs.
Herramientas
Las más frecuentes en nuestros proyectos:
- SIEM open source: Wazuh, Elastic SIEM, Graylog.
- SIEM comercial: Splunk, QRadar, Microsoft Sentinel, Google Chronicle.
- Data lakes: S3 + Athena, BigQuery, Snowflake.
- Forwarders: Fluent Bit, Filebeat, NXLog, Vector.
La elección depende del volumen y del presupuesto. Wazuh cubre bien Media. Para Alta con volumen alto, suele imponerse Sentinel o Splunk.
Correlación y alertado
Recoger logs sin casos de uso es acumular por acumular. Debes definir:
- Casos de uso (p.ej. “múltiples fallos de login seguidos de un éxito”).
- Umbrales y reglas de detección.
- Proceso de respuesta por alerta (playbook).
- Revisión periódica de la eficacia.
Un set mínimo inicial: 20–30 reglas cubriendo autenticaciones anómalas, exfiltración, cambios de privilegio, malware y alertas de proveedor cloud.
Evidencias para el auditor
El auditor pedirá:
- Política o procedimiento de logging.
- Inventario de sistemas con logs centralizados.
- Configuración de retención.
- Muestra de logs con los campos mínimos.
- Casos de uso y alertas definidos.
- Evidencia de revisión periódica (actas, tickets de investigación).
- Registro de incidentes detectados a través de logs.
Presentar un SIEM sin alertas ni revisiones equivale a no tener SIEM.
Errores frecuentes
- Registrar todo sin discriminar. Explota el coste y hace los análisis imposibles.
- No registrar lo importante (acciones de admin, exportaciones). Queda expuesto en auditoría.
- Logs en el propio servidor donde ocurren. Si el servidor se compromete, los logs también.
- Sin rotación ni backup. Disco lleno, no hay logs nuevos.
- Logs con datos personales sin control. Problemas de RGPD.
- Nadie los mira. El peor caso.
Casos de uso mínimos para empezar
Si estás arrancando y necesitas priorizar:
- Múltiples fallos de autenticación seguidos de éxito.
- Accesos desde IP geográficamente anómalas.
- Escalado de privilegios inesperado.
- Creación de cuentas con privilegios elevados.
- Exportación masiva de datos.
- Desactivación de controles de seguridad (EDR, antivirus).
- Acceso a bases de datos en horario no habitual.
- Cambios en reglas de firewall críticas.
Con esos ocho casos cubiertos, una organización Media puede defender bien la exigencia de monitorización.
Revisión operativa
Las revisiones periódicas también deben dejar rastro:
- Diaria: revisión de alertas de alta criticidad.
- Semanal: revisión de alertas medias y tendencias.
- Mensual: revisión de falsos positivos y ajuste de reglas.
- Trimestral: revisión completa de casos de uso y cobertura.
Un guardia rotatorio con horarios documentados demuestra el proceso.
Recomendación final
Una buena estrategia de logging no es la que más datos captura, sino la que captura lo correcto, lo protege de manipulación y se revisa con proceso. En auditoría, tres elementos marcan la diferencia: centralización, retención probada e historial de alertas investigadas. Lo demás es ruido.