Jak se připravit na katastrofu

Iluze toho, že právě nám se nemůže nic stát, je tím nejhorším, co nás může potkat. Je sice jednoduché žít v sebeklamu, ale to nikoho jakkoliv neochrání. Kdo je jen trochu zodpovědný a soudný, tak se samozřejmě na možnost nějakého problému připraví.

Příprava

Celá věc má jeden zásadní háček: ať se snažíme sebevíce, nikdy vlastně nevíme, na co přesně se připravujeme. Eventuálních variant a možností, které mohou nastat, je tolik, že je snad ani nemá smysl kvantifikovat.

Nicméně existuje několik obecných pravidel a zákonitostí, které se vyplatí ctít. Neudělat nic totiž není řešením. Představte si situaci, že se „něco“ stane. Co se bude dít následně? I jednoduchý krizový plán je lepší než žádný. Ostatně, pokud není incident komu nahlásit, tak ani nahlášený být nemůže.

Právě neexistence krizového plánu je největším problémem. Plán přitom nemusí mít formu svazku ne nepodobného telefonnímu seznamu. Naopak, takový fascikl je v praxi nepoužitelný.

O problematice krizového plánování nemusejí ani být podrobně informováni všichni zaměstnanci – stačí jen ti nejdůležitější. Ostatní instruujte několika jednoduchými a zapamatovatelnými zásadami společně s kontaktními údaji, na které se obracet v případě, že k potížím dojde. Obrazně řečeno: nemusí být každý hasičem, ale stačí, když ho dokáže zavolat.

Je absurdní, že právě situaci, kdy nikdo neví, co se má dělat a odkud vlastně vůbec začít, se dá poměrně jednoduše předejít – a přesto je to jedna z nejčastějších chyb, které se stále dokolečka dokola dělají. Podcenění přípravy v různých podobách je zkrátka nejčastějším problémem a konstatování typu „stejně se nepřipravíme na vše“, „nakonec bude všechno jinak“ nebo „stejně to nebude fungovat“ jsou jen plané výmluvy.

Hlavně, ať to funguje

Máme-li být objektivní a upřímní, tak je pravdou, že plány Disaster Recovery (dále jen DR) skutečně jen málokdy fungují. Naprosto otevřeně to nedávno na jedné bezpečnostní konferenci prohlásil Gil Hecht, CEO z firmy Continuity Software: „DR prostě nefunguje.“ A hned svá tvrzení podložil čísly. Šedesát procent plánů na nouzovou obnovu selže nejen při testech, ale i následně při ostrém nasazení.

Kdyby byl jeho hlas osamocený, mohli bychom jej podezřívat z přihřívání vlastní marketingové polívčičky. Jenomže třeba Sean Derrington ze Symantecu jej podporuje a tvrdí, že na základě průzkumu, který si jeho zaměstnavatel nechal udělat, zhruba polovina manažerů datových center připustila selhání DR. Praxe přitom ukazuje, že zklamání ze selhání pečlivě a mnohdy draze připravovaných plánů pro „případ ztroskotání“ je spíše pravidlem než výjimkou.

Proč tomu tak vlastně je? Důvody je zapotřebí hledat nikoliv ve vlastní filozofii DR a její implementaci, ale v samotném informačním systému. Ten je totiž málokdy statický, ale dynamicky se vyvíjí a mění. Všechny změny se pochopitelně testují a zkoumají, ovšem (zpravidla) pouze s ohledem na provozní podmínky. Tedy nikoliv na to, jak se projeví právě v DR.

Je to ostatně logické, protože změny v DR se velmi špatně testují. A více než kde jinde právě zde platí ono okřídlené „malá změna znamená velké důsledky“, aneb na první pohled drobná úprava v informačním systému a v principu jeho fungování se v konečném důsledku může projevit (a v praxi často i projevuje) naprostým překopáním celého DR.

Zatím nikdo přitom nevymyslel, jak v DR stoprocentně a jednoduše reflektovat každou změnu. Firmy zabývající se jeho implementací se celkem logicky brání tím, že DR dělá jen to, co jest mu dáno do vínku a že to není žádný systém s „nadpřirozenými“ schopnostmi. Což je samozřejmě pravda, ale otázku snadného a rychlého reflektování změn to pochopitelně neřeší.

Něco se stalo?

Svět je plný absurdit a jedním z největších takových problémů v oblasti ICT bezpečnosti je otázka: „Jak zjistíme, že se vlastně něco stalo“. Zatímco v reálném světě se na průšvih přijde zpravidla hned, ve světě virtuálním některé věci nemusejí být na první pohled patrné.

Zpravidla jsme odkázáni na monitorovací schopnosti firewallů, systémů IDS a IPS. Jejich značnou nevýhodou ale bývá, že zastavují pouze nelegitimní provoz.

Co ale s útoky, které se skrývají za provozem legitimním? Nebo s útoky, které jsou vedené postupně a roztříštěně? To znamená, že se neprojeví najednou a ve velkém stylu, ale postupně na různých místech ve formě drobných projevů.Všechna síťová zařízení obecně ukládají logy. Problém ale je, že každý produkt vytváří svůj vlastní záznam a často v navzájem nekompatibilním formátu – a to se bohužel mnohdy týká i zařízení od jednoho výrobce.

Dát dohromady jednotlivé logy a vyhodnotit je se tak může stát přímo nadlidským úsilím. Přitom informace o útoku mnohdy máme přímo před očima, ale prostě je nevidíme.

A tak vznikl obor označovaný jako log management, jehož úkolem je řídit zmíněné záznamy, aby nešlo pouze o data, ale abychom z nich byli schopni vytěžit informace.

Logy je zapotřebí vzájemně korelovat a dát dohromady relevantní data – například časově souvislé události. Zkrátka: nejde pouze o sbírání dat, ale také o jejich vyhodnocování. Protože bez vyhodnocování logů budeme pouze úředníky, kteří plní šanony kolem sebe, aby byli důležití.

Ale pokud ty šanony neotevřeme, tak se nikdy nic nedozvíme. Spousta šanonů (logů) v žádném případě neznamená zajištění bezpečnosti.

Základní problémy log managementu jsou přitom následující:

• Informací je moc. Logy stále bobtnají, řečeno slovy: pořád se něco děje. Práce s nimi je čím dále obtížnější.

• Není na první pohled vidět, co je důležité. Informací je hodně, často se podobají jako vejce vejci – ale přitom některý údaj může mít výrazně vyšší důležitost než údaj jiný. Přestože jsou na první pohled tak podobné.

• Jakým způsobem data korelovat? Aneb jak je třídit a poskládat tak, abychom se zbavili marastu a k sobě se dostaly pouze informace důležité?

Samozřejmě, že s tímto neradostným stavem se nelze s klidným svědomím pasivně smířit. V prvé řadě je zapotřebí data filtrovat – ač jsou si velmi podobná, přece jen je běžný provoz poněkud odlišný od úkonů mimořádných.

Dále je nutné aplikovat na tato data pravidla, což bývá kamenem úrazu. Jak se takový útok vlastně pozná? Kdyby se na tuto otázku dalo odpovědět jednou větou nebo jediným algoritmem, bylo by to krásné. Ovšem na druhé straně: jako první by situace zneužili útočníci, kteří by své ataky upravili tak, aby se dostali zpod křídel této definice.

Plány, plány, plány…

DR je soubor procesů, politik a procedur, které slouží k obnovení původního stavu po nečekané události. Kromě snadno představitelného obnovení dat (za záloh, znovuvytvořením apod.) slouží také k obnově přístupu ke komunikaci nebo k pracovním místům.

Jde tedy o komplexní systém: pokud stojíte nad vyhořelou serverovnou a data máte zálohovaná na páskách v dodávkovém vozidle, nicméně nemáte je kam odvézt a kde použít, pak jste DR jaksi nezvládli.

Aby se zvýšila pravděpodobnost úspěšného obnovení, je zapotřebí plán. Uvádí se, že velké firmy vydávají dvě až čtyři procenta svého rozpočtu na DR. Přitom často nejde o peníze v této kolonce, ale o činnosti, které vykonávají takřka podvědomě. DR je zkrátka něco jako pojištění – je to jistota stability, kterou si vytváříme v dobách dobrých, abychom překonali časy zlé.

***tento článek vyšel v tištěném SecurityWorldu 2/2009