qradar administrador avanzado
Post on 26-Feb-2018
251 Views
Preview:
TRANSCRIPT
-
7/25/2019 QRadar Administrador Avanzado
1/107
IBM Security QRadar 7.2 SIEM
Advanced Administration Course
Copyright 2013, ScienceSoft Inc.
-
7/25/2019 QRadar Administrador Avanzado
2/107
Abstract
This introductory course to IBM Security QRadar SIEM enables administrators of QRadar to use the fullpotential of QRadar reporting and offense mechanisms in their network environment. Administratorsgain knowledge on how to create new users, log sources, understand the importance of connectingVulnerability 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, buildingUniversal DSM Log Source eXtensions (LSX), and creation of rules.
Intended auditory: IBM Security QRadar SIEM Administrators. Each trainee must be given an ID tosuccessfully complete the lab training session.
Course duration: 2 days.
-
7/25/2019 QRadar Administrador Avanzado
3/107
Connect to Lab Environment
How to connect to the QRadar Lab Environment:
1. Go to https://qradar.scnsoft.com
2. If successful, you should see QRadar console login page.
-
7/25/2019 QRadar Administrador Avanzado
4/107
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
-
7/25/2019 QRadar Administrador Avanzado
5/107
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 Ruleso Event ruleo Flow ruleo Common ruleo Offense rule
-
7/25/2019 QRadar Administrador Avanzado
6/107
Agenda
Day 2
Anomaly Detection Ruleso Anomaly ruleo Behavioral ruleo 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 offenseo Indiceso Naming convention. Renaming offenses
4. Tuning rules
Optimizing Custom Rules Creating an OR Condition within the CRE Cleaning the SIM Model Identifying Network Assets
-
7/25/2019 QRadar Administrador Avanzado
7/107
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
-
7/25/2019 QRadar Administrador Avanzado
8/107
Day 1
-
7/25/2019 QRadar Administrador Avanzado
9/107
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. Thefollowing items are assigned for each user: User role;
The role represents granted user privileges to access specific functionality andinformation 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. Defaultsecurity profile is for administrative users and allows access to all networks and all logsources. Additional security profiles can be created to meet the requirements foraccessing 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.
-
7/25/2019 QRadar Administrador Avanzado
10/107
Introduction to QRadar administration
features and functionality
Security profile management includes permission precedence, which allows QRadar todisplay 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.
-
7/25/2019 QRadar Administrador Avanzado
11/107
Introduction to QRadar administration
features and functionality
Task 1: Create 6 different users on the QRadar. Each user will be given Admin user roleand Admin security profile for the simplicity reasons. The password will be the same asthe username.
Trainee1
Trainee2
Trainee3
Trainee4
Trainee5
Trainee6
-
7/25/2019 QRadar Administrador Avanzado
12/107
Introduction to QRadar administration
features and functionality
Create and customize network and remote hierarchies
QRadar SIEM utilizes network hierarchy to understand the network traffic and provide theability to view the network activity across the entire network infrastructure. Networkhierarchy needs to be defined by a range of IP addresses representing geographicallocation and/or business units (i.e. Europe Office, Marketing Dept.). The following bestpractices 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 related servers into multi-CIDR objects:
Group IP addresses
Accounting 10.1.1.0/25
Marketing 10.1.2.0/25
Group IP addresses
Databases 10.1.5.10/32
10.1.10.20/32
10.1.20.30/32
-
7/25/2019 QRadar Administrador Avanzado
13/107
Introduction to QRadar administration
features and functionality
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 definedwithin your network hierarchy. Failure to do so could result in QRadar generating anexcessive number of false positives.
-
7/25/2019 QRadar Administrador Avanzado
14/107
Introduction to QRadar administration
features and functionality
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 bytwo or more system administrators using QRadar UI: the system will report an error
accessing the resource.
-
7/25/2019 QRadar Administrador Avanzado
15/107
Introduction to QRadar administration
features and functionality
Task 2: Create the following network hierarchy in QRadar:Group Subgroup IP addresses
International_Offices All 10.0.0.0/8
International_Offices Germany 10.10.0.0/16
International_Offices Germany_Berlin_Marketing 10.10.1.0/24
International_Offices Germany_Munich_Accounting 10.10.5.0/24
International_Offices Italy 10.20.0.0/16
International_Offices Italy_Rome_Marketing 10.20.1.0/24
International_Offices Italy_Milan_Accounting 10.20.5.0/24
International_Offices France 10.30.0.0/16
International_Offices France_Paris_Marketing 10.30.1.0/24
International_Offices France_Lyon_Accounting 10.30.5.0/24
International_Offices Spain 10.40.0.0/16
International_Offices Spain_Madrid_Marketing 10.40.1.0/24International_Offices Spain_Barcelona_Accounting 10.40.5.0/24
International_Offices Poland 10.50.0.0/16
International_Offices Poland_Warsaw_Marketing 10.50.1.0/24
International_Offices Poland_Krakow_Accounting 10.50.5.0/24
International_Offices Austria 10.60.0.0/16
International_Offices Austria_Vienna_Marketing 10.60.1.0/24
International_Offices Austria_Graz_Accounting 10.60.5.0/24
Trainee 1
Trainee 2
Trainee 3
Trainee 4
Trainee 5
Trainee 6
-
7/25/2019 QRadar Administrador Avanzado
16/107
Introduction to QRadar administration
features and functionality
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 ofthe reference sets is to create manageable entities that can be reused within QRadar rulesand offenses. Reference sets in QRadar are flat and represent linear structure of single lineentries. 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 automaticrule/offense response.
View the contents of a reference set;This operation can only be done manually through GUI.
Delete a reference set (manually through GUI);This operation can only be done manually through GUI.
Import/Export elements to/from a reference set;This operation can only be done manually through GUI.
-
7/25/2019 QRadar Administrador Avanzado
17/107
Introduction to QRadar administration
features and functionality
Task 3: Create AlphaNumeric, case insensitive reference sets corresponding to yourtrainee 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
andput your trainee ID, name and surname (case insensitive) as 3 separate elements. Othertrainees should follow the suite.
-
7/25/2019 QRadar Administrador Avanzado
18/107
Introduction to QRadar administration
features and functionality
Configure Vulnerability Scanner
QRadar uses Vulnerability Integration Services (VIS) for building vulnerability assessmentprofiles. These profiles use network activity data to determine vulnerabilities and threatlevel on the business network assets. Vulnerability assessment integration is build uponQRadar interaction with various vulnerability scanners. The following two types ofintegration 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 directinteraction with particular vulnerability scanner, which can be used on a daily basis forthe most critical network assets.
Vulnerability data file import
Such integration allows import of already available vulnerability reports through fileimport. This approach can be used on a monthly basis for large sets of vulnerabilitydata covering huge networks, which can be gathered in advance.
In order for QRadar to build vulnerability assessment profiles for the network assets, thefollowing steps must be performed on QRadar:
Add and configure suitable network scanner;
Configure scan schedules.
-
7/25/2019 QRadar Administrador Avanzado
19/107
Introduction to QRadar administration
features and functionality
Task 4: Create Nessus Scanner instance corresponding to your Trainee ID to collectscheduled results of the Nessus Vulnerability Scanner. Add suitable schedule to collectthe 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.
-
7/25/2019 QRadar Administrador Avanzado
20/107
Introduction to QRadar administration
features and functionality
Configure Routing Rules
After receiving raw log data from log sources, QRadar can forward it to one or moreexternal systems, such as ticketing or alerting systems. Normalized event data can also beforwarded to other QRadar systems. QRadar keeps all forwarded data unmodified. Thefollowing 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 followingoptions 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 whatrouting options. The following types of rules are available:
Bulk event forwarding (through Admin tab);
Selective event forwarding (through Offenses->Rules tab).
-
7/25/2019 QRadar Administrador Avanzado
21/107
Introduction to QRadar administration
features and functionality
The event forwarding is very convenient for the situations when there are specificrequirements for certain events handling and such events of matched criteria need to beforwarded for the storage, immediate handling, and/or escalation. Sometimes, it isnecessary to filter out traffic based on a specific value of normalized fields to save storagespace.
The following routing options are available:
Forward;
Drop;
Bypass Correlation.
-
7/25/2019 QRadar Administrador Avanzado
22/107
Introduction to QRadar administration
features and functionality
Task 5: Create a routing rule corresponding to your badge to drop events that containyour name or surname in the Username normalized field.
Example: If you have a badge that says Trainee 1, you should create arouting rule calledTrainee1 Drop
and put your ID trainee1, name or surname (all three) as a filter so that anyincoming event containing your name, surname, or ID as Username should be dropped by
this routing rule. Other trainees should follow the suite.
-
7/25/2019 QRadar Administrador Avanzado
23/107
Introduction to QRadar administration
features and functionality
Configure Retention Periods
The following list of retention periods is available for many QRadar configuration settings aswell 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);
-
7/25/2019 QRadar Administrador Avanzado
24/107
Introduction to QRadar administration
features and functionality
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 definesuitable retention periods for the collected events and flows that match custom filters inorder to satisfy different data storage period requirements. QRadar provides 11 retentionbuckets: 10 unconfigured and 1 default. The precedence goes from top to bottom. If thereare no specific requirements on the different kind of data storage, the default bucket willalways 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).
-
7/25/2019 QRadar Administrador Avanzado
25/107
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. Theshell/cmd wildcards and question marks (* and ?) might be considered as a very primitivetype 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 representpatterns with metacharacters
.The very first one to look at is . (dot), which represent any character. The other importantmetacharacter is ? (question mark), which literally means optional. It comes in handy whenyou want to match something that might have additional characters, but doesntnecessarily have to: cente?re? (American center, British centre).
The other two very import meta characters: ^ (carat) and the $ (dollar sign), which are thestart 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) thatmatches any number, including none, of the immediately preceding item.
-
7/25/2019 QRadar Administrador Avanzado
26/107
Security Events normalization
.+test vs .+?test
GREEDY LAZY
-
7/25/2019 QRadar Administrador Avanzado
27/107
Security Events normalization
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 aclass: [A-Za-z0-9].
This example defines a class of all English alphabet letters in both UPPER and lower cases aswell 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 stringinstead of the whole string (Hint: Custom Properties)
Another useful metacharacter is | (pipe), which means OR. This metacharacter has to beused with () (parentheses) identifying the scope: (T|t)est will match both Test and testcapturing T or t as a backreference #1. If we do not want to capture the backreference, theregex has to be written as follows: (?:T|t)est
NOTE: a? vs (?:a)
-
7/25/2019 QRadar Administrador Avanzado
28/107
Security Events normalization
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 canbe repeated. The syntax is {min,max}, where min is a positive integer number indicating theminimum number of matches, and max is an integer equal to or greater than min indicatingthe maximum number of matches. If the comma is present but max is omitted, themaximum 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).
-
7/25/2019 QRadar Administrador Avanzado
29/107
Security Events normalization
Common Regular Expressions
There is an infinite number of regular expressions that can be used to match a desiredstring of text. The following are several common regular expressions:
This is only the beginning of regular expressions that cover very basics necessary for theQRadar integration. Mastering regular expressions cannot be thought over night andrequires additional time for reading and practicing. Advanced reading material as well asregex related software (Regex Buddy) can be found on the internet.
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
-
7/25/2019 QRadar Administrador Avanzado
30/107
Security Events normalization
Common normalization fields
QRadar includes a comprehensive list of available normalization fields for both Log Activityand Network Activity. The following fields are considered to be common because they areused as default fields while displaying the default views of Log Activity and Network Activity.
Common Fields for Log Activity
Field Name Description
Event Name normalized name of the event;
Log Source Log Source that sent the event;
Event Count number of events combined into the normalized event;
Time date and time at which QRadar received the event;
Low Level Category low level category associated with this event;
Source IP source IP address of the event;Source Port source port of the event;
Destination IP destination IP address of the event;
Destination Port destination port of the event;
Username username associated with the event;
Magnitude magnitude of the event.
-
7/25/2019 QRadar Administrador Avanzado
31/107
Security Events normalization
Common Fields for Network Activity
Field Name Description
Flow Type
measurement of the ratio of incoming to outgoing activity.
Standard Flow bidirectional traffic;
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;
-
7/25/2019 QRadar Administrador Avanzado
32/107
Security Events normalization
Field Name Description
Total Packets total number of packets within the flow;
Protocol protocol associated with the flow;
Application application detected within the flow;
ICMP Type/Code Internet Control Message Protocol type and code;
Source Flags Transmission Control Protocol flags of the source packet;
Destination Flags Transmission Control Protocol flags of the destination packet.
Common Fields for Network Activity
-
7/25/2019 QRadar Administrador Avanzado
33/107
Security Events normalization
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 datafrom 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 numericproperties.
The following naming convention for the custom properties is considered as a goodpractice:
:
Good Examples Confusing Examples
Oracle: Role Role
SELinux: Role Role
MS Server: Role Role
-
7/25/2019 QRadar Administrador Avanzado
34/107
Security Events normalization
Task 6: Create a custom property corresponding to Trainee ID. The properties shouldextract user name out of the following statement and the like:
Oct 20 08:33:48 fakeware src=10.10.1.2 uid=root success=yes msg=user fake_userwas created on the system
Example: If your Trainee ID Trainee 1, you should create a custom property calledTrainee1: Affected User
to extract username fake_user out of the event. Username canpotentially have only letters, numbers, _ (underscore), and (hyphen). Other traineesshould follow the suite.
-
7/25/2019 QRadar Administrador Avanzado
35/107
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 coveradditional reporting requirements. The LSX uses Java flavor regular expressions to provideparsing logic for the data extraction and further normalization with QRadar. LSX consists ofthe following items:
Preprocessor
Optional. A binary for collecting/preprocessing unsupported log source data to make itavailable for QRadar standard protocols. The need for preprocessor is based on thelog source data availability.
LSX XML Parser
Mandatory. An XML file that contain QRadar parsing and matching rules for the datanormalization process. This is the core of any LSX and its development requiresadvanced knowledge of regular expressions.
LSX Mapper
Optional. Ordinary, the mapping of successfully parsed data by LSX XML and assigningsuitable QRadar IDs (QID) is a manual process involving QRadar command promptand 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.
-
7/25/2019 QRadar Administrador Avanzado
36/107
Building LSX (normalization part)
Obligatory fields
The development of any XML starts with LSX XML template. LSX XML parser consists of thefollowing 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 inmalfunction of LSX.
EventName The action that the event represent. The value of this field plays vitalrole in the data correlation process as QRadar at least needs to
know what kind of action was performed.
-
7/25/2019 QRadar Administrador Avanzado
37/107
Building LSX (normalization part)
Optional fields
The following LSX XML fields are optional and their presence depends on thecorresponding data availability within the event. Best practices suggest that all availabledata should be parsed for better correlation and visibility.
Field Name Description
EventCategory
specific category the event belongs to;
SourceIp IP address of the source;
SourcePort
port of the source;
SourceIpPreNAT
real IP address of the source;
SourceIpPostNAT
mapped IP address of the source;
SourceMAC
MAC identifier of the source;
SourcePortPreNAT
real port of the source;
SourcePortPostNAT
mapped port of the source;
DestinationIp
IP address of the destination;
DestinationPort
port of the destination;
DestinationIpPreNAT
real IP address of the destination.
-
7/25/2019 QRadar Administrador Avanzado
38/107
Building LSX (normalization part)
Optional fields
Field Name Description
DestinationIpPostNAT
mapped IP address of the destination;
DestinationPortPreNAT
real port of the destination;
DestinationPortPostNAT
mapped port of the destination;
DestinationMAC MAC identifier of the destination;DeviceTime
time at which the event has occurred;
Protocol
protocol used;
UserName
user who is responsible for the event;
HostName
host name (or IP address) where the event has occurred;
GroupName
name of the group that the host belongs to;
NetBIOSName NetBIOS name of the host;
ExtraIdentityData
user-specific data associated with the event;
SourceIpv6
IPv6 source IP address for the message;
DestinationIpv6
IPv6 destination IP address for the message.
-
7/25/2019 QRadar Administrador Avanzado
39/107
Building LSX (normalization part)
Patterns and matchers
LSX XML basically consists of two different types of variables:
Patterns
Patternsare used for defining Regex patterns that will match specific parts from theincoming event. The number of patterns vary and depends on the data availability.The structure of a pattern is as follows:
-
7/25/2019 QRadar Administrador Avanzado
40/107
Building LSX (normalization part)
Patterns and matchers
Matchers
Matchers are used to link together parsed values with QRadar normalized fields sothat the specific data gets assigned to proper QRadar variables like Username, SourceIP address, etc. The number of matchers must be the same as the number ofpatterns. The structure of a matcher is as follows:
-
7/25/2019 QRadar Administrador Avanzado
41/107
Building LSX (normalization part)
Patterns and matchers
Example for patterns and matchers:
-
7/25/2019 QRadar Administrador Avanzado
42/107
Building LSX (normalization part)
Values extraction
Reviewing the logs
A critical step in creating a Universal DSM is reviewing the logs for usability. At a bareminimum, the logs should have a value that can be mapped to an event name. The eventname 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 from192.168.50.80:3364
May 20 17:16:26 dropbear[22331]: password auth succeeded for 'root' from192.168.50.80:3364
May 20 16:42:19 kernel: DROP IN=vlan2 OUT= MAC=00:01:5c:31:39:c2:08:00SRC=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 prod49420003, idf 010029a2, lal 00af0008 Oct 22 16:35:00 sxpgbd0081 last messagerepeated 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)
-
7/25/2019 QRadar Administrador Avanzado
43/107
Building LSX (normalization part)
Values extraction
Determining Which Fields Can Be Used
The first step in creating the log source extension is reviewing the unsupported logs anddetermining what fields will be used. At a bare minimum, the EventName field must beused.
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.12DST=192.168.100.25 LEN=351 TOS=0x00 PREC=0x00 TTL=64 ID=9582 PROTO=UDPSPT=67 DPT=68 LEN=331
The following fields are usable for this example:
EventName, i.e. DROPSourceMAC, i.e. MAC=5c:31:39:c2:08:00SourceIp, i.e. SRC=172.29.255.121DestinationIp, i.e. DST=192.168.100.25Protocol, i.e. PROTO=UDPSourcePort, i.e. SPT=67DestinationPort, i.e. DPT=68
-
7/25/2019 QRadar Administrador Avanzado
44/107
Building LSX (normalization part)
Values extraction
-
7/25/2019 QRadar Administrador Avanzado
45/107
Building LSX (normalization part)
Values extraction
Remove any unused fields and their corresponding Pattern IDs from the LSX.
-
7/25/2019 QRadar Administrador Avanzado
46/107
Building LSX (normalization part)
Values extraction
Rename the Pattern IDs to a unique name. This saves confusion if multiple patterns areused and helps distinguish between field and Pattern ID names.
-
7/25/2019 QRadar Administrador Avanzado
47/107
Building LSX (normalization part)
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. Thesepatterns 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 errorchecking. 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
-
7/25/2019 QRadar Administrador Avanzado
48/107
Building LSX (normalization part)
Values extraction
It is important to isolate capturing groups as the value passed to QRadar fields should onlycontain 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.
-
7/25/2019 QRadar Administrador Avanzado
49/107
Building LSX (normalization part)
Timestamp formatting
While logging an event, different log sources produce vast variety of timestamps at whichevents were logged at the source. These timestamps do not follow a unique pattern andtherefore have to be normalized for QRadar to correctly display the time, at which theevent 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 amatcher for parsing and formatting the original timestamp.
A timestamp candidate Jan 06 14:31:56 test-host will produce the following patternand matcher for the event timestamp:
(\w{3}\s\d{2}\s[\d:]+)\s]]>
-
7/25/2019 QRadar Administrador Avanzado
50/107
Building LSX (normalization part)
LSX deployment
At this point, the LSX is complete and can be used to parse the unsupported log sourcewithin QRadar. The completed LSX must be uploaded to QRadar and applied to theUniversal DSM. The logic from the LSX is then used to parse the logs from the unsupportedlog source.
The following steps must be produced within QRadar GUI to enable newly developed LSX:
Create Log Source ExtensionThis steps involves defining a new Log Source Extension within QRadar, specifying thevalues for the required fields and uploading newly created LSX XML file to completethe 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 LogSource, so that the data can be parsed correctly. Special attention must be paid forthe
Log Source Identifier
(LSI) variable, as this is how the incoming events will beassociated with the specific Log Source. After the Log Source creation, deploy thechanges.
-
7/25/2019 QRadar Administrador Avanzado
51/107
Building LSX (normalization part)
Testing events normalization
Initially, all of the events from the Universal DSM will appear as unknown in the Log Activitytab. This is normal. Correctly created Log Source with the corresponding LSX XML should atleast correctly identify the Log Source normalized field when the corresponding data isreceived by QRadar. This is achieved by the
Log Source Identifier
value during Log Sourceconfiguration.
cc c
-
7/25/2019 QRadar Administrador Avanzado
52/107
Building LSX (normalization part)
Testing events normalization
How to correctly specify the Log Source Identifier (LSI)? There are two approaches to solvethis:
Automatic
LSI is automatically identified as the IP address of the source host that send thesystem. 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 Sourcesshould always be specified manually.
-
7/25/2019 QRadar Administrador Avanzado
53/107
Building LSX (normalization part)
Testing events normalization
Further verification of event normalization would be to check if Event ID was correctlyparsed out of the incoming event as was specified in the LSX XML. This can be done bychecking the value of Event ID through the Map Event button in the Event Viewer.
-
7/25/2019 QRadar Administrador Avanzado
54/107
Building LSX (normalization part)
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 calledTrainee1_LSX
. Log Source Identifier must be determined based on the data analysis.Other trainees should follow the suite.
-
7/25/2019 QRadar Administrador Avanzado
55/107
Building LSX (normalization part)
Task 8: Create a LSX XML corresponding to your Trainee ID. XML should only contain thepatterns and matchers to extract the relevant data out of the relevant log sample. Logsamples relevancy is determined through the corresponding Log Activity filter. Aftercompletion, assign LSX XML to the appropriate Log Source.
Example: If your Trainee ID is Trainee 1, you should first create a filter called Trainee1and filter out the events relevant to a specific Log Source. Then, create an XML file basedon the copy of LSX XML Template called
Trainee 1_LSX.xml
. After log samples analysis, onlythe required patterns and matchers must be present, others deleted. After thedevelopment is complete, LSX XML should be associated with the Log Source
Trainee1
bycreating suitable Log Source Extension. Other trainees should follow the suite.
-
7/25/2019 QRadar Administrador Avanzado
56/107
Building LSX (mapping part)
QRadar event categories (High and Low Level)
Prior LSX development finalization, identified Event IDs must be correctly mapped to thecorresponding Event Names. Although the event names might appear as understandablevalues in the logs, e.g. DROP, DENY, and ACCEPT, QRadar has no understanding of whatthese values actual represent.
From QRadar perspective, these value are strings of text that are not mapped to any knownvalues. 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 fixedand 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 thatQID 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.
-
7/25/2019 QRadar Administrador Avanzado
57/107
Building LSX (mapping part)
Proper category assignment best practice
Any successful Event ID mapping lies within understanding of what exactly the Event IDrepresents, i.e. the action behind it. If the action is determined correctly, the appropriateHigh-Level Category and then Low-Level Category is chosen for the event out of the list ofavailable categories. The Low-Level Category must be as close as possible to the meaningof the action.
Example:
Analysis of the following event
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-Leveland Low-Level Category would be as follows:
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 genericpair 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.
Event ID High-Level Category Low-Level CategoryUser_Created_Success Authentication User Account Added
-
7/25/2019 QRadar Administrador Avanzado
58/107
Building LSX (mapping part)
EventCRE vs Custom QID
Mapping process of Event ID to QID involves the following two completely differentapproaches:
Mapping to Event CRE
Event CRE is an event template that is used by QRadar to generate new events. EventCRE templates already being present on QRadar system. Each Low-Level Category
may have Event CRE templates representing a particular kind of action. Event CRE arenot being associated with any Log Source and therefore can be used for a genericmapping purpose.
Mapping to Custom QID
Custom QID mapping is a more advanced technique that involves creation of a newQID first for a specific purpose only and then using this Custom QID for mapping aparticular Event ID. This technique requires knowledge of QRadar CLI tools.
-
7/25/2019 QRadar Administrador Avanzado
59/107
Building LSX (mapping part)
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 ]|-e[-f ]|-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
-f If you specify the -i or -e option, allows you tospecify a file name to import or export QID map entries
-dIf you specify the -i or -e option, allows you to specify adelimiter for the import or export file. The default is acomma
-h Display the help options
-
7/25/2019 QRadar Administrador Avanzado
60/107
Building LSX (mapping part)
Creating new QIDs
New QID are created with the following syntax:
qidmap_cli.sh -c --qname --qdescription --severity --
lowlevelcategoryid
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 CLIcommand:
/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-LevelCategory pair.
-
7/25/2019 QRadar Administrador Avanzado
61/107
Building LSX (mapping part)
Mapping events in UI
EventCRE vs new QID:
-
7/25/2019 QRadar Administrador Avanzado
62/107
Building LSX (mapping part)
Testing events mapping
After the mapping is successful, all new events that are identified by the correspondingEvent IDs will automatically be normalized and will participate in the correlation logic andrules.
-
7/25/2019 QRadar Administrador Avanzado
63/107
Building LSX (mapping part)
Task 9: Create corresponding EventCRE mapping for each event manually.
Example: All trainees should create suitable EventCRE mappings manually for all eventsrelevant to their Log Sources. Upon mapping completion, all events must have Event Nameand Low Level Category properly assigned.
-
7/25/2019 QRadar Administrador Avanzado
64/107
Day 2
-
7/25/2019 QRadar Administrador Avanzado
65/107
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. BBscan be created or edited to satisfy specific requirements. In simple words, BBs are testingconditions for the rules, thus BBs are the rules themselves, but without a specific action orrule respond defined. QRadar includes a comprehensive set of default predefined BBs tocover 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 thatcontain vast variety of predefined host assets that can be edited to reflect anyenvironment. 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 theSystem: Load Building Blocks
rule in order for the BB to work correctly.
-
7/25/2019 QRadar Administrador Avanzado
66/107
Building blocks (BB) overview and specifics.
Enabling custom BB.
Task 10: Create BB:HostDefinition corresponding to your Trainee ID with the source ordestination 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 calledBB:HostDefinition:Trainee1
and add a condition with the source or destination IP addressequal to 10.10.1.2. Other trainees should follow the suite.
-
7/25/2019 QRadar Administrador Avanzado
67/107
Building blocks (BB) overview and specifics.
Enabling custom BB.
Network definitions
Another frequently used in rules creation family of BBs is BB:NetworkDefinition family thatcontain vast variety of predefined network assets that can be edited to reflect any networkenvironment. This BB can be regarded as a soft copy of the Network Hierarchy. Missingnetworks can be easily created and exported as new BBs.
BB:NetworkDefinition are created taking into the account CIDRs of the required networkassets.
Best practices suggest that it is advisable to use the Network Hierarchy definitions ratherthan Building Blocks for rules checking IP addresses for networks.
-
7/25/2019 QRadar Administrador Avanzado
68/107
Building blocks (BB) overview and specifics.
Enabling custom BB.
False positives
Like any other BBs, BB:FalsePositive family is used to match incoming events based oncertain conditions. However, the purpose of the false-positive identification through BBs isto exclude matched events from contributing to the other rules that create offenses. Thisapproach is used to bulk-identify false-positive events with similar conditions, i.e. Low-LevelCategory.
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.
-
7/25/2019 QRadar Administrador Avanzado
69/107
Building blocks (BB) overview and specifics.
Enabling custom BB.
User Tuning / User Defined False Positives Tunings
To reduce the number of offenses, the following BBs needs to be edited since they areproducing 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 fromcreating offenses. The user must have appropriate permissions for creating customizedrules 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.
-
7/25/2019 QRadar Administrador Avanzado
70/107
Building blocks (BB) overview and specifics.
Enabling custom BB.
User Tuning / User Defined False Positives Tunings
-
7/25/2019 QRadar Administrador Avanzado
71/107
Rules overview
Custom Rules
A rule is a collection of tests that perform an action when certain conditions are met. Eachrule can be configured to capture and respond to a specific event, sequence of events, flowsequence, or offense. The actions which can be triggered can include sending an email orgenerating a syslog message. A rule can reference multiple building blocks by using thetests 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 eventproperties.
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 eventsand flows simultaneously.
Offense Rule
This rule is applicable for offenses only as it tests the conditions for already created
offenses.
-
7/25/2019 QRadar Administrador Avanzado
72/107
Rules overview
Anomaly Detection Rules
QRadar also offers a functionality of testing the conditions on aggregated fields thuscreating anomaly rules. In order to enable the anomaly rules creation, the search mustcontain a Group By field, be of Time series type, Capture Time Series data, and must alsobe 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 innetwork activity that occurs in regular seasonal patterns.
Threshold Rule
This rule type performs tests on aggregated fields to alert on network activity thatexceeds a defined threshold.
-
7/25/2019 QRadar Administrador Avanzado
73/107
Rules overview
Anomaly Detection Rules
-
7/25/2019 QRadar Administrador Avanzado
74/107
Rules overview
Anomaly Detection Rules
-
7/25/2019 QRadar Administrador Avanzado
75/107
Creating Rules
Functions (rule tests) overview
QRadar provides a comprehensive set of already predefined rule tests that can be usedwhen constructing a rule. These tests are written in human language so that the meaningof the test condition can be easily understood. The tests are grouped into the categoriesfor 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
-
7/25/2019 QRadar Administrador Avanzado
76/107
Creating Rules
Functions (rule tests) overview
-
7/25/2019 QRadar Administrador Avanzado
77/107
Creating Rules
Using custom properties and reference sets in rules tests
The following rules are suitable for working with Custom Properties and Reference Setsconditional testing:
when the event matches this search filter
when any of these event properties are contained in any of these reference set(s)
-
7/25/2019 QRadar Administrador Avanzado
78/107
Introduction to QRadar administration
features and functionality
Task 11: Create rule corresponding to your Trainee ID that matches your ID, name orsurname from the custom property Trainee X: Affected User from the relevant log. Norule response.
Example: If your Trainee ID is Trainee 1, you should create an Event Rule calledTrainee1:Rule: Custom Property Match
and add a condition with the custom propertyTrainee1: Affected User
to match your ID, name or surname. No rule response should be
configured. Other trainees should follow the suite.
-
7/25/2019 QRadar Administrador Avanzado
79/107
Introduction to QRadar administration
features and functionality
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 ruleresponse.
Example: If your Trainee ID is Trainee 1, you should create an Event Rule calledTrainee1:Rule: Reference Set Match
and add a condition to match the value of customproperty
Trainee1: Custom Property
from the reference set Trainee1
. No rule response
should be configured. Other trainees should follow the suite.
-
7/25/2019 QRadar Administrador Avanzado
80/107
Creating Rules
Rule Responses
During rule configuration wizard, QRadar provides the ability to configure the ruleresponse. 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 toallow 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
-
7/25/2019 QRadar Administrador Avanzado
81/107
Creating Rules
Rule Responses
-
7/25/2019 QRadar Administrador Avanzado
82/107
Tuning Rules
Optimizing Custom Rules
When building custom rules, it is highly recommended that you optimize the order of thetesting. This ensures that the rules do not slow down the Common Rule Engine (CRE). Thetests 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 expressionsearches. To ensure these tests run against a smaller subset of data and execute faster, itis 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
-
7/25/2019 QRadar Administrador Avanzado
83/107
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 conditionaltest. To create an OR condition within the CRE put each separate set of conditions into abuilding 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.
-
7/25/2019 QRadar Administrador Avanzado
84/107
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 offensesare based on the most current rules, discovered servers, and network hierarchy. When youclean the SIM model, all existing offenses are closed, but this does not affect existing eventsand flows.
-
7/25/2019 QRadar Administrador Avanzado
85/107
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
ServersProxy Servers BB-HostDefinition: Proxy Servers
Server Networks BB-HostDefinition: Server Networks
Vulnerability Scanners BB-HostDefinition: VA Scanner Source ID
-
7/25/2019 QRadar Administrador Avanzado
86/107
Fine tuning false positives
From event properties
-
7/25/2019 QRadar Administrador Avanzado
87/107
Fine tuning false positives
By Routing Rules
-
7/25/2019 QRadar Administrador Avanzado
88/107
Fine tuning false positives
By rule thresholds update
-
7/25/2019 QRadar Administrador Avanzado
89/107
Fine tuning false positives
Discovering Servers
QRadar automatically discovers and classifies servers in your network, providing a fasterinitial deployment and easier tuning when network changes occur.
The Server Discovery function uses the asset profile database to discover many types ofservers on your network. This function lists automatically discovered servers and enablesyou to select which servers you want to include in building blocks.
-
7/25/2019 QRadar Administrador Avanzado
90/107
Fine tuning false positives
Populating Building Blocks
Building blocks use the same tests as rules, however they do not have any actionsassociated with them. Building blocks group together commonly used tests, to buildcomplex logic, so they can be used in rules. Building blocks are often configured to testgroups 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 yournetwork, 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 onthe needs of your network.
-
7/25/2019 QRadar Administrador Avanzado
91/107
Fine tuning false positives
False Positive Rule Chains
The rule FalsePositive: False Positive Rules and Building Blocks is a special QRadar rulebecause it is the first rule to execute in the CRE. When it loads, all of its dependencies areloaded 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 rulehappens 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 willenable you to quickly find and identify the customizations within your site.
-
7/25/2019 QRadar Administrador Avanzado
92/107
Analyzing Offenses
Offenses
As event and flow data passes through the CRE, it is correlated using the rules setup on thecustomers QRadar system. Depending on how each rule is configured, an offense can begenerated based on this correlation. These Offenses are displayed using the Offenses tab.
Offense investigation is a time consuming process and requires understanding of thesubject of the offense as well as the common-sense knowledge of networking, computingand Information Technology (IT).
Common recommendations for QRadar correlation rules
Use most important information from event content to create Offense index. Note thatwhen index matches for different offenses in a short time period then only one offensewill be created from several rules.
Fill in all BBs (hosts definitions, port definitions, etc.) with proper informationcorresponding 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 excessivenumber of false-positive offenses to be created. For such rules offense creation couldbe omitted, and quick searches could be used for reporting (e.g. one search for all suchsuspicious rules triggered). It's OK to have single-event rules which are not generatingoffenses. Other option is to include timeframe or number of events seen.
-
7/25/2019 QRadar Administrador Avanzado
93/107
Analyzing Offenses
Common recommendations for QRadar correlation rules
IMPORTANT: Make sure the rule "System: Load Building Blocks" includes all the customBBs you have created and want to utilize.
IMPORTANT: Make sure the rule FalsePositive: False Positive Rules and Building Blocksincludes all the custom BBs you have created for identifying false positives and want toutilize.
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 createdto 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 getbroken because of removed Log Sources. Hence the use of Log Source Group is highlyadvised.
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 listingnames.
Add annotations for each and every Offense.
Review all rules with disabled offense creation. Most likely some of them will need to be
enabled.
-
7/25/2019 QRadar Administrador Avanzado
94/107
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 therelevant log. Rule response should be configured to generate on offense includingoriginal 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 generatean 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 outof the custom property
Trainee1: Custom Property
. Other trainees should follow the suite.
-
7/25/2019 QRadar Administrador Avanzado
95/107
Analyzing Offenses
Offenses
-
7/25/2019 QRadar Administrador Avanzado
96/107
QRadar Risk Manager
QRM Overview
QRadar Risk Manager is an internal component of QRadar SIEM solution that proactivelyhelps in assessing the risks from vulnerabilities, correlating the network topologyinformation with data from QRadar SIEM, including assets configuration, events and flowpatterns. QRM also helps in detecting configuration errors in firewalls and IPS systems tobuild a complete picture of a possible intrusion path.
-
7/25/2019 QRadar Administrador Avanzado
97/107
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 theassessment 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 ofdevice configurations across an organizations switches, routers, firewalls andintrusion 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 networkconnectivity before and after a proposed network configuration change, such as
adding a firewall rule to one or more devices.
-
7/25/2019 QRadar Administrador Avanzado
98/107
QRadar Risk Manager
QRM Deployment
IBM Security QRadar Risk Manager deployment includes a IBM Security QRadar SIEMConsole and QRadar Risk Manager appliance as a managed host. QRM can be suppliedeither as a hardware appliance or a software image to be installed on existing hardwarethat meets certain requirements. During the installation, QRM requires the followingparameters 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 amanaged host to QRadar SIEM. This is achieved through the Deployment Editor in QRadarConsole Admin tab.
-
7/25/2019 QRadar Administrador Avanzado
99/107
QRadar Risk Manager
QRM Deployment: Adding as a Managed Host
-
7/25/2019 QRadar Administrador Avanzado
100/107
QRadar Risk Manager
QRM Adapters
QRM uses adapters to integrate the network devices into QRadar SIEM. With the help ofadapters, QRM collects and imports configuration information from the network deviceslike 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 therequired devices.
-
7/25/2019 QRadar Administrador Avanzado
101/107
QRadar Risk Manager
QRM Adapters
The following methods of adding devices are available in QRadar Console through Admintab (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 ManagerServer (CPSMS).
For more details, please, consult the user documentation for QRM Adapters.
-
7/25/2019 QRadar Administrador Avanzado
102/107
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 foraudit compliance and to schedule configuration backups. The configurationinformation for your devices is collected from device backups in Configuration SourceManagement. 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 anddestination, 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.
-
7/25/2019 QRadar Administrador Avanzado
103/107
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 communicationsthat are allowed between assets and networks. To assist with compliance andcorporate policy breaches, organizations use Policy Monitor to assess and monitorrisks 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.
-
7/25/2019 QRadar Administrador Avanzado
104/107
ScienceSofts Identity
An international IT company, expert in the design, developmentand 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
WHO WE ARE:
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
-
7/25/2019 QRadar Administrador Avanzado
105/107
SIEM expertise
Authorized IBM security partner in Finland; QRadar reseller in Belarus,two certified QRadar technical resources, Tivoli Security/ QRadar salesresources
SIEM implementation engagements in USA, UK, Middle East, Africa
Created TSIEMQRadar Migration Guide together with IBM PS andEnablement teams; Participated in the creation of QRadar exam as aninvited IBM partner
A number of QRadar Log Source Extensions (LSXs) and Device SupportedModules (uDSMs) created
Two major releases of IBM TCIM (2007-2008), three major releases of IBMTivoli Security Information and Event Manager (TSIEM) major releases(2009-2011)
More than 120 completed CISM, TCIM, and TSIEM Event Sources andCompliance Management Modules projects, over 40 device rules andcore bug-fixing for TSOM
-
7/25/2019 QRadar Administrador Avanzado
106/107
SCIENCESOFT, INC.
2 Bedy Str.
220040 Minsk, BelarusPhone: + 375 17 293 3736Email: contact@scnsoft.com
Web: www.scnsoft.com
Lets keep in touch
SCIENCESOFT OY
Hitsaajankatu 22
00810 Helsinki, FinlandPhone: +358 50 388 3000Email: contact@scnsoft.fi
Web: www.scnsoft.fi
-
7/25/2019 QRadar Administrador Avanzado
107/107
www.scnsoft.com
top related