Conformité et preuves — prouver plutôt que déclarer¶

Un tableau de bord qui affiche « conforme » en vert répond à une question que personne ne pose. Un auditeur demande autre chose : « comment savez-vous que c'était vrai à telle date, et que personne n'a retouché la preuve depuis ? »

Cette page décrit comment le parc répond à cette question-là : un catalogue de contrôles, des sondes qui mesurent, un statut qu'on ne peut pas saisir à la main, et un registre qu'on ne peut pas réécrire sans que ça se voie.

Les termes techniques renvoient au glossaire.

Ce que « conforme » peut vouloir dire ici¶

Deux référentiels servent de grille, et aucun des deux ne s'applique au sens strict :

NIS2 oblige les entités essentielles et importantes de l'Union. Un parc personnel n'en est pas une. La directive sert de grille de mesure : ses dix mesures minimales (article 21 §2) et sa mécanique de notification (article 23) sont un bon inventaire de ce qu'une défense sérieuse doit couvrir.
SOC 2 est un rapport rendu par un auditeur agréé, sur une période. Aucun outil n'est « certifié SOC 2 », et un produit qui l'affirme confond le rapport avec le dossier. Un outil peut, en revanche, produire le dossier de preuves que l'auditeur demanderait.

C'est ce que fait le parc : un catalogue de contrôles, des preuves mesurées, un statut dérivé des preuves, un export — et les critères non couverts, affichés comme tels plutôt que tus.

flowchart LR
    classDef src fill:#3f3f46,stroke:#3f3f46,color:#fff
    classDef proof fill:#1e40af,stroke:#1e40af,color:#fff
    classDef out fill:#0f766e,stroke:#0f766e,color:#fff

    cat["Catalogue de contrôles<br/>versionné dans git"]:::src
    son["Sondes<br/>pass · fail · indeterminate"]:::src
    att["Attestations humaines<br/>session authentifiée · expiration"]:::src
    tri["Gestes de triage<br/>avant → après · auteur"]:::src

    run["Lanceur<br/>toutes les six heures"]:::proof
    reg["Registre chaîné<br/>ajout seul · SHA-256"]:::proof
    anc["Ancre quotidienne<br/>git, deux dépôts distants"]:::proof

    der["Statut DÉRIVÉ<br/>recalculé à chaque lecture"]:::out
    tab["Tableau de conformité"]:::out
    exp["Dossier d'audit"]:::out

    cat --> run
    son --> run --> reg
    att --> reg
    tri --> reg
    reg --> anc
    reg --> der --> tab
    der --> exp

1. Le catalogue de contrôles communs¶

Un contrôle est une mesure de sécurité dont on peut prouver qu'elle fonctionne. Le catalogue en compte une trentaine. Chacun porte :

un objectif, en une phrase ;
les articles de NIS2 et les critères de SOC 2 auxquels il répond — un contrôle posé une fois sert les deux référentiels (contrôles communs) ;
ses sources de preuve : une ou plusieurs sondes, une attestation, ou les deux.

Le catalogue est un fichier versionné dans git. Chaque version entre elle-même au registre : on sait non seulement ce qui était prouvé à une date, mais ce qu'on exigeait à cette date.

Comment le catalogue couvre les dix mesures de l'article 21 §2 :

NIS2, art. 21 §2	Ce que le catalogue y met	SOC 2	Preuve
a) analyse des risques	Analyse de risques et angles morts écrits, revue annuelle	CC3	attestation
b) gestion des incidents	SIEM et alerting, détection à l'exécution, IDS réseau, témoins des moteurs de fichiers, renseignement sur la menace, réponse automatique, investigation à chaud	CC7	sondes
c) continuité, sauvegardes, gestion de crise	Sauvegardes immuables, restauration éprouvée, clé maîtresse hors ligne	A1, CC9	sondes + attestation
d) chaîne d'approvisionnement	Quarantaine de versions, SBOM, revue des fournisseurs critiques	CC8, CC9	sondes + attestation
e) sécurité du développement et de la maintenance, vulnérabilités	Scan continu, délai de correction des critiques exposés, traçabilité des changements, correctifs, blocage au périmètre	CC6, CC7, CC8	sondes
f) évaluation de l'efficacité	Intégrité du registre de preuves, revue trimestrielle des contrôles	CC4	sonde + attestation
g) cyberhygiène et formation	Correctifs, durcissement CIS, compétence de l'opérateur	CC1, CC5	sondes + attestation
h) cryptographie	Certificats réellement servis, clé maîtresse	CC6	sondes
i) contrôle d'accès, gestion des actifs	Inventaire et persistance, SBOM, absence de secrets en clair sur les hôtes	CC6, C1	sondes
j) authentification multifacteur, communications sécurisées	MFA sur les comptes à privilèges, canal de crise hors du parc	CC6, CC2	sonde + attestation

S'y ajoutent l'article 20 (responsabilité et supervision : une attestation annuelle) et l'article 23 (notification : le registre d'incidents).

2. Les sondes¶

Une sonde est un script qui mesure un fait et rend un verdict. Son contrat est court, et chaque clause a une raison :

Clause	Raison
Une seule ligne JSON en sortie : identifiant, verdict, fait observé, détail, date de mesure	Un lanceur unique, un format unique, aucune interprétation
Verdict parmi `pass`, `fail`, `indeterminate`	Trois états, parce qu'il y a trois situations
Cible injoignable → `indeterminate`, jamais `pass`	Une absence de réponse n'est pas une mesure
Sort en succès dès qu'un verdict est rendu, même `fail`	Un contrôle en échec n'est pas une sonde en panne
Moins d'une minute	Une sonde lente est une sonde qu'on finit par désactiver
Aucun secret dans la sortie	Le détail part dans un registre que d'autres lisent
En-tête : ce qu'elle prouve, ce qu'elle ne prouve pas, la commande qui l'a fait échouer	Une sonde qu'on n'a jamais vue rouge ne mesure rien

{"probe": "<identifiant>", "status": "pass",
 "observed": "<le fait mesuré, en une phrase>",
 "detail": {"...": "..."}, "measured_at": "<date ISO 8601>"}

La dernière clause est la plus importante. Avant d'être admise, chaque sonde subit sa vérification inverse : on provoque exprès la situation qu'elle doit détecter, et on la regarde passer au rouge. Une sonde qui ne peut pas échouer n'est pas une preuve, c'est une décoration.

Ce que mesurent les sondes, par exemple : les certificats réellement servis et leur échéance ; les agents du SIEM connectés ; un conteneur jetable qui déclenche la détection à l'exécution ; la règle canari des moteurs de fichiers ; une suppression refusée sur la cible de sauvegarde ; l'âge du dernier exercice de restauration ; la présence de la quarantaine de versions dans chaque dépôt ; le second facteur des comptes à privilèges ; l'intégrité du registre face à ses ancres.

Une sonde prouve ce qu'elle mesure, et pas davantage

La sonde du registre d'incidents vérifie que les échéances des incidents déclarés sont tenues. Un registre vide la fait passer. Elle ne prouve donc pas qu'aucun incident n'a eu lieu, ni qu'un incident réel a été déclaré — et c'est écrit dans son en-tête, là où le prochain lecteur le trouvera.

Les sondes tournent toutes les six heures. Une sonde présente sur disque mais rattachée à aucun contrôle apparaît sur le tableau comme preuve orpheline : elle mesure quelque chose que personne n'a demandé, ou un contrôle a perdu sa preuve.

3. Le statut dérivé¶

Le statut d'un contrôle ne se saisit pas. Il se calcule, à chaque lecture, à partir des preuves :

Statut	Condition
Effectif	Toutes ses sondes rendent `pass`, et sont fraîches (36 heures par défaut), et toutes ses attestations sont valides
En échec	Au moins une sonde rend `fail`
Non vérifié	Tout le reste : une sonde muette, périmée, indéterminée, une attestation manquante ou expirée

La troisième ligne est celle qui fait la différence. L'absence de mesure n'est pas une mesure : un contrôle dont la sonde s'est tue ne reste pas vert par inertie, il passe en « non vérifié ».

Pourquoi ne jamais saisir un statut : un statut saisi est une déclaration. Il était vrai le jour où on l'a écrit, et il le reste dans l'interface bien après que la réalité a changé. Un statut dérivé ne peut pas mentir plus longtemps que la fraîcheur de sa preuve.

4. Le registre chaîné et son ancre¶

Toutes les preuves — chaque verdict de sonde, chaque attestation, chaque version du catalogue — entrent dans un registre chaîné, en ajout seul.

flowchart LR
    classDef e fill:#1e40af,stroke:#1e40af,color:#fff
    classDef a fill:#0f766e,stroke:#0f766e,color:#fff

    e1["Entrée n<br/>contenu + empreinte de n-1"]:::e
    e2["Entrée n+1<br/>contenu + empreinte de n"]:::e
    e3["Entrée n+2 — tête<br/>contenu + empreinte de n+1"]:::e
    anc["Ancre du jour<br/>numéro + empreinte de tête<br/>versionnée dans git"]:::a

    e1 --> e2 --> e3
    e3 -.->|"chaque soir"| anc

Chaque entrée contient l'empreinte SHA-256 de la précédente. Modifier, supprimer ou insérer une entrée au milieu casse la chaîne à l'entrée exacte : la vérification dit où.
Il reste un cas que la chaîne seule ne voit pas : la troncature. Supprimer les dernières entrées laisse une chaîne parfaitement valide, simplement plus courte.
D'où l'ancre : chaque soir, le numéro et l'empreinte de la tête du registre sont versionnés dans git et poussés sur deux dépôts distants. Un registre tronqué ne retrouve plus ses ancres. Une sonde confronte le registre aux ancres publiées.

Une conséquence voulue

Restaurer la base du registre depuis une sauvegarde la ramène à un état antérieur : ses entrées récentes ont disparu, et la vérification contre les ancres échoue. C'est exact — le registre a bel et bien perdu des preuves. Cet échec se consigne ; il ne se « corrige » jamais en purgeant les ancres, ce qui reviendrait à effacer la trace de la perte.

5. Deux journaux, et qui les signe¶

Le registre porte deux sortes d'entrées :

les preuves, décrites plus haut ;
les gestes humains : chaque décision de triage, chaque action de remédiation, inscrite avec son état avant et après, dans la même transaction que le geste lui-même — un geste sans trace ne peut pas avoir eu lieu.

L'auteur d'un geste est lu du canal — la session authentifiée par le fournisseur d'identité — et jamais du corps de la requête. Un journal dont l'auteur se déclare lui-même ne prouve rien : n'importe quel détenteur d'un accès pourrait y écrire n'importe quel nom.

6. Les attestations¶

Certaines choses ne se mesurent pas : qu'une analyse de risques a été relue, que l'opérateur se forme, que les fournisseurs critiques ont été revus, que le canal de crise hors du parc a été testé. Elles relèvent d'une attestation : une déclaration humaine datée.

Trois garde-fous en font autre chose qu'une case cochée :

elle n'est acceptée que depuis une session authentifiée ;
elle expire — annuellement ou trimestriellement selon le contrôle ;
elle entre au registre comme n'importe quelle preuve, donc elle ne se retouche pas.

7. Auditer — la marche à suivre¶

Un auditeur, ou l'opérateur dans six mois, refait ces gestes :

Recalculer la chaîne du registre, puis la confronter aux ancres prises dans git — pas à celles que le serveur annonce : l'intérêt d'une ancre est d'être hors de portée de la machine qu'elle surveille.
Exporter le dossier d'audit : catalogue, statuts, preuves, incidents et méthode, en un fichier.
Rejouer une sonde à la main, sans écrire au registre, et comparer son verdict au dernier enregistré.
Choisir un contrôle au hasard et demander sa vérification inverse : quelle commande l'a fait échouer, et qu'a-t-elle rendu ?

8. Ajouter un contrôle ou une sonde¶

Écrire la sonde selon le contrat, en-tête compris.
La faire échouer exprès, et noter la commande qui l'a fait échouer.
La déclarer dans un contrôle du catalogue — l'identifiant de la preuve est le nom du fichier de la sonde.
La lancer à blanc, puis attendre le passage suivant du lanceur. Une sonde non déclarée apparaît comme orpheline : l'oubli se voit.