Triage and detection engineering

About 15 min read

On this page

Every chapter of this site says that closes feed detection engineering . This page is the interface that sentence depends on: what the triage desk sends, in what shape, to whom, and what it should get back. Without it, feedback arrives as “this rule is noisy” in a chat channel, the wrong team gets the ticket, and a rule that works gets de-tuned because nobody wrote down that it fired correctly.

The page is for both sides of the desk. Analysts get the routing rules and the request template; SOC leads and detection engineers get the governance and the shared numbers. In a small SOC the same person may wear both hats. The request still gets written, because the written request is what lets a second person review the change.

What each side owes the other

Triage owes detection engineering

The verdict on both axes: the exact values, on every close. Detection: true positive, false positive (logic), false positive (data). Activity: malicious, policy violation, authorized (benign true positive), benign-confirmed, undetermined. Every per-rule number below is computed from these two fields.
The rule’s identity: name, ID and version as deployed when it fired, and the exceptions active on it at the time.
Evidence by ID, not by impression: the case IDs, the sample alert IDs, and the field values that justify a change.
A proposed change with its risk: what to change, what it could silence, and the two test samples that prove it.
The gaps found in Uncover: techniques observed in a case that raised no alert, written so detection engineering can act on them (see Uncover’s deliverables).
No silencing from the console: a suppression or alert-tuning rule created to clear a queue, outside a request, is a detection change nobody reviewed.

Detection engineering owes back

A readable rule, or a recorded reason it cannot be read: an Alerting and Detection Strategy (ADS) record or equivalent, with its known false positives and blind spots.
Calibration facts: the rule’s version, last review, precision here, known benign triggers and active exceptions, findable in seconds (see trust calibration).
A decision on every request: accepted, changed or declined, with a reason, within a time both teams agreed in writing.
Change notices: every rule change versioned and announced, because a change to a linked rule invalidates the pattern entries that rely on it.
Tests: every change proved against a malicious sample before it ships.
Enrichment: the fields triage needs to decide fast, added to the alert when a request shows they were missing.

The routing table

The verdict decides the route. A benign close that is a false positive goes to whoever owns the defect; a benign close that is a benign true positive goes to context, and the rule stays as written. What a benign close teaches explains the fork; this table extends it to every finding a case can hand detection engineering.

Where each finding goes. Request types refer to the tuning request below.
Finding	What it looks like	Route	Owner and artifact
False positive (logic)	The rule matched something it was not meant to describe: an over-broad pattern, the wrong field, a broken condition.	A logic change plus a regression test proving the rule still fires on the malicious variant.	The rule’s owner. Tuning request: logic change.
False positive (data)	The logic was right and its input was wrong: a parser error, a missing or mis-mapped field, clock skew, duplicate ingestion, a stale asset tag.	A pipeline or parser fix, not a rule ticket. Working around bad data inside one rule hides the defect from every other rule that reads the same field.	The log-pipeline or platform owner. Tuning request: data or pipeline fix. Case D follows one: a parser that stamped receipt time as event time.
Benign true positive, one-off	The rule read the activity correctly, the activity was authorized, and it is not expected to recur (a one-time migration, a ticketed penetration test).	Document it in the close. No request.	The analyst. The close record.
Benign true positive, recurring class	The same authorized behavior fires again and again: a sanctioned tool, a scheduled job, a role’s normal workflow.	A pattern entry first, so the alert still fires and closes fast against written discriminators. Only when volume demands a silencing control: a scoped, expiring exception keyed to the context that makes it benign. The rule logic stays as written.	The pattern library owner (pattern entry); detection engineering for any exception. Tuning request: exception.
Correct fire, too little context	The verdict was right but slow, because the alert lacked the fields that decide it. In Case B those were the extension ID, the child’s command line and the destination set.	An enrichment request: put the deciding fields on the alert.	Detection engineering. Tuning request: enrichment.
True positive, under-rated	A malicious true positive the rule caught at a severity that left it waiting in the queue, or caught only at a late step when an earlier one was visible.	A severity change, or a new detection on the earlier step.	Detection engineering. Tuning request: severity change or new detection.
Coverage gap found in Uncover	A technique observed in the case that raised no alert: a false negative . In Case A, the rule’s network leg read only the web proxy, so the same chain on a laptop off the VPN raised nothing.	A new-detection request, mapped to the ATT&CK technique and its Detection Strategy.	Detection engineering. Tuning request: new detection.
A chain no rule linked	Several low-signal events on one entity over days, each closed alone or never alerted (the attack-chains example).	A risk-rule request: let those observations add risk to the entity instead of raising alerts of their own.	Detection engineering. Tuning request: risk-rule request.
A rule you could not read	An undocumented or misleading in-house rule, or a vendor detection whose fires stay ambiguous from one case to the next.	In-house: a documentation request (an ADS record). Vendor-managed: a vendor case, or a wrapper rule the team can read (see alert provenance).	The rule owner, or the platform owner for vendor content. Tuning request: documentation, or vendor case or wrapper rule.
A control gap, not a detection gap	The case shows a missing preventive control: in Case C, push MFA that is not phishing-resistant and user consent open to unverified publishers.	IR’s recommendations, or the control owner. Not the detection backlog.	IR or the control owner. The event report’s recommendations.
Undetermined	The activity verdict could not be reached.	No rule change until the case resolves. The case closes with its gaps named and a reopen trigger , or moves up a level (see undetermined verdicts). File an enrichment or data request only when a missing field is what kept it undetermined (Case D closes this way).	The analyst. The close record.

Three rules the table does not override

A request never holds up a case decision: file it after the verdict, and if an escalation criterion is confirmed, the escalation tripwire escalates first and the request waits. Never add or widen an exception on a rule while a case it fired on is open at P1 or P2 or is with IR, because IR may be using those fires to track scope. And one request covers one rule (or one missing detection), so each can be decided, tested and closed on its own.

Mapping the console’s close codes

Many teams close in a console whose classifications do not match these values one for one. Record the ASSURED values in the case record, and map them like this:

ASSURED verdict	Microsoft Sentinel close classification	Microsoft Defender XDR alert classification
True positive · malicious or policy violation	True Positive - suspicious activity	True positive
True positive · authorized or benign-confirmed	Benign Positive - suspicious but expected	Informational, expected activity
False positive (logic)	False Positive - incorrect alert logic	False positive
False positive (data)	False Positive - incorrect data	False positive
Undetermined	Undetermined	No equivalent; keep the value in the case record

Defender XDR has one false-positive value for both kinds, so the logic-or-data split lives only in your case record. Without it, the two rows of the routing table that send work to different owners collapse into one queue. Sources: Microsoft Learn, Sentinel incident triage (updated July 2026) and Investigate alerts in Defender XDR (updated September 2026), both checked October 2026.

The tuning request

The tuning request is the one artifact that carries every row of the routing table except the one-off close and the control gap. The name is historical: the request type field covers exceptions, enrichment, logic and data fixes, severity changes, new detections, risk rules, documentation, vendor cases and retirements. The one-page reference calls it the detection-engineering feedback, and the Documentation phase is where it is written.

A good request does five things:

Names one rule at one version. A request against “the PowerShell rules” cannot be tested or closed.
Carries evidence by ID. Case IDs, sample alert IDs, the window, and how many fires in it carried each verdict. Reference the case; do not paste it. Copy only the fields the change needs, and refer to insider-risk cases by case ID alone.
States the change and its scope. Entity- or field-level by default. Anything rule-wide needs the approver’s explicit sign-off.
States the risk of the change. What the change could silence, and how an attacker who learned of it could ride it. A request that cannot answer this is not ready.
Brings two test samples. A benign sample that should stop alerting (or should now carry the new field), and a malicious sample or emulation that must still fire. An Atomic Red Team test for the technique is the usual source of the second.

Tuning request (triage to detection engineering) tuning-request.md · 98 lines · Template version 2.0

Download tuning-request.md JSON Schema

# Tuning request (triage to detection engineering)

<!-- ASSURED Methodology by Timothy Zilber, © Block, Inc., CC BY 4.0
     (https://creativecommons.org/licenses/by/4.0/). Reuse and adapt freely
     with attribution; note any changes you make.
     Template version: 2.0
     ASSURED detection feedback
     (https://assured-methodology.vercel.app/docs/detection-feedback).
     One request per rule (or per missing detection). File it after the
     case has a verdict on both axes; a request never holds up a close or
     an escalation. Use the routing table on the detection-feedback page to
     pick the request type and the owner. Reference cases and alerts by ID
     and copy only the fields the change needs: no personal data beyond what
     the rule itself matches, and insider-risk cases by case ID only.
     Sections 1 to 6 are the analyst's; section 7 is detection
     engineering's. -->

## 1. Request

- Request ID (e.g. DE-NNNN):
- Request type (one): exception · enrichment · logic change · data or
  pipeline fix · severity change · new detection · risk-rule request ·
  documentation · vendor case or wrapper rule · retire
- Routed to (rule owner, pipeline owner, vendor contact, or pattern-library
  owner):
- Filed by, and date (UTC):
- Material AI use (assistant and version, and which fields began as AI
  drafts; "none" if unassisted):

## 2. The detection

- Rule name, ID, and version as deployed when it fired (for a new-detection
  request: "none fired", and the technique that went unseen):
- Provider (in-house · vendor-managed · community Sigma · managed provider)
  and whether the logic is inspectable (yes · no: vendor-managed):
- ATT&CK technique ID(s) and version (e.g. Enterprise v19), and the
  Detection Strategy (DET) and Analytic (AN) IDs where known:
- Exceptions, suppressions, and pattern entries active on this rule when it
  fired (IDs):

## 3. Evidence

- Cases (every case ID that motivated the request):
- Sample alert IDs (benign samples for exceptions and fixes; for a gap, the
  event IDs of the activity that raised no alert):
- Verdict on both axes, using the exact values:
  - Detection: true positive · false positive (logic) · false positive (data)
  - Activity: malicious · policy violation · authorized (benign true
    positive) · benign-confirmed · undetermined
- Window and volume (fires in the window, and how many carried each
  verdict):
- Observed precision (true-positive fires / fires with a detection verdict,
  benign true positives counted as correct) and actionability (fires that
  needed action beyond the close / fires), with the window:
- The fields and values that justify the change:
- What the analyst could not see (missing fields, telemetry the rule does
  not read):

## 4. Proposed change

- The change, as specifically as you can state it. For an exception, the
  tuple it is keyed to (for a tool: version or pinned hash, extension or
  plugin ID, destination set). Never signer and install path alone.
- Scope (entity- or field-level; anything rule-wide needs the approver's
  explicit sign-off):
- Expected effect (volume, precision and actionability before and after):
- Risk of the change (what it could silence, and how an attacker could ride
  it):

## 5. Tests

- Benign sample that should stop alerting, or should now carry the new
  field:
- Malicious sample or emulation that must still fire (event replay, or an
  Atomic Red Team test ID for the technique):

## 6. Governance (exceptions and suppressions only)

- Owner (named person):
- Approver (a second person, not the requester):
- Expiry date (by default 90 days; shorter for a tool that updates often):
- Re-fire triggers (e.g. version change, new extension or plugin ID,
  destination outside the set, rule change, observed abuse):
- Hit-count monitoring (expected hits per week, and the threshold that
  forces review):
- Linked pattern entry (PTN-NNN and version), if one exists:
- Re-test at expiry: the malicious sample from section 5 still fires.

## 7. Resolution (detection engineering)

- Decision (accepted · accepted with changes · declined), with the reason:
- Change reference (pull request or commit) and deployed rule version:
- Tests run, and results (benign sample, malicious sample):
- Pattern entries invalidated by this change, and their owners notified:
- Triage notified (date, channel):
- Result after 30 days (volume, precision, any reversed closes or missed
  detections):
- Closed (UTC date):

A filled request: the exception shown later on this page

DE-NNNN · type: exception · routed to: rule owner, detection engineering
Rule: "Rclone copies data to cloud storage", id 3f6a2c1e..., version of 2026-07-15
Provider: in-house Sigma; logic inspectable: yes
ATT&CK: T1567.002 Exfiltration Over Web Service: Exfiltration to
Cloud Storage (Enterprise v19)
Active exceptions when it fired: none
Cases: CASE-20260814-031 and the 26 later closes (case query linked)
Verdict, all 27 fires in 30 days: true positive · authorized (benign true positive)
Precision 27/27; actionability 0/27
Subject: svc-archive-upload, not privileged (read scope: the export share
only; write scope: the archive bucket; identity inventory, 2026-08-30)
Justifying fields: User = that service account; Hashes = the build the
backup team pinned; CommandLine target = the archive remote; proxy log shows
only the archive's storage endpoint
Change: filter keyed to all three fields together, never to the binary alone
Risk: an attacker holding the service account who reuses the pinned build and
the remote label passes the filter; mitigated by the separate egress rule on
the job's destinations, which this request leaves untouched
Tests: benign = last night's job events (stop alerting); malicious = the same
binary run by another account, and the pinned build run to any other
remote (both must still fire)
Owner: backup-platform lead · approver: detection-engineering lead
Expiry: 2026-11-30 · re-fire triggers: new rclone build, new remote, any other
account, rule change · expected hits: about 7 a week; review above 15

Exception and suppression governance

Four tools reduce what reaches the queue, and they cost different amounts of visibility. Choose the cheapest one that solves the problem:

Tool	What happens	What is lost	Right for
Pattern entry	The alert still fires; triage closes it at Level 0 against written discriminators	Analyst minutes, nothing else	A recurring benign true-positive class
Exception	The rule still runs; a narrow, context-keyed tuple is excluded from alerting	Alerts on that tuple only	A recurring class whose volume a pattern entry cannot absorb
Suppression	The alert is hidden, by rule, host set or time window	Everything the suppression matches	Rarely; a short window with a named reason
Tuning	The rule’s logic changes	Whatever the new logic no longer matches	False positives (logic), never benign true positives

Every exception and every suppression is governed the same way:

A record with eight parts: its scope (entity- and field-level, never rule-wide), a rationale with the case link, an owner, an approver who is not the requester, an expiry date, storage as code next to the rule, a monitored hit count, and a re-test at expiry proving the rule still fires on the malicious variant.
Keyed to the context that makes it benign. For a sanctioned tool, that is the tuple of tool version, extension or plugin ID, and destination set, with re-fire triggers for a version change, a new extension and a new destination. Never signer and install path alone: code running inside a signed host (an IDE extension, an MCP server, a package-manager script) inherits both. Case B’s pattern entry is the worked example.
Expired means off. An exception past its expiry stops applying until the owner re-tests and renews it. It does not roll over quietly.
Watched by hit count. Zero hits for a full review period means the exception can be retired. A spike needs review: either the sanctioned activity changed, or someone who learned the tuple is riding it.
Never looser than Level 0. An exception hides alerts that a Level 0 close would at least have seen, so it never covers a subject that would fail the eligibility gate: a crown-jewel asset, a privileged identity, or automation with deploy, signing, secrets or repository-write capability.
Listed in one register. Every active exception and suppression, its owner and expiry, and how many are past due. This exception register is what makes the inventory numbers below computable.

Vendor consoles use their own words for these tools, so read what a feature does rather than what it is called. Defender XDR’s alert tuning (previously alert suppression) offers three actions: Hide alert suppresses the alert (Defender for Endpoint alerts only); Set as behavior keeps the signal for hunting without queueing it, which preserves more than a suppression does; and Resolve alert resolves the alert and its incidents automatically. In this methodology that last one is a machine close, so it is allowed only under the governed tier: a pattern entry carrying the machine-close flag , discriminators evaluated by code, the eligibility gate enforced, human QA sampling, tracked reversal and miss rates, and a kill switch with a named owner (Microsoft Learn, Tune an alert, updated September 2026).

Reading a rule and its exceptions during triage

The rule family page walks a full Sigma rule and its ADS record field by field. The skill this page adds is reading the exception that sits next to a rule, because an alert in front of you is also evidence about every exception that did not apply to it. Sigma keeps exceptions as separate filter files that name the rules they apply to; at conversion the filter’s condition is appended to the rule’s, so the rule file itself stays unedited (Sigma Filters Specification v2.1.0, 2025-08-02; SigmaHQ filter documentation, checked October 2026).

# rules/proc_creation_win_rclone_cloud_copy.yml
title: Rclone copies data to cloud storage
id: 3f6a2c1e-8b4d-4e7a-9c2f-1d5e7b9a0c34
status: stable
modified: 2026-07-15
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\rclone.exe'
    CommandLine|contains: [' copy ', ' sync ', ' move ']
  condition: selection
falsepositives:
  - Sanctioned backup jobs (see filter EXC-0142)
level: high
tags:
  - attack.exfiltration
  - attack.t1567.002

# filters/exc-0142_backup_rclone.yml
title: EXC-0142 nightly backup job to the sanctioned archive
description: DE-NNNN from CASE-20260814-031. Owner, approver and expiry are in the exception register.
date: 2026-09-01
logsource:
  category: process_creation
  product: windows
filter:
  rules:
    - 3f6a2c1e-8b4d-4e7a-9c2f-1d5e7b9a0c34
  selection:
    User: 'CORP\svc-archive-upload'
    Hashes|contains: 'SHA256=(pinned build hash)'
    CommandLine|contains: ' corp-archive:'
  condition: not selection

What an analyst reads, top to bottom:

status and modified. A stable rule, last changed on 2026-07-15, before the exception below was written (2026-09-01). A rule change after an exception or pattern entry was written is an invalidation trigger for both, so check the two dates before trusting either.
detection. The logic needs a binary named rclone.exe. A renamed copy escapes it. That is a blind spot to remember when the rule stays quiet on a host where you expected it to fire, not a reason to trust the quiet.
falsepositives. It points at the filter. Read the filter before you close anything as known noise.
filter, rules. The exception names this one rule by ID. A filter with rules: any applies to every rule on the log source, and is the first thing to question in an exception review.
filter, selection and condition. All three fields must match for not selection to remove an event: the service account, the pinned build (the tool version) and the archive remote. An alert that matches two of the three is exactly the case the exception was not written for, and it is real work. The remote name is a label from rclone’s configuration file, not a network destination, so the request that created this exception kept a separate egress rule on the job’s destinations. The exception is only as strong as its weakest field.
description. It carries the request and case IDs. Owner, approver and expiry live in the register, because the filter format has no fields for them.

Record what you read: the rule ID and version that fired, the exceptions active on it, and whether the event matched any of them in part. When the rule has an ADS record, four of its nine sections earn a look on shift: False Positives, Blind Spots and Assumptions, Validation, and Response (Palantir’s ADS framework). When the logic cannot be read at all, validate by the evidence instead, as reading a black-box alert describes.

How a request becomes a change

Keeping detections as code ( detection-as-code ) is what makes every step below possible. The flow most programs converge on:

Triage files the request after the case verdict, from the template.
Detection engineering decides within the agreed time: accepted, accepted with changes, or declined with a reason. A declined request with a reason is a good outcome; a silent one is not.
The change lands as code: a rule, filter or parser change in version control, reviewed by a second person in a pull request that links the request.
Automated tests run before merge: the rule still converts for each platform it ships to, the benign sample stops alerting, and the malicious sample (replayed events, or an emulation run) still fires.
It ships with a new version and a change notice. Triage hears about it, and closes against the pattern entries linked to the rule move to Level 1 until each entry’s owner re-verifies it.
Someone watches it for 30 days: volume, precision, and any closes reversed or detections missed. The request closes with that result written in.

A quiet rule is a finding

Every logic change, exception and parser fix risks silencing the malicious variant along with the noise. A rule that suddenly stops firing after a change is a finding to investigate, not a relief. The same goes for a rule with no fires at all over a long period and no recent validation test: it may be broken, or its telemetry may be gone.

A few numbers per rule are enough to tell broken logic from noisy-but-correct rules, and to tell whether the loop is working. Each comes from fields the templates already carry: the rule ID and version, the two verdict axes, and the request ID. Count per rule version, because a logic change starts a new series. The site-wide metric set, with denominators and gaming risks, belongs to Measuring triage; these are the ones detection engineering reads.

Number	Formula	How to read it
Precision	True-positive fires ÷ fires with a detection verdict (benign true positives count as correct)	Low precision is a logic or data defect: the first two routing rows
False-positive split	False positive (logic) fires ÷ fires, and false positive (data) fires ÷ fires	Which owner gets the work
Benign-true-positive share	Authorized and benign-confirmed fires ÷ fires	High with high precision: a healthy rule that needs context (a pattern entry, enrichment, an exception), not tuning
Actionability	Fires that needed action beyond the close ÷ fires	The share of the rule’s volume that changed anything
Undetermined share	Undetermined fires ÷ fires	High: the alert lacks the fields that decide it; an enrichment request
Exception inventory	Active exceptions per rule, their age, the number past expiry, hits per exception per period	Past expiry should be zero; zero hits retires an exception; a spike triggers review
Reversed closes	Level 0 closes on this rule later found wrong ÷ Level 0 closes on it	The pattern entries on this rule need review
Time to tune	Request filed → change deployed	The speed of the loop itself
Misses found	False negatives found by hunts, IR or Uncover gap requests, per technique	Coverage measured where it failed, not where a cell is colored

Coverage needs one more caveat. A colored cell on a MITRE ATT&CK heatmap means at least one analytic maps to the technique, not that its procedures are covered (see ATT&CK in Uncover). Since v18 (October 2025), each technique carries a Detection Strategy (a DET ID) with platform-specific Analytics (AN IDs). T1556, Modify Authentication Process, for example, lists DET0104 with analytics AN0287 to AN0291 for Windows, Linux, macOS, identity providers and cloud IAM (attack.mitre.org, checked October 2026). A new-detection request names the DET ID, so detection engineering can see which analytics already exist and which platform the gap sits on.

Key takeaway

Triage and detection engineering share one loop, and the verdict decides where each piece of it goes: logic defects to the rule owner, data defects to the pipeline, benign true positives to context, gaps to new detections, control gaps to IR. The tuning request carries it, with one rule, evidence by ID, the risk of the change and two tests. Exceptions are keyed to the context that makes the activity benign, expire, and get counted. And both teams read the same per-rule numbers, computed from the two verdict fields every close already records.

← Measuring triage Adopting ASSURED →

Technical details verified 2026-10-13. Product names, defaults and retention change; check your own tenant.

Edit this page on GitHub Report a correction