Mensch, schön, dass Sie alle noch da sind! In unserer kleinen, kongressbedingten Pause habe ich den kleinen blauen Helm hier durchaus vermisst. Es juckte mir ein paar Mal in den Fingern, denn es haben sich richtig viele spannende Themen angestaut.
Vor allem in der Cybersecurity-Politik ist momentan so richtig Dampf, sowohl in Deutschland, als auch in der EU, als auch international. Außerdem schauen wir uns zwei Cybersecurity-Vorfälle an, zu denen es neue Erkenntnisse gibt, und jede Menge frischer Lesestoff für das lange Wochenende ist auch dabei. Legen wir los.

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

1. Knackpunkte aus der EU-Debatte zum Cyber Resilience Act (CRA)
2. Security by Design: Internationaler Schulterschluss (und S4x23-Video)
3. Loseblattsammlung: Viel los in der deutschen Cybersecurity-Politik
4. Oldsmar... Und wieder ein OT-Security-Vorfall weniger
5. Lieferkettenangriff Next Level: Die ganze Story hinter dem SolarWinds-Hack
6. Neuer Blog: Erst verstehen, dann schützen
7. Termine: H2-Sicherheit, OTCEP Singapur, Security unter Kontrolle

1. Knackpunkte aus der EU-Debatte zum Cyber Resilience Act (CRA)

Wie geht es eigentlich weiter mit dem Cyber Resilience Act (CRA)?

Zur Erinnerung: Am 15. September 2022 hatte die EU-Kommission erstmals einen Entwurf für den CRA veröffentlicht. Wenn die Gesetzgebung so käme, wäre das eine umfassende Regulierung für Produkthersteller: Cybersecurity würde ins CE-Kennzeichen aufgenommen so wie bislang Sicherheits-Anforderungen für Druckbehälter, Sonnenbrillen, Kinderspielzeug und viele andere Produkte (siehe Erklärblog von September 2022, Lesestoff 1).

Das ist jetzt fast ein Dreivierteljahr her, und es ist Zeit für ein kleines Update. Am 01.01.2023 hat Schweden die EU-Ratspräsidentschaft für die erste Hälfte von 2023 übernommen. Jeder neue Ratsvorsitz bringt auch neue Prioritäten mit sich, und zumindest die Deutsche Industrie- und Handelskammer hat Anfang des Jahres analysiert, dass Schweden eher "wenig Ambition bei Digitalthemen" habe: "Bei dem im Herbst 2022 vorgestellten Cyber Resilience Act [...] ist das Ziel lediglich, die Diskussionen zu einer Positionierung im Rat zu beginnen oder fortzuführen."

Es war also zunächst wenig überraschend, dass es erst einmal augenscheinlich nicht so richtig voranging mit dem CRA. Aber in den letzten Wochen hat sich dann doch einiges getan.

Crashkurs EU-Politik: Die EU-Kommission macht Gesetzesvorschläge, über die sich dann Parlament und Rat einigen müssen - sonst gibt es am Ende kein Gesetz (gute Ablaufgrafik dazu hier). Und mittlerweile gibt es sowohl eine Position des EU-Parlaments als auch eine geänderte Fassung des Rats.

Die Position des EU-Parlaments fassen sogenannte Berichterstatter zusammen. Berichterstatter sind Mitglieder des EU-Parlaments; für verschiedene Themen gibt es verschiedene Berichterstatter. Für den CRA ist das der italienische Abgeordnete Nicola Danti.
Der Berichterstatterreport beinhaltet also die Themen, die das Parlament am bisherigen CRA-Entwurf kritisch sieht. Der europäische Rat reagiert darauf mit einer neuen Fassung des Gesetzesentwurfs, um den Text näher an eine Fassung zu bringen, auf die Rat und Parlament sich einigen können.

Beides, der Berichterstatterreport (Lesestoff 2) und der vollständige Neuentwurf des CRA-Texts (nicht öffentlich), liegen mittlerweile vor, wie EURACTIV und der Tagesspiegel berichten.
Das grundsätzliche Konstrukt aus dem CRA-Entwurf (erklärt in Lesestoff 1) bleibt dasselbe - aber um einige zentrale Punkte gibt es Diskussionen. Man kann also absehen, welche Punkte sich wahrscheinlich noch ändern werden - auch wenn nicht entschieden ist, in welche Richtung. Die industrielle Automatisierung spielt dabei durchaus eine Rolle.

Eine Auswahl der Knackpunkte:

• Die Definition der betroffenen Produkte: Es soll weiterhin eine Unterscheidung dahingehend geben, wie hoch die Hürde für die Konformitätsbewertung (also das Erlangen des CE-Kennzeichens ist: Selbstauskunft des Herstellers oder externes Konformitätsbewertungsverfahren?
  Höhere Anforderungen gelten für Produkte, die entweder eine Sicherheitsfunktion erfüllen (z.B. Authentifizierung), eine zentrale Systemfunktion erfüllen - oder beides zusammen. Im Vergleich zum bisherigen CRA-Entwurf werden aber Mikrocontroller und industrielle Automatisierungssysteme nicht mehr explizit genannt - dafür aber Verbraucherprodukte wie Wearables, Gesundheitsprodukte und Babyphones.
  Der Querverweis auf die NIS2-Richtlinie (Produkte, die in einer kritischen Infrastruktur eingesetzt werden) ist nicht mehr da - dies hat wohl vor allem den Grund, dass es schwierig vorherzusehen ist, wo ein Produkt eingesetzt wird.
• Automatisierte Security-Updates: Diese sollen im neuesten Entwurf als Standardoption gelten, wenn der Nutzer sich nicht dagegen entscheidet. Ausnahmen soll es für industrielle Produkte geben, bei denen automatische Updates zu Störungen und Stillständen führen könnten.
• Produktlebensdauer: Im bisherigen Entwurf war vorgesehen, dass Hersteller während der gesamten Produktlebensdauer oder fünf Jahre lang (je nachdem, was kürzer ist) Security-Updates zur Verfügung stellen müssen. Diese pauschale Festlegung auf fünf Jahre ist ein Kritikpunkt des Parlaments: Besser wäre, wenn die Hersteller die Lebensdauer selbst festlegen dürften (durchaus auch als Wettbewerbsfaktor) - aber wenn diese unter fünf Jahren liegt, den Quellcode ihrer Produkte offenlegen müssten, damit Updates nach Ende der offiziellen Lebensdauer von Dritten bereitgestellt werden können (was auch nicht unproblematisch ist.... siehe diesen älteren Blogpost zum Thema Micropatching).
• Meldung von Security-Vorfällen: Dies ist gemäß Tagesspiegel der größte Konfliktpunkt zwischen Rat und Parlament: An wen sollen Sicherheitsvorfälle gemeldet werden? Kommission und Parlament sind für die zentrale Sammlung bei der EU-Agentur für Cybersicherheit Enisa, damit es auch einen zentralen Überblick über die Lage der Cybersicherheit in der EU gibt.
  Der Rat hätte lieber eine dezentrale Sammlung bei den nationalen Cyber Security Incident Response Teams (die es aber nicht überall gibt). Grund: Die Enisa habe zu wenig Kapazitäten für die Verarbeitung aller Meldungen, außerdem sei die zentrale Sammlung solch sensibler Informationen ein Sicherheitsrisiko, weil sie für Angreifer ebenso wertvoll wie für Verteidiger sind.
• Maschinenverordnung kein Ersatz für CRA: Im ursprünglichen Entwurf sollten Maschinenprodukte, die unter die EU-Maschinenverordnung fallen, auch als konform zum CRA gelten. Das ist im neuen Entwurf nicht mehr vorgesehen.

Ab Juli ist dann Spanien dran mit der Ratspräsidentschaft. Nun wird es erst einmal spannend sein zu sehen, was das EU-Parlament in der zweiten Lesung zum CRA-Entwurf sagt.

2. Security by Design: Internationaler Schulterschluss (und S4x23-Video)

Von Gesetzgebungs-Details zum Cyber Resilience Act zoomen wir nun ein wenig heraus, sowohl thematisch, als auch geografisch. Denn der CRA ist nur ein Baustein des übergeordneten Themas Security by Design, und die EU ist nur ein Teil der internationalen Gemeinschaft, die sich mit diesem Thema befasst - und zwar mit wohl noch nie dagewesenem Schulterschluss.

Security-Behörden aus den USA, Kanada, den Niederlanden, Großbritannien, Australien, Neuseeland und - tadaaa! - Deutschland haben gemeinsame Empfehlungen zu Security by Design veröffentlicht. Das sind große Neuigkeiten. Weniger, weil das Papier inhaltlich so bahnbrechend ist (es ist im Lesestoff verlinkt), sondern aus zwei anderen Gründen:

1. Es zeigt, dass sich in der Produkt-Security etwas ändern muss:
   So eine gemeinsame, koordinierte Aktion in der internationalen Cybersecurity-Politik schon bemerkenswert (weil selten) ist. Es verleiht dem Thema "Security by Design" großes Gewicht und ist ein Zeichen, dass all diese Länder die Problematik gleichermaßen sehen und daran arbeiten.
   Das ist wichtig, denn: Bislang zielt die Cybersecurity-Regulierung primär auf Betreiber. Betreiber kritischer Infrastrukturen, Betreiber von Anlagen, die unter die Störfallverordnung fallen. Aber nicht zuletzt die Häufung der Lieferketten-Vorfälle haben gezeigt: Wenn Betreiber mit unsicheren Produkten arbeiten müssen, die sie nicht verstehen (können) und auf die sie keinen Einfluss nehmen können, ist das wie Suppe essen mit der Gabel.
   Wann ist es eigentlich okay geworden, Security zum Anwenderproblem zu machen? Wann haben wir eigentlich kapituliert und begonnen zu akzeptieren, dass all unsere IT- und OT-Systeme so fragil sind, dass man Security-Profi sein muss, um sie guten Gewissens zu betreiben? Es wird Zeit, dass auch Hersteller auch einen Teil ihrer Verantwortung übernehmen, oder - wie CISA-Direktorin Jen Easterly jüngst im Magazin "Foreign Affairs" schrieb: Hört auf, Security-Verantwortung wie einen schwarzen Peter herumzureichen.
2. Es macht Hoffnung auf weiteren Schulterschluss:
   Wenn die Einigung auf gemeinsame Prinzipien geklappt hat, besteht zumindest Hoffnung, dass es auch mit der weitren Gesetzgebung im Schulterschluss klappt. Das wäre wichtig, denn für global agierende Produkthersteller ist es ineffizient, völlig unterschiedliche Security-Anforderungen auf verschiedenen Märkten erfüllen zu müssen.
   Security by Design ist schwierig genug und die verpflichtende Erfüllung von Security-Anforderungen, etwa durch den CRA, empfinden viele Hersteller ohnehin schon als Zumutung - es wäre gut, wenn die Politik das Ganze nicht noch frustrierender macht.

Überaus freundlich war, dass die internationalen Sicherheitsbehörden ihr "Security-by-Design"-Papier mit dem Veröffentlichungszeitpunkt meines S4x23-Vortrags "Security by Design Decisions" abgestimmt haben. Es geht darum, wie Ingenieure mit wenig Zeit und Budget trotzdem Security by Design in ihrem Alltag unterbekommen. Link zum Video siehe unten.

Übrigens, weil das oft missverstanden wird:
In der Automatisierungstechnik ist „Security by Design“ nicht nur Herstellerthema. Sicher muss ja nicht nur die einzelne Steuerung, das einzelne Leitsystem sein - sondern die ganze automatisierte Anlage. Für die liegt aber ein großer Teil des Engineerings beim Integrator oder sogar beim Betreiber. „Secure by design“ wird so eine Anlage nur, wenn jeder, der Engineering-Entscheidungen trifft, auch Verantwortung für die damit untrennbar verbundenen Security-Entscheidungen übernimmt.

Das BMBF-Projekt, in dem wir unsere "Security by Design Decisions"-Methode (inklusive Software) entwickeln, läuft jedenfalls noch bis Ende des Jahres, und das Forschungsteam freut sich über möglichst viel Anwenderfeedback. Wenn Sie also Lust haben, mal reinzuschauen und vielleicht einen Testlauf "Security by Design" in Ihrer Organisation (Hersteller, Integrator oder Betreiber) zu  machen: Einfach bei mir melden.

3. Loseblattsammlung: Viel los in der deutschen Cybersecurity-Politik

So, nun von internationalem zurück aufs nationale Parkett. Auch in Deutschland tut sich momentan so viel im Bereich Cybersecurity-Gesetzgebung, dass man kaum hinterherkommt (vor allem dann nicht, wenn man das Hardhats-Briefing zwei Monate Pause hatte). Also, Datumstempel gezückt - hier kommt eine Loseblattsammlung dessen, was zwischen deutschen Aktendeckeln momentan so los ist:

• Neue Kritisverordnung: Die 3. Änderungsverordnung zur BSI-Kritisverordnung ist veröffentlicht. Zur Erinnerung: Die Kritisverordnung regelt, welche Anlage ab welchen Schwellenwerten in welchem Sektor als kritische Infrastruktur zählen. In der neuesten Änderung wurden "LNG-Anlagen" zu Anhang 1 hinzugefügt (klar, die Realität der Gasversorgung in Deutschland hat sich ja zuletzt deutlich verändert); außerdem "Seekabelanlandestationen" zu Anhang 4 (Telekommunikation).
• Schwellenwerte für Entsorger: Der Kritis-Sektor Siedlungsabfallentsorgung ist noch ganz neu; daher kommt er in der bisherigen Kritis-Verordnung noch gar nicht vor. Natürlich schauen Betreiber gespannt hin, wer in ihrem Sektor KRITIS-Betreiber werden soll. Der Entwurf für die Kritis-V für die Abfallentsorgung liegt nun vor, wie der Tagesspiegel berichtet. Der Sektor soll in zwei Gruppen gegliedert werden:
  🚮 Sammlung und Beförderung und
  ♻ Verwertung und Beseitigung
  Als KRITIS zählt eine Anlage immer dann, wenn sie mehr als 500.000 Einwohner versorgt. Für die Abfallwirtschaft soll das so übersetzt werden: Alle Anlagen, die als jährliche Kapazität das Pro-Kopf-Abfallaufkommen von 500.000 Einwohnern verarbeiten können, fallen darunter. Das bedeutet aufs Jahr gerechnet:
  🍽 80.000 t Restmüll,
  🍎 32.000 t Biomüll,
  🍫 18.000 t Verpackungen (gelber Sack),
  📰 33.000 t Altpapier oder
  🍾 12.500 t Glas
  Das Ziel der Definitionen aus Sicht des Bundesinniministeriums (BMI) sei, im Ernstfall "allen Müll von der Straße zu bekommen", zitiert Tagesspiegel-Reporter Benjamin Stiebel. Die Branchenvertreter der Abfallentsorger hätten lieber eine engere Definition gehabt.
• B3S Ernährung: Im Sektor Ernährung ist der branchenspezifische Sicherheitsstandard (B3S) überarbeitet worden. Erinnerung: Ein B3S regelt, wie genau Betreiber eines spezifischen Sektors den im BSI-Gesetz nur vage umschriebenen "Stand der Technik" erfüllen können. Die neueste Version für die Ernährungsindustrie hat die Nummer 3.1 und hat die Eignungsfeststellung des BSI bestanden.
• Grundschutzprofil Chemie: Die Chemieindustrie ist ja keine kritische Infrastruktur (nur möglicherweise "Unternehmen im besonderen öffentlichen Interesse") - deswegen gibt es auch keinen branchenspezifischen Sicherheitsstandard (B3S). Trotzdem bestand der Wunsch nach einer Handreichung, wie die Branche Security angehen soll. Der NAMUR-AK 4.18 hat daher ein Grundschutzprofil entwickelt.
  Ein Grundschutzprofil ist eine Art Kochrezept, wie der BSI IT-Grundschutz auf einen bestimmten Organisationstyp angewendet werden kann. Dabei muss allerdings der etwas eigenwilligen Methode des IT-Grundschutzes gefolgt werden: Die Architektur des abzusichernden Geltungsbereich muss mit IT-Grundschutz-Bausteinen modelliert werden, die ihrerseits eine implizite Risiko-Analyse und passende Security-Maßnahmen enthalten. Weil in einem Profil, das für eine ganze Branche anwendbar sein soll, natürlich keine konkrete Architektur vorliegt, werden verschiedene Referenzarchitekturen definiert.
  Das Grundschutzprofil Chemie ist in jahrelanger Arbeit entstanden, nun öffentlich verfügbar und kann kommentiert werden.
• Grundsätzliche Anforderungen im Nachweisverfahren (nach § 8a Abs. 5 BSIG): Das BSI hat Anforderungen an KRITS-Nachweise veröffentlicht. Man kann dem Papier ansehen, dass hinter jedem Paragraphen eine Geschichte steckt - und wenn Sie wie ich einige KRITIS-Prüfungen miterlebt haben, fallen Ihnen bestimmt beim Lesen auch spontan ein paar Anekdoten ein....
  Leseprobe? "Die prüfende Stelle muss gegenüber dem Betreiber der zu prüfenden KRITIS-Anlage bzw.
  des zu prüfenden KRITIS-Anlagenteils unternehmensfremd sowie rechtlich und wirtschaft-
  lich unabhängig sein. Insbesondere sind damit Stellen untauglich, die über geteilte Unter-
  nehmens- oder Konzernstrukturen mit dem Betreiber verbunden sind."
  Spaß beiseite: Bei den § 8a-Prüfern ist noch einige Luft nach oben, das ist ein offenes Geheimnis. Von "mir egal, dass sie einen B3S haben, ich prüfe grundsätzlich nach ISO/IEC 27001" über "zu dieser Abweichung kenne ich eine Firma, die Ihnen bei der Behebung hilft, hier ist die Visitenkarte" zu "der branchenspezifische Experte im Prüfteam ist besonders auskunftsfähig, denn er ist zufällig auch unser ISMS-Beauftragter" gibt es da einige Kuriositäten. Also gut, dass nun zumindest ein paar Eckpfeiler vom BSI definiert sind.
• Stichtag für Systeme zur Angriffserkennung: Dann gab es ja noch einen Stichtag in den letzten Wochen: Ab 1. Mai 2023 müssen kritische Infrastrukturen Systeme zur Angriffserkennung umsetzen. Hintergrund dieser regulatorischen Forderung, so munkelt man, ist übrigens die zu geringe Anzahl der gemeldeten Security-Vorfälle gewesen. Wenn jeder ein Angriffserkennungssystem hat, so das Kalkül, dann müssten da ja auch mehr Vorfälle erkannt werden.
  So weit, so nachvollziehbar, das Problem ist nur: So ein System zur Angriffserkennung (IDS, IPS, SIEM...) ist tatsächlich eher etwas für Fortgeschrittene. Um überhaupt sinnvoll damit arbeiten zu können, muss man seine Infrastruktur kennen, wissen, was normal ist, und jemanden haben, der die Angriffsmeldungen einordnen und sinnvoll darauf reagieren kann.
  Dementsprechend gibt es wahrscheinlich noch große Lücken in der Umsetzung - und große Wissenslücken beim BSI über die Umsetzung. "„Über die Erfüllung der Anforderungen zum Einsatz von Systemen zur Angriffserkennung kann aktuell noch keine Aussage getroffen werden“, sagte einen BSI-Sprecherin dem Tagesspiegel. Mit der ganz großen Keule (bis zu 2 Mio. € Strafe) wird die Behörde ohnehin eher nicht um die Ecke kommen; üblich sind erst einmal Verwarnungen und Fristen zur Nachbesserung.
  Das BSI hat unterdessen seine FAQ für Systeme zur Angriffserkennung angepasst. Das gehört auch zur Kategorie "man kann sich die Anekdoten dazu denken": Fristverlängerungen von "wenigen Wochen" sind nun gemäß FAQ möglich, wenn die Ursache durch die "seitens des BSI vorgenommenen Änderungen der Prüfmodalitäten zustande kommt". Außerdem sind Prüfungen durch "Unternehmen [...], die auch bereits als Berater auftraten" möglich - wenn die Berater- und Prüferrolle in persona voneinander getrennt werden.
• Grundgesetzänderung für aktive Cyberabwehr: Bundesinnenministerin Nancy Faeser möchte, das künftig das Bundeskriminalamt (BKA) "aktive Cyberabwehr" betreiben darf. "Aktive Cyberabwehr", auch als "Hackback" bezeichnet, bedeutet im Klartext, dass das BKA dann selbst Cyberangriffe durchführen darf.
  Bislang ist das nicht möglich, womit sich Deutschlands Weg deutlich von dem etwa der USA oder Israel abhebt. Das nächste Stuxnet kommt aus Deutschland? Der Weg bis dahin ist lang, denn dafür müsste erst einmal das Grundgesetz geändert werden.
• Personalia: Ja, und dann war da ja noch diese unrühmliche Geschichte mit Jan Böhmermann und Arne Schönbohm, genauer: Das Absägen des ehemaligen BSI-Präsidenten nach der Ausstrahlung einer sensationslüsternen, schlecht recherchierte Unterhaltungssendung. Wenig überraschend hat das Innenministerium unter Nancy Faeser, das Schönbohm damals abberief, nun nach sechsmonatiger Untersuchung herausgefunden, dass die Vorwürfe haltlos waren.
  Seinen Job ist Arne Schönbohm trotzdem los, eine öffentliche Rehabilitierung blieb bislang aus. Die neue BSI-Präsidentin steht unterdessen fest: Es wird Claudia Plattner. Sie ist Mathematikerin, ist derzeit Generaldirektorin für Informationssysteme bei der EZB und übernimmt die Leitung des BSI zum 01. Juli 2023.

Der nächste spannende Stichtag steht übrigens schon vor der Tür: Bis zum 17. Oktober 2024 muss Deutschland die europäische NIS-2-Richtlinie in deutsches Recht überführen. Das bedeutet, dass die Gesetzgebung für die Security kritischer Infrastrukturen weitreichend überarbeitet werden muss. Ein früher Referentenentwurf liegt vor, aber die Eier sind noch so ungelegt, dass wir mit der Analyse noch ein wenig abwarten. Die ganz Ungeduldigen können im Lesestoff schon einmal reinschauen.
Übrigens: Das Gesetz trägt den wunderschönen Arbeitstitel "NIS2UmsuCG" (NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz). Mit der Aufgabe, das schon einmal auswendig zu lernen, schließen wir die deutschen Aktendeckel für diesen Monat wieder.

4. Oldsmar... Und wieder ein OT-Security-Vorfall weniger

Weil Ihnen nun wahrscheinlich noch etwas der Kopf schwirrt, kommt nun ein bisschen leichtere Kost aus der Kategorie "was wurde eigentlich aus...?".

Erinnern Sie sich noch an den Security-Vorfall in Oldsmar, Florida? Falls nein: Hardhats-Text hier, Blog dort.

Nun, der Security-Vorfall war wohl keiner, wie Anna Ribeiro von Industrial Cyber nun berichtet (oder auf deutsch: Moritz Tremmel für Golem, im Lesestoff). Stattdessen handelte es sich um einen Bedienfehlers eines Mitarbeiters. Das Ganze war ein "non-event", innert zwei Minuten erledigt, aber "die Strafverfolgungsbehörden und die Medien haben sich auf die Idee eines Cyberangriffs gestürzt und sie verbreitet", wird ein ehemaliger Mitarbeiter der Stadt zitiert. Er gibt freimütig zu, man habe durchaus viele Security-Schwachstellen gehabt, an denen habe man auch gearbeitet. Aber die viermonatige FBI-Ermittlung des "Cyberangriffs" ergab - nichts.

Erinnert Sie das ungut an den Arne-Schönbohm-Fall von gerade? Dann müssen wir wohl noch einmal über Hype-Mechanismen im öffentlichen Diskurs sprechen, wenn es um Cybersecurity geht.

Jedenfalls werden nun einige Security-Produktpräsentationen aktualisiert werden müssen. Wenn man mit Panikmache Security verkaufen möchte, sehnt man sich natürlich nach OT-Security-Vorfällen oder Beinah-Vorfällen. Davon gibt es nur nicht besonders viele, zumindest nicht mit wirklichen physischen Folgen. Und nun mit Oldsmar noch einen weniger.

5. Lieferkettenangriff Next Level: Die ganze Story hinter dem SolarWinds-Hack

Und weil es so schön war, noch ein bisschen Lesestoff aus der Kategorie "was wurde eigentlich aus...?" Dieses Mal geht es um einen definitiv realen Security-Vorfall, nämlich den Lieferkettenangriff auf die Netzwerkverwaltungssoftware Solarwinds (siehe Hardhats-Briefings von Januar und März 2021).

Kim Zetter ist dran geblieben, nachdem der Hype vorbei war, und hat die Ermittlungen rund um den Vorfall weiter verfolgt. Das Ergebnis ist bei WIRED erschienen, lang und lesenswert (Lesestoff).

Zetter zeichnet den gesamten Verlauf der Entdeckung des SolarWinds-Hacks nach - zumindest das, was sie herausbekommen konnte. Denn das Ziel des Angriffs waren wahrscheinlich (auch) US-Regierungsbehörden - und die geben sich eher schmallippig, wenn man sie danach fragt, was die Angreifer gesucht haben könnten und was sie tatsächlich gefunden haben.

Der Text macht sehr greifbar, warum Lieferkettenangriffe so ein großes Problem sind.

Im SolarWinds-Fall haben die Angreifer sich sehr genau ausgesucht, welches Software-Produkt sie angreifen wollen, indem sie Quellcode und Kundendaten verschiedener SolarWinds-Produkte auswerteten. Die Software "Orion" war "die perfekte Wahl", schreibt Zetter. Etwa 45 % der SolarWinds-Kunden nutzen Orion, in Summe etwa 33.000 Kunden. Die Netzwerkverwaltungssoftware nimmt beim Kunden eine mächtige Position im Netzwerk ein und sie kommuniziert mit vielen verschiedenen Servern. Ein bisschen untergejubelte Kommunikation fällt da nicht groß auf.

Die Orion-Software haben die Angreifer kompromittiert, indem sie bösartigen Code in ein Software-Update geschmuggelt haben - und zwar in den Software-Entwicklungsprozess hinein, also noch bevor die legitimen Orion-Entwickler das Update programmiert daraus ausführbare Dateien gemacht haben. Die manipulierte Datei saß geduldig im Build-Server für das Orion-Produkt. Ein Build-Server macht aus Quellcode von verschiedenen Entwicklern eine ausführbare Datei - und zwar automatisiert. Was man in dort unterbringt, kommt völlig legitim in die Software, wird signiert und als legitimes Update an Kunden ausgeliefert.

Die Kompromittierung der Software während ihrer Entstehung, in der Build-Phase, war ein Novum. Vor dem SolarWinds-Angriff gab es auch schon Lieferkettenangriffe, bei denen Software-Update-Mechanismen für die Verteilung von Malware genutzt wurden. Aber diese verwendeten meist gestohlene Signaturen, um statt eines legitimen Updates Schadcode auszuliefern und dieses legitim erscheinen zu lassen. Im SolarWinds-Fall begann der Betrug noch einen Schritt eher, nämlich in einer Vermengung des legitimen Software-Updates mit einer Zeile Schadcode.

Build-Server als Teil eines Continuous Integration / Continuous Deployment - Prozesses benutzt jedes Softwareunternehmen. Es ist Stand der Technik. Gegen einen Angriff wie den auf SolarWinds dürfte keiner dieser Server gewappnet sein. Es gibt sehr viele potenzielle Opfer für so einen Angriff, und eigentlich wissen wir gar nicht genau, wie viele davon auch schon reale Opfer sind. Denn auch wenn wir mittlerweile rekonstruieren können, wie der Schadcode in das SolarWinds-Update kam, ist immer noch unklar, wie eigentlich die Angreifer Zugriff auf das SolarWinds-Netzwerk bekommen konnten - so ein Build-Server ist natürlich nur von internen Netzen aus erreichbar. Es sei nicht undenkbar, schreibt auch Zetter, dass auch SolarWinds schon Opfer eines Lieferkettenangriffs war. Auch Softwarelieferanten sind Kunden eines anderen Softwarelieferanten, das bringt unsere vernetzte, auf Software aufbauende Welt mit sich.

Wenn man all diese Erkenntnisse sacken lässt, wird klar: Ganz sicher hat der SolarWinds-Vorfall dazu beigetragen, dass Security by Design nun so einen großen Stellenwert für Security-Behörden auf der ganzen Welt hat. Er zeigt einfach, dass unsere vernetzte IT-Infrastruktur in ihren Entwicklungsprozessen aus Security-Sicht ganz schön blank ist.

Und dass ein Angriff, der diese Verwundbarkeit ausnutzt, gewaltige Auswirkungen haben kann. Dieser Absatz über dien Tag nach der Bekanntgabe des SolarWinds-Hacks reicht, um die Fantasie anzuregen:
"Monday morning, calls started cascading in to SolarWinds from journalists, federal lawmakers, customers, and government agencies in and outside the US, including president-elect Joe Biden’s transition team. Employees from across the company were pulled in to answer them, but the queue grew to more than 19,000 calls.The US Cybersecurity and Infrastructure Security Agency wanted to know whether any research labs developing Covid vaccines had been hit. Foreign governments wanted lists of victims inside their borders. Industry groups for power and energy wanted to know whether nuclear facilities were breached."

6. Neuer Blog: Erst verstehen, dann schützen

Security für Automatisierungstechnik haben wir ja irgendwie alle nicht gelernt.
Entweder kommt man aus der Automatisierung, kennt seine Prozesse, Anlagen und Automatisierungssysteme in- und auswendig und muss sich nun plötzlich mit der Spielverderberdisziplin Security beschäftigen.
Oder man kommt aus der IT oder bestenfalls schon aus der IT-Security, kennt Server- und Netzwerktechnik, Angriffsvektoren, Risiken, und übliche Security-Maßnahmen und muss sich plötzlich mit der sehr fremden Welt der Automatisierungstechnik befassen.

Möglich auch, dass man in beiden Welten noch nicht so richtig daheim ist und nun vor der großen Aufgabe steht, zwei sehr unterschiedliche Denksysteme gleichzeitig lernen zu müssen.

Egal, welcher Weg zutrifft: Die wirklich großen Aha-Effekte entstehen, wenn Wissen aus beiden Welten aufeinandertrifft. Wenn wir nicht versuchen, das Wissen der einen Welt der anderen überzustülpen, wenn ITler nicht stirnrunzeln, dass die Automatisierer "halt einfach mal von Windows XP weg müssten" und die Automatisierer nicht augenrollen, dass die ITler "eben keine Ahnung hätten, was so ein Anlagenstillstand bedeute", wenn wir reden und verstehen statt zu runzeln und und rollen.

Mein Kollege Dietmar Marggraff hat einen Blog gestartet, der genau so ein Synthese versucht. Er erklärt sich selbst und seinen Lesern Anlagen- und Automatisierungsprozesse und würzt sie mit Security-Überlegungen: Wie funktioniert eigentlich ein Regelkreis? Und was bedeutet es aus Security-Sicht, dass er so funktioniert?

Bislang gibt es Artikel zu Gasturbinen, dem Stromnetz, Umspannwerken, Kohlekraftwerken, und Prozessleitsystemen, aber der Fundus wächst ständig. Große Leseempfehlung!
(Und wenn Sie selbst Experte für irgendeinen Typ automatisierte Anlage oder ein Stück Automatisierungstechnik sind und auch reden statt runzeln wollen - melden Sie sich gern bei Dietmar zu einem gemeinsamen "was bedeutet das eigentlich aus Security-Sicht?"-Gespräch. Horizonterweiterung garantiert.

7. Termine: H2-Sicherheit, OTCEP Singapur, Security unter Kontrolle

So, das wars mit dem Marathon-Briefing für diesen Monat. Zum Abschluss kommt noch ein kleines Ankündigungs-Stakkato:

• Am 6. Juli veranstaltet Dr. Manuela Jopen von der Gesellschaft für Anlagen- und Reaktorsicherheit (GRS) einen Workshop zum Thema Wasserstoff-Sicherheit. Elektrolyseure zur Herstellung von Wasserstoff erleben momentan im Zuge der Energiewende einen Boom - sie müssen schnell und wirtschaftlich in Serie gefertigt werden. "Schlabbern" wir dabei die Sicherheit?
  Es geht um verschiedene Aspekte der Sicherheit, ich darf in einem Impulsvortrag den Aspekt Security beleuchten. Ich freue mich sehr darauf, denn es wird eine Veranstaltung, bei der ich richtig viel lernen werde. Der Workshop ist für alle Interessierten offen, online und kostenlos. Anmelden können Sie sich hier.
• Noch ein bisschen länger hin, aber Ende August bin ich wieder für eine Woche in Singapur als Teil des OT Cybersecurity Expert Panels der staatlichen Cybersecurity Agency of Singapore. Letztes Jahr war es eine beeindruckende Veranstaltung, sowohl aufgrund des hochkarätig besetzten Panels um Robert M. Lee, Dale Peterson, Joel Langill, Eric Byres et al., aber auch aufgrund der Entschlossenheit und Stringenz, mit der die Singapurer in den letzten Jahren ihr Programm für die Security kritischer Infrastrukturen aufgebaut haben.
  Von letztem Jahr gibt es ein Video meines Vortrags zu den Top 20 Secure PLC Coding Practices. Vor allem die ebenfalls aufgezeichnete Debatte danach lohnt sich... die Singapurer waren ganz aus dem Häuschen, weil es so eine "schöne kontroverse Debatte" geworden ist. Hier geht's zum Video.
• Unser Kongress SECURITY UNTER KONTROLLE (liebevoll "SuK" genannt) - der Grund, warum dieses Briefing ein kleines Frühlingsschläfchen hinter sich hat - war ein voller Erfolg. Wir waren mit 150 Teilnehmern ausverkauft und das schönste Teilnehmer-Feedback war die "gleichbleibend hohe Qualität der Vorträge", die "tolle Stimmung unter den Teilnehmern" und "man merkt das viele Herzblut, das in der Veranstaltung steckt". Wenn Sie sich wundern, warum die Fotos alle so wunderschön sind - das liegt an der tollen Location. Das Alte Kesselhaus des ehemaligen Stahlwerks auf dem Areal Böhler ist einfach enorm gutaussehend.
  Alle Vorträge (bis auf eine Ausnahme) wurden aufgezeichnet und werden, wenn wir mit schneiden fertig sind, nach und nach auf dem SuK-YouTube-Kanal veröffentlicht. Einfach schon mal abonnieren, dann verpassen Sie die Videos nicht. Auch gut: SuK auf LinkedIn folgen.
  Wenn Sie nächstes Jahr dabei sein wollen: Der nächste Termin ist der 11.+12. September 2024, der Call for Contributions wird diesen Sommer online gehen.

Stay secure!
Sarah Fluchs