Triggering threat modeling in agile development

Abstract

Trussemodellering burde gjennomføres så tidlig som mulig i smidig utvikling, men den må oppdateres etter hvert som arkitekturen og systemet endres. I smidig utvikling er det utfordrende å vite når denne oppdateringen bør gjennomføres. Den gjeldende akademiske litteraturen mangler en systematisk måte å utløse slike oppdateringer basert på endringer gjort i koden. Denne masteroppgaven har som mål å forbedre programvaresikkerheten i smidig utvikling ved å foreslå et metode-artefakt som kan indikere når trussemodellering bør finne sted. Mer spesifikt prøver denne oppgaven å besvare følgende forskningsspørsmål: Forskningsspørsmål 1: Hvordan kan trussemodellering bli utløst basert på kodeendringer? Forskningsspørsmål 2: Hva er effekten av metoden som løser forskningsspørsmål 1?

Metode-artefaktet som er foreslått i denne oppgaven kategoriserer kodeendringer og utløser trussemodelleringer basert på de faktiske endringene i systemet, på en systematisk måte. Artefaktet ble forbedret og evaluert med to papir prototype brukertester hos IT selskapet SpareBank 1 Utvikling. Senere ble en minimal implementasjon av artefaktet testet hos IT utviklingsselskapet Visma, som en del av deres arbeidsflyt i GitHub.

Denne oppgaven følger design forsknings metodologien, og strukturen i oppgaven er derfor en blanding av AIMRAD og stegene i design forskning. Den begynner med å utforske og forklare problemet, lage et utkast av artefaktet, etterfulgt av design og implementasjon av artefaktet, deretter en demonstrasjon i en fiktiv case. Til slutt ble artefaktet evaluert etter hvor bra det løser problemet, hvor godt den fyller kravene som er definert, mulige bi-effekter ble undersøkt, brukbarheten ble evaluert, og den ble sammenlignet med andre artefakter.

Resultatene indikerer at artefaktet er effektivt for å løse problemet og sikkerhetseksperter rangerer den høyt. Brukbarheten var innenfor de akseptable verdier, og de fleste brukbarhetsutfordringene kan forbedres med automatisering eller små forbedringer. Artefaktet påvirket utviklernes smidige arbeidsflyt lite, og den krevde lite ekstra tid og innsats.

In agile development, threat modeling should be performed as early as possible, but it will need to be updated as the architecture and system change. The challenge for an agile development team then becomes to determine when to update the threat modeling. The current body of research lacks a systematic way of determining when this update should be triggered based on the changes made to the system. This thesis aims to improve software security in agile development by proposing a method-artifact for triggering threat modeling. More specifically, it answers the research questions: RQ1: How can threat modeling be triggered based on code changes? RQ2: What is the effect of the suggested approach from RQ1?

The method-artifact proposed in this thesis categorizes code changes and creates triggers for threat modeling based on the actual changes to the system in a systematic manner. The artifact was evaluated with two paper prototype user tests at the IT company SpareBank 1 Utvikling to improve and evaluate the artifact. Later, a minimum-viable-product implementation was tested at the software development company Visma as part of their pipeline in GitHub.

This thesis follows the design science methodology, and the structure is, therefore, a combination of aIMRAD and the steps in design science. It begins by explicating the problem, outlining an artifact, designing and developing the artifact, followed by a demonstration of the artifact on a fictional case. Finally, the artifact is evaluated against how well it solves the problem and fulfills the requirements, its side effects are studied, the usability is evaluated, and it is compared to other similar artifacts.

The results indicate that the artifact effectively solved the problems and security experts rated it highly. The usability was within the acceptable range, and most usability challenges could be improved by increased automation or minor tweaks. The artifact impacted the developer’s agile workflow to a small extent and required little extra time and effort.