Appliquer le benchmark CIS Ubuntu — les contrôles qui comptent et ceux que nous sautons

Le benchmark CIS Ubuntu a environ 200 contrôles. Certains durcissent matériellement le système. D'autres allument des dashboards de compliance pleins de jaune sans changer l'économie de l'attaquant. Quelques-uns sont activement contre-productifs sur un hôte Ubuntu moderne où les défauts ont déjà dépassé leur recommandation.

Voici le sous-ensemble pragmatique que nous livrons sur chaque flotte Ubuntu managée — et les contrôles que nous sautons explicitement, avec leur raisonnement.

Le run d'audit

# Auditeur open-source — même set de contrôles que le CIS-CAT payant
sudo bash <(curl -fsSL https://github.com/dev-sec/cis-dil-benchmark/raw/main/inspec.sh) \
  --target=local://
 
# OpenSCAP avec le profil 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

Nous le lançons toutes les 24 heures à travers la flotte et alimentons les deltas dans un dashboard Grafana. Le dashboard est divisé entre « contrôles qui échouent parce qu'ils devraient » et « contrôles qui échouent parce que le benchmark a tort sur cet environnement ».

L'article complet couvre :

• Les contrôles Level 1 que nous appliquons universellement (défauts de firewall, complexité de mot de passe, audit daemon)
• Contrôles Level 2 — lesquels nous appliquons aux hôtes internet-facing uniquement
• Contrôles que nous sautons explicitement et pourquoi (par ex., désactiver tout chargement de modules)
• Profils AppArmor — ceux en mode enforce par défaut
• Configuration auditd — les règles qui font remonter de vraies attaques vs le bruit
• Trade-offs CIS-CAT vs OpenSCAP vs ansible-lockdown

Nous appliquons ce baseline à chaque hôte Ubuntu managé.