Red team, blue team e purple team: le differenze

Il red team è un gruppo autorizzato che simula un attaccante reale per raggiungere un obiettivo preciso, per esempio arrivare ai dati dei clienti. Il blue team è chi presidia i sistemi e deve accorgersi dell'attacco e rispondere. Il purple team non è una terza squadra fissa: è il momento in cui le due lavorano insieme per trasformare quello che l'attacco ha mostrato in rilevazioni e procedure migliori.

Qui trovi cosa fa ciascuna squadra secondo le definizioni del NIST e del framework europeo TIBER-EU, in cosa un esercizio di red team si distingue da un penetration test, cosa chiedono DORA e la guida TIBER-IT e da quale dei tre conviene partire.

I tre colori in breve

• Red team: attacca. Emula le tattiche di un avversario plausibile, insegue un obiettivo concordato e di norma lavora senza che chi presidia i sistemi lo sappia.
• Blue team: presidia. Monitora, rileva, analizza, contiene e ripristina. Nella maggior parte delle aziende coincide con il SOC, interno o esterno.
• Purple team: collega. Red e blue ripercorrono insieme l'attacco, vedono cosa è stato rilevato e cosa no e decidono cosa cambiare.
• White team: arbitra. È il piccolo gruppo che sa del test, ne fissa le regole e lo ferma se esce dal perimetro. Se ne parla meno, ma senza di lui l'esercizio non è controllabile.

Il red team: emulare un avversario, non contare le vulnerabilità

Il glossario del NIST, che riprende la definizione del CNSSI 4009-2022, descrive il red team come un gruppo autorizzato e organizzato per emulare le capacità di attacco di un potenziale avversario contro la postura di sicurezza di un'organizzazione. Lo scopo dichiarato è migliorare la sicurezza mostrando l'impatto di un attacco riuscito e, insieme, cosa funziona per chi presidia i sistemi. Il NIST SP 800-53 Rev. 5 definisce l'esercizio di red team come un tentativo avversariale simulato, in condizioni realistiche, di compromettere le missioni o i processi di business, per valutare in modo complessivo le capacità di sicurezza dell'organizzazione.

La parola che conta è obiettivo. Un red team non riceve un elenco di indirizzi da verificare: riceve un traguardo (in TIBER-EU si chiamano flag) e sceglie la strada, che può passare da una mail di phishing, da un fornitore o da una configurazione dimenticata.

Red team e penetration test

Se ti serve il quadro di partenza, cos'è un penetration test e in cosa differisce da un vulnerability assessment sono spiegati nei rispettivi articoli. Qui conta il passo successivo, che il NIST SP 800-115 (settembre 2008, par. 2.4.2) descrive distinguendo due modi di testare:

• Test dichiarato (overt): lo staff IT sa del test e collabora. Permette una valutazione completa, limita l'impatto sui sistemi e diventa un'occasione di formazione. È l'impostazione tipica di un pen test.
• Test riservato (covert): lo staff IT non sa nulla, il vertice aziendale ne è pienamente informato e lo autorizza. Lo scopo è misurare il danno che un avversario può causare, non individuare ogni vulnerabilità né verificare ogni controllo. È la logica del red team.

Lo stesso documento indica il prezzo della scelta: il test riservato richiede più tempo e costa di più, perché per non farsi notare il team deve rallentare scansioni e azioni. In cambio dà un'indicazione più fedele della sicurezza di tutti i giorni, perché gli amministratori non sono in allerta. Detto in breve: il pen test risponde alla domanda quali porte sono aperte, il red team alla domanda ce ne accorgeremmo se qualcuno entrasse.

Il blue team: chi presidia i sistemi

Per il NIST (sempre dal CNSSI 4009-2022) il blue team è il gruppo responsabile della difesa dei sistemi informativi dell'organizzazione contro gli attaccanti simulati del red team, di solito per un periodo prolungato, in un contesto operativo realistico e con regole stabilite e sorvegliate da un gruppo neutrale. Fuori dagli esercizi, il blue team è semplicemente chi fa questo lavoro ogni giorno:

• raccoglie e correla log ed eventi da endpoint, rete, cloud e identità;
• scrive e mantiene le regole di rilevazione;
• analizza gli allarmi e separa i falsi positivi dagli incidenti veri;
• contiene, risponde e ripristina, e documenta cosa è successo.

In pratica è il perimetro di un SOC. La guida nazionale TIBER-IT v2.0 (novembre 2025) aggiunge un dettaglio che il mid-market tende a trascurare: il blue team è composto da tutto il personale dell'entità testata che non fa parte del Control Team, comprese le terze parti, in particolare chi gestisce i sistemi, e include chi è responsabile della difesa della rete. Se il monitoraggio è affidato a un fornitore esterno, quel fornitore fa parte del blue team e viene messo alla prova insieme all'azienda. La guida è esplicita sul segreto: «È fondamentale che il BT non sia a conoscenza del test durante il suo svolgimento e sia completamente estraneo alla preparazione e all’esecuzione del test.»

Il white team: chi sa e arbitra

Un attacco simulato su sistemi veri ha bisogno di un arbitro. Il glossario NIST chiama white team il piccolo gruppo che conosce in anticipo le attività del red team, le osserva e controlla che il test non superi i limiti concordati; nella seconda definizione contribuisce a fissare le regole d'ingaggio e i criteri di valutazione e ricava le lezioni apprese. Il NIST SP 800-115 descrive lo stesso bisogno da un altro lato: una terza parte fidata che evita che lo staff avvii una risposta a un incidente senza prima verificare che non si tratti del test.

In TIBER-EU questo ruolo è il Control Team: secondo il framework, solo questo gruppo ristretto dell'entità sa del test, mentre il resto del personale ne è all'oscuro.

Il purple team: quando le due squadre si siedono allo stesso tavolo

Il purple team è il punto in cui il red teaming smette di essere una pagella e diventa miglioramento. La Purple Teaming Guidance di TIBER-EU (gennaio 2025) lo descrive come un'attività collaborativa fra i tester del red team e il blue team, che può andare da una discussione a tavolino a prove tecniche vere e proprie. Serve ad ampliare la conoscenza delle tecniche degli attaccanti e a individuare insieme i punti deboli di prevenzione e rilevazione, che finiscono poi nel piano di rimedio. Durante questo esercizio il blue team è pienamente informato, e la guida precisa che il purple teaming non sostituisce la fase di red teaming riservata.

Nel processo TIBER-EU l'ordine è preciso. Finito l'attacco, red team e blue team scrivono ciascuno il proprio report, poi ripercorrono insieme gli scenari (il replay) e infine fanno l'esercizio di purple teaming, entro dieci settimane dalla fine della fase di attacco attivo. Gli argomenti indicati dal framework comprendono:

• gli aspetti che non è stato possibile testare durante l'attacco;
• gli altri passi che il red team avrebbe potuto fare e come il blue team avrebbe potuto rispondere;
• scenari alternativi e le loro conseguenze;
• le misure di rimedio previste, discusse con chi ha condotto l'attacco.

Lo stesso metodo si può usare anche fuori dai framework regolamentati, in forma più leggera e ricorrente: il red team esegue una tecnica alla volta, il blue team controlla in diretta se l'ha vista e, se no, scrive la regola che mancava. È un modo pratico per far crescere la rilevazione anche quando un esercizio riservato completo non è ancora giustificato.

Red team, TLPT e TIBER-IT: cosa chiede DORA

Per il settore finanziario il red team ha una veste normativa. Il Regolamento (UE) 2022/2554 (DORA) definisce il test di penetrazione guidato dalla minaccia (TLPT) all'articolo 3, punto 17, come un quadro che imita tattiche, tecniche e procedure di attori reali della minaccia e consente di testare in modo controllato i sistemi di produzione critici, e la definizione si chiude proprio con la parola red team. L'articolo 26 lo richiede con cadenza almeno triennale alle sole entità finanziarie individuate dalle autorità competenti, sui sistemi attivi di produzione che supportano le funzioni essenziali o importanti; l'autorità può chiedere di ridurre o aumentare la frequenza.

Il come lo descrivono il framework TIBER-EU, aggiornato dalla BCE nel gennaio 2025 per allinearsi a DORA, e in Italia la Guida nazionale TIBER-IT v2.0, aggiornata da Banca d'Italia, Consob e Ivass. Due elementi aiutano a capire la scala dell'esercizio: la fase di attacco attivo dura almeno 12 settimane, e il blue team resta all'oscuro per tutto quel tempo. Secondo la Banca d'Italia, anche le entità non obbligate possono svolgere test volontari, che seguono lo stesso processo. Il dettaglio del pilastro dei test di DORA è nell'articolo su test di resilienza operativa digitale e TLPT.

Da quale partire

I tre colori non sono livelli da scalare in fretta. Ognuno ha senso solo se il precedente regge:

1. Prima sai cosa hai di esposto. Se non hai un quadro recente delle vulnerabilità, un red team le scoprirà per te nel modo più costoso. Un percorso di vulnerability assessment e penetration test viene prima.
2. Poi verifichi che qualcuno guardi. Un red team contro un'azienda senza monitoraggio continuo dimostra soltanto che nessuno se ne accorge, e lo si sa già. Il blue team va costruito, o affidato a un SOC, prima di metterlo alla prova.
3. Con un blue team attivo, il purple teaming è spesso il primo passo utile. Come ogni test dichiarato costa meno di un esercizio riservato, e produce subito regole di rilevazione nuove, misurabili.
4. Il red team riservato arriva quando la rilevazione è matura e la domanda diventa: un avversario determinato, per settimane, passerebbe inosservato?
5. Se sei un'entità finanziaria individuata dall'autorità, il percorso non lo scegli tu: è il TLPT, con i tempi e i ruoli di TIBER-IT.

In sintesi: il red team attacca per raggiungere un obiettivo, il blue team rileva e risponde, il purple team fa lavorare insieme le due squadre perché l'attacco lasci rilevazioni migliori e non solo un report. Il red team non sostituisce il penetration test e ha valore solo se dall'altra parte c'è un blue team che guarda. In DORA prende la forma del TLPT, regolato in Italia dalla guida TIBER-IT.

Se la parte che oggi manca è il blue team, cioè monitoraggio, rilevazione e risposta agli incidenti 24 ore su 24, trovi come lavoriamo nella pagina dei servizi di cybersecurity.