Pentest-Scoping-Checkliste: Was du vor dem Test klären musst

Ein Penetrationstest ist nur so gut wie sein Scope. Jeder enttäuschende Test, von dem wir gehört haben, der Bericht, der nichts fand, weil das interessante System ausgenommen war, der Test, der am zweiten Tag wegen eines fehlenden Accounts stand, das Finding, das niemand in der Produktion nachstellen konnte, geht auf ein Scoping-Gespräch zurück, in dem eine Frage nicht gestellt wurde. Diese Checkliste ist die Liste dieser Fragen.

Geh sie vor dem Scoping-Gespräch durch und bring die Antworten mit. Ein halber Tag Vorbereitung bei dir ist einen Testtag wert.

1. Zielsysteme: Was genau getestet wird

• Nenne jedes Ziel beim Namen: URLs, Hostnamen, IP-Bereiche, App-Store-IDs, Cloud-Account-IDs, Gerätemodell und Firmware-Version, Steuergerätevariante und Softwarestand, Anlagensegment.
• Zieh die Grenze. Was ist drin, was ist draußen, und was ist grau: Komponenten Dritter, geteilte Dienste, der Identity Provider, der Zahlungsdienstleister.
• Zähle, was den Aufwand treibt: Nutzerrollen, Seiten oder Endpunkte, Integrationen, Schnittstellen an einem Gerät, Diagnosedienste an einem Steuergerät, Netzsegmente in einer Anlage. Diese Zahlen bestimmen Tage und Preis.
• Sag, was am wichtigsten ist. Die Kundendaten? Die Firmware-Signatur? Die Sicherheitsfunktion? Tester priorisieren nach dem, was du ihnen sagst.

2. Umgebung: Wo getestet wird

• Produktion, Staging oder eine eigene Testumgebung? Staging nur, wenn es der Produktion in Konfiguration, Integrationen und Datenstruktur entspricht.
• Bei Hardware, IoT und Steuergeräten: Wie viele Geräte, und dürfen sie kaputtgehen? Debug-Zugang, Firmware-Images, Schaltpläne und ein Labornetzteil oder ein Testaufbau beschleunigen alles.
• Bei OT: ein Prüfstand, eine Ersatzsteuerung oder ein Zwillingsaufbau. Aktive Tests an einer laufenden Anlage brauchen ein Wartungsfenster und eine Freigabe der Sicherheitsverantwortlichen; siehe OT-Pentest ohne Stillstand.
• Bei Cloud: welche Accounts oder Subscriptions, welche Leserolle für die Tester, und wessen Zustimmung die Testrichtlinie des Anbieters verlangt.

3. Zugang und Testtiefe

Ansatz	Die Tester bekommen	Richtig, wenn
Black Box	Nichts außer dem Namen des Ziels	Du wissen willst, was ein Außenstehender schafft; länger für dieselbe Abdeckung
Grey Box	Accounts pro Rolle, Architekturüberblick, API-Spezifikation	Die meisten Tests; die meisten Findings pro Tag
White Box	Quellcode, Konfiguration, Build-Artefakte, Firmware	Produkte vor dem Release, sicherheitskritischer Code, Compliance-Nachweise

Was auch immer du wählst: zwei Accounts pro Rolle, damit die Autorisierung zwischen Nutzern getestet werden kann. Die Accounts müssen am ersten Morgen funktionieren, mit eingerichteter MFA und Testzahlungsmitteln, wo nötig.

4. Spielregeln

• Zeitfenster: Termine, Arbeitszeiten, Zeitzone, und ob Tests nachts oder am Wochenende erlaubt oder gewünscht sind.
• Ausnahmen: Denial of Service, Social Engineering, physischer Zugang, destruktive Tests, bestimmte Hosts. Schreib sie auf.
• Empfindliche Systeme: alles, was vorsichtig behandelt werden muss, alte Appliances, eine SPS, die bei einem Portscan neu startet, eine ratenbegrenzte API eines Dritten.
• Abbruchbedingungen: Was die Tester tun, wenn sie Daten echter Kunden, Spuren eines früheren Einbruchs oder ein kritisches Finding entdecken. Üblich: anhalten, anrufen, dokumentieren.
• Ansprechpersonen: eine technische Ansprechperson bei dir, die innerhalb von Stunden antwortet, eine Eskalationsperson, eine auf Seiten der Tester, jeweils mit Telefonnummer.
• Monitoring: Weiß dein SOC Bescheid? Entscheide, ob der Test auch eine Erkennungsübung ist oder ob das Blue Team vorab informiert wird.

5. Rechtliche Freigabe

• Eine schriftliche Freigabe, unterschrieben vom Systemeigentümer, mit Zielen, Zeitraum und Testern. In Deutschland fallen Sicherheitstests ohne Erlaubnis unter § 202a bis § 202c StGB; die unterschriebene Erlaubnis macht den Test legal. Zyberum beginnt nicht ohne sie.
• Dritte: Hoster, SaaS-Anbieter und Outsourcing-Partner, deren Systeme berührt werden, müssen schriftlich zustimmen. Cloud-Anbieter haben Richtlinien für Tests der eigenen Ressourcen veröffentlicht; lies sie.
• Datenschutz: Können personenbezogene Daten sichtbar werden, dann vereinbare, wie damit umgegangen wird, wo Nachweise gespeichert werden und wann sie gelöscht werden. Eine NDA ist Standard.
• Bei Produkten: Kläre, ob du Komponenten von Zulieferern testen lassen darfst, oder nimm sie aus.

6. Ergebnisse

• Berichtsstruktur: Management-Zusammenfassung, Scope und Methode, Findings mit Reproduktion und Empfehlungen, CVSS und Schweregrad im Kontext, Angriffsketten. Siehe Pentest-Bericht lesen.
• Formatwünsche: eine Zuordnung zu einem Standard oder einer Regulierung (OWASP ASVS, IEC 62443-4-2, Arbeitsprodukte nach ISO/SAE 21434, CRA Anhang I), eine geschwärzte Version für Kunden, ein Bestätigungsschreiben nach dem Nachtest.
• Ergebnispräsentation: eine Stunde mit Entwicklern und Geschäftsleitung, meist eine Woche nach dem Bericht.
• Nachtest: enthalten oder nicht, wie viele Runden, bis wann. Mach ihn zum Teil des Angebots.
• Sprache: Deutsch, Englisch oder beides.

7. Die Fragen, die dir Tester stellen werden

Rechne im Gespräch mit diesen Fragen; mit Antworten wird das Angebot präzise:

1. Warum jetzt? Eine Kundenanforderung, eine Regulierung, ein Launch, ein Vorfall, Routine?
2. Wurde das schon einmal getestet, und dürfen wir den letzten Bericht sehen?
3. Was hat sich seitdem geändert?
4. Wer behebt die Findings, und wann hat diese Person Zeit?
5. Was wäre das Schlimmste, das ein Angreifer mit diesem System anstellen könnte?

Typische Scoping-Fehler

• Den interessanten Teil ausnehmen, weil ihn “ein Partner betreibt”. Dem Angreifer ist egal, wer ihn betreibt.
• Zuerst nach Budget scopen. Entscheide, was getestet werden muss, und dann, was du ausdrücklich verschiebst.
• Kein Nachtest. Ein Bericht voller offener Findings ist nicht das, was dein Auditor sehen will.
• Accounts am dritten Tag. Die häufigste Ursache für verlorene Testtage.
• Ein Staging-System testen, das niemand pflegt, und dann darüber streiten, ob die Produktion denselben Fehler hat.

Nach dem Scoping

Du bekommst ein Festpreisangebot, in dem Ziele, Tage, Termine, Ausnahmen und Ergebnisse stehen. Dieses Dokument plus die unterschriebene Freigabe ist der Scope. Stellt sich das Ziel während des Tests als größer heraus, sagt dir ein guter Anbieter das am ersten Tag und lässt dich wählen: erweitern, eingrenzen oder die geringere Abdeckung akzeptieren, dokumentiert im Bericht. Buch ein kostenloses Scoping-Gespräch und bring diese Liste mit.