universitetet i oslo - in2000 software engineering og ......2020/02/18 · tradisjonell fossefall...

IN2000

Software Engineering og prosjektarbeid

Vår 2020

Sikker systemutvikling

Audun Jøsang

Universitetet i Oslo

Oversikt

• Bakgrunn for sikkerhet i IT-utdanningen

• Sikker smidig programvareutvikling

• Trusselmodellering i programvareutvikling

• Trusselpoker

IN2000 2020 Sikker systemutvikling 2

Obligatorisk informasjonssikkerhet i IT-utdanningen

• Stortinget har vedtatt at alle IT-studieprogrammer ved

universiteter og høyskoler må ha obligatoriske kurs I

informasjonssikkerhet• Source: https://www.tekna.no/aktuelt/tekna-gjennomslag-om-ikt-sikkerhet-i-utdanningen/


11. april 2018


15.08.2014

Audun Jøsang

Sikker systemutvikling

- en del av innebygd informasjonssikkerhet


Sikker

systemutvikling

Tradisjonell fossefall og overgang til

smidig utvikling og DevOps


Test/Verifisering

Drift

Design

Krav

Implementering

Waterfall SDLC (Software

Development Life Cycle)

Smidig programvareutvikling

• Systemkrav spesifiseres som brukerhistorier

• Hver brukerhistorie implementeres i en sprint

• Fortsetter så lenge det er igjen brukerhistorier

• Systemet er ferdig når alle brukerhistorier er laget


Evaluering av

nåværende system

Utgivelse av ny

programvareversjon

Kode, integrere og

teste ny funskjonalitet

Planlegg koding av ny

funksjonalitet

Splitt brukerhistorien

opp i enkeltfunksjonerVelg brukerhistorie for

neste programversjon

Produksjonssetting

av ferdig system

Planlegging av nytt

system Sprintsyklus

Sikker smidig programvareutvikling

• Sikker smidig programvareutvikling har tilleggsaktiviteter

– … ved oppstart av prosjektet

– … i hver sprintsyklus

– … ved avsluttende evaluering av system

• «Sikker smidig» blir nødvendigvis litt mindre smidig


Evaluering av

system & sikkerhet

Utgivelse av ny

programversjon

Kode, integrere &

teste ny funksjon.

Planlegg koding

av nye funksjoner

Splitt brukerhistorie

i enkeltfunksjoner

Velg brukerhistorie

for neste versjon

Innhent generelle

sikkerhetskrav

Identifiser trusler

som må forhindres

Planlegging

Produksjonssetting

Aktiviteter for sikkerhet

Funksjonell og ikke-funksjonell sikkerhet

• Funksjonell sikkerhet:

– Sikkerhetskrav som utgjør en

egen brukerhistorie

– Sikkerhetsfunksjon som er

nødvendig for brukerhistorien

– Sikkerhetsfunksjon som gir en

«synlig» tjeneste til brukere

– F.eks.: Brukerautentisering

• Ikke-funksjonell sikkerhet:

– Sikkerhetskrav som ikke er en

egen brukerhistorie


unødvendig for brukerhistorien

men nødvendig for å hindre trusler


«usynlig» for brukeren

– F.eks.: Inputvalidering mot

SQL-injection og XSS


Brukerhistorie og “Use Case”

Brukerhistorie – Sett fra brukerperspektiv:

Som [bruker] ønsker jeg [funksjon] for å nå [resultat].

Eksempel: Som Flickr-bruker, ønsker jeg å kunne

definere tilgangskontroll, slik at jeg kan velge hvem

som kan se de forskjellige bildene jeg har lagt ut.

Use Case – Sett fra designerens perspektiv:

Beskrivelse av et sett med interaksjoner mellom et

system og én eller flere aktører (der en "aktør" kan

være en bruker eller et annet system).

IN2000 2020 Sikker systemutvikling11

Bruker-

historie

Use CaseServer logic

Angriperhistorie og “Misuse Case”

(Angripers målsetting og Trusselscenario)

Angriperhistorie – Angripers målsetting:

Som [angriper] ønsker jeg [funksjon] for å nå [resultat].

Eksempel: Som angriper ønsker jeg å hacke Flickr-

kontoer for å stjele private bilder og personlig info.

Misuse Case (Trusselscenario)

Sett fra trusselaktøren sitt perspektiv:

Beskrivelse av et sett med

trinn og interaksjoner som

må utføres av angriperen

for å oppnå mål.

IN2000 2020 Sikker systemutvikling12

Server logic

Misuse

Case

Angriper

-historie

Trusselmodellering

• Systemeiere må prøve å blokkere alle relevante trusler ved å

fjerne sårbarheter som trusselen utnytter

• Angripere trenger bare å finne ett gjennomførbart scenario

• Nye trusler/sårbarheter oppdages kontinuerlig

• Utfordrende å forsvare seg mot rask trusselinnovasjon


Front-end

Web server

Back-end

app. logic

MySQL

databaseInternet

KlientplatformBruker

Trusselaktør med målsettinger for angrep

Trusselscenarier

STRIDE Trusselmodellering for programvareutvikl.

S

T

R

I

D

Tampering (kompromittering)

Repudiation (benekting)

Information disclosure (datatyveri og -lekkasje)

Denial of service (tjenestenekt)

Kan en angriper få tilgang til ved å misbruke en annens identitet?

Kan en angriper endre data som prosesseres av systemet?

Kan en angriper benekter misbruk, uten at vi kan bevise misbruket ?

Kan en angriper få tilgang til konfidensielle og personlige data?

Kan en angriper sabotere eller redusere tilgjengeligheten av systemet?

EElevation of privilege (utvidet tilgang)Kan en angriper oppnå tilgangsrettigheter som privilegert bruker?

Spoofing (identitetstyveri)


Trusselpoker – Threat Poker

• Gamifisering (gamification) av sikker smidig

• Bruk av vanlig kortstokk for å løse trusler under systemutvikling


Trusselpoker

• Hver deltager får en hel suite– Hjerter, Spar, Ruter eller Kløver

– 1 kortstokk → 4 deltagere, 2 kortstokker → 8 deltagere osv.

• Et spill om hver trussel.– Innledende diskusjon om hver trussel/sårbarhet og dens mulige løsning

– For hver trussel/sårbarhet spilles et spill med en eller flere runder

– I hver runde spilles 1 oddetallskort for risiko og 1 partallskort for løsning

– Kortene legges først med ansikt ned, og vendes opp samtidig

– Store sprik i tallverdi trigger diskusjon om risiko/løsning, og ny runde.

– Spillet avsluttes ved enighet om risiko, løsning og estimert tidsbruk.

• Risikovurdering: Oddetallskort (3, 5, 7, 9, J, K, A) → Risiko

– Estimere både sikkerhetsrisiko og personvernrisiko relatert til trusselen

• Løsningsvurdering: Partallskort (2, 4, 6, 8, 10, Q) → Tidsbruk

– Estimere tid det tar å fjerne relevante sårbarheter slik at

trusselscenariet elimineres, dvs. slik at sårbarheten er fjerne og en

angriper ikke lenger kan gjennomføre trusselen.


Risikonivå for trussel (oddetallskort + ess)


Tall Beskrivelse

3 Ubetydelig personvern- eller sikkerhetsrisiko, kan ignoreres

5 Svært lav personvern- eller sikkerhetsrisiko, bør løses hvis

det kan gjøres enkelt og raskt.

7 Lav personvern- eller sikkerhetsrisiko, bør løses hvis det

bare krever relativt lav innsats og relativt kort tid.

9 Moderat personvern- eller sikkerhetsrisiko, bør løses selv

om det krever betydelig innsats og tid.

J (11) Høy personvern- eller sikkerhetsrisiko, bør alltid løses selv

om det krever svært høy innsats i tid og ressurser.

K (13) Meget høy personvern- eller sikkerhetsrisiko med potensielt

svært alvorlige konsekvenser. Må løses uten unntak.

A (14) Ekstrem personvern- og/eller sikkerhetsrisiko. Med mindre

tilfredsstillende løsning kan implementeres børdet stilles

spørsmål om det er forsvarlig at denne brukerhistorien eller

funksjonen implementeres i det hele tatt.

Forventet tidsbruk for løsning, dvs. å stoppe trusselen

ved å fjerne sårbarhet(er) (partallskort)


Tall Beskrivelse

2 Ubetydelig innsats, er løst eller kan løses raskt og enkelt.

4 Svært liten innsats, svært lett å løse.

6 Lav innsats, relativt lett å løse.

8 Moderat innsats, vil kreve god del arbeid. (Vurder å utsette til

en annen sprint)

10 Høy innsats, vil ta det meste av tiden for det meste av

teamet under nåværende sprint. (Vurder å utsette til en

annen sprint)

Q (12) Meget høy innsats, vil kreve så mye arbeid at

nåværendesprint må forlenges, eller utsettes til annen sprint.

Eksperiment med trusselpoker


• Trusselpoker er utviklet på IFI som del av et Masterprosjekt

• Inspirert av Protection Poker, utviklet av University of North Carolina

• Utprøvd i klasse for smidig systemutvikling (IN2000) vår 2018

• Publikasjon:

Hanne Rygge and Audun Jøsang.

Threat Poker: Solving Security and Privacy Threats in Agile Software Development

NordSec 2018, Oslo, November 2018.

Slutt på forelesning


universitetet i oslo - in2000 software engineering og ......2020/02/18 · tradisjonell fossefall...

Documents