Lesson 87 — The Detection Duplicated Another Rule
The new detection worked.
So did another rule already in production.
Both were creating alerts for the same behaviour.
Agent Foskett had a new question: which one should stay?
Overlap is not automatically redundancy.
Two rules can alert on similar activity while protecting different parts of the attack story.
Case briefing
Investigation objective
Determine whether two detections are genuinely redundant, partially overlapping or independently valuable, then reduce duplicate analyst work without removing meaningful coverage.
Investigator's rule
Do not delete a detection because the alerts look similar. Compare the security coverage first.
Stage 1 — describe both security hypotheses
| Detection | Security hypothesis |
|---|---|
| Rule A | A browser launching PowerShell may indicate malicious script execution originating from web content. |
| Rule B | PowerShell performing suspicious child-process activity may indicate post-exploitation execution. |
Similar alerts can represent different ideas
Both rules may fire on the same incident, but one begins with browser ancestry while the other focuses on suspicious PowerShell behaviour. The overlap is real, but the hypotheses are not identical.
Start with intent, not query text
Two queries can look different and still detect the same behaviour. Two similar queries can also protect different attack paths. Compare what each rule is designed to detect.
Stage 2 — measure real production overlap
AlertInfo
| where Timestamp > ago(30d)
| where Title in (
"Browser Spawned PowerShell",
"Suspicious PowerShell Execution"
)
| summarize Alerts=count() by Title
| order by Alerts descVolume alone does not prove duplication
If both rules generate similar counts, they may still be detecting different populations. The next step is to compare which entities and incidents overlap.
Use the alert platform carefully
Field availability can vary by product and data source. The principle is to compare alert populations, affected entities, timing and incident correlation using the telemetry your environment actually exposes.
Stage 3 — classify the overlap
| Pattern | Meaning |
|---|---|
| Nearly all Rule A alerts also trigger Rule B | Strong candidate for redundancy review |
| Only some alerts overlap | Partial coverage overlap |
| Different devices or techniques dominate | Likely distinct operational value |
| Same incident, different attack stages | Potentially complementary detections |
Duplicate does not mean identical
Rules can create redundant analyst work even when their logic differs. If they repeatedly produce separate alerts for the same security story, the operational effect may still be duplication.
Complementary overlap can be useful
Independent signals can strengthen confidence, enrich an incident or provide resilience if one telemetry source fails. The question is whether analysts benefit from both signals as separate work items.
Stage 4 — compare unique coverage
Unique matches deserve investigation
Before retiring either rule, review examples that only one detection found. Those cases reveal the coverage you may lose.
Look for systematic differences
Unique coverage may come from different process ancestry, device types, account context, telemetry availability or attack stages. Those differences should be understood, not averaged away.
Stage 5 — test known malicious cases
| Historical case | Rule A | Rule B |
|---|---|---|
| Phishing → browser → PowerShell | Match | Match |
| Script launched from Office | No match | Match |
| Browser launched benign admin shell | Match | No match |
| PowerShell post-exploitation chain | No match | Match |
The broader rule may not be the better rule
A rule that matches more cases can also produce more noise. Coverage must be compared with precision, explainability and operational value.
The narrower rule may still matter
A focused detection can provide clearer context, faster triage or stronger confidence even if another rule technically detects the same attack later.
Stage 6 — compare analyst experience
| Question | Why it matters |
|---|---|
| Do both alerts land in the same incident? | May reduce duplicate case creation already |
| Do analysts investigate both separately? | Direct workload duplication |
| Does one rule provide better context? | May justify keeping it as primary |
| Does one alert consistently arrive earlier? | May improve response time |
| Does one rule depend on a fragile data source? | Redundant coverage may provide resilience |
Coverage is only one dimension
Detection engineering also includes clarity, speed, maintainability, data reliability and the amount of analyst work each rule creates.
Ask the SOC
If analysts consistently close one alert after discovering the other already explains the incident, that is strong operational evidence that duplication exists.
Stage 7 — choose a consolidation strategy
Retirement is the highest-risk option
Deleting a rule is easy. Proving that nothing important disappears is harder. Treat detection retirement as a controlled security change.
Merging can improve the story
Where compatible, a single detection or incident representation may preserve multiple supporting signals while giving the analyst one coherent investigation.
Stage 8 — validate the chosen design
DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| extend BrowserParent =
InitiatingProcessFileName in~ (
"msedge.exe", "chrome.exe", "firefox.exe"
)
| summarize Events=count(),
BrowserInitiated=countif(BrowserParent)
by DeviceId, DeviceName, AccountNameRetest unique cases
Every historical case previously found by the retiring or modified rule should be checked against the proposed replacement logic where practical.
Backtest the workload too
The new design should reduce redundant analyst work without unexpectedly creating a new volume problem or losing important context.
Stage 9 — document the coverage decision
Document what replaces the retired coverage
The record should make it clear which remaining detection protects the behaviour, what unique logic was preserved and what testing justified the decision.
Include rollback criteria
If post-change monitoring reveals missed cases or degraded context, the team should know how to restore the previous design quickly.
Stage 10 — monitor after consolidation
Redundancy can return
Detection libraries evolve. New vendor rules, custom analytics and changed logic can create fresh overlap later. Periodic coverage review is part of detection maintenance.
One good alert can be better than two mediocre ones
The objective is not to maximise the number of detections. It is to provide reliable coverage and useful analyst decisions.
Lesson 87 key takeaways
- Similar alerts do not automatically mean duplicate security coverage.
- Compare the security hypothesis behind each rule first.
- Measure production overlap using entities, timing and incident context.
- Review cases that only one detection found.
- Partial overlap may represent complementary coverage.
- Independent signals can add confidence or resilience.
- Duplicate analyst work is an operational detection-engineering problem.
- Compare coverage, precision, speed, explainability and maintainability.
- Retiring a detection is a controlled security change.
- Retest known malicious and unique historical cases before retirement.
- Merging logic or changing alert presentation may be safer than deleting coverage.
- Document the replacement coverage and rollback criteria.
- Monitor for gaps after consolidation.
Module 9 — Detection Engineering: Turning Findings into Protection
Lesson 87 compared overlapping detections and reduced redundant analyst work without assuming that similar alerts meant identical coverage. Lesson 88 moves into detection maintenance: what happens when the environment changes after the rule has already been deployed?
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 9: Detection Engineering: Turning Findings into Protection
How do you handle duplicate security detection rules?
Lesson 87 of the Agent Foskett SOC Analyst Academy teaches analysts how to compare overlapping detection rules, identify unique coverage and reduce duplicate SOC analyst work without creating security gaps.
Detection overlap and rule consolidation
Learn how to compare detection hypotheses, production overlap, unique historical cases, analyst workload and rollback requirements before merging or retiring redundant security detections.
