dc.contributor.advisor | Cruzes, Daniela Soares | |
dc.contributor.author | Håkonsen, Kristoffer Håkon | |
dc.date.accessioned | 2022-10-08T17:20:02Z | |
dc.date.available | 2022-10-08T17:20:02Z | |
dc.date.issued | 2022 | |
dc.identifier | no.ntnu:inspera:112046434:25720542 | |
dc.identifier.uri | https://hdl.handle.net/11250/3024839 | |
dc.description.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. | |
dc.description.abstract | 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. | |
dc.language | eng | |
dc.publisher | NTNU | |
dc.title | Triggering threat modeling in agile development | |
dc.type | Master thesis | |