Verifikation af forensiske værktøjer: test, validering og kontrol af fund

Forside › Kvalitet og standarder · Gennemgået oktober 2026 · Af John Nielsen

Et forensisk værktøj er software, og software kan have fejl. Et værktøj kan tolke et tidsstempel forkert, overse poster i en database eller vise en slettet besked som aktiv. Derfor er det ikke nok at skrive “værktøjet viste”. Den sagkyndige skal kunne begrunde, at værktøjet er egnet til datatypen, og kontrollere de fund, sagen afhænger af.

Verifikation handler ikke om mistillid til et bestemt produkt. Det handler om, at resultatet skal kunne stå alene, også hvis værktøjet senere viser sig at have en fejl i netop den version, der blev brugt. Standardens ramme for egnede metoder er beskrevet i ISO/IEC 27041, og standarderne samlet i ISO/IEC 27037 og NIST SP 800-86 forklaret. Her handler det om praksis: test af værktøjet og kontrol af de fund, sagen bygger på.

To niveauer

Værktøjsvalidering · Fungerer værktøjet generelt korrekt til denne type data? Test med kendte data og kendte resultater.
Verifikation af fund · Er netop dette fund korrekt? Kontrol i de underliggende data, med et andet værktøj eller manuelt.

Begge dele er nødvendige. Et værktøj, der er valideret til en bestemt beskedapp, kan stadig fejle, når appen opdateres og ændrer sin databasestruktur. Omvendt kan et enkelt fund godt verificeres manuelt, selvom værktøjet ikke er formelt valideret til datatypen.

Validering med kendte data

Princippet er enkelt: Lav et datasæt, hvor du ved præcis, hvad der er, og se, om værktøjet finder det.

Opret testdata: fx en testtelefon med kendte beskeder og opkald, en disk med kendte filer, sletninger og tidsstempler, eller en testpostkasse med kendte mails og regler.
Dokumentér forventede resultater før testen, så resultatet ikke tilpasses bagefter.
Kør værktøjet med de indstillinger, der bruges i praksis.
Sammenlign resultatet med det forventede, felt for felt.
Gem testen, så den kan gentages ved nye versioner.

Testdata bør dække de situationer, der typisk giver problemer: slettede poster, danske tegn, beskeder med vedhæftninger, tidsstempler omkring skift mellem sommer- og vintertid og poster fra flere tidszoner. Offentligt tilgængelige testdatasæt og testrapporter kan bruges som udgangspunkt, blandt andet fra amerikanske NIST: testprogrammet Computer Forensics Tool Testing (CFTT) og referencedatasættene i Computer Forensic Reference Data Sets (CFReDS).

Verifikation af enkelte fund

For de fund, der bærer en konklusion, er fremgangsmåden:

Find kilden: Hvilken fil, database, tabel og post kommer fundet fra? Et godt værktøj viser det direkte.
Se de rå data: Åbn databasen eller filen med et neutralt værktøj, fx en databasefremviser eller en hexeditor, og kontrollér værdien.
Kontrollér tolkningen: Er tidsstemplet i det format, værktøjet antager? Sekunder eller millisekunder? Hvilken epoke? Er tidszonen rigtig?
Brug et andet værktøj: Giver det samme resultat? Hvis ikke, hvorfor?
Søg efter modstridende spor: Findes der data, der peger i en anden retning?

Det er især tidsstempler, der giver anledning til fejl. Forskellige systemer bruger forskellige epoker og opløsninger, og en fejl på én time i en tidszone kan ændre rækkefølgen af hændelser. Hvordan tidsstempler fra mange kilder samles korrekt, er beskrevet i tidslinjeanalyse.

Hashværdier er en del af valideringen

At et sikringsværktøj beregner samme hashværdi som et uafhængigt værktøj på den færdige kopi, er en enkel og stærk kontrol af, at kopien er korrekt og læsbar. Det er god praksis at gøre det for alle kopier, ikke kun ved tvivl. Algoritmevalget er beskrevet i hashalgoritmer i forensic.

Mobiltelefoner og apps

Mobilområdet er det sted, hvor verifikation oftest er nødvendig. Apps opdateres hyppigt, og værktøjernes parsing halter ofte efter. Et udtræk kan se komplet ud, selvom en ny app-version har flyttet beskeder til en anden tabel eller en anden fil. Kontrollér derfor:

om antallet af beskeder i en samtale stemmer med det, der kan ses i de rå data,
om vedhæftninger er koblet til de rigtige beskeder,
om slettede beskeder er markeret korrekt,
om afsender og modtager er tolket rigtigt i gruppesamtaler.

Udtrækstyperne og deres begrænsninger er beskrevet i udtræk fra mobiltelefoner.

Egne scripts og regneark

Meget analysearbejde foregår uden for de store værktøjer: et script, der samler logfiler, en forespørgsel mod en database eller et regneark, der normaliserer tidsstempler. Den slags hjælpemidler er også værktøjer og skal behandles sådan. Gem scriptet eller forespørgslen i den version, der blev brugt, test det på et lille datasæt med kendt resultat, og beskriv i rapporten, hvad det gør.

Regneark er en særlig faldgrube. De kan omformatere datoer, fjerne foranstillede nuller, afrunde lange tal som id’er og serienumre og tolke tekst som formler. Importér derfor data som tekst, og kontrollér et udsnit mod kildefilen, før regnearket bruges som grundlag for en tidslinje eller en optælling.

Fejl i kopiering og eksport

Verifikation gælder ikke kun analysen, men også de trin, hvor data flyttes. Når et udtræk eksporteres til et rapportformat, et regneark eller et gennemgangsværktøj, kan felter blive afkortet, tegn blive forkert kodet og tidszoner blive ændret. Sammenlign derfor antal poster og et udsnit af værdierne før og efter hver eksport, og notér resultatet.

Opdateringer

Nye versioner af værktøjer, apps og styresystemer kan ændre resultaterne. En validering gælder for en bestemt version af værktøjet og en bestemt version af den data, der er testet. Notér versionen, og gentag kritiske tests ved væsentlige opdateringer. Behold om muligt den version, der blev brugt i en sag, så analysen kan gentages, hvis resultatet senere bliver bestridt.

Hvor langt skal man gå?

Ikke alle fund kræver samme grad af kontrol. En rimelig tommelfingerregel er, at indsatsen følger betydningen:

Fund, der bærer en konklusion: altid kontrol i rå data og helst et andet værktøj.
Fund, der støtter en konklusion: kontrol ved stikprøver.
Baggrundsoplysninger: værktøjets output kan bruges, hvis værktøjet er kendt og valideret til datatypen.

Det skal fremgå af rapporten, hvilke fund der er kontrolleret hvordan. Valget af værktøjer i det hele taget er beskrevet i værktøjer i digital forensic.

Dokumentation i rapporten

Rapporten bør angive:

værktøjer og præcise versioner,
hvordan centrale fund er verificeret, og med hvad,
kendte begrænsninger i værktøjet for den pågældende datatype,
uoverensstemmelser mellem værktøjer, og hvordan de er afklaret,
forbehold, hvor verifikation ikke var mulig.

Skærmbilleder af rå data, fx en databasepost eller et hexudsnit, kan lægges i bilag som dokumentation for kontrollen. Opbygningen af rapporten er beskrevet i rapportskrivning i digital forensic.

Hvorfor det betyder noget i retten

Modparten eller en skønsmand kan spørge, hvordan den sagkyndige ved, at værktøjet viser det rigtige. Flere af de typiske spørgsmål er samlet i Typiske tekniske spørgsmål til metoden. Et svar med konkret verifikation, fx at værdien er kontrolleret direkte i databasen og bekræftet med et andet værktøj, er langt stærkere end en henvisning til værktøjets udbredelse. Hvordan sådanne spørgsmål typisk stilles, er beskrevet i krydsforhør af en IT-sagkyndig.

Standarder

Krav om egnede og validerede metoder går igen i standarderne for digital forensic, særligt ISO/IEC 27041, der handler om at sikre, at undersøgelsesmetoder er egnede til formålet. Se ISO/IEC 27037 og NIST SP 800-86.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Kvalitet og standarder

Læs også: ISO/IEC 27037 og NIST SP 800-86 forklaret · ISO/IEC 27041: sikring af, at metoden er egnet

→ Second opinion på en IR- eller forensic-rapport · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik