Aplicar el benchmark CIS Ubuntu — los controles que importan y los que nos saltamos

El benchmark CIS Ubuntu tiene aproximadamente 200 controles. Algunos endurecen materialmente el sistema. Otros disparan dashboards de compliance llenos de amarillo sin cambiar la economía del atacante. Unos pocos son activamente contraproducentes en un host Ubuntu moderno donde los defaults ya los han superado.

Este es el subconjunto pragmático que entregamos en cada flota Ubuntu gestionada — y los controles que nos saltamos explícitamente, con su razonamiento.

El run de auditoría

# Auditor open-source — mismo conjunto de controles que el CIS-CAT de pago
sudo bash <(curl -fsSL https://github.com/dev-sec/cis-dil-benchmark/raw/main/inspec.sh) \
  --target=local://
 
# OpenSCAP con el perfil SSG
sudo apt install ssg-base ssg-debderived
sudo oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
  --results /tmp/cis-results.xml \
  /usr/share/xml/scap/ssg/content/ssg-ubuntu2404-ds.xml

Lo ejecutamos cada 24 horas a través de la flota y alimentamos los deltas en un dashboard de Grafana. El dashboard se divide entre «controles que fallan porque deberían» y «controles que fallan porque el benchmark se equivoca con este entorno».

El artículo completo cubre:

• Los controles de Nivel 1 que aplicamos universalmente (defaults de firewall, complejidad de contraseña, audit daemon)
• Controles de Nivel 2 — cuáles aplicamos solo a hosts expuestos a internet
• Controles que nos saltamos explícitamente y por qué (p. ej., deshabilitar todo carga de módulos)
• Perfiles de AppArmor — los que están en modo enforce por defecto
• Configuración de auditd — las reglas que sacan a la luz ataques reales vs ruido
• Los trade-offs entre CIS-CAT, OpenSCAP y ansible-lockdown

Aplicamos este baseline en cada host Ubuntu gestionado.