Es war im September schwierig, daran vorbeizukommen: Die Uniklinik Düsseldorf, kritische Infrastruktur im Sektor Gesundheit, hatte einen Ransomware-Vorfall. Als Folge konnte eine Frau nicht notfallbehandelt werden und starb nach der um eine Stunde verspäteten Behandlung im 30 km entfernten Wuppertaler Krankenhaus - oder verkürzt in den Schlagzeilen: Tod durch Ransomware. Die Meldung machte als "erstmals Tote durch einen Hackerangriff" weltweit die Runde.

Wir widmen uns den technischen Hintergründen des Vorfalls - und auch sonst ist das Oktoberbriefing recht vorfallslastig. Schutzhelme wärmstens empfohlen.

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

1. Ransomware-Vorfall in der Uniklinik Düsseldorf
2. Blackout durch Desinformation, Flugzeugabsturz durch Fehler in Engineering und Zertifizierung
3. Öffentliche Datenbanken über OT-Security-Vorfälle
4. Hilfestellung für die Reaktion auf Security-Vorfälle: ISO/IEC 27035-3:2020 frisch veröffentlicht
5. Wie aus Leuchttürmen digitale Zwillinge werden können
6. OT-Security-Konferenzen in der Pandemie
7. Update zum Secure PLC Coding Projekt

1. Ransomware-Vorfall in der Uniklinik Düsseldorf

Die Uniklinik Düsseldorf (kurz UKD) gehört zu den kritischen Infrastrukturen im Sektor Gesundheit (der Schwellenwert liegt bei 30.000 stationären Fällen pro Jahr, die Klinik hat etwa 50.000).

In der Nacht vom 9. September wurde das Krankenhaus Opfer eines Ransomware-Angriffs, bei dem 30 Server verschlüsselt wurden. Einfallstor war nach Angaben des BSI die Citrix-VPN-Schwachstelle CVE-2019-19781, auch liebevoll "Shitrix" genannt.Mittlerweile nimmt das UKD auch Notfälle wieder auf, und gegen die Täter wird ermittelt - im Raum steht der Verdacht auf fahrlässige Tötung. Wie üblich dürften die Täter wohl unbekannt bleiben.

Aufgrund der nachgeladenen Schadsoftware DoppelPaymer steht eine russische Hackergruppe im Verdacht.
Die Landesregierung will künftig mehr Geld für IT-Sicherheit in Krankenhäusern zur Verfügung stellen - bislang 2 Mio. Euro jährlich pro Uniklinik.

Eigentlich wollte ich hier nur eine kurze Analyse schreiben, aber nachdem ich mich durch die (auffallend spärlichen) Informationen zum Vorfall gearbeitet hatte, war das Ergebnis zu viel für einen HardHats-Unterpunkt.Daher ist daraus ein Blogeintrag geworden (siehe Lesestoff-Link). Wer jetzt nämlich nur nach besserem Patchmanagement schreit, macht es sich entschieden zu leicht.

Stattdessen hier meine fünf Lektionen in Kurzform:
Lektion 1: Keine Gnade für möglicherweise kompromittierte Systeme

Lektion 2: “Security-Experten” können Organisationen nicht um ihre Security-Verantwortung erleichtern

Lektion 3: Kritische Systeme müssen so IT-unabhängig wie möglich arbeiten können

Lektion 4: Man muss nicht auf der Zielscheibe sein, um Ziel zu werden

Lektion 5: Mehr Security machen, nicht nur mehr Security kaufen.

2. Blackout durch Desinformation / Flugzeugabsturz durch Fehler im Engineering- und Zertifizierungs-Prozess

Zwei interessante Studien über das Eintreten von Vorfällen haben diesen Monat die Runde gemacht.

Der erste ist rein hypothetisch, aber ein interessanter Ansatz:
Kann nur durch Beeinflussung von Menschen ein weiträumiger Stromausfall (Blackout) entstehen?
Forscher aus Singapur und den Vereinten Arabischen Emiraten haben eine Studie veröffentlicht (Lesestoff-Link 1), die beleuchtet, ob durch Manipulation des Verhaltens von Stromkonsumenten durch gezielte Desinformation Stromausfälle herbeigeführt werden können. In der Studie wurden gefälschte Discount-Angebote verschickt, wenn man seinen Stromverbrauch auf eine bestimmte Zeit legt - die ohnehin schon eine Peak-Zeit ist.
Das Szenario beinhaltet zwar viele "wenns" (richtet hier irgendjemand seinen Stromverbrauch wirklich nach schwankenden Strompreisen aus?), aber es kann durchaus als Inspirationsquelle dienen für Security-Vorfallsszenarien, die völlig ohne Angriff auf die Technik herbeigeführt werden können.

Der zweite ist keine Studie, sondern der Ermittlungsbericht des US-amerikanischen Department of Energy zu den Boeing 373 Max-Abstürzen (Lesestoff-Link 2). Oberflächlich betrachtet hat er keinen Security-Bezug, aber bei den Inhalte zur funktionalen Sicherheit, Risikoanalysen und dem Zusammenspiel sorgfältiger Engineering-Prozesse und externer Überprüfungen durch Zertifizierungen, fällt es schwer, keine Security-Parallelen zu ziehen.
Ein Kernproblem hinter dem Absturz war das sogenannte MCAS (Maneuvering Characteristics Augmentation System) - eine Funktion, die unter bestimmten Bedingungen die Flugzeugnase nach unten drückt. Für MCAS wurde auf Redundanzen für kritische Sensoren verzichtet, man definierte die Funktion nicht als neue Safety-Funktion, um Zertifizierungsaufwände gering zu halten, und man entfernte Hinweise auf das System aus Trainingsunterlagen für Piloten.

Der Bericht ist lesenswert - nicht nur, weil er für einen Behörden-Ermittlungsbericht zumindest für deutsche Gewohnheiten in auffallend emotionalem Erzählstil verfasst ist, sondern auch weil er zeigt, wie über Jahre hinweg systematisch von Einzelpersonen zu Bedenken gegebene Risiken vom Tisch gewischt wurden. Der Bericht nennt das schonungslos "gambling" - zocken, mit den Leben von Flugzeugpassagieren als Einsatz.

3. Öffentliche Datenbanken über OT-Security-Vorfälle

Öffentliche Datenbanken über OT-Security-Vorfälle könnten uns allen helfen - um Risikoanalysen valider zu machen durch Statistiken über echte Fälle, und um die Prävention von und Reaktion auf Vorfälle zu verbessern.

Solche Datenbanken haben zwei Probleme: Erstens geben die wenigstens Unternehmen gern preis, dass sie Opfer eines Security-Vorfalls wurden und schon gar nicht inklusive aller Details. Zweitens muss die Datenbanken jemand pflegen und qualitätssichern, damit wir unsere Statistiken nicht aus fehlerhaften Daten zimmern (shit in, shit out).

Trotzdem gibt es ein paar Anläufe, ein paar davon schon älter, einer gerade neu. Achtung - Akronymschlacht:

1. RISI (Repository of Industrial Security Incidents) ist eine Datenbank von OT-Security-Vorfällen, die einen Einfluss auf den Betrieb hatten oder hätten haben können. Sie wurde zwischen 2001 und 2015 gepflegt und dann aus den oben genannten Gründen pausiert - bis heute.
2. CIRWA (Critical Infrastructure Ransomware Attacks): Die Datenbank basiert auf öffentlich bekannten Ransomware-Vorfällen zwischen 2013 und heute. Sie beinhaltet momentan 747 Vorfälle, alle inklusive MITRE ATT&CK-Mapping sowie einige Statistiken auf Basis der Datensätze und ist frei verfügbar. Sie wird gepflegt von der US-Amerikanischen Forschungseinrichtung CARE Lab um die Professorin Aunshul Rege, die Security-Fragestellungen aus sozialwissenschaftlicher Perspektive betrachtet.
3. SCIDMARK (Systems and Cyber Impact Database MARKup): Eine Datenbank, die im September nach fünf Jahren Arbeit erstmals als Testversion öffentlich gemacht wurde (und kostenlos und öffentlich bleiben soll). Das Projekt möchte keine Sammlung von Vorfällen sein, sondern eine Sammlung von Auswirkungen auf den Betrieb - spezialisiert auf OT. Entsprechend beinhaltet sie bislang wenige (14), aber sehr ausführlich nach ihren Folgen analysierte Vorfälle. Es wird von der US-Amerikanischen Organisation infracritical gepflegt.

4. Hilfestellung für die Reaktion auf Security-Vorfälle: ISO/IEC 27035-3:2020 frisch veröffentlicht

Noch ein Thema - dann ist es aber auch gut mit Vorfällen für diesen Monat:
Die ISO/IEC 27035-3 hat Ende August ihr finales Votum bestanden und ist nun frisch als internationaler Standard veröffentlicht.

Sie ist bislang nur auf Englisch verfügbar, aber einen schön sperrigen deutschen Titel gibt's schon mal (also falls Sie noch einen neuen Scrabble-Begriff mit V brauchen...):
"Leitlinien für IKT-Vorfallsreaktionsmaßnahmen".

Der Standard gibt konkrete Anleitung zur technischen Reaktion auf Vorfälle - das IKT steht für Informations- und Kommunikationstechnik. Es geht also explizit nicht um die oft abgehandelten organisatorischen Aspekte wie Meldeketten. Der Standard geht sukzessive die Incident-Response-Phasen "Erkennung und Meldung", "Einschätzung und Entscheidung" und "Reaktion" und gibt Hilfestellung von angemessenen Containment-Strategien (System herunterfahren oder nicht?) bis hin zu konkreten Arten von Tools (natürlich nicht konkreten Produkten), die bei der Reaktion hilfreich sind.

5. Wie aus Leuchttürmen digitale Zwillinge werden können

Vor zwei Jahren, als ich das Security-Engineering-Modell der Layered Blueprints (das mit den Leuchttürmen) vorstellte, habe ich mir am Ende gewünscht, dass wir nicht alle für uns allein Leuchttürme bauen, sondern sie teilen, nutzbar machen für andere und darüber diskutieren - eine Skyline von Leuchttürmen statt ein einsamer Turm auf einem Felsen.

Ron Brash (Director of Security Insights bei Verve) hat im vergangenen Monat das Konzept aufgegriffen, und gezeigt, wie er sich eine Implementierung eines Layered Blueprints für eine Komponente - zum Beispiel ein HMI-Bedienpanel - vorstellt. Analog könnte man Standard-Blueprints für bestimmte, häufig vorkommende Systeme bauen - ein Modell pro System, das alle Security-relevanten Informationen in sich vereint.

Klingelt da was? Genau - das klingt verdammt nach digitalem Zwilling. In einer Antwort auf Rons Post habe ich Gedanken dazu beigesteuert, wie aus Leuchtturmmodellen ein digitaler Zwilling werden kann und wie Asset Inventory und Configuration Management Tools wie zum Beispiel Verve dabei helfen können.

Rons Blogpost finden Sie im ersten, meine Antwort im zweiten Lesestoff-Link, und wie es weiter geht, erfahren Sie in einem der nächsten Schutzhelm-Briefings. Nur so viel: Die Herausforderung liegt in der Implementierung des Konzepts - von einer Idee auf einem Stück Papier zu einem nutzbaren Datenmodell als Idealbild eines Systems aus Security-Sicht.

6. OT-Security-Konferenzen in der Pandemie: CS3, SANS ICS, S4

Die großen OT-Security-Konferenzen finden ihren Weg durch die Corona-Pandemie - jede auf ihre Weise:

1. Die CS3sthlm in Stockholm findet am 21. und 22. Oktober statt - allerdings nicht in Stockholm, sondern virtuell. Trainings fallen aus, aber es gibt eine virtuelle "Welcome Reception" - zum gegenseitigen Kennenlernen der Teilnehmer und Warmwerden mit der Konferenzplattform. Konferenzbeiträge werden Teilnehmern auch im Nachgang als "Video on Demand" zur Verfügung gestellt. Tickets kosten 229 €.
2. Auch der SANS Insitute ICS Summit findet im März 2021 virtuell statt - und erstmals kostenlos, ebenso wie der Capture The Flag (CTF)-Wettbewerb, bei dem Teilnehmer möglichst viele voreingebaute Schwachstellen in den Zielsystemen in möglichst kurzer Zeit ausnutzen müssen.
   Eine Woche nach dem Summit gibt es (kostenpflichtige) Trainings.
3. Einen anderen Weg geht die S4:
   Die S4x21 in Miami fällt aus. Gründer Dale Peterson erklärt in einem Blogartikel, warum er sich gegen eine virtuelle Konferenz entschieden hat.
   Interessantester Grund aus meiner Sicht: "The virtual conference approach is a primitive and not particularly effective use of the media. At the start of the television age, most programs consisted of radio talent reading scripts into a microphone with little thought to how to use the video feed. Early Internet ads were banner ads similar to display ads in newspapers. It's common to try to recreate what worked in one media in the new media, and I think this is what we are doing with virtual conferences. Can we do better than full or multi-day powerpoint presentations? I think so."
   Es wird stattdessen OT-Security-Inhalte weiterhin im wöchentlichen Podcast und auch in einer neuen, wöchentlichen "TV show" geben.
   Dafür ist die S4x22 bereits geplant für den 25. - 27. Januar 2022. In Pandemiezeiten wird es ja langsam zur Gewohnheit, Kalender zwei Jahre im Voraus zu befüllen...

7. Update zum Secure PLC Coding Projekt

Keine Konferenz, aber ein Communityprojekt:
Bei den Secure PLC Coding Practices geht es voran.

Das Projekt in Zahlen: Wir haben mittlerweile 635 registrierte User, 46 Practice-Kandidaten und 30 neu vorgeschlagene Practices.
Es geht jetzt ans Konsolidieren, Vervollständigen, Verfeinern - und wir haben eine Voting-Funktion eingeführt, um Practices nach dem "Bundesligaprinzip" in die Top 20 Auf- und Absteigen zu lassen.

Sie wollen unterstützen, haben aber nur ein paar Minuten Zeit? Hier sind drei schnelle Wege, mitzumachen:
1) Hier abstimmen, welche Practices aus Ihrer Sicht unbedingt in die Top 20 müssen:

2) Komplettieren Sie eine der unvollständigen Practices. Oft fehlen noch Beispiele, Erklärungen, oder Gründe, warum die Practice wichtig ist. Idealerweise kommentieren Sie einfach mit Textbausteinen, die in die Lücken passen. Eine Liste unvollständiger Practices finden Sie hier.

3) Schlagen Sie eine neue Practice vor, die aus Ihrer Sicht wichtig für SPS-Security ist, in der Liste aber fehlt. Hier ist eine Anleitung, wie das geht - Sie müssen nur ein Template befüllen (und alles frei lassen, was Sie nicht befüllen können).

Eine deutschsprachige Diskussionsgruppe trifft sich monatlich in einer Webkonferenz, um das Projekt voranzubringen - die nächste am 8. Oktober. Wenn Sie dabei sein wollen, antworten Sie einfach formlos auf diese Mail.

Stay secure!
Sarah Fluchs