Hvornår SOC’en skal kalde en uvildig ind

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

En SOC skal kalde en uvildig IT-sagkyndig ind, når efterspillet af en hændelse sandsynligvis bliver en tvist, en ansættelsessag, en forsikringssag eller et krav mod en leverandør, eller når SOC’en, MSP’en eller deres egne konti selv kan blive en del af forklaringen. I de situationer er det ikke nok, at analysen er teknisk korrekt. Den skal også kunne forsvares over for en part, der har en interesse i at bestride den. Kriterierne bør stå i runbooken, før hændelsen sker, så eskaleringen ikke afhænger af en vurdering midt om natten.

MSP’ens udgave af spørgsmålet står i tjeklisten til MSP’er. Hvordan bevissikringstrin skrives ind i selve playbooken, er beskrevet i bevissikringstrin i jeres IR-playbooks. Her er SOC’ens vinkel: hvilke signaler der bør udløse eskaleringen, og hvilke SOC-data der skal fryses, indtil den uvildige er inde.

Hvorfor SOC’ens egen analyse ikke altid rækker

En SOC er bygget til at opdage og inddæmme. Dens data er formet af egne valg: hvilke kilder der er koblet på, hvilke regler der er slået til, hvordan felter normaliseres, og hvilke alarmer en analytiker har lukket som falsk positiv. Det er helt legitimt i driften. I en tvist bliver de samme valg til spørgsmål. Hvis kunden senere spørger, om SOC’en burde have opdaget angrebet tidligere, er SOC’en ikke længere en neutral kilde, men en part med en interesse i svaret.

Det samme gælder, når hændelsen handler om en person. En SOC, der efterforsker en navngiven medarbejder på eget initiativ, kan komme til at gå videre end mandatet og samtidig skabe materiale, som en modpart vil angribe som ensidigt. Den uvildige erstatter ikke SOC’ens arbejde, men tager den del, der skal kunne efterprøves af andre.

Eskaleringskriterier

Følgende situationer bør hver for sig udløse spørgsmålet om en uvildig:

Insider: mistanken retter sig mod en medarbejder, en konsulent eller en tidligere ansat, og der kan komme ansættelsesretlige følger.
Privilegeret konto: en administrator, en driftskonto eller en tjenestekonto med vide rettigheder er involveret, og den undersøgte kan have ændret logningen.
SOC’ens eller MSP’ens egne værktøjer: RMM, EDR-konsol, SIEM-konti eller partneradgange indgår i angrebskæden.
Forsikring: hændelsen er eller bliver anmeldt til et forsikringsselskab, som vil vurdere indgangsvej, omfang og sikkerhedsniveau.
Kunde eller leverandør: der er tegn på, at en part vil rejse krav om ansvar, fx for manglende opdatering, manglende overvågning eller forsinket reaktion.
Persondatabrud med følger: de registrerede kan rejse erstatningskrav, eller omfanget er omstridt.
Ledelsen: personer i ledelsen er involveret, eller ledelsen har selv truffet beslutninger, der er til diskussion.
Modstridende forklaringer: to parter giver uforenelige forklaringer, og data skal afgøre det.

Signaler i data

Ud over situationerne kan tekniske signaler pege på, at sagen er på vej mod en tvist:

rydning af hændelseslogs, fx 1102 i Security-loggen eller 104 i System-loggen,
ændret revisionspolitik, deaktiveret logning eller EDR-agenter, der er stoppet eller afinstalleret,
administrative handlinger uden for et godkendt ændringsvindue,
store download- eller synkroniseringsmængder fra en konto, der er opsagt eller er ved at fratræde,
en alarm, der blev lukket som falsk positiv og senere viser sig at høre til hændelsen.

Et signal er ikke en konklusion. Det er et tegn på, at analysen fremover skal tåle en modparts gennemgang.

Det, SOC’en fryser imens

Eskaleringen må ikke betyde, at intet sker. Flygtige data skal sikres af SOC’en, mens den uvildige kommer ind, og her har en SOC nogle særlige kilder:

Rå hændelser, ikke kun normaliserede. Eksportér de rå events fra SIEM’et for den relevante periode og de relevante kilder, med forespørgsel, tidszone og hashværdi. Se SIEM-data som bevis.
Alarmhistorikken. Gem alarmer med status, tidspunkter for ændringer og analytikernes noter, også dem, der er lukket.
Regelversioner. Eksportér detektionsreglerne, som de så ud i perioden. En regel, der er rettet efter hændelsen, kan ikke forklare, hvorfor noget blev eller ikke blev opdaget.
Dækningen. Notér, hvilke kilder der var koblet på hvornår, og hvor der var huller eller forsinket indlæsning.
Opbevaringen. Sæt automatisk sletning på pause for de berørte indekser og konti, og notér det.
Indgreb. Før en log over isoleringer, blokeringer, nulstillinger og andre indgreb med tidspunkt, system og udførende analytiker.

Begræns samtidig adgangen til sagen i SOC-platformen til de analytikere, der arbejder på den, og undlad at kontakte den person, mistanken gælder.

Når den undersøgte har administratorrettigheder

En særlig situation opstår, når den undersøgte selv kan slette eller ændre de logs, SOC’en bygger på. Så skal analysen hvile på kilder, den undersøgte ikke har kontrol over, og indsamlingen bør ske med firøjnesikring. Fremgangsmåden er beskrevet i undersøgelse af en administrator, der kan slette loggen. Hvis SOC’ens egne analytikere har administratoradgang til de samme systemer, er det i sig selv et argument for at hente en uvildig ind.

Hvem beslutter

SOC’en indstiller, men beslutningen ligger hos den, der har råderet over data: kunden eller den dataansvarlige, ofte i samråd med en advokat. Skriv derfor tre ting ind i runbooken og kundeaftalen: hvilke kriterier der udløser en indstilling, hvem hos kunden der kan træffe beslutningen uden for kontortid, og hvem der ringes til. Med en beredskabsaftale er konflikttjek og kontaktpunkt afklaret på forhånd. Den praktiske afvejning mellem egen IT, leverandør og uvildig er beskrevet for ledelsen på bevissikring-digitalt.dk.

Samspillet bagefter

Når den uvildige er inde, fortsætter SOC’en med inddæmning og overvågning. Den uvildige sikrer de kilder, der skal bære en senere rapport, kontrollerer SOC’ens eksporter og overtager analysen af de spørgsmål, der kan blive omstridte. Nielco IT har indsigt i og erfaring med incident response og hackerangreb og arbejder uvildigt ved siden af den eksisterende IR-indsats. Rollefordelingen er beskrevet i samarbejde med jeres IR-leverandør.

Typiske fejl

Eskalering, når skaden er sket. Spørgsmålet stilles først, når kunden har sendt et advokatbrev, og SIEM’ets opbevaring er udløbet.
Konklusioner i tickets. Analytikere skriver vurderinger af skyld eller hensigt i sager, der senere fremlægges.
Rettede regler uden historik. Detektionsreglen opdateres efter hændelsen, og den gamle version gemmes ikke.
Undersøgelse uden mandat. SOC’en gennemgår en medarbejders mail eller filer, før kunden har taget stilling.
Ingen tidszoneangivelse. Eksporter afleveres uden oplysning om, hvorvidt tiderne er UTC eller lokal tid.

Hvad eskaleringen kan og ikke kan

En tidlig eskalering kan sikre, at de data, SOC’en har, bliver brugbare i en sag, og at analysen bliver lavet af en, der ikke har en interesse i resultatet. Den kan ikke genskabe logs, der aldrig blev indsamlet, eller detektionsdækning, der ikke fandtes. Det skal stå i rapporten som en begrænsning, ikke udfyldes med antagelser.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Undersøgelse efter et hackerangreb

Læs også: Bevissikringstrin i jeres IR-playbooks · Hændelse hos flere kunder på én gang

→ 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