En intern test er en sjælden lejlighed til at se jeres logning arbejde på en kendt hændelse. I ved, hvem der var på nettet, hvornår og fra hvilken maskine, og bagefter kan I spørge: kan vi finde det i vores egne logs? Svaret hviler på en enkel sammenligning mellem testerens tidslinje og det, jeres systemer faktisk registrerede. Forskellen mellem de to viser, hvad I ville have kunnet efterforske, hvis det havde været en rigtig hændelse.
Sammenligningen kræver lidt forberedelse og en aftale med testeren, men ingen særlig øvelse. Den er en del af en almindelig pentest, så længe formålet er at kontrollere logningen og ikke at måle, hvor hurtigt nogen reagerer.
Forskellen på logning og reaktion
Det er nyttigt at holde to spørgsmål adskilt. Det første er, om hændelserne blev skrevet ned et sted, der kan findes bagefter. Det andet er, om nogen så dem i tide og gjorde noget. En pentest kan give et godt svar på det første, fordi tidslinjen er kendt. Det andet kræver en anden opsætning, hvor reaktionen er det, der afprøves, og hvor det er aftalt, hvem der ved hvad. → Pentest eller øvelse, når IT vil afprøve opdagelse og reaktion
Øvelser, der måler opdagelse og reaktion, er behandlet på red-teaming.dk. Her handler det om den mere jordnære del: om logningen gør jer i stand til at rekonstruere et forløb.
Selve spørgsmålet om, hvorvidt overvågningen skal kende til testen, aftales før start. Det påvirker ikke sammenligningen bagefter, for den bygger på de gemte logs og ikke på, hvem der kiggede.
Et praktisk forbehold hører med. Er overvågningen orienteret, kan nogen være fristet til at slå ekstra logning til i testperioden for at se mere. Det giver et bedre billede af testen, men et dårligere billede af jeres hverdag. Lad logningen stå, som den plejer, og notér, hvis noget alligevel blev ændret undervejs, så resultatet kan læses rigtigt.
Det, I skal aftale før testen
Sammenligningen er kun mulig, hvis begge sider har noget at holde op mod hinanden.
- Testerens tidslinje · bed om en log over aktiviteter med tidspunkt, kildemaskine og hvilke konti der blev brugt. Den skal være detaljeret nok til at kunne genfindes, men behøver ikke beskrive fremgangsmåden.
- Tidsangivelse · aftal, hvilken tidszone tidslinjen skrives i, og kontrollér, at jeres egne systemer har korrekt tid. Uden det bliver sammenligningen et gætteri.
- Opbevaring · sørg for, at logs fra testperioden ikke bliver overskrevet, før sammenligningen er lavet.
- Ejer · udpeg den person i IT, der skal lave sammenligningen, og giv vedkommende tid til det.
Driften fører sin egen log over testperioden, og den kan bruges som et tredje spor. → Driftslog over testperioden
Hvilke spor I skal lede efter
Den britiske myndighed NCSC beskriver i sin introduktion til logning, hvilke kilder der typisk hjælper med at besvare spørgsmål under en hændelse. Grupperet efter IT-afdelingens hverdag ser det sådan ud:
- Login og konti · logins, mislykkede forsøg og ændringer i grupper fra kataloget, VPN og fjernadgang.
- Netværk · hvad firewalls, DNS og proxy registrerede om forbindelser mellem net og ud af huset.
- Maskiner · hændelser på klienter og servere, herunder programmer, der blev startet.
- Inventar · hvilken maskine der havde hvilken adresse, og hvor den sad, så en hændelse kan føres tilbage til en enhed.
Testkontiene er et godt sted at starte. Når I ved, hvilke konti testeren brugte, kan I følge dem gennem systemerne og se, hvor sporet holder op. → Testkonti under opsyn
Sådan læser I resultatet
Gå tidslinjen igennem punkt for punkt, og sortér hver aktivitet i en af tre kategorier.
- Fundet · aktiviteten står i jeres logs, og den kan knyttes til maskine, konto og tidspunkt.
- Delvis · noget er registreret, men det kan ikke kobles sammen, fx fordi maskinens adresse ikke kan føres tilbage til en enhed, eller fordi tidspunkterne ikke passer.
- Mangler · aktiviteten har ikke efterladt spor, I kan finde.
Kategorien delvis kan være den mest lærerige. Den viser, at logningen findes, men at den ikke kan bruges til at fortælle en sammenhængende historie. Årsagerne kan være manglende tidssynkronisering, for kort opbevaring eller logs, der ligger på hver sin maskine uden at blive samlet.
Mangler er ikke nødvendigvis et tegn på, at intet er sat op. Måske er en bestemt kilde slået fra, eller logningen dækker kun servere og ikke klienter. Skriv årsagen ned for hver mangel, så rettelsen rammer rigtigt.
Notér også, hvor lang tid det tog at finde sporene. Hvis det krævede en hel dag at samle logs fra fem systemer for en enkelt aktivitet, er det i sig selv en oplysning. Under en rigtig hændelse er tiden knap, og spredte logs uden fælles opslag forsinker hvert eneste spørgsmål, der skal besvares.
Fra resultat til forbedring
Resultatet af sammenligningen er ikke et fund i rapporten, medmindre testeren er bedt om at vurdere logningen. Det er jeres eget materiale. Behandl det alligevel som fund: hver mangel bliver en opgave med ejer og prioritet.
Prioritér efter, hvor vigtigt sporet ville være i en rigtig hændelse. Manglende logins på domænecontrollerne vejer tungere end manglende hændelser på en testserver. NCSC anbefaler desuden, at logs gemmes længe nok til at kunne besvare spørgsmål om en hændelse, og nævner mindst seks måneder som udgangspunkt. Vurdér jeres opbevaring ud fra det. → Fund om logning og overvågning
Hvis testen også omfattede Microsoft 365 eller cloudplatforme, kan samme sammenligning laves der. → Logning i Microsoft 365, Azure og AWS
Det skal I lade være med
- At glemme at bede om testerens tidslinje. Uden den er der intet at sammenligne med.
- At lade logs fra testperioden blive overskrevet. Sammenligningen skal laves, mens de findes.
- At blande logning og reaktion sammen. En pentest siger noget om sporene, ikke om beredskabet.
- At ignorere forskelle i tid. Ure, der går forkert, gør sporene ubrugelige.
- At gemme resultatet uden opgaver. Mangler i logningen skal have en ejer.
Hvad kan og ikke kan konkluderes
Sammenligningen viser, om de aktiviteter, testeren udførte, efterlod spor i jeres systemer. Den siger ikke, om andre former for aktivitet ville blive registreret, og den siger intet om, hvorvidt nogen ville have opdaget forløbet undervejs. En hændelse, der ligner testen, kan rekonstrueres. Andre forløb er ikke afprøvet.
Tjekliste til logningen under testen
- ☐ Har testeren lovet en tidslinje med tidspunkt, maskine og konto?
- ☐ Er tidszonen aftalt, og går jeres egne ure rigtigt?
- ☐ Er logs fra testperioden sikret mod at blive overskrevet?
- ☐ Er der udpeget en person til sammenligningen?
- ☐ Er hver mangel blevet til en opgave med ejer?
Kilder
- NCSC: Introduction to logging for security purposes: logkilder, der hjælper ved hændelser, tidssynkronisering og opbevaring i mindst seks måneder.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Alarmer under testen · Pentest eller øvelse
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
