Purple team — attaquer ses propres défenses

Le concept en une phrase

Le purple team fait jouer l’attaque (red) et la défense (blue) ensemble, dans le même exercice, pour vérifier que chaque attaque simulée produit bien une détection — et corriger quand ce n’est pas le cas.

Construire un SIEM et écrire des règles de détection ne suffit pas à savoir si elles fonctionnent vraiment. La seule façon de le vérifier, c’est de rejouer une vraie attaque contre son propre système et de regarder, en direct, si l’alerte sort. Sur les TAAF, c’est exactement ce que l’Acte 3 fait rejouer contre l’incident du jour J : la kill chain complète, du phishing initial jusqu’à la tentative d’exfiltration bloquée au pare-feu.

Les grands principes

1. Red, blue, purple — trois postures, un but

Red team — joue l’attaquant. Son objectif est de progresser dans le système comme le ferait un adversaire réel, en exploitant les faiblesses trouvées (par le scan, l’audit de conformité, ou sa propre reconnaissance).
Blue team — joue le défenseur. Son objectif est de détecter, contenir et documenter ce que fait le red team, avec les mêmes outils qu’en conditions réelles (SIEM, règles de détection, journalisation).
Purple team — n’est pas une troisième équipe séparée : c’est la collaboration délibérée entre red et blue, dans le même exercice, pour que chaque action offensive soit immédiatement confrontée à ce que la défense en a vu (ou pas vu).

Le but n’est jamais que le red gagne ou que le blue gagne : c’est que le système gagne — qu’il ressorte de l’exercice avec une détection mesurablement meilleure qu’avant.

2. La boucle — attaquer, observer, ajuster, rejouer

flowchart LR
    A[Attaquer\nred rejoue une technique] --> O[Observer\nblue cherche la détection]
    O --> Aj{Détecté ?}
    Aj -->|Oui| D[Documenter\nla détection tient]
    Aj -->|Non| Aj2[Ajuster\nnouvelle règle / correctif]
    Aj2 --> R[Rejouer\nmême technique]
    R --> O

C’est une boucle, pas une séquence à sens unique. Quand une technique n’est pas détectée, on n’écrit pas juste « non détecté » dans un rapport : on ajuste (nouvelle règle Sigma, correctif de configuration, source de log manquante ajoutée) puis on rejoue la même technique pour vérifier que l’ajustement fonctionne réellement. C’est cette boucle courte, répétée, qui améliore la détection — pas un audit ponctuel isolé.

3. Émulation d’adversaire — rejouer des techniques connues, pas « hacker »

Le purple team ne consiste pas à improviser des attaques créatives pour le plaisir de la difficulté. Il rejoue des techniques documentées, référencées dans des cadres comme MITRE ATT&CK, pour reproduire fidèlement le comportement d’adversaires réels et connus.

Sur les TAAF, cette émulation prend une forme précise : reconstituer la kill chain du jour J elle-même, technique par technique — le phishing initial, l’obfuscation PowerShell, l’escalade svc_backup → Domain Admins, le mouvement latéral, jusqu’à la tentative d’accès au coffre CLASSIFIED-VAULT-X et la collecte (pg_dump de genetic_samples). L’exercice ne réinvente pas une attaque fictive : il rejoue exactement celle qui a eu lieu, pour vérifier que chaque étape est désormais détectée — et confirmer que la tentative d’exfiltration reste bien bloquée au pare-feu, comme au jour J.

4. L’angle mort comme livrable — une attaque non détectée est le résultat le plus précieux

C’est le point le plus contre-intuitif du purple team : un test qui échoue à être détecté n’est pas un échec de l’exercice — c’est son résultat le plus utile.

Un audit qui confirme que tout fonctionne déjà bien n’apporte presque rien de nouveau. Un exercice qui révèle qu’une technique connue passe sous les radars du SIEM donne exactement ce qu’il faut pour progresser : une règle à écrire, une source de log à ajouter, un capteur à repositionner. L’angle mort découvert aujourd’hui est une compromission réelle évitée demain.

5. Cadre et éthique — environnement contrôlé, jamais en prod

Le purple team reste un exercice à haut risque s’il n’est pas cadré :

Environnement contrôlé — les techniques sont rejouées dans un environnement dédié (labo, environnement de formation), jamais directement en production, pour éviter tout impact réel sur les systèmes critiques (énergie, télémétrie satellite, systèmes de vie sur les bases australes).
Autorisation et périmètre explicites — comme pour tout audit (voir L’audit de sécurité), un exercice purple team se mène avec un mandat écrit et un périmètre défini à l’avance.
Documentation systématique — chaque technique rejouée, chaque détection (ou absence de détection) est consignée, pour nourrir le rapport final et les futures itérations de la boucle.

Où ça sert dans TAAF

TP Purple Team — l’exercice qui rejoue la kill chain complète du jour J contre le SIEM Grafana-natif construit à l’Acte 2.
Module 1 — Ombre Légitime (LotL Windows) — reconstitue en forensic la phase Windows/AD de l’attaque (PowerShell obfusqué, escalade svc_backup, mouvement latéral) : une des techniques rejouées en purple team.
Module 2 — Downgrade PQC — le volet réseau/SATCOM de la même kill chain, forensic du downgrade cryptographique côté uplink.
MITRE ATT&CK & la kill chain — le cadre qui référence les techniques rejouées ici, et le vocabulaire commun entre red et blue.

Ressources associées

Ces liens sont des points de départ pour vos propres recherches — voir la bibliothèque complète sur la page Ressources, section Audit & durcissement.

À chercher par vous-même : « purple team vs red team vs blue team », « adversary emulation MITRE ATT&CK », « purple team exercise methodology », « detection engineering feedback loop ».