Bezprostředně po útoku se objevila řada výzev, které doporučují vyměnit řešení od CrowdStriku za jiné, případně v rámci snižování závislosti na jednom dodavateli vyměnit i jiné podnikové systémy (například vyměnit i Microsoft Windows nebo Microsoft cloudové služby atd.). Myslím, že všichni podvědomě tuší, že tudy cesta nevede a že tyto výzvy jsou motivované především obchodními zájmy jejich proponentů. Správnou reakcí na tento incident by podle mě totiž měla být především revize přístupu firem ke třem oblastem. Jsou jimi strategické řízení dodavatelů IT, zvýšení odolnosti a zajištění kontinuity služeb (jednoduše mít plán B pro případ, že server, na kterém běží firemní aplikace nebude dostupný) a dostatečné testování a opatrné nasazování nových verzí softwaru na kritické systémy.

Tyto oblasti má dnes opravdu dobře promyšlené málokdo; přitom firmy, které uvedené tři disciplíny zvládnou, budou mnohem méně náchylné k různým problémům IT. Výpadky služeb totiž mohou být zaviněny i jinými příčinami, než pouze chybnou aktualizací nějakého softwaru. „Do kolen“ vás může dostat i chyba vašeho vlastního zaměstnance, útok hackera, nebo třeba útok pomocí ransomware. Jak by tedy měla revize těchto oblastí vypadat?

Musíme vědět, na čem fungují naše kritické firemní procesy a co se stane při výpadku jejich dodavatele

Firmy by si měly sestavit a pravidelně procházet seznam všech zá­vi­s­los­tí na různých nástrojích, jejich výrobcích, a na po­sky­to­va­te­lích IT služeb. Minimálně pro oblast nejkritičtějších procesů a služeb, bez kterých se provoz firmy neobejde. Správci IT musí poměrně přesně vědět, z čeho jsou tyto procesy a služby poskládané a na čem jsou závislé. A to do velké míry detailu. Jaké knihovny ve svých aplikacích používáte, kde a jak jsou firemní aplikace závislé na externích dodavatelích (hardwarově i softwarově)?

Potom je třeba se hned zamyslet, co budete dělat, pokud „to“ pře­sta­ne fungovat (výpadek fungování nějaké „krabičky“, výpadek celé cloudové služby a podobně). Jak dlouho přežijete jenom s papírem či jiným náhradním řešením? Máte vlastně nějakou alternativu? A umíte vyhodnotit, jestli je určitý dodavatel rizikovější než nějaký jiný? Po této první úvaze některé firmy můžou začít přehodnocovat i svoji celkovou IT strategii. Z pohledu IT provozu a jeho nákladů je určitě krátkodobě výhodnější, zkonsolidovat všechno na jedné platformě, od jednoho výrobce a podobně. Pokud se k tomu ale přidá parametr rizikovosti, možná se začnete částečně přiklánět i k určité heterogenitě, i za cenu vyšší komplexity a nákladů.

Klíčové je zvyšování odolnosti a zajištění kontinuity služeb

Rizika související s chybou IT nástrojů nebo s výpadkem dodavatelů jsou přitom pouze podmnožinou hlavních kybernetických rizik. Z těch dalších je třeba počítat například s již zmiňovaným ransomware, nejrůznějšími útoky hackerů nebo zneužitím přístupů zaměstnanců. Pro všechna tato rizika by firmy měly mít interně zpracované plány dalšího postupu. Jak zajistíme fungování našich služeb a provozu (Business Continuity), jak obnovíme naše systémy do stavu před incidentem (Disaster Recovery) a jak budeme reagovat v průběhu nejrůznějších kritických situací, abychom minimalizovali škody a zkrátili návrat k normálu (Incident Response)?

Ve stručnosti jde o to, zamyslet se na tím, co nejhoršího se může z pohledu firemního provozu stát? Které naše procesy jsou nejdůležitější a bez kterých se naopak v nouzi obejdeme? Co budeme dělat, když nastane „událost X“? Kde a jak zprovozníme klíčové aplikace a jak rychle obnovíme svá data? Ve chvíli, kdy si tyto plány připravíme, je musíme otestovat. V tuto chvíli se většinou ukáže, že původní představy byly moc optimistické, a přichází na řadu úprava plánů, často spojená s potřebou změny IT architektury a doplněním nových opatření či nástrojů. Důležité je upozornit, že jde o opakující se cyklus. Testy funkčnosti by měly být co nejrealističtější, protože jejich cílem je ochrana provozu před reálnými hrozbami, ne pouhé akademické cvičení. A právě proto by měly být i pravidelné.

Dostatečné testování a nasazování nových verzí systému

Poslední část už je relativně snadná. Všechny nové verze softwaru je lepší nasazovat nejdříve někde v testovacím prostředí. Teprve po určité době, kdy se přesvědčíme, že všechno funguje, můžeme nasadit novou verzi také do produkce. Tento postup je potřeba aplikovat i na bezpečnostní nástroje, protože je to software jako jakýkoliv jiný. Ano, je to v rozporu s požadavkem IT bezpečnosti „nasaďte co nejdříve“. V případě kritických aplikací se ale vyplatí vědět, zda po aktualizaci bude vše fungovat tak, jak má.

Podobným směrem míří také aktuální legislativní regulace

To, že kvalitní řízení rizik a funkční plány reakce na incidenty a obnovy provozu je základem pro to, aby se firmy dokázaly s podobnými incidenty vypořádat, reflektují mimo jiné i současné regulace, ať už jde o NIS2 a nový Zákon o kybernetické bezpečnosti, případně DORA v bankovnictví. Dá se přitom očekávat, že v budoucnu poroste v důsledku těchto regulací a podobných incidentů v některých oborech i tlak ze strany trhu samotného. Firmy budou chtít jednoduše mít jistotu, jak mají jejich dodavatelé zabezpečený svůj firemní provoz a co se stane, pokud u nich dojde k výpadkům systému.

Ivan Svoboda Autor článku je poradcem pro kyber­ne­tic­kou bezpečnost ve společnosti ANECT.