QRadar Rules and Offenses

The greatest challenge for any security team across organizations is to receive informed alerts and then perform incident management. Now, what do we mean by informed alerts? In QRadar, we have discussed how data is collected (Chapter 4). What do we do with this data? We correlate this data against the rules that are defined in QRadar.

Rules are security conditions against which every event is matched. If the event matches the rule, the event is tagged with the rule name. If the rule conditions are matched, then an alert is generated. In QRadar, we call security alerts offenses. For every offense triggered, we correlate events and flows to break down and explain the offense. So, when it comes to offense analysis, the Security Operations Center (SOC) analyst wants to get relevant information about the offense or attack. Once the analyst has the information, the analyst can look up whether it has happened before. If it has happened before, there will be a...

Different types of QRadar rules

Rules are lists of security conditions that are defined. QRadar has hundreds of rules out of the box. These rules cater to different use cases for cyber-attacks. The use cases are derived from continuous cyber-attacks that happen around the world. The QRadar development team works on different security use cases and continues to add new rules. These rules are added to QRadar via auto updates (we will discuss auto updates later in this chapter). Along with the default rules in QRadar, QRadar users can also create new custom rules based on events, flows, common rules (both events and flows), and other offenses. These are the different types of rules in QRadar:

• Event rules: Rules are categorized based on what kind of data is required in the rule conditions. When events are evaluated against certain values, those rules are called event rules. These event rules will consist of different conditions for one or more events that happen in real time.
...

Understanding the Rule Wizard

As seen in Figure 7.1, there are options to create rules. When you click to create a new rule or click on the already available rules, the Rule Wizard opens. The following is a screenshot of what the Rule Wizard looks like. Notice that the rule has different components, such as rule name, rule definition, rule action, rule response, and so on.

Figure 7.2 – Rule Wizard – part 1

While creating rules, it is important to understand each component and how it can be used. Let’s dive in.

Rule name

When creating a new rule, you can mention the name of the rule you want to create. In Figure 7.2, the name of the rule is marked as Inbound Email with Suspicious Subject. The rule name should actually be a description of what the rule does. It is very similar to writing readable code for any programming language. We use the right kinds of variable names in a programming language so that our code remains readable...

What is historical rule correlation?

When you create a rule in QRadar, you would like to test the rule against sample data to understand the number of offenses created, the frequency of the offensees, and the performance impact on the system. The best way to test this is to create a rule and then run a historical correlation to test the rule. The historical correlation rule is run on past data. We can select the range of time for which data was collected to run the rule. For example, a newly created rule can be run on 6-month-old data. Usually, you should run the historical correlation during non-business hours so that the impact, if any, is minimal. Based on the results, you can further tune the rule.

Consider another scenario in which QRadar was down for some time because of, say, a system upgrade activity or any other reason. In such a scenario, we can run a historical correlation and generate the offenses that were lost if there are any.

Historical correlation is also used...

Offense generation and management

When the rule conditions match, the rule action triggers. It completely depends on the options selected in the rule action section for an offense to be generated.

Important note

If all the conditions match and if the indexed property is null, an offense is not generated. For example, if the indexed property is a destination port but the event that triggers the offense does not have a destination port value (the value is null), then the offense is not generated.

This note is for a specific design element with which QRadar ensures that no offense is generated even if rule conditions are matched.

Another peculiar design feature is offense-chaining. Offenses are chained together to provide analysts with a deeper understanding of the security incident. It binds one or more offenses based on the offense index field. This helps analysts relate multiple offenses just by looking at one chained offense. Offense-chaining saves analysts a lot of time...

Summary

In this chapter, we dug deep into the fundamental aspects of QRadar, which are rules and offenses. We discussed different types of rules and how these rules can be designed to meet security requirements. We dealt with the minute details of optimizing rules with building blocks and using reference data.

After going through this chapter, you should be in a position to implement security use cases using QRadar rules and offenses. You will be able to use different types of rules, generate alerts in the form of offenses, and manage those offenses.

In the next chapter, we will discuss how internal threats can be mitigated using a QRadar app called User Behavior Analytics.