Nachdem Sie letzte Woche schon ein kurzes "Pre-Briefing" bekommen haben zu einem meiner Herzensprojekte "Security unter Kontrolle", geht es diese Woche wieder wie gewohnt mit einem breiteren Themenspektrum weiter.

Wo wir gerade bei Herzensprojekten sind: Es gibt Neuigkeiten zum zweiten Herzensprojekt, unserem Forschungsprojekt IDEAS. Und falls Ihr - vielleicht nicht ganz freiwilliges - Herzensprojekt momentan die Umsetzung der Security im Rahmen der Störfallverordnung / KAS-51 ist, werden Sie auch fündig.
Auch wenn Cybersecurity-Angriffe bislang eher eine Randnotiz im beklemmenden Russland-Ukraine-Krieg sind - komplett daran vorbeischauen können wir nicht. Legen wir los:

In dieser E-Mail gibt es Neuigkeiten und Lesestoff zu folgenden Themen:

1. OT-Security-Vorfall beim deutschen Tankstellenzulieferer Oiltanking
2. Die Rolle von Automation Security im Russland-Ukraine-Krieg
3. Sinn, Unsinn und Quantifizierbarkeit von Security-Risikoanalysen
4. Sind SBOMs näher, als wir denken?
5. IDEAS-Paper: Warum wir ein Security-Engineering-Informationsmodell brauchen
6. LANUV-Veranstaltung: Safety und Security in der Anlagensicherheit

1. OT-Security-Vorfall beim deutschen Tankstellenzulieferer Oiltanking

Es ist nun schon eine Weile her, aber da wir hier den Angriff auf die Colonial Pipeline in den USA so ausführlich beleuchtet haben, soll ein Vorfall in derselben Branche diesseits des großen Teichs nicht unter den Tisch fallen.

Was macht Oiltanking?
Oiltanking, eine Tochter der Hamburger Holding Marquard & Bahls, betreibt Tanklager. Kunden von Oiltanking sind Tankstellen: Kleine, unabhängige, aber auch Shell und Aral. Vom Angriff betroffen war übrigens auch der Mineralölhändler Mabanaft, ebenfalls eine Tochter von Marquard & Bahls.

Was wissen wir über die technischen Details des Vorfalls?
Zunächst zur Oiltanking-Infrastruktur: Das Betreiben von Tanklagern umfasst auch das Beladen von Tanklastern mit Kraftstoff aus den Tanklagern. Das geschieht komplett automatisiert (lies: dort ist Automatisierungstechnik / OT im Spiel).
Diese Automatisierungstechnik war durch den Vorfall lahmgelegt. Weil es keine Möglichkeit mehr gibt, den Prozess bei Ausfall der Automatisierung von Hand zu steuern, bedeutet dies, dass das Be- und Entladen der Tanklager nicht mehr möglich war.
(Wie das mit der Aussage des BSI-Präsidenten zusammenpasst, dass bei den Tankstellen teils keine Kartenzahlung oder Anpassung der Preise möglich war, bleibt zumindest mir unklar.)

Technische Details zum Angriff sind wenige bekannt.
Weil es keine weiteren Informationen von den betroffenen Firmen gab, schießen die Spekulationen ins Kraut: Es gebe unbestätigte Mutmaßungen, dass Ransomware die Ursache war, schreibt unter anderem heise. Sagen wir so: Für die Mutmaßung muss man kein Security-Experte sein. Sie ist nicht besonders exotisch und die statistische Wahrscheinlichkeit, dass sie stimmt, ist groß.
Beim Nachrichtenmagazin Techzine spekuliert ein Manager einer Security-Firma gar eine Verbindung zum Russland-Ukraine-Krieg in den Vorfall hinein.
Von Oiltanking kommt das Übliche: Man habe sich externe Hilfe geholt und arbeite an der Behebung des Vorfalls, "mit Hochdruck", versteht sich.

Die Automation-Security-Community beginnt ja an dieser Stelle gern die Haarspalterei, ob der Vorfall wirklich ein Angriff auf die OT war, oder: Sind die Automatisierungssysteme tatsächlich das Ziel des Angriffs gewesen oder ein Kollateralschaden?
Was man sicher sagen kann, ist, dass die Verfügbarkeit eines Teils der Automatisierungstechnik der Oiltanking durch den Vorfall beeinträchtigt wurde.

Was waren die Auswirkungen?
Was waren die Auswirkungen? Stories wie aus den USA im letzten Jahr, wo sich lange Schlangen vor den Tankstellen bildeten und Menschen sich genötigt sahen, Treibstoff zu hamstern, gab es hier nicht. Das liegt vor allem daran, dass Oiltanking bei Weitem nicht so ein zentrales Glied in der Tanklogistikkette ist wie die Colonial Pipeline. Während die Alternative zur Pipeline das ungleich umständlichere Befördern von Gas aus dem Süden USAs an die Ostküste per LKW war, ist der Ausfall eines Tanklagerbetreibers in Deutschland kein Beinbruch - denn es gibt noch 25 weitere, wie der Spiegel schreibt. Es seien nur 1,7 Prozent der Tankstellen betroffen, erklärte BSI-Präsident Arne Schönbohm, damit sei der Vorfall "ernst, aber nicht gravierend". Das Handelsblatt fügt jedoch hinzu, weil Oiltanking einer der größten unabhängigen Anbieter von Tankraum sei, könnten Folgen eines längeren Ausfalls bei Oiltanking trotzdem zu Engpässen führen.

Und nun kommt das "Aber": Die Auswirkungen auf die kritische Infrastruktur der Tanklogistik waren also nicht schwerwiegend; wir als Gesellschaft haben davon nicht viel gespürt. In KRITIS-Sprech: Die Erbringung der kritischen Dienstleistung war (aus Sicht des Endverbrauchers) nicht gefährdet. Anders sieht es aus, wenn man Oiltanking als Firma isoliert betrachtet.
Neben kleineren, unabhängigen Tankstellen beliefert Oiltanking Shell und Aral, die nach dem Vorfall gegenüber der Nachrichtenagentur Reuters erklärten, sie nutzten nun eben vorübergehend Tanklager anderer Firmen. Das für Tankwillige erfreuliche Statement beinhaltet damit die andererseits für Oiltanking-Verantwortliche wenig erfreuliche Information, dass die Dienstleistung von Oiltanking durch den Angriff sehr wohl komplett außer Gefecht gesetzt wurden.

2. Die Rolle von Automation Security im Russland-Ukraine-Krieg

Weil wir den aktuellen "Elefanten im Raum", der Russland-Ukraine-Krieg, ohnehin schon kurz berührt haben: Die Security-Welt beobachtet momentan angespannt und sorgenvoll, welche Rolle Security-Angriffe auf kritische Infrastrukturen im Russland-Ukraine-Konflikt spielen. Dass Russland solche Angriffe ausüben kann und es im Zweifel auch tut, haben bereits die Angriffe auf das ukrainische Stromnetz durch eine russische Hackergruppe im Jahr 2015 bewiesen (damals kam es zu Stromausfällen).

Die (berechtigterweise) nervöse Aufmerksamkeit lässt sich vielleicht damit zusammenfassen, dass die bisherigen Security-Angriffe auf Ukrainische Systeme in 2022 bereits eine Wikipedia-Seite haben (Link im Lesestoff 1). Bislang sind "nur" Regierungswebseiten und Banken betroffen, also keine OT - soweit öffentlich bekannt. Am Nachmittag vor dem russischen Einmarsch in die Ukraine ist eine neue, relativ ausgeklügelte "Wiper"-Malware zeitgleich auf mehreren ukrainischen Systemen aufgetaucht, schreibt Kim Zetter (Lesestoff 2). Wiper-Malware löscht gezielt Daten auf Systemen, um sie unbrauchbar zu machen - im Gegensatz zu Ransomware versucht man also gar nicht erst so zu tun, als könne man die Daten wiederherstellen.

Russland bekommt allerdings auch im Cyberraum einige Gegenwehr: Die Hacker-Aktivisten "Anonymous" haben kurz nach Beginn von Putins Invasion Russland "den Krieg erklärt" und greifen nun beispielsweise russische Webseiten an, leaken potenziell kriegsrelevante Informationen und stören die russischen Militär-Kommunikationskanäle - angeblich. Warum diese Erfolgsmeldungen mit Vorsicht zu genießen sind, schreibt Roman Zipp auf Twitter. Dennis Kenji-Kipker beleuchtet das Anonymous-Engagement aus rechtlicher Sicht und Manuel Atug kommentiert, wie Techies sinnvoller helfen können.

Die russische Ransomware-Hackergruppe Conti, bekannt für besonders aggressive Angriffe zum Beispiel auf Krankenhäuser, hat derweil verlautbart, bei etwaigen Cyberangriffen auf russische kritische Infrastrukturen "Vergeltungsmaßnahmen" zu ergreifen. Daraufhin leakten Unbekannte, mutmaßlich ukrainische Security-Researcher, jahrelange interne Chats der Ransomware-Gruppe. Security-Journalist Brian Krebs wertet diese in einer Serie von Blog-Posts aus - die Chats seien "eine Goldmine" für Einblicke in die Hackergruppe, schreibt er.

Derweil sucht die Ukraine auch für den Cyberraum Freiwillige, die bei der Verteidigung helfen - man muss sich also nicht gleich Anonymous anschließen, um etwas zu tun. Die weltweite Solidarisierung mit den Ukrainern im Cyberraum durch Unternehmen und Zivilbevölkerung geht allerdings über Hacking hinaus. Beispiele:

• Die Zivilbevölkerung nutzt Google-Rezensionen russischer Restaurants sowie Tinder, um Russen Informationen und eine Perspektive auf den Krieg zukommen zu lassen, die nicht in den vom Putin kontrollierten russischen Medien zu finden sind. Die Idee und der Aufruf dazu stammen ebenfalls von Anonymous.
• Elon Musk aktiviert seine Satelliten-Internet-Technologie "Starlink" in der Ukraine, um zerstörte Internet-Infrastruktur zu kompensieren. Google Maps deaktiviert die Echtzeit-Informationen über Staus und Menschenansammlungen für die Ukraine, nachdem klar wurde, dass diese Daten Einblicke in russische Truppenbewegungen, aber auch Rückschlüsse auf Fluchtbewegungen und Schutzräume der Ukrainer möglich sind. 
• Und Twitter und Facebook sperren russische Werbeanzeigen, weil sie Desinformation über den Krieg verbreiten.

All diese Informationsschnipsel haben neben dem süßen, Hoffnung stiftenden auch einen bitteren Beigeschmack: Sie zeigen, welche Macht die großen Technologie-Unternehmen haben, die sogar einen Krieg beeinflussen können. Gut, dass sie in diesem Krieg alle auf der richtigen Seite stehen...

Es ist keine gute Zeit für Spekulationen über mögliche neue OT-Security-Angriffe, so interessant sie aus technischer Sicht auch wären. Es ist für die Ukrainer am Ende egal, ob ihre kritischen Infrastrukturen (lies: Grundlagen des zivilen Lebens) physisch oder aus dem Cyberraum angegriffen werden.
Wenn Sie an Kontext und Historie zu russischen Angriffen auf kritische Infrastrukturen, auch 2015 in der Ukraine, interessiert sind, empfehle ich die Lektüre von Andy Greenbergs "Sandworm" (Lesestoff 3).

3. Sinn, Unsinn und Quantifizierbarkeit von Security-Risikoanalysen

Ein kleiner Lesehinweis aus einer Online-Diskussion im Februar: Machen wir eigenltich "risikobasiert" zu sehr zu einem Dogma?, habe ich mich gefragt. Wenn man schon glaubt zu wissen, welche Security-Anforderungen man umsetzen muss - ist es dann sinnvoll, Risiken "hinzuzudichten", weil man damit sein Bauchgefühl logisch validiert, oder ist es eine überfllüssige akademische Übung?

Die harmlose Frage hat äußerst interessante Diskussionen aufgebracht - von Cyber-Hygiene über Quantifizierbarkeit von Risiken und die Entwicklung des Risikobegriffs in der Safety bis hin zu Buchtipps ist in über 100 Kommentaren das ein ode andere Juwel dabei. Links zum Schmökern finden Sie im Lesestoff 1 und 2.

4. Sind SBOMs näher, als wir denken?

SBOMs sind eins der viel gepriesenen Security-Allheilmittel der Stunde. SBOM steht für "Software Bill of Materials", also eine Software-Stückliste. Gemeint ist im Prinzip so etwas wie ein Assetinventar, aber innerhalb einer Software: Welche Module enthält die Software? Welche Bibliotheken werden verwendet? Welcher Protokollstack?

Es ist kein Zufall, dass das Thema SBOM in den letzten Jahren, mit Ripple20 (HardHats 07/20) im Jahr 2020 sowie SolarWinds (HardHats 01/21, 03/21) und Log4j im Jahr 2021, an Bedeutung gewonnen hat. Allen drei Schwachstellen ist gemein, dass sie in weit verbreiteter Software steckten und es teils Wochen gedauert hat, bis Softwarehersteller angeben konnten, ob sie von der Schwachstelle betroffen waren - denn sie hatten möglicherweise die betroffene Software irgendwo in ihren Produkten verwoben - nur wenige Hersteller schreiben wirklich allen Code selbst.
SBOMs versprechen die Lösung für dieses Problem, indem sie Softwarestückchen und Abhängigkeiten innerhalb einer Software transparent machen. Mit einem SBOM, so die Hoffnung, ließe sich beim nächsten Ripple20, SolarWinds oder Log4j in Nullkommanix herausfinden, ob man betroffen ist. Gleichzeitig haben SBOMs Nutzen über Security hinaus: Softwarelizenzen sind einfacher verwaltbar, und Developer müssen bewusster über Abhängigkeiten ihrer Software nachdenken, wenn sie ihr ein SBOM mitgeben müssen.

Die Linux Foundation hat nun einen umfassenden Bericht zum Thema SBOM herausgegeben (s. Lesestoff), für den sie Unternehmen zu ihrer Einstellung zum Thema Software Security und SBOMs befragt haben.
Es ist passend, dass so ein Report von der Linux Foundation kommt, denn die Nutzung von OpenSource-Software wie Linux in jedem Winkel des Internets und Software-Universums macht die Betroffenheitsanalysen bei Schwachstellen in solcher Software natürlich zu einem ebenso weit verbreiteten Problem - eine entsprechend große Rolle spielen SBOMs als ein Teil der Lösung.

Der Bericht enthält neben guten Erklärungen, was SBOMs eigentlich sind und was sie enthalten ("A SBOM is formal and machinereadable metadata that uniquely identifies a software component, its dependencies, and license data"), einige erhellende, teils sogar überraschende Botschaften:

• SBOMs sind schon relativ weit verbreitet: 47% der befragten Organisationen haben schon 2021 SBOMs selbst produziert oder konsumiert, 78% streben dies 2022 an.
• Security ist unter den Befragten die #1 Priorität bei der Auswahl von Software. Das hätte ich, die immer sagt, niemand entscheide sich nur aus Security-Bedenken gegen eine Funktionalität, nicht gedacht (ich vermute auch, dass die Umfrage unter Automatisierern andere Ergebnisse zutage gebracht hätte).
• SBOMs sind für die Befragten neben niedrigschwelliger Infrastruktur für die Meldung von Schwachstellen die vielversprechendste Maßnahme gegen Lieferkettenrisiken (wie Ripple20, SolarWinds und Log4j).
• Fast alle Befragten waren sich darüber bewusst, dass die "Executive Order on Improving the Nation's Cybersecurity" der US-Regierung aus dem Mai 2021 die Empfehlung einer SBOM enthält und wollen unter anderem deswegen SBOMs einführen. Wer hätte das gedacht - Papier ist nicht nur geduldig, sondern wirkt tatsächlich...

5. IDEAS-Paper: Warum wir ein Security-Engineering-Informationsmodell brauchen

Über ein Security-Engineering-Informationsmodell haben Sie mich schon oft schreiben hören, aber was kann man konkret damit anfangen?
Als erstes Zwischenergebnis unseres BMBF-Projekts IDEAS habe ich mit unseren Projektpartnern Emre Taștan und Rainer Drath von der Hochschule Pforzheim Anwendungsfälle für ein Security-Engineering-Domänenmodell beschrieben:

1. Informationsaustausch zwischen security-relevanten Planungswerkzeugen
2. Aufrechterhaltung der Security während des Betriebs
3. Visualisierungen und modellbasiertes Security-Engineering
4. Integration von Security in den Prozess der Automatisierungstechnik - "Security by Design"

Wir leiten danach Anforderungen an das Domänenmodell ab - und für Datenmodell-Liebhaber beinhaltet das Paper auch den Beginn eines AutomationML-Modells zur Unterstützung der Anwendungsfälle und Erfüllung der Anforderungen, indem ein "SPR-Konzept" eingeführt wird: Die Beschreibung von zu schützenden Systemen mittels "Dreiecken" aus Sender, Process und Receiver. Das Paper ist frei verfügbar (Open Access), den Volltext finden Sie im Lesestoff-Link.
Am 11.03. hält Emre Taștan außerdem den Vortrag zum Paper auf der Pforzheimer Konferenz AALE (Angewandte Automatisierungstechnik in Lehre und Entwicklung). Die Konferenz ist online und kostenlos, das Veranstaltungsprogramm finden Sie hier. Registrieren geht kostenlos hier.

Woran wir gerade arbeiten: Der Frage, wie genau wir Security im Automation-Engineering-Prozess unterbringen. Wir dachten, es kommt dabei so etwas wie ein Phasenmodell heraus - tut es aber nicht.
Eigentlich wollte ich erste Ergebnisse auf der S4 in Miami, Florida vorstellen, die in den April verschoben wurde, aber die Pandemie verunmöglicht die Reise über den Atlantik mit einem Säugling. Deswegen wird es nun Ergebnisse auf der AUTOMATION im Juni in Baden-Baden geben.

6. LANUV-Veranstaltung: Safety und Security in der Anlagensicherheit

Wir schließen wie versprochen mit einem Veranstaltungshinweis für diejenigen unter Ihnen, die sich Security in Sicherheitsberichten und Genehmigungsunterlagen für die Anlagensicherheit herumschlagen:
Die Veranstaltungsleiter Ludwig Schenk und Stephan Gebhard (LANUV) haben eine zweitägige Veranstaltungen "Safety und Security in der Anlagensicherheit" zusammengestellt, die den Fokus auf praktische Hilfestellung legt. Ich darf in zwei Sitzungen Hintergrundwissen und praktische Anleitung zu IT-Risikobeurteilungen geben. Wir werden unter anderem auch auf das heiß diskutierte Thema eingehen, welche Informationen im Sicherheitsbericht denn nun dargestellt werden dürfen, müssen, sollen und können - und welche nicht.

Die Veranstaltung ist übrigens ein hervorragendes Beispiel dafür, wie Sie mit "denen in der Behörde" ins Gespräch kommen, ihre Anforderungen besser verstehen und diskutieren können. Anträge und Genehmigungsverfahren werden ja doch immer erträglicher, wenn man die Menschen dahinter kennt...

Es ist eine Hybridveranstaltung, man kann also virtuell oder in Präsenz teilnehmen. Es ist auch möglich, ein Ticket für einen einzelnen Tag zu kaufen. Programm und Registrierungsmöglichkeit finden Sie im Lesestoff-Link.

Stay secure!
Sarah Fluchs