• norsk
    • English
  • English 
    • norsk
    • English
  • Login
View Item 
  •   Home
  • Fakultet for informasjonsteknologi og elektroteknikk (IE)
  • Institutt for datateknologi og informatikk
  • View Item
  •   Home
  • Fakultet for informasjonsteknologi og elektroteknikk (IE)
  • Institutt for datateknologi og informatikk
  • View Item
JavaScript is disabled for your browser. Some features of this site may not work without it.

Triggering threat modeling in agile development

Håkonsen, Kristoffer Håkon
Master thesis
Thumbnail
View/Open
no.ntnu:inspera:112046434:25720542.pdf (10.10Mb)
URI
https://hdl.handle.net/11250/3024839
Date
2022
Metadata
Show full item record
Collections
  • Institutt for datateknologi og informatikk [6336]
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.
 
Publisher
NTNU

Contact Us | Send Feedback

Privacy policy
DSpace software copyright © 2002-2019  DuraSpace

Service from  Unit
 

 

Browse

ArchiveCommunities & CollectionsBy Issue DateAuthorsTitlesSubjectsDocument TypesJournalsThis CollectionBy Issue DateAuthorsTitlesSubjectsDocument TypesJournals

My Account

Login

Statistics

View Usage Statistics

Contact Us | Send Feedback

Privacy policy
DSpace software copyright © 2002-2019  DuraSpace

Service from  Unit