SIEM

Også kendt som: Security Information and Event Management

Et system, der samler logs fra hele organisationen ét sted og slår alarm, når noget ser forkert ud.

Kladde - dette opslag er endnu ikke gennemgået.

Sådan kommer du i gang

De typiske trin i rækkefølge. Tilpas dem til jeres organisation.

Tag udgangspunkt i de trusler og risici, der betyder noget for organisationen, og skriv en prioriteret liste over detektions-use cases koblet til MITRE ATT&CK.
Tilslut de logkilder, hver use case kræver, begyndende med identitet, endpoints, mail og internetvendte systemer, og kontrollér, at felterne parses korrekt.
Beslut, hvem der triagerer alarmer og hvornår (en intern SOC, en MSSP eller en vagtordning), og skriv en respons-playbook for hver use case.
Slå først et lille udvalg af regler til, lad dem køre i stilhed mod rigtige data, og tun tærskler og undtagelser, før de kalder nogen ud.
Hold detektionsreglerne i versionsstyring med beskrivelse, ejer, testdata og ATT&CK-kobling, og gennemgå ændringer, før de går i drift.
Mål alarmmængde, andel af falske positiver og tid til triage hver måned, og tun eller udfas regler, som ingen handler på.
Test detektionerne jævnligt med angrebssimuleringer eller purple team-øvelser og igen efter større ændringer i kilder eller parsere.
Gennemgå dækning og omkostninger hvert kvartal i lyset af nye trusler, hændelser og forretningsændringer, og omsæt erfaringer fra hændelser til nye use cases.

Typiske faldgruber

At købe en SIEM uden folk til at holde øje med og triagere alarmerne.
At slå alle standardregler til og drukne analytikerne i falske positiver.
At skære logkilder fra for at spare licens uden at tjekke, hvilke detektioner der holder op med at virke.
Ikke at opdage, når en kilde eller parser stille går i stykker, og en regel holder op med at slå til.

Gode vejledninger

Building a Security Operations Centre (SOC) - Detection(åbner i en ny fane) · NCSC UK (på engelsk)
Best Practices for Event Logging and Threat Detection(åbner i en ny fane) · CISA (på engelsk)
Best practices for Microsoft Sentinel(åbner i en ny fane) · Microsoft (på engelsk)
MITRE ATT&CK(åbner i en ny fane) · MITRE (på engelsk)

Teknisk uddybning

Begrebet blev skabt af Gartner-analytikerne Mark Nicolett og Amrit Williams i 2005 ved at sammensmelte to ældre produktkategorier: security information management (SIM), der fokuserede på logindsamling, opbevaring og compliancerapportering, og security event management (SEM), der fokuserede på korrelation og alarmering i realtid. En SIEM-pipeline har fem trin. Indsamling sker via agenter, syslog (RFC 5424, helst over TLS efter RFC 5425 frem for UDP, der kan tabe beskeder), Windows Event Forwarding og API-kald mod cloud- og SaaS-tjenester. Parsing og normalisering mapper leverandørspecifikke felter til et fælles skema - tidligere CEF eller LEEF, i dag ofte Elastic Common Schema, Microsofts ASIM eller Open Cybersecurity Schema Framework (OCSF, lanceret i 2022). Berigelse tilføjer kontekst som aktivejer, brugerens afdeling, geolokation og træf i threat intelligence. Korrelation og analyse anvender regler og modeller. Lagringsniveauer (hot, warm, cold eller arkiv) afvejer søgehastighed mod omkostningen ved opbevaring.

Korrelationslogikken spænder fra regler på enkelthændelser (et nyt medlem føjet til Domain Admins) over tærskel- og sekvensregler (mange mislykkede logon efterfulgt af et vellykket fra samme kilde inden for ti minutter) til statistiske baselines og user and entity behaviour analytics (UEBA), der markerer afvigelser, fx en bruger, der henter langt mere data end sine kolleger i samme rolle. Sigma er blevet et leverandørneutralt regelformat, der kan oversættes til forskellige SIEM'ers forespørgselssprog (KQL, SPL, EQL m.fl.), så detektionsindhold kan deles. SIEM'er integreres i stigende grad med SOAR (security orchestration, automation and response), så playbooks automatisk kan berige en alarm, oprette en sag, spærre en konto eller isolere en maskine.

De dominerende begrænsninger er økonomiske og driftsmæssige. Licenser afregnes typisk efter indlæst datamængde (GB pr. dag) eller hændelser pr. sekund, hvilket presser organisationer til at fravælge "støjende" kilder - ofte netop dem, man har brug for i en efterforskning. Parsere går stille i stykker, når en leverandør ændrer sit logformat, så en kilde kan se sund ud, mens felterne er tomme. Detection engineering kræver versionsstyring, test mod eksempeldata og kortlægning af dækning mod MITRE ATT&CK. En SIEM med standardregler og uden tuning giver alarmmængde uden indsigt.

Opbevaringstiden styres af efterforskningsbehov og regulering: efterforskning af hændelser kræver rutinemæssigt måneders historik, fordi dwell time måles i uger, mens logs med personoplysninger skal respektere databeskyttelsesforordningens princip om opbevaringsbegrænsning. NIST SP 800-92 (2006) er den klassiske vejledning i logstyring, og ISO/IEC 27002:2022 kontrol 8.15 (logning), 8.16 (overvågningsaktiviteter) og 8.17 (tidssynkronisering) er de sædvanlige ankre. En SIEM er en platform, ikke en funktion: uden en SOC eller vagthavende analytikere til at triagere outputtet er den et dyrt logarkiv.

Hvad du bør lære først

Alt det, dette bygger på - grundlaget først.

Relationer

En slags: Kontrol (foranstaltning)
Består af: Detektionsregel
Forudsætter: Log Audit-logning
Åbner for: SOAR
Bruges sammen med: Threat intelligence Security operations center (SOC)Audit-logning Log Alarmering Anomalidetektion Endpoint detection and response (EDR)Hændelseshåndtering Kompromitteringsindikator (IoC)Indtrængningsdetektion (IDS)Loghåndtering Sikkerhedsovervågning

Kilder og videre læsning

Standarder og officielle tekster

NIST SP 800-92 - Guide to Computer Security Log Management · NIST

Kursusmateriale

Cyber Security Fast Track - Ordliste

Hvor dataene kommer fra

Dette opslag er skrevet af en AI ud fra kilderne ovenfor og er endnu ikke gennemgået af et menneske. Brug det som udgangspunkt, og tjek alt vigtigt mod kilderne.

Se gennemgangskøen Foreslå en rettelse på GitHub Dette begreb som JSON

Test dig selv

Indlæser…