Een developmentteam kan in een uur een threat model maken voor een feature, als het vier vragen in de juiste volgorde beantwoordt en de sessie afsluit met tickets in plaats van een document. De vragen komen uit het Threat Modeling Manifesto: waar werken we aan, wat kan er misgaan, wat gaan we eraan doen en hebben we het goed genoeg gedaan. Een security architect is niet nodig, omdat het werk niet afhangt van het aangeboren talent van één persoon.
Het uur in één oogopslag
| Minuten | Vraag | Resultaat |
|---|---|---|
| Vooraf | - | Eén persoon maakt een conceptdiagram van de datastromen |
| 0-10 | Waar werken we aan | Gecorrigeerd diagram, genummerde entry points |
| 10-30 | Wat kan er misgaan | Lijst met threats, gegroepeerd per STRIDE-categorie |
| 30-45 | Wat gaan we eraan doen | Een respons voor elke threat |
| 45-55 | Tickets en tests | Eén ticket en één test per mitigatie |
| 55-60 | Hebben we het goed genoeg gedaan | Controle op volledigheid |
Voorafgaand aan de sessie
Kies één feature, niet een heel product. Problemen vinden tijdens het ontwerp is veel efficiënter dan gebreken in productie oplossen, dus houd de sessie voordat de bouw begint.
Nodig een developer uit, de eigenaar van de requirements en, als er infrastructuur bij betrokken is, iemand van operations. Een van hen brengt een concept van het dataflowdiagram mee, gemaakt in een tool waarvan het team de bestanden later kan bewerken.
Minuut 0-10: waar werken we aan
De groep corrigeert het concept. De OWASP Threat Modeling Cheat Sheet vraagt om een helder beeld van trust boundaries, datastromen, datastores, processen en externe entiteiten, die vaak mogelijke aanvalspunten vormen. Controleer of ze er allemaal op staan.
Als sommige deelnemers niet technisch zijn, brainstorm dan op een whiteboard over de stromen in plaats van aan te dringen op DFD-notatie.
Nummer de entry points gaandeweg, met major.minor-notatie voor gelaagde punten (1, 1.2, 1.2.1), zoals ook de OWASP community-pagina over het proces doet, en markeer ook de exit points. Een foutmelding op een inlogpagina kan aanvallen mogelijk maken via het bijbehorende entry point, zoals account harvesting ("gebruikersnaam niet gevonden") of SQL injection (via SQL-foutmeldingen).
Minuut 10-30: wat kan er misgaan
Begin bij een technisch ontwerp met STRIDE. Loop elk component, elke datastroom en elke trust boundary langs de zes categorieën en noteer bij elke threat welk entry point-ID erbij hoort.
| Categorie | Schendt | Voorbeeld |
|---|---|---|
| Spoofing | Authenticatie | Gestolen authenticatietoken gebruikt om zich voor te doen als een gebruiker |
| Tampering | Integriteit | Onbedoelde database-updates via de applicatie |
| Repudiation | Verantwoording | Logs gemanipuleerd om handelingen te verbergen |
| Information Disclosure | Vertrouwelijkheid | Gegevens onttrokken aan een database met gebruikersaccounts |
| Denial of Service | Beschikbaarheid | Gebruiker buitengesloten door veel mislukte authenticatiepogingen |
| Elevation of Privileges | Autorisatie | Een JWT aangepast om de rol te wijzigen |
Voeg bij een bedrijfsregel misuse cases toe: handelingen die in de verkeerde volgorde, herhaaldelijk, gelijktijdig of voor een onbedoeld resultaat worden uitgevoerd. Gebruik voor één aanvalsdoel met meerdere stappen een attack tree. Voeg geen technieken toe om grondig te lijken; leg uit waarom elke techniek past en wat ze onbelicht laat.
Kans maal impact klinkt overzichtelijk, maar beide zijn lastig in te schatten en het product negeert de kosten van de oplossing. In één uur volstaat een grove inschatting per threat: hoog, midden of laag.
Een uitgewerkt voorbeeld: wachtwoord resetten
Neem een wachtwoordreset. Het diagram toont de browser, de webapplicatie, de gebruikersdatabase en een mailservice, met een trust boundary tussen internet en de applicatie. Het resetverzoek is entry point 3 en de link in de e-mail is 3.1 (ter illustratie gekozen ID's).
De groep vindt vier threats. Een resetlink werkt voor iemand anders dan de eigenaar (spoofing). Een melding "geen account met dit adres" onthult wie er geregistreerd is (information disclosure). Resetgebeurtenissen worden niet gelogd (repudiation). Iemand activeert herhaaldelijk resets voor een slachtoffer (denial of service).
Minuut 30-45: wat gaan we eraan doen
Elke threat krijgt een van vier responses:
- Mitigeren: de kans verkleinen dat de threat zich voordoet.
- Elimineren: de feature of het component weghalen dat de threat veroorzaakt.
- Overdragen: de contractuele of financiële verantwoordelijkheid bij een andere partij leggen.
- Accepteren: niets doen, omdat de andere opties niet passen binnen de zakelijke randvoorwaarden.
Overdragen verkleint op zichzelf de kans of de schade niet, dus leg vast wie de resterende maatregelen en het restrisico beheert. Noteer bij geaccepteerde threats wie het risico heeft geaccepteerd en waarom.
Minuut 45-55: tickets en tests
Zet elke afgesproken mitigatie om in een requirement die een developer kan oppakken. Eén rij per threat is genoeg:
| Threat ID | STRIDE | Ticket | Test |
|---|---|---|---|
| 3.1-S | Spoofing | Maak resetlinks eenmalig bruikbaar en kortlevend | Een gebruikte of verlopen link wordt geweigerd |
| 3-I | Information Disclosure | Geef voor elk adres dezelfde generieke respons | Bekende en onbekende adressen geven identieke responses |
| 3-R | Repudiation | Log elk resetverzoek | Een resetpoging verschijnt in de log |
De testkolom maakt het model meer dan een diagram. Elke mitigatie heeft een controle nodig die faalt als de maatregel ontbreekt. Abuse cases laten zich direct vertalen: speel het verzoek opnieuw af, stuur de stappen in de verkeerde volgorde, stuur twee verzoeken tegelijk. Zet de tickets in de eigen backlog van de feature, met het threat ID in de titel.
Minuut 55-60: hebben we het goed genoeg gedaan
Begin met een eenvoudige controle: zijn er vastgelegde stukken met een diagram, een lijst met threats en een lijst met maatregelen? Ontbreekt er een, dan is de sessie nog niet af. Controleer of elke threat een respons heeft, of bij elke mitigatie staat hoe het team die gaat implementeren en of bij geaccepteerde risico's staat waarom.
Houd het model daarna levend. Werk het bij samen met het systeem en draai bij een ontwerpwijziging alleen de betrokken onderdelen opnieuw.
Waar begint u
- Kies een aankomende feature en reserveer een uur met een developer, de eigenaar van de requirements en iemand van operations.
- Laat één persoon het dataflowdiagram opstellen, met de trust boundaries gemarkeerd. De groep corrigeert het en nummert de entry points in de eerste tien minuten.
- Pas 20 minuten lang STRIDE toe op elk component en elke stroom, en noteer bij elke threat het ID van het betrokken entry point.
- Wijs aan elke threat een respons toe, noteer wie eigenaar is van elk geaccepteerd of overgedragen risico en maak vervolgens één ticket en één test per mitigatie.
- Bewaar het diagram, de lijst met threats en de lijst met maatregelen bij de documentatie van de feature. Wilt u een externe blik op het eerste model, dan kan onze adviesdienst het beoordelen, en de vastgelegde threats vormen een goede scope voor een latere penetratietest.
