QRadar Administrador Avanzado

7/25/2019 QRadar Administrador Avanzado

1/107

IBM Security QRadar 7.2 SIEM

Advanced Administration Course

Copyright 2013, ScienceSoft Inc.


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.


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.


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


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


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/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


8/107

Day 1


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.


10/107



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.


11/107



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


12/107



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


13/107



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.


14/107



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.


15/107



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


16/107



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.


17/107



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.


18/107



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.


19/107



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.


20/107



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).


21/107



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.


22/107



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.


23/107



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);


24/107



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).


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.


26/107


.+test vs .+?test

GREEDY LAZY


27/107


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)


28/107


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).


29/107


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


30/107


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.


31/107


Common Fields for Network Activity


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;


32/107



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


33/107


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


34/107


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.


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.


36/107


Obligatory fields

The development of any XML starts with LSX XML template. LSX XML parser consists of thefollowing obligatory fields:


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.


37/107


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.


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.


38/107


Optional fields


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.


39/107


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:


40/107



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:


41/107



Example for patterns and matchers:


42/107


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)


43/107


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


44/107


Values extraction


45/107


Values extraction

Remove any unused fields and their corresponding Pattern IDs from the LSX.


46/107


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.


47/107


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


48/107


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.


49/107


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]]>


50/107


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.


51/107


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


52/107



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.


53/107



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.


54/107


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.


55/107


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.


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.


57/107


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


58/107


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.


59/107


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


60/107


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.


61/107


Mapping events in UI

EventCRE vs new QID:


62/107


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.


63/107


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.


64/107

Day 2


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.


66/107


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.


67/107


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.


68/107


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.


69/107


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.


70/107


Enabling custom BB.

User Tuning / User Defined False Positives Tunings


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.


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.


73/107

Rules overview



74/107

Rules overview



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


76/107

Creating Rules

Functions (rule tests) overview


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)


78/107



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.


79/107



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.


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


81/107

Creating Rules

Rule Responses


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


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.


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.


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


86/107

Fine tuning false positives

From event properties


87/107


By Routing Rules


88/107


By rule thresholds update


89/107


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.


90/107


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.


91/107


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.


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.


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.


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.


95/107

Analyzing Offenses

Offenses


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.


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.


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.


99/107

QRadar Risk Manager

QRM Deployment: Adding as a Managed Host


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.


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.


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.


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.


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


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


106/107

SCIENCESOFT, INC.

2 Bedy Str.

220040 Minsk, BelarusPhone: + 375 17 293 3736Email: [email protected]

Web: www.scnsoft.com

Lets keep in touch

SCIENCESOFT OY

Hitsaajankatu 22

00810 Helsinki, FinlandPhone: +358 50 388 3000Email: [email protected]

Web: www.scnsoft.fi


107/107

www.scnsoft.com

Documents

QRadar Administrador Avanzado