Når ledelsen har bestilt en ekstern penetrationstest, lander det praktiske arbejde hos IT-afdelingen. Testen bliver kun så god som det grundlag, driften leverer: en korrekt liste over adresser og navne, afklaret ejerskab for hver af dem, en overvågning, der ved, hvad der foregår, og en person, testeren kan ringe til. Har I de fire ting klar før første testdag, kan testeren bruge tiden på jeres systemer i stedet for på at vente på svar.
Hvorvidt testen skal være ekstern eller intern, er en bestillingsbeslutning, som penetrationtest.dk forklarer for køberen. Her handler det om det, der sker bagefter, når driften skal gøre testen mulig.
Hvad den eksterne test afprøver
En ekstern test ser på virksomheden fra internettet, uden adgang til det interne net. Testeren undersøger de tjenester, der svarer på jeres offentlige adresser: webløsninger, fjernadgang, mail, loginsider og de administrationsflader, som måske ikke burde være synlige. Spørgsmålet er, om noget af det kan bruges til at komme længere ind, end det var meningen.
For IT-afdelingen betyder det, at testen rammer det udstyr og de tjenester, I selv driver eller har bestilt hos andre: firewallen, gatewayen til fjernadgang, webserverne hos hostingfirmaet og de cloudtjenester, der er sat op med jeres domæner. Fundene kan derfor handle om opsætning, opdateringer og åbninger, som er blevet stående. Ansvaret for at rette dem ligger også hos jer eller jeres leverandører.
Adresserne er jeres ansvar
Testeren tester det, der står på listen. Listen skal derfor komme fra driften og være kontrolleret, ikke skrevet ud fra hukommelsen. Saml domæner, underdomæner og offentlige adresser fra registraren, DNS, internetudbyderen, hostingfirmaet og jeres cloudkonti, og sammenlign kilderne. Uoverensstemmelser er i sig selv værdifulde, fordi de peger på systemer, ingen har ansvaret for. → Overblik over jeres internetvendte systemer
Notér for hver linje, hvad den bruges til, hvem der driver den, og hvem der er teknisk kontakt. Hvis en adresse ikke kan forklares, så sig det til testeren i stedet for at fjerne den i stilhed. Den ukendte adresse kan være det vigtigste punkt på listen.
Giv også testeren en kort beskrivelse af, hvad der ligger bag de vigtigste navne. At kundeportal.firma.dk viser ordrer for erhvervskunder, mens kampagne.firma.dk er en statisk side, hjælper testeren med at bruge tiden der, hvor konsekvensen er størst. Beskrivelsen behøver ikke være lang. Den skal bare gøre det muligt at skelne mellem det kritiske og det trivielle, og den skal være skrevet af nogen, der kender driften. Datér listen, og gem den sammen med aftalen, så I senere kan se, hvad rapporten bygger på.
Ejerskab og tilladelser
En adresse, I bruger, er ikke nødvendigvis en adresse, I må lade teste. Hjemmesiden kan ligge på en delt server hos et hostingfirma, mailen kan være en tjeneste i cloud, og fjernadgangen kan være drevet af en leverandør. For hver linje skal det stå klart, om virksomheden selv råder over den, eller om en anden part skal give lov. → Hostede servere i den eksterne test
Afklar det i god tid. En leverandør, der først hører om testen dagen før, kan sige nej eller bede om udsættelse. Cloududbydere har egne regler for test af kunders ressourcer, og de skal være læst, inden testen begynder.
Overvågning, alarmer og blokeringer
En ekstern test ligner set udefra et angreb, og det er meningen. Jeres overvågning, firewall og eventuelle beskyttelse af webløsningerne vil reagere. Beslut sammen med den, der bestilte testen, hvad der skal ske, når de gør det. → Alarmer under testen
- Besked til overvågningen · ved SOC eller driftsleverandørens vagt, at der kommer testtrafik, og fra hvilke adresser?
- Automatiske blokeringer · skal testerens adresser kunne blokeres som alle andre, eller skal de undtages for at give testen tid til at nå dybere?
- Låste konti · hvad gør servicedesken, hvis brugere bliver låst ude af en loginside, der indgår i testen?
- Logning · gemmes logs fra perioden, så I bagefter kan se, hvad overvågningen faktisk registrerede?
Hvis I vælger at undtage testerens adresser, så skriv det ned og fjern undtagelsen igen bagefter. En glemt undtagelse er en åbning, ingen længere kender grunden til.
Kontakt og beredskab i testperioden
Testeren skal kunne få fat i en person med teknisk indsigt hele testperioden. Det gælder især, hvis testeren finder noget alvorligt, eller hvis en tjeneste begynder at opføre sig anderledes. Den person skal kunne vurdere situationen og træffe en beslutning eller hurtigt få fat i den, der kan. → Kontaktperson under testen
Planlæg også, hvad der sker, hvis en kunde ringer, fordi webshoppen er langsom, eller hvis driftsleverandøren ser en alarm og vil lukke for trafikken. En kort intern besked til servicedesken og vagten forhindrer, at testen bliver standset ved en misforståelse. Undgå større ændringer i testperioden. Hvis en ny firewallregel eller en opdatering ikke kan vente, så fortæl testeren det, så resultatet kan læses rigtigt.
Det skal I lade være med
- At sende en adresseliste fra hukommelsen · saml fra flere kilder, og sammenlign dem.
- At fjerne ukendte adresser fra listen · de skal undersøges, ikke skjules.
- At glemme leverandørernes tilladelse · hosting, cloud og driftsleverandør skal være på plads før start.
- At lade overvågningen være uvidende uden en beslutning · det er et valg, ikke en forglemmelse.
- At rette i stilhed under testen · ændringer skal meldes, ellers kan rapporten ikke tolkes.
- At lade undtagelser stå efter testen · fjern dem, og notér, at det er sket.
Hvad kan og ikke kan konkluderes
En ekstern test viser, hvordan de adresser og tjenester, der stod på listen, kunne bruges fra internettet i testperioden. Den kan påvise svagheder i opsætning og opdatering og vise, om de kan føre videre. Den siger intet om adresser, der manglede, eller om, hvad en bruger på kontornettet kan nå.
En test uden alvorlige fund er heller ikke et bevis på, at opsætningen holder i morgen. Nye tjenester, ændrede regler og nye sårbarheder i udstyret ændrer billedet. Fundene skal derfor bruges som pejlemærke for driften, ikke som en endelig godkendelse. → Typiske fund i en ekstern test
Tjekliste til første testdag
- ☐ Er adresselisten samlet fra flere kilder og kontrolleret?
- ☐ Har hver adresse en ejer, et formål og en teknisk kontakt?
- ☐ Har hostingfirma, cloududbyder og driftsleverandør givet lov, hvor det kræves?
- ☐ Er det besluttet, om overvågningen får besked, og om testerens adresser undtages?
- ☐ Ved servicedesken, hvad de gør ved låste konti og henvendelser?
- ☐ Er en teknisk kontaktperson udpeget for hele perioden?
- ☐ Er logning fra testperioden sikret?
- ☐ Er det aftalt, hvem der fjerner undtagelser bagefter?
Den samlede forberedelse på tværs af ekstern og intern test er beskrevet i → Forberedelse i IT-afdelingen.
Kilder
- NCSC (UK): Penetration testing: forberedelse med testkonti og teknisk kontakt i hele testperioden.
- NIST SP 800-115: skelnen mellem test udefra og indefra.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Låste konti under testen · Hvor tit skal internetsiden testes?
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
