Trennen Sie die Internetverbindung
(computer.rip)- Nach großen Sicherheitsvorfällen wie dem CrowdStrike-Ausfall kommt oft die Reaktion, man hätte das System „gar nicht mit dem Internet verbinden dürfen“. Viele Arbeitssysteme haben jedoch den Informationsaustausch als Kernfunktion, sodass sich das Problem nicht durch simples Abschotten lösen lässt.
- Systeme wie Flugbuchungs- und Planungssysteme überschreiten Organisations- und Regionsgrenzen und sind eher Teil einer Kommunikationsinfrastruktur, die Telefon und Telegrafie ersetzt hat. Entfernt man die Vernetzung, verschwindet damit auch ihr eigentlicher Wert.
- „Nicht mit dem Internet verbunden“ kann sehr Unterschiedliches bedeuten: von einem Einzelgerät über strikte Air Gaps, Data Diodes, private WANs, VPN-Tunnel und eingeschränktes Routing bis hin zu einer AWS Private VPC. Entsprechend unterscheidet sich auch das Threat Model stark.
- In Offline- oder nur eingeschränkt verbundenen Umgebungen treiben OS-Updates, Paketmanager, interne Repositories, TLS-Trust-Stores, Cloud-Lizenzen, Content-Updates und sogar der Umgang mit Docker-Images Zeit und Kosten nach oben.
- Man kann auf mehr Systeme restriktive Netzwerkregeln anwenden und Software mit Blick auf den Offline-Betrieb bauen, doch das heutige Software-Ökosystem nimmt weiterhin die Internetverbindung als Standard an.
Die Grenzen des Satzes „Nicht mit dem Internet verbinden“
- Jedes Mal, wenn ein großer Sicherheitsvorfall in die Nachrichten kommt, wiederholt sich die Reaktion: „So ein System dürfte nicht mit dem Internet verbunden sein.“
- Aus Sicht von Sicherheit und Stabilität hat diese Einschätzung einen intuitiven Reiz, aber in der Praxis werden nur wenige Umgebungen tatsächlich so betrieben.
- Das Kernproblem ist, dass die Aussage „nicht mit dem Internet verbunden“ für sich genommen Architektur, Betriebskosten und Threat Model nicht ausreichend präzisiert.
Moderne Arbeitssysteme sind eher Kommunikationsgeräte
- Abstrakt betrachtet können Computer durch Berechnung Wert schaffen, aber Systeme in der industriellen Praxis haben stärker den Charakter von Informationstechnik als von reiner Berechnung.
- Informationstechnik muss Informationen entgegennehmen und ausgeben. Ein Betrieb, bei dem wie früher ein Operator Bänder einlegt, ist teurer und langsamer als Echtzeitkommunikation.
- Moderne geschäftlich genutzte Computer fungieren größtenteils als Kommunikationsgeräte.
- Es gibt nicht viele Systeme, die Wert schaffen, ohne mit anderen Arbeitssystemen verbunden zu sein.
- Solche Verbindungen überschreiten oft Organisations- und geografische Grenzen.
- Flugbuchungs- und Planungssysteme entstanden als Ersatz für Telefon- und Telegrafiesysteme; das Netzwerk ist Teil ihrer eigentlichen Funktion.
Auch Wartung und Betrieb brauchen Netzwerke
- Selbst bei Systemen, für die Echtzeitkommunikation nicht essenziell für den Geschäftszweck ist, hat Netzwerkverbindung im Betrieb großen Wert.
- Ohne Internetverbindung beginnt das Problem schon bei der Frage, wie Software-Updates beschafft oder Systeme überwacht werden sollen.
- Selbst wenn man festlegt, dass ein System „fertig“ ist und weder Updates noch Echtzeit-Monitoring braucht, ändern sich geschäftliche Anforderungen mit der Zeit.
- Netzwerkverbindungen senken die Kosten für solche Änderungen erheblich.
„Nicht mit dem Internet verbunden“ hat viele Abstufungen
- Der Zustand „nicht mit dem Internet verbunden“ hat keine einheitliche Bedeutung, sondern ist ein Sammelbegriff für verschiedene Implementierungen.
- Die möglichen Formen reichen von vollständiger Trennung bis zu eingeschränkter Konnektivität.
- Einzelgerät ohne jede Netzwerkverbindung
- Striktes Air Gap ohne Verbindungen außerhalb eines privaten LANs und ohne Datenübertritt über die Sicherheitsgrenze
- Ein Air Gap, in das Daten per DVD-R über die Sicherheitsgrenze eingebracht werden
- Eine Struktur, bei der Daten per Cross-Domain Solution oder Data Diode von einem Netzwerk mit niedrigerer Sicherheit in ein Netzwerk mit höherer Sicherheit übertragen werden
- Eine Struktur mit einer Cross-Domain Solution ohne NSA-Zertifizierung
- Auch private Weitverkehrsnetze lassen sich in mehrere Stufen einteilen.
- Privates WAN mit vollständig getrennter physischer Infrastruktur und Manipulationsschutz
- Nutzung gemeinsamer Kabelkanäle, gemieteter Dark Fiber oder Wellenlängen auf lit fiber
- MPLS-basiertes Virtual Private Ethernet
- Tunneling-basiertes Virtual Private Ethernet mit Verschlüsselung und Authentifizierung
- Auch privater Verkehr über öffentliche Kommunikationsnetze wird teils als „nicht verbunden“ bezeichnet.
- Hardwaregeräte, die über ein Common-Carrier-Netz wie das Internet verschlüsselte und authentifizierte Tunnel aufbauen
- Varianten mit Geräten ohne NSA-Zertifizierung
- Verifizierte Software-Tunnel, die auf niedriger Ebene des Betriebssystem-Netzwerk-Stacks konfiguriert sind, um ein Umgehen des Tunnels zu verhindern
- Software-Tunnel mit geringerem Verifizierungsgrad
- Kombinationen aus WireGuard und
iptables-Skripten
- Auch eingeschränkte Internetverbindung fällt oft unter denselben Begriff.
- Private Netzwerke, in denen per Policy-based Routing nur extrem schmale Traffic-Flüsse erlaubt sind
- Strukturen, in denen die erlaubten Flüsse in alten Jira-Tickets dokumentiert sind und einige davon „damit es funktioniert“ hinzugefügt wurden
- Firewall-basierte Strukturen mit relativ großzügigem Outbound und strengem Inbound
- Auch in Cloud-Umgebungen ist die Abgrenzung unscharf.
- AWS Private VPC ohne externes Routing
- Eine VPC, die über PrivateLink usw. mit anderen Private VPCs kommuniziert
- Eine Struktur, in der einige angebundene VPCs ins Internet routen
- Eine Struktur mit NAT Gateway und Internet Gateway, aber in beide Richtungen streng gesetzten Security Groups
- All diese Formen wurden bereits als „nicht mit dem Internet verbunden“ bezeichnet, obwohl Angriffsfläche und Risiken jeweils unterschiedlich sind.
- Wenn man bei einem Flugbuchungssystem sagt, es solle „nicht mit dem Internet verbunden“ sein, aber keinen vollständig netzlosen Zustand meint, spricht man in Wirklichkeit über eine der Zwischenstufen — und jede davon bringt eigene praktische Überlegungen mit sich.
Offline-Umgebungen erhöhen Kosten und Zeitaufwand massiv
- Wird Software in Netzwerken ohne Internetverbindung oder mit stark eingeschränkter Konnektivität betrieben, steigen Aufwandsschätzungen für Zeit und Kosten stark an.
- Bei schwächeren Formen wie einer AWS Private VPC kann man grob mit dem 3- bis 5-Fachen rechnen.
- Bei stärkeren Formen nahe vollständiger Trennung kann es auf das 10-Fache oder weit mehr hinauslaufen.
- Fast das gesamte Software-Ökosystem ist unter der Annahme von Internetverbindung entworfen.
- Betriebssysteme versuchen, Updates von Online-Servern zu holen.
- Kommerzielle OS-Anbieter stellen Update-Infrastruktur für private Netze möglicherweise nur gegen separate kostenpflichtige Lizenzen bereit.
- Bei freien Betriebssystemen kann man es selbst lösen, aber mit modernen Technologien kann das erheblichen Aufwand bedeuten.
- Im Entwicklungs- und Deployment-Prozess tauchen Probleme mit verschiedenen Paketmanagern und internen Repositories immer wieder auf.
- Je nach Paketmanager ist die Unterstützung für private interne Repositories unterschiedlich gut.
- Mehrere Paketmanager, Aufrufarten und Laufzeitumgebungen zusammen erhöhen die Komplexität.
- Auch TLS-Zertifikate interner Dienste sorgen für wiederkehrende Arbeit.
- Dienste in privaten Netzen verwenden oft keine Zertifikate, die in den Root-Programmen öffentlicher CAs enthalten sind.
- Manche Komponenten wie die JRE haben eigene Trust Stores, und in einigen Tech-Stacks hängt das Verhalten von der verwendeten Bibliothek ab.
- Selbst wenn es einen Trust Store des Betriebssystems gibt, sind separate Anpassungen nötig, wenn Tools ihren eigenen Speicher verwenden.
- Auch die Prüfung von Cloud-Lizenzen und Entitlements wird zum Hindernis.
- Manche Software versucht für die Prüfung von Cloud-Lizenzen nach außen zu verbinden.
- Workarounds reichen von zahlreichen Firewall-Ausnahmen bis zur Ausstellung angepasster Lizenzmodelle und können viel Zeit kosten.
- Schon der Prozess für Offline-Content-Updates kann auf Vendor-Seite kompliziert sein.
- In einem Fall mit Enterprise-Software musste man über ein veraltetes Kundensupport-Portal und zusätzlich ein separates Entitlement-Portal gehen.
- Das Anlegen von Accounts und Eskalationen dauerte mehr als drei Monate, und im finalen Portal gab es ein ungültiges TLS-Zertifikat.
- Das dokumentierte Verfahren zum Einspielen von Updates funktionierte nicht mehr, sodass ein langer E-Mail-Austausch mit Ingenieuren nötig war.
- Für eine einjährige Lizenz wurde ein fünfstelliger Betrag bezahlt, doch sie war fast abgelaufen, bevor die Nutzung überhaupt vorbereitet war; Verzögerungen bei der Verlängerung führten dann zum Ausfall einer CI-Pipeline.
- Die Schwierigkeit des Offline-Betriebs besteht nicht darin, dass einzelne Aufgaben unmöglich wären, sondern darin, dass alles ein wenig schwieriger wird — eher ein death by a thousand cuts.
- Produkte, die nicht für Offline-Umgebungen konzipiert wurden, werden oft mit Ad-hoc-Skripten und Notlösungen betrieben; die daraus entstehenden technischen Schulden landen dann beim Kunden, der die Offline-Umgebung betreibt.
- Red Hat geht mit diesem Bereich vergleichsweise gut um, aber die eingesparte Zeit bezahlt man entsprechend in bar.
Solche Umgebungen sind selten und auf bestimmte Branchen konzentriert
- Die starken Formen nicht internetverbundener Umgebungen finden sich vor allem bei Verteidigung und Nachrichtendiensten.
- Auch einige Banken praktizieren eine starke Netzwerksegmentierung.
- Verteidigung, Nachrichtendienste und Banken gelten zugleich als Branchen mit hohen Kosten und langen Laufzeiten — nicht unabhängig von dieser Betriebsweise.
- Schwächere Formen eingeschränkter Konnektivität finden sich vor allem in stark regulierten Branchen wie Finanzwesen und Gesundheitswesen.
- Gelegentlich gibt es auch gewöhnliche Softwareunternehmen, die Netzwerke aus Sicherheitsgründen sehr stark abschotten.
Praktische Reaktionen, die heute möglich sind
- Dass weniger Systeme mit dem Internet verbunden sein sollten, ist grundsätzlich keine schlechte Idee.
- Allerdings ist die heutige Softwareindustrie nicht darauf vorbereitet, dass sich Systeme ohne oder mit nur eingeschränkter Internetverbindung bequem betreiben lassen.
- Ein realistischerer Ansatz als der Ruf nach vollständiger Trennung ist es, eingeschränkte Konnektivität und Offline-Tauglichkeit zu verbessern.
-
Netzwerkregeln so weit wie möglich einschränken
- Auf möglichst viele Systeme sollten restriktive Netzwerkregeln angewendet werden.
- Cloud-Anbieter machen solche Konfigurationen heute leichter als früher.
- Bei AWS ist es nicht ganz einfach, eine praktikable Umgebung ohne Internetrouting zu betreiben, aber auch nicht unmöglich schwer.
- Bleibt man innerhalb des Bereichs von AWS Managed Services, hält sich der Schmerz meist in Grenzen — allerdings zu Kosten.
-
Software mit Blick auf Offline-Umgebungen entwickeln
- Funktionen, die nach außen verbinden müssen, sollten sich nach Möglichkeit deaktivieren lassen.
- Wenn Deaktivieren schwer ist, sollte der Kunde die verwendeten Endpoints ändern können.
- Wenn Endpoints austauschbar sind, braucht der Kunde auch eine Möglichkeit, eigene Endpoints zu betreiben.
- Bei einfachen statischen Dateien lässt sich das leicht mit etwas wie nginx und einem Verzeichnis bereitstellen.
- Bei einer API muss man dem Kunden unter Umständen auch die interne Implementierung ausliefern, was zusätzlichen Wartungsaufwand erzeugt.
-
TLS- und Abhängigkeitsannahmen reduzieren
- In Offline-Umgebungen werden schon kleine Annahmen über Verbindungen zu anderen Diensten komplex.
- Man sollte nicht annehmen, dass Let’s Encrypt erreichbar ist.
- Offline-Umgebungen bringen fast immer eine interne Zertifizierungsstelle mit sich.
- Man sollte den system trust store verwenden.
- Anforderungen oder Abhängigkeiten sollten nicht erst zum Zeitpunkt des Deployments beschafft werden.
- Docker hatte den Vorteil, Pakete selbstenthaltend zu machen, aber es gibt Container, die nicht einmal starten, wenn sie kein npm-Repository erreichen.
- Wenn für jeden Docker-Container der TLS-Trust-Store angepasst werden muss, kann Docker in Offline-Umgebungen die Verwaltung eher erschweren als erleichtern.
Die Beziehung zwischen dem CrowdStrike-Ausfall und Internetverbindung
- Zum CrowdStrike-Ausfall wurde mehrfach gefragt: „Warum war das überhaupt mit dem Internet verbunden?“ — doch die Frage der Internetverbindung steht zu dem damaligen Problem fast orthogonal.
- CrowdStrike-Content-Updates gehören im Idealfall gerade zu der Art von Updates, die auch in Offline-Umgebungen schnell bereitgestellt werden sollten.
- In realen stark abgeschotteten Offline-Umgebungen können interne CrowdStrike-Update-Mirrors jedoch Tage, Wochen, Monate oder Jahre hinterherhinken.
- Solche Verzögerungen können zwar dazu führen, dass ein Problem vermieden wird, aber das gleicht eher einem Zufall, bei dem zwei Fehler sich gerade so gegenseitig aufheben.
1 Kommentare
Meinungen auf Hacker News
Ich arbeite im Bereich Sicherheit/Systeme/Betrieb, stimme dieser Prämisse aber grundsätzlich nicht zu. Ich verstehe, dass der Autor sagt, es sei „nicht so einfach“, und stimme dem voll zu, aber das heißt nicht, dass man gute Arbeit leistet.
Leider machen die meisten ihre Arbeit nicht gut, und die gesamte Branche ist so gestaltet, dass sie auch dann überleben kann, wenn schlecht gearbeitet wird, während es schwer gemacht wird, gute Arbeit zu leisten.
Wenn man Digital Signage ausrollt, sollte Netzwerkzugriff nur für die IP-Adressen meiner Server auf eine Allowlist gesetzt werden, und es sollten nur Verbindungen akzeptiert werden, die über signierte Updates und Certificate Pinning abgesichert sind.
Damit wird es für entfernte Angreifer nahezu unmöglich, etwas anzurichten. Wenn man sich die Sicherheitsindustrie ansieht, die durch die Verbreitung des Internet of Things (IoT) gewachsen ist, gibt es ganz sicher Signage oder andere IoT-/SCADA-/Deployment-Geräte mit offenen Ports und Standardpasswörtern.
IoT sind einfach Computer, aber es sind auch Computer, die noch stärker vernachlässigt werden als Server oder virtuelle Maschinen, die schon nicht ordentlich betrieben werden.
Es gibt auch Stellen, die es gut machen, aber sie sind eine winzige Minderheit, weil die Struktur nicht darauf ausgelegt ist, gutes Arbeiten zu belohnen. „Best Practices“ oder Herstelleranweisungen zu befolgen bedeutet oft nicht, dass man es gut macht, sondern nur, dass man gerade genug getan hat, damit der Hersteller Support leistet, und in vielen Fällen bedeutet es uneingeschränkten Netzwerkzugriff.
Man muss sich weiterhin um Netzwerk-Bugs, kryptografische Schwachstellen, Fehlkonfigurationen und andere Probleme sorgen, durch die ein entfernter Angreifer das System missbrauchen kann. Wenn man dieses Argument vorbringen will, braucht man ein Beispiel, das buchstäblich nicht mit dem Internet verbunden ist, nicht nur eines, das stärker abgesperrt wurde.
Ich verstehe nicht ganz, wo du anderer Meinung bist als der Blogautor. Oder meinst du, dass es grundsätzlich unmöglich ist, die Sicherheit von mit dem Internet verbundenen Systemen zu verbessern, weil die Leute dazu nicht in der Lage sind?
In Schweden gibt es ein vom Internet getrenntes privates Netz namens Sjunet, das von Gesundheitsdienstleistern genutzt wird. Ziel ist es, Computer zu wertvollen Kommunikationsgeräten zu machen, ohne die Krankenhaus-IT dem gesamten Internet auszusetzen.
Von Sjunet-Mitgliedern wird erwartet, dass sie ihr eigenes Netzwerk kennen und ihre IT streng kontrollieren.
Man kann Sjunet als eine branchenweite Air-Gap-Umgebung betrachten. Es verbessert die Sicherheit und dürfte zugleich weniger kosten, als wenn jede Organisation ihr eigenes Air-Gap-Netz mit einer riesigen Allowlist betreibt.
Es vermittelt ein falsches Sicherheitsgefühl und dient auch als Ausrede für schlechte Sicherheitsrichtlinien. Die Bandbreite ist niedrig und teuer.
Es ist ein Netzwerk, das Einrichtungen wie Kreis- und Stadtverwaltungen verbindet und ihnen Zugriff auf zentrale Datenbanken mit personenbezogenen Daten von Bürgern gibt. Es wird für Dinge wie Adressänderungen, die Ausstellung neuer Ausweise sowie die Registrierung von Geburten und Eheschließungen genutzt.
Soweit ich weiß, läuft die „Źródło“-App auf einem separaten „Air-Gap“-Computer, der keinen Internetzugang hat, aber Zugriff auf das interne Netz besitzt, und sie authentifiziert sich über ein kryptografisches Client-Zertifikat auf einer Smartcard.
Sind alle auf dem neuesten Patchstand? Weiß man, dass die Leute nicht einfach beliebige USB-Geräte einstecken?
Es wäre schön, wenn es ähnlich wie Tor wäre, nur ohne die dubiosen Dinge.
Als Steuerungsingenieur habe ich Hunderte Maschinen gebaut. Es gibt Ethernet-Kabel für Feldbus-Netzwerke, aber sie dürfen niemals mit dem Internet verbunden werden.
In jedem Werkzeug- und Formenbaubetrieb im Industriegebiet nebenan stehen CNC-Maschinen mit Ethernet-Port, die nicht ins Internet gehören. Jede Fertigungsanlage mit Sondermaschinen, Förderlinien, Pressen, Robotern, CNCs, Pumpstationen usw. nutzt Ethernet, aber auch PLC- und HMI-Systeme, die nicht für eine Exposition im Internet geeignet sind.
Der Artikel sagt, moderne Arbeitscomputer seien fast hauptsächlich Kommunikationsgeräte und es gebe nicht viele produktive Arbeitssysteme, die Wert schaffen, ohne mit anderen Geschäftssystemen verbunden zu sein. Dabei ignoriert er aber die gesamte Fertigungsindustrie und die elektronischen Geräte, die diese Industrie herstellt.
Millionen eingebetteter Systeme und PLCs prüfen alle 1 Millisekunde, ob sich der Zustand physischer und logischer digitaler Eingänge geändert hat, und wenn ja, ändern sie den Zustand physischer und logischer digitaler Ausgänge und schaffen so den ganzen Tag Wert.
In ein Widerstandsschweißgerät, dessen Gusskörper vor über 100 Jahren hergestellt wurde und dessen letztes Update 2003 darin bestand, eine PLC und einen Schwarzweißbildschirm zur Rezepteinstellung anzubauen, muss man kein Sicherheitssystem von 2024 einbauen. Man geht mit dem Klemmbrett hin, gibt die Sollwerte ein und schmilzt den Stahl präzise.
Um sich mit solchen Maschinen zu verbinden, nimmt man normalerweise einen Laptop und ein Ethernet-Patchkabel und geht bis vor die Maschine. Wenn mehr nötig ist, erwartet man vom Kunden, sie in ein Operational-Technology(OT)-Netzwerk mit Firewall zu stellen oder mit SCADA/VPN-Geräten wie Tosibox oder Ixon Information Technology (IT) und OT zu verbinden.
Was du betreust, ist vielleicht nichts, das jemand ausnutzen möchte, aber PLCs findet man häufig in kritischer Infrastruktur und High-End-Fertigungsanlagen, deshalb sind sie für böswillige Akteure attraktive Ziele. Sie könnten versuchen, kritische Infrastruktur auszunutzen, oder Geräte mit schwacher Sicherheit zu infizieren, an die sich eines Tages hochwertige Endpunkte wie Engineering-Laptops direkt anschließen könnten.
https://www.cisa.gov/news-events/cybersecurity-advisories/aa... - Water Infra
https://claroty.com/team82/research/evil-plc-attack-using-a-...
Ich bin weiterhin nicht überzeugt von dem Argument, man dürfe Systeme nicht air-gappen, weil man dann keine internetzentrierten Entwicklungspraktiken nutzen könne. Ich halte dieses Argument für absurd.
Wenn ein System so beschaffen ist, dass man seinen Ethernet-Port mit Epoxidharz versiegeln muss, hätte es von Anfang an nicht mit internetzentrierten Entwicklungspraktiken programmiert werden dürfen. Eine MRT-Maschine zieht beim Booten JS-Abhängigkeiten von NPM? Direkt ins Gefängnis. Nicht metaphorisch, sondern tatsächlich.
Nachdem ich ein Video gesehen hatte, in dem jemand an einem McDonald’s-Kiosk herumspielt, habe ich angefangen, dasselbe mit Geräten zu versuchen, die man an verschiedenen Orten sieht.
In einem Foodcourt gab es einen Kiosk mit Windows und vollständigem Internetzugang. Jemand hätte Malware herunterladen und Kreditkartendaten stehlen können. Jedes Mal, wenn ich ihn benutzte, schaltete ich ihn aus oder hinterließ eine Nachricht auf dem Bildschirm, und irgendwann stellten sie ihn in den Kioskmodus um.
Ein anderes Gerät war ein Parkautomat, der überhaupt nicht gehärtet war. Die Kriminellen scheinen es noch nicht bemerkt zu haben.
Das dritte war ein interaktives Display einer Biermarke. Es war nichts, womit man großen Schaden anrichten konnte, aber es fühlte sich gut an, Notepad zu öffnen und „Drink water“ zu hinterlassen. Am Ende haben sie es ausgeschaltet, und auch das ist eine Lösung.
„Kein Geld an zufällige Passanten auszahlen“ sollte ziemlich weit oben auf der Anforderungsliste stehen, aber in der Realität war das offenbar nicht der Fall.
Dieser Teil spricht mir wirklich aus der Seele. Ich habe versucht, IntelliJ verständlich zu machen, dass der JRE-Truststore ein neues Zertifikat für zscaler verwenden muss. Es gab zwei oder drei auswählbare JDKs, und ich habe das neue Zertifikat in jeden einzelnen Truststore gelegt, aber es funktionierte immer noch nicht, und ich hatte keine Ahnung warum.
Es gibt auch hamnet. Auf dem 44Net-IP-Block ist ein Teil ins Internet routbar und ein Teil nicht.
https://hamnetdb.net/map.cgi
Weil Amateurfunk-Frequenzbänder verwendet werden, gibt es interessante Einschränkungen. Kommerzielle Nutzung ist vollständig verboten.
Das ist der soziale Vertrag dieses Frequenzbereichs: Man bekommt günstigen Zugang zu vielen Bändern von 136 kHz bis 241 GHz, darf damit aber kein Geld verdienen.
Nur in den Niederlanden und in Deutschland ist es ziemlich weit verbreitet: https://hamnetdb.net/map.cgi . Hier in Spanien kann ich es nirgendwo in meiner Nähe nutzen.
Es scheint ziemlich offensichtlich, dass Buchungssysteme von Fluggesellschaften zumindest ans Netzwerk angeschlossen sein müssen, und ich habe kaum jemanden gehört, der behauptet, alles müsse offline sein. Aber ich habe zum Beispiel auch gehört, dass eine Drehmaschine in einer Werkstatt durch diesen Vorfall ausgefallen ist.
Ob sie wirklich online sein musste, sollte man überdenken. Natürlich wird es Gründe geben, aber diese Gründe muss man gegen das Risiko abwägen.
Außerdem gibt es viele noch absurdere Beispiele, die mit dem Internet verbunden sind, etwa Kühlschränke, Wasserkocher oder Garagentore. Ich weiß nicht, ob solche Dinge vom CrowdStrike-Vorfall betroffen waren, aber selbst wenn nicht, ist es beim nächsten Mal nur eine Frage der Zeit.
Zu der Behauptung, nicht verbundene Systeme seien „sehr, sehr nervig“: Aus meiner Erfahrung als Nutzer ist jede Sicherheit „sehr, sehr nervig“. Zwei-Faktor-Authentifizierung, verpflichtende Passwortwechsel, gesperrte Geräte, Malware-Scanner, Link-Sanitizer – manches davon ist nötig und manches Unsinn, aber ich bin nicht befugt zu entscheiden, was was ist. Sicher ist nur, dass alles Reibung erzeugt.
Meine wichtigste Schlussfolgerung ist nicht: „Alle diese Systeme dürfen nicht mit dem Internet verbunden sein“, sondern ein paar andere Dinge.
Erstens sollten solche Systeme ausgehende Netzwerkflüsse nicht zulassen. Dann werden alle automatischen Updates blockiert, und danach kann man sie über interne Bereitstellungskanäle verwalten.
Zweitens lässt sich, selbst wenn man das nicht tut, bei vielen Enterprise-Softwareprodukten die automatische Aktualisierung abschalten. Windows ist ein typisches Beispiel, und CrowdStrike selbst ebenso. Ich habe gehört, dass es unter den CS-Kunden welche gab, die automatische Updates deaktiviert und manuell ausgerollt haben und so dem Schaden entgangen sind.
Drittens sollten Updates, ergänzend zu Punkt 2, nach einem kleinen Smoke Test schrittweise ausgerollt werden. Nur für den Fall. Auch hier habe ich gehört, dass es unter den CS-Kunden welche gab, die durch ein schrittweises Rollout verhindern konnten, dass mehr als nur ein Teil der Geräte betroffen war.
Der Text fasst ziemlich gut die Zeit zusammen, in der wir hochmoderne KI-Lösungen an Militärkunden geliefert haben. 80 % des Aufwands flossen darin, Tools, die Internet voraussetzen, in Air-Gap-Umgebungen reibungslos zum Laufen zu bringen.