Umfang eines Penetrationstests
Elementrica
Ein anonymisiertes Musterdokument. Ein Auszug aus einem Statement of Work und Rules of Engagement.
Über dieses Dokument. Es ist ein Auszug aus einem echten Dokument, bereinigt um Kundendaten und sensible Angaben. Alle Namen, Domains und IP-Adressen sind fiktiv (Domains in der Zone .example, die Adressierung anonymisiert). Wir zeigen es, damit Sie sehen, wie wir die Grenze eines Tests ziehen und was wir bewusst in den Abschnitt „außerhalb des Umfangs“ schreiben. Die kommerzielle Seite (genauer Aufwand, Preis, Tagesplan) wird individuell vereinbart.
1. Kontext des Auftrags
Das Kundenprofil und das Ziel des Tests bestimmen, wo wir die Grenze ziehen. Deshalb beginnen wir mit dem Kontext, nicht mit einer Werkzeugliste.
2. Ziele des Tests
Die Ziele formulieren wir in der Sprache des Kundenrisikos, nicht in Technik. Sie entscheiden, was wichtig ist und was nebensächlich.
- Feststellen, ob sich aus dem Internet unbefugter Zugriff auf die Daten der Plattformnutzer erlangen lässt.
- Die Datentrennung zwischen Mandanten prüfen (Broken Access Control, IDOR, horizontale und vertikale Autorisierungsfehler).
- Die Widerstandsfähigkeit von Anmeldung, Passwort-Reset und Sitzungsverwaltung prüfen.
- Nachweise und Prioritäten für einen Maßnahmenplan liefern, dazu Material für das Gespräch mit einem DORA-Prüfer.
3. Testumfang (in scope)
Jedes Asset ist namentlich genannt. Es gibt keinen Posten wie „alles Übrige“ oder „die restliche Infrastruktur“. Was nicht auf dieser Liste steht, wird nicht getestet.
4. Testart und Perspektive
5. Methodik und Standards
Die Methodik sorgt dafür, dass das Ergebnis wiederholbar und überprüfbar ist und nicht davon abhängt, worauf ein bestimmter Tester an dem Tag Lust hatte.
- PTES als Prozess für die Durchführung des Tests.
- OWASP WSTG 4.x für die Webanwendung und das Partnerportal.
- OWASP API Security Top 10 für die API.
- OWASP MASTG für die mobile App.
- NIST SP 800-115 für die externe Infrastruktur.
- Risikoklassifizierung und -priorisierung nach CVSS 4.0.
6. Spielregeln (Rules of Engagement)
7. Außerhalb des Umfangs (out of scope)
Das ist der wichtigste Teil dieses Dokuments. Es ist keine Liste von Dingen, die wir nicht können. Es ist eine Liste bewusster Entscheidungen, jede mit einem Grund.
Was wir tun, wenn wir etwas jenseits der Grenze finden. Stoßen wir bei der Informationsbeschaffung auf ein relevantes Asset außerhalb des Umfangs (etwa eine vergessene Subdomain mit Admin-Panel), testen wir es nicht ohne Erweiterung des Auftrags. Wir melden es gesondert als Beobachtung, mit einer Beschreibung des Risikos. Die Grenze schützt beide Seiten, aber wir tun nicht so, als gäbe es ein Problem nicht, nur weil es ein paar Meter hinter der Linie liegt.
8. Aufwand und Ergebnisse
Die Zahl der Personentage ist die reale Obergrenze für die Tiefe eines Tests. Wir nennen sie offen, denn ein Umfang ohne zugeordnete Zeit ist eine Absicht, kein Plan. Die folgenden Werte sind Beispiele.
Was der Kunde am Ende erhält:
- Einen technischen Bericht mit Nachweisen: Reproduktionsschritte, Funktionsnachweis, Prioritäten nach CVSS 4.0 und einen konkreten Behebungsweg für jede Schwachstelle.
- Eine Zusammenfassung für die Leitung in der Sprache des Geschäftsrisikos, bereit für das Gespräch mit Vorstand und Prüfer.
- Eine Sitzung zur Besprechung der Ergebnisse mit dem Team des Kunden.
- Einen Retest der Korrekturen und eine schriftliche Bestätigung, dass die Schwachstellen behoben sind.
9. Annahmen und Bedingungen
- Der Kunde stellt Testkonten, Zugang zu den Umgebungen und die Mobile-Builds vor Arbeitsbeginn bereit.
- Der Kunde erklärt, dass er berechtigt ist, den Test der genannten Assets zu beauftragen.
- Jede Änderung des Umfangs während der Arbeit erfordert eine schriftliche Abstimmung (Change Request).
- Alles unterliegt einer NDA. Nach Abschluss werden die Testdaten gemäß der vereinbarten Aufbewahrungsrichtlinie gelöscht.
Vereinbaren Sie eine kostenlose, 30-minütige Beratung, unverbindlich. Nach dem Gespräch mit einem Berater haben Sie einen ersten Entwurf eines sinnvollen Umfangs.