IT-afdelingen har investeret i overvågning, logning og måske en ekstern SOC, og nu vil nogen vide, om den virker. Det er et rimeligt spørgsmål, men en almindelig penetrationstest er bygget til at finde svagheder, ikke til at måle, om nogen opdager den, der leder efter dem. Svaret hviler på formålet: en pentest kan give et indirekte billede af opdagelsen, mens et egentligt mål for opdagelse og reaktion kræver en test, der er planlagt til netop det.
Forskellen afgør, hvad I bestiller, og hvad I kan forvente at få at vide bagefter.
Hvad en pentest er bygget til
En penetrationstest skal finde så mange relevante svagheder som muligt inden for et afgrænset område og en afgrænset tid. Testeren arbejder bredt, afprøver mange veje og gør ikke nødvendigvis noget for at skjule sig. Overvågningen kan være orienteret, så alarmer ikke fører til, at testen stoppes eller at et beredskab kaldes ud. → Alarmer under testen
Det er en god ramme for at finde fund. Det er en dårlig ramme for at måle opdagelse. En overvågning, der fanger en støjende test, er ikke nødvendigvis god til at fange en angriber, der går forsigtigt frem. Og en overvågning, der er orienteret på forhånd, reagerer ikke som den ville over for et ukendt angreb.
Det, en pentest alligevel kan vise
Selv om formålet er et andet, giver en pentest IT-afdelingen nyttige oplysninger om overvågningen, hvis I forbereder det.
- Hvad blev logget · efter testen kan I sammenholde testerens aktiviteter med jeres logs og se, hvad der efterlod spor. → Logning efter testen
- Hvad udløste alarmer · og hvad der ikke gjorde, selv om det burde have gjort.
- Hvor der mangler synlighed · systemer eller net, hvor testerens aktiviteter slet ikke kunne ses.
- Hvordan vagten handlede · hvis vagten ikke var orienteret, kan I se, hvem der fik besked, og hvad der skete.
Den sammenligning kræver, at testeren leverer en tidslinje over sine aktiviteter, og at I gemmer jeres logs fra perioden. Aftal det før testen. → Log over testperioden
Resultatet er en liste over huller i synligheden, ikke en karakter for overvågningen. Det er stadig værdifuldt, fordi hullerne kan lukkes.
Når spørgsmålet er reaktionen
Hvis det, I vil vide, er, om organisationen kan opdage og reagere på et realistisk angreb, er det et andet spørgsmål. Det handler om mennesker, procedurer og beslutninger lige så meget som om teknik. Hvem ser alarmen? Hvem beslutter at isolere en server? Hvornår får ledelsen besked?
NCSC (UK) beskriver i sin vejledning om penetrationstest en scenariebaseret form for test, hvor formålet også er at vurdere de opdagelses- og reaktionsevner, organisationen har. Det kræver, at testen bygges op om et scenarie, og at forsvaret ikke kender tidspunktet. Den slags øvelser, red teaming og beslægtede former, er et selvstændigt fagområde. Hvordan de planlægges, styres og bruges, er beskrevet for sikkerhedsfunktioner på red-teaming.dk.
IT-afdelingens del af en øvelse
Selv når en øvelse er det rigtige svar, har IT-afdelingen en rolle. I er dem, der skal opdage og reagere, men også dem, der kender miljøet bedst.
- Hvem ved besked · kun få må kende til øvelsen. IT-chefen kan være en af dem, mens resten af driften reagerer som normalt.
- Stopregler · der skal være en vej til at stoppe øvelsen, hvis den truer driften.
- Adskillelse fra rigtige hændelser · nogen skal kunne afgøre, om en alarm er øvelse eller virkelighed.
- Beredskabsplanen · øvelsen afprøver den plan, I har. Hvis planen er uklar, vil det vise sig. → Beredskabsplanen efter testen
Forbered jer på, at en øvelse kan være ubehagelig for driften. Den måler, hvad I gør under pres, og resultatet kan pege på personer, selv om det handler om procedurer.
Hvad I skal vælge imellem
Valget afhænger af, hvor I står.
- Har I ikke styr på de grundlæggende svagheder · så er en pentest det første skridt. En øvelse vil finde de samme svagheder og give et mindre præcist billede af dem.
- Har I logning og overvågning, men ved ikke, hvad den ser · så kan en pentest med sammenligning af logs bagefter vise hullerne i synligheden.
- Har I rettet de kendte svagheder og vil vide, om organisationen reagerer · så er en øvelse det rigtige redskab.
Beslutningen om en større øvelse kan ligge uden for IT-afdelingen, fordi den involverer ledelsen og andre dele af organisationen. IT’s bidrag er at beskrive, hvilket spørgsmål overvågningen skal besvare, og hvad I allerede ved.
Fra huller i synligheden til forbedringer
Når sammenligningen mellem testerens tidslinje og jeres logs er lavet, har I en liste over aktiviteter, der ikke blev set. Behandl den som andre fund. Hvert hul skal have en ejer og en beslutning: skal der logges mere, skal en alarm justeres, eller skal et system dækkes af overvågningen, som ikke var det før?
Vær opmærksom på, at flere logs ikke i sig selv giver bedre opdagelse. Data, som ingen ser på, ændrer ikke reaktionen. Prioritér de huller, der dækker de mest kritiske systemer, og de aktiviteter, der ville gå forud for et alvorligt angreb. Hvis overvågningen leveres af en ekstern part, skal listen deles med dem, så de kan tage stilling til deres del.
Det skal I lade være med
- At kalde en pentest en test af overvågningen · den er ikke bygget til at måle opdagelse.
- At konkludere ud fra alarmer, der var varslet · en orienteret vagt reagerer ikke som over for et ukendt angreb.
- At glemme at gemme logs fra testperioden · uden dem kan intet sammenlignes.
- At springe den grundlæggende test over · en øvelse oven på kendte svagheder giver mindre ny viden.
- At lade hele driften kende til en øvelse · så måler den ikke den normale reaktion.
- At bruge øvelsens resultat mod enkeltpersoner · den handler om procedurer og opsætning.
Hvad kan og ikke kan konkluderes
En pentest kan vise, hvilke af testerens aktiviteter der blev logget og opdaget, og hvor der mangler synlighed. Den kan ikke vise, om overvågningen ville opdage en forsigtig angriber, eller om organisationen reagerer rigtigt under pres. Det kræver en test, der er bygget til formålet. Ingen af delene garanterer, at et rigtigt angreb bliver opdaget.
Tjekliste, når IT vil afprøve opdagelse
- ☐ Er det formuleret, om spørgsmålet er synlighed eller reaktion?
- ☐ Er de grundlæggende svagheder kendt og under behandling?
- ☐ Er det aftalt, at testeren leverer en tidslinje over aktiviteter?
- ☐ Gemmes logs fra testperioden?
- ☐ Er det besluttet, om vagten skal være orienteret?
- ☐ Er der stopregler, hvis en øvelse vælges?
- ☐ Er ledelsen inddraget, hvis spørgsmålet er reaktionen?
Kilder
- NCSC (UK): Penetration testing: beskriver en scenariebaseret testform, hvor formålet også er at vurdere organisationens evne til opdagelse og reaktion.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Logning under en intern test · Driftsmonitorering under testen
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
