I har endnu ikke fået lavet en test: et ærligt svar i skemaet

Feltet om penetrationstest skal udfyldes, og produktet er aldrig blevet testet af en ekstern tester. Fristen er om få dage, og fristelsen er at skrive noget, der lyder bedre end virkeligheden. Det ærlige svar hviler på tre dele: sig, at produktet ikke er testet endnu, fortæl, hvad I gør i stedet, og giv en konkret plan med en dato.

Et blankt nej uden forklaring får kunden til at tro, at sikkerhed ikke er prioriteret. Et ja, der dækker over en intern gennemgang eller en scanning, bliver opdaget, så snart kunden beder om rapporten. Mellem de to ligger et svar, som kunden kan acceptere, i hvert fald for en tid.

Hvorfor et for stort ja er farligt

Et svar i et sikkerhedsspørgeskema bliver en del af kundens dokumentation og måske en del af aftalegrundlaget. Hvis I skriver, at produktet testes regelmæssigt, og kunden senere beder om den seneste rapport, står I med et svar, der ikke holder. Det skader tilliden mere end det oprindelige nej ville have gjort, og det kan få betydning, hvis der senere opstår en tvist om, hvad I har lovet.

Det samme gælder halve sandheder. En automatisk scanning, en kollegas gennemgang eller en test af et andet system er ikke en penetrationstest af produktet, og den skal ikke beskrives som en. → Svar, I ikke kan dokumentere

Det ærlige svar i tre dele

Status · produktet er endnu ikke penetrationstestet af en ekstern tester.
Det, der findes nu · de sikkerhedsforanstaltninger, I faktisk har, fx automatiske test i udviklingen, kodegennemgang, adgangsstyring og logning.
Planen · hvornår testen er bestilt eller planlagt, hvad den skal omfatte, og hvornår kunden kan forvente et resumé eller en erklæring.

Et tænkt eksempel på et svar fra et softwarehus med en platform til medlemsadministration: Platformen er endnu ikke penetrationstestet af en ekstern part. Vi kører automatisk sårbarhedsscanning af koden og dens afhængigheder ved hver udgivelse, og alle ændringer gennemgås af en anden udvikler. En ekstern penetrationstest af webapplikationen og API’et er bestilt til gennemførelse i næste kvartal. Et resumé fra testeren kan udleveres, når testen og eventuelle rettelser er afsluttet.

Svaret er kort og konkret, og hver sætning kan dokumenteres. Det nævner det, der findes, uden at kalde det mere, end det er. Bemærk, at eksemplet ikke lover noget om resultatet af testen, kun at den gennemføres, og at kunden får et dokument bagefter. Undgå også at skrive, at I forventer få eller ingen fund. Det ved ingen, før testen er lavet. → Ja, nej eller delvist

Planen skal være reel

En plan med en dato er kun troværdig, hvis den holder. Skriv ikke, at testen er planlagt, hvis den kun er en idé. Hvis I endnu ikke har valgt tester, så skriv, at I er ved at indhente tilbud, og hvornår I forventer at have bestilt. Kunden vil hellere have en realistisk dato end en optimistisk, der skrider. Regn også tid med til rettelser efter testen. Første test af et produkt kan finde noget, og et resumé, der viser alvorlige åbne fund, er ikke det dokument, kunden venter på.

Når testen bestilles, så tænk kundernes brug ind fra starten. Omfanget skal dække det, kunderne køber, og rapporten skal kunne deles i en form, kunderne accepterer. Ellers står I med en test, der ikke løser det problem, der fik jer til at bestille den. → Bestil testen til kundebrug

Hvad testen kommer til at koste, afhænger især af produktets størrelse, antallet af roller og integrationer, og om API’et skal med. Det er værd at afklare tidligt, så planen i skemaet ikke bygger på et budget, der ikke findes. Se mere om, hvad der påvirker opgaven, under pris og tilbud.

Når kunden ikke vil vente

Nogle kunder har en fast regel om, at leverandører skal kunne vise en test, før aftalen underskrives. Spørg, om kunden kan acceptere en betinget aftale, hvor testen skal være gennemført inden en bestemt dato, eller om en del af aftalen kan vente. Spørg også, hvad kunden konkret vil have dokumenteret. Nogle gange handler bekymringen om én funktion, som kan prioriteres i testen, så et resultat foreligger hurtigere. → Aftalen venter på en pentestrapport

Hvis kunden står fast, er det en forretningsbeslutning, om I vil fremskynde testen. En hastesag skal tydeligt aftales med testeren, fordi den koster mere og lægger pres på jeres egne udviklere, der skal kunne rette fundene hurtigt. Overvej, om en mindre første test af den del, kunden bekymrer sig mest om, er bedre end at presse hele omfanget ind i en kort periode.

Forbered jer på næste skema

Når det første skema har afsløret manglen, kommer den igen i det næste. Brug anledningen til at få styr på det grundlæggende: en beskrivelse af jeres sikkerhedsarbejde i udviklingen, en oversigt over de foranstaltninger, der findes, og en plan for test, som også rækker ud over den første. Så kan svaret i næste skema skrives hurtigt og med samme ordlyd hver gang. Læg svaret i jeres fælles svarbibliotek med en ejer og en dato, så det bliver taget op til revision, når planen ændrer sig. → Startup uden sikkerhedsfunktion

Opdater svaret, så snart testen er gennemført. Et skema, der stadig siger “planlagt”, efter at rapporten er modtaget, sender et forkert signal til en kunde, der læser det igen ved fornyelsen.

Det skal I lade være med

Kalde en scanning for en penetrationstest · kunden kan se forskel, når dokumentationen bliver efterspurgt.
Skrive et nej uden forklaring · fortæl, hvad der findes, og hvad der kommer.
Opgive en dato, I ikke kan holde · en skredet plan svækker tilliden til næste svar.
Bestille en test, der ikke dækker det, kunden køber · så løser den ikke kundens behov.
Glemme at opdatere svaret · når testen er gennemført, skal skemaerne vise det.

Hvad kan og ikke kan konkluderes

Et ærligt svar uden test viser kunden, at I kender jeres egen situation og har en plan. Det siger intet om, hvordan produktet vil klare en test, og det kan ikke erstatte en rapport, hvis kunden kræver én. Kundens beslutning kan derfor stadig falde ud til jeres ulempe, men den træffes på et korrekt grundlag.