We hebben inmiddels baselines, normen, frameworks, certificeringen, audits, hercertificeringen en steeds weer nieuwe versies daarvan. ISO 27001, ISO 27002, BIO, NEN 7510, ENSIA en allerlei aanvullende normen en richtlijnen helpen organisaties om informatiebeveiliging gestructureerd in te richten.
Daar is op zichzelf niets mis mee. Sterker nog: een goede baseline helpt om niets essentieels over het hoofd te zien.
Maar ik blijf met een andere vraag zitten: “Hoeveel van iedere euro die we aan informatiebeveiliging besteden, komt uiteindelijk terecht bij de feitelijke bescherming van het informatiesysteem?“
Een nieuwe versie betekent opnieuw werk
Er verschijnt een nieuwe versie van een norm of baseline. En vervolgens begint een bekende cyclus:
- De nieuwe versie anschaffen.
- Gap-analyse uitvoeren.
- Risicoanalyses opnieuw beoordelen.
- Controls opnieuw koppelen.
- Beleid en procedures aanpassen.
- Registers en verklaringen wijzigen.
- Medewerkers instrueren.
- Interne audits uitvoeren.
- (Management) reviews houden.
- Consultants inschakelen.
- Beoordelen tooling: aanpassen, of nieuw aanschaffen.
- Externe audits laten uitvoeren.
- En uiteindelijk opnieuw certificeren.
Daarmee is inmiddels een omvangrijke markt ontstaan van adviseurs, auditors, opleiders, softwareleveranciers en certificerende instellingen. Dat hoeft niet te betekenen dat normen worden gewijzigd om deze markt in stand te houden. Maar helemaal uitsluiten kunnen wij dat niet. Voor de betrokkenen is het immers hun middel van bestaan en mogelijk missie!
Reële aanwijzingen: dreigingen veranderen, technologie verandert en wetgeving verandert. Normen móéten dus kunnen meegroeien. Maar het economische mechanisme is er wel.
Iedere wijziging van een norm veroorzaakt opnieuw advies-, implementatie-, audit- en certificeringswerk. En dat rechtvaardigt volgens mij een bestuurlijke vraag die veel vaker gesteld zou mogen worden:
Wat krijgen we er concreet aan extra bescherming voor terug? Een certificaat is nog geen veilige organisatie
Stel dat een organisatie Configuratie Management, logging, monitoring, patchmanagement en secure development al uitstekend heeft ingericht. Een nieuwe normversie kan die onderwerpen anders rubriceren, anders nummeren of explicieter benoemen. Maar wordt die organisatie daardoor feitelijk veiliger? Niet noodzakelijk.
Andersom kan een organisatie uitstekend gedocumenteerd zijn, alle verplichte overleggen hebben gehouden en de audit succesvol hebben doorlopen, terwijl ergens:
- De updates van een oud systeem niet worden bijgehouden.
- Niemand zich werkelijk eigenaar voelt.
- Accounts te ruime rechten hebben.
- Een leverancier ongecontroleerde toegang heeft.
- Recovery nooit werkelijk is getest.
- Of een kritische end-to-end-keten nooit integraal is beproefd.
Dan is de Opzet misschien goed beschreven en het Bestaan kan zelfs worden aangetoond. Maar hoe staat het met de Werking?
Daar zit voor mij een potentiële “blinde vlek”: Compliance is niet hetzelfde als bescherming
We hebben de afgelopen jaren steeds meer aandacht gekregen voor aantoonbaarheid. Terecht, maar daar zit ook een risico in. Aantoonbaarheid kan langzaam een doel op zichzelf worden. Dan verschuift de aandacht van: “Zijn we voldoende beschermd?” naar: “Kunnen we aantonen dat we aan de norm voldoen?”
Dat zijn twee verschillende vragen. Een organisatie kan veel compliance produceren zonder dat dezelfde hoeveelheid energie wordt besteed aan het werkelijk verkleinen van het aanvalsoppervlak. En daar zou bij bestuurders een alarmbel moeten gaan rinkelen.
Vandaar de €100-vraag
Stel dat een organisatie €100 beschikbaar heeft voor informatiebeveiliging. Hoeveel daarvan besteden we dan aan: normen, beleid, registers, documentatie, adviseurs, audits, tooling voor compliance en certificering?
En hoeveel gaat rechtstreeks naar: patching, hardening, IAM, MFA, monitoring, veilige softwareontwikkeling, ketentesten, back-up en recovery, netwerksegmentatie, leveranciersbeheersing, technisch onderhoud en het daadwerkelijk oplossen van kwetsbaarheden?
Ik zeg niet dat de eerste categorie overbodig is. Goed bestuur, goede processen en onafhankelijke toetsing zijn noodzakelijk. Maar de verhouding moet wel uitlegbaar zijn. Want uiteindelijk houdt een ISO-certificaat een aanvaller niet tegen. Een goed geconfigureerd systeem mogelijk wel.
Moet iedere nieuwe baseline misschien een beschermingsbusinesscase hebben?
Bij iedere nieuwe versie van een norm of baseline zou ik eigenlijk de impact en de koste daarvan willen weten:
1. Welk risico wordt door deze wijziging beter beheerst?
2. Welke concrete maatregel verandert er in de praktijk?
3. Wat kost implementatie van die verandering?
4. Hoe stellen we vast dat de maatregel daadwerkelijk werkt?
5. Hoeveel aantoonbare risicoreductie krijgen we voor die investering terug?
Stel dat het resultaat van een normwijziging bijvoorbeeld uiteindelijk is: 47 documenten aangepast, 18 procedures gewijzigd, drie workshops gehouden, een nieuwe audit uitgevoerd, iemand tijdelijk ingehuurd, €75.000 besteed,
maar: de feitelijke technische en organisatorische bescherming is onveranderd.
Wat hebben we dan precies bereikt?
Misschien moeten we de volgorde omdraaien en niet beginnen met
“Wat verlangt de nieuwe baseline van ons?” Maar met: “Waar kunnen wij vandaag werkelijk geraakt worden?”
- Wie is daarvan eigenaar?
- Welke afhankelijkheden bestaan er?
- Wat is de staat van onderhoud?
- Welke zwakke plekken kennen we?
- Welke kennen we waarschijnlijk nog niet?
- Welke maatregelen werken aantoonbaar?
- Kunnen we herstellen als het misgaat?
En pas daarna gebruiken we normen en baselines als controlemechanisme om vast te stellen of we belangrijke onderwerpen hebben gemist. Dan krijgt een norm weer de plaats die hij volgens mij hoort te hebben: als hulpmiddel voor bescherming, niet als eindproduct van bescherming.
De voordeur eerst dicht
We kunnen enorme hoeveelheden tijd besteden aan rollen, processen, beleid, wetgeving, verantwoordingsstructuren en certificeringen. Maar als we bij aanschaf, ontwerp, ontwikkeling, wijziging en onderhoud van informatiesystemen de verkeerde keuzes maken, blijven we achteraf repareren. Daarom zou een groter deel van onze energie naar de voordeur moeten:
- Privacy & Security by Design.
- Eigenaarschap.
- Veilige ontwikkeling.
- Integraal ketentesten.
- Onderhoud.
- Monitoring.
- Disaster Recovery (DR): Dit richt zich specifiek op het herstellen van de IT-infrastructuur na een grote ramp of storing.
- Herstel na een calamiteit (datalek, hack, afpersing…..)
- Disaster Recovery (DR): Specifiek het herstellen van de IT-infrastructuur na een grote ramp of storing.
- Service restorability: Dit gaat over het vermogen om een specifieke IT-dienst snel weer online te krijgen.
- Business continuity: Continuïteit van de hele organisatie, waar ICT-herstel een groot onderdeel van is.
- Testen, testen, testen…
- En aantonen werking.
Certificering kan een waardevolle bevestiging geven. Maar certificering mag nooit het doel worden. De werkelijke maatstaf is uiteindelijk veel eenvoudiger:
Zijn onze informatie, processen, mensen en systemen vandaag aantoonbaar beter beschermd dan gisteren?
Zo niet, dan moeten we ons misschien afvragen waar al die compliance euro’s precies zijn gebleven.