Das Management von Sicherheitsvorfällen – ein Klassiker bekommt durch NIS-2 neue Brisanz

Mit der Behandlung und speziell dem Management von Sicherheitsvorfällen sollten sich alle Organisationen befassen, denn jede IT-Infrastruktur kann von einem Sicherheitsvorfall betroffen sein. Betreibt eine Organisation jedoch ein Informationssicherheitsmanagementsystem (ISMS) nach ISO/IEC 27001 oder nach BSI-IT-Grundschutz, besitzt das Management von Sicherheitsvorfällen automatisch eine besondere Bedeutung. Ist eine Organisation eine wichtige oder besonders wichtige Einrichtung oder gar Betreiber einer kritischen Infrastruktur im Sinne des BSI-Gesetzes vom Dezember 2025 [1], nimmt das Management von Sicherheitsvorfällen eine noch exponiertere Rolle ein.

Spätestens jetzt ist es an der Zeit, sich mit dem Thema Management von Sicherheitsvorfällen in der eigenen Organisation auseinanderzusetzen. Als Denkanstoß kann der vorliegende Artikel dienen: Er beschreibt alle wesentlichen Aspekte des Sicherheitsvorfallmanagements, erläutert Prozess-Strukturen und betrachtet Schnittstellen zwischen Prozessen. Regulative Grundlagen werden diskutiert und Werkzeuge und Methoden für das SVM vorgestellt.

Auswirkungen von NIS-2 auf das SVM

Mit dem Anfang Dezember 2025 in Kraft getretenen BSI-Gesetz (BSIG, [1]) erfolgt die Umsetzung der NIS-2-Richtlinie der EU [2] in deutsches Recht. Durch dieses Gesetz bekommt ein angemessenes Management von Sicherheitsvorfällen eine herausgehobene Bedeutung, denn es verpflichtet wichtige und besonders wichtige Einrichtungen sowie Betreiber kritischer Infrastrukturen dazu, angemessene Maßnahmen zur Bewältigung von Sicherheitsvorfällen zu ergreifen, und verlangt zudem eine Meldung von erheblichen Sicherheitsvorfällen.

Als erheblich gilt im Sinne des §2 Nr.11 BSIG ein Sicherheitsvorfall, der

• schwerwiegende Betriebsstörungen der Dienste oder finanzielle Verluste für die betreffende Einrichtung verursachen kann oder bereits verursacht hat, oder
• andere Personen (natürliche oder juristische) durch erhebliche materielle oder immaterielle Schäden beinträchtigen kann oder bereits beeinträchtigt hat.

Für spezielle Einrichtungen, wie beispielsweise DNS-Dienstanbieter oder Vertrauensdienstanbieter, gelten darüber hinausgehende Definitionen von erheblichen Sicherheitsvorfällen durch weitere Durchführungsverordnungen der EU (z.B. Durchführungsverordnung (EU) 2024/2690 vom 17.10.2024).

Nach §32 (1) BSIG sind Betreiber wichtiger und besonders wichtiger Einrichtungen dazu verpflichtet, einen erheblichen Sicherheitsvorfall unverzüglich nach der Kenntniserlangung an das BSI zu melden. Dazu steht seit dem 06. Januar 2026 das neue Meldeportal des BSI zur Verfügung. Unter „Kenntniserlangung“ ist dabei der Zeitpunkt gemeint, zu dem ein Mitarbeiter der Einrichtung während seiner Arbeitszeit Kenntnis über den erheblichen Sicherheitsvorfall erlangt (vgl. hierzu [3]). Für die Erstmeldung eines erheblichen Sicherheitsvorfalls darf eine Einrichtung den Zeitraum von 24 Stunden nach der Kenntniserlangung nicht überschreiten. Diese Erstmeldung dient als Frühwarnung und soll bereits Informationen enthalten, ob der gemeldete Vorfall auf böswillige oder rechtswidrige Handlungen zurückzuführen ist und ob der Vorfall ggf. sogar grenzüberschreitende Auswirkungen mit sich bringen kann.

Innerhalb von 72 Stunden nach der Kenntniserlangung über einen erheblichen Sicherheitsvorfall muss die Einrichtung die Informationen der Erstmeldung aktualisieren und eine Bewertung des Vorfalls sowie seinen Schweregrad und die Auswirkungen melden. Spätestens nach einem Monat wird, falls der Vorfall beendet ist, eine Abschlussmeldung erwartet. Diese Meldung muss einen ausführlichen Bericht zum Vorfall inklusive des Schweregrads und der Auswirkungen enthalten. Es müssen zudem Angaben zur Art der Bedrohung bzw. zu den tiefer liegenden Ursachen, die den Vorfall auslösten, gemacht und die ergriffenen sowie ggf. noch laufenden Abhilfemaßnahmen dargestellt werden. Sollte der gemeldete Vorfall nicht binnen eines Monats abgeschlossen werden können, muss anstatt der Abschlussmeldung eine sogenannte Folgemeldung mit denselben Inhalten erfolgen. Zusätzlich kann das BSI Zwischenmeldungen über relevante Statusaktualisierungen während der Bearbeitung des Vorfalls fordern.

Noch härter trifft es die Betreiber kritischer Anlagen, auch als KRITIS bezeichnet: Zum einen müssen diese in den Meldungen zu erheblichen Sicherheitsvorfällen ergänzende Angaben zur Art der betroffenen Anlage, zur kritischen Dienstleistung sowie zu den durch den Vorfall entstandenen Auswirkungen auf diese Dienstleistung übersenden. Zum anderen verpflichtet §31 (2) BSIG die KRITIS-Betreiber dazu, Systeme zur Angriffserkennung einzusetzen, die eine kontinuierliche und automatische Erfassung sowie Auswertung von Merkmalen und Parametern zur Erkennung von Angriffen im laufenden Betrieb sicherstellen. Die eingesetzten Systeme sollen Bedrohungen permanent identifizieren und vermeiden sowie passende Gegenmaßnahmen bei eingetretenen Störungen ergreifen. Damit übernimmt §31 (2) des neuen BSI-Gesetzes die Rolle des §8a im bisherigen, als „IT-Sicherheitsgesetz 2.0“ bekannten BSI-Gesetz und stellt erhebliche Anforderungen an die Detektion von sicherheitsrelevanten Ereignissen.

Dieser Überblick über die im BSI-Gesetz verankerten Meldepflichten zeigt: Ein durchdachtes Management von Sicherheitsvorfällen ist für alle Betreiber wichtiger und besonders wichtiger Einrichtungen sowie KRITIS-Betreiber ein absolutes Muss. Und auch Einrichtungen, die in diesem Punkt bisher gut aufgestellt sind, müssen jetzt nach Inkrafttreten des Gesetzes und der Einrichtung des Meldeportals durch das BSI ihre Prozesse aktualisieren. Ansonsten ist im Ernstfall die Einhaltung der Meldepflichten wahrscheinlich utopisch.

Anforderungen im Sicherheitsvorfallmanagement

Sicherheitsvorfallmanagement ist jedoch deutlich mehr als das fristgerechte Erfüllen von gesetzlich vorgegebenen Meldepflichten. Vielmehr beinhaltet das SVM die Detektion von sicherheitsrelevanten Ereignissen (SREs, s.u.) und die Behandlung eines Sicherheitsvorfalls (inklusive der möglichen Meldungen an das BSI im Falle eines erheblichen Sicherheitsvorfalls).

Dies erfordert zunächst eine Definition der Begriffe „sicherheitsrelevantes Ereignis“ bzw. „Sicherheitsvorfall“. Im Sinne der „Orientierungshilfe zum Einsatz von Systemen zur Angriffserkennung“ [4] des BSI werden alle Ereignisse, die die Vertraulichkeit, Integrität, Authentizität oder Verfügbarkeit von Informationen, Geschäftsprozessen, IT-Diensten, -Anwendungen oder -Systemen derart beeinträchtigen, dass ggf. ein Schaden entstehen kann, als sicherheitsrelevante Ereignisse (SREs) bezeichnet. Ein SRE stellt einen Sicherheitsvorfall dar, wenn der begründete Verdacht auf die Verletzung von Vertraulichkeit, Integrität, Authentizität oder Verfügbarkeit besteht.

Insbesondere an der Detektion von SREs können diverse Organisationseinheiten beteiligt sein. Denn neben speziellen Bereichen zur Detektion wie z. B. einem Security Operations Center (kurz SOC) können sicherheitsrelevante Ereignisse auch im Rahmen von Prozessen anderer Organisationseinheiten wie dem IT-Monitoring oder dem User Help Desk erkannt werden. Ebenso müssen automatisierte Meldungen durch eingesetzte Werkzeuge genauso berücksichtigt werden können wie Meldungen von ungewöhnlichem Verhalten von IT-Systemen, die ein aufmerksamer Endnutzer macht. Die Koordination dieser verschiedenen Prozesse und Organisationseinheiten stellt eine zentrale Herausforderung im SVM dar und bringt die Notwendigkeit mit sich, dass SVM kein reines ISMS-Thema bleiben kann, sondern dabei vielmehr auch weitergehende Ebenen einer Einrichtung berücksichtigen muss.

Essenziell ist, dass alle Meldungen, egal aus welcher Quelle, zügig und kompetent weiterbearbeitet werden. Somit erfordert das SVM eine eigene (ggf. virtuelle) Organisationseinheit, die einerseits tief in die verwendete Technik einsehen kann und andererseits die Kompetenzen besitzt zu entscheiden, wie mit Meldungen von sicherheitsrelevanten Ereignissen weiter verfahren wird. Mehr zum organisatorischen Aufbau des SVMs ist im nächsten Abschnitt dieses Artikels enthalten.

Folgt man mit seinem ISMS dem Standard ISO/IEC 27001 [5] und den damit verbundenen ISO-Standards, trifft man auf das Thema SVM in den Anforderungen 5.24 bis 5.28 im Kapitel „5 Organisatorische Maßnahmen“. Wie gewohnt sind diese Anforderungen eher knapp gehalten, jedoch verfügt die ISO-2700x-Familie über eigene Normen, die sich ausschließlich mit der Gestaltung von ISMS-Prozessen bzw. dem Management von Sicherheitsvorfällen auseinandersetzen: die ISO/IEC 27022 [6] bzw. ISO/IEC 27035 [7], auf die wir im nächsten Kapitel noch kurz eingehen werden.

Im Falle eines ISMS nach BSI IT-Grundschutz sind Bausteine der Schicht „Detektion und Reaktion (DER)“ des BSI IT-Grundschutz-Kompendiums in der Edition von 2023 [8] für das SVM vorrangig umzusetzen. Für das SVM sind jedoch auch einzelne Anforderungen aus Bausteinen anderer Schichten relevant. Im Grundschutz++, dem noch in der Entwicklung befindlichen Nachfolger des IT-Grundschutzes, sind den Themen Detektion und Sicherheitsvorfallbehandlung jeweils eigene, sogenannte Praktiken gewidmet, die Anforderungen enthalten. Einen Blick in die aktuelle „Stand-der-Technik-Bibliothek“, dem Nachfolger des IT-Grundschutz-Kompendiums, finden Sie unter [9].

Weitere Veröffentlichungen des BSI, die Vorgaben zum SVM enthalten, sind der „Mindeststandard des BSI zur Protokollierung und Detektion von Cyberangriffen“ [10] sowie die „Orientierungshilfe zum Einsatz von Systemen zur Angriffserkennung“ [4]. Mit seinen Mindeststandards legt das BSI die Sicherheit der Informationstechnik des Bundes fest. Die genannte Orientierungshilfe adressiert die Betreiber kritischer Infrastrukturen. Beide Dokumente erweitern und schärfen die Anforderungen des IT-Grundschutz-Kompendiums in der Edition von 2023 deutlich.

Auch wenn eine Einrichtung kein ISMS streng nach ISO/IEC 27001 oder BSI IT-Grundschutz betreibt, können die vorgenannten Standards und Veröffentlichungen herangezogen werden, um das SVM in der eigenen Einrichtung zu gestalten. Sie können als Leitschnur bei der organisatorischen Ausgestaltung dienen.

Organisatorischer Aufbau und grundlegende Prozesse

Der organisatorische Aufbau und die grundlegenden Prozesse für ein SVM sind in verschiedenen Standards zur Informationssicherheit teilweise ausführlich geregelt.

Ein wichtiges Beispiel ist hier die Serie von Standards, die sich in den letzten Jahren um die ISO/IEC 27001, wie oben dargestellt, gebildet hat. Die Norm ISO/IEC 27022 „Information technology – Guidance on information security management system processes“ [6] stellt dabei ein allgemeines Prozess-Referenzmodell zur Verfügung, das die für ein ISMS erforderlichen, in der Norm ISO/IEC 27001 implizit geforderten Prozesse definiert. Hier wird unter anderem der Prozess „Information security incident management” spezifiziert, der dann als Grundlage für einen an die eigenen Gegebenheiten angepassten Prozess zum Management von Sicherheitsvorfällen dienen kann.

Der Standard ISO/IEC 27035 „Information technology – Information security incident management” beschäftigt sich als Vertiefung sogar ausschließlich mit dem Information Security Incident Management. Er besteht aus vier Teilen. Teil 1 „Part 1: Principles and process“ [7] beinhaltet die grundlegenden Konzepte und Prinzipien des Managements von Sicherheitsvorfällen und einen zugehörigen Prozess in Form eines Phasenplans. Die Phasen umfassen dabei die Detektion von SREs, die Bewertung derselben, die Reaktion auf Sicherheitsvorfälle sowie eine Nachbereitung in Form eines Lessons-Learned-Prozesses. Damit wird ein strukturierter Ansatz bereitgestellt, um sicherheitsrelevante Ereignisse zu erkennen, zu melden, zu beurteilen, geeignete Reaktionen zu ergreifen und gesammelte Erfahrungen nachzubereiten, um sie zukünftig umzusetzen.

Mit diesem Phasenplan bietet die ISO/IEC 27035 eine Blaupause, um ein für die eigene Organisation maßgeschneidertes SVM aufzubauen. Die Herausforderung, dass an den diversen Phasen zahlreiche Prozesse innerhalb und außerhalb der Informationssicherheit beteiligt sind, bleibt aber bestehen. Ein Beispiel für einen Prozess, der an verschiedenen Phasen des SVMs beteiligt ist, ist das Risikomanagement. Denn einerseits muss der Status des betroffenen Risikos bei der Wertung eines SREs zur Weiterverarbeitung unbedingt berücksichtigt werden, und andererseits kann die Bearbeitung eines SREs eine zugehörige Risikoeinschätzung unmittelbar positiv oder negativ beeinflussen. Analoges gilt auch für andere Prozesse in und außerhalb der Informationssicherheit, wie die Abbildung 1 dargestellt.

Methoden und Werkzeuge zur Detektion und Behandlung von Sicherheitsvorfällen

An welcher Prozessstruktur man sich auch orientiert, ohne spezielle Methoden und zugehörige Werkzeuge, die bei der Erkennung von SREs helfen, kommt das SVM nicht aus.

Das MITRE ATT&CK-Framework [11] bietet eine frei verfügbare Wissensdatenbank zu real genutzten Angriffstaktiken und -techniken. In der sogenannten ATT&CK-Matrix werden den taktischen Phasen eines Angriffs genutzte Angriffstechniken zugeordnet und zugehörige Sub-Techniken beschrieben. Außerdem gibt es eine Liste von Maßnahmen zur Entschärfung der Angriffstechniken. Das Framework unterstützt damit die Entwicklung von Analysemethoden, um solche Techniken zu erkennen, Bedrohungen zu strukturieren sowie zu analysieren und Maßnahmen zu ihrer Entschärfung zu wählen.

Ein zentraler Bestandteil des SVMs sind die Werkzeuge, die insbesondere bei der Detektion von SREs eine tragende Rolle spielen (siehe auch Abbildung 2). Eine vollständige, möglichst zentrale Protokollierung von insbesondere betriebs- oder sicherheitsrelevanten Ereignissen  dient dabei als Basis. Im Fall einer zentralen Protokollierung wird oft von einem Log-Management (LM) gesprochen. Hier werden kontinuierlich und möglichst lückenlos Ereignisprotokolle aus nahezu allen IT-Systemen und Anwendungen eines Unternehmens erfasst, sortiert und an einem zentralen Ort gespeichert. Diese Daten sind vollständig indexiert und maschinell durchsuchbar.

Die dadurch mögliche automatisierte Analyse der Daten kann durch eine Lösung des Security Information and Event Management (SIEM) erfolgen. Ergänzend zum reinen Log-Management kann eine SIEM-Lösung sicherheitsrelevante Daten erfassen und verwalten, sie in Echtzeit korrelieren und analysieren sowie Meldungen und Alarme erzeugen, wenn dabei Anomalien erkannt werden. Neben den Daten des Log-Managements können auch lokal protokollierte Daten und Daten aus weiteren Werkzeugen, wie im Folgenden beschrieben, in die Analyse eingebunden werden.

Eine SIEM-Lösung wird oft mit einer Lösung für Security Orchestration, Automation and Response (SOAR) kombiniert, die als weiterer Automatisierungsschritt über definierte Schnittstellen aktiv Maßnahmen zur Abwehr der Sicherheitsbedrohungen auslösen kann. Somit erweitert SOAR die SIEM-Lösung um automatisierte Reaktionen auf die im SIEM erzeugten Meldungen und Alarme.

In die genannten Werkzeuge können auch Daten und Meldungen weiterer Werkzeuge eingebunden werden (vgl. Abbildung 2). Hier sind zunächst Werkzeuge zur Erkennung von Schadsoftware zu nennen. Dazu gehören Intrusion-Detection-Systeme (IDS) und Intrusion-Prevention-Systeme (IPS) sowie IDS-/IPS-Funktionen von Firewalls, in der Vergangenheit oft als Next Generation Firewalls (NGFW) bezeichnet, oder anderen Sicherheitskomponenten. Außerdem zählen hierzu Lösungen für Endpoint Detection and Response (EDR), die kontinuierlich Endgeräte überwachen und analysieren, um verdächtiges Verhalten und Bedrohungen zu erkennen und gegebenenfalls automatisiert darauf zu reagieren, Lösungen für Extended Detection and Response (XDR), die EDR über Endgeräte hinaus auf Sicherheitskomponenten und Dienste erweitern. Hinzu kommen Lösungen für Network Detection and Response (NDR), die als Pendant zu EDR/XDR auf Netzebene den Netzverkehr in Echtzeit passiv überwachen und analysieren, um verdächtige Aktivitäten, Angriffe, Sicherheitsverletzungen oder Abweichungen von normalen Verhaltensmustern zu identifizieren. Typischerweise werden EDR-/XDR-/NDR-Lösungen einerseits an eine SIEM- oder SOAR-Lösung als Datenquelle angebunden, können aber andererseits auch Ziel für eine vom SOAR orchestrierte Aktion sein.

Auch Werkzeuge zur Erkennung von Schwachstellen gehören zu relevanten Werkzeugen für das SVM. Hierzu zählen Schwachstellenscanner, die regelmäßig oder bedarfsorientiert aktive und passive Schwachstellenscans durchführen. Ebenso fließen erkannte Schwachstellen aus Penetrationstests und Red-Teaming-Übungen in das SVM mit ein.

Zusammenfassung

Das Management von Sicherheitsvorfällen darf für keine Organisation ein gänzlich neues Thema sein. Für alle Organisationen, die nun vom neuen BSI-Gesetz bzw. der NIS-2-Richtlinie betroffen sind, gewinnt es sogar an Brisanz. Ein gut durchdachtes SVM hilft nicht nur dabei, die neuen gesetzlichen Pflichten zu erfüllen, sondern kann im Ernstfall Schaden vom Unternehmen abwenden oder zumindest reduzieren. Das macht das SVM zu einem zentralen Prozess der Informationssicherheit, der Schnittstellen zu zahlreichen weiteren Prozessen innerhalb und außerhalb der Informationssicherheit hat.

Quellen

[1] „Gesetz über das Bundesamt für Sicherheit in der Informationstechnik und über die Sicherheit in der Informationstechnik von Einrichtungen (BSI-Gesetz – BSIG)“ als Artikel 1 in „Gesetz zur Umsetzung der NIS-2-Richtlinie und zur Regelung wesentlicher Grundzüge des Informationssicherheitsmanagement in der Bundesverwaltung“, verfügbar unter Bundesgesetzblatt Teil I – Gesetz zur Umsetzung der NIS-2-Richtlinie und zur Regelung wesentlicher Grundzüge des Informationssicherheitsmanagements in der Bundesverwaltung – Bundesgesetzblatt

[2] „Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 on measures for a high common level of cybersecurity across the Union, amending Regulation (EU) No 910/2014 and Directive (EU) 2018/1972, and repealing Directive (EU) 2016/1148 (NIS 2 Directive)“, verfügbar unter: Directive – 2022/2555 – EN – EUR-Lex

[3] BSI – NIS-2-Meldepflicht, abgerufen am 07.01.2026

[4] „Orientierungshilfe zum Einsatz von Systemen zur Angriffserkennung“, Version 1.1, BSI, 2024, verfügbar unter https://www.bsi.bund.de/DE/Themen/Regulierte-Wirtschaft/Kritische-Infrastrukturen/Service-fuer-KRITIS-Betreiber/KRITIS-Downloads/kritis-downloads_node.html#doc434598bodyText4

[5] DIN EN ISO/IEC 27001, Informationssicherheit, Cybersicherheit und Datenschutz – Informationssicherheitssysteme“, Deutsche Fassung EN ISO/IEC 27001:2023, 2024

[6] ISO/IEC TS 27022, „Information technology – Guidance on information security management system processes“, 2021

[7] ISO/IEC 27035 „Information technology – Information security incident management”, Teil 1 bis Teil 4, 2020 bis 2024

[8] „BSI IT-Grundschutz-Kompendium“, Edition 2023, BSI

[9] https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek

[10] „Mindeststandard des BSI zur Protokollierung und Detektion von Cyberangriffen“, Version 2.1, BSI, 2024

[11] MITRE ATT&CK-Framework, verfügbar unter https://attack.mitre.org/