Sådan læser I en pentestrapport: fund, alvorlighed og det, rapporten ikke siger

En pentestrapport skal omsætte undersøgelsen til beslutninger om systemerne. Den skal kunne læses af ledelsen, der skal prioritere, og af IT, der skal rette, og den skal sige tydeligt, hvad den dækker, og hvad den ikke dækker.

Mange rapporter er lange. Det er ikke længden, der gør dem brugbare. Det er, om man hurtigt kan finde svaret på tre spørgsmål: hvad blev testet, hvad blev fundet, og hvad skal gøres først.

Rapportens opbygning

En god rapport har typisk de samme dele:

Resumé · til ledelsen, uden fagord.
Scope og metode · hvad der blev testet, hvordan og hvornår.
Fund · ét afsnit pr. fund med alvorlighed, beskrivelse og anbefaling.
Bilag · tekniske detaljer til dem, der skal rette.

Mangler en af delene, er det et spørgsmål værd at stille til den, der har lavet rapporten.

Ved en webshop skal ledelsen kunne finde betydningen for drift og kundedata, mens driftsleverandøren skal kunne finde de konkrete fund. Delene bør hænge sammen, så en anbefaling i resuméet kan føres tilbage til dokumentationen længere inde i rapporten.

Kontrollér også, hvilken version der er afleveret. Hvis rapporten om ERP-systemet findes i flere udgaver, skal modtagerne kunne se, hvilken der gælder. En senere forklaring eller rettelse bør ikke efterlade forskellige konklusioner hos systemejeren og driftsleverandøren.

Resuméet

Resuméet skal kunne læses på få minutter. Det bør sige, hvad testen skulle besvare, det samlede billede, de vigtigste fund og hvad der anbefales først. Det bør ikke gentage alle fund.

Et godt resumé er nøgternt. Ord som “kritisk” og “alvorligt” skal svare til fundene, ikke bruges for at skabe opmærksomhed. Står der, at sikkerheden er “god”, bør det fremgå, hvad det sammenlignes med.

For en kundeportal bør resuméet forklare, hvilke oplysninger eller funktioner de væsentligste fund berører. Det skal også vise, om undersøgelsen var begrænset til bestemte kundetyper. Ledelsen skal kunne forstå, hvad den skal tage stilling til, uden først at læse de tekniske bilag.

Skeln mellem vurdering og beslutning. Rapporten kan anbefale rettelser i webshoppen, men det er virksomhedens ansvar at vælge prioritering og acceptere eventuelle udeståender. Et resumé bør gøre det klart, hvilke spørgsmål der kræver en beslutning, frem for blot at beskrive sikkerheden med et samlet tillægsord.

Scope og metode

Afsnittet om scope er det, der oftest bliver sprunget over, og det er en fejl. Det fortæller, hvilke systemer der var med, hvilke der ikke var, hvilken periode testen kørte i, og hvor meget testeren fik at vide på forhånd. → Scope i en penetrationstest · Black box, grey box og white box

Uden det afsnit kan en læser tro, at hele organisationen er testet. Sender I rapporten videre til en kunde, er det afsnittet, kunden vil læse først.

Ved et ERP-system kan en test omfatte salgsafdelingen uden at omfatte økonomi. Rapporten bør vise den forskel, selv om begge dele bruger samme systemnavn. Kontroller også, om undersøgelsen gjaldt produktionen eller et testmiljø, og om væsentlige forskelle mellem miljøerne er beskrevet.

Sammenhold rapportens dækning med bestillingen. Hvis aftalen omfattede gæstenettet, men rapporten ikke siger noget om det, skal forskellen forklares. Manglende dokumentation for en del af opgaven bør ikke læses som et resultat uden fund. → Ekstern eller intern penetrationstest

Fundene

Hvert fund bør indeholde:

En titel, der siger, hvad problemet er.
Alvorlighed efter en skala, rapporten forklarer.
Hvilke systemer der er berørt.
En beskrivelse af, hvad fundet betyder for jer.
Dokumentation for, at fundet er reelt.
En anbefaling, der kan føres ud i livet.

Et fund kan være reelt, selv om anbefalingen mangler. Men køberen har brug for både underbygning og et forslag til håndtering. Spørg til manglerne, før rapporten om kundeportalen bruges som færdigt grundlag for opfølgningen.

Et fund i webshoppen bør kunne fordeles til den ansvarlige leverandør uden at miste sin sammenhæng. Systemnavn og berørte funktioner skal være præcise. Forklaringen skal vise forskellen mellem det, testeren faktisk dokumenterede, og mulige følger, som ikke blev afprøvet.

Hvis samme fejl omtales flere steder i ERP-systemet, så undersøg sammenhængen. Det kan være relevant at rette en fælles årsag frem for at behandle observationerne enkeltvis. Rapporten bør give nok oplysninger til, at systemejer og driftsleverandør kan afklare det sammen.

Alvorlighed

CVSS er en skala til at beskrive sårbarheders alvorlighed fra 0 til 10. FIRST angiver kategorierne ingen, lav, middel, høj og kritisk i CVSS v4.0-specifikationen. Ved fund i en kundeportal bør rapporten angive version, score og det anvendte beregningsgrundlag.

CVSS v4.0 skelner mellem grundlæggende egenskaber, trusselsforhold og miljøforhold. Skalaen kan derfor også inddrage oplysninger om det konkrete miljø. Spørg, hvad rapportens score omfatter. Et grundtal for en fejl i ERP-systemet er ikke nødvendigvis en fuld vurdering af virksomhedens risiko.

Brug alvorligheden sammen med betydningen for forretningen. En webshop med kundebestillinger kan kræve en anden prioritering end en afskærmet demonstrationsløsning. Det skal forklares, hvilke oplysninger og funktioner der berøres. En farve eller et tal er ikke nok til at beslutte, hvem der skal rette først.

Hvis driftsleverandøren er uenig i scoren på et portal-fund, så få begrundelsen frem. Skeln mellem uenighed om beregningen og uenighed om virksomhedens prioritet. Begge dele kan være relevante, men de besvarer forskellige spørgsmål.

Det, der virker

Rapporter fortæller ofte mest om det, der ikke virkede. Det, der faktisk holdt, er også værd at vide. Står der intet om det, så spørg. Det gør det lettere at se, hvor indsatsen ikke skal flyttes hen.

En rapport om gæstenettet kan beskrive, at den aftalte adskillelse holdt i de gennemførte undersøgelser. Det er en mere præcis oplysning end en generel konklusion om, at netværket er sikkert. Spørg, hvilke forhold observationen bygger på, og hvilke dele der ikke indgik.

I en kundeportal er “ingen fund” heller ikke det samme som en beskrivelse af fungerende kontroller. Se efter, om rapporten forklarer, hvilke roller og funktioner der blev undersøgt. Det hjælper jer med at skelne mellem gennemført arbejde uden påviste fejl og områder uden vurdering.

Prioritering

Rapporten giver et udgangspunkt, men prioriteringen er jeres. Spørg:

Hvilke fund berører de systemer, der betyder mest for forretningen?
Hvilke fund kan rettes hurtigt?
Hvilke kræver en leverandør, og hvem taler med leverandøren?
Hvilke fund accepterer vi bevidst, og hvem har besluttet det?

Fund, der bevidst ikke rettes, bør skrives ned med begrundelse. Så står det klart, at det er et valg og ikke en forglemmelse.

Ved ERP-systemet kan en rettelse kræve både systemejerens beslutning og driftsleverandørens arbejde. Sæt en ansvarlig på hvert fund, og markér afhængighederne. En opgave er ikke placeret, blot fordi rapporten er sendt til leverandøren.

En accepteret rest skal også kunne forklares senere. Hvis en rettelse i webshoppen udskydes, så notér begrundelse, beslutningstager og tidspunktet for en ny vurdering. Henvis til fundets betegnelse i rapporten, så ledelsen og IT taler om samme forhold.

Det skal I lade være med

At læse resuméet og lægge resten væk. IT skal bruge fundene, ikke resuméet.
At tælle fund som mål for sikkerhed. Færre fund kan betyde mindre scope.
At sammenligne rapporter med forskelligt scope eller metode som om de var ens.
At sende rapporten bredt. Den beskriver svagheder og skal behandles fortroligt.
At glemme opfølgningen. En rapport uden retest viser ikke, om noget er rettet.

Brug heller ikke rapporten om kundeportalen som et mærkat, der kan sendes videre uden forklaring. Modtageren skal kunne se formål, dækning og væsentlige udeståender. Et uddrag, som kun viser resuméets positive formuleringer, kan give et andet indtryk end den samlede rapport.

Hvad rapporten kan og ikke kan sige

Rapporten kan sige, hvad der blev fundet i det, der blev testet, med den metode og i den periode, der står i den. Den kan ikke sige, at systemerne er sikre, og den siger intet om systemer uden for scope.

Den kan heller ikke sige noget om tiden efter testen. Nye fejl bliver kendt, og systemer ændres. → Hvor ofte skal I teste?

Hvis driftsleverandøren oplyser, at et fund i webshoppen er rettet, er det en ny oplysning efter testen. Skeln mellem leverandørens tilbagemelding og resultatet af en senere kontrol. Den oprindelige rapport dokumenterer undersøgelsen på sit tidspunkt, ikke en rettelse, der endnu ikke var gennemført.

Tjekliste, når rapporten lander

☐ Står det tydeligt, hvad testen skulle besvare?
☐ Er scope, periode og metode beskrevet?
☐ Har hvert fund alvorlighed, dokumentation og anbefaling?
☐ Har nogen vurderet fundene i forhold til jeres egne systemer?
☐ Er det aftalt, hvem der retter hvad, og hvornår?
☐ Er fund, der ikke rettes, skrevet ned med begrundelse?
☐ Er der aftalt en retest?
☐ Er det besluttet, hvem rapporten må deles med?

Skal rapporten bruges over for en kunde, er der mere om det på pentestrapport.dk. Skal den forklares for bestyrelsen, se sikkerhedstesten.dk.

Brug tjeklisten på den konkrete levering. Ved ERP-systemet bør systemejeren og driftsleverandøren gennemgå svarene sammen, så uklare fund og manglende ansvar bliver afklaret, før rapporten lægges i arkivet.