Pentest-Auftragsumfang: Ein Leitfaden für Profis

Der Umfang eines Pentest-Auftrags ist eines der am häufigsten unterschätzten 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 Glaubwürdigkeit kostet. Der Auftragsumfang ist eine formale Aufzeichnung der Testgrenzen, die Assets, Techniken und Testdauer definiert. Ohne einen präzisen Umfang arbeitet selbst der beste Pentester im Vakuum und der Kunde erhält einen Bericht, der seinen tatsächlichen Bedürfnissen nicht entspricht.

Inhaltsverzeichnis

• Bestandteile des Pentest-Auftragsumfangs

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

• Die Rolle der präzisen Umfangsdefinition für die Rechtssicherheit und Ergebnisqualität

• Praktische Richtlinien und Beispiele für das Scoping von Webanwendungs- und API-Pentests

• Kosten und Ressourcen je nach Pentest-Auftragsumfang

• Warum eine präzise Umfangsdefinition die größte Herausforderung und der Schlüssel zum Pentest-Erfolg ist

• Pentest-Werkzeuge und -Ausrüstung zur Unterstützung bei der Umsetzung des Auftragsumfangs

• Häufig gestellte Fragen

Wichtigste Erkenntnisse

Bestandteile des Pentest-Auftragsumfangs

Ausgehend von der allgemeinen Einführung besprechen wir im Detail die Schlüsselelemente des Auftragsumfangs. Der Pentest-Auftragsumfang ist mehrdimensional. 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 für jedes Kickoff-Meeting mit dem Kunden. Aus unserer Erfahrung als Anbieter von Pentest-Ausrüstung wissen wir, dass Kunden am häufigsten dann nach zusätzlichen Werkzeugen zurückkehren, wenn sich der Auftragsumfang während des Projekts ändert - eine präzise 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)

• Ausschlüsse, also Systeme, die der Tester nicht berühren darf, z.B. Produktionssysteme von Drittanbietern

• Netzwerkgeräte: 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 häufigsten Missverständnisse auftreten. Der Kunde erwartet möglicherweise einen vollständigen Test, verbietet aber die Ausnutzung von Schwachstellen aus Angst vor Systemausfällen. Der Technik-Scope umfasst Entscheidungen bezüglich:

• 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 können. Er definiert die Stunden und Tage zulässiger Testaktivitäten. Er enthält auch Blackouts - Zeiträume, in denen Tests verboten sind, z.B. während des Jahresabschlusses oder Systemupdates. Das Weglassen dieses Elements führt zu Situationen, in denen der Tester freitagabends um 23:00 Uhr einen Scanner startet und das Monitoring des Kunden einen Alarm auslöst, den niemand zu bearbeiten erwartet.

Es lohnt sich, Penetrationstest-Methodologien kennenzulernen, die präzisieren, 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 geprüft 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 selbstständig kartieren muss. Der Technik-Scope ist hier normalerweise breiter, aber auf externe Aktionen beschränkt.

• Grey Box ist das am häufigsten gewählte Modell bei kommerziellen Sicherheitstestdiensten. Der Scope umfasst vom Kunden bereitgestellte Zugangsdaten und mögliche Netzwerkdiagramme.

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

Eine detaillierte Übersicht über Ausrüstung zur Unterstützung verschiedener Black/Grey/White-Box-Modelle finden Sie in einem speziellen Artikel.

Die Rolle der präzisen Umfangsdefinition für die Rechtssicherheit und Ergebnisqualität

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 Formalität betrachten. Das ist er nicht.

Das Fehlen einer schriftlichen Zustimmung und einer präzisen Definition setzt sowohl das testende Unternehmen als auch den Tester selbst einem erheblichen rechtlichen Haftungsrisiko aus. In Polen können Tests ohne Autorisierung als Verstoß gegen das Cybersicherheitsgesetz oder das Strafgesetzbuch im Bereich des unbefugten Zugriffs auf Informationssysteme eingestuft werden.

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

• SOW definiert, was getestet wird. Es enthält die Liste der Systeme, Anwendungen, Umgebungen und Ausschlüsse.

• 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: Überprüfen Sie immer, ob die Person, die das ROE unterzeichnet, tatsächlich befugt ist, die Zustimmung zu Tests zu erteilen. Die Unterschrift eines IT-Mitarbeiters ohne entsprechende Vollmacht schützt Sie im Falle eines Vorfalls nicht rechtlich.

Schritte zur ordnungsgemäßen 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. Lassen Sie die Dokumentation von befugten Personen auf beiden Seiten unterzeichnen

Eine vollständige Analyse der formalen Anforderungen finden Sie im Artikel über Penetrationstest-Methodik und -Regeln.

Praktische Richtlinien und Beispiele für das Scoping von Webanwendungs- und API-Pentests

Unter Berücksichtigung 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 präzisen Ansatz beim Scoping erfordern.

Der Umfang eines Web/API-Tests wird auf Ebene von URLs, Endpunkten und Zugriffsrollen definiert. Eine präzise Festlegung des Authentifizierungstest-Umfangs ist unerlässlich.

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 berücksichtigende Zugriffsrollen: Anonymer Benutzer, registrierter Benutzer, Moderator, Administrator. Jede Rolle öffnet einen anderen Satz von Funktionalitäten und potenziellen Schwachstellen.

• Testdatenumfang: Welche Testkonten der Kunde bereitstellt, welche Daten während des Tests erstellt und geändert werden können.

• Umgebungsbeschränkungen: Ob Tests Produktionsdatenbanken berühren dürfen oder ob der Tester ausschließlich auf der Staging-Umgebung arbeitet.

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

Eine ungenaue Definition der Zugriffsrollen ist einer der häufigsten Fehler. Der Tester testet ausschließlich als anonymer Benutzer, während 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 Gesprächen mit Pentestern, die bei uns Ausrüstung kaufen, wiederholt sich dieses Szenario regelmäßig - 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, einschließlich Passwort-Reset-Prozesse, OAuth, SSO und API Keys. Diese Pfade sind der am häufigsten übersehene 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 schlägt sich direkt im Budget und Projektzeitplan nieder, und das Verständnis dieses Zusammenhangs hilft, Missverständnisse bei der Preisgestaltung zu vermeiden.

Je größer und komplexer der Umfang, desto höher sind die Kosten und desto länger dauert die Testumsetzung. Das scheint offensichtlich, aber die Details sind weniger intuitiv als Sie denken.

Einige Faktoren, die Ressourcen und Kosten weniger offensichtlich beeinflussen:

• Scope-Ausschlüsse: Paradoxerweise können viele Ausschlüsse den Test verlängern, da der Tester ständig überprüfen muss, welche Systeme er angreifen darf und welche nicht.

• Umgebungsverfügbarkeit: Tests auf Staging statt Produktion erfordern zusätzliche Konfiguration und oft separate Testdaten.

• Berichterstattung: Ein detaillierter Bericht mit Re-Tests und Debrief-Sitzungen kann 20 bis 30 Prozent zur gesamten Ausführungszeit des Auftrags hinzufügen.

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

Mehr über die Planung von Pentest-Zeit und -Ressourcen finden Sie in unseren Materialien für Spezialisten.

Warum eine präzise Umfangsdefinition die größte Herausforderung und der Schlüssel zum Pentest-Erfolg ist

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

Die häufigste Ursache für die Diskrepanz zwischen Test und Kundenerwartungen ist fehlerhaftes Scoping und ein schlecht definiertes ROE. Aber das Problem liegt normalerweise nicht in technischer Nachlässigkeit - es liegt im Kommunikationsprozess.

Kunden beschreiben den Umfang in Geschäftssprache. Sie sagen "testen Sie unsere Systeme" oder "prüfen Sie, ob wir sicher sind". Pentester müssen dies in eine Liste von Hosts, Endpunkten und erlaubten Techniken übersetzen. Diese Übersetzung ist der Punkt, an dem Informationen am häufigsten verloren gehen. Wir beobachten dies in der Branche seit Jahren - Pentester, die bei uns Ausrüstung für physische Tests bestellen, erfahren oft erst nach Beginn des Auftrags, dass der Kunde den physischen Zugang zum Serverraum nicht im Scope berücksichtigt hat, obwohl er einen "vollständigen Sicherheitstest" erwartet hatte.

Das zweite häufig übersehene 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 führt zu Situationen, in denen der Tester entweder zu früh stoppt oder eine Schwachstelle auf eine Weise ausnutzt, die der Kunde als Grenzüberschreitung betrachtet.

Ein weiterer Fehler ist das Fehlen von Geschäfts-Stakeholdern im Prozess der Umfangsdefinition. Techniker konzentrieren sich normalerweise auf die Infrastruktur. Dabei weiß der Risikomanager oder Betriebsdirektor, welche Geschäftsprozesse kritisch sind und Priorisierung erfordern. Ein ausschließlich von der IT definierter Umfang kann die Anwendung übersehen, die 80 Prozent des Unternehmensumsatzes abwickelt, weil "es ein altes System ist und jeder es kennt".

Profi-Tipp: Beziehen Sie Geschäfts-Stakeholder in die Scoping-Sitzung ein. Ein Treffen mit der für Geschäftsprozesse verantwortlichen Person kann Assets aufdecken, die die IT-Abteilung nicht erwähnt 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 Telefongespräch behandeln, liefern regelmäßig Tests, die der Kunde als nutzlos bewertet.

Pentest-Werkzeuge und -Ausrüstung zur Unterstützung bei der Umsetzung des Auftragsumfangs

Mit Kenntnis der Herausforderungen und Best Practices lohnt es sich, die Werkzeuge kennenzulernen, die Pentester bei der Umsetzung eines präzisen Auftragsumfangs unterstützen. Die richtige Ausrüstung ermöglicht schnelleres und genaueres Arbeiten im vollständigen Einklang mit dem festgelegten Scope.

Im SAPSAN-Katalog finden Sie Ausrüstung für spezifische Testvektoren, die vom Auftragsumfang abgedeckt werden. Bash Bunny Hak5 ist ein vielseitiges Gerät zur Automatisierung von HID-Angriffen und Netzwerktests, besonders nützlich bei Aufträgen mit physischem Zugang oder Endpunkten. Packet Squirrel Mark II bewährt sich bei internen Tests und Pivoting im Kundennetzwerk, wo der Scope die LAN-Infrastruktur umfasst. Für Aufträge mit Fokus auf Webanwendungen und APIs stehen Werkzeuge für Webanwendungs-Pentests zur Verfügung, die den vollen Umfang OWASP-konformer Tests abdecken. SAPSAN liefert in die gesamte EU und die USA und gewährleistet schnellen Zugang zu Ausrüstung unabhängig vom Projektstandort.

Häufig gestellte Fragen

Was ist ein Pentest-Auftragsumfang?

Der Auftragsumfang ist eine formale Aufzeichnung der Testgrenzen, erlaubten Techniken und Ausführungszeit. Er definiert, welche Systeme getestet werden, welche Angriffsmethoden erlaubt sind und in welchem Zeitfenster Tests stattfinden können.

Warum ist eine präzise Umfangsdefinition so wichtig?

Ein ungenauer Umfang führt zu voneinander abweichenden Erwartungen und rechtlichen Risiken. Eine präzise Festlegung der Testgrenzen verhindert rechtliche Vorfälle und garantiert, dass der Abschlussbericht den tatsächlichen Bedürfnissen 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 präziser Scope umfasst konkrete URLs, API-Versionen, Testumgebungen und alle Benutzerrollen vom anonymen Benutzer bis zum Administrator.

Wie beeinflusst die Umfangsgröße Kosten und Zeit von Penetrationstests?

Der Umfang schlägt sich direkt in Zeit und Kosten nieder: Externe Tests dauern typischerweise 3 bis 7 Tage, während umfangreiche Red-Team-Aufträge mehrere Wochen in Anspruch nehmen können. Je mehr Systeme, Rollen und Techniken der Scope abdeckt, desto größer der Bedarf an Ressourcen und Budget.