Warum eine schlechte Scope-Definition kostbare Erkenntnisse verhindert und welche Leitfragen zum optimalen Scope führen
Der Pentest, der viel gekostet und wenig gebracht hat
Das Projekt schien sauber gelaufen zu sein. Ein renommierter Dienstleister, ein ordentliches Angebot, ein klarer Zeitplan, ein umfangreicher Report. Achtzig Seiten, sauber strukturiert, viele Screenshots, CVSS-Scores, Empfehlungen.
Trotzdem sitzt der CISO nach der Ergebnispräsentation mit einem mulmigen Gefühl im Meeting. Die Fragen aus dem Management treffen genau ins Schwarze:
- Sind unsere wichtigsten Systeme wirklich gut geschützt oder wurden sie gar nicht getestet?
- Wie realistisch sind die gefundenen Schwachstellen im Hinblick auf einen echten Angriff?
- Welche Risiken sind nach diesem Pentest geringer als vorher, und welche sind unverändert?
Beim genaueren Hinsehen zeigt sich das Problem. Der Scope war vor allem entlang der vorhandenen Infrastruktur definiert worden. Die leicht erreichbaren Systeme wurden getestet, die sauber dokumentierten IP-Ranges, das neue Webportal, ein paar interne Server. Kritische, aber schwer testbare Abhängigkeiten, alte Zugangswege, Drittanbieter und Schattenbereiche der IT waren nicht Teil des Scopes.
Das Ergebnis ist typisch. Viel Aufwand, respektabler Bericht, aber kein klares Bild über die Sicherheit der wirklich wichtigen Prozesse und Assets. Nicht weil die Tester schlecht gearbeitet hätten, sondern weil der Scope an der falschen Stelle begonnen hat.
Warum ein guter Pentest mit den richtigen Fragen beginnt
Ein Pentest ist kein Selbstzweck. Er ist ein Werkzeug, um etwas herauszufinden. Wenn dieses „etwas“ vor dem Projekt nicht sauber definiert ist, kann der Test fachlich sauber ausgeführt werden und trotzdem in die falsche Richtung laufen.
Der Scope ist in diesem Sinne ein strategisches Steuerinstrument. Er legt fest, wo Zeit, Kreativität und technische Tiefe investiert werden. Er entscheidet darüber, ob ein Pentest eher eine Hygieneprüfung ist oder ob er gezielt reale Risiken sichtbar macht.
In vielen Organisationen wird getestet, weil getestet werden muss, nicht weil man eine konkrete Frage beantworten will. Compliance fordert einen Pentest, ein Audit hat ihn empfohlen, ein Kunde möchte ein Zertifikat sehen. Der Fokus liegt dann darauf, den Test nachweisbar durchgeführt zu haben. Das ist verständlich, aber riskant, denn es verleitet dazu, den Scope entlang formaler Strukturen zu planen, nicht entlang der tatsächlichen Bedrohungslage.
Der häufigste Fehler: Der Scope folgt der Infrastruktur und nicht dem Risiko. Man zeichnet Netze, listet Server, trägt IP-Ranges ein und definiert, welche URLs geprüft werden. Was aus Sicht eines Angreifers interessant ist, bleibt Nebensache. Genau hier entscheidet sich, ob ein Pentest später als Pflichtübung in der Schublade landet oder ob er den Blick auf die Sicherheitsstrategie schärft.
Was ein Scope eigentlich ist
Begrifflich wird der Scope oft auf „zu testende IP-Adressen“ reduziert. Das greift zu kurz.
Ein sinnvoll verstandener Scope beschreibt die Auswahl der Systeme, Prozesse und Ziele, die in einem Test betrachtet werden sollen. Er definiert also nicht nur, welche technischen Komponenten erreichbar sind, sondern auch, welche Geschäftsprozesse dahinterstehen, welche Daten betroffen sind und welche Ziele das Testteam verfolgen soll.
Scope bedeutet außerdem Klarheit darüber, was ausdrücklich nicht geprüft wird und warum. Diese negative Abgrenzung ist wichtig, damit später niemand überrascht ist, dass ein bestimmter Bereich unbewertet geblieben ist.
Was ein Scope nicht sein darf: ein Schutzschild. Ein zu enger Scope vermittelt manchmal ein Sicherheitsgefühl, das in der Praxis gefährlich ist. Wenn kritische Systeme aus Bequemlichkeit oder Angst vor Betriebsrisiken ausgeklammert werden, bleibt die größte Angriffsfläche genau dort, wo niemand hinschaut.
Ebenso irreführend ist die Vorstellung, dass ein schmaler Scope automatisch gut ist, weil er Testdauer und Kosten reduziert. Weniger Fläche bedeutet nicht automatisch mehr Aussagekraft. Es kann im Gegenteil dazu führen, dass Budget in wenig relevante Systeme fließt, während echte Risiken weiter im Dunkeln liegen.
Die Perspektive des Angreifers
Angreifer halten sich nicht an Scope-Dokumente und sie interessieren sich selten dafür, welche Systeme in der CMDB sauber dokumentiert sind. Sie orientieren sich an der realen, nicht an der beschriebenen Angriffsfläche.
Lücken in der Dokumentation sind für Angreifer keine Randnotiz, sondern eine Chance. Vergessene VPN-Knoten, alte Portale mit geringem Traffic, Testumgebungen, die nie vom Netz genommen wurden, alte Serviceaccounts, nicht mehr betreute Schnittstellen von Drittanbietern, all das sind attraktive Einstiegspunkte.
Stellen Sie sich einen Pentest vor, der sich ausschließlich auf das neue, hochgehärtete Webportal konzentriert, weil genau dieses Projekt im Fokus stand. Parallel existiert noch ein älteres Authentifizierungssystem, das aus historischen Gründen weiterhin gültige Tokens ausstellt und gegenüber dem Internet erreichbar ist. Im Scope-Dokument steht es nicht, weil es „perspektivisch abgelöst“ werden soll.
Ein echter Angreifer wird genau hier ansetzen. Für ihn zählt, was funktioniert, nicht was im Architekturplan als „Legacy“ markiert ist. Zu enge Scopes sind deshalb nicht nur unvollständig, sondern realitätsfern. Ein guter Scope versucht, sich der Angreiferperspektive anzunähern, statt sie auszublenden.
Die wichtigsten Leitfragen für einen aussagekräftigen Scope
Die sinnvollste Art, einen Scope zu entwickeln, besteht darin, Fragen zu stellen, bevor man Systeme auflistet. Einige Leitfragen sind dabei zentral.
Zunächst geht es um die geschäftskritischen Assets. Welche Systeme, Anwendungen oder Daten würden bei einer Kompromittierung den größten Schaden verursachen. Das können Kundendaten, Produktionssysteme, Finanzprozesse oder geistiges Eigentum sein. Nicht jedes laute System ist kritisch, und nicht jedes kleine System ist harmlos.
Danach lohnt sich der Blick auf Angreiferprofile. Welche Art von Gegner soll simuliert werden. Ein externer, anonymer Angreifer ohne Vorwissen verhält sich anders als ein interner Mitarbeiter mit legitimen Zugängen. Ein Lieferant mit VPN-Zugang zu bestimmten Netzen hat wiederum andere Möglichkeiten.
Auf dieser Basis lassen sich Bedrohungsszenarien formulieren. Geht es darum, unberechtigten Zugriff auf Kundendaten zu simulieren. Geht es um Ransomware Szenarien, um Sabotage in Produktionsumgebungen, um Kontoübernahmen in einem Kundenportal oder um das unbemerkte Abgreifen sensibler Dokumente.
Die nächste Frage betrifft Schnittstellen nach außen. Welche Systeme sind exponiert, sei es über das Internet, über Partnernetze oder über APIs. Wie sehen typische Kommunikationspfade aus, und wo könnten Angreifer ihren ersten Fuß in die Tür setzen.
Besonders spannend sind die Systeme, die organisatorisch unter dem Radar laufen. Veraltete Komponenten, unklare Ownership, geringe Wartung. Hier entstehen oft die Einfallstore, die in einem rein infrastrukturbasierten Scope unterschlagen werden.
Schließlich sollte klar sein, was das Ergebnis des Pentests liefern soll. Geht es primär um eine technische Schwachstellenliste, um eine Bewertung von Risiko und Reifegrad, um eine Darstellung typischer Angriffspfade oder um Entscheidungsgrundlagen für Budgetpriorisierung. Die Antwort hat direkten Einfluss darauf, wie der Scope zugeschnitten wird.
Eine grafische Darstellung kann hier hilfreich sein, zum Beispiel eine Prozesskette, in der technische Systeme, Rollen und Datenflüsse markiert werden. Über diese Visualisierung lassen sich Scope-Kandidaten gemeinsam mit Fachbereichen und IT diskutieren.
Scope-Varianten und wofür sie sich eignen
Natürlich gibt es nicht den einen idealen Scope-Typ, der zu jeder Organisation passt. Unterschiedliche Varianten haben unterschiedliche Stärken.
Ein breiter Infrastruktur-Pentest eignet sich gut, um einen Hygiene-Check durchzuführen. Er zeigt, ob grundlegende Konfigurationsfehler, veraltete Protokolle oder offensichtliche Schwachstellen in der Breite vorhanden sind. Für eine tiefe Risikoabschätzung ist er weniger geeignet, weil die Zeit pro System begrenzt ist.
Ein Fokus auf Crown Jewels konzentriert sich auf wenige, sehr kritische Assets. Hier investieren Pentester mehr Zeit in kreative Angriffswege, kombinieren Schwachstellen und betrachten auch Randbedingungen wie Rechtekonzepte oder Protokollierung. Diese Form ist besonders wertvoll, wenn klar ist, welche Systeme existenziell sind.
Prozessbasierte Scopes betrachten nicht nur einzelne Systeme, sondern komplette Geschäftsprozesse. Beispielsweise den Weg eines Kunden von der Registrierung bis zur Rechnungsstellung oder den Prozess von der Bestellung bis zum Warenausgang. Das erlaubt es, Angriffspfade entlang realer Abläufe zu simulieren.
Use-Case-basierte Tests sind ähnlich, aber stärker auf konkrete Fragestellungen ausgerichtet, etwa „Kann ein externer Angreifer Kontoübernahmen im Kundenportal durchführen“ oder „Kann ein interner Benutzer mit Standardrechten unbemerkt sensible Daten abziehen“.
In der Praxis ist ein kombinierter Scope oft am sinnvollsten. Ein breiter Blick für die Grundhygiene, ergänzt durch fokussierte Tests für kritische Prozesse, liefert ein ausgewogenes Bild, ohne Ressourcen zu verzetteln.
Typische Stolperfallen bei der Scope-Definition
Viele Probleme wiederholen sich in Pentest-Projekten, unabhängig von Branche oder Unternehmensgröße.
Eine häufige Aussage lautet: „Testen Sie bitte nur die neuen Systeme.“ Die Logik dahinter ist nachvollziehbar, denn dort ist gerade viel Aufmerksamkeit. Aus Angreifersicht sind jedoch oft die alten Systeme interessanter, weil sie weniger im Fokus stehen und länger gewachsen sind. Wer den Scope nur auf Neues beschränkt, lässt die klassischen Einfallstore unberührt.
Ebenso verbreitet ist die Sorge um Betriebsrisiken. „Bitte das Livesystem nicht anfassen“ ist ein verständlicher Wunsch, allerdings nimmt man sich damit genau die Möglichkeit, reale Konstellationen zu testen. In vielen Fällen lässt sich hier ein Mittelweg finden, etwa durch enge Abstimmung, Zeitfenster, abgestimmte Testarten oder das gezielte Testen weniger kritischer Funktionen, während andere beobachtet werden.
Die Aussage „Wir testen nur, was in der CMDB steht“ ist bequem, aber gefährlich. Kaum eine CMDB ist vollständig, und je komplexer die Umgebung, desto größer die Lücken. Wird der Scope ausschließlich an der dokumentierten Welt ausgerichtet, bleiben unsichtbare Systeme genau dort, wo sie Angreifer am liebsten sehen.
Zeitdruck sorgt ebenfalls für schlechte Scopes. Wenn ein Test „bis Ende des Monats“ stehen muss, ist die Versuchung groß, schnell einen Minimal-Scope zu definieren. Besser wäre, ein kleineres, aber gut durchdachtes Teilprojekt zu wählen, statt in Eile einen formal großen, aber inhaltlich beliebigen Scope zu bauen.
Budgetrestriktionen sind real, und niemand kann unbegrenzt testen lassen. Dennoch gilt: Ein kleiner, sauber definierter Scope, der eine klare Frage beantwortet, ist wertvoller als eine breite, aber oberflächliche Abdeckung. Priorisierung ist hier der Schlüssel.
Mini-Fallbeispiel: Der Scope, der fast zur Katastrophe führte
Ein Unternehmen betreibt ein neues Kundenportal, das gerade intensiv vermarktet wird. Die Verantwortlichen entscheiden sich für einen Pentest mit klarem Scope: getestet wird ausschließlich dieses Portal, inklusive Frontend und Backend API.
Der Test verläuft erfolgreich. Einige Schwachstellen werden gefunden und behoben, der Bericht bescheinigt ein insgesamt gutes Sicherheitsniveau.
Was im Scope nicht stand: Der zentrale Authentifizierungsdienst, über den auch andere Anwendungen angebunden sind. Das Portal vertraut diesem Dienst vollständig. Ein Angreifer, der dort ansetzen würde, könnte Tokens für beliebige Nutzer generieren. Der Authentifizierungsdienst ist älter, wurde aus einem Vorgängerprojekt übernommen und bisher nie separat geprüft.
Einige Monate später entdeckt das SOC bei einem anderen Projekt verdächtige Aktivitäten genau gegen diesen Dienst. Glücklicherweise wurde der Angriff früh erkannt. Nachträglich betrachtet ist klar, dass der ursprüngliche Pentest hier eine massive Lücke hatte. Die Lehre war deutlich: Scopes dürfen nicht nur Assets abbilden, sondern müssen auch Abhängigkeiten berücksichtigen.
Zusammenarbeit mit dem Dienstleister
Ein guter Pentest beginnt nicht mit der Unterzeichnung des Vertrags, sondern mit einem Gespräch.
In diesem Rahmen werden Annahmen geprüft, blinde Flecken sichtbar und Prioritäten abgeklärt. Dienstleister können hier ihre Erfahrung aus anderen Projekten einbringen, etwa bei der Einschätzung, welche Komponenten für Angreifer erfahrungsgemäß besonders attraktiv sind.
Transparenz über Einschränkungen ist ebenfalls wichtig. Wenn bestimmte Systeme aus regulatorischen oder betrieblichen Gründen nur eingeschränkt getestet werden dürfen, sollte dies klar benannt und in der Risikoabwägung berücksichtigt werden.
Effiziente Scope-Diskussionen konzentrieren sich auf Risiken, nicht auf Systemlisten. Statt „Wir testen Server X und Y“ heißt es besser „Wir wollen herausfinden, ob ein externer Angreifer Zugriff auf diese Art von Daten bekommen kann“. Die technische Ableitung erfolgt dann gemeinsam.
Beispiele aus früheren Tests, sei es im eigenen Haus oder aus anonymisierten Fallstudien des Dienstleisters, sind hilfreich. Sie zeigen, wo in ähnlichen Umgebungen Angriffspfade verliefen, und helfen, den Scope realistischer zu gestalten.
Technische Tiefe: Warum Scoping auch Discovery umfasst
Scoping ist keine reine Schreibtischübung. Je nach Ausgangslage kann es sinnvoll sein, vorbereitende Discovery-Schritte in den Scope aufzunehmen.
In vielen Umgebungen gibt es Systeme, die im Scope sein sollten, aber nicht dokumentiert sind. Attack Surface Mapping von außen, Cloud Discovery in großen Tenants oder ein strukturierter Blick auf Zertifikate und DNS-Einträge zeigen oft Komponenten, die in der internen Sicht fehlen.
Hier zeigt sich der Unterschied zwischen bekannter und realer Angriffsfläche. Bekannte Systeme sind jene, die in den Plänen auftauchen. Reale Angriffsfläche umfasst alles, was aus Sicht eines Angreifers sichtbar ist. Zertifikate, die auf alte Hostnamen ausgestellt sind, vergessene Subdomains, öffentlich erreichbare APIs, externe Dienste mit Unternehmensbranding, all das gehört in diese Betrachtung.
Viele Pentester nutzen ohnehin OSINT, um sich ein Bild zu machen. Diese Phase sollte explizit im Scope verankert werden, denn sie liefert nicht nur technische, sondern auch organisatorische Erkenntnisse. Wenn bereits in der Vorbereitung Lücken in der Dokumentation auffallen, ist das ein starkes Signal für den weiteren Sicherheitsprozess.
Leitfaden zur Scope-Erstellung
Statt einer starren Checkliste lässt sich ein strukturierter Weg skizzieren, der in der Praxis gut funktioniert.
Am Anfang steht die Identifikation kritischer Prozesse. Nicht Server, nicht Datenbanken, sondern Abläufe, die für das Unternehmen wichtig sind. Verkauf, Produktion, Abrechnung, Support, Entwicklung, je nach Kontext.
Auf dieser Basis werden relevante Assets abgeleitet. Welche Anwendungen, Systeme, Schnittstellen und Daten sind für diese Prozesse zentral.
Im nächsten Schritt bewertet man realistische Angriffswege. Wie könnte ein externer Angreifer versuchen, diese Prozesse zu beeinflussen. Welche Einstiegspunkte sind naheliegend, welche eher exotisch, aber nicht ausgeschlossen.
Dann werden technische und organisatorische Abhängigkeiten betrachtet. Authentifizierungsdienste, zentrale Datenhaltung, Integrationen zu Partnern, administrative Zugänge.
Aus diesen Bausteinen entsteht ein konsolidierter Scope Vorschlag, der priorisiert, welche Teile unbedingt geprüft werden sollten und welche optional sind, falls Budget und Zeit es erlauben.
Dieser Vorschlag wird mit dem Dienstleister validiert. Pentester können hier einschätzen, ob der Scope in der vorgesehenen Zeit sinnvoll bearbeitbar ist, ob er zu breit oder zu schmal ist und welche Anpassungen die Aussagekraft erhöhen würden.
Zum Schluss wird der Scope sauber dokumentiert und freigegeben. Idealerweise so, dass später nachvollziehbar bleibt, warum bestimmte Bereiche drinnen oder draußen sind. Das hilft bei der Einordnung der Ergebnisse und bei Folgeprojekten.
Ein positiver Fall: Der Scope, der die Sicherheitsstrategie veränderte
Ein Unternehmen im Finanzbereich stand vor der Aufgabe, einen Pentest durchzuführen, um sowohl regulatorische Anforderungen zu erfüllen als auch die eigene Sicherheitslage besser zu verstehen. Statt einfach die Firewall und ein paar Portale in den Scope zu schreiben, wählte man einen anderen Weg.
Gemeinsam mit dem Dienstleister wurde ein zentraler Geschäftsprozess ausgewählt: vom Login im Kundenportal über die Einsicht in Kontoinformationen bis hin zu bestimmten Transaktionsarten. Man identifizierte alle beteiligten Systeme, inklusive Authentifizierung, interne Services, Schnittstellen zu Partnern und relevanter Administrationspfade.
Der Pentest konzentrierte sich darauf, ob und wie ein externer Angreifer diesen Prozess missbrauchen könnte. Das Ergebnis waren nicht nur technische Findings, sondern ein klares Bild über die Schwachstellen im Zusammenspiel. Mehrere kritische Punkte lagen nicht in der sichtbaren Frontend-Anwendung, sondern in Berechtigungskonzepten, Fehlerbehandlung und einem wenig beachteten internen Service.
Diese Erkenntnisse führten dazu, dass das gesamte Security-Programm neu priorisiert wurde. Statt überall ein bisschen zu härten, investierte das Unternehmen gezielt in die Absicherung der identifizierten Angriffspfade, in Monitoring und in Prozessanpassungen. Der Pentest wurde damit zum Ausgangspunkt einer strategischen Weiterentwicklung und nicht nur zum Pflichtdokument.
Fazit: Scope als entscheidender Erfolgsfaktor
Ein Pentest ist immer nur so gut wie sein Scope. Er bestimmt, welche Fragen gestellt werden, welche Systeme ins Licht rücken und welche Risiken sichtbar werden. Ein sauber definierter Scope sorgt dafür, dass Budget und Zeit dort eingesetzt werden, wo der Erkenntnisgewinn am größten ist.
Gute Scope-Arbeit spart am Ende Kosten und Zeit, weil sie verhindert, dass man gründlich an den falschen Stellen testet. Sie reduziert Blind Spots, macht Abhängigkeiten transparent und liefert Ergebnisse, die sich direkt in Maßnahmen übersetzen lassen.
Wer Scoping als formalen Nebenschritt behandelt, verschenkt Potenzial. Wer es als zentralen Bestandteil des Pentest-Projektes versteht, erhält Berichte, die nicht im Archiv verschwinden, sondern in der Sicherheitsstrategie Spuren hinterlassen.