Wenn die Netzwerkgrenze ihr Versprechen nicht mehr hält

Es ist ein gewöhnlicher Nachmittag auf der Intensivstation, als ein Patientenmonitor beginnt, Messwerte an eine IP-Adresse außerhalb des Hauses zu senden, die in keiner Dokumentation auftaucht. Der Monitor selbst hängt im internen Netz, hinter der Firewall, genau dort, wo die klassische Netzwerkarchitektur automatisch von Vertrauen ausgeht. Für Sie als IT-/OT-Sicherheitsverantwortliche eines Klinikums mit mehreren Stationen und zahlreichen vernetzten Medizingeräten ist das kein Gedankenspiel, sondern der Moment, in dem sich zeigt, dass ein Gerät im eigenen Netz nicht automatisch ein vertrauenswürdiges Gerät ist.

Der Perimeter-Gedanke, auf dem die meisten Kliniknetze bis heute aufbauen, stammt aus einer Zeit mit klar gezogenen Grenzen: eine Firewall am Rand, dahinter ein internes Netz, dem pauschal vertraut wurde, weil es angeblich nur eigene Geräte enthielt. Innerhalb dieses internen Netzes reichte oft eine grobe Unterteilung nach Stationen oder Gerätetyp aus, weil ein Angreifer ohnehin erst durch die Außengrenze musste, bevor er überhaupt etwas erreichen konnte.

Dieses Modell hält nicht mehr, weil sich die Angriffsfläche längst nach innen verschoben hat. Infusionspumpen, Beatmungsgeräte und Patientenmonitore hängen heute im selben Netz wie Verwaltungssysteme, oft mit Software, die sich nicht ohne Weiteres patchen lässt. Hersteller warten ihre Geräte aus der Ferne, klinische KI-Systeme lesen Laborwerte, Bildgebung und Verlaufsdaten aus mehreren Quellen zugleich, und jedes dieser Systeme wird zu einem möglichen Einstiegspunkt, sobald es einmal im internen Netz sitzt. Wer sich allein auf die Außengrenze verlässt, hat für den Fall, dass genau dort etwas durchrutscht, keine zweite Verteidigungslinie mehr übrig — und in einer Klinik ist der Unterschied zwischen einer durchgerutschten E-Mail und einem manipulierten Patientenmonitor kein abstraktes Risiko.

Genau an diesem Punkt setzt Zero Trust an, wie es das NIST-Rahmenwerk SP 800-207 beschreibt: Vertrauen wird nicht mehr aus dem Standort im Netz abgeleitet, sondern für jede einzelne Ressource neu bewertet. Wie eine Klinik im laufenden Angriff Systeme stufenweise abschaltet, ist eine eigene Frage, die ein anderer Beitrag zu diesem Themenblock behandelt; hier geht es um die Architektur, die diesem Moment vorausgeht und entscheidet, wie viel ein einzelnes kompromittiertes Gerät überhaupt erreichen kann.

Was Zero Trust nach NIST SP 800-207 tatsächlich verändert

NIST veröffentlichte die Sonderpublikation SP 800-207 im August 2020. Sie beschreibt Zero Trust als ein sich entwickelndes Bündel von Sicherheitsparadigmen, das die Verteidigung von einem statischen, netzwerkbasierten Perimeter weg und hin zu Nutzern, Geräten und einzelnen Ressourcen verschiebt. Der Begriff Ressource ist dabei bewusst weit gefasst: Er meint jedes Gerät, jeden Dienst, jeden Arbeitsablauf und jedes Konto, auf das zugegriffen wird — nicht das Netzwerksegment, in dem es liegt.

Das NIST-Rahmenwerk SP 800-207 definiert Zero Trust als Wechsel vom statischen Netzwerkperimeter zum Schutz einzelner Ressourcen — kein Gerät und kein Konto gilt allein deshalb als vertrauenswürdig, weil es sich im internen Netz befindet. Für ein Kliniknetz bedeutet das einen Bruch mit der bisherigen Logik: Ein Beatmungsgerät im Stationsnetz ist danach nicht automatisch vertrauenswürdiger als ein Laptop im Gästenetz, weil beide für sich genommen bewertet werden.

Bewertet wird dabei nicht einmalig, sondern je Zugriff, und zwar anhand des Kontexts: Welche Identität steht hinter der Anfrage, in welchem Zustand befindet sich das anfragende Gerät, zu welcher Uhrzeit und von welchem Ort aus geschieht der Zugriff, und passt das Verhalten zum bisherigen Muster? Ein Wartungskonto, das plötzlich auf zwanzig Geräte gleichzeitig zugreifen will, obwohl sein bisheriges Muster ein einzelnes Gerät betraf, fällt in diesem Modell auf, unabhängig davon, ob es sich technisch im richtigen Segment befindet.

Was das Prinzip nicht mitliefert, ist für die Praxis ebenso wichtig.

Was Zero Trust nicht verspricht

Der Ansatz schützt die einzelne Ressource, nicht das Netzwerksegment, in dem sie steht — für Datenintegrität und Prozesssicherheit braucht es zusätzliche Maßnahmen. Ein Beatmungsgerät, dessen Zugriffsanfrage korrekt authentifiziert und autorisiert wurde, kann trotzdem falsche oder manipulierte Messwerte liefern; ob ein übertragener Wert klinisch plausibel ist, prüft Zero Trust nicht, das bleibt Aufgabe der medizinischen Systeme selbst.

Ebenso wenig lässt sich Zero Trust als Produkteigenschaft kaufen. NIST beschreibt Prinzipien, kein Prüfsiegel, und ein einzelnes Gerät oder eine einzelne Firewall kann ein ganzes Kliniknetz nicht „zero-trust-fähig“ machen, weil der Ansatz die Zusammenarbeit vieler Komponenten voraussetzt — Identitätsverwaltung, Netzwerksegmentierung, Protokollierung und Richtlinien, die alle ineinandergreifen müssen. Wer ein Gerät als bereits vollständig entsprechend verkauft, bewirbt eher eine Haltung als einen abgeschlossenen Zustand.

Auch die physische Sicherheitsfunktion eines Geräts liegt außerhalb dessen, was Zero Trust regelt: Ein mechanischer Not-Halt, wie ihn ein eigener Beitrag zur Sicherheit autonomer Roboter für Bewegungsgefahr an der einzelnen Maschine einordnet, schützt unabhängig davon, wie eine Netzwerkarchitektur das Gerät gerade bewertet — beide Ebenen ergänzen sich, ersetzen sich aber nicht.

Und ein einzelnes gesichertes Segment ist kein Beweis dafür, dass jedes Gerät darin für sich sicher ist: Innerhalb desselben Segments können weiterhin unterschiedlich vertrauenswürdige Geräte stehen, solange die Bewertung nicht auf der Ebene der einzelnen Ressource ansetzt. Genau diese Vermischung von Netzwerkfunktion und klinischer Kernfunktion wurde bei bestimmten Patientenmonitoren zum Sicherheitsproblem — und zeigt, wie sich beides in der Praxis trennen lässt.

Der Patientenmonitor, der zwei Funktionen in einem Gehäuse trug

Die US-Arzneimittelbehörde FDA veröffentlichte am 2. Juli 2025 eine aktualisierte Sicherheitsmitteilung zu bestimmten Patientenmonitoren der Hersteller Contec und Epsimed. Die FDA beschrieb bei diesen Geräten drei Schwachstellenklassen: unautorisierte Fernsteuerung, eine Backdoor-Funktion und Datenabfluss bei Internetverbindung. Alle drei Klassen setzten voraus, dass der Monitor überhaupt mit dem Internet verbunden war — ohne diese Verbindung blieben die eigentlichen Messfunktionen des Geräts unberührt.

Der FDA waren zum Zeitpunkt der Mitteilung keine dadurch verursachten Vorfälle, Verletzungen oder Todesfälle bekannt — eine Momentaufnahme, kein Dauerurteil.

Interessant für die eigene Netzwerkplanung ist vor allem, wie der Hersteller das Problem tatsächlich löste. Die tatsächlich umgesetzte Lösung entfernte am 2. Juli 2025 die Netzwerkfunktion der betroffenen Monitore vollständig — die Geräte lassen sich seither nur noch lokal nutzen.

An diesem Fall lässt sich eine Unterscheidung zeigen, die für jede Zero-Trust-Architektur in der Klinik trägt: Die klinische Kernfunktion eines Geräts — hier die Messung von Vitalwerten — und seine Netzwerkfunktion sind zwei getrennte Ressourcen mit unterschiedlichem Risiko, auch wenn sie im selben Gehäuse stecken. Wer beide als untrennbares Paket behandelt, kann die Netzwerkfunktion nicht kappen, ohne die Kernfunktion mitzutreffen — wer sie architektonisch trennt, kann genau das, was Contec am Ende umsetzte, schon vorher als Entwurfsentscheidung treffen, statt es erst nach einer Sicherheitsmitteilung nachzuholen.

Säule 1: Wissen, welches Gerät gerade tatsächlich im Netz spricht

Jede der folgenden drei Säulen setzt eine Voraussetzung, die banal klingt und in der Praxis trotzdem oft fehlt: zu wissen, welches Gerät und welcher Software-Agent gerade tatsächlich mit dem Kliniknetz spricht. Ohne diese Kenntnis lässt sich weder sinnvoll segmentieren noch autorisieren, weil jede Regel ein bekanntes Subjekt braucht, auf das sie angewendet wird.

Die US-Cybersicherheitsbehörde CISA veröffentlichte im April 2023 ihr Zero Trust Maturity Model in der zweiten Fassung; das Dokument selbst bleibt als Fachrahmenwerk brauchbar, auch wenn die CISA-Webseite es inzwischen als Altbestand kennzeichnet, der nicht notwendig die aktuelle Verwaltungspolitik widerspiegelt. Für Legacy- und mitgebrachte Geräte hält das Modell fest: CISA benennt Altgeräte mit eingeschränkten Authentifizierungsoptionen ausdrücklich als eigene Herausforderung für Zero Trust — Grundvoraussetzung ist ein laufend aktuelles Geräteinventar, kein einmaliger Stichtag.

In einer Klinik trifft das auf einen großen Teil der Medizingeräte zu: Infusionspumpen, ältere Bildgebungssysteme und viele eingebettete Steuerungen laufen mit Firmware, die kein modernes Zertifikat und keinen Sicherheitsagenten unterstützt. Für solche Geräte lässt sich Identität selten direkt herstellen, wohl aber indirekt kompensieren — über einen dedizierten Netzwerk-Proxy, über Zugriffskontrolle auf Portebene oder über ein Verhaltensprofil, das ungewöhnliche Kommunikationsmuster auffallen lässt, selbst wenn das Gerät selbst nichts von seiner eigenen Überwachung weiß.

Entscheidend ist, dass das Inventar nicht als einmalige Bestandsaufnahme vor einem Audit entsteht, sondern als laufender Abgleich: Jedes neu angeschlossene Gerät, jeder neue Software-Agent und jeder ausgetauschte Servicelaptop eines externen Technikers gehört in dieselbe, kontinuierlich aktualisierte Liste, bevor er überhaupt Zugriff bekommt.

Säule 2: Vom groben VLAN zur Mikrosegmentierung

Die zweite Säule setzt auf der ersten auf: Wer weiß, welches Gerät wo hängt, kann beginnen, das Netz so zu unterteilen, dass ein kompromittiertes Gerät nicht automatisch Zugriff auf alle anderen hat. Viele Kliniknetze kennen dafür bislang nur ein grobes Werkzeug, das VLAN — eine Sammelgruppe, die zum Beispiel „alle Medizingeräte einer Station“ in einem gemeinsamen Segment zusammenfasst.

CISA beschreibt den Weg von einem groben Perimeter-/VLAN-Segment zu einer Mikrosegmentierung je Anwendung beziehungsweise Gerät als Reifegrad, nicht als Alles-oder-Nichts-Umstellung. Zwischen diesen beiden Polen liegt eine Reihe von Zwischenstufen, die sich einzeln umsetzen lassen, ohne dass am ersten Tag jedes einzelne Gerät sein eigenes isoliertes Segment braucht.

Für ein Kliniknetz heißt das konkret: Statt eines einzigen Medizingeräte-VLANs, das Infusionspumpen, Patientenmonitore und Bildgebungsworkstations gleichermaßen umfasst, entstehen kleinere Gruppen entlang der tatsächlichen Kommunikationsbeziehungen — Infusionspumpen einer Station in einer eigenen Gruppe, Bildgebung in einer anderen, mit klar definierten, wenigen erlaubten Verbindungen zwischen ihnen. Ein kompromittierter Monitor erreicht dann nicht mehr automatisch die Steuerung einer Infusionspumpe im selben Haus, weil beide in getrennten Gruppen liegen, selbst wenn sie über dieselbe physische Verkabelung laufen.

Ein VLAN allein bleibt dabei eine Infrastrukturmaßnahme, keine Zero-Trust-Umsetzung, weil Vertrauen darin weiterhin an der Segmentzugehörigkeit hängt und nicht an der einzelnen Ressource. Wertvoll wird die Segmentierung erst in Kombination mit den anderen Säulen.

Säule 3: Rechte, die nicht von selbst bleiben

Die dritte Säule betrifft die Frage, wie lange eine einmal erteilte Berechtigung gültig bleibt. In vielen Kliniknetzen bekommt ein Konto beim Anlegen einen festen Satz an Rechten, der über Monate oder Jahre unverändert bleibt, selbst wenn sich die Aufgabe der Person oder des Systems längst geändert hat.

Zero Trust kehrt dieses Muster um: Statt einer einmaligen Vergabe steht eine wiederkehrende Prüfung, die Kontext wie Verhalten, Gerätezustand und aktuellen Auftrag einbezieht. Dieses Prinzip lässt sich auf klinische KI-Agenten übertragen, die im Normalbetrieb auf mehrere Systeme zugreifen — etwa auf Laborwerte, Bildgebung und die elektronische Patientenakte, um eine Diagnoseunterstützung oder eine Workflow-Funktion zu erfüllen: Ein klinischer Agent, der im Normalbetrieb auf viele Systeme zugreifen darf, sollte diese Rechte nicht automatisch dauerhaft und unverändert behalten — kontinuierliche statt einmalige Autorisierung ist ein Zero-Trust-Grundsatz.

Eine eigene NIST-Vorschrift, die genau das für Software-Agenten verlangt, gibt es dafür nicht; die Übertragung ist eine redaktionelle Einordnung, keine Normzitierung. Praktisch bewährt hat sich trotzdem, einen Auslöser für die erneute Prüfung zu definieren: Sobald ein Agent auf Systeme zugreifen will, die außerhalb seines bisherigen, dokumentierten Aufgabenbereichs liegen, oder sobald sich die Menge der abgefragten Datensätze plötzlich vervielfacht, sollte das eine erneute, bewusste Freigabe auslösen und nicht automatisch durchlaufen.

Wie sich Handlungen eines Agenten überhaupt zuverlässig einer Identität und einem Auftrag zuordnen lassen, vertieft ein eigener Beitrag zur Governance von KI-Agenten.

Wie viel Autonomie ein System in einer bestimmten Aufgabe überhaupt haben sollte und wie sich das nachweisen lässt, ordnet ein Beitrag zu Autonomiestufen und Sicherheitsnachweis ein. Für die Netzwerkarchitektur selbst zählt hier vor allem, dass Rechte ein Ablaufdatum brauchen, auch wenn die Aufgabe des Systems formal unverändert erscheint.

Säule 4: Der Wartungszugang als eigene Vertrauensgrenze

Ein Wartungszugang, den ein Medizingerätehersteller für Fernsupport nutzt, wird in vielen Kliniknetzen wie ein interner Account behandelt — einmal eingerichtet, dauerhaft aktiv, oft mit weitreichenden Rechten, weil ein Servicetechniker im Zweifel schnell an viele Systeme herankommen soll. Genau diese Bequemlichkeit macht den Fernzugang zu einer eigenen Vertrauensgrenze, die eine gesonderte Betrachtung braucht, unabhängig davon, wie vertrauenswürdig der Hersteller im Allgemeinen ist.

Herstellerzugänge sollten deshalb nicht dauerhaft offen sein. Sinnvoll sind zeitlich begrenzte Wartungsfenster, separate Identitäten, Mehrfaktor-Authentisierung, Session-Logging, möglichst wenige Rechte und ein Jump-Host als einzige Eintrittsstelle für solche Zugriffe. Übernimmt statt eines Menschen ein automatisierter Wartungsagent des Herstellers diese Aufgabe, gilt der Grundsatz umso strenger: Seine Berechtigung muss enger sein als die eines menschlichen Root-Accounts, weil ein Agent typischerweise schneller und in größerem Umfang handelt, als ein Mensch es in derselben Zeit könnte.

Ein dauerhaft offener Herstellerzugang ist selbst eine Zero-Trust-Lücke — zeitlich begrenzte Wartungsfenster, eigene Identitäten und ein Jump-Host sind der Unterschied zwischen kontrolliertem und unkontrolliertem Fernzugriff. Für besonders wichtige und wichtige Einrichtungen nennt § 30 Absatz 2 BSIG die Sicherheit der Lieferkette einschließlich der Beziehungen zu unmittelbaren Anbietern und Diensteanbietern ausdrücklich als Teil des Risikomanagements — als Randbedingung dieses Beitrags, nicht als eigener Pflichtenkatalog: § 30 BSIG nennt Lieferkettensicherheit ausdrücklich als Teil des Risikomanagements — die vollständige Pflichtenlage für das eigene Haus behandelt ein eigener Beitrag zur Klinik-Cybersicherheit, nicht dieser Text.

Am wirksamsten lassen sich diese Bedingungen vor der Unterschrift durchsetzen, nicht danach: ein Wartungsfenster, ein Jump-Host und eine widerrufbare Identität gehören in den Wartungsvertrag, nicht in eine spätere Bitte an den Lieferanten. Wer sie erst einfordert, wenn das Gerät schon in Betrieb ist, verhandelt aus der schwächeren Position, weil ein Rückbau der bestehenden Zugriffslogik aufwändiger ist als eine Vertragsklausel vor der Bestellung.

Die Prüffrageliste: vier Säulen zum Selbst-Abklopfen

Die vier Säulen lassen sich in eine kompakte Prüffrageliste übersetzen, mit der Sie die eigene Netzwerkarchitektur an konkreten Fragen abklopfen, statt bei der allgemeinen Prinzipienebene zu bleiben. Jede Zeile benennt zusätzlich ein Warnzeichen: woran sich ein Rückstand in der Praxis erkennen lässt, nicht nur, was im Idealfall gelten sollte. Die acht Fragen decken die vier Säulen paarweise ab, damit sich sowohl der aktuelle Stand als auch der nächste sinnvolle Schritt ablesen lässt.

Am aussagekräftigsten wird die Liste, wenn Sie sie nicht als einmaliges Ausfüllen behandeln, sondern als wiederkehrenden Termin — nach jeder größeren Anschaffung, nach jedem neuen Wartungsvertrag und nach jeder Erweiterung der klinischen KI-Systeme. Wer die Prüffrageliste durchgeht, verschafft sich eine technische Selbsteinschätzung — keinen Nachweis der BSIG- oder DSGVO-Konformität; den dafür zuständigen Beitrag zur Klinik-Cybersicherheit haben Sie weiter oben bereits verlinkt gefunden.

Was diese Liste nicht ersetzt

Die Prüffrageliste ist ein Werkzeug für die eigene technische Standortbestimmung, kein Ersatz für ein externes Audit, einen Penetrationstest oder eine rechtliche Prüfung der eigenen Pflichtenlage. Wer alle acht Fragen mit „Ja“ beantwortet, hat eine solide Architektur beschrieben — und trotzdem nicht automatisch jede Anforderung erfüllt, die BSIG, DSGVO oder das Medizinprodukterecht an das eigene Haus stellen.

Diese Einordnung ersetzt keine individuelle IT-Sicherheits- oder Rechtsberatung für das eigene Haus — für die konkrete BSIG-Pflichtenlage siehe den verlinkten Beitrag zur Klinik-Cybersicherheit. Wo besondere Kategorien von Gesundheitsdaten verarbeitet werden oder eine Datenschutz-Folgenabschätzung nach Artikel 35 DSGVO in Betracht kommt, gehört das in ein eigenes Prüfverfahren mit der Datenschutzbeauftragten des Hauses, nicht in eine technische Checkliste.

Wie groß die eigene Pflichtenlage tatsächlich ist, hängt außerdem von Bettenzahl, Sektor und der Einstufung als besonders wichtige, wichtige oder kritische Einrichtung ab — eine Einstufung, die dieser Beitrag nicht für Sie trifft und die sich nicht aus einer technischen Prüffrageliste ableiten lässt. Wer hier Klarheit braucht, holt sie sich am besten vor der nächsten größeren Investition ein, nicht erst danach.

Was dieser Beitrag bewusst nicht behandelt

Drei Themen liegen nah an diesem Beitrag und werden hier bewusst nicht ausgebaut, weil sie an anderer Stelle in diesem Themenblock eine eigene, ausführlichere Behandlung bekommen. Wie eine Klinik bei einem laufenden Cyberangriff Systeme in einer festgelegten Reihenfolge herunterfährt oder in einen eingeschränkten Betrieb überführt, behandelt ein eigener Beitrag zu diesem Themenblock zur gestuften Reaktion auf Cyberangriffe — Zero Trust liefert dafür nur die Voraussetzung, dass sich einzelne Ressourcen überhaupt gezielt trennen lassen, ohne gleich das ganze Netz mitzureißen.

Wie ein Krankenhaus nach einem Vorfall wieder in einen geordneten Betrieb zurückfindet, mit welchem Mindestumfang an Funktionen es dabei zunächst arbeitet und wie ein Wiederanlauf sauber freigegeben wird, entwickelt ein weiterer eigener Beitrag zu Wiederanlauf und Notbetrieb in diesem Themenblock. Eine eigene Bezeichnung für diesen Mindestbetrieb wird dort eingeführt, hier absichtlich nicht.

Und der vollständige Pflichtenbestand aus BSI-Gesetz, Sozialgesetzbuch und dem KRITIS-Dachgesetz — mit Schwellenwerten, Meldefristen und den unterschiedlichen Adressatenkreisen — gehört, wie weiter oben verlinkt, in den Beitrag zur Klinik-Cybersicherheit. Dieser Text zitiert daraus ausschließlich § 30 BSIG zur Lieferkette, weil er unmittelbar die Frage des Herstellerfernzugriffs berührt, und baut daraus keinen eigenständigen Pflichtenkatalog auf.

Was am Montagmorgen zuerst zählt

Der Patientenmonitor vom Anfang dieses Beitrags wäre in einer Zero-Trust-Architektur kein geringeres Risiko gewesen, aber ein begrenzteres: Seine Netzwerkverbindung hätte als eigene, überwachte Ressource gegolten, deren ungewöhnliches Verhalten auffällt, statt als Teil eines pauschal vertrauten internen Netzes unbemerkt zu bleiben. Genau dieser Unterschied — begrenzter statt unbegrenzter Schaden — ist der eigentliche Gewinn, den die vier Säulen zusammen bringen, nicht die Aussicht auf einen ereignisfreien Betrieb.

Wer mit der Umsetzung beginnt, kommt am ehesten über die erste Säule ins Arbeiten: ein belastbares, laufend aktualisiertes Geräteinventar, weil sich Mikrosegmentierung, laufende Autorisierung und ein geordneter Herstellerzugriff ohne dieses Fundament kaum sauber umsetzen lassen. Und weil sich Netzwerkarchitektur selten kurzfristig ändern lässt, gehören diese vier Fragen in jede neue Ausschreibung für Medizingeräte und Wartungsverträge, nicht erst in die Nachbetrachtung nach dem nächsten Vorfall.