QRadar Offense: How to Read and Investigate an Offense

What Creates an Offense

A Rule in QRadar is a collection of Tests applied to an Event, Flow, series of events, Offense, or other combination depending on the rule type. When conditions are met, a Response can create an Offense, add data to a Reference Set, send a notification, or perform another action. The Rule name is merely a starting point; the analyst must understand the Test stack and the data Scope.

Before opening Raw events, ask: Is this an Event rule or a Flow rule? Is it a Threshold within a time window? Is the condition Stateful? Does the Rule rely on a Building Block that defines a group, such as “mail servers” or “vulnerability scanners”? Is the Offense associated with a Source IP, Destination IP, Username, or another attribute?

Magnitude, Relevance, Credibility and Severity

Magnitude measures the importance of the Offense in the environment and is used for sorting. Relevance refers to the potential impact on the network and assets. Credibility represents the reliability of the signal and is influenced, among other things, by the reliability of the log source and corroboration from additional sources. Severity refers to the threat level relative to the target's readiness. QRadar re-evaluates Magnitude when data is added and at scheduled times.

No score should be interpreted in isolation without understanding the data. High Credibility from one source does not guarantee the event is malicious; a Parser might classify legitimate activity as a severe category. High Relevance can result from a critical asset, but if the target is a Honeypot or Lab, the context is different. High Severity might be justified in terms of the event type, even if the action was blocked.

Events and Flows: Two Lenses

An Event typically describes a log record: Authentication, Firewall deny, Process, Audit, or an application event. A Flow describes a network conversation or communication: source, destination, Ports, Protocol, Bytes, Packets, and timings. An Offense can include one or both. Connecting an Event and a Flow allows checking not only “what the product reported,” but also “whether the traffic occurred and what its extent was.”

In an investigation, open the Events list, sort by time and category, and check QID, Log Source, Username, Payload, and custom fields. Then move to Flows: Did the Source access the Destination? Was there bi-directional communication? What was the data volume? Does the Port match the expected service? The absence of a Flow does not prove there was no communication; it might be that there is no NetFlow coverage in that Segment.

Source, Destination, and Assets

QRadar associates an Offense by “Offense source” determined by the rule and events. Sometimes the Source is an external address, sometimes a user, internal Host, or destination. Do not assume the Source field is always an attacker. In a Malware callback example, an internal Source might be a compromised workstation; in a Scan example, the Source might be an authorized organizational Scanner.

Asset context changes prioritization: a Domain Controller server, admin workstation, and test server are not the same. Check Asset weight, Owner, Network hierarchy, open Ports, Vulnerabilities, and business relationships. If QRadar does not identify the asset or identifies it by an old name, note this as a gap in evidence.

Offense Investigation Workflow

1. Read the Description, Rule(s), Offense type, Source, Destination, Magnitude, Start time, and Last event.
2. Open the Rule or the rule details and understand the Tests, Threshold, time window, and Building Blocks.
3. Review the contributing Events. Group by QID, Log Source, Username, Source, and Destination to identify repetitions and duplications.
4. Check related Flows, if any, and look for communication before and after the central Event.
5. Verify Network hierarchy and Asset profile. Ask if the addresses are internal, VPN, NAT, Proxy, or Shared infrastructure.
6. Build a Timeline and perform additional searches in Log Activity and Network Activity for a broader range.
7. Check for additional Offenses on the same assets, users, Domains, or Rules. A link between incidents can broaden the Scope.
8. Classify, document Notes, assign an Owner, and decide whether to escalate, close, or keep under monitoring.

Scenario: Multiple Sources Against a Critical Target

In the lab, an Offense named “Multiple authentication failures followed by success” was created on a critical file server. Magnitude is 8, there are 180 Events from three Log Sources, and the Offense source is an internal IP. The working table might look like this:

If the Source is a management server and the failures correspond to a failed Job after a password change, it might be a Benign Positive. But Success followed by SMB to a sensitive Share still requires authentication of the account and action. If there is no approved Change, escalate to IR or the identity team according to the Playbook.

Closing, Notes, and Tuning

Notes should include hypothesis, evidence, searches performed, gaps, Classification, and actions. The Closing Reason should be consistent to allow for Metrics and Tuning. “False Positive” without explanation is not enough; state if the root cause is an authorized Scanner, a faulty Parser, Threshold, Duplicate, Asset context, or legitimate user activity.

Tuning can involve modifying a Rule, Building Block, Reference set, Network hierarchy, Log source credibility, or Asset weight. Every change needs an Owner, documentation, Regression testing, and a Review date. Do not exclude an entire Source IP if only an Event name, Destination, maintenance window, or Service account can be excluded.

Checklist

• ✓I understood what created the Offense and which Rules contributed.
• ✓I broke down Magnitude into its contextual components and did not use it as proof.
• ✓I checked Events and also Flows when available.
• ✓I verified Source, Destination, NAT, Proxy, and Network hierarchy.
• ✓I checked Asset criticality and Vulnerabilities.
• ✓I built a Timeline and searched for activity before and after.
• ✓I wrote detailed Notes and a Closing Reason.
• ✓I implemented focused Tuning with an Owner and Review date.

Common Mistakes

• Closing based on low Magnitude without opening the events.
• Assuming the Offense source is an attacker.
• Counting Events without checking for duplicates or Aggregation.
• Ignoring Flows or the lack of traffic coverage.
• Relying on an outdated Asset profile.
• Changing a Rule in production without a Baseline and Regression test.

Summary and CTA

Choose a lab Offense and write a one-page investigation report: what created it, what Magnitude says, which Events and Flows contribute, who the Source and Destination are, what the Asset context is, and what the closing decision is. Then compare your report to another analyst's Ticket. This exercise teaches how to work with QRadar as an investigation platform and not just an alert queue.

FAQ