Leverandøren siger, at alt er sikkert: sådan kontrollerer I det

Et kort svar om, at systemet er sikkert, siger mest om leverandørens egen opfattelse. Om det holder, afhænger af, hvad svaret bygger på: hvem der har undersøgt hvad, hvornår, og om resultatet kan forelægges i en form, virksomheden selv kan vurdere.

Kontrollen består derfor af to trin. Først beder I om det grundlag, udsagnet hviler på, og læser det kritisk. Dernæst vurderer I, om grundlaget er tilstrækkeligt til den beslutning, I skal træffe, eller om der er brug for en test, som virksomheden selv bestiller. Tillid til en leverandør kan sagtens være berettiget, men den bør kunne begrundes.

Et udsagn er ikke et testresultat

Sætninger som vi følger best practice eller vores løsning er testet giver ingen oplysning om omfang, metode eller resultat. De kan være sande, men læseren kan ikke se, hvilke dele af løsningen der er undersøgt, og om fundene er håndteret.

Forskellen bliver tydelig, når virksomheden selv skal stå til ansvar. Hvis en kunde, en revisor eller bestyrelsen spørger, hvordan kundeportalen er sikret, er det svært at henvise til en mail fra leverandøren. Det er lettere at henvise til et dokument, der beskriver en afgrænset undersøgelse og dens konklusion.

Det samme gælder driftsleverandøren, der passer kontornettet og serverne. Et udsagn om, at firewallen er sat korrekt op, og at opdateringer installeres, beskriver en hensigt. Det siger ikke, om nogen uden for driften har set efter. Spørgsmålet er ikke, om leverandøren er til at stole på, men om virksomheden kan vise, hvorfor den stoler på leverandøren.

Tag også højde for, at leverandøren har en interesse i svaret. Det gør ikke svaret forkert, men det er en grund til at ønske et grundlag, som ikke alene kommer fra den part, der skal vurderes. Den tanke er kernen i ønsket om dokumentation fra en part uden binding til løsningen.

Bed om grundlaget, ikke om en ny forsikring

Et konkret spørgsmål giver et mere brugbart svar end et generelt. Bed om de oplysninger, der gør det muligt at vurdere udsagnet:

Hvad blev undersøgt · hvilke systemer, funktioner og miljøer indgik, og hvad var udeladt.
Hvem undersøgte det · en intern funktion hos leverandøren eller en ekstern part uden binding til løsningen.
Hvornår · datoen for undersøgelsen og den version af løsningen, den gjaldt.
Hvad blev fundet · i det mindste et resumé og en oplysning om, hvordan alvorlige fund er håndteret.
Hvad blev efterprøvet · om rettelserne er kontrolleret bagefter, eller kun meldt lukket.

En leverandør vil ikke altid dele hele rapporten, og det kan der være gode grunde til. Et resumé eller en testerklæring kan være tilstrækkeligt, hvis det besvarer spørgsmålene ovenfor. → Testerklæring: hvad den kan dokumentere

Læs dokumentationen med jeres eget spørgsmål for øje

En rapport om leverandørens platform kan være grundig og alligevel ikke dække den del, virksomheden bruger. Hvis rapporten handler om standardløsningen, mens virksomheden har fået tilpasninger, særlige integrationer eller egne roller, står de dele ofte uden for konklusionen.

Sammenlign derfor rapportens afgrænsning med jeres egen brug. Gælder den samme miljø, som jeres data ligger i? Indgik de roller, jeres medarbejdere og kunder har? Er integrationen til ERP-systemet nævnt? Hvor svaret er nej, er der et hul mellem leverandørens dokumentation og jeres behov. → Sådan læser I en pentestrapport

Alderen tæller også. En undersøgelse fra før en større opdatering siger mindre om den nuværende udgave. → Rapportens alder

Hvornår giver en uafhængig test mening?

Når leverandørens dokumentation ikke slår til, kan virksomheden overveje at bestille en test selv. Det er især relevant, når løsningen behandler følsomme oplysninger, når virksomheden har egne tilpasninger, eller når en kunde eller en standard forventer dokumentation, som virksomheden kan stå inde for.

Uafhængigheden handler om, at den, der tester, ikke har bygget, driver eller sælger løsningen. Hvorfor det betyder noget, og hvordan det spørges ind til, er beskrevet i → Uafhængig penetrationstest.

En test fra virksomhedens side kræver leverandørens tilladelse, når systemet drives eller ejes af leverandøren. Hostingfirmaet eller udbyderen af en standardløsning kan have regler for, hvad kunder må teste, og hvornår. Afklar dem, før opgaven bestilles, og få accepten på skrift.

Skriv retten til dokumentation ind i aftalen

Den bedste tid til at sikre adgang til dokumentation er, før kontrakten underskrives. Det kan aftales, at leverandøren med jævne mellemrum fremlægger et resumé af sine sikkerhedstest, at kunden må lade udføre en test efter forudgående varsel, og at alvorlige fund i den del, kunden bruger, bliver meddelt.

Ved eksisterende aftaler kan spørgsmålet tages op ved næste forlængelse eller ved en større ændring. Det er ikke juridisk rådgivning, og aftalens konkrete formulering bør vurderes af den, der normalt varetager virksomhedens kontrakter. → Kontrakten om penetrationstest

Når leverandøren afviser at dele noget

Et afslag behøver ikke betyde, at noget er galt. Det kan skyldes fortrolighed over for andre kunder eller frygt for, at detaljer om svagheder spredes. Spørg i så fald, hvad leverandøren kan dele, og om en fortrolighedsaftale ændrer svaret.

Hvis leverandøren hverken vil dele et resumé, svare på konkrete spørgsmål eller tillade en test, er det en oplysning i sig selv. Virksomheden må så vurdere, om den kan leve med usikkerheden, og skrive den vurdering ned. Det er en risikobeslutning, som hører til hos ledelsen og ikke hos IT-afdelingen alene.

Det skal I lade være med

At nøjes med en mundtlig forsikring · bed om et skriftligt grundlag, der kan vurderes.
At læse leverandørens rapport som jeres egen · den dækker leverandørens afgrænsning, ikke nødvendigvis jeres brug.
At teste leverandørens system uden tilladelse · det kan være i strid med aftalen og med loven.
At acceptere en gammel undersøgelse uden spørgsmål · tjek datoen og den version, den gjaldt.
At lade afslag passere uden notat · skriv ned, hvad der blev bedt om, og hvad der blev svaret.

Hvad kan og ikke kan konkluderes

Leverandørens dokumentation kan underbygge, at de undersøgte dele af løsningen var i en bestemt tilstand på det tidspunkt, undersøgelsen blev gennemført. Den kan ikke uden videre overføres til jeres tilpasninger, jeres data eller en senere version.

En uafhængig test kan give virksomheden et eget grundlag for den del, der blev testet. Den fjerner ikke behovet for løbende at følge leverandørens håndtering af sikkerheden.