QRadar: How to work with Match Count Rules

Resolving The Problem

When you have a rule “at least This Many events (x) in This Amount of  time (y)” the rule matches when the number of specified events are received.  If the action is to create an offense, the offense will be created with the original name. If a response is required to create a new event and offense, the CRE event will be generated.  This new event and offense can be created using the Rule Response wizard feature Dispatch New Event. If the CRE event is to replace the offense name this will happen the first time the value of This Many events (x) are received. However if the events continue to be received and the value of This Amount of Time (y) has not passed, no additional CRE events will occur. If the offense is closed within the time specified in the rule, a new offense will be created with the original offense name. The renaming of the offense will not happen until the Amount of time value (y) set in the rule has passed. The point Administrators need to understand with Match Count Rules is that when closing offenses with This Many Events (x) within the time specified in the rule, does not reset the counters.  New offenses will be created but the CRE Event will not fire again until the Event Count (x) in the Time specified (y) is not matched. This is the intended design.

Note: The time value (y) is measured from the last event received.

Example 1:  Criteria to match is and when at least 5 events are seen with the same Source IP and different Username in 1 hour(s)

Looking at this means once 5 events have been received within 1 hour the offense will be created with the correct name.  If the offense is closed within 1 hour a new offense will be created but with the original name and the CRE will not occur to rename it.  To get the offense named correctly there would need to be less than 5 events within 1 hour.

Computer 1 / User 1 / Source IP 1 / start time 00:00.00
Computer 2 / User 1 / Source IP 1 / start time 00:01.00
Computer 1 / User 1 / Source IP 1 / start time 00:02.00
Computer 2 / User 1 / Source IP 1 / start time 00:03.00
Computer 1 / User 1 / Source IP 1 / start time 00:04.00
Computer 1 / User 1 / Source IP 1 / start time 00:04.30
Computer 1 / User 2 / Source IP 1 / start time 00:05.00
CRE event fired - offense created and named correctly for Source IP 1

Example 2: Same Criteria

Computer 1 / User 1 / Source IP 2 / start time 00:10.00
Computer 2 / User 1 / Source IP 2 / start time 00:11.00
Computer 1 / User 1 / Source IP 2 / start time 00:21.00
Computer 2 / User 1 / Source IP 2 / start time 00:31.00
Computer 1 / User 1 / Source IP 2 / start time 00:31.30
Computer 1 / User 1 / Source IP 2 / start time 00:41.00
Computer 1 / User 2 / Source IP 2 / start time 00:51.00

No CRE Event fired because the condition is still matching on Computer 1 and User 1. This is still  within 1 hour window, but an offense will be created for Source IP 2 which is incorrectly named. Once 1 hour has passed without matching Computer 1 a new CRE event will occur. If the rate of 5 events received in 1 hour is not met, the CRE event will not happen.

Note: The 1 hour is a rolling window, so once 5 events come in from more than one user this condition will match until 1 hour has passed where the condition does not match.