Restrisiko: det, der står tilbage efter testen

Når rapporten er læst og de første rettelser er lavet, er sikkerheden ikke færdigbehandlet. Restrisikoen består af to dele: de områder, testen aldrig så på, og de fund, der stadig står åbne efter opfølgningen.

Begge dele er normale. En penetrationstest er afgrænset i tid, omfang og udgangspunkt, og ikke alle fund kan eller skal rettes med det samme. Problemet opstår først, når resten ikke er beskrevet. Så kan en ledelse tro, at testen har lukket et spørgsmål, som den kun har belyst delvist.

To slags rest: det uprøvede og det urettede

Det uprøvede er alt det, der lå uden for opgaven. Hvis testen omfattede kundeportalen, men ikke den integration, der sender ordrer videre til ERP-systemet, siger rapporten intet om integrationen. Det er ikke en fejl i testen. Det er en følge af scope, og det skal stå synligt.

Det urettede er de fund, testen faktisk påviste, men som virksomheden endnu ikke har lukket. Nogle venter på en leverandør. Andre er nedprioriteret, fordi konsekvensen vurderes som lille. Et tredje sæt kan være udskudt til en større ombygning.

Hold de to slags adskilt. De kræver forskellige beslutninger: det uprøvede kan føre til en ny test, mens det urettede kræver en plan eller en accept. → Scope i en penetrationstest

Find resten i rapporten

Rapporten indeholder normalt de oplysninger, der skal til for at beskrive restrisikoen. Afsnittet om omfang og afgrænsning viser, hvad der indgik. Forudsætningerne viser, hvilke konti, roller og miljøer testeren brugte. Begrænsningerne viser, hvad der ikke kunne gennemføres som planlagt.

Læs de tre afsnit sammen. En webshop kan være testet med en almindelig kundekonto, mens administratorrollen ikke indgik. En del af kontornettet kan have været utilgængelig på testdagen. Hver af den slags oplysninger er en del af resten, selv om den ikke står under overskriften fund. → Sådan læser I en pentestrapport

Fundlisten giver den anden halvdel. Markér for hvert fund, om det er rettet og efterprøvet, rettet uden efterprøvning, planlagt eller ikke håndteret.

Restrisiko er ikke et tal

Det er fristende at sammenfatte resten i én score eller en farve. Det skjuler mere, end det viser. Et lavt antal åbne fund siger ikke noget om de systemer, der aldrig blev testet, og en samlet farve gør det svært at se, hvilket system der bærer resten.

Beskriv i stedet resten i almindelige ord. Hvad står åbent, hvilket system og hvilke oplysninger berører det, og hvem ejer spørgsmålet? En kort beskrivelse af hvert punkt er lettere at tage stilling til end en samlet vurdering, som ingen kan efterprøve.

Skeln også mellem rest, der er kendt, og rest, der blot er antaget. At gæstenettet ikke indgik, er en kendt oplysning. At det formentlig er i orden, fordi det blev sat op af driftsleverandøren, er en antagelse. Skriv antagelser som antagelser, så de kan blive afprøvet senere.

Hvem bærer resten?

Testeren kan beskrive, hvad der blev undersøgt og fundet. Det er virksomheden, der beslutter, hvad der er acceptabelt at leve med. Den beslutning hører hos den, der har ansvaret for systemet og for de oplysninger, det behandler.

For ERP-systemet kan det være økonomichefen sammen med IT-ansvarlig. For kundeportalen kan det være den forretningsansvarlige. Driftsleverandøren eller hostingfirmaet kan bidrage med vurderinger, men kan ikke på virksomhedens vegne beslutte, at en rest er i orden.

Når et urettet fund bevidst får lov at stå, er det en risikoaccept. Den bør være skriftlig, have en begrundelse og en dato for ny vurdering. → Risikoaccept efter penetrationstest

Fortæl om resten, når resultatet deles

Restrisikoen skal med, når resultatet bliver fortalt videre. Hvis ledelsen får at vide, at kundeportalen er testet, men ikke hører, at integrationen til ERP-systemet lå udenfor, bliver beslutningsgrundlaget skævt. Det samme gælder, når en kunde beder om dokumentation for testen.

Skriv derfor et kort afsnit om resten, hver gang resultatet sammenfattes. Det behøver ikke at gentage fundene i detaljer. Det skal fortælle, hvilke systemer testen omfattede, hvilke væsentlige dele der ikke indgik, og om der står fund åbne, som har betydning for modtagerens spørgsmål.

Formuleringen skal være præcis uden at afsløre mere end nødvendigt. En kunde har sjældent brug for en beskrivelse af et åbent fund, men kan have brug for at vide, at det findes, og at der er en plan for det. Aftal internt, hvem der godkender den slags tekster, før de sendes. Gem den udgave, der blev sendt, sammen med rapporten, så I senere kan se, hvad modtageren fik at vide.

Hold oversigten levende

Restrisiko ændrer sig. Et fund kan blive rettet, en leverandør kan komme med en opdatering, og et nyt modul kan gøre en gammel afgrænsning forkert. En oversigt, der kun blev skrevet den dag rapporten kom, bliver hurtigt misvisende.

Knyt oversigten til den handlingsplan, I alligevel fører efter testen. Så kan hvert punkt følges med status, ansvarlig og næste dato. Når der planlægges en ny test, er oversigten også et naturligt udgangspunkt for scope: de uprøvede områder kan komme med, og de urettede fund kan efterprøves. → Handlingsplan efter penetrationstest · → Retest efter penetrationstest

Det skal I lade være med

At sige, at testen er bestået · En test afleverer resultater under bestemte forudsætninger, ikke en godkendelse.
At glemme det uprøvede · Systemer uden for scope er en del af resten, også når de ikke nævnes i fundlisten.
At lade udskudte fund forsvinde · Et fund, der venter på en leverandør, skal stå i oversigten, til det er håndteret.
At samle alt i én score · Ledelsen skal kunne se, hvilke systemer og oplysninger resten handler om.
At lade leverandøren acceptere på jeres vegne · Beslutningen om at leve med en rest hører hos systemets ejer.
At lade oversigten stå stille · Ændringer i webshoppen eller ERP-systemet kan flytte resten.

Hvad kan og ikke kan konkluderes

En beskrevet restrisiko viser, hvad virksomheden ved er åbent efter testen, og hvad testen ikke dækkede. Den gør det muligt at træffe en bevidst beslutning om næste skridt.

Den kan ikke vise, at alt uden for oversigten er i orden. Ukendte svagheder i de testede systemer kan stadig findes, og en test er et øjebliksbillede af forholdene på testtidspunktet. Oversigten er et arbejdsredskab, ikke en erklæring om sikkerhedsniveauet. → Penetrationstest er ingen garanti