# Hardening Strategy: Sicherheit als ganzheitliches Framework

TL;DR / Management Summary Einzellösungen wie Firewalls oder Passwörter reichen nicht aus. Wahre Enterprise-Sicherheit folgt einem anerkannten Framework wie NIST (National Institute of Standards and Technology). In diesem finalen Modul der Security-Serie führen wir alle bisherigen Themen zusammen. Wir mappen unsere technischen Maßnahmen (LUKS, Sudo, Auditd, Snapper) auf die fünf Phasen des NIST-Frameworks: Identify, Protect, Detect, Respond und Recover. Dies ist Ihr Masterplan für eine revisionssichere Infrastruktur.

# 1. Das NIST Cybersecurity Framework (CSF)

Die strategische Einordnung.

Ein Senior Admin denkt in Funktionen, nicht nur in Tools.

# 2. Der Reifegrad-Check (Maturity Model)

Wo steht Ihr Team?

# Stufe 1: Reaktiv

• Manuelle Installationen.
• Passwort-Logins erlaubt.
• Updates nur bei Fehlern.

# Stufe 2: Strukturiert

• Ansible-Playbooks für Standard-Setup (Artikel 109).
• SSH-Keys und Fail2Ban aktiv.
• Regelmäßiges Patching.

# Stufe 3: Enterprise / Compliance

• Zentrale Identitäten (AD/LDAP).
• FIM (AIDE) und IDS (Suricata) integriert.
• Vollständiges Auditing aller administrativen Sitzungen.

# 3. Die ‘Defense in Depth’ Architektur (Mermaid)

Die Schichten der Festung.

graph TD
    A[Public Traffic] --> B[Layer 1: Perimeter Firewall / WAF]
    B --> C[Layer 2: Host Firewall / firewalld]
    C --> D[Layer 3: Protocol Härtung / SSHD]
    D --> E[Layer 4: OS Security / AppArmor / SELinux]
    E --> F[Layer 5: Application User / Least Privilege]
    F --> G[Layer 6: Data Encryption / LUKS]
    H[Detection: Auditd / SIEM] -.->|Monitoring all Layers| B
    H -.-> C
    H -.-> D
    H -.-> E

# 4. Day-2 Operations: Regelmäßige Audits

Sicherheit durch Kontrolle.

Verlassen Sie sich nicht auf das initiale Setup.

1. Monatlich: OpenSCAP Scans gegen CIS-Benchmarks (Artikel 348).
2. Quartalsweise: Pentest der eigenen Frontends (Artikel 347).
3. Jährlich: Überprüfung des Berechtigungskonzepts und Key-Rotation (Artikel 302).

# 5. Troubleshooting & “War Stories”

Wenn Frameworks ignoriert werden.

# Story 1: “Die vergessene Detection”

Symptom: Ein Server wurde kompromittiert, die Hacker luden unbemerkt TB-weise Daten ab. Der Vorfall wurde erst durch die Cloud-Rechnung bemerkt. Ursache: Die Härtung (Protect) war gut, aber es gab kein Outbound-Monitoring (Detect). Lösung: Implementieren Sie Egress-Filterung (Artikel 312) und überwachen Sie die Datenvolumina via sar (Artikel 268).

# Story 2: “Compliance-Burnout”

Symptom: Die IT-Abteilung ist nur noch mit der Pflege von hunderter Security-Regeln beschäftigt und kommt nicht mehr zum eigentlichen Betrieb. Ursache: Zu viele manuelle Prozesse und starres Befolgen von STIG-Regeln ohne Priorisierung. Lösung: Automatisieren Sie! Nutzen Sie die RHEL System Roles (Artikel 109) oder Salt-Formulas, um Härtung als “Hintergrundrauschen” mitlaufen zu lassen.

# 6. Fazit & Empfehlung

• SOP: Erstellen Sie eine Standard Operating Procedure (SOP) für neue Server. Kein System geht live, ohne die 10 Kern-Maßnahmen des CIS-Benchmarks durchlaufen zu haben.
• Balance: Sicherheit darf die Produktivität nicht verhindern. Suchen Sie den Dialog mit den Entwicklern.
• Wahl: SLES und RHEL bieten die besten integrierten Werkzeuge für Enterprise-Compliance. Nutzen Sie sie!

# Anhang: Die 10 Gebote der Linux-Sicherheit

1. Kein Root-Login via SSH.
2. Keine Passwort-Authentifizierung.
3. Immer MFA für Admins.
4. Partitionstrennung für System und Daten.
5. Disk-Encryption (FDE) für alle Datenträger.
6. Firewall: Alles zu, was nicht offen sein muss (Egress inklusive!).
7. Applikations-Isolation via AppArmor/SELinux.
8. Zentrales, verschlüsseltes Logging.
9. Automatisiertes Security-Patching.
10. Regelmäßige Integritäts- und Compliance-Scans.