Co rozhoduje v prvních hodinách po ransomwarovém útoku? Propojení ISMS, BIA a BCM
První hodiny po ransomwarovém útoku často ukážou, jak dobře je organizace připravena na skutečný výpadek. Nejde přitom jen o úroveň technického zabezpečení. Rozhodující je, zda organizace ví, které služby musí obnovit jako první, na čem jejich provoz závisí a kdo má v krizové situaci rozhodovat.

První hodiny po ransomwarovém útoku často ukážou, jak dobře je organizace připravena na skutečný výpadek. Nejde přitom jen o úroveň technického zabezpečení. Rozhodující je, zda organizace ví, které služby musí obnovit jako první, na čem jejich provoz závisí a kdo má v krizové situaci rozhodovat.
Právě zde se ukazuje význam propojení řízení bezpečnosti informací (ISMS), analýzy dopadů na podnikání (BIA) a řízení kontinuity činností (BCM). Tři oblasti, které se v organizacích často řeší odděleně, ale při skutečném incidentu musí fungovat společně.
První hodiny po ransomwaru: Když přestanou fungovat běžné postupy
Organizace, které prošly ransomwarovým útokem, popisují první hodiny velmi podobně. Aby se zabránilo dalšímu šíření útoku, je potřeba odpojit části sítě. Služby se zastaví, přestane fungovat e-mail a často i telefonní ústředna.
Běžné komunikační a pracovní postupy najednou nejsou dostupné. Lidé nemají přístup k informacím, které běžně používají, a jednotlivé týmy musí začít řešit obnovu provozu.
V takové chvíli už není hlavní otázkou, zda má organizace zpracovanou analýzu rizik nebo jak kvalitní firewall pořídila. Do popředí se dostávají mnohem konkrétnější otázky:
- Které služby potřebujeme obnovit jako první?
- Z jakých záloh je můžeme obnovit?
- Jak dlouho bude obnova trvat?
- Kdo rozhoduje o prioritách a dalším postupu?
- Jak budou jednotlivé týmy komunikovat, pokud nefunguje e-mail ani telefon?
Odpovědi na tyto otázky by neměly vznikat až ve chvíli, kdy útok nastane. Organizace je potřebuje znát předem, mít je podložené aktuálními informacemi a pravidelně ověřovat, že připravené postupy skutečně fungují.
Technologie a bezpečnostní dokumentace často vznikají odděleně
Organizace investují do různých oblastí kybernetické bezpečnosti. Pořizují firewally, zálohovací systémy, ochranu koncových stanic nebo monitoring. Často jde o reakci na konkrétní problém – bezpečnostní incident, provozní výpadek nebo zjištění z penetračního testu. Vedle toho vzniká bezpečnostní dokumentace. Analýzy rizik, bezpečnostní politiky, evidence aktiv a další podklady, které organizace potřebuje pro audit, splnění legislativních požadavků nebo interní řízení bezpečnosti.
Na tomto přístupu není nic špatného. Technická opatření i bezpečnostní dokumentace jsou nezbytné. Problém nastává, pokud spolu tyto oblasti nejsou propojené. Organizace může mít kvalitní zálohování, ale nemusí vědět, které systémy má obnovit přednostně. Může mít podrobně zpracovanou analýzu rizik, ale bez přehledu o tom, jaký dopad bude mít výpadek konkrétní služby na její provoz.
Stejně tak může mít připravený krizový plán, který však neodpovídá aktuálnímu stavu informačních systémů. Při skutečném incidentu pak jednotlivé technologie a dokumenty neposkytují ucelený podklad pro rozhodování.
ISMS, BIA a BCM: Tři vrstvy, které musí fungovat společně
Aby organizace dokázala efektivně reagovat na ransomwarový útok nebo jiný závažný výpadek, potřebuje propojit tři základní oblasti.
1. ISMS: Co máme, na čem závisíme a co nás ohrožuje?
ISMS (Information Security Management System) představuje systém řízení bezpečnosti informací.
Jedním z jeho důležitých podkladů je aktuální přehled aktiv, jejich vzájemných vazeb a souvisejících rizik.
Organizace tak může zjistit například to, že klíčová agenda závisí na jediném serveru nebo na jednom externím dodavateli technické podpory.
Taková informace je zásadní nejen pro hodnocení rizik, ale také pro plánování obnovy provozu.
ISMS pomáhá odpovědět na otázku: Co máme, jak spolu jednotlivé části souvisejí a co je ohrožuje?
2. BIA: Jak dlouho si můžeme dovolit výpadek?
BIA (Business Impact Analysis), tedy analýza dopadů na činnost organizace, navazuje na znalost aktiv a jejich vazeb.
Jejím úkolem je určit, jaké důsledky bude mít přerušení jednotlivých služeb a jak dlouho může organizace bez těchto služeb fungovat.
Důležitými parametry jsou zejména:
- RTO (Recovery Time Objective) – cílová doba, do které má být služba po výpadku obnovena.
- RPO (Recovery Point Objective) – maximální přípustná ztráta dat vyjádřená časovým intervalem.
Pokud například organizace stanoví pro určitou službu RTO čtyři hodiny, ale její obnova ze zálohy trvá dva dny, existuje zásadní nesoulad mezi požadavky provozu a skutečnými možnostmi IT.
Právě BIA pomáhá takové rozdíly odhalit včas. Současně poskytuje podklady pro rozhodování o investicích do zálohování, redundance a dalších opatření. Organizace tak může lépe rozlišit, kde potřebuje vyšší úroveň dostupnosti a kde by naopak investovala do technologií, které neodpovídají skutečným provozním potřebám.
BIA odpovídá na otázku: Jak dlouho bez konkrétní služby vydržíme a jak velkou ztrátu dat si můžeme dovolit?
3. BCM: Co konkrétně uděláme, když výpadek nastane?
BCM (Business Continuity Management) se zaměřuje na řízení kontinuity činností organizace.
Na základě znalosti aktiv, jejich vazeb a dopadů výpadků vznikají konkrétní postupy pro zvládání mimořádných situací.
Součástí jsou krizové plány, které určují:
- Jaké kroky je potřeba provést.
- Kdo za jednotlivé činnosti odpovídá.
- Kdo rozhoduje o dalším postupu.
- Jaké kontakty a komunikační kanály se použijí.
- Jaké náhradní postupy lze využít při nedostupnosti běžných systémů.
Důležité je, aby krizové plány byly dostupné i v situaci, kdy běžná IT infrastruktura nefunguje.
Stejně zásadní je jejich pravidelné testování. Plán, který nikdo nevyzkoušel, totiž nemusí v reálné situaci odpovídat možnostem organizace.
BCM odpovídá na otázku: Jak budeme postupovat, kdo co udělá a jak zajistíme pokračování nebo obnovu klíčových činností?
Proč je propojení ISMS, BIA a BCM tak důležité?
Každá z těchto oblastí přináší jiný pohled. Jejich skutečný přínos se však projeví až ve chvíli, kdy na sebe navazují a vycházejí ze stejných, aktuálních informací.
V praxi se problémy s jejich odděleným řízením projevují několika způsoby.
Krizový plán neodpovídá aktuálnímu stavu IT.
Pokud plán kontinuity nevychází z aktuální mapy aktiv a jejich vazeb, může zastarat už při první větší změně infrastruktury. Změní se systém, dodavatel nebo způsob poskytování služby, ale krizový postup zůstane stejný.
Požadavky na obnovu neodpovídají skutečným možnostem.
BIA stanoví RTO čtyři hodiny, zatímco reálná obnova ze zálohy trvá dva dny. Pokud organizace tento rozdíl neověřuje, zjistí ho až ve chvíli, kdy potřebuje službu skutečně obnovit.
Analýza rizik nezohledňuje provozní dopady.
Analýza rizik může určit pravděpodobnost a závažnost bezpečnostních hrozeb. Bez návaznosti na BIA však nemusí dostatečně ukazovat, které služby jsou pro pokračování činností organizace skutečně kritické.
Technologické investice neodpovídají prioritám organizace.
Pokud se bezpečnostní technologie pořizují bez znalosti provozních závislostí a dopadů výpadků, mohou chránit především to, co je nejvíce viditelné.
Nemusí však dostatečně chránit systémy a služby, na kterých je organizace ve skutečnosti nejvíce závislá.
Společným problémem všech těchto situací je nedostatečná návaznost informací. Organizace sice má technologie, dokumentaci i krizové postupy, ale jednotlivé části nevycházejí ze společného základu.
Jak propojujeme ISMS, BIA a BCM v Open Apps Development
V Open Apps Development vyvíjíme nástroje s cílem propojit všechny tři oblasti tak, aby pracovaly se stejnými daty a jednotlivé informace na sebe přirozeně navazovaly.
OMIS: Společný základ pro řízení aktiv a rizik
OMIS (Open Management for Information Security) slouží k řízení bezpečnosti informací a práci s informacemi o aktivech, jejich vzájemných vazbách a rizicích.
Vytváří tak datový základ, ze kterého mohou vycházet další procesy související s bezpečností a kontinuitou provozu.
OBIR: Analýza dopadů a požadavků na obnovu
Na informace vedené v OMIS navazuje OBIR, který se zaměřuje na dopadovou analýzu BIA a stanovení parametrů RTO a RPO.
Pomáhá tak propojit znalost aktiv a jejich závislostí s konkrétními požadavky na dostupnost a obnovu služeb.
BCM: Krizové plány navázané na aktuální informace
Ve spolupráci se společností PERITRA, která přináší zkušenosti z krizového řízení a přípravy krizových postupů, vyvíjíme BCM systém pro tvorbu, správu a testování krizových plánů.
Cílem je, aby krizové postupy nevznikaly izolovaně, ale navazovaly na aktuální informace o aktivech, jejich závislostech a dopadech případných výpadků.
Organizace tak může postupně propojit znalost svého prostředí, požadavky na obnovu a konkrétní činnosti, které je potřeba při mimořádné situaci provést.
Připravenost na ransomware nezačíná až při útoku
Ransomwarový útok velmi rychle prověří, zda organizace dokáže převést informace o svých systémech a rizicích do konkrétních rozhodnutí a kroků.
Samotné bezpečnostní technologie nestačí. Stejně tak nestačí dokumentace, pokud neodpovídá aktuálnímu provozu a není propojena s reálnými možnostmi obnovy.
ISMS poskytuje přehled o aktivech, vazbách a rizicích. BIA určuje dopady výpadků a požadavky na obnovu. BCM převádí tyto informace do konkrétních postupů a odpovědností.
Když všechny tři oblasti pracují se společnými daty, organizace má lepší podklady pro rozhodování, může včas odhalovat nesoulad mezi požadavky a skutečnými možnostmi a připravovat krizové postupy odpovídající reálnému prostředí.
A právě o to nám v Open Apps Development jde.
Chceme, aby organizace při výpadku nemusela improvizovat.

.jpg)
