Auteur: Chris Gralike, d.d. 18-11-2025

Recent kwam ik ‘STRIDE’ tegen als analysestructuur in een security assessment. Dit herinnerde mij aan de kracht en de eenvoud ervan. Hoewel ik het zelf al een tijdje minder bewust had toegepast, bleek het nog steeds een heel krachtig hulpmiddel om over bedreigingen en risico’s na te denken.

Cybersecurity is een complex vakgebied met enorm veel facetten om rekening mee te houden. Te veel om allemaal te onthouden of continu ‘top of mind’ te houden. Daarom maken we dankbaar gebruik van verschillende acroniemen om ons een handje te helpen. STRIDE is hier misschien wel het bekendste voorbeeld van.

het STRIDE acroniem is door Loren Kohnfelder en Praerit Garg ontwikkeld en stamt uit de late jaren ’90. In die tijd werd Microsoft Windows geplaagd door uiteenlopende securityproblemen. Loren en Praerit realiseerden zich dat veel van deze problemen niet op te lossen waren met pleisters achteraf (bolt-on-security). Ze moesten al tijdens het ontwerp ondervangen worden (security-by-design).

Het fundamentele inzicht was dat softwareontwikkelaars niet per se security-experts zijn. Daarom bedachten ze het ‘STRIDE’-ezelsbruggetje. En dat is precies waarom dit model ook vandaag de dag zo relevant voor ons is: je hoeft geen security-expert te zijn (het helpt wel) om de risico’s in je eigen werkproces te zien, zolang je weet waar je op moet letten.

Zoals hiervoor beschreven is STRIDE een ezelsbruggetje dat wordt gebruikt om digitale risico’s in kaart te brengen. Het helpt je om op een gestructureerde manier naar een systeem, applicatie of bedrijfsproces te kijken en jezelf de vraag te stellen: ‘wat kan hier misgaan?’

Het STRIDE-acroniem verdeelt bedreigingen in zes hoofdcategorieën. Elke letter in het acroniem staat voor een specifieke hoofdcategorie. Door deze letters één voor één langs te lopen voorkom je dat je belangrijke risico’s over het hoofd ziet. Althans dat is het idee achter dit acroniem.

De zes categorieën die STRIDE benoemt zijn:

• Spoofing (voordoen als iemand),
• Tampering (knoeien met gegevens),
• Repudiation (ontkennen van handelingen),
• Information disclosure (Datalekken),
• Denial of service (sabotage, onbereikbaarheid),
• Elevation of privilege (misbruik van rechten).

Het kennen van de categorieën is stap één, maar hoe pas je dit nu toe in de praktijk? Het simpelweg afvinken van een lijstje is daarbij niet voldoende. Een effectieve STRIDE-analyse draait om interactie tussen verschillende betrokkenen en visualisatie.

In de securitypraktijk volgen we daarom de volgende drie stappen:

1. Visualiseren
2. Analyseren (met behulp van STRIDE)
3. Interpretatie en prioritering

Maar wat gebeurt er precies tijdens elk van deze stappen? Laten we hier kort op inzoomen.

Stap 1 – Visualiseren

Je kunt niet goed beveiligen wat je niet goed begrijpt. IT is vaak complexer dan het op het eerste oog lijkt. Daarom is het advies om altijd eerst een visualisatie te maken van het object dat we willen analyseren. Dit kan een proces, een systeem of een specifieke applicatiebewerking zijn.

De uitwerking hiervan noemen we vaak een ‘Data Flow Diagram’. Dit klinkt technisch, maar is in feite een schematische voorstelling die laat zien waar informatie vandaan komt, waar het wordt opgeslagen of verwerkt, en wie er toegang heeft. Een goede visualisatie levert vaak al de eerste inzichten op, nog voordat STRIDE in beeld komt.

Stap 2 – Analyseren

Met de tekening uit stap 1 als leidraad leggen we de ‘STRIDE-lat’ langs elke stap in het proces. Dit is het moment waarop de kritische vragen gesteld moeten worden. Het doel is om breed te denken, daarom is het van belang dit samen met verschillende betrokkenen te doen.

Heb je bijvoorbeeld wel eens stilgestaan bij de vraag hoe makkelijk het voor iemand is om met jouw gestolen accountgegevens (Spoofing) OneDrive te installeren op een vreemde laptop? Wat zou diegene vervolgens met al jouw gesynchroniseerde bestanden kunnen doen (Tampering, Information Disclosure)?

Belangrijk: voorkom dat ‘gekke’ ideeën in deze fase direct worden afgeschoten. Het diskwalificeren van een risico doen we pas later, als we kunnen aantonen dat het niet relevant is. Zorg er in deze fase vooral voor dat alle inzichten worden vastgelegd.

Vervolgens kijk je naar de maatregelen. Mag OneDrive bijvoorbeeld alleen aangemeld worden op systemen die door ons beheerd worden? En levert die beperking niet weer nieuwe risico’s op voor de werkbaarheid? Of hebben we rapportages waarmee we alle aanmeldingen via monitoring (SIEM) controleren?

Stap 3 – Interpretatie en prioritering

Een sessie levert vaak tientallen potentiële risico’s op, maar – misschien nog wel belangrijker – ook een dieper begrip van de informatiestromen binnen de organisatie. De laatste stap richt zich op het toetsen en wegen van de gevonden risico’s. Wat is hoofdzaak en wat is bijzaak?

De kwaliteit van deze analyse valt of staat met de uitwerking: hoe concreter een risicoscenario is beschreven, hoe beter de inschatting gemaakt kan worden. Op basis van deze uitwerking kan beoordeeld worden welke maatregelen écht nodig zijn om een bepaald risico te mitigeren (verkleinen) tot een acceptabel niveau.

Het STRIDE-model is na ruim 25 jaar nog altijd een krachtig hulpmiddel om grip te krijgen op digitale veiligheid. Het dwingt je om verder te kijken dan de standaard checklists en de ‘happy flow’ van je bedrijfsprocessen. Door te denken als een aanvaller, kun je de verdediging versterken nog voordat er daadwerkelijk iets misgaat.

Maar zoals bij elk gereedschap, bepalen de betrokkenen het resultaat. De grootste uitdaging zit vaak niet in het begrijpen van de letters, maar in de uitvoering: het begeleiden van de discussie, het voorkomen van tunnelvisie en – vooral – het vertalen van een veelvoud aan scenario’s naar een werkbaar actieplan.

Hulp bij uw cybersecurity?

Wij ondersteunen organisaties bij het begrijpen, analyseren en opvolgen van risico. Wij helpen u om de juiste vragen te stellen, hoofd- van bijzaken te scheiden en theoretische risico’s om te zetten in concrete verbeterstappen.

Neem gerust contact met ons op om te bespreken hoe we uw organisatie samen weerbaarder kunnen maken.

Bronnen:

• L. Kohnfelder, P. Garg, The threats to our products, april 1999.
• A. Shostack, Experiences Threat Modeling at Microsoft, jan 2008.