Obsah
- Len fakty
- Žiadne chyby, žiadny stres - Váš sprievodca krok za krokom k vytvoreniu softvéru na zmenu života bez zničenia vášho života
- Účtovanie o dopade?
- Čas na zmenu systému?
Zdroj: BrianAJackson / iStockphoto
Zobrať:
Nastal čas, aby sme sa otriasli s tým, ako uvažujeme o hodnotení rizika pre komponenty s otvoreným zdrojom.
Výzvou je vyvinúť systém na hodnotenie toho, ako vážne by mala komunita vyvíjajúca softvér brať zraniteľné miesta. Kód je napísaný ľuďmi a vždy bude mať nedostatky. Potom, ak predpokladáme, že nič nebude dokonalé, je otázkou, ako najlepšie rozdeliť komponenty podľa ich rizika takým spôsobom, ktorý nám umožní pokračovať v produktívnej práci?
Len fakty
Aj keď existuje mnoho rôznych prístupov, ktoré by bolo možné pri riešení tohto problému prijať, každý s vlastným platným odôvodnením, zdá sa, že najbežnejšia metóda je založená na kvantitatívnom modeli.
Na jednej strane použitie kvantitatívneho prístupu k posudzovaniu závažnosti zraniteľnosti môže byť užitočné v tom, že je objektívnejšie a merateľnejšie, založené výlučne na faktoroch súvisiacich so samotnou zraniteľnosťou.
Táto metodika sa zameriava na to, aký druh poškodenia by sa mohol vyskytnúť, ak by sa zraniteľnosť mala zneužiť, pričom sa vezme do úvahy, ako často sa komponent, knižnica alebo projekt používa v softvérovom priemysle, ako aj faktory, ako napríklad aký prístup môže útočníkovi poskytnúť zničiť trosky, ak by ich použili na porušenie svojich cieľov. Pri ovplyvňovaní skóre tu môžu hrať veľkú úlohu faktory, ako je ľahká potenciálna využiteľnosť. (Viac informácií o zabezpečení nájdete v dokumente Cybersecurity: Ako nové pokroky prinášajú nové hrozby - a naopak).
Ak sa chceme pozrieť na makroúrovni, kvantitatívna perspektíva sa zameriava na to, ako by zraniteľnosť mohla poškodiť stádo, pričom sa menej zameriava na škody, ktoré by mohli utrpieť spoločnosti, ktoré sú skutočne zasiahnuté útokom.
Národná databáza zraniteľností (NVD), pravdepodobne najznámejšia databáza zraniteľností, používa tento prístup pre verzie 2 a 3 ako svoj spoločný systém klasifikácie zraniteľností (CVSS). Na svojej stránke vysvetľujúcej svoje metriky na hodnotenie zraniteľností píšu o svojej metóde, ktorá:
Jeho kvantitatívny model zabezpečuje opakovateľné presné meranie a umožňuje používateľom vidieť základné charakteristiky zraniteľnosti, ktoré boli použité na vygenerovanie skóre. CVSS je preto vhodný ako štandardný systém merania pre priemyselné odvetvia, organizácie a vlády, ktoré potrebujú presné a konzistentné skóre vplyvu zraniteľnosti.
Na základe kvantitatívnych faktorov pri hre je NVD schopný prísť so skóre závažnosti, a to tak s počtom na stupnici - 1 až 10, pričom 10 je najťažších - ako aj s kategóriami NÍZKA, STREDNÁ a VYSOKÁ ,
Žiadne chyby, žiadny stres - Váš sprievodca krok za krokom k vytvoreniu softvéru na zmenu života bez zničenia vášho života
Svoje programovacie schopnosti si nemôžete vylepšiť, keď sa nikto nestará o kvalitu softvéru.
Účtovanie o dopade?
Zdá sa však, že NVD sa snaží vyhnúť sa tomu, čo môžeme nazvať kvalitatívnejšou mierou zraniteľnosti, založenou na tom, aký vplyv má určité zneužívanie na spôsobovanie škôd. Aby boli spravodlivé, zahŕňajú vplyv, pokiaľ merajú vplyv zraniteľnosti na systém, pričom prihliadajú na faktory dôvernosti, integrity a dostupnosti. Sú to všetky dôležité prvky, na ktoré sa treba pozerať - napríklad s ľahšie merateľným prístupovým vektorom, zložitosťou prístupu a autentifikáciou -, ale necítia sa za úlohu spájať vplyv reálneho sveta, keď zraniteľnosť spôsobuje organizácii skutočné straty.
Zoberme si napríklad porušenie programu Equifax, ktoré odhalilo osobné identifikačné informácie asi 145 miliónov ľudí vrátane podrobností o vodičských preukazoch, číslach sociálneho zabezpečenia a ďalších bitov, ktoré by mohli bezohľadné postavy použiť na vykonávanie rozsiahlych podvodov.
Equifax, ktorý použil vo svojej webovej aplikácii, umožnil útočníkom vchádzať do predných dverí a nakoniec si ich vyzbrojiť pažami plnými šťavnatých osobných informácií, ktoré sa objavili v projekte Apache Struts 2, bola zraniteľnosť (CVE-2017-5638). ,
Aj keď mu NVD správne udelil skóre závažnosti 10 a VYSOKÉ, ich rozhodnutie bolo dôsledkom ich kvantitatívneho posúdenia jeho možnej škody a nebolo ovplyvnené rozsiahlou škodou, ktorá nastala neskôr, keď sa porušenie spoločnosti Equifax stalo verejným.
Nejde o dohľad zo strany NVD, ale o súčasť ich stanovenej politiky.
NVD poskytuje CVSS „základné skóre“, ktoré predstavuje vrodené vlastnosti každej zraniteľnosti. Momentálne neposkytujeme „časové skóre“ (metriky, ktoré sa v priebehu času menia v dôsledku udalostí, ktoré sú mimo zraniteľnosti) alebo „environmentálne skóre“ (skóre prispôsobené tak, aby odrážalo dopad zraniteľnosti na vašu organizáciu).
Pre osoby s rozhodovacou právomocou by mal systém kvantitatívneho merania menej záležať, pretože sa zameriava na šance, že rozšíri škody v celom odvetví. Ak ste CSO banky, mali by ste sa zaoberať kvalitatívnym dopadom, ktorý môže mať zneužívanie, ak sa používa na vyrovnanie s údajmi zákazníka, alebo ešte horšie, s ich peniazmi. (Viac informácií o rôznych druhoch zraniteľností nájdete v článku 5 najstrašších hrozieb v technike.)
Čas na zmenu systému?
Preto by zraniteľnosť v Apache Strusts 2, ktorá bola použitá v prípade Equifax, mala dostať vyššie hodnotenie vzhľadom na to, aké veľké škody sa ukázali byť, alebo by sa posun ukázal ako príliš subjektívny pre systém ako NVD na pokračuj?
Priznávame, že prísť s potrebnými údajmi, aby sme mohli prísť s „environmentálnym skóre“ alebo „časovým skóre“, ako je opísané v NVD, by bolo nesmierne ťažké, čím by sa manažéri voľného tímu CVSS otvorili nekonečnej kritike a veľa práce. pre NVD a ďalšie pre aktualizáciu ich databáz podľa nových informácií.
Existuje, samozrejme, otázka, ako by sa takéto skóre zostavilo, pretože len veľmi málo organizácií pravdepodobne poskytne potrebné údaje o vplyve porušenia, pokiaľ sa od nich nevyžaduje zákon o zverejňovaní. Z prípadu Uber sme videli, že spoločnosti sú ochotné rýchlo vyplácať v nádeji, že zabránia tlači, aby informácie v okolí porušili verejnú vôľu.
Možno je potrebný nový systém, ktorý by mohol začleniť dobré úsilie z databáz zraniteľností a pridať ďalšie vlastné skóre, keď budú k dispozícii informácie.
Prečo podnecovať túto ďalšiu vrstvu bodovania, keď sa zdá, že predchádzajúca vrstva vykonala svoju prácu dostatočne dobre počas všetkých týchto rokov?
Úprimne povedané, je na zodpovednosti organizácií, aby prevzali zodpovednosť za svoje aplikácie. V ideálnom svete by každý pred pridaním do svojho inventára skontroloval skóre komponentov, ktoré používajú vo svojich produktoch, dostával varovania, keď sa v projektoch, ktoré sa predtým považovali za bezpečné, objavia nové zraniteľné miesta a všetky potrebné opravy implementuje sám. ,
Možno, keby existoval zoznam, ktorý by ukázal, aké zničujúce môžu byť niektoré z týchto zraniteľností pre organizáciu, potom by organizácie mohli cítiť väčší tlak, aby sa nechytili riskantných komponentov. Prinajmenšom by mohli podniknúť kroky na uskutočnenie skutočného inventára knižníc s otvoreným zdrojom, ktoré už majú.
V dôsledku fiaska v spoločnosti Equifax sa pravdepodobne viac ako jeden výkonný pracovník na úrovni C snažil zabezpečiť, aby vo svojich výrobkoch nemali zraniteľnú verziu Struts. Je poľutovaniahodné, že trvalo takúto udalosť, aby prinútilo priemysel brať svoju bezpečnosť otvoreného zdroja vážne.
Dúfajme, že lekcia, že zraniteľné miesta v otvorených zdrojových komponentoch vašich aplikácií môžu mať veľmi reálne dôsledky, bude mať vplyv na to, ako tí, ktorí rozhodujú, uprednostnia zabezpečenie, výberom vhodných nástrojov na zaistenie bezpečnosti ich produktov a údajov zákazníkov.