Design

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)