Scope i en penetrationstest: hvad skal testes, og hvad skal holdes ude?

En penetrationstest kan kun svare på det, scope beskriver. Er scope uklart, bliver rapporten uklar, og testeren risikerer at teste systemer, ingen havde lov til at give adgang til.

Scope er den skriftlige afgrænsning af opgaven: hvilke systemer, hvilke metoder, hvilket tidsrum og hvad der er udelukket. Den skrives før testen og bliver gengivet i rapporten.

Hvorfor scope er mere end en liste over adresser

Mange scope-beskrivelser består af en række IP-adresser og et domænenavn. Det er for lidt. En liste fortæller, hvad testeren må ramme. Den fortæller ikke, hvad I vil vide.

Et godt scope starter med et spørgsmål. “Kan en fremmed komme ind i vores kundeportal?” giver et andet scope end “kan en kunde se andre kunders data?”. Det første kræver en test udefra uden konto. Det andet kræver testkonti med forskellige roller. → Black box, grey box og white box

Spørgsmålet bestemmer også, hvornår testen er færdig. Uden spørgsmål er testen færdig, når tiden er brugt.

Ved en webshop kan ledelsen ønske svar om kundedata, mens driftsleverandøren forventer en test af serveren. Beskriv begge forventninger, og vælg det spørgsmål, opgaven faktisk skal besvare. Det gør bestillingen brugbar for både indkøber og tekniker.

Et klart mål gør også rapporten lettere at bedømme. Hvis spørgsmålet er adskillelsen mellem kunder i portalen, skal resultatet fortælle, om netop den adskillelse blev undersøgt. En generel formulering om god sikkerhed er ikke et svar på det aftalte spørgsmål.

Systemer, der er med

Beskriv systemerne, så der ikke er tvivl:

Navne og adresser · domæner, underdomæner, IP-adresser og adresserækker.
Applikationer · med adresse, version og de roller, der skal testes.
Interne netværk · hvilke segmenter, og hvorfra testen starter.
Trådløse netværk · hvilke netværksnavne og lokationer.
Cloudtjenester · hvilke konti, abonnementer eller lejemål.

Brug de samme navne, som står i jeres egen dokumentation. Så kan fundene bagefter føres tilbage til de rigtige systemer.

En kundeportal kan have både en offentlig del, en kundedel og en administrationsdel. Skriv, hvilke dele der er omfattet, og hvilke roller der indgår. At portalen har samme navn på tværs af delene, gør dem ikke automatisk til samme testopgave.

For et ERP-system bør systemejeren kunne genkende afdelingernes navne og funktioner i listen. Hvis økonomi og lager omtales forskelligt hos virksomheden og driftsleverandøren, så afklar navnene før bestillingen. Rapportens fund skal senere kunne fordeles uden en ny oversættelse af systemoversigten.

Det, der skal holdes ude

Skriv undtagelserne lige så tydeligt som de omfattede systemer. I en webshop kan betalingsudbyderens platform ligge uden for opgaven, selv om kunden møder den i samme købsforløb. Rapporten skal kunne vise grænsen uden at få hele købsforløbet til at fremstå undersøgt.

Andre parters systemer · eksempelvis betalingsudbyderens løsning, når den ikke er omfattet af tilladelsen.
Dele af produktionen · eksempelvis ERP-funktioner, som ikke indgår i den aftalte undersøgelse.
Påvirkning af driften · angiv, hvilke former for belastning og ændring af data opgaven ikke omfatter.
Oplysninger · afgræns, hvilke kundedata der må indgå som dokumentation.

Et fravalg skal ikke skjules i et bilag. Hvis økonomidelen af ERP-systemet holdes ude, bør bestillingen forklare, at testen ikke giver et svar om den del. Ledelsen kan så tage stilling til, om fravalget passer til formålet, eller om behovet kræver en anden opgave.

Undtagelserne bør også være forståelige for rapportens modtager. En kunde, der spørger til webshoppen, kan ellers læse tjenestens navn som dækning af både butikken og betalingen. Brug samme opdeling i bestilling og rapport. → Ekstern eller intern penetrationstest

Ejerskab og tilladelse

Scope skal kun omfatte den test, der er tilladelse til. Ved en kundeportal hos et hostingfirma er virksomhedens eget domænenavn ikke i sig selv en beskrivelse af rettighederne til hele platformen. Skeln mellem virksomhedens løsning og de ressourcer, andre råder over.

Straffelovens § 263, stk. 1 omhandler uberettiget adgang til en andens datasystem eller data. En scope-beskrivelse erstatter ikke afklaring af tilladelsen. For webshoppen skal den aftalte opgave derfor passe til det, virksomheden og relevante tredjeparter kan godkende.

Beskriv i scope, hvilke systemer tilladelsen omfatter. Den praktiske afklaring med hostingfirma og driftsleverandør er behandlet i → Før penetrationstesten. Her er det afgørende, at listen over omfattede systemer ikke rækker længere end det godkendte område.

Metoder og grænser

Scope bør beskrive den aftalte afprøvning uden at blive en teknisk arbejdsvejledning. For en kundeportal kan bestillingen afgrænse, om opgaven alene skal påvise en mulig fejl eller også dokumentere dens konsekvens. Det skal være forståeligt for den, der godkender undersøgelsen.

Formål · hvilke spørgsmål om eksempelvis kundernes adgang skal afprøvningen besvare?
Udgangspunkt · hvilke roller og hvilken adgang indgår i ERP-systemet?
Tilladt påvirkning · hvilke ændringer af testdata er omfattet, og hvilke er udelukket?
Medarbejdere og lokaler · indgår disse overhovedet, eller handler opgaven alene om de navngivne systemer?
Dokumentation · hvilke oplysninger fra webshoppen må bruges til at underbygge et fund?

Skriv også, hvad resultatet skal vise. Ved gæstenettet kan behovet være en vurdering af adskillelsen fra kontornettet. Det kræver en tydelig beskrivelse af de net, der indgår, og de begrænsninger, der gælder for undersøgelsen.

Vurdering af medarbejdere eller fysisk adgang skal fremgå særskilt, hvis det ønskes. En teknisk test af kundeportalen bør ikke kunne læses som en bestilling af en bredere undersøgelse af kundeservice. → Hackere og deres hatte

Tidsrum

Angiv datoer og klokkeslæt for den aftalte testperiode. Hvis webshoppen kun må undersøges i bestemte tidsrum, skal det fremgå af scope. En formulering som “i næste uge” er svær at bruge, når rapporten senere skal forklare, hvilken periode resultatet dækker.

Skeln mellem perioden for selve testen og fristen for rapporten. Ved et nyt ERP-system kan ledelsen have brug for resultatet før beslutningen om ibrugtagning. Scope bør gøre det muligt at se, om den planlagte aflevering passer til den beslutning.

Den praktiske planlægning omkring driftsleverandøren hører til forberedelsen. → Før penetrationstesten

Når scope skal ændres undervejs

Den praktiske håndtering hører til i → Før penetrationstesten.

Når rapporten om kundeportalen læses, skal det være muligt at se forskellen mellem den bestilte dækning og det, undersøgelsen faktisk omfattede. En liste med portalens navn er ikke tilstrækkelig, hvis kun kundedelen blev vurderet. Det er rapportens beskrivelse af den gennemførte undersøgelse, der afgør, hvilke spørgsmål resultatet besvarer.

Det skal I lade være med

At sætte “alt” i scope. Testen bliver bred og tynd, og ingen kan se, hvad der faktisk blev afprøvet.
At udelade det kritiske system for at undgå forstyrrelser. Det er ofte det, der burde testes.
At glemme leverandørens tilladelse. Hosting og SaaS ejes sjældent af jer.
At bruge andre navne end jeres egen dokumentation. Så kan fund ikke placeres.

En formulering som “test af hele webshoppen” kan dække over meget forskellige forventninger. Salg kan tænke på købsforløbet, IT på driften og en kunde på beskyttelsen af oplysninger. Skriv delene ud, så den brede formulering ikke bliver den eneste fælles forståelse af opgaven.

Hvad kan og ikke kan konkluderes

Et præcist scope gør det muligt at knytte rapportens fund til de systemer, forudsætninger og tidsrum, undersøgelsen dækkede. Den kan ikke sige noget om systemer uden for scope, og den kan ikke sige, at de er sikre.

Det er derfor, scope skal stå i rapporten. En læser, der kun ser fundene, kan tro, at hele organisationen er testet. Står scope tydeligt, ved læseren, hvad resultatet dækker. → Sådan læser I en pentestrapport

For et gæstenet kan et resultat om adskillelse fra kontornettet være vigtigt uden at være en vurdering af alle interne systemer. Læs konklusionen sammen med listen over net og de aftalte begrænsninger. En præcis afgrænsning gør svaret anvendeligt, men gør ikke undersøgelsen udtømmende.

Hvis en kunde efterspørger dokumentation om ERP-systemet, skal rapporten kunne vise, om netop det system var med. Et fund i webshoppen kan ikke bruges til at udfylde det hul. → Uafhængig penetrationstest

Tjekliste til scope

☐ Har vi formuleret det spørgsmål, testen skal besvare?
☐ Er alle systemer i scope beskrevet med navn, adresse og version?
☐ Er det skrevet, hvad der er uden for scope?
☐ Råder vi selv over alle systemer, eller har vi skriftlig tilladelse?
☐ Er metoder og grænser aftalt, også for udnyttelse og dataudtræk?
☐ Står testperioden med datoer og klokkeslæt?
☐ Er kontakt, stop og ændringer undervejs aftalt i forberedelsen?

Er scope en del af et krav fra en kunde, så tjek, hvad kunden forventer. Underleverandører med NIS2-krav fra en kunde finder mere på nis2-pentest.dk.

Prøv at læse beskrivelsen uden hjælp fra systemejeren. Ved en webshop skal en kollega kunne se, om både kundedelen og administrationen indgår. Hvis det kræver en mundtlig forklaring, bør teksten præciseres.