Attachment 14105966 Design Guide PDF

Front cover
Draft Document for Review November 3, 2007 12:04 am
SG24-7530-00
Compliance Management
Design Guide
with IBM Tivoli Compliance Insight Manager
Enterprise integration for operational
and regulatory compliance
Complete architecture and
component discussion
Deployment scenario
with hands-on details
Axel Buecker
Ann-Louise Blair
Franc Cervan
Dr. Werner Filip
Scott Henley
Carsten Lorenz
Frank Muehlenbrock
Rudy Tan
ibm.com/redbooks
7530edno.fm
International Technical Support Organization

Compliance Management Design Guide with IBM
Tivoli Compliance Insight Manager
July 2007
SG24-7530-00
7530edno.fm
Note: Before using this information and the product it supports, read the information in
Notices on page ix.
First Edition (July 2007)

This edition applies to Version 8.0 of IBM Tivoli Compliance Insight Manager and Version 3.1 of
IBM Tivoli Security Operations Manager.
This document created or updated on November 3, 2007.
Copyright International Business Machines Corporation 2007. All rights reserved.

Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP
Schedule Contract with IBM Corp.
7530TOC.fm
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
The team that wrote this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
Comments welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
Part 1. Architecture and design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Chapter 1. Business context for compliance management . . . . . . . . . . . . 3
1.1 Introduction to compliance management . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Business drivers for compliance management . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Criteria of a compliance management solution . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Recent challenges for compliance management . . . . . . . . . . . . . . . . . . . 10
1.5 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Chapter 2. Architecting a compliance management solution . . . . . . . . . . 13
2.1 Security Information and Event Management architecture . . . . . . . . . . . . 14
2.2 IBM Tivoli SIEM solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.1 Event types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3 Solution architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.1 Projecting a security compliance solution . . . . . . . . . . . . . . . . . . . . . 21
2.3.2 Definition of a security compliance solution . . . . . . . . . . . . . . . . . . . 21
2.3.3 Design of a security compliance solution . . . . . . . . . . . . . . . . . . . . . 23
2.4 IBM Tivoli compliance tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Chapter 3. IBM Tivoli Compliance Insight Manager component structure27
3.1 Product overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2 Product architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.1 Tivoli Compliance Insight Manager cluster . . . . . . . . . . . . . . . . . . . . 30
3.2.2 Tivoli Compliance Insight Manager Enterprise Server . . . . . . . . . . . 30
3.2.3 Tivoli Compliance Insight Manager Standard Server . . . . . . . . . . . . 32
3.2.4 Actuators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.5 Management Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2.6 iView Web portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2.7 Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.8 Component architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Copyright IBM Corp. 2007. All rights reserved.
iii
7530TOC.fm
3.3 Product processes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.3.1 Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3.2 Mapping and loading. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3.3 Data aggregation and consolidation . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.3.4 Reporting and presentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.4 The W7LogSDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.4.1 How the W7LogSDK works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.4.2 Event attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.4.3 W7LogSDK CSV format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.4.4 W7LogSDK XML format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.4.5 Validators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.5 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Chapter 4. Compliance management solution design. . . . . . . . . . . . . . . . 73
4.1 Functional design and configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.1.1 Discovery and analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.1.2 Project definition and planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.1.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.1.4 Product use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.2 Operational design and configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.2.1 Monitoring and maintenance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.2.2 Archiving and information retention. . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.2.3 Performance and scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.2.4 Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.3 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Chapter 5. IBM Security Information and Event Management . . . . . . . . 103
5.1 Security Information and Event Management . . . . . . . . . . . . . . . . . . . . . 104
5.2 Introducing IBMs SIEM solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.3 The SIEM architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.3.1 Event collection and retention of records . . . . . . . . . . . . . . . . . . . . 108
5.3.2 Monitoring and correlation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
5.3.3 Logging standards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
5.4 IBM Tivoli Security Operations Manager . . . . . . . . . . . . . . . . . . . . . . . . . 113
5.4.1 Product overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
5.4.2 Centralize log aggregation in multivendor environments . . . . . . . . 114
5.4.3 Improve incident detection by correlating across devices . . . . . . . . 115
5.4.4 Reduce incident mitigation time . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
5.4.5 Improve efficiency through operational integration . . . . . . . . . . . . . 116
5.4.6 Deepen understanding through comprehensive reporting . . . . . . . 116
5.4.7 Multiple deployment options to suit your environment . . . . . . . . . . 117
5.4.8 Provide a platform for offering managed security services . . . . . . . 117
5.4.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
iv
Compliance Management Design Guide with IBM Tivoli Compliance Insight Manager
7530TOC.fm
5.5 Tivoli Compliance Insight Manager and Tivoli Security Operations Manager
complement each other . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
5.5.1 Different groups have differing requirements . . . . . . . . . . . . . . . . . 118
5.5.2 The combined strength . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
5.5.3 SIEM integration scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
5.6 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Part 2. Customer environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Chapter 6. Introducing Tivoli Financial Accounting Corporation. . . . . . 129
6.1 Company profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
6.2 Current IT infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
6.3 Security compliance business objectives . . . . . . . . . . . . . . . . . . . . . . . . 133
6.3.1 Comply to security requirements in the industry . . . . . . . . . . . . . . . 134
6.3.2 Maintain and demonstrate management control. . . . . . . . . . . . . . . 134
6.3.3 Integrate monitoring across a multi-platform environment . . . . . . . 134
6.3.4 Harvest and structure information to specific needs . . . . . . . . . . . . 135
6.3.5 Establish a cost efficient and future proofed solution . . . . . . . . . . . 136
6.4 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Chapter 7. Compliance management design . . . . . . . . . . . . . . . . . . . . . . 137
7.1 Business requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
7.2 Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
7.3 Design approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
7.4 Implementation approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
7.4.1 Determine what reports need to be generated . . . . . . . . . . . . . . . . 148
7.4.2 Monitoring target assets for reports . . . . . . . . . . . . . . . . . . . . . . . . 149
7.4.3 Identify what data needs to be collected from each event source . 151
7.4.4 Ensure that Tivoli Compliance Insight Manager has the ability to monitor
audit trails from that event source. . . . . . . . . . . . . . . . . . . . . . . . . . 151
7.4.5 Prioritize the target systems and applications . . . . . . . . . . . . . . . . . 152
7.4.6 Planning deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
7.4.7 Divide the tasks into phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
7.5 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Chapter 8. Basic auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
8.1 Phase one auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
8.2 Install Tivoli Compliance Insight Manager cluster . . . . . . . . . . . . . . . . . . 159
8.2.1 Install Enterprise Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
8.2.2 Install Standard Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
8.3 Phase one reporting requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
8.4 Enabling and configuring auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
8.4.1 Auditing settings for the Windows Security log . . . . . . . . . . . . . . . . 161
8.4.2 Active Directory audit policy settings. . . . . . . . . . . . . . . . . . . . . . . . 162
Contents
7530TOC.fm
8.4.3 File server settings - object access auditing . . . . . . . . . . . . . . . . . . 165

8.5 Configuring Standard Server for new event sources. . . . . . . . . . . . . . . . 171
8.5.1 Create GEM database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
8.5.2 Create system group and add Windows machines . . . . . . . . . . . . . 172
8.5.3 Add event sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
8.6 Installing an Actuator on target machine . . . . . . . . . . . . . . . . . . . . . . . . . 185
8.7 Configuring W7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
8.7.1 Configuring a new policy with W7 rules . . . . . . . . . . . . . . . . . . . . . 202
8.8 iView Compliance Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
8.8.1 Policy Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
8.8.2 Special Attentions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
8.8.3 Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
8.9 Self audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
8.10 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Chapter 9. Extending auditing to other platforms . . . . . . . . . . . . . . . . . . 243
9.1 IT environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
9.2 Basic approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
9.3 Auditing AIX 5.3 systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
9.3.1 Configure auditing for AIX systems . . . . . . . . . . . . . . . . . . . . . . . . . 245
9.3.2 Adding the AIX event source to Tivoli Compliance Insight Manager250
9.3.3 The results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
9.3.4 AIX auditing conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
9.4 Auditing Domino R6 systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
9.4.1 Configuring auditing for Domino systems . . . . . . . . . . . . . . . . . . . . 262
9.4.2 Adding the Domino event source . . . . . . . . . . . . . . . . . . . . . . . . . . 262
9.4.3 The results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
9.4.4 Domino R6 auditing conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
9.5 Auditing Oracle 10g systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
9.5.1 Configuring auditing for Oracle 10g systems . . . . . . . . . . . . . . . . . 272
9.5.2 Adding the Oracle 10g event source. . . . . . . . . . . . . . . . . . . . . . . . 274
9.5.3 The results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
9.5.4 Oracle 10g auditing conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
9.6 Auditing SAP system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
9.6.1 Configuring auditing for SAP systems. . . . . . . . . . . . . . . . . . . . . . . 279
9.6.2 Adding the SAP event source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
9.6.3 The results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
9.6.4 SAP R/3 auditing conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
9.7 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Chapter 10. Customized and regulatory reporting. . . . . . . . . . . . . . . . . . 289
10.1 Producing customized reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
10.1.1 Creating a customized report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
vi
7530TOC.fm
10.1.2 Distributing reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

10.2 Using compliance management modules . . . . . . . . . . . . . . . . . . . . . . . 302
10.2.1 Tool-based regulatory compliance reporting . . . . . . . . . . . . . . . . . 303
10.2.2 Running compliance reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
10.3 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Chapter 11. System Z integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
11.1 Reporting requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
11.2 Audit settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
11.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
11.3.1 Standard Server implementation. . . . . . . . . . . . . . . . . . . . . . . . . . 315
11.3.2 Actuator implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
11.3.3 Basel II compliance management module implementation . . . . . . 345
11.4 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
Chapter 12. Tivoli Security Operations Manager integration . . . . . . . . . 371
12.1 Reasons for integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
12.2 Integrating Tivoli Security Operations Manager to Tivoli Compliance Insight
Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
12.2.1 General integration approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
12.2.2 Applying the Tivoli Compliance Insight Manager event taxonomy 374
12.2.3 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
12.2.4 The Tivoli Compliance Insight Manager Audit Logger script . . . . . 376
12.2.5 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
12.3 Additional Tivoli Security Operations Manager incidents . . . . . . . . . . . 400
12.3.1 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
12.3.2 Worm detection events to Tivoli Compliance Insight Manager401
12.3.3 Policy violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
12.3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
12.4 Use Tivoli Compliance Insight Manager for log management of Tivoli
Security Operations Manager collected syslog data . . . . . . . . . . . . . . . 410
12.4.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
12.4.2 Basic approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
12.4.3 Our EAM syslog-ng configuration . . . . . . . . . . . . . . . . . . . . . . . . . 411
12.4.4 Setting up SSH users for Tivoli Compliance Insight Manager . . . 412
12.4.5 Modify syslog-ng.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
12.4.6 Adding the remote SSH based event source . . . . . . . . . . . . . . . . 414
12.4.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
12.5 Tivoli Compliance Insight Manager attention alerts to Tivoli Security
Operations Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
12.5.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
12.5.2 Basic approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
12.5.3 Configure Tivoli Compliance Insight Manager attention alerts . . . 425
Contents
vii
7530TOC.fm
12.5.4 Configure Tivoli Security Operations Manager to process custom alerts

428
12.5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
12.6 Single audit portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
12.7 Laying down standard policy on Tivoli Security Operations Manager data .
438
12.7.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
12.8 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
Appendix A. Corporate policy and standards . . . . . . . . . . . . . . . . . . . . . 447
Standards, practices, and procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
Practical example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
External standards and certifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
Industry specific requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
Product or solution certifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
Nationally and internationally recognized standards . . . . . . . . . . . . . . . . . 453
Data Privacy Laws . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
How to get Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
viii
7530spec.fm
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area.
Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product, program, or service that
does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not give you any license to these patents. You can send license
inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at
any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on
the capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrate programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs.
ix
7530spec.fm
Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
Redbooks (logo)
developerWorks
z/OS
AIX 5L
AIX
CICS
Domino
DB2
IBM
Lotus Notes
Lotus
MVS
Notes
OS/390
Redbooks
RACF
SOM
Tivoli Enterprise
Tivoli Enterprise Console
Tivoli
WebSphere
The following terms are trademarks of other companies:

SAP R/3, SAP, and SAP logos are trademarks or registered trademarks of SAP AG in Germany and in
several other countries.
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.
Java, Solaris, Streamline, 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.
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.
7530pref.fm
Preface
In order to comply with government and industry regulations such as Sarbanes
Oxley, Gramm-Leach-Bliley and COBIT, enterprises have to constantly detect,
validate, and report unauthorized change and out-of-compliance actions within
their IT infrastructure.
The IBM Tivoli Compliance Insight Manager solution allows organizations to
improve the security of their information systems by capturing comprehensive log
data, correlating this data through sophisticated log interpretation and
normalization, and communicating results through a dashboard and full set of
audit and compliance reporting.
We discuss the business context of security audit and compliance software for
enterprises, and describe the logical and physical components of Tivoli
Compliance Insight Manager. Finally, within a business scenario we discuss a
typical deployment.
This book is a valuable resource for security officers, administrators, and
architects who wish to understand and implement a centralized security audit
and compliance solution.
The team that wrote this book

This book was produced by a team of specialists from around the world working
at the International Technical Support Organization, Austin Center.
Axel Buecker is a Certified Consulting Software IT Specialist at the International
Technical Support Organization, Austin Center. He writes extensively and
teaches IBM classes worldwide on areas of Software Security Architecture and
Network Computing Technologies. He holds a degree in computer science from
the University of Bremen, Germany. He has 21 years of experience in a variety of
areas related to Workstation and Systems Management, Network Computing,
and e-business Solutions. Before joining the ITSO in March 2000, Axel worked
for IBM in Germany as a Senior IT Specialist in Software Security Architecture.
Ann-Louise Blair is a Software Engineer in the IBM Australia Development
Laboratory. She has 4 years of experience working in the IT industry and holds a
Bachelor of Software Engineering (Hons1) degree from the University of
Queensland. Having worked in both testing and development roles in the Gold
Coast Integration Factory team, Ann-Louise has gained expertise working with
xi
7530pref.fm
many Tivoli software products. Her main focus for the past two years has been
developing data integration solutions using IBM Tivoli Directory Integrator.
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 area of expertise are Tivoli Security and Automation products.
Dr. Werner Filip is a professor of the department for 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 University of Applied
Sciences Frankfurt he worked for 25 years for IBM in various positions, during
his last 10 years with IBM as a Consultant in Systems and Network Management
at former IBMs 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. As such he
is an expert in many of the IBM Tivoli Security products and in recent years has
specialized in the Security Information and Event Management space. His
current role at IBM as an above country expert for the Asia Pacific region means
that he is often travelling thoughout the Asia and Pacific region speaking with
and assisting IBM customers to 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 Bachelor 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 cerified Senior Managing Consultant at IBM in Germany.
He manages security solutioning in large and complex IT infrastructure
outsourcing engagements for customers throughout Europe, Middle-East and
Africa. He has more than 8 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 Bachelor
Degree in European Studies from Univeristy of Wolverhamption, UK, and a
Diploma in Business Science from University of Trier, Germany.
Frank Muehlenbrock is an IBM Information Security Manager. After having
supported pre-sales andservices activities in Germany for the Tivoli Security
xii
7530pref.fm
Compliance Manager he has specialized in the recent years in implementing,

managing and maintaining security policies, standards and guidelines. In this
current role he manages the Information Security for a large global outsourcing
customer of IBM with involved countries in EMEA and North America. Frank
studied Information Management at the Fachhochschule Reutlingen, Germany.
He is an accredited Security Architect and also holdes the CISM certification
(Certified Information Security Manager). He also holds several other industry
certifications which he achieved during his 20 years experience in the
information technology industry.
Rudy Tan is a Senior IT-Specialist and he 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 was working 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 Compliance Management Design Guide with IBM Tivoli
Compliance Insight Manager this great team also developed the Deployment
Guide Series: IBM Tivoli Compliance Insight Manager, SG24-7531.
Thanks to the following people for their contributions to this project:
Preface
xiii
7530pref.fm
??????????
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 in one of the following ways:
Use the online Contact us review Redbooks 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
xiv
7530p01.fm
Part 1
Part
Architecture and
design
In this part we discuss the overall business context for security compliance
management of IT systems and explain the general business requirements for a
security compliance management solution.
Then a framework for providing security compliance functionality throughout an
organization is described. In addition to this we introduce the high-level
components and new concepts for the design of a compliance management
solution using IBM Tivoli Compliance Insight Manager.
Additionally, an understanding of the high level product architecture of Tivoli
Compliance Insight Manager is provided.
At the end of this part we introduce you to the IBM Security Information and
Event Management solution.
7530p01.fm
7530ch01.fm
Chapter 1.
Business context for

compliance management
In this chapter, we discuss the overall business context for security compliance
management of IT systems. After a short definition of the necessary terms we
describe the factors that influence why and how compliance management should
be conducted in a given business context.
Further, we explain the general business requirements for a security compliance
management solution.
7530ch01.fm
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, 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 a 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 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 management direction on
1
The Sarbanes-Oxley Act was established in 2002, results from 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 find more information check out this URL:
http://www.soxlaw.com/
The Basel II is an accord issued by the Basel Committee on Banking Supervision and summarized
recommendations on banking laws and regulations with the intent to harmonize banking regulation
worldwide. This second accord introduces matters around Operational Risk, which again includes
risks in the area of technology, processes and people. To find more information check out this URL:
http://www.bis.org/publ/bcbsca.htm
7530ch01.fm
information security. Some more information on this discussion can be found in

Appendix A, Corporate policy and standards on page 447.
Bringing both definitions together, security compliance is understood as the
process that safeguards 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, to analyze, to
consolidate, and to 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 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, todays economy relies on information as a fourth factor
of production. Due to the large amount, frequent update and fast aging of
Chapter 1. Business context for compliance management
7530ch01.fm
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
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 focusses 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 on-going
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 for
organizations to stay in business and to 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 customers 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
3
4
For more information on HIPAA check out this URL: http://www.hhs.gov/ocr/hipaa/

For more information on PCI check out this URL: https://www.pcisecuritystandards.org/
7530ch01.fm
determines how much money a bank can use to provide credits to their
customers and how much it has to keep in reserve to cover for risks, which again
affects the interest rates a bank can offer its customers. So today, even the
external regulation itself develops further from a basic approach of compliance
vs. non-compliance towards approaches in the area of level of control vs.
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 more and more shift from compliance to
control objectives.
Most organizations do not stop after they have met the basic principles set out in
their policies, 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.
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.
7530ch01.fm
Selection of security controls

... is the intention to check technical security controls and security controls in
processes and on the organizational level.
Spot check vs. duration check
... is the intention to check the security configuration of systems, of network
devices and/or 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).
Number of security controls
... 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, middle ware, and
business applications need to be supported?
Frequency of checks
... 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
... defines how fast reported deviations must be fixed.
Scope of compliance checking
... 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
... is concerned with 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 and/or even towards specific
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 pre-defined time frame, or
continuous (despite the checks still being performed non-continuously). The
latter is often referred to as dashboard.
7530ch01.fm
Level of automation
... is concerned with a compliance management solution relying on
automated checks, which requires higher investments in technology, or on
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 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 with influence on 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. Further, 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, middle ware, and business applications that need to be supported by
any IT security compliance management solution. Also, the level of
standardization, centralization and consolidation has significant influence on
the IT security compliance management solution.
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 which meet the security control
requirements on a given platform, as well as descriptions about how to
7530ch01.fm
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
bears 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 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 todays more complex applications and moves
toward service oriented architectures (SOA) take operations management to
new levels of complexity.
Complexity of the compliance criteria
Further, checking the security controls of managed systems ensures that a
system does not degrade in its security controls posture due to changes on
the system after it has been installed. For example, changes made while
resolving a problem, while installing or upgrading a new application or middle
ware, or due to an attacker changing the configuration to hide his tracks or to
compromise the system.
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
labour 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:
10
7530ch01.fm
Organizations want to be able to react on 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, organizations want to 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 incompliant over
time, but it is the actions of people on and to IT systems that can cause
non-compliance accidentally or on purpose.
Shifting the focus from resulting status to evoking pro 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 that the organization spends more time for
managing compliance than for its primary objectives.
The proceeding of this book discusses the implementation of such an automated
solution based on the IBM Tivoli Compliance Insight Manager as well as other
supporting technologies and products.
11
7530ch01.fm
12
7530ch02.fm
Chapter 2.
Architecting a compliance
management solution
An architecture is designed to be strategicit is meant to have a longer life than
a blue print, design specification, or a topological map or configuration. If it is too
specific, it becomes constrained by current circumstances. If it is too broad or
general, it cannot provide direction and guidance. It is meant to assist in making
decisions related to the identification, selection, acquisition, design,
implementation, deployment, and operation of security elements in an
organizations environment.
An architecture also has to support many communities and represent the
long-term view of a technical direction. Security compliance architectures in
particular need to allow for multiple implementations depending on the realities
of the moment, and caution should be exercised to prevent the security
compliance architecture from becoming a blueprint for a specific implementation.
In this chapter we describe a framework for providing security compliance
functionality throughout the organization. A security compliance architecture
must be flexible and open in order to deal with the ever changing environments
an organization may face in the future. The primary factors that require a
modification to an architecture are:
A change to the requirements in the regulatory environment in which the
organization operates.
13
7530ch02.fm
A change to the requirements of the organizational and process environment.

A change to the technology environment requirements.
The above mentioned points are intentionally described in this order. Although all
three issues could arise independently, either internally or externally, a change to
the regulatory requirements will always have an impact on organizational and
process requirements as well as the technology environment.
To adapt to the ever changing environments a security compliance architecture
should not only focus on event sources of compliance information, like collection
points (databases), data processing, and reporting, it also has to consider
different event types like settings, people events, and network events.
2.1 Security Information and Event Management

architecture
Security Information and Event Management, abbreviated as SIEM, helps an
organization to gather security data from many different information systems.
The volume of security log data is growing over time with more and more
systems being connected to an organizations infrastructure. Having all that
information in a centralized storage helps an organization to better analyze the
data and respond to auditors requests during reviews and audits.
Many market organizations complain about three major problems they cannot
completely, or even partially, fulfill:
1. Demonstrating compliance to regulatory requirements
2. Ensuring appropriate protection of intellectual capital and privacy information
3. Being able to manage security operations securely and effectively
A SIEM system collects data from log files and alerts from a variety of
infrastructure components like firewalls, routers, anti-virus systems, servers, and
many more. It informs IT teams about unusual behavior on these systems, and
these teams can then decide whether and what kind of further investigation
needs to be taken.
A Security Information and Event Management (SIEM) architecture can be
broken down into two elements, Security Information Management (SIM) and
Security Event Management (SEM).
The SIM component provides reporting and analysis of data primarily from host
systems and applications, and secondarily from security devices to support
regulatory compliance initiatives, internal threat management, and security policy
14
7530ch02.fm
compliance management. It can be used to support the activities of the IT

security, internal audit, and compliance organizations.
The SEM component improves security incident response capabilities. It
processes near-real-time data from security devices, network devices, and
systems to provide real-time event management for security operations. It helps
IT security operations personnel be more effective in responding to external and
internal threats.
A SIEM solution needs to provide log data capturing capabilities. Aggregated
information has to be securely stored. Also, archived data faces the requirement
of having to reside in a database format that allows for accurate and expedient
reporting and viewing capabilities.
Figure 2-1 on page 16 depicts a typical Security Information And Event
Management architecture. In the bottom third of the figure it shows the very basic
event collection and record retention capabilities. This retained data is then used
for monitoring and correlation tasks (middle part of the figure). In the top third of
the figure you see that the analyzed data can be reported in either security
information driven or security event driven reports. More details about the SIEM
architecture can be found in 5.3, The SIEM architecture on page 107.
Chapter 2. Architecting a compliance management solution
15
7530ch02.fm
Security Event
Management Reporting
e
nc
lia d
mp oar
Co shb
Da
S
Da ecur
sh ity
bo
ard
Security Information
Management Reporting
Monitoring
Correlation
Forensics
Reports
ol
ntr
Co
an
ce
Alerts
Co
mp
li
Advanced Analytics
Rule Based Correlation

Configuration
Logging
Policy Based Correlation

Event
Collection
Collection & Record Retention
Information & Event Source

Devices
OS
Application
DBMS
Mainframe
Figure 2-1 The SIEM architecture
In Gartners1 research paper Magic Quadrant for Security Information and Event
Management, 1Q07 you find an industry wide standard definition of SIEM:
16
Magic Quadrant for Security Information and Event management, 1Q07, publication date 9 May
2007, ID number G00147559.
7530ch02.fm
Market definition/description:
The SIEM market is driven by customer needs to analyze security event data
in real time (for threat management, primarily focused on network events) and
to analyze and report on log data (for security policy compliance monitoring,
primarily focused on host and application events). SIM provides reporting and
analysis of data primarily from host systems and applications, and secondarily
from security devicesto support security policy compliance management,
internal threat management and regulatory compliance initiatives. SIM
supports the monitoring and incident management activities of the IT security
organization, and supports the reporting needs of the internal audit and
compliance organizations. SEM improves security incident response
capabilities. SEM processes near-real-time data from security devices,
network devices and systems to provide real-time event management for
security operations. SEM helps IT security operations personnel be more
effective in responding to external and internal threats.
With SIEM in place all problems in the previous numeration can be mitigated.
The benefits of SIEM are also clear: More effective security management and
compliance with regulatory requirements. Side effects like rapid return of
investment and ongoing savings on equipment and manpower are not addressed
here, but are also valid business reasons to implement a SIEM architecture.
2.2 IBM Tivoli SIEM solution

During the last years the working environment became more and more
challenging. The number of external audits and internal reviews for compliance
have increased rapidly. With each of these reviews resources are bound to reply
to the auditors. Intellectual property protection from insiders, outsourcers and
hackers has become difficult more than ever. Also, the management of security
operations needs to be done in a very comply environment. With an IBM Tivoli
SIEM solution you should be able to:
Demonstrate compliance with regulations
Protect intellectual property and ensure privacy properly
Manage security operations effectively and efficiently
A SIEM architecture should combine people and technology. What do people do
across an enterprises applications, databases, operating systems, security and
network devices?
17
7530ch02.fm
To install the full breadth of IBMs SIEM capabilities, a combination of the IBM
Tivoli Security Operations Manager (TSOM) real-time correlation and operational
dashboard, and the IBM Tivoli Compliance Insight Managers (TCIM) user
monitoring, compliance dashboard and regulatory compliance reporting should
be used. Real time threat and infrastructure event sources are directed to Tivoli
Security Operations Manager for real time correlation and infrastructure controls
monitoring, while internal user focused log sources are sent to the Tivoli
Compliance Insight Manager log management system and infrastructure.
The following figure shows how an IBM SIEM solution can look like if both
Compliance Insight Manager and Security Operations Manager technologies are
used for security compliance solutions.
Figure 2-2 Tivoli Security Operations Manager and Tivoli Compliance Insight Manager as
part of a SIEM solution
Organizations may envision some event sources to be monitored by both

components. For example, server operating system logs are of interest for
real-time threat management to get a more complete picture of attempted
compromises like failed login attempts. They are also core to user monitoring.
IBMs SIEM architecture can meet this requirement in one of several ways,
including having the hosts send SYSLOG based events to a single collector,
which forwards the data to both security engines for correlation (see Tivoli
Compliance Insight Manager Standard Servers and Tivoli Security Operations
Manager EAMs), or the event sources can be directed to be sent to two locations
18
7530ch02.fm
directly from the device. For a significant majority of deployment scenarios, the
IBM SIEM architecture is able to collect log or event data only once and make
effective use of that information within both Tivoli Security Operations Manager
and Tivoli Compliance Insight Manager technologies.
Bi-directional correlated events are also being integrated between Standard
Servers of Tivoli Compliance Insight Manager and Tivoli Security Operations
Manager CMS Servers (see Figure 2-2).
2.2.1 Event types

Generally it can be said that there are three different kinds of event types that
must be monitored in order to be and stay fully compliant.
1. Settings, policies and standards
2. People related events
3. Device related events
Examples of events logged include but are not limited to the following:
All successful and failed sign-on attempts.
All successful and failed attempts to access sensitive resources.
Rejected access attempts to all resources.
Use of privileged user-ids.
User-ids with system privileges allocated.
All changes in the access control system carried out an administrator
All access attempts to databases storing definitions, passwords, and so on
belonging to the access control system.
Settings, policies and standards

Every organization needs to provide documentation to its employees that clearly
state the guidelines on how to use the organizations IT systems. This
documentation usually is referred to as the Information Security Policy. It can
also communicate to the employees what is prohibited or which mandatory
processes are to be followed. There is a variety of interpretations of policies,
standards, procedures (working instructions) or guidelines. In this book we
concentrate on policies and standards. But how do they relate and what exactly
do they mean. Well, now is the time to have a closer look.
Security policies are defined by the executive board and provide a clearly stated
security direction for the overall organization. They can also be named the
security constitution.
19
7530ch02.fm
Security standards are the next level of security rules adherence. Security
standards are metrics that define allowable boundaries. A standard must provide
sufficient parameters that a procedure or guideline can unambiguously be met.
Standards, in comparison to policies, will change if requirements or technologies
change. Policies will rather remain static. There may be multiple standards for
one policy. More discussion on this topic can be found in 1.1, Introduction to
compliance management on page 4 and Appendix A, Corporate policy and
standards on page 447.
A good example of a standard would be the password rules. This standard
documents the allowed minimum password length, the maximum password age
or whether a new user needs to change his/her password after the first access.
When talking about standards it is clear that security compliance in larger
organizations cannot be maintained manually. How could this be accomplished
for hundreds or even thousands of IT systems with different operaing
environments, database servers, Internet facing systems and more? IBM Tivoli
Security Compliance Manager helps you to check on your security compliance
automatically. For more details refer to IBM Tivoli Security Compliance
Manager on page 24.
People related events

IT security compliance can only be accomplished if the people working within the
IT environment adhere to the above mentioned policies. Roles and
responsibilities need to be identified within the environment defining who uses
what resources, and how are they using the resources. Another defining
parameter needs to specify what activities are performed within the IT
environment. These roles can vary from privileged administrative tasks,
database administration, or just accessing a specific file on a file share. There
have to be defined roles and responsibilities documented within the IT
environment.
Why is user related behavior such an issue? Almost every publicly provided
analysis about internal incidents shows that most of the problems are caused by
the technically savvy or privileged users of an organization. The numbers vary
from 70% to 90%. This clearly shows that the highest risk comes from inside an
organization. Many of these incidents are inadvertent violations of a change
management process or acceptable use policy. But there are also incidents that
are deliberate due to revenge or negative events like demotions or mergers.
Regardless of the why, the issue is too costly to ignore. Experts, analysts,
auditors, and regulators are imploring organizations to start monitoring for this
threat.
20
7530ch02.fm
Device related events

You must have a complete overview of your current IT environment that both the
assets and users operate in. In this context we talk about the technology
environment in which the solution is implemented. You have to consider the type
of devices that people work with, and you have to ensure that these devices are
compliant in accordance with enterprise policies.
Event data from various network security devices are required and then need to
be normalized, filtered, and transmitted to a centralized management system.
2.3 Solution architecture

In this section we discuss the solution architecture for Security Information and
Event Management. Basically, there are three steps to run through:
1. Projecting a security compliance solution
2. Definition of a security compliance solution
3. Design of a security compliance solution
These three steps are explained in the following sections.
2.3.1 Projecting a 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). We restrict our discussion to the technical tasks associated with the
production of the architecture and design document. For redundancy reasons we
do not explain the different project phases in this section. Please refer to our
detailed explanation of the different project phases for deploying a security
compliance solution in our scenario in Chapter 4, Compliance management
solution design on page 73.
2.3.2 Definition of a security compliance solution

The project definition and planning phase documents the project in detailed
steps. It involves the following tasks:
Analyze the existing environment.
Describe the problem at hand.
Document the detailed requirements for the solution.
21
7530ch02.fm
The initial project definition is based on the documentation that triggered the
project, such as the IT architecture, security architecture, request for proposal
(RFP) or equivalent. All of these documents identify the business background
and the business need for the solution. They also document the business and
technical requirements for the solution. For a security compliance solution, the
following (unordered) areas need to be defined in this phase:
Regulatory requirements
What are the regulatory requirements the organization has to adhere to? For
example, is the enterprise listed at the New York Stock Exchange (NYSE)? If
that is the case it needs to be compliant to the Sarbanes-Oxley Act (SOX).
Other regulatory requirements apply depending on the industry the
organization is operating in.
Security policies
What does the corporate security policy define for users, accounts,
passwords, access control, and so on? It is important to follow the
organizations 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 that have to be monitored? Examples are
privileged users, database administrators, executives, and so on.
Target systems: What are the components in your system environment
that have to be monitored? Examples include operating systems,
databases, applications, the network, firewalls, physical locations, and so
on.
Reports
In order to constantly demonstrate evidence of compliance it is mandatory to
show compliance reports.
Processes
Although we are purely focusing on designing a security compliance solution,
the outcome of architecting such a solution does not only result in a technical
toolset and an infrastructure that has to be implemented. In order to create a
comprehensive solution supporting processes must be developed and put
into production. Examples of such processes are:
Patch management process
User identity revalidation process
Problem and change management process
Incident management process
22
7530ch02.fm
There are many more processes that could be added to this list. Basically, for
every IT related tasks you need to have a process in place.
2.3.3 Design of a 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.
As communication is its main purpose, 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 already addressed in Chapter 1,
Business context for compliance management on page 3):
At the organizational level
At the system level
At the process level
At an organizational level, a design diagram is often produced as part of an
overall IT strategy. In this instance it is used to describe the vision of the
business and IT capabilities 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 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 have been developed and validated.
The last level is the process level. This document will most likely not be ready
before the solution is deployed. Only then is it possible to identify, develop, and
implement the processes that are needed in order 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 4, Compliance management solution design on page 73 describes the
design of a security management solution in depth.
23
7530ch02.fm
2.4 IBM Tivoli compliance tools

In this paragraph we describe the IBM Tivoli products available to monitor and
maintain security compliance.
IBM Tivoli Security Compliance Manager

Tivoli Security Compliance Manager is a centralized repository for archiving
native audit trails in order to observe and report on security compliance policies
(do not mistake this with the above mentioned enterprise policy). Tivoli Security
Compliance Manager deploys predefined policies onto managed systems and
provides a central repository for automated reporting purposes and data mining.
The architecture of the Tivoli Security Compliance Manager is based on a
client/server model. The Tivoli Security Compliance Manager client acts as an
agent that collects data from the client subsystem on a predefined schedule or
on request of the Tivoli Security Compliance Manager server. After the data has
been collected by the client it is being sent to the server.
Let us take a look at the activities performed by server and client:
Tivoli Security Compliance Manager server
Tivoli Security Compliance Manager provides an interface for defining
policies that specify the conditions that should exist on a client. On the
Tivoli Security Compliance Manager server you schedule when the
security compliance data is collected on the clients and which clients
collect what kind of data.
The Tivoli Security Compliance Manager server stores the security
compliance data received from the clients in a central database and
provides the available data to users through an administration console and
administration commands.
The server provides security violation details as a basis for compliance
reporting.
Tivoli Security Compliance Manager client
The client collects information about its environment required to assess
compliance with the security policy at a predefined schedule using
different collectors. This data is sent back to the Tivoli Security
Compliance Manager server.
More information about Tivoli Security Compliance Manager can be found in the
IBM Redbooks deliverables Deployment Guide Series: IBM Tivoli Security
Compliance Manager, SG24-6450 and Building a Network Access Control
Solution with IBM Tivoli and Cisco Systems, SG24-6678-01.
24
7530ch02.fm
IBM Tivoli Security Operations Manager

Network and IT resource availability is absolutely critical to business and service
assurance. Enterprises, federal agencies, and service providers can lose millions
of dollars per year as a result of worms, trojans, and other types of malware that
bring down corporate resources and organization-facing services.
The Security Operations Manager is a Security Information And Event
Management (SIEM) platform designed to improve the effectiveness, efficiency,
and visibility of security operations and information risk management. Security
Operations Manager can enable the enterprise to automate the following tasks:
Log aggregation, correlation and analysis.
Recognition, investigation and response to incidents.
Incident tracking and handling.
Enable monitoring and enforcement of policy.
Provide comprehensive reporting for compliance efforts.
Security Operations Manager automates many repetitive and time-intensive
activities that are required for effective security operations.
Data mining, historical reporting, self-auditing, and tracking capabilities provide
critical information for understanding security trends. Security Operations
Manager supplies standard and customizable report templates, an automated
report scheduler, and export functionality of all graphs and charts. It draws on
information stored in a security event database to deliver historical reporting and
trending on demand.
The event collectors can send data to a single central management server, or an
organization can use multiple servers to maximize availability.
Security Operations Manager can also be used as a managed security services
(MSS) platform. It can help the MSS provider to reduce operational costs by
offering a high degree of automation. In addition, it can demonstrate service
levels and value to organizations through its comprehensive reporting
capabilities.
For more information about Tivoli Security Operations Manager please refer to
the IBM Redbooks deliverable Enterprise Security Architecture Using IBM Tivoli
Security Solutions, SG24-6014-04.
IBM Tivoli Compliance Insight Manager

Compliance Insight Manager helps to gain and maintain an overview of security
compliance posture and to monitor user related security policies.
25
7530ch02.fm
It provides automated user activity monitoring across heterogeneous systems,

with an ad-hoc dashboard functionality and flexible reporting capabilities to help
measure an organizations security posture and respond to auditors requests.
It performs effective Privileged User Monitoring and Audit (PUMA) on
databases, applications, servers, and mainframes. By translating captured native
audit log information into an easily understandable format it supports the
organizations auditing needs. Built-in PUMA reports are available as well as a
report definition engine to create custom reports. For compliance requirements
the history of information needs to be stored. Compliance Insight Manager
efficiently collects, stores, investigates and retrieves logs through automated log
management.
The remainder of this book is focused on providing more details on the Tivoli
Compliance Insight Manager architecture and components.
2.5 Conclusion
In this chapter we shed some light into the necessary steps in order to architect a
compliance management solution. After we investigated the different compliance
related event types that have to be collected we described a general solution
architecture.
Finally we spent a few paragraphs on introducing the IBM Tivoli solution offerings
in the compliance management space: Tivoli Security Compliance Manager,
Tivoli Security Operations Manager, and Tivoli Compliance Insight Manager.
In the the following chapter we start to focus on Tivoli Compliance Insight
Manager by introducing the product architecture and component model to you.
26
7530ch03.fm
Chapter 3.
IBM Tivoli Compliance

Insight Manager component
structure
In this chapter we introduce the high-level components and new concepts for the
design of a compliance management solution using Tivoli Compliance Insight
Manager.
We provide you with an understanding of the high level product architecture of
Tivoli Compliance Insight Manager. We describe the role of each of the
components within the Tivoli Compliance Insight Manager environment and the
internal processes that occur to achieve centralized logging and compliance
auditing. The final section of the chapter describes the W7LogSDK toolkit that
can be used for extra flexibility in customizing your Tivoli Compliance Insight
Manager deployment.
27
7530ch03.fm
3.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 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 49. 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.
3.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 3-1 illustrates the high level Tivoli Compliance Insight Manager product
architecture.
28
7530ch03.fm
Archive audit trails

Normalization of audit trails
Archive security policies
Preparation of reports
Alerts and email notification
Standard
Server
Consolidation of statistics from multiple

databases
Overall compliance checking
Forensic search indexing
Administration of log archives
Tivoli
Compliance
Insight
Manager
Enterprise
Server
Web Portal
Report viewing
- Compliance
- Event detail
- Log management
- Forensic search
Policy management using Policy Generator
Scoping
Collection of audit trails

Collection of user information
Actuators
Management
Console

network configuration
Configuration of data for report
preparation
Alert and email notification
configuration
Security policy violation definition
user management
Figure 3-1 Tivoli Compliance Insight Manager architecture
This section describes each of these components in the Tivoli Compliance

Insight Manager environment.
Chapter 3. IBM Tivoli Compliance Insight Manager component structure
29
7530ch03.fm
A note on naming: This IBM Redbook deliverable 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. So what the heck is going on here?
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 bookand 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)
3.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.
3.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.
30
7530ch03.fm
Figure 3-2 A Tivoli Compliance Insight Manager cluster environment
Centralized log management

As shown in Figure 3-2, 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 overhead 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.
Centralized forensics
The Enterprise Server also provides the 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.
31
7530ch03.fm
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 3.3.2,
Mapping and loading on page 46.
3.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 3.2.6, iView
Web portal on page 34.
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 3.2.5,
Management Console on page 33.
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.
3.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 3-3.
32
7530ch03.fm
Actuator
Actuator
Scripts
Agent
Figure 3-3 Actuator software
The Actuator software can be installed locally on the target system or remotely.
In Data collection using Actuators on page 40 we describe the log collection
process.
3.2.5 Management Console

The Management Console is responsible for 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 3-4. 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 40 describes this concept in more detail.
33
7530ch03.fm
Figure 3-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.
3.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.
34
7530ch03.fm
3.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, 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. Additionally 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.
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
35
7530ch03.fm
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 via 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 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.
3.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 3-5 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.
36
7530ch03.fm
Figure 3-5 Tivoli Compliance Insight Manager architecture
3.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.
37
7530ch03.fm
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 3-6 Tivoli Compliance Insight Manager key processes flowchart
Figure 3-6, Tivoli Compliance Insight Manager key processes flowchart 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.
These key processes are described in further detail in this section.
38
7530ch03.fm
3.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 servers 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 the collect
process is operating and to detect if collect failures have occurred. Tivoli
Compliance Insight Manager alerts selected administrators if a collect 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 users 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.
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:
39
7530ch03.fm
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. You can refer back to Figure 3-3 on page 33 for a
diagrammatic 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
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.
40
7530ch03.fm
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. With relation 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.
Agent collection mechanism

Figure 3-7 illustrates the steps involved in collecting data from an audited
system.
41
7530ch03.fm
Figure 3-7 Agent data collection method
1. The collect 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 collect.
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.
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. Additionally,
42
7530ch03.fm
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 collect reduces the operational overhead compared to an agent-based
approach. The SSH approach with UNIX provides a secure connection; the
NetBIOS approach used with Windows remote collect does not provide a secure
connection due to limitations inherent to the Windows environment.
Windows agentless collection

The most common implementation of remote collect 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 3-8
shows the typical configuration used to perform an agentless collect when the
audited systems are Windows machines. Be aware, however, the agentless
collection method is not supported on all event sources.
Figure 3-8 Agentless data collection over NetBios
43
7530ch03.fm
1. The collect 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 collect for UNIX
servers. It uses SSH to perform the collect so it is secure. The basic
configuration for a UNIX agentless collection is shown below in Figure 3-9.
Figure 3-9 Agentless data collection over SSH
Tivoli Compliance Insight Manager uses 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.
44
7530ch03.fm
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-00 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 3.4, The W7LogSDK on page 59.
IBM Services are available to assist with collecting logs from event sources that
are not automatically support 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. 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 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.
45
7530ch03.fm
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 via parentheses.
The forensic tools operate over all of the Standard Servers associated with the
Enterprise Server. They access the Depots via 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
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.
3.3.2 Mapping and loading

Once log data has been centralized in the Depot, it can be processed and
analyzed. This process is shown below in Figure 3-10.
46
7530ch03.fm
Figure 3-10 Mapping and loading steps
Mapping
To make the audit trail data accessible, it is translated (or normalized) into an
easy-to-understand data model called the Generic Event Model (GEM).
The Tivoli Compliance Insight Manager mapping process for each and every
platform is coded using the Generic Scanning Language (GSL) and the Generic
Mapping Language (GML) in files that reside on the Tivoli Compliance Insight
Manager server. The chunks are sorted based on their timestamps and are
processed sequentially by the appropriate mappers. These mappers determine
the field translation values. That is, the mapper interprets the original log data
and translates the chunk data into the GEM database model.
For more information on GSL/GML refer to the IBM Tivoli Compliance Insight
Manager User Reference Guide Version 8.0, SC23-6545.
47
7530ch03.fm
Determine attributes
Security log data consists of records. Each record usually describes one event
that happened on the audited system. Central to GEM is the classification of
these events according to their W7 attributes. This is the process of normalizing
the data. W7 is an English Language format which describes: Who did What,
When, Where, From Where, Where To and on What. The use of W7 formatted
information enables security specialists and non-technical personnel including
auditors to interpret audit information without the need for detailed knowledge
of each source. Most operating systems, infrastructure applications, and almost
every security device produces log data that is not readily understandable,
therefore mapping to the W7 format translates data into powerful audit
information.
Group and apply rules

To prepare data for reporting, the Tivoli Compliance Insight Manager
administrator will define one or more W7 grouping functions and policies which
each resemble a set of filters. These filters determine how the attributes
associated with each GEM event are classified. This grouping process takes the
fields from the GEM tables and labels them according to the W7 model defined
by the administrator.
The process of adding meta information from the currently active policy to the
GEM records using the W7 classification scheme for the assets is often referred
to as grouping (or filtering).
The process of comparing each GEM event with the defined policies allows the
severity of each event to be evaluated. The policies applied to the event data
throughout this process determines the contents of the policy exception and
attention reports. When high severity events such as policy violations are
detected, an automatic e-mail alert can be sent to pre-defined recipients.
Loading
During the loading phase the server uploads the GEM records together with the
meta information into a relational GEM database. Usually, GEM databases are
periodically emptied and filled with recent data, often on a daily basis. This
means the data of the last day is present in the database in W7 format, ready for
analysis. If necessary, other data from the Depot can be mapped and loaded
through manual commands for analysis.
Note: Because mapping precedes and serves loading, the combination of the
two is also called load (in short form).
48
7530ch03.fm
In the remainder of this section we describe the key concepts related to mapping
and loading in more detail.
The W7 model
A security log consists of event records. Each record usually describes a single
event that occurred on the audited system. Tivoli Compliance Insight Manager
normalizes the collected event data into an English-based language called W7
so that it can easily be interpreted. All Tivoli Compliance Insight Manager
security events have seven basic attributes:
Who
Which user or application initiated the event?
What
What kind of action does the event represent?
When
When did the event occur?
Where
On which machine did the event happen?
OnWhat
What was the object (file, database, printer) involved?
WhereFrom
From which machine did the event originate?
WhereTo
Which machine is the target or destination of the event?
Figure 3-11 is a pictorial representation of the W7 model.
Figure 3-11 W7 model
49
7530ch03.fm
Benefit of using W7
The disparate platforms and systems generating the logs will often use different
terminology for the same action. For example, one operating system may use the
term logging on, while another operating system uses login. Similarly, one
system may request a userid while another system asks for a username.
Unless you are an expert in all of the different systems used by your
organization, it is very difficult to search through the logged data manually to find
all instances of a given action or user.
Mapping the raw event data into a standard set of seven distinctive attributes
enables a consistent method for monitoring, analyzing, and reporting irrespective
of the original format of the event. When translating log records into W7 format,
the seven W's of the event are determined from the structure and content of the
original log record. Log record formats are very different for every distinct event
source; therefore the normalization of data into W7 requires a specialized
knowledge of each event source to be mapped. The logic required to do this
mapping is built into the mapper code that resides on each audited machine or
device.
W7 is a grammar that enables you to check if a certain GEM event is in
compliance with the security policy. Through the use of this grammar, you can
differentiate between events that are compliant, considered exceptions and
require special attention.
Groups
In order to apply logic and draw conclusions from the normalized data, the
events have to be classified. Knowing that an event happened on Monday at
8.30 AM is one thing, but in order to draw conclusions, it is more interesting to
know whether it happened during or outside a specific time period for example
office hours. Similarly, a user-id has certain access rights, detailing what a user
is allowed to initiate. These user access rights are usually dependent on their
role. For example, based on whether he/she is an administrator, regular user or
guest. Therefore all W7 attributes are classified into W7 groups. There are five
types of groups resulting:
1. Who groups for classification of users and processes
2. What groups for classification of event types
3. When groups for classification of time periods
4. Where groups for classification of machines and devices
5. onWhat groups for classification of objects
The Where, Where from and Where to attributes are all classified using the same
Where groups.
50
7530ch03.fm
The correct classification for a particular object is site specific and is

automatically synchronized across the servers being audited. For example, in
which Who group does each user belong and to which Where group should each
system be assigned? The Tivoli Compliance Insight Manager administrator
defines the W7 elements and the grouping function that tells on which W7
element each GEM event attribute is projected. All GEM event table values that
are not covered by the specified grouping functions, will be classified into one of
the default groups: Other Periods, Other Sources, Other Events, Other Platforms
or Other Objects.
The Tivoli Compliance Insight Manager administrator can review and update this
information in the Grouping editor on the Tivoli Compliance Insight Manager
Management Console.
Figure 3-12 shows how the GEM event data is linked to the W7 model:
Figure 3-12 The relationship between GEM event and the W7 model
Each W7 value of a GEM event is classified by the grouping process under a W7

group label. If you look at the W7 model as a five dimensional space, you can
see that the GEM event in the example is linked to the W7 point determined by
the W7 rule (EVENING, USERS, LOGON LOGOFF, LOCALMACHINE,
SYSTEM). Security policy rules are also represented by a combination of W7
group labels. Only the GEM events that collide with a W7 point that represents a
policy rule, are in compliance with the security policy. Attention rules are also
represented by a combination of W7 group labels. GEM events are classified as
attention events if they collide with a W7 point that represents an attention rule.
51
7530ch03.fm
That is, the W7 model can be used to determine if some GEM database records
need special attention or whether the records comply with the set of policy rules.
The result of the grouping for a particular record can be viewed in the Event
detail report in iView, as shown in Figure 3-13.
Figure 3-13 Event Detail View
The column called Field shows the GEM field values of a GEM event. The
column Group shows for each GEM field value which W7groups are linked to the
value left of it. For example, the GEM field value
Administrator(MSTESTCE\ADMINISTRATOR) is linked to at least two W7
groups: Administrators and IT.
Policy management
Whether or not an event deserves special treatment is determined by comparing
the W7 groups it is classified into against a set of rules defined by the Tivoli
Compliance Insight Manager administrator. As previously mentioned, there are
two kinds of rules:
Policy rules
These describe acceptable user, for example, allowed

behavior
Attention rules
These identify events deserving special attention
Policy rules are used to monitor the way that information and processes are
being used within an organization. That is, they specify which actions can be
52
7530ch03.fm
performed by which people on which systems at what times. Actions that do not
match a policy rule generate policy exceptions. Policy rules have an associated
priority that can be set to enable differentiation so that policy violations and other
exceptions can be processed according to their severity or importance. This
allows security administrators and auditors to focus on addressing those events
that have the most significant impact on the business.
By refining policy rules, you can ensure that existing policies are effective and
can even establish new policies that reflect the actual behavior of users, as
opposed to theoretical activities contained in policy manuals and non-automated
tracking systems.
Automatically applying the policy rules makes it easy to quickly determine
whether or not each monitored action does or does not comply with policy.
Attention rules are used to highlight instances of events that are critical to the
organization. One typical application for these rules is to monitor change
management activities even if the events are allowed by your policy rules.
Actions that match an attention rule generate actions. For example, by looking
for a specific instance of a data attribute in any of the W7 dimensions for certain
events, you can set an alert to notify someone of a change to a servers
configuration.
Figure 3-14 illustrates the process of comparing a logged event to the specified
policy and attention rules to determine whether actions and alerts are necessary.
53
7530ch03.fm
Figure 3-14 Applying policy and attention rules
Alerting and notification

Alerts are messages that Tivoli Compliance Insight Manager sends when a
serious or potentially harmful security event has occurred. Alerts allow for a fast
response to the event by a systems manager or system administrator. The aim of
alerts is to raise attention for events that require a follow-up, that is, special
54
7530ch03.fm
attention events or events above a defined severity level, such as security policy
exceptions. These properties are evaluated in the policy evaluation step of the
Map/Load process. The Map/Load process (mapper) sends alerts, as mentioned
in the Group and apply rules on page 48.
Tivoli Compliance Insight Manager can send alerts through the following
protocols:
SMTP
Alerts are sent as e-mails.
SNMP
Alerts are sent as SNMP traps.
Custom alerts
Sent through a mechanism invoked with a user-provided

program or script.
For more information about alerts look up the section Managing Alerts in the
IBM Tivoli Compliance Insight Manager User Guide Version 8.0, SC23-6544.
Which IT security policies to map into policy rules

Corporate IT security policies generally cover a whole range of controls
including:
Awareness programs
Security clearance
Authorization matrices
Logon policies
and so on
Only those IT security policy rules that interact with the security functions on a
platform may be considered to become Tivoli Compliance Insight Manager
security policy rules.
The following requirements must be met in order to use Tivoli Compliance Insight
Manager to report on a particular policy:
1. The security functions on the target must contain audit functions to monitor
the actions relating to the rule.
2. Tivoli Compliance Insight Manager must support the platform and collect the
information that the target provides.
Figure 3-15 describes some high level steps in the process of evaluating the
corporate IT security policy and creating rules to be used in the Tivoli
Compliance Insight Manager security policy.
55
7530ch03.fm
Translate the rule

into W7,
recognizing
Subjects, Objects
and Verbs
Drop the rule if

no match is
found. Backup
the rule with
procedures if
a partial match
is found.
Commit
TCIM
security
policy
Corporate IT
Security
Policy rule
Classify it as either a
policy rule or an
attention rule
Determine if the
audit trail on the
target can be
configured to
provide entities
that match the
Subject, Object or
Verb
Add an appropriate W7
policy rule to the TCIM
security policy
Figure 3-15 Creating policies in Tivoli Compliance Insight Manager
Policy generation and enforcement

Policies are used as the baseline to filter all events (which are kept for forensic
investigations and regulatory compliance purposes) facilitating the exposure of
exceptions to the rules. Policies can be changed and adapted easily at any time.
Tivoli Compliance Insight Manager provides an easy to use integrated policy
generation tool, the Policy Generator, which allows the user to create policy rules
simply by looking at current event data and making a decision as to what
constitutes acceptable use of, or access to, information resources. Normal,
acceptable behavior becomes the rule. Policy generation is an evolving process.
If legitimate user actions are triggering policy exceptions and alerts in Tivoli
Compliance Insight Manager then the security administrator needs to adjust the
policy to ensure it reflects the real world environment and permissible actions.
Rules within policies can be adjusted at any time.
56
7530ch03.fm
If the policy is formulated to reflect the rules of a regulation such as

Sarbanes-Oxley, GLBA or has been established as part of a security framework
like ISO17799 or COBIT, Tivoli Compliance Insight Manager provides the ideal
reporting tool to meet your regulatory compliance obligations.
The Policy Generator is an automated tool for creating policies from loaded event
data in a database and, based upon the in-built knowledge of various platforms,
builds the most applicable policy from that data. This policy can then be loaded
and modified if desired using the Policy Editor in the Management Console.
3.3.3 Data aggregation and consolidation

An aggregation process maintains data and statistics, spanning a longer period.
The aggregation process builds an aggregation database from which trends
and summaries can be extracted.
When a scheduled load is performed, part of the GEM database contents is
copied into the aggregation database. In particular, the following contents are
copied;
The number of GEM events represented by the W7 categories
All GEM events that need attention or do not comply to a policy rule set
For enterprise-wide trending in a Tivoli Compliance Insight Manager cluster
environment, aggregation databases from multiple Standard Servers are brought
together into a single consolidation database.
3.3.4 Reporting and presentation

Tivoli Compliance Insight Managers Web-based reporting tool, iView, provides a
large number of standard and custom reports. These are produced on request by
iView, which pulls information from mapped data, including that stored in the
aggregation database. These reports can highlight attempts to breach security
as well as (attempted) access to critical resources.
Both standard and custom reports let you examine exceptions and events that
require special attention, and since the data presented in these reports is in the
W7 format, no specialized knowledge is required to interpret the output. Reports
are clear, concise, and integrate all security data for your review. Tivoli
Compliance Insight Manager provides a dashboard with graphical and statistical
overviews of logged activities, with drill-down capabilities to identify and examine
related events. Additionally, Tivoli Compliance Insight Managers clear illustration
of policy exceptions enables you to continuously monitor and tailor your security
policies to your changing business needs.
57
7530ch03.fm
Compliance management modules

From the boardroom to information technology departments, rules and
regulations are placing ever-increasing demands on organizations of all sizes. In
the middle are IT security managers and auditors, who face the overwhelming
task of understanding the regulations and implementing a wide array of
compliance measures.
Tivoli Compliance Insight Manager has plug-in compliance management
modules available that provide optionally installable sets of capabilities to allow a
customer to monitor and maintain compliance with a selected standard. These
modules include sample policies and compliance report templates to assist
customers to meet their regulatory requirements.
Regulations underscore the need to understand who is touching the most crucial
corporate data, and whether this behavior complies with security policy. You can
use Tivoli Compliance Insight Manager to monitor all security events and audit
them, versus security policy.
Compliance management modules for the following dictates or best practice sets
exist:
Sarbanes-Oxley
HIPAA
ISO17799
and more
These management modules are described in more detail in the IBM Tivoli
Compliance Insight Manager User Guide Version 8.0, SC23-6544.
Report distribution
Tivoli Compliance Insight Manager Version 8.0 provides the functionality for the
automated distribution of reports in full or as excerpts to a predefined group of
Tivoli Compliance Insight Manager users. This report distribution functionality is
available through the Web interface of iView. More information about the report
distribution functionality can be found in Distributing Reports in the IBM Tivoli
Compliance Insight Manager User Guide Version 8.0, SC23-6544.
User roles
You can assign every Tivoli Compliance Insight Manager user specific access
and viewing rights from the Management Console. This level of granularity in
setting user access lets you customize views and management rights for specific
users, and limit access to administrative functionality. The ability to define the
mailing lists for alerts regarding high severity events also allows the Tivoli
Compliance Insight Manager administrator to control access to the security event
58
7530ch03.fm
data. Any Tivoli Compliance Insight Manager user activity, from administrative
actions to report viewing, is automatically self-audited and included in the
organization wide security reporting.
3.4 The W7LogSDK

Tivoli Compliance Insight Manager has Actuators available that cover a large
number of event sources including operating systems and applications.
In addition to the Actuators there is a W7LogSDK available to allow you to use
Tivoli Compliance Insight Manager to monitor event sources that are not
supported out of the box. You can use the W7LogSDK to create log files that
present event data in a W7 format that can be interpreted by the Tivoli
Compliance Insight Manager server. The W7LogSDK allows you to create these
log files either in CSV or XML format as described in the sections that follow.
For a working example of how to apply the W7LogSDK, you can refer to
Chapter 12, Tivoli Security Operations Manager integration on page 371. This
chapter describes the practical application of the W7LogSDK to integrate Tivoli
Compliance Insight Manager and Tivoli Security Operations Manager.
3.4.1 How the W7LogSDK works

W7Log event sources integrate directly into the normal processing of all other
event sources defined in Tivoli Compliance Insight Manager.
The target application or transformation tool writes the audit log in the W7Log
event format to a specified directory.
On a schedule (or manually), the log data is collected and securely stored in
the Tivoli Compliance Insight Manager log Depot.
On a schedule (or manually), this data can then be normalized and loaded
into a Tivoli Compliance Insight Manager reporting database.
Note: The capability to collect W7Log event data is fully integrated into the
Tivoli Compliance Insight Manager 8.0 Windows Actuator.
As a result, W7Log event data must be collected through a Windows platform.
The application developer needs to provide the following:
59
7530ch03.fm
A file with event data in one of the W7Log formats, which can be XML or CSV.
The file must be fully compliant with the format definitions described in this
chapter.
The file(s) must be placed in a directory that is specified as an event source
property through the Management Console.
Each file in the specified directory must be COMPLETE (for example,
containing only complete log records) when the W7Log Actuator reads it. A
suitable manner to ensure this is to construct the log file somewhere else and
then move it to the designated directory for collection.
The contents of different log files shall not overlap in generation time of the
log records.
The files must be processed in the correct time sequence; the recommended
way to ensure this is through the naming of the log files.
Note: The W7Log Actuator will read ALL the log files from the designated
directory on the Actuator system and combine them into a chunk file to be
stored in the Depot. It then REMOVES all the log files from the directory.
3.4.2 Event attributes

Regardless of whether you elect to use the W7LogSDK CSV or XML format,
every event that occurs on the audited system will need to be described by 16
values. These values cover all the W7 dimensions, as well as one event detail
field which can be used to store arbitrary text. More specifically, the following 16
items of information need to be present in each event:
For the When dimension: when
For the Who dimension: whorealname, whologonname
For the What dimension: whatverb, whatnoun, whatsuccess
For the Where, WhereFrom, and WhereTo dimensions: wheretype,
wherename, wherefromtype, wherefromname, wheretotype,
wheretoname
For the OnWhat dimension: onwhattype, onwhatpath, onwhatname
Plus a single event detail: info
The following tables Table 3-1 to Table 3-8 show the detailed syntax for each of
these expected values, as well as giving some examples.
60
7530ch03.fm
Table 3-1 When W7 dimension

When
Defined as:
time at which the event has occurred
Fields:
when
Syntax:
the field is specified as:

YYYY-MM-ddTHH:mm:sshh:mm
where:
YYYY - the year in the Gregorian calendar
MM - the month number (1-12)
dd - the day number (1-31)
T - literal separator between date and time
HH - the hour (0-23)
mm - the minute (0-59)
ss - the second (0-59) since local midnight
The second hour and minute specifications indicate the

difference between the local time and Coordinated Universal
Time (UTC).
Example:
when: 2005-11-27T10:33:45+05:00
Table 3-2 Who W7 dimension

Who
Defined as:
platform-dependent logon ID and logon name of the user who

initiated the event. The name of the system process or
application can be specified here instead of the name of the
actual user
Fields:
whorealname
whologonname
Syntax:
arbitrary string values with a maximum length of 64 characters
Example:
whorealname: John Doe

whologonname: jdoe
61
7530ch03.fm

Table 3-3 What W7 dimension
What
Defined as:
Type of the event, specified as a triplet of values. The verb is

an action type (for example logon, create, and so on); noun'refinement of the action type (for example user, file,
correspondingly, and so on); and success can be Success if
the action was successfully executed or Failure if otherwise.
Fields:
whatverb
whatnoun
whatsuccess
Syntax:
whatverb and whatnoun are arbitrary string values with a

maximum of 20 characters;
whatsuccess is an arbitrary string value with a maximum of 8
characters.
Example:
whatverb: Create
whatnoun: File
whatsuccess: Success
whatverb: Remove
whatnoun: Group
whatsuccess: Failure
whatverb: Clear
whatnoun: Auditlog
whatsuccess: Success
Remarks:
The following values are used for the whatsuccess field:

Success - the operation succeeded
Failure - the operation or attack failed
Warning - the attack succeeded, or an undesirable situation is
detected
Info - if none of the above values are applicable
Each of these what attributes (whatverb, whatnoun and
whatsuccess) should be written with an upper case first letter
and lower case for the remaining letters.
Table 3-4 Where W7 dimension

Where
62
Defined as:
platform (type and name) where the event was registered (for
example SUN Solaris, GATEWAY, and so on)
Fields:
wheretype
wherename
7530ch03.fm
Where
wheretype is an arbitrary string value with a

maximum of 20 characters;
Syntax:
wherename is an arbitrary string value with a

maximum of 128 characters.
Example:
wheretype: CISCO IDS

wherename: ids-01.domain.com
63
7530ch03.fm

Table 3-5 Where From W7 dimension
Where From
Defined as:
platform (type and name) of the event's origin platform (for

example Internet, 192.168.103.104 and so on)
Fields:
wherefromtype
wherefromname
Syntax:
wherefromtype is an arbitrary string value with a maximum of

20 characters;
wherefromname is an arbitrary string value with a maximum of
128 characters.
Example:
wherefromtype: Internet
wherefromname: host.domain.com
Remarks:
For traffic events, which identify something (e.g., a PACKET)

traveling from a source system to a destination system, the
From Where identifies the source system.
For action events, events of types that are commonly
associated with a single user account, the From Where
dimension identifies the workstation from where the user
logged on who initiated the action. If the Who implies that the
action was not associated with a particular user account (for
example, if it is equal to System), then the From Where is
equal to the Where.
Table 3-6 The Where To W7 dimension

Where To
64
Defined as:
platform (type and name) of the event's target platform (for

example Microsoft Windows. WORKSTATION and so on)
Fields:
wheretotype
wheretoname
Syntax:
wheretotype is an arbitrary string value with a maximum of 20

characters;
wheretoname is an arbitrary string value with a maximum of
128 characters.
Example:
wheretotype: WebApp
wheretoname: webserver_01
7530ch03.fm
Where To
Remarks:
For traffic events, which identify something (e.g., a PACKET)

traveling from a source system to a destination system, the
From Where identifies the destination system.
For action events, events of types that are commonly
associated with a single user account, the Where To
dimension identifies the namespace where the On What
resides (such as a Domain). If there is no particular On What,
then the Where To is equal to the Where.
65
7530ch03.fm

Table 3-7 On What W7 Dimension
On What
Defined as:
triplet indicating what object (for example file, database,

printer, and so on) was the object of the event.
Fields:
onwhattype
onwhatpath
onwhatname
Syntax:
onwhattype is an arbitrary string value with a maximum of 20

characters;
onwhatpath is an arbitrary string value with a maximum of 150
characters;
onwhatname is an arbitrary string value with a maximum of
110 characters.
Examples:
onwhattype: FILE
onwhatpath: C:\Documents and Settings
onwhatname: ntuser.ini
onwhattype: FILE
onwhatpath: -/etc
onwhatname: passwd
onwhattype: PRINTER
onwhatpath: printer01.domain.com
onwhatname: HP LaserJet First Floor
onwhattype: DATABASE
onwhatpath: ORADBINSTANCE
onwhatname: OracleSchema1
Remarks:
The identity of the object is split into an object path and an

object name. If no object path is present (for example, the
name is a relative name), then a single period. is used for it.
The root directory or object of a file or object hierarchy is
referred to as a single dash -.
For example, the /etc directory on a Unix system is displayed
as -/etc, and the / (root) directory itself as -/-.
The value for onwhattype should be capitalized. The values for
onwhatpath & onwhatname should be in the same case as
extracted from the audited system.
66
7530ch03.fm
Table 3-8 The info

Where To
Defined as:
any additional information that must be captured in the event
Fields:
info
Syntax:
info is an arbitrary string value with a maximum of 3900

characters.
Note:
1. Record fields can be empty or have only spaces, however it is
recommended to use single dash - for absent values.
2. The size of record fields is not checked by the Tivoli Compliance Insight
Manager mapper. It is the responsibility of the producer of the W7Log file
to ensure that fields do not exceed the maximum string length.
3.4.3 W7LogSDK CSV format

The W7Log CSV (comma separated values) format is similar to the popular CSV
file format used by applications such as Microsoft Excel, as a portable
representation of a structured database. Each line is one entry or record and the
fields in a record are separated by commas.
If the value of a field includes a comma or a new line, the whole field must be
surrounded with double quotes. When the field is in quotes, any quote literals
must be escaped by two quotes (""). Text that comes after quotes that have been
closed, but come before the next comma will be ignored.
Empty fields are returned as strings of length zero: "". The following line has
three empty fields and three non-empty fields in it. There is an empty field on
each end, and one in the middle. One token is returned as a space.
,second,, ,fifth,
Blank lines are always ignored. No other lines will be ignored, even if they start
with "#" sign.
This format differs from the standard in several respects:
Leading and trailing white space is significant.
A backslash is not a special character and is not used to escape anything.
67
7530ch03.fm
Quotes inside quoted strings are escaped with a double quote rather than a
backslash
W7LogSDK CSV format does not define any comment character.
The W7LogSDK CSV file contents is defined as follows:
1. Log records must be written in UTF-8 encoding.
2. Header lines must list field names, separated by commas in the fixed order,
exactly as follows:
when,whorealname,whologonname,whatverb,whatnoun,whatsuccess,wheretyp
e,wherename,wherefromtype,wherefromname,wheretotype,wheretoname,onwh
attype,onwhatpath,onwhatname,info
3. The remaining lines must list the field values for every log record, one record
per line. There must be exactly 16 values in each log record, describing one
event that happened on the audited system. Please refer to the event
attributes listed in 3.4.2, Event attributes on page 60.
Example 3-1 illustrates valid contents for a W7LogSDK CSV file. It specifies
some imaginary events.
Example 3-1 test.csv
when,whorealname,whologonname,whatverb,whatnoun,whatsuccess,wheretype,w
herename,wherefromtype,wherefromname,wheretotype,wheretoname,onwhattype
,onwhatpath,onwhatname,info
2003-07-18T14:22:00+00:00, John Smith, jsmith, Logon, System, Success,
Microsoft Windows, PDC,-,WORKSTATION, Microsoft Windows,PDC,SYSTEM,
-,PDC, successful logon
2003-07-18T14:22:01+00:00, -, exporer.exe, Create, File, Success,
Microsoft Windows, PDC, -, -, -, -, FILE, C:\Documents and
Settings\jsmith,ntuser.ini,
3.4.4 W7LogSDK XML format

The W7LogSDK XML format is defined by the following XML schema:
events.xsd
<?xml version="1.0" encoding="UTF-8" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:element name="when" type="xs:dateTime"/>
<xs:element name="info" type="xs:string"/>

<xs:attribute name="type" type="xs:string" />
68
7530ch03.fm
<xs:attribute name="name" type="xs:string" />

<xs:attribute name="path" type="xs:string" />
<xs:attributeGroup name="whereAttributes">
<xs:attribute ref="type"/>
<xs:attribute ref="name"/>
</xs:attributeGroup>

<xs:element name="who">
<xs:complexType>
<xs:attribute name="logonname" type="xs:string" />
<xs:attribute name="realname" type="xs:string" />
</xs:complexType>
</xs:element>
<xs:element name="what">
<xs:complexType>
<xs:attribute name="verb" type="xs:string" />
<xs:attribute name="noun" type="xs:string" />
<xs:attribute name="success" type="xs:string" />
</xs:complexType>
</xs:element>
<xs:element name="onwhat">
<xs:complexType>
<xs:attribute ref="type"/>
<xs:attribute ref="path"/>
<xs:attribute ref="name"/>
</xs:complexType>
</xs:element>
<xs:element name="where">
<xs:complexType>
<xs:attributeGroup ref="whereAttributes"/>
</xs:complexType>
</xs:element>
<xs:element name="wherefrom">
<xs:complexType>
</xs:complexType>
</xs:element>
<xs:element name="whereto">
<xs:complexType>
</xs:complexType>
</xs:element>
<xs:element name="event">
<xs:complexType>
<xs:all>
69
7530ch03.fm
<xs:element ref="when"/>
<xs:element ref="who"/>
<xs:element ref="where"/>
<xs:element ref="what"/>
<xs:element ref="onwhat"/>
<xs:element ref="wherefrom"/>
<xs:element ref="whereto"/>
<xs:element ref="info"/>
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name="sample">
<xs:complexType>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="event" />
<xs:element ref="sample" />
</xs:choice>
</xs:complexType>
</xs:element>
</xs:schema>
The XML log file must contain XML log records defined by the above schema,
each of which describes one event that happened on the audited system. Please
refer to the event attributes listed in 3.4.2, Event attributes on page 60.
The record fields can not contain XML special characters, so corresponding XML
entities must be used instead:
&lt - The less than sign (<)
> - The greater than sign (>)
& - The ampersand (&)
' - The single quote ( ' )
" - The double quote ( " )
Example 3-2 shows a valid XML file that has been formatted using the
W7LogSDK XML schema:
Example 3-2 test.xml
<sample>
<event>
<when>2003-07-18T14:22:01-02:00</when>
<what verb="Logon" noun="System" success="Success"/>
70
7530ch03.fm
<onwhat type="SYSTEM" path="-" name="PDC"/>

<who logonname=" John Smith" realname="jsmith"/>
<where type="Microsoft Windows" name="PDC"/>
<whereto type="Microsoft Windows" name="PDC"/>
<wherefrom type="-" name="WORKSTATION"/>
<info>testing record</info>
</event>
<event>
<when>2003-07-18T14:22:01-02:00</when>
<what verb="Create" noun="File" success="Success"/>
<onwhat type="FILE" path="C:\Documents and Settings\jsmith"
name="ntuser.ini "/>
<who logonname="-" realname="explorer.exe"/>
<where type="Microsoft Windows" name="PDC"/>
<whereto type="-" name="-"/>
<wherefrom type="-" name="-"/>
<info></info>
</event>
</sample>
3.4.5 Validators
There are W7LogSDK Format Verification tools available that allows software
developers to test the validity of the generated logs.
Note: The validators do not check the size of each record field, the person
responsible for producing each log must ensure that the size requirements for
each field are satisfied.
These validators are available on the installation CDs. You can refer to the IBM
Tivoli Compliance Insight Manager Installation Guide Version 8.0, GI11-8176-00
for further details on installing and using these validators.
3.5 Conclusion
Tivoli Compliance Insight Manager gathers audit information from across the
organization and compares activity to the acceptable use policies defined by
both your organization and by your regulators. The core of Tivoli Compliance
Insight Manager is based on a secure, reliable, and robust log collection engine
that supports effective, complete log collection and fast, efficient query and
retrieval. By focusing on security from the inside, it uses the W7 methodology
71
7530ch03.fm
(Who, did What, on What, When, Where, Where from and Where to) to
consolidate, normalize, analyze and report on vast amounts of user behavior and
system activity. As a result, organizations can quickly and easily reveal who
touched what within the organization (with alerts and proactive reports) and
compare that activity to an established internal policy or external regulations.
Numerous organizations rely on the policy-based approach of Tivoli Compliance
Insight Manager to simplify monitoring the activities of privileged users, such as
administrators and outsourcers; improving security auditing, compliance
monitoring and enforcement for heterogeneous environments, ranging from
super servers to the desktop.
72
7530ch04.fm
Chapter 4.
Compliance management
solution design
In this chapter we discuss Tivoli Compliance Insight Manager solution design
from two aspects. In the context of implementation process, we first discuss the
functional design and configuration, which is directly related to the functional
requirements. Next, in 4.2, Operational design and configuration on page 87,
we discuss the aspects of Tivoli Compliance Insight Manager solution design
related to non-functional and operational aspects of implementing and
maintaining Tivoli Compliance Insight Manager deployment, such as monitoring
and maintenance, archiving and information retention, performance and
scalability.
4.1 Functional design and configuration

In the following sections we discuss Tivoli Compliance Insight Manager solution
design as an important part of and in the context of the Tivoli Compliance Insight
Manager implementation process. We do not go into details of the Tivoli
Compliance Insight Manager implementation process here, but cover this topic
briefly as a part of the big picture. For more details see the IBM Redbooks
deliverable Deployment Guide Series: IBM Tivoli Compliance Insight Manager,
SG24-7531-00.
73
7530ch04.fm
So, what does it take to implement Tivoli Compliance Insight Manager from start
to finish?
The process is fairly simple and consists of four key phases:
Discovery and analysis
Project definition and planning
Implementation
Product use
The most critical piece of information we need for any successful implementation
are the reporting requirements. They tell us what data we need to capture and
what we need to report on. That leads us to the overall amount of data we collect
on a daily basis, how much hardware we need, and so on. Based on this
information we can design and size our solution. We describe each phase in
more detail in the following sections.
4.1.1 Discovery and analysis

In this first phase we analyze and evaluate reporting requirements, discover and
learn about the implementation environment and provide audit settings that
support our reporting requirements for every event source on every platform.
Reporting requirements
We identify the reports we need based on specified objectives in terms of
regulatory compliance, internal security policies, operational efficiency, audit
concerns, and so on. Our design approach, based on risk assessment, is to
address privileged user monitoring and auditing (PUMA) first, then expand the
solution to address other objectives.
Note: A risk assessment takes into account the sensitivity and criticality of the
data and defines the assets that can be considered high risk and should
therefore be controlled. The controls put into place for these assets are
therefore most important and should be addressed first if possible by Tivoli
Compliance Insight Manager. The set of administrative or high privilege
accounts form an asset that has high priority.
To meet reporting requirements we also need to
... identify collection types (near real time or batch)
... decide on information grouping (by geographic location, platform, business
unit, and so on)
74
7530ch04.fm
... specify the time frame for data to be maintained in the Depot (for example
one, two, three months or years) and in the GEM databases (for example
from one to seven days)
... determine the time frame (for example one, two, three months or years)
and location (for example SAN, DVDs) to archive the data.
Installation environment
The goal of this task is to assess and document on the computing environment to
prepare for the Tivoli Compliance Insight Manager implementation. We identify
existing audit settings (if fine tuned, not to generate excessive amount of log
data) and data capture, network topology (communication settings, firewalls,
locations, and so on) to identify solution constraints or limitations, estimated log
volume, data storage (type, location) and so on.
Audit settings
The goal of this task is to specify the audit data we need to collect in order to
support the reporting requirements. The audit settings used are always a
trade-off between security and system performance and disk space used. In
most cases, auditing every single action is not an option, thus we analyze the
audit subsystem and determine, evaluate and document/provide audit settings
that support our reporting requirement for every event source on every supported
platform. For example, in the Windows audit subsystem all logons on the
platforms are captured by the audit categories account logon and logon. To
generate the same report on Solaris you would need to activate the audit class lo
in the system wide audit file.
A basic example of the Windows audit settings required for PUMA reporting on
actions performed by IT administrators is shown in Figure 4-1 on page 76 and
Figure 4-2 on page 77.
Chapter 4. Compliance management solution design
75
7530ch04.fm
Figure 4-1 PUMA Audit Policy settings
Examples of actions performed by IT administrators include creating, modifying

and/or deleting administrator accounts, password resets, logon/logoff successes
and failures, and so on.
We suggest three levels of default auditing for Windows:
Low setting on production systems where performance and disk space are
critical.
Medium setting in most other cases.
High setting on servers that contain confidential data and object access
auditing for the directories that contain the confidential data.
For more details on Windows audit recommendations from Microsoft as well as
independent third parties and auditing configuration for all other supported event
sources see the IBM Tivoli Compliance Insight Manager Installation Guide
Version 8.0, GI11-8176-00.
76
7530ch04.fm
Figure 4-2 PUMA Object Access settings
We show more details about various audit settings in our scenario in the second
part of the book starting in Chapter 8, Basic auditing on page 157.
4.1.2 Project definition and planning

At this point we have acquired base information from phase 4.1.1, Discovery
and analysis on page 74 about reporting requirements, installation environment
and audit settings. Our next step involves an Implementation pre-planning
worksheet, based on target platforms (with server names, platforms and
versions, daily log sizes, server location, database groupings, and so on).
Then we define a draft project plan with an initial project schedule, reporting
requirements, and installation environment information. This plan is based on the
typical Tivoli Compliance Insight Manager implementation design architecture
(number and location of Tivoli Compliance Insight Manager servers, hardware
specifications, and so on) and installation prerequisites (software/platform
77
7530ch04.fm
versions, audit settings, ports and protocols needed to install Tivoli Compliance
Insight Manager, and so on).
The Tivoli Compliance Insight Manager implementation design architecture is a
result of information gathered in previous phases, product capabilities and
planning. Therefore, it is very important for a successful implementation, that we
discuss it in more detail in the following sections. General logical (conceptual)
and physical (system) architecture is already explained in the Tivoli Compliance
Insight Manager product documentation and in Chapter 3, IBM Tivoli
Compliance Insight Manager component structure on page 27, thus we will
focus on the different design layouts and the reasons behind those. 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 being grouped into zones.
Using Figure 4-3 on page 79, think of these areas as uncontrolled, controlled,
restricted, secured, and externally controlled. A client utilizes the network to
access applications and data. This client can be from either within your
organization or outside of it.
We use the IBM Method for Architecting Secure Solutions (MASS), discussed
more in the IBM Redbooks deliverable Enterprise Security Architecture Using
IBM Tivoli Security Solutions, SG24-6014-04, as a starting point. MASS
provides a set of security domains to help define the threats to an organization
(including actors and users, flow control, authorization, physical security, and so
on). It enables you to assign information assets to your security domains that
become crucial in high-level design of architecture.
78
7530ch04.fm
Internet
DMZ
Production Zone
Intranet
Restricted
Management Zone
Uncontrolled
Controlled
Secured
Controlled
Figure 4-3 MASS domain concept
Note: The breaks between each network zone indicate the use of a firewall
that clearly delineates each perimeter from the next.
Using the concept of security domains you can translate Figure 4-3 on page 79
into something more targeted, as shown in Figure 4-8 on page 82.
Tivoli Compliance Insight Manager supports up to eight audit configurations as
shown from Figure 4-4 on page 80, to Figure 4-7 on page 81, where dashed
lines represent the system boundary. The layout of Tivoli Compliance Insight
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.
Note: The number of audit configurations supported on a specific platform
varies from one event source to another.
This is sufficient for auditing multiple event sources on systems running different
operating systems. For more information on deploying Tivoli Compliance Insight
Manager event sources, see the IBM Tivoli Compliance Insight Manager
Installation Guide Version 8.0, GI11-8176-00.
79
7530ch04.fm
Audited system
Target system
PoP
TCIM server
Figure 4-4 Tivoli Compliance Insight Manager audit configuration 1
Figure 4-4 shows the audit configuration with all components separated.
Audited system
Target system
PoP
TCIM server
Figure 4-5 Tivoli Compliance Insight Manager audit configurations 2, 3, 4 and 5
Figure 4-5 shows audit configurations where either left, middle, right or left and
right pair of components share the same system.
Note: The Tivoli Compliance Insight Manager Enterprise 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.
Note: The audited system can act as the target system for some event
sources.
Audited system
Target system
PoP
TCIM server
Figure 4-6 Tivoli Compliance Insight Manager audit configurations 6 and 7
Figure 4-6 shows audit configurations where only the audited system or the
server is on its own system.
80
7530ch04.fm
Audited system
Target system
PoP
TCIM server
Figure 4-7 Tivoli Compliance Insight Manager audit configuration 8
Figure 4-7 shows the simplest audit configuration, with all components on the
same system.
To exchange information among its components, Tivoli Compliance Insight
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 different mechanisms in a variety of
configurations. A system audited through remote collect does not need to run the
Tivoli Compliance Insight Manager software. Instead, event data is forwarded to
the server by a Point of Presence system with direct access to the audited
system. To audit several systems in a Windows domain, only one must be
configured as a Point of Presence and have an Actuator installed. For more
information on Tivoli Compliance Insight Manager concepts and different typical
configurations, see the IBM Tivoli Compliance Insight Manager User Guide
Version 8.0, SC23-6544-00.
We place different components of Tivoli Compliance Insight Manager into
different network zones as shown in Figure 4-8 on page 82, to show many, but
not all, possible audit configurations and collect mechanisms.
81
7530ch04.fm
Internet
DMZ
Production Zone
Intranet
Audited system
Audited system
Audited system
Audited system
Target system
Target system
Syslog NG
FTP server
PoP
PoP
Audited system
Audited system
Restricted
Audited system
External API
PoP
Target system
PoP
Audited system
Uncontrolled
Controlled
3
2
TCIM
cluster
TCIM
server
TCIM cluster
TCIM cluster
Secured
TSOM
10
Console
Controlled
Figure 4-8 Tivoli Compliance Insight Manager deployment options
For Tivoli Compliance Insight 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
should be placed into the management zone, because chunks are stored there
and they are the most important asset as they hold crucial data for any forensic
and/or reporting activity.
Point of Presence components 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.
The Management Console can be placed anywhere in the network (together with
an Actuator), but in our example it is in the regular Intranet zone.
Let us explain the different examples of possible audit configurations and collect
mechanisms numbered from 1 to 10 in Figure 4-8.
1. Example 1 shows the most simple collect configuration. The Actuator and the
audited instance of the event source are located on the server system. In
other words, Tivoli Compliance Insight Manager collects data directly from the
server itself. Tivoli Compliance Insight Manager controls the transfer of data.
2. Example 2 shows a configuration where the Actuator and the audited
instance of the event source are located on the same system, while the
server is hosted by another system. In other words, Tivoli Compliance Insight
Manager collects data directly from a Point of Presence (not equal to server).
82
7530ch04.fm
3. Example 3 shows a configuration similar to the previous one, but this time the
user arranges to transfer data from an audited system to a Point of Presence
(not equal to server), where the data is collected.
4. Example 4 shows the remote collection for Windows configuration, where the
audited instance of the event source is hosted by a system other than the
Point of Presence system, and the server system acts as a Point of Presence
for this event source. In other words, Tivoli Compliance Insight 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 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 Point of Presence to the audited system.
6. Example 6 shows Syslog and SNMP collection - the Tivoli Compliance Insight
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 on the network and receives all
incoming events. 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 both SNMP and Syslog messages. The Actuator,
server, and the audited instance of the event source are all hosted by
different systems. In other words, Tivoli Compliance Insight Manager collects
data directly from a remote audited system through a Point of Presence (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 Point of
Presence), from where a Point of Presence (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,
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 in a folder where it can be picked up
by the Actuator.
83
7530ch04.fm
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 finally shows the integration with IBM Tivoli Security Operations
Manager (TSOM). In Chapter 5, IBM Security Information and Event
Management on page 103 we cover the integration in more detail.
Based on the different Tivoli Compliance Insight Manager deployment options
shown in Figure 4-8 on page 82 and the various collect configuration examples,
we can show how a small, medium and large solution design could look like. We
start with an example of a small solution in Figure 4-9 on page 84.
Internet
DMZ
Production Zone
Intranet
Audited system
Audited system
Audited system
Target system
Audited system
Audited system
Audited system
PoP
PoP
Target system
Restricted
TCIM server
Console
Uncontrolled
Controlled
Secured
Controlled
Figure 4-9 Small Tivoli Compliance Insight Manager deployment
A small Tivoli Compliance Insight 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 the need in such environment.
For a more advanced environment with more audited systems and log forensics
requirement, 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,
84
7530ch04.fm
but have to implement some Points of Presence with Actuators. Figure 4-10 on
page 85 depicts how a medium Tivoli Compliance Insight Manager deployment
can look like.
Internet
DMZ
Audited system
Audited system
Audited system
Production Zone
Audited system
Audited system
Audited system
Audited system
Audited system
Audited system
Target system
PoP
PoP
Intranet
Audited system
Audited system
Audited system
Target system
PoP
PoP
Restricted
TCIM server
TCIM cluster
Uncontrolled
Controlled
Secured
Console
Controlled
Figure 4-10 Medium Tivoli Compliance Insight Manager deployment
Most demanding environments could involve multiple heterogeneous

environments with high performance, availability, and scalability requirements,
communication across dispersed locations, and so on. One possible Tivoli
Compliance Insight Manager deployment for such requirements is shown in
Figure 4-11.
85
7530ch04.fm
Internet
DMZ
Audited system
Audited system
Audited system
PoP
Production Zone
Audited system
Audited system
Audited system
Audited system
Audited system
Audited system
Target system
PoP
Intranet
Audited system
Audited system
Audited system
Target system
PoP
PoP
Restricted
Audited system
Audited system
Audited system
Syslog NG
TCIM
cluster
TCIM
server
TCIM cluster
TCIM cluster
Uncontrolled
Controlled
SAN
Secured
Console
Controlled
Figure 4-11 Large Tivoli Compliance Insight Manager deployment
For high scalability and performance there are multiple clusters deployed with
multiple Points of Presence serving different clusters. As shown with the line
coming from the Internet zone, there is consolidation among different
locations/regions in place. For high Syslog performance, the Syslog receiver is
implemented in the DMZ zone. For high availability all Tivoli Compliance Insight
Manager servers are connected to a Storage Area Network (SAN).
We will cover the design approach for our specific scenario in more detail in the
second part of the book in 7.3, Design approach on page 145.
4.1.3 Implementation
Before we start with the implementation, we verify that the recommended audit
settings are in place and that all systems are configured as suggested in the
prerequisites (we verify Tivoli Compliance Insight Manager servers hardware,
software/platform versions, audit settings, TCP/IP connectivity, and so on).
Here is a simple outline of the implementation steps:
1.
2.
3.
4.
5.
6.
86
Install server(s)
Install necessary POPs per platform type
Activate the event sources
Activate auditing for all event sources
Collect and load the data
Build the W7 model, policy, and attention rules
7530ch04.fm
7. Configure the alerts

8. Create/code the reports
9. Configure report distribution
Repeat step 6 to 7 for all reports per event source.
For details on the product installation and configuration see the IBM Tivoli
Compliance Insight Manager Installation Guide Version 8.0, GI11-8176-00.
We will cover the implementation approach for our specific scenario in more
detail in the second part of the book in 7.4, Implementation approach on
page 148.
4.1.4 Product use

During the product use phase we are facing the security improvement cycle. In
this cycle the policy exceptions are monitored and adjusted for improvement.
The effectiveness of the controls is reported and translated back to the security
objectives. Policies and reporting are constantly adjusted to reflect changes in
the organization and/or changes of assets. Policies are fine tuned to eliminate
events that belong to normal processes. Groups are modified on an as-needed
basis and all changes and settings are documented.
4.2 Operational design and configuration

In this section we discuss the aspects of Tivoli Compliance Insight Manager
solution design not directly related to the functional requirements. It deals with
the considerations to take into account when designing the non-functional and
operational aspects of implementing and maintaining Tivoli Compliance Insight
Manager deployment.
4.2.1 Monitoring and maintenance

In this section we cover general monitoring and maintenance procedures for
Tivoli Compliance Insight Manager to verify the overall state of the environment
on a daily, weekly and monthly basis.
Daily checks
On a daily basis all logons to the system and the status of the collected data
should be verified.
87
7530ch04.fm
Logons
Based on the Tivoli Compliance Insight Manager use role, granted access rights
should be verified for the following:
Management Console
After a successful logon, the Management Console displays the previously
opened view. Management Console logon failures are logged in the bbbin.log
file. You find these files in the IBM\TCIM\server\log directory. The system
prompts you with a Login has failed error message under the following
circumstances:
Password is incorrect
User ID is not authorized to use Management Console
User ID is unknown
Tivoli Compliance Insight Manager server service is down
Oracle service is down
If you are prompted with a connection error, verify the service status.
Web Portal
In order to access iView, Log Manager, Policy Generator and Scoping
applications you need to connect through the Tivoli Compliance Insight
Manager Portal as shown in Figure 4-12:
Figure 4-12 Tivoli Compliance Insight Manager portal
88
7530ch04.fm
If you receive a Page cannot be displayed error message, verify that the
following services are running. The service status can be verified using the
Windows Services application.
IIS service
Tomcat service
The system prompts you with the error message if the user name or
password is incorrect.
A user must have the Log on to Portal role to access iView. If you have not
been assigned this role, you receive the error Permission denied: insufficient
role privileges.
Data collection
To verify the data collection check the timestamp in the Last Collect column. In
our screenshot in Figure 4-13, we just set a new schedule for the z/OS event
source, so the data collection has not started yet, thus the Last Collect column is
empty. On the other hand, the data collection from the Oracle event source
worked as expected.
Figure 4-13 Tivoli Compliance Insight Manager data collection
The column shows the time of the oldest log record available in the last collected
chunk. In normal conditions, the last collect time should be a multiple of the
collect schedule. Verify this information for each event source that has a collect
schedule defined.
Database check
The database can be in one of the following four states, which can be checked in
the Management Console:
Error
Loaded
Loading
Cleared
The failure message and database contents can be seen in iView as shown in
Figure 4-14 below.
89
7530ch04.fm
Figure 4-14 Tivoli Compliance Insight Manager database status
The End time stamps for each platform shown in iView should be close to the
latest scheduled collect relative to the Last Load timestamp shown in the
Database View in the Management Console as shown in Figure 4-15. If this is
not the case, either the event source failed to collect the latest log records, or no
log records were produced between the end time and the collection time for that
platform.
Compare the time in the Last Load column with the Load Schedule frequency.
The last load time stamp should be a multiple of the load frequency defined in the
load schedule and as close as possible to the current time.
Figure 4-15 Tivoli Compliance Insight Manager database load
Database load problems can occur during the three phases of preparing the
reports in the GEM database:
Mapping
Loading
Post-processing
Every load process of a GEM database is recorded in the
mainmapper-<GEM_DB_Name>.log[#] files in the IBM\TCIM\server\log
directory.
Weekly checks
On a weekly basis disk space, Depot and Tivoli Compliance Insight Manager
services should be checked.
90
7530ch04.fm
Disk space
The device where the Tivoli Compliance Insight Manager server is installed
should have at least 20GB of free space.
The size of the temporary database file of the database engine located in the
IBM\TCIM\Engine10g\oradata\EPRORADB directory would be between 512MB
and 2GB.
Gemitems files in the IBM\TCIM\Server\run directory may be deleted for a

database if the database is not in load status.
Depot
The time stamps of the latest collected chunks should be as close to the current
time with relation to the defined collect schedules.
Services
All Tivoli Compliance Insight Manager services of startup type Automatic should
be running. The Tivoli Compliance Insight Manager server service spawns
additional tasks that can be seen in the task manager. These tasks are
agent.exe, auditctl.exe, and bbbin.exe.
In order to stop all services related to Tivoli Compliance Insight Manager, you
can use a batchfile like the one shown in Example 4-1:
Note: Both Example 4-1 and Example 4-2 are taken from our ITSO scenario.
For your specific configuration, you should replace the lines
net stop "IBM Tivoli Compliance Insight Manager Event Mapper DBname"
or
net start "IBM Tivoli Compliance Insight Manager Event Mapper DBname"
with the lines reflecting your GEM databases (DBname being Local, Manual
and SelfAudit in our example).
Example 4-1 Batch script to STOP Tivoli Compliance Insight Manager
@echo off
echo.
echo This script will STOP all TCIM services.
echo.
echo To abort this script close this window or use CRTL-C, otherwise press a key to proceed.
pause
echo.
echo Stopping IBM Tivoli Compliance Insight Manager Event Mapper Local service...
91
7530ch04.fm
echo.
net stop "IBM Tivoli Compliance Insight Manager Event Mapper Local"
echo.
echo Stopping IBM Tivoli Compliance Insight Manager Event Mapper Manual service...
echo.
net stop "IBM Tivoli Compliance Insight Manager Event Mapper Manual"
echo.
echo Stopping IBM Tivoli Compliance Insight Manager Event Mapper SelfAudit service...
echo.
net stop "IBM Tivoli Compliance Insight Manager Event Mapper SelfAudit"
echo.
echo Stopping IBM Tivoli Compliance Insight Manager Tomcat service...
echo.
net stop "IBM Tivoli Compliance Insight Manager Tomcat"
echo.
echo Stopping IBM Tivoli Compliance Insight Manager Server 8.0 service...
echo.
net stop "IBM Tivoli Compliance Insight Manager Server 8.0"
echo.
echo Stopping OracleCeAEngine10gTNSListener service...
echo.
net stop OracleCeAEngine10gTNSListener
echo.
echo Stopping OracleServiceEPRORADB service...
echo.
net stop OracleServiceEPRORADB
echo.
echo All services stopped. Press a key to proceed.
echo.
pause
In order to start all services related to Tivoli Compliance Insight Manager, you
can use a batchfile like the one shown in Example 4-2:
Example 4-2 Batch script to START Tivoli Compliance Insight Manager
@echo off
echo.
echo This script will START all TCIM services.
echo.
echo To abort this script close this window or use CRTL-C, otherwise press a key to proceed.
pause
echo.
echo Starting OracleServiceEPRORADB service...
echo.
net start OracleServiceEPRORADB
echo.
echo Starting OracleCeAEngine10gTNSListener service...
echo.
92
7530ch04.fm
net start OracleCeAEngine10gTNSListener

echo.
echo Starting IBM Tivoli Compliance Insight Manager Server 8.0 service...
echo.
net start "IBM Tivoli Compliance Insight Manager Server 8.0"
echo.
echo Starting IBM Tivoli Compliance Insight Manager Tomcat service...
echo.
net start "IBM Tivoli Compliance Insight Manager Tomcat"
echo.
echo Starting IBM Tivoli Compliance Insight Manager Event Mapper Local service...
echo.
net start "IBM Tivoli Compliance Insight Manager Event Mapper Local"
echo.
echo Starting IBM Tivoli Compliance Insight Manager Event Mapper Manual service...
echo.
net start "IBM Tivoli Compliance Insight Manager Event Mapper Manual"
echo.
echo Starting IBM Tivoli Compliance Insight Manager Event Mapper SelfAudit service...
echo.
net start "IBM Tivoli Compliance Insight Manager Event Mapper SelfAudit"
echo.
echo All services started. Press a key to proceed.
echo.
pause
Tasks
There are several schedules to be considered in a Tivoli Compliance Insight
Manager environment as shown in Figure 4-16.
93
7530ch04.fm
Figure 4-16 Tivoli Compliance Insight Manager tasks
Some of the tasks relate to synchronization between the Enterprise and

Standard Servers, and others relate to the collection of data and generation of
reports. The Standard Servers in a Tivoli Compliance Insight Manager cluster
are responsible for the collection of the log files and the generation of reports and
alerts. Both collection and report generation are normally scheduled through
Management Console in the Standard Server.
The schedules that should be synchronized for Standard Servers are collect,
load, restart, and report distribution.
The collect schedule depends on the amount of log data that the event source
produces. Collection on a daily basis, after regular office hours is suggested.
The user information source collection schedule should be prior to any last
collection of the day, before the load schedule runs. For example, if the last
collection of the day is at 10:00 p.m., the user information source collect
schedule should be a few minutes before 10:00 p.m.
As with the collect schedule, the load schedule should be sequential. That is, the
next load schedule should begin after the last load has completed. Analyze the
mainmapper log files related to the GEM database to determine how long it takes
to load the GEM database.
The restart task performs the following actions:
94
7530ch04.fm
Clears any unused memory and processes.

Performs maintenance on the Depot.
Runs a shrink table space task (during the daily restart on Sundays) to
optimize the size of the Tivoli Compliance Insight Manager database files.
The restart task should be scheduled before the start of the first scheduled daily
mapping. By looking at the database view in the Management Console, you can
determine when this first mapping takes place. This task should be scheduled
every 12 hours.
Report distribution should be scheduled after the load schedule has completed.
There are several job schedules that should be considered in the Enterprise
Server: consolidation, indexer, log continuity report generator and centralized
log management. The jobs that can be scheduled are consolidation and log
continuity report generator, since all others are scheduled automatically.
For reference, the centralized log management runs every minute and the
indexer is scheduled to re-index every Sunday at 10:00 p.m.
The consolidation job is represented by the beat.bat file on the Enterprise
Server. This job reads the aggregation databases from the Standard Servers and
copies the tables to the consolidation database (also referred to as the Beat
database) on the Enterprise Server. The aggregation databases are updated
during the post-processing job on a scheduled GEM database load. Therefore,
you should schedule the consolidation job after all GEM databases are loaded on
the Standard Servers.
The log continuity report generator job regenerates the continuity report in the
log manager. From the users point of view, it is helpful if this task is scheduled to
run at the beginning of each working day. The time it takes to generate the report
depends on the size of the Depot on the Standard Servers. The task can be
scheduled to begin around 6:00 a.m. so the report will be generated before the
working day begins.
The chunk continuity report generator (CCRG) job is implemented as a
scheduled task that can also be run on demand. When it runs, it searches the
Depot for chunks and determines if the chunks are complete and continuous. In
order to get this information, it looks at the chunk header files of each chunk and
fills the chunk continuity tables appropriately.
In a Tivoli Compliance Insight Manager environment, all log collection
information is consolidated on the Enterprise Server.
95
7530ch04.fm
Logs
For auditing, troubleshooting or any forensic activity related to the Tivoli
Compliance Insight Manager itself, it is important to identify and discuss the
purpose, location and content of various Tivoli Compliance Insight Manager log
files.
Server logs
All log files for the server can be found in the \server\log directory. The key files
are:
auditctl.log
Contains information about the collection of log files from the

event sources.
BBBin.log
Contains information about access to the management console.
install.log
Contains information about the initial installation of the server.
mainmapper-<GEM_DB_Name>.log
Contains information about the load process for the gem
database. Not only will you find errors but also indication of
mapper/bulk loading and postprocessing times.
plugger.log
Contains information about which platform plugs have been

applied during installation and the result of the installation.
restart.log
Contains information about the result of the daily scheduled

restart.
Consolidation logs
Key consolidation logs can be found in consolidation\log. The most important
logs are:
install.log
Contains information about the initial installation.
consolidation.log
Contains information about the scheduled beat task.
If automatic synchronization jobs between the Enterprise and Standard Servers

fail, an indication can be found in the log continuity report on the Enterprise
Server. It is not updated with the information of the Standard Servers or you can
see that the CCRG schedule is not synchronized on the Standard Servers.
Portal logs
Key Web Portal logs can be found in \iview\tomcat\logs. The most important logs
are:
96
InsightPortal_AuditTrail.log
Contains information about the usage of the

portal.
LogManager_AuditTrail.log
Contains information about the reports

generation.
7530ch04.fm
iView logs
Key iView logs can be found in \iview\log or iview\server. The most important
logs are
iview\log\Install.log
Contains information about the installation of

iView.
iview\server\Iview_excerpt.log
Contains information about reports sent out

by e-mail.
4.2.2 Archiving and information retention

Archiving and information retention has become an imperative when you want to
capture and preserve information for compliance reasons. Archive information
needs to be managed, retained and protected effectively, and then disposed of
properly when it is no longer needed. We can discuss Tivoli Compliance Insight
Manager archiving and information retention from many perspectives: disaster
recovery, high availability and regulatory, and so on.
There are no internal Tivoli Compliance Insight Manager tools you can use for
full disaster recovery, but you can implement any existing technology outside of
Tivoli Compliance Insight Manager such as Tivoli Storage Manager.
High availability is not an issue for Tivoli Compliance Insight Manager, because
data is not collected in real time, but instead based on a collection schedule.
When the system or network is not available at the time the collection of the logs
is attempted, Tivoli Compliance Insight Manager always begins log collection
from where it was last successful. This keeps log data from being missed due to
network or other system problems.
Tivoli Compliance Insight Manager provides the ability to store all the event data
in a compressed format on a Windows file system as individual chunks of log
information in a log Depot. As a result it is easy to integrate with a SAN archival
system for long term storage. From regulatory perspective it is important that the
log Depot is also monitored by Tivoli Compliance Insight Manager itself, as a
result any access to the raw log data is logged and reports can be run to ensure
that only proper access has occurred to the log data. The raw data remains in the
log Depot in an unaltered format. As a result the data can be used in legal
proceedings if required. We suggest the use of secure log management
solutions together with Tivoli Compliance Insight Manager, such as the IBM
System Storage DR550 and/or IBM System Storage DR550 Express, to meet
most stringent requirements on secure transmission and storage of regulatory
audit data:
Encryption and integrity verification in transit (Tivoli Compliance Insight
Manager)
97
7530ch04.fm
Encryption and immutability at rest (DR550)

Audit reports on continuity of logs (Tivoli Compliance Insight Manager)
The DR550 File System Gateway is designed to offer file archiving capability
without requiring any application enablement, and to provide Network File
System (NFS) and Common Internet File System (CIFS) file system access to
applications. You can find out more about DR550/DR550 Express on the Web at
the following locations:
http://www.ibm.com/systems/storage/disk/dr
http://www.ibm.com/systems/storage/disk/dr/express/
http://www.redbooks.ibm.com/cgi-bin/searchsite.cgi?query=dr550
Export and import

The export and import functionality in the Management Console gives you the
ability to back up data from the Depot. The Management Console has an
interface for defining a backup schedule and a target destination for the backup
as shown in Figure 4-17.
Figure 4-17 Tivoli Compliance Insight Manager backup
The idea behind this backup is that it moves the archived security data (chunks)
from the Depot to the backup media. This means that the moved chunks are no
longer available for selection when creating reports. To do this the chunks must
be imported again.
When you export data from the Depot it is flagged in the Log Manager as data
exported. So if you want to retrieve the original log data, then you can easily see
that the data is not in the Depot and needs to be imported.
The export schedule is defined using Management Console and the backup is
performed by the Tivoli Compliance Insight Manager server. Transferring
security data helps to maintain enough disk space on the Tivoli Compliance
Insight Manager server and because all chunks are registered within Tivoli
Compliance Insight Manager the tables in the database are also cleaned up.
98
7530ch04.fm
After the security data has been backed up using the export facility in the
Management Console, it is not available for reporting until it has been imported
again using the Management Console.
4.2.3 Performance and scalability

Tivoli Compliance Insight Manager scales in any direction, from a very small
installation to extremely large sites. Data is collected and loaded into databases.
You can organize data collections organization-wide, by platform, by application,
by department, by region, or any other segmentation that is meaningful and
specific to your organization. Insight can be configured to run on a Windows
system for smaller installations, or can use multi-processor threaded and
clustered systems for larger sites.
For scalability reasons Tivoli Compliance Insight Manager servers can be
deployed as multiple clusters as shown in Figure 4-11 on page 86, but for best
performance it is recommended not to put more then four Tivoli Compliance
Insight Manager servers into a single Tivoli Compliance Insight Manager cluster.
The Tivoli Compliance Insight Manager log collection architecture automatically
takes into account the possibility of high levels of log traffic and even network
and system outages. The collection method allows the native system to generate
log messages at its own rate and then we collect the logs on a schedule as
needed.
This architecture not only eliminates the possibility of our solution impacting the
native system log generation process, but also provides for when the system or
network is not available at the time collection of the logs is attempted. The Tivoli
Compliance Insight Manager always begins log collection from where it was last
successful. This keeps log data from being missed due to network or other
system problems. Via log continuity dashboard we can show any logs with
collection problems, or where log information contains time gaps.
Log collection is almost exclusively dependent on available network resources
and the disk subsystem performance at the collection point. Tivoli Compliance
Insight Manager provides several options for collecting Syslog data dependent
upon the requirements for performance:
Internal Syslog collector for mid range performance where message rates are
less than a thousand messages per second
External collection through the Syslog daemon, suitably configured, for
scalable, reliable high performance where message rates are in the tens of
thousands of events per second up to hundreds of thousands of events per
second as shown in Figure 4-11 on page 86.
99
7530ch04.fm
For better system performance and report distribution results, database load and
report distribution task schedules should be matched. For more information on
Tivoli Compliance Insight Manager reporting, see the IBM Tivoli Compliance
Insight Manager User Guide Version 8.0, SC23-6544-00.
4.2.4 Support
There are numerous options to find support for Tivoli Compliance Insight
Manager. If you encounter a problem, you want it resolved quickly, you can
search the available knowledge bases to determine whether the resolution to
your problem was already encountered and is already documented.
IBM provides extensive documentation in an information center that can be
installed on your local computer or on an Intranet server. You can use the search
function of this information center to query conceptual information, instructions
for completing tasks, reference information, and support documents.
If you cannot find an answer to your question in the information center, search
the Internet for the latest, most complete information that might help you resolve
your problem. You can search a variety of resources, which includes: IBM
Technotes, IBM downloads, IBM Redbooks, IBM developerWorks, Forums and
news groups, Google, and so on.
A product fix might be available to resolve your problem. To determine what fixes
are available for your IBM software product, check the product support on the
IBM Software support site:
http://www.ibm.com/software/support
For more information on Tivoli Compliance Insight Manager support, see the
IBM Tivoli Compliance Insight Manager Installation Guide Version 8.0,
GI11-8176-00.
Whether you are building a skills plan, or simply looking for educational
resources, we can help you define a software skills program that is right for you.
Select from a wide variety of training options from comprehensive training
portfolio, take advantage of extensive list of skills resources and communities
and verify skill level through role based certification. For more information visit
the Training and Certification Web site:
http://www.ibm.com/software/sw-training
That concludes the support section.
100
7530ch04.fm
4.3 Conclusion
You have to consider how compliance design objectives can be realized using
Tivoli Compliance Insight Manager. The goal is to produce a plan containing a
phased set of implementation steps where the end result satisfies the functional
requirements and therefore also satisfies the original business requirements.
While business and functional requirements are the main parts of the security
design objectives, we also have to consider other non-functional requirements
and constraints. These may include objectives that are necessary to meet
general business requirements, or practical constraints on designing the
compliance solution.
Prioritizing the monitoring and reporting requirements of the target systems and
applications is important because the priorities are one of the primary factors
used to decide which implementation tasks will be done in which phase of the
project. It is rare that a compliance management solution can be created as a
single deliverable satisfying every requirement on all targets. It is far more likely
that it will be delivered in phases and the highest priority requirements should be
included in the earliest phases.
After mapping the requirements to Tivoli Compliance Insight Manager features
and creating a list of implementation tasks, the priorities of each target and the
implementation effort for each target can be used to decided how to break up the
project into phases. The goal of breaking the project into phases is to quickly
deliver solutions to some high-priority requirements. This allows the company to
begin seeing a return on their investment, while lower priority and more difficult
tasks are still being executed.
That concludes the solution design. We continue with Chapter 5, IBM Security
Information and Event Management on page 103.
101
7530ch04.fm
102
7530ch05.fm
Chapter 5.
IBM Security Information

and Event Management
In this chapter we introduce the IBM Security Information and Event
Management solution as well as describing the differences between IBMs two
products Tivoli Security Operations Manager and Tivoli Compliance Insight
Manager and how the combination of the two provides a strong Security
Information and Event Management solution.
103
7530ch05.fm
5.1 Security Information and Event Management

Security Information and Event Management (SIEM) was briefly introduced in
Chapter 2, Architecting a compliance management solution on page 13. Let us
now take a closer how to more fully define SIEM and IBMs approach to it.
Many terms are used to describe this solution space and the discussion about
these terms between various vendors generally result in some level of argument.
For example, some of the terms that may be used include Security Information
Management, Security Event Management, Security Information and Event
Management, Enterprise Security Management, Log Management. There is not
much agreement about exactly what these terms mean and which products in
the market fit into which slot.
There are typically three broad areas of requirements in this space:
The capability of collecting and storing security log information in order to
support audit requirements and the ability to be able to demonstrate that the
required logs have been collected.
The ability to analyze security event data in real time for threat management.
Real time threat management generally being focussed on network related
information such as is produced by the myriad of network security devices
(firewalls, switches, routers, intrusion detection, vulnerability assessment and
so on).
The requirement to analyze and report on log data for security policy
compliance monitoring. This reporting requirement is typically focussed on
reporting and analysis of security events from host and application systems.
Based on these requirements an interpretation of what a SIM tool is and what a
SEM tool is would be as follows.
SIM provides reporting and analysis of data primarily from host systems and
applications, and secondarily from security devices to support security
policy compliance management, internal threat management and regulatory
compliance initiatives. SIM supports the monitoring and incident management
activities of the IT security organization, as well as the reporting needs of the
internal audit and compliance organizations.
SEM improves security incident response capabilities. SEM processes
near-real-time data from security devices, network devices and systems to
provide real-time event management for security operations. SEM helps IT
security operations personnel be more effective in responding to external and
internal threats.
104
7530ch05.fm
To achieve each of the goals of SIM and SEM you also need a strong supporting
security log management capability.
For our purposes and in alignment with how some market analysts are
describing Security Information and Event Management (see the Market
Definition introduced in Chapter 2, Architecting a compliance management
solution on page 13) we will refer to the combination of these capabilities (SIM,
SEM and log management) as a Security Information and Event Management
solution (or SIEM solution).
5.2 Introducing IBMs SIEM solution

IBMs Security Information and Event Management solution is a solution that
addresses the characteristics of a Security Information and Event Management
solution as described in the opening section of this chapter. The solution brings
two IBM products together combining the capabilities of the Tivoli Compliance
Insight Manager product and the Tivoli Security Operations Manager product.
In addition the SIEM solution offers some other capabilities that are often key
decision factors for organizations looking at these types of technologies.
Amongst these additional factors are:
A rapid and simple deployment and support process.
IBMs SIEM solution is modular, flexible and includes the capability to start an
implementation small addressing key aspects of an organizations
requirements and then grow to encompass the complete SIEM requirements
of an organization. As an example the Tivoli Security Operations Manager
component of the solution has often been recognized as a rapid return on
investment solution in this space. Sometimes organizations deploying SIEM
solutions will place emphasis in their evaluations on their vendor providing an
appliance type solution. IBM currently does not offer an appliance but
provides the flexibility of a rapidly deployed software solution. The installation
of the Tivoli Security Operations Manager component can take less than half
an hour on the various hardware and operating system platforms that it
supports. This means that an organization can focus on the configuration
activities that are more important during project implementation. Tivoli
Security Operations Manager configuration is almost completely Web-based
and can be considered very straightforward. Typically appliance based
solutions do not offer much flexibility, for example, in order to grow you only
have the option of buying more appliances. With the IBM solution you have
options, you can buy more hardware, increase the capacity of the hardware
you have, change the operating platform that it is running on and so on.
Chapter 5. IBM Security Information and Event Management
105
7530ch05.fm
Including security operations center console functions for large and complex
environments.
The Tivoli Security Operations Manager component provides complete
security operations functions, including dashboard views suitable for an
operations center, security incident management and service level reporting
capabilities and integration with leading ticketing systems. In addition it
provides security operators with the ability to be greatly more effective by
capturing their knowledge and incorporating it into threat and risk
management practices as well as allowing automation and remediation.
Integration with network analysis.
IBMs SIEM solution currently provides network statistical analysis functions
that mean that an organization can start to identify threats soon after the
solution is deployed without having to resort to writing specific threat
identification rules. The statistical analysis component compares background
noise against current threat levels before providing a threat/risk assessment
for each of the network nodes in an organization.
Have comprehensive user- and access-oriented analysis.
IBMs SIEM solution primarily via its Tivoli Compliance Insight Manager
component provides extremely detailed and comprehensive capabilities in
this area and is recognized as a leading and innovative solution primarily on
these capabilities. These capabilities are discussed in a great level of depth
throughout this book including practical examples in Part 2, Customer
environment on page 127 of the book.
Be integrated with a vendor's vulnerability management and systems
management products.
IBMs SIEM solution includes integration with key enterprise systems
management products such as IBM Tivoli Enterprise Console, IBM Tivoli
Netcool/Omnibus and other non-IBM system management products. This
integration means that the IBM SIEM solution can become a part of a large IT
Service Management solution and could leverage the capabilities of IBMs IT
Service Management strategy, including such factors as IBMs process
managers based on industry best practice. More information about IBM
Service Management is available at the following URL
http://www.ibm.com/software/tivoli/solutions/it-service-management/.
This integration also allows IBM to satisfy what for many organizations is the
vision of Network and Security Operations Center convergence (a recognized
best practice by many analysts).
The Tivoli Compliance Insight Manager component of the solution focuses on
tracking the interaction of users versus data and reporting this in terms of
compliance against a configurable audit policy. Tivoli Security Operations
Manager on the other hand focuses on real time identification of security related
106
7530ch05.fm
threats occurring throughout network and perimeter devices and management of

those threats in a security operations center. Tivoli Compliance Insight Manager
brings a depth of analysis capability to the SIEM space that other solutions are
unable to bring. The focus that Tivoli Compliance Insight Manager applies to
auditing and applying security policy to privileged users is not typical in the SIEM
space. By combining the two products into a single offering IBM has created an
extremely powerful SIEM solution.
5.3 The SIEM architecture

This section shows that the IBM SIEM architecture meets the goals of common
security information end event management. Figure 5-1 introduced in Chapter 2,
Architecting a compliance management solution on page 13 defines the
components of a SIEM solution. We address each of these components and how
they relate to IBMs solution below.
Figure 5-1 The SIEM architecture
107
7530ch05.fm
5.3.1 Event collection and retention of records

The IBM SIEM solution provides the ability to store all the event data in a secure,
compressed and efficient way. It includes the capability to do content searches
across the entire raw log depot when it is important to find critical information in
the raw logs. The raw logs are secure and when the logs are archived they are
stored for easy retrieval. If the need arises to research back dated logs, retrieval
of the data is straightforward. The logs, along with any policy and user role /
group information, are archived. Thus, when the raw data is retrieved not only
the data but all of the policy and user group / role information is restored. This
makes the analysis of archived data both efficient and accurate.
The log depot is also monitored by the IBM SIEM solution. As a result, access to
the raw log data is logged and reports can be run to ensure that only proper
access has occurred on the log data. The IBM SIEM solution includes a log
management portal where log management tasks are performed, collection
status is verified, and log management reporting is provided. The IBM SIEM log
management portal provides a complete log management solution that allows
the effective management of log collection activity.
Figure 5-2 The IBM SIEM log collection and record retention
The IBM SIEM architecture allows you to scale the solution to the size necessary
to meet the growing audit logging and monitoring requirements. The IBM SIEM
solution has a layered architecture. The data will be compressed and available
when required. For the analysis and reporting phase the data stored in the log
depot takes up only a fraction of the size of the original data. Only critical
information required for analysis, status reporting, audit reporting, and alerting is
extracted from the raw event logs and then normalized into an easy to read
format. It is common practice to define both a raw event log data retention policy
and a reporting / analysis database retention policy.
108
7530ch05.fm
Figure 5-3 IBM SIEM log analysis and reporting
The IBM Security Information and Event Management architecture provides you
with a solid log collection and storage foundation to build your solution.
5.3.2 Monitoring and correlation

The IBM SIEM solution supports an unprecedented number of event sources out
of the box. This allows you to collect much of your required log data without
having to create customized event source support.
The IBM SIEM architecture includes a multi-phased approach to event
correlation and analysis called deterministic threat analysis. This type of threat
analysis gives a security team the ability to detect known and unknown attacks,
internal misuse, misconfigurations and other anomalous activity. Using
deterministic threat analysis, every event goes through both computational
(policy based) and rule-based correlation. This establishes a base line from
which any change will be detected.
Computational correlation engine

Computational correlation involves the use of algorithms to assign values to
events or groups of events, based on factors such as the severity of the event or
109
7530ch05.fm
the weighting assigned to a particular asset. These values are derived from your
security policies and standards.
The IBM SIEM architecture uses two distinct techniques to perform
computational correlation on events gathered by the system. Impact correlation
relates to the calculations performed on individual events. Statistical correlation
determines the trends created by groups of events. Together, these two methods
of calculating threats provide a highly accurate and surprisingly easy to
administer method of prioritizing incidents of your network infrastructure without
the need to configure rules.
The IBM SIEM architecture makes it possible to consolidate information from the
network or insider attack that compromised the portal with the out of policy
database changes. Analysts using the IBM SIEM solution are able to see the
effects of an attack on applications and data as well as details of when it
occurred, what user identities were used, and how it was accomplished. Using
the comprehensive graphical interface, a non-technical user can focus on a
specific event that occurred on the database. They can extend their analysis to
view all activity by a particular user around the time of that event, including
activity on other systems. They can drill down into the details about a specific
event or database operation, and look at all events on the database or events for
a user on other systems around the time of a specific policy violation or alert.
They can pull up out of the box reports such as one on the actions of system
administrators to find out how a user was granted privileges and who granted
them. These capabilities allow auditors and administrators to determine not only
which user performed an action on a database, device, mail server or other
infrastructure component but the actions that were performed by privileged users
to grant that user the privileges they needed to perform actions that violated
policy.
Traditionally, to get the full breadth of capability that is required by many
organizations, both a security event management product and security
information management product would need to be purchased. These products
have traditionally been offered by different organizations and often did not work
well together. IBM is offering an industry leading security event management
solution, Tivoli Security Operations Manager, and an industry leading security
information management solution, Tivoli Compliance Insight Manager. By
combining these products IBM's SIEM solution can provide the most in-depth
security event analysis capability in the industry. While these products can be
used independently of each other, the combined capabilities enable you to
identify real time correlated events that occur in the network and tie these events
to user activity that has occurred related to these events. Associating real time
events with in-depth user information allows your organization to more quickly
understand the root cause of events and reduce the time required to respond to
an event, reduce the number of events that result in false positive alerts, and
110
7530ch05.fm
improve the ability to provide data to support regulatory requirements for both
compliance and audit.
Figure 5-4 The Tivoli Security Information and Event Management solution
Another key capability of the IBM SIEM solution is the support for remote store
logging and monitoring.
5.3.3 Logging standards

The IBM SIEM architecture is used by organizations that must comply with
stringent data logging standards. It helps support PCI, SOX, GLBA and many
other regulatory standards around the world.
The IBM SIEM architecture is designed to satisfy the needs of those reporting to
the CSO and CIO (security managers, administrators, and so on). The log
management layer of the IBM SIEM architecture automates the reliable,
verifiable collection and storage of organization log data, supporting the
organization's audit and compliance requirements. The IBM SIEM architecture
log management layer has the complete log management capabilities required to
rapidly and efficiently search voluminous native logs for forensic detail in support
of management's assertion that effective controls are in place for log collection
as required by policy and regulations.
111
7530ch05.fm
Log collection and management

The IBM SIEM scalable log manager component ensures that collection of the
original log data is reliable and verifiable, including rapid real-time collection of
tens of thousands of events per second.
For audit and compliance purposes all log data needs to be collected and stored
for later analysis, forensics or retrieval. The IBM SIEM architecture can collect
and index events from virtually any platform.
Auditors require organizations to prove their statements regarding reliable log
collection. The IBM SIEM log manager provides administrators with specific
information and reports to enable them to verify that collects are occurring on
schedule and to diagnose problems when they occur.
The collect history report shows all collect events, from both event source and
user information sources, which allows the administrator to maintain a reliable
log collection operation and provides assistance with the diagnosis of issues with
the collection process.
The log continuity report verifies the completeness of the collected data in as
much that all data that was originally stored into a chunk on the actuator machine
was transferred successfully to the collector server and is still in the depot at the
moment the chunk continuity report is created. In other words, it verifies that the
chunks in the depot are for a continuous chain, and that there are no missing
chunks. The report is run on a scheduled daily basis (at a specified time, for
example, 10.00 pm). The report shows both a graphic and a table of the log
continuity.
Forensic analysis may be required for specific audit and compliance
requirements or to investigate suspected incidents, possibly requiring reporting
across raw log data covering many months or even years. The IBM SIEM log
manager provides search and reporting tools that allow a query to be run against
all log data and across multiple Tivoli Compliance Insight Manager servers.
Activity anomalies are easier to investigate with log manager's activity grouping,
meaning that increases in areas such as network traffic are quickly identified for
operations and security personnel follow-up.
The IBM SIEM solution analyzes and translates the collected original raw audit
data into streams of common events that are stored in an internal database on
the IBM SIEM server. Translating all events into a single standard language and
storing them in a commonly used database system reduces the amount of
technical background needed by an auditor or security officer.
The IBM SIEM architecture is an event auditing solution that translates / maps
events into seven groups: Who, What, Where, When, on What, from Where, and
112
7530ch05.fm
Where to. Correlation of data is done automatically in existing reports. Within the
product, correlation across and within one or more of the seven W's is possible.
Once the mapping is complete the IBM SIEM compares the events to a policy
that provides alerting and reporting of abnormal and special attention events as
defined by the custom policy.
The IBM SIEM solution does not just rely on events logged in Syslog / SNMP
data which typically are generated by network and security devices, it can also
collect and analyze the native audit logs of operating systems, databases, and
applications. These systems should also be audited according to the common
criteria and best security practice, which is part of the standard installation
process.
5.4 IBM Tivoli Security Operations Manager

The IBM Tivoli Compliance Insight Manager product is the primary focus of this
Redbook and is very well described elsewhere, however, as described in the first
section of this chapter the Tivoli Security Operations Manager product is an
essential component of a complete Security Information and Event Management
solution. In this section we describe some of the capabilities of the Tivoli Security
Operations Manager product. If you are interested to get a more detailed
understanding refer to the IBM Redbooks deliverable Deployment Guide Series:
IBM Tivoli Security Operations Manager 4.1, SG24-7439-00 and Enterprise
Security Architecture Using IBM Tivoli Security Solutions, SG24-6014-04.
5.4.1 Product overview

Network and resource availability is absolutely critical to business and service
assurance. But organizations, federal agencies, and service providers can lose
millions of dollars per year as a result of worms and other types of malware that
bring down corporate resources and customer-facing services. That's why
information security is one of the top concerns of every CIO in any organization
or carrier.
To maximize resource and service availability and protect customer information,
today's information security teams must be able to:
Quickly recognize and handle security incidents.
Enforce security policies.
Support audit and compliance initiatives.
113
7530ch05.fm
The problem is that each of these activities involves security data that is
distributed throughout the organization. Organizations and service providers
need to be able to access and analyze this disparate dataquickly and
efficiently.
In today's complex, multivendor environments that means leveraging an
automated, integrated solution.
In response to these challenges IBM provides Tivoli Security Operations
Managera security event management platform designed to improve the
effectiveness, efficiency and visibility of security operations and information risk
management. Tivoli Security Operations Manager centralizes and stores security
data from throughout the technology infrastructure so that you can:
Automate log aggregation, correlation and analysis.
Recognize, investigate and respond to incidents automatically.
Streamline incident tracking and handling.
Enable monitoring and enforcement of policy.
Provide comprehensive reporting for compliance efforts.
Tivoli Security Operations Manager automates many repetitive, time- intensive
activities required for effective security operations. The result is an efficient,
cost-effective approach to security operations.
5.4.2 Centralize log aggregation in multivendor environments

To detect attacks, malware, potentially dangerous misconfigurations and internal
misuse, a security team must analyze reams of event data from throughout the
security infrastructure:
Intrusion detection systems
Firewalls
Virtual private networks
Antivirus applications
Plus, there is relevant information to be obtained from the typical IT or operations
infrastructure servers and hosts. Unfortunately, the volume of data and number
of disparate machines in a typical network can make manual analysis of security
data impossible. Consequently, it is important to automate the process of
aggregating events from disparate devices and systems into one central
locationwhere the data can be correlated to facilitate incident response and
reporting.
114
7530ch05.fm
Centralization and automatic aggregation of data is also important for

compliance efforts. Organizations often store their log data for extended periods
of time to enable historical analysis of log data, if necessary. Tivoli Security
Operations Manager provides a platform from which your organization can
automatically aggregate host logs, security events, asset data and vulnerability
data. You select how much data you want the software to draw inand from
which sourcesand Tivoli Security Operations Manager gathers the data using
standard and native protocols such as Extensible Markup Language (XML),
Syslog, Simple Network Management Protocol (SNMP), Simple Mail Transfer
Protocol (SMTP), CheckPoint OPSEC, Sourcefire eStreamer, and many more. It
can also use its own low-impact universal agent to collect information.
Tivoli Security Operations Manager supports the collection of event and log data
from hundreds of different devices today. Additionally, you can add support for
custom devices and internal applications. In an IBM SIEM solution environment
this collected data can then be passed to the Tivoli Compliance Insight Manager
component of the solution for log term log management.
5.4.3 Improve incident detection by correlating across devices

Drawing on information from across the infrastructure, Tivoli Security Operations
Manager can help you detect attacks, misuse and anomalous activity. The
software analyzes and prioritizes event data using four complementary
correlation techniques:
Rule-based correlation - detects known attacks and policy violations.
Vulnerability correlation - maps known attacks to known system
vulnerabilities.
Statistical correlation - identifies anomalies by performing advanced analysis
of events and hosts.
Susceptibility correlation - helps determine the likelihood of exposure for any
given system.
Additionally, Tivoli Security Operations Manager can use your business priorities
to weigh the importance of assets during the correlation process in order to
prioritize security activities. This is an important factor when attempting to comply
with the various compliance regulations that are mandatory for a well run
organization. When security analysts use the console, they see not an endless
list of security events, but meaningful information that has been prioritized in
alignment with your goals and policy.
115
7530ch05.fm
5.4.4 Reduce incident mitigation time

To help you drastically reduce the time it takes to handle attacks,
misconfigurations and misuse, Tivoli Security Operations Manager tightly
integrates its investigation and response tools. The software also facilitates the
escalation and tracking process. Investigative features include the following:
Integrated one-click investigation tools.
Automated responses to block threats and close the loop.
Geographic tracking of suspicious activity.
Security-oriented ticketing system.
5.4.5 Improve efficiency through operational integration

Tivoli Security Operations Manager addresses operational inefficiencies
experienced by siloed IT organizations by facilitating the flow of incident
management data between security, network and systems management
operations teams. For example, Tivoli Security Operations Manager integrates
closely with enterprise network and system management productsincluding
event managers and dashboards, as well as IBM Tivoli Enterprise Console,
IBM Tivoli Omnibus and IT help-desk ticketing systems, such as Remedy.
You can leverage these integrations to:
Support business and service assurance requirements.
Correlate security insights with information from the broader operations
environment.
Further facilitate incident remediation.
Tivoli Security Operations Manager also integrates with IBM Tivoli Identity
Manager and IBM Tivoli Access Manager for e-business to provide monitoring
and oversight for customer's identity and access policiesenforcing policies,
and quickly detecting and addressing potential misuse attempts.
5.4.6 Deepen understanding through comprehensive reporting

The on-the-fly data mining, historical reporting, self-auditing and tracking
capabilities in Tivoli Security Operations Manager provide critical components for
understanding security trends. What's more, these reports help IT communicate
relevant security information to other audiences, such as management and audit
teams.
Features include:
116
7530ch05.fm
Standard and customizable report templates.

An automated report scheduler.
HTML, PDF and XML exporting of all graphs and charts.
Self-auditing and tracking of all security activities.
Tivoli Security Operations Manager draws on information stored in a security
event database to deliver on demand historical reporting and trending.
5.4.7 Multiple deployment options to suit your environment

Tivoli Security Operations Manager features a modular architecture that can
adapt toand grow withyour organization's security infrastructure. Each of the
components, the event aggregation module that collects and normalizes data,
the central management server that performs advanced analysis and correlation,
and the database that stores historical information, can be distributed on
separate hardware, or the components can be deployed together.
An organization might deploy multiple event aggregation modules throughout the
organization to support higher volumes of event information or facilitate
geographic distribution of system resources. For example, one customer uses 12
event aggregation modules for its geographically dispersed locations, enabling
the organization to distribute data collection and processing. Similarly, the event
aggregation modules can all send data to a single central management server, or
an organization can use multiple servers to maximize availability, if one server is
unavailable to an event aggregation module, it will instead forward the event to a
secondary central management server.
5.4.8 Provide a platform for offering managed security services

In addition to serving as the critical IT security platform for midsize and large
organizations and carriers, Tivoli Security Operations Manager can also act as a
strong, proven foundation for a highly profitable managed security services
business. The same deployment options that make the software scalable and
stable for any organization also enables Tivoli Security Operations Manager to
meet the needs of a highly distributed services environment.
When used by managed security service providers, Tivoli Security Operations
Manager helps:
Reduce operational costs by offering a high degree of operational
automation.
Optimize time to value, thanks to speedy implementation and immediate,
out-of-the-box capabilities.
117
7530ch05.fm
Demonstrate service levels and value to customers through comprehensive

reporting capabilities.
5.4.9 Conclusion
Security breaches can have serious, measurable consequences: lost revenue,
downtime, damage to reputation, damage to IT assets, theft of proprietary or
customer information, clean-up and restoration costs, and potential litigation
costs. To reduce these risks, security organizations need the capability to quickly
identify and react to attacks.
Tivoli Security Operations Manager provides a holistic view of your security
posture and the abilities to drill down and investigate attacks quickly. As a result,
it is a valuable tool in helping to prevent intrusions and maximize the security of
your business.
For more technical details around Tivoli Security Operations Manager refer to
IBM Redbooks deliverables Deployment Guide Series: IBM Tivoli Security
Operations Manager 4.1, SG24-7439-00 and Enterprise Security Architecture
Using IBM Tivoli Security Solutions, SG24-6014-04.
5.5 Tivoli Compliance Insight Manager and Tivoli

Security Operations Manager complement each other
Often IBMs customers ask about the difference between Tivoli Security
Operations Manager and Tivoli Compliance Insight Manager. In this section we
attempt to explain that and why the two are required in a complete SIEM or
compliance solution.
5.5.1 Different groups have differing requirements

IBMs SIEM solution recognizes the fact that within most organizations different
groups have different requirements and that a complete solution should address
both IT Security and Line of Business Security.
IT Security typically addresses security threats, which is the focus of Tivoli
Security Operations Manager. Where as Line of Business Security primarily
addresses user security. Questions such as who can come in, what can they do,
and can I easily prove it to an auditor.
These types of functions are typically the responsibility of or focus of different
levels or groups within an organization. For example:
118
7530ch05.fm
C-level executive officers such as the Chief Information Officer (CIO) and
Chief Financial Officer (CFO) need to be able to demonstrate compliance with
regulations. The number of regulations that they need to be able to
demonstrate compliance for grows rapidly and includes for example,
Sarbanes-Oxley, SAS70, PCI, Basel II and so on. A key challenge for this
group of people is to keep up with the requirements of the various compliance
regulations that are developed.
The Chief Information Security Officer and audit groups are interested in
protecting intellectual property and ensuring privacy properly. Where as,
The technical security teams need to be able to manage security operations
and threats effectively and efficiently.
These differing requirements are more graphically illustrated in Figure 5-5.
Figure 5-5 Different groups have different requirements from a SIEM
The IBM SIEM solution combining Tivoli Compliance Insight Manager and Tivoli
Security Operations Manager addresses each of these differing requirements as
follows (graphically illustrated in Figure 5-6 on page 120). For the C-level officers
who need to be able to demonstrate compliance with regulations it provides a
compliance dashboard and reporting capabilities. These capabilities are
provided by the Tivoli Compliance Insight Manager component of the solution.
For the Chief Information Security Officer and audit teams who require the ability
to report on user behaviors it provides privileged user monitoring and audit,
database and application auditing, and operating system (including mainframe)
119
7530ch05.fm
auditing. These capabilities are provided almost completely by the Tivoli

Compliance Insight Manager component of the solution.
For the security technical teams who need to be able to manage security
operations effectively and efficiently the solution provides a security operations
dashboard that incorporates incident management, log management and
reporting capabilities, real time event correlation and integration with IT
Operations. This capability is provided almost completely by Tivoli Security
Operations Manager.
Figure 5-6 Market problems matched to IBMs SIEM solution capabilities
In a complete Security Information and Event Management solution the two

products Tivoli Compliance Insight Manager and Tivoli Security Operations
Manager complement each other. Each component may be implemented
individually with very little overlap, however, the full strength of a an integrated
SIEM solution can only be achieved by implementing both components together
and integrating them as is detailed in the rest of this chapter.
5.5.2 The combined strength

A little history: There are very few areas of overlap between the two products
today. That is incredible considering the differing heritages (both products came
from IBM acquisitions and were developed independently). Both products
supported data collection from very many sources (over 200 in the case of Tivoli
120
7530ch05.fm
Security Operations Manager). After the acquisition of the two products was
completed, an analysis revealed that only 31 sources were common with only 10
sources having strong relevance to both products. This reflects the different
focusses that were applied in the development of the two products. Tivoli
Security Operations Manager was developed with network security and threat
identification in mind. It was designed to perform high speed real time correlation
of events across differing platforms in order to identify incidents. Where as Tivoli
Compliance Insight Manager was designed to focus on the needs of business
users and to present security information in a way that they understand, for
example, in terms of who has done what to what when and where (for example,
by categorization of data using the W7 model). Tivoli Security Operations
Manager appeals to those who require the ability to identify in real time that a
particular host IP address is being attacked or is attacking. Where as Tivoli
Compliance Insight Manager maps data directly back to your users so that you
can identify, who of your known people is doing something that is not in
accordance with your policies.
The key area of overlap is in the collection of information from operating system
sources (see Figure 5-7 on page 122). For Unix and Linux systems this does not
provide any great complexity as these platforms typically use syslog. This means
that in a combined solution a single high speed syslog collector can be used to
satisfy the requirements of both components of the SIEM solution. Further the
Tivoli Compliance Insight Manager Windows Point of Presence used to collect
Windows event logs can also host the Tivoli Security Operations Manager real
time event collector for collection of Windows operating system generated
security events.
121
7530ch05.fm
Figure 5-7 Architectural view of the SIEM solution
5.5.3 SIEM integration scenarios

In this section we describe some user personas, the typical problems they face
combined with the appropriate high level SIEM solution that could be applied
today. In Chapter 12, Tivoli Security Operations Manager integration on
page 371 we describe in more detail the technical steps required to implement
some of these integration scenarios. Today the integration is performed using
the features that are integral to the two components.
User personas
Here are some of the user personas that may be interested in information
provided by a SIEM solution:
Network operations
Network administrators
Security administrators
Database administrators
Chief Information Security Officers
Internal auditors
External auditors
122
7530ch05.fm
Typical problems encountered

Some of the typical problems that these groups face are:
Real-time threat management
Network management
Failed audit
Requirements to comply with a new regulation
SIEM scenario 1 solution

In scenario 1 the persona is network operations who have a requirement to
correlate events, assess threats, and react in real time. For them the solution
may be just Tivoli Security Operations Manager. Implementation of this solution
is discussed in a great deal of detail in the IBM Redbooks deliverable
Deployment Guide Series: IBM Tivoli Security Operations Manager 4.1,
SG24-7439-00.

In scenario 2 the persona is the Chief Information Security Officer and internal
audit teams and the problem is failed audits or new requirements to comply with
regulations. In order to address the requirements for this group of people you
may only need to implement Tivoli Compliance Insight Manager. Implementation
of this component is the primary focus of Part 2, Customer environment on
page 127 of this IBM Redbooks deliverable.

In this scenario a customer uses Tivoli Security Operations Manager to monitor
and react to operational security threats and has implemented Tivoli Compliance
Insight Manager to provide audit and policy reporting capability. The customer
now wants an audit trail of actions taken by their security operators using Tivoli
Security Operations Manager and assess these against their policy.
In this scenario you utilize the integration that allows for Tivoli Security
Operations Manager to be an event source for Tivoli Compliance Insight
Manager. The benefits of this approach are that Tivoli Security Operations
Manager can react to events and take action. Tivoli Compliance Insight Manager
would provide the historical audit trail and policy based reporting for those
actions. This scenario is explored more fully in Chapter 12, Tivoli Security
Operations Manager integration on page 371 and serves as a good introduction
to some of the integration features provided by the two components.
123
7530ch05.fm

In this scenario the customer needs a basic log management implementation
that allows them to grow to a full featured SIEM solution at some point in the
future. This group of customers typically want to know that they have full log
coverage and be able to demonstrate this fact to auditors.
For this customer the Tivoli Compliance Insight Manager log management
features may be implemented. This allows collect failure and alerting via a
custom script as well as log continuity reporting to demonstrate full log coverage.
This scenario is covered in Chapter 8.1, Phase one auditing on page 158.

Some customers need to comply with the PCI data security standards and their
environment include z/OS as well as many Windows and Unix servers.
For these customers there is a requirement to be able to capture z/OS security
events along with network and other events and evaluate these against the
requirements of the PCI data security standards. The IBM SIEM solution is the
only solution that covers the full range of environments from network security, to
distributed systems, to z/OS. For this customer the z/OS logs are collected by
the Tivoli Compliance Insight Manager component and the majority of
compliance reporting is performed by Tivoli Compliance Insight Manager with the
network focussed controls required by PCI addressed by Tivoli Security
Operations Manager. This scenario is partially covered in Part 2, Customer
environment on page 127.

In this scenario an organization is after all the aspects that were identified as part
of a complete SIEM solution.
For example they want:
Security Information Management Reporting
Security Event Management Reporting
Including security dashboards, and compliance dashboards
Monitoring and correlation (both rules-based and policy-based correlation)
Minimization of the creation of specific rules
Forensic capabilities
Log management including
Record retention
Event collection across all platforms both network and applications tiers
124
7530ch05.fm
Security and network operations convergence

Support for IT Best Practices such as IBM's Service Management capabilities
Integration with best of breed network management products, identity and
access management capabilities
Incident and threat management capabilities
This requires a full SIEM solution. The rest of this book describes the capabilities
of Tivoli Compliance Insight Manager that supports these goals. While in
Chapter 12, Tivoli Security Operations Manager integration on page 371 we will
show the integration between the two components of the IBM SIEM solution that
allows these capabilities to be fully achieved.
5.6 Conclusion
In this chapter we explored the concepts of Security Information and Event
Management and illustrated how these concepts are supported by the IBM
Security Information and Event Management solution. Next we described how
the two components of the solution complement each other and highlighted the
differences in their capabilities. Finally we showed some of the basic use cases
and the way these use cases could be met with the components of the IBM SIEM
solution. The rest of this book describes how Tivoli Compliance Insight Manager
meets many of the requirements of SIEM whilst Chapter 12, Tivoli Security
Operations Manager integration on page 371 shows how the two components of
the SIEM solution are currently integrated.
125
7530ch05.fm
126
7530p02.fm
Part 2
Part
Customer
environment
This part illustrates a scenario about a fictional financial institution and describes
the implementation of security compliance management with Tivoli Compliance
Insight Manager.
127
7530p02.fm
128
7530ch06.fm
Chapter 6.
Introducing Tivoli Financial

Accounting Corporation
To illustrate the implementation of security compliance management with Tivoli
Compliance Insight Manager, we now want to discuss a scenario about a
fictional financial institution called Tivoli Financial Accounting Corporation
(TFAC). In this chapter we provide an introduction to the overall structure of the
Tivoli Financial Accounting Corporation including its company profile, its current
IT architecture and infrastructure, as well as its medium-term business vision and
objectives with regard to security compliance management.
Note: All names and references for company and other business institutions
used in this chapter are fictional. Any match with a real company or institution
is coincidental.
129
7530ch06.fm
6.1 Company profile

Tivoli Financial Accounting Corporation is a leading financial services company
with headquarters in Europe and operates in the European Union and in the
United States of America. Tivoli Financial Accounting Corporation offers private
banking and insurance products. Tivoli Financial Accounting Corporation started
as a privately held company and has recently been acquired by a large universal
bank in the Netherlands, which intends to make an initial public offering for Tivoli
Financial Accounting Corporation in six months on the New York stock
exchange. Tivoli Financial Accounting Corporation provides insurance products
to more than 500,000 european households and performs wealth management
for more than 61,000 private investors.
Note: The following sections describe company information that is relevant to
a security compliance management solution and uses an existing Tivoli
Security Operations Manager implementation. It also assumes that all the
systems to be monitored are already up and running. It is not intended to
provide a complete description of the company nor do the subsequent
chapters intend to cover all necessary activities surrounding the actual
implementation tasks.
6.2 Current IT infrastructure

Tivoli Financial Accounting Corporation has an IT environment with common
elements for financial services institutions. As with other banks, Tivoli Financial
Accounting Corporation has a long history of computing and today still performs
a majority of the processing of banking data on the mainframe. However, Tivoli
Financial Accounting Corporation has also entered the client-server-era. The
company has deployed MS Windows XP workstations to all branches and
manges them with Active Directory. Also, utility servers used for print and file
services run on MS Windows 2003 and Tivoli Financial Accounting Corporation
today runs business applications like SAP R3 on an Oracle Database on an MS
Windows environment. Due to the raising threads of internet attacks against
banks in the 90s, Tivoli Financial Accounting Corporation has established its own
security operations center in Brussels, which operates 24 by 7 and uses a Tivoli
Security Operations Manager deployment as its core to manage network security
devices on the corporate network perimeter and on key points in the internal
network infrastructure. Overall, the company stores approximately 246 Terabytes
of data from its business operations.
130
7530ch06.fm
Figure 6-1 IT Infrastructure of Tivoli Financial Accounting Corporation
Tivoli Financial Accounting Corporation uses one pair of fully resilient data
centers in Brussels, Belgium for their EU operations. These centers are also
hosting the mainframe system and a fully mirrored Storage Area Network for 150
Terabytes of data. The company also runs two smaller data centers in Newark,
New Jersey, USA to support US operations, which host 70 Terabytes of data.
The company uses two dedicated local data centers in Luxembourg, because
regulatory restrictions in Luxembourg prohibit export of banking customer data
outside of Luxembourg. The remaining storage of 26 Terabytes is allocated to
these data centers.
Chapter 6. Introducing Tivoli Financial Accounting Corporation
131
7530ch06.fm
Figure 6-2 Geographical distribution of Tivoli Financial Accounting Services
Tivoli Financial Accounting Corporation stores customer information and internal

financia data as well as HR data in all of these locations, and they intend to
monitor their compliance status in more detail. In a first step, the companys IT
operations have consolidated a table listing all major infrastructure assets and
their average log size per day as can be seen in Table 6-1 below. This is
equivalent to roughly one million events per hour.
Note: Table 6-1 only shows an excerpt from Tivoli Financial Accounting
Corporations compiled infrastructure assets. The intent here is to provide you
with an overview of their initial IT asset analysis.
Table 6-1 Major infrastructure assets and average log size per day
Application
Platform
Server
Name
File & Print
MS Windows 2003
EUHQ-FP
File & Print
MS Windows 2003
File & Print
MS Windows 2003
File & Print

File & Print
...
132
Log in
MB/day
Zone
Server Location
100
Intranet
Brussels HQ
BR1-FP
100
Intranet
Brussels 1
BR2-FP
100
Intranet
Brussels 2
MS Windows 2003
AM1-FP
100
Intranet
Amsterdam 1
MS Windows 2003
AM2-FP
100
Intranet
Amsterdam 2
...
...
...
...
...
7530ch06.fm

Application
Platform
Server
Name
Log in
MB/day
Zone
Workflow
MS Windows 2003
EUHQ-DO
10
Production
Brussels HQ
Workflow
IBM Lotus Domino
EUHQ-DO
100
Production
Brussels HQ
...
...
...
Database
Oracle Enterprise
LU-DB
Database
MS Windows 2003
Database
Oracle Enterprise
...
Server Location
...
...
500
Production
Luxembourg 1
USHQ-DB
10
Production
Newark HQ
USHQ-DB
750
Production
Newark HQ
SAP
AIX 5,3
EUHQ-SP
1000
Production
Brussels HQ
SAP
SAP R3
EUHQ-SP
100
Production
Brussels HQ
SAP
AIX 5,3
LU-SP
750
...
...
...
MF COREBANK
zOS LPAR1
EU-ANIT
MF BRATELLER
zOS LPAR2
EU-ASRU
MF EBANKING
zOS LPAR3
EU-AZEN
1500
SOC
RH Linux Enterprise
EUHQ-SO
10
SOC
IBM Tivoli SOM
EUHQ-SO
2500
...
...
...
Compliance
IBM Tivoli CIM
EUMF-SC
Compliance
MS Windows 2003
LU-SC
Compliance
IBM Tivoli CIM
SWIFT Connect
MS Windows 2003
MAIL Connect
RH Linux Enterprise
USHQ-MR
...
...
...
Production
Luxembourg 1
...
...
3000
Production
Brussels HQ
2000
Production
Brussels HQ
...
...
Production
Brussels HQ
Management
Brussels HQ
Management
Brussels HQ
...
...
200
Management
Brussels HQ
10
Management
Luxembourg 1
USHQ-SC
400
Management
Newark HQ
EUHQ-SW
250
DMZ
Brussels HQ
100
DMZ
Newark HQ
...
...
...
WEB Connect
MS Windows 2003
EUHQ-WW
WEB Connect
MS Windows 2003
LU-WW
100
DMZ
Brussels HQ
60
DMZ
Luxembourg 1
WEB Connect
MS Windows 2003
USHQ-WW
Network Device
Nokia, Cisco
various
100
25
DMZ
Newark HQ
Various
Various
Workstation
Windows XP
various
Various
Various
The table already includes the systems reserved for Tivoli Compliance Insight
Manager, listed under the application category Compliance. The table does not
list the shadow systems in the respective backup data centers.
6.3 Security compliance business objectives

Tivoli Financial Accounting Corporation tries to achieve objectives in the area of
security compliance management that are very similar to other financial
organizations and are summarized below.
133
7530ch06.fm
6.3.1 Comply to security requirements in the industry

As a leading European financial institution, Tivoli Financial Accounting
Corporation is obliged to protect the confidentiality, integrity and availability of
customer banking information. This makes effective security monitoring of its IT
environment essential. In order to protect the security of the customer
information appropriately, the company focusses on establishing and maintaining
a good IT security environment. A secure IT environment is achieved by
implementing and enforcing a comprehensive security policy framework
matching the IT infrastructure as well as its surrounding processes like system
administration and infrastructure monitoring and frequent performance of
auditing. Daily administration, authentication, and authorization to systems that
handle customer banking information are common security elements of their
everyday procedures. Due to the workload and the present cost constraints,
proper monitoring is limited and audit is often postponed. Besides customer
banking data, Tivoli Financial Accounting Corporation also must protect its own
business information, partially, as this is legally required, but primarily for its own
interest in protecting its intellectual capital and assets.
6.3.2 Maintain and demonstrate management control

In order to achieve a high level of control, Tivoli Financial Accounting Corporation
management wants security compliance monitoring to be able not only to see
what happened, but how it happened. Exceptions to defined security policy
requirements have to be identified, logged and communicated to management in
automatically generated reports. Tivoli Financial Accounting Corporation already
uses a well-known security management solution. However, this is more
network-focussed and does not meet the requirement of automatically reporting
exceptions on operating systems and middle-ware components of the
infrastructure" states Tivoli Financial Accounting Corporation Chief Information
Security Officer (CISO). "Monitoring and reporting would create too high of a
daily manual workload. Some staffmembers are already tracking logs, but with a
million server events, it is possible to monitor only a few systems, he explains.
On the other hand, he is well aware, that oversight has become essential for
management today and a solution must be found.
6.3.3 Integrate monitoring across a multi-platform environment

Tivoli Financial Accounting Corporation is looking for the ability to detect and to
deter unauthorized use of IT systems and access to customer and financial data
within the corporate perimeter; non-repudiation of transactions is essential for
financial institutions. Tivoli Financial Accounting Corporation does envision a tool
that enables them to collect and review the monitored data in a standardized
134
7530ch06.fm
language, one that can present this data in an comfortable, accessible way. The
internal audit department of Tivoli Financial Accounting Corporation wants all IT
systems to be audited. As a leading financial institution, they have to be sure that
everything is done by the rules and that no data can be misused by falling into
the hands of unauthorized users. "We need to know what is happening in the IT
environment. I would like to monitor all our assets at all times!" the Tivoli
Financial Accounting Corporation CISO says. For Tivoli Financial Accounting
Corporation this means all platform events have to be centrally collected and
reported. Having a fully automated tool that is capable of monitoring and
reporting across all of Tivoli Financial Accounting Corporations systems, where
classified information is handled, is a key requirement for the solution.
6.3.4 Harvest and structure information to specific needs

Tivoli Financial Accounting Corporations CISO states that they need a proven
set of capabilities that are very stable in operation, and that require only minor
daily attention. The solution needs to be able to expose potential security
breaches on their systems that require more detailed attention. At this time the
Tivoli Financial Accounting Corporation staff is only able to monitor a very limited
numbers of events, and if they spot exceptions, they are often unable to trace
their root causes. Tivoli Financial Accounting Corporation CISO: Our solution
needs to enable us to guarantee the high level of security that is fundamental for
a company in the financial business.
He continues: The actual collected data needs to be correlated in a way, that
allows easy grouping and filtering, so that we can monitor it more effectively,
investigate it thoroughly if required. Above all, the software must be able to report
the collected data in an aggregated manner to business people who are not
neccesarily experts in understanding bits and bytes! We would like to see our
reports being almost identical for all platforms. The solution needs to be highly
flexible and capable of supplying the required data in a form that can be routinely
utilized every day, without problems. The solution needs to fit in with Tivoli
Financial Accounting Corporations own way of working. The solution also needs
to be able to help supporting any future and current reporting requirements
derived from regulations like Basel II, Sarbanes-Oxley, and PCI.
Tivoli Financial Accounting Corporation CISO: When monitoring the last seven
days we expect to see upwards of 50 million events per week. It is paramount
that any solution will allow us to regularly update the exception qualifications in
order to save the auditors work. We want to be able to refine our security policy
on an ongoing basis and that the solution can be adopted easily to reflect these
changes. The solution should help Tivoli Financial Accounting Corporation with
the task of formalizing security policy requirements on the technical level by
providing support for the formalization of rules in accordance to requirements in
135
7530ch06.fm
their IT security policy framework. It should provide Tivoli Financial Accounting

Corporation the possibility to classify events as exceptions to these requirements
during the continuous monitoring process.
6.3.5 Establish a cost efficient and future proofed solution

Tivoli Financial Accounting Corporation wants to have comprehensive monitoring
of all security events, with automatic identification of potential security violations
and extensive reporting of the security posture. Besides these objectives, Tivoli
Financial Accounting Corporation intends to establish a solution, which will be
cost efficient and flexible to fit for future growth of the company and its IT
infrastructure. Ideally, the solution does not require more headcount than the IT
security and audit departments have today, but the new solution can drive the
efficiency of these resources. Tivoli Financial Accounting Corporation CISO:
Daily manual workload of our four compliance employees of the IT security team
needs to be reduced substantially. These colleagues are working one full-time
eight-hour shift, but only monitor our E-mail system and some key file servers in
the timeframe. To monitor all systems without a solution in place would mean an
unfeasibly large increase in staff. Also, we would like to have a solution that can
keep pace with the growth of the company and also with the ever-increasing
regulatory boundaries. We would like to be able to easily organize our Basel II
and Sarbanes-Oxley compliance on the IT level. We also envision that the
solution can help to distinguish mistakes signaled as unintentional errors from
the malicious activities.
6.4 Conclusion
We have introduced Tivoli Financial Accounting Corporation, a fictional financial
institution that will serve as an example scenario for the Tivoli Compliance Insight
Manager implementation outlined in the following chapters. We have discussed
the company profile, the current IT infrastructure, as well as the objectives with
regard to security compliance management. We will use this information to
design and to implement an appropriate compliance management solution.
136
7530ch07.fm
Chapter 7.
Compliance management
design
In this chapter, we describe the design approach that Tivoli Financial Accounting
Corporation will take in order to design a compliance management solution that
meets all their regulatory requirements. This discussion is divided into the
following sections:
Business requirements
Functional requirements
Design approach
Implementation approach
As described in Chapter 6, Introducing Tivoli Financial Accounting Corporation
on page 129, Tivoli Financial Accounting Corporation plans to list with the Stock
Exchange in six months time and they want to be prepared to meet their auditing
and reporting compliance needs. By using Tivoli Compliance Insight Manager as
the basis for their compliance management solution, Tivoli Financial Accounting
Corporation will be able to meet these regulatory requirements.
137
7530ch07.fm
7.1 Business requirements

Tivoli Financial Accounting Corporation would like to implement a compliance
management solution that they can customize for their environment.
Furthermore, they want a solution that can help them meet any future regulatory
requirements that may be introduced including SOX and PCI compliance.
Keeping regulatory compliance in mind, the CIO and the Information Security
team have identified three primary business requirements for their solution:
1. Implement processes to help achieve regulatory compliance. In particular,
monitor and report on user access to sensitive company assets. The sensitive
assets that need to be protected include the companys financial data, as well
as confidential customer data that is stored on their servers.
2. Monitor and audit the actions taken by privileged users for internal purposes.
The Tivoli Financial Accounting Corporation security representatives
recognize the need to monitor privileged users and their activities on key
corporate systems and data to ensure that confidentiality, integrity and the
availability of systems is properly maintained. This monitoring and auditing
can help prevent costly damages or outages due to inadvertent mistakes or
malicious actions of powerful users.
3. A centralized logging mechanism is needed. In order to meet regulatory
requirements, the IT security team would like to automate rapid, reliable log
file collection and management across their distributed IT environment, which
includes a variety of applications, operating systems and databases.
a. This logging mechanism needs to be configurable so that it can change as
the corporate requirements and reporting needs evolve.
b. Historical log data should be accessible in order to get a global view of
compliance.
Supporting business requirements were also identified as follows.
Reduce the costs of monitoring and auditing user access to company
resources by automating the process. This automated process should notify
key IT security personnel of certain situations including policy violations. As a
result, the manual processes and the costs associated with them can be
minimized.
The compliance management solution needs to have multi-platform support
so that it can monitor systems across Tivoli Financial Accounting
Corporations distributed IT environment. The automated monitoring process
should allow the corporate IT security policies to be defined and refined on an
ongoing basis, for example, when new systems are introduced to the IT
environment.
138
7530ch07.fm
The CIO wants to be able to quickly gain an overview of the corporate

security compliance posture. The security IT staff needs the ability to quickly
and easily generate reports that cover the internal security processes
including the actions of privileged users. Reports should be able to compare
user activities and security events to regulatory and acceptable use
frameworks.
7.2 Functional requirements

We extract functional requirements by mapping business requirements to their
underlying reasons. We expand the reasons in increasing detail until we find
problems that can be solved using capabilities of Tivoli Compliance Insight
Manager. Our functional requirements tie the low-level reasons for each
business requirement to a capability of the compliance management solution that
can be used to fulfill that business requirement.
Let us examine every business requirement, and search for reasons and the
functional requirements.
Business requirement 1: In order to be prepared for future regulatory
requirements, Tivoli Financial Accounting Corporation needs to monitor user
access to all sensitive company assets. This monitoring is important for two
key reasons. Firstly, there is the threat of employees misusing the data and
breaching privacy. Employees may fraudulently access and/or disclose
confidential information. The second primary issue is data integrity. It is
essential that the company ensures their data records are accurate and
complete. Therefore, Tivoli Financial Accounting Corporation must be able to
detect if someone tampers with critical data.
Tivoli Financial Accounting Corporation has corporate IT security policies
outlined to help prevent the misuse of sensitive assets. To enforce that these
IT security policies are being adhered to, they want to audit the logs of critical
systems and applications.
The sheer volume of logged events generated each day on these assets
means that monitoring them manually is infeasible. Tivoli Financial
Accounting Corporation wants to implement a compliance management
solution that enables total monitoring of all system events, with automatic
identification and reporting of potential security breaches.
The required log data can be generated by disparate targets located on
distributed systems across Tivoli Financial Accounting Corporations IT
environment. Therefore, the compliance management solution needs to have
multi-platform support to collect data from the critical systems including the
mainframe.
Chapter 7. Compliance management design
139
7530ch07.fm
Extracting relevant information from the raw logs manually can be difficult
because the format of logs is often quite incomprehensible. This can be
overcome by implementing a compliance management solution that is
capable of processing the log data and transforming it into a standardized
format that is easier to read. As described in Chapter 6, Introducing Tivoli
Financial Accounting Corporation on page 129, Tivoli Financial Accounting
Corporation would ideally like to be able to view this data through a
Web-based portal. They also like the ability to easily generate meaningful
reports to display the compliance information.
The key functional requirements for monitoring user access to sensitive
company assets are listed in Table 7-1.
Table 7-1 Functional requirements for monitoring user access to sensitive assets
Requirement
Description
The corporate IT security policies can be mapped into policies within

the compliance management solution.
Use of company assets are continuously monitored, with automatic

detection and reporting of potential security breaches.
The compliance management solution should have multi-platform

support including mainframes so that it can adapt to Tivoli Financial
Accounting Corporations unique IT environments.
The compliance management solution should transform the data

extracted from the logs into a readable, easy to comprehend format for
the end user. This should be available through a Web based portal.
The user should be able to easily generate reports regarding user

access to corporate assets.
Business requirement 2: Monitoring and auditing the actions of privileged

users is important. The reasons for this monitoring are very similar to those
described for monitoring all user access in business requirement 1 on page
139. A special focus on monitoring privileged users is necessary since they
have more authority than regular users to perform actions on corporate
systems. The IT security staff needs to know that privileged users are
managing data and systems as expected. Powerful users could mistakenly or
deliberately damage systems or information assets, which can be extremely
costly.
Theft or release of information assets is also one of the main drivers for this
monitoring. For example, if a senior executive is leaving the company to go to
a competitor then the IT security team may want to generate a report on that
individuals actions on confidential corporate data over the past month.
140
7530ch07.fm
Tivoli Financial Accounting Corporation must be able to verify that the

privileged users are behaving as expected and not violating the companys
internal IT security policies.
Table 7-2 describes the functional requirements for monitoring and auditing
the actions of privileged users.
Table 7-2 Functional requirements for monitoring and auditing privileged users
Requirement
Description
The administrators of the compliance management solution can define

the group of privileged users to be monitored.
The administrators of the compliance management solution can

specify which corporate data systems & assets contain critical data.
Policies can be configured to describe the access rights for privileged

users and the actions they are allowed to perform.
Reports can be generated automatically regarding privileged users

and their actions over a period of time.
Business requirement 3: A centralized logging mechanism should be at the

heart of the compliance management solution. Tivoli Financial Accounting
Corporation has hundreds of points across the enterprise generating log
events. Regulators and auditors require these log files to be captured and
retained. Additionally, Tivoli Financial Accounting Corporation wants to be
able to investigate any events that may represent internal or external threats.
Time and cost constraints mean that this log file management must be fast
and affordable. This logging requirement is closely linked to the previous two
requirements, which rely on using logs to monitor the actions of users.
In order to be fast and affordable the logging mechanism should have the
ability to automatically collect logs on a pre-defined schedule. The
mechanism should also have a backup and archival process in place to
ensure that no logs are lost. Auditors require the history of logs to be available
to prove that the log data is continually captured and to allow old events to be
investigated. The historical log data can be used to obtain an overall view of
compliance.
The functional requirements for the compliance management logging
mechanism are shown in Table 7-3.
Table 7-3 Functional requirements for logging mechanism
Requirement
Description
Automatic log collection can be scheduled.
141
7530ch07.fm
Requirement
Description
The logging mechanism should have a backup and archival process.
Logs should be retained so that the continuity of the logs can be

proven.
Business requirement 4: Reduce the costs of monitoring and auditing user

access to company resources. This requirement is also related to all the other
business requirements. As previously mentioned, in order to manually
monitor all systems, a large, infeasible increase in staff would be necessary
due to the following:
Amount of log data generated
Platform specific expertise required
Complexity of extracting meaningful information from each log
Time taken to compare each logged event with the corporate IT security
policies to identify any policy exceptions
Effort required to manually present the results in a meaningful report
Tivoli Financial Accounting Corporation has decided to implement an
automated compliance management solution to overcome these issues. This
compliance management solution needs to be flexible enough to cater for the
Tivoli Financial Accounting Corporations unique IT architecture and security
policies. To minimize the manual labor required, this automated process
needs to send an e-mail to members of Tivoli Financial Accounting
Corporations IT security team to notify them of suspicious activities including
policy violations.
The functional requirements to minimize the costs of monitoring and auditing
user actions are listed in Table 7-4.
Table 7-4 Functional requirements to reduce the manual labor required to monitor logs
Requirement
Description
Send an e-mail alert to IT security team when suspicious events

including policy violations occur.
All system events can be monitored and reported on automatically with

minimal manual labor required.
Business requirement 5: The compliance management solution should be

flexible enough to adapt to Tivoli Financial Accounting Corporations unique
IT environment. The IT environment can be expected to continuously evolve
142
7530ch07.fm
over time. There are a few main aspects of the IT environment that when
modified, will impact the compliance management solution:
Changes to the IT architecture
Changes to the IT personnel
Changes to the internal IT security policies governing the use of the
company assets
The architecture of Tivoli Financial Accounting Corporations IT environment
changes regularly as new systems are acquired, new uses are applied to
existing systems and old systems are retired. Therefore, it is essential that
when these changes occur, the compliance management solution can be
configured to access the logged audit data available on each of the IT
systems in use. In order to do this, it needs to have multi-platform support as
previously mentioned (please refer to Table 7-1 on page 140). Similarly, it is
important that the compliance management solution is able to collect and
process logs from a wide variety of different event sources on those target
systems. Ideally it should be flexible enough to monitor and process logs from
ANY event source provided those logs contain sufficient data in an
appropriate format.
Clearly, the compliance management solution is limited by what data is being
logged by each of the event sources. Therefore, appropriate audit settings
need to be identified and configured on the target systems. The auditing on
each target system can be referred to as an audit sub-system.
Changes to the IT personnel may include existing staff changing roles, new
staff being hired and staff leaving the company. Any of these personnel
changes need to be reflected in the structure of the compliance management
solution, which needs to compare the behavior of these users with the defined
security policies of allowable actions.
The corporate IT security policies themselves also need to be defined and
refined on an ongoing basis as the business grows. For example, when new
regulatory requirements are introduced, the business needs to be able to
create new policies, as well as modify the existing policies. Similarly, when
new assets are introduced into the system, a new audit-subsystem will need
to be established on the target system and new policies will need to be
established to monitor and audit the usage of the new asset.
Since the compliance management solution is reliant on the individual audit
sub-systems to obtain its data, it is important to maintain data integrity in the
logs on the target systems. To ensure the integrity is maintained, Tivoli
Financial Accounting Corporation needs their compliance management
solution to audit the actions performed on the audit sub-systems.
The configuration of the compliance management solution is extremely
important to ensure that the correct log data is audited. Therefore, only a
143
7530ch07.fm
restricted list of privileged users should be authorized to change the

compliance management solution itself and these changes should be
audited. This capability is referred to as self-auditing.
The functional requirements for the flexibility of the compliance management
solution are described in Table 7-5.
Table 7-5 Functional requirements for flexibility in the compliance management solution
Requirement
Description
Be flexible enough to monitor and audit logs from ANY event source,
provided the log contains sufficient data in an appropriate format.
Policies can be created, modified and deleted by the administrator of

the compliance management solution.
The compliance management solution will need to monitor the audit

sub-systems.
The compliance management solution should have self-auditing

capability.
Business requirement 6: The compliance management solution needs to

have extensive reporting capabilities. After the log data has been collected
and stored, it needs to be analyzed to get an overview of Tivoli Financial
Accounting Corporations compliance. For example, the logged events need
to be compared with the IT security policies to find any violations and other
potential threats.
Rather than having to this process manually, Tivoli Financial Accounting
Corporation want to automatically generate reports to display meaningful
compliance information that has been extracted from the logged data. These
reports can assist the company to demonstrate their SOX compliance.
Since Tivoli Financial Accounting Corporation want to be prepared to
introduce SOX and PCI compliance in the future, sample report templates for
the different regulatory requirements like SOX can be a very useful starting
point. Tivoli Financial Accounting Corporation needs to determine exactly
which reports they want to generate for their unique IT environment and
exactly how they would like them to be presented. The compliance
management solution needs to allow new customized reports to be created
so that Tivoli Financial Accounting Corporation can create reports that are
useful for their IT security staff. These customized reports will allow them to
actively enforce their security policies and meet their regulatory requirements.
Table 7-6 shows the functional requirements for reporting.
144
7530ch07.fm
Table 7-6 Functional requirements for reporting

Requirement
Description
Sample report templates will be available to assist with meeting

regulatory requirements such as SOX in the future.
The compliance management solution will have the ability to

customize reports.
7.3 Design approach

Let us now consider how compliance design objectives can be realized using
Tivoli Compliance Insight Manager. Our goal is to produce a plan containing a
phased set of implementation steps where the end result satisfies the functional
requirements and therefore also satisfies the original business requirements.
While business and functional requirements are the main parts of the security
design objectives, we also have to consider other non-functional requirements
and constraints. These may include objectives that are necessary to meet
general business requirements, or practical constraints on designing the
compliance solution. Tivoli Compliance Insight Manager implementations often
include non-functional requirements relating to the following areas. For further
information on some of these compliance management non-functional
requirements, please refer back to Chapter 4, Compliance management solution
design on page 73:
High availability
Backup and recovery
Performance and capacity
Change management
Existing infrastructure
Budget and staffing
Non-functional requirements are outside the scope that is covered by the
scenario implementation within this book. We focus on the use of Tivoli
Compliance Insight Manager to meet the functional requirements for the scenario
as outlined in 7.2, Functional requirements on page 139.
The steps involved in producing an implementation plan are described below.
Steps 1-5 encompass the Discovery and Analysis phase of design, while steps
6-7 are required as part of the Project Definition and Planning phase. These
145
7530ch07.fm
phases are described in Chapter 4, Compliance management solution design

on page 73.
1. Determine what reports need to be generated for Tivoli Financial Accounting
Corporation to monitor their compliance.
Note: The reports that are needed should be based on the existing IT
security policies that are in place. Tivoli Compliance Insight Manager
provides component modules with sample report templates and policy
rules to assist with requirements for regulations such as Basel II and
Sarbanes Oxley in the future. These templates can then be customized for
Tivoli Financial Accounting Corporations specific needs.
2. Decide which target assets should be monitored to produce these reports.
3. Identify what data needs to be collected from each event source on the target
machines and whether the auditing on that system can be configured to log
the required event details.
Note: If it is not possible for sufficient data to be captured in the target
system logs, then it is not possible to audit and report on that type of event.
4. Ensure that Tivoli Compliance Insight Manager has the ability to monitor audit
trails from that event source.
Note: A complete list of supported event sources for Tivoli Compliance
Insight Manager can be found at ***location of event source list***. If the
event source is not supported, you could consider using the W7LogSDK
toolkit to create logs that can be processed by Tivoli Compliance Insight
Manager. The W7LogSDK is described in 3.4, The W7LogSDK on
page 59.
5. Prioritize the monitoring and reporting requirements for the various target
systems and applications.
6. Complete a pre-planning worksheet to cover all of the target event sources.
7. Divide the tasks into phases.
Prioritizing the monitoring and reporting requirements of the target systems and
applications is important because the priorities are one of the primary factors
used to decide which implementation tasks will be done in which phase of the
project. It is rare that a compliance management solution can be created as a
single deliverable satisfying every requirement on all targets. It is far more likely
146
7530ch07.fm
that it will be delivered in phases and the highest priority requirements should be
included in the earliest phases.
Assigning priorities to the requirements is often difficult because They are all
important. You can more easily compare the priorities of the target systems and
applications by performing a risk assessment1. The targets that are identified as
being a high risk can then be treated as the highest priority. A simple way to
calculate risk is to use the following formula:
Risk = Impact * Likelihood
The Impact component should be a 1-10 rating that represents the impact or
consequence for the business if a threat is realized. The impact should be judged
by business experts and should take into account both the short term and the
long term effect on the business.
The likelihood of a threat occurring can also be rated on a 10 point scale, from 1
indicating that it is extremely unlikely to occur through to 10 indicating that the
event is very likely to occur on a daily basis. The technical experts are probably
in the best position to evaluate the likelihood of each threat.
Asking yourself some questions that gauge the positive and negative impacts of
the requirements for each target may also help you with your prioritization:
How much money can be saved by automating the auditing of this target?
How sensitive is the data stored on this target?
Are there existing mechanisms or processes in place for auditing the target,
which will be sufficient for now?
What is the complexity of monitoring this target? Does Tivoli Compliance
Insight Manager provide an Actuator that supports this event source?
After mapping the requirements to Tivoli Compliance Insight Manager features
and creating a list of implementation tasks, the priorities of each target and the
implementation effort for each target can be used to decided how to break up the
project into phases. The goal of breaking the project into phases is to quickly
deliver solutions to some high-priority requirements. This allows the company to
begin seeing a return on their investment, while lower priority and more difficult
tasks are still being executed.
To learn more about risk management you may want to refer to the Risk Management Guide for
Information Technology Systems from the NIST
(http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf) or check out the IT
Security Cookbook at http://www.boran.com/security/index.html.
147
7530ch07.fm
7.4 Implementation approach

This section applies the design approach described in 7.3, Design approach on
page 145 to Tivoli Financial Accounting Corporations specific requirements. It is
beyond the scope of this redbook to show the full design and analysis for Tivoli
Financial Accounting Corporation. The remainder of this chapter summarizes the
result of applying the design analysis to Tivoli Financial Accounting Corporations
environment and describes the overall phased implementation plan.
7.4.1 Determine what reports need to be generated

First, we are going to look at the different report requirements.
Internal IT security policies

The logging requirements for the IT security policy were described in Chapter 6,
Introducing Tivoli Financial Accounting Corporation on page 129 as follows:
All logon attempts, both successful and failed
All attempts to access classified resources
All denied attempts to access all resources
Use of privileged user id
Use of user id with system privilege
Administrators actions in the access control system
All attempts to access resources belonging to access control systems
Regulatory requirements
Being a financial corporation, Tivoli Financial Accounting Corporation would
initially like to align its reporting with Basel II. However, the company also wants
to be able to adjust their reports and policies in the future to accommodate other
regulations such as SOX and PCI when necessary.
The set of reports listed in Table 7-7 has been identified as a starting point for
them. You notice that many of these reports can be generated from the data
collected for the internal IT security policy requirements (the numbers in the
brackets refer to sections in ISO 17799).
Table 7-7 Initial Basel II reporting goals
Basel II report
Description
Security alert (6.3, 8.1.3)
Alerts sent in response to policy exceptions or special

attention exceptions.
148
7530ch07.fm
Basel II report
Description
Operational change control (8.1.2)
Changes to the operating environment such as system

updates, DBA activity, and so on.
Operator log (8.4.2)
Actions performed by the IT Admin staff.
Review of user access rights (9.2.4, 9.7)
Actions performed by administrators on users.
System access and use (9.2.4.c, 9.7)
Successes and failures against key assets.
User responsibilities and password use

(9.3)
Logon failures and successes either locally or remotely.
User identification and authentication

(9.5.3)
Logon and logoff successes and failures.
Application access control (9.6)
Actions, Exceptions and events on HR Data, Sensitive Data,

User Sensitive Data, System, Financial Data, Proprietary
Data and General Data.
Information access restrictions (9.6.1)
Who accessed sensitive or private data successfully or

unsuccessfully.
Sensitive system isolation (9.6.2)
Exceptions and failures against sensitive systems data in

asset groups User, HR Data, Source Code, and Financial
Data.
Logging and reviewing events (9.7.2.3)
Exceptions and failures recorded by the Tivoli Compliance

Insight Manager system.
Control of operational software (10.4.1)
Exceptions and failures caused by updating or changing of

critical system components.
Data access (12.1.4)
Exceptions and failures against HR, Sensitive and

Proprietary data.
7.4.2 Monitoring target assets for reports

For reports to be meaningful, it is important that we identify the target systems
and applications for which each of the reports should be generated.
Table 7-8 shows the classifications of Tivoli Financial Accounting Corporations
current assets. You can refer back to Chapter 6, Introducing Tivoli Financial
Accounting Corporation on page 129 for the details of Tivoli Financial
Accounting Corporations IT environment.
149
7530ch07.fm
Table 7-8 Classification of Tivoli Financial Accounting Corporations systems and event sources
Event Source
Classification
Windows XP workstations
Internal use - non confidential. It is company policy

not to store confidential data on workstations.
Deemed a low risk.
No
File & Print W2K3 servers
Internal use - in Intranet zone.
Yes
Tivoli Security Operations

Manager servers
Confidential - in Management zone.
Yes
Tivoli Compliance Insight

Manager servers
Confidential - in Management zone.
Yes
DMZ machines
Demilitarized zone - No confidential data is stored

on these servers. Some confidential data will pass
through these machines, but it is deemed low risk
due to controls already in place.
No
z/OS mainframe
Confidential data including customer, hr and

financial data in DB2.
Yes
DB2 on z/OS
Confidential data including customer, hr and

financial data.
Yes
AIX
Confidential corporate data in SAP.
Yes
SAP (on AIX)
Confidential data.
Yes
W2K3 servers (Lotus

Domino hosts)
Sensitive data in Domino.
Yes
Domino
Sensitive data in internal e-mails.
Yes
Red Hat Linux syslog

consolidation
Internal use - Tivoli Security Operations Manager

EAM.
Yes
W2K3 server (Oracle hosts)
Confidential data in Oracle.
Yes
Oracle
Confidential corporate data.
Yes
Win2K3 Domain Controllers
Sensitive corporate data.
Yes
Active Directory
Sensitive corporate data.
Yes
150
Monitor with
Tivoli Compliance
Insight Manager?
7530ch07.fm
7.4.3 Identify what data needs to be collected from each event source
Each of the individual reports need to be analyzed and a list of the event details
that are needed from each event source need to be identified. Once the list of
required attributes has been determined, the audit subsystem of the target
system can be investigated to determine whether audit settings exist that will
produce logs containing the required details.
If it is not possible to generate the required log data then that report can not be
produced for that particular system.
Tivoli Financial Accounting Corporation has analyzed the audit subsystems for all
of the event sources that are to be monitored by Tivoli Compliance Insight
Manager (as described in Table 7-8). It has been determined that it is possible to
collect sufficient data from each of these audit subsystems for the purposes of
monitoring and reporting on these event sources.
7.4.4 Ensure that Tivoli Compliance Insight Manager has the ability to
monitor audit trails from that event source
Next we have to look through the list of event sources and compare it against the
list of supported Tivoli Compliance Insight Manager event sources.
Table 7-9 Tivoli Compliance Insight Manager support for event sources
Event Source
TCIM Support for TOFTs environment
AIX OS
Yes - IBM AIX audit logs
W2K3 OS
Yes - Microsoft Windows Security Event

Log
Active Directory
Yes - Active Directory is supported by the

Windows Actuator
Red Hat Linux OS
Yes - Red Hat Linux syslog
Mainframe
Yes - IBM z/OS
DB2
Yes - IBM DB2 on z/OS
Oracle
Yes - Oracle DBMS on Windows
SAP
Yes - SAP R/3 on AIX
Domino
Yes - IBM Lotus Domino Server on

Windows
151
7530ch07.fm
Event Source
TCIM Support for TOFTs environment
Tivoli Security Operations Manager
Yes - Tivoli Compliance Insight

Manager/Tivoli Security Operations
Manager integration capabilities
Yes - Self-audit capabilities
7.4.5 Prioritize the target systems and applications

The set of administrative or high privileged accounts can be viewed as an asset
that has a high impact once compromised. The systems are quite vulnerable to
privileged access because they are only protected by a user id, password and
account locks, and are exposed to anyone who is using the system. The
privileged user accounts should therefore be monitored with high priority.
The set of sensitive business data once compromised would also have a high
impact, but they are less vulnerable because they are protected by ACLs,
encryption, and authentication. The exposure is also lower because you do not
know where these assets are physically located and how to access them.
Therefore monitoring the controls that manage these sensitive assets is of a
lower priority.
As a result, Tivoli Financial Accounting Corporation wants to prioritize monitoring
the privileged users asset controls first with Tivoli Compliance Insight Manager
and then expand the monitoring to address all access to sensitive assets based
on the results of the corporate risk assessment.
They also spent time prioritizing the different event sources. The existing controls
that are in place on the various systems helped them to determine which
systems and applications were the highest priority. For example, the Windows
servers were deemed to be a high priority because of their exposure. The
Windows servers contain confidential information and are used consistently by
all employees. With only limited access controls and monitors currently in place,
the Windows servers are classified as a relatively high risk. Meanwhile, z/OS
was not considered as high a risk. The mainframe does contain highly
confidential data, but because the IT security team already has strong controls
and processes in place for restricting and monitoring access to this resource, it
was deemed a lower risk than other systems. This process of comparing the
risks associated with individual event sources helped Tivoli Financial Accounting
Corporation in planning their phased Tivoli Compliance Insight Manager
deployment.
152
7530ch07.fm
7.4.6 Planning deployment

Tivoli Financial Accounting Corporation has completed a pre-planning worksheet
for all of the event sources that are going to be monitored using Tivoli
Compliance Insight Manager. The worksheet helped them to plan their
compliance management solution.
Based on the data captured during this planning phase, Tivoli Financial
Accounting Corporation has determined that for their current IT architecture they
will use a Tivoli Compliance Insight Manager cluster comprised of two Standard
Servers and one Enterprise Server. This decision was based on the fact that
each Standard Server is capable of processing up to 16 GB of log data per day.
You can refer back to Chapter 6, Introducing Tivoli Financial Accounting
Corporation on page 129 for details on the expected amount of log data from
each of Tivoli Financial Accounting Corporations event sources.
One Standard Server will be used for the z/OS and DB2 event sources, while the
other Standard Server will process the other event sources.
Figure 7-1 shows the planned high level design for Tivoli Financial Accounting
Corporations compliance management solution. As you can see, some systems
in the Production Zone are audited through locally installed Actuators, while
other auditing is done through agentless/remote collections depending on which
event source is being monitored.
Figure 7-1 Planned Tivoli Compliance Insight Manager solution design
153
7530ch07.fm
7.4.7 Divide the tasks into phases

After completing the planning phase and undertaking a comprehensive risk
assessment of Tivoli Financial Accounting Corporations IT environment, the
implementation of the compliance management solution has been divided into
five separate phases. With each new phase, Tivoli Financial Accounting
Corporation will expand their compliance management solution. These phases
are outlined below in Table 7-10.
Table 7-10 Implementation phases
Phase
Number
Name
Description
Windows Basic
Auditing
Initially, Tivoli Financial Accounting Corporation

wants to implement basic log management and
auditing functionality for their Windows event
sources with basic reporting.
Extended
Auditing
Phase 2 expands the centralized log

management and auditing to include AIX, SAP,
Domino, and Oracle with basic reporting.
Reporting
requirements
In this phase we introduce more extensive

reporting including report distribution. The
reports created in this phase are focused on
presenting data for the purposes of
demonstrating regulatory compliance.
System z
integration
The System z servers that store critical data also

need to be compliant. Therefore, we want the
centralized Tivoli Compliance Insight Manager
solution to include these machines.
Tivoli Security
Operations
Manager
integration
Tivoli Financial Accounting Corporation would

like to realize the full benefits of using both Tivoli
Compliance Insight Manager and Tivoli Security
Operations Manager by integrating the two
products to fulfill their compliance needs. This
includes monitoring the Red Hat syslog
consolidation servers.
7.5 Conclusion
In this chapter, we described the design approach that was taken by Tivoli
Financial Accounting Corporation in order to design their compliance
management solution using Tivoli Compliance Insight Manager. We outlined the
154
7530ch07.fm
business requirements and the associated functional requirements. Once these

requirements were identified, the design approach was outlined. When applied to
their unique IT environment, this process of design and analysis helped Tivoli
Financial Accounting Corporation to devise an implementation plan. They have
decided to deploy their Tivoli Compliance Insight Manager solution through five
phases of implementation:
1. Basic auditing of Windows event sources
2. Extended auditing of AIX, SAP, Domino and Oracle
3. Implement reporting requirements
4. System z integration
5. Tivoli Security Operations Manager integration
The remaining chapters of this book describe each of these implementation
phases in detail.
155
7530ch07.fm
156
Chapter 8.
7530ch08.fm
Basic auditing
In this chapter we describe the implementation for phase one of Tivoli Financial
Accounting Corporations compliance management solution using Tivoli
Compliance Insight Manager. As outlined in Chapter 7, Compliance
management design on page 137, in phase one they plan to install a Tivoli
Compliance Insight Manager cluster. For this phase, they monitor the actions of
their Windows domain users by installing local Windows Actuators and configure
a Microsoft Windows event source for each Windows server. An Active Directory
event source is also configured on the Windows Domain Controllers. The audit
subsystem on each Windows server has to be configured to generate sufficient
log information. Appropriate W7 groups and rules are established through the
Management Console and ultimately, the iView Compliance Dashboard is used
to monitor user actions.
157
7530ch08.fm
8.1 Phase one auditing

Figure 8-1 shows the initial IT architecture. This architecture was described in
detail in Chapter 6, Introducing Tivoli Financial Accounting Corporation on
page 129. In phase one, the Tivoli Compliance Insight Manager servers are
installed and configured and the Windows 2003 servers including the Active
Directory server are going to be monitored. These server groups have been
highlighted in bold, underlined text in the diagram.
Figure 8-1 Tivoli Financial Accounting Corporation IT architecture
Auditing needs to be configured on each of the Windows 2003 target machines.

As described in Chapter 7, Compliance management design on page 137,
Tivoli Financial Accounting Corporation initially wants to focus their audit on the
actions of privileged users as a result of the risk assessment. In particular, they
want to monitor the logons, both successful and failed, as well as access to
critical data shares.
User logons should be monitored on all of the Windows servers. Additionally,
Active Directory have to be monitored as a separate event source on the Active
Directory servers.
158
7530ch08.fm
The critical data shares reside on the Windows 2003 file and print servers shown
in the Intranet zone of Figure 8-1 on page 158. The share folders to be audited
have been identified as:
C:\Finance
C:\HR
C:\CustomerData
Print Share: C:\WINDOWS\system32\spool
Finally, the Tivoli Compliance Insight Manager servers need to be enabled for
self-auditing.
8.2 Install Tivoli Compliance Insight Manager cluster

For phase one, Tivoli Financial Accounting Corporation will deply an Enterprise
Server with a single Standard Server belonging to it. Therefore, both of these
Tivoli Compliance Insight Manager servers need to be installed and configured
on Windows 2003 servers, shown in the Management Zone of Figure 8-1.
8.2.1 Install Enterprise Server

Installation of the Enterprise Server consists of the following procedures:
1. Install the database engine provided with Tivoli Compliance Insight Manager.
2. Install the desired Tivoli Compliance Insight Manager components for the
Enterprise Server.
3. Configure the Consolidation Server.
Note: Tivoli Financial Accounting Corporation will mostly use the default
values when installing the server, but have opted to change the default OS
account and database account user names.
OS Account: cearoot_os
Database Account: cearoot_db
You can refer to the IBM Tivoli Compliance Insight Manager Installation Guide
Version 8.0, GI11-8176-00 for more information about the Enterprise Server
installation process.
Chapter 8. Basic auditing
159
7530ch08.fm
8.2.2 Install Standard Server

The installation of the Standard Server is very similar to the installation of the
Enterprise Server.
The steps for the Standard Server installation are as follows:
Standard Server.
3. Register the Standard Server with the Enterprise Server.
For more details on each of these steps you can refer to the IBM Tivoli
Compliance Insight Manager Installation Guide Version 8.0, GI11-8176-00.
8.3 Phase one reporting requirements

As described in Table 8-1, Tivoli Financial Accounting Corporation have identified
key reporting requirements to aid in their compliance management. For phase
one of the implementation, the following reporting is desired (the numbers in the
brackets refer to sections in ISO 17799):
Table 8-1 Initial Basel II reporting goals
Basel II report
Description

attention exceptions.

updates, DBA activity, and so on.
Actions performed by the IT Admin staff.
Actions performed by administrators on users.
Successes and failures against key assets.

(9.3)
Logon failures and successes either locally or remotely.

(9.5.3)

Data and General Data.
160
7530ch08.fm
Basel II report
Description

unsuccessfully.

Data.

Insight Manager system.

critical system components.

Proprietary data.
8.4 Enabling and configuring auditing

All of the Windows 2003 servers need to have appropriate audit policies
configured so that the Windows Security logs contain sufficient information. In
this section we describe the settings that are configured for all of the Windows
2003 servers, as well settings specific to the Active Directory and file/print
servers.
8.4.1 Auditing settings for the Windows Security log

The Microsoft Management Console (MMC) can be used to set the Audit Policy
for the Windows servers. We follow these steps to configure the policy on the
Windows servers:
1. Go to Start All Programs Administrative Tools Local Security
Policy
2. In the left hand menu, navigate to the Local Policies Audit Policy
3. Set the Audit Policy to log appropriate events. For Tivoli Financial Accounting
Corporations reporting requirements, the audit policy shown in Figure 8-2 is
configured on each Windows 2003 Server.
161
7530ch08.fm
Figure 8-2 Local Audit Policy settings
Note: The Audit object access option is only set to Success/Failure on the
file and print servers that host confidential file shares. On the other Windows
servers in Tivoli Financial Accounting Corporations environment the Audit
object access is set to No auditing.
8.4.2 Active Directory audit policy settings

The Tivoli Financial Accounting Corporation Active Directory servers are hosted
on Windows 2003. The Windows local audit policy settings should be configured
on the Active Directory servers. Configure appropriate settings through
Administrative Tools Domain Security Policy and Administrative
Tools Domain Controller Security Policy.
Tivoli Financial Accounting Corporation wants to closely monitor the actions of
their domain users. Figure 8-3 displays the domain security audit policy settings
that are being used on the Windows 2003 Active Directory servers. The same
auditing is also configured in the Default Domain Controller security settings.
162
7530ch08.fm
Figure 8-3 Domain security settings
By default, the Active Directory is configured to log critical and error events only.
Only change this behavior if a detailed investigation is needed, because
extensive logging of events can quickly consume data storage space.
The following types of events that can be written to the event log are defined in
the Active Directory:
1. Knowledge Consistency Checker (KCC)
2. Security Events
3. ExDS Interface Events
4. MAPI Events
5. Replication Events
6. Garbage Collection
7. Internal Configuration
8. Directory Access
9. Internal Processing
10.Performance Counters
11.Initialization/Termination
12.Service Control
13.Name Resolution
14.Backup
15.Field Engineering
16.LDAP Interface Events
17.Setup
18.Global Catalog
19.Inter-Site Messaging
163
7530ch08.fm
Microsoft has defined six levels of diagnostic logging for the Active Directory:
0 - (None)
Only critical events and error events are logged at this level.
1 - (Minimal)
Very high-level events are recorded in the event log at this

setting.
2 - (Basic)
Events with a logging level of 2 or lower are logged.
3 - (Extensive) Events with a logging level of 3 or lower are logged.

4 - (Verbose)
Events with a logging level of 4 or lower are logged.
5 - (Internal)
All events are logged, including debug strings and configuration
Tivoli Financial Accounting Corporation has decided to perform a high level of

logging on Security Events and Directory Access. We apply these settings
through the registry as follows:
1. Run regedit.exe on the Active Directory target machine.
2. Navigate to the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Di
agnostics
3. Assign a value from 0 - 5 for each of the available REG_DWORD values in
this Diagnostics subkey. The values configured for Tivoli Financial
Accounting Corporations Active Directory servers are shown in Figure 8-4.
164
7530ch08.fm
Figure 8-4 Registry settings for Active Directory diagnostic event logging
4. Close regedit.
Note: Tivoli Financial Accounting Corporation uses an Active Directory forest.
The worked example in this chapter describes the monitoring of a single
Active Directory server only. In reality, to complete the Tivoli Compliance
Insight Manager compliance management solution for Tivoli Financial
Accounting Corporation, the process for monitoring the single Active Directory
server in this chapter has to be repeated for each member of the forest.
8.4.3 File server settings - object access auditing

As described in 8.1, Phase one auditing on page 158, the following Windows
2003 file shares contain sensitive data that needs to be monitored:
165
7530ch08.fm
C:\Finance
C:\HR
C:\CustomerData
Print Share: C:\WINDOWS\system32\spool
In this section we describe how to monitor and audit one of these file shares
(C:\Finance). Tivoli Financial Accounting Corporation has to repeat this process
for all of the shared folders that need to be audited.
To enable and configure auditing of access to the C:\Finance folder, we complete
the following steps on the target file and print servers.
1. Open Windows Explorer, right click on the shared folder and select
Properties as shown in Figure 8-5.
Figure 8-5 Folder properties
2. Click on the Security tab and then the Advanced button, as shown in
Figure 8-6.
166
7530ch08.fm
Figure 8-6 Advanced Security options
3. Select the Auditing tab. Figure 8-7 shows the default contents of this tab.
167
7530ch08.fm
Figure 8-7 Auditing Security settings for a Windows folder
4. Configure auditing for a new user or group by clicking Add. An input box is
displayed. We enter the name of the user group to be monitored and click
OK. In Figure 8-8, the Domain Users group has been added because all
authenticated users of the Tivoli Financial Accounting Corporation systems
are contained in this group.
168
7530ch08.fm
Figure 8-8 Select User, Computer or Group input box
5. An Auditing Entry window for the selected folder is displayed. We elect to

Apply onto this folder, subfolders and files using the available drop down
menu. We then set the appropriate Access options in the check boxes before
clicking OK. As you can see in Figure 8-9, Tivoli Financial Accounting
Corporation has elected to monitor the create, read, write and delete access
to this folder, as well as all subfolders and files.
169
7530ch08.fm
Figure 8-9 Auditing Entry window
6. The new auditing entry now appears in the Advanced Security Settings
window as shown in Figure 8-10.
170
7530ch08.fm
Figure 8-10 The new auditing entry is displayed in the Advanced Security Settings
window
7. Click OK to close.
Remember to repeat steps 1 through 7 for the other involved file shares.
8.5 Configuring Standard Server for new event sources

Now that the audit subsystems have been configured on the target machines, the
Tivoli Compliance Insight Manager Standard Server needs to be configured to
monitor the Windows targets. This configuration involves the following high level
steps in the Tivoli Compliance Insight Manager Management Console.
1. Create a GEM database to store the event data
2. Create a Windows Machine Group and add the machines to be audited
3. Add the individual event sources for each target machine
171
7530ch08.fm
Each of these steps are outlined in sections 8.5.1, Create GEM database,
8.5.2, Create system group and add Windows machines, and 8.5.3, Add event
sources.
8.5.1 Create GEM database

In the database view of the Management Console we are able to create a new
GEM database for loading Windows event data as follows.
1. Open the Tivoli Compliance Insight Manager Management Console.
2. Switch to the Database View.
3. Select Database Add GEM Database
4. The Add GEM Database window appears. Fill out the name and size for the
new database and click OK. Tivoli Financial Accounting Corporation will be
storing all Windows event data in a database called General, as shown in
Figure 8-11. The size for the GEM database, here 16GB, has been
determined by the raw log data estimates in 6.2, Current IT infrastructure on
page 130.
Figure 8-11 Add GEM Database
5. Figure 8-12 shows how the new database appears in the Database View.
Figure 8-12 New database
8.5.2 Create system group and add Windows machines

In order for Tivoli Compliance Insight Manager to monitor one or more event
sources on a particular machine, the audited machine needs to be registered in
172
7530ch08.fm
the Management Console. If desired, the registered machines can be grouped

together into system groups to organize the audited systems.
Tivoli Financial Accounting Corporation wants to group their audited Windows
machines into a system group called WindowsSystems in the Machine View of
the Management Console.
Create Windows system group

In this section we describe how to create a system group from the Machine View
window.
1. From the Machine View in the Management Console, select
System Create Machine Group. The Create Machine Group window is
displayed.
2. Type a name for the new machine group in the New group name field (see
Figure 8-13).
Figure 8-13 Create machine group
3. Click OK to confirm the action.

4. The new Machine Group is now displayed in the Machine View window.
Add Windows target machines

Each of the Windows 2003 servers to be audited needs to be added as a new
machine. Tivoli Financial Accounting Corporation places each of its Windows
targets into the new WindowsSystems group. In this section, the setup and
configuration for auditing one of Tivoli Financial Accounting Corporations
domain controller servers (FSPDC) is shown. Tivoli Financial Accounting
Corporation has to repeat this process for adding the other Windows target
machines.
Here are the steps we perform to add each machine:
1. Right click on the WindowsSystems machine group shown in the
Management Console Machine View and select Add Machine. The Add
Machine Wizard begins (see Figure 8-14).
173
7530ch08.fm
Figure 8-14 Add Machine Wizard
2. Select the Audited Machine Type from the available drop-down menu. For
Tivoli Financial Accounting Corporations Windows 2003 servers, the correct
machine type is Microsoft Windows, highlighted in Figure 8-15. Select Next.
174
7530ch08.fm
Figure 8-15 Choose Machine Type
3. Enter the name of the target machine(s) to be audited in the Name input box
within the Machine frame and click on the Add button. As illustrated in
Figure 8-16, the machine name now appears in the Selected frame. Click
Next.
Note: Checking the Show Available Event Source Types box causes the
Event Source Type panel on the right hand side of the screen to appear. This
allows you to browse the supported event sources for the type of machine you
are adding.
175
7530ch08.fm
Figure 8-16 Choose Audited Machines
4. A local Actuator will be installed on each of the target machines. This option is
selected in Figure 8-17. Click Next.
Figure 8-17 Select Point of Presence
176
7530ch08.fm
5. The default port that is used for the Point of Presence is 5992. We check the
availability of the configured port by clicking on the Test Port button. In this
window we can choose to perform either an Automatic or a Manual install. For
demonstration purposes, we show a manual Actuator installation on a single
Windows 2003 target system (FSPDC), as shown in Figure 8-18. When
adding the remaining Windows 2003 server machines in Tivoli Compliance
Insight Manager, Tivoli Financial Accounting Corporation can use the option
of automatically installing the Windows Actuators on the targets.
Figure 8-18 Configure new Point of Presence
6. The port we have configured is available, so the message box shown in

Figure 8-19 is displayed. We click OK on the Test IP and Port message box
and click Next in the New Point of Presence window to advance the Wizard.
Figure 8-19 Test Port success
7. The Choose Event Source Type window appears. For the FSPDC machine,
which is an Active Directory Domain controller, both Microsoft Active
177
7530ch08.fm
Directory and Microsoft Windows have been selected (see Figure 8-20).
Select Next.
Note: When adding the Windows 2003 server machines that are not Active
Directory servers, only the Microsoft Windows event source would be
selected.
Figure 8-20 Choose Event Source Type
8. Figure 8-21 shows the Completing the Add Machine Wizard window that
appears. Click Finish to complete the Add Machine setup.
178
7530ch08.fm
Figure 8-21 Complete Add Machine Wizard
Note: During the Add Machine Wizard a configuration file is created. This file
is needed when you install the Actuator on your target machine(s).
8.5.3 Add event sources

Immediately after the Add Machine wizard completes, the Event Source wizard
automatically runs once for each event source that was selected in step 7 in the
previous section Add Windows target machines on page 173.
For the FSPDC domain controller that has just been added, the wizard runs
twice: once for Microsoft Active Directory and once for Microsoft Windows.
In this section we illustrate how to complete the Add Event Source Wizard for the
Microsoft Active Directory event source on the FSPDC Windows server. The
wizard for the Microsoft Windows event source on FSPDC is similar and so are
the wizards for each of Tivoli Financial Accounting Corporations other Windows
server event sources.
The steps that follow describe how to complete the Microsoft Active Directory
Event Source wizard for the FSPDC server:
1. Click Next on the Event Source Wizard welcome screen that is displayed as
shown in Figure 8-22.
179
7530ch08.fm
Figure 8-22 Add Event Source Wizard
2. The Choose an Audit Policy Profile window is displayed. Tivoli Financial

Accounting Corporation has already configured the audit subsystems on each
of the target machines and wants Tivoli Compliance Insight Manager to leave
those existing settings. Therefore, the option None is selected in Figure 8-23.
Click Next.
180
7530ch08.fm
Figure 8-23 Choose an Audit Policy Profile
3. The next window that appears allows us to choose a collect schedule (see
Figure 8-24). A collect schedule should be tuned to prevent audit trail loss
because the event log overwrites itself. We configure the desired schedule
and click Next.
181
7530ch08.fm
Figure 8-24 Choose a Collect Schedule
4. The next screen prompts us to select the GEM database where the data
collected from this event source should be loaded. Tivoli Financial Accounting
Corporation loads all Windows events in the GEM database called GENERAL
that was created in 8.5.1, Create GEM database on page 172. We select
GENERAL as shown in Figure 8-23 and click Next.
Note: Data collected from your FSPDC machine is first stored in the
Depot. At load time it will be loaded into the GEM database, here
GENERAL.
182
7530ch08.fm
Figure 8-25 Choose a GEM database
5. Figure 8-26 shows the next screen that is displayed. This screen allows us to
configure a Load schedule for loading the data from the event source into the
GEM database. The Load schedule should be related to the Collect schedule
that was configured in step 3. Configure the Load schedule and click Next.
Note: In general, set load frequency to an interval as long as or longer than
the collect schedule interval. For example, data may be collected hourly,
and loaded twice a day. It is unlikely that you would want to collect data
twice a day, and load it hourly.
Set the load schedule time at least 15 minutes after each scheduled
collection time. This delay ensures that Tivoli Compliance Insight Manager
loads the most recently collected data into the database.
183
7530ch08.fm
Figure 8-26 Choose a Load schedule
The Event Source Wizard is now complete and the final screen shown in
Figure 8-27 is displayed. Click on the Finish button.
184
7530ch08.fm
Figure 8-27 Complete the Add Event Source Wizard
8.6 Installing an Actuator on target machine

The manual install type was selected when adding the FSPDC machine through
the Add Machine wizard in step 5 of Add Windows target machines on
page 173. Therefore, the Windows Actuator needs to be manually installed on
the FSPDC Windows server.
In this section we describe the process of installing the Actuator locally on the
Windows 2003 server called FSPDC.
1. Start the installation wizard on the Tivoli Compliance Insight Manager
Windows CD 2 of 2. The Setup.exe file is located in the NT directory. The
Welcome screen in Figure 8-28 is displayed. Click Next.
185
7530ch08.fm
Figure 8-28 Welcome screen of installation wizard
2. You are presented with the License Agreement screen (see Figure 8-29).
After agreeing with the License terms and conditions click Yes to proceed
with the installation.
186
7530ch08.fm
Figure 8-29 License Agreement
3. Figure 8-30 shows the Choose Setup screen for the installation wizard.
Select Point of Presence to install a Windows Actuator on the FSPDC server
and click Next.
187
7530ch08.fm
Figure 8-30 Choose Setup screen
4. Enter the path to the installation directory. The default location C:\IBM\TCIM
is being used on the FSPDC server as shown in Figure 8-31. Click Next.
188
7530ch08.fm
Figure 8-31 General Installation Directory
5. Figure 8-32 shows the next screen. It confirms the target directory based on
the installation directory selected on the previous screen. Click Next to
proceed.
189
7530ch08.fm
Figure 8-32 Target Directory
6. The Select Configuration File screen is displayed as shown in Figure 8-33.

In order to complete this screen, the configuration file, that was created when
running the Add Machine Wizard, needs to be made available to the FSPDC
server.
Note: The default location for this config file on the Tivoli Compliance
Insight Manager Standard Server is
<TCIMHomeDir>\Server\config\machines\<TargetMachineName>-<TCIMSer
verName>.cfg
We copied this config file to the FSPDC server, enter the complete path to the
file locally and click Next.
190
7530ch08.fm
Figure 8-33 Select Configuration File
7. The Enter OS Account screen allows us to configure an operating system

account that will be used to run the Tivoli Compliance Insight Manager
Actuator service (refer to Figure 8-34). Tivoli Financial Accounting
Corporation is using an account called cearoot_os. Click Next.
Note: In this case we are using a local account, however you can also use
a Domain account.
191
7530ch08.fm
Figure 8-34 Enter OS Account
8. The setup process is performed. A Setup Status screen is displayed to

monitor the progress of the setup tasks as shown in Figure 8-35.
Figure 8-35 Setup Status
9. The Updates Overview screen shown in Figure 8-36 outlines the installed
components. Click Next.
192
7530ch08.fm
Figure 8-36 Updates Overview
10.The Actuator Installation Wizard is now complete and the Setup Finished
screen appears (see Figure 8-37). Click Finish.
Figure 8-37 Setup Completion
193
7530ch08.fm
8.7 Configuring W7
Now that the audit sub-systems have been configured on the Windows servers
and the event sources have been registered with Tivoli Compliance Insight
Manager, the W7 rules can be configured on the Standard Server. In particular,
the groups need to be defined, along with appropriate W7 policy and attention
rules.
In this section we describe the process of setting up the W7 rules for the Tivoli
Financial Accounting Corporations Windows event sources.
Adding User Information Source

In order to create meaningful policy and attention rules, it is important to define
W7 groups that represent the structure of your IT environment.
To assist with creating these W7 groups, Tivoli Compliance Insight Manager
allows you to import grouping data from an existing User Information Source
(UIS).
Tivoli Financial Accounting Corporation imports the user information from Active
Directory on the FSPDC server to simplify the creation of their W7 grouping
definitions.
The following steps illustrate how to import this UIS data.
1. Open the System menu and select Add User Information Source, as
Figure 8-38 Add User Information Source
2. The Add User Information Source Wizard starts. Click Next on the welcome
screen as shown in Figure 8-39.
194
7530ch08.fm
Figure 8-39 Add User Information Source Wizard welcome screen
3. The next screen that is displayed allows us to select the machine where the
User Information Source resides. Figure 8-40 shows that for this example,
FSPDC is selected. Click Next.
195
7530ch08.fm
Figure 8-40 Choose a Machine
4. The Choose a User Information Source screen appears. As seen in

Figure 8-41, we choose to import the Active Directory groupings from FSPDC
and click Next.
196
7530ch08.fm
Figure 8-41 Choose a User Information Source
5. The User Information Source properties are displayed on the next screen, as
displayed in Figure 8-42. Click the Edit button to modify the Domain name.
Note: The difference between Grouping ActiveDirectory and Grouping
Windows is that Grouping ActiveDirectory is for Active Directory on
Windows 2000 and Windows 2003 and Grouping Windows is for Windows
NT Domains.
197
7530ch08.fm
Figure 8-42 User Information Source Properties
6. You can now enter the name of the Active Directory domain. Tivoli Financial
Accounting Corporation has used the domain name INSIGHT to represent all
of its users who are being monitored by Tivoli Compliance Insight Manager.
The wizard has now advanced to the next screen by clicking Next.
198
7530ch08.fm
Figure 8-43 Define User Information Source
7. Now you can choose a collect schedule for extracting information from the
specified UIS before clicking Next to continue. Refer to Figure 8-44.
199
7530ch08.fm
Figure 8-44 UIS Collect Schedule
8. The Add User Information Source completion screen is displayed. You should
collect the UIS data before the (last) collection of the audit trail happens. In
that way you are sure that the UIS data is applied to the chunks that will be
analyzed.
Click the Finish button to complete the process as shown in Figure 8-45.
200
7530ch08.fm
Figure 8-45 Completing the Add User Information Source Wizard
9. The new User Information Source is now displayed in the Event Source view
of Management Console as can be seen in Figure 8-46.
Figure 8-46 Grouping ActiveDirectory UIS is available in the Management Console
Viewing the User Information Source

Once the first scheduled UIS collection is complete, we can view the user
information grouping definitions that have been collected.
Select Policy View Automatic Policy and choose the current time in order to
get the most recent grouping definition.
201
7530ch08.fm
Note: If there is more than one UIS defined in the management console, you
have the option to select which Automatic Policy you want to view. Each UIS
will show the name of the machine being used to collect the UIS data.
8.7.1 Configuring a new policy with W7 rules

Policy building is a crucial part of using Tivoli Compliance Insight Manager to
effectively monitor your environment. Policy building is essentially the
combination of W7 groups. You can combine W7 elements to create policy and
attention rules.
As described in Chapter 3, IBM Tivoli Compliance Insight Manager component
structure on page 27, if the rule is added to the set of policy rules then this rule
marks all GEM events that match it as normal events. Therefore, events that
match policy rules are not displayed in policy exception reports. Meanwhile, if the
rule is added to the set of attention rules then all GEM events that match the
attention rule are marked as attention events. These attention events show up in
the special attention reports.
The following process can be used to create a new policy for Tivoli Financial
Accounting Corporation that includes grouping and policy rules for the Windows
event sources that are being monitored for phase one:
1. Duplicate the latest committed policy to create a new working policy.
2. The new working policy can be used for customizing the W7 group definitions.
The Group Definition Set from the UIS can be imported into this policy.
3. Policy building. Create appropriate W7 policy rules and attention rules.
4. Load the database using this working policy.
5. Commit the policy when the W7 rules are producing the desired results.
Let us describe each of these five steps in more detail now.
Create a new work policy

Tivoli Financial Accounting Corporation is going to use the default committed
policy that is installed with Tivoli Compliance Insight Manager as the foundation
for the policy that they need to develop.
To create a Work policy in the Management Console Policies View, right click on
the most recent committed policy and select Duplicate as shown in Figure 8-47
on page 203.
202
7530ch08.fm
Figure 8-47 Create a new working policy
A new policy appears under the Work folder as shown in Figure 8-48.
Figure 8-48 Work policy
Import UIS group definitions

The imported group definitions from the UIS can be included into the new
working policy as follows:
1. Open the working policy in the Policies window and right-click on the policy
name. Select Import Group Definition Set.
203
7530ch08.fm
Figure 8-49 Import Group Definition Set
2. Use the Browse button to search for the correct configuration file.
Figure 8-50 Browse for configuration file name
3. The imported group definitions from the UIS are stored in an automatic policy
by default. The automatic policies are located at
<TCIM_HOME>/Server/config/grouping/automatic as shown in Figure 8-49.
204
7530ch08.fm
Figure 8-51 NT folder for the automatic policy contains the config file
4. As shown in Figure 8-52, open the FSPDC.cfg file.
205
7530ch08.fm
Figure 8-52 Select group definition file
5. Configure the group definition set name to be FSPDC and click OK as

depicted in Figure 8-53.
Figure 8-53 Name new definition set
6. A folder called FSPDC appears in the policy window on the right hand side.
We double-click on this policy group and its contents is displayed in the left
hand panel as shown in Figure 8-54.
206
7530ch08.fm
Figure 8-54 Locate the new group definition set in the working policy
Customize group definitions

Besides the grouping definitions imported from the UIS, we also need to create
some other grouping rules to describe sensitive company assets.
As an example, the following figures show how Tivoli Financial Accounting
Corporation describes the Windows locations of their confidential financial data.
In 8.1, Phase one auditing on page 158 we explained that the Windows file
servers have a number of directories that contain sensitive corporate data. The
financial data is stored within the C:\Finance directory.
A W7 rule needs to be created in the new Tivoli Compliance Insight Manager
policy to describe this corporate asset. The default policy that has been used as
the basis for this working policy already has a number of pre-defined groups that
are initially empty. Tivoli Financial Accounting Corporation has decided to use
the existing FinancialData - Medium group to represent the C:\Finance file share
on the Windows servers. In the future, they may decide to have more
fine-grained control of financial assets by adding rules to classify financial assets
as either High, Medium or Low.
The following steps illustrate how to specify a W7 group definition to describe the
Financial file share on the Windows servers:
1. Open the NT group definitions and expand the list of onWhat groups in the left
hand panel. Locate the group for Financial Data - Medium, right-click and
select New Condition as shown in Figure 8-55.
207
7530ch08.fm
Figure 8-55 Create new condition
2. Figure 8-56 shows how to create a requirement to specify the new condition.
That is, right click on the condition and select New Requirement.
Figure 8-56 Create new requirement
3. As you recall, object access auditing was configured in 8.4.3, File server
settings - object access auditing on page 165. These configured audit
settings on the target machine result in user actions on the C:\Finance folder
(and its contents) being logged by Windows. These logged events describe
208
7530ch08.fm
actions on the finance share. When mapped by Tivoli Compliance Insight

Manager, these events have a W7 Object Path value that starts with
C:\Finance.
Therefore, the requirement Object Path starts with C:\Finance is configured
Figure 8-57 Specify condition for asset to be classified as FinancialData - Medium
4. The new requirement is now complete and can be seen in the Grouping panel
Figure 8-58 W7 group definition for the Windows financial data file share
Tivoli Financial Accounting Corporation now repeats the process of creating

appropriate grouping definitions, with associated conditions and requirements,
for the rest of their Windows environment. For instance, they include the other
confidential file shares (including C:\HR, C:\CustomerData and the print share)
209
7530ch08.fm
into W7 onWhat groups. Additionally, extra group conditions and requirements

are added into the other W7 groups: Who, What, When & Where.
Showing all of these grouping definitions for Tivoli Financial Accounting
Corporation is beyond the scope of this IBM Redbook.
Create W7 policy rules

The grouping definitions that have been created can now be used to formulate
W7 policy rules that describe the set of permissible W7 events.
The default committed policy that was used as the basis for the current working
policy contains a number of pre-defined policy rules and attention rules. Tivoli
Financial Accounting Corporation analyzes these existing policy and attention
rules to ensure that they are all appropriate to their IT environment. Where
appropriate these pre-existing rules are edited.
New rules are also created to customize the rules to meet Tivoli Financial
Accounting Corporations needs. In this section we describe the process of
creating one of the policy rules. The rule is defined in Table 8-2.
Table 8-2 New W7 policy rule
W7 Category
Who
What
Where
Value
System
System Operations
INSIGHT
For this policy rule to be useful, Tivoli Financial Accounting Corporation has
ensured that the W7 Who group called System effectively describes the
permitted system users with appropriate requirements and conditions defined.
Similarly, the W7 Where group called INSIGHT has been created to represent all
of the Windows servers being monitored in the INSIGHT domain.
In the following figures we show the steps involved to create the new policy rule
from the Policies view in the Management Console.
1. Ensure that the Policy tab is selected and right-click in the Policy Rules panel.
Select New Rule as shown in Figure 8-59.
210
7530ch08.fm
Figure 8-59 Create a new policy rule
2. As you can see in Figure 8-60, an Edit Rule window appears where you can
enter the W7 groups that specify the new rule. Click OK.
Figure 8-60 Edit rule window
3. The new rule appears in the Policy Rules list as can be seen in Figure 8-61.
Figure 8-61 List of policy rules
211
7530ch08.fm
4. Once the new policy rules have been defined, the working policy must be
saved. The Save option is under the Policy menu. (Refer to Figure 8-62).
Note: For phase 1 of implementation, Tivoli Financial Accounting
Corporation also wanted to create policy rules to capture the allowed
operations on the confidential file shares. For example, a policy rule
specifying that the W7 Who group called Finance can perform operations
on objects in the W7 onWhat group called FinancialData and so on.
Figure 8-62 Save working policy
Create W7 attention rules

Attention rules also need to be created in the working policy. The W7 attention
rules represent events that you are interested in monitoring.
After reviewing the pre-defined attention rules, the IT security staff at Tivoli
Financial Accounting Corporation proceeds to identify some attention rules.
212
7530ch08.fm
For example, the IT security staff are interested in being notified whenever
confidential financial data is deleted. In this section we outline the configuration
in Tivoli Compliance Insight Manager to configure an attention rule for these
deletion events.
Here it is important to highlight that a W7 group has been defined to represent
the deletions performed by a user in a Windows environment. Figure 8-63 shows
this group definition.
Figure 8-63 W7 What group: User Actions - Deletions
This What group can now be used in the new attention rule.
Here is an outline of the steps involved in creating the new attention rule for
capturing any deletion events on the Windows financial data file shares.
1. Ensure that the Attention tab is selected and right click in the Attention Rules
panel. Select the New Rule option shown in Figure 8-64.
Figure 8-64 Create new attention rule
2. Figure 8-65 shows the Edit Rule window that appears. The new attention rule
has been defined as: Any user performing a deletion (W7 What = User
Actions - Deletions) on objects in the financial file shares (W7 onWhat =
Financial Data).
213
7530ch08.fm
Tivoli Financial Accounting Corporation has opted to assign an ID to this

attention rule so that it can be managed easily. Tivoli Compliance Insight
Manager allows these rule IDs to be used to create alerts for individual
attentions. That is, an alert can be configured in the future to send an e-mail
to an IT security admin when events matching this attention rule are detected
by Tivoli Compliance Insight Manager. In Alerts on page 215 we describe
how to create an e-mail alert.
Note: The rule ID should be a single word consisting of letters and
numbers only.
Figure 8-65 Edit attention rule window
3. After we click OK in the Edit Rule window, the new attention rule appears in
the Attention Rules panel.
214
7530ch08.fm
Figure 8-66 Attention rule for deletions on FinancialData
Alerts
As described in the previous section, Tivoli Financial Accounting Corporation
wants to configure an alert that sends an e-mail to the IT security admin staff
when deletions are performed on objects in the confidential file shares.
The following steps describe how an e-mail alert is created for the Windows
finance file share:
1. Open the Alert Maintenance window in the Management Console. Click on
the New button as shown in Figure 8-67.
215
7530ch08.fm
Figure 8-67 Alert Maintenance window
2. Tivoli Compliance Insight Manager creates a new alert with placeholder

entries and adds it to the bottom of the existing alert list (if any). We right click
on the new alert and select Edit as shown in Figure 8-68.
216
7530ch08.fm
Figure 8-68 Choose to Edit the new alert
3. The Edit Alert window is displayed. Configure the alert to send an e-mail to
the recipient admin@tfac.com when events matching the attention rule with
ID DeleteFinancials occur. (Refer to Figure 8-69). Click OK.
Figure 8-69 Edit Alert options
217
7530ch08.fm
4. The alert is updated with the new configured settings. Click on the Protocol
Settings button identified in Figure 8-70 to configure the protocols in use.
Protocol settings apply to all alerts that are sent using the same protocol.
Figure 8-70 Alert Maintenance windows displays the modified alert
5. The Protocol Settings window is displayed as shown in Figure 8-71.

Configure the e-mail settings for thei environment and click OK.
218
7530ch08.fm
Figure 8-71 Protocol Settings window
The alert has now been configured.
Load the database

Now that the Tivoli Compliance Insight Manager environment has been
configured for the Windows event sources and a working policy has been
created, you can collect and load data from the target systems. Once the data is
loaded, iView can be used to view the data and the effect of the policy mapping
process.
You can wait for the next scheduled collect and load to occur. Alternatively, you
can temporarily cancel the scheduled load and manually load the database
instead.
Note: In a production environment we do not recommend to temporarily
cancel scheduled loads.
In order to perform manual loads we recommend to create a GEM database
for that sole purpose.
Performing manual loads on scheduled loads will change the appearance of
the dashboard, and statistics information will not be well calculated.
Additionally, the Last Load Date field is updated.
Here is the process for manually loading the database:
219
7530ch08.fm
1. Locate the database that you plan to load in the database view of the
Management Console. Right click and select Load as shown in Figure 8-72.
Figure 8-72 Start the Load process
2. The Load Database Wizard Welcome screen, shown in Figure 8-73, is

displayed.
Figure 8-73 Welcome to the Load Database Wizard
220
7530ch08.fm
3. As highlighted in Figure 8-74, select the GENERAL database on the next

screen and click Next.
Figure 8-74 Choose a database to load
4. Specify a period of time for which the collected data should be loaded as
shown in Figure 8-75 and click Next.
221
7530ch08.fm
Figure 8-75 Data collection period
5. On the next screen, depicted in Figure 8-76, decide whether to perform a data
collection now or whether to use the data that has already been collected
through an earlier collect process.
222
7530ch08.fm
Figure 8-76 Specify whether to collect before the load
6. Since you are performing a manual load, the wizard prompts you to specify
which policy should be used to map the data. In order to test the policy you
have been working on select the fixed policy option and navigate to the
correct policy in the work folder as seen in Figure 8-77. Click Next to proceed.
223
7530ch08.fm
Figure 8-77 Select a policy to be applied to the loaded data
7. Click Finish on the completion screen for the wizard.
Figure 8-78 Complete the Load Database Wizard
224
7530ch08.fm
8. When you refresh the database view in the Management Console you can
see that the status for that database changes to the value Loading... to signify
that the load process has started. When the load is complete the status is
Loaded and the time and date of the last load is updated.
Commit the policy

Now that the database has been loaded using the policy that we have been
working on, the IT security team needs to review the data that has been collected
and how it is presented in iView. In 8.8, iView Compliance Dashboard we
describe how to navigate through iView to view the data.
This review of the data may lead to modifications to the groupings and rules
defined in the policy. After any policy changes, the data can be re-loaded and
mapped using the policy so that the new effect of the rules can be reviewed.
Once the team is satisfied that the policy is configured as desired, the policy can
be committed. The most recently committed policy is the policy that will
automatically be applied to scheduled database loads.
To commit the working policy right click on the policy (in the work folder of
Management Console Policy Explorer) and select Commit. When the policy has
been committed it appears in the Committed folder.
8.8 iView Compliance Dashboard

In order to open iView navigate to http://localhost/iview in a Web browser on the
Tivoli Compliance Insight Manager Standard Server. Enter your login details in
the Web page that opens. After entering the login name (cearoot_db) and
password click the Log in button.
The Compliance Dashboard is displayed.
Scroll down to the Database Overview section at the bottom of the page and click
on the GENERAL database icon that is shown in Figure 8-79.
Figure 8-79 GENERAL database icon
The database summary for the GENERAL database is displayed. Figure 8-80
shows an example of this summary page. You can see an events summary
225
7530ch08.fm
section on the right hand side of the screen that includes Total Events, Policy
Exceptions, Special Attentions, and Failures. There are Event List icons and
Event Summary Report icons to link through to more specific event details.
Figure 8-80 Summary of GENERAL Database
Let us now look in more detail at mapped events. In particular we explore the
Policy Exceptions and Special Attentions.
8.8.1 Policy Exceptions

Click on the Event Summary Report link for the Policy Exceptions. The Policy
Exception Summary window is displayed as shown in Figure 8-81.
226
7530ch08.fm
Figure 8-81 Policy Exception Summary
This view shows a summary of the exceptions that have occurred with the
number of each type of exception in the last column. For a view of all the
individual policy exception events you may choose the Policy Exception Event
List icon from the GENERAL database summary page (rather than the Policy
Exception Summary icon). Clicking on this icon displays all of the individual
Policy Exception events.
Figure 8-82 Policy Exception Event List
227
7530ch08.fm
To look at an individual event in more detail, click on one of the values in the
Date/Time column, which is a hyperlink to the event detail view. Figure 8-83
shows the event detail for the event selected in Figure 8-82.
Figure 8-83 Event Detail
Clicking on the text This is a policy exception links you to the page shown in
Figure 8-84 where the Policy Exception event is explained further. Here you can
see the W7 rule that the individual event was mapped to during the load process.
228
7530ch08.fm
Figure 8-84 Explanation of Policy Exception
8.8.2 Special Attentions

We can review the special attention events in a similar way. The Special
Attention Summary for the data that has been loaded into the GENERAL
database is shown in Figure 8-85.
229
7530ch08.fm
Figure 8-85 Special Attention Summary
You can click on any values in the #SpecAtt column to link through to a break
down of that group of events. After clicking on the number 141 (as seen in
Figure 8-85), the details for that group of Special Attention events is displayed.
Figure 8-86 shows the Special Attentions for events classified as User Actions File (W7 What group) on Financial Data (W7 onWhat group) by user
INSIGHT\Katie (W7 Who Group) located at INSIGHT\FSPDC (W7 Where
group).
230
7530ch08.fm
Figure 8-86 Special Attention Events of User Actions
Once again you can get further event details about a particular item that is listed
by clicking on the link in the Date/Time field. The Event Detail page shown in
Figure 8-87 is displayed.
231
7530ch08.fm
Figure 8-87 Event Detail for selected special attentions
The link This is a special attention event can be used to see an explanation of
why the event has been classified as a Special Attention event. You can see
from Figure 8-88 that in this case, the Special Attention event for IT personnel
(W7 Who group) performing an action on the Financial Data - Medium objects
(w7 onWhat group) has been triggered.
232
7530ch08.fm
Figure 8-88 Explanation of Special Attention event
8.8.3 Reports
The iView Reports page can be used to generate online reports based on the
loaded data. To open this page you can click on the Reports button in the top
menu of the Database Summary page (refer back to Figure 8-80).
iView Reports is divided into four main categories:
Configuration Tools
Daily Verification
Detailed Investigation
Firewall Reports
Each of these categories contain pre-defined reports for you to analyze the
events that have been captured. Examples from some of these categories are
described in the remainder of this section.
Configuration Tools reports

Figure 8-89 shows a snapshot from the iView Reports screen. Run the Events
by Rule report to delve into the data currently loaded in the GENERAL database.
233
7530ch08.fm
Figure 8-89 Configuration Tools - Events by Rule report
The icon in the shape of a tick in the Action column in the row of Events by Rule
indicates that in order to run this report some user input is required. It indicates
that some parameters are needed to determine the scope of the report. You are
prompted to configure the W7 rule for which you want the matching events to
display. Configure the report to include all events that are classed as user
actions on a file containing financial data. That is, you are filtering the events
using the W7 What group User Actions - File and the W7 onWhat group
Financial Data as displayed in Figure 8-90.
Figure 8-90 A part of the Events by Rule report configuration
When this report is submitted, a list of events matching this W7 rule are created.
As shown on the previous event list reports, it is possible to navigate through
Web links to find individual event details where desired.
Daily Verification reports

The daily verification reports include a number of useful reports to check events
that have been detected on the audited systems.
234
7530ch08.fm
As described in Figure 8.3, there are a number of Basel II reports that Tivoli
Financial Accounting Corporation are particularly interested in generating.
One of the desired reports is based on user responsibilities and password use.
Therefore, one of the daily verification reports that is of interest to Tivoli Financial
Accounting Corporation is the Logon Failure Summary report.
You can generate the Logon Failure Summary report by clicking on the
appropriate link as shown in Figure 8-91.
Figure 8-91 Daily Verification Reports: Logon Failure Summary
A list of the failed logon events and their associated details are displayed in the
browser. Refer to Figure 8-92 for an example Logon Failure Summary report.
Figure 8-92 Logon Failure Summary Report
235
7530ch08.fm
Detailed investigation
Earlier in this chapter we also outlined Tivoli Financial Accounting Corporations
desire to monitor actions performed on their confidential file shares (refer back to
8.1, Phase one auditing on page 158), so let us now view the detailed
investigation report called Object Audit.
Figure 8-93 Detailed Investigation Reports - Object Audit
As can be seen from Figure 8-93, this is another example of a report that
requires parameters to be specified before it can be generated. Select which W7
onWhat group you want to audit. As shown in Figure 8-94, select to audit the
Financial Data.
Figure 8-94 Financial Data Object Audit
236
7530ch08.fm
When you click Submit the report is generated. The screen shown in Figure 8-95
shows the output for this report.
Figure 8-95 Object Audit Report
As with all of the online reporting in Tivoli Compliance Insight Manager, you are
able to examine the finer details of these events by clicking on the desired links.
Let us find out more about the Object Deletion event that is listed in the Object
Audit Report by clicking on the 1 in the #Events column. The W7 details of the
event are displayed, as shown in Figure 8-96, and by clicking on the available link
in this window you can obtain the event details given in Figure 8-97.
237
7530ch08.fm
Figure 8-96 Object Audit Event List
Figure 8-97 Event Detail
Analyzing Trends with iView

The trends part of iView presents the aggregated data from all the databases.
The Trends section opens by default with the All Events of the last seven days.
You can see this view in Figure 8-98. Last Month can be clicked to view events
of the last month. The drop down menu allows you to choose between policy
exceptions, special attention events, and failures, or get a percentage view of the
three options.
238
7530ch08.fm
If the diagram represents the last week, click Previous to return to the previous
week. Click Next to go forward one time period. If no data is available, the control
is unavailable.
Below the bar graph in this view there are seven list boxes for each W7 group
types. You can configure all possible W7 group combinations using these drop
down menus. If you select Go (located to the right of these seven list boxes) then
the diagram displays data for the selected groups. There is a table at the bottom
of the screen with a description of every bar in the diagram. You can click its
number of events to get its event list.
Figure 8-98 Trend data
8.9 Self audit

When installed, the Tivoli Compliance Insight Manager servers automatically
configure and schedule self audits. You may have noticed in certain diagrams
throughout this chapter that there is a database called SelfAudit configured by
default on the Tivoli Compliance Insight Manager server. In the database view of
239
7530ch08.fm
the Management Console, displayed in Figure 8-99, you can see that this
database also has a daily load schedule associated with it when the server is
initially installed. That is, a Tivoli Compliance Insight Manager Server
automatically starts self auditing from the moment it is first installed.
Figure 8-99 Self Audit database and schedule
Auditing the Tivoli Compliance Insight Manager environment is important so that

the IT security staff is aware of user actions that affect Tivoli Financial
Accounting Corporations compliance management solution.
Figure 8-100 shows the Daily Verification Report called Logon Failure Summary
run against the Self Audit database. Figure 8-101 and Figure 8-102 show the
results of using iView to display further details about the login failure event.
Figure 8-100 Self-Audit Logon Failure Summary
240
7530ch08.fm
Figure 8-101 Self Audit Logon Failure Event List
Figure 8-102 Logon Failure Event Detail
There is lots of other useful self audit reporting capabilities. For instance, the
report displayed in Figure 8-103 shows all the events contained in the Self Audit
database that are classified as Configuration Changes. As you can see, by
default Configuration Change events include user actions such as creating
policies, committing policies, aggregating log data, and so on.
241
7530ch08.fm
Figure 8-103 Event List of Configuration Changes - Self Audit Database
8.10 Conclusion
Phase one of Tivoli Financial Accounting Corporations implementation plan is
now complete. In this chapter we have described the process that was used to
install and configure a Tivoli Compliance Insight Manager cluster. Tivoli Financial
Accounting Corporation now has their Tivoli Compliance Insight Manager
environment set up to monitor the actions of their Windows domain users. In
order to achieve this monitoring, Windows Actuators were installed on the
Windows servers in the IT environment. Microsoft Windows event sources and
Active Directory event sources were configured for the appropriate servers.
The audit subsystems on each server were also configured to ensure that
sufficient log information is generated on the target machines. Appropriate W7
groups and rules were defined and encapsulated in a Tivoli Compliance Insight
Manager policy that has been committed. Scheduled loads can now be
performed on the GENERAL database to collect the data from these Windows
event sources. The iView Compliance Dashboard can be used to monitor user
actions by reporting on the loaded events.
In the next phase, Tivoli Financial Accounting Corporation is going to expand
their deployed compliance management solution by using Tivoli Compliance
Insight Manager to audit more platforms and applications in their environment. In
particular, in phase two, they begin monitoring AIX, SAP, Domino and Oracle.
242
7530ch09.fm
Chapter 9.
Extending auditing to other

platforms
In this chapter Tivoli Financial Accounting Corporation is going to expand their
deployed compliance management solution by using Tivoli Compliance Insight
Manager to audit more platforms and applications in their environment. In
particular, in phase two, they begin monitoring AIX, SAP, Domino and Oracle.
Let us begin by looking at the current IT environment.
243
7530ch09.fm
9.1 IT environment
Figure 9-1 shows the customer IT architecture. This architecture was described
in detail in Chapter 6, Introducing Tivoli Financial Accounting Corporation on
page 129. The system groups that we are addressing in this phase of the project
have been highlighted in Figure 9-1.
Figure 9-1 Tivoli Financial Accounting Corporation IT architecture components for phase 2
Specifically in this phase of the project we are going to implement log

management and basic audit reporting for the following types of systems:
AIX 5.3 Systems
Domino 6.5
SAP R/3 System
Oracle 10.2
We use the Standard Server that was installed as part of phase 1 of the project
as our Tivoli Compliance Insight Manager server. Details of how to install a
Standard Server and add it to a Tivoli Compliance Insight Manager cluster are
contained in the IBM Tivoli Compliance Insight Manager Installation Guide
Version 8.0, GI11-8176-00.
244
7530ch09.fm
9.2 Basic approach

As with all Tivoli Compliance Insight Manager event sources the basic approach
to collecting audit data can be encompassed in the following steps:
1. Configure the target system so that it generates the audit data you need.
2. Create a Tivoli Compliance Insight Manager event source for that target
system using either a local or remote Point of Presence.
3. If the Point of Presence is remote then you also need to configure the target
system to make the audit data available to Tivoli Compliance Insight Manager
in some way. For many systems this means you have to create a user
account, configure the system so the user account is able to access the audit
data. and configure a collection mechanism (a typical collection method is to
use SSH, as we use it for our AIX systems later in this section).
4. Configure the appropriate policy groups and rules.
9.3 Auditing AIX 5.3 systems

For each of the target systems we need to configure auditing using whatever
mechanism is appropriate for that environment. Basic steps for configuring
auditing for these platforms are discussed in the installation guide and are more
fully elaborated here.
9.3.1 Configure auditing for AIX systems

On the AIX system we use the audit subsystem to create some useful audit
information as well as collecting the standard files that AIX uses to capture login
and failed login information.
AIX standard login files

Logins and failed logins on AIX are captured in the files /var/adm/wtmp and
/etc/security/failedlogin by default. We do not need to configure AIX any further to
generate these files. By default the wtmp file is readable by any user, however,
the failedlogin file is by default located in a directory that is not accessible by all
users. This means, that when we configure the user id that Tivoli Compliance
Insight Manager uses to collect this log data, we need to ensure that it is a
member of a group that has been granted access to this file.
Chapter 9. Extending auditing to other platforms
245
7530ch09.fm
AIX audit subsystem

The audit subsystem on AIX is highly configurable, exploring every audit setting
and configuration option is outside the scope of this Redbook. Detailed
information about configuring this subsystem is available in the IBM Redbooks
deliverable Accounting and Auditing on AIX 5L, SG-6396. For our purposes we
explain some basic concepts and configuration options.
The AIX audit subsystem uses the two information collection modes BIN and
STREAM. We will use the BIN mode.
Some basic commands to control the audit subsystem (these commands are
located in the /usr/sbin directory by default) include:
audit start
Starts the audit subsystem.
audit shutdown
Stops the audit subsystem and flushes the bin files.
audit off
Suspends the audit subsystem temporarily.
audit on
Resumes the audit subsystem after suspension.
audit query
Displays the current audit subsystem status.
The following commands can be useful when interacting with the AIX audit
subsystem:
auditcat
Used to write bin files produced by the subsystem to an

auditrail file.
auditpr
Used to format and print audit records in a human

readable format.
The AIX audit subsystem is controlled by the following files (by default these files
are located in the /etc/security/audit directory):
config file
This file contains the key stanzas that control the auditing subsystem. The
stanzas include:
246
start:
Specifies the audit collection method. Tivoli

Compliance Insight Manager typically uses the bin
method.
bin:
This stanza specifies how the bin mode audit

collection method is configured.
stream:
This stanza specifies how the stream mode audit

collection method is configured.
classes:
This stanza defines audit classes. An audit class is a

specific set of AIX events. Classes can be assigned to
a single user, a user group or to all.
users:
7530ch09.fm
This stanza specifies to which users event auditing

applies and which audit classes are captured for that
user. Using the user default applies the collection
policy to all users.
A cut down example of a Tivoli Compliance Insight Manager config file is

shown in Example 9-1. The Tivoli Compliance Insight Manager Installation
guide has a complete example that should be studied more closely.
Example 9-1 The AIX audit subsystem config file
start:
binmode = on
streammode = off
bin:
trail = /audit/trail
bin1 = /audit/bin1
bin2 = /audit/bin2
binsize = 10240
cmds = /etc/security/audit/bincmds
freespace = 65536
stream:
cmds = /etc/security/audit/streamcmds
classes:
eprise = PROC_Delete, PROC_Execute, PROC_RealUID, PROC_AuditID,
PROC_RealGID, PROC_Environ, PROC_Privilege, PROC_Settimer,
FILE_Link, FILE_Unlink, FILE_Rename, FILE_Owner, FILE_Mode,
FS_Mount, FS_Unmount, FILE_Acl, FILE_Privilege, FS_Chroot,
TCPIP_Config, TCPIP_host_id, TCPIP_route, TCPIP_connect,
TCPIP_access, TCPIP_set_time, TCPIP_kconfig, TCPIP_kroute,
TCPIP_kconnect, TCPIP_kcreate, USER_Login, PORT_Locked, SYSCK_Check,
SYSCK_Update, SYSCK_Install, USER_Check, USER_Logout, PORT_Change,
USER_Change, USER_Remove, USER_Create, USER_SetGroups, USER_SetEnv,
USER_SU, GROUP_User, GROUP_Adns, GROUP_Change, GROUP_Create,
GROUP_Remove, PASSWORD_Change, PASSWORD_Flags, PASSWORD_Check,
PASSWORD_Ckerr, SRC_Start, SRC_Stop, SRC_Addssys, SRC_Chssys,
SRC_Addserver, SRC_Chserver, SRC_Delssys, SRC_Delserver,
ENQUE_admin, ENQUE_exec, SENDMAIL_Config, SENDMAIL_ToFile,
AT_JobAdd, AT_JobRemove, CRON_JobRemove, CRON_JobAdd, CRON_Start,
CRON_Finish, NVRAM_Config, DEV_Configure, DEV_Change, DEV_Create,
DEV_Start, INSTALLP_Inst, INSTALLP_Exec, UPDATEP_Name, DEV_Stop,
DEV_UnConfigure, DEV_Remove, LVM_ChangeLV, LVM_ChangeVG,
LVM_CreateLV, LVM_CreateVG, LVM_DeleteVG, LVM_DeleteLV,
247
7530ch09.fm
LVM_VaryoffVG, LVM_VaryonVG, BACKUP_Export, BACKUP_Priv,

RESTORE_Import, USER_Shell, TCBCK_Check, TCBCK_Update,
PROC_SetGroups
Points of interest include our start: stanza where we specify the bin mode
collection. Our bin stanza defines the default locations for the audit trail
information. In the class section we have defined the event classes that we
are interested in. We arbitrarily picked the label eprise. Last and probably
most important we have defined our users stanza where we have indicated
that we want to collect the events labelled with eprise for all of our users, for
example, the default for all users is the event list specified by the label eprise.
bincmds file
This file contains the commands that are used by the audit daemon (auditbin)
when it is flushing the audit bin files to the audit trail. For our purpose the
bincmds file should be as described in Example 9-2.
Example 9-2 bincmds file entries for Tivoli Compliance Insight Manager
# the next line removes our previous temporary work audit trail
# in case we did not clean up properly previously.
/usr/bin/rm -f /var/log/eprise/working
# the next line uses the auditcat tool to output the audit trail
# into the location /var/log/eprise/working. The $bin
# parameter will be expanded to the path /audit/trail from
# our config file.
/usr/sbin/auditcat -o /var/log/eprise/working $bin
# The next line appends the flushed data to a date and hour stamped
# file in /var/log/eprise e.g. trail.2007083115. This is the file
# which TCIM is looking for when it collects audit data.
/usr/bin/cat /var/log/eprise/working >>
/var/log/eprise/trail.`date +"%Y%m%d%H"`
# The next line alows us to maintain the full audit trail in the
# /audit/trail location (this is not required by TCIM but local
# practice may be that this should be the full audit trail).
/usr/bin/cat /var/log/eprise/working >> /audit/trail
# last we remove our temporary working file as it is no longer
# required.
/usr/bin/rm -f /var/log/eprise/working
248
7530ch09.fm
events file
This file is where we define the event formatting options. We would like to get
audit entries for objects being read, written, and executed, so we need to add
the entries in Example 9-3 to the end of the events file (notice that comments
in the event file are preceded with the * character.
Example 9-3 events file entries for Tivoli Compliance Insight Manager
* Object Audit Event Definitions needed

* for Tivoli Compliance Insight Manager
Obj_READ = printf "%s"
Obj_WRITE = printf "%s"
Obj_EXECUTE = printf "%s"
objects file
This file defines the system objects we specifically want to monitor access to.
For this to work we must have previously defined in the events file the events
we want to receive. For our purposes we are interested to see people
accessing a directory that contains our sensitive data in a file called
/home/sensitivedata. To achieve this we add the lines in Example 9-4 to the
end of the /etc/security/audit/objects file.
Example 9-4 objects file entries for Tivoli Compliance Insight Manager
/home/sensitivedata:
r = "Obj_READ"
w = "Obj_WRITE"
Preparing the AIX system for audit data collection using SSH
In order for Tivoli Compliance Insight Manager to perform remote collection of
audit data we have to do the following:
Create a user for Tivoli Compliance Insight Manager to use. In our case we
create a user named insight.
Ensure that the user has the correct permissions to access the audit data, for
example, the user needs to have full permissions for the /var/log/eprise
directory and its contents, read permissions for the failedlogin file
(/etc/security/failedlogin), read and execute permissions for the /etc and
/etc/security directories, read permissions for the wtmp file (/var/log/wtmp),
and read and execute permissions for the /var and /var/log directories. We
achieved this by adding the insight user to the system, audit, and security
groups on the AIX target system.
Configure the system so that the Tivoli Compliance Insight Manager server is
able to perform an SSH collect from the AIX system using the new user id.
249
7530ch09.fm
The basic steps to perform this are covered in the IBM Tivoli Compliance
Insight Manager Installation Guide Version 8.0, GI11-8176-00 (Chapter 9 Enabling Collect using SSH event sources). Let us summarize the steps that
are required:
Create ssh public and private keys.
Copy the public key to the insight users ssh/authorized_keys file.
Save the private key to the Tivoli Compliance Insight Manager servers
SSHKeys directory (typically C:\IBM\TCIM\server\run\sshkeys).
Perform one Putty based ssh login from the Tivoli Compliance Insight
Manager server to the target platform using your Tivoli Compliance Insight
Manager user.
Test the connection using the chksshcon tool.
In the previous sub sections we have shown how to configure and prepare the
AIX system so that its audit subsystem generates the information we want and
so that Tivoli Compliance Insight Manager is able to use SSH to collect that
information. Next we show you how to configure Tivoli Compliance Insight
Manager to collect the audit information.
9.3.2 Adding the AIX event source to Tivoli Compliance Insight

Manager
In this subsection we show how to configure Tivoli Compliance Insight Manager
to collect the AIX audit data using SSH.
1. Step one is to invoke the Add Machine Wizard from the Tivoli Compliance
Insight Manager Management Console. This is depicted in Figure 9-2.
250
7530ch09.fm
2. Select IBM AIX from the audited machine type (see Figure 9-3 on page 251).
Figure 9-3 Audited machine type
3. Select your machine as shown in Figure 9-4 (in our case our AIX system is
named FINSYS).
251
7530ch09.fm
Figure 9-4 Choose the machine
4. Choose the Point of Presence that performs the collection (see Figure 9-5). In
our case we are using our EXPANSIONTCIM server to perform the remote
SSH collection. This is the same server that should have previously been
configured so that it is able to connect to the target system using SSH.
252
7530ch09.fm
Figure 9-5 Select the Point of Presence
5. Select the event source type of AIX Audit trail through SSH as shown in
253
7530ch09.fm
Figure 9-6 Event Source Type
6. At this stage you have completed the Add Machine Wizard as shown in
Figure 9-7 on page 255. Select the finish option which automatically invokes
the Add Event Source Wizard.
254
7530ch09.fm
Figure 9-7 Add machine wizard complete
7. Select Next on the opening screen of the Add Event Source Wizard (see
Figure 9-8 on page 256).
255
7530ch09.fm
Figure 9-8 The add event source wizard
8. Now configure the event source properties as shown in Figure 9-9 on

page 257 and described below:
Audit trail directory /var/log/eprise
Directory where our audit information is located.
256
Audit trail prefix
trail
Prefix for the log files we collect (see Example 9-2 on
page 248 where we defined this).
SSH KeyFile
finsys.ppk
Private key we use to connect to the AIX system.
SSH Port
22
Default SSH port.
SSH User
insight
User id that we created on the AIX system for collection.
7530ch09.fm
Figure 9-9 AIX Event Source Properties
9. Next choose a collection schedule (in our case we are testing and will
manually trigger the collection, we can change the schedule at a later date).
10.Choose a GEM database to store the collected data (in our case we chose
the GENERAL database so that we could apply the same policies to our AIX
systems as we have applied to the rest of our environment).
11.Next complete the Add Event Source Wizard.
Our AIX system is now configured to both generate appropriate audit data and
for Tivoli Compliance Insight Manager to collect and report on that data. In the
next section we are going to manually load and display the results of that load.
9.3.3 The results

The next time a collection and a database load is performed for the GENERAL
GEM database Tivoli Compliance Insight Manager uses the event source we
have configured to log on remotely to the AIX server using SSH to collect the
various audit files that we have documented above. Once the collection has been
performed the data is parsed and mapped to the W7 model and can be reported
257
7530ch09.fm
on in the iView portal. Figure 9-10 on page 258 shows that we have successfully
collected and mapped the data from our AIX system into the W7 model.
Figure 9-10 AIX events displayed in the iView portal
Figure 9-11 on page 258 shows our policy exceptions. We can see that we have
a number of policy exceptions for our root user showing failed logon attempts.
Figure 9-11 Policy exceptions summary including our AIX system
Figure 9-12 on page 259 shows some further detail about our AIX system and
shows object audit events for our root user attempting to access our sensitive
258
7530ch09.fm
data. This can be further defined as a policy breach and could result in Tivoli
Compliance Insight Manager generating an attention alert.
Figure 9-12 root user accessing sensitive data
In Figure 9-13 we show how we could change the sensitive data significance in
our policy so that it would highlight unusual attempts to access our sensitive data
(of course the significance value should align with the results of your risk
analysis).
259
7530ch09.fm
Figure 9-13 Highlighting access to sensitive data on our AIX server
Figure 9-14 shows the results of applying this policy.
Figure 9-14 Policy applied
In Figure 9-15 on page 261 we further refine this by defining a special attention
alert that can be used to notify our security officers about attempts to access our
sensitive data.
260
7530ch09.fm
Figure 9-15 Our special attention alert definition
Figure 9-16 on page 261 shows the results of this special attention alert when
access to our sensitive data is detected.
Figure 9-16 Special attentions when sensitive data has been accessed
9.3.4 AIX auditing conclusion

In this section we have shown how to configure Tivoli Compliance Insight
Manager to collect audit data from the AIX platforms and how policies can be
applied to this data. Also refer to the use of the aixpert command at the
following URL:
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix
.security/doc/security/aix_sec_expert.htm
The command helps you to setup auditing to a certain IBM recommended level.
261
7530ch09.fm
In the next sections we cover additional platforms. Our coverage is not as

detailed because the basic steps are very similar. Key aspects that we highlight
in the following sections are how to set up auditing on the target system and what
the event source configuration options should be in order to collect from those
event sources.
9.4 Auditing Domino R6 systems

Lotus Domino is IBMs premier collaborative and e-mail environment. As such it
often hosts important and sensitive information. In this part of the project Tivoli
Financial Accounting Corporation is extending their audit capabilities to
incorporate the audit information contained in the Domino Administration
Requests Database.
9.4.1 Configuring auditing for Domino systems

A default installation of Domino creates and uses two main databases that are
used by Tivoli Compliance Insight Manager for audit monitoring. These
databases are:
log.nsf
This database contains Miscellaneous Domino system

events and mail routing events and generally holds these
events for the last 7 days worth of activity. Both of these
event types are extracted and collected by Tivoli Compliance
Insight Manager.
admin4.nsf
This is the Domino administration requests database. It

contains all of the administrative requests for a Domino
domain and is the primary place that administrative actions
are logged in Domino.
No further configuration of Domino is required as both of these databases are

created by default when you install Domino. Our next step is to configure Tivoli
Compliance Insight Manager to capture this information and store it in the Tivoli
Compliance Insight Manager repository.
9.4.2 Adding the Domino event source

Tivoli Compliance Insight Manager requires a Point of Presence with the Lotus
Notes client installed on it. The Lotus Notes client is used by the Point of
Presence to access the audit information that was described above. Prior to
configuring the Domino event sources in Tivoli Compliance Insight Manager you
need to install the Lotus Notes client on the Point of Presence. Once you have
262
7530ch09.fm
installed the Notes client test that it is able to access the audit data by performing
the following steps:
1. Log onto the Point of Presence as the Administrator user that Tivoli
Compliance Insight Manager is using to collect data. In our case this user was
cearoot_os (the default user is cearoot).
2. Start the Lotus Notes client and logon to Notes using the Notes user that
Tivoli Compliance Insight Manager will use to access the Notes client.
3. From within the Lotus Notes client open the Notes Log (log.nsf) and
Administration Requests (admin4.nsf) databases on the Domino server. If this
is successful then the Notes client is configured correctly for Tivoli
Compliance Insight Manager to use.
Once you have confirmed that the Lotus Notes client on the Point of Presence is
able to access the Domino audit data you can create the new Tivoli Compliance
Insight Manager Domino event source. This function is performed in the same
way as other event sources were added to Tivoli Compliance Insight Manager.
The basic steps are:
1. Press the Add Event Source button in the Tivoli Compliance Insight
Manager administration console to start the Add Event Source Wizard. During
the Wizards execution the following steps are important:
2. When the wizard asks you for a machine on which the application runs that
you want to audit (see Figure 9-17 on page 264) select the machine on which
the Notes client is installed (this machine should already be a Point of
Presence, if it is not, you need to install the appropriate Actuator on that
machine prior to commencing execution of the Add New Event Source
Wizard). In our case the machine is already being audited for Windows
events, so it previously had a Windows Actuator installed.
263
7530ch09.fm
Figure 9-17 Select the Domino audit machine
3. When asked to choose the Event Source type select the Lotus Notes event
source (see Figure 9-18 on page 265).
264
7530ch09.fm
Figure 9-18 Select the Lotus Notes event source
4. Next you are asked to define the event source properties (see Figure 9-19 on
page 266). In this dialog you enter the details for the Domino server that you
wish to audit, for exmple, the entries are for the server name (fspdc in our
case), logfile (which remains the same), password (Note: when you click on
this you are asked for the current password and to create a new password for
the Notes user), and the admin requests database file name (which you
should not need to change).
265
7530ch09.fm
Figure 9-19 Defining the Domino Event Source Properties
5. Next define the collection and load schedules and complete the Event Source
Definition Wizard. The next time you perform a scheduled collection and load
you will have collected audit data from the Lotus Domino event source.
In this section we described the process of adding the Lotus Domino event
source to our Tivoli Compliance Insight Manager implementation. The next
section shows the results of this process.
9.4.3 The results

After we have defined our auditing configuration and configured our event source
as shown in the previous two sections we should now have collected Lotus
Domino audit event data within our Tivoli Compliance Insight Manager repository
(as shown in Figure 9-20 on page 267).
266
7530ch09.fm
Figure 9-20 Domino audit data within Tivoli Compliance Insight Manager
The next step is to apply the appropriate policy and create appropriate attention
alerts. To illustrate what is possible here we have highlighted two cases.
In the first case Lotus Domino captures a lot of information in its admin4.nsf and
log.nsf databases. This information is faithfully captured and stored in the Tivoli
Compliance Insight Manager GEM repository. However, much of this information
is just about business as usual within our policy guidelines and should not be
highlighted as a policy breach. After our first data collect and load we noticed the
following results in Tivoli Compliance Insight Manager (see Figure 9-21 on
page 267), that means a lot of policy violations were generated by the data
collected from the Notes Domino system.
Figure 9-21 Domino policy exceptions
On closer inspection the majority of these events appeared to be related to a

Domino function called journaling (see Figure 9-22 on page 268).
267
7530ch09.fm
Note: Lotus Domino journaling is a function where each mail item is inspected
and those mail items matching predefined rules will have a copy retained.
Figure 9-22 Domino Policy Exceptions
We determined that this was not a policy exception so we changed our policy
definitions as follows.
First we created an On What group definition called Journaling as shown in
Figure 9-23. As you can see, we defined a group to highlight Database Object
operations where the object path contains the value Journal. This group was
assigned a very low significance since operations on this object are considered
to be low risk.
Figure 9-23 Group definition for journaling
We then created a policy that indicated that journaling actions were within our
policy as shown in Figure 9-24 on page 269.
268
7530ch09.fm
Figure 9-24 Our journaling policy
The results of this are a massive reduction in the number of policy violations that
Tivoli Compliance Insight Manager reports (as shown in Figure 9-25 on
page 269).
Figure 9-25 Reduced Domino policy exceptions
In our case we were also particularly concerned about users or administrators

who accessed a mail box named Sensitive Mail. So our next step was to create
the appropriate policy groups and attention rules to highlight attempts to access
the Sensitive Mail box. We did this by adding a requirement to the On What
policy group that defines anything that contains the string Sensitive in its object
name to be Sensitive data (this is shown in Figure 9-26 on page 270).
269
7530ch09.fm
Figure 9-26 The Sensitive Data - User policy group definition
We also wanted special attention alerts if someone attempts to access this

mailbox out of hours so we defined a special attention rule as shown in
Although we have already highlighted the difference between a policy rule and a
special attention rule several times throughout this book, we tink it is worth
describing again. Normal policy rules define what is allowed, anything else is a
policy exception, a special attention rule is the opposite of this and specifically
defines what is not allowed.
Figure 9-27 Our Domino special attention rule
The result of creating this policy grouping definition and special attention rule can
be seen in Figure 9-28 and Figure 9-29 on page 271 respectively.
270
7530ch09.fm
Figure 9-28 Policy exceptions for users accessing our Sensitive mail file
Figure 9-29 Special attention alerts for users accessing our Sensitive mailbox out of business hours
9.4.4 Domino R6 auditing conclusion

In this section we have discussed how to add Lotus Domino to your audited
environment using Tivoli Compliance Insight Manager and how Tivoli Financial
Accounting Corporations created some basic policies and attention alerts for
their Domino audit data. In the next section we extend our auditing to the Oracle
platform.
271
7530ch09.fm
9.5 Auditing Oracle 10g systems

As part of phase 2 of Tivoli Financial Accounting Corporations implementation of
Tivoli Compliance Insight Manager we are now going to extend auditing to their
Oracle 10g system. The steps required for configuring Tivoli Compliance Insight
Manager to audit the Oracle 10g system are similar to each of the other systems
we have done to date. For example, configure the target system to produce
appropriate auditable information, setup the target system so that Tivoli
Compliance Insight Manager is able to collect that audit information, configure
the new event source within Tivoli Compliance Insight Manager and create or
modify policies required for the Oracle systems. In this section we show the key
steps that are required to achieve this goal.
9.5.1 Configuring auditing for Oracle 10g systems

The first step is to configure the target Oracle 10g system so that it will produce
the appropriate audit information that will meet our purposes.
Oracle is able to generate audit trail information in several ways and has a very
configurable audit subsystem. It can produce audit information in both operating
system logs or in Oracle tables and can be configured to produce log records for
the following types of events:
Use of specific SQL commands

Actions by specific users
Actions from specific proxies
Use of specific privileges by specific users
Actions on specific tables
Tivoli Compliance Insight Manager can use log data that is produced in either
format, for example, within an Oracle instance or in OS managed log files (in the
case of Windows the OS log file is the Windows application event log).
Configuring Oracle to generate audit log data is described well in Chapter 41 in
the IBM Tivoli Compliance Insight Manager Installation Guide Version 8.0,
GI11-8176.
The basic steps are:
Configure Oracle to generate audit trail information in the format you desire,
for example, in a database table or in the OS logs; we choose the OS log.
This step is performed by modifying the audit_trail parameter in the Oracle
initialization file (see the installation guide for further details). In our case we
set audit_trail=OS as the parameter to signify that we want the Oracle audit
information in the OS log (this parameter can be modified in several ways, for
272
7530ch09.fm
example, editing the config file directly or by using the sqlplus Web interface).
After modifying this parameter you need to restart your Oracle instance.
Run the appropriate Oracle AUDIT commands to set up auditing the way you
desire. We are configuring Oracle in a way to produce extensive audit
information because our database contains very sensitive data. The IBM
Tivoli Compliance Insight Manager Installation Guide Version 8.0, GI11-8176
provides three examples of audit configuration settings for Oracle ranging
from low auditing, medium auditing, to high auditing. The high auditing
settings are configured by running the following Oracle audit commands (from
an sql prompt):
AUDIT SESSION
AUDIT SYSTEM AUDIT
AUDIT USER
AUDIT SELECT, INSERT, UPDATE, DELETE ON DEFAULT BY
SESSION
AUDIT SYSTEM GRANT
These settings allow us to capture all logons and logoffs, all changes to the
audit system itself, all changes to user profiles, all attempts to access any of
our tables or modify any of our tables, and any attempts to grant or revoke
privileges.
Once this has been done we can check that our audit settings have worked by
monitoring the contents of the Windows Application event log. If the settings
have worked you should start to see events as shown in Figure 9-30 appear in
the event log.
273
7530ch09.fm
Figure 9-30 The Oracle audit events in the application event log
Once we have successfully started to generate Oracle audit events we need to

configure Tivoli Compliance Insight Manager to collect those audit events. We do
this in the next section.
9.5.2 Adding the Oracle 10g event source

Now we are ready to define our new Oracle event source. This process is much
the same as adding other event sources so we only show the key steps.
First start the Add New Event Source Wizard from the Tivoli Compliance Insight
Manager Management Console and select the Point of Presence that you would
like to use to collect the Oracle events. In our case there is a Point of Presence
274
7530ch09.fm
already installed on the Windows system on which our Oracle instance is

installed collecting standard Windows audit events.
When asked by the Wizard to select the event source type select the Oracle
event source type as shown in Figure 9-31. Note that you do not need to change
the OS Version (which in our case is Microsoft Windows) but you need to modify
the Source Name so that it matches the Oracle database (the Source Name also
appears in the Windows Application Event log as the source of events).
Figure 9-31 Select the Oracle event source type
Next you are asked for the audit policy profile you want to apply to the Oracle
instance (as shown in Figure 9-32 on page 276). We select none as we have
already configured the auditing settings on the target Oracle instance manually.
You could use these settings to control how the Oracle instance is configured for
auditing (each of the policy level settings, for example, low/medium/high
corresponds to a policy configuration file that contains some SQL commands
that configure the appropriate levels of auditing. We felt more comfortable to
define our Oracle auditing settings manually).
275
7530ch09.fm
Figure 9-32 Audit Policy Profile selection
Next, select a collection schedule and GEM database for the event data (in our
case for testing we chose a schedule of never and the GEM event database of
GENERAL). Once the wizard has completed the event source should be
configured and you are now able to schedule collections and GEM database
loads.
9.5.3 The results

After performing the steps outlined in the sections above you have configured
Tivoli Compliance Insight Manager to collect audit data from Oracle 10g. This
results in Tivoli Compliance Insight Manager collecting the Oracle audit data
from the Windows system hosting our Oracle instance and then mapping it to the
W7 format and loading the data into the GENERAL GEM database. Figure 9-33
on page 277 shows how the Oracle data looks once it is loaded into the GEM
database.
276
7530ch09.fm
Figure 9-33 Oracle data loaded into the GEM database
Now that we have the data within Tivoli Compliance Insight Manager we can
start to write and apply policy and attention rules as we have done previously
with the other data sources. Let us assume we have a sensitive set of data and
we want to be alerted if modifications occur to this data. We modify the policy
grouping so that modifications are highlighted and create an attention rule that
alerts us if the data is modified. The policy definition is depicted in Figure 9-34.
Figure 9-34 A policy grouping for our Oracle data
Our attention rule is shown in Figure 9-35 on page 278.
277
7530ch09.fm
Figure 9-35 Our Oracle special attention rule specification
If we now apply this policy to our Oracle data we see the following results for our
policy groupings (see Figure 9-36 on page 278) and special attention alerts (see
Example 9-37).
Figure 9-36 Our policy rules indicating high severity for attempts to access sensitive data
278
7530ch09.fm
Figure 9-37 Our special attentions indicating access to sensitive Oracle data
At Tivoli Financial Accounting Corporation we further extended our basic policies

with specific cases for the Oracle system data that is now being captured.
9.5.4 Oracle 10g auditing conclusion

In this section we added the Oracle platform to our existing audit collection
practices and then applied some basic policies. The next step was to complete
the policy groupings so that the standard policies could apply equally to the data
that was collected from our Oracle systems.
In the next section we extend auditing to the SAP systems.
9.6 Auditing SAP system

As part of phase 2 of Tivoli Financial Accounting Corporations implementation of
Tivoli Compliance Insight Manager we are going to extend auditing to the SAP
R3 systems running on Windows. The steps required for configuring Tivoli
Compliance Insight Manager to audit SAP R3 are similar to the other systems we
have done to date, for example, configure the target system to produce
appropriate auditable information, setup the target system so that Tivoli
Compliance Insight Manager is able to collect that audit information, configure
the new event source within Tivoli Compliance Insight Manager, and create or
modify policies required for the SAP system. In this section we show the key
steps that are required to achieve this goal.
9.6.1 Configuring auditing for SAP systems

Release 4.0 and later of SAP R/3 supports an internal auditing system, called the
Security Audit Log. Each SAP application server maintains its own daily audit log
279
7530ch09.fm
file. You can specify the name and location of the Security Audit Log using the
rsau/local/file profile parameter. The following information has been taken from
the IBM Tivoli Compliance Insight Manager Installation Guide Version 8.0,
GI11-8176. It describes the various parameters that may be set (see Table 9-1
on page 280).
Table 9-1 Audit log parameter settings for SAP
Audit Log Parameter
Set value to...
rsau/enable
rsau/local/file
path to audit log file
rsau/max_diskspace/local
maximum space to allocate for the audit files
rsau/selection_slots
rec/client
ALL
Note: The rsau/local/file parameter contains the entire path name to the audit
logs, as well as the file name. The file name must include + symbols to contain
a variable datepart. Do not include a file extension in the file name. See the
following examples for clarification.
This example shows a valid path and filename:
/usr/sap/machine1/log/audit_++++++++
This example shows an invalid path and filename; the filename does not
include a datepart:
/usr/sap/machine1/log/audit
This example shows an invalid path and filename; the filename includes a
file extension:
/usr/sap/machine1/log/audit_++++++++.aud
After you have configured the basic audit settings you need to specify the events
to audit and log as described below.
Start SAP transaction SM19 to specify the events to log in the Audit Security Log.
The installation guide for Tivoli Compliance Insight Manager provides suggested
settings to specify the events that you should log and the audit settings for each
of those events.
Another point to note is that SAP R/3 logging is not circular, which means that
when the log reaches the size specified by the max_disksize parameter, the
audit process will stop. To prevent this from happening you should set the
280
7530ch09.fm
max_disksize parameter to a reasonable size and you should schedule an

operating system job to delete old SAP R/3 audit logs (alternatively there is an
SAP transaction SM18 which can do this for you).
After you have configured the SAP R/3 event source to produce appropriate
audit logs you are ready to add it to the Tivoli Compliance Insight Manager
installation.
9.6.2 Adding the SAP event source

Prior to adding the SAP event source you need to install an Actuator on the
system where SAP resides. After this adding an SAP R/3 event source is
handled the same way as adding any other Tivoli Compliance Insight Manager
event source. First you start the Add Event Source Wizard. Select the Point of
Presence machine that collects the SAP audit logs and the GEM database to
take the records. Then select the event source type (as shown in Figure 9-38 on
page 281).
Figure 9-38 Select the SAP R/3 Event Source type
Then define the event source properties as shown below in Figure 9-39 on
page 282. The details required here are the prefix for the SAP Log Name (audit_
by default), the SAP Log Directory, and the SAP Version. Then define a
collection schedule.
281
7530ch09.fm
Figure 9-39 Define the event source properties
After you have completed the Add Event Source Wizard Tivoli Compliance
Insight Manager can now be configured to collect your SAP R/3 audit data.
In the next section we show the results of this data collection.
9.6.3 The results

After we have performed the steps outlined in the sections above we now have
configured Tivoli Compliance Insight Manager to collect audit data from SAP R/3.
This results in Tivoli Compliance Insight Manager collecting the SAP R/3 audit
data from the Windows system hosting our SAP R/3 Instance and then mapping
it to the W7 format and loading the data into our specified GEM database.
Figure 9-40 on page 283 and Figure 9-41 on page 283 show how the SAP R/3
data looks once it is loaded into the GEM database.
282
7530ch09.fm
Figure 9-40 SAP R/3 Data in Tivoli Compliance Insight Manager
Figure 9-41 SAP R/3 Platform History Event List
Again we can now apply a policy to this data in the same way as we applied
policies to each of the other audit event data sources. For example, in our
environment we want to highlight users who have modified an SAP system audit
policy. To do this we can use the following policy group definition using the
standard SAP R/3 Tivoli Compliance Insight Manager provided groupings (see
Figure 9-42).
Figure 9-42 Modify significance of the System Updates what action
We can then create some simple policy rules to emphasize what is considered
normal activity within the policy, such as user actions in office hours, system
283
7530ch09.fm
administration during office hours, report runs outside of office hours, and so on,
as illustrated below (see Figure 9-43 on page 284).
Figure 9-43 Our SAP Policy rules
We also create some attention rules that can alert us if some action is performed
that is not in accordance with our policy, for example, someone modifies our
audit policy as shown in Figure 9-44.
Figure 9-44 Special attention definition for change of SAP Audit policy
These policy and attention definitions result in a dashboard that looks like
Figure 9-45. This dashboard has grouped all of the events according to our policy
groupings and highlights events associated with changes to the SAP audit
policies. It also shows the special attentions.
284
7530ch09.fm
Figure 9-45 SAP compliance dash board
Clicking on the intersection of the Ordinary Users and System Updates grid (this
intersection is highlighted in red because it contains high severity policy
violations) shows us all of the events for Ordinary Users performing System
Update activities (as shown in Figure 9-46 on page 286). Clicking on the special
attention summary icon shows us that the user THIMMEL is our culprit! (this is
shown in Figure 9-47 on page 286).
285
7530ch09.fm
Figure 9-46 High severity policy exceptions displayed
Figure 9-47 Special Attention Summary - highlighting THIMMEL
9.6.4 SAP R/3 auditing conclusion

In this section we extended our Tivoli Compliance Insight Manager
implementation to cover audit data from the SAP R/3 systems. We were able to
add a new event source type and then apply policies and special attention rules
to the data that was captured by Tivoli Compliance Insight Manager.
9.7 Conclusion
In this chapter we have shown how you can add new event sources to a Tivoli
Compliance Insight Manager implementation. Once the event sources are
configured you can create audit policies to report on the data that has been
captured. We also showed how you can create policy rules and apply these with
some basic modifications to the underlying policy groupings across all aspects of
your infrastructure.
286
7530ch09.fm
In the next chapter we extend on these themes further by showing how to create
custom reports using the Tivoli Compliance Insight Manager custom report tool.
287
7530ch09.fm
288
7530ch10.fm
10
Chapter 10.
Customized and regulatory

reporting
In this chapter we discuss how Tivoli Financial Accounting Services can use
Tivoli Compliance Insight Manager for reporting on compliance towards business
regulations that apply to the company, for example Basel II.
289
7530ch10.fm
10.1 Producing customized reports

In Chapter 8, Basic auditing on page 157 and Chapter 9, Extending auditing to
other platforms on page 243 we have discussed how to implement standard
reporting with Tivoli Compliance Insight Manager choosing from its variety of
predefined reports. These reports can be used to perform investigations and root
cause analysis as well as quick reporting to the IT department. However, in some
cases, a more advanced presentation of the data might be required. In order to
answer specific requests from various stakeholders, which are not covered by
the standard reports, Tivoli Compliance Insight Manager provides a custom
reporting functionality, which allows to present the event information collected
with the software product filtered by custom criteria. Also, custom reporting
allows to add a graphical representation of the data in common chart formats.
The Tivoli Financial Accounting Services security policy framework requires the
performance of a systematic attack detection, which is defined in the Tivoli
Financial Accounting Services security policies as the monitoring of logon
failures, if they happen more than five times in a minute, as this might indicate
not a simple user error but a malicious activity against a user account using a
brute force attack.
The CIO office thus asks that a custom report is created for systematic attack
detection and sent to them per e-mail on a daily basis. This can be performed
automatically by Tivoli Compliance Insight Manager.
10.1.1 Creating a customized report

Tivoli Compliance Insight Manager comes with standard reporting on logon
failures. However, this standard report does not consider company-specific
thresholds, nor does it provide a graphical representation of the events, which
can help to directly catch the account that may be under attack.
In order to create a custom report, open the portal and click on iView
Reports Create Custom Report as shown in Figure 10-1 on page 291.
290
7530ch10.fm
Figure 10-1 Adding a custom report
This invokes the Report Editor page, which consists of multiple sections. In a first
step we fill in the fields in the General Information section, as shown in
Figure 10-2.
Figure 10-2 Filling in general information section
The information in this section provides a unique name to the report, a

description with a maximum length of 150 characters as well as the Report
Center, which defines either the tap, under which the report shows in the list of all
Chapter 10. Customized and regulatory reporting
291
7530ch10.fm
reports in the standard report center or the Compliance Management Module, to

which the report should be allocated.
Next, we fill in the Report Layout section of the report editor as shown in
Figure 10-3. As Report Type, we select Threshold Report and configure it to use
a threshold of five events in one minute. This means, that the report only shows
events that occur together with at least another four events of the same kind in
the chosen time window of one minute.
For the understanding of report results, it is important to realize that this report
type basically summarizes every five log events and replaces them with one
respective threshold event in the report.
Figure 10-3 Filling report type and column selection of the report layout
After defining the report type, we select the columns that we would like to see in
the report, by clicking on the W7 items on the left side of the mask. The columns
to be displayed in the report are the platform name, where the event occurred,
and the logon name, which has been used in the event. By default, the number of
events is selected and already shown on the right side of the mask. This item
cannot be deleted, as we have specified in the report type, that we want a
threshold report on events.
292
7530ch10.fm
As the last item for the layout of the report, we want to include a bar chart. This
means that we want to have a bar showing the number of threshold events,
added by platform and by logon name used. Figure 10-4 shows the necessary
selections.
Figure 10-4 Filling the chart definition of the report layout section
Finally, before the report definition is complete, the events must be selected that
should be reported on in the threshold report. This is achieved by defining the
data criteria of the report, as shown in Figure 10-5 on page 294.
293
7530ch10.fm
Figure 10-5 Filling the data criteria section
As we have selected a threshold report type and defined events as the threshold
source, we cannot change the event selection of the data criteria section; it is
pre-defined and greyed out. We have to add a condition, so that only logon
failures are taken into account for the report. Logon failure is an activity that is
described as a what in w7 terminology, and the corresponding detail description
of a logon failure in the model is Logon: User / Failure.
After entering the conditions on the left side of the mask and pressing the Add
button, the rule is displayed on the right side of the mark and we are finished with
the data criteria section. The mask now looks as shown in Figure 10-6.
294
7530ch10.fm
Figure 10-6 Completed criteria section
After we finish the Report Editor by clicking the Save button on the bottom of the
mask, we can see the custom report at the end of the report list in the new
section Tivoli Financial Accounting Services CIO Office Reports together with
the short description we gave it in the Report Editor, as shown in Figure 10-7 on
page 296. The report list is sorted alphabetically by report groups, in which the
reports again are shown in alphabetical order. This means that a custom report
may not show at the end of the list, but in the middle of it, depending on the
report group you used.
Also, the new report is only shown on another system displaying the report list
after a click on the refresh browser button, as the report list including the new
report must be reloaded from the server. So there is no need to panic, in case
you cannot find a newly defined report directly.
295
7530ch10.fm
Figure 10-7 New defined custom report and description at end of report list.
Finally we click on the report to test the report. We can see that the result
matches the requirements, and that the content of the report indicates a possible
brute force attack against six user identifiers, as shown in Figure 10-8.
Figure 10-8 Result of the custom report on Logon Failures
The report shows that more than ten logon failures must have occurred against
the user identifier agoodrich on workstation WXWKST03, as the threshold was
broken not only once like with the other user identifiers, but even twice.
Remember, that the report shows the number of threshold violations, not the
actual number of events. Also, on the same workstation, one threshold violation
has been caused with the user identifier bedwards. By clicking on the violations
296
7530ch10.fm
in the list, you are able to review the events and their detailsjust like with the
standard reporting.
As we can see, the custom report is working as expected and as required. Now,
we need to set up the distribution for the report, so that the CIO office receives it
in their mailbox every day. We show you how to configure this in the next section.
10.1.2 Distributing reports

The CIO office wants to have an update on the custom report Tivoli Financial
Accounting Services Logon Failures above Threshold on a daily basis in order to
be in control and to be able to trigger investigations like checking whether the
user to whom a user identified belongs is still employed or whether the user
might have called the helpdesk reporting an issue to log on.
A Tivoli Compliance Insight Manager administrator can schedule a report to run
on a periodic basis and configure Tivoli Compliance Insight Manager to
automatically send the results to specified e-mail addresses.
In order to set up a scheduled distribution of the custom report, we must first
check, whether the intended recipient of the e-mail is a registered Tivoli
Compliance Insight Manager user, as only these users are allowed to receive
reports.
In order to accomplish this, we open the Compliance Console and invoke the
user management dialog as shown in Figure 10-9 on page 298.
297
7530ch10.fm
Figure 10-9 User Management Dialog in Management Console
Using the Add button, we creat the user CEACIOOFFICE and provided rights to
log onto the portal, to create and edit custom reports and to usewhich means
viewcustom reports in iView. This way the CIO office can access the portal and
also investigate violations in reports received by e-mail.
After confirming that the user exists we open the portal and click on
iView Distribution.
On the following panel Automated Report Distribution we configure the e-mail
settings that are used by the distribution engine to send out the reports.
298
7530ch10.fm
Note: Tivoli Compliance Insight Manager assumes that the mail server
provided in the field Mail-host does not require authentication when the Tivoli
Compliance Insight Manager server connects to the SMTP service. For
example, an internal relay server, ideally setup for system management
activities like report distribution, can be used.
It must be clear, that the sensitivity of the distributed data is high, so that the
mail engine should only be used for internal mail distribution and not for mail
distribution over the Internet.
Also, we fill in the appropriate e-mail address of the CIO office next to the user
CEACIOOFFICE, as shown in Figure 10-10.
Figure 10-10 Automated Report Distribution Setup
Once, these settings are made, we can configure the distribution of the logon
failures threshold report by clicking on Add distribution task, which invokes the
Edit Automated Distribution Task dialog shown in Figure 10-11 on page 300.
299
7530ch10.fm
Figure 10-11 General information section of the automated report distribution editor
To establish a daily automated report distribution for the Tivoli Financial

Accounting Services Logon Failure Threshold Report, we specify the e-mail title,
the body of the e-mail as well as the format of the report, either PDF or CSV in
the general information section as shown in Figure 10-11. Also, we specify the
schedule, recurrence and the run time, which determines when the event query
to the database is performed and the report sent directly thereafter.
Note: As querying the event database can be quite time consuming
depending on the amount of data, and in case you want to have the report
every day, for example, always including the events of the last 24 hours, the
schedule for the loading of the event databases and schedule for the report
distribution must be matched properly, for example, the database loading for a
given database must complete, before the report is run.
Next, in the report section of the editor, we select the Tivoli Financial
Accounting Services Logon Failures Above Threshold report from the drop-down
list, as shown in Figure 10-12 on page 301.
300
7530ch10.fm
Figure 10-12 Report section of report distribution editor
We then add the user CEACIOOFFICE to the lists of recipients in the

addressees section of the editor, as shown in Figure 10-13.
Figure 10-13 Addressees section of report distribution editor
Finally, when we close the editor by pressing the Save button, we return to the
Automated Report Distribution main page, which now shows that the distribution
task has been defined, as shown in Figure 10-14.
301
7530ch10.fm
Figure 10-14 Automated Report Distribution main page with defined task
Now the Tivoli Financial Accounting Services CIO Office will receive one e-mail
every day with a report in PDF format, which shows the logon failures above
threshold.
10.2 Using compliance management modules

Tools like Tivoli Compliance Insight Manager cannot automate the way of
interpretation of regulatory into functional terms. It is wrong to assume, that by
deploying and configuring a compliance management tool a company can
automatically become compliant.
This said, there are compliance management modules for Tivoli Compliance
Insight Manager that each provide a set of pre-defined reports. These reports are
aligned to the structure and/or sections of several given regulatory standard. By
this, they indicate a mapping between the security events, which are logged in
the IT infrastructure and consolidated by Tivoli Compliance Insight Manager, and
the requirement of the given standard.
302
7530ch10.fm
Tivoli Compliance Insight Manager compliance management modules are

currently available for the following regulatory standards:
Basel II
GLBA
HIPAA
ISO17799
Sarbanes-Oxley
These compliance management modules for Tivoli Compliance Insight Manager
can be used as one cornerstone to demonstrate control over the mapped
requirements of a given regulatory standard, to the extent that these
requirements address the technical security infrastructure and can be monitored
with the respective logging mechanisms.
10.2.1 Tool-based regulatory compliance reporting

Before diving into the compliance reporting features of Tivoli Compliance Insight
Manager, it is important to confirm the correct understanding about what tools
can provideand what they cannot providetowards regulatory compliance.
In order for regulations to become binding to organizations, they must be put into
laws, which predominate in the sovereign territory, in which the organizations are
based. As the intent is to preserve the uniformity of laws to a high extentand
prevent that laws must be changed, for example, with every advance in
technologyregulatory clauses in laws formulate rather broad requirements.
Regulatory authorities usually provide further guidance about how to meet these
requirements in more functional terms, which again are still somewhat distant
from technical terms. The actual interpretation into functional and even technical
terms retains with the company. Thus, two companies falling under the same
regulatory requirements can have very distinctive ways in meeting these
requirements and also in reporting upon them, yet still both be able to meet the
requirements.
Further, it is important to choose the right moment to go public with reporting
performed by automated tools. As soon as you have such tools running, they
become part of your official knowledge andin case they are not properly
configured, so that they may show incompliant despite you may be
compliantwill push you into a lot of arguing with your auditors. Such tools,
including Tivoli Compliance Insight Manager, are powerful, so use them with
care.
303
7530ch10.fm
Finally, tools like Tivoli Compliance Insight Manager address detective security
controls primarily, they do not providefor other systems than itselfpreventive
security controls. If a given regulatory standard does require preventive security
controls and you do not have them deployed, Tivoli Compliance Insight Manager
might help you to detect and monitor this, which means, that you are at least in
control of the non-compliance, but the product cannot fix this. To conclude this
topic, regulatory standards may require security controls, which fall outside the
technical remit and must be taken care of on the business level.
10.2.2 Running compliance reports

Tivoli Compliance Insight Manager provides a predefined set of reports. These
reports are grouped to follow the chapters, sections or other structure of a given
standard.
As one example for the usefulness of the compliance reports for Tivoli Financial
Accounting Services, we discuss the requirement that Tivoli Financial
Accounting Services has to comply to Basel II as it finds interpretation to the local
banking laws of the countries, where Tivoli Financial Accounting Services
operates, and as one fundamental example within Basel II, that banks have to
establish non-repudiation for their transactions.
As Tivoli Financial Accounting Services like all other banks today process their
financial transactions with the help of information technology, they must be able
to prove whether or not a transaction has not been manipulated on the IT
infrastructure level.
This makes a log collection and storage of systems which processes financial
transactions essential. The Basel II Compliance Management Module provides
the respective reports, as these are addressed in sections 8.4 and 9.7.1 of the
Basel II accord.
They can be accessed via the portal from the Regulations Resource Center by
clicking iView Regulation.
When selecting the report Log Collection, the report shows the event source, the
planned schedule for the log collection as well as the last collection date and the
events collected in the last collection. The result for the Tivoli Financial
Accounting Services infrastructure is shown in Figure 10-15 on page 305.
304
7530ch10.fm
Figure 10-15 Basel II report on log collection
Similar to this, clicking on the report Log storage provides an overview of the log
storage files created together with the storage data and the event source, of
which the log data is taken from the log database into storage. The example
report for the Tivoli Financial Accounting Services infrastructure is shown in
305
7530ch10.fm
Figure 10-16 Basel II report on log storage
The Basel II management module allows Tivoli Financial Accounting Services a

fast start into technical compliance reporting as input for the overall regulatory
compliance reporting.
10.3 Conclusion
These configurations conclude our custom reporting and compliance reporting
example for Tivoli Compliance Insight Manager at Tivoli Financial Accounting
Services.
We have covered how to create custom reports, how to distribute them via e-mail
and how to use the compliance reporting options of Tivoli Compliance Insight
Manager.
The examples demonstrate that the reporting can be only as good and
meaningful as the definition of a policy. Reports that show a great number of
exceptions, only because these have not been covered in the policy, can create
more disturbance then clarification, so that it is important to perform acceptance
reviews with the receivers of the reports.
306
7530ch11.fm
11
Chapter 11.
System Z integration
In Chapter 6, Introducing Tivoli Financial Accounting Corporation on page 129,
we described Tivoli Financial Accounting Corporations profile and high level
requirements. To summarize, we have to institute controls over data access and
use within the corporate perimeter on many different platforms. We already
covered the distributed environment in Chapter 8, Basic auditing on page 157,
Chapter 9, Extending auditing to other platforms on page 243 and Chapter 10,
Customized and regulatory reporting on page 289. The next step for Tivoli
Financial Accounting Corporation to implement a compliance management
solution and fulfill the business requirements is System Z integration.
Keeping compliance in mind, the business requirements we have identified in
Chapter 7, Compliance management design on page 137, addressed the
implementation processes to help achieve regulatory compliance and reduce
operational risk. In particular, we identified monitoring and reporting on high
privilege user accounts and activities, and access to sensitive company assets
including financial and business data, as well as confidential customer data that
is stored on their servers, as highest priority processes to implement.
By mapping identified business requirements to the underlying reasons and
expanding the reasons in increasing detail, we extracted functional requirements
for multi-platform support, from data collection from the critical systems to
Basel II reporting, including System Z. One of the outstanding capabilities of
Tivoli Compliance Insight Manager is to collect data from distributed systems
such as Unix, Linux, Windows together with midrange event data and System Z.
307
7530ch11.fm
In our scenario some of the business critical applications run on System Z, such
as the corporate banking transaction system, the branch bank teller and
customer online home banking applications. They exploit CICS to process
sensitive financial, business, and customer data stored on the DB2 backend. We
do not go into details here, but Tivoli Financial Accounting Corporations network
deployment from Chapter 6, Introducing Tivoli Financial Accounting
Corporation on page 129 is shown again for reference in Figure 11-1, with
System Z highlighted in bold in production zone.
Figure 11-1 Tivoli Financial Accounting Corporation System Z deployment
In the following sections we show the System Z integration based on our general
design discussion in Chapter 4, Compliance management solution design on
page 73 and the scenario specific design discussion in Chapter 7, Compliance
management design on page 137, followed by applying the same approach for
log collection and management, policies, reporting and regulatory requirements
as those shown in the distributed environment. We start with reporting
requirements as a first step in the analysis phase.
308
7530ch11.fm
11.1 Reporting requirements

The most critical piece of information we need for any successful implementation
are reporting requirements. They tell us what we need to capture and how we
need to report.
Measuring IT security as part of operational risk is easiest when you use a
common standard. Tivoli Compliance Insight Managers Basel II compliance
management module leverages the embedded ISO17799 standard and offers
dozens of reports on compliance to IT security.
To show that the controls are in place, active and working, we have defined the
example set of Basel II reports shown in Table 11-1 below (the numbers in the
brackets refer to sections in ISO 17799):
Table 11-1 System Z Basel II reporting requirements example
Basel II report
Description

attention exceptions

updates, DBA activity, and so on
Actions performed by the IT Admin staff
Actions performed by administrators on users
Successes and failures against key assets

(9.3)
Logon failures and successes either locally or remotely

(9.5.3)

Data and General Data

unsuccessfully

Data

Insight Manager system
Chapter 11. System Z integration
309
7530ch11.fm
Basel II report
Description

critical system components

Proprietary data
Let us add some comments about the Basel II reports from the above table:
Operational change control (8.1.2): The system update report shows changes
to key system components. This report, when used with the incident tracking
report, allows changes to be monitored and recorded and tracked using an
external incident tracking system.
Operator log (8.4.2): Basel II requires that operational staff maintain logs of
their activities. Using this report you can verify the activities of the IT Admin
staff against this log. Examples of these actions include creating, modifying,
deleting administrator accounts, password resets, logon and logoff
successes, and so on.
Review of user access rights (9.2.4, 9.7): This report shows accesses by
users to key resources and shows success and failures. Failures indicate that
the user rights are not sufficient to access the resource. These failures need
to be reviewed to determine whether this user has a legitimate need to
access this data. Similarly, successful accesses must be reviewed on a
regular basis to determine if these users should still have the right to access
this resource and if not have the access revoked or changed.
System access and use (9.2.4.c, 9.7): This report shows accesses by users
to key resources and shows success and failures. Failures indicate that the
user rights are not sufficient to access the resource. These failures need to be
reviewed to determine where the user has a legitimate need to access this
data. Similarly, successful accesses must be reviewed on a regular basis to
determine if these users are still permitted access rights to this resource and
if not have their access revoked or changed.
User responsibilities and password use (9.3): This report shows failed
attempts to logon to the systems and services in the network. Failed logons
can be as simple as someone having forgotten a password to an attempted
breach of security. This report is an excellent starting point for someone
looking to determine in appropriate use of user information or identity theft.
User identification and authentication (9.5.3): This report shows successful
logon and logoff events based on event data collected from systems and
services throughout the enterprise. Using this event data, you can see all user
IDs that are currently in use, determine whether these user IDs and
passwords are being used responsibly, and do a visual inspection to ensure
310
7530ch11.fm
that the user IDs do not reveal the user's role or responsibility in the
enterprise.
Information access restrictions (9.6.1): Monitoring access to key information
systems and access success and failures is key. This report shows who
accessed which key systems.
Sensitive system isolation (9.6.2): This report shows accesses by users to
key resources and shows success and failures. Groups HR DATA, Sensitive
Data, Source code, financial data, and proprietary data are monitored with
this report. Failures indicate that the user rights are not sufficient to access
the resource. These failures need to be review to determine if this user does
have legitimate needs to access this data. Similarly, successful accesses
should be reviewed on a regular basis to determine if these users should still
have rights to access this resource and if not have the access revoked
changed.
Logging and reviewing events (9.7.2.3): Basel II requires that logs be
collected and that these logs not be tampered with. Using this report, you can
see through the Tivoli Compliance Insight Manager self-audit events, whether
any actions have been taken that would compromise this event data. This
report requires a valid Tivoli Compliance Insight Manager policy that
represents the Tivoli Financial Accounting Corporations security policy.
Control of operational software (10.4.1): Control of change and update to
system files and resources is essential to control risk. This report shows who
accessed and changed which system resources. Modification made to the
audit subsystem need to be reported because any modification affects the
level of information in any of the other reports discussed.
Data access (12.1.4): The data access report monitors access to key data
resources. The report shows access to resources defined in the HR_DATA,
SENSITIVE_DATA, PROPRIETARY_DATA, FINANCIAL_DATA and
GENERAL_DATA, who accessed the data and from where.
We show real data from our scenario for some of these reports later in Reports
on page 351.
Our next step is to specify the audit data to collect in order to support our
reporting requirements. We provide audit settings that support Tivoli Financial
Accounting Corporations Basel II System Z required reports in the next section.
11.2 Audit settings

The goal of this task is to specify the audit data to collect in order to support Tivoli
Financial Accounting Corporations Basel II System Z reporting requirements. In
311
7530ch11.fm
most cases, auditing every action is not an option, thus we analyze the audit
subsystem and determine, evaluate, and provide audit settings that support
reporting requirements for event sources on the System Z platform.
For audit data Tivoli Compliance Insight Manager uses the event data that is
created through normal System Management Facilities (SMF) processing on
System Z.
SMF is a component providing a standardized method for writing records of
activity to a file (or a data set using System Z terms). SMF provides full
instrumentation of all baseline activities running on System Z, including I/O,
network activity, software usage, error conditions, processor utilization, and so
on. It forms the basis for many monitoring and automation utilities. Each SMF
record has a numbered type (for example "SMF 120" or "SMF 89"), and
operators have great control over how much or how little SMF data to collect.
Based on reporting requirements example identified in previous sections, we
determined the System Z audit settings example needed for our scenario, shown
in Table 11-2 below:
Table 11-2 System Z Basel II audit settings example
SOX report
Audit settings
None
SMF 9, SMF 11, SMF 52, SMF 53, SMF 54, SMF 55, SMF
56, SMF 58, SMF 80 events SETROPTS, CHAUDIT, SMF
90 subtypes 1, 3, 4, 6, 16, 18, 19, 20, 21, 22, 23, 24, 25, 27,
28, 29, 31
52, SMF 53, SMF 54, SMF 55, SMF 56, SMF 58, SMF 61,
SMF 62, SMF 64, SMF 65, SMF 66, SMF 80 events
SETROPTS, CHAUDIT, ALTDSD, PERMIT, RALTER,
RDEFINE, RDELETE, ADDVOL, RENAME, DELETE,
DELVOL, DEFINE, DELDSD, ADDSD, ACCESSSMF, SMF
90 subtypes 1, 3, 4, 5, 6, 13, 14, 16, 18, 19, 20, 21, 22, 23,
24, 25, 27, 28, 29, 31, SMF 92 subtypes 10, 11, SMF 118
56, SMF 58, SMF 80 events SETROPTS, CHAUDIT, SMF
90 subtypes 1, 3, 4, 6, 16, 18, 19, 20, 21, 22, 23, 24, 25, 27,
28, 29, 31
312
7530ch11.fm
SOX report
Audit settings
90 subtypes 1, 3, 4, 5, 6, 13, 14, 16, 18, 19, 20, 21, 22, 23,
24, 25, 27, 28, 29, 31, SMF 92 subtypes 10, 11, SMF 118

(9.3)
SMF 30 subtypes 1, 5, SMF 118 subtype 72, SMF 80 event

RACINIT

(9.5.3)

RACINIT
90 subtypes 1, 3, 4, 5, 6, 13, 14, 16, 18, 19, 20, 21, 22, 23,
24, 25, 27, 28, 29, 31, SMF 92 subtypes 10, 11, SMF 118
90 subtypes 1, 3, 4, 5, 6, 13, 14, 16, 18, 19, 20, 21, 22, 23,
24, 25, 27, 28, 29, 31, SMF 92 subtypes 10, 11, SMF 118
90 subtypes 1, 3, 4, 5, 6, 13, 14, 16, 18, 19, 20, 21, 22, 23,
24, 25, 27, 28, 29, 31, SMF 92 subtypes 10, 11, SMF 118
None

RACINIT
313
7530ch11.fm
SOX report
Audit settings
90 subtypes 1, 3, 4, 5, 6, 13, 14, 16, 18, 19, 20, 21, 22, 23,
24, 25, 27, 28, 29, 31, SMF 92 subtypes 10, 11, SMF 118
Typically it is the System Z system programmers who actually configure SMF

audit settings on System Z.
Based on the System Z Basel II audit settings example in the table above, we
predict roughly 3 Gb of audit data per day from each Logical Partition (LPAR) on
Tivoli Financial Accounting Corporations System Z.
We have the following recommendations for SMF audit settings:
To audit logon in RACF we must capture SMF record type 30, subtype 1.
This reflects the time of logon for TSO sessions and batch jobs.
In addition, we must collect RACINIT events in SMF record type 80, to
capture logon to CICS, session managers, and so on.
Logoff from TSO has to be logged to track the end of a session. This is
reflected by SMF record type 30, subtype 5.
Record type 30, subtype 2 and 4 generate a huge volume but are not relevant
for auditing.
Data set access is captured in SMF record type 80, ACCESS events.This
requires that the profiles protecting the data sets have AUDIT(ALL(READ))
for confidential data and AUDIT(SUCCESS(UPDATE) FAIL(READ)) for the
change of sensitive data.
For more information about SMF, see z/OS MVS System Management Facilities
(SMF), SA22-7630 and z/OS Security Server RACF Macros and Interfaces,
SA22-7682-03.
Now that the audit subsystems have been configured and activated on the target
machines, we can start with Tivoli Compliance Insight Manager implementation
for the System Z, which is covered in the next section.
314
7530ch11.fm
11.3 Implementation
Based on our analysis and the System Z Basel II audit settings example
configuration, a new Standard Server will be dedicated for the System Z and
added to the Tivoli Compliance Insight Manager cluster as show in Figure 11-2,
with the System Z and Tivoli Compliance Insight Manager cluster highlighted in
bold in production and management zone respectively.
Figure 11-2 Tivoli Financial Accounting Corporation Tivoli Compliance Insight Manager cluster
The Tivoli Compliance Insight Manager Basel II compliance management

module integration is also a part of the System Z implementation, which we
execute in the following steps:
1. Standard Server implementation
2. Actuator implementation
3. Basel II compliance management module implementation
11.3.1 Standard Server implementation

To implement our new Tivoli Compliance Insight Manager Standard Server we
perform an installation before we proceed with the configuration.
315
7530ch11.fm
Installation
The steps for the Standard Server installation are as follows:
Standard Server.
3. Register the Standard Server with the Enterprise Server.
We do not describe the Standard Server installation and registration to the
Enterprise Server here as it is straightforward. For more details on each of these
steps see the IBM Tivoli Compliance Insight Manager Installation Guide Version
8.0, GI11-8176-00.
Configuration
Tivoli Compliance Insight Manager configuration involves the following high level
steps in the Tivoli Compliance Insight Manager Management Console:
1. Create a GEM database to store the event data
2. Create a System Z Machine Group
Each of these steps are outlined in the following sections.
Create GEM database

We create new GEM database for loading all System Z related event data. Tivoli
Financial Accounting Corporation will be storing all System Z event data in a
database called FINANCE, as shown in Figure 11-3.
Figure 11-3 Add FINANCE database
Based on the System Z Basel II audit settings example in Audit settings on

page 311, we predict roughly 3 Gb of audit data per day from each System Z
316
7530ch11.fm
LPAR on Tivoli Financial Accounting Corporations System Z. We have three

LPARs in the System Z environment to serve the corporate banking transaction
system, branch bank teller and customer online home banking applications. Thus
in total we expect roughly 9 Gb of audit data per day. To be on the safe side, we
configure the FINANCE database for 15 Gb (15 x 1024 Mb) as shown in
Figure 11-3 above.
Figure 11-4 shows how the FINANCE database appears in the Database View.
Figure 11-4 Tivoli Financial Accounting Corporation FINANCE database
Create Machine Group

In order for Tivoli Compliance Insight Manager to monitor one or more event
sources on a particular machine, the machine needs to be registered in the
Management Console. If desired, the registered machines can be grouped
together into Machine Groups to organize the audited systems.
Tivoli Financial Accounting Corporation wants to group their audited System Z
machines into a Machine Group called SystemZ.
We create a System Z group SystemZ in the Management Console as shown in
Figure 11-5.
Figure 11-5 Add SystemZ Machine Group
The new SystemZ Machine Group is now displayed in the Machine View window
317
7530ch11.fm
Figure 11-6 Tivoli Financial Accounting Corporation SystemZ Machine Group
After the new Standard Server is installed and registered with the Enterprise
Server and both the GEM database and Machine Group are prepared, we can
focus on on our System Z target and implement Actuators to start collecting
required audit data.
11.3.2 Actuator implementation

The Tivoli Compliance Insight Manager Actuator component on System Z copies
selected SMF data to a file that is stored in Unix System Services (USS) and
then passes the data to the Tivoli Compliance Insight Manager Server. The
Actuator consists of the following processes:
The Agent
The Agent provides a secure communication channel to the Tivoli
Compliance Insight Manager Server. It is typically started soon after Initial
Program Load (IPL) and only stopped in preparation for the next IPL.
The User Information Source Actuator
This Actuator collects data from the security data base and from the
CKFREEZE data set.
The Event Source Actuator
This process reads live or accumulated SMF data and generates an extract
available to be used by the Agent. The Event Source Actuator also references
the User Information Source data.
SMF records are written to SMF data sets when they are created. These are then
periodically dumped to sequential files using the SMF Dump Utility (IFASMFDP).
IFASMFDP can also be used to split such sequential files and copy them to other
files.
318
7530ch11.fm
Note: The original SMF data is not deleted, changed or moved, the data is
only copied. This means that other processes that use this data to report on
specific data and events in the System Z environment are not affected by
Tivoli Compliance Insight Manager. This also preserves the originating data
for further processing or forensic analysis tasks where it may be required for
chain of evidence needs.
System requirements
Here is a list of the system requirements on System Z for implementing the
Actuator.
SMF processing has to be activated.
UNIX System Services (USS) have to be available.
A user id is needed with the authority to:
Define users, groups, directories and file systems.
Define a set of IP ports to be allocated for the Agent.
Create and mount recommended HFS or zFS filesystems.
Setup STARTED or SURROGAT profiles.
Update access to one of the procedure libraries of the Job Entry
Subsystem.
Create entries in the Job Scheduler and/or Automated Operations.
Adjust and synchronize USS timezone(s).
Unicode support.
TCP/IP security.
Tivoli zSecure 1.7.0 at PTF PZ01300 or higher.
Preparation
It is recommended to use separate file systems for the Actuator software and the
Agent data.
It is also recommended to create two separate RACF users:
One that owns the Actuator software and directories.
One that owns the Agent data and directories and has read and execute
permission on the Actuator software and directories.
The defaults shown in Table 11-3 on page 320 are used here:
319
7530ch11.fm

Table 11-3 System Z owners, directories and filesystems
Software
data
Owning User
C2RUSER
C2RAUDIT
Owning Group
C2RGROUP
C2EGROUP
Directory
/usr/lpp/c2e/vx.y
u/c2eaudit/actuatr1
Mountpoint
/usr/lpp/c2e
u/c2eaudit
Filesystem
OMVS.C2R.HFS
OMVS.C2EAUDIT.HFS
Variable
C2ESW
C2EPATH
Software installation
In order to install the software follow these steps.
1. Run the job C2RZCHFS from the CNRINST library to prepare the location
where the software is to be installed. This job must be executed under root
authority.
2. The recommended install directory is /usr/lpp/c2e/v8.0. The install directory is
referred to as C2ESW.
3. Upload the file C2EPAX.Z from the z/OS directory on the Tivoli Compliance
Insight Manager CD into an HFS or zFS file on System Z in binary mode.
4. Run the job C2EUNPAC from the CNRINST library to unpack the software.
This job can be run as root where C2RUSER and C2RGROUP is substituted
in shown step or as SURROGAT where USER=C2RUSER and
GROUP=C2RGROUP.
5. Provide the location of the C2EPAX.Z file and the software installation
directory (C2ESW) to the job.
Agent installation
1. Edit or at least uncomment the Actuators specific parameter section in the
zSecure configuration (default C2R$PARM of library C2RPARM). Specific
parameters are C2ECUST, C2EPATH, C2ESW, C2ELVPFX,and C2ELVLLQ.
Only C2EPATH and C2ELVPFX are mandatory.
The parameters are documented in Appendix E in zSecure Suite:
CARLa-Driven Components Version 1.8.1, SC23-6556-00.
2. Run the job C2EZAUSR in the CNRINST library to create the Agent's owner,
group, home directory, and filesystem if needed.
3. Change the USER parameter to the user id that will run the agent.
320
7530ch11.fm
4. Include the location of the Agent's typical C2R$PARM that contains the
correct C2EPATH parameter in the C2EJSTRT job.
5. Set the C2ESW parameter to the software install directory (/usr/lpp/c2e/v8.0).
6. Run the job C2EAROOT in the SCKRSAMP library to build the agent's root
directory. Among others this creates a symbolic link in the root directory
called bin to the C2ESW.
Attention: Do not start the Agent job or procedure until after having set up
the secure connection.
For more information on Software and/or Agent installation see zSecure Suite:
CARLa-Driven Components Version 1.8.1, SC23-6556-00.
Agent activation
Before starting the Agent activation, let us consider how the following
recommendations about performance and multiple LPARs apply to the Tivoli
Financial Accounting Corporation System Z environment:
Generally recommended setup:
Separate Agents on each System Z LPAR that you want to monitor.
Live strategy for the event source, with a schedule as frequent as it
corresponds to the demand to have events available on the Tivoli Compliance
Insight Manager server in a reasonable time.
If the Agent for Tivoli Compliance Insight Manager is the only component of
zSecure, also use a Live strategy for the User Information Source. A collect
schedule of once a day is sufficient for most cases.
Multiple System Z LPARs recommended setup:
When processing multiple System Z LPARs, the recommended setup is that
each System Z LPAR has its own Agent, processing SMF, CKFREEZE, and
the security database from that System Z LPAR. However, when most of the
DASD is shared, a performance gain can be achieved by not writing all
shared information to all CKFREEZEs.
A multiple System Z LPAR Agent usually requires more processing than
several single Agents. This is because each event source collects references
to all User Information Source data, for example: CKFREEZEs, and possibly
UNLOADs from all System Z LPARs are processed during each chunk of
SMF collection.
In general, multiple System Z LPAR Agents are not recommended. If you run
with a common SMF accumulation data set and do not wish to split that, you
may consider setting up a single System Z LPAR Agent on each System Z
321
7530ch11.fm
LPAR and use a Live event source. This way, each Agent only processes its
own System Z LPARs SMF. There is no objection against combining the Live
event source with a Poll or Wait User Information Source.
Each of the LPARs on System Z that need to be audited should be added as a
new machine. Tivoli Financial Accounting Corporation will place each of its
System Z targets into the new SystemZ Machine Group. In this section, the setup
and configuration for auditing one of the System Z LPARs is shown. Tivoli
Financial Accounting Corporation repeats this process for adding other System Z
LPARs.
These steps are performed to add each System Z LPAR:
1. With focus on the SystemZ Machine Group in the Management Console
Machine View, we start Add Machine Wizard, as shown in Figure 11-7.
2. In next window we select the Audited Machine Type from the available
drop-down menu. For Tivoli Financial Accounting Corporations System Z, the
correct machine type is IBM z/OS or OS/390 as shown in Figure 11-8.
322
7530ch11.fm
Figure 11-8 Choose Machine Type
Note: Checking the Show Available Event Source Types checkbox causes the
Event Source Type panel on the right hand side of the screen to appear. This
allows you to browse the supported event sources for the type of machine you
are adding.
3. In the next window we enter the name of the target machine(s) to be audited
in the Name input box within the Machine frame. Figure 11-9 shows our first
target on System Z, LPAR ANIT.
Figure 11-9 Choose Machine
323
7530ch11.fm
4. We add the Machine to the Selected area as shown in Figure 11-10, to be

able to test it against DNS resolving. Click Test to commence a DNS lookup.
Figure 11-10 Add Machine
5. The DNS lookup should resolve host name or IP address of the machine as
Figure 11-11 DNS lookup
6. Next, a local Actuator is installed on each of the target machines. This option
is selected as shown in Figure 11-12.
324
7530ch11.fm
Figure 11-12 Select Point of Presence
7. The default IP port that is used for communication is 5992. We check the
availability of the configured port, and if the system requirements discussed at
the beginning of this section are met, we receive the following message box
Figure 11-13 IP port success
8. In case of port success we can leave the default setting as shown in

Figure 11-14.
325
7530ch11.fm
Figure 11-14 Configure Point of Presence
As also shown in the above figure, the Install Type is always manual by default
for IBM z/OS or OS/390 Machine Type.
However, the default port tested might not be free, as shown in the example
message box below, with details, in Figure 11-15.
Figure 11-15 IP port not free
If the IP port is not free, you can find one as shown in Figure 11-16. By default, IP
port 23000 is used in that case, if available.
326
7530ch11.fm
Figure 11-16 Find free port
You might also experience an unexpected side effect of System Z, such as

dynamic Virtual IP Addressing (VIPA).
With VIPA, the DNS holds the Virtual IP Address of the System Z, but this
address does not really exist. System Z has another network address (physical
address) that accepts packages with the main address as destination. When the
System Z sends packages, they originate from the physical address.
This is designed for instant recovery when one of the System Z LPARs dies. A
backup machine can take over and accepts the packages sent to the virtual
address.
The Tivoli Compliance Insight Manager server has been designed to refuse
packages that claim to be from an Agent but have an IP address that does not fit
the value in the configuration file. Those messages will be dropped.
Also, a System Z can have several network interfaces, each with a different IP
address. If this is the case, packages received from the System Z can have a
different address from what the DNS says.
Tip: Specify the IP physical address of the System Z LPAR by issuing a
netstat command on the TSO prompt and look at the local socket column.
Note: You may find the IP physical address this way, but there is no absolute
guarantee.
327
7530ch11.fm
Important: Another option is to configure Tivoli Compliance Insight Manager

server in a way that it may ignore the IP address of messages that claim to be
from the System Z Agent. This removes a security feature of the
communication layer, so it should be done with caution.
9. Next we choose the correct Event Source Type, in our scenario z/OS, as
Figure 11-17 Choose Event Source Type
10.The final wizard window is shown in Figure 11-18.
Figure 11-18 Complete Add Machine Wizard
328
7530ch11.fm
11.Before we finish our configuration we save the configuration file needed for
Agent activation. Click Save and enter a filename as shown in Figure 11-19.
Figure 11-19 Save configuration file
12.We now transfer this configuration file in text mode to the Agent root directory
on System Z (C2EPATH).
13.To initialize the Agent, we run the C2ECNNT job located in CNRINST under
the user id that owns the Agent install directory (C2EAUDIT). To verify
success we check the agent.log file located in the C2EPATH/log directory for
the string: LCM: Initial certification completed successfully.
Note: A configuration file is only valid for 24 hours before it expires.
14.Run the C2EJSTOP job in SC2RJOBS library, again using the C2EAUDIT
user id, to stop the initialization process.
15.Continue to activate the Agent using the C2EJSTRT job in SC2RJOBS library
using C2EAUDIT user id.
329
7530ch11.fm
Add event source

Immediately after the Add Machine Wizard completes, the Event Source Wizard
will automatically run.
In this section we illustrate how to complete the Add Event Source Wizard for the
z/OS Event Source on the ANIT System Z LPAR.
1. We continue on the Add Event Source Wizard welcome screen that is
displayed as shown in Figure 11-20. Click Next.
Figure 11-20 Add Event Source Wizard
2. Next we define z/OS Event Source properties. We use default settings with
the Live collection strategy as recommended before. Table 11-4 provides
properties explanation.
Table 11-4 Event Source properties
330
Property
Description
Collect past data
Configures the collection of SMF records regardless of the time

stamps. This option is intended for recovery of lost SMF intervals,
and for initially loading a Tivoli Compliance Insight Manager
server with SMF data. For normal production, it should be set to
NO. When this property is set to NO, SMF intervals that have
already been collected will not be collected again.
7530ch11.fm
Property
Description
Collect strategy
Determines how the collection is executed. The options are Live,

Poll, or Wait.
Live: SMF data is collected from the System Z LPAR where the
Agent is running. No more than one event source per Agent
should run under the Live strategy. Using the Live strategy (with
the SMF switch intercept) guarantees that no SMF records is
lost, provided that the SMF data sets are off loaded in the correct
order.
Poll: Data is collected from the data set that you specify under
SMF Data Set Name. If this data set is in use at the moment that
event source collection starts (or, for instance, when the data set
resides on tape and all tape drives are in use), this particular
event source collection is cancelled. The schedule remains
active, therefore in time a new attempt is made.
Wait: Same as Poll strategy, the difference being that if the data
set is in use, the event source collection waits (up to half an hour)
until the data set is available.
Error retention
Number of days that message log files are kept. Older log files
are deleted at the next event source collect.
SMF Dataset name
Data set from which data is collected when the collect strategy is
Poll or Wait. For normal production, you should specify your SMF
accumulation data set here. Often, installations off load their
active SMF into a data set that is member of a Generation Data
Group (GDG), for instance: off load into
SYS2.WEEKLY.SMF(0),and once a week create
SYS2.WEEKLY.SMF(+1). If your installation uses a GDG, you
can specify SYS2.WEEKLY.SMF(0), which represents the most
recent member of the GDG. Processing ACF2 data by an Agent
that runs on a RACF system, or reverse, is not supported. This
field must be empty when the collect strategy is Live.
Store raw files
Reserved for future use.
Enter the proper Event Source Properties now as shown in Figure 11-21 on
page 332. Click Next to continue.
331
7530ch11.fm
Figure 11-21 Define Event Source Properties
For better understanding we depict System Z Live as well as Wait and Poll
strategies in Figure 11-22 and Figure 11-23 respectively. In the Live strategy,
the Event Source will only read the intercepted SMF datasets.
LPAR
OS Batch
SMF MANx
datasets
Unix System Services
SMF Archive
datasets
CARLa
extract
Compressed
extract
TCIM
Actuator and
Agent function
Figure 11-22 System Z Live collect strategy
332
7530ch11.fm
LPAR
OS Batch
SMF MANx
datasets
CARLa
extract
Unix System Services
SMF Archive
datasets
SMF Archive
datasets
SMF Archive
datasets
Compressed
extract
TCIM
Actuator and
Agent function
Figure 11-23 System Z Wait and Poll collect strategy
3. In the next dialog we choose a Collect Schedule as shown in Figure 11-24.

Click Next to continue.
333
7530ch11.fm
As recommended in the Agent activation section, we choose to collect data

on a daily basis, at 1 am, when System Z utilization is low. As we expect
about 3 Gb of data from each System Z LPAR, we plan to provide the system
reasonable time to load this data into the GEM database a few of hours later.
4. We choose to load audit data into the prepared FINANCE database as
shown in Figure 11-25. Click Next to continue.
Figure 11-25 Choose a GEM Database
5. For the Load Schedule we choose to load data on a working day basis, at 3
am, as shown in Figure 11-26. Click Next to continue.
This schedule allows for System Z audit data to be collected on time from all
System Z LPARs and then loaded into the FINANCE GEM database. On the
other hand, audit data collected from Friday to Sunday is loaded as late as
Monday morning, but there is no expected high activity during the weekend
on System Z, thus we do not expect the Tivoli Compliance Insight Manager
server to be overloaded.
For reporting reasons we want last weeks data available at any time, thus we
are using a seven day sliding schedule as shown in Figure 11-26.
334
7530ch11.fm
Figure 11-26 Choose a Load Schedule
6. We complete the Add Event Source wizard as shown in Figure 11-27. Click
Finish.
335
7530ch11.fm
Figure 11-27 Complete Add Event Source Wizard
After we have repeated the implementation process to the current point for all
three Tivoli Financial Accounting Corporations System Z LPARs, namely ANIT,
ASRU, and AZEN, the Tivoli Compliance Insight Manager Management Console
Machine View reflects the status of System Z LPARs as shown in Figure 11-28.
Figure 11-28 System Z Machine View
Similary, the Event Source View in Tivoli Compliance Insight Managers

Management Console reflects the status of System Z event sources as shown in
Figure 11-29.
336
7530ch11.fm
Figure 11-29 System Z Event Source View
Lastly, the Database View in Tivoli Compliance Insight Managers Management

Console reflects the System Z FINANCE database status as shown in
Figure 11-30.
Figure 11-30 System Z Database View
In the following step we configure a User Information Source with a Live collect
strategy using the Management Console. We have to run at least one User
Information Source collect before we run any Event Source collect, otherwise the
Event Source collect will fail, because the CKFREEZE data set was never written
into. Thus we postpone loading and testing the FINANCE database for now.
Add user information source

It is not always necessary to define the grouping process manually. For System
Z the Tivoli Compliance Insight Manager server produces the grouping functions
for the Who and Where grammatical form. It reads the user databases for the
System Z platform and translates the information to a grouping function
definitions. These grouping functions are merged with the user defined grouping
functions during the grouping process. The merging process looks at the most
recent collection time of the chunks selected for loading and finds the most
recent user information grouping definitions for all supported platforms, created
before the most recent chunk is loaded.
337
7530ch11.fm
The user information source is actually yet another event source responsible for
the collection of the user database information. The collected information is also
stored in the Tivoli Compliance Insight Manager server archive as a chunk. The
information is already stored as a grouping function definition and is used during
a scheduled load of a database.
We add the z/OS user information source using the Management Console to
include RACF user and IOCONFIG information in the reports.
In this section we illustrate how to complete the Add User Information Source
Wizard for the z/OS user information source on the ANIT System Z LPAR.
1. We start with the Add User Information Source Wizard welcome screen that is
displayed as shown in Figure 11-31. Click Next to continue.
Figure 11-31 Add User Information Source Wizard
2. Next we choose a machine as shown in Figure 11-32. Click Next to continue.
338
7530ch11.fm
Figure 11-32 Choose a Machine
When loading data into a GEM database, Tivoli Compliance Insight Manager
uses the group definitions from the user information source in addition to the
groups defined in the policy. User information from a user information source
is applied to all event sources from the same operating system.
3. We chose z/OS grouping for our scenario as shown in Figure 11-33. Click
Next to continue.
339
7530ch11.fm
Figure 11-33 Choose a User Information Source
4. Next we define z/OS Event Source properties. We use default settings, with a
Live collection strategy as recommended before and shown in Figure 11-34.
340
7530ch11.fm
Figure 11-34 Define User Information Source Properties
Table 11-5 below provides a description of the user information source

properties.
341
7530ch11.fm

Table 11-5 User Information Source properties
Property
Description
Collect strategy
The collection strategy used by the Point of Presence to collect

the user information source data. There are three collection
strategies:
Live: The user data is read from the Primary RACF database
while policy relevant data is read from an IOCONFIG dataset.
The dataset creation is triggered by the user information source.
Poll: The user data is read from the Primary RACF database
while policy relevant data is Collect strategy read from an
IOCONFIG dataset. The dataset is defined in the IOCONFIG
Data Set Name property. If this dataset is being used during
collection, an error will be returned.
Wait: The user data is read from the Primary RACF database
while policy relevant data is read from an IOCONFIG dataset.
The dataset is defined in the IOCONFIG Data Set Name
property. If this dataset is being used during collection, the user
information source will try to collect again 30 minutes later.
Complex name
Logical name given to a set of System Z LPARs that share the

same users in a RACF database. All event sources that collect
the SMF from this set of System Z LPARs will prefix the RACF
user IDs found in the SMF with the Complex name.
Error retention
The number of log files sets to maintain in C2EPATH/

log/*.props directory for this user information source.
IOCONFIG
Dataset Name
Name of an existing IOCONFIG dataset used by this user

information source to obtain system specific information and add
it to the zOS grouping file. This field should be empty when using
the Live strategy.
System policy type
Determines in which W7 WHERE group the System Z LPAR will

be categorized such as Systems with non-segregated
administration and Systems with segregated administration.
UNLOAD Data Set

Name
Name of an existing unloaded RACF dataset related to the

IOCONFIG Dataset Name parameter. This field should be empty
when using the Live strategy.
5. Again, as with the event source and as recommended in Agent activation on

page 321, we choose to collect data on a daily basis, at midnight as shown in
Figure 11-35, when System Z utilization is low and before the event source
collect begins. Click Next to continue.
342
7530ch11.fm
6. We complete the Add User Information Source wizard as shown in

Figure 11-36. Click Finish.
343
7530ch11.fm
Figure 11-36 Complete Add user Information Source Wizard
After we repeat adding user information source configuration for all three Tivoli
Financial Accounting Corporations System Z LPARs, namely ANIT, ASRU, and
AZEN, the Tivoli Compliance Insight Manager Management Console Machine
View reflects the status of System Z LPARs as shown in Figure 11-37.
Figure 11-37 System Z Machine View
Similarly, the Event Source View in Tivoli Compliance Insight Managers

Management Console reflects the new status of System Z Event Sources as
344
7530ch11.fm
Figure 11-38 System Z Event Source View
Lastly, there are no changes in the Database View in Tivoli Compliance Insight
Managers Management Console as shown in Figure 11-39.
Figure 11-39 System Z Database View
This concludes our section about the Actuator implementation. We can begin
collecting audit data now. The last step before we can show System Z Basel II
compliance reports is the Basel II compliance management modulel
implementation.
11.3.3 Basel II compliance management module implementation

Now that we can collect, load and store needed audit data from the System Z
machines, we have to perform an additional step to be able to report on this data
according to Basel II compliance regulations.
A best practice approach for a regulatory compliance life cycle is as follows:
Evaluate
Install compliance management module
Import templates
345
7530ch11.fm
Configure W7 groups
Adjust reports
Commit policy
Re-evaluate
In this section we go through the life cycle of the Basel II compliance
management module, which includes the installation, implementation, and finally
Basel II compliance reports as identified in the Tivoli Financial Accounting
Corporation requirements. The goal is to produce Basel II compliance reports for
its System Z environment.
Installation
The IBM Tivoli Basel II Management Module Installation Guide Version 8.0,
GI11-8177-00 provides an overview and installation information for the IBM Tivoli
Basel II compliance management module, so we do not go into details here.
After successful installation from a self-extracting executable on a separate CD,
the Basel II compliance management module is displayed in the Tivoli
Compliance Insight Manager Management Modules section of the portal as
346
7530ch11.fm
Figure 11-40 Tivoli Compliance Insight Manager Basel II compliance management module
Optionally, the templates, reports, and documentation associated with the Basel
II compliance management module can be accessed in the iView Regulations
Resource Center as shown in Figure 11-41.
347
7530ch11.fm
Figure 11-41 Tivoli Compliance Insight Manager Regulations
Let us explain some of those components below.
Classification Template
A W7 Classification Template helps us build W7 groups according to the Basel II
regulation.
The Classification Template is a link to the grouping.cfg file that contains a
complete list of all group names for each and every W7 category used by the
Basel II compliance management module report and Tivoli Compliance Insight
Manager policy. The template can be exported using the download button, but it
is recommended to use the Windows file explorer to copy the file from the
\iView\Web\regulations\basel\ directory to the destination in the policy directory.
Figure 11-42 partially shows the onWhat category in the Basel II classification
template.
348
7530ch11.fm
Figure 11-42 Basel II Classification Template
The Classification Template is an empty W7 classification. Containing no

references to entities but the description for each groups, it explains what type of
entities should be classified by the group.
Policy Template
The Policy Template contains a set of policy and attention rules based on the
regulation's recommendation.
This is the link to the policy.pcy file that is installed with the grouping file
belonging to the Basel II compliance management module. Again, this file can be
downloaded using the download button, but is recommended to use the windows
file explorer to do this from \iView\Web\regulations\basel\directory.
Policy Rules from Basel II Policy Template are shown in Figure 11-43.
349
7530ch11.fm
Figure 11-43 Basel II Policy Rules template
The Policy Template contains policy and attention rules based on the
recommendations in the Basel II regulation. These recommendations were
evaluated and translated into the W7 model and included if meaningful coverage
can be achieved.
A partial list of all Attention Rules from the Basell II Policy Template is shown in
Figure 11-44.
350
7530ch11.fm
Figure 11-44 Basel II Attention Rules template
As with the grouping.cfg file or Classification Template, the file contents are used
in the Tivoli Compliance Insight Manager default policy. Once used there, the
groups and rules will build the dashboard contents in iView. The policy rules
used in the Management Module are derived from the Basel II compliance
regulation.
Reports
The reports section contains the reports required by the regulation.
The most important link of the Basel II compliance management module is the
Reports link. It provides access to the set of reports specially defined for the
Basel II compliance management module. Every report has a link to a paragraph
in the compliance regulation that discusses the need for information of the type
shown in the report.
351
7530ch11.fm
These reports are build according to the report requirements recognized in the
Basel II regulatory compliance document.
Figure 11-45 shows a partial list of Basel II regulation reports.
Figure 11-45 Basel II Reports
The set of reports is partly a set of text files found in the

\iView\Srv\reports\nl\consul\regulations\basel\ directory for the Basel II
compliance management module. Some reports are hard coded in a Java class
but most are coded in the .pearl files.
Import
Once the compliance management module has been installed we need a
working policy. Because we want System Z to be compliant to Basel II
regulations, we use templates that come with Basel II compliance management
module and customize them to suit Tivoli Financial Accounting Corporations
System Z need. This paragraph explains what needs to be done.
It is a recommended approach in Tivoli Compliance Insight Manager to create a
duplicate of Tivoli Financial Accounting Corporations default predefined policy,
located in the committed folder in
\Server\config\grouping\committed\20000101000000 and start with that.
352
7530ch11.fm
Although it can be used as a template for all supported systems, at the moment
we dont want to deal with anything else but System Z.
1. We create a new empty System Z policy called SystemZ in the work directory
(..\Server\config\grouping\work on hard drive), as shown in Figure 11-46.
Figure 11-46 Create Basel II policy
Later on, we can merge this policy into a common Tivoli Financial Accounting
Corporation policy, where System Z plays an integral part.
2. Next we open the SystemZ policy and import all needed components. From
the ..\iView\Web\regulations\basel directory we import the Basel II grouping
file grouping.cfg as shown in Figure 11-47.
Figure 11-47 Import Basel II grouping
353
7530ch11.fm
3. Finally we import Basel II policy rules and attention rules from the template
policy.pcy located in the same Basel II regulation directory
..\iView\Web\regulations\basel as before and as shown in Figure 11-48.
Figure 11-48 Import Basel II rules
Note: The same file policy.pcy is used to import policy rules as well as
attention rules, but import is done separately for each of the two.
Once imported, Basel II policy and attention rules are displayed as shown in
Figure 11-49 and Figure 11-50 respectively.
Figure 11-49 Basel II Policy Rules
Attention: Figure 11-50 doesnt show all Basel II attention rules.
354
7530ch11.fm
Figure 11-50 Basel II Attention Rules
Now that the policy is in place, we have to customize it for Tivoli Financial
Accounting Corporations System Z environment. We do not modify any policy
and attention rules, as they are based on the Basel II regulation
recommendations, which were evaluated and translated into the W7 model.
In the next paragraph we customize W7 Groups for Tivoli Financial Accounting
Corporations System Z environment.
W7 groups
First we assign entities to the classification template groups. When the policy is
used, these grouping is merged and used together with the latest grouping from
the user information source.
Figure 11-51 shows an example of Tivoli Financial Accounting Corporations
assignment for the W7 category When and in part for category Where (Customer
Information systems group).
355
7530ch11.fm
Figure 11-51 W7 assignment example
If you already have a grouping in place, then it is recommended to rename the

existing groups to the group names used in the classification template. To do this
you need to know what the classification groups refer to. The best references are
the regulatory reports that make use of these groups.
After you run the report, you can use the Extra Information panel to obtain
information on:
What assets, processes or actions are monitored by the report (Background).
Filters used by the report (Filters)
Also the group's description in the classification template should provide
enough information to determine which entities should be referred by it. An
example was already shown in Figure 11-42 on page 349.
What the report was meant to be used for (Help).
For Tivoli Financial Accounting Corporation we already described a set of
identified Basel II reports in Reporting requirements on page 201.
356
7530ch11.fm
After we save our first policy, it is time to load the System Z audit data, see the
first resulting reports and make adjustments if necessary.
Reports
To load the System Z audit data into the FINANCE database, we first have to
disable the existing associated load schedule in the Tivoli Compliance Insight
Managers Management Console as shown in Figure 11-52.
Note: In a production environment we recommend using a specificly created
test GEM database, so we do not have to interrupt any scheduled load or
report on our FINANCE database.
Figure 11-52 Disable load schedule
Then we start loading the database, using our draft policy, as illustrated next.
1. First we select our FINANCE database and start the Load Database Wizard
as shown in Figure 11-53. Click Next to continue.
357
7530ch11.fm
Figure 11-53 Start Load Database Wizard
2. In the next step we confirm the preselected database as shown in

Figure 11-54. Click Next to continue.
Figure 11-54 Choose database
3. For the data we want to load, we have to specify the time frame as shown in
Figure 11-55. Click Next to continue.
358
7530ch11.fm
Figure 11-55 Choose time period
4. We also specify whether we want the latest data from the event sources in
addition to audit data already present in the Depot, or just the latest, as shown
in Figure 11-56. Click Next to continue.
Figure 11-56 Collect and/or load
359
7530ch11.fm
5. Finally, we choose our policy to use for this load, as shown in Figure 11-57.
Figure 11-57 Choose policy
6. We complete the Load Database Wizard as shown in Figure 11-58. Click

Finish.
Figure 11-58 Complete Load Database wizard
360
7530ch11.fm
We are now ready to request the System Z audit data to be loaded into the
FINANCE database.
After successful load, we open the dashboard, to have a first look at Tivoli
Financial Accounting Corporations System Z Basel II compliance status, as
Figure 11-59 Tivoli Financial Accounting Corporations System Z Basel II summary
At a first glance we see a grid dashboard, which clearly indicates that a majority
of exceptions are related to customer data on System Z.
We can also check the status of audit data and the FINANCE database itself, as
361
7530ch11.fm
Figure 11-60 FINANCE database status
We see that the database was loaded successfully with the automated policy
used together with our SystemZ work policy. We also see the amount of audit
data in the database together with the time frame for each of the Tivoli Financial
Accounting Corporations System Z LPAR.
We end the Reports section with some actual Basel II reports for Tivoli Financial
Accounting Corporations System Z, as requested and identified in Reporting
requirements on page 309. These reports are depicted from Figure 11-61
through Figure 11-69 on page 367.
362
7530ch11.fm
Figure 11-61 Operational change control (8.1.4)
363
7530ch11.fm
Figure 11-62 Operator log (8.4.2)
Figure 11-63 review of user access rights (9.2.4)
364
7530ch11.fm
Figure 11-64 System access and use (9.2.4c)
Figure 11-65 User responsibilities and password use (9.3)
365
7530ch11.fm
Figure 11-66 User identification and authentication (9.5.3)
Figure 11-67 Application access control (9.6)
366
7530ch11.fm
Figure 11-68 Control of operational software (10.4.1)
Figure 11-69 Data access (12.1.4)
367
7530ch11.fm
Commit
We are satisfied with the reports and want to put them into automatic mode. To
be more exact, we want to schedule System Z audit data load with Basel II
policy.
1. First we re-enable the load schedule for the FINANCE database as shown in
Figure 11-70.
Figure 11-70 Re-enable load schedule
2. Last but not least, we commit the Basel II policy, to be used for subsequent
scheduled loads, as shown in Figure 11-71.
Figure 11-71 Commit policy
This concludes our implementation and Basel II compliance management report

section. In the final section we summarize this chapter.
368
7530ch11.fm
11.4 Conclusion
Demonstrating a proper understanding of operational risk is a critical aspect of
the complying with the Basel II regulation. In todays business environment, IT
security is a critical component of operational risk management. IT security
manages a growing number of operational controls and is a repository for
evidence of operational incidents, so it becomes critical for IT security to support
risk management in its Basel II compliance efforts. This requires implementing a
series of mechanisms to monitor, measure, and control risks and incidents. This
close interaction between risk management and IT security will not only
accelerate regulatory compliance, but will also significantly improve the
effectiveness of operational risk management thorough the enterprise.
Tivoli Financial Accounting Corporation effectively defined and produced Basel II
compliance reports for its System Z environment, and showed that the controls
are in place, active and working.
The very last phase in the Tivoli Financial Accounting Corporation scenario is
discussed in the next chapter Tivoli Security Operations Manager integration on
page 371.
369
7530ch11.fm
370
7530ch12.fm
12
Chapter 12.
Tivoli Security Operations

Manager integration
In this chapter we describe several different integration options between Tivoli
Security Operations Manager and Tivoli Compliance Insight Manager in order to
capture the full benefits of IBMs SIEM solution that was introduced in Chapter 5,
IBM Security Information and Event Management on page 103.
371
7530ch12.fm
12.1 Reasons for integration

Tivoli Financial Accounting Corporation has achieved significant value from
implementing Tivoli Compliance Insight Manager to satisfy many of their internal
user oriented auditing requirements. They have also recently implemented Tivoli
Security Operations Manager in order to improve security operational efficiency
and have been able to demonstrate some significant improvements in their
compliance posture using the two products in isolation. Now they wish to
combine the two products in order to leverage the capabilities of a completely
integrated Security Information and Event Management solution. Some of the
benefits that they seek include:
Allowing Tivoli Compliance Insight Manager to leverage the integration that
Tivoli Security Operations Manager already has with the operational
environment, for example, its linkages to the network operations world. The
aim being to increase the overall level of service that the organization is able
to offer.
Allowing Tivoli Compliance Insight Manager to apply security policy to the
Tivoli Security Operations Manager environment.
Avoiding the duplication of event collectors but also allowing Tivoli
Compliance Insight Manager to apply security policy reporting to information
collected from the network security environment.
Allowing a single log management solution that leverages the capabilities of
Tivoli Compliance Insight Manager.
Allowing Tivoli Compliance Insight Manager audit compliance alerts to be
correlated with real time alerts by the Tivoli Security Operations Manager
environment in order to highlight hosts threatened due to policy non
compliance as well as to leverage the more sophisticated rules environment
provided by Tivoli Security Operations Manager.
12.2 Integrating Tivoli Security Operations Manager to

In this first integration we will be configuring the combined Tivoli Security
Operations Manager and Tivoli Compliance Insight Manager solution so that
Tivoli Security Operations Manager generated events can be captured and
reported within the Tivoli Compliance Insight Manager environment. There are
several ways in which Tivoli Security Operations Manager and Tivoli Compliance
Insight Manager can be integrated depending on an organizations requirements.
Each of these mechanisms may on first glance appear to be complex. In reality
372
7530ch12.fm
they are generally very simple scripts that use some of the basic integration
features that have been built in to the two main components of the SIEM solution.
The integrations can also be extended or modified to meet whatever customer
requirements are provided, for example, rather than locking you into a single way
of doing this that does not meet every organizations requirements.
In 12.2.1, General integration approach below we begin the integration
scenarios by showing how to have Tivoli Security Operations Manager audit
events made available to Tivoli Compliance Insight Manager for policy
evaluation. Later in this section we describe how this same approach can be
used to have other policy breach events detected by Tivoli Security Operations
Manager and made available to Tivoli Compliance Insight Manager for complete
compliance dashboard coverage.
12.2.1 General integration approach

The goal of this integration is to include auditable events from Tivoli Security
Operations Manager into the Tivoli Compliance Insight Manager compliance
reports.
The integration works in four steps:
1. Identify auditable events in Tivoli Security Operations Manager using Rules.
2. The Rule triggers a Tivoli Security Operations Manager Action, which is used
to write an event record to a log file in a W7 standardized format.
3. Tivoli Compliance Insight Manager periodically collects the log file, and stores
it in its log management Depot.
4. Tivoli Compliance Insight Manager analyzes the events and includes the
events in its compliance reports.
Tivoli Security Operations Manager allows you to create Rules to capture
specific situations, based on the occurrence of one or several events. This
enables you to identify situations such as network attacks from certain patterns,
or to call out policy violations such as unauthorized protocols being used.
Once a Rule has identified a situation, it can trigger Actions that can be used to
create an alert, or something as active as enforcing policy by reconfiguring
devices.
In this integration we use Rules to describe compliance relevant events, and
Actions to make these events available to Tivoli Compliance Insight Manager.
Tivoli Compliance Insight Manager includes a W7Log SDK that end-users and
service providers can use to create their own target platform support for Tivoli
Chapter 12. Tivoli Security Operations Manager integration
373
7530ch12.fm
Compliance Insight Manager. The W7Log SDK extends the Tivoli Compliance
Insight Manager product with support for collecting and processing using
generalized input formats. This event format provides complete coverage for the
same W7 dimensions that are used in the normalization process for the natively
supported event sources in Tivoli Compliance Insight Manager. We use the CSV
generic event format available in the W7Log SDK to create the Tivoli Security
Operations Manager audit trail directly in the W7 grammar. This provides
immediate coverage of Tivoli Security Operations Manager through Tivoli
Compliance Insight Manager's comprehensive set of audit and compliance
reports. This concept is illustrated in Figure 12-1 on page 374. More details on
the W7Log SDK is provided in 3.4, The W7LogSDK on page 59.
We augment Tivoli Security Operations Manager with an audit trail capability in a
standardized format.
InSight
Depot
Target
Application
Native
W7Log
Actuator
InSight
reports
Figure 12-1 Tivoli Security Operations Manager integration via W7Log SDK
12.2.2 Applying the Tivoli Compliance Insight Manager event

taxonomy
In order to perform this integration it is important to use a common event
taxonomy using the General Event Model. In our case we will use some
standardized values for each of the W7 dimensions that are relevant to the IBM
SIEM solution.
The types of audit events that Tivoli Security Operations Manager can produce
can be examined by viewing the Audit Option of the Tivoli Security Operations
Manager Admin tab (see Figure 12-2 on page 375).
374
7530ch12.fm
Figure 12-2 Tivoli Security Operations Manager self auditing options
Initially we are choosing to only forward Tivoli Security Operations Manager

Successful Login audit events. For this type of event we use the following
values for each of the W7 parameters.
Who will be the user id value provided by Tivoli Security Operations Manager
userid field.
What will be either Logon, User, Success.
When will be automatically populated in the correct format by the integration
script and will be the local time on the Tivoli Security Operations Manager
server.
Where will be automatically populated with the string Tivoli Security
Operations Manager and the hostname of the Tivoli Security Operations
Manager server for example TSOM, demosys in our case (our hostname is
demosys).
375
7530ch12.fm
On What will be populated with the values TSOM AUDIT RULE,-,$rule

where $rule will be populated by Tivoli Security Operations Manager with the
name of the audit rule that was triggered.
Where From will be populated with the values TSOM System,9.3.5.160
where the IP address is the IP address of the Tivoli Security Operations
Manager server.
Where To will be automatically populated with the default values from our
script -,- which indicates that the values are unspecified in the original event.
Finally the info field that is available for use within Tivoli Compliance Insight
Manager will be populated with the contents of the Tivoli Security Operations
Manager info field (typically this field contains the original event string).
12.2.3 Prerequisites
This integration uses Tivoli Compliance Insight Manager 8.0 on Windows 2003,
and Tivoli Security Operations Manager 3.1 on Linux RedHat Enterprise Server.
One additional tool is required on the Tivoli Compliance Insight Manager 8.0
server, which is the PuTTY toolset. Specifically, the tools puttygen.exe, plink.exe
and pscp.exe are used in this prototype. This toolset can be found on the Tivoli
Compliance Insight Manager 8.0 distribution media, disk 2. Alternatively, these
tools can be downloaded from the following Website
(http://www.chiark.greenend.org.uk/~sgtatham/putty/).
12.2.4 The Tivoli Compliance Insight Manager Audit Logger script

The Tivoli Compliance Insight Manager Audit Logger is a simple script that is
triggered from a Tivoli Security Operations Manager Action. Its purpose is to add
event details from the rule that triggers it to an audit trail that Tivoli Compliance
Insight Manager can read. The script writes events in the native Tivoli
Compliance Insight Manager W7Log grammar.
Attention: This script is a minimalist example of how an integration can be
performed using some of the basic features of both products. For production
installs, it may be desirable to write more sophisticated scripts with additional
functionality and exception handling.
The script accepts eight named parameters on the command line: seven
parameters that define each of the dimensions in the W7 model, and one
additional informational value. Each parameter is a string with a prescribed,
mandatory format. The parameters themselves are optional: when omitted, the
script uses default values for these parameters.
376
7530ch12.fm
Usage of the Tivoli Compliance Insight Manager Audit Logger script:

tcimlogger [--option='<string>']
Optional parameters are described in Table 12-1.
Table 12-1 Optional parameters to the tcimlogger script
Option
Description
--when='<utime>'
Parameter is expected to be an integer value with

Unix time stamp. Defaults to $now.
--who='<realname,logonname>'
<realname> is the full name of the user,

<logonname> the account name. Defaults to '-,-'.
--what='<verb,noun,success>'
The typical three values to define the action of an

event. See appendices for more examples.
Defaults to '-,-,-'.
--where='<type,name>'
<type> is the platform type of the device that

generated this event, <name> is the platform
name. Defaults to 'TSOM,<TSOM hostname>'.
--wherefrom='<type,name>'
<type> and <name> of the device from which the

event originates. Defaults to '-,-'.
--whereto='<type,name>'
<type> and <name> of the device to which the

event is directed. Defaults to '-,-'.
--onwhat='<type,path,name>'
The typical three values to define the object of an

event. Can be used to denote the Tivoli Security
Operations Manager rule that defines the auditable
event, for example with 'RULE,-,$rule'. Defaults to
'-,-,-'.
--info='<description>'
Description of the event, additional information.

Defaults to '-'.
Let us look an example use of the tcimlogger script when called from an Action in
Tivoli Security Operations Manager:
tcimlogger --what='Detect,WORM,Warning' \
--wherefrom='-,$srcip' \
--whereto='-,$dstip' \
--onwhat='RULE,-,$rule'
In this example, the default values are used for the unspecified parameters
When, Who, Where and Info.
377
7530ch12.fm
The source code of the sample tcimlogger script is provided in Example 12-1 on
page 378.
Example 12-1 tcimlogger script source code
#!/usr/bin/perl -w
#
# Sample TCIM audit logger for TSOM
# Version: 0.1, 2007-06-26
use strict;
use Fcntl ':flock';
use Getopt::Long;
open LOG, ">>/var/log/tcim/audit.log";
flock LOG, LOCK_EX;
seek LOG, 0, 2;
# print header if new file
print LOG format_header() if tell(LOG) == 0;
my ($when,$what,$who,$where,$onwhat,$wherefrom,
$whereto,$info);
GetOptions( "when=s"
"what=s"
"who=s"
"where=s"
"onwhat=s"
"wherefrom=s"
"whereto=s"
"info=s"
=>
=>
=>
=>
=>
=>
=>
=>
\$when,
\$what,
\$who,
\$where,
\$onwhat,
\$wherefrom,
\$whereto,
\$info );
# set default values if parameter empty

$when ||= scalar time;
$what ||= "-,-,-";
$who ||= "-,-";
$where ||= "TSOM," . `/bin/hostname`;
chomp($where);
$onwhat ||= "-,-,-";
$wherefrom ||= "-,-";
$whereto ||= "-,-";
$info ||= "-";
378
7530ch12.fm
print LOG print_date($when) .

",$who,$what,$where,$wherefrom,$whereto,$onwhat,\"$info\"\n";
close LOG;
# returns a formatted header string:
sub format_header {
return "when,whorealname,whologonname,whatverb," .
"whatnoun,whatsuccess,wheretype,wherename," .
"wherefromtype,wherefromname,wheretotype," .
"wheretoname,onwhattype,onwhatpath,onwhatname," .
"info\n";
}
# returns a formatted date/time string in UTC/GMT time zone
sub print_date {
my @dt = gmtime(shift);
return sprintf '%.4d-%.2d-%.2dT%.2d:%.2d:%.2d-%.2d:%.2d',
$dt[5]+1900,$dt[4]+1,$dt[3],$dt[2],
$dt[1],$dt[0],0,0;
}
12.2.5 Installation
Let us now take a closer look at the different installation steps.
Install the Log Script on the Tivoli Security Operations

Manager server
Log on as root on the Tivoli Security Operations Manager server to perform the
following actions.
First, install the tcimlogger script to its preferred location. This assumes that you
have already copied the script to the Tivoli Security Operations Manager server.
Example 12-2 Commands to run at the Tivoli Security Operations Manager server
mkdir -p /var/log/tcim
chown -R root.ns /var/log/tcim
chmod -R 764 /var/log/tcim
cp tcimlogger /usr/local/bin
chmod 754 /usr/local/bin/tcimlogger
379
7530ch12.fm
Install the Collect Scripts on the Tivoli Security Operations

Manager server
Now you have to create pre-collect and post-collect scripts. First, create an
executable file /usr/local/bin/tcim-precollect as follows. This script is responsible
for moving the audit trail information created by the tcimlogger script into a
location where it can be collected by Tivoli Compliance Insight Manager.
Example 12-3 Tivoli Compliance Insight Manager pre-collect script
#!/bin/sh
PATH=/bin
cd /var/log/tcim
if [ -f audit.log ]; then
mv audit.log audit-`date +%s.%N`.log
fi
Next, you need another executable file /usr/local/bin/tcim-postcollect as below,
which is responsible for removing the Tivoli Security Operations Manager audit
log information after Tivoli Compliance Insight Manager has reliably collected it.
Example 12-4 Tivoli Compliance Insight Manager post-collect script
#!/bin/sh
PATH=/bin
cd /var/log/tcim
rm -f audit-*.log
Both files need to have the correct ownership and permissions that allow read
and execution by the service users used by both Tivoli Security Operations
Manager and Tivoli Compliance Insight Manager (a typical user to use for this
purpose would be the ns user on the Tivoli Security Operations Manager
Central Management Server, for example, you could run chown root.ns tcim-*
and chmod 754 to get right permissions).
The collect from the Tivoli Compliance Insight Manager server is performed
using SSH. The instructions below detail how to create a public/private key pair
for the ns user on the Tivoli Security Operations Manager server.
1. Run the following commands:
# cd ~ns
# mkdir .ssh
# ssh-keygen -b 1024 -t rsa
This generates the public/private rsa key pair.
a. Enter file in which to save the key (/root/.ssh/id_rsa): .ssh/id_rsa
380
7530ch12.fm
b. Enter a passphrase (empty for no passphrase).

c. Enter the same passphrase again.
d. Your identification has now been saved in .ssh/id_rsa.
e. Your public key has also been saved in .ssh/id_rsa.pub.
The key fingerprint is something like:
8f:33:fe:b3:27:4d:1b:85:73:ce:75:27:0b:1b:cb:4f root@TSOM-DEMO
2. Now move your newly created public key into the authorized keys directory so
that it can be used during SSH session initiation between the Tivoli
Compliance Insight Manager and Tivoli Security Operations Manager servers
during the Tivoli Compliance Insight Manager collection process.
# mv .ssh/id_rsa.pub .ssh/authorized_keys
# chown -R ns.ns .ssh
3. Next, copy the id_rsa file to the Tivoli Compliance Insight Manager server,
and convert it to the PuTTY key format.
4. Use the puttygen.exe tool to convert this private key file to PuTTY format, and
save as id_rsa.ppk. Start the puttygen.exe tool, open the id_rsa file, and save
it as a private key in the .ppk format.
Install the Collect Script on the Tivoli Compliance Insight

Manager server
After the previous step, the conversion of the ns user's private key file to PuTTY
format, you need to execute an initial manual SSH connection as outlined below
from the Tivoli Compliance Insight Manager server to Tivoli Security Operations
Manager, to ensure that the Tivoli Security Operations Manager SSH server
keys are identified and stored by PuTTY in the Windows Registry of the Tivoli
Compliance Insight Manager server. Skipping this step can prevent the
automated collect from working. This step needs only be done once.
First create a staging directory for the Tivoli Security Operations Manager event
source in Tivoli Compliance Insight Manager, and a temporary directory that is
used during the file transfer of the audit files. This example assumes that a D:\
drive can be used on the Tivoli Compliance Insight Manager server, please
replace with your preferred location of the staging directory.
mkdir D:\IBM\TSOM
mkdir D:\IBM\TSOM\Staging
mkdir D:\IBM\TSOM\temp
Then copy the ns user's private PuTTY key to the D:\IBM\TSOM directory. Now
make the initial connection to the Tivoli Security Operations Manager server to
test the connection, and to store the Tivoli Security Operations Manager server's
SSH keys:
381
7530ch12.fm
e:
cd \IBM\TSOM
plink -i id_rsa.ppk ns@192.168.111.111
Simply accept the Tivoli Security Operations Manager server keys, and after the
connection is established, type exit in the Tivoli Security Operations Manager
shell to log out.
Next, create the following collect script on the Tivoli Compliance Insight Manager
server in the D:\IBM\TSOM directory:
Make sure you have the PuTTY tools plink.exe and pscp.exe in your
Windows search path, or fully qualify the file names with the directory they
can be found in.
Replace the IP address in the script with the IP address or DNS host name of
the Tivoli Security Operations Manager server.
Also modify the directory and drive of where you want Tivoli Compliance
Insight Manager to be able to find the audit files, which is the directory
structure created in the previous step.
Example 12-5 depicts the file tcim-collect.cmd.
Example 12-5 tcim-collect.cmd
@echo off
set tsom=192.168.111.111
e:
cd \ibm\tsom
plink -i id_rsa.ppk ns@%tsom% /usr/local/bin/tcim-precollect
pscp -i id_rsa.ppk ns@%tsom%:/var/log/tcim/audit-*.log .\temp
plink -i id_rsa.ppk ns@%tsom% /usr/local/bin/tcim-postcollect
move .\temp\*.* .\Staging
This script takes care of rolling-over the current audit log file on the Tivoli
Security Operations Manager server, then copies any available rolled-over file to
the Tivoli Compliance Insight Manager server into a temporary directory using
scp. Then the post-collect script is called to dispose of the old logs on the Tivoli
Security Operations Manager server, and finally the files are copied from the
temporary directory to the event source staging directory.
382
7530ch12.fm
The script should now be scheduled to run regularly through the Windows
Scheduler. For a proof of concept, a recommended interval would be five
minutes.
It is fairly easy to test this process with the following steps:
1. Create a file /var/log/tcim/audit.log on the Tivoli Security Operations Manager
server that is owned by the ns user.
2. Manually kick-off the tcim-collect.cmd script.
3. The log directory on the Tivoli Security Operations Manager server should
now be empty, and a new file can be found in the Staging directory on the
Tivoli Compliance Insight Manager server.
Create a Tivoli Security Operations Manager event source in

The following steps show how to add a Tivoli Security Operations Manager event
source to Tivoli Compliance Insight Manager.
1. First, create a new GEM database that is used to report on the Tivoli Security
Operations Manager events. Any available GEM database can be used, but
for the purposes of this document, we create a new one.
From the Management Console, select to add a new database. Fill out the
resulting dialog box as appropriate. Figure 12-3 shows a 1 MB database to be
created initially, it auto-expands as necessary.
Figure 12-3 Create a GEM database for Tivoli Security Operations Manager audit events
2. Now we add a new event source through the Add Event Source Wizard (see
Figure 12-4). Click Next to continue.
383
7530ch12.fm
Figure 12-4 The Add Event Source Wizard
3. Select the host on which the tcim-collect script and staging directory exist (in
Figure 12-5 we only have one machine set up). Click Next to continue.
Figure 12-5 Select the point of presence responsible for collecting Tivoli Security
Operations Manager events
384
7530ch12.fm
4. Find the Tivoli Security Operations Manager event source in the list (see
Figure 12-6). Click Next to continue.
Figure 12-6 Select the Tivoli Security Operations Manager event source
5. Make sure to enter the correct Staging directory that was set up in the
previous step (see Figure 12-7). Click Next to continue.
Figure 12-7 Enter the correct staging directory details
385
7530ch12.fm
6. Now choose a collect frequency (see Figure 12-8). You may also choose to
select Never, and collect on-demand during a manual load of the GEM DB.
This schedule may be changed later to match more precisely your collection
requirements (we have found that collecting daily with a seven day sliding
load window most meets our requirements). When the collect is performed it
moves the data from the staging directory into a sub directory of the Depot
directory and preserves the information in the standard chunk format used by
Tivoli Compliance Insight Manager.
Figure 12-8 Choose a collect frequency
7. The wizard requires you to select a GEM database in which to load the data
from this event source. Select the one we just created, or another database
that you wish to use (see Figure 12-9 on page 387). Click Next to continue.
386
7530ch12.fm
Figure 12-9 Select the GEM database
8. Now select a load frequency (Figure 12-10). In production environments, a

load schedule would be triggered once a day, but for the purposes of this
document, we use a Manual Load process. Therefore the frequency below is
set to Never. Click Next to continue.
Figure 12-10 Select a load frequency
387
7530ch12.fm
9. This completes the wizard (see Figure 12-11). Click Finish.
Figure 12-11 Wizard complete
With the infrastructure elements in place, we are now ready for an example
where we can generate some audit information from Tivoli Security Operations
Manager.
Next we show you how Tivoli Security Operations Manager detects a user
logging in to the Tivoli Security Operations Manager Web interface, and forwards
this event to Tivoli Compliance Insight Manager. It is admittedly a simple
example, but it is easy to set up and demonstrate most of the integration features
to meet the requirements of a full SIEM. In later sections we show other
integrations that extend this basic example.
Tivoli Security Operations Manager is self auditing and captures audit
information within its event repository for many different types of actions ranging
from user logins, user logouts, failed logins, modification of rules, modification of
configuration options, to rules being triggered. As a simple example when a user
logs in to Tivoli Security Operations Manager it shows an event as depicted in
Figure 12-12 in its event console.
388
7530ch12.fm
Figure 12-12 A successful Tivoli Security Operations Manager login event
Notice the event of type CMS_LOGIN_SUCCESS, this is a native Tivoli

Security Operations Manager event (typically Tivoli Security Operations Manager
audit events have a type prefixed with CMS).
Whenever an event like this occurs, we want to have this logged in our Tivoli
Security Operations Manager audit trail and show up in Tivoli Compliance Insight
Managers compliance reports. For this to happen, we need to define two things:
1. A Tivoli Security Operations Manager rule that identifies this event, and which
can take action to log its information.
2. The Action that actually writes the information to a log file.
In Tivoli Security Operations Manager, we need to start by defining the Action.
From the CMS screen (Tivoli Security Operations Manager Web interface),
select the Tools menu option, and go to the Actions panel. Now create a new
Action as follows (see Figure 12-13).
389
7530ch12.fm
Figure 12-13 Defining the audit action
The title of the Action is Audit-TCIM: Login User.

The Action Type is Shell, this allows us to specify a shell script to be executed
when this Action is invoked.
Finally, type the following Shell Command in the edit box (shown here below
in Example 12-6) with continuation characters for readability, which may be
omitted in the Action box: just type one single command line):
Example 12-6 Basic action definition for login audit event
/usr/local/bin/tcimlogger --what="Logon,User,Success" \
--who="$username[1],$username[1]" \
--wherefrom="TSOM System,9.3.5.160" \
--onwhat="TSOM AUDIT RULE,-,$rule" \
--info="$info"
In Example 12-6 we have defined that the action creates a new audit entry for
Tivoli Compliance Insight Manager with the following plain english meaning.
A successful user logon was performed by $username[1] (this value is replaced
by Tivoli Security Operations Manager with the actual userid), the audit event is
from the TSOM System with the IP address 9.3.5.160. This was generated by
a TSOM AUDIT RULE and the rule name was $rule (this is replaced by Tivoli
Security Operations Manager with the actual rule name. Additional information
that is provided to Tivoli Compliance Insight Manager by Tivoli Security
390
7530ch12.fm
Operations Manager is the full contents of the Tivoli Security Operations

Manager information field (signified by the $info variable above - typically this
field contains the contents of the original event that was collected by Tivoli
Security Operations Manager).
Next, from the same Tools menu, select the Rules panel and define a new Rule
as shown below in Figure 12-14.
The title of the Rule is Audit: Login User.
Select the Audit-TCIM: Login User from the available actions.
Finally, make sure this rule is triggered by any single event that has
CMS_LOGIN_SUCCESS as its event type.
391
7530ch12.fm
Figure 12-14 The Tivoli Security Operations Manager audit rule definition
392
7530ch12.fm
You should now open a new Web browser window and log on to CMS again to
trigger this action. To verify that the action has logged the event, have a look at
the audit log on the Tivoli Security Operations Manager server (ls -l
/var/log/tcim/audit.log gives you a last modified date for the file which should
indicate that it was modified recently). The contents should contain a W7LogSDK
format representation of the Tivoli Security Operations Manager login event
similar to the example below (Example 12-7).
Example 12-7 Tivoli Security Operations Manager audit log event
[root@TSOM-DEMO root]# cat /var/log/tcim/audit.log

when,whorealname,whologonname,whatverb,whatnoun,whatsuccess,wheretype,w
herename,wherefromtype,wherefromname,wheretotype,wheretoname,onwhattype
,onwhatpath,onwhatname,info
2007-07-03T17:51:40-00:00,admin,admin,Logon,User,Success,TSOM,TSOM-DEMO
,-,9.3.5.160,-,-,RULE,-,Audit: Login User,"successful login to user
account 'admin' (id 1)"
Now either wait until the Tivoli Compliance Insight Manager scheduled collect job
has fired, or manually kick off the tcim-collect.cmd script on the Tivoli
Compliance Insight Manager server. You can verify that the file has correctly
collected the information by browsing the contents of the Staging directory (see
Figure 12-15):
Figure 12-15 View the contents of the Staging directory
393
7530ch12.fm
From the Tivoli Compliance Insight Manager Management Console, right-click

on the Tivoli Security Operations Manager GEM database and initiate a load as
follows:
1. Select the GEM database to load (Figure 12-16). Click Next to continue.
Figure 12-16 Select the GEM database
2. Choose the load period as in Figure 12-17. Click Next to continue.
Figure 12-17 Choose the load period
394
7530ch12.fm
3. If you have configured the Tivoli Security Operations Manager event source
in Tivoli Compliance Insight Manager without a regular collect schedule, or if
you want to collect the Tivoli Security Operations Manager data from the
Staging directory immediately, select the Collect option in the next screen as
shown below (Figure 12-18). Click Next to continue.
Figure 12-18 Choose to collect the data
4. Choose a policy to apply to the data on load (see Figure 12-19). Click Next to
continue.
395
7530ch12.fm
Figure 12-19 Choose the policy to apply
5. And select Finish (see Figure 12-20).
Figure 12-20 Wizard finished
The GEM database is now loading, and when the load operation has completed,
the Management Console shows a green GEM database icon (see
Figure 12-21).
396
7530ch12.fm
Figure 12-21 The Tivoli Security Operations Manager GEM database load has completed
The event can be inspected in the Tivoli Compliance Insight Manager

Web-based report interface of iView, in which an All Event report for the Tivoli
Security Operations Manager GEM database looks as follows (see
Figure 12-22).
397
7530ch12.fm
Figure 12-22 Tivoli Security Operations Manager audit events displayed in the iView portal
A drill-down into the event details of this event shows the following event
properties (see Figure 12-23).
398
7530ch12.fm
Figure 12-23 The Tivoli Security Operations Manager audit event in Tivoli Compliance Insight Manager
Notice how the original additional event information in Tivoli Security

Operations Manager has been preserved in the info field in Tivoli Compliance
Insight Manager.
Conclusion
In this section we have outlined a basic approach to make Tivoli Security
Operations Manager events available to Tivoli Compliance Insight Manager. In
the next section we provide several more examples.
399
7530ch12.fm
12.3 Additional Tivoli Security Operations Manager

incidents
In this section we extend the integration performed in section 12.2, Integrating
Tivoli Security Operations Manager to Tivoli Compliance Insight Manager where
we concentrated on capturing Tivoli Security Operations Manager audit
information to include Tivoli Security Operations Manager detected policy
violations, attacks and compliance breaches.
12.3.1 Approach
These integrations are very simple extensions of the integration performed
previously. We are again using the tcimlogger script but in this case what we
need to do further is to identify which events are of use to monitor our audit
policies in Tivoli Compliance Insight Manager and then categorize them
according to the Tivoli Compliance Insight Manager W7 event taxonomy.
Tivoli Security Operations Manager provides and categorizes many different
types of event via its various correlation mechanisms. Typically as a result of
detecting some type of policy breach or attack Tivoli Security Operations
Manager creates a meta event which represents the attack or policy breach. A
meta event could represent many 100s or even 1000s of individual original
events and can be used to indicate any type of incident that an organization
desires. When Tivoli Security Operations Manager is installed it comes with
many existing rules and a default event classification/taxonomy. These rules and
the event taxonomy can be extended to represent anything that is needed by an
organization. Then once an event has been categorized correctly or a meta
event has been created it makes it very easy to then trigger an audit logging
action using our previously described approach. Typically the highest level of
event, for example, events that represent key incidents or policy breaches is of
the most interest from an audit perspective and therefor of most interest to Tivoli
Compliance Insight Manager.
Some of the rule categories used be Tivoli Security Operations Manager which
will generate these types of events include:
Attack Detection Rules - this category of rules correlate the incoming events
against each other to detect and highlight attacks. The category includes
simple cases such as unusually high volumes of events targeting a specific
host, attacks that have successfully traversed the firewalls, automated scan
attempts and attempts to administer network/network security devices from
external locations. Some of the rules also re categorize or group events into
an event class that more closely mirrors the actual action. For example
events generated that target specific well known database ports (generated
400
7530ch12.fm
from say a firewall) will be categorized as app.db to indicate that the events
are database related events. Some of these types of rules will generate
events that may be of interest to Tivoli Compliance Insight Manager.
Policy Breach Detection Rules - Include rules such as identifying that there
are services available at the perimeter that are considered dangerous,
general misuse such as accessing porn sites or gambling sites or use of chat
protocols. Use of un-encrypted protocols for login information. Successful
logins in close proximity to 3 unsuccessful logins (for example, if our policy is
to lock accounts after 3 unsuccessful login attempts). Policy rules tend to
build on general attack rules and other categorization rules. This type of rule
will generate events that may be of interest to Tivoli Compliance Insight
Manager.
Compliance Rules - these rules examine incoming high threat events and
previously identified incidents (see the previous two bullet points) to
determine if those events are related to our compliance resources. For
example if a policy breach such as unsecured protocols used to administer a
system is detected and the target of that administration attempt is a resource
relevant to our financial reporting obligations (for example, an important
resource from a Sarbanes-Oxley compliance perspective - this concept is
captured using Tivoli Security Operations Managers watchlist capability) then
a new meta event is created that represents a Sarbox compliance issue (the
exact meta event created is of class compliance.sarbox). This type of event
would then be of a great deal of value to Tivoli Compliance Insight Manager.
12.3.2 Worm detection events to Tivoli Compliance Insight Manager

One of the attack detection rules that Tivoli Security Operations Manager
implements will detect and categorize worms within our environment (more
accurately, this rule is based on the results of several other rules). When this rule
triggers it creates an event of event class attack.worm. So all we need to do to
have this incident recognized in Tivoli Compliance Insight Manager is to create a
rule that looks for attack.worm and then triggers an audit logging action using
our previously defined tcimlogger script.
We create a Tivoli Security Operations Manager rule labeled Audit: Detect
Worm to identify worm activity on the network. Then create an action
Audit-TCIM: Detect Worm and pass the following W7 values to the tcimlogger
script (see Example 12-8 on page 402):
Who - In this case we do not have a who value so this defaults to -,-, for
example, be unspecified.
What will be Detect, Worm, Warning.
401
7530ch12.fm
When will be automatically populated in the correct format by the integration

script and will be the local time on the Tivoli Security Operations Manager
server.
Where will be automatically populated with the values TSOM, demosys.
On What will be populated with the values RULE,-,$rule where $rule will be
populated by Tivoli Security Operations Manager with the name of the audit
rule that was triggered. This indicates that the event was identified by a Tivoli
Security Operations Manager rule and which rule it was.
Where From will be populated with the values -,$srcip[1] where $srcip[1] is
the IP address of the system that is identified by Tivoli Security Operations
Manager as the source of the worm propagation attempt.
Where To will be populated with the values -,$dstip[1] where $dstip[1] is the
IP address of the system that is identified by Tivoli Security Operations
Manager as the target of the worm propagation attempt.
Finally the info field that is available for use within Tivoli Compliance Insight
Manager will be populated with the contents of the Tivoli Security Operations
Manager info field (typically this field contains the original event string).
Example 12-8 Worm Tivoli Compliance Insight Manager logging parameters
/usr/local/bin/tcimlogger --what="Detect,Worm,Warning" \
--wherefrom="-,$srcip[1]" \
--whereto="-,$dstip[1]" \
--onwhat="RULE,-,$rule" \
--info="$info"
Once you have completed adding this action to Tivoli Security Operations
Manager the action definition looks like this (see Figure 12-24 on page 403):
402
7530ch12.fm
Figure 12-24 The Action Definition for our Worm Detection Audit action
Next, we create a rule that triggers when an event of attack.worm is detected

(see Figure 12-25 on page 404). As you can see this is a very simple rule as all
the heavy lifting has been done by the rules that created the original attack.worm
meta event.
403
7530ch12.fm
Figure 12-25 Rule definition for Worm detection audit events
The contents of the generated audit log then looks something like Figure 12-26
on page 405.
404
7530ch12.fm
Figure 12-26 Worm detected audit entries in W7 SDK format
The next time our Tivoli Security Operations Manager GEM database is loaded
these new worm detected audit events will appear in the Tivoli Compliance
Insight Manager portal as depicted in Figure 12-27 on page 405.
Figure 12-27 Worm audit events displayed in Tivoli Compliance Insight Manager
405
7530ch12.fm
12.3.3 Policy violations

Tivoli Security Operations Manager can be used to detect many policy violations
and will typically map a policy violation detected to the policy.violation event
class. Again, if we now want to have this event in Tivoli Compliance Insight
Manager we use the integration that we have already used in the previous cases.
This is a particularly interesting type of event, as generally policy violations
detected by Tivoli Security Operations Manager will not have user information
associated with them, rather they have the source and destination IP addresses.
The reason for this is that Tivoli Security Operations Manager is using the
information that it has available to it which is generally coming from network
specific sources such as firewalls or routers, which may not be able to provide
Tivoli Security Operations Manager with a user context.
By having this information available to us in Tivoli Compliance Insight Manager it
is now possible to connect these network policy violation detections with the user
who originated the policy violation.
For this case our action definition uses the following values (see Example 12-9)
and we name our defined action Audit: Policy violation:
Example 12-9 Policy Violation Action Script
/usr/local/bin/tcimlogger --what="Detect,Policyviolation,Warning" \
--wherefrom="-,$srcip[1]" \
--whereto="-,$dstip[1]" \
--onwhat="RULE,-,$rule" \
--info="$type"
Note: In this case we have used the $type field from the Tivoli Security
Operations Manager event. This is typically more interesting for policy
violation events than the Tivoli Security Operations Manager $info field. The
type field indicates what type of policy violation has been detected by Tivoli
Security Operations Manager. For example it may contain values such as
unauthorized Web browsing or unauthorized chat client.
Our Tivoli Security Operations Manager rule definition is depicted in Figure 12-28
on page 408. Note that the important part is the rule event signature where we
are only triggering the rule on detection of an event of class policy.violation.
Again this is very easily implemented as all of the heavy lifting required to identify
the policy violation has been performed in other Tivoli Security Operations
Manager rules. From this and the previous examples you can realize to see how
simple the integration between Tivoli Security Operations Manager and Tivoli
Compliance Insight Manager is.
406
7530ch12.fm
Later in 12.7, Laying down standard policy on Tivoli Security Operations

Manager data on page 438 you see the full power of combining these two
solutions when we start to apply policy to the data collected by both Tivoli
Security Operations Manager and Tivoli Compliance Insight Manager.
407
7530ch12.fm
Figure 12-28 The Policy Violation detection rule definition
408
7530ch12.fm
When this rule has run and the information has been collected by Tivoli
Compliance Insight Manager the resulting events appear in the Tivoli
Compliance Insight Manager event views as illustrated in Figure 12-29.
Figure 12-29 Tivoli Security Operations Manager policy violation events viewed in Tivoli Security
Operations Manager
12.3.4 Conclusion
In this section we have extended our original Tivoli Security Operations Manager
to Tivoli Compliance Insight Manager event integration to integrate additional
event types. In the next section we introduce a mechanism for using Tivoli
Compliance Insight Manager to manage syslog data collected by Tivoli Security
Operations Manager.
409
7530ch12.fm
12.4 Use Tivoli Compliance Insight Manager for log

management of Tivoli Security Operations Manager
collected syslog data
Many of the real time events that Tivoli Security Operations Manager collects are
collected using the syslog protocol. Typically these same logs are required to be
managed from an audit perspective (in fact around 50% of network and network
security devices support syslog). In a combined solution we can leverage the log
management capabilities provided by Tivoli Compliance Insight Manager. In a
Tivoli Security Operations Manager architecture the Event Aggregation Module
acts as a high speed syslog consolidator. Typically the native syslog daemon on
an Event Aggregation Module is replaced with the syslog-ng syslog daemon. In
this integration we configure Tivoli Compliance Insight Manager to collect and
manage the syslog on the Event Aggregation Module. Conceptually this means
that Tivoli Security Operations Manager no longer has to be concerned about
long term log management for its syslog conduit.
This integration pre-supposes that Tivoli Security Operations Manager and Tivoli
Compliance Insight Manager are already installed. It also requires that a Tivoli
Security Operations Manager Event Aggregation Module (EAM) is installed on
RedHat Enterprise Linux 3 (RHEL) (these same steps could be used on a non
RHEL system) and that the basic syslog daemon installed when you install RHEL
has been replaced with the more capable and better performing syslog-ng
daemon (the process for replacing the stock syslog daemon with the syslog-ng
daemon has been described in the IBM Redbook deliverable Deployment Guide
Series: IBM Tivoli Security Operations Manager 4.1, SG24-7439-00.
Note: The syslog-ng component is used by many organizations as a high
speed syslog replacement. Syslog-ng is available as both an open source
edition and a premium edition from the site:
http://www.balabit.com/network-security/syslog-ng
12.4.2 Basic approach

To perform this integration the following high level steps need to be performed.
Later in this section we provide a step by step set of instructions for this process.
1. Step 1: Backup important syslog-ng configuration files.
410
7530ch12.fm
2. Step 2: Modify the /etc/syslog-ng/syslog-ng.conf file to include the Tivoli

Compliance Insight Manager required configurations.
3. Step 3: Create a user on the EAM system and then configure the EAM for
remote SSH collection of logs by Tivoli Compliance Insight Manager.
4. Step 4: Add the Snort event source to Tivoli Compliance Insight Manager.
12.4.3 Our EAM syslog-ng configuration

On our EAM we are already using the syslog-ng package to provide high speed
syslogging capability and additional syslogging flexibility. The key file that we
need to back up is the syslog-ng.conf file which is located in
/etc/syslog-ng/syslog-ng.conf. Example 12-10 on page 411 illustrates the basic
contents of our EAMs syslog-ng.conf file prior to making modifications for the
Tivoli Compliance Insight Manager integration (please note, this is an example
configuration file only and those of you reading this who are expert at syslog-ng
configuration probably have much more complex/capable configuration files).
The example provides embedded comments to indicate the purpose of the
various important syslog-ng configuration options (for those working extensively
with syslog-ng it is recommended to read the documentation on the site from
which the syslog-ng daemon is available).
The essential part of this configuration is that we want all of the events that we
consider important that are received by the syslog-ng daemon to be placed into
the /var/log/messages file (which is where the default Tivoli Security Operations
Manager EAM configuration expects to find them). We also use some basic
syslog-ng configuration options that help to format the messages in a format that
is more easily recognized by the Tivoli Security Operations Manager conduits.
Example 12-10 A basic syslog-ng.conf file
#
#
#
#
#
EAM basic syslog-ng configuration

define some options, the important ones here for us are
the use of long hostnames and the use of fully qualified domain
names.
options { sync (0);

time_reopen (10);
log_fifo_size (2048);
long_hostnames (off);
use_dns (no);
use_fqdn (no);
perm(0644);
create_dirs (no);
411
7530ch12.fm
keep_hostname (yes);
};
# these next entries define the standard event sources
source s_internal { internal(); };
source s_local { unix_stream("/dev/log"); };
source s_udp { udp(); };
source s_tcp { tcp(); };
source s_kernel { pipe ("/proc/kmsg" log_prefix("kernel: ")); };
# these next two destination entries define where we want events to go
destination eam_messages {
file ("/var/log/messages");
};
destination d_kernel {
file ("/var/log/kern");
};
# these next entries tie the sources together with the destinations
# in this config we are basically saying we want all events except
# kernel generated events to go into our /var/log/messages file
log
log
log
log
log
{
{
{
{
{
source(s_udp); destination(eam_messages); };
source(s_tcp); destination(eam_messages); };
source(s_local); destination(eam_messages); };
source(s_internal); destination(eam_messages); };
source(s_kernel); destination(d_kernel); };
12.4.4 Setting up SSH users for Tivoli Compliance Insight Manager

We create a user named insight on the EAM host for the Tivoli Compliance
Insight Manager collection process to use. This user needs to have the
appropriate public key from the Tivoli Compliance Insight Manager server in
order to allow the Tivoli Compliance Insight Manager server to connect to it using
SSH. The process for generating and transferring this key is discussed in some
detail in Chapter 9 of the IBM Tivoli Compliance Insight Manager Installation
Guide Version 8.0, GI11-8176-00. To summarize the steps you need to:
Have PuTTY installed on the Point of Presence machine (in our case this is
our Tivoli Compliance Insight Manager Standard Server).
412
7530ch12.fm
Create an account on the audited machine for use by the Tivoli Compliance
Insight Manager server (in our case we are using the insight user that we
used previously).
Create and transfer the authentication tokens (for example, the PuTTY public
and private key pairs that we are going to use). The public key for the point of
presence machine needs to be in the authorized_keys file on the EAM for the
insight user (for example, in the .ssh/authorized_keys file). The private key
needs to be placed in the C:\IBM\TCIM\Server\run\sshkeys directory).
Perform a one time PuTTY connection as the cearoot user to our target
system for collection so that the appropriate key entries are added to the
Windows registry.
You can test the SSH connectivity using the chksshconn tool located in the
C:\IBM\TCIM\Tools directory as follows:
chksshconn -h demosys -u ns -k id_rsa.ppk
The -h option specifies the host to test, -u specifies the user to use on the
remote host and -k specifies the private key file to use from the sshkeys
directory.
Once this has been done and SSH connectivity has been confirmed we can
more onto step 3.
12.4.5 Modify syslog-ng.conf

Now we want to modify our syslog-ng configuration so that the syslog-ng
daemon places events into the correct locations for Tivoli Compliance Insight
Manager to collect and in the correct format. We do this by creating a syslog-ng
filter that will place all of the Snort events from our Snort system into a separate
file from which Tivoli Compliance Insight Manager can collect it. Using the basic
syslog-ng.conf file from Example 12-10 on page 411 we add the following entries
to our syslog-ng.conf file (see Example 12-11 on page 413).
Example 12-11 Tivoli Compliance Insight Manager syslog-ng.conf entries
# Our Snort hostname is demosys and the Snort program is referred to

# as Snort so we create an appropriate filter
# It is required that this entry be in your syslog-ng.conf file for
# every host that you want TCIM to collect events for.
filter f_ism_hosts {
host(192.168.164.200);
};
413
7530ch12.fm
# This is where tcim expects to find its events ie. in a subdirectory

# of the /var/log/consul directory. It also expects log entries
# to be in the format defined by the template below.
destination tcim {
file (/var/log/consul/$HOST/syslog-$YEAR-$MONTH-$DAY.log
template(<$PRI>$DATE $HOST $MSG\n)
create_dirs(yes)
owner(insight)
group(insight)
perm(0600)
dir_owner(insight)
dir_group(insight)
dir_perm(0700));
};
# Bring the sources, filter and destinations together
log { source(s_udp); filter(f_ism_hosts); destination(tcim); };
When we add this to the end of our syslog-ng.conf file the syslog-ng daemon will
create a log file in the /var/log/consul/192.168.164.200 directory. The log will be
named syslog<suffix>.log where the suffix is made up of the current year, month
and day for example syslog-2007-08-27.log. This is the file that the Tivoli
Compliance Insight Manager collection process is expecting to find when it does
a log collection.
After making these changes restart the syslog-ng daemon and confirm that
syslogging is still occurring as expected.
12.4.6 Adding the remote SSH based event source

In this step we are configuring the EAM for SSH remote collection of the Snort
syslog events using the insight user and keys that we created in step 2.
1. Log in to the Tivoli Compliance Insight Manager management server and
select the Machine View. Then press the Add Machine button to start the
Add Machine Wizard (see Figure 12-30 on page 415). Click Next to
continue.
414
7530ch12.fm
Figure 12-30 The Add Machine Wizard
2. Select the Audited Machine Type of Linux (see Figure 12-31 on page 415).
Figure 12-31 Select Audited Machine Type
3. Now add your machine name (in our case we are using the IP address of
192.168.164.200 (see Figure 12-32 on page 416). Click Next to continue.
415
7530ch12.fm
Figure 12-32 Choose Audited Machine
4. Next select the Point of Presence that will do the collection for us. In our case
we are using the TCIMDEMO Point of Presence (Note: this is where the SSH
connection we setup earlier needs to work from). This is shown in
Figure 12-33 on page 416. Click Next to continue.
Figure 12-33 Selecting the Point of Presence
5. In our case we are choosing to collect Snort logs so we want to define this
event source type as Snort syslog from syslog host (see Figure 12-34). Click
Next to continue.
416
7530ch12.fm
Figure 12-34 Defining the event source type
6. Next the Add Event Source Wizard automatically starts (see Figure 12-35 on
page 417). Click Next to continue.
Figure 12-35 The Add Event Source Wizard
7. Sdd the appropriate details for the SSH KeyFile, SSH Port, user and host (in
our case the key file is called key.ppk, the port is the default 22 port, the user
417
7530ch12.fm
is insight and the host IP address is 192.168.164.200) as shown in

Figure 12-36 on page 418. Click Next to continue.
Figure 12-36 Defining the event source properties
8. Now we create a collect schedule as shown in Figure 12-37 on page 419. In

our case we are choosing to not schedule a collect at this point until we are
happy that everything is working correctly. Later we will modify the collect
schedule to reflect our requirements.
418
7530ch12.fm
Figure 12-37 Selecting the collect schedule
9. Next we choose the GEM database that we want the Snort data to be loaded
into (we have previously created a database labeled Snort for this purpose).
This is illustrated in Figure 12-38. Click Next to continue.
419
7530ch12.fm
Figure 12-38 Defining the database for the event source
10.This completes the Add Machine Wizard as shown in Figure 12-39.
Figure 12-39 The Add Machine Wizard is complete
To test this configuration we are going to create a simple policy using the
standard Snort policy groupings that are provided with Tivoli Compliance Insight
Manager.
420
7530ch12.fm
First we create a new empty policy called SNORT in the same way as is
described in several other places throughout this book including later in this
chapter in 12.7, Laying down standard policy on Tivoli Security Operations
Manager data on page 438. We add the Snort policy groupings as follows.
Open the policy and right click in the Policy section to Import the Group Definition
Set for Snort as shown in Figure 12-40 on page 421. The Snort group definition
file that we are after is named snort_group.cfg.
Figure 12-40 Import the Snort policy grouping
Then create a basic policy as defined below in Figure 12-41 on page 422. In this
example we have also modified some of the system groups, specifically the
SensitiveSystems group, where we have defined our Snort system (with IP
Address 192.168.164.200) as being a sensitive system with a significance of 99.
Our very basic policy should highlight non reconnaissance traffic and traffic that
is targeting our sensitive system. We have chosen this policy as reconnaissance
traffic is often considered white noise in the sea of events that a system will
receive. With our policy reconnaissance traffic is considered normal, any other
type of traffic is considered abnormal and should be highlighted. Also any traffic
that is specifically targeting our Sensitive System will be highlighted as worth
investigation.
421
7530ch12.fm
Figure 12-41 Basic policy creation
Next we collect, load and apply our Snort policy to the loaded data. After this has
been done the results displayed in the iView portal for the Snort database will
look similar to what is in Figure 12-42 on page 423.
422
7530ch12.fm
Figure 12-42 The Snort compliance dashboard
Further drill down into our exceptions result in a report similar to that shown in
Figure 12-43 Exceptions
The results of this are that we now have events that were collected by the Tivoli
Security Operations Manager Event Aggregation Module (EAM) component
available to Tivoli Compliance Insight Manager for further processing and
application of policies. Tivoli Compliance Insight Manager can also now perform
log management for Tivoli Security Operations Manager collected syslog data.
By applying this approach to all of the syslog data collected by Tivoli Security
Operations Manager we reduce the requirement to manage Tivoli Security
Operations Manager syslog data for long periods of time. The key benefit of this
is that we now have realtime Security Event Management available in a way that
meets our long term auditing requirements.
423
7530ch12.fm
12.4.7 Conclusion
In this section we have shown how to use the Tivoli Security Operations Manager
EAM to both collect events for real time processing by Tivoli Security Operations
Manager as well capture the same event data for long term log management and
policy reporting by Tivoli Compliance Insight Manager. In the next section we
show how Tivoli Financial Accounting Corporation implemented a mechanism
where by Tivoli Security Operations Manager data can be supplemented with
policy breach data captured by Tivoli Compliance Insight Manager and where
Tivoli Compliance Insight Manager can use the rules facility in Tivoli Security
Operations Manager for sophisticated automation.
12.5 Tivoli Compliance Insight Manager attention alerts

to Tivoli Security Operations Manager
Tivoli Compliance Insight Manager has the capability of generating attention
alerts when a policy has been breached. This information may be useful from a
real time alerting perspective and can add to the real time monitoring capabilities
of Tivoli Security Operations Manager. However as Tivoli Compliance Insight
Manager does not operate in real time the nature of these alerts is generally not
time critical. What is useful though is being able to see all the events generated
by a system in the same view when performing host investigative tasks. For a
security operator the capability of seeing policy alerts in the same context as real
time alerts provides them with an additional valuable source of information when
evaluating a current incident. In addition performing this integration allows Tivoli
Compliance Insight Manager to leverage Tivoli Security Operations Managers
greater incident management capabilities.
This integration scenario requires that Tivoli Security Operations Manager and
Tivoli Compliance Insight Manager be installed at functioning. It also requires
that the Tivoli Security Operations Manager product have the latest device rules
update as this has Tivoli Compliance Insight Manager support (device rules prior
to October 2007 may not have device support for Tivoli Compliance Insight
Manager).
12.5.2 Basic approach

The basic approach is to use Tivoli Security Operations Managers UCM
(Universal Collection Module) to collect custom attention alerts from Tivoli
424
7530ch12.fm
Compliance Insight Manager. It relies on both Tivoli Security Operations

Managers ability to read text files for event content and Tivoli Compliance Insight
Managers ability to use a custom alert type that can write to a log file.
12.5.3 Configure Tivoli Compliance Insight Manager attention alerts

Now we configure Tivoli Compliance Insight Manager to generate alerts. We use
the custom alert protocol to create a log of Tivoli Compliance Insight Manager
alerts. This log file is then monitored using a local installation of the Tivoli
Security Operations Manager Universal Collection Module.
To configure the custom alert protocol from Tivoli Compliance Insight Manager
perform the following steps:
1. Log into the Tivoli Compliance Insight Manager management console and
select the Alerts management component (see Figure 12-44 on page 425)
then create a new custom alert.
Figure 12-44 Open the Tivoli Compliance Insight Manager Alerts management console
2. Double click on the alert to bring up the following dialog box (see Figure 12-45
on page 426) and enter the following values:
425
7530ch12.fm
Protocol = custom
Recipient = TSOM
Severity = 70
Rule ID(s) = alert_to_TSOM
Note: We use the Rule ID alert_to_TSOM later when we create attention
rules that we would like to generate alerts to Tivoli Security Operations
Manager.
Figure 12-45 Alert details
3. Click on OK to save the custom alert.

4. Next we need to define a Custom protocol for our alert. Do this by first
highlighting our custom alert and then pressing the Protocol Settings button
(see Figure 12-46 on page 427).
426
7530ch12.fm
Figure 12-46 Protocol Settings
5. In the resulting dialog box enter the following details (see Figure 12-47 on
page 428).
c:\IBM\TSOM\run\alert.cmd <eventfile>
Note: The <eventfile> parameter will be substituted for a comma separated
representation of the alert when Tivoli Compliance Insight Manager
generates it.
427
7530ch12.fm
Figure 12-47 Custom alert protocol settings
6. Next create the cmd file that is referenced above and the alerts directory for
Tivoli Compliance Insight Manager to place its alerts log into (see
Example 12-12 for the contents of the cmd file). Run these commands:
mkdir C:\IBM\TSOM\alerts
mkdir C:\IBM\TSOM\run
notepad C:\IBM\TSOM\run\alert.cmd
Then enter the details into the alert.cmd file and save it. At this point if a rule
is triggered with the id alerttotsom by Tivoli Compliance Insight Manager it
will be written to the tcimalert.log.
Example 12-12 alert.cmd file
@echo off
type %1 >> C:\IBM\TSOM\alerts\tcimalert.log 2>nul:
12.5.4 Configure Tivoli Security Operations Manager to process

custom alerts
Next we install the Tivoli Security Operations Manager Universal Collection
Module (UCM) on the Tivoli Compliance Insight Manager server. Installation of
the Tivoli Security Operations Manager UCM is covered in the Tivoli Security
Operations Manager installation guide. Once we have installed the UCM we
must modify the UCM configuration file so that the section that refers to Consul
428
7530ch12.fm
reflects the correct alert file location and the IP address of the Tivoli Compliance
Insight Manager server.
1. To do this search through the ucm.cfg file until you find the Consul entry and
then modify it so that it looks like Example 12-13. In our case the IP address
of the Tivoli Compliance Insight Manager server is 192.168.164.150.
Example 12-13 UCM configuration change
#
# create file tailer 25 for consul
#
ucm.tailer.file.filename.25=c:/IBM/TSOM/alerts/tcimalert.log
ucm.tailer.file.buffer.size.25=1024
ucm.tailer.file.sensortype.25=consul
ucm.tailer.file.saves.file.name.25=consul-1
ucm.tailer.file.start_at_end.25=false
ucm.tailer.file.hostname.25=192.168.164.150
2. Now we can define the Tivoli Security Operations Manager sensor for Tivoli
Compliance Insight Manager. This is done in the standard way that any Tivoli
Security Operations Manager sensor is defined (more information on this may
be found in IBM Tivoli Security Operations Manager 3.1 Installation Guide
or in the IBM Tivoli Compliance Insight Manager User Reference Guide
Version 8.0, SC23-6545-00). The basic steps for defining our new Tivoli
Security Operations Manager sensor are shown in the next few of figures.
First define the sensor at the CMS as shown in Figure 12-48.
429
7530ch12.fm
Figure 12-48 Define a Consul sensor at the CMS
Then define the sensor at the EAM as shown in Figure 12-49 on page 431.
430
7530ch12.fm
Figure 12-49 Define a Consul sensor at the EAM
3. Then start the UCM service.

4. At this point any special attention alerts generated by Tivoli Compliance
Insight Manager will also appear in the Tivoli Security Operations Manager
system (as shown in Figure 12-50 on page 431) and can be used in Tivoli
Security Operations Manager rules.
Figure 12-50 Tivoli Compliance Insight Manager attentions in Tivoli Security Operations Manager
431
7530ch12.fm
Now we can use Tivoli Security Operations Managers rules to run some
automation, send e-mail, and escalate to other systems management
products when special attention alerts are captured. For example, if we
wanted to run some automation we could define a Tivoli Security Operations
Manager action that looks like Figure 12-51 on page 432 and a rule that looks
like Figure 12-52 on page 433.
Figure 12-51 Define a Tivoli Security Operations Manager Action to respond to a special
attention alert
432
7530ch12.fm
Figure 12-52 Define a rule that detects a special attention alert
433
7530ch12.fm
12.5.5 Conclusion
In this section we have shown how to have Tivoli Compliance Insight Manager
generated alerts made available to Tivoli Security Operations Manager for further
rules based processing and correlation. In the next section we explain
mechanisms for integrating the visual aspects of the Tivoli Security Operations
Manager and Tivoli Compliance Insight Manager tools so that reports can be
accessed from a common location.
12.6 Single audit portal

Often organizations would like a single portal for presentation of compliance
information. At present the integration between Tivoli Security Operations
Manager and Tivoli Compliance Insight Manager is in its early stages. Even so it
is easy to integrate the components so that a single entry point can be
presented.
In this integration we modify the iView portal so that links to various sets of Tivoli
Security Operations Manager functionality are available. The functionality we
would like available from our iView portal is the ability to click on a link and be
taken directly to the Tivoli Security Operations Manager real time event viewing
portal, another link to take us to the Tivoli Security Operations Manager reporting
portal to give us easy access to network security related events and last a link to
a set of regularly scheduled reports from the Tivoli Security Operations Manager
data (for this we have created a Web site where pre generated reports are
available). Each link is created in the same way so we will only show how to
create the basic container and one of our links. Please keep in mind that
currently this type of customizing the basic iView portal is not supported by IBM,
however we considered it so straightforward and lacking in any real danger that
we have made the integration details available in this Redbook.
The iView portal is a Web application running on the Apache Tomcat application
server. The application server used by default for iView may change in the future,
however, the steps would be very much the same even if the iView application
were running on some other application server, such as IBMs own WebSphere
Application Server.
Within the Tomcat directory are various configuration files that control how the
iView application runs (the Tomcat directory is located by default in
C:\IBM\TCIM\iView\tomcat). One of the subdirectories is the conf\insight-apps
directory (for example, C:\IBM\TCIM\iView\tomcat\conf\insight-apps). This
directory contains a series of subdirectories where each of the subdirectories
represents an application that can be invoked from the iView portal or a section
434
7530ch12.fm
of the iView portal (see Figure 12-53 on page 435). The subdirectories will
typically be prefixed with app to represent applications that can be invoked from
the iView portal and sec for subsections of the iView portal view.
Figure 12-53 The iView directory structure
To create a new application or section of the iView portal we need only replicate
these app or sec directories as required. For our purposes we have created three
new app directories, one for each of the applications we wish to launch and one
new sec directory to contain these applications. In Figure 12-53 these are
labelled app-tsom, app-tsomreports, app-tsomscheduledreports and
sec-tsomportal. These directories initially are just direct copies of one of the other
existing app or sec directories as required. We will modify the directory contents
435
7530ch12.fm
so that the final result is an iView portal that looks like the figure below (see
Figure 12-54 on page 436).
Figure 12-54 The final iView portal view
First we will start with the contents of the app-tsom directory. After the copy it will
contain three files. The application.xml file controls what application will be
invoked when you click on the link in the portal, the resources.properties file
controls what text will be displayed in the iView portal and the gif file is the icon
that will be displayed in the portal.
To add a link to the Tivoli Security Operations Manager real time events console
from the portal we modified the contents of the application.xml file to reflect what
is in Figure 12-55 on page 437. The key value we are modifying is the URL that is
invoked by clicking on the link. In our case we modify it to point at our Tivoli
Security Operations Manager real time event portal (which is at
http://192.168.164.200).
436
7530ch12.fm
Figure 12-55 The application.xml file
We then modify the resources.properties file so that it looks like Figure 12-56, for
example, it reflects the link name of TSOM and the description of Open TSOM
Realtime Event Portal.
Figure 12-56 The resources.properties file
This has now defined our link to the Tivoli Security Operations Manager real time
event viewer portal. The other two applications are defined in the same way as
this except in the case of the link to the Tivoli Security Operations Manager
Reports Portal we will use the URL that takes us to the Tivoli Security Operations
Manager Reports Portal.
For the Tivoli Security Operations Manager Scheduled Reports link we have
used a Tivoli Security Operations Manager capability provided via its reporting
portal. The capability allows us to automatically schedule and generate a report
in html format and publish that to a specified location (in our case a reporting
Web server). Conceptually what we have done is provide a single entry point to
these pre generated reports from the iView portal.
In addition it would be possible to use Tivoli Compliance Insight Manager to
monitor the access to that portal in order to confirm compliance. Most
compliance regulations dont just state that audit reports should be generated,
they also state that those reports should be reviewed. By using a portal based
approach to presenting the combined set of reports from both Tivoli Compliance
Insight Manager and Tivoli Security Operations Manager we can also leverage
Tivoli Compliance Insight Managers Web server audit capabilities to monitor
whether the audit reports are being reviewed.
Now we create a new section within the iView portal to contain our Tivoli Security
Operations Manager components. This is done by copying one of the existing
sec directories to sec-tsomportal and modified its contents. The sec-tsomportal
437
7530ch12.fm
directory will contain two files branding-properties and section.xml we

modified these so that the contents reflect
Figure 12-57 branding.properties
Figure 12-58 section.xml
By creating and modifying these sec and app configurations and then restarting
the Tomcat server we are now able to provide a consistent entry point to all of
our SIEM components as show in Figure 12-54 on page 436.
12.7 Laying down standard policy on Tivoli Security

Operations Manager data
In this section we create some simple policy rules to apply to Tivoli Security
Operations Manager audit records. This is a fairly simple example which we can
extend relatively easy as we translate our overall policy rules into the W7
language.
For testing purposes we will create a new blank policy which we will call
TSOMPolicy. We will then create three basic rules that can be expressed in plain
english as:
Tivoli Security Operations Manager Administrators can log on to the system
at any time of the day or night.
Non Tivoli Security Operations Manager Administrators can only log in during
defined working hours.
Any events generated by the system user are not considered exceptions but
we wish these displayed in our dashboard separately from audit events
generated by successful/unsuccessful logins to Tivoli Security Operations
Manager.
Here are the necessary implementation steps.
438
7530ch12.fm
1. Create a blank policy called TSOMPolicy (see Figure 12-59 on page 439).
Figure 12-59 Create new Tivoli Security Operations Manager Policy
2. Open your new policy and create a new Tivoli Security Operations Manager
policy group (as in Figure 12-60 on page 439) and name it TSOM.
Figure 12-60 TSOM Policy Group
439
7530ch12.fm
3. Then import the global_policy group (see Figure 12-60 on page 439). This
should give you the following policy groups defined (
Figure 12-61 TSOM Policy groups defined
4. Next double click on your TSOM Policy Group to display the W7 groupings
ready for definition.
You should define the following groups for your who definitions:
Who
TSOMAdmins where logon name is admin
Who
System where logon name is system
Who
NotAdmins where the user is not in the groups TSOMAdmins or

System.
This will result in your who definition shown in Figure 12-62 on page 440.
Figure 12-62 Who definitions for TSOMPolicy
Next for your What definitions:

What
Logon where the event main class is Logon
What
Worm where the event main class contains Worm
What
Policy where the event main class contains Policy
This will result in your what definition shown in Figure 12-63 on page 441.
440
7530ch12.fm
Figure 12-63 What definitions for TSOMPolicy
Next for your On What definitions:

On What
PolicyAlerts where Object name contains Policy
On What
Worm where Object name contains Worm
On What
Logons where Object name contains Login
This will result in your OnWhat definition shown in Figure 12-64 on page 441.
Figure 12-64 OnWhat definitions for TSOMPolicy
441
7530ch12.fm
5. Next create some rules based on these policy groupings. In our rule we are
stating (admittedly this is a very simple rule) the following:
TSOMAdmins are allowed to logon anytime they need. Any other
TSOMAdmin action will be marked as an exception.
NotAdmins are only allowed to logon in business hours. Any other
NotAdmin action will be marked as an exception.
We dont want any exceptions generated by the System user (as this user
is the user that will be the source of all our Tivoli Security Operations
Manager events that are not audit related).
The first of these rules is created by first right clicking in the Policy Rules area
of the window (see Figure 12-65 on page 442).
Figure 12-65 Creating a policy rule
Then entering the values as illustrated in Figure 12-66 on page 443.
442
7530ch12.fm
Figure 12-66 First policy rule definition
The other rules are created in the same manner. When you have completed
the Policy Rules window will look as in Figure 12-67 on page 443.
Figure 12-67 Our basic policy TSOM definition
12.7.1 Results
After we have created this policy and applied it to the data collected from Tivoli
Security Operations Manager our results will be a dashboard as illustrated in
443
7530ch12.fm
Figure 12-68 The results of applying our Tivoli Security Operations Manager policy
This report is telling us that we have collected 107 events. Of those 107 events
three are policy exceptions. The dashboard further informs us that the
NotAdmins who group is where exceptions lie, for example, some of our non
administrators must have logged in out of normal office hours. Typically the
intersection of the NotAdmins Who group and the Logons group will display in
the color red to indicate that exceptions occur in this group. From this report we
can navigate to the exceptions very easily by clicking on the event summary icon
next to the policy exceptions list. Doing this will result in a report as in
Figure 12-69 Policy Exception Report
From here we can quickly drill down to find the original event that generated the
policy exception.
444
7530ch12.fm
From this example you can see that it is fairly easy to apply policy to Tivoli
Security Operations Manager data. The value of this approach is that once you
have defined policies across your enterprise you can extend those policies to
new platforms such as Tivoli Security Operations Manager with little difficulty.
12.8 Conclusion
In this chapter we discussed multiple Tivoli Security Operations Manager and
Tivoli Compliance Insight Manager integration scenarios and showed how these
integrations can be easily implemented using the integration features that have
been designed into each of the components. We then went on to show how Tivoli
Compliance Insight Manager policy could be applied to Tivoli Security
Operations Manager data, generating some policy reports using a simple
example that should demonstrate the business value that will ultimately be
achieved by Tivoli Financial Accounting Corporation. In conclusion to this
chapter we should reiterate that IBM only recently acquired both components of
the SIEM solution, so the integration is at an early stage. However, the
integration that has been performed is already powerful and is to improve in the
future.
445
7530ch12.fm
446
7530ax01.fm
Appendix A.
Corporate policy and

standards
Technology should not drive the corporate policy; it should be the other way
around. Once you know what you need to protect and the potential threats and
risks to those assets, you can start protecting them. First, all the threats and risks
will be classified in a study based on certain elements, such as:
Direct financial loss

Indirect financial loss (such as investigation, recovery, and so on)
Loss of confidential information
Liability
Image impact (loss of goodwill, customer loyalty, and so on)
Cost of risk mitigation or transfer
Accepting residual risk
This study can process the same threats and risks applied to different assets, but
concludes at a different level of liability, based on your particular business
environment. Then the decision has to be made: accept, mitigate, or transfer the
risk. This process can be handled by external consultants, such as IBM Global
Services, or by an internally appointed team. The process can use both formal
and informal methods, but the result is usually a blend of these approaches. The
threat identification, as well as this severity study, using a formal approach is
done in conjunction with the organization by applying a standard and a proven
methodology.
447
7530ax01.fm
It is tempting to directly translate the threat analysis into a technical solution, but
it should first lead to the corporate policy and standards. These documents will
highlight the risks and present how they must be handled enterprise wide.
The first document that must be written is therefore the corporate policy
document. It must outline the high-level directions to be applied enterprise wide.
It is absolutely not technical; it is derived from the business of the enterprise and
should be as static as possible, as seen in Figure A-1.
Static
Corporate
Policy
Standards
Standards
Standards
Standards
ProceduresPractices
ProceduresPractices
Procedures
Technical
Figure A-1 Dynamics for policy, standards, practices, and procedures
Attention: Policies is a very common term and in many products you will find
specific policies sections. These are the product related policies that are
covered in the practice or procedure documents. The corporate policy is not
related to products and is a high level document.
448
7530ax01.fm
Standards, practices, and procedures

Standards are derived from the corporate policy. They are documents explaining
how to apply the policy details in terms of authentication, access control, and so
on. They explain how the policy must be applied. Changes in threats or major
technology changes can impact them.
The standards are then mapped to practices or procedures.
The practices are descriptions of practical implementations of the standard on an
operating system, application, or any other endpoint. They will detail precise
configurations, such as the services to be installed, the way to set up user
accounts, or how to securely install software.
The procedures document the single steps to be applied to requests and the
approval and implementation flows. Such a procedure could be the request to
access a specific set of sensitive data, where the approval path (system owner,
application owners, and so on) and conditions (Virtual Private Network (VPN),
strong authentication, and so on) are explained in detail.
Tip: Approval procedures are often implemented by sending E-mails or
paperwork. The efficiency can be improved by using a computer to handle
these repetitive tasks and ensure that changes within the company are
applied quickly to the procedures. As explained later, this can reduce human
errors.
Practical example
Here is an example of how a policy is defined and implemented with procedures
and practices.
The operations manager has reported an increased workload on the help desk
due to problems caused by employees downloading non-business related
programs onto their systems.
The problems range from the introduction of viruses to disruption of business
processes, with a real financial impact. To address this problem, upper
management incorporated, in the corporate policy, the following directive: The
corporate assets may be used only to perform enterprise related tasks.
First, the policy must be communicated to all employees in the enterprise.
The standards for the networking part explain which services may be allowed on
the employee computer. The practice will then explain how to set up the
Appendix A. Corporate policy and standards
449
7530ax01.fm
Windows or Linux clients according to the standards, and the procedures will
explain how to perform a request, the requirements, and the approval paths, to
get special services installed on your computer.
The existing clients will be updated and controls will be performed to verify the
compliance, in addition to further audit of the environment.
The five steps we went through are summarized in Figure A-2. It is a common
approach adopted in many methodologies.
Policies
Implement
Manage
Risk
Audit
Figure A-2 The five steps in defining your IT security
External standards and certifications

The discussion on corporate policies suggests that internal business needs are
the drivers for designing corporate policies. While this is true, there are a number
of external factors that can change these business needs and policies. Some of
these external pressures can be detailed enough to specify not only policies, but
also standards and procedures.
450
7530ax01.fm
Examples of these external drivers are shown in this section. The list is not
exhaustive, nor is each description complete. It is provided as a guide to the type
of standards that may (or may not) apply to your organization and, therefore,
some of the external factors you must consider when creating policies.
Many organizations use these external standards as a guide to help them
formulate their own corporate policies. It is not uncommon to find organizations
using the ISO17799 standards, but without having them externally audited and
certified. These standards are seen as a good foundation for security.
Industry specific requirements

Some industry sectors have standards that are specific to that industry sector.
Two examples are:
The Sarbanes-Oxley Act (SOX)
SOX was established in 2002, results from 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.
Basel II
Basel II is an accord issued by the Basel Committee on Banking Supervision
and provides summarized recommendations on banking laws and regulations
with the intent to harmonize banking regulation worldwide. This second
accord introduces matters around Operational Risk, which again includes
risks in the area of technology, processes and people.
Any pharmaceutical company that wishes to sell or market its products in
America needs to abide by these rules. Corporate policies, standards, and
processes need to reflect this requirement.
CFR 21 Part 11
21 CFR Part 11 applies to electronic records that are created, modified,
maintained, archived, retrieved, or transmitted under any records
requirements covered by Federal Drug Agency regulations.
Any pharmaceutical company that wishes to sell or market its products in
America needs to abide by these rules. Corporate policies, standards, and
processes need to reflect this requirement.
Health Insurance Portability and Accountability Act (HIPAA)
HIPAA was established in 1996 and contains provisions for USA national
standards for the security and privacy of electronic health information. It
451
7530ax01.fm
provides safeguards for the area of administration processes and the physical
and technical infrastructure and defines the rights of individuals and the
related obligations for organizations in the health industry with regard to
Personal Health Information (PHI).
The requirements of the HIPAA standard have since then been adopted into
health industry regulation of many other countries, for example in Germany.
Gramm-Leach-Bliley Act (GLBA)
GLBA was established in 1999 and deals with the protection of the privacy of
customers or financial institutions as well as the security requirements to be
met by financial institutions. The two significant impacts of the act are on one
hand the obligation of strict separation between corporate and private
banking and insurance activities on financial institutions in the USA in
contrast to the widely spread universal banking approach taken by financial
institutions in Europe. On the other hand, the act introduces the requirement
to take precautions against Social Engineering, which is referred to as
Pretexting in the act. Also, the act requires financial institutions to establish a
security framework to protect their own and their customers financial data.
Product or solution certifications

Some products or solutions can be certified before use so that a potential
purchaser has an understanding that the product or solution will fit the role it is
needed for.
Common Criteria
This is a set of tests originally based upon the US Orange book and
European/Australian ITSEC evaluations. It is currently recognized by 14
countries. There are seven levels of tests. Evaluation Assurance Levels (EAL)
14 are usually used in the commercial areas, while the tests representing the
higher EALs 57 are reserved for the security testing of highly secure
environments.
CAPS UK
In addition to internationally recognized evaluations, there maybe local
evaluations that impact an organization. The UK Government's
Communications-Electronic Security Group (CESG) have produced the Assisted
Products Scheme in effort to help commercial product vendors produce
cryptographic products suitable for use by the British government. It is called
CAPS (CESG Assisted Product Scheme). CAPS is similar in purpose to the FIPS
140 (for the US and Canadian governments) and the Cryptographic Advisory
Note (CAN) (for the Australian and New Zealand governments).
452
7530ax01.fm
Nationally and internationally recognized standards

Some standards bodies publish broad general sets of standards that an
organization can implement. These standards can be audited and hence the
organization can be sure they are complying
BS7799, ISO17799 and ISO27001

BS7799 was written in February 1995 and was updated in May 1999 and is the
most widely known standard. British Standard (BS) 7799 consists of multiple
parts. The first part is intended to serve as a single reference point for identifying
a range of security controls, needed for most situations, where information
systems are used in industry and commerce within large, medium, and small
organizations. This part has been lifted onto the international level in 2001 and is
called ISO17799; it has been updated in 2005. The second part of BS7799
defines the standard against which organizations can be certified for meeting the
method and intend of part 1. This second part has been internationally adopted
as ISO27001. In order to reduce confusion with the numbering, ISO17799 has
recently be renumbered as ISO27002.
BS7858
BS7858 is just one example of some of the other less well known standards that
could affect security policy. Specifically, BS7858 gives recommendations for the
security screening of personnel to be employed in an environment where the
security of people, goods, or property is a significant feature of the employing
organization's operations.
Data Privacy Laws

The privacy laws of the country in which an organization operates are many and
diverse. The application of the laws is variable from geography to geography,
and it is good to be aware of the impact of them upon corporate security policies.
Modern democracies are often fond of creating freedom of information laws. One
of the problems with these laws is that they are directly contrary to the same
democracies wish to maintain the privacy of individual information. Besides the
the articles of the privacy laws, the actual legal practice and enforcement of the
laws is very important. In some countries, the actual obligations may not be met
in a given case, but it might be a widely accepted practice.
453
7530ax01.fm
Privacy law is, therefore, a growing area. Some examples are:

UK Data Protection Act 1998
An act to make new provisions for the regulation of the processing of
information relating to individuals, including the obtaining, holding, use, or
disclosure of such information.
European Data Directive 95/46/EC
This directive and others give direction to issues surrounding the protection of
individuals with regard to the processing of personal data and on the free
movement of such data. The way they interact with national law must also be
considered.
Summary
Corporate policies must be thought of as business level requirements. They are
primarily internal business drivers, but they may be impacted upon by external
factors, so corporate policies will have to take account of these factors.
Subsidiary standards and the procedures and practices that result in turn are
also produced.
Corporate policies should be relatively static and technology free, while
standards, practices, and procedures can be more fluid and technology specific.
454
7530glos.fm
Glossary
8-bit UCS/Unicode Transformation Format is a
variable-length character encoding for Unicode. It is
able to represent any character in the Unicode
standard, yet the initial encoding of byte codes and
character assignments for UTF-8 is consistent with
ASCII.
Aggregation Database 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, which is used for trend
and summary reports.
Access Management A discipline that focuses on

ensuring that only approved roles are able to create,
read, update, or delete data - and only using
appropriate and controlled methods. Data
governance programs often focus on supporting
access management by aligning the requirements
and constraints posed by governance, risk
management, compliance, security, and privacy
efforts.
Alerts are messages that Tivoli Compliance

Insight Manager sends when a serious or potentially
harmful security event has occurred. Alerts allow for
a fast response to the event by a systems manager
or system administrator.
Actuator A piece of software that automates

the collection of logs from event sources and
transmits the logs to the Depot. Each Actuator
consists of an Agent and numerous Actuator
Scripts. The server where the Actuator is
installed is referred to as the Point of Presence.
Actuator Scripts 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.
Agent The Agent is a component of the
Actuator. It listens for collect requests from the
Tivoli Compliance Insight Manager Server;
invokes the appropriate Actuator Script;
compresses the retrieved logs and maintains
an encrypted channel for communication with
the Tivoli Compliance Insight Manager Server
in order to securely deliver the requested logs.
Assurance Activities designed to reach a measure

of confidence. Assurance is different from audit,
which is more concerned with compliance to formal
standards or requirements.
Audit An independent examination of an effort to
determine its compliance with a set of requirements.
An audit may be carried out by internal or external
groups.
Audit Report A report which shows infrastructure
changes that are made to hardware and software
and who is responsible for the changes.
Audit Trail A record that can be interpreted by
auditors to establish that an activity has taken place.
Often, a chronological record of system activities to
enable the reconstruction and examination of the
sequence of events and/or changes in an event. An
audit trail of system resource usage may include
user login, file access, and triggers that indicate
whether any actual or attempted security violations
occurred.
Audited System A system on which events
occur and are recorded in logs which provide
the audit data for Tivoli Compliance Insight
Manager.
455
7530glos.fm
Authentication In computer security, verification
of the identity of a user or process and the
construction of a data structure that contains the
privileges that were granted to the user or process.
Contrast with authorization.
Authorization The process of granting a user
either complete or restricted access to an object,
resource, or function. Contrast with authentication.
Basel II A round of deliberations by central
bankers from around the world, under the auspices
of the Basel Committee on Banking Supervision
(BCBS) in Basel, Switzerland, aimed at producing
uniformity in the way banks and banking regulators
approach risk management across national borders.
The Basel II deliberations began in January 2001,
driven largely by concern about the arbitrage issues
that develop when regulatory capital requirements
diverge from accurate economic capital calculations.
Basel II recommends three pillars: risk appraisal and
control, supervision of the assets, and monitoring of
the financial market, to bring stability to the financial
system.
Batch Collect Mechanism for retrieving security
log data.
British Standard 7799 A standard code of
practice and provides guidance on how to secure an
information system. It includes the management
framework, objectives, and control requirements for
information security management systems.
Can Spam Act of 2003 is a commonly used name
for the United States Federal law more formally
known as S. 877 or the Controlling the Assault of
Non-Solicited Pornography and Marketing Act of
2003. The law took effect on January 1, 2004. The
Can Spam Act allows courts to set damages of up to
$2 million when spammers break the law. Federal
district courts are allowed to send spammers to jail
and/or triple the damages if the violation is found to
be willful.
CCO See Chief Compliance Officer.
456
CERT See Computer Emergency Response

Team.
Certified Server Validation (CSV) is a technical
method of e-mail authentication intended to fight
spam. Its focus is the SMTP HELO-identity of Mail
transfer agents.
Change Control A formal process used to ensure
that a process, product, service, or technological
component is modified only in accordance with
agreed-upon rules. Many organizations have formal
Change Control Boards that review and approve
proposed modifications to technology
infrastructures, systems, and applications. Data
governance programs often strive to extend the
scope of change control to include additions,
modifications, or deletions to data models and
values for reference/master data.
Chief Compliance Officer (CCO) is the officer
primarily responsible for overseeing and managing
compliance issues within an organization. The CCO
typically reports to the Chief Executive Officer. The
role has long existed at companies that operate in
heavily regulated industries such as financial
services and health care. For other companies, the
rash of recent accounting scandals, the
Sarbanes-Oxley Act, and the recommendations of
the U.S. Federal Sentencing Guidelines have led to
additional CCO appointments.
Chunk Data structure of the archived log files in
the Depot. A chunk consists of a header file and one
or more data files.
Client A system entity that requests and uses a
service provided by another system entity, called a
server. In some cases, the server may itself be a
client of some other server. A system entity that
requests and uses a service provided by another
system entity, called a server. In some cases, the
server may itself be a client of some other server.
Cluster (Tivoli Compliance Insight

Manager) The combination of a Enterprise
Server and one or more Standard Servers.
COBIT See Control Objectives for Information and

related Technology.
Collect History Report Tivoli Compliance Insight
Manager report that documents log collection
events.
Collector A software module that runs on a client
system and gathers data. This data is subsequently
sent to a server.
Committee of Sponsoring Organizations of the
Treadway Commission (COSO) is a U.S.
private-sector initiative, formed in 1985. Its major
objective is to identify the factors that cause
fraudulent financial reporting and to make
recommendations to reduce its incidence. COSO
has established a common definition of internal
controls, standards, and criteria against which
companies and organizations can assess their
control systems.
Common Criteria The Common Criteria is the
result of the integration of information technology
and computer security criteria. In 1983, the US
issued the Trusted Computer Security Evaluation
Criteria (TCSEC), which became a standard in
1985. Criteria developments in Canada and
European ITSEC countries followed the original US
TCSEC work. The US Federal Criteria development
was an early attempt to combine these other criteria
with the TCSEC, and eventually led to the current
pooling of resources towards production of the
Common Criteria. The Common Criteria is
composed of three parts: the Introduction and
General Model (Part 1), the Security Functional
Requirements (Part 2), and the Security Assurance
Requirements (Part 3). While Part 3 specifies the
actions that must be performed to gained
assurance, it does not specify how those actions are
to be conducted; to address this issue, the Common
Evaluation Methodology (CEM) was created for the
lower levels of assurance.
7530glos.fm
Compliance is either a state of being in

accordance with established guidelines,
specifications, or legislation or the process of
becoming so. Software, for example, may be
developed in compliance with specifications created
by some standards body, such as the Institute of
Electrical and Electronics Engineers (IEEE), and
may be distributed in compliance with the vendor's
licensing agreement. In the legal system,
compliance usually refers to behavior in accordance
with legislation, such as the United States' Can
Spam Act of 2003, the Sarbanes-Oxley Act (SOX) of
2002, or HIPAA (United States Health Insurance
Portability and Accountability Act of 1996).
Compliance Check A set of rules used to
determine whether a computer or group of
computers is compliant or not. There are two types
of compliance checks: software and security.
Compliance Dashboard Available in iView.

It displays an easy-to-understand, color-coded
matrix that highlights degrees and level of
compliance based on user behavior and data
access.
Compliance Management Module Tivoli
Compliance Insight Manager
regulation-specific reporting interface.
Compliance Report A report that provides
information about the patch compliance status of all
selected target computers.
Compliant State The state that a user wants an
object to have.
Glossary
457
7530glos.fm
Computer Emergency Response Team
(CERT) The CERT/CC is a major reporting center
for Internet security problems. Staff members
provide technical advice and coordinate responses
to security compromises, identify trends in intruder
activity, work with other security experts to identify
solutions to security problems, and disseminate
information to the broad community. The CERT/CC
also analyzes product vulnerabilities, publishes
technical documents, and resents training courses.
The CERT/CC is located at the Software
Engineering Institute (SEI), a federally funded
research and development center (FFRDC)
operated by Carnegie Mellon University (CMU).
Configuration Compliance The comparison of
known state to a compliant state and may include
automated actions. After discovery or scanning is
performed, devices are said to be either compliant or
noncompliant.
Consolidation Database An Enterprise Server
database that delivers enterprise-wide trend and
summary reports.
Control A means of managing a risk or ensuring
that an objective is achieved. Controls can be
preventative, detective, or corrective and can be
fully automated, procedural, or technology-assisted
human-initiated activities. They can include actions,
devices, procedures, techniques, or other
measures.
Control Objectives for Information and related
Technology (COBIT) is a set of best practices
(framework) for information technology (IT)
management created by the Information Systems,
Audit and Control Association (ISACA), and the IT
Governance Institute (ITGI) in 1992. COBIT
provides managers, auditors, and IT users with a set
of generally accepted measures, indicators,
processes and best practices to assist them in
maximizing the benefits derived through the use of
information technology and developing appropriate
IT governance and control in a company.
COSO See Committee of Sponsoring
Organizations of the Treadway Commission.
458
CSV
See Certified Server Validation.
Data Aggregation is the ability to get a more

complete picture of the information by analyzing
several different types of records at once.
Data Governance The exercise of
decision-making and authority for data-related
matters. The organizational bodies, rules, decision
rights, and accountabilities of people and
information systems as they perform
information-related processes. Data governance
determines how an organization makes decisions.
Data Mapping The discipline, process, and
organizational group that conducts analysis of data
objects used in a business or other context,
identifies the relationships among these data
objects, and creates models that depict those
relationships.
Data Privacy The assurance that a person's or
organization's personal and private information is
not inappropriately disclosed. Ensuring data privacy
requires access management, security, and other
data protection efforts.
Delta Table A database table used for saving
changed data from subsequent runs of a collector.
Deployment The process of reconfiguring and
reallocating resources in the managed environment.
Deployment occurs in response to deployment
requests, created manually by administrators or
automatically by the system.
Depot Tivoli Compliance Insight Manager secure
storage facility for storing and archiving logs.
Depot Server The component that stores files for
distribution. Files are uploaded to a Depot server
using a client and stored in a directory that is
specified when the Depot server is installed. Depot
servers can replicate files to other Depot servers
and download files to clients.
Domain A logical grouping of resources in a
network for the purpose of common management
and administration.
7530glos.fm
Enterprise Server A server that provides

centralized log management, performs forensic
searches of the GEM log archives, and creates
reports.
Governance, Risk, and Compliance (GRC) An

acronym often used by management in financial
institutions to acknowledge the interdependencies of
these three disciplines in setting policy.
Event is an observable occurrence in a system or

network.
Gramm-Leach-Bliley Act is an Act of the United

States Congress which repealed the Glass-Steagall
Act, opening up competition among banks, security
companies and insurance companies. The
Glass-Steagall Act prohibited a bank from offering
investment, commercial banking, and insurance
services.
Event Source Each operating system or

application from which Tivoli Compliance Insight
Manager collects log files (also called audit trails).
Extensible Markup Language (XML) is a
general-purpose markup language. It is classified as
an extensible language because it allows its users to
define their own tags. XML is recommended by the
World Wide Web Consortium. The W3C
recommendation specifies both the lexical grammar,
and the requirements for parsing.
File Transfer Protocol (FTP) is used to transfer
data from one computer to another over the Internet,
or through a network.
Forensic Analysis is used to follow up on security
incidents and behavioral trends.
FTP See File Transfer Protocol.
Geberic Scanning Laguage (GSL) is a scripting
language that enables you to describe the structure
and label the attributes contained in the log files of
ubiquitous collect event sources. The GSL Toolkit
eases the forensic analysis of log data by enabling
you to define attributes contained in the log data and
to describe the structure of log files.
GEM
See Generic Event Module.
General Scanning Language (GSL) is a scripting

language that enables someone to describe the
structure and label the attributes contained in the log
files of ubiquitous collect event sources.
GRC See Governance, Risk, and Compliance.

GSL
See General Scanning Language.
GSL See Generic Scanning Language.

Health Insurance Portability and Accountability
Act (HIPAA) is the United States Health Insurance
Portability and Accountability Act of 1996. There are
two sections to the Act. HIPAA Title I deals with
protecting health insurance coverage for people who
lose or change jobs. HIPAA Title II includes an
administrative simplification section which deals with
the standardization of health care-related
information systems. In the information technology
industries, this section is what most people mean
when they refer to HIPAA. HIPAA establishes
mandatory regulations that require extensive
changes to the way that health providers conduct
business.
HIPAA See Health Insurance Portability and
Accountability Act.
IETF See Internet Engineering Task Force.
Incident An incident as an adverse network event
in an information system or network or the threat of
the occurrence of such an event.
Generic Event Module (GEM)

Databases Reporting databases that contain the
logs from different event sources.
Glossary
459
7530glos.fm
Information Quality Management is an

information technology (IT) management discipline,
which encompasses the COBIT Information Criteria
of efficiency, effectiveness, confidentiality, integrity,
availability, compliance, and reliability. The idea is
for companies to have the risks of using a program
diminished to protect private and sensitive
information definition.
Information Systems Audit and Control
Association (ISACA) is an international
association for the support and improvement of
professionals whose jobs involve the auditing of
corporate and system controls.
ISO/IEC17799 is an information security standard

published by the International Organization for
Standardization (ISO) and the International
Electrotechnical Commission (IEC) as ISO/IEC
17799:2005 and subsequently renumbered ISO/IEC
27002:2005 in July 2007, bringing it into line with the
other ISO/IEC 27000-series standards. It is entitled
Information technology - Security techniques - Code
of practice for information security management.
The current standard is a revision of the version first
published by ISO/IEC in 2000, which was a
word-for-word copy of the British Standard (BS)
7799-1:1999.
Information Technology Governance is a subset

discipline of Corporate Governance focused on
information technology (IT) systems and their
performance and risk management. The rising
interest in IT governance is partly due to compliance
initiatives (e.g. Sarbanes-Oxley (USA) and Basel II
(Europe)), as well as the acknowledgement that IT
projects can easily get out of control and profoundly
affect the performance of an organization.
IT Governance Institute (ITGI) Exists to assist

enterprise leaders in their responsibility to ensure
that IT goals align with those of the business, it
delivers value, its performance is measured, its
resources properly allocated and its risks mitigated.
Through original research, symposia and electronic
resources, the ITGI helps ensure that boards and
executive management have the tools and
information they need for IT to deliver against
expectations.
International Compliance The International

Standards Organization (ISO) produces
international standards such as ISO 27002.
iView Tivoli Compliance Insight Manager Web

user interface for compliance reporting.
Internet Engineering Task Force

(IETF) develops and promotes Internet standards,
cooperating closely with the W3C and ISO/IEC
standard bodies; and dealing in particular with
standards of the TCP/IP and Internet protocol suite.
ISACA See Information Systems Audit and Control
Association.
ISO Name generally applied to quality system
standards published by the International
Organization for Standardization. ISO certification is
provided, on a fee basis, by third party assessors or
registrars through an on-site, in-depth audit to
determine that a company's quality system meets
the requirements of the standard.
JAAS See Java Authentication and

Authorization Service.
Java Authentication and Authorization Service
(JAAS) is a set of APIs that enable services to
authenticate and enforce access controls upon
users. It implements a Java technology version of
the standard Pluggable Authentication Module
(PAM) framework, and supports user-based
authorization.
Log Chunk The set of events placed in the Depot
by the collect mechanism.
Log Collection Event Each instance of collecting
an audit trail, or log chunk, from an audited machine
is called a log collection event.
ISO 27002 See SO/IEC 17799.
460
Log Continuity Report Tivoli Compliance Insight

Manager report that documents log continuity
status.
Log Manager Tivoli Compliance Insight Manager
centralized log collection, management, and
reporting interface. The Log Manager is only
available on the Enterprise Server.
Logs and Audit Trails The system records that
documents all activity that occurred on the audited
machine.
Management Console Enables you to load data
into the databases, add new audited machines and
event sources, configure collection and reporting
schedules, and add and configure users.
Metadata Information about a particular data set
which may describe, for example, how, when, and
by whom it was received, created, accessed, and/or
modified and how it is formatted. Some metadata,
such as file dates and sizes, can easily be seen by
users; other metadata can be hidden or embedded
and unavailable to computer users who are not
technically adept. Metadata is generally not
reproduced in full form when a document is printed.
National Institute of Standards and Technology
(NIST) A unit of the US Commerce Department.
Formerly known as the National Bureau of
Standards, NIST promotes and maintains
measurement standards. It also has active
programs for encouraging and assisting industry
and science to develop and use these standards.
7530glos.fm
Payment Card Industry Data Security Standard

(PCI DSS) . It was developed by the major credit
card companies as a guideline to help organizations
that process card payments prevent credit card
fraud, hacking and various other security issues. A
company processing, storing, or transmitting credit
card numbers must be PCI DSS compliant or they
risk losing the ability to process credit card
payments.
PCI DSS See Payment Card Industry Data
Security Standard.
Point of Presence The server where the

Actuator is installed is referred to as a Point of
Presence (POP).
Policy A set of one or more compliance queries
used to demonstrate the level of adherence to
specific security requirements.
Policy Bundle A file containing the information
associated with a policy, such as the compliance
queries, the collectors, and the associated
schedules. A policy bundle permits the policy to be
saved and subsequently applied to other servers.
Policy Exceptions Actions or network activity that
violates company policy.
Policy Generator Tivoli Compliance Insight
Manager tool that can be used to create policies
using existing logs to set a baseline for acceptable
network activity.
NIST See National Institute of Standards and

Technology.
Policy Rules is a Tivoli Compliance Insight

Manager tool that helps a user to generate
automatically a set of policy rules or extend an
existing policy rule set.
Normalization The process of standardizing log

data by describing them in a single, uniform
language.
PoP See Point of Presence.

Proxy Relay A special pull client that acts as a
relay between the server and one or more clients. A
proxy relay is used to reach a limited number of
clients that are located behind a firewall, or that are
in an IP-address range that is not directly
addressable by the server.
Glossary
461
7530glos.fm
Proxy Server A server that acts as an intermediary
between a workstation user and the Internet so that
the enterprise can ensure security, administrative
control, and caching service. A proxy server is
associated with or part of a gateway server that
separates the enterprise network from the outside
network and a firewall server that protects the
enterprise network from outside intrusion.
Pull Client A client that permits communication
with the server to be initiated by only the server.
Push Client A client that permits communication
with the server to be initiated by either the client or
the server.
PuTTY is a free software SSH, Telnet, rlogin, and
raw TCP client. It was originally available only for
Windows, but is now also available on various Unix
platforms.
Regulatory Compliance Refers to systems or
departments at corporations and public agencies to
ensure that personnel are aware of and take steps
to comply with relevant laws and regulations.
Remote Collect Agentless log collection facilitated
by SSH or by NetBIOS for Windows.
Risk Management In a broad sense, to assess,

minimize, and prevent negative consequences
posed by a potential threat. The term risk
management has significantly different meanings
that can affect Data Governance programs. At an
enterprise level, risk refers to many types of risk
(operational, financial, compliance, etc.); managing
risk is a key responsibility of Corporate Boards and
Executive Teams. Within financial institutions (or in
the context of a GRC program), risk management
may be a boundary-spanning department that
focuses on risk to investments, loans, or mortgages.
At a project level, risk management is an effort that
should be undertaken as part of project
management, focusing on risks to the successful
completion of the project. From a
compliance/auditing/ controls perspective, risk
assessments and risk management are high-effort
activities included in the COSO, and COBIT
frameworks and required by Sarbanes-Oxley and
other compliance efforts. Data governance
programs may be asked to support any of these risk
management efforts, and may need input from these
efforts to resolve data-related issues.
Role Based Access Control Assigns users to
roles based on their organizational functions and
determines authorization based on those roles.
Risk is the product of the level of threat with the

level of vulnerability. It establishes the likelihood of a
successful attack.
Risk Assessment is the process by which risks
are identified and the impact of those risks
determined.
462
7530glos.fm
Sarbanes-Oxley Act (SOX) is legislation enacted

in response to the high-profile Enron and WorldCom
financial scandals to protect shareholders and the
general public from accounting errors and fraudulent
practices in the enterprise. The act is administered
by the Securities and Exchange Commission (SEC),
which sets deadlines for compliance and publishes
rules on requirements. Sarbanes-Oxley is not a set
of business practices and does not specify how a
business should store records; rather, it defines
which records are to be stored and for how long. The
legislation not only affects the financial side of
corporations, but also affects the IT departments
whose job it is to store a corporation's electronic
records. The Sarbanes-Oxley Act states that all
business records, including electronic records and
electronic messages, must be saved for not less
than five years. The consequences for
non-compliance are fines, imprisonment, or both. IT
departments are increasingly faced with the
challenge of creating and maintaining a corporate
records archive in a cost-effective fashion that
satisfies the requirements put forth by the
legislation.
Security audit is a systematic evaluation of the

security of a company's information system by
measuring how well it conforms to a set of
established criteria. A thorough audit typically
assesses the security of the system's physical
configuration and environment, software,
information handling processes, and user practices.
Security audits are often used to determine
regulatory compliance, in the wake of legislation
(such as HIPAA, the Sarbanes-Oxley Act, and the
California Security Breach Information Act) that
specifies how organizations must deal with
information.
Scoping Enables you to define limited access for

certain users or for certain groups of users.
Sensitive Information As defined by the federal

government, is any unclassified information that, if
compromised, could adversely affect the national
interest or conduct of federal initiatives.
Secure Shell (SSH) is a network protocol that

allows data to be exchanged over a secure channel
between two computers. Encryption provides
confidentiality and integrity of data. SSH uses
public-key cryptography to authenticate the remote
computer and allow the remote computer to
authenticate the user, if necessary.
Security Controls are individual security

requirements that are categorized into
security-related areas. Different organizations must
demonstrate the implementation of the security
controls through a formal audit process to achieve
the respective certification required.
Sensitive Data Data that is private, personal, or
proprietary and must be protected from
unauthorized access.
Server A system where audit data is collected

and investigated using Tivoli Compliance
Insight Manager.
Shell A Unix term for the interactive user interface
with an operating system. The shell is the layer of
programming that understands and executes the
commands a user enters. In some systems, the shell
is called a command interpreter.
Simple Mail Transfer Protocol (SMTP) is the de
facto standard for e-mail transmissions across the
Internet.
Glossary
463
7530glos.fm
Simple Network Management Protocol
(SNMP) Defined by the Internet Engineering Task
Force (IETF). SNMP is used by network
management systems to monitor network-attached
devices for conditions that warrant administrative
attention.
Threat A potential for violation of security, which

exists when there is a circumstance, capability,
action, or event that could breach security and
cause harm.
Threat Assessment is the identification of types of
threats that an organization might be exposed to.
SMTP See Simple Mail Transfer Protocol.

Snapshot The result of running all of the
compliance queries in a policy against a set of
clients. A snapshot shows the number of violations
and indicates what clients are not adhering to the
security requirements being tested by the
compliance queries.
SNMP See Simple Network Management
Protocol.
Tivoli Compliance Insight Manager Cluster The

combination of a Enterprise Server, one of the
Standard Servers, and a collector in a network
deployment.
Tivoli Compliance Insight Manager Server A
generic term referring to the Tivoli Compliance
Insight Manager engine that collects, and
normalizes log data using the W7 methodology.
There are two types of Tivoli Compliance Insight
Manger servers, Enterprise and Standard.
SOX See Sarbanes-Oxley Act.

Special Attentions Actions or network activities
that may not violate company policy but are
suspicious and require additional attention.
SSH See Secure Shell.
Standard Server The Tivoli Compliance Insight
Manager server collects, archives, and normalizes
log data, and generates reports.
Standard Server The Tivoli Compliance

Insight Manager server that collects, archives
and normalizes log data and generates
reports.
Syslog is often used for both the actual syslog
protocol, as well as the application or library sending
syslog messages. Syslog is typically used for
computer system management and security
auditing.
Tivoli Compliance Insight Manager Suite. Refers

to the entire Tivoli Compliance Insight Manager
application. This includes the Tivoli Compliance
Insight Manager server, Point of Presence, Analysis
Engine, Web Portal, iView, Log Manager, and the
Compliance Modules.
Tivoli Compliance Insight Manager Web
Portal Tivoli Compliance Insight Manager single
sign-on interface provides access to iView, the
Policy Generator, Log Manager (only on the
Enterprise Server), Scoping, and Compliance
Modules.
UTF-8 See 8-bit UCS/Unicode Transformation
Format.
Vulnerability A flaw or weakness in a system's
design, implementation, or operation and
management that could be exploited to violate the
system's security policy.
Target System A system to which Tivoli

Compliance Insight Manager receives access
to the audit data.
464
7530glos.fm
W7 Attributes The following list shows the basic

W7 attributes:
1. Who Which user or application initiated the
event?
2. What What kind of action does the event
represent?
3. When When did the event occur?
4. Where On which system did the event happen?
5. OnWhat What was the object (file, database,
printer) involved?
6. Wherefrom From which system did the event
originate?
7. WhereTo Which system is the target or
destination of the event?
W7 Methodology Tivoli Compliance Insight
Manager patent-pending normalization
methodology, which translates log files into an
English-based language of who, what, on what,
when, where, where from, and where to.
World Wide Web Consortium (W3C) is the main
international standards organization for the World
Wide Web (W3).
XML See Extensible Markup Language.
Glossary
465
7530glos.fm
466
7530bibl.fm
Related publications
The publications listed in this section are considered particularly suitable for a
more detailed discussion of the topics covered in this book.
IBM Redbooks
For information about ordering these publications, see How to get Redbooks on
page 469. Note that some of the documents referenced here may be available in
softcopy only.
Deployment Guide Series: IBM Tivoli Security Compliance Manager,
SG24-6450-00
Enterprise Security Architecture Using IBM Tivoli Security Solutions,
SG24-6014-04
Understanding SOA Security Design and Implementation, SG24-7310-01
Deployment Guide Series: IBM Tivoli Compliance Insight Manager,
SG24-7531-00
Deployment Guide Series: IBM Tivoli Security Operations Manager 4.1,
SG24-7439-00
Building a Network Access Control Solution with IBM Tivoli and Cisco
Systems, SG24-6678-01
Accounting and Auditing on AIX 5L, SG-6396-00
Other publications
These publications are also relevant as further information sources:
IBM Tivoli Compliance Insight Manager Installation Guide Version 8.0,
GI11-8176-00
IBM Tivoli Compliance Insight Manager User Guide Version 8.0,
SC23-6544-00
IBM Tivoli Compliance Insight Manager User Reference Guide Version 8.0,
SC23-6545-00
Addional IBM Tivoli Compliance Insight Manager related manuals:
467
7530bibl.fm
IBM Tivoli Basel II Management Module Installation Guide Version 8.0,

GI11-8177-00
IBM Tivoli GLBA Management Module Installation Guide Version 8.0,
GI11-8178-00
IBM Tivoli HIPAA Management Module Installation Guide Version 8.0,
GI11-8179-00
IBM Tivoli ISO17799 Management Module Installation Guide Version 8.0,
GI11-8181-00
IBM Tivoli Sarbanes-Oxley Management Module Installation Guide Version
8.0, GI11-8180-00
IBM Tivoli Security Operations Manager related manuals:
IBM Tivoli Security Operations Manager 3.1 Installation Guide
IBM Tivoli Security Operations Manager 3.1 Administration Guide
IBM Tivoli Security Operations Manager 3.1 User Guide
Online resources
These Web sites are also relevant as further information sources:
IBM Software support Web site
http://www.ibm.com/software/support
To find more information about Basel II check out this URL:
http://www.bis.org/publ/bcbsca.htm
To find more information about the Sarbanes-Oxley Act check out this URL:
http://www.soxlaw.com/
To find more information about PCI check out this URL:
https://www.pcisecuritystandards.org/
To find more information about HIPAA check out this URL:
http://www.hhs.gov/ocr/hipaa/
IBM Training and certification Web site
http://www.ibm.com/software/sw-training/
468
7530bibl.fm
How to get Redbooks

You can search for, view, or download Redbooks, Redpapers, Technotes, draft
publications and Additional materials, as well as order hardcopy Redbooks, at
this Web site:
ibm.com/redbooks
Help from IBM

IBM Support and downloads
ibm.com/support
IBM Global Services
ibm.com/services
Related publications
469
7530bibl.fm
470
7530IX.fm
Index
A
access rights 34
action
Security Operations Manager 373
Active Directory
audit policy settings 161162
diagnostic logging 164
event source 157
event source configuration 179
Actuator 28, 59, 80, 82
data collection 40
installation 185
script 32, 40, 42
software 32
System Z 318
administrative accounts 152
Agent 32
activation 34
collection mechanism 41
encrypted communication 41
agentless
collect 40
collection for UNIX 44
collection for Windows 43
collection mechanism 43
aggregated data 35
aggregated information 15
aggregation
database 35, 38, 57
process 35, 38, 57
AIX
audit subsystem 246
log management 245
login files 245
alert 54
attention rule 214
analyzing trends 238
anomalous activity 115
antivirus
application 114
service 5
API
Windows event management 83

arbitrary log data 45
architecture 13
SIEM 15
archival 75
archiving 97
attack 114, 400
Attack Detection Rule 400
attention
alert 259, 270, 424425
event 55
report 48
rule 34, 52, 194, 202, 212
Oracle 278
SAP 284
System Z 350
audit
AIX subsystem 246
concerns 74
configuration 81
data collection 249
data collection approach 245
data storage 35
database 119
events 373
log for SAP 279
log information 380
network appliance 84
policy 106
policy for Oracle 275
policy for Windows 2003 Server 161
portal 434
requirements 28
settings 7475, 143
System Z settings 311
trail 5, 34
collect command 42
trail data 47
trail for Oracle 272
W7 information translation 48
auditable event 373
auditctl.log 96
audited
machine 42, 50
471
7530IX.fm
add to system group 173
AIX 251
data collection 39
registration 172
system 32, 40
auditing
AIX 245
Domino 262
Oracle 272
SAP 279
System Z 307
automated processes 37
awareness programs 55
B
Basel II 4, 6, 289, 345, 451
compliance management module 303, 309
reporting goals 148, 160
reports 352
System Z compliance 345
batch collect 39
BBBin.log 96
brute force attack 290, 296
BS7799 453
BS7858 453
business
assurance 113
conduct guidelines 4
context 3
data 152
objectives 133
requirements 138
scenario 129
tasks 21
C
central dashboard 28
centralized
forensics 31
log management 30, 95
CFR 21 Part 11 451
change management 22
activities 53
CheckPoint OPSEC 115
Chief Financial Officer 119
Chief Information Officer 119
Chief Information Security Officer 119, 122, 134
chunk 39, 42, 82
472

archiving 42
continuity report generator 95
GEM data translation 47
indexing 45
cluster 315
scalability 99
scenario configuration 153
CMS 389
screen 389
Server 19
COBIT 57
collect
manual command 42
mechanism 81
process 37, 39
schedule 42, 89, 94, 181, 321
script 381
strategy
System Z 331
collection
depot 35
schedule 97
types 74
Commerical Laws 6
Common Criteria 452
communication
chunk data 42
encrypted channel 41
encryption 32
compliance 138
architecture 13
breaches 400
console 297
criteria 10
dashboard 124, 225
initiative 113
maintenance 10
management 4
business drivers 5
challenges 10
criteria 7
module 58, 302
monitoring 134
report 22
rule 401
scope of checking 8
Security Operations Manager report 373
solution design 23
Compliance Insight Manager 18, 25

architecture 28, 36
Audit Logger 376
cluster 30
Collect Script 381
components 27
integration with TSOM 372
component architecture 36
components 27
comprehensive reporting 116
computational correlation 109
configuration
data 36
database 36
consolidated
data 35
log management 31
viewing 28
consolidation
database 36
job 95
process 38
Consolidation Server
configuration 159
consolidation.log 96
continuous
collection of logs 39
correlation 15, 18, 113, 115, 120
engine 109
cost
business requirement 142
pressure 10
CSV log files 59
custom alerts 55, 428
customized report 290
D
daily verification report 234
dashboard 28, 36, 57, 106, 157, 225, 444
log continuity 99
data
aggregation 57
basic collection approach 245
collection 89
collection methods 39
collection task 94
compression 108
consolidation 57
integrity 139
7530IX.fm
investigation 39
longterm storage 36
mining 116
database
administrator 122
check 89
manual load 219
store 35
define users 34
Depot 35, 37, 108
collection 39
indexing 45
log continuity report 95
weekly check 90
depth of reporting 8
design objectives 145
detailed investigation report 236
deterministic threat analysis 109
device events 21
discovery and analysis 74
distribution of reports 58
Domino
Administration Requests Database 262
attention alerts 270
journaling 267
log management 262
policy violations 267
DR550 97
duration check 8
E
encrypted channel 41
encrypted communication 32
Enterprise Server 28, 30
forensic tools 46
installation 159
job schedules 95
Point of Presence 80
synchronization task 94
European Data Directive 95/46/EC 454
event
attributes 60
collection 15, 108
correlation 120
detail report 52
repository 388
source 14, 40
Index
473
7530IX.fm
sources 18
type 14, 19
Event Aggregation Module 410
event source
Active Directory 157
adding an ... 179
AIX 250
configuration 171
Domino 262
Oracle 274
SAP 281
exception report 48
exceptions 35
Extensible Markup Language
see XML
external
auditor 122
external API
event collection 40
F
failures 35
file based
collection of log data 45
filter 48, 56
firewall 114
forensic
activity 82
analysis 39, 111112
capability 45
function 30
investigation 56
review 28
tools 46
Format Verification tools 71
four eyes principle 5
frequency of checks 8
FTP
collect 83
functional design 73, 78
functional requirements 139
G
Gartner 16
GEM 28, 374
data normalization 47
database 35, 37, 75, 383, 394
... for System Z 316
474

consolidation job 95
creation 172
load problems 90
mainmapper log files 94
grouping events 51
loading the database 48
records 48
tables 48
Generic Event Model
see GEM
Generic Mapping Language 47
Generic Scanning Language 45, 47
GLBA 57, 111
compliance management module 303
GML
see Generic Mapping Language
Gramm-Leach-Bliley Act 452
group
definition customization 207
groups 50
GSL
see Generic Scanning Language
H
harmful security event 54
Health Insurance Portability and Accountability Act
451
help-desk ticketing systems 116
heterogeneous environment 85
HIPAA 6, 58
historical log data 138
historical reporting 116
I
IBM
Method for Architecting Secure Solutions
see MASS
SIEM solution 17, 108
IBM System Storage DR550 97
see Compliance Insight Manager
IBM Tivoli Security Compliance Manager
see Security Compliance Manager
IBM Tivoli Security Operations Manager
see Security Operations Manager
identity
revalidation process 22

impact correlation 110
implementation 74, 86
approach 148
process 73
incident
detection 115
handling 114
management 22, 120
mitigation time 116
tracking 114
indexer 95
indexing
process 38
Industry Regulation 6
information retention 97
Information Security Policy 19
install.log 96
internal
auditor 122
misuse 114
intrusion detection system 114
investigation 290
tools 116
ISO17799 5758, 309, 451, 453
ISO27001 453
ISO27002 453
IT
security 118
policies 148
strategy 23
iView 28, 32, 34, 88, 351, 434
Compliance Dashboard 225
compliance dashboard 157
event detail report 52
logs 97
report generation 34
Reports 233
trends 238
L
large deployment 86
legal obligations 9
level
of automation 9
of reporting 8
liability 447
line of business security 118
7530IX.fm
Linux
SSH collect 83
Syslog receiver 83
load period 394
load schedule 94, 183
log
aggregation 114
analysis 114
collection 99, 112
continuity 31
continuity dashboard 99
continuity report 112
generator 95
continuous collection 39
correlation 114
data 97
data capturing 15
depot 108
event collection 40
historical data 138
history 31
management 31, 112, 120
management for AIX 245
management for Domino 262
management for Oracle 272
management for SAP 279
management for System Z 307
management portal 108
manager 88
script 379
logging
requirements 28
IT security policy 148
standards 111
login files
AIX 245
Logon Failure Summary report 235
logon policies 55
logs 96
longterm storage 36
M
Magic Quadrant for Security Information and Event
Management 16
mainmapper
log files 94
mainmapper-.log 96
Index
475
7530IX.fm
maintain compliance 58
maintenance
compliance 10
malware 114
managed security services 25, 117
management charts 35
Management Console 28, 3233, 36, 82, 98, 157,
345
manual
collect command 42
mapper 50, 55
mapping
process 37, 46
MASS 78
medium deployment 85
meta
event 400, 403
information 48
misconfiguration 114
monitor compliance 58
monitored environment 22
monitoring 15, 87
requirements 101
MTP 115
multivendor environment 114
N
NetBIOS
agentless collection 4344
event collection 40
network
administrators 122
analysis 106
appliance auditing 84
availability 113
models 78
operations 122
security devices 104
traffic 112
zones 81
non-functional requirements 87, 145
non-repudiation 304
normalization
W7 data 50
normalized audit data 35
normalized log data 28
normalizing
GEM data 48
476

Novell
O
ODBC
event collection 40
OnWhat 49
operational efficiency 74
operational requirements 87
Oracle
attention rule 278
audit policy 275
data collection 40
event source 274
log management 272
Orange book 452
organizational
complexity 9
level design 23
level security control 5
P
password
length 5
patch management 22
PCI 6, 111, 119
people events 20
performance efficiency 10
plugger.log 96
Point of Presence 33, 40, 81, 83, 245
Domino 262
Enterprise Server 80
Oracle 274
port configuration 177
SAP 281
policies and standards 10
policy
attention report 48
breach detection rule 401
breach on AIX 259
compliance management 104
corporate 447
definition
exception report 48, 202
exceptions 226, 444
exceptions for AIX 258
framework 4

generation tool 56
generator 88
group 439
management 52
mapping
results 219
reporting 123
rule 52, 194, 202, 210
System Z 349
violation 115, 373, 400, 406
violations in Domino 267
POP
see Point of Presence
portal
logs 96
practices 4, 449
preparation of reports 34
priority requirements 101
privileged accounts 152
privileged user access 138
Privileged User Monitoring and Audit 26
problem management 22
procedures 4, 449
process
aggregation 38, 57
changes 14
collect 37, 39
consolidation 38
indexing 38
level design 23
level security control 5
mapping 37, 46
reporting 57
processes 22
processing creditcard information 6
product support 100
product use 74, 87
project
definition and planning 74, 77
management tasks 21
proof of concept 383
PUMA 26, 74
reporting 75
PuTTY 381382, 412
SSH for Windows 44
7530IX.fm
R
RACF 314
raw
data 97
event data
mapping 50
log data 45
traces 31
real time
correlation 18, 120
event collection 112
record oriented
Redbooks Web site 469
Contact us xiv
regulatory
changes 13
compliance 74, 104, 138
reporting 303
obligations 9
requirements 22, 137, 148
remote
data collection 43
report
distribution 95
generation task 94
policy exception 48
reporting 120
customized 290
database 35
detailed investigation 236
iView 233
Logon Failure Summary 235
policy exception 202
process 57
requirements 74, 101, 160, 309
reports 22, 357
Request for Proposal 22
restart task 95
restart.log 96
retention of records 108
retention policy 108
RFP 22
risk
assessment 74, 106, 147
management 6
role 20
root cause analysis 290
Index
477
7530IX.fm
rule-based correlation 109, 115
S
SAN 75, 86, 97
SAP
attention rules 284
audit log 279
event source 281
log management 279
Sarbanes-Oxley 4, 5758, 119, 401
Sarbanes-Oxley Act 22, 451
scalability 99
scenario
business objectives 133
business requirements 138
cluster configuration 153
compliance monitoring 134
design objectives 145
functional requirements 139
high level design 153
implementation approach 148
IT environment 130
regulatory requirements 137
reporting requirements 160
scope of compliance checking 8
secure connection
SSH 43
security
administrator 122
architecture 78
clearance 55
compliance 5
compliance architecture 13
compliance monitoring 134
controls 45, 8
dashboard 124
devices 104
domain 79
incident 113
incident management 106
incident response capabilities 15
log 39
operations center 107
operations dashboard 120
operator 106
Oracle log 40
policies 5
478

policy 19, 22, 34, 74, 113
compliance management 14, 104
policy exception 55
policy framework 4, 9
policy reporting 372
policy rules 55
practices 4
procedures 4
risk 4
standard 20
standards 4, 20
technical team 120
threats 123
Security Compliance Manager 24
Security Event Management
see SEM
Security Information and Event Management
see SIEM
Security Information Management
see SIM
Security Operations Manager 18, 25, 84, 105
action 373
Attack Detection Rule 400
audit events 373
audit information 400
Collect Scripts 380
Compliance Rule 401
correlation 400
dashboard 106
deployment options 117
Event Aggregation Module 410
event collector 25
event source 383
integration with TCIM 372
Log Script 379
managed security services 117
operational integration 116
Policy Breach Detection Rule 401
policy violation 406
reporting 116
rule 373
syslog data 410
Universal Collection Module 424
W7 event record 373
self audit 144, 239
SEM 14, 104
market definition 17
separation of duty 5
server

log files 96
service
assurance 113
service level reporting 106
service oriented architecture
see SOA
severity level 55
shadow system 133
SIEM 14, 104, 388
architecture 1516
integration benefits 372
integration scenarios 122
log analysis 109
log collection 108
solution 111
solution architecture 21
SIM 14, 104
Simple Mail Transfer Protocol
see SMTP
Simple Network Management Protocol
see SNMP
small deployment 84
SMF data 318
SMTP
alerting 55
SNMP 113, 115
alerting 55
collection 83
event collection 40
Snort
event 413
logs 416
SOA
compliance challenge 10
Solaris 75
solution
architecture 21
constraints 75
design 73
Sourcefire eStreamer 115
SOX 22, 111
special attention 229
spot check 8
SSH 380
7530IX.fm
audit data collection 249

collection 83
event collection 40
staging directory 385
Standard Server 19, 28, 30, 32
Configuration Database 36
forensic tools 46
installation 160
log files 96
W7 rules configuration 194
standards 449
statistical
correlation 110, 115
database 35
overview 57
Storage Area Network
see SAN
Sun Solaris
data collection 40
event source 40
support 100
susceptibility correlation 115
suspicious activity 116
syslog 113, 115
collection 83
conduit 410
consolidator 410
daemon 410
data 410
data collection 99
event collection 40
events 18
syslog-ng 83, 410
configuration 411
system group 173
system level design 23
System Management Facilities 312
System Z
Actuator 318
Agent installation 320
attention rule 350
audit settings 311
Basel II compliance 345
collect schedule 321
collect strategy 331
Index
479
7530IX.fm
event source 330
log management 307
LPAR recommendations 321
policy rule 349
reporting requirements 309
SMF data 318
systematic attack detection 290
V
Virtual IP Addressing 327
virtual private network 32, 114
vulnerability
correlation 115
management 106
W7
target
system 22
user 22
tasks 94
tcimlogger script 400
technical
direction 13
security control 5
tasks 21
technological complexity 9
technology changes 14
text based
threat
analysis 109
assessment 106
management 14, 104
threshold event 292
ticketing system 116
Tivoli Compliance Insight Manager 57
Tivoli Enterprise Console 116
Tivoli Omnibus 116
trending information 35
trends 238
U
ubiquitous log collection 44
UK Data Protection Act 1998 454
Universal Collection Module 424
installation 428
UNIX
SSH collect 83
user behavior 20
User Information Source 194
UTF-8 encoding 68
480
analysis 46
attention rule 212
attributes 48
categories 57
category 57
classification scheme 48
Classification Template 348
data store 35
dimension 60
dimensions 374
format 57, 59
grammar 50
grouping functions 48
groups 50, 52, 157, 194, 202, 355
language 28, 438
log event format 59
log event sources 59
methodology 71
model 46, 49
parameters 375
policies 48
policy rule 210
rules
configuration 194, 202
W7LogSDK 59, 373, 393
collect custom log data 45
CSV format 67
Format Verification tools 71
toolkit 27
XML format 68
Web portal 28, 88
logs 96
Web-based reporting application 32
What 49
When 49
Where 49
WhereFrom 49
WhereTo 49
Who 49
7530IX.fm
Windows
audit subsystem 75
event management API 83
Windows 2003 Server
audit policy 161
wizard 388
work policy
creation 202
worm
detection event 401
propagation attempt 402
X
XML 115
log file 59, 70
Z
z/OS 124
log 124
Index
481
7530IX.fm
482
483
(0.5 spine)
0.475<->0.875
250 <-> 459 pages
(1.0 spine)
0.875<->1.498
460 <-> 788 pages
(1.5 spine)
1.5<-> 1.998
789 <->1051 pages
7530spine.fm
smooth which has a PPI of 526. Divided 250 by 526 which equals a spine width of .4752 . In this case, you would use the .5 spine. Now select the Spine width for
the book and hide the others: Special>Conditional Text>Show/Hide>SpineSize(-->Hide:)>Set . Move the changed Conditional text settings to all files in your
book by opening the book file with the spine.fm still open and File>Import>Formats the Conditional Text Settings (ONLY!) to the book files.
Design Guide with IBM Tivoli
Compliance Insight Manager
Compliance Management Design Guide with

Compliance Management Design Guide with IBM Tivoli
Compliance Management Design Guide with IBM Tivoli Compliance
(0.2spine)
0.17<->0.473
90<->249 pages
484
(2.5 spine)
2.5<->nnn.n
1315<-> nnnn pages
7530spine.fm
smooth which has a PPI of 526. Divided 250 by 526 which equals a spine width of .4752 . In this case, you would use the .5 spine. Now select the Spine width for
the book and hide the others: Special>Conditional Text>Show/Hide>SpineSize(-->Hide:)>Set . Move the changed Conditional text settings to all files in your
book by opening the book file with the spine.fm still open and File>Import>Formats the Conditional Text Settings (ONLY!) to the book files.
Compliance
Management Design
Guide with IBM Tivoli
Compliance
Management Design
Guide with IBM Tivoli
(2.0 spine)
2.0 <-> 2.498
1052 <-> 1314 pages
Back cover
Design Guide
with IBM Tivoli Compliance Insight Manager
Enterprise
integration for
operational and
regulatory
compliance
In order to comply with government and industry regulations

such as Sarbanes Oxley, Gramm-Leach-Bliley and COBIT,
enterprises have to constantly detect, validate, and report
unauthorized change and out-of-compliance actions within
their IT infrastructure.
INTERNATIONAL
TECHNICAL
SUPPORT
ORGANIZATION
Complete
architecture and
component
discussion
The Tivoli Compliance Insight Manager solution allows

organizations to improve the security of their information
systems by capturing comprehensive log data, correlating
this data through sophisticated log interpretation and
normalization, and communicating results through a
dashboard and full set of audit and compliance reporting.
BUILDING TECHNICAL
INFORMATION BASED ON
PRACTICAL EXPERIENCE
Deployment scenario
with hands-on
details
We discuss the business context of security audit and

compliance software for enterprises, and describe the logical
and physical components of Tivoli Compliance Insight
Manager. Finally, within a business scenario we discuss a
typical deployment.
This book is a valuable resource for security officers,
administrators, and architects who wish to understand and
implement a centralized security audit and compliance
solution.
IBM Redbooks are developed by

the IBM International Technical
Support Organization. Experts
from IBM, Customers and
Partners from around the world
create timely technical
information based on realistic
scenarios. Specific
recommendations are provided
to help you implement IT
solutions more effectively in
your environment.
For more information:

ibm.com/redbooks
SG24-7530-00
ISBN

Attachment 14105966 Design Guide PDF

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Attachment 14105966 Design Guide PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Front cover

Draft Document for Review November 3, 2007 12:04 am

Draft Document for Review November 3, 2007 12:04 am

International Technical Support Organization

Draft Document for Review November 3, 2007 12:04 am

First Edition (July 2007)

Copyright International Business Machines Corporation 2007. All rights reserved.

Draft Document for Review November 3, 2007 12:04 am

Copyright IBM Corp. 2007. All rights reserved.

Draft Document for Review November 3, 2007 12:04 am

3.3 Product processes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Draft Document for Review November 3, 2007 12:04 am

Draft Document for Review November 3, 2007 12:04 am

8.4.3 File server settings - object access auditing . . . . . . . . . . . . . . . . . . 165

Draft Document for Review November 3, 2007 12:04 am

10.1.2 Distributing reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

Draft Document for Review November 3, 2007 12:04 am

12.5.4 Configure Tivoli Security Operations Manager to process custom alerts

Draft Document for Review November 3, 2007 12:04 am

Copyright IBM Corp. 2007. All rights reserved.

Draft Document for Review November 3, 2007 12:04 am

The following terms are trademarks of other companies:

Draft Document for Review November 3, 2007 12:04 am

The team that wrote this book

Copyright IBM Corp. 2007. All rights reserved.

Draft Document for Review November 3, 2007 12:04 am

Draft Document for Review November 3, 2007 12:04 am

Compliance Manager he has specialized in the recent years in implementing,

Draft Document for Review November 3, 2007 12:04 am

Become a published author

Draft Document for Review November 3, 2007 12:04 am

Copyright IBM Corp. 2007. All rights reserved.

Draft Document for Review November 3, 2007 12:04 am

Draft Document for Review November 3, 2007 12:04 am

Business context for

Copyright IBM Corp. 2007. All rights reserved.

Draft Document for Review November 3, 2007 12:04 am

1.1 Introduction to compliance management

Information security defines the level of protection for information assets of an

Draft Document for Review November 3, 2007 12:04 am

information security. Some more information on this discussion can be found in

1.2 Business drivers for compliance management

Chapter 1. Business context for compliance management

Draft Document for Review November 3, 2007 12:04 am

information, most businesses today rely heavily on their information technology

For more information on HIPAA check out this URL: http://www.hhs.gov/ocr/hipaa/

Draft Document for Review November 3, 2007 12:04 am

1.3 Criteria of a compliance management solution

Chapter 1. Business context for compliance management

Draft Document for Review November 3, 2007 12:04 am

Selection of security controls

Draft Document for Review November 3, 2007 12:04 am

Chapter 1. Business context for compliance management

Draft Document for Review November 3, 2007 12:04 am

1.4 Recent challenges for compliance management

Draft Document for Review November 3, 2007 12:04 am

Organizations want to be able to react on indicators that suggest a future

Chapter 1. Business context for compliance management

Draft Document for Review November 3, 2007 12:04 am

Draft Document for Review November 3, 2007 12:04 am

Copyright IBM Corp. 2007. All rights reserved.

Draft Document for Review November 3, 2007 12:04 am