Purple Team en Pratique: Construire une Boucle de Feedback Red vs Blue

Le Purple Team n'est pas un atelier trimestriel avec pizza et belles diapositives, c'est une cadence d'ingenierie ou chaque TTP execute par la Red devient une hypothese de detection pour la Blue en moins de 72 heures. Chez Basilisk OffSec, on tourne en sprints de deux semaines: 10 techniques selectionnees dans ATT&CK, execution controlee en laboratoire corporatif, et cloture avec une regle Sigma deployee en production. Le KPI n'est pas combien de shells la Red a obtenu, mais combien de techniques sont passees de 'non detectee' a 'alertee avec faible faux positif'. Qui ne mesure pas ce delta fait du theatre securitaire couteux. Ce guide decompose le cycle en etapes reproductibles, outils concrets et metriques qui survivent a une revue de direction.

Ce que signifie vraiment le Purple Team

Faire tourner la Red et la Blue en silo produit deux verites: des attaquants qui ecrivent des rapports que personne ne transforme en detection, et des defenseurs qui construisent des regles qu'aucun adversaire reel ne declenche. Le Purple Team efface la frontiere en liant les deux cotes a la meme ligne de temps et au meme artefact. C'est une fonction, pas un effectif permanent: les memes personnes changent de role a chaque exercice. L'objectif operationnel est de reduire la boucle de feedback de mois a jours. Un cycle mature produit au moins une detection versionnee par sprint, un playbook de reponse lie, et une baisse mesuree du temps moyen de detection pour la technique pratiquee. Le reste n'est que preparation.

Prioriser les techniques par threat intel reel

Le point de depart est un catalogue de techniques priorise par threat intel reel, pas par mode de conference. On prend des rapports recents (Mandiant M-Trends, CrowdStrike OverWatch, ANSSI CERT-FR) et on les croise avec la matrice ATT&CK Enterprise v15. Pour une operation financiere, par exemple, T1078.004 (comptes cloud), T1558.003 (Kerberoasting) et T1059.001 (PowerShell) finissent en haut. La priorisation suit trois axes: probabilite face a notre profil sectoriel, rayon d'impact en cas de succes, et ecart de detection actuel selon l'ATT&CK Navigator. Les techniques qu'on detecte deja de facon fiable descendent dans la liste; les cellules sombres de la heatmap definissent le sprint. Ainsi l'exercice reste ancre a un risque mesurable plutot qu'a une curiosite personnelle.

Le contrat ecrit entre Red et Blue

Avant l'execution, la Red documente la procedure exacte et la Blue dessine quelle telemetrie devrait capturer chaque etape. Ce contrat ecrit elimine le classique 'on n'a pas vu parce que Splunk n'ingerait pas cet index'. Le contrat nomme, par technique: la source de donnees attendue (Sysmon Event ID 1, 4688, 4104, un log Zeek), le champ attendu et le bruit de fond. Si la source de donnees manque, c'est deja un constat avant le premier payload. Cette repetition a sec revele reguliere ment un capteur deploye mais non collecte, ou le PowerShell Script Block Logging desactive. Ces angles morts precis sont ceux qui sauvent un incident reel plus tard.

Execution controlee dans la fenetre

L'execution se fait dans une fenetre convenue, avec un flag d'exercice dans les logs et un canal Slack #purple-live ouvert. Chaque action Red recoit un timestamp UTC, le hostname cible et le hash du binaire utilise. Quand on lance Kerberoasting via Rubeus, l'operateur note le ticket exact extrait et le compte de service cible. En parallele, l'analyste SOC tente la detection en temps reel sans savoir quelle etape arrive, simulant le scenario reel. Si capture en quatre minutes, on note vert. Si passe inapercue, ca devient un ticket Jira avec priorite definie par la criticite de l'actif touche. On tourne deliberement avec OPSEC desactive (flags bruyants, named pipes par defaut) pour que la Blue puisse voir les artefacts.

Du constat a la regle durable

Apres execution, le vrai travail commence: transformer un constat en regle durable. On convertit les hypotheses d'abord en Sigma comme source de verite neutre, puis en EQL sur Elastic et KQL sur Sentinel. Une regle n'est mergee dans main que si elle remplit trois criteres: elle couvre la technique de l'exercice, genere moins de 5 faux positifs par semaine en staging, et a un playbook de reponse lie. Les techniques d'evasion forcent l'equipe a sortir de la signature pour aller vers la detection comportementale, en surveillant les appels NtAllocateVirtualMemory, les patterns parent-child anormaux et l'acces aux handles de LSASS. Une regle sans cas de test qui la declenche de facon prouvee est consideree comme inachevee.

Infrastructure d'exercice auditable

L'infra d'exercice doit etre auditable. Le C2 tourne en VLAN isole avec capture PCAP complete, et le trafic est miroite vers le SIEM de staging via port mirror. Le mouvement lateral suit un playbook fixe avec Impacket et Evil-WinRM, toujours avec des flags bruyants pour que la Blue voie les artefacts. Le pivoting interne utilise Chisel ou Ligolo-ng sur des tunnels bien documentes. Tout est journalise dans un repo Git prive: chaque commit Red est reference par la PR de regle Blue, creant une tracabilite que les auditeurs adorent et que le manager adore montrer au board. Les snapshots des VMs avant et apres l'exercice permettent un rejeu propre quand une regle doit etre ajustee.

Metriques et langage commun

La communication tue plus de programmes Purple Team que le manque d'outils. On etablit un vocabulaire commun: 'detecte' signifie alerte generee et triee, pas juste un log present dans un index froid. Les retros durent 60 minutes avec trois diapos: techniques executees, detections livrees, dette technique ouverte. Metriques suivies: MTTD par categorie ATT&CK, pourcentage de couverture des Tactics dans l'environnement, et nombre de regles avec taux FP au-dessus du seuil. En six mois, un client est passe de 23% de couverture Credential Access a 71%, avec une baisse de 40% des alertes bruyantes. Ces chiffres sont le langage qui libere du budget.

Pieges frequents

Le premier piege est la competition: des que la Red veut 'gagner', elle arrete de jouer bruyant et la Blue n'apprend rien. Le deuxieme est la regle sans playbook qui se declenche a 3 heures du matin et ne guide personne vers l'action. Le troisieme est la regle jamais testee en staging qui produit 200 faux positifs par jour en production et se fait couper en une semaine. Le quatrieme est l'absence de versionnement: une detection qui vit seulement dans la tete d'un analyste disparait avec lui. Le cinquieme est de sauter la repetition a sec, si bien que la telemetrie manquante n'apparait qu'en pleine execution et fait exploser le sprint.

Checklist pratique

Avant le sprint: choisissez cinq techniques pertinentes pour votre secteur, signez un contrat ecrit avec le SOC, verifiez les sources de donnees par technique. Pendant le sprint: executez dans la fenetre avec un flag d'exercice et logging complet, notez chaque action avec timestamp et hash, marquez les detections en direct dans #purple-live. Apres le sprint: ecrivez la regle Sigma, traduisez-la en EQL et KQL, testez-la en staging contre le seuil de FP, liez le playbook de reponse, mergez dans Git, mesurez le MTTD. Aucun sprint n'est termine sans un seul artefact versionne. Cet artefact est exactement ce qui separe la detection continue du divertissement ponctuel.

Roles, rotation et psychologie

Le Purple Team ne fonctionne que si les roles tournent et que personne n'occupe un siege permanent de gagnant. En pratique, un analyste qui a joue Blue pendant trois sprints passe deliberement du cote Red pour sentir a quel point ses propres detections sont fragiles sous une legere variation. Cette rotation construit l'empathie et dissout la mentalite de silo ou la Red croit les defenseurs lents et la Blue croit les attaquants vantards. Le facilitateur, souvent un detection engineer, garde l'exercice honnete: pas de moments gotcha, pas de payloads caches, pas d'acharnement en retro. Quand une technique passe, c'est une lacune systemique de telemetrie, pas un echec personnel de l'analyste. Cette culture precise decide si le programme est encore vivant apres le troisieme sprint ou s'etouffe dans les reproches mutuels. Un board finance une maturation mesurable, pas une bataille de boue entre deux equipes. Traitez la relation comme une seule equipe a deux casquettes et les chiffres suivent.

Automatisation avec Atomic Red Team et CI

Une fois le cycle manuel solide, on automatise la regression. Atomic Red Team fournit des tests atomiques decrits en YAML par technique ATT&CK qui s'executent dans un pipeline contre une VM jetable. Apres chaque mise a jour de contenu du SIEM, on relance les atomics pertinents et on verifie si la regle Sigma associee se declenche toujours; si elle casse, le build echoue, exactement comme un test unitaire. Cela previent le detection drift, ou une regle qui marchait devient silencieuse parce qu'un champ a ete renomme dans le schema de logs. Les resultats atterrissent comme rapport de couverture dans le meme repo Git, versionnes a cote des regles. La frontiere compte: l'automatisation ne remplace pas l'hypothese humaine, elle protege seulement l'acquis. Les nouvelles techniques naissent toujours du threat intel et de l'emulation manuelle; la CI garantit seulement qu'aucune detection existante ne se degrade sans etre remarquee pendant que l'environnement continue d'evoluer dessous.

FAQ : A quelle frequence lancer un cycle Purple Team ?

Les sprints de deux semaines sont le point ideal pour la plupart des equipes: assez courts pour garder l'elan, assez longs pour vraiment durcir une regle jusqu'en production. Hebdomadaire epuise l'equipe et livre des detections a moitie faites; mensuel laisse la boucle de feedback perdre son tranchant. Cinq a dix techniques par sprint est realiste quand chacune se termine par une regle versionnee.

FAQ : Faut-il des outils couteux pour le Purple Team ?

Non. Sysmon avec une configuration durcie, la stack ELK ou Wazuh, Atomic Red Team pour l'execution, et Sigma pour des regles portables suffisent pour un cycle complet a cout de licence nul. Le goulot n'est jamais l'outil, c'est la discipline de fermer la boucle et de transformer chaque technique en artefact versionne.

Conclusion

Conclusion pratique: commencez petit et mesurable. Choisissez cinq techniques pertinentes pour votre secteur, redigez un contrat avec le SOC, executez en fenetre courte avec logging complet, et ne fermez pas le sprint sans regle Sigma versionnee dans Git. Un Purple Team qui ne laisse aucun artefact versionne derriere lui n'a pas passe l'echelle, il a juste diverti. Le cycle Red-construit-hypothese, Blue-valide-telemetrie, equipe-merge-regle-en-prod doit tenir en deux semaines. Si ca prend plus longtemps, vous gerez un projet, pas une detection continue. Repetez le cycle jusqu'a ce que les cellules sombres de la heatmap ATT&CK deviennent une couverture mesuree.