Ganz schön angriffslastig war dieser April 2024! Natürlich schauen wir uns die xz-Hintertür an, aber auch Wirtschaftsspionage aus China, Angriffe auf die Wasserversorgung aus Russland und Angriffe aus Schleusen aus wo-auch-immer.
Dazu gibt es drei neue Cybersecurity-Dokumente, die sich für Schutzhelmfans lohnen anzuschauen - und den Abschluss machen eine sehr traurige und zwei frohe Botschaften.

1. Beinahe ein Generalschlüssel fürs Internet: Hintertür in xz utils
2. Hacker aus China haben vor 10 Jahren Informationen über Getriebetechnik von VW gestohlen
3. Angriffe auf Wasserversorger in den USA und Polen: Ist Sanworm aktiver, als wir mitbekommen?
4. Noch ein Hafen-Angriffsszenario: Schleusen schließen
5. ISA/IEC 62443-6-1: Erster Standard zu 62443-Prüfmethoden veröffentlicht
6. Top 20 Secure PLC Coding Practices auf Deutsch
7. Solide Einsteigerlektüre: ICS Security-Kompendium des BSI aktualisiert
8. Ross Anderson ist gestorben
9. Security unter Kontrolle 2024: Programm steht
10. Juni-Veranstaltungshinweise: DSLAM, ISA OT Cybersecurity Summit
11. Danke für 4 Jahre!

1. Beinahe ein Generalschlüssel fürs Internet: Hintertür in xz utils

Wie jeden Monat gab es auch im April ein Thema, um das man nicht herumkam. Dieses Mal war es immerhin keine Katastrophe, sondern nur eine Beinahe-Katastrophe: Eine raffiniert versteckte Hintertür in einer sehr weit verbreiteten Open-Source-Softwaresammlung (xz utils) wurde kurz vor ihrem Rollout noch gefunden.

Für den Fall, dass Sie "xz-Backdoor" zwar mittlerweile hundert Mal gelesen haben, aber immer noch nicht so genau wissen, was eigentlich dahinter steckt, hier die Fakten:

Was ist das für eine Hintertür und warum regen sich alle so auf?

• xz utils ist eine Sammlung von Unix-Softwareprogrammen, die Dateien komprimieren können. Die Sammlung ist auf den meisten Linux-Distributionen standardmäßig installiert.
• xz utils wird unter anderem von SSH verwendet, einem sehr weit verbreiteten Linux-Dienst für den sicheren, authentifizierten Remote-Zugriff auf Server.
• Die Hintertür hätte es erlaubt, die Authentifizierung zu umgehen, die bei einem Remote-Zugriff mittels SSH notwendig ist. Auf den betroffenen Servern wäre also Vollzugriff aus der Ferne, inklusive Ausführen von beliebigen Befehlen oder Schadcode (Remote Code Execution) möglich gewesen. Das reicht locker für den maximalen CVSS-Score von 10, den die Schwachstelle CVE-2024-3094 daher auch bekommen hat.
• Damit wäre unautorisierter Remote-Zugriff auf alle im öffentlichen Internet mittels SSH erreichbaren Linux-Server möglich gewesen - eine Art "Generalschlüssel für das Internet", wie es Volker Zota und Malte Kirchner in der heiseshow ausdrücken. Übertrieben ist das nicht, denn gemäß Shodan gibt es etwa 20 Millionen SSH-Zugänge weltweit, 2 Millionen alleine in Deutschland.

Und warum nur Beinahe-Katastrophe?

• Verschiedene Linux-Distributionen laden aktualisieren Software unterschiedlich schnell herunter, je nach Interesse des Nutzerkreises. Wer unbedingt die neuesten Updates  schnellstmöglich (als "rolling releases") haben möchte (in der Regel brauchen das nur Entwickler der Linux-Betriebssysteme), kann bestimmte Entwicklerversionen ("unstable" Versionen) wählen - da sind die Updates aber manchmal noch nicht ausgereift. Auch die auf Pentests ausgelegte Distribution Kali Linux bekommt die "rolling releases".
• Für die meisten Anwendungen werden "stable" Versionen verwendet; hier wird neue Software erst nach ausgiebigeren Tests installiert und mehr Augenmerk darauf gelegt, dass Software-Updates die Systemstabilität nicht beeinträchtigen.
• Die Version von xz utils, in der die Hintertür enthalten war, war bislang nur in einigen "unstable"-Linux-Distributionen enthalten. Aaaaber: Sie war kurz davor (genauer: 2 Wochen), auch in die weit verbreiteten stable-Versionen ausgerollt zu werden.
• Andres Freund, ein deutscher Software-Entwickler bei Microsoft in San Francisco, hat die Hintertür bei Wartungsarbeiten entdeckt. Fehlgeschlagene SSH-Logins beanspruchten plötzlich viel mehr Rechenleistung als vorher - das kam ihm seltsam vor. Am 29. März hat er seinen Fund öffentlich gemacht - nachdem er ihn im Rahmen einer "coordinated disclosure" an die Entwickler der Linux-Distributionen Debian, Red Hat gemeldet hatte.

Wie konnte die Hintertür eingeschleust werden?

• Die Softwaresammlung xz utils wurde - wie so viele Open-Source-Projekte, auf denen das gesamte Internet aufbaut - seit Jahren von einem einzelnen Entwickler als Hobby programmiert und aktualisiert.
• Diese Einzelperson litt schon einige Jahre unter Burnout und psychischen Problemen, weshalb er die Hilfe eines Unbekannten oder einer Gruppe von Unbekannten, "Jia Tan", annahm. "Jia Tan" übernahm immer mehr Aufgaben im Projekt - und programmierte schließlich die Hintertür ein.
• Die Hintertür selbst ist sehr raffiniert eingebaut. Man kann sie nicht im Quellcode finden, sondern nur in der kompilierten, ausführbaren Version der Software.
• Außerdem ist es eine sogenannte NOBUS (nobody but us)-Hintertür. Nicht jeder kann sie nutzen, sondern man braucht einen geheimen Schlüssel dafür. Deswegen vermuten viele einen Geheimdienst hinter dem Angriff.

Was muss ich tun?

• Ihre Linux-Server sind mit großer Wahrscheinlichkeit nicht betroffen, es sei denn, Sie haben eine der Entwicklerversionen installiert (Liste hier) und zwischen dem 26.03. und 28.03. ein Update gemacht. Prüfen kann man die Betroffenheit für konkrete Server mit diesem Tool.

Jetzt zur großen Frage: Was lernen wir daraus?
Wie konnte diese Beinahe-Katastrophe passieren und wie könnte man sie verhindern?

Die Aufregung über die xz-utils-Hintertür ist nicht nur deswegen groß, weil die Schwachstelle so weitreichend gewesen wäre - sondern auch, weil so etwas im Software-Ökosystem, das wir nun mal haben, jederzeit wieder passieren könnte: Niemand hat ein Patentrezept, um solche Katastrophen zukünftig zu verhindern.

Das Grundproblem ist, dass jede Infrastruktur, die Software und Internettechnologien nutzt (also eigentlich jede)

Das Grundproblem ist eigentlich gar kein Problem, sondern eine Vorteil von Software, nämlich ihre Skalierbarkeit: Einmal geschrieben, kann Software beliebig vervielfältigt werden, und damit kann sie eigentlich jeder nutzen. Toll, denn so kann man im Gegensatz zu oft sehr materialintensiven Ingenieurdisziplinen - nehmen wir mal den Bau eines Kraftwerks als Beispiel - mit fast keinem weiteren Materialeinsatz ein Produkt beliebig vervielfältigen.
Stellen Sie sich vor, wenn einer mal einen ordentlichen Kühlturm gebaut hätte, könnten alle anderen Kraftwerke ihn nutzen. Wie praktisch!

Und hier fangen die Probleme an. Schneiden wir sie in Problemscheiben:

1. Komplexität der Software-Lieferkette: Kein Software-Entwickler schreibt jede Zeile Code selbst. Es wäre ja auch haarsträubend ineffizient, wenn jeder das Rad neu erfinden würde. Viel effizienter ist ja, einfach existierende Software zu nutzen, die dieselbe Aufgabe löst. Also ist fast jedes Stück Software ein schier unüberschaubarer Haufen von Software-Stückchen aus verschiedenen Quellen, die alle von verschiedenen Menschen aktualisiert werden - denn Software ist ja nie fertig.
   
   Stellen Sie sich vor, Sie würden so Ihr Kraftwerk bauen. Was für ein Gewimmel von Ingenieuren am Kühlturm!
   
   
2. Große Macht und Verantwortung von Einzelpersonen: Wer schreibt eigentlich all diese Software-Stückchen? Gerade bei sehr grundlegender Linux-Betriebssystemsoftware oder Internetprotokollen ist die verwendete Software oft Open Source. Das heißt: Prinzipiell kann erst einmal jeder dazu beitragen. Und oft sind es gerade kleine, unscheinbar scheinende Hobbyprojekte von Einzelpersonen, die extrem viel genutzt werden. Klar - wieso sollte man so ein Detail wie ein Kompressionstool selbst schreiben, wenn es doch schon eins gibt? Das Phänomen ist so bekannt, dass es dazu einen xkcd-Comic mit Kultstatus gibt.
   Auf den Schultern dieser einzelnen, oft unbekannten Personen lastet oft eine große Verantwortung (und damit auch große Macht): Was sie in ihre Software einbauen, nutzen Millionen. Klar, es können auch Millionen daraufschauen, denn der Quellcode ist ja offen und kann von jedem getestet, geprüft und reviewt werden (das wichtigste Argument von Open-Source-Verfechtern). Aber am Ende ist das mehr Prinzip Hoffnung als ein gelenkter Prozess. Andres Freund, der Entdecker der xz-utils-Hintertür, sagt selbst, dass eine Menge Zufall zu seiner Entdeckung beigetragen hat.
   
   Also stellen Sie sich vor, Sie bauen Ihr Kraftwerk - und laden jeden ein, daran mitzubauen, der Lust hat. Sie hoffen einfach, dass alle Mitbauenden ordentliche Arbeit machen - und wenn nicht, dass es die anderen rechtzeitig merken. Nix Vieraugenprinzip.
   
   
3. Entwickler können die Einsatzszenarien ihrer Software nicht überblicken: Die umfassende und kostenlose Wiederverwendung von Softwarebibliotheken bedeutet auch, dass kein Programmierer vorhersehen kann, wofür seine Kreationen so eingesetzt werden. Was das bedeutet, versteht man, wenn man Dr. David Clark zuhört, der am MIT in den 70ern die Architektur für das hutige Internet mitgebaut hat. In einem 2011 aufgenommenen Video erzählt er: "Als die Leute gefragt haben, ob wir uns vorstellen konnten, dass das Internet mal Systeme auf der ganzen Welt verbinden würde, haben wir gesagt - klar! Es könnte Zehntausende Systeme im Internet geben! [...] Wenn Sie uns damals gefragt hätten, hätten wir wahrscheinlich gesagt, dass es eine ziemliche dumme Idee ist, Teile des Netzwerks für den Betrieb von kritischen militärische Operationen oder kritischer Infrastuktur wie dem Stromnetz an ein öffentliches Network zu hängen. Das tut man einfach nicht!"
   
   Übersetzt in unser Kraftwerksbeispiel hieße das: Sie lassen nicht nur jeden mitbauen - Sie erzählen den einzelnen Ingenieuren auch nicht, was sie da bauen. Die Ingenieure wählen Material für eine Wand aus, ohne zu wissen, ob sie einen Gartenpavillon oder einen Kühlturm bauen - und Sie selbst kümmern sich nicht darum, aus welchem Material ihr Kühlturm ist, solange er nicht zusammenbricht.

Das Problem ist also nicht Open-Source. Das Problem ist nicht, dass Software wiederverwendet wird. Das Problem ist nicht, dass Einzelpersonen Software entwickeln und sie kostenlos zur Verfügung stellen. Das Problem müsste noch nicht einmal sein, dass diese Software dann zum Beispiel für kritische Infrastrukturen genutzt wird. 

Das Problem beginnt, wenn niemand mehr die Verantwortung für die Software in kritischen Infrastrukturen übernehmen kann:

• Die Entwickler der Software nicht, weil sie oft sowieso nur ein Hobby betreiben und unmöglich alle Einsatzszenarien vorhersehen können - sie kennen sie ja oft noch nicht einmal.
• Die Betreiber der Infrastrukturen nicht, weil sie weder die Security dieser schieren Masse der genutzten Software kontrollieren können noch die Entwickler in die Pflicht nehmen: Wer Software kostenlos nutzt, kann eben nicht auch noch Ansprüche stellen.

Puh. Wenn das alles keiner verantworten kann - dann sollten wir es vielleicht so tatsächlich nicht machen?
Wenn wir so Kraftwerke oder auch nur Häuser bauen würden, wie wir IT-Systeme bauen....dann schliefen wir wohl alle lieber im Zelt.

Wer verantwortlich handeln will, kann eigentlich nur Software verwenden, deren Security er entweder selbst kontrollieren oder jemanden in die Pflicht nehmen kann. Und ja, das wird definitiv viel teurer als der bisherige Ansatz "kostenlose Software nutzen + Prinzip Hoffnung".

Der Cyber Resilience Act fordert übrigens genau das: Der Inverkehrbringer eines Produkts haftet für die Security - inklusive aller verwendeten Software-Bibliotheken. Die Praxis wird wohl erst auf längere Sicht zeigen, was das für Software-Sammlungen wie xz-utils bedeutet.

2. Hacker aus China haben vor 10 Jahren Informationen über Getriebetechnik von VW gestohlen

Wir in der OT-Security haben ja meist eher die Disruption von Prozessen und kritischen Dienstleistungen auf dem Schirm. Gern tun wir alles, was mit Vertraulichkeit zu tun hat, als zweitrangig ab.

Welches Ausmaß aber staatlich getriebene Wirtschaftsspionage annehmen kann, darein gibt es nun dank einer Recherche des Spiegels und des ZDFs Einblicke (siehe Lesestoff).

"Mehr als 40" (VW?-)interne Dokumente konnten die Spiegel- und ZDF-Reporter einsehen sowie Gespräche mit "einem Dutzend Personen" führen, die den Fall kennen. Der Fall, das ist eine Angriff mutmaßlich chinesischer Staatshacker auf den VW-Konzern zwischen 2010 (beginnend mit der Analyse der VW-IT, um Einfallstore zu finden) und 2015. VW hat den Vorfall auf Anfrage der Journalisten bestätigt.

Basierend von der Anzahl von Systemen, die neu aufgesetzt werden mussten, um dem Cyberangriff Herr zu werden, soll Microsoft während des Falls vom "weltweit größten Cyberangriff" gesprochen haben. Damit ist der Fall auch ein Beispiel für einen Cyberangriff, der nicht an die Öffentlichkeit kam - bis jetzt, neun Jahre später. Das vermittelt ein Gefühl für die berühmte Dunkelziffer von Cyberangriffen, über die Unternehmen nicht sprechen.

Wer die Angreifer wirklich waren, dafür fehlen wie fast immer endgültige Beweise. IP-Adressen sind aber nach Peking und in die Nähe des chinesischen Militärs zurückverfolgt worden. Außerdem deuten der verwendete Schadcode sowie die Zeitzonen, in denen Hacker und VW-Verteidiger agierten, auf China hin.

Zehntausende Dokumente sind im Zuge des Hackerangriffs abgeflossen und Verteidiger konnten rekonstruieren, welche: Es ging um Ottomotoren und vor allem Getriebetechnik. "das, was deutsche Autos ausmacht", zitiert Journalist Hakan Tanriverdi einen Experten.

China ist VWs wichtiger Absatzmarkt. Lange war VW der erfolgreichste Autohersteller in China. 2023 allerdings wurden erstmals mehr Autos des chinesischen Herstellers BYD als Volkswagen verkauft...

3. Angriffe auf Wasserversorger in den USA und Polen: Ist Sanworm aktiver, als wir mitbekommen?

Das Security-Unternehmen Mandiant, das mittlerweile zu Google gehört, hat Ende April mit einem 40-seitigen Bericht (Lesestoff) Aufsehen erregt. Der Bericht trägt den Titel "Unearthing Sandworm" ("den Sandwurm ausgraben").
Sandworm ist die bekannteste russische Hackergruppe, wird dem russischen Militärnachrichtendienst GRU zugerechnet und ist verantwortlich für alle großen Cybersecurity-Angriffe auf kritische Infrastrukturen der letzten Jahre, angefangen mit den Angriffen auf das ukrainische Stromnetz 2015.

In dem Bericht bereitet Mandiant vieles noch einmal struturiert auf, was schon bekannt war - die vergangenen Angriffe, üblicherweise verwendete Tools, die organisatorische Zuordnung zum GRU.
Aber der Anlass für den Bericht ist ein anderer: Mandiant warnt vor der Hackergruppe und benennt sie offiziell als "Advanced Persistent Threat" (APT44). Und zwar vor allem, weil Sandworm wohl viel aktiver ist, als in letzter Zeit öffentlich wahrgenommen wurde.

Sandworm ist in allen drei APT-Disziplinen - Spionage, Zerstörung und psychologische Einflussnahme - aktiv, führt der Bericht aus. Gerade die letzte Komponente, die psychologische Einflussnahme und Verunsicherung, spiele oft eine wichtige Rolle. Dafür pflege Sandworm mindestens drei Telegram-"Personas" - Kanäle, unter denen sie als "Hacktivisten" erfolgreiche (oder angeblich erfolgreiche) Angreife teilen und ihre Wirkung auch gern übertreiben.

Eine wichtige Botschaft aus dem Bericht:
Sandworm greift zwar hauptsächlich die Ukraine an, aber bei Weitem nicht ausschließlich. Spionageoperationen hat Mandiant auch in Nordamerika, Europa, dem Nahen Osten, Asien und Lateinamerika beobachtet, Manipulationen an Wahlsystemen in mehreren NATO-Mitgliedsstaaten, sowie Angriffe auf Journalisten und NGOs.

Ein interessantes Detail, das viele US-Medien aufgegriffen haben, ist in einem Infokasten auf Seite 13 versteckt: Über die Telegram-Kanäle hatte die Gruppe Anfang 2024 Videos gepostet ein Beispiel hier), die zeigen, wie sie ein HMI in polnischen und US-amerikanischen Wasserversorgungssystemen manipulieren und Wassertanks zum Überlaufen bringen. Solche Videos können natürlich gefälscht sein, aber der Mandiant-Bericht stellt zumindest mutmaßliche Verbindungen zu bestätigten Vorfällen bei einzelnen US-Wasserversorgern her.
Das ist, auch wenn der Schaden überschaubar ist und die Trinkwasserversorgung nicht beeinträchtigt war, eine Eskalation: Denn bislang hatte Sandworm oder eine anderer staatliche russische Hackergruppe keine bekannten, zerstörerischen Angriffe auf US-Boden verübt.

Der Bericht kommt zu einer Zeit, in der der öffentliche Konsens eher dahin schwenkte, den oft antizipierten "Cyber War" als weniger wahrscheinlich einzustufen. Für Zerstörung sind physische Angriffe einfach effizienter, und insgesamt gibt es als Teil des Ukraine-Kriegs und allgemein als Teil von Kriegen weniger Cyberangriffe als erwartet - zumindest nicht mit Auswirkungen auf kritische Infrastrukturen, sondern eher zur Verunsicherung und Desinformation.
Man kann den Bericht als weitere Bestätigung dieser These sehen - denn selbst bei den nun bekannt gewordenen Vorfällen ist, selbst wenn die Behauptungen der Telegram-Gruppen stimmmen, die Trinkwasserversorgung nicht beeinträchtigt worden, das Ganze war eher ein Muskelspiel der Cyber-Angreifer.
Man kann ihn auch als Warnung lesen, dass wir viele Cyber-Angriffe - oder deren Vorbereitungen - gar nicht mitbekommen.

4. Noch ein Hafen-Angriffsszenario: Schleusen schließen

Und noch ein Cybersecurity-Angriff, zu dem es nur Andeutungen gibt:
Der stellvertretende Generalsekretär für Innovation der NATO, James Appathurai, hat in einer Rede einen Angriff auf einen europäischen Hafen erwähnt, ohne den Hafen genauer zu benennen.

Da wir aber im letzten Hardhats-Briefing schon über Angriffsszenarien auf Häfen sinniert haben, ist das hier eine interessante Ergänzung:
"Die Cyber-Angreifer haben versucht, die Schleusen zu sperren. Wir haben also Schiffe, die durchfahren, und [die Angreifer] versuchen, sie zu sperren und das Wasser abzulassen, um das Schiff in der Schleuse abzusenken, was das Schiff beschädigen und den Hafen blockieren würde."

5. ISA/IEC 62443-6-1: Erster Standard zu 62443-Prüfmethoden veröffentlicht

Die IEC TS 62443-6-1 ist veröffentlicht; man kann Sie nun im IEC-Webstore kaufen (Lesestoff).

Moment, mal, -6-1 ?! Ja richtig, die ohnehin schon sehr umfangreiche Normenreihe 62443 hat eine neue Kategorie bekommen: -6-x. Unter dieser Nummer werden "Evaluation Methodologies" für andere Standardteile veröffentlicht - also Prüfmethoden, mit denen man den Erfüllungsgrad der Anforderungen in bestimmten 62443-Teilen evaluieren kann. Das ist wichtig für Zertifizierungen, und damit auch für Gesetze, die die Einhaltung bestimmter Anforderungen fordern - zum Beispiel der Cyber Resilience Act.

Die -6-1 definiert Prüfmethoden für die IEC 62443-2-4, die Security-Anforderungen für Dienstleister definiert. Analoge "Sechser-Standards", also Prüfmethoden für andere 62443-Teile, sind in Arbeit.

Übrigens ist das Dokument kein Standard, sondern "nur" eine TS (Technical Specification). Das bedeutet, dass es noch nicht alle Genehmigungsstufen durchlaufen hat, die ein Standard durchlaugen müsste. Das ist ein Indikator dafür, dass das Dokument Schwierigkeiten hatte, einen breiten Konsens zu erreichen, also noch umstritten ist - oder einfach noch nicht so reif.

6. Top 20 Secure PLC Coding Practices auf Deutsch

Fast drei Jahre ist es mittlerweile her, dass wir die Top 20 Secure PLC Coding Practices veröffentlicht haben. Secure Coding Practices gibt es für "normale" Software, aber nicht für SPS-Programme, hatte Jake Brodsky auf der S4x20 in Miami treffend bemerkt, und daraufhin haben wir (Dale Peterson, Jake Brodsky, Vivek Ponnada und ich) dann eine Gruppe ins Leben gerufen, die diese Lücke füllt.

Jede Menge Vorschläge, viele Seiten Text und noch mehr Kommentare von über 1.000 Freiwilligen später sind dann die Top 20 Secure PLC Coding Practices entstanden.

"Die Top 20", wie sie liebevoll genannt werden, waren von Tag 1 an ein Projekt von Ehrenamtlichen. Umso schöner, dass dieses Projekt auch drei Jahre später noch lebt. Wir bekommen regelmäßig Anfragen von Menschen, die die Idee der Top 20 verbreiten möchten (gern! wir haben Foliensätze dafür) oder Ideen haben, wie sie besser werden können und mithelfen können (supergern! wir brauchen jede helfende Hand!).

Und manchmal geschehen auch kleine Wunder. Zum Beispiel als Rudolf Preuss uns aus dem Blauen eine E-Mail schrieb, er habe die Top 20 auf Deutsch übersetzt, ob wir das vielleicht auf unsere Projektwebsite stellen wollten...?

Und wie wir wollten!

Also, die Top 20 Secure PLC Coding Practices gibt's jetzt auf Deutsch (übrigens als 5. Übersetzung neben Kroatisch, Spanisch, Arabisch und Chinesisch). Link im Lesestoff. Und hier geht's zur Projektwebsite, falls das Projekt insgesamt bislang an Ihnen vorbeigegangen ist.

(Ich weiß, das Ding auf dem Bild sieht einer SPS eher entfernt ähnlich... aber es war das realitätsnähste, was ich Midjourney entlocken konnte.)

7. Solide Einsteigerlektüre: ICS Security-Kompendium des BSI aktualisiert

Ohne viel Tamtam hat das BSI sein ICS-Security-Kompendium aktualisiert. Das Dokument, nicht zu verwechseln mit dem IT-Grundschutz-Kompendium, ist eine solide und ausführliche Einsteigerlektüre in das Thema OT-Security.

Die erste Ausgabe ist vor elf Jahren erschienen - da war viel Raum für ein Update. Und das Update ist gelungen. Es steht so viel Wissen darin, dass man sich vor Jahren noch mühsam aus verschiedenen Quellen zusammensuchen musste. Wie schön, dass es nun einmal als Grundlagenwissen an einer Stelle zusammengefasst ist.

Der wertvollste Teil für Einsteiger aus meiner Sicht ist das Kapitel 2 "Einführung in ICS" - denn im Gegensatz zu allen anderen Kapiteln findet man dieses Wissen wirklich nirgends sonst. Es gibt kein Buch, in dem man den Aufbau eines ICS in so komprimierter und security-relevanter Form nachlesen könnte.
Die Einführung in ICS ist nun auch technisch auf den neuesten Stand gebracht; inklusive Virtualisierung, Cloud und Service-orientierten Architekturen.

Im aktualisierten Kapitel 3 "Schwachstellen und Angriffe" nimmt die Lieferkette erwartungsgemäß einen prominenten Platz ein.
Auch die Standards in Kapitel 4 sind aktualisiert und ich vermisse uaf den ersten Blick nichts. Selbst die Standards an der Schnittstelle zur funktionalen Sicherheit sind sehr vollständig.
Die Liste der Good Practices in Kapitel 5 ist weder neu, noch falsch, noch ubedingt notwendig - ein Verweis auf einen der Standards hätte es wahrscheinlich auch getan - schadet aber auch nicht.

Etwas überraschend ist, dass eine Liste echter Angriffe auf OT-Systeme komplett fehlt. Dass ein ICS-Security-Kompendium komplett ohne das Wörtchen "Stuxnet" auskommt, ist mindestens mal überraschend. (Triton taucht kurz im Rahmen des Kapitels zu funktionaler Sicherheit vs Security auf).

Und weil wir gerade über die Top 20 Secure PLC Coding Practices sprachen: Die sind nun auch im ICS-Security-Kompendium verewigt. Das macht das Top20-Team und mich schon ein wenig stolz! Zu finden sind die Top 20 im Kapitel 6.1.4 Produktentwicklung.

Jedenfalls: Wenn Sie eine Kollegin haben, die sich in die OT-Security einarbeiten muss - legen Sie ihr dieses Dokument auf den Tisch. Link im Lesestoff.

8. Ross Anderson ist gestorben

Das war eine schockierende Nachricht für die Security-Welt:

Ross Anderson, der Autor des legendären Buchs "Security Engineering", ist plötzlich im Alter von 68 Jahren verstorben. Wer ein Gefühl für Anderson's Lebensleistung bekommen möchte, dem sei neben der Lektüre ebendieses Buchs (Lesestoff 1) der Nachruf seines Weggefährten Bruce Schneier empfohlen (Lesestoff 2).

Zwei Wochen vor seinem Tod hat Anderson außerdem in einem Interview ausführlich über sein Leben gesprochen.

9. Security unter Kontrolle 2024: Programm steht

Unser Programmbeirat hatte keinen leichten Job: Wir haben so viele Einreichungen bekommen, dass wir nur etwa 20 % davon annehmen konnten.

Wie auch letztes Jahr haben wir uns viel Mühe gegeben, das Programm dramaturgisch sinnvoll in Blöcke à zwei Vorträge zu gliedern. Es gibt ja nur eine Bühne, sodass man sich nicht zwischen parallelen Vorträgen entscheiden muss. Und tadaaaa - schauen Sie sich dieses Knallerprogramm an:

Keynote 1 zum Cyber Resilience Act (CRA) mit Benjamin Bögel, EU-Kommission.
Keynote 2: 🤐 😎
Block 1: Security-Vorfälle (Vorträge von Jan Hoff, Marcel Fischer)
Block 2: Maschinenlesbare Security-Advisories (Sören Finster, Klaus Biß)
Block 3: Das ist auch OT?! (Stephan Gerling, Vincent Rockenfeld)
Block 4: Security für Betreiber (Peter Breidbach, ein Panel mit fünf verschiedenen Betreibern)
Block 5: Security-Regulierungen (Manuel 'HonkHase' Atug, Christian Arlt)
Block 6: Sicherer Entwicklungsprozess (Jan Ciechanowicz, Rudolf Preuss)
Block 7: Security für neue Technologien (Prof. Karl-Heinz Niemann, Ragnar Schierholz)
...und ich selbst darf den Abschlussvortrag halten.

Die zweite Keynote wird noch eine - ziemlich coole! - Überraschung. Freue mich schon sehr, wenn sie in trockenen Tüchern ist und ich sie verraten darf.

Außerdem gibt es mehr Zeit für Pausen und informellen Austausch, weil sich unsere Teilnehmer das letztes Jahr gewünscht haben. (Das war eine Herausforderung, weil wir gleichzeitig auch möglichst viele der tollen Einreichungen im Programm unterbringen wollten.... deswegen ist der zweite Tag nun etwas länger als letztes Jahr).

Die Titel aller Vorträge gibts schon auf unserer Website (Lesestoff). Die genaue Zeitplanung wird noch ein bisschen hin und her geschoben, und Abstracts zu allen Vorträgen folgen in Kürze - wir sind dran.

Tickets kann man auch schon kaufen, und zwar hier (letztes Jahr waren wir ausverkauft!). Ich freue mich darauf, viele Hardhats-Leser persönlich in Düsseldorf zu treffen!

10. Juni-Veranstaltungshinweise: DSLAM, ISA OT Cybersecurity Summit

Langsam aber sicher beginnt auch der Veranstaltungsommer. Diese Woche spricht gefühlt die halbe Welt entweder über die RSA in San Francisco oder das OMR Festival in Hamburg.
Ich selbst bin weder bei RSA noch OMR, dafür aber im Juni auf zwei anderen Veranstaltungen:

DSLAM in Leipzig am 4. Juni: 
Eine kleines, feines, mit wahnsinnig viel Herzblut von Reinhold Nawroth ins Leben gerufene Security-Event "Digital Security Slam", das vieles anders machen möchte als die Security-Events, die man so kennt: Keine bezahlten Vorträge, Security-Schlangenöl und Schwachstellen-Kauderwelsch. Dafür gibt es kurze, unterhaltsame Slam-Beiträge zu einem breiten IT-Security-Themenfeld. Wem "Slam" nichts sagt: Das Konzept aus dem Format des Poetry Slams, bei dem selbtverfasste literarische Texte auf der Bühne in begrenzter Zeit (ca 10 Minuten) unterhaltsam vorgetragen werden. Eine Ableitung ist der Science Slam, bei dem Wissenschaftler ihre Forschung präsentieren.
Ich darf selbst einen Beitrag zum DSLAM beisteuern und habe selten so viel Motivation und Engagement erlebt wie in der Runde meiner Mit-Speaker - die 23 Slams werden bestimmt nicht langweilig.
Die Tickets sind erschwinglich, die Veranstaltung dauert nur einen Tag - bekommt man also gut auch spontan unter. Wenn Sie Security unter Kontrolle mögen, gefällt Ihnen vielleicht auch der DSLAM. Link zu Tickets und Agenda siehe unten.
ISA OT Cybersecurity Summit in London am 18. Juni:
Die International Society of Automation (ISA), bekannt als die Standardisierungsorganisation hinter der Standardreihe ISA/IEC 62443, veranstaltet vom 17.-21. Juni einen OT Cybersecurity Summit in London. Zwei Tage Konferenz und drumherum Workshops und Trainings - nicht nur, aber auch rund um die Standardreihe ISA/IEC 62443. Wer tiefer in den Standard einsteigen möchte, sowohl als Anwender als auch zum Mitgestalten, der findet da jede Menge Menschen zum Fragen.
Das Konferenzprogramm (18. und 19. Juni) rund um OT-Security ist aber auch unabhängig von der ISA/IEC 62443 sehenswert. Ich darf am ersten Kongresstag die Keynote beisteuern.
Man kann virtuell oder vor Ort teilnehmen. Taylor Swift ist offenbar gleichzeitig in London, bei Vor-Ort-Teilnahme ist eine baldige Buchung also sicher sinnvoll. Links zu Tickets und Agenda ebenfalls unten.

11. Danke für 4 Jahre!

Und dann wird das Schutzhelmbriefing diesen Monat noch vier Jahre alt! Im Mai 2020, mitten in der Pandemie, ging's los. Danke Ihnen fürs Mitlesen und Mitdenken, für Korrekturen und Kritik, für Antworten und Anstöße.

Die Geburtstags-Luftschlangen stehen unserem blauen Schutzhelm ganz hervorragend, oder?

Wenn Sie mir und meinem Helm ein Geburtstagsgeschenk machen möchten, empfehlen Sie das Briefing heute einer Person weiter - oder Sie drücken auf "Antworten" und schicken mir Feedback und Verbesserungsvorschläge für die nächsten vier Jahre.

Stay secure!
Sarah Fluchs