Forside › Tjeklister og skabeloner · Gennemgået oktober 2026 · Af John Nielsen
Digital forensics læres bedst ved at kombinere tre ting: solid viden om, hvordan styresystemer, filsystemer og netværk virker, forståelse af metoden, altså sikring, verifikation, analyse og rapport, og praktisk øvelse på data, hvor svaret er kendt på forhånd. Værktøjerne kommer til sidst. Den, der kan forklare, hvad et artefakt er, og hvorfor det kan tage fejl, bliver en bedre analytiker end den, der kun kan betjene et program.
Artiklen er til IT-folk, der vil i gang med faget, eller som skal kunne samarbejde med en IT-sagkyndig. Den giver en læserækkefølge her på sitet og neutrale henvisninger til fagmiljøer og ressourcer, uden at anbefale bestemte kurser eller produkter.
Forudsætningerne
Før de forensiske emner giver mening, bør grundlaget være på plads:
- Styresystemer · Artefakter er bivirkninger af, hvordan Windows, macOS, Linux, iOS og Android arbejder
- Filsystemer · Tidsstempler, sletning og gendannelse afhænger af NTFS, APFS, ext4 og andre
- Netværk · Logs fra firewalls, VPN, DNS og proxyer forudsætter kendskab til protokoller og adresser
- Identitet og cloud · Mange sager handler om konti, logins og auditlogs i cloudtjenester
- Databaser og formater · Apps gemmer data i SQLite, plist, JSON og lignende
- Scripting · Gentagelige udtræk, parsing og kontrol af værktøjers resultater
Mange med baggrund i drift, netværk eller IT-sikkerhed har allerede meget af dette. Det nye er ofte metoden og disciplinen i dokumentationen.
Læserækkefølge på sitet
Rækkefølgen bygger fra begreber til praksis:
- Faget og begreberne. Start med hvad er digital forensics og slå termer op i ordbogen.
- Standarderne. Læs om ISO/IEC 27037 og NIST SP 800-86, som beskriver de grundlæggende principper for identifikation, sikring og analyse.
- Sikring og integritet. Forensiske kopier, skrivebeskyttelse, hashværdier og kæde af ansvar (chain of custody).
- Tid. Tidsstempler, tidszoner og urafvigelser er den hyppigste fejlkilde. Læs tidslinjeanalyse tidligt.
- Platformene. Vælg den platform, du arbejder mest med, og gå i dybden med dens artefakter og logs, før du breder dig.
- Fortolkning og fejlkilder. Læs fejlkilder i digital forensics og artiklerne om attribution, fravær af spor og bias.
- Rapporten. Afslut med rapportskrivning, fordi det er her, alt det foregående skal kunne forklares.
Brug tematiske oversigter på bloggen til at finde artiklerne om hver platform og hvert emne.
Øv på kendte data
Den vigtigste læring sker, når du selv laver en handling og bagefter finder sporene af den. Byg et lille testmiljø:
- en virtuel maskine med Windows og en med Linux, som du kan nulstille,
- en gammel telefon, som du nulstiller og bruger som testenhed,
- en testkonto i en cloudtjeneste, hvor du kan generere logs,
- en notesbog, hvor du skriver hver handling ned med tidspunkt.
Lav så handlingerne: tilslut et USB-drev, åbn en fil, slet den, send en mail, skift tidszone, kopiér en mappe. Sikr maskinen, og find sporene. Passer de med dine noter? Hvor afviger de, og hvorfor? Fremgangsmåden svarer til den, der bruges til at teste værktøjer, beskrevet i testdatasæt og referencedata.
Øv kun på egne enheder, egne konti og data, du har lov til at bruge. Faget handler om lovlig sikring og analyse, og det gælder også, når man øver.
Offentlige testdata og udfordringer
Der findes offentligt tilgængelige diskimages, hukommelsesdumps og mobiludtræk, der er lavet til undervisning og test, med kendte scenarier og ofte med svar. Nogle stammer fra standardiseringsorganer og forskningsmiljøer, fx NIST’s samling af referencedatasæt (CFReDS), andre fra konferencer og fællesskaber, der laver forensiske udfordringer. De giver mulighed for at øve på realistiske data uden at røre persondata.
Brug svarene til at kontrollere dig selv, men læg mærke til, hvordan du kom frem til resultatet. I en sag er det metoden, der bliver efterprøvet.
Fagmiljøer og kilder
Nogle typer kilder går igen, når faget skal følges:
- Standarder og retningslinjer fra ISO/IEC, NIST og det europæiske netværk af forensiske institutter (ENFSI). De ændrer sig langsomt og er grundlaget for metoden.
- Forskningskonferencer med offentligt tilgængelige artikler, fx DFRWS, hvor nye artefakter og metoder beskrives og afprøves.
- Leverandørdokumentation fra Microsoft, Apple, Google og andre platforme om logs, opbevaring og eksport. Den er ofte den eneste autoritative kilde til, hvad en logpost betyder, men den ændres løbende.
- Open source-fællesskaber, hvor værktøjer til parsing af artefakter udvikles. Kildekoden viser præcis, hvordan et artefakt fortolkes.
- Faglige netværk for IT-sikkerhed og incident response, hvor erfaringer med konkrete platforme deles.
Vær kritisk over for blogindlæg og videoer, der viser en metode uden at forklare, hvorfor den virker, og hvornår den ikke gør. Kontrollér påstande om et artefakts betydning mod testdata eller leverandørens dokumentation.
Uddannelse og certificering
Der findes kurser og certificeringer fra både uafhængige organisationer, uddannelsesinstitutioner og værktøjsleverandører. Leverandørernes kurser lærer typisk deres eget værktøj. Uafhængige kurser og akademiske forløb lægger mere vægt på metoden. Begge har deres plads, men en certificering er ikke i sig selv et bevis for, at en analyse er korrekt. I en sag er det dokumentationen af den konkrete metode, der tæller. Udbuddet på dansk er begrænset, og meget af faglitteraturen og undervisningen foregår på engelsk.
Typiske begynderfejl
Visse fejl går igen hos dem, der er nye i faget, og de er værd at kende fra starten:
- Værktøjet tages for sandheden. Et fund i en pæn rapport fra et værktøj kontrolleres ikke i de underliggende data.
- Tidszoner ignoreres. Tidsstempler fra forskellige kilder sammenlignes uden normalisering.
- Et artefakt overfortolkes. En LNK-fil eller en logpost tages som bevis for en brugerhandling, selvom systemet selv kan have skabt den.
- Fravær tolkes som bevis. At der ikke er fundet noget, betyder ikke, at intet er sket, hvis kilden ikke dækker spørgsmålet.
- Noter skrives bagefter. Notater, der rekonstrueres efter analysen, er svagere og mere upræcise end samtidige noter.
- Én hypotese. Analysen søger kun efter det, der bekræfter den første forklaring, og overser det, der taler imod.
Øvelse på testdata er den bedste måde at opdage disse fejl hos sig selv, før de opstår i en rigtig sag. Det hjælper også at få en erfaren kollega til at gennemgå egne analyser og stille de spørgsmål, en modpart ville stille.
Fra IT-drift til forensics
For den, der kommer fra IT-drift, er de største omstillinger typisk:
- at dokumentere alt undervejs, ikke kun resultatet,
- at arbejde på kopier og aldrig på originalen,
- at skelne mellem det, data viser, og det, man slutter,
- at beskrive usikkerhed og alternative forklaringer,
- at kunne forklare et teknisk fund for en ikke-teknisk læser.
Det er de samme egenskaber, der gør en IT-afdeling til en god samarbejdspartner, når en uvildig IT-sagkyndig skal ind i en sag. Selv uden at arbejde med forensics på fuld tid gør kendskabet til metoden det lettere at sikre data korrekt i de første timer.
Kilder og versioner
- NIST CFReDS: referencedatasæt til digital forensics
- DFRWS: forskningskonferencer og udfordringer
- ENFSI: European Network of Forensic Science Institutes
- NIST SP 800-86: integration af forensiske teknikker i hændelseshåndtering
Senest gennemgået: oktober 2026.
Næste skridt
- Tjekliste: før reinstallation eller udskiftning af en maskine
- Tjekliste til MSP’er: når kunden ringer med en hændelse
Del af: Tjeklister og skabeloner
Læs også: Forensic-arbejdsstationen: krav til opsætning og isolation · Tjekliste: forensisk sikring af en computer · Alle skabeloner og værktøjer
→ Tjeklister og skabeloner · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
