Es wäre ja schön, wenn man seine Top-Themen mal selbst setzen könnte, aber seit einigen Monaten tun das meist große Technologieunternehmen und ihre neuesten Schwachstellen beziehungsweise Angreifergruppen und ihre neuesten Coups für uns: Im Januar Solarwinds, im März der Angriff auf die Trinkwasseranlage in Florida.
Diesen Monat: Hafnium natürlich, die Exchange-Schwachstelle. Wir schauen nur ganz kurz drauf und nutzen das Thema dann schamlos als Sprungbrett für weniger breitgetretene Folgethemen.

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

1. Hafnium: GAU für Mailserver
2. IPCEI-CIS: Eine europäische Cloud für die Industrie?
3. Deutsche Position zu Recht im Cyberspace
4. Wie viele Komponentenhersteller haben ein ISAsecure-Zertifikat?
5. Worauf achten bei OT-Asset-Management-Produkten?
6. Schwachstellen in SPSen von GE und Rockwell
7. Security for Safety für Ohren und Augen
8. Termine im April: EnergyShield-Workshop, Hannovermesse

1. Hafnium: GAU für Mailserver

Also, Hafnium. Was ist da eigentlich los? Fassen wir uns kurz*:

Was ist passiert?
Die Software in Microsofts populären Mailserver Exchange hat vier vorher nicht bekannte Schwachstellen ("zero-day exploits"). Da Microsoft Patches bis Microsoft Server 2010 bereitgestellt hat, bestehen die Schwachstellen in der Software offenbar seit mindestens zehn Jahren. Die Schwachstellen (Link zu den CVEs: No1, No2, No3, No4) ermöglichen es, Befehle auf dem Exchange-Server auszuführen, Dateien abzulegen, oder Quellcode auszuführen, also in kurz: Alles, was das Herz begehrt.

Das Ganze ist nur aufgeflogen, weil Angriffe zur Ausnutzung dieser Schwachstellen durch eine Security-Firma DEVCORE beobachtet wurden, die Microsoft am 5. Januar über ihre Beobachtungen unterrichtete. Weitere Beobachtungen von Angriffen folgten. Am 26./27. Januar begannen dann Massenscans von betroffenen Exchange-Servern.
Microsoft veröffentlichte die Informationen über Schwachstellen und Patches fünfeinhalb Wochen später, am 2. März.
Für die Angriffe macht Microsoft eine chinesische, mutmaßlich staatsnahe Hackergruppe verantwortlich, die sie Hafnium genannt haben - diese Namensgebung haben die Schwachstellen bzw. die Angriffswelle geerbt. Security-Journalist Brian Krebs hat eine detaililerte Zeitleiste der Geschehnisse aufgestellt (Lesestoff 1).

Wer ist betroffen?
Eigentlich fast jeder, denn Microsoft-Exchange-Server hat nun wirklich fast jedes Unternehmen. Die übliche Einschränkung "....aber nicht mit dem Internet verbunden" dürfte hier auch hinfällig sein, denn ein Mailserver muss natürlich mit dem Internet verbunden sein, um Nutzen zu bringen.
Aber: Es sind nur Exchange-Server "on premise", also beim Nutzer selbst betrieben und nicht in der Microsoft-Cloud (Office 365). Es sei denn, trotz O365 wird ein lokaler Exchange-Server betrieben, etwa für SMTP-Relays oder Active-Directory-Synchronisierung.

Weil es so viele Betroffene gibt, hat das BSI IT-Bedrohungslage 3 ausgerufen und Unternehmen mit potenziell betroffenen Servern angeschrieben.
Das vollständige BSI-Advisory mit empfohlenen Maßnahmen finden Sie in Lesestoff-Link 2.

Und jetzt?
Es könnte ganz einfach sein: Es gibt ein Patch gegen die Schwachstelle. Die Sache hat aber gleich zwei Haken:

1. Das Patch gibt es nur für Exchange-Server auf dem neuesten Software-Stand. Da das Patchen von Exchange-Servern aber nicht ganz einfach ist, sind viele Exchange-Server nicht auf dem neuesten Software-Stand. Das bedeutet, sie müssen dorthin erst gebracht werden, und dann funktioniert das Patch. Und damit kommen wir zu Haken
2. Je nachdem, wie viel Zeit zwischen Bekanntwerden der Schwachstelle (und massenhaften Ausnutzung) und dem Patchen vergangen ist, steigt das Risiko, dass der Server vor dem Patchen bereits kompromittiert wurde. Mindestens also die fünfeinhalb Wochen zwischen den Massenscans und dem Microsoft-Patch hatten die Angreifer Zeit für die Kompromittierung.

Exchange-Server sind mit vielen "Kronjuwelen" der IT-Infrastruktur direkt verbunden, DNS und Active Directory zum Beispiel. Wer sich nicht sicher sein kann, dass der eigene Server nicht kompromittiert worden ist (und ganz sicher sein ist schwierig), dann hilft aus Security-Sicht nur "abreißen, neu machen", wenn kein Restrisiko verbleiben darf - aber es gibt gerade bei einer für viele Unternehmen so wichtigen Infrastruktur wie Mailservern eben nicht nur die Security-Sicht.

Die Sache mit der Cloud...
Es ist bittere Ironie für Security-Experten, dass gerade E-Mail-Kunden, die keine Exchange-Server mehr on-premise betreiben, sondern nur in der Microsoft-Cloud, von Hafnium nicht betroffen sind. Ausgerechnet die "böse" Cloud war in diesem Fall die aus Security-Sicht glücklichere Wahl. Ebenso dürfte diese Erkenntnis Microsofts Cloud-Geschäft durchaus zuträglich sein - Wasser auf die Mühlen aller, die ohnehin in die Cloud wollen.

Und damit hätten wir die perfekte Überleitung zum nächsten Thema.

*ich weiß, "fassen wir uns kurz" hält dann doch nie, was es verspricht...

2. IPCEI-CIS: Eine europäische Cloud für die Industrie?

Wer momentan einen Cloud-Gang für OT erwägt, hat dafür mit großer Wahrscheinlichkeit einen US-amerikanischen Konzern auf der Lieferantenliste: Microsoft Azure und Amazon Web Services (AWS) sind die häufigsten Vertreter.

Aus Security-Sicht bedeutet eine Cloud erst einmal wertneutral, dass Sie Kontrolle darüber abgeben, wie ihre Infrastruktur bertrieben wird.
Die eingezeichneten Wolken auf den Netzplänen könnte man eigentlich auch in schwarze Vierecke verwandeln, denn Cloud bedeutet meist vor allem: Black Box. Sie können nicht nachvollziehen, was dort wie technisch umgesetzt ist, und sie dürfen es - falls im Vertrag nicht anders vereinbart - übrigens auch nicht pentesten. Und: Je mehr Dienste in (einer einzigen) Cloud sind, desto abhängiger werden Sie natürlich von dieser einzigen Cloud.

Seinen Cloud-Anbieter (und das Service Level Agreement mit ihm) wähle man also mit Bedacht - aber so viele Optionen gibt es eben nicht, schon gar nicht europäische, die sich an europäische Datenschutz- und Sicherheitsstandards halten.
Das hat auch die EU erkannt und nun ein "Important Project of Common European Interest" (IPCEI) ausgerufen, Thema: "Next Generation Cloud Infrastructure und Services" (CIS). Das Projekt soll Forschung, Entwicklung und Innovationen fördern, die die Entwicklung von europäischem Recht unterworfenen, vertrauenswürdigen und technologisch wettbewerbsfähigen und skalierbaren Cloud-Infrastrukturen vorantreiben. Am Ende soll es eine europäische "Multi-Provider"-Infrastruktur geben - also weg von "Azure oder Amazon".
Das Ganze steht noch am Anfang, aber das Kürzel IPCEI-CIS können wir uns wohl schon einmal merken. Ein kurzes EU-Diskussionspapier dazu findet sich in Lesestoff-Link 1.

Zielgruppe der neuen Cloud-Infrastruktur soll die europäische Industrie sein; gerechtfertigt wäre auch zu sagen: europäische kritische Infrastrukturen, denn wörtlich genannt sind als Beispiele "manufacturing, energy, mobility or healthcare". Die Initiative kommt aus den Ländern Deutschland, Frankreich, Italien und Spanien; einen ersten Workshop gab es Ende Januar - Ergebnisse sind keine öffentlich bekannt.

Zum großen europäischen Cloud-Infrastrukturprojekt GAIA-X hat das neue IPCEI-CIS nur mittelbare Verbindungen: Die dortigen Ergebnissen sollen "genutzt werden, wenn relevant".

Interessierte Unternehmen können sich an das Wirtschaftsministerium wenden (ipcei-cis@bmwi.bund.de), schreibt die Website "Cloudcomputing Insider" (ausführlicher Artikel auf Deutsch im Lesestoff-Link 2).

3. Deutsche Position zu Recht im Cyberspace

Das Auswärtige Amt, das Verteidigungsministerium und das Innenministerium haben gemeinsam ein englischsprachiges Positionspapier veröffentlicht, das den Titel "On the Application of International Law in Cyberspace" trägt (siehe Lesestoff 1).
Dafür, dass das Papier detailliert und klar Stellung zu international höchst umstrittenen rechtlichen Aspekten der Security bezieht, ist es bislang erstaunlich unter dem Radar der Security-Community geblieben.

Es beginnt mit der Kernaussage: Auch im Cyberspace gelten UN-Charter und Völkerrecht und fährt dann auf 17 Seiten mit einer Betrachtung einzelner Aspekte fort:

1) Definition von Cyberangriffen
Kann ein Cyberangriff (explizit genannt sind Angriffe auf kritische Infrastrukturen und Wahlmanipulationen) eine Kriegshandlung darstellen? Wann zählt ein Cyberangriff völkerrechtlich als Angriff?

2) Attribution
Die "Attribution" ist die eindeutige Zuordnung eines Angriffs zu seinem Urheber - das ist die Voraussetzung für eine Reaktion auf einen Angriff, soweit logisch. Leider ist aus technischer Sicht Attribution oft ein großes Problem.
Wie weist man eindeutig den Urheber einer Angriffs nach, bei dem alle digitalen Spuren irgendwie gefälscht sein könnten? Was häufig nachvollziehbar ist, ist der Ort, von dem ein Angriff ausgeht - aber das reiche für die Attribution explizit nicht aus, so das Papier. Dafür ist ein Staat auch dann verantwortlich, wenn staatliche Organe ihre Kompetenzen überschreiten oder wenn er eine nicht-staatliche Gruppe durch den Staat instruiert wird.

3) Reaktionen auf Cyberangriffe
Unter welchen Bedingungen und in welcher Form sind Reaktionen auf Cyberangriffe erlaubt? Im Positionspapier werden "Retortion", also rechtmäßige, aber feindselige Handlungen, Selbstverteidigung und Gegenmaßnahmen - im völkerrechtlichen, nicht technischen Sinn! - beleuchtet.

Für eine rechtliche Einordnung fragen Sie lieber einen Juristen als eine Ingenieurin - ich kann Sie immerhin auf zwei (englischsprachige) einordnende Beiträge des Juristen Michael Schmitt verweisen - Lesestoff-Links 2 und 3.

4. Wie viele Komponentenhersteller haben ein ISAsecure-Zertifikat?

Anton Shipulin hat eine Folie mit interessanter Statistik für uns aus einem ISAsecure-Webinar festgehalten: Wie viele Hersteller wurden in den letzten Jahren bei der ISAsecure für die Einhaltung der ISA/IEC 62443 (Automation Security) zertifiziert (Link zur Grafik s. unten)?

Schaut man sich nur die 62443-Zertifizierungen an, kann man mit ein bisschen Euphemismus sagen: Die Zahlen steigen. Aber seehr langsam. 2020 waren es gute zehn (ja 10, da kommen keine Nullen mehr) Zertifikate jeweils für die 62443-4-1 (sicherer Entwicklungsprozess für Komponenten) und 62443-4-2 (Komponenten), die Zertifizierungen nach IEC 62443-3-3 (Systeme, also ein Verbund von Komponenten) kann man als "nicht signifikant" zusammenfassen.

Der Einordnung halber sei gesagt, dass die Zertifizierung nach dem Schema der ISAsecure nur eine Möglichkeit der Zertifizierung nach IEC 62443 darstellt. Man kann sich auch nach IECEE-Schema oder in Deutschland nach den Zertifizierungsschemata der deutschen Akkreditierungsstelle DAkkS zertifizieren lassen.

Und: Security-Zertifizierungen für Komponten gibt es natürlich nicht nur nach ISA/IEC 62443. Möglich sind auch Zertifizierungen nach Common Criteria oder der Beschleunigten Sicherheitszertifizierung (BSZ) des BSI.

5. Worauf achten bei OT-Asset-Management-Produkten?

Dale Peterson hat vergangenen Monat eine Keynote bei PAS OptICS gehalten, Titel: "Making Sense of ICS Security Products". Man könnte erwarten, dass das Dales eine von Dales Marktanalyse für Security-Monitoring-Tools ist - aber weit gefehlt. Es sind 30 hoch lohnenswerte Minuten, wenn Sie wissen wollen, worauf Sie bei verschiedenen Tools im OT-Security-Dunstkreis - vor allem beim Asset Management, der Nummer-1-Priorität für viele Betreiber! - achten müssen.

Dales Punkte decken sich wunderbar mit dem, was wir in Beratungs- und Evaluierungsprojekten zum Thema Tools in den letzten Jahren gelernt und beobachtet haben. Ich wage eine Zusammenfassung von Dales Punkten, gewürzt mit eigenen Erkenntnissen. Link zum Video unten im Lesestoff-Link.

Asset Management-Tools:

• Aktives Abfragen der Assets ergibt sehr viel bessere Informationen als rein passives Mithören von Netzwerkverkehr. Daher haben mittlerweile alle Hersteller diese Option.
• Nicht jede Monitoring-Lösung ist auch ein gutes Asset Managment Tool - auch wenn sie das behauptet. Asset Management ist nicht nur eine Liste von Assets, sondern auch Configuration Management, Vulnerability Management, Change Management... und das Asset-Inventar muss Informationen enthalten, die das Managen der Assets ermöglichen: Verantwortliche, Kritikalität - keine Informaitonen, die man automatisiert abfragen kann.
• Ad Vulnerability Management: Ein gutes Werkzeug hilft auch dabei, die Frage zu beantworten, ob das Patchen überhaupt sinnvoll ist - auch das nichts, was vollständig automatisiert geht.
• Pragmatische Auswahlstrategie für Asset Management Tools: Demo aller infragekommenden Hersteller anfragen und sehen, welches Inventory die eigenen Assets am besten abbildet.

Security-Monitoring-Tools:

• Die Tools sind teuer - vor allem auch im Betrieb. Also: Nur kaufen, wenn Security-Monitoring wirklich gerade Priorität hat.
• ADetection-Lösungen werden oft primär für ihre Asset-Inventory-Funktionen gekauft. Darin sind sie aber nicht unbedingt besonders gut (siehe oben).
• Monitoring-Produkte helfen nur, wenn Sie wissen, wie sie Ihre Reaktion organisieren - wer bewertet die Daten, und wie reagieren Sie, wenn das Monitoring-Tool wirklich ein Problem anzeigt?

Andere Lösungen:

• Endpoint Protection: Whitelisting schlagen in der OT Virenschutzprogramme (weil Virenschutzprogramme nur weit verbreiteten Schadcode finden). Es gibt bislang keine Endpoint-Protection (z.B. Virenschutz) für SPSen, nur Forschung dazu
• Fernzugriff: Multifaktor-Authentifizierung ist die wichtigste Security-Anforderung
• Cloudanbindung: Unidirectional Gateways sind eine gute Lösung, wenn Daten wirklich nur in eine Richtung kommuniziert werden müssen.
  Sonst bleibt nur Deep Packet Inspection, also Firewalls, die Protokolle auf Applikationsebene verstehen und überprüfen können. Es gibt bislang aber OT-keine spezifische Deep Packet Inspection-Lösung.

Abschließend ein paar Worte zur Tool-Strategie.
Wir haben viele, viele Evaluierungen durchgeführt mit der Fragestellung "was ist das beste OT-Security-Tool"?
Kurz zusammengefasst: Es gibt kein Tool, dass ALLES gut kann. Wichtig ist, wie immer bei Tools, sich seine eigenen Anforderungen klar zu machen - und das Tool dann kompromisslos danach auszuwählen, dass es diese Anforderungen richtig gut kann. Dabei kommt zwangsläufig irgendwann mehr als ein Produkt heraus.
Dann wird das nächste Thema wichtig: Sie wollen kein OT-Security-Datensilo bauen. Nicht in einem Produkt, aber schon gar nicht in mehreren Produkten. Es gibt keinen Grund, warum ein gutes Asset-Inventory-Tool nur für die Security relevant sein sollte, und die Daten sollten nutzbar für alle potenziell interessanten Anwendungen sein - auch solche, die mit Security nichts mehr zu tun haben.
Ehe Sie sich versehen, wird ein gutes Asset-Inventar der erste Baustein für Industrie 4.0 in Ihrem Unternehmen, und dafür haben Sie besser ein gutes Konzept für ein Informationsmodell, mit dem Sie idealerweise unternehmensübergreifend Daten zwischen verschiedenen Softwarewerkzeugen einheitlich austauschen können.

Kurz: Finden Sie gute Tools für einzelne Anwendungen, und finden Sie ein gutes Konzept, wie diese Tools miteinander reden können.

6. Schwachstellen in SPSen von GE und Rockwell

Was wäre so ein Monat ohne Schwachstellen?
Auch dieses Mal sind ein paar Aufreger dabei. Widmen wir uns diesmal ganz den SPSen:

1. Authentifizierungslücke in Rockwell Logix-Steuerungen (CVE-2021-22681):
   Rockwell Logix-SPSen haben offenbar den geheimen Schlüssel für die Authentifizierung zwischen Engineering-PC und Steuerung hartverdrahtet; sowohl in der SPS als auch in den Engineering-PCs. Und dieser hartverdrathtete geheime Schlüssel lässt sich für Fremde extrahieren - das war's dann mit geheim.Jeder mit dem Schlüssel kann so tun, als sei er eine authentifizierte Engineering-Station und die Steuerungslogik verändern.
   Rockwell wurde bereits 2019 von Claroty über die Schwachstelle informiert, hat sie aber erst jetzt publik gemacht (Report von Claroty hier). Es gibt kein Patch, sondern stattdessen Empfehlungen, die einen ziemlich langen Bart haben: Steuerungen im "Run"-Modus belassen, wenn sie nicht verändert werden sollen, Steuerungen nicht mit dem Internet verbinden, Netze segmentieren. Zu Deutsch bedeutet das: "Unsere Steuerungen sind unsicher, ergreift bitte möglichst viele flankierende Maßnahmen".
   Die Schwachstelle hat den CVSS-Höchstwert 10.0. Die Schwachstelle ist von remote ausnutzbar, und die Ausnutzung erfordert wenig Fachwissen.
   Das Advisory des US-CERT finden Sie in Lesestoff 1.
2. Neun Schwachstellen in elektrischen Relais (UR) von General Electrics (diverse CVEs):
   Nicht viel besser als bei Rockwell sieht es bei GE aus. Security-Forscher von Verve, Scada-X, VuMetric und CyTRICS haben insgesamt neun Schwachstellen in den "Universal Relays" (UR) gefunden. Darunter findet sich das ganze Potpourri üblicher Sicherheitslücken feldnahen OT-Komponenten: Hartverdrahtete Passwörter (kommt Ihnen das bekannt vor?), unsichere Werkseinstellungen by Default, ungeschützte Firmware-Uploads, lückenhafte Input-Validierung, Verwendung bereits gebrochener Verschlüsselungsalgorithmen...
   GE empfiehlt ein Upgrade auf aktuelle Firmware-Versionen und stellt außerdem seinen Kunden weitere Informationen zum Umgang mit den Schwachstellen zur Verfügung - allerdings nur nach Login.
   Das kumulative Advisory des US-CERT (kumulativer CVSS 9.8) finden Sie in Lesestoff 2.

Solche Schwachstellen sind ärgerlich, aber nicht neu - und es gibt auch wenig Grund, nun in Panik zu verfallen, wie Ron Brash im Verve-Blog treffend schreibt. So frustrierend es klingt: Der sinnvollste Umgang mit solchen Hiobsbotschaften, ist die Existenz solcher Schwachstellen einfach vorauszusetzen und nicht auf deren Veröffentlichung zu warten. Wenn Sie Ihre Steuerungen als unsicher annehmen, liegen Sie wahrscheinlich richtig - und die meisten flankierenden Maßnahmen sind ohnehin Security-Basics: Keine unnötigen Verbindungen (schon gar nicht von remote), Netze segmentieren, ein Asset-Inventory mit Software- und Protokoll-Versionsständen aufbauen und insgesamt: Sich nicht auf von Herstellern gepriesene inhärente Sicherheitsfeatures verlassen.

Trotzdem: Ich kann die Steilvorlage von Rockwell und GE nicht komplett ungenutzt verstreichen lassen, ohne noch eine frohe Botschaft zu platzieren. Mit den Top 20 Secure PLC Coding Practices, die einen Handlungsleitfaden für sicheren Umgang mit Steuerungen bieten sollen, sind wir auf der Zielgeraden. In der vergangenen Woche haben wir die letzten Texte fertig geschrieben, nun geht es an das Kompilieren der Top20-Liste und das Vorbereiten der Veröffentlichung, die wie geplant diesen Sommer kommen wird.
Wie stellt man Integrität von SPSen sicher, wenn diese dazu wenig Features bieten? Wie geht Input-Validierung? Und welche Werte kann ich monitoren, damit Security-Probleme schnell auffallen? Darauf haben wir mittlerweile ein paar Antworten, und ich freue mich darauf, sie mit Ihnen allen zu teilen.

7. Security for Safety für Ohren und Augen

Falls Sie lieber Hören und Sehen statt immer nur ellenlange Texte zu lesen, gibt es diesen Monat direkt zwei Möglichkeiten dazu:

1. Podcast "Safety Corner":
   Ich war zu Gast bei Florian Wagner in seinem Podcast Safety-Corner. Gesprochen haben wir - natürlich - darüber, wie Security und Safety zusammenhängen, wie nicht, und was sie voneinander lernen können. Den Podcast können Sie auf Spotify und allen üblichen Podcast-Portalen oder direkt im Browser anhören - Link 1 (nein, kein Lesestoff diesmal).
   Aber wahrscheinlich haben Sie das alle bereits gemacht, denn Florian hat mir letzte Woche gesteckt, dass dies seine bislang meistgehörte Podcast-Folge ist...
   Im Übrigen sind auch die anderen Folgen hörenswert, wärmstens empfehlen kann ich Episode 4 zum Systems Engineering.
2. Video "ICS Cybersec 2021":
   Außerdem war ja neulich noch die ICS Cybersec - eine israelische OT-Security-Konferenz, organisiert von Dan Ehrenreich. Für die, die es nicht geschafft haben, reinzuschauen: Die volle Videoaufzeichnung finden Sie unter Link 2. Mein Vortrag zum Thema Security for Safety (Englisch) beginnt ab Minute 57.

8. Termine im April: EnergyShield-Workshop, Hannovermesse

Im April gibt es trotz Ostern zwei Chancen, uns wenigstens virtuell zu treffen:

1. Energy Shield-Workshop am 15.04.2021:
   Energy Shield ist ein von der EU gefördertes Projekt zum Schutz des europäischen Stromnetzes. Im halbtätigen Workshop am 15.04. gibt es Vorträge und zwei Diskussionspanels. Im zweiten Panel darf ich mit Matthias Rohr, Dan Cimpean, Massimiliano Masi und Matteo Merialdo zum Thema "Latest incidents targeting critical
   infrastructure and their impact on designing new technologies, business models and policies" diskutieren.
   Sie können vorab Fragen einreichen, damit wir nicht an den wichtigsten Themen vorbeidiskutieren (Link 1). Das Programm finden Sie in Link 2.
   Die Registrierung ist kostenlos und geht hier.
2. Hannovermesse, 12.-16.04.2021:
   Nachdem wir im vergangenen Jahr skeptisch waren, probieren wir dieses Jahr mal aus, wie sich eine virtuelle Messe so anfühlt.
   Wenn Sie auch mal reinschauen wollen: Kostenlose Tickets für die HMI finden Sie in Link 3.

Ich freue mich, wenn wir uns sehen! Ansonsten lesen wir uns in alter Frische im Mai.

Stay secure!
Sarah Fluchs