Wenn die IT ausfällt: Krisensimulation für Krankenhäuser

Cyberangriffe auf Krankenhäuser beginnen oft unspektakulär: mit einer Phishing-Mail, einem schlecht abgesicherten Server oder einer Schwachstelle in ganz normaler Standard-IT. Die Folgen können trotzdem schnell weit über die Technik hinausreichen. Wenn zentrale Systeme ausfallen, stellt sich im Klinikalltag nicht nur die Frage nach dem Angriffsweg, sondern vor allem danach, ob Alarmierung, Kommunikation und Versorgung unter Krisenbedingungen funktionieren.

Nico Brüggemann ist wissenschaftlicher Mitarbeiter am Fraunhofer SIT und trainiert Krankenhäuser für den IT-Notfall.

(Bild: Fraunhofer SIT)

Genau dafür wird derzeit eine Krisensimulation für Krankenhäuser erprobt. Sie soll nicht nur technische Reaktionen testen, sondern vor allem zeigen, wie belastbar die Abläufe im Ernstfall wirklich sind. Im Interview erklärt Nico Brüggemann vom Fraunhofer-Institut für Sichere Informationstechnologie (SIT) unter anderem, wie das Format aufgebaut ist, warum viele Häuser ihre Alarmierungsprozesse zu selten praktisch üben und warum auch moderne Standards wie FHIR geprüft werden müssen. Außerdem geht es darum, was sich aus den Übungen wissenschaftlich lernen lässt und warum dafür noch weitere Krankenhäuser als Studienteilnehmer gesucht werden.

Sie arbeiten an einer Krisensimulation für Krankenhäuser. Was genau ist die Idee dahinter?

Die Grundidee ist, eine Lage zu simulieren, die sich möglichst nah an der Realität bewegt. Bei der Krisensimulation ist es so, dass die Leute eigentlich keine Rollen spielen sollen. Wenn wir in ein Krankenhaus gehen, soll dort idealerweise wirklich der IT-Administrator sitzen, der im Ernstfall zuständig wäre, dazu die Geschäftsführung, der Vorstand, der Krisenstab. Es geht nicht darum, irgendetwas abstrakt nachzustellen, sondern reale Abläufe mit den echten Verantwortlichen zu üben.

Wie läuft so eine Simulation dann konkret ab?

Sie beginnt mit einer kurzen Einführung in die Regeln und den Ablauf. Und dann beginnt das Ganze quasi mit den IT-Leuten. Sie bekommen eine virtuelle Umgebung, in der sie sich durchklicken können. Dort tauchen dann nach und nach sogenannte Indicators of Compromise auf, also Hinweise darauf, dass gerade ein Angriff läuft.

Die IT analysiert das, bewertet es und muss entscheiden, wann sie eskaliert. Irgendwann wird dann der Krisenstab informiert. Ab diesem Punkt wird aus der technischen Analyse eine echte Krisenübung: Dann müssen verschiedene Bereiche zusammen Entscheidungen treffen und kommunizieren.

Was heißt das in der Praxis? Worüber reden die Teilnehmer dann?

Sehr schnell nicht mehr nur über Technik. Natürlich gibt es den technischen Auslöser, etwa ausgefallene Systeme oder verdächtige Aktivitäten. Aber dann kommen die Fragen, die im Krankenhausalltag wirklich relevant sind.

Wir spielen zum Beispiel Ereignisse ein: Das PACS oder das DICOM-System funktionieren nicht mehr. Ein Reporter steht vor der Tür. Der Chefarzt ruft an und will wissen, wie es weitergeht. Und dann kommen ganz praktische Probleme dazu, an die viele am Anfang gar nicht denken: Wie versorgt man Patientinnen und Patienten weiter, wenn die IT heruntergefahren ist? Wie organisiert man Essen, wenn digitale Abläufe ausfallen? Wie geht man mit Allergien oder Diätvorgaben um, wenn Informationen nicht mehr ohne Weiteres abrufbar sind?

Genau diese Mischung macht die Übung realistisch. Es geht eben nicht nur darum, ob man einen Angriff erkennt, sondern ob ein Krankenhaus unter Stress weiter handlungsfähig bleibt.

Wie lange dauert das?

Meistens drei bis fünf Stunden. Das hängt stark von der Gruppe ab, also davon, wie tief diskutiert wird, wie schnell Entscheidungen getroffen werden und wie gut die Prozesse eingespielt sind.

Wir planen dabei bewusst keine festen Pausen ein. Natürlich kann jede und jeder den Raum kurz verlassen. Aber das Spiel läuft weiter. Das macht das Ganze noch mal so ein bisschen realitätsnäher, weil eine echte Krise eben auch nicht wartet, bis alle wieder am Tisch sitzen. Wer zwischendurch rausgeht, muss sich danach selbst wieder auf den aktuellen Stand bringen.

Anschließend machen wir ein Debriefing: Was lief gut, was lief nicht gut, wo haben Prozesse funktioniert, wo nur auf dem Papier? Oft gibt es danach noch einen kurzen Theorieblock, etwa zur Krisenkommunikation. Insgesamt ist das dann faktisch ein ganzer Tag.

Der kritische Punkt ist also nicht nur die Angriffserkennung?

Genau. Der Fokus liegt nicht primär darauf, ob jemand besonders elegant einzelne technische Artefakte erkennt. Wichtiger ist, ob die Alarmierungs- und Krisenprozesse funktionieren.

Wissen die IT-Leute, wen sie informieren müssen? Wissen sie auch, wie sie diese Personen tatsächlich erreichen? Funktioniert die Alarmierung nicht nur im Organigramm und im Handbuch, sondern unter Zeitdruck? Deshalb trennen wir IT und Krisenstab zu Beginn auch oft räumlich. Die IT muss den Krisenstab dann mit den Mitteln erreichen, die im Haus tatsächlich vorgesehen sind.

Und da sieht man oft schon die erste Schwachstelle. Vieles ist dokumentiert, aber selten praktisch eingeübt. Das ist eines der größten Mankos. In vielen Häusern ist festgelegt, wer wann informiert werden soll und wer im Krisenstab sitzt. Aber ob diese Alarmierung in der Praxis wirklich funktioniert, wird oft kaum getestet.

Nun wissen die Teilnehmer ja, dass sie in einer Simulation sitzen. Verzerrt das die Reaktion nicht?

Natürlich gibt es diesen Effekt. Die Leute sind in gewisser Weise gebiased, weil sie wissen, dass etwas passieren wird. Es kann also sein, dass früher eskaliert wird, als das in einer echten Lage der Fall wäre.

Ganz vermeiden lässt sich das kaum, es sei denn, man würde so eine Übung völlig unangekündigt durchführen. Das halte ich aber nicht zwingend für die bessere Lösung. Der Mehrwert liegt aus meiner Sicht nicht darin, Menschen zu überrumpeln, sondern darin, Prozesse realitätsnah zu testen und Schwächen sichtbar zu machen.

Ist das für die teilnehmenden Häuser eher Training oder eher Evaluation?

Beides. Für die Häuser ist es eine Übung, aber zugleich auch eine Auswertung. Wir dokumentieren die Durchführung sehr genau und erstellen danach einen Abschlussbericht. Darin halten wir fest, was gut funktioniert hat, wo es gehakt hat und an welchen Stellen Prozesse angepasst werden sollten.

Darüber hinaus ist das Ganze wissenschaftlich angelegt. Wenn das Krankenhaus zustimmt, werten wir die Ergebnisse systematisch aus. Uns interessiert zum Beispiel: Welche Notfallprozesse sind tatsächlich lebbar? Reagieren manche Häuser robuster als andere? Und falls ja, woran liegt das?

Woran könnte das liegen?

Ein möglicher Faktor wäre etwa, ob ein Haus unter die KRITIS-Regulierung fällt oder nicht. Bei KRITIS-Häusern würde man zumindest erwarten, dass sie in bestimmten Punkten besser vorbereitet sind, weil sie seit Jahren strengere Auflagen haben. Ob das tatsächlich so ist, muss man aber empirisch prüfen.

Genau dafür brauchen wir mehr Durchläufe. Und deshalb suchen wir auch noch weitere Krankenhäuser, die an solchen Simulationen teilnehmen und sich als Studienteilnehmer einbringen wollen. Nur mit einer größeren Zahl von Übungen bekommt man am Ende belastbare Daten.

Wie stark passen Sie das Szenario an das jeweilige Krankenhaus an?

Vor der Übung machen wir eine Vorevaluation. Die Häuser bekommen einen Fragebogen, in dem sie ihre IT-Umgebung grob beschreiben: Welche Systeme werden genutzt, was ist intern, was extern, was ist ausgelagert? Auf dieser Basis passen wir den Einstieg in das Angriffsszenario an.

Es geht uns dabei nicht um jedes einzelne Detail, sondern um einen plausiblen Angriffsweg. Wenn ein Haus zum Beispiel einen eigenen Exchange-Server betreibt, kann das ein realistischer Einstiegspunkt im Szenario sein. Wichtig ist aber zugleich, dass die Übungen vergleichbar bleiben. Deshalb versuchen wir, die Grundstruktur der Angriffe weitgehend gleich zu halten und nur so viel anzupassen, dass der Ablauf für das jeweilige Haus glaubwürdig ist.

Welche Angriffswege sehen Sie denn in der Realität bei Krankenhäusern am häufigsten?

Viele denken zuerst an hochspezialisierte medizinische Systeme, an veraltete Geräte oder an besonders exotische Angriffsszenarien. Die spielen sicher auch eine Rolle. Die Angriffe, die wir aber sehen auf Krankenhäuser, die finden über einen ganz anderen Weg statt, nämlich über diese ganz normale Standard-IT. Also über Exchange-Server, Citrix-Umgebungen, Phishing-Mails und ähnliche Schwachstellen, die im Grunde in jeder Branche vorkommen können.

Das ist aus meiner Sicht eine wichtige Erkenntnis. Natürlich gibt es im Gesundheitswesen massive Probleme bei Spezialsoftware und Medizingeräten. Aber der erste Einstieg erfolgt eben oft nicht über das exotische System, sondern über ganz gewöhnliche Unternehmens-IT.

Gleichzeitig gibt es seit Jahren Kritik an der Sicherheit medizinischer Systeme. Widerspricht sich das nicht?

Nein, das widerspricht sich nicht. Beides ist wahr. Auf der anderen Seite wissen wir, dass viele medizinische Systeme aus Sicherheitssicht problematisch sind: veraltet, schlecht segmentiert, nicht auf heutige Bedrohungslagen ausgelegt. Wenn ein Angreifer einmal im Netzwerk ist, kann das schnell kritisch werden.

Auf der anderen Seite sehen wir eben, dass die eigentlichen Angriffe auf Krankenhäuser oft über Standard-IT beginnen. Das heißt: Die Medizingeräte sind nicht automatisch der wahrscheinlichste Einstiegspunkt, auch wenn sie intern später natürlich zum Problem werden können.

Sie haben sich auch mit Austauschstandards wie HL7, DICOM und FHIR beschäftigt. Warum ist das Thema sicherheitstechnisch relevant?

Weil darüber ein großer Teil der Kommunikation im Gesundheitswesen läuft. Und weil bei diesen Standards oft unklar ist, worüber eigentlich gesprochen wird. Wenn jemand „HL7“ sagt, kann damit der ältere HL7-v2-Standard gemeint sein, aber auch die Organisation hinter den Standards. Dieselbe Organisation steht auch hinter FHIR. Das macht die Debatte nicht gerade einfacher.

Inhaltlich muss man die Dinge aber sauber trennen. HL7 v2, das seit Jahren in Kliniken für den Datenaustausch genutzt wird, ist eine Sicherheitsvollkatastrophe, kann man sagen.

Das Problem ist nicht nur, dass einzelne Implementierungen schlecht sind. Das Problem beginnt schon beim Standard selbst. HL7 v2 bringt keine eingebauten Sicherheitsmechanismen mit. Es gibt keine verpflichtende Transportverschlüsselung, keine robuste standardisierte Authentifizierung und keinen integrierten Schutz vor Manipulation. Das ist historisch erklärbar, weil der Standard aus einer Zeit stammt, in der man von abgeschotteten internen Netzen ausging. Aber in vernetzten Umgebungen wird genau das heute zum Risiko.

Solange so etwas nur in streng getrennten, gut kontrollierten Netzen läuft, kann man organisatorisch einiges abfedern. Sobald aber externe Anbindungen dazukommen oder die alten Vertrauensannahmen nicht mehr tragen, wird es problematisch.

Und DICOM?

DICOM ist ein etwas anderer Fall. Dort gibt es Sicherheitserweiterungen durchaus. Technisch wäre also mehr Absicherung möglich. Das Problem ist eher, dass diese Möglichkeiten in der Praxis oft nicht konsequent genutzt werden.

Das heißt: Anders als bei HL7 v2 liegt die Schwäche bei DICOM nicht nur in der historischen Architektur, sondern oft auch in der realen Implementierung und im Zusammenspiel unterschiedlicher Hersteller. Am Ende führt das aber zu einem ähnlichen Ergebnis: Systeme, die deutlich schwächer abgesichert sind, als sie sein müssten.

FHIR gilt oft als moderner Standard. Ist das dann die Lösung?

FHIR ist auf jeden Fall konzeptionell moderner. Es arbeitet stärker mit Webtechnologien und ist dafür gedacht, strukturierte Daten in zeitgemäßen Architekturen auszutauschen. Insofern ist FHIR deutlich anschlussfähiger an heutige Sicherheitsmechanismen als HL7 v2.

Aber das heißt eben nicht automatisch, dass FHIR-Systeme sicher sind. Auch bei FHIR gilt: Wenn eine Schnittstelle offen im Netz steht, wenn die Authentifizierung schlecht umgesetzt ist oder Zugriffskontrollen fehlen, dann hilft einem der moderne Standard allein nicht weiter. Der Vorteil liegt eher darin, dass man Sicherheit bei FHIR technisch zeitgemäßer umsetzen kann, nicht darin, dass sie automatisch vorhanden wäre.

Haben Sie dazu auch eigene Untersuchungen gemacht?

Ja. Wir haben selbst nach öffentlich erreichbaren Systemen gesucht, die DICOM, HL7 und FHIR sprechen. Bei DICOM und HL7 ist problematische Exponierung wenig überraschend. Interessant war aber, dass auch bei FHIR nicht nur sauber abgesicherte Installationen zu finden waren.

Das bestätigt im Grunde einen simplen, aber wichtigen Punkt: Nicht nur die Wahl des Standards ist entscheidend, sondern vor allem seine konkrete Umsetzung. Auch moderne Technik bleibt unsicher, wenn sie schlecht implementiert oder fahrlässig betrieben wird.

Das passt zu den jüngsten BSI-Berichten über Krankenhausinformationssysteme (KIS), Praxissoftware und Pflegedokumentationssysteme. Dazu hatten das Fraunhofer SIT und die Open Source Security GmbH zwei repräsentative KIS getestet.

Ja. Dort sieht man immer wieder dieselben Muster: fehlende Transportverschlüsselung, veraltete Kryptografie, schwache Authentifizierung, unsichere Wartungszugänge, problematische Update-Prozesse, architektonische Schwächen. Das Problem sind eben nicht nur einzelne Schwachstellen, sondern oft historisch gewachsene Strukturen.

Es ergibt sich ein ziemlich konsistentes Bild. Der Digitalisierungsdruck steigt, aber bei der IT-Sicherheit zentraler Softwareprodukte gibt es in vielen Bereichen weiterhin deutlichen Nachholbedarf.

Sie haben vorhin auch die Lieferkette angesprochen. Warum ist die so wichtig?

Weil Krankenhäuser nicht isoliert arbeiten. Sie hängen an Dienstleistern, Abrechnungsanbietern, externen Softwarepartnern und vielen anderen Gliedern in dieser Kette. Für Angreifer kann das sehr attraktiv sein. Warum ein einzelnes Krankenhaus angreifen, wenn man über einen Dienstleister potenziell Zugriff auf viele bekommt?

Ich glaube, das wird noch unterschätzt. Krankenhäuser müssten eigentlich ein sehr starkes Interesse daran haben, was in ihrer gesamten digitalen Lieferkette passiert. Denn wenn dort etwas schiefläuft, landen die Folgen am Ende trotzdem im Krankenhausbetrieb.

Wenn Sie auf das Projekt insgesamt schauen: Was ist die eigentliche Stärke dieser Simulationen?

Dass sie all diese Ebenen zusammenbringen. Es geht nicht nur um den technischen Angriffsweg, sondern darum, was danach im Haus tatsächlich passiert: Alarmierung, Kommunikation, Entscheidungsfindung, Versorgung, Zuständigkeiten.

Und genau das ist aus meiner Sicht entscheidend. Man kann viele Dokumente schreiben und viele Prozesse definieren. Aber ob diese Prozesse in einer Lage wirklich tragen, sieht man erst, wenn man sie einmal durchspielt.

Wird man diese Simulation demnächst auch außerhalb einzelner Kliniken sehen können?

In angepasster Form ja. Zum Beispiel ist bei der Jubiläumstagung des KH-IT im September 2026 in Berlin ebenfalls eine Version der Simulation vorgesehen, naturgemäß aber nicht das vollständige Zusammenspiel in einem Krankenhaus, weil vor allem IT-Leitungen und IT-Mitarbeitende zusammenkommen. Daran lässt sich aber vielleicht gut zeigen, was solche Übungen leisten können.

(mack)