10 spørsmål og svar om Smittestopp-appen

Les intervjuet med prosjektleder og Tekna-medlem Inga Nordberg om prosessen bak utviklingen av Smittestopp-appen – om tidspresset og de vanskelige vurderingene. 

Intervjuet danner bakgrunnen for de 10 spørsmålene vi har stilt FHI om tekniske løsninger og vurderinger av personvern.  Spørsmålene er besvart av informasjonssikkerhetssjef i FHI, Pål Solerød, systemarkitekt Lars Kristian Roland (til vanlig seksjonsleder for arkitekturstyring i Direktoratet for e-helse) og Jan Gunnar Broch fra Direktoratet fra e-helse.

1.  –  Det er stilt kritiske spørsmål om det er mulig å programmere et så avansert verktøy på så kort tid uten mange bugs og sikkerhetshull. Kan dere fortelle om utviklingsfasene, kvalitetssikringsarbeid, og beskrive noen av de vanskeligste tekniske utfordringene og hvordan dere løste disse? Hvordan håndterer dere feilretting og sikkerhetsforbedring etter lansering? Hvilke feil er det sannsynlig at brukere og hackere finner i appen?

–  Ja, dette har vært et utviklingsarbeid som har gått fort og det er naturlig å stille spørsmålet om det lar seg gjøre uten alvorlige sikkerhetshull. Prosjektet startet i første halvdel av mars, og vurderinger rundt sikkerhet og personvern var viktige fra begynnelsen av. Behandling av sensitive personopplysninger har vi gode rutiner for i helse- og omsorgssektoren, og de gjelder selv om Norge er rammet av en epidemi. Det hadde ikke vært mulig å gjennomføre prosjektet hvis det ikke var for mange dyktige fagpersoner som har jobbet godt sammen. Kanskje var så utstrakt bruk av videokonferanse og hjemmekontor faktisk med på å bryte ned noen av de vanlige barrierene mellom organisasjoner og gi økt samarbeid på tvers. Nå handlet det ikke så mye om hvor møtene skulle være og hvilken virksomhet du tilhørte, men å få de riktige fagpersonene med og lytte til råd fra de som kunne hjelpe.

–  Dette har dermed ikke vært et vanlig utviklingsprosjekt, men det har vært en forutsetning for arbeidet at løsningen som lanseres skal anses som sikker og det har vært nødvendig å vente på ferdigstillelse av ROS (risiko og sårbarhet)-arbeidet og de viktigste identifiserte sikkerhetstiltakene før løsningen kunne lanseres.

Ikke helseinformasjon i sky

–  Et viktig tiltak har vært å dele opp funksjonaliteten i flere moduler som kan utvikles parallelt og leveres på forskjellige tidspunkt. Spesielt i appen ønsket vi å begrense funksjonaliteten til det absolutt nødvendige for å redusere risiko. Den første versjonen fremstår vel derfor som ganske kjedelig. Vi tok valg som å ikke lagre helseinformasjon i skyløsningen og ikke vise sensitiv informasjon i appen, for å redusere risiko. På sikt kan det hende at vi bør vise varsler og kanskje ha innsyn i noen data om deg selv i appen, men dette krever mer analyse rundt sikkerheten.

–  Vi tok noen valg tidlig som for eksempel å ikke bruke ID-Porten med personnummer. Vi gjorde dette av flere grunner, noen basert på forutsetninger som forandret seg og ikke lenger gjelder. Når valget om SMS-innlogging og det å utelate personnummer av personverngrunner var tatt, ble dette vanskelig å gjøre om på. Dette har gjort deler av løsningene vanskeligere å utvikle fordi vi ikke har personnummer på alle brukere. Vi bruker kontakt- og reservasjonsregisteret til å oversette mellom personnummer og telefonnummer, men denne løsningen har svakheter fordi man kan legge inn det telefonnummeret man ønsker selv. Vi vil derfor vurdere å legge til mer informasjon i registreringen som kan validere identiteten på brukeren framover. Men vi vet jo samtidig at dette fort vil bli kritisert av personvernårsaker. Det er en fin balanse mellom å samle inn for mye informasjon og ikke ha nok. Vi har vært klar over at valgene våre må tåle en debatt og det er en god ting.

Strever med lokasjonsdata

–  Et annet vanskelig punkt har vært innsamling av lokasjonsdata. Det har vært mange uttalelser både i Norge og EU om at lokasjonsdata ikke er nødvendig for å identifisere nærkontakter. Vi tror at det kan være uansvarlig å introdusere en slik løsning kun basert på Bluetooth, fordi mangel på validering kunne føre til feil varsler. Det kan også være at algoritmene må endres over tid og at lokasjonsdata kan være til hjelp der. Hva om det for eksempel viser seg at reglene for varsler om nærkontakt bør være annerledes på forskjellige steder, innendørs og utendørs? På dette området er vi altså usikre, både fordi noen telefoner fungerer annerledes på Bluetooth enn andre og fordi vi ønsker en måte å validere at nærkontakter faktisk har skjedd. Dette er et område vi forventer å lære mer etter hvert, og vi hører fra andre europeiske land at de strever med det samme.

–  I Smittestopp brukes lokasjon også til å vurdere effekten av smitteverntiltak på populasjonsnivå, men her benyttes ikke direkte personidentifiserbare data til analyser. Det er viktig at vi har gode rutiner for anonymisering og en grundig ROS-analyse av denne delen av løsningen før den tas i bruk. Dette er ikke på plass helt ennå, det vil derfor ta litt tid før vi får resultater på dette området.

Sentral lagring – åpne testdata

–  Et annet spørsmål som har vært diskutert gjennom hele prosjektet har vært bruk av sentral lagring. Noen andre løsninger har lagt opp til at data lagres lokalt i telefoner og kun lastes opp til sentrale løsninger hvis personen blir smittet. Noen løsninger har også lagt opp til at varsling og kontaktsporingsalgoritmene ligger i telefonene. Ved å lagre sentralt har vi muligheten til å sammenligne data fra flere telefoner før vi sender ut varsler, og tilpasse løsningen underveis ettersom vi lærer. Men det kommer til å bli utfordrende å utvikle algoritmer uten å kunne se på dataene man analyserer, så kanskje må vi gjøre mer for å få inn åpne testdata.

–  Med mer logikk i appen må man være sikker på at algoritmene er riktig, for det er vanskelig å oppdatere en hel base med apper dersom man finner ut at løsningen bør forandres. Sentral lagring og sentrale algoritmer gir større fleksibilitet til endring, men har jo helt tydelige personvernutfordringer, så vi har diskutert denne balansen mye i prosjektet. Selv om vi kan lagre data sikkert sentralt, så skal vi ikke gjøre det uten at det er veldig gode grunner til det.

–  Vi tror ikke at brukere finner sikkerhetsfeil i appen, men hvordan valgene våre vurderes av andre kan vi ikke være sikre på. Vi må være åpne for kritikk og endringsforslag, og synes det er bra at mange kommer med konstruktive tilbakemeldinger på hvordan vi kan utvikle Smittestopp til å bli bedre. Heldigvis har vi hatt eksterne til å gjennomføre penetrasjonstester og samarbeid med en oppnevnt ekspertgruppe har vært svært nyttig.

 2. –  Hvilke tekniske og etiske utfordringer og dilemmaer møtte dere og hvilke valg ble gjort? Hvilke risiko- og sårbarhetsanalyser er gjennomført og hvor ser man de største risikoene – hvordan håndteres disse?

 –  Å digitalisere smittesporing og å bruke aggregert og anonymisert informasjon til å overvåke epidemiutviklingen og evaluere tiltak, finnes det svært lite erfaring med. Vi kan derfor ikke være bastante på hvilken nytte den gir. Et viktig etisk dilemma er hvor langt vi skal gå når det finnes usikkerhet. Vi tror Smittestopp vil gi stor nytte sammen med økt testkapasitet og strategi for karantene og isolasjon. Dette må vi følge nøye med på framover slik at man får trygghet på at appen gir den nytten som man ønsker. Vi samarbeider også med andre land som går gjennom tilsvarende tester. Vi er glade for at mange andre enn oss har tenkt på personvern og nytte i denne saken. Det er viktig at vi teknologer som lager slike løsninger også tenker på personvern og nytteverdi.

Ekspertgruppe til stor hjelp

–  I alle prosjekter vi gjennomfører i helse- og omsorgssektoren er risiko og sårbarhetsanalyser viktige. Disse hjelper oss å identifisere risikoer og finne de riktige tiltakene. ROS-analysearbeidet i Smittestopp har vært veldig omfattende, og vi har fått god hjelp fra mange forskjellige parter. Mange eksterne firma med mye erfaring og kompetanse på sikkerhet har vært med i dugnaden. De har sett gjennom løsningen og kommet med innspill. Ekspertgruppen har også vært til stor hjelp i dette arbeidet.

 3. –  En ekspertgruppe har vurdert løsningen, og påpekt en rekke områder som må forbedres. Hva var de viktigste funnene som ble gjort og hvordan ble disse korrigert. Noen som gjenstår? Kommer dere til å kjøre lignende teknisk gjennomgang med andre grupper nå etter at appen er lansert?

–  Ekspertutvalget ser på hele omfanget av løsningen. Eksempler på funn er knyttet til protokollbruk, ytelse og anbefaling om kryptering av data som mellomlagres på telefonen. Det som er ansett som kritisk er løst, mens flere forbedringer vil bli tatt inn i kommende versjoner.
Ekspertgruppens mandat går ut april. Vi har helt klart sett nytten av å ha en ekstern kompetansegruppe som ettergår løsningen, så om -  og i tilfelle hvordan dette kan videreføres, vil bli avklart i løpet av kort tid.  

 4. –  Under lanseringen sa Statsministeren at appen har blitt bedre på grunn av innspill og spørsmål utenfra. Hvor viktig har innspill fra uavhengige aktører, slik som Tekna, vært for å forbedre resultatet?

–  Særlig ekspertgruppens gjennomgang har vært viktig for oss.  Den konstruktive dialogen med ekspertgruppen har bidratt til at løsningen er forbedret fortløpende, og vil forbedres ytterligere gjennom planlagte endringer. Det er blant annet gjort forbedringer i koden som øker ytelse på bakgrunn av ekspertgruppens innspill.

–  Når det gjelder innspill fra informatikk- og sikkerhetsmiljøet ellers, så er både FHI og Simula på generell basis veldig glad for det miljøet gjør. Vi følger med på diskusjonen hele tiden. De arbeider raskt, godt og ansvarlig.

–  Tekna har gjennom åpne spørsmål også bidratt til at vi kan forbedre vår kommunikasjon ut til teknologimiljøer. I et svært intenst arbeid, er det lett at kommunikasjon om vurderinger som gjøres og bakgrunnen for valg som blir tatt, blir skadelidende.

Vil se på Apple- og google-løsning

  5. –  Apple og Google lager sammen en løsning for smitteoppsporing som skal ta hensyn til personvernet. Den benytter primært sporing av nærkontakt med Bluetooth og andre funksjoner i mobiltelefonene. Det blir laget et API som gjør det mulig å anonymisere sporing slik at andre kan bygge apper basert i deres teknologi. Hvordan vurderer dere å bruke denne teknologien når den blir tilgjengelig? Hvorfor venter dere ikke i så fall? Stemmer det at Microsoft har en egen løsning for helsedata der sikkerhet og personvern er ivaretatt i grunndesignet?

–  Initiativet fra Google og Apple er veldig godt, og vi har håpet at noe slikt skal komme. Løsningen de har valgt er forskjellig fra det vi har valgt, og gir mindre mulighet til å endre algoritmer for nærkontakt og å validere nærkontakter. Noe av grunnen til at FHI har valgt sentral lagring og bruk av både GPS og Bluetooth, er for å kunne kompensere noe for utfordringer vi har funnet i teknologien som gjør at sporing blir unøyaktig. Når Apple og Google gjør sine løsninger tilgjengelig, så vil vi vurdere om dette kan brukes til å erstatte eller fungere sammen med dagens løsning. FHI sin løsning samler også data sentralt for å kunne lage anonymisert statistikk som kan brukes til å følge smitteutbredelse og vurdere effekten av smitteverntiltak. Dersom innsamling og analyse av anonyme data viser seg å være så viktig som vi tror for å vurdere smitteverntiltak, er det sannsynlig at vi vil fortsette å beholde innsamling av GPS og Bluetooth-data til sentral lagring også etter at Apple og Google har gjort sine løsninger tilgjengelig for oss.

–  Vi har erfaring med bruk av Microsofts skyprodukter i flere tidligere tjenester i Norge, og tidligere erfaring og ROS-analyser har vært avgjørende for at vi kunne ta dette i bruk så raskt i Smittestopp. Løsningene vi bruker fra Microsoft brukes også mye til helse i utlandet og er blant annet HIPAA-sertifisert for bruk i USA. Vi har primært brukt løsninger hos Microsoft som vi har erfaringer med fra tidligere. Ellers bør spørsmål om hva Microsoft kan tilby rettes mot Microsoft.

Kritikk mot sentral lagring

6.  –  En hoved-kritikk av appen er at den lagrer data sentralt. Hvordan er lagringsproblematikken vurdert og besluttet, med hensyn til lokal versus sentral lagring av data? Hva er ulemper og risiko ved de ulike tekniske valgene det vil si vurderinger av kontaktsporing versus forskning.

–  Selv om vi mener at sentral lagring er trygt så er det et større inngrep i personvernet å lagre dette på et sentralt sted der man kan sammenstille og gjøre analyser på tvers av data som rapporteres fra flere brukere. Et viktig element er at man skal ha tillit til at data som samles inn kun brukes til de formålene som står i forskriften, og at vi har de riktige tekniske løsningene på plass for tilgangsstyring og annen sikring.

–  Vi mener at sentral lagring gir bedre treffsikkerhet i kontaktsporing, raskere varsling og ikke minst mulighet til å vurdere hvorvidt tiltakene i samfunnet fungerer eller ikke, og spisse tiltak mot områder hvor data fra appen viser spesielt høy smitterisiko ved mange nærkontakter.

Basert på frivillighet

 7. –  Statsministeren sier at appen følger GDPR-reglene. Kunne dere utdype hvordan?

–  Det rettslige grunnlaget for behandling av personopplysninger er grundig vurdert opp mot GDPR. Hjemmelen for å behandle de innsamlede opplysningene fra Smittestopp-appen tar utgangspunkt i personvernforordningen, smittevernloven og forskrift om digital smittesporing og epidemikontroll i anledning utbrudd av Covid-19.

–  Det Europeiske Personvernrådet (EDPB) har publisert en erklæring hvor de sier at bruk av persondata for å bekjempe Korona-smitte ikke bryter med EUs databeskyttelsesregelverk. Nasjonal lovgivning for bruk av ikke-anonyme data kan innføres med hjemmel i ePrivacydirektivet.

–  Det er likevel frivillig å installere appen, og bruker må godkjenne personvernerklæringen for å ta appen i bruk.

Servere i Irland

 8. –  Store selskaper og offentlig virksomheter blir daglig utsatt for hacker-angrep både fra andre nasjoner og grupperinger. Noen ganger lykkes de med innbrudd. Hvordan er sikkerhet bygget inn i løsningen. Hva er garantiene for at personlige og nasjonale data ikke kommer på avveie? Er data utelukkende distribuert og lagret på norske servere?

–  Innsamlede data fra brukere av Smittestopp blir lagret i skyløsningen Azure, levert av Microsoft. Sikkerheten i Azure som plattform er vurdert flere ganger av Norsk Helsenett (NHN) som akseptabel, også for sensitive opplysninger.  Det er sterk autentisering for tilgang til løsningen, og sikkerhetsmekanismer flagger automatisk og varsler om mistenkelige aktiviteter/påloggingsforsøk.

–  Den tekniske løsningen er etablert av ressurser fra Simula, Microsoft og NHN, hvor hver komponent, bruk av disse og koblingen mellom dem i løsningen er dokumentert og vurdert ut fra beste praksis. Azure Security Center benyttes for å automatisk skanne etter potensielt sårbare konfigurasjoner. Dette gjøres og følges opp kontinuerlig, siden miljøet er i stadig endring. Dette sørger for liten risiko på det som brukes av komponenter fra skyplattformen.

–  Videre er det etablert 24x7 sikkerhetsovervåkning av tjenesten fra et Security Operations Centre (SOC). Forsøk på innbrudd og tjenestenektangrep vil her fanges opp, og en sikkerhetsorganisasjon står klar til å gjennomføre nødvendige tiltak for å opprettholde sikker og normal drift.

–  Serverne befinner seg fysisk i Irland. Det har vært viktig for oss å ha lagring innenfor EU/EØS regionen med hensyn til GDPR, og valget om Irland er basert på funksjonalitet og kapasitet, nødvendige komponenter var tilgjengelige i Irland og ikke i Norge. Dette er vurdert i ROS arbeidet. Når nødvendig funksjonalitet er på plass i Norge vil vi kunne flytte løsningen fra Irland til Norge.

–  Informasjon om smitte og andre helseopplysninger ligger utelukkende på servere hos FHI i Norge.

Lukket kildekode

 9. –  Det er mange som hevder at dere burde ha frigitt kildekoden, noe dere ikke ønsket på grunn av sikkerhetshensyn. Appen ble hacket etter få timer og synliggjorde kildekoden. Hva sier dette om sikkerheten til systemet? Burde dere i etterpåklokskapen og tilliten til systemet ha frigitt den i utgangspunktet?

–  Det har vært flere grunner til at kildekoden ikke har vært frigitt. Dette inkluderer sikkerhet, og også om åpen kildekode gjør det enklere for regimer uten demokratisk styresett å gjenbruke vår løsning. Det er en samlet vurdering som gjør at kildekoden ikke er åpnet.

–  Det har ikke vært vanlig praksis i helse- og omsorgssektoren at leverandører eller tjenestetilbydere må gjøre sine løsninger tilgjengelige som åpen kildekode. Det finnes mange andre løsninger som nasjonale e-helseløsninger, pasientjournalsystemer og registre der det ikke er åpen kildekode. Det var derfor ikke naturlig for oss at dette ble vurdert så nøye som mange kritikere har ment. Men det finnes grunner både for og mot åpen kildekode, og det er en viktig debatt som går utover Smittestopp, og kanskje burde vurderes mer generelt i offentlige løsninger.

–  Det virker også noen sikkerhetseksperter som ikke er enige i at åpen kildekode er et riktig sikkerhetstiltak, og at det er andre sikkerhetstiltak som for eksempel penetrasjonstester og annen gjennomgang av kildekode og løsning i mer strukturerte former som er bedre løsninger. Slike tiltak har vært del av planen hele tiden.

–  Vi observerer at de som har dekompilert Android-koden og vært åpen om det, ikke har varslet oss om ting vi ikke visste om fra før, men også at vi har fått nyttige innspill på endringer.

Pseudonymisert informasjon

 10. –  Mange er bekymret for personvern. Hvordan er personvern bygget inn i løsningen – beskriv teknisk? For eksempel, er brukerne anonymisert? Kan de identifiseres i etterkant eller kan ID kobles opp mot andre baser for å identifisere? Hvordan gjøres anonymiseringen?

–  Vi har tenkt mye på personvern gjennom hele utviklingsprosessen. Det omfattende arbeidet med ROS-analysen og DPIA (Data Protection Impact Assessment) har vært gode måter å få diskutert personvernutfordringer og nødvendige tiltak. For eksempel er lokasjons- og Bluetooth-informasjon lagret med pseudonymer, og koblingen mellom pseudonymene og telefonnummer er lagret i en separat database med egne tilgangsregler. Et annet eksempel er at smittestatus lagres og behandles et tredje sted utenfor skyløsningen. Ettersom ulike personer har tilgang til de forskjellige lagringskomponentene, er det en kjede av personer som må være enig når data skal behandles og analyseres.

–  Vi jobber fremdeles med noen forbedringer basert på gode innspill fra ekspertgruppen og andre som har sett over løsningen. Formålet om å følge smitteutbredelse og vurdere effekt av smitteverntiltak kan ikke gjøres på direkte personidentifiserende opplysninger, så her behandles kun pseudonymisert informasjon. Denne behandlingen gjøres med skript som ender opp med anonym informasjon som vi gir flere tilgang til å lese. Anonymisering av lokasjonsinformasjon er spesielt vanskelig, og vi vil ikke behandle lokasjonsinformasjon til å følge smitteutbredelse og vurdere effekt av smitteverntiltak før vi er helt sikre på at denne transformeringen ikke kan reverseres for å identifisere enkeltbrukere.

–  Analyseløsningen og dermed anonymiseringsprosessen skal være ferdig før analyser presenteres ut. Dette vil komme i løpet av en ukes tid og i forkant av det vil vi ferdigstille en ROS-analyse for denne delen. Alle detaljer om dette er derfor ikke klare ennå.