IBM QRadar External Alerts

Generates a detection alert for each IBM QRadar offense written to the configured indices. Enabling this rule allows you to immediately begin investigating IBM QRadar offense alerts in the app.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/03/17"
  3integration = ["ibm_qradar"]
  4maturity = "production"
  5promotion = true
  6updated_date = "2026/03/17"
  7
  8[rule]
  9author = ["Elastic"]
 10description = """
 11Generates a detection alert for each IBM QRadar offense written to the configured indices. Enabling this rule allows you
 12to immediately begin investigating IBM QRadar offense alerts in the app.
 13"""
 14from = "now-2m"
 15index = ["logs-ibm_qradar.offense-*"]
 16interval = "1m"
 17language = "kuery"
 18license = "Elastic License v2"
 19max_signals = 1000
 20name = "IBM QRadar External Alerts"
 21note = """## Triage and analysis
 22
 23### Investigating IBM QRadar External Alerts
 24
 25IBM QRadar is a Security Intelligence Platform that provides SIEM, log management, anomaly detection, and incident forensics. The rule promotes QRadar offense records as Elastic detection alerts, enabling analysts to investigate potential threats with full offense context including rule names, severity, and status.
 26
 27### Possible investigation steps
 28
 29- Review the offense details including rule name, description, and categories to understand the nature of the alert.
 30- Examine the offense severity and status (OPEN, HIDDEN, etc.) to prioritize investigation.
 31- Cross-reference the offense with QRadar console for additional context including contributing events and log sources.
 32- Investigate source and destination networks, device count, and event count associated with the offense.
 33- Consult the IBM QRadar investigation guide and resources tagged in the alert for specific guidance on handling similar threats.
 34
 35### False positive analysis
 36
 37- Offenses triggered by routine administrative activities or known maintenance can be false positives. Review the offense context and create exceptions for scheduled activities.
 38- Legitimate security testing or penetration testing may generate offenses. Coordinate with security teams to whitelist these during scheduled tests.
 39- Low-severity offenses from specific rules that are known to produce noise can be excluded by creating rule exceptions.
 40- Offenses from development or test environments may not require investigation. Consider excluding these environments if appropriate.
 41
 42### Response and remediation
 43
 44- Isolate affected systems if malicious activity is confirmed to prevent lateral movement.
 45- Review the offense details to identify compromised accounts, credentials, or systems and take appropriate remediation steps.
 46- Apply relevant security patches or updates to address any exploited vulnerabilities.
 47- Escalate to the security operations center (SOC) or incident response team for further analysis if the threat appears significant.
 48- Document the incident and update detection logic or exceptions based on findings.
 49"""
 50references = ["https://docs.elastic.co/en/integrations/ibm_qradar"]
 51risk_score = 47
 52rule_id = "d6702168-2be6-4d7d-a549-9bff67733df3"
 53rule_name_override = "rule.name"
 54setup = """## Setup
 55
 56### IBM QRadar Offense Integration
 57This rule is designed to capture offense events generated by the IBM QRadar integration and promote them as Elastic detection alerts.
 58
 59To capture IBM QRadar offenses, install and configure the IBM QRadar integration to ingest offense records into the `logs-ibm_qradar.offense-*` index pattern.
 60
 61If this rule is enabled alongside the External Alerts promotion rule (UUID: eb079c62-4481-4d6e-9643-3ca499df7aaa), you may receive duplicate alerts for the same QRadar events. Consider adding a rule exception for the External Alert rule to exclude data_stream.dataset:ibm_qradar.offense to avoid receiving duplicate alerts.
 62
 63### Additional notes
 64
 65For information on troubleshooting the maximum alerts warning please refer to this [guide](https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts).
 66"""
 67severity = "medium"
 68tags = [
 69    "Data Source: IBM QRadar",
 70    "Use Case: Threat Detection",
 71    "Resources: Investigation Guide",
 72    "Promotion: External Alerts",
 73]
 74timestamp_override = "event.ingested"
 75type = "query"
 76
 77query = '''
 78event.kind: alert and data_stream.dataset: ibm_qradar.offense
 79'''
 80
 81
 82[[rule.risk_score_mapping]]
 83field = "ibm_qradar.offense.magnitude"
 84operator = "equals"
 85value = ""
 86
 87[[rule.severity_mapping]]
 88field = "event.severity"
 89operator = "equals"
 90severity = "low"
 91value = "21"
 92
 93[[rule.severity_mapping]]
 94field = "event.severity"
 95operator = "equals"
 96severity = "medium"
 97value = "47"
 98
 99[[rule.severity_mapping]]
100field = "event.severity"
101operator = "equals"
102severity = "high"
103value = "73"
104
105[[rule.severity_mapping]]
106field = "event.severity"
107operator = "equals"
108severity = "critical"
109value = "99"

Triage and analysis

Investigating IBM QRadar External Alerts

IBM QRadar is a Security Intelligence Platform that provides SIEM, log management, anomaly detection, and incident forensics. The rule promotes QRadar offense records as Elastic detection alerts, enabling analysts to investigate potential threats with full offense context including rule names, severity, and status.

Possible investigation steps

  • Review the offense details including rule name, description, and categories to understand the nature of the alert.
  • Examine the offense severity and status (OPEN, HIDDEN, etc.) to prioritize investigation.
  • Cross-reference the offense with QRadar console for additional context including contributing events and log sources.
  • Investigate source and destination networks, device count, and event count associated with the offense.
  • Consult the IBM QRadar investigation guide and resources tagged in the alert for specific guidance on handling similar threats.

False positive analysis

  • Offenses triggered by routine administrative activities or known maintenance can be false positives. Review the offense context and create exceptions for scheduled activities.
  • Legitimate security testing or penetration testing may generate offenses. Coordinate with security teams to whitelist these during scheduled tests.
  • Low-severity offenses from specific rules that are known to produce noise can be excluded by creating rule exceptions.
  • Offenses from development or test environments may not require investigation. Consider excluding these environments if appropriate.

Response and remediation

  • Isolate affected systems if malicious activity is confirmed to prevent lateral movement.
  • Review the offense details to identify compromised accounts, credentials, or systems and take appropriate remediation steps.
  • Apply relevant security patches or updates to address any exploited vulnerabilities.
  • Escalate to the security operations center (SOC) or incident response team for further analysis if the threat appears significant.
  • Document the incident and update detection logic or exceptions based on findings.

References

Related rules

to-top