Běžný den analytika v SOCu začíná velkým množstvím alertů v SIEM. Následně do oběda řeší velké množství alertů v SIEM. Po návratu z oběda mu už zůstalo jen vyřešit velké množství alertů v SIEM. Ale může si vydechnout, velké množství alertů bude řešit už asi jen 4-5 hodin, dokud nenastoupí další směna. Pak se může věnovat work / life balance, aby se mohl na následující den opět pustit do velkého množství alertů v SIEM.

Takovýto obraz, i když odlehčeně podaný, není velmi uspokojivý. Přesně takto však vypadá denní realita většiny SOCů. Obrovské množství dat, které do SOCu proudí, generuje velké množství ALERTů, které musí SOC zpracovat. Nabízí se jednoduché řešení – optimalizovat počet ALERTů, optimalizovat závažnost jednotlivých ALERTů a podobně. Toto řešení však nemusí přinést očekávaný úspěch a v případě, že SIEM není úplně špatně nastaven asi nedosáhneme nějakého velkého snížení. Navíc nelze očekávat, že počet útoků bude klesat, právě naopak, čili jsme se vlastně nikam nedostali.

Všechny ALERTy je však třeba zpracovat. Pokud nám zpracování trvá dlouho, vychází nám rovnice nějak takto: hodně ALERTů x dlouhé zpracování ALERTu = problém (nebo příležitost pokud se na to díváme příliš optimisticky). Množství ALERTů jsme už adresovali, podívejme se nyní na dobu zpracování ALERTu. Běžný proces zpracování ALERTu můžeme ilustrovat na případě ALERTu ke spuštění podezřelého procesu na jedné z pracovních stanic.

Nejprve si toho ALERTu musí někdo (operátor SOCu) všimnout a začít ho řešit, následně potenciálně eskalovat na analytika, identifikovat dotčené aktiva, zkontrolovat IOC v threat intelligence a v již řešených ALERTech, manuálně si zjistit kontext z ostatních dat, se kterými by to mohlo souviset. Celý tento proces a všechny provedené úkony musí navíc někde sepsat a následně to předat na incident response. Najednou jsme na minimálně 30 minutách věnovaných řešení jednoho ALERTu – samotná kognitivní analytická činnost a doba čekání na dokončení vyhledávacích dotazů. Nemluvě o rušivých vlivech a dalších věcech, které zvyšují čas potřebný k analýze a řešení incidentu.

Co když bychom však dokázali založit tiket z ALERTu automaticky, podle typu ALERTu bychom automaticky dotáhli a do tiketu doplnili data o dotčených aktivech, ověřili IOC proti TI feedom a našim historickým datům a podle typu ALERTu bychom si automaticky dohledali a doplnili do tiketu potřebný kontext z ostatních zdrojů dat (DNS logy, e-mailové logy, NetFlow, fyzická bezpečnost).

Na základě analytického vyhodnocení by potom mohl následovat automatizovaný proces incident response, který by mohl obsahovat například sběr operační paměti, spuštěných procesů a dalších forenzních dat z pracovní stanice a případně automatickou navázanou akci – například statickou a dynamickou analýzu podezřelého souboru z pracovní stanice, reImage stroje nebo jeho odříznutí ze sítě či další možné způsoby a postupy incident response. Celý tento automatický proces by trval desítky sekund (samotný čas na dokončení dotazů a analytickou činnost), což pro nás představuje obrovskou úsporu času. Navíc všechny tyto činnosti by byly zaznamenány v daném tiketu a mohli bychom si je libovolně skládat a předpřipravit do playbooků a šablon podle typu incidentu.

Možná si řeknete, že jde o hudbu budoucnosti, ale není to tak. Právě tyto funkcionality dohromady nabízejí SOAR řešení.

SOAR, tedy Security Orchestration, Automation and Response v sobě spojují tři věci:

• orchestraci – integraci a propojení různých bezpečnostních a ne-bezpečnostních nástrojů a úkonů
• automatizaci – automatizované provádění činností nad orchestrovanými nástroji
• reakci – pomocí automatizované orchestrace provádíme jednotlivé součásti incident response procesu

Tyto tři součásti jsou podporovány systémem case managementu, který nejen zaznamenává všechny provedené činnosti a umožňuje kolaboraci při analýze a incident response ale měří a analyzuje různé nastavitelné metriky v tomto procesu. Třešničkou na dortu je možnost automatické přípravy hlášení podle legislativních požadavků například z GDPR nebo ZoKB.

Předpokladem pro efektivní využívání těchto systémů je mít dobře nastavené procesy a kvalitní experty v SOCu, kteří dokáží připravit SOAR playbooky a šablony pro jednotlivé typy incidentů, podle kterých bude SOAR fungovat. V podstatě však jde o formalizaci a přepsání již existujících playbooků do různých pravidel a workflow daného SOAR nástroje. I to však samozřejmě něco stojí, ale v tomto případě platí, že výsledek stojí za to a investice do SOAR se vrátí mnohonásobně.

Hlavním benefitem je úspora času (= peněz) při analýze a reakci na incident. Tato úspora nám umožňuje rychleji a efektivněji reagovat na incident a tímto zabránit dalším finančním, know-how nebo reputačním ztrátám. Přitom získáváme zabalené benefity v podobě formalizovaných procesů, které nám nedovolí na něco zapomenout, zjednodušení práce analytiků, kteří díky playbooku mají jasně popsán proces analýzy daného typu incidentu, možnosti efektivnějšího měření KPI, a mnoho dalšího. Při současných trendech v kyberbezpečnosti (zejména rostoucí počet útoků a nedostatek odborníků) je tak velmi těžké hledat argumenty, proč SOAR nevyužít na maximum.

Dávid Kosť, Lead Security Analyst, Axenta a.s

Obrázek: rawpixel.com / Freepik