Lesson 90 — From Hunt to Production Detection
The hunt found something real.
The behaviour was repeatable.
The evidence was strong.
Now it had to become protection.
A hunt is evidence. A detection is an operational control.
The journey from one to the other requires testing, tuning, explanation, ownership and monitoring.
Case briefing
Investigation objective
Take a validated threat-hunting finding through the complete detection-engineering lifecycle: hypothesis, telemetry, logic, baseline, backtesting, tuning, explainability, deployment, monitoring and ownership.
Investigator's rule
Do not productionise the hunt query. Productionise the security hypothesis.
Stage 1 — extract the security hypothesis
The hunt query was built to investigate
It may contain temporary filters, known IOCs, analyst pivots or case-specific values. Those helped answer the hunt question but may not belong in a reusable detection.
The hypothesis should survive changing IOCs
Where possible, preserve repeatable attacker behaviour rather than tying the rule only to the domain, hash or IP from the original case.
Stage 2 — identify the minimum telemetry
| Requirement | Telemetry needed |
|---|---|
| Browser ancestry | Process creation telemetry |
| PowerShell execution | Process name and command line |
| User and device context | Account and device identifiers |
| Follow-on activity | Network, file or additional process telemetry where required |
| Production reliability | Consistent data-source availability |
Detection begins with observable evidence
A strong hypothesis cannot become a reliable detection if the required telemetry is missing, inconsistent or delayed beyond the intended response window.
Know the dependency
Document which data source and fields the rule relies on. Later, telemetry health becomes part of detection health.
Stage 3 — build the first candidate
DeviceProcessEvents
| where Timestamp > ago(1h)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where InitiatingProcessFileName in~ (
"msedge.exe", "chrome.exe", "firefox.exe"
)
| project Timestamp,
DeviceId,
DeviceName,
AccountName,
InitiatingProcessFileName,
ProcessCommandLineKeep the first candidate understandable
Start with the smallest logic that expresses the behaviour. Complexity should be added because evidence requires it, not because sophisticated queries look impressive.
Do not tune yet
Before adding exclusions, thresholds or allowlists, learn how the behaviour actually appears across the environment.
Stage 4 — build the baseline
DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where InitiatingProcessFileName in~ (
"msedge.exe", "chrome.exe", "firefox.exe"
)
| summarize Events=count(),
FirstSeen=min(Timestamp),
LastSeen=max(Timestamp)
by DeviceId, DeviceName, AccountName
| order by Events descAsk what normal looks like
Which devices generate the behaviour? Which accounts? Is it rare, concentrated, seasonal or associated with a known workflow?
The baseline informs engineering
It may justify contextual filtering, segmentation or a threshold. It should not automatically become an exclusion list.
Stage 5 — backtest against history
| Backtest question | What it tells you |
|---|---|
| How many matches occur? | Expected detection volume |
| How concentrated are the matches? | Whether a small population drives noise |
| Does the original malicious case match? | Positive control coverage |
| Do other known malicious cases match? | Generalisability |
| What benign cases dominate? | Tuning opportunities |
The original attack is a positive control
If the production candidate cannot reproduce the behaviour that justified its creation, stop and understand why before proceeding.
One attack is not enough
Where possible, test multiple known examples so the detection does not become an overfit reconstruction of one incident.
Stage 6 — tune without deleting the hypothesis
Every tuning change has a cost
An exclusion, threshold or suppression decision can reduce analyst workload while also creating a blind spot. Measure both sides.
Search the boundary
Review behaviour close to thresholds and inside exclusions. False negatives do not generate tickets complaining about themselves.
Stage 7 — check for duplicate coverage
| Question | Decision value |
|---|---|
| Does another rule detect the same hypothesis? | Possible redundancy |
| Do both rules fire on the same incidents? | Possible duplicate analyst work |
| Does either rule have unique coverage? | Reason to preserve both |
| Could one alert preserve both signals? | Consolidation opportunity |
New does not automatically mean additional protection
Before deploying another alert, understand what existing detections already cover and whether the new rule adds unique value.
Reduce duplicate work, not useful resilience
Overlapping signals may still be valuable when they detect different attack stages or rely on independent telemetry.
Stage 8 — make the alert explainable
The SOC receives an alert, not your design session
The production output must carry enough context for another analyst to understand the behaviour and begin investigating.
Test with another analyst
Give them the alert without explaining the query. Can they say what happened, why it matters and what they would check next?
Stage 9 — define production ownership
| Production requirement | Decision |
|---|---|
| Owner | Who maintains the detection? |
| Severity | How should the SOC prioritise it? |
| Response | What investigation path should follow? |
| Data dependency | What telemetry must remain healthy? |
| Review cadence | When should assumptions be revisited? |
| Rollback | How can a harmful change be reversed? |
Production needs an owner
A detection without ownership can slowly become stale, noisy or misleading while everyone assumes somebody else is maintaining it.
Define success before deployment
Expected volume, acceptable false-positive patterns, known attack coverage and analyst workflow should be understood before the rule enters production.
Stage 10 — deploy, observe and measure
Watch the first production period closely
Historical backtesting cannot reproduce every operational condition. Early production observation validates how the rule behaves with real SOC workflows.
Measure analyst outcomes
How often is the alert actionable? What verdicts are analysts reaching? Are multiple alerts representing one investigation? Those results feed the next engineering cycle.
Stage 11 — monitor for drift
DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where InitiatingProcessFileName in~ (
"msedge.exe", "chrome.exe", "firefox.exe"
)
| summarize Events=count(),
Devices=dcount(DeviceId)
by bin(Timestamp, 1d)
| order by Timestamp ascThe environment will change
New software, workflows, devices and identities can change what the detection sees even when the query itself remains untouched.
Revisit assumptions, not just thresholds
If the environment changes significantly, the original distinguishing behaviour may need to be re-evaluated rather than merely tuned around the new noise.
Stage 12 — preserve the engineering record
The reasoning matters as much as the query
Future analysts need to know why the detection exists, what evidence justified its design and which assumptions must remain true.
This makes future changes safer
When the environment drifts or new detections overlap, the team can revisit evidence rather than guessing what the original engineer intended.
The complete detection-engineering lifecycle
The hunt found the opportunity
Detection engineering turns that opportunity into repeatable protection for the next analyst, the next device and the next incident.
The lifecycle never really closes
Production feedback, environment changes and new attacker behaviour send the detection back through testing and refinement. Good detections are maintained, not merely created.
Lesson 90 key takeaways
- Do not simply convert a threat-hunt query into a production alert.
- Extract and preserve the underlying security hypothesis.
- Confirm the telemetry required to observe the behaviour reliably.
- Build the simplest candidate that expresses the hypothesis.
- Baseline the behaviour before tuning.
- Backtest against historical telemetry and known malicious cases.
- Tune noise without deleting meaningful attack coverage.
- Review existing detections before creating duplicate analyst work.
- Make the alert understandable to analysts who did not build it.
- Define ownership, severity, response expectations and data dependencies.
- Observe production behaviour and analyst outcomes after deployment.
- Monitor environmental and telemetry drift.
- Preserve the reasoning, assumptions and validation evidence.
- Detection engineering is a continuous lifecycle from finding to protection.
Module 9 complete — Detection Engineering: Turning Findings into Protection
You have taken investigation findings and threat-hunting evidence through the full detection-engineering lifecycle: choosing what deserves detection, tuning false positives, building baselines, backtesting, managing alert volume, protecting against false negatives, reviewing duplicate coverage, monitoring drift and building explainable alerts.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 9: Detection Engineering: Turning Findings into Protection
How do you turn a threat hunt into a production detection?
Lesson 90 of the Agent Foskett SOC Analyst Academy completes the detection-engineering lifecycle by taking a validated threat-hunting finding through security hypothesis development, telemetry validation, baselining, backtesting, tuning, deployment and ongoing monitoring.
Production detection engineering lifecycle
Learn how to preserve attack coverage, reduce false positives and duplicate analyst work, create explainable alerts, assign detection ownership and monitor production rules for environmental and telemetry drift.
