Craig Riddell, Global Field CISO di Wallarm – Serie di interviste

Craig Riddell, Global Field CISO di Wallarm, è un esperto di cybersecurity di lunga data che si concentra sull’aiutare le imprese a gestire i rischi crescenti legati alle API e ai sistemi guidati da intelligenza artificiale. Nel suo ruolo attuale, lavora a stretto contatto con CISO, CIO e leader di ingegneria per tradurre modelli di attacco e scenari di abuso nel mondo reale in strategie di sicurezza azionabili, con un forte accento sull’osservabilità – capire come le API e i sistemi di intelligenza artificiale si comportano in produzione tra utenti, applicazioni e integrazioni. La sua carriera copre ruoli di leadership in identità e gestione dell’accesso, architettura di trust zero e sicurezza aziendale in organizzazioni come Netwrix, Kron e HP, dove ha guidato trasformazioni IAM su larga scala e modernizzato i framework di sicurezza. L’esperienza di Riddell si concentra su minacce emergenti come attacchi di logica aziendale, abuso di API, deriva del sistema di intelligenza artificiale e frode, con un focus costante sul colmare il divario tra strategia di sicurezza di alto livello e esecuzione operativa.

Wallarm è un’azienda di cybersecurity specializzata nella protezione delle API, delle applicazioni e dei sistemi guidati da intelligenza artificiale in ambienti cloud moderni. La sua piattaforma fornisce scoperta continua, test e protezione in tempo reale contro minacce come abuso di API, attacchi di logica aziendale e sfruttamento automatizzato, offrendo una profonda visibilità su come i sistemi si comportano attraverso infrastrutture complesse. Progettata per architetture multi-cloud e cloud-native, Wallarm si integra con i flussi di lavoro DevOps e di sicurezza esistenti, consentendo alle organizzazioni di rilevare e bloccare gli attacchi mentre si verificano, piuttosto che dopo il fatto. Combinando l’inventario delle API, la rilevazione delle minacce guidata da intelligenza artificiale e le capacità di risposta automatizzate, la piattaforma affronta una realtà crescente in cui le API e i sistemi di intelligenza artificiale sono diventati la principale superficie di attacco per le imprese digitali moderne.

Hai iniziato la tua carriera lavorando direttamente con sistemi e infrastrutture e sei poi passato a ruoli di leadership focalizzati sulla sicurezza dell’identità, dell’accesso, delle API e dell’intelligenza artificiale. Quali sono stati i principali cambiamenti lungo questo percorso che ti hanno portato a concludere che il vero rischio si è spostato dall’perimetro alle API e ai sistemi guidati da macchina?

All’inizio della mia carriera, l’attenzione era rivolta alla protezione del perimetro. Firewall, segmentazione, infrastrutture harden. Quel modello funzionava quando i sistemi erano più statici e i confini di trust erano più facili da definire.

Ciò che è cambiato è come le applicazioni sono costruite e come i sistemi interagiscono. Le API sono diventate il tessuto connettivo di tutto, e l’intelligenza artificiale ha accelerato ulteriormente questo processo. Ora i sistemi prendono decisioni, chiamano altri sistemi ed eseguono azioni a una scala e velocità che non coinvolgono gli esseri umani nel ciclo.

A quel punto, il perimetro diventa meno rilevante. Il vero rischio si sposta dove vengono prese le decisioni e vengono eseguite le azioni, all’interno delle API e dei flussi di lavoro guidati da macchina.

Se non si ha visibilità e controllo lì, si sta fidando di un comportamento che non si può vedere appieno. È lì che si presenta il rischio aziendale, dalla esposizione finanziaria agli esiti inattesi e alla disrupzione operativa.

Hai descritto la “stretta di mano cyber” come rotta, riferendoti a come i sistemi stabiliscono la fiducia e scambiano azioni attraverso catene di API e processi automatizzati sempre più complesse. Come si presenta questo crollo in un ambiente aziendale reale di oggi?

Nella maggior parte degli ambienti, i sistemi si fidano l’uno dell’altro in base all’identità e all’autenticazione. Un token è valido, una richiesta è ben formata e l’interazione è consentita.

Il problema è che questo presume che “valido” significhi “sicuro”. Ciò non è più vero.

Autenticazione dell’identità, ma non convalida dell’intento. Verifichiamo l’accesso, ma non il comportamento attraverso la catena.

Un servizio può essere autorizzato a chiamare un altro servizio, che a sua volta attiva azioni a valle attraverso più API. Ogni passaggio sembra legittimo in isolamento, ma attraverso l’intera catena, inizia a vedersi un comportamento non intenzionale o abuso di logica.

In ambienti guidati da intelligenza artificiale, ciò è amplificato. Gli agenti possono concatenare azioni ed eseguire flussi di lavoro senza revisione umana.

La stretta di mano ancora avviene, ma nessuno chiede se il comportamento ha senso nel contesto. La fiducia è stabilita ma non convalidata continuamente.

Perché il rischio dell’AI e delle API spesso cade tra i confini organizzativi invece di essere chiaramente posseduto?

Perché i sistemi non si allineano con come le organizzazioni sono strutturate.

DevOps possiede la consegna. La sicurezza possiede la politica. Le squadre aziendali possiedono gli esiti. Le squadre dei dati possiedono i modelli. Ogni gruppo possiede un pezzo, ma nessuno possiede il sistema come si comporta in produzione.

Le API eseguono la logica aziendale attraverso i sistemi. L’intelligenza artificiale introduce un processo decisionale non deterministico su questo. Insieme, tagliano attraverso ogni confine.

Sono costruite da un team, protette da un altro e consumate da un terzo, con monitoraggio inconsistente attraverso tutti loro.

I gap che questo crea non sono fallimenti dei team. Sono fallimenti del modello operativo nel riflettere come i sistemi moderni funzionano effettivamente.

Nella tua esperienza, quali team tendono ad assumere di possedere il rischio dell’AI, e dove si trovano i più grandi punti ciechi tra la sicurezza, il DevOps e le unità aziendali?

Le squadre di sicurezza tendono a possedere il rischio dell’AI da una prospettiva di governance e conformità. DevOps possiede la distribuzione e l’affidabilità. Le unità aziendali si concentrano sugli esiti.

I punti ciechi si presentano tra quelle aree.

La sicurezza definisce cosa dovrebbe accadere. DevOps assicura che il sistema funzioni. L’azienda si concentra sugli esiti. Ma poche squadre guardano costantemente a cosa il sistema sta facendo effettivamente in tempo reale.

Quella lacuna è dove vive il rischio, specialmente quando il comportamento è tecnicamente valido ma contestualmente sbagliato.

Molte moderne minacce appaiono come comportamento valido e autenticato piuttosto che come intrusioni ovvie. Come le organizzazioni dovrebbero ripensare la rilevazione in questa nuova realtà?

Dobbiamo andare oltre l’identificazione di “cattive” richieste.

In molti casi, la richiesta è valida. Le credenziali sono legittime. La chiamata API è attesa. Ciò che non è atteso è la sequenza di azioni, il volume o l’esito.

La rilevazione deve diventare comportamentale e contestuale. È meno bloccare una singola richiesta e più capire come i sistemi interagiscono nel tempo.

Gli approcci che effettivamente funzionano a larga scala vanno oltre il pattern matching. Decompongono le richieste in modo strutturale, trattando ogni interazione come un set di token comportamentali piuttosto che cercare di abbinare contro pattern noti come cattivi.

Ciò consente di capire come il comportamento evolve e dove si discosta, anche quando tutto sembra valido in superficie.

Se si fa affidamento a regole statiche o firme, si perderà la maggior parte di ciò che conta.

Hai sottolineato l’importanza dell’osservabilità nel comportamento del mondo reale. Cosa significa un’osservabilità significativa per le API e i sistemi di intelligenza artificiale in produzione?

Un’osservabilità significativa non è solo log e metriche. È capire il comportamento nel contesto.

Per le API, significa visibilità completa della richiesta e della risposta, come vengono utilizzati gli endpoint e come le interazioni evolvono nel tempo.

Per i sistemi di intelligenza artificiale, significa capire gli input, le decisioni e le azioni risultanti.

La cosa più importante è collegare questi elementi attraverso i sistemi in flussi di lavoro completi, non eventi isolati.

Senza di questo, si opera su assunzioni sul comportamento del sistema invece che sulla realtà.

Perché i modelli di revisione e approvazione umana tradizionali stanno diventando meno efficaci in ambienti guidati da macchina?

Perché la velocità e la scala sono cambiate.

I sistemi stanno facendo migliaia o milioni di chiamate al minuto, e gli attacchi o il comportamento non intenzionale possono svilupparsi in minuti o secondi. Non è realistico mettere un essere umano nel ciclo per ogni decisione senza rompere le prestazioni.

I sistemi di intelligenza artificiale non sono sempre deterministici, il che rende i modelli di approvazione pregressi meno efficaci.

La supervisione umana è ancora importante, ma deve spostarsi dall’approvazione di azioni individuali alla definizione di limiti e al monitoraggio degli esiti.

Quali sono i gap operativi più comuni che vedi quando le aziende cercano di proteggere i sistemi di intelligenza artificiale utilizzando framework di sicurezza legacy?

Il gap più grande è la dipendenza eccessiva dai controlli al momento del design.

Le organizzazioni si concentrano sulla protezione dei modelli, sulla revisione del codice e sulla definizione delle politiche prima della distribuzione. Ciò è importante, ma presume che i sistemi si comporteranno come previsto una volta che saranno live.

Nella realtà, i sistemi evolvono. Le API cambiano. I modelli di intelligenza artificiale interagiscono con nuovi dati e flussi di lavoro. Il comportamento cambia nel tempo.

Senza una convalida continua del comportamento in produzione, le organizzazioni sono effettivamente cieche dopo la distribuzione.

Cosa significa un modello operativo pratico quando più stakeholder condividono la responsabilità per il rischio dell’AI e delle API?

Inizia con il riconoscimento che nessun team può possedere questo processo dall’inizio alla fine.

Un modello pratico definisce la responsabilità condivisa, ancorata intorno a una fonte di verità comune: il comportamento in esecuzione.

La sicurezza definisce il rischio e la politica. L’ingegneria costruisce e opera i sistemi. L’azienda definisce gli esiti accettabili.

Le squadre che hanno la meglio in questo operano in un ciclo chiuso. Scoperta continua, applicazione e raffinamento guidati da ciò che i sistemi stanno facendo effettivamente in produzione, non da ciò che è stato assunto al momento del design.

Tutti gli stakeholder devono avere visibilità su come i sistemi operano in produzione. Da lì, le squadre possono allinearsi su cosa significhi “buono”, rilevare le deviazioni e rispondere.

Il cambiamento è da proprietà isolata a responsabilità coordinata, fondata sull’intuizione in fase di esecuzione.

Guardando avanti, ti aspetti che la responsabilità della sicurezza diventi più centralizzata di nuovo, o continuerà a frammentarsi man mano che i sistemi diventano più autonomi?

La responsabilità rimarrà distribuita perché ciò riflette come sono costruiti i sistemi.

Ciò che cambierà è come quella responsabilità sarà coordinata.

Vedremo più modelli di governance unificati in cui le squadre possiedono i loro domini ma operano con visibilità e contesto condivisi.

Le organizzazioni che avranno successo non saranno quelle che cercheranno di centralizzare tutto. Saranno quelle che allineeranno gli stakeholder su come i sistemi si comportano effettivamente nel mondo reale.

Perché se nessuno capisce il comportamento in esecuzione, nessuno possiede effettivamente il rischio.

Grazie per la grande intervista, i lettori che desiderano saperne di più possono visitare Wallarm.