fb
IT Systems 9/2024 IT Security 13. 10. 2024 16:36

Strasti kolem záplatování zranitelností

Eliminace zranitelností ve firemní IT infra­struk­tu­ře dnes patří mezi základní činnosti, které pomáhají před­chá­zet vážným bez­peč­nost­ním inci­den­tům a jejich důsledkům. S jejich detekcí a tříděním podle závažnosti pomáhají nástroje pro skenování zranitelností. Jejich využití ale není triviální. Zranitelnosti je třeba řešit systémově. Zejména prioritizace zranitelností výrazně pomáhá tomu, aby firma zůstala chráněná před nejzávažnějšími hrozbami.

Zatímco menší firmy často dokážou s výstupy z nástrojů pro ske­no­vá­ní zranitelností pracovat poměrně efektivně, s rostoucí velikostí firmy a IT infrastruktury se zvyšuje riziko, že kritické zranitelnosti nebudou řešeny včas. Pokud je totiž počet hlášených zranitelností příliš vysoký, vývojáři či správci jednotlivých IT platforem je mají tendenci ignorovat. Nástroje, které dříve pomáhaly zvyšovat firemní bezpečnost, tak přestávají přinášet očekávaný užitek. Jednou z cest, jak se můžou firmy z této pasti dostat, je agregace správy zranitelností, vedoucí k výrazně přesnější prioritizaci.

Jako zranitelnost se označuje situace, kdy se na konkrétní IT infrastruktuře najde něco, co je zneužitelné útočníky. Jakmile je v nějakém softwaru či ovladači nalezena nová zranitelnost (kdekoliv na světě), je jí přiřazena míra závažnosti a je nahlášena do celosvětových databází, na základě čehož dokážou automatické skenovací nástroje při konkrétním testu zjistit, jestli se tato zranitelnost vyskytuje také na systémech IT infrastruktury v libovolné organizaci.

Nejnáročnější a zároveň nejdůležitější část práce ale nastává až po dokončení skenu. Je jí samotné odstranění nalezených zranitelností (tzv. patching, neboli záplatování).Ivan Svoboda Toto odstranění zranitelnosti si lze představit třeba jako instalaci nové verze softwaru nebo změnu konfigurace. To je však samo o sobě rizikové. „Zavedením nové verze totiž na jedné straně odstraníte nalezenou zranitelnost, ale zároveň můžete přidat nechtěně nějakou novou, nebo z nějakého důvodu přestane něco fungovat. Proto je potřeba tuto novou verzi nejdříve otestovat, zda nedojde k nějakým nežádoucím efektům,“ vysvětluje Ivan Svoboda, poradce pro kybernetickou bezpečnost společnosti ANECT.

Skenovací nástroje dokážou zcela běžně nalézt na jediném serveru i desítky různě závažných zranitelností. Další desítky se nacházejí v operačních systémech, v samotných aplikacích, síťových prvcích či jakémkoli jiném zařízení, třeba v tiskárně či kameře. S rostoucí velikostí firmy se tak významně zvyšuje počet požadavků na jejich opravu.Petr Mojžíš „Manažeři zodpovědní za provoz IT ve velkých firmách měsíčně dostávají vyšší stovky až tisíce takových požadavků. V jednu chvíli jich je přitom už tolik, že je prostě začnou ignorovat všechny a veškeré ošetřování zranitelností přichází až s aktualizacemi, které jsou instalovány z jiných než bezpečnostních důvodů. Průměrná doba odstranění kritické zranitelnosti je potom podle našich pozorování často dokonce vyšší než doba odstranění méně závažných problémů,“ říká Petr Mojžíš, security architect společnosti ANECT.

Pokud se totiž zranitelnost nachází v kritické aplikaci nebo na serveru, který je klíčový pro běh firemních systémů, není vždy možné ji odstranit za běžného provozu, ale je potřeba záplatu otestovat a nasadit v době, kdy je vytíženost těchto systémů nižší. Existuje totiž riziko, že při jejím odstraňování dojde k nezamýšlenému pádu firemních systémů, což může znamenat vysoké finanční nebo reputační ztráty.

Prioritu by měly mít závažné a zneužívané zranitelnosti

Jednotlivé nástroje, které skenují zranitelnosti ve firemních sítích, dokážou každé z nich přiřadit míru jejich závažnosti. Děje se tak dvěma způsoby. Nástroje využívají především už zmíněné veřejné databáze, které obsahují informace o potenciální závažnosti dané chyby. Některé potom využívají i služeb společností, které se zaměřují na Cyber Threat Intelligence, jejíž součástí je také informace o tom, které zranitelnosti jsou aktivně využívané. Mezi těmito množinami je však překvapivě malý překryv.

„Pro firmy je tedy klíčové, aby vyhodnocovaly oba tyto zdroje, protože díky tomu se dokážou soustředit na ty zranitelnosti, které jsou nebezpečné a zároveň jsou aktivně zneužívané. Pokud by vycházely pouze z informací o jejich potenciální nebezpečnosti, tak ze statistického pohledu mají více než 60% pravděpodobnost, že se budou dříve věnovat zranitelnosti, která je sice označená jako závažná, ale která není reálně zneužívaná. A mezitím nechají neopravené ty, které jsou důležité a zároveň široce zneužívané,“ upozorňuje Ivan Svoboda. Zároveň dodává, že pro zlepšení prioritizace je potřeba také vědět, zda jde o kritický server nebo prvek, který je viditelný mimo interní síť. „Bohužel firmy často nevědí, které prvky jsou pro ně klíčové a bez kterých se chod jejich byznysu neobejde. Tato znalost je přitom zásadní nejen pro správnou prioritizaci oprav, ale především pro ochranu těchto prvků a dat a zajištění kontinuity provozu v případě úspěšného hackerského útoku,“ upozorňuje.

Popsané principy vedou k jedinému cíli, kterým je zvýšení přehlednosti o stavu firemní IT infrastruktury a efektivní využití interních zdrojů. Jinými slovy jde o to, aby měly firmy možnost se na základě toho, kolik zranitelností jsou reálně schopné řešit v řádu dní, možnost definovat si jasná kritéria pro to, čemu se v rámci svých možností budou věnovat. „Mohou si například stanovit, že počet těch nejkritičtějších zranitelností by neměl přesáhnout X událostí měsíčně. Mělo by jít o číslo, na kterém se shodne kybernetická bezpečnost společně s provozem IT. Tak, aby bylo jasné, že provoz je tento počet reálně schopen opravdu odbavit. Následně je možné nastavit skenovací, filtrační a prioritizační pravidla, a pokud je počet požadavků vyšší, tato pravidla dále zpřísňují. Toho lze přitom s využitím nových nástrojů dosáhnout interně, nebo je možné tuto správu pořídit jako službu. Typicky jde o doplňkové aktivity bezpečnostních a dohledových center, která se primárně starají o monitoring síťového provozu a o reakce na bezpečnostní incidenty,“ vysvětluje Petr Mojžíš.

Výše uvedená prioritizace zranitelností výrazně pomáhá tomu, aby firma zůstala chráněná před nejzávažnějšími hrozbami plynoucími z chyb ve své IT infrastruktuře, protože snižuje počet událostí, na které je potřeba rychle reagovat. Hackeři jsou totiž v průměru schopní začít zneužívat kritickou zranitelnost pět dní od jejího nalezení. Proto mají také například ve Velké Británii firmy povinnost odstranit kritickou zranitelnost viditelnou mimo interní síť právě do pěti dní a do dvou týdnů potom tu, která se nachází v interní síti.

I proto je vhodné využívat pro skenování takové nástroje, které kromě samotného nalezení zranitelností a jejich prioritizace dokážou pomoci i při jejich následném odstraňování neboli patchování.

Ani to však nemusí stačit. Velké firmy často používají hned několik různých nástrojů na skenování zranitelností. Například jeden nástroj pro skenování technické infrastruktury, jiný pro skenování aplikací, další nástroj pro skenování cloudu a kontejnerů, další nástroje pro penetrační testy atd. A každý z těchto nástrojů generuje pravidelně nějaké seznamy nálezů, ale většinou s trochu odlišným číselníkem závažnosti, s jiným reportingem, s jiným workflow a podobně. „V tu chvíli přichází potřeba přidat další unifikační integrační vrstvu, která umožní sjednotit výstupy ze všech těchto nástrojů i následnou práci a dohled nad odstraňováním těch nejkritičtějších zranitelností. Tak, aby IT provoz nebo vývoj věděl, že do týdne je například potřeba odstranit zranitelnost číslo 13 z nástroje X a zranitelnost č. 257 z nástroje Y,“ vysvětluje Ivan Svoboda.

Naštěstí všechny výše zmíněné problémy jsou dnes řešitelné, ať již pomocí specializovaných integračních nástrojů, či pomocí služeb zaměřených právě na efektivní správu zranitelností.

Kalendář akcí
Konference - Semináře - Školení
Časopis IT Systems/Speciál
Aktuální číslo časopisu IT Systems Aktuální číslo časopisu příloha #1
Archív časopisu IT Systems
IT Systems 7-8 IT Systems 6 IT Systems 5 IT Systems 4
Archív časopisu IT Systems Special
Aktuální číslo časopisu příloha #1 Aktuální číslo časopisu příloha #1 Aktuální číslo časopisu příloha #1 Aktuální číslo časopisu příloha #1