SIEM für Krankenhäuser: §391 SGB V und Medizintechnik
Zwei Regelwerke, ein Netz: die Lage im Krankenhaus
In einem Krankenhaus stehen die Systeme mit dem geringsten Spielraum für Ausfälle oft dort, wo am wenigsten verändert werden darf. Geräte in der bildgebenden Diagnostik und im Labor laufen über Jahre in dem Zustand, in dem sie freigegeben wurden — häufig auf Betriebssystemen, die längst aus dem Support gefallen sind, und mit einer Herstellerdokumentation, die Software von Dritten ausschließt. Weder patchen noch einen Agenten installieren ist dort eine Option, und genau deshalb liegen diese Geräte in abgetrennten Netzen.
Regulatorischer Kontext: §391 SGB V
und §30 BSIG gelten nebeneinander
Die Pflicht aus dem Fachrecht.
§391 SGB V trägt die amtliche Überschrift „IT-Sicherheit in Krankenhäusern”. Absatz 1 verpflichtet Krankenhäuser, „nach dem Stand der Technik angemessene organisatorische und technische Vorkehrungen zur Vermeidung von Störungen der Verfügbarkeit, Integrität und Vertraulichkeit ihrer informationstechnischen Systeme, Komponenten oder Prozesse zu treffen”. Die Norm nennt weder eine Größenschwelle noch einen Stichtag. Sie ist damit eine Dauerpflicht und kein Projekt mit Termin.
Was „angemessen” bedeutet.
Absatz 3 bindet den erforderlichen Aufwand an zwei Größen: an die Folgen eines Ausfalls oder einer Beeinträchtigung des Krankenhauses und an den Schutzbedarf der verarbeiteten Patienteninformationen. Ein Haus mittlerer Größe und eine Universitätsklinik schulden nach dieser Systematik nicht dasselbe.
Warum das BSIG daneben steht.
Absatz 5 nimmt von der Pflicht nur die Häuser aus, die „nicht ohnehin als Betreiber kritischer Anlagen gemäß den §§ 30, 31 und 39 des BSI-Gesetzes” Vorkehrungen zu treffen haben. Ein Krankenhaus, das keine kritische Anlage betreibt, fällt nicht unter diese Ausnahme. Es kann gleichzeitig wichtige oder besonders wichtige Einrichtung nach §28 BSIG sein — dieser Status knüpft an Einrichtungsart und Größe an, nicht an den KRITIS-Status. Ein zugelassenes Krankenhaus nach §108 SGB V erbringt Gesundheitsdienstleistungen und ist damit Erbringer von Gesundheitsdienstleistungen im Sinne der Richtlinie 2011/24/EU — die Einrichtungsart, die Anlage 1 BSIG im Sektor Gesundheit nennt. Für solche Häuser gelten §30 BSIG und §391 Abs. 1 SGB V nebeneinander.
Zwei Angemessenheitsmaßstäbe
Neben §391 Abs. 3 SGB V steht §30 Abs. 1 Satz 2 BSIG mit einem anderen Katalog: Risikoexposition, Größe der Einrichtung, Umsetzungskosten, Eintrittswahrscheinlichkeit und Schwere von Sicherheitsvorfällen sowie deren gesellschaftliche und wirtschaftliche Auswirkungen. Die beiden Maßstäbe sind nicht deckungsgleich.
Dokumentation.
§30 Abs. 1 Satz 3 BSIG lautet: „Die Einhaltung der Verpflichtung nach Satz 1 ist durch die Einrichtungen zu dokumentieren.” Ein wiederkehrender Nachweisturnus folgt daraus nicht — den gibt es nach §39 BSIG ausschließlich für Betreiber kritischer Anlagen.
Der B3S ist ein Weg, keine Vorschrift.
§391 Abs. 4 SGB V ist eine Kann-Regel: die Pflichten lassen sich „insbesondere erfüllen”, indem ein branchenspezifischer Sicherheitsstandard angewendet wird, dessen Eignung das Bundesamt nach §30 Abs. 8 BSIG festgestellt hat.
Wie lassen sich Medizingeräte überwachen?
Anforderungen und Abdeckung im Überblick
Die Tabelle ordnet den Anforderungen dieses Segments zu, was die Plattform technisch abdeckt und was auf der Services-Seite hinzukommt. Wo etwas fehlt oder von einer Entscheidung Dritter abhängt, steht es in derselben Zeile.
| Anforderung | Plattform | Advanced Services |
|---|---|---|
| Angemessene Vorkehrungen nach Stand der Technik (§391 Abs. 1 SGB V) und Risikomanagement (§30 Abs. 1 Satz 1 BSIG) | Zentrales Monitoring und zentrale Reaktion in einer integrierten Plattform aus SIEM, SOAR, UEBA, XDR und CTI; das native Risikomodul ist an ISO 27005 ausgerichtet, CMDB und BIA liefern den Kontext. Die SIEM-Plattform deckt damit die geforderte Funktion ab und unterstützt die Erfüllung der Pflicht — Pflichtenträger bleibt das Krankenhaus. | Kundenspezifische Risikomethodik, dokumentiertes Risk Register, Reporting-Templates für die Geschäftsleitung. |
| Geräte, auf denen keine Software installiert werden darf | Bei einem als Medizinprodukt CE-gekennzeichneten Gerät entscheidet die Herstellerdokumentation des Geräts; untersagt der Hersteller Software von Dritten, wird nichts installiert. Für die Überwachung ist eine Installation auf dem Gerät nicht erforderlich: der Umfang der Agentenausrollung ist wählbar — ausgewählte Geräte oder eine definierte Gruppe, manuell oder per Gruppenrichtlinie —, und das Verhalten der Geräte im Netz wird über die Protokolle der umliegenden Schutzsysteme sichtbar, die in der Regel bereits angebunden sind. Das ist Netzverhalten, keine Innensicht des Geräts. | — (Frage der Architektur und der Gerätedokumentation, kein eigener Servicebestandteil) |
| Abgetrenntes Medizintechnik-Netz | Ein LogForwarder steht im Segment selbst, erfasst dort lokal und gibt die Daten verschlüsselt an den zentralen Kollektor weiter. Das ist ein Standard-Architekturmuster der Plattform, keine Branchenfunktion. | — (Plattformeigenschaft) |
| Ältere Betriebssysteme in Diagnostik und Labor | Agentenlos über Windows Event Forwarding oder einen Vermittler wie nxlog. Das Minimum für den XDR-Agenten ist Windows 10; darunter bleibt es bei den agentenlosen Wegen. | — (Plattformeigenschaft) |
| Abgetrenntes Medizintechnik-Netz | Ein LogForwarder steht im Segment selbst, erfasst dort lokal und gibt die Daten verschlüsselt an den zentralen Kollektor weiter. Das ist ein Standard-Architekturmuster der Plattform, keine Branchenfunktion. | — (Plattformeigenschaft) |
| Ältere Betriebssysteme in Diagnostik und Labor | Agentenlos über Windows Event Forwarding oder einen Vermittler wie nxlog. Das Minimum für den XDR-Agenten ist Windows 10; darunter bleibt es bei den agentenlosen Wegen. | — (Plattformeigenschaft) |
| KIS, PACS, RIS | Keine Parser für klinische Protokolle — HL7 und DICOM werden nicht geparst. Angebunden wird, was das jeweilige System ausgibt: Syslog, Datei oder Windows-Ereignisprotokoll. Je Betriebssystem stehen dafür Windows Event Forwarding bzw. der XDR-Agent, unter Linux rsyslog und imfile und bei Geräten mit SNMP Telegraf, sofern ein passendes Plugin vorhanden ist. | — (kein Servicebestandteil belegt) |
| Verbund, mehrere Standorte, gewachsene Umgebung | Weitere Kollektoren ohne Kauf zusätzlicher Lizenzen, eigene Retention-Policies je Gerät. Log Management ist eine vom SIEM getrennte Schicht — gespeichert werden kann mehr, als korreliert wird. Lizenziert wird nach der Größe der Umgebung bzw. der Anzahl der Assets, nicht nach dem Volumen der verarbeiteten Daten. | — (Plattformeigenschaft) |
| Betrieb rund um die Uhr | — (Betriebsmodell, keine Eigenschaft der Plattform) | Zwei Modelle über europäische Partner: Eigenbetrieb mit Unterstützung — Sie verwalten Ihre Umgebung, Parser und Regeln bleiben beim Partner; oder Managed SIEM — der Partner betreibt, und der Vertrag besteht zwischen Ihnen und dem Partner. 24/7 mit Eskalationspfad L1–L3, das SLA wird auf Ihren Bedarf zugeschnitten. Gehostet wird ausschließlich in europäischer Infrastruktur — Stichwort digitale Souveränität. |
Ergebnisse und Marktresonanz
Gartner ★ 4.8/5
Reviews
Bewertungen ansehen
G2 ★ 5/5
Peer Insights
Bewertungen ansehen
ISO 27001
Zertifikat
ISO 9001
Zertifikat
Security Made in Poland
Poland Security Congress
250+
Kunden in Europa
Deloitte Fast 50
Führendes Unternehmen · 2022
Häufig gestellte Fragen
Möglich — und das ist der Regelfall, den diese Seite behandelt. Das BSIG knüpft den Status als wichtige oder besonders wichtige Einrichtung an Einrichtungsart und Größe (§28 BSIG), nicht an den KRITIS-Status. §391 Abs. 5 SGB V nimmt nur Betreiber kritischer Anlagen aus. Für alle anderen Häuser gelten beide Pflichtenkreise nebeneinander. Die Betroffenheitsprüfung im Einzelfall führt das BSI.
Das entscheidet die Herstellerdokumentation des Geräts. Technisch ist eine Installation nur bei einem unterstützten Betriebssystem möglich; untersagt der Hersteller Software von Dritten, wird nichts installiert. Für die Überwachung ist sie ohnehin nicht erforderlich: der Umfang der Agentenausrollung ist wählbar, und das Verhalten der Geräte im Netz wird über die umliegenden Schutzsysteme sichtbar.
Über einen LogForwarder im Segment selbst. Er erfasst die Daten lokal und gibt sie verschlüsselt an den zentralen Kollektor weiter, sodass das Segment abgetrennt bleibt. Das ist ein Standard-Architekturmuster der Plattform und keine krankenhausspezifische Funktion. Ob zusätzlich direkt auf einem Gerät erfasst wird, ist eine Frage des einzelnen Geräts.
Über Windows Event Forwarding oder einen Vermittler wie nxlog. Das Minimum für den XDR-Agenten ist Windows 10; ältere Systeme werden deshalb agentenlos angebunden. Die Ereignisprotokolle erreichen den zentralen Kollektor, ohne dass auf dem System selbst Software installiert wird. Unter Linux übernehmen rsyslog und imfile dieselbe Aufgabe.
Nächster Schritt: Netzsegmente,
Datenquellen, Geräte
Technisches Gespräch vereinbaren — wir gehen Ihre Netzsegmente durch,
die vorhandenen Datenquellen und die Geräte, auf denen nichts installiert werden darf.
