Der Weg zur NIS-2-Konformität: : Zwischen Phantom-Lücken und Sicherheits-Illusion
Zu NIS-2 stellt die ENISA eine Technical Implementation Guidance in Bezug auf technische und methodische Anforderungen von Maßnahmen zum Management von Cyberrisiken bereit. Bei der Nutzung als Grundlage für eigene Umsetzungen ist allerdings eine gewisse Vorsicht geboten – unser Autor warnt, dass eine reine "Häkchen-Compliance" anhand des vorliegenden Mappings von NIS-2 zu Controls nach ISO 27001 und/oder NIST CSF 2.0 nicht genügt.
Die Umsetzung der europäischen NIS-2-Richtlinie, konkretisiert durch das deutsche Umsetzungsgesetz, stellt Unternehmen und Organisationen vor neue regulatorische Herausforderungen. Betroffene Einrichtungen stehen vor der Pflicht, nicht nur die Mindestanforderungen aus der NIS-2-Richtlinie zu erfüllen, sondern auch Sicherheitsmaßnahmen nach dem aktuellen „Stand der Technik“ einzuführen und einschlägige internationale Normen zu berücksichtigen. Insbesondere für kleine und mittlere Unternehmen (KMU) sowie heterogen strukturierte Unternehmensgruppen erweist sich dieses Vorhaben in der Praxis als organisatorische Mammutaufgabe.
Vor allem im Bereich der Cyber- und Informationssicherheit personell schwach aufgestellte Unternehmen geraten in ein komplexes Dickicht aus gesetzlichen Vorgaben, wie der ISO 27001, dem Framework NIST CSF 2.0 und den begleitenden Dokumenten der EU-Agentur für Cybersicherheit (ENISA). Ein ungeprüftes Vertrauen auf rein tabellarische Konformitätsabgleiche, wie es bei dem offiziellen ENISA-Mapping zwischen der Durchführungsverordnung (EU) 2024/2690, der ISO 27001 „Information technology – Security techniques – Information security management systems – Requirements“ und dem NIST Cybersecurity Framework (CSF) 2.0 der Fall ist, kann geradewegs zu Risikoszenarien und Kontrollverlust führen. Die Verordnung 2024/2690 wurde speziell für digitale Dienste konzipiert, ist jedoch zusammen mit der Technical Implementation Guidance der ENISA (ENISA Guidance) als Best Practice allgemein zu empfehlen.
Wirksamkeitsanalyse der ENISA Guidance
Um die reale Steuerbarkeit und die inhaltliche Belastbarkeit der regulatorischen Vorgaben zu bewerten, wurde im Rahmen eines Design-Science-Research-Ansatzes durch den Autor ein Zielbild entwickelt. Ziel dieses Vorgehens war es, die tatsächliche Wirksamkeit der rund 170-seitigen ENISA Guidance zu ermitteln. Das methodische Fundament der Untersuchung kombinierte eine qualitative Textanalyse mit einer semi-quantitativen Validierung. Ausgangspunkt bildete das offizielle ENISA-Mapping (Version 1.2), welches die Schnittmengen zwischen den regulatorischen Anforderungen und den etablierten Sicherheitsstandards abbildet. Die Ergebnisse dieser systematischen Validierung offenbaren eine eklatante Diskrepanz zwischen der formellen Dokumentenlage und der operativen Realität.
Betrachtet man ausschließlich das offizielle ENISA-Mapping, suggeriert diese Tabelle tiefgreifende Lücken: 24 Controls der ISO 27001 (25,8 %) und 20 Unterkategorien des NIST CSF 2.0 (18,9 %) werden dort als nicht abgedeckt ausgewiesen. Die qualitative Textanalyse der vollständigen ENISA Guidance bricht dieses Bild allerdings vollständig auf: Für beide Konzepte zeigt sich ein tatsächlicher inhaltlicher Gesamtabdeckungsgrad von circa 80 % der vermeintlichen Lücken. Ein Großteil der aus der Tabelle abzuleitenden Fehlstellen wird nämlich im Fließtext der Guidance durch praxisnahe Umsetzungsempfehlungen, Nachweisbeispiele (Examples of Evidence) sowie konkrete Handlungstipps (Tips) explizit angesprochen. So gilt beispielsweise das ISO-Control 6.7 „Remote-Arbeit“ im offiziellen Mapping formell als nicht geregelt – die tatsächliche ENISA Guidance fordert unter anderem in Kapitel 8.1.2 die Vermittlung von IT-Sicherheitswissen zur sicheren Konfiguration von Heimnetzwerkinfrastrukturen. Ähnlich verhält es sich mit zentralen Schutz- und Wiederherstellungsprozessen im NIST-Framework.
Im Umkehrschluss bedeutet dies aber auch, dass einige sicherheitsrelevante Aspekte aus ISO 27001 und NIST CSF 2.0 durch die ENISA Guidance nur partiell oder gar nicht abgedeckt werden. Die beschriebenen Erkenntnisse können in der Praxis zu folgenden zwei Szenarien führen:
Szenario 1: Die Phantom-Lücken-Falle
Aus der geschilderten dokumentarischen Diskrepanz des ENISA-Mappings erwächst die Gefahr, in eine Phantom-Lücken-Falle zu tappen: Wenn Informationssicherheitsverantwortliche das offizielle ENISA-Mapping ungeprüft als strategische Planungsgrundlage heranziehen, entsteht ein intransparentes und verzerrtes Lagebild, weil das Mapping im Vergleich zur ISO 27001 und dem NIST CSF 2.0 Sicherheitslücken suggeriert.
Das kann zu Fehlallokationen in Form von kostspieligen und zeitintensiven Parallelprojekten führen, um vermeintliche Lücken zu schließen, die in Wahrheit durch die ENISA Guidance längst beschrieben sind. Wertvolle Arbeitszeit wird dann gegebenenfalls für das bürokratische Neuerfinden bereits existierender Räder verschwendet.
Szenario 2: Die Sicherheits-Illusion
Das gefährlichere Gegenstück zur Ressourcenverschwendung ist das Szenario der Sicherheits-Illusion. Nutzen Unternehmen das offizielle ENISA-Mapping oder rein regulatorische Anforderungstexte als unreflektierte Checkliste, wiegen sich Verantwortliche womöglich in einer Scheinsicherheit: Sobald die geforderten Kreuze gesetzt und Dokumente formal erstellt sind, wird fälschlicherweise eine robuste Resilienz angenommen.
Unter anderem folgende Punkte werden durch die ENISA Guidance nicht erwähnt, jedoch von der ISO 27001 und dem NIST CSF 2.0 verlangt:
- Mangelnder Schutz im Verarbeitungsprozess: Sowohl in der ISO- als auch in der
NIST-Betrachtung spart die ENISA Guidance den Schutz der Vertraulichkeit,
Integrität und Verfügbarkeit von Daten im aktiven Verarbeitungsprozess (Data in
Use) aus. - Fehlende Software- und Quellcode-Kontrolle: Das für moderne Entwicklungsumgebungen und softwaredefinierte Infrastrukturen essenzielle Control 8.4 „Zugriff auf den Quellcode“ wird in der Guidance nicht erwähnt.
- Defizite in der Sicherheitskultur und Systemintegration: Die Anforderungen an eine sich kontinuierlich verbessernde Sicherheitskultur (KVP) oder einen integrativen Ansatz des Lieferkettenmanagements in die übergeordnete Prozesslandschaft werden durch die Guidance nicht ausdrücklich gefordert.
Werden diese echten Lücken im Zuge einer „Häkchen-Compliance“ ignoriert, entsteht eine reine Scheinkonformität. Diese schützt weder vor tatsächlichen Cyberangriffen, noch hält sie einer rechtlichen Überprüfung im Sinne des deutschen NIS-2-Umsetzungsgesetzes stand. Weil dieses Gesetz den Stand der Technik und die Berücksichtigung internationaler Normen einfordert, drohen dem Management trotz erfüllter ENISA-Checkliste persönliche Haftungsrisiken.
Fazit
Die Wirksamkeitsanalyse des Autors belegt, dass die ENISA Guidance eine fundierte Basis für den Aufbau einer NIS-2-konformen Architektur darstellt. Sie sollte jedoch unter keinen Umständen autark oder rein tabellarisch angewendet werden!
Ein wirksames Sicherheitskonzept erfordert, die ENISA Guidance als anwendungsorientiertes Werkzeug heranzuziehen und gezielt mit den identifizierten Lücken der ISO 27001 und des NIST CSF 2.0 zu harmonisieren.
PS: Über das „National Online Informative References Program“ (OLIR) des NIST stellt der Autor kostenfrei seine eigene Mapping‑Datei (Excel‑Tabelle) der Zuordnung von ISO/IEC 27001:2022‑Controls zu den Kategorien des NIST CSF 2.0 bereit, die Anwendern, die beide Frameworks vergleichen oder integrieren möchten, als Referenz dienen kann.
Möglicherweise interessieren Sie auch die folgenden <kes>-Beiträge: