Samme skema hvert år: hvad ændrer I i svarene?

Når kunden sender det samme sikkerhedsskema for andet eller tredje år, er det fristende at åbne sidste års fil, rette datoen og sende den retur. Men kunden bruger den årlige leverandørvurdering til at se, om noget har ændret sig, og et uændret svar er også et udsagn. Opdateringen hviler på to spørgsmål: hvad er sket i produktet og hos jer siden sidst, og hvilke svar bygger på dokumenter, der er blevet ældre?

Svarene om penetrationstest er blandt dem, der skal ændres. Testdatoen er ny eller burde være det, fundene har fået ny status, og omfanget kan være et andet. Det samme gælder svar om leverandører, hosting og organisation, hvis der er sket skift i løbet af året.

Start med sidste års svar, ikke med skemaet

Find det skema, kunden fik sidst, i den form det blev sendt. Det er det, kunden sammenligner med, og ikke den udgave, der ligger i jeres svarbibliotek i dag. Har I svaret anderledes til kunden end i biblioteket, fx fordi svaret blev tilpasset et særligt modul, skal den forskel med ind i årets svar.

Gem samtidig årets svar sammen med sidste års, så der findes en samlet historik pr. kunde. Giv også én person ansvaret for netop denne kundes skema år efter år. Når den samme person kender sidste års svar, de opfølgende spørgsmål og de løfter, der blev givet undervejs, bliver opdateringen hurtigere, og risikoen for, at et tilsagn fra sidste år bliver glemt, bliver mindre.

Læs derefter kundens nye skema igennem. Nogle kunder tilføjer spørgsmål hvert år, fjerner andre eller strammer ordlyden. Et spørgsmål, der før lød “Tester I produktet?”, kan nu lyde “Testes produktet af en uafhængig part mindst én gang årligt, og kan rapporten udleveres?”. Så er sidste års ja ikke længere et svar. → Sikkerhedsspørgeskema fra kunden

Det, der skal opdateres

Gå disse områder igennem, uanset om I tror, de har ændret sig:

Seneste test · dato, tester og omfang for den nyeste penetrationstest.
Status på fund · hvad er rettet og efterprøvet siden sidste svar, og hvad er stadig åbent.
Produktets omfang · nye moduler, integrationer eller API’er, som kunden bruger eller kan komme til at bruge.
Leverandører og hosting · nye eller udskiftede underleverandører og ændret placering af data.
Organisation og roller · ny sikkerhedsansvarlig, nye kontaktpersoner eller ændret ansvar.
Politikker og certificeringer · nye versioner, fornyede certifikater eller ophørte ordninger.

Hvert punkt skal holdes op mod dokumentationen. Et svar om testen skal passe med den rapport, kunden kan bede om. → Hvor ofte tester I?

Når testen ikke er nyere end sidst

Det sker, at årets skema kommer, før den nye test er gennemført. Så står kunden med et svar, der henviser til den samme rapport som sidste år. Det er ikke nødvendigvis et problem, men det skal fremgå tydeligt. Skriv datoen for den test, der er gennemført, og hvornår den næste er planlagt, og sig, om der er sket væsentlige ændringer i produktet siden.

Hvis kunden har et krav om, at rapporten skal være under et år gammel, er det her, det bliver synligt. Det er bedre at sige det selv end at lade kunden regne det ud. → Rapport under et år gammel

Vis kunden, hvad der er nyt

Kundens sikkerhedsfolk skal læse mange skemaer. Gør det let for dem at se forskellen fra sidste år. Nogle kunders portaler viser selv ændringerne. Hvis ikke, kan I vedlægge et kort følgebrev eller en note øverst i skemaet med de væsentligste ændringer:

Ny test · gennemført i februar, omfang udvidet med det nye rapportmodul.
Fund · de to fund, der var åbne ved sidste svar, er rettet og efterprøvet.
Leverandør · ny udbyder af mailudsendelse, oplyst i den vedlagte oversigt.
Kontakt · ny sikkerhedsansvarlig fra august.

En sådan oversigt er også nyttig for jer selv, og den kan gemmes i historikken for kunden. Den tvinger jer til at se på, hvad der faktisk er sket, i stedet for kun at rette datoer.

Svar, der er blevet for brede

Et år gammelt svar kan være blevet upræcist, uden at nogen har ændret det. Et svar om, at “alle ændringer testes”, kan have været rigtigt, da produktet var lille, men holder måske ikke, efter at udviklingsteamet er vokset, og der udgives hver uge. Læs derfor hvert svar med friske øjne, og spørg, om det stadig er sandt for hele produktet.

Hvis I opdager, at sidste års svar var forkert, så ret det i år, og overvej at sige det til kunden. En kort forklaring på, hvorfor svaret er anderledes, er bedre end at lade kunden selv opdage uoverensstemmelsen. → Svar, I ikke kan dokumentere

Et tænkt eksempel

Et softwarehus, der leverer et system til lønadministration, modtager det tredje årlige skema fra en større kunde. Sidste år var produktet testet i marts med to åbne fund af middel alvor. I år er en ny test gennemført i april, og den omfattede også det nye modul til udlæg, som kunden er begyndt at bruge. Begge gamle fund er rettet, og den nye test fandt ét nyt fund af lav alvor, som står på planen.

Softwarehuset opdaterer svarene om test og fund, tilføjer modulet til omfanget, opdaterer leverandøroversigten med en ny backupudbyder og skriver en kort note øverst med de fire ændringer. Resten af svarene gennemgås af deres ejere og bekræftes uændrede med ny dato.

Det skal I lade være med

Rette datoen og sende igen · Kunden læser ændringerne, også dem, der mangler.
Tage svarene fra biblioteket uden at se sidste års udgave · Kunden sammenligner med det, kunden fik.
Overse nye spørgsmål · Skemaet kan være strammet siden sidst.
Skjule, at testen er den samme som sidst · Skriv datoen, og sig, hvornår den næste kommer.
Lade et forkert svar stå · Ret det, og forklar ændringen.

Hvad kan og ikke kan konkluderes

Et omhyggeligt opdateret skema viser kunden, at I følger med i jeres eget produkt, og gør det let at se, hvad der er sket siden sidste vurdering. Det kan ikke erstatte en ny test, hvis kunden kræver en, og et uændret svar er kun rigtigt, hvis nogen har kontrolleret, at det stadig gælder. → Et årshjul for sikkerhedstest