Er is een fundamenteel probleem met hoe de meeste organisaties over beveiliging nadenken. Ze bouwen eerst iets, en vragen zich dan af: "Is dit veilig?" Dat is alsof je eerst een huis bouwt en dan pas kijkt of de grond stevig genoeg is. Threat modeling is het omgekeerde: eerst nadenken over wat er mis kan gaan, en dan bouwen met die kennis in je achterhoofd.
De vier vragen
In de kern draait threat modeling om vier vragen die onweerstaanbaar simpel klinken en verrassend moeilijk zijn om goed te beantwoorden:
- Wat bouwen we? — een model van het systeem. Dataflows, componenten, grenzen, actoren.
- Wat kan er mis gaan? — de dreigingen identificeren. Systematisch, niet op basis van onderbuikgevoel.
- Wat gaan we eraan doen? — voor elke dreiging: mitigeren, accepteren, overdragen, of vermijden.
- Hebben we het goed gedaan? — valideren dat de mitigaties werken en dat we niets gemist hebben.
Het mooie van deze vragen is dat ze geen diepgaande security-expertise vereisen. Elke ontwikkelaar, architect of product owner kan ze beantwoorden — mits ze de juiste structuur en begeleiding krijgen.
STRIDE: een gestructureerde manier om na te denken
Het meest gebruikte raamwerk voor het beantwoorden van vraag twee is STRIDE, bedacht door Microsoft in de vroege jaren 2000. Het is een acroniem dat zes categorieën dreigingen beschrijft:
- Spoofing — iemand doet zich voor als iemand anders. Een vervalste e-mail, een nagemaakt certificaat, een gestolen sessiecookie.
- Tampering — data wordt onderweg of in rust gewijzigd. Een man-in-the-middle die een API-response aanpast, een aanvaller die logbestanden wijzigt.
- Repudiation — iemand ontkent een actie te hebben uitgevoerd, en je kunt het niet bewijzen. "Ik heb dat bestand niet verwijderd." Zonder audit trail is dat het einde van de discussie.
- Information Disclosure — gevoelige informatie lekt naar onbevoegden. Van een verbose foutmelding tot een volledige database-dump.
- Denial of Service — het systeem onbeschikbaar maken. Niet alleen DDoS — ook een query die de database vastloopt of een bestandsupload die de schijf volschrijft.
- Elevation of Privilege — meer rechten krijgen dan de bedoeling is. Van gebruiker naar admin, van read-only naar read-write.
STRIDE is geen checklist die je afvinkt. Het is een denkraamwerk dat je dwingt om systematisch na te denken over categorieën dreigingen die je anders zou missen. Zonder STRIDE denk je aan de voor de hand liggende dingen. Met STRIDE denk je aan de dingen die je niet voor de hand vindt.
Hoe ziet een threat modeling sessie eruit?
Een praktische sessie duurt meestal twee tot drie uur en werkt het best met een gemengd team: ontwikkelaars die het systeem kennen, een security-specialist die de dreigingen kent, en iemand van de business die het risico kan inschatten.
Je begint met een diagram. Geen UML-monstrositeit — een simpele tekening van de componenten, de datastromen, en de vertrouwensgrenzen. Waar komt data binnen? Waar gaat het naartoe? Wie heeft toegang tot wat? Waar zit de grens tussen "vertrouwd" en "niet vertrouwd"?
Vervolgens loop je elk onderdeel langs met STRIDE. Voor elke dataflow, elke component, elke grens: kan hier gespoofed worden? Kan data hier worden aangepast? Kan informatie hier lekken? Het voelt in het begin alsof je paranoia aan het cultiveren bent — en dat is precies de bedoeling.
Veelgemaakte fouten
De meest gemaakte fout is threat modeling behandelen als een eenmalige exercitie. Je doet het bij de start van het project, produceert een mooi document, en kijkt er nooit meer naar om. Ondertussen evolueert het systeem, komen er nieuwe componenten bij, veranderen de dataflows, en is het originele model na zes maanden hopeloos verouderd.
De op één na meest gemaakte fout is te gedetailleerd beginnen. Je hoeft niet elke variabele in je code te modelleren. Begin op architectuurniveau: de grote blokken, de belangrijkste datastromen. Zoom alleen in op de plekken waar het risico het grootst is.
En de derde fout: alleen naar technische dreigingen kijken. De gevaarlijkste aanvallen combineren technische en menselijke elementen. Social engineering, phishing, insider threats — ze staan niet in STRIDE, maar ze horen wel in je dreigingsmodel. Compliance-frameworks zoals SOC 2 verwachten dat je ze meeneemt.
Wanneer doe je het?
Het korte antwoord: zo vroeg mogelijk, en dan steeds opnieuw. Bij elke significante architectuurwijziging, bij elke nieuwe integratie, bij elke verandering in het dreigingslandschap. Het kost tijd — maar het is altijd minder tijd dan het kost om een kwetsbaarheid in productie te repareren die je in de ontwerpfase had kunnen voorkomen.