op.mon.1 ENS: Detección de Intrusión — qué exige y cómo cumplirla

op.mon.1 (Detección de intrusión) es la medida del Anexo II del Esquema Nacional de Seguridad (RD 311/2022), dentro de la familia op.mon de monitorización del sistema, que exige tener un mecanismo activo de detección de intrusión — un IDS/IPS basado en firmas y/o análisis de anomalías, a nivel de red y/o host — en las tres categorías (Básica, Media y Alta), con dos refuerzos que se añaden según sube la categoría: R1 (detección basada en reglas, desde Media) y R2 (procedimientos de respuesta formalizados, desde Alta). No basta con "tener un firewall": hace falta un sistema que analice tráfico o comportamiento y genere alertas trazables.

¿Qué exige exactamente op.mon.1 del Anexo II del ENS?

La familia op.mon agrupa las medidas de monitorización del sistema dentro del marco operacional del ENS. op.mon.1 es la primera y exige un mecanismo de detección de intrusión capaz de identificar actividad anómala o maliciosa, ya sea a nivel de red (tráfico), de host (comportamiento en el propio sistema) o ambos. La norma no impone un producto concreto — puede ser firmas conocidas de ataques, análisis de anomalías de comportamiento, o una combinación de ambos.

Lo que sí cambia es el nivel de exigencia según la categoría del sistema:

• Categoría Básica: op.mon.1 a secas — mecanismo de detección de intrusión activo, sin refuerzos adicionales.
• Categoría Media: op.mon.1 + R1 — además de detectar, la detección tiene que apoyarse en reglas (firmas actualizadas, patrones conocidos de ataque), no solo en heurísticas genéricas.
• Categoría Alta: op.mon.1 + R1 + R2 — además de detectar con reglas, la organización tiene que tener procedimientos de respuesta formalizados: qué se hace cuando salta una alerta, quién actúa, en qué plazo, y cómo queda documentado.

En otras palabras: Básica pide "que exista el radar", Media pide "que el radar tenga un catálogo de amenazas actualizado", y Alta pide "que además haya un protocolo escrito de qué hacer cuando el radar suena".

¿Qué evidencia pediría un auditor para dar por cumplida esta medida?

En una auditoría de certificación o de seguimiento del ENS, op.mon.1 no se da por buena con una captura de pantalla del dashboard el día de la visita. Lo que normalmente se pide:

• Configuración documentada del mecanismo de detección: qué producto, dónde está desplegado (red, host o ambos), qué cubre y qué no.
• Evidencia de que las firmas/reglas están actualizadas — no vale un IDS instalado hace dos años con el catálogo de firmas congelado (esto es justo lo que exige R1 en Media/Alta).
• Histórico de alertas reales, no una prueba sintética el día de la auditoría: logs con timestamp, origen, tipo de evento detectado.
• Trazabilidad de la respuesta (obligatorio en Alta por R2): quién revisó cada alerta relevante, qué acción se tomó, en qué plazo. Un procedimiento sin evidencia de que se ha seguido en la práctica no convence a un auditor.
• Retención de logs acorde a lo que exige el ENS para las medidas de monitorización (habitualmente un mínimo de 2 años, según la categoría).

El error más común que vemos en consultoría ENS no es no tener herramienta — es tener un IDS/IPS instalado sin nadie revisando las alertas, lo cual falla exactamente en el punto que un auditor va a mirar primero: la evidencia de que la detección genera una reacción real.

¿Cómo cubre Wazuh op.mon.1, R1 y R2?

Wazuh es una plataforma SIEM/XDR open source que cubre las tres capas de esta medida sin necesidad de sumar productos distintos (más detalle en qué es Wazuh):

• op.mon.1 base: el motor de reglas y decoders de Wazuh analiza logs de red, sistema y aplicaciones en tiempo real y genera alertas ante patrones sospechosos — cubre la detección tanto a nivel de host (vía el agente instalado en cada equipo) como de red (vía syslog de firewalls, IDS externos o Wazuh integrado con Suricata).
• R1 (detección basada en reglas): el ruleset de Wazuh viene con miles de reglas basadas en firmas conocidas — fuerza bruta SSH, escaneos de puertos, escalada de privilegios, persistencia — y se actualiza con el propio producto. Muchas de esas reglas ya vienen mapeadas a técnicas MITRE ATT&CK, lo que facilita justificar ante el auditor que la detección "basada en reglas" no es genérica sino trazable a patrones de ataque documentados.
• R2 (procedimientos de respuesta): aquí es donde Wazuh aporta algo que un IDS pasivo no tiene de serie: Active Response. Cuando una regla de alta severidad se dispara, Wazuh puede ejecutar automáticamente una acción — bloquear la IP de origen, aislar el host — y ese log de ejecución es en sí mismo la evidencia de que existe un procedimiento de respuesta activo, no solo escrito en un documento.

Ejemplo real: una alerta de fuerza bruta por SSH (rule ID 5712 del ruleset por defecto, mapeada a la técnica MITRE ATT&CK T1110 — Brute Force):

{
  "rule": {
    "id": "5712",
    "level": 10,
    "description": "sshd: brute force trying to get access to the system.",
    "mitre": { "id": ["T1110"], "tactic": ["Credential Access"] },
    "groups": ["authentication_failures", "pci_dss_10.2.4", "syslog", "sshd"]
  },
  "agent": { "name": "srv-web-01", "ip": "10.0.4.22" },
  "data": { "srcip": "185.220.101.47" }
}

Y la regla de Active Response que convierte esa alerta en una acción de respuesta ejecutada (evidencia de R2), configurada en ossec.conf:

<active-response>
  <disabled>no</disabled>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>5712</rules_id>
  <timeout>600</timeout>
</active-response>

El log resultante de esa ejecución (IP bloqueada, timestamp, regla que lo disparó) es exactamente el tipo de evidencia que un auditor de categoría Alta pide para R2. Si quieres ver otro ejemplo práctico de cómo una regla concreta de Wazuh se traduce en evidencia de auditoría — en ese caso para detectar instalaciones de software en Windows —, tenemos un caso paso a paso que toca op.mon.1 de pasada.

¿Qué alternativas a Wazuh existen para cubrir op.mon.1?

Wazuh no es la única vía, y ser honestos aquí importa más que vender una única solución:

• Suricata / Snort: NIDS/NIPS dedicados, especializados en análisis de tráfico de red en tiempo real con firmas (reglas ET Open, Emerging Threats). Cubren muy bien la parte de red de op.mon.1 y R1, pero no dan visibilidad de host ni gestión de logs por sí solos — normalmente se integran con un SIEM (Wazuh puede ingerir alertas de Suricata directamente) para tener también R2 y trazabilidad centralizada.
• Microsoft Defender for Endpoint / Sentinel: buena opción si tu organización ya vive en el ecosistema Microsoft 365/Azure. Defender for Endpoint cubre bien la detección de comportamiento a nivel de host (EDR), y Sentinel añade correlación tipo SIEM y respuesta automatizada (playbooks) para R2. El coste es por licencia y crece con el número de endpoints/GB ingeridos, y la curva de aprendizaje de KQL (su lenguaje de consultas) no es trivial para un equipo pequeño.
• Firewall NGFW con IPS integrado (Fortinet, Palo Alto): cubre bien la detección de intrusión a nivel de red en el perímetro, con firmas actualizadas por el fabricante (R1) y capacidad de bloqueo automático (aporta parte de R2 en el perímetro). Es una opción sólida si el punto de entrada principal de riesgo es la red externa, pero no sustituye visibilidad a nivel de host ni correlación de logs de aplicaciones — para eso sigue haciendo falta un SIEM encima.

Ninguna de las tres es "peor" que Wazuh de forma general — depende de qué visibilidad necesitas (red vs. host vs. ambas) y de qué stack ya tienes desplegado. La ventaja práctica de Wazuh para el ENS concretamente es que cubre red + host + correlación + respuesta en una sola plataforma sin licencia recurrente, lo cual simplifica la evidencia que hay que presentar en auditoría porque no está repartida entre tres consolas distintas.

¿Qué limitación tiene un IDS/IPS por sí solo?

Un mecanismo de detección de intrusión mal afinado no cumple mejor la medida por generar más alertas — al contrario. Sin tuning (ajustar umbrales, silenciar falsos positivos conocidos, priorizar por severidad real), un IDS/IPS produce cientos de alertas diarias de bajo valor, y el equipo termina ignorando la consola entera por fatiga de alertas. Eso es un fallo de op.mon.1 en la práctica aunque la herramienta esté técnicamente instalada y actualizada: la norma no pide "tener el producto", pide que la detección funcione y se traduzca en respuesta real. La herramienta es condición necesaria, no suficiente — hace falta alguien revisando y afinando las reglas de forma continua.

Si estás en esta fase de implementación del ENS y quieres que te ayudemos con el mapeo completo de los controles del Anexo II — no solo op.mon.1 — puedes ver cómo lo planteamos en consultoría de adecuación ENS.

Preguntas frecuentes

¿op.mon.1 aplica a todas las categorías del ENS?

Sí, pero con exigencia creciente: Básica pide el mecanismo de detección activo; Media añade R1 (detección basada en reglas); Alta añade además R2 (procedimientos de respuesta formalizados).

¿Qué diferencia hay entre IDS e IPS a efectos del ENS?

Un IDS detecta y alerta; un IPS además puede bloquear automáticamente. op.mon.1 base no exige IPS específicamente, pero en categoría Alta el refuerzo R2 es más fácil de demostrar con una respuesta automatizada tipo IPS o Active Response.

¿Sirve un antivirus como detección de intrusión?

No por sí solo. Un antivirus/EDR cubre malware conocido en el endpoint, pero op.mon.1 pide detección de intrusión de red y/o host basada en firmas y/o anomalías — normalmente hace falta complementarlo con visibilidad de red o un SIEM que correlacione ambas fuentes.

---

Artículo relacionado:

• Detectar instalaciones y desinstalaciones de software en Windows con Wazuh

---