Craig Riddell, Global Field CISO på Wallarm – Intervjuserie

Craig Riddell, Global Field CISO på Wallarm, är en erfaren cybersäkerhetsexpert som fokuserar på att hjälpa företag att hantera de växande riskerna som är kopplade till API:er och AI-drivna system. I sin nuvarande roll arbetar han nära med CISO:er, CIO:er och ingenjörsledare för att översätta verkliga attackmönster och missbruks scenarier till agerbara säkerhetsstrategier, med stark betoning på observabilitet – förståelse för hur API:er och AI-system beter sig i produktion över användare, applikationer och integrationer. Hans karriär omfattar ledande roller inom identitet och åtkomsthantering, nolltillitsarkitektur och företagssäkerhet i organisationer som inkluderar Netwrix, Kron och HP, där han drev storskaliga IAM-omvandlingar och moderniserade säkerhetsramverk. Riddells expertis fokuserar på nya hot som affärlogikattacker, API-missbruk, AI-systemdrift och bedrägeri, med ett konsekvent fokus på att överbrygga gapet mellan högnivåsäkerhetsstrategi och operativ exekvering.

Wallarm är ett cybersäkerhetsföretag som specialiserar sig på att skydda API:er, applikationer och AI-drivna system i moderna molnmiljöer. Dess plattform erbjuder kontinuerlig upptäckt, testning och realtids skydd mot hot som API-missbruk, affärlogikattacker och automatiserade exploateringar, samtidigt som den erbjuder djup insikt i hur system beter sig över komplexa infrastrukturer. Utformad för multi-moln och moln-nativa arkitekturer integrerar Wallarm i befintliga DevOps- och säkerhetsflöden, vilket möjliggör för organisationer att upptäcka och blockera attacker medan de händer snarare än efteråt. Genom att kombinera API-inventering, AI-driven hotdetektering och automatiserad responsförmåga adresserar plattformen den växande verkligheten där API:er och AI-system har blivit den primära attackytan för moderna digitala företag.

Du började din karriär med att arbeta direkt med system och infrastruktur och har sedan flyttat till ledande roller med fokus på identitet, åtkomst, API och AI-säkerhet. Vilka nyckel förändringar under resan ledde dig till att dra slutsatsen att den verkliga risken har flyttat från periferin och in i API:er och maskin-styrda system?

Tidigt i min karriär var fokus på att skydda kanten. Brandväggar, segmentering, förstärkning av infrastruktur. Den modellen fungerade när systemen var mer statiska och förtroendegränser var lättare att definiera.

Vad som förändrades var hur applikationer byggdes och hur system interagerade. API:er blev den sammanhållande vävnaden i allt, och AI accelererade det ytterligare. Nu fattar system beslut, ringer andra system och utför åtgärder i en skala och hastighet som inte involverar människor i loopen.

På den punkten blir periferin mindre relevant. Den verkliga risken flyttar till där beslut fattas och åtgärder utförs, inuti API:er och maskin-styrda arbetsflöden.

Om du inte har insyn och kontroll där, litar du på beteende som du inte fullständigt kan se. Det är där affärsrisken dyker upp, från finansiell exponering till oavsiktliga konsekvenser och operativa avbrott.

Du har beskrivit den cyberhandslag som trasig, med hänvisning till hur system etablerar förtroende och utbyter åtgärder över alltmer komplexa kedjor av API:er och automatiserade processer. Hur ser den här sönderfallet ut i en verklig företagsmiljö idag?

I de flesta miljöer litar system på varandra baserat på identitet och autentisering. En token är giltig, en begäran är välgjord, och interaktionen tillåts.

Problemet är att detta antar att giltig är detsamma som säker. Det är inte längre sant.

Vi autentiserar identitet, men vi validerar inte avsikt. Vi verifierar åtkomst, men inte beteende över kedjan.

En tjänst kan vara auktoriserad att anropa en annan tjänst, som utlöser nedströmsåtgärder över flera API:er. Varje steg ser legitimt ut i isolering, men över hela kedjan börjar du se oavsiktligt beteende eller missbruk av logik.

I AI-drivna miljöer förstärks detta. Agenter kan kedja åtgärder och utföra arbetsflöden utan mänsklig granskning.

Handslaget sker fortfarande, men ingen frågar om beteendet är meningsfullt i sammanhanget. Förtroende etableras men valideras inte kontinuerligt.

Varför faller AI- och API-risken så ofta mellan organisationsgränser istället för att tydligt ägas?

Eftersom systemen inte stämmer överens med hur organisationer är strukturerade.

DevOps äger leverans. Säkerhet äger policy. Företagsgrupper äger resultat. Datateam äger modeller. Varje grupp äger en bit, men ingen äger systemet som det beter sig i produktion.

API:er utför affärslogik över system. AI introducerar icke-deterministiskt beslutsfattande ovanpå det. Tillsammans skär de över alla gränser.

De byggs av ett team, säkras av ett annat och konsumeras av ett tredje, med inkonsekvent övervakning över alla dem.

Gapet som detta skapar är inte en brist i team. Det är en brist i den operativa modellen för att återspegla hur moderna system faktiskt fungerar.

I din erfarenhet, vilka team antar vanligtvis att de äger AI-risken, och var finns de största blind fläckarna mellan säkerhet, DevOps och företagsenheter?

Säkerhetsteam tenderar att äga AI-risken från ett styrnings- och regelefterlevnads perspektiv. DevOps äger distribution och tillförlitlighet. Företagsgrupper fokuserar på resultat.

Blind fläckarna dyker upp mellan dessa områden.

Säkerhet definierar vad som ska hända. DevOps ser till att systemet körs. Företaget fokuserar på resultat. Men mycket få team tittar konsekvent på vad systemet faktiskt gör i realtid.

Det gapet är där risken bor, särskilt när beteendet är tekniskt giltigt men sammanhangs fel.

Många moderna attacker verkar som giltigt och autentiserat beteende snarare än uppenbara intrång. Hur bör organisationer omdefiniera upptäckt i denna nya verklighet?

Vi behöver flytta bortom att identifiera “dåliga” förfrågningar.

I många fall är förfrågan giltig. Legitimationen är legitim. API-anropet är förväntat. Vad som inte är förväntat är sekvensen av åtgärder, volymen eller resultatet.

Upptäckt måste bli beteendemässig och sammanhangsberoende. Det handlar mindre om att blockera en enskild förfrågan och mer om att förstå hur system interagerar över tid.

Tillvägagångssätt som faktiskt fungerar i stor skala flyttar bortom mönstermatchning. De dekomponerar förfrågningar strukturellt, behandlar varje interaktion som en uppsättning beteendemässiga token snarare än att försöka matcha mot kända dåliga mönster.

Det gör att du kan förstå hur beteendet utvecklas och var det avviker, även när allt ser giltigt ut på ytan.

Om du förlitar dig på statiska regler eller signaturer kommer du att missa det mesta av vad som är viktigt.

Du har betonat vikten av insyn i verkligt beteende. Vad ser meningsfull insyn ut som för API:er och AI-system i produktion?

Meningsfull insyn är inte bara loggar och mått. Det handlar om att förstå beteende i sammanhanget.

För API:er betyder det fullständig insyn i förfrågan och svar, hur slutpunkter används och hur interaktioner utvecklas över tid.

För AI-system handlar det om att förstå indata, beslut och resulterande åtgärder.

Viktigast av allt handlar det om att koppla samman dessa över system till fullständiga arbetsflöden, inte isolerade händelser.

Utan det opererar du på antaganden om systembeteende snarare än verkligheten.

Varför blir traditionella mänskliga gransknings- och godkännandemodeller mindre effektiva i maskin-styrda miljöer?

Eftersom hastigheten och skalan har förändrats.

System fattar tusentals eller miljontals beslut per minut, och attacker eller oavsiktligt beteende kan utvecklas på minuter eller sekunder. Du kan inte realistiskt sätta en människa i loopen för varje beslut utan att bryta prestanda.

AI-system är inte alltid deterministiska, vilket gör för-godkännandemodeller mindre effektiva.

Mänsklig tillsyn är fortfarande viktig, men den behöver flytta från att godkänna enskilda åtgärder till att definiera skyddsräcken och övervaka resultat.

Vilka är de vanligaste operativa gapen du ser när företag försöker säkra AI-system med hjälp av äldre säkerhetsramverk?

Det största gapet är överdriven tillit till design-tidskontroller.

Organisationer fokuserar på att säkra modeller, granska kod och definiera policys innan distribution. Det är viktigt, men det antar att system kommer att bete sig som förväntat när de är live.

I verkligheten utvecklas system. API:er ändras. AI-modeller interagerar med ny data och arbetsflöden. Beteendet förändras över tid.

Utan kontinuerlig validering av beteende i produktion är organisationer i princip blinda efter distribution.

Vad ser en praktisk operativ modell ut som när flera intressenter delar ansvar för AI- och API-risken?

Det börjar med att erkänna att inget enskilt team kan äga detta från början till slut.

En praktisk modell definierar delat ansvar, förankrat kring en gemensam sanning: driftsbeteende.

Säkerhet definierar risk och policy. Ingenjörer bygger och opererar system. Företaget definierar acceptabla resultat.

Teamen som kommer före detta opererar i en sluten loop. Kontinuerlig upptäckt, genomdrivande och förfining driven av vad system faktiskt gör i produktion, inte vad som antogs vid design-tiden.

Alla intressenter behöver insyn i hur system opererar i produktion. Därifrån kan teamen anpassa sig till vad “bra” ser ut, upptäcka avvikelser och svara.

Förändringen är från enskild ägo till samordnat ansvar, grundat i driftsinsikt.

Om du ser framåt, förväntar du dig att säkerhetsansvar kommer att bli mer centraliserat igen, eller kommer det att fortsätta att fragmenteras när system blir mer autonoma?

Ansvaret kommer att förbli distribuerat eftersom det speglar hur system byggs.

Vad som kommer att förändras är hur det ansvaret samordnas.

Vi kommer att se mer enhetliga styrningsmodeller där team äger sina domäner men opererar med gemensam insyn och sammanhang.

De organisationer som lyckas kommer inte att vara de som försöker centralisera allt. De kommer att vara de som anpassar intressenter kring hur system faktiskt beter sig i den verkliga världen.

Eftersom om ingen förstår driftsbeteende, äger ingen verkligen risken.

Tack för den utmärkta intervjun, läsare som vill lära sig mer bör besöka Wallarm.