hard-hat-icon

Security-Briefing für Hard Hats: Januar 2021

Willkommen im Jahr 2021! Schön, dass Sie da sind.

Vielleicht haben Sie es gar nicht gemerkt, aber wir sind dieses Mal eine Woche später dran als sonst. Ich wollte mir, Ihnen und dem Jahr ein bisschen Zeit geben, um auf Betriebstemperatur zu kommen. Dank Solarwinds wäre das wohl gar nicht nötig gewesen - nicht wenige der 300.000 Solarwinds-Kunden hat die Hiobsbotschaft der potenziellen Kompromittierung über die Feiertage beschäftigt.
Falls sie auch dazu gehören, überspringen Sie einfach das erste Thema - Sie können es wahrscheinlich nicht mehr hören, und für das Zweite können Sie definitiv noch ein wenig frischen Gehirnschmalz brauchen.

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

  1. Solarwinds / Sunburst: "Das sieht schlechter aus als gedacht"
  2. Systemmodelle für Security-Engineering
  3. Neues vom digitalen Zwilling
  4. ICS Detection Tools - Marktübersicht
  5. OpenSource Tool für Siemens PCS7-Härtung
  6. GitHub-Studie: WIe sicher ist OpenSource-Software?
  7. Ransomware in OT?
  8. ICS CyberSec Conference Israel

1. Solarwinds / Sunburst: "Das sieht schlechter aus als gedacht"

Ich möchte gar nicht erst versuchen, hier die x.te Analyse des Solarwinds-Vorfalls zu schreiben.
Stattdessen: Ein Zusammenfassung, was eigentlich passiert ist, sowie Links auf guten Lesestoff zum Thema. Los geht's.

Erst die Zusammenfassung:
Es begann alles mit FireEye. FireEye ist eine IT-Security-Firma, die sowohl Softwareprodukte als auch - unter dem Namen Mandiant - Beratungs-, Threat Intelligence- und Incident-Response-Leistungen anbietet. FireEye hat unter anderem die TRITON/TRISIS-Malware analysiert.
Jede Security-Firma weiß, dass sie unter beständigem Hacker-Beschuss stehen; aus Angreifersicht hat es natürlich etwas, Experten für IT-Sicherheit zu zeigen, dass sie selbst Sicherheitslücken haben.
Als FireEye im Dezember bekanntgab, dass sie gehackt wurden, war das deswegen eine unerfreuliche, aber nicht wahnsinnig überraschende Nachricht. Passiert den Besten.
Das Ganze bekam die erste interessante Wendung, als FireEye bekanntgab, dass selbst entwickelte Pentesting-Tools beim Angriff entwendet wurden. Solche Tools nutzen Pentester und Red Teamer, um Sicherheitslücken bei Kunden effizient ausnutzen - und sie sind ein gutes Beispiel für die "Dual Use"-Problematik der IT-Security, denn natürlich sind diese Tools genauso effizient, wenn sie in die falschen Hände geraten.

FireEye hat daraufhin "Countermeasures" gegen die Nutzung dieser Tools auf GitHub veröffentlicht - zumeist sind das Regelwerke für Intrusion Detection-Systeme.

Problem solved, könnte man denken - ärgerlich, aber passiert. Wenn nicht am gleichen Tag wie die Countermeasures FireEye-CEO Kevin Mandia einen Blog veröffentlicht hätte, in dem er beschreibt, dass der Angriff ziemlich hochkarätig war:
"Based on my 25 years in cyber security and responding to incidents, I’ve concluded we are witnessing an attack by a nation with top-tier offensive capabilities. This attack is different from the tens of thousands of incidents we have responded to throughout the years."

Das sieht schlechter aus als gedacht, sagten da die ersten Kommentatoren, und das kann man seitdem eigentlich täglich wiederholen.

Denn natürlich hat FireEye Nachforschungen angestellt, wie es eigentlich zur Kompromittierung kam, und dabei etwas aufgedeckt, was scheibchenweise immer größer wurde (und noch wird):
Die Angreifer hatten die weit verbreitete Monitoring-Software "Orion" der Firma Solarwinds verwendet, um über ein legitim aussehendes Software-Update für Orion eine Hintertür in Zielsystemen zu installieren.

Aus jetziger Perspektive war der FireEye-Hack also nur ein Symptom eines sehr viel größeren Angriffs - und wir können wohl froh sein, dass er bei FireEye aufgeflogen ist. Die Ausmaße: 18.000 kompromittierte Netzwerke, davon 250 aktiv von den Angreifern ausspioniert. Unter den Zielen sind hochrangige Firmen und Behörden: Mehrere US-Regierungsbehörden, Deloitte, Microsoft, Intel, Cisco, Nvidia, kritische Infrastrukturen im Gesundheitswesen und der Petrochemie - die Liste wächst täglich.
Seit wann?
FireEye hat bereits im Dezember gemutmaßt, dass die Angreifer schon seit dem Frühjahr 2020 im Netzwerk gewesen sein könnten, aber dieses Datum rückt mehr und mehr in die Vergangenheit. Mittlerweile geht man davon aus, dass es schon im Herbst 2019 losging.
Was war das Ziel?
Weiß man noch nicht so genau, aber die US-Regierungsbehörden scheinen die primäre Zielscheibe gewesen zu sein.
Wer steck dahinter?
Wohl Russland - genauer: der russische Auslandsgeheimdienst SWR.

Wichtiger ist, was wir als Security-Community daraus lernen. Der Angriff ist eine "Supply Chain Attack", ein Angriff auf die Lieferkette, da nicht Solarwinds selbst, sondern die Solarwinds-Kundschaft das eigentlich Ziel war.

Solarwinds selbst war offenbar kein Security-Musterschüler, wie die New York Times schreibt:
"Interviews with current and former employees of Solarwinds suggest it was slow to make security a priority, even as its software was adopted by America’s premier cybersecurity company and federal agencies. Employees say that under Mr. Thompson, an accountant by training and a former chief financial officer, every part of the business was examined for cost savings and common security practices were eschewed because of their expense."

Aber für eigentlichen Opfer des Angriffs kommt er aus der Software-Lieferkette kommt, über ein Update von einem als vertrauenswürdig eingestuften Hersteller, und das macht die Frage, was man dagegen hätte tun können, schwierig und für einzelne Unternehmen wohl unlösbar.

In seinem lesenswerten Meinungsbeitrag zu Sunburst macht Security-Legende Bruce Schneier drei wichtigte Punkte:

  1. Angriffe wie Sunburst sind erlaubt und das Brot-und-Butter-Geschäft von Geheimdiensten. Die USA werden nichts dagegen tun (außer neidisch auf die Russen zu sein, dass sie die Solarwinds-Idee zuerst hatten).
  2. Von digitaler Spionage zu digitalen Angriffshandlungen sind es im Cyberspace aber nur ein paar Zeilen Code.
  3. Der US-Ansatz von "defense forward", also der Priorisierung der Offensive, des "wir greifen an, bevor sie uns angreifen" macht uns alle unsicherer, denn er bedeutet, dass man Hintertüren fördert und Wissen über Sicherheitslücken geheimhält, statt sie zu schließen - und dabei sich selbst verwundbarer macht.

Oder, in Schneiers Worten:
"If anything, the US’s prioritization of offense over defense makes us less safe. In the interests of surveillance, the NSA has pushed for an insecure cellphone encryption standard and a backdoor in random number generators (important for secure encryption). [...] In other words, we allow for insecure standards and systems, because we can use them to spy on others. We need to adopt a defense-dominant strategy. As computers and the internet become increasingly essential to society, cyber-attacks are likely to be the precursor to actual war. We are simply too vulnerable when we prioritize offense, even if we have to give up the advantage of using those insecurities to spy on others.
[...]
The US needs to willingly give up part of its offensive advantage in cyberspace in exchange for a vastly more secure global cyberspace. We need to invest in securing the world’s supply chains from this type of attack, and to press for international norms and agreements prioritizing cybersecurity, like the 2018 Paris Call for Trust and Security in Cyberspace or the Global Commission on the Stability of Cyberspace. Hardening widely used software like Orion (or the core internet protocols) helps everyone. We need to dampen this offensive arms race rather than exacerbate it, and work towards cyber peace."

2. EU gibt Cybersecurity-Strategie bekannt, USA warnt vor OT-Angriffen

Ich weiß ja nicht, wie es Ihnen geht, aber mich nervt das schon länger: Ich habe ja mal Ingenieur gelernt, und ich dachte danach, wenn Ingenieure Probleme sehen, bauen sie ein Modell, um die Probleme systematisch zu lösen.

Für Security schien das irgendwie nicht zu gelten, und ich finde, wir müssen das ändern.
2020 haben einige kluge Leute Konzepte weiterentwickelt, die zum hehren Ziel "Modelle für Security Engineering" beitragen können: der digitale Zwilling, die Verwaltungsschale, besseres Modellieren von Angriffsgraphen, Chaos Engineering.

Daher war nun die Zeit reif für einen ersten Vorschlag für Modelle, die das Security Engineering systematisieren können. Das Paper "On Modelling for Security Engineering (as a submodel of the Digital Twin)" finden Sie im Lesestoff-Link, vorerst auf Englisch.

Die gute Nachricht: Auch wenn wir als Security-Community spät dran sind, ist jetzt eine wunderbare Zeit, um mit der Modellbildung anzufangen - denn alle Welt baut gerade Modelle für den digitalen Zwilling!

3. Neues vom digitalen Zwilling

Da, wie Sie gerade gelesen haben, der digitale Zwilling eine nicht unwichtige Rolle für das Security Engineering spielen könnte, kommen hier ein paar Bits und Bytes der letzten Monate zum Konzept - Achtung, es geht kreuz und quer durch verschiedene "Versionen" des digitalen Zwillings. Los geht es mit der "Verwaltungsschale" - die ist nämlich auch nichts anderes als eine Digital-Twin-Implementierung.

Die Links unten sind daher ausnahmsweise mal keine Lesestofflinks, sondern Implementierlinks: Digital Twin-Software zum Anfassen und Ausprobieren - erstaunlich ähnlich benamt: Einmal die Microsoft-Variante (Azure Digital Twin Explorer) und einmal die Verwaltungsschalen-Variante (Admin Shell IO).

4. ICS Detection Tools - Marktübersicht

Bei den ICS Detection Tools hat sich in 2020 einiges getan.
Die vielen Akquisitionen und Partnerschaften alle zu überblicken, ist müßig - in letzter Zeit ist PAS von Hexagon gekauft worden, CyberX von Microsoft, und Nozomi partnert mit Honeywell und Yokogawa.

Dale Peterson hat, wie in den letzten Jahren regelmäßig, eine Marktübersicht über die Detection Tools verfasst, diesmal in drei Teilen (alle in den Lesestoff-Links):

  1. Teil 1 dreht sich vor allem um den aktuellen Stand bei Dragos, Claroty und Nozomi, die Dale als Marktführer sieht.
  2. Teil 2 teilt die Hersteller in Lösungssegmente auf.
  3. Teil 3 schaut auf die Interaktion der Detection Tools mit SIEM- und Asset-Management-Lösungen.

Machen Sie sich Ihr eigenes Bild, aber ich nehme aus den Analysen mit, dass es (no surprise here) die eierlegende Wollmilchsau nicht gibt. Es macht Sinn, sich die Werkzeuge für den Zweck auszusuchen, der einem wichtig ist - im Zweifel ist das dann eben mehr als ein Werkzeug für mehr als eine Aufgabe.

Umso wichtiger wird es für die Hersteller, dass sie keine Datensilos bauen, sondern Interoperabilität zwischen ihren und anderen Tools ermöglichen - und für die Nutzer der Tools, dass sie eine Lösung für die Integration von Informationen aus verschiedenen Werkzeugen finden.
Eine SIEM-Lösung, wie sie in Teil 3 von Dales Analyse anklingt, springt da eigentlich noch zu kurz, wir brauchen etwas domänenübergreifendes, kein Security-Datensilo. Ideen dazu siehe oben, in den Gedanken zu Modellierung und digitalen Zwillingen.

Zurück zum Thema "welches Tool für welchen Zweck":
Ein paar Highlight-Aussagen aus Dales Analysen habe ich dazu herausgepickt, ohne Anspruch auf Vollständigkeit:

  • Asset Inventory: Claroty hat das beste Asset Inventory kurz vor Nozomi, während Dragos hier eine Schwäche hat.
  • Herstellerpartnerschaften: Nozomi baut stark auf Herstellerpartnerschaften, z.B. Honeywell und Yokogawa (s.o.). Das kann wichtig sein, weil Leitsystemhersteller oft die Installation bestimmter Software in ihren Systemen mit Verlust von Herstellergarantien unmöglich machen.
  • Incident-Response-Dienstleistungen (aufbauend auf den Threat-Intelligence-Daten): Claroty hat dafür Partner, Dragos macht's selbst, Nozomi hat noch keinen Incident-Response-Service
  • Risikometriken und Compliance-Analysen (z.B. zur IEC 62443): Wird von Betreibern gefordert und fehlt häufig. Radiflow z.B. hat ein Compliance-Tool.
  • Nischenanbieter (geografisch oder inhaltlich): SCADAfence, Otorio, Industrial Defender, Rhebo, Radiflow
  • Vulnerability Management (idealerweise für IT und OT): Das ist die Spezialität von Tenable für IT, und seit der Akquisition von Indegy auch für OT. Ein weiterer Anbieter ist Tripwire (IT und OT) und dann gibt es noch bislang reine IT-Lösungen (Rapid7, Qualys)
  • Daten in die Cloud (um dort Predictive Maintenance o.ä. anhand von digitalen Zwillingen anzubieten): Microsoft inkl. Akquisition von CyberX
  • Detection-Funktion als VM integriert in OT-Netzwerkkomponenten: Cisco inkl Akquisition von Sentryo
  • Eigene Produkte von Leitsystemherstellern (in der Regel auf die eigenen Systeme beschränkt): Honeywell (inkl. Akquisition von Nextnine), Schneider Electric, Siemens, Yokogawa, Emerson...
  • SIEM-Lösungen, die OT-Daten integrieren können: Bislang nur Splunk mit OT-Plug-In.

5. Open Source Tool für Siemens PCS7-Härtung

Nach viel Lesestoff kommen nun noch ein paar kürzere Hinweise.
Los geht es mit Otorio - den Namen haben Sie vielleicht gerade erst im ICS Detection Tool-Marktüberblick gelesen.

Otorio-Researcher hatten im September Konfigurationsschwachstellen in Siemens PCS 7 gefunden. Nun haben sie ein Open-Source-Tool herausgebracht, das die sichere Siemens-PCS7-Konfiguration leichter machen soll - Blog dazu im Lesestoff-Link.

Die Worte zur Begründung, warum Otorio sich diesem Tool gewidmet hat, sprechen Betreibern wahrscheinlich aus der Seele: Konfigurationslücken sind mindestens genauso wichtig wie fancy Schwachstellen.

Das kann man ruhig mal für sich so stehen lassen:
"While CVE "hunting" is an important process, and should be kept going, there can be simpler ways of exploiting the network. One example is exploiting a default or a misconfigured security configuration on a target endpoint. We believe such configuration issues must be addressed with (at least) as the same priority as vulnerability scanning and mitigation. We also believe that the defender's role is to mitigate what will most likely be exploited by an attacker. Exploiting a misconfigured Windows share on the network is much easier than applying a complicated CVE exploit. The impact for the attacked company, however, is just as bad."

6. GitHub-Studie: Wie sicher ist OpenSource-Software?

Open Source hat einen guten Ruf. Man teilt Wissen, erfindet das Rad nicht neu - und sicherer ist es auch, schließlich schaut eine ganze Community auf die Schwachstellen!
Fast richtig - wichtiger Unterschied: Es KANN eine ganze Community auf die Schwachstellen schauen, was nicht heißt, dass sie es auch tut.

GitHub, die Plattform, auf der wohl der meiste OpenSource-Quellcode liegt, hat einen idealen Datensatz um die Security von OpenSource-Projekten zu untersuchen - und genau das hat haben Sie im "Octoverse"-Projekt auch gemacht (s. Lesestoff).

Das Ergebnis ist aufgrund des beschränkten Datensatzes natürlich kein Vergleich der Sicherheit von Open- und ClosedSource-Software, aber mindestens zwei Aussagen sind interessant:

Erstens: Auch in OpenSource-Software werden Schwachstellen oft länger als vier Jahre lang nicht entdeckt.
Zweitens: Wenn die Schwachstellen aber dann entdeckt wurden, ist die Community schnell mit dem Fixen - das dauert "typischerweise" nur knapp über vier Wochen.

Vor dem Hintergrund der Supply-Chain-Risiken und Sunburst macht die weit verbreitete Verwendung von OpenSource-Software (94% der in der Studie betrachteten GitHub-Projekte nutzten OpenSource-Code) aber auch nachdenklich: Eine Sicherheitslücke in einem viel verwendeten Stück OpenSource-Quellcode kann enorme Auswirkungen haben.
Das rechtfertigt diese bemerkenswerte Aussage im Octoverse-Report:
"Open source is critical infrastructure".

7. Ransomware in OT?

Ransomware war ja 2020 ein totales Trendthema (leider...), da wurde es Zeit, dass es mal Zahlen zu ICS gibt. Dragos und IBM (mit Security X-Force-Produkt) zusammengenommen haben wahrscheinlich einen ansehnlichen Datensatz zu Ransomware-Vorfällen in ICS, in der Studie haben sie 194 Fälle ausgewertet und dabei eine Steigerung der Ransomwarefälle von 500% Prozent zwischen 2018 und 2020 gefunden - mit einem Peak im Mai 2020.

Wenn die Ransomware, die ihr Einfallstor in der Regel über die IT-Netzwerke hat, den Sprung in die OT schafft, kann sie potenziell Produktionsprozesse unterbrechen, bemerkt die Studie. Die empfohlenen Maßnahmen bergen daher auch keine großen Überraschungen, aber das behauptet die Studie auch nicht:
Sich den Übergang (alle Übergänge!) von IT nach OT bewusst machen, OT in einer eigenen Domäne betreiben und den Netzwerkverkehr an der Grenze streng kontrollieren. Außerdem die üblichen Verdächtigen: Backup, Multifaktorauthentifizierung, Defense in Depth, Awareness. Oh, und Dragos oder IBM kaufen, selbstverständlich.

Eine interessante Beobachtung der Dragos/IBM-Studie ist, dass Ransomware-Angreifer zunehmend nicht "nur" die Verschlüsselung von Daten als Erpressungsbasis nutzen, sondern auch drohen, sensible Daten zu veröffentlichen. Sensible Daten können Geschäftsgeheimnisse sein - aber auch Infrastrukturdaten, die zukünftige Angriffe erleichtern.

Weiteren Einblick in "verschärfte" Erpressungstaktiken bietet übrigens ein kleiner Artikel bei ZDnet: Einige Ransomware-Angreifer nutzen mittlerweile Callcenter, um ihre Opfer mit Angriffen unter Druck zu setzen, ihre Daten nicht von Backups wiederherzustellen, weil das nicht helfen würde und sie weiter "unter Beschuss" stünden, sondern lieber das Lösegeld zu zahlen...

8. ICS CyberSec Conference Israel

Eine kleine Ankündigungen in eigener Sache zum Schluss:
Am 11. Februar findet die israelische ICS CyberSec 2021 statt - natürlich nur virtuell, es ist ja Pandemie... Jedenfalls werde ich virtuell ein Update zum elegantesten Pfad durch den Dschungel Security for Safety geben und Einblicke in den Stand der ISA84-Arbeit zum IEC TR 84.00.09 gewähren, und ich vermute, dass die Vorträge der anderen Speaker Dale Peterson, Patrick Miller, Marina Krotofil und Dan Ehrenreich gewohnt hörenswert sein werden.

Die Teilnahme ist kostenlos und die Vorträge wird es in zwei verschiedenen Slots geben, um sie für möglichst viele Zeitzonen angenehm zu machen.
In deutscher Zeit bedeutet das:11. Februar, 9-13 Uhr oder 17-21 Uhr.

Kostenlose Registrierung über den Link unten.

Stay secure!
Sarah Fluchs

hard hat icon

Dieser Artikel entstammt unserem monatlichen Security‑Briefing für Hard Hats