Drift de configuración: qué es y cómo mantener sus servidores alineados al baseline

Endurecer una vez no basta: cada cambio aleja otra vez la configuración del estándar.

Muchas organizaciones invierten semanas en llevar sus servidores a un baseline de seguridad, es decir, a una configuración de referencia aprobada, normalmente basada en los CIS Benchmarks. Meses después, una nueva medición muestra que parte de ese trabajo se perdió. Nadie desactivó la seguridad a propósito: simplemente, los servidores siguieron cambiando.

A ese fenómeno se le llama drift de configuración (deriva de configuración). En este artículo explicamos qué es, de dónde viene, qué riesgos trae y cómo controlarlo de forma continua.

Qué es el drift de configuración

El drift es la diferencia que se acumula con el tiempo entre la configuración real de un sistema y su baseline aprobado. Un servidor que el día de la implementación cumplía con la política puede, semanas después, tener un servicio reactivado, una directiva de contraseñas distinta o un protocolo antiguo habilitado de nuevo.

Lo importante es entender que el drift es normal. Los servidores son sistemas vivos: reciben parches, software nuevo y cambios de urgencia. El problema no es que exista, sino no medirlo y no corregirlo.

Causas más comunes

Causa	Cómo genera drift
Instalación de software	El instalador habilita servicios, abre puertos en el firewall local o cambia permisos para que la aplicación funcione
Parches y actualizaciones	Algunas actualizaciones restablecen valores por defecto o agregan configuraciones nuevas que el baseline todavía no contempla
Cambios de emergencia	Durante un incidente se relaja una regla para restablecer el servicio y luego nadie la vuelve a su valor
GPO superpuestas	Varios objetos de directiva de grupo (GPO) aplican valores distintos al mismo parámetro y gana el que tiene mayor precedencia, no necesariamente el correcto
Administradores distintos	Cada persona o proveedor configura “a su manera”, sin un estándar común ni registro de cambios
Servidores fuera del dominio	Equipos en DMZ o grupos de trabajo que no reciben las GPO y se configuran a mano
Restauraciones y plantillas antiguas	Un servidor restaurado desde un respaldo o creado desde una plantilla desactualizada nace ya fuera del baseline

Por qué importa: los riesgos

Riesgo de auditoría

Si su organización declaró cumplir con un estándar (CIS, PCI-DSS, ISO 27001 o una exigencia regulatoria), el auditor no evalúa lo que se configuró el día de la implementación, sino lo que encuentra el día de la revisión. Un informe de cumplimiento antiguo no sirve como evidencia si la configuración actual ya no coincide.

Aumento de la superficie de ataque

Cada parámetro que vuelve a su valor inseguro reabre una vía que el hardening había cerrado: un protocolo de autenticación débil, un servicio innecesario expuesto o una cuenta con más privilegios de los necesarios. El drift deshace, poco a poco, el trabajo de reducción de riesgo.

Pérdida de confianza en los datos

Cuando el equipo no sabe con certeza cómo están configurados sus servidores, cada incidente o auditoría empieza con una investigación manual. Esa incertidumbre consume tiempo que debería dedicarse a mejorar.

Relación con CIS Controls v8.1

Los CIS Controls v8.1 dedican un control completo al tema. El Control 4, Configuración segura de activos empresariales y software, pide establecer y mantener configuraciones seguras en servidores, estaciones, dispositivos de red, equipos móviles y aplicaciones.

La palabra clave es “mantener”. El control no se satisface con un proyecto de hardening puntual: exige un proceso documentado de configuración segura que se revise de forma periódica y cuando haya cambios importantes en la organización. Medir y corregir el drift es la forma práctica de demostrar ese mantenimiento.

Cómo detectar el drift

Medición periódica contra el benchmark

El primer paso es comparar la configuración real con el baseline de forma regular. Dos herramientas habituales:

• Qualys Policy Audit (antes conocido como Policy Compliance) evalúa la configuración de los activos contra políticas basadas en CIS y otros marcos, y permite programar evaluaciones y reportes. Si ya usa el Cloud Agent de Qualys para vulnerabilidades, puede aprovecharlo también para cumplimiento.
• CIS-CAT Pro Assessor, la herramienta del propio CIS, analiza sistemas contra los CIS Benchmarks y genera reportes. Su versión Pro requiere membresía CIS SecureSuite; existe una versión Lite gratuita con cobertura limitada.

La frecuencia depende de la criticidad. Lo razonable es que los servidores críticos se midan con más frecuencia que el resto y que cada medición se compare con la anterior, no solo con el objetivo.

Monitoreo continuo

La medición periódica muestra el drift después de que ocurre. El monitoreo continuo lo detecta cuando ocurre: vigila cambios en parámetros de seguridad, registros de eventos de modificación de GPO y alertas de herramientas de gestión de configuración. La combinación ideal es monitoreo continuo para los sistemas críticos y medición periódica para todo el parque.

Cómo corregirlo y prevenirlo

Detectar sin corregir solo produce reportes. Estas son las palancas principales:

• GPO bien gobernadas. Centralice la configuración de seguridad en pocos GPO, con nombres claros, responsables definidos y sin valores contradictorios. Revise la precedencia y elimine directivas huérfanas.
• Gestión de configuración. Para servidores fuera del dominio o con Linux, use herramientas de configuración declarativa que reapliquen el estado deseado de forma periódica.
• Integración con gestión de cambios. Todo cambio que afecte la configuración de seguridad debe pasar por el proceso de cambios. Los cambios de emergencia deben tener una tarea de cierre que obligue a revisar si se revierten o se convierten en excepción.
• Plantillas actualizadas. Las imágenes y plantillas de servidores nuevos deben nacer alineadas al baseline vigente.
• Excepciones con fecha de revisión. Una desviación aprobada no es drift, siempre que esté documentada, tenga control compensatorio y vuelva a evaluarse.

El enfoque de CalCom Hardening Suite (CHS)

Según la información pública de CalCom, CHS no solo aplica la política de hardening: también vigila cambios no autorizados y vuelve a imponer los valores aprobados para evitar el drift, con análisis de brechas programado. Esto reduce la dependencia de la corrección manual entre una auditoría y la siguiente. En Innova Digital Systems implementamos CHS como parte de ese ciclo de mantenimiento; puede ver cómo lo trabajamos en CalCom Hardening.

Métricas útiles para reportar

Para que la gerencia y los auditores entiendan la situación, conviene reportar pocas métricas, siempre con datos propios del entorno y nunca con cifras de referencia genéricas:

• Porcentaje de cumplimiento del baseline, por rol de servidor y en total, y su tendencia entre mediciones.
• Número de controles que retrocedieron desde la medición anterior (controles que pasaron de “cumple” a “no cumple”).
• Tiempo de corrección: días transcurridos entre la detección de una desviación y su corrección.
• Cobertura de medición: proporción de servidores del inventario que efectivamente se evaluaron.
• Excepciones vigentes y vencidas, con su responsable.
• Desviaciones por causa, cuando se pueda identificar (parche, instalación, cambio de emergencia, GPO), para atacar el origen.

Estas métricas muestran si el control funciona, no solo si se hizo un proyecto.

Checklist para controlar el drift de configuración

• Baseline aprobado y documentado por rol de servidor, con versión del benchmark CIS.
• Inventario completo de servidores, incluidos los que están fuera del dominio.
• Medición programada con Qualys Policy Audit, CIS-CAT u otra herramienta equivalente.
• Frecuencia de medición definida según criticidad.
• Monitoreo continuo de cambios en los sistemas críticos.
• GPO de seguridad consolidados, sin valores contradictorios.
• Cambios de emergencia con tarea de cierre y revisión obligatoria.
• Plantillas e imágenes de servidores alineadas al baseline vigente.
• Excepciones documentadas con control compensatorio y fecha de revisión.
• Reporte periódico con cumplimiento, retrocesos, tiempo de corrección y cobertura.
• Revisión del baseline cuando cambia el benchmark o la infraestructura.

En resumen

El drift de configuración es inevitable en cualquier infraestructura que cambia. Lo que marca la diferencia es tener un baseline claro, medirlo con regularidad, corregir las desviaciones a tiempo y documentar las excepciones. Así es como se cumple de verdad el Control 4 de CIS: no con un proyecto de una vez, sino con un proceso que se sostiene en el tiempo.