Coordinated vulnerability disclosure

Koordineeritud haavatavuste avalikustamine (CVD)

Kuidas turvanõrkustest teatada, neid vastu võtta ja koordineerida, koos näidispoliitikatega.

Koordineeritud haavatavuste avalikustamine (Coordinated vulnerability disclosure, CVD) on arvutiturbe mõiste. See kirjeldab, kuidas inimesed saavad turvaprobleemide kohta aruandeid jagada. Näiteks vigade aruanded, sissetungiohud, häkkimisohud, andmelekked, veebisaitide rikkumised jne.

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

Sisukord:

Poliitikad:

Sissejuhatus

See dokument selgitab koordineeritud haavatavuste avalikustamist viisil, mis võib aidata inimestel koostööd teha.

Dokumendi eesmärgid:

  1. Aidata inimesi, kes avastavad turvaprobleeme ja soovivad neist teatada.

  2. Aidata ettevõtete esindajatel mõista vastutustundliku avalikustamise vajadusi, eesmärke, tavasid ja erijuhte.

  3. Lisada hoidla kausta näidised koordineeritud haavatavuste avalikustamise poliitikatest.

Ootame tõmbepäringuid (pull request), GitHubi probleemiteateid (issue) või e-kirju aadressil security@joelparkerhenderson.com.

Mis on koordineeritud haavatavuste avalikustamine?

Koordineeritud haavatavuste avalikustamine kirjeldab kolme sammu olukorras, kus keegi avastab turvaprobleemi (näiteks tarkvaraviga) ja soovib sellest teatada tootjale (näiteks tarkvara valmistavale ettevõttele).

Sammud:

  1. Avastaja teatab probleemist tootjale privaatselt ja heas usus.

  2. Tootja püüab heas usus kaitsta kasutajaid ja probleemi lahendada.

  3. Pärast kokkulepitud aja möödumist tehakse turvaprobleem avalikuks.

1. samm: teata probleemist

  1. samm on avastaja ülesanne: teata probleemist privaatselt ja heas usus.

  • Hea: avastaja saadab asjakohase teabe tootjale, näiteks e-kirjaga tootja turvalisuse e-posti aadressile (tavaliselt „security@example.com") või tootja veebisaidi veebivormi kaudu (tavaliselt „https://www.example.com/security").

  • Halb: aruande postitamine avalikus ajaveebis, meedia teavitamine, ähvardused, katsed müüa turvaprobleemi häkkeritele jne.

  • Nõuanne: avastaja võib otsustada jääda anonüümseks; ka tootja võib otsustada jääda anonüümseks.

Soovi korral jätka probleemiga kursis olemist.

  • Hea: suhtluskanalite avamine, lisateabe andmine või olukorra jälgimine.

  • Halb: probleemi unustamine.

  • Nõuanne: avastaja võib otsustada, kas aidata või mitte, ning kas suhelda või mitte, ja võib korraldust muuta, kui asjaolud muutuvad.

Soovi korral avalikusta probleem teistele.

  • Hea: määratud aja ootamine ja seejärel avalikuks tulemine, näiteks asjakohase teabe postitamine turvauudiste saidile, asjakohaste kolmandate osapoolte turvateadlaste kontakteerimine või probleemi teatavaks tegemine mis tahes avalikus sotsiaalvõrgustikus jne.

  • Halb: probleemi teistele mitte avalikustamine, välja arvatud juhul, kui see põhjustaks endale või teistele proportsionaalselt suuremat riski.

  • Nõuanne: kui asjaolud muutuvad, näiteks avastatakse suurem risk või aktiivne ärakasutamine looduses, võib avastaja probleemi teistele varem avalikustada.

2. samm: taga kontaktid

  1. samm on tootja ülesanne: taga, et kontaktid on kasutatavad.

  • Hea: tootja avaldab turvalisuse kontakt-e-posti aadressi (tavapäraselt „security@example.com") ja ideaalis turvalise e-posti krüpteerimisvõtme.

  • Hea: tootja avaldab turvalisuse kontaktveebilehe (tavapäraselt „https://www.example.com/security") ja teeb lehe ideaalis lihtsasti leitavaks, näiteks veebisaidi jaluse, saidikaardi ja otsingu kaudu.

  • Halb: tootja ei paku e-posti aadressi ega veebilehte või ei tee neid lihtsasti leitavaks.

Taga töötajate suutlikkus.

  • Hea: tootja õpetab klienditoe töötajatele, mida teha turvapäringu saabumisel, näiteks kuidas vastata kontaktandmetega või kuidas suunata päring õigele sisemisele meeskonnale.

  • Hea: tootja kontrollib perioodiliselt, et töötajate suutlikkus toimib.

  • Halb: tootja ei õpeta ega kontrolli.

Vasta avastajale ajakava piires.

  • Kui avastaja ajakava ei määra, kasuta ühte tööpäeva, sest see on tööstusstandard ja praegune tööstuse parim tava.

  • Kui avastaja esitab küsimusi, vasta neile. See on eriti oluline, kui avastaja küsib testimiseks luba. Taga, et kõik vastused on selged ja otsekohesed.

Vasta avastajale volitatud turvakontakti ja/või volitatud turvaprotsessi kaudu.

  • Hea: vastus turvalisusele pühendatud e-posti aadressilt, näiteks „security@example.com".

  • Näiteks need on halvad: vastus üldotstarbeliselt e-posti aadressilt, näiteks „help@example.com", või kelleltki, kes ei ole volitatud turvaspetsialist.

Anna avastajale teada, et probleem on tunnistatud turvaaruandeks.

  • Hea: turvalisusele omane sõnastus, näiteks „Meie turvameeskond on saanud teie vastutustundliku avalikustamise aruande", „Meie turvaprotsessil on järgmised sammud" või „Teie teave on nüüd meie turvajälgijas id-numbriga XYZ" jne.

  • Halb: üldine sõnastus, näiteks „Hindame teie ostusoovi", „Võtame turvalisust tõsiselt", või vastutuse üleandmise sõnastus, näiteks „Saatsime teie e-kirja teisele osakonnale" jne.

3. samm: tegutse heas usus

  1. samm on avastaja ja tootja ühine ülesanne: tegutse heas usus.

Mõista, et koordineeritud haavatavuste avalikustamine kirjeldab head usku järgivat protsessi.

    1. eesmärk on hea usk aidata kasutajatel end turvariskide eest kaitsta.
    1. eesmärk on hea usk turvaprobleem lahendada.

  • Avastaja ja/või tootja võib heas usus otsustada kaasata teisi turvainimesi, näiteks pöörduda teiste asjakohaste turvateadlaste poole, et nad probleemiga aitaksid.

Mõista, et koordineeritud haavatavuste avalikustamine ei tekita mingeid kohustusi.

  • Avastaja ja/või tootja võib igal ajal ükskõik mis põhjusel loobuda, hoiatusega või ilma. On viisakas hoida kõiki asjaosalisi kursis ja teavitatuna, kuid see ei ole alati võimalik, praktiline ega soovitav.

  • Koordineeritud haavatavuste avalikustamine ei loo õiguslikku kokkulepet. Kui avastajal ja tootjal on juba õiguslik kokkulepe, soovitame kõigil asjaosalistel pöörduda asjakohaste juristide poole; ära kasuta seda dokumenti õigusnõuandena.

Mõista, et koordineeritud haavatavuste avalikustamine püüab kasutada head suhtlust ja lükata ähvardused tagasi.

  • Koordineeritud haavatavuste avalikustamine toimib kõige paremini siis, kui kõik asjaosalised mõistavad, et 1. eesmärk on aidata kasutajatel end turvariskide eest kaitsta ja 2. eesmärk on turvaprobleem lahendada.

  • Koordineeritud haavatavuste avalikustamine lükkab tagasi igasugused kättemaksu, hirmutamise, peatamise, tühistamise, väljapressimise, järelkäimise koormuse või ohvri süüdistamise ähvardused.

Mõista, et koordineeritud haavatavuste avalikustamine võib eri inimestele tähendada erinevat.

  • Avastajal ja tootjal võib olla koordineeritud haavatavuste avalikustamisest erinev arusaam. Need arusaamad ei pruugi omavahel ühtida. Hea usk hõlmab seda, et kõik asjaosalised sellest aru saavad.

  • Mõned tootjad avaldavad koordineeritud haavatavuste avalikustamise poliitikaid. Need võivad olla kasulikuks juhiseks. Kui avastaja otsustab kasutada mõnda teist liiki koordineeritud haavatavuste avalikustamist või tal on vastutustundliku avalikustamise kohta teistsugune arusaam, on see täiesti korras.

Mõista, et tavaliselt teeb avastaja avaldajale teene.

  • Tavaliselt ei vaja avastaja haavatavuste avaldamiseks kellegi luba.

  • Tavaliselt on avastaja teave avaldajale kasulik.

Edu kontrollimine

Pärast probleemi lahendamist peab tootja edu kontrollima.

  • Kas kõik inimesed ja protsessid käsitlesid avalikustamist edukalt? Kui jah, siis hea. Kui ei, siis kaalu järeltegevuse uuringut, näiteks algpõhjuse analüüsi (RCA), tagantjärele analüüsi aruandeid, Ishikawa diagramme või süsteemiteoorial põhinevat põhjuslikku analüüsi (CAST).

  • Kas lahendamata probleemid on kokku sorteeritud (triage) ja jälgitud?

  • Kas tootja ja avastaja mõistavad mõlemad, mida järgmiste sammude jaoks teha? Seda on eriti oluline õigesti teha juhuks, kui peaks tulema uusi koordineeritud haavatavuste avalikustamisi.

Juhised

Koordineeritud haavatavuste avalikustamise juhised võivad tulla paljudest valdkondadest, näiteks eetikaekspertidelt, õiguskaitsjatelt, avalikkuse põhjendatud ootustest jne.

Kui otsid juhiseid, võivad sind huvitada need kolm valdkonda, mida kirjeldame allpool.

  • Hea samaarlane

  • Päästmiskohustus

  • Hoolsuskohustus

Hea samaarlane

Vikipeedia: Good Samaritan law

Hea samaarlase seadused pakuvad õiguskaitset inimestele, kes osutavad mõistlikku abi neile, kes on vigastatud, haiged, ohus või muul viisil töövõimetud või keda nad selleks peavad. Kaitse eesmärk on vähendada pealtnäijate kõhklust aidata hirmust, et neid kaevatakse kohtusse või nende vastu algatatakse süüdistus.

Päästmiskohustus

Vikipeedia: Duty to rescue

Päästmiskohustus on mõiste, mis kirjeldab olukorda, kus osapoolt võib pidada vastutavaks selle eest, et ta ei tulnud ohus oleva teise osapoole appi. Päästmiskohustusel võivad olla moraalsed ja/või õiguslikud tahud.

Hoolsuskohustus

Vikipeedia: Duty of care

Hoolsuskohustus on kohustus järgida mõistliku hoolsuse standardit mis tahes tegevuse juures, mis võib ettenähtavalt teistele kahju tekitada. Hoolsuskohustusel võivad olla moraalsed ja/või õiguslikud tahud. Kaaluda tuleb näiteks järgmist: kahju või vigastuse ettenähtavus, võimaliku kahju või vigastuse võimalik ulatus, kostja tegevuse tähtsus või ühiskondlik väärtus, tegevuse kasulikkus kostjale, alternatiivse tegevuse teostatavus, alternatiivse tegevusega seotud kulud ja koormus, alternatiivse tegevuse suhteline kasulikkus ning alternatiivse tegevuse suhteline ohutus.

Erijuhud

Meie turvameeskonnad on näinud laia valikut erijuhte.

Kirjeldame neid siin, et aidata inimestel mõista, kus on arvamused selle kohta, mis võib olla korras ja mis mitte, väga erinevad. Soovitame, et kõik asjaosalised räägiksid neist heas usus.

Teiste kasutajate teabele juurdepääs

Näide: avastad, et URL-is on sinu kasutaja id, see paljastab vea ja sa usud, et saad URL-i muutes asendada oma kasutaja id mõne teise kasutaja id-ga.

  • Kas avastajal on lubatud seda teha, näiteks ainsa eesmärgiga selgitada välja, kas see mõjutab ka teisi kasutajaid?

  • Kas on olulisem mõista kiiresti riski ulatust kõigi kasutajate jaoks kui kaitsta paari kasutajat, kelle teave võib häkkeritele juba nähtav olla?

  • Kas avastajal on lubatud seda teha nii paljude kasutajatega, kui soovid?

  • Kas avastajal on lubatud proovida kasutajatega ühendust võtta, et neile teada anda, et nad on mõjutatud? Kas on lubatud pakkuda leevendusnõuandeid?

Teenusetõkestus

Näide: avastad vea, mis kogemata peatab sinu konto, näiteks käivitab parooliluku.

  • Kas seda peetakse teenusetõkestusründeks?

Soovimatu e-kiri

Näide: püüad turvaprobleemist teatada ettevõtte inimestele, keda pead asjakohaseks ja kelle leiad LinkedInist, Facebookist jne uurides või nimetavade abil, näiteks „webmaster@example.com" või „security@example.com".

  • Kas see on korras?

  • Kas seda peetakse soovimatuks e-kirjaks?

  • Kas seda peetakse volitamata e-kirjaks?

Välistatud rühmad

Näide: kuulud välistatud rühma, näiteks oled alaealine või sanktsioonide nimekirjas või sanktsioonide nimekirjas olevas riigis.

  • Kas sul on lubatud aruanne esitada?

  • Kas on lubatud teatada anonüümselt?

  • Kas on lubatud tahtlikult muuta potentsiaalselt tuvastavat teavet, näiteks välistatud rühmast pääsemiseks ja eesmärgiga aidata avalikustamisel jõuda õigete inimesteni?

Kolmas osapool

Näide: avastad, et ettevõtte tarkvaral on viga, mis hõlmab kolmandat osapoolt, näiteks lõimimist teise tarkvaraga või teise veebisaidiga.

  • Kas sul on lubatud teatada kogu leitud teabest mõlemale osapoolele?

  • Kas on vaja teha kaks eraldi vastutustundlikku avalikustamist, näiteks üks aruanne ühele ettevõttele ja teine aruanne kolmanda osapoole ettevõttele, eesmärgiga piirata kummalegi ettevõttele saadetavat teavet?

  • Kas avastajal on lubatud viia ettevõtted omavahel kontakti?

Häiriv tarkvara

Näide: oled piisavalt osav, et kirjutada viirus, mis sinu arvates tõenäoliselt aitab kasutajatel end turvariski eest kaitsta, tuvastada, kas nad on ohus, või turvarisk parandada.

  • Kas see on korras?

  • Kas avastajal on lubatud suunata kasutajaid sellisele tarkvarale ja/või juhenditele või õpetustele, mis kirjeldavad, kuidas seda liiki tarkvara luua?

Koordineeritud haavatavuste avalikustamine vs vastutustundlik avalikustamine

Koordineeritud haavatavuste avalikustamine on eelistatud termin.

  • Kõige olulisem aspekt on koordineerimine avastaja ja tootja vahel.

Vastutustundlik avalikustamine on iganenud termin.

  • Inimestel on erinev arusaam sellest, mida tähendab vastutustundlik olla. Näiteks mõned inimesed väidavad, et avastaja jaoks on vastutustundlik teavitada avalikkust koheselt, sõltumata mis tahes suhtlusest tootjaga, ning koordineeritud haavatavuste avalikustamine on vastutustundetu, sest see varjab teavet avalikkuse eest.

Jälgimine