Ein guter Penetrationstest beginnt vor dem ersten Request. Unklare Ziele, fehlende Rollen und verspätete Zugänge verbrauchen Testzeit, ohne die Sicherheit zu erhöhen. Eine strukturierte Vorbereitung sorgt dafür, dass der Pentester relevante Angriffspfade prüfen kann und das Entwicklungsteam am Ende verwertbare Ergebnisse erhält.
Das Geschäftsziel nennen
„Wir brauchen einen Pentest“ beschreibt noch keinen Prüfschwerpunkt. Der Anlass kann ein bevorstehender Launch, eine Kundenanforderung, ein wesentlicher Architekturwechsel oder eine konkrete Risikofrage sein. Daraus entstehen unterschiedliche Tests.
Hilfreiche Ziele sind beispielsweise:
- Mandantentrennung und Rollenmodell vor dem Go-live prüfen,
- die externe API einschließlich Partnerzugängen bewerten,
- Angriffspfade aus dem Internet bis zu kritischen Daten untersuchen,
- Korrekturen aus einem früheren Audit verifizieren,
- eine mobile App samt Backend und lokaler Speicherung prüfen.
Ein klares Ziel hilft, Zeit auf die teuersten Risiken zu konzentrieren.
Scope technisch eindeutig festlegen
Der Scope enthält mehr als eine Hauptdomain. Subdomains, APIs, mobile Builds, IP-Bereiche, Cloud-Ressourcen und Quellcode müssen ausdrücklich ein- oder ausgeschlossen werden. Drittanbieter-Systeme dürfen nur mit passender Erlaubnis getestet werden.
| Angabe | Beispiel |
|---|---|
| Systeme | Webanwendung, API, Adminbereich, mobile App |
| Umgebung | dediziertes Staging oder kontrollierte Produktion |
| Rollen | Gast, Kunde, Manager, Administrator |
| Testarten | manuell, automatisiert, Quellcodeanalyse |
| Ausschlüsse | Lasttests, Social Engineering, echte Zahlungen |
| Zeitfenster | normale Tests und besonders riskante Aktionen |
DNS-Namen und IPs werden vor Beginn verifiziert. Alte oder vergessene Systeme können wichtig sein, dürfen aber nicht ohne Autorisierung aktiv getestet werden.
Repräsentative Konten und Daten bereitstellen
Für Berechtigungsprüfungen werden mindestens zwei Konten derselben Rolle und Konten unterschiedlicher Rollen benötigt. So lässt sich horizontaler Zugriff zwischen Nutzern und vertikaler Zugriff auf höhere Funktionen unterscheiden. Bei Mandantenfähigkeit sind Konten in mindestens zwei getrennten Organisationen sinnvoll.
Testdaten sollten fachlich realistisch, aber nicht unnötig personenbezogen sein. Der Pentester benötigt verständliche Objekte, Statuswechsel und Beziehungen. Eine leere Testumgebung verhindert viele relevante Prüfungen.
Dokumentation gezielt auswählen
Nützlich sind Architekturübersicht, Rollenmatrix, API-Spezifikation, Datenfluss, bekannte Einschränkungen und Änderungen seit dem letzten Test. White-Box-Informationen machen einen Test nicht weniger realistisch. Sie ermöglichen, mehr Zeit in tiefe Angriffspfade statt in vermeidbare Orientierung zu investieren.
Bei einem Quellcode-Review gehören Build-Anleitung, relevante Repositories, verwendete Revision und Umgang mit Secrets in die Vorbereitung. Zugangsdaten werden über einen vereinbarten sicheren Kanal geteilt und nach Abschluss rotiert oder deaktiviert.
Kommunikation während des Tests
Vor Beginn stehen fachliche und technische Kontakte fest. Kritische Findings werden nicht bis zum Abschlussbericht zurückgehalten. Der Meldeweg nennt Erreichbarkeit, erwartete Reaktionszeit und wer einen Test bei Betriebsproblemen stoppen kann.
Die Rules of Engagement regeln:
- erlaubte und verbotene Methoden,
- Umgang mit gefundenen Daten,
- Beweissicherung und minimale Ausnutzung,
- Rate Limits und Betriebsgrenzen,
- Sofortmeldung kritischer Ergebnisse,
- Löschung oder Rückgabe von Projektdaten.
Einen verwertbaren Bericht vereinbaren
Ein Finding braucht Titel, Schwere, betroffene Komponente, Voraussetzung, reproduzierbare Schritte, Evidenz, Auswirkung und konkrete Korrektur. Eine reine Scannerliste erfüllt diesen Zweck nicht. Der Managementteil erklärt die wichtigsten Risiken und Abhängigkeiten ohne technische Details zu verfälschen.
CVSS kann technische Schwere vergleichbar machen. Die Priorität entsteht jedoch erst zusammen mit Erreichbarkeit, Datenwert, vorhandenen Kontrollen und geschäftlicher Bedeutung. Das Entwicklungsteam sollte Findings direkt mit dem Tester besprechen können.
Nachtest von Anfang an einplanen
Ein Nachtest prüft die konkrete Korrektur und mögliche Varianten der Ursache. Dafür müssen Version, Umgebung und erwartetes Verhalten dokumentiert sein. Idealerweise ergänzt das Entwicklungsteam einen automatisierten Regressionstest, damit derselbe Fehler nicht unbemerkt zurückkehrt.
Nicht jedes Finding wird sofort behoben. Akzeptierte Risiken benötigen Verantwortlichkeit, Begründung, kompensierende Kontrollen und ein Ablaufdatum für die erneute Entscheidung.
Übergabepaket vor Testbeginn
Diese Tabelle kann direkt als gemeinsame Startcheckliste verwendet werden:
| Paket | Muss enthalten | Verantwortlich |
|---|---|---|
| Autorisierung | Auftraggeber, freigegebene Ziele, Zeitraum und erlaubte Methoden | Projektleitung |
| Scope | Domains, APIs, IPs, Builds, Repositories und ausdrückliche Ausschlüsse | Technik und Pentester |
| Identitäten | mindestens zwei Konten je relevanter Ebene und zwei Mandanten, falls vorhanden | Produktteam |
| Testdaten | realistische Objekte und Zustände ohne unnötige Echtdaten | Fachteam |
| Betrieb | Monitoring-Hinweis, Stop-Kontakt, Rate Limits und Wartungsfenster | Operations |
| Evidenz | sicherer Übertragungsweg, Aufbewahrung und Löschtermin | Security |
| Abnahme | Berichtsempfänger, Severity-Modell, Nachtest und erwartete Frist | Projektleitung |
Vor dem ersten aktiven Test werden die Ziele technisch aufgelöst und mit dem Scope abgeglichen. So fällt eine falsch konfigurierte Subdomain oder fremde Cloud-IP auf, bevor daraus ein rechtliches oder betriebliches Problem wird.
Wenn AI den Testprozess unterstützt, beschreibt AI-unterstützte Pentests realistisch einordnen die Grenzen. Für den anschließenden Entwicklungsprozess hilft Security-Findings priorisieren und nachhaltig beheben.
Quellen und Vertiefung
Fazit
Eine Stunde guter Vorbereitung schafft oft mehr Testtiefe als ein zusätzlicher Tag mit fehlenden Zugängen. Klare Ziele, vollständiger Scope, realistische Rollen, verlässliche Kommunikation und ein geplanter Nachtest machen den Pentest zu einer technischen Entscheidungshilfe statt zu einer Pflichtübung.