Der Scope eines Pentests legt fest, was geprüft werden soll, wie weit die Prüfung gehen darf und welche Testhandlungen ausdrücklich ausgeschlossen sind. Häufig wird der Scope hauptsächlich als technische Liste verstanden: bestimmte Domains, IP-Adressen, Webanwendungen, APIs und Endpunkte.
Das greift jedoch zu kurz.
Ein sinnvoller Scope muss sich vor allem daran orientieren, wo das tatsächliche geschäftliche Risiko des Kunden liegt. Eine technisch vollständige Prüfung ist nur dann wertvoll, wenn sie die Systeme, Daten und Geschäftsprozesse erfasst, deren Gefährdung für den Kunden tatsächlich relevant wäre.
Deshalb sollte der Scope eines Web- oder API-Pentests immer in direkter Abstimmung zwischen Auftraggeber und Pentester festgelegt werden.
Der Scope ist mehr als eine Liste von URLs
Zum technischen Scope können beispielsweise gehören:
- Domains, Subdomains und IP-Adressen
- Webanwendungen und Kundenportale
- API-Endpunkte und API-Versionen
- mobile oder externe Clients einer API
- Benutzerrollen und Berechtigungsstufen
- angebundene Drittanbieter und Identitätsdienste
Damit ist der Scope aber noch nicht vollständig beschrieben.
Zusätzlich muss festgelegt werden, welche Daten, Geschäftsprozesse und Angriffsmethoden betrachtet werden sollen. Auch organisatorische und betriebliche Einschränkungen gehören dazu. Eine Anwendung kann technisch im Scope liegen, während bestimmte Funktionen oder Testmethoden ausdrücklich ausgeschlossen bleiben.
So kann beispielsweise das Kundenportal getestet werden, während der Versand realer Bestellungen, die Veränderung produktiver Kundendaten oder die Belastung eines angebundenen Zahlungssystems untersagt ist.
Ausgangspunkt ist das geschäftliche Risiko
Der wichtigste Ausgangspunkt für die Scope-Festlegung ist nicht die technische Architektur, sondern die Frage:
Was wäre für den Kunden besonders problematisch, wenn es durch einen Angreifer kompromittiert würde?
Die klassische Betrachtung der Informationssicherheit unterscheidet zwischen Vertraulichkeit, Integrität und Verfügbarkeit. Diese Einteilung ist hilfreich, bildet den geschäftlichen Schaden aber nicht automatisch vollständig ab.
Eine Schwachstelle kann technisch betrachtet nur die Vertraulichkeit betreffen und trotzdem ein erhebliches wirtschaftliches Risiko darstellen.
Ein Beispiel aus der Praxis war eine Preisliste, die ausschließlich registrierten und anschließend durch das Unternehmen verifizierten Kunden zur Verfügung stehen sollte. Die Preise waren bewusst nicht öffentlich zugänglich. Das Unternehmen wollte dadurch verhindern, dass Wettbewerber seine Preisstruktur ohne Weiteres einsehen und für eigene Angebote oder Vertriebsstrategien verwenden konnten.
Für den Kunden war der Schutz dieser Preisliste geschäftlich besonders wichtig.
Ein zuvor eingesetzter Pentester hatte das Problem nur am Rande erkannt. Aus einer rein technischen Perspektive handelte es sich um eine unbeabsichtigte Offenlegung von Informationen. Die Integrität der Daten wurde nicht verändert und die Verfügbarkeit des Systems war nicht beeinträchtigt. Entsprechend wäre die Schwachstelle möglicherweise nur mit einem mittleren Schweregrad bewertet worden.
Aus Sicht des Kunden wäre ein unkontrollierter Zugriff auf die Preisliste jedoch ein kritischer Fehler gewesen. Die Schwachstelle hätte unmittelbar die Wettbewerbsposition und die eigene Preisstrategie gefährden können.
Dieses Beispiel zeigt, warum eine technische Schweregradbewertung allein nicht ausreicht. Verfahren wie CVSS können die Bewertung unterstützen. Sie ersetzen aber nicht die Betrachtung des konkreten geschäftlichen Schadens.
Kritische Daten und Geschäftsprozesse identifizieren
Vor Beginn des Pentests sollte deshalb gemeinsam ermittelt werden, welche Systeme auf besonders schützenswerte Daten zugreifen und welche Endpunkte an kritischen Geschäftsprozessen beteiligt sind.
Dabei reicht es nicht, nur die offensichtlichen Funktionen wie Login, Registrierung oder Passwortzurücksetzung zu betrachten. Relevant können beispielsweise auch Endpunkte sein, die:
- Preislisten, Verträge oder interne Dokumente bereitstellen
- personenbezogene oder vertrauliche Kundendaten ausgeben
- Rollen und Berechtigungen verändern
- Bestellungen, Buchungen oder Zahlungen auslösen
- Exporte oder Berichte erzeugen
- Dateien hochladen oder verarbeiten
- administrative Aktionen durchführen
Gerade bei APIs ist die Bedeutung eines Endpunkts anhand seiner URL oder seiner technischen Bezeichnung nicht immer erkennbar. Ein unscheinbarer Endpunkt kann Zugriff auf besonders sensible Informationen ermöglichen oder einen zentralen Geschäftsprozess steuern.
Der Kunde kennt die wirtschaftliche Bedeutung seiner Daten und Abläufe. Der Pentester kennt typische Angriffswege und technische Abhängigkeiten. Erst die Verbindung beider Perspektiven ermöglicht einen sinnvollen Scope.
Auch Benutzerrollen gehören zum Scope
Bei Webanwendungen und APIs muss festgelegt werden, aus welchen Rollen und Berechtigungsstufen heraus getestet werden soll.
Ein Test ausschließlich ohne Anmeldung kann zwar Schwachstellen auf öffentlich erreichbaren Oberflächen finden, erfasst aber keine Fehler innerhalb geschützter Kunden- oder Administrationsbereiche.
Je nach Anwendung können unter anderem folgende Perspektiven relevant sein:
- nicht angemeldeter Benutzer
- registrierter, aber noch nicht verifizierter Benutzer
- regulärer Kunde
- privilegierter Kunde oder Geschäftspartner
- Mitarbeiter
- Administrator
- technischer API-Client
Besonders Fehler in der Zugriffskontrolle lassen sich häufig erst durch den Vergleich mehrerer Benutzerkonten erkennen. Ein Pentester muss beispielsweise prüfen können, ob ein Kunde auf die Daten eines anderen Kunden zugreifen oder ob ein Benutzer Funktionen einer höher privilegierten Rolle aufrufen kann.
Dafür müssen passende Testkonten, Rollen und Beispieldaten bereitgestellt werden. Andernfalls besteht die Gefahr, dass ein wesentlicher Teil der tatsächlichen Angriffsfläche ungeprüft bleibt.
Der Scope legt auch die zu prüfenden Schwachstellen fest
Ein Scope beschreibt nicht nur Systeme und Endpunkte. Er kann ebenfalls festlegen, welche Arten von Schwachstellen geprüft werden sollen.
Bei einem umfassenden Web- und API-Pentest gehören typischerweise unter anderem Fehler in folgenden Bereichen dazu:
- Authentifizierung und Sitzungsverwaltung
- Autorisierung und Zugriffskontrolle
- Eingabevalidierung und Injection-Schwachstellen
- Geschäftslogik
- Datei-Uploads und Dateiverarbeitung
- Informationslecks
- serverseitige Anfragen und Integrationen
- kryptografische Verfahren und Transportverschlüsselung
- Sicherheitskonfiguration und Fehlermeldungen
Je nach Zielsetzung kann der Auftrag aber enger gefasst sein. Ein Test kann sich beispielsweise ausschließlich auf eine neue API, einen Bezahlprozess oder die Trennung verschiedener Mandanten konzentrieren.
Dabei sollte eindeutig dokumentiert werden, welche Schwachstellenklassen betrachtet werden und welche nicht. Die Formulierung „Durchführung eines Pentests“ allein ist dafür zu ungenau.
Testmethoden müssen ausdrücklich vereinbart werden
Nicht jede grundsätzlich mögliche Testmethode darf automatisch eingesetzt werden. Bestimmte Verfahren können den Betrieb beeinträchtigen, Benutzer täuschen oder rechtliche und organisatorische Folgen haben.
Deshalb muss festgelegt werden, ob beispielsweise folgende Methoden zulässig sind:
- Social Engineering und Phishing
- Brute-Force-Angriffe oder Password Spraying
- Tests von Rate Limits
- Denial-of-Service- oder Lasttests
- automatisierte Schwachstellenscanner
- das Hochladen potenziell gefährlicher Dateien
- die Veränderung oder Löschung von Daten
- Tests gegen angebundene Drittanbieter
Ein regulärer Web-Pentest umfasst nicht automatisch Social Engineering oder Phishing. Auch ein Denial-of-Service-Test sollte niemals ohne ausdrückliche Freigabe durchgeführt werden.
Die Entscheidung hängt unter anderem von der Risikotoleranz des Kunden, den vorhandenen Schutzmaßnahmen und der betrieblichen Situation ab.
Vorhandene Schutzmaßnahmen beeinflussen die Testtiefe
Gibt ein Kunde beispielsweise an, wirksame Rate Limits und Schutzmechanismen gegen automatisierte Anmeldeversuche umgesetzt zu haben, kann ein kontrollierter Brute-Force-Test sinnvoll sein. Dann wird nicht nur geprüft, ob ein Schutzmechanismus vorhanden ist, sondern auch, ob er unter realistischen Bedingungen tatsächlich greift.
Ähnliches gilt für vorsichtige Last- oder Denial-of-Service-Tests. Solche Tests können zweckmäßig sein, wenn die Widerstandsfähigkeit des Systems ausdrücklich bewertet werden soll und geeignete Schutzmaßnahmen erwartet werden.
Weiß der Kunde dagegen bereits, dass keine Rate Limits vorhanden sind, ist ein umfangreicher Brute-Force-Test meist nicht notwendig. Der Pentester würde lediglich eine bereits bekannte Schwäche praktisch ausnutzen und dabei möglicherweise Konten sperren, Systeme belasten oder produktive Abläufe beeinträchtigen.
In diesem Fall reicht es häufig aus, die fehlende Schutzmaßnahme zu dokumentieren und das daraus entstehende Risiko zu bewerten. Ein begrenzter, nicht destruktiver Nachweis kann trotzdem sinnvoll sein, sofern er für die Nachvollziehbarkeit des Befunds erforderlich ist.
Ein Pentest soll neue Erkenntnisse liefern. Er sollte nicht unnötig Schaden verursachen, nur um eine bereits bekannte Schwäche ausführlich zu demonstrieren.
Warum produktive Systeme teilweise ausgeschlossen werden
Es kann vorkommen, dass geschäftskritische Systeme oder Endpunkte bewusst aus dem aktiven Test ausgeschlossen werden. Das wirkt zunächst widersprüchlich: Gerade wichtige Systeme sollten schließlich besonders gründlich geprüft werden.
In der Praxis kann ein aktiver Test jedoch Risiken für laufende Geschäftsprozesse verursachen. Ein Endpunkt kann beispielsweise unmittelbar Bestellungen auslösen, Produktionsdaten verändern, externe Dienstleister ansprechen oder rechtlich relevante Vorgänge erzeugen.
Ein vollständiger Ausschluss sollte trotzdem nicht vorschnell erfolgen. Stattdessen können alternative Vorgehensweisen vereinbart werden, beispielsweise:
- Prüfung in einer produktionsnahen Testumgebung
- Tests innerhalb eines Wartungsfensters
- Beschränkung auf nicht verändernde Anfragen
- Verwendung speziell vorbereiteter Testdaten
- Freigabe nur bestimmter Testfälle
- gemeinsame Überwachung durch Betrieb oder Entwicklung
Wird ein Bereich tatsächlich nicht getestet, muss diese Einschränkung im Abschlussbericht deutlich genannt werden. Andernfalls könnte der Eindruck entstehen, die gesamte Anwendung sei geprüft worden.
Scope und Rules of Engagement gehören zusammen
Der technische Scope sollte durch verbindliche Testregeln ergänzt werden. Diese werden häufig als Rules of Engagement bezeichnet.
Darin sollten unter anderem die zulässigen Testzeiten, Ansprechpartner, Abbruchkriterien und Meldewege festgelegt werden. Ebenfalls wichtig ist die Frage, wie mit kritischen Schwachstellen umzugehen ist, die während des Tests entdeckt werden.
Ein praxistauglicher Scope sollte mindestens folgende Punkte beantworten:
- Welche Systeme, Anwendungen, APIs und Endpunkte werden getestet?
- Welche Benutzerrollen und Testkonten stehen zur Verfügung?
- Welche Daten und Geschäftsprozesse sind besonders kritisch?
- Welche Schwachstellenklassen sollen betrachtet werden?
- Welche Testmethoden sind erlaubt oder verboten?
- Welche betrieblichen Einschränkungen und Abbruchkriterien gelten?
- Welche Drittanbieter oder verbundenen Systeme sind ausgeschlossen?
- Wie werden kritische Befunde gemeldet und bewertet?
Diese Punkte sollten vor Testbeginn schriftlich vereinbart werden. Änderungen während des Pentests müssen ebenfalls dokumentiert und durch den Auftraggeber freigegeben werden.
Ein guter Scope verbessert auch den Abschlussbericht
Ein klar definierter Scope erleichtert nicht nur die Durchführung, sondern auch die Bewertung der Ergebnisse.
Der Pentester kann die gefundenen Schwachstellen besser in den geschäftlichen Kontext einordnen. Der Kunde erhält dadurch keine rein technische Liste von Befunden, sondern eine nachvollziehbare Darstellung der tatsächlichen Risiken.
Dabei sollte zwischen der technischen Schwere einer Schwachstelle und ihrer Bedeutung für das Unternehmen unterschieden werden.
Eine technisch schwerwiegende Schwachstelle kann in einem isolierten, unkritischen System nur ein begrenztes Geschäftsrisiko verursachen. Umgekehrt kann eine technisch vergleichsweise einfache Informationsoffenlegung besonders kritisch sein, wenn sie vertrauliche Preise, Geschäftsstrategien, Kundendaten oder andere wettbewerbsrelevante Informationen betrifft.
Diese Einordnung ist nur möglich, wenn der geschäftliche Kontext bereits bei der Scope-Festlegung berücksichtigt wurde.
Fazit
Der Scope eines Web- oder API-Pentests sollte niemals nur aus einer Liste von Domains, URLs und IP-Adressen bestehen.
Er muss festlegen, welche Systeme, Benutzerrollen, Daten, Geschäftsprozesse, Schwachstellenklassen und Testmethoden betrachtet werden. Gleichzeitig müssen betriebliche Einschränkungen und ausdrücklich verbotene Handlungen dokumentiert werden.
Entscheidend ist dabei das geschäftliche Risiko des Kunden. Der Pentester kann technische Schwachstellen erkennen und deren Ausnutzbarkeit beurteilen. Welche Folgen eine Schwachstelle für das Unternehmen hat, lässt sich jedoch nur gemeinsam mit dem Kunden bestimmen.
Ein guter Scope verbindet deshalb technische Angriffsflächen mit geschäftlichen Prioritäten. Erst dadurch wird aus einer allgemeinen Sicherheitsprüfung ein Pentest, der die für den Kunden tatsächlich relevanten Risiken untersucht.