NIS-2 als Architekturaufgabe (3): Angriffserkennung als betreibbare Architektur: Der Alarm, den niemand liest : SIEM, Logging und Detection Engineering als technische Substanz der NIS-2-Anforderung an Angriffserkennung

Die frühe Erstmeldung an die gemeinsame Meldestelle muss unverzüglich erfolgen, spätestens binnen 24 Stunden. Die Alarmwarteschlange war fünf Wochen im Rückstand. Beide Zahlen stammen aus derselben Organisation, einem Fall aus der Prüfpraxis der Autoren: einem regionalen Energieversorger mit rund 300 Mitarbeitern, 12.000 Ereignissen am Tag und 94 Prozent Fehlalarmen in der Stichprobe einer technischen Prüfung. Die Erkennungsplattform war lizenziert, in Betrieb und im Auditbericht als umgesetzte Maßnahme dokumentiert. Sie lief nur ins Leere.

Ein Angriff wäre in dieser Lage nicht das eigentliche Problem gewesen. Das Problem wäre gewesen, dass ihn wochenlang niemand bemerkt hätte – und dass hinterher niemand hätte sagen können, wann die 24-Stunden-Frist zu laufen begonnen hat.

Bei einer über Wochen nicht bearbeiteten Alarmwarteschlange kann im Nachhinein schwer rekonstruierbar sein, wann die Einrichtung von einem erheblichen Sicherheitsvorfall Kenntnis erlangt hat. Das beseitigt die Meldepflicht nicht; es verschärft vielmehr die Anforderungen an belastbare Detektions-, Eskalations- und Dokumentationsprozesse.

Der Fall ist keine Ausnahme. Er ist in vielen Organisationen die Regel, wenn Angriffserkennung als Beschaffungsthema behandelt wurde: Man führte ein System ein, band Datenquellen an, aktivierte die mitgelieferten Regeln – und ließ den Betrieb laufen. Niemand hat entschieden, was dieses System eigentlich erkennen soll und woran man merkt, wenn es damit aufhört.

Angriffserkennung ist Dimension 2 des Referenzmodells dieser Serie – und die erste Dimension, die zwingend auf ihrer Vorgängerin aufsetzt. Dimension 1, die Asset-Transparenz, war Thema der vorigen Ausgabe: ein vollständiges, dynamisches Inventar über IT, OT und Cloud.

Ohne diese Basis fehlt der Erkennung der Bezugsrahmen – ein Alarm ohne Kontext über Kritikalität, Eigentümer und Netzsegment ist eine Zeile, keine Entscheidungsgrundlage.

Damit verschiebt sich der Maßstab: Gemessen wird nicht die Existenz eines Systems, sondern die Fähigkeit, ein Ereignis technisch zu belegen – was passiert ist, wann, auf welchem System und in welcher Reihenfolge. Logdaten sind das Rohmaterial dieser Evidenz. Sie sind nicht die Evidenz selbst.

Was NIS-2 unter Erkennung versteht

Art. 21 Abs. 2 lit. b der NIS-2-Richtlinie verlangt Maßnahmen zur Bewältigung von Sicherheitsvorfällen. Eine bestimmte Detektionstechnologie schreibt die Richtlinie nicht vor. Je nach Risikoexposition kann die Fähigkeit, Sicherheitsereignisse rechtzeitig zu erkennen, zu bewerten und zu eskalieren, jedoch erforderlich sein, um diese Pflicht wirksam zu erfüllen. Technisch ist die Reihenfolge ohnehin eindeutig: Ein Vorfall, der nicht erkannt wird, wird nicht bewältigt, nicht bewertet und nicht gemeldet.

§ 30 BSI-Gesetz (BSIG) verpflichtet besonders wichtige und wichtige Einrichtungen, geeignete, verhältnismäßige und wirksame technische und organisatorische Risikomanagementmaßnahmen zu ergreifen und deren Einhaltung zu dokumentieren. Abs. 2 nennt dafür Mindestbereiche, darunter die Bewältigung von Sicherheitsvorfällen (Nr. 2) und Verfahren zur Bewertung der Wirksamkeit der Maßnahmen (Nr. 6).

Für Betreiber kritischer Anlagen enthält § 31 Abs. 2 BSIG eine weitergehende Spezialpflicht: Für die informationstechnischen Systeme, Komponenten und Prozesse, die für die Funktionsfähigkeit der kritischen Anlage maßgeblich sind, müssen Systeme zur Angriffserkennung (SzA) eingesetzt werden, die geeignete Parameter und Merkmale aus dem laufenden Betrieb kontinuierlich und automatisch erfassen und auswerten. Der Umfang der Pflicht hängt damit von der Einordnung der Einrichtung ab – die technische Logik dahinter nicht: Wer erkennen will, braucht dieselben Schichten, unabhängig davon, in welche Kategorie er fällt.

Wichtig ist dabei, was dort nicht steht. Verlangt werden Systeme zur Angriffserkennung, keine bestimmte Produktkategorie. Ein Security Information and Event Management (SIEM) ist eine mögliche Plattform, um diese Fähigkeit zu bündeln – die Anforderung selbst ist es nicht. Die Fähigkeit setzt sich aus vier Bestandteilen zusammen: Telemetrie aus den relevanten Systemen, Kontext über das, was diese Systeme sind, Regeln, die auffälliges Verhalten beschreiben, und ein Betrieb, der die Ergebnisse bearbeitet.

Wer diese vier mit Endpunkt-Sensorik, Netzwerkanalyse und einer schlanken Auswertungsschicht abdeckt, verfügt über die Fähigkeit. Wer eine große Plattform betreibt und einen der vier auslässt, verfügt nicht darüber. Ob damit auch die gesetzlichen Anforderungen erfüllt sind, ist eine zweite Frage: Sie hängt vom Anwendungsbereich, der Risikoexposition und der Angemessenheit der konkret getroffenen Maßnahmen ab.

Seine eigentliche Schärfe entfaltet der Anforderungsrahmen an anderer Stelle, nämlich bei den Meldepflichten. § 32 Abs. 1 BSIG staffelt sie für besonders wichtige und wichtige Einrichtungen in vier Stufen:

• Erstmeldung: unverzüglich, spätestens 24 Stunden nach Kenntniserlangung von einem erheblichen Sicherheitsvorfall (§ 32 Abs. 1 Nr. 1 BSIG)
• Folgemeldung: binnen 72 Stunden (§ 32 Abs. 1 Nr. 2 BSIG)
• Zwischenmeldung: auf Ersuchen des Bundesamts für Sicherheit in der Informationstechnik (BSI) über den aktuellen Status (§ 32 Abs. 1 Nr. 3 BSIG)
• Abschlussmeldung: spätestens einen Monat nach Übermittlung der Meldung nach Nr. 2 (§ 32 Abs. 1 Nr. 4 BSIG)

Dauert der Sicherheitsvorfall zum Zeitpunkt der fälligen Abschlussmeldung noch an, tritt zunächst eine Fortschrittsmeldung an deren Stelle (§ 32 Abs. 2 BSIG); die Abschlussmeldung folgt
nach abschließender Bearbeitung. Betreiber kritischer Anlagen übermitteln außerdem Angaben zur Art der betroffenen Anlage, zur betroffenen kritischen Dienstleistung und zu den Auswirkungen des Vorfalls auf diese Dienstleistung (§ 32 Abs. 3 BSIG).

Erst- und Folgemeldung knüpfen an die Kenntniserlangung eines erheblichen Sicherheitsvorfalls an, nicht an sein Eintreten. Das klingt nach einem Vorteil für Organisationen, die spät erkennen. Es ist keiner. Im Prüfgespräch ist nicht die eingehaltene Frist die interessante Zahl, sondern die Spanne zwischen Ereignis und Kenntnisnahme – und die Frage, warum sie so lang war. Nachweisfähigkeit entscheidet sich in dieser Dimension nicht am Bericht, sondern an diesem Zeitraum. Die Zwischenmeldung erfolgt auf Ersuchen des BSI; für die Abschlussmeldung ist grundsätzlich der Zeitpunkt der Übermittlung der Folgemeldung maßgeblich.

Hier liegt die Unterscheidung, die diese Artikelserie durchzieht, besonders offen: Ein SIEM-Konzept, das Datenquellen, Regelwerk und Eskalationswege beschreibt, kann angemessen sein. Ob dieses System einen Angriff erkennt, ist eine Frage der Wirksamkeit – und die lässt sich nicht lesen. Angemessenheit steht im Dokument. Wirksamkeit muss man auslösen.

Vier Schichten zwischen Logzeile und Signal

Zwischen einer Protokollzeile und einem belastbaren Sicherheitssignal liegen vier Schichten. Jede kann für sich funktionieren und trotzdem wirkungslos bleiben, wenn die darunter fehlt.

Schicht 1: Abdeckung statt Volumen

Die erste Frage an eine Erkennungsarchitektur ist nicht, wie viele Ereignisse sie verarbeitet, sondern welche Systeme überhaupt hineinliefern. Beantworten lässt sie sich nur mit dem Inventar aus Dimension 1 des Referenzmodells in der Hand: Jedes als kritisch klassifizierte Asset wird gegen die Liste der angebundenen Quellen geprüft. Was dabei regelmäßig auffällt, sind keine Feinheiten, sondern Lücken im Fundament – Verzeichnisdienste ohne vollständige Anmeldeprotokollierung, Firewalls, die nur verworfene Verbindungen melden, Cloud-Mandanten, deren Audit-Protokoll nie aktiviert wurde.

OT-Umgebungen brauchen hierfür einen eigenen Weg. Steuerungssysteme liefern häufig keine auswertbaren Protokolle, und ein Log-Agent lässt sich auf einer speicherprogrammierbaren Steuerung nicht installieren. Sichtbarkeit entsteht dort über Netzwerksensorik: passive Analyse des Verkehrs an Segmentgrenzen, ergänzt um die Protokolle vorgelagerter Systeme. Das ist weniger präzise als ein Endpunkt-Agent – und deutlich mehr als die verbreitete Alternative, nämlich nichts.

Schicht 2: Eine Zeit, eine Sprache

Ereignisse aus verschiedenen Quellen sind nur vergleichbar, wenn sie dieselbe Zeitbasis und dieselbe Feldsemantik verwenden. Beides ist leicht zu fordern und regelmäßig ungelöst. Zwei Systeme mit vierzig Sekunden Zeitdrift erzeugen zwei Wahrheiten über dieselbe Minute – und eine Ereigniskette, die im Prüfgespräch auseinanderfällt. Eine synchronisierte Zeitquelle und die Speicherung in UTC mit dokumentierter Zeitzone sind deshalb keine Betriebsdetails, sondern Voraussetzung für Belegbarkeit.

Dasselbe gilt für Begriffe. Derselbe Benutzer erscheint je nach System als Anmeldename, als Prinzipalname oder als Objektkennung. Erst die Auflösung dieser Bezeichner auf eine Identität macht aus vier Ereignissen einen Vorgang. Was in Dimension 1 als Kontextmodell entstanden ist, wird hier zum Übersetzungsschlüssel. Entscheidend ist die Zusammenführung: Erst wenn Zeitbasis, Identität und Asset-Kontext zusammenkommen, wird aus einzelnen Ereignissen ein prüfbarer Vorgang.

Schicht 3: Vom Ereignis zum Fall

Korrelation verbindet einzelne Ereignisse zu einem Vorgang und ergänzt sie um Kontext: Welche Kritikalität hat das betroffene System? Wer ist verantwortlich? In welchem Segment steht es? Derselbe fehlgeschlagene Anmeldeversuch ist auf einem Testsystem ein Hinweis und auf einem Verzeichnisdienst in der Produktionszone ein Vorfall. Ohne Asset-Kontext kann die Auswertung diese Unterscheidung nicht treffen. Sie kann nur beide Ereignisse gleich laut melden – und genau das ist der Mechanismus, mit dem Alarmmüdigkeit entsteht.

Schicht 4: Detection Engineering

Die vierte Schicht ist keine Technologie, sondern eine Disziplin. Erkennungsregeln sind Software – und zwar in jeder Hinsicht, die zählt: Sie gehen aus einer Anforderung hervor. Sie enthalten Fehler. Sie altern, weil sich die Systeme unter ihnen verändern. Und sie müssen getestet werden, weil sonst niemand bemerkt, dass sie nicht mehr greifen.

Ändert sich das Format einer Datenquelle, feuert eine Regel, die niemand prüft, nicht falsch – sie feuert gar nicht mehr. Stille Regeln sind das teuerste Ergebnis eines gut gemeinten Detection-Projekts: Sie erzeugen genau das Gefühl von Abdeckung, das sie längst nicht mehr liefern.

Ein betreibbarer Prozess hält deshalb für jede Regel fest, aus welcher Anforderung oder welchem Bedrohungsszenario sie hervorgeht, auf welche Angriffstechnik sie zielt – üblicherweise mit Referenz auf ein etabliertes Modell wie MITRE ATT&CK –, welche Datenquelle sie benötigt, wann sie letztmals ausgelöst und wann sie letztmals getestet wurde. Diese Dokumentation ist kein Selbstzweck. Sie ist im Prüfgespräch der Unterschied zwischen einem laufenden System und einem gesteuerten Prozess.

Wenn der Alarm zum Hintergrundrauschen wird

Eine Erkennung, die niemand bearbeitet, ist keine Erkennung. Das ist der praktische Knackpunkt dieser Dimension und der Punkt, an dem die meisten Architekturen scheitern – nicht an fehlender Technik, sondern an einem Signal- Rausch-Verhältnis, das die verfügbare Bearbeitungskapazität dauerhaft überschreitet.

Der Grund liegt nicht in der Technik. Eine Warteschlange ist kein Speicherproblem, sondern ein Entscheidungsstau: Jeder Alarm verlangt von einem Menschen ein Urteil darüber, ob hier gerade etwas passiert. Bleibt dieses Urteil aus, ist die Erkennung technisch erfolgt und praktisch nicht geschehen. Erkennung endet nicht beim Alarm. Sie endet bei einer Entscheidung.

Eine hohe Fehlalarmquote ist dabei nicht automatisch ein Regelfehler. Häufig ist sie ein Kontextfehler: Die Regel ist präzise, ihr fehlt nur die Information, die den Normalfall vom Ausnahmefall trennt. Ein Alarm über eine Anmeldung aus dem Ausland ist wertlos, solange nicht bekannt ist, welche Benutzergruppen regelmäßig aus dem Ausland arbeiten. Der Weg zurück führt dann nicht in die Regellogik, sondern in Dimension 1.

Steuerbar wird der Betrieb erst mit wenigen belastbaren Kennzahlen. Sie sind unbequem, weil sie den Rückstand sichtbar machen. Genau deshalb sind sie der Kern jeder Wirksamkeitsprüfung – und die Antwort auf die Frage, die ein Prüfer als Erstes stellt: Woran merken Sie, dass Ihre Erkennung funktioniert? Gesetzlich vorgegeben ist keine dieser Kennzahlen; Auswahl, Definition und Zielwerte richten sich nach Risikoexposition, Geschäftsmodell und Betriebsmodell der Einrichtung.

Was bedeutet das für…?

Die vier Schichten beschreiben, wie Erkennung technisch entsteht. Wer sie verantwortet und welche Entscheidung daraus folgt, hängt von der Rolle ab.

… Geschäftsführung und Vorstand

Angriffserkennung wirkt wie ein technisches Thema und enthält doch zwei Entscheidungen, die niemand anderes treffen kann. Die erste ist die Betriebszeit: Wird durchgängig überwacht, und wenn ja, mit eigenem Personal oder über einen externen Dienstleister? Das ist eine Budget- und Vertragsfrage, keine Konfigurationsfrage. Die zweite betrifft den Umgang mit bekannten Lücken: Sobald ein Abdeckungsbericht zeigt, dass ganze Infrastrukturbereiche nicht überwacht werden, ist diese Kenntnis Teil der Aktenlage.

§ 38 BSIG weist der Geschäftsleitung besonders wichtiger und wichtiger Einrichtungen die Verantwortung zu, die nach § 30 BSIG erforderlichen Risikomanagementmaßnahmen umzusetzen und deren Umsetzung zu überwachen. Operative Aufgaben lassen sich organisatorisch übertragen; die gesetzliche Leitungsverantwortung bleibt davon unberührt. Bei Pflichtverletzungen richtet sich die Haftung nach den für die Rechtsform der Einrichtung geltenden gesellschaftsrechtlichen Vorschriften.

Für die Angriffserkennung heißt das konkret: Die Leitungsebene sollte beantworten können, wie lange es im eigenen Haus im Mittel dauert, bis ein Sicherheitsereignis bemerkt wird. Gesetzlich vorgegeben ist diese Kennzahl nicht – aussagekräftiger ist in dieser Dimension aber keine. Wer diese Zeitspanne nicht kennt, kann schwer belastbar beurteilen, ob Erkennung und Eskalation genügend Zeit für die anschließende Bewertung und einen fristgerechten Meldeprozess lassen.

… CISO und IT-Leitung

Die Leitfrage lautet nicht, ob ein SIEM läuft, sondern welche Angriffstechniken die Organisation heute belegbar erkennt – und für welche keine Datenquelle existiert. Eine Abdeckungsmatrix macht diese Antwort prüfbar und trennt zwei Dinge, die im Alltag verschwimmen: Regeln, die fehlen, und Daten, die fehlen. Der erste Fall ist Aufwand. Der zweite ist Architektur.

Dazu kommt die Priorisierung – und hier liegt die eigentliche Entlastung. Vollständige Abdeckung ist kein realistisches Ziel und wird auch nicht erwartet. Eine Organisation muss nicht jede Angriffstechnik erkennen. Sie muss begründen können, welche sie erkennt, welche nicht und warum. Diese Begründung, abgeleitet aus Risikoanalyse, Asset-Kritikalität und den für die eigene Umgebung plausiblen Angriffswegen, ist selbst ein Beleg: Sie zeigt, dass Erkennung gesteuert wird und nicht zufällig entsteht. Eine Lücke, die benannt, bewertet und terminiert ist, ist im Prüfgespräch etwas anderes als eine Lücke, die niemand kannte.

… technische Umsetzungsteams

Umsetzungsteams wissen meist genau, welche Regeln seit Monaten nicht ausgelöst haben und welche Datenquelle nach dem letzten Systemwechsel nie wieder angebunden wurde. Entscheidend ist, wie dieses Wissen behandelt wird: als informelle Erfahrung im Team oder als dokumentierte Architekturanforderung mit Zuständigkeit und Termin.

Der praktische Hebel ist ein Regel-Repository unter Versionskontrolle – jede Regel mit Anforderungsbezug, Datenquelle, Testfall und letzter Prüfung. Damit wird Detection Engineering überprüfbar – im Betrieb und in der Prüfung. Eine Regel, deren letzter Test nicht dokumentiert ist, bleibt im Prüfgespräch eine Behauptung. Versionierung, dokumentierte Testfälle und regelmäßige Reviews sind dabei geeignete Mittel, um die nach § 30 Abs. 2 Nr. 6 BSIG erforderliche Bewertung der Wirksamkeit zu stützen. Vorgegeben sind weder ein bestimmtes Repository noch ein einheitlicher Review-Zyklus; beides ist risikoorientiert festzulegen.

Use Case: Angriffserkennung bei einem regionalen Energieversorgung

Wie der Weg aus dieser Lage aussehen kann, lässt sich am eingangs skizzierten Fall des Energieversorgers nachvollziehen: rund 300 Mitarbeiter, hybride IT/OT-Infrastruktur und KRITIS-Relevanz.(Hinweis: Für Betreiber, die den Sondervorgaben der §§ 5c–5e EnWG unterliegen, richten sich die einschlägigen IT-Sicherheits- und Meldepflichten nach Maßgabe des spezialgesetzlichen Regimes des EnWG. Das technische Vorgehen zur Angriffserkennung bleibt davon unberührt.) Die technische Prüfung ergab 12.000 Ereignisse und 200 bis 400 Alarme pro Tag, 94 Prozent Fehlalarme in der Stichprobe, fünf Wochen Rückstand in der Warteschlange und 210 aktive Erkennungsregeln ohne dokumentierten Anforderungsbezug. Aus dem OT-Netz lagen keine Logdaten vor.

• Phase 1 – Datenbasis bewerten. Abgleich der angebundenen Datenquellen gegen das Asset-Inventar aus Dimension 1. Ergebnis: 40 Prozent der als kritisch eingestuften Systeme lieferten keine oder unvollständige Daten. Die Lücken wurden nach Kritikalität und Exposition priorisiert geschlossen, im OT-Netz über passive Sensorik an den Segmentgrenzen statt über Agenten.
• Phase 2 – Regelwerk prüfen. Alle 210 Regeln wurden gegen drei Kriterien geprüft: Existiert die referenzierte Datenquelle noch? Ist ein Erkennungsbeitrag erkennbar? Ist die Fehlalarmquote vertretbar? Ergebnis: 47 Regeln deaktiviert, 68 überarbeitet, 31 neu entwickelt. Das Alarmvolumen sank auf 30 bis 50 pro Tag, die Fehlalarmquote unter 30 Prozent. Entscheidend war nicht
  die Zahl der Regeln, sondern dass jede eine dokumentierte Herkunft erhielt.
• Phase 3 – Betrieb verankern. Einführung eines vierteljährlichen Regel-Reviews, Aufbau des Repositorys mit verpflichtender Dokumentation, klare Definition des Eskalationspfads von der Alarmierung in die Incident Response und damit die Verknüpfung mit Dimension 3.

Am Ende stand kein anderes SIEM. Es war dieselbe Technologie mit einer anderen Betriebslogik. Der Unterschied lag nicht im System, sondern im Prozess darum herum – und er war belegbar: Erstmals ließ sich beantworten, welche Angriffstechniken erkannt werden und welche nicht.

Visualisierungsansatz: Detection-Coverage-Matrix

Die Frage, welche Angriffstechniken eine Organisation erkennt, lässt sich in einer Heatmap mit zwei Achsen abbilden: Zeilen als Angriffsphasen nach MITRE ATT&CK, Spalten als Infrastrukturdomänen – Endpunkte, Netzwerk, Identitäten, Cloud, OT/ICS. Vier Farbzustände unterscheiden fehlende Abdeckung, partielle Abdeckung, gepflegte und getestete Regeln sowie nicht anwendbare Kombinationen.

Ergänzt um einen Abdeckungsbalken je Angriffsphase entsteht daraus kein Betriebs-Dashboard, sondern ein Managementinstrument: Es zeigt, wo strukturelle Lücken bestehen, trennt fehlende Regeln von fehlenden Daten und liefert die Grundlage für eine begründete Ausbaureihenfolge. Im Prüfgespräch belegt es einen gesteuerten Erkennungsprozess – nicht nur ein laufendes System.

Fazit

Protokollierung ist die Voraussetzung der Angriffserkennung, nicht ihr Ergebnis. Zwischen Logzeile und belastbarem Sicherheitssignal liegen vier Schichten. Fällt eine aus, verliert die Kette ihre Beweiskraft – auch dann, wenn das System weiterläuft und Berichte erzeugt.

• Abdeckung vor Volumen. Die relevante Kennzahl ist nicht die Menge verarbeiteter Ereignisse, sondern der Anteil kritischer Systeme, die belastbare Daten liefern.
• Regeln sind Software. Ohne Versionierung, Test und Review erzeugen sie Abdeckung auf dem Papier und Stille im Betrieb.
• Bearbeitbarkeit ist Teil der Architektur. Eine Warteschlange, die niemand aufarbeitet, ist keine Kapazitätsfrage, sondern eine Erkennungslücke.
• Wirksamkeit wird ausgelöst, nicht dokumentiert. Erst der kontrollierte Test belegt, dass ein Alarm entsteht, richtig priorisiert und eskaliert wird.
• Erkennung ist keine Produktfrage. Telemetrie, Kontext, Regeln und Betrieb müssen zusammenkommen. Welche Plattform sie bündelt, ist nachrangig – und keine der vier lässt sich durch eine der anderen ersetzen.

Für die Wirksamkeit der Angriffserkennung ist eine zentrale Messgröße die Spanne zwischen Ereignis und technischer Erkennung. Je länger sie ist, desto später kann eine qualifizierte Bewertung beginnen. Erkennung endet bei einer Entscheidung – und genau dort beginnt die nächste Dimension.

Ein Alarm, der korrekt entsteht, korrekt priorisiert wird und dann auf einen Prozess trifft, der Zuständigkeiten offenlässt, endet als gut dokumentierter Fehlschlag. Der Beitrag in der nächsten Ausgabe der IT-SICHERHEIT widmet sich Dimension 3 des Referenzmodells, der Incident Response: warum die 24- und 72-Stunden-Fristen aus § 32 BSIG der eigentliche Belastungstest jeder Sicherheitsarchitektur sind, was Playbooks tatsächlich leisten – und wo Automatisierung an ihre Grenzen stößt.

Literatur

[1] Europäisches Parlament und Rat der EU (2022): Richtlinie (EU) 2022/2555 über Maßnahmen für ein hohes gemeinsames Cybersicherheitsniveau in der Union (NIS-2-Richtlinie). Amtsblatt der EU, L 333, 27.12.2022.
[2] Gesetz zur Umsetzung der NIS-2-Richtlinie und zur Regelung wesentlicher Grundzüge des Informationssicherheitsmanagements in der Bundesverwaltung (NIS2-RLUG / BSIG).
[3] Bundesamt für Sicherheit in der Informationstechnik – BSI (2023): BSI-Standard 200-2: IT-Grundschutz-Methodik. Bonn: BSI.
[4] Bundesamt für Sicherheit in der Informationstechnik – BSI (2026): Handreichung Schulung für Geschäftsleitungen, Version 1.0, 17.04.2026.
[5] International Organization for Standardization (2022): ISO/IEC 27001:2022 – Informationssicherheits-Managementsysteme. Genf: ISO.
[6] MITRE Corporation: MITRE ATT&CK – Adversarial Tactics, Techniques and Common Knowledge. McLean, VA.
[7] IEC 62443 (2018 ff.): Security for industrial automation and control systems. Genf: IEC.
[8] ENISA: NIS2 Technical Implementation Guidance, Version 1.0, June 2025 (veröffentlicht 26.06.2025).