Simon Edwards, CEO e Fondatore di SE Labs – Serie di Interviste

Simon Edwards, CEO e Fondatore di SE Labs, è un esperto di test di sicurezza informatica con oltre tre decenni di esperienza che coprono ricerca sulla sicurezza, valutazione di prodotti, giornalismo tecnico e standard di settore. Prima di fondare SE Labs nel 2015, Edwards ha diretto Dennis Technology Labs, dove ha guidato iniziative di test di sicurezza, e in precedenza ha trascorso molti anni come giornalista e redattore tecnologico. Ha ricoperto inoltre ruoli di leadership senior presso l’Anti-Malware Testing Standards Organization (AMTSO), tra cui Presidente, Direttore e Co-Presidente. Edwards testa prodotti di sicurezza dal metà degli anni ’90 e ha introdotto i primi approcci di test anti-malware nel mondo reale, progettati per valutare come le tecnologie di sicurezza si comportano contro attacchi completi, distribuiti via Internet, piuttosto che contro campioni di malware isolati.

SE Labs è un’azienda indipendente di test e consulenza sulla sicurezza informatica che valuta come le tecnologie di sicurezza si comportano contro attacchi realistici. I suoi ricercatori replicano le tecniche degli aggressori lungo l’intera catena di attacco per valutare prodotti tra cui protezione degli endpoint, Endpoint Detection and Response (EDR), servizi di sicurezza cloud, firewall, sicurezza email e tecnologie di rilevamento di rete. Oltre ai test comparativi pubblici, SE Labs offre certificazione, test di sicurezza avanzati, validazione di prodotto e servizi di consulenza per imprese e fornitori di sicurezza informatica. L’azienda pubblica le proprie metodologie di test e i framework di emulazione delle minacce ed è certificata secondo ISO/IEC 27001:2022 e BS EN ISO 9001:2015 per la fornitura di test di prodotti di sicurezza IT.

La tua carriera si estende per più di tre decenni tra giornalismo tecnologico, consulenza sulla sicurezza, test indipendenti e ruoli di leadership presso l’Anti-Malware Testing Standards Organization (AMTSO). In che modo questa esperienza ha influenzato il modo in cui distingui i veri progressi nella cybersecurity alimentata dall’IA da tecnologie che vengono principalmente presentate come “IA” a fini di marketing?

Il giornalismo mi ha insegnato a mettere in dubbio le affermazioni, mentre i test indipendenti mi hanno mostrato che l’unica risposta affidabile proviene dalle evidenze. Le aziende di cybersicurezza utilizzano l’apprendimento automatico e le decisioni automatizzate da molti anni, quindi aggiungere “IA” al nome di un prodotto non rappresenta necessariamente un avanzamento tecnico.

Tre aspetti fondamentali da considerare: Cosa fa realmente l’IA? Quale risultato di sicurezza misurabile migliora? E un tester indipendente può riprodurre tale miglioramento?

Se la risposta è semplicemente che il prodotto analizza una grande quantità di dati o automatizza un processo esistente, l’etichetta IA potrebbe riguardare più il posizionamento che la capacità.

Un vero progresso si comporta bene contro attacchi sconosciuti o appena emersi, migliora la protezione o la risposta, riduce il carico per gli analisti e lo fa senza introdurre rischi inaccettabili. Qualsiasi altra cosa è o una non-miglioria o un peggioramento!

“AI-driven” è diventata un’affermazione comune nei prodotti di cybersecurity. Quali sono le capacità più importanti che dovrebbero essere testate in modo indipendente prima che un’organizzazione accetti che una piattaforma di sicurezza alimentata dall’IA fornisca effettivamente ciò che il fornitore promette?

Non inizierei testando se un prodotto contiene IA. Inizierei testando le affermazioni di sicurezza fatte su di esso. Non mi importa davvero come funzioni un prodotto, purché funzioni. Questo è l’obiettivo preciso del programma di test PIVOT, che sta guadagnando molta trazione nel settore in questo momento.

Testare in questo modo significa esporre il prodotto a attacchi completi e misurare come risponde. Probabilmente dovrebbe rilevare l’attività e poi potrebbe impedire il proseguimento dell’attacco. Ciò dipende da come il prodotto è costruito e configurato, nonché dalle affermazioni di marketing che il fornitore sta facendo.

Dobbiamo anche esaminare la narrazione investigativa presentata al cliente. Il sistema ha compreso cosa è accaduto, ha collegato gli eventi rilevanti e ha reso le prove visibili alla persona che deve agire su di esse?

Il test dovrebbe includere varianti sconosciute, configurazioni cliente realistiche e attività aziendali normali. Deve inoltre misurare i falsi positivi, le richieste di risorse e le azioni che possono essere considerate potenzialmente non sicure. Se il sistema è autonomo, dobbiamo sapere quando agisce, perché agisce, quali permessi utilizza e se le sue decisioni possono essere annullate.

Abbiamo visto alcuni casi nei media di sicurezza IA che si comporta in modo incontrollato, superando i propri limiti e potenzialmente la legge. La domanda importante non è se la piattaforma sembra intelligente, ma se produce risultati di sicurezza costantemente migliori e più sicuri.

Gli agenti IA autonomi possono potenzialmente eseguire ricognizione, sfruttamento, movimento laterale e altre fasi di un attacco molto più velocemente di un attaccante umano. Come deve cambiare il testing di cybersecurity quando gli attacchi iniziano a operare a velocità di macchina?

L’unità di test deve passare dalla singola tecnica alla campagna completa operante sotto pressione temporale. Con ciò intendo che, invece di provare diversi modi di attacco per una mattina o una settimana, la verifica di determinate misure di sicurezza deve avvenire rapidamente. Altrimenti non è realistico, e il realismo è molto importante.

I test tradizionali possono lasciare lacune comode tra le fasi, così che ogni evento possa essere esaminato separatamente. Un attaccante autonomo può comprimere ricognizione, sfruttamento e movimento laterale in un periodo molto più breve. Ciò potrebbe esporre debolezze non visibili nei test più lenti, inclusi ritardi nella telemetria, sistemi sovraccarichi e azioni difensive che arrivano solo dopo che l’attacco ha raggiunto il suo obiettivo.

Per darti un esempio estremamente semplice, se hackiamo un Mac, scarichiamo tutti i suoi file e rubiamo le password degli account, non serve a molto se l’antivirus segnala la notizia negativa un giorno dopo.

Testare le risposte di sicurezza contro attaccanti IA richiede quindi un’instrumentazione ad alta risoluzione e una misurazione precisa della latenza di rilevamento e risposta. Deve verificare se le prestazioni peggiorano con l’aumento del volume e della velocità dell’attività, e se la difesa può interrompere un attacco senza attendere una decisione umana a ogni fase.

L’attacco può anche adattarsi a ciò che scopre. Il test deve riflettere ciò mantenendo la verità di base, le prove e la riproducibilità. La velocità delle macchine non dovrebbe significare abbandonare una metodologia controllata. Dobbiamo continuare a progettare test controllati che possano operare e misurare gli eventi alla stessa velocità dei sistemi valutati.

SE Labs utilizza scenari di attacco realistici basati sulle tattiche e tecniche di gruppi di minaccia come Scattered Spider. Come ricreare questi avversari in un ambiente controllato garantendo che il test rifletta come si svolgerebbe un attacco reale, piuttosto che testare semplicemente contro una checklist predefinita?

Partiamo dagli obiettivi dell’avversario, dai comportamenti noti e dalle probabili decisioni, piuttosto che trattare le sue tecniche come una lista della spesa.

Il test segue una catena di attacco realistica attraverso ricognizione, accesso iniziale, esecuzione, escalation dei privilegi, attività post-compromissione e movimento laterale. È importante che il tester possa utilizzare solo le informazioni effettivamente scoperte durante la ricognizione e l’attacco. Non forniamo all’attaccante conoscenze che non sarebbero disponibili in un vero engagement.

Lo scenario è delimitato e attentamente controllato, ma non è semplicemente una sequenza di pressioni di pulsanti predeterminate. Se una via è bloccata, l’attaccante può perseguire un’alternativa credibile entro le regole del test. Ciò consente al prodotto di sicurezza di influenzare il modo in cui lo scenario si sviluppa.

Allo stesso tempo, ogni azione e risultato importante viene registrato in modo da poter spiegare l’esito e confrontare i prodotti in modo equo. Controllato non deve significare rigidamente sceneggiato. Deve significare sicuro, osservabile e supportato da prove.

I prodotti di cybersecurity sono stati tradizionalmente valutati soprattutto per la loro capacità di rilevare le minacce. Perché le organizzazioni dovrebbero sempre più considerare protezione, contenimento e risposta agli incidenti quando valutano sistemi di sicurezza guidati dall’IA?

Il rilevamento non è lo stesso della difesa. Una piattaforma può generare un avviso accurato consentendo comunque all’attaccante di raggiungere l’obiettivo. È per questo che il programma di test PIVOT include sia il rilevamento sia la protezione come parti congiunte e separate del test complessivo.

Puoi paragonare il rilevamento della sicurezza informatica a una telecamera CCTV. Deve notare un’intrusione e darti indizi su cosa è accaduto, ma non fermerà fisicamente l’intruso. La protezione della sicurezza informatica è molto più attiva. Può espellere o neutralizzare l’attaccante, prevenendo danni.

Le organizzazioni devono sapere se il prodotto ha impedito l’attività iniziale, interrotto la catena di attacco, limitato il movimento laterale, protetto asset importanti e supportato il recupero. Se un attacco ha successo, le domande successive sono quanto rapidamente è stato contenuto e se il cliente ha ricevuto informazioni sufficientemente affidabili per rispondere efficacemente.

Ciò diventa particolarmente importante con i sistemi guidati dall’IA perché, sebbene possano produrre riepiloghi molto convincenti di quanto accaduto, una spiegazione persuasiva non sostituisce la protezione. La spiegazione deve essere supportata da prove e deve condurre a un’azione appropriata.

Misuriamo quindi rilevamento e protezione separatamente. Esaminiamo anche se il rilevamento dichiarato era realmente visibile e utile al cliente. In definitiva, il valore di un sistema di sicurezza risiede nel cambiare l’esito di un attacco, non solo nell’osservarlo.

Man mano che le piattaforme di sicurezza introducono agenti autonomi capaci di investigare avvisi e intraprendere azioni di rimedio, come dovrebbero i laboratori indipendenti testare l’intero flusso di lavoro umano‑e‑IA anziché valutare la tecnologia di rilevamento sottostante in isolamento?

Il test dovrebbe seguire l’intero processo dalla prima attività malevola al risultato finale di sicurezza, che potrebbe essere l’interruzione dell’attacco o il suo successo totale – o qualcosa di intermedio.

Dobbiamo esaminare ciò che l’agente ha osservato, cosa ha concluso, cosa ha raccomandato o fatto, cosa è stato mostrato all’operatore umano e come l’operatore ha risposto (o quali opzioni gli sono state presentate). Ciò include la qualità delle prove, la chiarezza del passaggio di consegne, il tempo richiesto, il numero di interventi e se l’umano poteva comprendere, contestare o invertire la decisione dell’agente.

Anche le diverse modalità operative sono importanti. Un agente che raccomanda un’azione per l’approvazione presenta un rischio diverso rispetto a uno che può isolare automaticamente i sistemi, disabilitare gli account o modificare i controlli di sicurezza.

Un sistema non ha avuto successo solo perché il suo rilevatore di base ha identificato l’attacco. Se crea una coda incomprensibile, nasconde prove importanti, raccomanda la risposta sbagliata o compie un’azione dirompente, l’intero flusso di lavoro è fallito. I test indipendenti dovrebbero misurare la performance combinata della tecnologia, dei suoi componenti autonomi e delle persone che si prevede le utilizzeranno.

Un rischio dei benchmark di sicurezza standardizzati è che i fornitori possano ottimizzare i prodotti specificamente per il test. Come può il testing indipendente rimanere riproducibile e imparziale introducendo al contempo sufficiente imprevedibilità per rivelare come i prodotti si comportano contro attacchi non familiari?

La riproducibilità non richiede di fornire ai partecipanti le domande dell’esame in anticipo.

Un test credibile dovrebbe pubblicare la sua metodologia, l’ambiente, i principi di punteggio, la configurazione del prodotto e i requisiti di evidenza. I fornitori dovrebbero comprendere le regole e avere un’opportunità equa di verificare che i loro prodotti funzionino correttamente. Tuttavia, la campagna di attacco precisa, i payload e alcuni dei percorsi di attacco dovrebbero rimanere sconosciuti fino al momento in cui il test viene eseguito.

Ad esempio, in PIVOT non divulghiamo quali gruppi di attacco replicheremo fino a dopo il completamento dei test. I veri bersagli non ricevono alcun avviso prima dell’inizio di un attacco!

Possiamo combinare un nucleo standard, che supporta il confronto nel tempo, con variazioni non familiari che testano la capacità generale. Una baseline e un periodo di quiete nascosto possono stabilire come il prodotto si comporta prima dell’attacco. La configurazione dovrebbe poi essere controllata, i log conservati e qualsiasi affermazione verificata contro le proprie evidenze del tester.

L’equità significa applicare le stesse regole e gli stessi standard di evidenza a ogni partecipante. Non significa ripetere un attacco in modo così prevedibile da permettere a un fornitore di riconoscere il benchmark anziché la minaccia.

Inoltre, la trasparenza radicale aiuta i fornitori a riprodurre gli attacchi, il che è importante se vogliono correggere eventuali problemi riscontrati, come il mancato rilevamento o la mancata protezione contro una minaccia. SE Labs, in sostanza, forma i propri clienti quando incontrano problemi.

Gli agenti di sicurezza autonomi introducono una categoria diversa di rischio perché una decisione errata potrebbe innescare un’azione di rimedio non necessaria o addirittura dirompente. Come dovrebbe il testing misurare falsi positivi, ragionamenti errati e azioni autonome potenzialmente dannose insieme alla tradizionale accuratezza di rilevamento?

Il testing tradizionale dei falsi positivi è solo il primo livello. Con un agente autonomo, dobbiamo distinguere tra un avviso falso, una conclusione non supportata e un’azione errata. Ognuna ha un impatto potenziale diverso.

I test dovrebbero esporre il sistema ad attività legittime che somigliano a comportamenti malevoli, così come a evidenze incomplete, ambigue o fuorvianti. Se l’agente consuma contenuti non attendibili, il testing dovrebbe anche verificare se tali contenuti possono influenzare indebitamente le sue decisioni.

Il ragionamento dovrebbe essere valutato in base al fatto che la conclusione sia supportata dalle evidenze disponibili, non in base a quanto plausibile o sicura sembri la spiegazione. Per le azioni autonome, dovremmo misurare l’ambito, la proporzionalità, l’uso delle autorizzazioni, i controlli di approvazione, l’auditabilità e la reversibilità.

Il punteggio deve riflettere le conseguenze. Un avviso non necessario è solo un inconveniente; disabilitare un account importante o isolare un sistema critico potrebbe interrompere l’organizzazione. Una misura di sicurezza utile deve quindi considerare sia la frequenza degli errori sia il danno che ciascun errore può causare.

Detto ciò, a volte il cliente sceglie una politica che genera problemi. Questo non è necessariamente colpa del fornitore di sicurezza.

L’IA generativa e i modelli open source sempre più capaci stanno abbassando la soglia per automatizzare parti del processo di attacco. Ti aspetti che l’IA renda gli attacchi informatici fondamentalmente più sofisticati, o il pericolo più grande è che gli aggressori potranno semplicemente operare su scala e velocità drasticamente maggiori?

La mia aspettativa è che il pericolo più immediato sia la scala, la velocità e la riduzione dei costi.

L’IA può aiutare gli aggressori a raccogliere informazioni, personalizzare l’ingegneria sociale, modificare il codice e coordinare parti di una campagna. Alcuni attacchi diventeranno più sofisticati di conseguenza, soprattutto quando l’IA aiuta a collegare tecniche esistenti o ad adattarle a un bersaglio specifico. Ma l’IA non elimina la necessità di accesso, credenziali, vulnerabilità sfruttabili o errori da parte dei difensori.

L’IA non è neanche molto brava a produrre exploit affidabili, cosa già molto difficile anche per un umano esperto. Perciò, a mio forte avviso, riduce la probabilità di attacchi fondamentalmente più sofisticati.

Il cambiamento più grande è che attività che prima richiedevano tempo, competenza o un team di persone possono ora essere tentate più rapidamente e su molti più obiettivi. L’IA può elevare la competenza di aggressori relativamente ordinari, consentendo al contempo a quelli più capaci di gestire più operazioni simultaneamente.

Ciò è significativo anche se le tecniche di attacco sottostanti non sono rivoluzionarie. Il pericolo non è necessariamente una forma completamente nuova di attacco informatico. Si tratta di attacchi familiari che diventano più rapidi, più economici, più personalizzati e molto più numerosi.

Man mano che gli agenti IA difensivi e offensivi diventano più autonomi, a cosa dovrà assomigliare un ambiente credibile di test della sicurezza informatica per tenere il passo? Potremmo eventualmente arrivare a un punto in cui i prodotti di sicurezza devono essere continuamente sfidati da avversari IA adattivi piuttosto che valutati principalmente attraverso test di sicurezza periodici?

Un ambiente credibile dovrà assomigliare a un’organizzazione vivente piuttosto che a una raccolta di obiettivi isolati. Dovrebbe includere endpoint, sistemi di identità, email, reti, servizi cloud, utenti realistici e attività aziendali normali. Deve inoltre fornire un’instrumentazione completa in modo che ogni decisione e conseguenza possa essere ricostruita.

Gli avversari adattivi potrebbero ricevere obiettivi e limiti, per poi scegliere percorsi in base a ciò che scoprono e a come il prodotto difensivo risponde. Il test dovrebbe comunque avere condizioni di partenza controllate, una descrizione affidabile di quanto realmente accaduto e la capacità di riprodurre gli eventi importanti. Senza questi elementi, i test adattivi potrebbero apparire impressionanti ma essere scientificamente deboli.

Mi aspetto che i test diventino più continui, soprattutto quando prodotti, modelli e politiche possono cambiare frequentemente. Tuttavia, la sfida continua dovrebbe integrare, non sostituire, i test comparativi periodici. Le organizzazioni hanno bisogno di entrambi: benchmark controllati come PIVOT che supportano la responsabilità e il confronto, e valutazioni adattive continue che rivelano come i sistemi si comportano man mano che le minacce e i prodotti stessi evolvono.

Credo che dovremmo preoccuparci più del fatto che esseri umani relativamente inesperti possano violare sistemi e reti, piuttosto che dei robot che creano la prossima generazione di tecnologia di attacco informatico.

Grazie per la splendida intervista, i lettori che desiderano saperne di più dovrebbero visitare SE Labs.