Forside › Kvalitet og standarder · Gennemgået oktober 2026 · Af John Nielsen
Valget af værktøj er sjældent det, der afgør et bevis. Det afgørende er, at værktøjet er egnet til den konkrete datatype, at det bruges korrekt, og at brugen kan dokumenteres og efterprøves. Denne artikel beskriver værktøjskategorierne, de krav, et forensisk værktøj bør opfylde, og hvordan et valg begrundes i en rapport. Den anbefaler ikke bestemte produkter.
Både kommercielle værktøjer og open source bruges i faget. Mange undersøgelser kombinerer flere: ét til sikring, ét eller flere til analyse og et tredje til at kontrollere de vigtigste fund.
Kategorier
- Sikring (imaging) · Kopiere lagermedier til forensiske formater med hashværdier og logfil
- Skrivebeskyttelse · Forhindre ændringer på kildemediet, i hardware eller software
- Hukommelse · Sikre og analysere RAM: processer, netværksforbindelser, nøgler
- Mobil · Logiske udtræk, filsystemudtræk, parsing af app-databaser
- Cloud · Indsamling via tjenesternes API’er og eksportfunktioner, med logning
- Analyseplatforme · Samlet analyse af filsystemer, artefakter, søgning og tidslinjer
- Specialværktøjer · Enkelte artefakter: registreringsdatabase, browserdata, logs, mails
- Tidslinjer · Samle tidsstempler på tværs af kilder
- eDiscovery · Behandling, søgning og gennemgang af store dokumentmængder
- Rapportering · Udtræk, bilag og rapportskabeloner
Formaterne, som sikringsværktøjer skriver, har betydning for, hvilke metadata og hashværdier der følger med kopien. Det er beskrevet i forensiske diskformater. Hardware- og softwarebaseret skrivebeskyttelse er beskrevet i skrivebeskyttere.
Krav til et forensisk værktøj
Uanset kategori bør et værktøj:
- ikke ændre kilden, eller dokumentere præcist, hvad det ændrer, fx når en telefon skal have installeret en hjælpeapp for at kunne lave et udtræk,
- beregne og registrere hashværdier for det sikrede,
- logge, hvad det har gjort, med version, indstillinger og tidspunkter,
- give gentagelige resultater på de samme data med de samme indstillinger,
- vise, hvor et fund kommer fra: fil, database, tabel, post eller offset,
- være kendt og afprøvet i faget, eller være valideret af den, der bruger det.
Kravet om sporbarhed til kilden er det, der oftest skiller et egnet værktøj fra et uegnet. Et værktøj, der viser en pæn liste over beskeder, men ikke kan pege på den underliggende database og post, gør det svært at efterprøve fundet.
Hvad værktøjer typisk tager fejl af
Fejl i forensiske værktøjer er sjældent dramatiske. De er typisk små tolkningsfejl, der kan få stor betydning:
- Tidsstempler: forkert epoke, forkert enhed (sekunder eller millisekunder) eller forkert antagelse om tidszone.
- Nye app-versioner: en app ændrer sin databasestruktur, og værktøjet viser færre poster eller blander felter.
- Slettede poster: rester i en database tolkes som aktive, eller aktive poster mangler.
- Tegnsæt: danske tegn og emojis vises forkert, så søgninger ikke rammer.
- Dubletter: samme besked vises flere gange, fordi den findes i flere kilder på enheden.
Derfor skal fund, der bærer en konklusion, kontrolleres i de underliggende data. Fremgangsmåden er beskrevet i verifikation af værktøjer.
Værktøjer i felten
Ved sikring på stedet gælder særlige hensyn. Udstyret skal kunne fungere uden netværk, og det skal være forberedt, før det tages med: opdaterede versioner, testede skrivebeskyttere, nok lagerplads til kopierne og et fast sted at notere tidspunkter og serienumre. Et sikringsværktøj, der fejler halvvejs gennem en stor disk, koster tid, som ikke altid er til stede, når en server kun må tages ud af drift i et kort vindue.
Det er også en god idé at kende værktøjets opførsel ved læsefejl. En læserækkefølge for nye i faget står i Kom i gang med digital forensics. Nogle værktøjer springer dårlige sektorer over og noterer det i loggen, andre stopper. Loggen skal gemmes sammen med kopien, fordi den dokumenterer, hvilke dele af mediet der ikke kunne læses.
Test før brug i en sag
Før et nyt værktøj eller en ny version bruges i en sag, bør det afprøves på data, hvor resultatet er kendt på forhånd. Det behøver ikke være et stort projekt: en testtelefon med kendte beskeder eller en lille disk med kendte filer og sletninger afslører de mest almindelige fejl. Testen og resultatet gemmes, så det senere kan dokumenteres, at værktøjet var kontrolleret.
Kommercielt eller open source?
Begge dele bruges i praksis, og ingen af dem er i sig selv mere korrekte. Kommercielle værktøjer har ofte bred understøttelse af apps og telefoner, support og hyppige opdateringer. Open source-værktøjer er gennemsigtige, fordi koden kan undersøges, og de er ofte specialiserede i ét artefakt eller én filtype.
Det, der betyder noget, er ikke licensformen, men at værktøjet er egnet til den konkrete opgave, at versionen er kendt, og at resultatet er kontrolleret. En modpart kan stille spørgsmål til begge typer: til kommercielle værktøjer om lukket kode, til open source om test og vedligeholdelse.
Mere end ét værktøj
Vigtige fund bør bekræftes med et andet værktøj eller ved manuel kontrol af de underliggende data. Værktøjer kan tolke det samme artefakt forskelligt, især nye eller sjældne formater. Hvis to værktøjer giver forskellige resultater, skal forskellen forklares, ikke bare det ene resultat vælges.
En tidslinje på tværs af kilder bygges ofte med et særskilt værktøj eller manuelt i et regneark ud fra flere værktøjers output. Det kræver, at tidsstempler er normaliseret til samme tidszone og format, som beskrevet i tidslinjeanalyse.
Versioner og reproducerbarhed
Værktøjer opdateres ofte, og en ny version kan tolke data anderledes end den forrige. Notér den præcise version i rapporten, og gem om muligt installationen eller en kopi af den version, der blev brugt. Så kan analysen gentages, hvis resultatet senere bliver bestridt, også selvom leverandøren har udgivet nye versioner.
Licensnøgler, opdateringer af parsing-moduler og indstillinger for fx tidszone bør også dokumenteres. To kørsler med samme version, men forskellige indstillinger, kan give forskellige resultater.
Begrundelse af valget i rapporten
Rapporten behøver ikke forklare, hvorfor ét produkt er valgt frem for et andet. Den skal vise, at værktøjet var egnet:
- hvilke værktøjer der er brugt til hvilke dele af undersøgelsen,
- versioner og relevante indstillinger,
- hvordan centrale fund er kontrolleret,
- kendte begrænsninger for den pågældende datatype.
Det sidste punkt er vigtigt. Hvis et værktøj ikke understøtter en bestemt app-version, eller hvis en del af et udtræk ikke kunne behandles, skal det stå under begrænsninger.
Værktøjet erstatter ikke fagligheden
Et værktøj erstatter ikke faglig forståelse. Den sagkyndige skal kunne forklare, hvad værktøjet viser, hvor dataene kommer fra, hvordan de er tolket, og hvilke begrænsninger der er. Det er ofte netop det, der bliver prøvet, når en sagkyndig afgiver forklaring. Hvordan det foregår set fra advokatens side, er beskrevet i krydsforhør af en IT-sagkyndig. Forskellen på at købe et værktøj og at bruge en sagkyndig er beskrevet på digital-bevissikring.dk.
Standarder
Krav om egnede og validerede metoder går igen i de internationale standarder for håndtering af digitale beviser. ISO/IEC 27041 handler specifikt om at sikre, at undersøgelsesmetoder er egnede. Se ISO/IEC 27037 og NIST SP 800-86 for et overblik over standardfamilien.
Kilder og versioner
- NIST: Computer Forensics Tool Testing Program (CFTT)
- NIST: Computer Forensic Reference Data Sets (CFReDS)
- ISO/IEC 27041: sikring af, at undersøgelsesmetoder er egnede
Senest gennemgået: oktober 2026.
Næste skridt
- ISO/IEC 27041: sikring af, at metoden er egnet
- ISO/IEC 27042: analyse og fortolkning af digitale beviser
- ISO/IEC 27043: principper og processer for hændelsesundersøgelser
- ISO/IEC 17025 og digital forensics: hvad standarden kræver
Del af: Kvalitet og standarder
Læs også: ISO/IEC 30121: forensic readiness som styringsramme · ISO/IEC 27037 og NIST SP 800-86 forklaret
→ Second opinion på en IR- eller forensic-rapport · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT