Threat Modeling in de Praktijk

Dreigingen Eerst Op Papier Vangen

Dit onderwerp werkt het best als praktisch kader: helder genoeg voor besluitvorming en concreet genoeg voor uitvoering.

In Threat Modeling in de Praktijk is het doel keuzes vastleggen die teams consistent en herhaalbaar kunnen uitvoeren.

Daarmee blijft dit hoofdstuk geen theorie, maar een bruikbaar kompas voor consistente uitvoering.

Directe maatregelen (15 minuten)

• Gebruik deze pagina om maatregelen te prioriteren en in backlog om te zetten.
• Koppel elke maatregel aan eigenaar, deadline en aantoonbaar bewijs.
• Herhaal periodiek op basis van risico, wijzigingen en incidentlessen.

Waarom dit telt

De kern van Threat Modeling in de Praktijk is risicoreductie in de praktijk. Technische context ondersteunt de maatregelkeuze, maar implementatie en borging staan centraal.

Minimum viable threat model

Voor elk kritisch systeem minimaal:

1. Contextdiagram (actoren, systemen, externe afhankelijkheden).
2. Dataflows met trust boundaries.
3. Misuse cases per kritieke flow.
4. Top-risico’s met prioriteit en eigenaar.
5. Concrete controlkeuzes + verificatieplan.

Als één van deze ontbreekt, is het model incompleet.

Werkwijze in 6 stappen

Stap 1: Scope en assets

• bepaal systeemgrenzen;
• markeer kroonjuwelen (data, processen, credentials).

Stap 2: Dataflow tekenen

• leg elke dataoverdracht vast;
• markeer trust transitions expliciet.

Stap 3: Dreigingen identificeren

• gebruik STRIDE of ATT&CK-gebaseerde scenario’s;
• focus op realistische risicopaden, niet op theoretische randgevallen.

Stap 4: Risico prioriteren

• impact x waarschijnlijkheid;
• benadruk ketenafhankelijkheden en detectieblinde vlekken.

Stap 5: Maatregelen kiezen

• voorkeursvolgorde: elimineren > beperken > detecteren > reageren;
• koppel elke maatregel aan eigenaar en implementatietermijn.

Stap 6: Valideren en onderhouden

• valideer met pentest/tabletop;
• update model bij architectuurwijzigingen.

STRIDE praktisch vertaald

STRIDE	Architectuurvraag	Typische maatregel
Spoofing	Kan een actor zich voordoen als een ander?	Sterke authN, token-validatie, mTLS
Tampering	Kan data onderweg of in opslag worden gewijzigd?	Integriteitscontrole, signing, immutability
Repudiation	Kunnen acties ontkend worden?	Audit logs met identity context
Information Disclosure	Lekt gevoelige data buiten scope?	Encryptie, segmentatie, data-minimalisatie
Denial of Service	Kan beschikbaarheid gericht worden verstoord?	Rate limiting, autoscaling, fallback
Elevation of Privilege	Kan een actor rechten opschalen?	Least privilege, policy enforcement, PAM

Uitkomstformat voor teams

Per risico registreer je:

• risico-id;
• scenario;
• impacted asset;
• huidige controls;
• ontbrekende control;
• owner;
• targetdatum;
• bewijs van implementatie.

Dit format maakt threat modeling direct bruikbaar voor backlog en governance.

Koppeling aan architectuur en bestuur

• Architectuur: input voor reference designs en ADR’s.
• Engineering: input voor backlog en testcases.
• Bestuur: input voor top-risico rapportage en investeringsbesluit.

Threat modeling heeft pas waarde als uitkomst leidt tot uitvoering.

Samenvatting

Threat modeling is geen workshopdoel op zich maar een beslismachine: het maakt risicopaden zichtbaar, prioriteert risico’s en koppelt maatregelen aan eigenaarschap en bewijs.

← Vorige ADR Security Besluitvorming Volgende → Redactionele Richtlijn: Defensief-Only