Penetrationstests: Schwachstellen finden & priorisieren

1. Methodik

Im Rahmen des White-Box-Penetrationstests kombinieren wir automatisierte SAST-Techniken mit einer tiefgehenden manuellen Quellcodeanalyse, um Implementierungsfehler, fehlerhafte Sicherheitslogik und strukturelle Schwachstellen bereits auf Code-Ebene zuverlässig zu identifizieren. Neben der maschinellen Erkennung untersuchen unsere Experten gezielt sicherheitskritische Bereiche, Architekturentscheidungen und komplexe Kontrollflüsse, die automatisierte Tools oftmals nicht erfassen können.

Der dynamische Anwendungssicherheitstest (DAST) wird durch unsere Penetrationstester um kreative Angriffstechniken, Angriffsvektorkombinationen und individuelle Angriffspfad-Analysen erweitert, die über die Fähigkeiten jeder automatisierten Lösung hinausgehen. Während DAST die laufende Anwendung und ihre Schnittstellen auf ausnutzbare Schwachstellen prüft, beziehen unsere Tester zusätzlich den konkreten Anwendungskontext, die abbildeten Geschäftsprozesse sowie mögliche unbeabsichtigte Interaktionen zwischen Komponenten ein. Dadurch werden komplexe Schwachstellen erkannt, die nur durch menschliches Verständnis der Anwendung und ihrer Abläufe identifiziert werden können.

Durch die Kombination aus SAST + manueller Codeanalyse sowie DAST + kreativer manueller Angriffssimulation erreichen wir eine besonders hohe Testtiefe und decken sowohl statische Implementierungsfehler als auch realistisch ausnutzbare Schwachstellen in der Laufzeitumgebung ab.

2. Prüfobjekt und Prüftiefe

Das folgende Prüfobjekt wurde im Rahmen der Vorbesprechung zur Angebotserstellung definiert:

• Web-Anwendung
  • Wir überprüfen, ob die Web-Anwendung resilient gegen die häufigsten Schwachstellen in Web-Anwendungen ist. Hierzu überprüfen wir alle Schwachstellen-Klassifizierungen, welche in den OWASP Top 10 Web 2025 (aktueller Release-Kandidat, auf Wunsch können alternativ die OWASP Top 10 2021 geprüft werden) aufgeführt sind:
    • A01:2025 - Broken-Access-Control: Wir prüfen, ob Benutzer nur auf die Ressourcen und Funktionen zugreifen können, für die sie autorisiert sind, und ob unautorisierte Zugriffe durch fehlerhafte Zugriffskontrollen verhindert werden.
    • A02:2025 - Security-Misconfiguration: Wir prüfen, ob Systeme, Server und Anwendungen sicher konfiguriert sind, z. B. keine unnötigen Dienste aktiv sind, Standardpasswörter geändert wurden und sicherheitsrelevante Header oder Berechtigungen korrekt gesetzt sind.
    • A03:2025 - Software-Supply-Chain-Failures: Wir prüfen, ob die eingesetzten Bibliotheken, Abhängigkeiten, Build-Prozesse und Software-Komponenten aus vertrauenswürdigen Quellen stammen und gegen Manipulation oder Kompromittierung geschützt sind.
    • A04:2025 - Cryptographic-Failures: Wir prüfen, ob kryptografische Verfahren korrekt implementiert und aktuelle Standards verwendet werden, um die Vertraulichkeit und Integrität sensibler Daten zu gewährleisten.
    • A05:2025 - Injection: Wir prüfen, ob Benutzereingaben korrekt validiert, bereinigt und parametrisiert werden, um Angriffe wie SQL-, Command- oder Script-Injection zu verhindern.
    • A06:2025 - Insecure-Design: Wir prüfen, ob die Anwendung bereits auf Architekturebene sicher entworfen wurde, etwa durch Threat-Modeling, Sicherheitsprinzipien und den gezielten Einsatz von Schutzmechanismen.
    • A07:2025 - Authentication-Failures: Wir prüfen, ob Authentifizierungsmechanismen sicher implementiert sind, z. B. durch starke Passwortrichtlinien, Multi-Faktor-Authentifizierung und korrekte Session-Verwaltung.
    • A08:2025 - Software-or-Data-Integrity-Failures: Wir prüfen, ob Software, Updates und Daten auf Integrität und Authentizität überprüft werden, um Manipulationen und unautorisiertes Ändern von Inhalten zu verhindern.
    • A09:2025 - Logging-and-Alerting-Failures: Wir prüfen, ob sicherheitsrelevante Ereignisse ausreichend protokolliert und Warnmeldungen ausgelöst werden, damit Angriffe oder Anomalien zeitnah erkannt und behandelt werden können.
    • A10:2025 - Mishandling-of-Exceptional-Conditions: Wir prüfen, ob Fehler- und Ausnahmebedingungen korrekt behandelt werden, ohne sicherheitsrelevante Informationen preiszugeben oder ungewollte Zustände zu erzeugen.

3. Abgrenzung des Prüfumfangs

Im Rahmen des Penetrationstests werden keine physischen Angriffe, Social-Engineering-Tests oder Denial-of-Service (DoS/DDoS)-Szenarien durchgeführt.

1. Regulatorische Rahmenbedingungen für den Penetrationstest im Rahmen der Premarket-Submission FDA

Bei der Durchführung eines White-Box-Penetrationstests im Kontext einer FDA-Premarket-Submission orientieren sich die Prüfmethoden an den sicherheitsrelevanten Empfehlungen der aktuellen FDA-Guidance für Medizinprodukte.

Der Prüfplan wird in der Vorbereitungsphase individuell erarbeitet und bildet die Grundlage für alle nachfolgenden Tests.

Die nachfolgenden Sicherheitsanforderungen dienen als strukturierte Übersicht der wesentlichen Prüfpunkte:

• Authentication
  • Wir prüfen, ob Authentifizierungsmechanismen der Software und des Betriebssystems unbefugten Zugriff zuverlässig verhindern und ob Identitäten sicher gespeichert, verwaltet und verifiziert werden.
• Authorization
  • Wir analysieren Rollen- und Berechtigungskonzepte, um sicherzustellen, dass unautorisierte Zugriffe auf sicherheits- oder patientenbezogene Funktionen ausgeschlossen sind.
• Cryptography
  • Wir bewerten die Implementierung kryptografischer Mechanismen hinsichtlich Vertraulichkeit, Integrität und Authentizität von Daten sowie deren korrekte Konfiguration.
• Code/Data/Execution Integrity
  • Wir prüfen, ob Schutzmechanismen gegen Manipulationen, unautorisierte Codeausführung oder Integritätsverletzungen wirksam umgesetzt sind.
• Confidentiality
  • Wir untersuchen, ob sensible Patienten-, Diagnose- und Systemdaten während Speicherung, Übertragung und Verarbeitung angemessen geschützt sind.
• Event Detection & Logging
  • Wir bewerten, ob sicherheitsrelevante Ereignisse erkannt, protokolliert und ausgewertet werden können, um Angriffe schnell zu identifizieren.
• Resiliency & Recovery
  • Wir prüfen die Widerstandsfähigkeit des Systems gegenüber Angriffen, Fehlfunktionen oder Datenkorruption und bewerten vorhandene Wiederanlauf- und Recovery-Mechanismen.
• Updatability / Patchability
  • Wir analysieren, ob sicherheitskritische Updates, Patches und Wartungsverfahren nachvollziehbar, sicher und ohne Gefährdung der klinischen Funktionalität durchgeführt werden können.

Hinweis: Die oben aufgeführten Sicherheitsanforderungen dienen der Übersicht. Ein detaillierter Prüfplan, welcher als Grundlage für den White-Box-Penetrationstest dient, wird durch die Prüfer der zentrust in der Vorbereitungsphase entwickelt.

2. Analyse von Hardware und physischen Schnittstellen

Der White-Box-Penetrationstest umfasst eine Analyse der Hardware-Komponenten und deren physischen Schnittstellen. Hierbei werden diese Komponenten auf Schwachstellen und Sicherheitsmängel analysiert welche durch einen Angreifer mit temporärem Zugriff auf das Prüfobjekt (Beispiel: Patient für kurze Zeit unbeaufsichtigt mit Prüfobjekt) geprüft.

Die Prüfer bedienen sich in dieser Phase primär „auf dem freien Markt“ zugänglichen Angriffswerkzeugen um dem gewählten Angriffszenario/Angriffspotenzial (siehe unten) Rechnung zu tragen.

3. Analyse von Software, Betriebssystem und Schnittstellen (SAST & DAST)

Im Rahmen des White-Box-Penetrationstests kombinieren wir automatisierte SAST-Techniken mit einer tiefgehenden manuellen Quellcodeanalyse, um Implementierungsfehler, fehlerhafte Sicherheitslogik und strukturelle Schwachstellen bereits auf Code-Ebene zuverlässig zu identifizieren. Neben der maschinellen Erkennung untersuchen unsere Experten gezielt sicherheitskritische Bereiche, Architekturentscheidungen und komplexe Kontrollflüsse, die automatisierte Tools oftmals nicht erfassen können.

Der dynamische Anwendungssicherheitstest (DAST) wird durch unsere Penetrationstester um kreative Angriffstechniken, Angriffsvektorkombinationen und individuelle Angriffspfad-Analysen erweitert, die über die Fähigkeiten jeder automatisierten Lösung hinausgehen. Während DAST die laufende Anwendung und ihre Schnittstellen auf ausnutzbare Schwachstellen prüft, beziehen unsere Tester zusätzlich den konkreten Anwendungskontext, die abbildeten Geschäftsprozesse sowie mögliche unbeabsichtigte Interaktionen zwischen Komponenten ein. Dadurch werden komplexe Schwachstellen erkannt, die nur durch menschliches Verständnis der Anwendung und ihrer Abläufe identifiziert werden können.

Durch die Kombination aus SAST + manueller Codeanalyse sowie DAST + kreativer manueller Angriffssimulation erreichen wir eine besonders hohe Testtiefe und decken sowohl statische Implementierungsfehler als auch realistisch ausnutzbare Schwachstellen in der Laufzeitumgebung ab.

Zusätzlich wird die Härtung des Microsoft Windows Betriebssystems für die definierten Umgebungs- und Betriebsbedingungen während des White-Box-Penetrationstests analysiert. Die Analyse der Härtung umfasst einen Vergleich mit international anerkannten Standards (Sicherheitsempfehlungen) für die sichere Ausführung des Betriebssystems.

Zu diesem Zweck wird der CIS (Center for Internet Security) Benchmark für Microsoft Windows 11 / Windows 11 Enterprise als primärer Referenzstandard herangezogen. Der CIS-Benchmark dient als Baseline für empfohlene Konfigurations- und Sicherheitsmaßnahmen (Gruppenrichtlinien, Registry-Einstellungen, Services, Audit-Konfigurationen, Firewall- und Verschlüsselungseinstellungen etc.). Die Prüfung berücksichtigt die jeweils aktuelle Version des CIS-Benchmarks, die für den Ziel-Build relevant ist.

4. Bewertung des Angreiferpotenzials (CEM – Common Methodology for IT Security Evaluation)

Zur Bewertung der Sicherheit des Prüfobjekts wurde das Angreiferpotenzial gemäß der Common-Methodology-for-Information-Technology-Security-Evaluation (CEM) bestimmt. Die Bestimmung des Angreiferpotenzials dient dazu, die erwarteten Fähigkeiten, Ressourcen und Motivationen potenzieller Angreifer zu klassifizieren und damit den erforderlichen Prüfaufwand sowie die Aussagekraft der Testergebnisse nachvollziehbar und reproduzierbar zu gestalten. Dabei werden Faktoren wie Fachwissen, Kenntnis des ToE, Zugriffsmöglichkeiten, Ausrüstung sowie Zeitaufwand (siehe Tabelle B.2 der CEM) herangezogen, um das erwartete Angreiferpotenzial zu charakterisieren.

Diese Vorgehensweise ermöglicht eine transparente Einordnung der Prüfergebnisse in Bezug auf die realistisch zu erwartenden Bedrohungsszenarien im Rahmen der beabsichtigten Anwendung und des vorgesehenen Einsatzumfeldes des Prüfobjektes.

Die resultierende Punktzahl erlaubt eine Einordnung des erforderlichen Aufwands zur erfolgreichen Ausnutzung einer Schwachstelle in eine von fünf Kategorien (siehe Tabelle B.3 der CEM):

Im Rahmen des White-Box-Penetrationstest wird erwartet, dass die Wirksamkeit der Schutzmaßnahmen welche durch die Sicherheitsanforderungen aus der FDA-Guidance implizit vorgegeben werden, dem berechneten Angreiferpotenzial standhalten. Kann die Wirksamkeit nicht nachgewiesen werden, so wird dies als eine Abweichung (Fail) erfasst. In den unten aufgeführten Angriffsszenarien wird die für das geschilderte Angriffsszenario spezifische Berechnung in tabellarischer Form aufgeführt

6. Angriffsszenarien und Angreiferpotenzial

Szenario „Physisch“

In diesem Angriffsszenario wird ein Angreifer simuliert, der für einen kurzen Zeitraum unbeaufsichtigten physischen Zugriff auf das Prüfobjekt erhält. Es wird angenommen, dass der Angreifer aus finanziellen Motiven handelt und ein besonderes Interesse am Zugriff auf unzureichend geschützte Patienteninformationen (Vertraulichkeit) hat. Erfolgt ein erfolgreicher Zugriff, könnten diese Informationen verkauft oder zur Erpressung verwendet werden.

Beispiel: Ein Patient (Angreifer) wird zu einer Untersuchung in der Arzt-Praxis in das Untersuchungszimmer geführt. Die Tür zum Flur wird mit dem Hinweis geschlossen, dass der Arzt in Kürze erscheinen wird. In diesem Zeitraum hat der Angreifer unbeaufsichtigten physischen Zugriff auf das Prüfobjekt.

Da der Angreifer unentdeckt bleiben möchte, scheiden aufwändige physische Manipulationen, beispielsweise das Öffnen des Gehäuses, aus. Der Angriff konzentriert sich daher auf physisch zugängliche Schnittstellen sowie Ein- und Ausgabegeräte des Systems.

Berechnung des Angreiferpotenzials für dieses Szenario:

Szenario „Netzwerk“

In diesem Angriffsszenario wird ein Angreifer simuliert, der über das Netzwerk auf das Prüfobjekt zugreift. Es wird angenommen, dass sich der Angreifer bereits innerhalb des internen Netzwerks einer Arzt-Praxis befindet.

Der Angreifer handelt aus finanziellen Motiven und hat das Ziel, auf sensible Patienteninformationen zuzugreifen oder die Funktionsfähigkeit des medizinischen Geräts zu beeinträchtigen, um Lösegeldforderungen zu stellen. Das Hauptaugenmerk liegt hierbei auf der Vertraulichkeit und Verfügbarkeit der verarbeiteten Daten.

Beispiel: Nach einer erfolgreichen Kompromittierung eines Arbeitsplatzrechners im Praxisnetzwerk scannt der Angreifer das interne Netz nach erreichbaren Geräten. Das Prüfobjekt wird als vernetztes medizinisches Gerät identifiziert, das über standardisierte Protokolle (z. B. TCP/IP, HTTP oder proprietäre Schnittstellen) kommuniziert. Der Angreifer versucht, über bekannte oder unsicher konfigurierte Netzwerkdienste, Standardzugänge oder fehlende Authentifizierungsmechanismen Zugriff auf das Gerät oder die übertragenen Daten zu erlangen.

Da der Angriff verdeckt und aus der Ferne erfolgt, stehen dem Angreifer keine physischen Manipulationsmöglichkeiten zur Verfügung. Das Angriffsszenario erfordert technisches Fachwissen über Netzwerkinfrastrukturen, gängige Angriffsvektoren sowie Kenntnisse über die Kommunikationsschnittstellen des Prüfobjekts.

Berechnung des Angreiferpotenzials für dieses Szenario:

7. Abgrenzung des Prüfumfangs

Im Rahmen des Penetrationstests werden keine Social-Engineering-Tests durchgeführt.