The Alert That Fires Every Night at 02:00
A SOC receives about 400 alerts per day. An IDS rule flags outbound DNS queries to a domain on a threat feed. The rule fires 30–40 times every night between 01:50 and 02:10 from the same 12 workstations, and the domain resolves to a sinkhole operated by the feed vendor. Analysts have been closing these as false positives for three weeks. Last week a workstation in that group was found beaconing to a different domain that was not on the feed. The SOC has no asset inventory mapping workstations to owners, and the feed is updated weekly. The SOC's SLA requires high-severity alerts to be triaged within 30 minutes.
1. What is wrong with how the team is handling these alerts, and what is the risk?
Read the worked answer
The team is treating a recurring, predictable pattern as benign by repetition rather than by evidence. The 02:00 window and fixed workstation set suggest a scheduled task or software update, which may be legitimate - but the team never confirmed the cause, so the alert is being suppressed by habit. The risk is twofold: (1) the same rule that catches the benign scheduled query also catches real beaconing, and the team has trained itself to ignore it; (2) the workstation that later beaconed to a non-feed domain shows the pattern was not fully benign - either the scheduled task is compromised or the sinkhole domain is a decoy. Closing without root-cause is an unmanaged detection gap, and the 30-minute SLA is being met on paper while the actual investigation is zero.
2. Design a triage approach that resolves the nightly noise without blinding the SOC to real beaconing.
Read the worked answer
Steps: (1) Identify the cause of the 02:00 queries on the 12 hosts (scheduled task, updater, telemetry) and document it; (2) if benign, create a narrow exception keyed to process, destination, and time window - not a blanket domain suppression - and require re-review when the feed or process changes; (3) enrich alerts with asset owner and process context so analysts can distinguish scheduled vs. interactive; (4) keep a separate high-signal rule for beaconing to non-feed domains and for periodic patterns outside the known window; (5) add the previously seen non-feed domain to hunting queries and review the 12 hosts for persistence. The principle: suppress the known benign instance, never the behavior class.