Sichere Konfigurationsbaselines für NIS2 und DORA

Die Fehlkonfiguration am Freitagnachmittag, die zum Thema für das Leitungsorgan wurde

Um 16:40 Uhr an einem Freitag genehmigte der Engineering Lead einer Fintech-Plattform eine Firewall-Änderung, die wie eine routinemäßige Anpassung aussah. Eine temporäre Regel wurde geöffnet, um eine Integration mit einem Anbieter für Zahlungsanalysen zu testen. Im Ticket stand: „nach dem Test entfernen“. Der Test war erfolgreich. Die Regel blieb bestehen.

Drei Wochen später fand ein externer Scan eine aus dem Internet erreichbare Administrationsschnittstelle. Der Server war gepatcht. Für normale Benutzer gab es MFA. Der Schwachstellenscanner meldete keine kritische CVE. Das System war dennoch nicht sicher, weil seine Konfiguration vom genehmigten gehärteten Sollzustand der Organisation abwich.

Am Montagmorgen führte der CISO vier Gespräche parallel:

1. Die Aufsichtsbehörde wollte wissen, ob die operative Resilienz beeinträchtigt war.
2. Der Datenschutzbeauftragte wollte wissen, ob personenbezogene Daten offengelegt worden waren.
3. Das Leitungsorgan wollte wissen, warum „temporäre“ Änderungen nicht erkannt wurden.
4. Der interne Auditor für ISO/IEC 27001:2022 wollte Nachweise, dass sichere Baselines definiert, genehmigt, umgesetzt und überwacht wurden.

An diesem Punkt erkennen viele Sicherheitsprogramme eine unbequeme Wahrheit. Sichere Konfiguration ist nicht nur eine technische Härtungscheckliste. Im Jahr 2026 sind sichere Konfigurationsbaselines ein Thema der Governance, der Cyberhygiene, des IKT-Risikomanagements, der Auditnachweise und der Rechenschaftspflicht des Leitungsorgans.

Eine zweite Variante desselben Problems zeigt sich in vielen regulierten Organisationen. Maria, CISO eines wachsenden B2B-Zahlungsdienstleisters, hat kompetente Entwickler, gepatchte Systeme und bewährte Cloud-Sicherheitspraktiken. Eine Prüfung der Umsetzungsreife für NIS2 und DORA weist jedoch eine rote Feststellung aus: fehlende formalisierte sichere Konfigurationsbaselines. Ihr Team weiß, wie Server zu härten sind, aber ein großer Teil dieses Wissens steckt in den Köpfen der Ingenieure, nicht in genehmigten Standards, automatisierten Prüfungen oder Nachweispaketen.

Diese Lücke ist nicht mehr vertretbar. NIS2 verlangt, dass Leitungsorgane Maßnahmen des Cybersicherheitsrisikomanagements genehmigen und überwachen. DORA verlangt ein dokumentiertes Rahmenwerk für das Management von IKT-Risiken und resiliente IKT-Betriebsabläufe. GDPR verlangt geeignete technische und organisatorische Maßnahmen. ISO/IEC 27001:2022 verlangt risikobasierte Kontrollauswahl, Umsetzung, Überwachung, Audit und kontinuierliche Verbesserung.

Sichere Konfigurationsbaselines verbinden all diese Verpflichtungen zu einem praktischen Kontrollsystem: Baseline definieren, Verantwortlichkeiten zuweisen, bei der Bereitstellung durchsetzen, Ausnahmen steuern, Baseline-Abweichungen erkennen, Nachweise erbringen und nach Audits oder Vorfällen verbessern.

Wie es Clarysecs Zenith Blueprint: 30-Schritte-Roadmap für Auditoren in der Phase „Kontrollen in der Praxis“, Schritt 19, Technische Maßnahmen I, formuliert:

„Viele Verstöße entstehen nicht durch Softwarefehler, sondern durch schlechte Konfigurationsentscheidungen. Unveränderte Standardpasswörter, aktivierte unsichere Dienste, unnötig geöffnete Ports oder ohne Begründung dem Internet ausgesetzte Systeme.“

Dieser Satz erklärt, warum sichere Konfigurationsbaselines heute eine zentrale Resilienzkontrolle sind. Sie definieren, was „sicher“ bedeutet, bevor ein Auditor, eine Aufsichtsbehörde, ein Kunde oder ein Angreifer danach fragt.

Was eine sichere Konfigurationsbaseline tatsächlich ist

Eine sichere Konfigurationsbaseline ist der genehmigte, dokumentierte und wiederholbare Satz von Sicherheitseinstellungen für einen Systemtyp. Sie kann für Windows-Server, Linux-Hosts, Netzwerkgeräte, SaaS-Mandanten, Cloud-Speicher, Kubernetes-Cluster, Datenbanken, Firewalls, Endgeräte, Identitätsplattformen, IoT-Geräte und Operational Technology gelten.

Eine belastbare Baseline beantwortet praktische Fragen:

• Welche Dienste sind standardmäßig deaktiviert?
• Welche Ports dürfen extern exponiert werden?
• Welche Authentifizierungs- und MFA-Einstellungen sind verbindlich?
• Welche Protokollierungseinstellungen müssen aktiviert sein?
• Welche Verschlüsselungseinstellungen sind erforderlich?
• Welche Administrationsschnittstellen sind eingeschränkt?
• Welche Cloud-Ressourcen dürfen öffentlich sein, und wessen Genehmigung ist dafür erforderlich?
• Welche Abweichungen erfordern Risikoakzeptanz?
• Wie häufig prüfen wir auf Baseline-Abweichungen?
• Welche Nachweise belegen, dass die Baseline wirksam betrieben wird?

Der häufigste Fehler besteht darin, Baselines als technische Präferenzen und nicht als gesteuerte Kontrollen zu behandeln. Eine Checkliste eines Linux-Administrators, eine Wiki-Seite eines Cloud-Architekten oder eine Firewall-Konvention eines Netzwerkingenieurs können nützlich sein. Auditierbar werden sie jedoch erst, wenn sie genehmigt, Risiken zugeordnet, konsistent angewendet und überwacht werden.

Deshalb ist ISO/IEC 27001:2022 ein besonders hilfreicher Anker. Die Abschnitte 4.1 bis 4.3 verlangen, dass Organisationen interne und externe Themen, interessierte Parteien und den ISMS-Geltungsbereich verstehen, einschließlich gesetzlicher, regulatorischer, vertraglicher und Drittparteienanforderungen. Die Abschnitte 6.1.2 und 6.1.3 verlangen eine Informationssicherheitsrisikobeurteilung, Risikobehandlung, Kontrollauswahl, eine Anwendbarkeitserklärung und Genehmigung durch den Risikoverantwortlichen. Die Abschnitte 8.2 und 8.3 verlangen, dass Risikobeurteilungen und Risikobehandlung in geplanten Abständen oder nach wesentlichen Änderungen wiederholt werden.

Anhang A konkretisiert die technische Erwartung anschließend über A.8.9 Konfigurationsmanagement, unterstützt durch Asset-Inventar, Schwachstellenmanagement, Änderungsmanagement, Protokollierung, Überwachung, Zugriffskontrolle, Kryptografie, Cloud-Nutzung und dokumentierte Betriebsverfahren.

Das Ergebnis ist eine einfache, aber wirksame Governance-Aussage: Wenn Ihre Organisation nicht zeigen kann, was „sicher“ für jeden wesentlichen Systemtyp bedeutet, kann sie Cyberhygiene unter NIS2, IKT-Risikokontrolle unter DORA, Rechenschaftspflicht unter GDPR oder Kontrollwirksamkeit unter ISO/IEC 27001:2022 nicht überzeugend nachweisen.

Warum NIS2, DORA und GDPR Baselines unvermeidbar machen

NIS2, DORA und GDPR verwenden unterschiedliche Begriffe, laufen aber auf dieselbe operative Anforderung hinaus: Systeme müssen sicher konfiguriert, kontinuierlich überwacht und durch verantwortliches Risikomanagement gesteuert werden.

NIS2 Article 20 verlangt von den Leitungsorganen wesentlicher und wichtiger Einrichtungen, Maßnahmen des Cybersicherheitsrisikomanagements zu genehmigen, deren Umsetzung zu überwachen und Cybersicherheitsschulungen zu erhalten. Article 21 verlangt geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen. Sichere Konfigurationsbaselines unterstützen Article 21(2)(a) zu Konzepten für Risikoanalyse und Sicherheit von Informationssystemen, Article 21(2)(e) zur Sicherheit bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen einschließlich Schwachstellenbehandlung, Article 21(2)(f) zu Konzepten und Verfahren zur Bewertung der Wirksamkeit, Article 21(2)(g) zu grundlegender Cyberhygiene und Cybersicherheitsschulung, Article 21(2)(h) zu Kryptografie, Article 21(2)(i) zu Zugriffskontrolle und Asset-Management sowie Article 21(2)(j) zu Multi-Faktor-Authentifizierung und sicherer Kommunikation.

DORA gilt ab dem 17. Januar 2025 und fungiert als sektorspezifisches Regelwerk für die operative Resilienz erfasster Finanzunternehmen. Articles 5 und 6 verlangen Governance und ein dokumentiertes Rahmenwerk für das Management von IKT-Risiken. Article 8 verlangt die Identifizierung von IKT-Assets, Informations-Assets, IKT-gestützten Geschäftsfunktionen und Abhängigkeiten. Article 9 verlangt Schutz- und Präventionsmaßnahmen, einschließlich Sicherheitsleitlinien, Verfahren, Protokollen und Werkzeugen für IKT-Systeme, sicherer Datenübertragung, Zugriffskontrolle, starker Authentifizierung, Schutz kryptografischer Schlüssel, Änderungsmanagement, Patchen und Aktualisierungen. Articles 10 bis 14 erweitern das Modell um Erkennung, Reaktion, Wiederherstellung, Backup, Wiederherstellung aus Backups, Lernen und Kommunikation.

GDPR ergänzt die Datenschutzperspektive. Articles 5 und 32 verlangen Integrität, Vertraulichkeit, Sicherheit der Verarbeitung und Rechenschaftspflicht durch geeignete technische und organisatorische Maßnahmen. Öffentliche Cloud-Buckets, zu weit exponierte Datenbanken, unsichere Standardeinstellungen und übermäßige administrative Zugriffe sind nicht nur Infrastrukturschwächen. Sie können zu Datenschutzversäumnissen beim Schutz personenbezogener Daten werden.

Ein einziges Programm für sichere Konfigurationsbaselines kann alle drei Regime unterstützen, ohne doppelte Nachweisstränge zu erzeugen.

Das Clarysec-Baseline-Modell: Richtlinie, Verfahren und Plattformnachweise

Clarysec behandelt sichere Konfiguration als wiederholbares Kontrollsystem, nicht als einmaliges Härtungsprojekt. Die Baseline muss durch Richtlinien autorisiert, in Verfahren überführt, durch technische Kontrollen umgesetzt und mit Nachweisen belegt werden.

Die Informationssicherheitsleitlinie legt diese Erwartung auf Unternehmensebene fest:

„Die Organisation muss eine Mindest-Kontrollbasislinie pflegen, die aus ISO/IEC 27001 Anhang A abgeleitet und, sofern angemessen, durch Kontrollen aus ISO/IEC 27002, NIST SP 800-53 und COBIT 2019 ergänzt wird.“
Aus Abschnitt „Risikobehandlung und Ausnahmen“, Richtlinienklausel 7.2.1.

Diese Klausel verhindert, dass Konfigurationshärtung zu einer Sammlung persönlicher Präferenzen wird. Sie verankert die Mindest-Kontrollbasislinie in anerkannten Rahmenwerken.

Für Cloud-Umgebungen konkretisiert die Richtlinie zur Nutzung von Cloud-Diensten die Anforderung:

„Alle Cloud-Umgebungen müssen einer dokumentierten Baseline-Konfiguration entsprechen, die vom Cloud-Sicherheitsarchitekten genehmigt wurde.“
Aus Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.3.1.

Die P33 – Richtlinie zur Audit- und Compliance-Überwachung macht die Baseline anschließend zu einer überwachten Kontrolle:

„Automatisierte Werkzeuge müssen eingesetzt werden, um Konfigurationseinhaltung, Schwachstellenmanagement, Patch-Status und privilegierten Zugriff zu überwachen.“
Aus Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.4.1.

Konfiguration ist außerdem untrennbar mit Schwachstellen- und Patch-Management verbunden. Die Richtlinie zum Schwachstellen- und Patch-Management legt fest:

„Die Behebung von Schwachstellen muss mit Baseline-Konfigurationen und Standards zur Systemhärtung abgestimmt sein.“
Aus Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.4.1.

Dieser Punkt ist wesentlich. Ein System kann gepatcht und dennoch unsicher sein, wenn SMBv1 aktiviert ist, Administrationsschnittstellen exponiert sind, Protokollierung deaktiviert ist oder schwache Authentifizierungseinstellungen bestehen bleiben. In Zenith Controls: Leitfaden zur übergreifenden Einhaltung wird Konfigurationsmanagement als präventive Kontrolle zum Schutz von Vertraulichkeit, Integrität und Verfügbarkeit behandelt, mit operativer Fähigkeit in sicherer Konfiguration. Zenith Controls erläutert außerdem die Abhängigkeit zwischen Konfigurationsmanagement und Schwachstellenmanagement:

„Schwachstellenmanagement hängt von bekannten Konfigurationen ab. Ohne definierte Baseline ist es unmöglich sicherzustellen, dass Patches konsistent eingespielt werden.“

Das ist die Nachweislogik, die Auditoren und Aufsichtsbehörden zunehmend erwarten: ein Kontrollsystem, keine isolierten technischen Aufgaben.

Zuordnung von ISO/IEC 27001:2022 A.8.9 zu unterstützenden Kontrollen

ISO/IEC 27001:2022 Anhang A Maßnahme A.8.9 Konfigurationsmanagement ist der Anker, sollte aber nicht als kleines eigenständiges Dokument behandelt werden. Sie hängt von einer breiteren Kontrollfamilie ab.

Diese kontrollübergreifende Beziehung ist der Grund, warum Clarysec empfiehlt, sichere Konfiguration als ISMS-Fähigkeit mit Verantwortlichen, Nachweisen, Kennzahlen und Managementberichterstattung zu steuern.

Eine breitere Zuordnung hilft, dasselbe Baseline-Programm in andere Rahmenwerke zu übertragen.

Eine praktische Baseline-Struktur, die Sie diesen Monat umsetzen können

Der häufigste Fehler besteht darin, vor jeder Durchsetzung zunächst einen perfekten 80-seitigen Härtungsstandard schreiben zu wollen. Beginnen Sie mit einer minimalen, aber auditierbaren Baseline für jede wesentliche Technologiefamilie und entwickeln Sie diese anschließend durch Automatisierung und Überprüfung weiter.

Für eine Cloud-Speicher-Baseline kann die erste Version vorsehen, dass öffentlicher Zugriff standardmäßig deaktiviert ist, Verschlüsselung ruhender Daten aktiviert ist, Zugriffsprotokollierung aktiviert ist, administrativer Zugriff auf genehmigte Gruppen beschränkt ist, MFA für privilegierten Konsolenzugriff erforderlich ist, Versionierung aktiviert ist, wenn Wiederherstellungsanforderungen dies verlangen, Replikation auf genehmigte Regionen beschränkt ist und Änderungen ausschließlich über genehmigte Infrastructure-as-Code-Pipelines erfolgen.

Für eine Windows Server 2022-Baseline zur Unterstützung der Zahlungsabwicklung kann die erste Version vorsehen, dass SMBv1 deaktiviert ist, nicht erforderliche Dienste deaktiviert sind, RDP auf einen gehärteten Jump Host beschränkt ist, die Windows Defender Firewall nach dem Default-Deny-Prinzip aktiviert ist, lokale Administratorkonten kontrolliert werden, Ereignisprotokolle an das SIEM weitergeleitet werden, Endpoint-Schutz aktiviert ist und administrative Änderungen mit genehmigten Tickets verknüpft sind.

Erstellen Sie für jede Baseline ein kleines Nachweispaket:

1. Das genehmigte Baseline-Dokument.
2. Einen Screenshot oder eine exportierte Richtlinie, die die angewendete Konfiguration zeigt.
3. Eine Liste der durch die Baseline abgedeckten Assets.
4. Ein Änderungsticket, das zeigt, wie Aktualisierungen genehmigt werden.
5. Einen Bericht zur Konfigurationseinhaltung oder eine manuelle Überprüfungsaufzeichnung.

Dies passt direkt zu Zenith Blueprint, Phase „Kontrollen in der Praxis“, Schritt 19, in der Clarysec Organisationen empfiehlt, Konfigurationschecklisten für wesentliche Systemtypen festzulegen, Einstellungen bei der Bereitstellung möglichst automatisiert konsistent anzuwenden und bereitgestellte Systeme anschließend regelmäßig zu auditieren. Der Blueprint liefert außerdem eine praktische Auditmethode:

„Wählen Sie einige repräsentative Systeme aus (z. B. einen Server, einen Switch, einen Endbenutzer-PC) und validieren Sie, dass deren Konfiguration Ihrer sicheren Baseline entspricht. Dokumentieren Sie Abweichungen und Abhilfemaßnahmen.“

Für KMU ist dieser repräsentative Stichprobenansatz oft der schnellste Weg von informeller Härtung zu auditbereiten Nachweisen.

Härtungsbeispiele für KMU, die Risiken schnell reduzieren

Sichere Konfiguration ist nicht nur ein Enterprise-Cloud-Thema. KMU erzielen oft die größte Risikoreduzierung durch einige klare Baseline-Regeln.

Die Netzwerksicherheitsrichtlinie – KMU legt fest:

„Nur erforderliche Ports (z. B. HTTPS, VPN) dürfen dem öffentlichen Internet ausgesetzt werden; alle anderen müssen geschlossen oder gefiltert sein.“
Aus Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.1.3.

Sie verlangt außerdem Änderungsdisziplin:

„Alle Änderungen an Netzwerkkonfigurationen (Firewall-Regeln, Switch-ACLs, Routing-Tabellen) müssen einem dokumentierten Änderungsmanagementprozess folgen.“
Aus Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.9.1.

Und sie legt einen Überprüfungszyklus fest:

„Der IT-Support-Dienstleister muss eine jährliche Überprüfung der Firewall-Regeln, der Netzwerkarchitektur und der Wireless-Konfigurationen durchführen.“
Aus Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.6.1.

Endgeräte-Baselines benötigen dieselbe Aufmerksamkeit. Clarysecs Endpoint-Schutz – Richtlinie zum Schutz vor Schadsoftware – KMU legt fest:

„Geräte müssen veraltete Protokolle (z. B. SMBv1), die durch Schadsoftware ausgenutzt werden können, deaktivieren.“
Aus Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.2.1.3.

Für IoT- und OT-Umgebungen bleiben unsichere Standardeinstellungen eine wiederkehrende Exponierung. Die Internet of Things (IoT) / Operational Technology (OT) Security Policy – KMU legt fest:

„Standard- oder hartcodierte Passwörter müssen geändert werden, bevor Geräte aktiviert werden.“
Aus Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.3.2.

Diese Richtlinienklauseln sind keine abstrakten Aussagen. Es handelt sich um Baseline-Anforderungen, die getestet, nachgewiesen und nachverfolgt werden können. Für ein KMU, das sich auf Kunden-Due-Diligence, NIS2-Lieferantenprüfungen, Cyberversicherung oder eine ISO/IEC 27001:2022-Zertifizierung vorbereitet, schaffen sie unmittelbaren Wert.

Ausnahmebehandlung: die Kontrolle, die Reife von Papierarbeit trennt

Jede Baseline wird Ausnahmen haben. Eine Legacy-Anwendung kann ein altes Protokoll benötigen. Eine Lieferanten-Appliance unterstützt möglicherweise nicht die bevorzugte Verschlüsselungseinstellung. Eine temporäre Firewall-Öffnung kann für eine Migration erforderlich sein. Die Frage ist nicht, ob Ausnahmen existieren. Die Frage ist, ob sie gesteuert werden.

Eine ausgereifte Ausnahmenaufzeichnung enthält:

• Die verletzte Baseline-Anforderung.
• Die geschäftliche Begründung.
• Das betroffene Asset und den Verantwortlichen.
• Die Risikobeurteilung.
• Die kompensierenden Kontrollen.
• Die genehmigende Stelle.
• Das Ablaufdatum.
• Die Überwachungsanforderung.
• Den Abhilfeplan.

Hier wirken ISO/IEC 27001:2022-Risikobehandlung und DORA-Verhältnismäßigkeit zusammen. ISO/IEC 27001:2022 verlangt, dass Kontrollentscheidungen durch Risikobeurteilung, Risikobehandlung, die Anwendbarkeitserklärung und Genehmigung durch den Risikoverantwortlichen begründet werden. DORA erlaubt eine verhältnismäßige Umsetzung auf Basis von Größe, Risikoprofil sowie Art, Umfang und Komplexität der Dienstleistungen, erwartet aber weiterhin dokumentierte IKT-Risiko-Governance, Überwachung, Kontinuität, Tests und Sensibilisierung.

Verhältnismäßigkeit ist keine Erlaubnis, Baselines auszulassen. Sie ist die Anforderung, sie intelligent zu skalieren.

Für ein Kleinst- oder kleineres Finanzunternehmen unter einem vereinfachten IKT-Rahmenwerk kann die Baseline knapp sein und durch manuelle Stichproben unterstützt werden. Für ein größeres Finanzunternehmen wird derselbe Bereich wahrscheinlich automatisierte Konfigurationsprüfungen, Einbindung des internen Audits, jährliche Tests und Berichterstattung an das Leitungsorgan erfordern.

Die Änderungsmanagement-Richtlinie erinnert Organisationen außerdem daran, auf Folgendes zu achten:

„Abweichungen von der Baseline-Konfiguration oder Manipulationen nach genehmigten Änderungen“
Aus Abschnitt „Durchsetzung und Einhaltung“, Richtlinienklausel 8.1.2.3.

Diese Formulierung verbindet Änderungskontrolle mit der Erkennung von Baseline-Abweichungen. Eine Änderung kann genehmigt sein und dennoch Risiko erzeugen, wenn der umgesetzte Zustand vom genehmigten Zustand abweicht oder wenn eine temporäre Einstellung nach Schließung des Änderungsfensters bestehen bleibt.

Einen Nachweispfad für viele Compliance-Verpflichtungen aufbauen

Eine sichere Konfigurationsbaseline sollte nicht fünf separate Compliance-Arbeitsstränge erzeugen. Das Modell von Clarysec nutzt einen Nachweispfad, der mehreren Verpflichtungen zugeordnet ist.

Der Schlüssel ist Nachvollziehbarkeit. Zenith Blueprint, Phase Audit, Überprüfung und Verbesserung, Schritt 24, weist Organisationen an, die Anwendbarkeitserklärung zu aktualisieren und mit dem Risikobehandlungsplan gegenzuprüfen. Wenn eine Kontrolle anwendbar ist, benötigen Sie eine Begründung. Diese Begründung sollte mit Risiko, rechtlicher Verpflichtung, vertraglicher Anforderung oder geschäftlichem Bedarf verknüpft sein.

Für sichere Konfiguration sollte der SoA-Eintrag zu A.8.9 auf den Standard für sichere Konfigurationsbaselines, abgedeckte Asset-Kategorien, Baseline-Verantwortliche, Änderungsmanagementverfahren, Überwachungsmethode, Ausnahmeprozess, Überprüfungszyklus und übergreifende Compliance-Verpflichtungen wie NIS2 Article 21, DORA Articles 6, 8 und 9, GDPR Article 32 und Kundenverpflichtungen verweisen.

Wie Auditoren sichere Konfigurationsbaselines prüfen

Sichere Konfiguration ist für Auditoren attraktiv, weil sie nachweisstark ist. Sie kann durch Dokumente, Interviews, Stichproben und technische Prüfung getestet werden.

Die praktischen Fragen sind vorhersehbar:

• Nutzen Sie beim Installieren neuer Server eine Härtungscheckliste?
• Wie verhindern Sie, dass unsichere Dienste wie Telnet auf Routern ausgeführt werden?
• Sind Cloud-Speicherressourcen standardmäßig privat?
• Wer darf eine Abweichung von der Baseline genehmigen?
• Wie erkennen Sie Baseline-Abweichungen nach einer Änderung?
• Können Sie eine aktuelle Konfigurationsüberprüfung vorlegen?
• Können Sie zeigen, dass eine erkannte Abweichung korrigiert wurde?
• Werden Netzwerk- und Cloud-Konfigurationen gesichert und versioniert?
• Sind Rollback-Verfahren dokumentiert und getestet?

Die stärksten Organisationen pflegen ein Baseline-Nachweispaket für jede wesentliche Systemkategorie. Es verkürzt Audits, verbessert Antworten auf Kunden-Due-Diligence und hilft dem Management, die tatsächliche Kontrollleistung zu verstehen.

Baseline-Abweichungen zu einer Cyberhygiene-Kennzahl für das Leitungsorgan machen

Leitungsorgane benötigen nicht jede Firewall-Regel. Sie müssen jedoch wissen, ob sich die Cyberhygiene verbessert oder verschlechtert.

Ein nützliches Dashboard für sichere Konfiguration enthält:

• Anteil der Assets, die einer genehmigten Baseline zugeordnet sind.
• Anteil der Assets, die Baseline-Prüfungen bestehen.
• Anzahl kritischer Baseline-Abweichungen.
• Durchschnittliches Alter offener Abweichungen.
• Anzahl abgelaufener Ausnahmen.
• Anzahl erkannter nicht autorisierter Konfigurationsänderungen.
• Anteil privilegierter Konfigurationsänderungen mit genehmigten Tickets.
• Ausnahmen für öffentliche Cloud-Exponierung.
• Status der Baseline-Überprüfung nach Technologiefamilie.

Diese Kennzahlen unterstützen die Leistungsbewertung nach ISO/IEC 27001:2022, die Managementaufsicht nach NIS2 und die IKT-Risikoberichterstattung nach DORA. Sie lassen sich außerdem natürlich NIST CSF 2.0-Governance-Ergebnissen sowie COBIT 2019-Zielen für Überwachung und Einhaltung zuordnen.

Eine einfache Regel auf Führungsebene hilft: Kein kritisches System wird produktiv gesetzt, ohne Baseline-Nachweise. Dies kann durch Änderungsmanagement, CI/CD-Gates, Cloud-Richtlinienprüfungen, Infrastructure-as-Code-Reviews, MDM-Einhaltung, GPO-Durchsetzung oder Netzwerkkonfigurationsprüfung durchgesetzt werden. Der Reifegrad kann variieren, die Kontrolllogik jedoch nicht.

Das 90-Tage-Playbook für sichere Konfigurationsbaselines

Wenn Sie bei null beginnen, versuchen Sie nicht, jedes Konfigurationsthema gleichzeitig zu lösen. Nutzen Sie einen 90-Tage-Plan.

Tage 1 bis 30: Mindest-Baseline definieren

Identifizieren Sie kritische Asset-Kategorien. Weisen Sie jeder Kategorie einen technischen Verantwortlichen, einen Risikoverantwortlichen und eine genehmigende Stelle zu. Erstellen Sie eine erste Baseline für die Einstellungen, die für Ransomware-Resilienz, Cloud-Exponierung, privilegierten Zugriff, Protokollierung, Verschlüsselung und Datenschutz am relevantesten sind.

Erstellen Sie das Baseline-Register und ordnen Sie es dem ISMS-Geltungsbereich, dem Risikoregister und der Anwendbarkeitserklärung zu. Wenn Sie NIS2 unterliegen, bestimmen Sie, ob Sie eine wesentliche oder wichtige Einrichtung sind oder ob Kunden eine an NIS2 ausgerichtete Cyberhygiene erwarten. Wenn Sie ein Finanzunternehmen unter DORA sind, identifizieren Sie, welche IKT-Assets kritische oder wichtige Funktionen unterstützen. Wenn Sie personenbezogene Daten verarbeiten, ordnen Sie Systeme den GDPR-Verarbeitungstätigkeiten und Datenkategorien zu.

Tage 31 bis 60: Durchsetzen und Nachweise sammeln

Wenden Sie die Baseline auf eine Stichprobe risikobehafteter Systeme an. Nutzen Sie Automatisierung, wo möglich, warten Sie aber nicht auf perfekte Werkzeuge. Exportieren Sie Konfigurationen, erstellen Sie Screenshots, speichern Sie Richtlinieneinstellungen und erfassen Sie Änderungstickets.

Erstellen Sie für jede Ausnahme einen Risikoeintrag mit Ablaufdatum. Erstellen Sie für jede Abweichung ein Abhilfeticket.

Tage 61 bis 90: Überwachen, berichten und verbessern

Führen Sie eine Konfigurationsüberprüfung durch. Ziehen Sie Stichproben aus einem Server, einem Endgerät, einem Netzwerkgerät und einer Cloud-Umgebung. Vergleichen Sie die tatsächlichen Einstellungen mit der genehmigten Baseline. Dokumentieren Sie Abweichungen und Korrekturmaßnahmen.

Berichten Sie die Baseline-Einhaltung an das Management. Aktualisieren Sie die Anwendbarkeitserklärung und den Risikobehandlungsplan. Überführen Sie wiederkehrende Abweichungen in eine Ursachenanalyse. Wenn eine Fehlkonfiguration einen Vorfall verursacht oder dazu beigetragen hat, aktualisieren Sie die relevante Baseline im Rahmen der Lessons Learned.

Damit erhalten Auditoren etwas Prüfbares, Aufsichtsbehörden etwas Verständliches und das Management etwas Steuerbares.

Schlussgedanke: Sichere Konfiguration ist Cyberhygiene mit Nachweis

NIS2 spricht von Maßnahmen des Cybersicherheitsrisikomanagements und grundlegender Cyberhygiene. DORA spricht von IKT-Risiko, Resilienz, Überwachung, Kontinuität und Tests. GDPR spricht von geeigneten Maßnahmen und Rechenschaftspflicht. ISO/IEC 27001:2022 spricht von Risikobehandlung, Kontrollen, dokumentierten Informationen, Leistungsbewertung und kontinuierlicher Verbesserung.

Sichere Konfigurationsbaselines verbinden all dies.

Sie zeigen, dass Systeme nicht mit unsicheren Standardeinstellungen bereitgestellt werden. Sie zeigen, dass Änderungen kontrolliert werden. Sie zeigen, dass Baseline-Abweichungen erkannt werden. Sie zeigen, dass Ausnahmen risikobasiert akzeptiert werden. Sie zeigen, dass Nachweise vorliegen, bevor der Auditor danach fragt.

Vor allem reduzieren sie reales operatives Risiko. Die Firewall-Regel vom Freitagnachmittag, der öffentliche Cloud-Bucket, die vergessene SMBv1-Einstellung, das Standardpasswort eines IoT-Geräts und die nicht protokollierte Administrationskonsole sind keine theoretischen Audit-Feststellungen. Sie sind praktische Fehlerpunkte.

Clarysec hilft Organisationen, diese Fehlerpunkte in kontrollierte, überwachte und auditierbare Baselines zu überführen.

Nächste Schritte

Wenn Ihre Organisation sichere Konfiguration für ISO/IEC 27001:2022, NIS2-Cyberhygiene, DORA-IKT-Risikomanagement, GDPR-Rechenschaftspflicht oder Vertrauensbildung bei Kunden nachweisen muss, beginnen Sie mit dem Toolkit von Clarysec:

• Nutzen Sie Zenith Blueprint: 30-Schritte-Roadmap für Auditoren, um Konfigurationsmanagement in der Phase „Kontrollen in der Praxis“, Schritt 19, umzusetzen und es in der Phase Audit, Überprüfung und Verbesserung, Schritt 24, zu validieren.
• Nutzen Sie Zenith Controls: Leitfaden zur übergreifenden Einhaltung, um Konfigurationsmanagement unterstützenden Kontrollen aus ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST SP 800-53, COBIT 2019 und Auditmethodiken zuzuordnen.
• Nutzen Sie Clarysec-Richtlinien wie die Informationssicherheitsleitlinie, die Richtlinie zur Nutzung von Cloud-Diensten, die P33 – Richtlinie zur Audit- und Compliance-Überwachung, die Richtlinie zum Schwachstellen- und Patch-Management, die Netzwerksicherheitsrichtlinie – KMU, die Endpoint-Schutz – Richtlinie zum Schutz vor Schadsoftware – KMU und die Internet of Things (IoT) / Operational Technology (OT) Security Policy – KMU, um Ihre Baseline-Anforderungen zu definieren, durchzusetzen und nachzuweisen.

Eine sichere Baseline ist nicht nur eine Härtungscheckliste. Sie ist der Nachweis, dass Ihre Organisation weiß, wie ein sicherer Zustand aussieht, ihn konsistent anwendet und ihn nachweisen kann, wenn es darauf ankommt.