Les normes que Pavois cartographie

La menace : quatre checklists pour un seul réglage

La vraie menace ici n'est pas un exploit précis, c'est l'incohérence et les déclarations invérifiables. Chaque équipe, auditeur ou régulateur exige un référentiel différent : un environnement de données carte répond à PCI-DSS, un hôte du secteur public français à ANSSI-BP-028, un système fédéral américain à NIST 800-53/171, tandis que les opérations se standardisent sur les CIS Benchmarks et la défense sur STIG. Maintenir quatre ou cinq listes distinctes pour le même réglage sshd ou sysctl garantit la dérive, des valeurs contradictoires et un audit irreproductible. Pire, la plupart des outils prouvent la conformité en lisant les fichiers : un Include ou un drop-in casse silencieusement la correspondance, et vous livrez un contrôle qui semble couvert mais ne l'est pas.

Pourquoi c'est important

Un contrôle ne vaut que par sa preuve. Si vous ne pouvez pas montrer à un auditeur une vérification concrète en disant voici la ligne CIS, la règle ANSSI et la famille NIST sur lesquelles elle se mappe, et voici la valeur effective mesurée, la déclaration de conformité n'est que du théâtre. Cartographier correctement les normes transforme un durcissement épars en une posture multi-référentielle défendable issue d'un seul scan, et permet de répondre « sommes-nous CIS Niveau 2 ? » et « sommes-nous ANSSI renforcé ? » sans réauditer la machine pour chacune.

Une règle neutre, N vues

Le principe porteur : un contrôle possède un unique identifiant interne stable et neutre (un slug domaine-objet comme ssh-disable-root-login), et chaque norme y est rattachée comme tag dans un bloc norms. Une norme est une vue, jamais une copie. On ne duplique jamais un contrôle par référentiel, donc les correspondances ne peuvent jamais diverger. Les normes elles-mêmes :

• CIS Benchmarks : consensus communautaire, prescriptif et par produit, deux profils : Niveau 1 (socle) et Niveau 2 (défense en profondeur, peut casser des fonctionnalités). Étiqueté level_cis: '1'|'2' + le numéro de recommandation.
• ANSSI-BP-028 : le guide Linux de l'agence française, numéroté R1..R<n>, avec quatre niveaux cumulatifs (minimal, intermediary, enhanced, high).
• NIST SP 800-53 / 800-171 : des familles de contrôles (AC, AU, SC, CM), postures abstraites plutôt que réglages ligne à ligne.
• PCI-DSS : exigences numérotées (Req-8.x), réussite/échec, obligatoire pour les données de carte.
• STIG : guides prescriptifs DISA par règle, granularité proche de CIS.

Types de mappings : direct contre support

Un mapping est une référence croisée, pas une preuve d'équivalence. La force dépend de la nature de la norme :

Un mapping direct signifie que la norme prescrit ce réglage exact ; le check la satisfait seul. Un mapping support signifie que le check contribue à une famille abstraite parmi d'autres ; le réussir est une preuve vers la famille, pas un certificat que le check seul la remplit. Le badge crosswalk de chaque fiche l'indique.

Un mapping réel, lu correctement

Le contrôle ssh-disable-root-login porte ce bloc norms, mesuré une seule fois par une vérification sshd -T :

"norms": {
  "bp28": "R33",
  "cis": ["5.1.20", "2.2.6", "5.1.22"],
  "nist": ["AC-17(a)", "AC-6(2)", "CM-6(a)", "IA-2"],
  "pci-dss": ["2.2.6", "Req-2.2.4"]
}

Lisez-le correctement : CIS 5.1.20 et ANSSI BP-028 R33 sont directs (chacun prescrit PermitRootLogin no) ; NIST AC-17(a)/IA-2 sont support (désactiver le SSH root contribue aux familles accès distant et identification, que beaucoup d'autres contrôles servent aussi). Un check réussi est une preuve vers toutes, pas un « conforme à cinq normes » global.

Comment les mappings sont validés

Les correspondances sont par OS et épinglées par version : chaque règle enregistre dans os_versions la version de benchmark à laquelle elle a été alignée (ex. CIS 2.0.0 pour rhel9, 1.1.0 pour debian12), car un numéro de recommandation CIS ne signifie rien sans sa version. Chaque mapping est ensuite recoupé contre des sources indépendantes plutôt qu'affirmé :

# recouper chaque entree norms[] contre SSG, ansible-lockdown et ciso-assistant
mise run validate_mappings

C'est la discipline qui garde un crosswalk honnête plutôt qu'aspirationnel, et le même corpus neutre est publié en paquet OSCAL (catalogue + profils) pour l'outillage GRC.

Ce que Pavois audite

Pavois livre un seul corpus de contrôles neutres, chacun auditant la configuration effective (sshd -T, sysctl, systemctl show), chacun portant un bloc norms qui le rattache à chaque norme qui le couvre. Le rapport HTML expose un <select> de réglementation et un sélecteur de niveau (CIS 1/2, ANSSI minimal..high) qui recompose chapitres et score côté client : la même preuve, reprojetée selon la norme que parle votre auditeur. Comme chaque vérification lit l'état résolu, la correspondance reste honnête même lorsque les réglages vivent dans des Include ou drop-ins qu'un scanner par fichier raterait.

FAQ

Un check réussi signifie-t-il que je suis conforme à cinq normes ? Non. C'est une preuve vers ses mappings. Les mappings directs (CIS, STIG, ANSSI), il les satisfait pleinement ; les mappings support (familles NIST), il y contribue avec d'autres contrôles.

Pourquoi épingler une version de benchmark par OS ? Parce qu'un 5.1.20 nu n'a aucun sens sans sa version : CIS renumérote d'une version à l'autre. os_versions enregistre exactement à quel benchmark chaque mapping a été aligné.

Puis-je exporter les mappings pour mon outil GRC ? Oui, le corpus neutre est publié en catalogue et profils OSCAL, le format machine-readable du NIST pour l'automatisation de la conformité.