Conformiteit aantonen in de tijd, niet één keer

Een technicus zet MFA aan op het Microsoft 365-account van een klant, maakt een schermafbeelding en bergt die op in de bewijsmap. Acht maanden later vraagt de cyberverzekeraar van die klant — of zijn ISO 27001-auditor — om het bewijs dat MFA sinds de vorige verlenging onafgebroken actief is geweest. De schermafbeelding bewijst dat niet. Zij bewijst alleen dat de instelling aanstond op het moment waarop zij werd gemaakt.

Dat is het meest voorkomende verschil tussen wat een technicus bewijs noemt en wat een auditor bewijs noemt — en het kost geld op precies het moment waarop u het ontdekt, namelijk tijdens de audit.

Wat noemt een auditor een bewijs?#

Een gedateerde waarneming, in de tijd herhaald, die aantoont dat een maatregel gedurende de hele betrokken periode stand heeft gehouden — geen eenmalige verklaring die laat zien dat hij op één moment werkte. De norm ISO/IEC 27001:2022 legt dat vast in clausule 9.1: de organisatie moet de doeltreffendheid van haar beheersmaatregelen monitoren en meten, en gedocumenteerde informatie bewaren als bewijs van de resultaten — niet als bewijs dat een technicus de instelling ooit heeft gecontroleerd.

Voor een technicus beantwoordt het bewijs de vraag "staat het aan". Voor een auditor beantwoordt het de vraag "stond het de hele beoordeelde periode aan, en hoe weet u dat zonder elke dag te zijn gaan kijken".

Het auditvak scheidt die twee vragen al lang, en het vocabulaire is bruikbaar ook als u nooit een certificering doorloopt. Aan de ene kant het opzetbewijs: de maatregel bestaat, hij is geconfigureerd zoals het beleid voorschrijft, iemand kan hem op het scherm laten zien. Aan de andere kant het bewijs van operationele werking: de maatregel heeft het verwachte effect gehad, zonder onverklaarde onderbreking, gedurende de hele beoordeelde periode. Een schermafbeelding beantwoordt de eerste vraag en laat de tweede volledig open. Dat is precies het verschil tussen een verklaring over één moment en een verklaring over een periode — en het is die tweede die een verzekeraar of een gereguleerde klant uiteindelijk altijd vraagt.

Waarom volstaat een momentopname nooit?#

Omdat zij niets zegt over wat er vóór of na de dag van vastlegging is gebeurd. Een ISO 27001-certificeringsaudit, of een controle door een toezichthoudende autoriteit, betreft een periode — doorgaans het afgelopen jaar — en niet het moment van de audit. Eén enkele verklaring, hoe oprecht ook op het moment van ondertekening, dekt letterlijk maar één dag op driehonderdvijfenzestig.

Het risico is niet eens oneerlijkheid. Het is dat een momentopname die vlak vóór de audit is verzameld, juist de minst representatieve periode van het jaar beschrijft: de periode waarin iedereen net heeft gecontroleerd en gecorrigeerd wat niet in orde was.

Er is nog een mechanischere reden, en die verrast veel dienstverleners de eerste keer. Een auditor leest de hele periode niet terug: hij neemt steekproeven. Hij kiest data binnen de beoordeelde periode — vaak zonder u vooraf te vertellen welke — en vraagt om het bewijs van de staat van de maatregel op díé data. Bevat uw dossier alleen een schermafbeelding van de dag vóór de audit, dan is elke steekproefdatum een gat. U kunt die gaten niet achteraf vullen: een beheerconsole toont de toestand van vandaag, niet die van 14 maart. De meting van 14 maart bestond die dag, of zij bestaat niet.

Hoe raakt een beveiligingsinstelling ontregeld zonder dat iemand het expres deed?#

Door normaal gebruik van het systeem, niet door een fout. Een gebruiker raakt buitengesloten van zijn account, een technicus zet op vrijdagavond tijdelijk MFA uit om hem te deblokkeren, en niemand denkt er maandag aan het weer aan te zetten. Een update van de beheerconsole zet een groepsbeleid terug op de standaardwaarde. Een nieuw apparaat komt in het beheerde bestand vóór het conformiteitsbeleid erop is toegepast. Een beveiligingsregel richt zich op een gebruikersgroep waarvan de samenstelling verandert met aanwervingen en vertrekken, zonder dat iemand het bereik opnieuw synchroniseert.

Elk van die gebeurtenissen is op zichzelf onschuldig. Opgeteld over twaalf maanden, over tientallen accounts en meerdere tools, leveren zij precies op waar een auditor voor vreest: een maatregel die klopte op de dag dat hij werd gecontroleerd, en die al drie maanden niet meer klopt zonder dat iemand het heeft gemerkt.

Wat die drift duur maakt, is niet de ernst ervan maar de onopvallendheid. Geen van deze gevallen zet een alarm af, want geen ervan is een storing: het systeem doet precies wat eraan gevraagd is. Naast elkaar gelegd hebben zij allemaal dezelfde signatuur.

De rechterkolom is de enige die de vraag van de auditor beantwoordt. De drie andere beschrijven de toestand van vandaag — nuttig om te beheren, waardeloos om te bewijzen.

Wat moet een bewijs hebben om een audit te doorstaan?#

Vijf eigenschappen, en geen enkele is optioneel: ontbreekt er één, dan valt het dossier bij de volgende vraag. De regel die ze samenvat past in één zin — het ontbreken van een meting is het ontbreken van bewijs, niet een gunstig bewijs.

Een ongedateerd bewijs bewijst niets over een periode. Een bewijs dat door het volgende wordt overschreven — een dashboard dat alleen de laatste meting toont — verliest het spoor van het moment waarop de maatregel ophield te gelden. En een dag zonder meting mag nooit standaard als conforme dag worden geteld, want de eerste auditor die dat opmerkt, trekt de rest van het dossier in twijfel, ook de delen die wél klopten.

Hoe ziet een bewijsmeting er concreet uit?#

Als één regel per meting, niet als een document. Hieronder de minimale vorm van een bruikbare reeks voor één enkele maatregel — het toepassen van MFA op de Microsoft 365-accounts van een klant — over een handvol dagen.

Zes regels, en het hele verhaal is al leesbaar. Op 14 maart viel een account buiten het bereik van MFA. Op de 15e draaide de verzameling niet — en de regel zégt dat, in plaats van stilzwijgend de waarde van de dag ervoor over te nemen. Op de 16e werd een account aangemaakt: de noemer gaat van 52 naar 53, het nieuwe account valt nog niet onder het beleid, en de dekking daalt een tweede keer zonder dat wie dan ook een instelling heeft gewijzigd. Op de 17e zijn beide afwijkingen hersteld.

Een schermafbeelding van 17 maart zou 100 % hebben getoond en zou volkomen oprecht zijn geweest. Zij zou ook de drie voorafgaande dagen hebben uitgewist, waaronder de dag waarop de verzameling niet draaide — het enige punt in het dossier waarover een zorgvuldige auditor u om uitleg zal vragen.

Wat doet een auditor met een reeks gedateerde metingen?#

Drie dingen, in deze volgorde, en u kunt ze maar beter hebben zien aankomen. Hij controleert eerst de noemer: waar komt het getal 52 vandaan, hoe is het bereik samengesteld, en wat zou er gebeuren als een werkplek in geen enkele inventaris stond. Een conformiteitspercentage dat is berekend over een populatie die u zelf kiest, heeft geen bewijskracht, en dat is het eerste wat een ervaren auditor test.

Vervolgens neemt hij steekproeven. Hij kiest twee of drie data uit de periode en vraagt u om bij de bron de toestand terug te vinden die uw meting beweert. Zegt de regel van 14 maart 51 op 52, dan wil hij weten welk account ontbrak en waarom. Een meetreeks waarmee u niet kunt afdalen naar het detail, overleeft deze stap niet.

Ten slotte kijkt hij naar de gaten en de dips — en juist daar staat de intuïtie van veel dienstverleners op zijn kop. Een curve van 100 % over driehonderdvijfenzestig dagen, zonder één enkele dip, wekt geen vertrouwen: zij suggereert dat de meting niet veel meet. Een reeks die een dip op 14 maart laat zien, de oorzaak ervan, en het herstel op de 17e, beschrijft een beheersysteem dat werkt. De norm ISO/IEC 27001 voorziet dat geval overigens uitdrukkelijk in clausule 10.2: een vastgestelde afwijking moet worden behandeld, de oorzaken ervan onderzocht, en de corrigerende maatregel bewaard als gedocumenteerde informatie. Een gedocumenteerde en gecorrigeerde afwijking is een element van conformiteit, geen bekentenis.

Wat problemen geeft, is nooit de afwijking. Het is de afwijking die tijdens de audit wordt ontdekt omdat niemand mat.

Welke maatregelen kunt u automatisch meten, en welke nooit?#

Slechts een deel, en dat kunt u beter ronduit zeggen dan de indruk wekken dat een tool governance vervangt. Maatregelen waarvan de toestand in een bevraagbare console leeft, meet u doorlopend; maatregelen die op een menselijke handeling of een document berusten, bewijst u anders, en daarvoor bestaat geen eerlijke automatisering.

De rechterkolom is geen noodoplossing: het is dezelfde eis, toegepast op bewijs van een andere aard. Een ongedateerd verslag van een toegangsbeoordeling heeft precies hetzelfde gebrek als een ongedateerde schermafbeelding van een console.

Wat moet u doorlopend verzamelen in plaats van bij de audit te reconstrueren?#

Regelmatige technische metingen van elke automatisch verifieerbare maatregel — MFA toegepast, back-up succesvol uitgevoerd, beschermingsagent aanwezig, patches bij — die afzonderlijk worden bewaard in plaats van samengevoegd tot één indicator die de historie platwalst. Het praktische verschil is eenvoudig te verwoorden: in plaats van één keer per jaar te antwoorden "ja, MFA staat aan", kunt u antwoorden "MFA is toegepast op minstens 95 % van de werkplekken gedurende 91 van de afgelopen 92 dagen", met de datum van de dag die losliet en wat er die dag gebeurde.

Het tweede antwoord is verifieerbaar. Het eerste niet — het vraagt de auditor u op uw woord te geloven, wat noch zijn rol is noch de uwe om te vragen.

Dezelfde redenering geldt voor beslissingen, niet alleen voor metingen. Een conformiteitsregister dat alleen zijn huidige toestand toont, heeft het gebrek van het dashboard: het zegt niet wanneer een regel van "niet conform" naar "conform" ging. Een historie die de oude status, de nieuwe status en de omslagdatum bewaart, beantwoordt een vraag die de auditor stelselmatig stelt — hoe lang staat deze afwijking al open, en wat is er intussen gedaan.

Hoe lang moet u die metingen bewaren?#

Minimaal de periode die de audit bestrijkt, en in de praktijk langer. De beoordeelde periode van een ISO 27001-audit is doorgaans het afgelopen jaar, maar de duur van een certificeringscyclus en de precieze inhoud van de opvolgingsaudits hangen af van het schema dat de certificerende instelling hanteert: aan haar moet u vragen welke periode u moet dekken, niet aan een blogartikel. Aan verzekeringszijde komt de vraag bij de verlenging, dus elk jaar, over de twaalf voorafgaande maanden.

De praktische regel die vergissingen voorkomt: bewaar één volledige periode méér dan wat men u vandaag vraagt. Een dossier dat precies begint op de dag waarop de audit begint, wekt de — vaak onterechte — indruk voor de gelegenheid te zijn samengesteld. En bewaar de metingen in de vorm waarin zij zijn geproduceerd, met hun oorspronkelijke tijdstempel: een export die bij de audit is nabewerkt, herberekend of geherformatteerd, verliest juist de eigenschap die er een bewijs van maakte.

Dat is het principe achter de module voor continue drift van Vigicap: elke connectormeting wordt bewaard en nooit overschreven, waardoor u een gedateerde dekking kunt tonen zoals die hierboven in plaats van een losse schermafbeelding. Het conformiteitsregister volgt dezelfde regel: elke statuswijziging van een doelstelling bewaart de oude status, de nieuwe en de datum ervan, in plaats van de vorige waarde te vervangen.