An alert-quality report shows a SIEM rule generating many true positives but also a high false-positive rate and heavy analyst workload. What should the report drive the analyst to do?
Select an answer to reveal the explanation.
Short Explanation
Think of a SIEM rule like a car alarm: if it goes off for every passing truck, you'll stop listening. The report is telling you which alarms are noisy, so tune the worst false-positive rules first while keeping the real break-ins detected. If you don't fix the noise, your team burns out chasing ghosts.
Full Explanation
Alert-quality reporting turns raw SIEM events into detection-performance data. True positives show useful coverage, false positives show noisy logic, and analyst workload shows operational cost. When a rule produces many true positives but also many false positives, the correct response is to tune that rule—adjust thresholds, add contextual exclusions, enrich events, or correlate it with other signals—so precision improves without losing the detections that matter. Escalating every unmatched alert to threat hunting is wrong because threat hunting is proactive and hypothesis-driven, not indiscriminate triage, and it would increase analyst fatigue rather than reduce it. Increasing log ingestion volume is also wrong because more raw data does not fix imprecise detection logic; it can add noise and storage cost while leaving the same false positives intact. Requiring a full incident ticket for every false positive is wrong because it adds documentation burden without improving detection quality, and it can slow response to actual incidents. Exam caveat: CS0-004 expects reporting to enable process improvement and detection tuning, not just activity logging. Operational check: rank rules by false positives and analyst time, tune the top noisy rule, then compare true positives and false positives after the change.