Penetrationtest

Opstartsmødet før penetrationstesten: dagsorden og beslutninger

Opstartsmødet før penetrationstesten: dagsorden og beslutninger

Opstartsmødet er den sidste lejlighed til at opdage en misforståelse, før testeren går i gang. Mødet skal bygge på et godkendt scope og en underskrevet aftale, så tiden bruges på at bekræfte opgaven, fordele roller og lukke åbne punkter frem for at forhandle indholdet forfra.

Svaret på, hvad mødet skal afklare, er derfor kort: Er alle enige om, hvad der testes, og hvad der holdes ude? Er tilladelser, adgange og testkonti klar? Ved alle, hvem de skal kontakte, og hvornår arbejdet kan stoppes? Og hvad sker der, hvis testeren finder noget alvorligt undervejs? Kan mødet ikke svare ja til de spørgsmål, bør startdatoen flytte sig.

Et møde, der bekræfter frem for at forhandle

Det er fristende at bruge opstarten til at tilføje ønsker. En leder husker pludselig gæstenettet, eller en systemejer vil have en ekstra rolle i kundeportalen med. Sådanne ønsker kan være gode, men de hører til i en ændring af opgaven med en skriftlig godkendelse og ikke i en bisætning på et møde. Et ønske, der bliver nævnt og ikke fulgt op, ender let som en forventning hos den ene part og et ukendt punkt hos den anden. → Ændringer i opgaven undervejs

Mødet har størst værdi, når forberedelsen er gjort. Har I endnu ikke afklaret tilladelser og drift, er det den del, der skal på plads først. → Før penetrationstesten

Hvem skal sidde med?

Deltagerkredsen afhænger af opgaven. Ved en test af webshoppen kan det være den IT-ansvarlige, systemejeren og en kontakt hos hostingfirmaet. Ved en intern test af kontornettet kan driftsleverandøren og den, der har ansvaret for overvågningen, være vigtigere.

  • Bestilleren · den person, der ejer aftalen og kan træffe beslutninger på virksomhedens vegne.
  • Systemejerne · dem, der kender de systemer, testen omfatter, og deres forretningsmæssige betydning.
  • Driften · intern drift eller driftsleverandøren, som skal kunne reagere, hvis noget opfører sig anderledes.
  • Testeren · den eller de personer, der udfører arbejdet, ikke kun den, der solgte opgaven.
  • Referenten · en person, der noterer beslutninger og åbne punkter undervejs.

Hvem der i øvrigt skal kende til testen, er en beslutning for sig. → Hvem skal involveres internt?

Forslag til dagsorden

  1. Formål · hvilken beslutning resultatet skal bruges til, fx åbningen af en ny kundeportal.
  2. Scope · gennemgang af systemer, roller og undtagelser i den godkendte version.
  3. Tilladelser · status for godkendelser fra hostingfirma, driftsleverandør og andre parter.
  4. Adgang · testkonti, testdata og eventuelle undtagelser i overvågningen.
  5. Tidsplan · periode, testvinduer og perioder, hvor der ikke må testes.
  6. Kommunikation · kontaktpersoner, kanaler og hvordan status meldes undervejs.
  7. Stop og varsling · hvem der kan standse arbejdet, og hvordan alvorlige fund meldes.
  8. Aflevering · tidspunkt for rapport og gennemgang, modtagere og sikker overførsel.

Dagsordenen kan sendes ud på forhånd sammen med scope og en oversigt over åbne punkter. Så kan deltagerne undersøge status i egen organisation inden mødet, og mødet kan bruges til beslutninger frem for opslag.

Rækkefølgen er ikke afgørende, men formålet bør komme først. Hvis deltagerne ikke er enige om, hvad testen skal svare på, kan resten af dagsordenen ikke afgøres meningsfuldt.

Beslutninger, mødet skal ende med

Et opstartsmøde, der kun er en gennemgang, efterlader de svære spørgsmål åbne. Sørg for, at mødet ender med klare beslutninger på de punkter, der ellers vil skabe tvivl, når testen er i gang.

Den første er, om testen kan starte som planlagt. Den beslutning bør træffes af bestilleren og ikke overlades til testeren alene. Mangler en tilladelse, eller virker testkontiene til ERP-systemet ikke, er det bedre at udskyde end at begynde med et hul i opgaven. → Testkonti og testdata

Den anden handler om alvorlige fund. Beslut, hvad der tæller som så alvorligt, at det skal meldes med det samme, og hvem der modtager meldingen. → Kritisk fund midt i testen

Den tredje gælder overvågningen. Skal den have besked, og i givet fald hvem og hvor meget? Valget påvirker, hvad testen kan sige om virksomhedens evne til at opdage aktivitet. En overvågning, der er orienteret i detaljer, kan ikke samtidig bruges som målestok for, hvad den selv ville have opdaget. → Skal overvågningen eller SOC’en have besked?

Åbne punkter og hvem der lukker dem

Der kan sagtens stå spørgsmål åbne, når mødet slutter. Det er i orden, så længe hvert punkt har en ejer og en dato. En godkendelse fra hostingfirmaet, der afventer svar, skal have en navngiven person, der følger op, og en klar konsekvens, hvis svaret ikke kommer. Konsekvensen kan være, at den berørte del flyttes til senere, eller at den udgår og noteres som ikke testet i rapporten.

Skeln mellem punkter, der blokerer starten, og punkter, der kan afklares undervejs. En manglende kontakt uden for arbejdstid kan være acceptabel, hvis der kun testes i dagtimerne. En manglende tilladelse til en del af scope er derimod en blokering for netop den del.

Referatet er det fælles grundlag

Skriv et kort referat og send det til alle deltagere samme dag eller hurtigst muligt efter mødet. Det skal ikke gengive diskussionen, men de beslutninger, der blev truffet, og de punkter, der står åbne. Referatet bliver det dokument, parterne vender tilbage til, hvis der opstår tvivl om, hvad der blev aftalt.

NIST SP 800-115 beskriver koordinering mellem de involverede parter som første del af selve gennemførelsen. For køberen er referatet den enkleste måde at gøre den koordinering synlig og efterprøvelig på. Gem referatet sammen med aftalen og scope, så det kan findes igen ved afslutningsmødet og ved næste test.

Det skal I lade være med

  • At holde mødet uden testeren · Den, der udfører arbejdet, skal høre forudsætningerne direkte.
  • At tilføje opgaver mundtligt · Nye ønsker kræver en skriftlig ændring.
  • At starte med en tilladelse, der mangler · Udskyd hellere den berørte del.
  • At glemme driften · Den, der skal reagere på en forstyrrelse, skal kende planen.
  • At lade åbne punkter stå uden ejer · Et punkt uden navn og dato bliver ikke lukket.
  • At undlade referat · Hukommelsen er et svagt grundlag, når der opstår tvivl.

Hvad kan og ikke kan konkluderes

Et godt opstartsmøde viser, at parterne har samme forståelse af opgaven og rammerne. Det siger intet om resultatet af testen, og det forhindrer ikke, at uforudsete forhold opstår. Det gør det blot lettere at håndtere dem, fordi rollerne er kendt på forhånd.

Tjekliste efter opstartsmødet

  • ☐ Er formålet med testen formuleret og accepteret af alle?
  • ☐ Er scope gennemgået i den godkendte version?
  • ☐ Er alle nødvendige tilladelser modtaget, eller er den berørte del udskudt?
  • ☐ Virker testkonti og adgange?
  • ☐ Er kontaktpersoner, stop og varsling aftalt?
  • ☐ Har hvert åbent punkt en ejer og en dato?
  • ☐ Er referatet sendt til alle deltagere?

Kilder

  • NIST SP 800-115: kapitlerne om planlægning og gennemførelse, herunder koordinering mellem parterne.

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Artikler om penetrationstest

Læs også: Penetrationstest fra start til slut · Rules of engagement

→ 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.