Pentest-Auftragsumfang: Ein Leitfaden fur Profis

Der Umfang eines Pentest-Auftrags ist eines der am haufigsten unterschatzten Elemente des gesamten Penetrationstestprozesses. Die meisten Pentester wissen, was Penetrationstests im Allgemeinen sind, behandeln den Scope jedoch als einfache Liste von IP-Adressen zum Scannen. Das ist ein Fehler, der Projekte Zeit, Geld und Glaubwurdigkeit kostet. Der Auftragsumfang ist eine formale Aufzeichnung der Testgrenzen, die Assets, Techniken und Testdauer definiert. Ohne einen prazisen Umfang arbeitet selbst der beste Pentester im Vakuum und der Kunde erhalt einen Bericht, der seinen tatsachlichen Bedurfnissen nicht entspricht.

Inhaltsverzeichnis

• Bestandteile des Pentest-Auftragsumfangs

• Wie das Black/Grey/White-Box-Modell den Umfang und Ablauf von Penetrationstests beeinflusst

• Die Rolle der prazisen Umfangsdefinition fur die Rechtssicherheit und Ergebnisqualitat

• Praktische Richtlinien und Beispiele fur das Scoping von Webanwendungs- und API-Pentests

• Kosten und Ressourcen je nach Pentest-Auftragsumfang

• Warum prazise Umfangsdefinition die grosste Herausforderung und der Schlussel zum Pentest-Erfolg ist

• Pentest-Werkzeuge und -Ausrustung zur Unterstutzung der Auftragsumfang-Umsetzung

• Haufig gestellte Fragen

Wichtigste Erkenntnisse

Bestandteile des Pentest-Auftragsumfangs

Von der allgemeinen Einfuhrung ausgehend besprechen wir im Detail die Schlusselelemente des Auftragsumfangs. Der Pentest-Auftragsumfang ist nicht einheitlich. Er besteht aus drei verschiedenen Dimensionen, von denen jede unterschiedliche Testgrenzen definiert und eine separate Vereinbarung mit dem Kunden erfordert.

Der Auftragsumfang gliedert sich in Target-Scope, Technik-Scope und zeitlichen Scope. Diese Dreiteilung eignet sich als Vorlage fur jedes Kickoff-Meeting mit dem Kunden. Aus unserer Erfahrung als Anbieter von Pentest-Ausrustung wissen wir, dass Kunden am haufigsten dann nach zusatzlichen Werkzeugen zuruckkehren, wenn sich der Auftragsumfang wahrend des Projekts andert - eine prazise Scope-Definition zu Beginn spart Zeit und Budget.

Target-Scope legt fest, welche Systeme, Netzwerke und Anwendungen getestet werden. Er umfasst:

• Konkrete IP-Adressen, CIDR-Bereiche oder Domainnamen

• Webanwendungen, identifiziert durch URL oder Umgebung (Produktion, Staging)

• Ausschlusse, also Systeme, die der Tester nicht beruhren darf, z.B. Produktionssysteme von Drittanbietern

• Netzwerkgerate: Router, Firewalls, Switches

• Cloud-Infrastruktur mit Angabe von Konten und Regionen

Technik-Scope definiert, welche Angriffsmethoden erlaubt sind. Dies ist einer der Bereiche, in denen am haufigsten Missverstandnisse auftreten. Der Kunde erwartet moglicherweise einen vollstandigen Test, verbietet aber die Ausnutzung von Schwachstellen aus Angst vor Systemausfallen. Der Technik-Scope umfasst Entscheidungen bezuglich:

• Schwachstellenausnutzung (mit oder ohne Payload)

• Denial-of-Service-Angriffe (DoS), die in Produktionsumgebungen normalerweise verboten sind

• Social Engineering, Phishing und Pretexting

• Physische Angriffe auf die Infrastruktur

• Methoden zur Rechteausweitung und Lateral Movement

Zeitlicher Scope ist das Fenster, in dem Tests stattfinden konnen. Er definiert die Stunden und Tage zulassiger Testaktivitaten. Er enthalt auch Blackouts - Zeitraume, in denen Tests verboten sind, z.B. wahrend des Jahresabschlusses oder Systemupdates. Das Weglassen dieses Elements fuhrt zu Situationen, in denen der Tester freitagabends um 23:00 Uhr einen Scanner startet und das Monitoring des Kunden einen Alarm auslost, den niemand zu bearbeiten erwartet.

Es lohnt sich, Penetrationstest-Methodologien kennenzulernen, die prazisieren, wie diese drei Dimensionen in verschiedenen Branchen-Frameworks formalisiert werden.

Wie das Black/Grey/White-Box-Modell den Umfang und Ablauf von Penetrationstests beeinflusst

Mit Kenntnis der Scope-Elemente analysieren wir, wie verschiedene Testmodelle die Scope-Definition und -Umsetzung beeinflussen. Die Modellwahl ist nicht nur eine methodische Frage. Sie bestimmt direkt, was gepruft werden kann, wie tief und zu welchen Kosten.

Das Black/Grey/White-Box-Modell bestimmt das Wissensniveau und den Zugang des Testers, was wiederum beeinflusst, wie detailliert der Auftragsumfang in der Dokumentation formuliert werden muss.

Einige praktische Beobachtungen zu jedem Modell:

• Black Box erfordert einen umfangreichen Target-Scope, da der Tester die Infrastruktur selbststandig kartieren muss. Der Technik-Scope ist hier normalerweise breiter, aber auf externe Aktionen beschrankt.

• Grey Box ist das am haufigsten gewahlte Modell bei kommerziellen Sicherheitstestdiensten. Der Scope umfasst vom Kunden bereitgestellte Zugangsdaten und mogliche Netzwerkdiagramme.

• White Box verlagert den Schwerpunkt des Scopings auf die technische Dokumentation. Der Tester benotigt Zugriff auf Code-Repositories, Architekturdiagramme und Systemkonfigurationen. Der Scope muss angeben, welche Repositories und Umgebungen vom Test abgedeckt werden.

Eine detaillierte Ubersicht uber Ausrustung zur Unterstutzung verschiedener Black/Grey/White-Box-Modelle finden Sie in einem speziellen Artikel.

Die Rolle der prazisen Umfangsdefinition fur die Rechtssicherheit und Ergebnisqualitat

Nach der Besprechung der Testmodelle konzentrieren wir uns auf die rechtlichen und qualitativen Konsequenzen, die sich aus dem Umfang ergeben. Dies ist ein Bereich, den viele Pentester als Formalitat betrachten. Das ist er nicht.

Das Fehlen einer schriftlichen Zustimmung und Prazision setzt sowohl das testende Unternehmen als auch den Tester selbst rechtlicher Haftung aus. In Polen konnen Tests ohne Autorisierung als Verstoss gegen das Cybersicherheitsgesetz oder das Strafgesetzbuch im Bereich des unbefugten Zugriffs auf Informationssysteme eingestuft werden.

Zwei Schlusseldokumente zur Formalisierung des Umfangs sind SOW (Statement of Work) und ROE (Rules of Engagement). Der Unterschied zwischen ihnen ist grundlegend und wird oft ubersehen:

• SOW definiert, was getestet wird. Es enthalt die Liste der Systeme, Anwendungen, Umgebungen und Ausschlusse.

• ROE legt fest, wie der Test ablaufen soll. Es regelt erlaubte Techniken, Testzeiten, Eskalationsregeln und Abbruchbedingungen.

Die Trennung dieser Dokumente hat praktische Bedeutung. Das SOW wird vom Anwalt oder Projektmanager auf Kundenseite unterzeichnet. Das ROE wird von der technisch verantwortlichen Person unterzeichnet, z.B. dem CTO oder Security Manager. Eine Unterschrift unter dem falschen Dokument durch die falsche Person bietet nicht die erforderliche Autorisierung.

Profi-Tipp: Uberprufen Sie immer, ob die Person, die das ROE unterzeichnet, tatsachlich befugt ist, die Zustimmung zu Tests zu erteilen. Die Unterschrift eines IT-Mitarbeiters ohne entsprechende Vollmacht schutzt Sie im Falle eines Vorfalls nicht rechtlich.

Schritte zur ordnungsgemassen Festlegung des Umfangs:

1. Definieren Sie die vom Test abgedeckten Systeme und erstellen Sie eine Ausschlussliste

2. Legen Sie erlaubte Methoden und Techniken fest, notieren Sie Verbote

3. Bestimmen Sie das Zeitfenster und planen Sie Blackouts

4. Definieren Sie Abbruchbedingungen und Eskalationsverfahren

5. Genehmigen Sie die Dokumentation mit Unterschriften befugter Personen auf beiden Seiten

Eine vollstandige Analyse der formalen Anforderungen finden Sie im Artikel uber Penetrationstest-Methodik und -Regeln.

Praktische Richtlinien und Beispiele fur das Scoping von Webanwendungs- und API-Pentests

Unter Berucksichtigung der allgemeinen Regeln und Risiken wenden wir uns den praktischen Aspekten der Umfangsdefinition bei Webanwendungstests zu. Diese Art von Tests hat ihre eigenen Besonderheiten, die einen sehr prazisen Ansatz beim Scoping erfordern.

Der Umfang eines Web/API-Tests wird auf Ebene von URLs, Endpunkten und Zugriffsrollen definiert. Eine prazise Festlegung des Authentifizierungstest-Umfangs ist unerlasslich.

In der Praxis sollte der Umfang eines Webanwendungstests Folgendes enthalten:

• Liste der URLs und API-Endpunkte: Die Angabe der Domain allein reicht nicht aus. Es muss spezifiziert werden, ob alle Subdomains, bestimmte Pfade, versionierte APIs (v1, v2) und Umgebungen (Produktion vs. Staging) getestet werden.

• Zu berucksichtigende Zugriffsrollen: Anonymer Benutzer, registrierter Benutzer, Moderator, Administrator. Jede Rolle offnet einen anderen Satz von Funktionalitaten und potenziellen Schwachstellen.

• Testdatenumfang: Welche Testkonten der Kunde bereitstellt, welche Daten wahrend des Tests erstellt und geandert werden konnen.

• Umgebungsbeschrankungen: Ob Tests Produktionsdatenbanken beruhren durfen oder ob der Tester ausschliesslich auf der Staging-Umgebung arbeitet.

• Spezifische zu untersuchende Bedrohungen: Der Kunde kann OWASP Top 10, Geschaftslogik oder kontoübergreifende Autorisierung priorisieren.

Ungenaue Definition der Zugriffsrollen ist einer der haufigsten Fehler. Der Tester testet ausschliesslich als anonymer Benutzer, wahrend die schwerwiegendsten Schwachstellen im Admin-Panel liegen. Der Abschlussbericht deckt die Bereiche nicht ab, die dem Kunden am wichtigsten sind, und der Auftrag gilt als gescheitert. In Gesprachen mit Pentestern, die bei uns Ausrustung kaufen, wiederholt sich dieses Szenario regelmiissig - der Kunde erwartete einen Admin-Panel-Test, aber niemand hat das im Scope dokumentiert.

Profi-Tipp: Nehmen Sie alle wichtigen Authentifizierungs- und Autorisierungspfade in den Scope auf, einschliesslich Passwort-Reset-Prozesse, OAuth, SSO und API Keys. Diese Pfade sind der am haufigsten ubersehene Angriffsvektor.

Weitere technische Aspekte des Web-Test-Scopings finden Sie im Leitfaden zum Umfang von Webanwendungs- und API-Pentests.

Kosten und Ressourcen je nach Pentest-Auftragsumfang

Zum Schluss betrachten wir die pragmatischen Aspekte der Testumsetzung. Der Umfang schlagt sich direkt im Budget und Projektzeitplan nieder, und das Verstandnis dieses Zusammenhangs hilft, Missverstandnisse bei der Preisgestaltung zu vermeiden.

Je grosser und komplexer der Umfang, desto hoher die Kosten und langer die Testumsetzungszeit. Das scheint offensichtlich, aber die Details sind weniger intuitiv als Sie denken.

Einige Faktoren, die Ressourcen und Kosten weniger offensichtlich beeinflussen:

• Scope-Ausschlusse: Paradoxerweise konnen viele Ausschlusse den Test verlangern, da der Tester standig uberprufen muss, welche Systeme er angreifen darf und welche nicht.

• Umgebungsverfugbarkeit: Tests auf Staging statt Produktion erfordern zusatzliche Konfiguration und oft separate Testdaten.

• Berichterstattung: Ein detaillierter Bericht mit Re-Tests und Debrief-Sitzungen kann 20 bis 30 Prozent zur gesamten Ausfuhrungszeit des Auftrags hinzufugen.

• Zugang zu spezialisierten Werkzeugen: Bestimmte Testvektoren erfordern dedizierte Ausrustung, was die Kosten auf Seiten des testenden Unternehmens beeinflusst.

Mehr uber die Planung von Pentest-Zeit und -Ressourcen finden Sie in unseren Materialien fur Spezialisten.

Warum prazise Umfangsdefinition die grosste Herausforderung und der Schlussel zum Pentest-Erfolg ist

Nach der Besprechung aller praktischen Aspekte ist es Zeit fur eine Expertenperspektive. Der Auftragsumfang ist ein Thema, bei dem der Markt seit Jahren dieselben Fehler macht und niemand offen daruber spricht.

Die haufigste Ursache fur die Diskrepanz zwischen Test und Kundenerwartungen ist fehlerhaftes Scoping und ein schlecht definiertes ROE. Aber das Problem liegt normalerweise nicht in technischer Nachlassigkeit - es liegt im Kommunikationsprozess.

Kunden beschreiben den Umfang in Geschaftssprache. Sie sagen "testen Sie unsere Systeme" oder "prufen Sie, ob wir sicher sind". Pentester mussen dies in eine Liste von Hosts, Endpunkten und erlaubten Techniken ubersetzen. Diese Ubersetzung ist der Punkt, an dem Informationen am haufigsten verloren gehen. Wir beobachten dies in der Branche seit Jahren - Pentester, die bei uns Ausrustung fur physische Tests bestellen, erfahren oft erst nach Beginn des Auftrags, dass der Kunde den physischen Zugang zum Serverraum nicht im Scope berucksichtigt hat, obwohl er einen "vollstandigen Sicherheitstest" erwartet hatte.

Das zweite haufig ubersehene Thema sind Abbruchbedingungen (Stop Conditions). Das ROE sollte spezifizieren, was der Tester tut, wenn er eine kritische Schwachstelle entdeckt, z.B. eine Remote-Exploitation ohne Authentifizierung auf einem Produktionssystem. Macht er weiter oder berichtet er sofort dem Kunden und wartet auf eine Entscheidung? Das Fehlen dieser Regeln fuhrt zu Situationen, in denen der Tester entweder zu fruh stoppt oder eine Schwachstelle auf eine Weise ausnutzt, die der Kunde als Grensuberschreitung betrachtet.

Ein weiterer Fehler ist das Fehlen von Geschafts-Stakeholdern im Prozess der Umfangsdefinition. Techniker konzentrieren sich normalerweise auf die Infrastruktur. Dabei weiss der Risikomanager oder Betriebsdirektor, welche Geschaftsprozesse kritisch sind und Priorisierung erfordern. Ein ausschliesslich von der IT definierter Umfang kann die Anwendung ubersehen, die 80 Prozent des Unternehmensumsatzes abwickelt, weil "es ein altes System ist und jeder es kennt".

Profi-Tipp: Beziehen Sie Geschafts-Stakeholder in die Scoping-Sitzung ein. Ein Treffen mit der fur Geschaftsprozesse verantwortlichen Person kann Assets aufdecken, die die IT-Abteilung nicht erwahnt hat, weil sie sie nicht als "IT" betrachtete.

Effektive Standardisierung von Scope und ROE erfordert Vorlagen, Prozesse und organisatorische Disziplin. Unternehmen, die Scoping als einmaliges Telefongesprach behandeln, liefern regelmiissig Tests, die der Kunde als nutzlos bewertet.

Pentest-Werkzeuge und -Ausrustung zur Unterstutzung der Auftragsumfang-Umsetzung

Mit Kenntnis der Herausforderungen und Best Practices lohnt es sich, die Werkzeuge kennenzulernen, die Pentester bei der Umsetzung eines prazisen Auftragsumfangs unterstutzen. Die richtige Ausrustung ermoglicht schnelleres, genaueres Arbeiten in voller Ubereinstimmung mit dem festgelegten Scope.

Im Sapsan-Katalog finden Sie Ausrustung fur spezifische Testvektoren, die vom Auftragsumfang abgedeckt werden. Bash Bunny Hak5 ist ein vielseitiges Gerat zur Automatisierung von HID-Angriffen und Netzwerktests, besonders nutzlich bei Auftragen mit physischem Zugang oder Endpunkten. Packet Squirrel Mark II bewahrt sich bei internen Tests und Pivoting im Kundennetzwerk, wo der Scope die LAN-Infrastruktur umfasst. Fur Auftrage mit Fokus auf Webanwendungen und APIs stehen Werkzeuge fur Webanwendungs-Pentests zur Verfugung, die den vollen Umfang OWASP-konformer Tests abdecken. Sapsan liefert in die gesamte EU und die USA und gewahrleistet schnellen Zugang zu Ausrustung unabhangig vom Projektstandort.

Haufig gestellte Fragen

Was ist ein Pentest-Auftragsumfang?

Der Auftragsumfang ist eine formale Aufzeichnung der Testgrenzen, erlaubten Techniken und Ausfuhrungszeit. Er definiert, welche Systeme getestet werden, welche Angriffsmethoden erlaubt sind und in welchem Zeitfenster Tests stattfinden konnen.

Warum ist eine prazise Umfangsdefinition so wichtig?

Ein ungenauer Umfang fuhrt zu nicht ubereinstimmenden Erwartungen und rechtlichem Risiko. Prazise Festlegung der Testgrenzen verhindert rechtliche Vorfalle und garantiert, dass der Abschlussbericht den tatsachlichen Bedurfnissen des Kunden entspricht.

Welche Testmodelle beeinflussen den Pentest-Umfang?

Black/Grey/White-Box-Modelle definieren die Zugriffsebene des Testers und beeinflussen den Testumfang. Black Box simuliert einen Angreifer ohne Infrastrukturkenntnis, Grey Box setzt teilweisen Zugang voraus, und White Box bietet vollen Einblick in Architektur und Code.

Was sollte die Umfangsdefinition von Webanwendungstests enthalten?

Der Umfang eines Web/API-Tests wird auf Ebene von Endpunkten und Zugriffsrollen definiert. Ein praziser Scope umfasst konkrete URLs, API-Versionen, Testumgebungen und alle Benutzerrollen vom anonymen Benutzer bis zum Administrator.

Wie beeinflusst die Umfangsgrosse Kosten und Zeit von Penetrationstests?

Der Umfang schlagt sich direkt in Zeit und Kosten nieder: Externe Tests dauern typischerweise 3 bis 7 Tage, wahrend umfangreiche Red-Team-Auftrage mehrere Wochen in Anspruch nehmen konnen. Je mehr Systeme, Rollen und Techniken der Scope abdeckt, desto grosser der Bedarf an Ressourcen und Budget.