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.
LFSi — Linux From SourcITEC. © SourcITEC — LFSi team.