Coordinated vulnerability disclosure

Divulgarea coordonată a vulnerabilităților (CVD)

Cum să raportați, să primiți și să coordonați vulnerabilitățile de securitate, cu politici exemplu.

Divulgarea coordonată a vulnerabilităților (Coordinated vulnerability disclosure, CVD) este un termen din securitatea informatică. Descrie modul în care oamenii pot împărtăși rapoarte despre probleme de securitate. Exemple sunt rapoartele de erori, riscurile de intruziune, avertismentele de hacking, scurgerile de date, breșele în site-uri web etc.

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

Cuprins:

Politici:

Introducere

Acest document explică divulgarea coordonată a vulnerabilităților în moduri care îi pot ajuta pe oameni să colaboreze.

Obiectivele documentului:

  1. Să ajute persoanele care descoperă probleme de securitate și vor să le raporteze.

  2. Să ajute reprezentanții companiilor să înțeleagă nevoile, obiectivele, practicile și cazurile speciale ale divulgării responsabile.

  3. Să includă în folderul depozitului exemple de politici de divulgare coordonată a vulnerabilităților.

Primim cu plăcere pull request-uri, probleme (issues) pe GitHub sau e-mailuri la security@joelparkerhenderson.com.

Ce este divulgarea coordonată a vulnerabilităților?

Divulgarea coordonată a vulnerabilităților descrie trei pași atunci când cineva descoperă o problemă de securitate (cum ar fi o eroare de software) și vrea să o raporteze producătorului (cum ar fi compania care face software-ul).

Pași:

  1. Descoperitorul raportează problema în privat și cu bună-credință producătorului.

  2. Producătorul încearcă cu bună-credință să protejeze utilizatorii și să abordeze problema.

  3. După o perioadă de timp stabilită, problema de securitate este făcută publică.

Pasul 1: Raportați problema

Pasul 1 este pentru descoperitor: raportați problema în privat și cu bună-credință.

  • Bine: descoperitorul trimite informațiile relevante producătorului, de exemplu prin e-mail la adresa de e-mail de securitate a producătorului (de obicei „security@example.com") sau printr-un formular pe pagina web a producătorului (de obicei „https://www.example.com/security").

  • Rău: postarea raportului pe un blog public, alertarea presei, amenințări sau încercări de a vinde problema de securitate hackerilor etc.

  • Sfat: descoperitorul poate alege să rămână anonim; și producătorul poate alege să rămână anonim.

Dacă doriți, rămâneți la curent cu problema.

  • Bine: deschiderea canalelor de comunicare, furnizarea de informații ulterioare sau monitorizarea situației.

  • Rău: uitarea problemei.

  • Sfat: descoperitorul poate alege să ajute sau nu și poate alege să comunice sau nu, și poate schimba aranjamentul dacă circumstanțele se schimbă.

Dacă doriți, divulgați problema și altora.

  • Bine: așteptarea perioadei specificate și apoi publicarea, de exemplu postarea informațiilor relevante pe un site de știri de securitate, contactarea cercetătorilor de securitate terți relevanți sau anunțarea problemei pe orice rețea socială publică etc.

  • Rău: nedivulgarea problemei altora, cu excepția cazului în care considerați că ar cauza un risc mai mare decât cel comparabil pentru dumneavoastră sau pentru alții.

  • Sfat: dacă circumstanțele se schimbă, de exemplu se descoperă un risc mai mare sau o exploatare activă în libertate (in the wild), descoperitorul poate divulga problema altora mai devreme.

Pasul 2: Asigurați contactele

Pasul 2 este pentru producător: asigurați-vă că contactele sunt viabile.

  • Bine: producătorul publică o adresă de e-mail de contact pentru securitate (convențional „security@example.com") și, ideal, o cheie sigură de criptare a e-mailului.

  • Bine: producătorul publică o pagină web de contact pentru securitate (convențional „https://www.example.com/security") și, ideal, face pagina ușor de descoperit, de exemplu prin subsolul site-ului, harta site-ului și căutare.

  • Rău: producătorul nu oferă o adresă de e-mail sau o pagină web ori nu le face ușor de descoperit.

Asigurați capacitățile personalului.

  • Bine: producătorul instruiește personalul de asistență ce să facă dacă primește o solicitare de securitate, de exemplu cum să răspundă cu informații de contact sau cum să transmită solicitarea echipei interne potrivite.

  • Bine: producătorul verifică periodic dacă capacitățile personalului funcționează.

  • Rău: producătorul nu instruiește sau nu verifică.

Răspundeți descoperitorului în intervalul de timp stabilit.

  • Dacă descoperitorul nu specifică un interval, folosiți o zi lucrătoare, deoarece acesta este standardul industriei și cea mai bună practică actuală din industrie.

  • Dacă descoperitorul pune întrebări, răspundeți-le. Acest lucru este deosebit de important dacă descoperitorul cere permisiunea de a testa. Asigurați-vă că toate răspunsurile sunt clare și directe.

Răspundeți descoperitorului printr-un contact de securitate autorizat și/sau un proces de securitate autorizat.

  • Bine: un răspuns de la o adresă de e-mail dedicată securității, cum ar fi „security@example.com".

  • De exemplu, acestea sunt rele: un răspuns de la o adresă de e-mail cu scop general, cum ar fi „help@example.com", sau de la oricine nu este un profesionist în securitate autorizat.

Comunicați descoperitorului că problema este recunoscută ca raport de securitate.

  • Bine: formulări specifice securității, cum ar fi „Echipa noastră de securitate a primit raportul dumneavoastră de divulgare responsabilă", sau „Procesul nostru de securitate are acești pași următori", sau „Informațiile dumneavoastră sunt acum în trackerul nostru de securitate cu numărul de id XYZ" etc.

  • Rău: formulări generale, cum ar fi „Apreciem afacerea dumneavoastră", sau „Luăm securitatea în serios", formulări de pasare a responsabilității, cum ar fi „V-am trimis e-mailul către alt departament" etc.

Pasul 3: Lucrați cu bună-credință

Pasul 3 este pentru descoperitor și producător împreună: lucrați cu bună-credință.

Înțelegeți că divulgarea coordonată a vulnerabilităților descrie un proces de bună-credință.

  • Obiectivul nr. 1 este buna-credință în a-i ajuta pe utilizatori să se protejeze de riscurile de securitate.

  • Obiectivul nr. 2 este buna-credință în abordarea problemei de securitate.

  • Descoperitorul și/sau producătorul pot alege cu bună-credință să implice alte persoane din securitate, de exemplu contactând alți cercetători de securitate relevanți pentru a ajuta cu problema.

Înțelegeți că divulgarea coordonată a vulnerabilităților nu creează nicio obligație.

  • Descoperitorul și/sau producătorul se pot retrage oricând, din orice motiv, cu sau fără avertisment. Este politicos să îi țineți pe toți cei relevanți informați și la curent, dar acest lucru nu este întotdeauna posibil, practic sau de dorit.

  • Divulgarea coordonată a vulnerabilităților nu creează niciun acord juridic. Dacă descoperitorul și producătorul au deja un acord juridic, sugerăm ca toți cei implicați să consulte avocații potriviți; nu folosiți acest document ca sfat juridic.

Înțelegeți că divulgarea coordonată a vulnerabilităților urmărește să folosească o comunicare bună și respinge amenințările.

  • Divulgarea coordonată a vulnerabilităților este cea mai bună când toți cei implicați înțeleg că obiectivul nr. 1 este să îi ajute pe utilizatori să se protejeze de riscurile de securitate, iar obiectivul nr. 2 este să abordeze problema de securitate.

  • Divulgarea coordonată a vulnerabilităților respinge orice fel de amenințare cu represalii, intimidare, suspendare, revocare, șantaj, povara urmăririi sau învinovățirea victimei.

Înțelegeți că divulgarea coordonată a vulnerabilităților poate însemna lucruri diferite pentru oameni diferiți.

  • Descoperitorul și producătorul pot avea înțelegeri diferite ale divulgării coordonate a vulnerabilităților. Aceste înțelegeri pot să nu se alinieze. Buna-credință include faptul că toți cei implicați înțeleg acest lucru.

  • Unii producători publică politici de divulgare coordonată a vulnerabilităților. Acestea pot fi îndrumări utile. Dacă un descoperitor alege să folosească un alt tip de divulgare coordonată a vulnerabilităților sau are o înțelegere diferită a divulgării responsabile, este absolut în regulă.

Înțelegeți că de obicei descoperitorul îi face o favoare editorului.

  • De obicei, descoperitorul nu are nevoie de permisiunea nimănui pentru a publica vulnerabilități.

  • De obicei, informațiile descoperitorului îl ajută pe editor.

Verificați succesul

După ce problema este rezolvată, producătorul trebuie să verifice succesul.

  • Au gestionat toți oamenii și procesele divulgarea cu succes? Dacă da, bine. Dacă nu, luați în considerare efectuarea unor cercetări post-acțiune, cum ar fi analiza cauzei principale (RCA), rapoarte post-mortem, diagrame Ishikawa sau analiza cauzală bazată pe teoria sistemelor (CAST).

  • Sunt problemele rămase triate (triage) și urmărite?

  • Înțeleg și producătorul, și descoperitorul ce trebuie făcut pentru orice pași următori? Este deosebit de important să se facă corect în cazul în care ar putea exista divulgări coordonate ulterioare ale vulnerabilităților.

Îndrumări

Îndrumările pentru divulgarea coordonată a vulnerabilităților pot veni din multe domenii, cum ar fi experți în etică, avocați juridici, așteptările rezonabile ale publicului larg etc.

Dacă căutați îndrumări, v-ar putea interesa aceste trei domenii, toate descrise mai jos.

  • Bunul samaritean

  • Obligația de salvare

  • Obligația de diligență

Bunul samaritean

Wikipedia: Good Samaritan law

Legile bunului samaritean oferă protecție juridică persoanelor care acordă asistență rezonabilă celor care sunt, sau despre care cred că sunt, răniți, bolnavi, în pericol sau altfel incapacitați. Protecția are scopul de a reduce ezitarea trecătorilor de a ajuta, de teama de a fi dați în judecată sau urmăriți penal.

Obligația de salvare

Wikipedia: Duty to rescue

O obligație de salvare este un concept care descrie o circumstanță în care o parte poate fi trasă la răspundere pentru că nu a sărit în ajutorul unei alte părți aflate în pericol. O obligație de salvare poate avea aspecte morale și/sau juridice.

Obligația de diligență

Wikipedia: Duty of care

O obligație de diligență este obligația de a respecta un standard de grijă rezonabilă în timpul efectuării oricăror acte care ar putea cauza în mod previzibil rău altora. O obligație de diligență poate avea aspecte morale și/sau juridice. Câteva aspecte de luat în considerare sunt: previzibilitatea prejudiciului sau a vătămării, amploarea posibilă a prejudiciului sau a vătămării potențiale, importanța sau valoarea socială a activității în care este angajat pârâtul, utilitatea conduitei pentru pârât, fezabilitatea conduitei alternative, costurile și poverile asociate conduitei alternative, utilitatea relativă a conduitei alternative și siguranța relativă a conduitei alternative.

Cazuri speciale

Echipele noastre de securitate au văzut o gamă largă de cazuri speciale.

Le descriem aici pentru a-i ajuta pe oameni să înțeleagă unde există o gamă largă de opinii despre ce poate fi în regulă și ce nu. Recomandăm ca toți cei implicați să comunice cu bună-credință despre acestea.

Accesarea informațiilor altor utilizatori

Exemplu: descoperiți că o adresă URL conține id-ul dumneavoastră de utilizator și dezvăluie o eroare și credeți că puteți edita adresa URL pentru a schimba id-ul dumneavoastră de utilizator cu un alt id de utilizator.

  • Este în regulă ca descoperitorul să facă acest lucru, de exemplu cu singurul scop de a descoperi dacă afectează și alți utilizatori?

  • Este mai important să se înțeleagă rapid amploarea riscului pentru toți utilizatorii decât să se protejeze câțiva utilizatori ale căror informații ar putea fi deja vizibile pentru hackeri?

  • Este în regulă ca descoperitorul să facă acest lucru cu câți utilizatori doriți?

  • Este în regulă ca descoperitorul să încerce să contacteze utilizatorii pentru a-i informa că sunt afectați? Este în regulă să ofere sugestii de atenuare?

Refuzul serviciului

Exemplu: descoperiți o eroare care vă suspendă accidental contul, de exemplu declanșând o blocare a parolei.

  • Este considerat acesta un atac de refuz al serviciului?

E-mail nesolicitat

Exemplu: încercați să raportați o problemă de securitate persoanelor din companie pe care le considerați relevante și pe care le descoperiți cercetând pe LinkedIn, Facebook etc. sau folosind convenții de denumire precum „webmaster@example.com" sau „security@example.com".

  • Este în regulă?

  • Este considerat e-mail nesolicitat?

  • Este considerat e-mail neautorizat?

Grupuri excluse

Exemplu: sunteți într-un grup exclus, cum ar fi minor, sau pe o listă de sancțiuni, sau într-o țară aflată pe o listă de sancțiuni.

  • Este în regulă să faceți un raport?

  • Este în regulă să raportați anonim?

  • Este în regulă să schimbați deliberat informații potențial identificatoare, de exemplu pentru a scăpa din grupul exclus și cu scopul de a ajuta divulgarea să ajungă la persoanele potrivite?

Terț

Exemplu: descoperiți că software-ul unei companii are o eroare care implică un terț, cum ar fi o integrare cu alt software sau alt site web.

  • Este în regulă să raportați toate informațiile pe care le găsiți ambelor părți?

  • Este necesar să faceți două divulgări responsabile diferite, de exemplu un raport către o companie și un alt raport către compania terță, cu scopul de a limita informațiile trimise fiecărei companii?

  • Este în regulă ca descoperitorul să pună companiile în legătură una cu cealaltă?

Software perturbator

Exemplu: sunteți suficient de priceput încât să puteți scrie un virus despre care credeți că probabil îi va ajuta pe utilizatori să se protejeze de riscul de securitate, să identifice dacă sunt în pericol sau să remedieze riscul de securitate.

  • Este în regulă?

  • Este în regulă ca descoperitorul să îi îndrume pe utilizatori către software de acest fel și/sau către ghiduri sau tutoriale care descriu cum se creează acest tip de software?

Divulgarea coordonată a vulnerabilităților vs. divulgarea responsabilă

Divulgarea coordonată a vulnerabilităților este termenul preferat.

  • Cel mai important aspect este coordonarea între descoperitor și producător.

Divulgarea responsabilă (responsible disclosure) este un termen depășit.

  • Oamenii au păreri diferite despre ce înseamnă a fi responsabil. De exemplu, unii oameni susțin că este responsabil ca descoperitorul să notifice imediat publicul indiferent de orice interacțiune cu producătorul și iresponsabil să facă divulgare coordonată a vulnerabilităților pentru că ascunde informații de la public.

Urmărire