Connector Corner: Accelerate revenue generation using UiPath API-centric busi...
Deployment guide series ibm tivoli compliance insight manager sg247531
1. Front cover
Deployment Guide Series:
IBM Tivoli Compliance
Insight Manager
Planning for an enterprise compliance
management deployment
Installation and configuration of
major components
Best practices and
troubleshooting
Axel Buecker
Ann-Louise Blair
Franc Cervan
Dr. Werner Filip
Scott Henley
Carsten Lorenz
Frank Muehlenbrock
Rudy Tan
ibm.com/redbooks
2.
3. International Technical Support Organization
Deployment Guide Series:
IBM Tivoli Compliance Insight Manager
February 2008
SG24-7531-00
10. Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
AIX® iSeries® Redbooks®
DB2® PartnerWorld® Redbooks (logo) ®
IBM® RACF® Tivoli®
The following terms are trademarks of other companies:
Oracle, JD Edwards, PeopleSoft, Siebel, and TopLink are registered trademarks of Oracle Corporation
and/or its affiliates.
Snapshot, and the Network Appliance logo are trademarks or registered trademarks of Network Appliance,
Inc. in the U.S. and other countries.
ITIL is a registered trademark, and a registered community trademark of the Office of Government
Commerce, and is registered in the U.S. Patent and Trademark Office.
Java, Solaris, Sun, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United
States, other countries, or both.
Active Directory, Excel, Internet Explorer, Microsoft, Windows, and the Windows logo are trademarks of
Microsoft Corporation in the United States, other countries, or both.
Intel, Pentium, Pentium 4, Intel logo, Intel Inside logo, and Intel Centrino logo are trademarks or registered
trademarks of Intel Corporation or its subsidiaries in the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Other company, product, or service names may be trademarks or service marks of others.
viii Deployment Guide Series: IBM Tivoli Compliance Insight Manager
12. Franc Cervan is an Advisory IT Security Specialist from IBM Slovenia. He holds
a degree in electrical engineering and is also ITIL® certified. He has over 10
years of experience in security and systems management solutions. Since 2003
he is part of the IBM Software group as a Tivoli Technical Sales Specialist for the
SEA region. His areas of expertise are Tivoli Security and Automation products.
Dr. Werner Filip is a professor at the Department of Computer Science and
Engineering at the University of Applied Sciences Frankfurt am Main, Germany
and a Consultant in IT Security. His primary research interests are Systems and
Network Management and Applied Security. Prior to joining the University of
Applied Sciences Frankfurt, he worked for 25 years for IBM in various positions,
and spent his last 10 years with IBM as a Consultant in Systems and Network
Management at the former IBM European Networking Center, Germany. He
received a diploma in Mathematics and a Doctorate in Computer Science from
the Technical University Darmstadt, Germany.
Scott Henley is an IBM Pre-sales Senior IT Specialist. He performs pre-sales
support for the IBM Tivoli Security portfolio throughout Asia Pacific. He is an
expert in many IBM Tivoli Security products and in recent years has specialized
in the Security Information and Event Management space. His current role at
IBM is as an above country expert for the Asia Pacific region, which means that
he travels throughout the Asia and Pacific region speaking with and assisting
IBM customers so that they get the best value from their investment in IBM
security technologies. He is also often called upon to speak at various industry
conferences on topics such as Compliance, Risk Management, and Governance.
He holds a Bachelors Degree and Masters Degree with Distinction in Information
Technology, is a CISSP, and holds numerous other industry and product
certifications that he has collected throughout his almost 20 years in the IT
Industry.
Carsten Lorenz is a certified Senior Managing Consultant at IBM Germany. He
manages security solutioning in large and complex IT infrastructure outsourcing
engagements for customers throughout Europe, the Middle-East, and Africa. He
has more than eight years of experience in the security and compliance field,
specializing in the areas of Security Management, IT Risk Assessment,
Governance, and Operational Risk Management. Carsten has performed
consulting engagements with IBM customers in various industries, ranging from
Fortune 500 to SMBs. Carsten is a CISSP and a CISA, and he holds a Bachelors
Degree in European Studies from University of Wolverhamption, UK, and a
diploma in Business Science from the University of Trier, Germany.
x Deployment Guide Series: IBM Tivoli Compliance Insight Manager
13. Frank Muehlenbrock is an IBM Information Security Manager. After having
supported pre-sales and services activities in Germany for Tivoli Security
Compliance Manager, he has specialized in recent years in implementing,
managing, and maintaining security policies, standards, and guidelines. In his
current role, he manages Information Security for a large global outsourcing
customer of IBM that has a presence in EMEA and North America. Frank studied
Information Management at the Fachhochschule Reutlingen, Germany. He is an
accredited Security Architect and also holds a Certified Information Security
Manager (CISM) certification. He also holds several other industry certifications,
which he achieved during his 20 years of experience in the information
technology industry.
Rudy Tan is a Senior IT-Specialist and works as a technical course developer in
the IBM Tivoli Lab in Delft, Netherlands. He has 15 years of experience in the IT
industry with a focus on security. In the past 10 years, Rudy has worked at
Consul as a Tivoli Compliance Insight Manager developer, consultant, and
trainer.
Figure 1 From left, Werner, Axel, Ann-Louise, Franc, Scott, Rudy, Carsten, and Frank
Besides working on this IBM Redbooks publication, this great team also
developed the Compliance Management Design Guide with IBM Tivoli
Compliance Insight Manager, SG24-7530.
Preface xi
14. Thanks to the following people for their contributions to this project:
Wade Wallace
International Technical Support Organization, Austin Center
Nick Briers, Koos Lodewijkx, Dimple Ahluwalia, Jose Amado, Bart Bruijnesteijn,
Philip Jackson, Sujit Mohanty, Erica Wazewski
IBM
Become a published author
Join us for a two- to six-week residency program! Help write a book dealing with
specific products or solutions, while getting hands-on experience with
leading-edge technologies. You will have the opportunity to team with IBM
technical professionals, Business Partners, and Clients.
Your efforts will help increase product acceptance and customer satisfaction. As
a bonus, you will develop a network of contacts in IBM development labs, and
increase your productivity and marketability.
Find out more about the residency program, browse the residency index, and
apply online at:
ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us!
We want our books to be as helpful as possible. Send us your comments about
this book or other IBM Redbooks publications in one of the following ways:
Use the online Contact us review book form found at:
ibm.com/redbooks
Send your comments in an e-mail to:
redbooks@us.ibm.com
Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400
xii Deployment Guide Series: IBM Tivoli Compliance Insight Manager
18. 1.1 Introduction to compliance management
The process that an organization operates in accordance with expectations is
called compliance management. The expectations are formulized as
requirements in the policies and can include requirements derived from external
laws and regulations (like country-specific data privacy laws, such as Sarbanes
Oxley1, or Basel II2) and from the individual mission statement of an organization
(like ethical behavior or business conduct guidelines).
Information security defines the level of protection for information assets of an
organization and summarizes all activities around the security controls applied in
order to achieve a desired level of confidentiality, integrity, and availability of
information assets. In a best practice approach, the desired level is derived by
determining the balance between risks resulting from compromised information
security and the benefit aligned with the information asset. It is a good business
practice to minimize the security risk to information in proportion to the
importance of such information to the business. Security controls are usually
defined in a security policy framework.
A security policy framework is organized hierarchically, starting with a top level
organizational security policy, which is directly derived from the business context,
defines the requirements rather broadly, and leaves room for interpretation. The
next level consists of refining policies per business unit or department to
implement the top level policy. Depending on the size of an organization, there
might be several layers of security policies with increasing precision from top to
bottom. At one point, the policies start to define technology requirements at a
high level and are often referred to as security standards. Again, there can be
multiple levels of standards. Besides these standards about security
requirements in technical terms, you can find security procedures and security
practices describing process details and work instructions to implement the
security requirements. The benefit of a policy framework is the reduction of
interpretation to a minimum, the translation of broad business directions into
corresponding work instructions for processes and technical settings for
systems, and the provision of extensive editable records about the management
direction for information security.
1
The Sarbanes-Oxley Act was established in 2002, as a result of corporate scandals (for example,
Enron and Worldcom) about incorrect financial reporting and aims to protect stakeholders from
huge losses and to prevent future shocks to confidence in the financial system in the USA. Since
July 2006, the law applies to all companies listed on the US stock exchanges, including
international or foreign companies. To learn more, go to http://www.soxlaw.com/.
2
Basel II is an accord issued by the Basel Committee on Banking Supervision that summarizes
recommendations about banking laws and regulations with the intent to harmonize banking
regulation worldwide. This second accord introduces matters concerning Operational Risk, which
again includes risks in the area of technology, processes, and people. To learn more, go to
http://www.bis.org/publ/bcbsca.htm.
4 Deployment Guide Series: IBM Tivoli Compliance Insight Manager
19. Bringing both definitions together, security compliance is understood as the
process that ensures that the operations of an organization meet the
requirements defined in the security policies, which again consolidate legal and
regulatory obligations and management direction. Compliance management
requires the ability to identify compliance criteria and to assess, analyze,
consolidate, and report on the previous, the current, and the expectable
compliance status of security controls.
Security controls exist on an organizational, process, and technical level:
An organizational level security control can be a concept like separation of
duties, for example, ensuring that someone changing something is not the
same person controlling the business need and proper execution of the
change. This type of security control may require an organizational setup
where those two employees report to different managers.
A process level security control can be a concept like the four eyes principle,
where a specific authorization requires two signatures (or passwords) to be
presented before a transaction can be completed. As a result, this process
step would always require two employees to be available for execution.
A simple technical security control can be a required length for a password or
specific permissions that are defined for accessing an operating system
resource or business data. Operating systems and applications provide
configuration settings that allow the administrator to specify minimum
password lengths so that the system itself can enforce this control. A more
complex technical security control can be the requirement to run an antivirus
service (with up to date virus definition files, of course!) on a computer system
or a correctly configured port filter.
Technical security controls are the easiest to monitor, as computer systems save
audit trails and configuration files, which can be checked for the fulfillment of
requirements. Security controls on the organizational and the process level
(especially when process steps are not performed with the help of technology)
are harder to check and to control, as they are less persistent, and audit trails are
not created automatically and can be easier manipulated.
1.2 Business drivers for compliance management
While the traditional factors of production are defined as natural resources,
capital goods, and labor, today’s economy relies on information as a fourth factor
of production. Due to the large amount, frequent update, and fast aging of
information, most businesses today rely heavily on their information technology
to better use information. Information has become so critical, that damage
incurred to this information can force a company out of business, for example, by
Chapter 1. Business context 5
20. reduced availability caused by downtime of systems processing this information.
The protection of information and the technology used to process it has become
essential, and compliance management of companies focuses to a significant
extent on the compliance of underlying information technology.
Compliance management today is driven by multiple initiatives:
Compliance towards commercial laws and industry regulation
Compliance management can be externally driven to keep up with the
changing global regulatory and business environment. This requires ongoing
audit capabilities. Regulations, which translate into security control
requirements, are, for example, data privacy laws (applicable for any
organization dealing with personally identifiable information), Basel II (for
organizations providing financial services), HIPAA3 (for organizations involved
in activities with potential impact to public health and hygiene) and PCI4 (for
organizations processing credit card information).
Compliance to objected performance and efficiency targets
Compliance management can be internally driven by the intent of
organizations to stay in business and be profitable. Driven by the fact that
compliance requirements must be fulfilled in order to meet legal and
regulatory obligations, companies want to maximize the benefits of
compliance management by also using the process to identify not only risks,
but also opportunities to increase efficiency, which ultimately can lead to
competitive advantage.
Note: Customers are responsible for ensuring their own compliance with
various laws and regulations such as those mentioned above. It is the
customers’ sole responsibility to obtain the advice of competent legal counsel
regarding the identification and interpretation of any relevant laws that may
affect the customer’s business and any actions the customer may need to
take to comply with such laws. IBM does not provide legal, accounting, or
auditing advice, or represent that its products or services ensure that the
customer is in compliance with any law.
The trend to use compliance management beyond its initial purpose is reflected
in some of the regulations. For example, in Basel II, the excellence of risk
management for IT systems, which is part of the operational risk complex, has an
impact on the competitive advantage of banks. The level of excellence
determines how much money a bank can use to provide credit to their customers
and how much it has to keep in reserve to cover risks, which again affects the
interest rates a bank can offer its customers. So today, even the external
3
For more information about HIPAA, go to http://www.hhs.gov/ocr/hipaa/.
4
For more information about PCI, go to https://www.pcisecuritystandards.org/.
6 Deployment Guide Series: IBM Tivoli Compliance Insight Manager
21. regulation itself develops further from a basic approach of compliance versus
non-compliance towards approaches in the area of control versus
non-compliance, where compliance is the highest level of control possible.
Note: Being compliant versus being in control
If you have ever been audited (or audited someone), you probably know that
there is a difference between being:
In compliance: All your systems and processes are operated and delivered
according to the security policies and standards (and you have evidence
for compliance).
In control: You know what is in compliance and what is not, you know why,
and you have a plan of action (and you have evidence for control).
Now, what is more important? Being in control is. Because you could be in
compliance by accident. Further, if you are compliant, but not in control,
chances are high that you will not stay compliant for very long.
If you are in control, you will end up being compliant eventually. Or at least you
will have it on record why you are not compliant.
And if you are not compliant and not in control, gaining control should be your
primary goal.
This is the reason why regulations shift more and more from compliance to
control objectives.
Most organizations do not stop after they have met the basic principles set out in
their policies, as they want to understand how efficiently this level of compliance
was achieved or even exceeded. Customers also want to identify indicators
about how stable and consistent the current compliance achievement is and
whether the state of compliance can be maintained.
Chapter 1. Business context 7
22. 1.3 Criteria of a compliance management solution
While having security compliance management in place is generally a good
security practice, there are several factors that influence if and how compliance
management is implemented in a specific environment. Let us take a look at the
main dimensions of compliance management:
Selection of security controls
This is the intention to check technical security controls and security controls
in processes and on the organizational level.
Spot check versus duration check
This is the intention to check the security configuration of systems, of network
devices, and of applications at any given point in time (or multiple points in
time), or it is the intention to monitor the behavior over a period of time that
might cause a non-compliant configuration (and maybe even prevent this
result, if the behavior is analyzed early enough to counteract it).
Number of security controls
This defines which and how many security controls are checked. Do you only
check security settings in configuration files or do you check log entries as
well? Do you check only operating system level controls or are application
level controls checked as well? Which operating systems, middleware, and
business applications need to be supported?
Frequency of checks
This defines how often a compliance check is performed. This does not only
define how often the configuration settings are collected from the
environment, but also the frequency in which system administrators are called
upon to fix or investigate identified deviations.
Follow up time frame
This defines how fast reported deviations must be fixed.
Scope of compliance checking
This defines which business processes and their supporting IT systems are
required to be checked for compliance and what level of control is required for
these IT systems. As security is always concerned about the weakest link,
related infrastructure systems need to be included as well.
Level and depth of reporting
This concerns organizations having to fulfill obligated external reporting
requirements as well as individual reporting to fulfill needs inside the
organization, for example, towards the board of directors, internal accounting,
the security operations management, or even towards specific
8 Deployment Guide Series: IBM Tivoli Compliance Insight Manager
23. compliance-related projects. The reporting can differ in detail and range from
reporting technical details to highly aggregated business level reporting. Also,
the reporting can be discrete, for example, on a predefined time frame, or
continuous (despite the checks still being performed non-continuously). The
latter is often referred to as dashboard.
Level of automation
This concerns a compliance management solution relying on automated
checks, which requires higher investments in technology, or for manual
checks, which requires more human effort and skills, or a combination of both.
Also, the level of automation can be limited by technological limitations, for
example, compliance tools not supporting every system, that should be
checked for compliance, or the system itself is not providing enough
functionality to provide information about its compliance.
The key dimensions listed above can be derived by considering the following
secondary factors:
Business environment of the organization
Is corporate espionage or other business crime an issue? Does the company
use outsourcing services? How dependent is the business on its IT systems?
Regulatory and legal obligations
In which industry is the business operating? In which countries is the
business operating? Which laws and regulatory requirements exist in each
country for this industry that influence information security? What level of
scrutiny is executed by the regulators?
Note: It is useful to keep in mind that a security compliance management
system can provide a lot of evidence about the level of executive control.
Organizational complexity
The size and setup of the organization influences the speed of the reaction to
deviations from the desired security level. Furthermore, it will have a
significant impact on the requirements on an IT security compliance
management solution, such as the administration approach.
Technological complexity
Obviously, the existing IT environment defines the scope of the operating
system, middleware, and business applications that need to be supported by
any IT security compliance management solution. Also, the level of
standardization, centralization, and consolidation has a significant influence
on the IT security compliance management solution.
Chapter 1. Business context 9
24. Security policy framework maturity
Mature businesses have shaped the existing security policies and standards
as well as work practices and procedures from the policy level. This defines
the general security control requirements and the standard level, which
provides platform specific security settings that meet the security control
requirements on a given platform, as well as descriptions about how to
implement the standards and how to deal with situations where the standard
cannot be applied due to specific technical requirements of a given system.
1.4 Recent challenges for compliance management
Even if the goal for security compliance is clear, defined by precise policies and
standards, the task of compliance management for a larger number of systems
has the following major challenges in addition to the requirements resulting from
the factors discussed above:
Maintenance of compliance over time
Even in a stable environment, systems are constantly changed because
patches must be applied, updates must be installed, or additional packages
require a change in the configuration of the underlying operating environment.
Also, the ever increasing requirements of regulations require companies to
keep up with these changes in order to retain compliance.
Complexity of the environment
Few businesses can claim that their environment is homogenous and
centralized. Heterogeneous, geographically distributed systems in large
numbers is the norm, with not only systems from multiple vendors, but also
running several different versions of operating systems at the same time.
Complexity is growing, and today’s more complex applications and moves
toward service-oriented architectures (SOA) take operations management to
new levels of complexity.
Complexity of the compliance criteria
Checking the security controls of managed systems ensures that a system
does not degrade in its security controls posture due to changes made on the
system after it has been installed. For example, changes made while
resolving a problem, while installing or upgrading a new application or
middleware, or due to an attacker changing the configuration to hide his
tracks or to compromise the system.
10 Deployment Guide Series: IBM Tivoli Compliance Insight Manager
25. Performance efficiency and cost pressure
Organizations always try to do more with less. As compliance is a matter of
quality, there is a requirement for compliance to be delivered for less cost. As
labor costs are considered one of the major operation expenses for
organizations, the aim is to automate compliance management as much as
possible.
Organizations want to evolve from the traditional compliance checking, which
focuses on collecting of the compliance status information at a given point in time
towards controlling the non-compliant events at any point in time:
Organizations want to be able to react to indicators that suggest a future
status of non-compliance.
Organizations want to identify what causes a status of non-compliance in
order to avoid it in the future.
In order to achieve both goals, organizations extend the scope of compliance
checking from technical configurations of the operating environment towards the
behavior of actors in this environment, including or even especially the users and
administrators. It is not the IT systems that choose to become noncompliant over
time, but it is the actions of people that can cause noncompliance accidentally or
on purpose.
Shifting the focus from the resulting status to evoking proactive behavior puts the
focus closer to the root cause.
1.5 Conclusion
As a result of the influencing factors discussed above, a security compliance
management solution must provide a flexible yet comprehensive framework that
can be configured and customized to the specific organization in question and
takes a holistic approach on collecting and controlling the information security
compliance of an organization. Such business requirements for compliance
management set the boundaries for functional and non-functional requirements
of a technical compliance management solution.
The increased pressure on organizations to demonstrate better control and
compliance and the ever-increasing complexity of the business and the technical
environment demands integrated and automated solutions for compliance
management in order to prevent the organization from spending more time for
managing compliance than for its primary objectives.
Chapter 1. Business context 11
26. The rest of this book discusses the implementation of such an automated
solution based on the IBM Tivoli Compliance Insight Manager.
12 Deployment Guide Series: IBM Tivoli Compliance Insight Manager
28. 2.1 Product overview
Tivoli Compliance Insight Manager helps organizations meet audit and logging
requirements. It provides reliable, verifiable log data collection and centralizes
security log data from heterogeneous sources. Log data is analyzed and
compared with the security policy and if suspicious activities are detected, Tivoli
Compliance Insight Manager can automatically trigger the appropriate actions
and alerts.
Tivoli Compliance Insight Manager has the ability to archive normalized log data
for forensic review and to provide consolidated viewing and reporting through a
central dashboard. It also provides specific forensic capabilities for searching
and retrieving the original log data.
Tivoli Compliance Insight Manager uses the Generic Event Model (GEM) and the
W7 language to consolidate, normalize, and analyze vast amounts of user and
system activity. These models are discussed in further detail in “The W7 model”
on page 35. Tivoli Compliance Insight Manager is able to deliver alerts and
reports on who touched what information and how those actions may violate
external regulations or internal security policies. By revealing who touched what
within the organization and comparing that activity to an established internal
policy or external regulation defining appropriate use, security specialists can
successfully implement the first layer of defense for information protection,
thereby accelerating compliance efforts.
2.2 Product architecture
The Tivoli Compliance Insight Manager environment includes a number of key
components:
Enterprise Server
Standard Server
Actuators
Management Console
Web Portal (iView)
Figure 2-1 on page 15 illustrates the high level Tivoli Compliance Insight
Manager product architecture.
14 Deployment Guide Series: IBM Tivoli Compliance Insight Manager
29. · Archive audit trails
· Normalization of audit trails
· Archive security policies
· Preparation of reports
· Alerts and e-mail notification
Standard
Server
· Collection of audit trails
· Consolidation of statistics from multiple
· Collection of user information
databases
· Overall compliance checking
· Forensic search indexing Tivoli
· Administration of log archives
Enterprise Compliance Actuators
Server
Insight
Manager
Management · Tivoli Compliance Insight Manager
Web Portal network configuration
· Report viewing Console · Configuration of data for report
- Compliance preparation
- Event detail · Alert and e-mail notification
- Log management configuration
- Forensic search · Security policy violation definition
· Policy management using Policy Generator · Tivoli Compliance Insight Manager
· Scoping user management
Figure 2-1 Tivoli Compliance Insight Manager architecture
This section describes each of these components in the Tivoli Compliance
Insight Manager environment.
Chapter 2. Architecture and component structure 15
30. A note on naming: This IBM Redbooks publication covers Tivoli Compliance
Insight Manager V8.0. But when you look at the product manuals for this
release, you will not be able to locate the terms Standard Server and
Enterprise Server. What is happening in this situation?
In the coming releases of Tivoli Compliance Insight Manager, IBM Tivoli is
renaming the terms that are currently used in the product with the ones that
are being used in this book—and a new release is not far out. This is why we
decided to already use the new terms in our architecture discussion.
These terms can be mapped as follows:
Enterprise Server - Primary Server (in the manual)
Standard Server - Expansion Server (in the manual)
2.2.1 Tivoli Compliance Insight Manager cluster
An operational Tivoli Compliance Insight Manager cluster configuration is
comprised of one Enterprise Server and one or more Standard Servers.
The sections that follow outline the major functional capabilities of each of these
servers.
2.2.2 Tivoli Compliance Insight Manager Enterprise Server
The Tivoli Compliance Insight Manager Enterprise Server is a Windows®-based
server that provides centralized log management and forensic functions, allowing
these features to operate across multiple Tivoli Compliance Insight Manager
Standard Servers. As a general guide, we recommend monitoring up to three
Standard Servers per Enterprise Server.
Centralized log management
As shown in Figure 2-2 on page 17, the Enterprise Server offers consolidated log
management facilities over all connected Tivoli Compliance Insight Manager
Standard Servers. From one Enterprise Server, you can get a consolidated view
of log collections and log continuity. This simplifies the management of a Tivoli
Compliance Insight Manager cluster, reducing your operational impact as well as
providing a single view for auditors to examine the complete log history. Finally,
the centralized management feature provides a point of access to query and
download the original log data collected by standard servers.
16 Deployment Guide Series: IBM Tivoli Compliance Insight Manager
31. Figure 2-2 A Tivoli Compliance Insight Manager cluster environment
Centralized forensics
The Enterprise Server also provides forensic search capabilities. The Enterprise
Server allows you to search the archived logs for evidence without using the
GEM and W7 tools. Sometimes you may want to look for the raw traces without
going through the report preparation process.
Note: The GEM and W7 tools are used by Tivoli Compliance Insight Manager
for mapping and loading the data. They are described in detail in 2.3.2,
“Mapping and loading” on page 33.
Chapter 2. Architecture and component structure 17
32. 2.2.3 Tivoli Compliance Insight Manager Standard Server
Tivoli Compliance Insight Manager uses a centralized Windows-based server,
called the Standard Server, as the heart of its security audit and compliance
system. The Standard Server performs the following main functions:
Collects security logs from the audited event sources.
Archives the logs.
Normalizes the event data and loads it into the reporting databases.
Sends e-mail alerts when a high severity event is detected.
Creates reports.
The security status of the audited systems can be viewed through the
Web-based reporting application called iView. iView is described in 2.2.6, “iView
Web portal” on page 20.
Another main component of the Tivoli Compliance Insight Manager system is the
Management Console, which is used to manage and configure the system. Each
Standard Server has its own configuration database managed by the
Management Console. The Management Console is described further in 2.2.5,
“Management Console” on page 19.
To exchange information between its components, Tivoli Compliance Insight
Manager uses a virtual private network consisting of agents that maintain
encrypted communication channels. This network runs on the TCP/IP layer of the
existing organizational network.
2.2.4 Actuators
Depending on the platform, Actuator software is installed on audited systems as
a service or daemon. Each Actuator consists of an Agent and numerous
Actuator scripts. The Agent is responsible for maintaining a secure link with the
Agents running on the Tivoli Compliance Insight Manager Server and other
audited systems. The Actuator scripts are invoked by the Agent (at the request of
the Tivoli Compliance Insight Manager Server) to collect the log for a particular
event source. There is a different script for every supported event type. The
Actuator is depicted in Figure 2-3 on page 19.
18 Deployment Guide Series: IBM Tivoli Compliance Insight Manager
33. Actuator
Actuator
Scripts
Agent
Figure 2-3 Actuator software
The Actuator software can be installed locally on the target system or remotely.
We describe the log collection process in “Data collection using Actuators” on
page 26.
2.2.5 Management Console
The Management Console is responsible for the configuration and management
of the Enterprise Server and the Standard Server(s).
The Management Console can operate locally or in a distributed manner, as
shown in Figure 2-4 on page 20. All that is required for remote operation apart
from the Management Console itself is a local Point of Presence to which it can
communicate.
Note: A system that has a Tivoli Compliance Insight Manager Actuator
installed is referred to as a Point of Presence. “Data collection using
Actuators” on page 26 describes this concept in more detail.
Chapter 2. Architecture and component structure 19
34. Figure 2-4 Management Console component overview
You can use the Management Console to perform numerous tasks related to the
configuration and management of the Tivoli Compliance Insight Manager
servers:
Activate the Agents and have them collect audit trails from different platforms.
Define the security policy and attention rules.
Define users and their access rights.
Start the preparations of the reports.
All the actions on the Management Console are performed by the Tivoli
Compliance Insight Manager server. You can think of the Management Console
as being the user interface for the Tivoli Compliance Insight Manager server.
After the reports have been prepared by the server, a Tivoli Compliance Insight
Manager user may generate the specific reports using the iView component.
2.2.6 iView Web portal
The events found in the logs are normalized and stored in databases. The data in
the databases is available for further investigation through the Web-based tool
called iView. iView is a reporting application that Tivoli Compliance Insight
Manager administrators can use to generate specific reports on compliance level
and policy violations. It uses an HTTP-server, authorizing users to view reports
through their Web browser.
20 Deployment Guide Series: IBM Tivoli Compliance Insight Manager
35. 2.2.7 Databases
Tivoli Compliance Insight Manager supports and maintains a set of embedded
databases. These databases store the audit data from security logs and other
sources of event information, for example, Syslog. In the flow from collection to
archive, audit data is indexed and normalized to facilitate analysis, forensics,
information retrieval, and reporting.
An embedded database is also used to store configuration information about the
Tivoli Compliance Insight Manager environment itself.
Storing security audit data
Tivoli Compliance Insight Manager uses a file system based log repository as a
collection depot for the original security logs, and the embedded databases to
store normalized audit data, aggregated data, and consolidated data.
Depot
Collected logs are stored in the log Depot, which is a compressed, online, and
file system based log repository.
Reporting database
Data that has been mapped into the W7 format is stored in an instance of an
embedded database. These reporting databases are also known as GEM
databases. They are periodically emptied and then filled with more recent data.
Typically, this refresh cycle is done on a daily scheduled basis, meaning that data
from the previous period is present and available for analysis and reporting. Data
from a Depot can be mapped and manually loaded into the reporting database
for processing.
Aggregation database
The aggregation process takes a large number of individual events and
duplicates them into a more manageable set of information. In addition, the
aggregation process creates statistical data that can be used to provide
management level trending data, charts, and reports. It takes multiple events that
have a relationship and consolidates them into a single event. The aggregation
process involves two key operations:
A statistical database of events, exceptions, failures, and attentions is
created. The events are used to generate management charts, reports, and
trending information. For example, users can report on policy exception
trends over a selected time period.
Chapter 2. Architecture and component structure 21
36. It copies across the exceptions and attentions from the scheduled loads for
each database that is configured. This provides the user with significant
forensic capability. With these events in the same database as the statistical
events, it is possible to perform drill down operations into the data for
forensics, trending, and analysis.
Aggregation is performed as part of the normal scheduled load processing. After
a successful scheduled load, aggregation is performed for each reporting
database. Aggregation vastly reduces the amount of event information that
needs to be online, and allows users to have an organization view of security
events through iView (the Tivoli Compliance Insight Manager dashboard).
Additionally, these aggregated statistics are used for providing long-term
trending information and are typically held for several years (dictated by local or
statutory requirements). This is highly valuable data and provides a historical
database of an organization’s performance against defined security policies and
regulations.
Consolidation database
The consolidation database consolidates all the aggregation databases in a
Tivoli Compliance Insight Manager cluster. This provides an overall view of all
servers in the cluster for trending and statistical purposes.
Tivoli Compliance Insight Manager configuration data
The configuration data for the Tivoli Compliance Insight Manager environment
itself is also stored in embedded databases known as Configuration Databases.
Configuration Database
The Configuration Database for each Standard Server is managed through the
Management Console. Each Configuration Database includes information such
as the Actuator configuration, collect schedules, location of audit log data,
available GEM databases, the list of audited machines, and so on.
2.2.8 Component architecture
All of the components of Tivoli Compliance Insight Manager that have been
outlined so far work together to create a compliance management solution. Each
of the different components interact with one another and a number of processes
are performed by each of them.
Figure 2-5 on page 23 encapsulates the key components and processes in the
Tivoli Compliance Insight Manager environment. Each of the components and
the role that they play in the Tivoli Compliance Insight Manager environment will
be discussed in further detail throughout the remainder of the chapter.
22 Deployment Guide Series: IBM Tivoli Compliance Insight Manager
37. Figure 2-5 Tivoli Compliance Insight Manager architecture
2.3 Product processes
The Tivoli Compliance Insight Manager product runs several automated
processes. Together, these processes provide a complete solution from
collecting and analyzing logs to reporting and auditing activities for compliance.
Event data is retrieved from the audited systems through a process called
collect. It is then stored on the Standard Server in the Depot.
For analysis, the data is taken from the Depot and normalized into a data model
called General Event Model (GEM). This process is called mapping.
Subsequently, the mapped data is loaded into a reporting database called a
GEM database.
Chapter 2. Architecture and component structure 23
38. Data and statistics, spanning a longer period, are maintained by a process called
aggregation. The aggregation process builds a special database, called the
aggregation database, from which trends and summaries can be extracted.
In order to check and investigate the information security status, the Tivoli
Compliance Insight Manager system offers a large number of reports. These are
produced on request by a Web-based application called iView. It can be used to
view GEM databases as well as the aggregation database.
Figure 2-6 shows the key processes performed by a Tivoli Compliance Insight
Manager server. A Tivoli Compliance Insight Manager Enterprise Server also
performs two extra processes, namely indexing and consolidation.
Figure 2-6 Tivoli Compliance Insight Manager key processes flowchart
These key processes are described in further detail in this section.
24 Deployment Guide Series: IBM Tivoli Compliance Insight Manager
39. 2.3.1 Collection
Collection is the process of centralizing event data by retrieving it from the
audited machines and applications and archiving it in the Depot, the central
storage repository for log data on the Tivoli Compliance Insight Manager Server.
The reliable, verifiable collection of original log data is a key part of the process
required for compliance. Through Tivoli Compliance Insight Manager, you can
automate the collection process from your audited machines. Security audit data
is collected in its native form, transferred securely from the target, and stored in
the server’s Depot in the form of a chunk. The term chunk is used to refer to a set
of compressed logs and is the unit of collection in Tivoli Compliance Insight
Manager.
The Depot supports the consolidation function of Tivoli Compliance Insight
Manager and data remains there until it is explicitly backed up and removed. This
way log data is preserved for forensic analysis and investigations.
Tivoli Compliance Insight Manager provides a set of tools to verify that the
collection process is operating and to detect if collection failures have occurred.
Tivoli Compliance Insight Manager alerts selected administrators if a collection
failure occurs so that immediate action can be taken to prevent possible loss of
log data.
Tivoli Compliance Insight Manager provides specific reporting for administrators
and auditors to verify collections are occurring on schedule without problems. It
also allows you to verify that there is a continuous collection of logs available.
Tivoli Compliance Insight Manager can send alerts if the event data indicates
there is cause for concern and further investigation is needed. Finally, it is
possible to download selected logs from the Depot to a user’s local machine for
further analysis outside of Tivoli Compliance Insight Manager.
Methods of data collection
The most common mechanism for retrieving security log data is through a
process called batch collect. A security log is created on the audited machine by
the application, system, or device being audited. In general, such logs contain
records of many events, which all get processed as a batch. The Tivoli
Compliance Insight Manager Server initiates the collection of security logs from
the audited machines. This action is either triggered by a set schedule, or
manually through the Management Console. After receiving the security logs, the
Tivoli Compliance Insight Manager Server archives the security logs in the
Depot.
Chapter 2. Architecture and component structure 25
40. Event data is collected using a variety of methods to establish the consolidated
archive stored in the Depot. Events can be collected in numerous ways,
including:
Logs
Syslog
SNMP
NetBIOS
ODBC
External APIs
SSH
There are two methods of data collection:
1. Locally installed software (Actuator) on the target machine.
2. Agentless collection. This can be achieved by either:
a. A remote Actuator installation that allows you to collect the application
security log that is located on a different host machine.
b. The Tivoli Compliance Insight Manager server acting as a Point of
Presence to collect the data.
Data collection using Actuators
A typical Tivoli Compliance Insight Manager network consists of the Tivoli
Compliance Insight Manager Server and a number of host machines to be
audited. These host machines may be running one or more applications, each of
which can be audited by the Tivoli Compliance Insight Manager Server. These
host machines are often referred to as the audited systems.
The Tivoli Compliance Insight Manager Actuator is comprised of Agent software
and numerous Actuator scripts. Refer to Figure 2-3 on page 19 for a graphical
representation of this architecture. The Actuator is used to facilitate the data
collection process. The server where the Actuator is installed is referred to as a
Point of Presence (POP). It can collect and forward security logs for the operating
system, applications, databases, or devices on which it is installed. Every
application that generates security audit log data is referred to as an event
source.
Each event source that is monitored has an associated Actuator. For example,
the security log on a Sun™ Solaris™ server is collected by the Actuator for the
Solaris event source. The same server running Oracle® could use the same
Actuator to collect and monitor the Oracle security log. There is a different
Actuator script for every supported type of event, so the Actuator can process
26 Deployment Guide Series: IBM Tivoli Compliance Insight Manager
41. logs for several different event sources. In this example scenario, the Actuator is
collecting the logs from two event sources, namely “Solaris” and “Oracle for
Solaris”.
The Agent listens continuously on a reserved port for collect requests issued by
the Tivoli Compliance Insight Manager server. When a request is received, the
Agent invokes the appropriate script to gather the logs. After the Actuator has
collected the security audit log for a particular event source, the Agent
compresses and transfers the logs to the centralized Depot. The Agent maintains
an encrypted channel for all communication between the target machine and the
Tivoli Compliance Insight Manager server. That is, it provides a secure and
guaranteed transmission service.
Note:
1. The audited system often acts as the target system for event sources.
2. In regards to audit configurations, the audited system and the target
system can be described as the audited system, a system on which the
audited instance of the event source is hosted.
3. The Tivoli Compliance Insight Manager server can act as a Point of
Presence in some configurations. If this is the case, no Actuator needs to
be installed, because it is already included in the server installation.
Otherwise, an Actuator corresponding to the operating system running on
the Point of Presence needs to be installed.
For the examples throughout the remainder of this chapter, in the event that the
audited systems also act as the target systems for the Tivoli Compliance Insight
Manager server to access the audit trail, the term audited system will be used.
Chapter 2. Architecture and component structure 27
42. Agent collection mechanism
Figure 2-7 illustrates the steps involved in collecting data from an audited
system.
Figure 2-7 Agent data collection method
Note that:
1. The collection schedule is automatically triggered based on configured
settings. Alternatively, a manual collect command is given to the Tivoli
Compliance Insight Manager server through the Management Console.
2. The Tivoli Compliance Insight Manager server issues an audit trail
collect command to the Actuator. This command activates the Actuator on
the audited machine.
3. The appropriate Actuator script reads the security log and collects only those
new records since the last collection.
4. The Actuator formats the collected records into chunk format and compresses
the chunks. A chunk can contain many different log types from the audited
machine.
5. The Agent reads the chunk log data.
6. The Agent securely sends the chunk data in encrypted form to the Agent on
the Tivoli Compliance Insight Manager server.
28 Deployment Guide Series: IBM Tivoli Compliance Insight Manager
43. 7. The Agent on the server receives the chunk. The server application stores the
chunk in the Depot and archives the chunks by registering them in the
logmanager application and configuration database.
8. After successfully sending the chunks to the Tivoli Compliance Insight
Manager server, the Actuator deletes its local copy of the chunk. In additional,
on some platforms, you can also have the Actuator delete the original audit
trail.
Agentless collection
Tivoli Compliance Insight Manager supports agentless collection on Windows,
Novell, and UNIX® platforms. When using agentless remote collection, the
picture is slightly different than agent-based collection, but the steps remain the
same. This Point of Presence establishes the secure connection to the Tivoli
Compliance Insight Manager server, sending all agentless collected data
securely to the Depot.
Note: In the case of Windows, the agentless data collection requires one Point
of Presence per domain.
Agentless collection reduces the operational impact compared to an
agent-based approach. The SSH approach with UNIX provides a secure
connection; the NetBIOS approach used with Windows remote collection does
not provide a secure connection due to limitations inherent to the Windows
environment.
Chapter 2. Architecture and component structure 29
44. Windows agentless collection
The most common implementation of remote collection is on the Microsoft®
Windows domain. To audit several machines in a domain, only one of them
needs to be a Point of Presence and have an Actuator installed. Figure 2-8
shows the typical configuration used to perform an agentless collection when the
audited systems are Windows machines. Be aware, however, the agentless
collection method is not supported on all event sources.
Figure 2-8 Agentless data collection over NetBIOS
Note that:
1. The collection schedule is automatically triggered based on site specific
settings. Alternatively, a manual collect command is given to the Tivoli
Compliance Insight Manager server through the Management Console.
2. The Tivoli Compliance Insight Manager server issues a collect log
command to the Actuator. This command activates the Actuator on the target
machine.
3. The actuator reads the security log from the remote server(s) using a
NetBIOS connection, collecting only those new events since the last
collection cycle.
4. The log data is processed and sent to the Depot on the Tivoli Compliance
Insight Manager server.
UNIX agentless collection
Tivoli Compliance Insight Manager also supports agentless collection for UNIX
servers. It uses SSH to perform the collection so it is secure. The basic
configuration for a UNIX agentless collection is shown in Figure 2-9 on page 31.
30 Deployment Guide Series: IBM Tivoli Compliance Insight Manager
45. Figure 2-9 Agentless data collection over SSH
Tivoli Compliance Insight Manager uses a PuTTY client to establish the SSH
connection, which needs to be appropriately configured. The UNIX server also
needs to be running an SSH daemon, set up with the appropriate privileges, as
per the Tivoli Compliance Insight Manager documentation.
Ubiquitous log collection
Tivoli Compliance Insight Manager can collect logs from any source. In some
cases, no mapping or normalization will be available for a specific source, but
indexers can be built for forensic analysis of these logs.
Tivoli offers a toolkit that shows how to configure an event source to collect
arbitrary log data. This method allows the collection of log data that meets the
following criteria:
File based
Record oriented
Text
You can refer to the IBM Tivoli Compliance Insight Manager User Reference
Guide Version 8.0, SC23-6545 for further information about how to customize
ubiquitous collect event sources for forensic search and analysis.
Similar to the ubiquitous log collection, the W7LogSDK gives you the ability to
collect custom log files. Furthermore, the W7LogSDK allows you to map and load
the data. This toolkit is described in 2.4, “The W7LogSDK” on page 46.
Chapter 2. Architecture and component structure 31
46. IBM Services are available to assist with collecting logs from event sources that
are not automatically supported by Tivoli Compliance Insight Manager.
Syslog and SNMP collect
Tivoli Compliance Insight Manager can process and analyze security events that
are collected through the syslog and SNMP network logging mechanisms. The
support for syslog and SNMP messages is done either using a built-in
syslog/SNMP receiver or directly from a syslog-NG server. The Tivoli
Compliance Insight Manager Actuator has a built-in listening component that can
be activated on any Windows Point of Presence and can receive SNMP and
syslog messages. The collection of syslog messages captured by a syslog-NG
server is done through a Windows POP that collects the syslog files through
SSH.
Indexing and forensics
As previously mentioned, in a Tivoli Compliance Insight Manager cluster
environment, you have the forensic capability for in-depth investigation into your
raw log data.
When a chunk is placed in the Depot, it is indexed using the specific indexer that
has been configured for that event source. Indexers do not normalize the data,
only split it into fields. The fields, or terms, are indexed using a proprietary
technique so the data can be easily searched using the forensic investigation
user interface.
You can build your own indexers using the Generic Scanning Language (GSL)
Toolkit to include collected arbitrary log data in forensic investigations or in cases
where the default indexer does not provide the analysis required.
Through the user interface, you are able to search by:
Date
Event source
Field within that event source
A simple query language is available that supports Boolean operators (AND, OR)
and allows the grouping of terms through parentheses.
The forensic tools operate over all of the Standard Servers associated with the
Enterprise Server. They access the Depots through normal Windows file share
protocols.
Forensic analysis needs to happen once a problem is suspected or detected. It
can be carried out through the normal reporting databases very effectively.
However there are circumstances where this is not adequate, such as when
32 Deployment Guide Series: IBM Tivoli Compliance Insight Manager
47. specific log data that is not part of the W7 model needs to be searched and
correlated or where the criteria of the search is not practical for W7 analysis. For
such situations, Tivoli Compliance Insight Manager provides a forensic
investigation tool to search original unprocessed/non-normalized data in the
Depot. This allows searches to be carried out over many years worth of data
across a number of Standard Servers in a Tivoli Compliance Insight Manager
cluster.
2.3.2 Mapping and loading
Once log data has been centralized in the Depot, it can be processed and
analyzed. This process is shown in Figure 2-10.
Figure 2-10 Mapping and loading steps
Chapter 2. Architecture and component structure 33