QRadar Administrador Avanzado

Copyright © 2013, ScienceSoft ScienceSoft Inc.

This introductory course to IBM Security QRadar SIEM enables administrators of QRadar to use the full potential of QRadar reporting and offense mechanisms in their network environment. environment. Administrators gain knowledge on how to create new new users, log sources, understand the importance of connecting Vulnerability Vulnerabil ity 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 propert properties, ies, building Universal DSM Log Log Source eXtensions (LSX), and creation creation of rules. Intended auditory: IBM Security QRadar SIEM Administrators. Administrators. Each trainee must be given an ID to successfully complete the lab training session. Course duration: 2 days.

This introductory course to IBM Security QRadar SIEM enables administrators of QRadar to use the full potential of QRadar reporting and offense mechanisms in their network environment. environment. Administrators gain knowledge on how to create new new users, log sources, understand the importance of connecting Vulnerability Vulnerabil ity 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 propert properties, ies, building Universal DSM Log Log Source eXtensions (LSX), and creation creation of rules. Intended auditory: IBM Security QRadar SIEM Administrators. Administrators. Each trainee must be given an ID to successfully complete the lab training session. Course duration: 2 days.

How to connect to the QRadar Lab Environment:

1.

Go to

2.

If successful, you should see s ee QRadar console login page.

•

• • • • • •

• • •

• • • • • • • •

User roles and security profiles Create and customize network and remote hierarchies Reference Sets management Configure Vulnerability Scanner Configure Routing Rules Configure Retention Periods Regular Expressions Common normalization fields Creating and managing custom properties LSX structure Obligatory fields Optional fields Patterns and matchers Values extraction Timestamp formatting LSX deployment Testing events normalization

•

• • • • • •

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

•

• • • •

•

Host definitions Network definitions False positives User Tuning / User Defined False Positives Tunings Custom Rules o Event rule o Flow rule o Common rule o Offense rule

• •

• • •

• • • •

Anomaly Detection Rules o Anomaly rule o Behavioral rule o Threshold rule Functions (rule tests) overview Using custom properties and reference sets in rules tests Rule responses o Classic responses (SNMP, Syslog, E-Mail, IF-MAP) o Specific responses (Reference Set, Reference Map, Trigger Scan) o Including events into offense o Indices o Naming convention. Renaming offenses Optimizing Custom Rules Creating an OR Condition within the CRE Cleaning the SIM Model Identifying Network Assets

•

• • • • • • •

• • • •

From event properties By Routing Rules By rule thresholds update Discovering Servers Populating Building Blocks False Positive Rule Chains Cleaning-up fine tunings QRM Overview QRM Deployment QRM Adapters QRM use cases

•

All users that are allowed to access IBM Security QRadar SIEM must be configured first. The following items are assigned for each user:  ; The role represents granted user privileges to access specific functionality and information in QRadar. Default roles are Admin (full access) and All (limited access). Additional user roles can be created to meet the requirements for user permissions. The following basic operations are available for user roles management:  Create a user role;  Edit a user role;  Delete a user role. 

; The profile provides access to networks and log sources for QRadar users. Default security profile is for administrative users and allows access to all networks and all log sources. Additional security profiles can be created to meet the requirements for accessing networks and log sources. The following basic operations are available for security profiles management:  Create a security profile;  Edit a security profile;  Duplicate a security profile;  Delete a security profile.

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



     

: Create 6 different users on the QRadar. Each user will be given “Admin” user role and “Admin” security profile for the simplicity reasons. The password will be the same as the username.

•

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



Group

IP addresses

Accounting

10.1.1.0/25

Marketing

10.1.2.0/25

Group related servers into multi-CIDR objects: Group

IP addresses

Databases

10.1.5.10/32 10.1.10.20/32 10.1.20.30/32



Group units by top parent group. Nest 2 or more subgroups, if needed.

Acceptable CIDR values are: 

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



: /25…/32 (except /31) – Classless networks (1 – 124 hosts). 10.1.1.1/32

: Ensure all internal address spaces, both routable and non-routable, are defined within your network hierarchy. Failure to do so could result in QRadar generating an excessive number of false positives.

Network hierarchy structure is being saved to the following files on the QRadar file system:

It is not advisable to make changes to the network hierarchy simultaneously by two or more system administrators using QRadar UI: the system will report an error accessing the resource.



: Create the following network hierarchy in QRadar: International_Offices

All

10.0.0.0/8

International_Offices

Germany

10.10.0.0/16


Germany_Berlin_Marketing

10.10.1.0/24


Germany_Munich_Accounting

10.10.5.0/24


Italy

10.20.0.0/16


Italy_Rome_Marketing

10.20.1.0/24


Italy_Milan_Accounting

10.20.5.0/24


France

10.30.0.0/16


France_Paris_Marketing

10.30.1.0/24


France_Lyon_Accounting

10.30.5.0/24


Spain

10.40.0.0/16


Spain_Madrid_Marketing

10.40.1.0/24


Spain_Barcelona_Accounting

10.40.5.0/24


Poland

10.50.0.0/16


Poland_Warsaw_Marketing

10.50.1.0/24


Poland_Krakow_Accounting

10.50.5.0/24


Austria

10.60.0.0/16


Austria_Vienna_Marketing

10.60.1.0/24


Austria_Graz_Accounting

10.60.5.0/24

Trainee 1

Trainee 2

Trainee 3

Trainee 4

Trainee 5

Trainee 6

•

A reference set is a set of elements, such as a list of IP addresses or user names, that are derived from events and flows occurring on your network. The main purpose of the reference sets is to create manageable entities that can be reused within QRadar rules and offenses. Reference sets in QRadar are flat and represent linear structure of single line entries. The following basic operations are available for the reference set management:  Add a reference set; This operation can only be done manually through GUI.  Edit a reference set; This operation can be done manually through GUI as well as through an automatic rule/offense response.  View the contents of a reference set; 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.



: Create AlphaNumeric, case insensitive reference sets corresponding to your trainee ID. Add your trainee ID, name and surname as 3 elements.

Example: If your trainee ID is “Trainee 1”, you should create a reference set “ ” and put your (case insensitive) as 3 separate elements. Other trainees should follow the suite.

•

QRadar uses Vulnerability Integration Services (VIS) for building vulnerability assessment profiles. These profiles use network activity data to determine vulnerabilities and threat level on the business network assets. Vulnerability assessment integration is build upon QRadar interaction with various vulnerability scanners. The following two types of integration are supported: 

Such integration allows vulnerability scanners management through QRadar GUI: scan schedule, IP range set, vulnerability data transfer etc. This approach allows direct interaction with particular vulnerability scanner, which can be used on a daily basis for the most critical network assets. 

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

Add and configure suitable network scanner;



Configure scan schedules.



: Create Nessus Scanner instance corresponding to your Trainee ID to collect scheduled results of the Nessus Vulnerability Scanner. Add suitable schedule to collect the results by QRadar.

Example: If your Trainee ID is “Trainee 1”, you should create a Nessus scanner “ ” 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.

•

After receiving raw log data from log sources, QRadar can forward it to one or more external systems, such as ticketing or alerting systems. Normalized event data can also be forwarded to other QRadar systems. QRadar keeps all forwarded data unmodified. The following items must be configured first in order for QRadar to forward the data: 

These are external systems that QRadar will forward the data to. The following options are available for the configurations: 

Name;



Event Format (Raw or Normalized)



Destination Address;



Destination Port;



Protocol (Raw – TCP/UDP, Normalized – TCP only).



These are the rules that determine what log data is being forwarded and with what routing options. The following types of rules are available: 

Bulk event forwarding (through Admin tab);



Selective event forwarding (through Offenses->Rules tab).

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

Forward;



Drop;



Bypass Correlation.



: Create a routing rule corresponding to your badge to drop events that contain your name or surname in the “Username” normalized field.

Example: If you have a badge that says “Trainee 1”, you should create a routing rule called , (all three) as a filter so that any “ ” and put your ID incoming event containing your name, surname, or ID as Username should be dropped by this routing rule. Other trainees should follow the suite.

•

The following list of retention periods is available for many QRadar configuration settings as well as for the collected data from the log sources: 

Automatic Updates 



System Settings 





Backup Retention Period (days, 1-65535); Temporary Files Retention Period (6 hrs – 2 years);

Management Database Settings 

Accumulator Retention Minute-By-Minute (1 day – 2 years);



Accumulator Retention Hourly (1 day – 2 years);



Accumulator Retention Daily (1 day – 2 years);



Payload Index Retention (1 day – 2 years);



Offense Retention Period (1 day – 2 years);



Attacker History Retention Period (1 day – 2 years);



Target History Retention Period (1 day – 2 years);

Ariel Database Settings 

Search Results Retention Period (1 day – 3 month);



Ariel Database Settings 



Asset Profile Settings 



Search Results Retention Period (1 day – 3 month); Asset Profile Retention Period (1 day – 2 years);

Events and Flows Settings

How long does the collected data is being kept? QRadar utilizes retention buckets to define suitable retention periods for the collected events and flows that match custom filters in order to satisfy different data storage period requirements. QRadar provides 11 retention buckets: 10 unconfigured and 1 default. The precedence goes from top to bottom. If there are no specific requirements on the different kind of data storage, the default bucket will always be applied for all incoming events or flows as it has the lowest precedence, i.e. always checked last. The following properties are available for the events and flows buckets retention settings: 

Name (convenient name for the bucket);



Keep data placed in this bucket for (1 day – 2 years);



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



Delete data in this bucket (space vs retention period);



Current Filters (specific filters for custom only buckets).

•

A regular expression ( , , ) is a pattern describing a certain amount of text, against which strings can be matched. Strings either match the pattern or they don't. The shell/cmd wildcards and question marks (* and ?) might be considered as a very primitive type of RE. Just imagine that will match any filename with the “.” (dot) present, however, will only match a 3-character-long filename with the “.” present. In simple words, regular expressions represent

.

The very first one to look at is (dot), which represent . The other important metacharacter is (question mark), which literally means . It comes in handy when you want to match something that might have additional characters, but doesn’t necessarily have to: (American “center”, British “centre”). The other two very import meta characters: (carat) and the and of a line respectively. Searching for the pattern but only if it’s on a line by itself.

(dollar sign), which are the will find the word ,

There are also metacharacters that control how many things are being matched. These are (plus) that matches of the immediately preceding item; and (asterisk) that matches , including , of the immediately preceding item.

GREEDY

LAZY

Regular expressions make the use of character classes or sets, which are specified by (square brackets). Simply put the required characters in the square brackets that will form a : . This example defines a class of all English alphabet letters in both and cases as well as from . The specified regex will match a single character out of this class. Regular expressions can use

(parentheses) as

for the specific regex match:

The placeholders or backreferences are used to return only a matched part of the string instead of the whole string (Hint: Custom Properties) Another useful metacharacter is (pipe), which means . This metacharacter has to be used with (parentheses) identifying the scope: will match both and capturing or as a backreference #1. If we do not want to capture the backreference, the regex has to be written as follows:

Regular expressions use special metacharacters (not limited to, depending on regex flavor) for , , , tab etc. There is additional repetition operator that allows to specify how many times a token can be repeated. The syntax is , where is a positive integer number indicating the of matches, and is an integer equal to or greater than min indicating the of matches. If the comma is present but max is omitted, the maximum number of matches is infinite. Examples: will match

or

will match digits will match

digits infinitely (10-~); and exactly (10-99).

(10-9999);

•

There is an infinite number of regular expressions that can be used to match a desired string of text. The following are several common regular expressions:

IPv4 Address

(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})

127.0.0.1, 192.168.10.1

Port Number

(\d{1,5})

22, 80, 10001

MAC Address

((?:[0-9a-fA-F]{2}\:){5}[0-9a-fA-F]{2})

00:11:22:AA:66:DD

Protocol

(tcp|udp|icmp|gre)

tcp

Device Time

(\w{3}\s\d{2}\s\d{2}:\d{2}:\d{2})

Oct 28 10:01:10

White Space

\s

Match Anything

.+?

Anything will be matched here

This is only the beginning of regular expressions that cover very basics necessary for the QRadar integration. Mastering regular expressions cannot be thought over night and requires additional time for reading and practicing. Advanced reading material as well as regex related software (Regex Buddy) can be found on the internet.

•

QRadar includes a comprehensive list of available normalization fields for both Log Activity and Network Activity. The following fields are considered to be common because they are used as default fields while displaying the default views of Log Activity and Network Activity. 

normalized name of the event; Log Source that sent the event; number of events combined into the normalized event; date and time at which QRadar received the event; low level category associated with this event; source IP address of the event; source port of the event; destination IP address of the event; destination port of the event; username associated with the event; magnitude of the event.



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). time at which QRadar receives the flow; time at which QRadar stores the flow in the database; source IP address of the flow; source port of the flow; destination IP address of the flow; destination port of the flow; username associated with the flow; magnitude of the flow; total number of bytes in the flow; total number of packets sent from the source; total number of packets sent to the destination; 



total number of packets within the flow; protocol associated with the flow; application detected within the flow; Internet Control Message Protocol type and code; Transmission Control Protocol flags of the source packet; Transmission Control Protocol flags of the destination packet.

•

Standard normalization fields are not always enough to build required filters or rules. Custom properties are properties that you can create by extracting the necessary data from unnormalized event payload. The following are 2 types of the custom properties: 

These properties are extracted using Java flavor RegEx statements. 

These properties are created by performing operations on existing numeric properties. The following naming convention for the custom properties is considered as a good practice:

Good Examples

Confusing Examples



: Create a custom property corresponding to Trainee ID. The properties should extract user name out of the following statement and the like:

<23>Oct 20 08:33:48 fakeware src=10.10.1.2 uid=root success=yes msg=user was created on the system Example: If your Trainee ID “Trainee 1”, you should create a custom property called “ ” to extract username “fake_user ” out of the event. Username can potentially have only letters, numbers, _ (underscore), and – (hyphen). Other trainees should follow the suite.

•

QRadar provides Universal Device Support Module (uDSM) Log Source eXtension (LSX) framework that allows custom development and integration for unsupported log sources. Additionally, LSX can provide parsing enhancements to already existing DSM to cover additional reporting requirements. The LSX uses Java flavor regular expressions to provide parsing logic for the data extraction and further normalization with QRadar. LSX consists of the following items: 

Optional. A binary for collecting/preprocessing unsupported log source data to make it available for QRadar standard protocols. The need for preprocessor is based on the log source data availability. 

Mandatory. An XML file that contain QRadar parsing and matching rules for the data normalization process. This is the core of any LSX and its development requires advanced knowledge of regular expressions. 

Optional . Ordinary, the mapping of successfully parsed data by LSX XML and assigning suitable QRadar IDs (QID) is a manual process involving QRadar command prompt and GUI for each event. Optionally, a shell script for creating QRadar QID mappings for the data normalization process can be created to automate manual task.

•

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

This is a default field and must always be present in XML. Moreover, its default value must not be modified. Failure to comply will result in malfunction of LSX. The action that the event represent. The value of this field plays vital role in the data correlation process as QRadar at least needs to know what kind of action was performed.

•

The following LSX XML fields are optional and their presence depends on the corresponding data availability within the event. Best practices suggest that all available data should be parsed for better correlation and visibility. specific category the event belongs to; IP address of the source; port of the source; real IP address of the source; mapped IP address of the source; MAC identifier of the source; real port of the source; mapped port of the source; IP address of the destination; port of the destination; real IP address of the destination.

•

mapped IP address of the destination; real port of the destination; mapped port of the destination; MAC identifier of the destination; time at which the event has occurred; protocol used; user who is responsible for the event; host name (or IP address) where the event has occurred; name of the group that the host belongs to; NetBIOS name of the host; user-specific data associated with the event; IPv6 source IP address for the message; IPv6 destination IP address for the message.

•

LSX XML basically consists of two different types of variables: 

Patternsare used for defining Regex patterns that will match specific parts from the incoming event. The number of patterns vary and depends on the data availability. The structure of a pattern is as follows: where can be any name of your choice, except for the mandatory ” that must always be present with the default value;

” field

can be any regex that is used for the purpose of extracting the corresponding data. Example:

•



Matchers are used to link together parsed values with QRadar normalized fields so that the specific data gets assigned to proper QRadar variables like Username, Source IP address, etc. The number of matchers must be the same as the number of patterns. The structure of a matcher is as follows:
"

order=“

“

pattern-id =“

“

capture-group =“

“

enable-substitutions=“

”/>

where values from the obligatory and optional fields tables; order of precedence, i.e. 1, 2, 3, etc. Depends on the number of similar patterns; correspond to the name of the pattern ID used in patterns; number of the regex capture group (if any) or a custom group name; “true” for a custom group name, otherwise “false”.

•

Example for patterns and matchers: will yield the following matchers:

•



A critical step in creating a Universal DSM is reviewing the logs for usability. At a bare minimum, the logs should have a value that can be mapped to an event name. The event name should be a unique value that can distinguish the various log types. 

An example of

logs:

Oct 20 17:16:14 dropbear[22331]: 192.168.50.80:3364 May 20 17:16:26 dropbear[22331]: 192.168.50.80:3364

for 'root‘ from

for 'root' from

May 20 16:42:19 kernel: IN=vlan2 OUT= MAC=00:01:5c:31:39:c2:08:00 SRC=172.29.255.121 DST=255.255.255.255 PROTO=UDP SPT=67 DPT=68 

An example of

logs:

Oct 21 08:12:08 loopback 1256559128 autotrace[215824]: W: trace: no map for prod 49420003, idf 010029a2, lal 00af0008 Oct 22 16:35:00 sxpgbd0081 last message repeated 7 times Oct 24 01:30:00 sxpgbd0081 /usr/local/monitor-rrd/sxpgbd0081/.rrd (rc=-1, opening '/usr/local/monitor-rrd/sxpgbd0081/.rrd': No such file or directory)

•



The first step in creating the log source extension is reviewing the unsupported logs and determining what fields will be used. At a bare minimum, the EventName field must be used. Determine which values in the unsupported log source can be mapped to the fields in the LSX template. It is to use all of the fields in the default LSX template. Example log entry: May 20 17:24:59 kernel: DROP MAC=5c:31:39:c2:08:00 SRC=172.29.255.12 DST=192.168.100.25 LEN=351 TOS=0x00 PREC=0x00 TTL=64 ID=9582 PROTO=UDP SPT=67 DPT=68 LEN=331 The following fields are usable for this example: , i.e. , i.e. MAC= , i.e. SRC= , i.e. DST= , i.e. PROTO= , i.e. SPT= , i.e. DPT=

•

•

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

•

Rename the Pattern IDs to a unique name. This saves confusion if multiple patterns are used and helps distinguish between field and Pattern ID names.

•



The next step in creating a uDSM is building the regular expression patterns. 

Visually analyze the unsupported log source to identify unique patterns. These patterns will later be translated into regular expressions. When possible, you should include characters before and after the actual value to provide a basic level of error checking. This will prevent similar values from being unintentionally matched.

Field Name

Matched Text

Regex

EventName

DROP

\sDROP\s

SourceMAC

MAC=5c:31:39:c2:08:00

MAC=((?:[0-9a-fA-F]{2}\:){5}[0-9a-fA-F]{2})

SourceIp

SRC=172.29.255.121

SRC=(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})

DestinationIp

DST=192.168.100.25

DST=(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})

Protocol

PROTO=UDP

PROTO=((?:tcp|udp|icmp|gre))\s

SourcePort

SPT=67

SPT=(\d{1,5})\s

DestinationPort DPT=68

DPT=(\d{1,5})\s

•

It is important to isolate capturing groups as the value passed to QRadar fields should only contain relevant values, but not the entire string match. 

The next step is to migrate the patterns with capture groups into the LSX.

•

While logging an event, different log sources produce vast variety of timestamps at which events were logged at the source. These timestamps do not follow a unique pattern and therefore have to be normalized for QRadar to correctly display the time, at which the event occurred rather than received by QRadar. This is very important for searches, correlation rules and offenses. LSX framework provides flexibility through the use of a corresponding pattern and a matcher for parsing and formatting the original timestamp. A timestamp candidate “<14> Jan 06 14:31:56 test-host” will produce the following pattern and matcher for the event timestamp:

(\w{3}\s\d{2}\s[\d:]+)\s]]>



: Make sure the rule “FalsePositive: False Positive Rules and Building Blocks” includes all the custom BBs you have created for identifying false positives and want to utilize.



Rename Offense with new event creation using special naming convention.



Check the rules which are not creating offenses. A new rule(s) may need to be created to include those and create offense, or custom search could be used for reporting.



Use event category as a matching condition instead of specific QID when possible.



Use Log Source Group instead of listing specific Log Sources. Some of the rules will get broken because of removed Log Sources. Hence the use of Log Source Group is highly advised.



Use network hierarchy element(s) or BB instead of specifying exact IP addresses.



Use dynamic reference set or BB with users allowed to perform actions instead of listing names.



Add annotations for each and every Offense.



Review all rules with disabled offense creation. Most likely some of them will need to be enabled.



: Create a rule corresponding to your Trainee ID that matches your trainee ID, name or surname in custom event property from the reference set “Trainee X” from the relevant log. Rule response should be configured to generate on offense including original events. The offense should have the same name as the rule.

Example: If your Trainee ID is “Trainee 1”, you should create an Event Rule that will generate an offense as a rule response, called “ ” and add a condition with the reference set “ ” to match your Trainee ID, name or surname out of the custom property “ ”. Other trainees should follow the suite.

•

•

QRadar Risk Manager is an internal component of QRadar SIEM solution that proactively helps in assessing the risks from vulnerabilities, correlating the network topology information with data from QRadar SIEM, including assets configuration, events and flow patterns. QRM also helps in detecting configuration errors in firewalls and IPS systems to build a complete picture of a possible intrusion path.

•

QRM provides the following key capabilities: 

Policy monitoring to improve compliance QRadar Risk Manager features an automated policy engine that simplifies the assessment of a wide spectrum of information security and compliance policies.



Device configuration management to detect changes and profile future risks QRadar Risk Manager provides automated collection, monitoring and auditing of device configurations across an organization’s switches, routers, firewalls and intrusion detection system (IDS)/intrusion prevention system (IPS) devices.



Modeling and simulation of attacks and network configuration changes QRadar Risk Manager provides simulation capabilities that can check network connectivity before and after a proposed network configuration change, such as adding a firewall rule to one or more devices.

•

IBM Security QRadar Risk Manager deployment includes a IBM Security QRadar SIEM Console and QRadar Risk Manager appliance as a managed host. QRM can be supplied either as a hardware appliance or a software image to be installed on existing hardware that meets certain requirements. During the installation, QRM requires the following parameters in order to be properly initiated: •

Hostname - Type a fully qualified domain name as the system hostname.

•

IP Address - Type the IP address of the system.

•

Network Mask - Type the network mask address for the system.

•

Gateway - Type the default gateway of the system.

•

Primary DNS - Type the primary DNS server address.

•

Secondary DNS - Optional. Type the secondary DNS server address.

•

Public IP - Optional. Type the Public IP address of the server.

Once the initial installation and configuration are completed, QRM needs to be added as a managed host to QRadar SIEM. This is achieved through the Deployment Editor in QRadar Console Admin tab.

•

•

QRM uses adapters to integrate the network devices into QRadar SIEM. With the help of adapters, QRM collects and imports configuration information from the network devices like firewalls, routers and switches. The following adapters are supported: •

Check Point SecurePlatform Appliances

•

Cisco Internet Operating System (IOS)

•

Cisco Catalyst (CatOS)

•

Cisco Security Appliances

•

Juniper Networks ScreenOS

•

Juniper Networks JUNOS

•

Juniper Networks NSM

The adapters need to be installed on the QRM in order to provide the support for the required devices.

•

The following methods of adding devices are available in QRadar Console through Admin tab (Plugins->QRM): •

- Add one device. - Add multiple devices.

•

•

- Add devices that are managed by a Juniper Networks NSM console. - Add devices that are managed by a Check Point Security Manager

•

Server (CPSMS). For more details, please, consult the user documentation for QRM Adapters.

•

The following use cases are identified with QRM key capabilities: 

Collected by QRM configuration information for network devices, can be used for audit compliance and to schedule configuration backups. The configuration information for your devices is collected from device backups in Configuration Source Management. Each time QRadar Risk Manager backs up your device list, it archives a copy of your device configuration to provide a historical reference. 

The topology in QRadar Risk Manager displays a graphical representation of your network devices. A topology path search can determine how your network devices are communicating and the network path that they use to communicate. Path searching allows QRadar Risk Manager to visibly display the path between a source and destination, along with the ports, protocols, and rules. 

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.

•

The following use cases are identified with QRM key capabilities: 

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

Organizations use corporate security policies to define risks and the communications that are allowed between assets and networks. To assist with compliance and corporate policy breaches, organizations use Policy Monitor to assess and monitor risks that might be unknown. 

You can use a simulation to test your network for vulnerabilities from various sources. 

You can use a topology model to determine the effect of configuration changes on your network using a simulation.

An international IT company, expert in the design, development and delivery of custom software solutions, IT consulting and IT outsourcing services. • Locations in •

and

, customers in

countries

full-time staff; established in

•

Software development and IT outsourcing

•

Mobile and telecom solutions

• Information Security (SIEM) solutions • Enterprise document management solutions • Cloud and Remote infrastructure management services

•

•

•

•

•

•

in ; QRadar reseller in , two certified QRadar technical resources, Tivoli Security/ QRadar sales resources SIEM implementation engagements in Created together with IBM PS and Enablement teams; Participated in the creation of QRadar exam as an invited IBM partner →

A number of QRadar Log Source Extensions ( Modules ( ) created

) and Device Supported

Two major releases of IBM TCIM (2007-2008), three major releases of I BM Tivoli Security Information and Event Manager (TSIEM) major releases (2009-2011) More than 120 completed CISM, TCIM, and TSIEM and Compliance Management Modules projects, over 40 device rules and core bug-fixing for TSOM

SCIENCESOFT, INC.

SCIENCESOFT OY

2 Bedy Str. 220040 Minsk, Belarus Phone: + 375 17 293 3736 Email: [email protected] Web: www.scnsoft.com

Hitsaajankatu 22 00810 Helsinki, Finland Phone: +358 50 388 3000 Email: [email protected] Web: www.scnsoft.fi

QRadar Administrador Avanzado

Recommend Documents