QRadar SIEM 7.2 Flows Overview

(1)

QRadar SIEM 7.2 Flows Overview

Panelists

• Dwight Spencer – Principal Solutions Architect & Co-founder of Q1 Labs • Aaron Breen – QRadar World-wide Support Leader

• Adam Frank – Principal Solutions Architect • Dale Beresford – Support Services Team Lead • Jonathan Pechta – Support Technical Writer

Reminder: You must dial-in to the phone conference to listen to the panelists. The web cast does not include audio.

• USA: 866-803-2145 • Canada: 866-845-8496

• Participant passcode: 9348947

(2)

Goal: Provide insight on the QRadar

components responsible for flow collection.

(3)

Types of flow data

QRadar can collect several types of flow data: QFlow, NetFlow,

SFlow, JFlow, and Packeteer.

We differentiate these into two categories:

• Internal flows: packet based collection (QFlow or Packeteer)

• External flows: sources from routers or switches that generate their

own session statistics (NetFlow, SFlow, and JFlow)

Data available by flow type:

• QFlow or Packeteer – layer 7 visibility, provides details on application

communication, URLs, etc.

(4)

Placement of devices for flow collection

1. Where do you require visibility?

If you are to consider the “perimeter” of

the network, where a corporate entity

connects to the public internet as the most

volatile location, then this is where most

users will put the most granular data

collection type, which is a packet based

collection solution.

2. Available hardware &

capabilities

Most

volatile

(5)

The Event Correlation Service (ECS)

The QFlow component is responsible

for reading different types of flow data

and creates flow records to be

processed.

ECS is the core service responsible

for event and flow collection for

QRadar.

ECS is comprised of three core

components:

• Event Collector component

• Event Processor component

• Magistrate component (Console only

)

QFlow process

End

ECS

End

3. Magistrate

1. Event Collector

2. Event Processor

The Event Correlation Service (ECS)

End

Start

Flow data

(6)

The Event Collector component completes a

number of flow processing functions for ECS.

• Flow deduplication: Flow deduplication is a process that

removes duplicate flows when multiple QFlow collectors are providing data to flow processor appliances.

• Asymetric recombination

:

Responsible for combining two sides

of each flow when data is provided asymmetrically. This process can recognize flows from each side and combine them in to one record. However, sometimes both sides of the data do not exist.

 External flow sources such as NetFlow that may only report ingress or egress traffic.

 Instances where span traffic enters a network from a single point, and exists via another, creating asymmetric reporting of data to flow

collectors.

Event Collector

Flow deduplication

Asymetric recombination

Throttle

What is an Event Collector component?

Forwarding

• Throttle: Monitors the number of incoming events & flows to the system to manage input queues and licensing.

• Forwarding: Applies routing rules for the system, such as sending data to offsite targets, external Syslog systems, JSON systems, other SIEMs, etc.

Flow deduplication

Asymetric recombination

Throttle

Flow deduplication

(7)

What is an Event Processor component?

• Custom Rules Engine (CRE): The Custom Rules Engine (CRE) is responsible for processing events received by QRadar and comparing them against defined rules, keeping track of systems involved in incidents over time, generating notifications to users and generating offenses.

• Host profiler: Responsible for resolving asset information from passive flow data. Flows provide detailed information about network activity and allow QRadar to build a passive database on assets, ports, protocols, direction, applications, number of packets, bytes transferred, and even an index of the source and destination payload.

• Streaming: Responsible for sending real-time event data to the Console when a user is viewing events from the Log Activity tab with Real time (streaming). Streamed events are not

provided from the database.

• Event storage (Ariel): A time series database for events and flows where data is stored on a minute by minute basis. Data is stored where the event is processed.

Event Processor

Streaming Host profiler

Custom Rules Engine

(8)

What is the Magistrate component?

The Magistrate Processing Core (MPC) is responsible for correlating

offenses with event notifications from multiple Event Processor (EP)

components. Only the Console will have a Magistrate component.

Layers

• Offense rules:

Monitors and takes actions on

offenses, such as generating email notifications.

• Offense management:

Updates active offenses,

transitioning inactive offenses to active and

provides access to offense information to the

user through the Offenses tab.

• Offense storage: Writes offense data to a Postgres database.

What is the Magistrate (MPC) component?

Magistrate

Offense rules Offense management

(9)

ECS, the big picture

End

Start

Remember:

• ECS runs on any

appliance that processes

events, such as 16xx,

17xx, and 18xx

appliances.

• This means that ECS

is running

simultaneously on a

number of appliances in

a multi-system

deployment. Each ECS

is taking in events,

processing them,

evaluating rules, etc.

Magistrate

Offense rules Offense management Offense storage

Event Collector

Protocol Throttle Parsing, traffic analysis, and auto detection

Coalescing Forwarding

Event Processor

Host profiler Custom Rules Engine

Streaming Storage

Flow deduplication

(10)

Types of flow records

• Standard flow: A single standard flow record

• Type A Superflow (Network scans): One source to many destination IPs

This is a unidirectional flow, which has the same source, but multiple destinations.

• Type B Superflow (DDoS): Multiple sources to a single destination IP

This is a unidirectional flow, which has the multiple sources, but has a single destination.

• Type C Superflow (Port scans): One-to-one source and destination with

many ports

This is a one-to-one flow with different source or destination ports

• Over Flow record: Created when license limits are exceeded

• Flow bundle subflow record: Legacy – no longer used

(11)

The first questions addressed by the panelists will be these that were asked in

advance in the QRadar Customer forum.

Advanced questions: part 1

Q1: How can I achieve application layer visibility using QRadar All-in-one

appliance? Do I need to connect SPAN port to a NIC which is used by QFlow

collector?

Q2: How will encryption be dealt with here (I mean whether we need any SSL

termination proxy or not )?

Q3: How can Layer-7 analysis be made possible in case of VFlow collectors

since we don't have any SSL termination mechanism in virtual

environments?

(12)

Advanced questions: part 2

Q6: How does QFlow differentiate between applications that are using the

same port? (For example, port 443 being used by Facebook and LinkedIn)

How is an IRC running on port 80 or 443 identified?

Q7: Feeding un-encrypted data to QFlow puts limitations on me as my

(13)

Now is your opportunity to ask questions of our

panelists.

Questions for the panel?

To ask a question after this presentation:

If you were unable to attend this webcast or have questions later, we have

set aside a forum post specifically for this webcast. See the

IBM Security

Intelligence QRadar Forum.

To ask a question now:

1. Type your question into the chat window.

2. When prompted by the operator, you can press

*1

to ask a question

(14)

Where do I get more information?

Questions on this or other topics can be directed to the QRadar forums:

IBM Security Intelligence QRadar Forum.

ibm.com/security

only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any