Gestión de configuración segura: el control que sostiene ISO 27001 y el ENS
En muchas organizaciones ya han invertido en EDR, MFA, parcheado y monitorización. Sin embargo, en auditorías y en análisis post-incidente sigue apareciendo la misma debilidad “silenciosa”: la configuración real de los sistemas no coincide con la configuración aprobada, o no existe una forma fiable de demostrar qué configuración estaba vigente en un momento dado.
Ahí es donde entra la gestión de configuración segura: un control con apariencia técnica, pero con un trasfondo claramente organizativo y de gobernanza. No se trata solo de “endurecer” equipos; se trata de definir, aprobar, desplegar, supervisar y revisar configuraciones de forma que la organización mantenga el control durante todo el ciclo de vida.
Este enfoque está reflejado de forma directa en ISO/IEC 27002 (control 8.9) cuando establece que las configuraciones (incluidas las de seguridad) de hardware, software, servicios y redes deben establecerse, documentarse, aplicarse, supervisarse y revisarse.
Y, en el ámbito público y de operadores vinculados al Esquema Nacional de Seguridad, la idea se materializa con mucha claridad en el tándem OPEX2 + OPEX3: configuración segura antes de entrar en operación y gestión continua de esa configuración en el tiempo.
Veamos cómo encaja todo, qué evidencias son razonables y qué soluciones ayudan a operarlo sin convertirlo en “documentación decorativa”.
1. Cuando “está en marcha no es lo mismo que “está protegido”
La mayoría de sistemas se despliegan con una prioridad legítima: poner el servicio en marcha. El problema es que “arrancar” y “operar” no garantizan que el activo esté dentro de una línea base segura (baseline) ni que la organización pueda sostenerla frente a cambios, parches, nuevos requisitos o desviaciones.
La configuración por defecto suele estar optimizada para facilidad de uso y compatibilidad. En ese escenario aparecen patrones muy repetidos: cuentas preconfiguradas, servicios habilitados por defecto, componentes accesorios, compatibilidades heredadas y permisos amplios para acelerar despliegues. La consecuencia relevante para un auditor no es solo la existencia de un parámetro “débil”, sino algo más estructural: si cada sistema evoluciona de forma distinta, se pierde trazabilidad, y con ella la capacidad de reaccionar con rigor ante una vulnerabilidad o un incidente.
Por eso la gestión de configuración segura no debería plantearse como una acción puntual (“hardening inicial”), sino como un ciclo de vida gobernado: la configuración debe nacer aprobada, mantenerse conforme y poder demostrarse con evidencias objetivas (registros, versiones, validaciones y control de cambios). Esta lógica es coherente con la orientación de ISO 27002 sobre procesos, responsabilidades, plantillas estándar y revisión periódica.
2. Qué pide ISO 27001/27002 cuando habla de gestión de la configuración
En la norma ISO 27001:2022, el control 8.9 “Gestión de la configuración” exige que las configuraciones (incluidas las de seguridad) de hardware, software, servicios y redes se establezcan, documenten, apliquen, supervisen y revisen, con el objetivo de evitar cambios no autorizados o incorrectos.
ISO 27002 (que aporta guía práctica para los controles del Anexo A) aterriza la idea con un enfoque muy reconocible para cualquier auditoría seria:
- Definir plantillas/baselines de configuración segura apoyándose en guías públicas y considerando el nivel de protección requerido.
- Minimizar privilegios, desactivar identidades innecesarias, restringir funciones y servicios no requeridos y cambiar credenciales por defecto.
- Mantener registro de configuraciones y de cambios, almacenado de forma segura.
- Supervisar configuraciones y compararlas contra el objetivo definido (y corregir desviaciones).
- Integrar la disciplina con gestión de activos y automatizar cuando sea posible (por ejemplo, infraestructura como código).
En otras palabras: no es “bastionar una vez”. Es gestionar el ciclo de vida de la configuración: definir la línea base, desplegarla, controlar cambios, verificar desviaciones y revisar periódicamente para que la seguridad se mantenga y sea demostrable.
3. ENS: de la puesta en operación (op.exp.2) a la gestión continua (op.exp.3)
El ENS (Esquema Nacional de Seguridad) el planteamiento es especialmente pedagógico porque separa dos momentos:
OPEX2 (op.exp.2): configurar antes de entrar en operación
OPEX2 exige configurar equipos antes de operar retirando cuentas y contraseñas estándar, aplicando mínima funcionalidad y seguridad por defecto, y extendiendo el enfoque a máquinas virtuales con el mismo rigor que en sistemas físicos.
Este punto es importante desde control y gobernanza: OPEX2 no trata de “preferencias técnicas”, sino de establecer un estado inicial controlado (baseline de arranque) del que luego se deriva todo lo demás.
OPEX3 (op.exp.3): gestión continua de la configuración de seguridad
En este control el ENS da el siguiente paso: no basta con pasar a producción con una configuración adecuada, además es necesario que dicha configuración se mantenga segura de forma continua y constates la configuración garantizando:
- La mínima funcionalidad y mínimo privilegio,
- La adaptación autorizada a nuevas necesidades,
- La reacción ante vulnerabilidades e incidentes,
- y la edición de configuración solo por personal autorizado.
Además, añade refuerzos muy operativos: mantenimiento regular de configuraciones autorizadas, verificaciones periódicas para detectar elementos no autorizados, lista de servicios permitidos, responsabilidad limitada a pocos administradores, backups de configuración, aplicación de actualizaciones y uso de herramientas para conocer el estado de seguridad de la configuración (y corregir).
Aquí se aprecia la diferencia clave: OPEX2 se centra en asegurar la configuración inicial; OPEX3 exige sostenerla en operación mediante gestión continua y verificación.
4. Un modelo operativo razonable: gobernar el ciclo de vida de configuraciones
Si se quiere evitar que la medida se convierta en “papel”, conviene operarla como un ciclo continuo. Un buen punto de partida es el ejecutar el siguiente proceso:
La gestión de configuración segura funciona cuando se opera como un ciclo de vida: se define una configuración objetivo (línea base), se despliega de forma controlada y se verifica continuamente para evitar la deriva. Este enfoque encaja con la lógica de ISO/IEC 27002 (definir–documentar–aplicar–supervisar–revisar) y con ENS, que separa claramente la configuración previa a operación (OPEX2) y la gestión continua (OPEX3).
4.1. Planificación y definición
Objetivo: establecer un marco formal para decidir qué es “configuración segura” en la organización, por tipología de activo y nivel de criticidad, y dejarlo aprobado, versionado y listo para desplegar.
En esta etapa se construye la base de control: sin una línea base aprobada, no existe referencia contra la que medir cumplimiento. Para que sea operable y auditable, conviene estructurar el trabajo en cinco piezas:
a) Alcance y tipologías (qué entra en el control)
- Inventario mínimo de activos incluidos: servidores, endpoints, dispositivos de red, servicios en la nube, workloads (VM/containers), aplicaciones base.
- Segmentación por tipologías: “servidor Windows”, “Linux de aplicación”, “puesto estándar”, “puesto privilegiado”, “firewall”, etc.
- Identificación de “activos críticos” y “configuraciones críticas” (por impacto en disponibilidad, confidencialidad e integridad).
b) Fuentes de referencia (contra qué se diseña la línea base)
- Marco ENS (mínima funcionalidad, seguridad por defecto, credenciales por defecto fuera, etc.).
- ISO 27001/27002 (ciclo de vida y gestión de cambios).
- Guías técnicas: CCN-STIC, CIS Benchmarks, hardening guides del fabricante, y requisitos propios del negocio (teletrabajo, cloud, etc.).
c) Diseño de la línea base (baseline) y criterios de excepción
Una línea base “gobernable” no es una lista infinita de parámetros; es un conjunto de decisiones reproducibles:
- Identidades y privilegios: cuentas por defecto, privilegios locales, separación de roles.
- Superficie de exposición: servicios permitidos, puertos, protocolos, administración remota.
- Configuración de seguridad: firewall local, cifrados, bloqueo de sesión, auditoría/logging, etc.
- Requisitos mínimos para cloud/SaaS (p. ej., MFA, registros, configuración de almacenamiento, redes).
- Excepciones: cuándo se permiten, quién aprueba, qué compensatorias se exigen y caducidad/revisión.
d) Gobernanza: roles, responsables y “puntos de control”
Para sostener OPEX3/ISO de verdad, hay que asignar responsabilidades claras:
- Propietario de baseline.
- Responsable de despliegue.
- Responsable de verificación.
- Comité o flujo de aprobación para cambios relevantes.
e) Entregables y evidencias (lo que queda listo al final de la etapa)
- Catálogo de baselines por tipología, versionado y con fecha.
- Matriz de aplicación: qué baseline aplica a qué activos/perfiles.
- Procedimiento de cambios y excepciones.
- Checklist de puesta en servicio (entrada en operación) alineada con OPEX2.
- Criterios de verificación: cómo se medirá la conformidad (herramienta, periodicidad, umbrales).
Resultado esperado: una organización no “opina” sobre si está segura; tiene un estándar aprobado y un método de medición. Eso es gobernanza.
4.2. Implementación y despliegue
Objetivo: convertir las líneas base aprobadas en construcciones repetibles (no artesanales) y desplegarlas con control de cambios, validación y trazabilidad.
Esta fase es donde la configuración segura se transforma en operación. La clave es que el despliegue sea reproducible y que el resultado sea verificable.
a) Construcciones estándar (cómo se materializa la baseline)
Según tecnología, la línea base se implementa como:
- Imágenes/golden images para servidores y puestos (plantillas de VM, imágenes de endpoint).
- Políticas centralizadas: GPO, MDM/UEM, perfiles de configuración.
- Infraestructura como código (IaC) y plantillas (Terraform/ARM/CloudFormation) para cloud.
- Archivos de configuración para red (routers/switches/firewalls) y hardening scripts.
b) Despliegue controlado (producción no es un laboratorio)
- Despliegue por oleadas: piloto → preproducción → producción.
- Ventanas de cambio y aprobaciones según criticidad.
- Backout plan (capacidad de revertir) cuando el cambio afecte a servicio.
c) Validación rigurosa (la parte que evita incidentes por hardening)
Un despliegue serio exige validación antes de declarar “cumple”:
- Validación funcional: el servicio opera sin degradación no aceptable.
- Validación de seguridad: el baseline se ha aplicado y los controles esperados están activos.
- Validación de compatibilidad: aplicaciones críticas no quedan bloqueadas sin mitigación.
- Evidencia: informe o registro de validación (qué se probó, resultado, aprobador).
d) Trazabilidad y evidencias (lo que un auditor espera encontrar)
- Identificador de baseline aplicada (nombre/versión).
- Activo/ámbito donde se aplicó.
- Fecha y responsable.
- Ticket/cambio asociado (aprobación).
- Resultado de validación y, si aplica, excepciones documentadas.
Resultado esperado: la línea base deja de ser un documento y pasa a ser un estándar aplicado, con pruebas y trazabilidad.
4.3. Seguimiento y actualización
Objetivo: asegurar que las configuraciones reales siguen alineadas con las aprobadas a lo largo del tiempo, gestionando cambios, detectando desviaciones y actualizando baselines ante tecnología y amenazas nuevas.
Aquí se cumple el requisito más importante de gobernanza: mantener el control cuando el entorno cambia. La realidad es que sistemas y servicios evolucionan continuamente (parches, versiones, nuevos módulos, cambios cloud, nuevas políticas). Si no hay seguimiento, aparece la deriva de configuración y se pierde consistencia.
a) Medición de conformidad (estado real vs estado objetivo)
El seguimiento debe basarse en verificación periódica, por ejemplo:
- Escaneos de configuración (por baseline/benchmark).
- Comprobaciones automatizadas de políticas (MDM/GPO/IaC).
- Auditorías internas por muestreo en activos críticos.
- Control de servicios autorizados y detección de cambios no aprobados.
b) Gestión de desviaciones (corregir o justificar, pero siempre registrar)
Cuando se detecta una desviación, se decide:
- Remediación: se reaplica baseline o se corrige el parámetro.
- Excepción: se autoriza temporalmente con compensatorias y revisión.
- Cambio de baseline: si la desviación refleja una necesidad legítima y recurrente, se actualiza la línea base (gobernanza del estándar).
c) Actualización de líneas base (mejora continua)
Las baselines deben revisarse regularmente (p. ej., anual como mínimo) y también cuando haya:
- nuevas versiones de sistemas operativos o plataformas,
- cambios de arquitectura (cloud/híbrido),
- nuevas vulnerabilidades relevantes,
- incidentes que evidencien brechas de configuración,
- cambios regulatorios o requisitos ENS/ISO 27001.
d) Control operativo que sostiene OPEX3
En términos ENS, esta etapa es la que da cumplimiento material a OPEX3:
- mantenimiento de mínima funcionalidad y mínimo privilegio,
- reacción ante vulnerabilidades/incidentes,
- control de quién puede editar configuración,
- verificación periódica y capacidad de corrección.
Resultado esperado: la organización mantiene consistencia, reduce exposición por drift y puede demostrar, en auditoría, que el control no es puntual, sino continuo y medible.
5. Qué pide un auditor: evidencias mínimas (ISO 27001 y ENS)
En un enfoque de control y gobernanza, lo “mínimo defendible” suele incluir:
Política/procedimiento de configuración segura: alcance, roles, periodicidad, gestión de cambios y excepciones.
Baselines aprobadas por tipología de activo (servidor, endpoint, red, cloud), y fuentes utilizadas (CCN-STIC, CIS Benchmarks, guías de fabricante).
Registro de configuración y cambios: qué se aplicó, cuándo, por quién, contra qué plantilla/versión y con qué evidencias.
Evidencia de verificación periódica y tratamiento de desviaciones (tickets, informes de compliance, acciones correctivas).
Control de accesos y segregación: personal autorizado para editar configuración (alineado con OPEX3).
Backups de configuración y capacidad de reconstrucción (ENS R3).
Herramientas que midan el estado de configuración (ENS R5) y/o comparen real vs objetivo.
6. Controles prácticos que sostienen la gobernanza
La configuración segura se concreta en familias de decisiones repetibles. Algunas especialmente habituales:
- Cuentas y credenciales por defecto: eliminación o inutilización de cuentas preconfiguradas y credenciales estándar. (ENS OPEX2 y CIS Control 4 lo enfatizan).
- Mínima funcionalidad: deshabilitar servicios y componentes no necesarios, mantener lista de servicios autorizados (ENS R1) y restringir superficie expuesta.
- Bloqueo de sesión: CIS define umbrales de referencia (p.ej., bloqueo automático en SO de propósito general).
- Gestión segura: administración por protocolos seguros y, cuando aplique, “infraestructura como código” con control de versiones.
- Cloud/SaaS/PaaS/IaaS: aplicar estándares de configuración también en cloud, no solo on-prem.
- Registro y auditoría: habilitar logging con retención acorde, porque muchas desviaciones se detectan tarde si no hay trazas (además de facilitar investigación). (Ejemplificado en políticas tipo y playbooks).
7. Soluciones y herramientas que ayudan a operarlo
Para convertir el control en algo “operable”, normalmente se combinan herramientas por capas:
1) Aplicación centralizada de configuración
- GPO (Active Directory) para Windows y servidores, con diseño por capas y evidencias de aplicación.
- MDM (p. ej., Microsoft Intune u otros) para endpoints móviles/portátiles y cumplimiento continuo.
- Gestión de configuración (Ansible, Puppet, Chef, Salt) para estandarizar y reaplicar estado.
2) Baselines y guías
- CCN-STIC (serie ENS) como referencia prioritaria en entornos ENS (cuando aplique).
- CIS Benchmarks cuando no exista guía CCN aplicable o como refuerzo técnico.
- CIS Controls v8 (Control 4) como marco de buenas prácticas y madurez.
3) Verificación y medición (compliance técnico)
- CIS-CAT o herramientas equivalentes para medir desviaciones frente a benchmark (útil como evidencia de auditoría).
- Escáneres de configuración, posture management (especialmente en cloud) y reportes periódicos.
4) Gobierno de cambios y trazabilidad
- CMDB/ITSM (ServiceNow, GLPI, Jira Service Management, etc.) para vincular activos ↔ baseline ↔ cambios ↔ aprobaciones.
- Repositorios de configuración con control de versiones (Git) cuando se use IaC.
El criterio de selección no debería ser “herramienta de moda”, sino capacidad de evidencia: poder demostrar qué se aprobó, qué se aplicó, qué se verificó y qué se corrigió.
8. Riesgos de no gestionarlo como un control de ciclo de vida
Sin necesidad de dramatizar, cuando la configuración segura se aborda como una acción puntual (y no como un ciclo de vida gobernado), el impacto suele ser directo y medible:
- Mayor tiempo de respuesta ante vulnerabilidades. Si no hay certeza sobre la configuración real y su baseline asociada, la organización dedica esfuerzo a “reconstruir la foto” (inventario, comprobaciones, validaciones) antes de poder corregir con precisión.
- Deriva de configuración (configuration drift). Con el paso del tiempo, parches, cambios urgentes y ajustes locales introducen desviaciones respecto a la configuración aprobada, reduciendo de forma progresiva el nivel de seguridad y la consistencia operativa.
- Complejidad y fricción en auditorías ISO 27001/ENS. La ausencia de trazabilidad (qué baseline aplica, qué versión, qué cambios se autorizaron y qué verificaciones se realizaron) dificulta aportar evidencias objetivas y sostenibles.
- Aumento de la superficie de exposición. Servicios habilitados sin necesidad, puertos abiertos por compatibilidad, cuentas por defecto o privilegios excesivos elevan el riesgo de compromiso, especialmente en los ámbitos más exigidos por OPEX2/OPEX3 y las prácticas alineadas con CIS Control 4.
9. Conclusiones
La gestión de configuración segura no es un “tarea técnica” aislada ni un ejercicio puntual de bastionado. En un marco de control y gobernanza, es el mecanismo que permite a la organización estandarizar, reducir variabilidad, mantener trazabilidad y demostrar cumplimiento de forma sostenible, tanto en ISO 27001/27002 como en el ENS (OPEX2/OPEX3).
Para que aporte valor real (y no se quede en documentación), conviene quedarse con estas ideas clave:
La seguridad empieza en la configuración inicial, pero se gana en el tiempo. OPEX2 fija el estado de partida; OPEX3 exige mantenerlo operativo mediante verificación, control de cambios y reacción ante vulnerabilidades e incidentes.
Sin línea base no hay control. La baseline (por tipología y criticidad) es la “referencia oficial” para decidir si un activo cumple o no, y para corregir desviaciones con criterio.
La evidencia es parte del control. Lo que no se registra (versiones, cambios, validaciones, excepciones) es difícil de sostener en auditoría y, sobre todo, difícil de operar con rigor.
Automatizar no es opcional cuando hay escala. GPO/MDM, IaC y herramientas de verificación reducen el error humano, evitan deriva de configuración y convierten la conformidad en algo medible y repetible.
El éxito se mide por consistencia y capacidad de respuesta. Menos excepciones crónicas, menos desviaciones, remediación más rápida ante vulnerabilidades y auditorías más eficientes son señales claras de madurez.
Si tu organización está avanzando en ISO 27001, en ENS, o en ambos, el paso más rentable suele ser un diagnóstico de configuración segura: inventario y perfiles, revisión de baselines, medición de desviaciones, normalización del control de cambios y un plan de remediación priorizado con evidencias listas para auditoría. Esto transforma la configuración segura en lo que debe ser: un control operativo, gobernado y demostrable.
