En intern penetrationstest begynder inden for virksomhedens grænse, og det betyder, at IT-afdelingen skal levere udgangspunktet. Testeren skal have en vej ind på nettet, de konti, opgaven forudsætter, en person at henvende sig til og en afgrænsning, som driften kan stå inde for. Mangler en af de fire dele, går testtiden med at vente, eller resultatet svarer på et andet spørgsmål end det, der blev stillet.
Valget mellem ekstern og intern test og de overordnede aftaler hører til køberens beslutning og er beskrevet på penetrationtest.dk. Her er det driftens praktiske arbejde, der er i centrum.
Fire ting, testen ikke kan undvære
Uanset hvordan testen er skruet sammen, skal IT-afdelingen kunne svare ja til fire spørgsmål, før testeren går i gang.
- Adgang · er det klart, hvorfra testeren arbejder, og virker forbindelsen?
- Konti · har testeren de konti og roller, opgaven kræver, og er de kontrolleret?
- Kontakt · er der en navngiven person i IT, der kan svare i hele testperioden?
- Afgrænsning · ved både testeren og driften, hvilke net og systemer der er med, og hvilke der ikke er?
Svarene skal være skrevet ned og delt med testeren. En mundtlig aftale på opstartsmødet holder ikke nødvendigvis, når der opstår tvivl på tredjedagen.
Adgang til nettet
Det første praktiske spørgsmål er, hvor testeren skal sidde på nettet. Det kan være et netværksstik på kontoret, en VPN-forbindelse, en af jeres egne maskiner eller en testenhed, der placeres hos jer. Valget afgør, hvad testen siger noget om, og det er derfor ikke kun et logistisk spørgsmål. → Testerens udgangspunkt på det interne net
Når valget er truffet, er det driftens opgave at få det til at virke. Det kan kræve, at et stik åbnes i det rigtige segment, at netværksadgangskontrollen tillader enheden, eller at en VPN-profil oprettes. Test forbindelsen før første dag, så testeren ikke bruger den første formiddag på fejlfinding. Hvis I bruger en testenhed, skal der være aftaler om udstyr, placering og fjernelse. → Testenhed på jeres netværk
Konti og roller
En intern test kan begynde med en almindelig brugerkonto, fordi spørgsmålet er, hvor langt en medarbejder eller en angriber med en medarbejders adgang kan komme. Nogle test begynder helt uden konto, andre har brug for flere roller.
Opret testkonti, der ligner rigtige konti i rettigheder, men som tydeligt er testkonti i navn og beskrivelse. Giv dem en udløbsdato, og notér, hvem der lukker dem bagefter. Undgå at genbruge en eksisterende medarbejders konto, også selv om det virker nemmere. Det gør det svært at skelne testen fra almindelig brug i loggene, og det giver testeren adgang til personens data.
Hold øje med kontiene i testperioden. Hvis en testkonto pludselig bruges fra et uventet sted, skal I opdage det. → Testkonti under opsyn
Afgrænsning set fra driften
Køberen har bestemt, hvad testen skal handle om. Driften skal oversætte det til net, adresseområder og systemer, som testeren kan forholde sig til.
- Med · de segmenter og adresseområder, testen må bevæge sig i.
- Uden for · systemer, der ikke må testes, fx produktionsanlæg, medicoudstyr eller en leverandørs udstyr uden tilladelse.
- Med forsigtighed · systemer, der er kendt for at være følsomme, og som testeren skal tage særlige hensyn til. → Skrøbelige systemer
Skillelinjen mod produktionsnettet fortjener sin egen opmærksomhed. Er der OT eller styringer på nettet, skal det stå klart, hvor IT-testen holder op. → OT-grænsen
NCSC anbefaler, at både risikoejere og teknisk personale deltager, når omfanget fastlægges. For en intern test er driften den part, der kender nettet bedst, og som derfor skal være med i den samtale.
Dokumentation til testeren
En netværkstegning, en oversigt over de vigtigste servere og en liste over kendte undtagelser sparer testeren tid og giver et bedre resultat. Dokumentationen behøver ikke være perfekt. Det vigtigste er, at den svarer til virkeligheden så godt, som I kan få den til. Hvis testen viser, at tegningen ikke passer, er det også en nyttig oplysning. → Netværkstegning og systemoversigt
Beslut på forhånd, hvor meget testeren skal have udleveret. En test med meget forhåndsviden kan nå længere på den tid, der er til rådighed. En test med lidt forhåndsviden siger mere om, hvad en udenforstående kan finde på egen hånd. NIST SP 800-115 beskriver planlægning af tekniske sikkerhedstest som et selvstændigt trin, og valget af forhåndsviden hører hjemme dér.
Mennesker i driften
Ud over kontaktpersonen skal flere vide, at testen finder sted. Servicedesken skal kunne genkende henvendelser om låste konti eller mærkelige advarsler. Overvågningen eller SOC’en skal vide, om de skal reagere som normalt eller have besked på forhånd. Den, der kan stoppe testen, hvis noget går galt, skal være kendt af alle. → Kontaktpersonen i IT under testen
Tænk også på tidspunkterne. Arbejder testeren uden for normal arbejdstid, skal der være en kontakt, der kan nås dér, og natlige driftsjob som sikkerhedskopiering og opdateringer skal være kendt, så de ikke forveksles med testens påvirkning. Planlagte ændringer i testperioden bør enten udskydes eller meldes til testeren, så resultaterne ikke bygger på et net, der ændrer sig undervejs.
Sørg til sidst for en frisk sikkerhedskopi af de vigtigste systemer, før testen begynder. En intern test er normalt forsigtig, men det er driftens ansvar at kunne vende tilbage, hvis noget uventet sker. → Backup og gendannelsespunkt før testen
Det skal I lade være med
- At give testeren en rigtig medarbejders konto. Brug testkonti med tydelige navne.
- At teste forbindelsen på første testdag. Gør det dagen før.
- At lade afgrænsningen være et adresseområde uden forklaring. Skriv, hvad der er med, og hvorfor.
- At glemme servicedesken. Låste konti og alarmer lander dér først.
- At udlevere forældet dokumentation uden forbehold. Sig, hvis I er usikre på den.
- At gennemføre store ændringer i testperioden. Udskyd dem, eller meld dem til testeren på forhånd.
Hvad kan og ikke kan konkluderes
En godt forberedt intern test bruger tiden på at undersøge jeres net og ikke på at vente på adgang. Den siger noget om det, der kunne nås fra det valgte udgangspunkt med de udleverede konti. Den siger ikke noget om andre udgangspunkter eller om systemer uden for afgrænsningen. Forberedelsen påvirker derfor ikke kun forløbet, men også, hvad rapporten kan bruges til.
Tjekliste før første testdag
- ☐ Er udgangspunktet valgt, og er forbindelsen testet?
- ☐ Er testkonti oprettet med tydelige navne og udløbsdato?
- ☐ Er det skrevet ned, hvad der er med, uden for og med forsigtighed?
- ☐ Har testeren fået netværkstegning og systemoversigt?
- ☐ Er kontaktperson, servicedesk og overvågning orienteret?
- ☐ Er det aftalt, hvem der lukker konti og adgange efter testen?
Kilder
- NCSC: Penetration testing: risikoejere og teknisk personale deltager i fastlæggelsen af omfanget.
- NIST SP 800-115: planlægning af tekniske sikkerhedstest.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Testenhed på jeres netværk · Forberedelse i IT-afdelingen
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
