Spørgsmål om hændelser og håndtering af sårbarheder

Når kunden spørger til hændelser og sårbarheder, vil kunden vide, hvad der sker den dag, noget går galt i jeres produkt: hvem opdager det, hvem retter det, og hvornår hører kunden om det. Svaret skal derfor beskrive en proces, der findes i dag, med kontaktvej, roller og meddelelser til kunderne, og ikke en hensigt.

Penetrationstesten er én af flere kilder til sårbarheder i den proces. Det er et pænt svar at nævne den, men et svar, der kun handler om den årlige test, efterlader det vigtigste uden svar: hvordan I håndterer det, der dukker op mellem to test.

Hvad spørgsmålene dækker

Skemaerne kan blande to emner, som er nyttige at holde fra hinanden i svaret:

Sårbarhedshåndtering · hvordan I finder, vurderer, prioriterer og retter svagheder i produktet og dets komponenter.
Hændelseshåndtering · hvad I gør, når en svaghed er blevet udnyttet, eller når der er mistanke om, at kundedata er berørt.
Modtagelse udefra · hvordan en forsker, en kunde eller en anden udenforstående kan indrapportere en svaghed.
Meddelelse til kunderne · hvornår og hvordan kunden får besked, og hvad beskeden indeholder.
Historik · om der har været hændelser, og hvordan de blev håndteret.

Det sidste spørgsmål kræver omtanke og behandles i → Åbenhed om tidligere fund over for nye kunder

Kilderne til sårbarheder

Beskriv, hvor jeres viden om svagheder kommer fra. Det viser kunden, at processen ikke afhænger af én kilde:

Penetrationstest · den eksterne test, med dato og omfang.
Automatiske kontroller i udviklingen · fx kontrol af kode og afhængigheder ved hver ændring.
Meddelelser fra leverandører · når en komponent eller tjeneste, produktet bygger på, får en kendt sårbarhed.
Indrapporteringer udefra · fra kunder, forskere eller kundernes egne test.
Egen overvågning · logning og alarmer i driften.

Fundene fra pentesten hører til i den samme liste som alt andet. Lever de i et separat dokument, som kun den sikkerhedsansvarlige kender, bliver det svært at svare præcist, når kunden spørger, hvad der er sket med dem. Ligger de i den fælles liste med alvor, ejer og status, kan svaret i skemaet og status i rapporten bygge på de samme oplysninger.

Hver kilde fører til samme sted: en registrering, en vurdering af alvor og en ejer af rettelsen. Det er den fælles vej, kunden vil se. → Sårbarheder i afhængigheder mellem to test

Vurdering og prioritering i ord, kunden forstår

Kunden vil vide, at alvorlige svagheder bliver rettet før mindre alvorlige, og helst hvordan I afgør, hvad der er alvorligt. Beskriv skalaen, I bruger, og hvem der træffer beslutningen. Hvis I bruger en anerkendt metode til at vurdere alvor, så nævn den.

Vær forsigtig med faste rettefrister. Skriver I en frist for kritiske sårbarheder i skemaet, kan den blive læst som et løfte, og kunden kan senere ønske den skrevet ind i kontrakten. Oplys kun frister, I allerede arbejder efter og kan dokumentere, fx i en intern politik. Hvis I ikke har faste frister, så beskriv prioriteringen med ord og sig, at der ikke er en fast frist. → Rettefrister, kunden vil skrive ind i kontrakten

En kontaktvej, der kan findes

Mange skemaer spørger, om en udenforstående kan melde en svaghed til jer. Det britiske NCSC har udgivet et værktøjssæt til at oprette en proces for modtagelse af sårbarhedsmeldinger. Det består af tre dele: en kontaktvej, der er let at finde, en politik, der sætter forventningerne for den, der melder, og en security.txt-fil. Filformatet er beskrevet i RFC 9116, som lægger filen et fast sted på domænet, så andre kan finde kontaktoplysninger og politik.

Har I sådan en kontaktvej, så henvis til den i svaret. Har I den ikke, er det et godt tidspunkt at overveje den, men skriv ikke, at den findes, før den gør. Opbygningen af en sådan politik er beskrevet i → Ansvarlig offentliggørelse

Når kunden skal have besked

Det felt, kunden læser mest grundigt, handler om underretning. Kunden vil vide, om I giver besked, når en sårbarhed eller en hændelse kan berøre kundens data, hvem beskeden går til, og hvad den indeholder.

Svar med det, der faktisk er jeres praksis eller jeres aftale. Hvis kontrakten har en bestemmelse om underretning, så henvis til den. Hvis en kunde er underlagt egne regler om rapportering af hændelser, kan kunden have brug for hurtige oplysninger fra jer, og det er en god grund til at aftale kontaktpersoner på begge sider på forhånd. Teksten her er ikke juridisk rådgivning om, hvornår en underretning er påkrævet. → Pligt til at underrette kunden om sårbarheder

Beskriv også, hvordan beskeden sendes. En fast skabelon og en liste over sikkerhedskontakter hos kunderne gør det muligt at svare hurtigt og ens. → Sikkerhedsmeddelelse til kunderne

Et tænkt eksempel

Et softwarehus med et system til digitale ansøgninger i fonde besvarer feltet: “Beskriv jeres proces for håndtering af sårbarheder og sikkerhedshændelser.”

Svaret: “Sårbarheder registreres i én fælles liste uanset kilde: ekstern penetrationstest én gang om året, automatisk kontrol af kode og komponenter ved hver udgivelse, leverandørmeddelelser og meldinger via vores sikkerhedskontakt, som er beskrevet i en offentlig politik. Hver sårbarhed får en alvorlighed og en ejer i udviklingsteamet, og kritiske sårbarheder prioriteres foran planlagt udvikling. Ved mistanke om, at kundedata er berørt, aktiveres vores hændelsesplan, og kundens udpegede sikkerhedskontakt orienteres efter bestemmelserne i kundeaftalen.”

Svaret beskriver en proces og peger på dokumenter, der findes, uden at love frister, softwarehuset ikke har.

Det skal I lade være med

Svare kun med den årlige test · Kunden vil vide, hvad der sker mellem testene.
Love frister, I ikke arbejder efter · De bliver læst som en forpligtelse.
Beskrive en kontaktvej, der ikke findes · Kunden kan prøve den.
Blande hændelser og sårbarheder sammen · De to spørgsmål har forskellige svar.
Udelade leverandørernes sårbarheder · Komponenter og tjenester er en del af produktet.
Love underretning ud over aftalen · Henvis til det, der står i kontrakten.

Hvad kan og ikke kan konkluderes

Et svar, der beskriver kilder, vurdering, ejerskab og underretning, viser kunden, at sårbarheder i produktet bliver håndteret efter en fast proces. Det giver ikke vished for, at alle svagheder bliver fundet, og det siger ikke noget om, hvor hurtigt en bestemt sårbarhed bliver rettet, medmindre I har en dokumenteret praksis for det. Pentesten er en efterprøvning af en del af produktet på et bestemt tidspunkt og kan ikke stå alene som svar.