F5 Sicherheitslücke: Was der BIG-IP-Vorfall bedeutet

Einleitung

Im Oktober 2025 hat der IT-Hersteller F5 einen schwerwiegenden Sicherheitsvorfall in seiner eigenen Infrastruktur offengelegt: Ein staatlicher Akteur hatte im August 2025 persistenten Zugriff auf das F5-Netzwerk erlangt und dabei unter anderem Informationen über unveröffentlichte Schwachstellen in BIG-IP-Produkten sowie Teile des Quellcodes entwendet. Das BSI stufte den Vorfall mit Kritikalität 2 ein und veröffentlichte am 16. Oktober 2025 eine Sicherheitsmitteilung. Für Krankenhäuser und andere Gesundheitseinrichtungen, die F5 BIG-IP als Load Balancer, Application Delivery Controller oder TLS-Terminierungspunkt einsetzen, ergibt sich hieraus unmittelbarer Handlungsbedarf – sowohl auf der technischen als auch auf der governance-seitigen Ebene.

Was ist passiert: Chronologie des F5-Vorfalls

Der Angriff auf F5 verlief nach einem für staatlich motivierte Akteure typischen Muster: stille Persistenz, gezielter Datenabfluss, keine unmittelbare Sabotage.

August 2025: Ein staatlicher Akteur erlangt persistenten Zugriff auf das interne Netzwerk von F5. Der Zeitpunkt des initialen Zugangs ist bislang nicht öffentlich bestätigt.

Abgeflossene Daten umfassen laut F5: - Informationen über bis dato nicht veröffentlichte (Zero-Day-)Schwachstellen in BIG-IP-Produkten - Teile des Quellcodes von BIG-IP - Bei einem "kleinen Prozentsatz" von Kunden: Konfigurations- und Implementierungsdetails der F5-Produkte

Was F5 ausschließt (Stand Oktober 2025): - Abfluss von Kundendaten aus CRM-, Support- oder Finanzsystemen - Schwachstellen, die Remote Code Execution (RCE) ermöglichen - Als kritisch bewertete Sicherheitslücken unter den entwendeten Informationen - Bekannte aktive Ausnutzung der abgegriffenen Schwachstellen

15. Oktober 2025: F5 veröffentlicht eine Sicherheitsmitteilung und informiert betroffene Kunden.

16. Oktober 2025: Das BSI publiziert seine Cybersicherheitswarnung (Kritikalität 2) und empfiehlt Kunden, präventive Maßnahmen umzusetzen.

Wichtig für die Bewertung: Die Aussage, dass keine RCE-fähigen Schwachstellen abgeflossen seien, stammt vom Hersteller selbst und basiert auf dem Untersuchungsstand zum Zeitpunkt der Meldung. Staatliche Akteure veröffentlichen keine Angriffspläne – die tatsächliche Nutzung der entwendeten Informationen kann zeitverzögert erfolgen.

Warum F5 BIG-IP im Krankenhaus besonders exponiert ist

F5 BIG-IP ist in vielen mittleren und großen Krankenhäusern sowie Klinikverbünden ein kritischer Netzwerkknoten. Die Plattform wird typischerweise eingesetzt als:

Application Delivery Controller (ADC) für KIS-, RIS- und PACS-Anwendungen
TLS-Offloading-Punkt vor internen Applikationsservern – mit vollständigem Einblick in den entschlüsselten Datenverkehr
Web Application Firewall (WAF) zum Schutz webbasierter Patientenportale
Load Balancer für hochverfügbare klinische Systeme
VPN-Gateway für Remote-Zugriffe von niedergelassenen Ärzten, Telemedizin-Anwendungen oder Supportpersonal

Ein kompromittiertes BIG-IP-System stellt damit kein peripheres IT-Asset dar, sondern ein zentrales Sicherheits- und Verfügbarkeits-Gateway. Angreifer, die Konfigurationsdetails eines solchen Systems kennen, wissen:

Welche internen Dienste hinter welchen virtuellen Servern liegen
Welche SSL-Zertifikate und Cipher-Suites verwendet werden
Ob und wie iRules (BIG-IP-Scripting) den Traffic manipulieren
Welche Netzwerksegmente erreichbar sind und welche Zugriffskontrollen greifen

Diese Information ist kein unmittelbarer Exploit – aber eine hochwertige Grundlage für gezielte Folgeangriffe. Genau das ist das Geschäftsmodell staatlicher APT-Gruppen.

Technische Sofortmaßnahmen: Was jetzt zu tun ist

F5 hat bereits eigene Maßnahmen zur Härtung seiner Infrastruktur eingeleitet und gibt konkrete Empfehlungen für Kunden heraus. Ergänzt um die Empfehlungen des BSI ergibt sich für Krankenhäuser folgende Maßnahmenstruktur:

1. Inventar und Betroffenheitsabklärung

Prüfen Sie, ob Ihre Einrichtung zu dem "kleinen Prozentsatz" von Kunden gehört, bei denen Konfigurationsdaten abgeflossen sind. F5 sollte betroffene Kunden direkt informiert haben. Falls keine Kontaktaufnahme erfolgte: aktiv beim F5-Support nachfragen und die Kommunikation dokumentieren.
Erfassen Sie alle BIG-IP-Instanzen in Ihrer Infrastruktur (Versionsstände, Einsatzzweck, Netzwerksegment).

2. Patches und Updates priorisiert einspielen

Überwachen Sie die F5 Security Advisories (https://my.f5.com/manage/s/article/K4602) engmaschig. F5 wird die im Vorfall kompromittierten Schwachstellen in Patches adressieren – sobald CVEs veröffentlicht werden, gilt für Krankenhäuser unter §391 SGB V ein kurzes Reaktionsfenster.
Priorisieren Sie BIG-IP-Systeme, die direkt aus dem Internet erreichbar sind oder als WAF/VPN-Gateway fungieren.

3. Konfiguration und Credentials rotieren

Wenn Konfigurationsdaten Ihrer Einrichtung abgeflossen sein könnten oder Sie dies nicht ausschließen können:

Passwörter und API-Keys aller BIG-IP-Verwaltungskonten rotieren
Zertifikate neu ausstellen, insbesondere für TLS-Offloading und Management-Interfaces
iRules und iApps auf unautorisierte Änderungen prüfen (Integrity Check gegen bekannt-guten Zustand)
SNMP-Communities und Syslog-Konfigurationen überprüfen

4. Netzwerksegmentierung des Managementinterfaces

Das BIG-IP Management Interface (MGMT) darf ausschließlich aus einem dedizierten Out-of-Band-Managementnetz erreichbar sein – niemals aus dem allgemeinen Netz oder gar aus dem Internet. Falls dies noch nicht umgesetzt ist, hat dieser Vorfall Priorität.

Management-Zugang auf explizit erlaubte Jump-Host-IPs beschränken
SSH-Zugang auf zertifikatsbasierte Authentifizierung umstellen
GUI-Zugang (HTTPS auf Port 443/8443) vom Produktionsnetz trennen

5. Logging und Monitoring intensivieren

Aktivieren Sie erweitertes Logging auf BIG-IP für Verwaltungszugriffe, Konfigurationsänderungen und ungewöhnliche Traffic-Muster
Leiten Sie Logs in Ihr SIEM (falls vorhanden) mit erhöhter Alerting-Priorität für BIG-IP-Quellen weiter
Definieren Sie konkrete Detektionsregeln für: unerwartete Adminlogins, Konfigurationsänderungen außerhalb von Change-Windows, neue virtuelle Server oder iRules

Einordnung in den regulatorischen Rahmen für Krankenhäuser

§391 SGB V und B3S Krankenhaus

Krankenhäuser, die als KRITIS-Betreiber klassifiziert sind (ab 30.000 vollstationäre Fälle/Jahr), unterliegen seit Oktober 2021 dem B3S Krankenhaus als anerkanntem Sicherheitsstandard. Dieser verlangt unter anderem ein systematisches Schwachstellenmanagement und die zeitnahe Einspielung von Sicherheitspatches. Der F5-Vorfall ist ein klassischer Fall, bei dem das Schwachstellenmanagement auf externe Bedrohungsintelligenz (BSI-Warnung, Herstellermitteilung) reagieren muss – nicht nur auf veröffentlichte CVEs.

Auch unterhalb der KRITIS-Schwelle gilt seit dem 1. Januar 2022 gemäß §391 SGB V, dass alle Krankenhäuser in Deutschland angemessene technische und organisatorische Maßnahmen zur IT-Sicherheit nachweisen müssen. Der Nachweis erfolgt gegenüber den Landesverbänden der Krankenkassen. Ein dokumentierter Umgang mit der BSI-Warnung zu F5 ist Teil dieses Nachweises.

NIS2UmsuCG

Seit der Umsetzung des NIS2UmsuCG in Deutschland gelten verschärfte Anforderungen für wichtige und besonders wichtige Einrichtungen. Krankenhäuser fallen unter den Sektor "Gesundheit" und zählen je nach Größe als wichtige Einrichtungen. Für diese gilt unter anderem:

Pflicht zur Umsetzung von Maßnahmen nach §30 BSIG, darunter Schwachstellenmanagement, Patch-Management und Supply-Chain-Sicherheit
Meldepflicht nach §32 BSIG: Erhebliche Sicherheitsvorfälle sind innerhalb von 24 Stunden (Frühwarnung) und 72 Stunden (Meldung) an das BSI zu melden

Der F5-Vorfall selbst ist ein Vorfall beim Hersteller, kein direkter Vorfall in Ihrer Einrichtung. Solange keine aktive Ausnutzung in Ihrer Infrastruktur nachweisbar ist, besteht keine unmittelbare Meldepflicht. Jedoch: Wenn Konfigurationsdaten Ihrer Einrichtung nachweislich abgeflossen sind, ist zu prüfen, ob dies als sicherheitsrelevantes Ereignis meldepflichtig ist. Für rechtliche Beratung wenden Sie sich an einen Anwalt oder eine auf IT-Recht spezialisierte Kanzlei.

DSGVO und BDSG

Wenn BIG-IP als TLS-Terminierungspunkt Patientendaten verarbeitet (was in der Regel der Fall ist), kann der Abfluss von Konfigurationsdetails eine DSGVO-relevante Situation darstellen. Prüfen Sie, ob der Abfluss von Konfigurationsdaten das Risiko für die Rechte und Freiheiten der betroffenen Personen erhöht. Eine Datenschutz-Folgeabschätzung der veränderten Risikolage ist zu dokumentieren.

Übergeordnete Lektion: Supply-Chain-Sicherheit und Vertrauen in Herstelleraussagen

Der F5-Vorfall illustriert ein strukturelles Dilemma der IT-Sicherheit im Gesundheitswesen: Kritische Infrastrukturkomponenten wie Load Balancer, Firewalls oder SIEM-Systeme sind selbst Angriffsziele – und ihre Sicherheit ist zu einem erheblichen Teil vom Sicherheitsniveau des Herstellers abhängig.

Was dieser Vorfall für Ihr ISMS bedeutet:

Herstellerkommunikation als Informationsquelle bewerten: F5 kommuniziert, dass keine kritischen RCE-Schwachstellen abgeflossen seien. Diese Aussage basiert auf dem Kenntnisstand des Herstellers – und staatliche Angreifer haben keinen Anreiz, ihre Funde offenzulegen. Behandeln Sie Herstelleraussagen als einen von mehreren Datenpunkten, nicht als abschließende Bewertung.
Zero-Trust-Prinzip für kritische Netzwerkknoten: BIG-IP-Systeme sollten nicht deshalb als vertrauenswürdig gelten, weil sie als Sicherheitskomponenten positioniert sind. Monitoring, Integritätsprüfungen und minimale Berechtigungen gelten auch für Security-Appliances.
Supply-Chain-Risikobewertung im ISMS verankern: Das BSI-Grundschutz-Kompendium (OPS.2.3: Nutzung von Outsourcing) und ISO 27001 (Annex A, Kontrolle 5.19: Informationssicherheit in Lieferantenbeziehungen) fordern eine systematische Bewertung von Lieferantenrisiken. Ein Sicherheitsvorfall beim Hersteller einer kritischen Infrastrukturkomponente muss in Ihrem Risikomanagement-Prozess als Trigger für eine erneute Risikobewertung definiert sein.
Notfallplan für kompromittierte Sicherheitskomponenten: Haben Sie einen dokumentierten Notfallplan für den Fall, dass ein BIG-IP-System als kompromittiert gilt? Wer trifft die Entscheidung zur Abschaltung? Welche klinischen Prozesse fallen aus, wenn der Load Balancer offline geht? Diese Business Impact Analyse (BIA) sollte vorbereitet sein, bevor der Ernstfall eintritt.

Checkliste: Sofortmaßnahmen für ISB und IT-Leitung

Maßnahme	Priorität	Verantwortlich
F5-Support kontaktieren: Sind eigene Konfigurationsdaten betroffen?	Hoch	IT-Leitung
Alle BIG-IP-Instanzen inventarisieren (Version, Funktion, Netzwerkposition)	Hoch	IT-Betrieb
F5 Security Advisories auf neue CVEs überwachen	Hoch	Schwachstellenmanagement
Admin-Credentials und API-Keys rotieren	Hoch	IT-Betrieb
Zertifikate für TLS-Offloading neu ausstellen	Mittel	IT-Betrieb
iRules und Konfiguration auf Integrität prüfen	Mittel	IT-Betrieb
Management-Interface auf Out-of-Band-Netz beschränken	Mittel	Netzwerk
Logging auf BIG-IP erhö

Kostenlose NIS2-Bestandsaufnahme starten →