IBM Support

QRadar: Custom rule tuning considerations

How To


Tuning custom rules is an important consideration to ensure optimum performance in a QRadar environment. The faster a system can process its rule set against each event, the more EPS a system can process without encountering performance degradation.


The Custom Rule Engine (CRE) performs the following functionality:
  • Each event is tested against every enabled rule on the system.
  • Each rule runs a set of tests to check whether an event matches the rule.
  • Each test runs a series of comparisons to check whether an event matches the test.
There are two methods to consider to make the rule set more efficient:
  • Reduce the number of tests run
  • Reduce the number of complex tests run
Reducing the number of tests
Every time the CRE evaluates a rule, and its associated tests, it adds to the workload of the Rule Engine. It is best practice to reduce the number of potential tests run against each event.
There are two main ways the number of tests can be reduced:
  1. The first option is to ensure only rules that are needed are enabled on a system. Rules are created to detect certain symptoms. Over time your requirements can change, and certain rules can become redundant. It is good practice to regularly review the current rule set to ensure that unnecessary or unused rules are not contributing to processing time.
  2. The second option is to reduce the number of tests a rule runs. To clarify, this option does not refer to the number of tests a rule contains. When the CRE tests an event against a rule, the tests in the run are evaluated in sequential, descending order. If a rule fails a test, then the CRE ignores any remaining tests. For example, if a rule has 20 tests, but fails 99% of the time on the first test, then on average, the rule is running 1-1.2 tests and is considered efficient. The best practice is to ensure that the first 2-3 tests eliminate as many events as possible. To demonstrate the difference in number of tests practically, let’s look at the two following rules:
    1. Rule A has 4 tests and 1000 events to test.
      30% of the events pass the 1st test, 20% pass the 2nd test, and 10% pass the third test.

      1st Test – 1000 events tested.
      2nd Test – 300 events tested (30% of 1000)
      3rd Test – 60 events tested (20% of 300)
      4th Test – 6 events tested (10% of 60)

      Total tests for the rule = 1000 + 300 +60 + 6 = 1366
    2. Rule B has 4 tests and 1000 events to test.
      4% of the events pass the 1st test, 50% pass the 2nd test, and 20% pass the third test.

      1st Test – 1000 events tested.
      2nd Test – 40 events tested (4% of 1000)
      3rd Test – 20 events tested (50% of 40)
      4th Test – 4 events tested (20% of 20)

      Total tests for the rule = 1000 + 40 +20 + 4 = 1064
      Rule B ran fewer tests and so is more efficient.
Reducing the number of expensive tests
Each test consists of several comparisons, which the CRE carries out to check whether the event matches that test. Think of comparisons as the smallest basic component of a rule set. The rule set is made up of several rules, each of which contain a set of tests, which in turn are each made up of a number of comparisons.
Each test runs a number of comparisons to detect whether there is a match. The higher the number of comparisons run, the more complex the test. In each rule, the aim is to keep the number of comparisons as low as possible, to keep the rule efficient. The best practice is to put complex tests near the end of the rule stack, to ensure they are run as few times as possible.
Most rule tests are made of two components:
  • The data we want to detect (Called the pattern)
  • The data in the event we want to search (Called the string)
For example, in the following test:
The is the pattern we are trying to find, and the source IP is the string.
There are three simple guidelines that summarise a test’s complexity:
1) Type of test
There are three types of test that must be considered:
  • Exact Match tests
  • Contains Tests
  • Match Count Tests

Exact Match tests

For an exact match, the pattern and string must be identical.

If there is any difference between the pattern and the string, the test can be immediately failed.
For example, in the following test:
The remote port must be exactly 32007 to match. If the remote port is 2007, the rule does not trigger.
For exact matching tests, the maximum number of comparisons is:
Length of the String - Length of the Pattern + 1

Contains Tests

For a "contains" test, the pattern must be present somewhere in the string. Since this test type is a more open criteria, the CRE needs to perform a much greater number of comparisons.

The maximum number of comparisons is:
((Length of String - Length of Pattern) * Length of Pattern) + 1
Calculating the comparison count is not a requirement for setting up efficient rules but is a good concept to be aware of.
The "contains by" search is useful in certain tests, but where possible always use an exact match test.

Match Count Tests

Match Count tests look for a preset number of events in the required time period. There are two main types of match count test:

  • Rule and Building Block match counts, that test the event based on what rules, or building blocks it triggered.
  • Property match counts, that test the event based on it's event properties.
Example 1:
Rule match count tests are used to check whether an event matches another rule or Building Block.
For example, in the following rule:
If the event does not match the Log Source Test Building Block, the test fails and the CRE ceases testing the rule. If it passes, then the event is considered a partial match of the test. When the number of events matching this test reaches the threshold defined, the CRE will progress to the next test in the rule stack.
Example 2:
Property match count rules usually check for a recurring property, or differences in properties over time:
It is important to consider that with property match count tests, all events will partially match the test. To take the previous example, every event contains a Source IP, so every event can count for this test.
When a property match count is used, the CRE will always progress to test the next test in the rule stack. 
Therefore, it is best practice to put any property match count last in the rule stack.
2) Length of pattern or string
The longer the pattern or string, the longer the average time to complete the test. The following Rule contains a "Payload Contains" test:
Event Payloads, depending on their type, can be up to 32,000 characters in length. Most are between 1000-4000 characters, so 2500 characters is used in this example.
The pattern here is "license exceeded", which is 16 characters long.
The maximum number of comparisons = (2500 - 16) * 16 + 1 = 39,745
For this reason "Payload contains" type tests are not considered efficient.
3) Number of String or Patterns
The greater the number of patterns and strings to test, the longer the average time. An example of a test with multiple patterns is:
when the source IP is one of,,,,,,,,,,
In this test we have 10 patterns, each of which must be tested against the string (the source IP of the event).
The worst case of testing one of these patterns is about 31 comparisons. When testing 10 patterns, the worst case per event for this test = 31 * 10 = 310 comparisons.
Another example would be the following test:
For this test, the pattern is the event property specified, and the strings are each of the entries in reference set.
To take the following example, where the Full Usernames is a reference set containing 200,000 elements:
There are 2 patterns here, Username and Event Category, and 200,000 Strings, each of the entries in the Full Usernames reference set. Every pattern needs to be checked against every string until it is found.
Assuming the average number of comparisons per pattern and string check is 3:
The maximum number of comparisons = 3 comparisons * 2 patterns * 200,000 strings = 1,200,000 comparisons
Large reference sets are often a cause of expensive rules, so it is good practice to set a time to live on any reference sets you use. Our recommendation is to try to keep all reference sets with fewer than 100,000 elements.

Related Information

Document Location


[{"Type":"MASTER","Line of Business":{"code":"LOB24","label":"Security Software"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSV4BL","label":"IBM QRadar"},"ARM Category":[{"code":"a8m0z000000cwt3AAA","label":"QRadar Apps"}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"}]

Document Information

Modified date:
14 September 2023