Je security cultuur zal falen. Dat is niet het probleem.

Samenvatting

Een SaaS-bedrijf slaat twee dagen voor Black Friday een security check over. Een hardcoded test-rekeningnummer komt mee in de release. Transacties gaan een week lang naar verkeerde rekeningen. Het bedrijf verliest 1 miljoen dollar.

Elke control die dit had moeten voorkomen, bestond. Niet een faalde technisch. Ze werden niet toegepast, omdat het bedrijf zijn mensen had getraind om de deadline te zien als de echte constraint en security als de variabele om uit te stellen.

De standaardreactie: fix de cultuur. Wij denken dat dat de verkeerde vraag is. Security cultuur faalt onder druk. De vraag is wat jouw architectuur doet wanneer dat gebeurt. En onder de Nederlandse Cyberbeveiligingswet is dat geen IT-discussie meer. Het is jouw verantwoordelijkheid als bestuurder.

Wanneer de uitzondering de strategie wordt

Sina Yazdanmehr, CEO van IT security consultancy Aplite GmbH, beschrijft een corporate dat een redelijk risk-exemption proces had opgebouwd. Projecten die live moesten voordat een security issue was opgelost, konden een formulier indienen, sign-off krijgen, en doorgaan met een uitzondering van één jaar. Remediation werd verondersteld te volgen.

Na vijf of zes jaar telde het register honderden items: architecturele gaten, ontbrekende firewalls, ongepatchte systemen, elk jaar opnieuw verlengd zonder kritische blik. Senior leadership las de lijst als bewijs dat het proces werkte. Wat het in werkelijkheid was: jaren aan opgebouwd risico zonder realistisch plan om het op te ruimen.

Het inkorten van de geldigheidsduur en het expliciet maken van de juridische zwaarte van een ondertekende uitzondering hielp. Een ondertekende risk exemption legt vast wie wat wist en wanneer, en die zichtbare aansprakelijkheid veranderde hoe managers ermee omgingen. Maar dit blijft een culture fix. Het leunt erop dat de volgende manager het formulier anders leest dan de vorige. Onder aanhoudende druk valt de cultuur terug. De lijst groeit weer.

Architectuur verandert wat een uitzondering betekent, niet of je ze hebt. Het afhandelen van uitzonderingen is onderdeel van hoe Zero Trust werkt: in ons AUXO™-portaal worden geaccepteerde risico’s vastgelegd tegen de specifieke Protect Surface™ waar ze betrekking op hebben, zodat de exposure gedocumenteerd is in plaats van geïmpliceerd. Die structurele zichtbaarheid helpt. Het stopt niet dat de lijst groeit.

Wat het wel verandert, is het bereik. Een uitgezonderd systeem binnen een goed gedefinieerde Protect Surface™, gesegmenteerd en continu gemonitord, is nog steeds een uitgezonderd systeem. Maar de vraag “wat brengt deze uitzondering ons concreet aan blootstelling?” heeft nu een afgekaderd antwoord. De lijst kan nog steeds lang worden. De schade van elk afzonderlijk item is begrensd voordat de uitzondering ooit werd ingediend.

Heldencultuur: de verkeerde interventie

Lieuwe Jan Koning, Co-founder en CTO bij ON2IT, noemt het Black Friday-patroon de preventieparadox: het verlies dat wordt voorkomen, levert geen organisatorisch krediet op, terwijl het verlies dat plaatsvindt een volledige post-mortem genereert. De engineer die op tijd levert, krijgt de bonus. De engineer die een ontbrekende compliance check aankaart, krijgt het stempel bottleneck.

De meeste organisaties reageren door die incentives te willen veranderen. Dat is de verkeerde interventie. Onder echte deadline druk in een echt bedrijf zijn incentives praktisch onverplaatsbaar. Het engineering team dat levert voor Black Friday stopt niet omdat de CISO het uitzonderingen-formulier heeft aangescherpt. Ze vinden een ander pad, omdat de business daarvan afhankelijk is.

Hetzelfde patroon zie je in awareness training. Phishing training stopt mensen niet met klikken. Met genoeg moeite achter een gerichte mail klikt iemand altijd. De nuttige vraag is niet hoe je de klik tegenhoudt. Het is wat er gebeurt ná de klik. Kan de gebruiker de malicious site überhaupt bereiken? Als ze credentials invullen, werken die credentials zonder tweede factor? Als ze werken, wat kan de aanvaller dan daadwerkelijk bereiken? Dat zijn architectuurvragen. De klik gaat gebeuren. De blootstelling hoeft niet.

De juiste vraag is niet hoe je de held weerhoudt van shortcuts. Het is hoe je zorgt dat de shortcut die hij neemt jouw betalingsinfrastructuur, klantgegevens of kernsystemen niet blootlegt. Dat is het Zero Trust argument toegepast op de werkelijkheid van een organisatie: ga ervan uit dat de developer de check overslaat, en ontwerp zodat de impactradius van die beslissing wordt begrensd door architectuur, niet door vertrouwen in een proces dat ze net hebben omzeild.

Nee zeggen haalt geen risico weg, alleen zicht

Er is een failure mode aan de kant van het security team in deze dynamiek. Wanneer het primaire antwoord op een verzoek “nee” is, gaat het werk gewoon door, maar buiten het zicht van security.

Yazdanmehr beschrijft een machine learning team dat productiedata nodig had om een model te trainen. Synthetische data was niet toereikend. Het security team weigerde zonder alternatieven te bespreken. Dus zocht het team een contact in operations, liep weg met een volledige database-export via SharePoint, en verspreidde kopieën over developer-werkstations en de persoonlijke laptop van een contractor. De situatie liep ruim een jaar door.

Toen de CISO het aankaartte, was de reactie van het team: “Verwachtte je dat we niet zouden werken omdat jij zei dat het niet veilig is?”

Architectuur had die vraag anders beantwoord. Productiedata-toegang voor een ML-team zou niet via SharePoint naar de laptop van een contractor moeten kunnen lopen, omdat dat pad er niet zou moeten zijn. Een ingeperkte pipeline, met gemaskeerde of bemonsterde data, geserveerd vanuit een gecontroleerde omgeving, neemt de workaround als optie weg. Waar de inperking niet strak genoeg kan zijn, signaleert behavioral analytics in de GSOC de anomalie: een contractor-account dat plotseling een volledige database-export trekt, is een patroon waar je niet de intentie van de gebruiker voor hoeft te kennen om er een alert op te geven. De eerlijke kanttekening: behavioral detection is reactief. Het ziet de beweging nadat die heeft plaatsgevonden. Dat is nog altijd beter dan het alternatief dat dit team koos, namelijk geen zicht.

Dit is hetzelfde structurele falen als de Black Friday case, maar dan van de andere kant. Beide gebeuren omdat het security model leunt op een mens, de engineer in het ene geval, de CISO in het andere, die onder concurrerende druk de juiste beslissing moet nemen. Wanneer ze dat niet doen, is er geen fallback, tenzij de architectuur is ontworpen om die te bieden.

De vertrouwenskloof die je rollout tegenwerkt

Een bedrijf met 800 medewerkers kocht een enterprise ChatGPT-contract met zero data retention. Dertig seats waren actief. De meeste medewerkers gebruikten nog steeds persoonlijke accounts, en plakten source code en contract-drafts in een model dat trainde op alles wat werd ingevoerd.

Twee groepen dreven dit. De eerste had nooit het verschil tussen enterprise- en consumer-accounts uitgelegd gekregen in termen die relevant waren voor hun werk. De tweede vertrouwde de uitleg niet en ging ervan uit dat het bedrijfsaccount een monitoring tool was. Het persoonlijke account voelde privé. Het bedrijfsaccount voelde als surveillance.

De organisatie had het technische probleem opgelost. Het menselijke probleem niet. Dat is het patroon: technische controls die correct zijn ontworpen, en ineffectief blijken omdat de mensen die ze moeten gebruiken het óf niet begrijpen óf niet vertrouwen.

Het architectonische antwoord is hier moeilijker dan in de voorgaande cases. Werkelijk voorkomen dat medewerkers persoonlijke AI-accounts gebruiken vraagt strakke controle op het endpoint: managed browsers, application allowlists, DLP die uitgaande prompts inspecteert. Die controls bestaan. Ze zijn ook duur, ingrijpend, en niet altijd haalbaar. Waar je ze niet volledig kunt toepassen, verschuift de architectonische lever: beperk wat het persoonlijke account aan credentials en data kan blootleggen, en gebruik GSOC-monitoring om de lekkage die wel plaatsvindt te signaleren. Een deel van deze case moet het security team oplossen door het vertrouwen op te bouwen. Awareness alleen brengt je daar niet.

Wat we zien in de GSOC

De vier cases hierboven komen van buiten ON2IT. Het patroon dat ze beschrijven zien we terug in onze eigen data.

In de GSOC zijn de alerts die het meest betrouwbaar correleren met grote release-windows geen sophisticated attacks. Het zijn insiders, contractors en engineers onder druk die systemen benaderen buiten hun normale reikwijdte. Soms slaagt de toegang en lijkt het op laterale beweging. Soms wordt het tegengehouden bij de grens en lijkt het op een mislukte poging door een onbekend account. Beide leiden tot onderzoek, omdat beide ongebruikelijk zijn. De gebruiker doet meestal legitiem werk, en vindt het pad dat de architectuur openlaat, of botst tegen de muur die de architectuur heeft neergezet. Het signaal is in beide gevallen hetzelfde: mensen onder tijdsdruk die buiten hun normale reikwijdte werken. De taak van de architectuur is om die muur op de juiste plek te zetten.

Dit is het ontwerpprincipe achter hoe wij MDR Prevent™ uitvoeren voor onze klanten. We mappen Protect Surfaces™ rond de assets die er werkelijk toe doen, zoals je betalingsinfrastructuur, je klantdatabase, je order management systeem, en begrenzen de toegang tot elk afzonderlijk. Wanneer een engineer onder deadline druk levert zonder een check uit te voeren, is de vraag niet langer of de check het issue had gevangen. De vraag is wat de wijziging aan de andere kant kan bereiken. Voor een goed gedefinieerde Protect Surface™ is het antwoord: niet de dingen die er een miljoen-dollar-verhaal van hadden gemaakt.

Wanneer containment toch faalt, brengt MDR Detect™ de laterale beweging in onze GSOC aan het licht voordat het een incident wordt. De twee diensten beantwoorden de twee helften van dezelfde vraag. MDR Prevent™ begrenst wat de verkeerde beslissing kan bereiken. MDR Detect™ ziet het wanneer het toch gebeurt.

Wat dit betekent onder de Cyberbeveiligingswet

De Nederlandse Cyberbeveiligingswet, de implementatie van NIS2, legt de verantwoordelijkheid voor cybersecurity-resilience expliciet bij het bestuur. Niet bij de CISO. Niet bij IT. Bij jou. Aantoonbare nalatigheid bij een security-incident kan persoonlijke aansprakelijkheid betekenen.

Dat verandert wat de vier cases hierboven betekenen voor je governance. Een uitzonderingenlijst die jaren ongezien is verlengd, een release-besluit dat security oversloeg, een ML-team dat productiedata buiten de organisatie heeft verspreid, een SaaS-rollout met een lege adoptie. Vier ondertekende of impliciete beslissingen waarvoor uiteindelijk jij verantwoording aflegt.

Wat de wet niet zegt, is dat je culture-programma’s moet draaien. Wat ze wel zegt, is dat je redelijkerwijs moet zorgen dat je organisatie de bekende risico’s heeft afgedekt. “Redelijkerwijs” is een architectonisch criterium, niet een cultureel. Een bestuur dat kan aantonen dat zijn architectuur de blast radius van een falende control begrenst, staat er bij een incident anders voor dan een bestuur dat alleen kan wijzen op afgevinkte awareness trainingen.

De architectuur die uitgaat van een falende cultuur

Zero Trust is een architectonisch antwoord op de vraag die deze blog stelt. Het gaat er niet vanuit dat de cultuur standhoudt. Het gaat ervan uit dat de gebruiker de verkeerde keuze zal maken, dat de developer de check overslaat, dat het team een route om het beleid heen zoekt. Protect Surfaces™ zijn zo ontworpen dat wanneer die dingen gebeuren, de schade beperkt blijft. De held die levert zonder de security check uit te voeren, kan nog steeds leveren. Wat hij aan de andere kant van die beslissing kan bereiken, wordt begrensd door architectuur, niet door vertrouwen in een proces dat hij net heeft omzeild.

Architectuur is niet het hele antwoord. Een security functie die opereert als de afdeling-van-nee blijft workarounds produceren, ook in een goed gesegmenteerde omgeving, omdat mensen het pad om de muur heen vinden wanneer de muur voelt als obstructie. Het architectonische argument in dit stuk is geen vervanging voor security teams die zich verbinden met de business. Het is wat die teams onder zich bouwen, zodat wanneer hun engagement faalt, of wanneer de business hen overruled, of wanneer iemand onder druk de verkeerde keuze maakt, de consequentie wordt begrensd.

Dat is een ander antwoord dan “fix de cultuur.” Culture work vraagt hoe je mensen de juiste keuze laat maken. Architecture work vraagt wat er gebeurt wanneer ze dat niet doen. De meeste energie in de sector gaat naar de eerste vraag. De vier cases in dit stuk, en de patronen die we in onze eigen data zien, zijn een argument om de tweede serieus te nemen.

Belangrijkste punten

• Security cultuur faalt onder druk op voorspelbare manieren. De signalen om naar te kijken in je eigen organisatie: een uitzonderingenlijst die zonder kritische blik wordt verlengd, een engineer die wordt beloond voor leveren langs een ontbrekende check, een gesanctioneerde tool met lage adoptie tegen een ongesanctioneerd alternatief.
• Proberen heldencultuur-incentives te veranderen is de verkeerde interventie. De juiste vraag is wat de held kan bereiken wanneer hij de bocht afsnijdt, niet of hij dat zal doen.
• Een security-weigering is geen control. Het haalt zicht weg en produceert een minder veilige uitkomst dan een begrensde versie van het oorspronkelijke verzoek.
• Architectuur is niet absoluut. Een security functie die zich verbindt met de business blijft nodig. Architectuur is wat de fouten van die verbinding opvangt.
• Onder de Cyberbeveiligingswet ligt aantoonbare verantwoordelijkheid voor cybersecurity-resilience bij het bestuur. “Redelijkerwijs” is een architectonisch criterium, niet een cultureel.

Conclusie

De vier cases in dit stuk zijn niet ongewoon. Ze zijn hoe security cultuur faalt in organisaties die al hebben geïnvesteerd in security. Het uitzonderingenproces bestaat. De review gates bestaan. De enterprise tool is gekocht. De CISO zit aan tafel.

Het patroon is hetzelfde. Een control die afhangt van een mens die onder concurrerende druk de juiste keuze maakt. Wanneer de druk wint, is de control er niet.

Architectuur is een ander antwoord. Het vraagt mensen niet de juiste keuze te maken. Het begrenst wat de verkeerde keuze kan bereiken. De held die levert zonder de check, kan nog steeds leveren. Het uitgezonderde systeem dat nog niet is gepatcht, is nog steeds uitgezonderd. De engineer die source code in een persoonlijk AI-account plakte, deed dat nog steeds. In elk geval is de impact van die beslissing begrensd voordat de beslissing werd genomen.

Dat is hoe je de tweede vraag serieus neemt. En het is, onder de Cyberbeveiligingswet, ook het bewijs dat je het serieus hebt genomen.

Call to action

Als de patronen in dit stuk herkenbaar zijn in jouw organisatie, is MDR Prevent™ hoe wij dit architectonische antwoord operationeel maken voor onze klanten. We mappen Protect Surfaces™ rond de assets die er werkelijk toe doen en begrenzen de toegang onafhankelijk. Neem contact op om te zien hoe jouw versie van containment eruitziet.