Aplicando o benchmark CIS Ubuntu — os controles que importam e os que pulamos

O benchmark CIS Ubuntu tem mais ou menos 200 controles. Alguns endurecem materialmente o sistema. Outros disparam dashboards de compliance cheios de amarelo sem mudar a economia do atacante. Alguns são ativamente contraproducentes em um host Ubuntu moderno onde os defaults já os ultrapassaram.

Este é o subconjunto pragmático que entregamos em cada frota Ubuntu gerenciada — e os controles que pulamos explicitamente, com o raciocínio.

O run de auditoria

# Auditor open-source — mesmo conjunto de controles que o CIS-CAT pago
sudo bash <(curl -fsSL https://github.com/dev-sec/cis-dil-benchmark/raw/main/inspec.sh) \
  --target=local://
 
# OpenSCAP com o 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

Rodamos isso a cada 24 horas em toda a frota e alimentamos os deltas em um dashboard Grafana. O dashboard é dividido entre «controles que falham porque deveriam» e «controles que falham porque o benchmark está errado sobre este ambiente».

O artigo completo cobre:

• Os controles de Nível 1 que aplicamos universalmente (defaults de firewall, complexidade de senha, audit daemon)
• Controles de Nível 2 — quais aplicamos apenas em hosts expostos à internet
• Controles que pulamos explicitamente e por quê (ex.: desabilitar todo carregamento de módulos)
• Perfis AppArmor — os que estão em modo enforce por padrão
• Configuração do auditd — as regras que trazem à tona ataques reais vs ruído
• Os trade-offs entre CIS-CAT, OpenSCAP e ansible-lockdown

Aplicamos este baseline em cada host Ubuntu gerenciado.