Klarer Scope in deiner Vulnerability-Disclosure-Policy bestimmt, was Forscher testen sollen. Mach es falsch und du wirst valide Research entmutigen oder mit ungewolltem Testing umgehen müssen.
Die Scope-Section deiner Vulnerability-Disclosure-Policy bestimmt, was Forscher testen sollen und was sie vermeiden sollen. Mach es falsch und du wirst entweder valide Research entmutigen oder mit ungewolltem Testing umgehen müssen, das deine Security nicht verbessert.
Ohne klaren Scope wissen Forscher nicht, was akzeptabel zum Testen ist. Einige werden alles testen, inklusive Systeme, die du nicht besitzt oder nicht fixen kannst. Andere werden vermeiden, irgendetwas zu testen, weil sie unsicher sind, was erlaubt ist. Keines dieser Outcomes dient der Security.
Klarer Scope ermutigt Forscher, sich auf Systeme zu fokussieren, wo ihre Findings umgesetzt werden. Er schützt Third-Party-Services, die du integrierst, aber nicht kontrollierst. Er managed Forscher-Erwartungen darüber, was du als valide Vulnerabilities betrachtest.
Der simpelste Ansatz ist, spezifische Domains, IP-Ranges oder Applications zu listen, die Forscher testen können. Das funktioniert gut für Organisationen mit einer kleinen Anzahl von Web-Properties.
Das Problem mit der Aufzählung von Systemen ist, dass es Maintenance erfordert. Launche ein neues Produkt und du musst deinen Scope updaten. Akquiriere ein anderes Unternehmen und deren Systeme sind nicht automatisch gecovered. Forscher könnten interessante Vulnerabilities in Systemen entdecken, die du vergessen hast zu listen.
Breitere Scope-Definitionen vermeiden dieses Problem, schaffen aber Ambiguität. "Alle Systeme, die von Example Corp besessen und betrieben werden" zu sagen ist technisch comprehensive, aber Forscher können nicht wissen, was das inkludiert. Sie sehen deine Corporate-Website, aber betreibst du auch Infrastruktur, die sie nicht leicht identifizieren können?
Ein Hybrid-Ansatz funktioniert besser. Liste deine primären Properties explizit, dann füge ein Catch-All für andere owned Systems hinzu. Das gibt Forschern klare primäre Targets, während Reports auf Systemen erlaubt werden, die du nicht explizit erwähnt hast.
Die meisten Organisationen integrieren Third-Party-Services. Deine Website könnte Cloudflare für CDN nutzen, AWS für Hosting, Stripe für Payments und Auth0 für Authentication. Vulnerabilities in diesen Services sind nicht deine zum Fixen.
Third-Party-Services explizit vom Scope auszuschließen verhindert verschwendeten Effort. Ein Forscher, der Tage damit verbringt, eine Vulnerability im Checkout-Flow deines Payment-Providers zu finden, kann keine Response erwarten, wenn du diesen Code nicht kontrollierst.
Aber die Boundary ist nicht immer klar. Wenn du Cloudflare auf eine Weise misskonfigurierst, die Origin-Server exposed, ist das im Scope? Du bist für die Configuration responsible, auch wenn Cloudflare den Service bereitstellt. Gleiches gilt für unsachgemäß konfigurierte AWS-S3-Buckets oder zu permissive Auth0-Rules.
Die Unterscheidung ist, ob die Vulnerability in deiner Configuration und Nutzung des Third-Party-Service ist, oder im Service selbst. Ersteres ist im Scope, weil du es fixen kannst. Letzteres nicht, weil du es nicht kannst.
Scope ist nicht nur über welche Systeme Forscher testen können, sondern wie sie sie testen können. Bestimmte Testing-Methoden sind universell problematisch und sollten explizit verboten werden.
Social Engineering gegen deine Mitarbeiter ist nicht useful Security-Testing für die meisten Organisationen. Ein Forscher, der deine Helpdesk anruft und vorgibt, ein Executive zu sein, demonstriert, dass Social Engineering funktioniert, was du bereits wusstest. Außer du testest speziell Social-Engineering-Defenses, schließe es vom Scope aus.
Physical-Security-Testing erfordert noch mehr explizite Authorization. Ein Forscher, der in deinem Office auftaucht, um Badge-Reader oder Door-Locks zu testen, ist nicht hilfreich ohne vorherige Coordination. Das Risk, Law Enforcement zu involvieren, ist zu hoch.
Denial-of-Service-Testing ist tricky. Legitimes Security-Testing verursacht manchmal versehentlich Service-Disruption. Das ist anders als absichtlich DoS-Vulnerabilities zu testen, indem Production-Services heruntergefahren werden. Dein Scope sollte intentional DoS verbieten, aber anerkennen, dass accidental Disruption während authorized Testing keine Violation ist.
Einige Organisationen schließen bestimmte Vulnerability-Typen vom Scope aus. Übliche Exclusions beinhalten SPF/DMARC-Issues, fehlende Security-Headers ohne demonstrierten Impact, descriptive Error-Messages oder Self-XSS.
Diese Exclusions sind kontrovers. Einige Forscher argumentieren, dass Organisationen sie nutzen, um valide Security-Issues zu ignorieren. Organisationen kontern, dass sie bekannte Limitations adressieren und keine Duplicate-Reports von Issues wollen, die sie akzeptiert haben.
Der Middle Ground ist, zu erklären, warum du bestimmte Findings ausschließt, statt sie nur zu listen. Wenn du entschieden hast, dass fehlende CSP-Headers keine Priorität gegeben deines Threat-Models sind, hilft das zu erklären Forschern, die Entscheidung zu verstehen. Wenn du "SPF-Records" ohne Context ausschließt, wissen Forscher nicht, ob du aware des Issues bist und es nicht fixen willst, oder ob du SPF nicht verstehst.
Forscher stoßen manchmal während des Testings auf Daten, auf die sie nicht zugreifen sollten. Echte User-Daten, Financial Information, Healthcare Records oder Daten über Minors erfordern special Handling.
Dein Scope sollte spezifizieren, dass Forscher Zugriff auf echte User-Daten minimieren müssen. Wenn sie eine Vulnerability demonstrieren müssen, ist das Erstellen von Test-Accounts präferabel zu echten User-Daten zuzugreifen. Wenn sie auf echte User-Daten zugreifen müssen, um das Issue zu demonstrieren, sollten sie das Minimum nötige zugreifen und es nicht exfiltrieren oder retainen.
Das geht so sehr darum, Forscher zu schützen wie User. Ein Forscher, der während des Testings auf extensive echte User-Daten zugreift, hat potentielle Legal Exposure unter verschiedenen Data-Protection-Laws. Klar zu stating, dass sie solchen Zugriff minimieren sollten, liefert Guidance, die alle schützt.
Viele Organisationen betreiben Legacy-Systeme, von denen sie wissen, dass sie unsicher sind, aber nicht sofort fixen oder decommissionieren können. Diese Systeme schaffen Scope-Challenges.
Sie vom Scope auszuschließen verhindert, dass Forscher bekannte Issues melden, signalisiert aber auch, dass Security-Testing auf diesen Systemen nicht willkommen ist. Sie zu inkludieren bedeutet, Reports über Probleme zu erhalten, die du bereits kennst und nicht schnell fixen kannst.
Ein Ansatz ist, Legacy-Systeme als in-Scope zu listen, aber mit Caveats. Acknowledge, dass du aware der Security-Limitations bist und an Migration arbeitest, aber an unexpected Issues interessiert bist, die Forscher entdecken könnten. Das managed Erwartungen, während noch valuable Research erlaubt wird.
Scope entwickelt sich, während sich deine Infrastruktur ändert. Neue Produkte launchen, Unternehmen akquirieren oder zu neuen Architekturen migrieren beeinflusst alles Scope.
Wenn du Systeme zum Scope hinzufügst, announce es. Forscher, die dein Programm monitoren, werden es bemerken und könnten neue Targets investigaten. Wenn du Systeme vom Scope entfernst, erkläre warum. Wenn du einen Service decommissionst, sollten Forscher wissen, keine Zeit darauf zu verbringen.
Entferne Systeme nicht stillschweigend vom Scope ohne Erklärung, besonders wenn Forscher sie getestet haben. Ein Forscher, der eine Vulnerability in einem System findet, das letzten Monat im Scope war, verdient eine Response, auch wenn du seitdem entschieden hast, es auszuschließen.
Organisationen betreiben manchmal multiple Disclosure-Channels mit verschiedenem Scope. Ein internes VDP könnte breiten Scope haben, der alle Systeme covered. Ein öffentliches Bug Bounty könnte engen Scope haben, limitiert auf spezifische High-Priority-Applications.
Das funktioniert, aber kommuniziere es klar. Forscher sollten wissen, welchen Channel sie für welche Findings nutzen sollen. Eine Vulnerability in einem Out-of-Scope-System für dein Bug Bounty könnte noch im Scope für dein VDP sein, nur ohne Payment.
Ob Forscher Production-Systeme testen sollten, hängt von deiner Risk-Tolerance und der Natur deines Service ab. Für viele Web-Applications ist sorgfältiges Testen von Production-Systemen akzeptabel. Für Financial Services oder Healthcare-Systeme ist es das möglicherweise nicht.
Wenn du Staging oder Testing-Environments bereitstellst, spezifiziere, ob Forscher sie statt Production nutzen sollten. Wenn du solche Environments nicht bereitstellst, werden Forscher Production-Systeme by Default testen.
Die Challenge mit Staging-Environments ist, dass sie oft nicht Production matchen. Security-Issues in Production existieren möglicherweise nicht in Staging, oder vice versa. Forscher bevorzugen generell das Testen von Production, weil es die tatsächliche Security-Posture reflektiert.
Einige Organisationen limitieren Scope geografisch. Sie könnten Systeme ausschließen, die in bestimmten Ländern gehostet sind, oder Testing auf Forscher in bestimmten Jurisdiktionen beschränken.
Geografische Restriktionen sind selten in Vulnerability Disclosure, aber sie existieren. Eine Organisation, die spezifischen Export-Controls unterliegt, könnte restricten, wer technische Details über ihre Systeme erhalten kann. Eine Organisation, die primär in einem Land operiert, könnte nur diese Systeme scopen.
Diese Restriktionen schaffen Enforcement-Challenges. Wie verifizierst du, wo ein Forscher located ist? Wie verhinderst du, dass Forscher außerhalb deines geografischen Scope Systeme testen, auf die sie zugreifen können? Geografischer Scope macht nur Sinn, wenn du starke technische oder Legal Reasons dafür hast.
Wie auch immer du Scope definierst, dokumentiere ihn klar in deiner Vulnerability-Disclosure-Policy. Nutze spezifische Examples statt nur generelle Principles. Statt "teste keine Third-Party-Services", liste die spezifischen Third-Party-Services, die du integrierst und die out-of-scope sind.
Liefere Context für deine Scope-Entscheidungen, wenn hilfreich. Wenn du bestimmte Systeme ausschließt, weil sie decommissioned werden, sage es. Wenn du Scope auf spezifische Applications limitierst, weil sie sensible Daten handhaben, erkläre das.
Klarer Scope reduziert Friction mit Forschern und hilft ihnen, ihre Efforts zu fokussieren, wo du am meisten von ihren Findings profitierst.
Ein technischer Vergleich von Vulnerability Disclosure Ansätzen von security.txt bis zu Full Bug Bounty Plattformen. Die Security Trade-offs auf jeder Reifestufe verstehen.
Ein technischer Vergleich von Vulnerability Disclosure Ansätzen von security.txt bis zu Full Bug Bounty Plattformen. Die Security Trade-offs auf jeder Reifestufe verstehen.
GDPR schafft Verpflichtungen rund um Data Breaches, die mit Vulnerability Management intersecten. Diese Intersection zu verstehen verhindert Compliance-Probleme.
Get the latest security research insights and vulnerability disclosure best practices delivered to your inbox.