Får historiens høyeste GDPR-bot etter gigantblemme: – Vi anser dette som svært alvorlig

[Martin Braathen Røise]

<br data-mce-bogus="1">

Får historiens høyeste GDPR-bot etter gigantblemme: – Vi anser dette som svært alvorlig

[tommyb]

Får historiens høyeste GDPR-bot etter gigantblemme: – Vi anser dette som svært alvorlig

 

 

Trenger... mer... konkrete... opplysninger. Føler vi (utviklere generelt) burde kunne ta læring av denne saken, men trenger mer konkret informasjon om hva som trigger denne reaksjonen. 

 

Feilretting på første dag høres ut som de (kunden) har gjort det de kunne i ettertid. Og forsåvidt som leverandøren tok dem alvorlig også. Det rettferdiggjør naturligvis ikke hva som helst fra utviklings- eller utrullingsfasene, men når sikkerhetsbruddet først har skjedd, høres det ut som det som kunne gjøres ble gjort.

 

Siterer litt fra artikkelen og litt fra kilden: 

 

 

 

Manglende sikkerhet rundt innloggingen i appen har gjort det mulig for uvedkommende å få tilgang til å se og endre personopplysninger til mer enn 63 000 barn i grunnskolen i Oslo.

 

Snakker vi om manipulering av URI for å se andre opplysninger enn de man selv har rettighet til å se? 

 

 

Slik Datatilsynet forstår det, kan ikke sårbarhetene utnyttes ved vanlig bruk av appen Skolemelding, men ved at man bruker et verktøy for å kunne se og manipulere trafikk av data som kommuniseres. Slike verktøy er lett tilgjengelig for nedlasting fra internett. Sårbarhetene som ble oppdaget er autentiseringsproblemer og et manglende skille mellom brukere som gjorde at man kunne få tilgang til andres meldinger. Det var også mulig å høste personopplysninger og knytte enkeltpersoner til meldinger.

 

Det høres ut som en kombinasjon av HTTP og manglende rettighetssjekk på IDen på funksjonsnivå, som man utnytter med å manipulere URI og/eller post-data.

 

 

Mangelfull sikkerhetstesting før lanseringen av appen førte til at den ble lansert med sårbarheter som er godt kjent i sikkerhetsmiljøer verden over.

Kjente sårbarheter? Eller kjente typer sårbarheter, som den jeg nevner ovenfor? Det virker som det siste. 

 

 

Kommunen har ikke vært bevisst sitt ansvar og har lansert en skolemeldingsapp med en uakseptabel sårbarhet uten å gjennomføre egnede tiltak for å lukke sårbarhetene. De har også hatt mangelfull kontroll med leverandøren når det gjelder resultater av sikkerhetstestingen.

 

Det er ikke økonomisk trivielt for en kunde å få full oversikt og forståelse over hvilke kontaktpunkter i en app som har, eventuelt ikke har, en fungerende rettighetssjekk. Jeg tror ikke at det er veldig mange kommuner som er i stand til å forstå og gjennomføre analyse om det mangler rettighetssjekk på ID-nivå i en app der man ikke har tilgang til URIene. Og for bl.a. alle andre kommuner, ville det vært nyttig om det ble navngitt eksempler på egnede tiltak. 

 

Jeg lurer på om ikke noe av ansvaret som legges på kommunen faktisk med fordel kunne legges et hakk lengre opp. For at alle mulige leverandører i et prisbasert anbud skal tilfredsstille en konkret type sikkerhetssjekk som et krav, bør nok denne type krav spesifiseres i regelverk og anbudsmaler sentralt. 

 

 

Og så til Datatilsynets personvernsvurderinger: 

 

 

Det er også mulig å registrere sensitive personopplysninger i fritekstfeltet.

Det ligger i et fritekstfelts natur, og kravet her er nok til at det ikke skal være mulig å sende sensitive opplysninger. Men det tar effektivt bort muligheten til å formulere en personlig beskjed. Og ville nedtrekksliste gjort kommunikasjon til skolen ikke-sensitiv? Allerede "Egenmelding" eller "Fravær" er strengt tatt personopplysninger...

 

 

Et av bruksområdene til appen er at foresatte skal sende meldinger om sine barn eller gi beskjed om fravær ved bruk av fritekstfelt. Det legger til rette for å kommunisere sensitive personopplysninger, slik som helseopplysninger, om barna. Det finnes ingen tekniske tiltak for å forhindre at det skjer, og det informeres heller ikke i appen om at man ikke skal kommunisere slike opplysninger. Hadde man tatt hensyn til innebygd personvern, ville det ikke vært et fritekstfelt, men for eksempel en nedtrekksliste eller avkrysningsbokser.

 

Som forelder, kunne aldri en nedtrekksliste eller avkrysningsliste formidle de konkrete beskjeder jeg trenger å sende til skolen. Hvor mye av beskjeden "Pass spesielt godt på at han ikke overanstrenger seg i dag før reisen til Radiumhospitalet i morgen", skal det være mulig å formidle til klasseforstanderen? Kanskje ikke noe i det hele tatt, etter streng tolkning. Men da begynner spørsmålet å bli hvilke oppgaver en slik app er i stand til å løse.

 

Jeg rettferdiggjør ikke leverandøren, og jeg rettferdiggjør ikke kommunen, men en kommunikasjonsform mellom skole og hjem må nødvendigvis inneholde fritekst, det må nødvendigvis være mulig å fortelle skolen viktige helseopplysninger, og det burde være et statlig ansvar, ikke et kommunalt, å få på plass et moderne kommunikasjonsverktøy som faktisk er godt nok mellom skole og hjem. Dette er en så sårbar prosess at den må gjøres svært ordentlig én gang, og ikke på restbudsjett i hver en liten kommune i Norge. 

 

Og ellers er kanskje ikke innlegget mitt veldig relevant for den konkrete GDPR-dommen her, men mer en bekymring over hvor fritt kommuner og skoler står til å forsøke løse dette hver for seg, når det faktisk er ganske sensitive opplysninger de garantert ikke er kvalifisert til å beskytte. Eller strengt tatt ikke har lov å motta. 

Endret 3. mai 2019 av tommyb

[Ivarko]

Trenger... mer... konkrete... opplysninger. Føler vi (utviklere generelt) burde kunne ta læring av denne saken, men trenger mer konkret informasjon om hva som trigger denne reaksjonen.

Her finn du brevet Datatilsynet har sendt til Oslo kommune: https://www.datatilsynet.no/contentassets/f7246f38ff394d32bef6895bc65a4b4f/varsel-om-gebyr---oslo-kommune.pdf

 

I brevet står det meir detaljert kva feila var og korleis dei vert utnytta. Dette finn du under punkt 3.4 i brevet på side 5-6. Det er elles noko interessant informasjon om tryggingsvurderingane som blei gjort i punkt 3.3.

 

Datatilsynet har skrive ein artikkel om saka her: Varsel om gebyr til Oslo kommune

[Ivarko]

Eg innser at mange ikkje kjem til å lese brevet frå Datatilsynet, og sjølv dei som opnar det vil finne at det inneheld ein del informasjon om saka som kanskje ikkje er interessant. Eg legg ved nokre utdrag med mine uthevingar frå brevet, som de kan finne her: https://www.datatilsynet.no/contentassets/f7246f38ff394d32bef6895bc65a4b4f/varsel-om-gebyr---oslo-kommune.pdf

 

På spørsmål fra Datatilsynet om det finnes DPIA og risikovurdering for løsningen, svarer

kommunen at det ikke ble gjennomført en formell DPIA, men at det ble gjennomført en

risikovurdering. En av ni identifiserte sårbarheter/trusler ble vurdert som uakseptabel.

Sårbarheten var at det registreres sensitive data i løsningen. Det ble foreslått noen tiltak for å

håndtere sårbarheten. Det ene var å gi informasjon på skolenes og kommunens nettsider om at

det ikke må skrives sensitive opplysninger i fritekstfeltet, som er gjennomført. Det andre var å

legge inn informasjon i appen i neste oppdatering, som var planlagt til 13. desember 2018. Et

siste tiltak var å lage maler for registrering av ulike typer fravær. Dette tiltaket er planlagt som

en del av Videreutviklingen av løsningen i 2019. Avslutningsvis skriver kommunen at

Utdanningsetaten vil vurdere behovet for fritekstfelt for å melde fravær.

 

 

[…]

 

 

3.4 Sårbarhetene i systemet

Slik vi forstår det kan ikke sårbarhetene utnyttes ved vanlig bruk av appen Skolemelding, men

ved at man bruker et verktøy slik som en web proxy for å kunne se og manipulere trafikk av

data som kommuniseres gjennom systemet. Slike verktøy er lett tilgengelig for nedlasting fra

internett. Det krever en viss teknisk kompetanse for å kunne bruke dem, men det er også lett

tilgjengelig informasjon på internett om hvordan man kan bruke dem.

 

3 .4. 1 Autentiseringsnroblemer

Vi beskriver her prosessen for en foresatt-bruker av Skolemelding.

 

Når en bruker av appen for foresatte skal logge inn, blir brukeren som forventet tatt gjennom

innloggingsprosessen i ID-porten. Det er etter dette at problemer oppstod. Det var en feil i

logikken til autentiseringsserveren (kalt midporten), som brukes av systemet.

Innloggingsløsningen ga kun ut fødselsnummer (som er foresattes bruker ID) som et

tilgangstoken² etter innlogging. Det var derfor her mulig å lage sitt eget tilgangstoken uten å

gå via innloggingsløsningen så lenge det ble benyttet et fødselsnummer som er registrert som

en foresatt.

 

Fødselsnummer er bygget opp på en veldefinert måte og er begrenset til 11 millioner. Dette

gjør det lett for en angriper å generere alle mulige fødselsnummer, for så å prøve de ut mot

løsningen. Utvalget av fødselsnummer man trenger å teste kan også reduseres basert på

eksempelvis fødselsår når man vet at man skal prøve ut fødselsnummer som kan tilhøre

foresatte til barn i grunnskolen. Basert på en ytterligere svakhet i systemet er det ikke

nødvendig å ha mer enn en gyldig bruker for å få tilgang til andres meldinger.

 

 

3.4.2 Manglende skille mellom brukere giør at man kan få tilgang til andres meldinger

 

Når en bruker er autentisert kan vedkommende lese meldinger som ligger lagret på serveren.

Dette gjøres i bakgrunnen av appen ved å spesifisere blant annet en ID for ønsket melding.

ID-en er et sekvensielt generert heltall som fungerer som en unik identifikator for meldingen.

Systemet mangler en verifikasjon på hvem en melding (ID) tilhører når den hentes ut. Dette

fører til at en autentisert bruker kan hente ut hvilken som helst melding i systemet ved å

spesifisere en gyldig meldings-ID, uavhengig av hvem den tilhører. Gjetting av gyldige ID-er

vil ikke være vanskelig siden de som tidligere nevnt består av sekvensielle heltall.

 

3.4.3 Mulighet for høsting av opplysninger og knvtte person til meldinger

Det er også mulighet til å hente ut informasjon om brukeren man er innlogget som og elevene

som er tilknyttet denne brukeren. Dette inkluderer fullt navn, brukernavn, e-post,

fødselsnummer og telefonnummer. Dette gjøres ved å kjøre et kall til serveren, som returnerer

LDAP³ data. Dette resulterer i at selv om noen i utgangspunktet tester med tilfeldige

fødselsnummer så vil de videre ha mulighet til å knytte fødselsnummeret til person og familie

på en lett måte.

 

 

[…]

 

 

Datatilsynet vurderer at pålegg 1) er nødvendig for å unngå at særlige kategorier av

personopplysninger om barn kommuniseres i appen. Oslo kommune skriver på sin nettside at

Skolemelding ikke skal benyttes til sensitive opplysninger. En av bruksområdene som trekkes

frem er melding om sykefravær. Melding om fravær gjøres i et fritekstfelt i appen. Det finnes

ingen advarsel eller informasjon i selve appen om at man ikke skal skrive inn sensitive

personopplysninger i meldinger. Basert på dette fremstår det som sannsynlig at det vil legges

sensitive opplysninger inn i løsningen, og vi kan med stor sannsynlighet anta at man ikke har

tatt utgangspunkt i innebygd personvern (jf. forordningen artikkel 25) når man har laget

løsningen.

[Bing123]

Tror de skal analysere resten av norske kommuners utvalgte apps som håndterer persondata.

 

Frykter Oslos er en av de bedre "skoleappene", for her er det mye ræl!

[tommyb]

Mange kommuner som skal bidra til statskassa, da.

[Xantippe]

Hvem er den famøse utviklreen?

Det kan være godt å vite slik at andre kan holde seg langt borte fra dem og unngå slike blemmer.

[oppat]

Dette er utrolig spennende. Nå får ledelsen gjennom GDPR et mye mer konkret ansvar for hva de må prioritere og se på mhp personvern.

 

Jeg ser meget lyst på hva GDPR kan utrette på ledelsesnivå framover. 2 millioner er ingenting, men det er utrolig viktig mhp at ledelsen vanligvis kan skyve ansvar over på andre, men her er det mye vanskeligere.

[oppat]

 

Jeg lurer på om ikke noe av ansvaret som legges på kommunen faktisk med fordel kunne legges et hakk lengre opp. For at alle mulige leverandører i et prisbasert anbud skal tilfredsstille en konkret type sikkerhetssjekk som et krav, bør nok denne type krav spesifiseres i regelverk og anbudsmaler sentralt. 

 

Nei ansvaret ligger akkurat der det skal. Kommunen burde ha brukt ET ANNET firma som "tok ansvar" for at deres underleverandør ikke ga dem problemer.  Det kan godt spesifiseres i anbudsmaler, men jeg er 95% sikker på at det allerede finnes.

 

Anbudsmaler og regelverk er byråkrati, og byråkrati er pr. definisjon generelt og ikke spesifikt for en gitt situasjon.

 

 

Endret 4. mai 2019 av oppat

[Salazar]

Mange slike utfordringer i kommunene. Her er en større utfordring: de fleste kommunene bruker en felles meldingsformidler som heter SvarUt. Hvor mange kommuner har fått med seg at når de sender et dokument med sensitivt innhold til en innbygger, så sender de fleste kommuner en link til dokumentet, og at selve dokumentet da blir lagret forever i SvarUt? At SvarUt nå lagrer millioner av dokumenter? Kommunene burde tatt det opp med KS (Kommunenes sentralforbund), men hvem leverer SvarUt? KS.

[IBalic]

Hva har dette med GDPR å gjøre?

[oppat]

Hva har dette med GDPR å gjøre?

 

Hvilket innlegg svarer du på?

[IBalic]

Hvilket innlegg svarer du på?

 

Jeg svarer på artikkelen. 

 

GDPR er nevnt i overskriften, men hverken i uttalelsen til Oslo kommune, i selve artikkelen, eller i brevet som er referert til over her, er GDPR nevnt. Jeg bare synes artikkelen er mangelfull da det ikke er åpenbart at dette har noe som helst med GDPR å gjøre. 

[Ivarko]

Hvem er den famøse utviklreen?

Det kan være godt å vite slik at andre kan holde seg langt borte fra dem og unngå slike blemmer.

CGI Norge AS er leverandør av appen Skolemelding.

 

Hva har dette med GDPR å gjøre?

Oslo kommune har ifølge Datatilsynet brote reglane om personopplysningstryggleik i personvernforordninga GDPR.

[NULL]

CGI Norge AS er leverandør av appen Skolemelding. 

 

Som ironisk nok også tilbyr konsulenttjenester/rådgivning knyttet til GDPR...

[tommyb]

Kommunen burde ha brukt ET ANNET firma som "tok ansvar" for at deres underleverandør ikke ga dem problemer.  Det kan godt spesifiseres i anbudsmaler, men jeg er 95% sikker på at det allerede finnes.

 

Anbudsmaler og regelverk er byråkrati, og byråkrati er pr. definisjon generelt og ikke spesifikt for en gitt situasjon.

 

 

 

Du mener i ettertid at kommunen burde ha visst. Med mindre du kan overføre den kunnskapen til kommunene før de velger firma, så leverer du rein etterpåklokskap og ganske generell sådan. 

 

Kommunen kan ikke og har faktisk ikke lov til å gjette på om et firma ikke kommer til å gjøre en god nok jobb. Og om ikke Oslo klarer det, klarer i alle fall ikke småkommunene det. Det må formaliseres. Formaliene må være konkrete og nøyaktige, men ikke overveldende. Hvis du har sett personvernloven i bokform, innser du at den ikke gjør jobben når man trenger innkjøpskompetanse. Kommunene trenger annen støtte, for eksempel som innkjøpsveiledninger. Og ja, det finnes allerede mye regelverk. Hvorvidt dette er godt og relevant, er jo denne saken i seg selv Oslo kommunes svar på. 

 

Det første skrittet på å gjøre kommunene bedre til innkjøp, er å gi dem et regelverk de kan forventes å ha kompetanse til å følge. 

Endret 4. mai 2019 av tommyb

[tommyb]

Jeg svarer på artikkelen. 

 

GDPR er nevnt i overskriften, men hverken i uttalelsen til Oslo kommune, i selve artikkelen, eller i brevet som er referert til over her, er GDPR nevnt. Jeg bare synes artikkelen er mangelfull da det ikke er åpenbart at dette har noe som helst med GDPR å gjøre. 

 

Jeg er enig i at artikkelen ikke knytter det til GDPR direkte. Kanskje GDPR gir Datatilsynet ekstra mulighet (og motivasjon) til å gjøre kritikk om til bøter? 

[-Night-]

Ikke noe problem, Oslo kommune setter bare opp enda en bomring og foresetter som før.

 

#andresinepenger

Endret 5. mai 2019 av -Night-

[Anders Jensen]

"men vi hadde da brannmur"? Ser for meg div topptunge møter..

[Pop]

Selvsagt er dette knyttet til GDPR. Hvilke andre lover enn Personopplysningsloven med forordning dekker brudd på personvern (og i stor grad informasjonssikkerhet)? Og GDPR ble hvilken lov i Norge?

 

Selvsagt mener Oslo kommune at de rettet opp i punktene når de ble varslet om det. Skal det frita dem fra ansvaret og straffeskyld?

 

Hele målet med GDPR/Personopplysningsloven er jo at man skal følge den. FØR man tar i bruk en tjeneste. Om man ikke har kompetansen til å tilstrekkelig teste tjenesten teknisk og juridisk kontrollere samsvaret i den med gjeldende lovverk, må man sette jobben til en part som er kompetent nok. FØR man tar den i bruk. Det er jo ikke andre premisser for en lov fordi det er snakk om opplysninger, eller fordi det er en kommune, eller fordi det er barns opplysninger, eller fordi det er data, eller annet irrelevant svada.