Ti jsou ovšem z povahy své funkce zaměřeni na provozní potřeby organizace, ne však na bezpečnost a ochranu dat. To vede k nesystematičnosti činností a procesů a jejich následné nedostatečnosti.
V kybernetické bezpečnosti jsou tyto výzvy řešeny prostřednictvím zavedení služeb Security Operations Center (dále jen „SOC“) a Incident Response Team (dále jen „IRT“). Jejich podstatu a základní atributy vysvětlíme v následujícím textu. Nejprve je ale třeba zaměřit pozornost na objekty celé této oblasti řízení bezpečnosti informací, tedy na kybernetické bezpečnostní události a kybernetické bezpečnostní incidenty.
§7 zákona č. 181/2014 Sb., o kybernetické bezpečnosti uvádí tyto definice kybernetické bezpečnostní události (dále jen „událost“) a kybernetického bezpečnostního incidentu (dále jen „incident“):
„Kybernetickou bezpečnostní událostí je událost, která může způsobit narušení bezpečnosti informací, tedy důvěrnosti, dostupnosti nebo integrity informací v informačních systémech nebo narušení bezpečnosti služeb.“
„Kybernetickým bezpečnostním incidentem (dále jen „incident“) je narušení bezpečnosti informací, tedy důvěrnosti, dostupnosti nebo integrity informací v informačních systémech, nebo narušení bezpečnosti služeb v důsledku KBU.“
Událostí je tedy vše, co může potenciálně znamenat bezpečnostní incident nebo k němu může vést. V případě události však nebylo v danou chvíli zaznamenáno, že by byla narušena důvěrnost, dostupnost nebo integrita informací (např. ztráta vstupní karty nebo zachycený malware z vnější sítě; patří sem i každá jiná provozní nebo technická podezřelá událost nebo jev, který by potenciálně mohl značit kompromitaci aktiv nebo jiný bezpečnostní problém).
Oproti tomu, o bezpečnostním incidentu hovoříme až ve chvíli, kdy už byla bezpečnost porušena, tzn. došlo k porušení důvěrnosti, integrity nebo dostupnosti informací. Za incident bychom tedy měli určitě považovat např. neoprávněné použití ukradené vstupní karty, úspěšný kybernetický útok prostřednictvím malwaru, únik neveřejných informací nebo nedostupnost funkce či služby informačního systému (delší, než je stanovená maximální tolerovaná doba výpadku).
Zákon o kybernetické bezpečnosti vztahuje definici bezpečnostních událostí a incidentů k informacím v informačních systémech. Dobrá praxe však radí, že je třeba pamatovat i na listinné dokumenty a další média, pokud jsou v organizaci používána a nesou chráněné informace.
Hranice mezi bezpečnostní událostí a incidentem bývají v praxi často velmi tenké. Organizace by měla jasně vymezit, ve kterých případech:
Právě rozdílný postoj k posuzování bezpečnostních událostí a incidentů bývá důvodem, proč organizace se srovnatelným rizikovým prostředím vykazují různou míru evidovaných incidentů.
Některé organizace při posuzování bezpečnostních událostí a incidentů zákonné definice aplikují striktně. Jiné organizace za bezpečnostní incident považují i vědomé hrubé porušení bezpečnostních politik uživateli (i bez toho, aniž by reálně k porušení bezpečnosti došlo). Některé organizace považují jakýkoli výpadek nebo nedostupnost služeb a informací za incident. Jiné tak posuzují pouze výpadky, které překročí dobu stanovenou ve smlouvě o dodávce služeb nebo na základě analýzy dopadů.
Některé bezpečnostní incidenty jsou rozpoznatelné snadno. Typickým příkladem je zašifrování a znepřístupnění dat ransomwarem. Existuje však celá řada případů, kdy je třeba bezpečnostní událost hlouběji prozkoumat. Jedině tak spolehlivě určíme, zda jde opravdu o incident. Taková situace může nastat např. v případě, kdy dojde k výpadku serveru. Analýza určí, že jde o nedostupnost vyvolanou DoS útokem, tedy o bezpečnostní incident.
Největší hrozbu z hlediska možného dopadu pak představují útoky typu „advanced persistent threat“ (dále jen „APT“). Útočníci vyvíjí aktivity po delší časové období za využití nejrůznějších technik a typů malwaru a přizpůsobují se obranným snahám oběti. Takové útoky mohou vyústit v závažný incident. Oběť ho rozezná zpravidla až ve chvíli, kdy na ni dolehnou jeho tíživé dopady.
Možnost včasné detekce útoků i typu APT se nejvíce odvíjí od schopnosti oběti kvalitně detekovat bezpečnostní události. Tzn. analyzovat jejich vektory a kořenové příčiny a odhalit je jako indikátory těchto útoků. Zde hraje zásadní úlohu Security Operations Center (dále jen „SOC“).
Aktivity SOC se zaměřují nejen na analýzu detekovaných událostí, ale také na proaktivní vyhledávání možných bezpečnostních hrozeb a zranitelností informačních systémů. Nové hrozby a zranitelnosti pomáhá objevit sledování dostupných evidencí řešených kybernetických incidentů nebo provozování tzv. Cyber Threat Intelligence. Ta se zakládá na shromažďování informací o rizicích z dark webu a deep webu. SOC na základě analýzy širokého spektra dat a informací určí, že se jedná o bezpečnostní incident a co nejrychleji jej eskaluje na určené osoby.
SOC může být zřízen v organizaci a jeho provoz je pak zajištěn stávajícími nebo nově přijatými zaměstnanci. Část práce SOC pak zpravidla zastávají pracovníci stávajícího oddělení HelpDesk. Kromě doposud evidovaných událostí provozního charakteru HelpDesk nově přijímá a eviduje také události bezpečnostní:
Úskalím budování vnitřního SOC bývá zejména nedostatek kvalifikovaných lidských zdrojů a jejich neochota držet pohotovosti k zajištění zvoleného režimu služby (tuto neochotu lze do jisté míry vyvážit poskytnutím příplatků za držené pohotovosti). Výše mzdových nákladů a nákladů na pořízení a provoz technologií SOC pak často představují důvod, proč se stále více organizací obrací na externí poskytovatele služby. Další možností je pak kombinace interního a externího SOC, kdy externí tým může doplňovat určité, interně nepokryté znalosti, technologie či časovou dostupnost SOC organizace.
K zajištění kybernetické bezpečnosti je potřebné zvážit vhodný režim pokrytí služby v bezpečnostním a obchodním kontextu konkrétní organizace. Režimy SOC se liší:
Z hlediska bezpečnosti informací lze zajistit největší účinnost služeb SOC prostřednictvím aktivního režimu 24/7. Tento režim ovšem vyžaduje zvýšené náklady, a to jak v případě interního SOC (náklady na mzdy), tak i při využití externě poskytovaných služeb.
Organizace hledající úsporné řešení zavádí režim 8/5. Tento model postihuje klasickou pracovní dobu. Pokud organizace netrpí nedostatkem technických pracovníků, nabízí se jako vhodné v rámci režimu 8/5 interní řešení SOC. I zde je nicméně možné zapojit třetí stranu, a to zejména pro využití specialistů na bezpečnost používaných technologií.
Další atributy SOC je třeba stanovit a upravit v interní bezpečnostní dokumentaci, případně ve smlouvě s dodavatelem služby. Ty nejdůležitější jsou:
1) Katalog činností SOC: ať už organizace staví interní nebo externí SOC, doporučujeme stanovit okruh činností a úkolů, které tomuto týmu svěřit. SOC slouží zejména k identifikaci, analýze a hlášení bezpečnostních událostí a zjištěných incidentů, ale může nabídnout další cenné služby, jako jsou:
2) Sledované zdroje: znamenají takové zdroje, na základě jejichž analýzy bude SOC identifikovat bezpečnostní události. Obyčejně se jedná o:
3) Způsob vyhodnocování a provádění analýzy událostí: určení vhodných technologií a postupů pro analýzu. Nejvíce se odvíjí od sledovaných zdrojů.
4) Vnitřní organizace: úrovně a počet analytiků, jejich znalosti i kompetence a systém eskalace událostí mezi úrovněmi.
5) Klasifikace incidentů: jak se budou zjištěné bezpečnostní události klasifikovat; zpravidla se používá třístupňový model.
6) Eskalace zjištěných bezpečnostních incidentů a reporty o událostech: organizace by měla určit frekvenci, při níž bude SOC určené kontaktní osobě pravidelně podávat zprávu o zjištěných událostech. Dále je třeba určit, komu a v rámci jakých reakčních dob v návaznosti na jednotlivé klasifikační stupně bezpečnostního incidentu, případně též v návaznosti na chráněné informační systémy a výsledky analýzy dopadů (též „business impact analysis“), bude SOC hlásit identifikované incidenty.
Zvyšte kybernetickou bezpečnost pomocí služeb SOC
Jakmile SOC zjistí bezpečnostní incident, měl by být aktivován Incident Response Team (dále jen „IRT“), který se postará o zvládnutí incidentu. To zahrnuje hlavně zastavení šíření a vymýcení následků incidentu, uvedení dotčených důležitých informačních systémů a procesů do chodu, vyšetření všech detailů ohledně incidentu a následné navržení opatření ke zvýšení obranyschopnosti proti obdobným incidentům v budoucnu.
Týmy pro reakci na kybernetické incidenty se kromě IRT označují běžně také zkratkami CSIRT (Computer Security Incident Response Team) nebo CERT (Computer Emergency Response Team). Termín CERT je od roku 1997 registrovanou známkou Carnegie Mellon University. Ačkoli jej mnoho společností používá obecně, o používání registrované známky mohou organizace požádat.
Pravděpodobně jste zaznamenali zkratky CERT a SIRT v souvislosti s týmy řízenými určenými orgány veřejné správy. Ty evidují a řeší kybernetické bezpečnostní incidenty. V České republice fungují na této úrovni dva týmy, jejichž zřízení je ustanoveno v zákoně o kybernetické bezpečnosti:
Týmy CERT a CSIRT se ovšem zřizují pro určitá odvětví. Provozují je poskytovatelé služeb informační společnosti a stále více dalších povinných osob podle zákona o kybernetické bezpečnosti. Sem patří banky či univerzity. Pro reakci na bezpečnostní incidenty využívá služeb komerčních poskytovatelů řada dalších povinných osob podle zákona o kybernetické bezpečnosti, ale i jiných organizací, které si uvědomují potřebu chránit své informace.
Týmy typu CERT a CSIRT se většinou organizují v některé z mezinárodních zájmových organizací. Mezi ty nejvýznamnější z nich se řadí:
Týmy si v rámci organizace vyměňují informace ohledně řešených incidentů, hrozeb a zranitelností. Tyto platformy také průběžně rozvíjí své standardy, pravidla a metodiky. Ty pomáhají svým členům při zakládání, rozvoji nebo zlepšování svých týmů a pro okolí znamenají jistou informaci o úrovni poskytovaných služeb.
Tým pro odezvu na bezpečnostní incidenty může – podobně jako u SOC – organizace utvářet sama, nebo tyto služby zajistit prostřednictvím dodavatele. Opět se zde nabízí i varianta kombinace: v případě zjištění bezpečnostního incidentu může být svolán primárně interní IRT. Pokud však nastane mimořádně technicky složitý problém, a interní IRT na jeho řešení nestačí nebo nedisponuje specialisty na konkrétní technologii, využije organizace smluvního externího dodavatele.
Tým v konkrétním složení se zpravidla zformuje až ve chvíli, kdy jde do akce. Otázkou však je, do jaké doby od jeho vyrozumění je tato akce požadována a v kterou denní dobu. I zde platí, že bezpečnostním ideálem je pokrytí služby 24/7. V případě středně nebo vysoce závažného incidentu je pochopitelně ideální co nejmenší doba reakce.
V případě interních zaměstnanců však zpravidla naráží požadavek takovéto pohotovosti na odpor. Pro tyto případy se nabízí řešení rozdělené pohotovosti mezi interní a externí IRT: během pracovní doby jsou určení interní zaměstnanci povinní reagovat a svolat IRT a mimo pracovní dobu je dostupnost služeb zajištěna externím týmem pro odezvu na bezpečnostní incidenty.
IRT by měl vykonávat činnosti v rámci reakce na incidenty na základě mandátu, který mu organizace svěří. Ta musí dále určit, které činnosti musí a může IRT vykonávat, základní pravidla eskalace incidentu a vyrozumění osob v organizaci nebo např. národních týmů.
Další atributy IRT je třeba stanovit a upravit v interní bezpečnostní dokumentaci, případně ve smlouvě s dodavatelem služby. Ty nejdůležitější jsou:
1) Způsob aktivace IRT: kdo tým aktivuje (zaměstnanec organizace v konkrétní bezpečnostní roli, manažer IRT po vyrozumění interním, nebo externím SOC), jakým prostředkem, (zda telefonicky, e-mailem, SMS).
2) Katalog činností IRT: odvíjí se od úkolů svěřeným IRT; ty základní jsou:
IRT se může v základní sestavě scházet také pravidelně a může být pověřeno dalšími úkoly, které spadají obyčejně do působnosti SOC. Patří sem:
3) Stanovení složení IRT: určení stálých a nestálých členů týmu. Podle typu IRT a podle konkrétního incidentu by měli být uvažováni alespoň: manažer IRT, právník, specialista pro komunikaci s veřejností a specialisté na jednotlivé typy technologií.
4) Klasifikace incidentů a stanovení doby reakce: obdobně, jako je tomu u SOC, ideálně ve vzájemné shodě.
5) Identifikace interních a externích zainteresovaných stran, na které je třeba vést kontakty a v případě potřeby je vyrozumět.
6) Oprávnění pro členy IRT při vyšetřování KBI: při vyšetřování incidentů může být potřebné umožnit IRT prohledávání osobních věcí osob v lokalitě organizace, zabavení osobních věcí osobám, požadování podání svědectví, monitorování komunikací, přístup ke kamerovým záznamům, přístup k auditním logům apod.
Služby SOC a IRT by měla v některé míře a formě využívat každá organizace, která zajišťuje služby informační společnosti. Spadají sem také organizace, které spravují nebo provozují informační systémy obsahující informace důležité pro její obchodní zájmy nebo pro zájmy veřejnosti, což dnes zahrnuje prakticky všechny organizace. U malých organizací stačí dva nebo tři šikovní zaměstnanci, kteří jsou za svou práci odpovídajícím způsobem ohodnoceni a jsou podporováni vedením a vybaveni odpovídajícími pravomocemi – pokud je to i váš případ, nemusíte přímo zřizovat nebo najímat veliké expertní týmy.
V každém případě však doporučujeme důsledně ohlídat, aby se řešení pro řízení bezpečnostních událostí a incidentů vyznačovalo systematičností. Také je důležité, aby pokrývalo všechny cíle řízení událostí a incidentů, tedy aby zajistilo prevenci zahrnující detekci a analýzu co možná nejširšího spektra bezpečnostních událostí. Spadají sem i proaktivní služby SOC a eliminace zranitelností zneužitých dříve.
Důležitá je příprava zahrnující nastavení procesů, pravomocí, působností a postupů, vypracování plánů reakce, materiální zajištění, smlouvy se specialisty na technologie a další. Nezbytná je odezva, díky které jsou negativní dopady incidentu minimalizovány, a obnova, která zajistí rychlý návrat k běžnému chodu.
Systematický by měl postup k řešení incidentu být také ve vztahu k systému řízení informací organizace jako celku. Proto vedení nebo vhodný orgán v organizaci (např. výbor pro řízení kybernetické bezpečnosti) každé řešení incidentu zpětně vyhodnocuje, projednává možná ponaučení se z něho a přijímá opatření ke zlepšení celého systému řízení bezpečnosti informací.
