Typický pracovní den analytika v bezpečnostním dohledovém centru (SOC) je zahájen záplavou alertů v systému SIEM. Až do oběda se pak věnuje zpracování tohoto velkého objemu upozornění. Po obědové pauze mu zbývá dokončit řešení dalšího značného množství alertů v SIEM. Může si však alespoň trochu oddechnout, protože ho od konce směny a nástupu dalšího týmu dělí už jen přibližně 4 až 5 hodin práce s těmito alerty. Poté se může soustředit na rovnováhu mezi pracovním a soukromým životem, aby byl připraven na další den plný velkého množství alertů v SIEM.
Ačkoliv je tento popis podán s nadsázkou, pro většinu SOC center představuje každodenní realitu. Obrovské množství dat, která do centra proudí, nevyhnutelně generuje velké množství upozornění, jež musí personál SOC zpracovat. Jako první se nabízí zdánlivě jednoduché řešení: optimalizovat počet a závažnost jednotlivých alertů. Tento přístup však nemusí přinést kýžený výsledek, a pokud není systém SIEM nastaven zcela chybně, pravděpodobně nedocílíme výraznějšího snížení. Navíc nelze předpokládat, že by počet kybernetických útoků klesal – spíše naopak. Tím se v podstatě dostáváme do slepé uličky.
Všechny alerty je nicméně nutné zpracovat. Pokud nám jejich řešení trvá příliš dlouho, dostáváme se k rovnici: vysoký počet alertů × dlouhá doba zpracování = problém (nebo příležitost, pokud jsme nenapravitelní optimisté). Počtem alertů jsme se již zabývali, zaměřme se tedy nyní na dobu jejich zpracování. Běžný postup si můžeme ukázat na příkladu alertu, který signalizuje spuštění podezřelého procesu na pracovní stanici.
Nejprve je nutné, aby si alertu někdo (operátor SOC) všiml, začal se jím zabývat a případně ho eskaloval na analytika. Následuje identifikace zasažených systémů, ověření indikátorů kompromitace (IOC) v databázích hrozeb a v historii již řešených alertů a ruční dohledání souvisejícího kontextu z dalších datových zdrojů. Celý tento proces a veškeré provedené kroky je navíc třeba pečlivě zdokumentovat a následně předat týmu pro řešení incidentů (incident response). Rázem se dostáváme na minimálně 30 minut, které jsou věnovány jedinému alertu, přičemž tento čas zahrnuje jak samotnou analytickou práci, tak čekání na výsledky vyhledávacích dotazů. A to nepočítáme rušivé vlivy a další faktory, které čas potřebný k analýze a vyřešení incidentu dále prodlužují.
Představme si ale situaci, kdy bychom mohli z alertu automaticky založit tiket. Podle typu alertu by se do tiketu automaticky načetly a doplnily údaje o dotčených systémech, ověřily by se IOC vůči zdrojům threat intelligence i našim historickým datům a na základě typu alertu by se automaticky dohledal a přidal potřebný kontext z dalších zdrojů (DNS záznamy, e-mailové logy, NetFlow, data z fyzické bezpečnosti).
Na základě analytického vyhodnocení by pak mohla navazovat automatizovaná reakce na incident. Ta by mohla zahrnovat například sběr obsahu operační paměti, seznamu spuštěných procesů a dalších forenzních dat z pracovní stanice. Případně by mohla spustit navazující akce, jako je statická a dynamická analýza podezřelého souboru, obnova systému z image (re-image) nebo jeho izolace od sítě a další postupy reakce na incidenty. Celý tento automatizovaný proces by zabral jen desítky sekund (čas potřebný na dokončení dotazů a analytických úkonů), což představuje masivní časovou úsporu. Všechny tyto činnosti by navíc byly zaznamenány v příslušném tiketu a mohli bychom je flexibilně skládat a připravovat do tzv. playbooků a šablon podle typu incidentu.
Možná se zdá, že se jedná o vizi daleké budoucnosti, ale opak je pravdou. Přesně tuto kombinaci funkcí totiž nabízejí řešení typu SOAR.
SOAR (Security Orchestration, Automation and Response) v sobě kombinuje tři klíčové oblasti:
· Orchestraci – integraci a koordinaci různých bezpečnostních i nebezpečnostních nástrojů a procesů.
· Automatizaci – automatické vykonávání činností nad propojenými nástroji.
· Reakci – provádění jednotlivých kroků procesu reakce na incidenty pomocí automatizované orchestrace.
Všechny tyto složky podporuje systém pro správu případů (case management), který nejen zaznamenává veškeré provedené aktivity a usnadňuje spolupráci při analýze a řešení incidentů, ale také měří a analyzuje nastavitelné metriky v celém procesu. Jako bonus pak slouží možnost automatické přípravy hlášení v souladu s legislativními požadavky, například GDPR nebo Zákona o kybernetické bezpečnosti.
Nezbytným předpokladem pro efektivní nasazení těchto systémů je existence dobře nastavených procesů a přítomnost kvalitních expertů v SOC, kteří dokážou připravit SOAR playbooky a šablony pro jednotlivé typy incidentů. V zásadě se však jedná o formalizaci a převedení již existujících postupů do pravidel a pracovních toků daného SOAR nástroje. I to samozřejmě vyžaduje určité náklady, ale v tomto případě platí, že výsledek za to stojí a investice do SOAR se mnohonásobně vyplatí.
Klíčovým přínosem je úspora času (a tedy i financí) při analýze a reakci na incident. Tato úspora nám umožňuje reagovat rychleji a efektivněji, a tím předcházet dalším finančním, reputačním nebo know-how ztrátám. Současně získáváme další výhody v podobě formalizovaných postupů, které minimalizují riziko opomenutí, zjednodušení práce analytiků, kteří mají díky playbookům jasně definovaný proces analýzy, a možnosti efektivnějšího měření klíčových ukazatelů výkonnosti (KPI). Vzhledem k současným trendům v kybernetické bezpečnosti, zejména rostoucímu počtu útoků a nedostatku odborníků, je tak velmi obtížné hledat argumenty, proč by se technologie SOAR neměla využívat naplno.
