Detection engineering
Build and test signals that lead to useful investigations.
Turn a behavior into a useful signal
Detection engineering designs, tests, deploys, and maintains logic that identifies security-relevant activity. A useful detection does more than match suspicious text: it starts an investigation the organization can perform with the available evidence and a clear response owner.
Begin with a behavior and a reason it matters. For example, a mailbox forwarding change following an unusual authentication event may indicate account abuse. The engineering question is which records capture those actions, how they can be connected reliably, and which legitimate workflows might produce the same sequence.
Write the investigation before the rule
In a fictional academy, staff occasionally forward messages to approved shared mailboxes. A rule that alerts on every forwarding change creates avoidable noise. A narrower design considers the destination's relationship to the organization, the identity making the change, recent account activity, and approved business exceptions.
The analyst receiving the alert needs the affected mailbox, destination, creator, event time, and relevant authentication evidence. If the detection produces only a count and a severity label, someone must repeat the original searches before making a decision.
Write a short triage guide while implementing the rule. Explain its intended behavior, prerequisites, known blind spots, and escalation conditions. This connects detection development with Alert triage instead of treating alert delivery as the final outcome.
Test positive and negative cases
Use authorized simulations or prepared test records representing both suspicious and legitimate activity. Verify that the logic finds the intended sequence and handles time windows, delayed ingestion, duplicate events, and missing fields appropriately. Tests should reflect actual source schemas rather than an idealized example that the production data cannot satisfy.
A passing test demonstrates behavior under those conditions. It does not establish universal coverage of the corresponding MITRE ATT&CK technique. Different platforms, event settings, or adversary procedures may require different evidence and logic.
Measure what happens after deployment. Review alert volume, investigation outcomes, analyst effort, and missed cases discovered through other routes. Tuning should reduce unnecessary work while preserving the behavior the rule exists to find; suppressing everything noisy is not a security improvement.
Maintain the dependency chain
Rules depend on sensors, permissions, event schemas, enrichment sources, and operational processes. A source change can silently break a useful detection even when the rule syntax remains valid. Monitor ingestion and field quality, and assign ownership for periodic review.
For a practical exercise, specify a detection for an unexpected privileged account creation. List required events, a legitimate provisioning example, an abuse example, and the first three analyst questions. Then remove the creator field from the test data. Explain what confidence the rule can still support and what additional source is needed.
Related concepts
References & further reading
Original explanations, with primary references for deeper study.
NIST: Incident Response Recommendations, SP 800-61 Rev. 3