Termin vereinbaren

Penetrationstests richtig einordnen und beauftragen

Wie ein Penetrationstest funktioniert, worin er sich von Schwachstellenscans und Red Teaming unterscheidet – und welche Methodiken, Abläufe und regulatorischen Vorgaben bei der Beauftragung relevant sind.

Ein Penetrationstest ist ein autorisierter, kontrollierter Angriff auf die eigenen Systeme: Sicherheitsexperten versuchen mit den Methoden realer Angreifer, Schwachstellen zu finden und deren tatsächliche Ausnutzbarkeit nachzuweisen. Damit beantwortet er eine Frage, die automatisierte Scans offenlassen – welche Lücken im Zusammenspiel wirklich zu einem Sicherheitsvorfall führen können. Mit NIS2, DORA und TISAX wird der Nachweis wirksamer technischer Sicherheitsmaßnahmen zunehmend zur regulatorischen Erwartung. Dieser Beitrag ordnet Begriffe, Testarten, Methodiken, Ablauf und Turnus ein.

Das Wichtigste im Überblick

01

Was ein Penetrationstest ist – und was nicht

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.

02

Testarten: von der Webanwendung bis zum WLAN

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.

03

Black-, Grey- und White-Box: die Informationsbasis

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.

04

Methodiken: OWASP WSTG, PTES und BSI-Leitfaden

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.

05

Ablauf und rechtliche Grundlage

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.

06

Turnus und regulatorische Auslöser: NIS2, DORA, TISAX

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.

Standards & Quellen

Die Inhalte dieser Seite basieren auf den folgenden öffentlich verfügbaren Leitfäden und Studien.

OWASP Foundation · 2020

OWASP Web Security Testing Guide v4.2

Referenz-Testkatalog für Webanwendungen und APIs; Version 4.2 seit Dezember 2020, Version 5.0 in Entwicklung.

Bundesamt für Sicherheit in der Informationstechnik (BSI) · 2016

Ein Praxis-Leitfaden für IS-Penetrationstests

Deutschsprachige Hilfestellung zu Ablauf und Beauftragung von IS-Penetrationstests (Stand 08.11.2016).

Amtsblatt der EU / EUR-Lex · 2022

Richtlinie (EU) 2022/2555 (NIS2)

Art. 21 Abs. 2 Buchst. f fordert Konzepte und Verfahren zur Bewertung der Wirksamkeit der Cybersicherheits-Risikomanagementmaßnahmen.

Amtsblatt der EU / EUR-Lex · 2022

Verordnung (EU) 2022/2554 (DORA)

Art. 25 nennt Penetrationstests als Teil des Testprogramms, Art. 26 verlangt TLPT mindestens alle drei Jahre; anwendbar seit 17.01.2025.

Verband der Automobilindustrie (VDA) / ENX Association · 2023

VDA Information Security Assessment (ISA) Version 6

Prüfgrundlage der TISAX-Assessments; Version 6.0 ist seit dem 1. April 2024 verbindlich für neu beauftragte Assessments (aktuelle Fassung 6.0.3), der Nachfolgekatalog ISA 2027 gilt für Bestellungen ab dem 01.01.2027.

Penetrationstest geplant?

In einem unverbindlichen Erstgespräch klären wir mit Ihnen Scope, Testtiefe und den passenden Turnus für Ihre Systeme.