op.exp.3 (Gestión de la configuración de seguridad) es la medida del Anexo II del Esquema Nacional de Seguridad (RD 311/2022) que obliga a mantener operativa en el tiempo la línea base de configuración segura fijada en op.exp.2 — mediante verificación periódica, control de cambios y reacción documentada ante desviaciones. Aplica desde categoría básica, con refuerzos progresivos R1 (media) y R2-R3 (alta). No es gestión de vulnerabilidades ni inventario de CVEs — eso corresponde a op.exp.4 — sino vigilar que la configuración segura ya establecida no se degrade con el tiempo.
¿Qué exige exactamente op.exp.3?
El punto de partida es op.exp.2: antes de poner un sistema en producción, hay que haberlo configurado con una línea base de seguridad (servicios innecesarios deshabilitados, cuentas por defecto eliminadas, parámetros de hardening aplicados). op.exp.3 entra después: exige que esa configuración siga siendo la que se fijó, no la que ha ido quedando tras meses de cambios, parches y manos distintas tocando el sistema.
En la práctica, op.exp.3 se traduce en tres obligaciones concretas:
- Verificación continua: comprobar periódicamente que la configuración real de cada sistema coincide con la línea base aprobada.
- Control de cambios: cualquier modificación de la configuración de seguridad debe quedar registrada y, en los niveles superiores, autorizada.
- Reacción ante desviaciones: cuando la verificación detecta que algo se ha desviado (un puerto abierto que no debería estarlo, un servicio reactivado), tiene que haber un proceso — no solo una alerta — que lleve a corregirlo.
La aplicación por categoría, según el Anexo II del RD 311/2022:
Básica
op.exp.3 tal cual: verificación y control de la configuración segura de los sistemas.
Media
op.exp.3 + R1: mantenimiento regular, con una periodicidad establecida y documentada para las verificaciones.
Alta
op.exp.3 + R1 + R2 (responsabilidad limitada: quién puede modificar la configuración) + R3 (copias de seguridad de la configuración antes de cada cambio).
Dato concreto: a diferencia de otras medidas op.exp que solo entran a partir de categoría media, el RD 311/2022 amplió op.exp.3 también a la categoría básica. Si tu organización se declaró básica pensando que se libraba de esta medida, no es el caso.
¿Qué evidencia pediría un auditor para op.exp.3?
En una auditoría de certificación (o de renovación) sobre el ENS, op.exp.3 no se acredita con una declaración de intenciones. El auditor va a pedir, como mínimo, tres tipos de evidencia:
- Histórico de verificaciones periódicas: fechas de cada comprobación de la línea base, no solo la más reciente. Un único escaneo no demuestra "gestión", demuestra una foto puntual.
- Porcentaje de cumplimiento contra un benchmark: idealmente frente a un estándar reconocido (CIS Benchmarks, por ejemplo), con la evolución de ese porcentaje en el tiempo.
- Registro de corrección de desviaciones: cuándo se detectó un cambio no autorizado o una configuración que se había desviado, quién lo corrigió, y cuándo. Esta es la evidencia que más se pasa por alto — tener el escaneo no basta si no hay traza de qué se hizo con el resultado.
Sin estos tres elementos, op.exp.3 queda como una medida "implementada" solo de nombre.
¿Qué se puede sacar de Wazuh para op.exp.3?
Wazuh cubre las dos piezas técnicas centrales de op.exp.3 con dos módulos distintos, que conviene no confundir entre sí:
El módulo SCA (Security Configuration Assessment) escanea la configuración de cada agente contra un benchmark — normalmente CIS Benchmarks para el sistema operativo o servicio en cuestión — y devuelve un porcentaje de cumplimiento, con el detalle de qué controles pasan y cuáles fallan. Ejecutado con periodicidad programada, genera exactamente el histórico de verificaciones que pide un auditor:
# ossec.conf — agente, escaneo SCA programado cada 12h
<sca>
enabled="yes"
scan_on_start="yes"
interval="12h"
<policies>
<policy>cis_debian12.yml</policy>
</policies>
</sca>
El módulo FIM (File Integrity Monitoring) cubre la otra mitad: control de cambios y detección de desviaciones. Configurado sobre los ficheros de configuración crítica (/etc/ssh/sshd_config, políticas de firewall, ficheros de servicios expuestos), genera una alerta en el momento en que alguien modifica esa configuración fuera del proceso de cambio establecido — que es, literalmente, lo que exige el control de cambios de op.exp.3.
# ossec.conf — FIM sobre configuración crítica
<syscheck>
<directories check_all="yes" report_changes="yes">/etc/ssh,/etc/firewalld</directories>
</syscheck>En conjunto: SCA aporta la verificación continua y el % de cumplimiento; FIM aporta la detección de cambios no autorizados. Entre los dos queda cubierta la parte técnica de op.exp.3 — la reacción ante la desviación sigue siendo un paso humano.
¿Qué alternativas existen a Wazuh para esta medida?
op.exp.3 no exige una herramienta concreta, solo un resultado. Estas son las alternativas más habituales, con sus diferencias reales:
- OpenSCAP: herramienta open source con el mismo enfoque de compliance scanning que el SCA de Wazuh, basada en el estándar SCAP y perfiles como los de CIS o STIG. La diferencia práctica es operativa: OpenSCAP no trae por defecto la parte de agentes distribuidos, histórico centralizado y alertas en tiempo real que sí tiene Wazuh — hay que orquestar los escaneos (cron, Ansible) y centralizar los informes por tu cuenta.
- Compliance-as-code (Ansible, Chef, Puppet): aquí el enfoque cambia de detección a enforcement. En vez de escanear y alertar sobre una desviación, un playbook de Ansible (o una receta de Chef) puede aplicar la configuración correcta de forma recurrente y revertir automáticamente un cambio no autorizado la siguiente vez que se ejecute. Va un paso más allá que Wazuh o OpenSCAP, a cambio de más trabajo de mantenimiento de las propias recetas/playbooks.
- Qualys / Tenable (CSPM comercial): plataformas de cumplimiento y gestión de postura de seguridad con soporte comercial, dashboards de compliance más pulidos out-of-the-box y cobertura amplia de benchmarks. El coste es de licencia recurrente, normalmente por activo gestionado, frente al coste cerrado o nulo de licencia de Wazuh/OpenSCAP.
La elección real suele depender de si tu organización quiere solo detectar desviaciones (Wazuh SCA, OpenSCAP) o además corregirlas automáticamente (Ansible/Chef/Puppet), y de si prefiere coste cerrado (open source) o soporte comercial con licencia recurrente (Qualys/Tenable).
¿Qué limitación tiene automatizar op.exp.3 con estas herramientas?
Un informe de SCA con 95% de cumplimiento no significa que op.exp.3 esté resuelto. Significa que la herramienta ha detectado que el 5% restante no cumple la línea base — y ese 5% sigue ahí hasta que alguien lo revisa y lo corrige. La parte técnica (escanear, alertar) la resuelve cualquiera de las herramientas anteriores; la parte que realmente cumple la norma — quién revisa ese informe, quién decide si la desviación es aceptable o hay que corregirla, y en qué plazo — es un proceso organizativo que ninguna herramienta ejecuta sola. Wazuh, OpenSCAP y Qualys generan el dato; op.exp.3 exige además la gestión de ese dato.
Artículo relacionado:
Diagnóstico gratuito
¿Necesitas acreditar op.exp.3 y no sabes qué evidencia falta?
Revisamos tu configuración actual, qué controles del Anexo II te faltan y cómo montar la verificación continua con Wazuh u otra herramienta que ya tengas. Sin compromiso.