Forside › Sikring: metoderne samlet · Gennemgået oktober 2026 · Af John Nielsen
En chain of custody-log, loggen over kæde af ansvar (chain of custody), er den løbende registrering af, hvor et bevisobjekt har været, hvem der har haft det, og hvad der er sket med det, fra det blev sikret, til det leveres tilbage eller slettes. I digital forensics skal loggen også kunne følge data gennem kopier: fra det fysiske medie til imaget, fra imaget til arbejdskopier og fra arbejdskopier til eksporter og bilag. Det, der binder kæden sammen teknisk, er hashværdierne. Hver post skal derfor kunne kobles til en bestemt hashværdi, så det kan vises, at objektet ved hver overdragelse var det samme som ved sikringen.
Begrebet og dets betydning er forklaret på Kæde af ansvar (chain of custody), og hvad advokaten skal kræve dokumenteret, står på Chain of custody i civile sager. En udfyldbar skabelon findes på Skabelon: bevislog (chain of custody) for IT. Denne artikel forklarer, hvorfor felterne er der, og hvordan loggen bygges, så den kan efterprøves.
To niveauer: objektregister og hændelseslog
En brugbar log har to dele:
- Objektregistret beskriver hvert bevisobjekt én gang: hvad det er, hvor det kommer fra, og hvordan det identificeres.
- Hændelsesloggen registrerer alt, der sker med objekterne over tid, én linje pr. hændelse, med henvisning til objektets id.
Adskillelsen gør det muligt at se et objekts samlede historie ved at filtrere hændelsesloggen på dets id, og den forhindrer, at beskrivelsen af objektet ændrer sig fra linje til linje.
Felter i objektregistret
- Objekt-id · Entydigt nummer, der aldrig genbruges
- Overordnet objekt-id · Det objekt, dette er afledt af (tomt for originaler)
- Type · Fysisk medie, image, logisk beholder, eksport, arbejdskopi, bilag
- Beskrivelse · Fabrikat, model, kapacitet, eller filnavn og format
- Unik identifikation · Serienummer, IMEI, konto-id, eller sti og filnavn
- Kilde · Hvor og fra hvem objektet stammer
- Sikret af og tidspunkt · Person og tid med tidszone
- Metode og værktøj · Fx skrivebeskytter og imagingværktøj med version
- Hashalgoritme og hashværdi · Værdien ved oprettelsen af objektet
- Bemærkninger · Tilstand, skader, afvigelser
Feltet for overordnet objekt er det, der gør loggen digital. Det skaber et stamtræ: Den bærbare computer er objekt 1, imaget af dens disk er objekt 2 med objekt 1 som forælder, arbejdskopien er objekt 3 med objekt 2 som forælder, og en eksport af en enkelt mappe til en advokat er objekt 4 med objekt 3 som forælder. Ethvert bilag i en rapport kan så føres tilbage til det fysiske medie. → Arbejdskopier og masterkopi
Hændelser, der skal registreres
Hændelsesloggen bør mindst have en linje, når:
- objektet sikres eller oprettes,
- objektet overdrages til en anden person eller organisation,
- objektet flyttes til en anden opbevaringsplacering,
- objektets hashværdi kontrolleres, med resultat,
- der laves en kopi af objektet (som samtidig opretter et nyt objekt i registret),
- objektet åbnes eller analyseres, hvis det er en masterkopi,
- der opstår en afvigelse, fx en fejl, et brud på forsegling eller en mislykket verifikation,
- objektet tilbageleveres eller slettes.
Hver linje har felterne: løbenummer, objekt-id, tidspunkt med tidszone, hændelsestype, fra person eller sted, til person eller sted, hashværdi målt ved hændelsen (hvor relevant), forseglingsnummer (hvor relevant), og hvem der har registreret linjen.
Hashreferencer
Hashværdien i objektregistret er referencen. Ved hver kontrol registreres den målte værdi i hændelsesloggen, ikke blot “OK”. Så kan en læser selv se, at værdierne er identiske, og en eventuel fejl i en senere kontrol kan ikke skjules af et afkrydsningsfelt. Angiv altid algoritmen. Brug gerne to algoritmer for masterkopier. → Hashalgoritmer i forensic
For logiske beholdere og eksporter med mange filer peger loggen på et hashmanifest i stedet for at liste hver fil. Manifestet er selv en fil med sin egen hashværdi, som registreres i loggen. Derved er hver enkelt fil dækket, uden at loggen bliver uoverskuelig.
Loggens egen integritet
Loggen er selv en del af beviset, og den kan blive mødt med indsigelsen om, at den er rettet bagefter. Gode greb er:
- Kun tilføjelser. Linjer rettes ikke. En fejl rettes med en ny linje, der henviser til den forkerte.
- Løbenumre uden huller. Et manglende nummer skal kunne forklares.
- Periodiske hashværdier af selve loggen. Gem fx en datostemplet kopi af loggen ved hver vigtig hændelse og registrér dens hashværdi et andet sted, fx i en mail til advokaten.
- Begrænset skriveadgang. Få personer, med navn, må skrive i loggen.
- Et system med revisionsspor. Hvis loggen føres i et system, bør systemet selv registrere, hvem der har tilføjet hvad og hvornår.
Et regneark på et fællesdrev opfylder ingen af disse krav af sig selv. Det kan bruges, men så skal de manuelle greb følges konsekvent. → Logning af analytikerens egen adgang
Når flere organisationer er involveret
I mange sager passerer data gennem flere hænder: virksomhedens IT-afdeling, en IT-leverandør, en IT-sagkyndig, en advokat og måske en skønsmand. Hver organisation fører ofte sin egen log. Det er acceptabelt, så længe overgangene kan kobles sammen. Det kræver, at:
- objekt-id’et fra afsenderens log noteres i modtagerens log, så objektet kan genkendes,
- hashværdien ved afsendelse og ved modtagelse står i begge logs,
- tidspunktet for overdragelsen er registreret i begge ender, og eventuelle forskelle kan forklares, fx transporttid.
Overdragelsen er det sted, hvor kæden oftest brister, fordi hver part antager, at den anden registrerer. Selve transporten og kvitteringen er beskrevet i Overførsel af beviskopier.
Hændelser i cloud og eksporter
Når data sikres fra cloudtjenester, er der intet fysisk objekt at give et serienummer. Objektet er eksportfilen, og dets unikke identifikation er en kombination af tjenesten, tenant eller konto, eksportjobbets id og tidspunktet. Tjenestens egen auditlog over eksporten bør sikres og registreres som et selvstændigt objekt, fordi den viser, hvem der startede eksporten og med hvilke parametre.
I rapporten
Rapporten behøver ikke gengive hele loggen, men den bør henvise til den og gengive stamtræet for de objekter, konklusionerne bygger på: fra fysisk medie eller konto til den kopi, analysen er udført på, med hashværdier ved hvert led. Loggen selv vedlægges som bilag eller kan udleveres på forespørgsel.
Typiske fejl
- Tidspunkter uden tidszone, eller blanding af lokal tid og UTC.
- Hashværdier, der kun er registreret som “verificeret”, uden selve værdien.
- Afledte kopier og eksporter, der ikke er registreret som egne objekter.
- Overdragelser mellem kolleger i samme organisation, der ikke registreres, fordi de “ikke tæller”.
- Fysisk forsegling, hvor forseglingens nummer ikke står i loggen.
- Huller i de første timer, før nogen tænkte på at føre log. Registrér dem ærligt som ukendte perioder.
Hvad loggen kan og ikke kan bevise
En komplet log med hashreferencer kan vise, at det objekt, der analyseres, er det samme, som blev sikret, og at kun navngivne personer har haft adgang. Den kan ikke vise, at data var korrekte eller ægte, da de blev sikret. Den kan heller ikke reparere huller fra før sikringen, men den kan gøre dem synlige og afgrænsede.
Kilder og versioner
- ISO/IEC 27037: retningslinjer for håndtering af digitale beviser
- NIST: eksempel på chain of custody-formular
- NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response
- NIST FIPS 180-4: Secure Hash Standard
Senest gennemgået: oktober 2026.
Næste skridt
- Forensiske diskformater: raw, E01 og AFF4
- Skrivebeskyttere (write blockers): hvordan og hvorfor
- Hukommelsessikring (RAM): hvad hukommelsen rummer, og hvordan den sikres
Del af: Sikring: metoderne samlet
Læs også: Teknisk kommissorium: fra spørgsmål til afgrænset analyseopgave · Mærkning, forsegling og fotodokumentation af medier
→ Forensisk sikring · For sagkyndige · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
