Während ich die Themen für das August-Briefing gesammelt habe, fing mein Kopf an zu rauchen: RCE, NIS2, CRA, Kritis-Dachgesetz, NIS2UmsuCG - alles gerade irgendwie aktuell, ständig tauchen neue inoffizielle Entwurfsversionen zu Cybersecurity-Gesetzestexten auf. Daher erschien es mir passend, dass wir das Hard-Hats-Briefing in diesem Monat nutzen, um mal ein wenig aufzuräumen im Gesetzesdschungel. Wenig überraschend nehmen diese Aufräumarbeiten einen Großteil des Briefings ein. Zur Auflockerung schauen wir gegen Ende dann noch darauf, was Russlands wichtigster Hacker in seine Masterarbeit schreibt. Und dann habe ich noch einen Terminhinweis für nächste Woche. 

Also: Der dickste Brocken in diesem Briefing kommt gleich zu Anfang - dann wird's leichter, versprochen. Legen wir los.

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

1. Regulierungsmarathon in EU und D: Kritis-Dachgesetzes, NIS2-Umsetzung, CRA
2. Was ist sicherer - Open Source oder proprietäre Software?
3. Business Continuity Management - der neue BSI-Standard 200-4 ist da
4. Die Masterarbeit von Russlands wichtigstem Hacker
5. Nächste Woche: OT Cybersecurity Expert Panel Forum

1. Regulierungsmarathon in EU und D: Kritis-Dachgesetz, NIS2-Umsetzung, CRA

Momentan jagt ja ein neues Cybersecurity-Gesetz das nächste. Letzten Monat war es das NIS2-Umsetzungsgesetz (NIS2UmsuCG), das als Referentenentwurf veröffentlicht (oder besser: durchgestochen) wurde. Diesen Monat ist es das Kritis-Dachgesetz.

Dass das Durchstechen immer früherer Gesetzesentwürfe mittlerweile normal geworden ist, stößt übrigens nicht nur auf Begeisterung. Der Tagesspiegel zitiert den stellvertretenden Fraktionsvorsitzenden der Grünen, Konstantin von Notz, mit den Worten: "Dass bereits ein erster Referentenentwurf [des Kritis-Dachgesetzes] in Hintergrundgesprächen an Journalistinnen und Journalisten verteilt wird, noch bevor er den Fraktionen des Parlaments vorliegt, ist äußerst bedauerlich."

Aus Anwendersicht ist das frühe Bekanntwerden der Entwürfe ein zweischneidiges Schwert. Einerseits bekommen Betroffene eher mit, wohin die Regulierungs-Reise geht - und haben möglicherweise noch Chancen zur Einflussnahme. Ein häufiger Kritikpunkt bei der Kritis-Gesetzgebung ist, dass die Meinung von Verbänden und Betroffenen nicht ausreichend gehört würde.
Andererseits sind Entwürfe ja aus gutem Grund nur Entwürfe - nichts darin ist final. Wenn frühzeitig öffentliche Diskussionen an noch nicht ausgefeilten Formulierungen oder nicht mehrheitsfähigen Ideen entbrennen, hilft das nicht bei der sachlichen Verhandlung der Gesetzestexte. Außerdem kursieren mittlerweile oft so viele verschiedene Entwurfsversionen, die von so vielen gut oder weniger gut informierten Experten (und Verkäufern von Security-Lösungen) kommentiert werden, dass es fast unmöglich wird, den Überblick zu behalten.

Zur Abwechslung schenken wir uns heute mal die inhaltliche Diskussion der "ungelegten Eier". Stattdessen räumen wir mal unsere schwirrenden Köpfe gemeinsam ein wenig auf, um besser gewappnet in die vielen Entwurfs- und Diskussionrunden zu gehen, die noch kommen werden. Denn: Ich muss ehrlicherweise auch jedes Mal wieder nachschauen, um was genau es denn jetzt noch mal in welchem Gesetz ging und welche EU-Richtlinie durch welches nationale Gesetz umgesetzt wird...

Dabei hilft ein kleines Bild:

Cybersecurity-Gesetzgebung in Deutschland entsteht meist aus der Umsetzung einer EU-Richtlinie in nationales Recht, und sie ist (bislang) immer Gesetzgebung für kritische Infrastrukturen (zusätzliche branchenspezifische Richtlinien zum Beispiel für Störfallbetriebe, die Bahn oder Automobilhersteller lassen wir hier der Einfachheit halber außen vor.)
Das Ganze begann 2008 mit der ECI-Richtlinie, die die EU-Mitgliedsstaaten verpflichtete, kritische Infrastrukturen zu identifizieren. Man begann damals mit den beiden Sektoren Energie und Transport, und Deutschland hat die Richtlinie 2011 in mit einem Gesetz und einer Verordnung umgesetzt. Mit der Cybersecurity ging es dann erst so richtig los, als 2016 die NIS-Richtlinie beschlossen wurde. Wir erinnern uns: Danach kam das deutsche IT-Sicherheitsgesetz (IT-SiG), und plötzlich mussten Betreiber kritischer Infrastrukturen alle zwei Jahre einen Nachweis über Ihre Security erbringen. Welche Betreiber betroffen sind, regeln Kritis-Verordnungen - und da kommen schubweise Sektoren hinzu. Es gab einen ersten Schwung Sektoren, der 2018 erstmals Nachweise erbringen musste und einen weiteren, der 2020 erstmals fällig war.
2021 trat dann das IT-Sicherheitsgesetz 2.0 (IT-SiG 2.0) in Kraft (als ein Teil des BSI-Gesetzes, BSIG), bei dem sowohl Sektoren als auch Anforderungen hinzukamen - viel beachtet zum Beispiel die "Uniböfi" (Unternehmen im besonderen öffentlichen Interesse und die "SzA" (Systeme zur Angriffserkennung). Mit dem IT-SiG 2.0 hat die Bundesregierung einigen Anforderungen der NIS2-Richtlinie, die damals schon unterwegs, aber noch nicht verabschiedet war, bereits vorgegriffen.

So, und nun sind wir bei dem Regulierungsmarathon angekommen, über den momentan alle schreiben. Alles oberhalb der roten Linie im Bild oben ist bereits in Kraft, bei allem unterhalb der Linie diskutieren wir über Entwurfsfassungen. Insgesamt ist es eine deutliche Verbreiterung und Vertiefung der bestehenden Cybersecurity-Regulierung:

Die RCE-Richtlinie (schon in Kraft) ersetzt die ECI-Richtlinie von 2008. Dabei geht es um die "Resilienz kritischer Entitäten" - man könnte auch sagen: Um allgemeine, der Cybersecurity übergeordnete Resilienz. Es werden natürlich mehr Sektoren als kritische Infrastrukturen definiert als in der Version von 2008 - das war aber mit der NIS-Richtlinie ohnehin schon geschehen. Es gibt nur kleine Abweichungen gegenüber den in den NIS- bzw. NIS2-Richtlinien definierten Sektoren.
Spannender ist die Definition von übergreifenden Maßnahmen, die die Resilienz, also die Ausfallsicherheit der kritischen Dienstleistungen sicherstellen sollen: etwa Risikoanalysen, Notfallmanagement, Alarmierung und Business Continuity, physische Sicherheit undPerimeterschutz und Sicherheitsüberprüfungen des Personals.

Die NIS2-Richtlinie (ebenfalls schon in Kraft) ersetzt die NIS-Richtlinie von 2016. Dabei geht es um Cybersecurity für kritische Infrastrukturen, also das, was bislang in den Versionen des IT-Sicherheitsgesetzes geregelt war - aber es sind mehr Betreiber betroffen (kleinere Organisationen, mehr Sektoren) und es kommen zusätzliche Security-Anforderungen hinzu, beispielsweise für die Security der Lieferketten.

Wenn man diese Unterscheidung kennt - RCE-Richtlinie für die allgemeine Resilienz, NIS-Richtlinie für die Cybersecurity - leuchtet auch die Übersetzung in deutsches Recht direkt ein.
Das NIS2UmsuCG (NIS2-Umsetzungsgesetz) erweitert die im IT-Sicherheitsgesetz schon getroffenen Regeln zur Cybersecurity. Das Kritis-Dachgesetz ist ziemlich genau das, was der Titel sagt: Es betrifft alle übergeordneten Maßnahmen, die kritische Infrastrukturen zusätzlich zur Cybersecurity treffen müssen. Es setzt sozusagen ein Dach mit allgemeiner Resilienz über die bestehende Cybersecurity-Regulierung für kritische Infrastrukturen.

Und dann gibt es ja noch den Cyber Resilience Act (CRA). Der macht ein ganz neues Fass auf: Er adressiert nicht Cybersecurity für Betreiber kritischer Infrastrukturen, sondern für Produkthersteller - ganz allgemein, unabhängig von der KRITIS-Regulierung.

Also, fassen wir zusammen: Momentan geht es um Verbreiterung und Vertiefung der bestehenden Cybersecurity-Gesetzgebung:

• Verbreiterung 1 (RCE-Direktive und Kritis-Dachgesetz): Betreiber kritischer Infrastrukturen müssen zusätzlich zu Cybersecurity nun auch allgemeine Maßnahmen gegen Ausfallsicherheit ergreifen.
• Vertiefung (NIS2-Direktive und NIS2UmsuCG): Die Cybersecurity-Anforderungen für die Betreiber kritischer Infrastrukturen werden ergänzt.
• Verbreiterung 2 (CRA): Hersteller müssen nun auch Cybersecurity-Anforderungen erfüllen.

Mit Ihrem nun aufgeräumteren Kopf schicke ich Sie nun los, um nach Herzenslust Entwürfe und Kommentare zu Entwürfen der drei Gesetzestexte "unter der roten Linie" zu lesen. Sie können ja nun einordnen, worum es geht. Sie dürfen auf alle Texte mit einer ordentlichen Portion Gelassenheit schauen, denn es kann sich grundsätzlich noch alles daran ändern.

Voilà, hier ist Ihr Lesestoff-Berg:

1. RCE und Kritis-Dachgesetz: Gesetzes-/Entwurfstexte (Lesestoff 1 und 2), juristischer Kommentar bei beck (Lesestoff 3), inhaltlicher Kommentar bei heise (Lesestoff 4).
2. NIS2 und NIS2UmsuCG: Gesetzes-/Entwurfstexte (Lesestoff 5 und 6), einen Kommentar hatte ich im Juli-Briefing bereits verlinkt.
3. CRA: Entwurfstext (Lesestoff 7), Erklärtext (Lesestoff 8), die aktuelle Debatte hatte ich im Juni-Briefing bereits zusammengefasst.
4. Kurze Zusammenfassungen aller obenstehenden Gesetze außer dem CRA finden Sie bei OpenKRITIS (Lesestoff 9).

…und im Lesestoff 10 finden Sie diesen Text als Blog-Post – da ist das Bild größer und man kann den Link besser teilen.

2. Was ist sicherer - Open Source oder proprietäre Software?

Jetzt, da wir so schon aufgeräumte Köpfe haben, können wir noch ein paar lose Fäden einsammeln. Zum Beispiel zum Cyber Resilience Act: Da hatten wir schon im Juni besprochen, dass eines der ganz großen ungelösten Probleme die Security von Open-Source-Software ist. Denn wen soll man bei Open-Source-Software verpflichten, Security-Updates bereitzustellen?

Open-Source-Verfechter argumentieren gern, die freie Software wäre ohnehin sicherer, da ja jeder auf den Quellcode schauen könne - und viele Augen haben auch eine größere Chance, Schwachstellen zu entdecken. Soweit die Theorie.

Die Security-Vor- und Nachteile von Open-Source-Software und proprietärer Software hat nun eine Vergleichsstudie beleuchtet. Erwähnenswert ist dabei wie so oft ihr Autraggeber: Die Open Source Business Alliance (OSBA) dürfte ein besonderes Interesse an bestimmten Ergebnissen haben.

Trotzdem erscheint das Fazit der Studie ausgewogen, ja sogar diplomatisch: Beide Entwicklungsmodelle ließen sich ohnehin nicht mehr voneinander trennen, schreibt Autor Dr. Mark Ohm von der Universität Bonn - denn auch proprietäre Software enthalte mittlerweile zunehmend Open-Source-Anteile. Wie Security in die Entwicklung zu integrieren sei, sei außerdem für beide Modelle identisch, stellt der Autor weiter fest - aber für Open Source lassen sich sowohl Secure Coding Practices als auch Qualitätsmetriken ob der Quellcodeoffenheit besser überprüfen.
Wichtig sei aber, dass eine treibende Institution hinter dem Open-Source-Projekt stehen müsse, um die Security-Anforderungen zu koordinieren und durchzusetzen - und hier könnte Open-Source-Software im Nachteil sein, wenn sie keinen mächtigen Treiber wie Google, Meta oder Microsoft hat.

Man könnte zusammenfassen: Bei den am Code messbare Qualitätsmetriken ist aufgrund der Quellcodenoffenheit Open Source im Vorteil, bei der Durchsetzung und Kontrolle von Secure Coding Practices aufgrund des organisatorischen Durchgriffs eher proprietäre Software - es sei denn, das Open-Source-Projekt hat einen mächtigen Treiber. Aber das ist mein Fazit, nicht das des Autors.

Wenn Sie sich Ihr eigenes Fazit bilden wollen: Die Studie ist - wie man es von Open-Source-Fans erwarten darf - frei verfügbar (Lesestoff 1).

Und wer haftet nun für die Security von Open-Source-Software?
Damit ist aber das Kernproblem noch nicht gelöst: Wer sorgt denn nun für die Security von Open-Source-Software, also wen nimmt der Cyber Resilience Act in die Pflicht?

Denn wenn die Ersteller von Open-Source-Software keinen ausreichenden Durchgriff auf die eigenen Produkte haben - können sie dann für Security sorgen? Die OSBA argumentiert: Hersteller von Open-Source-Software könnten ihre Produkte, die außerhalb irgendwelcher Verträge frei herunterladbar und modifizierbar seien, nur indirekt kontrollieren und deswegen auch nicht für ihre Security haften.

Als Reaktion auf diese Kritik sieht der aktuelle Entwurf des CRA Ausnahmen für nicht-kommerzielle Open-Source-Produkte vor. 

Dazu hat die OSBA letzte Woche noch einmal Stellung genommen (Lesestoff 2).
Sie argumentiert, die Abgrenzung "kommerziell" und "nicht-kommerziell" sei gar nicht sinnvoll möglich:
"Der CRA strebt zwar eine Ausnahme für Open Source Software an, sofern diese nicht für kommerzielle Aktivitäten eingesetzt wird. Das Problem liegt allerdings in der konkreten Definition von „kommerziell“. Hier ist eine klare Abgrenzung schwierig und es ergibt sich ein zu großer Graubereich mit Interpretationsspielraum und dadurch eine Rechtsunsicherheit. Open-Source-Lösungen werden teilweise im Rahmen einer rein kommerziellen Aktivität (durch bezahlte Angestellte einer Firma mit kommerziellem Interesse), im Rahmen von Wissenschaft und Lehre, durch die öffentliche Verwaltung und teilweise auch durch tausende Freiwillige in Ihrer Freizeit, ohne eigenes kommerzielles Interesse entwickelt und gepflegt. Oft werden Open-Source-Lösungen auch im Rahmen einer Kooperation zwischen diesen verschiedenen Akteuren entwickelt, so dass sich eine klare Unterscheidung in „kommerziell“ und „nicht-kommerziell“ nicht immer so einfach vornehmen lässt."

Einen konkreten Vorschlag für den CRA hat die OSBA auch: Für Open Source sollen nicht die Ersteller der Software für die Security haften, sondern die "In-Vekehr-Bringer" - also jeder, der Open-Source-Software nutzt und auf ihrer Basis einen kommerziellen Dienst anbietet.

Der schwarze Peter läge damit bei den Nutzern von Open-Source-Software. Ob das förderlich für ihre Attraktivität ist?
Die Diskussion ist wichtig und verfolgenswert, selbst wenn man sich nicht für den Cyber Resilience Act interessiert. Denn der CRA ist ja nur Katalysator und Sichtbarmacher der lange schwelenden Grundsatzdiskussion, wie man Security eigentlich besser gewährleisten kann - mit proprietärer oder Open-Source-Software.

3. Business Continuity Management: Neuer BSI-Standard 200-4 ist da

Dann hätten wir da noch einen losen Faden zur RCE-Direktive beziehungsweise zum Kritis-Dachgesetz, den Sie nun mit Ihrem aufgeräumten Kopf hervorragend einfädeln können: Das BSI hat nämlich im Juni die Überarbeitung des Standards zum Business Continuity Management veröffentlicht.

Die Überarbeitung des Standards stand schon lange an. Bereits als 2017 die anderen drei BSI-Standards 200-1 (ISMS), 200-2 (IT-Grundschutz-Methodik) und 200-3 (Risikomanagement) im Rahmen der Komplettüberholung des IT-Grundschutzes neue Versionen erhielten, kündigte das BSI an, auch den vierten Standard - damals noch mit dem Namen "Notfallmanagement" überarbeiten zu wollen.

Die Überarbeitung kommt nun zeitlich passend, denn mit der RCE-Direktive werden demnächst viele Betreiber kritischer Infrastrukturen nach einer Anleitung suchen, wie sie das dort geforderte Notfallmanagement (bzw. schicker: "Business Continuity Management") umsetzen. Es wird kein Zufall sein, dass die Pressemitteilung des BSI zur Veröffentlichung das Wort der Stunde (und der RCE-Direktive) - Resilienz - prominent im Titel trägt.

Schon der nun abgelöste BSI-Standard 100-4 war eine viel genutzte Bank für den Aufbau eines Notfallmanagements. Sein Umfang hat sich mit dem neuen Standard 200-4 nun fast verdreifacht. Es sind keine grundlegend neuen Themen hinzugekommen, aber alle Anleitungen, Definitionen und Beschreibungen sind modernisiert und aktualisiert worden. Der ein oder andere wird die berühmten "Phasen der Notfall- und Krisenbewältigung" aus dem alten Standard vermissen...die viel zitierte Abbildung hat in der neuen Version deutlich an Detail eingebüßt - oder an Klarheit gewonnen, je nach Perspektive.

So oder so: So umfangreiche, deutschsprachige Anleitung zum Business Continuity Management - vieles davon ist übrigens auch auf die enger auf Cybersecurity-Vorfälle eingegrenzte Incident Response übertragbar - sucht ihresgleichen. Der detailverliebte IT-Grundschutz und seine Ausläufer (zu denen auch der Standard 200-4 zählt) wird hierzulande häufig belächelt - im Ausland werden wir dafür nicht selten beneidet, denn es ist gerade für kleinere Unternehmen viel wert, so detailliert an die Hand genommen zu werden.

Ach so - was ist eigentlich Business Continuity Management (BCM)? Lassen wir den Standard doch selbst sprechen: "Im Fokus des BCM liegen die zeitkritischen Geschäftsprozesse der Institution, die gegen Ausfälle abgesichert werden sollen."

Kurzum: Ein Blick in den Lesestoff lohnt sich.

4. Die Masterarbeit von Russland wichtigstem Hacker

Nach dem vielen Gesetzen und Standards schulde ich Ihnen noch etwas Abwechslung.

Hakan Tanriverdi, unser Keynote-Speaker bei Security unter Kontrolle 2023 und einer der wenigen auf (OT-)Cybersecurity spezialisierten deutschsprachigen Journalisten, ist während seiner Recherchen auf eine interessante Datei gestoßen: Die Masterarbeit von einem der wichtigsten Hacker Russlands, dem Kopf der russisch-staatlichen Hackergruppe "Sandworm", die unter anderem für Angriffe auf das ukrainische Stromnetz und Eingriffe in Wahlkämpfe bekannt sind.

Die Rede ist von Evgenii Serebriakov. Seine Masterarbeit ist auf Virustotal aufgetaucht, einem Portal, bei dem man verdächtige Dateien hochladen und auf Malware analysieren lassen kann. Sie trägt den Titel "Information Confrontation in World Politics" und stammt aus dem Jahr 2019 - vor dem Ukraine-Krieg also.

Was schreibt jemand von Serebriakovs Kaliber in seine Masterarbeit? Erstaunlich viel, was sein Weltbild erklärt, analysiert Hakan in einem kurzen Twitter-Thread (Lesestoff): Russland muss sich gegen den bösen Westen verteidigen. Spiegel-Plus-Abonennten finden dort auch die ausführlichere Analyse verlinkt, die im Spiegel veröffentlicht wurde.

5. Nächste Woche: OT Cybersecurity Expert Panel Forum

Zum Abschluss noch ein Terminhinweis:

Schon nächste Woche finde die diesjährige Ausgabe des OT Cybersecurity Expert Panel Forums ("OTCEP") in Singapur statt. Die Veranstaltung wird von der Cybersecurity Agency  organisiert - in etwa das singapurer Pendant zum deutschen BSI. Während die Kernzielgruppe die Betriber kritischer Infrastrukturen in Singapur ist, hat das Event sich mittlerweile zu einer wirklich hochkarätig besetzten OT-Security-Konferenz gemausert. Die Vorträge, die überwiegend noch nirgendwo anders gehalten wurden, sind definitiv nicht nur für Singapur spannend.

Ich darf über mein derzeitiges Lieblingsthema Security by Design sprechen und bin gespannt auf die Vorträge meiner Vorredner Robert M. Lee, Eric Byres und Dale Peterson, die zur aktellen Bedrohungslage, zur Supply Chain Security und zur (gefühlten) Wirksamkeit von Security-Maßnahmen sprechen werden.

Für den zweiten Tag gibt es eine gute und eine schlechte Nachricht: Gut: Die CSA das Programm gegenüber letztem Jahr verbessert. Schlecht: Es gibt jetzt drei parallele Tracks, sodass man sich entscheiden muss... aber sehen Sie selbst im Programm.

Die 800 Plätze vor Ort in Singapur sind ausverkauft, aber virtuell kann man noch teilnehmen. Programm und Registrierungslink siehe unten. Vielleicht "sehen" wir uns ja!

Stay secure!
Sarah Fluchs