NIST CFTT og CFReDS: offentlige værktøjstests og testbilleder

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

Spørgsmålet “hvordan ved du, at værktøjet virker?” kommer før eller siden i enhver sag, hvor en teknisk konklusion bliver bestridt. To offentlige ressourcer fra amerikanske NIST giver en del af svaret: Computer Forensics Tool Testing (CFTT), der tester forensiske værktøjer mod offentliggjorte krav, og Computer Forensic Reference Data Sets (CFReDS), der stiller testdata med kendt indhold til rådighed. Ingen af dem erstatter egen validering, men de giver et uafhængigt udgangspunkt, som både egen og modpartens sagkyndige kan henvise til.

CFTT: hvad programmet gør

CFTT er et projekt under NIST’s Information Technology Laboratory med det formål at etablere en metode til test af forensiske værktøjer. Metoden er opbygget efter funktion: Faget opdeles i afgrænsede opgaver, fx skrivebeskyttelse, diskkopiering, gendannelse af slettede filer, file carving, strengsøgning, analyse af registreringsdatabasen, SQLite, mobiludtræk og udtræk fra cloudtjenester. For hver opgave udarbejdes en specifikation med krav, testpåstande og testcases, som sendes i offentlig høring, før den bruges.

Når et værktøj testes, vælges de testcases, der passer til de funktioner, værktøjet understøtter. Resultatet samles i en testrapport, som producenten får lejlighed til at kommentere. Rapporterne offentliggøres af det amerikanske Department of Homeland Security, sorteret efter værktøjskategori og udgivelsesdato.

Sådan læses en CFTT-rapport

En testrapport gælder en bestemt version af et bestemt værktøj, testet på en bestemt testopsætning på et bestemt tidspunkt. Det er det vigtigste forbehold. En rapport om version 7 siger ikke noget sikkert om version 9.

Rapporten er bygget op omkring testcases og deres resultat. Det interessante er sjældent, at et værktøj “bestod”, men de afvigelser, testerne har noteret, fx:

data i bestemte områder af disken, der ikke blev kopieret,
tidsstempler, der blev vist i en anden tidszone end forventet,
slettede poster i en database, der ikke blev fundet eller blev vist forkert,
felter fra mobilapps, der manglede eller var tildelt den forkerte samtale,
fejlmeddelelser, der ikke blev logget.

En afvigelse betyder ikke, at værktøjet er ubrugeligt. Den fortæller, hvor resultaterne skal kontrolleres manuelt eller med et andet værktøj. Er en afvigelse relevant for netop de data, sagen handler om, bør den nævnes i rapporten sammen med den kontrol, der er udført.

CFTT-rapporter er ikke en godkendelse eller certificering. Et værktøj, der ikke er testet af CFTT, er ikke dårligere af den grund; det betyder blot, at valideringen må hvile på andet grundlag.

Skrivebeskyttere og diskkopiering

For hardware-skrivebeskyttere og diskkopiering er CFTT’s resultater særligt nyttige, fordi kravene er enkle og velafgrænsede: Ingen skrivning til kilden, og en komplet og korrekt kopi. Testene afslører typisk forskelle i håndteringen af skjulte områder (HPA og DCO), fejlende sektorer og bestemte kommandoer. Når en skrivebeskytter eller et kopieringsværktøj vælges, er det rimeligt at tjekke, om modellen eller versionen er testet, og hvad der blev noteret. Se også skrivebeskyttere.

CFReDS: testdata med facit

CFReDS er NIST’s portal for dokumenterede referencedatasæt: simulerede diskimages, mobiludtræk, hukommelseskopier og scenarier, hvor indholdet er kendt og beskrevet. Nogle datasæt er bygget til at teste én funktion, fx strengsøgning eller gendannelse af slettede filer. Andre er hele scenarier med spørgsmål og svar, der kan bruges til træning og til at sammenligne værktøjer. Ældre datasæt ligger i et arkiv ved siden af den nuværende portal.

Fordelen er, at datasættene er offentlige. To sagkyndige kan køre hver deres værktøj mod samme billede og sammenligne resultatet mod samme facit. Det er en mere neutral øvelse end at diskutere, hvis værktøj er bedst.

Sådan findes det relevante materiale

Start med spørgsmålet, ikke med værktøjet: Hvilken funktion bærer konklusionen? Er det kopieringen af disken, gendannelsen af en slettet fil, udtrækket af en beskeddatabase eller fortolkningen af en registreringsnøgle? Find derefter den CFTT-kategori, der dækker funktionen, og læs specifikationen, før rapporterne. Specifikationen viser, hvilke krav der faktisk er testet, og dermed hvad en “bestået” test dækker, og hvad den ikke dækker. Find så rapporter for værktøjet og notér versionsforskellen til den version, der bruges i sagen. Til sidst søges der i CFReDS efter datasæt, der rammer samme funktion. Notér dato for opslag og rapportens udgivelsesdato, så det senere kan dokumenteres, hvilket grundlag vurderingen hvilede på.

Brug i egen validering

En fornuftig validering af et værktøj før brug i en sag kombinerer tre ting:

CFTT-rapporter for den relevante kategori og så tæt på den aktuelle version som muligt, læst med fokus på afvigelser.
Offentlige testdata fra CFReDS for de funktioner, der findes datasæt til, kørt på den version, der faktisk bruges.
Egne testdata for det, der er afgørende i sagen og ikke dækkes af de offentlige sæt, fx danske tegn, dansk tidszone med sommertid, danske apps eller en bestemt version af en beskedapp. Se testdatasæt og referencedata.

Valideringen dokumenteres med værktøj og version, testdata, forventet og faktisk resultat, og hvordan afvigelser er håndteret. Den overordnede metode er beskrevet i verifikation af værktøjer, og kravet om, at metoden er egnet, er beskrevet i ISO/IEC 27041.

Begrænsninger

Versionskløften. Værktøjer opdateres langt hyppigere, end de testes. De fleste versioner, der bruges i praksis, har ingen CFTT-rapport.
Mobil og cloud. Data ændrer sig med hver app- og styresystemopdatering, så test bliver hurtigt forældet. Her vejer egen test og manuel kontrol af enkeltfund tungere.
Amerikansk kontekst. Testdata afspejler sjældent danske forhold.
Afgrænset test. CFTT tester funktioner, ikke fortolkning. Et værktøj kan udtrække et tidsstempel korrekt, mens analytikeren fortolker det forkert.
Tilgængelighed. Kategorier og rapporter kan blive omorganiseret eller arkiveret, og ikke alle kategorier har nye rapporter. Henvis til den konkrete rapport og datoen for opslaget.

Når modpartens værktøj skal efterprøves

I en tvist kan det være relevant at spørge, hvordan modpartens sagkyndige har valideret sit værktøj. CFTT og CFReDS giver et sagligt grundlag for spørgsmålene: Er værktøjet og versionen testet i den relevante kategori? Er der kendte afvigelser, som berører sagens data? Er resultatet kontrolleret med et andet værktøj eller manuelt? Spørgsmålene er en del af en almindelig faglig efterprøvning og bør stilles konkret, ikke som en generel mistillid til værktøjet. SWGDE’s minimumskrav til værktøjstest kan bruges som supplement, se SWGDE’s vejledninger.

I rapporten

Angiv for hvert værktøj, der bærer en konklusion: navn, version, hvilken validering der er udført, om der findes relevante CFTT-resultater, og om kendte afvigelser er kontrolleret. Henvis til de konkrete testrapporter og datasæt med titel og dato. Skriv ikke, at et værktøj er “NIST-godkendt”; formuleringen er misvisende, fordi testene ikke er en godkendelse.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Kvalitet og standarder

Læs også: SWGDE’s vejledninger: hvad de dækker, og hvordan de bruges i civile sager · ISAE 3402- og SOC 2-erklæringer og logdata

→ Second opinion på en IR- eller forensic-rapport · For sagkyndige · 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