Článek
Komentář si také můžete poslechnout v audioverzi.
Svět má za sebou pravděpodobně největší výpadek IT služeb v historii. Kvůli chybě v nastavení aktualizace bezpečnostního softwaru firmy CrowdStrike bylo v pátek 19. července vyřazeno z provozu 8,5 milionu firemních počítačů po celém světě. To vedlo k narušení nebo úplnému zastavení provozu stovek společností a organizací po celém světě, často v kritických odvětvích, jakými jsou doprava, zdravotnictví či bankovnictví. Celosvětové škody se počítají v miliardách dolarů, v Česku, kde se výpadek projevil v menší míře, se mohou vyšplhat k desítkám až stovkám milionů korun. Jaké poučení bychom si z této události měli odnést?
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é tyto tři disciplíny zvládnou, budou mnohem méně náchylné k následným problémům. A je potřeba upozornit, že podobné výpadky služeb 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, co se stane při výpadku dodavatele
Firmy by si měly sestavit a pravidelně procházet seznam všech závislostí na různých nástrojích, jejich výrobcích a na poskytovatelí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řestane 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
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? Poté, co si tyto plány připravíme, je musíme otestovat. V tuto chvíli se přitom 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 také pravidelné.
Dostatečné testování a nové verze
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á.
A jak by znělo toto poučení a doporučení v jedné větě? Přemýšlejte nad IT bezpečností strategicky a určitě nepodceňujte kvalitní řízení rizik!
