Penetrationstests richtig einordnen und beauftragen

Ein Penetrationstest ist eine zeitlich begrenzte, beauftragte Sicherheitsüberprüfung, bei der Tester Schwachstellen manuell identifizieren, verketten und kontrolliert ausnutzen, um deren reales Risiko zu belegen. Ein Schwachstellenscan ist davon klar abzugrenzen: Er prüft automatisiert und in der Breite gegen bekannte Schwachstellenmuster, verifiziert Funde aber nicht und liefert regelmäßig Falschmeldungen – er ist Bestandteil des laufenden Schwachstellenmanagements, kein Ersatz für einen Pentest. Red Teaming wiederum verfolgt ein anderes Ziel: Es simuliert verdeckt einen realistischen Angriff auf definierte Krongüter und prüft dabei auch Detektions- und Reaktionsfähigkeit der Verteidiger, während ein Penetrationstest einen abgegrenzten Scope möglichst vollständig auf Schwachstellen untersucht.

Webanwendungs- und API-Tests prüfen u. a. Authentifizierung, Session-Management, Zugriffskontrolle und Injection-Schwachstellen. Externe Infrastrukturtests nehmen die aus dem Internet erreichbare Angriffsfläche ins Visier, interne Tests gehen von einem Angreifer im Netzwerk aus und untersuchen etwa Rechteausweitung, Lateral Movement und Active-Directory-Schwächen. Cloud-Pentests konzentrieren sich auf Fehlkonfigurationen, Identitäts- und Berechtigungsmodelle im Rahmen der geteilten Verantwortung mit dem Provider. Mobile-App-Tests betrachten lokale Datenhaltung, Plattformschutzmechanismen und die Backend-Schnittstellen; WLAN-Tests prüfen Authentisierung, Verschlüsselung und Netzsegmentierung am Standort.

Die Einteilung beschreibt, wie viel Vorwissen die Tester erhalten. Beim Black-Box-Test starten sie ohne interne Informationen – realistisch aus Angreifersicht, aber zeitintensiv und mit geringerer Abdeckung, weil Testzeit in die Informationsbeschaffung fließt. Beim White-Box-Test stehen Architekturunterlagen, Konfigurationen oder Quellcode zur Verfügung, was die größte Testtiefe pro Zeiteinheit ermöglicht. Der Grey-Box-Ansatz liegt dazwischen, typischerweise mit Testzugängen und Dokumentation; in der Praxis hat er sich für die meisten Prüfziele als effizienter Standard etabliert. Unabhängig davon werden Perspektive (extern/intern) und Grad der Ankündigung im Scoping festgelegt.

Anerkannte Methodiken machen Penetrationstests nachvollziehbar und vergleichbar. Für Webanwendungen und APIs ist der OWASP Web Security Testing Guide (WSTG) die Referenz; die aktuelle stabile Version 4.2 erschien im Dezember 2020, Version 5.0 befindet sich in Entwicklung. Der Penetration Testing Execution Standard (PTES, Version 1.0) strukturiert den Gesamtprozess in sieben Phasen von den Pre-Engagement-Interaktionen über Informationsgewinnung, Threat Modeling, Schwachstellenanalyse, Exploitation und Post-Exploitation bis zum Reporting. Für den deutschsprachigen Raum beschreibt der BSI-„Praxis-Leitfaden für IS-Penetrationstests“ (Stand 2016) ein strukturiertes Vorgehen und gibt insbesondere Hilfestellung bei der Beauftragung. Seriöse Anbieter legen die verwendete Methodik im Bericht offen.

Ein Penetrationstest beginnt mit dem Scoping: Ziele, Systeme, Testfenster, Ausschlüsse und Notfallkontakte werden schriftlich festgelegt. Es folgen Informationsbeschaffung und Schwachstellenanalyse, die kontrollierte Ausnutzung relevanter Funde sowie der Bericht mit Management-Zusammenfassung, technischen Details, Risikobewertung und priorisierten Maßnahmenempfehlungen; ein Retest nach der Behebung schließt den Zyklus ab. Rechtlich unverzichtbar ist die vorherige schriftliche Beauftragung durch den Berechtigten („Permission to Test“): Ohne sie können Testhandlungen Straftatbestände der §§ 202a ff. StGB (Ausspähen und Abfangen von Daten) erfüllen. Systeme Dritter – etwa bei Hosting-, Cloud- oder SaaS-Anbietern – dürfen nur mit deren Zustimmung bzw. im Rahmen ihrer Testrichtlinien geprüft werden; Vertraulichkeits- und Datenschutzvereinbarungen gehören in jeden Vertrag.

Einen universellen Pflichtturnus gibt es nicht; etabliert ist eine mindestens jährliche Prüfung kritischer Systeme plus anlassbezogene Tests nach wesentlichen Änderungen an Architektur oder Anwendungen. NIS2 (Richtlinie (EU) 2022/2555) verlangt in Art. 21 Abs. 2 Buchst. f Konzepte und Verfahren zur Bewertung der Wirksamkeit der Risikomanagementmaßnahmen – Penetrationstests sind hierfür ein etabliertes Mittel. Für den Finanzsektor nennt DORA (Verordnung (EU) 2022/2554, anwendbar seit 17.01.2025) Penetrationstests ausdrücklich als Teil des Resilienz-Testprogramms (Art. 25); von den Behörden dafür bestimmte Finanzunternehmen müssen zusätzlich mindestens alle drei Jahre bedrohungsorientierte Penetrationstests (TLPT) nach Art. 26 durchführen. Im Automotive-Umfeld erwarten TISAX-Assessments auf Basis des VDA-ISA-Katalogs (Version 6; für ab 2027 beauftragte Assessments der Nachfolgekatalog ISA 2027) Nachweise regelmäßiger technischer Überprüfungen und eines wirksamen Schwachstellenmanagements – Penetrationstests sind dafür ein gängiges Nachweismittel.