Red teaming automatizzato continuo (CART): cos'è e cosa non è

Il red teaming automatizzato continuo, in inglese continuous automated red teaming (CART), indica un software che attacca il tuo ambiente a intervalli regolari, come farebbe un avversario, e riporta cosa è riuscito. Ciascuna delle tre parole porta una promessa: continuo (non una fotografia annuale), automatizzato (nessuna persona guida ogni passo) e red teaming (emulazione di un avversario, non una checklist).

Non esiste una definizione standard o normativa di CART. Il glossario del NIST CSRC non ha una voce per il termine, e la sua definizione di red team, tratta dalla CNSSI 4009-2022, descrive persone, non software: «un gruppo di persone autorizzate e organizzate per emulare le capacità di attacco o di sfruttamento di un potenziale avversario contro la postura di sicurezza di un'organizzazione», il cui obiettivo è migliorarne la sicurezza dimostrando l'impatto degli attacchi riusciti e ciò che funziona per i difensori (il blue team) in un ambiente operativo (traduzione nostra).

Il CART è quindi un termine di fornitori e di mercato, e i prodotti venduti con questa etichetta sono diversi tra loro. La maggior parte è penetration test automatizzato o autonomo eseguito a calendario, spesso insieme alla scoperta della superficie d'attacco esterna. Giudica un prodotto da cosa fa, non dall'etichetta.

• Esercitazione di red team. Una campagna guidata da un obiettivo e condotta da persone, che può comprendere social engineering e accesso fisico e spesso non viene annunciata ai difensori. Mette alla prova l'organizzazione, le persone e la capacità di rilevare e rispondere, nell'arco di settimane. Il CART automatizza una parte dell'attacco tecnico, non l'intera esercitazione.
• Breach and Attack Simulation (BAS). Ripete scenari d'attacco catalogati e controllati, spesso tramite agenti da installare, per verificare se i controlli bloccano e rilevano tecniche note. Risponde a una domanda sulle difese e non cerca percorsi per cui nessuno ha scritto uno scenario. Vedi BAS, pentest automatizzato e AEV.
• Penetration test automatizzato. Individua gli asset, tenta lo sfruttamento reale, riusa le credenziali, si muove lateralmente e riporta i percorsi che hanno funzionato, con le evidenze. Negli strumenti autonomi sono agenti AI a scegliere il passo successivo. È ciò che fa la maggior parte dei prodotti CART.
• Adversarial Exposure Validation (AEV). Non una tecnica ma la categoria di mercato con cui Gartner indica le tecnologie che forniscono «evidenze coerenti, continue e automatizzate della fattibilità di un attacco» (traduzione nostra); secondo Gartner sostituisce la BAS e le tecnologie di penetration test e red teaming automatizzati del suo Hype Cycle 2023. I prodotti CART vi rientrano. Vedi Adversarial Exposure Validation (AEV).
• Continuous threat exposure management (CTEM). Un programma, non un prodotto. Il CART fornisce evidenze per la sua fase di validazione. Vedi CTEM.

Un'ultima confusione: «AI red teaming» indica spesso il test dei modelli di AI, non delle reti. Un prodotto CART attacca la tua infrastruttura; uno strumento di red teaming dei modelli attacca il tuo modello linguistico.

Un prodotto che può girare a calendario non è ancora un programma continuo. Chiedi, e pianifica, queste cinque cose.

1. Una cadenza proporzionata alla velocità di cambiamento. I sistemi esposti su internet e l'infrastruttura delle identità cambiano spesso e sono i primi a essere attaccati: testali più spesso di un segmento interno stabile. Le norme fissano alcuni minimi: l'RTS DORA sulla gestione del rischio ICT chiede una scansione automatica delle vulnerabilità almeno settimanale sugli asset che supportano funzioni essenziali o importanti, e il PCI DSS chiede scansioni ogni tre mesi e un penetration test ogni 12 mesi.
2. Esecuzioni innescate dalle modifiche. Un nuovo servizio esposto, una modifica al firewall, un rilascio importante, un'acquisizione o una vulnerabilità appena sfruttata in un software che usi dovrebbero far partire un test senza aspettare lo slot successivo. PCI DSS 11.3 e 11.4 e NYDFS 500.5 chiedono già test o scansioni dopo modifiche significative o rilevanti, e le misure ACN chiedono un test prima della messa in esercizio di un sistema rilevante. Per le vulnerabilità appena sfruttate vedi la finestra di patch d'emergenza guidata da KEV.
3. Un retest dopo ogni correzione. Un finding si chiude quando lo stesso attacco fallisce, non quando un ticket risulta risolto. Il PCI DSS 11.4.4 chiede di ripetere il penetration test per verificare le correzioni.
4. Un registro di cosa è cambiato. Nuovi finding rispetto all'esecuzione precedente, finding tornati dopo essere stati corretti e asset non testati nel periodo. Senza questo, uno strumento continuo produce lo stesso report ogni settimana.
5. Qualcuno che agisce. Il test continuo ripaga solo se i finding arrivano a un responsabile con una scadenza. Pianifica la capacità di correzione prima della cadenza.

Se il prodotto deve anche dirti se il SOC ha visto l'attacco, confronta la sua cronologia con i tuoi alert: il pentest automatizzato ti dice cosa ha funzionato, non se è stato rilevato.

Un consulente che conduce un'esercitazione di red team osserva ogni passo. Uno strumento continuo gira spesso di notte, in produzione, senza nessuno davanti, e uno autonomo decide da sé l'azione successiva. I controlli di sicurezza devono stare nel motore:

• Perimetro verificato a ogni azione, compresi gli indirizzi presenti nel codice generato dallo strumento, al momento dell'esecuzione. L'host dello strumento stesso escluso. Gli host scoperti in corsa aggiunti al perimetro solo con un consenso esplicito, e registrati.
• Soglie di approvazione per classe di azione. Decidi quali azioni attendono una persona: sfruttamento, attacchi alle credenziali, tutto ciò che modifica lo stato di un bersaglio, test di denial of service. Per le esecuzioni non presidiate scegli in modo esplicito cosa lo strumento può fare da solo e cosa deve aspettare che qualcuno sia disponibile.
• Un arresto di emergenza che regge. Un solo comando che ferma tutto, sopravvive al riavvio e si revoca solo con una decisione dell'operatore.
• Limiti di velocità e finestre di test, perché le esecuzioni pianificate non saturino sistemi fragili né cadano nelle ore critiche per il business.
• Un registro a prova di manomissione di ogni azione degli agenti e degli operatori, per ricostruire un incidente avvenuto durante un'esecuzione.

Per il ragionamento dietro le soglie di approvazione vedi human in the loop nei test di sicurezza con AI.

• Test threat-led imposti dal regolatore. Il DORA chiede alle entità finanziarie individuate dalla propria autorità competente un threat-led penetration test almeno ogni tre anni, con una fase attiva di red team di almeno 12 settimane e regole severe sui tester: il fornitore di threat intelligence è sempre esterno, i tester interni richiedono l'approvazione dell'autorità e ogni tre test serve un tester esterno. Vedi TLPT e il playbook sull'ingaggio TLPT DORA.
• CBEST. La valutazione intelligence-led di Bank of England, PRA e FCA è condotta da fornitori di threat intelligence e penetration test accreditati CBEST, quando i regolatori lo richiedono o lo approvano, e comprende circa 14 settimane di penetration test. Vedi CBEST e CAF nel Regno Unito.
• Test che indicano un soggetto qualificato o accreditato, come le scansioni ASV del PCI DSS o il penetration test annuale del NYDFS eseguito da un soggetto qualificato. Vedi requisiti di penetration test per normativa.
• Social engineering e accesso fisico, che fanno parte delle intrusioni reali e delle esercitazioni di red team e restano fuori da ciò che fa uno strumento di test di rete.
• Test della logica applicativa e giudizio. Abusare di un flusso di approvazione o di una regola di prezzo, decidere cosa si può testare e cosa significa un finding per il business restano lavoro per persone.

Quello che il CART cambia è il tempo tra un'esercitazione e l'altra: invece di arrivare a un TLPT o a un CBEST con una fotografia vecchia di un anno, ci arrivi con evidenze continue di cosa è stato testato e cosa è stato corretto. Il test obbligatorio diventa una conferma invece di una scoperta, ma non diventa facoltativo.

1. Cosa esegui davvero? Tentativi di sfruttamento reali, tecniche simulate o percorsi modellati? Per quali finding hai una prova?
2. Come decidi il passo successivo? Una sequenza fissa o agenti che si adattano? Cosa impedisce a un agente di uscire dal perimetro?
3. Cosa fa partire un'esecuzione? Solo il calendario, o anche modifiche, nuovi asset e nuove vulnerabilità? Posso ritestare un singolo finding su richiesta?
4. Cosa succede nelle esecuzioni non presidiate? Quali azioni attendono approvazione, chi viene avvisato e cosa succede a un'approvazione in sospeso se nessuno risponde?
5. Posso fermarlo? Mostrami l'arresto di emergenza in funzione, anche dopo un riavvio.
6. Black box, gray box o entrambi? Come conservi e usi le credenziali che ti fornisco?
7. Dove gira e cosa esce dalla mia rete? SaaS, piano di controllo in cloud con un agente locale, o tutto on-premise? Dove gira il modello AI? Può funzionare air-gapped?
8. Qual è l'evidenza? Posso dimostrare che i registri non sono stati alterati? Posso esportarli per un auditor, mappati sui framework su cui rendiconto?
9. Quanto costa il continuo? Con un prezzo per test o a consumo ogni retest aggiunge costo: calcola un anno di esecuzioni settimanali, non un singolo test. Vedi quanto costa il pentest automatizzato.
10. Cosa dichiari di non sostituire? Un fornitore che dice che il suo prodotto sostituisce TLPT, CBEST o un tester qualificato sta esagerando.

Le sezioni precedenti valgono qualunque prodotto tu scelga. Questa descrive come risponde Zero Hunt, il prodotto dietro questo sito.

• Cosa esegue. Zero Hunt è un red team AI autonomo per reti e infrastrutture: un controller coordina dieci agenti specializzati che tentano lo sfruttamento reale e dimostrano quali esposizioni sono sfruttabili, con un'evidenza per ogni finding. Non è uno strumento BAS e non ripete scenari di consegna via email o di malware contro i gateway.
• In continuo. Le campagne girano una volta, ogni giorno, ogni settimana, ogni mese o con una pianificazione personalizzata, e un operatore può avviarne una dopo una modifica. Una campagna rilanciata dopo una correzione dimostra la chiusura con evidenze firmate.
• Human in the loop. Cinque livelli di autonomia stabiliscono quali azioni attendono un operatore: al più basso ogni scansione attiva, al più alto nessuna soglia di approvazione, livello che si sceglie in modo esplicito. La verifica dello sfruttamento è abilitata solo ai due livelli più alti; sotto, un operatore può eseguire un singolo proof of concept dopo un consenso scritto e nominativo, con il perimetro riverificato in quel momento.
• Sicurezza. Il perimetro è verificato sulle chiamate agli strumenti e negli script generati, gli indirizzi dell'appliance sono esclusi, l'estensione del perimetro in corsa è su consenso ed è registrata, e l'arresto di emergenza resta attivo anche dopo un riavvio finché un operatore non lo revoca.
• Evidenze. Ogni tentativo di attacco è un record firmato Ed25519 in una catena di hash SHA-256 per campagna; report e pacchetti esportati sono firmati ECDSA; i finding sono mappati su 34 framework di compliance in tutto il mondo.
• On-premise, AI privata. I modelli proprietari girano sull'appliance, nessun dato del cliente la lascia, e la modalità air-gapped disattiva l'OSINT pubblico e il download di codice sorgente pubblico.

Zero Hunt non è indicato da Gartner come fornitore AEV e non sostituisce TLPT, CBEST o i tester qualificati richiesti da altre norme. Leggi del red team AI on-premise, oppure prenota una call di 30 minuti sulla readiness per collegare il test continuo alle norme che ti riguardano.

• Red team, definizione del glossario (NIST CSRC, dalla CNSSI 4009-2022)
• Penetration testing, definizioni del glossario (NIST CSRC)
• Adversarial Exposure Validation, definizione del mercato (Gartner Peer Insights)
• Regolamento (UE) 2022/2554 (DORA), articoli da 24 a 27 (EUR-Lex)
• Regolamento delegato (UE) 2025/1190, RTS sul TLPT (EUR-Lex)
• Regolamento delegato (UE) 2024/1774, RTS sul quadro di gestione del rischio ICT (EUR-Lex)
• CBEST Implementation Guide 2024 (Bank of England)
• PCI Data Security Standard (PCI SSC)

Le sintesi normative riprendono le guide di dettaglio linkate nel testo, che citano tutte le fonti primarie.