Forside › Tjeklister og skabeloner · Gennemgået oktober 2026 · Af John Nielsen
Når en kunde ringer med en hændelse, er MSP’en ofte den første med teknisk adgang. Det, der sker i de første timer, afgør, om der senere kan dokumenteres, hvad der skete, og hvem der bar ansvaret. Det gælder både ved sikkerhedshændelser, ved mistanke om en medarbejders misbrug og ved nedbrud, der kan ende i en tvist. Denne tjekliste samler de tekniske trin: hvad der sikres straks, hvad der ikke røres, hvordan egne indgreb dokumenteres, og hvornår der bør hentes en uvildig ind.
Haster det? Loginlogs, firewall- og VPN-logs og hukommelsen på berørte maskiner kan være væk inden for timer eller dage, især når kunden selv er begyndt at rydde op. Se akut forensisk sikring; hastesager koster ekstra.
En kortere version af IT-leverandørens første time findes på bevissikring-digitalt.dk. Her er den tekniske udgave.
Opkaldet
- ☐ Notér tidspunkt, hvem der ringer, og hvad der præcist er observeret.
- ☐ Spørg, hvad kunden selv har gjort indtil nu: genstartet, slettet, nulstillet adgangskoder, kørt scanninger.
- ☐ Afklar, hvem hos kunden der kan træffe beslutninger, og hvem der skal informeres.
- ☐ Afklar, om der er en advokat, et forsikringsselskab eller en incident response-leverandør inde i billedet.
- ☐ Start en indgrebslog fra første minut.
Mandat og aftalegrundlag
- ☐ Afklar, om kontrakten med kunden dækker hændelseshåndtering og bevissikring, eller om der skal laves en særskilt aftale.
- ☐ Få kundens beslutninger skriftligt, fx en mail, når der skal isoleres, slukkes eller geninstalleres.
- ☐ Afklar, hvem der må se det sikrede materiale, især hvis det indeholder persondata eller data om kundens medarbejdere.
- ☐ Vær forsigtig med at gå videre end opdraget, fx ved at gennemgå en medarbejders private filer, uden at kunden har taget stilling.
Hvad der sikres straks
De mest flygtige spor først:
- ☐ Loginlogs i cloudtjenester med kort opbevaring, fx Entra ID.
- ☐ Tilstanden på kompromitterede konti: regler, videresendelse, MFA-metoder, enheder og app-samtykker, før de ryddes op.
- ☐ Firewall-, VPN- og proxy-logs, der roterer hurtigt.
- ☐ EDR-telemetri for de berørte endpoints.
- ☐ RAM og kørende processer på berørte maskiner, hvis der er mistanke om aktiv skadelig kode eller fjernadgang.
- ☐ Backup-tilstanden: hvilke backups findes, hvornår er de taget, og er de intakte.
Ved hændelser i Microsoft 365 er listen udfoldet i tjekliste: logs at sikre i Microsoft 365.
Hvad der ikke røres
- ☐ Geninstallér, nulstil eller slet ikke maskiner og konti, før de er sikret, eller før kunden har truffet en dokumenteret beslutning.
- ☐ Kør ikke oprydningsværktøjer, defragmentering eller “fuld scanning med sletning” på berørte maskiner.
- ☐ Slet ikke logs, alarmer, mails eller filer, heller ikke ondsindede filer. Isolér dem i stedet.
- ☐ Log ikke ind som brugeren på den berørte maskine for at “se efter”.
- ☐ Ændr ikke opbevaringspolitikker, auditindstillinger eller logkonfiguration, uden at det noteres.
Spørgsmålet om, hvorvidt en maskine skal geninstalleres, er gennemgået i tjekliste: før reinstallation.
Inddæmning med dokumentation
Driften og sikkerheden skal genoprettes, og det kan ikke vente på en fuld sikring. Inddæmning og sikring kan dog normalt kombineres:
- ☐ Isolér maskiner via EDR eller netværk frem for at slukke dem, hvor det er muligt.
- ☐ Blokér konti og tilbagekald sessioner, efter at tilstanden er dokumenteret.
- ☐ Notér hvert indgreb med tidspunkt, system, handling og hvem der udførte det.
- ☐ Gem output fra kommandoer og scripts, der køres under hændelsen.
Loggen over indgreb er det, der senere gør det muligt at skelne MSP’ens handlinger fra angriberens eller brugerens. Se log over indgreb under incident response. Samspillet mellem forensics og incident response er beskrevet i forensic eller incident response.
MSP’ens egen rolle
En MSP har ofte selv administratoradgang, fjernadgangsværktøjer og egne konti i kundens miljø. Det betyder, at MSP’ens egne logs og handlinger kan blive en del af sagen, og at MSP’en i nogle tilfælde kan være part. Hvordan drift og undersøgelse holdes adskilt, er beskrevet i MSP’ens egen rolle.
- ☐ Sikr logs fra eget RMM-værktøj og egne fjernadgangsløsninger for den relevante periode.
- ☐ Sikr egne tickets og kommunikation med kunden om sagen.
- ☐ Notér, hvilke af MSP’ens konti der har adgang til kundens systemer.
- ☐ Vær opmærksom på, om hændelsen kan hænge sammen med MSP’ens egne systemer eller ydelser.
Hvis kunden giver MSP’en skylden for hændelsen, er det afgørende, at sikringen ikke foretages af de samme folk, der skal forklare egne handlinger. Leverandørens synsvinkel i den situation er beskrevet på bevissikring-digitalt.dk, og sporene efter leverandørens adgang i IT-leverandørens adgang: RMM-logs.
Kommunikation under hændelsen
- ☐ Brug en kommunikationskanal, der ikke er kompromitteret. Er kundens mail overtaget, må aftaler ikke sendes via den.
- ☐ Hold en fælles statusliste med kunden over, hvad der er sikret, hvad der er i gang, og hvad der venter.
- ☐ Skriv faktuelt og med tidspunkter i tickets og mails. De kan blive fremlagt senere.
- ☐ Undgå at konkludere om årsag og ansvar i den løbende kommunikation, før analysen er lavet.
Hvornår en uvildig skal ind
- ☐ Der er udsigt til en tvist, en ansættelsessag, en forsikringssag eller en sag mod en tredjepart.
- ☐ MSP’en kan selv være part eller have en interesse i udfaldet.
- ☐ Hændelsen involverer en administrator, herunder MSP’ens egne medarbejdere.
- ☐ Kunden har brug for en rapport, der kan fremlægges for en modpart eller en domstol.
- ☐ Opgaven kræver forensiske værktøjer eller kompetencer, MSP’en ikke har.
En uvildig IT-sagkyndig kan foretage eller kontrollere sikringen og senere forklare den uden at være bundet af kundeforholdet. Det fritager ikke MSP’en for at sikre de flygtige data i mellemtiden. Det, MSP’en har sikret og dokumenteret korrekt, kan den uvildige bygge videre på, og indgrebsloggen bliver et vigtigt bilag. Samme overvejelser for en SOC er beskrevet i Hvornår SOC’en skal kalde en uvildig ind.
Dokumentation
- ☐ Hver eksport gemmes i oprindeligt format med filnavn, der angiver kilde og periode.
- ☐ Hver fil hashes, og værdien noteres i en hashliste.
- ☐ Hver eksport noteres med værktøj, kommando, konto og tidspunkt.
- ☐ Materialet opbevares adskilt fra kundens kompromitterede miljø og fra MSP’ens almindelige drift.
- ☐ Overdragelser registreres med dato, tidspunkt og modtager.
Efter de første timer
- ☐ Aftal skriftligt med kunden, hvad der er sikret, hvad der ikke er, og hvem der har materialet.
- ☐ Aftal, hvem der har ansvaret for den videre sikring og analyse.
- ☐ Gennemgå opbevaringstider for de kilder, der ikke er sikret endnu, og planlæg dem.
- ☐ Notér huller: data, der allerede var væk, da MSP’en kom ind.
Forbered næste opkald
- ☐ Hav en opdateret oversigt pr. kunde over logkilder, opbevaringstider, licenser og administratorer.
- ☐ Hav eksportscripts og fremgangsmåder klar og afprøvet, så de ikke skal skrives under tidspres.
- ☐ Hav en skabelon til indgrebslog og hashliste klar.
- ☐ Aftal på forhånd med kunderne, hvem der kontaktes, hvis en sag kræver en uvildig.
- ☐ Gennemgå efter hver hændelse, hvad der manglede, og opdater oversigten.
Typiske fejl
- Maskinen geninstalleres som standardprocedure, før det er afklaret, om der er en sag.
- Kompromitterede konti ryddes op, før regler og enheder er dokumenteret.
- MSP’en undersøger sin egen rolle i en sag, hvor kunden retter kritik mod MSP’en.
- Indgreb udføres uden notater og kan senere ikke skelnes fra angriberens handlinger.
- Logs, der roterer om få dage, sikres først, når der er truffet beslutning om at gå videre.
Kilder og versioner
- NIST SP 800-61 Rev. 3: håndtering af sikkerhedshændelser
- RFC 3227: indsamling efter flygtighed
- Microsoft Learn: opbevaring af data i Microsoft Entra
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Tjeklister og skabeloner
Læs også: Tjekliste: tekniske trin ved sikring af en mobiltelefon · Forensic-arbejdsstationen: krav til opsætning og isolation · Alle skabeloner og værktøjer
→ Tjeklister og skabeloner · For MSP’er · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
