InfoSphere™ Optim™ & Guardium® Technology Ecosystem

InfoSphere™ Guardium® Technical Training

Guardium Architecture

Information Management

© 2011 IBM Corporation

Information Management

Agenda

 Introduction
 Database Activity Monitoring Options
 S-TAP Architecture
 CAS Architecture
 Collector Architecture
 Aggregator and Central Manager
 Implementation Options
 Failover and Load Balancing

2 © 2011 IBM Corporation

Information Management

Infrastructure

Local
Access Guardium
Collector

Data Servers Application Servers

Network
Switch
Network
Access
Internet
Client

3 © 2011 IBM Corporation

Information Management

Database Activity Monitoring

 Database activity needs to be captured to perform parsing, analysis, and auditing

– Session information
– Failed log-in attempts
– SQL commands
– SQL errors
– Returned data
 Mechanisms in which the database is accessed
– Network access
– Local access
– Encrypted connection
 Monitoring options
– Port Mirroring
– Network Tap
– Software Tap

4 © 2011 IBM Corporation

Information Management

Port Mirroring

Copy of network packets observed on the switch port

connected to the data server is sent to the Collector
■ No impact on data server performance
Mirrored Guardium
■ Requires network switch with port mirroring: Database Collector
Traffic
– Switched Port Analyzer (SPAN)
– Roving Analysis Port (RAP) Collector
Access
■ Requires direct connection to the Collector
■ Existing switch may not be able to accommodate multiple
data servers connected to that switch Network
Switch
■ Added cost of network switch with port mirroring feature
■ Encrypted and local connections will not be monitored Database
Traffic

Only recommended if network hardware already exists and

data server cannot handle any additional software load
Data Server

5 © 2011 IBM Corporation

Information Management

Network Tap

Dedicated network tap hardware sends copy of data

server traffic is to Collector (similar to port mirroring)
 No dependency on existing network hardware
Guardium
 No impact on data server performance Mirrored Collector
Database
 Added cost of network tap for each data server Traffic
Collector
 Requires direct connection to the Collector Access
 Data server has to be taken offline for installation
 Encrypted and local connections will not be monitored Network
Switch
Only recommended if data server has a high load and
Network
cannot handle any additional software load Tap

Database
Traffic
Data Server

6 © 2011 IBM Corporation

Information Management

Software Tap (S-TAP)

Host-based DBMS-independent software agent that sends

network and local database activities to Collector
 Monitors all database activities at Operating System level:
Collector Guardium – TCP, Shared Memory, Named Pipes, Bequeath
Access Collector
+
 Handles encrypted traffic:
Mirrored – SSH/IPSEC, Oracle ASO, SQL Server SSL
Database
Traffic  Does not require any changes to database environment
 Installed only once on every system regardless of how many
database instances and types are running on that system
Database Network
Traffic Switch  No additional hardware cost and lower implementation cost
+
Mirrored  Specific traffic can be filtered such that not all traffic is sent
Database to the Collector. This reduces network load significantly.
Traffic
(filtered)  Less than 5% performance impact on data server
S-TAP
Data Server S-TAP is the recommended database activity monitoring option

7 © 2011 IBM Corporation

Information Management

S-TAP Architecture

K-TAP (Kernel Tap) Data Server

 Kernel module that hooks into Application/User Level
client/server communication
 Monitors DBMS network port
Local
 Different module for varying Application/User
versions of Linux/Unix kernel

A-TAP (Application Tap)

 Monitors communication at the S-TAP DBMS
application level
➔ DB2, Informix, Oracle ASO
K-TAP A-TAP
 Dependent on K-TAP

Shared Memory
Collector
Network
Layer
Kernel Level
Network Application/User
8 © 2011 IBM Corporation
Information Management

CAS Architecture
Data Server

Application/User Level

Local
CAS (Change Audit System) Application/User

 Java module that monitors for

changes in baseline config: Config File
CAS
 Environment variables

 Configuration files

 Script outputs
S-TAP
DBMS
 Optional component
 Requires Java Virtual Machine K-TAP A-TAP
 Does not require S-TAP

Shared Memory

Network Layer

Collector Kernel Level

9 © 2011 IBM Corporation
Information Management

Collector – G2000 Appliance

Hardware Specification Collector – G2000

– Form factor: 1U rack server
– Processor: 2x quad core
– Storage: 2x 300GB - RAID-1

Network Configuration
– Gigabit network adapter with 4 network interfaces
– eth0 port: Management port and S-TAP communication
– other ports: Monitoring port for N-TAP/SPAN connection
– Network adaptor expansion option for additional N-TAP/SPAN

Software Configuration
– Kernel: Hardened Linux kernel (limited command line access)
– Storage: Relational database (not directly accessible to users)
– Option available to log to flat files stored on the Collector
– Interface: Secure web server providing graphical web interface

10 © 2011 IBM Corporation

Information Management

Collector Architecture

 Collector receives raw database activity data from S-TAP

 Database activity data is parsed and evaluated on the Collector
 Inspection Engine applies action based on installed Security Policy
 Logging stored in normalized relational database
 Alerts sent based on notification configuration
 Control signal sent to S-TAP for filtering control and termination actions

Alert
Security Policy
Inventory Data → Log SQL Construct
Log
Sales Data → Log Full SQL Collector
Data
Server Terminate Sensitive Data → Alert Database
Unknown User → Terminate
LOGIN USER ...
S-TAP SELECT... FROM ...
CREATE TABLE …
INSERT …
DELETE ....

11 © 2011 IBM Corporation

Information Management

Collector Sizing

Number of Monitored Data

Auditing Mode
Server Processor Cores*
Comprehensive 80 (20 Quad-Core CPUs)
Sensitive Object 160 (40 Quad-Core CPUs)
Privileged User (Windows) 160 (40 Quad-Core CPUs)
Privileged User (Unix) 240 (60 Quad-Core CPUs)

*Notes:
 Based on Intel Xeon (pre-Nehalem architecture) or AMD Opteron processors.
 These are simply guidelines. Sizing is dependent on database user activity,
specific security policy rules and actions, and data server load.

12 © 2011 IBM Corporation

Information Management

Managed Environment

Collector

Collector

Aggregator &
Central Manager

Collector
Collector

Remote
Locations
13 © 2011 IBM Corporation
Information Management

Central Manager and Aggregator – G5000 Appliance

Aggregator - G5000
■ Appliance dedicated to serve as central repository of audit
data from multiple Collectors

■ Similar hardware and software configuration as Collector

■ Collectors send data to Aggregator on a scheduled basis

■ Centralized repository allows for enterprise wide auditing

■ Querying for reports is performed on Aggregator, which

relieves Collectors from the performance impact of running
complex reports

■ Aggregator allows Collectors to be dedicated to monitoring

and policy enforcement tasks

■ Aggregator is highly recommended for environments with two or more Collectors

14 © 2011 IBM Corporation

Information Management

Central Manager Functionality

 Centralized Management:
– Status of managed Collectors and Aggregators
– Detailed enterprise S-TAP view
– Central patch management
– Centralized policy management
Unified security policy pushed out to all managed Collectors
– Centralized users/roles/permissions and groups management
– Centralized report definition and audit process definition
– Ability to query managed Collector's data from Central Manager
This is not applicable to managed Aggregator units

■ Implementation scenarios:
– Dedicated Aggregator
– Dedicated Central Manager
– Aggregator and Central Manager
15 © 2011 IBM Corporation
Information Management

Aggregator and Central Manager Scenario

Aggregate
Aggregator and Central Manager
Manages

Collector 1 Collector 2 Collector 3 Collector 4

16 © 2011 IBM Corporation

Information Management

Dedicated Aggregator Scenario

Aggregate Aggregator and Central Manager

Manages Aggregator

Collector H1 Collector H4

Collector S1 Collector S3
Collector S2 Collector H3
Collector H2
Sales Databases
Human Resources Databases

17 © 2011 IBM Corporation

Information Management

Dedicated Central Manager Scenario

Central Manager
Aggregate

Manages
Aggregator
Aggregator

Collector H1 Collector H4

Collector S1 Collector S3
Collector S2 Collector H2 Collector H3
Sales Databases Human Resources Databases

18 © 2011 IBM Corporation

Information Management

Failover and Load Balancing

■ S-TAP sends periodic heartbeat check to Collector

– Real-time alert can be generated if S-TAP is disabled or uninstalled
■ CAS can also generate alerts in case of connectivity outages

■ S-TAP and CAS can log in to temporary buffer files if Collector cannot be reached
– Buffer is a flat file located on the data server on which S-TAP/CAS is installed
– Default size is 100MB for S-TAP and 50MB for CAS
– Ensures that audit data is not lost in the event that Collector in unavailable

■ S-TAP and CAS can support multiple Collector for failover and/or load balancing

■ Load balancing would only be required to sustain logging in cases with extreme data
volumes and full audit condition

19 © 2011 IBM Corporation

Information Management

Failover

■ Hosts are set through web portal or guard_tap.ini file

■ If set through web portal, order matters:
– first server is the primary
– all other are secondary
■ If set through guard_tap.ini:
– primary=1 (primary) Primary host
– primary!=1 (secondary)
■ Note that it can be set more than 1 secondary.
– In this case, primary=2, ..., primary=n,
■ S-TAP and CAS will attempt to connect to the hosts
according to the order.

20 © 2011 IBM Corporation

Information Management

Load Balancing

■ Load balancing:
Section A
– 0 = All traffic reported to a single Collector
– 1 = Distribute sessions between Collectors Section C
– 2 = Full redundancy; Report to all Collectors
■ Order of host (primary or secondary) does not matter.
Primary Host
■ All hosts have the same weight and all traffic for a single
session must to go to the same Collector.

Section D

Section B
Secondary Host

21 © 2011 IBM Corporation

Information Management

Questions?

22 © 2011 IBM Corporation

Information Management

User Interface Overview – Demo

23 © 2011 IBM Corporation

InfoSphere™ Optim™ & Guardium® Technology Ecosystem

InfoSphere™ Guardium® Technical Training

Guardium Architecture

Information Management

© 2011 IBM Corporation