Kunden beder om en pentestrapport: de første skridt

En mail fra en kunde, der beder om jeres seneste pentestrapport, kan føre til en hurtig bestilling af en test, der ikke svarer på det, kunden spurgte om. Det første skridt er derfor ikke at bestille, men at forstå kravet: hvad skal dokumenteres, for hvilket system, og i hvilken form skal kunden modtage det?

Når de tre ting er afklaret, kan I vurdere, om en eksisterende rapport er nok, om en ny test er nødvendig, og hvad der kan deles. Bestillingen bliver mere præcis, og kunden får et svar, der kan bruges.

Spørg, hvad kunden faktisk beder om

Ordet pentestrapport bruges om flere forskellige ting. Nogle kunder vil se en fuld rapport med fund og anbefalinger. Andre er tilfredse med en kort erklæring om, at der er gennemført en test, hvornår og af hvem. Nogle har i virkeligheden et spørgeskema, hvor et af spørgsmålene handler om sikkerhedstest.

Spørg derfor kunden direkte. Hvad skal dokumentationen bruges til? Er der en bestemt standard eller en bestemt kontraktbestemmelse bag ønsket? Og hvem hos kunden skal læse den? Svarene afgør, hvor omfattende jeres svar skal være. → Kontrakten med en kunde kræver sikkerhedstest

Bed om kravet skriftligt, hvis det ikke allerede foreligger. En mundtlig formulering fra et salgsmøde er svær at bestille en test ud fra, og den er svær at henvise til, hvis kunden senere mener, at svaret ikke var tilstrækkeligt.

Hvilket system og hvilken del af leverancen

Kunden er sjældent interesseret i hele jeres IT. Det, der betyder noget for kunden, er typisk den løsning, kunden selv bruger eller har data i: kundeportalen, et API, kunden er koblet på, eller den del af driften, der behandler kundens oplysninger.

Afgræns derfor testen til det, kravet handler om. En rapport om kontornettet besvarer ikke et spørgsmål om kundeportalen, og en rapport om webshoppen siger ikke noget om integrationen til kundens ERP-system. Skriv i bestillingen, hvilke systemer der indgår, og hvorfor. → Scope i en penetrationstest

Spørg også, om kunden forventer en bestemt type test. Nogle kunder vil have en test med login som almindelig bruger, fordi de vil vide, om andre kunder kan se deres oplysninger. Andre er mest optaget af det, der er synligt fra internettet.

Tænk også på, om andre kunder kunne stille samme spørgsmål. Hvis flere kunder bruger den samme portal, kan en test, der er afgrænset til portalen som helhed, besvare flere henvendelser på én gang. Det kræver dog, at scope og rapport er skrevet, så de ikke indeholder oplysninger om enkelte kunder, og at hver modtager kan se, hvilken del af løsningen der er undersøgt. Spørg samtidig den kunde, der henvendte sig, om der er særlige forhold i netop deres opsætning, som en fælles test ikke ville dække.

Krav til testeren og til rapportens alder

Kravet kan også handle om, hvem der har udført testen. Et krav kan for eksempel være, at testen skal være udført af en uafhængig part og ikke af den, der har udviklet eller driver løsningen. Læs formuleringen præcist, for uafhængig kan betyde forskellige ting fra kunde til kunde. Hvis kravet nævner certificeringer eller bestemte kvalifikationer, så notér dem og spørg testeren, før I bestiller. → Uafhængig penetrationstest

Kunden kan også have en forventning om, hvor gammel rapporten må være. Hvis der ikke står noget, så spørg. En rapport fra før en stor ændring af portalen er måske ikke det svar, kunden har brug for, selv om den er relativt ny. → Rapportens alder

Hvad må kunden se?

En fuld pentestrapport indeholder oplysninger om svagheder, og nogle af dem kan være uløste. At sende den til en kunde er en beslutning, der bør træffes bevidst. Overvej, om en kort erklæring eller et resumé kan dække kundens behov. → Testerklæring til kunder

Hvis kunden skal have den fulde rapport, så aftal fortrolighed først. Hvem hos kunden må læse den, hvordan opbevares den, og hvad sker der med den, når samarbejdet slutter? En fortrolighedsaftale med kunden kan være et naturligt sted at få det beskrevet. → Deling af pentestrapporten

Husk, at kunden også vil se, hvad I har gjort ved fundene. En rapport med uløste kritiske fund og ingen plan giver et dårligere indtryk end en rapport, hvor fundene står sammen med en handlingsplan og eventuelle efterprøvninger.

Når I allerede har en rapport

Har I en nylig rapport, så læs den igen med kundens krav i hånden. Dækker scope det system, kunden spørger om? Er testen udført af en part, der opfylder kundens krav? Er de væsentlige fund rettet eller håndteret?

Hvis svaret er ja, kan rapporten eller en erklæring baseret på den være nok. Hvis svaret er nej på et af punkterne, så skriv til kunden, hvad I har, og hvad I planlægger. Et åbent svar med en plan er bedre end en rapport, der ikke passer, sendt i håb om, at ingen opdager forskellen. Spørg kunden, om en konkret plan med dato for den kommende test kan dække behovet i mellemtiden, og hvilken dokumentation kunden så forventer at modtage, når testen er gennemført.

Softwarehuse og SaaS-leverandører, der ofte får denne type krav, finder mere om emnet på pentestrapport.dk.

Det skal I lade være med

At bestille, før kravet er afklaret · En test af det forkerte system besvarer ikke kundens spørgsmål.
At sende den fulde rapport uden overvejelse · En erklæring eller et resumé kan være nok.
At dele uden aftalt fortrolighed · Rapporten beskriver svagheder og skal behandles derefter.
At lade leverandøren teste sit eget arbejde · Kunden vil ofte kræve en uafhængig part.
At sende en rapport, der ikke dækker kravet · Forklar hellere, hvad I har, og hvad der er planlagt.
At skjule uløste fund · En handlingsplan sammen med rapporten giver et mere troværdigt billede.

Hvad kan og ikke kan konkluderes

En pentestrapport kan dokumentere over for kunden, at en bestemt løsning er testet på et bestemt tidspunkt, af en bestemt part og med et beskrevet scope. Sammen med en handlingsplan kan den vise, hvordan I håndterer resultatet.

Den kan ikke dokumentere, at hele virksomheden er sikker, og den opfylder ikke nødvendigvis andre krav i kundens kontrakt. Hvad kunden accepterer, afgør kunden.