Penetrationtest

Efter en sikkerhedshændelse: hvornår giver en penetrationstest mening?

Efter en sikkerhedshændelse: hvornår giver en penetrationstest mening?

Efter et angreb er det fristende at bestille en penetrationstest for at finde ud af, hvad der skete. Testen svarer imidlertid på et andet spørgsmål: den afprøver, hvordan systemerne står nu, ikke hvordan angriberen kom ind, og hvad der blev berørt.

En penetrationstest giver derfor mest mening, når hændelsen er håndteret, systemerne er ryddet op, og virksomheden vil vide, om oprydningen holder. Mens hændelsen står på, er det undersøgelsen og håndteringen af hændelsen, der skal have opmærksomheden.

Bagudrettet undersøgelse og fremadrettet test

En undersøgelse af en hændelse ser bagud. Den skal klarlægge forløbet, sikre spor, afgøre hvilke systemer og data der er berørt, og danne grundlag for oprydning og eventuelle anmeldelser. Det kræver andre kompetencer og en anden arbejdsform end en penetrationstest.

En penetrationstest ser på tilstanden nu. Den kan afdække svagheder, som en angriber kunne bruge, men den kan ikke fastslå, hvilken vej en bestemt angriber faktisk gik. Et fund i testen er et muligt angrebspunkt og ikke et bevis for, hvad der skete.

Blandes de to sammen, kan resultatet blive en rapport, der hverken forklarer hændelsen eller giver et samlet billede af sikkerheden. Testen kan desuden ændre logfiler og systemtilstand, som undersøgelsen havde brug for. Derfor bør bestillingen af testen vente, til dem, der håndterer hændelsen, har sagt god for det.

Tre grunde til at vente, mens hændelsen står på

Mens hændelsen håndteres, taler tre forhold imod at sætte en test i gang.

  • Spor kan gå tabt · testaktivitet kan overskrive eller blande sig med de spor, undersøgelsen skal bruge.
  • Testen kan forveksles med angrebet · overvågningen og driftsleverandøren skal ikke bruge kræfter på at skelne testeren fra en angriber.
  • Billedet skifter hurtigt · systemer lukkes, adgangskoder skiftes og opsætningen ændres, så rapporten er forældet, før den er skrevet.

Når forløbet er klarlagt, de berørte systemer er genetableret, og de umiddelbare rettelser er gennemført, er der et stabilt udgangspunkt at teste. Det tidspunkt afhænger af hændelsens omfang og kan ikke sættes på forhånd. Lad den, der leder håndteringen, være med til at vurdere det.

Holder det, vi har lavet om?

Efter oprydningen er spørgsmålet ofte, om ændringerne virker. En penetrationstest kan bruges til at afprøve netop det.

I et tænkt eksempel har en angriber skaffet sig adgang til kontornettet gennem en fjernadgang med et svagt login. Efter hændelsen er fjernadgangen udskiftet, tofaktorlogin indført og en række konti nulstillet. En test kan nu rette sig mod den nye fjernadgang, mod det, en bruger på kontornettet kan nå, og mod om der stadig findes andre veje ind af samme slags.

Testen kan også bruges bredere, som udgangspunkt for den videre forbedring. En hændelse viser ét svagt punkt, men den siger ikke, at der ikke findes andre. En test, der tager udgangspunkt i, at en angriber allerede er inde, kan belyse, hvor langt en ny indtrænger kunne nå. → Assume breach

Ledelsen vil ofte have et svar på, om virksomheden er sikker nu. Det svar kan testen ikke give fuldt ud. Den kan give et dokumenteret billede af de områder, der blev undersøgt, og det er et bedre grundlag end en forsikring om, at alt er ryddet op.

Testen kan også bruges til at afprøve de kontroller, der er indført efter hændelsen. Er overvågningen skærpet, kan det aftales, at testen skal vise, om aktiviteten bliver opdaget. Det kræver en særskilt aftale med dem, der står for overvågningen, og skal stå i bestillingen. → Skal overvågningen eller SOC’en have besked?

Giv testeren det, der er nødvendigt

Testeren skal kende de dele af hændelsen, der har betydning for opgaven: hvilke systemer der var berørt, hvad der er ændret, og hvilke spørgsmål ledelsen vil have besvaret. Testeren behøver ikke alle detaljer fra undersøgelsen, og fortroligheden om hændelsen skal aftales, før oplysningerne deles. Saml oplysningerne i et kort notat: berørte systemer, gennemførte ændringer, kendte begrænsninger og de spørgsmål, testen skal besvare. Notatet gør det også lettere for ledelsen at se, hvad testen er bestilt til. → Scope i en penetrationstest

Overvej, om den samme part både skal hjælpe med hændelsen og teste bagefter. Det kan være praktisk, fordi kendskabet til systemerne er der. En tester, der ikke har deltaget i oprydningen, ser til gengæld ændringerne uden at have været med til at beslutte dem. → Uafhængig penetrationstest

Har hændelsen omfattet personoplysninger, kan der være pligter over for Datatilsynet, som skal håndteres uafhængigt af testen. Datatilsynets vejledning om brud på persondatasikkerheden er udgangspunktet. Teksten er ikke juridisk rådgivning.

Hvis testen støder på spor af angriberen

En test efter en hændelse kan finde tegn på, at adgangen ikke er helt lukket. Aftal på forhånd, hvad testeren skal gøre i så fald: stoppe, kontakte en navngiven person og overlade sagen til dem, der håndterer hændelser. Testeren skal ikke selv forfølge sporene. → Tegn på et rigtigt angreb under testen

Sørg også for, at overvågningen og driftsleverandøren kender testvinduet. Efter en hændelse er alle mere årvågne, og en uanmeldt test kan udløse en ny alarm, der tager tid fra det egentlige arbejde.

Det skal I lade være med

  • At bestille en pentest som undersøgelse af hændelsen · testen forklarer ikke forløbet.
  • At teste, mens hændelsen står på · spor og opmærksomhed skal bruges på håndteringen.
  • At teste kun det sted, angriberen kom ind · andre svagheder forsvinder ikke, fordi én er lukket.
  • At bruge en rapport uden alvorlige fund som afslutning på hændelsen · den siger noget om de undersøgte systemer, ikke om hele forløbet.
  • At holde testeren uden for de vigtige oplysninger · uden kendskab til ændringerne kan testen ramme ved siden af.
  • At glemme at varsle overvågningen · en ny alarm efter en hændelse koster tid og uro.

Hvad kan og ikke kan konkluderes

En test efter oprydningen kan vise, om de undersøgte systemer og de gennemførte ændringer holdt over for de forhold, der blev afprøvet på testtidspunktet. Den kan give ledelsen et grundlag for at vurdere, om indsatsen efter hændelsen har virket.

Den kan ikke fastslå, hvordan hændelsen skete, om alle spor er fjernet, eller om der er sket noget, som ingen har opdaget. Et resultat uden alvorlige fund er et godt tegn for de undersøgte områder, men det er ikke en afslutning på sagen. Testen erstatter heller ikke undersøgelsen af hændelsen eller de anmeldelser, der eventuelt skal foretages. → Testen garanterer, at vi er sikre

Tjekliste før testen bestilles

  • ☐ Er hændelsen håndteret, og er de berørte systemer genetableret?
  • ☐ Har dem, der håndterer hændelsen, sagt god for, at der testes?
  • ☐ Er det skrevet ned, hvilke ændringer testen skal afprøve?
  • ☐ Er fortrolighed om hændelsen aftalt med testeren?
  • ☐ Er det aftalt, hvad testeren gør ved tegn på en aktiv angriber?
  • ☐ Kender overvågning og driftsleverandør testvinduet?

Kilder

  • Datatilsynet: vejledning om brud på persondatasikkerheden og anmeldelse.

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Artikler om penetrationstest

Læs også: Hvor ofte skal I teste? · Spørgsmål og svar

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