Hardening von Geräten und Systemen 2026: sichere Konfiguration, CIS, STIG und Driftkontrolle

Hardening, Patching und Detektion beantworten unterschiedliche Fragen

Hardening ist nicht mit Softwareaktualisierung gleichzusetzen. Ein Update beseitigt eine bekannte Schwachstelle in einer bestimmten Produktversion. Hardening reduziert die Zahl exponierter Funktionen und Missbrauchspfade und erschwert die Ausnutzung bestimmter Fehlkonfigurationen und Schwachstellen. Es bietet jedoch keinen absoluten Schutz und ersetzt weder Schwachstellenmanagement noch EDR, Segmentierung, Datensicherungen oder Monitoring.

Patching beantwortet die Frage, ob bekannte Fehler behoben wurden. Hardening prüft, ob ein System nur die benötigten Funktionen bereitstellt und die vorgesehenen Sicherheitsregeln durchsetzt. Detektion beantwortet die Frage, ob die Organisation Aktivitäten eines Angreifers oder andere reaktionsbedürftige Ereignisse erkennen kann.

Ein Beispiel verdeutlicht den Unterschied. Ein vollständig aktualisierter Server kann weiterhin administrative Anmeldungen aus dem gesamten Netz erlauben, einen ungenutzten Dienst betreiben und ein gemeinsames Konto mit zu weitreichenden Berechtigungen enthalten. Es muss dabei keine CVE geben, die zu patchen wäre, dennoch bleibt die Angriffsfläche unnötig groß. Umgekehrt kann ein sehr sorgfältig konfigurierter, aber ungepatchter Server eine kritische Schwachstelle zur entfernten Codeausführung enthalten. Beide Prozesse sind notwendig.

Hardening sollte auch nicht gegen EDR oder ein SOC ausgespielt werden. Das Einschränken nicht autorisierter Programmausführung, die Trennung administrativer Identitäten und das Abschalten veralteter Protokolle können bestimmte Angreifertechniken erschweren. Monitoring bleibt trotzdem erforderlich, weil sich nicht jede Technik durch Konfiguration verhindern lässt. MITRE ATT&CK v19.2, aktuell seit dem 6. August 2026, ist ein nützlicher Katalog von Angreiferverhalten, aber weder eine Hardening-Checkliste noch ein Wirksamkeitsnachweis für Sicherheitsmaßnahmen.^[8]

Wie eine Baseline ausgewählt wird: CIS Benchmarks

CIS Benchmarks sind konsensbasierte Konfigurationsempfehlungen für zahlreiche Betriebssysteme, Cloud-Plattformen, Datenbanken, Netzwerkgeräte und Containerplattformen.^[1] Die meisten Benchmarks enthalten Profile Level 1 und Level 2. CIS beschreibt Level 1 als grundlegende Empfehlung zur Reduzierung der Angriffsfläche bei möglichst geringer Beeinträchtigung der Nutzbarkeit. Level 2 ist ein strengeres Defense-in-Depth-Profil, das sorgfältigere Tests erfordert und den Betrieb beeinflussen kann.^[2] Daraus folgt weder, dass Level 1 immer produktionssicher ist, noch dass Level 2 immer die bessere Wahl darstellt.

Der Benchmark muss zur konkreten Technologie und Version passen. Die CIS-Bibliothek entwickelt sich auch 2026 schnell weiter. Neue Versionen betrafen beispielsweise Windows Server 2025, Windows Server 2019, Ubuntu 24.04 LTS, Microsoft 365 und Kubernetes.^[1][15] Die Aussage, eine Organisation habe irgendwann CIS umgesetzt, reicht deshalb nicht aus. Im Bericht sollten Benchmark-Version, Profil und Datum der Übernahme in die eigene Baseline angegeben werden.

STIG, NIST, Microsoft und industrielle Umgebungen

DISA Security Technical Implementation Guides sind detaillierte Konfigurationsvorgaben, die für Umgebungen des US-Verteidigungsministeriums entwickelt werden.^[3] Außerhalb dieses Kontexts können sie eine wertvolle technische Referenz sein, werden dadurch aber nicht zu einer polnischen Rechtsvorschrift. Ihr Strengegrad kann für die Funktion eines zivilen Systems zudem unangemessen sein.

NIST SP 800-53 Rev. 5 arbeitet auf einer anderen Ebene. Es handelt sich um einen Katalog von Sicherheits- und Datenschutzkontrollen, in dem das Konfigurationsmanagement die eigene Kontrollfamilie CM bildet.^[4] Für einzelne Produkte werden nicht jeweils fertige Einstellungswerte vorgegeben. Deshalb eignet sich das Dokument eher zum Aufbau von Prozessanforderungen als zur unmittelbaren Konfiguration eines Systems. Das ältere NIST SP 800-123 aus dem Jahr 2008 bleibt ein veröffentlichter Leitfaden zur allgemeinen Serversicherheit, sein Alter muss bei technischen Detailaussagen jedoch berücksichtigt werden.^[5]

In Microsoft-Umgebungen sollte die eigene Baseline zusätzlich mit aktuellen Security Baselines des Herstellers und mit dem modernen Modell für privilegierten Zugriff abgeglichen werden. Microsoft beschreibt 2026 das Enterprise Access Model als Weiterentwicklung des früheren Active-Directory-Tier-Modells für lokale, Cloud- und Hybridumgebungen.^[6] Dies ist eine bessere Referenz als die mechanische Übertragung historischer Tier-Strukturen auf jede Organisation.

Es gibt keinen einzigen Benchmark für eine gesamte Organisation. Für Domänencontroller, Entwicklerarbeitsplatz, Webserver, Switch, Microsoft 365 und industrielle Steuerungen gelten unterschiedliche Baselines. In OT-Umgebungen bietet die IEC-62443-Familie einen Rahmen für die Sicherheit industrieller Automatisierungs- und Steuerungssysteme. Konkrete Maßnahmen müssen jedoch an Architektur, technologischen Prozess und Safety-Anforderungen angepasst werden.^[9]

Was gehärtet wird: Systeme, Identität, Netzwerk und Arbeitsstationen

Betriebssystem

Eine typische Baseline für Server oder Arbeitsstationen umfasst die Minimierung von Diensten und Paketen, den Schutz lokaler Konten, Authentisierungsrichtlinien, Host-Firewall, Protokollierung, kryptographische Einstellungen, Schutzmechanismen für Speicher und Anwendungen sowie Benutzerrechte. Eine Einstellung muss aus der Funktion des Systems abgeleitet werden. Einen Mechanismus nur deshalb zu deaktivieren, weil ein Benchmark dies empfiehlt, ohne Abhängigkeiten der Anwendung zu prüfen, ist kein professionelles Hardening.

Identität und privilegierter Zugriff

In Windows-Umgebungen ist eines der wichtigsten Ziele, Eskalationspfade zu hochprivilegierten Identitäten zu unterbrechen. Dazu gehören die Trennung normaler und administrativer Konten, die Beschränkung der Orte, von denen aus Administration möglich ist, die Kontrolle von Delegationen, der Schutz von Dienstkonten, die Reduzierung gemeinsamer Konten und starke Authentisierung, soweit technisch möglich.

Passwörter lokaler Administratorkonten sollten nicht auf mehreren Geräten identisch sein. Windows LAPS ermöglicht eine zentrale Verwaltung zufälliger, eindeutiger Passwörter solcher Konten und ist damit ein Baustein zur Verringerung des Risikos lateraler Bewegung.^[7] Es ersetzt jedoch weder die Verwaltung sämtlicher privilegierter Konten noch die Kontrolle administrativer Sitzungen. In hybriden Umgebungen sind die Trennung von Steuerungs-, Verwaltungs- und Datenebenen sowie der Schutz administrativer Geräte wichtig.^[6] Je höher das Privileg, desto weniger Orte sollten es empfangen können.

Netzwerk

Zum Hardening von Netzwerkgeräten gehören Administration nur aus definierten Quellen, starke Authentisierung von Administratoren, Abschalten ungenutzter Verwaltungsdienste, verschlüsselte Administrationsprotokolle, Beschränkung des Zugriffs auf Management-Schnittstellen, zentrale Protokollierung und Change Control. Segmentierung und Default-Deny-Regeln können laterale Bewegung deutlich einschränken, setzen jedoch Kenntnis der tatsächlichen Anwendungsflüsse voraus.

Arbeitsstationen

Zu wichtigen Maßnahmen auf Arbeitsstationen gehören Festplattenverschlüsselung, Beschränkung lokaler Administratorrechte, Application Control, sichere Browser- und Office-Konfiguration, Schutz von Anmeldedaten, Host-Firewall und EDR-Richtlinien. Eine Entwicklerarbeitsstation kann andere Ausnahmen benötigen als ein Büroarbeitsplatz. Jede Ausnahme sollte dennoch einen Verantwortlichen, eine Begründung und einen erneuten Prüftermin haben.

Cloud, Container und OT-Umgebungen

Cloud und SaaS

In der Cloud verschiebt sich Hardening von Betriebssystemeinstellungen zu Identitäten, Rollen, Netzen, Logging, Konfiguration verwalteter Dienste, Schlüsseln, Secrets und organisationsweiten Richtlinien. Zu prüfen sind sowohl einzelne Ressourcen als auch die Vererbung von Richtlinien auf Organisations- oder Tenant-Ebene. Aktiviertes MFA behebt weder übermäßige Rollen noch unkontrollierte OAuth-Anwendungen.

Container und Kubernetes

Eine Baseline muss Images, Hosts, Runtime, Orchestrator, Netzwerkrichtlinien, Secrets, Workload-Berechtigungen und CI/CD umfassen. CIS veröffentlicht eigene Benchmarks für Kubernetes und ausgewählte Containerumgebungen.^[1] Ein häufiger Fehler besteht darin, die Sicherheit eines Container-Images mit der Sicherheit des gesamten Clusters gleichzusetzen.

OT und eingebettete Systeme

Eine Baseline für Büroserver darf nicht ohne Wirkungsanalyse auf OT übertragen werden. Prozessverfügbarkeit, Herstellervorgaben, lange Lebenszyklen und begrenzte Wartungsfenster verändern die Art der Umsetzung. Segmentierung, Kontrolle des Fernzugriffs, Beschränkung erlaubter Kommunikation, Monitoring und formales Änderungsmanagement können wichtiger sein als die Durchsetzung einer einzelnen Einstellung.^[9]

Automatisierung und Kontrolle von Konfigurationsdrift

Manuell auf Dutzenden Geräten durchgeführtes Hardening verliert schnell an Konsistenz. Automatisierung kann GPO, Intune, Ansible, Puppet, Chef, Cloud-Mechanismen, Policy-as-Code oder eigene Skripte nutzen. Das konkrete Werkzeug ist weniger wichtig als die Fähigkeit, eine Konfiguration reproduzierbar auszurollen und Abweichungen zu erkennen.

Ein reifer Prozess besitzt mindestens sechs Elemente:

1. eine versionierte Baseline mit Verantwortlichem und dokumentierter Quelle;
2. eine Testumgebung oder Stichprobe, auf der Änderungen vor breitem Rollout geprüft werden;
3. einen automatisierten oder regelmäßigen Mechanismus zur Messung der Konformität;
4. ein formales Ausnahmeregister mit Begründung, Risiko und Datum der Neubewertung;
5. einen Rollback-Plan für den Fall, dass die Konfiguration den Dienst beeinträchtigt;
6. Umsetzungsnachweise: Ergebnisse von Konfigurationsscans, Policy-Exporte, Change-Logs und Gerätestichproben.

"100% CIS-Konformität" sollte kein Selbstzweck sein. Einige Empfehlungen können unpassend sein, andere können durch gleichwertige Kontrollen ersetzt werden. Eine bewusste, dokumentierte Entscheidung ist wertvoller als ein künstlich erhöhter Prozentwert.

Häufige Fehler

1. Einführung eines Benchmarks ohne Tests. Eine Baseline liefert Empfehlungen, kennt aber die Abhängigkeiten einer konkreten Anwendung nicht. Änderungen an TLS, Berechtigungen, Verschlüsselung oder Application-Control-Regeln können Dienste unterbrechen.
2. Fehlende Versionierung. "Wir verwenden CIS Level 1" sagt ohne Produkt, Benchmark-Version, Profil und akzeptierte Ausnahmen wenig aus.
3. Hardening nur auf Servern. Ein Angreifer benötigt unter Umständen nur eine Schwachstelle in Identitäten, einer Administrationsstation, einem Edge-Gerät, der Cloud oder einer Management-Plattform, um einen gut gehärteten Server zu umgehen.
4. Fehlende Drift-Kontrolle. Ohne Vergleich zwischen Ist-Zustand und Baseline weiß die Organisation nicht, ob eine Schutzmaßnahme weiterhin besteht.
5. Jede Abweichung als gleich schwere Schwachstelle behandeln. Eine Abweichung muss im Kontext von Funktion, Exposition und möglicher Auswirkung des Assets bewertet werden.
6. Eine Ausnahme ohne Verantwortlichen. Eine temporäre Abweichung ohne Frist und Risikobeschluss wird zur Dauerkonfiguration.

Woher die Anforderungen kommen

Polnisches Recht schreibt nicht allgemein die Einführung von CIS Benchmarks vor. Es verlangt jedoch Ergebnisse, für die sichere Konfiguration eine geeignete Maßnahme sein kann.

Nach der seit 3. April 2026 geltenden Novelle verlangt das Gesetz über das nationale Cybersicherheitssystem von wesentlichen und wichtigen Einrichtungen angemessene und verhältnismäßige Maßnahmen zum Management von Cybersicherheitsrisiken. Dazu gehören unter anderem Sicherheit bei Beschaffung, Entwicklung und Wartung von Systemen, Schwachstellenmanagement, Zugriffskontrolle, Lieferkettensicherheit, Kryptographie und die Bewertung der Wirksamkeit von Maßnahmen.^[10][11] CIS oder STIG werden nicht als verpflichtendes Profil vorgegeben, was auch für das KSC/NIS2-Audit relevant ist.

Die KRI-Verordnung vom 21. Mai 2024 verpflichtet erfasste Stellen unter anderem zu einem Informationssicherheitsmanagementsystem, aktuellen internen Regelungen, zur Begrenzung von Risiken aus Schwachstellen, zum Berechtigungsmanagement und zum risikoadäquaten Schutz von Systemen.^[12] Hardening ist ein naheliegender Weg zur Unterstützung eines Teils dieser Anforderungen, aber nicht der einzige.

DORA geht für Finanzunternehmen weiter. Die Delegierte Verordnung (EU) 2024/1774 verlangt sichere Konfigurationsbaselines für IKT-Assets, die deren Exposition gegenüber Cyberbedrohungen minimieren, und eine regelmäßige Überprüfung der wirksamen Umsetzung dieser Baselines.^[13] Das ist eine direkte Grundlage für einen Secure-Configuration-Prozess, aber keine Verpflichtung zur Nutzung eines bestimmten Benchmarks.

Art. 32 DSGVO verlangt dem Risiko angemessene Maßnahmen zum Schutz personenbezogener Daten. Er schreibt weder eine Konfigurationscheckliste noch ein Hardening-Profil vor.^[14] Eine Fehlkonfiguration kann zu einer Datenschutzverletzung beitragen, die Auswahl der Maßnahme muss aber weiterhin aus dem Risiko begründet werden.

ISO/IEC 27001:2022 bleibt eine freiwillige Managementsystemnorm, sofern ihre Anwendung nicht vertraglich oder durch einen besonderen Rechtsrahmen vorgeschrieben ist. Ihre Controls umfassen auch Konfigurationsmanagement, doch Konformität mit der Norm bedeutet nicht automatisch Konformität mit jedem Benchmark.^[16]

Wie die Reife eines Hardening-Programms bewertet werden kann

Ein Programm lässt sich mit einfachen Fragen beurteilen:

• Gibt es für jeden wesentlichen Systemtyp eine benannte, versionierte Baseline?
• Ist bekannt, welche Einstellungen bewusst vom externen Benchmark abweichen?
• Erhält ein neues Gerät seine sichere Konfiguration automatisch oder in einem wiederholbaren Prozess?
• Werden Abweichungen nach dem Rollout erkannt und nicht erst im Audit?
• Hat jede Ausnahme einen Verantwortlichen, eine Begründung, ein Risiko und einen Termin zur Neubewertung?
• Werden Änderungen zuerst getestet und gibt es einen sicheren Rollback?
• Ist privilegierter Zugriff von normaler Benutzerarbeit getrennt?
• Umfasst die Baseline Cloud, Netzwerkgeräte und Managementsysteme und nicht nur Betriebssysteme?
• Führt die Organisation nach Benchmark-Updates eine Differenzanalyse durch, statt alle neuen Einstellungen blind auszurollen?
• Fließen Hardening-Ergebnisse in Audit, Risikomanagement und Monitoring ein?

In Audit- und Hardening-Projekten von 4crypto ist es in der Regel sinnvoller, das Ergebnis als Karte von Abweichungen, Risiken, Entscheidungen und Nachweisen darzustellen als als einzigen Prozentwert der CIS-Konformität. So lässt sich eine technische Schwäche von einer bewusst akzeptierten Ausnahme unterscheiden.