Detection Engineering
SIEM and detection rules — correlation, essential log sources, MITRE ATT&CK mapping, IOC vs IOA, the pyramid of pain, EDR vs AV, threat intelligence and tuning without blind spots.
13 questions
JuniorTheoryVery commonWhat are false positives and false negatives in alerting, and why is alert fatigue a security failure?
What are false positives and false negatives in alerting, and why is alert fatigue a security failure?
A false positive alerts on benign activity; a false negative is a real attack that never alerted. False-positive volume causes alert fatigue — analysts close the queue unread, so real detections get dismissed too. Noise thus becomes missed breaches, not lost hours.
Common mistakes
- ✗Swapping the definitions of false positive and false negative
- ✗Treating alert noise as an operations annoyance rather than a detection failure
- ✗Adding alerts to prove coverage while nobody reads the resulting queue
Follow-up questions
- →How would you measure whether a single rule is worth keeping?
- →What do you check before muting a rule so you do not create a blind spot?
JuniorTheoryVery commonHow do indicators of compromise (IOC) differ from indicators of attack (IOA) in detection?
How do indicators of compromise (IOC) differ from indicators of attack (IOA) in detection?
An IOC is a static artefact left behind — a file hash, an IP, a domain, a registry key — found after the fact. An IOA is a behaviour in progress, like a document spawning a shell. IOCs are precise but go stale fast; IOAs survive attacker retooling.
Common mistakes
- ✗Swapping the two — calling a file hash an indicator of attack
- ✗Building a detection strategy only on IOC feeds and never on behaviour
- ✗Assuming IOCs never expire, so stale hashes and IPs stay in the rules
Follow-up questions
- →Why does a hash-based detection expire faster than a behavioural one?
- →What telemetry do you need before an IOA rule is even writable?
JuniorTheoryCommonWhat does an EDR (endpoint detection and response) agent give a defender that signature antivirus does not?
What does an EDR (endpoint detection and response) agent give a defender that signature antivirus does not?
EDR continuously records endpoint behaviour — process trees, command lines, connections, file writes — and ships it for detection, hunting and response. Signature antivirus only matches known-bad files at scan time, so fileless and novel attacks pass it.
Common mistakes
- ✗Calling EDR just an antivirus with more signatures
- ✗Assuming a signature engine can catch fileless or living-off-the-land activity
- ✗Forgetting that EDR value comes from retained telemetry, not only from blocking
Follow-up questions
- →Which EDR fields matter most when triaging a suspicious process?
- →Why does retained EDR telemetry make threat hunting possible at all?
JuniorTheoryCommonIn a SIEM log-aggregation platform, what is a correlation rule and why does its time window matter?
In a SIEM log-aggregation platform, what is a correlation rule and why does its time window matter?
A correlation rule fires only when several events line up — 20 failed logons then one success for the same account. The time window defines what counts as one story: too narrow misses slow attacks, too wide joins unrelated noise into false alerts.
Common mistakes
- ✗Treating a correlation rule as a single-condition keyword match
- ✗Widening the window to catch more and then drowning in unrelated joins
- ✗Assuming a narrow window is always safer — slow attacks fall outside it
Follow-up questions
- →How would you pick a window for a slow password-spraying pattern?
- →What state must a SIEM hold to evaluate a multi-event rule at scale?
MiddleDebuggingCommonA proxy log shows one host calling the same domain every 60 seconds. Triage it and say what is happening.
A proxy log shows one host calling the same domain every 60 seconds. Triage it and say what is happening.
The near-constant interval with uniform tiny responses is machine periodicity, not human browsing, which is bursty. Confirm by pivoting to EDR for the process and its parent, check the domain's age and reputation, then isolate the host if the process is untrusted.
Open full question →Common mistakes
- ✗Reading a fixed interval as proof of a legitimate updater without checking the process
- ✗Trusting the user-agent string as evidence that a human was driving the traffic
- ✗Reaching a verdict from network logs alone, with no endpoint pivot
Follow-up questions
- →How would jitter in the interval change your detection approach?
- →Which EDR fields settle whether the calling process is legitimate?
MiddleTheoryCommonWhich telemetry signals point to data exfiltration or command-and-control beaconing?
Which telemetry signals point to data exfiltration or command-and-control beaconing?
In DNS, watch query volume, long random subdomains, high entropy. On egress, watch upload-heavy asymmetry and new destinations. For beaconing, watch near-fixed intervals with low jitter to one host. Baseline per user and asset; flat thresholds alert constantly.
Common mistakes
- ✗Relying on a flat byte threshold instead of a per-user or per-asset baseline
- ✗Trusting traffic just because it uses port 443 or port 53
- ✗Ignoring connection timing, so a low-and-slow beacon never stands out
Follow-up questions
- →How do you separate a beacon from a legitimate polling agent or update check?
- →Why does jitter in the interval make interval-based detection harder?
MiddleTheoryCommonWhich log sources are essential for detection, and what becomes invisible without each of them?
Which log sources are essential for detection, and what becomes invisible without each of them?
EDR gives process ancestry and command lines; authentication logs expose credential abuse and lateral movement; DNS and proxy logs reveal command-and-control and exfiltration; cloud audit logs record control-plane changes. Drop one and that class goes unseen.
Common mistakes
- ✗Assuming normalisation in the SIEM makes different sources interchangeable
- ✗Collecting network telemetry only and losing all process-level context
- ✗Skipping cloud audit logs, so control-plane changes leave no detectable trace
Follow-up questions
- →Which source would you onboard first with a limited ingest budget, and why?
- →How do you prove a source is actually flowing and not silently broken?
MiddleTheoryCommonIn the adversary-behaviour matrix MITRE ATT&CK, how do tactics differ from techniques, and why can a coverage percentage mislead?
In the adversary-behaviour matrix MITRE ATT&CK, how do tactics differ from techniques, and why can a coverage percentage mislead?
Tactics are the attacker's goals — persistence, exfiltration; techniques are the concrete ways to reach them. Mapping detections onto techniques exposes gaps, but a percentage misleads: one weak rule marks a technique covered, and techniques differ hugely in relevance.
Common mistakes
- ✗Inverting the hierarchy — treating techniques as the goals and tactics as the methods
- ✗Reporting a coverage percentage as if every technique mattered equally
- ✗Marking a technique covered when the rule behind it detects only one narrow variant
Follow-up questions
- →How would you weight techniques by relevance to your own sector?
- →What evidence proves a mapped technique is genuinely detected, not just claimed?
MiddleDebuggingCommonA brute-force alert fires 400 times a day and the SOC now auto-closes it. Diagnose it and tune the rule.
A brute-force alert fires 400 times a day and the SOC now auto-closes it. Diagnose it and tune the rule.
Failures are counted per source IP, and the VPN gateway NATs hundreds of users behind one address, so ordinary typos cross the threshold. Key the rule on account instead, and for shared egress alert on distinct accounts failing per IP — that keeps spraying visible.
Open full question →Common mistakes
- ✗Raising the threshold, which silences spraying instead of removing the noise
- ✗Blanket-excluding the gateway IP and losing all visibility behind it
- ✗Reading a shared NAT address as one attacking user
Follow-up questions
- →How would you prove the tuned rule still catches a slow spraying campaign?
- →What context would you enrich the alert with to speed up triage?
MiddleTheoryCommonWhat does the indicator-hierarchy model pyramid of pain say about hash and IP detections versus TTP detections?
What does the indicator-hierarchy model pyramid of pain say about hash and IP detections versus TTP detections?
It ranks indicators by what changing them costs the attacker. Hashes and IPs sit at the bottom — rotated in minutes, so detections on them expire fast. TTPs (tactics, techniques, procedures) sit on top — rebuilding tradecraft is expensive, so those detections last.
Common mistakes
- ✗Reading the pyramid as defender collection difficulty instead of attacker cost
- ✗Running a detection programme almost entirely on hash and IP feeds
- ✗Assuming a TTP-level rule is just a slower version of an indicator match
Follow-up questions
- →Which telemetry does a TTP-level detection need that a hash match does not?
- →How would you justify the cost of behavioural rules over a cheap IOC feed?
MiddleTheoryOccasionalHow do strategic, operational and tactical threat intelligence differ, and why must IOC feeds be aged out?
How do strategic, operational and tactical threat intelligence differ, and why must IOC feeds be aged out?
Strategic intel informs risk decisions, operational describes campaigns and actors, tactical ships machine-readable IOCs. Tactical decays fastest — addresses get reassigned, domains sinkholed — so unaged indicators alert on innocents and need expiry and source scoring.
Common mistakes
- ✗Swapping the tiers — calling an IOC feed strategic intelligence
- ✗Loading an indicator feed into blocking rules with no expiry policy
- ✗Treating every feed as equally trustworthy instead of scoring it by source
Follow-up questions
- →What expiry policy would you set for domain versus hash indicators?
- →How do you measure whether a paid feed earns its place in your pipeline?
SeniorTheoryOccasionalHow do you find genuine detection-coverage gaps and validate them through purple-team exercises?
How do you find genuine detection-coverage gaps and validate them through purple-team exercises?
Start from telemetry, not the matrix — a technique is only detectable if the data exists. Rank techniques by intel relevance to your sector, then execute them safely together and record what alerted, what only logged, and what was silent. Fix the silent ones first.
Common mistakes
- ✗Treating the ATT&CK matrix as the starting point instead of available telemetry
- ✗Accepting a vendor coverage claim without validating it in your own environment
- ✗Running the exercise as a red-versus-blue scoreboard rather than a shared measurement
Follow-up questions
- →How do you prioritise which silent techniques get a detection first?
- →What do you change when a technique alerts but the alert is unactionable?
SeniorDesignOccasionalYou own detection for a 3,000-person company: 4,000 Windows endpoints with EDR, Active Directory, an on-prem proxy and DNS resolver, and two AWS accounts. The SIEM budget covers about 300 GB/day, but the pipeline already ingests 450 GB/day — mostly verbose Windows events and proxy allow-lines. Detection must keep covering credential abuse, lateral movement, command-and-control beaconing and cloud control-plane changes, and analysts must be able to hunt over 12 months of history. Compliance requires one year of retention for authentication and cloud audit records. Design the pipeline: what you keep at full fidelity, what you filter or aggregate at the edge, what you route to cheap storage instead of the SIEM, and how you prove afterwards that no detection quietly lost its source.
You own detection for a 3,000-person company: 4,000 Windows endpoints with EDR, Active Directory, an on-prem proxy and DNS resolver, and two AWS accounts. The SIEM budget covers about 300 GB/day, but the pipeline already ingests 450 GB/day — mostly verbose Windows events and proxy allow-lines. Detection must keep covering credential abuse, lateral movement, command-and-control beaconing and cloud control-plane changes, and analysts must be able to hunt over 12 months of history. Compliance requires one year of retention for authentication and cloud audit records. Design the pipeline: what you keep at full fidelity, what you filter or aggregate at the edge, what you route to cheap storage instead of the SIEM, and how you prove afterwards that no detection quietly lost its source.
Tier by detection value, not volume. EDR process events, authentication, DNS, proxy and cloud audit stay hot in the SIEM; verbose Windows noise and proxy allow-lines are filtered at the edge, raw data archived cheaply for hunting. Map rules to source fields and monitor source health.
Common mistakes
- ✗Uniform sampling across sources, which quietly breaks multi-event correlation
- ✗Cutting a source by raw volume rather than by its detection value
- ✗Filtering with no rule-to-source mapping, so a lost field silences a rule invisibly
Follow-up questions
- →How would you detect that a source stopped flowing after a log-format change?
- →Which events would you keep hot even though they are individually rare?
