Når testeren har været inde i miljøet i flere dage, og ingen kan finde sporene bagefter, er det et af de mest alvorlige budskaber i rapporten, selv om det ikke står med rødt. Det betyder, at en rigtig angriber kunne have gjort det samme, uden at I ville kunne se, hvad der skete. Svaret er ikke at slå al logning til på én gang, men at bygge op i en rækkefølge: først de spørgsmål, I skal kunne besvare, så de kilder, der giver svarene, derefter opbevaring og beskyttelse, og til sidst opsynet, der gør loggene til mere end et arkiv.
Hvordan I under selve testen sammenligner testerens tidslinje med jeres spor, er beskrevet i → Logning under den interne test. Her handler det om, hvad I gør med resultatet.
Hvad fundene kan vise
Fund om logning har forskellige former. Det er vigtigt at skelne, for de kræver forskellige rettelser.
- Ingen registrering · hændelsen blev slet ikke skrevet ned, fordi logningen var slået fra eller for begrænset.
- Registreret, men ikke samlet · sporet fandtes på den enkelte maskine, men nåede aldrig et centralt sted.
- Samlet, men væk · loggene var overskrevet eller slettet, før nogen kiggede.
- Samlet, men ikke set · sporet fandtes centralt, men ingen regel eller person opdagede det.
- Ikke til at stole på · loggene kunne ændres af den, der havde fået adgang.
Brug rapporten og jeres egen sammenligning til at placere hvert fund i en af grupperne. Så bliver det klart, om opgaven handler om opsætning, opbevaring eller opsyn. Et enkelt forløb fra testen kan godt falde i flere grupper: loginforsøget blev registreret og samlet, mens den efterfølgende ændring af en gruppe aldrig blev skrevet ned. Notér det på hvert trin, så rettelsen rammer det rigtige sted.
Start med spørgsmålene
NCSC anbefaler i sin vejledning om logning og overvågning, at logningen planlægges ud fra de spørgsmål, I skal kunne svare på under en hændelse, og at der ikke findes én løsning, der passer alle. Det er et godt udgangspunkt efter en test, for testen har givet jer konkrete spørgsmål:
- Hvilken konto blev brugt, og hvorfra?
- Hvilke maskiner var berørt?
- Hvilke rettigheder blev ændret?
- Hvilke data blev læst eller flyttet?
Lav en liste over de spørgsmål, I ikke kunne besvare efter testen. Den er jeres prioriteringsliste.
Inddrag dem, der skal bruge loggene, når listen laves. Det kan være driften, en ekstern overvågningstjeneste eller den part, I vil ringe til ved en alvorlig hændelse. De ved, hvilke oplysninger de har savnet, og hvilke formater de kan arbejde med. En logning, der er bygget op uden dem, kan være fuldstændig og alligevel ubrugelig i en presset situation, fordi ingen ved, hvor tingene ligger. Skriv også ned, hvem der må læse loggene. De kan indeholde personoplysninger og oplysninger om jeres opsætning, og adgangen bør derfor være begrænset og selv blive registreret.
Kilderne i den rigtige rækkefølge
Ikke alle logkilder er lige vigtige. Begynd med dem, der kunne have besvaret flest af spørgsmålene fra testen.
- Identitet · logins og ændringer i konti og grupper i Active Directory og Entra ID. → Entra ID-test
- Fjernadgang · VPN, fjernskrivebord og andre veje ind udefra.
- Servere med central betydning · domænecontrollere, filservere og backupsystemet.
- Cloudtjenester · aktivitet i Microsoft 365, Azure og AWS, hvor standardopsætningen ikke altid gemmer det, I har brug for. → Logning i Microsoft 365, Azure og AWS
- Netværkets grænser · trafik mellem zoner og ud mod internettet.
Klienterne kan komme senere i rækkefølgen, fordi mængden er stor. Men hvis testen viste, at en almindelig klient var vejen ind, skal den med tidligt.
Opbevaring og beskyttelse
En log, der er væk, når I har brug for den, er ikke meget værd. NCSC påpeger, at det kan tage lang tid at opdage en hændelse, og nævner i sin vejledning at gemme de vigtigste logs i mindst seks måneder. Hvor længe I skal gemme, afhænger af jeres egne behov og eventuelle krav, I er underlagt.
- Centralt sted · loggene samles uden for de systemer, de stammer fra.
- Søgbart · I skal kunne finde det, I leder efter, uden at gennemgå filer manuelt.
- Beskyttet · den, der har overtaget et system, må ikke kunne ændre eller slette sporene. NCSC anbefaler at beskytte loggene mod manipulation.
- Plads nok · opbevaringen må ikke løbe fuld og stoppe, uden at nogen opdager det.
Opsyn, der virker
Logning uden opsyn er et arkiv. Det hjælper ved efterforskning, men opdager intet. Når grundlaget er på plads, skal I beslutte, hvad der skal give en alarm, og hvem der ser den.
Lad testens forløb være udgangspunkt for de første regler. Det, testeren gjorde, er et konkret eksempel på aktivitet, I gerne ville have set: en konto, der pludselig får nye rettigheder, logins fra uventede steder eller en tjenestekonto, der bruges interaktivt. NCSC anbefaler at basere alarmerne på de trusler, organisationen faktisk står over for. → Alarmer under testen
NCSC nævner også at kontrollere, at loggene stadig ankommer, fx med en advarsel, når en kilde holder op med at sende. Det er en lille opgave, der forhindrer, at en kilde stille forsvinder. Har en driftsleverandør eller en ekstern overvågningstjeneste ansvaret, skal aftalen sige, hvilke kilder der er med, hvad der giver alarm, og hvordan I får besked.
Det skal I lade være med
- At slå al logning til på én gang. Mængden drukner det vigtige og fylder opbevaringen.
- At samle uden at beskytte. Logs, en angriber kan slette, er ikke til at stole på.
- At bygge alarmer uden en modtager. En advarsel, ingen ser, svarer til ingen advarsel.
- At glemme cloudtjenesterne. Standardopsætningen dækker ikke altid behovet.
- At regne med, at en kilde stadig sender. Kontrollér det løbende.
- At lade fundet vente til næste test. Opbygningen er driftsarbejde, der kan starte nu.
Hvad kan og ikke kan konkluderes
Efter opbygningen kan I vise, hvilke spørgsmål logningen nu kan besvare, og hvilke kilder der samles, beskyttes og overvåges. Det viser ikke, at et angreb vil blive opdaget i tide. Det kan kun afprøves, og en ny test eller en øvelse kan vise, om sporene nu findes og bliver set.
Tjekliste til logningen efter testen
- ☐ Er hvert logfund placeret: ingen registrering, ikke samlet, væk, ikke set eller ikke til at stole på?
- ☐ Findes der en liste over spørgsmål, I ikke kunne besvare efter testen?
- ☐ Er kilderne prioriteret ud fra den liste?
- ☐ Samles loggene centralt, søgbart og beskyttet mod ændring?
- ☐ Er opbevaringstiden besluttet ud fra jeres behov?
- ☐ Er der alarmer baseret på testens forløb, og en modtager for dem?
- ☐ Bliver det opdaget, hvis en kilde holder op med at sende?
Kilder
- NCSC: 10 Steps, Logging and monitoring: planlæg logning ud fra de spørgsmål, en hændelse rejser; beskyt logs mod manipulation; gem de vigtigste logs i mindst seks måneder; kontrollér, at logs stadig ankommer; alarmer ud fra de trusler, organisationen står over for.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Beredskabsplanen efter testen · Læring i driften efter testen
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
