ENS desde dentro (XXI): Gestión de la configuración de seguridad (op.exp.3) — cómo detectar cuando algo cambia sin permiso
Qué exige realmente op.exp.3 del ENS y cómo demostrarlo con evidencias: verificación periódica de la configuración, listado de servicios autorizados y copias de la configuración crítica.
Cómo demostrar, con evidencias, que la configuración de servidores, puestos y elementos de red sigue siendo la autorizada
Un viernes por la tarde, revisando el informe mensual de la herramienta de auditoría de configuración, aparece una alerta: un servidor de archivos tiene activo un servicio que no figura en el listado autorizado. Nadie lo instaló a propósito; probablemente llegó con una actualización o quedó activo tras una prueba puntual. Pero ahí está, y ahora hay que explicar por qué.
Ese es exactamente el escenario que op.exp.2 — Configuración de seguridad no cubre por sí solo. Dejar cada equipo bien configurado el primer día está bien, pero no basta: hay que demostrar que esa configuración sigue siendo la autorizada seis meses después, un año después, y que cualquier desviación se detecta antes de convertirse en un problema. De eso trata op.exp.3 — Gestión de la configuración de seguridad.
Tres frentes de verificación
La responsabilidad de mantener la configuración recae en el Responsable del Sistema, que puede delegar en los administradores designados, pero solo ellos —y siempre con autorización previa— pueden modificarla. La verificación en sí se apoya en tres mecanismos, según el tipo de activo.
Herramientas de auditoría automatizada. En servidores y puestos de trabajo usamos software que compara la configuración actual de hardware y software contra la línea base autorizada, y señala cualquier cambio: un componente nuevo, un servicio que se activó solo, una configuración que se movió. Los informes se revisan periódicamente, no se archivan sin más.
Revisión manual de perímetro. En cortafuegos, routers y proxies —los elementos más expuestos— optamos por una revisión manual planificada. Quien la ejecuta redacta un informe con lo que comprobó y lo que encontró, no una simple casilla marcada.
Calendario de revisión planificada. Para lo que no cubre ninguna herramienta, existe un calendario de revisiones manuales con periodicidad fija, para no depender de que alguien se acuerde.
Una periodicidad que varía según el riesgo
No todos los activos se revisan con la misma frecuencia, porque tampoco están igual de expuestos. Los puestos de usuario se verifican con carácter anual, los servidores cada semestre, y los elementos de perímetro cada dos meses. Son valores ajustables — lo importante no es el número exacto, sino que estén documentados y se cumplan.
Cada revisión comprueba tres cosas: que el hardware sigue siendo el inicial y autorizado, que la configuración de seguridad descrita en el procedimiento sigue vigente, y que los servicios activos coinciden con el listado autorizado para ese tipo de equipo.
El listado de servicios autorizados
Este es el punto donde más trabajo real hay detrás. Mantenemos un anexo con los servicios autorizados para servidores y para puestos de usuario, indicando para cada uno su función, si arranca de forma manual o automática, y con qué cuenta se ejecuta —casi siempre cuentas de sistema o de servicio de red, nunca cuentas de usuario con privilegios innecesarios. En un servidor de dominio típico, esa lista cubre desde los servicios de directorio y resolución de nombres hasta el antivirus corporativo y el agente de protección avanzada frente a amenazas.
Lo que descubrimos al auditar contra ese listado es que el proceso para obtener la lista real de servicios activos en cada máquina era manual: alguien tenía que exportar la configuración a mano y compararla servicio por servicio contra el anexo. Funcionaba, pero no escalaba, y era fácil que quedara desactualizado sin que nadie se diera cuenta.
Copias de la configuración crítica
El tercer pilar es sencillo de enunciar y fácil de olvidar: la configuración de los elementos críticos, sobre todo servidores y elementos de red, se respalda de forma regular. No sirve de nada detectar una desviación si, llegado el momento de reconstruir el sistema tras un incidente, no existe un punto de restauración fiable.
La lección práctica
Si algo me llevo de este control es que el mayor riesgo no está en la herramienta de auditoría, está en el proceso manual que la alimenta. Es fácil tener un listado de servicios autorizados impecable en un documento y, al mismo tiempo, no tener ninguna garantía de que ese documento refleja lo que realmente hay activo en cada máquina.
Mi recomendación: automatiza la extracción del listado de servicios activos siempre que puedas, aunque sea con un script sencillo que genere el informe automáticamente. Cuanto menos dependa la evidencia de que alguien se acuerde de exportarla a mano, más fiable es —y menos trabajo te da a ti cada semestre.
Este post forma parte de la serie "ENS desde dentro", donde comparto cómo se implementan y auditan en la práctica las medidas del Esquema Nacional de Seguridad. Si te está siendo útil, puedes suscribirte a la newsletter para recibir cada entrega, o descargar el checklist "Documentación para una auditoría ENS" con los 8 bloques de evidencia que un auditor va a pedirte.