~15 minutes
Cet article fait partie de la série MITRE ATT&CK en pratique. Retrouvez la vue d’ensemble et le sommaire complet sur la page d’entrée de la série.
Maintenant que nous avons vu ce qu’etaient ces reférentiels, essayons de répondre à la question suivante : comment on intègre tout ça dans un pipeline DevSecOPS existant, sans refondre l’organisation et sans ajouter six mois ?
La réponse peut etre courte : quatre phases, en commençant par ce qui a le plus d’impact et en construisant progressivement la couverture.
ATT&CK n’est pas une checklist qu’on remplit une fois. C’est un processus continu de cartographie des menaces et de validation des contrôles ; qui doit s’intégrer dans le cycle de développement, pas s’y ajouter comme une couche externe.
Note du PandaRedacteur : La question que j’entends le plus souvent c’est “par où on commence ?” La réponse honnête : par le threat model. Pas par les outils, pas par les règles SIEM. Identifier les groupes qui ciblent votre secteur, extraire leurs techniques, construire une couverture ciblée. Tout le reste découle de là.
Les quatre phases d’intégration
graph LR
P1["📐 Phase 1 Threat Model
ATT&CK-driven"] --> P2["🔧 Phase 2 Shift Left
Sécurité dans le code"]
P2 --> P3["🚀 Phase 3
Pipeline CI/CDGates ATT&CK"]
P3 --> P4["🔍 Phase 4
Detection & Couverture"]
style P1 fill:#e3f2fd,stroke:#1976d2
style P2 fill:#e8f5e9,stroke:#2e7d32
style P3 fill:#fff3e0,stroke:#e65100
style P4 fill:#f3e5f5,stroke:#6a1b9a
Phase 1 : Threat modeling ATT&CK-driven
Commencer systématiquement par le threat model, avant toute ligne de code, parce que c’est là que l’effort est le plus efficace. Corriger une faille de conception en phase de développement coûte 10x moins qu’en production.
Rappel d’un processus de Threat Model:
- Quels actifs sont critiques dans ce composant ? (données, modèle, credentials, pipeline de déploiement)
- Quels groupes d’attaquants ciblent notre secteur, et quelles sont leurs techniques préférées ?
- Pour chaque technique identifiée, quel est le contrôle dans notre architecture actuelle ?
- Où sont les problemes ?
La réponse à la question 2 vient directement d’ATT&CK : on filtre les groupes par secteur industriel, on extrait l’union de leurs techniques, on pondère par fréquence d’utilisation.
Pour une application IA, on ajoute ATLAS comme couche supplémentaire : on parcourt les 11 tactiques ATLAS et on répond à chaque fois si notre architecture est exposée.
Phase 2 : Shift Left, sécurité dans le code
Je distingue deux niveaux de shift left dans l’intégration ATT&CK :
Niveau développeur (pre-commit) : les hooks pre-commit détectent les patterns qui facilitent les techniques ATT&CK courantes avant même que le code arrive en revue. Des exemples concrets :
detect-secretspour les credentials hardcodés (T1552.001)banditpour les vulnérabilités Python (T1190 : injection, deserialization)semgrepavec des règles alignées sur les CWE qui mappent à des techniques ATT&CK
Niveau revue de code : une checklist ATT&CK pour les revues de code sur les composants sensibles. Pas exhaustive ; ciblée sur les techniques les plus probables selon le threat model :
| Composant | Techniques à vérifier | Questions de revue |
|---|---|---|
| Authentification | T1078, T1556 | Rate limiting ? Logs d’échec ? MFA ? |
| Upload de fichiers | T1190, T1505 | Validation MIME ? Exécution impossible ? |
| Traitement de données externes | T1059, T1203 | Désérialisation sécurisée ? Sandbox ? |
| Configuration LLM | AML.T0051 | Guardrails actifs ? Logging des prompts ? |
Phase 3 : Pipeline CI/CD avec gates ATT&CK
Je structure le pipeline en cinq étapes avec des gates explicites. Chaque gate bloque le déploiement si un risque ATT&CK de niveau critique n’est pas adressé.
graph TD
A["📝 Commit"] --> B["🔍 SAST T1190, T1552"]
B --> C{" ?"}
C -->|"Non"| FAIL1["❌ "]
style FAIL1 fill:#ffebee,stroke:#b71c1c
....
...
Gate 1 : SAST : Gate 2 : Signature d’image : Gate 3 : Scan de vulnérabilités : Gate 4 : Tests dynamiques :
Note du PandaRedacteur : Le gate le plus souvent sabré en urgence de livraison, c’est Gate 4. “On le passera à la prochaine release.” Cette phrase, je l’ai entendue dans presque toutes les équipes. Et c’est exactement comme ça que T1190 finit en incident de prod un vendredi soir.
Phase 4 : Détection et couverture en production
La phase 4 est la plus longue à construire, mais c’est elle qui donne la mesure réelle de l’efficacité du programme ATT&CK.
Couverture de détection : pour chaque technique ATT&CK prioritaire (celles du threat model), une règle de détection doit exister dans le SIEM. On utilise ATT&CK Navigator pour visualiser la couverture et identifier les gaps.
Règles Sigma exportables : le format Sigma permet d’écrire une règle une fois et de l’exporter vers Splunk, Elastic, Sentinel, QRadar. La communauté SigmaHQ maintient des centaines de règles tagguées par technique ATT&CK.
Dashboard de couverture (indicateurs clés) :
- % de techniques ATT&CK prioritaires couvertes par au moins une règle de détection
- Nombre de règles par tactique (identifier les angles morts)
- Temps moyen de détection (MTTD) par technique
- Taux de faux positifs par règle
Ce contenu représente de nombreuses heures de travail, d'expérience etc... J'ai remarqué que mon contenu était repris par certaines sociétés/personnes et j'ai donc décidé de donner du contenu minimal sur ce blog. C'est pourquoi je vous invite a me contacter sur LinkedIn en mentionnant cet article pour plus d'informations.
- ✓ Le threat model ATT&CK-driven en phase de conception est le contrôle le plus rentable : une lacune architecturale repérée avant le code ne devient jamais un incident de prod.
- ✓ Les gates CI/CD ATT&CK bloquent les régressions de sécurité avant le déploiement : SAST + signature d'image + scan de vulnérabilités sont les trois gates minimaux.
- ✓ Les règles Sigma tagguées ATT&CK permettent de construire une couverture de détection mesurable et exportable vers tous les SIEM du marché.
- ✓ Pour les applications IA : ATLAS ne remplace pas ATT&CK Enterprise ; ce sont deux couches, pas deux alternatives. Prompt injection, data poisoning et model theft n'apparaissent pas dans ATT&CK ; les ignorer parce qu'ils ne figurent pas dans la matrice principale est une erreur courante.
Sur le terrain, la phase 1 est celle qu'on saute le plus souvent. C'est aussi celle qu'on regrette le plus.