Was ein Penetrationstest leistet – und was nicht
Ein Penetrationstest liefert eine belastbare Aussage darüber, ob ein Angreifer mit realistischem Aufwand ein bestimmtes Ziel erreichen kann. Er zeigt Verkettungen, die kein Scanner findet: eine harmlos wirkende Fehlkonfiguration, die zusammen mit einem veralteten Dienst und zu weit gefassten Berechtigungen einen Weg zu produktiven Daten eröffnet.
Er liefert keinen Nachweis von Sicherheit. Das Ergebnis ist eine Stichprobe zu einem Zeitpunkt, in einem festgelegten Bereich, mit dem Wissen und dem Zeitbudget des beauftragten Teams. Ein Bericht ohne Befunde bedeutet, dass innerhalb dieser Grenzen nichts gefunden wurde – nicht, dass nichts vorhanden ist. Wer den Test als Ersatz für ein laufendes Schwachstellenmanagement einsetzt, verwechselt Momentaufnahme und Prozess.
Was unterscheiden Black-Box-, Grey-Box- und White-Box-Tests?
| Unterscheidung | Ausprägungen | Bedeutung für das Ergebnis |
|---|---|---|
| Informationsstand | Black Box, Grey Box, White Box | Je mehr Informationen das Testteam erhält, desto mehr Prüftiefe entsteht pro Zeiteinheit; Black Box misst eher die Erkennbarkeit von außen |
| Ausgangspunkt | extern (aus dem Internet), intern (aus dem Netz heraus) | Interne Tests zeigen die Ausbreitungswege nach einem erfolgreichen Erstzugriff |
| Gegenstand | Netz und Infrastruktur, Webanwendung, API, mobile Anwendung, Client, physischer Zugang, Social Engineering | Jeder Gegenstand braucht eigene Methodik und eigene Freigaben |
| Zielsetzung | Befundorientierter Test, bedrohungsorientiertes Red Teaming | Ein Pentest sucht möglichst viele Schwachstellen, ein Red Teaming prüft ein Angriffsziel und zugleich die eigene Erkennungsfähigkeit |
Vor der Beauftragung: der Geltungsbereich
Die Qualität eines Tests entscheidet sich vor dem ersten Prüftag. Schriftlich festzulegen sind mindestens: die genauen Ziele nach Adresse, Anwendung oder Konto; ausdrückliche Ausschlüsse; das Testfenster; erlaubte und unzulässige Techniken, insbesondere zu Denial-of-Service und Social Engineering; der Umgang mit gefundenen echten Daten; ein Notfallkontakt auf beiden Seiten; und die Frage, wie verfahren wird, wenn während des Tests Hinweise auf eine bereits bestehende Kompromittierung auftauchen.
Zwei Punkte werden regelmäßig übersehen. Erstens braucht es die Freigabe des Systemeigentümers, bei fremdbetriebenen Umgebungen zusätzlich die des Betreibers oder Cloud-Anbieters. Zweitens ist die schriftliche Beauftragung nicht nur eine Formalie: Prüfhandlungen an fremden Systemen können ohne die Einwilligung des Berechtigten strafrechtlich relevant sein.
Was muss ein Bericht zum Penetrationstest enthalten?
Ein brauchbarer Bericht enthält eine Zusammenfassung für die Leitung ohne Fachjargon, je Befund eine nachvollziehbare Beschreibung des Wegs mit Belegen, eine Einschätzung der Auswirkung im konkreten Umfeld und eine konkrete Empfehlung. Was er nicht enthalten sollte, ist eine ungefilterte Ausgabe eines Werkzeugs.
Ebenso wichtig ist der Umgang danach: Befunde gehören in dieselbe Behandlungslogik wie alle anderen Schwachstellen, mit Verantwortlichem, Frist und Nachprüfung. Ein vereinbarter Nachtest nach der Behebung ist der einzige belastbare Nachweis, dass die Befunde tatsächlich geschlossen wurden.
Regulatorischer Kontext
ISO/IEC 27001 verlangt, die Wirksamkeit der Maßnahmen zu bewerten, schreibt dafür aber keinen Penetrationstest und keinen Turnus vor. § 30 Abs. 2 Satz 2 BSIG formuliert ein Mindestmaß und verlangt in Nr. 6 „Konzepte und Verfahren zur Bewertung der Wirksamkeit von Risikomanagementmaßnahmen im Bereich der Sicherheit in der Informationstechnik“ — ein Verfahren also, keine Methode. Ein Penetrationstest ist eine mögliche Ausprägung, das Gesetz nennt ihn nicht.
Am weitesten geht DORA (Verordnung (EU) 2022/2554): Kapitel IV, Artikel 24 bis 27 regelt das Testen der digitalen operationalen Resilienz; nach Artikel 24 Absatz 6 sind Systeme, die kritische oder wichtige Funktionen stützen, mindestens jährlich angemessen zu testen. Für die von der Aufsicht dafür ermittelten Finanzunternehmen kommen bedrohungsorientierte Penetrationstests hinzu — das ist der amtliche deutsche Begriff der Verordnung (Artikel 3 Nummer 17), nicht „bedrohungsgeleitet“. Nach Artikel 26 Absatz 1 sind sie mindestens alle drei Jahre durchzuführen; die zuständige Behörde kann diese Häufigkeit herauf- oder herabsetzen. Welche kritischen oder wichtigen Funktionen ein solcher Test einschließt, bewertet das Unternehmen selbst; die Behörde validiert den daraus folgenden Umfang. Artikel 26 Absatz 11 verweist für die Durchführung ausdrücklich auf den TIBER-EU-Rahmen.
Häufigkeit
Ein verbindliches Intervall gibt es außerhalb sektorspezifischer Vorgaben nicht. Organisationen leiten die Frequenz üblicherweise aus dem Schutzbedarf des Systems, seiner Erreichbarkeit von außen, der Änderungsrate und vertraglichen Zusagen gegenüber Kunden ab. Verbreitet sind Tests vor der Produktivsetzung neuer extern erreichbarer Anwendungen und nach wesentlichen Architekturänderungen. Ein jährlicher Test, der immer denselben Bereich prüft, während der Rest der Landschaft ungeprüft bleibt, erzeugt vor allem Routine.
Das Scoping-Problem vor dem Test
Der häufigste Mangel eines Penetrationstests liegt vor dem Test: Geprüft wird, was im Auftrag steht, und im Auftrag steht, woran sich jemand erinnert hat. Systeme, die niemand genannt hat, bleiben unberührt, und der Bericht wirkt dadurch besser als die Lage.
In Rizzqo ist der Prüfumfang aus dem Bestand ableitbar statt aus einer Erinnerung. Objekte liegen klassifiziert und mit ihren Verknüpfungen vor, und der geerbte Schutzbedarf zeigt, welche von ihnen die kritischen Prozesse tragen. Nach dem Test lässt sich ein Befund der betroffenen Anforderung an dem Objekt zuordnen, an dem er festgestellt wurde, als Risikobewertung in Eintrittswahrscheinlichkeit und Schadenshöhe in Euro bewerten und über eine Maßnahme abarbeiten.