Programvareutvikling med innebygd personvern

Programvareutvikling med innebygd personvern

Denne veiledningen skal hjelpe til med å forstå og etterleve kravet om innebygd personvern i personvernregelverket. Innholdet er utarbeidet i samarbeid med sikkerhetseksperter og programutviklere i privat og offentlig sektor. Veiledningen har også vært på høring i flere virksomheter og organisasjoner. 

Innledning

English version

The guidelines about Software development with Data Protection by Design and by Default are also available in English.

Veiledningen retter seg først og fremst mot utviklere, arkitekter, prosjektledere, testere og personvern- og sikkerhetsrådgivere som utvikler, eller bidrar til utvikling av, programvare som inneholder personopplysninger.

Bakgrunn

Programvareutvikling bør følge en metodikk med grunnleggende aktiviteter for å sikre at sluttproduktet blir robust. Det finnes mye faglitteratur om å bygge inn sikkerhet ved utvikling av programvare. Samtidig er det lite faglitteratur om hvordan personvern bygges inn i programvare. I arbeidet med dette innholdet har vi tatt utgangspunkt i Microsoft Security Development Lifecycle (SDL) og Secure Software Development LifeCycle (S-SDLC), og sett på hvordan vi kan knytte prinsipper, rettigheter og krav i personvernregelverket til hver aktivitet.

Syv aktiviteter i en kontinuerlig prosess

Veiledningen inneholder de syv aktivitetene vi anser som viktige i en prosess som skal utvikle programvare med innebygd personvern. Hver aktivitet er gjengitt som en puslespillbrikke eller et steg som fører til neste aktivitet i sirkelen. Vi har valgt en sirkel for å vise at både programvareutvikling og arbeidet med personvern er kontinuerlige prosesser.

Vi beskriver hver av aktivitetene med våre anbefalinger til hvordan vi mener hver aktivitet bør gjennomføres, og hvilke tiltak som vi anser som viktige for å lykkes med kravet om å bygge personvern inn i en programvare. Det betyr likevel ikke at enhver virksomhet må ha en metodikk som slavisk følger denne prosessen for å utvikle programvare med innebygd personvern. Det er opp til den enkelte virksomhet å vurdere hvilken metodikk som skal brukes, hvilke tiltak, områder og faser som skal vektlegges og hvor innsatsen skal økes. Valg av metodikk vil typisk påvirkes av tjenesteområde, virksomhet, type programvare som skal utvikles, og betraktninger rundt og oppfattelse av egen risiko.

Vi ønsker ikke at innholdet skal brukes til å legge opp til stringente, sekvensielle og rigide prosesser rundt hver aktivitet. Den bør heller tilpasses til metodikken som virksomheten selv har valgt å bruke. I virksomheter som gjennomfører kontinuerlig produksjonssetting i høyt tempo, bør dere vurdere hvordan veilederen best mulig kan sikre at de grunnleggende kravene for personvern og sikkerhet er på plass, og hvordan for eksempel personvern- og sikkerhetstester kan inkluderes i helautomatiske testregimer. 

Oppsummering av aktivitetene

  1. Opplæring
    Denne aktiviteten sier noe om hva det er viktigst å gi opplæring i, hvordan det kan løses og hvilke verktøy som kan benyttes.
  2. Krav
    Krav beskriver hva som bør gjøres for å sette riktige krav til personvern og sikkerhet, at virksomheten bør sette toleransenivå for personvern og sikkerhet, og at det bør gjennomføres en vurdering av sikkerhetsrisiko og en vurdering av personvernkonsekvenser.
  3. Design
    Denne aktiviteten tar kravene videre til design gjennom å dele inn i dataorienterte og prosessorienterte designkrav. I denne aktiviteten er det viktig at virksomheten gjennomfører en analyse av angrepsflaten og en trusselmodellering.
  4. Koding
    Aktiviteten om koding understreker hvor viktig det er at utviklere bruker godkjente verktøy og rammer, at utrygge funksjoner og moduler bør ugyldiggjøres, og at statisk kodeanalyse og kodegjennomgang bør gjennomføres regelmessig.
  5. Test
    Test innebærer en anbefaling om å teste om personvernkrav og sikkerhetskrav er riktig implementert, en beskrivelse av hva slags sikkerhetstester som bør gjennomføres, og en forklaring på hvor viktig det er å gjennomgå trusselmodell og angrepsflate.
  6. Produksjonssetting
    Før produksjonssetting bør en plan for hendelseshåndtering etableres og det bør gjøres en full sikkerhetsgjennomgang av programvaren. Deretter godkjennes produksjonssetting og all relevant data fra hele utviklingsløpet arkiveres.
  7. Forvaltning
    Den siste aktiviteten omhandler forvaltning og drift av programvaren. Virksomheten bør være forberedt på å håndtere hendelser, avvik og angrep, og i stand til å gi ut oppdateringer, veiledning og informasjon til brukere og berørte.

Veilederen er utarbeidet i samarbeid med sikkerhetseksperter og programutviklere i privat og offentlig sektor. 

En stor takk til:
Dagfinn Bergsager (UiO), Johannes Brodwall (Sopra Steria), Andreas Hegna (Storebrand), Karoline Klever (Microsoft), Rita Nortug (Nets), Eirik Saltkjel (Direktoratet for e-helse), Eskild Storvik (Capgemini).