Organise le patching, le changement, la validation et le rollback

01Traite le patching comme un processus

Le NIST décrit le patch management d’entreprise comme l’identification, la priorisation, l’acquisition, l’installation et la vérification.

Dans SORIA Distribution :

inventorier
→ qualifier l'exposition et la mission
→ décider patch ou mitigation
→ préparer fenêtre et préchecks
→ appliquer sur périmètre pilote
→ tester sécurité et fonction
→ étendre ou rollback
→ conserver les preuves

02Manipule le plan de changement

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

column -s, -t "$lab/output/patch-change-plan.csv"

Le lab contient cinq changements synthétiques : web, ERP, identité, pare-feu et sauvegarde.

03Observe les priorités

URGENT
service web exposé ; fenêtre d'urgence ; snapshot et test portail

HIGH
ERP ou identité ; fenêtre de maintenance ou pilote

MEDIUM
firmware edge ou logiciel backup ; planification avec export et restauration

La priorité n’est pas calculée avec la sévérité seule.

Ajoute :

• actif réellement affecté ;
• exposition ;
• exploitation connue ;
• contrôle compensatoire ;
• criticité métier ;
• dépendances ;
• capacité de test et de retour.

04Prépare les préchecks

column -s, -t "$lab/output/prechecks.csv"

Exemples :

web      snapshot et espace disponibles
ERP      backup et test de commandes prêts
identité réplication et comptes de secours vérifiés
edge     export précédent et accès console
backup   point de restauration et capacité

Un backup non testé n’est pas automatiquement un précheck suffisant. La leçon suivante construit la preuve de restauration.

05Définis un critère d’arrêt

column -s, -t "$lab/output/stop-criteria.csv"

Un critère d’arrêt doit être observable :

portail fixture échoue
schéma attendu diffère
authentification pilote échoue
chemin management absent
catalogue backup illisible

« En cas de problème » n’est pas mesurable.

06Prépare le rollback avant l’action

column -s, -t "$lab/output/rollback-plan.csv"
cat "$lab/evidence/rollback/services-before.sha256"

Le validateur crée une variante sans rollback et exige son refus.

Le rollback contient :

artefact de retour
commande ou procédure
autorité
ordre
test après retour
critère de réussite

Le lab simule le retour de l’état target à l’état before et compare les fichiers.

07Gère l’urgence sans supprimer la discipline

Une vulnérabilité exploitée peut imposer une action rapide.

Options temporaires possibles :

• réduire l’exposition ;
• désactiver une fonction ;
• appliquer une règle de filtrage ;
• renforcer l’authentification ;
• surveiller un indicateur précis ;
• isoler l’actif.

La mitigation doit avoir :

propriétaire
date d'expiration
risque résiduel
preuve
plan de patch définitif

Elle ne doit pas devenir une exception permanente invisible.

08Valide en trois directions

Après changement :

positif
le contrôle attendu est présent

négatif
le chemin ou composant interdit est absent

fonctionnel
la mission reste disponible

Pour le portail :

positif : HTTPS conservé
négatif : Telnet retiré
fonctionnel : portail représenté disponible

Un scanner de configuration seul ne prouve pas le troisième point.

09Conserve les preuves

Dossier minimal :

ticket et approbation
inventaire/version before
source de l'avis
décision de priorité
préchecks
artefact de rollback
delta
résultats positif/négatif/fonctionnel
écarts
version after
limite de preuve

Une preuve doit permettre à un autre opérateur de comprendre ce qui a été fait et pourquoi.

10Reconnais les limites du lab

Le lab ne télécharge ni n’installe aucun patch.

Il prouve :

• que chaque changement possède les champs obligatoires ;
• qu’un rollback absent est bloqué ;
• que les services métier représentés restent disponibles ;
• que le before state peut être restauré sur une copie.

Il ne prouve pas la compatibilité réelle.