Beiträge

Räumliche Trennung bei der Digitalisierung von Kritischen Infrastrukturen?

/in /von

Unsere Mitglieder haben sich für die AG KRITIS mit der räumlichen Trennung bei der Digitalisierung von Kritischen Infrastrukturen auseinandergesetzt.Paper der AG KRITIS: Räumliche Trennung bei der Digitalisierung von Kritischen Infrastrukturen

Es ist nicht klug, so das Sprichwort, alle Eier in einem Korb zu lagern. Eine grundlegende Vorsichtsmaßnahme gegen Unfälle und Missgeschicke, aber auch gegen Angriffe, ist die räumliche Trennung von Werten. Insbesondere werden kritische Komponenten grundsätzlich redundant ausgelegt und diese redundanten Systeme räumlich voneinander getrennt betrieben, um zu vermeiden dass ein einzelnes Ereignis einen Schaden anrichten kann.

Es wird niemanden überraschen, dass die fortschreitende Digitalisierung und Vernetzung von Systemen der Kritischen Infrastruktur die Schutzwirkung von Redundanz und räumlicher Trennung deutlich schwächt. Für digitale Angreifer stellt Redundanz alleine kein Hindernis dar, wenn die redundanten Systeme dieselben Schwachstellen aufweisen. Und die Kommunikation in der digital vernetzten Welt koppelt räumlich getrennte Systeme wieder so dicht zusammen, wie schnell Daten durch das Kommunikationsnetz gesendet werden können. Eine unabsichtliche Fehl-Fernbedienung oder ein absichtlicher Angriff können digitalisierte, redundante Komponenten gleichermaßen betreffen.

In diesem Artikel diskutieren wir die Schwächung physischer Barrieren durch Digitalisierung und mögliche Maßnahmen zur Sicherstellung eines grundlegenden Schutzniveaus einer digitalisierten Kritischen Infrastruktur.

Physische Trennung als traditionelle Schutzmaßnahme

Physische Trennung in den verschiedensten Ausprägungen ist eines der am weitesten verbreiteten Schutzkonzepte, um Schaden zu vermeiden oder zumindest das Schadensausmaß zu reduzieren. Die Techniken sind dabei so vielfältig wie für uns alltäglich und intuitiv, dass wir sie vielleicht nicht einmal wirklich als solche erkennen. Ein Beispiel für so eine intuitive räumliche Trennung sind Bürgersteige und Fahrspuren, während Ampeln eine ebenso intuitive zeitliche Trennung darstellen.

Auch Kritische Infrastruktur wird in wesentlichen Teilen durch physische Trennung geschützt, sei dies die räumliche Barriere um ein Kraftwerk oder die räumlich getrennte redundante Stromversorgung eines Krankenhauses. Auch die durch Ressourcen-Lagerung erreichte zeitliche Trennung der Verbraucher von den Versorgungsquellen ist ein wesentlicher Baustein traditioneller Schutzkonzepte.

Schaden mit nahezu Lichtgeschwindigkeit

Digitalisierung von Kritischer Infrastruktur bedeutet vor allem einen automatisierten Austausch, sowie die Erzeugung und Verarbeitung von Sensor- und Steuerdaten. Insbesondere die hohe Geschwindigkeit der Kommunikation, zwischen 50 und 90% der Lichtgeschwindigkeit, verringert den Schutzeffekt räumlicher Trennung von kommunizierenden Komponenten in dramatischer Weise.

Allein in diesem Jahr finden sich etliche öffentliche Berichte von Firmen, Universitäten, Gerichten, kommunalen Systemen als auch Universitätskliniken und Krankenhäusern, die durch Ransomware innerhalb kürzester Zeit für Tage oder Wochen vollständig lahmgelegt wurden. Was selbst eine massive Sabotage an der Stromversorgung nicht erreichen könnte, bewirkt die Schadsoftware der organisierten Kriminalität in Minuten. Traditionelle Schutzkonzepte, die nur auf Redundanz und physischer Trennung beruhen, sind in einer digitalisierten Infrastruktur offensichtlich unzureichend.

Digitalisierte Schutzkonzepte

Die wesentliche Frage ist also, wie die physische Trennung ergänzt werden kann, um sowohl gegen Fehler als auch gegen Angriffe in einer digitalisierten Infrastruktur zu schützen? Sehr abstrakt betrachtet ist dies ein Kernthema der IT-Sicherheit, in deren Entwicklung eine Vielzahl von Schutzmechanismen erarbeitet wurden, mit denen physische Mechanismen ersetzt oder ergänzt werden. Die „Firewall“ hat es als dominantere Technologie sogar bis in den allgemeinen Sprachgebrauch geschafft. Im Folgenden werden einige Konzept vorgestellt, die in der IT-Sicherheit entwickelt wurden, um die Auswirkungen von Angriffen und Fehlern zu limitieren und zu verringern.

Isolation & Kapselung

Auch wenn es verlockend bzw. kostengünstiger erscheint, Systeme großflächig einheitlich zu digitalisieren, sollte nicht einfach „alles mit allem“ vernetzt werden. Der Grad der Vernetzung sollte sich an dem konkret vorgesehenen Kommunikationsbedarf orientieren. Systeme unterschiedlicher Kritikalität sollten auch im digitalen grundsätzlich voneinander getrennt bleiben. Kommunikation sollte nur in dem Maße ermöglicht werden, wie Bedarf und Nutzen nachgewiesen werden – sog. Business need to Know Designprinzip. Insbesondere sollen redundante Komponenten nicht über dieselben Kommunikationsnetze steuerbar bzw. erreichbar sein.

Eng verbunden mit dem Designprinzip der Isolation ist auch das „least privilege“ Designprinzip, das die Zugriffsmöglichkeiten und Rechte auf den einzelnen Systemen in ähnlicher Weise auf das Notwendige einschränkt.

Unabhängigkeit

Jede Abhängigkeit eines digitalen Systems bedeutet auch eine weitere potentielle Angriffsfläche. Auch die möglichen Fehlerquellen werden schnell unüberschaubar. Daher sollten Systeme in Kritischen Infrastrukturen möglichst unabhängig von anderen Systemen, Diensten und Funktionen betrieben werden. Ist eine Abhängigkeit notwendig, sollte diese als ebenso kritisch berücksichtigt werden. Benötigt ein System beispielsweise die exakte Uhrzeit, lässt sich eine Abhängigkeit zu einem Zeit-Server nicht vermeiden. Dieser Zeit-Server muss dann in das Schutzkonzept gegen Angriffe und Fehler mit einbezogen werden.

Heterogenität

Zuerst einmal sollte akzeptiert werden, dass Teile eines Systems ausfallen oder kompromittiert werden können. Insbesondere muss geplant werden, dass gleichartige Komponenten mit höherer Wahrscheinlichkeit gleichzeitig betroffen sind, weshalb Backup- und Wiederherstellung für den Ausfall ganzer Komponentengruppen geplant, umgesetzt und (auch die Wiederherstellung) getestet werden müssen.

Digitalisierte Systeme bestehen heutzutage jeweils aus einem komplexen Stapel von Software- und Hardware-Komponenten. Eine wesentlich Erkenntnis ist, dass Schwachstellen einer Komponente dieses Stapels meist alle Systeme betreffen, in denen diese Komponente verwendet wird. Die weite Verbreitung einer Komponente, z. B. eines Betriebsystems oder einer beliebten Softwarebibliothek führt dazu, dass auch deren Schwachstellen weit verbreitet sind und die betroffene System dementsprechend angreifbar wären. Um die Auswirkungen einzelner Schwachstellen zu reduzieren ist es demzufolge wichtig, die Verbreitung gleichartiger Baureihen zu beschränken, kurz, die Infrastruktur aus Systemen mit möglichst unterschiedlichen Software- und Hardware-Komponenten aufzubauen. Damit würde Heterogenität als eine digitale Schutztechnik die Redundanz bzw. räumliche Trennung ergänzen.

Praktisch bedeutet Heterogenität aber auch, dass der Aufwand in der Herstellung und im Betrieb der Infrastruktur steigt. Offensichtlich kann nicht jedes System vollständig anders als alle anderen aufgebaut werden. Deshalb ist es zuerst wichtig, eine Abwägung zu treffen und minimale Heterogenitätsanforderungen zu definieren. Dabei kann weiterhin der, oft durchaus räumlich beschränkte, Wirkbereich von Systemen berücksichtigt werden. Eine einfache Verteilung gleichartiger Komponenten auf unterschiedliche Systeme führt nämlich auch dazu, dass alle Systeme gleichzeitig angreifbar werden. Diese Abschätzung fehlt bisher in allen wesentlichen Standards und Richtlinien für den Schutz von Systemen.

Bei einigen Technologien ist Heterogenität nur in geringem Maß umsetzbar. In diesem Fall ist neben erhöhten Isolations- und Unabhängigkeitsanforderungen auch eine bessere Reaktivität notwendig.

Reaktivität

Im Vergleich zu nicht digitalisierter Kritischer Infrastruktur unterliegen Hardware und insbesondere Software heutzutage sehr kurzen Lebenszyklen. Wöchentliche Updates und monatliche „Patchdays“ sind eher die Regel als die Ausnahme. Gleichzeitig gilt das Betreiben möglichst aktueller Software und Hardware als beste Maßnahme gegen Angriffe. Dies ist schon in einem Büro-IT Umfeld schwierig. Digitale Kritische Infrastruktur schnell und häufig zu aktualisieren wird in den meisten Fällen ein enorme Herausforderung sein. Gleichzeitig stellt dies sogar ein wesentliches Risiko für die Verfügbarkeit der Versorgung dar. Trotzdem gehört die Reaktivität auf neue Schwachstellen als auch aktualisierte Software und Hardware in jedes Schutzkonzept. Möglichst frühzeitig sollte das eigene Reaktionsvermögen – unter anderem auf Schwachstellen und veraltete Komponenten – realistisch abgeschätzt werden. Dieses (vermutlich nicht allzu schnelle) Reaktionsvermögen sollte dann die Basis für die Planung von Betriebs- und Wartungszyklen sein. Ebenso sollte der Schutzbedarf gemäß den vorher vorgestellten Konzepten daran ausgerichtet werden, wie viele Schwachstellen innerhalb eines Betriebszyklus zu erwarten sind, ohne diese reaktiv beheben zu können.

#Shitrix: Was kann der Gesetzgeber aus dem Citrix-Vorfall lernen und für KRITIS Betreiber verbessern?

/in /von

Seit dem 07.01.2020 hat das CERT-Bund des BSI deutsche Netzbetreiber, die Bundesverwaltung, Betreiber Kritischer Infrastrukturen und andere -Nutzergruppen über verwundbare Citrix-Systeme informiert. Darüber hinaus wurde beispielsweise am 16.01.2020 nochmal verschärft darauf hingewiesen, dass seit dem 10.01.2020 verstärkt Exploit-Code zur Ausnutzung der Schwachstelle veröffentlicht wurde. Trotzdem sind heute immer noch viele Systeme verwundbar und werden aktiv kompromittiert, wie beispielsweise auch die Landeshauptstadt Potsdam und die Stadt Brandenburg!

Wie kann es sein, dass nach Veröffentlichung von Schwachstellen durch Hersteller und Entdecker als auch nach Warnmeldungen vom BSI ein sicherer Betrieb und eine zügige Absicherung der IT-Infrastruktur nicht gewährleistet werden kann? Bis heute sind immer noch viele Systeme ungepatcht.

Um den beschriebenen Herausforderungen auf geeignete Weise begegnen zu können, bedarf es staatlicher Unterstützung, die wir in diesem Beitrag zu politischen Forderungen zur Diskussion stellen möchten.

So kann es nicht weitergehen. Die Politik ist jetzt gefragt, einige wenige, aber sehr notwendige gesetzliche Änderungen durchzuführen.

Politische Forderungen

Was kann der Gesetzgeber aus dem Citrix-Vorfall als auch der kürzlich bekannt gewordenen Krypto-Schwachstelle bei Microsoft lernen und für uns alle verbessern?

Unabhängigkeit des Bundesamt für Sicherheit in der Informationstechnik

Wie einem Mitglied der AG KRITIS vertraulich zugetragen wurde, hätte die Citrix-Sicherheitslücke bereits einige Tage oder Wochen vor der ersten Meldung von Citrix am 17.12.2019 an das BSI gemeldet werden können. Mitarbeiter eines Unternehmens hatten schon früher Kenntnis über die Sicherheitslücke erlangt – entschieden sich aber, diese die Kenntnis der Sicherheitslücke vorerst nicht dem BSI öffentlich zu machen oder zu melden. Mangels Vertrauen, dass diese Erkenntnisse nicht auch an Angreifer oder über das BMI an die Sicherheitsbehörden zur Ausnutzung gelangen würden!

Stellungnahme vom 29.01.2020 zum obigen Abschnitt: Es handelte sich hierbei nicht um eine Meinung des Unternehmens, sondern um eine private Meinung, die in dieser Weise nicht für die Veröffentlichung vorgesehen war. Dafür entschuldigen wir uns nachdrücklich.

Das BSI muss aus den Strukturen des Bundesinnenministeriums herausgelöst werden, um eine unabhängige und defensive IT-Sicherheit in Deutschland zu etablieren. Das BMI ist auch für deutsche Sicherheitsbehörden zuständig, die zwangsläufig aufgrund ihres staatlichen Auftrags den IT-Sicherheitszielen gegensteuern müssen.

Ein unabhängiges und ausschließlich defensiv agierendes BSI kann zum einen das benötigte Vertrauen schaffen, so dass Sicherheitsforscher alle gefundenen Schwachstellen dem Hersteller als auch dem BSI möglichst umgehend bereitstellen. Zum anderen kann es dann wiederum auch konsequent die Entwicklung eines Patches und das ausrollen und installieren bei KRITIS Betreibern als Kunden dieser Hersteller überwachen und sicherstellen. Zur Not auch durch den Einsatz von Bußgeldern und Strafzahlungen, vergleichbar dem Bundesbeauftragten für den Datenschutz und die Informationsfreiheit im Rahmen der DSGVO.

Solange dieses Vertrauen nicht hergestellt ist, werden durch Sicherheitsforscher entdeckte Sicherheitslücken nicht konsequent an das BSI gemeldet. Des weiteren wird dadurch auch der Schwarzmarkt zum Handel mit Sicherheitslücken (0days oder zero day exploits) und zugehörigen Exploits zum Ausnutzen der Lücken angefeuert und nicht ausgetrocknet.

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 und Mindeststandards 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.

Patches müssen gesichert eingespielt werden können, um einen dauerhaften Schutz der IT-Landschaft zu gewährleisten.

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

/in /von

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.