Coordinated vulnerability disclosure

Koordineret offentliggørelse af sårbarheder (CVD)

Sådan rapporterer, modtager og koordinerer du sikkerhedssårbarheder, med eksempler på politikker.

Koordineret offentliggørelse af sårbarheder (Coordinated vulnerability disclosure, CVD) er et begreb inden for computersikkerhed. Det beskriver, hvordan folk kan dele rapporter om sikkerhedsproblemer. Eksempler er fejlrapporter, risici for indbrud, hackeradvarsler, datalækager, brud på hjemmesider osv.

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

Indhold:

Politikker:

Indledning

Dette dokument forklarer koordineret offentliggørelse af sårbarheder på måder, der kan hjælpe folk med at arbejde sammen.

Dokumentets mål:

  1. Hjælpe folk, der opdager sikkerhedsproblemer og vil rapportere dem.

  2. Hjælpe virksomhedsrepræsentanter med at forstå behov, mål, praksis og særlige tilfælde ved ansvarlig offentliggørelse.

  3. Medtage eksempler på politikker for koordineret offentliggørelse af sårbarheder i arkivets mappe.

Vi byder pull requests, GitHub-issues eller e-mail til security@joelparkerhenderson.com velkommen.

Hvad er koordineret offentliggørelse af sårbarheder?

Koordineret offentliggørelse af sårbarheder beskriver tre trin, når nogen opdager et sikkerhedsproblem (såsom en softwarefejl) og vil rapportere det til producenten (såsom virksomheden, der laver softwaren).

Trin:

  1. Opdageren rapporterer privat og i god tro problemet til producenten.

  2. Producenten forsøger i god tro at beskytte brugerne og at løse problemet.

  3. Efter en aftalt tid offentliggøres sikkerhedsproblemet.

Trin 1: Rapportér problemet

Trin 1 er for opdageren: rapportér problemet privat og i god tro.

  • Godt: Opdageren sender de relevante oplysninger til producenten, f.eks. via e-mail til producentens sikkerhedsadresse (typisk "security@example.com") eller via en formular på producentens hjemmeside (typisk "https://www.example.com/security").

  • Dårligt: at lægge rapporten på en offentlig blog, eller advare medierne, eller true, eller forsøge at sælge sikkerhedsproblemet til hackere osv.

  • Tip: opdageren kan vælge at være anonym; producenten kan også vælge at være anonym.

Hvis du vil, så fortsæt med at holde dig orienteret om problemet.

  • Godt: at åbne kommunikationslinjer, eller give opfølgende oplysninger, eller overvåge situationen.

  • Dårligt: at glemme problemet.

  • Tip: opdageren kan vælge at hjælpe eller ej, og kan også vælge at være i kontakt eller ej, og kan også vælge at ændre aftalen, hvis omstændighederne ændrer sig.

Hvis du vil, så offentliggør problemet over for andre.

  • Godt: at vente den aftalte tid og så gå offentligt ud, f.eks. ved at lægge de relevante oplysninger på et sikkerhedsnyhedssite, eller kontakte relevante sikkerhedsforskere hos tredjeparter, eller annoncere problemet på et offentligt socialt site osv.

  • Dårligt: ikke at offentliggøre problemet over for andre, medmindre du føler, at det ville medføre mere end tilsvarende risiko for dig selv eller andre.

  • Tip: hvis omstændighederne ændrer sig, f.eks. ved opdagelse af en højere risiko eller et aktivt udnyttet exploit i det fri (active exploit in the wild), kan opdageren offentliggøre problemet over for andre tidligere.

Trin 2: Sørg for kontaktoplysninger

Trin 2 er for producenten: sørg for, at kontaktveje er brugbare.

  • Godt: Producenten offentliggør en e-mailadresse til sikkerhedskontakt (efter konvention "security@example.com") og helst også en sikker nøgle til e-mailkryptering.

  • Godt: Producenten offentliggør en webside til sikkerhedskontakt (efter konvention "https://www.example.com/security") og gør helst siden let at finde, f.eks. via hjemmesidens sidefod, sitemap og søgning.

  • Dårligt: Producenten giver hverken en e-mailadresse eller en webside, eller gør dem ikke lette at finde.

Sørg for personalets evner.

  • Godt: Producenten uddanner supportpersonalet i, hvad de skal gøre, hvis de modtager en sikkerhedshenvendelse, f.eks. hvordan de svarer med kontaktoplysninger, eller hvordan de videresender henvendelsen til det rette interne team.

  • Godt: Producenten kontrollerer med jævne mellemrum, at personalets evner fungerer.

  • Dårligt: Producenten uddanner ikke eller kontrollerer ikke.

Svar opdageren inden for tidsrammen.

  • Hvis opdageren ikke angiver en tidsramme, så brug én arbejdsdag, fordi det er branchestandard og nuværende bedste praksis i branchen.

  • Hvis opdageren stiller spørgsmål, så besvar dem. Det er især vigtigt, hvis opdageren beder om tilladelse til at teste. Sørg for, at alle svar er klare og direkte.

Svar opdageren via en autoriseret sikkerhedskontakt og/eller en autoriseret sikkerhedsproces.

  • Godt: et svar fra en sikkerhedsspecifik e-mailadresse, f.eks. "security@example.com".

  • Eksempel på, hvad der er dårligt: et svar fra en generel e-mailadresse, f.eks. "help@example.com", eller fra nogen, der ikke er en autoriseret sikkerhedsprofessionel.

Giv opdageren besked om, at sagen er anerkendt som en sikkerhedsrapport.

  • Godt: sikkerhedsspecifik ordlyd, f.eks. "Vores sikkerhedsteam har modtaget din rapport om ansvarlig offentliggørelse", eller "Vores sikkerhedsproces har disse næste trin", eller "Dine oplysninger er nu i vores sikkerhedssporingssystem med id-nummer XYZ" osv.

  • Dårligt: generel ordlyd, f.eks. "Vi sætter pris på din forretning", eller "Vi tager sikkerhed alvorligt", ansvarsfralæggende ordlyd som "Vi har sendt din e-mail til en anden afdeling" osv.

Trin 3: Arbejd i god tro

Trin 3 er for opdager og producent sammen: arbejd i god tro.

Forstå, at koordineret offentliggørelse af sårbarheder beskriver en proces i god tro.

  • Mål nr. 1 er god tro for at hjælpe brugerne med at beskytte sig mod sikkerhedsrisici.

  • Mål nr. 2 er god tro for at løse sikkerhedsproblemet.

  • Opdageren og/eller producenten kan i god tro vælge at inddrage andre sikkerhedsfolk, f.eks. ved at kontakte andre relevante sikkerhedsforskere for at få hjælp til problemet.

Forstå, at koordineret offentliggørelse af sårbarheder ikke skaber nogen forpligtelse.

  • Opdageren og/eller producenten kan til enhver tid, af enhver grund, med eller uden varsel, trække sig. Det er høfligt at holde alle relevante personer informeret og opdateret, men det er ikke altid muligt, praktisk eller ønskeligt.

  • Koordineret offentliggørelse af sårbarheder skaber ingen juridisk aftale. Hvis opdageren og producenten allerede har en juridisk aftale, foreslår vi, at alle involverede rådfører sig med de rette jurister; brug ikke dette dokument som juridisk rådgivning.

Forstå, at koordineret offentliggørelse af sårbarheder sigter mod at bruge god kommunikation og at afvise trusler.

  • Koordineret offentliggørelse af sårbarheder er bedst, når alle involverede forstår, at mål nr. 1 er at hjælpe brugerne med at beskytte sig mod sikkerhedsrisici, og mål nr. 2 er at løse sikkerhedsproblemet.

  • Koordineret offentliggørelse af sårbarheder afviser enhver form for trussel om gengældelse, intimidering, suspension, tilbagekaldelse, afpresning, opfølgningsbyrde eller offerbebrejdelse.

Forstå, at koordineret offentliggørelse af sårbarheder kan betyde forskellige ting for forskellige mennesker.

  • Opdageren og producenten kan have forskellig forståelse af koordineret offentliggørelse af sårbarheder. Disse forståelser stemmer måske ikke overens. God tro omfatter, at alle involverede forstår dette.

  • Nogle producenter offentliggør politikker for koordineret offentliggørelse af sårbarheder. Disse kan være en nyttig vejledning. Hvis en opdager vælger at bruge en anden form for koordineret offentliggørelse af sårbarheder eller har en anden forståelse af ansvarlig offentliggørelse, er det helt i orden.

Forstå, at opdageren typisk gør udgiveren en tjeneste.

  • Typisk har opdageren ikke brug for nogens tilladelse til at offentliggøre sårbarheder.

  • Typisk hjælper opdagerens oplysninger udgiveren.

Bekræft succes

Når problemet er løst, skal producenten bekræfte succes.

  • Håndterede alle personer og processer offentliggørelsen med succes? Hvis ja, godt. Hvis ikke, så overvej at lave undersøgelser bagefter, såsom rodårsagsanalyse (RCA), post mortem-rapporter, Ishikawa-diagrammer eller kausalanalyse baseret på systemteori (CAST).

  • Er eventuelle udestående sager triageret og sporet?

  • Forstår både producent og opdager, hvad der skal gøres i eventuelle næste trin? Det er især vigtigt at få dette rigtigt, hvis der kan komme yderligere koordinerede offentliggørelser af sårbarheder.

Vejledning

Vejledning om koordineret offentliggørelse af sårbarheder kan komme fra mange områder, såsom etikeksperter, juridiske fortalere, offentlighedens rimelige forventninger osv.

Hvis du søger vejledning, kan du være interesseret i disse tre områder, alle beskrevet nedenfor.

  • Den barmhjertige samaritan

  • Redningspligt

  • Omsorgspligt

Den barmhjertige samaritan

Wikipedia: Lov om den barmhjertige samaritan

Love om den barmhjertige samaritan (Good Samaritan laws) giver retsbeskyttelse til personer, der yder rimelig hjælp til dem, som er, eller som de tror er, kvæstede, syge, i fare eller på anden måde ude af stand til at hjælpe sig selv. Beskyttelsen er beregnet til at mindske tilskueres tøven med at hjælpe af frygt for at blive sagsøgt eller retsforfulgt.

Redningspligt

Wikipedia: Redningspligt

En redningspligt er et begreb, der beskriver en omstændighed, hvor en part kan holdes ansvarlig for ikke at komme en anden part i fare til undsætning. En redningspligt kan have moralske og/eller juridiske områder.

Omsorgspligt

Wikipedia: Omsorgspligt

En omsorgspligt er forpligtelsen til at overholde en standard for rimelig omhu, når man udfører handlinger, der forudseeligt kan skade andre. En omsorgspligt kan have moralske og/eller juridiske områder. Nogle aspekter at overveje er: forudsigeligheden af skaden eller tilskadekomsten, den mulige størrelse af den potentielle skade eller tilskadekomst, vigtigheden eller den sociale værdi af den aktivitet, den sagsøgte var involveret i, nytten af adfærden for den sagsøgte, gennemførligheden af alternativ adfærd, omkostningerne og byrderne forbundet med den alternative adfærd, den alternative adfærds relative nytte og den alternative adfærds relative sikkerhed.

Særlige tilfælde

Vores sikkerhedsteams har set en bred vifte af særlige tilfælde.

Vi beskriver dem her for at hjælpe folk med at forstå, hvor der er en bred vifte af holdninger til, hvad der kan være i orden, og hvad der ikke kan være i orden. Vi anbefaler, at alle involverede kommunikerer i god tro om disse.

Adgang til andre brugeres oplysninger

Eksempel: du opdager, at en URL indeholder dit bruger-id og afslører en fejl, og du tror, at du kan redigere URL'en for at ændre dit bruger-id til et andet bruger-id.

  • Er det i orden, at opdageren gør dette, f.eks. med det ene formål at finde ud af, om det også påvirker andre brugere?

  • Er det vigtigere hurtigt at forstå risikoens omfang for alle brugere end at beskytte et par brugere, hvis oplysninger måske allerede er synlige for hackere?

  • Er det i orden, at opdageren gør det med så mange brugere, som vedkommende vil?

  • Er det i orden, at opdageren forsøger at kontakte brugere for at fortælle dem, at de er berørt? Er det i orden at tilbyde forslag til afhjælpning?

Denial of service

Eksempel: du opdager en fejl, der ved et uheld suspenderer din konto, f.eks. ved at udløse en adgangskodespærring.

  • Betragtes dette som et denial of service-angreb?

Uopfordret e-mail

Eksempel: du forsøger at rapportere et sikkerhedsproblem til personer i virksomheden, som du tror er relevante, og som du finder ved at researche på LinkedIn, Facebook osv. eller ved at bruge navnekonventioner som "webmaster@example.com" eller "security@example.com".

  • Er dette i orden?

  • Betragtes dette som uopfordret e-mail (unsolicited email)?

  • Betragtes dette som uautoriseret e-mail (unauthorized email)?

Udelukkede grupper

Eksempel: du er i en udelukket gruppe, f.eks. ved at være mindreårig, eller stå på en sanktionsliste, eller være i et land på en sanktionsliste.

  • Er det i orden, at du laver en rapport?

  • Er det i orden at rapportere anonymt?

  • Er det i orden bevidst at ændre potentielt identificerende oplysninger, f.eks. for at slippe uden om den udelukkede gruppe og med det mål at hjælpe offentliggørelsen med at nå de rette personer?

Tredjepart

Eksempel: du opdager, at en virksomheds software har en fejl, der involverer en tredjepart, f.eks. en integration med et andet stykke software eller en anden hjemmeside.

  • Er det i orden, at du rapporterer alle oplysninger, du finder, til begge parter?

  • Er det nødvendigt at lave to forskellige ansvarlige offentliggørelser, f.eks. én rapport til den ene virksomhed og en anden rapport til tredjepartsvirksomheden, med det mål at begrænse de oplysninger, der sendes til hver virksomhed?

  • Er det i orden, at opdageren sætter virksomhederne i forbindelse med hinanden?

Forstyrrende software

Eksempel: du er dygtig nok til at kunne skrive en virus, som du tror sandsynligvis vil hjælpe brugerne med at beskytte sig mod sikkerhedsrisikoen, eller afgøre, om de er i risiko, eller rette sikkerhedsrisikoen.

  • Er det i orden?

  • Er det i orden, at opdageren henviser brugere til software som denne og/eller til vejledninger eller tutorials, der beskriver, hvordan man laver denne slags software?

Koordineret offentliggørelse af sårbarheder vs. ansvarlig offentliggørelse

Koordineret offentliggørelse af sårbarheder er det foretrukne begreb.

  • Det vigtigste aspekt er koordineringen mellem opdager og producent.

Ansvarlig offentliggørelse (responsible disclosure) er et forældet begreb.

  • Folk har forskellige opfattelser af, hvad det vil sige at være ansvarlig. For eksempel går nogle ind for, at det er ansvarligt, at opdageren straks underretter offentligheden uanset enhver interaktion med producenten, og uansvarligt at lave koordineret offentliggørelse af sårbarheder, fordi det skjuler oplysninger for offentligheden.

Sporing