Threat modeling met STRIDE: dreigingen in software vroeg in kaart brengen

Veel beveiligingsproblemen zijn geen implementatiefout maar een ontwerpfout. Een systeem dat van nature te veel vertrouwen plaatst in zijn gebruikers, een dataflow zonder validatie tussen twee componenten, of een autorisatiemodel dat nooit echt is doordacht: zulke zwakheden zijn met geen enkele scanner te vinden en vaak duur om achteraf te repareren. Threat modeling is de gestructureerde methode om dit soort dreigingen vroeg te identificeren, idealiter al voordat er een regel code is geschreven. STRIDE is daarbij het meest gebruikte raamwerk. In dit artikel leggen we uit wat threat modeling inhoudt, hoe je STRIDE praktisch toepast, en hoe het zich verhoudt tot een klassieke risicoanalyse en een pentest.

Wat threat modeling is

Threat modeling is het systematisch nadenken over wat er mis kan gaan met een systeem, vanuit het perspectief van een aanvaller. Het draait om vier kernvragen, in 2014 geformuleerd door Adam Shostack: wat bouwen we, wat kan er misgaan, wat doen we eraan, en hebben we het goed gedaan? De eerste vraag dwingt tot een heldere weergave van het systeem, meestal in de vorm van een data flow diagram met componenten, datastromen, externe entiteiten en vertrouwensgrenzen. De tweede vraag is de kern: het identificeren van dreigingen. De derde gaat over tegenmaatregelen, en de vierde over verificatie.

De grote winst zit in het moment. Een dreiging die je tijdens het ontwerp ontdekt, kost een gesprek en een aanpassing op de tekentafel. Diezelfde dreiging die pas in productie wordt uitgebuit, kost een incident, herstelwerk en mogelijk een meldplicht. Threat modeling verschuift beveiliging naar links in de levenscyclus — het bekende 'shift left'.

STRIDE: zes categorieën dreigingen

STRIDE is een geheugensteun die door Microsoft is ontwikkeld en helpt om per component en datastroom systematisch dreigingen te bedenken. De zes letters staan voor zes categorieën, die elk de tegenpool zijn van een gewenste beveiligingseigenschap.

Spoofing is het zich voordoen als iemand of iets anders, en is de tegenpool van authenticatie. Denk aan een aanvaller die andermans inloggegevens of sessietoken gebruikt, of een service die zich voordoet als een vertrouwde tegenpartij. Tegenmaatregelen liggen in sterke authenticatie en multifactor.

Tampering is het ongeoorloofd wijzigen van data of code, en de tegenpool van integriteit. Het manipuleren van een verzoek, een database of een bestand in transit. Tegenmaatregelen zijn onder meer handtekeningen, hashes en invoervalidatie.

Repudiation is het kunnen ontkennen van een handeling, en de tegenpool van onweerlegbaarheid. Als een systeem niet vastlegt wie wat deed, kan een gebruiker zijn handelingen achteraf ontkennen. Hier helpt betrouwbare, manipulatiebestendige logging.

Information disclosure is het lekken van informatie aan onbevoegden, en de tegenpool van vertrouwelijkheid. Denk aan te uitgebreide foutmeldingen, onversleutelde opslag of een API die meer teruggeeft dan nodig. Versleuteling en strikte gegevensminimalisatie zijn de antwoorden.

Denial of service is het onbeschikbaar maken van een dienst, en de tegenpool van beschikbaarheid. Resource-uitputting, ontbrekende rate limiting of een dure operatie die ongelimiteerd kan worden aangeroepen. Tegenmaatregelen zijn throttling, quota en veerkrachtig ontwerp.

Elevation of privilege is het verkrijgen van rechten waarop men geen recht heeft, en de tegenpool van autorisatie. Een gewone gebruiker die beheerfuncties bereikt, of code die met te hoge rechten draait. Strikte toegangscontrole en het principe van least privilege beperken deze dreiging.

STRIDE in de praktijk toepassen

Een werkbare aanpak begint met het tekenen van het systeem op een whiteboard. Plaats de componenten, teken de datastromen en markeer de vertrouwensgrenzen — de plekken waar data van een minder vertrouwde naar een meer vertrouwde zone gaat. Juist op die grenzen concentreren de interessante dreigingen zich. Loop vervolgens per component of per datastroom de zes STRIDE-categorieën langs en vraag telkens: is deze dreiging hier relevant, en zo ja, wat doen we eraan? Leg de uitkomsten vast: de dreiging, de inschatting van kans en impact, de bestaande of geplande tegenmaatregel en de eigenaar.

Belangrijk is dat threat modeling teamwerk is. Het beste resultaat ontstaat in een sessie met een ontwikkelaar, een architect en iemand met security-expertise, niet als een document dat één persoon achteraf invult. De discussie zelf levert vaak de meeste inzichten op, omdat aannames hardop worden getoetst.

Threat modeling, risicoanalyse en pentest

Deze drie vullen elkaar aan en zijn geen vervanging van elkaar. Een risicoanalyse op organisatieniveau, zoals binnen ISO 27001, kijkt breed naar bedreigingen voor de informatievoorziening en weegt risico's tegen de risicobereidheid van de organisatie. Threat modeling zoomt in op één systeem of applicatie en is veel concreter en technischer. Een pentest, ten slotte, toetst achteraf of de daadwerkelijk gebouwde software bestand is tegen aanvallen.

In de ideale volgorde komt threat modeling eerst: het stuurt het ontwerp en bepaalt welke tegenmaatregelen nodig zijn. De pentest verifieert vervolgens of die maatregelen in de praktijk werken. Een goed threat model maakt een pentest bovendien gerichter, omdat de pentester direct weet waar de gevoelige plekken en aannames zitten. Andersom voeden bevindingen uit een pentest het threat model voor de volgende iteratie.

Veelgemaakte fouten

De eerste en grootste fout is threat modeling te laat doen, als het ontwerp al vastligt of de software al draait. Dan resteert vaak alleen nog het accepteren of duur repareren van risico's. De tweede fout is het te groot aanpakken: een poging om in één keer een heel platform te modelleren loopt vast. Begin klein, bij de meest gevoelige component of de nieuwste functionaliteit. De derde fout is het zien van threat modeling als een eenmalige exercitie. Systemen evolueren, en een threat model dat niet meegroeit, veroudert snel. De vierde fout is het overslaan van de vierde vraag — hebben we het goed gedaan? Zonder opvolging en verificatie blijft een threat model een lijst goede voornemens.

Threat modeling vraagt geen dure tooling; een whiteboard, de juiste mensen en een uur geconcentreerde tijd brengen je een heel eind. De methode schaalt mee: van een lichtgewicht sessie voor een nieuwe feature tot een diepgaande analyse van een kritisch systeem.

Secure Audit helpt organisaties om threat modeling in te bedden in hun ontwikkel- en risicoproces, en combineert dit met risicoanalyses en pentests tot een samenhangende beveiligingsaanpak. Neem contact op voor een vrijblijvend gesprek.