Wat is Responsible Disclosure?
Responsible Disclosure is een beleid en proces waarmee ethische hackers, onderzoekers en leveranciers een gevonden kwetsbaarheid vertrouwelijk melden aan de eigenaar of fabrikant van een systeem, zodat die het lek kan dichten voordat de details openbaar worden. Tegenwoordig heet dezelfde aanpak meestal Coordinated Vulnerability Disclosure (CVD): het NCSC verving in 2018 zijn eerdere leidraad voor responsible disclosure uit 2013 door de Leidraad Coordinated Vulnerability Disclosure. Het woord “gecoördineerd” benadrukt dat melder en organisatie samen bepalen wanneer en hoe er wordt gepubliceerd. Voor OT- en ICS-omgevingen is CVD extra belangrijk, omdat patches daar maanden of jaren op zich laten wachten.
🎯 Waarom is Responsible Disclosure belangrijk?
Geen organisatie vindt al haar eigen fouten. Externe onderzoekers vergroten het bereik van uw beveiligingsmonitoring, maar alleen als ze weten waar ze terechtkunnen en niet bang hoeven te zijn voor juridische gevolgen.
| Voordeel | Uitleg |
|---|---|
| Snelle detectie | Externe melders vinden kwetsbaarheden die interne tests en een pentest missen |
| Gecoördineerde mitigatie | U krijgt tijd om te patchen of maatregelen te nemen vóór openbaarmaking |
| Minder risico op full disclosure | Een melder zonder kanaal publiceert eerder direct, of verkoopt het lek |
| Relatie met de community | Toont openheid en samenwerking met ethische hackers |
| Compliance en reputatie | NIS2, de Cyber Resilience Act en IEC 62443-4-1 (onderdeel van de IEC 62443-reeks) vragen om een vorm van CVD |
Het alternatief is weinig aantrekkelijk. Bij full disclosure publiceert de onderzoeker alles meteen, waardoor aanvallers en verdedigers tegelijk beginnen. Bij non-disclosure blijft het lek onbekend of komt het via exploitmakelaars bij aanvallers terecht als zero-day.
🔄 Wat is het verschil tussen responsible, coordinated en full disclosure?
| Model | Wie bepaalt de publicatie? | Typische termijn | Risico |
|---|---|---|---|
| Responsible disclosure | De organisatie, de melder wacht op de oplossing | Vaak 60–90 dagen | Organisatie kan het proces eindeloos rekken |
| Coordinated vulnerability disclosure | Melder en organisatie in overleg, eventueel met een coördinator | Afgesproken deadline, met verlenging bij complexe fixes | Vraagt vertrouwen en goede communicatie |
| Full disclosure | De melder, direct en volledig | Geen | Aanvallers krijgen een voorsprong |
| Bug bounty | Platform of organisatie, met financiële beloning | Volgens programmaregels | Melders kunnen gebonden zijn aan geheimhouding |
Bekende onderzoeksteams hanteren vaste termijnen. Google Project Zero publiceert na 90 dagen, met 30 extra dagen voor gebruikers om de patch te installeren. CERT/CC gaat uit van 45 dagen en het Zero Day Initiative van 120 dagen. Het Nederlandse NCSC bevestigt een melding binnen één werkdag, geeft binnen drie werkdagen een eerste beoordeling en streeft naar een oplossing binnen 60 dagen.
🛠️ Wat hoort er in een Responsible Disclosure-beleid?
| Onderdeel | Beschrijving |
|---|---|
| Contactkanaal | Een vast e-mailadres of formulier, bij voorkeur met PGP-sleutel voor versleutelde meldingen |
| Scope | Welke systemen en domeinen onderzocht mogen worden, en welke uitdrukkelijk niet |
| Spelregels | Geen data downloaden of wijzigen, geen DoS, geen social engineering, niet verder gaan dan nodig |
| Juridische toezegging | De organisatie doet geen aangifte als de melder zich aan de regels houdt |
| Termijnen | Ontvangstbevestiging, eerste beoordeling en streeftermijn voor de oplossing (bijvoorbeeld 90 dagen) |
| Publicatie | Of en wanneer de melder mag publiceren, en of de organisatie een advisory of CVE uitgeeft |
| Beloning of erkenning | Optioneel: vermelding in een hall of fame, een attentie of een bug bounty |
Let op: een organisatie kan geen strafrechtelijke vrijwaring geven. Alleen het Openbaar Ministerie beslist over vervolging. Een organisatie kan wel beloven geen aangifte te doen.
Maak het beleid vindbaar via een security.txt-bestand. Volgens RFC 9116 (2022) staat dat
op /.well-known/security.txt, wordt het via HTTPS geserveerd en bevat het minimaal de velden
Contact en Expires. De vervaldatum ligt bij voorkeur minder dan een jaar in de
toekomst, zodat er geen verouderde contactgegevens blijven staan.
⚙️ Hoe pakt u Responsible Disclosure aan in een OT-omgeving?
In de OT-wereld is een onschuldige scan al riskant: een fragiele PLC kan crashen op onverwacht netwerkverkeer. Het beleid moet daarom strenger afbakenen dan in de IT.
- ✅ Wel in scope - publieke webportalen, remote-access-gateways, testomgevingen en informatie die toevallig openbaar blijkt (bijvoorbeeld via internetblootstelling)
- ✅ Wel in scope - fouten in firmware of software van leveranciers, gemeld aan de leverancier zelf
- ❌ Niet in scope - actieve tests, brute force of exploits op live SCADA- en PLC-systemen
- ❌ Niet in scope - fysieke toegang tot productielocaties of bediening van installaties
Een praktische aanpak in vijf stappen:
- Rollen vastleggen - wijs een eigenaar aan, koppel meldingen aan uw CSIRT of incidentteam en betrek de OT-verantwoordelijke bij elke OT-melding.
- Beleid en security.txt publiceren - met een expliciete OT-uitsluiting voor productiesystemen.
- Triage - beoordeel ernst met CVSS, controleer of het lek al op de KEV-lijst staat en bepaal welke installaties geraakt zijn.
- Mitigeren - omdat een OT-patch vaak pas tijdens een geplande stop kan, zijn tijdelijke maatregelen zoals segmentatie of firewallregels belangrijk; leg alles vast in uw kwetsbaarheidsbeheer en patchmanagement.
- Afsluiten en publiceren - informeer de melder, publiceer eventueel een advisory en evalueer het proces.
Gaat het lek over een product, dan hoort de melding bij de leverancier. Grote OT-fabrikanten hebben een eigen PSIRT; Siemens ProductCERT publiceert zijn advisories bijvoorbeeld op de tweede dinsdag van de maand. Machineleesbare advisories in het CSAF-formaat en een SBOM helpen asset owners om snel te zien of zij geraakt zijn. In de VS coördineert CISA CVD voor industriële besturingssystemen en publiceert het ICS-advisories.
🔐 Welke wetten en normen zijn relevant?
| Regelgeving / norm | Relatie met Responsible Disclosure |
|---|---|
| NIS2 / Cyberbeveiligingswet | Art. 21 noemt “behandeling en bekendmaking van kwetsbaarheden” als zorgplicht; art. 12 laat elke lidstaat een CSIRT als CVD-coördinator aanwijzen, bij wie u desgewenst anoniem kunt melden |
| Cyber Resilience Act | Fabrikanten moeten een CVD-beleid en een contactadres hebben (bijlage I, deel II, punten 5 en 6); volledig van toepassing vanaf 11 december 2027 |
| CRA-meldplicht | Actief misbruikte kwetsbaarheden melden via het Single Reporting Platform van ENISA, vanaf 11 september 2026 |
| ISO 27001 & ISO 27002 | Beheersmaatregel 8.8: beheer van technische kwetsbaarheden, inclusief meldingen van buiten |
| ISO/IEC 29147 en 30111 | Internationale normen voor het openbaar maken (29147) en intern afhandelen (30111) van kwetsbaarheden |
| IEC 62443-4-1 | De praktijk defect management eist dat leveranciers meldingen van beveiligingsproblemen ontvangen, beoordelen en bekendmaken |
| IEC 62443-2-1 | Beveiligingsprogramma van de asset owner, waarin kwetsbaarheids- en patchbeheer passen |
In Nederland vervult het NCSC de rol van CVD-coördinator. Het behandelt meldingen over systemen van de Rijksoverheid en coördineert kwetsbaarheden die meerdere organisaties of leveranciers raken. Voor andere systemen meldt u eerst bij de eigenaar en schakelt u het NCSC in als u geen adequate reactie krijgt. Daarnaast meldt de vrijwilligersorganisatie DIVD (Dutch Institute for Vulnerability Disclosure) kwetsbare systemen op internet aan hun eigenaren.
Rapportages zoals ISAE 3402 gaan over beheersmaatregelen van dienstverleners. Ze kunnen laten zien dat een leverancier kwetsbaarheden beheerst, maar vervangen geen CVD-beleid.
⚖️ Is ethisch hacken in Nederland strafbaar?
Binnendringen in een systeem zonder toestemming is computervredebreuk (artikel 138ab van het Wetboek van Strafrecht), ook met goede bedoelingen. Het Openbaar Ministerie legde in de beleidsbrief ethisch hacken van 14 december 2020 vast hoe het met melders omgaat. Meldt een ethisch hacker een gevonden kwetsbaarheid volgens het CVD-beleid van de organisatie of de NCSC-leidraad, dan stelt het OM in principe geen strafrechtelijk onderzoek in. Het OM toetst drie criteria:
- Maatschappelijk belang - handelde de hacker in een zwaarwegend algemeen belang?
- Proportionaliteit - ging de hacker niet verder dan nodig om het lek aan te tonen?
- Subsidiariteit - waren er geen minder ingrijpende manieren om hetzelfde doel te bereiken?
Heeft een organisatie geen CVD-beleid en doet zij toch aangifte, dan is dat voor het OM geen reden om de melder direct als verdachte aan te merken. Wel kan een onderzoek volgen naar de vraag of het om ethisch hacken ging, waarbij de bijdrage van CVD aan een veilige digitale samenleving zwaar weegt. Een eigen logboek van alle stappen helpt een melder om achteraf aan te tonen dat hij proportioneel handelde.
✅ Waar moeten ethische hackers en melders op letten?
- Lees eerst het beleid - van de organisatie, of anders de NCSC-leidraad
- Blijf binnen de regels - geen data meenemen, niets wijzigen, geen productiesystemen verstoren
- Misbruik niets - gebruik een gevonden kwetsbaarheid niet verder dan nodig om haar aan te tonen
- Meld volledig - geef genoeg technische details om het lek te reproduceren
- Gebruik officiële kanalen - en houd de melding vertrouwelijk tot de afgesproken publicatie
- Wees geduldig - vooral bij OT-kwetsbaarheden vraagt coördinatie tussen leverancier en gebruikers tijd
Organisaties doen er ook goed aan extern mee te kijken: meldingen over gelekte gegevens kunnen ook via darknet-monitoring of leakdetectie binnenkomen. Een eigen red team en security by design verkleinen het aantal meldingen dat überhaupt nodig is.
❓ Veelgestelde vragen
Is Responsible Disclosure hetzelfde als Coordinated Vulnerability Disclosure?
In de praktijk wel: beide gaan over het vertrouwelijk melden van een kwetsbaarheid zodat die kan worden verholpen vóór publicatie. Coordinated Vulnerability Disclosure (CVD) legt meer nadruk op gelijkwaardig overleg tussen melder en organisatie. Het NCSC gebruikt sinds 2018 de term CVD.
Moet mijn organisatie een Responsible Disclosure-beleid hebben?
Voor fabrikanten van producten met digitale elementen eist de Cyber Resilience Act vanaf 11 december 2027 een CVD-beleid. Organisaties onder NIS2 en de Cyberbeveiligingswet moeten kwetsbaarheden behandelen en bekendmaken als onderdeel van hun zorgplicht. Ook zonder plicht is een Responsible Disclosure-beleid een goedkope maatregel die meldingen in goede banen leidt.
Wat is een security.txt-bestand?
Een security.txt-bestand is een tekstbestand op /.well-known/security.txt dat volgens RFC
9116 aangeeft hoe u beveiligingsproblemen meldt. De velden Contact en Expires
zijn verplicht; een verwijzing naar het Responsible Disclosure-beleid via Policy is optioneel
maar gebruikelijk.
Hoe lang krijgt een organisatie om een kwetsbaarheid te verhelpen?
Gangbaar is 60 tot 90 dagen: het NCSC streeft naar 60 dagen, Google Project Zero hanteert 90 dagen. Bij OT-producten wordt vaak langer gecoördineerd, omdat leveranciers en asset owners patches moeten testen en uitrollen tijdens geplande stops.
Is een bug bounty hetzelfde als Responsible Disclosure?
Nee, een bug bounty is een Responsible Disclosure-programma met een financiële beloning per geldige melding, vaak via een platform zoals HackerOne of Intigriti. Exploitmakelaars zoals ZERODIUM zijn juist het tegenovergestelde: zij kopen kwetsbaarheden om ze door te verkopen, niet om ze te laten verhelpen.
Waar meld ik een kwetsbaarheid in een industrieel product?
Meld een kwetsbaarheid in een industrieel product eerst bij de PSIRT van de fabrikant, via diens security.txt of beveiligingspagina. Reageert de fabrikant niet of raakt het lek meerdere leveranciers, dan kunt u het NCSC als coördinator inschakelen; in de VS vervult CISA die rol.
📌 Samengevat
Responsible Disclosure geeft ethische hackers een veilige, legale route om kwetsbaarheden te melden en geeft organisaties tijd om ze te verhelpen voordat aanvallers ze misbruiken.
Een goed beleid noemt een contactkanaal, scope, spelregels, termijnen en publicatieafspraken, en is vindbaar via security.txt. NIS2, de Cyberbeveiligingswet, de Cyber Resilience Act en IEC 62443-4-1 maken CVD steeds meer een verplichting. In OT-omgevingen vraagt het extra zorg: sluit live productiesystemen uit van actief onderzoek en overbrug de tijd tot de patch met tijdelijke maatregelen.