Manažer bezpečnosti: Nastavení priorit pro záplaty

Když uvažujeme o správě záplat, máme obvykle na mysli aktualizace zabezpečení nebo balíčky Service Pack od společnosti Microsoft či patche pro Solaris. Ale co ostatní opravy? Například záplaty pro software Oracle WebLogic, Sun Java nebo RIM BlackBerry Desktop. A pro aplikace od firem Adobe, SAP, PeopleSoft, Oracle a další, které nejsou pokryty standardními aktualizacemi operačního systému.

Provozní manažer naší firmy prezentoval jednoho dne na podnikovém mítinku seznam nevyřešených případů zabezpečení. Bylo jich více než 80 a týkaly se především nenainstalovaných záplat aplikací.

Pro existenci této hromady restů jsou různé důvody. Jedním z nich je absence vývojového prostředí pro testování oprav ještě před jejich nasazením do provozu. Dalším je fakt, že instalace patchů by mohla vrátit konfigurace do výchozího nastavení. V ostatních případech jsme ztratili základní znalosti o aplikaci, protože původní správce byl propuštěn a odešel, aniž nám potřebné informace předal.

Musel jsem něco udělat, ale nařídit okamžitou instalaci všech oprav by pravděpodobně skončilo katastrofou. Rozhodl jsem se proto věnovat trochu času analýze všech zranitelností a přidělit jim priority podle tolerance nutné pro uvážlivou instalaci důležitých záplat.

Při určovaní kritérií pro stanovení, jak bezprostředně nutné opravy jsou, jsem nejprve zvažoval dopad případného zneužití dané zranitelnosti. Dokázal by hacker získat vzdálený přístup nebo zahájit útok DoS (odepření služby)?

Dalším aspektem bylo umístění zranitelného prostředku. U webového serveru umístěného v internetu je vyšší pravděpodobnost napadení hackery než u systému lokalizovaného v naší interní síti. Také náš server MS Active Directory určitě potřebuje více pozornosti než aplikace provádějící průzkum lidských zdrojů.

Potom přišla na řadu samotná zneužitelnost. Dokázali by zranitelnost využít začátečníci v oblasti skriptování, nebo by útok vyžadoval rozsáhlé znalosti či schopnosti programování?

Přidělení váhy
Důležitým kritériem výběru je také dostupnost. Dodavatelé aplikací někdy chybují v oblasti stupně varování a označí zranitelnost jako kritickou, přestože je vysoce nepravděpodobné, že někdy v budoucnu bude vytvořen kód k jejímu zneužití. Zranitelnost nelze ignorovat, ale mohou se klást otázky: Je kód pro využití zranitelnosti (exploit) volně dostupný na internetu? Je obsažen v aplikaci Metasploit? (Metasploit je nástroj pro vývoj a spouštění záškodnického kódu zaměřeného na cílové počítače a další prostředky IT.) Nebo je kód dostupný pouze přes tajné kanály? Odpovědi na tyto otázky pomohou určit, jak rychle byste měli jednat.

Nakonec je také nutno zdůraznit, že priority záplat také mohou záviset na implementaci kompenzačních ochran a omezení. Pokud záškodnický kód vyžaduje, aby koncový uživatel navštívil webové stránky s malwarem, a vy máte globálně nasazenou službu reputace webů, může být pozornost nižší.

Aby se mi lépe určovaly priority, vytvořil jsem tabulku s váženými průměry. Pokud je například exploit dostupný jen přes tajné kanály, ale zranitelné prostředky jsou připojeny do veřejného internetu, je přidělena vyšší váha než v případě umístění zranitelného prostředku do demilitarizované zóny, která je chráněna přes aplikační proxy.

Přidělení priorit poskytlo provoznímu týmu čas navíc, ale výsledkem by mělo být to, že všechny záplaty budou nainstalovány. Plánuji také proškolit další analytiky zabezpečení, aby dokázali použít stejnou metodologii pro určení priorit u budoucích záplat aplikací a já abych se mohl věnovat naléhavějším tématům, jako je prevence úniku dat z koncových stanic – o tom ale až někdy příště.