System Hardening & Security Baselines

Betriebssysteme und Anwendungen werden mit Standardkonfigurationen ausgeliefert, die auf Kompatibilität und Benutzerfreundlichkeit optimiert sind – nicht auf Sicherheit. Windows-Server aktivieren standardmäßig zahlreiche Dienste, die in den meisten Umgebungen nicht benötigt werden. Linux-Systeme kommen mit offenen Ports, unsicheren SSH-Standardkonfigurationen und unnötigen Paketen. Cloud-Ressourcen werden häufig mit öffentlichem Zugang und minimalen Zugriffskontrollen bereitgestellt.

Systemhärtung bezeichnet die systematische Reduktion der Angriffsfläche: Unnötige Dienste werden deaktiviert, unsichere Protokolle abgeschaltet, restriktive Dateisystemberechtigungen gesetzt, Audit-Logging aktiviert und Sicherheitsfeatures aktiviert, die standardmäßig inaktiv sind. Das Ergebnis ist ein System, das nur die für seine Funktion notwendigen Capabilities hat – und damit eine deutlich kleinere Angriffsfläche.

Anerkannte Referenzrahmen strukturieren diese Arbeit: CIS Benchmarks (Center for Internet Security) liefern plattformspezifische, durch die Community validierte Konfigurationsempfehlungen für Windows Server, Linux, macOS, Container und Cloud-Dienste. DISA STIGs (Defense Information Systems Agency Security Technical Implementation Guides) sind die US-Behördenstandards und besonders in regulierten und hochsicherheitsrelevanten Umgebungen relevant. BSI SiSyP adressiert spezifisch deutsche Behördenanforderungen.

Wir beginnen mit einem Hardening-Assessment: Ihre bestehenden Systeme werden gegen einen relevanten CIS Benchmark geprüft und der Compliance-Score ermittelt. Typischerweise erreichen nicht gehärtete Systeme 20-40 % der CIS-Anforderungen; nach unserem Hardening-Projekt sind 80-95 % Zielwert. Das Assessment zeigt gleichzeitig, welche Abweichungen das größte Risiko darstellen und welche für Ihre spezifische Umgebung angepasst werden müssen.

Nicht jede CIS-Empfehlung ist für jede Umgebung direkt anwendbar. Einige Einstellungen, die in einer dedizierten Server-Rolle sinnvoll sind, können in einer anderen zu Funktionsunterbrechungen führen. Wir prüfen jede Empfehlung auf Anwendbarkeit und dokumentieren begründete Ausnahmen – weil blinde CIS-Compliance ohne Verständnis des Kontexts kontraproduktiv ist. Das Ergebnis ist eine umgebungsspezifische Baseline, keine generische Vorlage.

Die Umsetzung erfolgt mit Infrastructure-as-Code-Ansätzen: Ansible Playbooks, PowerShell DSC oder GPOs, die die Hardening-Konfiguration deklarativ beschreiben und reproduzierbar auf alle Systeme anwenden. Das stellt sicher, dass neue Systeme automatisch die Baseline erhalten und keine manuellen Fehler entstehen. Gleichzeitig ist die Konfiguration versioniert, nachvollziehbar und bei Bedarf rückrollbar.

System Hardening ist kein einmaliges Projekt, sondern ein laufender Prozess. Konfigurationen driften: Administratoren ändern Einstellungen für Debugging, Anwendungen erfordern bestimmte Ports, Updates verändern Konfigurationsdefaults, neue Systeme werden ohne Hardening-Prozess bereitgestellt. Ohne kontinuierliche Überwachung verliert die Baseline schnell ihre Wirkung.

Wir implementieren kontinuierliche Compliance-Prüfungen, die Hardening-Drift erkennen und melden. Tools wie OpenSCAP, CIS-CAT oder Microsoft Defender for Cloud überprüfen regelmäßig den Compliance-Score jedes Systems und generieren Reports, die Abweichungen von der definierten Baseline sichtbar machen. Kritische Abweichungen werden automatisch getickt und zur Behebung eskaliert.

Für Cloud-Umgebungen (Azure, AWS, GCP) bieten Cloud Security Posture Management (CSPM) Tools wie Microsoft Defender for Cloud, AWS Security Hub oder GCP Security Command Center kontinuierliches Hardening-Monitoring mit unmittelbaren Alerts bei unsicheren Konfigurationsänderungen. Diese Integration ist besonders wichtig in dynamischen Cloud-Umgebungen, wo Ressourcen per Skript erstellt und Konfigurationen leicht versehentlich geändert werden.

Windows Server und Windows Client stellen unterschiedliche Härtungsanforderungen. Für Windows Server empfehlen CIS Benchmarks die Deaktivierung nicht benötigter Rollen und Features (SMBv1, NetBIOS über TCP/IP, LLMNR, WPAD), restriktive Konfiguration der Windows Defender Firewall, Aktivierung von Audit-Policies mit klar definierten Ereigniskategorien sowie die Durchsetzung starker Credential-Richtlinien kombiniert mit Protected Users und Authentication Policy Silos. Für Windows Clients ist zusätzlich Windows Defender Application Control (WDAC) oder AppLocker relevant – Mechanismen, die die Ausführung nicht autorisierter Software systemseitig blockieren.

Linux-Betriebssystem-Härtung umfasst das System selbst sowie alle installierten Dienste. Kernmaßnahmen: Reduzierung installierter Pakete auf das betriebsnotwendige Minimum, Härtung des SSH-Daemon (PermitRootLogin no, PasswordAuthentication no, AllowTcpForwarding no, MaxAuthTries 3), Konfiguration von Mandatory Access Controls via SELinux (RHEL/CentOS) oder AppArmor (Debian/Ubuntu), Aktivierung von Kernel-Härtungsparametern via sysctl (ASLR aktivieren, core dumps deaktivieren, IP-Forwarding deaktivieren) und Konfiguration der Paketfilter-Firewall via nftables oder firewalld. Für Produktivsysteme empfehlen wir zusätzlich das Aktivieren von auditd für lückenlose Systemaktivitätsprotokollierung.

Cloud-Workloads auf Azure, AWS und GCP erfordern eine eigene Härtungsperspektive: Virtuelle Maschinen erben nicht automatisch die Sicherheitskonfiguration des Cloud-Providers. On-Guest-Betriebssystem-Härtung (CIS Benchmarks für die jeweilige Distribution) ist ebenso erforderlich wie die Konfiguration der Cloud-Ebene: Security Groups, Network ACLs, IMDSv2 (AWS Instance Metadata Service), Azure Policy und CSPM-Integration. Wir kombinieren beide Perspektiven und stellen sicher, dass weder die Betriebssystem-Konfiguration noch die Cloud-Ebene Lücken aufweist.

Betriebssystem-Härtung ist in mehreren regulatorischen Rahmenwerken explizit gefordert. ISO 27001:2022 Annex A.8.9 (Configuration Management) verlangt, dass Konfigurationen von Hardware, Software und Diensten dokumentiert, implementiert, überwacht und regelmäßig überprüft werden. NIS2 Artikel 21 fordert Härtungsmaßnahmen als Teil der technischen Mindestsicherheitsanforderungen für wesentliche und wichtige Einrichtungen. Das BSI IT-Grundschutz-Kompendium enthält plattformspezifische Bausteine – SYS.1.2 (Windows Server), SYS.2.2 (Windows Client) und SYS.1.3 (Linux-Server) – mit detaillierten Härtungsanforderungen.

NIST Special Publication 800-70 definiert das National Checklist Program (NCP) und stellt Härtungs-Checklisten für alle gängigen Betriebssysteme bereit. Die CIS Benchmarks sind als NCP-konform anerkannt und damit in regulierten Umgebungen in Deutschland und Europa gleichermaßen einsetzbar. Für KRITIS-Betreiber ist die Ausrichtung an BSI IT-Grundschutz häufig verpflichtend; CIS Benchmarks können als ergänzende technische Implementierungshilfe eingesetzt werden, ohne den Grundschutz-Nachweis zu untergraben.

Blackfort dokumentiert alle Härtungsmaßnahmen auditgerecht: Für jede Maßnahme enthält das Härtungskonzept den normativen Bezug (CIS Benchmark-ID, BSI-Baustein-Referenz, ISO-Control), den Ist-Zustand vor Härtung, die implementierte Konfiguration und das Verifikationsergebnis nach Umsetzung. Dieses Dokument bildet bei nachfolgenden Audits nach ISO 27001, NIS2 oder BSI IT-Grundschutz die belastbare Grundlage für den Nachweis technischer Schutzmaßnahmen.

Eine erfolgreiche Betriebssystem-Härtung folgt einem strukturierten Ablauf, der Willkür ausschließt und Nachvollziehbarkeit sicherstellt. Wir arbeiten in sechs Phasen – von der initialen Bestandsaufnahme bis zur auditgerechten Abschlussdokumentation, die direkt in nachfolgende ISO-27001- oder NIS2-Prüfungen eingebracht werden kann.

Phase 1 – Systemklassifizierung: Bevor die erste Härtungsmaßnahme beginnt, werden alle Systeme nach Funktion, Kritikalität und Netzwerkexposition klassifiziert. Ein Internet-exponierter Webserver erfordert andere Härtungstiefe als ein isoliertes Backing-System im Intranet. Diese Klassifizierung bestimmt, welcher CIS Benchmark (Level 1 oder Level 2) und welche begründeten Ausnahmen für das jeweilige System vertretbar sind. Phase 2 – Baseline-Assessment: Jedes System wird mit einem automatisierten Compliance-Check (CIS-CAT Pro, OpenSCAP, Microsoft Security Compliance Toolkit) gegen den zutreffenden CIS Benchmark geprüft. Das Ergebnis ist ein quantitativer Compliance-Score: welche Anforderungen sind bereits erfüllt, welche weichen ab. Dieser Ausgangsstatus bildet die belastbare Messbasis für den gesamten Projekterfolg.

Phase 3 – Härtungsplanung und Ausnahmeverwaltung: Auf Basis des Assessments erstellen wir einen priorisierten Härtungsplan. Nicht jede CIS-Empfehlung ist für jede Umgebung direkt anwendbar – Ausnahmen werden schriftlich dokumentiert und fachlich begründet. Das Ergebnis ist ein unternehmensinternes Härtungsprofil, das sowohl technische als auch operative Anforderungen abbildet. Phase 4 – Implementierung mit Infrastructure as Code: Die Härtungsmaßnahmen werden mit Ansible Playbooks, PowerShell DSC oder GPOs implementiert – versioniert, reproduzierbar und in einer Test-Umgebung vorab validiert, bevor sie auf Produktionssysteme ausgerollt werden. Phase 5 – Verifikations-Scan: Nach der Implementierung wird ein erneuter Compliance-Check durchgeführt. Der Vorher-Nachher-Vergleich zeigt die Verbesserung im CIS Compliance Score und dokumentiert, welche Anforderungen umgesetzt wurden. Phase 6 – Auditgerechte Dokumentation: Jede Betriebssystem-Härtungsmaßnahme wird im Härtungskonzept mit normativem Bezug, Ist-Zustand, implementierter Konfiguration und Verifikationsergebnis dokumentiert.

Eine professionelle Betriebssystem-Härtung umfasst typischerweise mehrere Hundert Einzelkonfigurationen – abhängig vom Betriebssystem, der Systemrolle und der gewählten Härtungstiefe. Die folgenden vier Kernbereiche sind in jeder Betriebssystem-Härtung Pflicht und bilden das Fundament jeder Security Baseline.

Diensteverwaltung und Angriffsfläche: Alle nicht betriebsnotwendigen Betriebssystem-Dienste werden deaktiviert. Windows-Server deaktivieren aktiv missbrauchte Protokolle wie SMBv1, NetBIOS über TCP/IP, LLMNR und WPAD. Linux-Systeme werden auf ein minimales Paket-Set reduziert; unnötige Pakete werden entfernt. Offene Netzwerk-Ports werden auf das funktionale Minimum beschränkt und in der Host-Firewall explizit freigegeben. Zugriffskontrollen und Authentifizierung: Standardkonten werden deaktiviert oder umbenannt (Windows: lokaler Administrator, Gast; Linux: direkter Root-Login). Passwort-Policies erzwingen Komplexität und Mindestlänge. SSH-Dienste auf Linux-Systemen werden gezielt gehärtet: root-Login deaktiviert, Passwortauthentifizierung deaktiviert, SSH-Protokollversion und verfügbare Cipher Suites eingeschränkt. Lokale Windows-Administratorkonten werden über LAPS (Local Administrator Password Solution) mit einmaligen Zufallspasswörtern verwaltet.

Kryptographie und Protokollsicherheit: Veraltete und unsichere Protokolle werden systemweit abgeschaltet: TLS 1.0/1.1, SSL 2.0/3.0, RC4, DES, 3DES sowie MD5-basierte Signaturen. Auf Windows-Systemen werden aktivierte Cipher Suites und Protokollversionen via Schannel-Einstellungen oder Group Policy präzise gesteuert. Auf Linux-Systemen werden OpenSSL-Parameter und SSH-Algorithmen explizit konfiguriert. Audit-Logging und Überwachbarkeit: Betriebssystem-Härtung ohne Logging-Konfiguration ist unvollständig. Windows-Systeme erhalten erweiterte Audit-Policies für Anmeldevorgänge, Privilegien-Nutzung, Objektzugriffe und Systemereignisse. Linux-Systeme werden mit auditd konfiguriert, das Datei-Integritätsereignisse, relevante Systemaufrufe und Benutzerkommandos protokolliert. Alle Logs werden an ein zentrales SIEM oder Log-Management weitergeleitet – lokal verbleibende Logs sind im Incident-Fall wertlos.