Security im Rahmen der Störfallverordnung

Drei Crashkurse und ein Wegweiser: Security Engineering, KAS-51, LANUV-Orientierungspapier

Nur ein kleiner Teil in der Störfallbetrachtung einer Anlage, aber trotzdem “prüfungsrelevant”: Security. Photo by Robin Sommer

Security ist nur eine kleine Teilmenge in den aufwendigen Analysen, zu denen Anlagenbetreiber verpflichtet sind, wenn sie unter die Störfallverordnung fallen. Verständlich also, dass die Security nicht als Erstes auf der Agenda von Störfallbeauftragten steht. Aber sie gehört dazu, und mit dem KAS-Leitfaden 51 und dem Orientierungspapier des LANUV (Landesumweltamt NRW) zur Darstellung der IT-Sicherheit im Sicherheitsbericht wird konkreter, worauf Aufsichtsbehörden hinsichtlich Security achten.

Dieser Text bahnt einen Weg durch den Security-Dschungel, aufgeteilt in drei Crashkurse zu Security Engineering, KAS-51, LANUV-Orientierungspapier und zum Schluss einen kleinen Wegweiser, der Ihnen hoffentlich ein paar unnötige Schleifen durch das sperrige Security-Thema erspart.

Was hat die Störfallverordnung mit Security zu tun?

Die Antwort auf diese Frage steht im Leitfaden KAS-51. Das ist ein 2019 veröffentlichtes Papier der Kommission für Anlagensicherheit (KAS) des Bundesministeriums für Umwelt, Naturschutz und nukleare Sicherheit. Er richtet sich an Betriebe, die unter die Störfallverordnung fallen und macht Vorschläge, wie solche Betriebe sich um ihre Security kümmern sollen, um Störfällen vorzubeugen.

Der letzte Halbsatz “um Störfällen vorzubeugen” ist dabei wichtig. Denn aus Sicht der Störfallverordnung ist Security nur ein ganz kleines Scheibchen der großen Torte. Das Scheibchen ist eine Teilmenge einer Teilmenge, wie in der untenstehenden Grafik von links nach rechts zu sehen ist:

Schutz vor schädlichen Umwelteinwirkungen:

Das Bundesimmissionsschutzgesetz (BImschG) regelt, wie der Schutz vor schädlichen Umwelteinwirkungen zu vermeiden ist.

Teilmenge — schädliche Umwelteinwirkungen durch Störfälle:

Die Störfallverordnung, die mit vollem Namen 12. BundesImmissionsschutzverordnung (12. BImschV) heißt, regelt die Teilmenge der schädlichen Umwelteinwirkungen, die durch Störfälle verursacht wird.
Betroffene Betriebe müssen ein Sicherheitskonzept entwickeln und einen Sicherheitsbericht verfassen, der die Ergebnisse des Sicherheitskonzepts und eine Analyse der individuellen Bedrohungslage enthält.

Teilmenge der Teilmenge — schädliche Umwelteinwirkungen durch Störfälle durch Eindringen Unbefugter

Der KAS-Leitfaden 51 behandelt wiederum eine Teilmenge dieser Teilmenge, nämlich nur Störfälle, die durch Eingriffe Unbefugter hervorgerufen werden. Und darunter fallen eben unter anderem auch “cyberphysische Angriffe” — das Betrachtungsfeld der (OT-)Security.

Crashkurs: Security Engineering & KAS-Leitfaden 51

Den KAS-Leitfaden kann man grob in vier Teile gliedern. Für Lesefaule steht unter jeder Teilüberschrift ein “tl;dr” (too long, did not read) mit der Quintessenz des Abschnitts. Und nebenbei lernen Sie, wie eigentlich Security Engineering geht.

Teil 1: Basismaßnahmen und besondere Gefährdung (Kap. 4–5)

tl;dr: Hier gibt es nicht viel zu sehen.
Die Basismaßnahmen kommen später ohnehin noch einmal vor und dass eine “besondere Gefährdung”, dürfen Sie ohne viel Federlesen annehmen.

Der erste Teil ist der Einstieg und das “Muss”, das jeder Betrieb, der unter die Störfallverordnung fällt, erfüllen muss. Es gibt eine Reihe von zu erfüllenden Basismaßnahmen und es muss betrachtet werden, ob eine “besondere Gefährdung” vorliegt.

Die Basismaßnahmen sind ein kleines Security-Einmaleins: Sie umfassen Verantwortlichkeiten, Steuerung von Zutritt (zu Gebäuden und Schränken), Zugang (zu IT-Systemen) und Zugriff (auf bestimmte Systemfunktionalitäten), Manipulationsschutz, Dienstleisterregelungen und Sensibilisierungsschulungen.

Wenn keine besondere Gefährdung vorläge, wären Sie hier fertig. Im anderen Fall müssen Sie eine “Sicherungsanalyse” durchführen und weitere Maßnahmen festlegen — die all diese Basismaßnahmen noch einmal umfassen. Und dass Sie bei der Sicherungsanalyse und damit den weiterführenden Maßnahmen landen, können Sie annehmen.

Warum?

Weil die Frage nach dem “Vorliegen einer besonderen Gefährdung” überholt ist.

Aber eins nach dem anderen: Eine “besondere Gefährdung” liegt kurz gesagt dann vor, wenn Störfälle durch Security-Gefährdungen, also durch böswillige Manipulationen von IT-Systemen, hervorgerufen werden können.
Ursprünglich sollte dies für die Anlagen der Betriebsbereiche oberer Klasse gemäß Störfallverordnung gelten und für die unteren Betriebsbereiche nur in Ausnahmefällen — aber mittlerweile hat sich der Stand der Technik dazu geändert. Kurz gesagt: Sparen Sie sich die Haarspaltereien (und das Nachdenken über Basismaßnahmen) und machen Sie einfach die Sicherungsanalyse.

Das ist sinnvoll aus zwei Gründen.

1. Zum Einen haben die Kriterien für die oberen und unteren Betriebsbereiche wenig mit der Wahrscheinlichkeit für Security-Gefährdungen zu tun — die Manipulation eines IT-Systems wird nicht weniger wahrscheinlich, weil die Stoffe, mit denen hantiert wird, in kleineren Mengen vorhanden sind.
2. Zum Anderen ist es aufwendig bis unmöglich, die Möglichkeit von Security-Gefährdungen auszuschließen. Selbst, wenn Sie es versuchen: Die Überlegungen, die Sie dabei anstellen müssten (was wären mögliche Einfallstore für Security-Gefährdungen? Was könnte ein Security-Vorfall anrichten? Was tun Sie bereits, um Security-Gefährdungen zu vermeiden?) sind so ähnlich zu denen in einer Security-Risikoanalyse, dass Sie mit vergleichbarem Aufwand auch direkt die Security-Risikoanalyse machen können.

Ein großer Treiber für dieses Umdenken ist die überarbeitete VDI/VDE 2180, die den analogen Weg geht.

Struktur des KAS-Leitfaden 51 (Quelle: Kommission für Anlagensicherheit). Verweilen Sie nicht zu lang bei Kapitel 4 und 5, Sie müssen ohnehin weiter zu Kapitel 6–8 inkl. Anhängen.

Teil 2: Sicherungsanalyse (Kap. 6)

tl;dr: Die Begrifflichkeiten mögen ein wenig ungewohnt sein, aber im Prinzip können Sie hier jede Security-Risikoanalysemethodik (nicht die für die funktionale Sicherheit!) verwenden. Sie müssen dabei allerdings nur solche Gefährdungen betrachten, die Störfälle hervorrufen können.

Wenn Sie nun Teil 1 erfolgreich beiseite gelegt haben, kann es mit dem wichtigsten Werkzeug der Security weitergehen: Der Risikoanalyse.
Sie können für die Erfüllung des KAS-Leitfadens jede Risikoanalysemethodik verwenden, die in der Security üblich ist.

Wenn Sie versuchen, eine beliebige Security-Risikoanalyse mit der im KAS-Leitfaden 51 beschriebenen Vorgehensweise übereinander zu bekommen, könnte Ihnen ein wenig der Kopf rauchen — teilweise sind die KAS-51-Begrifflichkeiten etwas unüblich, aber der dahinterstehende Risikoanalyseprozess ist es nicht.

Versuchen wir also eine Übersetzungshilfe. Die folgende Grafik zeigt ein generisches Security-Engineering-Prozessmodell und als Teil davon übliche Teilschritte einer Security-Risikoanalyse, wie sie sich beispielsweise in den Standards VDI/VDE 2182, VDI/VDE 2180, ISO/IEC 27005, ISO 31000 oder IEC 62443–3–2 finden. Wenn Sie diese Teilschritte verinnerlicht haben, finden Sie sich in all diesen Standards zurecht; denn sie unterscheiden sich nur im Detail.

Übersetzungshilfe für den KAS-Leitfaden 51: Zuordnung der Begriffe aus der KAS-51 zu geläufigeren Teilschritten einer Security-Risikoanalyse

Geltungsbereich und Schutzbedarfseinschätzung (1.-2.)
Üblicherweise beginnt die Risikoanalyse nach der Definition des Geltungsbereichs mit einer Festlegung des Schutzbedarfs (manchmal auch: “Kritikalität”) einzelner Teilbereiche. Dies wird in der KAS-51 etwas irreführend “Gefahrenanalyse” genannt — deren Kern ist aber genau diese Identifikation der “sicherungsrelevanten” Teile der Anlage beziehungsweise des Betriebsbereichs.

Gefährdungsidentifikation (3.)
Der nächste Schritt einer Risikoanalyse ist die Gefährdungsidentifikation, während der für den Geltungsbereich — bevorzugt für seine schutzbedürftigsten Teile — mögliche Security-Gefährdungen identifiziert werden. Gefährdungen sind eine Kombination von Bedrohungen und Schwachstellen.
Diese beiden Elemente sind in der KAS-51 zweigeteilt: Die “Bedrohungsanalyse” ist ein eigener Teilschritt, während die Analyse der Schwachstellen und die Zusammenfassung zu “IT-Gefährdungen” in der “IT-Risikobeurteilung” aufgeht.

Risikobewertung (4.)
Im folgenden Schritt müssen die Risiken der identifizierten Gefährdungen bewertet werden, indem ihre Eintrittswahrscheinlichkeit und Auswirkung abgeschätzt werden. Diese Risikobewertung ist ebenfalls Teil der “IT-Risikobeurteilung” der KAS-51.

Eine Warnung zum Schluss:
Versuchen Sie nicht, die Security-Aspekte in Ihre Risikoanalyse für die funktionale Sicherheit (Safety) hineinzuweben. Beide Analysen haben verschiedene Betrachtungsbereiche sowohl hinsichtlich schützenswerten Systemen als auch relevanten Gefährdungen, verschiedene Detaillevel, eine ganz unterschiedliche Datenbasis und daher notwendigerweise komplett verschiedene Methoden.

Teil 3: Maßnahmenchecklisten (Kapitel 4, Kapitel 7 und Anhänge)

tl;dr: Bei den Maßnahmenvorschlägen erfindet der KAS-Leitfaden 51 dankenswerterweise das Rad nicht neu. Die Maßnahmen sind eine “Light-Version” üblicher IT-Security-Anforderungen — inklusive der Anforderung an ein Managementsystem, wie in der populären ISO/IEC 27001 beschrieben.

Nachdem Risiken identifiziert und bewertet wurden, folgt üblicherweise — und auch in der KAS-51 — die Behandlung der Risiken. Der KAS-Leitfaden schlägt dazu einen Katalog von Anforderungen vor, bestehend aus den Basismaßnahmen und weitergehenden Schutzmaßnahmen.

Die Basismaßnahmen entstammen Kapitel 4. Wir haben sie weiter oben bereits betrachtet; wie versprochen begegnen sie uns hier nun erneut.

Die weitergehenden Schutzmaßnahmen setzen eigene Schwerpunkte und sind in den Anhängen des KAS-Leitfadens beschrieben:

• Anforderungen zur Erweiterung des Sicherungsmanagements um Security stehen in Anhang 1.
  Ein üblicher Weg dahin die Einführung eines Informationssicherheits-Managementsystems (ISMS) gemäß ISO/IEC 27001.
• Anforderungen gegen cyberphysische Angriffe stehen in Anhang 2.
  Diese Anforderungen ergänzen die Basismaßnahmen aus Kapitel 4 und es ist sinnvoll, das Paket als Ganzes zu betrachten. Sie enthalten übliche Security-Anforderungen und keine darüber hinausgehenden Überraschungen.
  Der Anhang entspricht dem obsoleten KAS-Leitfaden KAS-44.
• Anforderungen gegen Drohnenangriffe stehen in Anhang 3.
  Die Wichtigkeit, die Drohnenangriffen eingeräumt wird, ist die einzige “Schrulle” der KAS-51 gegenüber gängigen IT-Security-Standards.
  Die prominente Positionierung des Themas im Leitfaden ist wohl historisch gewachsen und dem Umstand geschuldet, dass es einst einen eigenen KAS-Leitfaden zu Drohnenangriffen gab (KAS-45), der nun im KAS-Leitfaden 51 aufgegangen ist.
  Zumindest der passive Teil der empfohlenen Maßnahmen ist aber bekannt und üblich aus der physischen Sicherheit: Einhausung, Sichtschutz, Schutz von Öffnungen.

Teil 4: Sicherheitsbericht (Kap. 8)

tl;dr: Im Sicherheitsbericht erfolgt die Zusammenfassung der IT-Risikoanalyse und der IT-Security-Maßnahmen für die Aufsichtsbehörden. Er kann einen nichtöffentlichen Teil enthalten — darüber hinaus enthält die KAS-51 keine Hinweise darauf, was im Security-Teil des Sicherheitsberichts stehen soll. Diese Lücke füllt das LANUV-Orientierungspapier, das wir im folgenden Abschnitt behandeln.

Die gesammelten Erkenntnisse aus der IT-Risikoanalyse und der Umsetzung der Maßnahmen müssen im Sicherheitsbericht dokumentiert werden. Dies ist zwar nur eine Formalie, aber gleichzeitig die rechtlich erforderliche Unterlage für die Behörden, die die Umsetzung der Störfallverordnung beaufsichtigen (in der Regel Bezirksregierungen).

In der Praxis sieht das so aus, dass der existierende Sicherheitsbericht um IT-Security-Aspekte ergänzt wird (wir erinnern uns: Security ist nur eine Teilmenge einer Teilmenge für die Störfallverordnung). Weil Sicherheitsberichte veröffentlicht werden, kann es ratsam sein, sensible Informationen in einen nicht-öffentlichen Teil auszugliedern. Der KAS-Leitfaden 51 ermutigt explizit dazu. Sensible Informationen können solche sein, die einem Security-Angreifer die Arbeit erleichtern würden —etwa Informationen über die Netzwerkarchitektur, mögliche Angriffsszenarien und existierende Schwachstellen.

Darüber hinaus enthält der KAS-Leitfaden 51 keine Informationen dazu, wie die Dokumentation im Sicherheitsbericht aussehen soll — und das bringt uns zur LANUV-Orientierungspapier, das genau diese Lücke füllt.

Crashkurs LANUV-Orientierungspapier

Das Landesamt für Natur- und Umweltschutz in NRW (LANUV) hat im April 2021 ein “Orientierungpapier zur Darstellung der IT-Sicherheit im Sicherheitsbericht und in den Genehmigungsunterlagen zur Anlagensicherheit” herausgebracht.

Nun, da wir uns im KAS-Leitfaden 51 auskennen, können wir auch dieses Orientierungspapier besser einordnen: Es ergänzt die Informationen des KAS-Leitfadens 51 um konkrete Hinweise darauf, welche Informationen in welcher Form im Security-Teil des Sicherheitsbericht erwartet werden.

Das LANUV-Papier stellt selbst keine neuen Anforderungen. Alles, was Sie dort finden, steht als Anforderungen bereits im KAS-Leitfaden 51; lediglich die erforderliche Dokumentation im Sicherheitsbericht wird konkretisiert.

Betrachten Sie das Papier also als Spickzettel für die Prüfung.
Es ist, als würde Ihnen Ihr Mathelehrer zur Klassenarbeit ein Kochrezept danebenlegen, in dem er Ihnen die Lösungswege beschreibt und aufschlüsselt, wofür es die meisten Punkte gibt. Der einzige Abstrich gegenüber einer vollständigen Musterlösung der Klassenarbeit, die sie direkt abgeben könnten: Rechnen müssen Sie noch selbst.

Schauen wir uns die Ergänzungen des LANUV-Papiers im Detail an. Zusammengefasst sind sie in der untenstehenden Grafik, deren Aufbau Ihnen nun bereits vertraut sein dürfte — es gibt nur eine neue Spalte für das LANUV-Orientierungspapier zur Darstellung der IT-Sicherheit im Sicherheitsbericht:

Einordnung der Forderungen des KAS-Leitfadens 51 und der Hilfestellungen des LANUV-Orientierungspapiers in einen generische Security-Risikoaanlyseprozess

Wie Sie sehen, enthält das LANUV-Orientierungspapier Definitionshilfen, Beispiele und weiterführende Informationen zum Geltungsbereich und der Risikoanalyse. Werfen wir einen Blick auf ein paar nennenswerte Details.

Mindestinhalte des Security-Teils im Sicherheitsbericht

Sehr explizit wird definiert, was mindestens im Sicherheitsbericht dargestellt werden sollte:

• Geltungsbereich: Netzwerkarchitektur, Assetlisten
• IT-Risikobeurteilung: Methoden, Ergebnisse, resultierende Maßnahmen

IT-Risikobeurteilung ist Pflicht — aber nicht die Betrachtung der Vertraulichkeit

Unmissverständlich stellt das LANUV klar, welche Option Ihnen nicht bleibt: Die IT-Risikobeurteilung wegzulassen. Dies entspricht der bereits weiter oben im KAS-51-Crashkurs gemachten Beobachtung.

Zitat aus dem LANUV-Papier:

Eine systematische Gefahrenabschätzung für IT / OT ist ohne IT-Risikobeurteilung nur schwerlich realisierbar, daher ist in Analogie zur klassischen Gefahrenanalyse eine IT-Risikobeurteilung durchzuführen und zumindest deren zugrunde gelegte Methode und die Ergebnisse, einschließlich der daraus resultierenden Maßnahmen, im Sicherheitsbericht darzulegen.

Im LANUV-Papier versteckt ist allerdings auch noch eine kleines “Geschenk”: Sie dürfen in der Security-Risikoanalyse Auswirkungen auf die Vertraulichkeit außen vor lassen:

Die IT-Risikobeurteilung […] identifiziert die möglichen Auswirkungen der IT-Gefährdungen auf die Integrität und Verfügbarkeit der sicherheitstechnischen Funktionen (nach DIN EN 61511) (Auswirkungsanalyse)

Security-Risikoanalysemethodik: Getrennt von der funktionalen Sicherheit (Safety)

Ebenso deutlich ist die Forderung nach einer separaten Risikoanalyse für die Security (versus einer “Mitbetrachtung” in der Safety-Risikoanalyse). Auch dies entspricht dem Stand der Technik, wie bereits oben beschrieben.

Da die bisherigen Ansätze der klassischen Gefahrenanalyse für einen Einbezug der IT / OT Thematik oftmals nur bedingt geeignet sind, ist es ratsam, diese separat in einer IT-Risikobeurteilung durchzuführen.
Ein Hintergrund für diese Trennung ist insbesondere die unterschiedliche Betrachtungsweise der klassischen Gefahrenanalyse und der IT-Risikobeurteilung.

Eine separate Security-Risikoanalyse, auch wenn das vorerst nach Mehrarbeit klingen mag, ist nicht nur methodisch sinnvoll, sondern auch, weil es Abhängigkeiten verringert.
Security-Risikoanalysen haben nämlich viel kürzere Lebenszyklen als solche für Safety, weil die Bedrohungslage sich im schlimmsten Fall täglich ändert— und Sie wollen ja nicht bei jeder neuen Iteration der Security-Risikoanalyse Ihre Safety-Risikoanalyse wieder aufschnüren.

Stattdessen dürfen Sie, solang Sie eine separate Security-Risikoanlayse durchführen, in der Safety-Risikoanalyse Security-Gefährdungen außen vor lassen. Das LANUV formuliert das so:

Resultierend aus den IT-Gefährdungen der IT-Risikobeurteilung müssen Maßnahmen abgeleitet und umgesetzt werden, die eine ausreichende Sicherheit im Rahmen der praktischen Vernunft im Sinne der Störfall-Verordnung darstellen. Diese Gestattung der fachlichen Schnittstelle zwischen OT und IT ermöglicht es, im Rahmen der klassischen Gefahrenanalyse weiterhin nur einen Fehler zu unterstellen.

Dieser Gedanke ist internationaler Konsens und in der IEC TR 63069 als “Security Environment” definiert — eine “sichere Umgebung”, die Sie für Ihre Safety-Risikoanalyse annehmen dürfen.

Security Environment (Quelle: IEC TR 63069)

Als Risikoanalysemethode für die Security dürfen Sie, das sagt auch das LANUV-Papier, alles Übliche verwenden: Explizit genannt sind Ansätze aus den Standardreihen ISA/IEC 62443, ISO/IEC 2700x, VDI/VDE 2180 und VDI/VDE 2182 (und NAMUR NA 163 mit Einschränkungen).

Alle diese Varianten passen in die Teilschritte des Security-Risikoanalyseprozesses, den Sie bereits kennen gelernt haben.

Geltungsbereich: sicherheitsrelevante Anlagenteile (srA) und alles, was deren Integrität und Verfügbarkeit beeinträchtigen kann

Den Details zu Netzwerkarchitektur und Assetlisten widmen wir uns noch, aber zuerst möchte ich Ihr Augenmerk auf die Definition des Geltungsbereichs lenken. Auch dazu gibt es konkrete Aussagen im LANUV-Papier.

Das primäre Ziel im Sinne der Störfall-Verordnung ist der Schutz der sicherheitsrelevanten Anlageteile (nachfolgend srA genannt) und der damit in Verbindung stehenden Subsysteme […].
Die IT-Sicherheit wird unter diesem Kontext betrachtet, das heißt vorrangig alle IT-Elemente, die die Integrität und Verfügbarkeit von srA beeinflussen können.

Die Definition ist zwar klar, wirft aber zwei Folgefragen auf.

Frage 1: Was zählt zu den sicherheitsrelevanten Anlagenteilen (srA)?
Hier bewegt sich das LANUV, wie auch schon bei der generischen Forderung der IT-Security-Risikoanalyse, eng am in der VDI/VDE 2180 beschriebenen Standpunkt.
Zu den srA gehören demnach alle Sensoren, Aktoren und Logiksysteme, die Sicherheitsfunktionen ausführen — egal, ob es “reine” Safety-Systeme sind (VDI 2180: PLT-Sicherheitseinrichtungen, kurz: PLT-S), Hybridsysteme, die sowohl Safety- als auch normale Betriebsfunktionen ausführen (VDI 2180: PLT-Betriebseinrichtungen mit Sicherheitsfunktion, kurz PLT-BS).

Zitat aus dem LANUV-Papier:

Darstellung und Bezeichnung der sicherheitstechnisch relevanten Sensoren
(inklusive PLT-BS), Aktoren und Logiksysteme. Dies schließt hybride Bauteile
und vollintegrierte Systeme mit ein.

Frage 2: Wie bestimme ich, welche anderen IT-Elemente Vertraulichkeit und Verfügbarkeit von srA beeinflussen können?
Auch dazu gibt es eine konkrete Handreichung vom LANUV. Ausgehend von der obenstehenden Definition der srA sind danach mindestens die folgenden weiteren Elemente zu betrachten:

• “Beteiligte Bauteile”: etwa Router, Switche, DMZ-Systeme, Firewalls
• Übertragungsstrukturen: etwa Busse, Funknetze
• Schnittstellen der srA zu anderen Komponenten
• Zugangswege zu den srA
• Situative und temporäre Komponente “mit Bezug zur Anlagensicherheit”

…ist der Geltungsbereich nun “zu groß” oder “zu klein”?
Eine abschließende Bemerkung zum Geltungsbereich:
Auch wenn sicherheitsrelevante Anlagenteile gemäß LANUV-Orientierungspapier nach Ihrem Geschmack vielleicht zu breit definiert werden, ist der Geltungsbereich aus Security-Sicht damit immer noch vergleichsweise klein.

Ob die Einschränkung der Security-Risikoanalyse — selbst mit “Störfall-Scheuklappen” betrachtet — auf sicherheitsrelevante Anlagenteile überhaupt sinnvoll ist, ist ein durchaus streitbarer und in der Realität umstrittener Punkt.

Denn die Eingrenzung auf sicherheitsrelevante Anlagenteile verlässt sich auf die Annahme, dass ausschließlich durch Security-Angriffe auf diese Anlagenteile Störfälle hervorgerufen werden können. Diese Voraussetzung ist nicht zwingend realistisch, denn die Folgen eines Security-Angriffs sind schwierig anhand der beteiligten Komponenten vorhersagbar, sondern nur bei Betrachtung konkreter Security-Angriffsvektoren — und die unterscheiden sich von Safety-Angriffsvektoren.

In der Safety-Analyse, im Zuge derer die safety-relevanten Komponenten ausgelegt wurden, werden nämlich vernünftigerweise vorhersehbare Fehlanwendungen betrachtet, nicht aber die in der Security üblichen kreativen und böswilligen Manipulationen. Es ist also gut möglich, dass in dieser Analyse Szenarien durchgegangen sind, die von keiner “srA” abgefangen wurden.

Beispiel gefällig? Durch die kreative Manipulation von Stromversorgung oder Notrufsystemen ist die Verursachung oder zumindest die fehlende Reaktion auf Störfälle durchaus denkbar. Es gibt also Komponenten mit “indirekter Safety-Relevanz” — und diese sind im vom LANUV geforderten Geltungsbereich nicht explizit inbegriffen durchaus aber im Graubereich (“Systeme, die einen direkten Einfluss/Zugriff auf oben genannten Bauteilen haben oder sonst von Relevanz für die Sicherheit sind bzw. sein können”).

Direkte Safety-Relevanz vs. indirekte Safety-Relevanz (Quelle: Holger Laible)

Dokumentationshilfen für Netzwerk und Assetliste

Dieser Punkt ist weniger kritisch, aber ein guter Service des LANUV-Orientierungspapiers. In der wenig standardisierten Welt der IT-Netzwerkdokumentation und IT-Assetlisten gibt das Papier Leitplanken vor, was mindestens in diesen Dokumenten enthalten sein sollte, und macht sogar Beispiele, an denen Sie sich orientieren können.

Dokumentationen wollen nicht nur erstellt, sondern auch gepflegt werden, man kann sich in Details schnell verzetteln und die IT-Security kommt aus Sicht von Ingenieuren oft mit irritierend wenig Details aus (das liegt daran, dass sie auf Basis ihrer Dokumentation ja nichts selbst bauen und warten können muss…).
Daher: Nutzen Sie die definierten Minimalanforderungen des LANUV-Papiers. Sie sind wirklich das, was drauf steht: Eine echte Orientierungshilfe.
Oft lohnt es sich, zwischen den Zeilen zu lesen, was alles nicht in den Dokumentationen vorkommen muss. Zwei Beispiele:

Beispiel 1: Umfang der Netzwerkdiagramme

Der Schwerpunkt der Netzwerkarchitektur ist auf die Darstellung
- der Kommunikationsverbindungen innerhalb der OT Ebene (Level 0–3) und
- deren Anbindung (Schnittstellen) an andere Ebenen der IT / Netzwerke / Zugänge sowohl innerhalb wie außerhalb der Verantwortung der Betreiberin
(Übergange von Level 0–3 zu Level 4 & 5)

→ Was nicht dokumentiert werden muss: Das ganze Office-Netz — es reichen die Verbindungen dorthin.

Beispiel 2: Informationsgehalt der Assetlisten

Beispiel für einen abstrahierten Auszug einer Assetliste (Quelle: LANUV-Orientierungspapier)

→ Was nicht dokumentiert werden muss: Alle administrativen Details (Firmwareversionen, Softwarestand, Netzwerkmasken…), die Sie in üblichen Vorlagen für Assetlisten aus der IT-Administration finden.

Wegweiser

Wenn Sie die Informationen aus diesem Dreifach-Crashkurs in Security-Engineering, KAS-51 und LANUV-Orientierungspapier sacken gelassen haben, haben Sie das Rüstzeug, um Security im Rahmen der Störfallverordnung anzugehen.

Zum Abschluss noch ein kleiner Wegweiser zum Einstieg in die Umsetzung, die Ihnen viel Arbeit und Frust ersparen können:

Am Anfang war die Risikoanalyse

Beginnen Sie mit der Risikoanalyse, und lernen Sie sie lieben. Sie ist das wichtigste Werkzeug, das Sie brauchen, um Security-Entscheidungen zu treffen — egal ob für die Störfallverordnung oder unabhängig davon.
Wählen Sie eine der vorgeschlagenen Methoden aus oder orientieren Sie sich einfach am generischen Prozessmodell aus dem Leuchtturm — und legen Sie los.

Der Geltungsbereich: Manchmal ist mehr mehr

Stecken Sie nicht zu viel Energie in eine möglichst enge Definition des Geltungsbereichs. Wenn Sie merken, dass Sie mehr Zeit investieren, um Elemente aus dem Geltungsbereich “herauszudiskutieren” als die Risikoanalyse dieser Elemente kosten würde, nehmen Sie sie mit.

Ich weiß, es ist kontraintuitiv: Aber beim Geltungsbereich gilt nicht immer “weniger ist mehr”. Manchmal kann auch “mehr ist mehr”, oder präzise: “mehr ist weniger (Aufwand)” gelten. Ein einfacher Geltungsbereich kann nämlich auch einer sein, der nicht voll von komplizierten Schnittstellen und Annahmen ist.

In Funktionen denken

Wenn Sie dennoch ein Fan von “weniger ist mehr” sind, toben Sie sich lieber auf einem anderen Gebiet aus: Der Detailtiefe.

Das heißt nicht, dass Sie relevant Informationen weglassen sollen — aber schneiden Sie ihre “kleinsten Betrachtungseinheit” klug zu. Nehmen Sie nicht einfach ihre telefonbuchlange Assetliste und x-en in schicksalsergebener Fleißarbeit die Risikoanalyse Ihrer Wahl durch, sondern fragen Sie sich zuerst für jedes Asset, mit wem es interagiert und wozu sie es brauchen. So bündeln Sie ihren unüberschaubaren “Haufen Blech” in eine überschaubare Liste wichtiger Funktionen.

Beispiel:

In der Security-Risikoanalyse zahlt sich die Funktionsdenke aus.
Erstens rein zahlenmäßig, denn Risiken multiplizieren sich unangenehm auf:

• Für 100 Assets und zwei relevante Auswirkungsdimensionen (Integrität und Verfügbarkeit) landen Sie bei zwei Gefährdungsszenarien je Auswirkungsdimension (und das ist nicht viel!) bei 400 Risiken.
• Wenn Sie stattdessen 20 Funktionen betrachten, hat Ihre Risikoliste dagegen nur 80 Einträge. Gleich viel angenehmer, oder?

Zweitens wird Ihnen die Risikoanalyse leichter fallen. Sie werden nämlich feststellen, dass Sie sich die Fragen, die Sie sich beim Zuschnitt und der Definition der Funktionen gestellt haben, spätestens bei der Risikobewertung ohnehin stellen müssen. Oder wie bewerten Sie, wie schlimm es ist, wenn Router X ausfällt, ohne zu wissen, wofür Sie Router X benutzen?

Eben.

Mehr Details zur Funktionsdenkweise finden Sie hier und hier.

Die Compliance-Brille absetzen

Zu guter Letzt sind wir wieder bei “manchmal ist mehr mehr”. Natürlich — Sie können die Security-Anforderungen der Störfallverordnung mit Minimalaufwand umsetzen, aus reiner “Compliance-Sicht”: Alles, was nicht prüfungsrelevant ist, lassen Sie weg.

Ich prophezeie Ihnen: Sobald Sie die Compliance-Brille aufhaben, wird sich der ganze Security-Kram auch anfühlen wie Compliance: Trocken, sinnbefreit, rundum ärgerlich.

Es geht aber auch anders. Versuchen Sie mal, das notwendige Übel Security durch die Betriebsbrille zu sehen.
Bauen Sie nicht die tausendundeinste Dokumentation, sondern eine, die Ihnen hilft (aus Security-Sicht passen Ihre Systeme übrigens auf ein Blatt).
Wählen Sie eine Risikomethodik, die Ihnen bei zukünftigen Problemen hilft (was machen Sie eigentlich, wenn mal wieder eine Schwachstellenmeldung kommt? Wie validieren oder entkräften Sie ihr diffuses Bauchgefühl, das die geplante Anschaffung der neuen hybriden Safety-Systeme bei Ihnen hinterlässt?).
Security kann man übrigens auch als Sündenbock verwenden, um ungeliebte, unzuverlässige, fehleranfällige oder veraltete Systeme loszuwerden.

Es stimmt —wenn Sie unter die Störfallverordnung fallen, kommen Sie um Security nun nicht mehr drumherum. Aber Sie können selbst entscheiden, wie viel Ihnen das neue notwendige Übel für den Betrieb bringt.