GDPR schafft Verpflichtungen rund um Data Breaches, die mit Vulnerability Management intersecten. Diese Intersection zu verstehen verhindert Compliance-Probleme.
GDPR hat verändert, wie Organisationen mit Security-Vulnerabilities umgehen. Nicht weil es direkt Vulnerability Disclosure reguliert, sondern weil es Obligations um Data Breaches schafft, die oft mit Vulnerability Management intersecten. Dieses Intersection zu verstehen verhindert Compliance-Probleme.
Artikel 33 der GDPR erfordert, dass Organisationen ihre Aufsichtsbehörde innerhalb von 72 Stunden nach Kenntnis eines Personal-Data-Breach benachrichtigen. Diese Timeline schafft Spannung mit Coordinated Vulnerability Disclosure, die typischerweise auf längeren Timelines operiert.
Der Schlüsselphrase ist "Kenntnis erlangen". Wann erlangt eine Organisation Kenntnis eines Breach? Wenn ein Forscher eine Vulnerability meldet, triggert das die 72-Stunden-Uhr? Die Antwort hängt davon ab, ob die Vulnerability exploited wurde.
Eine gemeldete Vulnerability, die nicht exploited wurde, ist kein Breach unter GDPR. Das Potenzial für Data-Exposure ist nicht dasselbe wie tatsächliche Data-Exposure. Du hast Zeit, die Vulnerability zu fixen, bevor sie ein Breach wird.
Aber wenn ein Forscher eine Vulnerability meldet und erwähnt, dass sie auf User-Daten zugreifen können, oder wenn sie Evidenz liefern, dass andere auf User-Daten zugegriffen haben, ist das ein Breach. Die 72-Stunden-Uhr startet, wenn du diese Information erhältst.
GDPR verbietet die Verarbeitung personenbezogener Daten ohne Rechtsgrundlage. Security-Testing involviert oft die Verarbeitung personenbezogener Daten, was rechtliche Komplexität für beide, Forscher und Organisationen, schafft.
Wenn ein Forscher deine Systeme testet und auf personenbezogene Daten stößt, verarbeitet er diese Daten. Wenn sie auf User-Accounts zugreifen, Datenbank-Contents ansehen oder Communications während des Testings intercepten, verarbeiten sie personenbezogene Daten unter GDPR.
Organisationen, die Safe Harbor für Security-Forscher bereitstellen, müssen dies adressieren. Deine Vulnerability-Disclosure-Policy sollte klarstellen, dass Security-Testing innerhalb deines definierten Scope eine Rechtsgrundlage hat, typischerweise berechtigtes Interesse unter Artikel 6(1)(f). Du akzeptierst die Verarbeitung als notwendig für Security-Zwecke.
Das gibt Forschern keinen unbegrenzten Zugriff auf personenbezogene Daten. Deine Policy sollte spezifizieren, dass Forscher Data-Access minimieren müssen, keine Daten jenseits dessen exfiltrieren dürfen, was nötig ist, um die Vulnerability zu demonstrieren, und alle Daten löschen müssen, auf die sie während des Testings zugegriffen haben.
Wenn du eine Bug-Bounty-Plattform nutzt, verarbeitet diese Plattform wahrscheinlich Vulnerability-Reports, die Informationen über deine Systeme und potenziell deine User enthalten. Unter GDPR sind sie ein Data Processor, und du brauchst ein Data-Processing-Agreement.
Die meisten Plattformen bieten Standard-DPAs. Lies sie sorgfältig. Sie sollten spezifizieren, dass die Plattform Daten nur auf deine Instructions verarbeitet, angemessene Security-Measures implementiert und bei Data-Subject-Requests assistiert, wenn nötig.
Der tricky Part sind encrypted Reports. Wenn du End-to-End-Encryption nutzt, wo die Plattform Report-Contents nicht decrypten kann, könnten sie argumentieren, dass sie keine personenbezogenen Daten verarbeiten, weil sie sie nicht lesen können. Das vereinfacht Compliance, hängt aber davon ab, dass die Encryption-Implementierung wirklich End-to-End ist.
GDPR gibt Individuen Rights über ihre personenbezogenen Daten. Diese Rights schaffen interessante Szenarien in Vulnerability Disclosure.
Wenn ein Forscher eine Vulnerability meldet, die User-Daten exposed hat, und du betroffene User unter Artikel 34 benachrichtigst, könnten diese User ihre Rights ausüben. Sie könnten alle Informationen anfordern, die du über den Incident hältst (Right of Access), oder Details anfordern, wie ihre Daten exposed wurden.
Du musst diese Rights gegen Security-Considerations balancen. Du kannst Usern nicht den Exploit-Code des Forschers geben. Aber du musst genug Information liefern, damit sie verstehen, was passiert ist und welche Daten betroffen waren.
GDPR's Storage-Limitation-Prinzip erfordert, dass du personenbezogene Daten nur so lange behältst, wie nötig. Vulnerability-Reports enthalten oft personenbezogene Daten, inklusive Forscher-Kontaktinformationen, betroffene User-Daten in Examples und System-Informationen.
Wie lange solltest du Vulnerability-Reports behalten? Es gibt keine einzelne Antwort. Du brauchst sie lang genug, um den Fix zu verifizieren, Remediation zu tracken und potenziell gegen Legal Claims zu defendieren. Viele Organisationen behalten Reports mehrere Jahre, was generell akzeptabel ist gegeben des berechtigten Interesses, Security-Records zu maintainen.
Was mehr zählt, ist unnötige personenbezogene Daten aus Reports zu löschen. Wenn ein Forscher einen vollen Database-Dump inkludierte, wo wenige Example-Records ausreichen würden, lösche die excess Daten. Wenn Exploitation-Evidence User-Credentials inkludiert, stelle sicher, dass sie geändert werden, und entferne sie dann aus dem Report.
Vulnerability Disclosure involviert oft Cross-Border-Data-Transfers. Ein Forscher in einem Land meldet an ein Unternehmen in einem anderen. Der Report enthält Informationen über Systeme und potenziell User.
Wenn du eine EU-Organisation bist, die Reports von Forschern außerhalb der EU erhält, transferieren diese Forscher Daten zu dir. GDPR erfordert angemessene Safeguards für solche Transfers.
In der Praxis ist das selten ein Problem. Vulnerability-Reports qualifizieren typischerweise als notwendig für Security-Zwecke, was eine Derogation unter Artikel 49 ist. Aber wenn du ein Bug-Bounty-Programm betreibst, das extensive Forscher-Daten sammelt (Profile, Payment-Information, Performance-History), werden Standard-Transfer-Mechanismen wie Standard Contractual Clauses relevant.
GDPR verbietet nicht die Nutzung US-basierter Bug-Bounty-Plattformen, aber es schafft Compliance-Considerations. Nach Schrems II Privacy Shield invalidiert hat, erfordern Transfers in die USA extra Scrutiny.
Viele Organisationen haben geantwortet, indem sie erfordern, dass Vulnerability-Daten in der EU bleiben. Das schafft Demand für EU-basierte Plattformen oder Encryption-Ansätze, wo Daten nie die Kontrolle der Organisation in unencrypted Form verlassen.
Die Frage ist nicht, ob du legal eine US-Plattform nutzen kannst. Mit angemessenen Safeguards (SCCs, supplementary Measures) kannst du wahrscheinlich. Die Frage ist, ob der added Compliance-Burden und Risk es wert ist verglichen mit Alternativen.
GDPR erkennt Security als berechtigtes Interesse für Data-Processing an. Das bietet die lawful Basis für die meisten Vulnerability-Disclosure-Activities. Du kannst Daten verarbeiten, die in Vulnerability-Submissions gemeldet werden, weil du ein berechtigtes Interesse hast, deine Systeme zu sichern.
Das bedeutet nicht unlimited Processing. Du musst noch deine Interessen gegen die Rights von Data Subjects balancen und nur das verarbeiten, was nötig ist. Ein Forscher, der dir seinen Namen und Kontaktinformationen als Teil eines Vulnerability-Reports sendet, ist klar notwendig. Die Plattform, die jede Interaction speichert, die du mit diesem Forscher für Jahre hast, ist es möglicherweise nicht.
Organisationen verwechseln manchmal GDPR-Breach-Notification mit Vulnerability Disclosure. Sie sind related, aber distinct.
Breach-Notification unter Artikeln 33 und 34 geht darum, tatsächliche Data-Breaches an Behörden und betroffene Individuen zu melden. Es hat spezifische Requirements: 72-Stunden-Timeline, mandatory Information zu inkludieren und Assessment-Kriterien, wann Notification erforderlich ist.
Vulnerability Disclosure geht darum, den Prozess zu managen, wenn Security-Issues gemeldet werden, typischerweise bevor sie Breaches werden. Es ist nicht direkt von GDPR reguliert, obwohl GDPR Incentives schafft, gutes Vulnerability-Management zu haben, weil schlechtes Management zu Breaches führen kann.
Forscher haben auch GDPR-Rights. Wenn du eine Liste von Forschern maintainst, die Vulnerabilities gemeldet haben, sind das personenbezogene Daten. Forscher können Zugriff anfordern auf das, was du über sie gespeichert hast, Korrekturen anfordern oder Löschung anfordern.
Das schafft praktische Challenges. Du willst eine History maintainen, wer was gemeldet hat, für Attribution und um Repeat Contributors zu identifizieren. Aber wenn ein Forscher Löschung seiner Daten anfordert, hat GDPR keine Exception für "wir wollen Security-Records maintainen."
Dein berechtigtes Interesse, Security-Records zu maintainen, überwiegt usually das Interesse des Forschers an Löschung, aber du musst dieses Balancing demonstrieren. Dokumentiere, warum du Forscher-Daten retainst und für wie lange.
GDPR erfordert Transparenz über Data-Processing. Deine Vulnerability-Disclosure-Policy sollte erklären, welche Daten du von Forschern sammelst, wie du sie nutzt, wie lange du sie retainst und welche Rights Forscher haben.
Die meisten Organisationen tun das nicht gut. Ihre Policies fokussieren darauf, was Forscher tun sollten (attack nicht Production, exfiltriere keine Daten, etc.), aber erklären nicht, was die Organisation mit Forscher-Daten tut. Eine Privacy-Notice speziell für Forscher zu addieren, adressiert diese Gap.
Die Intersection von GDPR und Vulnerability Disclosure schafft mehrere praktische Requirements. Organisationen brauchen Vulnerability-Disclosure-Policies, die Data-Processing adressieren, sie brauchen DPAs mit Plattformen, sie brauchen dokumentierte Retention-Policies, und sie brauchen Prozesse für das Handling von Data-Subject-Requests related zu Security-Incidents.
Nichts davon macht Vulnerability Disclosure impossible oder auch nur besonders difficult. Es erfordert nur, über Privacy neben Security nachzudenken, was generell sowieso good Practice ist.
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.
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.
Get the latest security research insights and vulnerability disclosure best practices delivered to your inbox.