Im new to secops needed a clarification that if we are using qradar offenses connector and fetching the offences, then on what filters it fetches the offenses as it creates duplicate case for same offense multiple times if new events are added to that offense on SIEM even though the previous case wasn't closed yet. How can we avoid this. I need to only fetch unique offenses each time and once the case with same offense is closed then only new case should be created if in case any new events are appended to previous offense.
Kindly Help me to configure this!
Best answer by hzmndt
It seems you're encountering an issue with duplicate cases being created in Google SecOps when new events are added to an existing IBM QRadar offense. This is a known challenge, and the behavior can depend on the specific connector version and configuration.
Here's a breakdown based on the documentation:
How QRadar Connectors Fetch Offenses:
There are a few different connectors for QRadar within Google SecOps, and they behave slightly differently:
QRadar Offenses Connector: This connector fetches offenses and creates Google SecOps alerts based on the QRadar offenses themselves. It has a limit on the total number of events it will fetch per offense. By default, if no dynamic list rules are set, it will fetch all offenses returned from the QRadar API.
QRadar Baseline Offenses Connector: This connector is designed to create a single Google SecOps alert per QRadar offense and notably does not create additional Google SecOps alerts when new events are added to the offense in QRadar. This might be a key point for your issue. This connector also uses the Google SecOps dynamic list, and like the other, fetches all offenses if no rules are set. (Requires QRadar API version 10.1 or higher).
QRadar Correlation Events Connector v2 (Recommended): This connector fetches offenses based on the QRadar rule names that triggered the offense. To control ingestion, you must add the specific QRadar rule names (case-sensitive) to the dynamic list in Google SecOps. This connector keeps track of every event ingested per offense using a hash to prevent duplicate event ingestion.
Why Duplicate Cases Might Be Created:
If you are using the base "QRadar Offenses Connector," it might not have a built-in mechanism to update existing Google SecOps cases when new events are added to the source QRadar offense. Instead, the addition of new events might make the offense appear "new" or "updated" to the connector on subsequent polls, triggering a new alert ingestion.
The connector's logic for determining a unique offense (e.g., based on Offense ID, last updated time, event count) can influence this.
How to Avoid Duplicate Cases & Handle Updates:
Use the "QRadar Baseline Offenses Connector": As mentioned, this connector is designed to create only one alert per offense and not generate new alerts for subsequent events. This would prevent the duplicates you're seeing from new events.
Alert Grouping in Google SecOps: Google SecOps has an "Alert Grouping Mechanism" that allows you to define rules for how incoming alerts are grouped into cases. You could potentially configure grouping rules based on the QRadar Offense ID. This way, even if the connector sends a new "alert," SecOps could group it with the existing open case for that Offense ID instead of creating a new one. Check the "Configure an alert grouping" documentation within Google SecOps.
Connector Configuration & Dynamic Lists: Ensure you are using dynamic lists effectively if you only want to ingest offenses triggered by specific, important QRadar rules. This reduces the noise and volume of alerts.
Check Connector Version: Bugs related to duplicate events/alerts have been reported for QRadar connectors in the past. Ensure your connector version is up-to-date, as fixes or improvements may have been released. See the "Google SecOps Response Integrations release notes" for updates.
Playbook Logic: Within your SOAR playbooks, you can build logic to search for existing open cases with the same QRadar Offense ID. If found, update the existing case instead of proceeding as a new incident. This requires custom playbook development.
Desired Behavior: New Case Only if Previous is Closed:
This specific logic (re-alerting on new events only if the prior case is closed) is advanced. It's unlikely to be a default connector setting.
You would likely need to implement this through a combination of:
Alert Grouping: To group alerts from the same offense ID.
Custom Playbook Logic: The playbook triggered by the alert would need to:
Extract the QRadar Offense ID.
Search for any other cases in SecOps with the same Offense ID.
Check the status of those cases.
If an open case exists, update it (e.g., add a note, re-open if closed too soon).
If no open case exists, proceed with the current alert as a new incident.
Recommendations:
Identify: Confirm the exact name of the QRadar connector you are using.
Explore: Investigate the "QRadar Baseline Offenses Connector" as it seems to inherently prevent re-alerting on new events.
Configure: Look into Google SecOps "Alert Grouping" rules, using the QRadar Offense ID as a primary key for grouping.
Customize: If necessary, develop custom playbook logic to handle the stateful check (is the previous case closed?).
It seems you're encountering an issue with duplicate cases being created in Google SecOps when new events are added to an existing IBM QRadar offense. This is a known challenge, and the behavior can depend on the specific connector version and configuration.
Here's a breakdown based on the documentation:
How QRadar Connectors Fetch Offenses:
There are a few different connectors for QRadar within Google SecOps, and they behave slightly differently:
QRadar Offenses Connector: This connector fetches offenses and creates Google SecOps alerts based on the QRadar offenses themselves. It has a limit on the total number of events it will fetch per offense. By default, if no dynamic list rules are set, it will fetch all offenses returned from the QRadar API.
QRadar Baseline Offenses Connector: This connector is designed to create a single Google SecOps alert per QRadar offense and notably does not create additional Google SecOps alerts when new events are added to the offense in QRadar. This might be a key point for your issue. This connector also uses the Google SecOps dynamic list, and like the other, fetches all offenses if no rules are set. (Requires QRadar API version 10.1 or higher).
QRadar Correlation Events Connector v2 (Recommended): This connector fetches offenses based on the QRadar rule names that triggered the offense. To control ingestion, you must add the specific QRadar rule names (case-sensitive) to the dynamic list in Google SecOps. This connector keeps track of every event ingested per offense using a hash to prevent duplicate event ingestion.
Why Duplicate Cases Might Be Created:
If you are using the base "QRadar Offenses Connector," it might not have a built-in mechanism to update existing Google SecOps cases when new events are added to the source QRadar offense. Instead, the addition of new events might make the offense appear "new" or "updated" to the connector on subsequent polls, triggering a new alert ingestion.
The connector's logic for determining a unique offense (e.g., based on Offense ID, last updated time, event count) can influence this.
How to Avoid Duplicate Cases & Handle Updates:
Use the "QRadar Baseline Offenses Connector": As mentioned, this connector is designed to create only one alert per offense and not generate new alerts for subsequent events. This would prevent the duplicates you're seeing from new events.
Alert Grouping in Google SecOps: Google SecOps has an "Alert Grouping Mechanism" that allows you to define rules for how incoming alerts are grouped into cases. You could potentially configure grouping rules based on the QRadar Offense ID. This way, even if the connector sends a new "alert," SecOps could group it with the existing open case for that Offense ID instead of creating a new one. Check the "Configure an alert grouping" documentation within Google SecOps.
Connector Configuration & Dynamic Lists: Ensure you are using dynamic lists effectively if you only want to ingest offenses triggered by specific, important QRadar rules. This reduces the noise and volume of alerts.
Check Connector Version: Bugs related to duplicate events/alerts have been reported for QRadar connectors in the past. Ensure your connector version is up-to-date, as fixes or improvements may have been released. See the "Google SecOps Response Integrations release notes" for updates.
Playbook Logic: Within your SOAR playbooks, you can build logic to search for existing open cases with the same QRadar Offense ID. If found, update the existing case instead of proceeding as a new incident. This requires custom playbook development.
Desired Behavior: New Case Only if Previous is Closed:
This specific logic (re-alerting on new events only if the prior case is closed) is advanced. It's unlikely to be a default connector setting.
You would likely need to implement this through a combination of:
Alert Grouping: To group alerts from the same offense ID.
Custom Playbook Logic: The playbook triggered by the alert would need to:
Extract the QRadar Offense ID.
Search for any other cases in SecOps with the same Offense ID.
Check the status of those cases.
If an open case exists, update it (e.g., add a note, re-open if closed too soon).
If no open case exists, proceed with the current alert as a new incident.
Recommendations:
Identify: Confirm the exact name of the QRadar connector you are using.
Explore: Investigate the "QRadar Baseline Offenses Connector" as it seems to inherently prevent re-alerting on new events.
Configure: Look into Google SecOps "Alert Grouping" rules, using the QRadar Offense ID as a primary key for grouping.
Customize: If necessary, develop custom playbook logic to handle the stateful check (is the previous case closed?).
