Scope und Rules of Engagement: Das Fundament jedes Pentests

Warum Scope und RoE über Erfolg oder Desaster entscheiden

Die Grundidee ist schnell gesagt und steht im Pentest-Leitfaden: Scope ist der Gegenstand, RoE sind die Spielregeln. Interessant wird es erst in der Umsetzung. In der Praxis entscheidet die Qualität dieser beiden Dokumente darüber, ob ein Tester effizient am Wesentlichen arbeitet oder im Unklaren tappt, ob der Auftraggeber bekommt, was er braucht, und ob im Ernstfall klar ist, wer was wann tun darf.

Aus Operator-Sicht sind Scope und RoE vor allem zwei Dinge: eine Landkarte und eine Versicherung. Die Landkarte sagt, wohin die begrenzte Zeit fließt. Die Versicherung schützt beide Seiten, wenn etwas unerwartet läuft - ein Dienst wird instabil, ein Fund ist kritischer als gedacht, oder das Blue Team hält den Test für einen echten Angriff. Fehlt diese Grundlage, wird aus einem autorisierten Test im Zweifel ein Incident mit offener Haftungsfrage.

Den Scope sauber definieren

Ein guter Scope ist explizit, nicht implizit. Alles, was nicht ausdrücklich drin steht, ist im Zweifel draußen - diese Haltung schützt vor Scope-Creep und vor dem versehentlichen Testen fremder Systeme. Gleichzeitig muss der Scope vollständig genug sein, damit der Test die relevante Angriffsfläche trifft und nicht an ihr vorbei.

Was explizit festgehalten gehört

• Konkrete Ziele: Domains, Subdomains, IP-Bereiche, Hosts, Anwendungen, API-Endpunkte, Konten.
• Ausdrücklich ausgeschlossene Systeme und Adressen, inklusive Begründung, wo sie nicht offensichtlich ist.
• Die Umgebung je Ziel: Produktiv, Staging oder dedizierte Testumgebung.
• Der Umgang mit geteilter und Drittanbieter-Infrastruktur (siehe eigenen Abschnitt).
• Die Startposition des Testers: von außen, mit Konto, aus dem internen Netz (siehe Assumed Breach).

Die folgende Matrix ist eine Arbeitsvorlage. Sie wird pro Engagement ausgefüllt und ist zugleich die Referenz, gegen die der Tester im laufenden Test jede Zielwahl prüft.

Unbekannte und dynamische Assets

Der schwierigste Teil eines Scopes sind nicht die klar benannten Ziele, sondern die beweglichen: Wildcard-Domains, die während des Tests neue Subdomains ausspielen, Hosts hinter einem CDN, deren echte IP einem Dritten gehört, oder kurzlebige Cloud-Ressourcen. Drei Regeln helfen:

• Wildcards brauchen eine Verhaltensregel: Wird eine neue Subdomain im Testfenster entdeckt, gilt sie als in Scope, nur wenn sie dem Auftraggeber gehört und nicht ausgeschlossen ist. Im Zweifel: erst klären, dann testen.
• Eigentümerschaft vor Erreichbarkeit: Dass ein Host aus dem Scope heraus erreichbar ist, macht ihn nicht zum Ziel. Entscheidend ist, wem er gehört.
• Dynamisches explizit begrenzen: Cloud-Scopes über Konten oder Tags definieren, nicht über einzelne IPs, die sich ändern.

Rules of Engagement im Detail

Wenn der Scope das Was ist, sind die RoE das Wie. Sie übersetzen die Autorisierung in konkrete, im laufenden Test anwendbare Entscheidungen. Eine gute RoE beantwortet jede Frage, die ein Tester sich um drei Uhr nachts stellen könnte, ohne jemanden anrufen zu müssen - und benennt genau die Fälle, in denen er trotzdem anrufen soll.

Beispielklauseln

Formulierungen, die sich in der Praxis bewährt haben. Sie sind Muster, keine Rechtstexte, und werden an das konkrete Engagement angepasst.

Stop Conditions

Stop Conditions sind die vorab definierten Punkte, an denen der Tester anhält, statt weiterzumachen. Sie sind kein Zeichen von Schwäche, sondern das, was einen kontrollierten Test von einem unkontrollierten Angriff unterscheidet. Entscheidend ist, dass sie vor dem Test festgelegt werden, wenn niemand unter Druck steht.

Typische Stop Conditions:

• Betriebsstörung: Ein Zielsystem wird instabil oder fällt aus - unabhängig davon, ob der Test die Ursache ist.
• Verdacht auf echten Vorfall: Der Tester findet Spuren, die auf einen realen, fremden Angreifer hindeuten.
• Unerwartet kritischer Zugriff: Ein Pfad führt unerwartet schnell zu hochkritischen Daten oder Systemen (z. B. Produktivdatenbank, Sicherungssysteme).
• Scope-Verlassen: Ein Pfad würde nur über ein System außerhalb des Scopes weiterführen.
• Dritt- oder Personenbezug: Der nächste Schritt würde unbeteiligte Dritte oder nicht freigegebene personenbezogene Daten berühren.

Zu jeder Stop Condition gehört, was danach passiert: anhalten, den benannten Kontakt informieren, gemeinsam entscheiden, ob und wie weitergetestet wird, und die Entscheidung protokollieren. Ohne diesen definierten Ablauf ist eine Stop Condition nur eine gute Absicht.

Deconfliction

Deconfliction beantwortet die eine Frage, die bei jedem ernsthaften Test irgendwann auftaucht: Ist diese verdächtige Aktivität Teil des Tests oder ein echter Angriff? Je verdeckter ein Test abläuft und je weniger die Verteidigung vorgewarnt ist, desto wichtiger wird ein sauberer Deconfliction-Prozess - sonst löst der autorisierte Test eine echte Incident Response aus, mit allen Kosten und Risiken.

Die Bausteine:

• Protokollierung: Der Tester führt ein nachvollziehbares Log mit Zeitstempel, Quell-IP und Aktion. Das ist zugleich die Grundlage für die Evidenz im Bericht.
• Benannte Test-Infrastruktur: Quell-IPs, Hostnamen oder Kennungen der Testinfrastruktur sind einem eingeweihten Kreis bekannt.
• Direkter Draht: Eine feste, sofort erreichbare Verbindung zwischen Tester und einem eingeweihten Ansprechpartner (White Team bzw. Notfallkontakt).
• Vorab-Klärung des Knowledge Models: Festlegen, wer auf Verteidigungsseite eingeweiht ist - das entscheidet, ob der SOC den Test erkennen und melden soll oder nicht.

Die Gegenseite dieses Prozesses - wie ein SOC einen autorisierten Test von einem echten Angriff trennt und wann Pre-Notification oder Allowlisting sinnvoll ist - gehört in die Verteidigungsperspektive und wird auf blue-team.net vertieft. Die tiefere Betrachtung von Knowledge Models für verdeckte Operationen steht im Red-Teaming-Leitfaden.

Drittanbieter, Cloud und SaaS

Sobald ein Ziel nicht vollständig dem Auftraggeber gehört, greifen mehrere Ebenen ineinander, die sauber zu trennen sind: die Autorisierung durch den Berechtigten der getesteten Ressource, die vertraglichen Nutzungsrechte an dieser Ressource, die aktuelle Pentesting- bzw. Acceptable-Use-Policy des Providers und - nur falls Vertrag oder Policy das vorsehen - eine zusätzliche Freigabe durch den Provider. Nicht jeder Anbieter verlangt eine individuelle Vorabgenehmigung; manche erlauben Tests eigener Kundenressourcen innerhalb ihrer aktuellen Policy ohne separate Zustimmung. Diese Policies ändern sich und sind vor jedem Engagement zu prüfen.

Praktische Konsequenz: Shared- und Drittanbieter-Ziele gehören nicht automatisch in den Scope. Vor der Aufnahme werden Berechtigung, Nutzungsrechte und die aktuelle Provider-Policy geklärt - und dort, wo Vertrag oder Policy es verlangen, zusätzlich eine Betreiberfreigabe eingeholt. Im Zweifel gilt: erst klären, dann testen.

Pre-Engagement-Fragebogen

Ein guter Scope entsteht nicht am Verhandlungstisch aus dem Bauch heraus, sondern aus den richtigen Fragen. Der folgende Fragebogen deckt die Blöcke ab, die vor jedem Engagement geklärt sein müssen. Er dient zugleich als Protokoll: Die Antworten fließen direkt in Scope und RoE.

Assumed Breach und Knowledge-Entscheidungen

Eine zentrale Scope-Entscheidung wird oft unterschätzt: Von welcher Ausgangslage startet der Test? Die Perspektiven Black, Grey und White Box beschreiben, wie viel der Tester weiß, und sind im Leitfaden grundlegend erklärt. Hier geht es um die praktische Entscheidung, welche Ausgangslage welches Ziel am besten mit dem verfügbaren Budget erreicht.

Die pragmatische Wahl ist oft Assumed Breach, gerade bei internen und Active-Directory-Tests. Assumed Breach unterstellt einen bereits erfolgten Initial Access, damit die verfügbare Testzeit gezielt auf Post-Compromise-Verhalten, Privilege Escalation, Credential Access und Lateral Movement verwendet werden kann, statt einen großen Teil des Budgets an der Perimeterphase zu binden. Wer dagegen die Erkennung der Perimeterphase oder die Außenwirkung testen will, wählt bewusst Black Box. Wie viel die Verteidigung über den Test weiß, ist davon unabhängig und wird separat als Knowledge Model festgelegt.

Entscheidungsbaum: Ist diese Technik im Scope erlaubt?

Im laufenden Test stellt sich immer wieder dieselbe Frage: Darf ich diesen nächsten Schritt gehen? Der folgende Entscheidungsbaum fasst die Prüfung zusammen, die ein Operator dabei durchläuft - von oben nach unten, beim ersten Nein oder kritischen Ja wird angehalten.

Typische Fehler

• Vager Scope: Unklare Grenzen führen entweder zu Lücken oder zu Scope-Creep in fremde Systeme.
• Autorisierung nicht schriftlich dokumentiert: Für professionelle Pentests sollte die Autorisierung vor Testbeginn schriftlich festgehalten werden - das schafft einen belastbaren Nachweis über Berechtigung, Scope, Methoden und Rahmen und schützt beide Seiten bei späteren Unklarheiten.
• Autorisierung vom Nicht-Berechtigten: Die Freigabe muss vom tatsächlich Berechtigten stammen, nicht von einem gutwilligen Ansprechpartner ohne Mandat.
• Cloud oder SaaS als selbstverständlich im Scope angenommen: Fremdgehostete Ziele brauchen die Freigabe des Betreibers.
• Keine Stop Conditions: Im Ernstfall fehlt die vorab getroffene Entscheidung, wann angehalten wird.
• Keine erreichbaren Notfallkontakte: Ein Notfallkontakt, der nachts nicht rangeht, ist keiner.
• Keine Deconfliction: Ohne Abgleich hält der SOC den Test für einen echten Angriff und löst eine Incident Response aus.
• Produktivtest ohne Fenster und Abstimmung: Laute oder riskante Tests zur Hauptlast stören den Betrieb und beschädigen das Vertrauen.
• Eigene Aktionen nicht protokolliert: Ohne Log fehlt später die Evidenz für den Bericht und die Grundlage für Deconfliction.

Vom Dokument in die Durchführung

Scope und RoE sind kein abgeschlossener Vorgang, sondern die Referenz für den gesamten Test. Jede Zielwahl wird gegen den Scope geprüft, jede Technik gegen die RoE, und jede Aktion wird so protokolliert, dass sie später im Bericht nachweisbar und scope-konform ist. Damit sind Scope und RoE zugleich die Grundlage für sauberes Reporting und für die Risikobewertung der Funde.

Wie der Ablauf danach weitergeht, beschreibt der Phasenteil des Leitfadens. Die zielspezifischen Besonderheiten vertiefen die Fachartikel zu Web-, API-, Netzwerk-, Cloud- und Active-Directory-Pentesting im Pentest-Bereich.

Häufige Fragen

Sollte die Freigabe schriftlich vorliegen?

Für professionelle Pentests ja: Die Autorisierung sollte vor Testbeginn schriftlich dokumentiert werden und Berechtigung, Scope, Methoden und Rahmenbedingungen eindeutig festhalten. Das schafft einen belastbaren Nachweis und schützt beide Seiten bei späteren Unklarheiten. Eine rein mündliche Absprache lässt sich im Streitfall dagegen nur schwer belegen.

Wer darf einen Test autorisieren?

Der tatsächlich Berechtigte über die Zielsysteme. Bei Cloud- und Drittanbieter-Infrastruktur kommen deren Freigaben hinzu. Ein kooperativer Ansprechpartner ohne entsprechendes Mandat genügt nicht.

Was tun, wenn im Test ein echter Angreifer vermutet wird?

Das ist eine klassische Stop Condition: anhalten, den Notfallkontakt informieren und über Deconfliction klären, ob die Spur vom Test stammt. Bestätigt sich ein echter Vorfall, übernimmt die Incident Response.

Gehört die Cloud automatisch zum Scope?

Nein. Cloud- und SaaS-Ziele gehören nur mit ausdrücklicher Freigabe dazu, und zusätzlich gelten die Pentesting-Richtlinien des jeweiligen Anbieters, die vorab zu prüfen sind.