La purple team : faire travailler attaque et défense ensemble

Imaginez une équipe de football qui s'entraîne à attaquer dans un coin du terrain, et une autre qui s'entraîne à défendre dans l'autre coin, sans jamais se parler ni se rencontrer. Le résultat serait étrange. C'est pourtant ce qui arrive quand le red team et le blue team travaillent chacun de leur côté. La purple team (rouge + bleu) corrige cela : c'est une manière de travailler où l'attaque et la défense s'entraînent ensemble, pour améliorer la détection pas à pas.

La purple team est une méthode, pas une équipe

Contrairement à ce que le nom suggère, la purple team n'est pas forcément une équipe permanente. C'est surtout une façon de collaborer : les offensifs et les défensifs s'assoient côte à côte, partagent ce qu'ils font en temps réel et ajustent immédiatement. Le but est simple : que chaque technique d'attaque testée laisse une trace que la défense sait voir et exploiter.

Dans un exercice de red team « classique », on découvre à la fin du récit que telle action n'a déclenché aucune alerte. Dans un exercice purple, on le sait pendant l'exercice, et on corrige tout de suite, puis on rejoue pour vérifier que la correction fonctionne. Le cycle d'amélioration passe de quelques mois à quelques heures.

Le cycle de travail

Un exercice purple suit une boucle simple :

1. Choisir un comportement à tester. On le prend dans le catalogue MITRE ATT&CK (attack.mitre.org), par exemple « la découverte des comptes du domaine » ou « l'ouverture de session à distance avec un compte valide ». On préfère des comportements réalistes pour l'organisation, issus de la veille sur la menace.
2. Reproduire le comportement de manière contrôlée. L'équipe offensive l'exécute de façon sûre, limitée, avec des outils validés, et annonce l'heure exacte.
3. Observer la défense. L'équipe défensive cherche dans ses outils : le comportement a-t-il été journalisé ? Une alerte est-elle apparue ? Qu'a vu l'analyste ?
4. Améliorer. Si rien n'est visible, on identifie pourquoi : journal non activé, règle absente, alerte noyée dans le bruit. On corrige.
5. Rejouer. On répète le même comportement pour vérifier que la détection fonctionne maintenant.
6. Documenter. On consigne le résultat pour mesurer la progression au fil du temps.

Ce cycle est modeste, mais très efficace : chaque tour produit une amélioration concrète.

Un tableau de résultats

Pour rendre les résultats lisibles, on remplit un tableau par comportement testé. Un exemple fictif, dans le laboratoire d'Atelier Boréal :

Ce tableau révèle trois situations différentes, qui appellent trois traitements :

• Non journalisé : la donnée n'existe pas, il faut d'abord la produire.
• Journalisé mais sans alerte : la donnée existe, il manque la règle qui la transforme en signal.
• Alerte levée : on vérifie qu'elle est lisible, bien classée et qu'un analyste sait quoi en faire.

Les bénéfices d'une approche collaborative

• Un apprentissage mutuel : les défenseurs découvrent comment les attaquants raisonnent ; les offensifs comprennent ce que voit réellement un SOC.
• Un vocabulaire partagé : tout le monde parle en termes de comportements (ATT&CK) plutôt que d'outils.
• Des gains rapides et mesurables : chaque exercice laisse des règles de détection nouvelles ou améliorées.
• Un climat de confiance : on remplace l'image « les offensifs piègent les défensifs » par « nous travaillons ensemble contre un adversaire commun ».

Les pièges à éviter

• Tester sur la production sans précaution : on commence en laboratoire ou sur des machines de test, on documente les effets possibles, on prévoit un retour arrière.
• Mesurer le nombre de techniques testées plutôt que la qualité des améliorations obtenues : cocher des cases ne protège personne.
• Rendre l'exercice trop artificiel : une alerte qui ne se déclenche que lorsque l'on exécute exactement la commande de l'exercice est une mauvaise détection. On cherche à détecter le comportement, pas la signature d'un outil.
• Oublier l'humain : une alerte n'est utile que si quelqu'un la lit et sait quoi faire. Testez aussi les procédures.
• Ne pas rejouer : sans nouvelle exécution, on ignore si la correction marche.

Un laboratoire purple chez vous

Vous pouvez pratiquer cette méthode seul. Dans votre laboratoire isolé, jouez successivement les deux rôles : une machine « attaquante » (Kali Linux), une ou deux machines « cibles » qui produisent des journaux, et un endroit où lire ces journaux. Choisissez un comportement bénin et courant (par exemple plusieurs échecs de connexion), reproduisez-le dans le laboratoire uniquement, puis cherchez la trace laissée. Vous apprendrez en quelques soirées ce que beaucoup de professionnels mettent des années à voir : une action offensive laisse presque toujours une trace, encore faut-il savoir où la chercher.

À vous de jouer

Complétez le tableau purple ci-dessous pour trois comportements de votre choix dans votre laboratoire. Pour chacun, indiquez : le comportement, la source de journal où vous attendez de le voir, ce que vous avez effectivement observé, et l'action d'amélioration. Si vous n'avez pas encore de laboratoire opérationnel, travaillez à partir du scénario fictif suivant : « Un employé du service comptabilité, depuis son poste, tente à plusieurs reprises de se connecter à un serveur de fichiers auquel son compte n'a pas droit. »