Kunden krever sikkerhetstest, og dere har aldri hatt en

Den som sendte skjemaet har som regel ikke funnet på det selv. Vedkommende har et krav om å ha kontroll på leverandørene sine, fra egen ledelse, fra en revisor, fra en kunde lenger opp i kjeden eller fra regelverk, og skjemaet er måten den kontrollen dokumenteres på.

Det endrer hva dere skal levere. De trenger et svar de kan vise frem og stå for, ikke et perfekt svar. Et tydelig «nei, og slik håndterer vi det» er dokumenterbart. Et «ja» som ikke tåler ett oppfølgingsspørsmål er det ikke.

Det endrer også hvem dere kan spørre. Personen på den andre siden vil at dette skal bli ferdig. Å ta kontakt og spørre hva de er ute etter med spørsmål 17 blir nesten aldri oppfattet som svakhet. Det blir oppfattet som at noen faktisk leser.

Skjemaene ser forskjellige ut, men de spør om mye av det samme, fordi de stort sett bygger på de samme kontrollområdene. Noen kunder bruker ferdige skjemaer som er publisert åpent: CAIQ fra Cloud Security Alliance og SIG fra Shared Assessments er to av dem. Får dere et slikt, er hele spørsmålssettet tilgjengelig, og det er verdt å lese før dere begynner å svare.

Gruppene under er vår inndeling, ikke en gjengivelse av et bestemt skjema. De er satt opp etter kontrollområdene skjemaene pleier å følge, og dekker det meste av det som kommer.

Bak nesten hvert spørsmål ligger et enklere spørsmål. Finner dere det, blir svaret både lettere å skrive og lettere å stå for. Formuleringene under er illustrerende omskrivinger, ikke sitater fra et bestemt skjema.

Dette er spørsmålet folk sitter fast på, og det er der de dårlige valgene tas. To utveier finnes ikke. Å skrive ja er ingen av dem, fordi et svar i et skjema som regel følger med inn i kontrakten, og et uriktig svar der er noe helt annet enn en pinlig e-post. Å kjøpe en test i dag er heller ingen av dem, fordi fristen sjelden rekker.

Det som faktisk virker er å svare i tre deler: hva som er sant i dag, hva som skjer og når, og hva som gjør risikoen mindre i mellomtiden. Alle tre delene lar seg dokumentere, og ingen av dem krever at noe er ferdig.

Formulert som en mal, til å skrives om til deres egne forhold:

Det er det tredje punktet en kunde stikkprøvekontrollerer, og et oppdiktet svar der er verre enn ingen svar i det hele tatt. Skriv bare det dere faktisk gjør.

Har dere ingenting å sette inn, er det verdt å bruke et par dager på å få noe der før dere svarer. Tofaktor på alle administratorkontoer, en skriftlig oversikt over hvem som har tilgang til hva, og fjerning av kontoene til folk som sluttet i fjor er gjort på en ettermiddag, koster ingenting, og er ekte svar på tre av de vanligste spørsmålene i skjemaet.

Det samme gjelder rutiner. To avsnitt som beskriver det dere virkelig gjør er mer verdt enn tolv sider hentet fra en mal ingen følger. Kunden kan be om å få se rutinen. De kan også spørre den første utvikleren de møter om den stemmer.

Fem vedlegg som er raske å lage og som pleier å holde. Poenget med alle fem er det samme: de viser at noen har tenkt på dette, og at det finnes en ansvarlig med navn.

En sikkerhetsrapport i full lengde er en bruksanvisning for å komme inn hos dere. Den sier hvilke svakheter som finnes, hvor de er, og ofte hvordan de utnyttes steg for steg. Sender dere den til en kunde, vet dere ikke lenger hvor den ligger, hvem som har den, eller hvor lenge.

Sjekk kontrakten før dere sier nei. Enkelte norske leverandøravtaler inneholder en plikt til å gi kunden tilgang til revisjonsrapporter på forespørsel. Har dere signert noe slikt, er ikke dette lenger et spørsmål om hva som er lurt, og et avslag kan være et mislighold. Rådet under gjelder når dere står fritt.

Står dere fritt, er det verdt å spørre hvorfor. Noen ganger er svaret at skjemaet er skrevet for et annet slags leverandørforhold enn deres, og at et sammendrag holder fint. Det spørsmålet koster én e-post.

Blir kravet stående, be om tre ting skriftlig: hvem hos kunden som får dokumentet, hvordan det lagres, og at det ikke deles videre uten at dere vet om det. Vurder også å sende en versjon der åpne funn er beskrevet på funksjonsnivå og ikke som fremgangsmåte.

Er kunden en offentlig virksomhet, er det en grunn til her. Dokumenter som sendes inn i en offentlig anskaffelse kan bli gjenstand for innsyn, og en sårbarhetsrapport er det dokumentet dere minst av alt vil ha i den bunken. Det er behandlet nærmere på siden om sikkerhetskrav i anbud.

Kommer skjemaet fra én kunde, kommer det fra flere. Det er verdt å planlegge for med en gang, fordi det avgjør hva som er verdt å teste.

Skjemaet er skrevet av en kunde som kjenner sin egen risiko, ikke deres. Det spør om det som betyr noe for leveransen til dem.

Er den virkelige risikoen deres et internt system ingen kunde spør om, en gammel integrasjon eller en database med alt i, bør det testes uansett hva som står i regnearket. Å bruke hele testbudsjettet på å få et kryss i en rute er en dyr måte å ikke finne ut noe på.

To uker rekker som regel ikke til en levert rapport. Omfanget skal avtales og signeres, testen skal kjøres, og rapporten skal skrives. Det er verdt å vite før dere lover noe.

Det som rekker på to uker er å svare ærlig, å ha en plan med dato, og å rydde i det som lar seg rydde: tofaktor, gamle kontoer, hvem som har administratortilgang, og hva som ligger åpent på nett.

Og så det ingen tenker på: spør kunden om fristen for svaret og fristen for dokumentasjonen er den samme. Det er den ofte ikke. Skjemaet skal leveres nå, mens beviset skal foreligge før avtalen trer i kraft eller ved første gjennomgang.

Det finnes ingen norsk standard for hva et sikkerhetsskjema skal inneholde, og ingen for hva som er et akseptabelt svar. Det som står over er hva som erfaringsmessig fungerer, ikke en regel noen kan vise til.

Den eksterne sjekken leser det som er synlig utenfra og gir dere funnene med en gang, uten innlogging og uten e-postadresse.