Detektion og analyse: Identifikation af reelle hændelser
Lær at triagere alarmer fra SIEM-, EDR- og netværksværktøjer for at skelne sande positive fra falske positive og fastslå hændelsens omfang.
Detektion og analyse: Identifikation af reelle hændelser er en gratis Cloud & IT Cert Prep-lektion på CoddyKit. Dette er lektion 2 af 4. Du kan læse hele lektionen gratis nedenfor — og derefter øve dig praktisk i browseren med en indbygget kodeeditor og en AI-vejleder, der er tilgængelig døgnet rundt. Den er en del af læringsforløbet i Cloud & IT Cert Prep, og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. Cloud & IT Cert Prep-kurset indeholder 4 lektioner i alt.
Oversigt over registreringsfasen
Fasen for registrering og analyse begynder, når en potentiel sikkerhedshændelse identificeres første gang, og slutter, når omfanget og påvirkningen er tilstrækkeligt forstået til, at indeslutning kan påbegyndes. Den primære udfordring i denne fase er at skelne mellem sande og falske positiver — mellem en alarm, der skyldes skadelig aktivitet, og en alarm, der udløses af normal, men usædvanlig adfærd. Effektiv registrering kræver korrekt konfigurerede værktøjer, uddannede analytikere og dokumenterede grundlinjer for normal aktivitet.
Registreringskilder: hvor hændelser dukker op
Hændelser registreres gennem flere kanaler: SIEM-alarmer genereret af korrelationsregler, EDR-registreringer fra adfærdsanalyse på slutpunkter, brugerrapporter (den mest almindelige indledende registrering af phishing), underretninger fra tredjeparter (retshåndhævende myndigheder, leverandører af trusselsinformation og tjenester til underretning om brud), automatiseret scanning (sårbarhedsscannere eller CSPM, der finder uregelmæssigheder) samt trusselsjagt (proaktiv undersøgelse). Hver kilde har sin egen grad af pålidelighed og leverer forskellige typer beviser.
Logkilder til registrering
Effektiv registrering kræver indsamling af logge fra forskellige kilder. Kritiske logtyper omfatter: logge over godkendelse (Windows Security Event Log, /var/log/auth.log) til mislykkede og vellykkede login, netværkslogge (firewall, VPC Flow Logs, proxy) til usædvanlige forbindelser, DNS-logge til forespørgsler til kendte skadelige domæner, slutpunktslogge (EDR, Sysmon) til oprettelse af processer og filaktivitet samt cloud-revisionslogge (CloudTrail, Azure Monitor) til API-kald. En SIEM sammenlægger og korrelerer disse forskellige kilder.
# Key Windows Event IDs for incident detection
# 4624 - Successful logon
# 4625 - Failed logon
# 4648 - Logon using explicit credentials (possible lateral movement)
# 4720 - User account created
# 4732 - User added to privileged group
# 4688 - New process created (enable with audit policy)
# 7045 - New service installed (persistence mechanism)
# 4698 - Scheduled task created (persistence mechanism)Falske positiver kontra sande positiver
SOC-analytikere prioriterer og vurderer hundredvis eller tusindvis af alarmer dagligt, hvoraf de fleste er falske positiver — legitim aktivitet, der udløste en registreringsregel. En falsk positiv spilder analytikerens tid og skaber alarmtræthed, som får reelle trusler til at blive afvist. En sand positiv repræsenterer faktisk skadelig aktivitet. En falsk negativ er det farligste udfald — skadelig aktivitet, der slet ikke udløste en alarm. Finjustering af registreringsregler for at reducere falske positiver uden at øge antallet af falske negativer er en central færdighed i et SOC.
# Alert triage decision matrix
# Alert: 50 failed SSH logins from IP 1.2.3.4
# Investigation questions:
# 1. Is this IP known malicious? (Threat intel check)
# 2. Which account was targeted? (Privileged? Service?)
# 3. Did any login succeed after the failures?
# 4. Is this IP pattern seen on other systems?
# 5. What's the geo-location? Expected for this org?
# If login succeeded + privileged account + unexpected IP = TRUE POSITIVE
# If scanning all ports on internet with no success = likely automated scannerSIEM-korrelationsregler
SIEM-korrelationsregler kombinerer flere individuelle loghændelser for at identificere mønstre, der viser tegn på angreb. Eksempel: Ét mislykket login er normalt; 100 mislykkede login fra den samme IP-adresse på 60 sekunder tyder på brute force. Et andet eksempel: En bruger, der godkendes fra USA kl. 9 og derefter fra Kina kl. 11, kan ikke fysisk nå at rejse mellem stederne — kontoen er sandsynligvis kompromitteret. Effektive korrelationsregler afbalancerer følsomhed (at fange virkelige angreb) med specificitet (ikke at drukne analytikere i støj).
# SIEM rule pseudocode (Splunk SPL style)
# Detect potential brute force followed by success
source=windows:security EventCode=4625
| stats count AS failed_attempts BY src_ip, user
| where failed_attempts > 20
| join user [
search source=windows:security EventCode=4624
]
| where failed_attempts > 20 AND success_login=1
# Alert = brute force succeeded — possible compromiseKompromitteringsindikatorer i analysen
Under analysen indsamler de ansvarlige kompromitteringsindikatorer (IoC'er), der karakteriserer angrebet: mistænkelige IP-adresser, skadelige domænenavne, filhashværdier for malware, registreringsdatabasenøgler ændret af angriberen, usædvanlige procesnavne eller forælder-barn-relationer samt unormale netværksforbindelser. IoC'er bruges til at fastslå omfanget (findes denne IoC på andre systemer?), berige trusselsinformationen, blokere yderligere adgang for angriberen og udvikle SIEM-regler til at registrere lignende aktivitet i fremtiden.
# Searching for an IoC across all endpoints (PowerShell + EDR)
# Search for a specific malware hash on all Windows systems:
Get-WmiObject Win32_Process | Where-Object {
(Get-FileHash $_.ExecutablePath -Algorithm SHA256).Hash -eq
'a1b2c3d4...malware_hash'
} | Select-Object Name, ProcessId, ExecutablePath
# Search for suspicious network connections to known C2 IP:
Get-NetTCPConnection | Where-Object { $_.RemoteAddress -eq '1.2.3.4' }Fastlæggelse af omfang og påvirkning
En omfangsanalyse besvarer: Hvilke systemer er berørt? Hvilke data blev tilgået eller eksfiltreret? Hvordan kom angriberen ind, og hvornår skete det? De ansvarlige bruger loganalyse til at rekonstruere angrebets tidslinje, identificere den oprindelige adgangsvej, opliste alle systemer, som angriberen var inde på (lateral bevægelse), og fastslå, om data blev eksfiltreret (stigninger i udgående overførsler, mapper til midlertidig datalagring). Vurderingen af omfanget styrer beslutninger om indeslutning — du kan ikke indeslutte noget, du ikke har kortlagt.
EDR-analyse i håndtering af sikkerhedshændelser
EDR (Endpoint Detection and Response)-platforme er det primære tekniske værktøj til analyse af hændelser på slutpunktsniveau. EDR-telemetri leverer: træer over proceskørsel (hvad startede hvad), filsystemaktivitet, netværksforbindelser pr. proces, ændringer i registreringsdatabasen og registrering af hukommelsesinjektion. Under en hændelse gør EDR det muligt for analytikere samtidigt at søge efter en IoC på alle slutpunkter (trusselsjagt i hele virksomheden), isolere et kompromitteret slutpunkt fra netværket og hente retsmedicinske artefakter uden fysisk at berøre systemet.
Netværksanalyse under hændelser
Netværksbeviser er ofte den mest pålidelige kilde under analyse af hændelser. NetFlow- og VPC Flow Logs viser forbindelser mellem systemer uden at vise indholdet af datapakkerne — nyttigt til kortlægning af lateral bevægelse. Fuld pakkeoptagelse (PCAP) viser hele kommunikationsindholdet, herunder legitimationsoplysninger, eksfiltrerede data og C2-kommandoer (hvis trafikken ikke er krypteret). Logge over DNS-forespørgsler afslører malware, der regelmæssigt sender signaler til C2-domæner. De ansvarlige leder efter: store udgående dataoverførsler, forbindelser til usædvanlige porte, signalmønstre (regelmæssige forbindelser hvert N. sekund) og intern scanningsadfærd.
Etablering af angrebets tidslinje
Rekonstruktion af angrebets tidslinje er afgørende for at forstå opholdstiden (hvor længe angriberen var til stede før registreringen), identificere den oprindelige adgangsvej (så sårbarheden kan lukkes) og bevare beviserne i kronologisk rækkefølge til retssager. Tidslinjer opbygges ved at korrelere tidsstempler på tværs af flere logkilder. Synkronisering af tid (ved hjælp af NTP) er kritisk — logge med forkerte systemure skaber huller og modsigelser i tidslinjer, som svækker de retsmedicinske konklusioner.
Udløsningspunkter for eskalering og meddelelser
Det er ikke alle alarmer, der kræver fuld aktivering af CSIRT. Analytikere bruger dokumenterede kriterier til at afgøre, hvornår en eskalering skal udløses: Opdagelse af et bekræftet databrud udløser obligatoriske lovpligtige meddelelser og eskalering til ledelsen. Opdagelse af malware, der har spredt sig til mere end ét system, udløser fuld involvering af CSIRT. En enkelt phishingmail (uden klik) forbliver på niveau 1 hos analytikeren. Veldefinerede eskaleringstærskler forhindrer både overreaktion (spild af ressourcer på mindre hændelser) og underreaktion (at større databrud vokser, mens de behandles som mindre alarmer).
Hurtigt tjek
Test din forståelse af begreberne i CompTIA Security+ (SY0-701) fra denne lektion.
Opsummering af lektionen
I denne lektion har du lært, at detektion bygger på forskellige logkilder, der samles af et SIEM med korrelationsregler, som identificerer angrebsmønstre på tværs af flere hændelser, at IoC'er, der indsamles under analysen, bruges til at afgrænse hændelsen på tværs af alle systemer og udvikle blokeringsregler, og at falske negative resultater er det farligste udfald, fordi de giver angribere mulighed for at operere uopdaget. Nu ser vi nærmere på inddæmning, afhjælpning og genoprettelse.
Lær Cloud & IT Cert Prep med en AI-underviser — gratis
Skriv og kør rigtig kode i din browser, få øjeblikkelig hjælp fra en AI-underviser døgnet rundt, og fortsæt, hvor du slap, på web eller i appen.
- Kurser
- 150
- Lektioner
- 600
Ofte stillede spørgsmål
Er lektionen “Detektion og analyse: Identifikation af reelle hændelser” gratis?
Ja — hele teksten til “Detektion og analyse: Identifikation af reelle hændelser” kan læses gratis her på nettet. Hvis du vil øve dig interaktivt med en indbygget kodeeditor og en AI-vejleder døgnet rundt og få adgang til resten af Cloud & IT Cert Prep-kurset, skal du opgradere til CoddyKit PRO. Cloud & IT Cert Prep-kurset indeholder 4 lektioner i alt.
Hvad lærer jeg i “Detektion og analyse: Identifikation af reelle hændelser”?
Lær at triagere alarmer fra SIEM-, EDR- og netværksværktøjer for at skelne sande positive fra falske positive og fastslå hændelsens omfang. Du øver dig i Cloud & IT Cert Prep med praktisk kode, som du kører direkte i browseren, og en AI-vejleder døgnet rundt besvarer dine spørgsmål, mens du arbejder dig gennem lektionen.
Skal jeg have erfaring for at begynde på Cloud & IT Cert Prep?
Der kræves ingen tidligere erfaring. Cloud & IT Cert Prep på CoddyKit er tilrettelagt for både begyndere og øvede, så du kan starte her eller fra begyndelsen og lære i dit eget tempo. Dette er lektion 2 af 4.
Hvor lang tid tager lektionen “Detektion og analyse: Identifikation af reelle hændelser”?
De fleste CoddyKit-lektioner tager cirka 5–10 minutter. Hver lektion er kort og interaktiv, så du gør løbende fremskridt og kan fortsætte, hvor du slap – på både web og app.
Kan jeg skrive og køre kode i denne Cloud & IT Cert Prep-lektion?
Ja. Alle Cloud & IT Cert Prep-lektioner har en indbygget kodeeditor, så du kan skrive og køre rigtig kode direkte i din browser og få øjeblikkelig feedback fra AI – uden lokal opsætning.
Alle lektioner i dette kursus
- Forberedelse: IR-planer, playbooks og teams
- Detektion og analyse: Identifikation af reelle hændelser
- Inddæmning, eliminering og genoprettelse
- Evaluering efter hændelsen og lærte erfaringer