Veel softwareteams hebben hun security op papier goed ingericht. Er is een WAF, er zijn admin-accounts, er zijn policies, er is logging. En toch blijft er een ongemakkelijke vraag onder de tafel liggen: wie ziet als eerste dat een control niet meer doet wat hij belooft?
Die vraag is kleiner dan een audit en groter dan een alert. Het gaat niet om nog een tool erbij. Het gaat om eigenaarschap, bewijs en het moment waarop je besluit dat iets echt aandacht nodig heeft.
De recente FortiWeb-advisory van het NCSC is vooral daarom interessant. Niet omdat één product ineens het hele gesprek bepaalt, maar omdat het een bekend patroon laat zien: een control kan aanwezig zijn, netjes geconfigureerd lijken en tóch een aanname hebben die niet meer klopt. Als dat gebeurt, is de vraag niet alleen of je iets hebt, maar of iemand kan aantonen dat het vandaag nog werkt zoals bedoeld.
De spanning zit zelden in het gebrek aan tooling
In veel organisaties is security niet leeg. Er zijn dashboards, controls en processen genoeg. De frictie zit ergens anders: wie is eigenaar van de werking van die control, en wat is het eerste bewijs dat je checkt als je twijfelt?
Dat klinkt simpel, maar in de praktijk is het vaak diffuus. De ene teamleider denkt dat infrastructure het oppakt. Infrastructure denkt dat security het monitort. Security denkt dat de applicatie-eigenaar de businessimpact kent. En ondertussen staat er ergens een mechanisme dat ooit met zorg is ingericht, maar waarvan niemand nog precies kan zeggen wanneer het voor het laatst bewust is gevalideerd.
Dat is geen verwijt. Het is gewoon hoe groeiende softwareorganisaties werken. Je krijgt meer systemen, meer uitzonderingen, meer beheerders, meer afhankelijkheden. De controle zelf blijft vaak wel bestaan, maar het eigenaarschap erachter wordt zachter.
Juist daar ontstaat de spanning. Niet in de vraag of iets technisch mogelijk is, maar in de vraag of iemand zich verantwoordelijk voelt voor het bewijs dat het nog functioneert.
Wat de FortiWeb-aanleiding eigenlijk blootlegt
De NCSC-melding over Fortinet FortiWeb beschrijft kwetsbaarheden die laten zien dat een authenticatie- of inputcontrole niet automatisch hetzelfde is als een betrouwbare barrière. Een aanvaller hoeft dan niet per se “sterker” te zijn; soms volstaat het dat een aanname in het mechanisme zelf te ruim is geworden.
Je hoeft daar niet meteen een groot verhaal van te maken. Het interessante is het kleinere inzicht: een control is geen bezit, maar een bewering. En elke bewering vraagt om een eigenaar die weet hoe je die bewering minimaal verifieert.
Dat geldt niet alleen voor WAF’s of admin-interfaces. Het geldt voor toegangsregels, uitzonderingspaden, verificatiestappen, en alles wat in een organisatie als “afgedekt” voelt. Zodra niemand meer kan aanwijzen wat het kleinste bewijs is dat de control nog werkt, wordt die control vooral een herinnering aan eerdere keuzes.
En dan is de vraag niet: hebben we genoeg security gedaan? Maar: wie draagt vandaag het bewijs dat deze ene controle nog klopt?
Eén control, één eigenaar, één verificatiemoment
De meeste teams hebben geen behoefte aan een nieuw securityprogramma als eerste reactie. Ze hebben behoefte aan helderheid op één plek.
Kies bijvoorbeeld één kritisch toegangspad, één WAF-regel, één adminflow of één verificatiestap waarvan je zegt: dit moet blijven doen wat het belooft. Niet alles. Slechts één control waar de organisatie echt op leunt.
Leg dan drie dingen vast:
Wie is eigenaar van het bewijs dat deze control werkt?
Wat is het minimale verificatiemoment, bijvoorbeeld wekelijks, per release of na configuratiewijzigingen?
Welke afwijking vraagt direct om besluitvorming, en welke mag eerst als observatie blijven staan?
Dat is klein genoeg om vandaag te doen, en scherp genoeg om verschil te maken. Je opent daarmee geen brede audit. Je maakt één verantwoordelijkheid zichtbaar.
Voor leiders is dat vaak rustgevender dan een brede scan. Niet omdat de wereld ineens eenvoudig is, maar omdat je weet waar het eerste echte signaal vandaan moet komen.
Het kleine bewijs dat eigenaarschap zichtbaar maakt
In de praktijk ziet zo’n eerste stap er vaak verrassend nuchter uit. Een team kiest één control en schrijft op wat het bewijs is dat die control nog doet wat hij moet doen. Dat kan een configuratiecheck zijn, een testrequest, een periodic review van toegangslogica, of een observatie uit een change- of releaseproces.
Belangrijk is niet de elegantie van het document. Belangrijk is dat iemand kan zeggen: als dit signaal verandert, dan merken wij dat op vóórdat het een discussie wordt.
Dat kleine bewijsstuk heeft drie effecten.
Ten eerste maakt het eigenaarschap concreet. Niet “security” in het algemeen, maar een naam, een team, een moment.
Ten tweede maakt het prioriteit proportioneel. Niet elk signaal vraagt om paniek; sommige afwijkingen vragen alleen om bevestiging, andere om een besluit.
Ten derde voorkomt het dat controls alleen nog op vertrouwen draaien. Vertrouwen is prettig, maar in softwareorganisaties is getoond bewijs vaak stabieler dan herinnering.
Dat is precies waar veel leiders naar zoeken: minder theater, meer zichtbaar vakmanschap.
De volgende stap is zelden groter dan een afspraak
Als je hier iets van wilt meenemen, maak het dan niet ingewikkeld. Kies één control die voor jullie echt telt. Benoem de owner. Spreek af wanneer het bewijs wordt bekeken. En leg vast wat een afwijking betekent voor de volgende beslissing.
Meer hoeft het in eerste instantie niet te zijn.
Niet omdat dat genoeg is voor altijd, maar omdat een organisatie pas leert waar het bewijs ontbreekt als ze één plek echt scherp maakt. Daarna zie je meestal vanzelf waar het patroon zich herhaalt.
Dat is ook de reden dat wij dit liever benaderen als een Pathfinder Signal dan als een brede security-oefening. Niet eerst alles openleggen, maar eerst zichtbaar maken waar bewijs, eigenaarschap en prioriteit nu ontbreken. Eén control. Eén eigenaar. Eén verificatie.
Als je wilt, kun je daar rustig mee beginnen en kijken waar in jullie omgeving het eerste kleine signaal ligt dat vandaag nog geen duidelijke eigenaar heeft.