Conţinut
- Doar faptele
- Fără bug-uri, fără stres - Ghidul dvs. pas cu pas pentru crearea de programe care schimbă viața fără a vă distruge viața
- Contabilitate pentru Impact?
- E timpul să schimbați sistemul?
Sursa: BrianAJackson / iStockphoto
La pachet:
Este timpul să agități lucrurile cu modul în care ne gândim la evaluarea riscurilor pentru componentele open-source.
Dezvoltarea unui sistem de evaluare a gradului de seriozitate a comunității de dezvoltare a software-ului ar trebui să-și asume vulnerabilitățile este o provocare. Codul este scris de oameni și va avea întotdeauna defecte. Întrebarea atunci, dacă presupunem că nimic nu va fi niciodată perfect, este cum să clasificăm cel mai bine componentele în funcție de riscul lor într-un mod care să ne permită să continuăm să lucrăm productiv?
Doar faptele
Deși există multe abordări diferite pe care le-am putea adopta pentru a aborda această problemă, fiecare cu propria lor justificare valabilă, cea mai comună metodă pare să se bazeze pe un model cantitativ.
Pe de o parte, folosirea unei abordări cantitative pentru evaluarea gravității unei vulnerabilități poate fi utilă, întrucât este mai obiectivă și măsurabilă, bazată exclusiv pe factorii legați de vulnerabilitatea în sine.
Această metodologie analizează ce fel de daune ar putea apărea în cazul în care vulnerabilitatea ar putea fi exploatată, luând în considerare cât de des este folosită componenta, biblioteca sau proiectul în întreaga industrie software, precum și factori precum ce tip de acces i-ar putea oferi unui atacator naufragiază ar trebui să o folosească pentru a-și încălca ținta. Factorii precum exploatabilitatea potențială ușoară pot juca un rol important aici în afectarea scorului. (Pentru mai multe despre securitate, verificați Cibersecuritatea: modul în care noile progrese aduc noi amenințări - și vice versa.)
Dacă dorim să privim la un nivel macro, perspectiva cantitativă analizează modul în care o vulnerabilitate ar putea răni efectivul, concentrându-se mai puțin pe daunele care ar putea afecta companiile care sunt lovite efectiv de atac.
Baza de date națională a vulnerabilităților (NVD), poate cea mai cunoscută bază de date despre vulnerabilități, adoptă această abordare pentru ambele versiuni 2 și 3 ale sistemului comun de notare a vulnerabilităților (CVSS). Pe pagina lor care explică valorile lor pentru evaluarea vulnerabilităților, ei scriu despre metoda lor care:
Modelul său cantitativ asigură măsurarea precisă repetabilă și permite utilizatorilor să vadă caracteristicile de vulnerabilitate de bază care au fost utilizate pentru generarea scorurilor. Astfel, CVSS este bine adaptat ca un sistem de măsurare standard pentru industrii, organizații și guverne care au nevoie de scoruri de impact precise și coerente de vulnerabilitate.
Pe baza factorilor cantitativi în joc, NVD este în măsură să vină cu un scor de severitate, atât cu un număr pe scara lor - 1 până la 10, cu 10 fiind cel mai sever - cât și pe categorii de LOW, MEDIUM și HIGH. .
Fără bug-uri, fără stres - Ghidul dvs. pas cu pas pentru crearea de programe care schimbă viața fără a vă distruge viața
Nu îți poți îmbunătăți abilitățile de programare atunci când nimeni nu îi pasă de calitatea software-ului.
Contabilitate pentru Impact?
Cu toate acestea, NVD pare să depună eforturi pentru a păstra clar ceea ce putem numi ca o măsură mai calitativă a unei vulnerabilități, bazată pe cât de impactant a fost o anumită exploatare în producerea daunelor. Pentru a fi corecte, acestea includ impactul în măsura în care acestea măsoară impactul vulnerabilității asupra sistemului, analizând factorii de confidențialitate, integritate și disponibilitate. Acestea sunt toate elementele importante pe care trebuie să le analizeze - cum ar fi vectorul de acces mai ușor măsurabil, complexitatea accesului și autentificarea - dar nu se simt în sarcina de a relaționa impactul real atunci când o vulnerabilitate provoacă pierderi reale unei organizații.
Luăm, de exemplu, breșa Equifax care a expus informațiile de identificare ale unor 145 de milioane de persoane, inclusiv detaliile permisului de șofer, numerele de securitate socială și alte biți care ar putea fi folosite de personaje fără scrupule pentru a efectua operațiuni masive de fraudă.
Vulnerabilitatea (CVE-2017-5638) a fost descoperită în proiectul Apache Struts 2 pe care Equifax l-a folosit în aplicația lor web care le-a permis atacatorilor să meargă pe ușa din față și, în cele din urmă, să-l scoată cu brațele pline de informații personale suculente. .
În timp ce NVD i-a acordat, pe bună dreptate, un scor de severitate de 10 și HIGH, decizia lor s-a datorat evaluării cantitative a daunelor sale potențiale și nu a fost afectată de daunele extinse care au apărut ulterior când încălcarea Equifax a devenit publică.
Aceasta nu este o supraveghere din partea NVD, ci o parte din politica lor declarată.
NVD oferă „scoruri de bază” CVSS care reprezintă caracteristicile înnăscute ale fiecărei vulnerabilități. În prezent, nu oferim „scoruri temporale” (valori care se schimbă în timp din cauza evenimentelor externe vulnerabilității) sau „scoruri de mediu” (scoruri personalizate pentru a reflecta impactul vulnerabilității asupra organizației dvs.).
Pentru factorii de decizie, sistemul de măsurare cantitativ ar trebui să conteze mai puțin, deoarece se uită la șansele ca acesta să răspândească daune în întreaga industrie. Dacă sunteți OSC-ul unei bănci, ar trebui să vă preocupați impactul calitativ pe care îl poate avea o exploatare dacă este folosit pentru a compensa cu datele clientului dvs. sau, mai rău, cu banii lor. (Aflați despre diferitele tipuri de vulnerabilități din Cele mai scumpe amenințări tehnice.)
E timpul să schimbați sistemul?
Așadar, vulnerabilitatea din Apache Strusts 2 care a fost utilizată în cazul Equifax ar trebui să primească un rang mai ridicat, având în vedere cât de mare s-a dovedit dauna sau ar face ca schimbarea să devină mult prea subiectivă pentru un sistem precum NVD să ține pasul?
Acordăm că venirea cu datele necesare pentru a veni cu un „scor de mediu” sau „punctaj temporal” așa cum este descris de NVD ar fi extrem de dificilă, deschizându-i pe managerii echipei gratuite CVSS până la critici neîntrerupte și o tonă de muncă. pentru NVD și altele pentru actualizarea bazelor de date pe măsură ce apar noi informații.
Există, desigur, întrebarea despre cum ar fi compilat un astfel de scor, întrucât foarte puține organizații pot oferi informațiile necesare cu privire la impactul unei încălcări, cu excepția cazului în care acestea sunt impuse de o lege de divulgare. Am văzut din cazul Uber că companiile sunt dispuse să plătească rapid în speranța ca informațiile din jurul unei încălcări să ajungă în presă, ca să nu se confrunte cu un atac public.
Poate că ceea ce este necesar este un nou sistem care ar putea să încorporeze eforturile bune din bazele de date cu vulnerabilități și să adauge propriul punctaj suplimentar atunci când informațiile devin disponibile.
De ce să instigăm acest nivel suplimentar de notare atunci când cel precedent pare să-și fi făcut treaba destul de bine în toți acești ani?
Sincer, se reduce responsabilitatea pentru organizații să își asume responsabilitatea pentru aplicațiile lor. Într-o lume ideală, toată lumea ar verifica scorurile componentelor pe care le folosesc în produsele lor înainte de a le adăuga la inventar, ar primi alerte atunci când sunt descoperite noi vulnerabilități în proiectele considerate anterior ca sigure și ar implementa corecțiile necesare pe cont propriu. .
Poate dacă ar exista o listă care arăta cât de devastatoare ar putea fi unele dintre aceste vulnerabilități pentru o organizație, organizațiile ar putea simți mai multă presiune să nu se prindă cu componente riscante. Cel puțin, ar putea lua măsuri pentru a face un inventar real al bibliotecilor open-source pe care le au deja.
În urma fiasco-ului Equifax, mai mult de un executiv la nivel de C era probabil să se scurgă pentru a se asigura că nu au versiunea vulnerabilă a Struts în produsele lor. Este nefericit că a fost nevoie de un incident de această amploare pentru a împinge industria să își ia serios securitatea.
Sperăm că lecția potrivit căreia vulnerabilitățile componentelor open-source ale aplicațiilor dvs. pot avea consecințe din lumea reală va avea un impact asupra modului în care factorii de decizie acordă prioritate securității, alegând instrumentele potrivite pentru a păstra în siguranță produsele și datele clienților.