Testeren skal på få dage forstå et miljø, som IT-afdelingen har bygget op over år, og dokumentationen afgør, hvor meget af testtiden der går med at finde rundt. Hvad testeren har brug for, afhænger af to ting: hvad testen skal svare på, og hvad der kan deles uden at skabe en ny risiko. Den gode pakke er kort, rigtig og afgrænset. Den rummer en tegning over nettet, en oversigt over systemerne i opgaven og en liste over det, der ikke må røres. Adgangskoder, persondata og fortrolige aftaler hører ikke med.
Hvorfor udleveringen påvirker resultatet
En test har en fast ramme i tid. Hver time, testeren bruger på at kortlægge noget, I allerede kender, er en time, der ikke går til at afprøve det. En gennemtænkt udlevering kan derfor give dybere fund inden for den samme ramme.
Mængden af forhåndsviden er samtidig et valg af testtype og ikke kun en praktisk detalje. Får testeren meget at vide, viser resultatet, hvor langt en angriber med indsigt kan nå. Får testeren lidt, viser resultatet mere om, hvad en udenforstående kan finde på egen hånd. Valget hører til aftalen, og køberens forklaring af typerne står på penetrationtest.dk. Driftens del er at levere præcis det, der er aftalt.
Netværkstegningen
Testeren har ikke brug for en pæn tegning, men for en, der viser, hvordan nettet hænger sammen.
- Segmenter · hvilke net der findes, og hvad de bruges til, fx kontor, servere, gæster, administration og produktion.
- Overgange · hvor nettene mødes, og hvilket udstyr der styrer trafikken mellem dem.
- Forbindelser ud · internetforbindelser, forbindelser til andre lokationer og faste forbindelser til leverandører.
- Cloud · hvilke platforme og lejere der er koblet på, og hvordan.
- Ansvar · hvor jeres ansvar slutter, og en leverandørs begynder.
Det britiske NCSC anbefaler i sin vejledning om aktiver, at arkitekturtegninger viser tillidsgrænser, især omkring systemer mod internettet, tredjeparter og cloud. Den samme tankegang gør tegningen brugbar for testeren, fordi grænserne er dér, hvor en fejl rammer hårdest. → Segmentering i dybden
Systemoversigten
Ved siden af tegningen skal testeren have en liste over systemerne i opgaven. Det er et udtræk, ikke hele inventarlisten.
- Navn og formål · hvad systemet hedder, og hvad det bruges til.
- Placering · segment eller platform.
- Ejer · den, der kan svare på spørgsmål om systemet.
- Særlige hensyn · om systemet er gammelt, følsomt eller afgørende for driften. → Skrøbelige systemer
- Leverandør · om en ekstern part drifter systemet og selv skal give lov.
Listen skal også have den modsatte side med: de systemer og adresser, der ikke må testes. Den amerikanske standardorganisation NIST skriver i sin tekniske vejledning om sikkerhedstest, at planen bør nævne de systemer, der ikke er godkendt til test, med adresse og helst også navn. Det er driften, der kender adresserne, og derfor driften, der skal skrive listen. → Forberedelse i IT-afdelingen
NCSC peger i sin vejledning om penetrationstest på, at teknisk personale med kendskab til miljøet bør være med, når testens grænser lægges fast. Systemoversigten er det sted, hvor den viden bliver skrevet ned.
Pakken afhænger af testområdet
Der findes ikke én pakke, der passer til alle test. Indholdet følger det område, opgaven handler om.
- Ekstern test · domæner, adresseområder og de tjenester, I ved vender mod internettet. Tegningen over det interne net er sjældent nødvendig her.
- Intern test · segmenter, overgange og de vigtigste servere, plus oplysning om, hvor testeren skal sidde på nettet.
- Identitet og Microsoft 365 · en beskrivelse af, hvordan lokal katalogtjeneste og cloud hænger sammen, og hvilke roller testkontiene har.
- Cloudplatforme · hvilke abonnementer eller konti der er med, og hvem hos jer der ejer dem.
Hvis opgaven dækker flere områder, så del pakken op efter dem. Det gør det lettere for testeren at finde det relevante, og det gør det lettere for jer at holde styr på, hvem der har set hvad. Spørg testeren, før materialet samles, om der er noget bestemt, der mangler. Det spørgsmål sparer en runde frem og tilbage i første testuge.
Det, der bliver hos jer
Dokumentation om et net er selv følsom. En tegning med adresser, systemnavne og forbindelser er et kort over virksomheden, og den skal behandles som et.
- Adgangskoder · hører aldrig til i dokumentationen. Testkonti udleveres for sig, ad en aftalt kanal.
- Persondata · lister over medarbejdere eller kunder er ikke nødvendige for at forstå nettet.
- Kontraktindhold · aftaler med leverandører kan nævnes, men vilkår og beløb er uvedkommende.
- Forældede udgaver · tegninger, I ved er forkerte, forvirrer mere, end de hjælper.
Aftal, hvordan materialet sendes, hvor testeren opbevarer det, og hvad der sker med det, når opgaven er afsluttet. Det hører sammen med de øvrige aftaler om fortrolighed og bør stå i samme dokument.
Når tegningen og nettet ikke stemmer
Et net ændrer sig hurtigere, end tegningen bliver rettet. Brug derfor ikke ugen før testen på at gøre den perfekt. Skriv hellere, hvad I er usikre på: et segment, ingen helt kan forklare, eller en forbindelse, der måske er lukket. Usikkerheden er en oplysning, testeren kan arbejde videre med.
Viser testen, at tegningen og virkeligheden ikke passer sammen, er det et resultat i sig selv. NCSC skriver, at en organisation næppe har et fuldstændigt billede af sine aktiver, og anbefaler at lede efter dem, der mangler. En afvigelse peger på udstyr eller forbindelser, som ingen holder øje med. → Når testen viser, at dokumentationen ikke passer
Det skal I lade være med
- At sende alt, hvad I har. En mappe med hundredvis af filer koster testeren tid at sortere i.
- At vente til første testdag. Materialet skal være læst, før arbejdet begynder.
- At udelade det, I er usikre på. Et segment, der mangler på tegningen, kan havne uden for testen ved en fejl.
- At sende tegningen som almindelig mail. Behandl den som det kort, den er.
- At lade én person stå for hele pakken. Netværk, servere og cloud kan have hver sin ejer, og alle skal se listen igennem.
Hvad kan og ikke kan konkluderes
Dokumentationen bestemmer, hvor testeren kan begynde, ikke hvad testen finder. En grundig udlevering lover ikke flere fund, og en sparsom udlevering gør ikke testen mere virkelighedstro i sig selv. Resultatet gælder for de systemer og den viden, der var aftalt, og rapporten bør nævne, hvilket materiale testeren havde. → Kendte svagheder før testen
Tjekliste til dokumentationspakken
- ☐ Viser tegningen segmenter, overgange og forbindelser ud?
- ☐ Er cloudplatforme og leverandørforbindelser med?
- ☐ Har hvert system i opgaven en ejer på listen?
- ☐ Står systemer uden for testen med både adresse og navn?
- ☐ Er usikre punkter markeret som usikre?
- ☐ Er adgangskoder og persondata holdt ude?
- ☐ Er kanal, opbevaring og sletning aftalt?
Kilder
- NCSC: 10 Steps to Cyber Security, Asset management: britisk myndigheds vejledning om aktiver; arkitekturtegninger med tillidsgrænser, og at en organisation sandsynligvis ikke har et fuldt billede af sine aktiver.
- NIST SP 800-115: testplanen bør nævne systemer, der ikke er godkendt til test, med adresse og helst navn.
- NCSC (UK): Penetration testing: teknisk personale med kendskab til miljøet deltager, når testens grænser fastlægges.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Kontaktpersonen under testen · Intern test: det, IT stiller til rådighed
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
