Das eine Ereignis, das an Stelle 1 des Briefings stehen muss, steht meist schon früh fest - so auch diesen Monat. Es ist natürlich die Colonial-Pipeline. Wir schauen also - wieder einmal - in die USA. Aber auch hier bei uns ist einiges passiert: Forscher haben Sicherheitslücken im Tesla gefunden, das IT-Sicherheitsgesetz ist in Kraft und neue Umsetzungshinweise für OT-Bausteine im IT-Grundschutz gibt es auch.
Ich bin da ja nicht ganz objektiv, aber der wichtigste Termin für Juni steht eigentlich schon fest: Am 15. Juni veröffentlichen wir die Top 20 Secure PLC Coding Practices. Details siehe unten.
Und zum Ende des kommenden Monats gibt natürlich der Leitkongress der Automatisierungstechnik AUTOMATION - wenn auch digital statt in Baden-Baden. Ich darf zum Abendprogramm des Kongresses beitragen: Am 29.06. ab 18 Uhr können Sie meinen Beitrag zum diesjährigen Science Slam hören und sehen.

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

1. Colonial Pipeline: Hauptsache, die Anlage läuft?!
2. Microsoft Cybersecurity Reference Architecture - auch für Azure
3. Neue Autos, neue Angriffsvektoren
4. Welche Schwachstelle lohnt sich zu patchen?
5. Ein Security-Engineering-Werkzeug für Automatisierer
6. BSI hat Umsetzungshinweise zu OT-Bausteinen veröffentlicht
7. IT-Sicherheitsgesetz 2.0 ist nun in Kraft
8. Top 20 Secure PLC Coding Practices werden am 15. Juni veröffentlicht

1. Colonial Pipeline: Hauptsache, die Anlage läuft?!

Wenn Sie den letzten Monat nicht auf einer einsamen Insel verbracht haben, hatten Sie wahrscheinlich wenig Chance, drumherumzukommen: Colonial, der Betreiber der größten Pipeline der USA, ist Opfer eines Ransomware-Angriffs geworden.

Wie immer sortieren wir mal in Ruhe:

Was ist eigentlich passiert?
Das Office-IT-Netzwerk (nicht das OT-Netzwerk) von Colonial ist Anfang Mai mit Ransomware infiziert worden. Die OT-Systeme waren also von der Ransomware selbst nicht betroffen. Colonial hat daraufhin aber trotzdem eigentlich nicht betroffene Systeme im OT-Netzwerk heruntergefahren, und damit den Betrieb der Pipeline.

Warum genau hat Colonial die Pipeline außer Betrieb genommen?
Diese Tatsache hat Fragen aufgeworfen: Warum hat Colonial die Pipeline genau abgeschaltet? Die OT-Systeme zum Steuern und zu Beobachten des Benzinflusses waren ja intakt.

Automatisierungssysteme im Pipeline-Betrieb sind dafür da, den Benzinfluss über die Pipeline zu steuern und zu beobachten. Außerdem senden sie Daten an das IT-Netzwerk, um die Abnahmemengen zu übermitteln, auf deren Grundlage Rechnungen gestellt werden.

Hätte Colonial nur Sorge gehabt, dass die Ransomware sich von der IT in die OT ausbreitet, hätten sie die Verbindung zwischen beiden Netzerken trennen können. Daher liegt die Vermutung nahe: Die Pipeline wurde abgeschaltet, weil man das ausgelieferte Benzin nicht mehr hätte abrechnen können. Mit ihrem Angriff haben die Hacker also genau genommen nicht die Verteilung, sondern die Abrechnung des Treibstoffs lahmgelegt.

Und was hatte das für Auswirkungen?
Colonial sitzt im US-Bundesstaat Georgia und ist der größte US-amerikanische Pipeline-Betreiber. "Größte" wird hier gemessen am Volumen. Die Pipeline transportiert knapp 400 Millionen Liter Erdölprodukte täglich von Texas nach New York, ist 8800 Kilometer lang und versorgt 50 Millionen Verbraucher.

Verbraucher, das sind vor allem Autofahrer, Häfen und Flughäfen: 45 Prozent der an der US-Ostküste verbrauchten Kraftstoffe kommen aus der Colonial-Pipeline.
Dementsprechend sahen die Versorgungsengpässe aus: Nach dem Herunterfahren der Pipeline gab es in den betroffenen Gebieten an 50 bis 70 Prozent der Tankstellen kein Benzin mehr.
Vielleicht haben Sie Bilder von Autofahrern gesehen, die in sicherheitstechnisch fragwürdigen Gefäßen Benzin an Tankstellen gebunkert haben. Hamsterkäufe - dieses Mal für Benzin statt für Toilettenpapier. Die US-Behörden warnten davor, Benzin in Plastiktüten abzufüllen - dieser besonders bizarre Fall, der in den sozialen Netzwerken viral ging, kam aber gemäß einem Reuters-Factcheck aus dem Jahr 2019 und hatte nichts mit den Colonial-Angriffen zu tun.

Währenddessen sanken die Benzinpreise im Süden der USA am Golf von Mexiko, wo der Treibstoff ankam, aber ohne Pipeline nicht weiter transportiert werden konnte.

Wie ist Colonial mit dem Angriff umgegangen?
Vorweg: Die Angreifer dürften zufrieden sein. Colonial-CEO Joseph Blount hat entschieden, das Lösegeld ("Ransom") von umgerechnet 3,6 Mio Euro zu zahlen. Es ist nicht so selten, dass Lösegeldforderungen gezahlt werden - auch wenn Experten und Behörden sich stets wünschen, dass das nicht passiert, um das Ransomware-Geschäft unattraktiver zu machen.

Es ist aber recht selten, dass Unternehmehn öffentlich machen, dass und warum sie das Lösegeld gezahlt haben. Im Fall von Colonial: Man sei sich über das Ausmaß der durch den Schadcode verursachten Schäden unsicher gewesen und habe nicht einschätzen können, wie lange es dauern würde, bis man die Pipeline wieder betreiben könne - trotz Einbindung von Behörden und einer externen IT-Sicherheitsfirma.

Man kann sich also vorstellen, dass die unternehmerische Rechnung für Blount einfach war: Eine unbestimmte Zahl von Tagen Pipeline-Ausfall auf der einen, 3,6 Mio Euro auf der anderen Seite.

Wer steckt hinter dem Angriff?
Der verwendete Schadcode ist die Ransomware "DarkSide", wie das FBI bekanntgab. DarkSide ist ein relativ neues Geschöpf im Ransomware-Zoo, wird erst seit 2020 beobachtet, und soll in Russland oder der Ukraine geschrieben worden sein. Allerdings wird DarkSide als "Ransomware-as-a-Service" angeboten, sein Einsatz kann also auch von anderen "Kunden" beauftragt worden sein.

Die Gruppe hinter DarkSide rühmt sich selbst damit, bestimmte Sektoren wie Bildung und Gesundheitswesen nicht anzugreifen. "Our goal is to make money, and not creating problems for society" ließen sie nach dem Pipeline-Shutdown auf ihrer Website verlauten, die nun nicht mehr verfügbar ist.
Offenbar hat der Angriff tatsächlich größere Folgen gehabt, als die DarkSide-Macher erwartet hatten: DarkSide hat angeblich seinen Kunden mitgeteilt, dass die Ransomware-as-a-Service-Dienste nicht mehr zur Verfügung stehen. Der Grund: Der Druck der US-Behörden und steige, und damit sei die Aufrechterhaltung der eigenen Infrastruktur schwieriger.

Wie haben die US-Behörden reagiert?
Zur Eindämmung der Folgen hat die US-Regierung kurz nach dem Angriff den regionalen Notstand erklärt, um den Transport von Benzin von Texas nach New York mit LKWs statt der Pipeline zu beschleunigen.

Wichtiger noch: Am 27. Mai hat die US-Regierung eine Security-Direktive erlassen, die höhere Security-Anforderungen an Pipelinebetreiber stellt.

Kann mir das auch passieren?
Die nagende Frage nach solchen Ransomware-Vorfällen ist für Betreiber: Könnte uns das auch passieren? Man kann versuchen, eine Antwort zu finden, indem man zusammenträgt, was wir über die Security-Situation bei Colonial wissen - und das ist naturgemäß nicht viel, außer dass US-Regierungsmitarbeiter "frustriert" über den Security-Status bei Colonial waren.

Was können wir daraus lernen?
Zuerst die Binsenweisheiten.
Was bei Ransomware immer stimmt: Die effektivste Maßnahme sind funktionierende Backups, die offline und am besten an einem anderen Ort gesichert sind und deren Restore  regelmäßig unter Ernstfall-Bedingungen getestet wird (die Wiederherstellung sollte nicht nur funktionieren, sondern auch schneller gehen als die maximal tolerierbare Ausfallzeit der Systeme). Das hätte bei Colonial vielleicht geholfen.
Vielleicht? Nun ja: Es sind im Colonial-Fall auch Daten abgeflossen. Wogegen Backups nämlich nicht helfen, ist die zweite, häufiger werdende zweite Erpressungsstrategie: Sensible Daten kopieren und mit deren Veröffentlichung drohen.

Auch immer richtig: Sicherstellen, dass Ransomware sich nicht von der IT in die OT ausbreiten kann. Dies war im Colonial-Fall aber - wie weiter beleuchtet - wahrscheinlich nicht ursächlich für die Abschaltung der Pipeline. Trotzdem wäre die Ausbreitung wahrscheinlich technisch möglich gewesen, wie Kim Zetter in ihrem bemerkenswert detaillierten Bericht aufdröselt.

Nur: Der Befall der OT war ja gar nicht notwendig. Denn ein entscheidender Strang des Geschäftsmodells der Pipeline (die Abrechnung) war absolut abhängig von Systemen in der IT, die mit Daten aus der OT gespeist wurden. Für die OT galt also nicht nur "Hauptsache, die Anlage läuft", sondern auch "Hauptsache, die Anlage liefert vertrauenswürdige Daten an die IT".

Lessons Learned daher:

1. Manchmal ist es nicht so offensichtlich, was eigentlich wichtige Funktionen von OT-Systemen sind, die unter keinen Umständen versagen dürfen.
2. Die Kritikalität dieser Funktionen wird auch nicht offensichtlich, wenn man reine Datenströme anschaut, sondern erst, wenn man "zu welchem Zweck"? fragt.
3. Manchmal sind die wichtigen Funktionen von OT nicht erkennbar, wenn man allein OT-Experten fragt.
   Hand aufs Herz: Wer von Ihnen übermittelt Daten aus Leitsystemen "irgendwo in die IT"? Und wer hätte "Übermittlung von Messdaten an die IT" als absolut kritische Funktion eingestuft?
4. Angreifer müssen die wichtigsten Funktionen und Abhängigkeiten der Systeme nicht so kennen. Sie können einfach Glück oder Pech - je nach Perspektive haben, dass ein Angriff mehr Auswirkungen hat als erwartet (so wohl geschenen bei DarkSide und Colonial).
   Aber Betreiber müssen mehr wissen als Angreifer, und gemeint sind nicht proprietäre Protokolle - das wäre "Security by Obscurity" - sondern die Wirkmechanismen ihres komplexen Gesamtsystems.
   "Das durchschaut eine einzelne Person ohnehin nicht mehr, also auch kein Angreifer" ist keine akzeptable Ausrede.

2. Microsoft Cybersecurity Reference Architecture - auch für Azure

Da wir gerade beim Thema Datenübertragung von der OT in die IT sind: Ein häufiger Grund für solche Datenübertragungen ist die Hoffnung auf neue Analysemöglichkeiten oder bessere Administrationsmöglichkeiten in der Cloud.

Das Problem mit der Cloud ist, wie ich vergangenen Monat auch im Schlusswort "Zu guter Letzt" der aktuellen atp-Ausgabe schreiben durfte: Sie könnten statt einer Wolke eigentlich auch einen schwarzen Kasten in Ihre Netzpläne einzeichnen, denn die Cloud ist oft vor allem eine Black Box.

Ein bisschen durchsichtiger wird die Black Box, je mehr Sie über Microsofts Security-Mechanismen Bescheid wissen. Dabei hilft der beeindruckend detaillierte Foliensatz "Microsoft Cybersecurity Reference Architecture", den Microsoft am 14. Mai veröffentlicht hat. Er enthält auch eine Folie zu Azure (s. Lesestoff-Link).

Wie die Architektur von Microsofts Azure IoT aussieht und wofür die Lösung gedacht ist, erklärt Bill Lydon übrigens in diesem Artikel.

3. Neue Autos, neue Angriffsvektoren

Der Security gehen ja die Ziele nicht aus, vor allem nicht, wenn Technologie sich (dankenswerterweise) ständig weiterentwickelt. Machen wir also einen kleinen Exkurs zu Elektroautos:

Wie Sie wahrscheinlich wissen, sind Autos ja eher Computer mit Lenkrad. Deswegen haben sie natürlich viele Features, die wir auch von unserern Computer kennen. Zum Beispiel ein Stück Software mit dem Titel "ConnMan" - ein Linux-basierter Internet Connection Manager. Sie benutzen solche Software, wenn Sie das an Ihrem Smartphone das WLAN Ihres Lieblingscafés auswählen (Sie erinnern sich? So etwas hat man 2019 ab und an gemacht...), und Tesla-Autos nutzen eben "ConnMan", wenn ihr Besitzer oder ihr Infotainment-System eine Internetverbindung braucht.
Dieses Stück Software hat jedenfalls eine Schwachstelle, wie die deutschen Forscher Ralf-Philipp Weinmann und Benedikt Schmotzle herausgefunden haben. Man kann damit, wenn man in WLAN-Reichweite ist, alle Funktionen steuern, die ein Fahrer im Auto steuern kann, wenn er Knöpfe in der Konsole des Infotainment-Systems drückt - etwa Türen öffnen.
Was nicht geht: Losfahren.

Die Forscher haben den Angriff "TBONE" getauft - den Bericht dazu finden Sie im Lesestoff-Link 1. Tesla hat die Lücke mittlerweile gepatcht und nutzt den ConnMan nicht mehr als Internet Connection Manager.

Das Infotainment-System ist zwar in diesem Fall in einem Tesla eingebaut, jedoch nicht E-Auto-spezifisch. Keine bekannten Security-Angriffe, aber dafür bedenkenswerte E-Auto-spezifische Auswirkungsszenarien beschreibt dieser Artikel.
Erinnern Sie sich noch an die brennenden Samsung-Akkus, die 2016 in aller Munde waren und uns seitdem in Flugzeugen einen neuen Satz in der Safety-Einweisung bescheren ("wenn Ihr Smartphone raucht, nehmen Sie bitte Kontakt zum Kabinenpersonal auf")?
Nun stellen Sie sich vor, das, was brennt, ist keine Smartphone-Batterie - sondern die eines E-Autos. Fazit des Artikels: Für E-Autos braucht man deutlich mehr Wasser zum Löschen als für ein normales Auto - und einmal entzündet, schmoren die auch schon mal tagelang unter Wasser weiter.
Unsympathisch.

4. Welche Schwachstelle lohnt sich zu patchen?

Es ist eine große, wenn nicht die größte Frage im Schwachstellenmanagement, vor allem, wenn man von Schwachstellen überflutet wird und mit dem Patchen erheblicher Aufwand verbunden ist: Welche Schwachstellen sind wichtig genug, um sie zu patchen?

Zur Bewertung von Schwachstellen gibt es viele Ansätze, allen voran den CVSS Score, der jeder Schwachstelle mit einer CVE-Nummer quasi als Beipackzettel beiliegt.

Das EPSS-Projekt ist ein Community-Projekt, das die Wahrscheinlichkeit, das eine Schwachstelle ausgenutzt wird, genauer beziffern möchte. Dafür nutzt es nicht nur Informationen über die Schwachstelle (wie auch CVSS), sondern auch Beobachtungen über tatsächlich gesichtete Ausnutzungen einer Schwachstelle.

Das Projekt ist ein wichtiger Schritt zur besseren Quantifizierbarkeit von Security-Risiken. Denn während wir etwa in der Safety Statistiken haben, um die Wahrscheinlichkeit für das Versagen eines Teils zu beziffern, fehlen solche Statistiken in der Security bislang, sodass man sich oft mit hypothetischen Werten behelfen muss.

Die Daten des Projekts sind frei verfügbar (Link im Lesestoff). Bislang wurde die Ausnutzungswahrscheinlichkeit von über 60.000 Schwachstellen bewertet. Auf derselben Seite findet sich auch eine genauere Beschreibung des zugrundeliegenden Berechnungsmodells.

5. Ein Security-Engineering-Werkzeug für Automatisierer

Unser BMBF-Projekt "IDEAS" hatte ich Ihnen im Mai-Briefing schon angekündigt, nun schiebe ich noch etwas Lesestoff hinterher.

Zur Erinnerung: IDEAS steht für Integrated Data Models for the Engineering of Automation Security.  Der Lesestoff-Link beinhaltet eine kurze und niedrigschwellige Einführung für diejenigen unter Ihnen, denen "Integrated Data Models" so gar nichts sagt.

6. BSI hat Umsetzungshinweise zu OT-Bausteinen veröffentlicht

Bekanntermaßen hat das BSI in sein IT-Grundschutz-Kompendium, das für ausgewählte Systeme und Prozesse ("Bausteine" genannt) häufige Gefährdungen und Maßnahmen auflistet, mittlerweile auch OT-relevante Systeme aufgenommen. Die Bausteine tragen das Kürzel "IND" für Industrie.

Oft interessanter als die Bausteine selbst, weil detaillierter, sind die Umsetzungshinweise zu den Bausteinen, die Vorschläge für die Umsetzung der empfohlenen Maßnahmen an den betroffenen Systemen enthalten. Für fünf IND-Bausteine (Prozessleit- und Automatisierungstechnik, Allgemeine ICS-Komponente, SPS, Maschine und Safety Instrumented System) gibt es nun solche Umsetzungshinweise - Sie finden den Link im Lesestoff.

Die Qualität der Bausteine und damit auch der Umsetzungshinweise variiert. Der SPS-Baustein und die dazugehörigen Umsetzungshinweise enthalten ganze zwei Maßnahmen - Dokumentation und Zeitsynchronisation; die Hinweise für Safety Instrumented Systems (SIS) überraschenderweise deutlich mehr, teilweise durchaus auch für SPS relevante Maßnahmen wie die sichere Übertragung von Engineering-Daten.

7. IT-Sicherheitsgesetz 2.0 ist nun in Kraft

Endlich keine "ungelegten Eier" mehr: Das IT-Sicherheitsgesetz 2.0.
Wir erinnern uns kurz an die Regeln des deutschen Gesetzgebungsverfahren: Es endet mit der Veröffentlichung eines Gesetzes im Bundesgesetzblatt. Nachdem das IT-SiG 2.0 also den Bundesrat passiert hatte, stand nur noch die Veröffentlichung im Bundesgesetzblatt aus, die am 27.05. erfolgt ist (siehe Lesestoff) - am Tag danach tritt das Gesetz in Kraft.

Merken wir uns also den 28.05.2021. Ich würde wetten, dass in ein paar Monaten Security-Verantwortliche bei sowohl KRITIS-Betreibern als auch Unternehmen im besonderen öffentlichen Interesse (Uniböfi) das Datum auswendig aufsagen können, wenn sie nachts um drei geweckt werden.

Denn: Von dem Datum hängen die Fristen zur Erbringung von Nachweisen ab. Allerdings hat man die Fristen in der letzten Version des Gesetzes leicht geglättet, sodass sie jeweils am Monatsbeginn liegen statt auf dem 28. (und damit faktisch die Fristen um jeweils einen Monat reduziert):

• 24 Monate später (01.05.2023) müssen Systeme zur Angriffserkennung das erste Mal von Betreibern kritischer Infrastrukturen nachgewiesen werden (§ 8a Abs. 1a BSIG)
• ab 6 Monate später (01.11.2021) müssen Betreiber, die unter die Störfallverordnung fallen, Vorfälle dem BSI melden (§ 8f Abs. 8 BSIG)

Ein paar ungelegte Eier bleiben aber. Viele Fristen hängen vom Inkrafttreten von Rechtsverordnungen ab. Diese legen beispielsweise Schwellenwerte für KRITIS-Betreiber und für Unternehmen im besonderen öffentlichen Interesse fest (außer denen, die unter die Störfallverordnung fallen).

Gern übersehen: Neben neuen Anforderungen für Betreiber Kritischer Infrastrukturen und Unternehmen im besonderen öffentlichen Interesse ändert sich auch für das BSI viel. Hier sehen Sie das "neue" Selbstverständnis des BSI.

8. Top 20 Secure PLC Coding Practices werden am 15. Juni veröffentlicht

Die Top 20 Secure PLC Coding Practices ist ein Projekt, das sichere Coding-Praktiken für speicherprogrammierbare Steuerungen (SPS) erarbeitet - analog zu den in der "normalen" Softwareentwicklung schon lange gebräuchlichen "Secure Coding Practices".

Von dem Projekt haben Sie hier einiges gehört, weil auch von mir persönliches einiges an Herzblut hineingeflossen ist. Ende 2020 habe ich versprochen, dass wir im Juni 2021 ein fertiges Dokument veröffenltichen - und das Projektteam ist sehr stolz, nun verkünden zu dürfen: Wir halten Wort.

Am 15. Juni werden die Top 20 Secure Coding Practices auf dieser Website veröffentlicht  (momentan ist landen Sie dort noch auf einer Baustellenseite). Aber folgen können Sie dem Projekt schon einmal, es hat nämlich nun auch einen frisch erstellten Twitteraccount:

Stay secure!
Sarah Fluchs