NIST SP 800‑61 og bevissikring under incident response

Forside › Undersøgelse efter et hackerangreb · Gennemgået oktober 2026 · Af John Nielsen

NIST SP 800-61 er den mest udbredte reference for incident response. Revision 3 udkom i april 2025 og erstattede revision 2 fra 2012. Den nye udgave er ikke længere en selvstændig håndbog med fire faser, men en såkaldt Community Profile til NIST Cybersecurity Framework (CSF) 2.0. For en SOC betyder det, at bevissikring ikke længere står som et afsnit for sig, men som konkrete udfald under funktionen Respond, især RS.AN-06 og RS.AN-07. Artiklen beskriver, hvordan de to punkter omsættes til praksis, så data og noter fra en hændelse kan bruges, hvis hændelsen senere ender i en forsikringssag, en leverandørtvist eller en sag om ansvar.

Fra livscyklus til CSF 2.0

Revision 2 beskrev en livscyklus med fire faser: forberedelse, opdagelse og analyse, inddæmning, udryddelse og genopretning samt aktiviteter efter hændelsen. Mange IR-planer og playbooks er stadig bygget op efter den model.

Revision 3 lægger i stedet anbefalingerne ind under CSF 2.0’s seks funktioner: Govern, Identify, Protect, Detect, Respond og Recover. Dokumentet indeholder selv en tabel, der viser, hvordan de gamle faser svarer til de nye funktioner. Forberedelse svarer til Govern, Identify og Protect, læring efter hændelsen til forbedringsdelen af Identify, mens selve håndteringen ligger under Detect, Respond og Recover. Hvert udfald har en prioritet og en række anbefalinger og noter.

Strukturen er ikke kun kosmetisk. Den gør det lettere at revidere en IR-proces mod en ramme, som ledelse, revisor og forsikringsselskab også kender, og den gør det tydeligt, at dokumentation og bevaring er en del af selve responsen, ikke en efterrationalisering.

RS.AN-06: indgreb registreres

RS.AN-06 siger, at handlinger under en undersøgelse registreres, og at registreringernes integritet og oprindelse bevares. Noterne nævner logbog på papir, lyd- og videooptagelse og automatisk logning af sessioner som mulige midler, og at den ansvarlige for hændelsen typisk skal sikre, at optegnelserne beskyttes.

I praksis er det kravet om en log over indgreb: hvem gjorde hvad, hvornår, på hvilket system, og hvorfor. Den er afgørende, fordi IR-teamets egne handlinger, fx isolering, nulstilling af adgangskoder, sletning af konti og fjernelse af persistens, skaber hændelser i de samme logs, som angriberen har efterladt spor i. Uden indgrebsloggen kan en senere analyse ikke skelne mellem de to. Fremgangsmåden er beskrevet i log over indgreb under incident response.

For at bevare integriteten bør loggen føres et sted, hvor tidligere poster ikke kan ændres uden spor, og hashes eller arkiveres ved hændelsens afslutning.

RS.AN-07: data og metadata indsamles med integritet

RS.AN-07 siger, at data og metadata om hændelsen indsamles, og at deres integritet og oprindelse bevares. NIST bemærker, at formel bevishåndtering med kontinuitetsdokumentation ikke nødvendigvis udføres ved alle hændelser, men at de indsamlede data stadig er bevis i den forstand, at de er grundlag for at fastslå, hvad der er sandt. Anbefalingen er at indsamle og opbevare data efter organisationens procedurer for bevaring og opbevaring og at tage højde for, hvad det koster at opbevare data og den hardware og software, der skal til for at læse dem senere.

For civile sager er netop den formulering vigtig. En organisation kan ikke på forhånd vide, hvilke hændelser der ender i en tvist. Derfor bør indsamlingen fra starten ske, så den kan bære en tvist:

Hash ved indsamling af logeksporter, diskkopier, hukommelseskopier og EDR-pakker, med hashværdien noteret i indgrebsloggen.
Oprindelse: hvilket system, hvilken konto, hvilket værktøj og hvilken forespørgsel blev brugt til eksporten.
Tid: systemtid på kilden og tidszone for eksporten.
Opbevaring: hvor kopierne ligger, hvem der har adgang, og hvor længe de gemmes.

Sikringen af selve dataene følger samme principper som i NIST SP 800-86 og ISO/IEC 27037, som stadig er den relevante vejledning for den forensiske del.

De øvrige punkter, der berører bevis

RS.AN-03: Analyse af, hvad der skete, og årsagen. Rækkefølgen af hændelser og de involverede aktiver skal fastlægges. Det er grundlaget for en tidslinje, der kan efterprøves.
RS.AN-08: Hændelsens omfang skal estimeres og valideres. Det er her, spørgsmål om berørte data og eksfiltration hører til.
RC.RP-03 og RC.RP-05: Backup og gendannede systemer skal kontrolleres for integritet og kompromittering, før de bruges. Kontrollen er samtidig dokumentation af, hvilken tilstand der blev genoprettet til.
RC.RP-06: Afslutningen dokumenteres med en rapport over hændelsen, indsats og læring. Den rapport ender ofte som bilag i en tvist, se IR-rapporten som bevis.
PR.PS-04: Logs skal genereres og være tilgængelige. Uden den forberedelse er der intet at sikre.

Sådan omsættes det i SOC’ens playbooks

Gør indgrebsloggen obligatorisk fra første eskalering, ikke fra det tidspunkt, hvor nogen taler om forsikring eller advokat.
Indsæt et sikringstrin før ødelæggende handlinger: før reimage, gendannelse fra backup, sletning af konti eller rotation af logs. Se bevissikringstrin i IR-playbooks.
Standardisér eksporterne fra de vigtigste kilder, fx EDR, Entra ID, auditlog, firewall og hypervisor, med hash og en kort beskrivelse af forespørgslen.
Adskil analysekopier fra originaler, så analyse ikke ændrer det, der skal bevares.
Aftal på forhånd, hvornår en uvildig sagkyndig skal inddrages, fx ved mistanke om insider, ved tvist med en leverandør eller når en forsikringsdækning afhænger af årsagen.

Forholdet mellem IR og forensic

800-61 handler om at håndtere hændelsen; den forensiske undersøgelse handler om at kunne dokumentere den over for andre. De to mål kan trække i hver sin retning, især når driften skal genoprettes hurtigt. Revision 3 gør det lettere at forene dem, fordi dokumentation og bevaring nu er udfald i samme ramme som genopretning. Forskellen og samspillet er beskrevet i forensic eller incident response?.

Nielco IT har indsigt i og erfaring med incident response og hackerangreb og kan sikre uvildigt ved siden af IR-leverandøren, så IR-teamet kan koncentrere sig om driften. Se samarbejde med IR-leverandøren.

Begrænsninger

800-61 er en vejledning, ikke et krav, og den siger ikke, hvordan en bestemt logkilde sikres. Den er skrevet med amerikanske myndigheder som primær målgruppe og skal tilpasses danske forhold, fx krav om underretning efter databeskyttelsesreglerne og NIS2. Henvis i rapporten til revision og udgivelsesdato, og angiv, hvilke udfald processen er målt imod. Bygger en ældre IR-plan på revision 2, er det ikke en fejl i sig selv, men en opdatering bør tage stilling til, om RS.AN-06 og RS.AN-07 er dækket.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Undersøgelse efter et hackerangreb

Læs også: Skadebehandlerens tekniske tjekliste til en IR-rapport · Compromise assessment: er vi kompromitteret uden en kendt hændelse?

→ Undersøgelse efter et hackerangreb · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-sikkerhed og SOC · 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