TL;DR: Threat modeling is een gestructureerde methode om beveiligingsrisico’s in systemen en applicaties te identificeren nog voor de eerste regel code geschreven is. Door systematisch te analyseren wat er mis kan gaan, welke dreigingen realistisch zijn en welke maatregelen prioriteit verdienen, voorkomt u kostbare kwetsbaarheden in productie. NIS2 en de Cyber Resilience Act maken deze aanpak in 2026 feitelijk verplicht voor Belgische bedrijven en softwareleveranciers.
De meeste bedrijven ontdekken hun kwetsbaarheden pas wanneer het te laat is: tijdens een pentest, na een incident of bij een compliance-audit. Threat modeling draait die volgorde om. Het brengt dreigingen in kaart tijdens de ontwerp- en planningsfase, zodat u beveiligingsbeslissingen neemt op het moment dat ze het minst kosten en het meest impact hebben. In dit artikel leest u wat threat modeling concreet inhoudt, welke frameworks beschikbaar zijn, en waarom het voor Belgische bedrijven en softwareontwikkelaars in 2026 onmisbaar is geworden.
Wat is threat modeling en hoe verschilt het van een pentest?
Threat modeling is een systematisch proces waarbij u de beveiliging van een applicatie, systeem of netwerk analyseert door vier kernvragen te beantwoorden: wat bouwen we, wat kan er misgaan, wat doen we eraan, en is het resultaat voldoende? Het resultaat is een gestructureerd overzicht van alle potentiele dreigingen, de bijbehorende risico’s en de maatregelen om die risico’s te beperken.
Het fundamentele verschil met een penetratietest zit in het tijdstip en de aanpak. Een pentest is detectief: ethische hackers zoeken kwetsbaarheden in een systeem dat al gebouwd is. Threat modeling is preventief: het identificeert dreigingen voordat ze in code terechtkomen. Beide zijn waardevol, maar ze vullen elkaar aan in plaats van elkaar te vervangen.
Waarom dat onderscheid ertoe doet? Volgens onderzoek van IBM en het NIST stijgen de kosten om een beveiligingsfout te herstellen exponentieel naarmate een project vordert. Een kwetsbaarheid die u in de ontwerpfase oplost, kost een fractie van wat dezelfde fout in productie zou kosten (schattingen lopen uiteen van 6x tot 100x duurder). Voor een Belgisch softwarebedrijf kan dat het verschil betekenen tussen een winstgevend project en een financieel debacle door noodpatches en reputatieschade.
In de praktijk werken threat modeling en pentesting het best als tandem. Threat modeling bepaalt de strategie (waar zitten de grootste risico’s?), een pentest valideert de implementatie (zijn die risico’s daadwerkelijk gemitigeerd?).
De vier meest gebruikte threat modeling frameworks vergeleken
Er bestaan tientallen frameworks voor threat modeling, maar vier daarvan zijn bijzonder relevant voor Belgische bedrijven en softwareontwikkelaars. De keuze hangt af van uw context: bouwt u software, beheert u IT-infrastructuur, of moet u privacy-compliance aantonen?
| Framework | Focus | Kernprincipe | Beste inzet |
|---|---|---|---|
| STRIDE | Technisch/software | Zes dreigingscategorieen: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege | Softwareontwikkeling, API-ontwerp, webapplicaties |
| PASTA | Risico/business | Zevenstaps proces dat bedrijfsdoelen koppelt aan aanvalssimulatie | Organisaties met complexe compliance-eisen (NIS2, DORA) |
| LINDDUN | Privacy | Zeven privacydreigingen: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure, Unawareness, Non-compliance | GDPR-compliance, privacy-by-design, dataverwerkingsprocessen |
| OWASP TM | Applicatiebeveiliging | Flexibel, community-gedreven framework met ondersteuning voor cloud, API’s en gedistribueerde architecturen | Moderne webapplicaties, microservices, cloud-native omgevingen |
STRIDE, oorspronkelijk ontwikkeld door Microsoft, is het meest gebruikte framework vanwege de eenvoudige structuur. Elk onderdeel van uw systeem wordt geanalyseerd op zes dreigingscategorieen die rechtstreeks gekoppeld zijn aan beveiligingseigenschappen zoals authenticiteit, integriteit en vertrouwelijkheid. Voor development teams die starten met threat modeling is STRIDE vaak het logische instappunt.
PASTA (Process for Attack Simulation and Threat Analysis) kiest een andere invalshoek: het vertrekt vanuit bedrijfsdoelstellingen en werkt via zeven fasen toe naar concrete aanvalssimulaties. Dat maakt PASTA bijzonder geschikt voor organisaties die threat modeling willen koppelen aan hun NIS2-compliance traject.
LINDDUN verdient bijzondere aandacht. Dit framework is ontwikkeld aan de KU Leuven en richt zich specifiek op privacydreigingen. Voor Belgische organisaties die GDPR-compliance moeten aantonen, biedt LINDDUN een gestructureerde manier om privacyrisico’s al in de ontwerpfase te identificeren. Het is een zeldzaam voorbeeld van een Belgisch framework dat internationaal erkenning geniet.
OWASP Threat Modeling biedt de meeste flexibiliteit en sluit aan bij de bredere OWASP-ecosysteem dat veel ontwikkelteams al kennen. Waar STRIDE rigide categorieeen hanteert, is OWASP aanpasbaar voor moderne architecturen zoals cloud-applicaties, API’s en gedistribueerde systemen.
Het threat modeling proces in vijf stappen
Threat modeling hoeft geen wekenlang traject te zijn. Een gestructureerde sessie van een halve tot een hele dag levert al concrete resultaten op. Het proces volgt vijf logische stappen.
Stap 1: Definieer het systeem. Breng in kaart wat u wilt beschermen. Dat begint met een systeemdiagram (ook wel Data Flow Diagram genoemd) dat alle componenten, datastromen, vertrouwensgrenzen en externe afhankelijkheden visualiseert. Voor softwareteams is dit vaak het architectuurdiagram aangevuld met informatie over welke data waar opgeslagen en verwerkt wordt.
Stap 2: Identificeer dreigingen. Pas een framework toe (STRIDE, PASTA of een ander) om systematisch te analyseren wat er mis kan gaan. Dit is geen brainstorm op gevoel, maar een methodische doorloop van elk systeemonderdeel. Bij STRIDE vraagt u zich per component af: kan iemand zich voordoen als een ander (Spoofing)? Kunnen data gemanipuleerd worden (Tampering)? Enzovoort.
Stap 3: Prioriteer risico’s. Niet elke dreiging is even kritiek. Gebruik een prioriteringsmodel zoals DREAD (Damage, Reproducibility, Exploitability, Affected Users, Discoverability) om een score toe te kennen aan elke dreiging. Dit is essentieel voor KMO’s met beperkte budgetten: u wilt uw middelen inzetten waar het risico het grootst is.
Stap 4: Bepaal mitigaties. Voor elke geprioriteerde dreiging definieert u concrete maatregelen: een technische controle, een procesaanpassing of een bewuste risicoacceptatie. Documenteer waarom u bepaalde risico’s wel of niet mitigeert.
Stap 5: Valideer en herhaal. Een threat model is geen eenmalig document. Bij elke significante wijziging aan het systeem (nieuwe feature, nieuwe integratie, architectuurwijziging) herhaalt u de analyse. Integreer threat modeling in uw secure development lifecycle zodat het een vast onderdeel van het ontwikkelproces wordt.
Wanneer is threat modeling verplicht? NIS2, CRA en ISO 27001
Threat modeling wordt niet letterlijk bij naam genoemd in de Belgische NIS2-wet of de Cyber Resilience Act. Maar de eisen die beide wetgevingen stellen, zijn in de praktijk nauwelijks na te leven zonder een gestructureerde dreigingsanalyse.
NIS2 (Wet van 26 april 2024): Artikel 21 verplicht essentiële en belangrijke entiteiten om “passende en evenredige technische, operationele en organisatorische maatregelen” te nemen op basis van een risicoanalyse. Die risicoanalyse moet rekening houden met de beveiliging bij verwerving en ontwikkeling van systemen, de beveiliging van de toeleveringsketen en procedures voor incidentbehandeling. Threat modeling is de meest effectieve manier om aan deze vereisten te voldoen op applicatie- en systeemniveau.
Daarnaast legt de Belgische NIS2-wet expliciet verantwoordelijkheid bij het bestuursorgaan. Bestuurders moeten cybersecurity-risicobeheersmaatregelen goedkeuren en kunnen persoonlijk aansprakelijk worden gesteld. Threat modeling fungeert hier als instrument voor due diligence: het toont aan dat het management proactief risico’s heeft beoordeeld. Meer over de boetes en bestuurdersaansprakelijkheid leest u in onze NIS2-gids.
Cyber Resilience Act (CRA): De CRA, van kracht sinds december 2024, richt zich specifiek op producten met digitale elementen. Fabrikanten en softwareleveranciers moeten een beveiligingsrisicobeoordeling uitvoeren tijdens de ontwerp- en ontwikkelingsfase. De CRA vereist ook een Software Bill of Materials (SBOM), een machineleesbare inventaris van alle softwarecomponenten inclusief open-source bibliotheken. Threat modeling gebruikt de SBOM als input om de risico’s van externe afhankelijkheden te evalueren. De eerste CRA-meldplichten gelden vanaf 11 september 2026.
ISO 27001 en CyberFundamentals: Het CyFun-framework van het CCB vereist op de niveaus “Important” en “Essential” aantoonbare risicoanalyse. Threat modeling verfijnt de algemene CyFun-risicoanalyse door specifieke technische dreigingen te identificeren die door generieke controles mogelijk niet afgedekt worden.
Threat modeling voor KMO’s: haalbaar of alleen voor grote bedrijven?
Een veelgehoord bezwaar bij Vlaamse KMO’s: “Threat modeling is iets voor grote bedrijven met een dedicated security team.” Dat klopt niet meer. Moderne frameworks en tools hebben de drempel aanzienlijk verlaagd.
De sleutel is proportionaliteit. Een KMO met 80 medewerkers hoeft geen maandenlang threat modeling programma op te zetten. Een gerichte sessie van een halve dag, gefaciliteerd door een externe specialist, levert al een concreet dreigingsoverzicht op voor de meest kritieke systemen. Het OWASP-project Rapid Developer-driven Threat Modeling (RaD-TM) is specifiek ontwikkeld om het proces te versnellen via herbruikbare “threat templates” en een vereenvoudigd zesstappenproces.
Daarnaast ondersteunen AI-gedreven tools het proces steeds beter. Platforms kunnen op basis van systeemdiagrammen automatisch patronen herkennen die duiden op specifieke dreigingen en real-time aanbevelingen doen voor beveiligingscontroles. Volgens recente data kan de inzet van AI in beveiligingsworkflows leiden tot aanzienlijke besparingen op de kosten van een datalek.
Belgische KMO’s hebben bovendien een financieel voordeel. Via het VLAIO Cybersecurity Verbetertraject kunt u tot 50% subsidie krijgen op professionele begeleiding, inclusief threat modeling sessies. De VLAIO KMO-portefeuille biedt daarbovenop 45% subsidie (kleine ondernemingen) of 35% (middelgrote) op cybersecurity-advies.
De ROI spreekt voor zich. De gemiddelde kosten van een datalek bedragen wereldwijd circa 4,88 miljoen dollar (IBM, 2024). Een threat modeling sessie die één kritieke kwetsbaarheid in de ontwerpfase vangt, bespaart een veelvoud van de investering.
Hoe Cyberplan threat modeling inzet
Cyberplan combineert threat modeling met application pentesting en SDL-advies tot een geintegreerde aanpak. Het team van 22 gecertificeerde ethische hackers (OSCP, CISSP, CEH, CISM) brengt de dreigingen in kaart, valideert de mitigaties via gerichte pentests en begeleidt ontwikkelteams bij het structureel inbouwen van beveiliging.
Die combinatie is cruciaal. Threat modeling zonder validatie blijft theorie. Pentesting zonder voorafgaande dreigingsanalyse is schieten met hagel. De kracht zit in de koppeling: het threat model bepaalt wat er getest wordt, de pentest bevestigt of de mitigaties werken.
Benieuwd hoe threat modeling past binnen uw beveiligingsstrategie? Bekijk de threat modeling dienst of plan een vrijblijvend kennismakingsgesprek.
Veelgestelde vragen over threat modeling
Wat kost threat modeling voor een KMO?
De kosten hangen af van de scope en complexiteit van het systeem. Een gerichte sessie voor een webapplicatie start doorgaans bij enkele duizenden euro’s. Via de VLAIO KMO-portefeuille kunt u tot 45% van die kosten terugkrijgen als subsidie, waardoor de netto-investering beperkt blijft.
Hoe vaak moet u een threat model bijwerken?
Werk uw threat model bij na elke significante wijziging: een nieuwe feature, een architectuuraanpassing, een nieuwe integratie met een externe partij of een verandering in het dreigingslandschap. Voor de meeste KMO’s betekent dit minimaal jaarlijks en bij grote releases.
Kan ons development team zelf threat modeling doen?
Ja, mits het team getraind is in de methodiek. Frameworks zoals OWASP RaD-TM zijn specifiek ontworpen om ontwikkelaars zelfstandig threat modeling te laten uitvoeren. Voor de eerste sessie en de training is begeleiding door een externe specialist aan te raden.
Vervangt threat modeling een pentest?
Nee. Threat modeling en pentesting zijn complementair. Threat modeling identificeert dreigingen in de ontwerpfase (preventief), een pentest valideert of het gebouwde systeem bestand is tegen aanvallen (detectief). Beide zijn nodig voor een volledige beveiligingsaanpak.
Is threat modeling verplicht onder NIS2?
NIS2 noemt threat modeling niet letterlijk, maar vereist wel een risicoanalyse als basis voor beveiligingsmaatregelen en “beveiliging bij verwerving en ontwikkeling van systemen”. In de praktijk is een gestructureerde dreigingsanalyse de meest effectieve manier om aan deze vereisten te voldoen.
Wat is het verschil tussen STRIDE en OWASP Threat Modeling?
STRIDE werkt met zes vaste dreigingscategorieen en is het meest geschikt voor traditionele softwareontwikkeling. OWASP Threat Modeling is flexibeler en biedt betere ondersteuning voor moderne architecturen zoals cloud-applicaties, API’s en microservices. Beide zijn valide keuzes; de context bepaalt welk framework het best past.
