Rozbor bezpečnostního incidentu

Ať děláme, co děláme, preventivní bezpečnostní opatření ne vždy pracují zcela spolehlivě. K nějakému menš...


Ať děláme, co děláme, preventivní bezpečnostní opatření ne vždy pracují zcela
spolehlivě.


K nějakému menšímu či většímu incidentu téměř vždy dojde. Díky bezpečnostní
politice a předpřipraveným opatřením se s ním sice vypořádáme se ctí, ale...
Nemůžeme usnout na vavřínech a spokojeně si mnout ruce "tak jsme to (zase)
zvládli". Bezpečnostní incident totiž znamená, že "tesař někde nechal díru".
Tedy že ne vše, co jsme implementovali, bylo plně funkční. Uvědomme si také, že
bezpečnostní incidenty bez viníka neexistují - existují jen incidenty, kde se
viníka vypátrat nepodařilo. Nicméně i to je příznak nedokonalosti a i tentokrát
je zapotřebí udělat vše pro to, aby se podobná situace neopakovala.
Dělat chyby je lidské, ale jejich opakování už s lidskostí nemá mnoho
společného. Proto je nutné se beze zbytečných emocí pokusit provést analýzu
celého incidentu, a to tak, abychom se dostali k místu/okamžiku, kdy došlo k
chybě. Aby tuto bylo možné odstranit nebo alespoň potlačit, čímž pro příště
zvýšíme bezpečnost celého systému.

Co po incidentu
Incident je za námi, poplach je odvolaný a vše funguje zřejmě normálně.
Přestože se asi málokomu chce ohlédnout dozadu a zabývat se otázkami, které
jsou již za námi, tato činnost není samoúčelná a provedení "pitvy" celého
incidentu nesmírně pomůže při zajišťování bezpečnosti do budoucna. Samotný
bezpečnostní incident totiž v pořádku není a je nutné vynaložit veškeré možné
úsilí, aby se opakoval co nejméně a s minimálními důsledky na stav či chod
organizace.
S rozborem bezpečnostního incidentu je zapotřebí začít co nejdříve. Samozřejmě,
že nemá smysl se incidentem zaobírat ve chvíli, kdy trvá či kdy probíhá
likvidace následků. Ostatně, v tomto okamžiku by ani rozbor neměl smysl,
protože ještě nejsou k dispozici veškeré potřebné informace.
Pro rozbor a diskusi je nutné si důkladně nachystat podklady, které odpovídají
povaze proběhlého bezpečnostního incidentu. Jedná se o nejrůznější logy,
e-mailové zprávy, výpisy sledování provozu na síti apod. Pokud některý klíčový
dokument chybí, hledejte odpověď na otázku, proč chybí. Jsou špatně nastavené
některé kontrolní mechanismy, něco bylo přehlédnuto, není k některým datům
přístup, data jsou špatně zálohována, došlo k selhání lidského faktoru atd.? A
zároveň řešte otázku, co udělat pro to, aby tento (respektive žádný) dokument
příště nechyběl.
Veškeré tyto podklady přitom považujte za přísně tajné, protože až do
odstranění problému ukazují na slabé místo vašeho informačního systému. Jistě
by nebylo dobré, kdyby se k těmto informacím dostalo více osob, než je nezbytně
nutné, například i těch hledajících v odpadkovém koši. Ostatně, trashing
(vybírání odpadků a jejich následné zkoumání z hlediska přítomnosti citlivých
informací) je metoda populární u hackerů na celém světě. A přestože na
"dumpster divers" ("potápěče do odpadků") často pohlížíme skrze prsty, jedná se
o metodu nesmírně účinnou.
Vlastní "pitva" událostí bývá povětšinou velmi emocionální. Je to ostatně
pochopitelné, neboť málokdo rád přiznává chybu svoji nebo některého ze svých
podřízených. Musíte ale mít na paměti, že cílem aktivity není někoho
pranýřovat, nýbrž zvýšit bezpečnost ICT v organizaci. Pranýřováni by naopak
měli být ti, kdo stojí v cestě úplnému vyšetření nebo se na něm plně
nepodílejí.

Časová osa incidentu
Emoce jsou tedy potlačeny a můžeme se vrhnout na skládání kompletního obrazu
celého incidentu, tedy pokud se podaří na základě dostupných dokumentů a
svědectví tento obraz poskládat. Nejlepší je na základě dat poskládat časovou
posloupnost incidentu, jež je ze všech posloupností nejpřehlednější. K ní
následně přiřaďte události incidentu a úkony jednotlivých osob.
Nyní je čas odpovědět si na otázku, zda všichni reagovali včas a stanoveným
způsobem. A ani tentokráte není cílem hry dostat někoho na pranýř - často se
totiž ukáže, že chyba byla někde jinde (třeba nedostatečně vyřešená
zastupitelnost, nevčasné rozpoznání incidentu aj.). Kromě toho nezapomínejte,
že incident nikdy neprobíhá podle plánu, který jste pro něj vypracovali. Vždy
je zapotřebí počítat s určitým prvkem náhody nebo improvizace. Ostatně, kdyby
incident pokaždé probíhal podle plánu, nejspíše by nikdy nevznikl.
S vytvořenou časovou osou bezpečnostního incidentu nyní lze dále pracovat.
Vyznačte si na ní dva důležité body, a to kdy incident vznikl (co nejpřesněji)
a kdy byl zaznamenán. A nyní prozkoumejte všechny okolnosti, které vedly ke
zjištění incidentu: došlo k tomu zcela náhodně, nebo systematickým sledováním?
Nebyl incident v první chvíli podceňován či nedoceňován? Nebylo možné incident
detekovat dříve? Jinými slovy: došlo k odhalení incidentu za optimálních
podmínek (tedy bezprostředně po vzniku), nebo může být příště odhalen mnohem
dříve?
Ovšem na paměti mějte, že důležitý není pouze samotný počátek bezpečnostního
incidentu, ale i jeho průběh a vyřešení. Znovu si tak položte stejné či velmi
podobné otázky. Jaká byla návaznost jednotlivých kroků, odpovídala logice věci,
nebo byly některé kroky či úkony zbytečné, přeskočené či duplikované? Byla
realizace protiopatření systematická, nebo chaotická? Vedla ke kýženému
výsledku? Nechyběly nějaké zdroje (software, lidé, vypracované postupy apod.)?
Každý incident má totiž svoji ideální "kritickou cestu". Těžko ji sice dokážete
po časové ose reakcí vždy sledovat, ale cílem je co nejvíce se k ní přiblížit.
Následně si položte otázku, jak by se situace změnila za jiných podmínek. Tedy
kdyby k incidentu došlo v jinou denní či noční dobu, v jiný den. Byli bychom
připraveni stejně, lépe či hůře? Každý časový úsek má svá specifika, jako je
třeba dostupnost pracovníků.
Neméně důležité je zabývat se také skutečností, zda byl bezpečnostní incident
opravdu cíleným útokem (snaha odcizit data, DoS apod.) či zda šlo o náhodný
útok (příchod viru aj.). Pokud jste se stali terčem cíleného útoku, tak zkuste
zjistit, co bylo jeho skutečnou snahou. Nespokojte se s povrchními
konstatováními, ale snažte se celému problému přijít na kloub - možná najdete
další překvapivé vazby nebo skutečnosti, které jste dříve přehlédli nebo
přehlíželi. Tyto nové skutečnosti pak umožní cíl útoku chránit lépe či jinak.
Je totiž možné, že pokud hacker neuspěl, pak k dosažení svého cíle (znovu
zdůrazňujeme: je nutné správně určit skutečný cíl útoku) příště pravděpodobně
zvolí jinou taktiku. Navíc si prvním útokem mohl jen "oťukávat" terén. I v
tomto může rozbor incidentu ledasco napovědět. Byla cílem útoku data nebo firma
(např. její vyřazení z internetu pomocí DoS)? Odkud útok proběhl - zevnitř,
zvenčí, podílel se na něm jeden počítač/server nebo šlo o koordinovanou akci?
Nebyl přitom útok nebo alespoň sondování k jeho provedení realizován už dříve?
Pokud ano, pak nás útočník de facto varoval a my jsme něco přehlédli. A to by
se stávat nemělo. (Neocenitelnou službu v tuto chvíli má specializovaný
software, který automaticky prochází logy a monitoruje podezřelou aktivitu.)
Rozbor umožní kromě jiného stanovit, zda je skutečně už po útoku. Fakt, že
odezněly všechny viditelné nebo přímé projevy neznamená, že skutečný cíl útoku
nebyl odlišný od toho, co se zdálo. Některé útoky jsou totiž prováděny s tím,
že mají zakrýt skutečný cíl zájmu nebo jej usnadnit. Hackeři tak vás různými
způsoby nutí restartovat systémy (což je viditelný projev) třeba proto, aby
mohli být aktivováni trojští koně již dříve do systému umístění (a to na první
pohled nemusí být projev patrný).
Pokud bezpečnostní incident představuje zároveň trestný čin, pak nezapomeňte
uschovat/vyhotovit průkazné materiály pro případné policejní šetření nebo
následné důkazní řízení. Vyčíslete také vzniklou škodu a připojte metodiku,
jakou jste k ní dospěli.

Dokumentace
Vypracujte zprávu z bezpečnostního incidentu, a to pro management i pro
zainteresované pracovníky. Zpráva by měla obsahovat doporučení vyplývající z
rozboru. Následně tato doporučení nezapomeňte nasadit v praxi, zkontrolovat
jejich implementaci a prověřit účinnost - aby se nestalo, že byste jeden
problém vyřešili, ale další dva vytvořili.
A poučení? Prostě se snažte z bezpečnostního incidentu vytvořit pozitivní
událost, která jednak prověřila vaše pracovníky i mechanismy a jednak pomůže
zvýšit bezpečnost informačního systému do budoucna. A i když je pravděpodobné,
že se nepodaří zabránit dalšímu incidentu, pokud se "jenom" podaří pro příště
snížit vzniklé škody, je to dobře.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.