Compliance reporting, alerting, and basic event correlation

As suggested in 3.2.1, “Log Management” on page 38, the Tivoli Security Information and Event Manager Log Management component can be deployed separately, providing centralized log data archiving and log data analysis. If an organization needs to adhere to regulatory compliance or security policy

guidelines, a SIM module must be added to provide normalization of original log data. For a comprehensive deployment, Tivoli Security Information and Event Manager offers three types of servers:

 Log Manager Server

This server implements the base Log Management components and log analysis reports.

 Standard Server

This server provides base Log Management components and compliance reporting.

 Enterprise Server

This server provides base Log Management components, compliance reporting, and log analysis reporting.

Tivoli Security Information and Event Manager compliance reporting requires that the log data is normalized. Both a Standard and Enterprise Server can be used to normalize the log data. This normalization process is depicted in Figure 3-5 (using the Standard Server as an example).

Figure 3-5 Normalization process

Log data is normalized using General Scanning Language (GSL) and Generic

Mapping Language (GML) scripts. Next, the normalized events are combined

with the User Information Source (UIS data), which is collected from the user

directories and the policy rules. Both UIS data and policy rules are represented

in Tivoli Security Information and Event Manager’s W7 model, which is a classification scheme that uses the following categories:

 Who  When  What  Where  Onwhat  Whereto  Wherefrom

Elements of the normalized events are categorized and assigned to a class within the category. The classes are either taken from the user directories or created by the user. The purpose of these classes is to be able to represent corporate assets in the W7 model and thus be able to specify relations between the assets. Let us take a look at an example.

W7 example

Let us use an example to look at a business rule and how this business rule can be translated into a W7 rule.

Business rule

Here is a typical business rule.

Contractors are only allowed to access the IT resources during the regular

workday hours.

This translates into a W7 rule

The translation can be mapped into W7 language in the following way:

Who Contractors When Workdays What Access Onwhat IT resources Where * Whereto * Wherefrom *

The W7 model that can represent this business rule will, in addition to the classes, also contain definitions to specify which values of the log data are considered to represent an IT resource. The same mechanism is used to assign log data values to the contractor’s class.

The mapper process normalizes the log data and applies the W7 model to the events. The normalized events are stored temporarily as bulk-copy (BCP) files before the loader process loads them into a physical database. If certain

normalized events are identified as alerts, these events are sent out as SNMP or e-mail messages. But they can also trigger custom scripts. Tivoli Security Information and Event Manager Standard and Enterprise Servers can also support basic event correlation that can trigger alerts. These types of event correlation rules are platform independent and are limited to correlate single types of events on the time aspect of the event, for example, you can create a correlation rule that aggregates logon failure events when they occur more than five times within five minutes by specific users or any other W7 categories. These correlation rules are applied after the log data is collected and normalized. In cases where more complex real time rule-based event correlation and alerting is required to be processed by a Security Operations Center (SOC), a separate Tivoli Security Operations Manager module must be integrated with the Tivoli Security Information and Event Manager deployment.

After the normalized events are loaded into a physical database, post processing takes place and statistics are computed on the number of normalized events that match a W7 rule. Every normalized event will at least match one W7 rule because every event is categorized and the values are assigned to appropriate classes. These statistical results are loaded into a separate database called the

aggregation database. An example of information that can be found in the

aggregation database is:

When Work days

Who Contractors

What Access

Onwhat IT resources

#Events 1034

This result can be interpreted as Contractors have accessed the IT resources

1034 times on regular working days.

This statistical information is available on a Tivoli Security Information and Event Manager Standard or Enterprise Server and is computed based on the

normalized data that the server generated. From a compliance reporting perspective, there is little difference between a Standard and an Enterprise Server, but from an architectural perspective there is a difference. Tivoli Security Information and Event Manager servers can be clustered to share the log archive between each other. A Tivoli Security Information and Event Manager cluster is comprised of one or multiple Standard Servers and one Enterprise Server. The log archive on the Standard Servers are shared with the Enterprise Server. The Enterprise Server provides a log analysis component that can use the log data that is collected by the Standard Servers in the same cluster. Therefore, the forensic search tool and the Tivoli Common Reporting reports on the Enterprise Server can also search the log archives of the Standard Servers.

Besides this added functionality of a Tivoli Security Information and Event Manager cluster, the statistical data that is kept in the aggregation databases on each Standard Server are copied to the statistical database on the Enterprise Server. This copying process enables a user to generate a single report that shows a summary of all events that are processed by each Standard Server in the cluster. Not only does such a report inform about the number of times a specific action happened, but it also informs about how many events violated the security policy or triggered an alert message. In general, this type of single report can be used to proof overall compliance across multiple Standard Servers.

In document IT Security Compliance Management Design Guide (Page 62-66)