Retest efter penetrationstest: hvad skal dokumenteres, før et fund kan afsluttes?

En besked om, at et fund er rettet, giver ikke i sig selv dokumentation for, at problemet er efterprøvet. En brugbar retest bygger på det oprindelige fund, den gennemførte ændring og en tydelig beskrivelse af, hvad kontrollen omfattede.

I et tænkt eksempel har en kundeportal fået et fund om adskillelsen mellem kunders oplysninger. Softwareleverandøren melder, at løsningen er ændret. Virksomheden skal nu vide, om ændringen er kontrolleret, hvilke funktioner kontrollen dækkede, og om noget stadig står åbent. Det er den opgave, retest skal afgrænses til.

Retest begynder med det oprindelige fund

Det oprindelige fund skal kunne genfindes uden tvivl. Brug rapportens betegnelse og henvis til den relevante udgave. En intern opgave med titlen “ret adgang” fortæller for lidt, hvis rapporten om kundeportalen beskriver flere forskellige forhold.

Saml også de oplysninger, der forklarer fundets rækkevidde. Det kan være den berørte funktion, den brugerrolle, der indgik, og den dokumenterede konsekvens. Retest bør knyttes til disse forhold, så en senere læser kan forstå sammenhængen mellem fund og kontrol.

Læs først, hvad rapporten faktisk siger. Et fund i webshoppen kan være beskrevet som et påvist problem eller som et forhold, der kræver yderligere afklaring. Opgaven bagefter skal passe til den beskrivelse. → Sådan læser I en pentestrapport

Hvilke fund skal efterprøves?

Beskriv de fund, som retesten skal omfatte. En opgave kan være begrænset til en konkret ændring i kundeportalen eller omfatte en samlet liste over rettelser. Ordet retest fortæller ikke alene, hvor bred kontrollen bliver.

Prioriteringen bør hænge sammen med fundenes betydning og virksomhedens næste beslutning. Hvis webshoppen skal åbne for kunder, kan dokumentationen for en bestemt rettelse være afgørende. Andre forhold kan have en anden tidsplan. Registrér valget, så det ikke ligner en forglemmelse i den afsluttende oversigt.

Skeln også mellem retest og en ny, bred undersøgelse. Hvis ERP-systemet har fået nye moduler siden den oprindelige test, kan der være behov, som rækker ud over de gamle fund. De behov skal beskrives særskilt. → Scope i en penetrationstest · → Hvor ofte skal I teste?

Hvornår er en rettelse klar til kontrol?

En ændring skal være til stede i det miljø, som efterprøvningen gælder. Ved kundeportalen kan en leverandør have rettet en udviklingsudgave, mens virksomheden forventer svar om produktionen. Få miljø og relevant udgave med i tilbagemeldingen om rettelsen.

Beskriv ændringen i almindelige ord. For bestilleren kan det være nok at vide, at adskillelsen af kundernes ordrehistorik er ændret, og at de berørte funktioner er klar til vurdering. Testeren skal have de nødvendige supplerende oplysninger til den aftalte kontrol.

Brug en fælles oversigt, hvor leverandøren kan markere, hvilke rettelser der er klar, og hvilke der afventer. Ved ERP-systemet gør det det muligt at bestille kontrol af en afgrænset del uden at fremstille alle fund som behandlet. Forberedelsen af adgang og drift beskrives i → Før penetrationstesten.

Hvad hvis forudsætningerne er anderledes?

Et resultat skal læses sammen med de forhold, kontrollen blev gennemført under. I kundeportalen kan en ændret rollefordeling betyde, at det oprindelige udgangspunkt ikke længere findes. Det er en oplysning, som skal fremgå, ikke et forhold der bør forsvinde bag en kort status.

Sammenlignelighed kræver ikke, at alt står stille. Men relevante forskelle skal være forklaret. Hvis en funktion i webshoppen er fjernet, skal dokumentationen sige, hvad der er konstateret om fjernelsen. En udgået funktion er en anden situation end en funktion, der stadig findes og er efterprøvet efter rettelse.

Hvis kontrollen sker i et andet miljø, skal betydningen kunne forstås. En rettelse på en kopi af ERP-systemet dokumenterer ikke alene den tilsvarende tilstand i driften. → Penetrationstest i produktion eller testmiljø

Resultatet skal sige mere end lukket

En kort status er nyttig i virksomhedens opgaveoversigt, men den bør have dokumentation bag sig. For et fund i kundeportalen skal læseren kunne se, hvad der blev efterprøvet, hvornår det skete, og hvad resultatet viste.

Brug eksempelvis beskrivelser som efterprøvet uden genfund af det beskrevne problem, fortsat påvist eller ikke muligt at vurdere under de givne forhold. Det er forslag til tydeligt sprog, ikke en fast standard, alle rapporter skal følge. Rapportens egne betegnelser skal være forklaret.

Et fund i webshoppen kan være meldt rettet af leverandøren uden endnu at være efterprøvet. Bevar den forskel i oversigten. Ellers kan projektlederen komme til at fremlægge en leverandørmelding som et testresultat. Knyt derfor den korte status til et dateret kontrolgrundlag frem for kun til en mail om ændringen.

Delvise rettelser og rester

En ændring kan løse en del af problemet uden at give et fuldt svar. I kundeportalen kan kontrollen eksempelvis omfatte den almindelige kundes funktioner, mens en særlig kundetype endnu ikke er vurderet. Det resterende spørgsmål bør stå tydeligt.

Skeln mellem, at en rettelse ikke virker, og at dækningen er begrænset. De kræver forskellige næste skridt. Hvis ERP-funktionen ikke kunne indgå i kontrollen, er et manglende genfund ikke et resultat om funktionen. Virksomheden skal kunne se, hvad der faktisk er undersøgt.

En begrænsning kan være acceptabel som led i en plan, men den bør ikke udtrykkes som en ubetinget afslutning. Skriv, hvad der mangler, og hvem der tager stilling til resten. Den oprindelige alvorlighed og den senere håndtering bør fortsat kunne følges i dokumentationen.

En løsning kan også være ændret på en anden måde end rapportens første anbefaling. Virksomheden kan eksempelvis have fjernet en funktion i portalen, som ikke længere er nødvendig. Så skal kontrollens spørgsmål passe til den valgte løsning. Den skal ikke uden forklaring beskrives som en bekræftelse af en anbefaling, der aldrig blev gennemført.

Hvis virksomheden bruger en midlertidig løsning i webshoppen, bør den senere plan fremgå af dens egen oversigt. Retestresultatet skal vise den tilstand, der blev undersøgt. Beslutningen om at beholde en midlertidig løsning og tidspunktet for at vurdere den igen er oplysninger, virksomheden selv må føre videre.

Hvem afslutter fundet hos virksomheden?

Testeren kan dokumentere resultatet af den aftalte kontrol. Virksomheden skal tage stilling til, om dokumentationen og eventuelle rester er tilstrækkelige til den beslutning, der venter. Ved en webshop kan det være projektets beslutning om åbning eller fortsat drift.

Adskil gerne rollerne i oversigten: hvem gennemførte ændringen, hvem efterprøvede den, og hvem godkendte håndteringen? Det gør et ERP-fund lettere at forstå senere. Hvis samme part både retter og vurderer, bør den rolle være synlig. → Uafhængig penetrationstest

NIST SP 800-115, afsnit 8.3 beskriver verifikation efter gennemførelse af forbedringer. For kundeportalen kan det omsættes til et praktisk krav i bestillingen: afslutningen skal kunne føres tilbage til den ændring og den kontrol, virksomheden baserer sin beslutning på.

Det skal I lade være med

At lade meldt rettet betyde efterprøvet. Leverandørens ændring af kundeportalen og en test af ændringen er forskellige oplysninger.
At bestille alle fund uden en liste. Udpeg de forhold i ERP-rapporten, som opgaven skal besvare.
At fjerne den oprindelige dokumentation. Retest af webshoppen skal kunne læses sammen med fundet, den følger op på.
At skjule manglende dækning. En kundetype, der ikke indgik, er fortsat et åbent spørgsmål.
At behandle retest som et nyt sikkerhedsstempel. Kontrollen dækker den aftalte opgave, ikke alle dele af løsningen.

Ved bestilling skal leverancen fremgå, også hvis kontrollen skal have sin egen aflevering. → Sammenlign tilbud på penetrationstest

Hvad kan og ikke kan konkluderes

En retest kan underbygge, om et bestemt problem fortsat blev påvist under de beskrevne forhold. Den kan ikke alene dokumentere, at kundeportalen er fri for andre fejl. Det kræver en anden og eventuelt bredere undersøgelse at besvare nye spørgsmål.

En rettelse, der er kontrolleret i testmiljøet, giver heller ikke i sig selv et svar om produktionen. For ERP-systemet skal det fremgå, hvilken udgave og hvilke funktioner konklusionen vedrører. En samlet projektstatus må ikke skjule den afgrænsning.

Virksomheden kan vælge at afslutte en opgave med kendte rester. Så bør afslutningen beskrive beslutningen og begrundelsen. Den skal ikke formuleres, som om testeren havde dokumenteret, at resterne var væk. Det er forskellen mellem resultatet af en kontrol og virksomhedens håndtering af resultatet.