correlating-security-events-in-qradar

Query the events table with the INOFFENSE function, selecting startTime, sourceIP, destinationIP, username, and QIDNAME(qid), ordered by startTime. Then pivot on the source IP with a time-bounded query to find all related activity across log sources.

Create a building block rule that fires when 10 or more authentication failure events share the same source IP within 5 minutes. Then build a correlation rule matching that building block plus a successful authentication event from the same source and destination within 10 minutes.

Common causes include DSM parsing failures leaving username or sourceIP fields NULL, events mapped to wrong QIDs, and event coalescing collapsing distinct failures into fewer records. Validate field extraction with a simple AQL SELECT and check for events in the Stored or Unknown category.

Add known scanners and service accounts to reference sets and exclude them in rule tests. Analyze closed offenses with closeReason False Positive to find noisy QID and log source pairs, then raise thresholds or add NOT-in-reference-set conditions rather than disabling rules.

Yes, AQL supports LEFT JOIN between the events and flows tables on sourceIP and destinationIP with a time window condition. This enables detecting lateral movement and data exfiltration by linking authentication events to flow byte volumes.

Correlation depends entirely on proper DSM parsing and QID mapping; unparsed log sources produce NULL fields that break rule conditions. Coalescing can hide event counts needed for threshold rules, and log source onboarding requires administrator access outside this workflow's scope.