Conoscere le tecniche offensive non significa autorizzare un agente a utilizzarle
Nell’articolo pubblicato l’8 novembre abbiamo affrontato l’ipotesi di utilizzare un agente di intelligenza artificiale contro gli attacchi informatici. La domanda centrale riguardava il controllo: se affidiamo a un agente il compito di sorvegliare la rete, chi sorveglia l’agente?
Esiste però una domanda precedente.
Come può un’intelligenza artificiale (AI) riconoscere un attacco se non conosce il modo in cui potrebbe essere condotto?
Un medico studia le malattie senza doverle diffondere. Un investigatore impara le tecniche criminali senza ricevere il permesso di commettere reati. Analogamente, un sistema AI può conoscere tattiche e comportamenti offensivi senza essere autorizzato a utilizzarli contro sistemi reali.
La distinzione fondamentale riguarda tre elementi:
| Elemento | Domanda |
|---|
| Conoscenza | Che cosa sa il modello? |
| Capacità | Quali strumenti può utilizzare? |
| Autorizzazione | Dove e per quale scopo può agire? |
Il rischio nasce quando questi tre elementi vengono confusi.
Un modello che conosce un attacco non è ancora un attaccante
Un Large Language Model (LLM), cioè un modello linguistico di grandi dimensioni, può conoscere la terminologia della sicurezza informatica, descrivere vulnerabilità note e interpretare il comportamento di un aggressore.
Questa conoscenza non equivale automaticamente alla capacità di compromettere un sistema.
Per produrre un effetto reale servono anche:
- accesso a una rete;
- strumenti utilizzabili;
- credenziali;
- possibilità di eseguire comandi;
- obiettivi raggiungibili;
- permessi compatibili con l’azione;
- assenza o inefficacia dei controlli esterni.
Il modello diventa operativamente pericoloso quando la conoscenza viene collegata a strumenti e privilegi non adeguatamente limitati.
Non basta quindi chiedere se l’AI conosca una tecnica offensiva. Dobbiamo domandarci che cosa possa fare con quella conoscenza.
Red team, blue team e white team
Nella sicurezza informatica vengono normalmente distinti almeno tre ruoli.
Il red team simula il comportamento di un avversario. Cerca di individuare debolezze e verificare se le difese riescano a riconoscere un attacco autorizzato.
Il blue team difende l’ambiente. Analizza eventi, configurazioni e segnali anomali, riconosce le minacce e propone o applica le contromisure previste.
Il white team stabilisce le regole dell’esercitazione, controlla che il perimetro venga rispettato e valuta i risultati.
Il NIST (National Institute of Standards and Technology) descrive il red team come un gruppo autorizzato a simulare le capacità di un potenziale avversario. Il blue team difende l’ambiente, mentre un gruppo neutrale può supervisionare l’esercitazione e applicarne le regole.
Trasferendo questo modello agli agenti AI, potremmo immaginare:
- un agente red team che genera o esegue scenari offensivi esclusivamente nel laboratorio autorizzato;
- un agente blue team che osserva gli eventi e tenta di riconoscerli;
- un valutatore indipendente che confronta scenario previsto, evidenze prodotte e risposta difensiva.
Il terzo ruolo non deve necessariamente essere affidato a un’altra AI. Può comprendere controlli deterministici, registrazioni tecniche e revisione umana.
Che cosa significa realmente “addestrare” l’agente
Non sarebbe sufficiente consegnare al modello una raccolta di tecniche informatiche e chiedergli di comportarsi come un hacker.
Un sistema di questo tipo richiederebbe diversi livelli.
Una base di conoscenza verificata
MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) raccoglie tattiche e tecniche osservate nel comportamento di avversari reali. Può fornire un linguaggio comune per descrivere ciò che l’agente offensivo simula e ciò che il sistema difensivo dovrebbe riconoscere.
ATT&CK non rappresenta però un elenco completo di tutto ciò che un aggressore potrebbe fare. MITRE raccomanda di selezionare le tecniche pertinenti al proprio ambiente e di integrare la conoscenza pubblica con le evidenze interne disponibili.
Casi autorizzati e controllati
Gli esempi dovrebbero provenire da:
- incidenti anonimizzati;
- rapporti tecnici autorizzati;
- simulazioni;
- esercitazioni interne;
- configurazioni prive di credenziali reali;
- scenari costruiti dagli specialisti.
Non servirebbe conservare indiscriminatamente codice malevolo, dati sottratti o materiale proveniente da attività non autorizzate.
Un ambiente isolato
L’agente red team dovrebbe operare in un cyber range, cioè un laboratorio di rete separato dai sistemi reali.
L’ambiente dovrebbe contenere bersagli simulati, dati sintetici e strumenti limitati allo scenario. Non dovrebbe permettere di raggiungere Internet, le reti aziendali o servizi esterni non compresi nell’esercitazione.
L’isolamento non dovrebbe dipendere da una semplice istruzione scritta nel prompt. Deve essere applicato dall’infrastruttura.
Valutazioni ripetibili
Ogni esercitazione dovrebbe poter essere ripetuta, confrontando:
- scenario previsto;
- azioni effettivamente tentate;
- eventi registrati;
- rilevazioni del blue team;
- falsi allarmi;
- tempo necessario per riconoscere il problema;
- decisioni proposte;
- rispetto del perimetro.
Un sistema non dovrebbe ricevere una valutazione positiva soltanto perché è riuscito a compromettere il bersaglio simulato. Deve anche rispettare limiti, condizioni di arresto e strumenti autorizzati.
L’agente red team dovrebbe lavorare dentro una gabbia tecnica
La conoscenza offensiva può essere utile per verificare le difese, ma l’agente che la utilizza deve avere meno libertà di quanto avrebbe un normale utente.
Un ambiente prudente dovrebbe prevedere:
- rete isolata;
- bersagli espressamente predisposti;
- credenziali valide soltanto nel laboratorio;
- strumenti inseriti in una lista autorizzata;
- durata e obiettivi definiti;
- registrazione completa delle operazioni;
- impossibilità di trasferire dati verso l’esterno;
- condizioni automatiche di arresto;
- supervisione del white team.
Il National Institute of Standards and Technology definisce il red teaming dell’AI come un’attività strutturata per individuare vulnerabilità e capacità dannose, spesso svolta in un ambiente controllato e in collaborazione con chi sviluppa il sistema.
La parola importante è “controllato”.
Un prompt che ordina al modello di non uscire dal laboratorio rappresenta una regola comportamentale. Una rete realmente isolata rappresenta invece un limite tecnico.
Servono entrambe, ma non hanno lo stesso valore.
L’agente blue team ha bisogno di capacità differenti
L’agente difensivo non dovrebbe essere semplicemente una copia dell’agente offensivo con un prompt diverso.
Deve imparare a:
- interpretare log e segnali di sicurezza;
- collegare eventi provenienti da fonti differenti;
- riconoscere sequenze anomale;
- distinguere un incidente da un’attività legittima;
- spiegare quali evidenze sostengono l’allarme;
- proporre verifiche proporzionate;
- indicare il grado d’incertezza;
- chiedere l’intervento umano quando le informazioni non bastano.
In una prima fase potrebbe lavorare esclusivamente in lettura. Potrebbe classificare gli eventi e proporre azioni senza poter bloccare account, isolare dispositivi o modificare configurazioni.
Soltanto dopo una valutazione adeguata si potrebbero introdurre operazioni limitate e reversibili.
La possibilità di intervenire automaticamente dovrebbe dipendere dal tipo di evento, dall’affidabilità della rilevazione e dal danno che potrebbe produrre una risposta errata.
Un falso positivo che genera una segnalazione inutile è fastidioso. Un falso positivo che blocca un servizio essenziale può diventare un incidente.
Perché non affidare entrambi i ruoli allo stesso agente
Usare un solo agente potrebbe sembrare più semplice. Avrebbe la conoscenza dell’attaccante e quella del difensore, condividendo memoria, strumenti e contesto.
Questa concentrazione crea però diversi problemi.
Conflitto tra obiettivi
L’agente potrebbe dover massimizzare contemporaneamente la riuscita della simulazione e la capacità di interromperla. Il risultato della valutazione diventerebbe difficile da interpretare.
Condivisione delle stesse ipotesi
Se attaccante e difensore utilizzano lo stesso modello, le stesse fonti e lo stesso contesto, potrebbero condividere anche gli stessi errori.
Il blue team potrebbe riconoscere molto bene gli attacchi prodotti dal proprio gemello e fallire davanti a strategie differenti.
Eccesso di privilegi
Un unico agente dotato sia degli strumenti offensivi sia dei permessi difensivi avrebbe accesso a una combinazione di capacità particolarmente delicata.
Un errore d’interpretazione, una manipolazione del contesto o una configurazione sbagliata potrebbero collegare strumenti che avrebbero dovuto rimanere separati.
Valutazione poco indipendente
La stessa intelligenza che propone lo scenario non dovrebbe essere l’unico soggetto incaricato di stabilire se la risposta sia stata corretta.
Separare agenti, credenziali, contesti e strumenti non elimina il rischio. Rende però più difficile che un singolo errore attraversi l’intera catena.
Che cosa dovremmo misurare
Anche gli indicatori devono riflettere i ruoli differenti.
| Ruolo | Valutazioni principali |
|---|
| Red team | Aderenza allo scenario, copertura delle tecniche concordate, rispetto del perimetro e ripetibilità |
| Blue team | Capacità di rilevazione, falsi positivi, qualità delle evidenze e tempestività della segnalazione |
| White team | Completezza dei log, applicazione delle regole, arresto degli esperimenti fuori perimetro e riproducibilità |
Il numero di sistemi compromessi non dovrebbe rappresentare la misura principale dell’agente offensivo.
Analogamente, il numero di allarmi prodotti non dimostra la qualità dell’agente difensivo.
Un sistema che segnala tutto non sta necessariamente riconoscendo gli attacchi. Potrebbe semplicemente trasferire il lavoro di verifica alle persone.
Un esempio controllato
Immaginiamo un laboratorio che riproduca una piccola rete aziendale.
Il white team seleziona alcune tecniche pertinenti all’ambiente e definisce quali azioni siano consentite. Prepara i sistemi simulati, stabilisce la durata della prova e configura la registrazione degli eventi.
L’agente red team riceve l’obiettivo e può utilizzare soltanto gli strumenti del laboratorio.
L’agente blue team osserva i log e gli allarmi. Quando identifica una sequenza sospetta, deve indicare:
- eventi rilevati;
- possibile tecnica;
- sistemi interessati;
- livello di affidabilità;
- verifica consigliata;
- eventuale contromisura.
Il white team confronta ciò che è realmente avvenuto con ciò che il difensore ha ricostruito.
Le regole prodotte durante l’esercitazione possono essere esaminate e trasferite agli strumenti difensivi. L’agente offensivo, invece, rimane nel laboratorio.
Nessuna capacità operativa viene spostata automaticamente in produzione.
Il fallimento meno visibile
Il problema più evidente sarebbe un agente red team che uscisse dal perimetro.
Esiste però un fallimento più silenzioso: un agente blue team che appare competente, produce spiegazioni tecniche convincenti e genera molti allarmi, ma riconosce soltanto gli attacchi che assomigliano agli esempi usati durante la preparazione.
Il sistema potrebbe sembrare efficace perché supera tutte le prove previste. Nel frattempo rimarrebbe vulnerabile a comportamenti diversi, dati incompleti o segnali manipolati.
MITRE ricorda che ATT&CK descrive comportamenti osservati e non costituisce una lista esaustiva di tutte le possibilità. Coprire una tecnica non significa essere protetti da ogni variante con cui quella tecnica potrebbe manifestarsi.
L’esercitazione deve quindi cambiare nel tempo. Deve includere scenari non utilizzati durante la preparazione del modello e prove nelle quali le evidenze siano incomplete o contraddittorie.
Il mio punto di vista
Un agente difensivo deve conoscere il linguaggio dell’attaccante. Altrimenti potrebbe riconoscere soltanto anomalie generiche senza comprenderne la possibile progressione.
Questa conoscenza non richiede che l’agente disponga degli stessi privilegi di un aggressore reale.
Insegnerei le tecniche offensive nel laboratorio. Affiderei l’analisi difensiva a un agente separato. Lascerei autorizzazioni, condizioni di arresto e valutazione finale fuori dal controllo di entrambi.
Non addestrerei quindi un’intelligenza artificiale a “diventare un hacker”.
Costruirei un sistema nel quale un agente possa rappresentare l’avversario soltanto entro un ambiente progettato per impedirgli di diventarlo davvero.
Il confine decisivo non è ciò che il modello conosce.
È ciò che il sistema gli permette di fare con quella conoscenza.
Fonti consultate
Fonti verificate l’11 novembre 2026:
- MITRE, MITRE ATT&CK: base di conoscenza delle tattiche e delle tecniche osservate nel comportamento degli avversari.
- MITRE, Get Started with ATT&CK: utilizzo di ATT&CK per rilevamento, red teaming, blue team e valutazione delle difese.
- MITRE, ATT&CK Data and Tools: strumenti per rappresentare copertura difensiva e pianificazione delle esercitazioni.
- NIST, Red Team/Blue Team Approach: definizione dei ruoli red team, blue team e white team.
- NIST, Artificial Intelligence Red Teaming: definizione dell’attività strutturata di verifica dei sistemi AI in ambiente controllato.
- NIST, Artificial Intelligence Risk Management Framework: quadro per la gestione dei rischi nei sistemi di intelligenza artificiale.
- NIST, Cybersecurity, Privacy and AI: rapporto tra adozione dell’AI, sicurezza informatica e gestione dei nuovi rischi.
