Conformité CIS / STIG
Comprendre ce que « durci » veut dire concrètement sur LFSi, et piloter votre niveau d'exigence.
Les référentiels
LFSi s'aligne sur deux référentiels de sécurité internationalement reconnus, adaptés à une distribution construite depuis les sources :
- CIS Distribution Independent Linux Benchmark v2.0.0 — les bonnes pratiques du Center for Internet Security, organisées en deux niveaux : L1 (le socle, applicable partout) et L2 (renforcé, pour les environnements sensibles).
- DISA General Purpose Operating System SRG V3R3 — les exigences du département de la Défense américain (STIG), classées par sévérité : CAT I (critique), CAT II, CAT III.
Le durcissement progressif
C'est le principe clé sur LFSi :
- À l'installation, le socle est appliqué automatiquement : CIS L1 et STIG CAT I. Votre système démarre déjà durci, et un rapport de conformité initial est généré au premier démarrage.
- Ensuite, vous montez en exigence à votre rythme, depuis l'interface web (Conformité → Activation des niveaux) : CIS L2, STIG CAT II/III. Chaque activation est tracée et son effet immédiatement mesurable par un nouveau scan.
Pourquoi progressif ? Parce que certains contrôles de niveau supérieur peuvent contraindre vos usages : mieux vaut les activer en connaissance de cause, service par service, que tout subir d'un bloc.
Lancer un scan et lire le rapport
Depuis l'interface web (Conformité → Lancer un scan) ou le menu console. Le rapport présente, contrôle par contrôle :
| Champ | Signification |
|---|---|
| Identifiant | Le contrôle LFSi (ex. HRD-SSH-001) et ses références CIS/STIG |
| Sévérité | CAT I / II / III |
| Résultat | Conforme / Non conforme / Non applicable |
| Remédiation | Ce qu'il faudrait faire pour se mettre en conformité |
Le rapport s'exporte en HTML (lisible) et en JSON (pour vos outils).
Les exceptions : rien sous le tapis
Un contrôle peut être volontairement non appliqué — mais jamais silencieusement :
- chaque écart est documenté : identifiant, justification, date, responsable ;
- les exceptions apparaissent dans le rapport, distinctement.
Deux exceptions structurelles existent par construction (et sont documentées comme telles) : le support squashfs sur le média d'installation, et le routage contrôlé entre zones quand votre zonage l'exige.
Le cas particulier d'une distribution « from source »
Certains contrôles CIS/STIG supposent un gestionnaire de paquets d'éditeur (dnf/yum/rpm, dépôts Red Hat…). LFSi n'en a pas — et les remplace par des mécanismes équivalents ou plus stricts :
| Le référentiel demande… | LFSi répond par… |
|---|---|
| Paquets signés par l'éditeur | Signature de chaque paquet et de l'index du dépôt |
Vérification d'intégrité (rpm -Va) |
app verify + surveillance AIDE + manifestes d'empreintes |
| Origine des binaires | SBOM et traçabilité complète de compilation |
| Processus de mise à jour éditeur | Bundles signés, atomiques, réversibles + procédure de correctifs |
Ces équivalences sont elles aussi tracées dans le rapport (statut « compensé » ou « réimplémenté »).
En pratique : votre routine de conformité
- Après l'installation : lisez le rapport initial.
- Une fois vos services en place : activez L2 / CAT II-III progressivement, en re-scannant après chaque activation.
- Périodiquement : un scan, un œil sur les écarts, et des exceptions à jour.
Preuves de sécurité documentées
Certaines propriétés ne se vérifient pas par un scan de conformité : elles demandent une mesure, et cette mesure doit être conservée avec sa méthode et ses données brutes pour rester vérifiable des années plus tard.
- Fuite par le temps à l'authentification — comment nous savons que l'interface web ne révèle pas par sa durée de réponse ce que son message d'erreur refuse de dire. Deux fuites réelles trouvées et fermées, cinq campagnes de mesure avec leurs données brutes, et les graines permettant de tout rejouer à l'identique.
LFSi — Linux From SourcITEC. © SourcITEC — LFSi team.