Od nálezu zranitelnosti ke změně v produkci

Bezpečnostní tým dostane z nového skenu dlouhý export. Tisíce řádků, každý s identifikátorem zranitelnosti, IP adresou a skóre závažnosti. Někdo ho rozdělí podle týmů a rozešle. Provoz se snaží zjistit, které servery to vlastně jsou, k jaké službě patří a kdy se na ně smí sáhnout. Za měsíc přijde další export a nikdo s jistotou neví, co z toho minulého je opravené.

Za tímto obrazem jsou unavení lidé na obou stranách. Bezpečnost má pocit, že ji provoz neposlouchá. Provoz má pocit, že dostává seznamy bez souvislostí a bez priorit. A vedení se ptá na jednoduchou otázku, na kterou nikdo nemá rychlou odpověď: jsme na tom lépe než minulý měsíc?

Proč export ze skeneru nestačí

Skener dělá dobře to, k čemu je určen: najde zranitelné verze softwaru. Neví ale, jakou roli server hraje, jaká služba na něm stojí a kdo za ni odpovídá. Bez toho se z nálezu nedá rozumně udělat práce.

V praxi často vidíme tyto slabiny:

• nálezy se řadí jen podle skóre, i když v reálném provozu je důležitější, zda se zranitelnost aktivně zneužívá,
• termíny opravy se neodvozují od závažnosti, takže kritický nález může čekat stejně dlouho jako drobný,
• cesta od nálezu ke změně vede přes e-maily a ruční zakládání tiketů,
• stav nápravy se skládá z několika tabulek a je vždy o krok pozadu.

Jak k tomu přistupovat

Nález zranitelnosti má smysl teprve ve spojení s CMDB. Když víme, na kterém serveru je, víme také, kterou službu ohrožuje, kdo je její vlastník a jaké má servisní okno. Teprve pak lze rozumně rozhodnout o pořadí a termínu.

Priorita by se měla řídit dvěma otázkami: jak závažná je zranitelnost a zda ji někdo aktivně zneužívá. Z toho plyne termín. A cesta k opravě má vést přes běžný změnový proces, aby i rychlá oprava respektovala dopad na služby, jen s kratšími lhůtami.

Stejně podstatné je měřit nápravu, ne jen počet nálezů. Číslo, které jen roste nebo klesá podle toho, co skener zrovna našel, mnoho neříká. Užitečnější je vědět, kolik nálezů je po termínu, u kterých služeb a proč.

Jak to řeší Eywo Stratum

Eywo Stratum importuje nálezy ze skeneru a přiřadí je k položkám CMDB. Zranitelnosti jsou pak vidět po serverech i po službách, takže vlastník služby vidí, co se týká právě jeho.

Na tom staví prioritizace:

• aktivně zneužívané zranitelnosti (KEV) jsou zřetelně označené, aby nezapadly mezi ostatní,
• termíny podle závažnosti určují, do kdy má být nález opravený,
• zrychlený režim pro kritické chyby, dohodnutý předem v dohodě o patchování s vlastníkem služby, umožňuje kratší cestu bez obcházení odpovědnosti.

Od nálezu k opravě vede plán patchování ve vlnách. Servery se seskupí podle služeb a jejich oken a z plánu se jedním krokem vytvoří změny. Každá změna projde výpočtem dopadu na služby, kontrolou servisních oken, zmrazení a kolizí. Redundantní uzly lze patchovat postupně, aby služba zůstala dostupná.

Dashboard zranitelností a nápravy ukazuje, kolik nálezů je otevřených, které se blíží termínu a jak postupuje oprava po službách. Bezpečnost i provoz se dívají na stejná data, takže odpadá dohadování, čí tabulka je aktuální.

Společný obraz místo přehazování seznamů

Řízení zranitelností není jen bezpečnostní disciplína. Je to provozní práce, která potřebuje kontext: servery, služby, vlastníky a změny. Když jsou tyto informace propojené, bezpečnost nemusí naléhat a provoz nemusí hádat. Obě strany vidí, co je potřeba opravit nejdřív, kdo to schválí a kdy se to stane. A na otázku vedení, zda jsme na tom lépe než minulý měsíc, je odpověď na jedné obrazovce.

Import nálezů, prioritizace zranitelností, plán patchování a dashboard nápravy jsou součástí edice Business.