CIS Benchmarks y DISA STIG como base de hardening: qué son y cómo aplicarlos de forma selectiva

Qué es

El Center for Internet Security publica los CIS Benchmarks, guías de configuración desarrolladas por consenso que cubren sistemas operativos, plataformas en la nube y aplicaciones, y que se distribuyen desde cisecurity.org. Los benchmarks suelen dividirse en niveles de perfil: un perfil base pensado para ser ampliamente aplicable con un impacto operativo limitado, y un perfil más estricto para entornos que aceptan más renuncias funcionales. Cada organización elige el nivel; no viene fijado de antemano.

Las DISA STIG (Security Technical Implementation Guides) son el equivalente del Departamento de Defensa de EE. UU. y se publican e indexan a través del DoD Cyber Exchange en public.cyber.mil/stigs/. Los hallazgos de las STIG suelen clasificarse por categoría de severidad, y junto a cada comprobación se incluye una guía de corrección, de modo que esta pueda automatizarse o revisarse manualmente.

Ambos son recomendaciones, no leyes: una organización selecciona una línea base y después decide qué comprobaciones concretas se aplican a un host o servicio determinado.

Por qué importa

Un benchmark o una STIG redactados para un servidor de propósito general pueden deshabilitar un ajuste del que depende una aplicación concreta: un cifrado, un modo de autenticación heredado, el comportamiento de una cuenta de servicio. Aplicar todas las recomendaciones de forma incondicional y sin pruebas es una causa frecuente de caídas que parecen no tener relación con «una simple pasada de hardening». Tratar la línea base como una lista de verificación con la que se puntúa, y con excepciones documentadas, mantiene la pista de auditoría fiel a lo que realmente se hizo.

Cómo aplicarlo

• Elige una sola línea base (CIS o STIG, no una mezcla improvisada) por cada rol de host, y registra qué nivel de perfil se eligió y por qué.
• Lee cada comprobación antes de aplicarla en un entorno mixto o heredado; no apliques automáticamente todas las recomendaciones sin revisarlas.
• Para cada comprobación que no se aplique, anota el motivo y quién aprobó la excepción: esta lista es en sí misma un artefacto de auditoría.
• Vuelve a ejecutar la misma línea base tras cada actualización importante del sistema operativo o de la aplicación; tanto las recomendaciones como los valores por defecto cambian con el tiempo.
• Una vez elegida la línea base, prefiere el escaneo automatizado (véase OpenSCAP) a la verificación manual, para que las revisiones sean repetibles.

Trampas

• Aplicar un perfil más estricto a un host que nunca se probó con él y descubrir días después que se rompió una vía de inicio de sesión o una tarea de copia de seguridad.
• Considerar el «100 % de aprobación» como el objetivo, en lugar de que «cada desviación sea una decisión documentada y aprobada».
• Olvidar que los benchmarks y las STIG tienen versiones; escanear con una copia desactualizada oculta comprobaciones que recientemente han pasado a ser relevantes.