Orientierungshilfe OH SzA

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.

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.

Diese Seite fasst die OH SzA aus OpenKRITIS-Sicht zusammen. Bei der Umsetzung hilft das Mapping auf ISO 27001 und C5. Mit NIS2 bleiben die SzA-Anforderungen in §31 (2) erhalten.

Orientierungshilfe Angriffserkennung OH SzA

Austausch zu neuen BSI-Anforderungen für Angriffserkennung
Webinar ∙ CSK-Summit <kes> Keynote ∙ Mai 2023

Mapping Angriffserkennung auf Standards

Abgleich OH SzA auf BSI KRITIS, C5, ISO 27001
PDF ∙ OpenKRITIS-Analyse Angriffserkennung ∙ Juni 2023

Angriffserkennung KRITIS

Einleitung

Die folgenden Abschnitte fassen die Anforderungen der OH SzA aus OpenKRITIS-Sicht in sinnvolle Gruppen zusammen und konsolidieren die Texte und Struktur.

Alle MUSS-Anforderungen — ab dem ersten Prüfzyklus verbindlich
Referenzierte Anforderungen der BSI IT-Grundschutz-Bausteine (OPS und DER)
Alle SOLL-Anforderungen [Draft!] — ab dem zweiten Prüfzyklus verbindlich
Gruppiert in Allgemein (A), Governance (G), Protokollierung (P), Detektion (D), Reaktion (R)
Eindeutige IDs der Anforderungen; das Suffix .S für SOLL-Anforderungen

NIS2 ab 2024

Die Orientierungshilfe OH SzA konkretisiert die Anforderungen aus Sicht des BSI für §8a (1a) BSIG im IT-Sicherheitsgesetz 2.0. Mit der NIS2-Umsetzung ab 2024 bleiben die dedizierten SzA-Anforderungen für Betreiber kritischer Anlagen bestehen, in §31 (2) BSIG-E (NIS2UmsuCG).

Allgemein (SZA-A)

Ü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 2022/10/19
ID	Thema	Anforderung
A1	Rahmenbedingungen	Die für Angriffserkennung notwendige Technologie, Organisation und Personal muss vorhanden sein.
A2	Angriffsmuster	Informationen zu Schwachstellen eingesetzter Systeme und zu Angriffen müssen eingeholt werden.
A3	Plattform	Die zur Angriffserkennung notwendige Hardware und Software muss auf dem aktuellen Stand sein.
A4	Signaturen	Die Signaturen zur Detektion müssen aktuell gehalten werden.
A5	Konfiguration	Systeme müssen so konfiguriert werden, dass bekannte Möglichkeiten der Schwachstellenerkennung genutzt werden.

Governance (SZA-G)

Übergreifende Anforderungen zur Steuerung von Angriffserkennung in allen Phasen — von Vorgaben, Organisation und Verantwortlichkeiten bis zu Meldewegen und Compliance. Diese Anforderungen (G) sind in der OH SzA über alle Phasen verstreut und hier zusammengefasst.

Richtlinien

Angriffserkennung MUSS-Kriterien Richtlinien, eigene Zusammenstellung, Stand 2022/10/19
ID	Thema	Anforderung
G1	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.
G2	Richtlinie Detektion (DER.1)	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.
G3	Richtlinie Reaktion (DER.2.1)	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.
G3.S	Vorgehensweise (DER.2.1) 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.v

Verantwortlichkeiten und Ressourcen

Angriffserkennung MUSS/SOLL-Kriterien Governance, eigene Zusammenstellung, Stand 2022/11/08
ID	Thema	Anforderung
G4	Verantwortlichkeiten Detektion (DER.1)	Für die relevanten IT-Systeme müssen für Detektion Verantwortliche festgelegt sein, die die Einhaltung der Richtlinie sicherstellen.
G5	Ressourcen Protokollierung	Die Logging-Infrastruktur muss ausreichend mit personellen, technischen und finanziellen Ressourcen dimensioniert und budgetiert werden.
G6	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.
G6.S	Personal Detektion SOLL	Detektion sollte die überwiegende oder höherpriorisierte Aufgabe des Personals sein. Das Personal sollte spezialisierte Schulungen erhalten.
G7	Verantwortlichkeiten Reaktion	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.
G7.S	Organisation Reaktion (DER.2.1) SOLL	Zur Vorfallsbehandlung sollte es geeignete Strukturen geben: Dediziertes Team für Sicherheitsvorfälle, mit klarer Benennung bei nur anlassbezogenem Zusammentreten und regelmäßiger Überprüfung. Schnittstellen zwischen Incident, Problem, Notfall- und Sicherheitsmanagement sollten eingerichtet, analysiert und eingebunden sein. Ressourcen sollten ggf. gemeinsam genutzt werden.

Kommunikation

Angriffserkennung MUSS/SOLL-Kriterien Meldewege, eigene Zusammenstellung, Stand 2022/11/08
ID	Thema	Anforderung
G8	Meldewege Detektion (DER.1)	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.
G9	Awareness (DER.1)	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.
G9.S	Einbindung Vorfälle (DER.2.1) SOLL	Relevante Mitarbeiter im Betrieb, Service Desk und Fehlerbehebung sollten für Sicherheitsvorfälle und die notwendigen Handlungen sensibilisiert werden. Das Sicherheitsmanagement (ISMS?) sollte lesenden Zugriff auf Incident Management Tools haben.
G10	Benachrichtigungen (DER.2.1)	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.
G10.S	Kommunikation (DER.2.1) SOLL	Für Sicherheitsvorfälle sollten Meldewege und Kommunikationskanäle für Mitarbeiter aufgebaut werden. Zentrale Stellen dafür sollten an alle Mitarbeiter kommuniziert werden. Eine Kommunikationsstrategie sollte relevante Parteien, Reihenfolgen, Meldestufen und den Umgang mit Meldungen an Externe regeln.
G11	Meldungen	Vorfälle im Zusammenhang mit Angriffen müssen an die zuständigen Behörden gemeldet werden.

Regulatorik

Angriffserkennung MUSS-Kriterien Regulatorik, eigene Zusammenstellung, Stand 2022/10/19
ID	Thema	Anforderung
G12	Regulierung Protokollierung (tw. OPS.1.1.5)	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.
G13	Regulierung Detektion (tw. DER.1)	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.
G14	Branchenstandards	Weitergehende branchenspezifische Anforderungen an Protokollierung, Detektion und Reaktion müssen ebenfalls umgesetzt 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.

Angriffserkennung Protokollierung MUSS/SOLL-Kriterien, eigene Zusammenstellung
mit Basis-Anforderungen aus OPS.1.1.5, Stand 2022/11/08
ID	Thema	Anforderung
P1	Protokolldaten (tw. 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.
P2	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.
P2.S	Planung SOLL	Die Protokollierung sollte schrittweise, basierend auf Risiko-Analyse und der kritischen Dienstleistung, geplant werden. Systeme sollten gruppiert werden.
P3	Überprüfung	Die Protokollierung muss stichpunktartig überprüft werden.
P4	Geltungsbereich	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.
P4.S	Sichtbarkeit 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 – erst kritische und zentrale Systeme zur Steuerung, Leitsysteme etc. Priorisierung basierend auf der Kritikalität der Systeme [siehe BCM]
P5	Infrastruktur (tw. OPS.1.1.5)	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.
P5.S	Infrastruktur SOLL	Wenn keine Protokollierung mit bestehenden Systemen möglich ist, sollte die Infrastruktur angepasst oder um zusätzliche Maßnahmen ergänzt werden, um Detektion und Reaktion sicherstellen zu können. 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.

Angriffserkennung Erkennung MUSS/SOLL-Kriterien OH SzA, eigene Zusammenstellung
mit Basis-Anforderungen aus DER.1, Stand 2022/11/08
ID	Thema	Anforderung
D1	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.
D2	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.
D3	Systemfunktionen (DER.1)	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.
D4	Schadcode (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.
D5	Netze und IDS	Netzsegmente müssen durch zusätzliche Detektionssysteme geschützt werden, Netzübergänge durch netzbasierte IDS (NIDS), jeweils anhand des Netzstrukturplans.
D6	Korrelation und Signaturen	Protokolldaten müssen regelmäßig auf Auffälligkeiten kontrolliert werden. Die Signaturen der Detektionssysteme müssen aktuell und synchron gehalten werden.
D6.S	Korrelation SOLL	Protokoll- und Logging-Daten sollten zur Korrelation zeitlich synchronisiert werden (sein).
D7	Zentrale Detektion	Zur Erkennung und Auswertung müssen zentrale Komponenten eingesetzt werden. Sicherheitsrelevante Vorgänge müssen mit zentralen automatisierten Analysen erkannt werden.
D8	Dauerhafte Auswertung	Protokolldaten müssen lückenlos einsehbar und auswertbar sein, die Daten müssen möglichst permanent ausgewertet werden.
D9	Manuelle Verfahren	Manuelle, aktive Prozesse durch Mitarbeiter (inkl. Kontrolle und Test) und Aufgaben müssen in Verfahrensanleitungen dokumentiert sein.
D10	Automatische Alarmierung	Bei Überschreiten von Schwellenwerten (und Regeln) muss automatisch alarmiert werden, das zuständige Personal dann die Reaktion einleiten.
D10.S	Qualifikation von Vorfällen SOLL	Die Detektionssysteme sollten in eindeutigen Fällen SREs automatisch qualifizieren können – andernfalls durch festgelegte Verantwortliche. Nur qualifizierte SREs sollten den Reaktionsprozess auslösen.
D11	Überprüfung	Systemverantwortliche müssen die Analyseparameter auditieren und anpassen, Protokolldaten müssen regelmäßig automatisch auf sicherheitsrelevante Ereignisse überprüft werden.
D12	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.
D13	Angriffsmuster	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.
D14	Sicherheitsrelevante Ereignisse	Sicherheitsrelevante Ereignisse (SRE) müssen bewertet werden, ob sie einen Vorfall darstellen. Detektionsmechanismen müssen daraufhin nachjustiert werden.
D14.S	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.

Reaktion (SZA-R)

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

Angriffserkennung Reaktion MUSS/SOLL-Kriterien, eigene Zusammenstellung
mit Basis-Anforderungen aus DER.2.1, Stand 2022/11/08
ID	Thema	Anforderung
R1	Sicherheitsvorfall (DER.2.1)	Sicherheitsvorfälle müssen klar definiert und vom Regelbetrieb abgegrenzt sein. Die Definition muss den relevanten Mitarbeitern bekannt sein.
R1.S	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.
R2	Behebung (DER.2.1)	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.
R2.S	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.
R3	Wiederherstellung (DER.2.1)	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.
R4	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.
R5	Behandlung Angriffe	Sicherheitsvorfälle im vermeintlichen Zusammenhang mit Angriffen müssen behandelt werden.
R5.S	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. 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.

Umsetzungsgrad (Reifegrad)

In Prüfungen muss der Grad der Umsetzung (Reifegrad) die Systeme zur Angriffserkennung von KRITIS-Prüfern untersucht werden. Die Umsetzung wird in einer Skala von 0 bis 5 in den Nachweisformularen bewertet. Ab 2023 ist erst Reifegrad 3, dann 4 verbindlich.

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.

Betreiber sollten laut OH SzA grundsätzlich Reifegrad 4 (MUSS und SOLL) erreichen, um den Nachweis nach §8a (1a) BSIG zu erbringen, Abweichungen sind nur begründet zulässig. Im ersten Prüfzyklus ab 2023 ist nach der OH SzA aber noch Reifegrad 3 (MUSS) erlaubt.

Das oben skizzierte, jetzt umbenannte Reifegrad-Modell nach MUSS/SOLL/KANN ist unüblich und weicht von dem bestehenden ISMS/BCMS-Modell der Nachweisformulare leider ab.

Prüfung und Nachweise

Die oben genannten Anforderungen der Orientierungshilfe sind für Nachweise ab dem 1. Mai 2023 für Betreiber normativ. Nachweise ab diesem Stichtag müssen Aussagen zum Einsatz von Systemen zur Angriffserkennung enthalten.

Nachweisdokumente

Die Umsetzung nach §8a (1a) BSIG muss ab dem 1. Mai 2023 in KRITIS-Prüfungen in erweiterten Nachweisdokumenten belegt werden:

Nachweisdokument P, Umsetzungsgrad SzA PE.3
Mängelliste

Die aktualisierten Dokumente wurden Ende Oktober 2022 veröffentlicht.

Einbettung in KRITIS-Prüfungen

Die Anforderungen der Orientierungshilfe für Angriffserkennung (OH SzA) könnten in die BSI-Anforderungen für Angriffserkennung in KRITIS-Prüfungen wie folgt eingeordnet werden.

Einbettung OH SzA in KRITIS-Prüfungen, eigene Zusammenstellung, Stand 2022/10/19
Bereich	BSI-ID	Anforderung
Governance	77-79, 81-82	Prozesse und Verantwortlichkeiten für Sicherheitsvorfälle
	SZA-A	OH SzA A1 bis A5: Allgemeine Anforderungen und Rahmen
	SZA-G	OH SzA G1 bis G14: Governance
	SZA-D	OH SzA D1 bis D14: Erkennung (Detektion)
	SZA-R	OH SzA R1 bis R5: Reaktion
Systeme und Auswertung	80, 90-94	Systeme und Methoden zur systematischen Auswertung
	SZA-P	OH SzA P1 bis P5: Protokollierung
Tests und Schwachstellen	95-96	Regelmäßige Penetrationstests und Umgang mit Schwachstellen

Die Gruppen (SZA-A, SZA-G, ...) sind damit fünf Zusatzkontrollen, die zusätzlich zu den Hundert BSI-Anforderungen geprüft werden können. Die einzelnen Anforderungen der OH SzA (A1, R4, ...) wären dann die Prüfschritte dieser Zusatzkontrollen (Gruppen). Dopplungen lassen sich so nicht ausschließen, eine genauere aber komplexere Zuordnung folgt unten.

Mapping auf C5 und ISO 27001

Das OpenKRITIS-Mapping Angriffserkennung (PDF) ordnet MUSS-Anforderungen der OH SzA Kontrollen anderer Security Standards zu: BSI KRITIS, C5:2020 und ISO 27001/27002.

Die Zuordnungen sind nicht 1:1 deckungsgleich — die OH SzA Anforderungen werden von den BSI/C5/ISO-Kontrollen nicht immer vollständig umgesetzt. Die Anforderungen könnten als Teil der Kontrollen implementiert oder geprüft werden, müssten den Kontrollumfang dafür meist anpassen, wobei Lücken verbleiben. Die SOLL-Anforderungen werden noch ergänzt.

Angriffserkennung OH SzA Zuordnung C5:2020 und ISO 27002:2021, eigene Zusammenstellung, Stand 2022/12/13, PDF-Version
OH SzA	Thema	BSI KRITIS	C5:2020	ISO 27001 2022
SZA-A	Allgemeine Anforderungen
A1	Rahmenbedingungen	BSI-2 BSI-17	OIS-02 OIS-01 BCM-01	A.5.2 A.5.24 4-10 A.5.31
A2	Angriffsmuster	BSI-96 BSI-21 BSI-97	OPS-20 OPS-05 OIS-05	A.8.8 A.5.7
A3	Plattform	BSI-25	OPS-23	A.8.19 A.8.8
A4	Signaturen	BSI-21	OPS-05	A.8.7
A5	Konfiguration	BSI-93 BSI-91	OPS-15 OPS-13	A.8.9
SZA-G	Governance
G1	Richtlinie Protokollierung	BSI-2 BSI-66 BSI-87	OIS-02 SP-02 COM-03	A.5.1 A.5.24
G2	Richtlinie Detektion	BSI-2 BSI-66 BSI-77 BSI-87	OIS-02 SP-02 SIM-01 COM-03	A.5.1 A.5.24
G3	Richtlinie Reaktion	BSI-2 BSI-66 BSI-77 BSI-87	OIS-02 SP-02 SIM-01 COM-03	A.5.1 A.5.24
G4	Verantwortlichkeiten Detektion	BSI-77	SIM-01	A.5.24
G5	Ressourcen Protokollierung	BSI-20	OPS-01	A.8.6 7.1
G6	Personal Detektion	BSI-20 BSI-78	OPS-01 SIM-02	A.8.6 7.1 A.5.26
G7	Verantwortlichkeiten Reaktion	BSI-17 BSI-77	BCM-01 SIM-01	A.5.24 A.5.29
G8	Meldewege	BSI-81	SIM-04	A.6.8
G9	Awareness	BSI-68 BSI-82	HR-03 SIM-05	A.6.3 A.5.27 7.3
G10	Benachrichtigungen	BSI-100	OIS-05	A.5.5 5.31
G11	Meldungen	BSI-100	OIS-05	A.5.5
G12	Regulierung Protokollierung	BSI-85	COM-01	A.5.31 A.5.34 A.5.33
G13	Regulierung Detektion	BSI-85	COM-01	A.5.31 A.5.34 A.5.33
G14	Branchenstandards	BSI-16	OIS-01	A.5.31
SZA-P	Protokollierung und Logging
P1	Daten und Ereignisse	BSI-36 BSI-37	COS-01 OPS-10 OPS-12 OPS-14	A.8.20 A.8.16
P2	Planung	BSI-20 BSI-90	OPS-01 OPS-10	A.8.6
P3	Überprüfung	BSI-87 BSI-88	COM-02 COM-03	A.5.36
P4	Geltungsbereich	BSI-1 BSI-91 BSI-45	OIS-01 OPS-10 DEV-03	ISMS 4.2
P5	Infrastruktur	BSI-80	SIM-05 COS-01	A.8.15
SZA-D	Erkennung (Detektion)
D1	Bedrohungen und Risiken	BSI-14	OIS-07	8.2 8.3
D2	Kontinuierliche Überwachung	BSI-90	OPS-13	A.8.16
D3	Systemfunktionen	BSI-36 BSI-91	COS-01 OPS-13	A.8.26 A.8.27 A.8.15
D4	Schadcode	BSI-21	OPS-04 OPS-05	A.8.7
D5	Netze und IDS	BSI-36 BSI-37	COS-01 COS-02 COS-03	A.8.20 A.8.21 A.8.23
D6	Korrelation und Signaturen	BSI-80 BSI-21 SZA-A4	SIM-05 OPS-05	A.6.8
D7	Zentrale Detektion	BSI-80	COS-01 SIM-05	A.6.8
D8	Dauerhafte Auswertung	BSI-91	OPS-13	A.8.16
D9	Manuelle Verfahren	BSI-90 BSI-77	OPS-10	A.5.24
D10	Automatische Alarmierung	BSI-91 BSI-80	OPS-13 SIM-05	A.8.16
D11	Überprüfung	BSI-91	OPS-13	A.8.16
D12	Externe Quellen	BSI-97	OIS-05	A.5.5 A.5.6
D13	Angriffsmuster	BSI-96 BSI-07	OPS-20 OIS-05	A.5.7
D14	Sicherheitsrelevante Ereignisse	BSI-78 BSI-82	SIM-02 SIM-05	A.5.26 A.5.27
SZA-R	Reaktion und Wiederherstellung
R1	Definition	BSI-77	SIM-01	A.5.24 A.5.25
R2	Behebung	BSI-77 BSI-78	SIM-01 SIM-02	A.5.24 A.5.25 A.5.26
R3	Wiederherstellung	BSI-18	BCM-03	A.5.30
R4	Automatische Reaktion	BSI-36	COS-01 COS-02	A.8.21 A.8.22
R5	Behandlung Angriffe	BSI-78	SIM-02	A.5.26

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

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