⚠️ Mögliche Auswirkung auf Patientensicherheit

Betroffene Einrichtungen

🏥 Krankenhaus🏨 Fachklinik🏃 Rehaklinik🏡 Pflegeheim🔬 Labor🏢 Ambulantes Zentrum

Bereich

IT-InfrastrukturNetzwerkEndgeräte
Beschreibung

In EG Secure Solutions SiteGuard Server Edition wurde eine kritische OS-Command-Injection-Schwachstelle identifiziert, die es einem Angreifer ermöglicht, beliebige Betriebssystembefehle mit Root- bzw. SYSTEM-Privilegien auf dem betroffenen System auszuführen. Die vollständige Kompromittierung des Systems einschließlich aller darauf gespeicherter oder verarbeiteter Daten ist damit möglich. SiteGuard Server Edition wird als Web-Application-Firewall-Lösung zum Schutz von Webservern und Webanwendungen eingesetzt; sofern diese Lösung im Klinikumfeld zum Schutz von KIS-, PACS- oder Patientenportal-Frontends betrieben wird, besteht das Risiko, dass Angreifer über die kompromittierte Schutzschicht in kritische klinische Systeme eindringen und Patientendaten gefährden. Da die Schwachstelle bereits als aktiv ausgenutzt (CISA KEV) eingestuft ist, ist eine sofortige Priorisierung der Patches und Netzwerksegmentierung dringend erforderlich.

Handlungsempfehlung

1 SiteGuard Server Edition sofort auf die vom Hersteller EG Secure Solutions bereitgestellte gepatchte Version aktualisieren – Herstelleradvisory und Patch-Verfügbarkeit unter der offiziellen EG-Secure-Solutions-Supportseite prüfen und verfügbaren Sicherheits-Patch unverzüglich einspielen.

2. Bis zur Verfügbarkeit eines Patches den Netzwerkzugang zur SiteGuard-Server-Edition auf autorisierte Administratoren und vertrauenswürdige Netzsegmente beschränken (Firewall-Regeln, ACLs) und externe Erreichbarkeit unterbinden.

3. Systemlogs und Prozessaktivitäten des betroffenen Servers auf Anzeichen einer bereits erfolgten Kompromittierung (unbekannte Prozesse mit Root-/SYSTEM-Rechten, ungewöhnliche Netzwerkverbindungen) analysieren.

4. Privilegierte Konten und Dienstkonten auf dem betroffenen System überprüfen, nicht benötigte Zugänge sperren und Passwörter zurücksetzen, um eine laterale Bewegung im Netz zu erschweren.

5. Vorfall gemäß internem Incident-Response-Plan dokumentieren und – sofern KRITIS-relevant – Meldepflichten gegenüber BSI (NIS2) bzw. CERT.at (NISG) prüfen und ggf. einleiten.

🔒

Weitere konkrete Handlungsschritte für Ihre IT-Abteilung
sind ISMShield AI Kunden vorbehalten.

Jetzt freischalten →
Regulatorische Einordnung

NIS2-Relevanz: •••    B3S: •••    ISG: ••ˆ    Meldepflicht DE: ja

🔒

Regulatorische Einordnung (NIS2, B3S, ISG, nDSG)
nur für ISMShield AI Kunden.

Details freischalten →