Solution architecture

In this section, we discuss the solution architecture for SIEM. Basically, there are three steps:

1. Projection of an IT security compliance solution 2. Definition of an IT security compliance solution 3. Design of an IT security compliance solution

2.2.1 Projection of an IT security compliance solution

Most projects involve business tasks, such as cost-benefit analysis and budgeting, project management tasks, such as scheduling, resource allocation and risk management, and technical tasks, such as design, build, test, and deploy. The projects are also driven by business requirements, which we explained in 1.2, “Business drivers for IT security compliance management” on page 7 and in 1.3, “Business drivers for log management” on page 9. We restrict our discussion to the technical tasks that are associated with the production of the architecture and design document. For redundancy reasons, we do not explain the project phases in this section. Refer to our detailed explanation of the multiple project phases for deploying a security compliance solution in our scenario in Chapter 5, “Compliance management solution design” on page 89.

2.2.2 Definition of an IT security compliance solution

The project definition and planning phase documents the project in detailed steps. It involves the following tasks:

1. Analyze the existing environment. 2. Describe the problem at hand.

3. Document the detailed requirements for the solution.

The initial project definition is based on the documentation that triggered the project, such as the IT architecture, security architecture, and request for proposal (RFP) or equivalent. All of these documents identify the business background and the business needs for the solution and document the business and technical requirements for the solution. For a security compliance solution, the following (unordered) areas must be defined in this phase:

 Regulatory requirements

What are the regulatory requirements that the organization must adhere to? For example, is the enterprise listed at the New York Stock Exchange (NYSE)? If that is the case, it must be compliant to the Sarbanes-Oxley Act (SOX). Other regulatory requirements apply depending on the industry in which the organization is operating, such as compliance to PCI DSS, HIPAA, or FDA, just to name a few.

 Security policies

What does the corporate security policy define for users, accounts, passwords, access control, and so on? It is important to follow the

organization’s security policies because they ensure the correct handling of IT resources. They are the foundation of information security within an

organization.

 Monitored environment

– Target users: Who are the users who must be monitored? Examples are privileged users, database administrators, executives, and so on.

– Target systems: What are the components in your system environment that must be monitored? Examples include operating systems, databases, applications, the network, firewalls, physical locations, and so on.

 Reports

To demonstrate continuous evidence of compliance, it is mandatory to show compliance reports.

 Processes

Although we focus purely on designing a security compliance solution, the outcome of designing such a solution does not only result in a technical toolset and an infrastructure that must be implemented. To create a

comprehensive solution, we must develop supporting processes and put those processes into production, such as:

– Patch management process – User identity revalidation process

– Problem and change management process – Incident management process

There are many more processes that can be added to this list. Basically, for every IT related task, you need a process in place.

2.2.3 Design of an IT security compliance solution

The design of a security compliance solution is a schematic diagram that represents the governing ideas and candidate building blocks of the architecture. It provides an overview of the main conceptual elements and relationships in the architecture.

The main purpose of the design is communication. Thus, it is more important for the design diagram to be simple, brief, clear, and understandable rather than comprehensive or accurate in all details. Consequently, the diagram uses an informal rich picture notation. It typically includes supporting text that explains the main concepts of the architecture. This type of diagram can be produced at differing levels (in accordance to what we address in Chapter 1, “Business context for IT security compliance management” on page 3):

 At the organizational level

At an organizational level, a design diagram is often produced as part of an overall IT strategy. In this instance, it describes the vision of the business and IT capabilities that are required by an organization. It provides an overview of the main conceptual elements and relationships including data stores, users, external systems, and a definition of the key characteristics and requirements. At an organizational level, a design diagram is often produced as part of an overall IT strategy. In this instance, it describes the vision of the business and IT capabilities that are required by an organization. It provides an overview of the main conceptual elements and relationships, which includes data stores, users, external systems, and a definition of the key characteristics and requirements.

 At the system level

At a system level, the design diagram is produced very early in a project and influences the initial component model and operational model. It is not intended that design commitments be based on this overview until the (more formal) component model and operational model are developed and

 At the process level

The last level is the process level. This document most likely is not ready before the solution is deployed. Only after deployment is it possible to identify, develop, and implement the processes that are needed to become and stay in control of the security compliance solution.

Subsequently, the component model and operational model are the primary models, and the design diagram is a derivable view, which is revised if there are changes to the main concepts and relationships.

Chapter 5, “Compliance management solution design” on page 89 describes the design of a security management solution in depth.

2.3 Conclusion

In this chapter, we shed light into the necessary steps to plan an IT security compliance management solution. After we investigated several

compliance-related event types that must be collected, we described a general solution architecture.

In the next chapter, we introduce the IBM Tivoli Security Information and Event Manager logical and physical component structure and discuss several

Chapter 3.

Introducing the IBM Security