Sisu
- Lihtsalt faktid
- Pole vigu ega stressi - teie samm-sammuline juhend elumuutva tarkvara loomiseks ilma oma elu hävitamata
- Mõju arvestamine?
- Kas on aeg süsteemi muuta?
Allikas: BrianAJackson / iStockphoto
Ära võtma:
On aeg mõelda asjale, kuidas mõtleme avatud lähtekoodiga komponentide riski hindamisele.
Kergelt öeldes on väljakutse sellise süsteemi väljatöötamine, mille abil hinnata, kui tõsiselt tarkvaraarenduse kogukond haavatavusi peaks võtma. Koodi on kirjutanud inimesed ja sellel on alati vigu. Kui eeldame, et miski ei saa kunagi täiuslikuks, on küsimus, kuidas kõige paremini liigitada komponente nende riski järgi viisil, mis võimaldab meil produktiivset tööd jätkata?
Lihtsalt faktid
Ehkki selle probleemi lahendamiseks on palju erinevaid lähenemisviise, millel kõigil on oma kehtiv põhjendus, näib kõige levinum meetod põhinevat kvantitatiivsel mudelil.
Ühelt poolt võib haavatavuse tõsiduse hindamisel kasutada kvantitatiivset lähenemisviisi, kuna see on objektiivsem ja mõõdetavam, tuginedes üksnes haavatavusega seotud teguritele.
Selles metoodikas vaadeldakse, millist kahju võiks haavatavuse ärakasutamine tekitada, võttes arvesse, kui laialdaselt kasutatakse komponenti, teeki või projekti kogu tarkvaratööstuses, ning ka selliseid tegureid, nagu millist juurdepääsu võiks see ründajale anda vrakkide laastamine, kui nad peaksid seda oma eesmärgi rikkumiseks kasutama. Sellised tegurid nagu lihtne potentsiaalne kasutatavus võivad siin skoori mõjutamisel mängida suurt rolli. (Lisateavet turvalisuse kohta leiate küberturvalisusest: kuidas uued edusammud toovad uusi ohte - ja asepresidendiks.)
Kui tahame vaadata makrotasandil, vaadeldakse kvantitatiivses perspektiivis seda, kuidas haavatavus võiks karja kahjustada, keskendudes vähem kahjustustele, mis võivad langeda rünnaku alla sattunud ettevõtetele.
Riiklik haavatavuse andmebaas (NVD), ehk kõige tuntum turvaaukude andmebaas, kasutab seda lähenemisviisi nii versioonide 2 kui ka 3 jaoks - nende ühise haavatavuse punktisüsteem (CVSS). Lehel, mis selgitab haavatavuste hindamise mõõdikuid, kirjutavad nad oma meetodist, mis:
Selle kvantitatiivne mudel tagab korduva täpse mõõtmise, võimaldades samal ajal kasutajatel näha aluseks olevaid haavatavuse karakteristikuid, mida kasutati hinnete koostamisel. Seega sobib CVSS hästi standardseks mõõtesüsteemiks tööstustele, organisatsioonidele ja valitsustele, kes vajavad täpseid ja järjepidevaid haavatavuse mõju hindeid.
Mängitavate kvantitatiivsete tegurite põhjal suudab NVD leida tõsidusskoori, nii nende skaalal oleva arvuga - 1 kuni 10, 10 on kõige raskemad - kui ka madala, keskmise ja kõrge kategooriaga .
Pole vigu ega stressi - teie samm-sammuline juhend elumuutva tarkvara loomiseks ilma oma elu hävitamata
Te ei saa oma programmeerimisoskusi parandada, kui keegi tarkvara kvaliteedist ei hooli.
Mõju arvestamine?
Kuid näib, et NVD püüab jääda selgusetuks sellest, mida võime nimetada haavatavuse kvalitatiivsemaks mõõdupuuks, lähtudes sellest, kui mõjusalt on teatud ärakasutamine kahju tekitanud. Ausalt öeldes hõlmavad need mõju niivõrd, kuivõrd mõõdavad haavatavuse mõju süsteemile, võttes arvesse konfidentsiaalsuse, terviklikkuse ja käideldavuse tegureid. Need on kõik olulised elemendid, mida tuleks vaadata - nagu hõlpsamini mõõdetava juurdepääsuvektori, juurdepääsu keerukuse ja autentimise puhul -, kuid nad ei pea ülesandeks seostada reaalmaailma mõju, kui haavatavus põhjustab organisatsioonile tegelikke kaotusi.
Võtame näiteks Equifaxi rikkumise, mis paljastas umbes 145 miljoni inimese isikuandmeid, sealhulgas nende juhiloa üksikasjad, sotsiaalkindlustuse numbrid ja muud bitid, mida ebaausad tegelased võisid kasutada massiliste pettuste läbiviimiseks.
Just selle haavatavuse (CVE-2017-5638) abil, mis avastati projektis Apache Struts 2, kasutas Equifax nende veebirakenduses, mis võimaldas ründajatel välisuksest välja kõndida ja lõpuks need välja tõsta kätega, mis olid täis mahlast isiklikku teavet .
Ehkki NVD andis sellele õigustatult raskusastme 10 ja HIGH, oli nende otsus tingitud võimaliku kahju kvantitatiivsest hindamisest ning seda ei mõjutanud ulatuslik kahju, mis tekkis hiljem, kui Equifaxi rikkumine avalikustati.
See ei ole NVD järelevalve, vaid osa nende väljakuulutatud poliitikast.
NVD pakub CVSS-i "põhiskoori", mis tähistavad iga haavatavuse kaasasündinud omadusi. Me ei paku praegu "ajalisi hindeid" (mõõdikud, mis muutuvad aja jooksul haavatavuse väliste sündmuste tõttu) ega "keskkonnanäitajaid" (hinded, mis on kohandatud haavatavuse mõju kajastamiseks teie organisatsioonis).
Otsustajate jaoks peaks kvantitatiivne mõõtesüsteem olema vähem oluline, kuna ta uurib võimalusi, kuidas see levitab kahju kogu tööstuses. Kui olete mõne panga kodanikuühiskonna esindaja, peaksite muretsema selle kvalitatiivse mõju üle, mida ärakasutamine võib avaldada, kui seda kasutatakse kliendi andmetega tasumiseks või, mis veelgi hullem, nende raha tasumiseks. (Lisateave tehnika 5 kõige hirmutavama ohu eri tüüpi haavatavuste kohta.)
Kas on aeg süsteemi muuta?
Nii peaks Equifaxi kohtuasjas kasutatud Apache Strusts 2 haavatavus saama kõrgema asetuse, arvestades seda, kui ulatuslik kahju osutus, või muudaks nihe NVD-taolise süsteemi jaoks liiga subjektiivseks. sammu pidama?
Me anname endale loa, et NVD kirjeldatud keskkonnataseme või ajalise hinde koostamiseks vajalike andmete esitamine oleks erakordselt keeruline, avades vaba CVSS-i meeskonna juhid lõpmatu kriitika ja palju tööd NVD-le ja teistele nende andmebaaside värskendamiseks uue teabe ilmumise korral.
Muidugi on küsimus sellise skoori koostamise kohta, kuna tõenäoliselt pakuvad väga vähesed organisatsioonid vajalikke andmeid rikkumise mõju kohta, välja arvatud juhul, kui avalikustamisseadus seda nõuab. Uberi juhtumist nägime, et ettevõtted on valmis maksma kiiresti välja, lootes, et rikkumist ümbritsev teave ei jõua ajakirjandusse, et nad ei satuks avalikku tagasilööki.
Võib-olla on vaja uut süsteemi, mis hõlmaks haavatavuse andmebaasidest tehtud häid jõupingutusi ja lisab oma täiendava hinde, kui teave on kättesaadav.
Miks algatada see lisahindamise kiht, kui eelmine näib olevat kõik need aastad oma tööga piisavalt hästi hakkama saanud?
Ausalt öeldes lasub organisatsioonide vastutusel vastutus oma rakenduste eest. Ideaalses maailmas kontrolliks igaüks oma toodetes kasutatavate komponentide hindeid enne nende lisamist oma loendisse, saaks hoiatusi, kui varem ohututeks peetud projektides avastatakse uusi haavatavusi, ja rakendaks kõik vajalikud paigad ise .
Ehk kui oleks olemas nimekiri, mis näitas, kui hävitav võib mõni neist haavatavustest olla mõne organisatsiooni jaoks, võivad organisatsioonid tunda suuremat survet mitte riskida riskantsete komponentidega. Vähemalt võiksid nad astuda samme reaalse inventuuri saamiseks nende avatud lähtekoodiga raamatukogude kohta, mis neil juba olemas on.
Equifaxi fiasko tagajärjel krüptib tõenäoliselt rohkem kui üks C-taseme juht, et veenduda, et neil pole toodetes Strutsi haavatavat versiooni. On kahetsusväärne, et sellise ulatusega intsidendil oli vaja suruda tööstust võtma oma avatud lähtekoodiga turvalisust tõsiselt.
Loodetavasti mõjutab õppetund, et teie rakenduste avatud lähtekoodiga komponentide haavatavused võivad avaldada väga reaalseid tagajärgi, seda, kuidas otsustajad tähtsustavad turvalisust, valides sobivad tooted oma toodete ja klientide andmete turvalisuse tagamiseks.