Prépare un confinement borné sans détruire les preuves

01Distingue préparation et exécution

Dans ce Lot :

APPROVED_FOR_SIMULATION ≠ EXECUTED
PLANNED ≠ APPLIED
NOT_EXECUTED = état obligatoire du confinement

Le lab ne lance ni commande firewall, ni désactivation de compte, ni isolation endpoint.

02Identifie les preuves exposées

lab=/tmp/soria-ir-lot4-$USER
column -s, -t "$lab/source/evidence/protection.csv"

Chaque action de confinement possède une exigence PRESERVE_BEFORE_ACTION.

Cette exigence est utile même si la preuve n’a pas une valeur judiciaire : elle empêche l’équipe de détruire involontairement la base technique de son raisonnement.

03Borne le blast radius

Avant une action réelle, demande :

Quelle identité ?
Quel endpoint ?
Quel segment ?
Quel indicateur ?
Quelle durée ?
Quel propriétaire ?
Quel rollback ?

Une règle générale du type « bloque tout » n’est pas une stratégie de confinement suffisamment bornée.

04Préserve la source, travaille sur une dérivation

Le principe utilisé depuis le Lot 3 reste valable :

original -> préservé
copie/rapport -> dérivé

Le confinement ne doit pas réécrire l’historique pour rendre le scénario plus propre.

05Inspecte le résultat du lab

bash module4-containment-eradication-recovery.sh run "$lab"
column -s, -t "$lab/output/evidence-protection-report.csv"
column -s, -t "$lab/output/containment-decision.csv"

Le validateur échoue si une action est déclarée EXECUTED.

06Documente ce que le lab ne prouve pas

Le lab ne démontre pas :

• qu’un endpoint a été réellement isolé ;
• qu’un compte AD a été désactivé ;
• qu’une règle OPNsense a été appliquée ;
• que des preuves ont été acquises selon une procédure forensique légale.