Threat modelling uitgelegd: STRIDE en vier vragen

Wat is threat modelling?

Threat modelling is nadenken over een systeem voordat een aanvaller dat doet. De OWASP-spiekbrief omschrijft het binnen applicatiebeveiliging als een gestructureerd, herhaalbaar proces om bruikbaar inzicht te krijgen in de beveiligingskenmerken van een systeem. Je modelleert het systeem vanuit beveiligingsperspectief, zoekt de bedreigingen die daarbij horen en bepaalt hoe je erop reageert. Daarbij analyseer je het systeem vanuit het perspectief van een aanvaller en richt je je op de manieren waarop die het kan misbruiken.

Het gaat om het ontwerp en het gedrag van het systeem, niet om een scan van bestaande code. Daarin verschilt het van testen. Een penetratietest of scan kijkt naar wat er is gebouwd, terwijl threat modelling naar het ontwerp en de aannames kijkt. Een ontwerpfout, zoals een wachtwoordreset die een token geeft dat nooit verloopt, vind je met een model vaak sneller dan met een securitytest.

De Amerikaanse spelling van OWASP is threat modeling, met één l. In Nederlandse tekst schrijven we threat modelling met twee l's.

Wanneer doe je het en met wie?

Threat modelling doe je bij voorkeur vroeg in de levenscyclus van softwareontwikkeling, bijvoorbeeld tijdens het ontwerp. De OWASP Developer Guide schrijft dat het beoordelen van bedreigingen in de ontwerpfase aanzienlijk kan besparen ten opzichte van refactoring in een latere fase. Volgens de OWASP-spiekbrief is het geen eenmalige activiteit: een threat model hoort samen met het systeem te worden onderhouden en bijgewerkt. Een model dat eenmalig in een map staat, veroudert snel.

Het is een teamactiviteit. Het Manifesto zet samenwerking en dialoog centraal, en noemt doen in plaats van erover praten en voortdurend verfijnen als waarden. De spiekbrief schrijft dat het model door alle belanghebbenden moet worden beoordeeld, niet alleen door ontwikkelaars of beveiligers.

De vier vragen van threat modelling

Het Manifesto noemt vier kernvragen. De tabel zet ze naast de bijbehorende activiteit en uitkomst.

De OWASP-spiekbrief werkt het proces uit in vier basisstappen, die aansluiten bij deze vier vragen. Er is geen universeel erkende industriestandaard voor het proces. Voor het modelleren is het datastroomdiagram (DFD) volgens de spiekbrief waarschijnlijk de meest gangbare aanpak. Brainstormen is een alternatief, vooral nuttig als minder technische deelnemers meedoen.

Een diagram is eenvoudig. Je tekent rechthoeken voor externe partijen, zoals de gebruiker, afgeronde vormen voor processen, zoals de webapplicatie, twee lijnen voor gegevensopslag, zoals de database, en pijlen voor de datastromen. Een vertrouwensgrens is de lijn waar de mate van vertrouwen verandert, bijvoorbeeld tussen het internet en je webapplicatie. Daar liggen vaak de mogelijke aanvalspunten.

Voor cloudomgevingen noemt de spiekbrief aanvullende aandachtspunten, zoals de verdeling van verantwoordelijkheden tussen aanbieder en klant (shared responsibility), beheerde diensten en API's, multi-tenant en identiteitsfederatie, en dynamische infrastructuur. Zie ook cloud security uitgelegd.

Wat is STRIDE?

STRIDE is een geheugensteun om bedreigingen te vinden. Medewerkers van Microsoft hebben het oorspronkelijk ontwikkeld, en het deelt bedreigingen in zes categorieën in. Elke bedreiging kun je zien als de schending van een eigenschap die je van het systeem wilt.

Microsoft beschrijft spoofing als het zich onrechtmatig toegang verschaffen tot de inloggegevens van een ander. Tampering is het kwaadwillig wijzigen van gegevens, in een database of onderweg over een netwerk. Bij repudiation ontkent een gebruiker een actie, terwijl anderen dat niet kunnen bewijzen. Information disclosure is het blootstellen van informatie aan wie er geen toegang toe hoort te hebben. Denial of service ontzegt geldige gebruikers de dienst, en elevation of privilege betekent dat een gebruiker zonder rechten toch bevoorrechte toegang krijgt. Het Microsoft Threat Modeling Tool is volgens Microsoft een kernonderdeel van de Microsoft Security Development Lifecycle en is bedoeld om ook ontwikkelaars zonder beveiligingsachtergrond te helpen.

Gebruik STRIDE als reeks vragen per onderdeel van het diagram, niet als checklist die je afvinkt. Bij elk onderdeel vraag je of iemand kan doen alsof hij een ander is, of data kan worden gewijzigd, of iemand kan ontkennen dat hij iets deed, of informatie kan lekken, of de dienst kan uitvallen en of iemand meer rechten kan krijgen dan bedoeld. STRIDE helpt om niets te vergeten, maar het is niet de enige goede aanpak.

Rangschikken is het lastige deel. In theorie rangschik je op kans maal impact, maar beide zijn lastig te berekenen en de berekening negeert het werk om het probleem op te lossen. Meer over risico's staat op de skillpagina voor risk assessment.

Welke andere technieken bestaan er?

De OWASP-spiekbrief kiest bij een technisch ontwerp voor STRIDE, en noemt andere technieken als het bereik een andere kijk vraagt. Volgens een vergelijking van het Software Engineering Institute belichten methoden verschillende zorgen en kun je ze combineren. De spiekbrief noemt onder meer:

• Attack trees. Je beschrijft een aanvallersdoel of een aanval in meerdere stappen, beginnend bij het doel.
• Misuse of abuse cases. Je beschrijft misbruik van een geldige workflow of bedrijfsregel.
• LINDDUN. Een methode voor privacy-eigenschappen en privacyschade: Linking, Identifying, Non-repudiation, Detecting, Data disclosure, Unawareness and Unintervenability en Non-compliance. Je gebruikt hem als er persoonsgegevens in het spel zijn, zie ook privacy by design.
• PASTA. Koppelt bedrijfsdoelen en technische eisen aan bedreigingen voor de applicatie.
• OCTAVE. Richt zich op het organisatiebrede risico voor kritieke bedrijfsmiddelen.
• VAST. Visual, Agile, and Simple Threat Modeling, met aparte modellen voor de applicatie en voor operationele zaken, in ontwikkelworkflows.

De spiekbrief waarschuwt ervoor technieken toe te voegen alleen om het model compleet te laten lijken. Op de OWASP-projectpagina staan onder meer Threat Dragon, PyTM en de Threat Model Library als voorbeelden. Het zijn voorbeelden, geen aanbeveling.

Een voorbeeld: de wachtwoordreset van een webshop

Stel dat een webshop een wachtwoordreset heeft. Een gebruiker vraagt een reset aan, ontvangt een link per e-mail en kiest daarna een nieuw wachtwoord. Dit voorbeeld is verzonnen en beschrijft geen echte organisatie of echt incident.

Per bedreiging kies je een reactie. Je verkleint de kans of de gevolgen (mitigate), je verwijdert het onderdeel dat de bedreiging veroorzaakt (eliminate), je legt de verantwoordelijkheid bij een andere partij (transfer) of je accepteert het bewust (accept). Voor de eerste vier bedreigingen in de tabel ligt verminderen het meest voor de hand. Verwijderen betekent hier dat je de resetfunctie vervangt door inloggen zonder wachtwoord. Overdragen kan met een externe identiteitsprovider, maar die verkleint de kans of de gevolgen zelf niet, dus leg je vast wie het restrisico beheert. Accepteren vraagt een bewuste keuze die je vastlegt. Een goed threat model eindigt in concrete acties, zoals eisen in de backlog of een ontwerpaanpassing.

Een controlevraag uit de spiekbrief is of de maatregelen testbaar zijn. Het ontwerpprobleem achter dit voorbeeld hoort bij A06 Insecure Design uit de OWASP Top 10, zie het artikel over OWASP Top 10 en application security.

Wie doet aan threat modelling?

Bij sommige organisaties begeleidt de application security engineer teams en beoordeelt die modellen. Zie ook de rolgids en de werkgevers die deze functie zoeken. De security architect kan ontwerpkeuzes wegen, zie de rolgids en het vakgebied security architecture. De security engineer vertaalt maatregelen naar techniek. De penetration tester kan het model gebruiken om te bepalen waar te testen.

Ontwikkelaars doen mee. De spiekbrief noemt als uitdaging dat veel ontwikkelaars onvoldoende kennis en ervaring met beveiliging hebben, waardoor methodes lastig toe te passen zijn. In OWASP SAMM valt threat modeling onder de praktijk Threat Assessment, met drie niveaus: risicogericht brainstormen met bestaande diagrammen en eenvoudige checklists, daarna standaardiseren van training, processen en tools, en tot slot voortdurend optimaliseren en automatiseren.

Wil je beginnen? Kies één kleine functie van een systeem dat je kent, teken de datastromen, loop STRIDE langs en schrijf per bedreiging een reactie op. Laat het daarna door iemand anders bekijken. Dat is een uitvoerbare eerste oefening voor een portfolio, bijvoorbeeld in een home lab voor security.