# Compliance Mastery: CIS und STIG als Härtungs-Kompass

TL;DR / Management Summary Ein “sicherer Server” ist ohne Standard ein vages Versprechen. In der Enterprise-Welt nutzen wir Benchmarks wie CIS (Center for Internet Security) oder STIG (Security Technical Implementation Guide). Diese Dokumente liefern hunderte konkrete Anweisungen (z.B. “Separate Partition für /var”, “Noexec auf /tmp”). Wer seine Server nach diesen Benchmarks konfiguriert, erfüllt automatisch hohe regulatorische Anforderungen (PCI-DSS, SOC2) und bietet Angreifern kaum noch Angriffsfläche.

# 1. Einführung & Architektur

Das Regelwerk der Profis.

• CIS Benchmarks: Der globale Industrie-Standard. Konsensorientiert und herstellerunabhängig.
• STIGs: Von der US-Verteidigungsbehörde (DISA). Extrem strikt, oft die Basis für militärische oder staatliche Systeme.

# Der Compliance-Workflow (Mermaid)

graph LR
    A[Standard: CIS Level 1] --> B[Scanners: OpenSCAP / Lynis]
    B --> C[Target Host: SLES / Arch]
    C -->|Audit Data| B
    B --> D{Compliance Score}
    D -->|Fail| E[Remediation: Ansible / Bash]
    D -->|Pass| F[Certification / Audit Ready]
    E --> C

# 2. CIS Level 1 vs. Level 2

Wie tief geht die Härtung?

1. Level 1: Basisschutz. Beinhaltet sinnvolle Maßnahmen, die den Betrieb nicht beeinträchtigen (z.B. Password-Policys).
2. Level 2: Hochsicherheit. Kann die Performance einschränken oder Applikations-Inkompatibilitäten verursachen (z.B. Deaktivierung seltener Netzwerk-Protokolle).

# 3. Tools zur Überprüfung

Messen der Konformität.

# Lynis: Der schnelle System-Auditor

Lynis ist das Standard-Tool für einen schnellen “Gesundheitscheck”.

sudo lynis audit system
# Achten Sie auf den 'Hardening Index'.

# OpenSCAP: Der offizielle Auditor

Nutzen Sie die XML-Profile des SCAP Security Guide (Artikel 179):

# Beispiel: Scan gegen CIS Level 2
sudo oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis_level2 ...

# 4. Day-2 Operations: Configuration Drift verhindern

Den Standard halten.

Härtung ist kein Einmal-Event.

• Infrastructure as Code: Nutzen Sie Ansible-Rollen (z.B. ansible-lockdown), um die CIS-Vorgaben bei jedem Lauf neu zu erzwingen.
• Monitoring: Integrieren Sie den Hardening-Index in Ihr Monitoring. Ein plötzlicher Abfall deutet auf unautorisierte Änderungen hin.

# 5. Troubleshooting & “War Stories”

Wenn die Compliance den Dienst bricht.

# Story 1: “Der noexec-Falle”

Symptom: Nach dem Hardening gemäß CIS lässt sich keine Software mehr via dnf oder apt installieren. Ursache: Der Benchmark fordert noexec auf /tmp und /var/tmp. Viele Installer entpacken dort Skripte und versuchen diese auszuführen. Lösung: Mounten Sie /tmp temporär um (mount -o remount,exec /tmp), führen Sie die Installation durch und setzen Sie den Schutz danach wieder aktiv.

# Story 2: “Das verschwundene IPv6”

Symptom: Eine moderne Cloud-Applikation findet keine Peers mehr. Ursache: Ein STIG-konformer Admin hat IPv6 global deaktiviert, da “nicht benötigt”. Die Applikation (z.B. Kubernetes-Komponente) setzte jedoch auf IPv6-Link-Local Kommunikation. Lösung: Härten Sie IPv6 (Artikel 335) statt es komplett zu löschen. Ein Senior Admin weiß: “Sicher konfigurieren” ist besser als “Abschalten”.

# 6. Fazit & Empfehlung

• Standard: Streben Sie immer CIS Level 1 für alle produktiven Server an.
• Wartbarkeit: Nutzen Sie automatisierte Remediation-Skripte. Manuelle Härtung von 100 Parametern führt unweigerlich zu Fehlern.
• Transparenz: Stellen Sie die Audit-Reports dem Management zur Verfügung. Es beweist die Qualität Ihrer Arbeit.

# Anhang: Die Top 5 CIS Maßnahmen