Forside › Undersøgelse efter et hackerangreb · Gennemgået oktober 2026 · Af John Nielsen
Når et forsikringsselskab afviser eller nedsætter en erstatning efter en cyberhændelse, er begrundelsen ofte, at et sikkerhedskrav ikke var opfyldt: MFA på fjernadgang, rettidig patching, adskilt backup eller dækning med EDR. Spørgsmålet er da, hvordan det så ud på et bestemt tidspunkt før hændelsen, ikke hvordan det ser ud i dag. Det kan i mange tilfælde dokumenteres bagudrettet ud fra auditlogs over konfigurationsændringer, loginlogs, opdateringshistorik og backuplogs, men kun hvis de sikres hurtigt og fortolkes med omtanke for forskellen mellem politik og faktisk effekt.
Hvordan virksomheden håndterer afslaget og klagevejen, er beskrevet i Cyberforsikringen afviser kravet. Her handler det om den tekniske dokumentation.
Politik og effekt er to forskellige ting
Den største faldgrube er at dokumentere den konfigurerede politik i stedet for den faktiske effekt. En politik for betinget adgang, der kræver MFA, siger ikke noget om de konti, der var undtaget, de klienter, der brugte ældre godkendelse, eller de servicekonti, der loggede ind uden for politikken. En opdateringspolitik siger ikke noget om de servere, der ikke var med i den.
Dokumentationen bør derfor altid bestå af to dele: konfigurationen, som den var på tidspunktet, og bevis for, hvordan den virkede i praksis i perioden. Forsikringsselskabets tekniske rådgiver vil typisk gå direkte efter undtagelserne.
MFA
Konfigurationen på tidspunktet
I Microsoft Entra ID registrerer auditloggen ændringer af politikker for betinget adgang, sikkerhedsstandarder og godkendelsesmetoder. Ved at gå gennem ændringerne baglæns fra i dag kan politikkens tilstand på et bestemt tidspunkt rekonstrueres, forudsat at auditloggen rækker langt nok tilbage. Ændringer af MFA-metoder og registreringer er beskrevet i MFA-ændringer og betinget adgang i Entra ID-loggene.
Effekten i praksis
Loginloggen viser for hvert login, om MFA blev krævet og opfyldt, hvilken politik der blev anvendt, og om login skete med ældre godkendelse. En analyse af alle logins i perioden før hændelsen kan vise, hvor stor en andel der var dækket, og hvilke konti der ikke var. Se Entra ID-loginlogs.
For VPN og anden fjernadgang ligger MFA ofte i en separat løsning, fx en RADIUS-server eller en identitetsudbyder. Dens logs skal sikres for sig, og det skal dokumenteres, om VPN-løsningen overhovedet var koblet til den.
Opbevaring
Loginlogs og auditlogs har begrænset opbevaring i standardopsætningen. I Entra ID var det på tidspunktet for gennemgangen (oktober 2026) 7 dage uden betalt licens og 30 dage med P1 eller P2. Hvis hændelsen ligger måneder tilbage, kan de relevante data allerede være væk, medmindre de er sendt til et SIEM eller et lager. Sikr straks det, der findes, og dokumentér, hvor langt tilbage det rækker.
Patchniveau
Patchniveauet på hændelsestidspunktet kan ofte rekonstrueres fra flere uafhængige kilder:
- Opdateringsstyring. Rapporter og databaser fra opdateringsløsningen, fx Intune, WSUS eller Configuration Manager, viser, hvilke opdateringer der var godkendt, og hvornår hver maskine rapporterede dem installeret. Se MDM og Intune som datakilde.
- Maskinen selv. Windows registrerer installation af opdateringer i hændelseslogs og i opdateringshistorikken. En forensisk kopi af en server kan vise, hvilke opdateringer der var installeret, og hvornår.
- Sårbarhedsscanninger. Rapporter fra scanninger før hændelsen kan vise, hvilke sårbarheder der var kendt på hvilke systemer.
- Netværksudstyr. Firewall og VPN-udstyr har firmwareversioner, der fremgår af konfigurationsbackups og administrationslogs.
Det centrale spørgsmål er sjældent “var alt opdateret”, men “var den konkrete sårbarhed, der muligvis blev udnyttet, lukket på det konkrete system på det konkrete tidspunkt”. Det kræver datoen for, hvornår opdateringen blev tilgængelig, datoen for installationen og sammenhængen med indgangsvejen.
Backup
Backupkravet handler typisk om, at backuppen var adskilt fra produktionsmiljøet, at den var beskyttet mod sletning, og at den blev testet. Dokumentationen findes i backupsystemets konfiguration, jobhistorik og auditlog og i lagerets egne logs. Fremgangsmåden er beskrevet i Backup-logs: hvornår blev backuppen slettet eller ændret?.
EDR og logning
Krav om EDR-dækning kan dokumenteres med EDR-platformens inventar: hvilke maskiner havde en agent, hvornår blev de sidst set, og var beskyttelsen aktiv. Inventaret viser også de maskiner, der manglede, og det er dem, rådgiveren vil spørge til. Krav om logning dokumenteres med konfigurationen af logkilder og med de faktiske logs. At en log findes for perioden, er det stærkeste bevis for, at logningen var slået til.
Forensiske kopier og backup som tidskapsler
Når auditlogs ikke rækker langt nok tilbage, kan tilstanden på et bestemt tidspunkt ofte findes i data, der blev gemt af andre grunde. En forensisk kopi af en server taget under hændelsen viser installerede opdateringer, lokale politikker og agenter, som de var. Gamle gendannelsespunkter fra backup kan gendannes til et isoleret miljø og undersøges for patchniveau og konfiguration på et tidligere tidspunkt. Konfigurationsbackups af firewalls og VPN-udstyr, som mange IT-leverandører tager automatisk, viser regler, firmwareversioner og godkendelsesopsætning.
Den slags kilder har den fordel, at de ikke er lavet til tvisten. De er skabt i den daglige drift, og det giver dem vægt. Men de skal behandles med samme omhu som andre beviser: hashværdi, dokumenteret gendannelse og en klar angivelse af, hvilket tidspunkt de afspejler.
Hvem har dataene?
En stor del af dokumentationen ligger ofte hos IT-leverandøren: opdateringsrapporter, konfigurationsbackups, adgang til administrationsportaler og historik i ticketsystemet. Er leverandøren selv part i spørgsmålet om, hvorfor kravet ikke var opfyldt, er der en interessekonflikt i, hvem der udtrækker data. Bed om rådata frem for sammenfatninger, og bed om, at udtrækket dokumenteres, så det kan gentages af en uafhængig.
Spørgeskemaet
Mange tvister handler om svarene i forsikringens spørgeskema. Hvis svaret var “MFA på al fjernadgang”, skal dokumentationen vise, om det var rigtigt på tidspunktet for besvarelsen og på tidspunktet for hændelsen. Sammenlign derfor svarene punkt for punkt med de tekniske data, og vær ærlig om afvigelser. En afvigelse, der dokumenteres og forklares, står bedre end en, der opdages af modparten.
Faldgruber
- Dagens skærmbillede som bevis for fortiden. Konfigurationen i dag kan være ændret efter hændelsen, ofte netop som reaktion på den.
- Ændringer efter hændelsen. Når MFA strammes og systemer patches i genopretningen, overskrives den tidligere tilstand. Eksportér konfigurationen før ændringerne, hvis det kan nås.
- Undtagelser og servicekonti. De er sjældent synlige i den overordnede politik.
- Leverandørens rapporter. En månedsrapport fra IT-leverandøren om patchstatus er en sekundær kilde. Den bør bekræftes mod primære data.
- Tidsmæssig præcision. “Patchet i marts” er ikke nok, hvis sårbarheden blev udnyttet den 10. marts.
Dokumentation
Opbyg dokumentationen som en tabel over de krav, forsikringen henviser til. For hvert krav: kravets formulering, konfigurationen på tidspunktet med kilde, den faktiske effekt med kilde, undtagelser og huller, og en vurdering af, om kravet var opfyldt. Hold vurderingen adskilt fra fakta, så forsikringsselskabets rådgiver kan se præcist, hvor eventuel uenighed ligger. Leverancerne til forsikringsselskabet generelt er beskrevet i Cyberforsikringen: de tekniske leverancer.
Kilder og versioner
- Microsoft Learn: opbevaring af data i Microsoft Entra
- Microsoft Learn: loginlogs i Microsoft Entra
- Microsoft Learn: opbevaring af Microsoft 365-auditloggen
Senest gennemgået: oktober 2026.
Næste skridt
- Forensic eller incident response? Forskellen og samspillet
- Log over indgreb under incident response
- Ransomware: bevissikring parallelt med genopretning
Del af: Undersøgelse efter et hackerangreb
Læs også: Cyberforsikringen: de tekniske leverancer, forsikringsselskabet beder om · Persondatabrud på 72 timer: de tekniske fakta, der skal være fastlagt
→ Undersøgelse efter et hackerangreb · Haster det? Forensisk sikring (hastesager koster ekstra) · For sagkyndige · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
