Orientierungshilfe Systeme zur Angriffserkennung (OH SzA)

Für die Erkennung von Cyberangriffen legt das BSI in der Orientierungshilfe für Systeme zur Angriffserkennung (OH SzA) verbindliche Vorgaben für KRITIS-Betreiber fest. Die Orientierungshilfe definiert ab 2023 verbindliche Anforderungen für Protokollierung, Erkennung und Reaktion für Betreiber.

Diese Seite fasst die Anforderungen der OH SzA aus OpenKRITIS-Sicht zusammen. Bei der Umsetzung hilft das Mapping auf ISO 27001 und C5, bei Prüfungen auf KRITIS-Kontrollen.

Die Orientierungshilfe SzA fordert ab 2023 eine umfangreiche Organisation mit Infrastruktur zur Erkennung von Cyberangriffen (CERT, SOC, CSIRT) bis zur Reaktion. Inhaltlich legt die OH SzA dogmatisch starken Fokus auf Automatisierung, Zentralisierung mit vielen teils sehr spezifischen Vorgaben zur Architektur.

SzA

DE Orientierungshilfe Angriffserkennung OH SzA

Austausch zu den neuen BSI-Anforderungen für Angriffserkennung
Webinar ∙ Registrierung über LinkedIn ∙ 21. Oktober 2022

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.

Enthalten sind in der OpenKRITIS SzA-Struktur von November 2022:

up

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 Schwachstellen­erkennung genutzt werden.

up

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 Sicherheits­vorfä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 Sicherheits­vorfällen muss in einer Richtlinie definiert werden. Dort müssen Zweck, Ziele und Verhaltensregeln für die Arten von Sicherheits­vorfä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 Sicherheits­vorfä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, tech­nischen und finanziellen Ressourcen dimensioniert und budgetiert werden.
G6 Personal Detektion Es müssen genug personelle Ressourcen für die Detektion bereit­gestellt 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öher­priorisierte Aufgabe des Personals sein. Das Personal sollte spezialisierte Schulungen erhalten.
G7 Verantwortlichkeiten Reaktion Rollen und Verantwortlichkeiten für Sicherheits­vorfälle müssen definiert sein, relevante Mitarbeiter müssen über ihre Aufgaben unter­richtet werden. Ansprechpartner, Regeln, Entscheidungen und Kontakt­informationen müssen festgelegt sein.
G7.S Organisation Reaktion
(DER.2.1)
SOLL
Zur Vorfallsbehandlung sollte es geeignete Strukturen geben: Dediziertes Team für Sicherheits­vorfälle, mit klarer Benennung bei nur anlassbezogenem Zusammentreten und regelmäßiger Überprüfung.
Schnittstellen zwischen Incident, Problem, Notfall- und Sicherheits­management 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 sicherheits­relevanten Ereignissen und korrektem Verhalten in der Meldung ans Incident Management und von Sicherheits­vorfällen muss bekannt sein.
G9.S Einbindung Vorfälle
(DER.2.1)
SOLL
Relevante Mitarbeiter im Betrieb, Service Desk und Fehlerbehebung sollten für Sicherheits­vorfä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 Sicherheits­vorfälle informiert werden, inklusive Behörden, Datenschutz­beauftragte, 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 Kommunikations­kanä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.

up

Protokollierung (SZA-P)

Spezifische Anforderungen zum Logging und der Speicherung von Logdaten, damit die wichtigsten 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 Protokoll­daten
(tw. OPS.1.1.5)
Zur Angriffserkennung notwendige Daten auf System- und Netzebene müssen gespeichert und zur Auswertung bereitgestellt werden. Sicherheits­relevante 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, Daten­quellen/-flüsse, Kommunikations­beziehungen 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.

up

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 Protokoll­daten 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 sicherheits­relevanten Vorfall müssen Meldungen und protokollierte Ereignisse ausgewertet werden.
D4 Schadcode
(mit DER.1)
Es müssen Schadcode­detektions­systeme und ggf. zusätzlich auf zentralen Systemen Schadcode­scanner 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. Sicherheits­relevante 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 Verfahrens­anleitungen 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 Detektions­systeme 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 sicherheits­relevante 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 Sicherheits­relevante Ereignisse Sicherheits­relevante Ereignisse (SRE) müssen bewertet werden, ob sie einen Vorfall darstellen. Detektionsmechanismen müssen daraufhin nachjustiert werden.
D14.S Sicherheits­relevante 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.

up

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 Sicherheits­vorfall
(DER.2.1)
Sicherheits­vorfä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 Sicherheits­vorfä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 Sicherheits­vorfalls 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 Kommunikations­verfahren und Listen interner und externer Experten bestehen.
R2.S Eskalation
(DER.2.1)
SOLL
Eine Eskalationsstrategie sollte Anweisungen für Sicherheits­vorfä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 Sicherheits­vorfalls 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 Detektions­systeme müssen sicherheits­relevante 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 Sicherheits­vorfälle zu unterbinden, oder alternativ über manuelle Prozesse.
R5 Behandlung Angriffe Sicherheits­vorfä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 Handlungs­anweisungen aus Erfahrungen erstellt und kommuniziert werden.
Die Leitungsebene sollte über Vorfälle unterrichtet werden.

up

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 Nachweis­formularen 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.

up

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 Nachweis­dokumenten belegt werden:

  1. Nachweisdokument P, Umsetzungsgrad SzA PE.3
  2. 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 Sicherheits­vorfä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.

up

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 jeweiligen BSI/C5/ISO-Kontrollen nicht vollständig umgesetzt. Sie können als Teil der Kontrollen implementiert oder geprüft werden und den Kontrollumfang dafür anpassen. Die SOLL-Anforderungen der SzA werden noch ergänzt.

Angriffserkennung OH SzA Zuordnung C5:2020 und ISO 27002:2021, eigene Zusammenstellung, Stand 2022/10/26, 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-86
OIS-02
SP-02
COM-02
A.5.1
A.5.24
G2 Richtlinie Detektion BSI-2
BSI-66
BSI-77
BSI-86
OIS-02
SP-02
SIM-01
COM-02
A.5.1
A.5.24
G3 Richtlinie Reaktion BSI-2
BSI-66
BSI-77
BSI-86
OIS-02
SP-02
SIM-01
COM-02
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 OPS-01 A.8.6 7.1
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 Sicherheits­relevante 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

up

Weitere Informationen

Literatur

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

Quellen

  1. Orientierungshilfe zum Einsatz von Systemen zur Angriffserkennung (PDF), OH SzA, Bundesamt für Sicherheit in der Informationstechnik, September 2022
  2. IT-Grundschutz-Baustein (200-1): DER.1: Detektion von sicherheitsrelevanten Ereignissen, Bundesamt für Sicherheit in der Informationstechnik, Februar 2021
  3. IT-Grundschutz-Baustein (200-1): DER.2.1: Behandlung von Sicherheitsvorfällen, Bundesamt für Sicherheit in der Informationstechnik, Februar 2021