Chapter 1: Offense Analysis

QRadar uses rules to monitor the events and flows in your network to detect security
threats. When the events and flows meet the test criteria that is defined in the rules, an
offense is created to show that a security attack or policy breach is suspected. But knowing
that an offense occurred is only the first step. Offense Analysis is all about initially
identifying how it happened, where it happened, and who are the players involved in the
offense.
TASK: 1.1 Triage initial offense

1.1.1 Open an offense to view the details

- Identify the status of the offense
- Identify the last event/flow contributed to the offense

1.1.2 Review offense source and destination

- Identify the attack based on description.
- Using source IP and location, identify the source or origin of the attack
- Identify the destination IPs or target system involved in the attack

1.1.3 Review vulnerability and evidence

- Check the vulnerability status of the targets
- Identify the events associated or contributed to the offense
- If the offense is validated as false positive, close the offense with the appropriate closing
reason

Offense investigations
IBM® QRadar® uses rules to monitor the events and flows in your network to detect
security threats. When the events and flows meet the test criteria that is defined in the
rules, an offense is created to show that a security attack or policy breach is suspected.
But knowing that an offense occurred is only the first step; identifying how it happened,
where it happened, and who did it requires some investigation.
The Offense Summary window helps you begin your offense investigation by providing
context to help you understand what happened and determine how to isolate and resolve
the problem.
QRadar does not use device level user permissions to determine which offenses each user
is able to view. All users who have access to the network can view all offenses regardless of
which log source or flow source is associated with the offense.

Selecting an offense to investigate

The Offenses tab shows the suspected security attacks and policy breaches that are
occurring on your network. Offenses are listed with the highest magnitude first.
Investigate the offenses at the top of the list first.

About this task

Use the navigation options on the left to view the offenses from different perspectives. For
example, select By Source IP or By Destination IP to view information about repeat
offenders, IP addresses that generate many attacks, or systems that are continually under
attack. You can further refine the offenses in the list by selecting a time period for the
offenses that you want to view or by changing the search parameters.
You can also search for offenses that are based on various criteria. For more information
about searching offenses, see Offense searches.
Procedure
• Click the Offenses tab.
• On the navigation menu, select the category of offenses that you want to view.
• Optional: Depending on the category that you selected, you may be able to select the
following filtering options:
• From the View Offenses list, select an option to filter the list of offenses for a
specific time frame.
• In the Current Search Parameters pane, click Clear Filter links to refine
the list of offenses.
• To view all global offenses that are occurring on the network, click All Offenses.
• To view all offenses that are assigned to you, click My Offenses.
• To view offenses grouped on the high-level category, click By Category.
• To view low-level category groups for a particular high-level category, click
the arrow icon next to the high-level category name.
• To view a list of offenses for a low-level category, double-click the low-level
category.
Count fields, such as Event/Flow Count and Source Count do not consider
the network permissions of the user.
• To view offenses grouped by source IP address, click By Source IP.
The list of offenses displays only source IP addresses with active offenses.
• Double-click the Source IP group that you want to view.
• To view a list of local destination IP addresses for the source IP address,
click Destinations on the Source page toolbar.
• To view a list of offenses that are associated with this source IP address,
click Offenses on the Source page toolbar.
• To view offenses grouped by destination IP address, click By Destination IP.
 • Double-click the Source IP address group that you want to view.
• To view a list of offenses that are associated with the destination IP address,
click Offenses on the Destination page toolbar.
• To view a list of source IP addresses associated with the destination IP
address, click Sources on the Destination page toolbar.
• To view offenses grouped by network, click By Network.
• Double-click the Network that you want to view.
• To view a list of source IP addresses associated with this network,
click Sources on the Network page toolbar.
• To view a list of destination IP addresses associated with this network,
click Destinations on the Network page toolbar.
• To view a list of offenses that are associated with this network,
click Offenses on the Network page toolbar.
• Double-click the offense to see additional information.
Investigating an offense by using the summary information
The Offense Summary window provides the information that you need to investigate an
offense in IBM® QRadar®. The information that is most important to you during your
investigation might be different, depending on the type of offense that you are
investigating.
To make it easier for you to investigate an offense, the bottom of the Offense
Summary page groups information about top contributors to the offense. These
fields show only the most recent or most important pieces of information in that
category. Many fields show more information when you hover the mouse over them.
Some fields have right-click menu options.
Procedure
• Click the Offenses tab and double-click the offense that you want to investigate.
The Offense Summary window opens.
• Review the first row of data to learn about the level of importance
that QRadar assigned to the offense.
Learn more about the magnitude rating:
ParameterDescription

MagnitudeIndicates the relative importance of the offense. This value is calculated based
on the relevance, severity, and credibility ratings.

Status Hover your mouse over the status icon to see the status.

QRadar does not display a status icon when an offense is active.

Relevance Indicates the importance of the destination.

QRadar determines the relevance by the weight that the administrator

assigned to the networks and assets.
Severity Indicates the threat that an attack poses in relation to how prepared the
destination is for the attack.
 CredibilityIndicates the integrity of the offense as determined by the credibility rating that
is configured in the log source. Credibility increases as multiple sources report
the same event. QRadar administrators configure the credibility rating of log
sources.

• Review the information in the top portion of the Offense Summary window to
learn more about the type of attack and the timeframe when it occurred.
Learn more about the offense information:
Parameter Description

DescriptionShows the cause of the offense.

Chained offenses show Preceded by, indicating that the offense changed
over time as new events and flows were added to offense.
Offense The offense type is determined by the rule that created the offense. The
Type offense type determines what type of information is displayed in
the Offense Source Summary pane.
Event/Flow To see the list of events and flows that contributed to the offense, click
count the Event or Flow links.

If the flow count displays N/A, the offense might have a start date that
precedes the date when you upgraded to IBM QRadar version 7.1 (MR1).
The flows cannot be counted, but you can click the N/A link to
investigate the flows.
Source
Specifies the device that attempts to breach the security of a component
IP(s)
on your network. The device can have an IPv4 or IPv6 address.
Offenses of type Source IP always originate from only one source IP
address. Offenses of other types can have more than one source IP
address. You can see more information about the source IP address by
hovering the mouse over the address, or by using right-click and left-
click mouse actions.
Destination
Specifies the network device that the source IP address attempted to
IP(s)
access. The network device can have an IPv4 or IPv6 address.
If the offense has only one target, the IP address is displayed. If the
offense has multiple targets, the number of local or remote IP addresses
that were targeted. You can see more information by hovering the
mouse over the address, or by using right-click and left-click mouse
actions.
Start Specifies the date and time when the first event or flow occurred for the
offense.

Duration Specifies the amount of time that elapsed since the first event or flow that is
associated with the offense was created.

Network(s) Specifies the local networks of the local destination IP addresses that were
targeted. QRadar considers all networks that are specified in the network
 hierarchy as local. The system does not associate remote networks to an
offense, even if they are specified as a remote network or a remote service on
the Admin tab.

• In the Offense Source Summary window, review the information about the source
of the offense.
The information that is shown in the Offense Source Summary window depends
on the Offense Type field.
Learn more about the source summary information:
Parameter Description

Chained
Specifies whether the destination IP address is chained.
A chained IP address is associated with other offenses. For example, a
destination IP address might become the source IP address for
another offense. If the destination IP address is chained, click Yes to
view the chained offenses.
Destination
Specifies the network device that the source IP address attempted to
IP(s)
access. The network device can have an IPv4 or IPv6 address.
If the offense has only one target, the IP address is displayed. If the
offense has multiple targets, this field shows the number of local or
remote IP addresses that were targeted. You can see more
information by hovering the mouse over the address, or by using
right-click and left-click mouse actions.
Location Specifies the network location of the source or destination IP address. If the
location is local, click the link to view the networks.

Magnitude Specifies the relative importance of the source or destination IP address.

The magnitude bar provides a visual representation of the CVSS risk

value of the asset that is associated with the IP address. Hover your
mouse over the magnitude bar to display the calculated magnitude.
Severity Specifies the severity of the event or offense.

Severity specifies the level of threat that an offense poses in relation

to how prepared the destination IP address is for the attack. This
value is directly mapped to the event category that correlates to the
offense. For example, a Denial of Service (DoS) attack has a severity
of 10, which specifies a severe occurrence.
Source IP(s)
Specifies the device that attempted to breach the security of a
component on your network. The device can have an IPv4 or IPv6
address.
Offenses of type Source IP always originate from only one source IP
address. Offenses of other types can have more than one source IP
address. You can see more information about the source IP address
 by hovering the mouse over the address, or by using right-click and
left-click mouse actions.
Username Specifies the user name that is associated with the event or flow that
created the offense.

Hover your mouse over the user name to see the most recent
information in the asset model database for the user.
Events that do not include a user name in the payload, or system-
generated events that belong to a local computer or a system account,
show Unknown.
To access more information that is associated with a selected user
name, right-click the user name for View Assets and View
Events menu options.
VulnerabilitiesSpecifies the number of identified vulnerabilities that are associated with
the source or destination IP address. This value also includes the number of
active and passive vulnerabilities.

When you view the summary information for historical offenses, the Last
Known data fields are not populated.
• In the bottom portion of the Offense Summary window, review additional
information about the offense top contributors, including notes and annotations that
are collected about the offense.
To see all the information that QRadar collected in a category, click the links on the
right side of the category heading.
Learn more about the information presented in the offense details:
Offense
details
category Description

Last 5 Notes Use notes to track important information that is gathered during the offense
investigation. You can add a note to an offense, but you cannot edit or delete
notes.

Top 5 Shows the top 5 IP addresses with the highest magnitude, which is where the
Source IPs suspected attack or policy breach originated.

Offenses that have only one source IP address show only one entry in
the table.
Top 5 Shows the top 5 local IP addresses with the highest magnitude, which might
Destination indicate the target of the attack. Offenses that target less than 5 local IP
IPs addresses show fewer entries in the table.

The Chained column indicates whether the destination IP address is the

source IP address of another offense. A Yes in this column indicates that
an attacker has control over the system with this IP address and is using
it to attack other systems.
The Magnitude column shows the aggregate Common Vulnerability
 Scoring System (CVSS) score when it exists. When no CVSS score is
available, the column shows the highest magnitude of all the offenses
that the IP address is a part of.
When you hover the mouse over the destination IP address,
the Destination Magnitude shows the CVSS score. When no CVSS score
is available, a zero is displayed.
Top 5 Log Shows the log sources that contribute the most events to the offense.
Sources
The Custom Rule Engine (CRE) creates an event and adds it to the
offense when the test criteria that is specified in the custom rule
matches the incoming event. A log source that displays Custom Rule
Engine in the Description field indicates that QRadar created the
events from that log source.
Total Events shows the sum of all the events that are received from this
log source while the offense was active.
Top 5 Users Events must include user information in order for QRadar to populate this
table.

Top 5 Shows the low-level categories that have the most events that contributed to
Categories the offense.

Local Destination Count shows the number of local destination IP

addresses affected by offenses with events in the category. When all
destination IP addresses are remote, this field shows 0.
Last 10 Shows information about the last 10 events that contributed to the offense.
Events

Last 10 Shows information about the last 10 flows that contributed to the offense.
Flows
The Total Bytes column shows the sum of the bytes transferred in both
directions.
AnnotationsAnnotations provide insight into why QRadar considers the event or observed
traffic to be threatening.

QRadar can add annotations when it adds events or flows to an offense.

The oldest annotation shows information that QRadar added when the
offense was created. Users cannot add, edit, or delete annotations.
Last 5 Shows information about the results from the last five scheduled searches.
Search
Results

• If you installed IBM QRadar Risk Manager, click View Attack Path to see which
assets in your network are communicating to allow an offense to travel through the
network.
Investigating events
An event is a record from a log source, such as a firewall or router device, that describes an
action on a network or host. Events that are associated with an offense provide evidence
that suspicious activity is happening on your network. By examining the event data, you
can understand what caused the offense and determine how best to isolate and mitigate the
threat.

About this task

Some events are created based on an incoming raw event, while others are created by
the QRadar® Custom Rule Engine (CRE). Events that are created by QRadar do not have a
payload because they are not based on raw events.
Procedure
• In the Offense Summary window, click Events.
The List of Events window shows all events that are associated with the offense.
• Specify the Start Time, End Time, and View options to view events that occurred
within a specific time frame.
• Click the event column header to sort the event list.
• In the list of events, right-click the event name to apply quick filter options to reduce
the number of events to review.
You can apply quick filters to other columns in the event list as well.
• Double-click an event to view the event details.
The Event Information and the Source and Destination Information window
show only the information that is known about the event. Depending on the type of
event, some fields might be empty.
Learn more about the time fields on the Event Information:
Field Description

Start The time that QRadar received the raw event from the log source.
Time

StorageThe time that QRadar stored the normalized event.

Time

Log The time that is recorded in the raw event from the log source.
Source
Time

• In the Payload Information box, review the raw event for information
that QRadar did not normalize.
Information that is not normalized does not appear in the QRadar interface, but it
may be valuable to your investigation
Investigating flows:
IBM® QRadar® correlates flows into an offense when it identifies suspicious activity in
network communications. The flow analysis provides visibility into layer 7, or the
application layer, for applications such as web browsers, NFS, SNMP, Telnet, and FTP. A
flow can include information such as IP addresses, ports, applications, traffic statistics, and
packet payload from unencrypted traffic.
By default, QRadar tries to extract normalized fields and custom flow properties from the
first 64 bytes of flow data, but administrators can increase the content capture length to
collect more data.
• In the Offense Summary window, click Flows in the upper right menu. The Flow
List window shows all flows that are associated with the offense.
• Specify the Start Time, End Time, and View options to view flows that occurred within a
specific time frame.
• Click the flow column header to sort the flow list.
• In the list of flows, right-click the flow name to apply quick filter options to reduce the
number of flows to review. You can apply quick filters to other columns in the flow list as
well.
• Double-click a flow to review the flow details.

Protecting offenses
You might have offenses that you want to retain regardless of the retention period. You can
protect offenses to prevent them from being removed from QRadar® after the retention
period has elapsed.

About this task

By default, offenses are retained for thirty days. For more information about customizing
the offense retention period, see the IBM QRadar Administration Guide.
Procedure
• Click the Offenses tab, and click All Offenses.
• Choose one of the following options:
• Select the offense that you want to protect, and then select Protect from
the Actions list.
• From the Actions list box, select Protect Listed.
• Click OK.
Results
The offense is protected and will not be removed from QRadar. In the Offense window, the
protected offense is indicated by a Protected icon in the Flag column
Unprotecting offenses
You can unprotect offenses that were previously protected from removal after the offense
retention period has elapsed.

About this task

To list only protected offenses, you can perform a search that filters for only protected
offenses. If you clear the Protected check box and ensure that all other options are selected
under the Excludes option list on the Search Parameters pane, only protected offenses are
displayed.
Procedure
• Click the Offenses tab.
• Click All Offenses.
• Optional: Perform a search that displays only protected offenses.
• Choose one of the following options:
• Select the offense that you no longer want to protect, and then
select Unprotect from the Actions list box.
• From the Actions list box, select Unprotect Listed.
• Click OK

Offense chaining:
IBM® QRadar® chains offenses together to reduce the number of offenses that you need to
review, which reduces the time to investigate and remediate the threat.
Offense chaining helps you find the root cause of a problem by connecting multiple
symptoms together and showing them in a single offense. By understanding how an offense
changed over time, you can see things that might be overlooked during your analysis. Some
events that would not be worth investigating on their own might suddenly be of interest
when they are correlated with other events to show a pattern.
Offense chaining is based on the offense index field that is specified on the rule. For
example, if your rule is configured to use the source IP address as the offense index field,
there is only one offense that has that source IP address for while the offense is active.
You can identify a chained offense by looking for preceded by in the Description field on
the Offense Summary page. In the following example, QRadar combined all of the events
that fired for each of the three rules into one offense, and appended the rule names to
the Description field:

Exploit Followed By Suspicious Host Activity - Chained

preceded by Local UDP Scanner Detected
preceded by XForce Communication to a known Bot Command and Control
Q: How long are offenses active in QRadar?
Offenses in QRadar:
Offenses in QRadar can be retained indefinitely, if they are not closed or inactive.
After the initial offense rule has fired, the offense is marked as active in QRadar. QRadar®
checks every 10 minutes to see whether new events have been added to the offense. In
this state, the offense is waiting for new event or flows to hit the Offense Rule test. If new
events have been detected, the offense clock is reset to keep the offense as active for
another 30 minutes. QRadar will mark an offense as dormant if no new events or flows
occur after 30 minutes. We will also mark flow offense as dormant if we have not
processed any events after 4 hours.

Offenses Retention:
QRadars dormancy period lasts 5 days. After these 5 days, an offense is marked as
inactive. New events triggering the Offense rule test will not contribute to the inactive
offense. Our Offense Model checks each day within these 5 days to determine which
offenses are still dormant and which are inactive. If an event is received during the
dormant time, the dormant time is reset back to zero. You will have to wait another 5
days of no events or flows triggering the rule test in order for the offense to become
inactive.

Note: By default, the system allows 2,500 open (active) offenses and 100,000 (inactive)
offenses. If these values are reached, a System Notification is generated to alert the
administrator that they might need to review offenses that can be closed or tune rules to
reduce the overall number of offenses that are being generated in QRadar. By default the
system will begin to remove 0.05 percent all inactive offenses every 2 hours.

Offenses Maintenance:
When an offense is closed either by manually closing an offense or by magistrate, which
makes the offense inactive, the Offense Retention Period setting is then applied. The
Offense Retention Period determines how long inactive offenses are kept before being
purged from the Console.
The administrator can manage offenses from Admin tab > Advanced> Clean SIM
Model. The options include:
• Soft Clean - this option closes all offenses, but does not remove them from
QRadar.
• Hard Clean - this option closes and removes all offenses from the system. It is not
advised to Hard Clean your SIM Model, unless advised by QRadar Support.

TASK: 1.2 Analyze fully matched and partially matched rules

1.2.1 From the Offense Summary, In Event/Flow Count, click on the events/flows to view all the
contributed logs.
- Analyze the different types of events by event name, low level category, high level category
1.2.2 Select the event that can provide more evidence for the offense
- In the Event details -> Additional Information -> look for custom rule and custom rules
partially matched
1.2.3 Analyze the rules and building blocks contributed/triggered the offense
Rules
Rules, sometimes called correlation rules are applied to events, flows, or offenses to search
for or detect anomalies. If all the conditions of a test are met, the rule generates response.

What are rules?

Custom rules test events, flow, and offenses to detect unusual activity in your network. You
create new rules by using AND and OR combinations of existing rule tests. Anomaly
detection rules test the results of saved flow or events searches to detect when unusual
traffic patterns occur in your network. Anomaly detection rules require a saved search that
is grouped around a common parameter.

What are building blocks?

A building block is a collection of tests that don't result in a response or an action.
A building block groups commonly used tests to build complex logic so that it can be reused
in rules. A building block often tests for IP addresses, privileged user names, or collections
of event names. For example, a building block can include the IP addresses of all DNS
servers. Rules can then use this building block.
QRadar® has default rules and you can also download more rules from the IBM® Security
App Exchange to create new rules.
How do rules work?
QRadar Event Collectors gather events from local and remote sources, normalize these
events, and classify them into low-level and high-level categories. For flows, QRadar QFlow
Collectors read packets from the wire or receive flows from other devices and then
converts the network data to flow records. Each Event Processor processes events or flow
data from the QRadar Event Collectors. Flow Processors examine and correlate the
information to indicate behavioral changes or policy violations. The custom rules engine
(CRE) processes events and compares them against defined rules to search for anomalies.
When a rule condition is met, the Event Processor generates an action that is defined in the
rule response. The CRE tracks the systems that are involved in incidents, contributes
events to offenses, and generates notifications.
How is an offense created from a rule?
QRadar creates an offense when events, flows, or both meet the test criteria that is
specified in the rules.
QRadar analyzes the following information:

• Incoming events and flows

• Asset information
• Known vulnerabilities
The rule that created the offense determines the offense type.
The magistrate prioritizes the offenses and assigns the magnitude value based on several
factors, including number of events, severity, relevance, and credibility.
Note: Building blocks are tested before rules are tested.
For example, you have a building block that is defined to trigger an offense on high
magnitude events. The log activity can show that there were high magnitude events, but no
offense was triggered. This can happen because when the building block was tested, the
events was not at high magnitude. The magnitude of the event did not increase until the
rules were tested.
One solution is to set a rule to check for the different in Severity, Credibility, and Relevance
rather than to use a building block.

Custom rules
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.
What are custom rules?
Customize default rules to detect unusual activity in your network.

Rule types
Each of the event, flow, common, and offense rule types test against incoming data from
different sources in real time. There are multiple types of rule tests. Some check for
simple properties from the data set. Other rule tests are more complicated. They track
multiple, event, flow, and offense sequences over a period of time and use "counter" that
is on one or more parameters before a rule response is triggered.
Event rules
Test against incoming log source data that is processed in real time by the QRadar Event
Processor. You create an event rule to detect a single event or event sequences. For
example, to monitor your network for unsuccessful login attempts, access multiple hosts,
or a reconnaissance event followed by an exploit, you create an event rule. It is common
for event rules to create offenses as a response.
Flow rules
Test against incoming flow data that is processed by the QRadar Flow Processor. You can
create a flow rule to detect a single flow or flow sequences. It is common for flow rules to
create offenses as a response.
Common rules
Test against event and flow data. For example, you can create a common rule to detect
events and flows that have a specific source IP address. It is common for common rules to
create offenses as a response.
Offense rules
 Test the parameters of an offense to trigger more responses. For example, a response
generates when an offense occurs during a specific date and time. An offense rule
processes offenses only when changes are made to the offense. For example, when new
events are added, or the system scheduled the offense for reassessment. It is common for
offense rules to email a notification as a response.

Managing rules
You can create, edit, assign rules to groups, and delete groups of rules. By categorizing your
rules or building blocks into groups, you can efficiently view and track your rules. For
example, you can view all rules that are related to compliance.

Domain-specific rules
If a rule has a domain test, you can restrict that rule so that it is applied only to events that
are happening within a specified domain. An event that has a domain tag that is different
from the domain that is set on, the rule does not trigger a response.
To create a rule that tests conditions across the entire system, set the domain condition
to Any Domain.
Rule conditions
Most rule tests evaluate a single condition, like the existence of an element in a reference
data collection or testing a value against a property of an event. For complex comparisons,
you can test event rules by building an Ariel Query Language (AQL) query with WHERE
clause conditions. You can use all of the WHERE clause functions to write complex criteria
that can eliminate the need to run numerous individual tests. For example, use an AQL
WHERE clause to check whether inbound SSL or web traffic is being tracked on a reference
set.
You can run tests on the property of an event, flow, or offense, such as source IP address,
severity of event, or rate analysis.
With functions, you can use building blocks and other rules to create a multi-event, multi-
flow, or multi-offense function. You can connect rules by using functions that support
Boolean operators, such as OR and AND. For example, if you want to connect event rules,
you can use when an event matches any|all of the following rules function
Creating a custom rule
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 Offenses > Maintain Custom
Rules 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 should 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 this rule for 5 login failures in 10 minutes from the same user name, and
set as a Local rule, all 5 of those login failures must appear on the same Event
Processor. Therefore, if 3 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:
Parameter Description

Bypass
further rule Forces the matched event or flow to bypass all other rules in the rule
correlation engine and prevents it from creating an offense. The event is written to
event storage for searching and reporting.

Select this check box to dispatch a new event in addition to the original
event or flow, which is processed like all other events in the system.
Dispatch Dispatches a new event with the original event, and is processed like all
New Event other events in the system.

The Dispatch New Event parameters are displayed when you select this
check box. By default, the check box is clear.
The severity level that you want to assign to the event, where 0 is the lowest
Severity and 10 is the highest. The severity is displayed in the Annotation pane of the
event details.

The credibility that you want to assign to the log source. For example, is the log
source noisy or expensive? The range is 0 (lowest) to 10 (highest) and the
Credibility
default is 10. Credibility is displayed in the Annotation pane of the event
details.
 The relevance that you want to assign to the weight of the asset. For example,
how much do you care about the asset? The range is 0 (lowest) to 10 (highest)
Relevance
and the default is 10. Relevance is displayed in the Annotation pane of the
event details.

Email To change the Email Locale setting, select System Settings on the Admin tab.

Enter email
addresses toUse a comma to separate multiple email addresses.
notify

Enable this function to send an SNMP notification (trap).

SNMP Trap The SNMP trap output includes system time, the trap OID, and the
notification data, as defined by the MIB. You can access the MIB
from /opt/qradar/conf/Q1LABS-MIB.txt.
If you want to log the event or flow locally, select this check box.
Send to By default, this check box is clear.
Local Note: Only normalized events can be logged locally on an appliance. If you
SysLog want to send raw event data, you must use the Send to Forwarding
Destinations option to send the data to a remote syslog host.

If you want to log the event or flow on a forwarding destination, select

this check box.
Send to A forwarding destination is a vendor system, such as SIEM, ticketing, or
Forwarding alerting systems. When you select this check box, a list of forwarding
Destinationsdestinations is displayed.

To add, edit, or delete a forwarding destination, click the Manage

Destinations link.
Displays events that generate as a result of this rule to be displayed in
Notify the System Notifications item on the Dashboard tab.
If you enable notifications, configure the Response Limiter parameter.
Adds 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.
Add to To add data to a reference set, follow these steps:
Reference
• From the first list, select the property of the event or flow
Set
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 To use this rule response, you must create the reference data collection.
Data
 If you want this rule to remove data from a reference set, select this
check box.
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
Remove normalized or custom data.
from
• From the second list box, select the reference set from
Reference
which you want to remove the specified data.
Set
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 To use this rule response, you must have a reference data collection.
Data

You can 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
Execute
particular source IP address from your network in response to repeated login
Custom
failures.
Action
You add and configure custom actions by using the Define Actions icon
on the Admin tab.
Publish on
If the IF-MAP parameters are configured and deployed in the system settings,
the IF-MAP
select this option to publish the event information about the IF-MAP server.
Server

Response
Configures the frequency in which you want this rule to respond.
Limiter

If you want the Event Name information to contribute to the name of

the offense, select the This information should contribute to the
name of the offense option.
Offense If you want the configured Event Name to be the name of the offense, select
Name the This information should set or replace the name of the offense option.
Note: This option does not rename existing offenses. To rename an existing
offense, you must use the Offense Rule option This information should set or
replace the name of the offense.

Table 1. Event , Flow and Common Rule, and Offense Rule Response page parameters

An SNMP notification might resemble:

 "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:
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

Configuring an event or flow as false positive

You might have legitimate network traffic that triggers false positive flows and events
that makes it difficult to identify true security incidents. You can prevent events and
flows from correlating into offenses by configuring them as false positives.

Procedure
• From the, Log Activity, or Network Activity tabs, click the pause on the upper right
to stop real-time streaming of events or flows.
• Select the event that you want to tune.
• Click False Positive.
• Select an event or flow property option.
• Select a traffic direction option.
• Click Tune.
Results
The event or flow that matches the specified criteria will no longer correlates into offenses.
To edit false positive tuning, use the User-BB_FalsePositive: User Defined Positive
Tunings building block in the Rules section on the Offenses tab
Anomaly detection rules
Anomaly detection rules test the results of saved flow or events searches to detect when
unusual traffic patterns occur in your network.
Anomaly detection rules require a saved search that is grouped around a common
parameter, and a time series graph that is enabled. Typically the search needs to
accumulate data before the anomaly rule returns any result that identifies patterns for
anomalies, thresholds, or behavior changes.

Anomaly rules
Test event and flow traffic for changes in short-term events when you are comparing
against a longer timeframe. For example, new services or applications that appear in a
network, a web server crashes, firewalls that all start to deny traffic.
Example: You want to be notified when one of your firewall devices is reporting more often than it
usually does because your network might be under attack. You want to be notified when you
receive twice as many events in 1 hour. You follow these steps:

• Create and save a search that groups by log source, and displays only the count
column.
• Apply the saved search to an anomaly rule, and add the rule test, and when the
average value (per interval) of count over the last 1 hour is at
least 100% different from the average value (per interval) of the same
property over the last 24 hours.

Threshold rules
Test events or flows for activity that is greater than or less than a specified range. Use these
rules to detect bandwidth usage changes in applications, failed services, the number of
users connected to a VPN, and detecting large outbound transfers.
Example: A user who was involved in a previous incident has large outbound transfer.

When a user is involved in a previous offense, automatically set the Rule response to add to
the Reference set. If you have a watch list of users, add them to the Reference set. Tune
acceptable limits within the Threshold rule.
A reference set, WatchUsers, and Key:username are required for your search.
Complete the following search, and then apply it to a Threshold rule.
select assetuser(sourceip, now()) as 'srcAssetUser',
Applicationname(applicationid)as 'AppName', long(sum(sourcebytes
+destinationbytes)) as 'flowsum' from flows where flowdirection = 'L2R' and
REFERENCESETCONTAINS('Watchusers', username)group by 'srcAssetUser',
applicationid order by 'flowsum' desc last 24 hours
Behavioral rules
Test events or flows for volume changes that occur in regular patterns to detect outliers.
For example, a mail server that has an open relay and suddenly communicates with many
hosts, or an IPS (intrusion protection system) that starts to generate numerous alert
activities.
A behavioral rule learns the rate or volume of a property over a pre-defined season. The
season defines the baseline comparison timeline for what you're evaluating. When you set
a season of 1 week, the behavior of the property over that 1 week is learned and then you
use rule tests to alert you to any significant changes.
After a behavioral rule is set, the season adjusts automatically. When the data in the season
is learned, it is continually evaluated so that business growth is profiled within the season;
you do not have to change your rules. The longer a behavioral rule runs, the more accurate
it becomes. You can then adjust the rule responses to capture more subtle changes.
The following table describes the behavioral rule test parameter options.
Rule test
Description
parameter

The most important value. The season defines the baseline behavior of the
property that you are testing and which the other rule tests use. To define a
season, consider the type of traffic that you are monitoring. For example, for
Season network traffic or processes that include human interaction, 1 week is a good
season timeframe. For tracking automated services where patterns are
consistent, you might want to create a season as short as 1 day to define that
pattern of behavior.

Weight of the original data with seasonal changes and random error accounted
Current for. This rule test asks the question, "Is the data the same as yesterday at the
traffic level same time?"
The weight must be in the range of 1 to 100. A higher value places more weight
on the previously recorded value.

Weight of changes in the data for each time interval. This rule test asks the
Current question, "How much does the data change when it compares this minute to the
traffic minute before?"
trend
The weight must be in the range of 1 to 100. A higher value places more weight
on traffic trends than the calculated behavior.

Weight of the seasonal effect for each period. This rule test asks the question,
Current "Did the data increase the same amount from week 2 to week 3, as it did from
traffic week 1 to week 2?"
behavior
The weight must be in the range of 1 to 100. A higher value places more weight
on the learned behavior.

Use predicted values to scale baselines to make alerting more or less sensitive.
Predicted
The sensitivity must be in the range of 1 to 100. A value of 1 indicates that the
value
measured value cannot be outside the predicted value. A value of 100 indicates
that the traffic can be more than four times larger than the predicted value.
Table 1. Behavioral rule test definitions

The forecast for value from (n+1)th interval is calculated by using the following formula:
Fn+1 = B n + T n + Tn+1-s
Where F is the predicted value, B is the base value for interval n, T is the trend value for
interval n, and T is the trend value for season intervals ago and s is the number of intervals
within the season.
The base value is calculated by using the following formula:
Bn+1 = (0.2 + 0.3*( <Current traffic level> / 100.0))*(value n+1 – T n+1-s) + (1 – (0.2 + 0.3*( <Current traffic level>
/ 100.0)))*T n
The trend value is calculated by using the following formula:
Tn+1 = (0.2 + 0.3*( <Current traffic trend> / 100.0))*(B n+1 - Bn) + (1 - (0.2 + 0.3*(<Current traffic trend> /
100.0)))*Tn
Smoothed deviation D is calculated by using the following formula:
Dn+1 = (0.2 + 0.3*( <Current traffic behavior> / 100.0))*|value n+1 – Fn+1| + (1 – (0.2 + 0.3*( <Current traffic
behavior> / 100.0)))*D n+1-s

The behavioral rule produces an alert for the interval if the following expression is false:
F – (1 + ( sensitivity / 100.0)*3)*D <= value <= F + (1 + ( sensitivity / 100.0)*3)*D
During the first season, the behavioral rule learns for future calculations and doesn't
produce any alerts.

Creating an anomaly detection rule

Anomaly detection rules test the result of saved flow or event searches to search for
unusual traffic patterns that occur in your network. Behavioral rules test event and flow
traffic according to "seasonal" traffic levels and trends. Threshold rules test event and flow
traffic for activity less than, equal to, or greater than a configured threshold or within a
specified range.

Before you begin

To create anomaly detection rules on the Log Activity tab, you must have the Log
Activity Maintain Custom Rules role permission.
To create anomaly detection rules on the Network Activity tab, you must have
the Network Activity Maintain Custom Rules role permission.
To manage default and previously created anomaly detection rules, use the Rules page on
the Offenses tab.
About this task
When you create an anomaly detection rule, the rule is populated with a default test stack,
based on your saved search criteria. You can edit the default tests or add tests to the test
stack. At least one Accumulated Property test must be included in the test stack.
By default, the Test the [Selected Accumulated Property] value of each [group]
separately option is selected on the Rule Test Stack Editor page.
An anomaly detection rule tests the selected accumulated property for each event or flow
group separately. For example, if the selected accumulated value
is UniqueCount(sourceIP), the rule tests each unique source IP address for each event or
flow group.
The Test the [Selected Accumulated Property] value of each [group] separately option
is dynamic. The [Selected Accumulated Property] value depends on the option that you
select for the this accumulated property test field of the default test stack.
The [group] value depends on the grouping options that are specified in the saved search
criteria. If multiple grouping options are included, the text might be truncated. Move your
mouse pointer over the text to view all groups.
Procedure
• Click the Log Activity or Network Activity tab.
• Perform an aggregated search.
 You can add a property to the group by in a new historical search or select a
property from the Display list on the current search page.
• On the search result page, click Configure , and then configure the following
options:
• Select a property from the Value to Graph list.
• Select time series as the chart type from the Value to Graph list
• Enable the Capture Time Series Data check box.
• Click Save, and then enter a name for your search.
• Click OK.
• Select last 5 minutes from the Time Range list, while you wait for the time
series graph to load.
You must have time series data for the property that you selected in the Value to
Graph list to run a rule test on that accumulated property.
• From the Rules menu, select the rule type that you want to create.
• Add Anomaly Rule
• Add Threshold Rule
• Add Behavioral Rule
• On the Rule Test Stack Editor page, in the enter rule name here field, type a unique
name that you want to assign to this rule.
• To apply your rule by using the default test, select the first rule in the anomaly Test
Group list.
You might need to set the accumulated property parameter to the property that you
selected from the Value to Graph list that you saved in the search criteria. If you
want to see the result sooner, set the percentage to a lower value, such as 10%.
Change last 24 hours to a lesser time period, such as 1 hour. Because an anomaly
detection tests on aggregated fields in real time to alert you of anomalous network
activity, you might want to increase or decrease events or flows in your network
traffic.
• Add a test to a rule.
• To filter the options in the Test Group list, type the text that you want to
filter for in the Type to filter field.
• From the Test Group list, select the type of test that you want to add to this
rule.
• Optional: To identify a test as an excluded test, click and at the beginning of
the test in the Rule pane. The and is displayed as and not.
• Click the underlined configurable parameters to customize the variables of
the test.
• From the dialog box, select values for the variable, and then click Submit.
• To test the total selected accumulated properties for each event or flow group,
disable Test the [Selected Accumulated Property] value of each [group]
separately.
• In the groups pane, enable the groups you want to assign this rule to.
• In the Notes field, type any notes that you want to include for this rule, and then
Click Next.
 • On the Rule Responses page, configure the responses that you want this rule to
generate.
Learn more about rule response page parameters for anomaly detection rules:
The following table provides the Rule Response page parameters if the rule type is
Anomaly.
Table 1. Anomaly Detection Rule Response page parameters
ParameterDescription

Specifies that this rule dispatches a new event with the original event or flow,
Dispatch
which is processed like all other events in the system. By default, this check box
New Event
is selected and cannot be cleared.

If you want the Event Name information to contribute to the name of the
offense, select the This information should contribute to the name of
the associated offense(s) option.
If you want the configured Event Name to contribute to the offense, select
Offense
the This information should set or replace the name of the
Naming
associated offense(s).
Note: After you replace the name of the offense, the name won't change until the
offense is closed. For example, if an offense is associated with more than one
rule, and the last event doesn't trigger the rule that is configured to override the
name of the offense, the offense's name won't be updated by the last event.
Instead, the offense name remains the name that is set by the override rule.

The severity level that you want to assign to the event. The range is 0 (lowest) to
Severity 10 (highest) and the default is 5. The Severity is displayed in the Annotations
pane of the event details.

The credibility that you want to assign to the log source. For example, is the log
source noisy or expensive? Using the list boxes, select the credibility of the
Credibility
event. The range is 0 (lowest) to 10 (highest) and the default is 5. Credibility is
displayed in the Annotations pane of the event details.

The relevance that you want to assign to the weight of the asset. For example,
how much do you care about the asset? Using the list boxes, select the relevance
Relevance
of the event. The range is 0 (lowest) to 10 (highest) and the default is 5.
Relevance is displayed in the Annotations pane of the event details.

Ensure
that the
dispatched As a result of this rule, the event is forwarded to the magistrate. If an
event is offense exists, this event is added. If no offense was created on the
part of an Offenses tab, a new offense is created.
offense

Notify Events that generate as a result of this rule are displayed in the System
Notifications item in the Dashboard tab. If you enable notifications, configure
 the Response Limiter parameter.

Select this check box if you want to log the event or flow locally. By default, the
Send to check box is clear.
Local Note: Only normalized events can be logged locally on a QRadar® appliance. If
SysLog 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.

Adds 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.
Add to To add data to a reference set, follow these steps:
Reference
• From the first list, select the property of the event or flow
Set
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 To use this rule response, you must create the reference data collection.
Data

If you want this rule to remove data from a reference set, select this check
box.
Remove
from To remove data from a reference set, follow these steps:
Reference • From the first list, select the property of the event or flow
Set that you want to remove.
• From the second list, select the reference set from which
you want to remove the specified data.
Remove
from
Reference To use this rule response, you must have a reference data collection.
Data

You can 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
Execute
failures.
Custom
Action Select this check box and select a custom action from the Custom action
to execute list.
You add and configure custom actions by using the Define Actions icon
on the Admin tab.
Publish on
If the IF-MAP parameters are configured and deployed in the system settings,
the IF-MAP
select this option to publish the offense information about the IF-MAP server.
Server
 Response Select this check box and use the list boxes to configure the frequency with
Limiter which you want this rule to respond

Enable
Select this check box to enable this rule. By default, the check box is selected.
Rule

An SNMP notification might resemble:

"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:
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
• Click Next.
• Click Finish.

Configuring a rule response to add data to a reference data

collection
Set up rules that use reference data to alert you to suspicious activity. For example,
include a list of privileged users into reference data and then set up a rule that is
triggered to alert you when privileged user anomalies occur.
Before you begin
Before you send data to a reference set, your QRadar® administrator must create the reference
set.
About this task
QRadar supports the following data collection types:
Reference set
A set of elements, such as a list of IP addresses or user names, that are derived
from events and flows that are occurring on your network.
Reference map
Data is stored in records that map a key to a value. For example, to correlate user
activity on your network, you create a reference map that uses
the Username parameter as a key and the user’s Global ID as a value.
Reference map of sets
Data is stored in records that map a key to multiple values. For example, to test for
authorized access to a patent, use a custom event property for Patent ID as the
key and the Username parameter as the value. Use a map of sets to populate a list
of authorized users.
Reference map of maps
 Data is stored in records that map one key to another key, which is then mapped to
single value. For example, to test for network bandwidth violations, you create a
map of maps. Use the Source IP parameter as the first key,
the Application parameter as the second key, and the Total Bytes parameter as
the value.
Reference table
In a reference table, data is stored in a table that maps one key to another key,
which is then mapped to single value. The second key has an assigned type. This
mapping is similar to a database table where each column in the table is associated
with a type. For example, you create a reference table that stores
the Username parameter as the first key, and has multiple secondary keys that
have a user-defined assigned type such as IP Type with the Source IP or Source
Port parameter as a value. You can configure a rule response to add one or more
keys that are defined in the table. You can also add custom values to the rule
response. The custom value must be valid for the secondary key's type
Procedure
• Create the reference data collection by using the Reference Set
Management widget on the Admin tab.
You can also create a reference data collection by using
the ReferenceDataUtil.sh script.
• Create a rule by using the Rules wizard.
• Create a rule response that sends data to a reference data collection. You can add
the data as either shared data or domain-specific data
Editing building blocks
You can edit any of the default building blocks to use it in multiple rules or to build complex
rules or logic. You can save a group of tests as building blocks for use with rules.
For example, you can edit the BB:HostDefinition: Mail Servers building block to identify
all mail servers in your deployment. Then, you can configure any rule to exclude your mail
servers from the rule tests.
Procedure
• Click the Offenses or Network Activity tab.
• Click Rules.
• From the Display list, select Building Blocks.
• Double-click the building block that you want to edit.
• Update the building block, as necessary.
• Click Next.
• Continue through the wizard.
• Click Finish.
Rule performance visualization
Rule performance visualization extends the current logging around performance degradation and
the expensive custom rules in the QRadar® pipeline. With rule performance visualization, you can
easily determine the efficiency of rules in the QRadar pipeline, directly from the Rules page.

When rule performance visualization is turned on, the Performance column is added to
the Rules page. The Performance column is blank until a performance issue occurs in the
custom rule engine.
Figure 1. Performance column on the Rules page

When events or flows are routed to storage, QRadar begins collecting metrics on enabled
rules for efficiency measures. Metrics are collected on all event, common, and flow rules.
When you save rule updates, the metrics are cleared for the rules that you updated to avoid
any confusion around performance and updated rules. This option is configurable by an
Administrator.
You can sort rules by their performance metrics and identify the more expensive rules.
When you review the rules, you can adjust the tests to optimize each rule, and reduce the
load on the system.
With rule performance visualization, you see how expensive the rules
are. QRadar operations teams can monitor any expensive rules and ensure that they do not
cause future performance issues.
By having rules run efficiently, the workload on the system can decrease. Over time, this
efficiency can help QRadar avoid any performance degradations around rules, which cause
rules to bypass rule correlation. As a result, potential suspect activity might not trigger a
notification, potentially missing future security-related issues.
View the metrics for a rule
You can view the metrics for a rule from the Rules page when you move the mouse pointer
over the colored bars in the Performance column, and in the Performance
Analysis textbox, which is in the lower-right corner of the Rules page. You can also view
the metrics for a rule in the Rule Wizard when you edit a rule. The timestamp in
the Performance Analysis textbox shows when the metrics for the rule were updated. For
more information about creating rules, see the Rules topic.
From the Network Activity tab or the Log Activity tab, click Rules to display
the Rules page. Double-click a rule to open the Rule Wizard

Figure 2. Performance Analysis on the Rules page

Figure 3. Performance Analysis in the Rule Wizard

Colors and bars in the Performance column on the Rules
page
The number of bars that display is a visual aid for color blindness.
One red bar
The rule is under-performing and needs to be tuned. The EPS/FPS throughput for
this rule is below the lower limit. Open the rule and tune the tests.
Two orange bars
The rule might need some tuning.
Three green bars
The rule has a high throughput above the upper limit of the EPS/FPS threshold

The following image shows the default Custom Rule Settings in QRadar.
Figure 4. Custom Rule Settings

Viewing event details:

You can view a list of events in various modes, including streaming mode or in event
groups. In whichever mode you choose to view events, you can locate and view the details
of a single event.
Investigating an offense by using the summary information:
The Offense Summary window provides the information that you need to investigate an
offense in IBM® QRadar®. The information that is most important to you during your
investigation might be different, depending on the type of offense that you are
investigating.
To make it easier for you to investigate an offense, the bottom of the Offense
Summary page groups information about top contributors to the offense. These fields
show only the most recent or most important pieces of information in that category. Many
fields show more information when you hover the mouse over them. Some fields have
right-click menu options.
TASK: 1.3 Analyze an offense and associated IP addresses
1.3.1 Analyze Associated IPs of an Offense
- Go to Offenses tab- Read The offense information listed in the Table
- Double click on the offense to open it
- In the offense Read the information about the offense
- In the Source IP(s)/Destination IP(s) fields investigate the IPs associated, use right click
options to determine the following:
- DNS Lookup
- WHOIS Lookup
- X-Force Exchange Lookup
Offense management:
IBM® QRadar® reduces billions of events and flows into a manageable number of
actionable offenses that are prioritized by their impact on your business operations. Use
the Offenses tab to access all of the data that you need to understand even the most
complex threats.
By providing immediate context for the offense, QRadar helps you to quickly identify
which offenses are the most important, and to begin an investigation to find the source of
the suspected security attack or policy breach.
Tip: You can also manage offenses using the IBM QRadar Analyst Workflow interface.
Restriction: You cannot manage offenses in IBM QRadar Log Manager.

Offense prioritization:
The magnitude rating of an offense is a measure of the importance of the offense in your
environment. IBM® QRadar® uses the magnitude rating to prioritize offenses and help you
to determine which offenses to investigate first.
The magnitude rating of an offense is calculated based on relevance, severity, and
credibility.
• Relevance determines the impact of the offense on your network. For example, if a
port is open, the relevance is high.
• Credibility indicates the integrity of the offense as determined by the credibility
rating that is configured in the log source. Credibility increases as multiple sources
report the same event.
• Severity indicates the level of threat that a source poses in relation to how prepared
the destination is for the attack.
QRadar uses complex algorithms to calculate the offense magnitude rating, and the rating
is re-evaluated when new events are added to the offense and also at scheduled intervals.
The following information is considered when the offense magnitude is calculated:
• the number of events and flows that are associated with the offense
• the number of log sources
• the age of the offense
• the weight of the assets associated with the offense
• the categories, severity, relevance, and credibility of the events and flows that
contribute to the offense
• the vulnerabilities and threat assessment of the hosts that are involved in the
offense
The magnitude rating of an offense is different from the magnitude rating for an event. You
can influence the magnitude of an offense by setting the event magnitude in the rule
actions, but you cannot bypass the QRadar algorithms to set the offense magnitude
yourself.
Offense indexing
Offense indexing provides the capability to group events or flows from different rules
indexed on the same property together in a single offense.
IBM® QRadar® uses the offense index parameter to determine which offenses to chain
together. For example, an offense that has only one source IP address and multiple
destination IP addresses indicates that the threat has a single attacker and multiple victims.
If you index this type of offense by the source IP address, all events and flows that originate
from the same IP address are added to the same offense.
You can configure rules to index an offense based on any piece of
information. QRadar includes a set of predefined, normalized fields that you can use to
index your offenses. If the field that you want to index on is not included in the normalized
fields, create a custom event or a custom flow property to extract the data from the payload
and use it as the offense indexing field in your rule. The custom property that you index on
can be based on a regular expression, a calculation, or an AQL-based expression.
Offense indexing considerations
It is important to understand how offense indexing impacts your IBM®
QRadar® deployment.
System performance
Ensure that you optimize and enable all custom properties that are used for offense
indexing. Using properties that are not optimized can have a negative impact on
performance.
When you create a rule, you cannot select non-optimized properties in the Index offense
based on field. However, if an existing rule is indexed on a custom property, and then the
custom property is de-optimized, the property is still available in the offense index list. Do
not de-optimize custom properties that are used in rules.
Rule action and response
When the indexed property value is null, an offense is not created, even when you select
the Ensure the detected event is part of an offense check box in the rule action. For
example, if a rule is configured to create an offense that is indexed by host name, but the
host name in the event is empty, an offense is not created even though all of the conditions
in the rule tests are met.
When the response limiter uses a custom property, and the custom property value is null,
the limit is applied to the null value. For example, if the response is Email, and the limiter
says Respond no more than 1 time per 1 hour per custom property, if the rule fires a
second time with a null property within 1 hour, an email will not be sent.
When you index using a custom property, the properties that you can use in the rule index
and response limiter field depends on the type of rule that you are creating. An event rule
accepts custom event properties in the rule index and response limiter fields, while a flow
rule accepts only custom flow properties. A common rule accepts either custom event or
custom flow properties in the rule index and response limiter fields.
You cannot use custom properties to index an offense that is created by a dispatched event.

Payload contents
Offenses that are indexed by the Ariel Query Language (AQL), a regular expression (regex),
or by a calculated property include the same payload as the initial event that generated the
offense.
Offenses that are indexed by a normalized event field, such as Source IP or Destination IP,
include the event name and description as the custom rules engine (CRE) payload.

Offense retention
The state of an offense determines how long IBM® QRadar® keeps the offense in the
system. The offense retention period determines how long inactive and closed offenses are
kept before they are removed from the QRadar console.
Active offenses
When a rule triggers an offense, the offense is active. In this state, QRadar is
waiting to evaluate new events or flows against the offense rule test. When new
events are evaluated, the offense clock is reset to keep the offense active for
another 30 minutes.
Dormant offenses
An offense becomes dormant if new events or flows are not added to the offense
within 30 minutes, or if QRadar did not process any events within 4 hours. An
offense remains in a dormant state for 5 days. If an event is added while an offense
is dormant, the five-day counter is reset.
Inactive offenses
An offense becomes inactive after 5 days in a dormant state. In the inactive state,
new events that trigger the offense rule test do not contribute to the inactive
offense. They are added to a new offense.
Inactive offenses are removed after the offense retention period elapses.
Closed offenses
Closed offenses are removed after the offense retention period elapses. If more
events occur for an offense that is closed, a new offense is created.
If you include closed offenses in a search, and the offense wasn't removed from
the QRadar console, the offense is displayed in the search results.
The default offense retention period is 30 days. After the offense retention period expires,
closed and inactive offenses are removed from the system. Offenses that are not inactive
or closed are retained indefinitely.
Important: System performance is negatively impacted when the system retains many
inactive and closed offenses. For optimum performance, set the retention period for the
least amount of time possible. The suggested retention period is 3 days.
To prevent an offense from being removed from the system, you can protect it. Before you
protect offenses, consider the performance impact that it might have. Some offenses impact
system performance more than others. For example, offenses with large numbers of events
and flows have a greater impact on performance. Offenses that have many targets and
destinations impact performance more than an offense that has only a single target or
destination.
If you need to re-create an offense after it is removed from the system, run a historical
correlation job to analyze the historical data. For more information, see Historical
correlation
Investigating IP addresses:
You can use several methods to investigate information about IP addresses on
the Dashboard, Log Activity, and Network Activity tabs.
• Log in to QRadar®.
• Click the tab that you want to view.
• Hover over an IP address to view the location of the IP address.
• Right-click the IP address or asset name and select one of the following options:
TASK: 1.4 Recognize MITRE threat groups and actors
1.4.1 Open a Offense for investigation
- Select the rules contributing to offense by Clicking Display and Select Rules.
- Open the rule and review the MITRE threat from the rule and rule notes
1.4.2 Open a Offense for investigation
- Select the rules contributing to offense by Clicking Display and Select Annotations.
- Review the annotations to understand rule intent and MITRE threat
1.4.3 Use Case Manager to determine MITRE Threat group
- Open Use Case Manager App
- Select ATT&CK Actions -> Coverage Map and Report
- Review the rules and the corresponding MITRE threat group
MITRE ATTA & CK mapping and visualization:
The MITRE ATT & CK framework represents adversary tactics that are used in a security
attack. It documents common tactics, techniques, and procedures that can be used in
advanced persistent threats against enterprise networks.
The following phases of an attack are represented in the MITRE ATT & CK framework:
Tactics, techniques, and sub-techniques
Tactics represent the goal of an ATT & CK technique or sub-technique. For example, an
adversary might want to get credential access to your network.
Techniques represent how an adversary achieves their goal. For example, an adversary
might dump credentials to get credential access to your network.
Sub-techniques provide a more specific description of the behavior an adversary uses to
achieve their goal. For example, an adversary might dump credentials by accessing the
Local Security Authority (LSA) Secrets.
Workflow for MITRE ATT & CK mapping and visualization
Create your own rule and building block mappings in IBM® QRadar® Use Case Manager ,
or modify IBM QRadar default mappings to map your custom rules and building blocks to
specific tactics and techniques.
Save time and effort by editing multiple rules or building blocks at the same time, and by
sharing rule-mapping files between QRadar instances. Export your MITER mappings
(custom and IBM default) as a backup of custom MITER mappings in case you uninstall the
app and then decide later to reinstall it. For more information, see Uninstalling QRadar Use
Case Manager .
After you finish mapping your rules and building blocks, organize the rule report and then
visualize the data through diagrams and heat maps. Current® and potential MITRE
coverage data is available in the following reports: Detected in
timeframe report, Coverage map and report , and Coverage summary and trend .
TASK: 1.5 Perform offense management
1.5.1 Prioritize the offenses
- Click the offenses tab.
- Double click on the magnitude field of the list to arrange the offenses by magnitude
1.5.2 Assign an offense.
- Click the Offenses tab.
- Select the offense that you want to assign.
- To assign multiple offenses, hold the Control key while you select each offense.
- From the Actions list, select Assign.
- In the Assign To User list, select the user that you want to assign this offense to.
- Click save.
1.5.3 Document an offense.
- Click the Offenses tab. Select the offense to which you want to add the note.
- To add the same note to multiple offenses, press the Ctrl key while you select each offense.
- From the Actions list, select Add Note.
- Type the note that you want to include for this offense.
- Click Add Note.
1.5.4 Send Email notifications from an offense
- Click the Offenses tab.
- Select the offense for which you want to send an email notification.
- From the Actions list box, select Email.
- Configure the following parameters:
- To:
- From:
- Email Subject:
- Email Message:
- Click Send.
1.5.5 Hide an offense
- Click the Offenses tab.- Select the offense that you want to hide.
- To hide multiple offenses, hold the Control key while you select each offense.
- From the Actions list box, select Hide.
- Click OK.
1.5.6 Show a hidden offense.
- Click the Offenses tab
- To clear the filter on the offense list, click Clear Filter next to the Exclude Hidden Offenses
search parameter.
- To create a new search that includes hidden offenses, follow these steps:
- From the Search list box, select New Search.
- In the Search Parameters window, clear the Hidden Offenses check box in the Exclude
options list.
- Click Search.
- To remove the hidden flag from an offense:
- Select the offense for which you want to remove the hidden flag. To select multiple
offenses, hold the Control key while you click each offense.
- From the Actions list box, select Show.
1.5.7 Close an offense.
- Click the Offenses tab.
- Select the offense that you want to close.
- To close multiple offenses, hold the Control key while you select each offense.
- From the Actions list, select Close.
- In the Reason for Closing list, specify a closing reason.
- To add a close reason, click the icon beside Reason for Closing to open the Custom
Offense Close Reasons dialog box.
- Optional: In the Notes field, type a note to provide more information.
- The Notes field displays the note that was entered for the previous offense closing.
Notes must not exceed 2,000 characters.
1.5.8 Mark up an offense for follow up.
- Click the Offenses tab.
- Find the offense that you want to mark for follow-up.
- Double-click the offense.
- From the Actions list, select Follow up.
1.5.9 Protect an offense for follow up.
- Click the Offenses tab and click All Offenses.
- Choose one of the following options:
-Select the offense that you want to protect, and then select Protect from the Actions list.
- From the Actions list box, select Protect Listed.
- Click OK.
Assigning offenses to users:
By default, all new offenses are unassigned. You can assign an offense to an IBM®
QRadar® user for investigation.
When you assign an offense to a user, the offense is displayed on the My Offenses page for
that user. You must have the Assign Offenses to Users permission to assign offenses to
users. For more information about user role permissions, see the IBM QRadar
Administration Guide.
You can assign offenses to users from either the Offenses tab or Offense Summary pages.
This procedure provides instruction on how to assign offenses from the Offenses tab.
 • Click the Offenses tab.
• Select the offense that you want to assign.
To assign multiple offenses, hold the Control key while you select each offense.
• From the Actions list, select Assign.
• In the Assign To User list, select the user that you want to assign this offense to.
Note: The Assign To User list displays only those users who have privileges to view
the Offenses tab. The security profile settings for the user are followed as well.
• Click Save.
Result: The offense is assigned to the selected user. The User icon is displayed in the Flag
column of the Offenses tab to indicate that the offense is assigned. The designated user
can see this offense on the My Offenses page.
Assigning notes:
Add notes to an offense to track information that is collected during an investigation. Notes
can include up to 2000 characters.
• Click the Offenses tab.
• Select the offense to which you want to add the note.
To add the same note to multiple offenses, press the Ctrl key while you select each
offense.
• From the Actions list, select Add Note.
• Type the note that you want to include for this offense.
• Click Add Note.
Result: The note is displayed in the Last 5 Notes pane on the Offense Summary window.
A Notes icon is displayed in the flag column of the offense list.
Hover your mouse over the notes indicator in the Flag column of the Offenses list to view
the note.
Sending email notifications:
Share the offense summary information with another person by sending an email.
The body of the email message includes the following information, if available:
• Source IP address
• Source user name, host name, or asset name
• Total number of sources
• Top five sources by magnitude
• Source networks
• Destination IP address
• Destination user name, host name, or asset name
• Total number of destinations
• Top five destinations by magnitude
• Destination networks
• Total number of events
• Rules that caused the offense or event rule to fire
 • Full description of the offense or event rule
• Offense ID
• Top five categories
• Start time of the offense or the time the event was generated
• Top five annotations
• Link to the offense user interface
• Contributing CRE rules

Hiding offenses:
Hide an offense to prevent it from being displayed in the offense list. After you hide an
offense, the offense is no longer displayed in any list on the Offenses tab, including the All
Offenses list. However, if you perform a search that includes hidden offenses, the offense is
displayed in the search results.
• Click the Offenses tab.
• Select the offense that you want to hide.
To hide multiple offenses, hold the Control key while you select each offense.
• From the Actions list box, select Hide.
• Click OK.
Closing offenses:
Close an offense to remove it completely from your system.
The default offense retention period is 30 days. After the offense retention period expires,
closed offenses are deleted from the system. You can protect an offense to prevent it from
being deleted when the retention period expires.
Closed offenses are no longer displayed in any list on the Offenses tab, including the All
Offenses list. If you include closed offenses in a search, and the offense is still within the
retention period, the offense is displayed in the search results. If more events occur for an
offense that is closed, a new offense is created.
When you close offenses, you must select a reason for closing the offense. If you have
the Manage Offense Closing permission, you can add custom closing reasons. For more
information about user role permissions, see the IBM QRadar Administration Guide.
• Click the Offenses tab.
• Select the offense that you want to close.
To close multiple offenses, hold the Control key while you select each offense.
• From the Actions list, select Close.
• In the Reason for Closing list, specify a closing reason.
To add a close reason, click the icon beside Reason for Closing to open the Custom
Offense Close Reasons dialog box.
• Optional: In the Notes field, type a note to provide more information.
The Notes field displays the note that was entered for the previous offense closing.
Notes must not exceed 2,000 characters.
• Click OK.
Result: After you close offenses, the counts that are displayed on the By Category window
of the Offenses tab can take several minutes to reflect the closed offenses.
Marking an offense for follow-up:
Mark an offense for follow-up when you want to flag it for further investigation.
• Click the Offenses tab.
• Find the offense that you want to mark for follow-up.
• Double-click the offense.
• From the Actions list, select Follow up.
Result: The offense now displays the follow-up icon in the Flag column. To sort the
offense list to show flagged offenses at the top, click the Flags column header.
Protecting offenses:
You might have offenses that you want to retain regardless of the retention period. You can
protect offenses to prevent them from being removed from QRadar® after the retention
period has elapsed.
By default, offenses are retained for thirty days.
• Click the Offenses tab, and click All Offenses.
• Choose one of the following options:
• Select the offense that you want to protect, and then select Protect from
the Actions list.
• From the Actions list box, select Protect Listed.
 • Click OK.
Result: The offense is protected and will not be removed from QRadar. In
the Offense window, the protected offense is indicated by a Protected icon in the Flag
column.
TASK: 1.6 Describe the use of the magnitude of an offense
1.6.1 Review offense by magnitude
- Open the offense tab
- Review the offense by magnitude by hovering on magnitude column
- select an offense with highest magnitude or magnitude with high severity
1.6.2 Review offense with high magnitude
- Review the severity, relevance and credibility contributing to the magnitude of the offense
- Review other contributing factors for the offense magnitude rating
- Number of events
- Number of Log Sources
- Age of the offense
- Weight of the assets
TASK: 1.7 Identify events not correctly parsed and their source (Stored events)
1.7 1 Identify Unknown Events
- Click Log Activity Tab
- Add a filter for High Level Category – Unknown
1.7.2 Select a timeline for last 30 mins based on the load.
1.7.3 Review and recommend parsing and mapping of unknown and stored events
• https://www.youtube.com/watch?v=GgPW5OVwoMY
Routing options for rules:
You can choose from four rule routing options: Forward, Drop, Bypass correlation, and Log
Only. The following table describes the different options and how to use them.
The following table describes different routing option combinations that you can use.
These options are not available in offline mode.
If data matches multiple rules, the safest routing option is applied. For example, if data that
matches a rule that is configured to drop and a rule to bypass CRE processing, the data is
not dropped. Instead, the data bypasses the CRE and is stored in the database.
Troubleshooting DSMs:
If you come across a problem with your DSM, you can troubleshoot the following issues.
What happens when events, which are parsed, are collected
with unofficial DSMs?
Not having an official DSM doesn't mean that the events aren't collected. It indicates that
the event that is received by IBM® QRadar® might be identified as "Unknown" on the Log
Activity tab of QRadar. "Unknown" means that IBM QRadar collected the event, but was
unable to parse the event format to categorize the event. However, some unique events in
unofficial DSMs cannot be parsed or identified if they don't follow an event format that is
expected. When an event cannot be understood by the system, they are categorized as
"Unknown".
What is the difference between an unknown event and a
stored event?
Events comprise three different categories:
Parsed events
QRadar collects, parses, and categorizes the event to the proper log source.
Unknown events
The event is collected and parsed, but cannot be mapped or categorized to a specific log
source. The Event Name and the Low-Level Category are set as Unknown. Log sources
that aren't automatically discovered are typically identified as Unknown Event Log until a
log source is manually created in the system. When an event cannot be associated to a log
source, the event is assigned to a generic log source. You can identify these events by
searching for events that are associated with the SIM Generic log source or by using
the Event is Unparsed filter.

Stored events
The event cannot be understood or parsed by QRadar. When QRadar cannot parse an event,
it writes the event to disk and categorize the event as Stored.

How can you find these events in the Log Activity tab?
To find events specific to your device, you can search in QRadar for the source IP address of
your device. You can also select a unique value from the event payload and search
for Payload Contains. One of these searches might locate your event, and it is likely either
categorized as Unknown or Stored.
The easiest way to locate unknown or stored events is to add a search filter for Event in
Unparsed. This search filter locates all events that either cannot be parsed (stored) or events
that might not be associated with a log source or auto discovered (Unknown Log Event).
For more information about officially supported DSMs, see QRadar supported DSMs.
What do you do if you have an unknown event log from a log
source that is not auto discovered?
The Event Collection Service (ECS) contains a traffic analysis process that automatically
discovers and creates new log sources from events. Traffic analysis tries to identify the log
source by analyzing the event payloads. At minimum, 25 events are required to identify a
log source. If the log source cannot be identified by traffic analysis after 1,000 events,
then QRadar abandons the auto discovery process. When a log source cannot be identified
by the event payload and reaches the maximum threshold for traffic analysis,
then QRadar generates a notification that specifies the IP address of the log
source. QRadar generates the following notification:
Unable to automatically detect the associated log source for IP address <IP>
QRadar then categorizes the log source as SIM Generic and labels the events as Unknown
Event Log.
QRadar can auto discover certain log sources, but some supported log sources cannot be
detected. Common causes of this notification are:
• The device is a newer version than the DSM that QRadar supports to parse events.
• The device type does not support automatic log source discovery. Review the
documentation for your DSM to see whether it is automatically discovered.
• The logs might not follow an expected format. A customizable event format or
required field might be missing.
• The device might be creating an event format due to an incorrect configuration.
• The logs are coming from a device that is not an officially supported DSM in QRadar.
To resolve the unknown event log:

• Review the IP address to determine which device is sending unparsed events. After
you identify the device, you can manually create a log source by using the IBM
QRadar Log Source Management app.
• Review any log sources that forward events at a low rate. Log sources with low
event rates are a common cause of this notification.
• Ensure that auto update downloads the latest DSMs to properly parse events for
your QRadar system.
• Review any log sources that provide events through a central log server. Logs that
are provided from central log servers or management consoles might require their
log sources to be created manually.
• Review the Log Activity tab to determine the appliance type from the IP address in
the notification message and manually create a log source in QRadar.
What do you do if the product version or device you have is
not listed in the DSM Configuration Guide?
Sometimes a version of a vendor product or a device is not listed as supported. If the
product or device is not listed, follow these guidelines:
Version not listed
 If the DSM for your product is officially supported by QRadar, but your product version is
not listed in the IBM QRadar DSM Configuration Guide, you have the following options:

• Try the DSM to see whether it works. The product versions that are listed in
the guide are tested by IBM, but newer untested versions can also work.
• If you tried the DSM and it didn’t work, open a support ticket for a review of
the log source to troubleshoot and rule out any potential issues.
Tip: In most cases, no changes are necessary, or perhaps a minor update to
the IBM QRadar Identifier (QID) Map might be all that is required. Software
updates by vendors might on rare occasions add or change event formats
that break the DSM, requiring an RFE for the development of a new
integration. This is the only scenario where an RFE is required.
Device not listed
When a device is not officially supported, you have the following options:

• Open a request for enhancement (RFE) to have your device become officially
supported.
• Go to the QRadar SIEM RFE page (https://ibm.biz/BdRPx5).
• Log in to the support portal page.
• Click the Submit tab and type the necessary information.
Tip: If you have event logs from a device, attach the event information
and include the product version of the device that generated the event
log.
• Write a log source extension to parse events for your device. For more
information, see Log source extensions and the DSM Editor.
• You can use content extensions for sending events to QRadar that are
provided by some third-party vendors. They can be found on the IBM
Security App Exchange (https://exchange.xforce.ibmcloud.com/hub/). These
third-party DSM integrations are supported by the vendor, not by IBM. For a
list of available third-party DSMs, see DSMs supported by third-party
vendors.

Events routed directly to storage:

38750088 - Performance degradation has been detected in the event pipeline.
Event(s) were routed directly to storage.
Explanation
To prevent queues from filling, and to prevent the system from dropping events, the event
collection system (ECS) routes data to storage. Incoming events and flows are not
categorized. However, raw event and flow data is collected and searchable.

User response
Review the following options:
• Verify the incoming event and flow rates. If the event pipeline is queuing events,
expand your license to hold more data. To determine how close you are to your
EPS/FPM license limit, monitor the Event Rate (Events Per Second Raw) graph on
the System Monitoring dashboard. The graph shows you the current data rate.
Compare the data rate to the per-appliance license configuration in your
deployment.
For more information about EPS/FPM license limits, see QRadar: About EPS
HYPERLINK "https://www.ibm.com/support/pages/qradar-about-eps-fpm-
limits"& HYPERLINK "https://www.ibm.com/support/pages/qradar-about-eps-
fpm-limits" FPM Limits (https://www.ibm.com/support/pages/qradar-about-eps-
fpm-limits).
• Review recent changes to rules or custom properties. Rule or custom property
changes might cause sudden changes to your event or flow rates. Changes might
affect performance or cause the system to route events to storage.
• DSM parsing issues can cause the event data to route to storage. To verify whether
the log source is officially supported, see the DSM Configuration Guide.
• SAR notifications might indicate that queued events and flows are in the event
pipeline.
• Tune the system to reduce the volume of events and flows that enter the event
pipeline. Events must be tuned at the source, not in the product. You can set
coalescing on and configure your retention buckets to limit the number of stored
events. License throttling monitors the number of incoming events to the system to
manage input queues and licensing.

Maximum events or flows reached:

38750008 - The appliance exceeded the EPS or FPM allocation within the last hour.
Explanation: Each appliance is allocated a specific volume of event and flow data from the
license pool. In the last hour, the appliance exceeded the allocated EPS or FPM.
If the appliance continues to exceed the allocated capacity, the system might queue events
and flows, or possibly drop the data when the backup queue fills.

User response
• Adjust the license pool allocations to increase the EPS and FPM capacity for the
appliance.
• Tune the system to reduce the volume of events and flows that enter the event
pipeline.

Stored events:
Stored events do indeed use license capacity. Events being Stored can be caused because
the DSM can't parse the events or because the DSMFilter queue is full due to license or
performance problems. Routing to stored (on disk storage) for license/performance
happens when the in-memory queue of the relevant components above is full and so events
cannot be put in the queue of the downstream component. The queue fills when those
processing components have a processing rate lower than the ingestion rate to that
component. Each segment of the pipeline needs to have space for the next component in
line to take the incoming data. There are two locations in the QRadar event pipeline where
components can route to storage in two locations in QRadar where backups can occur
(incoming events (parsing/DSMFilter) and the custom rules engine (CRE). This is a
protection mechanism to keep data routing to disk when the event pipeline is backing up
due to a performance problem, such as license overages, under-performant regex, DSM
performance issues, or rules being backed up, etc.
TASK: 1.8 Outline simple offense naming mechanisms
1.8.1 Review offense names
- Open offense tab
- Review different Description column of offense and the rule associated with offense
1.8.2 Review rules to manage offense names
- Select Display -> Rules from Offense summary
- Review the rule name and Offense description
- Click and open the rule and go to Rule Response and review offense naming
1.8.3 Change offense naming
- If the offense description does not explain the attack properly, dispatch a new event with
information
- Use the event information to set or replace the name of the associated offense
TASK: 1.9 Create customized searches
1.9.1 Search offenses on my offenses / all offenses page
- Click the Offenses tab.
- From the Search list box, select New Search.
- Choose one of the following options:
- Select a previously saved search using one of the following options:
- From the Available Saved Searches list, select the saved search that you want to load.
- In the Type Saved Search or Select from List field, type the name of the search you
want to load.
- Click Load.
- Click Search
1.9.2 Search offenses on my offenses / all offenses page creating a new search
- Click the Offenses tab.
- From the Search list box, select New Search.
- On the Time Range pane, select an option for the time range you want to capture for this
search.
- On the Search Parameters pane, define your specific search criteria.
- On the Offense Source pane, specify the offense type and offense source you want to search:
- From the list box, select the offense type that you want to search for.
- Type your search parameters.
- In the Column Definition pane, define the order in which you want to sort the results:
- From the first list box, select the column by which you want to sort the search results.
- From the second list box, select the order that you want to display for the search results.
Options include Descending and Ascending.
- Click Search.
1.9.3 Search offenses by source IP.
- Click the Offenses tab.
- Click by Source IP. - From the Search list box, select New Search.
- On the Time Range pane, select an option for the time range you want to capture for this
search.
- On the Search Parameters pane, define your specific search criteria. -- On the Column
Definition pane, define the order in which you want to sort the results:
- From the first list box, select the column by which you want to sort the search results.
- From the second list box, select the order that you want to display for the search results.
Options include Descending and Ascending.
- Click Search.
1.9.4 Search offenses by destination IP
- Click the Offenses tab.
- On the navigation menu, click By Destination IP.
- From the Search list box, select New Search.
- On the Time Range pane, select an option for the time range you want to capture for this
search.
- On the Search Parameters pane, define your specific search criteria.
- On the Column Definition pane, define the order in which you want to sort the results:
- From the first list box, select the column by which you want to sort the search results.
- From the second list box, select the order in which you want to display the search
results. Options include Descending and Ascending.
- Click Search.
1.9.5 Saving Search criteria on the offenses tab
- Perform a search. See Offense searches.
- Click Save Criteria.
- Enter values for the following parameters
- Search Name
- Manage Groups
- Time span options (all offenses, Recent, Specific Interval)
- Set as Default (to make the search a default search)
- Click OK
Scheduled search:
Use the Scheduled search option to schedule a search and view the results.
You can schedule a search that runs at a specific time of day or night. If you schedule a
search to run in the night, you can investigate in the morning. Unlike reports, you have the
option of grouping the search results and investigating further. You can search on number
of failed logins in your network group. If the result is typically 10 and the result of the
search is 100, you can group the search results for easier investigating. To see which user
has the most failed logins, you can group by user name. You can continue to investigate
further.
You can schedule a search on events or flows from the Reports tab. You must select a
previously saved set of search criteria for scheduling.
• Create a report
 Specify the following information in the Report Wizard window:
• The chart type is Events/Logs or Flows.
• The report is based on a saved search.
Note: QRadar® does not support reports based on AQL searches that contain
subselect statements.
• Generate an offense.
You can choose the create an individual offense option or the add result to
an existing offense option.
You can also generate a manual search.
• View search results
You can view the results of your scheduled search from the Offenses tab.
• Scheduled search offenses are identified by the Offense Type column.
If you create an individual offense, an offense is generated each time that the report
is run. If you add the saved search result to an existing offense, an offense is created
the first time that the report runs. Subsequent report runs append to this offense. If
no results are returned, the system does not append or create an offense.
• To view the most recent search result in the Offense Summary window, double-click
a scheduled search offense in the offense list. To view the list of all scheduled search
runs, click Search Results in the Last 5 Search Results pane.
You can assign a Scheduled search offense to a user.

Exporting events:
You can export events in Extensible Markup Language (XML) or Comma-Separated Values
(CSV) format.
The length of time that is required to export your data depends on the number of
parameters specified.
• Click the Log Activity tab.
• Optional. If you are viewing events in streaming mode, click the Pause icon to pause
streaming.
• From the Actions list box, select one of the following options:
• Export to XML > Visible Columns - Select this option to export only the
columns that are visible on the Log Activity tab. This is the recommended
option.
• Export to XML > Full Export (All Columns) - Select this option to export all
event parameters. A full export can take an extended period of time to
complete.
• Export to CSV > Visible Columns - Select this option to export only the
columns that are visible on the Log Activity tab. This is the recommended
option.
• Export to CSV > Full Export (All Columns) - Select this option to export all
event parameters. A full export can take an extended period of time to
complete.
 • If you want to resume your activities while the export is in progress, click Notify
When Done.
When the export is complete, you receive notification that the export is complete. If you
did not select the Notify When Done icon, the status window is displayed.
Quick filter search options:
Search event and flow payloads by typing a text search string that uses simple words or
phrases.
Quick filter is one of the fastest methods that you use to search for event or flow payloads
for specific data. For example, you can use quick filter to find these types of information:
• Every firewall device that is assigned to a specific address range in the past week
• A series of PDF files that were sent by a Gmail account in the past five days
• All records in a two-month period that exactly match a hyphenated user name
• A list of website addresses that end in .ca
You can filter your searches from these locations:
Log Activity toolbar and Network Activity toolbars
Select Quick Filter from the list box on the Search toolbar to type a text search
string. Click the Quick Filter icon to apply your Quick Filter to the list of
events or flows.
Add Filter Dialog box
Click the Add Filter icon on the Log Activity or Network Activity tab.
Select Quick Filter as your filter parameter and type a text search string.
Flow search pages
Add a quick filter to your list of filters.
Note: Quick Filter searches that use a time frame outside of the Payload Index Retention
setting can trigger slow and resource-intensive system responses. For example, if the
payload index retention is set for 1 day, and you use a time frame for the last 30 hours in
the search.
When you view flows in real-time (streaming) or last interval mode, you can type only
simple words or phrases in the Quick Filter field. When you view events or flows in a
time-range, follow these syntax guidelines:
Limitations
Quick filter searches operate on raw event or flow log data and don't distinguish between
the fields. For example, quick filter searches return matches for both source IP address and
destination IP address, unless you include terms that can narrow the results.
Search terms are matched in sequence from the first character in the payload word or
phrase. The search term user matches user_1 and user_2, but does not match the following
phrases: ruser, myuser, or anyuser.
Quick filter searches use the English locale. Locale is a setting that identifies language or
geography and determines formatting conventions such as collation, case conversion,
character classification, the language of messages, date and time representation, and
numeric representation.
The locale is set by your operating system. You can configure QRadar® to override the
operating system locale setting. For example, you can set the locale to English and
the QRadar Console can be set to Italiano (Italian).
If you use Unicode characters in your quick filter search query, unexpected search results
might be returned.
If you choose a locale that is not English, you can use the Advanced search option
in QRadar for searching event and payload data.
How does Quick Filter search and payload tokens work?
Text that is in the payload is split into words, phrases, symbols, or other elements. These
tokens are delimited by space and punctuation. The tokens don't always match user-
specified search terms, which cause some search terms not to be found when they don't
match the generated token. The delimiter characters are discarded but exceptions exist
such as the following exceptions:
 • Periods that are not followed by white space are included as part of the token.
For example, 192.0.2.0:56 is tokenized as host token 192.0.2.0 and port token 56.
• Words are split at hyphens, unless the word contains a number, in which case, the
token is not split and the numbers and hyphens are retained as one token.
• Internet domain names and email addresses are preserved as a single token.
192.0.2.0/home/www is tokenized as one token and the URL is not separated.
192.0.2.7:/calling1/www2/scp4/path5/fff is tokenized as host 192.0.2.7 and the
remainder is one token /calling1/www2/scp4/path5/fff
File names and URL names that contain more than one underscore are split before a period
(.).
Example of multiple underscores in a file name:
If you use hurricane_katrina_ladm118.jpg as a search term, it is split into the following
tokens:
• hurricane
• katrina_ladm118.jpg
Search the payload for the full search term by placing double quotation marks around the
search term: "hurricane_katrina_ladm118.jpg"
Example of multiple underscores in a relative file path:
The thumb.ladm1180830/thumb.ladm11808301806.hurricane_katrina_ladm118.jpg is
split into the following tokens:
• thumb.ladm1180830/thumb.ladm11808301806.hurricane
• katrina_ladm118.jpg
To search for hurricane_katrina_ladm118.jpg, which consists of one partial and one full
token, place an asterisk in front of the query term, *hurricane_katrina_ladm118.jpg

Advanced search options:

Use the Advanced Search field to enter an Ariel Query Language (AQL) that specifies the fields that
you want and how you want to group them to run a query.
Note: When you type an AQL query, use single quotation marks for a string comparison, and use
double quotation marks for a property value comparison.

The Advanced Search field has auto completion and syntax highlighting.
Use auto completion and syntax highlighting to help create queries. For information about
supported web browsers, see Supported web browsers
Note: If you use a quick filter on the Log Activity tab, you must refresh your browser window
before you run an advanced search.

Accessing Advanced Search

Access the Advanced Search option from the Search toolbar that is on the Network
Activity and Log Activity tabs to type an AQL query.
Select Advanced Search from the list box on the Search toolbar.
Expand the Advanced Search field by following these steps:

• Drag the expand icon that is at the right of the field.

• Press Shift + Enter to go to the next line.
• Press Enter.
You can right-click any value in the search result and filter on that value.
Double-click any row in the search result to see more detail.
All searches, including AQL searches, are included in the audit log.

AQL search string examples

The following table provides examples of AQL search strings.

The following table provides examples of AQL search strings for X-Force®.
Creating a customized search:
You can search for data that match your criteria by using more specific search options. For
example, you can specify columns for your search, which you can group and reorder to
more efficiently browse your search results.
The duration of your search varies depending on the size of your database.
You can add new search options to filter through search results to find a specific event or
flow that you are looking for.
The following table describes the search options that you can use to search event and
flow data:
Procedure
• Choose a search option:
• To search events, click the Log Activity tab.
• To search flows, click the Network Activity tab.
• From the Search list, select New Search.
• Select a previously saved search.
• To create a search, in the Time Range pane, select the options for the time range that
you want to capture for this search.
Note: The time range that you select might impact performance, when the time
range is large.
• Enable unique counts in the Data Accumulation pane.
Note: Enabling unique counts on accumulated data, which is shared with many
other saved searches and reports might decrease system performance.
• In the Search Parameters pane, define your search criteria.
• From the first list, select a parameter that you want to search for.
• From the second list, select the modifier that you want to use for the search.
Note:
 To search for an event or flow whose custom property does not have a value,
use the "is N/A" operator. To search for an event or flow whose custom
property has a value, use the "is not N/A" operator.
• From the entry field, type specific information that is related to your search
parameter.
• Click Add Filter.
• Repeat these steps for each filter that you are adding to the search criteria.
• To automatically save the search results when the search is complete, select
the Save results when search is complete check box, and then type a name for the
saved search.
• In the Column Definition pane, define the columns and column layout that you want
to use to view the results:
• From the Display list, select the preconfigured column that is set to associate
with this search.
• Click the arrow next to Advanced View Definition to display advanced
search parameters.
• Customize the columns to display in the search results.
• In the Results Limit field, type the number of rows that you want the search
to return.
• Click Filter.
Creating a custom column layout
Create a custom column layout by adding or removing columns in an existing layout.

Procedure
• On the Log Activity or the Network Activity tab, click Search > Edit Search.
• In the Column Definition pane, select an existing column layout in the Display list.
When you modify the layout, the name in the Display list is automatically changed
to Custom.
• Modify your search grouping.
• To add a column to your search group, select a column from the Available
Columns list and click the right arrow to move the column to the Group
By list.
• To move a column from the Columns list to your search group, select a
column from the Columns list and drag it to the Group By list.
• To remove a column from your search group, select the column from
the Group By list and click the left arrow.
• To change the order of your column groupings, use the up and down arrows
or drag the columns into place.
• Modify your column layout.
• To add a column to your custom layout, select a column from the Available
Columns list and click the right arrow to move the column to
the Columns list.
• To move a column from the Group By list to your custom layout, select a
column from the Group By list and drag it to the Columns list.
 • To remove a column from your custom layout, select the column from
the Columns list and click the left arrow.
• To change the order of your columns, use the up and down arrows or drag
the columns into place.
• In the Name field, enter the name of your custom column layout.
• Click Save Column Layout
Deleting a custom column layout
You can delete an existing user-created column layout.

Procedure
• On the Log Activity or the Network Activity tab, click Search > Edit Search.
• In the Column Definition pane, select an existing user-created column layout in
the Display list.
• Click Delete Column Layout

Searching offenses on the By Source IP page:

The following table describes the search options that you can use to search offense data
on the By Source IP page:
Procedure
• Click the Offenses tab.
• Click By Source IP.
• From the Search list box, select New Search.
• On the Time Range pane, select an option for the time range you want to capture for
this search. See Table 1.
• On the Search Parameters pane, define your specific search criteria. See Table 1.
• On the Column Definition pane, define the order in which you want to sort the
results:
 • From the first list box, select the column by which you want to sort the
search results.
• From the second list box, select the order that you want to display for the
search results. Options include Descending and Ascending.
• Click Search.
Searching offenses on the My Offenses and All Offenses
pages:
On the My Offenses and All Offenses pages of the Offense tab, you can search for offenses
that match your criteria.
The following table describes the search options that you can use to search offense data on
the My Offenses and All Offenses pages.
The following table describes the options available in the Offense Type list box:
Procedure
• Click the Offenses tab.
• From the Search list box, select New Search.
• Choose one of the following options:
• To load a previously saved search, go to Step 4.
• To create a new search, go to Step 7.
• Select a previously saved search using one of the following options:
• From the Available Saved Searches list, select the saved search that you
want to load.
• In the Type Saved Search or Select from List field, type the name of the
search you want to load.
• Click Load.
 • Optional. Select the Set as Default check box in the Edit Search pane to set this
search as your default search. If you set this search as your default search, the
search automatically performs and displays results each time you access
the Offenses tab.
• On the Time Range pane, select an option for the time range you want to capture for
this search. See Table 1.
• On the Search Parameters pane, define your specific search criteria. See Table 1.
• On the Offense Source pane, specify the offense type and offense source you want to
search:
• From the list box, select the offense type that you want to search for.
• Type your search parameters. See Table 2.
• In the Column Definition pane, define the order in which you want to sort the
results:
• From the first list box, select the column by which you want to sort the
search results.
• From the second list box, select the order that you want to display for the
search results. Options include Descending and Ascending.
• Click Search.
Manage search results:
You can perform multiple connection searches while navigating to other interfaces.

You can configure the search feature to send you an email notification when a search is
complete. At any time while a search is in progress, you can view partial results of a search
in progress.
The search results toolbar provides the following options:
Procedure
• Click the Risks tab.
• On the navigation menu, click Connections.
• From the menu, select Search > Manage Search Results.
Saving search results from a connection search or a sub-
search
You can save your search results. You can save results from both connection searches and
sub-searches.

Procedure
• Click the Risks tab.
• On the navigation menu, click Connections.
• Perform a connection search or sub-search.
• From the Search Results window, select Search > Manage Search Results and
select a search result.
• Click Save Results.
• Type a name for the search results.
• Click OK.
Saving search criteria on the Offenses tab:
On the Offenses tab, you can save configured search criteria so that you can reuse the
criteria for future searches. Saved search criteria does not expire.
Procedure
• Procedure
• Perform a search. See Offense searches.
• Click Save Criteria.
• Enter values for the following parameters:

• Click OK.
Chapter 2: Rules & Building Block Design

Rules and Building Block Design QRadar rules are applied to all incoming events, flows, or
offenses to search for or detect anomalies. If all the conditions of a test are met, the rule
generates a response. A building block is a collection of tests that don't result in a response
or an action. A building block groups commonly used tests to build complex logic so that it
can be reused in rules. As an Analyst you need to fully understand how rules and building
blocks are designed and used, and although you are not responsible for implementing new
or tuning existing rules and building blocks, you can and should make recommendations on
updating QRadar components that may improve rules and building block design based on
your daily exposure to them.

TASK: 2.1 Interpret rules that test for regular expressions

2.1.1 Open Rule Wizard for the rule to investigate

2.1.2 Identify regular expressions to match patterns of text in the log source file

Types of reference data collections

IBM® QRadar® has different types of reference data collections that can handle different levels of
data complexity. The most common types are reference sets and reference maps.

If you want to use the same reference data in both QRadar SIEM and QRadar Risk Manager,
use a reference set. You can't use other types of reference data collections with QRadar
Risk Manager.
TASK: 2.2 Create and manage reference sets and populate them with data
2.2.1 Review the types of Reference Data
2.2.2 Investigate reference sets via the GUI
2.2.3 Create, edit, and delete reference sets
- GUI
- API
- Command Line
2.2.4 Understand Building Blocks and reference sets
• https://youtu.be/mNyd8FNns_4

Viewing the contents of a reference set

View information about the data elements in the reference set, such as the domain
assignment, the expiry on the data, and when the element was last seen in your network.
Procedure
• On the navigation menu ( ), click Admin.
• In the System Configuration section, click Reference Set Management.
• Select a reference set and click View Contents.
• Click the Content tab to view information about each data element.
5. Click the References tab to view the rules that use the reference set in a rule test or in a
rule response.

• To view or edit an associated rule, double-click the rule in the References list and
complete the rule wizard

Creating reference data collections with APIs

You can use the application program interface (API) to manage IBM® QRadar® reference
data collections.
Procedure
• Use a web browser to access https://<Console IP>/api_doc and log in as the
administrator.
• Select the latest iteration of the IBM QRadar API.
• Select the /reference_data directory.
• To create a new reference set, follow these steps:
• Select /sets.
• Click POST and enter the relevant information in the Value fields.
• Click Try It Out! To finish creating the reference data collection and to view
the results.
• To create a new reference map, follow these steps:
• Click/maps.
• Click POST and enter the relevant information om the Value fields.
 • Click Try It Out! to finish creating the reference data collection and to view
the results.
• To create a new reference map of sets, follow these steps:
• Select /map_of_sets.
• Click POST and enter the relevant information in the Value fields.
 • Click Try It Out! to finish creating the reference data collection and to view
the results.
• To create a new reference table or map of maps, follow these steps:
• Click /tables.
• Click POST and enter the relevant information in the Value fields.
 • Click Try It Out! to finish creating the reference data collection and to view
the results.

Creating reference data collections by using the command

line
Use the command line to manage reference data collections that cannot be managed in IBM®
QRadar®, such as reference maps, map of sets, map of maps, and tables. Although it's easier to
manage reference sets using QRadar, use the command line when you want to schedule
management tasks.
About this task
Use the ReferenceDataUtil.sh script to manage reference sets and other types of
reference data collections.
When you use an external file to populate the reference data collection, the first non-
comment line in the file identifies the column names in the reference data collection. Each
line after that is a data record that gets added to the collection. While the data type for the
reference collection values is specified when the collection is created, each key is an
alphanumeric string.
The following table shows examples of how to format data in an external file that is to be
used for populating reference maps.

You can also create reference data collections by using the /reference_data endpoint in
the QRadar RESTful API.
Procedure
• Using SSH, log in to IBM QRadar as the root user.
• Go to the /opt/qradar/bin directory.
• To create the reference data collection, type the following command
 • To populate the map with data from an external file, type the following command:

Example
Here are some examples of how to use the command line to create different types of
reference data collections:
Command reference for reference data utilities
You can manage your reference data collections by using the ReferenceDataUtil.sh utility on the
command line. The following commands are available to use with the script.
Create
Creates a reference data collection.

name
The name of the reference data collection.
[SET | MAP | MAPOFSETS | MAPOFMAPS | REFTABLE]
The type of reference data collection.
[ALN | ALNIC | NUM | IP | PORT | DATE]
The type of data in the reference set.
• ALN specifies alphanumeric values. This data type supports IPv4 and IPv6
addresses.
• ALNIC specifies alphanumeric values, but rule tests ignore the case. This data
type supports IPv4 and IPv6 addresses.
 • NUM specifies numeric values.
• IP specifies IP addresses. This data type supports only IPv4 address.
• PORT specifies port addresses.
• DATE specifies date values.
[-timeoutType=[FIRST_SEEN | LAST_SEEN]]
Specifies whether the amount of time the data elements remain in the reference
data collection is from the time the element was first seen or last seen.
[-TimeToLive='']
The amount of time the data elements remain in the reference data collection.
[-keyType=name:elementType,name:elementType,...]
A mandatory REFTABLE parameter of consisting of key name
to ELEMENTTYPE pairs.
[-key1Label='']
An optional label for key1, or the primary key. A key is a type of information, such
as an IP address.
[-valueLabel='']
An optional label for the values of the collection
Update
Updates a reference data collection.

name
The name of the reference data collection.
[-timeoutType=[FIRST_SEEN | LAST_SEEN]]
Specifies whether the amount of time the data elements remain in the reference
data collection is from the time the element was first seen or last seen.
[-timeToLive='']
The amount of time the data elements remain in the reference data collection.
[-keyType=name:elementType,name:elementType,...]
A mandatory REFTABLE parameter of consisting of key name
to elementType pairs.
[-key1Label='']
An optional label for key1.
[-valueLabel='']
An optional label for the values of the collection.
Add
Adds a data element to a reference data collection

name
The name of the reference data collection.
<value> <key1> [key2]
The key value pair that you want to add. The keys are alphanumeric strings.
• MAP and MAPOFSETS require Key 1.
• MAPOFMAPS and REFTABLE require Key 1, and the second-level Key 2.
[-sdf=" ... "]
The Simple Date Format string that is used to parse the date data
Delete
Deletes an element from a reference data collection.

name
The name of the reference data collection.
<value> <key1> [key2]
The key value pair that you want to delete. The keys are alphanumeric strings.
• MAP and MAPOFSETS require Key 1.
• MAPOFMAPS and REFTABLE require Key 1, and the second-level Key 2.
[-sdf=" ... "]
The Simple Date Format string that is used to parse the date data.
Remove
Removes a reference data collection.
name
The name of the reference data collection.

Purge
Purges all elements from a reference data collection.
name
The name of the reference data collection

List
Lists elements in a reference data collection.

name
The name of the reference data collection.
[displayContents]
Lists all elements in the specified reference data collection.
Listall
Lists all elements in all reference data collection.

[displayContents]
Lists all elements in all reference data collections.
Load
Populates a reference data collection with data from an external .csv file.
name
The name of the reference data collection.
filename
The fully qualified file name to be loaded. Each line in the file represents a record
to be added to the reference data collection.
[-encoding=...]
Encoding that is used to read the file.
[-sdf=" ... "]
 The Simple Date Format string that is used to parse the date data.

TASK: 2.3 Install QRadar Content Packs using the QRadar Assistant App
2.3.1 Navigating to the QRadar Assistant App
2.3.2 Search for Content Packs
2.3.3 Install Content Packs

Downloading apps with the QRadar Assistant App

On the Applications page, you can download and install apps from the IBM® X-Force® Exchange.
Procedure
• Use any of the following methods to find apps:

• To see a brief description of the app, click Quick View.

• To see the full description, click the app in the list, or click See full description from
the Quick View window.
• From the full app description, click Install, then click Accept Terms to download
and install the app.
• Optional: Hover over the download drawer icon to see icons of the apps that are
queued for download or installation.
You can place up to five apps in the download queue at one time.
 • Optional: Click the download drawer icon to see the Quick View and installation
status of all apps that are being installed.

Use the IBM® QRadar® Assistant app to manage your app and content extension inventory, view
app and content extension recommendations, follow the QRadar Twitter feed, and get links to
useful information.

The QRadar Assistant app consists of the following sections:

Guide Center
The QRadar Assistant Guide Center is a central point that links to a wide collection
of QRadar information resources. From the Guide Center, you can view tuning and
use cases videos that are recorded by QRadar experts, watch previously recorded
open mic sessions, access a wide variety of QRadar technical tips, view IBM
Security Community information, and watch video tutorials provided by IBM
Learning Academy.
Featured Applications
Featured applications are the most recently recommended applications that are
featured by IBM.
Twitter and Support
View the IBM QRadar Twitter feed
from IBMSecurity (https://twitter.com/IBMSecurity).
Support Forum
View the latest QRadar related questions from IBM developerWorks forums.
Applications page
Search, sort, and filter available apps by various categories. You can see a quick
view of the app, then expand to see the full description and download the app. See
which apps have updates available.
When you select an app to download, it appears in the download drawer.
 Open the drawer to see a list of apps that are queued for download or installation.
You can place up to five apps in the download queue at one time. To keep the
download drawer open, click the pin icon.
From Version 2.3.0, you can also view the list of currently installed QRadar
extensions and contents.
Watson Integration
On the Watson Integration page, you can learn how the IBM QRadar Advisor with
Watson works with QRadar to investigate and respond to threats. You can review
requirements for your QRadar system to install and run the Advisor app. You can
also download and install QRadar Advisor with Watson directly from the Assistant
app.
Configuring the QRadar Assistant app
The QRadar® Assistant app is included in QRadar installations of version 7.3.1 and later. You can
download the app from the IBM® Security App Exchange (https://exchange.xforce.ibmcloud.com/)
for those versions. An Admin user must configure certain options to enable the Assistant app in
your QRadar environment.
About this task
QRadar on Cloud administrators can learn how to add and manage authorized service
tokens by reading Manage authorized service tokens.
If you’re a QRadar on Cloud customer, contact IBM Customer Support to create an
authorized service token for you.
Procedure

• Click the Assistant app icon ( ).

• If you are the Admin configuring the Assistant app for the first time, complete the
following steps:
• Enter a valid authorized service token into the banner on the Assistant
app page and click Save.

• Click Settings, select the API Authentications tab, and enter your X-Force®
Exchange API Key and API Password. For more information, see Obtaining an
API Key and Password (https://api.xforce.ibmcloud.com/doc/#auth).
• For Assistant 3.5.0 or later, click the gear icon on the Assistant app page to go
to the Settings page, and then enter the authorized service token, your X-
Force® Exchange API Key, and API password.
After an Admin configures the authorized service token and API key and password,
other Admin users do not need to perform this configuration. Non-Admin users can
use the Assistant app, but are not authorized to download and install apps.
 • To configure a proxy server for communication with X-Force Exchange,
click Settings, select the Proxy tab, and enter the following information for your
proxy server:
• Protocol
• Address
• Port
• User name
• Password
• Click Save, then close the Settings window.
• If you want to use the QRadar Phone Home Service, click Agree.
Managing installed extensions
You can use the Installed section on the Applications page to view and manage currently installed
QRadar extensions and contents.
Procedure

• Click the Assistant app icon ( ), and then click Applications.

• In the Installed section, click View All to view applications by Installed Extensions,
Installed Content, and Custom Applications.
• Hover your cursor over an application card, and then click Quick View to open
the Details Summary pane
 • Click the list view icon ( ) to view apps in a list. In Options, you can perform
the following tasks.
• For extensions, you can select to either delete, stop, or start the selected item.
• For contents, you can select to delete the selected item

Phone Home
QRadar® Assistant app V 1.1.5 and later include a new Phone Home feature, which anonymously
shares data with the IBM® X-Force® Exchange to monitor QRadar and detect issues early.
Why should I opt in to the Phone Home feature?
Opting in allows IBM to proactively detect issues in QRadar before they affect your assets.
It also helps IBM evaluate how you use QRadar, to more effectively develop product
features and services in those areas.
How do I opt in?
After you update the QRadar Assistant app, a window will prompt you to agree or disagree
to using the Phone Home feature. Select Agree to start using the feature.
If you want to opt in at a later time, select to the Help tab on the User Settings window,
and select Opt In.
How do I opt out?
If you select Disagree, you are not prompted again until you update the app again. If you
want to opt in later, click the Help tab on the User Settings window, and select Opt Out.
What information is shared?
The following table describes the information you can share with IBM.
Privacy information
This feature does not collect personally identifiable information. Information you share
with the IBM X-Force Exchange does not include IP addresses, host names, log source
information, or any other information that identifies specific customers. To delete your
information please contact [email protected] and include your X-Force
Exchange username.

Configure URL access on firewalls

If your IBM® QRadar® Console is behind a restricted firewall, you must allow traffic to specific
URLs to use the full features of the Assistant app.
At a minimum, you must allow traffic to https://api.xforce.ibmcloud.com/ to connect to the App
exchange. To receive content updates for the Assistant app, allow traffic to the following URLs:

• https://api.xforce.ibmcloud.com/
• http://www-01.ibm.com/support/
• https://www.googleapis.com/youtube-nocookie.com/v3/
• https://www.googleapis.com/youtube/v3/
• https://www.securitylearningacademy.com/
• https://ibmmaas360.secure.force.com/(specifically https://ibmmaas360.secure.for
ce.com/ForumsRSSFeed)
• https://www.ibm.com/mysupport
Running the Assistant app in offline mode
Last Updated: 2022-06-01
Admin can run the QRadar Assistant app V3.1.0 or later in offline mode to manage installed
extensions.

About this task

The QRadar Assistant app V3.1.0 or later can run in offline mode in the following situations:

• Internet access is unavailable.

• X-Force API is not connected.
The services that require internet access are unavailable in the offline mode
Procedure

• Click the Assistant app icon , and then the QRadar Assistant is running in
offline mode banner appears in the bottom.
• In the Use Application Manager in offline mode banner, click the hyperlink
text Here.
• In the QRadar Assistant is running in offline mode window, click Continue

• See Managing installed extensions for the steps to manage installed extensions.
• Optional: Perform one of the following steps to configure a proxy server for
communication with X-Force Exchange.
 • In the tooltip under the Offline indicator in the upper right corner of the
page, click the hyperlink text here to configure the QRadar Assistant app
settings.
• Click Settings, and then select the Proxy tab

Installing extensions by using an admin level authorized

service token
Administrators can create an admin level authorized service token that enables IBM QRadar
Assistant to install extensions in the background.

About this task

You must be an administrator to complete this task.
In QRadar® Assistant 3.2.0 or later, you can use the install_exts_by_service_token parameter in
the config file to enable or disable the background installation. By default, the parameter is set
to true. You must set it to false to enable QRadar Assistant to install extensions by an admin level
authorized service token in the current browser session.

• Use SSH to log in to your QRadar Console as the root user.

• Connect to the QRadar Assistant app container by typing the following command:

• Go to the store folder for QRadar Assistant.

• Edit the config_prod.json file to change the value from true to false for
the install_exts_by_service_token parameter.
The installed_by field displays the name of the administrator or the authorized
service token that was used to install the extension.
• Save the config_prod.json file
TASK: 2.4 Analyze rules that use Event and Flow data
2.4.1 Identify the types of rules
- Event
- Flow
- Common
2.4.2 Understand Event Rule Parameters
2.4.3 Understand Flow Rule Parameters
2.4.4 Understand Common Rule Parameters
• https://www.ibm.com/support/pages/qradar-support-geodata-faq

QRadar Rules
Rules perform tests on events, flows, or offenses. If all the conditions of a test are met, the rule
generates a response.

IBM® QRadar® includes rules that detect a wide range of activities, including excessive
firewall denies, multiple failed login attempts, and potential botnet activity. For more
information about rules, see the IBM QRadar Administration Guide.
The following list describes the two rule categories:

• Custom rules perform tests on events, flows, and offenses to detect unusual activity
in your network.
• Anomaly detection rules perform tests on the results of saved flow or event
searches to detect when unusual traffic patterns occur in your network.

Network hierarchy
IBM® QRadar® uses the network hierarchy objects and groups to view network activity and
monitor groups or services in your network.
When you develop your network hierarchy, consider the most effective method for viewing
network activity. The network hierarchy does not need to resemble the physical
deployment of your network. QRadar supports any network hierarchy that can be defined
by a range of IP addresses. You can base your network on many different variables,
including geographical or business units.
You can view different areas of your network that is organized by business function and
prioritize threat and policy information according to business value risk.
IBM® QRadar® uses the network hierarchy to do the following tasks:
• Understand network traffic and view network activity.
• Monitor specific logical groups or services in your network, such as marketing, DMZ,
or VoIP.
• Monitor traffic and profile the behavior of each group and host within the group.
• Determine and identify local and remote hosts.
When you develop your network hierarchy, consider the most effective method for viewing
network activity. The network hierarchy does not need to resemble the physical
deployment of your network. QRadar supports any network hierarchy that can be defined
by a range of IP addresses. You can base your network on many different variables,
including geographical or business units.
The objects that are defined in your network hierarchy do not have to be physically in your
environment. All logical network ranges belonging to your infrastructure must be defined
as a network object.

Guidelines for defining your network hierarchy

Building a network hierarchy in IBM® QRadar® is an essential first step in configuring your
deployment. Without a well configured network hierarchy, QRadar cannot determine flow
directions, build a reliable asset database, or benefit from useful building blocks in rules.
Consider the following guidelines when you define your network hierarchy:

• Organize your systems and networks by role or similar traffic patterns.

For example, you might organize your network to include groups for mail servers,
departmental users, labs, or development teams. Using this organization, you can
differentiate network behavior and enforce behaviour-based network management
security policies. However, do not group a server that has unique behavior with
other servers on your network. Placing a unique server alone provides the server
greater visibility in QRadar, and makes it easier to create specific security policies
for the server.
• Place servers with high volumes of traffic, such as mail servers, at the top of the
group. This hierarchy provides you with a visual representation when a discrepancy
occurs.
• Do not configure a network group with more than 15 objects.
 Large network groups can cause difficulty when you view detailed information for
each object. If your deployment processes more than 600,000 flows, consider
creating multiple top-level groups.
• Conserve disk space by combining multiple Classless Inter-Domain Routings
(CIDRs) or subnets into a single network group. For example, add key servers as
individual objects, and group other major but related servers into multi-CIDR
objects.

• Define an all-encompassing group so that when you define new networks, the
appropriate policies and behavior monitors are applied.In the following example, if
you add an HR department network, such as 10.10.50.0/24, to the Cleveland group,
the traffic displays as Cleveland-based and any rules you apply to the Cleveland
group are applied by default

• In a domain-enabled environment, ensure that each IP address is assigned to the

appropriate domain.
 • https://www.ibm.com/docs/en/qsip/7.4?topic=hierarchy-acceptable-cidr-values

Defining your network hierarchy

A default network hierarchy that contains pre-defined network groups is included in IBM®
QRadar®. You can edit the pre-defined network hierarchy objects, or you can create new network
groups or objects.
About this task
Network objects are containers for Classless Inter-Domain Routing (CIDR) addresses. Any
IP address that is defined in a CIDR range in the network hierarchy is considered to be a
local address. Any IP address that is not defined in a CIDR range in the network hierarchy is
considered to be a remote address. A CIDR can belong only to one network object, but
subsets of a CIDR range can belong to another network object. Network traffic matches the
most exact CIDR. A network object can have multiple CIDR ranges assigned to it.
Some of the default building blocks and rules in QRadar use the default network hierarchy
objects. Before you change a default network hierarchy object, search the rules and
building blocks to understand how the object is used and which rules and building blocks
might need adjustments after you modify the object. It is important to keep the network
hierarchy, rules, and building blocks up-to-date to prevent false offenses.
Procedure
• On the navigation menu ( ), click Admin.
• In the System Configuration section, click Network Hierarchy.
• From the menu tree on the Network Views window, select the area of the network
in which you want to work.
• To add network objects, click Add and complete the following fields:
 • Click Create.
• Repeat the steps to add more network objects, or click Edit or Delete to work with
existing network objects.
Installing extensions by using Extensions Management
Use the Extensions Management tool to add security extensions to IBM® QRadar®. The Extensions
Management tool allows you to view the content items in the extension and specify the method of
handling content updates before you install the extension.
Before you begin
Extensions must be on your local computer before you install them in QRadar.
You can download QRadar extensions from the IBM Security App
Exchange (https://apps.xforce.ibmcloud.com/) and from IBM Fix
Central (www.ibm.com/support/fixcentral/).
About this task
An extension is a bundle of QRadar functions. An extension can include content such as
rules, reports, searches, reference sets, and dashboards. It can also include applications
that enhance QRadar functions.
Procedure
• On the navigation menu ( ), click Admin.
• In the System Configuration section, click Extensions Management.
• To upload a new extension to the QRadar console, follow these steps:
• Click Add.
• Click Browse and navigate to find the extension.
• Optional: Click Install immediately to install the extension without viewing
the contents. Go to 5.b.
• Click Add.
• To view the contents of the extension, select it from the extensions list and
click More Details.
• To install the extension, follow these steps:
• Select the extension from the list and click Install.
• To assign a user to the app, select the User Selection menu, and select a user.
For example, you might want to associate the app with a specified user that is
listed in the User Selection menu who has the defined permissions.
 • If the extension does not include a digital signature, or it is signed but the
signature is not associated with the IBM Security Certificate Authority (CA),
you must confirm that you still want to install it. Click Install to proceed with
the installation.
• . Review the changes that the installation makes to the system.
• Select Preserve Existing Items or Replace Existing Items to specify how to
handle existing content items.

• Click Install
• Review the installation summary and lick OK
TASK: 2.5 Analyze Building Blocks: Host definition, category definition, Port definition
2.5.1 Identify Host Definition
- From Log Activity tab -> Rules
- Select Building Blocks from Display
- Search for HostDefinition and HostReference
- Review the configuration of hosts
2.5.2 Identify Port Definition
- From Log Activity tab -> Rules
- Select Building Blocks from Display
- Search for Port Definition
- Review the configuration of hosts
2.5.3 Identify Building Block definitions and tuning opportunities
- Host Definitions
- Port Definitions
- False Positive Definitions
- Network Definitions
- Compliance Definitions
2.5.4 View of Building Blocks and reference sets
• https://youtu.be/mNyd8FNns_4
• https://www.youtube.com/watch?v=xhrYeD3Pxiw
• https://www.youtube.com/watch?v=UmKMbfmjqKQ
Tuning building blocks
You can edit building blocks to reduce the number of false positives that are generated by IBM®
QRadar®.
About this task
To edit building blocks, you must add the IP address or IP addresses of the server or
servers into the appropriate building blocks.

Procedure
• Click the Offenses tab.
• On the navigation menu, click Rules.
• From the Display list, select Building Blocks.
• Double-click the building block that you want to edit.
• Update the building block.
• Click Finish.
The following table describes editable building blocks.
• https://www.ibm.com/docs/en/qsip/7.4?topic=blocks-tuning-building

QRadar: Defining QRadar Flow Bias

Question
What is QRadar Flow Bias?
Answer
Flow Bias is used to describe the relative size, or data transfer bias, of a flow, based
on transfer into or out of the network, where local network resources are defined as
those entered into the Network Hierarchy. Any address not defined in the Network
Hierarchy are thus ‘unknown’, and are effectively considered as external or
‘Remote’. In/Out Bias requires traffic to be entering into or leaving your network.
The possible values for Flow Bias are:

• In/Out Only Communication - These are considered Unidirectional Flows, one

way only, where there are only bytes & packet counts on the Source or Destination
address, but not both.

In/Out Only traffic can indicate:

• Host or network scanning.
• Communication that is being blocked by a Firewall/IDS.
• The QRadar Flow collector is not seeing the other side of the traffic due to a
problem with a span or tap being mis-configured.
• A routing issue at the network level, where external traffic is actually
entering, then exiting your network.
• External flow (Netflow) data collection not sending both sides of a
communication. For example you are only seeing traffic on an inbound
communication, but not the corresponding outbound communication.

• Mostly Out/In Communication - The ratio on these Flows is more than 70% in one
direction.
• For most enterprise users, the majority of your traffic should be Mostly In,
if most of your endpoints are user workstations, which would be pulling
information towards the local workstations.
 • Mostly out, could represent local file or web servers, which are sending out
more data in the form of html responses or file downloads than they are
receiving URL requests. An example use case for monitoring for DLP in
QRadar, is to watch your user segments for “Mostly Out” traffic, indicating
some sort of large outbound file transfer.

• Near Same Communication - The ratio of these flows is between 30% and 70%
per direction. Near Same communication is not as common as Mostly In/Out.

Examples of Near Same could be:

• Video conference call, where video streams are Inbound & Outbound.
• VOIP voice call, where audio streams are both Inbound & Outbound.
• Interactive (text based) user session, where a user is navigating around a
command line based operating system, such as SSH or Telnet.
• Internet messaging or chat applications.
• Any other example, where two hosts are connected directly, and would
send and receive similar amounts of data.

• Other - Local to Local (Internal) and Remote to Remote (both Source and
Destination address unknown) traffic. If you are monitoring Internal Network
Points within your organization, you should expect to see a fair amount
of Other or Local to Local data.

• If you see a large amount of “Other” or “Remote to Remote”, it is often the

case the one of the IP address ranges in use on your network was not
included in the Network Hierarchy. It can also be an indicator of some
device on your network being incorrectly configured with a non-internal
address range, or perhaps some device is spoofing an internet based IP
address, although this is normally quite rare.
• ISP users may see a large amount of Communication if they have a large
internet transit point and do not define all their customer downstream
networks within their Hierarchy. A rare possibility is that you are seeing
traffic in your network that should not be there.
• Another possibility is that something on your network, by design (malicious
intent) or by mis-configuration, is spoofing or using an incorrect, Non-
Local defined IP Address.

IBM® QRadar building blocks

Building blocks group commonly used tests to build complex logic so that they can be used
in rules.
Building blocks use the same tests that rules use, but have no actions that are associated
with them. They're often configured to test groups of IP addresses, privileged user names,
or collections of event names. For example, you might create a building block that includes
the IP addresses of all mail servers in your network, then use that building block in another
rule, to exclude those hosts. The building block defaults are provided as guidelines, which
can be reviewed and edited based on the needs of your network.
You can configure the host definition building blocks (BB:HostDefinition) to
enable QRadar® to discover and classify more servers on your network. If a particular
server is not automatically detected, you can manually add the server to its corresponding
host definition building block. This action ensures that the appropriate rules are applied to
the particular server type. You can also manually add IP address ranges instead of
individual devices.
Edit the following building blocks to reduce the number of offenses that are generated by
high volume traffic servers:
BB:HostDefinition
VA Scanner Source IP
BB:HostDefinition
Network Management Servers
BB:HostDefinition
Virus Definition and Other Update Servers
BB:HostDefinition
Proxy Servers
BB:NetworkDefinition
NAT Address Range
BB:NetworkDefinition
Trusted Network
Reviewing building blocks
Building blocks are a reusable set of rule tests that can be used within rules when needed. Host
definition building blocks (BB:HostDefinition) categorize assets and server types into CIDR/IP
ranges. By populating host definition building blocks, IBM® QRadar® can identify the type of
appliance that belongs to an address or address range. These building blocks can then be used in
rules to exclude or include entire asset categories in rule tests.
About this task
Use server discovery to populate host definition building blocks (BB:HostDefinition).
Server discovery uses existing asset profile data so that administrators can define unknown
server types and then assign them to a server definition and the network hierarchy.

Procedure
• From the main navigation menu in the app, click Host Definitions.
• Optional: Watch tuning videos to learn more about the importance of defining host
definitions, and to get tips on how to automatically populate them.
• Click Host definitions and review and update IPs and ports in BBs from the Host
Definition group or check when BBs were last updated.
• Optional: To instantly refresh the rules from QRadar, click the Refresh icon.
Otherwise, the app automatically updates data from the Console every 15 minutes.
 • To edit IPs in reference sets in building blocks, complete the following steps:
• Click Host definitions > IPs & Ports.
• Click a link or the pencil icon (Edit).
• On the Edit reference set page, add an IP or select an existing IP and delete it
from the reference set.
The reference set opens in the QRadar Reference Data Management app, if
the app is installed on the QRadar Console.
• To edit ports in building blocks or rules sets, complete the following steps:
• Click Host definitions > IPs & Ports.
• Click a link or the pencil icon (Edit).
• In the Edit ports window, edit the list of ports as needed, and click OK.
A list accumulates the ports as you edit, displaying a star next to each update.
• Click Save when you're done.
Investigating QRadar rules and building blocks
Investigate your rules by filtering different properties to ensure that the rules are defined and
working as intended, including log source coverage. Determine which rules you might need to edit
in IBM® QRadar® or investigate further in the IBM QRadar Use Case Manager app.
Before you begin
Ensure you have the proper user permissions to view and maintain QRadar rules. For more
information, see Assigning user permissions for QRadar Use Case Manager.

About this task

Follow the suggested workflow for investigating your rules.

Procedure
• Go to the Use Case Explorer page, click the list icon, and pick a template to use.
• Filter rules and building blocks by attributes, activity, tests, MITRE ATT&CK tactics
and techniques, or content extension attributes.
• To find the rule you want to edit or search, filter on the rule name, tactic, or
technique by using a regular expression. You can also use the Group filter to select
the group you want to search, such as authentication or compliance.
• To create rules, click the plus sign icon and select either Event or
Flow or Offense to open the rule wizard.
It might take several minutes for the new rule to appear in the report. To see the
new rule immediately, click the Refresh icon in the report menu bar.
• Customize the report presentation to make it easier to investigate the rules and
building blocks.
• To investigate an individual rule or building block, make sure that the report table is
ungrouped. Then, select the rule name to open the rule investigation page, which
provides details about the rule or building block you selected.
• To investigate multiple rules or building blocks simultaneously, click the pencil icon
in the report table to display checkboxes for each table row. Select the relevant rules
or building blocks that you want to edit, and then click Open in rule wizard.
Important:
On QRadar 7.4.1 Fix Pack 2 or later, you can change the date range for the trend of
the selected rule in the Offense creation by current rule in a certain time chart.
The date range defaults back to the filtered date range (1 month) when you close
and reopen the rule.
On QRadar 7.3.3, the default date range is 3 days and cannot be edited.
• To enable or disable rules, make sure that the Rule enabled column is visible in the
report, and then switch the toggle to On or Off.
Important: You cannot disable an enabled rule if it has dependents. You cannot
enable a rule if it has any disabled or noninstalled dependencies. A list of
dependents or dependencies is available for review in the warning messages.
• Edit MITRE mappings for rules or building blocks. For more information, see Editing
MITRE mappings in a rule or building block.
• To add custom rule attributes to the selected rule or building block, follow these
steps:
• Click Open in rule wizard on the report menu bar.
• In the center pane of the screen, expand the Custom attributes section.
• If no custom attributes are currently added to the rule, click the plus sign
icon and select the checkbox for each relevant attribute and value. Then,
click Save and apply.
Tip: You can also define new custom attributes in this window.
• If you want to add more values to the custom attributes already added to the
rule, click the plus sign icon for the attribute and select values from the list.
Tip: You can also define new custom attribute values in this window.
• Close the wizard.
Tip: To fully manage custom rule attributes and their values, such as editing
or deleting, go to Settings > Custom Rule Attributes.
• To investigate QRadar User Behavior Analytics rules, see Investigating user
behavior analytics rules.
• Visualize your rules and building blocks after you organize the report data.
 • Export the report as a CSV or XML file to share with others.
• Export the MITRE mappings as a JSON file to share with others.

Filtering rules and building blocks by their properties

Tune your rules or building blocks by filtering their attributes, such as type, origin, group, and many
more. You can also tune rules or building blocks by filtering them based on their test definitions.
For example, you can add a test that matches only events from a specific log source. Examine and
improve your MITRE ATT&CK coverage by filtering your rules based on their mappings to tactics
and techniques.

Before you begin

If you want to filter by MITRE ATT&CK tactics, you must first map your rules to MITRE tactics and
techniques. For more information, see Editing MITRE mappings in a rule or building block.

About this task

The more filters that you apply to the rules, the more fine-tuned the list of results you get. QRadar
Use Case Manager uses the OR condition within the options of one filter group, and uses the AND
condition across multiple groups of filters. The only exception to the rule is in the Other
tests filter group, where the AND condition is used for multiple options of that filter group. Any
column that you can filter on can also be added to the rule report through the column selection
feature (gear icon).

As you select filters, the unapplied filter tags appear in the filters row with a lighter colored
background. After you apply the filters, the tags change to a darker colored background.

Procedure
• On the Use Case Explorer page, select from the filters in the Rule attributes section.
The following list describes some of the rule attributes you can filter and how to use
them:
Rule name
Enter a specific rule name or search for it by using regular expressions.
Rule enabled
See which rules are enabled or disabled to ensure that your system generates
meaningful offenses for your environment.
Rule category
Filter by custom or anomaly detection rules in the report. Custom rules perform
tests on events, flows, and offenses to detect unusual activity in your network.
Anomaly detection rules perform tests on the results of saved flow or event
searches as a means to detect when unusual traffic patterns occur in your network.
Group
Categorize the rules or building blocks into groups to help you efficiently view and
track your rules. For example, you can view all rules that are related to
compliance. Select specific groups or click Select all.
 Tip: The Unassigned filter helps you see which rules don't belong to a group, such
as "Amazon AWS" or "Compliance". Apply the filter and then edit the filtered rules in
the rule wizard to add more information and make them more robust.
Action
Select the action that you want the rule to take when an event occurs.
Tip: The Unassigned filter helps you see which rules don't have an action, such as
"Event is part of an offense" or "Severity is set". Apply the filter and then edit the
filtered rules in the rule wizard to add more information and make them more
robust.
Response
Select the response that you want QRadar to take when a rule is triggered.
Tip: The Unassigned filter helps you see which rules don't have a response, such as
"Email" or "Send to Local Syslog". Apply the filter and then edit the filtered rules in
the rule wizard to add more information and make them more robust.
Creation and modification dates
Use the date filters to see what changed during the last week, or to see rules that
were modified. The modification date shows the rules that were modified but not
the modified content of the rules.
Notes
Enter a specific note or search for it by using regular expressions. For example, you
can enter ^$ to find rules with empty notes and then add information to the note.
User Behavior Analytics rules
Filter rules on whether they are related to IBM QRadar User Behavior Analytics.
This filter displays only when the QRadar User Behavior Analytics app is installed in
your QRadar deployment.
Tips: For a rule to be considered related to QRadar User Behavior Analytics, the
following conditions must be met:
• The Dispatch New Event option must be selected in the Rule Response.
• The User Behavior Analytics risk score must be set on the Rule
Details page in QRadar Use Case Manager.
For more information, see Integrating new or existing QRadar content.
• Select from the filters in the Rule activity section. Filtering for inactive rules is
supported on QRadar 7.4.1 or later.
Rule active
Select Never to see which rules have never assigned an event to an offense since
they were installed in QRadar.
Rule not active (timeframe)
The default date is in the past week. Change the time period, or choose to filter rules
that aren't active since a specific date.
• Select from the filters in the Rule tests section. The following list describes some of
the rule tests you can filter:
Test definition
Enter a specific test definition or search for it by using regular expressions.
Log source type
A rule relates to log source types if it directly references the log source type, or if it
references a log source, QID, or event category that maps to the log source type. By
 default, you see only the log source types that are used by log sources in
your QRadar environment. Click Show all types to see the log source types that you
can use directly in a test or by the QID or event categories.
Log sources
A rule relates to log sources when the log source that is referenced by a test is used
in the rule. Use the search filter to find specific log sources to filter or click Select
all to filter all of the log sources in the list. You can filter on the log source name or
by using a regular expression. This type of search is useful when you have hundreds
of thousands of log sources in your environment.
Log source group
A rule relates to log source groups when a log source in the log source group that is
referenced by a test is used in the rule. For example, you can select sensor device as
the log source group and see only rules that run tests on log sources that are part of
the sensor device log source group.
Domains
A rule can work in the context of a single domain or in the context of all domains. If
there is more than one domain in your environment, they are added to the filter list.
Use this option to filter the domains in a multi-domain environment by each
individual domain.
To add a domain column to the rule report, click the gear icon. Scroll down to
the Rule tests section of the window, select Domain in the Test option list, and
then click Apply.
Other tests
Hover over each checkbox label to see the specific rule tests. For example, search for
a rule that references a specific value of a test, such as an IP like "Identity IP is not
0".
Tips:
• To identify source IP addresses only, add a column for Test: IP, and then
a source filter in the Test definition field.
• If you have multi-tenancy, use the Domain test to distinguish rules from one
tenant to another. Select the Domain filter, and then add the Domain column.
• If you're looking for custom properties or reference sets, use the predefined
templates.
• If you want to see the log source types that are used or unused, select the
appropriate filter. For example, the Log source coverage by rule template
shows the rules that are related to log source types based on tests. Assume
that 342 log source types are available in your environment. To see only the
rules for log source types that are currently used (log source types that have
at least one log source), select the Log source type - used filter.
• Select from the filters in the MITRE ATT&CK section. The following options are
available to filter:
Tactics
Select tactics from the list. For example, an Initial Access tactic is used by
adversaries who are trying to get into your network.
 Technique
Search for techniques and their sub-techniques or select them from the list. The
techniques are pre-filtered to match the selected tactic. For example, an Account
Discovery technique occurs when adversaries attempt to get a list of your local
system or domain accounts.
Sub-techniques are identified by a dot in the ID, such as "T1003.002 Security
Account Manager". Sub-techniques provide a more specific description of the
behavior an adversary uses to achieve their goal. For example, an adversary might
dump credentials by accessing the Local Security Authority (LSA) Secrets.
Mapping confidence
Indicates mappings that are assigned a specific level of confidence for rule coverage.
Mapping enabled
Indicates for each rule whether the mapping between the tactic or technique and
rules is turned on. Mappings that are not enabled are not added to the technique
coverage heat map.
• If you have many log sources in your environment, you can search for specific ones
by using the Search field in the Filters pane and then select them to fine-tune the
report. This search can make it easier to find a specific filter in the large list of filters
and log sources.
• To filter content extension attributes, follow the steps in Identifying gaps in QRadar
rule coverage from content extensions.
• To clear the report results, click Clear filters, choose new filters in the left pane, and
then click Apply filters to display new results.
TASK: 2.6 Review and recommend updates to the network hierarchy
2.6.1 Organize systems and networks by roles or similar traffic patterns in the network
hierarchy
2.6.2 Combine multiple CIDRs or subnets into a single network group
2.6.3 Consider using the most effective method to viewing network activity.
- Net Hierarchy does not need to resemble the physical deployment

TASK: 2.7 Review and recommend updates to building blocks and rules
2.7.1 Review active rules that generates offenses
- From QRadar, use Case Manager, Click Active Rules
- Apply filters to active rules to fine-tune the investigation pg. 17
- Filter rules that contribute to offense by time frame
- Select parameters to exclude offenses from results
- Select the closure reason for an offense as filters
- Review offense by rule

2.7.2 Apply Filters

- Apply filters to active rules to fine-tune the investigation
- Filter rules that contribute to offense by time frame
- Select parameters to exclude offenses from results
- Select the closure reason for an offense as filters
- Click Apply Filters
2.7.3 Review by rule, by category and rule, and by closed reason
- Hover over the chart segments to see more details about an offense,
- Hide of show chart legends
- Click legend keys to fine-tune chart display
- Zoom in for further investigation

2.7.4 Tune the rules by choosing the following methods:

- Toggle between the top noisy rules or all the rules from the list
- Add more rules to investigate by selecting a group of rule or an individual rule from the
list

Tuning the active rules that generate offenses

Tuning the top most noisy rules can have a significant impact on reducing false positives. To
investigate IBM® QRadar® offenses, you must view the rules that created the offense.
About this task
Unapplied filter tags appear in the filters row with a lighter colored background. After you
apply the filters, the tags change to a darker colored background.

Procedure
• From the QRadar Use Case Manager main menu, click Active Rules.
• Apply filters to the active rules to fine-tune your investigation.
• Filter the rules that started to contribute to offenses according to the
calendar or by timeframe. The default date is in the last three days. Change
the timeframe, or choose to filter the rules that began to contribute to
offenses between specific dates and times.
• Select parameters to exclude offenses from the results, such as hidden or
closed offenses. Offenses that are marked for follow-up are flagged for
further investigation. You might have offenses that you want to retain
regardless of the retention period; those offenses are protected to prevent
them from being removed from QRadar after the retention period elapses.
Inactive offenses can be removed from visualization so that reports aren't
cluttered.
• Select the closure reason for an offense. For example, you can filter to see
which rules generated the offenses that were closed as false positives. Rules
with many false positives likely need tuning. Offenses that are closed as a
non-issue are usually considered not critical to your organization.
• Click Apply Filters.
• Review the Offenses by rule, Offenses by category and rule, Closed offenses by
reason and rule, Events count trend by rule, and Offense creation trend by
rule charts.
Tip: The Offense creation trend by rule chart is supported on QRadar 7.4.1 Fix
Pack 2 or later.
• Hover over the chart segments to see more details about an offense.
• Hide or show chart legends.
 • Click legend keys to fine-tune the chart display.
• Zoom in for further investigation.
• Expand bar and timeline charts to full screen.
• Export bar and timeline charts to CSV, PNG, or JPG formats.
• View bar and timeline chart data in tabular format. Then, export the data in
CSV format to view offline or share with colleagues.
• In the table, tune the rules by choosing from the following methods:
• Toggle between the top noisy rules or all the rules from the list.
• Add more rules to investigate by selecting a group of rule or an individual
rule from the list.
Tip: The Event count column in the report indicates how many events the
rule associated to the offenses counted in the Offense count column.
The Event count column is supported on QRadar 7.4.1 Fix Pack 2 or later.
• Click Investigate.
• Watch a short video to learn how to use the rule wizard.
• Review each individual rule and the BBs that contribute to the active rule.
For each rule, you can further investigate it by clicking Show dependency
tree or Edit in rule wizard.
• Use the visualization diagram to further fine-tune any related options for the
rule or building block, such as log source types, custom properties, or
reference sets.
• Review the offenses that are generated by each active rule.
• Review the values in the various groups of tests, and tune if necessary.
• Review the MITRE ATT&CK mappings for the rule, and edit if necessary.
• To add custom rule attributes to the selected rule or building block, see Step
10 in Investigating QRadar rules and building blocks.
• To investigate QRadar User Behavior Analytics rules, see Investigating user
behavior analytics rules.
• To return to the Active Rules page, click Active Rules in the breadcrumbs.
• To export selected rule data in the report to CSV format that you can further process
or view in Excel, select the relevant checkboxes and then click Export
QRadar Use Case Manager app
Use the guided tips in the IBM® QRadar® Use Case Manager app to help you ensure that IBM
QRadar is optimally configured to accurately detect threats throughout the attack chain.
QRadar Use Case Manager includes a use case explorer that offers flexible reports that are
related to your rules. QRadar Use Case Manager also exposes pre-defined mappings to
system rules and helps you map your own custom rules to MITRE ATT&CK tactics and
techniques.
Explore rules through visualization and generated reports
• Explore the rules through different filters to ensure that they work as intended.
• Generate reports from predefined templates, such as searches based on rule
response and actions, log source coverage, and many others.
• Customize reports to see only the information that is critical to your analysis.
Tune your environment based on built-in analysis
• Gain tuning recommendations unique to your environment right within the app.
• Identify the topmost offense-generating or CRE-generating rules, and then follow
the guide to tune them.
• Reduce the number of false positives by reviewing the most common configuration
steps. Easily update network hierarchy, building blocks, and server discovery based
on recommendations.

Visualize threat coverage across the MITRE ATT&CK

framework
• Visually understand your ability to detect threats based on ATT&CK tactics and
techniques.
• View predefined QRadar tactic and technique mappings and add your own custom
mappings to help ensure complete coverage.
• Use new insights to prioritize the rollout of new use cases and apps to effectively
strengthen your security posture.

Tuning the active rules that generate CRE events

The Custom Rules Engine (CRE) event report shows which active rules generate CRE events. In
many cases, a rule response is configured to generate CRE events, along with the offense or without
it. The report shows which CRE events were generated most by which rule. In general, if the event
is generated many times per day, the rule is firing too often. Consider tuning the rule. For example,
1 or 2 Source IPs in the report are related to all the CRE events generated by the rule. The Source IP
might need to be added to one of Host Definition BBs that are referenced by the rule. Select the rule
and click Investigate to see which Host Definition to update.
About this task
You can also use this report to test the rules. In this case, the rule response does not include
the offense creation, only the CRE event dispatch. If the report shows that the rule is firing
too often, consider tuning it. If you're using CRE events to test the rule, and the number of
generated CRE events is only a few per week, change the rule response to generate an
offense.
Unapplied filter tags appear in the filters row with a lighter colored background. After you
apply the filters, the tags change to a darker colored background.

Procedure
• From the main menu, click CRE Report.
• Filter the rules according to the calendar or by timeframe. The default date is in the
last three days. Change the timeframe, or choose to filter the rules that began to
contribute to offenses between specific dates and times.
• Select the number of results to return, and click Apply Filters.
• Review the CRE events by rule and the CRE events by category and rule reports.
 • Hover over the chart segments to see more details about an offense.
• Hide or show chart legends.
• Click the legend keys in the CRE events by rule report to fine-tune the chart
display.
• Zoom in for further investigation.
• Expand the CRE events by category and rule chart to full screen.
• Export the CRE events by category and rule chart to CSV, PNG, or JPG
formats.
• View the CRE events by category and rule chart data in tabular format.
Then, export the data in CSV format to view offline or share with colleagues.
• Tune the rules by choosing from the following methods:
• Toggle between the topmost noisy rules or all the rules from the list.
• Add another rule to investigate by selecting a group of rule or an individual
rule from the list.
• Click Investigate.
• Review each individual rule and the BBs that contribute to the CRE event. For
each rule, you can further investigate it by clicking Show dependency
tree or Edit in rule wizard.
• Use the visualization diagram to further fine-tune any related options for the
rule or building block, such as log source types, custom properties, or
reference sets.
• Review the events that are generated by the current rule you selected.
• To instantly refresh the rules from QRadar®, click the Refresh icon.
Otherwise, the app automatically updates data from the Console every 15
minutes.
• Review the threshold values in the tests, and tune if necessary.
• Review the values in the various groups of tests, and tune if necessary.
• Review the MITRE ATT&CK mappings for the rule, and edit if necessary.
• To add custom rule attributes to the selected rule or building block, see step
9 in Investigating QRadar rules and building blocks.
• To investigate QRadar User Behavior Analytics rules, see Investigating user
behavior analytics rules.
• To return to the CRE events page, click CRE Report in the breadcrumbs.
• To export selected rule data in the report to CSV format to process or view in Excel,
select the relevant checkboxes and then click Export.
TASK: 2.8 Describe the different types of rules, including behavioral, anomaly and
threshold

2.8.1 Understand the types of rule behaviors

- Anomaly
- Behavior
- Threshold

2.8.2 Understand how an Anomaly rule is created and how that is different than a Custom
Rule
2.8.3 Create behavior, anomaly and threshold rules in QRadar

• https://www.youtube.com/watch?v=LgksZvchS38

Chapter 3: Threat Hunting

After the initial Offense Analysis and based on technical skills in understanding QRadar
rules and building block design, it is time to focus on the Analyst’s main task of Threat
Hunting. Starting with the results presented in an offense, the Analyst will investigate the
evidence inside an offense, such as event and flow details, triggered rules, payloads, and
more. Utilizing filters and advanced searches the Analyst will be able to distinguish real
threats from false positives.
TASK: 3.1 Investigate Event and Flow parameters

3.1.1 Investigate Event details

- In the Offense Summary window, click Events. The List of Events window shows all events
that are associated with the offense.
- Specify the Start Time, End Time, and View options to view events that occurred within a
specific time frame.
- Click the event column header to sort the event list.
- In the list of events, right-click the event name to apply quick filter options to reduce the
number of events to review. You can apply quick filters to other columns in the event list as
well.
- Double-click an event to view the event details. The Event Information and the Source and
Destination Information window show only the information that is known about the event.
Depending on the type of event, some fields might be empty.
- Learn more about the time fields on the Event Information:
- Field
- Description
- Start Time
- The time that QRadar received the raw event from the log source.
- Storage Time
- The time that QRadar stored the normalized event.
- Log Source Time
 - The time that is recorded in the raw event from the log source.
- In the Payload Information box, review the raw event for information that QRadar did not
normalize. Information that is not normalized does not appear in the QRadar interface, but
it may be valuable to your investigation.
3.1.2 Investigate Flow details
- In the Offense Summary window, click Flows in the upper right menu. The Flow List
window shows all flows that are associated with the offense.
- Specify the Start Time, End Time, and View options to view flows that occurred within a
specific time frame.
- Click the flow column header to sort the flow list.
- In the list of flows, right-click the flow name to apply quick filter options to reduce the
number of flows to review. You can apply quick filters to other columns in the flow list as
well.
- Double-click a flow to review the flow details.
- Learn more about the flow details:
- Event Description
- When the application is not identified in the payload, QRadar uses built-in
decoding to determine the application, and shows Application detected with
state-based decoding in Event Description.
- Source Payload and Destination Payload
- Shows the size of the payload.
- When the size exceeds 64 bytes, the payload might contain additional
information that is not shown in the QRadar interface.
- Custom Rules Partially Matched
- Shows rules for which the threshold value was not met, but otherwise the
rule matched.
- Flow Direction
-Specifies the flow direction, where L indicates local network, and R indicates
remote network.
TASK: 3.2 Perform AQL query

3.2.1 Perform detailed searches to find similar log and flow activity at any level of
granularity:
- On the QRadar Log and Network Activity tabs, select "Advanced" in the list beside the
search field.
- Enter an AQL query and click Search

3.2.2 Understand the AQL and QRadar interfaces

AQL Query structure:

Use Ariel Query Language (AQL) to extract, filter, and perform actions on event and flow
data that you extract from the Ariel database in IBM® QRadar®. You can use AQL to get
data that might not be easily accessible from the user interface.
The following diagram shows the flow of an AQL query.
Figure 1. AQL query flow

Structure of an AQL statement

Use the SELECT statement to select fields from events or flows in the Ariel database, which
are displayed as columns. For example, the following query returns the results that are
shown in the following table:
SELECT sourceip, destinationip, username, protocolid, eventcount FROM events
AQL queries begin with a SELECT statement to select event or flow data from the Ariel
database. You can refine the data output of the SELECT statement by using the WHERE,
GROUP BY, HAVING, ORDER BY, LIMIT, and LAST clauses.
SELECT
Use the SELECT statement to select fields from events or flows. For example, select all
fields from events or flows by typing:
SELECT * FROM events, or SELECT * FROM flows
Use the following clauses to filter and manipulate the data that is returned by the SELECT
statement:

WHERE
Use the WHERE clause to insert a condition that filters the output, for
example, WHERE logsourceid='65'.
GROUP BY
Use the GROUP BY clause to group the results by one or more columns that you
specify in the query, for example, GROUP BY logsourceid.
HAVING
Use the HAVING clause to specify a condition after the GROUP BY clause, for
example, HAVING MAG > 3.
ORDER BY
Use the ORDER BY clause to order the results for a column in the AQL query in an
ascending or descending order, for example, ORDER BY username DESC.
LIMIT
Use a LIMIT clause to limit the number of results that are returned to a specific
number, for example LIMIT 50 to limit the output to 50 results.
LAST
Use a LAST clause to specify a time frame for the query, for example LAST 1 HOURS.
The following example incorporates all of the clauses that are described in the list:
SELECT sourceip, destinationip, username
FROM events
WHERE username = 'test name'
GROUP by sourceip, destinationip
ORDER BY sourceip DESC
LIMIT 10
LAST 2 DAYS
 • SELECT statement
Use the SELECT statement to define the criteria that you use to retrieve event or
flow data.
• WHERE clause
Filter your AQL queries by using WHERE clauses. The WHERE clause describes the
filter criteria that you apply to the query and filters the resulting view to accept only
those events or flows that meet the specified condition.
• GROUP BY clause
Use the GROUP BY clause to aggregate your data by one or more columns. To
provide meaningful results of the aggregation, usually, data aggregation is combined
with aggregate functions on remaining columns.
• HAVING clause
Use the HAVING clause in a query to apply more filters to specific data by applying
filters to the results after the GROUP BY clause.
• ORDER BY clause
Use the ORDER BY clause to sort the resulting view that is based on expression
results. The result is sorted by ascending or descending order.
• LIKE clause
Use the LIKE clause to retrieve partial string matches in the Ariel database.
• COUNT function
The COUNT function returns the number of rows that satisfy the WHERE clause of a
SELECT statement.
• Quotation marks
In an AQL query, query terms and queried columns sometimes require single or
double quotation marks so that QRadar can parse the query.
• Sample AQL queries
Use Ariel Query Language (AQL) queries to retrieve data from the Ariel database
based on specific criteria.
Time criteria in AQL queries:
Define time intervals in your AQL queries by using START and STOP clauses, or use the
LAST clause for relative time references.

Define the time settings that are passed to the AQL query
The SELECT statement supports an arieltime option, which overrides the time settings.
You can limit the time period for which an AQL query is evaluated by using the following
clauses and functions:
• START
• STOP
• LAST
• NOW
• PARSEDATETIME
START
You can pass a time interval to START selecting data (from time), in the following formats:
yyyy-MM-dd HH:mm
yyyy-MM-dd HH:mm:ss
yyyy/MM/dd HH:mm:ss
yyyy/MM/dd-HH:mm:ss
yyyy:MM:dd-HH:mm:ss
The timezone is represented by 'z or Z' in the following formats:
yyyy-MM-dd HH:mm'Z'
yyyy-MM-dd HH:mm'z'
Use START in combination with STOP.
Examples
SELECT *
FROM events WHERE userName IS NULL
START '2014-04-25 15:51'
STOP '2014-04-25 17:00'
Returns results from: 2014-04-25 15:51:00 to 2014-04-25 16:59:59

SELECT *
FROM events WHERE userName IS NULL
START '2014-04-25 15:51:20'
STOP '2014-04-25 17:00:20'
Returns results from: 2014-04-25 15:51:00 to 2014-04-25 17:00:59

SELECT * from events

START PARSEDATETIME('1 hour ago')
STOP PARSEDATETIME('now')
STOP is optional. If you don't include it in the query, the STOP time is = now

STOP
You can pass a time interval to STOP selecting data (end time), in the following formats:
yyyy-MM-dd HH:mm
yyyy-MM-dd HH:mm:ss
yyyy/MM/dd HH:mm:ss
yyyy/MM/dd-HH:mm:ss
yyyy:MM:dd-HH:mm:ss
The timezone is represented by 'z or Z' in the following formats:
yyyy-MM-dd HH:mm'Z'
yyyy-MM-dd HH:mm'z'
Use STOP in combination with START.
Examples
SELECT * FROM events
WHERE username IS NULL
START '2016-04-25 14:00'
STOP '2016-04-25 16:00'
 SELECT * FROM events
WHERE username IS NULL
START '2016-04-25 15:00:30'
STOP '2016-04-25 15:02:30'

Use any format with the PARSEDATETIME function, for example,

SELECT *
FROM events
START PARSEDATETIME('1 day ago')
Even though STOP is not included in this query, the STOP time is = now.

Select * FROM events

START PARSEDATETIME('1 hour ago')
STOP PARSEDATETIME('now')
SELECT * FROM events
START PARSEDATETIME('1 day ago')
Select *
FROM events
WHERE logsourceid = '69'
START '2016-06-21 15:51:00'
STOP '2016-06-22 15:56:00'

LAST
You can pass a time interval to the LAST clause to specify a specific time to select data from.
The valid intervals are MINUTES, HOURS, and DAYS
Examples
SELECT * FROM events
LAST 15 MINUTES
SELECT * FROM events
LAST 2 DAYS
SELECT * from events
WHERE userName ILIKE '%dm%'
LIMIT 10
LAST 1 HOURS

Note: If you use a LIMIT clause in your query, you must place it before START and STOP
clauses, for
example:

SELECT *
FROM events
LIMIT 100
START '2016-06-28 10:00'
STOP '2016-06-28 11:00'
Time functions
Use the following time functions to specify the parse time for the query.

NOW
Purpose
Returns the current time that is expressed as milliseconds since the time 00:00:00
Coordinated Universal Time (UTC) on January 1, 1970.
Example
SELECT ASSETUSER(sourceip, NOW())
AS 'Asset user' FROM events

Find the user of the asset at this moment in time (NOW).

PARSEDATETIME

Purpose
Pass a time value to the parser, for example, PARSEDATETIME('time reference').
This 'time reference' is the parse time for the query.
Example
SELECT * FROM events
START PARSEDATETIME('1 hour ago')

AQL logical and comparison operators:

Operators are used in AQL statements to determine any equality or difference between
values. By using operators in the WHERE clause of an AQL statement, the results are
filtered by those results that match the conditions in the WHERE clause.
The following table lists the supported logical and comparison operators.
Examples of logical and comparative operators
• To find events that are not parsed, type the following query:
SELECT * FROM events
WHERE payload = 'false'
• To find events that return an offense and have a specific source IP address, type the
following query:
SELECT * FROM events
WHERE sourceIP = '192.0.2.0'
AND
hasOffense = 'true'
• To find events that include the text "firewall", type the following query:
SELECT QIDNAME(qid)
AS EventName,
* FROM events
WHERE TEXT SEARCH 'firewall'

Ariel Query Language in the QRadar interface:

Using AQL can help enhance advanced searches and provide specific results.
When you use AQL queries, you can display data from all across QRadar® in the Log
Activity or Network Activity tabs.
To use AQL in the search fields, consider the following functions:
• In the search fields on the Log Activity or Network Activity tabs, type Ctrl + Space
to see the full list of AQL functions, fields (properties), and keywords.
• Ctrl + Enter helps you create multi-line AQL queries, which makes the queries more
readable.
• By using the copy (Ctrl + C) and paste (Ctrl + V) keyboard commands, you can copy
directly to and from the Advanced search field.
Note: Ensure that you use appropriate quotation marks when you copy queries to the
search field.
The AQL categories are listed with the entered component in the interface. The following
table lists and explains the different categories:
Figure 1. AQL in the advanced search field

TASK: 3.3 Search & filter logs by specific log source type

3.3.1 Searching events:

- Click the Log Activity tab.
- On the toolbar, select Search > New Search.
- In the Time Range pane, define the time range for the event search:
- Click Recent.
- In the Recent list, select Last 6 Hours.
- In the Search Parameters pane, define the search parameters:
- In the first list, select Category [Indexed].
 - In the second list, select Equals to.
- In the High-Level Category list, select Authentication.
- In the Low-Level Category list, accept the default value of Any.
- Click Add Filter.
- In the Column Definition pane, select Event Name in the Display list and drag it to the
Columns list.
- Click Search.
3.3.2 Filtering Events:
- To apply a filter, click any of the following categories to see filtering options for that
category:
- Event Time
- Magnitude
- Log Source Name
- Category
- Source IP
- Source Port
- Destination IP
- Destination Port
- Event Name
- User
- To include only events with specific attributes, select that attribute in the filters list. To
exclude events with specific attributes, click the vertical ellipsis icon next to the attribute,
and click Apply IS NOT Filter.
Tip: You can right-click on a Log Source, Source IP, Destination IP, Category, or Username in
the events table and quickly apply an IS or IS NOT filter to the events.
- To sort the events table in ascending or descending order by an attribute, click the
appropriate table heading.
- To clear individual filters, click the close icon [x] on the filter indicator. To clear all filters,
click Clear filters.
- Click Update events to refresh the events results.

Searching events:
You can search for all authentication events that IBM® QRadar® received in the last 6 hours.
Procedure
• Click the Log Activity tab.
• On the toolbar, select Search > New Search.
• In the Time Range pane, define the time range for the event search:
• Click Recent.
• In the Recent list, select Last 6 Hours.
• In the Search Parameters pane, define the search parameters:
• In the first list, select Category [Indexed].
• In the second list, select Equals to.
• In the High Level Category list, select Authentication.
 • In the Low Level Category list, accept the default value of Any.
• Click Add Filter.
• In the Column Definition pane, select Event Name in the Display list and drag it to
the Columns list.
• Click Search.
Filtering events:
Filter the QRadar Analyst Workflow Events page to display only the specific events you want to
investigate.

As you apply filters, the events table displays only the events that meet your filter criteria.
Tip: You can copy and paste the URL from your browser to share the events page, including
all filters and configuration options.
Procedure
• To apply a filter, click any of the following categories to see filtering options for that
category:
• Event Time
• Magnitude
• Log Source Name
• Category
• Source IP
• Source Port
• Destination IP
• Destination Port
• Event Name
• User
• To include only events with specific attributes, select that attribute in the filters list.

To exclude events with specific attributes, click the vertical ellipsis icon [ ] next
to the attribute, and click Apply IS NOT Filter.
Tip: You can right-click on a Log Source, Source IP, Destination IP, Category, or
Username in the events table and quickly apply an IS or IS NOT filter to the events.
• To sort the events table in ascending or descending order by an attribute, click the
appropriate table heading.
• To clear individual filters, click the close icon [x] on the filter indicator. To clear all
filters, click Clear filters.
• Click Update events to refresh the events results.
TASK: 3.4 Configure a search to utilize time series

3.4.1 Create a time series graph:

- Click the Log Activity or Network Activity tab.
- To create a grouped search, follow these steps:
 - On the toolbar, click Search > New Search.
- From the Available Saved Searches, select a search and click Load.
- Go to the Column Definition pane and if the Group By list box is empty, from the
Available Columns list, select a column.
- Click Search.
- To use a grouped search, on the toolbar, click Quick Searches and select a grouped
search.
- In the Charts pane, click the Configure icon ().
- Configure the following parameters:
- Value to Graph
- The object type that you want to graph on the Y axis of the chart.
- Options include all normalized and custom event or flow parameters that are
included in your search parameters.
- Display Top
- The number of objects that you want to view in the chart. The default is 10. If you
include more than 10 items in your chart, your data might be illegible.
- Chart Type
- If your bar, pie, or table chart is based on saved search criteria with a time range of
more than 1 hour, you must click Update Details to update the chart and populate
the event details.
- Capture Time Series Data
- Enables time series data capture. When you select this check box, the chart begins
accumulating data

Configuring a time series chart:

You can display interactive time series charts that represent the records that are matched by a
specific time interval search.

Procedure
• In the chart title bar, click the Configure icon.
• In the Value to Graph list, select Destination IP (Unique Count).
• In the Chart Type list, select Time Series.
• Click Capture Time Series Data.
• Click Save.
• Click Update Details.
• Filter your search results:
• Right-click the event that you want to filter.
• Click Filter on Event Name is <Event Name>.
• To display the event list that is grouped by the user name, select Username from
the Display list.
• Verify that your search is visible on the Dashboard tab:
• Click the Dashboard tab.
• Click the New Dashboard icon.
• In the Name field, type Example Custom Dashboard.
 • Click OK.
• In the Add Item list, select Log Activity > Event Searches > Example
Search 1.
Result: The results from your saved event search display in the Dashboard.

Time series charts in QRadar Pulse:

At first glance, creating a time series chart from relational data in QRadar® Pulse can be
challenging. The amount of data that is returned by an AQL query can be unwieldy, but with
some background knowledge and careful planning, you can produce relevant and
meaningful time series charts.
Note: After you read about time series charts, create a dynamic time series chart by
following the procedure in Tracking the top five most active devices in the last ten minutes.
In QRadar Pulse V2.1.4 or later, the time series chart has a dynamic series option that is
useful when you don't know which devices you want to track, or find it difficult to make
time series charts work properly. It automatically detects series and displays them as
separate lines on the time series chart.
Ordering a metric by starttime does yield a time series, like the following AQL query, but
the amount of returned data can be unwieldy to work with and understand.
select starttime as 'Start Time',
SUM(eventcount) as 'Event Count (Sum)'
from events
where eventcount <> NULL
GROUP BY starttime
order by starttime
LAST 60 minutes

The amount of returned data can result in a noisy chart that doesn't provide much
information. The event start times might not occur at regular intervals, which can create
gaps in the data set.Figure 1. Too much data results in noisy results
Creating intervals in a time series query
The first step is to decide the type of interval to use for your data analysis. Do you want to
look at data from a narrow interval, such as every second? Or in larger intervals of every
minute or every hour? This decision is important because data points must be grouped in
intervals so that a metric is calculated.
Using the original query, you can group the data by using one of the following techniques:
• Using the GROUP BY clause to create an interval: GROUP BY starttime/60000.
Because starttime is in displayed in milliseconds, if you divide by 60,000 (60
seconds x 1000 milliseconds), you create groups or intervals of 60 seconds (1
minute).
• Changing the ORDER BY clause to use the aggregate sTime.
The query changes to the following code:

select starttime as 'sTime',

SUM(eventcount) as 'Event Count (Sum)'
from events
where eventcount > 0
GROUP BY starttime/60000
order by "sTime"
LAST 60 minutes

The data is now more visually consumable and ensures that one data point occurs every
minute. Now that the intervals are properly defined, you can use a few strategies to
format the data into a more friendly time series format.
Figure 2. More consumable data results with properly defined intervals

Pivoting rows to columns to create a series

One method for creating a time series chart involves pivoting the rows of data into
columns that directly represent a series in Pulse. For example, if your use case is to count
events for a specific device for each 1-minute interval, you must create a separate
conditional aggregate for each series that you want to plot on the graph.
SUM(IF LOGSOURCETYPENAME(devicetype) = 'System Notification' THEN 1.0 ELSE 0.0)
as system_notification
SUM(IF LOGSOURCETYPENAME(devicetype) = 'SIM Audit' THEN 1.0 ELSE 0.0) as sim_audit

The full query looks like the following example:

SELECT starttime/(1000*60) as 'minute',
(minute * (1000*60)) as 'stime',
SUM(IF LOGSOURCETYPENAME(devicetype) = 'System Notification' THEN 1.0 ELSE 0.0)
as system_notification,
SUM(IF LOGSOURCETYPENAME(devicetype) = 'SIM Audit' THEN 1.0 ELSE 0.0) as sim_audit
FROM events
WHERE devicetype <> NULL
GROUP BY minute
ORDER BY stime asc
LAST 10 minutes

The query takes the row data for both System Notification and SIM Audit devices and
pivots them into separate columns that correspond to a series on the chart:
Figure 3. Returned results for separate columns

The following image shows the view configuration and chart display for pivoting the
rows.Figure 4. Configuring the view and chart display
While this method is fairly efficient to transform relational data into time series data, you
must know ahead of time what data you're looking for.

Creating a dynamic time series

What if you don't know ahead of time what devices you're looking for, or you want to
graph the top five most active devices in the last hour? You can create a dynamic time
series in QRadar Pulse V2.1.4. Rather than pivoting rows of data into columns, the second
strategy uses a secondary GROUP BY clause (called "device" in the examples) to create a
dynamic time series.
SELECT starttime/(1000*60) as 'minute',
MIN(starttime) as 'stime',
eventcount as 'eventCount', devicetype as 'deviceType',
LOGSOURCETYPENAME(devicetype) as 'device',
count(*) as 'total'
FROM events
WHERE deviceType IN (
SELECT deviceType FROM (
SELECT devicetype as 'deviceType',
count(*) as 'total'
FROM events
GROUP BY deviceType
ORDER BY total DESC
LIMIT 8
LAST {Time_Span}
)
) and devicetype not in (18,105,147,368)
GROUP BY minute, device
ORDER BY minute asc
LAST {Time_Span}
The returned results for the query look like the following image:
Figure 5. Returned results for device
The difference from the previous method is that the data is not pivoted into columns and
contains repetitions in the time column that is caused by the secondary GROUP BY clause.
By using the dynamic time series option, QRadar Pulse splits the data into a proper time
series format. Select the column that contains the time (stime for the x-axis), the column
that contains the data (total for the y-axis), and the column that contains the GROUP
BY clause (to extract the different series by device).
Figure 6. Splitting the data by device
Although the chart looks the same as the one that was created by the previous method, the
underlying AQL query is much more dynamic. If the log sources change over time, the chart
automatically updates because the values are no longer hardcoded into the query.
However, you need to be aware of some caveats. Because the data rows don't pivot into
columns, the size of the data is much larger and grows proportionately with the number
of devices. QRadar Pulse processes the data, so the size of the data might negatively
impact the overall responsiveness of the browser. To prevent performance
degradation, QRadar Pulse renders the first 20 data series that it detects, and ignores
subsequent series. Limit the size of the data by using the WHERE clause
to LIMIT and ORDER your data sets for use in a dynamic time series. For example, if the
use case is "count the top three most active devices in the last 10 minutes, excluding
'Health Metrics'," create the following query:
SELECT starttime/(1000*60) as 'minute', (minute * (1000*60)) as 'stime',
LOGSOURCETYPENAME(devicetype) as 'device', count(*) as 'total'
FROM events
WHERE device IN (
SELECT deviceList FROM (
SELECT LOGSOURCETYPENAME(devicetype) as deviceList, count(*) as topDevices
FROM events
WHERE deviceList <> 'Health Metrics'
GROUP BY deviceList
ORDER BY topDevices DESC
LIMIT 3
LAST 10 minutes
)
)
GROUP BY minute, device
ORDER BY stime asc
LAST 10 minutes

The query is more efficient, and ensures that the three rendered series correspond to the
top three active devices in the selected time span.
• Tracking the top five most active devices in the last ten minutes
In this example, you create a dynamic time series chart to track the top five most
active devices in your environment in the last ten minutes. In QRadar Pulse V2.1.4
or later, the time series chart has a dynamic series option that is useful when you
don't know which devices you want to track, or find it difficult to make time series
charts work properly. It automatically detects series and displays them as separate
lines on the time series chart.
• Tracking flow data trends over 24 hours
In this example, you learn how to create a time series chart to track all flow data
from a specific interface over the last 24 hours.
• Aggregating data to create a time series chart
In this example, you learn how to create a time series chart to show the number of
events every minute for the SIM User Authentication category. You use global views
to aggregate the data into a format that IBM QRadar Pulse can display.
Creating an aggregated data view in the Log Activity tab
Aggregated data views are accumulated buckets of data that is used to generate reports and
dashboards. These global views are based on saved searches that accumulate the data regularly in
the background. Use the following procedure to create a time series graph for a SIM User
Authentication category.
Procedure
• In IBM® QRadar®, go to the Log Activity tab and switch to the Advanced
Search field.
• To make the global view reusable for any category, remove the "where" clause in the
previous example, enter the following AQL query, and then click Search.
select categoryname(category) as catname, category, count(category) as catcount, first(starttime) as Time
from events
group by category, starttime/60000
order by Time
last 1 hours

Note:
By default, QRadar displays two "Top 10" charts above the results list. You work with these
charts to create the Global View. By default, it looks something like the following example:

• On the pie chart, click Settings to display the configuration settings.

• To convert the chart into a time series chart that works with Pulse,
select Time in the Value to Graph list, and then change the chart type
to Time Series.
 • From the Value to Graph list, select COUNT.
• Select the Capture Time Series Data check box, and then click Save.
The Save Criteria page opens, where you create a saved search and a Global
View.
• Enter Pulse Category Count in the search name.
• Enter values for the following parameters:

• Click OK
Note: After the criteria is saved, the Global View is now active and ready for you to use in IBM
QRadar Pulse.

TASK: 3.5 Analyze potential IoCs

3.5.1 Repeat Event and Flow analysis.
3.5.2 Review IoC reference sets

Reference sets overview:

Use reference sets in IBM® QRadar® to store data in a simple list format.
You can populate the reference set with external data, such as indicators of compromise
(IOCs), or you can use it to store business data, such as IP addresses and user names, that is
collected from events and flows that occur on your network.
A reference set contains unique values that you can use in searches, filters, rule test
conditions, and rule responses. Use rules to test whether a reference set contains a data
element, or configure the rule response to add data to a reference set. For example, you can
create a rule that detects when an employee accesses a prohibited website, and configure
the rule response to add the employee's IP address or user name to a reference set.
For more information about configuring rule responses to add data to a reference set, see
the IBM QRadar User Guide.
Reference sets are the only type of reference data collection that you can manage
in QRadar. You can also use the command-line and the Restful API documentation
interface to manage reference sets.
• Adding, editing, and deleting reference sets
Use a reference set to compare a property value, such as an IP address or user name,
against a list. You can use reference sets with rules to keep watch lists. For example,
you can create a rule to detect when an employee accesses a prohibited website and
then add that employee's IP address to a reference set.
• Viewing the contents of a reference set
View information about the data elements in the reference set, such as the domain
assignment, the expiry on the data, and when the element was last seen in your
network.
• Adding elements to a reference set
Add elements to a reference set when you want IBM QRadar to compare a property
to the element value. Use QRadar to manually add elements to a reference set, or to
import elements from a .csv file.
• Exporting elements from a reference set
Export reference set elements to a .csv file when you want to include the
information in reports, or share the information with people who don't use IBM
QRadar.
• Deleting elements from a reference set
You might need to delete elements from a reference set when an element is added to
the reference set in error, or when you no longer need to compare the element with
other IBM QRadar properties. For example, you might need to remove an asset that
was mistakenly added to an asset exclusion blacklist.
Types of reference data collections:
IBM® QRadar® has different types of reference data collections that can handle different
levels of data complexity. The most common types are reference sets and reference maps.
If you want to use the same reference data in both QRadar SIEM and QRadar Risk Manager,
use a reference set. You can't use other types of reference data collections with QRadar
Risk Manager.
Finding IP address and URL information in X-Force
Exchange:
Use right-click menu options in IBM® QRadar® to find information about IP addresses and
URLs that is found on IBM Security X-Force® Exchange. You can use the information from
your QRadar searches, offenses, and rules to research further or to add information about
IP addresses or URLs to an X-Force Exchange collection.
You can contribute either public or private information to track data in collections when
you research security issues.
A collection is a repository where you store the information that is found during an
investigation. You can use a collection to save X-Force Exchange reports, comments, or any
other content. An X-Force Exchange report contains both a version of the report from the
time when it was saved, and a link to the current version of the report. The collection
contains a section that has a wiki-style notepad where you can add comments that are
relevant to the collection.
For more information about X-Force Exchange, see X-Force
Exchange (https://exchange.xforce.ibmcloud.com/).
Procedure
• To look up an IP address in X-Force Exchange from QRadar, follow these steps:
• Select the Log Activity or the Network Activity tab.
• Right-click the IP address that you want to view in X-Force Exchange and
select More Options > Plugin Options > X-Force Exchange Lookup to open
the X-Force Exchange interface.
• To look up a URL in X-Force Exchange from QRadar, follow these steps:
• Select either the Offenses tab, or the event details windows available on
the Offenses.
• Right-click the URL you want to look up in X-Force Exchange and
select Plugin Options > X-Force Exchange Lookup to open the X-Force
Exchange interface.
TASK: 3.6 Break down triggered rules to identify the reason for the offense

3.6.1 Investigate Event details

- In the Offense Summary window, click Events.
The List of Events window shows all events that are associated with the offense.
- Specify the Start Time, End Time, and View options to view events that occurred within a
specific time frame.
- Click the event column header to sort the event list.
- In the list of events, right-click the event name to apply quick filter options to reduce the
number of events to review. You can apply quick filters to other columns in the event list as
well.
- Double-click an event to view the event details.
The Event Information and the Source and Destination Information window show only the
information that is known about the event. Depending on the type of event, some fields
might be empty.
- Scroll down below the payload to view a list of rules that the event triggered.
- Click on each rule to determine how the event triggered it.
Tuning the active rules that generate offenses:
Tuning the top most noisy rules can have a significant impact on reducing false positives.
To investigate IBM® QRadar® offenses, you must view the rules that created the offense.
Unapplied filter tags appear in the filters row with a lighter colored background. After you
apply the filters, the tags change to a darker colored background.

Procedure
• From the QRadar Use Case Manager main menu, click Active Rules.
• Apply filters to the active rules to fine-tune your investigation.
• Filter the rules that started to contribute to offenses according to the
calendar or by timeframe. The default date is in the last three days. Change
 the timeframe, or choose to filter the rules that began to contribute to
offenses between specific dates and times.
• Select parameters to exclude offenses from the results, such as hidden or
closed offenses. Offenses that are marked for follow-up are flagged for
further investigation. You might have offenses that you want to retain
regardless of the retention period; those offenses are protected to prevent
them from being removed from QRadar after the retention period elapses.
Inactive offenses can be removed from visualization so that reports aren't
cluttered.
• Select the closure reason for an offense. For example, you can filter to see
which rules generated the offenses that were closed as false positives. Rules
with many false positives likely need tuning. Offenses that are closed as a
non-issue are usually considered not critical to your organization.
• Click Apply Filters.
• Review the Offenses by rule, Offenses by category and rule, Closed offenses by
reason and rule, Events count trend by rule, and Offense creation trend by
rule charts.
Tip: The Offense creation trend by rule chart is supported on QRadar 7.4.1 Fix
Pack 2 or later.
• Hover over the chart segments to see more details about an offense.
• Hide or show chart legends.
• Click legend keys to fine-tune the chart display.
• Zoom in for further investigation.
• Expand bar and timeline charts to full screen.
• Export bar and timeline charts to CSV, PNG, or JPG formats.
• View bar and timeline chart data in tabular format. Then, export the data in
CSV format to view offline or share with colleagues.
• In the table, tune the rules by choosing from the following methods:
• Toggle between the top noisy rules or all the rules from the list.
• Add more rules to investigate by selecting a group of rule or an individual
rule from the list.
Tip: The Event count column in the report indicates how many events the
rule associated to the offenses counted in the Offense count column.
The Event count column is supported on QRadar 7.4.1 Fix Pack 2 or later.
• Click Investigate.
• Watch a short video to learn how to use the rule wizard.
• Review each individual rule and the BBs that contribute to the active rule.
For each rule, you can further investigate it by clicking Show dependency
tree or Edit in rule wizard.
• Use the visualization diagram to further fine-tune any related options for the
rule or building block, such as log source types, custom properties, or
reference sets.
• Review the offenses that are generated by each active rule.
• Review the values in the various groups of tests, and tune if necessary.
• Review the MITRE ATT&CK mappings for the rule, and edit if necessary.
 • To add custom rule attributes to the selected rule or building block, see Step
10 in Investigating QRadar rules and building blocks.
• To investigate QRadar User Behavior Analytics rules, see Investigating user
behavior analytics rules.
• To return to the Active Rules page, click Active Rules in the breadcrumbs.
• To export selected rule data in the report to CSV format that you can further process
or view in Excel, select the relevant checkboxes and then click Export.
• Reviewing your network hierarchy
A well-defined and maintained network hierarchy can help prevent the generation
of false positive offenses. The network hierarchy is used to define which IP
addresses and subnets are part of your network. Ensure that all internal address
spaces, both routable and non-routable, are defined within your IBM
QRadar network hierarchy. QRadar can then distinguish your local network from
the remote network. Event and flow context is based on whether the source and
destination IPs are local or remote. Event and flow context, and data from your
network hierarchy are used in rule tests.
• Reviewing building blocks
Building blocks are a reusable set of rule tests that can be used within rules when
needed. Host definition building blocks (BB:HostDefinition) categorize assets and
server types into CIDR/IP ranges. By populating host definition building blocks, IBM
QRadar can identify the type of appliance that belongs to an address or address
range. These building blocks can then be used in rules to exclude or include entire
asset categories in rule tests.
Q: What is the difference between Start Time, Storage Time,
and Log Source Time on the Event Information screen in
QRadar?
Cause
QRadar displays three time stamp fields on events when users view the details of an event. These
three timestamps can have different values depending on where the data originated, when data
arrives, and when it is written to disk in QRadar.

Timestamp values as seen in the user interface:

Figure 1: A sample log off event sent by WinCollect to QRadar

As shown in the example image above, there is a six second delay when the remote Syslog
event "An account was logged off" and when QRadar received it as represented by the
Start Time and Log Source Time.

Answer

Start Time
The Start Time in an event record and represents the time at which the event arrived at
the QRadar appliance. When an event arrives in the event Pipeline an Object is created in
memory, then the start time is set to that time.

Note: In QRadar version 7.3.1 and above the Start Time begins after the EC-ECS Ingress
component of the Event Pipeline.

Storage Time
The Storage Time is when data is written out to disk by the Ariel component at the end of
the Event Pipeline. This can be useful for determining if the Event Pipeline is backed up,
for performance or licensing reasons. When investigating events delayed in the pipeline,
or messages about licensing or dropped events because of licensing, you can look at the
start timestamps and storage timestamps to see how far apart they are. This will give an
indication of how delayed the pipeline may be.

Log Source Time

The Log Source Time is pulled from the event payload itself after the system has parsed
the event. The Log Source Time that is available in the syslog header is the value that is
used. However, for some Log Sources, such as Windows logs that have
a MessageTime field in the body of the payload, or in the Message= area of the payload, we
might convert an epoch timestamp into a time, and then store that into the Log Source
Time, overriding even what's in the syslog header field.

Note:
• If there is no time available in the payload at all, then the log source time field is
populated with the same value as the start time.
• If an event includes a time zone, then we adjust the Log Source Time to account for
the time zone change.

Example:
If an event includes a time zone that is GMT+8 to the Console, the Log Source Time should
be listed as GMT-8 from the time stamp in the event payload. This is so users can
understand when the event occurred based on the Console time.
TASK: 3.7 Recommend changes to tune QRadar SIEM after offense analysis identifies
issues

3.7.1 Review Source and destination IP addresses

3.7.2 Look for remote to remote (R2R) events

3.7.3 Look for potential building block issues

TASK: 3.8 Distinguish potential threats from probable false positives

3.8.1 Distinguish potential threats from probable false positives

- Click the Log Activity tab.
- Optional. If you are viewing events in streaming mode, click the Pause icon to pause
streaming.
- Select the event that you want to tune.
- Click False Positive.
- In the Event/Flow Property pane on the False Positive window, select one of the following
options:
- Event/Flow(s) with a specific QID of <Event>
- Any Event/Flow(s) with a low-level category of <Event>
- Any Event/Flow(s) with a high-level category of <Event>
- In the Traffic Direction pane, select one of the following options:
- <Source IP Address> to <Destination IP Address>
- <Source IP Address> to Any Destination
- Any Source to <Destination IP Address>
- Any Source to any Destination
- Click Tune.
Tuning false positives
You can tune false positive events and flows to prevent them from creating offenses.

Before you begin

To create a new rule, you must have the Offenses > Maintain Custom Rules permission
for creating customized rules to tune false positives. For more information about roles and
permissions, see the IBM® QRadar User Guide.
Procedure
• Click the Log Activity tab, or the Network Activity tab.
• Select the event or flow that you want to tune.
• Click False Positive.
Note: If you are viewing events or flows in streaming mode, you must pause
streaming before you click False Positive.
 • Select one of the following Event or Flow Property options:
• Event/Flow(s) with a specific QID of <Event>
• Any Event/Flow(s) with a low-level category of <Event>
• Any Event/Flow(s) with a high-level category of <Event>
• Select one of the following Traffic Direction options:
• <Source IP Address> to <Destination IP Address>
• <Source IP Address> to Any Destination
• Any Source to <Destination IP Address>
• Any Source to any Destination
• Click Tune.
QRadar® prevents you from selecting Any Events/Flow(s) and Any Source To
Any Destination. This change creates a custom rule and prevents QRadar from
creating offenses.
Guidelines for tuning system performance
How you tune IBM® QRadar® depends on different scenarios and whether you have one
target or many targets within your network.
To ensure reliable system performance, you must consider the following guidelines:
• Disable rules that produce numerous unwanted offenses.
• To tune CRE rules, increase the rule threshold by doubling the numeric parameters
and the time interval.
• Consider modifying rules to consider the local network context rather than the
remote network context.
• When you edit a rule with the attach events for the next 300 seconds option
enabled, wait 300 seconds before you close the related offenses.
For more information, see the IBM QRadar User Guide.
The following table provides information on how to tune false positives according to these
differing scenarios
Custom rule testing order
When you build custom rules, you must optimize the order of the testing to ensure that the rules do
not impact custom rules engine (CRE) performance.

The tests in a rule are executed in the order that they are displayed in the user interface.
The most memory intensive tests for the CRE are the payload and regular expression
searches. To ensure that these tests run against a smaller subset of data and execute faster,
you must first include one of the following tests:
 • when the event(s) were detected by one or more of these log source types
• when the event QID is one of the following QIDs
• when the source IP is one of the following IP addresses
• when the destination IP is one of the following IP addresses
• when the local IP is one of the following IP addresses
• when the remote IP is one of the following IP addresses
• when either the source or destination IP is one of the following IP addresses
• when the event(s) were detected by one of more of these log sources
You can further optimize QRadar® by exporting common tests to building blocks. Building
blocks execute per event as opposed to multiple times if tests are individually included in a
rule.
For more information about optimizing custom rules, see the IBM® QRadar User Guide.
False positives configuration
Manage the configuration of false positives to minimize their impact on legitimate threats and
vulnerabilities. To prevent IBM® QRadar® from generating an excessive number of false positives,
you can tune false positive events and flows to prevent them from creating offenses.
False positive rule chains
The first rule to execute in the custom rules engine (CRE) is FalsePositive:False Positive Rules
and Building Blocks. When it loads, all of its dependencies are loaded and tested.

When an event or flow successfully matches the rule, it bypasses all other rules in the CRE
to prevent it from creating an offense.

Creating false positive building blocks

When you create false positive building blocks within QRadar, you must review the
following information:
Naming conventions
Use a methodology similar to the default rule set, by creating new building blocks by using
the following naming convention:

<CustomerName>-BB:False Positive: All False Positive Building Blocks,

where <CustomerName> is a name that you assign to the false positive building
block.
False positive building blocks
Building blocks must contain the test: and when a flow or an event matches any of the
following rules. This test is a collection point for false positive building blocks and helps
you to quickly find and identify customizations. Note the following guidelines when you
create your false positive building blocks:

• When the <CustomerName>-BB:False Positive: All False Positive Building

Block is created, add it to the test in the rule FalsePositive: False Positive
Rules and Building Blocks.
• When the new false positive building block is created, you can create new
building blocks to match the traffic that you want to prevent from creating
 offenses. Add these building blocks to the <CustomerName>-BB:False
Positive: All False Positive Building block.
• To prevent events from creating offenses, you must create a new building
block that matches the traffic that you are interested in. Save as a building
block <CustomerName>-BB:False Positive: <name_of_rule>, then
edit <CustomerName>-BB:False Positive: All False Positive building
blocks, to include the rule that you created.
Note: If you add a rule or building block that includes a rule to the FalsePositive: False
Positive Rules and Building Blocks rule, the rule that you add runs before the event
bypasses the CRE and might create offenses by overriding the false positive test

TASK: 3.9 Add a reference set based filter in log analysis

3.9.1 This task is covered under Search & filter logs task.

3.9.2 Add a reference set based filter in log analysis

- On the navigation menu, click Admin.
- In the System Configuration section, click Reference Set Management.
- To add a reference set:
- Click Add and configure the parameters.
- Learn more about reference set parameters: The following table describes each of
the parameters that are used to configure a reference set.
- Name
- The maximum length of the reference set name is 255 characters.
- Type
- Select the data types for the reference elements. You can't edit the Type parameter
after you create a reference set. The IP type stores IPv4 addresses. The Alphanumeric
(Ignore Case) type automatically changes any alphanumeric value to lowercase. To
compare obfuscated event and flow properties to the reference data, you must use an
alphanumeric reference
- Time to Live of elements
-Specifies when reference elements expire. If you select the Lives Forever default
setting, the reference elements don’t expire. If you specify an amount of time, indicate
whether the time-to-live pg. 25 interval is based on when the data was first seen, or was
last seen. QRadar removes expired elements from the reference set periodically (by default,
every 5 minutes).
- When elements expire
- Specifies how expired reference elements are logged in the qradar.log file when
they are removed from the reference set. The Log each element in a separate log entry
option triggers an Expired ReferenceData element log event for each reference element
that is removed. The event contains the reference set name and the element value. The Log
elements in one log entry option triggers one Expired ReferenceData element log event for
all reference elements that are removed at the same time. The event contains the reference
set name and the element values. The Do not log elements option does not trigger a log
event for removed reference elements.
- Click Create.
 - Click Edit or Delete to work with existing reference sets.

TASK: 3.10 Investigate the payload for additional details on the offense

3.10.1 Investigate flows

3.10.2 Determine what sort of things to use from payload.

- AQL searches for parameters that "do not match" to identify potential new custom entries

Importing Yara rules

You can import your existing Yara rules into IBM® QRadar® Incident Forensics and IBM QRadar
Network Insights, and use those rules for matching and flagging malicious content. More than one
Yara rule can exist in an imported file. Uploading a new Yara rules file replaces all existing Yara
rules within the system. Upload existing rules in the new file to retain them.
Procedure
• Click Main Menu > Admin and select Suspect Content Management.
• Click Select File.
• In the File Upload window, browse to the file you want to import and click Open.
Important: Yara rule names must be unique.
Results
You see a message when the Yara rule is imported successfully.

Deleting Yara rules

You can delete all existing Yara rules from IBM® QRadar® Incident Forensics. You upload a file that
contains a single empty rule to turn off Yara rules.
Procedure
• To create a new file that contains a single empty rule, use the following steps:
• Copy the following rule into a text editor of your choice:
rule empty
{
condition:
false
}
• Save as a text file.
• On the navigation menu ( ), click Admin.
• Select Suspect Content Management.
• Click Select File.
• In the File Upload window, browse to the file you created in Step 1 and click Open.
• Click Save.
Results
The single rule always returns a false result, which allows it to pass the validator. The
single rule deletes all existing rules, and is inserted into the database. The single rule never
flags content as suspicious.

Managing suspicious content

As an administrator, you can flag suspicious content by using the Suspect Content
Management feature.
Yara rules
To flag suspicious content in the files that are found in QRadar® Incident
Forensics network traffic, you can import and use existing Yara rules to specify the custom
rules that are run on the files.
Each Yara rule starts with the keyword rule followed by a rule identifier. Yara rules are composed
of two sections:
String definition
In the strings definition section, specify the strings to form part of the rule. Each string
uses an identifier that consists of a dollar sign ($) followed by a sequence of alphanumeric
characters that are separated by underscores.
Condition
In the condition section, define the logic of the rule. The condition section must contain a
Boolean expression that defines the conditions in which a file satisfies the rule.
The following example shows a simple Yara rule that looks for str1 at an offset of 25 bytes into
the file:

rule simple_forensics : qradar

{
meta:
description = "Simple Yara rule."

strings:
$str1 = "pattern of interest"

condition:
$str1 at 25
}

The following example shows a more complex Yara rule that flags content that contains the hex
sequence, and str1 at least three times:

rule ibm_forensics : qradar

{
meta:
description = "Complex Yara rule."
 strings:
$hex1 = {4D 2B 68 00 ?? 14 99 F9 B? 00 30 C1 8D}
$str1 = "IBM Security!"

condition:
$hex1 and (#str1 > 3)
}
When the Yara rule is uploaded, the decapper uses rules that are specified when it finds a
file in a recovery or a PCAP upload. If there is matching content that is found,
a SuspectContent field is added under the Attributes tab for a document. The Suspect
Content Description property is populated with the Yara rule name and any tags that are
identified by the rule.
Restriction: Implementation of Yara modules is not currently available.

TASK: 3.11 Recommend adding new custom properties based on payload data

3.11.1 Review the payload.

- See what's left after you exclude known entities from payload.
- Do this with AQL?

3.11.2 Custom property management

- Click the Log Activity tab or the Network Activity tab.
- If you are viewing the events or flows in streaming mode, click the Pause icon to pause
streaming.
- Double-click the event or flow that contains the data that you want to extract, and then click
Extract Property.
- In the Property Type Selection pane, select the type of custom property that you want to
create.
- Configure the custom property parameters.
- Click the help icon to see information about the custom property parameters.
- If you are creating an extraction-based custom property that is to be used in rules, search
indexes, or forwarding profiles, ensure that the Parse in advance for rules, reports, and
searches check box is selected.
- Optional: Click Test to test the expression against the payload.
- Click Save.
Creating a custom property
Create a custom property to extract data that IBM® QRadar® does not typically show from the
event or flow payloads. Custom properties must be enabled, and extraction-based custom
properties must be parsed, before you can use them in rules, searches, reports, or for offense
indexing.
Before you begin
QRadar includes a number of existing custom event properties that are not enabled or
parsed by default. Ask your administrator to review the custom event property that you
want to create to ensure that it does not exist.
To create custom event properties, you must have the User Defined Event
Properties permission.
To create custom flow properties, you must have the User Defined Flow
Properties permission. You must also set the IPFIX Additional Field Encoding field
to Payload or TLV and Payload.
Users with administrative capabilities can create custom event and flow properties by
selecting Custom Event Properties or Custom Flow Properties on the Admin tab.
You must configure a flow collector to export data to a flow processor. For more
information, see Configuring the Flow Collector format.
About this task
Although multiple default custom properties might have the same name and the same log
source, they can have different regex expressions, event names, or categories. For example,
there are multiple custom properties for Microsoft Windows Security Event Log
called AccountName, but each one is defined by a unique regex expression.
Procedure
• Click the Log Activity tab or the Network Activity tab.
• If you are viewing the events or flows in streaming mode, click the Pause icon to
pause streaming.
• Double-click the event or flow that contains the data that you want to extract, and
then click Extract Property.
• In the Property Type Selection pane, select the type of custom property that you
want to create.
• Configure the custom property parameters.
Click the help icon ( ) to see information about the custom property parameters.
• If you are creating an extraction-based custom property that is to be used in rules,
search indexes, or forwarding profiles, ensure that the Parse in advance for rules,
reports, and searches check box is selected.
• Optional: Click Test to test the expression against the payload.
• Click Save.
TASK: 3.12 Perform "right-click Investigations" on offense data
3.12.1 Perform "right-click Investigations" on offense data
- Open the Log Activity tab.
- In the Log Activity tab, right-click an event to view options for investigations:
- Filter on
- False positive - Select this option to open the False Positive window, which will allow you to
tune out events that are known to be false positives from creating offenses. This option is disabled in
streaming mode.
- More options
- Navigate: View by network, View source summary, View destination summary
 - Information: DNS Lookup, Whois Lookup, Port Scan, Asset profile, Search Events,
Search Flows
- Plugin options: X-Force Exchange Lookup
- Quick filter - Match or do not match the selection
Right-click menu options
On the Log Activity tab, you can right-click an event to access more event filter
information.
The right-click menu options are:

Tuning false positive events from creating offenses

You can use the False Positive Tuning function to prevent false positive events from creating
offenses.

Before you begin

You can tune false positive events from the event list or event details page.

About this task

You can tune false positive events from the event list or event details page.
You must have appropriate permissions for creating customized rules to tune false
positives.
For more information about roles, see the IBM® QRadar® Administration Guide.
Procedure
• Click the Log Activity tab.
• Optional. If you are viewing events in streaming mode, click the Pause icon to pause
streaming.
• Select the event that you want to tune.
• Click False Positive.
• In the Event/Flow Property pane on the False Positive window, select one of the
following options:
• Event/Flow(s) with a specific QID of <Event>
• Any Event/Flow(s) with a low-level category of <Event>
• Any Event/Flow(s) with a high-level category of <Event>
• In the Traffic Direction pane, select one of the following options:
• <Source IP Address> to <Destination IP Address>
• <Source IP Address> to Any Destination
• Any Source to <Destination IP Address>
• Any Source to any Destination
• Click Tune