Service-Account Logon Detection With Building Blocks Under CPU Pressure
Your QRadar deployment processes 45,000 EPS across three regions. You must detect successful logons by service accounts to domain controllers outside 07:00-19:00 local time. The environment has 60 domain controllers, 240 service accounts, and three regional time zones. The event processor is already at 70% CPU during peak, and the current catch-all rule uses a regex on the username field plus a 60-entry IP list. Analysts report the rule fires for expected batch jobs and for a monitoring account, and the rule is difficult to reuse. You have been asked to redesign the detection using building blocks, keep the false positive rate low, and avoid adding load to the event pipeline. The rule set currently has 14 rules and no building blocks. Log sources for all three regions are onboarded, but the domain controller logs arrive with a 20-minute delay.
1. Design the building blocks and the final rule. What conditions belong in each building block, and why?
Read the worked answer
Separate the detection into three reusable, semantically pure building blocks and one rule.
BB1 'Domain Controllers': an asset group or reference set of the 60 DC IPs/hostnames. Use an asset group if the assets are already modeled; it is maintained in one place and avoids duplicating a 60-entry list across rules.
BB2 'Service Accounts': a reference set of the 240 usernames, or a regex only if naming is disciplined. Prefer a reference set so additions do not require rule edits.
BB3 'Outside Business Hours (Local)': time-of-day conditions per region. If local time is not normalized reliably, keep three BBs (one per region) or use a custom property populated at the DSM/property layer; do not assume the event timestamp is local.
Final rule 'Successful service-account logon to DC outside business hours': event category/QID for successful logon AND BB1 AND BB2 AND BB3, with MITRE mapping and an offense response.
Why: BBs are evaluated as reusable pieces and referenced by many rules, and they let you change the account list or DC list without touching rule logic. Avoid one BB that combines all three conditions; that defeats reuse and makes testing harder.
2. A batch service account legitimately logs on at 03:00 to 12 domain controllers. How do you exclude it without weakening detection for the other 239 accounts?
Read the worked answer
Do not add the batch account to a global exclusion that applies to every rule, and do not delete it from the Service Accounts reference set if other rules need it. Instead:
- Create a separate BB, e.g. 'Known Batch Service Accounts', containing that one account (or a small set).
- In the final rule, add 'and not BB: Known Batch Service Accounts' only if the batch behavior is truly benign for this specific detection.
- If the account should still be flagged in other contexts (for example, logon to a non-DC server), keep the exclusion scoped to this rule rather than the shared BB.
- Better still, model the expected behavior: a BB 'Expected Batch Window' with the 03:00-04:00 window and the DC asset group, and exclude only that combination.
- Re-test with the Rule Wizard over at least two weeks of historical events, including the batch runs, and confirm the remaining alerts are the monitoring account and true anomalies.
This preserves detection for the other 239 accounts and keeps the exclusion auditable. Exclusions buried inside a shared BB are how detections quietly die.
3. How do you validate the redesign before production, and what performance considerations matter?
Read the worked answer
Validate in the Rule Wizard with historical events before deploying:
- Run the rule against 7-14 days of events, compare hit counts before and after, and inspect a sample of matches and near-misses.
- Confirm the BBs resolve correctly for all three regions, especially time-zone logic; a DC in one region should not be evaluated with another region's hours.
- Check the 20-minute-delayed logs. If the time-of-day condition uses event time, delays can push an event outside the intended window; decide whether to accept that or base the condition on a normalized field.
Performance:
- Reference sets and asset groups are cheaper than regex over every event.
- Keep the cheapest, most selective condition (the successful-logon QID/category) first so the BB lookups are evaluated less often.
- Avoid nested BBs with overlapping expensive conditions; keep each BB narrow.
- Monitor event processor CPU for 24 hours after deployment against the 70% baseline, and confirm the rule's hit rate is in the expected range.