Den CIS-Ubuntu-Benchmark anwenden — die Kontrollen, die zählen, und die, die wir überspringen

Der CIS-Ubuntu-Benchmark hat etwa 200 Kontrollen. Einige härten das System materiell. Andere lassen Compliance-Dashboards voller Gelb aufleuchten, ohne die Angreifer-Ökonomie zu ändern. Ein paar sind auf einem modernen Ubuntu-Host, dessen Defaults sie bereits überholt haben, aktiv kontraproduktiv.

Dies ist die pragmatische Teilmenge, die wir auf jeder gemanagten Ubuntu-Flotte ausliefern — und die Kontrollen, die wir explizit überspringen, mit Begründung.

Der Audit-Lauf

# Open-Source-Auditor — selber Kontroll-Satz wie das bezahlte CIS-CAT
sudo bash <(curl -fsSL https://github.com/dev-sec/cis-dil-benchmark/raw/main/inspec.sh) \
  --target=local://
 
# OpenSCAP mit dem SSG-Profil
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

Wir lassen das alle 24 Stunden über die Flotte laufen und füttern die Deltas in ein Grafana-Dashboard. Das Dashboard ist unterteilt in „Kontrollen, die fehlschlagen, weil sie sollten" und „Kontrollen, die fehlschlagen, weil der Benchmark in dieser Umgebung falsch liegt".

Der vollständige Beitrag behandelt:

• Die Level-1-Kontrollen, die wir universell anwenden (Firewall-Defaults, Passwort-Komplexität, Audit-Daemon)
• Level-2-Kontrollen — welche wir nur auf internet-facing Hosts anwenden
• Kontrollen, die wir explizit überspringen, und warum (z. B. das Deaktivieren jeglichen Modul-Ladens)
• AppArmor-Profile — die, die standardmäßig im enforce-Modus sind
• auditd-Konfiguration — die Regeln, die echte Angriffe ans Tageslicht bringen vs Rauschen
• Die CIS-CAT- vs OpenSCAP- vs ansible-lockdown-Trade-offs

Wir wenden dieses Baseline auf jeden gemanagten Ubuntu-Host an.