Prvním předpokladem pro úspěšné zvládání bezpečnostních incidentů je, aby v organizaci již fungoval zavedený systém jejich řízení (incident management), podporovaný aplikačním nástrojem. Incident management je většinou první proces, který je v organizaci z ITIL knihovny zaváděn. Pro jeho podporu existuje mnoho aplikací, jak placených, tak těch, které jsou k dispozici zdarma. Hlavním cílem procesu incident managementu je obnova služeb tak rychle, jak je to možné. Důvodem pro rychlou obnovu služeb je minimalizace nepříznivých dopadů na provoz IT služeb a s tím související snížení finančních dopadů a rizik z těchto dopadů plynoucích. Rychlá obnova služeb rovněž zvyšuje spokojenost jejich uživatelů.

Problémem většiny aplikací, které zajišťují podporu procesu incident management, je, že ukládají data do content databáze. V ní jsou sice informace klasifikovány, ale jsou ukládány pouze v textové podobě. Následné hledání informací v této databázi je možné pouze prostřednictvím fulltextového vyhledávání, případně podle definovaných kategorií incidentů. To způsobuje, že informace se jednak špatně hledají a zároveň jsou kladeny vysoké nároky na odbornost lidí, kteří tyto informace ve znalostní bázi vyhledávají. Rovněž tyto systémy neumějí efektivně využívat informace od externích subjektů, které jsou schopny tyto informace poskytovat. Mezi externí subjekty patří například výrobci jednotlivých technologií a aplikací, kteří jsou schopni informace poskytovat prostřednictvím data poolingu. Tito výrobci popisují již známé a řešené incidenty, včetně způsobu jejich řešení. Výstupy jsou výrobci schopni poskytovat ostatním uživatelům, bohužel ale převážně pouze v textové podobě.

Zvýšení efektivity zvládání incidentů můžeme realizovat prostřednictvím inteligentního řešení problémů, a to prostřednictvím analýzy nestrukturovaných dat. Základem této analýzy je umělá inteligence, která umožní zpracování textu s porozuměním přirozenému jazyku. Způsob efektivního zvládání incidentů prostřednictvím inteligentního problem managementu zobrazuje schéma (obr. 1).
 

Obr. 1: Průběh automatizované identifikace řešení incidentu

Identifikovaný incident prostřednictvím nástrojů bezpečnostního monitoringu či zadaný uživatelem je předán systému inteligentního problem managementu, který zahrnuje znalostní bázi řešených incidentů, příčin incidentů a úspěšných řešení. Následně probíhá zpracování požadavku na vyřešení incidentu porovnáním znalostí ze znalostní báze a externích zdrojů (data pooling). Pokud je ve znalostní bázi identifikován incident, který byl již dříve vyřešen, výstupem je nalezení nejlepšího možného řešení. Toto řešení se aplikuje a úspěšnost je odeslána zpět do znalostní báze. Úspěšná aplikace potvrdí platnost doporučeného řešení, neúspěch vyvolá proces manuální revize dostupných řešení v rámci pravidelné správy znalostní báze.

V rámci správy znalostní báze probíhá vnitřní zpracování na principu zpracování textu s porozuměním přirozenému jazyku (NLP) v jednotlivých krocích následovně: 

• Identifikace shody incidentů a odstranění duplicit (deduplikace). Deduplikace vychází z podobnosti, respektive vzdálenosti objektů a pomáhá nám odstranit duplicitní záznamy, a tím i zpřesnit výsledky hledání nejlepšího řešení incidentu.
• Identifikace incidentů se stejným kořenovým problémem (root cause) a shluková analýza neboli shlukování (clustering), jejímž úkolem je seskupení dat do skupin (shluků) tak, aby byly podobnější než data ze skupin různých.
• Automatizovaná analýza výběru nejlepšího řešení incidentu, které vychází z vytvořených vazeb mezi jednotlivými incidenty a známými řešeními incidentu, které jsou svázány přes kořenový problém. Systém nabídne nejlepší řešení incidentu. V některých případech nemusí být prvotní identifikace jednoznačná či může být předloženo více řešení, které mají stejnou váhu. V tomto případě je nutná verifikace výběru nejlepšího řešení incidentu.
• Aplikace nápravného opatření může být aplikována podle dalšího procesu, který je popsán v ITIL (change managementu). Incident po verifikaci úspěšnosti nápravného řešení může být uzavřen.
• Posledním krokem je automatizovaná úprava znalostní báze o úspěšnost implementovaného nápravného opatření, za účelem zpřesnění přesnosti budoucích identifikací nejlepšího řešení incidentu.

Proces automatizace zvládání incidentu lze zjednodušeně znázornit postupem znázorněným na obrázku 2. Systém nabízí řešení incidentu již na první úrovni podpory (většinou pracovník service desku), a není jej tak nutné předávat dále k řešení na druhou a třetí úroveň podpory.

Automatizace není vše

Výše uvedený přístup k zvládání bezpečnostních incidentů nám přinese podstatné zvýšení efektivity tohoto procesu a v neposlední řadě také finanční úspory. Prvním významným přínosem je, že pro identifikaci řešení není nutná vysoce kvalifikovaná pracovní síla, protože prostřednictvím automatizace je ve většině případů zvládne osoba s nižší kvalifikací a zkušenostmi na první úrovni podpory. Dalším přínosem je rychlost nalezení nejlepšího dostupného řešení, které proběhne řádově ve vteřinách místo toho, aby řešení hledal kvalifikovaný pracovník po mnohonásobně delší dobu. Rovněž uživatelé jsou spokojenější s rychlostí řešení jejich incidentů a jejich spokojenost se pozitivně odráží v celkové firemní kultuře.

Ovšem není to jediné možné využití tohoto systému. Rovněž může být využit pro automatizaci identifikace bezpečnostních incidentů a tím zajistit rychlejší reakce na ně. Systém může vyhodnocovat informace z dohledových nástrojů a na základě znalostní báze a dat z externích zdrojů může identifikovat bezpečnostní incidenty a zajistit včasnější reakci.

Obr. 2

Je na místě podotknout, že automatizace nemůže být nikdy samospásná. Ve své praxi auditora jsem se bohužel setkal i se špatně implementovanými procesy incident managementu, které práci neusnadňovaly, ale naopak přidělávaly. Uveďme jeden příklad za všechny.

Primární úroveň podpory a provoz service desku je zajišťován externím dodavatelem, jehož hodnocení není svázáno s počtem vyřešených incidentů na první úrovni podpory. Dodavatel pak pouze přeposílá incidenty na další řešitelské týmy místo toho, aby se snažil primárně incident vyřešit na první úrovni. Zde se ale nabízí velmi jednoduché řešení ve formě zavedení měření výkonnosti tohoto procesu, například měření počtu vyřešených incidentů na první úrovni podpory a následně hodnocení dodavatele podle toho, kolik procent incidentů vyřešil.

Tento příklad názorně ukazuje, že jakákoli automatizace či zavedené procesy nám nebudou prospěšné, pokud se nebudeme orientovat na cíl, kterého má být dosaženo. Z tohoto důvodu je na prvním místě třeba definovat cíl, kterého má být dosaženo, následně vybrat prostředek, pomocí něhož se k cíli dostaneme, a hlavně nesmí být opomenut způsob, jak budeme měřit dosažení námi vytknutého cíle.

Milan Goll
Autor pracuje jako senior konzultant ve společnosti Corpus Solutions.