TIVOLI

SECURITY INFORMATION AND EVENT

MANAGER

TSIEM Introduction| Event sources| Configuring Policies| Reporting in

TSIEM |Best Practices in TSIEM

WHY SIEM ?

Security Information/Events = Logs

Logs are audit records generated by any software

component running on our IT infrastructure
Log records cover:

Normal activity Incident alerts

Error conditions Non-privileged access to files
Configuration changes User access to assets
Policy changes Unauthorized use of resources
User behavior patterns Clearing of sensitive data

Logs provide feedback on the status of IT resources and

all activity
going through them

Event Log Data Creators

Complexity of the Security

Infrastructure

Issues

Day to day: manual analysis of log data wherever it exists,

Cost of expensive Security Experts
Operational:
Time to resolution
Difficult to create problem owner for resolution
Expensive
Strategic:
Siloed Security Management does not encourage Operational
Convergence across Discrete Business Units

The Solution
Security Information and Event Management (SIEM)

Use Case:
Vulnerable Server Attacked

TIVOLI SIEM
INTRODUCTION

Introduction to TSIEM
Tivoli Security
Information and Event
Manager (TSIEM):
An enterprise-wide auditing
program for monitoring
internal computer activity.

TSIEM:
Provides continuous, non-intrusive
assurance and documentary
evidence that data and systems
are
being managed in accordance
with and comply with company
policies.

Components of TSIEM
Log Management
The Log Management
module collects log data that
is relevant to security
auditing and compliance
monitoring. It
stores the data on a central
server, the Log Management
Server.

Security Information
Management (SIM)
The SIM module
evaluates and reports on
user-oriented
events and evaluates
them against
predetermined policy.

Server types and their functions

1.Log Management server

It provides all Log Management functions, including log

collection, log storage, log retrieval, forensic search,
and log management reports.
This server type is deployed to manage log data for
which SIM functions, such as W7 normalization and
compliance reporting, are not required.
If you did not purchase the Security Information
Module, you can deploy only Log Management Servers

Continued..

2. SIM Standard Server

It provides log collection, log storage, log
retrieval, W7 normalization, and compliance
reporting, but no forensic search or log
management reports

3. SIM Enterprise Server

It provides all Log Management Server
functions as well as all SIM functions such as
W7 normalization and compliance reporting.
Also provides a consolidated view of
normalized W7 data on the attached
Standard Servers , forensic search and log
management reporting.

EVENT
SOURCES

Event sources

Audit data is collected from various devices and applications

using event sources
To establish event monitoring in Tivoli Security Information and
Event Manager, you must deploy one or more event sources
An event source can be a database, an application, an
operating system, a network device, or other platform that
records its events in logs and to which the Tivoli Security
Information and Event Manager has access in order to collect a
selection of security-relevant logs for event monitoring and
reporting.

Data Collection scenarios

W7 Format

First collect the raw events that are being generated by

event sources
These events would be placed as chunks in the depot
directory of the TSIEM server which can then be loaded as
per schedule.
The customized script run periodically so that raw audit
data is converted into the W7 CSV or XML file and placed
at a location (which you have mentioned while creating the
W7 Event Source on the TSIEM GUI).
when, who, what, where, wherefrom, whereto, onwhat

Description of the W7 fields

W7 Fields

W7 Fields

Configuring
Policies and
Alert Rules

Configuring policies

A Security policy consists of group definition sets, policy

rules, and attention rules defined for one or more
platforms.
When systems whose activity is audited are registered,
IBM Tivoli Security Information and Event Manager
applies the policy and attention rules in your security
policy to load audit data from each system into a SIM
Reporting Database, organizing the data using the
groups you defined, and displaying the results in the
Compliance Dashboard.

Committing policies

A committed policy is
used to run automated
compliance checks.
Only work policies can
be committed. After a
policy is committed, it
cannot be modified or
deleted.

Elements of a security policy

When you create a security policy, you must define the

following elements:
Platforms
Group definition sets
Groups
Conditions
Requirements
Policy rules
Attention rules

Testing policies

Before you commit a Work policy, it can be helpful to test

it and see how it analyzes the audit data.
When you test a policy, you load audit data and map the
W7 data against the policy definitions. Only Work policies
can be tested. The testing functionality is not available for
Committed policies.
Open the Policy Editor. Click Test Policy. The Load
Database Wizard opens. Manually map and load audit
data into a Reporting Database and run the dataset
against a Work policy

Managing attention rules

Attention rules determine which events trigger an

alert.
The trigger criteria is based on a rule or
combination of rules.
We can use the Policy Editor to view attention rules,
create rules, delete rules, edit rules, copy rules,
paste rules, and import rules.
Attention rules are also referred to as Black listed
policies or Alert rules.

Managing alerts

All defined alerts are displayed in the Alerts page. You can
create, edit, and delete alerts, and you can also configure
the protocol settings used to send the alerts.
The purpose of an alert is to raise attention for events that
require a follow-up, that is, special attention events or
events that are above a defined severity level, such as
security policy exceptions. Alerts notify specified recipients,
such as a system administrator, when a serious or
potentially harmful security event has occurred. The
relevance (severity) of an event is defined in the security
policy.

Reporting in
TSIEM

Introduction to Reports

Tivoli Security Information and Event Manager provides

dozens of security compliance reports that enable you to
check compliance with security policy, to verify the log
collection events, and to analyze data in the Log
Management Depot.
The log management reports are accessed through the
Log Management Dashboard.
The Tivoli Common Reporting report set can be accessed
through the navigation panel in the Tivoli Integrated Portal
as well as through the Log Management reports.

Compliance Reports

TSIEM provides many security compliance reports,

including:
Graphic reports
Event summary reports
Event detail reports
Trend reports
Standard reports
Custom reports
Log management reports
Compliance management module reports

Graphic Reports

Graphic reports provide visual analyses of security

policy compliance activities. The purpose of
graphic reports is to show you, at a glance, the
status of security compliance in your organization.
Examples of graphic reports include the
Enterprise Overview graph, the Trend graphic, the
Database Overview graphic, some of the Log
Manager reports, and others

Example: Enterprise overview graph

Event summary reports

Event summary reports, or event lists, provide lists of all

events that match the specified criteria. For example,
you can see a list of all events that occurred during a
particular time period. Event summary reports are
useful for seeing what other events occurred at the
same time or affected the same technological assets, or
otherwise share a W7 attribute.
From the event list, you can drill down to see event
detail reports.

Example: Event summary reports

Trend reports

Trend reports show security events over

specific time periods.
Trend reports are useful for identifying
general trends in security compliance.
You can drill down into the trend reports to
see information about specific events.

Example: Trend reports

Report Centers

Configuration tools
Daily verification reports
Detailed investigation reports
Firewall reports

Configuration tools

Daily verification

Detailed Investigation

Troubleshooting
and
Best Practices

General Troubleshooting & Best Practice

Agent/Agent-less Collect
Troubleshooting:

Over View of the Collect process

Logs involved
Stages where collect may fail
Troubleshooting

Collect Process Overview

Stages where collect may fail

Connection fails.
Collect User has inadequate permission
(Audit Trail/TEMP).
Collect Script fails.
No Events to collect.

Connection Failures

Verifying that the Agent and TSIEM server are

communicating
Verifying ssh connections are good
Some common connection errors (this not an
exhaustive list):
1. Agent not running
2. Agent and or target is not reachable
3. SSH keys bad
4. Agent certificate bad.

User Permissions to the Audit Trail:

The user the agent runs as must have access

to the audit trail directory/files and any other
directories defined in the Event Source
properties.
Recommended user that the agent should
run as. Windows - administraor
Linux/AIX - root

Reporting Database Load Problems

Best Practices

Dont Try to filter the logs at the source

Good event logging systems will capture 100% and let you
purge later

Determine Reporting Time Periods

1 week, 1 month, 90 days - more?
Reporting Periods will drive event data retention policies.
Plan to store data at least 2 complete reporting intervals
If you purge old data be sure you have proper archives

Use a centralized, standard time source

When event logs are time aligned life is much easier

Best Practices

Dont Alert on Everything Take it Slow

Prioritize on what You REALLY want to be alerted on

Leverage Correlation to Weed Out False Positives

Rules-based correlation techniques can reduce the chatter
Correlated reporting will let get a more holistic view of the network

Be cautious of sensitive event log content

Be sure that centralized logging facility is secure

Encourage Your Teams to Analyze the Data

Determine your standard reports develop baselines look for

exceptions

If You Didnt Log It, Then It Never Happened

Demo
Questions/Comme
nts!!!!

Best Practices

Agent-based data flow log collection