Anhang 1 - Konkretisierung_Anforderungen_Massnahmen_KRITIS.pdf

Konkretisierung der Anforderungen

an die gemäß § 8a Absatz 1 und

Absatz 1a BSIG umzusetzenden

Maßnahmen

Hinweise zur Umsetzung der Kriterien des § 8a (1) und (1a) BSIG für die

Beurteilung der Informationssicherheit bei Betreibern Kritischer Infrastrukturen

Änderungshistorie

Tabelle 1: Änderungshistorie

Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63 53133 Bonn Tel. +49 (0)228 99 9582-6166 E-Mail: kritische.infrastrukturen@bsi.bund.de Internet: www.bsi.bund.de © Bundesamt für Sicherheit in der Informationstechnik 2024

Bundesamt für Sicherheit in der Informationstechnik 2

Inhalt

Inhalt

1 Einleitung ............................................................................................................................................................................................ 4

1.1 Zielsetzung und Adressatenkreis .................................................................................................................................... 4

1.2 Einheitliche Anforderungen ............................................................................................................................................. 4

1.3 Dankesworte ........................................................................................................................................................................... 5

1.4 Weiterführende Informationen ...................................................................................................................................... 5

1.5 Referenzen ............................................................................................................................................................................... 5

2 Anforderungskatalog zur Konkretisierung der Kriterien des § 8a Absatz 1 und Absatz 1a BSIG ................... 7

2.1 Informationssicherheitsmanagementsystem (ISMS) ............................................................................................. 7

2.2 Asset Management ................................................................................................................................................................ 8

2.3 Risikoanalysemethode ........................................................................................................................................................ 9

2.4 Continuity Management .................................................................................................................................................. 10

2.5 Technische Informationssicherheit ............................................................................................................................ 11

2.6 Personelle und organisatorische Sicherheit ............................................................................................................. 18

2.7 Bauliche/physische Sicherheit ...................................................................................................................................... 21

2.8 Vorfallserkennung und -bearbeitung ......................................................................................................................... 22

2.9 Überprüfung im laufenden Betrieb ............................................................................................................................. 23

2.10 Externe Informationsversorgung und Unterstützung ........................................................................................ 26

2.11 Lieferanten, Dienstleister und Dritte .......................................................................................................................... 26

2.12 Meldewesen ........................................................................................................................................................................... 27

2.13 Systeme zur Angriffserkennung (SzA) ........................................................................................................................ 27

2.13.1 Protokollierung .......................................................................................................................................................... 27

2.13.2 Detektion ...................................................................................................................................................................... 29

2.13.3 Reaktion ........................................................................................................................................................................ 32

3 Glossar ................................................................................................................................................................................................ 36

Bundesamt für Sicherheit in der Informationstechnik 3

Einleitung

1 Einleitung

1.1 Zielsetzung und Adressatenkreis

Das vorliegende Dokument bietet Betreibern Kritischer Infrastrukturen (KRITIS-Betreibern) und prüfenden Stellen eine Konkretisierung der Anforderungen des § 8a Absatz 1 und Absatz 1a BSIG. Zudem stellt der An- forderungskatalog den prüfenden Stellen geeignete Kriterien für eine sachgerechte Prüfung der eingesetz- ten Sicherheitsvorkehrungen vor, um die geforderten Nachweise gemäß § 8a Absatz 3 BSIG erbringen zu können.

Die nachfolgend dargestellten Anforderungen dienen KRITIS-Betreibern als Orientierungsmaßstab und Hilfestellung bei der Auswahl, Umsetzung und Prüfung der von ihnen gemäß § 8a Absatz 1 und Absatz 1a BSIG umzusetzenden Sicherheitsvorkehrungen, zu der gleichwertige Alternativen bestehen können. Dieser Anforderungskatalog stellt damit kein verbindliches Kriterium im Sinne des § 8a Absatz 5 BSIG dar.

1.2 Einheitliche Anforderungen

Mit diesem Anforderungskatalog soll den KRITIS-Betreibern und prüfenden Stellen ein besseres Verständ- nis über die Sichtweise des BSI ermöglicht werden. Die Konkretisierung der Anforderungen von § 8a Ab- satz 1 BSIG basiert auf dem bekannten „Anforderungskatalog Cloud-Computing (C5)“ [C5]. Die dort formu- lierten Anforderungen wurden an die spezifischen KRITIS-Aspekte angepasst und, soweit es nötig war, um weitere Anforderungen ergänzt bzw. gekürzt. Die Herkunft der C5-Anforderungen wurde transparent im Anforderungskatalog referenziert, so dass für KRITIS-Betreiber ein Vergleich mit den eigenen Grundlagen zur Absicherung der Kritischen Infrastruktur möglich ist und Mehrfachprüfungen vermieden werden können.

Die Konkretisierung der Anforderungen von § 8a Absatz 1a BSIG basiert auf der „Orientierungshilfe zum Einsatz von Systemen zur Angriffserkennung“ (OH SzA) und auf den in dieser Orientierungshilfe referen- zierten IT-Grundschutz-Bausteinen (Edition 2023) des BSI. Die Herkunft dieser Anforderungen wurde eben- falls transparent im Anforderungskatalog referenziert.

Die Anforderungen an Systeme zur Angriffserkennung sind in die Aufgabenbereiche Protokollierung, De- tektion und Reaktion unterteilt. Die Anforderungen an diese Aufgabenbereiche werden mit den in Versalien geschriebenen Modalverben MUSS, SOLLTE und KANN sowie den zugehörigen Verneinungen formuliert, um die jeweiligen Anforderungen in Bezug auf das Umsetzungsgradmodell zur Bewertung der ergriffenen Maßnahmen eindeutig zu kennzeichnen. Der Ausdruck MUSS bedeutet, dass es sich um eine Anforderung handelt, die unbedingt erfüllt werden muss, um einen Umsetzungsgrad der Stufe 3 zu erreichen. Der Aus- druck SOLLTE bedeutet, dass etwas normalerweise getan werden sollte, es aber Gründe geben kann, dies doch nicht zu tun. Dies muss aber sorgfältig abgewogen und stichhaltig begründet werden, um einen Um- setzungsgrad der Stufe 4 zu erreichen. KANN wird für Anforderungen verwendet, deren Erfüllung nicht zwingend erforderlich, aber eine sinnvolle Ergänzung ist, wenn ein Umsetzungsgrad der Stufe 5 erreicht werden soll.

Grundsätzlich gilt für die Gesamtheit aller Bereiche (Protokollierung, Detektion und Reaktion) und Prozesse zur Angriffserkennung, dass

• die notwendigen technischen, organisatorischen und personellen Rahmenbedingungen geschaffen werden MÜSSEN,

• Informationen zu aktuellen Angriffsmustern für technische Vulnerabilitäten fortlaufend für die im Anwendungsbereich eingesetzten Systeme eingeholt werden MÜSSEN,

• durchgängig alle zur effektiven Angriffserkennung erforderliche Hard-und Software auf einem aktu- ellen Stand gehalten werden MUSS,

• die Signaturen von Detektionssystemen immer aktuell sein MÜSSEN,

Bundesamt für Sicherheit in der Informationstechnik 4

Einleitung

• alle relevanten Systeme1so konfiguriert sein MÜSSEN, dass Versuche, bekannte Schwachstellen auszu- nutzen, erkannt werden können, sofern keine schwerwiegenden Gründe dagegensprechen2.

Das vorliegende Dokument stellt einen sachgerechten Ausgangspunkt dar, um die Anforderungen gemäß § 8a Absatz 1 und Absatz 1a BSIG zu konkretisieren. Dennoch obliegt es dem Betreiber sowie der prüfenden Stelle, für den konkreten Anwendungsfall zu entscheiden, ob diese Anforderungen im Rahmen der Organi- sation passend sind oder ob zusätzliche, weiterführende Anforderungen notwendig wären.

1.3 Dankesworte

Dieser Anforderungskatalog wurde in Zusammenarbeit mit dem Fachausschuss für Informationstechnolo- gie (FAIT) des Instituts der Wirtschaftsprüfer in Deutschland e. V. (IDW) auf Basis des C5 2016 entwickelt. Das BSI bedankt sich für die angenehme und gelungene Zusammenarbeit mit den Mitgliedern der Arbeits- gruppe „IT-Sicherheitsgesetz“ des FAIT.

1.4 Weiterführende Informationen

Weiterführende Informationen und beispielhafte Prüfungshandlungen für eine sachgerechte Prüfung auf Grundlage dieses Anforderungskatalogs enthält der IDW Prüfungshinweis: Die Prüfung der von Betreibern Kritischer Infrastrukturen gemäß § 8a Absatz 1 und § 8a Absatz 1a BSIG umzusetzenden Maßnahmen (IDW PH 9.860.2 n.F.) (11.2023).

Weitere Informationen für eine geeignete Umsetzung der Anforderungen des § 8a Absatz 1 und Absatz 1a BSIG können entnommen werden:

• der Orientierungshilfe zu Nachweisen gemäß §8a Absatz3 BSIG [OH1],

• der Orientierungshilfe zu branchenspezifischen Sicherheitsstandards (B3S) gemäß §8a Absatz2 BSIG [OH2],

• der Orientierungshilfe zum Einsatz von Systemen zur Angriffserkennung (OH SzA),

• Branchenspezifische Sicherheitsstandards (B3S) gemäß §8a Absatz2 BSIG, deren Eignung vom BSI fest- gestellt wurde,

• den einschlägigen Standards (z.B. Zertifizierungsschemata für ISO/IEC 27001 (nativ oder auf Basis von IT-Grundschutz), ISO/IEC 17021-1, ISO/IEC 27006) [GS, ISO1, ISO2, ISO3].

1.5 Referenzen

• [C5] AnforderungskatalogCloud Computing (C5), BSI, C5:2016, www.bsi.bund.de/dok/13368656

• [IDW] IDW PH 9.860.2 n.F. (11.2023), IDW

• [ISO1] ISO/IEC 27001:2013: Information technology –Security techniques –Information security mana- gement systems –Requirements, International Organization for Standardization, 2013

• [ISO2] ISO/IEC 17021-1, International Organization for Standardization

• [ISO3] ISO/IEC 27006, International Organization for Standardization

• [GS] IT-Grundschutz, BSI,www.bsi.bund.de/dok/128568

• [OH2] Orientierungshilfe zu Inhalten und Anforderungen an branchenspezifische Sicherheitsstandards (B3S) gemäß § 8a Absatz 2 BSIG, BSI, 10.01.2018, www.bsi.bund.de/dok/ohb3s

1 Siehe hierzu Planung der Protokollierung 2 Schwerwiegende Gründe liegen beispielsweise vor, wenn die dazu notwendigen Maßnahmen zu einer rele- vanten Gefährdung bzw. Beeinträchtigung der kritischen Dienstleistung des Betreibers führen können.

Bundesamt für Sicherheit in der Informationstechnik 5

Einleitung

• [OH1] Orientierungshilfe zu Nachweisen gemäß § 8a Absatz3 BSIG, BSI, 22.05.2019, www.bsi.bund.de/OHNachweise

• [OH SzA] Orientierungshilfe zum Einsatz von Systemen zur Angriffserkennung, BSI, 26.09.2022, www.bsi.bund.de/dok/oh-sza

Bundesamt für Sicherheit in der Informationstechnik 6

Anforderungskatalog zur Konkretisierung der Kriterien des § 8a Absatz 1 und Absatz 1a BSIG

2 Anforderungskatalog zur Konkretisierung der

Kriterien des § 8a Absatz 1 und Absatz 1a BSIG

2.1 Informationssicherheitsmanagementsystem (ISMS)

1. Managementsystem für Informationssicherheit (OIS-01) Die Unternehmensleitung initiiert, steuert und überwacht ein Managementsystem zur Informationssicher- heit (ISMS), das sich an etablierten Standards orientiert. Bei Anwendung der ISO 2700x-Reihe muss die Er- klärung zur Anwendbarkeit (Statement of Applicability) die IT-Prozesse zu Entwicklung und Betrieb der kritischen Dienstleistung umfassen.

Die hierzu eingesetzten Grundsätze, Verfahren und Maßnahmen ermöglichen eine nachvollziehbare Len- kung der folgenden Aufgaben und Aktivitäten zur dauerhaften Aufrechterhaltung der organisatorischen und technischen Vorkehrungen zur Vermeidung von Störungen der Verfügbarkeit, Integrität, Authentizität und Vertraulichkeit der informationstechnischen Systeme, Komponenten und Prozesse zu Entwicklung und Betrieb der kritischen Dienstleistung und umfasst:

• die Planung und Durchführung des Vorhabens,

• Erfolgskontrolle bzw. Überwachung der Zielerreichung und

• Beseitigung von erkannten Mängeln und Schwächen sowie kontinuierliche Verbesserung.

2. Strategische Vorgaben zur Informationssicherheit und Verantwortung der Unternehmensleitung (OIS-02) Eine Informationssicherheitsleitlinie mit Sicherheitszielen und strategischen Vorgaben, wie diese Ziele er- reicht werden sollen, ist dokumentiert. Die Sicherheitsziele leiten sich von den Unternehmenszielen und Geschäftsprozessen, relevanten Gesetzen und Verordnungen sowie der aktuellen und zukünftig erwarteten Bedrohungsumgebung in Bezug auf Informationssicherheit ab. Die strategischen Vorgaben stellen grund- legende Rahmenbedingungen dar, die in weiteren Richtlinien und Anweisungen näher spezifiziert werden. Die Informationssicherheitsleitlinie wird von der Unternehmensleitung verabschiedet und an alle betroffe- nen internen und externen Parteien der kritischen Dienstleistung kommuniziert.

3. Zuständigkeiten und Verantwortungen im Rahmen der Informationssicherheit(OIS-03) Die Verantwortlichkeiten, Pflichten sowie die Schnittstellen zum Melden von Sicherheitsvorfällen und Stö- rungen sind definiert, dokumentiert, zugewiesen und an alle betroffenen internen und externen Parteien (z. B. Unterauftragnehmer des KRITIS-Betreibers der kritischen Dienstleistung) kommuniziert. Seitens des KRITIS-Betreibers sind mindestens die folgenden Rollen (oder vergleichbare Äquivalente) in der Informa- tionssicherheitsleitlinie oder zugehörigen Richtlinien beschrieben und entsprechende Verantwortlichkeiten zugewiesen:

• IT-Leiter (CIO)

• IT-Sicherheitsbeauftragter (CISO)

• Beauftragter für die Behandlung von IT-Sicherheitsvorfällen (z.B. CERT-Leiter).

Veränderungen an Verantwortlichkeiten und Schnittstellen werden intern und extern so zeitnah kommu- niziert, dass alle mit organisatorischen und technischen Maßnahmen betroffenen internen und externen Parteien angemessen darauf reagieren können, bevor die Änderungen wirksam werden.

Der KRITIS-Betreiber identifiziert sämtliche Risiken im Zusammenhang mit überlappenden oder inkompa- tiblen Zuständigkeiten und Verantwortungen.

Bundesamt für Sicherheit in der Informationstechnik 7

Anforderungskatalog zur Konkretisierung der Kriterien des § 8a Absatz 1 und Absatz 1a BSIG

4. Funktionstrennung(OIS-04) Es existieren angemessene Vorgaben und Anweisungen zu organisatorischen und technischen Kontrollen, um die Trennung von Rollen und Verantwortlichkeiten („Separation of Duties“/Funktionstrennung), die hinsichtlich der Vertraulichkeit, Integrität und Verfügbarkeit der Informationen im Zusammenhangmit der kritischen Dienstleistung nicht miteinander vereinbar sind, zu gewährleisten (z.B. in Stellenbeschrei- bungen, Prozessbeschreibungen, SOD-Matrizen, etc.).

Die Vorgaben adressieren insb. die folgenden Bereiche (Beispiele):

• Administration von Rollen, Genehmigung und Zuweisung von Zugriffsberechtigungen für Benutzer unter Verantwortung des KRITIS-Betreibers

• die Entwicklung und Implementierung von Änderungen an der kritischen Dienstleistung sowie die War- tung der für die kritische Dienstleistung relevanten physischen und logischen IT-Infrastruktur (Netz- werke, Betriebssysteme, Datenbanken) und der IT-Anwendungen

• den Betrieb und die Überwachung des Betriebs der kritischen Dienstleistungen.

Operative und kontrollierende Funktionen sollten nicht von einerPerson gleichzeitig wahrgenommen werden dürfen. Kann aus organisatorischen oder technischen Gründen keine Funktionstrennung erreicht werden, sind angemessene kompensierende Kontrollen eingerichtet, um missbräuchliche Aktivitäten zu verhindern oder aufzudecken.

Vorhandene Funktionstrennungskonflikte und die dazu eingerichteten kompensierenden Kontrollen nach- vollziehbar dokumentiert (z.B. in einem Rollen-und Rechtekonzept), um eine Beurteilung über die Ange- messenheit und Wirksamkeit dieser Kontrollen zu ermöglichen.

2.2 Asset Management

5. Asset Inventar (AM-01) Die zur Erbringung der kritischen Dienstleistung eingesetzten IT-Systeme und Komponenten (Assets) wie z. B. PCs, Peripheriegeräte, Telefone, Netzwerkkomponenten, Server, Installationsdokumentationen, Verfah- rensanweisungen, IT-Anwendungen u. Werkzeuge sind identifiziert und inventarisiert. Durch angemessene Vorkehrungen und Maßnahmen wird sichergestellt, dass dieses Inventar vollständig, richtig, aktuell und konsistent bleibt. Änderungen an den Einträgen im Inventar werden nachvollziehbar historisiert. Soweit hierzu keine wirksamen Automatismen eingerichtet sind, wird dies durch regelmäßig stattfindende manu- elle Überprüfung der Inventardaten des Assets sichergestellt.

6. Zuweisung von Asset Verantwortlichen (AM-02) Sämtliche inventarisierten Assets mit Relevanz für die Erbringung der kritischen Dienstleistung sind einem Verantwortlichen auf Seiten des Betreibers der kritischen Dienstleistung zugewiesen. Die Verantwortlichen des Betreibers sind über den kompletten Lebenszyklus der Assets dafür zuständig, dass diese vollständig in- ventarisiert und richtig klassifiziert sind.

7. Nutzungsanweisungen für Assets (AM-03) Richtlinien und Anweisungen mit technischen und organisatorischen Maßnahmen für den ordnungsge- mäßen Umgang mit Assets, die für die Erbringung der kritischen Dienstleistung relevant sind und gemäß der Informationssicherheitsrichtlinie dokumentiert, kommuniziert und in der jeweils aktuellsten Version bereitgestellt werden.

8. Ab-und Rückgabe von Assets (AM-04) Alle internen und externen Mitarbeiter des Betreibers der kritischen Dienstleistung sind verpflichtet, sämt- liche Assets, die Ihnen in Bezug auf die kritische Dienstleistung ausgehändigt wurden bzw. für die sie ver- antwortlich sind, zurückzugeben oder unwiderruflich zu löschen sobald das Beschäftigungsverhältnis be- endet ist.

Bundesamt für Sicherheit in der Informationstechnik 8

Anforderungskatalog zur Konkretisierung der Kriterien des § 8a Absatz 1 und Absatz 1a BSIG

9. Klassifikation von Informationen (AM-05) Der Betreiber der kritischen Dienstleistung verwendet eine einheitliche Klassifizierung von Informationen und Assets, die für die Entwicklung und Erbringung der kritischen Dienstleistung relevant sind. Das Klassi- fizierungsschema basiert auf einer Risikoanalyse und Folgeabschätzung (4.4.3).

10. Kennzeichnung von Informationen und Handhabung von Assets (AM-06) Zu dem umgesetzten Klassifizierungsschema von Informationen und Assets existieren Arbeitsanweisungen und Prozesse, um die Kennzeichnung von Informationen, sowie die entsprechende Behandlung von Assets zu gewährleisten.

11. Verwaltung von Datenträgern (AM-07) Richtlinien und Anweisungen mit technischen und organisatorischen Maßnahmen für den sicheren Um- gang mit Assets sind gemäß der IT-Sicherheitsrichtlinie dokumentiert, kommuniziert und bereitgestellt.

Die Vorgaben stellen einen Bezug zur Klassifikation von Informationen her. Sie umfassen die sichere Ver- wendung, den sicheren Transport sowie die unwiederbringliche Löschung und Vernichtung von Daten- trägern.

12. Überführung und Entfernung von Assets (AM-08) Geräte, Hardware, Software oder Daten dürfen nur nach erfolgter Genehmigung durch autorisierte Gremien oder Stellen des Betreibers der Kritischen Infrastruktur in externe Räumlichkeiten überführt werden. Die Überführung findet auf sicherem Wege statt, entsprechend der Art des zu überführenden Assets.

2.3 Risikoanalysemethode

13. Richtlinie für dieOrganisation des Risikomanagements (OIS-06) Richtlinien und Anweisungen über das grundsätzliche Verfahren zur Identifikation, Analyse, Beurteilung und Behandlung von Risiken und insb. IT-Risiken, die zu Störungen der Verfügbarkeit, Integrität, Authen- tizität und Vertraulichkeit der für die Erbringung der kritischen Dienstleistung notwendigen informations- technischen Systeme führen, sind dokumentiert, kommuniziert und bereitgestellt.

14. Identifikation, Analyse, Beurteilung und Folgeabschätzung von IT-Risiken (OIS-07) Die Verfahren zur Identifikation, Analyse, Beurteilung und Behandlung von Risiken, einschließlich der für die Erbringung der kritischen Dienstleistung relevanten IT-Risiken, werden mindestens jährlich durch- laufen, um interne und externe Veränderungen und Einflussfaktoren zu berücksichtigen. Die identifizierten Risiken werden gemäß den Maßnahmen des Risikomanagements nachvollziehbar dokumentiert, bewertet und mit mitigierenden Maßnahmen versehen.

Vorgaben der Unternehmensleitung für den Risikoappetit und die Risikotoleranzen sind in der Richtlinie für das Risikomanagement oder einem vergleichbar verbindlichen Dokument enthalten. Dies schließt Folgeabschätzungen der Risiken für die Nutzer der kritischen Dienstleistung ein. Die Unternehmensleitung wird mindestens quartalsweise und in angemessener Form über den Status der identifizierten Risiken und mitigierender Vorkehrungen und Maßnahmen informiert.

15. Richtlinien zur Folgeabschätzung (BCM-02) Richtlinien und Anweisungen zum Ermitteln von Auswirkungen etwaiger Störungen der kritischen Dienst- leistung sind dokumentiert, kommuniziert und bereitgestellt.

Mindestens die folgenden Aspekte werden dabei berücksichtigt:

• Analysen in Bezug auf Komponenten, deren Ausfall den Ausfall der gesamten Anlage auslösen kann („Single Point of Failure“)

• Berücksichtigung einer Änderung der allgemeinen und branchenspezifischen Gefährdungslage

• Mögliche Szenarien basierend auf einer Risikoanalyse (z. B. Ausfall von Personal, Gebäude, Infrastruktur und Dienstleister)

Bundesamt für Sicherheit in der Informationstechnik 9

Anforderungskatalog zur Konkretisierung der Kriterien des § 8a Absatz 1 und Absatz 1a BSIG

• Identifizierung von Richtlinien und Anweisungen zu notwendigen Produkten und Dienstleistungen

• Identifizierung von Abhängigkeiten, einschließlich der Prozesse (inkl. dafür benötigter Ressourcen), Anwendungen, Geschäftspartner und Dritter

• Erfassung von Bedrohungen gegenüber der kritischen Dienstleistung

• Ermittlung von Auswirkungen resultierend aus geplanten und ungeplanten Störungen und den Veränderungen im Laufe der Zeit auf die kritische Dienstleistung

• Feststellung der maximal vertretbaren Dauer von Störungen bevor die Mindestqualität der kritischen Dienstleistung erreicht ist

• Feststellung der Prioritäten zur Wiederherstellung

• Feststellung zeitlicher Zielvorgaben zur Wiederaufnahme der kritischen Dienstleistung innerhalb des maximal vertretbaren Zeitraums (RTO)

• Feststellung zeitlicher Vorgaben zum maximal vertretbaren Zeitraum, in dem Daten verloren und nicht wiederhergestellt werden können (RPO)

• Abschätzung der zur Wiederaufnahmebenötigten Ressourcen.

16. Maßnahmenableitung(B3S) Es sind Richtlinien definiert, die die Ableitung von Maßnahmen und deren Überwachung regeln.

Dies beinhaltet, dass die identifizierten IT-Risiken im Zusammenhang mit der kritischen Dienstleistung gemäß den Vorgaben des Risikomanagements nachvollziehbar mit Maßnahmen versehen werden, um die IT-Risiken zu reduzieren. Dabei ist zu berücksichtigen, dass gegenüber allgemeinen Risikomanagement- ansätzen ein unbehandeltes Risiko durch eigenständige dauerhafte Risikoakzeptanz durch den Betreiber oder Versicherung gegen Risiken in der Regel keine zulässige Option im Sinne des BSIG ist.

Der Status der Maßnahmenumsetzung und der damit einhergehenden Veränderung der Risikobewertung wird überwacht und regelmäßig an die relevanten Stakeholder berichtet.

Auch bei Outsourcing o. Ä. verbleibt die volle Verantwortung für eine geeignete Risikobehandlung beim Betreiber.

2.4 Continuity Management

17. Verantwortung der gesetzlichen Vertreter des Betreibers der Kritischen Infrastruktur (BCM-01) Die gesetzlichen Vertreter des Betreibers der Kritischen Infrastruktur haben einen Prozessverantwortlichen (bspw. ein Mitglied der Unternehmensleitung) für Kontinuitäts-und Notfallmanagement benannt, der für die Etablierung der Prozesse und die Einhaltung der Leitlinien verantwortlich ist. Von dieser Verantwortung ist umfasst, dass ausreichende Ressourcen für einen geordneten Betrieb bereitgestellt werden.

Personen in der Unternehmensleitung und anderen relevanten Führungspositionen demonstrieren Füh- rung und Engagement in Bezug auf dieses Thema, indem sie beispielsweise die Mitarbeiter dazu auffordern beziehungsweise ermutigen, zu der Effektivität des Kontinuitäts-und Notfallmanagements aktiv beizutra- gen.

18. Planung der Betriebskontinuität (BCM-03) Basierend auf der Folgeabschätzung wird ein verbindliches Rahmenwerk zur Planung der Kontinuität der für die kritische Dienstleistung notwendigen IT-Systeme (einschließlich von Notfallplänen) eingeführt, dokumentiert und angewendet, das eine konsistente Vorgehensweise (z.B. an verschiedenen Standorten der Anlagen) sicherstellt. Diese Planung berücksichtigt etablierte Standards, die in einem „Statement of Applica- bility“ nachvollziehbar festgelegt sind.

Bundesamt für Sicherheit in der Informationstechnik 10

Anforderungskatalog zur Konkretisierung der Kriterien des § 8a Absatz 1 und Absatz 1a BSIG

Pläne zur Kontinuität der kritischen Dienstleistung berücksichtigen dabei folgende Aspekte:

• Definierter Zweck und Umfang unter Beachtung der relevanten Abhängigkeiten

• Zugänglichkeit und Verständlichkeit der Pläne für Personen, die danach handeln sollen

• Eigentümerschaft durch mindestens eine benannte Person,die für die Überprüfung, Aktualisierung und Genehmigung zuständig ist

• Festgelegte Kommunikationswege, Rollen und Verantwortlichkeiten

• Wiederherstellungsverfahren, manuelle Übergangslösungen und Referenzinformationen (unter Berück- sichtigung der Priorisierung bei der Wiederherstellung der kritischen Dienstleistung

• Methoden zur Inkraftsetzung der Pläne

• Kontinuierlicher Verbesserungsprozess der Pläne

• Schnittstellen zum Security Incident Management.

19. Verifizierung, Aktualisierung und Test der Betriebskontinuität (BCM-04) Die Folgeabschätzung sowie die Pläne zur Kontinuität der kritischen Dienstleistung und Notfallpläne wer- den regelmäßig (mindestens jährlich) oder nach wesentlichen organisatorischen oder umgebungsbedingten Veränderungen überprüft, aktualisiert und getestet.

Tests beziehen betroffene relevante Dritte (z. B. kritische Lieferanten) mit ein z.B. in Form von:

• Internen Übungen und Systemtests

• Übungen mit externen Partnern, insb. aus dem Kontext der kritischen Dienstleistung

• Übungen im Rahmen des Notfallmanagements

• Kommunikationsübungen

• Planübungen, Krisenübungen, Training seltener Ereignisse.

Die Tests werden dokumentiert und Ergebnisse werden für zukünftige Maßnahmen der Kontinuität der kritischen Dienstleistung berücksichtigt.

2.5 Technische Informationssicherheit

20. Notwendige/ausreichende Personal-und IT-Ressourcen (Betrieb und IT-Sicherheit)(RB-01, RB-02) Die Planung von Kapazitäten und Ressourcen (Personal und IT-Ressourcen) folgt einem etablierten Verfah- ren, um mögliche Kapazitätsengpässe zu vermeiden. Die Verfahren umfassen Prognosen von zukünftigen Kapazitätsanforderungen, um Nutzungstrends zu identifizieren und Risiken der Systemüberlastung zu be- herrschen.

Technische und organisatorische Maßnahmen zur Überwachung und Provisionierung bzw. Deprovisio- nierung bei KRITIS-Betreiber sind definiert. Dadurch stellt der Betreiber sicher, dass Ressourcen bereit- gestellt bzw. Leistungen gemäß der vertraglichen Vereinbarung erbracht werden und die Einhaltung der Dienstgütevereinbarungen sichergestellt ist.

21. Schutz vor Schadprogrammen(RB-05) Die logischen und physischen IT-Systeme, die der Betreiber zur Erbringung der kritischen Dienstleistung verwendet sowie die Perimeter des Netzwerks, die dem Verantwortungsbereich des KRITIS-Betreibers un- terliegen, sind mitVirenschutz-und Reparaturprogrammen versehen, die eine signatur-und verhaltens- basierte Erkennung und Entfernung von Schadprogrammen ermöglichen.

Die Programme werden gemäß den vertraglichen Vereinbarungen mit dem/n Hersteller/n, mindestens aber täglich,aktualisiert.

Bundesamt für Sicherheit in der Informationstechnik 11

Anforderungskatalog zur Konkretisierung der Kriterien des § 8a Absatz 1 und Absatz 1a BSIG

22. Datensicherung und Wiederherstellung (RB-06, RB-09) Richtlinien und Anweisungen mit technischen und organisatorischen Maßnahmen zum Vermeiden von Datenverlusten sind gemäß IT-Sicherheitsrichtlinie dokumentiert, kommuniziert und bereitgestellt. Diese sehen zuverlässige Verfahren für die regelmäßige Sicherung (Backup sowie ggf. Snapshots) und Wieder- herstellung von Daten (Restore) vor. Umfang, Häufigkeit und Dauer der Aufbewahrung entsprechen den Anforderungen der kritischen Dienstleistung. Der Zugriff auf die gesicherten Daten ist auf autorisiertes Personal beschränkt. Wiederherstellungsprozeduren beinhalten Kontrollmechanismen, die sicherstellen, dass Wiederherstellungen ausschließlich nach Genehmigung durch hierfür autorisierte Personen gemäß den internen Richtlinien erfolgen.

23. Datensicherung und Wiederherstellung – Überwachung(RB-07) Die Ausführung der Datensicherung wird durch technische und organisatorische Maßnahmen überwacht. Störungen werden durch qualifizierte Mitarbeiter untersucht und zeitnah behoben, um die Einhaltung der Anforderungen in Bezug auf Umfang, Häufigkeit und Dauer der Aufbewahrung zu gewährleisten.

24. Datensicherung und Wiederherstellung –Regelmäßige Tests(RB-08) Sicherungsdatenträger und Wiederherstellungsverfahren sind von qualifizierten Mitarbeitern regelmäßig mit dedizierten Testmedien zu prüfen. Die Tests sind so gestaltet, dass die Verlässlichkeit der Sicherungs- datenträger und die Wiederherstellungszeit mit hinreichender Sicherheit überprüft werden kann.

Die Tests werden durch qualifizierte Mitarbeiter durchgeführt und die Ergebnisse nachvollziehbar doku- mentiert. Auftretende Fehler werden zeitnah behoben.

25. Umgang mit Schwachstellen, Störungen und Fehlern –System-Härtung (RB-22) Systemkomponenten, welche für die Erbringung der kritischen Dienstleistung verwendet werden, sind gemäß allgemein etablierter und akzeptierter Industriestandards gehärtet. Die herangezogenen Härtungs- anleitungen werden ebenso wie der Umsetzungsstatus dokumentiert.

26. Geheimhaltung von Authentifizierungsinformationen(IDM-07) Die Zuteilung geheimer Authentifizierungsinformationen (z. B. Passwörter, Zertifikate, Sicherheitstoken) an interne und externe Benutzer des KRITIS-Betreibers erfolgt, soweit dies organisatorischen oder technischen Verfahren des KRITIS-Betreibers unterliegt, in einem geordneten Verfahren, das die Vertraulichkeit der In- formationen sicherstellt.

Soweit diese initial vergeben werden, sind diese nur temporär, höchstens aber 14 Tage gültig. Benutzer wer- den ferner gezwungen, diese bei der ersten Verwendung zu ändern.

27. Sichere Anmeldeverfahren(IDM-08) Die Vertraulichkeit der Anmeldeinformationen von internen und externen Benutzern unter Verantwortung des KRITIS-Betreibers sind durch die folgenden Maßnahmen geschützt:

• Identitätsprüfung durch vertrauenswürdige Verfahren

• Verwendung anerkannter Industriestandards zur Authentifizierung und Autorisierung (z.B. Multi- Faktor-Authentifizierung, keine Verwendung von gemeinsam genutzten Authentifizierungsinforma- tionen, automatischer Ablauf)

• Multi-Faktor-Authentifizierung für Administratoren des KRITIS-Betreibers (z. B. durch Smart Card oder biometrische Merkmale) ist zwingend erforderlich, sofern ein Zugriff über öffentliche Netze erfolgt.

28. Systemseitige Zugriffskontrolle(IDM-10) Der Zugriff auf Informationen und Anwendungsfunktionen wird durch technische Maßnahmen einge- schränkt, mit denen das Rollen-und Rechtekonzept umgesetzt wird.

Bundesamt für Sicherheit in der Informationstechnik 12

Anforderungskatalog zur Konkretisierung der Kriterien des § 8a Absatz 1 und Absatz 1a BSIG

29. Passwortanforderungen und Validierungsparameter (IDM-11) Sicherheits-Parameter auf Netzwerk,- Betriebssystem- (Host und Gast), Datenbank-, und Anwendungs- ebene (soweit für die kritische Dienstleistung relevant) sind angemessen konfiguriert, um unautorisierte Zugriffe zu verhindern. Soweit keine Zwei-Faktor-Authentifizierung oder die Verwendung von Einmal- passwörtern möglich ist, wird die Verwendung sicherer Passwörter auf allen Ebenen und Geräten (ein- schließlich mobilen Endgeräten) unter Verantwortung des KRITIS-Betreibers technisch erzwungen oder in einer Passwort-Richtlinie organisatorisch gefordert.

Die Vorgaben müssen mindestens die folgenden Anforderungen erfüllen:

• Minimale Passwortlänge von 8 Zeichen

• Mindestens zwei der folgenden Zeichentypen müssen enthalten sein: Großbuchstaben, Kleinbuchstaben, Sonderzeichen und Zahlen

• Maximale Gültigkeit von 90Tagen, minimale Gültigkeit von 1 Tag

• Passworthistorie von 6

• Übertragung und Speicherung der Passwörter in einem verschlüsselten Verfahren, das dem aktuellen Stand der Technik entspricht.

30. Einschränkung und Kontrolle administrativer Software(IDM-12) Die Verwendung von Dienstprogrammen und Managementkonsolen, die weitreichenden Zugriff auf die Daten der für die kritische Dienstleistung relevanten Daten ermöglichen, ist auf autorisierte Personen be- schränkt. Vergabe und Änderung entsprechender Zugriffsberechtigungen erfolgen gemäß der Richtlinie zur Verwaltung von Zugangs- und Zugriffsberechtigungen.

Der Zugriff wird durch starke Authentifizierungstechniken, einschließlich Multi-Faktor-Authentifizierung gesteuert.

31. Zugriffskontrolle zu Quellcode(IDM-13) Der Zugriff auf den Quellcode und ergänzende für die Entwicklung der kritischen Dienstleistung relevanten Informationen (z. B. Architektur-Dokumentation, Testpläne) sind restriktiv vergeben und werden über- wacht, um die Einführung von nicht autorisierten Funktionen oder das Durchführen unbeabsichtigter Änderungen zu vermeiden.

32. Richtlinie zur Nutzung von Verschlüsselungsverfahren und Schlüsselverwaltung (KRY-01) Richtlinien und Anweisungen mit technischen und organisatorischen Maßnahmen für Verschlüsselungs- verfahren und Schlüsselverwaltung sind gemäß IT-Sicherheitsrichtlinie dokumentiert, kommuniziert und bereitgestellt, in denen die folgenden Aspekte beschrieben sind:

• Das Nutzen von starken Verschlüsselungsverfahren (z. B. AES) und die Verwendung von sicheren Netz- werkprotokollen, die dem Stand der Technik entsprechen (z. B. TLS, IPsec, SSH)

• risikobasierte Vorschriften für den Einsatz von Verschlüsselung, die mit Schemata zur Informations- klassifikation abgeglichen sind und den Kommunikationskanal, Art, Stärke und Qualität der Ver- schlüsselung berücksichtigen

• Anforderungen für das sichere Erzeugen, Speichern, Archivieren, Abrufen, Verteilen, Entziehen und Löschen der Schlüssel

• Berücksichtigung der relevanten rechtlichen und regulatorischen Verpflichtungen und Anforderungen.

33. Verschlüsselung von Daten bei der Übertragung (Transportverschlüsselung)(KRY-02) Verfahren und technische Maßnahmen zur starken Verschlüsselung und Authentifizierung bei der Über- tragung von Daten der kritischen Dienstleistung (z. B. über öffentliche Netze transportierte elektronische Nachrichten) sind etabliert.

Bundesamt für Sicherheit in der Informationstechnik 13

Anforderungskatalog zur Konkretisierung der Kriterien des § 8a Absatz 1 und Absatz 1a BSIG

34. Verschlüsselung von sensiblen Daten bei der Speicherung(KRY-03) Verfahren und technische Maßnahmen zur Verschlüsselung sensibler Daten der kritischen Dienstleistung bei der Speicherungsind etabliert. Ausnahmen gelten für Daten, die für die Erbringung der kritischen Dienstleistung funktionsbedingt nicht verschlüsselt sein können. Die für die Verschlüsselung verwendeten privaten Schlüssel sind ausschließlich dem dafür vorgesehenen Empfänger nach geltenden rechtlichen und regulatorischen Verpflichtungen und Anforderungen bekannt. Ausnahmen (z. B. Verwendung eines Gene- ralschlüssels durch den KRITIS-Betreiber) folgen einem geregelten Verfahren.

35. Sichere Schlüsselverwaltung(KRY-04) Verfahren und technische Maßnahmen zur sicheren Schlüsselverwaltung beinhalten mindestens die fol- genden Aspekte:

• Schlüsselgenerierung für unterschiedliche kryptografische Systeme und Applikationen

• Ausstellung und Einholung von Public-Key-Zertifikaten

• Provisionierung und Aktivierung von Schlüsseln für beteiligte Dritte

• Sicheres Speichern eigener Schlüssel (sonstiger Dritter) einschließlich der Beschreibung, wie autorisierte Nutzer den Zugriff erhalten

• Ändern oder Aktualisieren von kryptografischen Schlüsseln einschließlich Richtlinien, die festlegen, unter welchen Bedingungen und auf welche Weise die Änderungen bzw. Aktualisierungen zu realisieren sind

• Umgang mit kompromittiertem Schlüssel

• Entzug und Löschen von Schlüsseln, bspw. im Falle von Kompromittierung oder Mitarbeiterverände- rungen.

36. Technische Schutzmaßnahmen(KOS-01) Basierend auf den Ergebnissen einer durchgeführten Risiko-Analyse, hat der KRITIS-Betreiber technische Schutzmaßnahmen implementiert, die geeignet sind, um netzwerkbasierte Angriffe auf Basis anomaler Eingangs-oder Ausgangs-Traffic-Muster (z.B. durch MAC-Spoofing und ARP-Poisoning-Angriffe) und/ oder Distributed-Denial-of-Service (DDoS)-Angriffe zeitnah zu erkennen und darauf zu reagieren. Zusätz- lich werden, wo notwendig bzw. sinnvoll, Intrusion Detection-und Intrusion Prevention-Systeme (IDS und IPS) eingesetzt.

37. Überwachen von Verbindungen(KOS-02) Physische und virtualisierte Netzwerkumgebungen sind so konzipiert und konfiguriert, dass die Verbin- dungen zwischen vertrauenswürdigen und nicht vertrauenswürdigen Netzen zu beschränken und über- wachen sind.

In festgelegten Abständen wird die geschäftliche Rechtfertigung für die Verwendung aller Dienste, Proto- kolle und Ports überprüft. Darüber hinaus umfasst die Überprüfung auch die Begründungen für kompen- sierende Kontrollen für die Verwendung von Protokollen, die als unsicher angesehen werden.

38. Netzwerkübergreifende Zugriffe(KOS-03) Jeder Netzwerkperimeter wird von Sicherheitsgateways kontrolliert. Die Zugangsberechtigung für netz- übergreifendeZugriffe basiert auf einer Sicherheitsbewertung.

39. Netzwerke zur Administration(KOS-04) Es existieren gesonderte Netzwerke zur administrativen Verwaltung der Infrastruktur und für den Betrieb von Managementkonsolen, die logisch oder physisch vom Netzwerk des KRITIS-Betreibers getrennt und durch Multi-Faktor-Authentifizierung vor unberechtigten Zugriffen geschützt sind.

Netzwerke, die zum Zwecke der Migration oder dem Erzeugen von virtuellen Maschinen dienen, sind eben- falls physisch oder logisch von anderenNetzwerken zu separieren.

Bundesamt für Sicherheit in der Informationstechnik 14

Anforderungskatalog zur Konkretisierung der Kriterien des § 8a Absatz 1 und Absatz 1a BSIG

40. Dokumentation der Netztopologie(KOS-06) Die Architektur des Netzwerks ist nachvollziehbar und aktuell dokumentiert (z. B. in Form von Diagram- men), um im Wirkbetrieb Fehler in der Verwaltung zu vermeiden und um im Schadensfall eine zeitgerechte Wiederherstellung gemäß den vertraglichen Verpflichtungen zu gewährleisten.

Aus der Dokumentation gehen die unterschiedlichen Umgebungen (z. B. Administrations-Netzwerk und geteilte Netzwerksegmente) und Datenflüsse hervor.

41. Richtlinien zur Datenübertragung(KOS-07) Richtlinien und Anweisungen mit technischen und organisatorischen Maßnahmen zum Schutz der Daten- übertragung vor unbefugtem Abfangen, Manipulieren, Kopieren, Modifizieren, Umleiten oder Vernichten (z. B. Einsatz von Verschlüsselung) sind gemäß IT-Sicherheitsrichtlinie dokumentiert, kommuniziert und bereitgestellt.

Die Vorgaben stellen einen Bezug zur Klassifikation von Informationen her (vgl. Nr. 9).

42. Vertraulichkeitserklärung(KOS-08) Die mit internen Mitarbeitern, externen Dienstleistern sowie Lieferanten des KRITIS-Betreibers zu schlie- ßenden Geheimhaltungs- oder Vertraulichkeitserklärungen basieren auf den Anforderungen des KRITIS- Betreibers zum Schutz vertraulicher Daten und betrieblicher Details.

Die Anforderungen sind zu identifizieren, dokumentieren und in regelmäßigen Abständen (mindestens jährlich) zu überprüfen. Soweit sich aus der Überprüfung ergibt, dass die Anforderungen anzupassen sind, werden mit den internen Mitarbeitern, den externen Dienstleistern sowie den Lieferanten des KRITIS- Betreibers neue Geheimhaltungs- oder Vertraulichkeitserklärungen abgeschlossen. Die Geheimhaltungs- oder Vertrau-lichkeitserklärungen sind vor Beginn des Vertragsverhältnisses bzw. vor Erteilung des Zugriffs auf Daten des KRITIS-Betreibers durch interne Mitarbeiter, externe Dienstleister oder Lieferanten des KRITIS-Betreibers zu unterzeichnen.

Soweit sich aus der Überprüfung Anpassungen an die Geheimhaltungs- oder Vertraulichkeitserklärungen ergeben, sind die internen und externen Mitarbeiter des Betreibers der Kritischen Infrastrukturen darüber in Kenntnis zu setzen und neue Bestätigungen einzuholen.

43. Richtlinien zur Entwicklung/Beschaffung von Informationssystemen(BEI-01) Richtlinien und Anweisungen mit technischen und organisatorischen Maßnahmen für die ordnungsge- mäße Entwicklung und/oder Beschaffung von Informationssystemen für die Entwicklung oder den Betrieb der kritischen Dienstleistung, einschließlich Anwendungen, Middleware, Datenbanken, Betriebssystemen und Netzwerkkomponenten sind gemäß IT-Sicherheitsrichtlinie dokumentiert, kommuniziert und bereit- gestellt.

In den Richtlinien und Anweisungen sind mindestens die folgenden Aspekte beschrieben:

• Sicherheit in der Softwareentwicklungsmethodik in Übereinstimmung mit in der Industrie etablierten Sicherheitsstandards (z.B. OWASP für Webapplikationen)

• Sicherheit der Entwicklungsumgebung (z.B. getrennte Entwicklungs-/Test-/Produktivumgebungen)

• Programmierrichtlinien für jede verwendete Programmiersprache (z. B. bzgl. Buffer Overflows, Ver- bergen interner Objektreferenzen gegenüber Benutzern)

• Sicherheit in der Versionskontrolle.

44. Auslagerung der Entwicklung(BEI-02) Bei ausgelagerter Entwicklung der kritischen Dienstleistung (oder Teilen davon) in Bezug auf Design, Entwicklung, Test und/oder Bereitstellung von Quellcode der kritischen Dienstleistung ist ein hohes Maß an Sicherheit gefordert. Deshalb sind mindestens die folgenden Aspekte vertraglich zwischen KRITIS- Betreiber und externem Dienstleister zu vereinbaren:

Bundesamt für Sicherheit in der Informationstechnik 15

Anforderungskatalog zur Konkretisierung der Kriterien des § 8a Absatz 1 und Absatz 1a BSIG

• Anforderungen an einen sicheren Software-Entwicklungsprozess (insbesondere Design, Entwicklung und Test)

• Bereitstellung von Nachweisen, dass eine ausreichende Prüfung vom externen Dienstleister durch- geführt wurde

• Abnahmeprüfung der Qualität der erbrachten Leistungen gemäß den vereinbarten funktionalen und nicht-funktionalen Anforderungen

• Das Recht, den Entwicklungsprozess und Kontrollen einer Prüfung, auch stichprobenartig, zu unterziehen.

45. Richtlinien zur Änderung von Informationssystemen(BEI-03) Richtlinien und Anweisungen mittechnischen und organisatorischen Maßnahmen für eine ordnungsge- mäße Verwaltung von Änderungen (Change Management) an Informationssystemen für die Entwicklung oder den Betrieb der kritischen Dienstleistung, einschließlich Anwendungen, Middleware, Datenbanken, Betriebssystemen und Netzwerkkomponenten sind gemäß IT-Sicherheitsrichtlinie dokumentiert, kom- muniziert und bereitgestellt.

Mindestens die folgenden Aspekte sind dabei zu berücksichtigen:

• Risikobeurteilung

• Kriterien zur Kategorisierung und Priorisierung von Änderungen und damit verbundene Anforderungen an Art und Umfang durchzuführender Tests und einzuholender Genehmigungen

• Anforderungen zur Benachrichtigung betroffener Stakeholder gemäß den vertraglichen Vereinbarungen

• Anforderungen an die Dokumentation von Tests sowie zur Beantragung und Genehmigung von Änderungen

• Anforderungen an die Durchführung von Roll-Backs

• Anforderungen an die Dokumentation von Änderungen in der System-, Betriebs-und Benutzerdokumentation

• Anforderungen an die Durchführung vonNotfalländerungen

• Anforderungen an die System-und Funktionstrennung.

46. Risikobewertung der Änderungen(BEI-04) Der Auftraggeber einer Änderung von Informationssystemen führt zuvor eine Risikobewertung durch. Alle möglicherweise von der Änderung betroffenenKonfigurationsobjekte werden auf potenzielle Auswirkungen hin bewertet. Das Ergebnis der Risikobewertung ist angemessen und nachvollziehbar zu dokumentieren.

47. Kategorisierung der Änderungen(BEI-05) Alle Änderungen von Informationssystemen werden basierendauf einer Risikobewertung kategorisiert (z. B. als geringfügige, erhebliche oder weitreichende Folgen), um eine angemessene Autorisierung vor Bereitstellung der Änderung in der Produktivumgebung einzuholen.

48. Priorisierung der Änderungen(BEI-06) Alle Änderungen werden basierend auf einer Risikobewertung priorisiert (z. B. als niedrig, normal, hoch, Notfall), um eine angemessene Autorisierung vor Bereitstellung der Änderung in der Produktivumgebung einzuholen.

49. Testen der Änderungen(BEI-07) Alle Änderungen an der kritischen Dienstleistung werden Tests (z. B. auf Integration, Regression, Sicherheit und Benutzerakzeptanz) während der Entwicklung und vor der Bereitstellung in der Produktivumgebung unterzogen. Die Tests werden von angemessen qualifiziertem Personal des KRITIS-Betreibers durchgeführt.

Bundesamt für Sicherheit in der Informationstechnik 16

Anforderungskatalog zur Konkretisierung der Kriterien des § 8a Absatz 1 und Absatz 1a BSIG

50. Zurückrollen der Änderungen(BEI-08) Es sind Abläufe definiert, um erforderliche Änderungen in Folge von Fehlern oder Sicherheitsbedenken zurückrollen zu können und betroffene Systeme oder Dienste im vorherigen Zustand wiederherzustellen.

51. Überprüfen von ordnungsgemäßer Testdurchführung und Genehmigung(BEI-09) Bevor eine Änderung in der Produktivumgebung veröffentlicht wird (Release), ist diese durch eine hierzu autorisierte Stelle oder ein entsprechendes Gremium dahingehend zu überprüfen, ob die geplanten Tests erfolgreich abgeschlossen und die erforderlichen Genehmigungen erteilt sind.

Für eine angemessene Zufallsstichprobe von Änderungen in der Produktivumgebung wird in einem risiko- orientierten Ansatz überprüft, obdie internen Anforderungen in Bezug auf ordnungsgemäße Klassifi- zierung, Test und Genehmigung von Änderungen eingehalten wurden.

52. Notfalländerungen(BEI-10) Notfalländerungen sind als solche von dem Änderungsmanager zu klassifizieren, der die Änderungsdoku- mentation vor Übertragung der Änderung in die Produktivumgebung erstellt.

Anschließend (z. B. innerhalb von 5 Werktagen) fügt der Änderungsmanager Begründung und Ergebnis der Übertragung der Notfalländerung zu der Änderungsdokumentation hinzu. Aus der Begründung muss her- vorgehen, warum der reguläre Änderungsprozess nicht durchlaufen werden konnte und was die Folgen einer Verzögerung durch Einhaltung des regulären Prozesses gewesen wären.

53. Systemlandschaft (BEI-11) Produktivumgebungen sind von Nicht-Produktivumgebungen physisch oder logisch getrennt, um unbe- fugten Zugriff oder Änderungen an Produktivdaten zu vermeiden. Produktivdaten werden nur im Rahmen von definierten Vorgaben in Test-oder Entwicklungsumgebungen repliziert, um deren Vertraulichkeit zu wahren.

54. Funktionstrennung(BEI-12) Verfahren zum Change Management beinhalten rollenbasierte Autorisierungen, um eine angemessene Funktionstrennung bei Entwicklung, Freigabe und Migration von Änderungen zwischen den Umgebungen sicherzustellen.

55. Richtlinien und Verfahren zur Risikominimierung des Zugriffs über mobile Endgeräte des KRITIS- Betreibers(MDM-01) Richtlinien und Anweisungen mit technischen und organisatorischen Maßnahmen für die ordnungsge- mäße Verwendung mobiler Endgeräte sowie andere Remote-Zugriffe (bspw. mobile Arbeitsplätze) im Ver- antwortungsbereich des KRITIS-Betreibers, die Zugriff auf IT-Systeme zur Entwicklung und zum Betrieb der kritischen Dienstleistung ermöglichen, sind gemäß IT-Sicherheitsrichtlinie dokumentiert, kommuni- ziert und bereitgestellt.

Darin werden mindestens folgende Aspekte beachtet, soweit diese auf die Situation des KRITIS-Betreibers anwendbar sind:

• Verschlüsselung der Geräte und der Datenübertragung

• verstärkter Zugriffsschutz

• erweitertes Identitäts-und Berechtigungsmanagement

• Verbot von Jailbreaking/Rooting

• Installation nur von freigegebenen Anwendungen aus als vertrauenswürdig eingestuften „App Stores“

• Bring-Your-Own-Device (BYOD) –Mindestanforderungen an private Endgeräte.

Bundesamt für Sicherheit in der Informationstechnik 17

Anforderungskatalog zur Konkretisierung der Kriterien des § 8a Absatz 1 und Absatz 1a BSIG

2.6 Personelle und organisatorische Sicherheit

56. Einstellung und Sicherheitsüberprüfung (HR-01) Die Vergangenheit aller internen und externen Mitarbeiter des KRITIS-Betreibers mit Zugriff auf die für die Erbringung der kritischen Dienstleistung notwendigen informationstechnischen Systeme, Komponenten und Prozesse wird vor Beginn des Beschäftigungsverhältnisses gemäß der lokalen Gesetzgebung und Regu- lierung durch den KRITIS-Betreiber überprüft. Besondere Genehmigungsverfahren im Einstellungsprozess für Mitarbeiter und Positionen, bei denen Zugriff auf besonders sensible Informationen besteht, sind eta- bliert.

Soweit rechtlich zulässig, umfasst die Überprüfung folgende Bereiche:

• Verifikation der Person durch Personalausweis

• Verifikation des Lebenslaufs

• Verifikation von akademischen Titeln undAbschlüssen

• Anfrage eines polizeilichen Führungszeugnisses bei sensiblen Positionen im Unternehmen.

Besondere Genehmigungsverfahren im Einstellungsprozess für Mitarbeiter und Positionen, bei denen Zu- griff auf besonders sensible Informationen besteht, sind etabliert.

57. Einstellung und Beschäftigungsvereinbarungen (HR-02) Beschäftigungsvereinbarungen beinhalten die Verpflichtungen der internen und externen Mitarbeiter des KRITIS-Betreibers auf Einhaltung einschlägiger Gesetze, Vorschriften und Regelungen in Bezug zur Infor- mationssicherheit. Die Sicherheitsleitlinie sowie die davon abgeleiteten Richtlinien und Anweisungen zur Informationssicherheit sindden Unterlagen zur Beschäftigungsvereinbarung beigefügt. Deren Einhaltung wird durch den Mitarbeiter schriftlich bestätigt, bevor Zugriff auf die kritische Dienstleistung oder die IT- Infrastruktur möglich ist.

58. Rollenzuweisung und Vieraugenprinzip oder Funktionstrennung (IDM-01) Ein auf den Geschäfts- und Sicherheitsanforderungen des KRITIS-Betreibers basierendes Rollen- und Rechtekonzept sowie eine Richtlinie zur Verwaltung von Zugangs- und Zugriffsberechtigungen sind dokumentiert, kommuniziert und bereitgestellt und adressieren die folgenden Bereiche:

• Die Vergabe und Änderung (Provisionierung) von Zugriffsberechtigungen auf Basis des Prinzips der ge- ringsten Berechtigung („Least Privilege Prinzip“) und wie es für die Aufgabenwahrnehmung notwendig ist („Need to know Prinzip“)

• Funktionstrennung zwischen operativen und kontrollierenden Funktionen („Separation of Duties“)

• Funktionstrennung in der Administration von Rollen, Genehmigung und Zuweisung von Zugriffsbe- rechtigungen

• regelmäßige Überprüfungvergebener Berechtigungen

• Berechtigungsentzug (Deprovisionierung) bei Veränderungen des Arbeitsverhältnisses

Anforderungen an Genehmigung und Dokumentation der Verwaltung von Zugangs- und Zugriffsberechti- gungen.

59. Identitäts-undBerechtigungsmanagement –Benutzerregistrierung (IDM-02) Zugangsberechtigungen für Benutzer unter Verantwortung des KRITIS-Betreibers (interne und externe Mitarbeiter) werden in einem formalen Verfahren erteilt. Organisatorische und/oder technische Maßnah- men stellen sicher, dass eindeutige Benutzerkennungen vergeben werden, die jeden Benutzer eindeutig identifizieren.

60. Identitäts-undBerechtigungsmanagement –Zugriffsberechtigung (IDM-03) Vergabe und Änderung von Zugriffsberechtigungen für Benutzer unter Verantwortung des KRITIS- Betreibers erfolgen gemäß der Richtlinie zur Verwaltung von Zugangs- und Zugriffsberechtigungen.

Bundesamt für Sicherheit in der Informationstechnik 18

Anforderungskatalog zur Konkretisierung der Kriterien des § 8a Absatz 1 und Absatz 1a BSIG

Organisatorische und/oder technische Maßnahmen stellen sicher, dass die vergebenen Zugriffe die folgenden Anforderungen erfüllen:

• Zugriffsberechtigungen entsprechen dem Prinzip der geringsten Berechtigung („Least-Privilege- Prinzip“)

• Zugriffsberechtigungen werden nur so vergeben, wie es für die Aufgabenwahrnehmung notwendig ist („Need-to-know-Prinzip“)

• die formalen Genehmigungen erfolgen durch eine autorisierte Person, bevor die Zugriffsberechtigungen eingerichtet werden (d. h. bevor der Benutzer auf die Systeme der kritischen Dienstleistung oder Kompo- nenten der geteilten IT-Infrastruktur zugreifen kann)

• die technisch zugewiesenen Zugriffsberechtigungen dürfen die formalen Genehmigungen nicht über- steigen.

61. Vergabe und Änderung (Provisionierung) von Zugriffsberechtigungen (IDM-04) Zugriffsberechtigungen von Benutzern unter Verantwortung des KRITIS-Betreibers (interne und externe Mitarbeiter) werden bei Änderungen im Beschäftigungsverhältnis (Kündigung, Versetzung, längerer Abwe- senheit/Sabbatical/Elternzeit) zeitnah, spätestens aber 30 Tage nach Inkrafttreten entzogen bzw. vorüber- gehend ruhe stellend gesetzt. Zugänge werden vollständig deaktiviert, sobald das Beschäftigungsverhältnis erlischt.

62. Identitäts- und Berechtigungsmanagement –Überprüfungen (IDM-05) Zugriffsberechtigungen von Benutzern unter Verantwortung des KRITIS-Betreibers (interne und externe Mitarbeiter) werden mindestens jährlich überprüft, um diese zeitnah auf Änderungen im Beschäftigungs- verhältnis (Kündigung, Versetzung, längerer Abwesenheit/Sabbatical/Elternzeit) anzupassen. Die Überprü- fung erfolgt durch hierzu autorisierte Personen aus den Unternehmensbereichen des KRITIS-Betreibers, die aufgrund ihres Wissens über die Zuständigkeiten die Angemessenheit der vergebenen Berechtigungen überprüfen können. Die Überprüfung sowie die sich daraus ergebenden Berechtigungsanpassungen werden nachvollziehbar dokumentiert. Administrative Berechtigungen werden regelmäßig (mind. jährlich) über- prüft.

63. Identitäts-und Berechtigungsmanagement –Administratoren (IDM-06) Vergabe undÄnderung von Zugriffsberechtigungen für interne und externe Benutzer mit administrativen oder weitreichenden Berechtigungen unter Verantwortung des KRITIS-Betreibers erfolgen gemäß der Richtlinie zur Verwaltung von Zugangs-und Zugriffsberechtigungen. DieZuweisung erfolgt personalisiert und wie es für die Aufgabenwahrnehmung notwendig ist („Need-to-know-Prinzip“). Organisatorische und/ oder technische Maßnahmen stellen sicher, dass durch die Vergabe dieser Berechtigungen keine ungewoll- ten, kritischen Kombinationen entstehen, die gegen das Prinzip der Funktionstrennung verstoßen (z. B. Zuweisen von Berechtigungen zur Administration der Datenbank wie auch des Betriebssystems). Soweit dies in ausgewählten Fällen nicht möglich ist, sind angemessene, kompensierende Kontrollen eingerichtet, um einen Missbrauch dieser Berechtigungen zu identifizieren (z.B. Protokollierung und Überwachung durch eine SIEM-Lösung (Security Information and Event Management)).

64. Identitäts-und Berechtigungsmanagement –Notfallbenutzer (IDM-09) Die Verwendung von Notfallbenutzern (für Aktivitäten, die mit personalisierten, administrativen Benutzern nicht durchgeführt werden können) ist dokumentiert, zu begründen und bedarf der Genehmigung durch eine autorisierte Person, die unter Berücksichtigung des Prinzips der Funktionstrennung zu erfolgen hat. Die Freischaltung des Notfallbenutzers erfolgt nur so lange, wie es für die Aufgabenwahrnehmung not- wendig ist.

Mindestens jährlich wird ein manueller Abgleich zwischen den erfolgten Freischaltungen der Notfall- benutzer und den entsprechenden Genehmigungen durchgeführt. Auffälligkeiten werden untersucht, um Missbrauch dieser Benutzer festzustellen und zukünftig zu verhindern. Die Aktivitäten der Notfallbenutzer werden revisionssicher protokolliert. Die Protokollierung ist hinreichend detailliert, um es einem sach- verständigen Dritten zu ermöglichen, die Aktivitäten nachzuvollziehen.

Bundesamt für Sicherheit in der Informationstechnik 19

Anforderungskatalog zur Konkretisierung der Kriterien des § 8a Absatz 1 und Absatz 1a BSIG

65. Festlegung notwendiger Kompetenzen (Betrieb und IT-Sicherheit) (SA-01) Von der Sicherheitsleitlinie abgeleitete Richtlinien und Anweisungen zur Informationssicherheit oder verwandter Themen sind nach einer einheitlichen Struktur dokumentiert. Sie werden sach-und bedarfs- gerecht an alle relevanten Stakeholder kommuniziert und bereitgestellt.

Sicherheitsleitlinien werden versioniert und von der Unternehmensleitung freigegeben.

Die Richtlinien und Anweisungen beschreiben mindestens die folgenden Aspekte:

• Ziele

• Geltungsbereiche

• Rollen und Verantwortlichkeiten einschließlich Anforderungen an die Qualifikation desPersonals und das Einrichten von Vertretungsregelungen

• die Koordination unterschiedlicher Unternehmensbereiche

• Sicherheitsarchitektur und -maßnahmen zum Schutz von Daten, IT-Anwendungen und IT-Infrastruk- turen, die durch den Betreiber der kritischen Dienstleistung oder von Dritten verwaltet werden sowie

• Maßnahmen zur Einhaltung rechtlicher und regulatorischer Anforderungen (Compliance).

66. Überprüfung und Freigabe von Richtlinien und Anweisungen (SA-02) Die Richtlinien und Anweisungen zur Informationssicherheit werden mindestens jährlich durch mit dem Thema vertraute Fachkräfte des Betreibers der kritischen Dienstleistung hinsichtlich ihrer Angemessenheit und Wirksamkeit überprüft.

Die Überprüfung berücksichtigt mindestens

• organisatorische Änderungen beim Betreiber der kritischen Dienstleistung,

• rechtliche und technische Änderungen im Umfeld des Betreibers der kritischen Dienstleistung.

Überarbeitete Richtlinien und Anweisungen werden durch hierzu autorisierte Gremien oder Stellen des Betreibers der kritischenDienstleistung genehmigt, bevor diese Gültigkeit erlangen.

Die regelmäßige Überprüfung wird durch zentrale Stellen beim Betreiber nachgehalten.

67. Abweichungen von bestehenden Richtlinien und Anweisungen (SA-03) Ausnahmen von Richtlinien und Anweisungen zur Informationssicherheit werden durch hierzu autorisier- te Gremien oder Stellen des Betreibers der kritischen Dienstleistung in dokumentierter Form genehmigt.

Die Angemessenheit genehmigter Ausnahmen und die Beurteilung der daraus entstehenden Risiken wird mindestens jährlich durch mit den Themen vertraute Fachkräfte des Betreibers der kritischen Dienstleis- tung vor dem Hintergrund der aktuellen und zukünftig erwarteten Bedrohungsumgebung in Bezug auf die Informationssicherheit überprüft.

68. Schulungen und Awareness (HR-03) Ein Programm zur zielgruppenorientierten Sicherheitsausbildung und Sensibilisierung zum Thema Infor- mationssicherheit existiert und ist verpflichtend für alle internen und externen Mitarbeiter des KRITIS- Betreibers. Das Programm wird regelmäßig in Bezug auf die gültigen Richtlinien und Anweisungen, den zugewiesenen Rollen und Verantwortlichkeiten sowie den bekannten Bedrohungen aktualisiert und ist dann erneut zu durchlaufen.

Das Programm umfasst mindestens die folgenden Inhalte:

• Die regelmäßige und dokumentierte Unterweisung hinsichtlich der sicheren Konfiguration und des sicheren Betriebs der für die kritische Dienstleistung erforderlichen IT-Anwendungen und IT-Infra- struktur, einschließlich mobiler Endgeräte

• die regelmäßige und dokumentierte Unterrichtung über bekannte Bedrohungen und

• das regelmäßige und dokumentierte Training des Verhaltens beim Auftreten sicherheitsrelevanter Ereignisse.

Bundesamt für Sicherheit in der Informationstechnik 20

Anforderungskatalog zur Konkretisierung der Kriterien des § 8a Absatz 1 und Absatz 1a BSIG

Externe Dienstleister und Lieferanten des KRITIS-Betreibers, die zum Betrieb der kritischen Dienstleistung beitragen, werden vertraglich verpflichtet, ihre Mitarbeiter und Unterauftragnehmer auf die spezifischen Sicherheitsanforderungen des KRITIS-Betreibers hinzuweisen und ihre Mitarbeiter allgemein zum Thema Informationssicherheit zu schulen.

Das Programm berücksichtigt verschiedene Profile und umfasst weiterführende Informationen für Positio- nen und Mitarbeiter, die umfangreiche Berechtigungen oder Zugriff auf sensible Daten haben. Externe Mit- arbeiter von Dienstleistern und Lieferanten des KRITIS-Betreibers, die zum Betrieb der kritischen Dienst- leistung beitragen, werden in den spezifischen Sicherheitsanforderungen des Betreibers der kritischen Infrastrukturen sowie allgemein zum Thema Informationssicherheit unterwiesen.

69. Disziplinarverfahren (HR-04) Ein Prozess für die Durchführung von Disziplinarmaßnahmen ist implementiert und an die Mitarbeiter kommuniziert, um die Konsequenzen von Verstößen gegen die gültigen Richtlinien und Anweisungen, sowie rechtliche Vorgaben und Gesetze transparent zu machen.

70. Beendigung des Beschäftigungsverhältnissess(HR-05) Interne sowie externe Mitarbeiter sind darüber informiert, dass die Verpflichtungen auf Einhaltung ein- schlägiger Gesetze, Vorschriften und Regelungen in Bezug zur Informationssicherheit auch bei einem Wechsel des Aufgabengebietes oder der Auflösung des Beschäftigungsverhältnisses bestehen bleiben.

2.7 Bauliche/physische Sicherheit

71. Rechenzentrumsversorgung (BCM-05) Die Versorgung der für den Betrieb der kritischen Dienstleistung notwendigen IT-Systeme (z.B. Elektrizität, Temperatur-und Feuchtigkeitskontrolle, Telekommunikation und Internetverbindung) ist abgesichert, überwacht und wird regelmäßig gewartet und getestet, um eine durchgängige Wirksamkeit zu gewähr- leisten. Sie ist mit automatischen Ausfallsicherungen und anderen Redundanzen konzipiert.

Die Wartung wird in Übereinstimmung mit den von den Lieferanten empfohlenen Wartungsintervallen und Vorgaben sowie ausschließlich von autorisiertem Personal durchgeführt.

Wartungsprotokolle einschließlich vermuteteroder festgestellter Mängel werden für den Zeitraum der zuvor vertraglich vereinbarten Frist aufbewahrt.

72. Perimeterschutz (PS-01) Es ist ein geeigneter Rahmen für die bauliche und physische Sicherheit, die zum sicheren Betrieb einer kritischen Dienstleistung notwendig ist, zu setzen. Die Begrenzungen von Räumlichkeiten oder Gebäuden, die sensible oder kritische Informationen, Informationssysteme oder sonstige Netzwerkinfrastruktur beherbergen, sind physisch solide und durch angemessene Sicherheitsmaßnahmen geschützt, die dem Stand der Technik entsprechen. Das Sicherheitskonzept beinhaltet die Einrichtung von verschiedenen Sicherheitszonen, die durch Sicherheitslinien als überwachte und gesicherte Übergänge zwischen den Zonen getrennt sind, wenn dies für den Schutz der kritischen Dienstleistung notwendig ist.

73. Physischer Zutrittsschutz (PS-02) Zugänge zu Räumlichkeiten oder Gebäuden, die sensible oder kritische Informationen, Informations- systeme oder sonstige Netzwerkinfrastruktur für den Betreiber einer kritischen Dienstleistung beherbergen, sind durch physische Zutrittskontrollen gesichert und überwacht, um unbefugten Zutritt zu verhindern.

74. Schutz vor Bedrohungen von außen (PS-03) Räumlichkeiten oder Gebäude, die sensible oder kritische Informationen, Informationssysteme oder sons- tige Netzwerkinfrastruktur für die kritische Dienstleistung beherbergen, sind durch bauliche, technische und organisatorische Maßnahmen vor Feuer, Wasser, Erdbeben, Explosionen, zivile Unruhen und andere Formen natürlicher undvon Menschen verursachter Bedrohungen geschützt.

An zwei georedundanten Standorten sind mindestens die folgenden Maßnahmen getroffen:

Bauliche Maßnahmen:

• Einrichtung eines eigenen Brandabschnitts für das Rechenzentrum

Bundesamt für Sicherheit in der Informationstechnik 21

Anforderungskatalog zur Konkretisierung der Kriterien des § 8a Absatz 1 und Absatz 1a BSIG

• Verwendung feuerbeständiger Materialien gemäß DIN 4102-1 oder EN 13501 (Feuerwiderstandsdauer von mindestens 90 Minuten).

• Technische Maßnahmen:

• Sensoren zum Überwachen von Temperatur und Luftfeuchtigkeit

• Aufschalten des Gebäudes an einer Brandmeldeanlage mit Meldung an die örtliche Feuerwehr

• Brandfrüherkennungs-und Löschanlage.

• Organisatorische Maßnahmen:

• Regelmäßige Brandschutzübungen und Brandschutzbegehungen, um die Einhaltung der Brandschutzmaßnahmen zu prüfen.

Es findet eine Überwachung der Umgebungsparameter statt. Bei Verlassen des zulässigen Regelbereichs werden Alarmmeldungen generiert und an die dafür zuständigen Stellen weitergeleitet.

75. Schutz vor Unterbrechungen durch Stromausfälle und andere derartige Risiken(PS-04) Dem Ausfall von Versorgungsleistungen wie Strom, Kühlung oder Netzanbindungen für Anlagen der kritischen Dienstleistung wird durch geeignete Maßnahmen und Redundanzen, in Abstimmung mit den Maßnahmen zur Betriebssicherheit, vorgebeugt.

Versorgungsleistungen für Strom und Telekommunikation, welche Daten transportieren oder Informa- tionssysteme versorgen, sind vor Abhören und Beschädigung geschützt.

Es findet eine Überwachung der Versorgungsleistungen statt. Bei Verlassen des zulässigen Regelbereichs werden Alarmmeldungen generiert und an die dafür zuständigen Stellen weitergeleitet.

Der Betreiber der kritischen Dienstleistung ermittelt und kommuniziert die Autark-Zeiten, die durch die getroffenen Maßnahmen bei Ausfall der Versorgungsleistungen oder beim Eintritt von außergewöhnlichen Ereignissen (z.B. Hitzeperioden, länger anhaltender Stromausfall) erreicht werden sowie die maximal tole- rierbaren Zeiten für einen Ausfall der Versorgungsleistungen.

Verträge für die Aufrechterhaltung der Notfallversorgung mit entsprechenden Dienstleistern sind abge- schlossen (z.B. für den Treibstoff der Notstromversorgung).

76. Wartung der Infrastruktur(PS-05) Richtlinien und Anweisungen mit technischen und organisatorischen Maßnahmen für die Erbringung der kritischen Dienstleistung sind dokumentiert, kommuniziert und bereitgestellt, welche die Wartung (insb. Fernwartung), Löschung, Aktualisierung und Wiederverwendung von Assets in der Informationsverar- beitung in ausgelagerten Räumlichkeiten oder durch externes Personal beschreiben.

2.8 Vorfallserkennung und -bearbeitung

77. Verantwortlichkeiten und Vorgehensmodell (SIM-01) Richtlinien und Anweisungen mit technischen und organisatorischen Maßnahmen sind gemäß der Infor- mationssicherheitsrichtlinie dokumentiert, kommuniziert und bereitgestellt, um eine schnelle, effektive und ordnungsgemäße Reaktion auf alle bekannten Sicherheitsvorfälle, i. S. von Störungen der Verfügbar- keit, Integrität, Authentizität und Vertraulichkeit ihrer informationstechnischen Systeme, Komponenten oder Prozesse, die zu einem Ausfall oder zu einer erheblichen Beeinträchtigungder Funktionsfähigkeit der betriebenen Kritischen Infrastrukturen geführt haben, zu gewährleisten.

Seitens des KRITIS-Betreibers sind dabei mindestens die in der Informationssicherheitsrichtlinie aufgeführ- ten Rollen zu besetzen, Vorgaben zur Klassifizierung, Priorisierung und Eskalation von Sicherheitsvorfällen zu definieren und Schnittstellen zum Incident Management sowie dem Business Continuity Management zu schaffen.

Zusätzlich hat der KRITIS-Betreiber ein Team zur Behandlung von Informationssicherheitsvorfällen ein- gerichtet, das zur koordinierten Lösung von konkreten Sicherheitsvorfällen beiträgt.

Bundesamt für Sicherheit in der Informationstechnik 22

Anforderungskatalog zur Konkretisierung der Kriterien des § 8a Absatz 1 und Absatz 1a BSIG

78. Bearbeitung von Sicherheitsvorfällen (SIM-03) Ereignisse, die einen Sicherheitsvorfall darstellen könnten, werden durch qualifiziertes Personal des KRITIS-Betreibers oder in Verbindung mit externen Sicherheitsdienstleistern klassifiziert, priorisiert und einer Ursachenanalyse unterzogen.

79. Dokumentation und Berichterstattung über Sicherheitsvorfälle (SIM-04) Alle Sicherheitsvorfälle werden gemäß Informationssicherheitsrichtlinie dokumentiert.

Eine verantwortliche Stelle für meldepflichtige Sicherheitsvorfälle ist eingerichtet. Eine Richtlinie ist um- gesetzt, die regelt, welche Sicherheitsvorfälle der verantwortlichen Stelle zu melden sind und welche Sicherheitsvorfälle gemäß den Vorgaben aus § 8b Absatz 4 BSIG unverzüglich an das BSI zu melden sind:

• Störungen der Verfügbarkeit, Integrität, Authentizität und Vertraulichkeit ihrer informationstechni- schen Systeme, Komponenten oder Prozesse, die zu einem Ausfall oder zu einer erheblichen Beein- trächtigung der Funktionsfähigkeit der von ihnen betriebenen Kritischen Infrastrukturen geführt haben

• erhebliche Störungen der Verfügbarkeit, Integrität, Authentizität und Vertraulichkeit ihrer infor- mationstechnischen Systeme, Komponenten oder Prozesse, die zu einem Ausfall oder zu einer er- heblichen Beeinträchtigung der Funktionsfähigkeit der von ihnen betriebenen Kritischen Infra- strukturen führen können.

80. Security Incident Event Management (SIM-05) Protokollierte Vorfälle werden zentral aggregiert und konsolidiert (Event-Korrelation). Regeln zur Erken- nung von Beziehungen zwischen Vorfällen und zur Beurteilung gemäß Kritikalität sind implementiert. Die Behandlung dieser Vorfälle erfolgt gemäß dem Security Incident Management Prozess.

81. Verpflichtung der Nutzer zur Meldung von Sicherheitsvorfällen an eine zentrale Stelle (SIM-06) Mitarbeiter und externe Geschäftspartner werden über ihre Verpflichtungen informiert. Falls erforderlich willigen sie dazu ein oder verpflichten sich vertraglich dazu, alle Sicherheitsereignisse zeitnah an eine zuvor benannte zentrale Stelle zu melden.

Zusätzlich wird darüber informiert, dass „Falschmeldungen“ von Ereignissen, die sich im Nachhinein nicht als Vorfälle herausstellen, keine negativen Folgen nach sich ziehen.

82. Auswertung und Lernprozess (SIM-07) Mechanismen sind vorhanden, um Art und Umfang der Sicherheitsvorfälle messen und überwachen sowie an unterstützende Stellen melden zu können. Die aus der Auswertung gewonnenen Informationen werden dazu verwendet, wiederkehrende oder mit erheblichen Folgen verbundene Vorfälle zu identifizieren und Notwendigkeiten für erweiterteSchutzmaßnahmen festzustellen.

2.9 Überprüfung im laufenden Betrieb

83. Anlassbezogene Prüfungen –Konzept (RB-17) Richtlinien und Anweisungen mit technischen und organisatorischen Maßnahmen sind gemäß Informa- tionssicherheitsrichtlinie dokumentiert, kommuniziert und bereitgestellt, um das zeitnahe Identifizieren und Adressieren von Schwachstellen aller KRITIS-relevanten IT-Systeme, die unter Verantwortung des KRITIS-Betreibers stehen, zu gewährleisten. Die Maßnahmen umfassen unter anderem:

• Regelmäßiges Identifizieren und Analysieren von Schwachstellen (Vulnerabilities)

• Regelmäßiges Nachhalten von Maßnahmen zum Adressieren identifizierterMaßnahmen (z. B. Ein- spielen von Sicherheitsaktualisierungen gemäß interner Zielvorgaben).

84. Umgang mit Schwachstellen, Störungen und Fehlern –Prüfung offener Schwachstellen (RB-21) Die IT-Systeme, welche der KRITIS-Betreiber für die Entwicklung und Erbringung der kritischen Dienstleis- tung verwendet, werden mindestens monatlich automatisiert auf bekannte Schwachstellen (Vulnerabilities) geprüft. Im Falle von Abweichungen zu den erwarteten Konfigurationen (u.a. dem erwarteten Patch-Level) werden die Gründe hierzu zeitnah analysiert und die Abweichungen behoben oder gemäß dem Ausnahme- prozess dokumentiert.

Bundesamt für Sicherheit in der Informationstechnik 23

Anforderungskatalog zur Konkretisierung der Kriterien des § 8a Absatz 1 und Absatz 1a BSIG

85. Informieren der Unternehmensleitung (SPN-01) Die Unternehmensleitung wird durch regelmäßige Berichte über den Stand der Informationssicherheit auf Grundlage der Sicherheitsprüfungen informiert und ist verantwortlich für die zeitnahe Behebung von daraus hervorgegangenen Feststellungen.

86. Interne Überprüfungen der Compliance von IT-Prozessen mit internen Informationssicherheitsrichtlinien und Standards (SPN-02) Qualifiziertes Personal (z. B. Interne Revision) oder durch den Betreiber der kritischen Dienstleistung be- auftragte sachverständige Dritte überprüfen jährlich die Compliance der internen IT-Prozesse mit den ent- sprechenden internen Richtlinien undStandards sowie der für den Betrieb der kritischen Dienstleistung rechtlichen, regulativen und gesetzlich vorgeschriebenen Anforderungen.

Die identifizierten Abweichungen werden priorisiert und in Abhängigkeit ihrer Kritikalität werden Maß- nahmen zur Behebung zeitnah definiert, nachverfolgt und umgesetzt.

Die Prüfung wird regelmäßig durchgeführt. Die Prüfung umfasst auch die Einhaltung der Anforderungen dieses Anforderungskatalogs.

87. Prüfungen in anderen, anderweitig vorgegebenen Prüfzyklen –interne IT-Prüfungen (SPN-03) Qualifiziertes Personal (z. B. Interne Revision) des KRITIS-Betreibers oder durch den KRITIS-Betreiber beauftragte sachverständige Dritte überprüfen mindestens jährlich die Compliance der IT-Systeme, soweit diese ganz oder teilweise im Verantwortungsbereich des KRITIS-Betreibers liegen und für die Entwicklung oder den Betrieb der kritischen Dienstleistung relevant sind, mit den entsprechenden internen Richtlinien und Standards sowie der für die kritischen Dienstleistungen relevanten rechtlichen, regulativen und ge- setzlich vorgeschriebenen Anforderungen. Die identifizierten Abweichungen werden priorisiert und in Abhängigkeit ihrer Kritikalität werden Maßnahmen zur Behebung zeitnah definiert, nachverfolgt und umgesetzt.

Der KRITIS-Betreiber verpflichtet seine Unterauftragnehmer zu solchen Prüfungen und lässt sich die Prüfberichte im gleichen Turnus vorlegen und verwertet sie bei seinen Überprüfungen.

88. Prüfungen in anderen, anderweitig vorgegebenen Prüfzyklen –Planung externer Audits (COM-02) Unabhängige Überprüfungen und Beurteilungen von Systemen oder Komponenten, die zur Erbringung der kritischen Dienstleistung beitragen, sind vom KRITIS-Betreiber so geplant, dass die folgenden Anforde- rungen erfüllt werden:

• Es erfolgt ausschließlich lesender Zugriff auf die kritische Dienstleistung und Daten.

• Aktivitäten, die möglicherweise die Verfügbarkeit der IT oder Komponenten beeinträchtigen und so zu Beeinträchtigungen der Verfügbarkeit der kritischen Dienstleistung führen könnten, werden außerhalb der regulären Geschäftszeiten bzw. nicht zu Zeiten von Lastspitzen durchgeführt.

• Die durchgeführten Aktivitäten werden protokolliert und überwacht.

Der KRITIS-Betreiber hat Vorkehrungen für außerplanmäßige Audits getroffen.

89. Prüfungen in anderen, anderweitig vorgegebenen Prüfzyklen –Durchführung externer Audits (SOM-03) Prüfungen und Beurteilungen von Prozessen, IT-Systemen und IT-Komponenten, soweit diese ganz oder teilweise im Verantwortungsbereich des KRITIS-Betreibers liegen und für den Betrieb der kritischen Dienst- leistung relevant sind, werden mindestens jährlich durch unabhängige Dritte (z.B. Wirtschaftsprüfer) durchgeführt, um Nichtkonformitäten mit rechtlichen, regulativen und gesetzlich vorgeschriebenen Anforderungen zu identifizieren. Die identifizierten Abweichungen werden priorisiert und in Abhängigkeit ihrer Kritikalität werden Maßnahmen zur Behebung zeitnah definiert, nachverfolgt und umgesetzt.

Falls notwendig, können außerplanmäßige Überprüfungen durch unabhängige Dritte durchgeführt werden.

Bundesamt für Sicherheit in der Informationstechnik 24

Anforderungskatalog zur Konkretisierung der Kriterien des § 8a Absatz 1 und Absatz 1a BSIG

90. Systematische Log-Auswertung –Konzept (RB-10, RB-14) Richtlinien und Anweisungen mit technischen und organisatorischen Maßnahmen sind gemäß SA-01 dokumentiert, kommuniziert und bereitgestellt, um Ereignisse auf allen Assets, die zur Entwicklung oder zum Betrieb der kritischen Dienstleistung verwendet werden, zu protokollieren und an zentraler Stelle aufzubewahren. Die Protokollierung umfasst definierte Ereignisse, welche die Sicherheit und Verfügbarkeit der kritischen Dienstleistung beeinträchtigen können, einschließlich einer Protokollierung des Aktivierens, Stoppens und Pausierens der verschiedenen Protokollierungen. Die Protokolle werden bei unerwarteten oder auffälligen Ereignissen durch autorisiertes Personal anlassbezogen überprüft, um eine zeitnahe Unter- suchung von Störungen und Sicherheitsvorfällen sowie das Einleiten geeigneter Maßnahmen zu ermög- lichen.

Ergänzende Informationen zur Basisanforderung

Sicherheitsrelevante Ereignisse sind u.a.

• An-und Abmeldevorgänge

• Erstellung, Änderung oder Löschung von Benutzern und Erweiterung der Berechtigungen

• Verwendung, Erweiterung und Änderungen von privilegierten Zugriffs-berechtigungen

• Nutzung von temporären Berechtigungen.

Da es sich bei den protokollierten Daten i. d. R. um personenbezogene Daten handelt, sind in dem Fall datenschutzrechtliche Anforderungen an die Aufbewahrung zu beachten und zu überprüfen. Erfahrungs- gemäß sollte eine Frist von einem Jahr nicht überschritten werden.

91. Systematische Log-Auswertung – kritische Assets (RB-12) Der KRITIS-Betreiber führt eine Liste aller protokollierungs- und überwachungskritischen Assets und überprüft diese Liste regelmäßig auf deren Aktualität und Korrektheit. Für diese kritischen Assets wurden Protokollierungs-und Überwachungsmaßnahmen definiert.

92. SystematischeLog-Auswertung –Aufbewahrung (RB-13) Die erstellten Protokolle werden auf zentralen Protokollierungsservern aufbewahrt, wo sie vor unautori- sierten Zugriffen und Veränderungen geschützt sind. Protokolldaten sind unverzüglich zu löschen, wenn sie zur Erreichung des Zwecks nicht mehr erforderlich sind. Zwischen den Protokollierungsservern und den protokollierten Assets erfolgt eine Authentisierung, um die Integrität und Authentizität der übertragenen und gespeicherten Informationen zu schützen. Die Übertragung erfolgt nach einer dem Stand der Technik entsprechenden Verschlüsselung oder über ein eigenes Administrationsnetz (Out-of-Band-Management).

93. Systematische Log-Auswertung –Konfiguration (RB-15) Der Zugriff und die Verwaltung der Protokollierungs-und Überwachungsfunktionalitäten ist beschränkt auf ausgewählte und autorisierte Mitarbeiter des KRITIS-Betreibers. Änderungen der Protokollierungen und Überwachungen werden vorab durch unabhängige und autorisierte Mitarbeiter überprüft und frei- gegeben.

Der Zugriff und die Verwaltung der Protokollierungs-und Überwachungsfunktionalitäten erfordert eine Multi-Faktor-Authentifizierung.

94. Systematische Log-Auswertung –Verfügbarkeit(RB-16) Die Verfügbarkeit der Protokollierungs-und Überwachungssoftware wird unabhängig überwacht. Bei einem Ausfall der Protokollierungs-und Überwachungssoftware werden die verantwortlichen Mitarbeiter umgehend informiert.

Die Protokollierungs-und Überwachungssoftware ist redundant vorhanden, um auch bei Ausfällen die Sicherheit und Verfügbarkeit der Systeme der kritischen Dienstleistung zu überwachen.

Bundesamt für Sicherheit in der Informationstechnik 25

Anforderungskatalog zur Konkretisierung der Kriterien des § 8a Absatz 1 und Absatz 1a BSIG

95. Penetrationstest(RB-18) Der KRITIS-Betreiber lässt mindestens jährlich Penetrationstests durch qualifiziertes internes Personal oder externe Dienstleister durchführen. Die Penetrationstests erfolgen nach einer dokumentierten Testmethodik und umfassen die für den sicheren Betrieb der kritischen Dienstleistung als kritisch definierte Infrastruktur- Komponenten, die im Rahmen einer Risiko-Analyse als solche identifiziert wurden. Art, Umfang Zeitpunkt/ Zeitraum und Ergebnisse werden für einen sachverständigen Dritten nachvollziehbar dokumentiert. Fest- stellungen aus den Penetrationstests werden bewertet und mindestens bei mittlerer bis sehr hoher Kritika- lität in Bezug auf die Vertraulichkeit, Integrität oder Verfügbarkeit der kritischen Dienstleistung nachver- folgt und behoben. Die Einschätzung der Kritikalität und der mitigierenden Maßnahmen zu den einzelnen Feststellungen werden dokumentiert.

96. Umgang mit Schwachstellen, Störungen und Fehlern –Integration mit Änderungs-und Incident- Management(RB-19) Richtlinien und Anweisungen mit technischen und organisatorischen Maßnahmen für den Umgang mit kritischen Schwachstellen sind gemäß SA-01 dokumentiert, kommuniziert und bereitgestellt.

Die Maßnahmen sind mit den Aktivitäten des Änderungsverfahrens (Change Management) und der Stö- rungs-und Fehlerbehebung (Incident Management) abgestimmt.

2.10 Externe Informationsversorgung und Unterstützung

97. Kontakt zu relevanten Behörden und Interessenverbänden (OIS-05) Angemessene und für den Anbieter der kritischen Dienstleistung relevante Kontakte zu Behörden und Interessenverbänden sind etabliert, um stets über aktuelle Bedrohungslagen und Gegenmaßnahmen in- formiert zu sein und zeitnah und angemessen darauf zu reagieren.

Es sind Verfahren definiert und dokumentiert, um die erhaltenen Informationen an die internen und ex- ternen Mitarbeiter des Anbieters der kritischen Dienstleistung zu kommunizieren und zeitnah und ange- messen darauf zu reagieren.

2.11 Lieferanten, Dienstleister und Dritte

98. Richtlinie zum Umgang mit und Sicherheitsanforderungen an Dienstleister des KRITIS-Betreibers (DLL-01) Richtlinien und Anweisungen zur Sicherstellung des Schutzes von Informationen (insb. deren Verfügbar- keit) auf sonstige Dritte (z.B. Dienstleister bzw. Lieferanten des KRITIS-Betreibers), die wesentliche Teile für den Betrieb der kritischen Dienstleistung beitragen, sind gemäß IT-Informationssicherheitsrichtlinie doku- mentiert, kommuniziert und bereitgestellt. Die Vorgaben dienen der Reduzierung von Risiken, die durch die Auslagerung von IT-Systemen entstehen können. Dabei werden mindestens die folgenden Aspekte berück- sichtigt:

• Definition und Beschreibung von Mindest-Sicherheitsanforderungen in Bezug auf die verarbeiteten Informationen, die sich an etablierten Informationssicherheitsstandards orientieren

• Anforderungen an das Incident-und Vulnerability-Management (insb. Benachrichtigungen und Kolla- borationen während einer Störungsbehebung)

• Weitergabe und vertragliche Verpflichtung auf die Mindest-Sicherheitsanforderungen auch an Unter- auftragnehmer, wenn diese nicht nur unwesentliche Teile zu Entwicklung oder Betrieb der kritischen Dienstleistung (z.B. RZ-Dienstleister) beitragen

• die Definition der Anforderungen ist in das Risikomanagement des KRITIS-Betreibers eingebunden. Diese müssen regelmäßig auf ihre Angemessenheit hin überprüft werden. (vgl. Nr. 14)

99. Kontrolle der Leistungserbringung und der Sicherheitsanforderungen an Dienstleister und Lieferanten des KRITIS-Betreibers (DLL-02) Verfahren zur regelmäßigen Überwachung und Überprüfung der vereinbarten Leistungen und Sicherheits- anforderungen von Dritten (z. B. Dienstleister bzw. Lieferanten des KRITIS-Betreibers), die wesentliche Teile für den Betrieb der kritischen Dienstleistungbeitragen, sind implementiert.

Bundesamt für Sicherheit in der Informationstechnik 26

Anforderungskatalog zur Konkretisierung der Kriterien des § 8a Absatz 1 und Absatz 1a BSIG

Die Maßnahmen umfassen mindestens:

• Regelmäßige Kontrolle von Dienstleistungsberichten (z. B. SLA-Reportings, Prüfungsberichten nach IDW PS 915 oder ISAE 3000), soweit diese von Dritten erbracht werden

• Überprüfung von sicherheitsrelevanten Vorfällen, Betriebsstörungen oder Ausfällen und Unterbrechun- gen, die mit der Dienstleistung zusammenhängen

• außerplanmäßige Überprüfungen nach wesentlichen Änderungen der Anforderungen oder des Umfelds. Die Notwendigkeit für außerplanmäßige Überprüfungen ist durch den KRITIS-Betreiber zu beurteilen und nachvollziehbar zu dokumentieren.

Festgestellte Abweichungen werden gemäß der Anforderung OIS-07 (vgl. Nr. 14) einer Risikoanalyse unterzogen, um diese zeitgerecht durch mitigierende Maßnahmen wirksam zu adressieren.

2.12 Meldewesen

100. Einrichtung einer Kontaktstelle Der Betreiber hat die Aufgaben und Zuständigkeiten für die Entgegennahme der Vorfallsmeldungen, deren Beurteilung sowie Weiterleitung an das BSI geregelt. Hierzu hat er eine Kontaktstelle gemäß §8b Absatz3 BSIG eingerichtet.

2.13 Systeme zur Angriffserkennung (SzA)

2.13.1 Protokollierung

101. Planung der Protokollierung (BSI OH SzA) In der Planungsphase SOLLTE, basierend auf den Ergebnissen der Risikoanalyse und in Anbetracht der kri- tischen Prozesse des Betreibers, eine schrittweise Vorgehensweise für die Umsetzung der Protokollierung geplant werden. Die Schritte MÜSSEN dabei so gewählt werden, dass eine angemessene Sichtbarkeit inner- halb angemessener Zeit erzielt wird.

Der Betreiber MUSS alle zur wirksamen Angriffserkennung auf System-bzw. Netzebene notwendigen Protokoll-und Protokollierungsdaten (siehe Glossar gemäß § 2 Absatz 8 und 8a BSIG) erheben, speichern und für die Auswertung bereitstellen, um sicherheitsrelevante Ereignisse (SRE) erkennen und bewerten zu können. Hierzu KÖNNEN zusätzliche Systeme eingesetzt werden, sodass zur wirksamen Angriffserkennung nicht jedes einzelne Gerät Protokollierungsdaten aufzeichnen muss und damit die Verfügbarkeit der Pro- duktivsysteme und damit der kritischen Dienstleistung gewährleistet werden kann. Die zur Speicherung notwendigen Systeme und deren IT-Sicherheitsvorkehrungen MÜSSEN schon in der Planung bedacht werden. Da die Protokollierung teilweise auch datenschutzrechtlich relevante Datensätze beinhalten kann, MUSS der legale Umgang mit diesen bei der Planung einbezogen werden. Ggf. ist dazu eine Anonymisierung bzw. Pseudonymisierung der Protokoll-und Protokollierungsdaten erforderlich.

Im Rahmen der Planung MÜSSEN alle Systeme identifiziert werden, die zur Aufrechterhaltung der kri- tischen Dienstleistung maßgeblich sind, damit deren Protokoll-und Protokollierungsdaten später erfasst werden können.

Sind die bestehenden Systeme nicht in der Lage, auskömmliche Protokoll-und Protokollierungsdaten be- reitzustellen, SOLLTE die Protokollierungsinfrastruktur so angepasst und/oder durch zusätzliche Maß- nahmen, Software oder Systeme ergänzt werden, dass Detektion und Reaktion im entsprechend der Risiko- analyse notwendigen Rahmen möglich sind.

Das anfallende Protokoll-und Protokollierungsdatenaufkommen KANN (und wird dringend empfohlen) anhand eines repräsentativen Systems pro Systemgruppe bestimmt werden.

Bundesamt für Sicherheit in der Informationstechnik 27

Anforderungskatalog zur Konkretisierung der Kriterien des § 8a Absatz 1 und Absatz 1a BSIG

Die Ergebnisse der Planungsphase MÜSSEN in einer geeigneten Form dokumentiert werden. Die Doku- mentation MUSS alle Netzbereiche, die Protokoll-und Protokollierungsdatenquellen, deren Beziehungen untereinander und den Datenfluss der Protokoll-und Protokollierungsdaten im Anwendungsbereich umfassen. Hierbei ist ein angemessener Abstraktions-und Detailgrad zu wählen, sodass der effektive Einsatz von SzA bewertet werden kann. Um dies zu unterstützen, SOLLTE insbesondere eine Gruppierung gleicher Systemgruppen innerhalb der Dokumentation erfolgen. Gleiche bzw. sehr ähnliche Netze (beispielsweise verschiedene Standorte mit gleichem Netzaufbau) können zusammengefasst werden. Darüber hinaus MUSS für jedes System bzw. für jede Systemgruppe dokumentiert werden, welche Ereignisse dieses bzw. diese protokolliert.

Es MUSS ein Prozess eingerichtet werden, der sicherstellt, dass die Protokollierung bei Veränderungen im Anwendungsbereich (Changes) entsprechend angepasst wird.

102. Erstellung einer Sicherheitsrichtlinie für die Protokollierung (SIM-01, BSI OH SzA, OPS.1.1.5A1) Ausgehend von der allgemeinen Sicherheitsrichtlinie der Institution MUSS eine spezifische Sicherheits- richtlinie für die Protokollierung erstellt werden. In dieser Sicherheitsrichtlinie MÜSSEN nachvollziehbar Anforderungen und Vorgaben beschrieben sein, wie die Protokollierung zu planen, aufzubauen und sicher zu betreiben ist. In der spezifischen Sicherheitsrichtlinie MUSS geregelt werden, wie, wo und was zu proto- kollieren ist. Dabei SOLLTEN sich Art und Umfang der Protokollierung am Schutzbedarf der Informationen orientieren.

Die spezifische Sicherheitsrichtlinie MUSS von dem oder der ISB gemeinsam mit den Fachverantwortlichen erstellt werden. Sie MUSS allen für die Protokollierung zuständigen Mitarbeitenden bekannt und grund- legend für ihre Arbeit sein. Wird die spezifische Sicherheitsrichtlinie verändert oder wird von den Anfor- derungen abgewichen, MUSS dies mit dem oder der ISB abgestimmt und dokumentiert werden. Es MUSS regelmäßig überprüft werden, ob die spezifische Sicherheitsrichtlinie noch korrekt umgesetzt ist. Die Ergebnisse der Überprüfung MÜSSEN dokumentiert werden.

103. Protokollierung auf System-und Netzebene (BSI OH SzA, OPS.1.1.5A3 –A5) Alle sicherheitsrelevanten Ereignisse von IT-Systemen und Anwendungen MÜSSEN protokolliert werden. Sofern die in der Protokollierungsrichtlinie als relevant definierten IT-Systeme und Anwendungen über eine Protokollierungsfunktion verfügen, MUSS diese benutzt werden. Wenn die Protokollierung eingerich- tet wird, MÜSSEN dabei die Vorgaben des herstellenden Unternehmens für die jeweiligen IT-Systemeoder Anwendungen beachtet werden. In angemessenen Intervallen MUSS stichpunktartig überprüft werden, ob die Protokollierung noch korrekt funktioniert. Die Prüfintervalle MÜSSEN in der Protokollierungsrichtlinie definiert werden. Falls betriebs-und sicherheitsrelevante Ereignisse nicht auf einem IT-System proto- kolliert werden können, MÜSSEN zusätzliche IT-Systeme zur Protokollierung (z.B. von Ereignissen auf Netzebene) integriert werden.

Die Systemzeit aller protokollierenden IT-Systeme und Anwendungen MUSS immer synchron sein. Es MUSS sichergestellt sein, dass das Datums-und Zeitformat der Protokolldateien einheitlich ist.

Bei der Protokollierung MÜSSEN die Bestimmungen aus den aktuellen Gesetzen zum Bundes-sowie Lan- desdatenschutz eingehalten werden(siehe CON.2 Datenschutz). Darüber hinaus MÜSSEN eventuelle Per- sönlichkeitsrechte bzw. Mitbestimmungsrechte der Mitarbeitendenvertretungen gewahrt werden. Ebenso MUSS sichergestellt sein, dass alle weiteren relevanten gesetzlichen Bestimmungen beachtetwerden. Proto- kollierungsdaten MÜSSEN nach einem festgelegten Prozess gelöscht werden. Es MUSS technisch unter- bunden werden, dass Protokollierungsdaten unkontrolliert gelöscht oder verändert werden.

Aufbau zentralisierter Protokollierungsinfrastrukturen: Alle gesammelten sicherheitsrelevanten Protokoll-und Protokollierungsdaten MÜSSEN an für den jewei- ligen Netzbereich zentralen3Stellen gespeichert werden. Die Zahl an zentralen Stellen zur Speicherung SOLLTE möglichst geringgehalten werden und sich mindestens an funktionalen Einheiten orientieren, sodass der Zugriff auf die gespeicherten Daten einfach erfolgen kann.

Die Protokollierungsinfrastruktur MUSS dazu ausreichend dimensioniert sein. Dafür MÜSSEN genügend technische, finanzielle und personelle Ressourcen verfügbar sein.

3Zentral im Sinne der Netzarchitektur

Bundesamt für Sicherheit in der Informationstechnik 28

Anforderungskatalog zur Konkretisierung der Kriterien des § 8a Absatz 1 und Absatz 1a BSIG

Bereitstellung von Protokoll-und Protokollierungsdaten für die Auswertung: Die gesammelten Protokoll-und Protokollierungsdaten MÜSSEN gefiltert, normalisiert, aggregiert und korreliert werden. Die so bearbeiteten Protokoll-und Protokollierungsdaten MÜSSEN geeignet verfügbar gemacht werden, damit sie ausgewertet werden können.

Eine zeitlich befristete Speicherung der unbearbeiteten Protokolldaten KANN den Detektionsprozess zu- sätzlich unterstützen.

Für die Erzielung einer angemessenen Sichtbarkeit von Angriffen SOLLTEN die Protokollierungsdaten- quellen auf Netzebene von außen (Netzgrenzen) nach innen (Netzbereiche) erschlossen werden.

Die Systemebene (kritische Anwendungen und Applikationen) SOLLTE ausgehend von den zentralen, kri- tischen Systemen, wie z. B. Prozessleit-und Automatisierungstechnik und Leitsystemen, erschlossen wer- den. Die Priorisierung zur Auswahl der Protokollierungsdatenquellen SOLLTE ausgehend von der Kritikali- tät der Systeme abgeleitet werden.

Nach erfolgreicher Umsetzung der Protokollierung MUSS geprüft werden, ob alle geplanten Protokollie- rungsdatenquellen gemäß der Planungumgesetzt wurden.

Sollten branchenspezifisch weitergehende gesetzliche oder regulatorische Anforderungen an die Protokol- lierung bestehen, so MÜSSEN diese ebenfalls entsprechend umgesetzt werden.

2.13.2 Detektion

104. Planung der Detektion (BSI OH SzA) Bei der Auswahl und dem Einsatz von Detektionsmaßnahmen MUSS eine umfassende und effiziente Ab- deckung der Bedrohungslandschaft erzielt werden. Dazu MÜSSEN die Ergebnisse der Risikoanalyse sowie die Größe und Struktur des Unternehmens in der Planung einbezogen werden. Zur Bestimmung der Ab- deckung KANN (und es wird empfohlen) eine standardisierte Methode angewendet werden (z.B. MITRE ATT&CK bzw. ATT&CK for ICS ). In Abhängigkeit der Unternehmensgröße und der Bedrohungslandschaft KANN eine separate Betrachtung von Detektionsmaßnahmen für die IT-und OT-Umgebung erforderlich sein.

105. Erstellung einer Sicherheitsrichtlinie für die Detektion von sicherheitsrelevanten Ereignissen (SRE) (BSI OH SzA, DER.1.A1) Ausgehend von der allgemeinen Sicherheitsrichtlinie der Institution MUSS eine spezifische Sicherheits- richtlinie für die Detektion von sicherheitsrelevanten Ereignissen erstellt werden. In der spezifischen Sicherheitsrichtlinie MÜSSEN nachvollziehbar Anforderungen und Vorgaben beschrieben werden, wie die Detektion von sicherheitsrelevanten Ereignissen geplant, aufgebaut und sicher betrieben werden kann. Die spezifische Sicherheitsrichtlinie MUSS allen im Bereich Detektion zuständigen Mitarbeitenden bekannt und grundlegend für ihre Arbeit sein. Falls die spezifische Sicherheitsrichtlinie verändert wird oder von den Anforderungen abgewichen wird, dann MUSS dies mit dem oder der verantwortlichen ISB abgestimmt und dokumentiert werden. Es MUSS regelmäßig überprüft werden, ob die spezifische Sicherheitsrichtlinie noch korrekt umgesetzt ist. Die Ergebnisse der Überprüfung MÜSSEN sinnvoll dokumentiert werden.

106. Einhaltung rechtlicher Bedingungen bei der Auswertung von Protokollierungsdaten (BSI OH SzA, DER.1.A2) Wenn Protokollierungsdaten ausgewertet werden, dann MÜSSEN dabei die Bestimmungen aus den aktu- ellen Gesetzen zum Bundes-und Landesdatenschutz eingehalten werden. Wenn Detektionssysteme einge- setzt werden, dann MÜSSEN die Persönlichkeitsrechte bzw. Mitbestimmungsrechte der Mitarbeitenden- vertretungen gewahrt werden. Ebenso MUSS sichergestellt sein, dass alle weiteren relevanten gesetzlichen Bestimmungen beachtet werden, z.B. das Telemediengesetz (TMG), das Betriebsverfassungsgesetz und das Telekommunikationsgesetz.

107. Festlegung von Meldewegen für sicherheitsrelevante Ereignisse (BSI OH SzA, DER.1.A3) Für sicherheitsrelevante Ereignisse MÜSSEN geeignete Melde-und Alarmierungswege festgelegt und doku- mentiert werden. Es MUSS bestimmt werden, welche Stellen wann zu informieren sind. Es MUSS aufgeführt sein, wie die jeweiligen Personen erreicht werden können. Je nach Dringlichkeit MUSS ein sicherheitsrele- vantes Ereignis über verschiedene Kommunikationswege gemeldet werden.

Bundesamt für Sicherheit in der Informationstechnik 29

Anforderungskatalog zur Konkretisierung der Kriterien des § 8a Absatz 1 und Absatz 1a BSIG

Alle Personen, die für die Meldung bzw. Alarmierung relevant sind, MÜSSEN über ihre Aufgaben informiert sein. Alle Schritte des Melde-und Alarmierungsprozesses MÜSSEN ausführlich beschrieben sein. Die ein- gerichteten Melde-und Alarmierungswege SOLLTEN regelmäßig geprüft, erprobt und aktualisiert werden, falls erforderlich.

108. Sensibilisierung der Mitarbeitenden [Vorgesetzte, Benutzende, Mitarbeitende] (BSI OH SzA, DER.1.A4) Alle Benutzenden MÜSSEN dahingehend sensibilisiert werden, dass sie Ereignismeldungen ihrer Clients nicht einfach ignorieren oder schließen. Sie MÜSSEN die Meldungen entsprechend der Alarmierungswege an das verantwortliche Incident Management weitergeben.

Alle Mitarbeitenden MÜSSEN einen von ihnen erkannten Sicherheitsvorfall unverzüglich dem Incident Management melden.

109. Einsatz von mitgelieferten Systemfunktionen zur Detektion [Fachverantwortliche] (BSI OH SzA, DER.1.A5) Falls eingesetzte IT-Systeme oder Anwendungen über Funktionen verfügen, mit denen sich sicherheitsrele- vante Ereignisse detektieren lassen, dann MÜSSEN diese aktiviert und benutzt werden. Falls ein sicherheits- relevanter Vorfall vorliegt, dann MÜSSEN die Meldungen der betroffenen IT-Systeme ausgewertet werden. Zusätzlich MÜSSEN die protokollierten Ereignisse anderer IT-Systeme überprüft werden. Auch SOLLTEN die gesammelten Meldungen in verbindlich festgelegten Zeiträumen stichpunktartig kontrolliert werden.

Es MUSS geprüft werden, ob zusätzliche Schadcodescanner auf zentralen IT-Systemen installiert werden sollen. Falls zusätzliche Schadcodescanner eingesetzt werden, dann MÜSSEN diese es über einen zentralen Zugriff ermöglichen, ihre Meldungen und Protokolle auszuwerten. Es MUSS sichergestellt sein, dass die Schadcodescanner sicherheitsrelevante Ereignisse automatisch an die Zuständigen melden. Die Zuständigen MÜSSEN die Meldungen auswerten und untersuchen.

110. Kontinuierliche Überwachung und Auswertung von Protokoll-und Protokollierungsdaten (BSI OH SzA) Alle Protokoll-und Protokollierungsdaten MÜSSEN kontinuierlich überwacht und ausgewertet werden. Dies KANN automatisiert werden, wenn bei relevanten Ereignissen eine unmittelbare Alarmierung der Ver- antwortlichen gewährleistet ist. Die Prüfung des Ereignisses und ggf. die Reaktion MUSS innerhalb einer der Risikoanalyse entsprechend geringen Zeitspanne erfolgen. Es MÜSSEN Mitarbeitende bzw. Mitarbeitende von Dienstleistern benannt werden, die dafür zuständig sind.

Müssen die verantwortlichen Mitarbeitenden aktiv nach sicherheitsrelevanten Ereignissen suchen, z.B. wenn sie IT-Systeme kontrollieren oder testen, MÜSSEN solche Aufgaben in entsprechenden Verfahrens- anleitungen dokumentiertsein.

Für die Detektion von sicherheitsrelevanten Ereignissen MÜSSEN genügend personelle Ressourcen bereit- gestellt werden.

111. Einsatz zusätzlicher Detektionssysteme (BSI OH SzA) Es MÜSSEN Schadcodedetektionssysteme eingesetzt und zentral verwaltet werden. Anhand des Netzplans MUSS festgelegt werden, welche Netzsegmente durch zusätzliche Detektionssysteme geschützt werden müssen. Insbesondere MÜSSEN die im Netzplan definierten Übergänge zwischen internen und externen Netzen um netzbasierte Intrusion Detection Systeme (NIDS) ergänzt werden.

112. Infrastruktur zur Auswertung von Protokoll-und Protokollierungsdaten und Prüfung sicherheitsrelevanter Ereignisse (BSI OH SzA) Damit die Protokoll-und Protokollierungsdaten korreliert und abgeglichen werden können, SOLLTEN sie alle zeitlich synchronisiert werden. Die gesammelten Ereignismeldungen MÜSSEN regelmäßig auf Auf- fälligkeiten kontrolliert werden. Damit sicherheitsrelevante Ereignisse auch nachträglich erkannt werden können, MÜSSEN die Signaturen der Detektionssysteme immer auf aktuellstem Stand gehalten werden.

Bundesamt für Sicherheit in der Informationstechnik 30

Anforderungskatalog zur Konkretisierung der Kriterien des § 8a Absatz 1 und Absatz 1a BSIG

113. Auswertung von Informationen aus externen Quellen (BSI OH SzA) Um neue Erkenntnisse über sicherheitsrelevante Ereignisse für den eigenen Informationsverbund zu ge- winnen, MÜSSEN externe Quellen herangezogen werden. Da Meldungen über unterschiedliche Kanäle in eine Institution gelangen, MUSS sichergestellt sein, dass diese Meldungen von den Mitarbeitenden auch als relevant erkannt und an die richtige Stelle weitergeleitet werden. Informationen aus zuverlässigen Quellen MÜSSEN grundsätzlich ausgewertet werden. Alle gelieferten Informationen MÜSSEN danach bewertet werden, ob sie relevant für den eigenen Informationsverbund sind. Ist dies der Fall, MÜSSEN die Informa- tionen entsprechend der Sicherheitsvorfallbehandlung eskaliert werden.

114. Auswertung der Protokoll-und Protokollierungsdaten durch spezialisiertes Personal (BSI OH SzA) Es MÜSSEN Mitarbeitende bzw. Mitarbeitende von Dienstleistern speziell damit beauftragt werden, alle Protokoll-und Protokollierungsdaten auszuwerten. Die Auswertung der Protokoll-und Protokollierungs- daten SOLLTE bei diesen höher priorisiert sein, als ihre übrigen Aufgaben. Daher empfiehlt es sich, dass dies ihre überwiegende Aufgabe ist. Dieses Personal SOLLTE spezialisierte weiterführende Schulungen und Qualifikationen erhalten. Ein Personenkreis MUSS benannt werden, der für das Thema Auswertung von Protokoll-und Protokollierungsdaten verantwortlich ist.

115. Zentrale Detektion und Echtzeitüberprüfungen von Ereignismeldungen (BSI OH SzA) EsMÜSSEN zentrale Komponenten eingesetzt werden, um sicherheitsrelevante Ereignisse zu erkennen und auszuwerten. Zentrale automatisierte Analysen mit Softwaremitteln MÜSSEN dazu eingesetzt werden, um alle in der Systemumgebung anfallenden Protokoll-und Protokollierungsdaten aufzuzeichnen, in Bezug zueinander zu setzen und sicherheitsrelevante Vorgänge sichtbar zu machen. Alle eingelieferten Protokoll- und Protokollierungsdaten MÜSSEN lückenlos in der Protokollverwaltung einsehbar und auswertbar sein. Die Daten MÜSSEN kontinuierlich ausgewertet werden.

Werden definierte Schwellenwerte überschritten, MUSS automatisch alarmiert werden. Das zuständige Personal4MUSS sicherstellen, dass bei einem Alarm nach fachlicher Bewertung und innerhalb einer der Risikoanalyse entsprechend geringen Zeitspanne eine qualifizierte und dem Bedarf entsprechende Reaktion eingeleitet wird. Die Systemverantwortlichen MÜSSEN regelmäßig die Analyseparameter auditieren und anpassen, falls dies erforderlich ist. Zusätzlich MÜSSEN bereitsüberprüfte Protokoll-und Protokollierungs- daten regelmäßig hinsichtlich sicherheitsrelevanter Ereignisse automatisch untersucht werden.

116. Qualifizierung von sicherheitsrelevanten Ereignissen (BSI OH SzA) Als eine zentrale Grundvoraussetzung für die effektive Detektion MÜSSEN zudem Informationen zu aktuel- len Angriffsmustern für technische Vulnerabilitäten fortlaufend für die im Anwendungsbereich eingesetz- ten Systeme eingeholt werden. Dazu MÜSSEN fortlaufend Meldungen der Hersteller (Hard-und Software), von Behörden, den Medien und weiterer relevanter Stellen geprüft werden und in dokumentierte Prozesse des Schwachstellenmanagements einfließen.

Bei der Umsetzung von Detektionsmechanismen SOLLTE initial eine Kalibrierung durchgeführt werden, um festzustellen, welche sicherheitsrelevanten Ereignisse (SRE) im Normalzustand auftreten (Baselining). Dazu SOLLTE bewertet werden, ob dieser Normalzustand in Hinblick auf die Zahl der falsch positiven Mel- dungen hingenommen werden kann oder ob Änderungen vorzunehmen sind. Die Kalibrierung SOLLTE bei Änderungen innerhalb des Anwendungsbereichs oder der Bedrohungslage erneut durchgeführt werden.

Die SRE MÜSSEN überprüft und dahingehend bewertet werden, ob sie auf einen Sicherheitsvorfall (qualifi- zierter SRE) hindeuten. Die zur Angriffserkennung eingesetzten Systeme sollten, in eindeutig zuordenbaren Fällen, eine automatisierte Qualifizierung der SRE ermöglichen. Nur qualifizierte SRE SOLLTEN den Prozess der Reaktion auslösen. Die Qualifizierung SOLLTE in automatisiert nicht eindeutig zuordenbaren Fällen manuell durch festgelegte Verantwortliche vorgenommen werden. Basierend auf den gewonnenen Er- kenntnissen der Qualifizierung MÜSSEN die Detektionsmechanismen nachjustiert werden.

Sollten branchenspezifisch weitergehende gesetzliche oder regulatorische Anforderungen bestehen, so MÜSSEN diese ebenfalls entsprechend umgesetzt werden.

4 Eigenes oder das eines Dienstleisters

Bundesamt für Sicherheit in der Informationstechnik 31

Anforderungskatalog zur Konkretisierung der Kriterien des § 8a Absatz 1 und Absatz 1a BSIG

2.13.3 Reaktion

117. Definition eines Sicherheitsvorfalls (BSI OH SzA, DER.2.1.A1) In einer Institution MUSS klar definiert sein, was ein Sicherheitsvorfall ist. Ein Sicherheitsvorfall MUSS so weit wie möglich von Störungen im Tagesbetrieb abgegrenzt sein. Alle an der Behandlung von Sicherheits- vorfällen beteiligten Mitarbeitenden MÜSSEN die Definition eines Sicherheitsvorfalls kennen. Die Defini- tion und die Eintrittsschwellen eines solchen Vorfalls SOLLTEN sich nach dem Schutzbedarf der betroffe- nen Geschäftsprozesse, IT-Systeme bzw. Anwendungen richten.

118. Erstellung einer Richtlinie zur Behandlung von Sicherheitsvorfällen (BSI OH SzA, DER.2.1.A2) Eine Richtlinie zur Behandlung von Sicherheitsvorfällen MUSS erstellt werden. Darin MÜSSEN Zweck und Ziel der Richtlinie definiert sowie alle Aspekte der Behandlung von Sicherheitsvorfällen geregelt werden. So MÜSSEN Verhaltensregeln für die verschiedenen Artenvon Sicherheitsvorfällen beschrieben sein. Zusätz- lich MUSS es für alle Mitarbeitenden zielgruppenorientierte und praktisch anwendbare Handlungsanwei- sungen geben. Weiterhin SOLLTEN die Schnittstellen zu anderen Managementbereichen berücksichtigt werden, z.B. zum Notfallmanagement.

Die Richtlinie MUSS allen Mitarbeitenden bekannt sein. Sie MUSS mit dem IT-Betrieb abgestimmt und durch die Institutionsleitung verabschiedet sein. Die Richtlinie MUSS regelmäßig geprüft und aktualisiert werden.

119. Festlegung von Verantwortlichkeiten und Ansprechpersonen bei Sicherheitsvorfällen (BSI OH SzA, DER.2.1.A3)) Es MUSS geregelt werden, wer bei Sicherheitsvorfällen wofür verantwortlich ist. Für alle Mitarbeitenden MÜSSEN die Aufgaben und Kompetenzen bei Sicherheitsvorfällen festgelegt werden. Insbesondere Mit- arbeitende, die Sicherheitsvorfälle bearbeiten sollen, MÜSSEN über ihre Aufgaben und Kompetenzen un- terrichtet werden. Dabei MUSS auch geregelt sein, wer die mögliche Entscheidung für eine forensische Untersuchung trifft, nach welchen Kriterien diese vorgenommen wird und wann sie erfolgen soll.

Die Ansprechpartner oder Ansprechpartnerinnen für alle Arten von Sicherheitsvorfällen MÜSSEN den Mitarbeitenden bekannt sein. Kontaktinformationen MÜSSEN immer aktuell und leicht zugänglich sein.

120. Benachrichtigung betroffener Stellen bei Sicherheitsvorfällen [Institutionsleitung, IT-Betrieb, Datenschutzbeauftragte, Notfallbeauftragte] (BSI OH SzA, DER.2.1.A4) Von einem Sicherheitsvorfall MÜSSEN alle betroffenen internen und externen Stellen zeitnah informiert werden. Dabei MUSS geprüft werden, ob der oder die Datenschutzbeauftragte, der Betriebs-und Personalrat sowie Mitarbeitende aus der Rechtsabteilung einbezogen werden müssen. Ebenso MÜSSEN die Melde- pflichten für Behörden und regulierte Branchen berücksichtigt werden. Außerdem MUSS gewährleistet sein, dass betroffene Stellen über die erforderlichen Maßnahmen informiert werden.

121. Behebung von Sicherheitsvorfällen [IT-Betrieb] (BSI OH SzA, DER.2.1.A5) Damit ein Sicherheitsvorfall erfolgreich behoben werden kann, MÜSSEN die Zuständigen zunächst das Problem eingrenzen und die Ursache finden. Danach MÜSSEN die erforderlichen Maßnahmen auswählt werden, um das Problem zu beheben. Die Leitung des IT-Betriebs MUSS eine Freigabe erteilen, bevor die Maßnahmen umgesetzt werden. Anschließend MUSS die Ursache beseitigt und ein sicherer Zustand her- gestellt werden.

Eine aktuelle Liste von internen und externen Sicherheitsfachleuten MUSS vorhanden sein, die bei Sicher- heitsvorfällen für Fragen aus den erforderlichen Themenbereichen hinzugezogen werden können. Es MÜSSEN sichere Kommunikationsverfahren mit diesen internen und externen Stellen etabliert werden.

Bundesamt für Sicherheit in der Informationstechnik 32

Anforderungskatalog zur Konkretisierung der Kriterien des § 8a Absatz 1 und Absatz 1a BSIG

122. Wiederherstellung der Betriebsumgebung nach Sicherheitsvorfällen [IT-Betrieb] (BSI OH SzA, DER.2.1.A6) Nach einem Sicherheitsvorfall MÜSSEN die betroffenen Komponenten vom Netz genommen werden. Zudem MÜSSEN alle erforderlichen Daten gesichert werden, die Aufschluss über die Art und Ursache des Problems geben könnten. Auf allen betroffenen Komponenten MÜSSEN das Betriebssystem und alle Applikationen auf Veränderungen untersucht werden. Die Originaldaten MÜSSEN von schreibgeschützten Datenträgern wieder eingespielt werden. Dabei MÜSSEN alle sicherheitsrelevanten Konfigurationen und Patches mit aufgespielt werden. Wenn Daten aus Datensicherungen wieder eingespielt werden, MUSS sichergestellt sein, dass diese vom Sicherheitsvorfall nicht betroffen waren. Nach einem Angriff MÜSSEN alle Zugangsdaten auf den betroffenen Komponenten geändert werden, bevor sie wieder in Betrieb genom- men werden. Die betroffenen Komponenten SOLLTEN einem Penetrationstest unterzogen werden, bevor sie wieder eingesetzt werden. Bei der Wiederherstellung der sicheren Betriebsumgebung MÜSSEN die Benutzenden in die Anwendungsfunktionstests einbezogen werden. Nachdem alles wiederhergestellt wurde, MÜSSEN die Komponenten inklusive der Netzübergänge gezielt überwacht werden.

123. Etablierung einer Vorgehensweise zur Behandlung von Sicherheitsvorfällen [Institutionsleitung] (BSI OH SzA, DER.2.1.A7) Es SOLLTE eine geeignete Vorgehensweise zur Behandlung von Sicherheitsvorfällen definiert werden. Die Abläufe, Prozesse und Vorgaben für die verschiedenen Sicherheitsvorfälle SOLLTEN dabei eindeutig ge- regelt und geeignet dokumentiert werden. Die Institutionsleitung SOLLTE die festgelegte Vorgehensweise in Kraft setzen und allen Beteiligten zugänglich machen. Es SOLLTE regelmäßig überprüft werden, ob die Vorgehensweise noch aktuell und wirksam ist. Bei Bedarf SOLLTE die Vorgehensweise angepasst werden.

124. Aufbau von Organisationsstrukturen zur Behandlung von Sicherheitsvorfällen (BSI OH SzA, DER.2.1.A8) Für den Umgang mit Sicherheitsvorfällen SOLLTEN geeignete Organisationsstrukturen festgelegt werden. Es SOLLTE ein Sicherheitsvorfall-Team aufgebaut werden, dessen Mitglieder je nach Art des Vorfalls ein- berufen werden können. Auch wenn das Sicherheitsvorfall-Team nur für einen konkreten Fall zusammen- tritt, SOLLTEN bereits im Vorfeld geeignete Mitglieder benannt und in ihre Aufgaben eingewiesen sein. Es SOLLTE regelmäßig geprüft werden, ob die Zusammensetzung des Sicherheitsvorfall-Teams noch ange- messen ist. Gegebenenfalls SOLLTE das Sicherheitsvorfall-Team neu zusammengestellt werden.

125. Festlegung von Meldewegen für Sicherheitsvorfälle (BSI OH SzA, DER.2.1.A9) Für die verschiedenen Arten von Sicherheitsvorfällen SOLLTEN die jeweils passenden Meldewege aufgebaut sein. Es SOLLTE dabei sichergestellt sein, dass Mitarbeitende Sicherheitsvorfälle über verlässliche und ver- trauenswürdige Kanäle schnell und einfach melden können.

Wird eine zentrale Anlaufstelle für die Meldung von Störungen oder Sicherheitsvorfällen eingerichtet, SOLLTE dies an alle Mitarbeitende kommuniziert werden.

Eine Kommunikations-und Kontaktstrategie SOLLTE vorliegen. Darin SOLLTE geregelt sein, wer grund- sätzlich informiert werden muss und wer informiert werden darf, durch wen dies in welcher Reihenfolge erfolgt und in welcher Tiefe informiert wird. Es SOLLTE definiert sein, wer Informationen über Sicherheits- vorfälle an Dritte weitergibt. Ebenso SOLLTE sichergestellt sein, dass keine unautorisierten Personen Informationen über den Sicherheitsvorfall weitergeben.

126. Eindämmen der Auswirkung von Sicherheitsvorfällen [Notfallbeauftragte, IT-Betrieb] (BSI OH SzA, DER.2.1.A10) Parallel zur Ursachenanalyse eines Sicherheitsvorfalls SOLLTE entschieden werden, ob es wichtiger ist, den entstandenen Schaden einzudämmen oder den Vorfall aufzuklären. Um die Auswirkung eines Sicherheits- vorfalls abschätzen zu können, SOLLTEN ausreichend Informationen vorliegen. Für ausgewählte Sicher- heitsvorfallszenarien SOLLTEN bereits im Vorfeld Worst-Case-Betrachtungen durchgeführt werden.

127. Einstufung von Sicherheitsvorfällen [IT-Betrieb] (BSI OH SzA, DER.2.1.A11) Ein einheitliches Verfahren SOLLTE festgelegt werden, um Sicherheitsvorfälle und Störungen einzustufen. Das Einstufungsverfahren für Sicherheitsvorfälle SOLLTE zwischen Sicherheitsmanagement und der Störungs-und Fehlerbehebung (Incident Management) abgestimmt sein.

Bundesamt für Sicherheit in der Informationstechnik 33

Anforderungskatalog zur Konkretisierung der Kriterien des § 8a Absatz 1 und Absatz 1a BSIG

128. Festlegung der Schnittstellen der Sicherheitsvorfallbehandlung zur Störungs-und Fehlerbehebung [Notfallbeauftragte] (BSI OH SzA, DER.2.1.A12) Die Schnittstellen zwischen Störungs-und Fehlerbehebung, Notfallmanagement und Sicherheitsmanage- ment SOLLTEN analysiert werden. Dabei SOLLTEN auch eventuell gemeinsam benutzbare Ressourcen identifiziert werden. Die bei der Störungs-und Fehlerbehebung beteiligten Mitarbeitenden SOLLTEN für die Behandlung von Sicherheitsvorfällen sowie für das Notfallmanagement sensibilisiert werden. Das Sicherheitsmanagement SOLLTE lesenden Zugriff auf eingesetzte Incident-Management-Werkzeuge haben.

129. Einbindung in das Sicherheits-und Notfallmanagement [Notfallbeauftragte] (BSI OH SzA, DER.2.1.A13) Die Behandlung von Sicherheitsvorfällen SOLLTE mit dem Notfallmanagement abgestimmt sein. Falls es in der Institution eine spezielle Rolle für Störungs-und Fehlerbehebung gibt, SOLLTE auch diese mit einbe- zogen werden.

130. Eskalationsstrategie für Sicherheitsvorfälle [IT-Betrieb] (BSI OH SzA, DER.2.1.A14) Über die Kommunikations-und Kontaktstrategie hinaus SOLLTE eine Eskalationsstrategie formuliert wer- den. Diese SOLLTE zwischen den Verantwortlichen für Störungs-und Fehlerbehebung und dem Informa- tionssicherheitsmanagement abgestimmt werden.

Die EskalationsstrategieSOLLTE eindeutige Handlungsanweisungen enthalten, wer auf welchem Weg bei welcher Art von erkennbaren oder vermuteten Sicherheitsstörungen wann einzubeziehen ist. Es SOLLTE geregelt sein, zu welchen Maßnahmen eine Eskalation führt und wie reagiert werden soll.

Für die festgelegte Eskalationsstrategie SOLLTEN geeignete Werkzeuge wie z. B. Ticket-Systeme ausgewählt werden. Diese SOLLTEN sich auch dafür eignen, vertrauliche Informationen zu verarbeiten. Es SOLLTE sichergestellt sein, dass die Werkzeuge auch während eines Sicherheitsvorfalls bzw. Notfalls verfügbar sind.

Die Eskalationsstrategie SOLLTE regelmäßig überprüft und gegebenenfalls aktualisiert werden. Die Check- listen (Matching Szenarios) für Störungs-und Fehlerbehebung SOLLTEN regelmäßig um sicherheitsrele- vante Themen ergänzt bzw. aktualisiert werden. Die festgelegten Eskalationswege SOLLTEN in Übungen erprobt werden.

131. Schulung der Mitarbeitenden des Service Desks [IT-Betrieb] (BSI OH SzA, DER.2.1.A15) Dem Personal des Service Desks SOLLTEN geeignete Hilfsmittel zur Verfügung stehen, damit sie Sicher- heitsvorfälle erkennen können. Sie SOLLTEN ausreichend geschult sein, um die Hilfsmittel selbst anwenden zu können. Die Mitarbeitenden des Service Desks SOLLTEN den Schutzbedarf der betroffenen IT-Systeme kennen.

132. Dokumentation der Behebung von Sicherheitsvorfällen (BSI OH SzA, DER.2.1.A16) Die Behebung von Sicherheitsvorfällen SOLLTE nach einem standardisierten Verfahren dokumentiert wer- den. Es SOLLTEN alle durchgeführten Aktionen inklusive der Zeitpunkte sowie die Protokolldaten der be- troffenen Komponenten dokumentiert werden. Dabei SOLLTE die Vertraulichkeit bei der Dokumentation und Archivierung der Berichte gewährleistet sein.

Die benötigten Informationen SOLLTEN in die jeweiligen Dokumentationssysteme eingepflegt werden, bevor die Störung als beendet und als abgeschlossen markiert wird. Im Vorfeld SOLLTEN mit dem oder der ISB die dafür erforderlichen Anforderungen an die Qualitätssicherung definiert werden.

133. Nachbereitung von Sicherheitsvorfällen (BSI OH SzA, DER.2.1.A17) Sicherheitsvorfälle SOLLTEN standardisiert nachbereitet werden. Dabei SOLLTE untersucht werden, wie schnell die Sicherheitsvorfälle erkannt und behoben wurden. Weiterhin SOLLTE untersucht werden, ob die Meldewege funktionierten, ausreichend Informationen für die Bewertung verfügbar und ob die Detektions- maßnahmen wirksam waren. Ebenso SOLLTE geprüft werden, ob die ergriffenen Maßnahmen und Aktivi- täten wirksam und effizient waren.

Die Erfahrungen aus vergangenen Sicherheitsvorfällen SOLLTEN genutzt werden, um daraus Handlungs- anweisungen für vergleichbare Sicherheitsvorfälle zu erstellen. Diese Handlungsanweisungen SOLLTEN den relevanten Personengruppen bekanntgegeben und auf Basis neuer Erkenntnisse regelmäßig aktualisiert werden.

Bundesamt für Sicherheit in der Informationstechnik 34

Anforderungskatalog zur Konkretisierung der Kriterien des § 8a Absatz 1 und Absatz 1a BSIG

Die Institutionsleitung SOLLTE jährlich über die Sicherheitsvorfälle unterrichtet werden. Besteht sofortiger Handlungsbedarf, MUSS die Institutionsleitung umgehend informiert werden.

134. Weiterentwicklung der Prozesse durch Erkenntnisse aus Sicherheitsvorfällen und Branchenentwicklungen [Fachverantwortliche] (BSI OH SzA, DER.2.1.A18) Nachdem ein Sicherheitsvorfall analysiert wurde, SOLLTE untersucht werden, ob die Prozesse und Abläufe im Rahmen der Behandlung von Sicherheitsvorfällen geändertoder weiterentwickelt werden müssen. Da- bei SOLLTEN alle Personen, die an dem Vorfall beteiligt waren, über ihre jeweiligen Erfahrungen berichten.

Es SOLLTE geprüft werden, ob es neue Entwicklungen im Bereich Incident Management und in der Foren- sik gibt und ob diese in die jeweiligen Dokumente und Abläufe eingebracht werden können.

Werden Hilfsmittel und Checklisten eingesetzt, z. B. für Service-Desk-Mitarbeitende, SOLLTE geprüft wer- den, ob diese um relevante Fragen und Informationen zu erweitern sind.

135. Automatische Reaktion auf sicherheitsrelevante Ereignisse (BSI OH SzA) Bei einem sicherheitsrelevanten Ereignis MÜSSEN die eingesetzten Detektionssysteme das Ereignis auto- matisch melden und in Netzen, wo durch die automatische Reaktion die kritische Dienstleistung nicht ge- fährdet wird, mit geeigneten Schutzmaßnahmen reagieren. In Netzen, wo die kritische Dienstleistung durch die Umsetzung nicht gefährdet wird, MUSS es möglich sein, automatisch in den Datenstrom einzugreifen, um einen möglichen Sicherheitsvorfall zu unterbinden. Sollte eine automatische Reaktion nicht möglich sein, MUSS über manuelle Prozesse sichergestellt werden, dass der mögliche Sicherheitsvorfall unterbunden wird.

Der Ausschluss von Netzen oder Netzsegmenten von einer automatischen Reaktion, bzw. dem Eingriff in den Datenstrom MUSS schlüssig begründet sein.

Festgestellte Sicherheitsvorfälle im vermeintlichen Zusammenhang mit Angriffen MÜSSEN behandelt werden.

Bei Störungen und Sicherheitsvorfällen insbesondere im vermeintlichen Zusammenhang mit Angriffen MUSS überprüft werden, ob diese den Kriterien der Meldepflicht nach §8b Absatz3 BSIG bzw. §11 Ab- satz1c EnWG entsprechen und eine Meldung an das BSI notwendig ist.

Die zur Angriffserkennung eingesetzten Systeme SOLLTEN automatisiert Maßnahmen zur Vermeidung und Beseitigung von angriffsbedingten Störungen ergreifen können, sofern das zu Grunde liegende SRE eindeutig qualifizierbar ist. Dabei MUSS gewährleistet sein, dass ausschließlich automatisiert ergriffene Maßnahmen nicht zu einer relevanten Beeinträchtigung der kritischen Dienstleistung des Betreibers führen können.

Die eingesetzten SzA SOLLTEN auch eine nicht-automatisierte Qualifizierung und Behandlung von Ereig- nissen unterstützen.

Bundesamt für Sicherheit in der Informationstechnik 35

Glossar

3 Glossar

Bundesamt für Sicherheit in der Informationstechnik 36

Glossar

Bundesamt für Sicherheit in der Informationstechnik 37