Softwaretest med fokus på sikkerhed

Uanset om software udvikles inhouse eller af en ekstern leverandør, kan der ske fejl. Fokus er normalt på at udvikle den tiltænkte funktionalitet og til tiden. Den tiltænkte funktionalitet er den funktionalitet i software, som ”kunden” ønsker. Et produkt kan dog også indeholde uønsket eller utilsigtet funktionalitet, hvilket der i forbindelse med udvikling af produktet kan være mindre fokus på hos både kunden og leverandøren. Den uønskede funktionalitet kan udgøre et sikkerhedsmæssigt problem.

Uønsket funktionalitet er samtidig unødig funktionalitet og dermed funktionalitet, der generelt ikke anvendes. Funktionalitet, der ikke anvendes, kan derfor indebære, at skjulte sikkerhedsmæssige problemer eksisterer i årevis, fordi den typiske bruger ikke anvender funktionaliteten. Derimod kan personer med onde hensigter søge målrettet efter unødig/uønsket funktionalitet med henblik på misbrug.

Stadig mere komplekse it-systemer og integrationer mellem it-systemer øger sandsynligheden for fejl/sårbarheder, også selv om der er fokus på sikkerhed under udviklingen. Meget software udvikles ved brug af færdige komponenter, som er en del af et ’developer tool’ eller udviklet af tredjepart, hvor man ikke kender disse tredjeparters fokus på sikkerhedsmæssige krav.

Test er derfor en forebyggende foranstaltning, som kan mindske sandsynligheden for fejl i software, fordi fejl/sårbarheder undgås eller findes inden ibrugtagning (idriftsættelse).

Test for fejl/sårbarheder er også relevant i forhold til it-systemer, som allerede er taget i brug. Dels i egne applikationer, men også i styresystemer, tredjepartssoftware og systemkonfigurationer. Test af den type software kan afdække sårbarheder, som har været der siden ibrugtagning, men som først er blevet aktuelle senere, fx fordi hackere sidenhen har vist, at sårbarhederne kan udnyttes.

Dermed er test også en opdagende foranstaltning – under forudsætning af, at fejl/sårbarheder i allerede ibrugtagne it-systemer opdages og rettes hurtigt, og dermed inden der sker ondsindet udnyttelse af fejlen/sårbarheden.

Meget overordnet kan man sige, at "brugertest", "user acceptance test", "integrationstest" og lignende har fokus på at teste softwares forventede funktionalitet, mens sikkerhedstestning har fokus på uønsket funktionalitet. Sikkerhedstestning handler blandt andet om, hvorvidt software kan bringes til at gøre noget uventet, ved at anvende softwaren på en måde man aldrig ville forvente af en ikke-ondsindet bruger, men derimod af en hacker. Selv en ikke-ondsindet bruger kan måske utilsigtet anvende den uønskede funktionalitet og skabe et sikkerhedsbrud. Der kan være overlap mellem de to grupper af tests, idet fx en brugertest kan vise uventet funktionalitet, som også kan føre til sikkerhedsbrud, men sikkerhedstestning er ikke fokusområdet i brugertests, hvorfor de ikke kan stå alene. Test med fokus på sikkerhed skal gå målrettet efter at finde al problematisk funktionalitet, og meget af den slags funktionalitet kan ikke findes af en almindelig bruger, da det kræver særlig viden om programmering, sårbarheder, og udnyttelse af sårbarheder.

Hvilke typer tests, der er relevante, kan være givet af selve projektet, fx er integrationstest givet, hvis der er tale om integrationer mellem it-systemer. En risikovurdering kan ligeledes vise særlige behov for både bestemte typer af tests og behov for særligt indhold i planlagte tests.

Følgende tests er grupperet efter, hvornår de normalt bliver gennemført (såfremt de er fundet relevante at gennemføre). Men det kan foregå helt anderledes afhængigt af organisationen, projekttypen og den anvendte projektstyringsmodel. Nogle tests vil det være naturligt at gennemføre flere steder i projektforløbet.

Allerede tidligt i design- og udviklingsfasen kan følgende overvejes:

• Test/undersøgelse af design med fokus på bevidst og ubevidst misbrug. Det sikres, at designet gør det muligt at efterleve krav i databeskyttelsesreglerne, og at behandlingen også kan stoppe (data kan slettes), når loven kræver det.
• Test/undersøgelse af design med fokus på, om det beskytter tilstrækkeligt imod, at brugerne uforvarende benytter personoplysninger til andre formål end det tiltænkte. Se punkt 72 om “Hovedelementerne i design- og standardindstillinger for formålsbegrænsning” i Det Europæiske Databeskyttelsesråds Retningslinjer 4/2019 om artikel 25, Version 2.0. Dette udføres, fordi data kan komme fra mange kilder, men for brugeren kan det være svært at gennemskue, hvornår oplysninger må anvendes og til hvilke formål. Når data overføres mellem it-systemer, vil det oprindelige formål med indsamlingen af personoplysningerne formentlig ikke fremstå klart for brugeren, hvilket kan medføre, at data anvendes i strid med formålet eller lovhjemmel.
• Kodegennemgang/code review udføres af en anden end den, som har udviklet koden. Der søges efter fejl, hardcodede adgangskoder og evt. baggøre, som en ondsindet udvikler bevidst har inkluderet i koden. Automatiseret kodegennemgang (fx ved hjælp af AI) kan udgøre et supplement, men kan ikke forventes at afsløre alle sikkerhedsmæssige problemer.

Visse tests er målrettet softwarens interaktion med andre it-systemer:

• Integrationstest er en meget almindelig test, som skal sikre, at integration mellem softwaremoduler eller mellem hele it-systemer fungerer. Ved udførsel af denne type test sikres fokus på, om der kan opstå problemer på grund af bl.a.:
  • forskydninger i datasæt mellem systemerne,
  • tidforsinkelser i synkronisering af data,
  • overførsler med for få eller for mange data,
  • langsomme overførsler af data,
  • fejl i filtre i dataoverførsler mellem it-systemer,
  • manglende reaktion fra nogle af it-systemerne på forespørgsler fra andre systemer,
  • og andre hændelser, som kan resultere i sikkerhedsbrud.
    
    Der testes også for, om ændringer i integration kan få indflydelse på gældende lovkrav til behandling af data, eksempelvis ved at data opbevares længere end nødvendigt, mv. Det betyder, at der også er fokus på andet end det, som kan give umiddelbare sikkerhedsbrud – ofte noget, som kan opstå over tid, uden at det bemærkes af brugerne. Hvis en ændring eksempelvis gør, at automatisk sletning af data ophører, kan det med tiden betyde, at der ophobes personoplysninger i strid med regler om dataminimering, sletning, mv.
    
    Sikkerhedsbrud, der opstår i denne sammenhæng, kan være meget alvorlige, fordi de kan påvirke store datasæt og dermed mange personers oplysninger eller adgange. Nogle konkrete eksempler på problemer af denne type er nævnt i foranstaltningen Ændringsstyring. Se også punkt 79 om ”vigtigste design- og standardelementer vedrørende nøjagtighed” i Det Europæiske Databeskyttelsesråds Retningslinjer 4/2019 om artikel 25, Version 2.0.

• Test af log for, om der logges som forventet, og at logdata gemmes længe nok og kan tolkes korrekt med den aktuelle vejledning eller et dertilhørende it-system. Test af log udføres så vidt muligt som en "blindtest": (1) loggens indhold tolkes ud fra vejledningen uden viden om, hvilke handlinger der genererede loggens indhold. (2) Det sammenholdes med de faktisk udførte handlinger, hvor disse handleringer er udført af en anden person end den, der tolker loggen. "Handlinger" i denne forbindelse kan dog også være skabt af maskiner.
• Test af, om loggen indeholder unødige personoplysninger eller autentificeringsfaktorer (adgangskoder, session cookies, mv.), som kan misbruges af personer med legitim adgang til loggen, eller hvis loggen skulle blive kompromitteret af en hacker.
• Test af kryptering. Alt efter behovet kan det fx omfatte test af:
  • Om adgangskoder opbevares envejs-krypteret (hashed).
  • Om overførsler mellem netværk og backup-overførsler sker med krypteret transmission, eller om data krypteres inden overførsel.
  • Om kommunikation over internettet til og fra en web-applikation sker med tilstrækkelig kryptering (se CFCS-skema over krypteringsmuligheder i vejledningen om Sikker brug af Transport Layer Security), og at det sikres, at denne ikke kan fravælges eller nedgraderes af brugeren. Nedgradering kan anvendes af hackere i ’Man in the Middle’-angreb for at gøre det nemmere at bryde krypteringen. ”Fravalg af kryptering” handler om, hvorvidt man kan fjerne ”s” i ”https”.
  • Om krypterede data (i fx backup) kan dekrypteres.

Disse tests kan overvejes, så snart det er muligt at teste software i et it-miljø, der ligner det endelige driftsmiljø:

• Belastningstest med fokus på, om høj belastning kan gøre et system utilgængeligt, hvilket i nogle tilfælde kan udgøre en risiko for de registrerede, fx når en læge ikke kan tilgå patientjournaler. Overbelastning kan også i særlige situationer få it-systemer til at agere uventet og derved kompromittere personoplysningers fortrolighed eller integritet.
• Test for 'hardening'. Her er fokus på operativsystemer og andet it, som indgår i et samspil med den udviklede/indkøbte software. Servere, pc'er, netværksudstyr, mv. tjekkes for, om de har været igennem en 'hardening', som lukker for al unødig funktionalitet (services, porte, mv.), som måske ellers kunne misbruges. Se mere om dette i State of the art in it Security udgivet af ENISA og TeleTrusT.
• Test for læk af oplysninger, hvor det kontrolleres om brugerinput – og ikke-ondsindet input – kan give brugeren indirekte adgang til oplysninger, som kan misbruges.
  
  Det kan fx være en applikation, som reagerer forskelligt afhængigt af input, og som derved afslører, om input er validt eller ej, hvorved brugeren kan prøve sig frem til validt input. Det kan være meget konkrete fejlmeddelelser, som afslører, hvordan applikationen fungerer. Ved AI (kunstig intelligens) kan det handle om brugerens mulighed for at afgive mange input med små variationer og derigennem afsløre bagvedliggende algoritmer eller datagrundlag – herunder personoplysninger.
• Test af, om opbevaring kan begrænses som forventet, jf. den opbevaringsbegrænsning, som skal gælde i it-systemet. Det kan komme af lovkrav, interne krav fastsat ud fra rammerne i fx databeskyttelsesforordningen eller ud fra et generelt behov for at minimere konsekvenser ved informationssikkerhedsbrud ved, at man minimerer de data, et potentielt brud ville kunne berøre. Det kan fx testes, om det er muligt at sætte og ændre slettetidspunkt/slettekriterie og, om personoplysninger faktisk slettes eller anonymiseres i henhold til tidspunktet/kriteriet. Se punkt 82 om “hovedelementerne i design- og standardindstillinger for opbevaringsbegrænsning” i Det Europæiske Databeskyttelsesråds Retningslinjer 4/2019 om artikel 25, Version 2.0.
  
  Behovet for sletning/anonymisering kan ligge mange år ude i fremtiden, men udfordringer på dette punkt bør være afdækket og håndteret, inden den pågældende software erhverves og tages i brug. Dette omfatter også sletning af logdata.

Umiddelbart inden idriftsættelse er det relevant at teste væsentlige forretningsmæssige, driftsmæssige og sikkerhedsmæssige krav til softwaren, som er en forudsætning for, at produktet lever op til forventningerne:

• Brugerfejlstest ift. alle tænkelige typer fejl fra brugernes side, såvel klumrefejl som bevidst misbrug og anvendelse af softwaren til et andet formål end det tiltænkte/tilladte. Det inkluderer test af, om brugerne uden videre kan tilgå oplysninger, de ikke er autoriserede til, og om de kan ændre/slette oplysninger, de kun burde kunne læse. Dette kan udføres som en del af den normale brugertest.
  
  Samme type test udføres også for ikke-personlige brugere, såsom RPA-brugere (Robotic Process Automation). Dette er vigtigt, fordi fejl ved brug af RPA ofte reproduceres i stort omfang og med ringere mulighed for at opdage fejl, da processen netop er automatiseret.
• Test for korrekt sessionsstyring/rettighedsstyring. Dette kan bl.a. omfatte:
  • Test af, om der er de forventede adgangskontrolkrav (krav til login).
  • Samtidighedsproblem, hvor to samtidige login resulterer i, at brugere får sammenblandet deres sessioner og dermed adgange.
  • Overtagelse af forudgående brugers rettigheder ved anvendelse af samme computer til login.
  • Test af, om man efter login kan tilgå data, der tilhører en anden bruger, fx ved at ændre i URL, session cookie, ’client side code’, eller ved at indtaste en anden persons personnummer (CPR-nr.)
    
    Det er en type fejl, som bør opdages under udvikling, men sikkerhedsbrud forårsaget af denne type fejl er alligevel ofte forekommende.
    
    Testen udføres på forhold, der ligner de endelige driftsforhold, idet fraværet af sådanne forhold i sig selv kan gøre, at et problem med sessionsstyring ikke opdages ved test.
• Test af, om alle standard adgangskoder i alle dele af it-systemet er fjernet eller udskiftet. Se mere om dette i State of the art in it Security udgivet af ENISA og TeleTrusT.
• Test af trådløse netværk. Det omfatter bl.a., om standardadgangskoder er udskiftet, og at muligheden for at administrere netværkene er stærkt begrænset. Se mere i State of the art in it Security udgivet af ENISA og TeleTrusT.
• Test for sårbarheder, som kan udnyttes af mere teknisk kyndige brugere eller af ondsindet software (malware). Testen omfatter (alt efter, hvad der er relevant) udviklet software, operativsystemer, tredjepartssoftware samt netværksudstyr, bl.a. routere og firewalls.
  
  Testen erstatter ikke sikkerhedsmæssig opdatering (patchning), idet især nul-dags-sårbarheder skal lukkes hurtigst muligt, og en patch kan være tilgængelig før en opdateret sårbarhedsskanner vil kunne identificere samme sårbarhed.
• Penetreringstest, hvor der udnyttes konkrete eller ofte forekommende sårbarheder. Denne type test kan belaste og endda ødelægge it-systemer og netværk, så de bliver utilgængelige for de retmæssige brugere, og derfor skal disse risici afspejles i planlægningen og aftaler om, hvad der må blive berørt af testen. Det sikres evt., at der er en nylig backup, inden testen gennemføres, og at anvendelse af it-systemerne standses, så der ikke sker ændringer i data i testperioden.
  
  Det er vigtigt at varsle relevant personale om testkørslen for at undgå unødig bekymring pga. alarmer, der viser reaktioner på tegn på indbrud i it-systemerne.
  
  Resultatet af en penetreringstest gennemgås af tester og udvikler for at identificere falske positive og potentielle problemer, der ikke aktuelt udgør et problem i den eksisterende anvendelse af it-systemet. Dette kan kræve efterfølgende manuel test af noget, som et automatisk penetreringstestværktøj har detekteret.

Planlægning, prioritering og dokumentation af tests:

Overvej at indføre relevante tests i projektplanen.  Projektplanen tilføjes i givet fald oplysninger om, hvordan og hvornår det kontrolleres af den dataansvarlige, om testen er udført og dokumenteret og relevante fejl udbedret.

Medtag evt. et særskilt punkt i projektplanen, som beskriver opgaven med at nedlukke test-systemet (præ-produktions-miljøer og lignende), når der overgås til produktion. Dette gøres dels for at undgå konflikter i fx systemintegrationer, som er testet mellem test-systemet og produktionssystemer, men også for at nedlukke et system, der ikke vedligeholdes sikkerhedsmæssigt og dermed på længere sigt kan komme til at udgøre en sikkerhedsrisiko.

Overvej hvilke tests der også bør udføres jævnligt efter tidspunktet for ibrugtagning af nyt it-system, fx for at finde sårbarheder, som er opdaget lang tid efter ibrugtagning. Dermed kan test for sårbarheder også fremgå af en kontrakt med en it-leverandør/databehandler, så det er denne, der skal holde øje med kendte sårbarheder (CVE’ere, Common Vulnerabilities and Exposures).

Alle tests og deres resultater bør dokumenteres for at holde styr på udbedring af fejl og begrundelser for ikke at udbedre bestemte fejl. Dokumentationen bør gemmes for at kunne identificere mangler ved testen, hvis der senere opstår brud på persondatasikkerheden, og dette brud skyldes en fejl, som burde være afsløret af testen. En del af dokumentationen kan være i form af logning, og denne log kan også være afgørende for at forstå fejlene.

Leverandørens prioritering af relevant sikkerhedsmæssig testning kan eksempelvis sikres gennem aftalevilkår, der stiller specifikke krav til typer af tests med fokus på it-sikkerhed og uønsket funktionalitet. Formuler kravene, så det kan kontrolleres, om de efterleves. Et krav om ”et sikkert login” er fx ikke konkret nok, men kan formuleres mere specifikt og målbart, eksempelvis at login ikke må kunne omgås ved "brute-force-angreb" (se Center For Cybersikkerheds ordforklaringer), eller at der skal være sikret imod ”injection” (se forklaring af begrebet i OWASP’s top ti).

Sørg for at der i projektplanlægningsfasen tages stilling til følgende for hver type test:

1. Om krav til test med fokus på sikkerhed skal indgå i kontrakt, databehandleraftale eller udbudsbeskrivelse.
2. I hvor høj grad test skal forberedes parallelt med udvikling af software for at sikre, at al funktionalitet kan nå at blive testet behørigt, også funktionalitet, som er skjult for brugere, eller som sjældent vil blive anvendt.
3. Hvem der er ansvarlig for, at alle sandsynlige fejlscenarier identificeres.
4. Om krav til test er defineret konkret nok til, at det kan konkrolleres, om krav er efterlevet.
5. Hvilke tests, der skal udføres af leverandør/databehandler, og hvilke af dataansvarlig selv (der må gerne være overlap).
6. Om der er tests, som bedst udføres af en tredjepart, fx fordi det kræver særlig viden.
7. Hvordan test og testresultat dokumenteres, uanset hvem der udfører testen.
8. Om test forudsætter anvendelse af personoplysninger. Læs mere i denne vejledning om personoplysninger som testdata. 
9. Hvordan adgangsrettigheder til testmiljøet styres. Læs mere om styring af adgangsrettigheder i denne vejledning.
10. Hvordan og hvornår der skal slettes testdata, som indeholder personoplysninger eller andre beskyttelsesværdige data.

Særligt om teknologi som AI, RPA, ML:

Med teknologier som Artificial Intelligence (AI), Robotic Process Automation (RPA), Machine Learning (ML) kan det være særligt vanskeligt at sikre en fyldestgørende test. Hvis det ikke kan vurderes, om et it-system, der behandler personoplysninger, bliver testet fyldestgørende, kan det være tegn på manglende transparens i behandlingen, hvilket også kan være et problem ift. relevante retlige rammer for behandlingens lovlighed. Manglende evne til at definere en test kan dermed være et symptom på et mere fundamentalt problem. Det er en af grundene til, at det kan være en fordel at begynde at definere test, før en it-løsning udvikles, og sikre, at de mest væsentlige brugsscenarier og væsentligste risici testes på relevant vis.

Teknologierne udelukker ikke, at der kan testes ordentligt. Regelbaseret AI kan fx være konkret nok til at blive testet fyldestgørende, mens anden AI er mere uforudsigelig.

Der kan udføres test, som handler mere om at sikre, at forvaltningsretlige eller dataetiske hensyn ikke kompromitteres, men disse er ikke nærmere beskrevet her. Det kan fx handle om test af automatiserede behandlinger og behandlinger via AI, bl.a. med fokus på at undgå diskriminerende behandling af de registrerede. Se punkt 79 om ”vigtigste design- og standardelementer vedrørende nøjagtighed” i Det Europæiske Databeskyttelsesråds Retningslinjer 4/2019 om artikel 25, Version 2.0.

Fornøden testning er med til at sikre et passende sikkerhedsniveau, når der ændres på it-miljøet, så det er en integreret del af den dataansvarliges efterlevelse af princippet om tilstrækkelig sikkerhed efter forordningens artikel 5, stk. 1, litra f). Dokumentation af testningen er med til at opfylde artikel 5, stk. 2, som handler om at kunne påvise, at stk. 1 overholdes (»princippet om ansvarlighed«).

Kravene til tilstrækkelig behandlingssikkerhed er derudover reguleret i forordningens artikel 32. I bestemmelsens stk. 1, litra b omtales foranstaltninger, der relaterer sig til evnen til at sikre vedvarende fortrolighed, integritet, tilgængelighed og robusthed af behandlingssystemer og -tjenester – altså en sikring af vedvarende passende sikkerhed. Test af ny og tilrettet software er en foranstaltning, som er uundværlig til sikring af, at ibrugtagningen af sådan software ikke reducerer sikkerhedsniveauet for organisationens behandlinger af personoplysninger.

Der kan være særlige forhold, hvor man kan regne med, at en softwareleverandør har tilstrækkeligt fokus på sikkerhed, men det er ofte sådan, at leverandørens primære fokus er på deadline og hurtig RoI (Return of Investment), så kunden får det, kunden har bedt om – hverken mere eller mindre. Derfor er det normalt nødvendigt for den dataansvarlige at tage stilling til og stille krav om relevant testning med fokus på sikkerhed for at sikre, at forordningens artikel 32 efterleves.

Test ift. 'hardening' kan evt. karakteriseres som en del af efterlevelsen af forordningens artikel 25, stk. 2, ang. databeskyttelse gennem standardindstillinger, fordi 'hardening' især handler om at opsætte it-systemerne på en måde, der giver den mindst mulige angrebsflade for ondsindede personer og malware. 

Ved anmeldelse af brud på persondatasikkerheden kan dokumentation af udførte tests indgå som en del af dokumentationen for, hvad man som dataansvarlig/databehandler har gjort for at forsøge at undgå brud og for at efterleve artikel 32 generelt.

Ved udvikling af software hos en ekstern leverandør, skal man forstå leverandørens rolle og ansvar i forhold til softwareleverancen, uanset om leverandøren er din databehandler i anden sammenhæng.

At en databehandler også skal efterleve artikel 32, fritager ikke den datatansvarlige for ansvar og er heller ikke ensbetydende med, at risikovurderingen er den samme for den dataansvarlige som for databehandleren i relation til anvendelsen af softwaren. Hvis en leverandør udvikler software, behandler leverandøren ikke nødvendigvis personoplysninger på andres vegne. Hvis personoplysninger indgår i en test af softwaren, kan leverandøren i nogle tilfælde være selvstændig dataansvarlig for behandlingen af disse oplysninger. En databehandler er ifølge databeskyttelsesforordningens artikel 4, nr. 8 en fysisk eller juridisk person, en offentlig myndighed, en institution eller et andet organ, der behandler personoplysninger på den dataansvarliges vegne. Det er muligt, at softwaren udvikles og driftes af en leverandør, som også behandler personoplysninger på vegne af den dataansvarlige, og som dermed er databehandler i en anden forbindelse, men hvor leverandøren i forhold til selve leverancen af software ikke er databehandler. Den dataansvarlige kan derfor ikke forlade sig på, at der i en databehandleraftale med leverandøren er stillet krav om behandlingssikkerhed, da databehandleraftalen ikke nødvendigvis vedrører udvikling af den pågældende software, men ofte (kun) vedrører drift eller ’hosting’.