Závažnost každé zranitelnosti lze určit pomocí mezinárodního standardu CVSS (The Common Vulnerability Scoring System) [2], který ohodnocuje zranitelnosti čtyřmi stupni závažnosti (low, medium, high, critical). Nejzávažnější jsou samozřejmě zranitelnosti hodnocené stupněm critical, často mají významný dopad na CIA triádu systémů (důvěrnost, integrita, dostupnost) a jejich zneužití bývá jednodušší než u méně závažných zranitelností [3].

Z důvodu tohoto ohromného množství zranitelností, které tvoří značné riziko pro bezpečnost organizací, je nutné, aby byly zajištěny nástroje a procesy pro detekci, analýzu a odstranění zranitelností v síti. Tuto problematiku řeší Vulnerability Management [4][5].

Co znamená Vulnerability Management?

Označení Vulnerability Management je souhrnný název pro procesy a nástroje z oblasti řízení zranitelností. V tomto článku se budeme zaobírat převážně tou první částí, tedy procesem řízení zranitelností. Ten bychom mohli označit jako postup speciálně navržený tak, aby jeho výstupem bylo zmírnění nebo odstranění rizika vyplývajícího z přítomnosti dané zranitelnosti. Vulnerability Management je jedním ze základních kamenů síťové bezpečnosti a často je navázán také na řízení rizik (Risk Management) nebo na další bezpečnostní disciplíny.

Mezi základní činnosti v rámci procesu řízení zranitelností patří identifikace a analýza zranitelností, jejich prioritizace a jeden ze způsobů jejich vyřešení, což bude zmíněno později. S většinou těchto kroků by člověku zodpovědnému za bezpečnost sítě měly pomoci nástroje pro řízení zranitelností (Vulnerability Management Systems).

Není to jen o technologii

Zmiňované VMS nástroje jsou vhodným pomocníkem pro zajištění technické stránky řízení zranitelností, tedy pro detekci, analýzu, prioritizaci a reportování zranitelností. Vulnerability Management je ale hlavně o procesech, proto je důležité jim porozumět a pochopit jejich podstatu. Více méně každý autor píšící o procesu řízení zranitelností používá vlastní členění a fáze, proto ani neexistuje ten jediný správný postup. My se zaměříme na proces podle metodologie OWASP, která je dle našeho názoru velmi kvalitní a zároveň jednoduchá [6].

Proces řízení zranitelností můžeme rozdělit na tři základní fáze – fáze detekce, reportování a poslední fáze odstraňování zranitelností. Každá fáze má svá specifika a konkrétní činnosti, které v rámci každé fáze musí být provedeny.

Vše je nutné připravit

V přípravné fázi je nutné stanovit rozsah řízení zranitelností. Tedy zvolit, které systémy se budou skenovat, kdo bude za řízení zranitelností odpovědný a jak bude probíhat odstranění zranitelností nebo případná akceptace rizika. K tomu, abychom dokázali rozsah správně určit, potřebujeme znát všechna technická a procesní omezení, která mohou být překážkou pro dobře vykonávané řízení zranitelností. Může se jednat o nedostatečnou kvalifikaci pracovníků, kteří mají řízení zranitelností vykonávat, nebo o nedostatečné kapacity společnosti. S oběma problémy by měl správně nastavený nástroj pro detekci a analýzu zranitelností a proces řízení zranitelností velmi pomoci.

Nejprve je nutné to najít…

Prvním krokem fáze detekce je stanovit, které systémy budou do skenování zranitelností zahrnuty, jakým způsobem budou skenovány a v jakých intervalech a časových oknech. Většina VMS nástrojů dokáže skenovat různé typy systémů – operační systémy, databáze, webové servery, síťová zařízení, webové aplikace a další. V ideálním případě jsou skenovány všechny systémy v síti, včetně produkčního prostředí, DMZ nebo třeba doménových kontrolerů.

Typ skenování se odvíjí od typu skenovaného systému. Systémy pod kontrolou firemních administrátorů umístěné v LAN síti je nejlepší skenovat pomocí autentizovaného skenu. Jedná se o využití privilegovaných účtů s vyšším než běžným oprávněním. Naopak systémy umístěné mimo perimetr firmy je vhodné skenovat klasickým síťovým skenem, díky tomu lze zjistit, jak vypadají dané servery z pohledu útočníka.

Výhodou privilegovaného skenování je menší zátěž sítě a samotného skenovaného systému, jelikož skenování probíhá přímo na cílovém zařízení, a přesnější výsledky, neboť s využitím privilegovaného účtu lze odhalit i zranitelnosti v softwaru, který nekomunikuje na žádném síťovém portu. Privilegované skenování má však také své nevýhody, jednou z nich je nutné vytvořené účtu pro skenování na všech skenovaných systémech. To může být problém pro organizace s velkým počtem zařízení.

Při nastavování plánovaného času spuštění skenu je nutné brát v potaz využívání systému uživateli nebo dalšími systémy v síti. Často se skeny plánují na noční hodiny, nebo alespoň mimo pracovní dobu, aby nedošlo k omezení běžné činnosti systému. Skenovací interval se vždy nastavuje podle kritičnosti skenovaných systémů, pro kritické produkční servery je vhodné nastavit skenování na každý den, méně kritické systémy se běžně skenují na týdenní bázi.

Dále je nutné informovat všechny zúčastněné strany a vlastníky aktiv o plánovaném skenování, aby tito lidé mohli v případě problémů správně reagovat. Jedná se převážně o zmiňované vlastníky aktiv, správce firewallů, IDS nebo IPS systémů a jiných monitorovacích systémů. Jakmile jsou všechny výše uvedené kroky splněny, můžeme přistoupit k samotnému skenování zranitelností.

… pak analyzovat…

Ve druhé fázi dle metodiky OWASP je prostor pro analýzu zranitelností a jejich reportování (celý proces této fáze je zobrazen na obrázku 1). Na začátku je třeba získané výsledky kategorizovat do skupin, aby následné vytváření reportů a analytické operace byly jednodušší proveditelné. Aktiva nebo skenované zařízení můžeme zařadit do skupin podle různých kritérií jako funkční skupina, geografická poloha, typ prostředí, typ operačního systému apod. Další skupiny zařízení mohou vzniknout na základě informací o přítomných zranitelnostech na těchto zařízeních. Můžeme vytvořit skupiny zařízení podle technologie, která obsahuje nalezené zranitelností, například podle konkrétních aplikací, knihoven atd. Nebo zařízení můžeme seskupovat podle úrovně zranitelností.

Obr. 1: Proces analýzy zranitelnosti a jejího reportování

V rámci analýzy je nutné ze všech objevených zranitelností vybrat ty, které představují největší riziko. K tomuto účelu se běžně používá již dříve zmíněný systém hodnocení CVSS, který ale trpí některými nedostatky. Například nezohledňuje dostupnost a kvalitu exploitu – zranitelnost, pro kterou neexistuje exploit není tak závažná, jako jiné zranitelnosti, pro které exploity existují a jsou dostupné v různých databázích. Správný nástroj pro řízení zranitelností dokáže s prioritizací pomoci a kromě uvedeného hodnocení CVSS často poskytuje i vlastní hodnocení závažnosti zranitelností, kde zohledňuje i další informace o zranitelnosti (například i informace o aktuálním zneužívání zranitelnosti z Threat Intelligence). Dále je třeba zvážit i další informace – závažnost systémů, na kterém se zranitelnosti nacházejí, služby, které zranitelné systémy poskytují a data, která se na systémech nachází.

Jakmile jsou zranitelnosti prioritizovány, na ty nejzávažnější je vhodné vytvořit tikety, aby náprava zranitelností byla monitorována a rychle předána na vlastníky aktiv. Většina nástrojů pro řízení zranitelností nabízí vestavěný service desk systém nebo umožňuje integraci na již používaný systém.

Posledním krokem v této fázi je vytvoření reportů a jejich distribuce na všechny zúčastněné strany. I zde by měla figurovat jistá míra automatizace, reporty by měly být vytvářeny v pravidelných intervalech a odesílány administrátorům, bezpečnostním správcům nebo dalším lidem na různých pozicích.

Management nebo Security Manager se zajímají většinou o celkový počet zranitelností v organizaci a jejich seskupení podle úrovně zranitelnosti. Správci a vlastníci aktiv se zajímají jen o zranitelnosti přítomné na zařízeních, které jsou v jejich správě. IT oddělení se zase bude zajímat o technické detaily a podrobnosti daných zranitelností, případně o rady a doporučení pro odstranění zranitelností. Všechny tyto reporty by měly být obsaženy v nástrojích pro řízení zranitelností a tím tento proces značně zjednodušit.

… a nakonec vyřešit

Poslední fáze metodiky OWASP se věnuje procesu odstranění zranitelnosti (proces zobrazuje schéma na obrázku 2). Dle této metodiky je do této fáze řazena ještě i prioritizace zranitelností, ale dle našich zkušeností je vhodné tohle provádět během analýzy zranitelností, aby tikety založené v předchozí fázi obsahovaly jen opravdu závažné zranitelnosti.

Obr. 2: Proces odstranění zranitelnosti

Pro každou zranitelnosti, která má být odstraněna, musí být nalezeno nápravné opatření, tedy způsob odstranění zranitelnosti. Tento návod poskytuje ve většině případů nástroj pro řízení zranitelností, není tedy nutné vynakládat příliš velké úsilí, požadované informace by měly být uvedeny u popisu zranitelnosti v nástroji.

Pokud odstranění zranitelnosti není možné (typicky se může jednat o nemožnost aktualizovat operační systém, protože na něm běží software, který není na novější verzi OS podporován), je třeba přistoupit k akceptaci zranitelnosti. V tomto okamžiku je nutné zvážit možná rizika, kterým bude systém vystaven v případě neodstranění zranitelnosti. Akceptace zranitelnosti musí být zdokumentována, tuto funkci obvykle poskytují nástroje pro řízení zranitelností.

Důvěřuj, ale prověřuj

Ve chvíli, kdy došlo k odstranění zranitelnosti, je vhodné pustit kontrolní skenování nástrojem pro řízení zranitelností, které potvrdí nepřítomnost zranitelnosti a zároveň ji označí za odstraněnou ve své databázi. Tento typ skenu se označuje jako remediation scan a je specifický identickým nastavením jako původní sken, který byl použit k detekci zranitelnosti.

Závěr

Jak jsme se snažili zmínit v článku, ani sebelepší technologie vám nezaručí kvalitní řízení zranitelností, pokud nebudete mít správně nastaveny příslušné procesy. Do detekce a odstraňování zranitelností zasahuje velké množství různých lidí s různými kompetencemi a zodpovědností, je důležité zajistit správnou komunikaci mezi těmito lidmi a předávání jen těch opravdu důležitých informací. Vybrat správnou technologii je pak jen třešničkou na dortu.

Použité zdroje:
[1] National Vulnerability Database [online]. [cit. 2019-06-21]. Dostupné z: https://nvd.nist.gov/
[2] Common Vulnerability Scoring System SIG [online]. [cit. 2019-06-21]. Dostupné z: https://www.first.org/cvss/
[3] Severity Levels for Security Issues [online]. [cit. 2019-06-21]. Dostupné z: https://www.atlassian.com/trust/security/security-severity-levels
[4] PALMAERS, Tom. Implementing a vulnerability management process. SANS Institute: Information Security Reading Room. 2, 20
[5] FOREMAN, Park. Vulnerability management. Boca Raton: Auerbach Pub., c2010. ISBN 978-1-4398-0150-5.
[6] OWASP Vulnerability Management Guide [online]. [cit. 2019-06-21]. Dostupné z: https://www.owasp.org/index.php/OWASP_Vulnerability_Management_Guide

David Pecl Autor článku je Senior Security Specialist ve společnosti AEC a.s.

Martin Dický Autor článku je Security Specialist ve společnosti AEC a.s.