Craig Riddell, Global Field CISO ve Wallarm – Interview Series

Craig Riddell, Global Field CISO ve Wallarm, je zkušený cybersecurity manažer zaměřený na pomoc podnikům spravovat rostoucí rizika spojená s API a systémy poháněnými umělou inteligencí. Ve své současné roli úzce spolupracuje s CISO, CIO a vůdci inženýrů, aby přeložil reálné útočné vzorce a scénáře zneužití do akčních bezpečnostních strategií, se silným důrazem na pozorovatelnost – pochopení, jak se API a systémy umělé inteligence chovají v produkci napříč uživateli, aplikacemi a integracemi. Jeho kariéra zahrnuje vedoucí role v oblasti identity a přístupového řízení, architektury zero trust a podnikové bezpečnosti ve společnostech jako Netwrix, Kron a HP, kde řídil rozsáhlé transformace IAM a modernizoval bezpečnostní rámce. Riddellův odborný zájem se soustředí na vznikající hrozby, jako jsou útoky na obchodní logiku, zneužití API, posun systémů umělé inteligence a podvody, se stálým zaměřením na překlenutí mezery mezi vysokou úrovní bezpečnostní strategie a provozní realizací.

Wallarm je kybernetická bezpečnostní společnost specializující se na ochranu API, aplikací a systémů poháněných umělou inteligencí v moderních cloudových prostředích. Jeho platforma poskytuje nepřetržitou detekci, testování a ochranu v reálném čase proti hrozbám, jako je zneužití API, útoky na obchodní logiku a automatizované explozivní útoky, a nabízí hlubokou viditelnost do toho, jak se systémy chovají napříč složitými infrastrukturami. Navrženo pro multi-cloud a cloud-native architektury, Wallarm se integruje do stávajících DevOps a bezpečnostních pracovních postupů, umožňujícím organizacím detekovat a blokovat útoky, zatímco k nim dochází, spíše než po skutečnosti. Kombinací inventáře API, detekce hrozeb poháněných umělou inteligencí a automatizovaných reakčních schopností platforma řeší rostoucí realitu, ve které se API a systémy umělé inteligence staly primární útočnou plochou pro moderní digitální podniky.

Začali jste svou kariéru prací přímo se systémy a infrastrukturou a od té doby jste přešli do vedoucích rolí zaměřených na identitu, přístup, API a bezpečnost umělé inteligence. Jaké byly klíčové posuny na této cestě, které vás vedly k závěru, že skutečné riziko se přesunulo od perimetru do API a strojově řízených systémů?

Na počátku své kariéry se zaměřoval na ochranu okraje. Brány firewall, segmentace, zpevňování infrastruktury. Tento model fungoval, když systémy byly statické a hranice důvěry byly snazší definovat.

Co se změnilo, je způsob, jakým jsou aplikace postaveny a jak systémy interagují. API se staly spojovacím tkáním všeho a umělá inteligence tuto změnu urychlila. Nyní systémy činí rozhodnutí, volají jiné systémy a provádějí akce v měřítku a rychlosti, které nezahrnují lidi do smyčky.

V tomto okamžiku se perimetr stává méně relevantním. Skutečné riziko se přesunulo tam, kde jsou učiněna rozhodnutí a prováděny akce, uvnitř API a strojově řízených pracovních postupů.

Pokud nemáte viditelnost a kontrolu tam, důvěřujete chování, které nelze plně vidět. To je místo, kde se objevuje obchodní riziko, od finančního vystavení až po neúmyslné výsledky a provozní přerušení.

Popsal jste kybernetický potřásání rukou jako rozbitý, odkazující na to, jak systémy navazují důvěru a vyměňují akce napříč stále složitějšími řetězci API a automatizovaných procesů. Jak vypadá tato porucha v reálném podnikovém prostředí dnes?

Ve většině prostředí systémy důvěřují jeden druhému na základě identity a autentizace. Token je platný, požadavek je dobře vytvořen a interakce je povolena.

Problém spočívá v tom, že se předpokládá, že platný znamená bezpečný. To již není pravda.

Autentizujeme identitu, ale neověřujeme záměr. Verifikujeme přístup, ale ne chování napříč řetězcem.

Služba může být autorizována k volání jiné služby, která spouští následné akce napříč několika API. Každý krok vypadá legitimně v izolaci, ale napříč plným řetězcem začnete vidět neúmyslné chování nebo zneužití logiky.

V prostředích poháněných umělou inteligencí je to zesíleno. Agenti mohou řetězit akce a spouštět pracovní postupy bez lidské revize.

Potřásání rukou stále probíhá, ale nikdo se neptá, zda chování má smysl v kontextu. Důvěra je zavedena, ale není průběžně ověřena.

Proč riziko AI a API tak často padá mezi organizační hranice místo toho, aby bylo jasně vlastněno?

Protože systémy nejsou sladěny s tím, jak jsou organizace strukturovány.

DevOps vlastní doručování. Bezpečnost vlastní politiku. Obchodní týmy vlastní výsledky. Týmy dat vlastní modely. Každá skupina vlastní kus, ale nikdo nevlastní systém, jak se chová v produkci.

API provádějí obchodní logiku napříč systémy. Umělá inteligence zavádí nedeterministické rozhodování na vrchol toho. Společně řezají napříč každou hranicí.

Jsou postaveny jedním týmem, zabezpečeny jiným a konzumovány třetím, s nekonzistentním monitorováním napříč všemi.

Mezery, které to vytváří, nejsou selháním týmů. Jsou selháním operačního modelu, aby odrážel, jak moderní systémy skutečně fungují.

Važíme-li se na vaše zkušenosti, které týmy obvykle předpokládají, že vlastní riziko AI, a kde existují největší slepá místa mezi bezpečností, DevOps a obchodními jednotkami?

Bezpečnostní týmy se obvykle domnívají, že vlastní riziko AI z hlediska governance a compliance. DevOps vlastní nasazení a spolehlivost. Obchodní jednotky se zaměřují na výsledky.

Slepá místa se objevují mezi těmito oblastmi.

Bezpečnost definuje, co by se mělo stát. DevOps zajišťuje, že systém běží. Obchodní jednotky se soustředí na výsledky. Ale velmi málo týmů se systematicky dívá na to, co systém skutečně dělá v reálném čase.

Tato mezera je místem, kde riziko žije, zejména když chování je technicky platné, ale kontextově špatné.

Mnohé moderní útoky se objevují jako platné a autentizované chování spíše než zjevné průniky. Jak by měly organizace přehodnotit detekci v tomto novém realitě?

Musíme se posunout za identifikaci „špatných“ požadavků.

Ve mnoha případech je požadavek platný. Pověření jsou legitimní. Volání API je očekávané. Co není očekávané, je posloupnost akcí, objem nebo výsledek.

Detekce musí být chování a kontext. Je to méně o blokování jednoho požadavku a více o pochopení, jak systémy interagují över čas.

Přístupy, které skutečně fungují v měřítku, přesahují párování vzorků. Rozkládají požadavky strukturálně, zacházejí s každou interakcí jako s sadou behaviorálních tokenů, spíše než se snažící se shodovat s známými špatnými vzory.

To umožňuje pochopit, jak se chování vyvíjí a kde se odchyluje, i když všechno vypadá platně na povrchu.

Pokud se spoléháte na statická pravidla nebo signatury, budete muset většinu toho, co je důležité, minout.

Vy jste zdůraznili důležitost pozorovatelnosti skutečného chování. Jak vypadá smysluplná pozorovatelnost pro API a systémy AI v produkci?

Smysluplná pozorovatelnost není jen logy a metriky. Je to pochopení chování v kontextu.

Pro API to znamená plnou viditelnost požadavků a odpovědí, jak jsou koncové body používány a jak interakce evoluují över čas.

Pro systémy AI to znamená pochopení vstupů, rozhodnutí a výsledných akcí.

Nejdůležitější je propojení těchto informací napříč systémy do plných pracovních postupů, ne izolovaných událostí.

Bez toho fungujete na základě předpokladů o chování systému, spíše než reality.

Proč se tradiční modely lidské revize a schválení stávají méně účinnými v prostředí řízeném stroji?

Protože se změnila rychlost a měřítko.

Systémy činí tisíce nebo miliony volání za minutu a útoky nebo neúmyslné chování mohou se vyvinout v minutách nebo sekundách. Nemůžete realisticky umístit člověka do smyčky pro každé rozhodnutí, aniž byste porušili výkon.

Systémy AI také nejsou vždy deterministické, což činí modely před-schválení méně účinnými.

Lidský dohled stále záleží, ale musí se posunout z individuálního schvalování akcí na definování ochranných zábran a monitorování výsledků.

Jaké jsou nejčastější provozní mezery, které vidíte, když společnosti snaží zabezpečit systémy AI pomocí legacy bezpečnostních rámců?

Největší mezera je nadměrná závislost na řízeních v době návrhu.

Organizace se soustředí na zabezpečení modelů, kontrolu kódu a definici politik před nasazením. To je důležité, ale předpokládá, že systémy se budou chovat tak, jak se očekává, až budou nasazeny.

Ve skutečnosti systémy evoluují. API se mění. Modely AI interagují s novými daty a pracovními postupy. Chování se mění över čas.

Bez průběžné validace chování v produkci jsou organizace efektivní slepé po nasazení.

Jak vypadá praktický operační model, když více zúčastněných stran sdílí odpovědnost za riziko AI a API?

Začíná to uznáním, že žádný jediný tým nemůže vlastnit tuto cestu koncovým-to-koncovému.

Praktický model definuje sdílenou odpovědnost, ukotvenou kolem společného zdroje pravdy: chování v reálném čase.

Bezpečnost definuje riziko a politiku. Inženýrství buduje a provozuje systémy. Obchodní jednotky definují přijatelné výsledky.

Týmy, které jsou před touto výzvou, fungují v uzavřené smyčce. Kontinuální objev, vynucení a rafinace poháněné tím, co systémy skutečně dělají v produkci, ne tím, co se předpokládalo v době návrhu.

Všechny zúčastněné strany potřebují viditelnost do toho, jak systémy fungují v produkci. Odtud mohou týmy sladit, co „dobré“ vypadá, detekovat odchylky a reagovat.

Posun je z izolovaného vlastnictví na koordinovanou odpovědnost, zakořeněnou v přehledu v reálném čase.

Pohledem do budoucnosti, očekáváte, že bezpečnostní odpovědnost se stane opět více centralizovanou, nebo bude pokračovat ve fragmentaci, jak systémy budou stále autonomnější?

Odpovědnost zůstane distribuovaná, protože to odráží, jak jsou systémy postaveny.

Co se změní, je to, jak tato odpovědnost bude koordinována.

Uvidíme více sjednocených modelů governance, kde týmy vlastní své domény, ale fungují se sdílenou viditelností a kontextem.

Organizace, které uspějí, nebudou ty, které se pokusí centralizovat vše. Budou to ty, které sladí zúčastněné strany kolem toho, jak systémy skutečně fungují ve skutečném světě.

Protože pokud nikdo nerozumí chování v reálném čase, nikdo skutečně nevlastní riziko.

Děkuji za skvělý rozhovor, čtenáři, kteří chtějí se dozvědět více, by měli navštívit Wallarm.