Vsebina
- Samo dejstva
- Brez napak, brez stresa - vaš korak za korakom vodnik za ustvarjanje programske opreme, ki spreminja življenje, ne da bi vam uničila življenje
- Računovodstvo vpliva?
- Čas za spremembo sistema?
Vir: BrianAJackson / iStockphoto
Odvzem:
Čas je, da razmislimo o tem, kako razmišljamo o oceni tveganja za odprtokodne komponente.
Razvoj sistema za ocenjevanje, kako resno naj bi skupnost za razvoj programske opreme sprejela ranljivosti, izziven. Kodo pišejo ljudje in bo vedno imela pomanjkljivosti. Vprašanje je torej, če predpostavimo, da nikoli nič ne bo popolno, kako naj razvrstimo komponente glede na tveganje na način, ki nam omogoča, da bomo še naprej delali produktivno?
Samo dejstva
Čeprav je pri reševanju te težave mogoče uporabiti veliko različnih pristopov, vsak s svojo veljavno utemeljitvijo, se zdi, da najpogostejša metoda temelji na kvantitativnem modelu.
Po eni strani je uporaba kvantitativnega pristopa k presoji resnosti ranljivosti lahko koristna, ker je bolj objektivna in merljiva, temelji pa le na dejavnikih, povezanih z ranljivostjo.
Ta metodologija obravnava, kakšna škoda bi lahko nastala v primeru izkoriščanja ranljivosti, glede na to, kako široko se uporablja komponenta, knjižnica ali projekt v celotni programski industriji, pa tudi na dejavnike, na primer, kakšen dostop lahko napadalcu omogoči razbitina, če bi jo uporabili za kršenje cilja. Dejavniki, kot je lahka potencialna izkoriščenost, lahko pri tem vplivajo na rezultat. (Če želite več o varnosti, preverite spletno varnost: Kako novi napredki prinašajo nove grožnje - in vice Versa.)
Če želimo pogledati na makro ravni, kvantitativna perspektiva gleda na to, kako lahko ranljivost škodi čredi, manj pa se osredotoči na škodo, ki bi lahko padla na podjetja, ki jih napad dejansko dejansko prizadene.
Nacionalna zbirka podatkov o ranljivosti (NVD), ki je morda najbolj znana baza ranljivosti, uporablja ta pristop za različici 2 in 3 kot njihov skupni sistem ocenjevanja ranljivosti (CVSS). Na svoji strani, ki razlagajo svoje metrike za ocenjevanje ranljivosti, napišejo svojo metodo, ki:
Njen kvantitativni model zagotavlja ponovljivo natančno meritev, hkrati pa uporabnikom omogoča, da vidijo osnovne značilnosti ranljivosti, ki so bile uporabljene za ustvarjanje rezultatov. Tako je CVSS zelo primeren kot standardni sistem merjenja za panoge, organizacije in vlade, ki potrebujejo natančne in dosledne ocene učinka na ranljivost.
Na podlagi kvantitativnih dejavnikov lahko NVD nato pripravi oceno resnosti, tako številke na lestvici - od 1 do 10, pri čemer je 10 najtežjih - kot tudi kategorije NIZKA, SREDNJA in VISOKA .
Brez napak, brez stresa - vaš korak za korakom vodnik za ustvarjanje programske opreme, ki spreminja življenje, ne da bi vam uničila življenje
Ne morete izboljšati svojih programskih veščin, kadar nikogar ne skrbi za kakovost programske opreme.
Računovodstvo vpliva?
Vendar se zdi, da se NVD trudi, da ne bo več jasno, kaj lahko označimo kot bolj kvalitativno merilo ranljivosti, ki temelji na tem, kako močan vpliv je imel določen izkoristek pri povzročanju škode. Če smo pošteni, vključujejo vpliv, če merijo vpliv ranljivosti na sistem, ob upoštevanju dejavnikov zaupnosti, celovitosti in razpoložljivosti. Vse to so pomembni elementi, na katere je treba gledati - kot z lažje merljivim vektorjem dostopa, zapletenostjo dostopa in avtentikacijo - vendar se jim zdi, da bi povezali vpliv v resničnem svetu, ko ranljivost povzroči resničnim izgubam organizacije.
Vzemimo za primer kršitev opreme Equifax, ki je razkrila osebne podatke o približno 145 milijonih ljudi, vključno s podatki o vozniških dovoljenjih, številkami socialnega zavarovanja in drugimi bitji, ki bi jih lahko brezobzirni znaki uporabili za obsežne operacije goljufij.
Ravno ranljivost (CVE-2017-5638) je bila odkrita v projektu Apache Struts 2, ki ga je Equifax uporabil v svoji spletni aplikaciji, ki je napadalcem omogočil, da so se sprehodili skozi vhodna vrata in jih na koncu razkrili z rokami, polnimi sočnih osebnih podatkov .
Medtem ko mu je NVD upravičeno dodelila oceno resnosti 10 in VISOKO, je bila njihova odločitev posledica kvantitativne ocene morebitne škode, nanjo pa ni vplivala obsežna škoda, ki je nastala pozneje, ko je kršitev Equifaxa postala javna.
To ni nadzor NVD, ampak del njihove navedene politike.
NVD zagotavlja CVSS "osnovne ocene", ki predstavljajo prirojene značilnosti vsake ranljivosti. Trenutno ne ponujamo "časovnih rezultatov" (meritve, ki se sčasoma spreminjajo zaradi dogodkov, ki so zunaj ranljivosti) ali "okoljskih rezultatov" (ocene prilagojene tako, da odražajo vpliv ranljivosti na vašo organizacijo).
Za tiste, ki odločajo, bi moral biti količinski merilni sistem manj pomemben, saj preučuje možnosti, da bo škodo razširil po vsej industriji. Če ste CSO banke, bi vas morali skrbeti za kvalitativni vpliv, ki ga lahko ima izkoriščenec, če se uporablja za pobotanje s podatki vaše stranke ali še huje, njihov denar. (Preberite več o različnih vrstah ranljivosti v 5 najbolj strašnih nevarnosti v tehniki.)
Čas za spremembo sistema?
Torej bi morala biti ranljivost Apache Strusts 2, ki je bila uporabljena v primeru Equifax, deležna višje razvrstitve glede na to, kako obsežna se je izkazala škoda, ali bi se ta premik izkazal za preveč subjektivnega za sistem, kot je NVD, vztrajati?
Omogočamo, da bi bilo pripravo potrebnih podatkov, da bi dosegli "okoljski rezultat" ali "časovni rezultat", kot ga opisuje NVD, izjemno težko, kar bi odprlo vodje brezplačne ekipe CVSS do nenehnih kritik in veliko dela za NVD in druge za posodabljanje njihovih baz podatkov, ko se pojavijo nove informacije.
Seveda se postavlja vprašanje, kako bi sestavila takšno oceno, saj je zelo malo organizacij verjetno, da bodo ponudile potrebne podatke o vplivu kršitve, razen če jih zahteva zakon o razkritju. Iz primera Uber smo zasledili, da so podjetja pripravljena hitro izplačati v upanju, da informacije o kršitvi ne bodo dosegle v tisk, da se ne bi spopadle z javnim odzivom.
Morda je potreben nov sistem, ki bi lahko vključil dobre napore iz zbirk podatkov o ranljivosti in dodal svoj dodaten rezultat, ko bodo informacije na voljo.
Zakaj sprožiti to dodatno plast, če se zdi, da je prejšnja v teh letih dovolj dobro opravila svoje delo?
Iskreno, organizacija je odgovorna za svoje vloge. V idealnem svetu bi vsi preverili večino komponent, ki jih uporabljajo v svojih izdelkih, preden jih dodali v svoj zalog, prejeli opozorila, ko so v projektih, za katere se je prej mislil, da so varni, odkrili nove ranljivosti in sami izvedli potrebne popravke. .
Mogoče bi obstajal seznam, ki bi pokazal, kako uničujoče so lahko nekatere od teh ranljivosti za organizacijo, potem bi organizacije morda čutile večji pritisk, da se ne bi ujele s tveganimi komponentami. Vsaj bi lahko sprejeli dejanski seznam, katere knjižnice odprtega izvora že imajo.
Po fiasku Equifax se je več kot en izvršilni direktor na ravni C verjetno spopadel in se prepričal, da v svojih izdelkih nima ranljive različice Struts. Žal je bil incident takšnih razsežnosti, da je industrija spodbudila, da svojo varnost odprtega vira resno vzamejo.
Upajmo, da bo nauk, da lahko ranljivosti v odprtokodnih komponentah vaših aplikacij povzročijo resnične posledice, vplival na to, kako odločevalci dajejo prednost varnosti, izberejo ustrezna orodja za varstvo podatkov svojih izdelkov in strank.