Traduis une décision de risque en exigences de durcissement testables

01Pars d’une décision déjà justifiée

SORIA Distribution a déjà identifié ses missions, actifs, vulnérabilités et traitements dans la matière de fondations. Tu ne recommences pas l’analyse complète.

Tu prends une décision précise :

Risque : administration du portail trop exposée
Traitement : REDUCE
Actif : AST-001
Mission : recevoir les commandes clients

Une décision de risque ne dit pas encore quoi configurer. Elle doit devenir un résultat observable.

02Manipule le dossier de référence

lab=/tmp/soria-hardening-lot1-$USER
bash module1-baseline-change-recovery.sh setup "$lab"
bash module1-baseline-change-recovery.sh status "$lab"
bash module1-baseline-change-recovery.sh run "$lab"

column -s, -t "$lab/source/change/risk-requirements.csv"

Le fichier contient six exigences. Observe REQ-001 :

décision        REDUCE
actif           AST-001
cible           exposer uniquement HTTPS et restreindre SSH
test positif    HTTPS présent
test négatif    Telnet absent
test fonctionnel portail représenté disponible
limite          aucun port réel testé

La ligne ne prétend pas que le serveur existe. Elle définit le contrat que devra respecter une mise en œuvre autorisée.

03Distingue les six parties de l’exigence

Une action comme « désactiver Telnet » n’est qu’un moyen. L’exigence contient le résultat et les preuves attendues.

04Relie la cible à la mission

Compare deux formulations :

Mauvais
Désactiver tous les services inutiles.

Testable
Sur AST-002 :
- conserver erp-api ;
- retirer ftp ;
- vérifier la lecture des commandes ;
- restaurer paquet et configuration si le test métier échoue.

La seconde formulation protège à la fois la sécurité et la disponibilité métier.

05Observe la séparation entre preuve et promesse

grep '^REQ-005,' "$lab/source/change/risk-requirements.csv"

REQ-005 exige deux dépôts et des rôles séparés. Mais sa limite déclare :

Immutabilité réelle non prouvée

Une propriété inscrite dans une politique n’est pas encore une propriété technique. La preuve doit venir d’un mécanisme observé et d’un test.

06Prépare les critères avant le changement

Pour chaque exigence, produis cette fiche :

ID
décision de risque
actif et propriétaire
mission à préserver
état initial connu
état cible
action bornée
test positif
test négatif
test fonctionnel
précheck
critère d'arrêt
rollback
preuve attendue
limite de preuve

L’ordre est important. Écrire les assertions après coup permettrait de les adapter à ce que l’outil a produit.

07Reconnais les modes d’échec

L’exigence est incomplète si :

• l’actif ou le propriétaire est absent ;
• la cible est une commande sans résultat attendu ;
• seul le test positif est prévu ;
• la mission n’est jamais vérifiée ;
• le rollback est « à définir » ;
• la preuve est une capture sans contexte ;
• une conformité complète est annoncée à partir d’un contrôle partiel.

Le lab bloque volontairement des variantes incohérentes pendant validate.

08Valide sans dépasser le périmètre

bash module1-baseline-change-recovery.sh validate "$lab"

Le résultat confirme la cohérence des fixtures. Il ne confirme pas :

un serveur durci
un patch installé
un port fermé
une restauration de production
une conformité ANSSI ou CIS

La frontière de preuve est un livrable, pas une réserve ajoutée à la fin.