Flygtighedsorden: hvad skal sikres først?

Forside › Sikring: metoderne samlet · Gennemgået oktober 2026 · Af John Nielsen

Flygtighedsordenen (order of volatility) er princippet om, at data sikres i rækkefølge efter, hvor hurtigt de forsvinder. Det mest flygtige først: det, der forsvinder ved næste handling eller genstart, før det, der ligger stabilt på en disk eller i et arkiv. Princippet stammer fra den klassiske computer, men det gælder lige så meget i cloud, hvor det flygtige ikke er hukommelse, men logs med kort opbevaring, sessioner og konti, der er sat til sletning. Ordenen er et udgangspunkt for planlægning, ikke en fast opskrift, og hvert valg skal afvejes mod, hvor meget selve sikringen ændrer.

Haster det? Hukommelse og netforbindelser forsvinder ved næste genstart, og cloudlogs med kort opbevaring kan udløbe inden for dage. Se Akut forensisk sikring; hastesager koster ekstra.

Hvordan hukommelsen sikres, og hvornår det er relevant, står i Hukommelsessikring (RAM). Her gennemgås hele rækkefølgen. Det konkrete valg ved en tændt enhed står i Sluk, isolér eller lad den køre?.

Den klassiske rækkefølge

Den hyppigst citerede formulering findes i RFC 3227 fra 2002, en vejledning om indsamling af beviser. Rækkefølgen er i hovedtræk:

Registre og cache i processoren
Routingtabel, ARP-cache, procestabel, kernestatistik og hukommelse
Midlertidige filsystemer
Disk
Fjernlogning og overvågningsdata, der er relevante for systemet
Fysisk konfiguration og netværkstopologi
Arkivmedier

Det første punkt er i praksis ikke tilgængeligt med almindelige værktøjer. Punkt 2 sikres i dag primært gennem en hukommelseskopi, som også indeholder procestabel og netforbindelser, suppleret med systemets egne kommandoer.

Princippet indgår også i ISO/IEC 27037 og NIST SP 800-86, se ISO/IEC 27037 og NIST SP 800-86.

Hvad der er flygtigt på en tændt computer

På en tændt computer eller server forsvinder blandt andet disse oplysninger ved slukning eller genstart:

aktive netværksforbindelser med fjernadresser og porte,
kørende processer med kommandolinje, forældreproces og indlæste moduler,
loggede brugere og aktive fjernsessioner,
åbne filer og netværksdrev,
oplåste krypterede drev og containere,
udklipsholderen og data i programmernes hukommelse,
midlertidige filer, der slettes ved genstart.

Krypterede drev er et særligt hensyn. Er et drev låst op, kan en logisk kopi tages, mens det er tilgængeligt. Slukkes maskinen, kræver adgang gendannelsesnøgle eller adgangskode, se BitLocker og FileVault.

Spørgsmålet om at slukke eller lade køre er behandlet i Sluk eller lad køre, og indsamling på en kørende maskine i Live response.

Flygtighed i servere og netværk

På servere og netværksudstyr er de flygtige data typisk:

forbindelsestabeller og NAT-tabeller i firewalls,
lokale logs i en ringbuffer, der overskrives, når den er fuld,
sessioner i VPN-koncentratorer,
hukommelsen i virtuelle maskiner, som kan bevares ved et snapshot med hukommelse.

Lokale logs på netværksudstyr kan forsvinde på timer eller dage, mens logs, der sendes til en central logserver, ofte bevares længere. Rækkefølgen bliver derfor: udstyrets lokale tilstand og buffer, derefter den centrale log. Kilderne er gennemgået i Netværk og logs i undersøgelser. Virtuelle skriveborde, der nulstilles ved logoff, er et særligt flygtigt tilfælde; se VDI og Citrix.

Flygtighed i cloud

I cloudtjenester er det sjældent hukommelsen, der er det flygtige. Det er:

logs med kort opbevaring, fx loginlogs og auditlogs, som afhænger af licens,
konti og postkasser, der er sat til sletning, fx efter en fratræden,
papirkurve og gendannelsesperioder, der tømmes automatisk,
sessioner og tokens, der udløber eller tilbagekaldes,
midlertidige ressourcer, fx virtuelle maskiner og containere, der skaleres ned.

Flygtigheden måles her i dage eller uger i stedet for sekunder, men princippet er det samme: Det, der forsvinder først, sikres først. Opbevaringsperioderne skal derfor kendes, se Logfiler og logrotation og Identifikation af datakilder.

Flygtighed på mobiltelefoner

En telefon har sin egen form for flygtighed. En tændt og oplåst telefon er i en tilstand, hvor flere data er tilgængelige for et udtræk end efter en genstart, fordi nøglerne til krypteret indhold er indlæst. Samtidig kan telefonen blive fjernslettet via MDM eller brugerens konto, beskeder kan forsvinde efter en indstillet periode, og batteriet kan løbe tomt. Prioriteringen er derfor typisk:

Hold telefonen tændt og opladet, og afskærm den fra netværk, hvis der er risiko for fjernsletning, og det kan ske uden at låse den.
Notér tilstand, skærmindhold og tid, før noget røres.
Lav udtrækket så hurtigt som muligt, ad lovlige veje og med ejerens samtykke eller kode.
Sikr derefter cloudbackup og kontodata, der også kan rumme indholdet.

Detaljerne om telefonens tilstande står i artiklen om udtræk fra mobiltelefoner.

Forberedelse

Flygtighed er lettest at håndtere, hvis den er tænkt ind på forhånd. En organisation, der sender logs til en central logserver med lang opbevaring, har gjort mange lokale logs mindre flygtige. En beredskabsplan, der angiver, hvem der må tage en hukommelseskopi, og med hvilket værktøj, sparer minutter, når det gælder; se Bevissikringstrin i jeres IR-playbooks. Og en liste over cloudlogs med deres opbevaringstider gør det muligt at handle i den rigtige rækkefølge uden at skulle undersøge det midt i en hændelse.

En samlet prioritering

I en konkret sag kombineres flygtighed med to andre hensyn: relevans og påvirkning. En meget flygtig kilde, der ikke er relevant for spørgsmålet, skal ikke sikres for enhver pris. En relevant kilde, hvis sikring ændrer meget på systemet, kan være bedre at sikre på anden vis.

En typisk prioritering ved en hændelse på en arbejdsstation med cloudkonti kunne se sådan ud:

Hukommelse, hvis spørgsmålet kræver det, og maskinen er tændt.
Oplåste krypterede drev ved logisk kopi.
Cloudlogs med kortest opbevaring og konti på vej til sletning.
Fuld diskkopi efter slukning.
Centrale logs, backup og arkiver.

Rækkefølgen af punkt 1 og 3 kan byttes, hvis flere personer arbejder samtidig, eller hvis cloudloggen udløber inden for timer.

Hver handling ændrer noget

Enhver indsamling på et kørende system ændrer systemet. Et program, der kopierer hukommelsen, optager selv hukommelse. En kommando, der viser netforbindelser, starter en proces. Det er acceptabelt, når det er nødvendigt og dokumenteret. Notér tidspunkt, kommando, værktøj og version for hver handling, så ændringerne senere kan skelnes fra de oprindelige spor.

Kør værktøjer fra et eksternt medie i stedet for at installere dem, og gem resultaterne på et eksternt medie i stedet for på systemets egen disk. Så begrænses både fodaftrykket i hukommelsen og risikoen for at overskrive slettede data på disken. Brug et ur, der er kontrolleret mod en pålidelig tidskilde, til at notere tidspunkterne, og notér samtidig systemets egen tid, så en eventuel afvigelse kan beregnes.

Typiske fejl

Disken først af vane, så netforbindelser og oplåste drev går tabt.
Genstart for at “se, om det hjælper”, før noget er sikret.
Glemte cloudlogs, fordi fokus er på den fysiske maskine.
Ordenen fulgt blindt, så tid bruges på flygtige data uden relevans, mens en relevant log udløber.

Hvad princippet kan og ikke kan

Flygtighedsordenen kan begrunde, hvorfor en sikring er foretaget i en bestemt rækkefølge, og vise, at tab af data er undgået, hvor det var muligt. Den kan ikke sige, hvilke kilder der er relevante. Det afgør spørgsmålet i sagen.

I rapporten

Beskriv den valgte rækkefølge, begrundelsen og de kilder, der bevidst er fravalgt eller ikke kunne nås i tide, med tidspunkt for hver handling.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Sikring: metoderne samlet

Læs også: Identifikation af datakilder: teknisk kortlægning før sikringen · Triage eller fuld kopi: hvornår er et hurtigt overblik nok?

→ Forensisk sikring · 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