Ranljivost proti tveganju: Kaj morajo vedeti odlocitelji

Skenirniki ranljivosti najdejo na stotine težav. V tipičnem podjetniškem okolju lahko prvo skeniranje vrne tisočere. Večina jih na noben smiseln način ni pomembna. Kljub temu redno vidam organizacije, ki jih ohromoti sam obseg ugotovitev: vsako obravnavajo kot enako nujno ali, še huje, prezrejo celotno poročilo, ker se zdi preveliko. Po osemnajstih letih pomoči organizacijam pri razumevanju varnostnih ugotovitev želim pojasniti razliko med ranljivostjo in tveganjem.

NIST obravnava tveganje glede na verjetnost in posledice, FIRST pa pojasnjuje uporabo CVSS in prilagoditev ocene kontekstu. Ocena tehnične resnosti sama ne nadomesti ocene poslovnega tveganja. NIST SP 800-30 Rev. 1: Guide for Conducting Risk Assessments; FIRST: CVSS v4.0 User Guide.

Ranljivost

Ranljivost je slabost, ki bi jo lahko izkoriščali. Je tehnično dejstvo, merljivo in objektivno. Nezakrpan strežnik Apache je ranljivost. SQL-vrivanje v spletnem obrazcu je ranljivost. Privzeto geslo na omrežni napravi je ranljivost. Skenirniki ranljivosti so dobri pri iskanju teh. Katalogizirajo znane slabosti, primerjajo različice programske opreme z bazami CVE in pripravijo poročila. Toda ranljivost sama po sebi vam pove zelo malo o tem, ali bi morali skrbeti zanjo.

Tveganje

Tveganje je verjetnost izkoriščanja, pomnožena z vplivom ob izkoriščanju. Tveganje zahteva poslovni kontekst. Nezakrpan strežnik Apache, ki gosti vaš javni portal za stranke, je povsem drugačno tveganje kot enak nezakrpan strežnik Apache na izoliranem notranjem razvojnem sistemu brez občutljivih podatkov. Tehnična ranljivost je enaka; tveganje pa je povsem drugačno. To razlikovanje je točka, kjer mnogi varnostni programi odpovedujejo. Vsako ranljivost obravnavajo enako, ker nimajo konteksta za razlikovanje.

Tveganje = Verjetnost x Vpliv

• Verjetnost: Ali je ranljivost izkoriščljiva v vašem specifičnem okolju? Je izpostavljena internetu ali dostopna le interno? Obstaja javni exploit? Se aktivno izkorišča v praksi? Ali izkoriščanje zahteva avtentikacijo ali poseben dostop? Med penetracijskimi testi pogosto najdem ranljivosti s "kritično" CVSS oceno, ki so dejansko neizkoriščljive zaradi omrežnih kontrol, zahtevanih predpogojev ali dejavnikov okolja. Nasprotno pa najdem "srednje" težave, ki so trivialno izkoriščljive in vodijo neposredno do občutljivih podatkov.
• Vpliv: Kakšen je najslabši možni izid, če je ta ranljivost izkoriščena? Do katerih podatkov bi bilo možno dostopati? Kateri sistemi bi bili lahko kompromitirani? Kakšen je poslovni vpliv v smislu finančne izgube, regulativnih kazni, škode ugledu ali operativne motnje? Kritična ranljivost na sistemu, ki ne vsebuje občutljivih podatkov in ne opravlja kritične funkcije, ima nizek vpliv ne glede na svojo CVSS oceno.

Okvir za prioritizacijo

1. Kritično + Izpostavljeno + Enostavno za izkoriščanje = Takoj popravite - To so ugotovitve, ki bi vas morale zbuditi ponoči. Internetno izpostavljena SQL-vrivanje z javnim exploit skriptom, nezakrpan VPN prehod z znano ranljivostjo za oddaljeno izvajanje kode, spletna aplikacija z obvodom avtentikacije. Te predstavljajo takojšnje, izvedljivo tveganje in jih je treba odpraviti v urah ali dnevih, ne tednih.
2. Kritično + Notranje + Težko za izkoriščanje = Kmalu popravite - Pomembno, a ne nujno. Samo notranja ranljivost, ki zahteva specifične pogoje za izkoriščanje, še vedno predstavlja tveganje, toda nujnost je nižja. Načrtujte odpravo znotraj rednega cikla krpanja, a ne dovolite, da se vleče mesece.
3. Nizek vpliv + Kakrsna koli izpostavljenost = Sprejmite ali popravite, ko je priročno - Razkritje informacij na neobčutljivih sistemih, ranljivosti za zavrnitev storitve na redundantnih storitvah ali teoretične napadalne poti, ki zahtevajo neverjetne verige dogodkov. Dokumentirajte odločitev o sprejemu tveganja in občasno preglejte, a ne dovolite, da te porabijo vire, potrebne za nujnejše težave.

Zakaj CVSS ocene niso dovolj

CVSS zagotavlja standardizirano oceno resnosti, a namenoma izključuje okoljski kontekst. CVSS 9,8 izgleda grozljivo, toda če je ranljiv sistem za več plastmi omrežnih kontrol in ne vsebuje občutljivih podatkov, je dejansko tveganje lahko minimalno. Nasprotno pa lahko CVSS 5,0 v vaši aplikaciji za obdelavo plačil predstavlja eksistencialno tveganje. Videl sem organizacije, ki so mesece odpravljale CVSS 9,8 na notranjem strežniku, medtem ko so prezrle CVSS 6,5 na API-ju za stranke, ki sem ga izkoriščal za pridobitev podatkov v manj kot eni uri. Kontekst je pomembnejši od ocen.

Pristop na podlagi tveganja

Učinkovito upravljanje ranljivosti se začne z razumevanjem vaših sredstev: katere sisteme imate, katere podatke hranijo in kako so izpostavljeni. Brez popisa in razvrstitve sredstev ne morete sprejemati utemeljenih odločitev o tveganju. Vedno priporočam, da organizacije najprej vložijo v upravljanje sredstev, preden vložijo v več orodij za skeniranje. Vedeti, kaj imate in koliko je vredno, je predpogoj za smiselno oceno tveganja.

Predstavitev tveganja vodstvu

Povedati upravnemu odboru "imamo 847 ranljivosti" je nesmiselno. Povedati jim "imamo tri nezakrpane sisteme, izpostavljene internetu, ki bi omogočili dostop do baze strank, kar bi prizadelo 200.000 zapisov in bi lahko zahtevalo presojo obveznosti prijave kršitve varstva osebnih podatkov" pa je izvedljivo. Vsakič, ko oddam poročilo, oblikujem vodstveni povzetek okoli poslovnega tveganja, ne tehnične resnosti. Številke CVE gredo v tehnični del. Vodstveni povzetek govori o tem, kaj bi se lahko zgodilo podjetju in koliko bi stalo. To je jezik, ki pomaga utemeljiti proračune za odpravo in organizacijske spremembe.

Povezano branje: Določanje prednosti pri odpravi ranljivosti; Komuniciranje varnostnega tveganja vodstvu.