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.
- MUSS-Anforderungen sind ab dem ersten Prüfzyklus verbindlich
- Referenzierte Anforderungen der BSI IT-Grundschutz-Bausteine (OPS und DER)
- SOLL-Anforderungen sind ab dem zweiten Prüfzyklus verbindlich
- Gruppiert in Allgemein (A), Protokollierung (P), Detektion (D), Reaktion (R)
- Eindeutige IDs der Anforderungen; das Suffix .S teilweise 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).
Umstrukturierung 2024
Das BSI hat im Sommer 2024 die SzA-Anforderungen in die Liste der BSI KRITIS-Anforderungen aus der Konkretisierung ergänzt, unter den Nummern 101 bis 135. Die Anforderungen wurden dabei vom BSI leicht zusammengefasst und umstruktuiert, speziell die SOLL-Anforderungen.
Die folgende Aufschlüsselung und das OpenKRITIS-Mapping nutzen nun die neue BSI-Struktur basierend auf den neuen Nummern BSI-101 bis BSI-135. Der Umgang mit SOLL-Anforderungen ist noch etwas uneinheitlich – teils sind diese in Hauptanforderungen integriert (mit .S-Suffix getrennt), teils haben sie eigene BSI-IDs erhalten, vor allem im Bereich Reaktion.
Allgemein (SZA-A)
Übergreifende Anforderungen an alle Phasen der Angriffserkennung, die sich vor allem um Rahmenbedingungen und Aktualität der Plattform und Systeme drehen.
| ID | 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 Schwachstellenerkennunggenutzt 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 | Thema | Anforderung |
|---|---|---|
| BSI-101 | Planung | Die zur Speicherung und Auswertung notwendige IT muss in der Planung bedachtund gesetzliche Regelungen (mind. Datenschutz) berücksichtigt werden. Die Planung muss dokumentiert werden, inkl. Netzbereiche, Datenquellen/-flüsse, Kommunikationsbeziehungen und protokollierter Ereignisse pro System. [alt: P2] 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. [alt: P4] |
| BSI‑102.S | Planung SOLL |
Die Protokollierung sollte schrittweise, basierend auf Risiko-Analyse und der kritischen Dienstleistung, geplant werden. Systeme sollten gruppiert werden. [alt: P2.S] |
| BSI-102 | 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. [alt: G1] Die Protokollierung muss stichpunktartig überprüft werden. [alt: P3] |
| BSI-103 | 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ündenmüssen die Daten an für den Netzbereichzentralen (Logging-)Stellen gespeichert werden. Die Systemzeit der protokollierenden Systeme und Anwendungen muss synchron sein. [alt: P1] Für Systeme ohne eigene Protokollierungs-Funktion muss dies von Systemen auf Netzebene übernommen werden. [alt: P5] 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. [alt: G12] Die Logging-Infrastruktur muss ausreichend mit personellen, technischen und finanziellen Ressourcen dimensioniert und budgetiert werden [alt: G5] |
| BSI‑103.S | Sichtbarkeit, Infrastruktur SOLL |
Log-Quellen sollten zur Erkennung von Angriffen im Geltungsbereich wie folgt erschlossen werden: [alt: P4.S]
|
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.
| ID | Thema | Anforderung |
|---|---|---|
| BSI‑104 | Bedrohungen und Risiken | Relevante Bedrohungen müssen durch Detektion umfassend und effizientabgedeckt werden, wozu die Risikoanalyse und Größe und Strukturdes Betreibers einbezogenwerden muss. [alt: D1] |
| BSI‑105 | 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.
[alt: G2] Für die relevanten IT-Systeme müssen für Detektion Verantwortliche festgelegt sein, die die Einhaltung der Richtlinie sicherstellen. [alt: G4] |
| BSI‑106 | 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. [alt: G13] |
| BSI‑107 | 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.[alt: G8] |
| BSI‑107.S | Überprüfung Meldewege (DER.1.A3) |
Die Meldewege sollten regelmäßig geprüft, aktualisiert und erprobt werden. |
| BSI‑108 | 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. [alt: G9] |
| BSI‑109 | 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. [alt: D3] |
| BSI‑109.S | Kontrolle Meldungen (DER.1.A5) |
Gesammelte Meldungen sollten stichpunktartig kontrolliert werden. |
| BSI‑110 | 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.
[alt: D2] Manuelle, aktive Prozesse durch Mitarbeiter (inkl. Kontrolle und Test) und Aufgaben müssen in Verfahrensanleitungen dokumentiert sein. [alt: D9] |
| BSI‑111 | Schadcode Netze, IDS (mit DER.1) |
Es müssen Schadcodedetektionssystemeund ggf. zusätzlich auf zentralen Systemen Schadcodescannereingesetzt werden. Auf diese muss zentraler Zugriff möglich sein, Meldungen müssen ausgewertet und untersucht werden. [alt: D4] Netzsegmente müssen durch zusätzliche Detektionssystemegeschützt werden, Netzübergänge durch netzbasierteIDS (NIDS), jeweils anhand des Netzstrukturplans. [alt: D5] |
| BSI‑112 | Korrelation und Signaturen | Protokolldaten müssen regelmäßig auf Auffälligkeiten kontrolliert werden. Die Signaturen der Detektionssysteme müssen aktuell und synchron gehalten werden. [alt: D6] |
| BSI‑112.S | Korrelation SOLL |
Protokoll- und Logging-Daten sollten zur Korrelation zeitlich synchronisiert werden (sein). [alt: D6.S] |
| BSI‑113 | 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. [alt: D12] |
| BSI‑114 | 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. [alt: G6] |
| BSI‑114.S | Personal Detektion SOLL |
Detektion sollte die überwiegende oder höherpriorisierte Aufgabe des Personals sein. Das Personal sollte spezialisierte Schulungen erhalten. [alt: G6.S] |
| BSI‑115 | Zentral und dauerhaft | Zur Erkennung und Auswertung müssen zentrale Komponenten eingesetzt werden.
Sicherheitsrelevante Vorgänge müssen mit zentralen automatisierten Analysen erkannt werden. [alt: D7] Protokolldaten müssen lückenlos einsehbar und auswertbar sein, die Daten möglichst permanent ausgewertet werden. [alt: D8] Systemverantwortliche müssen Analyseparameter auditieren und anpassen, Protokolldaten müssen regelmäßig automatisch auf sicherheitsrelevante Ereignisse überprüft werden. [alt: D11] Bei Überschreiten von Schwellenwerten (und Regeln) muss automatisch alarmiert werden, das zuständige Personal dann die Reaktion einleiten. [alt: D10] |
| BSI‑116 | 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. [alt: D13] Sicherheitsrelevante Ereignisse (SRE) müssen bewertet werden, ob sie einen Vorfall darstellen. Detektionsmechanismen müssen daraufhin nachjustiertwerden. [alt: D14] |
| BSI‑116.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. [alt: D14.S Die Detektionssysteme sollten in eindeutigen Fällen SREs automatisch qualifizieren können – andernfalls manuell durch festgelegte Verantwortliche.[alt: D10.S] |
Reaktion (SZA-R)
Umfangreiche organisatorische Anforderungen zur Reaktion auf Vorfälle mit definierten Vorgaben, Prozessen, Verantwortlichkeiten und Abläufen in der Wiederherstellung.
| ID | Thema | Anforderung |
|---|---|---|
| BSI‑117 | Sicherheitsvorfall (DER.2.1.A1) |
Sicherheitsvorfälle müssen klar definiert und vom Regelbetrieb abgegrenzt sein. Die Definition muss den relevanten Mitarbeitern bekannt sein. [alt: R1] |
| BSI‑117.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. [alt: R1.S] |
| BSI‑118 | 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. [alt: G3] |
| BSI‑118.S | Schnittstellen (DER.2.1.A2) SOLL |
Schnittstellen zu anderen Managementsysteme wie IT-Notfallmanagement sollten etabliert sein. |
| BSI‑119 | 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. [alt: G7] |
| BSI‑120 | 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. [alt: G10] |
| BSI‑121 | 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. [alt: R2] |
| BSI‑122 | 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. [alt: R3] |
| BSI‑122.S | Penetrationstests (DER.2.1.A6) SOLL |
Komponenten sollten nach einem Angriff vor der Wiederinbetriebnahme einem Penetrationstest unterzogen werden |
| BSI‑123 | 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. [alt: G3.S] |
| BSI‑124 | Organisationsstruktur (DER.2.1.A8) SOLL |
Es sollten geeignete Organisationsstrukturen für den Umgang festgelegt werden, mit Team, geeigneten Mitgliedern und Überprüfung [alt: G7.S] |
| BSI‑125 | 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. [neu] |
| BSI‑126 | Eindämmen SOLL |
Es sollte entschieden werden, ob der Vorfall eingedämmt oder aufgeklärt wird, dazu sollten Informationen und Worst Case Szenarien vorliegen. [neu] |
| BSI‑127 | Einstufung SOLL |
Sicherheitsvorfälle sollten nach einem einheitlichen Verfahren eingestuft werden, das zwischen ISMS und Incident Management abgestimmt ist. [neu] |
| BSI‑128 | 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 [alt: G9.S] |
| BSI‑129 | Einbindung SOLL |
Behandlung von Sicherheitsvorfällen sollten mit dem Notfallmanagement abgestimmt sein, ggf. auch mit Störungs- und Fehlerbehebung. [neu] |
| BSI‑130 | 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. [alt: R2.S] |
| BSI‑131 | Schulungen SOLL |
Mitarbeitern im Service Design sollten Hilfsmittel zur Verfügung stehen, sie sollten geschult sein und Schutzbedarfe der IT-Systeme kennen. [alt: R5.S] |
| BSI‑132 | 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. [alt: R5.S] |
| BSI‑133 | 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. [alt: R5.S] |
| BSI‑134 | 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. [alt: R5.S] |
| BSI‑135 | 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. [alt: R4] Sicherheitsvorfälle im vermeintlichen Zusammenhangmit Angriffen müssen behandelt werden. [alt: R5] Vorfälle im Zusammenhangmit Angriffen müssen an die zuständigen Behörden gemeldet werden. [alt: G11] |
| BSI‑135.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. [alt: R5.S] |
Umsetzung
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. 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
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.
| Bereich | BSI-ID | Anforderung |
|---|---|---|
| Governance | 77-79, 81-82 | Steuerung und allgemeine Prozesse für Sicherheitsvorfälle |
| SzA Kap 1.2 | SzA Allgemeine Anforderungen und Rahmen | |
| Prozesse | 101-103 | SzA Protokollierung (Logging) |
| 104-116 | SzA Erkennung (Detektion) | |
| 117-135 | SzA Reaktion | |
| Systeme und Auswertung |
80, 90-94 | Systeme und Methoden zur systematischen Auswertung |
| 103 | Systeme und Infrastruktur Protokollierung | |
| 95-96 | Regelmäßige Penetrationstests und Umgang mit Schwachstellen |
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.
Das BSI hat im Sommer 2024 die SzA-Anforderungen in die Liste der BSI KRITIS-Anforderungen ergänzt (101 bis 135), aber leider nicht in teilweise bereits passende (1 bis 100) integriert. Die neue, führende BSI KRITIS-Nr. ist markiert, ebenso Ergänzungen vom BSI zu C5 Mappings.
| SzA | Thema | BSI KRITIS weitere |
C5:2020 | ISO 27001 2022 |
|---|---|---|---|---|
| SZA-A | Allgemeine Anforderungen | |||
| Kap 1.2 | Rahmenbedingungen | BSI-2 BSI-17 |
OIS-02 OIS-01 BCM-01 |
A.5.2 A.5.24 4-10 A.5.31 |
| Kap 1.2 | Angriffsmuster | BSI-96 BSI-21 BSI-97 |
OPS-20 OPS-05 OIS-05 |
A.8.8 A.5.7 |
| Kap 1.2 | Plattform | BSI-25 | OPS-23 | A.8.19 A.8.8 |
| Kap 1.2 | Signaturen | BSI-21 | OPS-05 | A.8.7 |
| Kap 1.2 | Konfiguration | BSI-93 BSI-91 |
OPS-15 OPS-13 |
A.8.9 |
| SZA-P | Protokollierung und Logging | |||
| BSI-101 | Planung | BSI-1 BSI-20 BSI-90 BSI-91 BSI-45 |
OIS-01 OPS-01 OPS-10 DEV-03 |
ISMS 4.2 A.8.6 A.8.15 |
| BSI-102 | Richtlinie Protokollierung | BSI-87 BSI-88 BSI-2 BSI-66 BSI-87 |
COM-02 SIM-01 OIS-02 SP-02 COM-03 |
A.5.36 A.5.1 A.5.24 |
| BSI-102.S | Planung SOLL |
BSI-20 BSI-90 BSI-91 |
OPS-01 OPS-10 |
A.8.6 A.8.15 |
| BSI-103 | Protokollierung Systeme, Netze, Daten, Infrastruktur |
BSI-36 BSI-37 BSI-80 BSI-85 BSI-20 |
COS-01 OPS-01 OPS-10 OPS-12 OPS-14 SIM-05 COS-01 COM-01 |
A.8.6 A.8.20 A.8.15 A.8.16 A.5.31 A.5.34 A.5.33 7.1 |
| BSI-103.S | Sichtbarkeit, Infrastruktur SOLL |
BSI-90 | OPS-10 OPS-14 |
A.8.15 A.8.20 |
| SZA-D | Erkennung (Detektion) | |||
| BSI-104 | Bedrohungen und Risiken | BSI-14 | OIS-07 | 8.2 8.3 |
| BSI-105 | Richtlinie Detektion | BSI-2 BSI-66 BSI-77 BSI-87 |
OIS-02 SP-02 SIM-01 COM-03 |
A.5.1 A.5.24 |
| BSI-106 | Regulierung Detektion | BSI-85 | COM-01 | A.5.31 A.5.34 A.5.33 |
| BSI-107 | Meldewege | BSI-81 | SIM-04 | A.6.8 |
| BSI-107.S | Überprüfung Meldewege SOLL |
BSI-81 BSI-82 |
SIM-04 SIM-05 |
A.6.8 A.5.27 |
| BSI-108 | Awareness | BSI-68 BSI-82 |
HR-03 SIM-05 |
A.6.3 A.5.27 7.3 |
| BSI-109 | Systemfunktionen | BSI-36 BSI-90 BSI-91 BSI-93 |
COS-01 OPS-13 |
A.8.26 A.8.27 A.8.15 |
| BSI-109.S | Kontrolle Meldungen SOLL |
BSI-91 BSI-92 |
OPS-13 OPS-14 |
A.8.15 |
| BSI-110 | Kontinuierliche Überwachung | BSI-90 BSI-77 |
OPS-13 OPS-10 |
A.8.16 A.5.24 |
| BSI-111 | Schadcode, Netze, IDS | BSI-21 BSI-36 BSI-37 |
OPS-04 OPS-05 COS-01 COS-02 COS-03 |
A.8.7 A.8.20 A.8.21 A.8.23 |
| BSI-112 | Korrelation und Signaturen | BSI-80 BSI-21 |
SIM-05 OPS-05 |
A.8.15 |
| BSI-112.S | Korrelation SOLL |
BSI-90 BSI-21 |
OPS-10 OPS-05 |
A.8.15 A.8.17 |
| BSI-113 | Externe Quellen | BSI-97 | OIS-05 | A.5.5 A.5.6 |
| BSI-114 | Personal Detektion | BSI-20 BSI-78 |
OPS-01 SIM-02 |
A.8.6 7.1 A.5.26 |
| BSI-114.S | Personal Detektion SOLL |
BSI-20 BSI-78 |
OPS-01 SIM-02 |
A.8.6 A.5.26 |
| BSI-115 | Zentral und dauerhaft | BSI-80 BSI-91 |
COS-01 SIM-05 OPS-13 |
A.6.8 A.8.16 |
| BSI-116 | Sicherheitsrelevante Ereignisse | BSI-96 BSI-07 BSI-78 BSI-82 |
OPS-20 OIS-05 SIM-02 SIM-05 |
A.5.7 A.5.26 A.5.27 |
| BSI-116.S | Sicherheitsrelevante Ereignisse SOLL |
BSI-77 BSI-80 |
COS-01 SIM-01 SIM-02 |
A.5.24 A.5.25 A.5.26 |
| SZA-R | Reaktion und Wiederherstellung | |||
| BSI-117 | Sicherheitsvorfall | BSI-77 | SIM-01 | A.5.24 A.5.25 |
| BSI-117.S | Umgang mit Vorfällen SOLL |
BSI-77 | SIM-01 | A.5.24 A.5.25 |
| BSI-118 | Richtlinie Reaktion | BSI-2 BSI-66 BSI-77 BSI-87 |
OIS-02 SP-02 SIM-01 COM-03 |
A.5.1 A.5.24 |
| BSI-118.S | Schnittstellen SOLL |
BSI-77 | SIM-01 | A.5.24 A.5.26 |
| BSI-119 | Verantwortlichkeiten Reaktion | BSI-17 BSI-77 |
BCM-01 SIM-01 |
A.5.24 A.5.29 |
| BSI-120 | Benachrichtigungen | BSI-100 | OIS-05 | A.5.5 A.5.31 |
| BSI-121 | Behebung | BSI-77 BSI-78 |
SIM-01 SIM-02 |
A.5.24 A.5.25 A.5.26 |
| BSI-122 | Wiederherstellung | BSI-18 | BCM-03 | A.5.30 |
| BSI-122.S | Wiederherstellung SOLL |
BSI-18 | BCM-03 OPS-19 |
A.5.30 A.5.29 A.8.8 |
| BSI-123 | Vorgehensweise SOLL |
BSI-77 BSI-78 |
SIM-01 SIM-02 |
A.5.24 A.5.25 A.5.26 |
| BSI-124 | Organisationsstruktur SOLL |
BSI-77 | SIM-02 | A.5.24 A.5.25 |
| BSI-125 | Meldewege SOLL |
BSI-81 BSI-100 |
SIM-04 OIS-05 |
A.6.8 A.5.24 A.5.5 |
| BSI-126 | Eindämmen SOLL |
BSI-78 | SIM-02 | A.5.26 |
| BSI-127 | Einstufung SOLL |
BSI-77 BSI-78 |
SIM-01 SIM-02 |
A.5.24 A.5.25 A.5.26 |
| BSI-128 | Schnittstellen SOLL |
BSI-77 BSI-3 |
SIM-01 OIS-01 OIS-03 |
A.5.24 A.5.26 A.5.2 |
| BSI-129 | Einbindung SOLL |
BSI-77 BSI-18 |
SIM-02 BCM-03 |
A.5.26 A.5.29 A.5.30 |
| BSI-130 | Eskalation SOLL |
BSI-77 | SIM-01 | A.5.24 |
| BSI-131 | Schulungen SOLL |
BSI-20 BSI-68 |
OPS-01 SIM-02 |
A.5.26 A.6.3 |
| BSI-132 | Dokumentation SOLL |
BSI-79 | SIM-03 | A.5.26 A.5.28 |
| BSI-133 | Nachbereitung SOLL |
BSI-82 | SIM-05 | A.5.27 |
| BSI-134 | Weiterentwicklung SOLL |
BSI-82 | SIM-05 | A.5.27 |
| BSI-135 | Automatische Reaktion | BSI-36 BSI-78 BSI-100 |
COS-01 COS-02 SIM-02 OIS-05 |
A.8.21 A.8.22 A.5.26 A.5.5 |
| BSI-135.S | Auswertung SOLL |
BSI-36 BSI-78 |
COS-01 COS-02 SIM-02 |
A.8.21 A.8.22 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
- 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