Triage of a 1,240-Offense Backlog With Scanner Noise
Your SOC has 1,240 open offenses. In the last 24 hours, 380 new offenses arrived, and the team can fully investigate about 25 per shift. The largest source is a rule named 'Authentication Failure - Multiple Failed Logins,' which accounts for 61% of the new offenses; nearly all of those events originate from two vulnerability scanner IP ranges that were added last month. A second offense has magnitude 9 but contains a single event: a successful login to a finance database server by a contractor account at 02:14. A third offense has magnitude 4 but contains 400 events across 12 servers. The CISO wants the backlog reduced this week without missing the contractor activity. The QRadar deployment receives 45,000 EPS, has 90-day event retention, and uses asset weights for critical servers.
1. How should the analyst prioritize the 380 new offenses, and which QRadar offense attributes should drive the order?
Read the worked answer
Prioritize by magnitude together with relevance and offense type, not by arrival order or raw event count. Magnitude already blends severity, credibility, relevance, asset weight, and event count, so it is the best single sort key, but it must be read alongside the offense's contributing rules and the asset it touches.
Practical order:
- Filter to offenses whose source or destination asset has a high asset weight (the finance DB server, domain controllers).
- Within that set, sort by magnitude descending and by last event time.
- Review offenses with multiple contributing rules or with a source IP that is not a known scanner first; a single-rule offense from a scanner range can be bulk-deferred.
- Use 'Assign to me' and offense notes so two analysts do not duplicate work.
The 25-per-shift capacity means the team cannot investigate 380. The defensible approach is to triage all 380 with filters and saved searches, fully investigate only the ~25 highest-risk, and document a bulk-close decision for the scanner class after validating it. Reducing the backlog without a rule-level fix just recreates it next shift.
2. What is the most defensible way to handle the scanner-generated offenses, and where should the change be made?
Read the worked answer
Validate first, then tune at the rule or building-block layer, not by disabling the rule or closing offenses one by one. Steps:
- Confirm the two scanner ranges are authorized and that the events are genuine authentication failures generated by scans.
- Check whether the rule already references a building block. If it does, add the scanner ranges to a dedicated building block, e.g. 'Authorized Vulnerability Scanners', and negate it in the rule condition.
- If the rule has no building block, create the BB and edit the rule to exclude it, or add a rule-level exception using 'and not' against the BB.
- Do not edit a shared BB that other rules rely on; keep the scanner BB semantically narrow so other authentication rules can reuse it safely.
- Test with the Rule Wizard against 7 days of historical events to confirm the reduction before deploying.
- Check offense coalescing as well. If the scanner generates many offenses from the same source, coalescing may be compounding the backlog, but coalescing is not a substitute for excluding authorized scanners.
- Document the change and set a review date, because scanner ranges change.
3. Explain how the magnitude-9 offense can contain only one event, and whether it should be closed as a false positive.
Read the worked answer
Magnitude is not a count of events. QRadar computes it from severity, credibility, relevance, and the asset weight of the source/destination, with event count as only one modifier. A single successful login by a contractor account to a finance database at 02:14 can reach magnitude 9 if:
- the contributing rule has high severity (for example, a successful logon after multiple failures, or an unusual-logon-time rule),
- the destination asset has a high asset weight,
- the rule has high credibility or is tied to a high-confidence use case.
So the correct move is not to close it. Open the offense, read the contributing rules and the magnitude breakdown, check the asset weight and the user's normal behavior, and verify with the contractor's manager or the access request. A one-event offense on a critical asset is often the highest-value item in the queue; a 400-event offense on 12 low-weight servers may be a noisy scan. Close it as a false positive only after evidence, and if the rule is genuinely miscalibrated, fix the rule rather than the individual offense.