IBM®
QRadar® includes
rules that detect a wide range of activities, including excessive firewall denies, multiple failed
login attempts, and potential botnet activity. You can also create your own rules to detect unusual
activity.
Before you begin
Before you create a new rule, you must have the
permission.
About this task
When you define rule tests, test against the smallest data possible. Testing in this way helps
rule test performance and ensures that you don't create expensive rules. To optimize performance,
start with broad categories that narrow the data that is evaluated by the rule test. For example,
start with a rule test for a specific log source type, network location, flow source, or context
(R2L, L2R, L2L). Any mid-level tests might include IP addresses, port traffic, or any other
associated test. The rule must test payload and regex expressions last.
Similar rules are grouped by category. For example, Audit, Exploit, DDoS, Recon, and more. When
you delete an item from a group, the rule or building block is only deleted from the group; it
remains available on the Rules page. When you delete a group, the rules or
building blocks of that group remain available on the Rules page.
Procedure
-
From the Offenses, Log Activity, or
Network Activity tabs, click Rules.
-
From the Display list, select Rules to create a
new rule.
- Optional:
From the Display list, select Building Blocks to
create a new rule by using building blocks.
-
From the Actions list, select a
rule type.
Each rule type tests against incoming data from different sources in real time. For example,
event rules test incoming log source data and offense rules test the parameters of an offense to
trigger more responses.
- In the Rule Wizard window, select the Skip this page when
running this rules wizard checkbox and click Next.
If
you select the Skip this page when running this rules wizard checkbox, the
Welcome page does not appear each time that you start.
-
On the Rule Test Stack Editor page,
in the Rule pane, type a unique name that you
want to assign to this rule in the Apply text
box.
-
From the list box, select Local or Global.
- If you select Local, all rules are processed on the Event Processor on which they were received
and offenses are created only for the events that are processed locally.
- If you select Global, all matching events are sent to the QRadar
Console for processing and therefore,
the QRadar
Console uses more bandwidth
and processing resources.
Learn more about Local and Global rules:
- Global rule tests
- Use global rules to detect things like "multiple user login failures" where the events from that
user might appear on multiple Event processors. For example, if you configured a
Local rule for five login failures in 10 minutes from the same username, all
5 of those login failures must appear on the same Event Processor. Therefore, if three login
failures were on one Event Processor and
2 were on another, no offense is generated. However, if you set this rule to
Global, it generates an offense.
-
From the Test Group list, select one or more tests that you want to add
to this rule. The CRE evaluates rule tests line-by-line in order. The first test is evaluated and
when true, the next line is evaluated until the final test is reached.
If you want to select the when the event matches this AQL filter
query test for a new event rule, click the add (+) icon. In the
Rule pane, click This and enter an AQL WHERE clause
query in the Enter an AQL filter query text box.
Learn more about using rules for events that are not detected:
The following rule tests can be triggered individually, but rule tests in the same rule test
stack are not acted upon.
- when the event(s) have not been detected by one or more of these log source types for
this many seconds
- when the event(s) have not been detected by one or more of these log sources for this
many seconds
- when the event(s) have not been detected by one or more of these log source groups
for this many seconds
These rule tests are not activated by an incoming event, but instead are activated when a
specific event is not seen for a specific time interval that you configured. QRadar uses a watcher
task that periodically queries the last time that an event was seen (last seen time), and
stores this time for the event, for each log source. The rule is triggered when the difference
between this last seen time and the current time exceeds the number of seconds that is configured in
the rule.
-
To export the configured rule as a building block to use
with other rules, click Export as Building Block.
-
On the Rule Responses page, configure the responses that you want this
rule to generate.
Learn more about rule response page parameters:
Table 1. Event ,
Flow and Common Rule, and Offense Rule Response page parameters
Parameter |
Description |
Severity |
Select this checkbox to assign a severity level to the event, where 0 is the
lowest and 10 is the highest. The severity is displayed in the Annotation pane
of the event details. |
Credibility |
Select this checkbox to assign credibility to the log source. For example, is
the log source noisy or expensive? The range is 0 (lowest) to 10 (highest) and the default is 10.
Credibility is displayed in the Annotation pane of the event details. |
Relevance |
Select this checkbox to assign relevance to the weight of the asset. For
example, how much do you care about the asset? The range is 0 (lowest) to 10 (highest) and the
default is 10. Relevance is displayed in the Annotation pane of the event
details. |
Bypass further rule correlation event |
Select this checkbox to match an event or flow to bypass all other rules in the
rule engine and prevent it from creating an offense. The event is written to storage for searching
and reporting.
|
Dispatch New Event |
Select this checkbox to dispatch a new event in addition to the original
event or flow, which is processed like all other events in the
system.
Dispatches a new event with the original event, and is processed like all other events in the
system.
The Dispatch New Event parameters are displayed when you select this
checkbox . By default, the checkbox is clear.
|
Email |
Select this checkbox to change the Email Locale setting
from the System Settings on the Admin tab. |
Send to Local Syslog |
Select this checkbox to log the event or
flow locally.
By default, this checkbox is clear.
Note: Only normalized events can be logged locally on an appliance. If you want to send raw event
data, you must use the Send to Forwarding Destinations option to send the data to a remote syslog
host.
|
Send to Forwarding Destinations |
Select this checkbox to log the event or flow on a
forwarding destination.
A forwarding destination is a vendor system, such as SIEM, ticketing, or alerting systems. When
you select this checkbox, a list of forwarding destinations is displayed.
To add, edit, or delete a forwarding destination, click the Manage
Destinations link.
|
Notify |
Select this checkbox to display events that are generated as a result of this rule in the System
Notifications item on the Dashboard tab.
If you enable notifications, configure the Response Limiter parameter.
|
Add to Reference Set |
Select this checkbox to add events that are generated as a result of this rule to a reference
set. You must be an administrator to add data to a reference set.
To add data to a reference set, follow these steps:
- From the first list, select the property of the event or flow that you want to add.
- From the second list, select the reference set to which you want to add the specified data.
|
Add to Reference Data |
To use this rule response, you must create the reference data collection.
|
Remove from Reference Set |
Select this checkbox to remove data from a reference set.
To remove data from a reference set:
- From the first list box, select the property of the event or flow that you want to remove.
Options include all normalized or custom data.
- From the second list box, select the reference set from which you want to remove the specified
data.
The Remove from Reference Set rule response provides the following function:
- Refresh
- Click Refresh to refresh the first list box to ensure that the list is
current.
|
Remove from Reference Data |
To use this rule response, you must have a reference data collection.
|
Execute Custom Action |
Select this checkbox to write scripts that do specific actions in response to
network events. For example, you might write a script to create a firewall rule that blocks a
particular source IP address from your network in response to repeated login failures. You add and
configure custom actions by using the Define Actions icon on the
Admin tab.
|
Response Limiter |
Select this checkbox to configure the frequency in which you want this rule to
respond. |
An SNMP notification might resemble the following example:
"Wed Sep 28 12:20:57 GMT 2005, Custom Rule Engine Notification -
Rule 'SNMPTRAPTst' Fired. 172.16.20.98:0 -> 172.16.60.75:0 1, Event Name:
ICMP Destination Unreachable Communication with Destination Host is
Administratively Prohibited, QID: 1000156, Category: 1014, Notes:
Offense description"
A syslog output might resemble the following example:
Sep 28 12:39:01 localhost.localdomain ECS:
Rule 'Name of Rule' Fired: 172.16.60.219:12642
-> 172.16.210.126:6666 6, Event Name: SCAN SYN FIN, QID:
1000398, Category: 1011, Notes: Event description
What to do next
To test your rules, run Historical correlation.
To verify that the event triggers the rule test based on your building block, you can create an
email response, see Sending email notifications.