Beiträge

Kommentar zum neuen Referentenentwurf des IT-Sicherheitsgesetz 2.0 (IT-SiG2)

Die beiden Leiter der AG KRITIS, Manuel Atug und Johannes Rundfeldt zum von netzpolitik.org veröffentlichten neuen Entwurf des IT-SiG2 von Mai 2020:

Das neue IT-Sicherheitsgesetz 2.0 (IT-SiG2) ist definitiv eine Verbesserung zum vorherigen Entwurf von März 2019. Aber nicht alle Details sind gut, einzelne Punkte sind leider auch ein Rückschritt und werfen neue Gefahren und Risiken auf.

Die AG KRITIS begrüßt die Tatsache, dass die hochkritischen Änderungen an der Strafprozessordnung und am Strafgesetzbuch, die noch im ersten veröffentlichten Entwurf von März 2019 aufgeführt wurden, nun nicht mehr enthalten sind. Auch begrüßen wir die Tatsache, dass die Entsorgung – also Teil der Abfallwirtschaft – nun auch als kritische Infrastruktur betrachtet wird. Dies ist überfällig und sinnvoll, schließlich entstehen sehr schnell katastrophale Gesundheitsrisiken für die Bevölkerung wegen der drohenden Seuchengefahr und Gefährdungen in der Umwelt bedingt durch gefährliche Stoffe, wenn die Abfallentsorgung nicht mehr funktionieren würde.

Leider hat sich damit jedoch nicht alles zum Guten verbessert. Es gibt insbesondere auch einige Neuerungen, die in dieser Weise unsere kritischen Infrastrukturen direkt gefährden können.

Unser größter Kritikpunkt ist die hochgefährliche Datensammlung, die sich hinter der unscheinbaren Formulierung in § 9b Absatz 1 BSIG verbirgt. Dort geht es um IT (oder OT) -Komponenten in kritischen Infrastrukturen.

„Der Einsatz einer kritischen Komponente (§ 2 Absatz 13), (…), ist durch den Betreiber einer Kritischen Infrastruktur dem Bundesministerium des Innern, für Bau und Heimat vor Einbau anzuzeigen. In der Anzeige ist die kritische Komponente und die Art ihres Einsatzes anzugeben.“

Bisher müssen Hersteller solcher Komponenten mit dem BSI zusammen arbeiten, um eine Zertifizierung von Komponenten zu erreichen. Dabei kann das BMI diese Zertifizierung aus Gründen der öffentlichen Sicherheit ablehnen, auch wenn das BSI zum Schluss kommt, dass die zu zertifizierende Komponente den Kriterien entspricht.

Der neue IT-SiG2-Entwurf schafft hier allerdings eine neue Anzeigepflicht. Nicht mehr nur der Hersteller der Komponente muss mit den Behörden in Kontakt treten, sondern der Betreiber der Komponente muss deren Einsatz beim BMI melden. Auf diese Weise plant das BMI eine Liste aufzubauen, welcher KRITIS-Betreiber welche Komponenten im Einsatz hat. So eine Liste ist jedoch höchst kritisch zu bewerten, da jeder Geheimdienst und jede ausländische Macht, die Zugriff auf diese hochsensible Liste erlangt, unsere kritische Infrastruktur gefährden kann. Getreu dem Motto „Wo ein Trog ist, da sammeln sich auch Schweine“ halten wir es für überflüssig und gefährlich, so eine hochsensible Datensammlung überhaupt anzulegen. Wenn man aus sicherheitstechnischen Erwägungen trotzdem zum Schluss kommt, so eine Liste zu benötigen, so muss diese besonders vor dem Zugriff von in- und ausländischen Ermittlungsbehörden und Nachrichtendiensten geschützt werden. Nur ein unabhängiges BSI, das nicht mehr unter der Aufsicht des BMI steht, könnte so eine Liste geeignet verwalten.

Leider wurde diese essentielle fachliche Unabhängigkeit des BSI nicht im § 1 des BSIG vorgesehen. Hier wünschen wir uns eine Nachbesserung, denn ein fachlich unabhängiges BSI ist notwendig und überfällig. Obwohl es verschiedene Ansätze gibt, wie dies juristisch erreicht werden könnte, halten wir die Anpassung des § 1 BSIG für den naheliegendsten Ansatz, wenn man sowieso gerade plant, das BSIG zu ändern. Dabei kann man sich in der Ausgestaltung der fachlichen Unabhängigkeit hervorragend am statistischen Bundesamt orientieren.

Der zweite nicht weniger relevante Kritikpunkt ist die offensichtliche Umgehung des frisch geschaffenen Nationalen Cyberabwehrzentrum (NCAZ) bei erfolgreichen Cyberangriffen auf IT-Systeme. Im zu ändernden § 109a TKG findet sich die Formulierung:

„(1a) Im Falle einer unrechtmäßigen Übermittlung an oder unrechtmäßigen Kenntniserlangung von Daten durch Dritte unterrichtet der Diensteanbieter unverzüglich das Bundeskriminalamt über diesen Sachverhalt, wenn bestimmte Tatsachen die Annahme rechtfertigen, dass 1. jemand Telekommunikations- oder Datenverarbeitungssysteme ohne Erlaubnis oder Billigung des Diensteanbieters verändert, auf diese eingewirkt oder Zugangseinrichtungen zu diesen überwunden hat und 2. dies nicht fahrlässig erfolgt ist.“

Im Fall der vorsätzlichen und erfolgreichen Umgehung von Zugangseinrichtungen, der Veränderung von Daten oder der Einwirkung von Dritten auf diese ist es wohl angebracht, dies als Cyberangriff zu bezeichnen. Je nachdem, wer der Täter ist, ändert sich die Zuständigkeit für die Vorfallsbehandlung und Ermittlung.

Handelt es sich um einen Angriff eines deutschen Bürgers auf eine technische Einrichtung der Bundeswehr, wäre der MAD zuständig. Wären wir im Krieg und hätte die Bundeswehr ein Mandat, wäre in diesem Fall das KdoCIR zuständig. Wenn ein System angegriffen wird, welches nicht zur Bundeswehr gehört, sondern z.B. zu einem Telekommunikationsanbieter, dann wäre das BKA nur dann zuständig, wenn der Angriff von einem deutschen Bürger ausgeht. Geht der Angriff von einem ausländischen Bürger aus, wäre der BND zuständig. Ginge der Angriff von einer ausländischen staatlichen Macht aus, wäre der BND und unter Umständen auch das Auswärtige Amt zuständig. In manchen Sonderfällen fiele auch eine Teil-Zuständigkeit an das BfV.

Zum Zeitpunkt der initialen Detektion eines Angriffs ist der Täter und dessen Nationalität aber unbekannt. Daher kann nicht von vornherein klar sein, wer wirklich zuständig ist. Aus genau diesem Grund wurde das NCAZ geschaffen, welches die Vorfallsbehandlung zwischen den möglicherweise zuständigen Bundesbehörden koordinieren soll. Im NCAZ sitzen deswegen Vertreter aller möglicherweise zuständigen Behörden, wie z.B. dem BKA, der BPol, dem BfV, dem BND, dem MAD und dem KdoCIR.

Wir sind daher zu der Meinung gekommen, dass an dieser Stelle die Meldung an das NCAZ erfolgen soll und eben nicht an das BKA. Das NCAZ kann dann koordinieren, welche Bundesbehörde auf Basis der vorliegenden Indizien wahrscheinlich zuständig ist. Nichtsdestotrotz sind, egal welche Behörde für die Ermittlungen zuständig ist, immer auch andere Bundesbehörden einzubinden, wie z.B. das BSI, welches nötigenfalls Warnungen und Meldungen über das CERT-Bund herausgeben müsste.

„Man muss Gesetze kompliziert machen, dann fällt es nicht so auf“, sagte Bundesinnenminister Horst Seehofer im Juni 2019. An dieses Mantra hält man im BMI auch beim IT-SiG2 konsequent fest. Im alten Entwurf fand sich noch die Formulierung, dass die Rüstungsindustrie zur sog. „Infrastruktur in besonderem öffentlichen Interesse“ (ISBÖFI) gehören soll. Die „ISBÖFI“ ist quasi eine Art „KRITIS light“. Nicht alle KRITIS Pflichten werden auferlegt, aber manche. Im neuen IT-SiG2-Entwurf findet sich das Wort „Rüstung“ nun nicht mehr, trotzdem gehört Rüstung weiterhin zu ISBÖFI. Dies wird nun durch die verschleiernde Erwähnung des „§ 60 AWV Absatz 1 Satz 1-5“ festgelegt und auch in den Begründungen zum Gesetz weder erläutert noch aufgeklärt.

Die AG KRITIS ist der Meinung, dass Rüstung weder KRITIS ist, noch zu einer Art „KRITIS light“ gehören kann – denn die Rüstungsindustrie gehört eben nicht zu solchen Diensten, „die von wesentlicher Bedeutung für die Aufrechterhaltung wichtiger gesellschaftlicher Funktionen, der Gesundheit, der Sicherheit und des wirtschaftlichen oder sozialen Wohlergehens der Bevölkerung sind und deren Störung oder Zerstörung erhebliche Auswirkungen hätte“ (KRITIS-Definition).

Selbst wenn man argumentieren würde, dass die hergestellten Rüstungsgüter nach Bestellung, Produktion und Lieferung der Bundeswehr zu Gute kommen würden und damit bei der Aufgabenerfüllung der Bundeswehr (Verteidigungsarmee) helfen sollen – selbst dann wäre die Rüstungsindustrie noch nicht KRITIS, da die Bundeswehr diese Aufgaben mit Ihren Beständen erfüllen muss und die Beschaffung neuer Waffen so lange dauert, das diese neuen Waffen wohl kaum zur Bewältigung der dann aktuellen Lage eingesetzt werden können. Eine Mitverantwortung für die öffentliche Sicherheit kann daher bei der Rüstungsindustrie nicht behauptet werden. Entsprechend gehört die Rüstungsindustrie auch nicht zu den kritischen Infrastrukturen und darf daher auch nicht der neu geschaffenen Vorstufe „ISBÖFI“ zugeordnet werden.

Unser dritter Kritikpunkt ist, dass im IT-SiG von 2015 festgelegt wurde, dass eine Evaluierung der Gesetzesänderungen spätestens vier Jahre nach Inkrafttreten vorgenommen werden soll. Unserer Kenntnis nach ist diese Evaluierung aber bisher nicht erfolgt. Konsequenterweise sieht das BMI auch keine Evaluierung des neuen IT-SiG2 vor, sondern stellt in Aussicht, die aktuell gesetzeswidrig(!) überfällige Evaluierung des IT-SiG von 2015 doch noch vorzunehmen. Dies reicht dem BMI als Begründung, warum eine Evaluierung der zweiten Version des IT-SiG nicht notwendig wäre, weil man ja Erkenntnisse aus dem Gesetzesentwurf des IT-SiG2 in die Evaluierung des IT-SiG von 2015 einfließen lassen könne.

Selbstverständlich ist das nicht ausreichend – das BMI soll, wie aus gutem Grund im Gesetz vorgesehen, erst das vorhandene IT-SiG von 2015 evaluieren und dann diese Erkenntnisse, genau wie geplant, in das IT-SiG2 einfließen lassen – aber nicht andersherum, wie es aktuell im IT-SiG2 angegeben wird.

Weiterhin findet sich im IT-Sig2 auch noch eine Passage, die uns als AG KRITIS mit Freude erfüllt. Uns zeigen diese Änderungen, dass man auch ehrenamtlich erfolgreichen und sinnvollen Lobbyismus betreiben kann.

Es scheint so, als wurden bestehende Forderungen der AG KRITIS im IT-SiG2 berücksichtigt. So soll das unserer Ansicht nach zu schwach besetzte MIRT deutlich anwachsen. Dies vergrößert die staatlichen Krisenbewältigungskapazitäten signifikant. Auch das Bundesamt für Bevölkerungsschutz und Katastrophenhilfe (BBK) bekommt wichtige Aufgaben und weitere Personalstellen zugeteilt, um erstmalig in die Lage versetzt zu werden, auch für IT-Katastrophen Krisenreaktionspläne auszuarbeiten. Auch lesen wir den neu geschaffenen § 5c BSIG fast schon wie die initiale rechtliche Grundlage für den Einsatz eines zu schaffenden Cyberhilfswerks – wie von uns im Februar 2020 vorgestellt – und verortet die Kompetenzen und Verantwortlichkeiten an den richtigen Stellen, nämlich dem BSI gemeinsam mit dem Partner BBK.

Hier findet Ihr unser CHW-Konzept:

Implikationen für KRITIS durch Schwachstelle in Microsoft Krypto-Bibliothek

Update zum Thema: Was kann der Gesetzgeber aus dem Citrix-Vorfall lernen und für KRITIS Betreiber verbessern?

Was haben elliptische Kurven, Zertifikate und Windows-Updates mit Kritischen Infrastrukturen zu tun?

Mehr als man zunächst denken mag.

Was ist passiert?

Am 14. Januar 2020 veröffentlichte Microsoft ein Update, das bereits im Vorfeld viel Aufmerksamkeit erhalten hat. Der amerikanische Geheimdienst NSA hatte den Softwarehersteller auf einen Fehler aufmerksam gemacht, sodass die Schwachstelle behoben werden kann.

Bei der Schwachstelle (CVE-2020-0601, auch bekannt als #curveball) handelt es sich um einen Fehler in der Überprüfung von kryptographischen Zertifikaten. Zertifikate werden unter anderem für die Validierung von Softwarepaketen und -updates oder HTTPS-Verbindungen verwendet. Der Fehler ist in einer Microsoft Windows Standardbibliothek entdeckt worden und betrifft daher gleichzeitig auch viele andere Programme. Bei bestimmten kryptographischen Methoden wird ein eigentlich ungültiges Zertifikat als trotzdem gültig gekennzeichnet – eine eigentlich nicht vertrauenswürdige Verbindung, wird vertrauenswürdig oder ein Softwarepaket bzw. Update erhält den Eindruck, es kommt von einer vertrauenswürdigen Quelle. Neben Webseiten und Programmen kommen Zertifikate aber auch bei der Signatur und Verschlüsselung von E-Mails zum Einsatz. Outlook nutzt bei S/MIME Zertifikate – diese können ebenfalls gefälscht werden. Benjamin Deply hat hierzu ein entsprechendes Video veröffentlicht.

Details können der entsprechenden Veröffentlichung der amerikanischen Regierung entnommen werden. Die kryptographischen Details hat Tal Be’ery analysiert. Die Schwachstelle wird auch unter dem Namen ChainOfFools (Zertifikatsketten) oder CurveBall (elliptische Kurven) geführt.

Innerhalb weniger Tage ist von Forschern bereits ein entsprechender Angriff entwickelt und veröffentlicht worden, der fehlerhafte, aber gültige Zertifikate erstellt. Erste Schadsoftware wurde identifiziert, die mit vermeintlich gültigen Zertifikaten signiert worden ist.

Implikationen für KRITIS

Kryptographische Verfahren sind für einige KRITIS Betreiber auf dem ersten Blick eher von nachrangigem Interesse. Bestimmte Branchen wie Banken oder Telekommunikation nutzen Krypto als Teil ihres Geschäftsmodells oder sind bereits seit Jahrzehnten zur Verschlüsselung gezwungen. Es ist davon auszugehen, dass diese Branchen ein erhöhtes Augenmerk auf die oben genannte Schwachstelle haben.

Die Schwachstelle betrifft aber alle Betreiber und Internetanwender – nicht nur die, die Bank- oder Telekommunikationsdaten verschlüsseln. KRITIS Betreiber verwenden natürlich auch das Internet und verschlüsselte Verbindungen für einen gesicherten Datenaustausch. HTTPS (also verschlüsselte Internetverbindungen) beruht auf Vertrauen. Von zentralen vertrauenswürdigen Instanzen werden Zertifikate ausgegeben, die validiert werden können. Auf Basis der Validierung können Betreiber zwischen betrügerischen Webseiten bzw. Angreifern und dem eigentlichen Kommunikationspartner unterscheiden. Diese Validierung ist auf einem ungepatchten und somit anfälligen Windows System nur noch eingeschränkt möglich und es werden ggf. Daten durch einem unbefugten Dritten ausgetauscht oder heruntergeladen.

Zertifikate als Vertrauensanker und die Validierung dieser wird nicht nur bei HTTPS-Verschlüsselung eingesetzt, sondern auch im Umfeld von signiertem Programmcode. Entwickler können entsprechende Signaturzertifikate beantragen, um die Herkunft und Integrität ihrer Software bestätigen zu lassen. Setzen Unternehmen für kritische Geschäftsprozesse auf signierte oder verschlüsselte E-Mails können diese durch gefälschte E-Mail-Signaturen gestört werden.

Falsche Validierung wiederum eröffnet die Möglichkeit eines Supply-Chain-Angriffs. Die Kompromittierung der ukrainischen Softwarefirma MeDoc führte durch manipulierte Updatepakete zu einer der größten Ransomware-Infektionen weltweit. Nutzen nun Lieferanten für Kritische Infrastrukturen entweder keine Signatur oder validieren Betreiber diese unzureichend, so können Angriffe auf KRITIS erfolgen, ohne die Betreiber direkt anzugreifen. Die Schwachstelle erlaubt es einem Angreifer, Software gültig zu signieren, selbst wenn die Software manipuliert wurde.

KRITIS-Unternehmen, die das Microsoft Update nicht eingespielt haben, laufen daher dringend Gefahr, dass schädliche oder manipulierte Software einen legitimen Eindruck macht und deshalb innerhalb ihrer IT-Landschaften ausgeführt wird.

Gegenmaßnahmen

Wie bei fast allen öffentlich bekannt gewordenen Schwachstellen ist die erste Gegenmaßnahme die Evaluierung von Risiken im Patchmanagement-Prozess und anschließend zumeist das zeitnahe Einspielen der verfügbaren Sicherheitsaktualisierungen des Herstellers. Microsoft hat koordiniert aktualisierte Pakete bereitgestellt, die durch Kunden bzw. deren Systemadministratoren installiert werden müssen. Patchmanagement und Systemaktualisierungen in Kritischen Infrastrukturen ist ein sehr komplexes Thema, das an dieser Stelle nicht weiter vertieft werden soll. KRITIS Betreiber nutzen zum Teil weiterhin alte, nicht mehr unterstützte und nicht sichere Software – beispielsweise aufgrund von Legacy Komponenten in der Produktionsumgebung – und setzen sich und anderen damit stärker den Gefahren von Cyber-Angriffen aus.

Zulieferer für Kritischen Infrastrukturen sollten sich ihrer Supply-Chain-Verantwortung bewusst sein. Gerade in so einer Umgebung ist es notwendig, im Rahmen des Patchmanagements Aktualisierungen und Softwareverteilung auf Integrität und Herkunft zu prüfen. Dies erfordert, dass die Hersteller entsprechende Signaturen implementieren, die Betreiber müssen diese Signaturen aber auch auf Gültigkeit prüfen.

Politische Forderungen

Was kann der Gesetzgeber von diesem Vorfall lernen und für uns alle verbessern?

Quellcode Open Source oder in treuhänderischer Verwaltung

Schwachstellen in (insbesondere komplexer) Software können nie ausgeschlossen werden, daher empfiehlt sich immer ein geregeltes Patchmanagement im Rahmen eines etablierten Informationssicherheitsmanagementsystems (ISMS) – wie es auch über § 8a Abs. 1 BSIG als Stand der Technik gefordert und in  branchenspezifischen Sicherheitsstandards (B3S) nach § 8a Abs. 2 enthalten ist. Für sicherheitskritische Komponenten sollten jedoch höchste Standards gefordert und im Idealfall auch überprüfbar gemacht werden.

Durch Open Source oder treuhänderische Verwaltung von Quellcode und ggf. zugehöriger Patente kann die Überprüfbarkeit als auch eine sichere und dauerhafte Weiternutzung der Software gewährleistet werden, sofern der Hersteller irgendwann einmal nicht mehr verfügbar ist (Stichwort Insolvenz). Es sollte nicht dem Zufall oder den Interessen einzelner Institutionen überlassen werden, dass sicherheitsrelevante Software überprüft und weitergenutzt werden kann.

Gesetzlich verpflichtendes Patchmanagement

KRITIS Betreiber können häufig nicht ihre eigene Software für Spezialanwendungen schreiben und müssen diese zukaufen. Wir fordern daher neben der Veröffentlichung des Quellcodes, oder aber der treuhänderischen Verwaltung des Quellcodes eine gesetzliche Verpflichtung der KRITIS-Betreiber, Aktualisierungen und Softwareverteilung auf Integrität und Herkunft zu prüfen, aber auch binnen einer vorgegebenen und Bußgeldbewehrten Frist, Empfehlungen des BSI umzusetzen. Dies erfordert, dass Hersteller entsprechende Signaturen implementieren. Unsignierte Software, die nicht Open Source ist, und wo sich der Quellcode nicht in treuhändischer Verwaltung befindet, darf im KRITIS-Umfeld unserer Meinung nach nicht eingesetzt werden.

Responsible Disclosure von Schwachstellen – verpflichtend auch für Sicherheitsbehörden!

Die Schwachstelle wurde initial durch die NSA an Microsoft gemeldet, sodass eine Fehlerbehebung vorgenommen werden kann. Ein Meldeverfahren zur Behebung von Schwachstellen durch den Hersteller sollte auch für alle deutschen Sicherheitsbehörden verpflichtend vorgegeben sein – werden Schwachstellen an unsere Sicherheitsbehörden gemeldet, durch diese ermittelt oder anderweitig Kenntnis davon erlangt, so dürfen diese nicht für offensive Angriffe verwendet werden, da der Schutz der Kritischen Infrastrukturen im Vordergrund stehen muss. Responsible Disclosure und das Beheben von Schwachstellen trägt wesentlich zu einer sicheren und stabilen digitalen Gesellschaft bei, als das Zurückhalten und Ausnutzen von Schwachstellen.

Ist ein angemessener Schutz von digitalen Cyberwaffen möglich?

Wie lange die Sicherheitslücke dem staatlichen Akteur bekannt war ist nicht öffentlich bekannt. Die vergleichbar kritische Schwachstelle EternalBlue wurde vermutlich von der NSA Spezialeinheit Tailored Access Operations über fünf Jahre lang zurückgehalten und für eigene Angriffe (aktive Cyber-Abwehr oder auch Hack-Back) genutzt. Man hat diese digitale Cyberwaffe mit vielen anderen gehortet aber es nicht geschafft, diese Sammlung so zu sichern, dass kein anderer daran gelangen konnte und eine Sammlung an digitalen Cyberwaffen der NSA sind inzwischen öffentlich gewordenen.

Daher wurden auf Basis dieses NSA-Expoits die Erpressungstrojaner WannaCry und anschließend NotPetya entwickelt, die unter anderen auch die Institutionen Telefónica, FedEx, Deutsche Bahn und Schenker, Sandvik, Beiersdorf, Maersk, Rosneft oder auch Mondelez usw. betroffen und Schäden in Millionenhöhe verursacht haben.