Gère écarts, exceptions, contrôles compensatoires et dérive

L’idée reçue

« Une exception approuvée supprime l’écart. »

L’écart reste réel. L’exception change temporairement son traitement, avec une portée, un propriétaire, une échéance, une revue et éventuellement un contrôle compensatoire.

01Commence par l’écart

lab=/tmp/soria-hardening-assurance-project-$USER
bash module6-soria-hardening-project.sh setup "$lab"
column -s, -t "$lab/source/exceptions/gaps.csv"

Le registre décrit ce qui manque par rapport à l’exigence cible. Le Lot 6 conserve volontairement des écarts de preuve réelle pour Windows/AD, OPNsense/WireGuard et Kubernetes.

02Ne confonds pas écart et blocker

Un écart medium avec remédiation planifiée peut conduire à READY_WITH_ACTIONS. Un échec d’un contrôle critique, d’une restauration ou d’un rollback doit conduire à BLOCKED.

Le statut ne vient donc pas du nombre d’écarts mais de leur gravité, de leur traitement et de la preuve disponible.

03Borne l’exception

column -s, -t "$lab/source/exceptions/exceptions.csv"

Une exception active exige raison, approbateur, propriétaire, date de début, expiration et revue. Le lab compare les dates à sa date de référence et refuse une exception active déjà expirée ou non revue.

04Ajoute un contrôle compensatoire

column -s, -t "$lab/source/exceptions/compensating-controls.csv"

Le contrôle compensatoire ne doit pas être une promesse. Il référence un test et une preuve, possède un propriétaire et doit être marqué EFFECTIVE pour les fixtures de référence.

Exemple : lorsque l’exécution réelle de certaines mesures Windows n’est pas encore observée, un chemin d’administration restreint et une revue des administrateurs peuvent réduire temporairement le risque, sans prétendre remplacer le contrôle cible.

05Surveille la dérive

column -s, -t "$lab/source/exceptions/drift.csv"

La dérive compare baseline attendue et état représenté. Un écart ouvert doit avoir une action et une date de revue. Une dérive ACCEPTED sans exception active correspondante est incohérente.

06Provoque les erreurs utiles

bash module6-soria-hardening-project.sh run "$lab"
awk -F, '$1=="NEG-05" || $1=="NEG-06" || $1=="NEG-07" || $1=="NEG-08"' \
  "$lab/output/negative-test-report.csv"

Le lab bloque successivement : écart sans propriétaire, exception expirée/non approuvée, contrôle compensatoire inefficace et dérive en retard.

07Relie l’exception à la décision

cat "$lab/output/decision-rationale.csv"
cat "$lab/output/final-decision.txt"

READY_WITH_ACTIONS signifie ici : dossier cohérent, contrôles synthétiques vérifiés, mais preuves réelles encore attendues. L’exception ne transforme jamais une fixture en preuve d’exploitation.

08Prépare la revue

Pour chaque exception, l’apprenant doit pouvoir répondre :

quelle exigence n’est pas satisfaite ?
quel risque demeure ?
qui accepte temporairement ce risque ?
quel contrôle compensatoire réduit l’exposition ?
comment son efficacité est-elle testée ?
quand l’exception expire-t-elle ?
quelle action permet de la fermer ?

09Vérifie que la preuve reste bornée

cat "$lab/output/proof-boundaries.md"
column -s, -t "$lab/source/assurance/real-evidence-required.csv"

Une exception de preuve réelle doit rester visible. Elle ne doit pas disparaître lors de la synthèse ou de la présentation au décideur.

10Nettoie l’environnement

bash module6-soria-hardening-project.sh validate "$lab"
bash module6-soria-hardening-project.sh reset "$lab"
test ! -e "$lab"

Défi autonome

Décide si l’exception est acceptable

Prends GAP-WIN-001 et EX-WIN-001. Présente l’écart, le risque résiduel, le contrôle compensatoire, sa preuve, l’expiration et l’action requise. Explique ce qui ferait passer la décision à BLOCKED.

✓À retenir

Un bon registre d’exception rend le risque plus visible, pas moins. Il conserve l’écart, borne la dérogation, exige une compensation testée et programme une sortie.