Coordinated vulnerability disclosure

Gecoördineerde kwetsbaarheidsmelding (CVD)

Hoe je beveiligingskwetsbaarheden meldt, ontvangt en coördineert, met voorbeeldbeleid.

Gecoördineerde kwetsbaarheidsmelding (Coordinated vulnerability disclosure, CVD) is een term uit de computerbeveiliging. Het beschrijft hoe mensen meldingen over beveiligingsproblemen kunnen delen. Voorbeelden zijn bugmeldingen, inbraakrisico's, hackwaarschuwingen, datalekken, inbreuken op websites enzovoort.

Vertalingen: العربية, Български, বাংলা, Čeština, Cymraeg, Dansk, Deutsch, Ελληνικά, English, Español, Eesti, Euskara, فارسی, Suomi, Français, Gaeilge, Gàidhlig, ગુજરાતી, Hausa, עברית, हिन्दी, Hrvatski, Magyar, Bahasa Indonesia, Íslenska, Italiano, 日本語, 한국어, Lietuvių, Latviešu, Nederlands, Polski, Português, Română, Русский, Slovenčina, Slovenščina, Svenska, Kiswahili, ไทย, Türkçe, Українська, اردو, Tiếng Việt, 中文

Inhoud:

Beleid:

Inleiding

Dit document legt gecoördineerde kwetsbaarheidsmelding uit op manieren die mensen kunnen helpen samen te werken.

Doelen van het document:

  1. Mensen helpen die beveiligingsproblemen ontdekken en die willen melden.

  2. Vertegenwoordigers van bedrijven helpen de behoeften, doelen, werkwijzen en bijzondere gevallen van verantwoorde melding te begrijpen.

  3. Voorbeelden van beleid voor gecoördineerde kwetsbaarheidsmelding opnemen in de map van de repository.

We verwelkomen pull requests, GitHub-issues of e-mail naar security@joelparkerhenderson.com.

Wat is gecoördineerde kwetsbaarheidsmelding?

Gecoördineerde kwetsbaarheidsmelding beschrijft drie stappen wanneer iemand een beveiligingsprobleem ontdekt (zoals een softwarebug) en dit wil melden aan de producent (zoals het bedrijf dat de software maakt).

Stappen:

  1. De ontdekker meldt het probleem privé en te goeder trouw aan de producent.

  2. De producent probeert te goeder trouw de gebruikers te beschermen en het probleem aan te pakken.

  3. Na een afgesproken tijd wordt het beveiligingsprobleem openbaar gemaakt.

Stap 1: Meld het probleem

Stap 1 is voor de ontdekker: meld het probleem privé en te goeder trouw.

  • Goed: De ontdekker stuurt de relevante informatie naar de producent, bijvoorbeeld per e-mail naar het beveiligingsadres van de producent (meestal "security@example.com") of via een webformulier op de website van de producent (meestal "https://www.example.com/security").

  • Slecht: de melding op een openbare blog plaatsen, of de media waarschuwen, of dreigen, of proberen het beveiligingsprobleem aan hackers te verkopen enzovoort.

  • Tip: de ontdekker kan ervoor kiezen anoniem te blijven; de producent kan er ook voor kiezen anoniem te blijven.

Blijf desgewenst op de hoogte van het probleem.

  • Goed: communicatielijnen openen, of vervolginformatie geven, of de situatie in de gaten houden.

  • Slecht: het probleem vergeten.

  • Tip: de ontdekker kan kiezen om te helpen of niet, en ook om in contact te blijven of niet, en ook om de afspraak te wijzigen als de omstandigheden veranderen.

Maak het probleem desgewenst bekend aan anderen.

  • Goed: de afgesproken tijd afwachten en dan naar buiten treden, bijvoorbeeld door de relevante informatie te plaatsen op een beveiligingsnieuwssite, of contact op te nemen met relevante beveiligingsonderzoekers van derden, of het probleem aan te kondigen op een openbare sociale site enzovoort.

  • Slecht: het probleem niet bekendmaken aan anderen, tenzij je denkt dat het meer dan evenredig risico zou opleveren voor jezelf of anderen.

  • Tip: als de omstandigheden veranderen, bijvoorbeeld door de ontdekking van een hoger risico of een actieve exploit in het wild (active exploit in the wild), kan de ontdekker het probleem eerder aan anderen bekendmaken.

Stap 2: Zorg voor contactmogelijkheden

Stap 2 is voor de producent: zorg ervoor dat de contactmogelijkheden werken.

  • Goed: De producent publiceert een e-mailadres voor beveiligingscontact (conventioneel "security@example.com") en bij voorkeur een veilige sleutel voor e-mailversleuteling.

  • Goed: De producent publiceert een webpagina voor beveiligingscontact (conventioneel "https://www.example.com/security") en maakt de pagina bij voorkeur gemakkelijk vindbaar, bijvoorbeeld via de footer van de website, de sitemap en zoekfunctie.

  • Slecht: De producent biedt geen e-mailadres of webpagina, of maakt ze niet gemakkelijk vindbaar.

Zorg voor bekwaam personeel.

  • Goed: De producent leert medewerkers van de klantenservice wat ze moeten doen als ze een beveiligingsvraag ontvangen, bijvoorbeeld hoe ze moeten antwoorden met contactgegevens, of hoe ze de vraag moeten doorsturen naar het juiste interne team.

  • Goed: De producent controleert regelmatig of de bekwaamheid van het personeel werkt.

  • Slecht: De producent traint niet of controleert niet.

Reageer binnen de termijn op de ontdekker.

  • Als de ontdekker geen termijn opgeeft, hanteer dan één werkdag, omdat dit de industriestandaard is en de huidige beste praktijk in de sector.

  • Als de ontdekker vragen stelt, beantwoord ze dan. Dit is vooral belangrijk als de ontdekker toestemming vraagt om te testen. Zorg ervoor dat alle antwoorden duidelijk en direct zijn.

Reageer op de ontdekker via een bevoegd beveiligingscontact en/of een bevoegd beveiligingsproces.

  • Goed: een antwoord van een specifiek beveiligingsadres, zoals "security@example.com".

  • Voorbeeld van wat slecht is: een antwoord van een algemeen e-mailadres, zoals "help@example.com", of van iemand die geen bevoegde beveiligingsprofessional is.

Laat de ontdekker weten dat het probleem is herkend als een beveiligingsmelding.

  • Goed: beveiligingsspecifieke bewoordingen, zoals "Ons beveiligingsteam heeft uw melding van verantwoorde openbaarmaking ontvangen", of "Ons beveiligingsproces kent deze volgende stappen", of "Uw gegevens staan nu in onze beveiligingstracker met idnummer XYZ" enzovoort.

  • Slecht: algemene bewoordingen, zoals "Wij waarderen uw zaken", of "Wij nemen beveiliging serieus", of de bal doorspelende bewoordingen zoals "We hebben uw e-mail naar een andere afdeling gestuurd" enzovoort.

Stap 3: Werk te goeder trouw

Stap 3 is voor de ontdekker en de producent samen: werk te goeder trouw.

Begrijp dat gecoördineerde kwetsbaarheidsmelding een proces te goeder trouw beschrijft.

  • Doel nr. 1 is te goeder trouw gebruikers helpen zichzelf te beschermen tegen beveiligingsrisico's.

  • Doel nr. 2 is te goeder trouw het beveiligingsprobleem aan te pakken.

  • De ontdekker en/of producent kunnen te goeder trouw besluiten andere beveiligingsmensen te betrekken, bijvoorbeeld door contact op te nemen met andere relevante beveiligingsonderzoekers om met het probleem te helpen.

Begrijp dat gecoördineerde kwetsbaarheidsmelding geen verplichting schept.

  • De ontdekker en/of producent kunnen op elk moment, om welke reden dan ook, met of zonder waarschuwing afhaken. Het is beleefd om alle betrokkenen op de hoogte te houden, maar dit is niet altijd mogelijk, praktisch of wenselijk.

  • Gecoördineerde kwetsbaarheidsmelding schept geen juridische overeenkomst. Als de ontdekker en de producent al een juridische overeenkomst hebben, stellen we voor dat alle betrokkenen de juiste juristen raadplegen; gebruik dit document niet als juridisch advies.

Begrijp dat gecoördineerde kwetsbaarheidsmelding streeft naar goede communicatie en naar het afwijzen van bedreigingen.

  • Gecoördineerde kwetsbaarheidsmelding werkt het best wanneer alle betrokkenen begrijpen dat doel nr. 1 is gebruikers te helpen zichzelf te beschermen tegen beveiligingsrisico's, en doel nr. 2 is het beveiligingsprobleem aan te pakken.

  • Gecoördineerde kwetsbaarheidsmelding wijst elke vorm van bedreiging met vergelding, intimidatie, schorsing, intrekking, afpersing, last van opvolging of het de schuld geven aan het slachtoffer af.

Begrijp dat gecoördineerde kwetsbaarheidsmelding voor verschillende mensen iets anders kan betekenen.

  • De ontdekker en producent kunnen een verschillend begrip hebben van gecoördineerde kwetsbaarheidsmelding. Deze opvattingen komen mogelijk niet overeen. Te goeder trouw houdt in dat alle betrokkenen dit begrijpen.

  • Sommige producenten publiceren beleid voor gecoördineerde kwetsbaarheidsmelding. Dit kan nuttige richtlijnen bieden. Als een ontdekker ervoor kiest een andere vorm van gecoördineerde kwetsbaarheidsmelding te gebruiken, of een ander begrip heeft van verantwoorde melding, is dat absoluut prima.

Begrijp dat de ontdekker doorgaans de uitgever een gunst bewijst.

  • Doorgaans heeft de ontdekker niemands toestemming nodig om kwetsbaarheden te publiceren.

  • Doorgaans helpt de informatie van de ontdekker de uitgever.

Controleer het succes

Nadat het probleem is opgelost, moet de producent het succes controleren.

  • Hebben alle mensen en processen de melding succesvol afgehandeld? Zo ja, goed. Zo niet, overweeg dan nader onderzoek achteraf, zoals oorzaakanalyse (RCA), post-mortemrapporten, Ishikawa-diagrammen of causale analyse op basis van systeemtheorie (CAST).

  • Zijn eventuele openstaande kwesties getrieerd en worden ze bijgehouden?

  • Begrijpen zowel de producent als de ontdekker wat te doen bij eventuele vervolgstappen? Dit is vooral belangrijk om goed te doen voor het geval er nog vervolgmeldingen van gecoördineerde kwetsbaarheden kunnen komen.

Richtlijnen

Richtlijnen voor gecoördineerde kwetsbaarheidsmelding kunnen uit veel hoeken komen, zoals ethiekdeskundigen, juridische pleitbezorgers, de redelijke verwachtingen van het grote publiek enzovoort.

Als je richtlijnen zoekt, zijn deze drie gebieden misschien interessant voor je, alle hieronder beschreven.

  • Barmhartige Samaritaan

  • Reddingsplicht

  • Zorgplicht

Barmhartige Samaritaan

Wikipedia: Wet van de barmhartige Samaritaan

Wetten van de barmhartige Samaritaan (Good Samaritan laws) bieden wettelijke bescherming aan mensen die redelijke hulp verlenen aan degenen die gewond, ziek of in nood zijn of anderszins niet in staat zijn te handelen, of waarvan zij dat geloven. De bescherming is bedoeld om de aarzeling van omstanders om te helpen te verminderen, uit angst om te worden aangeklaagd of vervolgd.

Reddingsplicht

Wikipedia: Reddingsplicht

Een reddingsplicht is een concept dat een omstandigheid beschrijft waarin een partij aansprakelijk kan worden gehouden voor het nalaten een andere partij in nood te hulp te komen. Een reddingsplicht kan morele en/of juridische aspecten hebben.

Zorgplicht

Wikipedia: Zorgplicht

Een zorgplicht is de verplichting tot een norm van redelijke zorgvuldigheid bij het verrichten van handelingen die voorzienbaar anderen kunnen schaden. Een zorgplicht kan morele en/of juridische aspecten hebben. Enkele aspecten om te overwegen zijn: de voorzienbaarheid van de schade of het letsel, de mogelijke omvang van de potentiële schade of het potentiële letsel, het belang of de maatschappelijke waarde van de activiteit waarmee de gedaagde bezig was, het nut van het handelen voor de gedaagde, de haalbaarheid van alternatief handelen, de kosten en lasten van het alternatieve handelen, het relatieve nut van het alternatieve handelen en de relatieve veiligheid van het alternatieve handelen.

Bijzondere gevallen

Onze beveiligingsteams hebben een breed scala aan bijzondere gevallen gezien.

We beschrijven ze hier om mensen te helpen begrijpen waar een breed scala aan meningen bestaat over wat wel en niet in orde is. We raden aan dat alle betrokkenen hierover te goeder trouw communiceren.

Toegang tot informatie van andere gebruikers

Voorbeeld: je ontdekt dat een URL jouw gebruikers-id bevat, en een bug onthult, en je denkt dat je de URL kunt aanpassen om je gebruikers-id te veranderen in een ander gebruikers-id.

  • Is het in orde dat de ontdekker dit doet, bijvoorbeeld met als enig doel te ontdekken of het ook andere gebruikers raakt?

  • Is het belangrijker om snel de omvang van het risico voor alle gebruikers te begrijpen dan om een paar gebruikers te beschermen van wie de gegevens mogelijk al zichtbaar zijn voor hackers?

  • Is het in orde dat de ontdekker dit doet met zoveel gebruikers als hij of zij wil?

  • Is het in orde dat de ontdekker probeert contact op te nemen met gebruikers om te laten weten dat ze getroffen zijn? Is het in orde om suggesties voor beperking van de gevolgen te doen?

Denial of service

Voorbeeld: je ontdekt een bug die per ongeluk je account blokkeert, bijvoorbeeld door een wachtwoordblokkade te activeren.

  • Wordt dit beschouwd als een denial-of-serviceaanval?

Ongevraagde e-mail

Voorbeeld: je probeert een beveiligingsprobleem te melden aan mensen in het bedrijf die volgens jou relevant zijn, en die je vindt door onderzoek op LinkedIn, Facebook enzovoort, of door naamconventies te gebruiken zoals "webmaster@example.com" of "security@example.com".

  • Is dit in orde?

  • Wordt dit beschouwd als ongevraagde e-mail (unsolicited email)?

  • Wordt dit beschouwd als onbevoegde e-mail (unauthorized email)?

Uitgesloten groepen

Voorbeeld: je behoort tot een uitgesloten groep, zoals minderjarig zijn, of op een sanctielijst staan, of in een land zijn dat op een sanctielijst staat.

  • Is het in orde dat je een melding doet?

  • Is het in orde om anoniem te melden?

  • Is het in orde om opzettelijk mogelijk identificerende informatie te veranderen, bijvoorbeeld om aan de uitgesloten groep te ontsnappen, en met als doel de melding de juiste mensen te laten bereiken?

Derde partij

Voorbeeld: je ontdekt dat de software van een bedrijf een bug heeft waarbij een derde partij betrokken is, zoals een integratie met een ander stuk software of een andere website.

  • Is het in orde dat je alle informatie die je vindt aan beide partijen meldt?

  • Is het nodig om twee verschillende verantwoorde meldingen te doen, bijvoorbeeld één melding aan het ene bedrijf en een andere melding aan het bedrijf van de derde partij, met als doel de informatie die naar elk bedrijf wordt gestuurd te beperken?

  • Is het in orde dat de ontdekker de bedrijven met elkaar in contact brengt?

Verstorende software

Voorbeeld: je bent bekwaam genoeg om een virus te schrijven waarvan je denkt dat het gebruikers waarschijnlijk helpt zichzelf te beschermen tegen het beveiligingsrisico, of vast te stellen of ze risico lopen, of het beveiligingsrisico te verhelpen.

  • Is het in orde?

  • Is het in orde dat de ontdekker gebruikers wijst op software als deze, en/of op gidsen of tutorials die beschrijven hoe je dit soort software maakt?

Gecoördineerde kwetsbaarheidsmelding versus verantwoorde melding

Gecoördineerde kwetsbaarheidsmelding is de voorkeursterm.

  • Het belangrijkste aspect is de coördinatie tussen ontdekker en producent.

Verantwoorde melding (responsible disclosure) is een verouderde term.

  • Mensen hebben verschillende opvattingen over wat het betekent verantwoordelijk te zijn. Sommige mensen bepleiten bijvoorbeeld dat het verantwoordelijk is dat de ontdekker het publiek onmiddellijk op de hoogte stelt, ongeacht enige interactie met de producent, en onverantwoordelijk om gecoördineerde kwetsbaarheidsmelding te doen omdat het informatie voor het publiek verbergt.

Registratie