Coordinated vulnerability disclosure

Samordnat röjande av sårbarheter (CVD)

Hur du rapporterar, tar emot och samordnar säkerhetssårbarheter, med exempel på policyer.

Samordnat röjande av sårbarheter (Coordinated vulnerability disclosure, CVD) är en term inom datasäkerhet. Den beskriver hur människor kan dela rapporter om säkerhetsproblem. Exempel är felrapporter, intrångsrisker, hackningsvarningar, dataläckor, intrång på webbplatser med mera.

Översättningar: العربية, Български, বাংলা, Č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, 中文

Innehåll:

Policyer:

Inledning

Det här dokumentet förklarar samordnat röjande av sårbarheter på sätt som kan hjälpa människor att arbeta tillsammans.

Dokumentets mål:

  1. Hjälpa människor som upptäcker säkerhetsproblem och vill rapportera dem.

  2. Hjälpa företagsrepresentanter att förstå behov, mål, arbetssätt och särskilda fall kring ansvarsfullt röjande.

  3. Ta med exempel på policyer för samordnat röjande av sårbarheter i arkivets mapp.

Vi välkomnar pull requests, GitHub-ärenden (issues) eller e-post till security@joelparkerhenderson.com.

Vad är samordnat röjande av sårbarheter?

Samordnat röjande av sårbarheter beskriver tre steg när någon upptäcker ett säkerhetsproblem (till exempel ett programvarufel) och vill rapportera det till tillverkaren (till exempel företaget som tillverkar programvaran).

Steg:

  1. Upptäckaren rapporterar problemet privat och i god tro till tillverkaren.

  2. Tillverkaren försöker i god tro skydda användarna och åtgärda problemet.

  3. Efter en överenskommen tid offentliggörs säkerhetsproblemet.

Steg 1: Rapportera problemet

Steg 1 är till för upptäckaren: rapportera problemet privat och i god tro.

  • Bra: Upptäckaren skickar den relevanta informationen till tillverkaren, till exempel via e-post till tillverkarens säkerhetsadress (vanligtvis "security@example.com") eller via ett webbformulär på tillverkarens webbplats (vanligtvis "https://www.example.com/security").

  • Dåligt: att publicera rapporten på en offentlig blogg, att varna medierna, hot, eller försök att sälja säkerhetsproblemet till hackare med mera.

  • Tips: upptäckaren kan välja att vara anonym; tillverkaren kan också välja att vara anonym.

Om du vill, fortsätt att hålla dig underrättad om problemet.

  • Bra: att öppna kommunikationskanaler, eller lämna uppföljande information, eller bevaka situationen.

  • Dåligt: att glömma bort problemet.

  • Tips: upptäckaren kan välja att hjälpa till eller inte, och kan också välja att hålla kontakten eller inte, och kan dessutom välja att ändra upplägget om omständigheterna ändras.

Om du vill, röj problemet för andra.

  • Bra: att vänta den överenskomna tiden och sedan gå ut offentligt, till exempel genom att lägga upp relevant information på en säkerhetsnyhetssajt, eller kontakta relevanta säkerhetsforskare från tredje part, eller tillkännage problemet på valfri offentlig social webbplats med mera.

  • Dåligt: att inte röja problemet för andra, såvida du inte bedömer att det skulle innebära mer än motsvarande risk för dig själv eller andra.

  • Tips: om omständigheterna ändras, till exempel genom att en högre risk eller ett aktivt utnyttjande i det fria (active exploit in the wild) upptäcks, kan upptäckaren röja problemet för andra tidigare.

Steg 2: Se till att kontaktvägarna fungerar

Steg 2 är till för tillverkaren: se till att kontaktvägarna fungerar.

  • Bra: Tillverkaren publicerar en e-postadress för säkerhetskontakt (enligt konvention "security@example.com") och helst även en säker nyckel för e-postkryptering.

  • Bra: Tillverkaren publicerar en webbsida för säkerhetskontakt (enligt konvention "https://www.example.com/security") och gör helst sidan lätt att hitta, till exempel via webbplatsens sidfot, webbplatskarta och sökfunktion.

  • Dåligt: Tillverkaren tillhandahåller varken e-postadress eller webbsida, eller gör dem inte lätta att hitta.

Se till att personalen har förmågan.

  • Bra: Tillverkaren utbildar supportpersonalen i vad de ska göra om de får en säkerhetsförfrågan, till exempel hur man svarar med kontaktuppgifter, eller hur man vidarebefordrar förfrågan till rätt internt team.

  • Bra: Tillverkaren kontrollerar regelbundet att personalens förmåga fungerar.

  • Dåligt: Tillverkaren utbildar inte eller kontrollerar inte.

Svara upptäckaren inom tidsramen.

  • Om upptäckaren inte anger någon tidsram, använd en arbetsdag, eftersom detta är branschstandard och nuvarande bästa praxis i branschen.

  • Om upptäckaren ställer frågor, besvara dem. Det är särskilt viktigt om upptäckaren ber om tillstånd att testa. Se till att alla svar är tydliga och raka.

Svara upptäckaren via en behörig säkerhetskontakt och/eller en behörig säkerhetsprocess.

  • Bra: ett svar från en säkerhetsspecifik e-postadress, till exempel "security@example.com".

  • Exempel på vad som är dåligt: ett svar från en allmän e-postadress, till exempel "help@example.com", eller från någon som inte är en behörig säkerhetsexpert.

Låt upptäckaren veta att ärendet har identifierats som en säkerhetsrapport.

  • Bra: säkerhetsspecifik formulering, till exempel "Vårt säkerhetsteam har tagit emot din rapport om ansvarsfullt röjande", eller "Vår säkerhetsprocess har följande nästa steg", eller "Din information finns nu i vårt säkerhetsspårningssystem med ID-nummer XYZ" med mera.

  • Dåligt: allmän formulering, till exempel "Vi uppskattar din affär", eller "Vi tar säkerheten på allvar", eller formuleringar som skjuter över ansvaret, till exempel "Vi har skickat ditt e-postmeddelande till en annan avdelning" med mera.

Steg 3: Arbeta i god tro

Steg 3 är till för upptäckaren och tillverkaren tillsammans: arbeta i god tro.

Förstå att samordnat röjande av sårbarheter beskriver en process i god tro.

  • Mål nr 1 är god tro för att hjälpa användare att skydda sig mot säkerhetsrisker.

  • Mål nr 2 är god tro för att åtgärda säkerhetsproblemet.

  • Upptäckaren och/eller tillverkaren kan i god tro välja att involvera andra säkerhetspersoner, till exempel genom att kontakta andra relevanta säkerhetsforskare för att få hjälp med problemet.

Förstå att samordnat röjande av sårbarheter inte skapar någon förpliktelse.

  • Upptäckaren och/eller tillverkaren kan när som helst dra sig ur, av vilken anledning som helst, med eller utan förvarning. Det är hövligt att hålla alla berörda informerade och uppdaterade, men det är inte alltid möjligt, praktiskt eller önskvärt.

  • Samordnat röjande av sårbarheter skapar inget juridiskt avtal. Om upptäckaren och tillverkaren redan har ett juridiskt avtal föreslår vi att alla inblandade rådgör med lämpliga jurister; använd inte det här dokumentet som juridisk rådgivning.

Förstå att samordnat röjande av sårbarheter syftar till god kommunikation och till att avvisa hot.

  • Samordnat röjande av sårbarheter fungerar bäst när alla inblandade förstår att mål nr 1 är att hjälpa användare att skydda sig mot säkerhetsrisker, och mål nr 2 är att åtgärda säkerhetsproblemet.

  • Samordnat röjande av sårbarheter avvisar alla slags hot om vedergällning, hotfullt beteende, avstängning, återkallelse, utpressning, uppföljningsbörda eller skuldbeläggning av offret.

Förstå att samordnat röjande av sårbarheter kan betyda olika saker för olika personer.

  • Upptäckaren och tillverkaren kan ha olika uppfattning om samordnat röjande av sårbarheter. Dessa uppfattningar kanske inte stämmer överens. God tro innebär att alla inblandade förstår detta.

  • Vissa tillverkare publicerar policyer för samordnat röjande av sårbarheter. Dessa kan vara till hjälp som vägledning. Om en upptäckare väljer att använda en annan form av samordnat röjande av sårbarheter, eller har en annan uppfattning om ansvarsfullt röjande, är det helt i sin ordning.

Förstå att upptäckaren vanligtvis gör utgivaren en tjänst.

  • Vanligtvis behöver upptäckaren ingens tillstånd för att publicera sårbarheter.

  • Vanligtvis hjälper upptäckarens information utgivaren.

Kontrollera att det lyckades

När problemet är löst måste tillverkaren kontrollera att det lyckades.

  • Hanterade alla människor och processer röjandet på ett lyckat sätt? Om så är fallet, bra. Om inte, överväg att göra efterhandsundersökningar, till exempel grundorsaksanalys (RCA), efterhandsrapporter (post mortem), Ishikawa-diagram eller kausalanalys baserad på systemteori (CAST).

  • Har eventuella kvarstående problem triagerats och spåras?

  • Förstår både tillverkaren och upptäckaren vad som ska göras i eventuella nästa steg? Det är särskilt viktigt att få detta rätt om det kan komma ytterligare samordnade röjanden av sårbarheter.

Vägledning

Vägledning för samordnat röjande av sårbarheter kan komma från många håll, till exempel etikexperter, juridiska förespråkare, allmänhetens rimliga förväntningar med mera.

Om du söker vägledning kan du vara intresserad av dessa tre områden, som alla beskrivs nedan.

  • Den barmhärtige samariten

  • Plikt att rädda

  • Omsorgsplikt

Den barmhärtige samariten

Wikipedia: Lagar om den barmhärtige samariten

Lagar om den barmhärtige samariten (Good Samaritan laws) ger rättsligt skydd åt personer som ger rimlig hjälp till dem som är, eller som de tror är, skadade, sjuka, i fara eller på annat sätt oförmögna att hjälpa sig själva. Skyddet är avsett att minska åskådares tvekan att hjälpa till av rädsla för att bli stämda eller åtalade.

Plikt att rädda

Wikipedia: Plikt att rädda

Plikt att rädda är ett begrepp som beskriver en situation där en part kan hållas ansvarig för att ha underlåtit att komma en annan part i fara till undsättning. En plikt att rädda kan ha moraliska och/eller juridiska områden.

Omsorgsplikt

Wikipedia: Omsorgsplikt

En omsorgsplikt är skyldigheten att iaktta en standard för rimlig aktsamhet när man utför handlingar som förutsebart kan skada andra. En omsorgsplikt kan ha moraliska och/eller juridiska områden. Några aspekter att beakta är: hur förutsebar skadan eller personskadan är, den möjliga storleken på den potentiella skadan, vikten eller det samhälleliga värdet av den verksamhet som svaranden ägnade sig åt, nyttan av beteendet för svaranden, möjligheten till alternativt beteende, kostnaderna och bördorna med det alternativa beteendet, det alternativa beteendets relativa nytta och det alternativa beteendets relativa säkerhet.

Särskilda fall

Våra säkerhetsteam har sett ett brett spektrum av särskilda fall.

Vi beskriver dem här för att hjälpa människor att förstå var det finns en stor bredd av åsikter om vad som kan vara okej och vad som inte kan vara okej. Vi rekommenderar att alla inblandade kommunicerar i god tro om dessa.

Åtkomst till andra användares information

Exempel: du upptäcker att en webbadress (URL) innehåller ditt användar-ID, att den avslöjar ett fel, och du tror att du kan redigera URL:en för att ändra ditt användar-ID till ett annat användar-ID.

  • Är det okej att upptäckaren gör detta, till exempel med det enda målet att ta reda på om det påverkar andra användare också?

  • Är det viktigare att snabbt förstå hur stor risken är för alla användare än att skydda ett par användare vars information redan kan vara synlig för hackare?

  • Är det okej att upptäckaren gör detta med hur många användare som helst?

  • Är det okej att upptäckaren försöker kontakta användare för att meddela att de är berörda? Är det okej att erbjuda förslag på hur riskerna kan minskas?

Överbelastning (denial of service)

Exempel: du upptäcker ett fel som av misstag spärrar ditt konto, till exempel genom att utlösa en lösenordsspärr.

  • Räknas detta som en överbelastningsattack (denial of service)?

Oönskad e-post

Exempel: du försöker rapportera ett säkerhetsproblem till personer på företaget som du tror är relevanta, och som du hittar genom att undersöka på LinkedIn, Facebook med mera, eller genom att använda namnkonventioner som "webmaster@example.com" eller "security@example.com".

  • Är detta okej?

  • Räknas detta som oönskad e-post (unsolicited email)?

  • Räknas detta som obehörig e-post (unauthorized email)?

Uteslutna grupper

Exempel: du tillhör en utesluten grupp, till exempel genom att vara minderårig, eller finnas på en sanktionslista, eller befinna dig i ett land på en sanktionslista.

  • Är det okej för dig att göra en rapport?

  • Är det okej att rapportera anonymt?

  • Är det okej att medvetet ändra potentiellt identifierande information, till exempel för att undgå den uteslutna gruppen och med målet att hjälpa röjandet att nå rätt personer?

Tredje part

Exempel: du upptäcker att ett företags programvara har ett fel som involverar en tredje part, till exempel en integration med en annan programvara eller en annan webbplats.

  • Är det okej för dig att rapportera all information du hittar till båda parter?

  • Är det nödvändigt att göra två olika ansvarsfulla röjanden, till exempel en rapport till det ena företaget och en annan rapport till tredjepartsföretaget, med målet att begränsa informationen som skickas till varje företag?

  • Är det okej att upptäckaren sätter företagen i kontakt med varandra?

Störande programvara

Exempel: du är tillräckligt skicklig för att kunna skriva ett virus som du tror sannolikt hjälper användare att skydda sig mot säkerhetsrisken, eller att ta reda på om de är utsatta, eller att åtgärda säkerhetsrisken.

  • Är det okej?

  • Är det okej att upptäckaren hänvisar användare till sådan programvara och/eller till guider eller handledningar som beskriver hur man skapar den här typen av programvara?

Samordnat röjande av sårbarheter jämfört med ansvarsfullt röjande

Samordnat röjande av sårbarheter är den föredragna termen.

  • Den viktigaste aspekten är samordningen mellan upptäckare och tillverkare.

Ansvarsfullt röjande (responsible disclosure) är en term som avråds från.

  • Människor har olika syn på vad det innebär att vara ansvarsfull. Till exempel förespråkar vissa att det är ansvarsfullt av upptäckaren att underrätta allmänheten omedelbart oavsett eventuell kontakt med tillverkaren, och oansvarigt att göra samordnat röjande av sårbarheter eftersom det döljer information för allmänheten.

Spårning