Der März war pickepackevoll mit OT-Security-Themen - also ist das April-Briefing für Hard Hats ebenfalls pickepackevoll; inklusive einiger Deep Dives.

Bei den Cybersecurity-Regulierungen für Produkte (IoT, Autos, "alles, was Verbindungen hat") hat es im März richtig viele Neuigkeiten gegeben - dazu haben wir dieses Mal gleich drei Themen. Den Anfang macht natürlich der Cyber Resilience Act, der unerwartet früh durchs EU-Parlament gegangen ist.

News zu Cyber-Angriffen waren auch zahlreich, sodass ich eine Auswahl treffen musste. Ich habe mich für die Aktivitäten chinesischer Häcker in kritischen Infrastrukturen und für den Hack der CISA, dem US-Äquivalent des BSI, entschieden; außerdem schauen wir in den Rückspiegel und reflektieren die Cyber-Komponente des russischen Einmarschs in die Ukraine.

Und dann gab es noch das erste Update des NIST Cybersecurity Frameworks seit 10 Jahren und die Top 20 Secure PLC Coding Practices gibt's nun auf Deutsch. Die Entscheidung, was von beidem größere Nachricht ist, überlasse ich Ihnen, liebe Leser.

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

1. Der Cyber Resilience Act ist im EU-Parlament beschlossen worden
2. Freiwilliges Security-Label für IoT: USA führen Cyber Trust Mark ein
3. UNECE R155/156 gelten ab Juli: VW und Porsche stellen wegen Cybersecurity-Vorgaben beliebte Modelle ein
4. 2 Jahre Krieg: Rückblick auf hybride Kriegstaktiken beim russischen Einmarsch in die Ukraine
5. Chinesische Angriffe auf kritische Infrastrukturen: I-Soon, Volt Typhoon und Hafenkräne
6. US-CISA (Äquivalent zum deutschen BSI) wurde gehackt
7. NIST Cybersecurity Framework 2.0
8. Top 20 Secure PLC Coding Practices: Deutsche Übersetzung

1. Der Cyber Resilience Act ist im EU-Parlament beschlossen worden

Das war mal eine Überraschung (die mich ordentlich Schlaf gekostet hat): Anfang des Jahres hieß es noch, vielleicht wird es mit dem CRA nichts mehr vor den EU-Parlamentswahlen im Juni. Nun hat das EU-Parlament den CRA doch schon im März beschlossen.

Die am 12.03.2024 vom Parlament verabschiedete Fassung des CRA ist öffentlich verfügbar; es ist das erste öffentliche Update seit der Entwurfsfassung vom 15.09.2022 und mit großer Wahrscheinlichkeit auch die finale Version, vorbehaltlich der “legal-linguistic finalisation” — die ändert aber nichs mehr am Inhalt.
Nun fehlt nur noch die Zustimmung des europäischen Rats, dann kann der CRA in Kraft treten; er würde dann ab 2027 gelten.

Also der richtige Zeitpunkt, um sich anzuschauen, was eigentlich nun auf Hersteller von "products with digital elements" - also so ziemlich alle IT-/OT-Hersteller - zukommt. Ich habe mich durch die 338 Seiten Resolution und geänderten Gesetzestext gearbeitet. Die ganz kurze Zusammenfassung kommt hier, für die längere Version gibt es im Lesestoff 1 & 2 einen Blogartikel, wahlweise auf Deutsch oder Englisch.

Also los:

• Alle Produkte brauchen ein CE-Kennzeichen und müssen dafür die Konformität mit bestimmten "essential requirements" erklären.
• Die Liste von "important / critical entities", also Produkten, die eine Konformitätsbewertung durch Dritte durchführen lassen müssen, ist stark geschrumpft; insbesondere sind keine IIoT / IACS mehr drin. Für die meisten, insbesondere für die meisten OT-Hersteller, wird eine Selbsterklärung ausreichen.
• Die Anforderungen ("essential requirements") müssen aber alle umsetzen. Es sind generische Anforderungen an Security by Design, Incident Readiness und Schwachstellenmamagement. Details werden harmonisierte Normen klären.
• Eine technische Dokumentation muss alle Informationen sammeln, die die Konformität mit den "essential requirements" ermöglichen und belegen - insbesondere eine Risikoanalyse (prominenter verankert als im Entwurf von 2022). Die Dokumentation ist nicht öffentlich, Einsicht kann aber unter Umständen durch die Marktaufsichtsbehörde (in D wohl BSI / BNetzA) gefordert werden.
• Eine Nutzeranleitung, damit der Nutzer weiß, wie er das Produkt sicher nutzen muss. Wichtigste Funktionen, Security-Features, notwendige Konfigurationen, Installation von Updates, Änderungen, die er lieber nicht machen sollte - quasi die "Security-Visitenkarte" des Produkts. Sowas gibt's bislang nicht, damit kann man security-bewusste Kunden richtig glücklich machen, wenn man das als Hersteller gut macht.

Das ist viel Dokumentation - klingt aber negativer als es ist (und für KMU gibt es Erleichterungen). Denn wie auch NIS2 ist die CRA-Regulierung darauf ausgerichtet, dass man sich ordentlich Gedanken um Cybersecurity macht und das dokumentiert - und weniger darauf, dass man sehr spezifische Anforderungen umsetzen muss (von Meldepflichten für Security-Vorfälle und verpflichtenden Security-Updates mal abgesehen). Wenn man also Security gut machen möchte, lässt einem der CRA Raum dafür und erstickt einen nicht in Bürokratie. Und die technische Dokumentation, insbsondere die verpflichtenden "user instructions" sind eine Riesenchance, richtig Sympathie- und Vertrauenspunkte bei Kunden zu sammeln.

Übrigens gibt es eine interessante Umfrage von der ECSO, der gemeinnützigen "European Cyber Security Organisation", zu Herausforderungen, die Produkthersteller bei der Umsetzung des CRA sehen. Link zur Studie im Lesestoff 3 - ich habe die Ergebnisse bei LinkedIn kurz zusammengefasst.

2. Freiwilliges Security-Label für IoT: USA führen Cyber Trust Mark ein

Die Frage danach, wie Cybersecurity am besten für Käufer bzw. Nutzer transparent gemacht werden kann, gewinnt momentan weltweit an Momentum - auch mit konkreten Antworten.

Der Cyber Resilience Act (CRA) ist nun durchs EU-Parlament, und auch aus den USA gibt es Neuigkeiten:
Die Federal Communications Commission (FCC) hat im März dafür gestimmt, dass es ein Cybersecurity-Label für IoT-Geräte geben soll.

Die Fakten:

• Das Label ist freiwillig (das unterscheidet es vom CRA)
• Die EU hat eine Vereinbarung mit den USA für eine gemeinsame Roadmap für ein Cybersecurity-Labeling-Programm unterzeichnet (die Labels sollen also in der EU anerkannt werden). Solche Vereinbarungen gibt es auch mit weiteren Ländern.
• Das Cyber Trust Mark soll das Vorhandensein von "Baseline Security Requirements" bescheinigen, und weitere Informationen bereitstellen (z.B. ob es automatische Security-Updates gibt und für wie lange).
• Die genauen Anforderungen scheinen noch nicht ganz klar zu sein, auf der offiziellen Seite des Cyber Trust Marks werden quer durchs Gemüsebeet alle weltweit relevanten Standards verlinkt (darunter ISA/IEC 62243 und ETSI EN 303 645)
• Die Erfüllung der "Baseline Controls" soll von akkreditierten Prüflaboren überprüft werden.
• Es gibt ein Early-Adopter-Programm, bei dem sich Hersteller schon bewerben können

Drei Informationen sind in dem Kontext auch noch wichtig:

1. In Deutschland gibt es auch ein freiwilliges Security-Label - das IT-Sicherheitskennzeichen - allerdings bislang nur für vier ausgewählte Produktkategorien. Mit "smarten Verbrauchergeräte" ist IoT aber darunter.
2. Mit dem internationalen Standard ISO/IEC 27404 wird gerade ein "cybersecurity labelling framework for consumer IoT" erarbeitet. Das Vorhaben wurde von Singapur initiiert.
3. Die EU arbeitet mit dem EUCC an einem Cybersecurity Certification Scheme based on Common Criteria. Ein Zertifikat nach diesem Schema soll unter anderem als Konformitätsbewertungsverfahren für den Cyber Resilience Act gelten.

Links zum Cyber Trust Mark im Lesestoff: Bericht bei Nextgov (Lesestoff 1) und die offizielle Seite des Cyber Trust Mark (Lesestoff 2).

3. UNECE R155/156 gelten ab Juli: VW und Porsche stellen wegen Cybersecurity-Vorgaben beliebte Modelle ein

Nur wegen Cybersecurity hat noch niemand einen Produktionsprozess verändert? VW und Porsche jetzt schon.... Der VW Up und T6.1 sowie drei Porsche-Modelle werden ohne direkten Nachfolger eingestellt "wegen strengeren EU-Vorgaben zur Cybersicherheit".

Es gibt jede Menge Presseartikel dazu, jedoch sind die fast alle eine 1:1-Kopie der dpa-Meldung, und in der wird noch nicht mal erwähnt, um welche Vorgaben es sich eigentlich handelt, geschweige denn was genau sie fordert (soviel zum Thema Cybersecurity-Berichterstattung). Übrigens klingen die meisten Artikel im Subtext etwa so: "Superbeliebte Auto-Modelle wurden nur wegen EU-Bürokratie und überzogener Cybersecurity eingestellt".

Ich habe also mal ein bisschen gegraben und folgende Fakten gefunden:

• Es geht um die UNECE R 155, eine UN-Regulierung zu "Cyber security and cyber security management system" (Lesestoff 1). Es gibt auch noch die UNECE R 156 "Software update and software update management system" (Lesestoff 2).
• Wohlgemerkt sind das UN-Regulierungen....die EU ist also ausnahmsweise mal unschuldig.
• Die R 155 ist am 22.01.2021 in Kraft getreten.
• Für Fahrzeuge, die ab Juli 2024 zugelassen werden (für Wohnmobile etwas später), muss es während der Entwicklung ein extern geprüftes Cyber Security Management System (CSMS) gegeben haben.
• Mit "CSMS" meint die R 155 vor allem, dass es eine Security-Risikoanalyse gegeben haben muss: "Cyber Security Management System (CSMS)" means a systematic risk-based approach defining organisational processes, responsibilities and governance to treat risk associated with cyber threats to vehicles and protect them from cyber-attacks."
• Weil man ja nun mal kein CSMS "im Nachhinein" einführen kann für bereits entwickelte Autos, gibt es Übergangsregelungen: "However, for type approvals prior to 1 July 2024, if the vehicle manufacturer can demonstrate that the vehicle type could not be developed in compliance with the CSMS, then the vehicle manufacturer shall demonstrate that cyber security was adequately considered during the development phase of the vehicle type concerned."

Drei Gedanken dazu:

1. Spannend, dass die UNECE R 155, offenbar schon seit 2021 öffentlich, so wenig Aufmerksamkeit bekommen hat. Immerhin ist sie eine waschechte Markteintrittshürde für Produkte (Autos) aufgrund von Cybersecurity und fordert verpflichtend Security by Design - 3 Jahre vor dem CRA.
2. Eigentlich überraschend, dass nur VW und Porsche Modelle einstellen mussten. Heißt im Umkehrschluss, bei allen anderen ist so etwas wie eine Security-Risikoanalyse während der Entwicklung nachweisbar - oder es werden Modelle eingestellt und Cybersecurity wird nicht als Grund benannt (so passiert bei Audi, Renault, Mercedes-Benz und Smart).
3. Die Übergangsregelung ist recht großzügig: "demonstrate that cyber security was adequately considered" klingt dehnbar. Solang man sich irgendwie während der Entwicklung über Security Gedanken gemacht hat, sollte das machbar sein. Das war für den seit 2011 gebauten VW Up, den auf dem T5 von 2003 aufbauenden VW T6.1, und die seit 2014 bzw. 2016 gebauten Porsche-Modelle offenbar nicht möglich.

Für viele gute Ergänzungen empfehle ich die Lektüre der Kommentare dieses LinkedIn-Posts.

4. 2 Jahre Krieg: Rückblick auf hybride Kriegstaktiken beim russischen Einmarsch in die Ukraine

Am 24. Februar hat sich der russische Einmarsch in die Ukraine zum zweiten Mal gejährt.

Zu diesem Anlass habe ich mit dem stellvertretenden FDP-Fraktionsvorsitzenden und niedersächsischen FDP-Vorstand Konstantin Kuhle auf Einladung der Leuphana-Universität Lüneburg über hybride Kriegsführung diskutiert.

Moment, das war ein hybrider Angriff?
Jepp - auch wenn wir das in Deutschland vor allem mitbekommen wegen Schlagzeilen wie "Krieg in der Ukraine stört deutsche Windkraftanlagen". Wenn Sie damals schon unser Schutzhelmbriefing gelesen haben, wissen Sie, was da los war.
Für alle anderen habe ich es im Blog (Lesestoff) noch einmal zusammengefasst. Der Angriff ist nämlich ein prima Anschauungsbeispiel für die besonderen Charakteristika von Cyber-Angriffen als Teil von militärischen Auseinandersetzungen.

Fünf Beobachtungen:

1. Digitale Kommunikation ist eine komplexe kritische Infrastruktur.
   Wir sind immer vernetzter und die digitale Kommunikation wird immer wichtiger. Ohne Internet geht gar nichts mehr. Das macht Kommunikationsinfrastruktur zu einem attraktiven Ziel. Und wer hätte gedacht, dass es ein Bindeglied zwischen ukrainischer Militärkommunikation und deutschen Windkraftanlagen gibt?
2. Cyber-Angriffe sind ineffizient — aber hybride Angriffe sind sehr effizient.
   Mit Cyber-Angriffen wirklich physisch etwas kaputt zu machen, ist gar nicht so einfach. Wollte man mit einem Kriegsakt ein Windrad zerstören, wäre es wohl einfacher, eine Bombe darauf zu werfen. Lediglich Kommunikation zu stören ist aber vergleichsweise leicht. Als Teil hybrider Angriffe sind Cyber-Angriffe daher hoch effizient.
   So auch beim russichen Einmarsch in die Ukraine: Während eines physischen Angriffs ist es sehr praktisch, wenn der ohnehin überrumpelte Gegner auch noch ohne seine Kommunikationssysteme auskommen muss.
3. Ziel von Cyberwaffen sind meist kritische Infrastrukturen oder Desinformation.
   Bei hybrider Kriegsführung geht es immer um die Destabilisierung der Bevölkerung. Daher sind kritische Infrastrukturen wie Strom- und Wasserversorgung, deren Ausfall die Bevölkerung unmittelbar zu spüren bekommt, interessante Angriffsziele für Cyber-Angriffe.“Hybride Kriegsführung” umfasst nicht nur Cyber-Angriffe, sondern auch Desinformation und finanzielle Beeinflussung. Alles wunderbare unterstützende Mittel, um neben einem physichen Angriff die Stimmung zu lenken oder aufzuheizen.
4. Cyber-Angriffe haben hohe Streuverluste, was Kollateralschäden wahrscheinlich macht.
   Es ist ziemlich aufwendig, Cyber-Angriffe auf die eigentlich Zielsysteme zu begrenzen, denn dann muss man vorher genau wissen, welche Zielsysteme eigentlich wofür da sind.
   Dass die falschen Systeme getroffen werden, passiert dementsprechend oft - und wird in Kauf genommen. Nicht nur während des russichen Einmarschs in die Ukraine, bei dem die Fernwartung der deutschen Windräder nur ein Kollateralschaden waren, sondern auch in vielen anderen Beispielen. Beim Angriff auf die Düsseldorfer Uniklinik beispielsweise wollten die Angreifer eigentlich die Düsseldorfer Uni treffen.
5. Cyber-Angriffe haben fast immer Auswirkungen auf die Zivilbevölkerung.
   Das ist die bittere Folge aus den vier bisherigen Punkten. Das eigentliche düstere Szenario des “Cyberwars” ist also weniger das totale "Blackout". Das düstere Szenario ist, dass Cyber-Waffen die Wahrscheinlichkeit erhöhen, dass Kriegshandlungen Auswirkungen auf Zivilisten haben.

Kein Wunder also, dass seit Jahren immer wieder die Forderung einer “Genfer Konvention für den Cyberspace” laut wird...
Die Langfassung der fünf Punkte und Beschreibung des Anschauungsbeispiels finden Sie im Lesestoff.

5. Chinesische Angriffe auf kritische Infrastrukturen: I-Soon, Volt Typhoon und Hafenkräne

Oft hört man zu Cybersecurity-Angriffen ja vor allem "die Russen waren's". Dabei ist Russland bei Weitem nicht der einzige staatliche Akteur im Bereich der Cyber-Angriffe, wie gleich drei Ereignisse der letzten Wochen zeigen:

1. I-Soon Leaks:
Auf Github gab es im Februar einen großen Daten-Leak der chinesischen Cybersecurity-Firma I-Soon. Wenn die Dateien echt sind, belegen sie, dass der chinesische Staat der Firma fünfstellige Summen dafür zahlt, dass Hacker in Computersysteme zum Beispiel der Nato oder Außenministerien verschiedener Staaten einbrechen, um potenziell interessante Informationen zu stehlen.
Ein britischer Cybersecurity-Experte der University of Surrey kommentiert gegenüber dem Guardian (Lesestoff 1), dass er bei China im Gegensatz zu Russland eine andere Strategie bei den Angriffen beobachte. Während Russland vor allem mit Ransomware-Angriffen und dem Ziel der Störung von Infrastruktur auffiele (siehe Notizen zum Einmarsch in die Ukraine oben), kozentriere China sich offenbar darauf, massenhaft Daten zu sammeln - die aber durchaus als Basis für spätere, zerstörerische Angriffe genutzt werden könnten.
Bemerkenswert ist laut einem Kommentar der Ostasien-Cybersecurity-Forscherin (ja, das gibt's) Mei Danowski, dass es offenbar unter chinesischen Cybersecurity-Firmen einen regen Wettbewerb um das staatliche Geld gibt: "We think about [Chinese hackers] as ‘Oh, the state gives them cash to do stuff.’ In reality, if these leaked documents are true, it’s not like that. They have to go and look for business. They have to build up a reputation.”
Vielleicht auch ein Unterschied zu Russland: Dort sind es vor allem staatlich finanzierte Elite-Hacking-Truppen wie Sandworm, die die Angriffe ausführen. In China bewerben Cybersecurity-Unternehmen ihre Hacking-Dienste und die Regierung wählt daraus aus - und der Preis ist dabei durchaus ein Argument.

2. Volt Typhoon:
Ebenfalls im Februar haben die Security-Behörden der USA, Kanada, Australien und Großbritannien gemeinsam ein Security Advisory veröffentlicht (Lesestoff 2), in dem vor den Aktivitäten der staatlichen chinesischen Hackergruppe Volt Typhoon gewarnt wird. Die Hacker seien in IT-Systeme kritischer Infrastrukturen eingedrungen, und die US-Behörden schätzen die Aktivitäten als Vorbereitungen auf Angriffe auf die OT ein, um die Funktion kritischer Infrastrukturen zu stören.
Die Hackergruppe verhalte sich anders als bekannte Hackergruppen, führt das Advisory weiter aus. Insbesondere werden verstärkt "Living off the Land"-Techniken verwendet. "Living off the Land" heißt wörtlich übersetzt so viel wie "von dem Leben, was die Natur einem bereitstellt". Auf Cyber-Angriffe übertragen ist natürlich nicht die Natur, sondern die bestehende IT-Infrastruktur gemeint: Angreifer installieren keinen neuen Schadcode, sondern nutzen Bordmittel von Betriebssystemen und Anwendungen für ihre Angriffe - zum Beispiel PowerShell oder netstat. Das macht die Erkennung der Angriffe schwieriger.

3. Chinesische Hafenkräne von ZPMC:
Fast zeitgleich mit dem I-Soon-Leak und dem Volt Typhoon-Advisory wurde ein sehr reales Szenario (wieder) öffentlich diskutiert, wie ein chinesischer Cyber-Angriff den USA tatsächlich schaden könnte:
Anlass ist eine ebenfalls Ende Februar veröffentlichte Executive Order der US-Regierung, die Behörden bemächtigt, Cybersecurity in US-Häfen zu "verbessern", außerdem werden 20 Milliarden Dollar in Hafeninfrastruktur gesteckt. Unter anderem sollen damit Anreize geschaffen werden, Hafenkräne in den USA - und nicht mehr in China - zu produzieren.
Worüber ist die Regierung besorgt?
Admiral Jay Vann vom US Coast Guard Cyber Command, erklärt es in der Pressekonferenz zum Executive Order so (Lesestoff 3): 80 % der Hafenkräne in den USA und auch weltweit die Mehrheit aller Hafenkräne kämen aus den USA. Diese Kräne können über digitale Verbindungen ferngesteuert werden, und das sei ein Angriffspotential.
Das Weiße Haus kommentiert dazu, Cyber-Angriffe könnten genauso gefährlich für Häfen werden wie Stürme, kann man im NPR-Kommentar dazu lesen.
Die Cybersecurity-Beraterin des Weißen Hauses, Anne Neuberger, konkretisiert, wovor die Regierung Angst hat: Auf das amerikanische Hafen- und Wasserstraßensystem entfallen über 5,4 Billionen Dollar der jährlichen Wirtschaftstätigkeit der USA. 90 % des gesamten Überseehandels erfolgt über den Seeweg. Es geht also weniger um das Sicherheitsrisiko, dass einem Hafenmitarbeiter ein Container auf den Kopf fällt (das wäre per Fernsteuerung auch schwierig zu erwirken, denn dafür gibt es in der Regel auch mechanische Schutzvorrichtungen), sondern darum, dass Chaos in den Häfen entsteht und der Handel lahmgelegt wird.
Das Bedrohungsszenario an sich ist wohl realistisch: Im Executive Order geht es vor allem um die "ship-to-shore"-Kräne, die Container zwischen Hafen und Schiffen hin- und herbewegen. Wenn man mit Automatisierern in Häfen spricht, ist für sie die Möglichkeit, dass Container chaotisch abgestellt werden und nicht mehr auffindbar sind oder nicht mehr zugeordnet werden können, ein Schreckensszenario, das zum Totalstillstand führen kann. In einem Handelskrieg zwischen den USA und China wären die Kräne also eine mächtige Waffe.
Der Weltmarktführer für Hafenkräne, Shanghai Zhenhua Heavy Industries (ZPMC), widerspricht den Befürchtungen natürlich. Man halte sich an die Gesetze seiner Zielmärkte, die Medienberichte zu den Bedrohungsszenarien seien irreführend. Ähnlich äußert sich die American Association of Port Authorities (AAPA): Kräne seien nicht in der Lage, Herkunft, Ziel und Inhalt der Ware in den Containern nachzuvollziehen. Stimmt wohl, aber das ist ja auch nicht das Bedrohungsszenario, um das es geht.
Ist die Sorge vor chinesischen Hackerangriffen paranoid? Oder wäre es blauäugig, sich nicht zu sorgen? Die Frage erinnert an die Huawei-Debatten, die in den USA genauso wie in Deutschland geführt werden. Vor dem Hintergrund von I-Soon und Volt Typhoon wären Paranoia zumindest nicht aus der Luft gegriffen.

6. US-CISA (Äquivalent zum deutschen BSI) wurde gehackt

Man stelle sich vor, das BSI wurde Opfer eines Cyberangriffs. Das Äquivalent dazu ist in den USA im Februar passiert, wie im März bekannt wurde: die Cybersecurity & Infrastructure Security Agency der USA (CISA), wurde gehackt (Lesestoff).

Bekannte Fakten:

• es wurden Aktivitäten im Netzwerk bemerkt, die eine Schwachstelle in einer VPN-Lösung des Herstellers Ivanti ausnutzen.
• die CISA hat daraufhin "zwei wichtige Systeme sofort offline genommen" - es gibt keine offizielle Bestätigung, welche genau, nur Spekulationen darüber, dass sie security-relevante Informationen kritischer US-Infrastrukturen beinhalten könnten. Ob die Angreifer diese Informationen gesehen oder sonst etwas damit getan haben, ist ebenfalls nicht öffentlich bekannt (CISA hat Fragen danach nicht beantwortet).
• die Ivanti-Schwachstelle war bekannt, es gab sogar ein CISA-Advisory dazu. Aber das Ivanti-Tool, mit dem man herausfinden sollte, ob die Schwachstelle im eigenen Netz ausgenutzt worden war, hatte Lücken.
• Sprecher der CISA sagen, es gebe bislang keine bekannten Auswirkungen auf den Betrieb.

Klar: Wenn eine Organisation voller Security-Experten, die anderen Security-Ratschläge erteilt, gehackt wird, ist das eine Steilvorlage.
Es ist dabei immer leicht, Kommentare zu schrieben, die

• hämisch urteilen, die CISA könne wohl nicht einmal die eigenen Advisories umsetzen,
• eine "Signalwirkung" herbeifabulieren, wenn "sogar die CISA" gehackt werde,
• über Auswirkungen auf kritische Infrastrukturen spekulieren,
• die Kompetenz der Behörde oder von Security-Behörden im Allgemeinen in Frage zu stellen, oder
• ein weiteres Zeichen für die (angeblich) katastrophale Lage der Security unserer Gesellschaft und ihrer kritischen Infrastrukturen sehen.

Solche Kommentare sind meist vor allem ein Einblick in die Agenda des Kommentarschreibers, denn man kann das Ganze aber auch ausgeruhter sehen:
Dass Organisationen mit viel Security-Expertise den sportlichen Ehrgeiz von Angreifern in besonderem Maße wecken, versteht sich von selbst.
Dass auch bei Organisationen mit viel Security-Expertise Angriffe erfolgreich sein können, ist jedem klar, der sich mit Cybersecurity beschäftigt: Wenn Angreifer wirklich wollen, finden sie einen Weg. Wichtig ist, dass man dann schnell reagiert und die Auswirkungen begrenzt - und das ist bei der CISA geschehen, glaubt man den spärlichen öffentlich bekannten Infos.

Wenn man wollte, könnte man den Angriff sogar als Bestätigung der Wichtigkeit der CISA-Arbeit interpretieren: Immerhin basiert er auf einer Software-Lücke in einem Produkt - und die CISA macht mit ihren Security-by-Design-Veröffentlichungen seit Monaten intensiv auf das Problem der mangelnden Herstellerverantwortung für Schwachstellen aufmerksam...

7. NIST Cybersecurity Framework 2.0

Nach all den Deep Dives kommen uum Schluss noch zwei schnellere Meldungen.
Hier die erste: Nach 10 Jahren hat das NIST Cybersecurity Framework (CSF) ein Update bekommen. Das NIST CSF hat und hatte großen Einfluss darauf, wie Menschen in ihren Köpfen Cybersecurity-Anforderungen sortieren. Es ist vielleicht der umfangreichste Anforderungskatalog, den es gibt. Es ist auch eine Art Meta-Katalog mit Mappings zu zahlreichen anderen Anforderungskatalogen, zum Beispiel denen der ISA/IEC 62443-Reihe.

Am prominentesten im Gedächtnis (und wohl am meisten zitiert) sind die fünf Kategorien, in die das CSF die Maßnahmen einsortiert: Identify, Protect, Detect, Respond, Recover, wobei jede Kategorie eine knallige MS-Word-Standardfarbe hat.
Dementsprechend spektakulär ist, dass es im CSF 2.0 nun eine sechste Kategorie gibt: Govern. Sie enthält all das, was man in organisatorische Prozesse gießen muss. Das passte bislang nicht so richtig gut in die Kategorien.

Damit zeichnet das NIST CSF auch eine Entwicklung nach, die Cybersecurity im letzten Jahrzehnt gemacht hat. Zunehmend haben sich die Standard-Lösungsansätze von einzelnen Maßnahmen hin zur Notwendigkeit eines Managementsystems entwickelt. Eine Triebfeder dafür war sicher auch die Vielzahl an Cybersecurity-Regulierungen, die seit 2014 in Kraft getreten sind, vor allem für kritische Infrastrukturen. Und in diesen Regulierungen wird meistens ein Managementsystem gefordert - "govern" in NIST CSF-Kategorien - denn das eignet sich besser für Überprüfungen und Zertifizierungen als technische Einzelmaßnahmen und lässt Unternehmen Freiheit bei der Wahl spezifischer Maßnahmen.

Das neue NIST CSF richtet sich im Gegensatz zur ersten Version nicht mehr nur an kritische Infrastrukturen. Und den "Core" (den großen Meta-Anforderungskatalog), gibt es neben Excel nun auch maschinenlesbar in JSON und in einem durchsuchbaren Online-Tool.

Es gibt jede Menge Ressourcen rund um das NIST CSF, aber wer ein Gefühl dafür gewinnen möchte, was das Framework ausmacht, dem empfehle ich einen Blick ins Herz: In den "Core". Link zur PDF-Version im Lesestoff. Auf Seite 15 gibt's die Links zum vollständigen Katalog, sowohl zum Web-Tool als auch zur vollständigen Excel-Tabelle (versteckt hinter dem Link "legacy format").
Die Referenzen auf andere Standards sind allerdings ziemlich gut versteckt - ich habe sie bislang nicht gefunden (für Hinweise bin ich dankbar).

8. Top 20 Secure PLC Coding Practices: Deutsche Übersetzung

Das Thema lag ja lange auf unserem Aufgabenstapel und wurde nicht so recht fertig: Die Top 20 Secure PLC Coding Practices endlich auch auf Deutsch übersetzen (nachdem es Chinesisch, Arabisch, Spanisch und Kroatisch schon gibt).
Dann kam im März aus dem Blauen eine E-Mail in meinem Postfach an: Hallo, hier ist Rudolf Preuss, ich habe die Top 20 übersetzt, wollt ihr das auf die Projektwebsite hochladen?

Aber holla, natürlich wollen wir. Dickes Danke an Rudolf Preuss für die Arbeit und das Teilen. Es ist sehr schön zu sehen, dass die Freiwilligen-Community rund um die Top 20 weiterhin lebendig ist. Wer mitmachen möchte - wir haben zu viele tolle Ideen und zu wenig Kümmerer - kann gern eine E-Mail an plc-security-at-admeritia.de schicken!

Die deutsche Übersetzung ist natürlich im Lesestoff verlinkt.

Stay secure!
Sarah Fluchs