op.exp.8 ENS: Registro de la Actividad, qué exige y cómo cumplirlo

op.exp.8 (Registro de la actividad) es la medida del Anexo II del Esquema Nacional de Seguridad (RD 311/2022) que obliga a dejar constancia de qué usuario o entidad hizo qué, cuándo y con qué resultado, en cada sistema dentro del alcance. Aplica ya en el nivel básico, y a partir del nivel medio se le suman cuatro refuerzos progresivos (R1 a R4); en el nivel alto se añade un quinto (R5). Es, de las medidas del marco operacional, la que más exigencia acumula por niveles — y también una de las que más falla en auditoría por dar por hecho que "tener logs" es lo mismo que "cumplir op.exp.8".

¿Qué exige exactamente op.exp.8?

op.exp.8 pertenece a la familia op.exp (Explotación) del marco operacional del Anexo II. En su forma base — la que ya exige el nivel básico — pide que cada registro de actividad capture, como mínimo, cuatro campos: identificador del usuario o entidad que actúa, fecha y hora del evento, qué evento ocurrió y el resultado (éxito o fracaso). Esto es notablemente más exigente que en la versión anterior del ENS: el RD 311/2022 elevó el listón de lo que se considera un registro de actividad válido, y muchas implantaciones antiguas que se dieron por buenas en su día ya no cubren el texto actual.

A partir de ahí, la exigencia crece por refuerzos que se acumulan según el nivel de la información y los servicios tratados:

En lenguaje llano, qué pide cada refuerzo:

• R1 — Revisión periódica: alguien tiene que mirar los registros con una cadencia definida. No basta con que existan; tiene que haber evidencia de que se revisan (informes, actas, tickets de revisión).
• R2 — Sincronización de tiempo: todos los sistemas que generan registros deben tener el reloj sincronizado contra una fuente común, normalmente NTP. Sin esto, correlacionar eventos entre servidores distintos es prácticamente imposible.
• R3 — Retención de registros: el periodo durante el que se conservan los registros debe estar definido y documentado en la política de seguridad, no depender de la rotación por defecto del sistema.
• R4 — Control de acceso a los registros: quién puede leer o modificar los logs debe estar restringido y controlado — un registro que cualquiera puede editar no sirve como evidencia.
• R5 — Análisis automático: exclusivo del nivel alto. El registro no se limita a almacenarse para revisión manual (R1); tiene que haber correlación o análisis automatizado que genere alertas ante patrones anómalos.

¿Qué evidencia concreta pediría un auditor?

Un auditor ENS no se conforma con ver que "hay logs". Pide, como mínimo, tres cosas: que los campos exigidos estén realmente presentes en cada registro, que la hora de cada evento sea fiable, y que exista un criterio de retención documentado — no implícito.

Sobre R2, la sincronización horaria es el fallo típico que se pasa por alto: es fácil desplegar un SIEM y olvidarse de que el reloj del propio servidor no está sincronizado con NTP. El resultado es que los logs se generan con marca de tiempo, pero esa marca no es de fiar cuando hay que reconstruir la secuencia de un incidente que toca varios sistemas. Un auditor puede pedir directamente la configuración del cliente NTP de cada activo, o un log de deriva horaria, como evidencia de R2.

Sobre R3, "retención" en la práctica significa tres cosas a la vez: un periodo definido por escrito en la política de seguridad, una configuración técnica que efectivamente conserve los registros ese tiempo (no siete días por defecto porque nadie tocó la rotación de logs), y una forma de demostrar que no se han borrado antes de tiempo. Que el sistema "guarde logs indefinidamente" no cumple R3 si nadie decidió ni documentó ese periodo — la ausencia de un criterio explícito es justo lo que suele fallar, no la duración en sí.

¿Qué se puede sacar de Wazuh para op.exp.8?

Wazuh no "activa" op.exp.8 con un interruptor, pero sí cubre técnicamente cada uno de sus componentes si se configura con ese objetivo:

Auditoría de actividad en Linux (auditd). El agente de Wazuh puede leer directamente el log de auditd, que es el subsistema estándar del kernel Linux para trazar acciones de usuarios (autenticación, cambios en ficheros críticos, comandos ejecutados con privilegios). Se configuran reglas en auditd:

# /etc/audit/rules.d/audit.rules
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-a always,exit -F arch=b64 -S execve -k exec_commands

Y en el agente, en /var/ossec/etc/ossec.conf:

<localfile>
  <log_format>audit</log_format>
  <location>/var/log/audit/audit.log</location>
</localfile>

Wazuh trae decoders y reglas ya preparados para el grupo audit, que extraen usuario, comando, resultado (éxito/fracaso) y timestamp — exactamente los cuatro campos base de op.exp.8.

Auditoría de actividad en Windows (Sysmon). En Windows, la política de auditoría avanzada nativa junto con Sysmon aporta el detalle de proceso, usuario y resultado que exige la medida. Se ingesta vía canal de eventos:

<localfile>
  <log_format>eventchannel</log_format>
  <location>Microsoft-Windows-Sysmon/Operational</location>
</localfile>

<localfile>
  <log_format>eventchannel</log_format>
  <location>Security</location>
</localfile>

Ya tenemos un caso práctico sobre cómo estas mismas fuentes sirven para detectar instalaciones de software en Windows con Wazuh, que es en realidad un subconjunto de esta misma medida.

R2 — sincronización de tiempo como evidencia. Wazuh no verifica por sí solo que el reloj del sistema operativo sea correcto: confía en la marca de tiempo que le entrega el agente. La evidencia de R2 se construye a nivel de sistema operativo (cliente NTP activo en cada agente) y se puede auditar con una política SCA (Security Configuration Assessment) de Wazuh que compruebe que el servicio de sincronización horaria (chronyd/ntpd/Windows Time) está activo — el propio informe SCA sirve como evidencia documental ante el auditor.

R3 — retención en Wazuh Indexer. El backend de Wazuh (Wazuh Indexer, basado en OpenSearch) no borra alertas automáticamente por defecto; sin una política explícita, los índices crecen sin límite o dependen de la rotación manual. Para dejar constancia de un periodo de retención definido, se configura una política ISM (Index State Management):

PUT _plugins/_ism/policies/wazuh_retencion_ens
{
  "policy": {
    "description": "Retencion alertas op.exp.8 - ENS nivel medio",
    "default_state": "hot",
    "states": [
      {
        "name": "hot",
        "actions": [],
        "transitions": [
          { "state_name": "delete", "conditions": { "min_index_age": "395d" } }
        ]
      },
      { "name": "delete", "actions": [{ "delete": {} }] }
    ]
  }
}

Ese "395d" no es un valor mágico del ENS — es un ejemplo; el periodo real debe salir de la política de seguridad de tu organización (ver la FAQ sobre R3 más abajo).

Consultar los campos exigidos para una auditoría. Desde el propio Wazuh Indexer se puede extraer un extracto con los campos que pide op.exp.8 (usuario, fecha/hora, evento, resultado) filtrado por rango de fechas:

GET wazuh-alerts-*/_search
{
  "query": {
    "bool": {
      "filter": [
        { "range": { "@timestamp": { "gte": "now-90d" } } },
        { "term": { "rule.groups": "audit" } }
      ]
    }
  },
  "_source": ["@timestamp", "agent.name", "data.srcuser", "data.audit.exe", "data.audit.success"]
}

Ese tipo de extracto, con rango de fechas acotado y campos concretos, es justo el formato que un auditor pide ver — no el dashboard completo, sino la evidencia puntual de un periodo.

¿Qué alternativas hay a Wazuh para cubrir op.exp.8?

Wazuh no es la única forma de cumplir esta medida. Con honestidad, las alternativas más habituales:

• Graylog: plataforma de gestión de logs (open source con capa enterprise de pago) sobre Elasticsearch/OpenSearch. Cubre bien la captura, búsqueda y retención (R3) con políticas de índice nativas, y tiene un sistema de roles razonable para R4. Le falta, de fábrica, la correlación de amenazas que exige R5 en nivel alto — hay que construirla con "pipelines" propios o combinarla con otra herramienta.
• Stack ELK sin Wazuh (Filebeat/Winlogbeat + Logstash + Elasticsearch + Kibana): máxima flexibilidad, pero cero reglas de auditoría preconstruidas. Hay que decodificar auditd/Sysmon a mano y montar la correlación desde cero — es la misma situación que ya vimos al comparar Wazuh con Splunk para el ENS: ninguna herramienta genérica trae op.exp.8 resuelto de fábrica, pero el punto de partida de trabajo manual es mayor con un ELK "a pelo" que con Wazuh, que ya trae decoders de auditd y Sysmon.
• Reenvío nativo a un colector central (rsyslog/journald en Linux, Windows Event Forwarding con un colector WEC en Windows): es la opción más barata — no añade ninguna pieza de software nueva, solo centraliza lo que el sistema operativo ya genera. Cubre bien R3 y R4 si el colector está bien asegurado, pero no aporta nada de R1 (hay que construir la revisión periódica a mano, sin dashboards) ni de R5 (no hay correlación, solo almacenamiento).
• Splunk: motor de correlación (SPL) de los más maduros del mercado, cubre R5 sin problema técnico. El coste escala con el volumen de datos ingeridos — precisamente el factor que dispara el volumen de logs que exige op.exp.8 — y no trae el mapeo a la medida de fábrica, igual que el resto.

Ninguna opción "cumple op.exp.8" simplemente por instalarse. La diferencia está en cuánto trabajo de configuración falta para llegar del log crudo a los cinco refuerzos, y ahí Wazuh parte con ventaja porque ya trae los decoders de auditd y Sysmon construidos — el resto (NTP, retención ISM, control de acceso, revisión periódica) hay que configurarlo igual con cualquier herramienta de la lista.

¿Qué limitación tiene este enfoque?

Registrar mucho no es lo mismo que registrar bien. Es tentador activar todo lo auditable y dejar que el SIEM acumule terabytes de eventos, pero un histórico enorme sin R1 (nadie lo revisa) ni R3 bien dimensionado (retención indefinida por omisión, no por decisión) no pasa una auditoría real — y además tiene un coste de almacenamiento que crece mes a mes sin que nadie lo haya presupuestado. Antes de activar auditoría exhaustiva en todos los activos, conviene decidir qué eventos son realmente relevantes para op.exp.8, cuánto tiempo se van a retener y quién los va a revisar — en ese orden.

Preguntas frecuentes

¿op.exp.8 aplica en el nivel básico del ENS?

Sí. op.exp.8 (registro de la actividad) es una de las medidas que ya exige el nivel básico del ENS, sin refuerzos adicionales. A partir del nivel medio se le suman R1-R4; el nivel alto añade R5.

¿Qué es la sincronización horaria (R2) y por qué la exige el ENS?

R2 exige que todos los sistemas que generan registros tengan el reloj sincronizado contra una misma fuente, normalmente NTP. Sin eso, reconstruir la secuencia de un incidente que toca varios sistemas es imposible — y esa reconstrucción es justo lo que pide una auditoría.

¿Cuánto tiempo hay que retener los registros de actividad (R3)?

El RD 311/2022 no fija un número universal de meses; exige que el periodo de retención se defina y documente en la política de seguridad, coherente con el nivel de riesgo. Lo que suele fallar en auditoría es no tener ningún periodo definido, no la duración concreta elegida.

¿Qué añade el refuerzo R5 (análisis automático) en el nivel alto?

R5 exige que el registro no se limite a almacenarse a la espera de revisión manual (R1), sino que exista correlación o análisis automatizado que genere alertas ante patrones anómalos — la diferencia entre un archivo de logs y un SIEM en funcionamiento.

---

Artículos relacionados:

• Detectar instalaciones de software en Windows con Wazuh
• Wazuh vs Splunk: ¿cuál cumple mejor el ENS?

---