Årsagen bag fundet: hvad kunden vil vide ud over rettelsen

Når et alvorligt fund er rettet og efterprøvet, kommer kundens næste spørgsmål: hvorfor opstod fejlen, og hvad forhindrer, at den kommer igen? En NIS2-kunde kan ikke nøjes med at vide, at et hul er lukket, hvis den samme måde at arbejde på kan skabe nye huller i næste udgivelse. Svaret er en kort beskrivelse af årsagen bag fundet og af det, I har ændret ud over selve rettelsen.

Grundlaget findes i bilaget til gennemførelsesforordning (EU) 2024/2690. Punkt 6.5.2, litra c, kræver for hver konstatering en vurdering af kritisk betydning og af afbødende foranstaltninger. Ordet årsag står ikke i det punkt, men kunden skal kunne vurdere, om foranstaltningerne rækker ud over det enkelte fund. Teksten er ikke juridisk rådgivning.

Symptom og årsag

Et testfund beskriver et symptom: en funktion, der viser data, den ikke burde, eller en server, der kører en gammel udgave. Årsagen ligger et andet sted. Den kan være et designvalg, en manglende gennemgang før udgivelse, en standardopsætning, som ingen har set på, eller en opgave, som ingen har ansvaret for.

Kunden er interesseret i årsagen, fordi den siger noget om resten af leverancen. Et fund i én funktion kan være et tilfælde. Et fund, der skyldes, at adgangskontrol ikke er en del af jeres faste gennemgang, kan betyde, at andre funktioner har samme fejl. Det er derfor, en kunde kan spørge til årsagen, selv om rettelsen er efterprøvet og i orden. For kunden er årsagen et mål for, hvor meget rettelsen er værd. Lukker den et enkelt hul, eller ændrer den den måde, nye huller opstår på?

Hvor reglerne nævner årsager

Forordningen bruger ordet grundlæggende årsag om hændelser. Punkt 3.6.1 siger, at gennemgange efter hændelser, hvor det er muligt, skal afdække den grundlæggende årsag og resultere i dokumenterede erfaringer. SAMSIK’s vejledning om foranstaltninger siger noget tilsvarende om gennemgang efter en væsentlig hændelse. Et testfund er ikke en hændelse, men tankegangen er den samme, og kunder kan forvente den.

ENISA’s tekniske vejledning til forordningen, som ikke er bindende, anbefaler i afsnittet om sikker udvikling at overveje at lade resultater af årsagsanalyser føre til ændringer i udviklingsprocessen. For en kunde, der har overladt udvikling til jer, siger punkt 6.2.3, at kunden også anvender sine politikker for forsyningskæde og erhvervelse på den udliciterede udvikling. → Artikel 21, stk. 3: hvorfor kunden spørger til jeres udvikling

Det, kunden kan bede om at se

En beskrivelse af årsagen behøver ikke være lang. Den skal kunne læses af en sikkerhedsansvarlig hos kunden, som ikke kender jeres kode eller drift i detaljer.

Hvad fundet var · med henvisning til rapporten.
Hvorfor det kunne opstå · den proces, det valg eller det ansvar, der manglede.
Hvor ellers det kan findes · andre dele af leverancen, der bygger på samme valg eller komponent.
Hvad I har ændret · i proces, standard eller ansvar, ud over den konkrete rettelse.
Hvordan ændringen efterprøves · fx i næste test eller ved en intern gennemgang.

Hold beskrivelsen på begrebsniveau. Kunden har brug for at forstå sammenhængen, ikke for en teknisk opskrift. Er årsagen endnu ikke fundet, så sig det, og angiv, hvornår kunden kan forvente et svar. En foreløbig vurdering, der senere justeres, er mere nyttig for kunden end en endelig forklaring, der kommer for sent til at påvirke næste udgivelse. → Status på rettelser

Testerens rolle

Testleverandøren kan se et mønster, som I ikke selv lægger mærke til: flere fund af samme type, eller fund, der peger på et fælles svagt punkt. Det er værdifuldt, og I kan bede om, at rapporten nævner det. Men testeren kender ikke jeres interne processer og kan ikke afgøre, hvorfor en fejl opstod. Årsagen er jeres analyse.

Bed testleverandøren om at markere fund, der ser ud til at have en fælles årsag, og om at foreslå, hvor I bør se efter lignende fejl. Brug det som udgangspunkt for jeres egen vurdering. → Hvad I skal bede testleverandøren om

Når årsagen ligger hos andre

Nogle fund skyldes en komponent fra en underleverandør eller en standardopsætning hos en platform. Så er årsagen delvis uden for jeres kontrol, men kunden vil stadig vide, hvad I gør. Svaret kan være at stille krav til underleverandøren, at ændre jeres egen opsætning eller at udskifte komponenten. Fortæl kunden, hvilken del af årsagen I har indflydelse på. Det gør det muligt for kunden at vurdere, om der er en risiko, som kunden selv skal tage stilling til, og om kravet bør gå videre i kæden. Ligger fejlen i en open source-komponent, anbefaler ENISA’s vejledning til punkt 6.5, at fundet deles med det pågældende projekt. → Fund i tredjepartskomponenter i jeres leverance

Et tænkt eksempel

En leverandør af et laboratoriesystem til en privat klinik får ved en test tre fund, hvor brugere kan se oplysninger fra afdelinger, de ikke hører til. Fundene rettes hver for sig. Leverandøren undersøger derefter, hvorfor de opstod, og finder, at nye skærmbilleder ikke gennemgås for adgangskontrol før udgivelse. Klinikken får en kort beskrivelse: fundene, årsagen, at adgangskontrol nu er et fast punkt i gennemgangen, og at tre andre skærmbilleder er kontrolleret og fundet i orden. Ved næste test bliver adgangskontrol på tværs af afdelinger et udtrykkeligt punkt i omfanget.

Det skal I lade være med

At svare med rettelsen alene · kunden spørger også, om fejlen kan komme igen.
At give en person skylden · kunden har brug for at kende den proces, der svigtede, ikke et navn.
At love, at fejltypen aldrig kommer igen · I kan love en ændret proces, ikke et resultat.
At overlade årsagsanalysen til testeren · testeren kender ikke jeres interne forhold.
At skrive årsagen som teknisk opskrift · kunden skal forstå sammenhængen, ikke detaljerne.

Hvad kan og ikke kan konkluderes

En beskrivelse af årsagen viser kunden, at I har set ud over det enkelte fund, og hvad I har ændret. Den viser ikke, at alle fejl af samme type er fundet, og den kan ikke bevise, at den ændrede proces virker, før den er afprøvet. Næste test og jeres egne gennemgange er det, der kan vise det. Forordningen kræver vurdering og afbødning pr. fund, men den kræver ikke en årsagsanalyse af hvert testfund. → Midlertidige tiltag, når en rettelse tager tid