Penetrationstest am Krankenhausinformationssystem (KIS): Schwache Zugänge und Zertifikatsfehler prüfen, ohne den Betrieb zu gefährden

IT-Sicherheit im Krankenhaus und Penetration Testing

Ein Krankenhausinformationssystem (KIS) steht selten still. Patientenverwaltung und Behandlungsdokumentation laufen darüber zusammen, und ein Ausfall legt die digitale Behandlung im ganzen Haus lahm. Wer die IT eines Krankenhauses verantwortet, kennt diesen Druck: Das System muss rund um die Uhr erreichbar sein.

Seit Anfang 2025 liegt zugleich eine unbequeme Erkenntnis auf dem Tisch. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat zwei weit verbreitete KIS testen lassen und dabei Schwächen gefunden, die sich praktisch ausnutzen lassen – in der Zugangsverwaltung und in der Absicherung der Kommunikation. Damit steht die verantwortliche Person vor einem Zwiespalt, der sich nicht wegdiskutieren lässt: Prüfen ist geboten, doch ein aktiver Test gegen ein sicherheitskritisches Live-System wirkt wie ein Risiko für genau die Verfügbarkeit, die geschützt werden soll.

Der Befund: Was die BSI-Untersuchung zeigt

Hinter der Erkenntnis steht das Projekt SiKIS (Sicherheitseigenschaften von Krankenhausinformationssystemen). Darin hat das BSI gemeinsam mit dem Fraunhofer-Institut für Sichere Informationstechnologie (SIT) und der OpenSource Security GmbH zwei in Deutschland weit verbreitete KIS einem Penetrationstest unterzogen. Die Ergebnisse sind anonymisiert, benannt werden Schwachstellenklassen und keine Produkte. Ein vergleichbares Projekt des Nationalen Testinstituts für Cybersicherheit in der Schweiz kam zu ähnlichen Befunden, was für ein allgemeines Muster spricht.

Zwei dieser Klassen stehen hier im Mittelpunkt, weil Betreibende sie in der eigenen Umgebung selbst prüfen können. Die erste betrifft die Zugangsverwaltung. Das BSI beschreibt Wartungszugänge mit unsicheren Passwörtern, die über Jahre unverändert bleiben und umfassenden Zugriff auf die Datenbank besitzen – teils, ohne in der Kontoverwaltung des KIS überhaupt sichtbar zu sein. Die zweite betrifft die Absicherung der Kommunikation. Prüft ein KIS-Client die TLS-Zertifikate (Transport Layer Security) des Servers nur unzureichend, lässt sich die Identität des Gegenübers fälschen. Das BSI führt diesen Fall als Meddler-in-the-Middle-Angriff (MitM).

Das Problem: Warum diese zwei Klassen in Betreiberhand liegen

Beide Klassen entstehen häufig aus Konfiguration und Integration und nicht allein aus dem Produktkern. Genau darauf weist das BSI hin: Weil sich die Einrichtung eines KIS und dessen Einbindung in die vorhandene IT von Haus zu Haus unterscheiden, treten Schwächen auf, die generische Herstellertests nicht erfassen. Eine durch Fehlkonfiguration unzureichend verschlüsselte Verbindung gehört dazu, ebenso fehlende Zugangsbeschränkungen oder eine unsauber gesetzte Passwortrichtlinie.

Für die verantwortliche Person heißt das: Der Prüfbedarf sitzt in der eigenen Umgebung, und der Weg dahin ist noch offen. Wie sich das ohne Betriebsstörung machen lässt, bleibt an dieser Stelle bewusst unbeantwortet.

Die Konsequenz: Was auf dem Spiel steht

Das BSI zeichnet ein Angriffsszenario nach, das beide Klassen verbindet und sich an der MITRE-ATT&CK-Matrix orientiert. Am Anfang steht eine Phishing-Mail, deren Schadcode auf einem KIS-Client landet – einem regulären Arbeitsplatzrechner, der sich anders als ein Medizingerät nicht streng segmentieren lässt. Ist der Verkehr zwischen Client und Server unverschlüsselt oder unsicher konfiguriert, lassen sich medizinische Daten und Datenbank-Zugangsdaten mitschneiden. Mit diesen Zugangsdaten bauen Angreifende eine direkte Verbindung zur Datenbank mit erhöhten Rechten auf und lesen Patientendaten aus.

Der Schaden trifft unmittelbar die Versorgung. Fällt ein KIS aus, stehen Aufnahmestopps und verschobene Operationen im Raum. Der BSI-Lagebericht 2025 (Oktober 2025) ordnet Ransomware weiterhin als zentrale Bedrohung für den Gesundheitssektor ein. Regulatorisch verschärft das NIS2-Umsetzungsgesetz (NIS2UmsuCG), seit dem 6. Dezember 2025 in Kraft, die Nachweispflicht für betroffene Einrichtungen. Der Zwiespalt aus Prüfen-Müssen und Verfügbarkeit-Schützen bleibt damit bestehen. Gelöst wird er über das Wie.

Der Lösungsweg: Prüfungen nach Eingriffstiefe trennen

Der Weg aus dem Zwiespalt führt über eine Unterscheidung, die das BSI selbst vorgibt. In den Handlungsempfehlungen rät es Betreibenden, das KIS in Penetrationstests einzubeziehen, diese aber vorrangig an Test- und Entwicklungssystemen durchzuführen, um Fehlfunktionen zu vermeiden. An produktiv genutzten Systemen empfiehlt das BSI nur einen sehr begrenzten Umfang.

Wichtig dabei: Das Testsystem soll sich in seinen Sicherheitsmerkmalen möglichst wenig vom Produktivsystem unterscheiden. Andernfalls verliert das Ergebnis an Aussagekraft.

Daraus ergibt sich eine einfache Ordnung. Prüfungen mit hoher Eingriffstiefe, etwa das Ausprobieren von Zugangsdaten oder Checks, die Last erzeugen, gehören auf das Test- oder Entwicklungssystem. Lesende Prüfungen, die eine Konfiguration nur auswerten, lassen sich in eng begrenztem Umfang auch am Produktivsystem vertreten. Unter diese Ordnung fallen beide Themen.

Die Zertifikats- und TLS-Prüfung wertet aus, welche Protokollversionen, Algorithmen und Zertifikatseigenschaften ein Server anbietet. Sie greift kaum in den Betrieb ein und eignet sich für die begrenzte Prüfung am laufenden System. Das Ausprobieren schwacher Datenbank-Zugänge dagegen erzeugt Last, kann Konten sperren und trifft damit die Verfügbarkeit. Es gehört auf das Test- oder Entwicklungssystem oder in ein eng gestecktes Wartungsfenster.

Eine zweite Trennung betrifft die Zuständigkeit. Die BSI-Handlungsempfehlungen richten sich jeweils getrennt an Herstellfirmen und Betreibende. Architektur, die Speicherung von Passwörtern und die Signatur von Software-Updates stecken im Code des KIS und liegen damit bei der Herstellfirma. Betreibende können diese Punkte einfordern, ihre Umsetzung von außen prüfen und das Umfeld des KIS dauerhaft überwachen, damit Ausnutzungsversuche früh auffallen.

Der Lösungsbeitrag: Umsetzung mit Enginsight Hacktor

An dieser Stelle kommt die Enginsight-Plattform ins Spiel, konkret die Komponente Hacktor für den automatisierten Penetrationstest. Hacktor arbeitet in vier Schritten: Information Gathering zur Erfassung der Umgebung, ein CVE-Scan (Common Vulnerabilities and Exposures) auf bekannte Sicherheitslücken, ein Service-Bruteforce zum Aufdecken schwacher Zugänge und eine Service-Discovery für Konfigurationsmängel. Eine gefundene CVE validiert Hacktor über Meta-Informationen und verzichtet auf das aktive Ausnutzen der Lücke – eine Eigenschaft, die im Kontext eines KIS Gewicht hat.

Für die TLS- und Zertifikatsprüfung bringt die Service-Discovery einen umfangreichen SSL/TLS-Block mit, einschließlich einer Prüfung nach den Vorgaben des BSI und einer eigenen Kategorie für Zertifikatsfehler. Dieser Teil arbeitet serverseitig und lesend. Die Grenze gehört ehrlich benannt: Hacktor prüft die Serverkonfiguration und die Gültigkeit der Zertifikate, während die vom BSI betonte korrekte Zertifikatsprüfung durch den KIS-Client eine Eigenschaft des Clients bleibt, die über Hersteller und Konfiguration zu bestätigen ist.

Für die schwachen Zugänge greift der Service-Bruteforce die Datenbankdienste an, darunter MySQL, MariaDB, PostgreSQL, Microsoft SQL Server und MongoDB. Mit reduzierten Passwortlisten, Testkonten und eng gefassten Audit-Definitionen bleibt der Test kontrollierbar. Nach der BSI-Logik läuft er auf dem Test- oder Entwicklungssystem.

Aus der einmaligen Messung eines Prüflabors wird ein wiederkehrender Vorgang, weil Hacktor geplante Einsätze durchführen kann und kontinuierliches Reporting liefert, so dass auch künftige Schwachstellen aufgedeckt werden können. Das härtet die Systemebene fortlaufend, was in Zeiten von KI-Cyberattacken dringend notwendig ist. Zwischen zwei Prüfläufen kann sich die Umgebung jedoch verändern. Für diese Zeitspanne braucht es dauerhafte Überwachung.

Dauerhafte Überwachung: Was die Plattform von außen beiträgt

Enginsight greift nicht in den Code eines KIS ein. Die Architektur, das Hashing der Passwörter und die Signatur von Updates lassen sich mit der Plattform daher nicht verändern. Ihr Beitrag liegt in der dauerhaften Überwachung von außen, die auch bei Befunden hilft, deren Ursache bei der Herstellfirma liegt: Sie macht sichtbar, wenn sich an diesen Stellen etwas Auffälliges tut.

Watchdog überwacht dauerhaft das Netzwerk und meldet neue Geräte sowie offene Ports, die nicht offen sein sollten. Ein Beispiel ist ein Datenbank-Port, der aus einem Netzsegment erreichbar ist, für das kein Zugriff vorgesehen ist. Watchdog zeigt eine solche Auffälligkeit an; ob ein Angriff dahintersteht, klärt die weitere Analyse.

Am tiefsten reicht die Plattform direkt auf dem Host. Der Pulsar Agent läuft auf KIS-Clients und -Servern und überwacht sie von innen. Er inventarisiert die installierte Software und gleicht sie mit bekannten Schwachstellen (CVE) ab, analysiert mit dem Intrusion Detection System (IDS) den Netzwerkverkehr auf Angriffe und blockiert erkannte Netzwerkattacken über das Intrusion Prevention Systems (IPS) der Enginsight-Komponente Shield. Das File Integrity Monitoring (FIM) überwacht ausgewählte Dateien und Programme und dokumentiert Änderungen daran, etwa an Programmdateien und Konfigurationen des KIS-Clients, die über die Softwareverteilung eintreffen. Für das SIEM sammelt der Agent zudem Roh-Logs ein.

Schreibt das KIS eigene Logs, lassen sich diese an das Security Information and Event Management (SIEM) der Plattform anbinden. Ungewöhnliche Aktivitäten, etwa die Anmeldung eines lange ungenutzten Wartungskontos, fallen dann als Anomalie auf. Das setzt voraus, dass das KIS diese Logs überhaupt schreibt – eine Frage, die in das Gespräch mit der Herstellfirma gehört. Meldet das SIEM eine Auffälligkeit, kann das Team für Managed Detection and Response (MDR) reagieren, bevor sich daraus ein Vorfall entwickelt.

Läuft der KIS-Client als Webanwendung im Browser, prüft Observer die Anwendung dauerhaft auf TLS-Konfiguration, offene Ports, HTTP-Header und die Gültigkeit des Zertifikats. Aus der punktuellen Zertifikatsprüfung im Penetrationstest wird so eine laufende Beobachtung. Das ist auch für die Verfügbarkeit relevant: Das BSI weist darauf hin, dass ein abgelaufenes Serverzertifikat im Extremfall den Zugriff auf medizinische Daten blockiert.

Zum Mitnehmen: Die Betreiber-Checkliste zum Selbstprüfen

Die folgende Checkliste übersetzt die Betreiberempfehlungen der BSI-Handlungsempfehlungen für Krankenhausinformationssysteme (KIS) in prüfbare Punkte, geordnet nach den sieben Bereichen des Dokuments. Jeder Punkt ist markiert, wie er sich angehen lässt: selbst technisch prüfbar (ein Teil davon mit Hacktor, mit Hinweis auf Produktiv- oder Testsystem), beim Hersteller einzufordern oder in Architektur und Konzepten zu verankern.

Der Zielzustand: Wohin das führt

Am Ende steht die KIS-Prüfung als wiederkehrender Bestandteil des Betriebs, der die Verfügbarkeit achtet. Schwache Zugänge und veraltete TLS-Konfigurationen werden sichtbar und lassen sich nach Dringlichkeit einordnen, ohne dass ein Test das laufende System gefährdet. Ermöglicht wird das durch die Fähigkeit von Hacktor zu geplanten Zeiten eingesetzt werden zu können, so dass Belastungsspitzen umschifft werden. Zwischen den Prüfläufen behalten Watchdog, Pulsar Agent, SIEM und Observer das Umfeld des KIS im Blick, und Auffälligkeiten erreichen das MDR-Team.

Und die verantwortliche Person kann gegenüber Auditierenden und Geschäftsführung belastbar darlegen, was geprüft wurde und was daraus folgt. Der Zwiespalt vom Anfang, prüfen zu müssen und die Verfügbarkeit zu schützen, ist damit aufgelöst.