Důvodů, proč spousta bezpečnostních incidentů zůstává neodhalena, je několik. Jedním z nich je zavedení incident managementu. Ano, čtete správně. Vzhledem k tomu, že hlavním cílem incident managementu je obnovit službu tak rychle, jak jen to je možné, je zřejmé, že k zajištění důkazů obvykle nedochází. A nejsou-li důkazy, není možné zjistit příčinu, a tak se ani nedozvíme, že to byl např. malware, který nefunkčnost stanice způsobil. V praxi to totiž většinou funguje tak, že se nezkoumá, co nefunkčnost způsobilo, ale postupuje se přesně v souladu s výše uvedenou definicí. To znamená obnovit službu tak rychle, jak je to jen možné. Takže stanice se během několika minut obnoví z image a všichni jsou spokojeni.

• Uživatel je spokojen, neboť na to, že si stáhnul z internetu nebo přitáhl na USB flash disku hru, která obsahovala malware se nepřišlo, protože data na jeho HD byla přepsána.
• Vedoucí pracovník tohoto uživatele je spokojen, protože jeho podřízený může zase pracovat na přidělených úkolech.
• Manažer a operátoři helpdesku jsou spokojeni, neboť se jim podařilo službu rychle obnovit, obzvlášť když jsou mimo jiné hodnoceni i za počet vyřešených incidentů.
• Manažer ICT je spokojen, neboť to už je x-tá stanice, která mohla být takto rychle obnovena a investice do SW pro imagování stanic se díky tomu rychle zhodnocuje.
• Dokonce i CIO je spokojen. Proč by také nebyl, když se SLA plní na 100% a ze strany odběratele se neobjevila zatím jediná stížnost na kvalitu poskytovaných služeb.

V čem je tedy problém?

Problém spočívá v tom, že služba, kterou toto ICT poskytuje, je prostě drahá. Především proto, že společnost, která tuto službu odebírá, platí za něco, za co by vlastně ani platit nemusela. Kdyby byl totiž kromě incident managementu zaveden i problem management, jehož cílem je zjistit právě příčinu incidentu, výrazně by poklesl i počet těchto incidentů. Helpdesk totiž dost často řeší stejné incidenty, ale neodstraňuje jejich příčinu, pouze následek. To by se mělo zavedením problem managementu rozhodně změnit. Příčina by se měla analyzovat a následně by se mělo zvolit vhodné opatření k zabránění opakování daného incidentu. Součástí problem managementu by mělo být i vybudování knowledge base, tedy jakési databáze znalostí. Tím by mělo být zaručeno, že v okamžiku, kdy se daný incident znovu objeví, všichni budou vědět jak na něj správně reagovat a nebudou ztrácet drahocenný čas. Nehledě na to, že takto můžeme stanovit lépe závažnost incidentu. Měli bychom si ohlídat, aby v SLA byla uvedena hodnota MTU neboli (Maximum Tolerable Unavailability) v takovém případě víme, kolik máme času na zajištění důkazního materiálu a obnovu funkčnosti v souladu DRP.

Proč je důležité zjistit příčinu incidentu?

Bez zjištění příčiny incidentu není možné navrhnout a implementovat vhodná opatření k zabránění opakování tohoto incidentu. Nefunkčnost lze sice vyřešit restartem aplikace nebo serveru, ale pokud nezjistíme, co přesně nefunkčnost způsobilo, můžeme se dostat do situace, že se tento incident bude opakovat stále častěji. A nikdy se nedozvíme, že se jednalo o bezpečnostní incident, jehož původcem byl např. malware, který se nacházel na úplně jiném stroji, a který pouze využíval daný stroj k tomu, aby mohl napadat ostatní servery v síti, a využívat toho, že na nich nejsou nasazeny poslední patche. Také náklady spojené s realizací DRP mohou časem dosáhnout výše, která výrazně překročí ztrátu spojenou s delší dobou nedostupnosti dané služby, kterou by si šetření incidentu vyžádalo. Navíc platí, že klienti jsou obecně ochotni tolerovat jednou za čas delší výpadek, než když daná služba každou chvíli nefunguje.

Poznámka: V okamžiku, kdy zavedete problem management, můžete očekávat, že se vám výrazně zvýší počet bezpečnostních incidentů.

Related posts:

1. Bezpečnostní incident
2. Bezpečnostní incident: stanovení závažnosti incidentu
3. Incident management: jeden nástroj lepší než druhý

Stanovit správně závažnost bezpečnostního incidentu bývá velice často problém. Navíc se závažnost může v průběhu životního cyklu incidentu měnit. Např. na počátku vyšetřování bezpečnostního incidentu se může zdát, že se jedná o bezpečnostní incident se zanedbatelným dopadem na společnost, a teprve až v průběhu šetření se může ukázat, že původní předpoklad byl mylný.

Pokud už mají společnosti zavedený nějaký proces, který by se dal s trochou nadsázky označit jako incident management a v rámci tohoto procesu stanovují závažnost jednotlivých bezpečnostních incidentů, tak se jejich přístup značně liší. To, že jednotlivé společnosti používají různý počet stupňů pro vyjádření závažnosti bezpečnostního incidentu a jednotlivé stupně mají i různě pojmenovány, je pochopitelné. Zarážející však je, že pro stanovení stupně závažnosti nemají definována jasná pravidla.

Pokud společnost provedla analýzu rizik např. v souladu s metodikou popsanou v knize Řízení informačních rizik v praxi, může poměrně snadno stanovit závažnost bezpečnostního incidentu podle hodnoty aktiva, jehož důvěrnost, integrita nebo dostupnost byla nebo by mohla být narušena. Jak již ale bylo naznačeno v článku Bezpečnostní incident, možností je více. Pojďme se nyní zamyslet nad tím, na základě jakých kritérií můžeme závažnost stanovit.

Jednotlivé stupně závažnosti si pojmenujme např. takto:

• nízká (N)
• střední (S)
• vysoká (V)
• kritická (K)

Podle množství postižených uživatelů:

• jeden nebo několik málo uživatelů (N)
• celá pobočka (S)
• celý region (V)
• celá společnost (K)

Podle úrovně, která se bude incidentem zabývat:

• referent (N)
• nižší management (S)
• střední management (V)
• vrcholový management (K)

Podle toho, kdo musí být s incidentem seznámen:

• Jeden nebo několik málo zaměstnanců společnosti (N)
• Všichni zaměstnanci společnosti (S)
• Kromě vlastních zaměstnanců i osoby mimo společnost (V)
• Kromě vlastních zaměstnanců i veřejnost (K)

Podle úrovně odbornosti:

• první úroveň podpory (N)
• správce systému (S)
• bezpečnostní expert (V)
• bezpečnostní firma (K)

Bez ohledu na velikost organizace a předmět podnikání by měly čtyři stupně pro stanovení závažnosti bezpečnostního incidentu většině společností stačit.

A podle čeho stanovujete závažnost bezpečnostních incidentů ve vaší společnosti vy?

Related posts:

1. Bezpečnostní incident
2. Bezpečnostní incident: Drahý incident management
3. Bezpečnostní incident: role vyšetřovatele

Způsob vedení vyšetřování závažného bezpečnostního incidentu, který má na svědomí vlastní zaměstnanec společnosti, vykazuje určité odlišnosti od způsobu vedení vyšetřování incidentu, který byl veden útočníkem mimo organizaci a jehož totožnost neznáme a ani netušíme.

Je zajímavé, že ač má většina ISIRT (Information Security Incident Response Team) obvykle vypracovány postupy, jak provádět vyšetřování v případech, kdy došlo k bezpečnostnímu incidentu provedeného neznámým pachatelem odněkud z internetu, tak postupy pro šetření bezpečnostních incidentů, které mají na svědomí vlastní zaměstnanci, vypracovány většinou nemají. Přestože nejrůznější průzkumy a statistiky mluví zcela jasně a jejich závěry jsou naprosto jednoznačné, společnosti si jaksi nechtějí připustit skutečnost, že až 80% útoků je vedeno právě zevnitř organizace a vypracování odpovídajících postupů nevěnují dostatečnou pozornost.

Proč v případě bezpečnostního incidentu, který spáchal vlastní zaměstnanec postupovat trochu jinak? V případě, že útok provedl neznámý pachatel odněkud z internetu, se tato skutečnost dost často stává dříve či později veřejně známou. To, že je nedostupná nějaká služba, kterou společnost poskytuje, že se na internetu objevila důvěrná data, které společnost zpracovává, nebo že daná služba nefunguje tak jak má, to je něco co, se dost dobře před veřejností utajit nedá. Nezřídka se také vlastní zaměstnanci o této skutečnosti dozvědí dříve z televize nebo z internetu, než od svého zaměstnavatele. V takovém případě obvykle společnost informace o tom, co se stalo, netají, ale naopak se snaží zaměstnance s incidentem detailně seznámit, aby případně jí mohli poskytnout relevantní informace, které by vedly k odhalení pachatele, věděli, na co si mají dát pozor a v neposlední řadě i jak mají komunikovat s médii a odpovídat na dotazy klientů společnosti.

Na tomto místě bych chtěl také zdůraznit, že ten kdo dává podnět k vyšetřování, nebo ten kdo svolává vyšetřovací tým, není obvykle ten, kdo vlastní vyšetřování vede. Je nutné si uvědomit, že osoba, která podnět k vyšetřování dává, bývá dost často i osoba, která se cítí nějak poškozena nebo poškozenou stranu zastupuje. Nejenže není způsobilá k vyšetřování, neboť nemá potřebné zkušenosti, znalosti, schopnosti a dovednosti, ale nemůže z podstaty věci ani zaujmout v rámci šetření objektivní přístup. Hrozí zde, že se vyšetřování bude ubírat jiným směrem, nedojde k včasnému a správnému zajištění důkazního materiálu nebo bude důkazní materiál zničen, případně dojde k úniku informací z vyšetřování.

Problém mimo jiné spočívá také vtom, že společnosti v této oblasti mezi sebou nespolupracují, informace o těchto incidentech nejsou nikde publikovány a tak se nelze divit, že neexistují spolehlivé postupy jak důkazy zajišťovat, tzn. jak je pořizovat, uchovávat, jak s nimi pracovat, jak je vyhodnocovat a též jak je prezentovat. Problémem je i skutečnost, že se ve většině případů často zajišťují jen „digitální” stopy a zajištění klasických stop u běžných případů neprobíhá, málokdo asi snímá otisky prstů z klávesnice, myši, výpočetní techniky a má záznamy z kamery, aby mohl prokázat, kdo s počítačem opravdu pracoval. Ideální je zajistit původní datový nosič nebo alespoň jeho kopii. Avšak i v případě, že máme k dispozici takovýto důkazní materiál, může být věrohodnost těchto důkazů přesto zpochybněna. Problém spočívá ve spojení identity v informačním systému a fyzické osoby v prostoru a čase.

Vyšetřovací tým by měl být co nejmenší. V ideálním případě by jen jeden člověk měl znát všechny informace související s daným případem. Ostatní by měli znát jen informace nezbytně nutné pro provedení požadovaných úkonů. Důvod je prostý, čím víc osob bude s detaily vyšetřování seznámeno, tím větší je pravděpodobnost, že se informace z průběhu vyšetřování dostanou až k pachateli.

Aby bylo vyšetřování úspěšné, měl by mít vyšetřovatel bez ohlášení a bez předchozího souhlasu kohokoliv z managementu přístup do všech prostor a na všechna pracoviště společnosti. Dále by měl disponovat pravomocí zabavit prostředky výpočetní techniky, které mohou obsahovat důkazní materiál, a též by měl mít možnost v okamžiku, kdy to uzná za vhodné, vést v rámci vyšetřování interview s kýmkoliv, od prostého zaměstnance až po vrcholový management, představenstvo nebo generálního ředitele. Vyšetřovatel by měl mít dále přístup do všech IS systémů společnosti, aby mohl zajistit důkazy. Pro tento účel by mu měl být na všech systémech vytvořen restriktivní účet s právy umožňujícími procházet adresářovou strukturou, zobrazovat obsah souborů a nastavovat auditing. Všichni zaměstnanci by mu měli poskytnout požadovanou součinnost např. k zajištění důkazního materiálu.

Výše uvedené je pro úspěšný průběh vyšetřování zcela zásadní. Bavíme se zde o závažných bezpečnostních incidentech, kde hrozí riziko z prodlení, riziko úniku informací, riziko zničení veškerých stop a důkazního materiálu. Vyšetřovatel musí proto těmito pravomocemi a oprávněními v IS systému disponovat ještě dřív, než k incidentu nebo k zahájení vyšetřování dojde. Z výše uvedených důvodů také není žádoucí, aby do průběhu vyšetřování, které vyšetřovatel vede, kdokoliv zasahoval. Případné námitky proti způsobu vedení vyšetřování mohou být vzneseny kýmkoliv dodatečně a musí být přezkoumány nezávislým orgánem.

Je zřejmé, že vyšetřovatel musí (pokud má společnost opravdu zájem na tom, aby se něco vyšetřilo) za účelem své práce disponovat odpovídajícími pravomocemi, a proto je nanejvýš žádoucí, aby se jednalo o osobu vybavenou nejen potřebnými znalostmi, schopnostmi a dovednostmi, ale i osobu dostatečně a vhodným způsobem prověřenou. Vyšetřovatele však musí být také možné kontrolovat a z vyšetřování v případě zjištění závažných procesních pochybení odvolat. Za tímto účelem by měl vyšetřovatel vést deník, do kterého bude zaznamenávat svůj postup, evidovat důkazní materiál a tento deník pravidelně nebo na vyžádání předkládat svému nadřízenému. Vyšetřovatel by neměl brát tento požadavek jako zbytečnou byrokracii nebo projev nedůvěry – tímto způsobem vyšetřovatel chrání především sám sebe.

Způsobů jak daného adepta na pozici vyšetřovatele prověřit, je více. Vyšetřovatel bude pravděpodobně z útvaru nebo týmu, který  v dané společnosti řeší problematiku informační bezpečnosti. Mělo by se jednat o osobu, která dlouhodobě dosahuje požadovaných výsledků a vyznává stejné hodnoty, jako společnost pro kterou pracuje. Tato osoba by měla být vybrána na základě dlouhodobého sledování. Ověření její způsobilosti k této činnosti může být provedeno testem, který bude spočívat např. ve vyšetřování jí blízké osoby. Adept však nesmí tušit, že se jedná o cvičný úkol a neměl by ani tušit, že víme o tom, že k dané osobě má nějaký vztah. Tím se velice přiblížíme skutečné realitě. Následně vyrobíme důkazy, které budou svědčit v neprospěch této osoby a budeme sledovat, jak se náš subjekt zachová, zda důkazy zničí nebo bude dělat, že je neviděl nebo bude danou osobu kontaktovat a o zahájení šetření ji informovat či ji jiným způsobem varovat. Za správný přístup se obecně považuje, že vyšetřovatel prohlásí, že nemůže být vzhledem k jeho vztahu k dané osobě objektivní a sám požádá, aby byl z šetření daného případu odvolán.

Related posts:

1. Bezpečnostní incident: stanovení závažnosti incidentu
2. Bezpečnostní incident: Drahý incident management
3. Bezpečnostní incident

Za bezpečnostní incident se často považuje i podezření na porušení bezpečnostní politiky nebo pokus o překonání bezpečnostních opatření. Bezpečnostní incident má obvykle tento průběh: detekce incidentu – analýza incidentu – reakce na incident. Detekce může být automatická na základě informace z nějakého monitorovacího systému nebo manuální tzn., že incident někdo nahlásí. Společnost, která má zájem bezpečnostní incidenty efektivně řešit, by měla vydat odpovídající bezpečnostní standard a vhodnou formou s ním seznámit všechny zaměstnance. Dalším krokem je sestavení týmu, který bude za příjem hlášení, evidenci a šetření incidentů zodpovědný. Zahraniční literatura používá pro označení takového týmu zkratku ISIRT neboli Information Security Incident Response Team. Počet členů ISIRT závisí na počtu incidentů a velikosti organizace. Je zřejmé, že pokud má takový ISIRT fungovat, musí disponovat i odpovídajícím vybavením a pravomocemi.

V bezpečnostním standardu by mělo být uvedeno:

• co je to bezpečnostní incident, vhodné je uvést ve formě přílohy i nějaké příklady bezpečnostních incidentů.
• komu se má bezpečnostní incident hlásit. (Měla by být uvedena adresa na intranetu, e-mail, telefon i adresa pracoviště, protože  je třeba počítat s tím, že síťová infrastruktura nemusí fungovat.)
• jakou formu má hlášení o bezpečnostním incidentu mít. Standard by měl obsahovat ve formě přílohy formulář pro hlášení bezpečnostního incidentu.

U bezpečnostních incidentů bychom měli evidovat:

• kdy k incidentu došlo – vzhledem k tomu, že incident může souviset s jinou událostí, je vhodné vždy zjistit přesný čas.
• kde k incidentu došlo – přesné určení místa a jeho popis umožní vyšetřovacímu týmu rychle reagovat.
• kdo incident spáchal – identitu útočníka může být někdy obtížné zjistit, přesto bychom se měli pokusit získat o něm co nejvíce relevantních informací.
• jak k incidentu došlo – někdy nemáme dostatek informací, nicméně měli bychom se pokusit alespoň o pravděpodobný scénář popisu průběhu incidentu.
• co bylo cílem útoku – měli bychom také rozlišit, zda byl systém přímo cílem útoku nebo sloužil k přípravě na další útok.
• jaký atribut bezpečnosti byl narušen – tzn. zda byla narušena integrita, důvěrnost, dostupnost nebo neodmítnutelnost.
• jaký byl charakter narušení  - zda narušení bylo úmyslné nebo neúmyslné. A pokud neúmyslné, tak zda plynulo z nedbalosti nebo z neznalosti bezpečnostní politiky.
• jaké opatření bylo překonáno – zda bylo překonáno opatření na úrovni fyzické, logické, organizační, personální nebo technické bezpečnosti.
• jaké aktivum bylo narušeno – hardware, software (operační systém, aplikace, databáze), síť, data.
• jak vysoká je pravděpodobnost, že se incident bude znovu opakovat – spíše nízká, střední, vysoká, jistá.

Samotnou otázkou zůstává na základě čeho stanovit závažnost incidentu. Nabízí se několik řešení. Závažnost incidentu můžeme stanovit na základě hodnoty dopadu. V takovém případě se ptáme, jaký finanční nebo nefinanční dopad incident na danou společnost měl nebo by mohl mít. Jiným řešením je stanovit závažnost incidentu podle počtu a odbornosti lidí, kteří se na řešení incidentu podíleli. Lze předpokládat, že na řešení různých incidentů se bude podílet různý počet osob nebo týmů s různou úrovní znalostí.

Zjednodušený postup při šetření bezpečnostního incidentu:

1. identifikovat, kde k bezpečnostnímu incidentu došlo,
2. co nejrychleji zamezit dalším škodám,
3. analyzovat příčinu a zajistit stopy pro další analýzu,
4. odstranit příčinu a obnovit funkčnost,
5. zhodnotit škody,
6. navrhnout a implementovat vhodná opatření k zamezení opakování tohoto incidentu,
7. seznámit ostatní s výsledky šetření.

V praxi bývá dost často problém se splněním bodu 3, protože management většinou požaduje okamžitou obnovu provozu a na zajištění důkazů a zjištění příčin tak nezbývá čas. Ignorováním bodu 3 však máme značně ztížené podmínky v bodu 6, kdy bychom měli navrhnout vhodná opatření pro zamezení opakování incidentu. Volba vhodného opatření je v takových případech velice obtížná a společnosti nezbývá nic jiného než doufat, že se incident znovu nevyskytne.

Vybavení ISIRT:

• tým by měl mít vypracované postupy pro šetření jednotlivých typů incidentů a tyto postupy by měl aktualizovat s ohledem na nové typy incidentů,
• tým by měl mít vypracovaný komunikační plán, aby bylo zřejmé, kdo má koho informovat, kdo rozhoduje o dalším postupu atd.
• tým by měl mít k dispozici společnou místnost (war room), kde bude možné se v případě incidentu sejít a dohodnout se na dalším postupu,
• tým by měl mít k dispozici odpovídající SW a HW prostředky, aby si mohl např. pořídit kopii konfigurace, logů a případně i celého diskového oddílu napadeného systému.

Poznámka: Proces řízení bezpečnostních incidentů je popsán v mezinárodní normě ISO/IEC TR 18044 Information technology – Security techniques – Information security incident management.

A jak bezpečnostní incidenty zvládáte ve vaší společnosti vy?

Related posts:

1. Bezpečnostní incident: stanovení závažnosti incidentu
2. Bezpečnostní incident: Drahý incident management
3. Bezpečnostní incident: role vyšetřovatele