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
Transitioning from Tivoli Security Operations Manager to QRadar 2
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.
Transitioning from Tivoli Security Operations Manager to QRadar 3
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?
Transitioning from Tivoli Security Operations Manager to QRadar 4
• 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.
Transitioning from Tivoli Security Operations Manager to QRadar 5
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.
Transitioning from Tivoli Security Operations Manager to QRadar 6
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.
Transitioning from Tivoli Security Operations Manager to QRadar 7
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.
Transitioning from Tivoli Security Operations Manager to QRadar 8
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
Transitioning from Tivoli Security Operations Manager to QRadar 9
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)
Transitioning from Tivoli Security Operations Manager to QRadar 10
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
Transitioning from Tivoli Security Operations Manager to QRadar 11
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
Transitioning from Tivoli Security Operations Manager to QRadar 12
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”.
Transitioning from Tivoli Security Operations Manager to QRadar 13
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.
Transitioning from Tivoli Security Operations Manager to QRadar 14
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.
Transitioning from Tivoli Security Operations Manager to QRadar 15
• 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
Transitioning from Tivoli Security Operations Manager to QRadar 16
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.
Transitioning from Tivoli Security Operations Manager to QRadar 17
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
Transitioning from Tivoli Security Operations Manager to QRadar 18
Tivoli Security Operations Manager
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
Transitioning from Tivoli Security Operations Manager to QRadar 19
Tivoli Security Operations Manager
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
Transitioning from Tivoli Security Operations Manager to QRadar 20
Tivoli Security Operations Manager
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
Transitioning from Tivoli Security Operations Manager to QRadar 21
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
Transitioning from Tivoli Security Operations Manager to QRadar 22
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
Transitioning from Tivoli Security Operations Manager to QRadar 23
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
Transitioning from Tivoli Security Operations Manager to QRadar 24
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.
Transitioning from Tivoli Security Operations Manager to QRadar 25
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.
Transitioning from Tivoli Security Operations Manager to QRadar 26
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.
Transitioning from Tivoli Security Operations Manager to QRadar 27
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.
Transitioning from Tivoli Security Operations Manager to QRadar 28
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.
Contact IBM Security Intelligence Services.
Transitioning from Tivoli Security Operations Manager to QRadar 29
Top Related