Proč velké společnosti nepatchují

Prakticky není dne, kdy by se neobjevila nějaká zranitelnost a nebyl uvolněn nějaký patch. Z nejrůznějších zdrojů se také velice často dozvídáme, že společnost XY neměla nasazen kritický patch, ač byl uvolněn již před několika dny nebo dokonce týdny a stala se tak obětí neznámého útočníka. Pro mnohé bezpečnostní konzultanty je to vždycky velké překvapení a pozastavují se nad tím, jak je možné, že tak velká společnost daný patch nenasadila. A vyvozují z toho, že daná společnost nemá zavedený tzv. patch management.

Tím jen dokazují, že nemají dostatečné zkušenosti z reálného provozu. Ten, kdo někdy spravoval nějaký systém, ví, že nasazením patche hned po jeho uvolnění, bez toho aniž by ho nejdříve důkladně otestoval, může někdy nadělat více škody než užitku. Nasazovat patch bez jakékoliv analýzy a důkladného otestování je prostě holý nesmysl a dokonce možná větší, než patch nenasadit vůbec. Předpokládejme, že byl uvolněn patch řešící zranitelnost, která umožňuje útočníkovi za určitých podmínek např. provést vzdálený restart nebo shození systému, což by kromě nedostupnosti systému mohlo vést i k narušení integrity dat.

První, co bychom měli udělat je, že bychom si měli položit otázku, zda na našem systému může vůbec dojít ke zneužití dané zranitelnosti a pokud ano, jaká je pravděpodobnost, že daná zranitelnost bude opravdu zneužita. Pokud si na výše uvedenou otázku odpovíme, že pravděpodobnost zneužití v našem případě vskutku existuje, měli bychom se dále ptát, jaký finanční případně nefinanční dopad to bude mít na náš business.

Pokud výše uvedený krok přeskočíme, může se snadno stát, že patch nasadíme i na systém, na kterém by daná zranitelnost stejně nemohla být zneužita. To by samo o sobě nevadilo, nicméně problém je v tom, jakým způsobem patch danou zranitelnost odstraňuje. A to většinou nikdy nevíme, protože výrobce běžně chyby ve svém zdrojovém kódu nezveřejňuje a už vůbec ne jak danou chybu opravil. Kdybychom však patch nejdříve důkladně otestovali, zjistili bychom třeba, že při větším počtu připojených klientů, se prodlužuje doba odezvy, celý systém se výrazně zpomaluje, stává se nestabilním a od určitého počtu současně připojených uživatelů přestává fungovat zcela nebo dochází ke vzniku nejrůznějších anomálií, např. se uživateli zobrazují data jiného, právě přihlášeného uživatele. Z pohledu bezpečnosti se jedná o vážné narušení důvěrnosti, což je mnohem závažnější bezpečnostní incident, než výše uvedené narušení integrity nebo dostupnosti.

Situace však může být ještě mnohem horší. Dejme tomu, že jsme provedli analýzu a zjistili jsme, že náš systém je zranitelný a že pravděpodobnost, že daná zranitelnost bude zneužita, je vysoká. Patch jsme proto nasadili nejprve v testovacím prostředí. Po opakovaných testech jsme však dospěli k závěru, že patch sice odstraňuje danou zranitelnost, ale při větším počtu připojených klientů se objevují vážné chyby. Teď stojíme před poměrně zásadním rozhodnutím, zda patch nasadit nebo nikoliv. Volíme menší zlo, patch nasazovat nebudeme. Z logů na produkčním systému jsme totiž zjistili, že počet současně připojených uživatelů vysoce překračuje onu kritickou hodnotu. Riziko, že náš systém nebude při tomto počtu současně připojených uživatelů fungovat tak jak má, je jisté, ostatně ověřili jsme si to v testovacím prostředí. Pokud jde o zneužití zranitelnosti, na kterou byl uvolněn patch, tak tam se pořád jedná jen o hypotetické riziko, a i kdyby došlo k jeho uplatnění, výsledná finanční ztráta by byla výrazně nižší. Pokud by se prokázalo, že společnost o této skutečnosti věděla a došlo by k úniku důvěrných informací, mohla by jí být uložena pokuta. Nehledě na to, že i v očích veřejnosti se v případě úniku informací jedná o závažnější incident, než když je systém nějakou dobu mimo provoz.

Patch tedy nenasazujeme a rozjíždíme okamžitě jednání s dodavatelem systému. To však může trvat poměrně dlouho. Uvědomte si, že v dnešní době, kdy většina systémů je postavena na vícevrstvé SW a HW architektuře a samotná aplikace se navíc často skládá z mnoha komponent od různých výrobců, může být docela problém zajistit, aby spolu s nasazením patche nedošlo k nežádoucímu chování na kterémkoliv subsystému. Zranitelnost se totiž může objevit nejen na úrovni OS, jádra aplikace, modulu nebo komponenty dané aplikace, ale i na úrovni aplikačního, webového nebo databázového serveru. Netřeba snad dodávat, že na každé vrstvě obvykle běží vlastní instance nějakého OS. V době, kdy běží vývoj a testování, není systém chráněn proti nově objevené zranitelnosti a to bez ohledu na to, jak je společnost velká a kolik prostředků může do vývoje investovat. Zkrácení SDLC (Software Development Life Cycle) není možné. I když se použijí agilní metodiky vývoje SW, např. extrémní programování a na odstranění dané zranitelnosti, spočívající v přepsání kódu určité komponenty nebo třídy, budou pracovat dva programátoři, nějakou dobu jim to potrvá. Zapojení vyššího počtu vývojářů je od určitého množství kontraproduktivní.

A to není všechno, kromě procesu patch management ve většině velkých společností běží i proces, který se nazývá release management. Uvědomte si, že velké společnosti většinou využívají systémy, které pro ně byly vyvinuty na zakázku. Tyto společnosti též obvykle mají i velké množství zákazníků, kteří služby jejich systému využívají. Společnosti, kterým na klientech záleží, se snaží svůj systém upravovat tak, aby plnil jejich požadavky. To znamená, že dochází i k častějšímu nasazování nových verzí, než jak tomu je u krabicového SW. Nasazení nové verze vždy předchází důkladné testování, které často trvá několik dní až týdnů. Podstatná je zde právě ona délka SDLC, kterou nelze zkrátit. Pro nasazení nového release jsou stanoveny závazné termíny. Vše je důsledně naplánováno, testování, nasazení v pilotním provozu, roll-out. V okamžiku, kdy se objeví nová zranitelnost, to znamená všechno znovu otestovat. S množstvím nových zranitelností a patchů by se společnost dostala do situace, že by její ICT nedělalo nic jiného, než jen testovalo a nasazovalo nové patche. Taková společnost si dokáže dobře spočítat, že je pro ni výhodnější patche nasadit najednou spolu s dalším releasem.

Zajímavé je, že se vždycky najde nějaký „bezpečnostní expert“, který nemá v okamžiku, kdy se objeví nějaká zranitelnost, nic lepšího na práci, než začít testovat systémy velkých společností, zda náhodou danou zranitelnost neobsahují. A následně se pak pokusí dané zranitelnosti využít, v lepším případě danou společnost kontaktovat a nabízet jí pomoc při odstranění zjištěné zranitelnosti. Nezřídka se také stává, že pokud daná společnost o jeho pomoc nestojí, anebo mu nedej bože ani neodpoví, tak o tom hned píše na svém webu. Pak se může lehce stát, že dané zranitelnosti někdo opravdu zneužije.

Závěr: Před nasazením patche nejprve ověřte, zda má jeho nasazení smysl a důkladně ho otestujte, můžete tak předejít mnohým problémům. Doufám, že teď už víte, proč tolik velkých společností nemá nasazené patche hned po jejich uvolnění.

Miroslav Čermák
www.cleverandsmart.cz