transitioning from tivoli security operations manager · pdf filetransitioning from tivoli...

Transitioning from Tivoli SecurityOperations Manager to QRadar

IBM Security Systems

Version: 1.0Date: March 4th, 2012

Author: Xavier [email protected]

Table of Contents

Introduction..............................................................................................................1Overview of the Transition Process.......................................................................1

1 Understand the Current Business Requirements..................................................22 Review Use Cases with TSOM...............................................................................2

2.1 Security Operations Center Use Case............................................................22.2 On-demand Security Investigations Use Case................................................32.3 Compliance Reporting Use Case....................................................................32.4 Centralized Log Management Use Case.........................................................3

3 Evaluating the TSOM Deployment........................................................................33.1 Architecture....................................................................................................43.2 Configuration..................................................................................................4

4 Mapping TSOM Concepts to QRadar Concepts......................................................54.1 Architecture....................................................................................................54.2 High Availability.............................................................................................74.3 Disaster Recovery..........................................................................................94.4 Log Management............................................................................................94.5 Users, Groups, and Roles.............................................................................124.6 Security Domains.........................................................................................124.7 Netblocks and Hosts.....................................................................................124.8 Sensors........................................................................................................134.9 Firewall Blocking...........................................................................................134.10 Event Types and Classes............................................................................144.11 Rules and Actions.......................................................................................144.12 Watchlists...................................................................................................164.13 Statistical Correlation.................................................................................164.14 Host Investigation Toolkit...........................................................................164.15 Vulnerability Import....................................................................................174.16 Ticketing and Workflow..............................................................................174.17 Terminology................................................................................................17

5 Planning a QRadar Deployment..........................................................................205.1 Design the QRadar Architecture...................................................................205.2 Install appliances.........................................................................................235.3 Reuse the EAM IPs or reconfigure endpoints................................................235.4 Do Initial Configuration................................................................................245.5 Convert business logic from TSOM to QRadar..............................................24

5.5.1 Example.................................................................................................255.6 Keep TSOM online for a period of time for historical queries.......................26

Appendix................................................................................................................27

Illustration Index

Illustration 1: Typical Enterprise TSOM Deployment................................................6Illustration 2: Typical QRadar Distributed Deployment............................................7Illustration 3: TSOM High Availability Deployment...................................................8Illustration 4: QRadar High Availability Deployment...............................................9

Index of Tables

Table 1: Protocols available in TSOM and QRadar..................................................11Table 2: QRadar Appliances...................................................................................21Table 3: Software features of Log Manager vs. QRadar..........................................23

Introduction

IBM Tivoli Security Operations Manager (TSOM) was developed as a tool for automating activities in a Security Operations Center. In 2011, IBM acquired Q1 Labs with the industry-leading security intelligence solution to enhance the offerings. Many of the concepts map easily from Tivoli Security Operations Manager to QRadar. This guide should help to not only transition, but to also learn how to use QRadar to meet business requirements. We suggest using this opportunity to review the current business requirements and upcoming changes to requirements to incorporate them into the conversion from TSOM to QRadar.

This document was written by IBM Software Services for Security (ISSS), and is provided as-is with no warranties expressed nor implied. It is a simple guide, and is not meant to be a replacement for official product documentation. It was published February 15, 2012 using Tivoli Security Operations Manager 4.1.1 FP15 and QRadar 7.0 MR4. Products change and new features are added often, possibly making points in this guide incorrect. Always refer to current product documentation and leverage IBM architects to ensure accurate design.

Overview of the Transition Process

Transitioning from Tivoli Security Operations Manager to QRadar is a multi-step process. It is suggested that this entire guide be read through before starting the process to properly plan out the appropriate path.. There is not an automated or scripted migration or an upgrade, just a series of steps to follow. It requires analysis and understanding of the business requirements, use cases, Tivoli Security Operations Manager configuration, any customizations made to TSOM, and a basic understanding of QRadar features. Then a QRadar deployment can be planned to map business requirements to the new features in QRadar.

The transition from Tivoli Security Operations Manager to QRadar involves the following steps:

1. Understand the Current Business Requirements2. Review Use Cases with TSOM3. Evaluate the TSOM Deployment4. Re-evaluate business requirements5. Map TSOM Concepts to QRadar Concepts

Transitioning from Tivoli Security Operations Manager to QRadar 1

6. Plan a QRadar Deployment

At this point the execution of the transition plan can begin. Through each step of this process, IBM is here to help. Please make use of the Security Intelligence Professional Services group, Qmmunity forums, and the QRadar support help desk. Links to these are in the Appendix.

Note: There is no data migration path from Tivoli Security Operations Manager's database to QRadar. Part of the planning includes a time period to keep Tivoli Security Operations Manager available for historic data requests or searches.

1 Understand the Current Business Requirements

Review the current business requirements for Security Intelligence and SEIM. Compare those to requirements used when TSOM was acquired and implemented. Have the business owners changed? Have the business drivers changed or business unit changed? Are there new requirements (compliance, regulatory, business) that need to addressed? What requirements could not be solved in the past with TSOM? Do other organizations need to be involved? How can QRadar be leveraged?

Before migrating the organization should have been exposed to QRadar, Risk Manager and other components of the Q1 solution. It is useful to have a representative attend a QRadar training to understand the solution as part of the planning process.

Now is the best time to determine staffing and maintenance duties. The majority of QRadar customers have found they can achieve a greater level of visibility into their security posture with current staffing levels or less. Allowing those staff to perform other valuable activities.

Many organizations find adding flow data (netflow, Qflow, etc) is a next step in their evolution towards Security Intelligence.

2 Review Use Cases with TSOM

It is time to evaluate how Tivoli Security Operations Manager is being used to fulfil the business requirements. Before looking at the individual TSOM components, review the following common use cases and see what roles Tivoli Security Operations Manager plays for the


organization. Don't worry if use cases were used, but over time, have moved away from it.

2.1 Security Operations Center Use Case

The most common role for Tivoli Security Operations Manager is as the core workflow tool in a Security Operations Center (SOC). Whether 24/7 or 9-5, this use case describes having security analysts actively reviewing events and investigating security incidents. There might be a senior security analysts writing correlation rules to send alerts to a Network Operations Center (NOC). Tivoli Security Operations Manager is configured with asset information and the statistical correlation engine is tuned to help filter on the most important events. The security analysts might be using the internal ticketing system within Tivoli Security Operations Manager or an external ticketing tool to manage investigations into possible security incidents. They also might be using the Host Investigation Toolkit to quickly determine if security alerts are real or just false positives. The goal in this use case is to detect and quickly respond to security alerts from a variety of security devices.

2.2 On-demand Security Investigations Use Case

Tivoli Security Operations Manager can be configured to send alerts via email or some other means when certain events occur. When an analyst receives this email, they log into Tivoli Security Operations Manager to investigate the event and do any required incident response. If a change is required, a trouble or change ticket is opened in an external ticketing system and routed to the appropriate group.

2.3 Compliance Reporting Use Case

Often the main business driver for installing Tivoli Security Operations Manager is to comply with government or industry regulations that require log management and compliance reports. In this use case, Tivoli Security Operations Manager is configured to classify events according to policy so that reports can be generated based off that classification. The reports are reviewed for policy violations. If any problems need to resolved, a trouble or change ticket is opened in an external ticketing system and routed to the appropriate group.


2.4 Centralized Log Management Use Case

Some customers use Tivoli Security Operations Manager to collect and store logs from a variety of log sources. Occasionally there will be some type of problem detected elsewhere and the IT team will log in to Tivoli Security Operations Manager to research logs generated around the time that the problem surfaced. The problem is worked in an external ticketing system.

3 Evaluating the TSOM Deployment

Once the use cases have been reviewed, the next step is to document the TSOM deployment so that there is an understanding of what will be needed to configure in QRadar. By having an understanding of the Tivoli Security Operations Manager use cases, the following configurations may or may not be relevant.

3.1 Architecture

• How many CMSes are there?• Where are they located?• Is there any HA/DR configuration?• Why are the CMSes located where they are?• How many EAMs are there?• Where are they located?• Are there any custom event sources configured on the EAM?• Why are the EAMs located where they are?• Is there any UCMs deployed?• What server(s) are they deployed on?• What sensors are being collecting?• Which EAM are each of these sensors being collected from?• What is the average EPS count?

3.2 Configuration

• What user roles and groups are configured?• Is external LDAP configured?• Are there any Security Domains configured?• What are the Security Domains used for?• Are there any EAM filters?


• Are there any nonstandard EAM collection ports?• Are there any Firewall Blocking settings?• Are there any SNMP receivers?• What rules are enabled?

◦ Are there any references to Watchlists?◦ Are there any references to (manual or automatic) Netblocks or

Hosts?◦ Are there any references to Event Classes?◦ What actions are there configured?

• Are there any modifications to Netblocks or Hosts to tune the Statistical Correlation engine?

• Are there any non-default Event Class Filters?• Are there any internal or external Knowledge Base articles?• What Host Investigation Tools are configured?• Are there any data imports from a Vulnerability Scanner(s)?• Are there any reports being used?

4 Mapping TSOM Concepts to QRadar Concepts

Experienced practitioners of Tivoli Security Operations Manager should know the terminology and concepts pretty well. There are many concepts that are shared between TSOM and QRadar Mapping concepts is often just learning the new terminology.

4.1 Architecture

We should point out that Tivoli Security Operations Manager is a software-based solution and QRadar is fundamentally an appliance-based solution QRadar is available as software-only or virtual machine options. For the rest of this document, it will be assumed that appliances will be used.

Tivoli Security Operations Manager uses a centralized server (CMS) to do event decoration and correlation. The CMS uses a separate database back-end server, either IBM DB2 or Oracle. The event collection and normalization are distributed out to the EAMs. The smallest configuration for TSOM is three servers: EAM, CMS, and Database Server. To scale the solution, more computing power is added to the CMS and add more EAMs.


For QRadar, there is a centralized Console without requiring a centralized database. In the smallest configuration, QRadar is one appliance called an All-in-One Console. There are several sizes of the All-in-One to fit small, medium, and large customers. These are the 2000, 2100, and the 31xx family of All-in-One Consoles, respectively. Refer to technical specifications for the individual capabilities of these appliances. For enterprise customers the scalability is achieved by adding Event Processors and/or Flow Processors. In the distributed configuration, events can be stored on the Event Processors and flows stored on the Flow Processors. Comparing EAMs to Event Processor, EAM does collection and normalization while an Event Processor does collection, normalization, event decoration, correlation, and data storage. This results in a distributed design that is very scalable. The centralized Console shows a single pane, no matter how many additional Processors are deployed. Correlation can be performed locally on each processor or done globally.


Illustration 1: Typical Enterprise TSOM Deployment

4.2 High Availability

High Availability (HA) is not officially available with Tivoli Security Operations Manager, but because it is a software only solution, HA could be achieved using other tools like Tivoli System Automation or load balancers. The possible scenarios are very numerous, but most customers use two CMS servers and a single database server, one CMS being active while the other CMS is for fail-over. Then a load balancer is configured with a virtual IP address for the EAMs to use as the CMS's IP address. The load balancer checks to see if the active CMS is listening on port 2468. If it detected an extended outage, it will start forwarding traffic to the fail-over CMS. Alternatively, Tivoli Storage Manager could be installed on each EAM and detect the primary CMS failure. External disk synchronization solution is required for the CMS.


Illustration 2: Typical QRadar Distributed Deployment

High Availability for QRadar is built right in to the solution and is very simple to configure. HA is supported for either a Console or a Processor, or both. When an HA pair is configured, the appliances create a virtual IP address. If the primary appliance fails, QRadar automatically switches to the fail-over. The disks are synchronized automatically.


Illustration 3: TSOM High Availability Deployment

4.3 Disaster Recovery

Disaster recovery with Tivoli Security Operations Manager involves backing up and restoring both configuration files on the CMS and data from DB2 or Oracle database server. It is common to request a DBA to setup the database backup procedures. Tivoli Security Operations Manager is unaware of backup and restores. Alternatively, Tivoli Security Operations Manager can be configured like the HA description above, but with a CMS and database pair in separate datacenters. Using the same fail-over and synchronization 3rd party tools, the solution could have near-instant recovery in the case of a datacenter outage.

QRadar supports both standard backups and restores, but does so through the application. QRadar can easily backup configuration information only, or configuration plus event and flow data on a daily basis. These backups can be configured in the QRadar GUI for retention, keeping only 1 day of backups or several. A SAN, NFS, or iSCSI drive can be mounted to allow for immediate off-appliance backups. Then this SAN can be mirror at another datacenter to provide whole datacenter disaster recovery.

4.4 Log Management

In Tivoli Security Operations Manager, the event data, configuration data, and other information like assets and ticketing data is stored on the database server using either DB2 or Oracle. The event data is stored as normalized data along with the original raw log. The CMS will push down configuration data to the EAM, but the EAM does not


Illustration 4: QRadar High Availability Deployment

have any database on it. In QRadar, the event and flow data are stored in a propriety data store called Ariel. It is a file system based “database”, but is not to be confused with a relational database like DB2 or Oracle. The Ariel data store is very efficient in storing and retrieving data without the overhead that is associated with relational databases. The asset, configuration, and other data is stored in a Postgres database. This Postgres database exists primarily on the Console, but is replicated to each appliance in the deployment. External SANs are supported on the appliances to extend storage or for data backup.

Tivoli Security Operations Manager relies on the database to prune the data. The DBA needs to setup a truncate task on the database. There is no option to keep certain data longer, the entire event data table is pruned. With QRadar, the data retention is built into the software and QRadar manages it all with no DBA required. There is also an option within QRadar to have different retention for different data. For example, the solution could keep all data for 30 days, while keeping events from a PCI regulated environment for 1 year.

Collection with Tivoli Security Operations Manager and QRadar is very similar. There is the same preference for real-time, “push” protocols like Syslog and SNMP. Tivoli Security Operations Manager calls it's protocols conduits. To get the “pull” protocols in Tivoli Security Operations Manager, an agent called the Universal Collection Agent (UCM) must be used.

Protocol / Conduit TSOM QRadar

Syslog

SNMP

OPSEC LEA

SDEE

File Tail

Folder Tail

Windows Event Log via Microsoft Log Parser

Windows Event Log via Windows Event Log API

Windows Event Log via Snare (Syslog)


Protocol / Conduit TSOM QRadar

Windows Event Log via WMI/DCOM

Windows Event Log via agent (UCM or ALE)

Tivoli Event Integration Facility

JDBC

EMC Vmware

Estreamer

NSEL

Oracle Database Listener

PCAP

SMB Tail

Netflow

sFlow

J-Flow

Packeteer

Flowlog File

Napatech Interface

Table 1: Protocols available in TSOM and QRadar

The collection process between Tivoli Security Operations Manager and QRadar have another similarity, in that they both rely on regular expression for doing event parsing, and they both allow for modifications to the parsing code. Tivoli Security Operations Manager uses Java and Perl for it's parsing engine. The Java and Perl files are available in clear text on the EAM and are user editable. Writing parsing for a new event in Tivoli Security Operations Manager is fairly simple, given basic knowledge of Java or Perl.

QRadar's parsing code is compiled, but there are several ways to modify parsing. If there is a need to modify the parsing for an existing


sensor (called Device Support Module or DSM in QRadar) a Custom Event Property (extracted property) or a Log Source Extension can be used. If a brand new sensor needs to be created (a.k.a. DSM), a Universal DSM can be created. There is a guide to Log Source Extensions in a document titled Log Sources”. The link to this document is in the Appendix.

4.5 Users, Groups, and Roles

Users in Tivoli Security Operations Manager work in a very similar way in QRadar. The only notable difference is the way users are restricted to which data they can view. All the other features are equivalent in function: users are created once, external LDAP for Active Directory (AD) is supported, and various roles can be assigned, giving different permissions within the tool. QRadar relies on external LDAP, AD or other authentication products for user password policies.

Tivoli Security Operations Manager uses Groups to define any data filtering, and Groups use Security Domains to define what data gets seen by the user. QRadar filters data for the user either by Log Source Group or by Network Hierarchy.

4.6 Security Domains

Security Domains in Tivoli Security Operations Manager are generally used for one of three reasons: to filter content for users, to have a separate rule tree, or to have separate watchlists. The data that is included in a Security Domain is defined using the standard event filter interface, allowing for any field(s) to be used to populate the Security Domain. Most users define Security Domains by using the Netblock field.

The equivalent concept in QRadar is the Network Hierarchy and by using building blocks. Network Hierarchy is used to define IP space that is controlled by the business or organization. These network definitions can be given an asset weight, used to limit the data viewed by Qradar users, and can be used in rules. If you just want to define a network to use in rules, a network can be defines using building blocks.

4.7 Netblocks and Hosts

Tivoli Security Operations Manager not only collects security events, but it also learns about the environment by creating an asset


database. For every new IP and network that Tivoli Security Operations Manager sees, it adds it to an asset database located on the database server. Automatically, Tivoli Security Operations Manager does a special whois to an IBM server to get network ownership and geolocation. Tivoli Security Operations Manager also allows for the import of vulnerability data from a vulnerability scanner.

QRadar takes a very similar, but more targeted approach with learning and building an asset database. Instead of learning every IP address and network that comes across, It only builds asset profiles for the IP range defined in the Network Hierarchy. This allows QRadar to then do a deep profile on the asset. In addition to the data learned from a vulnerability scan import, QRadar can also learn the ports used by compiling flow data and classify asset types from syslog data. This additional data allows for a richer Asset profile. QRadar automatically discovers assets (servers and hosts) operating on your network, based on passive flow data and vulnerability data, to create asset profiles. Asset profiles provide information about each known asset in your network, including what services are running on each asset. Asset profile information is used for correlation purposes to help reduce false positives.

4.8 Sensors

Tivoli Security Operations Manager calls devices, servers, applications, etc. that produce logs: sensors. These sensors are collected via conduits. Sensors can be manually configured, or Tivoli Security Operations Manager's auto configuration can detect the various sensors. The auto configuration works on the Syslog and SNMP conduits. Sensors are updated via “Device Support Updates”, a manual download and installation process (usually once a quarter).

QRadar calls devices, servers, applications, etc. that produce logs: log sources. These log sources are collected via protocols. Log Sources can be manually configured, or let QRadar's auto discovery detect the various log sources. The auto discovery works on the Syslog protocol only. Log sources are updated via the Automatic Update feature and can be automatically installed on a weekly basis.

Here is special bonus for users of Tivoli Security Operations Manager 3.1: there used to be a useful feature called “silent sensor alarm” that would send an email if a sensor stopped sending data. This feature is available in QRadar in the Rules engine called “Inactive Log Sources”.


4.9 Firewall Blocking

Tivoli Security Operations Manager has a feature that can send a firewall rule change via OPSEC. This is for Checkpoint Firewalls only. This firewall rule change can be triggered manually or in the Stateful Rules.

QRadar has a similar concept, but the capabilities are a bit expanded with two supported protocols. Trusted Network Computing (TNC) recommendations allow QRadar to restrict or deny network access to users based on username or other credentials. The TNC recommendation uses the asset profile and user identify data collected by QRadar. The Interface for Metadata Access Points (IF-MAP) is an open standard client/server protocol. IF-MAP provides a common interface between the Metadata Access Point (MAP), in this case QRadar, and other elements of the TNC architecture. The IF-MAP protocol defines a publish/subscribe/search mechanism with a set of identifiers and data types.

4.10 Event Types and Classes

Events in Tivoli Security Operations Manager gets parsed, and from that parsing, one of the fields is labeled as the “Event Type”. Some places in Tivoli Security Operations Manager, Event Type is also called Event Name. The Event Type is a string from the original event, like a signature name or the an event ID code. Then the event gets assigned one or more Event Classes. Event Classes help categorize events using a hierarchical schema. Event Classes can be assigned in one of two ways: by mapping an Event Type to one or more Event Classes or using Event Class filters. Event Classes are manually created. There are some starter Event Classes and Event Type mappings that can be imported using the default security content for Tivoli Security Operations Manager. Any new Event Types or Event Classes have to be manually mapped.

Events in QRadar get parsed, and from that parsing, one of the fields is used to map the event to a QID (pronounced Q-eye-dee). QRadar has a table of all supported event types and they each have a QID. This QID has a readable event name, low level category, and high level category. These categories act in a similar way to Tivoli Security Operations Manager's Event Classes, even the hierarchical nature of the high and low level categories. These mappings are done by IBM and delivered weekly to QRadar via the Automatic Update feature.


4.11 Rules and Actions

Both Tivoli Security Operations Manager and QRadar have powerful correlation engines. Tivoli Security Operations Manager calls its correlation engine Stateful Rules. Tivoli Security Operations Manager has the following rule conditions:

• Simple Condition: This rule test looks at a single field by selecting a field, selecting a comparison operator, and inputting a value.

• Host Query Condition: This rule queries the asset database and looks for specific vulnerabilities or vulnerable ports.

• Simple State Condition: This rule looks for an event with the same field value to happen X amount over Y amount of time.

• Complex State Condition: This rule looks for a series of events by storing fields into a state table.

The actions that Tivoli Security Operations Manager can perform are:

• Open a internal TSOM ticket• Send an e-mail• Send an SNMP trap• Add or remove a host from a watchlist• Fire a script• Add a firewall rule via OPSEC

QRadar calls its correlation engine Rules, found on the Offense tab. QRadar has the follow event rule test. Note that QRadar can also flow rule tests, common rule tests (both events and flows), offense rule tests, and anomaly detection rule tests.

• Host Profile Tests: Queries the asset database for things like ports, host profile existence, profile age, port age, asset weight, and vulnerability information.

• IP/Port Tests: Test for source or destination IPs or ports.• Event Property Tests: Test for several event properties like

network, protocol, QID, event context, category, severity, credibility, relevance, location (internal vs external), rate analysis, false positive, username, IPv6, reference set, and search filters. There is even an option for searching the whole event.

• Common Property Tests: Test for several common properties like CVSS risk (host), CVSS risk (port), and the ability to search any property for any value.


• Log Source Tests: Test log source properties like which log source or log source group an event came from, the log source type, and testing for inactive log sources.

• Function - Sequence Tests: These tests perform similarly to the Complex State Condition in TSOM, but can also be used to sequence other rules.

• Function - Counter Tests: These test are like the Simple State Condition, but can also be used to count other rules.

• Function - Simple Tests: These rules test if an event has been matched to one or more other rules.

• Date/Time Tests: Does comparisons for date and time ranges• Network Property Tests: Test the network location of an IP in

Network Hierarchy or Remote Networks.• Function - Negative Tests: After so many minutes, if an event

doesn't match a rule, then fire an response.

QRadar calls the action taken, if a rule test is successful, a Rule Response. Here are the Rule Responses in QRadar:

• Creating an offense. • Sending an email.• Generating system notifications using the Dashboard feature.• Creating or adding data to reference sets.• Send a message to Syslog• Forward the event to a forwarding destination• Send an SNMP trap• Send IF-MAP datacenter• Create a new event

4.12 Watchlists

Watchlists are used in Tivoli Security Operations Manager to group assets when the group cannot be described as a Netblock. These Watchlists are basically flags on hosts and/or netblock. The flags could be anything from device type, OS version, related to a regulation, part of a bad list of IP, etc. Watchlists are used to filter data in the Powergrid or can be used in a Stateful Rule. A host or netblock could be added or removed to a watchlist manually or as part of a Stateful Rule action.

QRadar's equivalent concept is Reference Sets. However, Reference Sets are not for assets only. A Reference Set can be created for any field in QRadar like username, ports, event names, etc. Reference


Sets can be used in rules. Reference Sets can be created manually, or be populated in a rule response.

4.13 Statistical Correlation

Along with Tivoli Security Operations Manager's stateful rule correlation engine, there also is a statistical correlation engine. This engine reviews events coming in and calculates an atomic threat score. The algorithm took in several values including source netblock weight, source host weight, event priority, destination netblock weight, destination host weight, and a sliding window to computer compound threats. The atomic threat score is attached to every event, plus there is also a transitory top source and top destination table stored in memory to show real-time attacks.

QRadar also has an atomic threat score called Magnitude. It's calculated from:

• Credibility: How credible is the evidence. Credibility of the device, if multiple devices report same attack, credibility of overall offenses in increased.

• Relevance: Based on the weight of Networks and Assets, how relevant is this offense or violation to the organization? Is it occurring in areas of the network that are not as important or to hosts that do not exist?

• Severity: How much damage can occur. A firewall deny is a lot less severe than a DoS attack.

4.14 Host Investigation Toolkit

Tivoli Security Operations Manager enables security analysts to integrate their own investigative tools into the GUI. Tools like netcat and nmap can be used in the Host Investigation Toolkit (HIT) windows.

QRadar allows the same functionality, but with no cool acronym. When a security analyst right clicks an IP address in QRadar, a menu pops up with several options. Out of the box, QRadar allows for a DNS lookup, Whois lookup, and a port scan via nmap (which comes installed on the appliance). The right click menu can be extended to give the same functionality as the HIT window in TSOM.


4.15 Vulnerability Import

Tivoli Security Operations Manager and QRadar both allow the import of vulnerabilities scanner data. QRadar has this support right in the GUI, while access to the Tivoli Security Operations Manager VulnScanner import is via command line interface only. QRadar also has an expanded set of scanners supported.

4.16 Ticketing and Workflow

Tivoli Security Operations Manager provides an internal ticking system that allows for analysts to track security incidents, record notes about investigations, transfer tickets to other analysts, flag tickets, and close tickets. If a ticket is created because of a rule, Tivoli Security Operations Manager will continue to attach events until the incident is solved.

QRadar provides very similar functionality, but uses the term Offense instead of ticket. Offenses are used to track security incidents and record notes about investigations, plus analysts can transfer an offense to other analyst, flag an offense, and close an offense. If an offense is created because of a rule, QRadar will continue to attach events until the incident is solved.

4.17 Terminology

Please refer to the following translation guide to understand the difference in terms used in Tivoli Security Operations Manager and QRadar

Tivoli Security Operations Manager

QRadar

Action (rules) Response

Audit (internal audit) Audit

Atomic Threat Score Magnitude

Auto Configuration (EAM) Auto Discovery

Central Management Server (CMS) Console

Condition (rules) Condition

Conduit Protocol

Correlation Engine Magistrate



QRadar

Device Rules Device Support Module

Event Aggregation Module Event Processor and Event Collector

Event Class Category (low level and high level)

Event Console No term, but its the default view once click on the Log Activity Tab

Event Element (rules) Event Property

Event Filter (EAM) Routing Rule

Event Filter (Powergrid, Event Viewer)

Search, Saved Search

Event Filter (Event Class) Classification is handle automatically

Event Filter (Rules) Rule Test

Event Rate Events per Second (EPS)

Event Severity Severity

Event Type Event Name

Firewall Blocking (OPSEC) Trusted Networking Computing (TNC) and Interface For Metadata Access Points (IF-MAP)

Geoserver Geographic Networks

Group (user) No equivalent

Host Asset

Host Asset Weight Asset Weight

Host Criticality Weight Asset Weight

Host Investigation Tool Right Click Menu

Host Query (rule condition) Host Profile Tests

Keystore No equivalent, automatically managed

Knowledge Base Offense Notes

Location Location

Master Netblock No equivalent

Meta-event Dispatch New Event



QRadar

Netblock Network (Network Hierarchy or Remote Network)

Netblock Asset Weight Network Weight

Netblock Source Threat Network Weight

Password Policy No equivalent

Powergrid No term, but look at events in the Log Activity tab. Group log data using the Display list box. The log data view operates similar to the Powergrid now.

Reports Reports

Role (user) Role

Security Content (import script) Content comes preloaded and is updated via Automatic Update.

Security Domain Network Hierarchy

Sensor Log Source

Sensor Class Log Source Group

Sensor Type Log Source Type

Simple Condition (rule) Rule Test

State Action (complex state) Handled automatically when a Function Test is created

State Condition (complex) Function – Sequence Test

State Condition (simple) Function – Counter Test

State Table Handled automatically when a Function Test is created

Stateful Action Handled automatically when a Function Test is created

Stateful Rules Rules

System Configuration System Configuration

System Status System Monitoring Dashboard

Threat Correlation (statistical correlation)

No term, but the Magnitude is calculated in a similar manner as the Threat Score.

Threat Parameter No Equivalent – Handled automatically



QRadar

Ticket Offense

Token No Equivalent

Top Sources and Top Destinations Can be viewed in the Log Activity tab

Universal Collection Agent Adaptive Log Exporter and tail2syslog script

User Account User Account

Vulnerability Vulnerability

Vulnerability Import Vulnerability Assessment

Watchlist Reference Set

5 Planning a QRadar Deployment

Now that Tivoli Security Operations Manager has been reviewed and concepts have been considered, it is time to plan your QRadar deployment. Here are the steps to a successful QRadar Deployment:

1. Design the QRadar Architecture2. Install appliances3. Reuse the EAM IPs or reconfigure endpoints4. Do Initial Configuration5. Convert business logic from TSOM to QRadar6. Keep TSOM online for a period of time for historical queries

5.1 Design the QRadar Architecture

The first steps will be designing the architecture. There are many ways to architect QRadar. This guide will only touch on the standard deployments. Please review current QRadar options with your sales team and/or solution architect.

To understand the architectural options in QRadar, here is brief rundown of available appliances. EPS stands for Events Per Second. FPM stands for Flows Per Minute and applies to all supported Netflow versions including CFlow, JFlow, SFlow, VFlow, QFlow, and others. QFlow and VFlow are QRadar components that listen to a packet stream via a span, mirror, or tap and produces a Netflow-like stream


with the added bonus of protocol analysis. QFlow is measured in Mbps (Mega-bits per second) or Gbps (Giga-bits per second).

Appliance Model

Use

2000 All-in-One Console

Very Small Business All-in-One Console – Only 200 EPS and 15,000 FPM, 50 Mbps for QFlow, 200 log sources

2100All-in-One Console

Small to Medium sized business All-in-One Console – 1000 EPS, 50,000 FPM, 50 Mbps for QFlow, 750 log sources. You can add QFlow collectors to a 2100, but not any event or flow processors

31xxAll-in-One Console

or Enterprise Console

QRadar's standard All-in-One Console - 5000 EPS, 200,000 Flows, and 750 log sources. It does not have any embedded QFlow collectors like the 2000 and 2100. This appliance is also used with enterprise deployments. There are several versions of this appliance that has incrementally more capacity for more storage and/or concurrent users.

16xx Event

Processor

The 16xx series are expansion appliances that are deployed in conjunction with the 31xx. The 16xx series offers real-time collection, prioritization and correlation of event data and can scale to more than 10,000 events per second in the 1601 model, or 20,000 EPS in the higher models (1605, 1624, etc). There are several versions of this appliance that has incrementally more capacity for more storage and/or concurrent users.

17xx Flow Processor

Whether extracting native flow information from the network infrastructure, or working in tandem with QFlow collectors, QRadar flow processors enable the collection, analysis and storage of a variety of flow formats including Netflow, CFlow, JFlow, SFlow, VFlow and QFlow. The 17xx is an expansion appliance that is deployed in conjunction with the 31xx. There are several versions of this appliance that has incrementally more capacity for more storage and/or concurrent users.

18xxCombined

Event & Flow Processor

The 18xx series appliances are well suited for organizations looking to provide event and network activity monitoring and processing for remote or branch offices or to larger highly distributed organizations. Tops out at 1000 EPS and 50,000


Appliance Model

Use

FPM.

11xx, 12xx, & 13xx

QFlow Collector

These QFlow Collectors can be added to a 2100 or 3100. These devices perform content capture (selective partial packet capture) to produce QFlow data for a QRadar SIEM console or all-in-one appliance. There a number of appliance models that have various interfaces and capacities.

Table 2: QRadar Appliances

The easiest way to transition from Tivoli Security Operations Manager to QRadar is to replace the CMS with a 3100 and the EAMs with 1801s. This will give the same capacity you had before with the added bonus of collected Netflows. It is suggested to have at least one QFlow appliance to capture data going across the internet facing interface. For every interface you have a network intrusion detection/prevention device(s), you should also span that data to a QFlow appliance.

To get an effective sizing from IBM Security Solutions sales engineer or services, the following information is useful. This will allow IBM to get you an accurate sizing.

• Measured or estimated Events per Second• Measured or estimated Flows per Minute• Connect bandwidth to remote datacenters or sites • Will any of these remote sites be over a WAN link?• Is encryption between QRadar appliances required?• What version and type of netflow (Netflow vs JFlow, etc.)?• Utilization of the interfaces to be used with QFlow.• A list of devices that will be log sources• Data retention requirements.

Considering the power of QRadar, a smaller implementation might be preferable and will allow for some cost savings. A 2000, 2100, and 3100 appliance may be enough to meet requirements. The caution is the upgrade path of the 2000 and 2100. If you undersize a 2000, the upgrade requires replacing the appliance with a larger device. Other appliances allow for adding devices or additional licenses. These All-in-One consoles all the same application features, just with a smaller scope. If you don't need all the features of a full SIEM, then consider the QRadar Log Manager. A nice feature of QRadar is Log Manager


can be upgraded to SEIM with a simple license change. Below is a breakdown of the application features you would get with each software version.

Software Feature Log Manager

QRadar

Manages network and security events

Manages host and application logs

Tamper-proof data archive

Threshold-based correlation and alerts

Compliance reporting templates

Managing flows for full Network Behavior Analysis

Asset Profile Creation and Management

Work flow and remediation

Offense management

Integrated network, security, application and identity visibility

Table 3: Software features of Log Manager vs. QRadar

If High Availability (HA) is a requirement, or even a nice to have feature, consider the HA option with the appliances. With real-time UDP protocols like syslog and SNMP, if an event collector is down, events are being lost. Any of the appliance listed above can have an HA pair. HA is very easy to setup because it's built right into the application.

5.2 Install appliances

After receiving the new appliances, there are few things needed to get them installed. In the appliance box, there is a plastic envelope with the activation key and a CD with the installation manuals. The easiest way to get the appliance initially installed is to hook up a monitor and


USB keyboard to the appliance. To get through initial installation process, have the following ready:

• IP Address of the appliance• Subnet mask• Gateway IP• Fully qualified domain name• DNS server(s)• NTP server (needed for the console only)• SMTP Server• Time Zone• Activation Key

Follow the installation guide on the CDROM for detailed instructions.

5.3 Reuse the EAM IPs or reconfigure endpoints

When selecting an IP address for your event processors, consider reusing the EAM's IP address(es). This will require some coordination to achieve, but will save time since endpoints will not have to be reconfigured. To do this, have the console configured and online first. Then configure your event processor with the network cable unhooked. Finally unplug the EAM and plug in the event processor. On the event console, start the deployment manager and add the event processor. Save and deploy. You should have very minimal downtime.

If this cannot be achieved, the endpoint will need to be configured to point its logs to the new server. This can also be achieved with little to no downtime, but may be a large chunk of work if you have a lot of endpoints. Most devices and servers can have multiple syslog destinations. Just add the new event processor or console IP address in addition to the EAM.

With either scenario, some endpoints will need to be manually reconfigured in the new solution.

5.4 Do Initial Configuration

To get the solution up and running, some initial configuration steps must be taken. Please review the QRadar Administration Guide and the Tuning Guide for details on these steps.


1. Obtain an account for Qmmunity.Q1Labs.com This is provided for new customers and Q1 dedicated resources.

2. If there is more than one appliance, use the Deployment Manager to add the managed hosts.

3. Configure HA, if required.4. Patch your appliances to the newest patch level (downloadable

from Qmmunity).5. Update DSMs, Protocols, and VA Scanners (downloadable from

Qmmunity).6. Create your Network Hierarchy based on the Security Domains and

Netblocks from Tivoli Security Operations Manager.7. Configure any VA Scanners

5.5 Convert business logic from TSOM to QRadar

Now it is time to move the business logic. These are all the things that were written down in Chapter 2. Here is a good check list to make sure everything gets transitioned over to QRadar.

• Ensure all sensors are now log sources in QRadar. Review the Configuring DSM Guide to get the details.

• EAM filters can be setup as Rules.• Watchlists can be setup as Reference Sets.• Create User Roles first, then create Users.• Add external Netblocks to the Remote Networks.• Import Assets• Review the “Customizing the Right Click Menu” technote in

Qmmunity to transition any HIT scripts or URLs• Convert rules

This last step will require some thought about the original goal of the rule. Copying conditions to rules tests may not be the best way to accomplish the same task. Review the QRadar Users Guide to review the full capabilities of the QRadar rule engine. To get additional help designing rules, there is QRadar support, Security Intelligence professional services, and the Qmmunity Forums.

5.5.1 Example

Tivoli Security Operations Manager currently has a rule that detects any type of scan (ping sweep, port scan, etc) from the internet and places that IP on a watchlist. Then if that IP launched any type of an attack, create a ticket called “Compound Attack”. Also, create a Meta-Event to track this correlation.


The Tivoli Security Operations Manager rule would look like this:

• IF Source Netblock = External◦ AND Event Class = attack.recon.scan

▪ Add Source IP to Watchlist “Internet Scanners”• IF Event Class = attack

◦ AND Source Watchlist = “Internet Scanners”▪ Create Ticket “Compound Attack”

• Create Meta-Event “Compound Attack”

To accomplish this in QRadar, two rules can be created that do the same thing. There are some built in building blocks that can be used.

• “Internet Scanner” COMMON Rule ◦ Rule Tests:

▪ When the Source IP is a part of any of the following remote network locations “Internet”

▪ AND when a flow or an event matches all of the following rules: “BB:CategoryDefinition: Recon Events”

◦ Rules Response:▪ Add the Source IP of the detected event/flow to the

following Reference Set: “Internet Scanners (IP)”• “Compound Attack” COMMON RULE

◦ Rule Tests:▪ When a flow or an event matches all of the following rules:

“BB:CategoryDefinition: Suspicious Events”▪ When all of Source IPs are contained in all of these

reference set(s): “Internet Scanners (IP)”◦ Rule Responses:

▪ Ensure the detected event is part of an offense. Index offense based on IP. Include detected events by Source IP from this point forward, for 3600 second(s), in the offense.

▪ Dispatch New Event “Compound Attack – Scan then attack”

5.6 Keep TSOM online for a period of time for historical queries

Finally, Tivoli Security Operations Manager will need to be kept online for reference and historic data queries. The time period depends on the overall data retention policy and any external compliance concerns. Having TSOM available will also allow for confirmation of the total migration process.


Optionally, QRadar can be configured to send data to an EAM to test different aspects of the transition process from Tivoli Security Operations Manager. See the chapter titled, “Forwarding Event Data” in the QRadar Administrator Guide.


Appendix

h ttps://qmmunity.q1labs.com

Qmmunity has customer forums, product documentation, access to open support tickets, and much more.

https://qmmunity.q1labs.com/node/1273

The Log Sources Users Guide provides you with information for configuring log sources in the QRadar interface and integrating DSMs with QRadar.

https://qmmunity.q1labs.com/self-serve

Access to open a trouble ticket with QRadar support.

http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.netcool_som.doc/welcome.htm

Tivoli Security Operations Manager documentation.

http://www.ibm.com /software/support

Access to open a trouble ticket with TSOM support.

[email protected]

Contact IBM Security Intelligence Services.


mailto:[email protected]

http://www.ibm.com/software/support

http://www.ibm.com/software/support



https://qmmunity.q1labs.com/self-serve

https://qmmunity.q1labs.com/node/1273

http://qmmunity.q1labs.com/

http://qmmunity.q1labs.com/

transitioning from tivoli security operations manager · pdf filetransitioning from tivoli...

Documents