{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"security/detection-rule","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/security/detection-rule/","da":"https://cmaintz.github.io/tech-atlas/da/terms/security/detection-rule/"},"term":{"en":"Detection rule","da":"Detektionsregel"},"aka":{"en":["trigger rule","SIEM rule"],"da":["triggerregel","SIEM-regel"]},"domain":["security"],"cluster":"security-operations","status":"current","summary":{"en":"A written condition that a monitoring tool checks against incoming logs, raising an alarm whenever the events match it.","da":"En nedskrevet betingelse, som et overvågningsværktøj holder indkomne logs op imod, og som udløser en alarm, hver gang hændelserne matcher."},"body":{"formal":{"en":"A stored query or pattern - for example \"more than ten failed logins for one account within five minutes\" - that a SIEM or similar tool runs against log entries, with a priority and a short guide for the analyst attached.","da":"En gemt forespørgsel eller et mønster - fx \"mere end ti mislykkede login på én konto inden for fem minutter\" - som en SIEM eller et lignende værktøj kører mod logposter, med en prioritet og en kort vejledning til analytikeren vedhæftet."},"plain":{"en":"Like telling a shop guard exactly what to watch for - \"anyone who tries three card terminals in a row\" - instead of asking him to watch for anything strange.","da":"Som at fortælle en butiksvagt præcis, hvad han skal holde øje med - \"enhver, der prøver tre kortterminaler i træk\" - i stedet for at bede ham kigge efter alt mærkeligt."},"inPractice":{"en":"After CFCS warns of a new phishing wave aimed at municipalities, a municipal SOC writes a rule that fires when any staff member's browser visits one of the web addresses in the warning.","da":"Efter at CFCS har advaret om en ny phishing-bølge mod kommuner, skriver en kommunes SOC en regel, der slår alarm, når en medarbejders browser besøger en af webadresserne i advarslen."},"whyItMatters":{"en":"Rules turn a flood of logs into a few alarms worth reading; too loose and staff drown in noise, too tight and a real attack passes unseen.","da":"Regler forvandler en strøm af logs til nogle få alarmer, der er værd at læse; for løse, og medarbejderne drukner i støj, for stramme, og et reelt angreb glider forbi."}},"deepDive":{"en":"Detection rules come in several logical types. Atomic or single-event rules match one log record against conditions (a process named rundll32.exe with a command line referencing a URL). Threshold or aggregation rules count events per key over a time window (more than N failed logons per account in five minutes). Correlation or sequence rules require several events in order, often across sources (a successful logon from a new country followed within an hour by mailbox forwarding rule creation). Indicator-matching rules join events against a feed of indicators of compromise. Rules can run as scheduled queries over stored data or as streaming evaluations on ingest; scheduled rules need overlapping look-back windows and must account for ingestion delay, or events that arrive late are silently never evaluated.\n\nEach platform has its own language: Splunk SPL, Microsoft Sentinel and Defender KQL, Elastic EQL and ES|QL, and Google SecOps YARA-L. Sigma, started in 2017 by Florian Roth and Thomas Patzke, is the vendor-neutral YAML format: a rule declares a logsource (product, category, service), named selections of field conditions, a condition expression that combines them, plus metadata such as level (informational to critical), falsepositives and ATT&CK tags; converters translate it into the query language of the target backend. Sigma specification 2.0 standardised correlation rules for counting and ordering matches of other rules. Neighbouring formats cover other layers: YARA for byte and string patterns in files and memory, and Snort or Suricata signatures for network traffic.\n\nMature teams treat rules as code (detection-as-code). Rules live in version control with a unique ID, an owner, an ATT&CK mapping, a triage guide, known benign causes and test data; changes go through review and CI that validates syntax, runs the rule against recorded malicious and benign samples, and deploys it. Adversary emulation (for example Atomic Red Team tests mapped to ATT&CK techniques) verifies that the telemetry and the rule actually fire. The ATT&CK mapping yields a coverage map, though coverage by technique ID is only a rough proxy: one rule rarely covers every procedure that implements a technique.\n\nRule quality is a trade-off along David Bianco's Pyramid of Pain: rules keyed to hashes or IP addresses are precise but trivially evaded, whereas rules on behaviour (tools, techniques, procedures) are more durable but generate more benign matches and need tuning. Tuning usually adds exclusions, which must be narrow and reviewed, because a broad allowlist entry such as a whole directory or a signed binary becomes a blind spot attackers can use. Rules also depend on logging configuration: a rule for PowerShell script-block content is useless if script-block logging (event ID 4104) is not enabled, which is why rules should document their required data sources.","da":"Detektionsregler findes i flere logiske typer. Atomare regler eller regler for enkelthændelser matcher én logpost mod betingelser (en proces ved navn rundll32.exe med en kommandolinje, der henviser til en URL). Tærskel- eller aggregeringsregler tæller hændelser pr. nøgle over et tidsvindue (mere end N mislykkede logins pr. konto på fem minutter). Korrelations- eller sekvensregler kræver flere hændelser i rækkefølge, ofte på tværs af kilder (et vellykket login fra et nyt land fulgt inden for en time af oprettelse af en videresendelsesregel i postkassen). Indikatorregler matcher hændelser mod et feed af kompromitteringsindikatorer. Regler kan køre som planlagte forespørgsler over lagrede data eller som streaming-evaluering ved indlæsning; planlagte regler kræver overlappende look-back-vinduer og skal tage højde for forsinkelse i indlæsningen, ellers bliver hændelser, der ankommer sent, i stilhed aldrig evalueret.\n\nHver platform har sit eget sprog: Splunk SPL, KQL i Microsoft Sentinel og Defender, EQL og ES|QL i Elastic og YARA-L i Google SecOps. Sigma, som Florian Roth og Thomas Patzke startede i 2017, er det leverandørneutrale YAML-format: en regel angiver en logsource (product, category, service), navngivne selections af feltbetingelser, et condition-udtryk, der kombinerer dem, samt metadata som level (informational til critical), falsepositives og ATT&CK-tags; konvertere oversætter den til målsystemets forespørgselssprog. Sigma-specifikationen 2.0 standardiserede korrelationsregler, der tæller og ordner match fra andre regler. Nabostandarder dækker andre lag: YARA til byte- og strengmønstre i filer og hukommelse og Snort- eller Suricata-signaturer til netværkstrafik.\n\nModne teams behandler regler som kode (detection-as-code). Reglerne ligger i versionsstyring med et unikt id, en ejer, en ATT&CK-kortlægning, en triagevejledning, kendte godartede årsager og testdata; ændringer gennemgår review og CI, der validerer syntaksen, kører reglen mod optagede ondsindede og godartede eksempler og udruller den. Emulering af angribere (fx Atomic Red Team-tests knyttet til ATT&CK-teknikker) bekræfter, at telemetrien og reglen faktisk slår til. ATT&CK-kortlægningen giver et dækningskort, men dækning opgjort pr. teknik-id er kun en grov tilnærmelse: én regel dækker sjældent alle de procedurer, der kan udføre en teknik.\n\nRegelkvalitet er en afvejning langs David Biancos Pyramid of Pain: regler knyttet til hashes eller IP-adresser er præcise, men trivielle at omgå, mens regler på adfærd (værktøjer, teknikker, procedurer) holder længere, men giver flere godartede match og kræver justering. Justering tilføjer som regel undtagelser, som skal være snævre og gennemgås, fordi en bred allowlist-post, fx en hel mappe eller en signeret binærfil, bliver en blind vinkel, angribere kan udnytte. Regler afhænger også af logkonfigurationen: en regel for indholdet af PowerShell-scriptblokke er værdiløs, hvis script block logging (hændelses-id 4104) ikke er slået til, og derfor bør regler dokumentere, hvilke datakilder de kræver."},"edges":[{"type":"requires","to":"cs/log","confidence":"high","strength":"normal"},{"type":"part-of","to":"security/siem","confidence":"high","strength":"normal"},{"type":"causes","to":"security/false-positive","why":{"en":"A rule drawn too wide also matches normal work, sending alarms about things that are not attacks.","da":"En regel, der er for bredt formuleret, matcher også almindeligt arbejde og sender alarmer om ting, der ikke er angreb."},"confidence":"high","strength":"normal"},{"type":"used-with","to":"security/mitre-attack","why":{"en":"Teams name each rule after the attacker method it covers, which shows where their rules still leave gaps.","da":"Teams knytter hver regel til den angrebsmetode, den dækker, hvilket viser, hvor reglerne stadig har huller."},"confidence":"high","strength":"normal"},{"type":"used-with","to":"security/indicator-of-compromise","confidence":"high","strength":"normal"}],"depth":1,"sources":[{"title":"NIST SP 800-92 - Guide to Computer Security Log Management","url":"https://doi.org/10.6028/NIST.SP.800-92","tier":"standard","publisher":"NIST"},{"title":"Cyber Security Fast Track - SIEM module","tier":"course-material"},{"title":"Sigma Specification (v2.0), incl. Sigma Correlation Rules","url":"https://github.com/SigmaHQ/sigma-specification","tier":"official-doc","publisher":"SigmaHQ"}],"draft":true}