Angriffserkennung KRITIS

Mit der Orientierungshilfe für Systeme zur Angriffserkennung (OH SzA) legt das BSI Vorgaben zur Erkennung von Cyberangriffen durch KRITIS-Betreiber fest. Die Orientierungshilfe definiert verbindliche Anforderungen für Protokollierung, Erkennung und Reaktion bei Betreibern, die seit 2023 umgesetzt werden müssen.

Governance
Systeme
Systeme
Protokollierung
OH SzA
Detektion
Reaktion
Mapping

Die OH SzA fordert dazu eine umfangreiche Organisation und Infrastruktur zur Erkennung von Cyberangriffen. Starker Fokus liegt auf Automatisierung, Zentralisierung und sehr vielen und teils sehr spezifischen Vorgaben zur Architektur á la SOC, CERT und SIEM.

Incident Management

Organisation und Steuerung

Für die Behandlung von Sicherheitsvorfällen in Kritischen Infrastrukturen sind im ISMS klare Verantwortlichkeiten und Abläufe notwendig. Dafür muss das ISMS Rollen und Prozesse für die Erkennung und Behandlung von Cyber-Vorfällen in KRITIS-Anlagen definieren und im Betrieb implementieren.

KdA KRITIS	Anforderung	RUN Grad
BSI-77	Verantwortlichkeiten und Vorgehensmodell	(3)
BSI-78	Bearbeitung von Sicherheitsvorfällen	(3)
BSI-79	Dokumentation und Berichterstattung über Sicherheitsvorfälle	(3)
BSI-81	Verpflichtung der Nutzer zur Meldung von Sicherheitsvorfällen	(3)
BSI-82	Auswertung und Lernprozess	(3)

Rollen

Rollen und Aufgaben müssen für Cyber-Vorfälle im KRITIS-Geltungsbereich festgelegt werden. Die Rollen können einzeln oder auch zusammen Teil vom CERT, CSIRT, SOC beim Betreiber sein.

Leiter IS-Vorfälle: Governance für und Leitung der Vorfallserkennung und -behandlung
Team IS-Vorfälle: Reaktionsteam zur operativen Bewältigung und Lösung von Vorfällen

Prozesse

Für den Umgang mit Störungen und IS-Vorfällen müssen durch die Informationssicherheit zentrale Prozesse im IT-Betrieb der KRITIS-Anlagen definiert werden, u.a.:

Detektion: Störungen, Angriffe und IS-Vorfälle müssen anhand von Logs, Mustern und Indikatoren in der IT erkannt und festgestellt werden
Reaktion: Erkannte Vorfälle müssen von Fachpersonal klassifizert und behandelt, und die weitere Bewältigung eingeleitet werden (zum Incident-/Notfall-/Krisen-Management)
Meldungen: Festgestellte IS-Vorfälle und Störungen müssen dokumentiert und gemeldet werden, falls diese BSIG-meldepflichtig sind (ggf. über die Meldeorganisation)
Auswertung: Vorfälle und Bewältigung müssen für Lessons Learned ausgewertet werden

Nachweise

Artefakte als Nachweis für funktionierende Governance für Vorfälle sind u.a.:

Detektierte Angriffsmuster
Erkannte Angriffe
Bewältigte Vorfälle
Meldungen

Systeme und Auswertung

Um Vorfälle und Cyber-Angriffe in KRITIS-Anlagen zu erkennen, müssen Ereignisse (Events) in den IT-Systemen protokolliert, zentral korreliert und ausgewertet werden. Basierend auf den Informationen aus Log-Dateien von IT-Systemen und SIEM-Lösungen (Indikatoren) kann die Organisation für Sicherheitsvorfälle mit ihren Prozessen tätig werden.

BSI KRITIS KdA	Anforderung	RUN Grad
BSI-80	Security Incident Event Management (SIEM)	(3)
BSI-90	Systematische Log-Auswertung - Konzept	5
BSI-91	Systematische Log-Auswertung - kritische Assets	5
BSI-92	Systematische Log-Auswertung – Aufbewahrung	5
BSI-93	Systematische Log-Auswertung – Konfiguration	5
BSI-94	Systematische Log-Auswertung – Verfügbarkeit	5

Logs und Assets

In den wichtigen IT-Systemen (kritische Assets) der KRITIS-Anlagen müssen sicherheitsrelevante Ereignisse protokolliert und zentral (geschützt) aufbewahrt werden. Die Ereignisse umfassen in der Regel mindestens alle Vorgänge zu Nutzern, Berechtigungen und Anmeldungen in Systemen und speziell die Aktivitäten von Administratoren oder anderen privilegierten Benutzern. Der Scope der wichtigen IT-Systeme sollte regelmäßig überprüft und angepasst werden.

Nachweise

Nachweise für die effektive Auswertungen von Logs und Vorfällen sind u.a.:

Zentrale Log-Auszüge
Assets im SIEM
Ausgewertete Ereignisse
Indikatoren

Schwachstellen

Mit regelmäßigen Sicherheitstests (Penetrationstests) können KRITIS-Betreiber Angriffe auf die KRITIS-Anlagen simulieren, um Schwachstellen in der IT und OT aufzudecken und die Reaktion der Organisation auf Vorfälle zu überprüfen. Penetrationstest können zur Awareness im Unternehmen beitragen und neben technischen Schwachstellen systematische Lücken aufdecken.

Der Umgang mit kritischen Schwachstellen in Systemen und Prozessen muss Vorgaben aus dem ISMS folgen: Schwachstellen, die durch die Prozesse der Angriffserkennung in Protokollen, Scans oder Tests erkannt werden, aber auch automatisierte Scans durch das Schwachstellen-Management.

BSI KRITIS KdA	Anforderung	RUN Grad
BSI-95	Penetrationstest	5
BSI-96	Umgang mit Schwachstellen, Störungen und Fehlern	5

Nachweise

Artefakte von regelmäßigen und effektiven Penetrationstests sind u.a.:

Testberichte
Jahresplanung von Tests
Maßnahmen
Geschlossene Schwachstellen
Kennzahlen aus Scans
Kennzahlen von Vorfällen

Orientierungshilfe Angriffserkennung

OH SzA (Allgemein)

Übergreifende Anforderungen an alle Phasen der Angriffserkennung, die sich vor allem um Rahmenbedingungen und Aktualität der Plattform und Systeme drehen.

Angriffserkennung allgemeine MUSS-Kriterien, eigene Zusammenstellung, Stand Oktober 2024
OH SzA	Thema	Anforderung
Kap 1.2	Rahmenbedingungen	Die für Angriffserkennung notwendige Technologie, Organisation und Personal muss vorhanden sein.
Kap 1.2	Angriffsmuster	Informationen zu Schwachstellen eingesetzter Systeme und zu Angriffen müssen eingeholt werden.
Kap 1.2	Plattform	Die zur Angriffserkennung notwendige Hardware und Software muss auf dem aktuellen Stand sein.
Kap 1.2	Signaturen	Die Signaturen zur Detektion müssen aktuell gehalten werden.
Kap 1.2	Konfiguration	Systeme müssen so konfiguriert werden, dass bekannte Möglichkeiten der Schwachstellenerkennung genutzt werden.

Protokollierung (SZA-P)

Spezifische Anforderungen zum Logging und der Speicherung von Logdaten, damit Systeme der Kritischen Infrastruktur abgedeckt werden und die Protokollierung zentral geschützt ist.

KRITIS SzA Protokollierung MUSS/SOLL, eigene Zusammenstellung, Draft 20241024
BSI KRITIS KdA/RUN	Thema	Anforderung
BSI-101 3/4/5	Planung	Die zur Speicherung und Auswertung notwendige IT muss in der Planung bedacht und gesetzliche Regelungen (mind. Datenschutz) berücksichtigt werden. Die Planung muss dokumentiert werden, inkl. Netzbereiche, Datenquellen/-flüsse, Kommunikationsbeziehungen und protokollierter Ereignisse pro System. Die für die Kritische Infrastruktur (kDL) wichtigen Systeme müssen identifiziert werden. Die notwendige Protokollierung muss nach Änderungen (Changes) im Geltungsbereich mittels Prozess angepasst werden.
BSI-102 3	Richtlinie Protokollierung (OPS.1.1.5)	Die sichere Planung, Aufbau und Betrieb von Protokollierung muss in einer Richtlinie definiert werden, inkl. wie, wo und was protokolliert werden soll. Die Richtlinie muss vom ISB mit Fachverantwortlichen erstellt, abgestimmt, allen Mitarbeitern in der Protokollierung bekannt und die Umsetzung regelmäßig überprüft werden. Die Protokollierung muss stichpunktartig überprüft werden.
BSI‑102.S 4	Planung SOLL	Die Protokollierung sollte schrittweise, basierend auf Risiko-Analyse und der kritischen Dienstleistung, geplant werden. Systeme sollten gruppiert werden.
BSI-103 3	Protokollierung System, Netze, Daten, Infrastruktur (OPS.1.1.5)	Zur Angriffserkennung notwendige Daten auf System- und Netzebene müssen gespeichert und zur Auswertung bereitgestellt werden. Sicherheitsrelevante Ereignisse von IT und Anwendungen müssen protokolliert werden. Dafür müssen systemeigene Funktionen oder separate Systeme genutzt und Vorgaben eingehalten werden. Die gesammelten Daten müssen gefiltert, normalisiert, aggregiert, korreliert und verfügbar gemacht. Protokolldaten müssen vor Manipulation geschützt und nach bestimmten Fristen gelöscht werden. Bei großen Verbünden müssen die Daten an für den Netzbereich zentralen (Logging-)Stellen gespeichert werden. Die Systemzeit der protokollierenden Systeme und Anwendungen muss synchron sein. Für Systeme ohne eigene Protokollierungs-Funktion muss dies von Systemen auf Netzebene übernommen werden. Gesetzliche und regulatorische Anforderungen, inklusive Bundes- und Landesdatenschutz (ggf. Anonymisierung oder Pseudonymisierung) und ggf. branchenspezifische Regulierung, an die Protokollierung müssen eingehalten werden, ebenso Persönlichkeits- und Mitbestimmungsrechte. Die Logging-Infrastruktur muss ausreichend mit personellen, technischen und finanziellen Ressourcen dimensioniert und budgetiert werden.
BSI‑103.S 4/5	Sichtbarkeit, Infrastruktur SOLL	Log-Quellen sollten zur Erkennung von Angriffen im Geltungsbereich wie folgt erschlossen werden: Außen nach innen: von Netz-Grenzen zu inneren Bereichen Systeme: zuerst kritische und zentrale Systeme zur Steuerung, Leitsysteme etc. Priorisierung basierend auf der Kritikalität der Systeme [siehe BCM] Die Zahl zentraler Logging-Stellen sollte möglichst gering gehalten werden.

Erkennung (SZA-D)

Anforderungen zur geregelten, automatisierten Detektion von Cyberangriffen durch Systeme und Mechanismen. Schwerpunkt liegt auf kontinuierlicher Überwachung zentraler Punkte und Netzübergänge.

KRITIS SzA Erkennung MUSS/SOLL, eigene Zusammenstellung, Draft 20241024
BSI KRITIS KdA	Thema	Anforderung
BSI‑104 3/5	Bedrohungen und Risiken	Relevante Bedrohungen müssen durch Detektion umfassend und effizient abgedeckt werden, wozu die Risikoanalyse und Größe und Struktur des Betreibers einbezogen werden muss.
BSI‑105 3	Richtlinie Detektion (DER.1.A1)	Die Detektion von Sicherheitsvorfällen muss in einer Richtlinie definiert werden. Dort muss die sichere Planung, Aufbau und Betrieb von Detektion beschrieben werden. Die Richtlinie muss allen Mitarbeitern in der Detektion bekannt und die Umsetzung regelmäßig überprüft, Abweichungen mit dem ISO/ISB abgestimmt werden. Für die relevanten IT-Systeme müssen für Detektion Verantwortliche festgelegt sein, die die Einhaltung der Richtlinie sicherstellen.
BSI‑106 3	Regulierung Detektion (tw. DER.1.A2)	Gesetzliche und regulatorische Anforderungen, inklusive Bundes- und Landesdatenschutz, müssen bei der Auswertung von Protokollierung eingehalten werden, ebenso Persönlichkeits- und Mitbestimmungsrechte, TMG, TKG etc.
BSI‑107 3	Meldewege Detektion (DER.1.A3)	Melde- und Alarmierungswege müssen dokumentiert, eingerichtet und bekannt sein, inklusive der relevanten Stellen und Meldewege, Dringlichkeiten, Aufgaben und Prozesse. Die Verantwortlichen müssen die eigene Rolle in den Alarmierungs- und Meldeprozessen kennen.
BSI‑107.S 4	Überprüfung Meldewege (DER.1.A3)	Die Meldewege sollten regelmäßig geprüft, aktualisiert und erprobt werden.
BSI‑108 3	Awareness (DER.1.A4)	Mitarbeitern müssen für Ereignisse sensibilisiert werden. Der allgemeine Meldeprozess, Umgang mit sicherheitsrelevanten Ereignissen und korrektem Verhalten in der Meldung ans Incident Management und von Sicherheitsvorfällen muss bekannt sein.
BSI‑109 3	Systemfunktionen (DER.1.A5)	Vorhandene Funktionen zur Detektion von Systemen und Anwendungen müssen genutzt und ausgewertet werden. Bei einem sicherheitsrelevanten Vorfall müssen Meldungen und protokollierte Ereignisse ausgewertet werden.
BSI‑109.S 4	Kontrolle Meldungen (DER.1.A5)	Gesammelte Meldungen sollten stichpunktartig kontrolliert werden.
BSI‑110 3/5	Kontinuierliche Überwachung	Protokolldaten müssen kontinuierlich überwacht und ausgewertet werden. Dazu müssen eigene Mitarbeiter oder Mitarbeiter von Dienstleistern benannt werden, die in einer der Risikoanalyse angemessenen Zeitspanne reagieren. Manuelle, aktive Prozesse durch Mitarbeiter (inkl. Kontrolle und Test) und Aufgaben müssen in Verfahrensanleitungen dokumentiert sein.
BSI‑111 3	Schadcode Netze, IDS (mit DER.1)	Es müssen Schadcodedetektionssysteme und ggf. zusätzlich auf zentralen Systemen Schadcodescanner eingesetzt werden. Auf diese muss zentraler Zugriff möglich sein, Meldungen müssen ausgewertet und untersucht werden. Netzsegmente müssen durch zusätzliche Detektionssysteme geschützt werden, Netzübergänge durch netzbasierte IDS (NIDS), jeweils anhand des Netzstrukturplans.
BSI‑112 3	Korrelation und Signaturen	Protokolldaten müssen regelmäßig auf Auffälligkeiten kontrolliert werden. Die Signaturen der Detektionssysteme müssen aktuell und synchron gehalten werden.
BSI‑112.S 3	Korrelation SOLL	Protokoll- und Logging-Daten sollten zur Korrelation zeitlich synchronisiert werden (sein).
BSI‑113 3	Externe Quellen	Erkenntnisse und Meldungen externen Quellen müssen herangezogen werden, grundsätzlich ausgewertet und bewertet, und bei Relevanz an die richtigen Stellen weitergeleitet werden. Bei Relevanz muss entsprechend eskaliert werden.
BSI‑114 3	Personal Detektion	Es müssen genug personelle Ressourcen für die Detektion bereitgestellt werden. Für die Auswertung müssen Mitarbeiter oder Dienstleister beauftragt werden, ein Personenkreis muss ausschließlich für Angriffserkennung benannt werden.
BSI‑114.S 4	Personal Detektion SOLL	Detektion sollte die überwiegende oder höherpriorisierte Aufgabe des Personals sein. Das Personal sollte spezialisierte Schulungen erhalten.
BSI‑115 3	Zentral und dauerhaft	Zur Erkennung und Auswertung müssen zentrale Komponenten eingesetzt werden. Sicherheitsrelevante Vorgänge müssen mit zentralen automatisierten Analysen erkannt werden. Protokolldaten müssen lückenlos einsehbar und auswertbar sein, die Daten möglichst permanent ausgewertet werden. Systemverantwortliche müssen Analyseparameter auditieren und anpassen, Protokolldaten müssen regelmäßig automatisch auf sicherheitsrelevante Ereignisse überprüft werden. Bei Überschreiten von Schwellenwerten (und Regeln) muss automatisch alarmiert werden, das zuständige Personal dann die Reaktion einleiten.
BSI‑116 3	Sicherheitsrelevante Ereignisse	Informationen zu Schwachstellen und Angriffsmustern für die eingesetzten Systeme müssen für die Detektion fortlaufend eingeholt werden. Im Schwachstellen-Management müssen dazu fortlaufend Meldungen relevanter Stellen und Hersteller eingeholt werden und in Prozesse einfließen. Sicherheitsrelevante Ereignisse (SRE) müssen bewertet werden, ob sie einen Vorfall darstellen. Detektionsmechanismen müssen daraufhin nachjustiert werden.
BSI‑116.S 4	Sicherheitsrelevante Ereignisse SOLL	Vor der Umsetzung und bei wichtigen Änderungen im Geltungsbereich sollte eine Kalibrierung der Detektion und Baselining der auftretenden Ereignisse vorgenommen werden. Die Zahl von False Positives im Normalbetrieb sollte überprüft bewertet werden. Die Detektionssysteme sollten in eindeutigen Fällen SREs automatisch qualifizieren können – andernfalls manuell durch festgelegte Verantwortliche.

Reaktion (SZA-R)

Umfangreiche organisatorische Anforderungen zur Reaktion auf Vorfälle mit definierten Vorgaben, Prozessen, Verantwortlichkeiten und Abläufen in der Wiederherstellung.

KRITIS SzA Reaktion MUSS/SOLL, eigene Zusammenstellung, Draft 20241024
BSI KRITIS KdA	Thema	Anforderung
BSI‑117 3	Sicherheitsvorfall (DER.2.1.A1)	Sicherheitsvorfälle müssen klar definiert und vom Regelbetrieb abgegrenzt sein. Die Definition muss den relevanten Mitarbeitern bekannt sein.
BSI‑117.S 4	Umgang mit Vorfällen (DER.2.1) SOLL	Es sollte ein einheitliches Verfahren zur Einstufung von Sicherheitsvorfällen und Störungen geben, abgestimmt mit ISMS und Incident Management. In der Vorfallsbehandlung sollten die Auswirkungen abgeschätzt und entschieden werden, ob Aufklärung oder Eindämmung Priorität hat; im Vorfeld sollten Worst Case Szenarien analysiert werden.
BSI‑118 3	Richtlinie Reaktion (DER.2.1.A2)	Die Behandlung von Sicherheitsvorfällen muss in einer Richtlinie definiert werden. Dort müssen Zweck, Ziele und Verhaltensregeln für die Arten von Sicherheitsvorfällen und für verschiedene Zielgruppen festgelegt werden. Die Richtlinie muss allen Mitarbeitern bekannt, von den relevanten Stellen freigegeben sein und regelmäßig überprüft werden.
BSI‑118.S 4	Schnittstellen (DER.2.1.A2) SOLL	Schnittstellen zu anderen Managementsysteme wie IT-Notfallmanagement sollten etabliert sein.
BSI‑119 3	Verantwortlichkeiten Reaktion (DER.2.1.A3)	Rollen und Verantwortlichkeiten für Sicherheitsvorfälle müssen definiert sein, relevante Mitarbeiter müssen über ihre Aufgaben unterrichtet werden. Ansprechpartner, Regeln, Entscheidungen und Kontaktinformationen müssen festgelegt sein.
BSI‑120 3	Benachrichtigungen (DER.2.1.A4)	Relevante interne und externe Stellen müssen über Sicherheitsvorfälle informiert werden, inklusive Behörden, Datenschutzbeauftragte, Rechtsabteilung, Mitbestimmung usw. Ebenso müssen mögliche Maßnahmen kommuniziert werden.
BSI‑121 3	Behebung (DER.2.1.A5)	Die Behebung des Sicherheitsvorfalls muss im IT-Betrieb nach festgelegten Schritte erfolgen. Nach Finden des Problems und der Ursache müssen geeignete Maßnahmen ausgewählt und nach Freigabe durch die IT umgesetzt werden, um die Ursache zu Beheben. Es müssen sichere Kommunikationsverfahren und Listen interner und externer Experten bestehen.
BSI‑122 3	Wiederherstellung (DER.2.1.A6)	Nach einem Sicherheitsvorfalls müssen betroffene Systeme vom Netz genommen, Daten gesichert und Hard- und Software auf Veränderungen untersucht werden. Die Wiederherstellung muss dann festgelegten Schritten folgen — Restore von Originaldaten, Konfigurationen und Patches, die nicht vom Vorfall betroffen waren. Zugangsdaten müssen geändert, Nutzer in Funktionstest eingebunden werden.
BSI‑122.S 4	Penetrationstests (DER.2.1.A6) SOLL	Komponenten sollten nach einem Angriff vor der Wiederinbetriebnahme einem Penetrationstest unterzogen werden
BSI‑123 4	Vorgehensweise (DER.2.1.A7) SOLL	Es sollte eine definierte Vorgehensweise zur Behandlung von Sicherheitsvorfällen geben — mit Prozessen, Vorgaben und Abläufen. Die Vorgehensweise muss allen Beteiligten zugänglich, von der Leitungsebene freigegeben sein und regelmäßig überprüft und angepasst werden.
BSI‑124 4	Organisationsstruktur (DER.2.1.A8) SOLL	Es sollten geeignete Organisationsstrukturen für den Umgang festgelegt werden, mit Team, geeigneten Mitgliedern und Überprüfung.
BSI‑125 4	Meldewegen (DER.2.1.A9) SOLL	Passende Meldewegen für Arten von Vorfällen sollten aufgebaut und kommuniziert werden. Dazu sollte es eine Kommunikations- und Kontaktstrategie geben mit Festlegungen, wer meldeberechtigt ist.
BSI‑126 4	Eindämmen SOLL	Es sollte entschieden werden, ob der Vorfall eingedämmt oder aufgeklärt wird, dazu sollten Informationen und Worst Case Szenarien vorliegen.
BSI‑127 4	Einstufung SOLL	Sicherheitsvorfälle sollten nach einem einheitlichen Verfahren eingestuft werden, das zwischen ISMS und Incident Management abgestimmt ist.
BSI‑128 4	Schnittstellen SOLL	Schnittstellen zwischen Störungsbehebung, Notfallmanagement und ISMS sollten analysiert werden, ebenso gemeinsame Ressourcen. Relevante Mitarbeiter im Betrieb, Service Desk und Fehlerbehebung sollten sensibilisiert werden. Das ISMS sollte lesenden Zugriff auf Incident Management Tools haben.
BSI‑129 4	Einbindung SOLL	Behandlung von Sicherheitsvorfällen sollten mit dem Notfallmanagement abgestimmt sein, ggf. auch mit Störungs- und Fehlerbehebung.
BSI‑130 4	Eskalation (DER.2.1) SOLL	Eine Eskalationsstrategie sollte Anweisungen für Sicherheitsvorfälle festlegen, mit ISMS und Störungsmanagement abgestimmt: Einbindung interessierter Parteien, zu ergreifende Maßnahmen, Auswahl geeigneter (und bei Notfällen erreichbarer) Tools und Eskalationswege. Die Strategie sollte regelmäßig überprüft, geübt und aktualisiert werden.
BSI‑131 4	Schulungen SOLL	Mitarbeitern im Service Design sollten Hilfsmittel zur Verfügung stehen, sie sollten geschult sein und Schutzbedarfe der IT-Systeme kennen.
BSI‑132 4	Dokumentation SOLL	Behebung sollte nach einem standardisierten Verfahren dokumentiert werden, die Berichte sollten vertraulich sein. Die Dokumentation sollte vor (formellem) Abschluss des Vorfalls in entsprechenden Systemen gepflegt werden, nach Kriterien abgestimmt mit dem ISB.
BSI‑133 4	Nachbereitung SOLL	Die Behebung und Reaktion sollte standardisiert ausgewertet werden (Lessons Learned), Maßnahmen und Meldewege bewertet und Handlungsanweisungen aus Erfahrungen erstellt und kommuniziert werden. Die Leitungsebene sollte über Vorfälle unterrichtet werden.
BSI‑134 4	Weiterentwicklung SOLL	Nach der Analyse von Sicherheitsvorfällen sollten Prozesse und Abläufe ggf. weiterentwickelt werden und auch neue Entwicklungen im Incident Management und Forensik geprüft werden, Hilfsmittel sollten überprüft und aktualisiert werden.
BSI‑135 3	Automatische Reaktion	Detektionssysteme müssen sicherheitsrelevante Ereignisse automatisch melden und in Netzen wenn möglich automatisch reagieren, wenn die kDL nicht gefährdet wird. Dabei muss automatisch in Datenströme eingegriffen werden können, um Sicherheitsvorfälle zu unterbinden, oder alternativ über manuelle Prozesse. Sicherheitsvorfälle im vermeintlichen Zusammenhang mit Angriffen müssen behandelt werden. Vorfälle im Zusammenhang mit Angriffen müssen an die zuständigen Behörden gemeldet werden.
BSI‑135.S 4	Auswertung (DER.2.1) SOLL	Sicherheitsvorfälle sollten standardisiert protokolliert und dokumentiert werden. Anforderungen an QS, Vertraulichkeit und ggf. ein DMS sollten berücksichtigt werden.

Das OH SzA-Mapping zu ISO 27001, C5 und KRITIS ist in einem eigenen Artikel.

Umsetzung

Umsetzungsgrad (Reifegrad)

In Prüfungen muss Reifegrad der Systeme zur Angriffserkennung von KRITIS-Prüfern untersucht und in einer Skala von 0 bis 5 in den Nachweisformularen bewertet werden (RUN).

Grad	Umsetzung
0	Keine Maßnahmen umgesetzt, keine Pläne vorhanden
1	Planungen vorhanden, jedoch noch keine konkrete Umsetzung
2	Umsetzung wurde in allen Bereichen begonnen, jedoch noch nicht erfüllt
3	Alle MUSS-Anforderungen umgesetzt, KVP umgesetzt oder in Planung
4	Alle MUSS-Anforderungen umgesetzt, alle SOLL-Anforderungen umgesetzt oder stichhaltig begründet ausgeschlossen, KVP etabliert
5	Alle MUSS, SOLL und KANN-Anforderungen umgesetzt oder stichhaltig begründet ausgeschlossen. Sinnvolle zusätzliche Maßnahmen wurden umgesetzt, KVP etabliert.

Prüfung und Nachweise

Das Mindestniveau ist Reifegrad 3 (UG3), grundsätzlich sollten Betreiber jedoch Reifegrad 4 (MUSS und SOLL) erreichen, um den Nachweis nach §8a (1a) BSIG zu erbringen. Nachweise müssen Aussagen zum Einsatz von Systemen zur Angriffserkennung enthalten:

Nachweisdokument P, Umsetzungsgrad SzA PE.3
Mängelliste

Weitere Informationen

Literatur

Orientierungshilfe Angriffserkennung OH SzA, OpenKRITIS Briefing, Webinar Oktober 2022
OpenKRITIS-Mapping Orientierungshilfe Angriffserkennung zu KRITIS, C5 und ISO 27001, OpenKRITIS, Oktober 2022
Fragen und Antworten zum Einsatz von Systemen zur Angriffserkennung, Webseite des BSI, Bundesamt für Sicherheit in der Informationstechnik, o.D.
Kritische Infrastrukturen und weitere meldepflichtige Unternehmen: Einen Vorfall bewältigen, Webseite des BSI, Bundesamt für Sicherheit in der Informationstechnik
BSI veröffentlicht Orientierungshilfe zum Einsatz von Systemen zur Angriffserkennung, Pressemeldung, Bundesamt für Sicherheit in der Informationstechnik, September 2022

Quellen

Konkretisierung der KRITIS-Anforderungen (§ 8a Absatz 1 und Absatz 1a BSIG), OH SzA, Bundesamt für Sicherheit in der Informationstechnik, September 2024
Orientierungshilfe zum Einsatz von Systemen zur Angriffserkennung (PDF), OH SzA, Bundesamt für Sicherheit in der Informationstechnik, September 2022
IT-Grundschutz-Baustein (200-1): DER.1: Detektion von sicherheitsrelevanten Ereignissen, Bundesamt für Sicherheit in der Informationstechnik, Februar 2021
IT-Grundschutz-Baustein (200-1): DER.2.1: Behandlung von Sicherheitsvorfällen, Bundesamt für Sicherheit in der Informationstechnik, Februar 2021