How detections work

About 13 min read

Modern security platforms layer many kinds of detection logic Detection Logic The rule, model, or heuristic that decides whether a given input fires an alert. The logic that produced the alert matters as much as the alert it produced; two engines can name the same alert for very different reasons. on top of each other. ASSURED groups them into four families; this is a teaching taxonomy, not a standard (NIST SP 800-94, from 2007, uses signature-based, anomaly-based, and stateful protocol analysis), but it maps cleanly onto how alerts arrive in practice. In 2026 almost every product blends the families, so the label matters less than two questions: what can this logic see, and how does it fail?

When an alert arrives, ask which mechanisms produced it (plural on purpose): real detections are often hybrids. A deterministic Sigma rule that encodes a behavioral parent-child sequence is both rule-based and behavioral, and a “signature” hit may be one condition inside a larger correlation. The families are lenses for reading a detection, not boxes it must fit into, and naming the family is the start of reading the rule that actually fired, never a substitute for it.

The four families at a glance

Every family here is detection logic. User reports, external notifications, hunt findings and MDR escalations reach the SOC without a detection engine behind them; Other intake covers how to read those.

The four families, by how they fail

Each family is good at something specific and blind to something else. For triage the useful facts are the failure modes: what slips past the family (its false negatives), what its false positive looks like when it fires on nothing, and the first check that tells the two apart.

Signature-based detection

What it models

Known-bad artifacts Signature-Based Detection One of the four detection families ASSURED teaches: matching activity against known-bad patterns such as hashes, byte sequences, YARA rules or network signatures. Precise and cheap, but blind to anything new or modified. See Signature-based detection. : file hashes, import and similarity hashes, YARA byte patterns, domains, IP addresses, certificates, and network patterns such as Snort or Suricata content matches. The match is deterministic: the input matches the library or it does not.

What it misses

Anything genuinely new. Exact hashes and indicator lists miss altered variants too: a recompiled payload has a new hash, a fresh domain walks past a domain list, and living-off-the-land activity uses binaries no library flags. Similarity hashes and YARA byte patterns catch close variants of known families, not new code. It sits at the bottom of the Pyramid of Pain (below), so it is precise and fragile at once.

What its false positive looks like

A correct match on the wrong meaning: a stale indicator on an address that has since been reassigned, shared infrastructure (a CDN, a cloud provider, a sinkhole), a dual-use tool’s hash, or a generic heuristic AV name. A deterministic match is not a deterministic verdict.

First checks

The indicator’s first-seen date and feed (IP addresses and domains age fastest), its prevalence in your fleet (a hash on hundreds of hosts for months is more likely a tool or a bad signature than a fresh intrusion), and what a recompiled sibling would look like in process and network telemetry.

Anomaly-based detection

What it models

This environment's normal Anomaly-Based Detection One of the four detection families ASSURED teaches: the engine learns a baseline and alerts on deviations from it. It can catch activity no signature describes, at the price of firing on legitimate change. Ask what baseline the engine used and how long it had to learn. See Anomaly-based detection. : one observation, or one metric aggregated over a window, compared with a baseline for the entity, its peer group, or the fleet.

What it misses

Patience. Activity kept inside normal ranges (low and slow) never deviates, and activity present while the model was learning becomes part of the baseline. A baseline is only as clean as its learning window; the Subject chapter’s behavioral framework covers cold starts, peer groups and poisoned baselines.

What its false positive looks like

A real deviation with a benign cause: travel, a new tool rollout, a migration or merger, a role change, or a timezone error that makes ordinary work look off-hours. Most anomaly alerts are true deviations; the question is what explains them.

First checks

The baseline’s age and window (a brand-new entity has no history; treat that as unknown, not normal), the time converted to UTC and to the entity’s business timezone, and a join to identity, process or network telemetry before the deviation becomes a lead or a close.

Rule-based detection

What it models

Known-bad scenarios written by people Rule-Based Detection One of the four detection families ASSURED teaches: explicit logic over events (thresholds, sequences, field conditions), written as SIEM correlation rules or Sigma. Rules are transparent, so the analyst can read exactly why one fired, and brittle, so small variations slip past. See Rule-based detection. : several conditions, often within a short window, expressed as Sigma, KQL, SPL, YARA-L or EQL. It is the team’s institutional knowledge made executable.

What it misses

Every variant the author did not anticipate: an intermediate parent process, a renamed binary, a different log source, or a host where the telemetry the rule needs is missing or late. The rule’s “blind spots and assumptions” record says what it is known to miss.

What its false positive looks like

Two kinds, and they need different fixes. A logic false positive matches benign activity the author did not exclude (a signed internal add-in calling PowerShell). A stale benign hit fires correctly on activity the business has since made normal: a benign true positive, cleared by context (a pattern entry or a scoped, expiring exception) while the rule stays as written. Only the first is a logic fix; record which one it was in the case.

First checks

Open the rule before the evidence: its conditions, its documented false positives, when it was last tested and changed, and whether a suppression or exception is active. Then check each condition against raw telemetry. A rule with no recorded test, or one edited last week, earns less trust than one proven against a known-bad sample last month.

Behavioral analytics

What it models

A progression of related events: an ordered sequence across users, hosts and hours or days, learned by a UEBA User and Entity Behavior Analytics (UEBA) Security analytics that build behavioral baselines for users and entities (hosts, service accounts, applications) and score deviations from them: unusual logon times, first-seen hosts, data volumes far above normal. Its alerts are anomalies, not verdicts, and they are only as good as the baseline, which can absorb an attacker who has been present long enough (behavioral drift). model or hand-written as a correlation. Anomaly asks whether one observation is unusual; behavioral asks whether several observations together describe an adversary’s progression.

What it misses

Isolated critical actions that do not fit a multi-event pattern, and every step outside the model’s window or data sources. A model that is never revalidated drifts quietly.

What its false positive looks like

A manufactured story: one misattributed event (a shared host, a reused process ID, a service account acting for many people) stitched into a sequence, or a legitimate admin workflow that happens to follow an attack’s shape.

First checks

Open the raw event behind every step, not just the narrative. Pivot on the same entity just before the first step and just after the last, because the model only links what it covers. Carry the timeline into the handoff intact, with source and timestamp for every step.

When you cannot read the rule

Much of a modern queue is vendor-managed cloud, identity, and SaaS detections (AWS GuardDuty, Microsoft Entra ID Protection, Okta ThreatInsight, Microsoft Defender for Cloud Apps) and proprietary EDR or XDR content. These alerts show a title, a severity, and evidence entities, not the logic. “Read the rule” still applies; it just changes shape:

1. Identify the provider’s documented detection name and look up its published description and known false-positive conditions.
2. Treat the provider’s risk level as a prior, the same way you treat a family label, and use this alert title’s local history as the precision signal.
3. Treat the evidence entities and raw events as the rule. Validate with the events behind the alert (CloudTrail, Entra sign-in logs, the Okta System Log, the process tree) rather than with the vendor’s summary.
4. Record “logic not inspectable” as a calibration fact, and send repeated ambiguity to the vendor, or ask detection engineering for a wrapper rule you can read.

Alert: Unfamiliar sign-in properties
Source: Microsoft Entra ID Protection (risk detection)
Risk level: Medium
User: a.nguyen@corp.example
Sign-in: 2026-10-06 07:42 UTC, new ASN, new browser, MFA satisfied
Detection logic: vendor-managed (not inspectable)

Here the family is mostly anomaly (new properties against this user’s sign-in history), the logic is opaque, and the validation lives in the sign-in log entries themselves: the device, the session that followed, and what that session touched.

Trust calibration

Each family carries a different prior: a starting posture, useful for the first thirty seconds and no longer. The mechanism label alone never determines confidence: that comes from the actual rule logic, the telemetry behind it, and the rule’s measured performance in your environment. Before translating any label into trust, check the local calibration facts: the rule’s version and last review, its precision here (what fraction of recent fires matched the behavior the rule describes) and its actionability (what fraction needed action), what it is known to miss, how common the matched artifact is in this environment, and whether suppressions or exceptions are currently active on it.

Where to find them: the rule’s metadata or its detection documentation record, the detection catalog, the tuning ticket history, and the last 30 to 90 days of dispositions for this rule. For expected telemetry and known gaps by technique, ATT&CK’s Detection Strategies and Analytics (added in v18) are the public reference. The base rate matters more than the family: a rule that fired 200 times last month with 2 malicious true positives has 1% local precision for malicious activity, so start skeptical, whatever the family. Rare events are mostly false alarms even from good models, because the benign population is so much larger.

Four more sources of alerts need their own priors:

The Pyramid of Pain

One more lens cuts across the families: what the detection keys on. David Bianco’s Pyramid of Pain Pyramid of Pain David Bianco's model (2013) ranking indicators by how much it costs an attacker when defenders detect them: hash values (trivial to change), IP addresses, domain names, network and host artifacts, tools, and TTPs at the top (hardest to change). Detections built on behavior outlast detections built on hashes. (2013) ranks indicators by how much it costs the adversary to change them once defenders detect them: hash values are trivial, IP addresses easy, domain names simple, network and host artifacts annoying, tools challenging, and tactics, techniques and procedures (TTPs) tough. Hash and indicator signatures sit at the bottom, which is why a hit there is precise and also fragile: a recompiled payload or a new domain walks past it. Rules and behavioral sequences that key on artifacts and techniques sit higher and outlast the indicator. For triage, the level tells you what a miss looks like: a bottom-of-pyramid match says this exact artifact is back, and says nothing about the variant the adversary built next.

Reading a rule the way detection engineers keep it

One rule, three ways

Here is one rule, “an Office application spawns PowerShell that then reaches the network”, written the way detection engineers actually keep it: first as a Sigma Sigma A vendor-neutral, open standard for describing SIEM detection rules. Sigma rules can be translated into the query languages of multiple SIEMs, which makes them portable across detection platforms. rule. (Sigma expresses the 60-second network condition as a separate correlation rule; this is the process half.)

title: Office application spawns PowerShell
id: 0f2c7f43-6a1e-4f7e-9d0b-3c5a2b8e1d77
status: stable
description: Detects Word, Excel or PowerPoint launching PowerShell, a common initial-access chain.
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    ParentImage|endswith: ['\winword.exe', '\excel.exe', '\powerpnt.exe']
    Image|endswith: ['\powershell.exe', '\pwsh.exe']
  condition: selection
falsepositives:
  - Signed internal add-ins that call PowerShell (document them as exceptions)
level: high
tags:
  - attack.execution
  - attack.t1059.001

How to read it during triage:

• logsource says which telemetry the rule needs. If that telemetry is missing or late on this host, the rule could not have fired correctly.
• detection / condition are the actual logic: every field named here had to match.
• falsepositives is the author’s list of known benign triggers. Check it before you investigate.
• level is the author’s severity, a prior rather than a verdict. status (experimental, test, stable) tells you how much field testing the rule has had.
• tags map the rule to ATT&CK (here T1059.001, PowerShell), which tells you what the author thought they were catching.

The same full rule, network leg included, as a KQL KQL Kusto Query Language: Microsoft's piped, read-only query language for Sentinel, Defender XDR Advanced Hunting, Log Analytics and Azure Data Explorer. query for Microsoft Defender XDR advanced hunting:

// Office spawns PowerShell, and that PowerShell connects out within 60 seconds
let OfficeApps = dynamic(["winword.exe", "excel.exe", "powerpnt.exe"]);
let PowerShell = dynamic(["powershell.exe", "pwsh.exe"]);
DeviceProcessEvents
| where Timestamp > ago(1d)
| where InitiatingProcessFileName in~ (OfficeApps) and FileName in~ (PowerShell)
| project DeviceId, DeviceName, AccountName, ProcessId,
          ProcessStarted = Timestamp, ProcessCommandLine
| join kind=inner (
    DeviceNetworkEvents
    | where Timestamp > ago(1d)
    | where InitiatingProcessFileName in~ (PowerShell) and ActionType == "ConnectionSuccess"
    | project DeviceId, InitiatingProcessId, ConnectedAt = Timestamp, RemoteUrl, RemoteIP
  ) on $left.DeviceId == $right.DeviceId, $left.ProcessId == $right.InitiatingProcessId
| where ConnectedAt between (ProcessStarted .. ProcessStarted + 60s)

Read it the same way. The two tables are the log source: they exist only for hosts where Defender for Endpoint reports. The where lines are the conditions, and the join is the correlation the Sigma process rule left to a second rule. Process IDs are reused, so production versions also match on the process start time.

Well-run teams document each detection with an Alerting and Detection Strategy (ADS) record. Here is this rule’s, in summary:

“Blind spots and assumptions” is where “what it is known to miss” lives, and it is the first field to read when a rule like this stays quiet on a host where you expected it to fire. When a case shows the rule missing something it should have caught, or firing on something it should not, the gap goes back to the rule’s owners through detection feedback.