Typiske fejl, når softwarehuse svarer på kundekrav om test

Et kundekrav om penetrationstest går igennem mange hænder i et softwarehus, og hvert led har sin egen fejl, der er let at begå: kravet bliver læst for bredt, svaret i skemaet lover for meget, testen dækker ikke det, kunden køber, eller rapporten bliver sendt uden fortrolighed. Fejlene har én ting til fælles. De opstår, når svaret til kunden bliver skrevet ud fra det, der ville være rart at kunne sige, og ikke ud fra det, der kan dokumenteres. Her er de samlet efter, hvor i forløbet de opstår. Hvert afsnit peger videre til en artikel, der går i dybden med netop det led.

Når kravet skal forstås

Den første fejl sker, før nogen har bestilt noget. Et krav om, at leverandøren skal være testet, kan betyde en test af produktet eller af virksomhedens egen IT, og de to er forskellige opgaver. At gætte i stedet for at spørge kan føre til en test, kunden ikke kan bruge. Spørg derfor skriftligt, og gem svaret sammen med kravet. Så kan I henvise til det, når testen bestilles, og hvis kunden senere læser sit eget krav anderledes.

At antage, hvad kunden mener · spørg, hvad rapporten skal bruges til, og hvem der skal læse den.
At læse hver kundes krav for sig · flere krav kan opfyldes med én test, hvis I finder det fælles.
At overse en henvisning til en standard · find det konkrete krav bag henvisningen.

→ Hvad skal kunden bruge rapporten til?

Når skemaet skal udfyldes

Spørgeskemaet kan blive udfyldt under tidspres, og det er her, de for store svar opstår. Et ja til et spørgsmål om årlig penetrationstest er forkert, hvis I kun har kørt en automatisk scanning. Et ja til spørgsmålet om rettede fund er forkert, hvis et højt fund venter på en ombygning. Begge svar kan blive læst igen, hvis der senere opstår en hændelse, og så vejer de mere, end de gjorde, da de blev skrevet.

At svare ja, når svaret er delvist · brug kommentarfeltet til at sige, hvad der er opfyldt.
At kalde en scanning for en pentest · brug det rigtige navn.
At svare forskelligt til forskellige kunder · brug et godkendt svarbibliotek.
At lade sælgeren svare alene · tekniske svar skal komme fra dem, der ved det.

→ Svar, I ikke kan dokumentere

Når testen skal bestilles

En test, der er bestilt uden kunderne i tankerne, kan være god nok til jer selv og ubrugelig over for kunderne. Omfanget passer ikke til de moduler, kunderne køber, rapporten nævner ikke version og datoer, eller formen kan ikke udleveres.

At bestille et for smalt omfang · test det, kunderne bruger, herunder API og administration.
At glemme adskillelsen mellem kunder · den er et af de første spørgsmål fra kundens sikkerhedsfolk.
At bestille uden tid til rettelser · rapporten kan ende med at vise åbne fund.
At lægge testen, hvor der var tid · læg den, så rapporten er aktuel, når kunderne skal bruge den.

→ Bestil testen, så rapporten kan bruges over for kunder

Når rapporten skal udleveres

Den fulde rapport beskriver svagheder i jeres produkt. Sendt som vedhæftet fil til en sælger hos kunden kan den ende hvor som helst. Omvendt kan et resumé uden omfang og datoer være for tyndt til kundens sikkerhedsfolk. Valget af form er derfor ikke en formalitet, men en afvejning mellem kundens behov for at vurdere jer og jeres behov for at beskytte oplysningerne.

At sende den fulde rapport uden fortrolighed · aftal form og vilkår først.
At sende et resumé uden omfang · kunden skal kunne se, hvad der var med.
At bruge en gammel rapport uden at sige, hvad der er ændret · forklar ændringerne.
At føre ingen log over udleveringer · I skal kunne sige, hvem der har fået hvad.

→ Kundeversionen af rapporten

Når fundene skal følges op

Kunden spørger ikke kun, om I er testet, men hvad der skete bagefter. En rapport med fund, der ikke er rettet, og ingen plan for dem, er et dårligere svar end en rapport med færre fund og et tydeligt forløb. Fejlene i denne fase opstår, fordi testen opleves som afsluttet, når rapporten kommer. For kunden begynder den interessante del først der: hvad gjorde I med fundene, og kan I vise det?

At kalde et fund rettet, før det er efterprøvet · skeln mellem meldt rettet og efterprøvet.
At lade åbne fund stå uden plan · giv dem en periode og en ejer.
At glemme at orientere kunderne om et alvorligt fund · beslut det bevidst og skriv det ned.

Den britiske NCSC skriver, at vurderingen af risiko og beslutningen om rettelser er organisationens ansvar og ikke bør overlades helt til testteamet. → Retestbevis til kunden

Når kontrakten skal skrives

Et skemasvar kan blive en del af aftalegrundlaget, og en kontrakt kan gøre et løfte om test, rettefrister eller underretning bindende. Fejlene her er dyre at rette bagefter. Lad en, der kender jeres faktiske proces, læse sikkerhedsbestemmelserne, før kontrakten underskrives, og lad ledelsen tage stilling til de punkter, hvor I afviger fra jeres faste vilkår.

At acceptere rettefrister, I ikke kan holde · forhandl dem ud fra jeres faktiske proces.
At love underretning om alle sårbarheder · afgræns efter alvorlighed og berøring.
At give hver kunde sit eget sæt løfter uden at registrere dem · så bliver nogen glemt.
At skrive en sikkerhedsgaranti ind for at redde salget · ingen test kan bære den.

→ Forhandling af sikkerhedskrav · → Jeres egne sikkerhedsvilkår

Det skal I lade være med

Hvis listen skal koges ned til fem punkter, er det disse:

At love mere, end rapporten kan bære · i skema, salgstekst og kontrakt.
At teste noget andet end det, kunderne køber · omfanget skal passe til produktet.
At bestille uden tid til rettelser og retest · ellers viser rapporten åbne fund.
At udlevere uden fortrolighed og log · rapporten beskriver jeres svagheder.
At lade kravet være uden ejer · så falder det mellem salg og udvikling.

Hvad kan og ikke kan konkluderes

En liste over fejl kan hjælpe jer med at se, hvor jeres egen proces er svag. Den siger ikke, hvilke fejl der er mest udbredte, og den erstatter ikke en gennemgang af jeres egne kontrakter og svar. En kunde kan stadig stille krav, som listen ikke dækker. Teksten er ikke juridisk rådgivning.