Svar, I ikke kan dokumentere: risikoen ved at love for meget

Et sikkerhedsskema kan blive udfyldt under tidspres af en sælger, der gerne vil have aftalen i hus, og det er netop dér, de for store svar opstår. Risikoen er, at kunden lægger svarene til grund for sin beslutning, og at de kan blive en del af aftalegrundlaget. Et svar, I ikke kan dokumentere, er derfor ikke en lille unøjagtighed, men et løfte, I måske ikke kan holde.

Reglen er enkel: skriv kun det, I kan vise et dokument, en log eller en proces for, og formulér svaret, så det ikke siger mere end dokumentet. Teksten her er ikke juridisk rådgivning om, hvilken betydning et forkert svar har i en konkret aftale.

Hvorfor et svar vejer mere, end det ser ud til

For kunden er skemaet grundlaget for en vurdering. Kundens sikkerhedsfunktion bruger svarene til at beslutte, om produktet må tages i brug, og hvilke data der må lægges ind. Nogle kunder vedlægger skemaet som bilag til kontrakten eller henviser til det i aftalen. Andre gemmer det som dokumentation over for deres egen revisor eller tilsynsmyndighed.

Hvis et svar senere viser sig at være forkert, rammer det tilliden til hele skemaet. Kunden vil spørge, hvilke andre svar der heller ikke holder. Og hvis der opstår en hændelse, vil kunden læse skemaet igen med et andet blik end ved købet. → Sikkerhedsbilaget til kundekontrakten

Formuleringer, der lover for meget

Bestemte ord gør et svar bredere, end det var ment. Hold øje med dem, før skemaet sendes:

Altid og alle · “alle ændringer sikkerhedstestes” holder sjældent for hver eneste ændring.
Løbende og kontinuerligt · siger intet om frekvens og kan læses som mere, end I gør.
Ingen kendte sårbarheder · gælder kun på et tidspunkt og kun for det, der er undersøgt.
Fuldt testet · en penetrationstest har altid et afgrænset omfang.
Certificeret · kan forveksle jeres egen status med en leverandørs eller en enkelt medarbejders.
Efter standarden · “testet efter OWASP Top 10” lyder præcist, men listen er et oplysningsdokument om udbredte risici, ikke en testmetode.

Erstat dem med det konkrete: hvad blev testet, hvornår, af hvem, og hvad var resultatet. → Spørgsmålet om penetrationstest i skemaet

Hvor de for store svar opstår

De udokumenterede svar har ikke nødvendigvis ond vilje bag sig. De opstår, når den, der udfylder skemaet, ikke kender svaret og gætter i den retning, kunden ønsker. De opstår, når et gammelt svar genbruges, efter at produktet har ændret sig. Og de opstår, når en scanning, en kodegennemgang eller en test af et andet system bliver beskrevet som en penetrationstest af produktet.

Det sidste er særligt vigtigt i svar om test. En automatisk scanning er nyttig, men den er ikke det, kunden spørger om, når skemaet nævner penetrationstest. Skriv, hvad I har, med det rigtige navn. → Scanning og pentest i samme spørgsmål

Kontrollen før skemaet sendes

En kort kontrol fanger mange problemer, før de bliver til løfter. Lad en anden end den, der har udfyldt skemaet, læse det igennem med disse spørgsmål:

Hvilket dokument viser det? · Hvert ja skal kunne kobles til en rapport, en politik, en log eller en procedure.
Gælder det hele produktet? · Eller kun et modul, en version eller en del af driften?
Gælder det i dag? · Er dokumentet aktuelt, eller beskriver det situationen for et år siden?
Siger svaret mere end dokumentet? · Er der tilføjet ord som altid, alle eller løbende?
Kan vi vise det, hvis kunden spørger? · Og må det deles?

Den, der kontrollerer, skal have mandat til at stoppe skemaet, også selv om fristen er tæt på. → Hvem i softwarehuset skal svare på sikkerhedsspørgsmål?

Mange spørgsmål kan ikke besvares sandt med ja eller nej. Brug kommentarfeltet til at sige, hvad der er opfyldt, hvad der ikke er, og hvad der er planlagt. Et delvist svar med en forklaring er lettere for kunden at arbejde med end et ja, der senere skal trækkes tilbage. → Ja, nej eller delvist

Hvis kunden kræver et ja for at gå videre, er det en forhandling og ikke et udfyldningsspørgsmål. Tag den åbent, og spørg, om kravet kan opfyldes på en anden måde eller inden for en aftalt frist. → Forhandling af sikkerhedskrav

Når et forkert svar allerede er sendt

Det sker, at I opdager et for stort svar efter afsendelse, fx når testen viser, at et modul ikke var med, eller når en kollega påpeger, at en proces ikke længere følges. Ret svaret over for kunden så hurtigt som muligt, og forklar kort, hvad der var forkert, og hvad der er det rigtige. Ret også svaret i jeres svarbibliotek, så fejlen ikke går videre til den næste kunde.

Hvis svaret indgår i en kontrakt, så inddrag den, der har ansvaret for kundeaftalerne, før I skriver til kunden. Der kan være behov for juridisk bistand til at vurdere, hvad rettelsen betyder.

Et tænkt eksempel

En sælger i et softwarehus med et system til kursustilmelding svarer ja til spørgsmålet “Penetrationstestes alle nye funktioner før udrulning?”. Udviklingschefen læser skemaet igennem før afsendelse og retter svaret: “Nye funktioner gennemgår automatiske sikkerhedskontroller og kodegennemgang før udrulning. Større funktioner, der ændrer adgangsstyring eller håndtering af kundedata, tages med i den næste eksterne penetrationstest eller testes særskilt før lancering. Seneste eksterne test blev gennemført i maj.” Svaret er længere, men hver sætning kan dokumenteres.

Det skal I lade være med

Gætte i den retning, kunden ønsker · Spørg den, der kender svaret.
Kalde andre aktiviteter for penetrationstest · Brug det rigtige navn.
Bruge altid, alle og løbende uden belæg · Skriv det konkrete i stedet.
Låne en leverandørs certificering · Skriv, hvem den tilhører.
Sende uden en anden persons kontrol · Fire øjne fanger de for store ord.
Lade et forkert svar stå · Ret det over for kunden og i biblioteket.

Hvad kan og ikke kan konkluderes

Svar, der kan dokumenteres, giver kunden et korrekt grundlag og beskytter jer mod at have lovet mere, end I kan holde. De gør ikke produktet mere sikkert og garanterer ikke, at kunden accepterer svarene. Hvilken betydning et forkert svar får i en konkret aftale, afhænger af aftalen og kræver i givet fald juridisk vurdering.