« En incident, l’action la plus rapide est toujours la plus sûre. »
Un confinement peut préserver le SI ou casser une fonction critique. La décision doit mettre en regard preuve disponible, urgence, impact, autorisation et capacité de retour arrière.
01Compare les options
lab=/tmp/soria-ir-final-project-$USER
column -s, -t "$lab/source/response/containment-options.csv"Chaque option possède une cible, un impact métier, une précondition de preuve et un propriétaire d’approbation.
02Lis NOT_EXECUTED
Dans le projet final, même une option APPROVED_FOR_SIMULATION reste NOT_EXECUTED. Le lab valide la décision, pas l’action sur une machine réelle.
03Planifie l’éradication
column -s, -t "$lab/source/response/eradication-plan.csv"Chaque étape doit préciser owner, exit criteria, rollback, dépendance et statut. « Réinstaller » n’est pas un plan si l’état de confiance attendu et le retour arrière ne sont pas définis.
04Intègre le métier
Une isolation de poste d’administration ou une restriction du réseau de management peut empêcher des opérations nécessaires à la réponse. L’impact ne se résume donc pas à la disponibilité du service public.
Livrable C — note de décision
Pour les trois options de confinement, écris : bénéfice, risque, preuve préalable, impact métier, approbateur, décision et condition de réévaluation.
05Vérifie la frontière
bash module6-soria-incident-response-project.sh run "$lab"
column -s, -t "$lab/output/containment-decision.csv"
column -s, -t "$lab/output/eradication-review.csv"Le résultat doit conserver toutes les actions en NOT_EXECUTED ou PLANNED.
✓À retenir
Une réponse défensive reste gouvernée : preuve, impact, autorisation, critères de sortie et rollback sont des parties de la décision technique.