Schwupps, da sind wir schon im zweiten Halbjahr 2021... Es gibt viel zu besprechen aus dem vergangenen Monat, selbst, wenn wir die Performance der Fußball-Nationalmannschaft und der deutschen Tour-de-France-Fahrer außen vor lassen. Willkommen also zu einem im garantiert sportfreien Hard-Hats-Briefing!

Statt um Sport geht es um Security für Steuerungen, den Wassersektor, die Russen, die ISA/IEC 62443, ein neues MITRE-Framework und die Störfallverordnung - und in der Nachspielzeit zwei frei verfügbare Security-Engineering-Crashkurse - volle Ladung OT-Security, könnte man also sagen.

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

1. Top 20 Secure PLC Coding Practices sind veröffentlicht
2. Schwachstellen und Bugs in Siemens-SPSen
3. Security im Wassersektor - Panikmache oder echte Probleme?
4. Die Russen und die Ransomware
5. Neues ISA GCA Whitepaper erklärt ISA-62443-3-2 (Risikomanagement)
6. Gegenstück zu MITRE ATT&CK: MITRE D3FEND
7. LANUV-Orientierungspapier zur Darstellung der IT-Sicherheit im Sicherheitsbericht
8. Zweimal Security-Engineering-Crashkurs: Science Slam und Vortrag beim KDW

1. Top 20 Secure PLC Coding Practices sind veröffentlicht

Lange haben wir daran gearbeitet, oft haben wir es angekündigt, nun ist das Dokument endlich da: Die Top 20 Secure PLC Coding Practices - Programmierprinzipien speziell für speicherprogrammierbare Steuerungen (SPS).

Seit "die Top 20" am 15. Juni veröffentlicht wurden, ist dazu einiges geschrieben und gesagt worden. Hier dazu eine kleine Linksammlung - und ansonsten darf das Dokument auch gern erst einmal für sich stehen (Lesestoff 1).

1. Eine deutschsprachige Erklärung des Dokuments (Struktur, Zielgruppe, Hintergründe, weitere Pläne) finden Sie in meinem Blog (Lesestoff 2).
2. Wer lieber sieht und hört als liest, kann auch Dale Peterson's Unsolicited Response Show mit Vivek Ponnada und mir hier ansehen.
3. Kelly Jackson Higgins von Dark Reading hat ein paar weitere Stimmen zur Bedeutung des Projekts gesammelt.
4. Der Klassiker, mit dem alles begann: Jake Brodsky's Video von der S4 2020.
5. Eine fortlaufende Sammlung aller Ressourcen zum Thema finden Sie auf der Projektwebsite.

Das Wichtigste ist nun, dass das Dokument seine Leser - idealerweise Ingenieure, die tatsächlich SPSen programmieren - erreicht. Wenn Ihnen jemand einfällt, der oder die das Dokument kennen sollte: Teilen Sie es! Wir haben es unter eine Lizenz gestellt, die freies Teilen und Verwenden problemlos ermöglicht.

Das Zweitwichtigste ist, dass sich das Dokument kontinuierlich weiterentwickelt. Eine Practice macht für Sie keinen Sinn? Das mit der Guidance können Sie besser? Und die allerwichtigste Practice fehlt aus Ihrer Sicht noch? Lassen Sie es uns wissen - auf der Projektwebsite gibt's ein Kommentarformular, dass Kommentieren so unkompliziert wie möglich machen soll.

Oder wirken Sie gleich im Kernteam der Top 20 mit, das die inhaltlichen Kommentare, aber auch die weitere strategische Ausrichtung des Projektes besprechen wird - eine formlose Mail an plc-security@admeritia.de reicht, um Sie an Bord zu bringen.

2. Schwachstellen und Bugs in Siemens-SPSen

Es gibt zwar schon genug SPS-Schwachstellen, aber die größeren neuen werden praktischerweise immer dann gefunden, wenn Meilensteine im Top 20 Secure Coding Practices Project verkündet werden.
Bevor Sie die Verschwörungstheorien auspacken: Nein, wir stecken nicht dahinter.

Ende Mai, also etwa zwei Wochen vor der Veröffentlichung der Top 20, hat die OT-Security-Firma Claroty eine neue Schwachstelle in Siemens-SPSen (genauer: SIMATIC S7-1200 und SIMATIC S7-1500) bekannt gegeben. Claroty hat im Vorfeld der Bekanntgabe eng mit Siemens zusammengearbeitet ("coordinated disclosure"), sodass mit Verkündung der Schwachstelle auch ein Patch des Herstellers bereitsteht, das "schnellstmöglich" installiert werden sollte - siehe Security-Advisory von Siemens im Lesestoff 1.
Die Schwachstelle trägt die CVE-Nummer CVE-2020-15782. Auch wenn die Schwachstelle schwerwiegend ist, sind bislang keine Fälle bekannt, in denen sie ausgenutzt wurden. Wir können also hoffen, dass die Schwachstelle tatsächlich zuerst von "den Guten" (in diesem Fall Claroty) gefunden wurde.

Klingt wie "so weit, so gut" - nur: Wie steht es denn bei Ihnen so um den Patchprozess für Steuerungen?
Häufig werden diese nämlich komplett aus dem Patching ausgeschlossen oder müssen aufwendig per Hand gepatcht werden, was bei einer nicht unüblichen locker dreistelligen Zahl verbauter Steuerungen, die alle rund um die Uhr laufen, keine einfache Aufgabe ist.

Die Schwachstelle, obwohl beileibe nicht die erste SPS-Schwachstelle, ist bemerkenswert. Das Schädlichste, was man mit einer SPS anstellen kann, ist bekanntlich, ihr eine "feindliche" Steuerungslogik unterzujubeln, die sie dann ausführt, ohne Alarm zu schlagen (in Security-Sprech "native code execution"). Meist brauchte man dafür bislang physischen Zugang zur SPS, oder man nutzte den designierten Weg zum Programmieren einer SPS, nämlich ein Programmiergeräte bzw. eine Engineering Workstation - dies war etwa bei Stuxnet der Fall.
Die nun veröffentlichte Schwachstelle braucht diesen Umweg nicht. Sie umgeht die "Sandbox", also die geschützte Umgebung, in der neu implementierte Logik normalerweise ausgeführt wird, und schreibt stattdessen direkt in geschützte Bereiche des Arbeitsspeichers der SPS. Der Vorteil gegenüber dem physischen Zugang oder dem über das Programmiergerät: Der Angreifer muss nicht vor Ort sein, und er muss sich nicht als Nutzer authentifizieren. Technische Details erklärt Claroty im Blog (Lesestoff 2).

Notiz am Rande: Mit weniger Pressewirbel, aber mindestens genauso vielen technischen Details hat der auf SPSen spezialisierte Security-Researcher Gao Jian bei einer Amsterdamer Konferenz auf weitere Möglichkeiten aufmerksam gemacht, Schutzmechanismen in Siemens S7 SPSen auszuhebeln (siehe Lesestoff 3).

3. Security im Wassersektor - Panikmache oder echte Probleme?

Sie erinnern sich bestimmt noch an den Oldsmar-Vorfall - im US-Bundesstaat Florida war es einem Hacker gelungen, Chemikaliendosierungen im Prozessleitsystem eines Trinkwasserversorgers zu verändern, mit denen das Trinkwasser ungenießbar geworden wäre (siehe HardHats-Briefing im März).

Nun, zu Oldsmar gab es offenbar "Vorwehen" - genauer gesagt einen weniger bekannt gewordenen Vorfall ein paar Wochen zuvor in der Nähe von San Francisco, ebenfalls USA (NBC News-Artikel hierzu im Lesestoff 1).
Auch in diesem Fall wurde angeblich (siehe unten) das Vergiften eines Trinkwasserversorgers versucht.
Der Weg? Ein Klassiker, könnte man sagen: TeamViewer-Account eines nicht mehr beschäftigten Mitarbeiters. Er hat sich allerdings im Vergleich zum Oldsmar-Hacker wie ein Elefant im Porzellanladen verhalten, nämlich nicht Sollwerte verändert, sondern einfach "Programme deinstalliert, die für die Wasserbehandlung notwendig waren".
(Ob mit den "Programmen" ganze Applikationen oder Steuerungslogik gemeint war, wird nicht weiter spezifiziert).

Das "und dann?" wiederum ist ähnlich wie in Oldsmar: Die Veränderungen wurden schnell bemerkt und rückgängig gemacht, das Trinkwasser war zu keiner Zeit beeinträchtigt.

Wie bewertet man also die Berichte über solche Vorfälle? Panikmache oder Hinweis auf echte Probleme?

Wie immer hat die Medaille zwei Seiten.

Zuerst zur Panikmache-Seite:

• Panikmache 1: Der Wassersektor hat noch nie von Security gehört.
  Ich wiederhole gern meine Bemerkung aus dem März: Diese Szenarien (Nutzung eines Remote-Zugriffs, Veränderung von Sollwerten oder Steuerungslogiken) hat jeder Wasserwerker auf dem Schirm, der sich auch nur halbwegs mit Security auseinandersetzt - und meist ist die Einschätzung: "Das würden wir ratzfatz merken, bevor irgendwas wirklich Schlimmes passiert". Wie wir sehen: Äußerst korrekte Einschätzung.
• Panikmache 2: Jemand hätte fast das Trinkwasser vergiftet!
  Man kann an der Berichterstattung über den San-Francisco-Vorfall auch durchaus kritisieren, dass zwischen "ich lösche alle Programme" und "ich vergifte das Trinkwasser" noch einige Lichtjahre Interpretationsspielraum sind. Selbst wenn der Hacker sich etwas weniger wie ein Elefant im Porzellanladen bewegt hätte, ist es ja auch nicht so, als würde Trinkwasser in Sekundenschnelle vom Wasserwerk zum Endverbraucher gelangen. Dazwischen liegen Stunden, manchmal Tage, und viele biochemische Kontrollen.

Nun zur besorgniserregenden Seite:

• Sorge 1: Leichtfertiger Umgang mit Fernzugriffslösungen.
  Auch wenn die beiden Hacker, weder in Florida noch in Kalifornien, wirklich dramatische Auswirkungen hervorrufen konnten: Nicht mehr genutzte TeamViewer-Accounts, die einem Angreifer alle Möglichkeiten zur Interaktion mit einem Leitsystem geben, sind trotzdem ein Spiel mit dem Feuer. In den Händen eines Hackers, der weiß, was er tut, wären schwerere Auswirkungen natürlich denkbar, und wir müssen vielleicht nicht unbedingt warten, bis wir auf all diese schlummernden Zeitbomben von mäßig fähigen Hackern mit der Nase gestoßen werden...
  Oder, in den Worten von Jake Brodsky in seinem etwas emotionalen Blogpost zum Thema Fernzugriffe:"I know, the glossy magazines say you should have remote access because it saves money. Yeah, Right. Show me the business case. Unless managing the plant without remote access is impossible, this is bad advice. Typically this advice comes from people with very little time under a hard-hat. They came from the world of consultants and their ideas are what I like to call Corporate Pornography." 
• Sorge 2: Der eine Ingenieur, der "das bisschen IT nebenbei mitmacht"
  Der Punkt führt uns weg von Schlaglichtern wie den Vorfällen wie denen in Kalifornien und Florida und hin zu einem strukturellen Problem, und das wird unter anderem in einem Report, ersichtlich, den eine Gruppe von Organisationen, unter anderem das US-amerikanische Water ISAC, im Juni veröffentlicht hat. (ISAC steht für Information Sharing and Analysis Center, ein in den USA häufig gebrauchter Terminus für Organisationen, die Security- und vor allem Bedrohungsinformationen für eine bestimmte Branche sammeln und teilen.)
  In dem Bericht (siehe Lesestoff 2) geht es um den Security-Status in der US-amerikanischen Wasserindustrie. Nicht alle Ergebnisse sind auf Deutschland übertragbar, aber eines ist sehr ähnlich: Wasserversorgung ist meist kommunal organisiert, und die meisten Wasserver- und -entsorger bedienen weniger als 250.000  Einwohner. Zur Erinnerung: Der Schwellwert für die KRITIS-Regulierung in Deutschland sind 500.000 versorgte Einwohner. All die kleinen, kommunalen Organisation der Wasserbranche unter diesem Schwellwert haben keine gesetzliche Pflicht, aber meist erst recht keine Ressourcen, um sich um Security zu kümmern.
  Schon bei den "mittelgroßen" ist der Zuständige für die IT (nicht: IT-Security) die eine Person, die sich hobbymäßig sowieso mit Netzwerken befasst und bei der Rollenvergabe nicht bei drei auf dem Baum war (true story aus dem Beraterleben). Und diese Geschichte soll nicht zeigen, dass Wasserversorger alle provinziell und inkompetent besetzt sind, sondern, wie unwichtig IT (nicht: IT-Security)-Kompetenz in ihrem täglichen Betrieb war und meist noch ist. Das macht es nicht leichter, wenn man sich plötzlich mit IT-Security (nicht: "nur IT") befassen muss.

Die Debatte hat aufgrund der beiden Vorfälle und des veröffentlichten Water ISAC-Reports in den USA im Juni einige Wellen geschlagen. Einen lesenswerten Artikel des Security-Journalisten Brian Krebs finden Sie hier, einen ebenso lesenswerten Twitter-Thread aus dem Wassersektor (von @h2onolan) hier.

Erinnerung: Ende April gab es auch eine Studie zum deutschen Wassersektor. Auch wenn Security dort nur am Rande ein Thema ist - interessante Vergleiche zum US-amerikanischen Bericht lassen sich trotzdem ziehen. Link im Lesestoff 3.

4. Die Russen und die Ransomware

Es gibt ja zwei Dauerbrenner in der Security momentan.
Erstens: Ransomware. Zweitens: Die Russen waren's.

Im letzten Monat gab es einige lesenswerte Hintergrundartikel zur Kombination aus beidem:

• Lesestoff 1: NBC News beschreibt das Problem, dass Ransomware-Gruppen in Russland quasi unter staatlichem Schutz (wenn nicht im Auftrag staatlicher Geheimdienste) agieren.
• Lesestoff 2: Kim Zetter analysiert, wann es Sinn ergibt, Lösegeld zu zahlen - und wann eher nicht. Dafür hat sie den CEO einer Firma interviewt, die Lösegeldverhandlungen für Unternehmen übernimmt. Nicht immer geht es dabei um eine tatsächliche Verhandlung der Summe - manchmal kann man auf diesem Weg auch einfach Zeit gewinnen, um herauszufinden, ob die Backups funktionieren.
  Der Text ist gespickt mit Informationen, denen man die "Zeit an der Front" des Interviewpartners anmerkt, und die gerade deswegen so wertvoll sind.
  Zum Beispie.: Die Antworten des CEOs auf die Frage, auf wie viele kleine Arten man ein Backup "falsch" konfigurieren kann:
  - Die Backups liegen in einem Außenstandort, der nur mit Kupferkabeln angebunden ist, sodass das Wiederherstellen ewig dauert.
  - Die Backups funktionieren, aber die Applikation, die für die Wiederherstellung nötig ist, ist verschlüsselt.
  (Interessante Seiteninfo übrigens: Die Colonial Pipeline, die letzten Monat Schlagzeilen gemacht hat, weil sie das Lösegeld an ihre Erpresser schnell gezahlt hat, war für solch einen Fall versichert).
• Lesestoff 3: Brian Krebs erzählt, warum das Installieren einer kyrillischen Tastatur Schadcode-Schutz sein kann: Russiche Hacker vermeiden so, dass freidrehende Computerwürmer die eignene Leute infizieren.
  Dabei darf natürlich nicht der Disclaimer fehlen: Nein, Sie können ihr Antivirenprogramm nicht ad acta legen und stattdessen eine kyrillische Tastatur installieren. Das wäre ja auch zu schön gewesen.

5. Neues Whitepaper erklärt ISA-62443-3-2 (Risikomanagement)

Zum Ende des Juli-Briefings kommen nun noch ein paar Lesehinweise und anstehende Termine in schnellerer Folge.

Es geht los mit einem neuen Whitepaper der Global Cybersecurity Alliance der Industrial Society of Automation (ISA GCA). Die ISA ist das Zuhause der weltweit wichtigsten Automation-Security-Standardreihe, der ISA/IEC 62443, und die ISA GCA trägt ihren Teil zur Erklärung der etwas sperrigen Standardreihe bei.

Dieses Mal geht es auf 16 Seiten um die ISA-62443-3-2, der jüngst aktualisierte Standard zum Risikomanagement. Das Whitepaper gibt eine gute Einführung und Hinweise zur Anwendung des Standards - und es bietet eine kostenlose Möglichkeit, in den Standard hineinzuschnuppern, wenn man überlegt, ihn zu beschaffen. Link zum Whitepaper im Lesestoff.

6. Gegenstück zu MITRE ATT&CK: MITRE D3FEND

MITRE ATT&CK hat ja gerade einen Lauf - das Framework, das beobachtete Angriffsvektoren für verschiedene IT-Umgebungen beschreibt und kategorisiert, ist in aller Munde. Häufige Kritik: Nur weil ich weiß, was es für Angriffe gibt, weiß ich noch nicht, was ich nun dagegen tun soll.

Naheliegend war damit der nun neu erschienene Gegenpart zu MITRE ATT&CK.

Getreu der MITRE-Eigenart ist mindestens ein Buchstabe durch irgendetwas getauscht, das alle Welt den Eigennamen kreativ falsch schreiben lässt (ATT8CK? ATTACK? &TTACK?).
Also, üben wir schon einmal gemeinsam das Buchstabieren des neusten Familienmitglieds: MITRE D3FEND.

Die Idee hinter D3FEND ist, Verteidigungsstrategien für die Angriffe im ATT&CK-Framework zu liefern. Die Kategorien sind "Harden", "Detect", "Isolate", "Deceive", "Evict". Das erinnert an's NIST-Framework - mit dem großen Unterschied, dass MITRE wirklich nur technische Maßnahmen beinhaltet, und diese auch sehr konkret.

Ich lehne mich mal mit einer Prophezeiung aus dem Fenster:
D3FEND wird eher der unbekannte kleine Bruder von ATT&CK bleiben und weniger ein gleichwertiger Partner.

Grund 1: ATT&CK ist so populär aufgrund seiner Einzigartigkeit. Es hat erstmals Threat Intelligence als Communityprojekt übersichtlich strukturiert. Aber Frameworks für Maßnahmen? Genau, davon gibt es schon eine Million. Nun eben eine Million +1.

Grund 2: Eines der 10 Gebote der Security-Branche: Angriff ist sexier als Verteidigung. Red Team ist sexier als Blue Team. ATT&CK ist sexier als D3FEND.

Aber machen Sie sich selbst ein Bild. Den Link zum D3FEND-Framework finden Sie im Lesestoff 1, das Whitepaper von MITRE dazu in Lesestoff 2.

7. LANUV-Orientierungspapier zur Darstellung der IT-Sicherheit im Sicherheitsbericht

Wenn Sie unter die Störfallverordnung fallen, haben Sie es wahrscheinlich mitbekommen: Das LANUV hat im Frühjahr ein Orientierungspapier zur Darstellung der IT-Sicherheit im Sicherheitsbericht veröffentlicht.

Das Papier wird viel diskutiert, deswegen wird es dazu von mir im Juli auch einen Blogbeitrag geben. Bis dahin können Sie schon einmal das Papier herunterladen - siehe Lesestoff-Link.

8. Zweimal Security-Engineering-Crashkurs: Science Slam und Vortrag beim KDW

Zum Abschluss noch zwei Chancen, wie Sie mehr über Security Engineering lernen können. Die erste ist minimalinvasiv (Sie brauchen nur 10 Minuten) und unterhaltsam, die zweite etwas tiefer und mit Raum für Diskussionen:

1. Am 29.06. habe ich den Science Slam beim 22. Leitkongress für Mess- und Automatisierungstechnik (AUTOMATION) gewonnen.
   Was ist ein Science Slam? Vielleicht haben Sie schon einmal von einem Poetry Slam gehört - ein Science Slam ist so ähnlich, nur für Wissenschaft: Es ist ein Wettbewerb, bei dem die Slammer das eigene Forschungsgebiets in 10 Minuten möglichst unterhaltsam erklären.
   Bei mir ist das natürlich unser Forschungsprojekt IDEAS - in meinen 10 Minuten "Security muss Zeichnen lernen" erfahren Sie, wie Sie die Security-Spielverderber mit ihren penetranten Fragen ("haben Sie schon an die Security gedacht?!") mit einem Blatt Papier ruhig stellen können.
   Wir hatten es etwas schwer, da unser Veranstaltungsbeginn mit dem Anstoß des deutschen Achtelfinales der Fußball-EM zusammenfiel... aber das Video können Sie nun entspannt ohne Fußball noch nachschauen, siehe Video-Link unten.
2. Am 22.07. werde ich in einer After-Work-Veranstaltung des Kompetenzzentrums Deutsche Wasserwirtschaft (KDW) erklären, was Security Engineering ist, warum sich das oft so hemdsärmelig anfühlt und was wir dagegen tun können. Konkreter: Warum Security Engineering die Ergebnisse des Projekts IDEAS braucht - ordentliche Zeichnungen und Datenmodelle sowie ein eigenes Werkzeug - und warum Security dadurch für Schutzhelmträger, die nebenbei auch Security machen müssen, endlich greifbarer wird.
   Möglichkeit für Fragen und DIskussion inklusive.
   (Für die volle Transparenz: Ich bin Mitglied des Beirats des KDW.)
   Mit der Veranstaltung machen Sie nichts falsch: Sie ist kostenlos, öffentlich und online - den Anmelde-Link finden Sie unten.

Stay secure!
Sarah Fluchs