Penetration-test

Penetrationstest for IT‑afdelingen fra aftale til retest: en guide i trin

Penetrationstest for IT-afdelingen fra aftale til retest: en guide i trin

Når ledelsen har sagt ja til en penetrationstest, begynder IT-afdelingens del af arbejdet. Den del er sjældent beskrevet i tilbuddet, men den afgør, om testeren bruger tiden på jeres systemer eller på at vente på adgang, og om rapporten bliver til rettelser eller bliver liggende. Guiden følger forløbet i den rækkefølge, driften møder det, og hviler på én tanke: IT skal have styr på sine egne opgaver i hvert trin, før næste trin begynder.

Forløbet er delt i otte trin. Hvert trin har et kort afsnit med det, IT skal nå, og links til de artikler på sitet, der går i dybden. Brug guiden som tjekliste, første gang I er med, og som udgangspunkt for jeres egen arbejdsgang, når testen bliver en fast del af året.

Trin 1 og 2: beslutningen og overblikket

Det første trin er at forstå, hvad ledelsen har besluttet. Spørg, hvilket spørgsmål testen skal besvare, hvilke systemer der er med, og hvornår resultatet skal bruges. IT’s opgave er at bringe de praktiske forhold ind i beslutningen: drift, der ikke må forstyrres, leverandører, der skal give tilladelse, og perioder, hvor I ikke har folk. → IT-afdelingen og ledelsens beslutning

Det andet trin er overblikket. Testeren skal have en liste over adresser, systemer og netværk, og den liste er ofte den første kontrol af jeres egen dokumentation. Lav den ud fra det, der faktisk kører, og ikke kun ud fra det, der står i oversigten. Glemte servere og gamle domæner dukker tit op allerede her. Notér samtidig, hvem der ejer hvert system, så I ved, hvem der skal spørges, hvis testeren finder noget. → Overblik over jeres internetvendte systemer

Trin 3: forberedelsen før første testdag

Det tredje trin er det mest håndfaste. Aftalen skal omsættes til konti, adgang, en testmaskine eller en VPN-forbindelse, en netværkstegning og en kontaktperson. Registrér testen i jeres ændringsstyring, og skriv ned, hvilke undtagelser i firewall eller overvågning I laver, så de kan fjernes igen. Tag et gendannelsespunkt af de systemer, der ville gøre mest ondt at miste. → Forberedelse i IT-afdelingen

Er der systemer, der ikke tåler meget, skal testeren vide det på forhånd. Det gælder fx ældre styringer, medicinsk udstyr og systemer, som en leverandør har ansvaret for. Aftal hensynene skriftligt, før testen begynder. Ligger dele af driften hos en leverandør, skal leverandøren kende testvinduet og have givet sin tilladelse, før første testdag. Spørg også, om leverandørens egen overvågning skal have besked, og hvem hos leverandøren der kan nås, hvis noget skal stoppes.

Trin 4: mens testen kører

Det fjerde trin er testdagene. Kontaktpersonen skal kunne nås, også når testeren arbejder uden for normal tid, og skal kunne træffe beslutninger eller hurtigt finde den, der kan. Overvågningen skal kunne skelne testerens aktivitet fra et rigtigt angreb, og servicedesken skal vide, hvad brugerne kan opleve, fx låste konti eller langsomme svar. → Alarmer under testen

Før en kort driftslog over perioden: hvad I så, hvad I gjorde, og hvornår. Den gør det lettere at forklare hændelser bagefter og at afgøre, om en fejl skyldtes testen eller noget andet. Bliver der meldt et kritisk fund undervejs, skal det være aftalt, hvem der tager imod beskeden, og hvem der beslutter, om noget skal ændres med det samme.

Trin 5 og 6: rapporten og rettelserne

Det femte trin begynder, når rapporten kommer. Læs den i fællesskab, før den sendes videre, og led efter fund, der kræver en beslutning fra andre end IT. Hvert fund skal over i det opgavesystem, I i forvejen bruger, med en ejer, en frist og en henvisning til fundets nummer. Del fundene op i hurtige rettelser og større projekter, så de små ting ikke venter på de store. → Fra fund til opgave

Det sjette trin er selve rettelserne. Mange fund kan rettes uden nedetid, men nogle kræver en plan med test og en vej tilbage. Når den rigtige rettelse må vente, fx fordi et system ikke kan opdateres, skal der en midlertidig afhjælpning til, og den skal registreres som midlertidig. Læg de rettelser, der handler om opsætning, ind i jeres standardopsætning, så fundet ikke kommer igen på næste maskine. → Rettelser uden at stoppe driften

Trin 7 og 8: oprydning og retest

Det syvende trin er oprydningen. Testkonti, filer, ændrede indstillinger og undtagelser skal fjernes, og I bør have en liste fra testeren over alt, der er oprettet eller lagt ind. Gå listen igennem punkt for punkt, og notér, hvornår hvert punkt er fjernet. Glemte testkonti er en af de få måder, en test kan gøre jer mere sårbare bagefter.

Det ottende trin er at gøre sig klar til retesten. Kontrollér selv, at rettelserne virker, før testeren kommer igen, så retesten bruges på at bekræfte og ikke på at finde det, der stadig mangler. Giv samtidig ledelsen en status, der skelner mellem rettet, kontrolleret og åbent, og læg resultatet ind i næste års driftsplan. → Klar til retest

Det skal I lade være med

  • At starte forberedelsen ugen før testen · konti, adgang og tilladelser tager længere tid end ventet.
  • At sende en systemliste, ingen har kontrolleret · testeren tester det, der står på listen.
  • At glemme servicedesken · brugerne ringer, og svaret skal være klar.
  • At rette i stilhed under testen · det gør rapporten svær at læse og retesten uklar.
  • At lade rapporten blive i en mappe · fund uden ejer og frist bliver ikke rettet.
  • At springe oprydningen over · testens egne konti må ikke blive en ny svaghed.

Hvad kan og ikke kan konkluderes

En IT-afdeling, der følger de otte trin, giver testeren de bedste betingelser og får et resultat, der kan bruges i driften. Det siger ikke noget om, hvor mange fund testen giver, og det gør ikke miljøet sikkert. Trinene erstatter heller ikke den aftale, der er indgået med testeren, eller de krav, en kunde eller en revisor måtte have til forløbet.

Tjekliste for IT-afdelingen

Kilder

  • NIST SP 800-115: kapitel 6 og 7 om planlægning og gennemførelse af test og kapitel 8 om aktiviteterne efter testen, herunder afhjælpning.

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Artikler til IT-afdelingen

Læs også: Beredskab under testen · Fremdrift på rettelserne

→ 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 jeres miljø testes?

Fortæl kort, hvilke dele af jeres miljø der skal testes, og hvornår I skal bruge resultatet. Så vender jeg tilbage. Testen og rådgivningen er uvildige og uafhængige, og Nielco IT har ikke indgået forhandleraftaler med leverandører.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.