Threat modeling: van kwetsbaarheid naar beheersing

Datalekken en ransomware zijn geen uitzonderingen meer. Toch zien we dat veel organisaties risico’s pas serieus overwegen wanneer het al misgaat. Dat is zonde. Met threat modeling breng je risico’s vroegtijdig en gestructureerd in kaart, zodat je ze voorkomt in plaats van oplost.

Doel van threat modeling

Threat modeling helpt je om inzicht te krijgen in mogelijke dreigingen voor je systeem. Die dreigingen zijn niet alleen technisch van aard.

• Fouten in code of architectuur
• Onbedoeld handelen van gebruikers
• Misbruik via social engineering

Het verschil met traditioneel denken? Je kijkt niet naar use cases, maar naar abuse cases. Niet: hoe hoort het systeem te werken? Maar: hoe kan het misgaan?

Hoewel de techniek vaak centraal staat, is threat modeling breder toepasbaar. Denk ook aan fysieke beveiliging van panden of processen.

Begin vroeg en blijf herhalen

Voorkomen werkt alleen als je op tijd begint. Idealiter start je met threat modeling vóór het technisch ontwerp van de applicatie. Zo neem je risico’s direct mee in architectuurkeuzes.

Maar daar stopt het niet.

Software verandert continu. Denk aan nieuwe features, aanpassingen in architectuur en integraties met andere systemen. Elk van die veranderingen introduceert nieuwe risico’s.

Plan daarom periodiek sessies:

• Bij nieuwe features
• Bij architectuurwijzigingen
• Minimaal jaarlijks als vast onderdeel van je proces

De aanpak in vier stappen

Een effectieve threat modeling sessie bestaat uit vier stappen:

1. In kaart brengen van de applicatie
2. Identificeren van dreigingen
3. Prioriteren van risico’s
4. Bepalen van maatregelen

Belangrijk: betrek verschillende disciplines. Developers, infra-specialisten, security experts en business stakeholders kijken allemaal anders naar hetzelfde systeem. Juist die combinatie maakt het sterk. Een effectieve manier van threat modeling is een brainstormsessie houden met alle disciplines.

1. In kaart brengen van de applicatie

Het start met het inzichtelijk maken van hoe de applicatie werkt, of hoe deze is opgebouwd. Je brengt de verschillende componenten en hun onderlinge interacties in kaart. Daarbij zijn zogeheten trust boundaries belangrijk: de punten waar systemen, diensten of gebruikers met elkaar communiceren. Juist op die overgangen ontstaan vaak kwetsbaarheden. Ze vormen daarom een logisch en effectief startpunt bij het analyseren van risico’s.

2. Identificeren van dreigingen

Dit is vaak het lastigste onderdeel. Je probeert systematisch te bedenken waar het mis kan gaan. Dat kan vanuit verschillende invalshoeken:

• Vanuit de software: bekende kwetsbaarheden en patronen
• Vanuit de assets: wat wil je beschermen?
• Vanuit de aanvaller: hoe zou jij het systeem breken?

Een praktische manier om dit concreet te maken, is werken met persona’s:

• Hannah de hacker, professioneel en gericht op datadiefstal
• Scott de scripter, gebruikt kant-en-klare tools
• Domme Diane, maakt onbedoeld fouten
• Boze Bart, interne kennis, kwade intenties
• Ontevreden Onno, wil reputatieschade veroorzaken

Door vanuit deze perspectieven te denken, kom je sneller tot realistische scenario’s.

Werk dit visueel uit (bijvoorbeeld met post-its) en benoem zoveel mogelijk dreigingen. Ook als ze onwaarschijnlijk lijken. Filteren doe je later.

3. Prioriteren met DREAD

Niet elk risico vraagt dezelfde aandacht. Daarom breng je prioriteit aan, bijvoorbeeld met het DREAD-model:

• Damage: wat is de impact?
• Reproducibility: hoe herhaalbaar is het?
• Exploitability: hoe makkelijk is het uit te voeren?
• Affected users: hoeveel gebruikers worden geraakt?
• Discoverability: hoe vindbaar is het?

Geef elk onderdeel een score (bijvoorbeeld 1 - 3) en bereken een gemiddelde. Zo ontstaat een overzicht van wat echt aandacht nodig heeft.

Documenteer de uitkomsten. Niet alleen voor opvolging, maar ook om als organisatie beter te worden in het herkennen van gevaren. Bij sommige organisaties is het ook onderdeel van bepaalde certificeringen of het informatiebeveiligingsbeleid.

4. Maatregelen

Na een threat modeling sessie heb je inzicht in de belangrijkste dreigingen en hun prioriteit. Die gebruik je om gerichte keuzes te maken. Bij nieuwe functionaliteit neem je risico’s direct mee in ontwerp en implementatie. In bestaande systemen los je kwetsbaarheden op op basis van prioriteit. Leg daarbij vast wat is opgelost en wat nog openstaat, zodat je overzicht houdt en gericht kunt sturen.

5. Uitdagingen

Wanneer je voor het eerst een threat modeling sessie organiseert, lopen teams vaak tegen dezelfde valkuilen aan:

• De verkeerde mensen aan tafel
• Te veel focus op oplossingen in plaats van analyse
• Te veel detail, of juist te weinig diepgang
• Onvoldoende structuur in de sessie

De oplossing zit vooral in herhaling. Door dit regelmatig te doen, wordt threat modeling een vast onderdeel van je ontwikkelproces.

Meer weten?

Bij Betabit bouwen en beheren we bedrijfskritische software, waarbij beveiliging vanaf de basis wordt meegenomen. We werken met bewezen aanpakken zoals threat modeling en Privacy by Design om risico’s vroegtijdig te beheersen.

Die kennis delen we ook graag. In onze threat modeling workshop ga je met je team aan de slag om threat modeling in praktijk te brengen onder begeleiding van een ervaren trainer/coach. Aan het einde van de workshop heb je een goed overzicht van de kwetsbaarheden en een gedegen plan van aanpak. Daarnaast bieden we verschillende security- en softwareontwikkelingstrainingen waarmee je jouw team verder versterkt.

Wil je hier meer over weten, of eens sparren over jullie situatie? Neem gerust contact met ons op.