Construis une baseline adaptée au rôle et à la criticité

L’idée reçue

« Une baseline est une liste universelle de paramètres sûrs. »

Une référence externe aide à ne rien oublier. La baseline locale doit encore tenir compte du rôle, du risque, de la version, de l’exposition et des dépendances.

01Définis la baseline comme un état cible

Une baseline utile précise :

périmètre
rôle
criticité
contrôle
état cible
méthode de vérification
exception possible
rollback
limite de preuve

Elle ne doit pas se limiter à « conforme / non conforme ».

02Manipule les contrôles par rôle

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/role-baseline.csv"

Le lab couvre six rôles :

linux-web
linux-app
windows-identity
network-edge
backup-repository
admin-workstation

Chaque rôle possède un objectif différent.

03Observe les différences de rôle

Pour linux-web :

https conservé
ssh restreint
telnet retiré
logiciels limités au portail

Pour backup-repository :

ingest conservé
découverte locale désactivée
rôles séparés
dépôt isolé
restauration manifestée

Appliquer exactement la baseline web au dépôt de sauvegarde serait incohérent.

04Ajoute criticité et exposition

Deux actifs du même rôle peuvent nécessiter des niveaux différents :

serveur web interne de test
criticité MODERATE
exposition internal

portail de commandes
criticité HIGH
exposition external

L’écart de criticité peut modifier :

la priorité du patch ;
la profondeur des préchecks ;
le nombre d’anneaux ;
le besoin de haute disponibilité ;
la durée d’observation ;
l’autorité d’approbation.

05Utilise les référentiels comme sources

Une démarche saine :

1. prendre une référence officielle ou reconnue ;
2. identifier les contrôles pertinents ;
3. vérifier la version et le rôle ;
4. analyser l'impact fonctionnel ;
5. traduire en exigence locale ;
6. tester ;
7. enregistrer l'écart et la décision.

Le cours peut citer CIS Benchmarks, mais ne reproduit pas leur contenu propriétaire et ne prétend pas une conformité complète.

06Distingue trois colonnes critiques

État source
ce que la fixture ou la collecte décrit

État cible
ce que le rôle exige

Vérification
ce qui permettra de conclure

Ajoute une quatrième colonne :

Limite
ce que la vérification ne couvre pas

Le fichier du lab indique par exemple :

Permissions locales non immutabilité
Aucun socket réel inspecté
Aucun patch réel installé

07Gère l’écart sans maquiller le résultat

Un écart peut recevoir :

CORRECT
corriger dans la fenêtre approuvée

ACCEPT_TEMPORARILY
exception datée et approuvée

COMPENSATE
ajouter un contrôle qui réduit le risque

BLOCK
arrêter le déploiement

Le Lot 6 formalisera la gestion complète des exceptions et de la dérive. Ici, tu prépares déjà les champs nécessaires.

08Prépare la vérification de dérive

La baseline doit pouvoir être comparée à un nouvel état :

baseline versionnée
+ export effectif
→ delta
→ écart attendu ou dérive
→ action et preuve

Sans version, une modification du document peut donner l’illusion que le système a toujours été conforme.

09Évalue la qualité de la baseline

Une baseline est insuffisante si :

le rôle n’est pas précisé ;
elle mélange plusieurs versions incompatibles ;
le contrôle n’a pas de test ;
la mission n’est pas considérée ;
les exceptions n’ont pas de propriétaire ;
la cible change pour correspondre à l’état actuel ;
la mention « CIS compliant » remplace la preuve.

Livrable

Construis une baseline de rôle

Pour un rôle du lab, sélectionne cinq à huit contrôles. Indique source, cible, vérification, effet fonctionnel, rollback et limite. Justifie au moins un contrôle écarté ou adapté.

✓À retenir

Une baseline est un état cible contextualisé et vérifiable. Elle organise la décision ; elle ne remplace ni le test ni l’acceptation du risque résiduel.