Bežný deň analytika v SOCu začína veľkým množstvom alertov v SIEMe. Následne do obeda rieši veľké množstvo alertov v SIEMe. Po návrate z obeda mu už zostalo len vyriešiť veľké množstvo alertov v SIEMe. Ale môže si vydýchnuť, veľké množstvo alertov bude riešiť už asi len 4-5 hodín, kým nenastúpi ďalšia smena. Potom sa môže venovať work/life balance, aby sa mohol na nasledujúci deň opäť pustiť do veľkého množstva alertov v SIEMe.
Takýto obraz, aj keď zľahčene podaný, nie je veľmi uspokojivý. Presne takto však vyzerá denná realita väčšiny SOCov. Obrovské množstvo dát, ktoré do SOCu prúdia, generuje veľké množstvo alertov, ktoré musí SOC spracovať. Ponúka sa jednoduché riešenie – optimalizovať počet alertov, optimalizovať závažnosť jednotlivých alertov a podobne. Toto riešenie však nemusí priniesť očakávaný úspech a v prípade, že SIEM nie je úplne zle nastavený asi nedosiahneme nejaké veľké zníženie. Navyše, nedá sa očakávať, že počet útokov bude klesať, práve naopak, čiže sme sa vlastne nikde nedostali.
Všetky alerty však treba spracovať. Ak nám spracovanie trvá dlho, vychádza nám rovnica nejak takto: veľa alertov x dlhé spracovanie alertu = problém (alebo príležitosť ak sa na to pozeráme príliš optimisticky). Množstvo alertov sme už adresovali, pozrime sa teraz na dobu spracovania alertu. Bežný proces spracovania alertu môžeme ilustrovať na prípade alertu na spustenie podozrivého procesu na jednej z pracovných staníc.
Najprv si ten alert musí niekto (operátor SOCu) všimnúť a začať ho riešiť, následne potenciálne eskalovať na analytika, identifikovať dotknuté aktíva, skontrolovať IoC v threat intelligence a v už riešených alertoch, manuálne si zistiť kontext z ostatných dát, s ktorými by to mohlo súvisieť. Celý tento proces a všetky vykonané úkony musí navyše niekde spísať a následne to predať na incident response. Zrazu sme na minimálne 30 minútach venovaných riešeniu jedného alertu + samotná kognitívna analytická činnosť + doba čakania na dokončenie vyhľadávacích dotazov. Nehovoriac o rušivých vplyvoch a ďalších veciach, ktoré zvyšujú čas potrebný na analýzu a riešenie incidentu.
Čo ak by sme však dokázali založiť tiket z alertu automaticky, podľa typu alertu by sme automaticky dotiahli a do tiketu doplnili dáta o dotknutých aktívach, overili IoC proti TI feedom a naším historickým dátam a podľa typu alertu by sme si automaticky dohľadali a doplnili do tiketu potrebný kontext z ostatných zdrojov dát (DNS logy, e-mailové logy, netflow, fyzická bezpečnosť).
Na základe analytického vyhodnotenia by potom mohol nasledovať automatizovaný proces incident response, ktorý by mohol obsahovať napríklad zber operačnej pamäte, spustených procesov a ďalších forenzných dát z pracovnej stanice a prípadne automatickú naviazanú akciu – napríklad statickú a dynamickú analýzu podozrivého súboru z pracovnej stanice, reimage stroja, alebo jeho odrezanie zo siete či ďalšie možné spôsoby a postupy incident response. Celý tento automatický proces by trval desiatky sekúnd (+ samotný čas na dokončenie dotazov a analytickú činnosť), čo nám predstavuje obrovskú úsporu času. Navyše všetky tieto činnosti by boli zaznamenané v danom tikete a mohli by sme si ich ľubovoľne skladať a predpripraviť do playbookov a šablón poďla typu incidentu.
Možno si poviete, že ide o hudbu budúcnosti, ale nie je to tak. Práve tieto funkcionality dohromady ponúkajú SOAR riešenia. SOAR, teda Security Orchestration, Automation and Response v sebe spájajú tri veci:
– orchestráciu – integráciu a prepojenie rôznych bezpečnostných a nebezpečnostných nástrojov a úkonov
– automatizáciu – automatizované vykonávanie činností nad orchestrovanými nástrojmi
– reakciu – pomocou automatizovanej orchestrácie vykonávame jednotlivé súčasti incident response procesu
Tieto tri súčasti sú podporované systémom case managementu, ktorý nielen zaznamenáva všetky vykonané činnosti a umožňuje kolaboráciu pri analýze a incident response ale meria a analyzuje rôzne nastaviteľné metriky v tomto procese. Čerešničkou na torte je možnosť automatickej prípravy hlásení podľa legislatívnych požiadavok napríklad z GDPR alebo ZoKB.
Predpokladom pre efektívne využívanie týchto systémov je mať dobre nastavené procesy a kvalitných expertov v SOCu, ktorí dokážu pripraviť SOAR playbooky a šablóny pre jednotlivé typy incidentov, podľa ktorých bude SOAR fungovať. V podstate však ide o formalizáciu a prepísanie už existujúcich playbookov do rôznych pravidiel a workflowov daného SOAR nástroja. Aj to však samozrejme niečo stojí, ale v tomto prípade platí, že výsledok stojí za to a investícia do SOARu sa vráti mnohonásobne.
Hlavným benefitom je úspora času (= peňazí) pri analýze a reakcii na incident. Táto úspora nám umožňuje rýchlejšie a efektívnejšie reagovať na incident a týmto zabrániť ďalším finančným, know-how alebo reputačným stratám. Popritom získavame zabalené benefity v podobe formalizovaných procesov, ktoré nám nedovolia na niečo zabudnúť, zjednodušenia práce analytikov, ktorí vďaka playbookom majú jasne popísaný proces analýzy daného typu incidentu, možnosti efektívnejšieho merania KPI, a mnoho ďalších. Pri súčasných trendoch v kyberbezpečnosti (najmä rastúci počet útokov a nedostatok odborníkov) je tak veľmi ťažké hľadať argumenty, prečo SOAR nevyužiť na maximum.
Dávid Kosť, Lead Security Analyst, Axenta a.s.
Obrázek: rawpixel.com / Freepik
