Contrairement aux autres projets présentés ici, le README de ce dépôt est purement documentaire — schémas d'architecture et références d'API, sans captures d'interface. Les chiffres ci-dessous sont réels et proviennent directement des tests de conformité du dépôt, pas d'un argumentaire commercial.
La question à laquelle il répond
Un environnement d'émulation purple team qui rejoue de véritables playbooks d'adversaires pour répondre à la seule question qui compte : l'aurions-nous réellement détecté ? Il charge des TTP cartographiées sur ATT&CK, exécute des DAG de scénarios via un orchestrateur FastAPI et des agents de beaconing, puis exporte la couverture Sigma, des jeux de télémétrie de référence (fixtures) et des payloads prêts pour le SIEM.
Envergure du projet
Composition de la bibliothèque de scénarios
| Source | Nombre |
|---|---|
| Scénarios YAML classiques | 11 |
| Scénarios YAML générés | 2 500 |
| Scénarios de plans d'émulation (dérivés d'Atomic Red Team) | 11 |
| Scénarios de chaînes d'acteurs validés (adossés à des fixtures, avec événements SOC de référence) | 1 000 |
| Lignes d'événements SOC de référence | 2 000 |
| Espace de variantes de scénarios générables | 15 680 015 680 |
Architecture
Un scénario YAML ou une variante générée passe par un chargeur, puis par un planificateur tenant compte du DAG, avant de rejoindre une file d'exécution SQLite accompagnée d'un descripteur de tâche signé. Un agent beacon ou un exécuteur local lance la simulation de TTP enregistrée, produisant une télémétrie synthétique et des marqueurs, mappés vers Sigma/ECS/OCSF et vers des exports de requêtes SIEM. Le planificateur écrit également un journal d'audit chaîné par hachage pour chaque action, et la file suit de manière indépendante l'état de nettoyage et de relance.
Modèle de sûreté
- Paramètres de simulation (dry-run) activés par défaut pour les scénarios générés.
- Les TTP en mode marqueur uniquement produisent une télémétrie bénigne et des métadonnées de nettoyage — rien de destructeur.
- Une politique de sûreté centralisée bloque les modes à risque élevé, sauf autorisation explicite.
- L'orchestrateur dispose d'un endpoint d'arrêt d'urgence (killswitch) et d'une condition d'arrêt basée sur un fichier.
- Les URL de SIEM publiques exigent un indicateur
allow_external=trueexplicite — les URL localhost et de réseau privé du laboratoire sont autorisées par défaut, rien d'externe par inadvertance.
Préparation au déploiement en entreprise
Au-delà du moteur de simulation, le projet modélise également ce qu'exigerait son exploitation dans une organisation réelle : 11 volets de validation en laboratoire (Windows AD, parc Linux, AWS, Azure, GCP, Kubernetes, SaaS/Identité, Splunk, Elastic, Sentinel, Chronicle), 8 axes de durcissement (qualité des TTP, exploitation du parc, fidélité des imports, sandbox cloud, backends de secrets, performances, conformité, preuve publique), un RBAC OIDC/JWKS avec les rôles viewer/operator/admin, et une grille d'évaluation Platform Readiness sur 25 domaines accompagnée d'un pack de benchmark téléchargeable.
Rigueur des tests
Les tests de conformité vérifient des valeurs exactes, et non des approximations : exactement 5 064 TTP, exactement 3 522 scénarios chargés, une couverture des tactiques ATT&CK d'exactement 15/15 avec contrôle de l'état de synchronisation (drift-sync) — les chiffres du README sont éprouvés contre l'implémentation en fonctionnement, pas simplement affirmés.