Das Gerät, das Sie nicht patchen können

Warum das Netzwerk zur letzten Verteidigungslinie für OT-, IoT- und Medizingeräte geworden ist

Irgendwo in Ihrem Netzwerk läuft ein Gerät mit einem Betriebssystem, das bereits End-of-Support erreicht hat, bevor einige Ihrer Kollegen die Schule beendeten. Es könnte ein Ultraschallgerät, ein Gebäudemanagementsystem, ein Kartenleser, ein HMI auf einer Produktionslinie oder ein Laboranalysegerät sein, das mehr kostet als ein Firmenwagen. Sie wissen, dass es ein Risiko darstellt. Sie haben es angesprochen. Und Ihnen wird, höflich und wiederholt, mitgeteilt, dass es nicht gepatcht werden kann.

Diese Antwort ist normalerweise korrekt. Der Hersteller hat das Update nicht zertifiziert. Die behördliche Genehmigung gilt für einen bestimmten Software-Build und eine Neuvalidierung dauert Monate. Ein Wartungsvertrag erlischt, wenn Sie das Image ändern. Das Gerät läuft 24/7 in einer klinischen oder Produktionsumgebung, in der ein Neustart nicht einfach ein Klick ist, sondern eine geplante Aktivität. Oder der Hersteller des Geräts existiert einfach nicht mehr.

Der ehrliche Ausgangspunkt für alle, die heute ein Unternehmensnetzwerk betreiben, ist dieser: Ein erheblicher Teil der Geräte in Ihrem Netzwerk wird niemals gepatcht, wird nie einen Endpoint-Agent ausführen und wird nicht innerhalb Ihres Planungshorizonts ersetzt. Jede Sicherheitsmaßnahme, die von etwas anderem ausgeht – EDR-Abdeckung, agentenbasierte Statusprüfungen, automatisierte Patch-Compliance – hat genau dort eine Blindstelle, wo Ihre operativ kritischste Ausrüstung steht.

Wenn sich der Endpoint nicht selbst verteidigen kann, muss das Netzwerk dies stattdessen tun.

Warum die klassische Antwort nicht mehr funktioniert

Die klassische Antwort war, diese Geräte irgendwo anders unterzubringen. Ein medizinisches VLAN. Ein VLAN für Gebäudemanagement. Ein VLAN für Kameras. Firewall dazwischen und alles andere, und weitermachen.

Es funktioniert, bis es nicht mehr skaliert. Drei Dinge zerstören diesen Ansatz:

Die Geräteanzahl. Die Segmentierung nach Kategorie war mit einigen hundert Geräten überschaubar. Zusammengelegte Campus haben nun Tausende von Geräten, die ständig hinzukommen, oft von einem Facility-Contractor oder einem klinischen Techniker installiert, die vernünftigerweise keine Änderungsanfrage beim Netzwerk-Team eingereicht haben.

Das statische ACL-Problem. Das statische ACL-Problem. Jede Ausnahme – der Support-Tunnel des Service-Partners, der Monitoring-Server, der jeden Subnet erreichen muss, die neue Integration mit dem Patientendatensystem – wird zu einer weiteren Regel. Nach einigen Jahren kann niemand mehr etwas sicher entfernen, also wächst die Regelbasis nur noch. Die Segmentierung existiert in der Dokumentation, während die effektive Richtlinie im Stillen zu „überwiegend erlaubt" geworden ist.Der physische Standort entspricht nicht mehr der Richtlinie. Ein VLAN ist an den Ort gebunden, wo ein Gerät angeschlossen ist. Geräte wandern zwischen Abteilungen, Stockwerken und Gebäuden. Kabellose Geräte wandern ständig umher. Eine Richtlinie, die an einen Switch-Port oder eine SSID gebunden ist, zerfällt, sobald sich die physische Infrastruktur ändert, und die Lösung ist immer, das VLAN zu verbreitern.Das Ergebnis ist vertraut: ein Netzwerk, das in der Designdokumentation segmentiert ist und in der Praxis flach. Und flach ist genau die Bedingung, die Ransomware braucht. Der anfängliche Fuß in der Tür ist selten das ungerätschte Gerät, es ist ein phished-Benutzerkonto. Das ungerätschte Gerät macht den Unterschied zwischen einem Incident, der eine Abteilung betrifft, und einem, der das ganze Krankenhaus betrifft.

Der physische Standort entspricht nicht mehr den Richtlinien. Ein VLAN ist an den Ort gebunden, wo ein Gerät angeschlossen ist. Geräte wandern zwischen Abteilungen, Stockwerken und Gebäuden. Kabellose Geräte wandern ständig umher. Eine Richtlinie, die an einen Switch-Port oder eine SSID gebunden ist, zerfällt, sobald sich die physische Infrastruktur ändert, und die Lösung ist immer, das VLAN zu verbreitern.

Das Ergebnis ist vertraut: ein Netzwerk, das in der Designdokumentation segmentiert ist und in der Praxis flach. Und flach ist genau die Bedingung, die Ransomware braucht.

Der anfängliche Fuß in der Tür ist selten das ungerätschte Gerät, es ist ein phished-Benutzerkonto. Das ungerätschte Gerät macht den Unterschied zwischen einem Incident, der eine Abteilung betrifft, und einem, der das ganze Krankenhaus betrifft.

Drei Fähigkeiten, die das Ergebnis wirklich verändern

Wissen Sie kontinuierlich, was vorhanden ist. Nicht ein jährliches Inventar-Spreadsheet. Passive Profilierung, die Geräte danach identifiziert, wie sie sich im Netzwerk verhalten – DHCP-Fingerabdrücke, Protokollnutzung, Verkehrsmuster, MAC-Besitzerschaft – und kennzeichnet alles, das auftaucht und das Sie nicht erwartet haben.

In fast jeder Discovery-Übung übersteigt die Anzahl der verbundenen Geräte die CMDB-Anzahl. Die Lücke ist dort, wo das Risiko lauert.

Das Ausmaß dieser Lücke wird konsequent unterschätzt. In einer veröffentlichten runZero-Fallstudie der University of York, ein Campus mit 54.000 Studenten, endeten sie mit Sichtbarkeit von 25.000 Assets – etwa zweieinhalb Mal mehr als sie zuvor sehen konnten. Die Erklärung ihres CISO ist überdenkenswert: Ihre Netzwerkverwaltungstools waren gut bei der Verwaltung des Netzwerks, aber nicht bei der Sichtbarmachung der damit verbundenen Geräte.

Das sind zwei unterschiedliche Fähigkeiten, und die meisten Organisationen verfügen nur über eine davon.

Bestimmen Sie, was jedes Gerät mit welchen Systemen kommunizieren darf. Eine Infusionspumpe muss drei Server erreichen. Eine Kamera braucht den Network Video Recorder. Ein Türcontroller braucht seinen Access-Control-Server. Keines davon benötigt das Internet, den Dateiserver oder sich gegenseitig.

Erfassen Sie zunächst den tatsächlichen Datenverkehr in der Basis, und schreiben Sie dann die Richtlinie auf Grundlage dessen, was Sie beobachten, nicht auf Grundlage dessen, was die Herstellerdokumentation behauptet. Die Referenzarchitektur ist fast immer freizügiger als das erforderliche Ausmaß.

Erzwingen Sie es am Anschlusspunkt. Dies ist der Teil, der das Modell funktionsfähig hält. Richtlinien sollten an die Geräteidentität gebunden und auf der Zugriffsebene – den Port oder Access Point, wo es sich verbindet – angewendet werden, statt bei einer drei Hops entfernten Firewall.

Wenn die Durchsetzung dem Gerät folgt, ändert sich bei der Verlagerung zwischen Gebäuden nichts, und die laterale Bewegung zwischen zwei Geräten auf dem gleichen Switch wird blockiert statt unsichtbar zu bleiben.

Wie Sie es tun, ohne den Betrieb zu unterbrechen

Der Grund, warum diese Projekte zum Stillstand kommen, ist Angst, und diese Angst ist berechtigt: Niemand möchte derjenige sein, dessen Segmentierungsrichtlinie einen Eingriff unterbrochen hat. Sequenzierung löst das meiste davon.

1. Entdecken Sie passiv, bevor Sie etwas durchsetzen. Wochen, nicht Tage. Nichts ändert sich im Netzwerk während dieser Phase, daher gibt es kein Risiko zum Verhandeln.
2. Modellieren Sie Richtlinien im Monitormodus. Führen Sie die beabsichtigten Regeln aus und protokollieren Sie, was blockiert worden wäre. Dies verwandelt eine Diskussion über Risiken in eine Überprüfung eines Berichts und deckt normalerweise zwei oder drei legitime Flüsse auf, die niemand dokumentiert hat.
3. Beginnen Sie mit einer Gerätegruppe, die ein hohes Risiko und eine niedrige seitliche Reichweite hat. Kameras und Gebäudemanagement sind ideale erste Kandidaten: Der Sicherheitsvorteil ist real und die operativen Einsätze sind niedriger als bei klinischen oder Produktionsgeräten.
4. Beziehen Sie die Geräteeigentümer frühzeitig ein. Klinische Technik, Facilities, OT-Technik. Sie wissen Dinge, die das Netzwerk Ihnen nicht sagen kann – dass der Analysator nachts zum Hersteller hochlädt, dass ein Lieferant vierteljährlich anruft zum Kalibrieren. Sie haben auch ein informelles Veto: Das erste Mal, wenn eine Richtlinie für ein Betriebsproblem verantwortlich gemacht wird, wird sie aufgehoben, und einmal aufgehoben, kommt sie selten zurück. Die Richtlinie, die Sie ohne sie aufzwingen, hält bis zum ersten Incident. Die Richtlinie, auf die Sie sich einigen, übersteht es.
5. Erweitern Sie nach Gruppen, mit einem Rollback-Pfad pro Gruppe. Jeder Schritt sollte unabhängig rückgängig gemacht werden können.

Es lohnt sich, die Maßnahmen voraus zu vereinbaren, denn „wir sind sicherer" übersteht ein Budget-Gespräch nicht. Nützliche Kennzahlen: Zeit zur Identifizierung eines unbekannten Geräts im Netzwerk, Prozentsatz der Zugriffsstellen unter dynamischer Richtlinie und die Anzahl der Ziele, die ein kompromittiertes Gerät in jeder Gruppe erreichen könnte – sein Blast-Radius, und dessen Sinken ist der klarste Beweis dafür, dass das Programm funktioniert.

Der Compliance-Aspekt, kurz zusammengefasst

Wenn Sie als NIS2-essentieller oder wichtiger Bereich tätig sind, lassen sich die Verpflichtungen zu Asset-Management, Zugriffskontrolle und Incident-Erkennung ohne diese Fähigkeit ehrlich kaum erfüllen. Sie können nicht über einen Incident im erforderlichen Zeitrahmen berichten, wenn es Tage dauert, um festzustellen, was ein Gerät ist und was es erreicht hat.

ISO/IEC 27001 und die technische Implementierungsleitlinie der ENISA machen die Erwartungen ziemlich deutlich, und die nationalen Rahmen, die sich daraus in jedem Mitgliedstaat ableiten, sagen im Grunde das Gleiche in lokalen Begriffen. Die meisten Organisationen stellen fest, dass das Segmentierungsprojekt, das sie aus Sicherheitsgründen aufgeschoben haben, jetzt aus Compliance-Gründen erforderlich ist – was pragmatisch oft das Budget freischaltet.

Wo Damovo anschließt

Wir entwerfen und betreiben Campus-Netzwerke, bei denen dieses Modell Standard ist statt eine nachträgliche Ergänzung – Geräteprofilierung und Richtliniendurchsetzung in der Zugriffsebene integriert, mit Plattformen, die Ihre Kunden bereits nutzen, einschließlich Cisco Identity Services Engine und Extreme Networks Fabric und Universal ZTNA Policy, mit runZero für agentlose Asset-Discovery in IT, OT und IoT. Wir führen die Discovery- und Monitor-Mode-Phasen als strukturiertes Engagement durch, sodass Sie Ihren tatsächlichen Gerätebestand und Ihre tatsächliche Traffic-Baseline sehen, bevor Sie sich auf die Durchsetzung festlegen, und wir können den Policy-Lifecycle als verwaltete Dienste betreiben, wenn das interne Team nicht die Kapazität hat, ihn selbst zu verwalten.

Wenn Sie wissen möchten, wie viele Geräte tatsächlich in Ihrem Netzwerk vorhanden sind, ist das das Gespräch, mit dem Sie beginnen sollten.