Nacházíme se v hybridní době. Řada zaměstnanců se nevrátila do kanceláří a stále pracují z domova. Uživatelé ani administrátoři nejsou střeženi perimetrem a dalšími ochrannými prvky infrastruktury. Lidé se pohybují v soukromých sítích, které mnohdy nemají ve své správě. Tato situace ohrožuje aktiva, která máme za úkol chránit, a z pohledu řízení rizik představuje hrozbu. Musíme tedy reagovat na skutečnost, že jednotlivé prvky, na které se systém efektivního řízení bezpečnostních událostí a incidentů vztahuje, nejsou zcela pod naší kontrolou.
Incident management SIEM Service ITIL
Základní předpoklady
Výchozí dispozice podporující nezbytnost zavedení systému řízení bezpečnostních událostí a incidentů můžeme najít v zákonu o kybernetické bezpečnosti. [1] Zákon nám – jak ve svých technických, tak i organizačních opatřeních – udává povinnost detekovat, zaznamenávat, ale i vyhodnocovat kybernetické bezpečnostní události. Rovněž nám pomáhá rozlišit a vymezit pojmy kybernetické bezpečnostní události a kybernetického bezpečnostního incidentu. V rámci efektivního řízení je tedy nezbytné rozhodnout, zda se jedná o bezpečnostní událost, nebo o incident. Jako základní odrazovou platformu je však vhodnější použít vyhlášku o kybernetické bezpečnosti [2], která v § 14 přímo definuje nutné činnosti, které je třeba vykonat v oblasti zvládání kybernetických bezpečnostních událostí a incidentů. Jedná se o následující aktivity:
(1) Povinná osoba v rámci zvládání kybernetických bezpečnostních událostí a incidentů
- zavede proces detekce a vyhodnocování kybernetických bezpečnostních událostí a zvládání kybernetických bezpečnostních incidentů,
- přidělí odpovědnosti a stanoví postupy pro
- detekci a vyhodnocování kybernetických bezpečnostních událostí a incidentů a
- koordinaci a zvládání kybernetických bezpečnostních incidentů,
- definuje a aplikuje postupy pro identifikaci, sběr, získání a uchování věrohodných podkladů potřebných pro analýzu kybernetického bezpečnostního incidentu,
- zajistí detekci kybernetických bezpečnostních událostí,
- při detekci kybernetických bezpečnostních událostí se dále řídí § 22 a 23,
- zajistí, že uživatelé, administrátoři, osoby zastávající bezpečnostní role, další zaměstnanci a dodavatelé budou oznamovat neobvyklé chování informačního a komunikačního systému a podezření na jakékoli zranitelnosti,
- zajistí posuzování kybernetických bezpečnostních událostí, při kterém musí být rozhodnuto, zda mají být klasifikovány jako kybernetické bezpečnostní incidenty podle § 31,
- zajistí zvládání kybernetických bezpečnostních incidentů podle stanovených postupů,
- přijímá opatření pro odvrácení a zmírnění dopadu kybernetického bezpečnostního incidentu,
- hlásí kybernetické bezpečnostní incidenty podle § 32,
- vede záznamy o kybernetických bezpečnostních incidentech a o jejich zvládání,
- prošetří a určí příčiny kybernetického bezpečnostního incidentu a
- vyhodnotí účinnost řešení kybernetického bezpečnostního incidentu a na základě vyhodnocení stanoví nutná bezpečnostní opatření, popřípadě aktualizuje stávající bezpečnostní opatření k zamezení opakování řešeného kybernetického bezpečnostního incidentu.
(2) Povinná osoba uvedená v § 3 písm. c), d) a f) zákona dále při detekci kybernetických bezpečnostních událostí používá nástroj podle § 24.
Náš text primárně vychází z požadavků stanovených v § 14, zejména v bodech a), c), d), f) a k). Vzhledem k tomu, že tyto požadavky nemohou být z pochopitelných důvodů řešeny odděleně, článek zohledňuje i zbývající požadavky zmíněného paragrafu.
Roviny efektivního řízení
Každá organizace, která se chce zabývat otázkou efektivního řízení bezpečnostních událostí a incidentů, musí mít jasno ve třech základních rovinách. První z nich je rovina technologická, u níž – možná překvapivě – příliš nezáleží na tom, jaká technologická řešení jsou používána, ale zda jsou používána efektivně. Klíčem k technologické efektivitě je centralizace, unifikace a srozumitelnost informací, které technologie zaznamenávají, a jejich následné automatizované vyhodnocení.
Druhou rovinou je rovina procesní. Každá organizace potřebuje mít možnost udržovat se svými zaměstnanci blízký kontakt, být s nimi ve spojení prostřednictvím spolehlivého procesního a komunikačního kanálu. Potřebuje bezpečné cesty, díky nimž bude možné transparentně komunikovat a řešit veškeré potřebné záležitosti, jako je předávání informací a dat (např. v podobě logů, screenshotů či jiných záznamů), a to i v případech, kdy zaměstnanci budou pracovat mimo perimetr organizace.
Poslední rovina je uživatelská, zahrnující vedle běžných uživatelů i administrátory a také analytiky a operátory. Touto třetí rovinou do celého řízení vstupuje lidský faktor, který si pro lepší pochopení můžeme rozdělit i podle kompetencí, a to na část technickou a netechnickou. Ta technická je zastoupena jak administrátory, tak i analytiky a operátory, kteří přímo řeší bezpečnostní události a incidenty. Ta netechnická pak zahrnuje běžné uživatele, u nichž se nepředpokládá nutnost hlubšího vhledu do technické problematiky.
Velkou výzvou pro celkové řízení je propojení dvou zcela odlišných oblastí. Světa běžných netechnických uživatelů se světem vysoce expertně orientovaných osob. Předností odborníků je, že mají do dané problematiky detailní vhled, ale ne každý specialista je schopen formulovat vše tak, aby tomu běžný člověk rozuměl. Další výzvou je bezpečnost samotná. Přechodem části uživatelských a administrátorských stanic mimo chráněný perimetr vzniká nejen potřeba jejich vzdálené správy, ale také přenosu a vynucování bezpečnostních mechanismů na tyto stanice.
Obr. 1: Provázanost rovin efektivního řízení
Technologická rovina
Obvyklou reakcí většiny organizací, které se rozhodnou brát bezpečnost vážně, nebo těch, které se snaží dospět k souladu s některým z normativů, je, že si zakoupí další technologické řešení. Většinou takové, které je výrobcem nebo dodavatelem prezentováno v tom smyslu, že svými vlastnostmi pokrývá požadovanou oblast. Z mnoha důvodů, zejména pak z hlediska efektivity, je však výhodnější vyjít z instrumentů, které už daná organizace používá, zaměřit se na optimalizaci stávajících nástrojů a vytěžit již implementovaná řešení na maximum.
Pro efektivní řízení bezpečnostních událostí a incidentů je z technologického pohledu nezbytné mít pokryté zejména základní části infrastruktury. Jedná se o perimetr, o koncové stanice, o informace o tom, co se v infrastruktuře děje (zejména pak kdo a za jakých podmínek přistupuje ke zdrojům a informacím), případně o některé další. Uvedené oblasti jsou však základem, bez něhož nelze stavět efektivní řízení.
Zmíněná technologická řešení zaznamenávají veškeré informace, a tedy i detekce bezpečnostních anomálií a událostí do logů. Každý log se typicky nachází na jiném místě, v jiném formátu. Lze namítnout, že se výrobci bezpečnostních technologií snaží logy poskytnout v unifikovaném formátu. Tento formát ale napříč infrastrukturou zpravidla nebude zcela jednotný. Z důvodu centralizace a unifikace je proto žádoucí tyto informace (logy) sjednotit na jedno místo, kde budou k dispozici ve stejné podobě, a dále je vyhodnocovat. Tímto místem může být řešení typu Log management.
Z pohledu bezpečnosti však není dostatečné mít logy v unifikované podobě na jednom místě. Musí nad nimi být aplikována další logika – pravidla, která kombinují dílčí informace z jednotlivých logů mezi sebou a aplikují na ně další podmínky, tzv. korelace. V takovémto případě není řešení typu Log management dostatečné. I přes fakt, že některá tato řešení umožňují aplikaci pravidel, je žádoucí, aby pravidla nebyla nijak limitována, např. časem, kdy jsou kombinovány logy, rozsahem kombinací, výstupem a jeho prezentací a dalšími. Na základě uvedeného je tedy vhodnější pro centralizaci, unifikaci a vyhodnocení použít řešení typu Security Information and Event Management (SIEM), které obsahuje jak Log management, tak i korelační část, ale i mnoho dalších. Toto řešení zajistí přehled o dění v infrastruktuře na jednom místě téměř v reálném čase pro technicky orientované role, a významně jim tak uvolní ruce. Hlavní výhodou je, že nebudou muset spojovat informace z jednotlivých řešení manuálně, ale SIEM řešení tuto aktivitu vykoná za ně.
Základního naplnění technologické roviny efektivního řízení bezpečnostních událostí a incidentů docílíme tedy tím, že provedeme integraci existujících technologických řešení do jednoho místa. To bude sloužit jako prostor pro shromažďování informací z infrastruktury a rovněž je bude postupovat automatizovanému vyhodnocení – korelacím. Toto řešení však primárně slouží technickým rolím. A právě zde je nezbytné do technologické roviny zapojit i netechnické role, které do řízení vstupují.
Výsledné vyhodnocení bezpečnostních událostí by nemělo být realizováno pouze na úrovni SIEM řešení, ale na samostatné platformě tak, aby k ní byl umožněn přístup i netechnickým uživatelům. Zapojením netechnických uživatelů získáme další cenný detekční mechanismus mimo již definovaný technologický. Za tímto účelem je vhodné provést integraci SIEM řešení se Service Deskovou aplikací, a to pro všechna aktivní detekční a korelační pravidla SIEM řešení. Následně je třeba k této aplikaci poskytnout přístup jak technicky, tak i netechnicky orientovaným rolím s tím, že právě na úrovni této aplikace bude prováděno výsledné řízení bezpečnostních událostí a incidentů.
V úvodu našeho textu jsme zmínili specifické rysy dnešní hybridní doby. Právě ona přispívá k tomu, že z pohledu efektivity, a to zejména v případech bezpečnostních incidentů, je dnes nezbytné řešit stále častěji zásah na stanici mimo námi chráněný perimetr. Tento fakt vede k rostoucímu zájmu o pokročilé řešení pro ochranu koncových stanic – Endpoint Detection and Response (EDR). Daná volba umožňuje – na rozdíl od klasických antivirových řešení – také vzdálený přístup ke stanici, spouštění skriptů nebo přímo ukončování konkrétních procesů a mnoho dalších aktivit.
Tyto činnosti dávají bezpečnostním týmům možnost přímého zásahu na koncové stanici, i když není ve fyzickém dosahu. Toto řešení je rovněž žádoucí integrovat dle již uvedeného. Zde následně vyvstává příležitost k dalšímu rozšíření, a to v podobě povýšení SIEM na úroveň orchestrace, automatizace a reakce v podobě SOAR řešení. SOAR umožňuje vykonávat aktivity reakce, automatizovat dílčí část procesů a mnoho dalšího v obdobném rozhraní jako SIEM. Díky tomu rozšiřuje sběrné a vyhodnocovací schopnosti SIEM řešení o možnost přímého zásahu a automatizace v infrastruktuře z jednoho centrálního místa.
Propojenost jednotlivých dílčích částí technologické roviny znázorňuje schéma (viz Obr. 2).
Obr. 2: Provázanost částí technologické roviny
Procesní rovina
Prvotním předpokladem pro efektivní řízení v rámci procesní roviny je definovat samotný proces řízení, který bude následně bezezbytku dodržován, vynucován a vyhodnocován. Tento proces musí zohledňovat uživatele jako takové. Uživatele lze chápat jako mimořádně silný, ale zároveň stále výrazně podceňovaný nástroj, který může napomoci s detekcí a zároveň významně posílit výslednou úroveň bezpečnosti organizace.
Budou-li uživatelé vhodně zaangažováni, získá organizace další detekční kanál schopný identifikovat bezpečnostní anomálie a události. Proto je vhodné poskytnout jim prostor, v jehož rámci budou moci ohlašovat zjištěné skutečnosti. Jedná se o již zmíněnou platformu, do které jsou integrovány automatizovaně vyhodnocené informace z jednotlivých technologických řešení. Je vysoce žádoucí, aby tato platforma kopírovala a podporovala proces řízení bezpečnostních událostí a incidentů, který má organizace ustanoven. Proces jako takový by měl být složen minimálně z pěti částí, jak je prezentováno na Obr. 3.
Cílem procesu řízení bezpečnostních událostí a incidentů je minimalizace jejich dopadu na aktiva organizace. Prezentovaných pět základních částí tvoří pouze minimální rozsah procesu jako takového. Jedná se o:
- Detekci bezpečnostních anomálií, událostí a incidentů, která je primárním vstupem do celého procesu. Detekci je žádoucí realizovat automatizovaně na úrovni bezpečnostních technologií a manuálně uživateli, řešitelským týmem či zainteresovanou stranou.
- Analýzu, v rámci níž je předchozí detekce vyhodnocena z hlediska relevantnosti. V průběhu tohoto kroku dochází k posouzení, zda se jedná o reálnou bezpečnostní hrozbu vyžadující řešení, nebo o falešný poplach, který představuje chybu v detekčním mechanismu, a tudíž vyžaduje optimalizaci.
- Investigaci, kde je stanovena priorita a upřesněn dopad a jsou navrhovány konkrétní reakční kroky vedoucí k jeho minimalizaci. Cílem investigace je najít minimálně odpověď na otázky: kdo, co, kdy a kde, dále jaký je rozsah a jak je možné omezit dopad. Na základě toho lze definovat návrh postupu reakce zahrnující veškeré zjištění nezbytné ke kvalifikovanému rozhodnutí.
- Reakci, která vede k neutralizaci bezpečnostního incidentu dle předchozího postupu. V rámci reakce je žádoucí realizovat zejména tyto kroky:
- omezení rozsahu dopadu,
- izolaci napadených systémů či aktiv,
- neutralizaci veškerých identifikovaných a zanechaných artefaktů,
- návrat do plnohodnotného provozu.
- Aktivity po incidentu, které by měly být prováděny tak, abychom se z něj poučili. Musíme zaznamenat veškerá fakta, vytvořit nové příručky pro řešení událostí a incidentů a navrhnout zlepšení v oblasti bezpečnosti tak, abychom do budoucna předešli opakování takové situace.
Z procesního hlediska musí celý systém fungovat tak, že:
- Posbírá anomálie z infrastruktury, a to jak manuálně, tak i automatizovaně detekované (pod proces detekce).
- Shromáždí je v uživatelsky čitelné podobě a umožní jejich další zpracování (pod proces analýzy a investigace).
- Podpoří možnost komunikace a předávání informací napříč organizací (pod proces reakce a koordinace při reakci).
- Umožní sledovat dodržování procesu, např. parametrů SLA, umožní jeho vyhodnocení a zlepšování (pod proces aktivit po incidentu).
Mimo hlavní proces řízení bezpečnostních událostí a incidentů musí být z hlediska efektivity zavedeny další dílčí podprocesy, které hlavní proces rozšiřují, doplňují a podporují. Mezi takovéto podprocesy je možné zařadit komunikační a eskalační procesy, pracovní postupy pro jednotlivé typy bezpečnostních událostí a incidentů, procesy pro zotavení se po incidentu (Disaster Recovery), procesy pro krizové řízení, procesy pro zajištění kontinuity (Business Continuity) a další.
Z hlediska koncepce je žádoucí celé procesní zajištění problematiky postavit na principech ITIL. [3] Tyto principy ve značné míře pomohou s praktickou aplikovatelností a navážou celý postup na dílčí procesy organizace. Použití principu ITIL nám zároveň pomůže rozdělit činnosti do jednotlivých managementů. Z hlediska řešené problematiky se jedná zejména o management změn, problémů a incidentů.
Do procesní roviny vstupují také externí požadavky, jako jsou ty z legislativních a normativních aktů, na něž musí procesy brát rovněž zřetel. Výše uvedené je třeba zohlednit především při komunikaci s autoritami, jako je Národní bezpečnostní úřad či Úřad pro ochranu osobních údajů, ale i řada dalších. Součástí procesní roviny se tak stávají nejen externí subjekty, ale i komunikační a eskalační schémata a rámce, které musejí být dalšími podprocesy procesu řízení bezpečnostních událostí a incidentů. Cílem je efektivní řízení bezpečnostních incidentů.
Důležitou a neopomenutelnou částí procesní roviny jsou externí subjekty, které na řízení participují či přímo odpovídají za některou technologickou část. Tyto subjekty musejí být co nejtěsněji zapojeny do řízení a jejich participace musí být podmíněna nejlépe smluvně a podložena dohodami typu SLA. Nejdůležitější částí procesní roviny je však stále část uživatelská, a to jak technická, tak i netechnická, která přímo vykonává dílčí procesy a podprocesy.
Uživatelská rovina
Z hlediska efektivního řízení bezpečnostních událostí a incidentů je klíčové zapojení personálu a jeho kontinuální vzdělávání. Edukaci personálu je nezbytné realizovat na obou úrovních, netechnické a technické, a k těmto úrovním přistupovat odlišně.
Netechnickou úroveň uživatelů je žádoucí edukovat zejména v oblasti rozpoznání anomálií a bezpečnostních událostí. Dále je nutné, aby netechnická úroveň znala podprocesní postupy alespoň v oblastech:
- bezpečného chování v prostředí informačních technologií,
- chování v případě podezření na bezpečnostní incident,
- postupu nahlášení (řešení) bezpečnostní události a incidentu,
- komunikace a komunikační kanály.
Edukace uživatelů netechnické úrovně je zejména preventivního a reaktivního charakteru – snažíme se předejít skutečnostem, které by mohly vést k narušení bezpečnosti. Pokud už k němu dojde, musíme zajistit včasné informování. Obecně je možné konstatovat, že čím vzdělanější jsou uživatelé působící na netechnické úrovni, tím méně hrozí z jejich strany pravděpodobnost vzniku bezpečnostního incidentu. Zde je žádoucí aplikovat v maximální míře možnosti technologických opatření, čímž významně snížíme riziko lidské chyby. Stejně tak je důležité zavést systém pravidelného vzdělávání. Za tímto účelem mohou posloužit e-learningové platformy, edukační kampaně, tréninky či simulace bezpečnostních událostí. Klíčové je však hlavně zainteresovat subjekty, jichž se to týká, do celého řízení.
Edukace osob na technické úrovni by měla probíhat primárně v analytických, investigativních a reakčních dovednostech, sekundárně na úrovni znalosti, obsluhy a administrace jednotlivých technologických řešení. Vzhledem k faktu, že právě na technické úrovni se řeší bezpečnostní události a incidenty, je žádoucí, aby se příslušné osoby nemusely věnovat jiné agendě, která by mohla tříštit jejich pozornost a zahlcovat je nutností osvojovat si další znalosti, které pro ně nejsou relevantní.
Technickou úroveň je vhodné strukturovat do dílčích rolí a úrovní. První úroveň by měla být co možná nejblíže netechnické úrovni. To znamená, že daný jedinec bude rozumět jazyku, kterým netechnická úroveň komunikuje, ale zároveň bude schopen vykonávat základní aktivity technické úrovně. Nejnižší role v rámci první úrovně je označována jako L1 operátor. Takový uživatel by měl pracovat zejména na základě předem definovaných scénářů a postupů, podle nichž bude vykonávat svoji činnost. Vzdělávání na této úrovni je spíše obecnějšího charakteru, zejména v oblasti obsluhy a používání technologických řešení. Uvedená role zajišťuje z hlediska procesu řízení bezpečnostních událostí a incidentů zejména krok zahrnující detekci a částečně krok analýzy. Další role v rámci první úrovně by měly být již více technické. Druhou roli první úrovně vykonávají L2 analytici, kteří realizují procesní část analýzy, investigace a část reakce. Jedná se o roli, která je přímo orientována na používání technologických řešení.
Druhá úroveň by měla být plně administrátorská. Tato role, označovaná jako L3 analytik administrátor, by se měla specializovat na vykonávání akcí a zásahů na úrovni jednotlivých řešení (reakce). V rámci doplňkových aktivit by měla být také schopna pomáhat vyhodnocovat jednotlivé detekce (investigace) v případech, kdy to nezvládne realizovat role L2. Součástí aktivit, které spadají pod gesci této role, je i zvyšování bezpečnosti organizace, a to aplikací těch opatření, která vyplynou např. z poučení z incidentu.
V případě edukace technické úrovně, jež se přímo věnuje řešení bezpečnostních událostí a incidentů, je nezbytné zajistit rovněž systém kontinuálního vzdělávání. Ten by měl být zacílený na konkrétní potřeby v rámci řešení bezpečnostních událostí a incidentů v dané infrastruktuře. V případě edukace osob v administrátorské roli je vhodné vzdělání směrovat na přesně určená technologická řešení, která je třeba obsluhovat, a na znalosti v oblasti, kterou dané technologické řešení pokrývá. Typicky se jedná o administrátorská školení a systémy vzdělávání jednotlivých výrobců, které je vhodné kombinovat s oblastí, do níž se toto řešení profiluje.
Uživatelskou rovinu efektivního řízení bezpečnostních událostí a incidentů lze shledat plně funkční až tehdy, disponuje-li organizace dostatečně poučeným personálem na všech úrovních. S tím úzce souvisí i potřeba zajistit kontinuální posilování potřebných znalostí, přičemž toto posilování je vyhodnocováno z hlediska funkčnosti a je neustále zlepšováno a aktualizováno. Zejména s ohledem na nově vznikající bezpečnostní hrozby.
Ani taková úroveň připravenosti však společnosti nezaručí, že nedojde k mimořádné situaci, s níž se nepočítalo. Např. vznikne- li bezpečnostní událost v době, kdy není technická úroveň k dispozici. V takových případech je nezbytné řešit otázku kontinuity činností řízení bezpečnostních událostí a incidentů. Tuto kontinuitu je třeba zajistit v nepřetržitém režimu nezávislém na době vzniku bezpečnostní události. Musí tedy existovat automatizovaný systém, který aktivuje jednotlivé role, jež v rámci procesu řízení bezpečnostních událostí a incidentů figurují. To mimo jiné předpokládá zajištění jejich nepřetržité dostupnosti a správné nastavení všech potřebných kanálů tak, aby jedna role v případě potřeby aktivovala druhou. Primárním cílem všech těchto opatření musí být vyřešit bezpečnostní incident s minimálním dopadem na aktiva organizace.
Závěr
Navržený přístup k problematice efektivního řízení bezpečnostních událostí a incidentů je prezentován třemi základními pilíři. Právě ty je nezbytné zohlednit, aby bylo vůbec možné dosáhnout jisté míry efektivity v rámci řízení. Tyto pilíře představují tři úzce provázané oblasti, které se vzájemně podmiňují.
Zároveň je žádoucí postavit celý systém řízení na postupech a konceptech ITIL, které proces značně zefektivní a podpoří jeho reálnou aplikovatelnost. Jejich použitím bude vytvořen přesah mezi bezpečnostními událostmi a incidenty a provozní rovinou informační oblasti. Tím dojde k jejímu hlubšímu provázání na fungování celé organizace včetně řady dalších činností, které v rámci ní probíhají.
V obecné rovině je možné konstatovat, že veškerá uvedená řešení nemusejí být nutně zajištěna interními zdroji organizace. Z hlediska efektivity je ve většině případů mnohem výhodnější delegovat jak dílčí role, tak i správu technologické roviny na třetí stranu, která se na tyto oblasti specializuje a disponuje zdroji pro jejich pokrytí. Efektivita a celkové řízení bezpečnostních událostí a incidentů jsou přímo provázány s ekonomickou stránkou. V případě, že celé řešení leží výhradně na bedrech samotné organizace, mohou finální náklady dosáhnout enormní výše.
I na základě této okolnosti by měla organizace zvážit, zda je pro ni ekonomicky schůdné realizovat řízení odděleně interními silami, nebo jeho část přenechat společnostem, které se na tyto činnosti zaměřují, případně použít sdílený model odpovědností.
Tato e-mailová adresa je chráněna před spamboty. Pro její zobrazení musíte mít povolen Javascript.
Použitá literatura:
[ 1 ] Zákon č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů (zákon o kybernetické bezpečnosti). In: Sbírka zákonů České republiky.
[ 2 ] Vyhláška č. 82/2018 Sb., o bezpečnostních opatřeních, kybernetických bezpečnostních incidentech, reaktivních opatřeních, náležitostech podání v oblasti kybernetické bezpečnosti a likvidaci dat (vyhláška o kybernetické bezpečnosti). In: Sbírka zákonů České republiky.
[ 3 ] Information Technology Infrastructure Library (ITIL).
