Efter en hændelse hos jer: kunden vil se en ny test

Når et softwarehus har haft en sikkerhedshændelse, kan det være kunderne, der først kræver en ny penetrationstest. En ny test kan give dem dokumentation for, at de ændringer, I har lavet, holder, men den kan ikke alene vise, at hændelsen er forstået og håndteret.

Svaret til kunden består derfor af to dele: en redegørelse for hændelsen og det, I har ændret, og en test, der er afgrænset til netop de ændringer og de dele af produktet, hændelsen berørte. Rækkefølgen betyder noget. En test, der kommer før rettelserne, giver kunden en rapport om et produkt, der allerede er under ombygning.

Kundens spørgsmål er større end testen

Bag kravet om en ny test kan der ligge tre spørgsmål. Hvad skete der? Er vores data berørt? Og kan vi stole på produktet fremover? En pentestrapport svarer kun på en del af det sidste. De to første kræver jeres egen redegørelse, og hvis personoplysninger er berørt, kan der være regler om underretning, som I skal have afklaret særskilt med rådgivere. Teksten her er ikke juridisk rådgivning.

Lyt efter, hvad den enkelte kunde lægger vægt på. En kunde i sundhedssektoren spørger måske mest til adgangen til følsomme oplysninger. En anden vil primært vide, om integrationen til kundens eget system har været misbrugt. Testens afgrænsning bør kunne forklares med de spørgsmål.

Hvornår testen bør ligge

Der er to fejl, der går igen. Den ene er at bestille en test, mens undersøgelsen af hændelsen stadig står på. Testerens aktivitet kan blandes sammen med spor fra hændelsen, og rettelserne er endnu ikke på plads. Den anden fejl er at vente så længe, at kunderne mister tålmodigheden og begynder at stille krav om egne test.

En brugbar plan har tre trin: undersøgelsen afsluttes, de besluttede ændringer gennemføres, og testen afprøver dem. Giv kunderne datoerne for hvert trin, og hold dem orienteret, hvis et trin flytter sig. Penetrationtest.dk forklarer køberens side af den rækkefølge mere generelt på penetrationtest.dk. → Lanceringsdato og testvindue

Hvad testen skal dække

Testen bør tage udgangspunkt i hændelsen. Kom angriberen ind via et login, en integration eller en supportfunktion, skal netop den indgang og de tilstødende funktioner være med. Det samme gælder adskillelsen mellem kunder, hvis der er tvivl om, hvor langt adgangen rakte. → Multi-tenant: test af adskillelsen mellem kunderne · → Supportadgang og administrationsmodul

Overvej også, om testen skal være bredere end hændelsen. Hvis årsagen var en svaghed i en type funktion, der findes flere steder i produktet, er det rimeligt at afprøve de andre steder også. Beslut det på forhånd og skriv det i bestillingen, så rapporten viser, hvad der bevidst er med, og hvad der ikke er.

Giv testeren den viden fra undersøgelsen, der er nødvendig for at afgrænse testen. Det er ikke sikkert, at testeren skal have hele redegørelsen. Det vigtige er, at testen rammer det, kunderne er bekymrede for.

Hvad kunderne skal have bagefter

Overvej, hvilken form dokumentationen skal have, før testen bestilles. Nogle kunder vil se hele rapporten. Andre er tilfredse med et resumé eller et brev fra testeren, der siger, hvad der er afprøvet, hvornår, og hvad resultatet var. Efter en hændelse bør dokumentationen tydeligt forbinde testen med hændelsen: hvilke ændringer var formålet at kontrollere, og hvad viste testen om dem? → Hel rapport, resumé eller erklæring

Er der fund i den nye test, så sig det. Kunder, der lige har oplevet en hændelse hos en leverandør, reagerer stærkere på at opdage et fortiet fund end på et åbent fund med en plan. Vis status for rettelserne og datoen for retest.

Det en ny test kan og ikke kan genoprette

Testen kan vise, at de ændringer, I har lavet, holdt under afprøvningen. Det giver kunderne noget konkret at henvise til internt. Men tillid efter en hændelse bygger også på, hvordan I kommunikerede undervejs, og om jeres forklaring hænger sammen. En flot rapport opvejer ikke en uklar redegørelse.

Det britiske NCSC beskriver i sin vejledning om penetrationstest, at en test kun kan bekræfte forholdene på testtidspunktet, og at den ikke erstatter organisationens løbende arbejde med sårbarheder. Det er også en god ramme for samtalen med kunden: testen er et kontrolpunkt, ikke hele svaret.

Tænk til sidst på den næste regulære test. Hvis den ekstra test efter hændelsen ligger tæt på den årlige, kan de to måske samles. Hvis ikke, så forklar kunderne, hvordan de to forholder sig til hinanden. → Testen finder noget alvorligt: skal kunderne have besked?

Én stemme over for kunderne

Efter en hændelse kommer spørgsmålene fra mange sider på én gang: kundernes sikkerhedsfolk, deres indkøbere og deres ledelse. Hos jer risikerer sælgere, kundeansvarlige og udviklere at svare hver for sig. Det giver små forskelle i forklaringen, og kunderne lægger mærke til dem.

Udpeg derfor én person, der ejer kommunikationen om hændelsen og testen, og lav et fælles skriftligt grundlag, som alle andre henviser til. Grundlaget opdateres, når testen er bestilt, når den er gennemført, og når eventuelle fund er rettet. Notér også, hvilke kunder der har fået hvilken version af dokumentationen. Når den næste kunde spørger et halvt år senere, kan I så svare ud fra det samme grundlag i stedet for at rekonstruere forløbet fra mails. → Et fast kontaktpunkt for kundernes sikkerhedsspørgsmål

Det skal I lade være med

Teste midt i undersøgelsen · Spor fra hændelsen og testerens aktivitet kan blandes sammen.
Teste før rettelserne · Rapporten beskriver så et produkt, der allerede er ved at blive ændret.
Bruge testen som hele forklaringen · Kunden spørger også, hvad der skete, og hvad der er ændret.
Holde fund i den nye test tilbage · Et fortiet fund skader mere efter en hændelse end ellers.
Love, at det ikke sker igen · En test kan ikke dokumentere det, og kunden ved det.

Hvad kan og ikke kan konkluderes

En ny test kan dokumentere, at bestemte ændringer holdt under en afgrænset afprøvning på et bestemt tidspunkt. Den kan ikke vise, hvad der skete under hændelsen, om data blev tilgået, eller at produktet er sikkert fremover. Det skal fremgå af andre dele af jeres svar til kunderne.