Phase 2: Project definition and planning

At this point, you:

 Acquired base information from discovery and analysis about reporting requirements, the installation environment, and audit settings.

 Next, you implement a pre-planning worksheet, based on target platforms (with server names, platforms and versions, daily log sizes, server location, database groupings, and so on).

 Then, you define a draft project plan with an initial project schedule, reporting requirements, and installation environment information. This plan is based on the typical Tivoli Security Information and Event Manager implementation design architecture (number and location of Tivoli Security Information and Event Manager servers, hardware specifications, and so on) and installation prerequisites (software and platform versions, audit settings, ports, and protocols that are needed to install Tivoli Security Information and Event Manager).

The Tivoli Security Information and Event Manager implementation design architecture is a result of information that is gathered in previous phases, product capabilities, and planning. Therefore, for a successful implementation, it is very important that we discuss project definition and planning in more detail in the next subsections.

We explain general logical (conceptual) and physical (system) architecture in the Tivoli Security Information and Event Manager product documentation and in Chapter 4, “IBM Tivoli Security Information and Event Manager component structure” on page 53. In this section, we focus on the various design layouts and the reasons behind those layouts. We start with functional design and

configuration.

Design and configuration

There are common network models for security architectures where components with similar security requirements are grouped into zones. Using Figure 5-3 on page 95, think of these areas as uncontrolled, controlled, restricted, secured, and externally controlled. A client uses the network to access applications and data. This client can be from either within your organization or outside of it.

Firewall: In Figure 5-3 on page 95, the breaks between each network zone indicate the use of a firewall that clearly delineates each perimeter from the next.

Figure 5-3 Network zone concept

Using this concept you can translate Figure 5-3 into a more targeted deployment decomposition, as shown in Figure 5-8 on page 98.

Tivoli Security Information and Event Manager supports up to eight audit configurations, as shown in Figure 5-4 on page 96 through Figure 5-7 on page 97, where dashed lines represent the system boundary. The layout of Tivoli Security Information and Event Manager components, data flow from audited system to server, and the control of data flow from audited to target system define the actual audit configuration.

This configuration is sufficient for auditing multiple event sources on systems that run unlike operating systems. For more information about deploying Tivoli Security Information and Event Manager event sources, see IBM Tivoli Security

Information and Event Manager Event Source Guide

, SC23-9687.

Figure 5-4 on page 96 shows the audit configuration with all components separated.

Note: The number of audit configurations supported on a specific platform varies from one event source to another.

Figure 5-4 Tivoli Security Information and Event Manager audit configuration 1

Figure 5-5 shows audit configurations where either left, middle, right or left, and right pair of components share the same system.

Figure 5-5 Tivoli Security Information and Event Manager audit configurations 2, 3, 4, and 5

Figure 5-6 shows audit configurations where only the audited system or the server is on its own system.

Figure 5-6 Tivoli Security Information and Event Manager audit configurations 6 and 7

Figure 5-7 on page 97 shows the simplest audit configuration with all components on the same system.

Agents: The Tivoli Security Information and Event Manager Enterprise Server can act as an agent in configurations. If this is the case, no agent needs to be installed, because it is already included in the server installation. Otherwise, you must install an agent that corresponds to the operating system that runs on the agent.

Figure 5-7 Tivoli Security Information and Event Manager audit configuration 8

To exchange information among its components, Tivoli Security Information and Event Manager uses a network of agents that maintain encrypted communication channels. This network runs on the TCP/IP layers of the existing organizational network.

The actual collection process can involve multiple mechanisms in a variety of configurations. A system audited through remote collect does not need to run the Tivoli Security Information and Event Manager software. Instead, event data is forwarded to the server by an agent with direct access to the audited system. To audit several systems in a Windows domain, only one must be configured as an agent and have an Actuator installed. For more information about Tivoli Security Information and Event Manager concepts and typical configurations, see the IBM

Tivoli Security Information and Event ManagerVersion 2.0 User Guide,

SC23-9689.

In Figure 5-8 on page 98, we place components of Tivoli Security Information and Event Manager into separate network zones to show many, but not all, possible audit configurations and collect mechanisms.

Figure 5-8 Tivoli Security Information and Event Manager deployment options

For Tivoli Security Information and Event Manager to operate, at a minimum the database engine and one server must be deployed. Optionally, one or more servers can be added to enhance storage and logging capabilities. The server component must be placed into the management zone because chunks are stored there and they are the most important asset because they hold crucial data for any forensic or reporting activity.

Agents can be located in other network segments to suite the performance and scalability needs and requirements of direct or remote data collection from audited systems.

Let us explain the examples of possible audit configurations and collect mechanisms, numbered from 1 to 10, in Figure 5-8:

1. Example 1 shows the most simple collect configuration. The agent and the audited instance of the event source are located on the server system. In other words, Tivoli Security Information and Event Manager collects data directly from the server itself. Tivoli Security Information and Event Manager controls the transfer of data.

2. Example 2 shows a configuration where the agent and the audited instance of the event source are located on the same system, and the server is hosted by

another system. In other words, Tivoli Security Information and Event Manager collects data directly from an agent (not equal to server).

3. Example 3 shows a configuration that is similar to the previous one, but this time the user arranges to transfer data from an audited system to an agent (not equal to server), where the data is collected.

4. Example 4 shows the remote collection for a Windows configuration, where the audited instance of the event source is hosted by a system other than the agent, and the server system acts as an agent for this event source. In other words, Tivoli Security Information and Event Manager collects data directly from a remote system. The remote collect does not require a running agent on the audited system. Remote collect involves a remote data retrieval mechanism from an independent vendor. The most common configuration is used for event sources that are based on the Windows log mechanism using the Windows event management API.

5. Example 5 shows SSH collect, similar to the previous example, but this time the user arranges to transfer data from the audited system to a remote target system (not equal to server), from where the server collects the data. SSH collect is another variation of remote collect. It can be used with event sources that are based on UNIX and Linux. The configuration is similar to Windows remote collect; however, the data retrieval mechanism utilizes an SSH connection from the agent to the audited system.

6. Example 6 shows Syslog and SNMP collection—the Tivoli Security Information and Event Manager capability to process and analyze security events that are collected through the Syslog and SNMP network logging mechanisms. To collect network events, a component listens in the network and receives all incoming events.

The Tivoli Security Information and Event Manager agent has a built-in listening component that can be activated on any Windows agent and can receive both SNMP and Syslog messages. The agent, server, and the audited instance of the event source are all hosted by distinct systems. In other words, Tivoli Security Information and Event Manager collects data that is directly from a remote audited system through an agent (not equal to server). When the target system component is also present, a user arranges the data transfer to a remote system (not equal to the agent), from where an agent (not equal to server) collects the data.

7. Example 7 is similar to the previous one, but for high volume Syslog processing, a Microsoft Windows-based receiver might not deliver the necessary performance. In these situations, you might want to use a Linux-based Syslog receiver that provides better performance, such as Syslog NG, which is an open source Syslog implementation.

8. Example 8 shows a custom collection mechanism FTP collect. If no other suitable collect mechanism is available, a script is scheduled on the platform

of the event source. The log data is put into a folder where it can be picked up by the agent.

9. Example 9 shows a collection using external APIs. Frequently, obtaining security event data involves using an API that has a specific API event source. Whenever such an API works across a network link, this action influences the configuration. A common example is auditing network appliances. A network appliance usually comes with a management console or other external component that interacts with it. That component also provides the API to obtain the event data.

10.Example 10 shows the integration with IBM Tivoli Security Operations Manager. We discuss the integration in more detail in Chapter 3, “Introducing the IBM Security Information and Event Management solution” on page 27. Based on the various Tivoli Security Information and Event Manager deployment options that are shown in Figure 5-8 on page 98 and the various collect

configuration examples, we can show what a small, medium, and large solution design might look like. We start with an example of a small solution in Figure 5-9.

Figure 5-9 Small Tivoli Security Information and Event Manager deployment

A small Tivoli Security Information and Event Manager deployment is best suited for a homogenous environment. We assume a fairly simple environment with a small number of audited systems, which can all be monitored remotely. There is also no need for forensic log search capability, and Syslog performance is low. A single server deployment can handle all of the needs in such an environment.

For a more advanced environment with more audited systems and log forensics requirements, we design a cluster of servers for better performance and to implement log search capability. We also assume that the environment is heterogeneous. Thus, we cannot cover all audited systems remotely any more but must implement certain agents with Actuators.

Figure 5-10 illustrates how a medium Tivoli Security Information and Event Manager deployment might look.

Most demanding environments can involve multiple heterogeneous

environments with high performance, availability, and scalability requirements, communication across dispersed locations, and so on. Figure 5-11 shows one possible Tivoli Security Information and Event Manager deployment for such requirements.

Figure 5-11 Large Tivoli Security Information and Event Manager deployment

For high scalability and performance, there are multiple clusters deployed with multiple agents serving multiple clusters. As shown in Figure 5-11, with the line coming from the Internet zone, there is consolidation among several locations and regions in place. For high Syslog performance, the Syslog receiver is implemented in the DMZ zone. For high availability, all Tivoli Security Information and Event Manager servers are connected to a Storage Area Network (SAN). We discuss the design approach for our specific scenario in more detail in the second part of the book in 7.3, “Design approach” on page 140.