Pozor: Co při útoku hackerů nedělat!

„Zamkněte dveře,“ nařídil letový ředitel NASA LeRoy Cain. „Nevypínejte počítače. Nikdo neopustí své místo. Nikdo nebude telefonovat. Zazálohujte všechna dostupná data, odložte své poznámky.“

Kalendář ukazoval 1. února 2003 a letový ředitel právě čelil nejhoršímu možnému scénáři, jaký si bylo možné představit: během přistávacího manévru se nad Texasem rozpadl raketoplán Columbia.

Ač Cainovi stékaly slzy z očí – na palubě stroje bylo sedm astronautů a šance přežít rozpad raketoplánu ve výšce 65 kilometrů při rychlosti 6,5 km za sekundu a obklopeném žhavou plazmou o teplotě několika tisíc stupňů Celsia byla nulová – zachoval si chladnou hlavu.

Postupoval přesně podle předem připravených plánů a zachránil všechna data uložená v počítačích, což později významně pomohlo zrekonstruovat průběh nehody.

Samozřejmě je velmi nepravděpodobné, že by někdo z nás jednou čelil podobné situaci. Na druhé straně si z ní každý z nás může odnést ponaučení při řešení bezpečnostních incidentů.

Obvykle nedostatky

Naším nejčastějším prohřeškem ve chvíli, kdy se „něco stane“, je to, že nemáme plán reakce (Incident Response, IR). Samozřejmě v takové chvíli už je pozdě na něj myslet, ale to je o důvod víc nachystat si jej dříve, než bude pozdě.

Když je jakýmkoliv způsobem bezpečnostní problém odhalený, často se ukáže, že není jasné, co se má dělat. Není stanovená osoba nebo tým, dokonce nebývá stanovený ani postup.

Většinou je pouze vyrozuměn pracovník IT oddělení, ale to se často děje jen jaksi automaticky. V případě absence „horké linky“ nemusí být navíc k zastižení.

Stejně tak nemusí vědět, co přesně má dělat (s informatikem, který vše řeší doporučením restartu, se asi setkal každý z nás). A navíc nemusí mít vůbec zájem incident nějak důkladně šetřit: vždyť incident může (ale samozřejmě také nemusí) ukázat na jeho osobní selhání.

Ostatně to není problém pouze IT pracovníků, i na úrovni organizací je často snaha incidenty „zametat pod koberec“ a zásadně nepřiznávat chybu.

Proto je nezbytně nutné mít alespoň základní plán zvládání bezpečnostních incidentů. Ovšem pozor: plán musí být funkční. Zatímco zhruba šedesát procent organizací jej má, praxe ale ukazuje, že zhruba dvě třetiny plánů v praxi nefungují.

Často se vytvoří, aby se učinilo zadost zadání nebo aby se zaplnila mezera identifikovaná během některého z nesčetných auditů. Byť to zní vznosně, plán zvládání bezpečnostních incidentů je čas od času potřeba prověřit ostrým cvičením. To odhalí drobnosti, které jinak zůstávají přehlédnuté.

Třeba jako v případě jisté newyorské nemocnice, která si bezpečnostní audit nechala zpracovat – konstatovalo se v něm, že záložní dieselové agregáty v suterénu nejsou šťastným nápadem a že v případě velké vody nebudou plnit svoji úlohu.

Nemocnice je proto přesunula do vyšších pater. Auditor byl spokojený, problém se zdál být odstraněný. Pak ale přišel říjen 2012 a udeřil hurikán Sandy. Až v tu chvíli nemocnice s hrůzou zjistila, že agregáty sice přesunula – ale nádrže s naftou zůstaly v zaplaveném suterénu...

Jeden problém navazuje na druhý

Často na bezpečnostní incident reagujeme odstraněním nalezeného malwaru (což je nejčastější forma incidentu), a útok tím máme za ukončený. Jenže...

Tím se připravujeme o stěžejní důkazy, které nám mohou hodně napovědět o tom, kudy se útočník dostal do systému, kdy se tak stalo, jaké byly jeho záměry a co všechno vlastně získal. Druhou chybou, kterou v takové chvíli děláme, je vypnutí počítačů. Tím přicházíme o logy, nenahraditelná data v paměti apod.

Předpokládejme vždy nejhorší možný scénář: útok profesionála. Ten pak těžko použije jeden vektor, v horším případě mu dokonce sednete na vějičku: nastrčí kód, u něhož chce, aby byl nalezený. Skutečné nebezpečí se pak skrývá jinde. Dobrý útočník zkrátka bývá dobře připravený.

Samozřejmě že nikdo nechce, abyste se s rukama v klíně dívali, jak vám útočník stahuje další a další data ze sítě. Ale odstřihnout ho můžeme i jinak než vytržením elektrické šňůry ze zásuvky.

Například aktivací přísných omezení na firewallu nebo převodem veškerého provozu do uzavřené VPN sítě. Útočník sice bude výpadkem datového toku varován, ale vy nepřijdete o cenné informace.

A především: získáte čas a budete se moci rozhlédnout po informačním systému, aby bylo možné zmapovat celou šíři útoku.

Známý je například případ jedné americké banky, kdy útočník umístil do systému škodlivý kód. Po jeho odhalení následoval hloubkový bezpečnostní audit, který zjistil, že útočník ve skutečnosti zanechal v systému přes 300 druhů různého malwaru. Jinými slovy: odhalení jednoho exempláře zabránilo mnohem většímu útoku.

Zatajit, nebo nezatajit?

Kolik IR plánů tedy instrukce týkající se krizové komunikace obsahují? Tedy to, koho, kdy a jak informovat – nebo kdo má právo hovořit. Pokud nás k tomu legislativa nenutí jinak, máme tendenci bezpečnostní incidenty utajovat. Jistá logika v tom je: následná panika může natropit více škody než vlastní incident.

Na druhé straně si pak informace mohou žít svým vlastním životem. „Informovat, či neinformovat“ tak představuje jedno ze zásadních dilemat informační bezpečnosti – ale i to se však dá do značné míry ošetřit v plánech reakce.

Tento příspěvek vyšel v Security Worldu 2/2015. Časopis (starší čísla i předplatné těch nadcházejících) si můžete objednat na adrese našeho vydavatelství.