Leverandøraudit

Tre afgørelser om software med fejl i drift: spørgsmålene til softwareleverandøren

Tre afgørelser om software med fejl i drift: spørgsmålene til softwareleverandøren

I tre sager fra 2023 og 2024 gik software i drift med en fejl, der gav brugere adgang til andres oplysninger. I alle tre sager var der lavet test, kodegennemgang eller penetrationstest, og i to af dem er det beskrevet i detaljer. Datatilsynets kritik gik på, at testen ikke dækkede det kritiske scenarie. For en kunde er det den vigtigste lære, når softwareleverandørens test før idriftsættelse skal kontrolleres.

Artiklen er skrevet til kunden. Kun én af de tre virksomheder var databehandler for kunder. De to andre var selv dataansvarlige for deres løsning. Sagerne bruges her som eksempler på testkrav, en kunde kan stille sin softwareleverandør.

En platform til ejendomsmæglere

Datatilsynet traf afgørelse 28. september 2023 under j.nr. 2021-431-0163 og udtalte kritik. Virksomheden var databehandler og leverandør af en platform til en række dataansvarlige, og der blev anmeldt 65 brud.

Brugere, der var knyttet til en salgssag, kunne efter login og et tryk på en funktionstast til udviklerværktøjer se langt flere oplysninger i kildekoden, end skærmen viste. Det var bl.a. navne på mulige købere og deres bud, dokumenter og i enkelte tilfælde personnumre. Platformen havde været i brug siden starten af 2019, og fejlen blev rettet 4. november 2021, samme dag den blev kendt. Det var ikke muligt at se, hvem der havde set oplysningerne.

Datatilsynet skrev, at kravet om passende sikkerhed normalt vil indebære, at alle sandsynlige fejlscenarier bør testes og kontrolleres, når der udvikles nye applikationer, der behandler personoplysninger om mange brugere. Personoplysninger og andet, der kan kompromittere sikkerheden, bør generelt ikke stå i kildekoden, og at det kræver udviklerværktøjer at se dem, er ikke en sikkerhedsforanstaltning. Fejlen blev beskrevet som kendt og elementær.

En digital postløsning

Datatilsynet politianmeldte 12. januar 2024 virksomheden bag en digital postløsning og indstillede til bøde, j.nr. 2023-631-0012. Der findes kun en pressemeddelelse og ingen offentlig afgørelsestekst. Virksomheden var selv dataansvarlig for løsningen, som den ejede og drev. Ifølge Datatilsynets side verserer sagen fortsat ved domstolene, da den blev læst 12. november 2026. Der er altså ikke faldet dom.

Løsningen gik i drift 22. marts 2022. En uhensigtsmæssig kodning i den komponent, der stod for autentifikation, gav ved samtidige login brugere adgang til andres digitale post. Før lanceringen var der lavet kodegennemgang, statisk kodeanalyse og test af ydeevne, men fejlen blev ikke opdaget.

Datatilsynet vurderede, at sikkerheden og den indbyggede databeskyttelse ikke var tilstrækkelig, og at der manglede en konsekvensanalyse. Bedre test før idriftsættelsen burde ifølge Datatilsynet have afdækket fejlen, og ved test er det afgørende at have ekstra fokus på de særligt kritiske risikoscenarier.

En loginformidler

Datatilsynet traf afgørelse 23. juni 2023 under j.nr. 2022-431-0171 og udtalte alvorlig kritik af en virksomhed, der formidlede login mellem en national login-løsning og tjenester som netbanker. I en særskilt afgørelse samme dag fik den statslige dataansvarlige for login-løsningen også alvorlig kritik. Formidleren var selvstændig dataansvarlig for sin løsning.

I januar 2022 fik borgere ved login i netbank adgang til andres konti. Årsagen var en samtidighedsfejl i den nationale løsning kombineret med en anbefalet sikkerhedsforanstaltning, som formidleren kun havde gennemført delvist efter en menneskelig fejllæsning af anbefalingen. Formidleren havde dokumenterede test, ekstern kodegennemgang og penetrationstest, men fejlen viste sig først i drift ved stor trafik. Der havde ikke været belastningstest, der omfattede formidlere og tjenesteudbydere.

Datatilsynet skrev, at passende sikkerhed normalt vil indebære korrekt gennemførelse af anbefalede sikkerhedsforanstaltninger, og at risikoen er skærpet, når login giver adgang til netbank.

Det fælles mønster

I alle tre sager var der testet. Fejlen lå i et scenarie, testen ikke dækkede: data, der lå i koden uden at blive vist, samtidige login og belastning på tværs af flere parter. Det er en tolkning, at mønsteret kan bruges som tjekliste, men det følger af Datatilsynets egne formuleringer om sandsynlige fejlscenarier og særligt kritiske risikoscenarier.

Sagerne som auditprogram

Spørgsmålene er en tolkning af afgørelserne. De kan stilles til en softwareleverandør før idriftsættelse og ved større ændringer.

Hvilke fejlscenarier er testet? Bed om testplanen, og se efter, om scenarier, hvor en bruger kan se andres data, er testet særskilt.

Er der test af samtidighed og belastning? Spørg, om løsningen er testet med mange samtidige brugere, og om testen omfatter de andre parter, løsningen afhænger af.

Er anbefalede foranstaltninger gennemført som beskrevet? Har en tredjepart, fx udbyderen af en login-løsning, anbefalet eller krævet bestemte foranstaltninger, så bed om bevis for, at de er gennemført, og for, hvordan det er kontrolleret.

Ligger der data i koden? Spørg, om personoplysninger, adgangskoder eller certifikater kan findes i kildekoden eller i det, browseren modtager, og hvordan det er testet.

Hvad dækker kodegennemgang og penetrationstest? At de er udført, siger ikke, hvad de har dækket. Bed om omfanget.

Kontrol af test hos en softwareleverandør er beskrevet mere generelt i audit af softwarehuset, der udvikler til jer.

Hvad det kræver, og hvad det koster at lade være

Det kræver en aftale, hvor testplan og testresultater er noget, I kan forlange at se, og at nogen hos jer kan læse dem med de kritiske scenarier for øje.

Uden den kontrol nøjes I med at vide, at der er testet. Alle tre sager viser, at det ikke er nok.

Det skal I lade være med

  • At godtage “der er testet” som svar · spørg, hvad der er testet.
  • At regne en penetrationstest for en fuld test · den har et afgrænset omfang.
  • At skrive, at softwaren var utestet · i alle tre sager var der testet.

Det skal auditten kunne vise

  • ☐ En testplan med de kritiske scenarier, især adgang til andres data.
  • ☐ Resultater af test af samtidighed og belastning, også på tværs af parter.
  • ☐ Bevis for gennemførelse af anbefalede foranstaltninger fra tredjepart.
  • ☐ Omfanget af kodegennemgang og penetrationstest.

Kilder

Senest gennemgået: november 2026.

Næste skridt

Bed jeres softwareleverandør om testplanen for næste større release, og find de scenarier, hvor en bruger kan se andres data.

Læs også: Ændringsstyring hos leverandøren · Nedbruddet i en national login-løsning i 2022

→ Kontakt · Tlf. 70 13 63 23 · Leverandøraudit hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Skal en leverandør kontrolleres?

Skriv kort, hvilken leverandør det drejer sig om, og hvad der sætter det i gang. Så vender jeg tilbage. Auditten er uvildig og uafhængig, og Nielco IT har ingen forhandleraftaler.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.