|
04.08.2026 06:11 Uhr |
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
(mack)