Der blaue Schutzhelm ist zurück aus der Winterpause!

 Die Automation Security hatte keine Winterpause, und deswegen haben wir einiges aufzuholen. Gänzlich untypisch für Secuirty habe ich heute allerdings nur gute Nachrichten im Gepäck - sogar die, die auf den ersten Blick schlecht aussehen (Ransomware für Steuerungen!), sind halb so wild.
So kann 2023 weiter gehen, finde ich. Packen wir's an.

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

1. ISA-TR84.00.09: Konkrete Anleitung zu Security und Safety
2. GhostSec: Erste Ransomware für Steuerungen?
3. Nicht das Denken auslagern!
4. Das Schwachstellen-Grundrauschen sortieren
5. Keynote für "Security unter Kontrolle": Cyberangriffe auf die europäische Industrie
6. S4x23 steht vor der Tür

1. ISA-TR84.00.09: Konkrete Anleitung zu Security und Safety

Der Technical Report mit dem etwas sperrigen Titel ISA-TR84.00.09 "Cyber Security Related to the Safety Lifecycle" war drei Jahre in Arbeit - nun ist die erste Fassung öffentlich und kann kommentiert werden.

Wer Standards ohnehin schon skeptisch gegenübersteht (weltfremd! abstrakt! kompliziert!), fühlt sich auf den ersten Blick wahrscheinlich bestätigt: Das Ding hat über 300 Seiten - und das ist nur Teil 1.

Ich möchte Sie ermutigen, dennoch einen Blick hineinzuwerfen, und das sage ich nicht nur, weil ich die Arbeitsgruppe geleitet habe, die das Risikoanalyse-Kapitel (und seine Anhänge) verfasst hat. Hier sind vier Gründe, warum sich der Blick in den Technical Report lohnt:

1. Pragmatischer Ansatz für Security for Safety: Texte zu "Security for Safety" - also Security für Anlagen, in denen auch funktionale Sicherheit eine Rolle spielt, bilden oft eines von zwei Extremen ab: die totale Trennung ("beides ist so verschieden, das hat nichts miteinander zu tun") oder die totale Vermengung ("die Safety kann die Security einfach mit machen").
   Der ISA-TR84.00.09 geht einen pragmatischen Mittelweg. Beide Lebenszyklen bleiben voneinander unabhängig - der Report gibt aber eine Anleitung dafür, wie man sie am effizientesten kombiniert. Welche Tätigkeit sollte vor oder nach welcher anderen erfolgen? Wo gibt es Synergieeffekte, wo Abhängigkeiten?
2. Methodenneutral: Der Report hat einen Haupttext und einen Anhang. Der Haupttext beschreibt, WAS zu tu ist - aber nicht WIE. Es gibt viele Wege nach Rom, und der Text ist generisch genug, um sie alle abzubilden. Er navigiert den Leser durch den Security- und Safety-Dschungel, ohne Details oder Methoden festzulegen.
3. Konkrete Beispielmethoden: Wer aber lieber konkretere Anleitung möchte, findet sie im Anhang. Dort finden sich z.B. für den Risikoanalyseteil 13 verschiedene Methoden, die man für die Risikoanalyse nutzen kann - inklusive ihrer Vor- und Nachteile, einer Beschreibung, und Verweisen auf weiterführende Informationen. Ich kenne keinen umfassenderen Überblick über OT-taugliche Risikoanalysen. Die Spannbreite reicht von einfachen Checklisten über INL's CCE-Methode bis hin zu quantitativen Verfahren. Jedes dieser Anhang-Kapitel wurde von Experten für die einzelnen Methoden geschrieben; teilweise haben sie sogar Ihre eigenen Vorlagen für bestimmte Methoden zur Verfügung gestellt.
4. International tragfähig und zukunftstauglich: Der Technical Report ist nicht einfach nur ein weiteres Papier zu Security und Safety. Er ist sorgfältig darauf ausgerichtet, mit den relevanten Standards und dem voherrschenden Konsens (in der Prozessindustrie) in Einklang zu sein. Der Security-Teil ist kompatibel zur IEC 62443. Der Safety-Teil ist kompatibel zur IEC 61511. Und Teile des Reports werden auch in die aktuelle Überarbeitung des IEC TR 63069 einfließen - dem IEC-Standard zu Security und Safety.

Der Entwurfstext ist öffenltich verfügbar - siehe Lesestoff. Dort kann auch bis 13. Februar direkt kommentiert werden.

2. GhostSec: Erste Ransomware für Steuerungen?

Dieses Thema könnte man auch überschreiben mit "gehen Sie weiter, es gibt hier nichts zu sehen".

Was ist passiert?

Die kriminelle Hackergruppe "GhostSec" hat stolz verkündet, dass sie erstmals eine SPS (genauer gesagt eine Remote Terminal Unit, RTU, aber dazu gleich) verschlüsseln konnte. Die Idee: Schaut her, jetzt geht auch Ransomware für Steuerungen.

GhostSecs Ankündigung war ziemlich großspurig. Es las sich so, als hätte die Gruppe gerade mindestens das Penicillin erfunden oder die ersten Schritte auf dem Mond getan ("YES! We just encrypted the first RTU in history!"). Dementsprechend gab es auch recht viel Wirbel um die Geschichte.

Wenn man aufräumt, bleibt aber von der Story nicht viel übrig:

• Keine Überraschung: Nehmen wir mal an, die Behauptungen stimmen, und GhostSec hat eine RTU verschlüsselt. Das ist eigentlich nichts besonders Überraschendes: Wir wissen, dass man mit einer Steuerung, sobald man Zugriff darauf hat, so ziemlich alles anstellen kann - eben auch verschlüsseln. Oder, wie Dale Peterson schreibt: "It's well known in the ICSsec world that on many PLCs or RTUs you can upload your own firmware or logic, as well as get root on the OS. Encryption is just a choice of what to do with this easily achieved access. The poc's on lateral movement in level 1 and physical damage are much more important and interesting."
• Keine große Auswirkung: Macht es überhaupt Sinn, eine Steuerung zu verschlüsseln? Üblicherweise tut man das ja, um Lösegeld zu erpressen. Das funktioniert aber nur, wenn die verschlüsselten Daten wichtig und unwiderbringlich sind. Es mag Steuerungen geben, auf die das zutrifft - aber für den größeren Teil ist es kein allzu großes Drama, die Steuerungslogik vom Engineering-PC oder sogar aus dem Leitsystem heraus neu aufzuspielen. Auch viele Integratoren haben Kopien der Logik für die SPSen, die sie verbaut haben.
• Keine Neuheit: Die ersten und einzigen, die auf die Idee kommen, Steuerungen zu veschlüsseln, sind GhostSec auch nicht - siehe zum Beispiel diesen Text von Red Balloon Security.
• Keine SPS: Und jetzt kommt's: Was GhostSec verschlüsselt hat, war noch nicht einmal eine RTU. Tatsächlich scheinen die selbst proklamierten Hacker auf kreatives Herstellermarketing hereingefallen zu sein, wie Ron Fabela in seiner Analyse bravourös herausgearbeitet hat (Lesestoff). Das arme angegriffene Gerät, eine TELEOFIS RTU986V2, ist nämlich ein schnöder 3G-Router. Darauf befindet sich keine Steuerungslogik, sondern ein stinknormales Linux-Betriebssystem. Dass man die Dinger verschlüsseln kann, ist wirklich keine Neugkeit.

Das erste Anzeichen dafür, dass mit der GhostSec-Geschichte etwas nicht stimmt, war wohl schon die Tatsache, dass die Hacker ihren Hack überhaupt vermarktet haben (und die sensationslüsterne Art und Weise). Hätte es sich wirklich um einen technisch spektakulären Hack gehandelt, wäre gar kein Marketing nötig gewesen...

Manchmal bin ich immer noch erstaunt über die schiere Arroganz, die viele selbsternannte Hacker an den Tag legen, insbesondere gegenüber Automatisierern. Sie scheinen den Eindruck zu haben, Automatisierungsingenieure seien Neandertaler, die weder von Security, noch überhaupt von Technik irgendeine Ahnung hätten.

Vielleicht ist es also einfach Karma, dass genau diese "Hacker" sich in diesem Fall unfreiwillig selbst als technikferne Neandertaler geoutet haben.

3. Nicht das Denken auslagern!

Sind Sie noch dabei, Ihre Security-Prioritäten für 2023 zu sortieren? Aus der unendlichen Weite des Internets habe ich Ihnen dazu heute einen kleinen Text mit schönen und ungewöhnlichen Denkanstößen gefischt - Robert Woods "Why, and When, to Say 'No' as a CISO" (siehe Lesestoff).

Der Text enthält einige Juwelchen, aber dieses hier möchte ich hervorheben: Bei aller Effizienz - passen Sie auf, nicht das Denken auszulagern!

"There is no shortage of firms willing to come in and build out wholesale strategic plans, design metrics, and develop reports along the way. In many cases, these kinds of offerings are built off of boilerplate re-usable material — these may be appropriate, but every leader should be intentional about whether or not this is actually what is needed. [...] Your team should remain in the driver’s seat, thinking critically and steering the security program.[...] Outsourced teams are there to support your vision, not set it and think for you."

4. Das Schwachstellen-Grundrauschen sortieren

Über konkrete Schwachstellen für Automatisierungssysteme schreibe ich hier recht selten. Das liegt nicht daran - dass es davon zu wenige gibt. Im Gegenteil. Es wäre ohne weiteres möglich, ein monatliches Briefing NUR mit neuen Schwachstellen zu füllen.
(Okay, es wäre theoretisch möglich. Praktisch würde ich vor lauter Gähnen wahrscheinlich nie fertig werden).

Jedenfalls freue ich mich sehr über alle Werkzeuge, die das Schwachstellen-Grundrauschen sortieren, und den Schwachstellen-Hype etwas nüchterner zu betrachten - und diesen Monat gibt es gleich zwei davon:

• Das ICS Advisory Project (Lesestoff 1) ist ein interaktives Dashboard, erstellt und gepflegt von Dan Ricci. Dan hat so ein Dashboard unter anderem schon für unser Top 20 Secure PLC Coding Project erstellt. Das ICS Advisory Project visualisiert die Daten aus dem ICS-CERT Advisories des US Department of Homeland Security (DHS), also wirklich ICS-spezifische Schwachstellen. Man kann die Datenbank nach verschiedenen Kriterien durchsuchen und aufbereiten lassen. Dabei findet man so spannende Tatsachen wie die, dass deutsche Hersteller auf Platz 1 der von Advisories betroffenen Herstellern stehen...
  Das Dashboard ist ein Work in Progress. Dan steckt einiges an Herzblut dort hinein und ist offen für Anregungen.
• ICS-Security-Firma SynSaber hat eine Analyse zu ICS-Schwachstellen in der zweiten Hälfte 2022 vorgelegt (Lesestoff 2) - basierend auf gemeldeten CVEs. Da SynSaber diese Reports regelmäßig erstellt, sind auch interessante Vergleiche zur vorherigen Periode enthalten - zum Beispiel diese Zahl: Für 35% der Schwachstellen im 2. Halbjahr 2022 gibt es kein Hersteller-Patch (im 1. Halbjahr waren es nur 13%).
  Die Analyse ist frei verfügbar, die Angabe von Kontaktdaten vor dem Download kann übersprungen werden.

5. Keynote für "Security unter Kontrolle": Cyberangriffe auf die europäische Industrie

Es ist Ihnen wahrscheinlich auch schon aufgefallen: Wenn ich für das Hardhats-Briefing nach verlässlichen Informationen über Security-Vorfälle suche, lande ich in der Regel bei englischsprachigen Beiträgen. Das gilt sogar, wenn es um einen Vorfall auf deutschem Boden geht.

 Das Problem dabei, außer möglichen Sprachbarrieren?
Ausländische Medien haben naturgemäß kein riesiges Interesse daran, zu Akteuren, Vorfällen und Vorgehensweisen im deutschsprachigen Raum zu recherchieren. Dementsprechend wenig Handfestes wissen wir über Cyberangriffe auf die deutsche Industrie. Gibt es solche Angriffe? Wenn ja, wer steckt dahinter?
Wie gehen die Unternehmen damit um, und wie die Ermittlungsbehörden?

Das führt zu einer verzerrten Wahrnehmung: Die großen OT-Security-Vorfälle passieren in den USA, Russland, China, Korea, Israel - aber doch nicht hier! Oder?

Klar ist: Die Beantwortung dieser Fragen ist wahnsinnig aufwendig. Man braucht dafür Journalisten, die sich darauf spezialisieren und sowohl die Zeit als auch das Verständnis haben, sich mit den technischen Details und Hintergründen auseinanderzusetzen. Ich mit meinem Hardhats-Briefing bin darauf angewiesen; wir alle sind darauf angewiesen, wenn wir unser Wissen über Security-Angriffe auf die europäische Industrie nicht nur auf Mutmaßungen und Platitüden ("Wir sind alle verwundbar" / "Russland wars") von eilig befragten "Security-Experten" stützen wollen.

Hakan Tanriverdi ist so ein Journalist, zuletzt beim Bayrischen Rundfunk, nun beim Investigativ-Kollektiv paper trail media. Wem paper trail media nichts sagt, der kennt wahrscheinlich trotzdem einige bekannte Veröffentlichungen des Teams, etwa die Steuerbetrugs-Recherche rund um die "Panama Papers".

Hakan ist einer der wenigen deutschsprachigen Journalisten, die sich an das komplexe, technische und darüber hinaus noch tabuisierte Thema der großen Cybersecurity-Vorfälle heranwagen. Einer der wenigen, die dabei mehr zutage fördern als in internationalen Medien, dpa-Meldungen und Pressemitteilungen der betroffenen Unternehmen ohnehin schon steht.

Zwei Beispiele für Hakans Arbeit habe ich Ihnen unten als Hörstoff verlinkt:

• Die schon etwas ältere Podcast-Serie "Der Mann in Merkels Rechner" erzählt technische Details und Hintergründe zum "Bundestags-Hack" 2015.
• Ein brandneues Radiofeature (Dezember 2022) zu gezielten Ransomware-Angriffen auf kritische Infrastrukturen.

Und jetzt kommt's: Hakan ist der Keynote-Speaker für die allererste Ausgabe unseres Kongresses "Security unter Kontrolle".
Ganz ehrlich: Ich freue mir ein Loch in den Bauch über Hakans Keynote und könnte mir keinen besseren Keynote-Speaker für unseren Kongress vorstellen - und das ging auch dem Rest unseres Programm-Beirats so. Im Lesestoff finden Sie den Link zum Kongressprogramm, nun inklusive Keynote.
Hakan bleibt übrigens während des ganzen Kongresses da für Gespräche (und Selfies ;) ).

6. S4x23 steht vor der Tür

Man lernt ja nie aus. Diesen Monat habe ich ein neues Wort gelernt, das ich mit Ihnen teilen möchte: Die OT-Security-Armutsgrenze. Unternehmen unter der Armutsgrenze haben nicht genug Mittel, um grundlegende Security-Bedarfe zu decken.

Die S4 ist die Konferenz zum Thema OT-Security, von der ich mit Abstand die meisten neuen Ideen und Denkanstöße mit nach Hause bringe - meist genug für das ganze Jahr. Dieses Jahr gibt es mit 1000 verkauften Tickets einen Besucherrekord.
Die Vorträge werden im Laufe des Jahres alle auf dem S4-YouTube-Kanal veröffentlicht - ein paar Miami-Vibes kann man also auch ohne Flug- und Konferenzticket mitnehmen.

Sollte jemand dort sein - hier sind meine Termine:

• Mein Vortrag "Security by Design Decisions" ist für den ersten Konferenztag (Valentinstag, 14. Februar) für 14 Uhr Ortszeit auf der "Main Stage" angesetzt. Ich hoffe, dass der Vortrag Ihre Prioritäten für ICS-Security in 2023 duruchwürfelt. Wir lassen da so viel Potential brach liegen! Mehr dazu im Februar.
• Außerdem habe ich mich überzeugen lassen, als Panelist beim "Women in ICS Security"-Event am Montagabend (13. Februar) dabei zu sein - trotz meiner Skepsis gegenüber "Women in something"-Veranstaltungen. Mehr dazu vielleicht irgendwann.

Stay secure!
Sarah Fluchs