Modéliser la menace, et le faire tôt

Jour 1 · Modéliser la menace sur devsecops-lab · 25 min

Vous avez passé deux semaines à casser et réparer devsecops-lab : SAST, secrets, dépendances à CVE, image durcie, cluster. Vous connaissez ses dix failles par leur numéro. Le module d'aujourd'hui change de posture : au lieu de chercher des bugs un par un, vous allez raisonner sur l'architecture — les composants, les flux, les frontières — pour anticiper ce qui peut mal tourner, avant qu'un outil ne le confirme.

C'est cela, le threat modeling : un raisonnement structuré, mené tôt, sur ce qu'un attaquant pourrait faire de votre système. Il ne remplace ni le SAST ni le pentest — il les oriente. Un scanner lit le code ; un threat model lit les intentions de l'architecture, et voit des choses qu'aucun scanner ne verra jamais : une donnée sensible qui traverse une frontière sans contrôle, une hypothèse de confiance qui n'a jamais été écrite.

Les quatre questions

Adam Shostack, qui a formalisé la méthode chez Microsoft, la ramène à quatre questions. Elles sont votre fil conducteur des deux jours :

La brique de départ : le diagramme de flux de données

On ne peut pas raisonner sur des menaces sans un schéma d'accord sur ce qu'on protège. Le DFD (Data Flow Diagram) est ce schéma. Il ne connaît que quatre types d'éléments — et c'est sa force : quatre formes suffisent à décrire n'importe quel système.

Le cinquième trait n'est pas un élément mais une ligne : la frontière de confiance. Elle marque l'endroit où la donnée change de main — où elle passe d'un contexte contrôlé à un contexte qui ne l'est pas, ou l'inverse. C'est là, et presque uniquement là, que vivent les menaces. Un flux qui reste à l'intérieur d'une même zone de confiance est rarement intéressant ; un flux qui traverse une frontière l'est toujours.

La leçon suivante superpose STRIDE à ce DFD : à chaque endroit où un flux franchit une frontière, elle donne un vocabulaire pour nommer ce qui peut mal tourner.

STRIDE, posé sur devsecops-lab

Jour 1 · Modéliser la menace sur devsecops-lab · 30 min

STRIDE est une liste de contrôle : six catégories de menaces, une par lettre. Son intérêt n'est pas d'être exhaustive — elle ne l'est pas — mais d'être rapide à poser sur un DFD. Devant chaque élément et chaque flux, vous vous demandez : « et si quelqu'un faisait ça ici ? », six fois, une fois par lettre.

La clé pour ne jamais confondre les catégories : chacune est la négation d'une propriété de sécurité. Retenez la propriété, vous retrouvez la menace.

La menace qu'on oublie toujours : Repudiation

Regardez la colonne R. devsecops-lab n'écrit pratiquement aucun journal applicatif : le seul témoin des requêtes est le journal d'accès de Werkzeug. Conséquence directe : si un attaquant contourne l'authentification, vous ne pourrez pas reconstituer proprement ce qu'il a fait. Cette faiblesse ne casse rien aujourd'hui — c'est pourquoi on l'oublie — mais elle décide de tout au moment de l'incident. Vous la retrouverez lundi, quand vous jouerez une attaque sur votre propre maquette et tenterez d'en reconstruire la chronologie à partir de journaux qui n'existent qu'à moitié.

STRIDE, et les autres méthodes

STRIDE n'est pas seul. PASTA part du risque métier et remonte vers la technique ; on s'en servira demain comme grille de priorisation. LINDDUN vise la vie privée. Attack trees décomposent un objectif d'attaquant — c'est la leçon qui suit. On combine : STRIDE pour énumérer largement, l'attack tree pour approfondir un scénario qui fait peur.

Quiz — DFD, STRIDE et attack trees

Jour 1 · Modéliser la menace sur devsecops-lab · 10 min

TP 1 — Le DFD de devsecops-lab

Jour 1 · Modéliser la menace sur devsecops-lab · 55 min

Dessiner le diagramme de flux de données de votre appli, avec ses frontières de confiance, et le poser dans le rapport de threat model.

1. Placez-vous à la racine de votre dépôt et créez le rapport. Ouvrez-le par le contexte, en une phrase — c'est la réponse à « qu'est-ce qu'on construit ? » :
   copier

   cd devsecops-lab
   mkdir -p rapports
   cat > rapports/threat-model.md <<'EOF'
   # Threat model - devsecops-lab
   
   Perimetre : application Flask locale (app.py, ~130 lignes), port 5000,
   base SQLite lab.db, deployee sur localhost uniquement.
   Objet du modele : anticiper les menaces avant exploitation (M5).
   
   ## 1. Ce qu'on construit - DFD
   EOF

2. Listez d'abord, en clair, les éléments de chaque type. Ne dessinez rien encore : relisez app.py route par route et rangez chaque brique dans l'une des quatre catégories. Entités externes (client, URL tierce du /fetch), processus (Flask, le shell de /ping), dépôts (SQLite, les secrets en dur), flux (HTTP, SQL, commande shell, GET sortant).
3. Écrivez le DFD en Mermaid, dans le rapport. Les deux sous-graphes matérialisent deux zones de confiance ; l'URL tierce reste dehors. Adaptez les libellés, mais gardez les quatre flux — ce sont eux qui portent les menaces :
   copier

   ```mermaid
   flowchart LR
     U[Client / navigateur]
     subgraph serveur[Zone serveur - localhost:5000]
       F([Flask app.py])
       DB[(SQLite lab.db)]
       SH([subprocess ping - shell=True])
       SEC[/SECRET_KEY et API_KEY en dur/]
     end
     EXT[URL tierce - cible SSRF]
     U -- requete HTTP --> F
     F -- requete SQL concatenee / VULN-01 --> DB
     F -- host non filtre / VULN-03 --> SH
     F -- GET url fournie / VULN-08 --> EXT
     SEC -. clef lue / VULN-05 .-> F
   ```

4. Sous le diagramme, listez les frontières de confiance et, pour chaque flux qui en franchit une, la phrase « qui fait confiance à qui ». C'est le cœur du livrable :
   copier

   cat >> rapports/threat-model.md <<'EOF'
   
   ### Frontieres de confiance
   - FC1 reseau : Client -> Flask. Flask fait confiance a une entree HTTP non authentifiee.
   - FC2 processus : Flask -> shell. Flask fait confiance a une chaine construite depuis
     le parametre 'host' pour l'executer dans un shell.
   - FC3 donnees : Flask -> SQLite. Flask fait confiance a une requete concatenee.
   - FC4 sortant : Flask -> URL tierce. Flask fait confiance a une URL fournie par le client.
   - FC5 secret : les secrets ne devraient jamais quitter le serveur ; VULN-05 les expose
     dans la source versionnee.
   EOF

5. Vérifiez le rendu. Ouvrez rapports/threat-model.md dans l'aperçu de votre éditeur ou poussez sur une branche pour voir GitHub rendre le Mermaid. Le diagramme doit s'afficher, pas rester du texte : si c'est du texte, le bloc n'est pas ouvert par ```mermaid.
6. Committez le premier jet, sur une branche de travail (la main est protégée) :
   copier

   git checkout -b feat/threat-model
   git add rapports/threat-model.md
   git commit -m "threat model: DFD et frontieres de confiance de devsecops-lab"

TP 2 — STRIDE, élément par élément

Jour 1 · Modéliser la menace sur devsecops-lab · 1 h 25

Dérouler STRIDE sur chaque élément et chaque flux du DFD, en reliant chaque menace retenue à une VULN réelle de votre code — ou à un « aucune » assumé.

1. Ouvrez d'abord votre première passe. Vous avez fait un STRIDE de découverte le 5 août, à la fin du module 1 : il est dans rapports/stride-devsecops-lab-m1.md. Relisez-le maintenant, avant d'écrire quoi que ce soit — puis mettez-le de côté. Vous le confronterez à votre tableau du jour à la dernière étape ; c'est la seule façon de mesurer ce que trois modules d'outillage ont changé à votre regard.
   copier

   cat rapports/stride-devsecops-lab-m1.md

2. Ajoutez la section STRIDE au rapport, avec l'en-tête du tableau. Une ligne par menace retenue, rattachée à son flux et à sa VULN :
   copier

   cat >> rapports/threat-model.md <<'EOF'
   
   ## 2. Ce qui peut mal tourner - STRIDE
   
   | Element / flux | STRIDE | Menace concrete | VULN | Propriete niee | Etat |
   |---|---|---|---|---|---|
   EOF

3. Remplissez le flux Client → Flask (FC1). C'est le plus riche : presque toutes les entrées passent par là. Exemple de lignes à écrire vous-même dans le tableau :
   copier

   | Client->Flask /login | S | usurper l'admin par SQLi         | VULN-01 | Authentification | corrige M1-J3 |
   | Client->Flask /search| T | injecter du HTML rendu tel quel  | VULN-02 | Integrite        | corrige M2 |
   | Client->Flask /profile| I| lire le profil d'un autre (IDOR) | VULN-04 | Confidentialite  | ouvert |
   | Client->Flask (tous)  | R| aucun journal applicatif exploitable | -   | Tracabilite      | ouvert |

4. Déroulez maintenant les autres flux du DFD, un par un, et couvrez le reste des VULN. Chaque flux du TP1 doit produire au moins une ligne : Flask → shell (E/D, VULN-03), le flux /config vers le parseur YAML (E, VULN-07, déséralisation), Flask → URL tierce (I, VULN-08, SSRF), Flask → SQLite (T, VULN-01), secrets → Flask (I, VULN-05), et le hachage md5 de /hash (I, VULN-06).
5. Traitez explicitement les cases vides. Ajoutez sous le tableau deux ou trois décisions de non-menace, argumentées — c'est ce qui prouve que vous avez réfléchi plutôt que rempli :
   copier

   cat >> rapports/threat-model.md <<'EOF'
   
   ### Cases laissees vides, et pourquoi
   - Spoofing sur Flask->SQLite : ecarte, la base ne porte pas d'identite a usurper ;
     la menace est en amont, sur la construction de la requete.
   - Denial of service sur secrets->Flask : ecarte, ce flux est interne et n'expose
     pas de surface reseau.
   EOF

6. Relisez avec l'oeil de l'attaquant de M5 : chaque VULN-01 à VULN-10 doit apparaître au moins une fois dans la table ou dans les cases vides argumentées. Cochez-les sur la table des dix vulnérabilités. S'il en manque une, c'est un flux oublié au DFD — retournez au TP1.
7. Reprenez maintenant votre passe du 5 août et comparez-la ligne à ligne avec celle du jour. Écrivez trois lignes de plus au rapport : ce que vous aviez vu et qui tient, ce que vous aviez manqué, et ce que vous aviez surestimé. La question utile n'est pas « ai-je progressé » mais « qu'est-ce qui, dans ce que j'ai appris depuis, m'a fait voir cette ligne-là ».
   copier

   cat >> rapports/threat-model.md <<'EOF'
   
   ### Ecart avec la premiere passe (stride-devsecops-lab-m1.md, 5 aout)
   - Tenu :
   - Manque a l'epoque :
   - Surestime a l'epoque :
   EOF

8. Committez :
   copier

   git add rapports/threat-model.md
   git commit -m "threat model: table STRIDE reliee aux VULN-01..10"

Attack trees : décomposer un objectif

Jour 1 · Modéliser la menace sur devsecops-lab · 20 min

STRIDE énumère largement. L'attack tree fait l'inverse : il part d'un objectif d'attaquant et le décompose en sous-objectifs, jusqu'à des actions concrètes. Là où STRIDE demande « qu'est-ce qui peut mal tourner partout ? », l'arbre demande « de combien de façons peut-on atteindre ce but précis ? ».

La structure

• La racine est l'objectif de l'attaquant. Elle doit être mesurable : « exécuter une commande arbitraire sur le serveur », pas « pirater l'appli ».
• Les nœuds intermédiaires sont des sous-objectifs.
• Un nœud OR est atteint dès qu'un de ses enfants l'est. Un nœud AND exige que tous ses enfants le soient.
• Les feuilles sont des actions concrètes — chez vous, des VULN avec leur charge d'exploitation.

La leçon de l'arbre est visuelle : sous une racine reliée par un OR, il suffit d'un seul chemin pour gagner. Corriger une branche ne protège de rien tant qu'une autre reste ouverte. C'est exactement le cas de devsecops-lab, où plusieurs failles indépendantes mènent au même résultat — l'exécution de code.

Chaque feuille peut porter une étiquette : coût, probabilité, compétence requise. On reste qualitatif aujourd'hui. Demain, CVSS et DREAD donneront des chiffres à ces feuilles, et l'arbre deviendra un outil de priorisation.

TP 3 — Un attack tree vers l'exécution de code

Jour 1 · Modéliser la menace sur devsecops-lab · 55 min

Construire l'arbre d'attaque de l'objectif le plus grave, avec des feuilles qui sont des exploits réels de vos VULN.

1. Ajoutez la section attack tree au rapport et posez la racine. Choisissez un objectif mesurable :
   copier

   cat >> rapports/threat-model.md <<'EOF'
   
   ## 3. Un scenario approfondi - attack tree
   
   Objectif racine : executer une commande arbitraire sur le serveur devsecops-lab.
   EOF

2. Écrivez l'arbre en Mermaid. Notez le nœud OU à la racine (quatre chemins indépendants) et le nœud ET sous « détourner la confiance » (voler le secret et savoir signer un cookie) :
   copier

   ```mermaid
   flowchart TD
     G[But: executer une commande arbitraire sur le serveur]
     G --> OU{OU}
     OU --> C[Injecter une commande shell]
     OU --> D[Injecter un objet deserialise]
     OU --> B[Contourner l'authentification puis fonctions admin]
     OU --> T[Detourner la confiance de session]
     C --> C1[VULN-03: /ping?host=127.0.0.1;id]
     D --> D1[VULN-07: POST /config payload !!python/object/apply:os.system]
     B --> B1[VULN-01: user=admin'-- and pwd=x]
     T --> ET{ET}
     ET --> T1[VULN-05: lire SECRET_KEY dans la source]
     ET --> T2[forger un cookie de session signe avec cette clef]
   ```

3. Sous l'arbre, expliquez en deux lignes pourquoi la racine est un OU : quatre chemins indépendants y mènent, donc corriger une seule branche ne ferme pas l'objectif. C'est la conclusion opérationnelle de l'arbre.
   copier

   cat >> rapports/threat-model.md <<'EOF'
   
   Lecture : la racine est un OU. Fermer VULN-03 seule laisse VULN-07, VULN-01 et le
   detournement de session ouverts. Il faut traiter les quatre branches, pas une.
   La branche 'session' est un ET : voler la clef ne suffit pas sans savoir signer.
   EOF

4. Vérifiez que chaque feuille porte une charge exécutable, pas une catégorie. Relisez : /ping?host=127.0.0.1;id, la charge YAML, user=admin'--. Si une feuille ne se termine pas par quelque chose que vous pourriez taper, décomposez-la encore.
5. Committez :
   copier

   git add rapports/threat-model.md
   git commit -m "threat model: attack tree vers l'execution de code"

Noter une faille : CVSS v3.1

Jour 1 · Modéliser la menace sur devsecops-lab · 25 min

« Cette faille est grave » n'est pas une note. CVSS v3.1 (Common Vulnerability Scoring System) transforme une appréciation en un nombre de 0 à 10, calculé à partir de huit métriques. Son intérêt n'est pas le chiffre seul mais le vecteur qui l'explique : une chaîne comme CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H dit pourquoi le score vaut 9.8, et permet à un tiers de refaire le calcul.

Le référentiel de ce parcours l'impose : chaque finding de votre rapport de pentest (M5) et de votre audit (PFR) portera son vecteur complet, pas seulement sa bande. On apprend donc à le construire ici, sur vos propres failles.

Les huit métriques du Base score

Les bandes de sévérité — CVSS v3.1

Le cas de référence : l'injection SQL de /login

Déroulons VULN-01, métrique par métrique. C'est le vecteur donné en modèle par le référentiel, et celui que vous justifierez au TP suivant :

• AV:N — exploitable par une simple requête HTTP à distance.
• AC:L — aucune condition particulière ; la charge marche à tous les coups.
• PR:N — aucun privilège requis : la route est publique.
• UI:N — aucune action de la victime n'est nécessaire.
• S:U — l'impact reste dans le composant attaqué (l'appli et sa base).
• C:H / I:H / A:H — lecture, modification et destruction de la base sont toutes possibles.

Résultat : CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 9.8, Critical.

On n'utilise que le Base score : c'est le seul comparable d'une organisation à l'autre. Les scores Temporal (maturité de l'exploit) et Environmental (votre contexte) existent, mais ne se partagent pas — on les laisse de côté.

TP 4 — Noter vos failles en CVSS

Jour 1 · Modéliser la menace sur devsecops-lab · 55 min

Calculer, à la main puis avec le calculateur officiel, le vecteur et le score CVSS de trois de vos failles, et vérifier que la note reflète bien l'écart de gravité.

1. Ajoutez la section « findings notés » au rapport :
   copier

   cat >> rapports/threat-model.md <<'EOF'
   
   ## 4. Ce qu'on en fait - priorisation CVSS
   
   | VULN | Vecteur CVSS v3.1 | Score | Bande |
   |---|---|---|---|
   EOF

2. Notez d'abord VULN-01 (SQLi) sans regarder le modèle : posez les huit métriques une par une en vous justifiant à voix haute, puis lisez le score. Vous devez retomber sur le vecteur de référence :
   copier

   | VULN-01 | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H | 9.8 | Critical |

3. Notez maintenant VULN-02 (XSS réfléchi). Attention aux deux métriques qui la distinguent : UI:R (la victime doit ouvrir un lien piégé) et S:C (le code s'exécute dans son navigateur, hors du serveur). Impacts partiels : C:L / I:L / A:N. Vérifiez que vous obtenez bien 6.1 :
   copier

   | VULN-02 | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N | 6.1 | Medium |

4. Notez enfin VULN-03 (injection de commande). Raisonnez seul, puis comparez : elle s'attaque par le réseau, sans privilège ni interaction, et donne l'exécution de code — donc un impact total. Elle doit retomber au niveau de la SQLi :
   copier

   | VULN-03 | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H | 9.8 | Critical |

5. Écrivez, sous le tableau, une phrase qui explique l'écart entre l'XSS et les deux autres. C'est la trace que vous avez compris, pas seulement calculé :
   copier

   cat >> rapports/threat-model.md <<'EOF'
   
   L'XSS (6.1) est plus basse que la SQLi et l'injection de commande (9.8) parce qu'elle
   exige une action de la victime (UI:R) et n'atteint que partiellement C et I, sans A.
   Elle deborde en revanche du serveur (S:C), ce qui l'empeche de tomber plus bas.
   EOF

6. Committez :
   copier

   git add rapports/threat-model.md
   git commit -m "threat model: notation CVSS de VULN-01, VULN-02, VULN-03"

TP 5 — Boucler le threat model

Jour 1 · Modéliser la menace sur devsecops-lab · 40 min

Assembler et relire threat-model.md pour qu'il tienne debout seul, sans votre code sous les yeux — c'est le livrable que le point de contrôle exige.

1. Ajoutez un résumé exécutif en tête du rapport (juste après le titre) : trois phrases qu'un décideur non technique comprend. Combien de failles, la plus grave, l'état général :
   copier

   # Threat model - devsecops-lab
   
   > Resume : 10 failles modelisees, dont 3 Critical (SQLi, injection de commande,
   > deserialisation). L'objectif d'attaque le plus grave - executer du code - est
   > atteignable par 4 chemins independants. Faiblesse structurelle : absence de
   > journalisation exploitable (Repudiation), qui compromet toute reponse a incident.

2. Relisez en croisant les sections. Chaque VULN citée dans le DFD ou l'attack tree apparaît-elle dans la table STRIDE ? Les trois failles notées en CVSS sont-elles les plus graves de STRIDE ? Corrigez les écarts — c'est le vrai travail de ce TP.
3. Faites le test du lecteur sans code : reprenez la ligne VULN-01 et vérifiez que, sans ouvrir app.py, on comprend où est la faille, comment la déclencher, et pourquoi elle vaut 9.8. Ajoutez la charge d'exploitation si elle manque.
4. Vérifiez une dernière fois le rendu des deux diagrammes Mermaid dans l'aperçu, puis poussez la branche :
   copier

   git add rapports/threat-model.md
   git commit -m "threat model: resume executif et relecture croisee"
   git push -u origin feat/threat-model

M4 · J1 — DFD, STRIDE et attack tree sur devsecops-lab

Jour 1 · Modéliser la menace sur devsecops-lab · 30 min

Du modèle au registre de risques

Jour 2 · Du risque à l'incident rejoué · 30 min

Vous savez noter une faille. Noter une faille n'est pas gérer un risque. CVSS vous dit « cette injection SQL vaut 9.8 dans l'absolu » ; le registre de risques répond à la question que se pose vraiment une organisation : « compte tenu de notre contexte, qu'est-ce qu'on en fait, qui s'en occupe, et pour quand ? ».

Le registre reprend donc la note CVSS, mais y ajoute ce que CVSS ignore volontairement — parce que CVSS se veut comparable entre organisations, et que votre contexte ne l'est pas.

DREAD — une grille complémentaire, jamais un remplacement

DREAD cote cinq dimensions, chacune de 1 à 3 ici (faible, moyen, fort). Son total, de 5 à 15, sert à départager deux risques que CVSS place au même niveau — pas à remplacer CVSS, qui reste la note de référence du parcours.

Les quatre traitements — et le faux cinquième

• Mitiger — corriger, ou réduire la probabilité ou l'impact. Le cas général.
• Accepter — décider, en connaissance de cause et par écrit, de vivre avec. Une acceptation a toujours un propriétaire et une raison.
• Transférer — faire porter le risque par un tiers (assurance, prestataire). Le risque ne disparaît pas, il change de porteur.
• Éviter — supprimer la fonctionnalité qui porte le risque. Radical, parfois juste.

« Ignorer » n'est pas dans la liste. Ignorer, c'est accepter sans le documenter — et c'est précisément ce qu'un audit relève. Toute ligne de votre registre portera donc un traitement explicite, jamais un blanc.

Quiz — CVSS, DREAD et gestion du risque

Jour 2 · Du risque à l'incident rejoué · 10 min

TP 6 — Le registre de risques

Jour 2 · Du risque à l'incident rejoué · 1 h

Construire risk-register.csv : les dix VULN, leur note CVSS, une cote DREAD, un traitement décidé et un propriétaire.

1. Créez le fichier avec son en-tête. Une colonne par information ; les vecteurs CVSS ne contiennent pas de virgule, ce qui garde le CSV propre :
   copier

   cat > rapports/risk-register.csv <<'EOF'
   id,titre,composant,cwe,owasp,stride,cvss_vecteur,cvss_score,cvss_bande,dread,traitement,statut,module,proprietaire
   EOF

2. Ajoutez les premières lignes. Reprenez les vecteurs calculés hier pour VULN-01/02/03 ; notez que VULN-01 et VULN-02 sont déjà corrigées (statut), et servez-vous de DREAD pour départager les deux 9.8 :
   copier

   cat >> rapports/risk-register.csv <<'EOF'
   VULN-01,Injection SQL login,POST /login,CWE-89,A03,Spoofing,CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H,9.8,Critical,15,mitiger,corrige,M1-J3,Elie
   VULN-02,XSS reflechi,GET /search,CWE-79,A03,Tampering,CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N,6.1,Medium,9,mitiger,corrige,M2,Elie
   VULN-03,Injection de commande,GET /ping,CWE-78,A03,Elevation,CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H,9.8,Critical,13,mitiger,corrige,M2,Elie
   EOF

3. Complétez les sept lignes restantes (VULN-04 à VULN-10) vous-même, en vous appuyant sur la table des dix vulnérabilités du parcours pour le CWE, l'OWASP et le module de correction. Calculez chaque vecteur CVSS comme hier. Repères : IDOR (VULN-04) et SSRF (VULN-08) sont encore ouvertes, elles ne seront traitées qu'en M5 ; les CVE des dépendances (VULN-10) relèvent de la SCA de M2.
4. Décidez un traitement pour chaque ligne, et justifiez au moins une acceptation. Sur une maquette locale, certaines menaces (par exemple l'absence de rate-limiting, ou une faille sur une route jamais exposée) peuvent être acceptées avec raison — à condition de l'écrire. Ajoutez ces justifications dans un fichier compagnon :
   copier

   cat > rapports/risk-register-decisions.md <<'EOF'
   # Decisions de traitement - justifications
   
   - VULN-XX : ACCEPTEE. Motif : route non exposee sur la maquette locale, impact nul
     hors localhost. Proprietaire : Elie. A revoir si l'appli est exposee.
   EOF

5. Vérifiez que le CSV est bien formé — dix lignes de données, aucune virgule parasite :
   copier

   column -s, -t rapports/risk-register.csv | less -S
   # ou ouvrez-le dans un tableur ; toutes les colonnes doivent s'aligner

6. Committez le registre et ses justifications :
   copier

   git add rapports/risk-register.csv rapports/risk-register-decisions.md
   git commit -m "risk register: 10 VULN notees, traitees et attribuees"

Répondre à un incident

Jour 2 · Du risque à l'incident rejoué · 30 min

Un threat model dit ce qui peut arriver. La réponse à incident traite ce qui arrive. Les deux se répondent : un incident bien géré part toujours d'une préparation faite à froid — les journaux qu'on a pensé à collecter, les playbooks qu'on a écrits avant d'en avoir besoin. C'est la quatrième question de Shostack retournée : « a-t-on fait du bon travail ? » se vérifie le jour où quelqu'un attaque.

Les quatre phases (NIST SP 800-61)

1. Préparation. Avant tout incident : journalisation en place, playbooks écrits, rôles connus, sauvegardes. C'est la phase qui décide du succès des trois autres.
2. Détection et analyse. Repérer qu'il se passe quelque chose, comprendre quoi, jusqu'où. Sans journaux, cette phase est aveugle.
3. Confinement, éradication et reprise. Arrêter la propagation, retirer la cause, puis remettre en service sans revenir à l'état vulnérable.
4. Activité post-incident. Ce qu'on a appris, ce qu'on change. La boucle qui évite la répétition.

Ce qu'est un playbook

Un playbook n'est pas un cours : c'est une procédure faite pour être suivie sous pression, par quelqu'un qui n'a pas le temps de réfléchir. D'où sa forme : un déclencheur clair, des étapes numérotées, des décisions binaires (« si le secret a été poussé sur GitHub → le révoquer immédiatement »), et pas de prose. Vous en écrirez un au TP suivant, puis vous le suivrez pour de vrai dans la simulation.

TP 7 — Écrire un playbook

Jour 2 · Du risque à l'incident rejoué · 55 min

Rédiger un playbook de réponse à incident suivant les six étapes PICERL, pour un scénario tiré de vos propres failles.

1. Créez le playbook et posez son en-tête : déclencheur, périmètre, gravité attendue. Le déclencheur doit être sans ambiguïté :
   copier

   cat > rapports/playbook-secret-expose.md <<'EOF'
   # Playbook - secret expose dans le depot (VULN-05)
   
   Declencheur : Gitleaks (pre-commit ou CI) signale un secret, OU une clef en clair
   est reperee dans la source / l'historique.
   Perimetre : depot devsecops-lab. Gravite : elevee (un secret pousse est compromis).
   EOF

2. Écrivez les six sections PICERL, à l'impératif, avec des décisions binaires. Voici la trame ; complétez chaque étape avec la commande exacte :
   copier

   cat >> rapports/playbook-secret-expose.md <<'EOF'
   
   ## 1. Preparation (a froid, deja en place)
   - Hook Gitleaks en pre-commit + job 'secrets' en CI (M1).
   - .gitignore couvre .env ; .env.exemple versionne a vide.
   
   ## 2. Identification
   - [ ] Confirmer : quel secret, quelle valeur, depuis quel commit ?
         git log -p -S '<fragment_du_secret>' -- <fichier>
   - [ ] Le secret a-t-il ete POUSSE sur le distant ? (si oui -> compromis definitif)
   
   ## 3. Containment
   - [ ] Si pousse : considerer la clef comme publique des maintenant.
   - [ ] Bloquer la fuite en cours : ne plus committer ; geler la branche.
   
   ## 4. Eradication (deux gestes distincts, dans cet ordre)
   - [ ] REVOQUER la clef chez le fournisseur (elle ne doit plus rien valoir).
   - [ ] PURGER l'historique : git filter-repo --invert-paths --path <fichier>
         (ou BFG) ; retirer la valeur du code, la remplacer par une variable d'env.
   
   ## 5. Recovery
   - [ ] Re-scanner : gitleaks detect --no-git ; doit ne rien trouver.
   - [ ] Emettre une NOUVELLE clef, la stocker hors du depot (.env non versionne).
   - [ ] Forcer le re-clone chez les collaborateurs (l'historique a change).
   
   ## 6. Lessons learned
   - [ ] Pourquoi le hook n'a pas bloque ? (installe ? contourne par --no-verify ?)
   - [ ] Consigner l'incident dans journal-incidents.md.
   EOF

3. Relisez avec l'oeil de quelqu'un sous pression : chaque case à cocher est-elle une action unique et sans ambiguïté ? Réécrivez toute étape qui contient un « il faudrait » ou un « selon le cas » sans dire lequel.
4. Committez le playbook :
   copier

   git add rapports/playbook-secret-expose.md
   git commit -m "playbook: reponse au secret expose (VULN-05), forme PICERL"

TP 8 — Jouer l'incident sur votre maquette

Jour 2 · Du risque à l'incident rejoué · 1 h 10

Rejouer une attaque réelle sur votre propre devsecops-lab, la détecter dans les journaux, appliquer le cadre de réponse et reconstruire la chronologie — en mesurant ce que l'absence de journalisation vous coûte.

1. Déployez la version vulnérable de l'appli — l'incident n'a pas de sens sur le code corrigé. Utilisez l'image :dev construite en M1, ou revenez au commit d'avant-correction sur une branche jetable :
   copier

   docker run -d --name lab-incident --network dso-net -p 5000:5000 devsecops-lab:dev
   # alternative : git checkout -b incident-demo <commit_avant_fix_VULN-01>

2. Dans un terminal, suivez les journaux du conteneur — c'est votre unique source d'analyste. Laissez-le ouvert :
   copier

   docker logs -f lab-incident

3. Casquette attaquant. Rejouez la charge SQLi de votre attack tree contre votre propre appli. Notez l'heure exacte :
   copier

   date +%H:%M:%S
   curl -s -X POST http://localhost:5000/login --data "user=admin'--&pwd=x"
   # reponse attendue : bienvenue (HTTP 200) sans mot de passe valide

4. Enchaînez une deuxième action pour épaissir l'incident : lisez un profil (IDOR, VULN-04) ou testez la commande (VULN-03). Notez encore l'heure :
   copier

   curl -s http://localhost:5000/profile/1
   curl -s "http://localhost:5000/ping?host=127.0.0.1;id"

5. Casquette analyste. Vous n'avez que le terminal des journaux. Sans vous servir de ce que vous savez, reconstruisez ce que les logs permettent d'affirmer : quelles requêtes, à quelle heure, quel code de retour. Écrivez cette chronologie dans un rapport d'incident :
   copier

   cat > rapports/incident-2026-08-17.md <<'EOF'
   # Incident (exercice) - 2026-08-17
   
   ## Chronologie reconstruite depuis les seuls journaux
   | Heure | Ce que le journal montre | Ce qu'il ne montre PAS |
   |-------|--------------------------|------------------------|
   | hh:mm | POST /login -> 200       | le corps : la charge d'injection est invisible |
   | hh:mm | GET /profile/1 -> 200    | si d'autres id ont ete enumerees |
   | hh:mm | GET /ping -> 200         | la commande reellement executee |
   EOF

6. Faites l'inventaire du manque. Sous la table, listez les questions auxquelles vous ne pouvez pas répondre avec les journaux actuels, et reliez-les à la case Repudiation de votre threat model :
   copier

   cat >> rapports/incident-2026-08-17.md <<'EOF'
   
   ## Ce que l'access log ne permet pas de conclure
   - Impossible de prouver la charge SQLi : le corps du POST n'est pas journalise.
   - Impossible de savoir quelles donnees ont ete lues (pas de log applicatif).
   - Lien direct avec STRIDE-Repudiation (threat-model.md, section 2).
   
   ## Recommandation
   Journalisation applicative structuree au niveau des routes (qui, quoi, resultat),
   distincte de l'access log Werkzeug. Sans elle, la detection reste aveugle.
   EOF

7. Appliquez, pour la forme, la fin du cycle : l'éradication de VULN-01 a déjà eu lieu en M1-J3 (requête paramétrée). Vérifiez-le en rejouant la charge sur la version corrigée, qui doit renvoyer 401 — c'est votre étape de reprise. Puis arrêtez le conteneur d'incident :
   copier

   docker stop lab-incident && docker rm lab-incident

8. Consignez l'incident dans le journal du dépôt et committez :
   copier

   git add rapports/incident-2026-08-17.md
   git commit -m "incident (exercice): SQLi rejouee, chronologie et angle mort de journalisation"

TP 9 — Boucler les livrables du module

Jour 2 · Du risque à l'incident rejoué · 45 min

Rendre cohérents et rejouables les trois livrables du module — threat model, registre, playbook et incident — avant la revue de fin de module.

1. Passe de cohérence. Vérifiez, VULN par VULN, que le threat model et le registre s'accordent : même score CVSS, même statut. Vérifiez que l'incident rejoué (SQLi) et le playbook renvoient à des menaces présentes dans le threat model. Corrigez les écarts.
2. Mettez à jour journal-incidents.md : ajoutez la ligne de l'exercice d'aujourd'hui (symptôme, cause, correction, temps). Le journal est la mémoire du dépôt, il doit refléter la simulation.
   copier

   # ajoutez une ligne au tableau existant, par exemple :
   # | 2026-08-17 | SQLi rejouee en exercice | access log insuffisant | reco journalisation applicative | 0 |

3. Complétez reponses-reflexion.md : une section par TP du module, la question recopiée, votre réponse en trois à cinq lignes. C'est là que Samer puisera ses questions cet après-midi.
4. Ouvrez la Pull Request vers main. La branche est protégée : la PR est le seul chemin, et elle déclenche les cinq jobs que vous avez construits depuis le 3 août — secrets et sast (M1), sca et dast (M2), image (M3). Vérifiez qu'ils passent tous au vert :
   copier

   git add -A
   git commit -m "M4: alignement des livrables, journal et reflexions a jour"
   git push
   # puis ouvrez la PR feat/threat-model -> main sur GitHub

M4 · Bilan — Threat model, registre de risques et incident rejoué

Jour 2 · Du risque à l'incident rejoué · 2 h