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.

Plakat over de syv fasene i programvareutvikling med innebygd personvern, A3-format (pdf)

Retten til personvern inneholder en rekke grunnleggende prinsipper for å ivareta personvernet til de som registreres. Innebygd personvern skal sørge for at informasjonssystemene vi bruker oppfyller personvernprinsippene, og at de ivaretar de registrertes rettigheter.

Sentralt krav i regelverket

Innebygd personvern og personvern som standardinnstilling er et sentralt krav i personvernregelverket. Vi vil her beskriver hvordan dette kravet kan ivaretas. Den behandlingsansvarlige skal følge kravet om innebygd personvern ved utvikling av programvare, og ved bestilling av system, løsninger og tjenester. Kravet bør derfor også inkluderes når man inngår avtaler med leverandører og ved bruk av konsulenter.

Åpenhet er et nøkkelord i regelverket og det er også avgjørende når man bygger personvern inn i programvaren. Åpenhet om bruk av personopplysninger dreier seg blant annet om å gi svar på hva som behandles, av hvem, hvorfor, hvordan, hvor og hvor lenge. For å kunne benytte oss av rettighetene våre, må virksomheter være åpne om sin behandling av personopplysninger. Da kan de registrerte delta i beslutningsprosessen og sikre legitimiteten og effektiviteten for den behandlingsansvarlige.

Personvernhensyn gjennom hele prosessen

Forankring hos ledelsen er avgjørende for at det kan tas en beslutning om at virksomhetens innkjøp og programvareutvikling skal omfatte innebygd personvern. Ledelsen må også sikre at det settes av tilstrekkelig med ressurser til dette arbeidet. Å ta hensyn til personvernet gjennom hele utviklingsløpet er både kostnadsbesparende og mer effektivt enn å endre en ferdigutviklet programvare. Virksomheter som ikke følger personvernregelverket risikerer betydelige kostnader, både ved gebyr for å ha brutt reglene og ved at de taper av omdømme.

Målgruppen for denne fasen er ledelse og ansatte i virksomheten.

Hva skal det gis opplæring i? 

Kunnskap om personvern og informasjonssikkerhet er en forutsetning for å utvikle programvare med innebygd personvern. De ansatte må vite hvilke krav som gjelder, hva de skal se etter og hvilke verktøy som gjør dem i stand til å omsette kunnskap om personvern og informasjonssikkerhet til programvare som ivaretar dette.

De ansatte må vite hvilken metodikk og hvilke rutiner som skal følges. Virksomheten må selv finne ut hva som er relevant og hva den enkelte ansatte trenger opplæring i. Deretter må det lages en opplæringsplan.

Hvilke krav gjelder for virksomheten?

De ansatte bør få opplæring i gjeldende interne og eksterne krav. Interne krav kan omhandle personvern, informasjonssikkerhet, internkontroll og organisering av ressurser. Det inkluderer rutiner for risikovurderinger og krav til dokumentasjon. Eksterne krav omfatter personvernregelverket generelt, betydningen av personvernprinsippene spesielt og hvilke rettigheter de registrerte har.

Andre eksterne krav kan være regelverk og obligatoriske krav knyttet til fagområde, sektor eller bransje som programvaren skal utvikles for. I tillegg kan det være krav om å følge beste praksis, standarder eller normer innenfor teknologien som er valgt. Eksempler på dette er offentlighetsloven, pasientjournalloven, den kommende kommunikasjonsvernforordningen (ePrivacy) , IKT-forskriften og rammeverk for informasjonssikkerhet som for eksempel ISO27001 (standard.no) og The ISF Standard of Good Practice for Information Security (SoGP) (securityforum.org) 

Hvordan kan dette løses?

Programvareutviklere skal ha og følge en etablert metodikk for å utvikle programvare. Metodikken skal være godkjent av ledelsen. Ved utvikling av programvare som behandler personopplysninger, skal metodikken omfatte innebygd personvern og innebygd sikkerhet. Eksempler på rammeverk for utvikling med innebygd sikkerhet er Microsoft Security Development Lifecycle (SDL) (microsoft.com) og OWASP Flagship projects (owasp.org)

Hvilke verktøy kan benyttes?

Virksomheten bør utarbeide en oversikt over hvilke verktøy, standarder og beste praksis som skal brukes ved programvareutvikling. De ansatte bør få opplæring i hvilke verktøy de kan bruke, hvordan og til hva. Eksempler på verktøy for sikkerhetstesting, målinger og trusselmodellering med videre finnes blant annet i:
OWASP Application Security Verification Standard Project (owasp.org)

OWASP Testing Project (owasp.org)

ISO27k information security (iso27001security.com) 

Microsoft SDL (microsoft.com)

Last ned

Eksempel på sjekkliste for opplæringsfasen (pdf)

Målgruppen for denne fasen er alle som er involvert i utviklingen eller som har eierskap til programvaren som kravstiller, produkteier, kunde/bestiller, prosjektleder, utvikler, arkitekt, tester. Personvernombud og sikkerhetsrådgiver bør også bidra i prosessen.

Når personvern- og sikkerhetskrav, toleransenivåer, personvernkonsekvenser og sikkerhetsrisikoer avdekkes tidlig, vet utviklingsteamet hvilke krav de må forholde seg til. De kan da håndtere risiko knyttet til personvern og informasjonssikkerhet i hele utviklingsløpet.

Personvern- og sikkerhetskrav

For å sette riktige krav er det viktig å vite hva slags typer personopplysninger som skal behandles i programvaren, hvilke slutninger som kan trekkes om individer på bakgrunn av informasjon som behandles, hvem som er bruker og eier av opplysningene, hvem som defineres som behandlingsansvarlig, og eventuelt hvem som er databehandler eller mottakere av personopplysningene. Dette er nødvendig for å vite hvilke lover, regler, retningslinjer og normer som er relevante for programvaren som utvikles. Disse legger føringer for kravene som må stilles til programvaren.

Relevante personvern- og sikkerhetskrav finnes i personopplysningsloven, virksomhetens rutiner og retningslinjer for personvern og informasjonssikkerhet, ulike sikkerhetsstandarder, atferdsnormer (bransjenormer) eller andre relevante lovverk og føringer knyttet til sektoren. Virksomheten må selv avgjøre hvilke krav som er relevante for sin virksomhet, for programvaren som utvikles og sammenheng sluttproduktet skal brukes i. Personvernkrav og sikkerhetskrav bør formuleres i en sjekkliste som integreres i prosjektplanen og følges opp gjennom hele utviklingsløpet.

Må oppfylle grunnleggende personvernprinsipper

De viktigste kravene til en programvare med innebygd personvern er at de grunnleggende prinsippene for behandling av personopplysninger er oppfylt. Behandlingen skal ha et rettslig grunnlag (for eksempel samtykke, lovhjemmel, avtale), skal gjøres for bestemte formål og det skal kun innhentes opplysninger som er nødvendig for at programvaren skal fungere slik det er tenkt.

Med «nødvendig» mener vi at dere må vurdere mengde, omfang, lagringstid og tilgjengelighet knyttet til personopplysninger. For eksempel bør dere vurdere hvor detaljerte opplysninger det er behov for, om det er nødvendig med historikk, hvor lenge opplysningene må lagres, om automatiske sletterutiner kan gjennomføres, hvor opplysningene skal lagres, og hvem som skal ha tilgang til opplysningene og fra hvor.

Tydelig informasjon og god sikring

Klar og tydelig informasjon om hvordan personopplysningene brukes er grunnleggende for å ivareta brukerens personvern. Programvaren må gjøre det enkelt for den registrerte å ivareta sine rettigheter som for eksempel:

• innsyn
• informasjon
• korrigering
• begrensning
• dataportabilitet

Dette kan for eksempel løses med en innloggingsportal som gir oversikt over hvilke opplysninger som er registrert, informasjon om rettigheter og hjelpeskjema for å komme med innsigelser eller korrigeringer med videre.

Virksomheten skal ivareta personopplysningenes sikkerhet under innsamling, lagring, bearbeiding, visning, kommunikasjon, og sletting. Kryptering og tilgangsstyring er eksempler på tiltak som kan bidra til å ivareta sikkerheten.

Sikkerhetskravene til programvaren bestemmes ved å identifisere hvilken risiko programvaren kan være utsatt for og hvilken risiko virksomheten er villig til å ta. Dette legger føringer for valg av relevante og riktige tiltak for den enkeltes virksomhet og for programvaren. Vi anbefaler å bruke Datatilsynets sjekklister og anerkjente standarder for informasjonssikkerhet i utvelgelsen av relevante tiltak.

Definere toleransenivå for risiko

Risikovurdering handler om å identifisere konsekvenser ved ulike hendelser eller scenarier, og vurdere hvor sannsynlig eller lett en uønsket hendelse kan inntreffe. Det er virksomhetens ledelse som avgjør hvor stor risiko (risikoappetitt) virksomheten skal ta ved ulike scenarier. Dette kalles toleransenivå for risiko. Toleransenivå gir føringer for hvilke tiltak og ressurser som må settes inn for at programvaren ikke skal overskride det definerte toleransenivået.

Når det gjelder sikkerhet defineres toleransenivå for risiko enkeltvis for ulike «sikkerhetskategorier». Eksempler på sikkerhetskategorier kan være:

• utilsiktet endring av personopplysninger
• uautorisert utlevering av personopplysninger
• manglende tilgjengelighet som kan ha betydning for liv og helse

Når det gjelder personvern defineres toleransenivå for risiko enkeltvis for ulike «personvernscenarier». Eksempler på personvernscenarier kan være:

• at den registrerte ikke lenger har kontroll over sine personopplysninger
• at den registrerte utsettes for diskriminering på grunn av profilering gjort av programvaren
• at en person reidentifiseres av opplysninger som er blitt anonymisert

Noen sikkerhetskategorier og personvernscenarier vil ha nulltoleranse for risiko, mens for andre sikkerhetskategorier og personvernscenarier kan virksomheten bestemme seg for å ta en viss risiko. Ledelsen må sette akseptabelt toleransenivå, det vil si risikoappetitt, for henholdsvis personvern og sikkerhet.

Virksomhetens risikoappetitt dokumenteres ved å sette toleransenivå for ulike kategorier eller scenarier på personvern og sikkerhet, ofte i en hjelpetabell som kan gjenbrukes i andre risikovurderinger.

Vurdering av sikkerhetsrisiko

Personvernregelverket definerer personopplysninger som en verdi. En risikovurdering begynner med en kartlegging av verdier som bør sikres.

Det bør gjøres en trusselvurdering av hvilke aktører som kan være interessert i verdiene og hvilke angrepsvektorer de ulike trusselaktørene benytter. Deretter gjøres en vurdering av om verdiene er sårbare for de gitte truslene. Standarder for informasjonssikkerhet kan bidra til å avdekke sårbarheter og dermed også krav som må stilles til personvern og sikkerhet.

Resultatet av risikovurderingen vurderes opp mot toleransenivå for sikkerhet. Dersom risikonivået er høyere enn fastlagt nivå for akseptabel risiko, skal det iverksettes tiltak for å redusere risikoen. Det må også fastsettes hvem som er ansvarlig for tiltaket og settes en frist for implementering.

Vurdering av personvernkonsekvenser

Målet med å gjøre en vurdering av personvernkonsekvenser er å sikre at programvaren ivaretar den registrertes grunnleggende rettigheter - for eksempel at behandlingen er lovlig, rettferdig, og forutsigbar. For noen behandlinger av personopplysninger har den som er ansvarlig for behandlingen plikt til å utrede personvernkonsekvenser:

1. Ved systematisk og omfattende vurdering av personlige forhold når opplysningene brukes til automatiserte avgjørelser.
2. Ved behandling av sensitive personopplysninger i stort omfang.
3. Ved systematisk overvåking av offentlig område i stort omfang.

Er dere i tvil anbefaler vi at dere utfører en vurdering av personvernkonsekvenser (DPIA). Vurderingen skal som minimum inneholde:

• En systematisk beskrivelse av behandlingen, formål, og eventuelt hvilken berettiget interesse den ivaretar.
• En vurdering av nødvendighet og forholdsmessighet, sett opp mot formålet.
• En vurdering av risikoen for rettigheter og friheter til registrerte.
• Hvilke tiltak som skal iverksettes for å redusere risikoen.

I tilfeller der risikoen for personvernkonsekvenser er høy, skal det implementeres tiltak for å redusere risikoen. Dersom risiko for personvernkonsekvenser fremdeles er høy etter at tiltakene er implementert, og de ikke kan reduseres, krever personvernregelverket at dere kontakter Datatilsynet for en forhåndsdrøftelse.

Les vår veiledning om når og hvordan en vurdering av personvernkonsekvenser kan gjennomføres

Last ned

Eksempel på sjekkliste for kravsetting (pdf)

Målgruppen for denne fasen er primært arkitekter, sekundært personvernombud, sikkerhetsrådgivere og utviklere.

Det er viktig å ta høyde for at det vil finnes aktører som vil forsøke å få tak i og misbruke personopplysninger til egne formål. For å redusere angrepsflaten, må den analyseres og programvaren må modelleres og designes slik at sluttproduktet blir robust.

Designkrav beskriver nøyaktig og helhetlig hvordan egenskaper ved en programvare skal utvikles. Kravene bør beskrive hvordan funksjonalitet kan implementeres og distribueres på en sikker måte. For eksempel ved å designe identitetshåndtering der brukeren ser hva han eller hun har samtykket til, oppsett av sikkerhet rundt egen konto, passordhåndtering og hvordan innloggingsprosessen fungerer. Vi har delt opp designkrav i dataorienterte og prosessorienterte, slik som European Union Agency for Network and Information Security (ENISA) anbefaler.

Dataorienterte designkrav

1. Minimer og begrens 

   Mengden av innsamlede og prosesserte personopplysninger begrenses til det tillatte og kun det som er absolutt nødvendig. Opplysningene skal slettes når videre lagring ikke er nødvendig for formålet. «Select before you collect».

2. «Gjem og skjul» 

   Personopplysninger og sammenhengen mellom dem, bør ikke kommuniseres, behandles eller lagres i klartekst. Ved å skjule direkte identifiserende opplysninger fra visning i klartekst, reduseres risiko for misbruk og omfang av hendelser betydelig. Eksempler er pseudonymisering, kryptering og aggregering av personopplysninger.

3. Separer

   Ved å separere ulike behandlinger av personopplysninger tilknyttet en enkeltperson, reduseres muligheten for å lage komplette profiler av hver enkelt. Personopplysningene kan for eksempel lagres i adskilte databaser, entiteter og områder utfra ulike formål. Separasjon er også en god måte å oppnå formålsbegrensning og for å unngå urettmessig kobling og lenking mellom ulike datasett. Det bør fastsettes tid for automatisk sletting i tabeller med personopplysninger. Dette kan for eksempel gjøres i tilgangsstyringen til tabeller med personopplysninger, splitting av databasetabeller og ved å skille mellom enheter/områder som har høy tillit og lavere tillit.

4. Aggreger

   For å ivareta den registrertes personvern, bør personopplysninger samles inn og behandles mest mulig aggregert. Detaljerte personopplysninger bør unngås så langt det lar seg gjøre innenfor hva som fortsatt kan gi forretningsmessig verdi og som er relevant for formålet med innsamling og bruk. Eksempler er å redusere detaljer og sensitivitet på personopplysninger om enkeltpersoner, og å fjerne unødvendig eller overskuddsinformasjon når det er mulig. For å vise generelle trender eller verdier, kan statistiske data om flere personer kombineres uten å identifisere enkeltpersoner.

5. Personvern som standard

   Alle innstillinger skal, som standard, være konfigurert med den mest personvernvennlige innstillingen. Brukeren skal selv gjøre et bevisst valg om å endre innstillinger for å åpne opp for mindre personvernvennlige innstillinger. Det bør for eksempel være opp til brukeren selv å åpne opp for å dele mer data om seg selv med andre. Ved innstallering av en app bør den settes opp slik at appen aldri skal ha tilgang til å vite brukerens lokasjon eller å dele data med andre. Hvis brukeren ønsker disse funksjonene må han eller hun aktivt ta et valg for å endre innstillingene.

Prosessorienterte designkrav

1. Informer

   Programvaren bør designes slik at den registrerte er tilstrekkelig informert om hvordan programvaren fungerer og hvordan personopplysninger behandles. Den registrerte skal ha informasjon om at profilering og automatisert behandling av personopplysninger foregår og hvordan det foregår. Det er viktig å huske at det er spesielle krav som gjelder dersom programvaren skal rettes mot barn. For eksempel skal programvaren med et enkelt og forståelig språk gir informasjon om hva personopplysninger skal brukes til. Bilder, ikoner og symboler kan også brukes for gjøre informasjonen tydeligere. Animasjon, video og lyd kan være gode virkemidler for å tilpasse informasjonen til brukerens nivå for forståelse.

2. Kontroller

   Den registrerte har rett til å kontrollere egne personopplysninger. Det innebærer blant annet å be om innsyn, oppdatere og slette egne opplysninger. Der det er automatisert behandling og avgjørelser tas uten menneskelig innblanding, kan den registrerte kreve at det skal gjøres manuell behandling. Programvaren bør designes slik at den registrerte kan ivareta disse rettighetene på enklest mulig måte. Et eksempel er at brukeren via en meny eller en egen side i programvaren selv kan gi og fjerne samtykke, gi innsyn, blokkere, oppdatere og slette egne personopplysninger.

3. Håndhev

   Programvaren bør designes slik at det kan dokumenteres at den registrertes personvern blir ivaretatt. Dokumentasjonen bør omfatte ansvarsforhold og hvordan personvernregelverket håndheves. Den bør være tilgjengelig ved revisjon og kontroll av behandlingen. Dette omfatter også kunstig intelligens, profilering og automatisert behandling. Et eksempel er å ha en personvernerklæring som beskriver hvordan programvaren ivaretar de registrertes personvern, hvordan dere etterlever personvernregelverket og hvilke tekniske tiltak som er på plass for å beskytte personvernet. Tekniske tiltak kan være tilgangsstyring.

4. Demonstrer

   Den behandlingsansvarlige skal kunne dokumentere at den etterlever personvernregelverket og kravene til informasjonssikkerhet. Programvare skal tilrettelegges og utformes slik at den behandlingsansvarlige både kan dokumentere og vise hvordan personvernregelverket er implementert og ivaretatt. Eksempler er dokumentasjon som viser at programvaren er utviklet etter en metodikk som ivaretar innebygd personvern og informasjonssikkerhet, rapporter fra sikkerhetsrevisjoner, sikkerhetstester som penetrasjonstester og rapporter etter øvelser på hendelseshåndtering knyttet til personvern.

Reduser muligheten til å utnytte svakheter

Analyser angrepsflaten i den designede programvaren for å redusere muligheter til å utnytte svake punkter og sårbarheter. I en gjennomgang av designet bør input av data og hvor data sendes analyseres. Undersøk om samme type informasjon samles inn flere steder (dupliserende funksjonalitet) og vurder om funksjonaliteten kan forenkles. Ved å forenkle programvaren og fjerne unødvendig funksjonalitet vil sannsynligheten for feil reduseres.

I en slik analyse bør vurderingene av sikkerhetsrisiko og personvernkonsekvenser som er gjennomført i kravfasen benyttes. Ved funn skal sårbarhetsreduserende tiltak implementeres for å oppnå akseptabelt toleransnivå for personvern og sikkerhet. Toleransenivå skal også være utarbeidet i kravfasen. Analyse og reduksjon av angrepsflaten skal dokumenteres.

Trusselmodellering

Ved trusselmodellering analyserer man komponenter, tilgangspunkter, dataflyt og prosessflyt i programvaren. De involverte analyserer hvordan noen kan misbruke programvaren ved ulike scenarioer. Man gjennomgår hvert av scenarioene for å se hvordan designet kan forbedres for å unngå trusler som er identifisert. Dette gjøres ved å implementere sårbarhetsreduserende tiltak. Resultatet av dette er et mer herdet og robust sluttprodukt.

Som oppfølging bør det gjøres en risikovurdering av sårbarheter som gjenstår og som må håndteres ved andre tiltak. Disse sårbarhetene bør føres inn i et risikoregister.

Last ned

Eksempel på sjekkliste for designfasen (pdf)

Målgruppen for denne fasen er primært utviklere, sekundært personvernombud, sikkerhetsrådgivere og testere.

Det er viktig at virksomheten velger en sikker og felles metodikk for både for koding og for hvordan utviklere kan oppdage og fjerne sårbarheter fra koden. Automatiske verktøy for kodeanalyse bør innføres og virksomheten må ha rutiner for statisk kodeanalyse og kodegjennomgang.

Bruk godkjente verktøy og rammer

For å sikre en enhetlig praksis bør det defineres og publiseres en liste over godkjente og tillatte verktøy, prosesser og rammeverk for programvareutvikling og utrulling. I tillegg må det være klart hva ulike verktøy kan brukes til. Dette innebærer å beskrive godkjente verktøy med tilhørende sikkerhetsfunksjonalitet som kan bidra til å automatisere og håndheve sikkerhetsrutiner i kodingen. Listen bør også inneholde hvilke støttekomponenter, og komponenter og utviklingsverktøy fra tredjepart, som er tillatt å bruke under utvikling. Verktøy og støttekomponenter bør risikovurderes og analyseres for sårbarheter. Listen bør samstemmes med og godkjennes av sikkerhetsrådgiver, og den må oppdateres regelmessig. Det bør være et mål å bruke siste versjon av godkjente verktøy, slik at muligheter som ny sikkerhetsfunksjonalitet gir kan utnyttes. For eksempel kan listen inneholde godkjent krypteringsteknologi med nøkkellengde. Listen bør regelmessig oppdateres med de mest anerkjente og oppdaterte algoritmer og metoder, og hvilken nøkkellengde som er tilstrekkelig.

Programvare er i dag ofte sammensatt av flere samarbeidende tjenester. Det benyttes derfor et vesentlig større antall programmeringsspråk, biblioteker og rammeverk enn tidligere. Ofte legges både kode, biblioteker og serveroppsett sammen i mer statiske kontainere. Det er derfor er viktig at det settes opp regelmessig skanning etter sårbarheter i alle deler av koden, både i underliggende biblioteker og kontaineroppsett. Eksempler på dette kan man finne på GitHub (github.com) og Docker Security Scanning (docs.docker.com).

Ugyldiggjør utrygge funksjoner og moduler

Mange funksjoner, API-er, tredjepartsbiblioteker og moduler kan være usikre å bruke ut fra dagens trusselbilde. Det bør gjøres en analyse av alle funksjoner, API-er, tredjepartsbibliotek og moduler som brukes i programvareutviklingen. De som er utrygge forbys og de som er utdaterte eller inneholder kjente sårbarheter oppdateres. Når en forbudsliste foreligger, bør koden sjekkes (også arvet kode) for å erstatte forbudte funksjoner med tryggere alternativer. Dette kan gjøres ved å bruke verktøy for kodeskanning. I tillegg bør koden sjekkes for å deaktivere unødig sporing, logging og innsamling av personopplysninger. Utrygge funksjoner og moduler kan for eksempel håndteres av bibliotek som OWASP Dependency Check (owasp.org) 

Statisk kodeanalyse og kodegjennomgang

Statisk kodeanalyse og kodegjennomgang skal gjøres regelmessig. Statisk kodeanalyse sikrer at retningslinjer for sikker koding følges. Automatiske verktøy for kodeanalyse og kodegjennomgang bør brukes så langt det lar seg gjøre. I tillegg bør det gjøres en manuell gjennomgang av koden, for å sikre at man fanger opp svakheter som kan føre til feil bruk eller lekkasje av personopplysninger. Det kan for eksempel være vanskelig å fange mønstre siden data alene ikke nødvendigvis er å anse som personopplysninger, men at kobling av ulike typer data kan gi personopplysninger. For å ivareta personvernet er det viktig å kartlegge hvor personopplysninger lagres. En gjennomgang av koden bør spesielt se hvor personopplysninger skrives. En vanlig svakhet er å logge personopplysninger i applikasjonslogger med mangelfull sikkerhet.

Last ned

Eksempel på en sjekkliste for kodefasen (pdf)

Målgruppen for denne fasen er primært testere, sekundært personvernombud og sikkerhetsrådgiver, utviklere og prosjektleder.

Programvaren må testes for sårbarheter. Dette gjøres ved dynamisk testing, fuzz testing og penetrasjonstesting. Det er viktig å gjennomgå angrepsflaten for å verifisere at angrepsvektorer som ble avdekket i designfase, og eventuelle nye angrepsvektorer introdusert under koding, er håndtert. 

Test om personvernkrav og sikkerhetskrav er implementert

Det bør lages tester for å sikre at personvernkrav og sikkerhetskrav er ivaretatt gjennom design og koding, og at kravene er riktig implementert i programvaren. Sjekklisten som ble utarbeidet i kravfasen bør gjennomgås for å verifisere at alle komponenter for å ivareta kravene er med i programvaren. Verifiseringen inkluderer eventuelle nye komponenter som er introdusert senere i utviklingsløpet i aktivitetene for design og koding. Ved test skal det brukes syntetiske personopplysninger.

Sikkerhetstesting

Dette innebærer en omfattende testing av programvaren for å avdekke sårbarheter og for å være sikker på at koden ivaretar sikkerhet og personvern på tilstrekkelig måte. Det bør utarbeides et regime for automatisk kjøring av testsett, for eksempel hver gang programvaren bygges.

Dynamisk testing

Test funksjonalitet i kjørende kode ved å bruke verktøy eller manuell gjennomgang som analyserer hvordan programvaren oppfører seg ved ulike brukerrettigheter og ved kritiske sikkerhetsfeil. Testingen skal sikre at brukerne kun får tilgang til den informasjonen og funksjonaliteten de har rettigheter til. Det er viktig å verifisere at forsøk på å tilegne seg uautorisert informasjon logges som sikkerhetsfeil. Eksempler på kjente sikkerhetsfeil som bør undersøkes mens programvaren kjøres er Cross-site scripting og SQL injection. Sesjonshåndtering, cookie-bruk og tilgangskontroll bør også testes for å sikre at personopplysninger ikke kan hentes ut via brukere som ikke er logget inn.

Fuzz testing

Denne testaktiviteten gjennomføres ved å fremprovosere feil i programvaren. Dette kan gjøres ved å bruke verktøy som sender tilfeldig og misformet data (feil inputverdier) i alle mulige input-felt til programvaren manuelt, eller ved bruk av intelligente verktøy som analyserer sårbarheter i webapplikasjoner. Dersom programvaren har flere grensesnitt, bør dere etterstrebe å teste hvert enkelt av dem. Det bør brukes verktøy som kan analysere output og applisere sikkerhetskontekst. Webproxies med mulighet for å skanne etter sårbarheter i egen programvare er eksempler på slike verktøy.

Penetrasjonstesting/sårbarhetsanalyse

For å oppdage sårbarheter, bør penetrasjonstest eller sårbarhetsanalyse kjøres før produksjonssetting, og ellers med jevne mellomrom. Slike sikkerhetstester skal være lovlige og autoriserte forsøk på å finne, utnytte og avdekke sårbarheter. Etter at testen er gjennomført skal det implementeres tiltak som gjør programvaren mer robust. Fordi kunnskap kan være personavhengig, bør det rulleres på hvem som gjennomfører testing. Videre er det hensiktsmessig å bruke sikkerhetsrådgivere for å analysere resultatene.

Gjennomgang av trusselmodell og angrepsflate

Ettersom en programvare kan avvike fra funksjonelle og tekniske spesifikasjoner som er satt under krav- og designfasen, må trusselmodellen og angrepsflaten gjennomgås når programvaren er komplett. Denne gjennomgangen skal verifisere at angrepsvektorer som ble avdekket i designfasen er håndtert. Den skal også verifisere at nye angrepsvektorer som kan ha blitt introdusert i koding er identifisert og håndtert, og at trusselmodellen gjennomgås opp mot nyutviklet programvare. Siden krav kan ha endret seg underveis i utviklingsprosessen, må personvernkonsekvenser vurderes på nytt. Et eksempel er om det overføres mer data enn hva programvaren har bruk for, noe som kan medføre at slike data ikke er godt nok sikret eller ulovlig å bruke.

Last ned

Eksempel på en sjekkliste for testfasen (pfd)

Målgruppen for denne fasen er primært prosjektleder, sikkerhetsrådgiver og personvernombud. Ved utarbeidelse av en plan for hendelseshåndtering bør de som håndterer hendelser bidra, og i sikkerhetsgjennomgangen bør testere bidra.

I virksomheter som produksjonssetter tidlig og hyppig må det etableres en plan for hendelseshåndtering før første produksjonssetting, mens sikkerhetsgjennomgang bør gjøres ved hver produksjonssetting. Det er viktig at alle relevante data fra hele utviklingsløpet arkiveres.

Plan for hendelseshåndtering

Virksomheten må etablere en plan for å håndtere hendelser relatert til programvaren. Planen bør omfatte definerte ressurser og et kontaktpunkt eller responssenter som kan håndtere hendelser. Planen bør inneholde relevant kontaktinformasjon for bistand og eskalering, inkludert kontaktinformasjon til virksomhetens personvernombud. Planen bør også omfatte en oversikt over hvordan hendelser på kode arvet fra tredjepart skal håndteres. Responstiden bør defineres ut fra hvor viktig programvaren er. For eksempel vil programvare relatert til akuttbehandling innen helse sannsynligvis kreve responstid alle timer i døgnet, alle dager i året. Det er viktig å vurdere hvilke kanaler som brukes for å varsle hendelser. Ivaretar kanalene for eksempel sikkerheten til innholdet i meldingen og personvernet til den som rapporterer godt nok?

Planen bør definere hva en hendelse er og hvilken livssyklus den har. Det kan for eksempel være å detektere, analysere, rapportere, håndtere og normalisere. Videre bør planen beskrive konfigurering og håndtering av logger, inkludert hvilke føringer personvernregelverket legger for dette. I tillegg bør planen omfatte rutiner for evaluering av hendelseshåndtering («lessons learned»). Den bør også kort beskrive hvordan disse erfaringene kan få konsekvenser for utviklingsløpet, virksomheten og berørte.

Dersom hendelsen omfatter konfidensialitet-, integritet- eller tilgjengelighetsbrudd relatert til personopplysninger skal virksomheten varsle Datatilsynet innen 72 timer og den registrerte skal varsles umiddelbart.

Planen bør omfatte et regime for patching av programvaren som inkluderer policy og oppfølging. Dette omfatter også tredjepartskode. Planen bør oppdateres regelmessig og virksomheten bør definere hvilke triggere som krever oppdatering.

Full sikkerhetsgjennomgang av programvaren

Gjennomgangen skal baseres på tidligere gjennomganger i utviklingsløpet og inngå i de kontrollpunkter (control gates) som må gjøres før produksjonssetting. Alle krav, analyser og vurderinger gjort i utviklingsløpet skal gjennomgås på nytt for å avdekke eventuelle avvik. Ulike ekspertgrupper bør involveres i sikkerhetsgjennomgangen for å sikre en best mulig gjennomgang av ulike scenarier og konsekvenser, og best mulig kvalitet på eventuelle tiltak som implementeres.

Godkjenning av produksjonssetting

Sikkerhets- og personvernombud skal verifisere at alle definerte personvern- og sikkerhetskrav er implementert og fungerer etter hensikten. Virksomheten må definere hvem som har godkjenningsmyndighet.

All relevante data og dokumentasjon fra hele utviklingsløpet bør arkiveres. Dette er viktig for å utføre supportoppgaver og vil bidra til å redusere langsiktige kostnader knyttet til forvaltning og vedlikehold. Arkivering er i tillegg viktig for kunder og kontrollmyndigheter.

Last ned

Eksempel på sjekkliste for fasen med produksjonssetting (pdf)

Målgruppen for denne fasen er primært ansatte på responssenteret, sikkerhetsrådgiver og personvernombud samt ansatte i forvaltning, drift og vedlikehold.

Virksomheten må være forberedt på å håndtere hendelser, avvik og angrep som kan medføre konfidensialitets-, integritet- og tilgjengelighetsbrudd relatert til personopplysninger. Den bør ha et responssenter som kan håndtere hendelser og gi ut oppdateringer, veiledning og informasjon til brukere og berørte.

Håndtere hendelser og avvik

Virksomheten bør følge en plan for hendelseshåndtering. Når akutte hendelser opptrer, er det viktig å bevare roen og å bruke tid på å analysere hendelsen. Vær oppmerksom på at hendelsens karakter kan medføre endringer i hvordan planen følges. Responsteamet skal vite hvem de skal kontakte etter behov og hvem som er i stand til å bygge, teste og installere oppdateringer. Responsteamet bør også vite hvilke prioriteringer som gjelder, og vite nøyaktig hva de kan og skal gjøre når det virkelig er krise. For å få til dette trenger de ansatte regelmessige øvelser. For informasjon om gjennomføring av øvelser, se Difis veileder for planlegging og gjennomføring av IKT-øvelser

Hendelser skal rapporteres til et definert kontaktpunkt eller responssenter, som håndterer interne og eksterne hendelser. Rapportering av hendelser skjer via de kanaler som er beskrevet i planen for hendelseshåndtering som ble utarbeidet i aktivitet 6, produksjonssetting. Brukere av programvaren bør oppfordres til å rapportere inn feil, sårbarheter og mangler, slik at programvaren kontinuerlig kan forbedres og videreutvikles. Evaluering av hendelser bør følge planen.

Forvaltning, drift og vedlikehold av programvaren

Sørg for å følge virksomhetens rutiner for forvaltning, drift og vedlikehold av programvaren. Det inkluderer blant annet rutiner for hvordan personvern og sikkerhet skal ivaretas over tid. Eksempler på rutiner for å ivareta dette er:

• regelmessige sikkerhetstester
• sårbarhetsanalyser og penetrasjonstester på programvare, infrastruktur og nettverk

Rutinene bør også omfatte feilretting, ytelsesforbedringer og oppdatering og patching av både programvare og tredjepartskomponenter.

Det er viktig å definere hva som kan og skal logges. I tillegg må virksomheten regelmessig sikre, overvåke og følge opp hendelser i loggene. Vær oppmerksom på at personopplysninger som logges, ofte eksporteres til andre applikasjoner og kan bli tilgjengelig for flere personer enn de som har tjenestlig behov.

Gjennomfør regelmessige revisjoner og egenkontroller for å dokumentere samsvar med relevante regelverk.

Virksomheten bør ha et styringssystem for personvern og informasjonssikkerhet som omfatter anskaffelse, forvaltning, drift og vedlikehold. Styringssystemet bør være etablert i henhold til anerkjente rammeverk.

Last ned

Eksempel på sjekkliste for forvaltningsfasen (pdf)