QRadar: Troubleshooting incorrect offense name issues

Resolving The Problem

1. If Dispatch New Event is disabled, then no CRE event is dispatched, and the offense is not renamed.
   
   Recommendation
   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.
   
   Recommendation
   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.
   
   Recommendation
   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.
   
   Recommendation
   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.
   
   Example
   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 192.168.42.20 triggers this rule then a new offense, ID 101, is created with offense source 192.168.42.20. A new CRE event is generated, and updates the name of offense 101.
   
   Two hours later, a second event with Source IP value 192.168.50.50 triggers the rule, another new offense, ID 102, is created with offense source 192.168.50.50.  However, because the response limiter interval is not expired no new CRE event is generated.
   
   Recommendations
   • 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.
   
   Recommendation
   Identify and mitigate causes of performance degradation at CRE to ensure all events are correlated fully.