The Beacon Nobody Saw
Your SIEM has been live 90 days and produces 4,200 alerts per day for three analysts; mean time to acknowledge is 9 hours. A post-incident review of a confirmed intrusion finds the C2 beacon, HTTPS POSTs every 300 seconds to a domain registered six days earlier, was present in the proxy logs the whole time, buried among 1,100 daily alerts from one rule that fires on 'uncategorized site'. You also find DNS logs stopped arriving 11 days before the review: the log forwarder's client certificate expired and the pipeline failed silently. The beaconing host had EDR installed, but the malware used a signed binary and made no suspicious API calls. Executives want fewer alerts; the SOC wants more detections. New tooling budget is a quarter away.
1. What do you fix first, and what do you deliberately not delete?
Read the worked answer
Fix the silence before the noise.
- Telemetry integrity first. DNS was dark for 11 days and nothing told you. That is a bigger failure than 1,100 noisy alerts, because it means every conclusion drawn from the SIEM in that period is unsound. Add heartbeat and freshness monitoring per log source, alert on source silence, and put certificate expiry on the monitoring calendar.
- Then the noisy rule, by tuning rather than deletion. Uncategorized-site traffic from a developer fleet may be legitimate; aggregate per host and per destination, enrich with domain age and reputation, and downgrade to a low-priority queue. Deleting it removes real coverage and you lose the ability to measure the change.
- Then the missing detection. Periodicity to a newly registered domain is a behaviour, not a signature; it needs an analytic, not a new log rule.
- Measure precision before and after so the reduction is defensible.
The root causes are rule design, missing enrichment, and no health monitoring; a new tool purchased next quarter fixes none of them on its own.
2. What analytic would catch this beacon, and how would you validate it before trusting it?
Read the worked answer
Design: behavioural periodicity, not domain blocklists.
Beacon math: 300-second interval, small and consistent byte counts, one destination, rare across the fleet. Encode it as:
- Regularity of inter-arrival times per source/destination pair over several hours, tolerant of the jitter the implant introduces.
- Destination domain age under 30 days, and rarity of that destination across all hosts.
- Low and consistent request and response sizes; long session duration with few bytes.
- Combine with DNS presence where available, which is why the pipeline fix in the previous task matters.
Validation: replay the actual beacon in a lab against the analytic, then run it against a week of production data and hand-review every hit. Expect it to be noisy on software updaters, telemetry agents, and NTP-like traffic, so build the allowlist from observed benign periodicity rather than guesses. Set an explicit expected false-positive rate and a review cadence, and document the technique coverage it adds so the SOC can see what the detection buys.
3. Executives ask for 'fewer alerts' and the SOC asks for 'more detections'. How do you answer both with one plan?
Read the worked answer
Reframe from volume to coverage and confidence.
Show two numbers side by side: analyst-facing alerts per day, and validated coverage of the techniques actually used in the intrusion. The plan should reduce the first while increasing the second, and it should say so in those terms.
Concretely:
- Consolidate and enrich rules rather than deleting them; aim for a stated reduction in analyst-facing volume, with the noisy rule still running in a low-priority lane.
- Report precision per rule, so a rule that fires 1,100 times and never yields a true positive is visible as a cost rather than a control.
- Report detection coverage by technique, including the fact that this incident was missed twice, once by pipeline failure and once by detection logic.
- Give a target date and a measured baseline so the claim is checkable next quarter.
Be direct about the budget: the failure that mattered most was a silent log pipeline, and that is an engineering fix, not a purchase. Presenting 'fewer alerts' as the goal on its own invites exactly the deletion that made this incident undetectable.