Lesson 85 — The Detection Fired 600 Times a Day
The detection was finding the right behaviour.
But it fired 600 times yesterday.
Agent Foskett looked at the queue.
“Are these 600 investigations... or the same story repeated 600 times?”
Count investigations, not just events.
Repeated matching activity may represent one continuing security story rather than hundreds of independent cases.
Case briefing
Investigation objective
Measure the operational workload created by a high-volume detection and determine whether repeated matching events can be grouped into fewer, more meaningful investigation units.
Investigator's rule
Alert volume is not the same thing as incident volume — but careless grouping can hide separate attacks.
Stage 1 — measure before tuning
| Metric | What it tells you |
|---|---|
| Raw matches | How often the logic matched telemetry |
| Alerts generated | How often the detection created SOC work |
| Unique devices | How widely the behaviour occurred |
| Unique accounts | How many identities were involved |
| Repeated entities | Whether a small population dominates volume |
| Investigation groups | How many distinct stories analysts may actually need to assess |
600 is only the beginning
The number tells you the queue is busy. It does not explain whether the detection found 600 unrelated behaviours, 60 repeated bursts or one badly fragmented incident.
Do not tune from frustration
A large alert count creates pressure to suppress the rule. First establish where the volume comes from and whether repeated alerts share meaningful context.
Stage 2 — measure concentration
DeviceProcessEvents
| where Timestamp > ago(1d)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| summarize EventCount=count()
by DeviceId, DeviceName, AccountName,
bin(Timestamp, 5m)
| where EventCount > 10
| summarize Matches=count(),
Peak=max(EventCount)
by DeviceId, DeviceName, AccountName
| order by Matches descFind the heavy contributors
If a handful of device-account combinations produce most matches, the problem may be repeated alert creation rather than broad environmental prevalence.
Concentration changes the question
Instead of “why are there 600 alerts?”, ask “why are these seven devices repeatedly producing the same detection outcome?”
Stage 3 — map the repeated story
Group on meaningful dimensions
Useful grouping may include device, account, process lineage, detection reason and time proximity. The right keys depend on what the detection is trying to represent.
Time matters
Repeated activity seconds apart may belong together. Similar behaviour eight hours later may represent a new execution and deserve separate attention.
Stage 4 — define an investigation unit
| Possible grouping | Risk |
|---|---|
| Same device only | Different users or unrelated activity may be merged |
| Same account only | Activity across many devices may represent wider compromise |
| Same device + account | Better context, but distinct process chains may still differ |
| Device + account + behaviour + time window | More precise, but grouping logic becomes more complex |
Grouping is part of detection design
The detection should help the analyst see a coherent story. If every telemetry event becomes a separate task, the engineering layer may be pushing unnecessary correlation work onto the SOC.
But do not over-group
Combining unrelated activity can hide scope, recurrence or multiple affected entities. Group only when the shared context supports the same investigation.
Stage 5 — estimate analyst workload
Convert volume into time
Alert counts become operationally meaningful when translated into analyst effort. Use your SOC's actual triage data where available rather than assuming every alert takes the same time.
Workload is a security metric
A rule that consumes excessive analyst attention can reduce the team's ability to investigate other threats. Operational cost belongs in detection evaluation.
Stage 6 — preserve the evidence inside the group
| Do not lose | Why it matters |
|---|---|
| First seen / last seen | Shows duration of the activity |
| Total match count | Preserves intensity |
| Devices and accounts | Preserves scope |
| Process details | Supports behavioural investigation |
| Command-line variation | May distinguish repeated automation from evolving attack activity |
| External destinations or related entities | Can expose expansion of the incident |
Grouping should compress work, not evidence
The analyst should receive one coherent investigation with the important repeated observations attached — not one alert with all repetition silently discarded.
Frequency can itself be evidence
Repeated execution may increase confidence or severity. Do not remove the fact that an event happened 40 times merely because it is presented as one investigation.
Stage 7 — distinguish grouping from suppression
Suppression needs caution
Suppressing repeated alerts may be appropriate in some designs, but it can also create blind periods. Understand what happens to new evidence while suppression is active.
Grouping is often safer
Where supported, grouping can reduce repeated analyst work while retaining the fact that additional matching activity continued to occur.
Stage 8 — test the grouping boundaries
| Scenario | Same investigation? |
|---|---|
| Same device, account and process within two minutes | Likely candidate for grouping |
| Same device, different account | Review — may change scope |
| Same account, second device | Review — lateral movement or broader compromise possible |
| Same behaviour six hours later | May represent recurrence and deserve a new investigation |
| Same device but different process chain | Do not assume it is the same story |
Test edge cases
Good grouping logic needs examples that should combine and examples that must remain separate. Otherwise the rule may look efficient while hiding important distinctions.
Measure after the change
Recalculate daily investigation volume, analyst effort and malicious coverage after grouping is introduced. The improvement should be observable.
Stage 9 — write the operational finding
The detection was not necessarily noisy
It may have been repeatedly reporting valid behaviour at the wrong operational granularity.
The analyst queue is part of the system
Detection engineering does not end when a condition matches. The way matches become analyst work determines whether the detection is usable at scale.
Stage 10 — make the engineering decision
Efficiency must not become blindness
The objective is not to make the dashboard look quiet. It is to reduce redundant work while keeping meaningful attack evidence visible.
Detection volume needs an owner
Someone should monitor how much work the rule creates after deployment and revisit the design when volume, environment or attack behaviour changes.
Lesson 85 key takeaways
- Alert volume is not automatically incident volume.
- Measure where high-volume detection activity actually comes from.
- Count unique entities and repeated contributors, not only total alerts.
- Translate detection volume into analyst workload.
- Group repeated activity only when the evidence supports one investigation story.
- Device, account, behaviour and time are useful grouping dimensions.
- Do not over-group unrelated activity.
- Preserve first seen, last seen, match count, scope and important variation.
- Grouping, suppression and detection tuning are different engineering decisions.
- Frequency may itself be important security evidence.
- Test grouping boundaries with cases that should and should not combine.
- Measure workload and coverage again after the change.
- The goal is less redundant analyst work — not simply fewer alerts.
Module 9 — Detection Engineering: Turning Findings into Protection
Lesson 85 measured the analyst workload created by repeated detection activity and used grouping to reduce redundant work without discarding evidence. Lesson 86 will examine the opposite danger: tuning the threshold so aggressively that a real attack disappears.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 9: Detection Engineering: Turning Findings into Protection
How do you reduce repeated security alerts without losing detection coverage?
Lesson 85 of the Agent Foskett SOC Analyst Academy teaches analysts how to measure high-volume detection workload, identify repeated entities and group related activity into meaningful investigation units while preserving security evidence.
Managing detection alert volume in a SOC
Learn the difference between raw matches, alerts, investigation groups, suppression and tuning, and how detection engineering can reduce redundant analyst work without making genuine attack activity invisible.
