Threat modeling: zet architectuur om in beveiligingsbesluiten

Threat modeling (dreigingsmodellering) stelt de vraag wat er in een bepaald systeem mis kan gaan en wat het team daaraan moet doen. Het nuttige resultaat is geen catalogus van angstaanjagende mogelijkheden. Het is een set ontwerp- en implementatiebesluiten die aan de architectuur zijn gekoppeld, met eigenaren en bewijs dat de gekozen verdediging werkt.

Voor een CTO is de centrale vraag of engineering kan uitleggen hoe belangrijke beveiligingseigenschappen overeind blijven bij echt systeemgedrag: herhaalpogingen, achtergrondtaken, supporthandelingen met verhoogde rechten, storingen bij leveranciers en kwaadwillende invoer. Een diagram maakt die gesprekken concreet. Een onderhouden dreigingsmodel zet de conclusies om in opleverwerk.

De threat-modelingrichtlijnen van OWASP bieden een bruikbare basis: begrijp het systeem, identificeer dreigingen, bepaal hoe u reageert en beoordeel of het werk voldoende is. De onderstaande werkwijze past die denkwijze toe op engineeringbesluiten.

Beschrijf het systeem voordat u aanvallen bespreekt

Begin met een afgebakende functionaliteit, zoals klantexports, het initiëren van betalingen of apparaatupdates. Een heel platform in één keer modelleren levert vaak oppervlakkige observaties op, omdat niemand elke afhankelijkheid in voldoende detail kan uitleggen.

Formuleer de assets en beveiligingsdoelen in operationele termen. ‘Klantgegevens beschermen’ is te breed. ‘Een geauthenticeerde gebruiker kan alleen registraties exporteren die bij de tenant horen waarvoor hij geautoriseerd is’ geeft het team een eigenschap om te testen. Andere doelen kunnen gaan over de integriteit van transacties, beschikbaarheid van de dienst, herstel of de toerekenbaarheid van beheerhandelingen.

Breng gebruikers, diensten, gegevensopslag, externe afhankelijkheden, toegangspunten en vertrouwensgrenzen in kaart. Teken de belangrijke datastromen, inclusief asynchrone verwerking en beheerpaden. Label stromen met de gegevens die ze vervoeren, het authenticatiemechanisme en de autorisatiecontext, waar die de analyse beïnvloeden.

Een vertrouwensgrens markeert een verandering in aannames of bevoegdheid, niet per se een netwerkperimeter. Een browser die een API aanroept, passeert één grens. Een gedeelde worker die namens een klant handelt, passeert een andere, ook als beide diensten in hetzelfde cluster draaien.

Laat bij een multi-tenantapplicatie zien waar de tenantidentiteit wordt vastgesteld en hoe die de autorisatiecontroles, achtergrondtaken en exports bereikt. Neem service-identiteiten, toegang tot objectopslag, supporttools en externe callbacks mee. Anders beschrijft het diagram misschien het ideale pad, terwijl juist de paden ontbreken waarlangs isolatie het eerst wordt omzeild.

Leg aannames apart van feiten vast. ‘De queue kan niet door klanten worden beschreven’ heeft ondersteunend configuratiebewijs nodig. Onbekende zaken moeten onderzoekstaken worden, geen stilzwijgend aangenomen verdedigingen.

Kies een methode die het team helpt redeneren

Een methode levert aanknopingspunten en structuur. Ze bepaalt niet welke dreigingen het zwaarst wegen, bewijst niet dat een ontwerp veilig is en vervangt geen kennis van het systeem.

STRIDE voor systematische aanknopingspunten

STRIDE onderzoekt zes categorieën. Pas ze toe op relevante componenten, stromen en grenzen in plaats van elke categorie op elk element van het diagram te forceren.

Eén scenario kan meerdere categorieën omvatten. Houd waar passend één bruikbare registratie aan in plaats van dubbele tickets aan te maken om aan de taxonomie te voldoen.

Andere methoden voor andere vragen

PASTA, het Process for Attack Simulation and Threat Analysis, biedt een risicogerichte aanpak in zeven fasen die bedrijfsdoelstellingen, technische scope, decompositie, dreigings- en kwetsbaarheidsanalyse, aanvalsmodellering en risicobehandeling met elkaar verbindt. Ze past bij diepere analyses waarin het gedrag van aanvallers en de bedrijfsgevolgen expliciete aandacht nodig hebben.

Attack trees beginnen bij een doel van de aanvaller en splitsen dat op in alternatieve of gecombineerde routes. Voor ‘de export van een andere tenant bemachtigen’ kunnen alternatieven zijn: API-autorisatie omzeilen, de tenantcontext van de worker in verwarring brengen of een downloadcredential stelen. EN-relaties staan voor voorwaarden die tegelijk moeten optreden; OF-relaties staan voor alternatieven.

VAST, Visual, Agile, and Simple Threat modeling, legt de nadruk op schaalbare modellering vanuit applicatie- en operationeel perspectief. Teams die deze methode overwegen, moeten nagaan of hun tooling en ontwikkelproces die perspectieven consistent kunnen onderhouden.

Een praktisch startadvies is een dataflowdiagram plus STRIDE, gevolgd door een attack tree voor het scenario met de grootste gevolgen. Meer methodologie is alleen nuttig als ze tot betere besluiten leidt.

Organiseer de review rond concrete scenario’s

Breng de mensen samen die implementatie en werking begrijpen: een developer, een architect of technisch lead, een securityreviewer en iemand die het gedrag in productie kent. Betrek product-, privacy- of leveranciersspecialisten wanneer hun kennis de scope beïnvloedt.

Verspreid vóór de sessie het diagram, de beveiligingsdoelen, relevante configuratie en openstaande aannames. Loop tijdens de review één verzoek of gebeurtenis door van binnenkomst tot afronding. Vraag waar de identiteit verandert, waar gegevens worden opgeslagen, wat opnieuw wordt geprobeerd en welk component de bevoegdheid heeft een handeling goed te keuren.

Schrijf dreigingen als scenario’s, niet als labels. ‘Autorisatieprobleem’ is niet bruikbaar genoeg. Een sterkere formulering is: ‘Een geauthenticeerde gebruiker vervangt de exportidentificator door die van een andere tenant; het download-endpoint controleert de login maar niet het eigenaarschap van het object, waardoor klantgegevens worden blootgesteld.’

Scheid drie begrippen:

• Een dreiging beschrijft een schadelijke handeling of gebeurtenis, zoals het ongeautoriseerd ophalen van een export.
• Een kwetsbaarheid is een zwakte die haar mogelijk kan maken, zoals een ontbrekende controle op eigenaarschap.
• Risico weegt de waarschijnlijkheid en de gevolgen van het scenario in de werkelijke omgeving.

Een dreiging kan het onderzoeken waard zijn voordat een kwetsbaarheid is bevestigd. Evenzo betekent het vinden van een zwakte niet dat elke denkbare aanval uitvoerbaar is.

Neem naast externe aanvallen ook misbruik door legitieme gebruikers, insiders met verhoogde rechten, configuratiefouten en storingen bij leveranciers mee. Vraag wat er gebeurt wanneer een afhankelijkheid een time-out geeft of een onverwacht antwoord teruggeeft. Fail-opengedrag en inconsistente herhaalpogingen komen vaak juist in deze gesprekken naar boven.

Uitgewerkt voorbeeld: een multi-tenant exportpijplijn

Het volgende voorbeeld is illustratief. Stel dat een SaaS-applicatie een browserclient, een API, een gedeelde database, een job queue, een exportworker en objectopslag heeft. Tenantgebruikers vragen CSV-exports aan; de worker genereert bestanden en de API geeft tijdelijke downloadlinks uit. Supportbeheerders hebben een aparte interface voor probleemoplossing.

De beveiligingsdoelen zijn tenantisolatie, geautoriseerd starten van exports, begrensd verbruik van middelen en toerekenbare supporthandelingen. Stel dat de worker databasetoegang heeft die ruim genoeg is om meerdere tenants te bedienen. Dat maakt de omgang met de tenantcontext tot een centraal besluit in plaats van een klein implementatiedetail.

Volg de bevoegdheid door de stroom

Bij de API wordt de geauthenticeerde principal gekoppeld aan het toegestane tenantlidmaatschap. Een tenantidentificator die de browser meestuurt, is een selectieverzoek, geen bewijs van autorisatie. De API controleert lidmaatschap en exportrechten voordat ze een onveranderlijke taakregistratie aanmaakt met de geautoriseerde tenant, de aanvrager en de toegestane exportscope.

Het queuebericht verwijst naar die registratie. De worker valideert de taak en dwingt bij het maken van de export tenantgebonden gegevenstoegang af. Metadata in de opslag koppelt het resulterende object aan de taak en de tenant. Voordat de API een downloadlink uitgeeft, controleert ze de autorisatie van de huidige aanvrager aan de hand van die koppeling.

Ook dit ontwerp vraagt om expliciete besluiten over het intrekken van toegang: moet een gebruiker die na het aanvragen van een export zijn lidmaatschap verliest, toegang houden tot het voltooide bestand? Het team moet dat beleid vaststellen en consistent implementeren.

Zet scenario’s om in maatregelen en tests

Tijdelijke links introduceren een resterend blootstellingsvenster: bezit kan, afhankelijk van het mechanisme, toegang geven tot het verlopen. Het team moet beslissen of dat aanvaardbaar is voor de betrokken gegevens, of dat downloads een geauthenticeerde tussenschakel met actuele autorisatiecontroles nodig hebben.

Sluit het model niet af nadat alleen de synchrone API is getest. Verifieer vertraagde taken, herhaalpogingen, geannuleerde verzoeken, verlopen lidmaatschap, verwijderde tenants en gedeeltelijke fouten. Een opnieuw uitgevoerde taak mag bijvoorbeeld geen object hergebruiken dat aan een andere tenant is gekoppeld, en mag geen onvolledige export als geslaagd publiceren.

Het resultaat is een beoordeelde architectuur, een dreigingsregister, implementatietaken en gekoppelde verificatieresultaten. Het is niet alleen het diagram.

Prioriteer op basis van blootstelling en gevolgen

Prioriteer plausibele scenario’s op basis van blootstelling, impact, voorwaarden en bestaande verdediging. Maak onderscheid tussen een direct bereikbare autorisatiefout en een scenario dat meerdere onbewezen compromitteringen vereist. Neem waar relevant de betrokken gegevens, verstoring van de dienst, financiële gevolgen, veiligheidsimplicaties en de moeilijkheid van herstel mee.

Gebruik een eenvoudige, consistente schaal als dat het team helpt, maar leg de onderbouwing van de beoordeling vast. Een numerieke score met onverklaarde input creëert schijnprecisie. CVSS kan helpen bij het beoordelen van een concrete kwetsbaarheid; het is geen vervanging voor inzicht in de bedrijfsimpact of een architecturaal misbruikscenario.

Behandelopties zijn onder meer het ontwerp wijzigen, de blootstelling verkleinen, preventieve of detecterende maatregelen toevoegen, de functionaliteit vermijden of het resterende risico accepteren. Leverancierscontracten kunnen verantwoordelijkheden toewijzen, maar nemen technische faalwijzen niet weg.

Restrisico moet een benoemde beslisser, een reden, een vervaldatum of reviewaanleiding en eventuele randvoorwaarden voor de werking hebben. Het afronden van engineeringwerk en het accepteren van risico zijn verschillende besluiten. Een ticket kan klaar zijn terwijl er een wezenlijk risico blijft bestaan.

Neem het model mee in oplevering en bewijs

Leg voor elk wezenlijk scenario de identificator, de betrokken componenten, de voorwaarden, het gevolg, de bestaande verdediging, de behandeling, de eigenaar en de verificatiemethode vast. Koppel de registratie aan de versie van de architectuur en het relevante implementatiewerk, zodat beoordelaars kunnen zien welk ontwerp is beoordeeld.

Vertaal behandelingen naar toetsbare acceptatiecriteria. ‘Toegangsbeheer verbeteren’ is vaag. ‘Tenant A kan via geen enkel ondersteund endpoint de export van tenant B aanvragen, opvragen, annuleren of downloaden’ benoemt gedrag dat engineering kan verifiëren.

Gebruik bewijs dat past bij de bewering:

• Code review kan vaststellen waar autorisatie wordt afgedwongen.
• Configuratie-inspectie kan servicerechten en blootstelling van opslag vaststellen.
• Negatieve integratietests kunnen grenzen tussen tenants en bevoegdheden op de proef stellen.
• Load- en fault-injectiontests kunnen beschikbaarheid en foutgedrag onderzoeken.
• Gerichte penetratietests kunnen aanvalspaden onderzoeken die onafhankelijke verkenning nodig hebben.

Geen enkel afzonderlijk artefact bewijst het hele model. Een screenshot van een instelling bewijst niet dat elke worker die gebruikt, en een geslaagde test toont geen ongetest pad aan. Leg de testomgeving, de scope, de resultaten en de beperkingen vast.

Threat modeling vult secure coding, beoordeling van afhankelijkheden, kwetsbaarheidsscans en penetratietests aan. De onderscheidende bijdrage is architecturaal redeneren: het kan een gevaarlijke verdeling van bevoegdheden aan het licht brengen, zelfs wanneer afzonderlijke componenten geen bekende kwetsbaarheid hebben.

Houd tooling en automatisering ondergeschikt aan het model

Een gedeeld diagram en een gestructureerd register kunnen een eerste, gerichte review ondersteunen. Gespecialiseerde tools worden nuttig wanneer teams herbruikbare componentbibliotheken, consistente identificatoren, samenwerking en betrouwbare koppelingen tussen dreigingen en opleverregistraties nodig hebben.

Beoordeel of een tool vertrouwensgrenzen, eigen scenario’s, versiegeschiedenis, exporteerbare registraties, eigenaarschap en verwijzingen naar bewijs ondersteunt. Automatisch gegenereerde dreigingen zijn aanknopingspunten om te onderzoeken, geen bevestigde bevindingen. Lange lijsten zonder context kunnen de paar besluiten die ertoe doen verbergen.

AI-ondersteuning kan scenariobeschrijvingen opstellen, ontbrekende paden voorstellen of wijzigingen vergelijken met een eerder model. Menselijke beoordelaars moeten nog steeds de architectuur, de uitvoerbaarheid, de dekking van mitigaties en het restrisico valideren. Houd vertrouwelijke diagrammen en credentials buiten niet-goedgekeurde diensten. Het genereren van een dreigingsmodel is bovendien iets anders dan detectie tijdens runtime; een model maken betekent geen continue monitoring of geautomatiseerd herstel.

Herzie het model wanneer de architectuur of aannames veranderen

Werk het model bij voor nieuwe integraties, wijzigingen in authenticatie, handelingen met verhoogde rechten, gegevenscategorieën, netwerkblootstelling en grote wijzigingen in afhankelijkheden. Ook een incident of een onverwacht testresultaat kan een eerdere aanname ongeldig maken.

Verschillende systemen vragen om een verschillende nadruk. Cloudapplicaties vragen aandacht voor identiteitsrechten en toegang tot het managementvlak. Mobiele clients moeten worden behandeld als omgevingen die de aanvaller beheerst, niet als vertrouwde handhavingspunten. Verbonden apparaten introduceren fysieke toegang, integriteit van updates, herstel en mogelijk veiligheidsgevolgen. Functies met AI voegen niet-vertrouwde inhoud en grenzen rond toolgebruik toe; autorisatie moet handelingen beperken, ongeacht de uitvoer van het model.

Meet of belangrijke stromen actuele modellen hebben, of behandelingen met hoge prioriteit verificatiebewijs hebben, welke aannames nog openstaan en of reviews van geaccepteerde risico’s achterstallig zijn. Alleen dreigingen tellen beloont volume in plaats van bruikbare analyse. Vraag periodiek een onafhankelijke beoordelaar om één kritiek scenario en het bijbehorende bewijs kritisch te bekijken.

Maak de eerste review klein genoeg om af te ronden

Secani kan de werkwijze rond deze besluiten vastleggen door relevante systemen en afhankelijkheden te modelleren, eigenaren en beoordelaars toe te wijzen en bewijs te verbinden met eisen, maatregelen en besluiten. Openstaande aannames worden taken; bronmateriaal en menselijke goedkeuringen blijven aan de review gekoppeld. Door AI ondersteunde suggesties moeten vóór goedkeuring worden gecontroleerd.

Begin met één kritieke datastroom. Volg de bevoegdheid van begin tot eind, identificeer een handvol plausibele scenario’s en rond af met behandelingen die een eigenaar hebben en expliciete verificatiecriteria. Plan de volgende review rond de architectuurwijzigingen die die besluiten ongeldig kunnen maken.