In dit artikel wordt onderzocht hoe regelgeving zoals de CRA en NIS2 van invloed zijn op het beheer van ontwikkelingsrisico’s. We onderzoeken waarom Threat Modeling de standaardoplossing in de branche is en demonstreren de praktische toepassing ervan voor ontwikkelaars, AppSec-leiders en CTO’s.
Ben je al bekend met de basisbeginselen? Dit stuk bouwt voort op ons eerdere artikel, ” Threat Modeling: Een poort naar een veilige ontwikkelcultuur“ over de culturele fundamenten en een gefaseerde aanpak om aan de slag te gaan.
1. Wat de NIS 2- en CRA-regelgeving vereisen op het gebied van risicobeheer
Noch in de CRA noch in de NIS2 wordt de term “Threat Modeling” expliciet gebruikt. Wat ze wel vereisen, komt echter bijna perfect overeen met wat Threat Modeling oplevert.
De Cyberweerbaarheidswet (CRA)
De CRA is in december 2024 in werking getreden en is van toepassing op elk product met digitale elementen dat in december 2027 op de EU-markt wordt gebracht. De kernverplichting is secure-by-design: beveiliging moet vanaf het begin worden ingebouwd, niet achteraf worden toegevoegd.
Concreet vereist de CRA van fabrikanten dat ze:1
- Cyberbeveiligingsrisico’s beoordelen als onderdeel van het productontwikkelingsproces
- Documenteer beveiligingsbeslissingen en hun beweegredenen
- Ervoor zorgen dat kwetsbaarheden gedurende de hele levenscyclus worden geïdentificeerd en aangepakt
- Het principe van standaardbeveiliging/ontwerp toepassen
Elk van deze vereisten komt direct overeen met een resultaat van een goed uitgevoerd Threat Modeling proces: een risicoregister, gedocumenteerde ontwerpbeslissingen, geïdentificeerde aanvalsvectoren en architecturale risicobeperkingen.
NIS2
NIS2 is van toepassing op essentiële en belangrijke entiteiten in kritieke sectoren en breidt de beveiligingsverplichtingen verder uit in toeleveringsketens dan zijn voorganger. Tot de vereisten voor risicobeheer behoren
- Beveiliging moet worden meegenomen in de ontwikkeling van systemen en diensten
- Risico’s van leveranciers en componenten van derden moeten worden beoordeeld
- Incidenten moeten waar mogelijk voorkomen kunnen worden door proactief risicobeheer
Ook hier is Threat Modeling een van de weinige gestructureerde technieken die het bewijs levert waar deze verplichtingen om vragen, met name rond risico’s voor de toeleveringsketen en proactieve besluitvorming over architectuur.
2. Van goede praktijk naar bewijs voor naleving
Hier schieten veel teams tekort: ze doen Threat Modeling als oefening, maar ze behandelen het niet als een compliance artefact. Het verschil is belangrijk. Een Threat Model dat is opgesteld als een whiteboardgesprek is waardevol voor het team. Een Threat Model dat is gedocumenteerd, waarvan versies zijn gemaakt, dat is gekoppeld aan architectuurbeslissingen en dat opnieuw wordt bekeken wanneer het systeem verandert, wordt bewijsmateriaal.
Wat dat in de praktijk betekent:
- Traceerbaarheid: Elke geïdentificeerde bedreiging moet gekoppeld zijn aan een beslissing tot beperking of een aanvaard risico. “We hebben deze aanvalsvector geïdentificeerd, dit is wat we eraan hebben gedaan” is de zin die je compliance documentatie moet kunnen produceren.
- Herhaalbaarheid: Een eenmalig model voor een enkele functie voldoet niet aan de lopende CRA-verplichtingen. Teams hebben een lichtgewicht, herhaalbaar proces nodig dat in elke ontwerpfase kan worden toegepast.
- Versiebeheer: Als het systeem verandert, moet het Threat Model meeveranderen. Dit betekent dat TM-uitvoer moet worden behandeld als levende documenten, niet als momentopnamen.
- Dekking: De reikwijdte van CRA omvat componenten en afhankelijkheden van derden. Threat Modeling moet verder gaan dan je eigen code en ook de bibliotheken, API’s en services omvatten waar je product van afhankelijk is.
De kloof tussen “we doen aan Threat Modeling” en “we kunnen aantonen dat we aan Threat Modeling doen” is precies waar CRA en NIS2 onvoorbereide teams zullen blootstellen. Je moet laten zien dat je hebt nagedacht over risico’s voordat je gaat verschepen.
Hoe het eruit ziet voor elke rol
Hoewel mensen met alle soorten ervaringen hun plaats hebben in de activiteit, verschilt wat het betekent en wat het vraagt afhankelijk van waar je zit.
Voor ontwikkelaars en technici
Het goede nieuws: je hoeft geen beveiligingsexpert te worden2. Threat Modeling op het niveau van ontwikkelaars gaat over de gewoonte om te vragen “wat kan er misgaan?” voordat je code schrijft, niet erna.
In de praktijk kan dit betekenen:
- Een gestructureerd gesprek van 30-60 minuten voeren bij de start van een nieuwe functie of belangrijke verandering
- Een eenvoudig raamwerk zoals STRIDE of de 4 vragen gebruiken als leidraad voor de discussie
- Bedreigingen en overeengekomen mitigaties vastleggen in een lichtgewicht sjabloon, gekoppeld aan het relevante ticket of verhaal
- Onopgeloste risico’s expliciet benoemen in plaats van ze impliciet te laten
De output hoeft geen formeel document te zijn. Het moet vindbaar, toerekenbaar en eerlijk zijn over wat er is overwogen en wat er is besloten.
Voor AppSec/beveiligingsverantwoordelijken
Je rol verschuift van het maken van Threat Models naar het mogelijk maken ervan op schaal. Onder CRA-verplichtingen is de vraag die je moet beantwoorden: kan elk team, voor elke belangrijke functie, een Threat Model produceren dat een toezichthouder kan onderzoeken?
Dat vereist een gestandaardiseerd proces dat geen beveiligingsexpertise vereist om uit te voeren (sjablonen, checklists, lichtgewicht facilitatiegidsen, trainingsmateriaal), maar ook zorgen dat dit goed integreert in bestaande ontwikkelingsrituelen zoals ontwerpbeoordelingen, sprintplanning, architectuurbeoordelingsraden, …
Threat Modeling is voor jou een manier om bedreigingen over teams heen te verzamelen om systemische risico’s en terugkerende patronen te identificeren.
Threat Modeling geeft AppSec-leiders ook iets wat ze vaak missen: een gestructureerde manier om prioriteiten te stellen. Niet elke bedreiging heeft dezelfde reactie nodig. Een gedocumenteerde, op risico gerangschikte achterstand van beveiligingsproblemen is veel beter verdedigbaar en bruikbaar dan een ongedifferentieerde lijst met bevindingen.
Voor CTO’s en CISO’s
De CRA creëert persoonlijke verantwoordelijkheid voor senior leiders op manieren die eerdere raamwerken niet hadden. Secure-by-design is nu een productconformiteitseis met mogelijke gevolgen voor markttoegang. Je moet ervoor zorgen dat je op schema ligt door het je teams te vragen:
- Hebben we een gedocumenteerd proces voor het beoordelen van beveiligingsrisico’s tijdens het ontwerp?
- Kunnen we bewijs laten zien dat we bedreigingen hebben geïdentificeerd en aangepakt voor onze meest recente grote release?
- Bevat onze leveranciers- en afhankelijkheidsbeoordeling veiligheidsrisicocriteria?
- Is ons Threat Modeling proces geïntegreerd in onze SDLC of bestaat het als een parallelle activiteit die onder tijdsdruk wordt overgeslagen?
Investeren in mogelijkheden voor Threat Modeling wordt nu een onderscheidende factor in de markt, omdat klanten en partners nu kijken naar het beveiligingsbeleid van hun softwareleveranciers. Denk aan de praktische gevolgen van het niet kunnen aantonen van compliance wanneer het inkoopteam van een prospect daarom vraagt.
De nalevingsbrug slaan: een praktisch pad
Als je team net begint, “Threat Modeling: Een poort naar een veilige ontwikkelcultuur”. gaat in op de cultuuromslag en de gefaseerde aanpak. Dit artikel gaat verder waar dat artikel ophield.
Als je team al op de een of andere manier aan Threat Modeling doet, al is het maar informeel, dan is de weg naar een compliance-werkwijze korter dan je zou denken. Het gaat vooral om het systematiseren van wat je al doet.
De praktijk voor naleving is korter dan je zou denken. Het gaat vooral om het systematiseren van wat je al doet.
De kern van de zaak
Threat Modeling is altijd een van de meest rendabele investeringen geweest die een ontwikkelteam kan doen, het is een hoeksteen van de ‘linksverschuiving’-mentaliteit. CRA en NIS2 hebben het nu niet-optioneel gemaakt voor een groot deel van de markt.
De teams die het soepelst door deze overgang zullen navigeren, zijn de teams die Threat Modeling hebben ingebed als normaal onderdeel van de manier waarop ze software ontwerpen en bouwen. Geen compliance-oefening die onder druk wordt uitgevoerd, maar een gewoonte die als neveneffect betere software oplevert.
Het goede nieuws: je hoeft die gewoonte niet alleen op te bouwen. Er bestaan frameworks en (sommige) tools zijn licht. De expertise is ook beschikbaar.
Wat nodig is, is de beslissing om te beginnen.