IN2000 Software Engineering og prosjektarbeid Vår Sikker systemutvikling. Audun Jøsang Universitetet i Oslo

Transkript

1 IN2000 Software Engineering og prosjektarbeid Vår 2019 Sikker systemutvikling Audun Jøsang Universitetet i Oslo

2 Oversikt Modeller for programvareutvikling Sikker smidig programvareutvikling Trusselmodellering i programvareutvikling Trusselpoker IN Sikker systemutvikling 2

3 Obligatorisk informasjonssikkerhet i IT-utdanningen Stortinget har vedtatt at alle IT-studieprogrammer ved universiteter og høyskoler skal gi kompetanse i informasjonssikkerhet Source: april 2018 IN Sikker systemutvikling 3

4 Sikker systemutvikling - en del av innebygd informasjonssikkerhet Sikker systemutvikling IN Sikker systemutvikling 4

5 Fossefall og sikker fossefall Krav Design Koding Waterfall SDLC (Software Development Life Cycle) Testing Microsoft SDL (Secure Development Lifecycle) Vedlikehold IN Sikker systemutvikling 5

6 Smidig programvareutvikling Planlegging av nytt system Sprintsyklus Velg brukerhistorie for neste programversjon Splitt brukerhistorien opp i enkeltfunksjoner Planlegg koding av ny funksjonalitet Evaluering av nåværende system Utgivelse av ny programvareversjon Kode, integrere og teste ny funskjonalitet Produksjonssetting av ferdig system 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 IN Sikker systemutvikling 6

7 Sikker smidig programvareutvikling Planlegging Aktiviteter for sikkerhet Innhent generelle sikkerhetskrav Velg brukerhistorie for neste versjon Evaluering av system & sikkerhet Splitt brukerhistorie i enkeltfunksjoner Utgivelse av ny programversjon Planlegg koding av nye funksjoner Kode, integrere & teste ny funksjon. Identifiser trusler som må forhindres Produksjonssetting 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 IN Sikker systemutvikling 7

8 Scrum-modell for smidig programvareutvikling Product Vision Communication Scrum Master User Stories Product Owner Development Team Product Backlog Sprint Backlog Daily Scrums Definition of Done Incremental Product Backlog Refinement Sprint Planning Sprint Cycles (1-4 weeks each) Sprint Retrospective Sprint Review IN Sikker systemutvikling 8

9 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. Brukerhistorie 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). Use Case Server logic IN Sikker systemutvikling 9

10 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 Flickrkontoer for å stjele private bilder og personlig info. Angriper -historie 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. Server logic Misuse Case IN Sikker systemutvikling 10

11 Ingen sårbarhet uten en trussel Ny trussel i 2016 Nice Berlin London Barcelona Trussel blokkert (sårbarhet fjernet) IN Sikker systemutvikling 11

12 Trusselmodellering Trusselaktør med målsettinger for angrep Trusselscenarier Internet Front-end Web server Back-end app. logic MySQL database Bruker Klientplatform Systemeiere må prøve å blokkere alle relevante trusler Angripere trenger bare å finne ett gjennomførbart scenario Nye trusler oppdages kontinuerlig, av angripere og forsvarere Utfordrende å holde tritt med rask trusselinnovasjon IN Sikker systemutvikling 12

13 Tilnærminger for trusselmodellering Angripersentrisk Starter fra angripere som definerer sine angrepsmål, og hvordan de kan oppnå dem gjennom trusselscenarier. Starter vanligvis med et overordnet angrepsmål. Systemsentrisk Starter fra modell av systemet, og forsøker å følge modellens dynamikk og logikk, på jakt etter typer angrep mot hvert element i modellen. Denne tilnærmingen er for eksempel brukt til trussel modellering i Microsofts SDL (Secure Development Lifecycle). Verdisentrisk Starter fra verdiene i og rundt et system, for eksempel sensitive data, omdømme, eller evne til å yte tjenester, og forsøker å identifisere hvordan angrep og skade på slike verdier kan skje. IN Sikker systemutvikling 13

14 Angripersentrisk trusselmodellering Hovedmål for angrep Theft of Auth Cookies Obtain auth cookie to spoof identity AND OR Delmålsettinger AND Unencrypted Connection Eavesdropping Cross-Site Scripting XSS Vulnerability Cookies travel over unencrypted HTTP Attacker uses sniffer to monitor HTTP traffic Attacker possesses means and knowledge Application is vulnerable to XSS attacks IN Sikker systemutvikling 14

15 Systemsentrisk trusselmodellering Bruker Klientplatform Internet Front-end Web server Back-end app. logic MySQL database Bruker åpner skadevare i vedlegg/lenke Buffer overflow og System exploits Trafikkavlytting Uautorisert tilgang SQL injection Sikkerhet i OS and SW Kryptering Bevissthetstrening Passordpolicy Inputvalidering Sikkerhetstiltak IN Sikker systemutvikling 15

16 Verdisentrisk trusselmodellering Data CIA HW and SW Company reputation Customer base Legal compliance DOS attack Penetration of servers Disclosure of user data Misuse of user data IN Sikker systemutvikling 16

17 STRIDE Trusselmodellering for programvareutvikl. S Spoofing (identitetstyveri) Kan en angriper få tilgang til ved å misbruke en annens identitet? T R I D E Tampering (kompromittering) Kan en angriper endre data som prosesseres av systemet? Repudiation (benekting) Kan en angriper benekter misbruk, uten at vi kan bevise misbruket? Information disclosure (datatyveri og -lekkasje) Kan en angriper få tilgang til konfidensielle og personlige data? Denial of service (tjenestenekt) Kan en angriper sabotere eller redusere tilgjengeligheten av systemet? Elevation of privilege (utvidet tilgang) Kan en angriper oppnå tilgangsrettigheter som privilegert bruker? IN Sikker systemutvikling 17

18 Trusselpoker Spilles med vanlig kortstokk. For hver trussel spilles en risikorunde og en løsningsrunde Hver deltager får en hel suite Hjerter, Spar, Ruter eller Kløver 1 kortstokk 4 deltagere, 2 kortstokker 8 deltagere osv. Identifiser alle relevante trussescenarier Spill trusselpoker over hvert trusselscenario Risikorunde Estimere både sikkerhetsrisiko og personvernrisiko for trusselscenariet Partallskort (2, 4, 6, 8, 10, Q) Sikkerhetsrisiko Oddetallskort (3, 5, 7, 9, J, K) Personvernrisiko Løsningsrunde (ligner på «planning poker») Estimere tid for å fjerne relevante sårbarheter (dvs. blokkere trusselen) Partallskort (2, 4, 6, 8, 10, Q) tidsbruk i nåværende sprint Oddetallskort (3, 5, 7, 9, J, K) tidsbruk i backloggen (annen sprint) IN Sikker systemutvikling 18

19 Personvernrisiko er ikke personvernkonsekvens (DPIA) (Art. 5: Prinsipper for behandling av personopplysninger) 1. Personopplysninger skal behandles med: a) Lovlighet, rettferdighet og åpenhet b) Formålsbegrensning c) Dataminimering Personvernkonsekvens d) Riktighet e) Lagringsbegrensning f) Integritet og konfidensialitet Personvernrisiko 2. Den behandlingsansvarlige har ansvar for pkt. 1 ovenfor. IN Sikker systemutvikling 19

20 Sikkerhetsrisiko (partall) Tall Beskrivelse 2 Ubetydelig sikkerhetsrisiko, kan ignoreres 4 Svært lav sikkerhetsrisiko, kan løses hvis det kan gjøres meget enkelt og raskt. 6 Lav sikkerhetsrisiko, bør løses hvis det bare krever relativt lav innstats og kort tid. 8 Moderat sikkerhetsrisiko, bør løses selv om det krever betydelig innsats og tid. 10 Høy sikkerhetsrisiko, bør alltid løses såfremt det er praktisk mulig. Q (12) A (14) Meget høy sikkerhetsrisiko som må løses uten unntak. Ekstrem personvern- og/eller sikkerhetsrisiko. Det bør stilles spørsmål om det er forsvarlig at denne brukerhistorien eller funksjonen implementeres i det hele tatt. IN Sikker systemutvikling 20

21 Personvernrisiko (oddetall) Tall Beskrivelse 3 Ubetydelig personvernrisiko, kan ignoreres. 5 Svært lav personvernrisiko, liten eller ingen konsekvens for datasubjektene. 7 Lav personvernrisiko, forbigående eller lav negativ konsekvens for datasubjektene. 9 Moderat personvernrisiko, lang eller moderat negativ konsekvens for datasubjektene. 11 Høy personvernrisiko, permanent eller høy negativ konsekvens for datasubjektene. K (13) A (14) Meget høy personvernrisiko, alvorlig permanent konsekvens, mulighet for å bli suicidal, må løses Ekstrem personvern- og/eller sikkerhetsrisiko. Det bør stilles spørsmål om det er forsvarlig at denne brukerhistorien eller funksjonen implementeres i det hele tatt. IN Sikker systemutvikling 21

22 Forventet tidsbruk i nåværende sprint for å stoppe trusselen (fjerne sårbarhet) Implentering av ikke-funksjonell sikkerhet for brukerhistorien Partall (løsning i denne sprint) Tall Beskrivelse 2 Så godt som utført og løst allerede. 4 Svært lav innsats, lett å løse nåværende sprint 6 Lav innsats, relativt lett å løse som del av nåværende sprint. 8 Moderat innsats, vil kreve god del arbeid i nåværende sprint. 10 Høy innsats, vil ta det meste av tiden for det meste av teamet under nåværende sprint. Q Meget høy innsats, vil kreve så mye arbeid at nåværende (12) sprint må forlenges., A (14) Umulig å løse som del av dette programvareprosjektet. Løsningen må eventuelt finnes helt uavhengig av dette prosjektet. IN Sikker systemutvikling 22

23 Forventet tidsbruk i en annen sprint (for backloggen) Implementering av funksjonell sikkerhet i en brukerhistorie Oddetall (løsning legges i backloggen) Tall Beskrivelse 3 Allerede (planlagt) løst i en annen sprint 5 Svært lav innsats i en annen sprint. 7 Lav innsats, relativt lett arbeid i en annen (kanskje dedikert) sprint. 9 Moderat innsats, vil greve en god del arbeid i en annen (kanskje dedikert) sprint. J (11) K (13) A (14) Høy innsats som vil kreve en dedikert sprint kun for å eliminere dette trusselscenariet Meget høy innsats som sannsynligvis vil måtte kreve en lang sprint med stor innsats. Umulig å løse som del av dette programvareprosjektet. Løsningen må eventuelt finnes helt uavhengig av dette prosjektet. IN Sikker systemutvikling 23

24 Regler for trusselpoker 1. Identifiser relevante trusselscenarier for hver sprint Bruk f.eks. STRIDE-trusselmodellering 2. Velg ett spesifikt trusselscenario om gangen Diskuter aspekter rundt dette trusselscenariet 3. Risikorunden Spill ut kort med ansikt ned for risikonivå Eventuelt både for sikkerhetsrisiko og personvernrisiko Vend og vis kort, diskuter avvik mellom tallene på bordet Spill ny omgang, med ny diskusjon, helt til det oppstår konsensus 4. Løsningsrunden Spill ut kort med ansikt ned for tidsbruk i løsning Eventuelt både for denne sprint og backloggen Vend og vis kort, diskuter avvik mellom tallene Ny omgang, ny diskusjon, helt til konsensus 5. Beslutning om å løse trussel når: Risiko Tidsbruk 0 Løsningstall Løs! UiO 24 Risikotall Spring 2015 IN Sikker systemutvikling 24

25 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 Sikkerhetsfunksjon som er unødvendig for brukerhistorien men nødvendig for å stoppe trusler Sikkerhetsfunksjon som er «usynlig» for brukeren F.eks.: Inputvalidering mot SQL-injection og XSS IN Sikker systemutvikling 25

26 Eksperiment med trusselpoker Trusselpoker er utviklet på IFI som del av et Masterprosjekt 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 IN Sikker systemutvikling 26