AI útoky používají známé techniky, ale tradiční obrana jim nestačí

Marketing bezpečnostních firem si oblíbil poměrně věrohodný příběh: útoky využívající umělou inteligenci jsou něco zcela nového, a proto potřebujeme nový typ obrany. Zní to logicky, ale z velké části to není pravda.

Kybernetické útoky využívají software už desítky let. Červi, botnety, exploit kity, nástroje pro credential stuffing nebo automatizované skenery fungovaly strojovou rychlostí dávno předtím, než se do každého reportu o kybernetických hrozbách začalo přidávat slovo „AI“. Útočníci už dlouhou dobu umí sledovat, co funguje, upravit svůj postup a zkusit to znovu. Na tom není nic nového.

Co se ale změnilo, je rychlost a škála. Díky AI propojují útočníci lidskou invenci se strojovou rychlostí. Útoky se tak umí průběžně přizpůsobovat, běžet paralelně ve velkém množství a fungovat prakticky nepřetržitě. Navíc za stále nižší náklady.

Automatizace nikdy nebyla to nejzajímavější

Tradiční automatizace útoků se řídí logikou, která je většinou pevně daná. Skener kontroluje seznam známých zranitelností. Botnet vykonává předem připravenou sekvenci kroků. Nástroj pro credential stuffing postupně zkouší položky ze seznamu. Větvení je předem naprogramované. Jakmile se cílové prostředí dostatečně změní, nástroj přestane fungovat a je třeba jej přepsat.

Útočník s AI funguje jinak. Systému stačí zadat cíl a ten pak prostředí sám prozkoumá, zvolí akci, vyhodnotí výsledek a podle něj upraví další postup. Tento cyklus může opakovat průběžně, místo aby reagoval jen v předem naprogramovaných krocích. Tím automatizuje samotný rozhodovací cyklus útočníka: pozorování, interpretace, akce, vyhodnocení a přizpůsobení.

Vlastnost	Lidský útočník	Tradiční automatizace	Útočník využívající AI
Přizpůsobivost	Vysoká	Nízká, s předem danými větvemi	Vysoká
Škálovatelnost	Nízká kvůli omezenému paralelismu	Vysoká	Vysoká, včetně paralelního přizpůsobování
Rychlost rozhodování	Rychlost člověka	Vysoká, ale podle skriptu	Nepřetržitě, strojovou rychlostí

Je třeba říci, že tyto schopnosti jsou stále ve vývoji. Současné AI systémy zatím neumí bez dohledu provést každou fázi sofistikovaného průniku. Reconnaissance, phishing, exploitace, zneužití přihlašovacích údajů, eskalace oprávnění, laterální pohyb ani exfiltrace se samy o sobě nezměnily.

Co se ale změnilo, je kvalita rozhodování mezi jednotlivými fázemi, které už může probíhat bez člověka.

Jde tedy jen o rychlost?

Do velké míry ano. Pokud útok, který dříve trval několik dní, dnes proběhne během několika minut, může obrana založená na ručním třídění alertů, eskalaci a manuálním schvalování selhat, i když správně rozpozná, že se něco děje.

Stejně tak platí, že pokud útočník dokáže dohlížet na tisíce adaptivních kampaní namísto toho, aby ručně řídil jednu jedinou, začnou pro něj být zajímavým cílem i organizace, které dříve nestály za jeho čas a náklady.

Větší škála tedy neznamená jen více útoků. Rozšiřuje také okruh organizací, na které se vyplatí útočit.

AI tedy možná nevytváří zásadně nové typy útoků. Dokáže ale natolik zkrátit zpětnou vazbu útočníka, že obranné mechanismy navržené proti útočníkům jednajícím lidskou rychlostí jednoduše nestíhají.

Vaše senzory stále vidí, co se děje

V debatách o AI útocích se často ztrácí jeden důležitý fakt: nemusí se měnit úplně všechno.

Systémům typu EDR, NDR, IAM nebo SIEM je v principu jedno, zda určité rozhodnutí udělal člověk, skript nebo model. Tyto nástroje zaznamenávají výslednou akci jako jsou spuštění procesu, přístup k přihlašovacím údajům, autentizační události, změny oprávnění, laterální pohyb, neobvyklá síťová spojení, přístup k citlivým datům nebo exfiltrace.

Ať už tedy o akci rozhodl kdokoliv (nebo cokoliv), pořád se projeví v telemetrii. AI sama o sobě tradiční bezpečnostní senzory neoslepuje. Tvrzení, že ano, je třeba brát s rezervou.

Co se ale na straně obránců musí zlepšit, je práce s kontextem. Obránci potřebují chápat celé sekvence událostí, identity a vztahy napříč endpointy, sítěmi, cloudovými službami a aplikacemi, místo aby každý alert vyhodnocovali izolovaně.

Signatury a jednotlivé alerty totiž rychle ztrácejí hodnotu ve chvíli, kdy adaptivní útočník vytváří vzorec rozprostřený napříč několika systémy. Takový vzorec vyžaduje behaviorální detekci, která dokáže pracovat se stavem a souvislostmi.

Neznamená to ale, že musíme postavit chatbot nad SIEM nebo kompletně vyměnit všechny existující senzory.

Problémem není detekce, ale rychlost reakce

Představme si následující scénář:

35. minuta: Dojde k podezřelé aktivitě, která se projeví v telemetrii.
36. minuta: Analytik si všimne alertu.
37. minuta: Útočník dokončí svůj cíl.
38. minuta: Vyšetřování je hotové.
39. minuta: Začíná omezení incidentu.

Detekce byla správná, a přesto obrana selhala. Ve chvíli, kdy člověk alert vyhodnotil a začal jednat, byl už výsledek útoku rozhodnutý. Perfektní alert má jen malou hodnotu, pokud reakce probíhá pomaleji než samotný útok.

Kvalita detekce je pořád důležitá. Více než kdy dříve je ale důležitá rychlost reakce.

Mean Time to Respond (MTTR, jak dlouho v průměru trvá bezpečnostnímu týmu zareagovat na incident nebo hrozbu.), latence rozhodování a samotný návrh procesu pro omezení incidentu se proto musí stát klíčovými parametry bezpečnostní architektury.

Proč nestačí všechno plně automatizovat

Na současnou situaci se nabízí jednoduchá odpověď: pokud se útoky pohybují strojovou rychlostí, automatizujme obranu tak, aby reagovala stejně rychle.

Jenže tady narážíme na zásadní problém. Falešně pozitivní reakce může být velmi drahá. Automatizovaný systém, který izoluje nesprávný endpoint, zablokuje nesprávný účet nebo omezí nesprávnou službu, může narušit produkční prostředí téměř stejně efektivně jako útok, kterému měl zabránit.

Funkční model proto musí být omezený, řízený mírou jistoty a pokud možno umožňovat akci vrátit:

• Nízká jistota: Nejdříve shromáždit více telemetrie.
• Střední jistota: Zvýšit úroveň logování, omezit aktivitu nebo vyžádat nové ověření identity.
• Vysoká jistota: Zneplatnit token, omezit relaci nebo izolovat endpoint.
• Kritické systémy: Před destruktivní akcí vyžadovat lidské schválení.

Cílem je ponechat člověka v rozhodovacím procesu tam, kde má jeho úsudek skutečnou hodnotu, a současně umožnit, aby se vratné a nízkorizikové akce provedly okamžitě.

Omezení oprávnění nebo vratná izolace jsou bezpečnější než plošné vypínání systémů. Jakýkoliv model reakce, který nepočítá s náklady způsobenými falešně pozitivními výsledky, v produkčním prostředí dříve či později selže.

Hlubší problém je v datové vrstvě

Mnoho SIEM implementací je stále závislých na specialistech, kteří musí vyhledávat relevantní zdroje, konfigurovat kolektory, interpretovat proprietární schémata, vytvářet a opravovat parsery, normalizovat jednotlivá pole, ověřovat správnost sběru dat a průběžně upravovat detekční pravidla podle toho, jak se systémy mění.

To vyžaduje tickety, dokumentaci a čas inženýrů. Jde o přirozeně pomalý proces, který nedokáže držet krok s rychle se měnícím prostředím. Výsledkem je strukturální nerovnováha, která existuje bez ohledu na to, jak sofistikované uvažování útočník používá.

Adaptivní útočník může nový asset (zařízení, systém, prvek v infrastruktuře atp.) objevit a začít s ním interagovat prakticky okamžitě poté, co se v prostředí objeví. V mnoha organizacích ale obranný tým potřebuje samostatný projekt jen k tomu, aby daný asset vůbec dostal do zorného pole bezpečnostních nástrojů – vědět, že existuje, sbírat z něj telemetrii a rozumět tomu, co sbíraná data znamenají.

Útočník možná uvažuje rychleji. Největší výhodu má ale díky tomu, že tým obránců vidí skutečný stav prostředí až se zpožděním týdnů.

Je proto třeba stále opakovat, že detekční inteligence musí být vždy doprovázena dostatečnou viditelností. I velmi kvalitní detekční engine je prakticky slepý, pokud data chybějí nebo jsou špatně interpretována. SIEM proto musí vědět nejen to, co vidí, ale také, kde přesně má slepá místa.

Co musí zvládnout platforma datové vrstvy

Aby bylo možné mít dostatečnou viditelnost do IT prostředí a sbírat z něj data jako podklad pro další nástroje (SIEM), musí se platforma starající se o sběr dat z prostředí (typicky log management) průběžně přizpůsobovat změnám v prostředí, aniž by to vždy vyžadovalo samostatný integrační projekt.

Konkrétně jde o šest propojených schopností:

1. Průběžné mapování prostředí
   Endpointy, identity, cloudové účty, aplikace, workloady a datové zdroje je potřeba identifikovat ve chvíli, kdy se objeví, ne až během dalšího kvartálního auditu.
2. Autonomní ingest dat
   Platforma by měla být schopná připojit nové zdroje a začít sbírat data bez nutnosti spouštět pro každý z nich samostatný integrační projekt.
3. Sémantický parsing a normalizace
   Systém musí dokázat odvodit význam jednotlivých polí a událostí, namapovat je na společný datový model a následně správnost mapování ověřit.
4. Streamové zpracování
   Události je potřeba obohacovat, korelovat a vyhodnocovat už ve chvíli, kdy přicházejí, namísto spoléhání se na zpětné vyhledávání o několik minut nebo hodin později.
5. Identifikace slepých míst
   Platforma by měla sama detekovat chybějící zdroje, nefunkční kolektory, změny schémat nebo nemonitorovanou infrastrukturu.
6. Řízené provádění akcí
   Automatizované workflow musí mít možnost vyšetřovat, konfigurovat a omezovat aktivitu v rámci jasně definovaných oprávnění a bezpečnostních pravidel odpovídajících výše popsaným úrovním jistoty.

Všechny tyto schopnosti potřebují pevný technologický základ: škálovatelné multitenantní úložiště, rychlé vyhledávání, analytiku v reálném čase, detekční logiku fungující napříč doménami, spolehlivou transformaci a routing dat a rozhraní s velmi přesně nastavitelnými oprávněními. Některá z těchto rozhraní budou stále častěji navrhována přímo pro AI agenty.

Inteligentní vrstva ale slabé jádro systému nezachrání. Pouze vytvoří rychlé a sebevědomě působící rozhraní nad špatnými daty.

Autonomní konfigurace přináší vlastní rizika

AI dokáže odvodit datové schéma nebo vygenerovat parser. To je bezpochyby užitečné. Pokud se ale splete, chyba se může velmi rychle rozšířit dál. Špatně namapované pole může nenápadně poškodit všechny následné detekce, které z něj vycházejí.

Takové změny proto musí mít hodnocení míry jistoty, jasný původ, testování, postupné nasazování a možnost rollbacku. Bez těchto pojistek je automaticky odvozené schéma jen neověřeným předpokladem, který systém prezentuje s příliš velkou sebedůvěrou.

Nejde o souboj AI proti AI

V současnosti je bezpečnostní analytika jen tak dobrá jako datová vrstva, na které stojí. Pokud je telemetrie neúplná, zpožděná nebo špatně normalizovaná, i velmi schopný model může pracovat sebejistě a přitom naslepo.

Je proto mylné si představovat budoucnost jako souboj AI útočníků proti AI obráncům, který vyhraje ten s lepším modelem. Ve skutečnosti bude mít častěji výhodu ta strana, která má úplnou viditelnost, rozumí svému (nebo cizímu) měnícímu se prostředí, dokáže pracovat s kontextem v reálném čase a ve finále bezpečně jednat strojovou rychlostí.