Bedreigingsmodellering integreren met DevOps

Dit bericht is geschreven door Britna Curzi, Anthony Nevico, Jonathan Davis, Raphael Pazos Rodriguez en Ben Hanson

Inleiding

Threat modeling is een belangrijke beveiligingsmethode die helpt bij het identificeren en prioriteren van de belangrijkste risicobeperking voor een toepassing of systeem. Dit document bevat enkele reflecties over hoe het mogelijk is om bedreigingsmodellering effectiever en efficiënter te gebruiken, deze te integreren met moderne DevOps-methodologieën en -hulpprogramma's, en zich te concentreren op de waarde die is verstrekt aan alle verschillende actoren die betrokken zijn bij de levenscyclus van softwareontwikkeling.

Is dit artikel voor jou?

Dit document is het resultaat van het werk van een klein team beveiligings- en bedreigingsmodelleringsexperts van Microsoft en bevat invoer en ideeën van enkele van de meest prominente experts van buiten Microsoft. Er wordt geprobeerd een eenvoudige maar dringende vraag aan te pakken: wat moeten we doen om ervoor te zorgen dat het bedreigingsmodelleringsproces dat we gebruiken, wordt bijgewerkt naar de moderne vereisten die worden opgelegd door Agile-methodologieën en DevOps, zodat we de vereiste waarde tegen de laagste kosten bieden?

Als u een producteigenaar bent, het lid van een beveiligingsteam of gewoon een ontwikkelaar die overweegt om bedreigingsmodellering te gebruiken als onderdeel van uw ontwikkelingslevenscyclus, is dit document voor u.

Als u al bedreigingsmodellering hebt gebruikt, kunt u nog steeds praktische ideeën vinden om uw proces te verbeteren.

Toch is het document ontworpen om ideeën te introduceren om de huidige processen te verbeteren of om bedreigingsmodellering in te voeren als onderdeel van uw DevOps-proces. Het introduceert geen specifieke hulpprogramma's of producten, zelfs als het onze hoop is om deze ideeën te zien die in de toekomst door sommige hulpprogramma's of producten zijn geïmplementeerd. Daarom vindt u hier geen aankondigingen van nieuwe hulpprogramma's of previews van toekomstige functies.

Waarom is threat modeling belangrijk?

Threat Modeling is een van de belangrijkste benaderingen voor het veilig ontwerpen van softwareoplossingen. Met threat Modeling analyseert u een systeem aanvalsvectoren en ontwikkelt u acties voor het beperken van risico's die door deze aanvallen worden veroorzaakt. Op de juiste wijze is threat modeling een uitstekend onderdeel van elk risicobeheerproces. Het kan ook helpen om kosten te verlagen door ontwerpproblemen vroeg te identificeren en op te lossen. Een oud onderzoek van NIST schatte de kosten voor het oplossen van een ontwerpprobleem in productiecode ongeveer 40 keer hoger dan het herstellen ervan tijdens de ontwerpfase. Het bespaart ook kosten als gevolg van beveiligingsincidenten voor de toekomstige ontwerpproblemen. Houd er rekening mee dat het 2022 Cost of Data Breach Report van IBM Security en het Ponemon Instituut de gemiddelde kosten van een gegevenslek schat op $4,35 miljoen. Voor de zogenaamde Mega-schendingen, waarbij meer dan 50 miljoen records zijn betrokken, zijn de gemiddelde kosten $ 387M!

Threat modeling is de eerste activiteit die u kunt uitvoeren om uw oplossing te beveiligen, omdat deze werkt in het oplossingsontwerp. Dit kenmerk maakt het de meest effectieve beveiligingspraktijk die u op uw SDLC kunt toepassen.

Microsoft heeft een lange geschiedenis met threat modeling. In 1999 schreef twee (toen) Microsoft-werknemers, Loren Kohnfelder en Praerit Garg, een document, De bedreigingen voor onze producten. In dit document is de STRIDE-benadering geïntroduceerd, een synoniem voor het Microsoft Threat Modeling-proces.

Bedreigingsmodellering is een evolutief proces

Threat modeling is geen statisch proces; het ontwikkelt zich naarmate de behoeften veranderen en technologieën veranderen.

• Supply Chain-aanvallen zoals de recente aanval op SolarWinds laten zien dat er meer scenario's nodig zijn voor Threat Modeling dan de oplossing zelf, inclusief ontwikkeling en implementatie.

• Open Source-beveiligingsproblemen zoals de recente voor Log4j hebben aangetoond dat de huidige aanpak moet worden aangevuld op basis van de acceptatie van hulpprogramma's voor softwaresamenstellingsanalyse om te scannen op kwetsbare onderdelen door de oplossing defensief te ontwerpen om de blootstelling ervan te beperken.

• De toepassing van nieuwe technologieën zoals Machine Learning introduceert nieuwe aanvalsvectoren die moeten worden begrepen en gecontroleerd. Denk bijvoorbeeld aan de mogelijkheid om kwaadaardig geconstrueerde geluiden af te spelen die voor mensenoren onhoorbaar zijn, waardoor AI-services opdrachten uitvoeren, zoals besproken in .

Bij Microsoft oefenen verschillende productgroepen verschillende varianten van threat modeling uit op basis van hun specifieke beveiligingsvereisten. Elke variant is erop gericht een adequaat beveiligingsniveau te garanderen voor de scenario's waarop deze wordt toegepast, maar wat 'voldoende' betekent dat wijzigingen worden aangebracht, afhankelijk van de specifieke context.

Het beveiligen van Windows verschilt bijvoorbeeld van het beveiligen van Azure Cognitive Services, omdat deze systemen zeer verschillende grootten en kenmerken hebben. Een belangrijk aspect van threat modeling is het verdelen van de kosten ten opzichte van de risicotolerantie voor een toepassing. Hoewel dit kan leiden tot de beslissing om bedreigingsmodellering helemaal te voorkomen voor sommige scenario's, is het zo effectief wanneer dit op de juiste manier wordt gedaan, dat we het alleen kunnen aanbevelen voor elk IT-initiatief, inclusief projecten voor softwareontwikkeling en infrastructuurimplementatie.

Het belang van het focussen op de ROI

De afgelopen jaren is er een constante toename in interesse voor dreigingsmodellering als een belangrijk softwareontwikkelingsproces gezien. Dit belang is te wijten aan de exponentiële toename van aanvallen op infrastructuren en oplossingen. Initiatieven zoals de aanbevolen minimumstandaard van NIST voor de verificatie van code voor leveranciers of ontwikkelaars en het manifest voor bedreigingsmodellen hebben de vraag verder verhoogd tot het punt dat de huidige benaderingen enkele limieten hebben getoond. De resultaten van bedreigingsmodellering zijn bijvoorbeeld sterk afhankelijk van het aangenomen proces en van wie het bedreigingsmodel uitvoert. Er is dus een zorg om consistent hogere kwaliteit uit de ervaring te halen.

Maar wat betekent kwaliteit voor bedreigingsmodellering? Voor ons moet een kwaliteitsrisicomodel de volgende kenmerken hebben:

• Het moet bruikbare oplossingen identificeren, activiteiten die u kunt doen om de potentiële verliezen te verminderen die het gevolg zijn van aanvallen. Uitvoerbaar betekent dat deze oplossingen goed moeten zijn gedefinieerd, wat betekent dat u voldoende informatie krijgt om ze te implementeren en vervolgens de implementatie te testen. Dit betekent ook dat ze zodanig moeten worden verstrekt dat het ontwikkelingsteam er eenvoudig gebruik van kan maken. Met DevOps en Agile betekent dit dat er een eenvoudige manier is om de mitigerende maatregelen in de Backlog te importeren.

• Voor elke mitigatie moet de status worden geïdentificeerd. Sommige mitigaties zijn nieuw, terwijl andere al bestaan. Het bedreigingsmodel moet herkennen wat er al is en zich richten op het huidige risico om te bepalen hoe de situatie moet worden verbeterd.

• Het moet duidelijk aangeven waarom elke beperking is vereist door deze te koppelen aan de respectieve bedreigingen.

• Bovendien hebben risicobeperkende oplossingen een relatieve sterkte voor elke bedreiging. TLS-versleuteling kan bijvoorbeeld een sterke beperking zijn voor het risico dat gegevens tijdens overdracht openbaar worden gemaakt, en tegelijkertijd kan het een bijna volledige beperking zijn voor het risico dat de server is vervalst.

• De bedreigingen moeten geloofwaardig, goed gedefinieerd en specifiek zijn voor de oplossing.

• De bedreigingen moeten een bijbehorende ernst hebben, die rekening moet houden met zowel de waarschijnlijkheid als de impact. De ernst moet redelijk en bij voorkeur objectief zijn.

• Het moet mogelijk zijn om een uitgebreid overzicht te krijgen van de risico's en hoe deze kunnen worden aangepakt. Deze weergave zou nuttig zijn bij het stimuleren van zinvolle gesprekken met het beveiligingsteam en met besluitvormers voor bedrijven, en het zou ons in staat stellen om de onnodige complexiteiten te verbergen.

Deze lijst bevat al een belangrijk concept: threat modeling kan waarde bieden aan veel rollen die betrokken zijn tijdens de levenscyclus van de software, maar elke rol heeft verschillende behoeften en vereisten. Ontwikkelaars moeten bijvoorbeeld duidelijke informatie ontvangen over wat ze moeten implementeren en hoe ze kunnen controleren of wat ze hebben geïmplementeerd zich gedragen zoals verwacht. Aan de andere kant houdt het beveiligingsteam zich doorgaans bezig met de algehele beveiliging van het ecosysteem van infrastructuur en toepassingen die eigendom zijn van de organisatie; daarom moeten ze informatie ontvangen waarmee kan worden bepaald of het systeem binnen het bereik veilig genoeg is en voldoet aan de nalevingsvereisten. Ten slotte moeten producteigenaren en besluitvormers begrijpen wat nodig is om het risico aanvaardbaar te maken voor de organisatie.

Dergelijke verschillende behoeften moeten verschillende weergaven bieden voor het bedreigingsmodel, die elk zijn gericht op een specifiek gebruiksscenario.

Een typisch probleem met bedreigingsmodellering is dat hoe meer het succesvol is, hoe moeilijker het is voor de weinige beschikbare experts om de vraag te dekken en tegelijkertijd de hoge kwaliteit te bieden die op basis van deze ervaring wordt verwacht. Als gevolg hiervan kan de kwaliteit in sommige gevallen negatief worden beïnvloed. Alles is goed totdat threat modeling stopt met het leveren van een aanzienlijke waarde in vergelijking met de investering. Meer dan een paar organisaties worden beïnvloed door dit probleem. Er zijn al een aantal rapporten waarin zakelijke besluitvormers beginnen te twijfelen aan bedreigingsmodellering, omdat het naar verwachting geen significante waarde zou bieden voor de kosten.

Met waarde verwijzen we naar de bedrijfswaarde. Dit is de mogelijkheid om de informatie te verstrekken die nodig is om inzicht te krijgen in de risico's die het systeem binnen het bereik vertegenwoordigt en een zinvol beslissingsproces aan te sturen voor het selecteren van de juiste oplossingen die moeten worden geïmplementeerd. Bovendien is de waarde ook gerelateerd aan het verstrekken van de juiste informatie aan de ontwikkelaars en de testers. Ten slotte is de waarde gerelateerd aan de communicatie van het restrisico met alle betrokken partijen. We kunnen bijvoorbeeld de waarde meten door de impact van het threat modeling-proces te meten. Stel dat we het totale risico voor de oplossing meten door een getal toe te wijzen aan de ernst die aan elke bedreiging is geïdentificeerd. In dat geval verwachten we dat het totale risico in de loop van de tijd afneemt per effect van het bedreigingsmodel. Als het totale risico constant blijft of toeneemt, kunnen we een probleem hebben. Hoe steiler de afname, hoe hoger de impact van het bedreigingsmodel. Natuurlijk zou het bedreigingsmodel geen controle hebben over de geïmplementeerde oplossingen. Het is de verantwoordelijkheid van de producteigenaar om te bepalen wat er moet worden geïmplementeerd. Maar het voordeel van het koppelen van de effectiviteit van het bedreigingsmodel aan de daadwerkelijke implementatie van de mitigaties is dat het de impact op de daadwerkelijke beveiliging van de oplossing verhoogt en het risico vermindert dat het bedreigingsmodel een theoretische oefening blijft.

In plaats daarvan zijn de kosten gerelateerd aan de activiteiten die nodig zijn om het bedreigingsmodel zelf uit te voeren. Dit is de tijd die alle betrokken partijen nodig hebben om het bedreigingsmodel te produceren en te bespreken.

Dit stelt de vraag: kunnen we een threat modeling-proces definiëren dat is gericht op het maximaliseren van de bedrijfswaarde en het minimaliseren van de kosten?

Het belang van DevOps

We hebben al uitgelicht hoe belangrijk het is om ervoor te zorgen dat threat modeling een waardevolle praktijk is die is geïntegreerd met het DevOps-proces. Dit betekent dat het proces beschikbaar moet zijn voor alle teamleden, meestal door het te vereenvoudigen en te automatiseren. Het belangrijkste is dat we ons richten op threat modeling voor DevOps, dat we ervoor moeten zorgen dat de ervaring diep is geïntegreerd met de bestaande DevOps-processen.

Bedreigingsmodellering mag niet nog een andere last worden, maar in plaatsdaarvan moet het een asset zijn om de beveiligingsvereisten te vereenvoudigen, het ontwerp van veilige oplossingen, het opnemen van activiteiten in het hulpprogramma taak - en fouttracking naar keuze, en de evaluatie van het resterende risico gezien de huidige en toekomstige status van de oplossing.

Uitlijning met DevOps

We kunnen verschillende technieken gebruiken om bedreigingsmodellering af te stemmen op de huidige DevOps-praktijk.

Bedreigingen en oplossingen

Eerst moeten we ons richten op de bedreigingsmodellering en bepalen wat er precies moet gebeuren. Bedreigingen, die de aanvalspatronen zijn en hoe ze kunnen optreden, zijn nodig om uit te leggen waarom het team een beveiligingscontrole moet implementeren. Ze zijn ook een factor bij het bepalen wanneer oplossingen moeten worden geïmplementeerd. Toch is het echte doel om te bepalen wat er moet worden gedaan: de oplossingen. Daarom moet de aanpak leiden tot een snelle identificatie van de vereiste oplossingen en moet het besluitvormingsproces worden geïnformeerd, zodat het gemakkelijker is om te bepalen wat er moet worden uitgevoerd en wanneer. Het belangrijkste resultaat van dit beslissingsproces is het hebben van de geselecteerde oplossingen in de backlog om ze onderdeel te maken van het standaardproces. In het ideale geval moeten het hulpprogramma voor bedreigingsmodellering en het hulpprogramma voor taak- en foutopsporing worden gesynchroniseerd om de updates van de mitigatiestatus in het bedreigingsmodel weer te geven. Hierdoor zou het restrisico dynamisch en automatisch kunnen worden herzien, wat essentieel is voor de ondersteuning van geïnformeerde beslissingen als onderdeel van de gebruikelijke choreografieën van de aangenomen Agile-methodologie, zoals de sprintplanningsvergadering.

Wat kun je vandaag doen?

Als expert op het gebied van bedreigingsmodellering moet u ervoor zorgen dat u een proces voor bedreigingsmodellering implementeert dat acties duidelijk kan identificeren en opnemen in uw taak- en fouttracking naar keuze. Een manier is om een van de vele hulpprogramma's voor threat modeling te gebruiken om dit proces te automatiseren.

Als ontwikkelaar moet u zich richten op de beveiligingscontroles die als nodig zijn geïdentificeerd. Het proces moet zo zijn ontworpen dat u ze op dezelfde manier ontvangt als u verwacht andere activiteiten te ontvangen.

Functies, gebruikersverhalen en taken

We hebben al aangegeven dat de mitigaties het belangrijkste artefact vertegenwoordigen dat is geproduceerd door het bedreigingsmodel in verband met de integratie van DevOps. Daarom is het belangrijk om duidelijk het type objecten te definiëren dat is gemaakt op basis van deze mitigaties voor het hulpmiddel voor taak- en fouttracking van keuze. Sommige oplossingen kunnen meer duren dan een Sprint. Daarom is het misschien het beste om ze als functies te maken. Maar veel zijn eenvoudiger en kunnen in één Sprint worden geïmplementeerd; Het zou dus mogelijk zijn om ze te vertegenwoordigen als gebruikersverhalen of -taken. Hoewel het genereren van verschillende typen werkitems mogelijk is, kan dit leiden tot een gecompliceerd proces dat tot fouten en verwarring kan leiden. Daarom lijkt het praktischer om één type werkitem te gebruiken. Aangezien mitigaties kunnen worden beschouwd als kinderen van gebruikersverhalen, kunt u overwegen deze te vertegenwoordigen als taken, wat inhoudt dat de vereiste voor het uitvoeren van het betreffende werkitemtype in één Sprint wordt versoepeld.

Wat kun je vandaag doen?

Zorg ervoor dat maatregelen die door het bedreigingsmodel zijn geïdentificeerd, moeten worden opgenomen in de werkvoorraad. Identificeer een manier om ze duidelijk weer te geven.

Gebruikersverhalen

De mitigaties zijn niet de enige artefacten die deel uitmaken van een bedreigingsmodel, welke afgestemd kunnen en moeten worden op wat u hebt in uw Taak- en Fouttrackinghulpprogramma. U kunt bijvoorbeeld ook bedreigingen voorstellen. Dit doel kan worden bereikt door de gebruikersverhalen uit te breiden door de toevoeging van een ZONDER-component aan de gebruikelijke 'Als een [wie ben ik] ik wil [wat ik wil] zodat ik [iets kan doen]'. Bijvoorbeeld: "Als gebruiker wil ik betalen met mijn creditcard, zodat ik bepaalde goederen kan kopen, ZONDER dat mijn creditcardgegevens worden gestolen". De WITHOUT-component kan worden toegewezen aan een of meer bedreigingen en kan soms beveiligingsvereisten uitdrukken. Door ervoor te zorgen dat deze afstemming tussen bedreigingen en ZONDER-componenten expliciet wordt gemaakt binnen het bedreigingsmodel, kunnen we ervoor zorgen dat mogelijke risico's door het team worden weerspiegeld en verzorgd, omdat ze worden opgenomen als onderdeel van de gebruikersverhalen. U kunt deze relatie ook gebruiken om elke beveiligingsvereiste die is geïdentificeerd als onderdeel van de gebruikersverhalen toe te wijzen aan ten minste een bedreiging.

Leuk om te weten

De WITHOUT-component is geen origineel idee van het team dat deze pagina heeft geproduceerd. We weten niet zeker wie het voor het eerst heeft geïntroduceerd, maar we zijn dankbaar voor wie dit idee heeft gekregen.

Een diagram dat bedreigingen in kaart brengt met gebruikersverhalen en ZONDER clausules.

Afbeelding 1: Vereisten uitlijnen

In de vorige afbeelding ziet u bijvoorbeeld de volgende situaties:

• Threat A is gekoppeld aan User Story 1 via clausule WITHOUT 1.

• Threat B is gekoppeld aan User Story 2 via clausule WITHOUT 2.

• Bedreiging B is ook gekoppeld aan User Story 3. Maar User Story 3 is niet toegewezen aan een WITHOUT-component. Waarom? Het vertegenwoordigt een mogelijke anomalie die u moet onderzoeken.

• Bedreiging B is ook gekoppeld aan User Story 1. Het is nog niet duidelijk of we gebruikersverhalen moeten toestaan die zijn gekoppeld aan meer dan één bedreiging.

• Threat C is gekoppeld aan User Story 4, dat is gekoppeld aan WITHOUT 3 en 4. Het is nog niet duidelijk of we meer dan één WITHOUT clausule mogen hebben.

• Threat D is niet gekoppeld aan een gebruikersverhaal. Missen we een gebruikersverhaal of een WITHOUT-clause?

• User Story 5 is gekoppeld aan een WITHOUT-component, maar heeft geen bijbehorende bedreiging. Missen we een bedreiging of gewoon een koppeling tussen een gebruikersverhaal en een bedreiging?

We identificeren zelden beveiligingsvereisten als onderdeel van het bedreigingsmodel. Daarom introduceert de WITHOUT-component de mogelijkheid om de ervaring verder te integreren door de bedreigingsmodellen uit te breiden met beveiligingsvereisten en deze te koppelen aan de gerelateerde gebruikersverhalen. Deze benadering speelt een belangrijke rol bij het ontwikkelen van de bedreigingsmodelleringservaring van een evaluatie die na verloop van tijd wordt herhaald om het hulpprogramma voor beveiligingsontwerp voor DevOps te worden.

Wat kun je vandaag doen?

Begin met het gebruik van de WITHOUT-component in uw gebruikersverhalen.

Wijs de bedreigingen die u identificeert toe aan gebruikersverhalen met WITHOUT-componenten en vice versa.

Een geïntegreerde ervaring

U kunt hetzelfde idee toepassen op andere scenario's. Het bedreigingsmodel kan bijvoorbeeld de beveiligingsvereisten koppelen aan artefacten in het bedreigingsmodel zelf, zoals bedreigingen en oplossingen, en die in het hulpprogramma Traceren en bijhouden van fouten. De eis om monitoring te implementeren voor het identificeren van lopende aanvallen moet bijvoorbeeld worden toegewezen aan alle mitigaties die betrekking hebben op monitoring en vervolgens aan de bijbehorende artefacten in de Taak- en bugtrackingtool. Als gevolg hiervan zou het gemakkelijk zijn om situaties te identificeren waarbij een beveiligingsvereiste niet wordt gerealiseerd: in feite zou deze niet aan iets worden gekoppeld.

U kunt dezelfde koppelingen gebruiken tussen de artefacten in het hulpprogramma Taak- en fouttracking en de bedreigingen en oplossingen die zijn geïdentificeerd door het bedreigingsmodel om de prioriteit van de beveiligingsactiviteiten te vergemakkelijken. Beveiliging wordt meestal als laatste geïmplementeerd, soms om reactieve beveiligingsproblemen aan te pakken die worden geïdentificeerd door een hulpprogramma of een penetratietest. Integendeel, het is het meest effectief om de mitigaties samen met de gerelateerde gebruikersverhalen of -functies te implementeren. Waarom moet u wachten met het implementeren van de besturingselementen om de creditcardgegevens te beveiligen wanneer u deze samen met de gerelateerde betalingsfuncties moet implementeren? Het bedreigingsmodel moet deze relaties markeren en een eenvoudige manier bieden om te bepalen wanneer een bepaalde functie tijdens een Sprint wordt geïmplementeerd, vereist de implementatie van een gerelateerde beveiligingsfunctie. Deze informatie kan bijvoorbeeld worden gebruikt tijdens de sprintplanningsvergadering om een zinvolle discussie te voeren en een geïnformeerde prioriteitsaanduiding te stimuleren. Het mechanisme is eenvoudig. Stel dat de producteigenaar voor een project waaraan we werken besluit om een gebruikersverhaal voor de volgende Sprint te plannen. Het genoemde gebruikersverhaal heeft een WITHOUT-component die is gekoppeld aan een bedreiging. Het bedreigingsmodel identificeert verschillende oplossingen voor dezelfde bedreiging. Daarom kunnen we onmiddellijk afleiden dat we prioriteit moeten geven aan een of meer van de geïdentificeerde oplossingen.

Een diagram waarin wordt getoond hoe de koppeling tussen bedreigingen en risicobeperking kan worden gebruikt voor het prioriteren van beveiliging.

Afbeelding 2: Prioriteit geven aan beveiliging

In de bovenstaande afbeelding zien we bijvoorbeeld dat User Story 1 is gekoppeld aan bedreiging 1, die op zijn beurt is gekoppeld aan risicobeperking A en B. Daarom moeten we ook overwegen om een of beide van deze oplossingen te implementeren.

Wat kun je vandaag doen?

Koppel gebruikersverhalen met WITHOUT-componenten aan de werkitems die overeenkomen met de geselecteerde oplossingen met behulp van het bedreigingsmodel als referentie. Zorg er bij het plannen van de volgende Sprint voor dat u prioriteit geeft aan de gekoppelde beveiligingsactiviteiten wanneer u een van deze gebruikersverhalen implementeert met WITHOUT-componenten.

Integratie om onjuiste uitlijningen te markeren

Zodra we beginnen na te denken over hoe we de artefacten die het bedreigingsmodel opstellen, kunnen koppelen aan de artefacten in het hulpprogramma Task & Bug Tracking, wordt het gemakkelijker om kansen te identificeren voor het verbeteren van de kwaliteit van beide. De sleutel is om hun relaties te gebruiken om verschillen te markeren en de informatie te gebruiken die aanwezig is in één om de aanwezige informatie aan te vullen, te integreren en te interpreteren wat er in de andere aanwezig is. Zoals hierboven is besproken, kunt u dit doen zonder dat dit aanzienlijk van invloed is op de werking van het team. Dat komt doordat de benadering afhankelijk is van bestaande informatie en relaties creëert tussen de verschillende objecten in de verschillende werelden. Daarom zou het bedreigingsmodel de bron van waarheid worden voor de beveiliging van de oplossing. Tegelijkertijd wordt de Backlog continu afgestemd op de status van de oplossing.

Wat kun je vandaag doen?

Controleer regelmatig of er geen niet-toegewezen bedreigingen of gebruikersverhalen zijn met uitsluitingsclausules.

Bedreigingsmodellering en de bewerkingen

Al deze ideeën zijn voornamelijk gericht op de ontwikkelingszijde van DevOps. Kunnen we ook iets doen om bewerkingen te verbeteren? Dat denken we wel. Het zou bijvoorbeeld mogelijk zijn om threat modeling te gebruiken als een hulpprogramma om hoofdoorzaakanalyse mogelijk te maken, omdat het een uitgebreid overzicht van het systeem biedt vanuit een beveiligingsperspectief en zo een beter inzicht kan krijgen in de gevolgen van sommige aanvallen. Hiervoor zou het nodig zijn om het bedreigingsmodel te integreren met de bestaande feeds van de gekozen bewakingshulpprogramma's. Deze benadering kan een aanvulling vormen op de gekozen SIEM.

Een ander idee voor het integreren van bedreigingsmodellering met Operations is het gebruik van de eerste om het ontwerp te bepalen van hoe dit laatste kan gebeuren. Een voorbeeld hiervan is het ontwerp van gebeurtenissen voor de oplossing. Bedreigingsmodellering identificeert mogelijke aanvallen en we kunnen die kennis gebruiken om gebeurtenissen te identificeren die de oplossing binnen het bereik kan veroorzaken wanneer deze aanvallen mislukken. Als u strikte invoervalidatie uitvoert, heeft een kwaadwillende aanvaller een paar pogingen nodig voordat deze slaagt. In eerste instantie mislukken de pogingen en slaagt een van deze pogingen uiteindelijk. Door gebeurtenissen voor elke fout op te halen en waarschuwingen te activeren wanneer een bepaalde drempelwaarde is bereikt, kunt u mogelijk aanvallen detecteren en acties ondernemen om deze te herstellen. Deze situaties worden zelden gedetecteerd als u zich beperkt tot het bewaken van de infrastructuur. Daarom is het noodzakelijk om aangepaste gebeurtenissen op te nemen die het team moet ontwerpen en implementeren voordat de SOC deze kan gebruiken.

Bovendien weet de laatste mogelijk niet veel over de oplossing. Daarom kan de SOC mogelijk niet bepalen hoe moet worden gereageerd wanneer de invoervalidatie mislukt. Wanneer een gegevenslek optreedt, is het helaas noodzakelijk om snel te reageren om de directe schade en de waarschijnlijkheid en entiteit van uiteindelijke boetes te verminderen.

Daarom moeten we van tevoren plannen wat er moet worden bewaakt, onder welke omstandigheden we mogelijk een probleem hebben en wat er moet gebeuren als dat gebeurt. De beste manier om deze gebeurtenissen te identificeren, is om te vertrouwen op een bedreigingsmodel. Daarom zou het nuttig zijn om het te gebruiken om gestandaardiseerde artefacten te genereren om de implementatie van de benodigde configuraties te begeleiden en te versnellen om bewaking en controle te stimuleren en incidentrespons te vergemakkelijken.

Wat kun je vandaag doen?

Gebruik actief bedreigingsmodel om gebeurtenissen te identificeren die u voor elke bedreiging kunt genereren. Deze gebeurtenissen kunnen worden geleverd door de infrastructuur of iets dat door de toepassing moet worden gegenereerd. Neem werkitems op in uw backlog om ervoor te zorgen dat deze gebeurtenissen uitgevoerd worden.

Werk actief samen met uw operations- en beveiligingsteams, waaronder het SOC-team, om ervoor te zorgen dat de gebeurtenissen worden gebruikt om waarschuwingen te genereren en beveiligingsincidenten te identificeren.

De impact op de ROI

U vraagt zich misschien af waarom deze technieken de ROI van bedreigingsmodellering positief kunnen beïnvloeden. Vanuit ons oogpunt zijn ze cruciaal voor het verhogen van de waarde van bedreigingsmodellering voor de DevOps-teams. Het probleem dat we herhaaldelijk hebben gezien, is dat deze teams de beveiliging ervaren als kosten die een beperkte waarde bieden en veel onvoorzien werk vereisen. Soms is het onduidelijk waarom ze zoveel van hun tijd moeten investeren in het herstellen van de beveiliging. Als gevolg hiervan wordt beveiliging een probleem in plaats van een kans. Threat modeling biedt de mogelijkheid om deze problemen op te lossen, omdat het de redenen biedt om beveiliging te implementeren. Bovendien kan het vroeg in het ontwikkelingsproces worden gestart en ontwerpfouten voorkomen die kostbaar kunnen zijn als ze niet snel worden gedetecteerd. De bovenstaande technieken zijn bedoeld om bedreigingsmodellering beter te integreren met DevOps. Dit zorgt ervoor dat zakelijke besluitvormers en ontwikkelaars bedreigingsmodellering als een natuurlijke aanvulling op het ontwikkelings- en operationele proces ervaren. Daarom neemt de waarde die wordt ontvangen door het aannemen van bedreigingsmodellering toe en nemen de kosten af vanwege de integratie met de verschillende hulpprogramma's die al in gebruik zijn.

Het werk voor threat modelers vereenvoudigen

Een ander belangrijk aspect dat nodig is om het RENDEMENT van bedreigingsmodellering te verbeteren, is gerelateerd aan het verlagen van de kosten en het verhogen van het aantal mensen dat het kan leveren, terwijl er meer homogene kwaliteitsniveaus worden gehandhaafd.

Er zijn veel pogingen om het tekort aan bevoegde mensen aan te pakken. Sommige hiervan zijn gebaseerd op de actieve betrokkenheid van het hele DevOps-team in de oefening voor threat modeling. Het idee is om een leider van het initiatief te identificeren, dat wil zeggen iemand met tussenliggende kennis over het proces, maar niet noodzakelijkerwijs een expert is, en haar de discussie tussen de andere teamleden laten leiden. Deze aanpak wordt actief goedgekeurd door de ondertekenaars van het Threat Modeling Manifesto.

We zijn het er wel mee eens dat deze aanpak een goede waarde biedt en een verbetering vormt ten opzichte van de huidige situatie. Het biedt ook goede inzichten en stelt het team in staat om de beveiligingscultuur te laten groeien. Toch is het niet zonder nadeel, omdat het slechts een paar problemen behandelt, waardoor er veel wegvalt. Dit creëert een consistentieprobleem omdat het te gemakkelijk is om in het konijnenhol te springen en kostbare tijd te verspillen aan secundaire problemen, terwijl belangrijke over het hoofd worden gezien. De ervaring van de leider speelt een belangrijke rol bij het voorkomen van deze situaties. Bovendien vereist deze aanpak veel tijd van alle teamleden om elk probleem te bespreken.

Daarom kan zelfs het uitgeven van een paar uur per Sprint voor deze oefening een aanzienlijke investering vertegenwoordigen. Iedereen weet dat de meeste teams vaak tijd verspillen aan grote vergaderingen waarbij iedereen betrokken is, en die bedreigingsmodelleringssessies zouden geen uitzondering maken. Toch is deze aanpak uitstekend voor kleine producten, waarbij het team een handvol senioren omvat.

Een andere benadering

Gezien de beperkingen van de vorige benadering, geven we er de voorkeur aan om het aantal vergaderingen, hun lengte en het aantal deelnemers te beperken. Daarom zou de verantwoordelijkheid van de bedreigingsmodeller belangrijker zijn: niet alleen om de interviews te leiden, maar ook om het bedreigingsmodel zelf te creëren en te onderhouden. Deze aanpak vereist meer significante competenties en expertise. Bedreigingsmodellers kunnen vertegenwoordigd worden door Security Champions of door leden van het interne beveiligingsteam. De meeste organisaties zouden voor de eerste optie kiezen omdat de beveiligingsafdeling doorgaans volgeboekt is.

Beveiligingsleiders zijn lid van de DevOps-teams met een bepaald belang in beveiliging. Het zijn geen experts, maar ze hebben een basiskennis en de bereidheid om de beveiligingspostuur van hun team te verbeteren. Het idee is om een bevoorrechte verbinding te maken tussen de beveiligingsleiders en het interne beveiligingsteam, zodat de eersten in staat zijn om hun teams te helpen bij het doen van het juiste, terwijl het beveiligingsteam de werkbelasting kan verminderen. Met threat modeling zouden de beveiligingsleiders fungeren als bedreigingsmodellers en zou het interne beveiligingsteam de verantwoordelijkheid hebben om hen te begeleiden en hun werk te beoordelen.

Wat kun je vandaag doen?

Onderzoek de mogelijkheid om een Beveiligingskampioen-programma te gebruiken en gebruik te maken van het programma om uw levenscyclus voor secure softwareontwikkeling verder te versterken.

De rol van knowledge bases

Een belangrijk probleem met threat modeling is ervoor te zorgen dat de kwaliteit van de ervaring en de waarde voor het DevOps-team hoog is, ongeacht wie het bedreigingsmodel uitvoert. Met Beveiligingskampioenen wordt dit probleem nog urgenter. Een idee om dit aan te pakken is om knowledge bases te bieden om het bedreigingsmodel te maken. Knowledge Bases voor threat modeling zijn pakketten met informatie over een specifieke context: ze bevatten een definitie van de entiteiten die zijn gerelateerd aan die context, de mogelijke aanvalspatronen voor die entiteiten en de standaardbeperking die kan worden toegepast. Met Knowledge Bases kan de organisatie betere en consistentere resultaten krijgen, omdat ze referentiemateriaal vertegenwoordigen dat de threat modelers op een prescriptieve manier begeleidt. Knowledge bases moeten regels hebben waarmee we automatisch bedreigingen en oplossingen voor een systeem kunnen toepassen. Met deze automatisering kunnen we het feit overwinnen dat sommige bedreigingsmodelleerders mogelijk niet over de ervaring beschikken die nodig is om te bepalen of een bedreiging moet worden toegepast of als een oplossing effectief is.

Knowledge bases zijn geen nieuw idee: veel huidige hulpprogramma's voor threat modeling ondersteunen ze al in een bepaalde vorm. Maar veel huidige implementaties hebben aanzienlijke nadelen. U moet bijvoorbeeld eenvoudig knowledge bases kunnen onderhouden. Hun onderhoud is een probleem dat nog steeds onopgeloste is. Het is bijvoorbeeld niet eenvoudig om de beste informatiebronnen te identificeren die u kunt gebruiken om ze te bouwen. Bovendien is onderhoud doorgaans handmatig. Het maken en onderhouden van de knowledge bases moet de verantwoordelijkheid van het interne beveiligingsteam van de organisatie zijn. We hopen dat bedrijven in de toekomst kennisdatabases gaan bieden voor de meest voorkomende hulpprogramma's voor threat modeling om een aantal van de lasten van hun klanten op te heffen. Deze knowledge bases moeten flexibel zijn om hun acceptatie te ondersteunen en te vergemakkelijken, zelfs door de meest volwassen organisaties, die de genoemde knowledge bases moeten aanpassen aan hun praktijken, beleid en voorschriften.

Wat kun je vandaag doen?

Overweeg de mogelijkheid om deel uit te maken van de inspanningen van het gecentraliseerde beveiligingsteam voor het ontwikkelen van knowledge bases die door de verschillende ontwikkelteams kunnen worden gebruikt om threat modeling te versnellen.

Kennisbanken gebruiken

Een ander probleem met knowledge bases is dat ze soms te complex zijn om te gebruiken. Veel van hen proberen uitgebreid te zijn door essentiële en minder kritieke problemen op te slaan. Helaas zijn niet alle onderdelen vereist door alle systemen. U wilt een eenvoudigere benadering gebruiken wanneer het systeem dat u analyseert klein is en geen gevoelige gegevens verwerkt. Integendeel, u zou gedetailleerder willen gaan als het systeem complexer is en PII- en hoogwaardige gegevens verwerkt. Daarom moet het mogelijk zijn om verschillende versies van de kennis toe te passen, afhankelijk van de context of om bepaalde aanvalspatronen en bijbehorende risicobeperking als 'TOP' te markeren. Als gevolg hiervan kunnen de bedreigingsmodelleerders beslissen of ze een uitgebreide ervaring willen of eenvoudig willen gaan en het vereiste werk minimaliseren.

Over efficiëntie gesproken, is het noodzakelijk om ervoor te zorgen dat de activiteiten zo veel mogelijk worden gestroomlijnd en geautomatiseerd om de benodigde hoeveelheid werk te verminderen. We denken dat een ideaal punt voor het uitvoeren van een dreigingsmodel van een oplossing van gemiddelde grootte 1 dag werk voor de dreigingsmodelleur zou moeten zijn. Dergelijke resultaten zijn alleen mogelijk als het hulpmiddel van de keuze accelerators biedt om de benodigde tijd te besparen. Als het hulpprogramma bijvoorbeeld 20 verschillende soorten oplossingen op 100 verschillende plaatsen toepast en u wordt gevraagd om voor elk van deze locaties hun status op te geven, zou u vijf keer efficiënter zijn door u te richten op de eerste in plaats van de laatste. Het hulpprogramma van de keuze moet deze mogelijkheid bieden en tegelijkertijd de mogelijkheid verlenen om indien nodig een grondiger taak uit te voeren.

Wat kun je vandaag doen?

Als de knowledge bases die u vandaag gebruikt, het concept van 'TOP'-bedreigingen en -oplossingen niet ondersteunen, kunt u overwegen om te verwijderen wat zelden of nuttig is, zodat u zich alleen kunt concentreren op wat echt belangrijk is.

Soms is het probleem dat de aangenomen knowledge bases algemeen proberen te zijn en meerdere scenario's behandelen. U kunt de situatie verbeteren door ze te specialiseren.

De juiste vragen stellen

Tijdens onze analyse hebben we gekeken naar de mogelijkheid om een hulpprogramma te gebruiken ter ondersteuning van een vragenframework om de eerste fasen van de analyse te stimuleren. We hebben gemerkt dat de meeste onervaren threat modelers niet de juiste vragen kunnen stellen om de informatie op te halen die nodig is voor hun analyse. Sommige van onze experts hebben aangetoond dat het mogelijk is om enkele cruciale vragen te bepalen op basis van een systeemdiagram binnen de scope. Deze vragen kunnen zelfs automatisch worden toegepast, met enkele generatieregels. Het probleem is dat deze benadering mogelijk niet de waarde biedt die het lijkt te beloven. Dat komt doordat u de logica achter elke vraag moet begrijpen. Anders zou u het antwoord niet kunnen evalueren en bepalen of het bevredigend is. Het genereren van geautomatiseerde vragen kan echter een aanzienlijke waarde opleveren voor de minder deskundige bedreigingsmodelleerders, waardoor het inzicht in de systemen binnen het bereik wordt verbeterd.

Wat kun je vandaag doen?

Gebruik een gestructureerde benadering om vragen te stellen. Ons team heeft bijvoorbeeld goede resultaten behaald door Microsoft STRIDE als referentie te gebruiken. U kunt dit doen door elk onderdeel van de oplossingsvragen te vragen, zoals:

• Spoofing: hoe authenticeert de component zich ten opzichte van de diensten en bronnen die het gebruikt?

• Manipulatie: valideert het onderdeel de berichten die het ontvangt? Is de validatie los of strikt?

• Repudiation: wordt het onderdeel waarin de interacties worden vastgelegd in een auditlog?

• Openbaarmaking van informatie: is het verkeer dat binnenkomt en uitgaat bij de component versleuteld? Welke protocollen en algoritmen zijn toegestaan?

• Denial of Service: is het onderdeel geconfigureerd voor hogere beschikbaarheid? Is het beveiligd tegen DDoS-aanvallen?

• Uitbreiding van bevoegdheden: zijn gebruikers de minste bevoegdheden toegewezen die vereist zijn? Wordt er in de oplossing code voor normale gebruikers gemengd met die voor gebruikers met hoge bevoegdheden?

Technieken zoals deze kunnen worden geleerd en kunnen worden verbeterd met ervaring. Daarom is het belangrijk om een continue leerbenadering te implementeren die is ontworpen om leermateriaal te verzamelen en te verspreiden binnen de organisatie.

De impact op de ROI

Het is mogelijk om veel ideeën te identificeren om de efficiëntie van de bedreigingsmodelleringservaring, de kwaliteit ervan te verbeteren en uiteindelijk de ROI te verhogen. Deze inspanning moet echter worden beschouwd als een doorlopend proces, dat moet worden gericht op de continue verbetering van de praktijk.

Conclusies

Threat modeling is een uitstekende methodologie voor het verbeteren van de beveiliging van uw organisatie. Indien correct gedaan, kan het waarde bieden voor een zeer redelijke kosten. We hebben al verschillende technieken geïdentificeerd die essentieel kunnen zijn voor het verbeteren van de waarde van bedreigingsmodellering voor het beveiligen van moderne oplossingen, waaronder:

• Het bedreigingsmodel afstemmen met uw DevOps-praktijk door

  • Gericht op de mitigerende maatregelen

  • Mitigaties koppelen aan gebruikersverhalen

  • Verschillen tussen het bedreigingsmodel en de achterstand markeren

  • Het bedreigingsmodel gebruiken om een uitgebreidere bewaking en controle voor beveiliging te stimuleren

• Vereenvoudig het maken van bedreigingsmodellen en verhoog de consistentie van de resultaten

  • Vertrouwen op beveiligingskampioenen

  • Knowledge bases gebruiken om de identificatie van bedreigingen en risicobeperking te automatiseren

  • Betere knowledge bases maken

  • Een vraagframework bieden dat wordt ondersteund door automatisering

Hopelijk zijn sommige hiervan al te vinden in uw hulpprogramma voor bedreigingsmodellering van uw keuze. Anderen zullen in de toekomst worden opgenomen. We weten dat het maximaliseren van de ROI voor threat modeling een langetermijninspanning is die antwoorden vereist die we nog niet hebben. We weten ook dat sommige vragen nog steeds onbekend zijn. Dit document zou stof tot nadenken moeten bieden en hopelijk kan het u helpen bij het verbeteren van uw aanpak van bedreigingsmodellering. We hopen dat het een vuurtoren voor u en ons kan zijn en dat het nuttig zal zijn om onze inspanningen voor de komende jaren te leiden.