Établis l'état initial et cartographie les surfaces d'exposition

01Comprends le problème SORIA Distribution

Le portail, l’ERP, l’identité, le pare-feu, les sauvegardes et le poste d’administration ont des rôles différents.

Une baseline unique produirait deux erreurs :

• oublier une fonction nécessaire au rôle ;
• conserver une exposition héritée qui n’a plus de justification.

Avant toute modification, tu dois pouvoir répondre :

Quel actif ?
Quel rôle ?
Quelle mission ?
Quel propriétaire ?
Quelle zone ?
Quels services et logiciels ?
Quelle exposition ?
Quel chemin d'administration ?
Quelle preuve before ?

02Manipule l’inventaire

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/initial-inventory.csv"

Le rapport associe chaque actif à ses nombres de services et logiciels.

Examine ensuite les sources :

column -s, -t "$lab/source/inventory/assets.csv"
column -s, -t "$lab/source/inventory/services.csv"
column -s, -t "$lab/source/inventory/software.csv"

Les sources sont en lecture seule et leur checksum est conservé avant transformation.

03Classe les surfaces

Le lab utilise quatre catégories pédagogiques :

Une surface « interne » n’est pas automatiquement sûre. Une surface « externe » n’est pas automatiquement supprimable.

04Observe le registre d’exposition

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

Quelques cas :

https         external  required=yes  KEEP
ssh           admin     required=yes  RESTRICT
telnet        external  required=no   REMOVE
web-admin     admin     required=yes  RESTRICT
backup-ingest internal  required=yes  KEEP
avahi         internal  required=no   DISABLE

Le registre ne réduit pas la décision à « port ouvert = vulnérable ». Il ajoute mission, nécessité, test fonctionnel et rollback.

05Distingue trois niveaux de preuve

Déclaré
Le service figure dans un fichier d'inventaire.

Observé
Un outil autorisé montre le processus, le socket ou la configuration effective.

Démontré
Un test borné confirme le chemin autorisé, le refus attendu et l'effet fonctionnel.

Dans ce lab CI, seul l’état déclaré des fixtures et leurs transformations sont prouvés.

Sur une machine autorisée, une collecte pourrait employer des commandes adaptées au système. Elle devrait être enregistrée séparément et ne jamais viser un système non autorisé.

06Conserve le before state

cat "$lab/work/services-before.csv"
sha256sum "$lab/work/services-before.csv"
cat "$lab/evidence/rollback/services-before.sha256"

Le before state sert à :

• expliquer le delta ;
• reconnaître une dérive ;
• vérifier le rollback ;
• éviter de reconstruire l’histoire à partir de souvenirs.

Une capture d’écran isolée est moins exploitable qu’un export horodaté, versionné et hashé.

07Vérifie les dépendances fonctionnelles

Un service peut sembler inutile tout en étant une dépendance indirecte.

Pour SORIA Distribution :

Portail → ERP API → identité → réseau
Sauvegarde → catalogue → dépôt isolé → opérateur de restauration
Administration → poste dédié → WireGuard → interface management

L’inventaire technique doit être relu avec le propriétaire de mission.

08Définis le seuil de suffisance

L’état initial est suffisant pour le changement lorsque :

• le périmètre et le propriétaire sont connus ;
• les services et logiciels ont une justification ou un écart ;
• les chemins d’administration sont identifiés ;
• les dépendances critiques sont explicites ;
• une preuve before peut être comparée ;
• les inconnues deviennent des blockers ou actions.

Il n’est pas nécessaire de prétendre connaître toute l’entreprise pour durcir un périmètre borné.