Tuning a Noisy PowerShell BIOC and a 50,000-Indicator Feed
Atlas Retail's XSIAM tenant ingests 2.1 TB/day. A behavioral indicator for 'PowerShell with encoded command' fires about 900 times per day; the detection team's sample shows three true positives per week, mostly from a scheduled IT inventory script and a backup agent. The rule matches on the command line only, has no user or parent-process context, and applies to all endpoints, including 1,800 servers. Separately, the team just enabled a commercial threat-intelligence feed with 50,000 indicators. Within a day, indicator matching adds 2,000 alerts per day, many from an internal vulnerability scanner and from sinkholed domains. Leadership wants fewer alerts without losing detection of real attacker behavior, and wants a documented rationale for every tuning change. The tenant retains 90 days of searchable data.
1. How would you tune the PowerShell detection? Include the data you would query and the control you would use to avoid suppressing real attacks.
Read the worked answer
Start with a baseline, not a regex change. Query process events over 30-90 days and group by command line, parent image, user, endpoint group, and signer where available. The output should show the inventory script and backup agent as distinct clusters: same command line, same parent, same service account, recurring schedule. That evidence supports a narrow exclusion rather than a global one.
Restructure the rule into several detections:
- Workstations: encoded PowerShell with a suspicious parent such as an Office application, browser, or script host, or with a download cradle in the command line.
- Servers: encoded PowerShell only when the user is not the approved service account, the parent is not the approved scheduler, or the command line includes download or credential-access patterns.
- A low-severity inventory rule for the known IT script, retained for visibility but not promoted to an incident.
Use scoped exclusions with an owner, a justification, and an expiry date. Do not exclude -enc or -encodedcommand globally, and do not exclude by command-line substring alone. Prefer exclusion by file hash, signer, parent process, and user together. Replay historical true-positive samples against the revised logic before publishing, and map the detection to MITRE ATT&CK T1059.001. After deployment, compare the new rule's hits with the old rule's hits for two weeks to confirm the known true positives still fire.
2. What is your plan for the 50,000-indicator feed? Explain scoring, scoping, and alert design.
Read the worked answer
Do not promote every indicator match to an incident. First ingest and normalize the feed into Threat Intelligence Management, deduplicate indicators, and record source, confidence, first seen, last seen, and expiry. Filter out indicators that are known-bad only in theory: sinkholed domains, internal scanner addresses, and RFC1918 ranges that the feed should never contain. Score the remainder by confidence, age, indicator type, and relevance to the retail sector.
Use the feed primarily for enrichment and hunting. Create high-severity correlation rules only when a TI match is combined with a behavior or asset condition: for example, a process on a critical server connecting to a high-confidence C2 domain, or an endpoint resolving a domain tied to an actor that targets retail. Keep the raw match as a low-severity or informational signal for threat hunting. Scope the scanner allowlist to the scanner's IP addresses and user agent, and expire the allowlist rather than making it permanent.
Track per-feed precision: how many matches became true incidents, how many were scanner or sinkhole noise, and how many indicators were already expired. Review feed value quarterly and remove sources that produce noise without unique coverage.
3. Define metrics and a change-control process to prove the tuning did not reduce coverage.
Read the worked answer
Use a small set of metrics that can be measured before and after: alerts per day, alerts promoted to incidents, true-positive rate from analyst disposition, median time to triage, and coverage against a fixed test set of known malicious samples. For the PowerShell rule, keep a replay set of confirmed encoded-PowerShell attacks and confirm the revised rules still fire on every sample. For the TI feed, keep a set of known actor indicators and confirm they still enrich or alert where intended.
Change control:
- Every tuning change gets a ticket with the rule ID, old logic, new logic, query evidence, expected alert reduction, risk of missed detection, owner, and expiry date for any exclusion.
- Require peer review by a detection engineer who did not author the change.
- Publish to a test tenant or a limited endpoint group first where possible.
- Review the change after 30 days against the metrics; if true positives dropped unexpectedly, roll back.
- Keep an unmodified canary copy of the rule running in parallel for a defined period so coverage loss is visible.
Report the results to leadership as a before/after table, not as a claim that the rule was 'optimized.'