Responsible disclosure voor MSPs: CVD-beleid opstellen en implementeren

Responsible disclosure — ook wel Coordinated Vulnerability Disclosure (CVD) — is het proces waarbij een beveiligingsonderzoeker een ontdekte kwetsbaarheid vertrouwelijk meldt aan de eigenaar van het systeem, die daarna een afgesproken termijn krijgt om het probleem op te lossen voordat het openbaar wordt gemaakt. Het NCSC raadt alle organisaties die digitale diensten leveren aan om een CVD-beleid te hebben en publiceert richtlijnen via ncsc.nl/cvd. Voor MSPs is een CVD-beleid zowel een professionele standaard als een directe ondersteuning van de NIS2-verplichting tot kwetsbaarheidsbeheer.

Waarom responsible disclosure voor MSPs anders is dan voor andere bedrijven

Als MSP beheer je twee typen aanvalsdoelwitten tegelijk: je eigen systemen (beheerplatforms, portals, APIs) én de systemen van je klanten die jij onderhoudt. Een kwetsbaarheid in jouw RMM-platform raakt niet alleen jouw organisatie maar potentieel tientallen klantomgevingen.

Dat maakt het ontbreken van een CVD-beleid voor MSPs risicovoller dan voor een gemiddeld bedrijf. Een beveiligingsonderzoeker die een kwetsbaarheid in jouw beheerplatform ontdekt en geen meldkanaal vindt, heeft twee opties: de kwetsbaarheid verzwijgen (niet effectief voor de gemeenschap) of direct publiceren (full disclosure). Beide zijn ongunstig voor jou en je klanten.

Een CVD-beleid met een duidelijk meldkanaal geeft onderzoekers een derde optie: verantwoord melden, jou de tijd geven om te fixen, en daarna gepubliceerd worden met jouw medewerking. Dat is voor alle partijen de beste uitkomst.

De drie varianten: responsible disclosure, full disclosure en bug bounty

Responsible disclosure (Coordinated Vulnerability Disclosure)

De onderzoeker meldt de kwetsbaarheid vertrouwelijk aan de eigenaar. Er wordt een redelijke oplostermijn afgesproken — de industrie-standaard is 90 dagen, door Google Project Zero gepopulariseerd. Na die termijn mag de onderzoeker publiceren, ongeacht of het probleem is opgelost. Dit creëert een gezonde druk: organisaties die niet reageren of treuzelen met een fix, riskeren publieke exposure.

Responsible disclosure is de aanbevolen aanpak door het NCSC, ENISA (het Europese cybersecurity-agentschap) en de meeste grote tech-bedrijven. Het balanceert het belang van de onderzoeker (erkenning voor het werk), het belang van de organisatie (tijd om te fixen) en het publieke belang (kwetsbaarheid wordt uiteindelijk bekendgemaakt).

Full disclosure

De onderzoeker maakt de kwetsbaarheid onmiddellijk publiek, zonder de organisatie vooraf te informeren. Dit was gangbaar in de vroege jaren van de beveiligingsresearch maar is nu sterk teruggedrongen. Full disclosure geeft aanvallers direct de mogelijkheid de kwetsbaarheid te misbruiken voordat een fix beschikbaar is. Organisaties zonder CVD-beleid lopen een verhoogd risico op full disclosure door onderzoekers die geen andere weg zien.

Bug bounty

Een variant waarbij organisaties financiële vergoedingen uitkeren voor geldige kwetsbaarheidsmeldingen. Voor grote techbedrijven (Google, Microsoft, Meta) zijn bug bounty programma’s standaard met vergoedingen van duizenden tot honderdduizenden dollars per kwetsbaarheid. Voor de meeste MSPs is een formeel bug bounty programma te kostbaar en operationeel complex. Een responsible disclosure beleid zonder financiële vergoeding — maar met erkennig en een Hall of Fame — is voor MSPs de praktisch haalbare keuze.

CVD en NIS2: de formele koppeling

Artikel 21 van de NIS2-richtlijn verplicht organisaties tot kwetsbaarheidsbeheer. Een CVD-beleid is de formele ingang voor externe meldingen van kwetsbaarheden — aanvulling op de interne kwetsbaarheidsscanning en het patchproces.

De ENISA-richtlijnen voor NIS2-implementatie noemen CVD expliciet als aanbevolen maatregel voor de invulling van de kwetsbaarheidsbeheerverplichting. ENISA heeft ook een gecoördineerde Europese CVD-policy gepubliceerd (ENISA Good Practice Guide on Vulnerability Disclosure) die als referentie dient.

Praktisch betekent dit: als een NIS2-auditor vraagt hoe je omgaat met extern gemelde kwetsbaarheden, is een gepubliceerd CVD-beleid met een functionerend meldkanaal het antwoord.

Een CVD-beleid opstellen: de zes essentiële elementen

1. Scope: welke systemen vallen eronder?

Definieer helder welke systemen en diensten zijn opgenomen in je CVD-beleid. Wees specifiek: “alle systemen en diensten die eigendom zijn van of worden beheerd door [MSP-naam], inclusief onze beheerplatforms, klantportals, APIs en publiek toegankelijke webdiensten.”

Overweeg ook systemen van klanten expliciet buiten scope te plaatsen als je niet de eigenaar bent. Voor kwetsbaarheden in klantomgevingen kunnen onderzoekers direct de klant benaderen.

2. Meldkanaal: hoe kunnen ze melden?

Stel een dedicated meldkanaal in:

• E-mail: [email protected] of [email protected] (meest laagdrempelig)
• Webformulier: voor gestructureerde aanlevering van informatie
• Optioneel: PGP-encryptie voor versleutelde communicatie over gevoelige kwetsbaarheden

Publiceer het meldkanaal op een stabiele URL: jouwbedrijf.nl/security of jouwbedrijf.nl/responsible-disclosure.

3. Verwachte reactietijden

Geef onderzoekers duidelijkheid over wanneer ze wat kunnen verwachten:

4. Oplostermijn en publicatiemoment

Definieer de termijn waarbinnen je de kwetsbaarheid wilt oplossen. De industrie-standaard is 90 dagen. Voor kritieke kwetsbaarheden (CVSS ≥ 9.0) is 7-14 dagen meer passend. Geef aan wat er gebeurt als de termijn niet wordt gehaald: verleng je in overleg, of mag de onderzoeker publiceren?

Een redelijke aanpak: bij actief werken aan een fix kun je in overleg de termijn verlengen, maar communiceer dit proactief naar de onderzoeker.

5. Juridische bescherming: de veilige haven

Dit is het meest kritieke element. Onderzoekers die kwetsbaarheden melden, zijn kwetsbaar voor strafrechtelijke vervolging onder de Wet Computercriminaliteit — ook als ze te goeder trouw handelen. Jouw CVD-beleid moet expliciet een “veilige haven” bieden:

“Wij ondernemen geen juridische stappen tegen personen die kwetsbaarheden melden conform dit beleid, als zij: handelen te goeder trouw, geen onnodige schade aanrichten, geen gegevens stelen of vernietigen, de kwetsbaarheid niet publiek maken vóór de afgesproken termijn, en de kwetsbaarheid alleen aan ons melden.”

Dit is geen juridisch waterdichte bescherming — alleen het Openbaar Ministerie kan vervolging initiëren — maar het geeft onderzoekers de zekerheid dat jij als organisatie geen aangifte doet als zij zich aan de regels houden.

6. Erkenning: hoe bedank je de melder?

Onderzoekers die kwetsbaarheden melden, verdienen erkenning. Financiële beloning is niet verplicht voor een CVD-beleid (dat is bug bounty). Maar erkenning is essentieel:

• Vermelding op een “Hall of Fame” pagina op je website (met toestemming van de onderzoeker)
• Persoonlijk bedankbericht
• Optioneel: een kleine blijk van waardering (merchandise, Amazon-voucher)

Hall of Fame’s zijn effectief: ze motiveren onderzoekers om te melden in plaats van te verzwijgen of publiek te maken.

Het security.txt bestand: de technische standaard

Naast een CVD-beleidspagina is een security.txt bestand de technische standaard voor het communiceren van je meldkanaal. RFC 9116 specificeert dit bestand — het is vergelijkbaar met robots.txt maar voor beveiligingsonderzoekers.

Plaats het bestand op: https://jouwdomein.nl/.well-known/security.txt

Minimale inhoud:

Contact: mailto:[email protected]
Expires: 2027-05-01T00:00:00.000Z
Policy: https://jouwbedrijf.nl/responsible-disclosure
Preferred-Languages: nl, en

Genereer het bestand via securitytxt.org — het duurt twee minuten en is automatisch door beveiligingstools en onderzoekers vindbaar. Veel geautomatiseerde vulnerability scanners controleren op security.txt als eerste stap bij het zoeken naar een meldkanaal.

Omgaan met een kwetsbaarheidmelding: de praktijk

Een melding ontvangen is het begin van een proces, niet het einde. Zo handel je professioneel:

Stap 1 — Bevestig ontvangst (binnen 48 uur): stuur een persoonlijke e-mail (geen automatisch template) die bevestigt dat je de melding hebt ontvangen, een ticketnummer geeft, en aangeeft wanneer je een inhoudelijke reactie kunt verwachten.

Stap 2 — Beoordeel de kwetsbaarheid (binnen 5 werkdagen): analyseer de melding: is het een echte kwetsbaarheid? Wat is het risico? Wat is de CVSS-score? Informeer de onderzoeker over je bevinding.

Stap 3 — Werk aan de fix en communiceer proactief: houd de onderzoeker tweewekelijks op de hoogte van de voortgang. Niets is meer frustrerend voor een onderzoeker dan in het ongewisse te worden gelaten. Proactieve communicatie voorkomt dat onderzoekers het gevoel krijgen dat ze worden genegeerd en overstappen naar full disclosure.

Stap 4 — Deploy de fix en verifieer: roll de fix uit en verifieer dat de kwetsbaarheid daadwerkelijk is gedicht. Informeer de onderzoeker.

Stap 5 — Coördineer publicatie: bespreek met de onderzoeker wanneer en hoe ze publiceren. Bied aan om samen een advisory te schrijven. Bedank hen publiekelijk (als ze dat willen).

Veelgestelde vragen over responsible disclosure

Zijn we verplicht een CVD-beleid te hebben?
Wettelijk niet direct voor alle MSPs, maar het NCSC raadt het aan voor alle organisaties die digitale diensten leveren. Klanten in NIS2-plichtige sectoren verwachten het steeds vaker als onderdeel van vendor due diligence. En zonder CVD-beleid vergroot je het risico op full disclosure bij een gevonden kwetsbaarheid.

Wat als een onderzoeker dreigt direct te publiceren?
Reageer snel, professioneel en constructief. Bevestig de kwetsbaarheid als die geldig is, geef een realistische oplostermijn, en houd de onderzoeker op de hoogte. De meeste onderzoekers die dreigen te publiceren, doen dit omdat ze het gevoel hebben genegeerd te worden. Proactieve communicatie lost dit doorgaans op. Escaleer naar juridisch advies alleen als de onderzoeker aantoonbaar te kwader trouw handelt (data steelt, systemen beschadigt).

Hoe gaan we om met kwetsbaarheden in klantomgevingen die via ons worden gemeld?
Als de onderzoeker een kwetsbaarheid meldt in een klantomgeving die jij beheert, informeer de klant direct en coördineer de fix. Je CVD-beleid hoeft geen kwetsbaarheden in klantomgevingen te dekken — die zijn eigendom van de klant. Maar professioneel doorsturen en coördineren is de juiste handelwijze.

Moet de melder geanonimiseerd worden in de Hall of Fame?
Altijd vragen aan de melder wat hun voorkeur is. Sommige onderzoekers willen juist publieke erkenning (bij hun naam of alias), anderen willen volledig anoniem blijven. Respecteer die keuze altijd.

Hoe beschermt CVD ons juridisch?
CVD beschermt jou als organisatie doordat je aantoonbaar te goeder trouw handelt: je hebt een meldkanaal, je reageert professioneel, je lost kwetsbaarheden op. Als een onderzoeker buiten de afgesproken regels handelt (data steelt, systemen beschadigt), heb je dankzij de documentatie van de meldprocedure een sterke positie als je aangifte wilt doen.