QRadar: Troubleshooting rule tests with log activity searches

Troubleshooting

Problem

At times, users might notice that an event failed to trigger a rule and you need to troubleshoot the cause. This article provides an overview and example of the basic steps the QRadar Support completes when they diagnose why a rule did not trigger as expected.

Cause

A rule test in the rule did not meet the required criteria.

Diagnosing The Problem

Custom rules in QRadar apply simple and stateful criteria against event and flow records in real time. These tests run quick searches against a data set of one event at a time. Therefore, the best first step to take when troubleshooting rules that either fail to trigger or trigger unexpectedly is to search in Log Activity or Network Activity.

A general outline for troubleshooting rule tests:

Identify the start time of the first event that is intended to match the rule.
Add search criteria to replicate simple property and lookup tests.
Identify function tests and modify the search time criteria and grouping as needed.
Review search results to assess effectiveness of the search criteria.

1. Identify the start time of the first event that is expected match the rule

One fundamental requirement for this process is that we know of at least one event or flow record that we expect to trigger the custom rule.

Log in to the QRadar Console.
Click the Log Activity or Network Activity tab.
Create a search for the event or flow record we expect to trigger the custom rule.
Take notice of the Start time from the event or flow record details.
Set the view time range to start two minutes before the Start Time and end two minutes after.

2. Add search criteria to replicate simple property and lookup tests

Most rule tests make a quick comparison between a property value in the record or do a lookup based on a property value in the record. Identifying the corresponding search criteria for these tests is relatively simple.

For example, consider creating a custom rule with the following criteria:

Click the Offense tab.
Click Rules.
Click Actions > New Event Rule.
Click Next to access the Rules Wizard.
Click the appropriate box to confirm Events or Flows
In the search bar, type: When the event(s) were detected by one or more of these log source types.
Change log source types to Microsoft Security Event Log.
In the search bar, type: when the event QID is on of the following QIDs.
Click QID and update the value to equal 5001528.
In the search bar, type: when any of these properties match this regular expression.
```
and when the event(s) were detected by one or more of Microsoft Windows Security Event Log
and when the event QID is one of the following (5001528) Network Share Object Added
and when any of ShareName (custom) match .*?\$
and when any of ShareName (custom) are contained in any of Test RefSet - AlphaNumeric
```
- The first two tests are looking at the Log Source Type and QID.
- The third test is using an Ariel-based filter, and so you can use ShareName (custom) match .*?\$ as the corresponding search criteria.
- The fourth test is testing the value of a property against a reference set, which corresponds directly with a Reference Set filter in the search function.
The search is intended to display events that can match this custom rule includes these criteria:
```
Log source Type is Microsoft Windows Security Event Log
QID Number is 5,001,528
ShareName (custom) contains any of .*?\$
ShareName exists in any of Test RefSet
```

3. Identify function tests and modify the search time criteria and grouping as needed

Function tests provide a challenge when you apply this troubleshooting method because these tests match after they detect multiple records matching the criteria.

To emulate this type of test

Click the Log Activity tab.
Click Edit Search and add the properties referenced in the function test as Group By fields.
Note the time interval in the function test and move the start time for your search back by that amount.
For example, if the search time is set as 18:05-18:10, and the time interval in the function test is 1 hour, then the new search time needs to be updated to 17:05-18:10.

4. Review search results to identify which search criteria fail to match the target events

Run the search and examine the results. If the event in question does not show up in the Search Results, then that means that one of the rule tests failed to match. Start the investigation by filtering through each rule test one by one, in any order.

Working from the example tests discussed in step 1:

Starting from the last rule test, validate if ShareName exists in the reference set.
Remove the filter "ShareName exists in any of Test RefSet" search filter.
If the event shows up in the search result, then, we know that there is an issue with the value of ShareName not being found in the reference set.
If no events are found, then move on to the next rule test.
Continue this procedure to identify the problematic rule test.

To validate function tests, you need to review the search results and count how many events match the full criteria in the designated time range. If you use the Group By fields suggested in step 3, use the Count field to assess how many events match the criteria.

If the function test is assessing multiple criteria, such as the same Source Workstation (custom), username and different Destination IP"), review those Group By fields and compare them against the test criteria.

For example, an example of a function rule test is the match-count rule test:

and when RuleTest1 match at least 10 times with the same Source IP in 5 minutes

To validate this rule test through searches, you would need to use expand the time range 5 minutes prior and add the filter:

Custom Rule Partial or Full Matched is RuleTest1
Source IP [Indexed] equals x.x.x.x

Then validate the count of events to determine whether there are at least 10 events within the 5 minute time range. When you identify the rule tests that do not match the target events, you can tune the custom rule tests.

Resolving The Problem

Correct the rule test that caused the rule to not match.

Note: IBM support can assist users to identify whether a rule is not functioning due to software issues. Tuning or writing custom rules for users is out-of-scope for IBM Support. For information, see the Rule section of the performance technical note.

Document Location

Worldwide

[{"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":"a8m0z000000cwtrAAA","label":"Rules"}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"}]

Tips