Slovo triage sa v posledných týždňoch a mesiacoch neraz objavilo v médiach v súvislosti s koronavírusom. Spomínalo sa najmä na vrchole nákazy v Európe a označovalo akúsi prioritizáciu pacientov, ktorým sa mala poskytnúť zdravotnícka pomoc, keď boli kapacity naplnené. Tento pojem však v podobnom význame poznáme aj v kyberbezpečnosti, kedy ide o prioritizáciu riešenia upozornení (alertov), ktoré sú výsledkami rôznych detekčných metód.
Pod týmto názvom nachádzame aj ďalšiu potrebu v hierachii potrieb v kyberbezpečnosti. Po znalosti ochraňovaných aktív a širokej viditeľnosti do dejov, ktoré na nich prebiehajú sa cez detekciu neautorizovaných dejov dostávame k potrebe správneho vyhodnotenia výsledkov detekčných metód a ich prioritizácii.
Tému vyhodnocovania a prioritizácie som už čiastočne načal najmä v poslednom článku z tejto série, ktorý sa zaoberal overiteľnosťou a presnosťou detekčných metód. Overiteľnosť upozornení nám umožňuje vôbec poznať, ako presne daná detekčná metóda funguje a správne rozumieť upozorneniu na výstupe danej detekčnej metódy. Presnosť metódy je zase ovplyvňovaná pravdivosťou týchto upozornení, ktorá vychádza práve z ich vyhodnotenia a rozhodnutia, či ide o falošný poplach alebo dôsledok bezpečnostného incidentu.
Prioritizácia upozornení
Pre jednoduchosť môžeme uvažovať v štandardnom scenári – logy, NetFlow, endpointové dáta sa zbierajú do SIEMu, kde prebieha detekcia, ktorej výsledky (upozornenia, alerty) sú následne vyhodnocované SOC tímom. Upozornení bude štandardne veľa a je logicky nutné určiť, ktoré z nich sú najzávažnejšie a podľa toho ich začať vyhodnocovať. Ako jediné objektívne kritérium pre prioritizáciu vnímam dôležitosť dotknutých aktív, resp. predpokladaný dopad detekovaného bezpečnostného incidentu na činnosť danej organizácie. Z rôznych dôvodov to tak však v praxi často nebýva.
Skutočná priorita upozornenia je nutne subjektívna vlastnosť, ktorá aj keď je teoreticky definovaná hlavne z pohľadu dopadu na činnosť organizácie, je v praxi ovplyvňovaná ďalšími dynamickými a často subjektívnymi faktormi, ako počet upozornení vyžadujúcich prioritizáciu, iné upozornenia týkajúce sa rovnakého aktíva, očakávaná doba analýzy a riešenia jednotlivých upozornení a pod. Na základe subjektívnej (aj keď do istej miery formalizovateľnej) kombinácie rôznych faktorov, vznikne konečná priorita a upozornenie sa začne vyhodnocovať. Jednoducho povedané, analytik sa podľa aktuálneho súbehu relevantných faktorov „nejak“ rozhodne a vyberie si upozornenie, ktoré začne vyhodnocovať.
Vyhodnocovanie upozornení
Úlohou analytika pri vyhodnocovaní upozornenia je zodpovedať 6 otázok – Kto? Čo? Kedy? Kde? Prečo? Ako? (z anglického 5W1H – Who? What? When? Where? Why? How?) – o detekovanom bezpečnostnom incidente. Následne by mal do hry vstúpiť incident response tím, ktorý zodpovedá za reakciu na bezpečnostný incident. Spolupráca s IR tímom nemusí byť presne nalajnovaná, skôr by sa dalo povedať, že prebieha v cykloch – analytik niečo zistí, odovzdá to incident response tímu, ktorý si vyžiada ďalšie informácie a tak dookola, až kým nie je incident vyriešený. Prípadne v procese vyhodnocovania zistí, že ide o falošný poplach, čo však zase musí dobre zdôvodniť.
Zanedbajme na chvíľu technické možnosti a nástroje a tiež úroveň skúsenosti a znalostí u konkrétneho analytika. Čo je skutočným odzrkadlením tejto potreby vyhodnotenia upozornení je rýchlosť a správnosť – musíme na vyššie spomenuté otázky odpovedať správne a rýchlo. Ako to však dosiahnuť? Technické vybavenie a znalosti jednotlivých analytikov určite hrajú svoju rolu, ale na čom vyhodnocovanie stojí a padá, je procesná stránka veci.
V praxi sa na to používajú tzv. runbooky, alebo playbooky. Tie by mali v sebe obsahovať do istej miery formalizované postupy, ako vyhodnotiť jednotlivé upozornenia, vrátane toho, aké technické nástroje použiť, odkiaľ čerpať dodatočné dáta, koho kontaktovať a pod. Nespornou výhodou runbookov je, že sú deterministické – pri rovnakom upozornení nám (teoreticky) vždy vyjde rovnaký výsledok. Čo však správnosť a rýchlosť?
Determinizmus runbookov garantuje správne vyhodnotenie. Runbooky vytvárajú spravidla skúsenejší analytici a asi nedáva veľmi zmysel vytvoriť runbook podľa postupu, ktorý neprodukuje správne výsledky. Čiže ak je postup analyticky správny a sú použité správne nástroje, mal by vždy vyjsť správny výsledok.
Čo sa týka rýchlosti, runbooky, podľa úrovne detailu v nich, do istej miery odstraňujú nutnosť “myslieť”, čo znižuje šancu, že sa analytik pri vyhodnocovaní niekde “zamotá”. Ak je však runbook príliš špecifický, môže zas analytika spomaliť. Čo však najviac vplýva na rýchlosť vyhodnotenia je vhodná úroveň formálnosti, ktorá umožňuje automatizáciu celého vyhodnotenia a jeho výrazné zrýchlenie, napr. v systéme SOAR, o ktorom som písal v jednom z minulých článkov.
Upozorneniu sme tak dali v našom štandardnom scenári správnu prioritu a keďže máme kvalitné runbooky, dokázali sme ho aj rýchlo a správne vyhodnotiť. V časovej postupnosti by mala asi nasledovať reakcia na incident, ale tá je z pohľadu hierarchie potrieb čiastočne len implicitným predĺžením triage a čiastočne jej patria najvyššie stupienky hierarchie.
Dalo by sa povedať, že sme sa doteraz pozerali najmä na svoj piesoček – aké aktíva chránime, čo sa na nich deje a čo z toho by sa asi diať nemalo. V ďalších častiach sa však pozrieme vonku – na potreby súvisiace s cyber threat intelligence.
Dávid Kosť, Lead Security Analyst, AXENTA a.s
Peter Jankovský, CTO, AXENTA a.s.
Obrázok: Matt Swann
