Spørgsmålet om penetrationstest i skemaet: hvad svarer I?

Spørgsmålet ser enkelt ud: “Udfører I regelmæssig penetrationstest af jeres løsning?” Bag det ligger dog fem spørgsmål, som kundens sikkerhedsfolk vil have besvaret: hvad blev testet, hvornår, af hvem, hvad blev fundet, og hvad er der sket siden. Et præcist svar giver de fem oplysninger kort og ærligt og henviser til den dokumentation, kunden kan få.

Et rent ja er sjældent nok. Det fortæller kunden, at noget er testet engang, men ikke om det var produktet, kunden køber, eller om fundene er rettet. Uden de oplysninger sender kunden et opfølgende spørgsmål, og salget venter igen.

Hvad kunden egentlig spørger om

Kunden bruger svaret til at vurdere, om produktet er afprøvet af nogen, der har forsøgt at finde svagheder, og om I handler på resultatet. Det er ikke testen i sig selv, der interesserer, men hvad den siger om produktet og om jeres måde at arbejde på.

Læs også, hvordan spørgsmålet er formuleret. Står der “regelmæssig”, vil kunden vide noget om rytmen. Står der “uafhængig”, vil kunden vide, hvem testeren var. Står der “applikation”, er det produktet og ikke kontornettet, der er i fokus. Hvert ord peger på en del af svaret, I skal have med. Er formuleringen uklar, så spørg kundens kontaktperson, hvad der menes, før I svarer. Et kort spørgsmål tilbage sparer ofte en runde med uddybninger senere, og det viser, at I tager skemaet alvorligt.

De fem oplysninger i et godt svar

Omfanget · hvilket produkt, hvilke moduler og hvilket miljø blev testet, og var API’et med?
Tidspunktet · hvornår blev testen afsluttet, og hvilken version af produktet var det?
Testeren · var det en ekstern tester, og hvordan er testeren uafhængig af udviklingen?
Resultatet · var der alvorlige fund, og er de rettet og efterprøvet?
Næste test · hvornår er den planlagt, eller hvad udløser den?

Svaret behøver ikke være langt. Fem korte sætninger dækker meget af det, et skema spørger om. Det vigtige er, at hver sætning kan underbygges med rapporten eller en erklæring, hvis kunden beder om det. Skriv svaret, så det giver mening for en læser, der ikke kender jeres produkt. Brug kundens egne betegnelser for modulerne, hvis de afviger fra jeres interne navne, og undgå forkortelser, som kun udviklingsteamet bruger. Hvis flere kunder stiller næsten samme spørgsmål, kan en fast grundformulering spare tid, men tilpas den hver gang til det, netop denne kunde køber. → Hvor ofte tester I?

Et eksempel på et svar

Et tænkt svar fra et softwarehus med en platform til kontraktstyring kunne lyde sådan: Webapplikationen og det offentlige API blev penetrationstestet af en ekstern tester, som ikke deltager i udviklingen. Testen blev afsluttet i foråret og omfattede den version, der var i drift på det tidspunkt. Der var to fund af høj alvorlighed; begge er rettet, og rettelserne er efterprøvet af testeren. Næste test er planlagt til samme tid næste år og tidligere, hvis der kommer større ændringer i login eller adskillelsen mellem kunder. Et resumé fra testeren kan udleveres efter aftale om fortrolighed.

Svaret lover intet ud over det, der er sket, og det giver kunden en vej til at få dokumentationen. Det nævner ikke tekniske detaljer om fundene, fordi kunden ikke har brug for dem for at vurdere jeres håndtering. → Hel rapport, resumé eller erklæring

Omfanget skal passe til det, kunden køber

Det mest almindelige problem er, at testen dækkede noget andet end det, kunden skal bruge. Måske var kundeportalen med, men ikke integrationsmodulet, eller måske blev testen udført på en version, der siden er skrevet om. Sig det i svaret. Kunden opdager det alligevel, når rapportens omfangsafsnit bliver læst, og så er det bedre, at I selv har nævnt det. Hvis den del, kunden skal bruge, ikke var med, så skriv, hvornår den forventes testet, og om andre forhold, fx kodegennemgang eller automatiske test, dækker den i mellemtiden. → Omfangsafsnittet

Det britiske NCSC påpeger, at en penetrationstest kun kan bekræfte, at systemerne ikke var sårbare over for kendte problemer på testdagen. Det er en nyttig formulering at have i baghovedet. Svaret beskriver en test på et bestemt tidspunkt, ikke en garanti for produktet i dag. Skriv derfor ikke, at produktet er sikkert eller godkendt. Skriv, hvad der blev testet, og hvad resultatet var.

Hold scanning og pentest adskilt

Mange skemaer spørger til sårbarhedsscanning og penetrationstest i samme felt. Svar på dem hver for sig. En automatisk scanning i pipelinen er værdifuld, men den er ikke det samme som en manuel test, og kunden ved det. Hvis I blander dem sammen, kan det se ud, som om I forsøger at få scanningen til at ligne mere, end den er. → Scanning og pentest i samme spørgsmål

Når svaret ikke er et rent ja

Har I ikke fået testet produktet endnu, eller er seneste test for gammel til kundens krav, så sig det, og giv en plan med dato. Er der åbne fund, så oplys status uden at udlevere detaljer, der kan bruges mod produktet. Ærlighed på de punkter kan være det, der gør, at kunden tror på resten af skemaet. Et svar med en konkret plan og en ansvarlig person vejer tungere end et vagt løfte om, at en test er på vej. → Et ærligt svar, når I endnu ikke har en test · → Skemaet spørger til åbne fund

Det skal I lade være med

Svare ja uden flere oplysninger · det udløser blot et nyt spørgsmål fra kunden.
Beskrive en test af kontornettet som en test af produktet · kunden spørger til det, de køber.
Kalde en scanning for en penetrationstest · det svækker tilliden til hele skemaet.
Skrive, at alle fund er rettet, hvis enkelte er accepteret · forklar, hvad der er besluttet.
Vedhæfte den fulde rapport uopfordret · tilbyd det dokument, der passer, efter aftale om fortrolighed.

Hvad kan og ikke kan konkluderes

Et godt svar på pentest-spørgsmålet viser, at produktet er afprøvet, og at I har handlet på resultatet. Det viser ikke, at produktet er uden svagheder i dag, og det siger kun noget om de dele og den version, der var med i testen. Kunden kan konkludere noget om jeres praksis, men ikke om sikkerheden i dele, der ikke var testet.