Ga naar inhoud

Conformiteit en bewijzen – bewijzen in plaats van verklaren

Machinevertaling van het Franse origineel.

Een dashboard dat aangeeft "in orde" in groen, beantwoordt een vraag die niemand stelt. Een auditor vraagt echter: "Hoe weet u dat dit op dat moment waar was, en dat het bewijs niet is aangepast?"

Deze pagina beschrijft hoe het park op deze vraag antwoordt: een catalogus van controles, sensoren die meten, een status die niet direct kan worden vastgesteld, en een register dat niet zonder gevolg kan worden herschreven.

De technische termen verwijzen naar de glossarium.

Wat "in orde" hier kan betekenen

Twee referentiekaders dienen als basis, en geen van beide is strikt van toepassing:

  • NIS2 dwingt essentiële en belangrijke entiteiten binnen de Unie na te leven. Een particulier park valt daar niet onder. De richtlijn dient als meetinstrument: zijn tien minimale maatregelen (artikel 21 §2) en zijn notificatiemechanisme (artikel 23) vormen een goede inventaris van wat een serieuze beveiliging moet dekken.
  • SOC 2 is een rapport dat een geaccrediteerde auditor opstelt, over een bepaalde periode. Geen enkel instrument is "SOC 2-gecertificeerd", en een product dat dit beweert, verwar het rapport met het dossier. Een instrument kan echter wel het dossier met bewijzen produceren dat de auditor zou vragen.

Dat doet het park: een catalogus van controles, gemeten bewijzen, een status afgeleid van de bewijzen, een export – en de niet-gedekte criteria, die expliciet worden weergegeven in plaats van verborgen.

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. De catalogus van gemeenschappelijke controles

Een controle is een veiligheidsmaatregel waarvan kan worden bewezen dat deze werkt. De catalogus bevat er ongeveer dertig.

  • een doel, in één zin;
  • de artikelen van NIS2 en de criteria van SOC 2 waar het op voortbouwt – een enkele controle is van toepassing op beide referentiekaders (gemeenschappelijke controles);
  • zijn bewijsstukken: één of meerdere controles, een verklaring, of beide.

Het catalogusbestand is een versiebeheerde bestands in Git. Elke versie wordt geregistreerd: we weten niet alleen wat op een bepaalde datum is bewezen, maar ook wat we op dat moment verwachtten.

Hoe de catalogus de tien maatregelen van artikel 21 §2 dekt:

NIS2, artikel 21 §2 Wat het catalogus bevat SOC 2 Bewijs
a) Risicoanalyse Gedocumenteerde risicoanalyse en blinde vlekken, jaarlijkse herziening CC3 Attestatie
b) Incidentbeheer SIEM en waarschuwingen, detectie tijdens uitvoering, netwerk IDS, logs van bestanden, dreinformatie, automatische reactie, hete opsporing CC7 Sensoren
c) Continuïteit, back-ups, crisismanagement Onveranderlijke back-ups, bewezen herstel, offline master sleutel A1, CC9 Sensoren + attestatie
d) Supply chain Versie quarantaine, SBOM, beoordeling van kritische leveranciers CC8, CC9 Sensoren + attestatie
e) Ontwikkeling en onderhoud, kwetsbaarheden Continue scan, tijd voor het oplossen van gevonden kwetsbaarheden, traceerbaarheid van wijzigingen, patches, perimeterbeveiliging CC6, CC7, CC8 Sensoren
f) Effectiviteitsbeoordeling Integriteit van het bewijsstuk, kwartjaarlijkse controle CC4 Sensor + attestatie
g) Cyberhygiëne en training Patches, CIS hardening, vaardigheid van de operator CC1, CC5 Sensoren + attestatie
h) Cryptografie Werkend gecertificeerde sleutels, master sleutel CC6 Sensoren
i) Toegangscontrole, asset management Inventarisatie en persistentie, SBOM, geen expliciete geheimen op hosts CC6, C1 Sensoren
j) Multi-factor authenticatie, veilige communicatie MFA op bevoorrechte accounts, crisiskanaal buiten het netwerk CC6, CC2 Sensor + attestatie

Daarnaast zijn er artikel 20 (verantwoordelijkheid en toezicht: een jaarlijkse attestatie) en artikel 23 (rapportage: het incident register).

2. De sensoren

Een sensor is een script dat een feit meet en een conclusie trekt. De overeenkomst is kort, en elke clausule heeft een reden:

Clausule Reden
Eén JSON-regel als output: identificatie, conclusie, waargenomen feit, detail, meetdatum Eén enkele uitvoerder, een uniek formaat, geen interpretatie
Conclusie uit pass, fail, indeterminate Drie toestanden, omdat er drie situaties zijn
Onbereikbaar doel → indeterminate, nooit pass Een afwezigheid van een antwoord is geen meting
Succesvol uitvoeren zodra een conclusie is getrokken, zelfs fail Een mislukte controle is geen defecte sensor
Minder dan een minuut Een trage sensor is een sensor die uiteindelijk wordt uitgeschakeld
Geen geheimen in de output Het detail gaat naar een register dat anderen lezen
Kop: wat het bewijst, wat het niet bewijst, de opdracht die het mislukt Een sensor die nooit rood wordt, meet niets 
{"probe": "<identifiant>", "status": "pass",
 "observed": "<le fait mesuré, en une phrase>",
 "detail": {"...": "..."}, "measured_at": "<date ISO 8601>"}

De laatste clausule is het belangrijkst. Voordat een sensor wordt geaccepteerd, ondergaat deze een omgekeerde verificatie: we creëren expres de situatie die deze moet detecteren, en we kijken hoe deze rood wordt. Een sensor die niet kan falen, is geen bewijs, maar een decoratie.

Wat sensoren meten, bijvoorbeeld: de daadwerkelijk uitgegeven certificaten en hun vervaldatum; de agents van het SIEM; een tijdelijke container die de detectie activeert; de "canari"-regel voor bestandsengines; een afgewezen verwijdering op het back-up doel; de leeftijd van de laatste hersteloperatie; de aanwezigheid van tientallen versies in elk repository; de tweede factor van accounts met speciale rechten; de integriteit van het register ten opzichte van zijn "anchors".

Een sensor bewijst wat het meet, en niets meer

De controle van het incidentenregister controleert of de deadlines voor de gerapporteerde incidenten worden nageleefd. Een leeg register geeft aan dat er geen incidenten zijn geweest, maar bewijst niet dat er geen incidenten zijn geweest of dat een echt incident is gerapporteerd – en dit staat vermeld in de kop, waar de volgende lezer het zal vinden.

De controles draaien elke zes uur. Een controle die op een schijf staat, maar niet aan een controle is gekoppeld, wordt op de tabel weergegeven als een ongebracht bewijs: het meet iets waar niemand om heeft gevraagd, of een controle heeft zijn bewijs verloren.

3. De afgeleide status

De status van een controle wordt niet vastgelegd. Het wordt berekend, bij elke leesactie, op basis van de bewijzen:

Status Voorwaarde
Actief Alle controles geven pass, en zijn recent (standaard 36 uur), en alle attesten zijn geldig
Niet uitgevoerd Ten minste één controle geeft fail
Niet geverifieerd Het overige: een stil, verlopen, onbekende controle, een ontbrekende of verlopen attest

De derde regel is de cruciale. Het ontbreken van een meting is geen meting: een controle waarvan de sonde stil is gevallen, verandert niet van kleur door inertie, maar gaat over in "niet geverifieerd".

Waarom een status nooit vastleggen: een vastgestelde status is een verklaring. Het was waar op het moment dat het is geschreven, en blijft in de interface, zelfs nadat de werkelijkheid is veranderd. Een afgeleide status kan niet langer dan de versheid van zijn bewijs liegen.

4. Het kettingregister en zijn anker

Alle bewijzen – elk controleresultaat, elke attest, elke versie van het catalogus – komen terecht in een kettingregister, waarbij alleen wordt toegevoegd.

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
  • Elke entry bevat de SHA-256-hash van de vorige entry. Bewerken, verwijderen of een entry invoegen, breekt de keten precies op die entry: de controle geeft aan waar.
  • Er blijft een geval over waarbij de keten alleen niet zichtbaar is: het afkorten. Het verwijderen van de laatste entries laat een perfecte, maar kortere keten achter.
  • Daarom de anker: elke avond worden het nummer en de hash van het hoofd van het register versieerd in git en op twee externe repositories geplaatst. Een afgebroken register kan zijn ankers niet meer vinden. Een tool vergelijkt het register met de gepubliceerde ankers.

Een gewenste consequentie

Het herstellen van de basis van het register vanuit een backup brengt het terug naar een eerdere staat: de recente entries zijn verdwenen, en de controle op de ankers mislukt. Dit klopt: het register heeft daadwerkelijk bewijzen verloren. Dit falen wordt vastgelegd; het wordt nooit "hersteld" door de ankers te verwijderen, wat equivalent zou zijn aan het wissen van het bewijs van het verlies.

5. Twee logboeken, en wie ondertekent ze

Het register bevat twee soorten entries:

  • de bewijzen, zoals hierboven beschreven;
  • de menselijke acties: elke beslissing om te sorteren, elke actie om te herstellen, wordt vastgelegd met de toestand voor en na, in dezelfde transactie als de actie zelf — een actie zonder spoor kan niet hebben plaatsgevonden.

De auteur van een actie wordt gelezen vanuit de kanaal — de sessie die is geauthenticeerd door de identiteitsleverancier — en nooit van het lichaam van de request. Een logboek waarin de auteur zichzelf aangeeft, bewijst niets: elke persoon met toegang kan er een naam in schrijven.

6. De verklaringen

Sommige zaken zijn niet meetbaar: dat een risicoanalyse opnieuw is bekeken, dat de operator is opgeleid, dat de belangrijkste leveranciers opnieuw zijn gecontroleerd, dat een noodkanaal buiten het complex is getest. Dit zijn allemaal elementen van een verklaring: een handgeschreven verklaring.

Drie aspecten maken dit meer dan alleen een vinkje:

  • het moet zijn ondertekend na een geauthenticeerde sessie;
  • ze verlopen – jaarlijks of per kwartaal, afhankelijk van de controle;
  • ze worden opgenomen in het register, net als elke andere bewijsstuk, dus ze worden niet aangepast.

7. Auditer – de aanpak

Een auditor, of de operator binnen zes maanden, herhaalt deze stappen:

  1. De keten in het register opnieuw berekenen, en vervolgens vergelijken met de ankers die in git zijn opgeslagen – niet met de ankers die de server aangeeft: het doel van een anker is om bereik van de machine die ze controleert.
  2. Het auditrapport exporteren: catalogus, statuten, bewijzen, incidenten en methode, in een bestand.
  3. Een test opnieuw uitvoeren met de hand, zonder iets in het register te noteren, en de uitkomst vergelijken met de laatste opgeslagen.
  4. Een controle willekeurig selecteren en de inverse controle uitvoeren: welke opdracht heeft het mislukt, en wat heeft het resultaat opgeleverd?

8. Een controle of test toevoegen

  1. De test volgens het contract opstellen, inclusief de koptekst.
  2. De test opzettelijk laten falen, en de opdracht noteren die het heeft veroorzaakt.
  3. De test in een controle van de catalogus toevoegen — de identificatie van het bewijs is de naam van het bestand van de test.
  4. De test uitvoeren zonder verdere instructies, en wachten op de volgende uitvoer. Een test die niet is aangegeven, verschijnt als verloren: het is duidelijk dat er iets is vergeten.

Lees verder

Dernière vérification de cette page : 2026-09-11