Lesson 89 — Can Another Analyst Explain Why This Alert Fired?
The alert was technically correct.
But the analyst could not explain it.
The query was complicated. The evidence was buried.
Agent Foskett asked a simple question: why did this alert fire?
Detection logic should tell a security story.
The analyst needs to understand the behaviour, evidence and reason the alert matters.
Case briefing
Investigation objective
Evaluate whether a detection clearly communicates its security hypothesis, triggering evidence and investigative context so another analyst can understand and act on the alert without reverse-engineering the rule.
Investigator's rule
A detection is not fully operational until another analyst can explain why it fired.
Stage 1 — separate the query from the explanation
| The query answers | The analyst needs to know |
|---|---|
| Which records matched? | What suspicious behaviour occurred? |
| Which conditions evaluated true? | Why is that behaviour security-relevant? |
| Which fields were filtered? | Which evidence caused this specific alert? |
| How data was transformed? | What should I investigate next? |
Correct logic can still be opaque
A sophisticated query may detect excellent behaviour while producing an alert that gives the SOC almost no explanation. Detection quality includes what happens after the match.
The analyst should not need the source code first
Opening the query can be useful, but it should not be the only way to understand the alert's basic security story.
Stage 2 — state the security hypothesis
Start with behaviour
The explanation should describe the security behaviour being detected rather than simply restating the rule name or ATT&CK technique.
Explain the risk
Why is this process chain, identity action or cloud event unusual enough to deserve investigation? That reasoning belongs with the detection.
Stage 3 — expose the triggering evidence
DeviceProcessEvents
| where Timestamp > ago(1h)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where InitiatingProcessFileName in~ (
"msedge.exe", "chrome.exe", "firefox.exe"
)
| project Timestamp,
DeviceName,
AccountName,
InitiatingProcessFileName,
FileName,
ProcessCommandLineReturn fields the analyst can use
A match count alone may prove the rule executed, but the analyst usually needs entities, timestamps, process ancestry, command lines, IPs, URLs or other evidence appropriate to the behaviour.
Evidence should support the hypothesis
Every surfaced field should help explain the behaviour, establish scope or provide an investigative pivot. More columns are not automatically more useful.
Stage 4 — make the alert tell the story
| Alert element | Useful content |
|---|---|
| Title | Specific behaviour, not generic suspicion |
| Description | Security hypothesis and why it matters |
| Entities | Device, account, IP, application or resource involved |
| Evidence | The values that caused the detection to match |
| Time context | When the behaviour occurred and over what window |
| Investigation guidance | Useful first pivots and validation questions |
Names matter
“Suspicious Activity Detected” tells the analyst almost nothing. A title such as “Browser Spawned PowerShell with Suspicious Command Line” communicates the first investigative hypothesis immediately.
Descriptions should add meaning
A description should not simply repeat the title in a longer sentence. Explain why the behaviour may indicate malicious activity.
Stage 5 — test explainability with another analyst
The handover test is powerful
The detection engineer already knows what the rule means. A second analyst exposes assumptions that were obvious to the author but invisible to everyone else.
Do not explain away bad logic
Documentation cannot rescue a detection whose conditions are inconsistent or poorly justified. Explainability begins with coherent detection logic.
Stage 6 — make complex logic traceable
DeviceProcessEvents
| where Timestamp > ago(1h)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| extend BrowserParent =
InitiatingProcessFileName in~ (
"msedge.exe", "chrome.exe", "firefox.exe"
)
| where BrowserParent
| extend DetectionReason =
"Browser process launched PowerShell"
| project Timestamp, DeviceName, AccountName,
ProcessCommandLine, DetectionReasonLabel meaningful conditions
Where appropriate, derived fields can help identify which branch, condition or behavioural feature caused a record to qualify. This is especially useful as detection logic becomes more complex.
Keep the reason human-readable
The explanation should describe observable behaviour. Avoid internal labels that only make sense to the person who wrote the query.
Stage 7 — distinguish confidence from severity
| Concept | Question |
|---|---|
| Detection confidence | How strongly does the evidence support the hypothesis? |
| Potential impact | How damaging could this behaviour be? |
| Entity importance | Does it involve a privileged account or critical system? |
| Alert severity | How urgently should the SOC prioritise the resulting investigation? |
Explain why severity is justified
If a rule produces a high-severity alert, the analyst should be able to understand what evidence or context makes the situation high priority.
Do not hide uncertainty
Some detections are intentionally broad leads. That is acceptable when the alert clearly communicates that further validation is required.
Stage 8 — provide useful investigation pivots
Guidance should be specific
“Investigate the device” is weak guidance. Point analysts toward the evidence most likely to confirm or reject the detection hypothesis.
Do not prescribe the verdict
An alert description should help the analyst investigate, not tell them to assume compromise before the evidence supports it.
Stage 9 — document the detection for future analysts
| Detection record | What to capture |
|---|---|
| Purpose | The security behaviour and hypothesis |
| Data dependency | Required telemetry and relevant fields |
| Trigger logic | What conditions create a match |
| Known benign patterns | Expected sources of legitimate overlap |
| Validation | Historical and malicious cases used for testing |
| Investigation guidance | Recommended pivots and context |
| Owner / review | Who maintains it and when it should be reviewed |
Explainability helps maintenance too
Six months later, the detection engineer may not remember why a condition was added. Good documentation protects the reasoning behind the rule.
Future tuning becomes safer
When assumptions and triggering conditions are clear, another engineer can change the rule without accidentally deleting an important part of the security hypothesis.
Stage 10 — write the analyst-facing finding
Explainability creates trust
Analysts are more likely to use a detection effectively when they can see why it fired and connect the evidence to a defensible security hypothesis.
It also exposes weak detections
If the detection engineer cannot clearly explain why the behaviour matters, that may reveal that the hypothesis itself needs more work.
Lesson 89 key takeaways
- A technically correct detection can still be operationally opaque.
- Another analyst should be able to explain why an alert fired.
- Start with a clear security hypothesis expressed as behaviour.
- Explain why the behaviour is security-relevant.
- Surface the evidence that caused the alert to match.
- Return useful investigative entities and context.
- Alert titles should communicate the detected behaviour.
- Descriptions should explain meaning rather than repeat the title.
- Use another analyst to test whether the alert is understandable.
- Complex logic should remain traceable to human-readable reasons.
- Severity, confidence and potential impact are related but distinct.
- Investigation guidance should provide useful pivots without prescribing a verdict.
- Documentation preserves the reasoning behind the detection.
- Explainability improves triage, trust, maintenance and future tuning.
Module 9 — Detection Engineering: Turning Findings into Protection
Lesson 89 made the detection understandable to the analyst who receives it. Lesson 90 brings the whole module together by taking a successful hunt all the way through testing, deployment, monitoring and production ownership.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 9: Detection Engineering: Turning Findings into Protection
What makes a security detection explainable?
Lesson 89 of the Agent Foskett SOC Analyst Academy teaches analysts and detection engineers how to build transparent security detections that clearly communicate the security hypothesis, triggering evidence, entities and investigation context.
Building analyst-friendly security alerts
Learn how alert titles, descriptions, evidence, detection reasons, severity context and investigation guidance help SOC analysts understand why an alert fired and make defensible decisions.
