Coordinated vulnerability disclosure

Koordinirano razkrivanje ranljivosti (CVD)

Kako prijaviti, prejeti in uskladiti varnostne ranljivosti, s primeri pravilnikov.

Koordinirano razkrivanje ranljivosti (CVD) je izraz iz računalniške varnosti. Opisuje, kako lahko ljudje delijo poročila o varnostnih težavah. Primeri so poročila o napakah, tveganja vdora, opozorila o vdorih, uhajanje podatkov, vdori v spletna mesta ipd.

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

Kazalo:

Politike:

Uvod

Ta dokument pojasnjuje koordinirano razkrivanje ranljivosti na načine, ki lahko ljudem pomagajo pri sodelovanju.

Cilji dokumenta:

  1. Pomagati ljudem, ki odkrijejo varnostne težave in jih želijo prijaviti.

  2. Pomagati predstavnikom podjetij razumeti potrebe, cilje, prakse in posebne primere odgovornega razkrivanja.

  3. V mapo repozitorija vključiti primere politik koordiniranega razkrivanja ranljivosti.

Veseli bomo pull requestov, težav (issues) na GitHubu ali e-pošte na security@joelparkerhenderson.com.

Kaj je koordinirano razkrivanje ranljivosti?

Koordinirano razkrivanje ranljivosti opisuje tri korake, ko nekdo odkrije varnostno težavo (na primer programsko napako) in jo želi prijaviti proizvajalcu (na primer podjetju, ki izdeluje programsko opremo).

Koraki:

  1. Odkritelj težavo zasebno in v dobri veri prijavi proizvajalcu.

  2. Proizvajalec v dobri veri poskuša zaščititi uporabnike in rešiti težavo.

  3. Po določenem času se varnostna težava objavi.

Korak 1: Prijavite težavo

Korak 1 je za odkritelja: težavo prijavite zasebno in v dobri veri.

  • Dobro: Odkritelj pošlje ustrezne informacije proizvajalcu, na primer po e-pošti na proizvajalčev varnostni e-poštni naslov (običajno »security@example.com«) ali prek spletnega obrazca na proizvajalčevem spletnem mestu (običajno »https://www.example.com/security«).

  • Slabo: objava poročila na javnem blogu, obveščanje medijev, grožnje ali poskusi prodaje varnostne težave hekerjem ipd.

  • Nasvet: odkritelj lahko ostane anonimen; tudi proizvajalec lahko ostane anonimen.

Če želite, še naprej spremljajte težavo.

  • Dobro: vzpostavitev komunikacijskih poti, posredovanje dodatnih informacij ali spremljanje razmer.

  • Slabo: pozabiti na težavo.

  • Nasvet: odkritelj se lahko odloči, ali bo pomagal ali ne, ali bo v stiku ali ne, in lahko tudi spremeni dogovor, če se okoliščine spremenijo.

Če želite, težavo razkrijte tudi drugim.

  • Dobro: počakati določen čas in nato javno objaviti, na primer z objavo ustreznih informacij na novičarskem spletnem mestu o varnosti, stikom z ustreznimi zunanjimi varnostnimi raziskovalci ali objavo težave na katerem koli javnem družabnem omrežju ipd.

  • Slabo: ne razkriti težave drugim, razen če menite, da bi to za vas ali druge pomenilo večje tveganje od primerljivega.

  • Nasvet: če se okoliščine spremenijo, na primer odkrijete večje tveganje ali aktivno izkoriščanje v naravi, lahko odkritelj težavo drugim razkrije prej.

Korak 2: Zagotovite kontakte.

Korak 2 je za proizvajalca: zagotovite, da so kontakti delujoči.

  • Dobro: Proizvajalec objavi varnostni e-poštni naslov (običajno »security@example.com«) in po možnosti ključ za šifriranje e-pošte.

  • Dobro: Proizvajalec objavi spletno stran z varnostnim kontaktom (običajno »https://www.example.com/security«) in po možnosti poskrbi, da jo je enostavno najti, na primer prek noge spletnega mesta, zemljevida strani in iskanja.

  • Slabo: Proizvajalec ne zagotovi e-poštnega naslova ali spletne strani oziroma ju ne naredi lahko dostopnih.

Zagotovite zmožnosti osebja.

  • Dobro: Proizvajalec usposobi osebje za podporo, kaj storiti ob varnostni poizvedbi, na primer kako odgovoriti s kontaktnimi podatki ali kako poizvedbo posredovati pravi notranji ekipi.

  • Dobro: Proizvajalec redno preverja, ali zmožnosti osebja delujejo.

  • Slabo: Proizvajalec osebja ne usposobi ali tega ne preverja.

Odgovorite odkritelju v dogovorjenem roku.

  • Če odkritelj ne določi roka, uporabite en delovni dan, ker je to industrijski standard in trenutna najboljša praksa v industriji.

  • Če odkritelj postavlja vprašanja, nanje odgovorite. To je še posebej pomembno, če odkritelj prosi za dovoljenje za testiranje. Poskrbite, da so vsi odgovori jasni in neposredni.

Odgovorite odkritelju prek pooblaščenega varnostnega kontakta in/ali pooblaščenega varnostnega postopka.

  • Dobro: odgovor z varnostnega e-poštnega naslova, na primer »security@example.com«.

  • Primeri slabega: odgovor s splošnega e-poštnega naslova, na primer »help@example.com«, ali od nekoga, ki ni pooblaščen varnostni strokovnjak.

Odkritelju sporočite, da je težava prepoznana kot varnostno poročilo.

  • Dobro: varnostno specifična besedilo, na primer »Naša varnostna ekipa je prejela vaše poročilo o odgovornem razkritju«, »Naš varnostni postopek ima naslednje korake« ali »Vaše informacije so zdaj v našem varnostnem sledilniku pod številko XYZ« ipd.

  • Slabo: splošno besedilo, na primer »Cenimo vaše poslovanje z nami« ali »Varnost jemljemo resno«, ali preložitev odgovornosti, na primer »Vaše sporočilo smo posredovali drugemu oddelku« ipd.

Korak 3: Delujte v dobri veri

Korak 3 je za odkritelja in proizvajalca skupaj: delujte v dobri veri.

Razumite, da koordinirano razkrivanje ranljivosti opisuje postopek v dobri veri.

  • Cilj št. 1 je dobra vera, da uporabnikom pomagamo zaščititi se pred varnostnimi tveganji.

  • Cilj št. 2 je dobra vera, da rešimo varnostno težavo.

  • Odkritelj in/ali proizvajalec se lahko v dobri veri odločita vključiti druge varnostne strokovnjake, na primer stik z drugimi ustreznimi varnostnimi raziskovalci, ki bi pomagali pri težavi.

Razumite, da koordinirano razkrivanje ranljivosti ne ustvarja nobenih obveznosti.

  • Odkritelj in/ali proizvajalec lahko kadar koli iz kateregakoli razloga odstopita, z opozorilom ali brez njega. Vljudno je, da vse ustrezne osebe obveščate in jih seznanjate z novostmi, vendar to ni vedno mogoče, praktično ali zaželeno.

  • Koordinirano razkrivanje ranljivosti ne ustvarja nobenega pravnega dogovora. Če imata odkritelj in proizvajalec že pravni dogovor, predlagamo, da se vsi vpleteni posvetujejo z ustreznimi pravniki; tega dokumenta ne uporabljajte kot pravnega nasveta.

Razumite, da koordinirano razkrivanje ranljivosti stremi k dobri komunikaciji in zavrača grožnje.

  • Koordinirano razkrivanje ranljivosti je najboljše, kadar vsi vpleteni razumejo, da je cilj št. 1 pomagati uporabnikom zaščititi se pred varnostnimi tveganji, cilj št. 2 pa rešiti varnostno težavo.

  • Koordinirano razkrivanje ranljivosti zavrača vsakršne grožnje s povračilom, ustrahovanje, suspenz, preklic, izsiljevanje, breme nadaljnjega spremljanja ali obtoževanje žrtve.

Razumite, da lahko koordinirano razkrivanje ranljivosti različnim ljudem pomeni različne stvari.

  • Odkritelj in proizvajalec imata lahko različno razumevanje koordiniranega razkrivanja ranljivosti. Ta razumevanja se morda ne ujemajo. Dobra vera vključuje, da vsi vpleteni to razumejo.

  • Nekateri proizvajalci objavijo politike koordiniranega razkrivanja ranljivosti. Te so lahko koristna navodila. Če se odkritelj odloči za drugačno obliko koordiniranega razkrivanja ranljivosti ali ima drugačno razumevanje odgovornega razkrivanja, je to popolnoma v redu.

Razumite, da odkritelj običajno izkaže uslugo izdajatelju.

  • Odkritelj običajno ne potrebuje ničjega dovoljenja za objavo ranljivosti.

  • Informacije odkritelja običajno koristijo izdajatelju.

Preverite uspeh

Ko je težava rešena, mora proizvajalec preveriti uspeh.

  • Ali so vsi ljudje in postopki razkritje obravnavali uspešno? Če da, dobro. Če ne, razmislite o raziskavi po dogodku, kot so analiza temeljnih vzrokov (RCA), poročila po dogodku (post-mortem), diagrami Išikave ali vzročna analiza na podlagi teorije sistemov (CAST).

  • Ali so morebitne odprte težave razvrščene in spremljane?

  • Ali proizvajalec in odkritelj razumeta, kaj storiti pri morebitnih naslednjih korakih? To je še posebej pomembno pravilno urediti za primer morebitnih nadaljnjih koordiniranih razkritij ranljivosti.

Smernice

Smernice za koordinirano razkrivanje ranljivosti lahko izhajajo iz številnih področij, na primer od strokovnjakov za etiko, pravnih zagovornikov, razumnih pričakovanj splošne javnosti ipd.

Če iščete smernice, vas utegnejo zanimati ta tri področja, opisana spodaj.

  • Usmiljeni Samarijan

  • Dolžnost reševanja

  • Skrbnostna dolžnost

Usmiljeni Samarijan

Wikipedia: Good Samaritan law

Zakoni o usmiljenem Samarijanu zagotavljajo pravno zaščito ljudem, ki razumno pomagajo tistim, ki so poškodovani, bolni, v nevarnosti ali kako drugače nezmožni, ali za katere to menijo. Zaščita naj bi zmanjšala obotavljanje mimoidočih pri pomoči zaradi strahu pred tožbo ali pregonom.

Dolžnost reševanja

Wikipedia: Duty to rescue

Dolžnost reševanja je pojem, ki opisuje okoliščino, v kateri je lahko oseba odgovorna, ker ni priskočila na pomoč drugi osebi v nevarnosti. Dolžnost reševanja ima lahko moralna in/ali pravna področja.

Skrbnostna dolžnost

Wikipedia: Duty of care

Skrbnostna dolžnost je obveznost ravnati po standardu razumne skrbnosti pri vseh dejanjih, ki bi lahko predvidljivo škodovala drugim. Skrbnostna dolžnost ima lahko moralna in/ali pravna področja. Nekateri vidiki, ki jih je treba upoštevati, so: predvidljivost škode ali poškodbe, možna velikost potencialne škode ali poškodbe, pomen ali družbena vrednost dejavnosti, ki jo izvaja toženec, koristnost ravnanja za toženca, izvedljivost alternativnega ravnanja, stroški in bremena, povezani z alternativnim ravnanjem, relativna koristnost alternativnega ravnanja in relativna varnost alternativnega ravnanja.

Posebni primeri

Naše varnostne ekipe so videle širok razpon posebnih primerov.

Opisujemo jih tukaj, da bi ljudem pomagali razumeti, kje obstaja širok razpon mnenj o tem, kaj je lahko sprejemljivo in kaj ne. Priporočamo, da vsi vpleteni o teh primerih komunicirajo v dobri veri.

Dostop do podatkov drugih uporabnikov

Primer: odkrijete, da URL vsebuje vaš uporabniški ID in razkriva napako, ter menite, da lahko URL uredite tako, da vaš uporabniški ID zamenjate z ID drugega uporabnika.

  • Ali je odkritelju to dovoljeno, na primer z edinim ciljem ugotoviti, ali to vpliva tudi na druge uporabnike?

  • Ali je pomembneje hitro razumeti širino tveganja za vse uporabnike, kot zaščititi nekaj uporabnikov, katerih informacije morda že vidijo heker?

  • Ali je odkritelju dovoljeno to storiti s poljubnim številom uporabnikov?

  • Ali je odkritelju dovoljeno poskusiti stopiti v stik z uporabniki in jih obvestiti, da so prizadeti? Ali je dovoljeno ponuditi predloge za omilitev?

Zavrnitev storitve

Primer: odkrijete napako, ki nenamerno začasno onemogoči vaš račun, na primer sproži zaklep gesla.

  • Ali se to šteje za napad z zavrnitvijo storitve?

Neželena e-pošta

Primer: varnostno težavo poskušate prijaviti ljudem v podjetju, za katere menite, da so ustrezni, in jih odkrijete z raziskovanjem na LinkedInu, Facebooku ipd. ali z uporabo poimenovalnih konvencij, kot sta »webmaster@example.com« ali »security@example.com«.

  • Je to v redu?

  • Ali se to šteje za neželeno e-pošto?

  • Ali se to šteje za nepooblaščeno e-pošto?

Izključene skupine

Primer: ste v izključeni skupini, na primer mladoletni ste ali ste na seznamu sankcij ali v državi na seznamu sankcij.

  • Ali je v redu, da pošljete poročilo?

  • Ali je v redu poročati anonimno?

  • Ali je v redu namerno spremeniti potencialno identifikacijske podatke, na primer da bi se izognili izključeni skupini, s ciljem, da razkritje doseže prave ljudi?

Tretja oseba

Primer: odkrijete, da ima programska oprema podjetja napako, ki vključuje tretjo osebo, na primer integracijo z drugo programsko opremo ali drugim spletnim mestom.

  • Ali je v redu, da vse informacije, ki jih najdete, prijavite obema stranema?

  • Ali je treba opraviti dve različni odgovorni razkritji, na primer eno poročilo enemu podjetju in drugo poročilo podjetju tretje osebe, s ciljem omejiti informacije, poslane vsakemu podjetju?

  • Ali je odkritelju dovoljeno, da podjetji poveže med seboj?

Moteča programska oprema

Primer: ste dovolj vešči, da lahko napišete virus, za katerega menite, da bo verjetno pomagal uporabnikom zaščititi se pred varnostnim tveganjem, ugotoviti, ali so ogroženi, ali odpraviti varnostno tveganje.

  • Je to v redu?

  • Ali je odkritelju dovoljeno uporabnike usmeriti na takšno programsko opremo in/ali na vodnike ali vadnice, ki opisujejo, kako ustvariti takšno programsko opremo?

Koordinirano razkrivanje ranljivosti proti odgovornemu razkrivanju

Koordinirano razkrivanje ranljivosti je prednostni izraz.

  • Najpomembnejši vidik je koordinacija med odkriteljem in proizvajalcem.

Odgovorno razkrivanje je zastarel izraz.

  • Ljudje imajo različne poglede na to, kaj pomeni biti odgovoren. Nekateri na primer zagovarjajo, da je odgovorno, če odkritelj takoj obvesti javnost ne glede na kakršno koli interakcijo s proizvajalcem, in neodgovorno, če izvede koordinirano razkrivanje ranljivosti, ker to javnosti prikriva informacije.

Sledenje