Schon März und immer noch Lockdown - das heißt, Sie haben immer noch viel Zeit zum Lesen?
Das ist gut, denn der vergangene Monat hat ausreichend Lesestoff produziert. Wir beginnen OT-lastig mit der Trinkwasserversorgung, der Automobilbranche und dem Maschinen- und Anlagenbau, wenden uns dann Schadsoftware zu (Emotet, Sunburst und Konsorten und Schwachstellen in VPN-Software) und kratzen am Ende noch den Dauerbrenner Security und Safety - zur Abwechslung mal mit dem Fokus auf Gemeinsamkeiten statt auf Unterschieden.

Schnallen Sie sich an, es geht los.

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

1. Cyber-Angriff auf Trinkwasserversorger in Florida
2. Simplify
3. Security-Engineering in der Automobilindustrie
4. Security für Hersteller von Maschinen, Anlagen oder elektrischen Geräten
5. Das Ende von Emotet?
6. Mit Sunburst kann man infiziert sein, ohne Solarwinds zu nutzen
7. SonicWall-Schwachstelle und Windows-Support-Verkürzung
8. Was Security und Safety gemeinsam haben - und was nicht

1. Cyber-Angriff auf Trinkwasserversorger in Florida

Wahrscheinlich sind Sie im Januar an dieser Nachricht nicht vorbeigekommen: Es gab einen Hackerangriff auf eine Trinkwasseranlage in Oldsmar, einer Stadt im US-Bundesstaat Florida.

Vorweg die Tatsachen:
Wie kam der Angreifer in die Anlage?
Der Angreifer konnte mittels der deutschen Software TeamViewer auf das SCADA-System des Wasserversorgers zugreifen. TeamViewer lief auf mehreren Windows-7-Rechnern, es wurde überall dasselbe Passwort verwendet, und es gab keine Firewall zwischen dem Internet und den TeamViewer-Zugängen. TeamViewer war allerdings schon ein halbes Jahr gar nicht mehr in Verwendung - aber eben nicht deinstalliert.
Was hat der Angreifer versucht?
Im SCADA-System erhöhte der Angreifer den Sollwert für Natriumhydroxid (NaOH oder "Ätznatron") im Trinkwasser auf das mehr als 100-fache des normalen Werts.

Wie fiel es auf?
TeamViewer ist ein Werkzeug für Fernzugriff, mit dem man einen entfernten Bildschirm sehen und bedienen kann, als wäre er direkt vor einem. Das bedeutet auch, dass die Mausbewegungen auf dem gesteuerten Bildschirm sichtbar sind.
Das bemerkte ein Anlagenfahrer: Er sah der Veränderung des Sollwerts auf dem Bildschirm "live" zu und korrigierte ihn direkt auf den normalen Wert. Die erhöhten Werte sind nie "effektiv" geworden.

...und wenn der Operator das nicht gesehen hätte?
Hätte der Anlagenfahrer nichts bemerkt, hätte es noch länger als einen Tag gebraucht, bis die Veränderungen im Trinkwasser angekommen wären, und das wäre aufgrund veränderter pH-Werte im Wasser aufgefallen - NaOH ist basisch und erhöht den pH-Wert.

Was hätte passieren können?
Wäre das mit zu viel NaOH versetzte Trinkwasser bei den etwa 15.000 Einwohnern von Oldsmar angekommen wäre, hätte es Vergiftungen hervorrufen können, die sich beispielsweise in in Atembeschwerden, Lungenentzündungen, Brennen in Speiseröhre und Magen, Sehverlust und niedrigem Blutdruck äußern und tödlich enden können.

Und was heißt das jetzt für uns?
Die Nachricht des Angriffs machte eine wilde Tour durch die Medien und sozialen Netzwerke, was zu erwarten war. Manchmal konnte man glatt vergessen, dass ja letztendlich gar nichts passiert war.

Wie einige von Ihnen wissen, haben meine Kollegen und ich gerade im Wassersektor in den letzten Jahren bergeweise Risikoanalysen durchgeführt. Bei jeder einzelner dieser Risikoanalysen war genau das obenstehende Szenario (Fernzugriff, Veränderung des Sollwerts einer Chemikalie) auf der Liste - und zwar, weil die Mitarbeiter der Wasserversorger das auf dem Schirm haben, obwohl sie keine Security-Experten sind. Die hämischen Kommentare zum ahnungslosen Wassersektor sind also fehl am Platz.

Auch dass Teamviewer Gefahren birgt, ist den meisten glasklar. Auch wenn die Security-Community gern auf TeamViewer eindrischt - im Falle Florida muss man sagen: Teamviewer an sich war nicht das Problem. Eine eigentlich nicht mehr genutzte TeamViewer-Installation mit unsicherem Passwort, ohne Firewall, auf veralteten Betriebssystemen war das Problem, und die Lösungen für dazu sind so glasklar wie trivial.

"Angriffserkennung jetzt! Die Erkennung solcher Angriffe darf kein Glück bleiben!" (O-Ton Security-Toolhersteller) ist natürlich nicht die Lösung. Es als Glück zu bezeichnen, dass ein Operator auf den Bildschirm schaut, ist schon etwas abenteuerlich (was genau ist nochmal die Aufgabe eines Operators?).
Darüber hinaus bleibt fraglich, ob Angriffserkennungs-Tools, die nach Anomalien suchen, einen Angriff über eine legimitime Software überhaupt bemerkt hätten. Den Menschen nicht aus dem Spiel zu nehmen scheint zumindest für den Florida-Fall die klügere Option zu sein.
"Angriffserkennung" wird aber wohl dank des IT-Sicherheitsgesetzes 2.0 noch eine Weile das Buzzword No.1 bleiben.

Zwei interessante Notizen können wir noch mitnehmen:

1. Zum einen die Tatsache, dass es überhaupt eine Pressekonferenz gab und der Vorfall an die Öffentlichkeit geraten ist. Gerade bei einem Angriff, der für die Öffentlichkeit zu keinem Zeitpunkt eine Gefährdung darstellte und mit dessen Veröffentlichung man offensichtliche Versäumnisse in der eigenen Infrastruktur publik macht, ist das keine Selbstverständlichkeit.
2. Und wer zum Abschluss ein bisschen Polemik lesen mag - Ralph Langner liefert: "If you are in OT security, you will probably have heard a lot about scary threat actors with funny names such as Xenotime — even though these names admittedly doesn’t refer to real people sitting in real buildings. But when it comes to the Florida hack, the overfunded threat intel community has no clue. For the first noteworthy attack attempt on US critical infrastructure they have no idea where it came from. The irony!"

Last, but not least: Falls Sie sich im Wassersektor heimisch fühlen: Das frisch gegründete Kompetenzzentrum Digitale Wasserwirtschaft (KDW) hat für den 18.03. eine Diskussionsveranstaltung zum Thema "Hacking kritischer Infrastrukturen - Heute in Florida, morgen bei uns?" angekündigt - mit Teilnehmern vom BSI und LKA.
Die Anmeldung ist kostenlos unter dem untenstehenden Link möglich.
(Der Transparenz halber: Ich bin im Beirat des Kompetennzzentrums).

2. Simplify!

Einen kleiner, pumpengrüner Denkanstoß - auch im Kontext des Oldsmar-Angriffs lesbar - liefert Edward Amoroso im Lesestoff-Link.

In seinem kurzen, aber feinen Artikel "Want to Stop Nation-State Cyber Threats? Simplify." erinnert er anschaulich anhand einer kaputten Pumpe in seinem eigenen Keller, wie wichtig es für Security ist, zu wissen, wie Dinge funktionieren. Meist, so sein Punkt, wissen wir, nur was Systeme tun, aber nie wie.

Ein schönes Plädoyer für Systemverständnis als Schlüssel zur Security.
"You must demand simple components, and you must fight the urge to accept additional complexity. If you cannot explain it and diagram it, then it’s too complex."

Und Sie? Können Sie Ihre IT-Infrastruktur erklären und zeichnen?

3. Security-Engineering in der Automobilindustrie

Die Automobilbranche hat ihren eigenen Standard für die Safety - die ISO 26262 - und für Security geht man nun einen ähnlichen Weg mit der ISO/SAE 21434. Die SAE, ursprünglich
"Society of Automobile Engineers", ist eine Organisation, die unter anderem Standards für die Automobilbranche schreibt.

Der Standard ist als Entwurfsversion (DIS, "Draft International Standard") bereits erhältlich - siehe Lesestoff-Link 1. Für die Neugierigen unter Ihnen, die nicht direkt 118 Schweizer Franken investieren wollen, gibt es ein paar Einblicke im frei verfügbaren Whitepaper "Security Engineering for ISO 21434" von Yuri Gil Dantas, Vivek Nigam und Harald Ruess - siehe Lesestoff-Link 2.

Das Whitepaper enthält zwar auch eigene Methodenvorschläge der Autoren, aber die Kapitel 1-3 sind eine gute Zusammenfassung der ISO/SAE 21434, inklusive eines Beispiels (Scheinwerfersystem), das ebenfalls aus dem Standard entlehnt ist.

Der Security-Engineering-Standard für die Automobilindustrie ist sehr umfangreich und enthält einige neue - oder zumindest unübliche - Konzepte, auf die es sich einen Blick zu werfen lohnt:

1. Item vs. Asset: Ein "item" ist in der ISO/SAE 21434 eine Gruppe von Systemen im Betrachtungsraum, inklusive Funktionen und möglicherweise zu treffenden Annahmen (die auch explizit gemacht werden). Ein "asset" ist eine Komponente eines Items, die Schaden verursachen kann. Damit ist nicht - wie sonst häufig - "jedes Klötzchen ein Asset".
2. Damage scenario vs. threat scenario: Auch hier geschieht eine sorgfältige Trennung zwischen Auswirkungen (damage scenario) und Gefährdungen, die zu diesen Auswirkungen führen können (threat scenario).
   
3. Attack feasibility vs. likelihood: Ein Risiko bemisst die ISO/SAE 21434 in Auswirkungen und - nein, nicht Eintrittswahrscheinlichkeit oder -häufigkeit, sondern der sogenannten "attack feasibility", also der Machbarkeit eines Angriffsvektors. Das dürfte viele Ingenieure erfreuen, denen der Pi-mal-Daumen-Wert der Eintrittswahrscheinlichkeit immer ein Dorn im Auge war.
4. Risikoanalyse im Lebenszyklus: Der Standardentwurf ist ingesamt in Lebenszyklusphasen gegliedert - und in verschiedenen Lebenszyklusphasen kommen RiIsikoanalysemethoden (ein ganzes Sammelsurium wird vorgeschlagen) auf verschiedene Weisen zum Einsatz. Ein sehr konkreter Versuch, der Praxis näher zu kommen (und nicht von idealtypischen Risikoanalysen, durchführbar auf der grünen Wiese, auszugehen).

Es verdient mindestens eine Randbemerkung, dass die ISO/SAE 21434 ein Security-Standard ist, der versucht, an Erfolgskonzepte aus der Safety anzuknüpfen.
Nicht zufällig schlägt er Lebenszyklusphasen ähnlich der ISO 26262 vor, und auch die Strategie, Schaden verursachende Komponenten (Assets) einzugrenzen, erinnert an Fault Tree Analysis-Methoden. Viele OT-Security-Standards, die in dieser Denkweise entstehen, enden mit den allerbesten Absichten in zu kleinteiliger Methodik - zu häufig sind augenfällige Parallelen zwischen Security und Safety doch eher "false friends".

4. Security für Hersteller von Maschinen, Anlagen oder elektrischen Geräten

Seit einer Weile halten wir in Kooperation mit der schweizerischen IBF Solutions AG Security-Seminare für Hersteller, die unter die Maschinenrichtlinie der EU fallen. Einige Fragen kommen dabei immer wieder auf, weshalb unser Geschäftsführer Heiko Rudolph, der Geschäftsführer der IBF, Johannes Frick, und ich diese nun in einem Fachbeitrag beantworten (siehe Lesestoff-Link).

Es ist ein Plädoyer fürs Anfangen, nicht fürs Perfektmachen geworden - die eigenen Früchte etwas höher hängen, da die Angreifer oft erst einmal nach denen greifen, die am leichtesten erreichbar sind (die berühmten "low hanging fruits").

Aber wo anfangen? Drei Vorschläge:

1. Im Engineering: Auf der ohnehin zu erledigenden Maschinensicherheits-Risikobetrachtung gemäß Maschinenrichtlinie aufbauen. Dabei hilft die ISO/TR 12100-4, lässt aber einige wichtige Fragen außer Acht.
2. In der Inbetriebnahme: Security-Eigenschaften transparent machen
3. Im Betrieb: Schwachstellen sind keine Schande - aber sie schlecht kommunizieren, ist eine

Wir werfen auch einen kurzen Blick auf die umstrittene rechtliche Frage, ob die Maschinenrichtlinie selbst eigentlich die Berücksichtigung von Security fordert. Aber ganz ehrlich, während sich die Rechtsgelehrten noch streiten: Wenn Sie Hersteller sind, legen Sie einfach schon einmal gemütlich los, denn wenn die Maschinenrichtlinie die Security nicht fordert, dann wird es eben die nächste EU-Richtlinie tun, zum Beispiel der Cybersecurity Act.

5. Das Ende von Emotet?

Es ging hier viel um Ransomware in den letzten Monaten; und das war selten gut: Ransomware-Angriffe haben in der Corona-Pandemie zugenommen, Erpressersummen steigen.
Daher wollen wir auch die positiven Nachrichten nicht übersehen.

Ein häufiges Einfallstor für Ransomware ist der Trojaner Emotet, der - häufig versteckt in einem harmlos aussehenden MS-Word-Dokument, angehängt an eine E-Mail - den Rechner befällt, auf dem das Dokument geöffnet wurde.
Einmal infiziert, nimmt ein befallener Rechner dann Kontakt zu einem Command and Control-Server, auch C2-Server genannt, auf. Von solchen Servern aus können die befallenen Rechner gesteuert werden, zum Beispiel, um weitere Schadsoftware (z.B. Ransomware) nachzuladen, den Schadcode so zu verändertn, dass Virenscanner ihn nicht finden, oder um mit Hilfe der E-Mail-Kontakte des befallenen Rechners schadcodebehaftete E-Mails an weitere Opfer zu schicken.
Weil diese Command und Control-Server Tausende befallener Rechnern kontrollieren und für ihre Zwecke missbrauchen können, spricht man auch von einem Botnet - einem Netzwerk oft ahnungsloser Rechner, die für diejenigen,die C2-Server kontrollieren können, Gewehr bei Fuß stehen.

Mit so einem Botnet lässt sich natürlich einiges anstellen - und damit ist es ein prima Geschäftsmodell für die organisierte Kriminalität: Gegen Geld kann Emotet Türen zu Ziel-Computern öffnen, quasi "Malware as a Service". Die Gruppe hinter Emotet hat dieses Vorgehen perfektioniert und wird daher oft als "gefährlichste Schadsoftware der Welt" oder vom BSI auch als auch "König der Schadsoftware" bezeichnet.

Herauszufinden, welche Menschen hinter einem Botnetz stecken, ist schwierig; die beteiligten Server zu finden, wenigstens etwas einfacher. Denn um ein Botnetz mit tausenden von Rechner zu steuern, braucht man IT-Infrastruktur. Diese IT-Infrastruktur haben Ermittlungsbehörden aus Deutschland, den Niederlanden, der Ukraine, Litauen, Frankreich, England, Kanada und den USA in einer konzertierten Aktion gemeinsam mit der europäischen Polizeibehörde Europol und der europäischen Strafjustizbehörde Eurojust "zerschlagen" (koordinierte Pressemitteilung des Bundeskriminalamts siehe Lesestoff 1, Artikel in der Süddeutschen im Lesestoff 2).

"Zerschlagen" bedeutet in diesem Zusammenhang: Server wurden beschlagnahmt, der Zugriff der Täter auf diese Server wurde unterbunden und Beweise gesichert. Zu Recht wird das als riesiger Erfolg gefeiert, vor allem auch einer, bei dem die internationale Kooperation und Informationsweitergabe funktioniert hat.

Als nächstes geht es um die Opfer, also die von Emotet befallenen unfreiwilligen Botnetz-"Mitglieder". Die im Rahmen der Beweissicherung ermittelten IP-Adressen werden nun dem BSI übergeben, das die Opfer informiert.
Zudem hat natürlich nun die Polizei durch Übernahme der C2-Server dieselbe Macht über die Opfersysteme wie einst die Angreifer. Dieser wurde genutzt, um die Schadsoftware auf den befallenen Rechnern in Quarantäne zu verschieben, wo sie kein weiteres Unheil einrichten kann, und auch eine Deinstallation der Schadsoftware ist denkbar sowie eine Funktion, die verhindert, das betroffene Rechner mit anderen C2-Servern als den beschlagnahmten Kontakt aufnehmen können (Details im heise-Artikel, Lesestoff 3)

Das wirft natürlich Fragen auf: Dürfen die das? Oder, genauer: Wie weit darf die Polizei - auch zum guten Zweck - in die Opfersysteme eingreifen? Diese Frage beantworten Dennis Kenji-Kipker und Sven Herpig in einem Netzpolitik.org-Gastbeitrag aus juristischer Perspektive (Lesestoff 4).

6. Mit Sunburst kann man auch infiziert sein, ohne Solarwinds zu nutzen

Der Solarwinds-Schwachstelle Sunburst haben wir uns bereits im Januar-Briefing ausführlich gewidmet. Vielleicht erinnern Sie sich an das Leitmotiv dabei: "Das sieht schlechter aus als gedacht".

Nun, die Analysen gehen natürlich weiter, und es gibt ein paar kleinere Updates, zum Beispiel gesellt sich zur "Sunburst"-Schadsoftware ein weiteres Wetter-Sammelsurium "Sunspot", "Raindrop", "Teardrop".

Interessanter:
Der Virenschutz-Hersteller Malwarebytes hat bekannt gegeben, auch von den Sunburst-Angreifern kompromittiert worden zu sein.
Allerdings nutzt Malwarebytes die Solarwinds-Orion-Software, die bislang als Einfallstor bekannt geworden war, überhaupt nicht - es sind also offenbar alternative Einfallstore verwendet worden. Im Fall von Malwarebytes war das eine im Zusammenhang mit Microsoft Office 365 genutzte Cloud-Variante des Verzeichnisdiensts Actice Directory (AD), Azure AD (Deutschsprachiger Artikel bei inside-it-ch im Lesestoff-Link 1).
Verzeichnisdienste, die Nutzerkonten und -zugangsdaten verwalten, sind besonders lukrative Angriffsziele. Speziell zur Verteidigung gegen Sunburst-Infektionen hat FireEye Härtungsstrategien für Microsoft 365 veröffentlicht (Lesestoff-Link 2).

Im Lesestoff-Link 3 widmet sich außerdem Tim Conway für SANS der Frage, ob OT-Betreiber sich mit Solarwinds beschäftigen sollten.

7. SonicWall-Schwachstelle und Windows-Support-Verkürzung

Da wir heute schon über die sichere Verwendung von Teamviewer gesprochen haben, hier noch eine Warnung für ein anderes Fernzugriffstool: SonicWall hat eine Zero-Day-Schwachstelle in seinen Remote-Access-Gateways der SMA-100-Baureihe bekanntgegeben (s. Lesestoff 1).
Es gibt ein Patch, das schnellstmöglich installiert werden sollte - denn für die Schwachstelle sind schon Möglichkeiten der Ausnutzung (sogenannte Exploits) bekannt.

A propos Patching: Wenn Sie bislang Windows 10 Enterprise-Systeme im Long-Term Service Channel (LTSC) betrieben haben, also mit einem Betriebssystem, dessen Funktionalität sich bis zu 10 Jahre nicht ändert, dann gibt es Neuigkeiten. Microsoft hat angekündigt (Lesestoff 2), dass die zukünftigen LTSC-Releases nur noch 5 und nicht 10 Jahre unterstützt werden.
Weiterhin 10 Jahre Support gibt es für die IoT-Variante des Betriebssystems (Windows 10 IoT Enterprise).

8. Was Security und Safety gemeinsam haben - und was nicht

Für alle, die die israelische ICS Cybersec-Konferenz verpasst haben oder einfach lieber lesen als Videos schauen, habe ich die Quintessenz aus meinem Vortrag auch verbloggt (s. Lesestoff). Es geht darum, was Security und Safety gemeinsam haben, wo die Gemeinsamkeiten aufhören, und wie man durch eine Kopplung der beiden trotzdem durch den Risikoanalysedschungel kommt.

"Kopplung" bedeutet, wie bei gekoppelten Zugwaggons: Security und Safety können einen Teil ihres Weges gemeinsam bestreiten, müssen aber nicht - und sie haben eine gemeinsame Lokomotive, die Resilienz.

Außerdem beinhaltet der Artikel einen "Sneak Peak" auf die Entwicklung der Security-for-Safety-Standards (genauer gesagt Technical Reports) ISA TR84.00.09 und IEC TR 63069.

Stay secure!
Sarah Fluchs