Typer af penetrationstest: hvilken test svarer på jeres spørgsmål?

En forkert type penetrationstest kan give en grundig rapport uden at besvare virksomhedens egentlige spørgsmål. Valget bør derfor bygge på den situation, der skal undersøges, den adgang testeren må få, og den beslutning resultatet skal bruges til.

Betegnelserne ekstern, intern, webapplikation og trådløst net beskriver forskellige indgange til opgaven. De udelukker ikke altid hinanden. En kundeportal kan både være synlig fra internettet og have funktioner, som kræver brugeradgang. Et kontornet kan samtidig have et gæstenet, der skal behandles som et særskilt område.

Start derfor ikke med at vælge et navn fra en prisliste. Skriv først det spørgsmål, ledelsen eller projektejeren ønsker dokumenteret. Brug derefter testtypen til at gøre spørgsmålet bestilbart. → Scope i en penetrationstest

Begynd med situationen, ikke betegnelsen

Et praktisk udgangspunkt er at beskrive, hvor en uønsket adgang tænkes at begynde. Skal undersøgelsen tage udgangspunkt i internettet, en plads på kontornettet, en bruger i kundeportalen eller nærheden af det trådløse net? Svaret peger mod en type, men fastlægger endnu ikke hele opgaven.

Beskriv derefter det aktiv og den funktion, der har betydning. For webshoppen kan spørgsmålet handle om kunders konti og ordreoplysninger. For ERP-systemet kan det handle om adskillelsen mellem almindelige brugere og administrative roller. Det konkrete forretningsspørgsmål gør rapportens konklusion lettere at anvende.

Valget påvirkes også af den viden og adgang, testeren får. Det er et andet valg end selve testtypen. En ekstern test kan eksempelvis gennemføres med mere eller mindre forhåndsviden. → Black box, grey box og white box

Ekstern og intern test har forskellige udgangspunkter

En ekstern penetrationstest tager udgangspunkt i de systemer og tjenester, som virksomheden har aftalt skal vurderes udefra. Den kan være relevant, når spørgsmålet angår den eksponering, som en part uden for virksomhedens net kan møde. Det aftalte scope skal stadig navngive adresser, løsninger og undtagelser.

En intern test tager derimod udgangspunkt i en aftalt position inden for virksomhedens net. Det kan være relevant, når kontornettet skal vurderes med den forudsætning, at en enhed eller en bruger allerede befinder sig internt. Placeringen må beskrives præcist, fordi et gæstenet og et administrativt net ikke giver samme udgangspunkt.

Valget mellem de to er ikke en rangordning af grundighed. Det er et valg af perspektiv. Hvis begge situationer har betydning, kan de bestilles som adskilte dele med hver sit spørgsmål og resultat. Den mere udfoldede sammenligning findes i → Ekstern eller intern penetrationstest.

Webapplikationer og API’er kræver funktioner og roller

En test af en webapplikation retter sig mod den aftalte løsning, dens funktioner og de brugerroller, som indgår. For kundeportalen er det utilstrækkeligt alene at skrive portalens adresse. Bestillingen bør fortælle, om både kunder, medarbejdere og administrative roller skal indgå, og hvilke centrale handlinger der har betydning.

Et API kan være en del af samme opgave, hvis det understøtter portalen eller webshoppen. Det kan også afgrænses som sin egen del. OWASP beskriver webtest som et bredt område med blandt andet identitet, adgang og forretningslogik. Det betyder ikke, at enhver bestilling automatisk dækker alle emner i guiden. Dækningen skal stå i aftalen.

Integrationer til ERP-systemet og eksterne tjenester skal også placeres. Nogle kan undersøges, andre skal stå som undtagelser. Den detaljerede bestilling er behandlet i → Penetrationstest af webapplikationer.

Trådløse net skal knyttes til steder og net

En trådløs penetrationstest bør angive, hvilke net og hvilke fysiske områder der hører til opgaven. Virksomhedens medarbejdernet, gæstenet og andre trådløse forbindelser kan have forskellige formål og regler. En fælles betegnelse som trådløst net fortæller derfor for lidt.

For gæstenettet kan spørgsmålet være, om den aftalte adskillelse fra kontornettet er til stede under de beskrevne forhold. For medarbejdernettet kan spørgsmålet handle om den adgang, en godkendt testenhed får. Det er eksempler på bestillingsspørgsmål, ikke en teknisk opskrift på undersøgelsen.

Området omkring virksomhedens lokaler skal være afklaret, før opgaven begynder. NIST SP 800-115 behandler trådløs undersøgelse som et særskilt teknisk testområde og fremhæver samtidig planlægning og regler for gennemførelsen. Den konkrete tilladelse hører til forberedelsen. → Før penetrationstesten

Cloud og Microsoft 365 er et spørgsmål om afgrænsning

Ordet cloud beskriver ikke i sig selv en femte ensartet testtype. Et cloudmiljø kan rumme internetvendte tjenester, interne funktioner, identiteter og webapplikationer. Bestillingen bør derfor navngive de ressourcer og konfigurationer, som virksomheden råder over, samt de dele leverandøren ikke må undersøge.

Det samme gælder Microsoft 365. En formulering som test vores Microsoft 365 giver ikke et klart svar på, om opgaven vedrører identiteter, deling, administrative indstillinger eller en tilknyttet løsning. Vælg først det spørgsmål, der skal besvares. Afgræns derefter den adgang og dokumentation, som må anvendes.

Cloudleverandørens regler og ejerskabet til de enkelte ressourcer kan sætte yderligere rammer. De skal kontrolleres hos den relevante leverandør og i virksomhedens egne aftaler. Lovlighed og tredjepartsforhold behandles særskilt i → Er en penetrationstest lovlig?.

Mennesker og fysisk adgang kan være særskilte tillæg

Social engineering undersøger menneskelige situationer, og en fysisk vurdering kan handle om adgang til lokaler eller udstyr. De kan indgå i et bredere sikkerhedsprojekt, men bør ikke gemmes i en almindelig bestilling af penetrationstest. Deltagere, steder, data og stopkriterier kræver deres egen afgrænsning.

Et ønske om at undersøge kundeportalen giver eksempelvis ikke automatisk tilladelse til at kontakte medarbejdere. En test af kontornettet giver heller ikke i sig selv adgang til kontorer eller skabe. Sådanne udvidelser bør stå som særskilte aktiviteter med tydelig beslutning hos de ansvarlige.

Red teaming er tilsvarende et andet opgaveformat med et bredere mål og andre rammer. En kort introduktion findes på red-teaming.dk. Forskellen mellem forskellige aktørbetegnelser forklares i → Hackere og deres hatte.

Flere typer kan samles i én styret opgave

En virksomhed kan have behov for flere perspektiver uden at bestille en uafgrænset undersøgelse. Kundeportalen kan få en webapplikationstest, mens de internetvendte tjenester omkring den behandles i en ekstern del. Hver del bør have sit eget spørgsmål, sine egne aktiver og en synlig konklusion.

En samlet opgave kræver også en rækkefølge. Hvis et fund i den eksterne del ændrer forudsætningerne for en intern del, skal det være aftalt, hvordan opgaven fortsætter. Projektlederen bør kunne se, om rapporten samler resultaterne eller afleverer dem som adskilte vurderinger.

Beskriv desuden, hvilke dele der må dele forudsætninger. En testkonto til kundeportalen hører ikke nødvendigvis til den eksterne del, og en placering på kontornettet giver ikke automatisk adgang til ERP-systemet. Når adgangen skifter mellem delene, bør rapporten vise det. Ellers kan en læser få indtryk af, at alle resultater blev opnået fra samme udgangspunkt.

Leverancerne kan godt samles i én rapport, hvis opdelingen stadig kan genfindes. Et fælles resumé bør angive, hvilke spørgsmål der blev besvaret, og hvilke der stod åbne. De tekniske afsnit bør knytte hvert fund til den relevante del. Det hjælper virksomheden med at sende opgaven videre til den rigtige systemejer uden at gøre konklusionen bredere end grundlaget.

Miljøvalget er en selvstændig beslutning. En webtest i et testmiljø og en ekstern vurdering af produktionen kan ikke uden forklaring lægges sammen til én konklusion. → Penetrationstest i produktion eller testmiljø

På penetration-test.dk findes en supplerende introduktion til bestilling. Brug den som baggrund, mens det konkrete scope fortsat skrives til jeres egen løsning.

Det skal I lade være med

At vælge den bredeste etiket uden et spørgsmål · En stor overskrift giver ikke nødvendigvis et relevant svar om webshoppen.
At lade ekstern betyde alt på internettet · De konkrete tjenester og adresser skal være aftalt.
At kalde hele cloudmiljøet én løsning · Navngiv de ressourcer, konti og funktioner, der hører til opgaven.
At blande gæstenet og kontornet sammen · De kan give forskellige udgangspunkter og bør beskrives hver for sig.
At gemme kontakt til medarbejdere i småt · Mennesker og fysisk adgang skal have særskilt tilladelse og ramme.
At forveksle flere testtyper med fuld dækning · Hver del har fortsat begrænsninger, som rapporten skal vise.

Sammenlign kun tilbud, når opgavebeskrivelsen er den samme. Ellers kan en prisforskel dække over forskellige spørgsmål. → Sammenlign tilbud på penetrationstest

Hvad kan og ikke kan konkluderes

Den valgte testtype kan gøre udgangspunktet for undersøgelsen tydeligt. En ekstern test kan dokumentere resultater fra den aftalte position udenfor, mens en intern test kan belyse den beskrevne position på kontornettet. Ingen af betegnelserne dokumenterer alene, at alle virksomhedens systemer er undersøgt.

En webapplikationstest kan give et grundlag for at vurdere de funktioner og roller, der indgik. Den kan ikke uden videre bruges som konklusion om integrationer, cloudkonti eller trådløse net, som var uden for scope. Det samme princip gælder den anden vej.

Rapporten skal læses sammen med scope, forudsætninger og undtagelser. Først dér kan modtageren se, hvilket spørgsmål testen faktisk besvarede. → Sådan læser I en pentestrapport

Tjekliste til valg af testtype

☐ Er det spørgsmål, virksomheden skal have besvaret, skrevet i almindeligt sprog?
☐ Er udgangspunktet internet, internt net, brugerrolle eller trådløst område?
☐ Er systemer, funktioner, net og relevante steder navngivet?
☐ Er webroller, API’er og integrationer placeret i eller uden for scope?
☐ Er cloudressourcer og leverandørens regler afklaret særskilt?
☐ Er social engineering og fysisk adgang behandlet som egne tillæg?
☐ Har hver testdel en leverance, som kan genfindes i rapporten?
☐ Er det aftalt, hvordan flere testtyper påvirker hinanden?

Kilder

NIST SP 800-115, kapitel 6 og 7: planlægning og forskellige tekniske undersøgelsesområder.
OWASP Web Security Testing Guide: faglig ramme for testområder i webapplikationer.

Senest gennemgået: oktober 2026.