QRadar Administrador Avanzado

IBM Security QRadar 7.
2 SIEM
Advanced Administration Course
Copyright 2013, ScienceSoft Inc.
Abstract
This introductory course to IBM Security QRadar SIEM enables administrators of QRadar to use the full
potential of QRadar reporting and offense mechanisms in their network environment. Administrators
gain knowledge on how to create new users, log sources, understand the importance of connecting
Vulnerability Scanners, configure Log retention, and the creation and fine tuning of QRadar rules.
The following topics are to be covered in details: Regular Expressions, custom properties, building
Universal DSM Log Source eXtensions (LSX), and creation of rules.
Intended auditory: IBM Security QRadar SIEM Administrators. Each trainee must be given an ID to
successfully complete the lab training session.
Course duration: 2 days.
Connect to Lab Environment

How to connect to the QRadar Lab Environment:
https://qradar.scnsoft.com
1.
Go to
2.
If successful, you should see QRadar console login page.
Agenda
Day 1
1. Introduction to QRadar administration features and functionality
User roles and security profiles
Create and customize network and remote hierarchies
Reference Sets management
Configure Vulnerability Scanner
Configure Routing Rules
Configure Retention Periods
2. Security Events normalization
Regular Expressions
Common normalization fields
Creating and managing custom properties
3. Building LSX (normalization part)
LSX structure
Obligatory fields
Optional fields
Patterns and matchers
Values extraction
Timestamp formatting
LSX deployment
Testing events normalization
Agenda
Day 1
4. Building LSX (mapping part)
QRadar event categories (High and Low Level)
Proper category assignment best practice
EventCRE vs Custom QID
Creating new QIDs
Mapping events in UI
Testing events mapping
Day 2
1. Building blocks (BB) overview and specifics. Enabling custom BB.
Host definitions
Network definitions
False positives
User Tuning / User Defined False Positives Tunings
2. Rules overview
Custom Rules
o Event rule
o Flow rule
o Common rule
o Offense rule
Agenda
Day 2
Anomaly Detection Rules

o Anomaly rule
o Behavioral rule
o Threshold rule
3. Creating rules
Functions (rule tests) overview
Using custom properties and reference sets in rules tests
Rule responses
o Classic responses (SNMP, Syslog, E-Mail, IF-MAP)
o Specific responses (Reference Set, Reference Map, Trigger Scan)
o Including events into offense
o Indices
o Naming convention. Renaming offenses
4. Tuning rules
Optimizing Custom Rules
Creating an OR Condition within the CRE
Cleaning the SIM Model
Identifying Network Assets
Agenda
Day 2
3. Fine tuning false positives
From event properties
By Routing Rules
By rule thresholds update
Discovering Servers
Populating Building Blocks
False Positive Rule Chains
Cleaning-up fine tunings
4. Analyzing Offenses
5. QRadar Risk Manager
QRM Overview
QRM Deployment
QRM Adapters
QRM use cases
Day 1
Introduction to QRadar administration

features and functionality
User roles and security profiles
All users that are allowed to access IBM Security QRadar SIEM must be configured first. The
following items are assigned for each user:
User role;
The role represents granted user privileges to access specific functionality and
information in QRadar. Default roles are Admin (full access) and All (limited access).
Additional user roles can be created to meet the requirements for user permissions.
The following basic operations are available for user roles management:
Create a user role;
Edit a user role;
Delete a user role.
Security profile;
The profile provides access to networks and log sources for QRadar users. Default
security profile is for administrative users and allows access to all networks and all log
sources. Additional security profiles can be created to meet the requirements for
accessing networks and log sources.
The following basic operations are available for security profiles management:
Create a security profile;
Edit a security profile;
Duplicate a security profile;
Delete a security profile.

Security profile management includes permission precedence, which allows QRadar to
display the relevant to permission information in Log Activity tab and Network Activity tab.
The following options are available:
No Restrictions;
Network Only;
Log Source Only;
Network AND Log Sources;
All conditions MUST be met.
Network OR Log Sources.
Any condition MUST be met.
The following basic operations are available for security profiles management:
Create a security profile;
Edit a security profile;
Duplicate a security profile;
Delete a security profile.

Task 1: Create 6 different users on the QRadar. Each user will be given Admin user role
and Admin security profile for the simplicity reasons. The password will be the same as
the username.
Trainee1
Trainee2
Trainee3
Trainee4
Trainee5
Trainee6

Create and customize network and remote hierarchies
QRadar SIEM utilizes network hierarchy to understand the network traffic and provide the
ability to view the network activity across the entire network infrastructure. Network
hierarchy needs to be defined by a range of IP addresses representing geographical
location and/or business units (i.e. Europe Office, Marketing Dept.). The following best
practices are applied:
Group units with similar behavior;
Group units with similar traffic patterns;
Separate unique units;
Top the traffic consumers;
15 units per group average;
Group subnets (Classless Inter-Domain Routings, CIDRs) into single network group:
Group
IP addresses
Accounting
10.1.1.0/25
Marketing
10.1.2.0/25
Group related servers into multi-CIDR objects:

Group
IP addresses
Databases
10.1.5.10/32
10.1.10.20/32
10.1.20.30/32

Group units by top parent group. Nest 2 or more subgroups, if needed.
Acceptable CIDR values are:

Supernets:
/1/8 Class A networks (16,777,214 - 2,147,483,392 hosts);
10.0.0.0/8
/9/16 Class B networks (65,534 - 8,388,352 hosts);
10.1.0.0/16
/17/24 Class C networks (254 - 32,512 hosts);
10.1.1.0/24
Subnets:
/25/32 (except /31) Classless networks (1 124 hosts).
10.1.1.1/32
Important: Ensure all internal address spaces, both routable and non-routable, are defined
within your network hierarchy. Failure to do so could result in QRadar generating an
excessive number of false positives.

Network hierarchy structure is being saved to the following files on the QRadar file system:
/store/configservices/staging/globalconfig/net.conf
/store/configservices/staging/globalconfig/netid.conf
ATTENTION: It is not advisable to make changes to the network hierarchy simultaneously by
two or more system administrators using QRadar UI: the system will report an error
accessing the resource.

Task 2: Create the following network hierarchy in QRadar:
Group
Subgroup
IP addresses
International_Offices
All
Germany
10.10.0.0/16
Germany_Berlin_Marketing
10.10.1.0/24
Germany_Munich_Accounting
10.10.5.0/24
Italy
10.20.0.0/16
Italy_Rome_Marketing
10.20.1.0/24
Italy_Milan_Accounting
10.20.5.0/24
France
10.30.0.0/16
France_Paris_Marketing
10.30.1.0/24
France_Lyon_Accounting
10.30.5.0/24
Spain
10.40.0.0/16
Spain_Madrid_Marketing
10.40.1.0/24
Spain_Barcelona_Accounting
10.40.5.0/24
Poland
10.50.0.0/16
Poland_Warsaw_Marketing
10.50.1.0/24
Poland_Krakow_Accounting
10.50.5.0/24
Austria
10.60.0.0/16
Austria_Vienna_Marketing
10.60.1.0/24
Austria_Graz_Accounting
10.60.5.0/24
10.0.0.0/8
Trainee 1
Trainee 2
Trainee 3
Trainee 4
Trainee 5
Trainee 6

Reference Sets management
A reference set is a set of elements, such as a list of IP addresses or user names,

that are derived from events and flows occurring on your network. The main purpose of
the reference sets is to create manageable entities that can be reused within QRadar rules
and offenses. Reference sets in QRadar are flat and represent linear structure of single line
entries. The following basic operations are available for the reference set management:
Add a reference set;
This operation can only be done manually through GUI.
Edit a reference set;
This operation can be done manually through GUI as well as through an automatic
rule/offense response.
View the contents of a reference set;
Delete a reference set (manually through GUI);
Import/Export elements to/from a reference set;

Task 3: Create AlphaNumeric, case insensitive reference sets corresponding to your
trainee ID. Add your trainee ID, name and surname as 3 elements.
Example: If your trainee ID is Trainee 1, you should create a reference set Trainee1 and
put your trainee ID, name and surname (case insensitive) as 3 separate elements. Other
trainees should follow the suite.

Configure Vulnerability Scanner
QRadar uses Vulnerability Integration Services (VIS) for building vulnerability assessment
profiles. These profiles use network activity data to determine vulnerabilities and threat
level on the business network assets. Vulnerability assessment integration is build upon
QRadar interaction with various vulnerability scanners. The following two types of
integration are supported:
Direct communication through specific API
Such integration allows vulnerability scanners management through QRadar GUI:
scan schedule, IP range set, vulnerability data transfer etc. This approach allows direct
interaction with particular vulnerability scanner, which can be used on a daily basis for
the most critical network assets.
Vulnerability data file import

Such integration allows import of already available vulnerability reports through file
import. This approach can be used on a monthly basis for large sets of vulnerability
data covering huge networks, which can be gathered in advance.
In order for QRadar to build vulnerability assessment profiles for the network assets, the
following steps must be performed on QRadar:
Add and configure suitable network scanner;
Configure scan schedules.

Task 4: Create Nessus Scanner instance corresponding to your Trainee ID to collect
scheduled results of the Nessus Vulnerability Scanner. Add suitable schedule to collect
the results by QRadar.
Example: If your Trainee ID is Trainee 1, you should create a Nessus scanner Trainee1
and configure Scheduled Result Import collection type with any other values of choice, i.e.
no specific hostname, etc. Other trainees should follow the suite.

Configure Routing Rules
After receiving raw log data from log sources, QRadar can forward it to one or more
external systems, such as ticketing or alerting systems. Normalized event data can also be
forwarded to other QRadar systems. QRadar keeps all forwarded data unmodified. The
following items must be configured first in order for QRadar to forward the data:
Forwarding Destinations
These are external systems that QRadar will forward the data to. The following
options are available for the configurations:
Name;
Event Format (Raw or Normalized)
Destination Address;
Destination Port;
Protocol (Raw TCP/UDP, Normalized TCP only).
Routing rules
These are the rules that determine what log data is being forwarded and with what
routing options. The following types of rules are available:
Bulk event forwarding (through Admin tab);
Selective event forwarding (through Offenses->Rules tab).

The event forwarding is very convenient for the situations when there are specific
requirements for certain events handling and such events of matched criteria need to be
forwarded for the storage, immediate handling, and/or escalation. Sometimes, it is
necessary to filter out traffic based on a specific value of normalized fields to save storage
space.
The following routing options are available:
Forward;
Drop;
Bypass Correlation.

Task 5: Create a routing rule corresponding to your badge to drop events that contain
your name or surname in the Username normalized field.
Example: If you have a badge that says Trainee 1, you should create a routing rule called
Trainee1 Drop and put your ID trainee1, name or surname (all three) as a filter so that any
incoming event containing your name, surname, or ID as Username should be dropped by
this routing rule. Other trainees should follow the suite.

Configure Retention Periods
The following list of retention periods is available for many QRadar configuration settings as
well as for the collected data from the log sources:
Automatic Updates
Backup Retention Period (days, 1-65535);
System Settings
Temporary Files Retention Period (6 hrs 2 years);
Management Database Settings
Accumulator Retention Minute-By-Minute (1 day 2 years);
Accumulator Retention Hourly (1 day 2 years);
Accumulator Retention Daily (1 day 2 years);
Payload Index Retention (1 day 2 years);
Offense Retention Period (1 day 2 years);
Attacker History Retention Period (1 day 2 years);
Target History Retention Period (1 day 2 years);
Ariel Database Settings
Search Results Retention Period (1 day 3 month);

Ariel Database Settings
Search Results Retention Period (1 day 3 month);
Asset Profile Settings
Asset Profile Retention Period (1 day 2 years);
Events and Flows Settings
How long does the collected data is being kept? QRadar utilizes retention buckets to define
suitable retention periods for the collected events and flows that match custom filters in
order to satisfy different data storage period requirements. QRadar provides 11 retention
buckets: 10 unconfigured and 1 default. The precedence goes from top to bottom. If there
are no specific requirements on the different kind of data storage, the default bucket will
always be applied for all incoming events or flows as it has the lowest precedence, i.e.
always checked last. The following properties are available for the events and flows buckets
retention settings:
Name (convenient name for the bucket);
Keep data placed in this bucket for (1 day 2 years);
Allow data in this bucket to be compressed (never 2 weeks);

Delete data in this bucket (space vs retention period);
Current Filters (specific filters for custom only buckets).
Security Events normalization
Regular Expressions
A regular expression (RE, regex, regexp) is a pattern describing a certain amount of text,
against which strings can be matched. Strings either match the pattern or they don't. The
shell/cmd wildcards and question marks (* and ?) might be considered as a very primitive
type of RE. Just imagine that *.* will match any filename with the . (dot) present, however,
?.? will only match a 3-character-long filename with the . present.
In simple words, regular expressions represent patterns with metacharacters.

The very first one to look at is . (dot), which represent any character. The other important
metacharacter is ? (question mark), which literally means optional. It comes in handy when
you want to match something that might have additional characters, but doesnt
necessarily have to: cente?re? (American center, British centre).
The other two very import meta characters: ^ (carat) and the $ (dollar sign), which are the
start and end of a line respectively. Searching for the pattern ^test$ will find the word test,
but only if its on a line by itself.
There are also metacharacters that control how many things are being matched. These are
+ (plus) that matches one or more of the immediately preceding item; and * (asterisk) that
matches any number, including none, of the immediately preceding item.
GREEDY
LAZY
.+test vs .+?test

Regular expressions make the use of character classes or sets, which are specified by [ ]
(square brackets). Simply put the required characters in the square brackets that will form a
class: [A-Za-z0-9].
This example defines a class of all English alphabet letters in both UPPER and lower cases as
well as digits from 0 to 9. The specified regex will match a single character out of this class.
Regular expressions can use () (parentheses) as placeholders for the specific regex match:
User\s([^\s]+)\slogged\sout
NOTE:
^ vs [^abc]
The placeholders or backreferences are used to return only a matched part of the string
instead of the whole string (Hint: Custom Properties)
Another useful metacharacter is | (pipe), which means OR. This metacharacter has to be
used with () (parentheses) identifying the scope: (T|t)est will match both Test and test
capturing T or t as a backreference #1. If we do not want to capture the backreference, the
regex has to be written as follows: (?:T|t)est
NOTE:
a? vs (?:a)

Regular expressions use special metacharacters (not limited to, depending on regex flavor)
for word character \w, digit \d, space \s, tab \t etc.
There is additional repetition operator that allows to specify how many times a token can
be repeated. The syntax is {min,max}, where min is a positive integer number indicating the
minimum number of matches, and max is an integer equal to or greater than min indicating
the maximum number of matches. If the comma is present but max is omitted, the
maximum number of matches is infinite.
Examples:
\d{2,} will match two or more digits infinitely (10-~);
\d{2,4} will match digits between two and four (10-9999);
\d{2} will match two digits exactly (10-99).
Common Regular Expressions
There is an infinite number of regular expressions that can be used to match a desired
string of text. The following are several common regular expressions:
Variable
Regex
Value
IPv4 Address
(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})
127.0.0.1, 192.168.10.1
Port Number
(\d{1,5})
22, 80, 10001
MAC Address
((?:[0-9a-fA-F]{2}\:){5}[0-9a-fA-F]{2})
00:11:22:AA:66:DD
Protocol
(tcp|udp|icmp|gre)
tcp
Device Time
(\w{3}\s\d{2}\s\d{2}:\d{2}:\d{2})
Oct 28 10:01:10
White Space
\s
Match Anything
.+?
Anything will be matched here
This is only the beginning of regular expressions that cover very basics necessary for the
QRadar integration. Mastering regular expressions cannot be thought over night and
requires additional time for reading and practicing. Advanced reading material as well as
regex related software (Regex Buddy) can be found on the internet.
Common normalization fields
QRadar includes a comprehensive list of available normalization fields for both Log Activity
and Network Activity. The following fields are considered to be common because they are
used as default fields while displaying the default views of Log Activity and Network Activity.
Common Fields for Log Activity
Field Name
Event Name
Log Source
Event Count
Time
Low Level Category
Source IP
Source Port
Destination IP
Destination Port
Username
Magnitude
Description
normalized name of the event;
Log Source that sent the event;
number of events combined into the normalized event;
date and time at which QRadar received the event;
low level category associated with this event;
source IP address of the event;
source port of the event;
destination IP address of the event;
destination port of the event;
username associated with the event;
magnitude of the event.

Common Fields for Network Activity
Field Name
Description
measurement of the ratio of incoming to outgoing activity.
Standard Flow bidirectional traffic;
Flow Type
Type A one-to-many (i.e. network scan);

Type B many-to-one (i.e. DDoS);
Type C one-to-one (i.e. port scan).

First Packet Time
time at which QRadar receives the flow;
Storage Time
time at which QRadar stores the flow in the database;
Source IP
source IP address of the flow;
Source Port
source port of the flow;
Destination IP
destination IP address of the flow;
Destination Port
destination port of the flow;
Source Bytes
username associated with the flow;
Destination Bytes
magnitude of the flow;
Total Bytes
total number of bytes in the flow;
Source Packets
total number of packets sent from the source;
Destination Packets total number of packets sent to the destination;

Common Fields for Network Activity
Field Name
Description
Total Packets
Protocol
Application
ICMP Type/Code
Source Flags
Destination Flags
total number of packets within the flow;

protocol associated with the flow;
application detected within the flow;
Internet Control Message Protocol type and code;
Transmission Control Protocol flags of the source packet;
Transmission Control Protocol flags of the destination packet.
Creating and managing custom properties
Standard normalization fields are not always enough to build required filters or rules.
Custom properties are properties that you can create by extracting the necessary data
from unnormalized event payload. The following are 2 types of the custom properties:
Regex Based
These properties are extracted using Java flavor RegEx statements.
Calculation Based
These properties are created by performing operations on existing numeric
properties.
The following naming convention for the custom properties is considered as a good
practice:
<Product>: <Property Name>
Good Examples
Confusing Examples
Oracle: Role
Role
SELinux: Role
Role
MS Server: Role
Role

Task 6: Create a custom property corresponding to Trainee ID. The properties should
extract user name out of the following statement and the like:
<23>Oct 20 08:33:48 fakeware src=10.10.1.2 uid=root success=yes msg=user fake_user
was created on the system
Example: If your Trainee ID Trainee 1, you should create a custom property called
Trainee1: Affected User to extract username fake_user out of the event. Username can
potentially have only letters, numbers, _ (underscore), and (hyphen). Other trainees
should follow the suite.
Building LSX (normalization part)
LSX structure
QRadar provides Universal Device Support Module (uDSM) Log Source eXtension (LSX)
framework that allows custom development and integration for unsupported log sources.
Additionally, LSX can provide parsing enhancements to already existing DSM to cover
additional reporting requirements. The LSX uses Java flavor regular expressions to provide
parsing logic for the data extraction and further normalization with QRadar. LSX consists of
the following items:
Preprocessor
Optional. A binary for collecting/preprocessing unsupported log source data to make it
available for QRadar standard protocols. The need for preprocessor is based on the
log source data availability.
LSX XML Parser

Mandatory. An XML file that contain QRadar parsing and matching rules for the data
normalization process. This is the core of any LSX and its development requires
advanced knowledge of regular expressions.
LSX Mapper
Optional. Ordinary, the mapping of successfully parsed data by LSX XML and assigning
suitable QRadar IDs (QID) is a manual process involving QRadar command prompt
and GUI for each event. Optionally, a shell script for creating QRadar QID mappings
for the data normalization process can be created to automate manual task.
Obligatory fields
The development of any XML starts with LSX XML template. LSX XML parser consists of the
following obligatory fields:
Field Name
Description
allEventNames
This is a default field and must always be present in XML. Moreover,

its default value must not be modified. Failure to comply will result in
malfunction of LSX.
EventName
The action that the event represent. The value of this field plays vital
role in the data correlation process as QRadar at least needs to
know what kind of action was performed.
Optional fields
The following LSX XML fields are optional and their presence depends on the
corresponding data availability within the event. Best practices suggest that all available
data should be parsed for better correlation and visibility.
Field Name
EventCategory
SourceIp
SourcePort
SourceIpPreNAT
SourceIpPostNAT
SourceMAC
SourcePortPreNAT
SourcePortPostNAT
DestinationIp
DestinationPort
DestinationIpPreNAT
Description
specific category the event belongs to;
IP address of the source;
port of the source;
real IP address of the source;
mapped IP address of the source;
MAC identifier of the source;
real port of the source;
mapped port of the source;
IP address of the destination;
port of the destination;
real IP address of the destination.
Optional fields
Field Name
DestinationIpPostNAT
DestinationPortPreNAT
DestinationPortPostNAT
DestinationMAC
DeviceTime
Protocol
UserName
HostName
GroupName
NetBIOSName
ExtraIdentityData
SourceIpv6
DestinationIpv6
Description
mapped IP address of the destination;
real port of the destination;
mapped port of the destination;
MAC identifier of the destination;
time at which the event has occurred;
protocol used;
user who is responsible for the event;
host name (or IP address) where the event has occurred;
name of the group that the host belongs to;
NetBIOS name of the host;
user-specific data associated with the event;
IPv6 source IP address for the message;
IPv6 destination IP address for the message.
LSX XML basically consists of two different types of variables:

Patterns
Patternsare used for defining Regex patterns that will match specific parts from the
incoming event. The number of patterns vary and depends on the data availability.
The structure of a pattern is as follows:
<pattern id=<ID>" xmlns=""><![CDATA[<REGEX>]]></pattern>

where
<ID> can be any name of your choice, except for the mandatory allEventNames field
that must always be present with the default value;
<REGEX> can be any regex that is used for the purpose of extracting the
corresponding data.
Example:
<pattern id="allEventNames" xmlns=""><![CDATA[(.*)]]></pattern>
<pattern id=EventName1" xmlns=""><![CDATA[user.+?\shas\slogged\in]]></pattern>

<pattern id=EventName2"
xmlns=""><![CDATA[user.+?\shas\slogged\sout]]></pattern>
<pattern id=EventName3" xmlns=""><![CDATA[user.+?\swas\sdeleted]]></pattern>
Matchers
Matchers are used to link together parsed values with QRadar normalized fields so
that the specific data gets assigned to proper QRadar variables like Username, Source
IP address, etc. The number of matchers must be the same as the number of
patterns. The structure of a matcher is as follows:
<matcher field=<FIELD_NAME>"
order=<ORDER>
pattern-id=<ID>
capture-group=<GROUP_NAME>
enable-substitutions=<ENABLE>/>
where
<FIELD_NAME> values from the obligatory and optional fields tables;
<ORDER> order of precedence, i.e. 1, 2, 3, etc. Depends on the number of similar patterns;
<ID> correspond to the name of the pattern ID used in patterns;
<GROUP_NAME> number of the regex capture group (if any) or a custom group name;
<ENABLE> true for a custom group name, otherwise false.

Example for patterns and matchers:
<pattern id=EventName1" xmlns=""><![CDATA[user.+?\shas\slogged\in]]></pattern>
<pattern id=EventName2" xmlns=""><![CDATA[user.+?\shas\slogged\sout]]></pattern>
<pattern id=EventName3" xmlns=""><![CDATA[user.+?\swas\sdeleted]]></pattern>
will yield the following matchers:
<matcher field=EventName" order=1 pattern-id=EventName1 capturegroup=User_Login enable-substitutions=true/>
<matcher field=EventName" order=2 pattern-id=EventName2 capturegroup=User_Logout enable-substitutions=true/>
<matcher field=EventName" order=3 pattern-id=EventName3 capturegroup=User_Delete enable-substitutions=true/>
Values extraction
Reviewing the logs

A critical step in creating a Universal DSM is reviewing the logs for usability. At a bare
minimum, the logs should have a value that can be mapped to an event name. The event
name should be a unique value that can distinguish the various log types.
An example of usable logs:
Oct 20 17:16:14 dropbear[22331]: bad password attempt for 'root from

192.168.50.80:3364
May 20 17:16:26 dropbear[22331]: password auth succeeded for 'root' from
192.168.50.80:3364
May 20 16:42:19 kernel: DROP IN=vlan2 OUT= MAC=00:01:5c:31:39:c2:08:00
SRC=172.29.255.121 DST=255.255.255.255 PROTO=UDP SPT=67 DPT=68
An example of slightly usable logs:
Oct 21 08:12:08 loopback 1256559128 autotrace[215824]: W: trace: no map for prod
49420003, idf 010029a2, lal 00af0008 Oct 22 16:35:00 sxpgbd0081 last message
repeated 7 times
Oct 24 01:30:00 sxpgbd0081 /usr/local/monitor-rrd/sxpgbd0081/.rrd (rc=-1, opening
'/usr/local/monitor-rrd/sxpgbd0081/.rrd': No such file or directory)
Values extraction
Determining Which Fields Can Be Used

The first step in creating the log source extension is reviewing the unsupported logs and
determining what fields will be used. At a bare minimum, the EventName field must be
used.
Determine which values in the unsupported log source can be mapped to the fields in the
LSX template. It is not necessary to use all of the fields in the default LSX template.
Example log entry:
May 20 17:24:59 kernel: DROP MAC=5c:31:39:c2:08:00 SRC=172.29.255.12
DST=192.168.100.25 LEN=351 TOS=0x00 PREC=0x00 TTL=64 ID=9582 PROTO=UDP
SPT=67 DPT=68 LEN=331
The following fields are usable for this example:
EventName, i.e. DROP
SourceMAC, i.e. MAC=5c:31:39:c2:08:00
SourceIp, i.e. SRC=172.29.255.121
DestinationIp, i.e. DST=192.168.100.25
Protocol, i.e. PROTO=UDP
SourcePort, i.e. SPT=67
DestinationPort, i.e. DPT=68
Values extraction
Values extraction
Remove any unused fields and their corresponding Pattern IDs from the LSX.
Values extraction
Rename the Pattern IDs to a unique name. This saves confusion if multiple patterns are
used and helps distinguish between field and Pattern ID names.
Values extraction
Determining Regular Expression Patterns

The next step in creating a uDSM is building the regular expression patterns.
Finding The Strings To Match
Visually analyze the unsupported log source to identify unique patterns. These
patterns will later be translated into regular expressions. When possible, you should
include characters before and after the actual value to provide a basic level of error
checking. This will prevent similar values from being unintentionally matched.
Field Name
Matched Text
Regex
EventName
DROP
\sDROP\s
SourceMAC
MAC=5c:31:39:c2:08:00
MAC=((?:[0-9a-fA-F]{2}\:){5}[0-9a-fA-F]{2})
SourceIp
SRC=172.29.255.121
SRC=(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})
DestinationIp
DST=192.168.100.25
DST=(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})
Protocol
PROTO=UDP
PROTO=((?:tcp|udp|icmp|gre))\s
SourcePort
SPT=67
SPT=(\d{1,5})\s
DestinationPort DPT=68
DPT=(\d{1,5})\s
Values extraction
It is important to isolate capturing groups as the value passed to QRadar fields should only
contain relevant values, but not the entire string match.
Migrating Regular Expression Patterns Into The LSX
The next step is to migrate the patterns with capture groups into the LSX.
Timestamp formatting
While logging an event, different log sources produce vast variety of timestamps at which
events were logged at the source. These timestamps do not follow a unique pattern and
therefore have to be normalized for QRadar to correctly display the time, at which the
event occurred rather than received by QRadar. This is very important for searches,
correlation rules and offenses.
LSX framework provides flexibility through the use of a corresponding pattern and a
matcher for parsing and formatting the original timestamp.
A timestamp candidate <14>Jan 06 14:31:56 test-host will produce the following pattern
and matcher for the event timestamp:
<pattern id=DeviceTime1 xmlns="">
<![CDATA[<\d+>(\w{3}\s\d{2}\s[\d:]+)\s]]>
</pattern>
<matcher field=DeviceTime
order=1
ext-data="MMM dd HH:mm:ss
pattern-id=DeviceTime1
capture-group=1/>
where ext-data specifies timestamp format as defined in Java class SimpleDateFormat
LSX deployment
At this point, the LSX is complete and can be used to parse the unsupported log source
within QRadar. The completed LSX must be uploaded to QRadar and applied to the
Universal DSM. The logic from the LSX is then used to parse the logs from the unsupported
log source.
The following steps must be produced within QRadar GUI to enable newly developed LSX:
Create Log Source Extension

This steps involves defining a new Log Source Extension within QRadar, specifying the
values for the required fields and uploading newly created LSX XML file to complete
the process. During the upload, the XML file will be validated for errors.
Create Log Source
This step involves defining a new Log Source within QRadar, specifying the values for
the required fields and assigning newly created Log Source Extension to the Log
Source, so that the data can be parsed correctly. Special attention must be paid for
the Log Source Identifier (LSI) variable, as this is how the incoming events will be
associated with the specific Log Source. After the Log Source creation, deploy the
changes.
Initially, all of the events from the Universal DSM will appear as unknown in the Log Activity
tab. This is normal. Correctly created Log Source with the corresponding LSX XML should at
least correctly identify the Log Source normalized field when the corresponding data is
received by QRadar. This is achieved by the Log Source Identifier value during Log Source
configuration.
How to correctly specify the Log Source Identifier (LSI)? There are two approaches to solve
this:
Automatic
LSI is automatically identified as the IP address of the source host that send the
system. This approach is good for the Log Sources autodiscovery feature identifying
supported out-of-the-box Log Sources.
Manual
LSI can be manually set depending on the presence of the corresponding value
(hostname or IP address) in the incoming event. LSI for unsupported Log Sources
should always be specified manually.
Further verification of event normalization would be to check if Event ID was correctly

parsed out of the incoming event as was specified in the LSX XML. This can be done by
checking the value of Event ID through the Map Event button in the Event Viewer.

Task 7: Create a Log Source corresponding to your Trainee ID. Look at the data first.
Example: If your Trainee ID is Trainee 1, you should create Log Source called
Trainee1_LSX. Log Source Identifier must be determined based on the data analysis.
Other trainees should follow the suite.

Task 8: Create a LSX XML corresponding to your Trainee ID. XML should only contain the
patterns and matchers to extract the relevant data out of the relevant log sample. Log
samples relevancy is determined through the corresponding Log Activity filter. After
completion, assign LSX XML to the appropriate Log Source.
Example: If your Trainee ID is Trainee 1, you should first create a filter called Trainee1
and filter out the events relevant to a specific Log Source. Then, create an XML file based
on the copy of LSX XML Template called Trainee 1_LSX.xml. After log samples analysis, only
the required patterns and matchers must be present, others deleted. After the
development is complete, LSX XML should be associated with the Log Source Trainee1 by
creating suitable Log Source Extension. Other trainees should follow the suite.
Building LSX (mapping part)
QRadar event categories (High and Low Level)
Prior LSX development finalization, identified Event IDs must be correctly mapped to the
corresponding Event Names. Although the event names might appear as understandable
values in the logs, e.g. DROP, DENY, and ACCEPT, QRadar has no understanding of what
these values actual represent.
From QRadar perspective, these value are strings of text that are not mapped to any known
values. It is necessary to map all unknown events to their equivalents in the QRadar ID
(QID) map. The value will then appear as expected and treated as normalized events.
All QIDs are unique within QRadar and belong to specific categories. Categories are fixed
and cannot be modified by user. These categories are classified as follows:
High-Level Category
Top level category of the QID identifying generic area that QID belongs to.
i.e. Authentication, Access, DoS, Recon, System, etc.
Low-Level Category
Bottom level category of the QID identifying specific section of a particular area that
QID belongs to. One High-Level Category can have many Low-Level Categories, which,
in turn, can have many QIDs.
i.e. Admin Login Successful, Admin Login Failure, Host Logout. As of current QRadar
release, there are 1180 Low-Level Categories.
Proper category assignment best practice
Any successful Event ID mapping lies within understanding of what exactly the Event ID
represents, i.e. the action behind it. If the action is determined correctly, the appropriate
High-Level Category and then Low-Level Category is chosen for the event out of the list of
available categories. The Low-Level Category must be as close as possible to the meaning
of the action.
Example:
Analysis of the following event
<23>Oct 20 08:33:48 fakeware src=10.10.1.2 uid=root success=yes msg=user fake_user
was created on the system
yields the action of creating a user within the system. Therefore, the appropriate High-Level
and Low-Level Category would be as follows:
Event ID
User_Created_Success
High-Level Category
Authentication
Low-Level Category
User Account Added
where Event ID represents matchers capture_group from LSX XML.

If no corresponding pair of High-Level, Low-Level Categories can be found, a more generic
pair is chosen, i.e. System-Information, System-Notice, System-Alert, etc. Such mapping,
however, is less desirable and should be considered as a last resort.
EventCRE vs Custom QID
Mapping process of Event ID to QID involves the following two completely different
approaches:
Mapping to Event CRE
Event CRE is an event template that is used by QRadar to generate new events. Event
CRE templates already being present on QRadar system. Each Low-Level Category
may have Event CRE templates representing a particular kind of action. Event CRE are
not being associated with any Log Source and therefore can be used for a generic
mapping purpose.
Mapping to Custom QID
Custom QID mapping is a more advanced technique that involves creation of a new
QID first for a specific purpose only and then using this Custom QID for mapping a
particular Event ID. This technique requires knowledge of QRadar CLI tools.
Creating new QIDs
New QIDs creation involves the use of QRadar CLI QID map utility, which can create, export,
import, or modify user-defined QID map entries. The utility provides the following options:
qidmap_cli.sh [-l|-c|-m|-i[-f <filename>]|-e[-f <filename>]|-d]
Options
Description
-l
Lists the low-level category
-c
Creates a new QID map entry
-m
Modifies an existing user-defined QID map entry
-i
Imports QID map entries
-e
Exports existing user-defined QID map entries

<filename> If you specify the -i or -e option, allows you to
specify a file name to import or export QID map entries
If you specify the -i or -e option, allows you to specify a
delimiter for the import or export file. The default is a
comma
Display the help options
-f
-d
-h
Creating new QIDs
New QID are created with the following syntax:

qidmap_cli.sh -c --qname <name> --qdescription <description> --severity <severity> -lowlevelcategoryid <ID>
where qname and qdescription can be anything of your choice;
severity - 1 to 10, the highest is the most severe;
lowlevelcategoryid ID of the Low-Level Category (qidmap_cli.sh -l)
Example:
LSX XML matchers capture_group User_Deleted_Success yields the following CLI
command:
/opt/qradar/bin/qidmap_cli.sh -c --qname "Fakeware User Delete Success" --qdescription
"Fakeware Logging: User Successfully Deleted" --severity 3 --lowlevelcategoryid 3035
where 3035 is the ID for Authentication-User Account Removed High-Level, Low-Level
Category pair.
Mapping events in UI
EventCRE vs new QID:
Testing events mapping
After the mapping is successful, all new events that are identified by the corresponding
Event IDs will automatically be normalized and will participate in the correlation logic and
rules.

Task 9: Create corresponding EventCRE mapping for each event manually.
Example: All trainees should create suitable EventCRE mappings manually for all events
relevant to their Log Sources. Upon mapping completion, all events must have Event Name
and Low Level Category properly assigned.
Day 2
Building blocks (BB) overview and specifics.

Enabling custom BB.
Host definitions
A Building Block (BB) is a reusable component that can be included in QRadar rules. BBs
can be created or edited to satisfy specific requirements. In simple words, BBs are testing
conditions for the rules, thus BBs are the rules themselves, but without a specific action or
rule respond defined. QRadar includes a comprehensive set of default predefined BBs to
cover various IT, networking, and computing areas, i.e.:
Definitions, Devices, Databases, Networks, Policies, Threats, etc.
The most common family of BBs used in rules creation is BB:HostDefinition family that
contain vast variety of predefined host assets that can be edited to reflect any
environment. Host definitions family includes many categories, i.e.:
Database Server, LDAP Servers, DMZ Servers, Mail Servers, Proxy Servers and many others.
Missing categories can be easily created and exported as new BBs.
BB:HostDefinition are created taking into the account IP addresses and ports of the
required assets.
After creating a new member of any BB family, its name has to be included into the
System: Load Building Blocks rule in order for the BB to work correctly.

Enabling custom BB.
Task 10: Create BB:HostDefinition corresponding to your Trainee ID with the source or
destination IP address condition equal to the Source IP address from the relevant log.
Example: If your Trainee ID is Trainee 1, you should create a Building Block called
BB:HostDefinition:Trainee1 and add a condition with the source or destination IP address
equal to 10.10.1.2. Other trainees should follow the suite.

Enabling custom BB.
Network definitions
Another frequently used in rules creation family of BBs is BB:NetworkDefinition family that
contain vast variety of predefined network assets that can be edited to reflect any network
environment. This BB can be regarded as a soft copy of the Network Hierarchy. Missing
networks can be easily created and exported as new BBs.
BB:NetworkDefinition are created taking into the account CIDRs of the required network
assets.
Best practices suggest that it is advisable to use the Network Hierarchy definitions rather
than Building Blocks for rules checking IP addresses for networks.

Enabling custom BB.
False positives
Like any other BBs, BB:FalsePositive family is used to match incoming events based on
certain conditions. However, the purpose of the false-positive identification through BBs is
to exclude matched events from contributing to the other rules that create offenses. This
approach is used to bulk-identify false-positive events with similar conditions, i.e. Low-Level
Category.
After creating a new false-positive BB, its name has to be included into the FalsePositive:
False Positive Rules and Building Blocks rule in order for the BB to work correctly.

Enabling custom BB.
To reduce the number of offenses, the following BBs needs to be edited since they are
producing a lot of traffic:
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: TrustedNetwork
False Positive Tuning function can be used to tune out false positive events and flows from
creating offenses. The user must have appropriate permissions for creating customized
rules to tune false positives.
The following best practices tuning methodology is applicable:
Disable rules that produce numerous unwanted offenses.
Consider modifying rules to include local rather than remote network context.
When you edit a rule with the attach events for the next 300 seconds option enabled,
wait 300 seconds before closing the related offenses.

Enabling custom BB.
Rules overview
Custom Rules
A rule is a collection of tests that perform an action when certain conditions are met. Each
rule can be configured to capture and respond to a specific event, sequence of events, flow
sequence, or offense. The actions which can be triggered can include sending an email or
generating a syslog message. A rule can reference multiple building blocks by using the
tests found in the function sections of the test groups within the Rule Editor.
The following rules exist in QRadar:
Event Rule
This rule is only applicable on incoming events as it tests the conditions for event
properties.
Flow Rule
This rule is only applicable on incoming flows as it tests the conditions for flow
properties.
Common Rule
This rule is applicable for both events and flows as it tests the conditions for events
and flows simultaneously.
Offense Rule
This rule is applicable for offenses only as it tests the conditions for already created
offenses.
Rules overview
QRadar also offers a functionality of testing the conditions on aggregated fields thus
creating anomaly rules. In order to enable the anomaly rules creation, the search must
contain a Group By field, be of Time series type, Capture Time Series data, and must also
be saved.
The following anomaly rules exist in QRadar:
Anomaly Rule
This rule performs tests on aggregated fields for anomalous network activity.
Behavioral Rule
This rule type performs tests on aggregated fields to alert on volume changes in
network activity that occurs in regular seasonal patterns.
Threshold Rule
This rule type performs tests on aggregated fields to alert on network activity that
exceeds a defined threshold.
Rules overview
Rules overview
Creating Rules
QRadar provides a comprehensive set of already predefined rule tests that can be used
when constructing a rule. These tests are written in human language so that the meaning
of the test condition can be easily understood. The tests are grouped into the categories
for a better related to a particular category overview. These categories are:
All
Common Property
Date / Time
Event Property
Functions
Host Profile
IP / Ports
Log Source
Network Property
Creating Rules
Creating Rules
Using custom properties and reference sets in rules tests
The following rules are suitable for working with Custom Properties and Reference Sets
conditional testing:
when the event matches this search filter
when any of these event properties are contained in any of these reference set(s)

Task 11: Create rule corresponding to your Trainee ID that matches your ID, name or
surname from the custom property Trainee X: Affected User from the relevant log. No
rule response.
Example: If your Trainee ID is Trainee 1, you should create an Event Rule called
Trainee1:Rule: Custom Property Match and add a condition with the custom property
Trainee1: Affected User to match your ID, name or surname. No rule response should be
configured. Other trainees should follow the suite.

Task 12: Create rule corresponding to your Trainee ID that matches your trainee ID,
name or surname from the reference set TraineeX from the relevant log. No rule
response.
Example: If your Trainee ID is Trainee 1, you should create an Event Rule called
Trainee1:Rule: Reference Set Match and add a condition to match the value of custom
property Trainee1: Custom Property from the reference set Trainee1. No rule response
should be configured. Other trainees should follow the suite.
Creating Rules
Rule Responses
During rule configuration wizard, QRadar provides the ability to configure the rule
response. The following responses can be set up:
Classic responses (SNMP, Syslog, E-Mail, IF-MAP)
This type of response generates outgoing SNMP trap, e-mail or IF-MAP.
To enable SNMP trap configuration, edit /opt/qradar/conf/offenseCRE.snmp.xml
To enable sending the data to IF-MAP server, system settings must be modified to
allow such kind of data transfer.
Specific responses (Reference Set, Reference Map, Trigger Scan)
This type of response updates reference set/map, or trigger the IP address scan
(destination, source, or both).
Including events into offense
This type of response allows to include the original event into generated offense.
Naming convention. Renaming offenses
The following naming convention is used when naming the rule:

Component.Number.Rule or Offense: Rule Name
i.e. OS.001.Offense: Password Share
The same name of the offense must be specified in the Dispatch New Event
Creating Rules
Rule Responses
Tuning Rules
Optimizing Custom Rules
When building custom rules, it is highly recommended that you optimize the order of the
testing. This ensures that the rules do not slow down the Common Rule Engine (CRE). The
tests in a rule are executed in the order in which they are displayed in the user interface.
The most memory intensive tests for the CRE are the payload and regular expression
searches. To ensure these tests run against a smaller subset of data and execute faster, it
is strongly recommend you 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
Tuning Rules
Creating an OR Condition within the CRE
When adding more tests to a rule, each test can only be an AND or AND NOT conditional
test. To create an OR condition within the CRE put each separate set of conditions into a
building block and then create a new rule or building block that utilizes the following rule:
when an event matches any of the following rules
This will ensure both Building Blocks are loaded when the test is applied.
Tuning Rules
Cleaning the SIM Model
When the tuning process is complete, it is recommended that you clean the SIM model.
This ensures that QRadar only displays recent offenses. This function ensures that offenses
are based on the most current rules, discovered servers, and network hierarchy. When you
clean the SIM model, all existing offenses are closed, but this does not affect existing events
and flows.
Tuning Rules
Identifying Network Assets
The following network assets can be included in the BBs:
Category
Building Block
NAT Address
BB-NetworkDefinition: NAT Address Range
Network and Management Servers
BB-HostDefinition:Network Management
Servers
Proxy Servers
BB-HostDefinition: Proxy Servers
Server Networks
BB-HostDefinition: Server Networks
Vulnerability Scanners
BB-HostDefinition: VA Scanner Source ID
Fine tuning false positives
From event properties
By Routing Rules
By rule thresholds update
Discovering Servers
QRadar automatically discovers and classifies servers in your network, providing a faster
initial deployment and easier tuning when network changes occur.
The Server Discovery function uses the asset profile database to discover many types of
servers on your network. This function lists automatically discovered servers and enables
you to select which servers you want to include in building blocks.
Populating Building Blocks
Building blocks use the same tests as rules, however they do not have any actions
associated with them. Building blocks group together commonly used tests, to build
complex logic, so they can be used in rules. Building blocks are often configured to test
groups of IP addresses, privileged usernames, 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 should be reviewed and edited based on
the needs of your network.
False Positive Rule Chains
The rule FalsePositive: False Positive Rules and Building Blocks is a special QRadar rule
because it is the first rule to execute in the CRE. When it loads, all of its dependencies are
loaded and tested.
If the rule is successfully matched in QRadar, the rule will drop the detected event or flow.
This action will stop the event or flow from progressing through the CRE. Since this rule
happens first, the event or flow will not match any other rules and will not create an
offense.
When creating false positive BBs, the following approach is recommended:
Name building blocks according to the established naming convention;
Building blocks should contain the test
when a flow or an event matches any of the following rules
This is used as a collection point for all the false positive building blocks and will
enable you to quickly find and identify the customizations within your site.
Analyzing Offenses
Offenses
As event and flow data passes through the CRE, it is correlated using the rules setup on the
customers QRadar system. Depending on how each rule is configured, an offense can be
generated based on this correlation. These Offenses are displayed using the Offenses tab.
Offense investigation is a time consuming process and requires understanding of the
subject of the offense as well as the common-sense knowledge of networking, computing
and Information Technology (IT).
Common recommendations for QRadar correlation rules
Use most important information from event content to create Offense index. Note that
when index matches for different offenses in a short time period then only one offense
will be created from several rules.
Fill in all BBs (hosts definitions, port definitions, etc.) with proper information
corresponding to infrastructure.
Payload matching is slow. Use indexed custom property instead, when possible.
Creating offense from a single event isn't a good practice and may lead to excessive
number of false-positive offenses to be created. For such rules offense creation could
be omitted, and quick searches could be used for reporting (e.g. one search for all such
suspicious rules triggered). It's OK to have single-event rules which are not generating
offenses. Other option is to include timeframe or number of events seen.
Analyzing Offenses
Common recommendations for QRadar correlation rules
IMPORTANT: Make sure the rule "System: Load Building Blocks" includes all the custom
BBs you have created and want to utilize.
IMPORTANT: Make sure the rule FalsePositive: False Positive Rules and Building Blocks
includes all the custom BBs you have created for identifying false positives and want to
utilize.
Rename Offense with new event creation using special naming convention.
Check the rules which are not creating offenses. A new rule(s) may need to be created
to include those and create offense, or custom search could be used for reporting.
Use event category as a matching condition instead of specific QID when possible.
Use Log Source Group instead of listing specific Log Sources. Some of the rules will get
broken because of removed Log Sources. Hence the use of Log Source Group is highly
advised.
Use network hierarchy element(s) or BB instead of specifying exact IP addresses.
Use dynamic reference set or BB with users allowed to perform actions instead of listing
names.
Add annotations for each and every Offense.
Review all rules with disabled offense creation. Most likely some of them will need to be
enabled.
Analyzing Offenses
Task 13: Create a rule corresponding to your Trainee ID that matches your trainee ID,
name or surname in custom event property from the reference set Trainee X from the
relevant log. Rule response should be configured to generate on offense including
original events. The offense should have the same name as the rule.
Example: If your Trainee ID is Trainee 1, you should create an Event Rule that will generate
an offense as a rule response, called Trainee 1.Offense: Reference Set Match and add a
condition with the reference set Trainee1 to match your Trainee ID, name or surname out
of the custom property Trainee1: Custom Property. Other trainees should follow the suite.
Analyzing Offenses
Offenses
QRadar Risk Manager
QRM Overview
QRadar Risk Manager is an internal component of QRadar SIEM solution that proactively
helps in assessing the risks from vulnerabilities, correlating the network topology
information with data from QRadar SIEM, including assets configuration, events and flow
patterns. QRM also helps in detecting configuration errors in firewalls and IPS systems to
build a complete picture of a possible intrusion path.
QRadar Risk Manager
QRM Overview
QRM provides the following key capabilities:

Policy monitoring to improve compliance
QRadar Risk Manager features an automated policy engine that simplifies the
assessment of a wide spectrum of information security and compliance policies.
Device configuration management to detect changes and profile future risks
QRadar Risk Manager provides automated collection, monitoring and auditing of
device configurations across an organizations switches, routers, firewalls and
intrusion detection system (IDS)/intrusion prevention system (IPS) devices.
Modeling and simulation of attacks and network configuration changes
QRadar Risk Manager provides simulation capabilities that can check network
connectivity before and after a proposed network configuration change, such as
adding a firewall rule to one or more devices.
QRadar Risk Manager
QRM Deployment
IBM Security QRadar Risk Manager deployment includes a IBM Security QRadar SIEM
Console and QRadar Risk Manager appliance as a managed host. QRM can be supplied
either as a hardware appliance or a software image to be installed on existing hardware
that meets certain requirements. During the installation, QRM requires the following
parameters in order to be properly initiated:
Hostname - Type a fully qualified domain name as the system hostname.
IP Address - Type the IP address of the system.
Network Mask - Type the network mask address for the system.
Gateway - Type the default gateway of the system.
Primary DNS - Type the primary DNS server address.
Secondary DNS - Optional. Type the secondary DNS server address.
Public IP - Optional. Type the Public IP address of the server.
Once the initial installation and configuration are completed, QRM needs to be added as a
managed host to QRadar SIEM. This is achieved through the Deployment Editor in QRadar
Console Admin tab.
QRadar Risk Manager
QRM Deployment: Adding as a Managed Host
QRadar Risk Manager
QRM Adapters
QRM uses adapters to integrate the network devices into QRadar SIEM. With the help of
adapters, QRM collects and imports configuration information from the network devices
like firewalls, routers and switches.
The following adapters are supported:
Check Point SecurePlatform Appliances
Cisco Internet Operating System (IOS)
Cisco Catalyst (CatOS)
Cisco Security Appliances
Juniper Networks ScreenOS
Juniper Networks JUNOS
Juniper Networks NSM
The adapters need to be installed on the QRM in order to provide the support for the
required devices.
QRadar Risk Manager
QRM Adapters
The following methods of adding devices are available in QRadar Console through Admin
tab (Plugins->QRM):
Add Device - Add one device.
Discover Devices - Add multiple devices.
Discover NSM - Add devices that are managed by a Juniper Networks NSM console.
Discover CPSMS - Add devices that are managed by a Check Point Security Manager
Server (CPSMS).
For more details, please, consult the user documentation for QRM Adapters.
QRadar Risk Manager
QRM use cases
The following use cases are identified with QRM key capabilities:
Configuration Audit
Collected by QRM configuration information for network devices, can be used for
audit compliance and to schedule configuration backups. The configuration
information for your devices is collected from device backups in Configuration Source
Management. Each time QRadar Risk Manager backs up your device list, it archives a
copy of your device configuration to provide a historical reference.
View network paths in the topology
The topology in QRadar Risk Manager displays a graphical representation of your
network devices. A topology path search can determine how your network devices are
communicating and the network path that they use to communicate. Path searching
allows QRadar Risk Manager to visibly display the path between a source and
destination, along with the ports, protocols, and rules.
Visualize the attack path of an offense
Attack path visualization ties offenses with topology searches. This visualization
allows security operators to view the offense detail and the path the offense took
through your network. The visual representation shows you the assets in your
network that are communicating to allow an offense to travel through the network.
QRadar Risk Manager
QRM use cases
The following use cases are identified with QRM key capabilities:
Monitor policies
Use Policy Monitor to define tests that are based on the risk indicators, and then
restrict the test results to filter the query for specific results, violations, protocols,
or vulnerabilities.
Assess assets that have suspicious configurations and communications
Organizations use corporate security policies to define risks and the communications
that are allowed between assets and networks. To assist with compliance and
corporate policy breaches, organizations use Policy Monitor to assess and monitor
risks that might be unknown.
Simulate attacks on network assets
You can use a simulation to test your network for vulnerabilities from various sources.
Simulate the risk of network configuration changes
You can use a topology model to determine the effect of configuration changes on
your network using a simulation.
ScienceSofts Identity
WHO WE ARE:
An international IT company, expert in the design, development

and delivery of custom software solutions, IT consulting and IT
outsourcing services.
Locations in Finland and Belarus, customers in 25 countries
400 full-time staff; established in 1989
WHAT WE DO:
Software development and IT outsourcing

Mobile and telecom solutions
Information Security (SIEM) solutions

Enterprise document management solutions
Cloud and Remote infrastructure management services
SIEM expertise
Authorized IBM security partner in Finland; QRadar reseller in Belarus,

two certified QRadar technical resources, Tivoli Security/ QRadar sales
resources
SIEM implementation engagements in USA, UK, Middle East, Africa
Created TSIEM QRadar Migration Guide together with IBM PS and

Enablement teams; Participated in the creation of QRadar exam as an
invited IBM partner
A number of QRadar Log Source Extensions (LSXs) and Device Supported

Modules (uDSMs) created
Two major releases of IBM TCIM (2007-2008), three major releases of IBM
Tivoli Security Information and Event Manager (TSIEM) major releases
(2009-2011)
More than 120 completed CISM, TCIM, and TSIEM Event Sources and
Compliance Management Modules projects, over 40 device rules and
core bug-fixing for TSOM
Lets keep in touch
SCIENCESOFT, INC.
2 Bedy Str.
220040 Minsk, Belarus
Phone: + 375 17 293 3736
Email: contact@scnsoft.com
Web: www.scnsoft.com
SCIENCESOFT OY
Hitsaajankatu 22
00810 Helsinki, Finland
Phone: +358 50 388 3000
Email: contact@scnsoft.fi
Web: www.scnsoft.fi
www.scnsoft.com

QRadar Administrador Avanzado

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

QRadar Administrador Avanzado

Caricato da

Copyright:

Formati disponibili

IBM Security QRadar 7.

Advanced Administration Course

Copyright 2013, ScienceSoft Inc.

Connect to Lab Environment

If successful, you should see QRadar console login page.

Anomaly Detection Rules

Introduction to QRadar administration

User roles and security profiles

Introduction to QRadar administration

Introduction to QRadar administration

Introduction to QRadar administration

Create and customize network and remote hierarchies

Group related servers into multi-CIDR objects:

Introduction to QRadar administration

Acceptable CIDR values are:

Introduction to QRadar administration

Introduction to QRadar administration

Introduction to QRadar administration

Reference Sets management

A reference set is a set of elements, such as a list of IP addresses or user names,

Introduction to QRadar administration

Introduction to QRadar administration

Configure Vulnerability Scanner

Vulnerability data file import

Introduction to QRadar administration

Introduction to QRadar administration

Configure Routing Rules

Introduction to QRadar administration

Introduction to QRadar administration

Introduction to QRadar administration

Configure Retention Periods

Introduction to QRadar administration

Allow data in this bucket to be compressed (never 2 weeks);

Security Events normalization

In simple words, regular expressions represent patterns with metacharacters.

Security Events normalization

Security Events normalization

Security Events normalization

Security Events normalization

Common Regular Expressions

22, 80, 10001

Anything will be matched here

Security Events normalization

Common normalization fields

Security Events normalization

Type A one-to-many (i.e. network scan);

Type C one-to-one (i.e. port scan).

Security Events normalization

total number of packets within the flow;

Security Events normalization

Creating and managing custom properties

Security Events normalization

Building LSX (normalization part)

LSX XML Parser

Building LSX (normalization part)

This is a default field and must always be present in XML. Moreover,

Building LSX (normalization part)

Building LSX (normalization part)

Building LSX (normalization part)

Patterns and matchers

LSX XML basically consists of two different types of variables:

<pattern id=<ID>" xmlns=""><![CDATA[<REGEX>]]></pattern>

<pattern id=EventName1" xmlns=""><![CDATA[user.+?\shas\slogged\in]]></pattern>

Building LSX (normalization part)