Penetrationstest richtig beauftragen: Scope, Zugänge und Rules of Engagement
Von Nico Freitag, Geschäftsführer, Cybersecurity und Governance
Ein Penetrationstest wird belastbar, wenn Ziel, Systeme, Rollen, erlaubte Methoden, Testzeiten, Schutzmaßnahmen und Sofortmeldewege vor dem ersten Angriff schriftlich geklärt sind. Der Scope ist keine bloße URL-Liste. Er beschreibt die tatsächliche Angriffsfläche und legt fest, wie Tester, Auftraggeber und Betrieb bei kritischen Funden oder Störungen handeln.
Welches Ziel soll der Test beantworten?
Ein Test kann eine neue Webanwendung, eine API, einen externen Zugang, ein internes Netz oder einen vollständigen Angriffspfad prüfen. Formuliert zuerst die geschäftliche Frage: Soll ein Go-live abgesichert, eine Kundenanforderung belegt oder die Wirkung mehrerer Sicherheitsmaßnahmen geprüft werden? Daraus folgen Tiefe, Testart und Bericht. Ohne Ziel entsteht leicht eine breite Werkzeugprüfung, die viele Auffälligkeiten nennt, aber die entscheidende Unsicherheit des Auftraggebers nicht beantwortet.
Was gehört in einen vollständigen Scope?
Erfasst Domains, IP-Bereiche, APIs, mobile Anwendungen, Identitätsdienste, Rollen, Mandanten und relevante Drittanbieter. Benennt ausdrücklich ausgeschlossene Systeme und technisch verbundene Nachbarn. Klärt Testdaten, Benutzerkonten mit unterschiedlichen Rechten und verfügbare Dokumentation. Die OWASP Web Security Testing Guide strukturiert die Prüfung von Informationssammlung über Identität, Autorisierung, Sitzung, Eingaben und Geschäftslogik. Diese Struktur hilft, den Scope auf Funktionen statt nur auf Adressen zu beziehen.
Welche Rules of Engagement sind notwendig?
Legt Testfenster, Quelladressen, erlaubte Last, Umgang mit personenbezogenen Daten, Social Engineering, DoS-nahe Methoden und mögliche Persistenz fest. Bestimmt einen rund um die Uhr erreichbaren Kontakt und einen sicheren Kanal für kritische Funde. Definiert Stop-Kriterien, Beweissicherung und die Entscheidung, ob ein gefundener Weg weiter ausgenutzt werden darf. Die Regeln schützen nicht vor jedem Risiko, schaffen aber eine gemeinsame Handlungsgrundlage, bevor Zeitdruck entsteht.
Black Box, Grey Box oder White Box?
Black Box bildet geringe Vorkenntnis ab, verbraucht aber viel Zeit für Aufklärung. Grey Box stellt typische Konten und Grundinformationen bereit und erlaubt häufig mehr Prüfung der Geschäftslogik. White Box ergänzt Architektur oder Quellcode und eignet sich, wenn möglichst viel Sicherheitswirkung pro Testtag erreicht werden soll. Die Wahl ist keine Qualitätsstufe. Sie folgt der Fragestellung, dem Bedrohungsmodell und dem verfügbaren Budget. Für kritische Anwendungen ist eine Kombination oft sinnvoll.
Wie sieht ein verwertbares Ergebnis aus?
Jeder Fund braucht einen reproduzierbaren Nachweis, betroffene Komponenten, Voraussetzung, Wirkung und eine realistische Behebung. Priorisiert wird nach tatsächlicher Ausnutzbarkeit und Geschäftswirkung, nicht allein nach Werkzeugwert. Kritische Punkte werden sofort gemeldet. Der Abschluss umfasst eine technische Fassung, eine verständliche Leitungseinordnung, eine gemeinsame Besprechung und einen Nachtest. Zusätzlich sollte sichtbar sein, welche Bereiche geprüft wurden und welche Restunsicherheit außerhalb des Scopes bleibt.
Quellen und Grundlage
Zentrale Aussagen dieses Beitrags wurden anhand der folgenden Primärquellen geprüft.
Häufige Fragen
- Darf während des Tests Produktion geprüft werden?
- Das kann sinnvoll sein, muss aber anhand von Risiko, Ausweichmöglichkeiten und Regeln bewusst entschieden werden. Besonders belastende oder zerstörerische Methoden brauchen klare Grenzen.
- Wie viele Testkonten werden benötigt?
- Mindestens die relevanten Rollen und Mandanten müssen abgebildet werden. Autorisierungsfehler bleiben sonst leicht unsichtbar.
- Ist ein Schwachstellenscan Teil des Pentests?
- Werkzeuge können unterstützen. Der wesentliche Unterschied liegt in manueller Prüfung, Angriffsketten, Geschäftslogik, nachvollziehbarer Wirkung und fachlicher Priorisierung.