Od BAS k AEV a CTEM: co to doopravdy dělá a proč to bez přípravy nebude fungovat

V bezpečnosti se nyní hodně mluví o CTEM, AEV a BAS a nejeden CISO se tak nechal zlákat líbivou prezentací firem, které tento přístup k řízení zranitelností propagují.

Aby ne, když to marketing výrobců těchto SW servíruje jako „Nasadíš náš SW, a on ti nejenže řekne, jakou zranitelností začít, ale i jak velké představuje riziko v korunách“. No, nekup to.

Jenže realita je mnohem prozaičtější, aby to totiž takhle mohlo vůbec fungovat, tak je třeba udělat spoustu práce. Nástroje musí být hlavně nakrmené těmi správnými daty, jinak to bude průšvih. Dostanete hezký dashboard (některé jsou fakt vizuálně velice pěkné) ale naprosto nevhodný podklad pro kvalifikované rozhodnutí ohledně zranitelností.

Ano, dodavatelé velice rádi ukazují tlačítka „run test“ a dashboardy s čísly. Co ale málokoho zajímá, je práce před spuštěním, kdy je nutné zmapovat aktiva a závislost mezi nimi a nastavit integrace EDR/SIEM, definovat playbooky a runbooky, určit scope, stanovit hodnoty dopadů apod. Pokud tyto kroky přeskočíte, dostanete zcela nesmyslná čísla (garbage in, garbage out).

CTEM, AEV, BAS, a kdo se v tom má vyznat

Nejprve se vypořádáme s těmi buzzwordy, a uvedeme si co znamenají ty zkratky CTEM, AEV a BAS.

• CTEM (Continuous Threat Exposure Management) je procesní rámec od Gartnerů, který říká, jak má organizace kontinuálně řídit svou expozici.
• BAS (Breach and Attack Simulation) je automatizovaný engine, který spouští skripty (runbooky) a seskupuje je do scénářů (playbooky). Cílem je otestovat, zda vaše EDR/SIEM/firewall atd. detekují a korektně reagují. Některé BAS nástroje umí jen spouštět skripty, jiné už mají i orchestraci (plánování, agent management, reporty).
• AEV (Adversarial Exposure Validation) kromě toho, že obsahuje (či integruje) BAS, tak přidává ještě kontext. Spojuje výsledky simulací s topologií, zranitelnostmi, IAM daty a byznys hodnotami aktiv a dokáže navíc modelovat scénáře útoku (pokud mu dodáte data) a kvantifikovat riziko.

Orchestrace bez legrace, aneb Kdo rozhoduje, co a kde se spustí

Nejde o to, jestli nástroj umí spustit runbook, to umí většina. Otázka zní zda nástroj dokáže spojit výsledky testu s kontextem vaší organizace. Pokud nepotřebujete kvantifikaci rizik, tak dobře nastavený BAS s orchestrací často postačí. Pokud chcete prioritizovat řešení zranitelností podle obchodního dopadu, sáhnete po AEV.  Prakticky to celé funguje takto:

• Orchestrátor (AEV/BAS platforma) spouští runbooky a playbooky podle plánu.
• Platform admin / red team nastaví scope, safe-mode, parametry (target IP/URL, test ID, benign vs destructive).
• Business vlastník  schvaluje cíle a dopadové limity.
• SOC sleduje běh testu a má kill-switch pro okamžité zastavení při nečekaném chování.

AEV může automatizovat, ale neměla by automaticky rozhodovat o destruktivních testech v produkci bez lidského schválení.

Jak AEV pozná, které systémy jsou vystaveny do internetu

AEV obvykle zpracovává několik zdrojů, aby identifikovala expozici:

1. Discovery — vulnerability scanner, cloud inventory, firewall rules, WAF, load balancers, public DNS (co resolves to public IP) a Shodan-type skeny. Tyto zdroje indikují, které služby jsou dostupné z internetu.
2. Topologie a závislosti — mapování sítí, aplikací a datových toků z CMDB a network mappingu, aby se vědělo, jak se z internet-facing assetu dostat dovnitř.
3. Identity a oprávnění — IAM/AD export: kdo má jaká práva, existují-li trust-vztahy, servisní účty atd.
4. Threat intel — pokud proti konkrétním verzím existuje exploit, priorita expozice roste.
5. Telemetrie — EDR/SIEM data, pokusy o přihlášení, bruteforce atd., která potvrzují aktivitu proti vystaveným službám.

Kombinací těchto signálů AEV definuje, že „host X je internet-exposed“ a zároveň modeluje, zda z něj vede průchozí cesta k citlivému aktivu. Ale opět, AEV to sice může identifikovat automaticky, ale nelze se na to bezpodmínečně spolehnout. Pokud CMDB neodpovídá realitě nebo jsou logy neúplné, AEV modeluje spíš ideální svět než ten váš.

Kvantifikace rizik

O kvantifikaci se dnes mluví v souvislosti a AEV nejvíc a paradoxně právě to je ta část, která je nejméně automatická. Při kvantifikaci rizik potřebujeme obvykle znát pravděpodobnost realizace daného scénáře, zranitelnost a dopad. AEV dokáže dopočítat, zda útok projde, ale nedokáže samo o sobě spočítat, kolik by vás narušení bezpečnosti a business procesů mohlo stát. Ne, tak inteligentní opravdu není. Pokud proto v reportu uvidíte „Expected Loss: X Kč“, pamatujte, že pokud to někdo ručně nezadal (zpravidla business vlastník), např. na základě business impact analýzy, tak uvedená čísla budou naprosto nesmyslná.

Pak je zde ještě  otázka, odkud se vezme pravděpodobnost, že někdo zaútočí, a že to projde. Zde musíme rozlišit frekvenci útoků (Threat Event Frequency, zkr. TEF) odhadujeme z threat-intel, historie (SIEM), honeypotů, odvětvových benchmarků. Dále musíme spočítat zranitelnost (vulnerability, zkr. VULN), a to z technických vstupů: existence CVE + exploit availability, patch status, segmentace, detekční pokrytí, privilegia. A nakonec celkovou roční frekvenci ztrát (Loss Event Frequency, zkr. LEF) jako součin TEF a VULN. AEV pomáhá u druhého členu, první musíte odhadnout externími daty a expertními vstupy.

Aby kvantifikace měla smysl, tak:

• Business value aktiva (přímé náklady, revenue/hour, regulace).
• Historie incidentů a telemetrie (SIEM/EDR logy).
• Threat-intel signály (existence a dostupnost exploitů, běžící aktivní kampaně).
• Inventář a závislosti (CMDB, mapování datových toků).
• Detekční pokrytí (EDR pokrytí, SIEM pravidla, false negative rate).
• Ekonomické parametry (náklady na forenziku, MTTR, reputační multiplikátory).

Bez těchto vstupů dostanete přesné výpočty z nepřesných výchozích údajů, a to je nejhorší kombinace: falešná jistota + numerická přesnost.

Závěr

AEV je to mocný nástroj pro orchestraci testů a kvantifikaci rizik, ovšem záleží na datech, která do ní vložíte.  Není to kouzelný nástroj, která sám provede veškeré testy a zkvantifikuje rizika. Pokud chcete jen ověřit detekce, začněte s BAS. Pokud chcete prioritizovat podle dopadu a mít jednotný pohled na expozici, zvažte AEV a postupné budování CTEM procesu.

Pokud se vám líbí naše články, tak zvažte podporu naši práce – Naskenujte QR kód a přispějte libovolnou částkou.

Děkujeme!

Štítky: vulnerability management