IBM Support

QRadar: Troubleshooting incorrect offense name issues



Offense descriptions show up with the event name or flow application type instead of the custom naming configured in the triggered custom rule.


The dispatched CRE event did not fire due to response configuration, or was not associated with the intended offense.

Diagnosing The Problem

There are several conditions in which a CRE event might not be generated as expected or otherwise not associated with the expected offense.
We need to collect several pieces of critical data for each misnamed offense.

Note:  The conditions are tied to the custom rule configuration. Therefore, investigations can be expedited by identifying misnamed offenses triggered from the same rule.  That rule configuration now needs only to be reviewed once.
  1. In the Offense tab
    1. Find the offense in the main offenses listing and note the following data:
      • Offense ID
      • Domain
      • Description
      • Offense type
      • Offense source
      • Start Date
    2. Open the offense summary view.
      1. Click Display, then select Rules.
      2. For each rule, double-click the rule name to load Rule Wizard displaying the rule configuration details.
      3. Note the following details:
        1. Rule Name
        2. Is there a function (or match-count) test?
          1. If so, what properties are referenced in the function test?
          2. If so, what time interval is configured for the function test?

            For example, given a test like this:
            and when at least 5 events are seen with the same Source Workstation (custom), Username in 15 minutes
            The properties that are being tracked to be the same over multiple events are Source Workstation (custom) and Username.
            The time interval is 15 minutes.
        3. Click Next to view the Rule Wizard: Rule Response page.
          1. What is the Detected Event Indexing property (the property used to Index the offense from the detected event)

            Detected Event Indexing Property
            In this screen capture, the property from the detected event used to index the offense is Source IP.
          2. Is Dispatch New Event enabled?
            1. If yes, is Ensure the dispatched event is part of an offense enabled?
              1. What is the Dispatched Event Indexing property (the property being used to index the offense from the dispatched event)?
              2. What is the configuration under Offense Naming?

                Offense Naming configuration
                In this example, Dispatch New Event and Ensure the dispatched event is part of an offense are both enabled.
                The dispatched event is configured to contribute to an offense by using the property Source IP.
                The Offense Naming configuration is set to This information should contribute to the name of the associated offense(s).
              3. Is the Response Limiter configured and enabled?
                1. If yes, note the full configuration: number of responses, time interval, and property

                  Response Limiter configuration
                  In this example, the number of responses is 1. The time interval is 30 minutes, and the property is Source IP.
  2. From the Log Activity and Network Activity views:
    1. Find the event or flow records that triggered the offense. Open the record details view for the first record.
      1. Identify which event processor processed the detected event or flow.
    2. Was that event processor experiencing performance degradation at the time?

Resolving The Problem

  1. If Dispatch New Event is disabled, then no CRE event is dispatched, and the offense is not renamed.

    The only way to rename an offense is by a CRE event. Dispatch New Event must be enabled for offense naming to be updated
  2. If the Offense Naming configuration is set to "This information should not contribute to the naming of the associated offense(s)", then the CRE event name does not contribute to the offense naming in any way.

    Offense Naming must be set to either "This information should contribute to the name of the associated offense(s)" or "This information should set or replace the name of the associated offense(s)" for the dispatched event to contribute to offense naming.
  3. If the Detected Event Indexing and Dispatched Event Indexing properties do not match, then the CRE event contributes to a different offense than the offense to which the detected event contributed.

    For most use cases, use the same property for the detected event indexing property and the dispatched event indexing property if you want to have a CRE event update the offense name
  4. If the properties tracked in a function test are different than the detected event indexing property, then it is likely that a CRE event did trigger for the first offense matching the property in the function test. However, since the rule is still "hot" when the indexed property changes, no new CRE event is generated to rename the new offense.

    Review the events contributing to this offense and note the values matching the function test properties. Look for other offenses triggered from the same Rule with the same function test property values and different offense source values. It is most likely that, when the rule first became hot for the properties matching the function test, an offense and CRE event were generated and that CRE event contributed to the naming of that offense. When events matching the same function test properties, but have a different offense source value match the rule while that rule is already hot, the new events might contribute to a new offense but no new CRE event is generated since the rule was still hot.

    Configure the index properties used for the dispatched and detected events to match one of the properties that are being used for matching in the function test.
  5. If the Response Limiter is configured to trigger on a different property than what is used for the detected and dispatched event indexing, CRE events might be unexpectedly suppressed. Because the Response Limiter maintains its state information relative to the Rule, independently from any function test or offense information, the response limiter configuration does not automatically generate a CRE event response when a new offense is created.

    Consider a rule whose response limiter is configured for Respond no more than 1 time(s) per 12 hour(s) per Rule, but the detected and dispatched indexing are configured to use Source IP.

    If an event with Source IP value triggers this rule then a new offense, ID 101, is created with offense source A new CRE event is generated, and updates the name of offense 101.

    Two hours later, a second event with Source IP value triggers the rule, another new offense, ID 102, is created with offense source  However, because the response limiter interval is not expired no new CRE event is generated.

    • Use the same property for the response limiter configuration as the property used for detected & dispatched event indexing for most use-cases.
    • In most cases, do not use the property "Rule" in response limiter configuration because of the inherent problems this configuration can cause with response generation.
  6. If there is a function test configured for the rule, and the rule was still hot when the offense was closed, a new CRE event is not generated when another event triggers the same rule for the same offense source.

    When an offense is closed, it does not reset the rule state for relevant function tests. This behavior was identified as a defect, APAR IJ30912 , fixed in QRadar releases 7.4.3 FixPack 1 and 7.3.3 FixPack 9.
  7. All other configurations suggest CRE event is generated, and no conflicts between function test properties and indexing properties exist but CRE performance degradation occurred at the time the event arrived.

    When a CRE event is dispatched as a rule response, the initial CRE event record is automatically tagged with the triggering rule and is flagged as Associated With Offense. The new event is then sent back into the CRE for correlation against the rest of the rule set. If a system is experiencing performance degradation at the time the CRE event arrives to be correlated further, that CRE event might be "routed directly to storage" and bypass the CRE entirely, which would also cause that event to not be added to the metadata in the SIM model that identifies that event as associated with the offense, so it does not show up in the 'Events' search from the offense summary. In this situation, the CRE event might be present and might show up in Log Activity as associated with an offense (because the system is presenting data based on the event record). Clicking the red star loads the correct offense summary due to the offense type, offense source, and triggering rule. The CRE Event also notably lists the triggering rule in the event details.

    To verify
    Search for CRE events matching the rule name with the same index value as the offense.

    Identify and mitigate causes of performance degradation at CRE to ensure all events are correlated fully.
Next steps
If none of these conditions appear to represent your issue, open a new case with IBM Support. Include a description of the offense issue and collect logs from the Console and the managed host on where the triggering event or flow was processed.  Use the Advanced Options setting, Collect Logs for this Many Days to collect logs based on the Start Date of the offenses experiencing an issue.

Document Location


[{"Type":"MASTER","Line of Business":{"code":"LOB24","label":"Security Software"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSBQAC","label":"IBM Security QRadar SIEM"},"ARM Category":[{"code":"a8m0z000000cwthAAA","label":"Offenses"},{"code":"a8m0z000000cwtrAAA","label":"Rules"}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"},{"Type":"MASTER","Line of Business":{"code":"LOB24","label":"Security Software"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSKMKU","label":"IBM QRadar on Cloud"},"ARM Category":[{"code":"a8m0z000000cwthAAA","label":"Offenses"}],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"}]

Document Information

Modified date:
31 August 2022