Penetrationtest

Sammenlign tilbud på penetrationstest: omfang, dokumentation og ansvar

Sammenlign tilbud på penetrationstest: omfang, dokumentation og ansvar

Tilbud på en penetrationstest kan ligne hinanden, selv om de giver virksomheden forskellige svar. En brugbar sammenligning kræver samme opgavebeskrivelse og en tydelig opdeling af dækning, forudsætninger og leverancer.

En indkøber kan eksempelvis modtage tilbud på den samme kundeportal. Det ene omfatter den offentlige del, mens det andet også beskriver kundernes funktioner efter login. Begge bruger ordet penetrationstest. Før virksomheden vælger, skal det være klart, om forskellen skyldes opgaven, den planlagte indsats eller det materiale, der afleveres.

Brug samme spørgsmål i alle tilbud

Skriv det spørgsmål, virksomheden skal have besvaret, før tilbuddene vurderes. For kundeportalen kan det være, om kunder og medarbejdere har den tilsigtede adgang til oplysninger. Spørgsmålet skal kunne genfindes i leverandørens beskrivelse af opgaven.

En fælles bestilling bør også angive systemer, ønskede roller og væsentlige fravalg. Ellers kan hver tilbudsgiver have udfyldt hullerne forskelligt. Det er ikke nødvendigvis en fejl fra leverandørens side, men det gør sammenligningen usikker. → Scope i en penetrationstest

Når noget er uafklaret, så markér det som et spørgsmål. I et ERP-projekt kan det være, om økonomiafdelingens funktioner er med. Undgå at føre et ubeskrevet område ind som inkluderet i jeres egen oversigt. Afklaringen skal komme fra den, der skal levere undersøgelsen.

Sammenlign funktioner og brugerroller

Kontrollér, hvilke dele af løsningen hvert tilbud dækker. En kundeportal kan omfatte almindelige kunder, særlige kundeaftaler og medarbejdernes administration. Et tilbud med ordet hele portalen skal stadig forklare, hvad der indgår i praksis.

Gennemgå også forbindelser til andre systemer. Hvis webshoppen bruger oplysninger fra ERP-systemet, bør tilbuddet fortælle, hvordan integrationen er afgrænset i opgaven. En omtale af webapplikationen er ikke automatisk en beskrivelse af alle dens forbindelser. → Penetrationstest af webapplikationer

Hold startposition og forhåndsviden adskilt fra dækningen. En kundeportal kan undersøges med forskellig adgang og forskellige oplysninger. Sammenlign derfor de beskrevne forudsætninger, ikke kun black box eller grey box som etiketter. → Black box, grey box og white box

Hvad består den planlagte indsats af?

Et tilbud bør forklare undersøgelsens karakter, så køberen kan forstå, hvad der forventes dokumenteret. Ved et gæstenet kan der være forskel på en gennemgang af indstillinger og en aftalt praktisk afprøvning. Det er to forskellige grundlag for et svar.

Spørg også til forholdet mellem automatiseret arbejde og testerens faglige vurdering. Betegnelserne siger ikke alene, hvor dækkende leverancen bliver. For webshoppen er det relevant at vide, hvordan observationer bliver vurderet og knyttet til de funktioner og kundetyper, der er aftalt. → Automatisk eller manuel penetrationstest

En formulering om manuel test bør heller ikke stå alene som kvalitetsbevis. Tilbuddet skal fortsat beskrive prioritering, begrænsninger og dokumentation. Vurder indholdet i forhold til formålet. → Sårbarhedsscanning, sikkerhedstjek eller penetrationstest?

Den relevante indsats kan desuden afhænge af miljøet. Et tilbud på en kopi af kundeportalen skal kunne skelnes fra en undersøgelse i driften. → Penetrationstest i produktion eller testmiljø

Kvalifikationer skal passe til opgaven

Undersøg, hvem der skal udføre og fagligt gennemgå arbejdet. I en opgave om en kundeportal er relevant erfaring med webbaserede løsninger og brugerroller et mere konkret spørgsmål end et generelt udsagn om mange års sikkerhedsarbejde.

Ved henvisninger til certificering bør det fremgå, hvem eller hvad henvisningen gælder. Er det den person, der skal teste, firmaet eller en bestemt ordning? Spørg, hvad dokumentationen siger om den konkrete opgave. Et logo på tilbuddet bør ikke erstatte en forklaring af den relevante kompetence. → Krav til penetrationstesteren

Roller og interesser skal også være synlige. Hvis tilbudsgiveren har været med til at bygge ERP-løsningen, er det et forhold, som køberen bør kende. Den nærmere vurdering findes i → Uafhængig penetrationstest.

Forberedelsen bør desuden passe til driftsleverandørens og systemejerens bidrag. De praktiske aftaler behandles i → Før penetrationstesten.

Afleveringen skal være beskrevet

Se efter, hvilket materiale virksomheden modtager. For webshoppen kan behovet være et forståeligt resumé og fund med tilstrækkelig dokumentation til, at driftsleverandøren kan behandle dem. Tilbuddet bør forklare, hvordan rapporten viser dækning og væsentlige begrænsninger.

En rapport og et møde om rapporten er særskilte leverancer. Hvis projektlederen skal have hjælp til at forstå udeståender før åbningen, bør en gennemgang fremgå. Afklar også, hvordan spørgsmål til det afleverede materiale behandles, så virksomhedens forventning er tydelig.

Sammenlign den ønskede dokumentation med modtagerens behov. En kunde kan have andre forventninger end virksomhedens egen IT-afdeling. Rapportens anvendelse og deling skal derfor være afklaret i aftalen. → Sådan læser I en pentestrapport

Retest skal kunne findes som en leverance

Kontrol af rettelser kan være omfattet af et tilbud eller kræve en særskilt opgave. Læs, hvilke fund en eventuel retest gælder, og hvilken dokumentation der følger. Ordet opfølgning alene fortæller ikke, hvad der bliver efterprøvet.

I et ERP-projekt kan nogle rettelser være klar, mens andre afventer en senere udgave. Hvis tilbuddet har en afgrænset mulighed for retest, skal denne betingelse være forståelig. Virksomhedens plan bør ikke bygge på en kontrol, som leverandøren ikke har beskrevet.

Skeln mellem spørgsmål efter rapportens aflevering og en ny undersøgelse af ændringer. En forklaring af et fund i kundeportalen er en anden opgave end at efterprøve en rettelse. Begge dele kan være relevante, men skal kunne genkendes hver for sig. → Retest efter penetrationstest

Et tænkt eksempel med forskellige tilbud

Forestil jer en kundeportal med kundeadgang og administration. Virksomheden har sendt samme korte beskrivelse til forskellige tilbudsgivere. I sammenligningen kan følgende forskelle komme frem:

  • Tilbud med afgrænset adgang · den offentlige del undersøges, og der afleveres en rapport. Kundernes funktioner efter login er ikke beskrevet.
  • Tilbud med flere roller · kunde- og medarbejderadgang indgår, og der er beskrevet rapportgennemgang og kontrol af udvalgte rettelser.

Eksemplet viser en forskel i leverancen, ikke en rangering af leverandører. Hvis virksomheden alene skal have vurderet den offentlige del, kan en afgrænset opgave være relevant. Hvis spørgsmålet handler om kundeadskillelse, mangler det første tilbud en afklaring af netop den del.

Brug derfor forskellene til at stille konkrete spørgsmål. Notér for hvert område, om det er inkluderet, udeladt eller ikke afklaret. Først derefter kan beslutningen begrundes ud fra det behov, virksomheden faktisk har. Den videre plan beskrives i → Penetrationstest fra start til slut.

Lad tilbudsgiverne kontrollere jeres gengivelse af deres leverancer. I ERP-projektet kan et bilag eksempelvis forklare en undtagelse, som indkøberen ikke har fået med i oversigten. Spørg konkret til forskellen, og gem svaret sammen med tilbuddet. Formålet er en retvisende sammenligning, ikke at gøre alle leverandørernes beskrivelser ens.

Et tilvalg skal også stå som et tilvalg. Hvis rapportgennemgang for kundeportalen kræver en særskilt aftale, bør den ikke stå som en del af grundopgaven i beslutningsmaterialet. Gør det synligt, hvilke dele virksomheden faktisk vælger, så den endelige bestilling svarer til den løsning, der blev vurderet.

Det skal I lade være med

  • At tælle sider i tilbuddet som kvalitet. Kundeportalens relevante funktioner kan stadig mangle i en lang beskrivelse.
  • At ligestille ubeskrevet med inkluderet. Økonomirollen i ERP-systemet skal fremgå, hvis den er nødvendig for svaret.
  • At bruge et certifikat som hele vurderingen. Afklar den konkrete bemanding og relevante erfaring.
  • At overse fravalg i afleveringen. En webshoprapport kan være begrænset til bestemte funktioner eller kundetyper.
  • At antage, at opfølgning betyder retest. Find den beskrevne kontrol og dokumentation i tilbuddet.

Lad heller ikke krav om en standard erstatte opgavebeskrivelsen. Hvis en kunde har bestemte forventninger til portalens dokumentation, skal forventningerne være forklaret, før tilbuddene bruges til en beslutning.

Hvad kan og ikke kan konkluderes

En systematisk sammenligning kan vise, hvordan tilbuddene beskriver forskellige opgaver og leverancer. Den kan ikke alene dokumentere, hvor grundigt en kommende test af kundeportalen bliver udført. Den faktiske gennemførelse skal stadig vurderes ud fra rapport og øvrig aftalt dokumentation.

En manglende oplysning behøver heller ikke betyde, at leverandøren ikke kan levere den ønskede del. Den viser, at forholdet endnu ikke er afklaret. For ERP-systemet bør en uafklaret rolle derfor føre til et spørgsmål, før tilbuddet bliver vurderet på et forkert grundlag.

NIST SP 800-115, afsnit 6.4.1 og 6.5 behandler kompetencer og testplan. Brug disse som fagligt grundlag for at spørge til opgaven. De er ikke en garanti for en bestemt leverandørs kvalitet eller en beskrivelse af Nielco ITs faste vilkår.

Tjekliste før I vælger tilbud

  • ☐ Besvarer tilbuddene samme spørgsmål om løsningen?
  • ☐ Er systemer, funktioner og brugerroller sammenlignelige?
  • ☐ Fremgår miljø, adgang og udleveret viden tydeligt?
  • ☐ Er indsats og væsentlige begrænsninger forklaret?
  • ☐ Ved I, hvem der udfører og fagligt gennemgår arbejdet?
  • ☐ Er rapport, gennemgang og øvrige leverancer beskrevet?
  • ☐ Er en eventuel retest afgrænset og dokumenteret i tilbuddet?
  • ☐ Er uafklarede forhold besvaret før den endelige beslutning?

Kilder

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Artikler om penetrationstest

Læs også: Før penetrationstesten · Spørgsmål og svar

→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Skal I have testet noget?

Fortæl kort, hvad I vil have testet, og hvornår I skal bruge resultatet. Så vender jeg tilbage.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.