Deployment Guide Series IBM Tivoli Security Compliance Manager Sg246450

Front cover
Deployment Guide Series:
IBM Tivoli Security Compliance Manager

Business context and legal compliance discussion Best practices in a banking customer scenario Complete deployment guide with hands-on
Axel Buecker Hendrik H. Fulda Dieter Riexinger
ibm.com/redbooks
International Technical Support Organization Deployment Guide Series: IBM Tivoli Security Compliance Manager August 2005
SG24-6450-00
Note: Before using this information and the product it supports, read the information in Notices on page vii.
First Edition (August 2005) This edition applies to Version 5, Release 1, Modification 0 of IBM Tivoli Security Compliance Manager (product number 5724-F82).
Copyright International Business Machines Corporation 2005. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Part 1. Architecture and design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Chapter 1. Business context for security compliance management . . . . . 3 1.1 Introduction to compliance management . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Why compliance management? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3 Determining the how: influencing factors . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4 General challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.5 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Chapter 2. Tivoli Security Compliance Manager design and structure . . 11 2.1 Logical component architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.1.1 Data collection components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.1.2 Compliance evaluation components . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.1.3 Compliance report components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.1.4 Security Compliance Manager server . . . . . . . . . . . . . . . . . . . . . . . . 25 2.1.5 Administration components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.2 Physical component architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.2.1 Communication port usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.2.2 Deployment on physical nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.3 Security Compliance Manager walkthrough . . . . . . . . . . . . . . . . . . . . . . . 32 Chapter 3. Architecting a Security Compliance Management solution . . 49 3.1 Solution architectures, design, and methodologies. . . . . . . . . . . . . . . . . . 51 3.2 Design process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.2.1 Typical context of Security Compliance Manager solutions . . . . . . . 51 3.2.2 Phased project approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 3.2.3 Placing components in network zones . . . . . . . . . . . . . . . . . . . . . . . 57 3.2.4 Deployment of Security Compliance Manager clients. . . . . . . . . . . . 60 3.2.5 Delegated administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 3.2.6 Implementation of Security Compliance Manager policies . . . . . . . . 65 3.2.7 Integration with access control management systems . . . . . . . . . . . 66
Copyright IBM Corp. 2005. All rights reserved.
iii
3.2.8 Integration with Tivoli Risk Manager . . . . . . . . . . . . . . . . . . . . . . . . . 68 3.3 Business processes and compliance management . . . . . . . . . . . . . . . . . 69 3.3.1 A generic security compliance management business process . . . . 69 3.3.2 Security Compliance Manager business process support . . . . . . . . 71 3.3.3 Automated security compliance management . . . . . . . . . . . . . . . . . 77 Part 2. Customer environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Chapter 4. Armando Brothers Banking Corp.. . . . . . . . . . . . . . . . . . . . . . . 83 4.1 Company profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 4.2 Current IT architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 4.2.1 Existing security infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 4.2.2 Existing middleware infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . 87 4.3 Current security policies and standards . . . . . . . . . . . . . . . . . . . . . . . . . . 87 4.4 Emerging problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 4.5 Strategic objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 4.6 Critical success factors for strategy implementation . . . . . . . . . . . . . . . . . 89 4.7 Resulting business requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 4.8 Requirements on project execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 4.9 ROI study and results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Chapter 5. Security Compliance Manager design . . . . . . . . . . . . . . . . . . . 95 5.1 Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 5.1.1 Phase I: Establishing a baseline . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 5.1.2 Phase II: Extend coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.2 Design objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.2.1 General and infrastructure objectives . . . . . . . . . . . . . . . . . . . . . . . 100 5.2.2 Platform specific security concepts . . . . . . . . . . . . . . . . . . . . . . . . . 101 5.3 Implementation architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 5.3.1 Physical components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5.3.2 User roles and responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 5.4 Project organization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Chapter 6. Technical implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 6.1 Deployment phase I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 6.1.1 Planning and installing the server . . . . . . . . . . . . . . . . . . . . . . . . . . 117 6.1.2 DB2 maintenance tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 6.1.3 Deploying clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 6.1.4 Installing the reporting server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 6.1.5 Configuring operational reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 6.2 Deployment phase II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 6.2.1 Tivoli Access Manager integration . . . . . . . . . . . . . . . . . . . . . . . . . 146 6.2.2 Tivoli Risk Manager integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 6.2.3 Collector development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
iv
Deployment Guide Series: IBM Tivoli Security Compliance Manager
6.2.4 Report development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 6.3 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Part 3. Appendixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Appendix A. Developing a custom collector . . . . . . . . . . . . . . . . . . . . . . 173 Required method getReleaseNumber() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Required method getCompatibleOS() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Required method getDescription() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Required method getParameters(). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Required method getTables(). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Required method executeV2() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Appendix B. Introducing the Security Vulnerability Index . . . . . . . . . . . 179 So what is the IBM Global Services Vulnerability Index? . . . . . . . . . . . . . . . . 180 How does it work? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 Appendix C. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Contents
vi
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 illustrates 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. 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 IBM's application programming interfaces.
vii
Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both: AIX 5L Eserver Tivoli Enterprise AIX IBM Tivoli Enterprise Console DB2 Universal Database ibm.com Tivoli DB2 Redbooks Eserver Redbooks (logo) The following terms are trademarks of other companies: Crystal Reports, and Crystal Enterprise are trademarks or registered trademarks of Business Objects SA or its affiliated companies in the United States and other countries Java, JDBC, JVM, Solaris, Sun, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Excel, Microsoft, Natural, Windows NT, 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, and service names may be trademarks or service marks of others.
viii
Preface
The process that ensures that the security policies and standards of a company are adhered to is called compliance management. It requires the ability to report on the current compliance status of the security controls of any installed system and to react to any observed deviations. Most businesses today heavily rely on their IT systems, and damage incurred to their critical systems through downtime can force a company out of business. It is a good business practice to minimize the risk to IT systems in proportion to their importance to the business. The factors that influence how much compliance you need can be based on economical, technological, regulatory, or legal reasons. This IBM Redbook discusses the business context for security compliance management. It introduces the logical and physical components of Tivolis solution offering. We explain the planning steps and describe how to deploy IBM Tivoli Security Compliance Manager (ITSCM) Version 5.1 in a banking environment and how to integrate it with IBM Tivoli Access Manager and IBM Tivoli Risk Manager.
The team that wrote this redbook

This redbook was produced by a team of specialists from around the world working at the International Technical Support Organization, Austin Center.
ix
Figure 1 From left: Dieter, Axel, and Hendrik
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 18 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. Hendrik H. Fulda is a certified IT Strategy Consultant and currently holds a position as Managing Consultant in IBM Strategic Outsourcing. Having performed several engagements identifying information security risks and applying processes and technology to improve security, Hendrik has a strong background in Information Security and Security Architecture. He has published on the topic of e-business security and is a frequent speaker at industry conferences around Europe. Hendrik is a teacher of the IBM Method for Architecting Secure Solutions and holds an ISACA.org credential as a Certified Information Security Manager. Hendrik joined IBM in 1998 and lives in Hamburg, Germany.
Dieter Riexinger is a Certified IT Security Architect in IBM Germany. He holds a degree in Computer Science from the University of Mannheim, Germany. He has more than 13 years of experience mainly in Networking and IT Security disciplines. His areas of expertise include User Management, IBM Tivoli Access Manager, and IBM Tivoli Security Compliance Manager. Dieter has managed various design and architecture engagements for complex IT infrastructures. Thanks to the following people for their contributions to this project: Wade Wallace International Technical Support Organization, Austin Center Mike Garrison, Tom Ballard, Lakshmi Thiruvengada, James Galvin, John Giammanco IBM US
Become a published author

Join us for a two- to six-week residency program! Help write an IBM Redbook dealing with specific products or solutions, while getting hands-on experience with leading-edge technologies. You'll team with IBM technical professionals, Business Partners, and customers. Your efforts will help increase product acceptance and customer satisfaction. As a bonus, you'll develop a network of contacts in IBM development labs, and increase your productivity and marketability. Discover 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 Redbooks to be as helpful as possible. Send us your comments about this or other Redbooks in one of the following ways: Use the online Contact us review redbook form found at:
ibm.com/redbooks
Send your comments in an e-mail to:

redbook@us.ibm.com
Preface
xi
Mail your comments to: IBM Corporation, International Technical Support Organization Dept. JN9B Building 003 Internal Zip 2834 11400 Burnet Road Austin, Texas 78758-3493
xii
Part 1
Part
Architecture and design

In this part, we discuss the overall business context of the IBM Tivoli Security Compliance Manager. We then describe how to technically architect the overall solution into an existing environment, and introduce the logical and physical components.
Chapter 1.
Business context for security compliance management

In this chapter, we discuss the business context for security compliance management of IT systems. After a short definition of security compliance management, 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.
1.1 Introduction to compliance management

The process that ensures that the security, regulatory, and operational policies of a company are adhered to is called compliance management. It requires the ability to report on the current compliance status of security controls of any installed system and to react to any observed deviations. Security controls exist on a technical, process, and organizational 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 will enforce this control. A more complex technical security control can be the requirement to run an anti-virus service (with up to date virus definition files, of course!) on a computer system or a correctly configured portfilter. While it can be hard to have process level or organizational level security controls checked automatically (by a computer), technical security controls can be automatically monitored, as this only requires collecting configuration parameters (for example, minimum password length) and comparing these with predefined desired values. IT security compliance management is about ensuring that the defined settings (in a security policy or standard) are implemented correctly and consistently on all the installed IT systems. Because in practice there can be reasons why a specific configuration setting cannot be enforced in the desired way on a number of systems of each type (usually due to an application either explicitly requiring the parameter to be set differently or because it is simply not working otherwise) a significant part of compliance management is handling exceptions to the defined security policy or standard.
1.2 Why compliance management?

Most businesses today heavily rely on their IT systems, and damage incurred to their critical systems through downtime can force a company out of business. It is a good business practice to minimize the risk to IT systems in proportion to their importance to the business. Through regulation (for example, Basel II1 in the banking sector), the excellence of risk management for IT systems, which is part of the operational risk complex, even has an impact on the competitive advantage of banks because it can affect the interest rates a bank can offer its customers. Because the configuration of security relevant settings in an operating system has a direct impact on the resilience of the system against attacks, viruses, worms, or computer criminals, ensuring that these settings are always at the desired level directly lowers the risk to the system. No large enterprise (and, often, not even small enterprises), in order to protect their business investment, would publicly admit that they fell victim to a virus or worm incident, although even with relatively high level of security measures in place no one can be absolutely safe. And because these incidents cannot (and therefore should not!) be ruled out, you should present as little a target as reasonably possible. Reasonably here being relative to the values to protect and the amount of threats in the environment. Note: In some places, companies are legally required to publicly disclose all incidents. 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 middleware, or due to an attacker changing the configuration to hide his tracks or to compromise the system.
Basel II: International Convergence of Capital Measurement and Capital Standards: a Revised Framework, June 2004 (more information can be found at http://www.bis.org/publ/bcbs107.htm.)
Chapter 1. Business context for security compliance management
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 that). In control: You know what is in compliance and what is not, you know why,
and you have a plan of action. 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.
1.3 Determining the how: influencing factors

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. Frequency of checks How often is a compliance check being done? This does not only define how often the configuration data is collected from the systems, but also the frequency in which system administrators are called upon to fix or investigate identified deviations. Number and selection of controls Which and how many controls are checked? Are only operating system level controls checked or are application level controls checked as well? Which operating systems, middleware, and business applications need to be supported? Follow up time frame How fast do you have to fix reported deviations in the security configuration?
Organizational and process checkpoints There is a particular need for separation of duties, for example, when the employee checking the configuration must not be the administrator of the system, and for process requirements, especially in the area of exception management and escalation if deviations are encountered or not corrected in time. The factors that define how much compliance management, as defined by the dimensions above, has to be done are influenced by the threats in the external environment of a company. Let us summarize the external environment factors. Economy In which industry is the business operating? Is corporate espionage an issue? Does the company use outsourcing services? How dependent is the business on its IT systems? Regulatory/legal compliance In which countries and in which industry is the business operating? Which regulatory requirements exist that have an influence on required operational risk and the level of IT security? What level of scrutiny is executed by the regulators? It is useful to keep in mind that an IT security compliance management system can provide a lot of evidence for executed control. Technology The main reason why IT security compliance management is a good security practice today and should even be considered a mandatory task when using IT systems at all is that businesses usually cannot afford successful attacks against their IT infrastructure. The threats against IT systems have become so advanced that one does not even have to have enemies to become subject to an attack, because many attacks are done automatically by worms and viruses. Even if critical systems are not directly compromised, a single infected system in a company network will negatively affect other systems and incur costs for the clean up. Next, let us look at the internal environment factors of a company. Business and IT processes The value and amount of (business) information processed defines the level of security the processing system requires. And because security is always about the weakest link, related infrastructure systems need to be protected reasonably too. Organization The size and setup of the organization, for example, defines 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. Technology/existing IT environment Obviously, the existing IT environment defines the scope of the operating system, middleware, and business applications that need to be supported by any IT security compliance management solution. In mature businesses, these influencing factors have shaped the existing security policies and standards as well as work practices or procedures: Security Policy Non platform specific or high level security requirements Security Standards Platform specific controls (for example, configuration settings) Practices/Procedures Platform specific or non-specific descriptions on how to implement the security controls, for example, process steps, required documentation templates, and so on Further, these may have resulted in the IT department defining or creating the following tools to consistently implement the given standards and practices: Standard image/build Pre-configured installation image of an operating system with the correct settings applied. Checklists Configuration or system activation checklists for configuration settings or tasks that cannot be predefined using an image. Checklists usually exist for all sorts of IT assets, from physical servers and clients with their respective operating system builds, to applications and complex environment configurations.
1.4 General challenges

Now, even if the goal for security compliance is clear, defined by precise policies and standards (which often do not exist or are worded in broad, technically vague terms), the task of compliance management of 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. Complex environments 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.
1.5 Conclusion
As a result of the influencing factors discussed above, a security compliance management solution must provide a flexible framework that can be configured and customized to the specific business in question. However, requirements for compliance management often result in functional or non-functional requirements for the technical solution and for the processes and organization behind the solution. Let us look at a few examples. A high frequency of compliance checks reduces the window of opportunity for a potential attack/incident because the time frame that a vulnerability exists because of a control deviation is reduced. If the solution and the process to notify the system administrator is not automated properly, a lot of effort may be wasted in checking the reports that are generated in fast order. A centrally maintained system for gathering and processing the compliance data lowers the cost of maintenance when compared to a distributed system. However, it should be ensured that (the distributed) system administrators have direct access to the data of their systems to easily control the status of their system, for example, after a change. The need to request the information from a central team would be a burden on the central team and discourage the system administrator from proactive checks.
As a consequence, the compliance management solution must allow for fine grained access control definitions so that system administrators are limited to the data on their systems only. While the ability to collect data on as many controls on as many platforms as possible sounds like the number one priority for a compliance management system, it should not be underestimated how important the reporting capabilities can be, especially if reports on the compliance status are required for legal/regulatory and audit purposes. Perhaps most important, it is necessary to realize that business as usual for compliance management systems is the management of exceptions from the defined standards (for example, because of conflicts with applications). Therefore, effective and efficient exception management should be on the top of the list of requirements for a compliance management solution. At the end of the day, security is about the weakest link and, because of this, it is more important to have a consistent (if small) set of security controls in place on all the operated systems in a company, controlled through a reliable process in a reasonable time frame, than monitoring a hundred controls on a few systems in headquarters whenever someone feels like it.
10
Chapter 2.
Tivoli Security Compliance Manager design and structure

IBM Tivoli Security Compliance Manager is IBMs security policy compliance management product that acts as an early warning system by identifying security vulnerabilities and security policy violations for small, medium, and large businesses. Tivoli Security Compliance Manager helps organizations define consistent security policies and monitor compliance of these defined security policies. This chapter provides you with an understanding of the following topics: The high level logical component architecture for IBM Tivoli Security Compliance Manager The physical component architecture A complete Tivoli Security Compliance Manager walkthrough, from client registration to re-establishing compliance of a managed system.
11
2.1 Logical component architecture

The logical components of IBM Tivoli Security Compliance Manager may be grouped in five different areas of responsibility, with the Security Compliance Manager server being the central component, as depicted in Figure 2-1 on page 13. The areas are: Data collection components that build a framework for collecting security relevant configuration data from connected systems, such as operating systems, middleware components, applications, and so on. Administration components consisting of a graphical user interface and a command line interface are used to manage the Security Compliance Manager components. Compliance reporting components deliver different kinds of configurable reports for audit purposes and correcting deviations. Compliance evaluation components consisting of Security Compliance Manager snapshots and policies verify security compliance centrally. Both components are stored and maintained in the central database in order to ease the process of policy maintenance. The Security Compliance Manager server is the central component of a Security Compliance Manager infrastructure. Among the responsibilities of the server are: Manages when the security compliance data is collected and which clients collect what kind of data using the data collection components. Determines what security compliance data is collected, and how to interpret the data using the compliance management components. Stores the security compliance data received from the clients and provides the available data to users through the administration console and administration commands. Provides security violation details as a basis for the compliance report components. The following sections describe the components of the five layers in more detail.
12
Compliance Report Components
ITSCM Report
ITSCM Operational Report
ITSCM Admin GUI Administration Components
ITSCM Snapshots
ITSCM ITSCM Server Server
ITSCM Database
Compliance Evaluation Components ITSCM Policies
ITSCM Admin CLI ITSCM Client ITSCM ITSCM ITSCM Collector Collector Collector Windows Registry Configuration File Executable Firewall Data Collection Components ITSCM Proxy ITSCM Client ITSCM ITSCM Collector Collector Router
Figure 2-1 IBM Tivoli Security Compliance Manager logical component architecture
2.1.1 Data collection components

The data collection components are mainly responsible for collecting compliance data according to a schedule provided by the Security Compliance Manager server. One of the data collection components (the client) needs to be initially deployed to the systems that are to be monitored, either manually or by any other established means of software distribution in your environment. From that moment on, all components are centrally maintained using the Security Compliance Manager server management functions.
Chapter 2. Tivoli Security Compliance Manager design and structure
13
The data collection components are: Client Collector Proxy relay
Security Compliance Manager client

The client is Java language-based software that runs on systems to be monitored for security compliance. By default, the client runs as a daemon with root authority on UNIX systems, or as a service under the local system account on Microsoft Windows systems. The client provides the runtime environment for collectors deployed to the system and handles communication with the server. The type of client determines how communications are initiated between the server and the client. There are two types of clients: a push client and a pull client. A push client can establish a Secure Sockets Layer (SSL) connection to the server and send data. A pull client must wait until the server establishes a persistent SSL connection with the client before data can be sent. Defining a client as a push client, which is the default, permits communication with the server to be established by either the client or the server. In some network environments, however, inbound connections to the server are not permitted. In these cases, defining the client as a pull client forces the server to initiate the communication with the client. Pull clients are generally needed when the server is located behind a firewall. Client-server communication on page 15 provides a detailed description of the concept of push/pull clients.
Security Compliance Manager clients and client groups A client group is a container used to group one or more clients together. Clients
can be members of one or more client groups. A client group itself can be a member of one or more client groups, though care should be used when nesting groups because of the way inheritance works, which is described in Group inheritance on page 14. A client must be a member of a client group in order for a policy to be applied to the client. A policy can be assigned only to a client group. Individual collectors can be assigned to both clients and client groups. Objects added to a client group are inherited by all members of the group. The client group concept supports organizing large numbers of clients into categories representing operating system types, security policies, physical location, business objectives, or any other logical grouping. You can manage the control of groups using client group access permissions. Each user can be assigned specific permissions to control and manage specific client groups.
Group inheritance
Adding policies and collectors to client groups is a powerful feature because of group inheritance. Every client that is a member of the client group, or a member of a subgroup of the client group, inherits the collectors and policies added to the group. Adding a collector to a client group adds a collector instance, with the
14
same schedule and parameters, to every client that is a member of the client group or a member of any nested group. Similarly, adding a policy to a client group adds collector instances for every collector used in the policy to every client that is a member of the client group or a member of any nested group. The schedule and parameters for each collector instance are set in the policy and the same values are used for each client. You can take advantage of this collector inheritance by adding policies and individual collectors to a small set of groups, rather than adding them to large numbers of individual clients. Inheritance permits a large number of clients to run the same set of collectors using the same parameters at the same scheduled times. When a policy or a collector is removed from a client group, all related collector instances and any collected data are removed from all the clients in the client group and all the clients in any nested subgroups. Similarly, removing a client from a client group results in the collector instances, and any collected data that was collected as a result of a policy or collector added at the group level, to be removed as well.
Client-server communication
Clients can be categorized into one of three types. Table 2-1 describes the client types.
Table 2-1 Security Compliance Manager client types Client type Push client Description The push client permits communication with the server to be initiated by either the client or the server. Usually, the push client establishes an SSL connection to the server and sends data or asks for updates. The server only establishes a connection if an administrator forces an action to be performed on the client using the administration tools. Push is the default method to connect clients, as it requires less resources on the server. A pull client must wait until the server establishes a persistent SSL connection with the client before data can be sent. There are two situations requiring pull clients: The pull method allows clients to connect to a server, which is located behind a firewall that denies incoming connections. Clients located behind a Security Compliance Manager proxy relay need to be configured as pull clients. The pull mode operation uses more resources on the server.
Pull client
15
Client type DHCP push client
Description A DHCP push client has a dynamic IP address that permits communication with the server to be initiated by either the client or the server. This option is used for systems that frequently change their host name or IP address. The general communication for the DHCP push client works just like the regular push client; the difference is the DHCP push client establishes the SSL connection.
After a connection between the client and the server has been made, either can send data to the other. Clients contact the server at periodic intervals called a heartbeat, which is every 10 minutes by default, to check for updates. During this heartbeat, the client receives any new or updated collectors from the server, along with any new or updated collector schedules and parameters. The client component software itself can be sent by the server and the client updates itself and restarts. This client/server heartbeat can be initiated from the administration console using the soft reset request function, bringing a client into sync without explicitly waiting for the heartbeat. Data gathered by the collectors that have run on the client is queued for delivery to the server on a more frequent basis, which is every minute, by default. Each client is uniquely identified to the server using a client identification (CLI_ID) number.
Securing the Security Compliance Manager client

The client is designed to provide a maximum level of security. It provides the following security features: Temper resistance The Security Compliance Manager client is designed as a self-contained component. Each client contains its own Java Virtual Machine (JVM). For all operating system platforms other than HP-UX and NetWare, the JVM is automatically installed under the Security Compliance Manager client's base install directory. The JVM for HP-UX has to be added after the Security Compliance Manager installation. Access to the client files requires root access rights on the system in order to prevent misuse. This is extremely important if the client is installed on critical systems like firewalls. Secure communication The client establishes communication links with the Security Compliance Manager server based on the servers SSL certificate and IP address. Any other communication requests are denied. This assures that only the authorized Security Compliance Manager server is able to perform configuration requests like collector deployment or schedule changes. The server presents its SSL certificate during the first communication with the
16
client (first contact trust). This certificate is used to verify the servers unique identity and to encrypt all traffic within the Tivoli Security Compliance Manager environment.
Collector
A collector is a Java language-based software module, packaged as a Java Archive (JAR) file, that collects specific information from a client system. A collector is designed to have a short execution time and to be non-invasive. The collector may use different methods for collecting data depending on the compliance data to be gathered: Reading the content of one or more files on the client system. Running an operating system command or utility and examining the output. Running an executable program packaged as part of the collector JAR file and examining the output. Reading information from the registry on Microsoft Windows systems. Remotely logging in to another system and gather data. This method allows you to collect security compliance data from systems that do not support Java applications. Figure 2-2 on page 18 depicts the concept of Security Compliance Manager collectors. The first time a collector is deployed to a client, the JAR file for the collector is sent from the server to the client, along with the collector schedule and any associated parameters (1). Multiple instances of a collector can be deployed to a client. Subsequent instances of the collector share the same JAR file, but run on their own schedule and with their own parameters. Each instance of a collector is uniquely identified by a collector instance number (INSTANCE_ID). According to its schedule, the collector starts to read security compliance data from its corresponding data source, for example, the Windows Registry (2). Data collected by each collector instance is queued by the client and delivered to the server on a periodic basis, by default every minute (3). Delivery of collected data is determined by two configurable settings in the client.pref file: flush.interval (the default is 60 seconds) and flush.threshold (the default is 100 messages). The collected data is not stored on disk, but kept in memory until the connection to the server is established. The server stores the information received from the client into one or more tables in the database. The data in the database table is uniquely identified by the client identification number (CLI_ID) and the collector instance number (INSTANCE_ID) (4). When a collector instance is removed from a client, any data associated with that instance of the collector is removed from the database tables by the server.
17
ITSCM Client win.any.local_group.jar
ITSCM Server
4
ITSCM Database
Windows Registry CLI_ID INSTANCE_ID LOCAL_GROUP USERID LOGDATE 1219 27 Administrators Axel 2004-09-27 18:44:17.0 1219 27 Guests Hendrik 2004-09-27 18:44:17.0 1219 27 Guests Dieter 2004-09-27 18:44:17.0
Figure 2-2 Security compliance data stored in collector-specific database tables
Securing the collector system

The Security Compliance Manager collector system provides security features to prevent unauthorized manipulation of deployed collectors and the deployment of collectors that are not appropriate for a particular environment. Figure 2-3 on page 19 shows the signatures that are requested by a Security Compliance Manager client before it accepts any collectors: IBM (origin) certificate (IBM) The IBM collector certificate is included with Security Compliance Manager. This certificate is used by both the client and the server to verify that collectors were provided as part of an official IBM product. The IBM private key is not supplied with the product. This behavior is configurable in the Security tab of the Security Compliance Manager administration console. The IBM certificate prevents unauthorized third-party or malicious collectors from being used. Alternatively, you can use your own certificate for signing collectors. Collector authorization certificate The authorization root certificate is generated at installation time and protected by the server password. It is used to create authorization certificates (AC). Authorization certificates are used to digitally sign collectors that can be registered on the server. The authorization certificate allows constraints to be placed on the administrators by restricting the collectors they can load to a known set of collectors. Clients use certificates created with the authorization root certificate to verify that the collectors they receive were sent from the server. This certificate limits the collectors that an administrator can load to a designated subset and prevents the administrator from using IBM signed collectors that are not appropriate for a particular deployment.
18
Unsigned collectors collector Collectors signed with IBM certificate denied ITSCM Client Collectors signed with IBM and authorization certificates IBM collector AC collector IBM
accepted
Figure 2-3 Required collector certificate
Proxy relay
The IBM Tivoli Security Compliance Manager proxy relay provides a solution for the scenario of a server separated from destination clients by one or more intermediary networks because of firewall policies or address space concerns. The goal of the proxy relay is to permit the server to successfully connect to and communicate with each destination client system. Figure 2-4 on page 20 illustrates that any Security Compliance Manager client may be used as a proxy relay if a special collector called com.ibm.jac.server.JACProxy.jar is added to the Security Compliance Manager client using the Security Compliance Manager administration tools. The proxy relay collector permits a client to act as an intermediary, or proxy, between the server and a number of clients behind a firewall. The collector does not collect data in the usual sense, but does gather statistics on the clients using the proxy relay and the amount of data being transferred.
19
ITSCM Server
ITSCM Client com.ibm.jac.server.JAC Proxy.jar
ITSCM Client win.any.local_group.jar
Windows Registry
Figure 2-4 Security Compliance Manager client configured as proxy relay
Securing the proxy relay system

The proxy collector is a special collector that permits a client to act as an intermediary between the server and other clients. This function is useful in situations where direct communication between the server and clients might be impossible due to firewall policies or address space issues. Because the proxy relay can also be used to bypass a sites security, the proxy relay must possess a method to prevent abuse. The proxy relay enforces a security policy through the use of configurable Access Control Lists (ACLs). An Access Control List is a security method that uses a set of rules to determine which resources can be accessed by whom and from where. The proxy relay uses two ACLs, one to regulate incoming traffic, and one to regulate outgoing traffic. Each of these ACLs consists of a list of IP addresses and ports. Details on how to configure ACLs for proxy relay communication can be found in Chapter 15, Installing and using proxy relays, in the IBM Tivoli Security Compliance Manager Version 5.1 Administration Guide, SC32-1594.
2.1.2 Compliance evaluation components

Security Compliance Manager compliance evaluation components extract the data collected, analyze the data for non-compliance, and provide the input for reports in order to reveal adherence to internal and industry-standard security policies.
20
Security Compliance Manager policy

A Security Compliance Manager policy consists of one or more specially written SQL queries that are used to reveal compliance or violation of system security requirements. The combined results of all the queries in the policy indicate the level of adherence to the security policy. Policies can be applied to one or more client groups. Each SQL query in a policy is called a compliance query. A compliance query extracts, from one or more collector tables, data specifically collected for the compliance query, analyzes that data, and then returns the list of clients that are in violation of that specific security requirement. A compliance query is created to return a list of violations. The results of all the compliance queries associated with a policy can be used to provide a picture, or snapshot, of the level of compliance for all clients in a client group. The results of the compliance queries directly depend on the data extracted from the collector tables. When a policy is added to a client group, all the collectors required by the policy are added to the client group and inherited by all the member clients and client groups. The clients must run these collectors and return the data back to the server before the policy can produce meaningful snapshot reports. A policy consists of: One or more compliance queries One or more collectors that might have parameters and a default schedule associated with them A schedule for when a snapshot should be taken and sent to a set of e-mail addresses Policies are created using the Policies page of the administration console. After a policy has been created, it can be exported to a special binary file called a policy bundle. The policy bundle contains everything needed to re-create the policy: the compliance queries, the collectors, including their authorization keys, the default collector schedules, and any collector parameters. The maximum data size associated with the collector tables is saved also. The policy bundle does not contain information regarding the snapshot schedule. Importing a policy bundle on the same or a different server results in the collectors being installed with their default schedules and parameters, only if the collectors are not already installed, and the compliance queries are made available. Also note that more recent versions of collectors that might already be present on a server are not replaced by collectors bundled with the policy. Before a policy can be used, the collectors associated with the policy might need to be signed with one or more authorization keys. All the collectors must be registered. To authorize the collectors, if necessary, use the Collectors page of the administration console, or the scmsignpolicycollectors command. To register the collectors associated with a policy, use the Collectors page or the scmregisterpolicycollectors command.
21
Security Compliance Manager snapshot

A snapshot provides the compliance status of all client systems that are associated with a policy. Security Compliance Manager creates a snapshot by running all the compliance queries in a policy against all clients associated with the policy. The snapshot content consists of the output of the SQL compliance queries. Security Compliance Manager saves the results of a snapshot in the Security Compliance Manager database for further processing. Users may view the snapshot results using the Security Compliance Manager administration tool, or send the results to one or more e-mail addresses. Security Compliance Manager snapshot administrators can create snapshots on a scheduled basis, or can produce snapshots on demand using the administrative utilities. Archiving the results of snapshots on a regular basis can be used to show compliance with both internal security requirements, as well as industry-standard or governmental security and privacy requirements, over a period of time.
2.1.3 Compliance report components

Security Compliance Manager compliance report components provide the report capabilities that help reveal adherence to internal and industry-standard security policies. There are three types of reports provided by Security Compliance Manager. 1. Using the Reports Panel in the admin GUI, you can schedule queries and generate reports. 2. You can create snapshot reports (from scheduled snapshots). 3. You can use Crystal Reports (which include operational reports and historical reports).
Security Compliance Manager report

Tivoli Security Compliance Manager provides a reporting capability in the administration console. Each report contains the result of a single snapshot and lists the violations and the corresponding client details, as depicted in Figure 2-20 on page 48. A Security Compliance Manager administrator can schedule a report to run on a periodic basis and configure Security Compliance Manager to automatically send the results to specified e-mail addresses.
Security Compliance Manager operational reports

Security Compliance Manager provides operational reports for security compliance reporting. Operational reports require Crystal Enterprise, a server-based infrastructure for report delivery. Figure 2-5 on page 23 depicts the process of report creation and which Crystal products are involved. The Crystal Enterprise administration guide is included with the installation media in the
22
subdirectory \doc. Additional information can be found at http://www.businessobjects.com/products/platform/enterprise.asp.

report development Design GUI Report Developer Crystal Reports save report templates Operational Report Operational operational Report report template Crystal Enterprise import report templates publishing reports Web Interface Report User
Figure 2-5 Security Compliance Manager report development using Crystal products
Business Objects, the company that created Crystal Reports and Crystal Enterprise, offers different product suites. According to Business Objects, the baseline product is Crystal Reports, which is associated with report development. The report developer uses Crystal Reports for creating database connections, selecting database records, and designing new reports. The reports can then be saved to file as report templates and imported into Crystal Enterprise. Crystal Enterprise consists of multiple server components that provide the ability to schedule the creation of reports, to manage users and user groups, to configure security settings, and to organize reports using report folders. Crystal Enterprise publishes the reports using a Web interface. Note: If you do not have a Crystal Enterprise server in your environment you can also use a regular HTTP server to publish the results, such as the IBM HTTP Server.
23
Security Compliance Manager provides the following operational report templates (the latest additions and documentation on reports can be found in the IBM Tivoli Security Compliance Manager Version 5.1 Fix Pack 5.1.0-TIV-SCM-FP0009 February 18, 2005 Operational Reports Reference): 1. Administrative Activity Displays a history of the administration activities that were performed by users. 2. Changes to Roles and Permissions Displays a history of changes to the definitions for roles and permissions. 3. Client Group Membership Displays information about client groups and their members. 4. Client Violations Displays the policies and their latest snapshots. This report includes the details for all the violations associated with a client. Figure 2-6 on page 25 shows an example report. 5. Collector Run Information Displays information about previous runs of collectors. 6. Compliant and Non-compliant Systems Displays the systems that are compliant with the defined security policy as well as systems that are not in compliance. 7. Policy Import Time Displays the names and descriptions of all the policies that have been imported. 8. Policy Violations Trends Displays the violation information associated with all the policies. 9. Roles and Permissions Information This report displays information about the roles and permissions that are assigned to users. 10.Snapshot Creation Completion Displays the times that each snapshot associated with the policies were created. 11.User Group Membership This report displays information about user groups and their members.
24
Figure 2-6 Example for operational report: Client Violations
2.1.4 Security Compliance Manager server

The server is Java language-based software that centrally manages all data associated with Tivoli Security Compliance Manager. By default, the server runs as a daemon with root authority on UNIX systems and as a service running as the local system account on Microsoft Windows systems. The Security Compliance Manager server is the central component of a Security Compliance Manager infrastructure and manages compliance report components, compliance evaluation components, and data collection components. The Security Compliance Manager administrators and users
25
access the Security Compliance Manager server functions using the administration tools. 2.1.5, Administration components on page 28 describes the administration tools and the server functions in detail. 2.3, Security Compliance Manager walkthrough on page 32 demonstrates how to use Security Compliance Managers administration console in order to perform the administration tasks. The Security Compliance Manager server stores the data associated with the objects being managed in a centralized DB2 relational database. The server is the only Tivoli Security Compliance Manager component that directly accesses the database. Data can be extracted for system analysis, to generate status reports, and, as a preventative maintenance mechanism, to provide status and warning notifications.
Authentication
By default, authentication of users of the administration console and administration utilities is handled by the Tivoli Security Compliance Manager server. User information is stored in the database with the password being stored in MD5 message-digest format. The server does not enforce any password rules or perform any password strength testing and no mechanism exists to recover a forgotten password. Security Compliance Manager provides the option to integrate with any authentication system by offering the authentication interface based on Java Authentication and Authorization Service (JAAS). 3.2.7, Integration with access control management systems on page 66 describes the JAAS interface.
Securing the Security Compliance Manager server

The Security Compliance Manager server manages data, which can be an invaluable source of information for all kinds of intruders. The Security Compliance Manager database contains a list of IT systems, IP addresses, user accounts, configuration options, and much more information, which can provide hints for potential starting points for attacks. Tivoli Security Compliance Manager provides the following features to secure the Security Compliance Manager server and its data: Secured communication between server and administration console The communication between server and administration console is secured by SSL. The administration console verifies the identity of the server based on the server certificate. If the server is contacted for the first time or the servers certificate is renewed, then Security Compliance Manager displays the dialog window shown in Figure 2-7 on page 27. The Security Compliance Manager user may then contact the server administrator to verify that the certificate has changed before accepting the new certificate. This ensures that the Security Compliance Manager user is always talking to the correct Security Compliance Manager server instance.
26
Figure 2-7 Warning that a new Security Compliance Manager server is accessed
Secured communication between server and client The Security Compliance Manager client establishes communication links with the Security Compliance Manager server based on the servers SSL certificate and IP address. Any other communication requests are denied. This ensures that only the authorized server is able to perform configuration requests like collector deployment or schedule changes. The server presents its SSL certificate during the first communication with the client (first contact trust). This certificate is used to verify the servers unique identity and encrypts all traffic within the Tivoli Security Compliance Manager environment. Protecting the database The DB2 database contains valuable information about the IT infrastructure and known vulnerabilities. The node hosting Security Compliance Managers DB2 database system should be placed in a trusted security zone. Additionally, access to the Security Compliance Manager database should be restricted to the absolute minimum. Communications between Tivoli Security Compliance Manager components are secured using 128-bit Secure Sockets Layer (SSL) encryption. The cipher suites used are RSA_WITH_RC4_128_SHA, RSA_WITH_RC4_128_MD5, and RSA_WITH_3DES_EDE_CBC_SHA.
27
2.1.5 Administration components

Administrators and users use the administration components to centrally manage all the other components of the Security Compliance Manager infrastructure. The administration components consist of the Security Compliance Manager administration console and the command line interface (CLI). The following sections describe the administration components.
Administration console
The administration console is the graphical user interface (GUI) used to manage Tivoli Security Compliance Manager servers, clients, collectors, and keystores. The administration console also manages the data collected by the collectors, analyzes that data, and generates reports. The administration console offers functions to perform the following tasks: Manage individual client systems (register and unregister clients) Manage client groups (add and remove groups, and add and remove systems to and from groups) Manage collectors (install collectors, view status, set values for collector parameters, and customize schedules) Manage users (add and remove users, and create and manage user groups and roles) Manage proxy relays (define proxy relays and assign routing paths) Manage database tables (create delta tables and set maximum data age) Manage policies (create, import, and export policies, assign policies to client groups, schedule, run, and view snapshots Manage reports (define reports and run reports) Define and test SQL database queries Manage the server (define authorization keys, view server activity, back up keystores, and manage the database connection)
Command line interface

The command line interface provides an alternative to the administration console and offers a subset of the functions available with the administration console. The command line interface enables the administrator to perform operations on a large number of objects or to automate operations with scripts or batch files. The command line tools are available on all supported platforms.
28
A detailed list of commands, command parameters, and their usage is provided in the IBM Tivoli Security Compliance Manager Version 5.1 Administration Guide, SC32-1594.
2.2 Physical component architecture

In our discussion of Security Compliance Managers logical component architecture above, we have focused primarily on the logical relationships among software components, and not necessarily on the specific system configurations upon which they are installed. In this section, we introduce the physical aspects of Security Compliance Managers components and provide guidelines on how to deploy the software components on physical nodes.
2.2.1 Communication port usage

Our description of Security Compliance Managers logical components shows the server as the central component of a Security Compliance Manager infrastructure. The server communicates with all other components using different protocols. Figure 2-8 on page 30 depicts the default port usage for Security Compliance Manager servers communication links. The direction of the arrows in the diagram indicate the initiator of the communication. The different types of communication links are: From administration tools to server Communications between the administration console or command line interface and the server is based on Remote Method Invocation (RMI). The following ports are used: Administration utility to server: 1955 (RMI-Naming) Between server and push clients The communication can be initiated in two different ways: Client to server using port 1951: Communications between the push client and server is established, if the client wants to transfer collected data to the server. This connection is set up as required and released after the data transfer. Server to client using port 1950: This connection is optional. It is set up only if an administrator executes commands that require communication with the client, for example, if the administrator requests direct execution of a collector. If firewall rules forbid this communication, the functionality of the push client is not affected.
29
Between server and pull clients Communication with a pull client is initiated by the Security Compliance Manager server. The default port for this communication is 1950. This connection is permanent. Between server and proxy relay Communication with a proxy relay is initiated by the server using the default port 1960 on the proxy relay. This connection is permanent regardless of whether the proxy relay is configured as a push or pull client. If configured as a push client, the relay must be connected directly to the server. Between proxy relay and pull clients Communication with a pull client is initiated by the server. The default port for this communication is 1950. This connection is permanent. The proxy relay can only connect to pull clients.
ITSCM Admin GUI
ITSCM Admin CLI
ITSCM Operational Report
1955 RMI Naming 1951 PUSH Clients 1952 JLOG port logcmd
ITSCM Server
ITSCM Database
ITSCM Server
1950 Client port 1953 JLOG port logcmd
1950 Client port 1953 JLOG port
1960 Proxy port logcmd
ITSCM PUSH Client
ITSCM PUSH Client (Proxy)
ITSCM PULL Client
ITSCM PULL Client (Proxy)
ITSCM PULL Client
ITSCM PULL Client
permanent connection temporary connection (required) temporary connection (optional)
Figure 2-8 Communication port usage
30
2.2.2 Deployment on physical nodes

Security Compliance Manager supports different operating systems and configuration options for its server and proxy relay deployment. The following section describes the deployment options and provides some hints for the selection of nodes.
Deployment of Security Compliance Manager server

IBM recommends that you install the Security Compliance Manager server on a system with a high processor speed and ample disk space. The system that contains the server should be solely dedicated to that task. This configuration allows the system to be tuned and optimized for running Security Compliance Manager. This configuration also keeps the server from having to compete with other applications for system resources. The database server serves as the repository for all Security Compliance Manager data. The database server can be deployed on the same system as the Security Compliance Manager server; however, for better performance, the database server should be installed on a separate system. For even better performance, the database server can be installed on a multi-processor machine. The IBM Tivoli Security Compliance Manager Version 5.1 Deployment and Tuning Guide1 provides a formula and examples that describe the throughput calculation for the Security Compliance Manager server hardware: Throughput requirement = Number of clients * Number of collectors * Collector message size / Frequency of data collection The components of the formula are defined as follows: Number of clients The total number of clients connected to the Security Compliance Manager server. Number of collectors The average number of collectors deployed on a single client. Collector message size The average size of the message sent from the data collector to the server. This size should be determined in a test environment or during a pilot phase.
The IBM Tivoli Security Compliance Manager Version 5.1 Deployment and Tuning Guide is available as a part of the IBM Tivoli Security Compliance Manager 5.1 Utilities at http://www-1.ibm.com/support/docview.wss?rs=2004&context=SSVHZU&dc=D400&uid=swg24007082& loc=en_US&cs=utf-8&lang=en.
31
Frequency of data collection Represents the data collection schedule configured for the collectors in the Security Compliance Manager server.
Deployment of Security Compliance Manager proxy relay

The Security Compliance Manager proxy relay is a special collector that routes traffic between the Security Compliance Manager server and clients in different networks. You are not required to set up dedicated systems for the Security Compliance Manager proxy relay functionality. Ideally, existing nodes having enough throughput capacity can be used to route the Security Compliance Manager traffic. The same formula for throughput calculation shown in Deployment of Security Compliance Manager server on page 31 can be used for the Security Compliance Manager proxy relay system. The number of clients used in the formula is the number of clients connected via the proxy relay systems.
2.3 Security Compliance Manager walkthrough

This section provides a complete walkthrough, discussing the steps from Security Compliance Manager deployment planning up to the initial compliance deviation report.
Existing environment and planning

Figure 2-9 on page 33 depicts the given environment, consisting of three network zones, a management network, a production network, and the DMZ. There are different kinds of existing machines that are shown as white boxes. During the planning phase, the project team made the following architectural design decisions: The Security Compliance Manager server and the database will be installed on a dedicated system in the management network because the server is highly critical and the data is considered confidential. Security Compliance Manager clients in the management network are connected as push clients. This reduces the number of permanent connections from the server to the clients. The Security Compliance Manager clients in all other zones will be configured as pull clients due to firewall restrictions. The Security Compliance Manager server uses a proxy relay in the production network to connect to the client in the DMZ. The existing firewall rules require adjustment.
32
The Security Compliance Manager proxy relay is installed on an existing AIX server in order to reduce the need for additional hardware. The following steps are required to install the Security Compliance Manager infrastructure and complete an initial security compliance check.
itsosec3 ITSCM PUSH Client Win2000 itsosec4 ITSCM PULL Client Win2000 itsosec6 ITSCM Server AIX ITSCM Admin GUI
itsosec2 ITSCM PULL Client LINUX
itsosec7 ITSCM PULL Proxy AIX
ITSCM Database DB2
DMZ
Production Network
Management Network
Figure 2-9 Security Compliance Manager deployment example
Database installation
We install IBM DB2 Version 8.1 on AIX using the db2setup utility and create a db2instance called db2inst1. The IBM DB2 Universal Database Installation and Configuration Supplement Version 8, GC09-4837 provides details on how to install and configure DB2. The Security Compliance Manager installation program will create the database and perform the required configuration. For now, it is important to know the user ID and password of the DB2 instance that will be used for Security Compliance Manager.
Security Compliance Manager server installation

We install the Security Compliance Manager server on the same system where we installed the DB2 database. 6.1.1, Planning and installing the server on page 117 provides details on how to install the Security Compliance Manager server. During the installation procedure, we have to specify the DB2 instance ID and password. Security Compliance Manager creates the Security Compliance Manager database JAC, configures the table spaces, and creates and configures
33
all the required tables automatically. During the server installation, we define the user ID admin as the Security Compliance Manager master administrator. Additionally, the Security Compliance Manager server installation procedure installs the Security Compliance Manager administration command line utilities on the same machine. Attention: Before installing any Fix Pack for Tivoli Security Compliance Manager, make sure you have installed any additional Security Compliance Manager components that are needed on the system. For example, after the installation of a Fix Pack, you can no longer install the Security Compliance Manager client.
Security Compliance Manager administration GUI installation

We install the Security Compliance Manager administration GUI on the administrators workplace. The IBM Tivoli Security Compliance Manager Version 5.1 Installation Guide: All Components, GC32-1592 provides details on how to install the administration GUI. After installing the administration console, we can log on to the server.
Policy import
Security Compliance Manager provides basic security compliance policies as a starting point for policy development. These Security Compliance Manager policies can easily be adjusted to a given enterprise security policy. As a first step, we load the security policies for the operating systems in our environment. In our example, we use the CLI command scmimportpolicy to import the policies. The CLI commands are stored in the directory <SCM_HOME>/admin. We have to specify the user ID of the Security Compliance Manager administrator, the password, the Security Compliance Manager server name, the server port, and the name of the policy file. The parameter -r specifies that all collectors are registered automatically during the import process. The following example shows the parameter values used in our example:
scmimportpolicy -u admin -pw password -s scm.itso.austin.com -p 1955 -f /opt/IBM/SCM/policies/System_Windows.pol -r
This command is repeated for all required policies. In the Security Compliance Manager administration console, we see the imported policies under the Policies tab.
Policy development
It is a key task for any security compliance management process to integrate, apply, and maintain a company's security policy. Security policies are living documents that are adapted continuously to a changing environment. As described in 2.1, Logical component architecture on page 12, Tivoli Security
34
Compliance Manager provides an efficient way of integrating and maintaining the security policy by splitting this task into the parts data collection and compliance evaluation. Data collection is the process of gathering current system control settings. Compliance evaluation compares the current system settings to the settings required by the security policy. 6.2.3, Collector development on page 151 describes how to develop collectors gathering additional security related data. In our example, the data collectors provide enough information to implement the basic Security Compliance Manager policy. So we can concentrate on the compliance evaluation part. Tivoli Security Compliance Manager uses compliance objects in order to perform compliance control. Each compliance object consists of a single SQL statement. The SQL statements compare data collected by the Security Compliance Manager collectors with should-be values defined in the security policy. In most cases, changes of the security policy require nothing but adjusting the values specified in the SQL queries. Let us demonstrate the implementation of a specific security policy at the example of Windows 2000. The enterprise security policy in our example requires the settings in Table 2-2.
Table 2-2 Security policy details Control No 1 2 3 4 Control description Minimum password length Maximum password age Antivirus run frequency Security log retention time Required setting Eight characters Three months Weekly 180 days Severity High Normal Normal Low
The following steps show you how to create a new policy based on the policy imported previously: Rename the imported System_Windows policy to Windows2000_Policy using the Security Compliance Manager administration console. Open the Policies folder, right-click the imported System_Windows_Policy, select Rename Policy, and enter the new name Windows2000_Policy. Delete all compliance objects that are not required by our security policy. Figure 2-10 on page 36 shows the remaining compliance objects of the new policy.
35
Figure 2-10 Changing a compliance object
Select the WIN 2K Min Password Length compliance object, as shown in Figure 2-10. The Security Compliance Manager administration GUI shows the corresponding compliance SQL statement in the Compliance SQL area on the right side of the console. Change the password length to 8. Adjust the Item Priority according to the security policy, set the priority to High, and click Save to store the statement. Latest news: Fix Pack 2 introduced an Informational radio button to the Item Priority selection that, if selected, will not add to the violation count for the policy. Modify the other values in the compliance objects, as required by the security policy.
36
Perform the same steps for the other operating systems (AIX and Linux). Now we have a complete set of Security Compliance Manager policies that reflect our enterprise security policy. The final step is to generate a complete policy consisting of Java data collectors and compliance objects. Select the policy Windows2000_Policy, go to the Collectors tab, and click Generate Collector List, as shown in Figure 2-11. Security Compliance Manager now selects all required Java data collectors that are referenced by the compliance objects and creates a complete policy. You can export this policy into a JAR file containing data collectors and compliance objects. Click Save Collector List.
Figure 2-11 Example of collector list generated for a policy
Scheduling policies
For each policy, we assign a schedule that defines when the data collectors should be executed by the Security Compliance Manager clients. The default schedule for the policies executes the collectors daily. To view the current schedule, go to the Policies tab, select one of the policies, and open the Collectors tab on the right. The collectors and their schedules are sorted by compliance queries, as shown in Figure 2-12 on page 38.
37
Figure 2-12 Default collector schedule
The administration console displays collector schedules using horizontal bars. From left to right, the columns represent: Months Days of the month Days of the week Hours Minutes Schedules have a default gray background color. Absolute time specifications are displayed in blue; randomized time specifications are displayed in green. Thus, the collectors shown in Figure 2-12 are scheduled to run every month, on each day of the month and each day of a week at random hours and minutes, which means they run once a day. We adopt this schedule for all collectors in our policies, as it guarantees that not all collectors on all clients will run at the same time, flooding the network and SCM server with data. Another favorable side-effect is that nobody will be able to discover when a collector is collecting data in order to exploit this information.
Client installation
Tivoli Security Compliance Manager uses the InstallShield MultiPlatform (ISMP) tool for installation on all supported client platforms. Through the use of ISMP, a Java-based installation tool, a common look and feel for the installation is provided, regardless of your operating system. Configuration questions are provided by the installation routine, and a simple configuration is performed during the installation to get you up and running quickly. The ISMP tool provides the capability to perform silent installations based on response files. This method
38
shortens the installation time considerably and ensures a homogenous deployment on all systems. For our installation, the response file for the Windows platforms is shown in Example 2-1.
Example 2-1 Sample response file for pull clients on Windows platforms -P -W -W -W -W -W installLocation="C:\applications\SCM setupTypeSelectionPanel.selectedSetupTypeId=clientSetup" clientConfigPanel.clientPort="1950" clientConfigPanel.pushPull="pull" clientServerConfig.serverHostname="" clientServerConfig.serverPort="1951"
Using the response file, the command for client installation is:
scm_win32 -silent -options win_response_file
The installation of a push client on AIX, as required by our deployment plan, requires the following modifications, shown in Example 2-2, to the response file.
Example 2-2 Sample response file for push clients on UNIX platforms -P -W -W -W -W -W installLocation="/opt/IBM/SCM setupTypeSelectionPanel.selectedSetupTypeId=clientSetup" clientConfigPanel.clientPort="1950" clientConfigPanel.pushPull="push" clientServerConfig.serverHostname="itsosec6.itsc.austin.ibm.com" clientServerConfig.serverPort="1951"
Important: ISMP does not report any errors in silent mode. Therefore, if you type any of the options incorrectly, the installation will silently fail or respond unexpectedly. For example, if you are installing in /syslocal/tools/SCM and you were to type the command incorrectly, the component would still be installed in the default directory /opt/IBM/SCM and there would be no error message. Grouping the clients For our example, we define one group for each operating system type: WIN2K_Group Linux_Group AIX_Group We use these groups during the client registration to separate clients and to attach the Security Compliance Manager policies.
39
Client registration
When you start push clients, they try to contact the Security Compliance Manager server. The server does not accept the new clients until the administrator registers them. In order to register new push clients, you have to perform the following steps: 1. Click the Clients tab to go to the Clients page. 2. Right-click in the Groups/Clients window, click Show, and select Show Unregistered Clients. 3. The list of clients that have contacted the server is displayed in a window. Select the client you wish to register and click Register. 4. Verify the host name or the IP address of the client system and click OK. Optionally, you can specify an alias for the client. The alias name is used when displaying the client in the administration console. 5. In the next step, you can select the group where you want to add the client. Pull clients never appear in the Unregistered Clients window. To register the pull clients, which are placed in the Production Network and DMZ, you have to perform the following steps: 1. In the Clients page, right-click in the Groups/Clients window and click Register Client. 2. Specify the host name or the IP address of the client system and click OK. The host name or IP address specified must be addressable or resolvable from the server. Optionally, you can specify an alias for the client. 3. In the next step, you can select the group where you want to add the client. The Security Compliance Manager clients that are connected to the server appear in black in the Groups/Clients window, as shown in Figure 2-13 on page 41. The client placed in the DMZ zone is displayed in grey. This indicates that the client does not have a connection with the Security Compliance Manager server due to firewall restrictions.
40
Figure 2-13 Client groups showing active and inactive clients
Proxy relay installation

Next, we configure the system itsosec7.itsc.austin.ibm.com as the Security Compliance Manager proxy relay in order to connect to systems in the DMZ. For this purpose, we could use any Security Compliance Manager client in this network. The decision should be made based on available computing resources. The system acting as a proxy relay can be either a push client or a pull client. However, a proxy relay behind another proxy relay must be defined as a pull client. The configuration task consists of the following steps: 1. As you configure the Security Compliance Manager proxy relay for the first time, you have to install the proxy collector using the administration console. In the main menu, select Collectors Install Collectors. In the following file selection dialog, select the com.ibm.jac.server.JACProxy.jar that is stored in the directory <SCM_HOME>/collectors. Next, select and register the installed collector in the Collectors window, as shown in Figure 2-14 on page 42.
41
Figure 2-14 Registered Security Compliance Manager proxy collector
2. Add the com.ibm.jac.server.JACProxy.jar collector to the proxy relay system. Right-click the client entry in the Clients window and select the proxy collector from the selection list. Answer the question that asks if you want to change the default schedule with No. The proxy relay collector is now attached to the client itsosec7. Selecting the clients displays the attached collectors in the collectors window, as shown in Figure 2-15.
Figure 2-15 Proxy collector attached to the client
42
3. Next, we want to restrict inbound and outbound traffic through the proxy relay using Access Control Lists (ACLs). Otherwise, no inbound or outbound traffic is permitted through the proxy relay. Right-click the proxy collector and select Edit collector parameters, as shown in Figure 2-15 on page 42. In the next input window, we add the ACL rules shown in Table 2-3.
Table 2-3 ACL rules for proxy relay Input tab Inbound Added line 9.3.5.166/32:1960 Description Specify the Security Compliance Manager server itsosec6 as the only source of requests using port 1960. Specify the DMZ client itsosec2 as the only Security Compliance Manager client to contact using port 1950. By default, the proxy relay listens on port 1960.
Outbound
9.3.4.162/32:1950
Proxy Port
1960
4. Now we have to define the proxy and routing path in the Proxy page of the administration console. The Security Compliance Manager server uses this information to send requests to a client using the correct proxy relay. In the Proxies window, you define the name of the proxy. In this case, we choose the name DMZ Proxy. In the routing path section, we specify the IP address of the proxy relay and the port the proxy relay is listening to. Figure 2-16 shows the created entries in the Proxy page.
Figure 2-16 Definition of a proxy relay
43
5. In the last step, we have to configure the DMZ Proxy as the proxy to be used for the Security Compliance Manager client itsosec2. In the Client information tab, we select the DMZ Proxy from the Proxy drop-down list. Now the itsosec2 client changes to the active state and all clients are displayed as active.
Policy attachment
In a next step, we attach the new policies to the corresponding client group. The collectors associated with the policy are automatically added to the clients in the assigned groups and later run on the schedule defined in the policy. You can add a policy to a client group using the administration console. In the Clients tab, select the client group in the Groups/Clients window, right-click the client group, select Policy Add policy, and select the policy to be added. At the next client/server heartbeat, the collectors associated with the policy are added to the clients in the client group.
Collecting data
After 24 hours, the data collection will be completed. Usually, you want to collect the data immediately to verify the security compliance status of a newly installed client. In this case, open the administration console, select the client or client group in the Groups/Clients window of the Clients tab, right-click the policy in the Policies tab, and select Run policy collectors. Figure 2-17 shows the command to run all collectors in the Windows2000_Policy on all clients of the WIN2K_Group.
Figure 2-17 Collecting data outside the schedule
44
Snapshot creation
After the collectors return the collected data to the server, a snapshot can be created to show the level of compliance of the clients with the security policy. You can create snapshots immediately in the administration console, or schedule snapshots to occur on a regular basis. To immediately create a snapshot, select a group or client in the Groups/Clients window, right-click an attached policy, and select Create Snapshot. After the snapshot is created, a new folder is created under the Snapshot folder in the Policies window. The name of the folder indicates when the snapshot was taken, the number of violations identified, the name of the client group, and if the snapshot was restricted to a specific group. Figure 2-18 shows a snapshot for the group WIN2K_Group.
Figure 2-18 Snapshot and violated compliance objects
Selecting a compliance object under the snapshot displays the violation message and the affected hosts. The color of the compliance objects indicates whether or not violations of the security policy were found and whether violations are being suppressed. We assigned a priority to each compliance object when we defined it. Violations uncovered by the compliance query are shown in different colors to indicate the severity of the violation. The colors of the compliance queries have the meanings shown in Table 2-4 on page 46.
45
Table 2-4 Color coding for violations Color Green Meaning No violations and no suppressions. The WIN2K NAV Run Frequency compliance object has no violations and no suppressions. High priority violation. The WIN2K Min Password Length compliance query is of high priority and has two violations. The number of clients found in violation is indicated by the number in parentheses following the name of the compliance query. Normal priority violation. The WIN2K Max Password Age compliance object is of normal priority and has two violations associated with it. Low priority violation. The WIN2K Security Logs Retention compliance object is of low priority and has two violations.
Bold Red
Red
Orange
Latest news: An additional priority has been introduced with Fix Pack 2. The new priority is called Informational. The color used is blue. Informational compliance queries that fail return blue entries, but the count of Informational violations are not added to the total count of violations for the complete snapshot. Informational is useful when a compliance query is used to return information, but does not really represent a problem, or if a query is turned around to return all systems that are in compliance with some criteria.
Definition of suppressions
A suppression is used to temporarily exempt one or more clients from a compliance query. In our example, the system itsosec3 generates many security related events that are archived daily. Therefore, we want to define an exception for this machine in order to suppress the violations in our security deviation reports. To create a suppression, go to the Policies tab on the administration console and open the policy to display the Compliance Objects, Snapshots, and Suppressions folders. Right-click the Suppressions folder and click Create Suppression. Figure 2-19 on page 47 shows the suppression creation dialog. Enter a name for the suppression in the Suppression name field. The name of the suppression is displayed in the Suppressions window when a violation is suppressed in a snapshot. In the Expiration Date field, we can optionally enter the date when the suppression should expire. If no date is entered, the suppression expires one year from the current date. A suppression is provided to permit only a temporary exemption. Enter a reason for the suppression in the Reason field. The reason is
46
displayed in the Suppressions window to indicate why the specified client is being exempted from a compliance query. Select the client itsosec3 in the Clients field. If required, you could also define a suppression for one or more groups.
Figure 2-19 Suppression for a single client
As a last step, we click Display Query to generate the SQL statement based on the information specified on the window. The resulting SQL is displayed in the SQL Query statement field. The SQL string can be modified as needed. Performing a new snapshot reduces the number of violations associated to the compliance object WIN2K Security Logs Retention to one.
Export report
We can now export the security compliance report to a file in HTML format. Right-click the snapshot and select Export Snapshot to HTML file. The resulting report is shown in Figure 2-20 on page 48.
47
Figure 2-20 Snapshot report window
This concludes our walkthrough for a simple Security Compliance Manager deployment exercise. In the next chapter, we want to take a closer at how to properly architect a more complex deployment scenario.
48
Chapter 3.
Architecting a Security Compliance Management solution

The first part of this chapter describes important topics when planning a security compliance management project using IBM Tivoli Security Compliance Manager. The topics covered by chapter can be used as a check list during the design phase: System context In this section, we define the interfaces of the security compliance management solution and identify the sources that provide the requirements. Project phases This section describes typical project phases and the required skills for the implementation. Component placement This section defines typical network zones and discusses the placement of Security Compliance Manager components.
49
Deployment of Security Compliance Manager clients The client deployment discusses various planning activities during the mass rollout of Security Compliance Manager clients, management of Security Compliance Manager clients, and updating clients. Delegated administration Delegated administration describes Security Compliance Managers capabilities to support a cost effective design of security compliance management processes by delegating tasks to system owners or organizational units. Implementation of policies This section focuses on the necessary criteria to be considered during the decision making process for automating compliance management for specific IT systems and platforms. Integration with access management solutions Security Compliance Manager is able to integrate with access management solutions of multiple vendors based on the Java Authentication and Authorization Service (JAAS) standard. Integration with IBM Tivoli Risk Manager The integration of security compliance management and risk management provides a valuable source of information for decision makers. This section describes the integration options for Tivoli Security Compliance Manager and Tivoli Risk Manager. The second part of this chapter introduces a typical business process for security compliance management and its activities. It demonstrates how Security Compliance Manager supports the different process steps, such as applying the security policy or standards, performing and documenting security compliance checks, managing exceptions, and reporting compliance management results. The last section discusses the consequences of introducing automated compliance management and presents experiences gained in different projects.
50
3.1 Solution architectures, design, and methodologies

The task of developing IT solutions that consistently and effectively apply security principles has many challenges, including the complexity of integrating the specified security functions within the several underlying component architectures found in computing systems, the difficulty in developing a comprehensive set of baseline requirements for security, and a lack of widely accepted security design methods. With the formalization of security evaluation criteria into an international standard known as Common Criteria, one of the barriers to a common approach for developing extensible IT security architectures has been lowered. IBMs Method for Architecting Secure Solutions (MASS) is soundly based on Common Criteria as a comprehensive statement of security requirements, and a systematic approach for defining, modeling, and documenting security functions within a structured design process in order to facilitate greater trust in the operation of resulting IT solutions. More detailed information about MASS may be found in the IBM Redbook Enterprise Security Architecture using IBM Tivoli Security Solutions, SG24-6014. IBM Global Service employees use MASS in security architecture engagements. It helps understand and categorize security related problems and discussions in todays enterprise IT infrastructures. Throughout this redbook, we use MASS guidelines for the design and implementation of our sample projects.
3.2 Design process

This section focuses on Security Compliance Manager specific design process characteristics to support you in planning and setting up a security compliance management implementation project with Tivoli Security Compliance Manager. Chapter 5, Security Compliance Manager design on page 95 describes, in detail, a sample project that implements most of the design aspects introduced in this section.
3.2.1 Typical context of Security Compliance Manager solutions

The first step of the design process is to define the interfaces of the security compliance management solution and identify the source of the requirements. Figure 3-1 on page 52 depicts the typical requirement types.
Chapter 3. Architecting a Security Compliance Management solution
51
Legal & Regulatory Requirements (for example: Sarbanes Oxley Act)
Enterprise Security Policy
Security health check solution
Business Requirements
Existing IT Environment
Figure 3-1 Typical context for a security compliance management solution
Enterprise security policy The enterprise security policy has to define the required settings on all systems, such as operating systems, middleware systems, network devices, and applications, that fall in the scope of the solution. It has to define how often the security compliance checks have to be performed. The policy has to cover all legal and regulatory requirements. Thus, the enterprise security policy is the single source of requirements for the development of compliance objects for the Security Compliance Manager policies.
52
Attention: To start quickly, we recommend comparing the compliance checks that come with Security Compliance Manager out of the box with your existing enterprise security policy and to just customize the individual values (for example, the required password length). We do not always recommend to begin the compliance checking process using all the controls that come with Security Compliance Manager, because they are probably not all used in your enterprise security policy. Since maintaining configuration parameters in the existing IT systems costs resources, it may not be in your interest to fix the configuration settings that are not required by the existing enterprise security policy. But, because the Security Compliance Manager control set is a proven set of configuration settings, we recommend discussing all the controls that come with Security Compliance Manager, even if they are not part of the policy today, with the security policy creators or owners. Business requirements Typical requirements to consider are implementation timelines and project phases, reporting infrastructure, design of the security compliance management process, and integration with existing processes. Existing IT environment Integration with the existing IT environment is an important task in the design process. It comprises integration with an existing authentication and authorization infrastructure, security audit tools like intrusion detection systems, usage of existing systems for deploying security compliance management components, placement of the security compliance management components in security zones, software distribution systems for deploying compliance management components to existing IT systems, and many more aspects.
3.2.2 Phased project approach

If you run a security compliance management project for the first time, there are no inhibitors for a start small, grow fast strategy using Security Compliance Manager. This section discusses typical implementation phases and explains why a phased project approach offers you many advantages. Figure 3-2 on page 54 shows three project phases that you may want to consider.
53
Functionality
Solution Phase 3: Collector development for middleware systems and applications Integration with security audit components
Solution Phase 2: Development of collectors covering the enterprise security policy Adaptation of operational health check reports
Solution Phase 1: Covers Operating Systems supported by Security Compliance Manager No collector development Adaptation of compliance queries Rollout of Security Compliance Manager clients Standard reports
Time
Figure 3-2 Potential project phases
Project phase 1
Project phase 1 should at least include the following activities, which can be started simultaneously: Set up the Security Compliance Manager server infrastructure In 6.1.1, Planning and installing the server on page 117, we explain the required actions to set up a Security Compliance Manager server infrastructure. The server infrastructure is required in order to perform data collection and security compliance control. Rollout of Security Compliance Manager clients on supported operating systems You may roll out the initial Security Compliance Manager client software in the first phase on your existing server infrastructure. Software updates, collectors, and schedules are deployed automatically by the Security Compliance Manager server later when they become available. Client deployment options on page 62 provides a detailed discussion of the Security Compliance Manager client rollout options. Tip: The ability to start your server setup, client rollout, and adaptation of compliance objects in parallel due to the Security Compliance Manager architecture with its integrated collector deployment system can save significant amounts of time.
54
Adaptation of compliance objects In Policy development on page 34, we describe the process of modifying the Security Compliance Manager policies to the needs of your enterprise security policy. Even if the collectors are not sufficient to gather all data required by your policy, you will establish a baseline of security compliance management. This baseline already provides you with a good overview of the security compliance state of your current IT infrastructure. Figure 3-3 on page 57 depicts how the different project phases narrow the gap between security compliance checks stipulated by the enterprise security policy and the actual checks being performed. Utilize the Security Compliance Manager report functionality Apply Security Compliance Manager reports for routine or ad-hoc reports or set up a Crystal Enterprise environment to exploit the operational reports. Setting up at least a reporting infrastructure using the reports provided by Security Compliance Manager is a must in order to implement a complete security compliance environment. The owner of the systems and project sponsors need to be informed about security compliance issues. In 6.1.4, Installing the reporting server on page 128, we describe how to set up the reporting infrastructure for operational reports. Project phase 1 requires skills to set up the Security Compliance Manager server infrastructure and roll out the Security Compliance Manager clients. The adaptation of the Security Compliance Manager policies that come with the product require knowledge of your enterprise security policy and SQL skills to modify the compliance objects.
Project phase 2
Typically, project phase 2 enhances the Security Compliance Manager policies to fully cover the security controls defined in the enterprise security policy. This phase might require you to develop additional collectors in order to gather more security related data from the Security Compliance Manager clients. Another task of phase 2 can be the implementation of operational reports, trend reports, and other statistics to fulfill business requirements and optimize the security compliance management process. Project phase 2 requires Java implementation skills for the collector development, SQL skills for policy development, and Crystal Report development skills for modifying and creating operational reports. Platform specific skills are required to identify the sources of security data to be gathered by the Security Compliance Manager collectors.
55
Project phase 3
Project phase 3 can include full coverage of the security controls that can be automated. In many cases, application specific data collectors have to be implemented to support, for example, database systems, mail servers, ERP systems, or any kind of application. Another task of phase 3 can be the integration of the security compliance management solution with other security audit applications, for example, Tivoli Risk Manager. Tivoli Risk Manager is an application that leverages the Tivoli Enterprise Console event management system to manage enterprise security threats. Each of the managed technologies, such as firewalls, intrusion detection systems, routers, and hosts, has Tivoli Risk Manager-compliant adapters, rules, and tasks that enable security analysts to manage their enterprise from a single control point. In 3.2.8, Integration with Tivoli Risk Manager on page 68, we describe the integration of Tivoli Security Compliance Manager and Tivoli Risk Manager. Phase 3 may also cover the integration with the existing access management infrastructure, for example, Tivoli Access Manager. IBM Tivoli Access Manager is a policy-based access control solution for e-business and enterprise applications. Among many other features, Tivoli Access Manager provides a unified identity and security management platform. 3.2.7, Integration with access control management systems on page 66 provides details of the integration options with access management solutions. The skill requirements are similar as for project phase 2. In addition, you will need skills for the integration with the existing security audit and access management components.
56
Number of checked security controls

Number of security controls defined in enterprise security policy Security controls requiring manual checks Security controls covered by project phase 3 Security controls covered by project phase 2
Security controls covered by project phase 1
Time
Figure 3-3 Coverage of enterprise security policy by different project phases
3.2.3 Placing components in network zones

In this section, we introduce typical network zones in an enterprise and discuss the placement of Security Compliance Manager components. We have to consider four types of network zones in our discussion of component placement: Uncontrolled (external networks, for example, the Internet) Controlled (an external network-facing DMZ and the intranet) Restricted (a production network) Secure (a management network)
External networks (uncontrolled zone)

A good example are workplaces of subcontracted engineers working in a remote team from different locations. The engineers require access to the centralized databases of the team. Intruders might exploit security weaknesses on the engineers workplaces in order to get access to the designs stored in the central databases. Workstations in an uncontrolled zone are not under your direct control, so it is even more important to have the correct configuration for all the controls on these workstations. Even though these workplaces are placed in other networks, Security Compliance Manager is able to monitor the correct configuration settings negotiated with the participants of the remote team. The Security Compliance Manager clients on these workplaces should be configured as pull clients to enable the Security Compliance Manager proxy relay to establish connections from remote. If your firewalls can be configured to allow the
57
single port required for the Security Compliance Manager client/server communication, you can also configure push clients.
External network-facing DMZ and intranet (controlled zone)

The external network-facing DMZ is generally a controlled zone that contains components with which clients may directly communicate. It provides a buffer between the uncontrolled external network and internal networks. Typically, this DMZ is bounded by two firewalls. It is extremely important to control the security settings on systems in this network as they are exposed to external access. Security Compliance Manager proxy relays may be placed in this zone in order to access Security Compliance Manager pull clients in the external network. Corporate intranets may also be examples of such zones. Depending on the specific level of trust existing in the intranet, it may be appropriate to place certain Security Compliance Manager components within it. One example of such a component would be the Web server required to access the Security Compliance Manager operational reports. The transport between a controlled and an uncontrolled zone is classified as public. The transport between a controlled and another controlled or a restricted zone is classified as managed.
Production zone (restricted zone)

One or more network zones may be designated as restricted, that is, they support functions to which access must be strictly controlled, and of course, direct access from an uncontrolled network should not be permitted. As with an Internet DMZ, a restricted network is typically bounded by one or more firewalls and incoming/outgoing traffic may be filtered as appropriate. These zones may contain the back-end Security Compliance Manager components that do not directly interact with users. The transport between a restricted and a controlled zone is classified as managed. The transport between a restricted and a secured zone is classified as trusted.
Management zone (secured zone)

One or more network zones may be designated as a secured zone. Access is only available to a small group of authorized staff. Access into one area does not necessarily give you access to another secured area. If a secured zone exists, it will most likely contain the back-end Security Compliance Manager components that do not directly interact with users. The transport into a secured zone is classified as trusted.
58
Other networks
Keep in mind that the network examples we are using do not necessarily include all possible situations. There are organizations that extensively segment functions into various networks. However, in general, the principles discussed here may be easily translated into appropriate architectures for such environments. Placement of various data components within network zones is, on the one hand, a reflection of the security requirements in play, and on the other, a choice based upon an existing/planned network infrastructure and levels of trust among the computing components within the organization. While requirement issues may often be complex, especially with regard to the specific behavior of certain applications, with a bit of knowledge about the organizations network environment and its security policies, reasonable component placements are usually easily identifiable. Figure 3-4 on page 60 summarizes the general Security Compliance Manager component type relationships to the network zones discussed above. It also depicts the transport classifications.
59
The Security Compliance Manager clients in this zone should be configured as pull clients to avoid connection setup in more trusted networks. No Security Compliance Manager components other than pull clients should be placed in this zone.
The clients in this zone should be configured as pull clients to avoid connection setup in more trusted networks. Proxy relays may be placed in this zone to connect to Security Compliance Manager clients in external networks.
The specific level of trust in an internal network dictates how Security Compliance Manager clients communicate with the server.
Organizations may set up specialized restricted zones for production systems that may include Security Compliance Manager components. Clients in this zone may set up push connections to the Security Compliance Manager server.
Some organizations set up special networks to separate various management components from production systems. The Security Compliance Manager server should be placed here if this zone exists.
Uncontrolled Zone
Controlled Zone
Controlled Zone
Restricted Zone
Secured Zone
Internet
Internet DMZ
Intranet
Production Network
Management Network
Public
Managed
Trusted
LESS SECURE
MORE SECURE
Figure 3-4 Network zones and Security Compliance Manager component placement
3.2.4 Deployment of Security Compliance Manager clients

Before rolling out Security Compliance Manager clients in a large and heterogeneous IT environment, a few conceptual alternatives should be considered. In this section, we provide experiences and lessons learned from a large rollout project. The main aspects of rollout planning are: Tracking of the rollout progress Client deployment options Registration and grouping of clients Client update
Tracking of the rollout progress

To keep track with the rollout of Security Compliance Manager clients is an important task during the first project phase. You can exploit the Security Compliance Manager database to support this task. Usually, an organization will
60
maintain a central database to administrate its assets. This asset database is an ideal point to start the rollout process. One of the first steps after setting up the Security Compliance Manager server infrastructure is the registration and grouping of Security Compliance Manager clients. Instead of waiting until the push clients register themselves, you can start to pre-load all Security Compliance Manager clients in a single step. Security Compliance Manager provides the CLI command scmregisterclient to register Security Compliance Manager clients in batch. In Tracking of the rollout progress on page 124, we describe how to use Security Compliance Manager to track the rollout progress and provide example reports to support this task.
Registration and grouping of clients

Establishing groups of clients that represent organizational units that fit into the security compliance management process is an important task. Doing this work right saves all parties involved in the security compliance management process time and effort. Natural grouping options are operating system types, organizational units, security zones, countries, or administration domains. Additionally, client groups facilitate delegation of administration tasks. Security Compliance Manager supports the grouping of clients by offering client groups and group inheritance. A client group is a container used to group one or more clients together. Clients can be members of one or more client groups. A client group itself can be a member of one or more client groups. A client must be a member of at least one client group in order for a policy to be applied to the client. Adding policies and collectors to client groups is a powerful feature because of group inheritance. Every client that is a member of the client group, or a member of a subgroup of the client group, inherits the collectors and policies added to the group. Adding a collector to a client group adds a collector instance, with the same schedule and parameters, to every client that is a member of the client group or a member of any nested group. Figure 3-5 on page 62 shows an example of group inheritance. In this example there are two different security levels defined having different control settings and security compliance check frequency requirements. We use this criterion for the first grouping level. In the next level, we differentiate the clients by operating system types. Usually, there are so many differences between the operating systems, that for each different type another policy has to be defined. The next level represents the organizational units of the enterprise. We have to attach the policies only to the operating system groups. All child groups inherit the policy and the collectors attached to an operating system group. Later on in the security compliance management process, we can make a single snapshot for the operating system group SL1.AIX, which performs compliance checks for all clients in all subgroups, or create different snapshots for the organizational units.
61
Security Level 1 SL1.AIX
AIX Policy Level 1 SL1.AIX.North Host1.ab_bank.com Host2.ab_bank.com Host3.ab_bank.com SL1.AIX.South Host5.ab_bank.com Host6.ab_bank.com Linux Policy Level 1
SL1.Linux SL1.Linux.North Host7.ab_bank.com Host8.ab_bank.com SL1.Linux.South Security Level 2 SL2.AIX SL2.AIX.North Host9.ab_bank.com Host10.ab_bank.com SL2.AIX.South AIX Policy Level 2
Figure 3-5 Grouping example for clients exploiting group inheritance
Client deployment options

The Security Compliance Manager architecture requires installation of client components for all systems to be monitored. It is a major task in the first project phase to roll out the Security Compliance Manager clients. In addition to the manual interactive installation method, Security Compliance Manager supports this project phase with the following client installation options: Silent install The Security Compliance Manager InstallShield package provides the ability to perform a silent installation using response files. This option reduces the installation time considerably. In Client deployment options on page 62, we provide an example of a silent install. Software distribution mechanism Security Compliance Manager supports the Software Distribution component of Tivoli Configuration Manager to install multiple clients remotely. Tivoli Configuration Manager requires software package definition (SPD) files and response files. The SPD files and response files are available in an archive file named swdis.zip or swdis.tar. You can download either of these files from
62
the IBM Tivoli Software Support site, which can be located from the Tivoli Security Compliance Manager Web site:
http://www.ibm.com/software/tivoli/products/security-compliance-mgr/
Client update
Security Compliance Manager supports updating the Security Compliance Manager clients from the Security Compliance Manager server. Clients contact the server at periodic intervals called a heartbeat, which is every 10 minutes by default, to check for updates. During this heartbeat, the client checks the server for policy and collector updates and receives any new or updated collectors from the server, along with any new or updated collector schedules and parameters. The client component software itself can be sent by the server and the client updates itself and restarts. The client communicates with the server at intervals determined by the check.interval setting in the client.pref file, which is set at 14400 seconds (24 hours) by default (at the Fix Pack 2 - 5.1.0.2 level) to figure out if a new update is available. This feature reduces the maintenance effort for Security Compliance Manager clients extremely. Once installed, the Security Compliance Manager clients do not require further manual intervention. There are situations in which the automatic update of clients is not desired, for example, there might be frozen zones in which no modification of a production machine is allowed. If multiple organizational units are involved, it might also be difficult to arrange modifications of all systems at the same time. For these situations, Security Compliance Manager supports step-wise updates of the Security Compliance Manager clients. In order to prevent updates from the server to the client component, the client.pref file provides the update.enabled stanza that is configured as true by default. Changing the value to false disables the client software update (at the Fix Pack 2 - 5.1.0.2 level).
3.2.5 Delegated administration

Security Compliance Managers delegated user administration enables companies to configure a secure administration model for user identities and accounts in a distributed organization. Small companies that administer their users from a single department might not need to use delegated administration because of the extra work required to set up and maintain this administration model. Medium to large companies with many departments and divisions might want to implement a delegated user administration model because of internal politics, regional differences in the way identities and accounts are administered, or perhaps the number of identities and accounts is too large for a single department to manage.
63
Security Compliance Manager provides a role-based access control system. As a first step, users are grouped in Security Compliance Manager user groups. A user group should contain users requiring the same access rights in Security Compliance Manager. The next step is to define roles. The access rights of a role are defined by adding objects and functions to the role. For example, you can define read access for client groups and managing rights for policies. Finally, assigning roles to user groups provides the members of a user group with the corresponding access rights. Security Compliance Manager's role-based access control system is depicted in Figure 3-6.
User Groups
Add/Remove
Users
Roles
Group
Client
Objects
Assign Policy
Report
Collector
Admin_South Admin_North Security Audit Management
Admin_Role Audit-Role Mgmt_Role
Add/Remove Delete Read
Functions
Manage Create
Figure 3-6 Security Compliance Manager's role-based access control concept
Several default roles are defined to permit users to be granted a subset of those that are useful for controlling access to the access control management: Senior Admin Has permission to perform all actions. This role cannot be changed. Junior Admin Has permission to perform most actions, but excludes the collector, user, user group, and role actions. User Admin Has permission to perform all user, user group, and role actions. Client Admin Has permission to perform all client actions. Policy Admin Has permission to perform all policy actions. Snapshot Admin Has permission to perform all actions associated with snapshots. Reporting Admin Has permission to perform all report actions.
64
There is one default setting in the role-based access control concept. When the Security Compliance Manager server is installed, a default administration user is created. This user is a member of the Senior Admin user group and is permitted to perform all actions in the administration console and with the administration commands. This user cannot be removed from the Senior Admin user group, and the user ID itself cannot be removed. Using the Security Compliance Manager administration console, you can define specific roles, combining objects and functions allowed on them. Combined with the client grouping concept described in Registration and grouping of clients on page 61, Security Compliance Manager supports delegated administration that fits the needs of your enterprise. Implementing delegated administration on page 125 contains an example how to configure delegated administration and provides useful hints and tips that make administration an easy task.
3.2.6 Implementation of Security Compliance Manager policies

A Security Compliance Manager policy contains one or more compliance objects that are specially written SQL queries used to reveal compliance to or violation of system security controls. Generally, we need to deal with three types of controls: Controls that can be fully automated Security Compliance Manager data collectors gather all required information from the IT systems that are necessary in order to verify compliance to these controls. Controlling the configured maximum password length for user accounts is a good example for a control that can be fully automated. Security Compliance Manager provides many collectors for all supported platforms to extract this kind of information. Controls that must be checked manually These controls require human judgement, but can be supported by Security Compliance Manager through collecting the required information from the systems. A typical control would be user revalidation. User revalidation requires you to know all the current users and their access rights in the IT environment. Security Compliance Manager supports user revalidation by providing user details (except passwords and access rights), for example, group memberships. Based on that data, the IT user management department can decide if user accounts and access rights are configured appropriately. Controls that must be done manually Typically, these controls require additional information that is not available on the platforms to be controlled. A security policy may require that no confidential information is stored on a system in a specific security zone. A
65
Security Compliance Manager data collector cannot decide if confidential information resides on a system. During the architecture and design phase, it must be decided which controls to automate, which controls to support, and which controls to leave to manual checks. The decisions is usually driven by two factors: Risk What is the risk of not checking a control or (sub)system in an automated fashion? The answer is that the probability for damage caused by external or internal hackers exploiting system misconfiguration is higher. As soon as operating system or application updates are deployed, or even new software components are installed, various security controls might be affected. How often will security controls be checked if the check can be performed automatically? There is little difference between checking hourly, daily, weekly, or monthly. The difference is a slightly higher network load. Security controls that must be checked manually are usually performed once, twice, or in rare cases, 12 times a year. Additionally, we have to assume the risk of human errors if compliance checks are performed manually. This gives much more room for exploiting system misconfigurations. Cost The cost to automate a control has to be compared with the cost of checking it manually. Checking a control manually can be reduced to the following equation: Cost for manual checks = Number of systems to be controlled x Time to perform the check x security compliance check frequency x labor costs These repetitive costs that occur every year have to be compared to the development and maintenance costs for collector development. The result of this discussion is the number of collectors and policies to be implemented. In 6.2.3, Collector development on page 151, we provide information about implementing collectors.
3.2.7 Integration with access control management systems

By default, authentication for users of the administration console and administration utilities is handled by the Tivoli Security Compliance Manager server. User information is stored in the database with the password being stored in MD5 message-digest format. The server does not enforce any password rules or perform any password strength testing and no mechanism exists to recover a forgotten password. To provide additional security, or to integrate Tivoli Security Compliance Manager into your existing authentication mechanism, you can develop and install a Java Authentication and Authorization Service (JAAS)
66
plug-in that handles the authentication of users. You can find more information about JAAS at:
http://java.sun.com/products/jaas
Security Compliance Manager provides a sample JAAS plug-in as part of the server component. The sample JAAS plug-in is only for demonstrating the functionality of using an external authentication service. It obtains login information from a text file containing unencrypted user IDs and passwords. In 6.2.1, Tivoli Access Manager integration on page 146, we describe how to integrate Security Compliance Manager with an actual access management system using Tivoli Access Manager. IBM Tivoli Access Manager is a policy-based access control solution for e-business and enterprise applications. By providing a centralized, flexible, and scalable access control solution, Tivoli Access Manager allows you to build highly secure and well-managed network-based applications. Figure 3-7 shows the components required to integrate Security Compliance Manager with Tivoli Access Manager.
Security Compliance Manager server

Authentication request
JAAS Module Access Manager Java Runtime Environment
Access Manager Server Components Access Manager Runtime Environment

SSL connection
Access Manager Policy Database
IBM GSKit
LDAP Directory
Figure 3-7 Authentication of users using Tivoli Access Manager JAAS module
On the Security Compliance Manager server system, you have to install the Access Manager Java Runtime environment and configure the JAAS authentication to be used by Security Compliance Manager. The integration with Tivoli Access Manager has many advantages, for example: User accounts and passwords are stored in a common directory. Access Manager supports sophisticated password rules. You can define allowed login times for administrators and users individually. You can define maximum login attempts.
67
3.2.8 Integration with Tivoli Risk Manager

In today's enterprise network environments, there are multiple security components, such as firewalls, intrusion detection systems, antivirus software, identity management systems, access management systems, and many more. All such security components perform a unique specialized function and provide output that is presented to the security administrator for assessing network security status and taking appropriate actions. Often, the output is in the form of ASCII log files, SNMP traps, or even directly sent to the operating system log. A security administrator can hardly exploit this very useful security information that is stored in multiple locations in various forms in an efficient way and to accurately assess the current situation. Risk Management, in this context, refers to a systematic method by which information collected from security point products can be consolidated and correlated to obtain a precise and concise picture of the security risks that exist at any point in time and take the necessary action. Information obtained from one source tends to be more useful when analyzed in conjunction with information obtained from other sources (ideally in real time). Tivoli Risk Manager is an added on classic Tivoli Enterprise Console application that leverages the Tivoli Enterprise Console event management system to manage enterprise security threats. Figure 3-8 on page 69 depicts the high level architecture of Tivoli Risk Manager. It is a logically layered architecture that leverages Tivoli Enterprise Console components to implement enterprise risk management. Each of the managed technologies, such as firewalls, intrusion detection systems, routers, and hosts, has Tivoli Risk Manager-compliant adapters, rules, and tasks that enable security analysts to manage their enterprise from a single control point.
68
raw event Risk Network Intrusion Manager Detection System Adapter Risk Manager Agent summarized events or correlated incidents
Risk Host Intrusion Manager Detection System Adapter
Reporting
Risk Manager Agent
Database Auditing
Risk Manager Adapter
Risk Manager Agent
Risk Risk Manager Manager Correlation events Database and incidents Real-Time Display (TEC GUI) compliance issues
Logging Infrastructure
Risk Manager Adapter
Risk Manager Agent
Risk Manager Tivoli Security Adapter for Compliance Security Manager Compliance Manager
Risk Manager Agent
Figure 3-8 High level architecture of a Tivoli Risk Manager solution
The consolidation of incidents created by intrusion detection systems and security compliance issues provide a valuable source of information if attacks are detected and must be evaluated. For example, multiple login attacks on systems with weak password settings and missing security patches require immediate action. More information about Tivoli Risk Manager can be found in the IBM Redbook Centralized Risk Management using Tivoli Risk Manager 4.2, SG24-6095.
3.3 Business processes and compliance management

The first part of this section describes a generic security compliance management business process and how Security Compliance Manager supports it. The second part discusses the impact of automated security compliance tools on the management process.
3.3.1 A generic security compliance management business process

Figure 3-9 on page 70 depicts the elements of the generic compliance management processes.
69
System System administration System administration administration
7.Request exceptions
Security Policy
5. Correct settings
4. Report deviations
Security Audit Team 3. Document health check and deviations 9. Document accepted deviations
1. Apply security policy
6. Report compliance status 8. Ask for risk accaptance
2. Check control settings and compare to security policy
Authority
Management
Figure 3-9 Generic security compliance business process
1. Apply security policy. The first step in setting up a security compliance management process is to make sure the required security control settings of the enterprise security policy are audited. Usually, a list of controls and the required settings is created for system type. 2. Check control settings and compare to security policy. Periodically, the audit team controls the systems, if the real settings are in compliance with the policy. The audit team creates a report listing all controlled system and the violated controls. Often, the list must also contain the complete security control settings and the systems that are controlled. 3. Document security compliance check and deviations. The audit team archives the security compliance results documenting that the security compliance check was performed according to the security policy. 4. Report deviations. The audit team has to inform the system owners and administrators about the findings of the security compliance management process. Usually, a list of deviations is handed over, specifying a target date for correcting the settings.
70
5. Correct settings. The system administrators usually test the corrective actions in a test environment to verify that the system functions are not affected. Then they deploy the changes to the production environment. 6. Report compliance status. The audit team creates security compliance status reports for management and external audit purposes on a regular basis. 7. Request compliance exceptions. System administrators who come across security settings that affect the functionality of a system might request compliance exceptions. They ask the audit team if, for a certain amount of time, the violation of a security control can be tolerated. 8. Ask for risk acceptance. Being asked for compliance exceptions, the audit team will negotiate a risk acceptance with the management team. Usually, the risk acceptance is only temporary until there is a secure solution for the IT system. Depending on the customer environment, so called secondary controls may be required. At regular intervals, the tools and procedures used for checking the compliance status itself is checked against the current policy and standards. This secondary control is required, as security policies and especially security standards are living documents and have to be adjusted to the newest security threats, countermeasures, and technologies. Without continuous control, the security compliance management tools would soon deviate from the enterprise security policy.
3.3.2 Security Compliance Manager business process support

This section looks at the Security Compliance Manager components supporting the activities related to business processes.
Apply security policy

It is a key task for any security compliance management process to integrate, apply, and maintain a company's security policy. Security policies are living documents that are adapted continuously to a changing environment. Security Compliance Managers design concept reflects the need for a security compliance management solution that is easy to maintain and flexible to react to policy changes without delay. Security Compliance Manager separates the security compliance management process into data collection, which is performed by the Java data collectors, and compliance evaluation, which consists of SQL statements called compliance objects. In most cases, changes
71
to the security policy consists of simple modifications of the compliance objects that do not require touching the Security Compliance Manager clients. Security Compliance Manager also supports enterprise security policy changes that require modification of the Java data collectors or even the development of new collectors. Once the new collectors are installed in the Security Compliance Manager server, the server starts to distribute the new collectors to the Security Compliance Manager clients automatically. Within a few hours, a new policy is activated. Applying the enterprise security policy with Security Compliance Manager consists of two steps: developing Java data collectors and defining security compliance objects. Security Compliance Manager supports both activities: Security Compliance Manager provides a comprehensive set of Java data collectors for all supported platforms. The data collectors gather enough security relevant data to implement a solid security policy. In most cases, there is no need to develop additional Java data collectors. If required, the Security Compliance Manager Java Development Kit allows you to implement additional data collectors. In 6.2.3, Collector development on page 151, we describe how to develop new data collectors. The Security Compliance Manager administration console supports the development of policies and security compliance objects. In Policy development on page 34, we demonstrate how to create a policy and describe the development environment provided by Security Compliance Manager administration console.
Check control settings and compare to security policy

Comparing the actual configuration settings on computer systems with the required settings defined in the security standards is a very important task in the security compliance management process. Usually, the security auditor has to log in to the system, run multiple applications to obtain the actual settings, and compare the result manually with the standard. Even if supported by semi-automated security compliance management tools, this can be an annoying and time consuming task resulting in security compliance check frequencies like once or twice a year. Security Compliance Manager allows you to fully automate the task of gathering security data and comparing it to settings defined in the security standards. Automation allows you to implement daily security compliance checks of all systems without additional effort, providing additional security in the IT environment. In 2.1.1, Data collection components on page 13, we describe the data collection part, and in Snapshot creation on page 45, we demonstrate how snapshots perform data evaluation in more detail.
72
Security Compliance Manager goes even a step further and supports detection of configuration changes. If enabled, delta monitoring monitors changes to the configuration data. Each time the collector instance collects data and sends it to the server, the server compares the newly received data with the data stored in the collector table. If the data has changed, the new data is appended to the delta table and then the collector table itself is updated.
Document security compliance management

The security compliance management process requires documenting that compliance checks are performed regularly, within the required intervals, and that they are complete. (Complete means that all security control settings on all systems are actually checked.) Some environments even require archiving the data used for the security compliance management process and not only the result of the compliance check. Security Compliance Manager supports the documentation task as follows: Operational reports The Client Violations operational report documents that compliance checks are performed by listing Security Compliance Manager clients, their status, and the security audit findings. Figure 3-10 on page 74 shows an example report of type Client Violations. The report Snapshot Creation Completion displays the times that each snapshot associated with the policies were created. This report proves that compliance checks were performed completely.
73
Figure 3-10 Security Compliance Manager operational report: Client Violations
Checking the completeness of a report A snapshot can successfully run but return incomplete or inaccurate results for any of the following reasons: The collectors associated with the policy have not yet run on all of the clients. The collected data has not yet been added to the database tables. The snapshot was erroneously restricted to a client group that did not have the policy added.
74
The results of a snapshot are only as complete as the data contained in the database tables. If there is no data for the compliance queries to check, there are no violations to report. In order to verify the completeness of a report Security Compliance Manager provides the following options: Operational report The Collector Run Information report displays information about previous runs of the collectors, for example, information about the client, the collector instance, and the time of the run. The following code snippet shows a compliance query that can be used to generate a violation for each client that did not report data for one or more collector instances. The string $currentsnapshotid is replaced with the ID of the snapshot when the compliance query is run as part of a snapshot. This snapshot ID can be used to index the JAC_SYS.SNA_CLI_TAB_METADATA table, which contains a list of the tables returned by the clients that are part of the snapshot.
Select a.cli_id, No data from client with IP address of || b.primary_ip as IP_ADDR from jac_sys.sna_cli_tab_metadata a inner join jac_sys.clients b on a.cli_id = b.cli_id where sna_id=$currentsnapshotid and logdate is null
Delta monitoring By default, the Security Compliance Manager database contains only the most recent data collected by a Java data collector. If activated, delta monitoring monitors changes to the data that is returned by a collector instance. Each time the collector collects data and sends it to the server, the server compares the newly received data with the data stored in the database. If the data has changed, the new data is appended to the delta table and then the collector table itself is updated. The delta table allows you to prove the actual setting of a security control and not only the result of the compliance check.
Address deviations and correct settings

Usually, the security auditor informs the computer system owners about security findings and provides information about deviations and required corrective settings. Security Compliance Manager supports this task with the following options: Operational reports via Web access Operational reports that list audit issues can be provided as HTML reports using a Web interface.
75
Operational reports as files Operational reports can be provided as Crystal Reports, Adobe Acrobat files, Microsoft Excel files, and Microsoft Word files. Security Compliance Manager snapshot reports Snapshot reports can be accessed using the administration console. The user access model of Security Compliance Manager allows system owners to access their systems and create and view snapshot reports. Additionally, the reports can be exported as HTML files and handed over to the system owners using mail or workflow systems. The reports can be sent on an assigned schedule to specified e-mail addresses. Security Compliance Manager reports Reports are formal database queries for ongoing system verification and analysis. A report is used to send the results of an SQL query to one or more users. Reports can be grouped by client group, or by any other logical grouping, such as department or physical location. The report is sent on the assigned schedule to the specified e-mail addresses.
Report compliance status

Security compliance status reports for management and external audit purposes should be based on Security Compliance Manager operational reports. Security Compliance Manager offers a comprehensive set of reports for this purpose. The following reports are provided: Administrative Activity Displays a history of the administration activities that were performed by users. Changes to Roles and Permissions Displays a history of changes to the definitions for roles and permissions. Client Group Membership Displays information about client groups and their members. Client Violations Displays the policies and their latest snapshots. This report includes the details for all the violations associated with a client. Collector Run Information Displays information about previous runs of collectors. Compliant and Non-compliant Systems Displays the systems that are compliant with the defined security policy as well as systems that are not in compliance.
76
Policy Import Time Displays the names and descriptions of all the policies that have been imported. Policy Violations Trends Displays the violation information associated with all the policies. Roles and Permissions Information Displays information about the roles and permissions that are assigned to users. Snapshot Creation Completion Displays the times that each snapshot associated with the policies were created. There are no parameters associated with this report. User Group Membership Displays information about user groups and their members.
Managing compliance exceptions

Security standards may define security control settings that affect the functionality of an IT system. Often, there are no quick solutions to make the system compliant. System administrators who come across such a security setting will have to ask for a temporary risk acceptance until a more sophisticated solution is available. Security Compliance Manager supports this procedure by providing suppressions. A suppression is used to temporarily exempt one or more conditions from causing a violation to be reported. This condition can be based on the client, the client group, the compliance object, the violation message, or any combination of those conditions. Additional SQL statements can be added to any suppression in order to implement fine grained conditions. In Definition of suppressions on page 46, we provide an example of a suppression and describe how to define it.
3.3.3 Automated security compliance management

Prior to the introduction of automated security compliance management, security compliance checks are either never, only from time to time, or rarely carried out. If performed manually, more than often the compliance checks are performed only on a subset of the systems or on a subset of the controls. The result is a very incomplete view of the current security compliance status and uncertainty about how vulnerable the IT environment is. Experience shows that the introduction of a new security compliance management tool increases the insight and accuracy into the compliance status of an environment. In practice, this results in every system being noncompliant
77
with the given security standard in the first run in one or more controls. A phased project approach, as described in 3.2.2, Phased project approach on page 53, leads to a high number of known violated controls after each project phase, as shown in Figure 3-11. We have to bear in mind that the curve represents the number of known violated controls and not the number of actual violated controls. Due to automated compliance management, the number of known violated controls is much closer to the number of actual violated controls than before. So, after each project phase, there is a time period with increased effort for corrective actions that should be taken into consideration when preparing a project plan.
Number of known violated controls
Introduction of automated compliance management
Time
Project phase 1 Project phase 2 Project phase 3
Figure 3-11 Automated compliance management increases the insight and accuracy into the compliance status of the environment
Usually, there remains a number of deviations that cannot be corrected as required by the security policy, or which require a more sophisticated solution. These deviations to the policy usually result from one of three conditions: A specific control cannot be set as required on a specific system due to technical restrictions. Usually, changes to the security policy require configuration changes in all or many IT systems. For example, the minimum password length might be increased to 10 digits. Applications that are in use for a long time might not be able to reflect these changes. Modifications to the application might be too cost intensive or even impossible. Here, an exception to the security policy must be documented and integrated into the automated security compliance management process.
78
A control cannot be set as required on all or the large majority of systems. Financial risks are the reason in the following example. The security policy may require setting a maximum password age of three months. This would require password changes for technical users in regular intervals. As a consequence, a huge number of applications would have to be re-configured and complex processes for password management would be required. Usually, the drawbacks of this policy will outweigh the advantages. Here the policy or standard must be changed to reflect reality. A control cannot be set as required on a number of systems due to usability aspects. For example, users on test and development systems require more access rights on operating system resources than users on production systems. Experience shows that it requires a huge amount of additional effort to manage test and development systems in the same way as productive systems. Here, you must consider creating a different security standard for this group of systems. Additionally, the separation of the two system types in different network zones should be considered. Attention: The project and each project phase should be ended by an Exception Documentation activity: Compliance to the security standards is achieved by either making a system compliant or by documenting and approving any exceptions to the security standard. Because sometimes application configuration requirements are in conflict with the security configuration parameters, some systems can only be green once an exception has been filed.
79
80
Part 2
Part
Customer environment
Part 2 discusses how IBM Tivoli Security Compliance Manager might be used in customer situations. We are using a well-know customer scenario, the Armando Banking Brothers Corp. In our last encounter with this entity, in the IBM Redbook Enterprise Business Portals with IBM Tivoli Access Manager, SG24-6556, they have successfully deployed the Tivoli Access Manager solution for their Web-based application environment. This time, they are using Security Compliance Manager for their distributed server environment.
81
82
Chapter 4.
Armando Brothers Banking Corp.

This chapter provides an introduction to the overall structure of the Armando Brothers Banking Corporation, including its business profile, its current IT architecture and infrastructure, and its medium-term business vision, objectives, and the resulting business requirements. Note: All names and references to company and other business institutions used in this chapter are purely fictional. Any match with a real company or institution is coincidental.
83
4.1 Company profile

The Armando Brothers Banking Corp. (ABBC) is a financial institution that traces its history back to the early days of industrialization. It was a time of radical change and growing financing needs. The Armando brothers were open to new ideas and founded a bank situated in Austin, Texas to help pioneers of those days to finance their business ventures. ABBC, a bank very open to new technologies, expanded rapidly and became one of the most important banks with a tradition of retail and private banking, offering customized services for customers around the world. One reason for their success is their ability to explore different markets with specialized teams. ABBC is represented in all continents and all major cities with at least one office. ABBC began soon to elaborate the new business opportunities offered by electronic banking. They were among the first banks offering their clients online access to their accounts. Additionally, other user groups like business partners and subsidiaries gained access to their computing environment. Over the years, multiple IT systems offering a Web interface have been installed. Recent reports about virus incidents, intrusion attacks, and closely connected damage to the business and their reputation, as well as changes in the regulatory requirements (Basel II, Sarbanes-Oxley Act of 2002), have forced ABBC to rethink the way the existing corporate security policies are executed. Some of the major concerns are: The level of compliance to the security controls set forth in the security policies and standards in the company can currently only be measured in long intervals (months) because the compliance checks are executed manually. With increasing threats to the IT environment, as well as increasing interconnection to partners, this is no longer considered adequate. Regulatory focus on the operation of IT systems has increased and so ABBCs need to be able to demonstrate that the IT environment is under control has increased; this is supported by being instantly able to report on the security compliance status of its systems. Any manual work involved in the security compliance processes is costly and ABBC is under rising pressure to save costs and automate the processes.
84
4.2 Current IT architecture

ABBC is operating world-wide and is represented in all continents and major cities. ABBCs current architecture has grown along with the evolution in IT technology. No wonder that multiple systems of different vendors using different technologies have been installed. As they are inconsistent in the way they handle security, ABBC is faced with complex management tasks. ABBCs current IT architecture is depicted in Figure 4-1.
Internet DMZ
WebSEAL WebSEAL Server Server
Production Network Asia Production Network Europe Production Network USA

AIX Appl. Servers Windows Appl. Servers
Intranet
Mail Router
Linux Appl. Servers
DB2 Appl. Servers
Tivoli Access Manager Server
LDAP Corp. Directory
Network Management
Systems Management
Tivoli Risk Manager
Management Network - Headquarter Austin/Texas
Figure 4-1 ABBCs current IT environment
There are four zones in our drawing to represent the common divisions for ABBCs network architecture: Internet DMZ This is the first environment where the bank controls and defines the network and firewall controls to make sure that only authorized traffic passes. The controls here cover routing protocols, firewall rules, intrusion detection, system monitoring, link performance, and other technical measures. Production networks Production networks are the inner system networks that are available for the business applications and machines. These are the restricted zones where the bank has total control. The production networks are separated into region specific networks to reflect business needs and legal regulation requirements.
Chapter 4. Armando Brothers Banking Corp.
85
Intranet This is the internal corporate network. It allows internal users to have access to the banking systems available in the production network space, but this is only a controlled, as-needed access. The internal networks are not considered restricted compared to the production networks. Management network The management network hosts management applications required to manage the Internet DMZ zones, production networks, and ABBCs intranet. Only system monitoring teams are allowed to access systems in the management network. ABBCs IT infrastructure is made of many interdependent components, such as: Operating systems ABBCs heterogeneous environment contains Windows NT/2000 and UNIX (AIX/Solaris/Linux) systems. Server redundancy or high availability is part of all business machines in order to provide a 99.9% availability. Web servers The Web server layer (or Web farm) is able to handle all external requests with the highest SSL security available. In a recent project, the Web farm was reorganized by introducing Tivoli Access Manager for e-business, providing state of the art security management and single sign-on functionality. The IBM Redbook Enterprise Business Portals II with IBM Tivoli Access Manager, SG24-6885 provides details about this project. Database systems ABBCs most important database systems are DB2 and Oracle databases on various UNIX and Windows platforms. Transactions may be simple query operations or complex update operations in many different points. There is a high dependency on the database servers to perform transactional operations for users, which include external users, visitors, and internal users. Network and firewalls We have to recognize the importance of ABBCs network and firewall infrastructure for proper secure implementation of the compliance management solution. Management components ABBC implemented a security event management solution based on Tivoli Risk Manager.
86
4.2.1 Existing security infrastructure

The following components of ABBCs existing security infrastructure have been identified for special consideration when planning the security compliance management solution, either because they are part of the security controls that must be implemented or because they require integration planning: Tivoli Risk Manager agents are installed on critical Windows and UNIX systems. It is required to include the verification of the correct installation and execution of the Tivoli Risk Manager agents into the scope of the Security Compliance Manager implementation. McAfee antivirus software is installed on all Windows systems. Here, too, it is required to include the verification of the correct installation and execution of the antivirus software into the Security Compliance Manager scope. Tivoli Access Manager is the central security platform for authentication and authorization for ABBCs IT infrastructure and it is required to support the integration of Security Compliance Manager into Tivoli Access Manager for those purpose. In general, a security compliance management system is just one piece of a strong security infrastructure. However, it can be considered a key element because it is used to verify the correct operations of the other parts and therefore a main cornerstone in ensuring and documenting the integrity of the IT infrastructure of any company.
4.2.2 Existing middleware infrastructure

The following components of ABBCs existing middleware are considered highly critical and therefore included in the scope for compliance checks: DB2 databases Oracle databases An extension of the compliance checks in the configuration of applications is planned for the future, but is not currently on the list of requirements.
4.3 Current security policies and standards

ABBCs current security standards mandate a detailed list of configuration settings to be implemented before a system is put into production. The required configuration settings are defined for each operating system, middleware component, and critical applications. Usually, the definition also contains the specific source where the parameter can be verified, for example,
87
the specific key in the Windows registry or the specific line in the specific UNIX configuration file.
4.4 Emerging problems

The current solution for checking technical security controls on a specific system is for the system administrator to: Check the central tool repository for the latest version of the platform (for example, AIX, Windows NT, Windows 2000, Linux, and so on) specific tool Manually load the tool to the target system if a new version is available or the tool is not yet installed on the target system Manually execute the tool, which will generate a report on the local file system Manually copy the report to a central location, where it will be assessed and deviations in the configuration trigger a correction process For some platforms, not only does a checking tool exist for the operating system itself, but also for the installed middleware subsystems; here the above process has to be executed also for each subsystem installed on the target system. The quality of the current solution with regard to required business functionality can be roughly described using the following criteria: Number of supported platforms: Low, as it is currently not feasible to create a platform specific tool for each managed platform. Number of supported subsystems: Medium, as it is currently not feasible to create a specific tool for each managed subsystem. Number of controls per subsystem: High, as checks for all security relevant controls are usually implemented where a tool exists. Level of reporting: Low to Medium, as the current system does not allow for efficient reporting or reporting on trends. Analysis frequency: Low (quarterly at best), because of the significant manual work required; it is not economically feasible to do the checks more often than quarterly. Level of code re-use: Low to medium, as the tools have historically grown; most do not share a common code base and need to be maintained separately. Level of integrity: Low, as only some of the tools write checksums into the reports that would allow the detection of a falsified report. Cryptographic controls that would allow the detection of falsified tools is not possible at all today.
88
4.5 Strategic objectives

The strategic objectives with regard to IT security for ABBC are to: Increase the capabilities for managing the impact of increasing threats and risks in the IT infrastructure Establish effective audit readiness and compliance on the IT components Improve the value of security controls and countermeasures To achieve the stated objectives the company has set forth the following strategy:
Pro-actively create an environment in which continuous and sustained security controls improvements are achieved.
It is relatively easy to see that a compliance management solution, which lowers the amount of manual work, allows for an increase in compliance checking frequency, and can be centrally managed, will strongly support this strategy by giving management detailed, up-to-date reporting on the compliance status and trends while allowing the IT control processes to run faster and more efficient.
4.6 Critical success factors for strategy implementation

The following set of critical success factors (CSFs) for implementing the strategy have been identified with regard to risk management, cost management, and adding value.
Minimize risk
CSF: Reduce the window of opportunity (amount of time and number of opportunities) for an attacker to gain unauthorized access to computer systems by ensuring that a compliance deviation with regard to technical security configuration settings is detected in a timely manner. Enabling information: Security configuration settings of all managed systems. Checking information: Number of systems checked, number of deviations per system, and trends in compliance deviation status. Typical information gap: The current process of semi-automated compliance checks allows only a limited number of controls to be checked on relatively infrequent basis (quarterly). The information systems used to aggregate the compliance status information do not allow for (detailed) trend analysis.
89
Reduce costs
CSF: Automation and centralization of the compliance checking process can reduce the cost of conducting the compliance checks. Enabling information: The compliance checks that can be automated and must not be conducted by a individual. The effort required by an individual to conduct the compliance checks using the current tools is considerable. Checking information: Number of security configuration controls that have been examined for automation. Information gap: None. A list of security configuration controls that can be automatically checked is available from the group that created the tools used today. The current effort for conducting a security health check is one hour per system (acquire the latest version of the tool, install the tool, run the check, and report).
Add value
CSF: Increase in frequency of compliance checks can allow the business unit to react faster to compliance deviations and reduce the window of opportunity (time) for an attacker. Automation and centralization of the compliance checks will support this CSF. Demonstrate being in control of compliance status to regulators quickly. Being able to demonstrate on demand compliance reporting to a regulator gives you an advantage and raises the bar for competitors. Demonstrate the value of the system to senior management quickly by being able to report on a robust set of compliance controls of all installed systems in a relatively short time.
4.7 Resulting business requirements

Given the situation, goals, and considerations laid out in the previous pages, the major business requirement for our solution needs to automate the following processes: Collecting the security configuration from the target systems on scheduled intervals. Transferring the configuration data to a central system to be stored in a database. Checking the configuration data against a (customizable) predefined set of values (from the customers security policy).
90
Creating a report on the number of target systems with compliance deviations, reports on the specific deviations per system, and trend reports on the control compliance. It also needs to provide a framework that can deliver the following features: Allow for high re-usability of the non-platform specific components, for example, the communications components that implement the client/server communication, the software distribution components that implement the mechanisms for component updates on the clients, and so on, by using Java for the implementation of the communications client and the data collectors. Ensure the integrity of the transmitted data and its components against attacks by using SSL as a transport level security mechanism and the ability to cryptographically sign Java components so that any falsification can be detected, as attackers often alter the security configuration to hide their tracks. Can be integrated into the existing framework for access management: Tivoli Access Manager. The management front end has to be able to: Support the representation of the organization used to operate ABBCs systems to simplify reporting and access control management. Support the separation of duties, such as managing the systems (add/change/delete) and managing the compliance checks (add/change/delete) so that (for highly critical systems) not even the system administrators could tamper with the compliance checks. Allow for delegated administration so that it is, for example, possible for one department to change their systems without accidentally changing the systems of another department. In addition, the CIO stated the following business requirements: Minimize the effort of software development. During the past years, ABBC successfully implemented multiple projects using existing software products. This strategy reduced the investments in software development and maintenance dramatically. ABBC has also realized that to gain the extra advantage, software products must be enhanceable where it is required to implement functionality that the off-the-shelf product does not (yet) provide. So ABBC always looks into the efforts for enhancing a product so that current or future requirements can be met.
91
Minimize the number of new hardware systems. ABBCs IT management wants to reduce the number of hardware systems. An important goal of the project is to reuse existing hardware as much as possible. Using the same criteria as introduced earlier, the quality of such a solution with regard to business functionality can be roughly described as follows: Number of supported platforms: Medium today and high in the near future, as the solution is based on a product that will be enhanced by the vendor based on market and individual customer requests. Being an open platform, creating custom "collectors" is also possible for platform, which the vendor cannot support fast enough. Number of supported subsystems: Medium today, mostly in the near future; see the above bullet. Number of controls per (sub)system: High, as all security relevant control checks are implemented. Level of reporting: High, with detailed status and trends, as the system is based on a database that can store the current status as well as "snapshots" of points in time. Analysis frequency (quarterly, monthly, weekly, or better): Weekly or better, as the solution fully automates the checking process and schedules can be fully customized. Level of code re-use: High, because the whole software distribution and communication framework can be re-used. Level of integrity: High, because the solution uses cryptographic measures to ensure the integrity of its components, the transport, and the reported data. All these requirements play to the strengths of Tivoli Security Compliance Manager, its open and robust framework, its management approach, and its off-the-shelf capabilities.
4.8 Requirements on project execution

ABBC is expecting a regulatory audit in the second quarter of 2005 and while the exact date is uncertain, senior management has decided that by the end of the first quarter 2005 at least, some compliance checks must be automatically executable and the changed compliance management process must be executed for all Windows and UNIX systems.
92
Senior management then expects the IT department to gradually expand the number of controls that are checked automatically until the security policies and standards are fully reflected. There is a need to cover all systems with a selected set of compliance controls as early as possible, and then expand the number of controls to play to Security Compliance Managers advantage. The client rollout can be executed independently of the customization and enhancement of compliance controls, because the Security Compliance Manager architecture has an integrated software distribution mechanism that allows for (centrally managed) changes and updates to the data collection components.
4.9 ROI study and results

While the need for better compliance management is mostly driven by risk considerations and increased regulatory requirements, ABBC expects to see a return on investment from the process improvements and automation. It is understood, though, that the risk considerations basically result in more frequent and more detailed checks and that with the current practice a higher checking frequency is not feasible, while with Tivoli Security Compliance Manager basically any frequency is possible, which makes it tempting to simply require bi-weekly checks to make the business case look real good.
Current costs of execution and maintenance

Checking 6676 systems using the existing tools at one hour per system, with six hours of productivity per day, means that it takes 1112 days to make one check. In addition, several tools must be maintained at the cost of about one full time equivalent (one employee working full time). Acting on the reports is the same for both solutions and not discussed here.
Expected costs
Project costs for phase 1 are estimated at one project manager, one IT architect, and one policy developer for three months (180 days), plus rollout efforts of ten minutes per system (195 days, including seven days for software distribution packaging and tests), which equals 375 days. Additionally, the software must be purchased, but additional hardware costs are not expected. Project costs for phase 2 are estimated at one project manager, one IT architect, one IT specialist for report creation and one for policy creation, and one developer for collector development for three months, which equals to 300 days.
93
Maintenance is expected to require the equivalent of one half to one full-time person.
Conclusion
The proposed system, which does not incur costs per check, would therefore pay back within one year even if only one compliance check would be required. The savings are significant if quarterly (four) health checks are assumed (current practice) and massive if more frequent health checks are required. With an investment that will pay back within one year and a project time frame of about six months, this solution will allow ABBC to better deliver to its chosen strategy, lower the operational risks, add value, save costs significantly, and even look good in front of the next regulatory audit.
94
Chapter 5.
Security Compliance Manager design

This chapter describes the implementation architecture of ABBCs security compliance management solution and discusses the project organization for the deployment phase. To build a system that truly meets managements needs, the project team first defines the problem to be solved by the system. Chapter 4, Armando Brothers Banking Corp. on page 83 defines the objectives and business requirements that drive the project. The following list is a summary of the major business requirements: Implement a centralized, automated security compliance management process based on a standard product. Avoid negative impacts on the production environment. Build a tamper resistant compliance management system providing data integrity, confidentiality, and availability. Cover current strategic platforms used in ABBC's production environment and provide enough flexibility to react on future enhancements of the IT infrastructure systems.
95
Based on these requirements, IT security management defines the following implementation strategy: 1. Automate compliance management as far as possible for strategic platforms within the given time frame and budget to save costs. 2. Provide some, however limited, compliance status reporting as early as possible. 3. Expand the compliance control scope as fast as possible and as far as reasonably possible. In the next step, the project team identifies stakeholders from whom business and user needs are elicited, described, and prioritized. From this set of high-level expectations or needs, a set of product or system features, functional, and non-functional requirements are agreed upon.
96
5.1 Functional requirements

The project team analyzes the business requirements from the different business areas of ABBC. The analysis of the business requirements leads to a phased project approach including two phases: The goal of phase I is to implement a baseline functionality in a very short time frame. This project phase addresses the need for a fast improvement of IT security. The project team plans to adapt the existing Security Compliance Manager policies to the values defined in ABBCs security policy standards. Even if not all controls of the security policy standards are covered, this strategy provides a baseline of security control for all strategic platforms. Phase I of the project implements ABBCs security compliance process by exploiting the security report functionality provided by Security Compliance Manager. The second phase of the project expands the compliance control scope to strategic platforms implementing Security Compliance Manager Java collectors. It also extends the Security Compliance Manager policies developed in phase I to completely cover the controls of ABBCs security policy standards that can be automated. Phase II refines security reporting to support ABBCs organizational structure and optimize the security compliance process. The project team derives, from the business requirements, a set of platform requirements. Table 5-1 on page 98 lists the operating and middleware platforms covered by project phase 1 and project phase 2. The project team decides to skip system platforms that are not contained in ABBCs roadmap for strategic system platforms.
Chapter 5. Security Compliance Manager design
97
Table 5-1 Platform requirements for project phases I and II System type Platform Number of systems Phase 1 Operating systems Red Hat Linux SUSE Linux Linux/390 AIX Solaris Windows NT Windows 2000 Windows 2003 HP-UX AIX Firewall Total number of IT systems: Middleware & Applications DB2 Oracle SQL Server Tivoli Risk Manager 87 22 2 27 857 1314 6 1930 941 312 745 546 4 25 857 1314 6 1930 941 312 745 546 25 6676 Automation Phase 2 87 22 27
In the next step, the project team derives the functional requirements for each project phase.
5.1.1 Phase I: Establishing a baseline

The goal of phase I is to provide a compliance status on a limited set of controls on all systems that are supported by Security Compliance Manager, as listed in Table 5-1. The project team identifies the following functional requirements for phase I: Retention time Security compliance data gathered by the Security Compliance Manager collectors has to be available for 120 days.
98
Support of different security zones ABBCs IT systems are placed in different security zones, such as DMZ or production environment separated by geographical units. The compliance management solution has to cover all zones. Availability There has to be enough redundancy to guarantee a maximum down time of 48 hours, because the weekly security compliance reports are delayed no more than two days. Self-service interface for system owners The system administration teams require access to the security compliance system to verify the status of their systems at each time. The goal is to minimize the time between detection of a non-compliant control and its correction. Auditability The systems have to be configured to properly audit transaction execution. Logging should include both successful and failed attempts to log in, as well as logging of any administrative modifications. The auditing functions have to provide enough evidence to prove the correct compliance monitoring of ABBCs IT infrastructure. The project team defines the following functional requirements for security compliance reporting: Retention time Compliance reports have to be available for 120 days. National language support Support of different time zones The following type of reports have to be provided: Non-compliant systems report The report lists all systems having at least one non-compliant security control and the deviations. Scanned systems report The report proves that the systems are scanned successfully. Trend reports The trend report provides information about the number of deviations over a specified time frame.
99
5.1.2 Phase II: Extend coverage

The goal of phase II is to include additional compliance checks for platforms covered by phase I and additional platforms and subsystems that are strategic for ABBC, for example, database systems. Phase II integrates the security compliance management solution into ABBCs security platform (Tivoli Access Manager) and refines the reporting to optimize the security compliance process. The project team defines the following functional requirements: Develop Security Compliance Manager Java collectors and policy compliance objects to cover all controls defined by ABBCs security policy standards that can be automated. Develop Security Compliance Manager Java collectors and policy compliance objects to cover middleware systems and applications listed in Table 5-1 on page 98. Implement user authentication using ABBCs security platform based on Tivoli Access Manager by exploiting the sophisticated access control features. Develop a user access model that reflects ABBCs organizational structure.
5.2 Design objectives

This section describes the design objectives that are related to the infrastructure and operation of the security compliance management solution.
5.2.1 General and infrastructure objectives

The complexity of ABBCs heterogeneous, multi-layered enterprise makes it a challenge to manage compliance with ABBCs security policies and standards. The design of the security compliance management solution must cover multiple operating systems, critical business applications across the enterprise, and may not impact the confidentiality, the integrity, and the availability of corporate assets. Therefore, the security monitoring infrastructure itself must be treated as a critical system and designed carefully. The general design objectives for the monitoring environment include: Minimal impact on scanned IT systems The Security Compliance Manager client running on the IT systems may only slightly impact the performance during its installation, data collection, and data transfer to the Security Compliance Manager server.
100
Centralization To reduce infrastructure and administration costs, the security compliance management system uses a centralized Security Compliance Manager server for all regions. Scalability The centralized solution must be easily scalable to allow, in a cost effective manner, the addition of new Security Compliance Manager client systems. Support secure communication and privacy Critical information exchange, such as security compliance data, user ID, and password data for authentication, must be transmitted in an encrypted form. Applications and core system components should not rely on weak or clear text password processing or storage. The password rules implemented in the security monitoring systems must fulfill the requirements defined in the security policy. OS hardening The Security Compliance Manager infrastructure has to comply to the security class 1 defined in the enterprise security policy. Only authorized users can access the Security Compliance Manager servers and applications. Only required services are installed on the security monitoring systems. Confidentiality Security compliance data must be processed, transmitted, and stored in a secure fashion.
5.2.2 Platform specific security concepts

This section discusses integration aspects for specific platforms and subsystems that need to be included in the automated security compliance process.
Integration of Tivoli Risk Manager

Tivoli Risk Manager leverages the Tivoli Enterprise Console event management system to centrally manage enterprise security threats. Integrating Security Compliance Manager with Tivoli Risk Manager consists of two independent steps: Security deviation notification Security Compliance Manager is able to inform Tivoli Risk Manager about a security compliance deviation immediately after detecting it. The integration ensures a minimal delay between detection of a deviation and its correction.
101
This feature is important for machines at high risk, for example, machines in a DMZ that are accessible from external networks. Tivoli Risk Manager monitoring Security Compliance Manager can be exploited to perform security compliance management for Tivoli Risk Manager components. Typically, a Risk Manager infrastructure consists of a central Risk Manager Event Server and multiple Risk Manager Gateways or Clients. It is important to ensure the correct configuration of the Risk Manager components to avoid undetected intrusion attempts.
Integration of databases
Protecting and securing important information has always been a number one priority. ABBC stores the most important information assets in relational databases. Usually, database systems are open for public access, yet well equipped with advanced security options. The serious database administrator (DBA) has to implement a database security policy choosing between the operating system security, additional specialized security software, or using integrated database security features. The target security policy that is implemented is often a combination of all of them. ABBCs security policy standards define strict configuration settings and protection measures. Obviously, it is a high priority for the security compliance project to include databases in the automated security compliance process. The project team decides to implement Security Compliance Manager Java collectors and policies for DB2 and Oracle databases that cover the following data: Database system configuration The database Java collectors gather information stored in the configuration files of the database systems and operating system platforms. Most of the required information can be gathered using standard collectors provided by the Security Compliance Manager policies for operating system platforms. Database content The ABBC security policy requires gathering data that is stored in database tables like database authorization information. The project team designs generic database collectors using SQL statements to retrieve data from database tables.
Considerations about clients on high secure systems

ABBC operates a number of systems that provide security functions, such as proxies and application-level gateways/firewalls. These systems are located in a a separate network segment (Demilitarized Zone (DMZ)) between the external Internet and the (considered internal) segment holding the Internet facing application servers. Because these proxies are a major protection against threats
102
from the Internet, they must have as little vulnerabilities as possible towards attacks. Therefore, one of the protective measures taken is that only the absolute minimum of services/applications is active and even installed on those systems, which are otherwise normal AIX systems, an approach called hardening. So on the one hand, it is required to have only the minimal amount of services installed, but on the other hand, it is obviously necessary to check the compliance status of those systems carefully and often. As a result, the question needed to be analyzed is whether it is a higher risk to install additional software, the Security Compliance Manager client, for compliance checking, using some other solution or not checking the systems automatically. The latter alternative, no or manual compliance checking, was quickly ruled out by the IT Security department, so that the only question that remained was if Security Compliance Manager clients could be used or some other solution would be preferable. A risk analysis of the Security Compliance Manager client components identified and discussed the following risks: Risk: The installation of a TSCM client may void the warranty or support on "black boxes" such as firewalls, for example, the Checkpoint Secure Platform (SPLAT) or other appliances. Such "black boxes" often contain a stripped down version of Linux or Windows for which the security standards and policies apply as well. However, some vendors state that they will not support a deployed system if additional software is installed. Discussion: For such systems, you must evaluate whether the installation of a non-intrusive software component such as the TSCM client can be tolerated by the vendor or if the vendor has a different policy. If not, the risk of losing the warranty (or being required to reproduce an error without the TSCM client installed) must be weighted against the risk of a breach of security in or through this system due to flaws in the security configuration. Additional mitigating actions: Verify with the system vendor if there is a testing/certification process for third-party products. Risk: The Security Compliance Manager client requires the installation of a Java Runtime Environment. A Java Runtime Environment is often accessible by all users of a system. There have been vulnerabilities in the Java Runtime Environment in the past that allowed for privilege escalation (Privilege Escalation, SUN Alert 57221, Oct 031) and there may be issues in the future. Discussion: The Java Runtime Environment installed by the Security Compliance Manager client installer is executable only with root user privileges (Administrator). If another Java Runtime Environment is used, it can be restricted to be only executable by root so that no other user can access it. Privilege escalation is therefore not a issue.
1
http://sunsolve6.sun.com/search/document.do?assetkey=1-26-57221-1
103
Additional mitigating actions: Ensure that, if a third-party JRE is used, it is only executable by root. Risk: The Security Compliance Manager client opens a listening port for communication with the Security Compliance Manager server using Java Sockets provided by the Java Runtime Environment. There have been vulnerabilities in Java Sockets in the past (Remote Denial of Service Vulnerability, SUN Alert 57555, May 042) and there may be issues in the future. In some cases, it is not possible to only run the Security Compliance Manager client in push mode, so that the Security Compliance Manager client initiates the connection to the server, due to network connectivity issues. Discussion: Any solution that does not require a handshake between compliance management client and server cannot be tamper resistant, because the authenticity of the compliance management client cannot be verified by the server. Any alternative would therefore also require a listening port (where push cannot be used). As a result, Java Sockets is preferable to any alternative because Java Sockets is under intense scrutiny by vendors, programmers, and security experts worldwide and it is less likely that a vulnerability is known only to attackers for a long period of time. In addition, Java is used in other parts of the organization and already covered by the Computer Emergency Response Team (CERT) processes that alert the organization to critical vulnerabilities in deployed software packages. Attention: The Security Compliance Manager process that is responsible for the server communication does not run with root privileges. Additional mitigating actions: The filter rules of the routers and firewalls of this segment must ensure that the Security Compliance Manager client is only accessible by the Security Compliance Manager server (or proxy). In conclusion, the installation of Security Compliance Manager on hardened systems was authorized by the IT Security Department.
5.3 Implementation architecture

The projects next step is to define an implementation architecture. We start analyzing the current IT environment that was introduced in 4.2, Current IT architecture on page 85. ABBCs network is separated into different security
2
http://classic.sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert%2F57555&zone_32=categor y%3Asecurity
104
zones and geographies. In the following sections, we describe the physical components of the implementation architecture, define the security compliance process and derive the required roles and responsibility matrix that must be implemented in Security Compliance Manager server and the Crystal Enterprise reporting environment.
5.3.1 Physical components

The physical components of the security compliance infrastructure consist of: Security Compliance Manager server components Security Compliance Manager proxy systems Crystal Enterprise server In the following sections, we describe the components and their placement in ABBCs infrastructure.
Security Compliance Manager server components

The project team decides to implement a single Security Compliance Manager server managing Security Compliance Manager clients in all countries and security zones. The team follows the recommendations given in the IBM Tivoli Security Compliance Manager Version 5.1 Deployment and Tuning Guide3. Due to the number of clients (6676) and the high frequency of health checks (daily data collection and weekly snapshots), the team plans to deploy the Security Compliance Manager server and the DB2 database system on two separate AIX server systems. The throughput requirement is calculated according to the following formula, which is valid for both systems: Throughput requirement = Number of clients * Number of collectors * Collector message size / Frequency of data collection The calculation is based on the following estimations and observations that were performed in a pilot installation: Number of clients: 10000 (including future growth) Number of collectors: 20 (including middleware and application collectors) Average collector message size (in KB): 20 KB Frequency of data collection (in seconds): Daily Throughput requirement = 10000*20*20 / (24h*60min*60 sec.) = 46.3 KB/sec
This guide is part of the IBM Tivoli Security Compliance Manager 5.1 Utilities and can be found at http://www.ibm.com/support/docview.wss?rs=2004&context=SSVHZU&dc=D400&uid=swg24007082&lo c=en_US&cs=utf-8&lang=en.
105
The team adds additional 20% throughput requirement for report generation, ad-hoc snapshots, ad-hoc collector runs, and administrative access using the Security Compliance Manager administration console.
Security Compliance Manager proxy relay systems

The ABBC network zones are separated by firewalls. The project team discusses the IP connectivity with the network architecture group. They decide to implement a number of Security Compliance Manager proxy relays for each network zone. The proxy relay permits the server to successfully connect to and communicate with clients behind a firewall and avoids opening the firewall for all machines. The project team decides to identify existing nodes in the different security zones having enough available throughput capacity. The same formula is valid for the throughput calculation of Security Compliance Manager proxies as described in Security Compliance Manager server components on page 105. We only have to replace the total number of clients by the number of clients connected through the proxy relay. The Security Compliance Manager proxy relay can be installed on all platforms supported by the Security Compliance Manager client, which facilitates finding a suitable deployment system. In the DMZ, the mail relay systems are used as Security Compliance Manager proxy relays. In the production zones, the existing Tivoli gateway systems are used.
Crystal Enterprise server

The Crystal Enterprise server is placed in the same network zone as the Security Compliance Manager server. ABBC plans to consolidate the reporting infrastructure and use the Crystal Enterprise server for all kind of security reports, including security compliance reports, risk management reports, user revalidation reports, and many more. Figure 5-1 on page 107 outlines the architectural decisions of the implementation architecture. Security Compliance Manager proxies in the different security zones relay the traffic to the Security Compliance Manager server environment that is set up in the management network of ABBCs headquarter in Austin. Access for the administrative users from ABBCs intranet is protected by SSL.
106
Internet DMZ
ITSCM Client
Production Network Asia Production Network Europe Production Network USA

ITSCM Client ITSCM Client
Intranet
Tivoli Access Manager WebSEAL WebSEAL Server Server

ITSCM Client
AIX Appl. Servers
Windows Appl. Servers
ITSCM Client
ITSCM Client
ITSCM Client
ITSCM Proxy Server
Mail Router as ITSCM Proxy
Security Auditor
Linux Appl. Servers
DB2 Appl. Servers
ITSCM Client
ITSCM Client
Tivoli Access Manager Policy Server
LDAP Corp. Directory
ITSCM Server
Reporting Server
ITSCM Client
ITSCM Client
ITSCM Client
Network Management
Systems Management
Mgmt Database Server
Tivoli Risk Manager
Management Network - Headquarter Austin/Texas

Figure 5-1 Physical components of the security compliance solution
5.3.2 User roles and responsibilities

The user roles and responsibility matrix for ABBCs security compliance project can be derived from the security compliance process. Figure 5-2 on page 108 depicts the main process steps.
107
Development and Test Environment
provide policies and reports register new systems, report suppressions

Maintenance team Development team
test and develop
request policy and report changes ad-hoc snapshots

Administration teams ITSCM Server and Database
schedule snapshots
Security Audit Team
accomodate policy changes
Security Policy
retrieve compliance information
Crystal Enterprise Reporting Server
schedule reports
request risk acceptance
control security compliance status
escalate compliance issues
confirm risk acceptance

IT Management
Figure 5-2 ABBCs security compliance process
The general user roles in the security compliance process are: IT security management IT security management is the owner and the sponsor of the security compliance management process, and has the responsibility and authority for the overall process. This includes ensuring the measurement of process efficiency, enforcement of process standards and procedures, and handling recommendations for improvements. IT system administration teams The IT system administration teams are responsible for the installation and availability of the Security Compliance Manager client in order to perform compliance management tasks. The teams have to control the compliance status of their machines by analyzing the compliance reports. In the case of security violations, the administration teams have to correct the control within a time frame of 14 days. Due to the relatively short time frame, the administration teams require access to the Security Compliance Manager server to create ad-hoc snapshots. Using the ad-hoc snapshots, the administration teams can verify the effectiveness of their changes.
108
Security audit team This team manages the day-to-day activities involved in performing security compliance management. The security audit team is responsible for the creation and availability of security compliance reports for a time frame of 18 months as defined in ABBCs security policy. The security audit team may escalate compliance issues to the IT security management, for example, if administration teams do not correct open issues in a timely manner. Security Compliance Manager maintenance team The Security Compliance Manager maintenance team manages the compliance management infrastructure, including all tasks not directly related to security monitoring, for example, managing user accounts, applying policies and collectors, registering clients, or monitoring client connectivity. Security Compliance Manager development team The Security Compliance Manager development team implements, tests, and maintains security policies in Tivoli Security Compliance Manager and operational reports in Crystal Enterprise.
IT Security Management team
view reports
view reports, schedule reports
Security Audit Team
view reports, schedule reports
ITSCM Server and Database
administrative access
ITSCM Maintenance team
administrative access
ITSCM Operational Reports
Development team
view the teams IT systems create snapshots
IT System Administration teams
Figure 5-3 User roles access requirements on ITSCM server and operational reports
Delegated administration concept

ABBC is operating world-wide and organized its IT service infrastructure by the geographical regions USA, Europe, and Asia. Within each region, there are different administration teams for each system platform. For phase I of the
109
compliance management project, we distinguish between UNIX, Windows, and database administration teams. Each team requires access to different systems, policies, collectors, and snapshots using the Security Compliance Manager administration console. Therefore, ABBCs project team decides to implement a delegated administration structure providing the following advantages: Reduce time between detection and correction of non-compliance Delegated administration avoids time consuming interaction between a central security team and local administration teams. The administration teams in the geographical regions manage their own systems. As soon as a compliance deviation is detected, the local teams can start to correct the required settings and verify the result by creating new snapshots and reports. Minimal administration overhead Technical issues like communication problems between Security Compliance Manager server and clients, or missing firewall rules, can be resolved by the local administration teams directly. Reduced costs Delegation of administration tasks reduces the amount of work force required in the central team. Figure 5-4 on page 111 illustrates the delegation model for the security compliance management project.
110
USA Register clients/groups Manage operational reports Manage policies Manage collectors Schedule snapshots UNIX Systems
Administration Team UNIX (USA) Administration Team Windows (USA) Administration Team DB2 (USA) Manage clients Create ad-hoc snapshots Manage ITSCM reports View operational reports Administration Team UNIX (Europe) Administration Team Windows (Europe) Administration Team DB2 (Europe)
Windows Systems
DB2 Systems Central Monitoring Team Europe UNIX Systems
Windows Systems
DB2 Systems
Figure 5-4 Administration delegation at the example of USA and Europe
The project team decides to delegate the following functions to the local administration teams: Monitor client status The local team verifies if all Security Compliance Manager clients are active and correct connection problems. Evaluation of security compliance reports Based on the operational reports, the local teams elaborate on technical solutions for security deviations. Create ad-hoc snapshots and reports The local teams should be able to verify corrections of compliance issues by creating ad-hoc snapshots for single machines or a small number of machines. Manage users and user groups Each team is able to add users to their own user groups.
111
The following functions will be performed by the central security team: Schedule snapshots Snapshots for a large number of systems are time consuming and require resources in the central Security Compliance Manager server. Therefore, the central security team coordinates the snapshot creation process centrally and schedules most snapshots to run during the night. Manage operational reports The central team creates and maintains operational reports and publishes the reports. One of the reasons for keeping this function in the central team was that Crystal Enterprise development skill is not available in each administration team. Registration of groups and clients ABBC maintains a central database containing detailed information about the IT systems that are used world-wide. The central team pre-registers all IT systems based on this information. From that moment, the Security Compliance Manager database can be used to track the progress of the Security Compliance Manager client rollout by creating reports about inactive systems. In Tracking of the rollout progress on page 124, we describe this process and provide an example report. Manage policies and collectors for clients The central security team is responsible for ensuring that the IT systems are equipped with the correct policies and collectors. Therefore, only the central team is allowed to configure which policies are deployed to which IT systems. Implementing delegated administration on page 125 describes, in detail, how to configure the delegated administration concept in the Security Compliance Manager administration console. Publishing modified reports on page 168 provides the same information for the Crystal Enterprise administration console.
5.4 Project organization

The project organization for implementing the Security Compliance Manager solution, as well as the customization and additional development, will be set up as depicted in Figure 5-5 on page 113.
112
ABBC IT Department
ABBC IT Department
Project Manager
Security Architect
Process Consultant
ITSCM Subject Matter Expert
ITSCM/Java Programmer
Platform 1 Subject Matter Expert
Platform 2 Subject Matter Expert
Platform N Subject Matter Expert
Figure 5-5 Project organization diagram
The roles have the following responsibilities: Project manager Responsible for managing the project, organizing resources, tracking activities, and scope as well as reporting to management and communicating to the stakeholders. For example, the rollout of the Security Compliance Manager clients needs to be coordinated and tracked closely, as many departments (not shown in the diagram) are involved. Security / IT architect Responsible for the overall technical solution, know-how transfer between the subject matter experts and technical leadership. For example, it is very important that the development team and system administration teams work together very closely. The development team knows how to implement Java collectors and reports, but the system administration teams know how this information can be accessed and how the security policy standards have to be interpreted in detail.
113
Process consultant Responsible for the verification and (if required) customization of the affected IT processes and task descriptions. For example, the compliance checking instructions need to be updated to reflect the use of this centralized tool. Platform subject matter experts Responsible for delivering the input for the compliance queries, the technical sources (for example, Windows Registry, UNIX configuration file, and so on) of the configuration parameters, and the values to be collected. The platform SMEs are expected to know the relevant security standard for their platform and how it is implemented. Security Compliance Manager specialists Responsible for the setup of the central Security Compliance Manager IT environment and application as well as second level support and troubleshooting of the Security Compliance Manager clients rollout. For example, it can be expected that for about 5% of the clients, some sort of technical issue (for example, connectivity issues, target system resource issues, and so on) needs to be resolved by the Security Compliance Manager specialist and the person installing the client on the target system. Further, the Security Compliance Manager Specialist will customize the compliance queries from the input of the Platform Subject Matter Experts. Security Compliance Manager Java programmer Responsible for creating the additional collectors based on input from the Platform Subject Matter Experts. ABBC security department Responsible for providing the security standards for the platforms and supporting the interpretation of the security standards by the Platform Subject Matter Experts. For example, it is often the case that controls are not specific enough to be verifiable in only one way; here it is necessary to define the acceptable way of checking a specific control/configuration parameter. ABBC IT department Responsible for defining how the new system will be placed in the existing IT infrastructure and for defining how (and by whom) the system will be operated and maintained once it is handed over to production. For example, the Security Compliance Manager data and application must be integrated into the existing backup and systems management infrastructure. Further, once the system is in production, it needs to be maintained. Further, as the IT Department will be responsible for the Security Compliance Manager client rollout, it needs to provide the necessary contacts and resources. Also, the IT Department will need to work with the Process Consultant on the verification and update of compliance checking task and process descriptions.
114
Chapter 6.
Technical implementation
This chapter describes the implementation of ABBCs security compliance project. The project implementation is performed in two phases. Phase I implements the Security Compliance Manager server infrastructure, including the reporting server based on Crystal Enterprise 9, and the rollout of the Security Compliance Manager clients in ABBCs IT infrastructure. Phase II of the project provides implementation guidelines for a specific Security Compliance Manager policy, using the example of a Tivoli Risk Manager policy and the development of operational reports.
115
6.1 Deployment phase I

Deployment phase I of ABBCs security compliance project aims to achieve the following targets: Set up the Security Compliance Manager server infrastructure. Roll out Security Compliance Manager clients in ABBCs world-wide IT infrastructure. Adapt Security Compliance Manager policies provided by IBM to cover ABBCs security policy and standards. Set up the compliance management reporting infrastructure. Establish the process for automated compliance management. The compliance management project team defines the project plan shown in Figure 6-1. We are looking at a relatively short project duration for deployment phase I due to the following reasons: Security Compliance Manager client rollout and Security Compliance Manager policy development are performed in parallel. Security Compliance Manager offers the possibility to distribute Security Compliance Manager client enhancements and Java data collectors after the rollout of the clients. Using the Security Compliance Manager administration console, all required functions can be performed from a central location. Security Compliance Manager client rollout and Security Compliance Manager server setup can be performed in parallel. As soon as the server is available, the connection setup and initial handshake take place.
Initial snapshot and handover
Policy deployment Policy development Policy test phase ITSCM Client rollout ITSCM Server installation Reporting server installation Process integration
Time
Start of project phase I: 01/01/2005
End of project phase I: 28/02/2005
Figure 6-1 ABBCs project plan for deployment phase I
The following sections describe the steps required for deployment phase I.
116
6.1.1 Planning and installing the server

IBM recommends installing the Security Compliance Manager server on a system with a high processor speed and ample disk space. The system that contains the server should be solely dedicated to that task. This configuration allows the system to be tuned and optimized for running Security Compliance Manager. This configuration also keeps the server from having to compete with other applications for system resources. The Security Compliance Manager server benefits from being installed on a multi-processor machine, as different threads can be distributed and executed by different processors. The database server serves as the repository for all Security Compliance Manager data. The database server can be installed on the same system as the Security Compliance Manager server; however, for better performance, the database server should be installed on a separate system. For even greater performance, the database server can be installed on a multi-processor machine. ABBCs project team decides to install the Security Compliance Manager server and the Security Compliance Manager database on different multi-processor machines, as shown in Figure 6-2, because the Security Compliance Manager server has to manage 7,000 servers operating systems, middleware systems, and applications.
ITSCM Server DB2 JDBC driver
DB2 Database Server JAC ITSCM DB configuration
ITSCM Server component
Figure 6-2 Security Compliance Manager server and database on different systems
The following list discusses the installation tasks for this configuration: 1. Installation of the DB2 database system on the DB2 database server You have to create a separate file system for the DB2 database that is to be used by the server. Creating a separate file system does not remove the possibility of filling up a file system, but it does reduce the impact to other applications. Additionally, other applications do not influence the availability of the Security Compliance Manager database and separate file systems are also easier to backup. The IBM DB2 Universal Database Installation and Configuration Supplement Version 8, GC09-4837 describes the DB2 database installation steps in detail.
Chapter 6. Technical implementation
117
Tip: You can create the database instance for Security Compliance Manager during the installation of the DB2 software in one step or use the db2setup program to create the database instance after a successful base installation. Using the db2setup method is the preferred method to ensure that the database instance is working correctly for the Security Compliance Manager server. 2. Installation of the Security Compliance Manager database configuration on the DB2 database server Chapter 2, Installing the Tivoli Security Compliance Manager server, of the IBM Tivoli Security Compliance Manager Version 5.1 Installation Guide: All Components, GC32-1592 explains the installation steps of the database configuration for Security Compliance Manager. In this step, the Security Compliance Manager installer creates the database JAC on the DB2 database server, prefills the JAC tables with required data objects, and creates the Security Compliance Manager senior administration user for this installation. 3. Copying the DB2 JDBC driver files to the Security Compliance Manager server You need to copy the DB2 JDBC driver files db2java.zip and db2jcc.jar to the Security Compliance Manager server in any directory. In step 4, you have to specify the absolute path of the JDBC driver db2java.zip. It is important to use the JDBC driver of the actual database server. The version of the JDBC driver depends on the OS version and database version being used. 4. Installation of the Security Compliance Manager server component on the Security Compliance Manager server system Chapter 2, Installing the Tivoli Security Compliance Manager server, of the IBM Tivoli Security Compliance Manager Version 5.1 Installation Guide: All Components, GC32-1592 explains, in detail, the installation steps of the Security Compliance Manager server component. During the installation of the Security Compliance Manager server component, you have to specify the absolute path of the JDBC driver db2java.zip. The Security Compliance Manager installer creates links from the Security Compliance Managers jar directory to the JDBC driver files. In addition, you have to specify the database instance ID and password during the installation. The Security Compliance Manager installer obfuscates the password and stores it in the Security Compliance Managers server.ini file. The installer starts the Security Compliance Manager server automatically.
118
5. Verify the Security Compliance Manager server installation Stop the Security Compliance Manager server and set the debug parameter in the servers server.ini file to true. Restart the Security Compliance Manager server and verify the entries in the server.log file. The file should contain the following or similar entries after a successful start:
[20050313 13:05:18.562] ################ SERVER STARTING ############### [20050313 13:05:18.572] Server password found in cache [20050313 13:05:18.572] Opening server keystore: /opt/IBM/SCM/server/keystores/server.jks [20050313 13:05:18.752] Loading provider certificates [20050313 13:05:20.365] Setting up SSL Server [20050313 13:05:25.592] Creating server DB Connection Pool [20050313 13:05:27.074] Creating administrator DB Connection Pool [20050313 13:05:29.728] DHCP autoregister is: false [20050313 13:05:29.728] Starting service: com.ibm.jac.license.LicenseManager [20050313 13:05:30.139] Starting service: com.ibm.jac.server.aco.ACOSecurityManager [20050313 13:05:33.063] Starting service: com.ibm.jac.server.JACConfigurationManager [20050313 13:05:33.063] Starting service: com.ibm.jac.server.SecurityServer [20050313 13:05:33.283] Starting service: com.ibm.jac.server.ClientDistributionService [20050313 13:05:33.323] Starting service: com.ibm.jac.server.ClientDistributionService2 [20050313 13:05:33.333] Starting service: com.ibm.jac.server.ScheduledQueries [20050313 13:05:33.714] Starting service: com.ibm.jac.server.ScheduledPolicies [20050313 13:05:33.724] Starting service: com.ibm.jac.server.ServerBackend [20050313 13:05:33.824] Starting service: com.ibm.jac.server.ClientToServer [20050313 13:05:33.834] Starting service: com.ibm.jac.server.ClientServerPull2 [20050313 13:05:33.864] Returned to idle queue: PoolThread-1 [20050313 13:05:33.864] Returned to idle queue: PoolThread-2 [20050313 13:05:33.864] Returned to idle queue: PoolThread-3 [20050313 13:05:33.884] Listening for client connections on: 0.0.0.0:1951 [20050313 13:05:33.884] Returned to idle queue: PoolThread-4 [20050313 13:05:34.004] Returned to idle queue: PoolThread-5 [20050313 13:05:34.234] Starting service: com.ibm.jac.server.DeltaTables [20050313 13:05:34.535] Starting service: com.ibm.jac.server.TableCleaner [20050313 13:05:34.615] Starting service: com.ibm.jac.server.AdminServerFactory [20050313 13:05:34.625] All services started
Stop the server again, reset the debug value back to false, and restart the server.
119
6.1.2 DB2 maintenance tasks

According to ABBCs security policy, the Security Compliance Manager collectors daily collect data from the client systems. As a result, the Security Compliance Manager server will frequently update the DB2 database tables holding the data gathered from the Security Compliance Manager clients and violation messages. IBM recommends executing the DB2 command RUN_STATS when a table has had many updates, or after reorganizing a table. RUN_STATS updates statistics about the physical characteristics of a table and the associated indexes. These characteristics include number of records, number of pages, and average record length. The optimizer uses these statistics when determining access paths to the data. Using RUN_STATS regularly results in noticeable performance improvement when running snapshots and reports. The RUN_STATS command should run regularly on the database tables listed in Table 6-1.
Table 6-1 Database tables and update frequency Database schema JAC_IDATA JAC_SYS Database table All tables VIOLATIONS SNA_CLI_TAB_METADATA SNAPSHOTS COMPLIANCE_SQL_STATE JAC_SYS DELTA_TABLES ... number of configuration changes on Security Compliance Manager clients Changes depending on... ... run frequency of related collectors ... run frequency of snapshots
The following command will execute RUN_STATS on the database table JAC_SYS.VIOLATIONS and all indexes:
$ db2 runstats on table jac_sys.violations and indexes all DB20000I The RUNSTATS command completed successfully.
120
You can significantly decrease your snapshot creation time and improve other functions by implementing additional indexes in DB2. Here are two commands that can be run from the DB2 prompt or from the Security Compliance Manager administration console Query Tab to create indexes for the jac_sys.violations:
CREATE INDEX JAC_INDX.JAC_VIOL_SNA_ID ON JAC_SYS.VIOLATIONS (SNA_ID) PCTFREE 10 ALLOW REVERSE SCANS; CREATE INDEX JAC_INDX.JAC_VIOL_COM_ID ON JAC_SYS.VIOLATIONS (COM_ID) PCTFREE 10 ALLOW REVERSE SCANS;
6.1.3 Deploying clients

The project team starts the Security Compliance Manager client rollout activities already at the beginning of the project, as illustrated in Figure 6-1 on page 116. The IT infrastructure is managed by local teams using different methods and techniques to install and maintain the systems. Therefore, the project team delegates the rollout of the Security Compliance Manager client software to the local teams, who decide on the method of the client installation. Some local administration teams use a response file to silently install the software, as described in Client installation on page 38. Other teams integrate the Security Compliance Manager client software into a Tivoli Software Distribution environment. Regardless of the installation method, the central project team provides the following guidelines for the local teams to implement: For each platform, the central team specifies a home directory for the Security Compliance Manager software. It is easier for the central support team if, in case of installation problems, if all the Security Compliance Manager client installations follow the same rules. The Security Compliance Manager home directory should not be on the root file system. In later project phases, additional policies will be implemented that cause more collectors to be deployed to the client systems. Therefore, on UNIX based systems, the Security Compliance Manager client is installed in its own file system with a size of 150 MB or more. If the clients are connected directly to the Security Compliance Manager server, they are configured as push clients, which reduces the number of connections that are open at the Security Compliance Manager server system. Push clients require less resources on the Security Compliance Manager server than pull clients. Pull clients are configured only if they are connected through a proxy relay or if required by firewall rules.
Client organization (grouping)

ABBCs IT infrastructure comprises several thousand IT systems of different kinds, as outlined in 5.1, Functional requirements on page 97. Thorough planning of the Security Compliance Manager client and group layout is key to
121
avoiding unnecessary administration overhead in the security compliance process. The project team starts analyzing the ABBCs IT administration organization. It turns out that each geography runs several teams that are responsible for a particular subset of technologies, for example, there are UNIX teams covering the different UNIX flavors, Windows teams, and database teams. The project team have an organizational view as depicted in Figure 6-3.
Organizational view
USA Admin team 1 (UNIX) DMZ webs1.ab_bank.com webs2.ab_bank.com webs3.ab_bank.com Production zone . oba_p1.ab_bank.com . oba_p2.ab_bank.com . Admin team 2 (UNIX) DMZ
ITSCM console view
Production zone Admin team 3 (Windows) Production zone Admin team 4 (Databases) Production zone oba_p1.ab_bank.com
Figure 6-3 Mapping of ABBCs IT organization to Security Compliance Manager groups
The next step is to map the administration teams and the machines they are responsible for to Security Compliance Manager client groups. The grouping of Security Compliance Manager clients aims to achieve the following targets: The Security Compliance Manager clients must be assigned to user groups so that the administration teams have only access to their own machines. Administration teams can find their own machines more easily and do not mix up machines. Security Compliance Manager reports and operational reports can be reduced to groups belonging to an administration team.
122
Figure 6-3 on page 122 also depicts the mapping of the organizational entities to Security Compliance Manager client groups. The first level of groups separates the different administration teams. Access to the first level provides access to all systems in the subgroups of the team. The second level differentiates between groups having different security policies. An important feature of Security Compliance Manager is the possibility to add one Security Compliance Manager client to different groups. For example, the UNIX administration team1 manages the system oba_p1.ab_bank.com. The database team4 is managing the same system being responsible for the DB2 database. In our example, oba_p1.ab_bank.com is a member of the group US.Team1.AIX.PROD and a member of the group US.Team4.DB2. Both administration teams have access to the same Security Compliance Manager client, but are using different policies attached to the corresponding group.
Bulk registration of clients

Having created the group schema in the Security Compliance Manager database, the project team starts to upload the IT systems to the Security Compliance Manager database. The IT systems are listed in a central database, including all relevant information required for registering with the Security Compliance Manager server. The project team wants to automate the registration process in the beginning of the project, as several thousand machines are involved. They export the list of IT systems in a comma separated value (CSV) format. Based on this list, there are two options to automatically register the clients: Security Compliance Manager command line tools Security Compliance Manager provides the command line tool scmregisterclient to register clients. The command takes the following client attributes: Name of the client Client type (push or pull) Client port This information is sufficient to register a client. Additional fields, like the proxy relay to be used and the description field, have to be filled in manually. The CLI command scmaddgroupclient adds clients to their client groups. Using the CLI commands does not require a Security Compliance Manager server reboot and is the recommended method. Database import There is the option to import the CSV data directly into Security Compliance Managers database, which is very useful for the initial upload of many IT systems at once. This method requires a restart of the Security Compliance
123
Manager server so that the server recognizes the new clients. Additionally, a unique client ID has to be provided. The project team already created a complete CSV list containing ABBCs IT systems. Each line of the CSV file is formatted in the following way:
<client ID>, <IP address>, <proxy ID>, <client port>, <can masquerade>, <client name>, <offline (x=offline)>, <client type(3=PULL,2=PUSH)>, <description>
Here are some example entries from this CSV file:

2,"10.92.93.57.68",1,1950,,"webs1.ab_bank.com","3",,"Web server" 3,"10.92.93.57.69",1,1950,,"webs2.ab_bank.com","3",,"Web server" 4,"10.92.93.57.70",1,1950,,"webs3.ab_bank.com","3",,"Web server" 5,"10.93.25.10",1,1950,,"oba_p1.ab_bank.com","3",,"Online banking system" 6,"10.93.25.11",1,1950,,"oba_p2.ab_bank.com","3",,"Online banking system"
Another CSV file contains client IDs and group IDs reflecting the group membership of the new clients. The client IDs in both examples correspond to the values shown in Figure 6-3 on page 122. Here are some entries from this CSV file:
2,2 2,3 2,4 15,5 15,6
The complete list of clients and their group membership information can be uploaded using the following DB2 commands:
db2 import from <client CSV file> of del messages /tmp/scm_import.msg insert into jac_sys.clients db2 import from <group CSV file> of del messages /tmp/scm_import.msg insert into jac_sys.gro_cli_members
After importing the client and group information, the Security Compliance Manager server needs to be restarted. Therefore, this method is not recommended to be used after the initial upload. The advantage of this method is that the clients are uploaded using one command and all required fields like proxy information and description fields are included.
Tracking of the rollout progress

The Security Compliance Manager administration console displays the Security Compliance Manager clients as inactive as long as the actual rollout of the client software takes. During the rollout phase, more and more Security Compliance Manager clients will change automatically into the active state. Security Compliance Manager provides the CLI command scmlistclients. This command lists the client attributes and the client status, as shown in Example 6-1 on page 125.
124
Example 6-1 Result of the scmlistclients command Registered clients for server: abbc_scm1 Client name: cc_p1.ab_bank.com (ID = 1) Client name: webs1.ab_bank.com (ID = 2) Client name: webs2.ab_bank.com (ID = 3) Client name: webs3.ab_bank.com (ID = 4) Client name: oba_p1.ab_bank.com (ID = 5) Client name: oba_p2.ab_bank.com (ID = 6) active active inactive active - inactive - inactive
The client list, including the clients status, provides enough information for the project team to control if the Security Compliance Manager client software is installed and if the client connectivity is configured correctly at the firewalls between the Security Compliance Manager server and the subnetworks. Alternatively, the project team can create a Security Compliance Manager internal report querying the Security Compliance Manager clients operating system version. When the Security Compliance Manager client is connected successfully, the client provides the operating system version to the Security Compliance Manager server, which stores the value in the column OS_NAME of the Security Compliance Manager database table jac_sys.clients. The corresponding report uses the following SQL statement:
select cli_id, alias, primary_ip from jac_sys.clients where OS_NAME is null
This query lists all clients that were never connected to the Security Compliance Manager server.
Implementing delegated administration

Security Compliance Manager provides a role based access control system that is conceptually described in 3.2.5, Delegated administration on page 63. The project team implements the administration model depicted in Figure 6-4.
Functions: Manage snapshots Execute reports Test collector View clients Group Objects: US.Team1.AIX.DMZ US.Team1.AIX.PROD US.Team1.Solaris
Administration team US_Team1
User Groups
Roles
System Admin Role (Template) US-Team1 US-Team2 US-Team3 ... Senior Admin Role Snapshot Admin Role Policy Admin Role
Maintenance team
US_Team1 US_Team2 US_Team3 Maintenance Audit
Policy Objects: ABBC_AIX_PROD ABBC_AIX_DMZ ...
Security Audit Team
Figure 6-4 Administration concept for Security Compliance Manager server
125
The first step is to define the user groups. There is one user group for each local administration team, the maintenance team, and the security audit team. The project team assigns Security Compliance Managers default Senior Admin Role to the Maintenance user group. It provides the maintenance team with all administration rights. The security audit team requires only the ability to schedule snapshots and assign policies. This functionality is provided by the default roles Snapshot Admin and Policy Admin. The local IT administration teams require all the same Security Compliance Manager functions to create ad-hoc snapshots, run reports, and validate the Security Compliance Manager client status, but on different Security Compliance Manager objects. Therefore, the project team creates the role template System Admin Role, which grants the required Security Compliance Manager functions. The required Security Compliance Manager objects, such as group objects and policy objects, are assigned to the team roles. Start the Security Compliance Manager administration console and open the folder Users/Roles Roles, click the Create Role button, specify a role name, and confirm by clicking OK. Next, select Template in the Type section. Clicking Add Resource Tabs opens a window that offers the function types that you can add to the role template. Select Client Groups, Clients, Policies, and Reports, as shown in Figure 6-5.
Figure 6-5 Creating the System Admin Role
126
Click OK and select the functions for each function type as required. For the administration teams select View groups, Test collectors, Manage snapshots, and Execute reports. Click Save Role Information. In the next step, you have to create an administration team role. Click Create Role again and specify the role name US-Team1. This time, select Normal as the role type. Right-click the newly created role and select Inherit permissions from template, as shown in Figure 6-6.
Figure 6-6 Inheriting permissions from a template
The user team role is now listed as a child of the System Admin Role template, as shown in Figure 6-7. Add the resource objects to the team role. For example, in the Client Groups tab in the Role Definition section, click Add Resources. In the Add Resources windows, select the groups belonging to the administration team, and click OK.
Figure 6-7 Adding objects to the team role
You have to perform the same actions for the policies and reports required by the administration team and store the role by clicking the Save Role Information button. If a large number of client and group objects have to be added to a role,
127
you should consider using SQL statements to add clients to a role. For example, if all clients belonging to US-Team1 should be added to the role, you can use the SQL statement shown in Example 6-2. You have to replace ROLE_NAME with the name of the role, as displayed in the Security Compliance Manager administration console, and LIST_OF_GROUP_IDS with the Security Compliance Manager group IDs belonging to the role. The Security Compliance Manager server makes use of the new configuration immediately.
Example 6-2 Adding clients to a role using SQL select distinct r.rol_id, o.obj_id, c.cli_id from jac_sys.clients c, jac_sys.roles r, jac_sys.gro_cli_members m, jac_sys.groups g, jac_sys.object_class o where m.cli_id_child = c.cli_id and g.gro_id = m.gro_id_parent and g.gro_id in (<LIST_OF_GROUP_IDS>) and c.cli_id not in ( select rm.id from jac_sys.rol_obj_mapping rm where rm.rol_id = r.rol_id and rm.obj_id = o.obj_id ) and o.classname = com.ibm.jac.server.JACClientImpl and r.name = <ROLE_NAME>
6.1.4 Installing the reporting server

Crystal Enterprise provides a publishing platform for interactive reports. End users can access the reports via a Web application. Crystal Enterprise consists of a number of different components that can be logically grouped based on the type of work they perform, the client tier, the intelligence tier, the processing tier, and the data tier. The components that make up each of these tiers can be installed on one machine, or spread across many. More details about the Crystal Enterprise components can be found in the Crystal Enterprise 9 Administrators Guide, which is located in the directory /docs on the installation media. The ABBC project team decides to install all Crystal components on one Windows 2000 server system. The Automated Process Scheduler (APS) is responsible for maintaining the APS database, which contains, for example, information about users and groups, authorization data, location of reports, and job schedules. By default, Crystal Enterprise installs the Microsoft MSDE database system to manage its data. The ABBC project team decides to use the existing DB2 database server to store the APS data due to the following reasons: Avoid the effort and necessary skills of maintaining two different databases. Lack of MSDE specific database management knowledge within ABBC.
128
The MSDE database system does not include database management tools comparable to those available in DB2. The overview of the required components is depicted in Figure 6-8.
Reporting Server Crystal Enterprise Components APS
DB2 Database Server JAC
IBM HTTP Server
CE90
Figure 6-8 Components for the reporting environment
Installation of IBM HTTP Server

The IBM HTTP Server can be downloaded from IBMs Web site using the following URL:
http://www.ibm.com/software/webservers/httpservers/
In our example, we use IBM HTTP 1.3.28. The installation instructions are available at the following URL:
http://www.ibm.com/software/webservers/httpservers/doc/v1328/htdocs/en_US/m anual/ibm/9ainstal.htm
Note: Please make sure you do not use IBM HTTP Server Version 2.x, because this does not work correctly with Crystal Enterprise.
Configuring SSL for IBM HTTP Server

ABBCs security guidelines require you to encrypt the traffic containing user credentials and security compliance data. Therefore, the project team configures SSL to be used for all communications. The following steps describe how to configure SSL for the IBM HTTP Server: When you set up secure connections, you have to configure a digital certificate for the HTTP server. There are two ways to obtain a certificate: Buy a certificate from an external CA provider. Create a self-signed certificate.
129
If you want to create a new self-signed server certificate, then start the IBM Key Management Utility, which can be located in C:\Pogram Files\ibm\gsk5\bin\gsk5ikm.exe. In our example, we use self-signed certificates. Create the directory C:\Program Files\IBM HTTP Server\keytab, where you will store the servers certificate. Start the IBM Key Management Utility by selecting Key database File New from the menu bar. Select CMS key database file and enter the file name and location for the certificate. You will be prompted for a password to protect the certificate, as shown in Figure 6-9. You have to specify the expiration time for the certificate and select Stash the password to a file. This is required to avoid specifying the password each time you start the HTTP server. ABBCs security policy allows you to store passwords in stash files.
Figure 6-9 Saving the certificate password in a stash file
Select OK and acknowledge a window confirming that the password was saved in the stash file. Now you have to create the new certificate. Select Create New Self-Signed Certificate... from the menu bar. In the Create New Self-Signed Certificate window, enter all entries required for the certificate, as shown in Figure 6-10 on page 131. Make sure that the attribute Common Name equals the host name of the reporting server.
130
Figure 6-10 Attributes for the self-signed certificate
Click OK and see the new certificate stored in the Personal Certificates folder. Now follow the instructions documented in the online documentation of the IBM HTTP Server. Usually, the online documentation is stored under <HTTPD_HOME>\htdocs\en_US\manual\ibm\index.html. The SSL configuration of the HTTP server adds the following lines, displayed in Example 6-3, to the configuration file, which is stored in <HTTPD_HOME>\conf.
Example 6-3 SSL configuration section for IBM HTTP Server Listen 443 <VirtualHost report_s1.pzone.abbc.com:443> ServerName report_s1.pzone.abbc.com SSLEnable Keyfile "c:/program files/ibm http server/keytab/test.kdb" SSLV2Timeout 100 SSLV3Timeout 1000 DocumentRoot "C:/Program Files/IBM HTTP Server/crystal" SSLClientAuth none </VirtualHost>
131
Creating the APS database

Create a new APS database on the DB2 database server using the existing instance for Security Compliance Manager. Log in to the database server as the instance owner and create the database using the following command:
db2 create database CE90
This command creates a new database with default settings for most of the database parameters.
Installation of IBM DB2 client

To enable database connections from the reporting server to the DB2 database server, you have to install the DB2 database client.
Configuration of APS and DB2 connections

You have to configure DB2 database connections from the reporting server to the DB2 database server. During report generation, the Crystal Enterprise components have to access compliance data stored in the JAC database. The APS requires a DB2 database connection to its APS database that we created on the database server. For both connections, we use the DB2 client configuration assistant that is installed with the DB2 client. Usually, the DB2 client configuration assistant can be found by selecting Start Programs IBM DB2. Let us take a closer look at the necessary configuration steps using the example of the JAC database connection starting with the Welcome window in Figure 6-11 on page 133.
132
Figure 6-11 DB2 Client configuration assistant
In the Welcome window, select Add Database. In the following window (Figure 6-12), select Manually configure a connection to a database and click Next.
Figure 6-12 DB2 Add Database Wizard: Source
Select TCP/IP as the communication protocol to the DB2 database server and click Next.
133
Figure 6-13 DB2 Add Database Wizard: Protocol
In the next tab (Figure 6-14), specify the host name and port number of the Security Compliance Manager database configuration. The port number is defined in the /etc/services file of the database server. In our case, you have to specify port 50000 and select Next.
Figure 6-14 DB2 Add Database Wizard: TCP/IP configuration
In the next tab (Figure 6-15 on page 135), you have to enter the database name JAC for the Security Compliance Manager database and select Finish.
134
Figure 6-15 DB2 Add Database Wizard: Database configuration
The next window (Figure 6-16) confirms that the connection configuration was added successfully.
Figure 6-16 DB2 configuration confirmation
The next step is to test the connection. You have to make sure that the connection works correctly before continuing with the installation of the reporting server. Select Test Connection and specify the user ID and password for the Security Compliance Manager database. If the connection can be established successfully, the window shown in Figure 6-17 on page 136 appears.
135
Figure 6-17 DB2 installation message
Repeat the same steps for the database connection to the APS database CE90 that you created on the database server.
Installation of Crystal Enterprise 9

The setup program for Crystal Enterprise 9 is located in the root directory of the Crystal Enterprise 9 CD. Attention: Crystal Enterprise 9 must be installed directly using the system console. Remote installation using Windows Terminal Services Client is not possible. Start the setup program and the window shown in Figure 6-18 on page 137 appears.
136
Figure 6-18 Crystal Enterprise: setup window
We select Next, accept the Crystal Enterprise 9 for Tivoli license agreement (see Figure 6-19), and select Next.
Figure 6-19 Crystal Enterprise: license agreement
In the next window (Figure 6-20 on page 138), select the Custom installation option. The New option would install the complete set of Crystal Enterprise
137
components, including the MSDE database as the database system for the APS database. To avoid that action, you have to select the Custom installation. This option allows you to select only the required components.
Figure 6-20 Crystal Enterprise: installation types
Click Next. In the next window, open the Crystal APS folder and right-click the MSDE entry. Deselect the APS database from installation by clicking Entire feature will be unavailable, as depicted in Figure 6-21 on page 139.
138
Figure 6-21 Crystal Enterprise: custom installation window
Deselect the database drivers as well; they are not needed. Click Next. In the following window, you have to specify that you do not want to cluster the APS with an existing cluster, as this is the first installation of Crystal Enterprise 9. The next window asks for the database driver you want to use. Select the DB2 Database driver and click Next, as shown in Figure 6-22.
Figure 6-22 Crystal Enterprise: APS database type selection
139
In the next window (Figure 6-23), provide the logon information for the APS database. As the server, we use the database alias CE90 for the DB2 database connection that we configured in Configuration of APS and DB2 connections on page 132.
Figure 6-23 Crystal Enterprise: APS configuration
Click Next and start the installation program. After a successful installation, Crystal Enterprise is started automatically as a Windows service. Using the Crystal Configuration Manager, you can check the status of the Crystal components, as shown in Figure 6-24 on page 141.
140
Figure 6-24 Crystal Enterprise: configuration manager
Configure IBM HTTP Server for Crystal Enterprise 9

The installation program of Crystal Enterprise 9 installs the Web connector files so no special installation is required. All that is needed is to configure the IBM HTTP Server for Crystal Enterprise 9. In our example, IBM HTTP Server and Crystal Enterprise are installed on the same system. We already modified the httpd.conf file in Example 6-3 on page 131. You have to add the configuration lines marked in bold, as shown in Example 6-4.
Example 6-4 IBM HTTP Server configuration for Crystal Enterprise Alias /viewer/ "C:/Program Files/Common Files/Crystal Decisions/2.0/crystalreportviewers" Alias /crystalreportviewers "C:/Program Files/Common Files/Crystal Decisions/2.0/crystalreportviewers" Alias /crystal/Enterprise9/ "C:/Program Files/Crystal Decisions/Web Content/Enterprise9/" Listen 443 <VirtualHost report_s1.pzone.abbc.com:443> ServerName report_s1.pzone.abbc.com SSLEnable Keyfile "c:/program files/ibm http server/keytab/test.kdb" SSLV2Timeout 100 SSLV3Timeout 1000 DocumentRoot "C:/Program Files/IBM HTTP Server/crystal" SSLClientAuth none AddType Magnus-Internal/rpt .rpt AddType Magnus-Internal/csp .csp
141
AddType Magnus-Internal/cri .cri AddType Magnus-Internal/cwr .cwr Action Magnus-Internal/rpt /cgi-bin/wcscgi.cgi Action Magnus-Internal/cwr /cgi-bin/wcscgi.cgi Action Magnus-Internal/csp /cgi-bin/wcscgi.cgi Action Magnus-Internal/cri /cgi-bin/wcscgi.cgi </VirtualHost>
You have to restart the IBM HTTP server to activate the changes. Attention: Make sure that the server name is specified without a dot after the server name. If the httpd.conf file contains a line like:
ServerName report_s1.
please remove the dot after the ServerName. If a dot is added to the server name, the relative path links used in Crystal Enterprise will not work.
6.1.5 Configuring operational reports

The operational reports provided by Security Compliance Manager need to be installed in the Crystal Enterprise server. The steps for installing and scheduling the operational reports are described in the IBM Tivoli Security Compliance Manager Version 5.1 Fix Pack 5.1.0-TIV-SCM-FP0009 February 18, 2005 Operational Reports Reference. By default, the reports are found in the path Home Folders Tivoli Reports ITSCM Operational Reports, as shown in Figure 6-25 on page 143. The next step is to configure the access rights for the operational reports that are called object rights in Crystal Enterprise. Object rights are the base units for controlling users' access to folders, reports, and other objects. When granted, each right permits a user or a user group to perform a particular action on an object. To facilitate administration and maintenance, Crystal Enterprise includes a set of predefined access levels that allow setting common security levels quickly. The Crystal Enterprise administrator's guide recommends using the predefined access levels whenever possible, because they can greatly reduce the complexity of the object security model. The following list provides a brief description of some of the predefined access levels: No Access View Schedule The user or group is not able to access the object. Allows you to view the folder and the objects contained in the folder. Allows you to view the object or folder and its contents, and to generate instances by scheduling the object. The user or group
142
can view, delete, and pause the scheduling of instances that they own. Full Control This access level grants all of the available access rights. It is the only access level that allows users to delete objects. Basically, this access level is designed to provide a user or group with administrative control over one or more objects without being an administrator.
Figure 6-25 Default folder for Security Compliance Manager operational reports
The project team decides to follow the recommendations in the administrators guide. They define user groups based on the access requirements depicted in Figure 5-2 on page 108: IT system administration and IT management These groups get View permission for all reports. Security audit team The security audit team gets Schedule permission. The team members need to manage their schedules to create reports in regular intervals. Security Compliance Manager maintenance The maintenance team members require Full Control access to administer the Crystal Enterprise application. The project team defines the users and groups using the Crystal Management Console (CMC). The access rights are configured on the folder level. Go to the folder containing the reports and select the menu entry Rights, as shown in Figure 6-25. In the Rights view shown in Figure 6-27 on page 145, click the Add/Remove... button. Figure 6-26 on page 144 shows the window that allows you to select the user groups that must have access to the folder and its reports. Select the user groups in the Available groups list and click the > button to move them to the list on the right side.
143
Figure 6-26 Selecting user groups for the report folder
Clicking OK loads the window shown in Figure 6-27 on page 145. User groups and users that are not shown in the names list do not have access permissions that go beyond what is defined for the user group Everyone. Select the correct access level for each user group using the drop-down list and store the configuration by clicking the Update button.
144
Figure 6-27 Granting access permissions for user groups
6.2 Deployment phase II

Deployment phase II of ABBCs security compliance project aims to achieve the following targets: Integrate the Security Compliance Manager infrastructure into ABBCs IT environment. Reconfigure the Security Compliance Manager server to exploit Tivoli Access Managers sophisticated authentication mechanism. Integrate Security Compliance Manager with Tivoli Risk Manager. Enhance the Security Compliance Manager policies to cover ABBCs security policy. In the following sections, we describe the concepts of the integration tasks and installation steps. In 6.2.3, Collector development on page 151, we describe the implementation steps for a new Security Compliance Manager policy for Tivoli Risk Manager.
145
6.2.1 Tivoli Access Manager integration

In most IT environments, authentication and authorization is tightly coupled to individual applications. Companies typically build applications over time to serve their business needs. Many of these applications require some specific form of authorization. The result is often a wide variety of applications with differing authorization implementations. These proprietary authorization implementations require separate administration, are difficult to integrate, and result in higher costs of ownership. A distributed authorization service can provide these independent applications with a standard authorization decision-making mechanism. The benefits of such a standard authorization service would include: Reduced cost of developing and managing access to applications Reduced total cost of ownership and management of separate authorization systems Leveraging the existing security infrastructure Years ago, ABBC initiated a project to implement a centralized, solid, and easy-to-manage security architecture protecting ABBCs assets from external and internal attacks. ABBC chose Tivoli Access Manager as the strategic product to implement their security policy. The IBM Redbook Enterprise Business Portals II with IBM Tivoli Access Manager, SG24-6885 describes the implementation of ABBCs Access Manager infrastructure and how Access Manager protects external Web resources, internal communication links, and provides for centralized security management. One of the most important goals was to create a solid platform for access control with the following advantages: A common base for storing and managing user accounts and passwords. The service is centrally managed and therefore easy to administer; the addition of a new employee, for example, requires modifying the privilege database in one central location, rather than across multiple systems. The service has a scalable and flexible architecture that can be easily integrated with an existing infrastructure. The service uses a common and effective auditing model. The service is independent of any authentication mechanism. Implementation of sophisticated password rules. Definition of allowed login times for administrators and users. Definition of maximum login attempts. By default, the Security Compliance Manager server does not enforce any password rules or perform any password strength testing and no mechanism exists to recover a forgotten password. Consequently, ABBCs project team decides to integrate Security Compliance Manager with the existing Tivoli Access
146
Manager environment and exploit its sophisticated access control mechanisms. The following sections describe the three installation and configuration steps: Install and configure Access Managers Java Runtime Environment (JRE). Configure Security Compliance Managers JRE for Access Manager authentication. Configure Security Compliance Manager server to use JAAS authentication.
Install and configure the Access Manager JRE

Installation, configuration, and testing the Access Manager Java Runtime Environment (JRE) on AIX consists of the following steps: 1. Install the Access Manager JRE on the Security Compliance Manager server node. Follow the instructions in Chapter 8, Setting up a Java runtime environment system, in the IBM Tivoli Access Manager Base Installation Guide Version 5.1, SC32-1362. 2. Make sure that you are not using the Security Compliance Managers Java environment, but the Java environment in /usr/java131/jre/bin using the command which java. 3. Configure the Access Manager JRE environment in the directory /usr/java131 using the command shown in Example 6-5.
Example 6-5 Configuration command for Access Managers JRE java com.tivoli.pd.jcfg.SvrSslCfg -action config -admin_id <master administration ID of your Access Manager environment> -admin_pwd <password for master administrator> -appsvr_id <name of your SCM Server application, The application ID must be unique. Other instances of the application running on this or other systems must each be given a unique ID.> -appsvr_pwd <password for the keystore file> -host <host name of SCM server> -mode remote -port 900 -policysvr <host name of your policy server:7135:1> -authzsvr <host name of your authorization server:7136:1> -cfg_file <filename for configuration file to be created> -key_file <filename for keystore file> -cfg_action create
147
4. Before integrating the Security Compliance Manager application, we recommend testing the Access Managers JRE setup using a sample application. You can use the example provided by Suns JAAS Authentication Tutorial at:
http://java.sun.com/j2se/1.4.2/docs/guide/security/jaas/tutorials/GeneralAc nOnly.html
If the authentication using Access Managers JRE works, you can continue with the integration of Security Compliance Manager and Access Manager.
Configure JRE for Access Manager authentication

Configuring Security Compliance Manager for Access Manager authentication consists of the following steps: 1. Change to the /opt/IBM/SCM/server/jre/lib/ext directory using the following command:
cd /opt/IBM/SCM/server/jre/lib/ext
2. Move the ibmjcaprovider.jar and indicim.jar to ibmjcaprovider.jar.SCM and indicim.jar.SCM using the following commands:
mv ibmjcaprovider.jar ibmjcaprovider.jar.SCM mv indicim.jar indicim.jar.SCM
Tivoli Access Manager will explicitly delete the ibmjcaprovider.jar without warning. Therefore, these libraries have to be renamed. 3. Configure the Access Managers Java environment to the Security Compliance Manager Java environment using the following syntax and command (Example 6-6):
pdjrtecfg action config -host <policy_server_host> [port policy_server_port] [java_home jre_home] [domain domain_name] [config_type full] [enable_tcd [tcd path]] Example 6-6 Configuration command for Java environment <PDJRTE_HOME>/sbin/pdjrtecfg -action config -host itsosec8.itsc.austin.ibm.com -java_home /opt/IBM/SCM/_jvm/jre The output of the command is: Configuration of Access Manager Java Runtime Environment is in progress. This might take several minutes. Configuration of Access Manager Java Runtime Environment completed successfully.
148
4. Copy the configuration file PdPerm.properties from /usr/java131/jre into /opt/IBM/SCM/_jvm/jre. 5. Change to the /opt/IBM/SCM/jars directory using the following command:
cd /opt/IBM/SCM/jars
6. Move the Security Compliance Manager provided jaas.jar to jaas.jar.SCM using the following command:
mv jaas.jar jaas.jar.SCM
7. Link the ibmjcaprovider.jar.SCM and indicim.jar.SCM locally as JAR files using the following command:
ln -s /opt/IBM/SCM/server/jre/lib/ext/ibmjcaprovider.jar.SCM ibmjcaprovider.jar ln -s /opt/IBM/SCM/server/jre/lib/ext/indicim.jar.SCM indicim.jar
8. Change to the /opt/IBM/SCM/jars/boot directory using the following command:

cd /opt/IBM/SCM/jars/boot
9. Move US_export_policy.jar, ibmjcefw.jar, ibmjceprovider.jar, ibmjsse.jar, and local_policy.jar to .SCM extensions using the following command:
mv mv mv mv mv US_export_policy.jar US_export_policy.jar.SCM ibmjcefw.jar ibmjcefw.jar.SCM ibmjceprovider.jar ibmjceprovider.jar.SCM ibmjsse.jar ibmjsse.jar.SCM local_policy.jar local_policy.jar.SCM
Configure server to use JAAS authentication

The final step is the re-configuration of the Security Compliance Manager server to use the JAAS authentication module. 1. Change to the /opt/IBM/SCM/server directory using the following command:
cd /opt/IBM/SCM/server
2. Copy the server.ini file to a backup file, and modify the server.ini file in a text editor so that:
jac.security.authenticator=com.ibm.jac.server.JACAuthenticator
becomes:
#jac.security.authenticator=com.ibm.jac.server.JACAuthenticator
and insert:
jac.security.authenticator=com.ibm.jac.server.JACJaasAuthenticator jac.security.jaasconfiguration=JaasAuthentication
149
3. Change to the /opt/IBM/SCM/etc directory using the following command:

cd /opt/IBM/SCM/etc
4. Create a file named tamauthentication.config containing:

JaasAuthentication { com.tivoli.mts.PDLoginModule required; };
5. Change to the /opt/IBM/SCM/server/_jvm/jre/lib/security directory using the following command:

cd /opt/IBM/SCM/server/_jvm/jre/lib/security
6. Copy the java.security to a backup file and modify java.security to append the following lines:
# Configure Access Manager for login login.configuration.provider=com.ibm.security.auth.login.ConfigFile login.config.url.1=file:/opt/IBM/SCM/etc/tamauthentication.config
The file tamauthentication.config is the configuration file created during the Access Manager JRE configuration in Example 6-5 on page 147. 7. Restart the Security Compliance Manager server. The user authentication will now be performed by Tivoli Access Manager. User passwords and user IDs have to be managed using Access Managers administration and user tools. Attention: Tivoli Access Manager is used to perform authentication of users. The Security Compliance Manager server still performs authorization of user requests. Therefore, user IDs have to be created in Security Compliance Managers database using the Security Compliance Manager administration console.
6.2.2 Tivoli Risk Manager integration

The Tivoli Risk Manager integration consists of two independent steps: Security deviation notification Security Compliance Manager informs Tivoli Risk Manager about a security compliance deviation immediately after detecting it. Tivoli Risk Manager monitoring Security Compliance Manager controls the correct configuration of the Risk Manager components to avoid undetected intrusion attempts.
150
Security deviation notification

In 3.2.8, Integration with Tivoli Risk Manager on page 68, we describe the concept of integrating Security Compliance Manager with Tivoli Risk Manager. IBM provides a Tivoli Risk Manager adapter for IBM Tivoli Security Compliance Manager that routes compliance violation information detected by Security Compliance Manager to IBM Tivoli Risk Manager. The IBM Tivoli Security Compliance Manager Version 5.1 Tivoli Risk Manager Adapter Guide describes in detail the installation and configuration steps for the Security Compliance Manager Adapter.
Tivoli Risk Manager monitoring

Tivoli Risk Manager is a security monitoring tool that detects system attacks aimed at ABBCs IT infrastructure. Therefore, it is important that Tivoli Risk Manager is installed and running properly on all required systems. Based on this requirement, the Security Compliance Manager policy for Tivoli Risk Manager has to cover the following monitoring tasks: Is the Tivoli Risk Manager installed on a given system? Is the Tivoli Risk Manager component running? Which version of the Tivoli Risk Manager filterset and ruleset is used? In order to answer these questions, the Security Compliance Manager policy for Tivoli Risk Manager requires additional information that is not collected by the Java collectors provided with IBM Security Compliance Manager policies. In 6.2.3, Collector development on page 151, we describe the steps required to implement an additional Java collector for Security Compliance Manager.
6.2.3 Collector development

A collector is a Java language-based software module, packaged as a Java Archive (JAR) file, that collects specific information from a client system. In this section, we discuss the steps of collector development using the example of the Security Compliance Manager collector for Tivoli Risk Manager. First, we discuss some of the design guidelines given in the IBM Tivoli Security Compliance Manager Version 5.1 Collector Development Guide, SC32-1595. In the next step, we demonstrate the major design tasks of collector development and discuss implementation options. Appendix A, Developing a custom collector on page 173 lists the complete source code of the Security Compliance Manager collector for Tivoli Risk Manager.
151
Collector design guidelines

ABBCs development team has to decide on a number of design guidelines for their collector development project.
Collector releases (indicating compatible changes)

Every collector has a release number associated with it. The release number is provided in addition to the collector version number. The first release of a collector usually has a release number of 1. The collector release number increases each time the collector is modified or enhanced in a compatible way. Compatibility means that the table structure of the collector does not change. The new version number forces the Security Compliance Manager server to deploy the new collector to the Security Compliance Manager clients.
Collector versions (indicating incompatible changes)

The version number for a collector should be indicated by the name of the collector and has to be changed each time the collector is changed in an incompatible way, such as when the collector tables change. The IBM Tivoli Security Compliance Manager Version 5.1 Collector Development Guide, SC32-1595 recommends that the letter V followed by a number should be added to the name of the collector. The first version of a collector is usually indicated by V1.
Collector naming conventions

The IBM Tivoli Security Compliance Manager Version 5.1 Collector Development Guide, SC32-1595 recommends the following naming convention for Security Compliance Manager collectors: operating_system.os_version.collector_nameVversion_number This naming convention informs you about the platforms the collector is designed for and its version number. For example, the collector name any.any.JavaVersionV1 would indicate that it is the version 1 of the collector and runs on any operating system platform of any version. The collector aix.aix51.MyCollectorV2 will signal that it is can be run only on a single platform version. The recommended naming convention simplifies the process of combining collectors into a policy for a specific platform.
Collector execution time

Collectors should have short execution times and be non-invasive. In general, collectors should run five seconds or less. Security Compliance Manager is designed to keep impacts on the IT systems as low as possible. Instead of performing data collection in one step influencing the IT systems performance, the collectors can be executed at different times. Therefore, each data collector should perform only a single task within a limited time frame.
152
Completeness of collected data

The collector has to return data that can be interpreted by the SQL statement of the compliance object without uncertainty. If there are any errors during the data collection phase the returned data has to reflect this situation. If a collector does not return any data, the compliance object assumes that the execution of the collector failed.
Use one collector for all platforms or single platform collectors

Obviously, the answer to this question depends on the diversity of the platforms. In most cases, we recommend implementing single platform collectors if there are changes between the platforms. Implementing cross platform collectors results in: Cross platform collectors will be changed more often if any of the supported platforms will change. Differences in the platforms will result in a lengthy source code and make the collector source code less readable if you have to use multiple if-then-else statements. Developers of cross platform collectors need to have knowledge about all the platforms. Splitting the development among multiple developers is difficult. Changes in a cross platform collector requires modifications in multiple policies bundles. The same is true for differences between different versions and flavors of a platform, for example, differences between AIX V4.3 and AIX 5L V5.1 or between Windows NT and Windows 2000. To cover this design option, IBM provides collector naming conventions in the IBM Tivoli Security Compliance Manager Version 5.1 Collector Development Guide, SC32-1595 that tell you on which platforms the collector is able to run. Additionally, during execution, the collectors return a list of supported operating systems.
Collector design phase

During the collector design phase, the development team has to answer the following questions, which describe the major design options: Which platforms must be supported by the collector? What kind of data has to be gathered by the collector in order to implement the policy? How can a collector access that data on a given platform? How many collectors are required to gather that data?
153
Platform coverage
The development team inspects ABBCs Risk Manager infrastructure. They discover that the Tivoli Risk Manager Agent is installed on the platforms AIX, Sun Solaris, Linux, Windows NT, Windows 2000, and Windows 2003. The Tivoli Risk Manager collector has to run on all these platforms.
Data collection
In Tivoli Risk Manager monitoring on page 151, we define that the Tivoli Risk Manager policy has to verify if Tivoli Risk Manager is installed on a given system, if the Risk Manager Agent is running, and if the correct filterset is in use. In order to fulfill this task, the Risk Manager collector has to collect the following data: Data indicating that the Tivoli Risk Manager agent is installed The Microsoft Windows platforms have a feature called the registry, which contains registry keys and their values. The Tivoli Risk Manager program builds registry keys in a specific hierarchy. If, for example, the registry key RMHOME exists in Risk Managers registry hierarchy, as depicted in Figure 6-28, it indicates that the Tivoli Risk Manager agent is installed. If the registry key is not there, the software is definitely not installed.
Figure 6-28 Registry key for Tivoli Risk Managers home directory
Alternatively, the collector may verify if the environment variable RMHOME is set on the system. To check if Risk Manager is installed on a UNIX machine, we have to analyze the shell script file rma_eif_env.sh, which can be found at a known and defined path. This script sets variables, for example, the RMHOME value. Therefore, we check if this file exists as an indication that Tivoli Risk Manager is installed. Data indicating that the Tivoli Risk Manager agent is running Under Windows, Risk Manager is running as a service. The Risk Manager service always has the name "Risk Manager Agent". So you can check through if the service is started or not, as indicated in Figure 6-29 on page 155.
154
Figure 6-29 Service entry for Tivoli Risk Manager Agent
Alternatively, we can use the command net start, which returns a list of started processes. On UNIX, we have to use the command ps to verify if the Risk Manager Agents process rmagent is running. Data indicating that the current Risk Manager policy is in use It is important for the security of ABBCs environment that the Tivoli Risk Manager agents react to specific events according to ABBCs security policy. In ABBCs Risk Manager infrastructure, this configuration information is stored in the file filterset/ruleset/policy. Unauthorized modifications to this file may cause the Tivoli Risk Manager agents to misinterpret events and overlook attacks, so you must limit the users that can change the filterset. Collecting the complete policy of the Risk Manager Agent and verifying its correctness would be a troublesome task. A better option to implement this task is creating a hash of the filterset. A hash produces a specific number for a given object. The word 'tree', for example, may be mapped to the hash-value 5, and the sentence "Java is nice" to the hash-value "27". The important characteristic of a hash-value is that it is unique for each object. Even if you change a period into a comma in a large file, the hash-value will change completely. Therefore, the collector can build a hash of the filterset on a system to be monitored and store this value in the Security Compliance Manager database. This value is compared to the hash of the correct policy. If they are identical, everything is okay; if they vary, we can be sure that someone manipulated the filterset.
Design decisions
Based on the alternatives listed in the previous sections, ABBCs development team makes the following design decisions: The Tivoli Risk Manager policy requires data that can be stored in a single table in the Security Compliance Manager database schema jac_idata. This results in a single collector to be implemented, as each table belongs to a specific collector. The data to be collected is: Tivoli Risk Manager is installed. The team decides to verify if the RMHOME environment variable is set on a Windows system. This option avoids accessing the registry, which reduces the platform differences.
155
Risk Manager runtime information. The collector gathers runtime information using commands on Windows and UNIX systems. A hash of the Risk Managers ruleset. The collected data is stored in a database table using the following columns: TYPE VERSION The column TYPE defines the type of the returned data. If a record contains the entry TRM in the column TYPE, then the VERSION entry indicates if the Risk Manager Agent is installed. If a record contains the entry MD5 in the column TYPE, then the VERSION entry contains the name of the Risk Manager rule set file. If a record contains the entry TRM in the column TYPE, then the VERSION entry indicates if the Risk Manager Agent is running. If a record contains the entry MD5 in the column TYPE, then the VERSION entry contains the hash value of the Risk Manager rule set file.
VALUE
Figure 6-30 shows an example of values returned by the Tivoli Risk Manager collector.
Figure 6-30 Data returned by the Tivoli Risk Manager collector
Due to the minimal platform differences between UNIX and Windows, the team decides to implement a single collector that covers all platforms. The advantage is to have a single Risk Manager policy that can be attached to all infrastructure systems that need a Risk Manager Agent. The name of the collector will be any.any.TivoliRiskManagerV1.
156
Collector implementation phase

A collector is a Java language-based software module, packaged as a Java Archive (JAR) file. The classes and methods specific to Tivoli Security Compliance Manager collectors are provided in the client.jar file. The client.jar file is installed with the client component of Tivoli Security Compliance Manager. Any additional classes required to implement the collector have to be included in the collectors JAR file. The collectors library environment is depicted in Figure 6-31.
ITSCM Java collector (JAR file) ITSCM Java collector class
ITSCMs client.jar
Java libraries required by the collector
Java SDK 1.3.1
Figure 6-31 Security Compliance Manager Java collector JAR file
Collectors run in the Java Virtual Machine (JVM) of the Tivoli Security Compliance Manager client, which uses Java Version 1.3.1. Each collector instance runs in its own thread. On UNIX systems, the collectors run with root authority. On Microsoft Windows systems, the collectors run using the local system account. A collector extends the com.ibm.jac.CollectorV2 class that is implemented in the client.jar file. The collector needs to implement a set of required methods, which are called by the Security Compliance Manager client, the Security Compliance Manager server, or the Security Compliance Manager administration utilities. During installation and registration of the collector at the Security Compliance Manager server, and for display at the administration console, the following methods are called and need to be implemented by each collector: getReleaseNumber getReleaseNumber returns the release number of the collector. It is used to decide if a collector needs to be replaced on a client. getCompatibleOS returns the list of operating systems and platforms supported by the collector.
getCompatibleOS
157
getDescription
getDescription returns the text description of the collector. It is used to provide information about the collector in the administration console. Returns the names of the parameters supported by the collector. It has to return an empty Vector if no parameters are supported. If parameters are supported, the setParameters method must be implemented also. getTables returns the names and structures of the database tables that are populated by the data that the collector collects.
getParameters
getTables
After a collector is deployed to a client, the following actions are performed by the client during the next client/server heartbeat: 1. The collector JAR file is stored in the collectors subdirectory of the client, if the JAR file is not already present or if the release number of the collector has increased. 2. Any additional files packaged with the collector are stored in the scripts subdirectory in a directory with the same name as the collector. 3. A new thread is created in the JVM of the client and the constructor for the collector is called. The constructor should be an empty method. The optional start method must be used to perform any initialization needed by the collector. 4. The client calls the setParameters method to provide the collector instance with its parameters. 5. The client calls the start method. This method is optional and permits the collector to perform any required initialization. The client waits for the start method call to complete. 6. The collector instance then waits until the client calls the executeV2 method. The executeV2 method is called when the collector instance is scheduled to run, and when the Run Collector or Test Collector actions are requested using the administration console. The collector then gathers its data and queues it for transmission to the server. The thread then waits again. 7. If the parameters for a collector instance are set or changed, the client calls the setParameters method again to notify the collector instance of the change. 8. When the collector instance is being unloaded, the client calls the stop method. The stop method is optional and provides an opportunity for the collector to perform any cleanup. Figure 6-32 on page 159 illustrates the method calls made to the collector instance from the client component.
158
required methods optional methods (not implemented by the TivoliRiskManager collector) Collector instance TivoliRiskManagerV1 Client component TivoliRiskManagerV1() setParameters() start()
executeV2() stop()
Figure 6-32 Functions called by the Security Compliance Manager Client component
The TivoliRiskManager collector to be implemented consists of one class, TivoliRiskManagerV1, which extends the class com.ibm.jac.CollectorV2. The complete source code and documentation is listed in Appendix A, Developing a custom collector on page 173.
Risk Manager policy

Having implemented and tested the Security Compliance Manager collectors, you can define a new policy for Tivoli Risk Manager. Using the Security Compliance Manager administration console, go to the Policies tab and create a new policy named ABBC Risk Manager Policy. For each control, you define a Compliance Object, as shown in Figure 6-33.
Figure 6-33 Tivoli Risk Manager policy
159
The SQL statements for the compliance objects are: ABBC TRM ACTIVE
select distinct a.cli_id from jac_data.any_tivoli_riskmgr a where a.type = 'TRM' and a.value not like 'yes%'
ABBC TRM INSTALLED

select distinct a.cli_id from jac_data.any_tivoli_riskmgr a where a.type = 'TRM' and a.version not like 'yes%'
ABBC TRM POLICY VERSION

select distinct a.cli_id from jac_data.any_tivoli_riskmgr a where (a.type = 'MD5' and a.version like '%EvMonWin_Win.xml%' and a.value <> 'DKf6/DlYTSGQAn4nMEmsmsP159M=') or (a.type = 'MD5' and a.version like '%EvMonWin_Unknown.xml%' and a.value <> '0wzxW4dOwAdch17/5HQgYKhTRQQ=')
The hash values used in the SQL compliance objects need to be adjusted each time ABBC modifies the Tivoli Risk Managers ruleset.
6.2.4 Report development

Tivoli Security Compliance Manager provides a set of operational reports that can be published using Crystal Enterprise 9, as described in Security Compliance Manager operational reports on page 22. In the following section, we concentrate on the modification of the operational reports provided by Security Compliance Manager. Modifications are required to adapt the reports to ABBCs organizational structure required by the security compliance process. The project team analyzed the operational reports provided by Security Compliance Manager. It turned out that the reports fulfill the projects reporting requirements except for the organizational structure. The operational reports provide information about all the registered machines. ABBCs security compliance process requires operational reports from every administration team. The interrelationship between report development and report publishing is depicted in Figure 6-34 on page 161. The modifications described in the following paragraphs are performed using Crystal Report Professional Version 9.2.2.634. The project team acquires an upsell package from IBM that is required in order to modify and publish the operational reports.
160
report development Design GUI Report Developer Crystal Reports save report templates Operational Report Operational operational Report report template Crystal Enterprise
publishing reports Web Interface Report User
import report templates
Figure 6-34 Report development and publishing overview
Modifying operational reports

The modifications of the operational reports consists of the following tasks: Update the data source location for the report. Modify the command loading the records from the Security Compliance Manager database. Add a parameter to enable specific group IDs during the deployment of the report. Modify the report to display group information. Testing the report.
Update the data source location

Let us demonstrate the modifications of the example of the report ClientViolations.rpt. Having started the Crystal Report application, we load the report. The initial view is depicted in Figure 6-35 on page 162.
161
Figure 6-35 Operational report ClientViolations in Crystal Report
From the menu, select Database Set Datasource Location..., which opens the Set Datasource Location window. In the Replace with dialog, open the entry ODBC(RDO). The ODBC(RDO) window appears, as shown in Figure 6-36 on page 163. Select the database JAC, click Next, and specify the DB2 user name and password. Return to the Set Datasource Location window, make sure that the database entries in the Current Data Source and Replace With dialogs are selected, and click Update.
162
Figure 6-36 Selecting the JAC database as a new data source
Close the Set Datasource Location window and press F5 to refresh the report data. The Crystal Report application connects to the JAC database and loads the data required by the report.
Modify the database command

The report includes an SQL command that loads the violations from the Security Compliance Manager database. You have to modify the SQL statement so that the additional fields group name and group ID are loaded from the database. The modifications of the statement are shown in bold and italic in Example 6-7 on page 164.
163
Example 6-7 Modified SQL statement for report ClientViolations.rpt SELECTC.ALIAS, P.NAME, S.NAME, N.RUNDATE, C.DHCP, V.MESSAGE, G.NAME AS GROUP_NAME, M.GRO_ID_PARENT AS GROUP_ID FROM JAC_SYS.CLIENTS C, JAC_SYS.VIOLATIONS V, JAC_SYS.COMPLIANCE_SQL S, JAC_SYS.POLICIES P, JAC_SYS.GROUPS G, JAC_SYS.GRO_CLI_MEMBERS M, (SELECT A.RUNDATE, A.ID FROM JAC_SYS.SNAPSHOTS A, (SELECT MAX(ID) AS ID FROM JAC_SYS.SNAPSHOTS GROUP BY POL_ID) AS B WHERE A.ID=B.ID ) AS N WHERE C.CLI_ID=V.CLI_ID and C.CLI_ID = M.CLI_ID_CHILD and M.GRO_ID_PARENT = G.GRO_ID and C.CLI_ID NOT IN (SELECT V.CLI_ID FROM JAC_SYS.VIOLATIONS V, JAC_SYS.SNAPSHOTS S, JAC_SYS.VIOLATION_SUPPRESSION VS, JAC_SYS.SUPPRESSIONS_POL SP WHERE V.SNA_ID=S.ID and V.VIO_ID=VS.VIO_ID and VS.SUP_ID=SP.SUP_ID and SP.SUPPRESS_UNTIL>S.RUNDATE ) and V.COM_ID=S.ID and S.POL_ID=P.ID and V.SNA_ID=N.ID
Latest news: The SQL code has been slightly changed in Fix Pack 2 so that it looks only at full (unrestricted) snapshots. Please make sure you consult the updated product documentation. From the menu, select Database Database Expert. In the Database Expert window, right-click the Command entry in the Selected Database control. In the context menu, select Edit Command and modify the command, as shown in Example 6-7. Select OK and return to the report.
Adding the group parameter

In the next step, you have to modify the report to reduce the clients and violations included in the report to the number of records belonging to a specified group. Create a new parameter in the Field Explorer section. Right-click the entry
164
Parameter Fields and select New..., which opens the Create Parameter Field window, as shown in Figure 6-37. Enter the name of the new parameter Group ID and the prompting text. Select the Value type Number and Allow multiple values. Click OK and the new parameter is added to the list of parameter fields without a green tick. The green tick indicates that the control is already used in the report.
Figure 6-37 Adding a group parameter
You also have to modify the report to actually include the new parameter. From the menu, select Report Select Expert..., which opens the Select Expert window showing the rules that reduce the number of records selected for the report. Click the <New> tab and the Choose Field window appears. Select the GROUP_ID that is available (due to the modified database command), shown in Example 6-7 on page 164.
165
Figure 6-38 Select GROUP_ID for the select statement
Click OK and return to the Select Expert window. A new tab Command.GROUP_ID exists, as shown in Figure 6-39. From the left drop-down list, select is equal to and from the right drop-down list, select {?Group ID}, which is the parameter field you created before.
Figure 6-39 Definition of a select statement using Select Expert
166
Click OK and the parameter field Group ID has a green tick indicating that it is actually used in the report.
Modifying the report layout

The report should display the group information that is covered by the new report. For this reason, you need to add a new parameter field of type String called Admin Team. This parameter allows to specify the name of the administration team during the deployment of the report. In order to display the teams name in the report, you have to drag and drop the parameter field into the header section of the report.
Testing the report

Press F5 to refresh the report data. In the Refresh Report Data window, select Prompt for new parameter values. In the Enter Parameter Values windows, select the parameter Group ID and add the values 2, 15, 6, 4, and 5 for the US UNIX administration team, as shown in Figure 6-40.
Figure 6-40 Specifying group parameters for the UNIX administration team
167
In the refreshed report, you have to verify that only machines belonging to the US UNIX team and the corresponding violations appear in the report.
Publishing modified reports

The project team already configured operational reports that cover all IT systems of ABBC on the Crystal Enterprise server. Now the administration teams should only get access to their own reports. Therefore, the project team removes the local administration teams access to the overall reports. They create a new folder structure giving each administration team its own subfolder, as shown in Figure 6-41.
Figure 6-41 Example of group structure in Crystal Enterprise
Using the access control methods of Crystal Enterprise, each administration team is granted access to its own subfolder. 6.1.5, Configuring operational reports on page 142 describes how to set access rights on Crystal Enterprise folders. Using the publish.bat command, you have to publish the new reports to their new destinations. You have to publish the reports for each team subfolder separately. Example 6-8 shows the command for the ClientViolations report and folder US_UNIX_team1.
Example 6-8 Publishing command for placing reports in group folders TivoliCrystalPublisher.exe -sourcepath <directory containing the reports> -destfolder "US.Team1" -aps itsosec1 -apsuser Administrator -apspassword <pwd> -apsauth secEnterprise -dbserver JAC -dbdatabase JAC -dbuser db2admin -dbpassword <pwd> -overwrite 2 -logpath c:\reports\logs -loglevel 4
168
For each report, you have to configure the groups belonging to the administration team. Log in to the CMC as an administrator, select a report, and go to the Parameters tab. Figure 6-42 shows the parameter configuration window showing the new parameters for group IDs and the group name.
Figure 6-42 Additional parameters for the group report
Tip: Having specified all types of parameters, make sure you click the Update button. Missing this step will delete all your modifications in the Parameters section.
6.3 Conclusion
These configurations conclude our example deployment for IBM Tivoli Security Compliance Manager at ABBC. We have covered the design and implementation phases for the infrastructure components and for deploying Security Compliance Manager clients, collectors, policies, and reports, including the development of a new collector and modification of an operational report.
169
170
Part 3
Part
Appendixes
171
172
Appendix A.
Developing a custom collector

This appendix provides the implementation details of the Security Compliance Manager custom collector for Tivoli Risk Manager. The TivoliRiskManager collector consists of one class, TivoliRiskManagerV1, which extends the class com.ibm.jac.CollectorV2. The required methods in this appendix have to be implemented.
173
Required method getReleaseNumber()

This method (Example A-1) is defined as abstract in the CollectorV2 class and must be implemented by any collector.
Example: A-1 Required method getReleaseNumber() private static final int RELEASE = 1; public int getReleaseNumber() { return RELEASE; }
Required method getCompatibleOS()

This method (Example A-2) returns a String array containing the list of the operating systems that the collector can run on. This method is defined as abstract in the CollectorV2 class and must be implemented by any collector.
Example: A-2 Required method getCompatibleOS() private static final String[] COMPATIBLE_OS = { "Windows", SunOS", "AIX", "Linux", HP-UX" }; public String[] getCompatibleOS() { return COMPATIBLE_OS; }
Required method getDescription()

This method (Example A-3) returns a String containing the description of the collector. This method is defined as abstract in the CollectorV2 class and must be implemented by any user defined collector.
Example: A-3 Required method getDescription() private static final String DESCRIPTION = "Collector gathers installation, version, and status information of a Tivoli Risk Manager Agent"; public String getDescription() { return DESCRIPTION;
174
Required method getParameters()

This method (Example A-4) returns a Vector of Strings containing the names of the parameters supported by the collector. As the TivoliRiskManagerV1 collector does not require any parameter, we return an empty Vector. This method is defined as abstract in the CollectorV2 class and must be implemented by any collector.
Example: A-4 Required method getParameters() public Vector getParameters() { return new Vector(); }
Required method getTables()

This method (Example A-5) returns an array of class CollectorTable that describes the structure of the collector database tables. Each database table defined by the collector is represented by an array element. This method is defined as abstract in the CollectorV2 class and must be implemented by any collector.
Example: A-5 Required method getTables() private static final String[] TABLENAME = { "ANY_TIVOLI_RISKMGR" }; private static final CollectorTable.Column[][] TABLE_DEFINITION = { { new CollectorTable.Column("OS",Types.VARCHAR,30), new CollectorTable.Column("TRM_INSTALLED",Types.VARCHAR,75), new CollectorTable.Column("TRM_ACTIVE",Types.VARCHAR,25), new CollectorTable.Column("TRM_VERSION",Types.VARCHAR,15), new CollectorTable.Column("TRM_HASH_FILE",Types.VARCHAR,150), new CollectorTable.Column("TRM_HASH_VALUE",Types.VARCHAR,75) } }; public CollectorTable[] getTables(){ CollectorTable[] tables = new CollectorTable[TABLENAME.length]; for(int i = 0; i < TABLENAME.length; i++) { tables[i] = new CollectorTable(TABLENAME[i]); } for(int i = 0; i < TABLENAME.length; i++) { for(int j = 0; j < TABLE_DEFINITION[j].length; j++) {
Appendix A. Developing a custom collector
175
tables[i].addColumn(TABLE_DEFINITION[i][j]); } } return tables; }
Required method executeV2()

This method (Example A-6) gathers compliance data from the client. In this method, we implement the actual functionality of the collector. Compliance data is returned as an array of class Message. Each array element represents the data for one database table. This method is defined as abstract in the CollectorV2 class and must be implemented by any collector. The logic of this method is: 1. Initialize data objects, which are used to return the collected data. 2. Detect the operating system the collector is running on. 3. For each platform, collect the data. 4. Return the records for the database tables.
Example: A-6 Required method executeV2() public Message[] executeV2() { Message[] stats; Vector[] columns; CollectorTable[] tables; String[] headers; Object[] record = null; String str = ""; String Value = "";
/* * Get the table information for this collector. */ tables = getTables(); /* * Allocate an array of Vectors to contain the database * table column information for this collector. Allocate * a vector for each database table used by the collector. */ columns = new Vector[TABLENAME.length]; /* * Allocate the array of Message objects to be returned from the
176
* collector. Allocate a Message object for each database table. */ stats = new Message[TABLENAME.length]; /* * Instantiate the message array. */ for (int i = 0; i < TABLENAME.length; i++) { stats[i] = new Message(TABLENAME[i]); columns[i] = tables[i].getColumns(); /* * Fill in the column headers for the current table. */ headers = new String[columns[i].size()]; for (int j = 0; j < columns[i].size(); j++) { headers[j] = ((CollectorTable.Column) columns[i].elementAt(j)).getName(); } stats[i].getDataVector().addElement(headers); } /* * For each table, fill in the data records. */ record = new Object[columns[0].size()]; String os_name = System.getProperty("os.name"); /* * Verify if Risk Manager is installed and get home directory */ record[0] = "TRM"; record[1] = isTRMInstalled ( os_name ); /* * Verify if Risk Manager Agent is running */ record[2] = isTRMRunning ( os_name ); /* * add first record to result set for SCM server */ stats[0].getDataVector().addElement(record); /* * Hashing the policies */ StringTokenizer st; String he; ArrayList eventDefinitions;
Appendix A. Developing a custom collector
177
ArrayList ruleset; File file; //get rulesets defined in RMMonitorList ruleset = getValues(new File(rmhome + EvMonWin), RMMonitorList); // extract the ruleset file names for(int i = 0; i < ruleset.size(); i++) { // get EventDefinitions, for example A1EventDefinitions, or A2EventDefinitions eventDefinitions = getValues(new File(rmhome + EvMonWin), (String)ruleset.get(i) + "EventDefinitions"); //Building the hash of the files. for(int j = 0; j < eventDefinitions.size(); j++) { try{ file = new File((String)eventDefinitions.get(j)); he = hashEntry(file); } catch(Exception e){ he = "file not found"; } record = new Object[columns[0].size()]; record[0] = "MD5"; record[1] = (String)eventDefinitions.get(j); record[2] = he; stats[0].getDataVector().addElement(record); } } return stats; }
The complete source code of the collector can be downloaded from the following site:
ftp://www.redbooks.ibm.com/redbooks/SG246450
178
Appendix B.
Introducing the Security Vulnerability Index

This appendix introduces a new IBM offering: The IBM Global Services Security Vulnerability Index is a service that gets updated by IBM Global Services on a daily basis and causes the Security Compliance Manager policies to also get updated accordingly. This service answers the question that our customers have asked about the ability to be notified of new vulnerabilities and how to check their systems for them. The package consists of a new install feature, available free of charge, for Security Compliance Manager; however, the IBM Global Services Security Vulnerability Index is a subscription service and as such is billable.
179
So what is the IBM Global Services Vulnerability Index?

IBM Security Intelligence Services created the IBM Global Business Security Index, which is a monthly report that assesses, measures, and analyzes network security threats and the broader business security landscape. The index is based on data culled from IBM's monitoring of large and small customer networks in multiple locations worldwide, as well as input from our security professionals working on consulting engagements. It is a tool to aid in tactical incident response and strategic security planning. It serves as a barometer of the daily, weekly and monthly threat landscape, and is collected by IBM's 2700 worldwide information security professionals and half a million monitoring devices from many Fortune 500 companies and government entities in 34 countries around the world. On average, IBMs monitoring service detects 100 million suspected or actual attacks against customers each month. The IBM Security Intelligence Services Team collects a broad range of IBM's security data, analyzes it for non-obvious trends, identifies emerging threats, and releases the analysis on a monthly basis via the IBM Security Threats and Attack Trends (STAT) report available to customers via a secure Web portal. It distills the onslaught of security information to a manageable level and reduces hype to help enterprises gain better insight and advance warning on potential threats to the network and the broader enterprise so they can better prepare.
How does it work?

Security Compliance Manager customers get continually updated intelligence on patches and the latest security vulnerabilities. Via a snapshot mechanism, systems are flagged that are missing key security patches and vulnerabilities based on latest advisory information from IBM Global Services. IBM Global Services continually feeds and identifies critical security patches and vulnerability information to Security Compliance Manager for select OS platforms. It is used to identify systems that are missing critical security patches and have vulnerabilities. You can purchase this service directly through IBM Global Services at the following site:
180
IBM Tivoli Compliance Manager Design and Deployment Guide
http://www.ibm.com/services/us/index.wss/so/bcrs/a1008776
This Web site also contains sample reports. The IBM Tivoli Security Compliance Manager Security Index Enablement Pack can be downloaded from the IBM Tivoli Security Compliance Manager 5.1 Utilities Web site at:
http://www.ibm.com/support/docview.wss?rs=2004&context=SSVHZU&dc=D400&uid=s wg24007082&loc=en_US&cs=utf-8&lang=en
The Security Compliance Manager new feature can be downloaded from:

http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliSecurityCompl ianceManager.html
Appendix B. Introducing the Security Vulnerability Index
181
182
IBM Tivoli Compliance Manager Design and Deployment Guide
Appendix C.
Additional material
This redbook refers to additional material that can be downloaded from the Internet as described below.
Locating the Web material

The Web material associated with this redbook is available in softcopy on the Internet from the IBM Redbooks Web server. Point your Web browser to:
ftp://www.redbooks.ibm.com/redbooks/SG246450
Alternatively, you can go to the IBM Redbooks Web site at:

ibm.com/redbooks
Select the Additional materials and open the directory that corresponds with the redbook form number, SG246450.
183
Using the Web material

The additional Web material that accompanies this redbook includes the following files: File name SG246450.zip Description Zipped Risk Manager collector Java code, as described in Appendix A, Developing a custom collector on page 173, and the corresponding Risk Manager policy file ABBC Risk Manager Policy.pol.
How to use the Web material

Create a subdirectory (folder) on your workstation, and unzip the contents of the Web material zip file into this folder.
184
Glossary
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 (http://www.bis.org/publ/bcbs107.htm) 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. CERT. Computer Emergency Response Team. 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 presents 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). For more detailed information about the CERT/CC, see Meet the CERT/CC at http://www.cert.org/meet_cert/meetcertcc.html. Collector. A software module that runs on a client system and gathers data. This data is subsequently sent to a server. 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. More information can be found at http://niap.nist.gov/cc-scheme/index.html. Compliance query. An SQL query that extracts specific data from the server database and returns a list of clients that are in violation of specific security requirements. Delta table. A database table used for saving changed data from subsequent runs of a collector. Disinherit. To remove actions from a role that were originally copied from a template. Inherit. To copy actions to a role from a template.
185
JAAS. The 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. More information can be found at http://java.sun.com/products/jaas/. 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. 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. 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. 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.
186
Related publications
The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this redbook.
IBM Redbooks
For information about ordering these publications, see How to get IBM Redbooks on page 189. Note that some of the documents referenced here may be available in softcopy only. Centralized Risk Management using Tivoli Risk Manager 4.2, SG24-6095 Enterprise Business Portals with IBM Tivoli Access Manager, SG24-6556 Enterprise Business Portals II with IBM Tivoli Access Manager, SG24-6885 Enterprise Security Architecture using IBM Tivoli Security Solutions, SG24-6014.
Other publications
These publications are also relevant as further information sources: IBM DB2 Universal Database Installation and Configuration Supplement Version 8.2, GC09-4837 IBM Tivoli Access Manager Base Installation Guide Version 5.1, SC32-1362 IBM Tivoli Security Compliance Manager Tivoli Risk Manager Adapter Guide Version 5.1 IBM Tivoli Security Compliance Manager Version 5.1 Administration Guide, SC32-1594 IBM Tivoli Security Compliance Manager Version 5.1 Collector Development Guide, SC32-1595 IBM Tivoli Security Compliance Manager Version 5.1 Installation Guide: All Components, GC32-1592 IBM Tivoli Security Compliance Manager Version 5.1 Installation Guide: Client Component, GC32-1593 IBM Tivoli Security Compliance Manager Version 5.1 Release Notes, GI11-4695
187
IBM Tivoli Security Compliance Manager Version 5.1 Tivoli Risk Manager Adapter Guide IBM Tivoli Security Compliance Manager Version 5.1 Fix Pack 5.1.0-TIV-SCM-FP0009 February 18, 2005 Operational Reports Reference The following guides are part of the IBM Tivoli Security Compliance Manager 5.1 Utilities and can be found at:
IBM Tivoli Security Compliance Manager Version 5.1 Deployment and Tuning Guide IBM Tivoli Security Compliance Manager Version 5.1 Performance Report IBM Tivoli Security Compliance Manager Component Optimization
Online resources
These Web sites and URLs are also relevant as further information sources: The homepage for Basel II: International Convergence of Capital Measurement and Capital Standards: a Revised Framework, June 2004, can be found at:
http://www.bis.org/publ/bcbs107.htm
The IBM Tivoli Security Compliance Manager 5.1 Utilities offer policies, collectors, reports, Tivoli Data Warehouse enablement pack, software distribution files, collector SDK, Tivoli Risk Manager adapter, and tuning information and can be found at:
IBM product manuals for IBM DB2 Universal Database can be found at the following location:
http://www-306.ibm.com/software/data/db2/udb/support/manualsv8.html
IBM product manuals for IBM Tivoli Security Compliance Manager can be found at the following location:
http://publib.boulder.ibm.com/tividd/td/IBMTivoliSecurityComplianceManager5 .1.html
BusinessObjects Enterprise
http://www.businessobjects.com/products/platform/enterprise.asp
188
The CERT Coordination Center

http://www.cert.org/meet_cert/meetcertcc.html
The Common Criteria Evaluation and Validation Scheme

http://niap.nist.gov/cc-scheme/index.html
IBM Global Services - Security intelligence

http://www.ibm.com/services/us/index.wss/so/bcrs/a1008776
IBM HTTP Server

http://www.ibm.com/software/webservers/httpservers
IBM Tivoli Security Compliance Manager - Product overview

http://www.ibm.com/software/tivoli/products/security-compliance-mgr
IBM Tivoli Security Compliance Manager support

http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliSecurityCompl ianceManager.html
IBM Tivoli Security Compliance Manager 5.1 Utilities

http://www-1.ibm.com/support/docview.wss?rs=2004&context=SSVHZU&dc=D400&uid =swg24007082&loc=en_US&cs=utf-8&lang=en
Installing and uninstalling the IBM HTTP Server

http://www.ibm.com/software/webservers/httpservers/doc/v1328/htdocs/en_US/m anual/ibm/9ainstal.htm
JAAS Authentication Tutorial

http://java.sun.com/j2se/1.4.2/docs/guide/security/jaas/tutorials/GeneralAc nOnly.html
Java Authentication and Authorization Service (JAAS)

http://java.sun.com/products/jaas
SunSolve Document ID #57221: A Vulnerability in JRE May Allow an Untrusted Applet to Escalate Privileges
http://sunsolve6.sun.com/search/document.do?assetkey=1-26-57221-1
How to get IBM Redbooks

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

IBM Support and downloads
ibm.com/support
IBM Global Services

ibm.com/services
190
Index
A
access control list 20 access control lists 43 access control management system 66 access control system 64 Access Manager 67 integration 146 Java Runtime environment 67 Java Runtime Environment installation 147 ad-hoc snapshot 108, 111 administration 63, 108 components 28 delegation 109, 125 administration console 28 installation 34 Administrative Activity report 76 Adobe Acrobat reports 76 anti-virus software 68 audit 70, 99 team 109 authentication 26, 66, 100, 146 authorization certificate 18 Automated Process Scheduler 128 automation 77 group inheritance 14 grouping 39 identification number 17 installation 38, 54 organization 121 pull 1415, 32, 57 push 1415, 32 registration 40, 112 rollout 116 secure communication 16, 27 security 16 server communication 15 silent install 62 status monitoring 111 update 63 updates 16 Client Group Membership report 76 Client Violations report 76 collector 17, 28, 100 certificates 18 code for Risk Manager 173 design 153 design guidelines 152 development 72, 151 distribution 72 instance number 17 management 112 proxy collector 41 schedule 38 updates 16 Collector Run Information report 7576 commands scmaddgroupclient 123 scmimportpolicy 34 scmlistclients 124 scmregisterclient 61, 123 scmregisterpolicycollectors 21 scmsignpolicycollectors 21 Common Criteria 51 communication 15, 26, 101 configuration 29 compliance 6 deviation notification 150 evaluation 71
B
Basel II 5 bulk registration 123 business context 3 business process 69 business requirements 53, 90, 95
C
Changes to Roles and Permissions report 76 CLI_ID 17 client 14 adding to a role using SQL 128 bulk registration 123 deployment 60, 121 deployment options 62 DHCP push 16 group 14, 61
191
exception 71, 77 legal 7 object 35, 65 proof of ... 22 query 21, 75 report 71, 76, 99, 108 compliance evaluation components 20 policy 21 snapshot 22 compliance management influencing factors 6 introduction 4 compliance report components 22 operational reports 22 Compliant and Non-compliant Systems report 76 components administration 28 compliance evaluation 20 compliance report 22 data collection 13 server 25 configuration changes 73 server component 117 control 6 controlled network 58 cost considerations 66 management 89 Crystal Enterprise 22, 106 Automated Process Scheduler 128 installation 128 object rights 142 Crystal Reports 76
DB2 RUN_STATS 120 delegated administration 63, 109, 125 delta monitoring 73, 75 deployment 115 example 33 design decisions 32 objectives 100 process 51 development of a collector 151 reports 160 team 109 deviation 75 deviation notification 150 DHCP push client 16 DMZ 58 documentation 73
E
enterprise security policy 52, 70 exception 71, 77 handling 4 external authentication service 67
F
firewall 14, 29, 68 fix pack 34 four eyes principle 4 functional requirements 96, 100
G
group 39 client organization 121 registration 112
D
data collection 44, 71 data collection components 13 client 14 collector 17 proxy relay 19 database access 26 installation 33, 117 JAC 33 security 102 server 31 tables 28
H
hardening of the OS 101 health check 105 heartbeat 16
I
IBM DB2 see DB2 IBM HTTP Server installation 129
192
IBM Tivoli Access Manager see Access Manager IBM Tivoli Risk Manager see Risk Manager IBMs Method for Architecting Secure Solutions 51 implementation architecture 95, 104 import policy 34 inheritance client groups 14 installation client 121 server 117 InstallShield MultiPlatform 38 silent mode 39 INSTANCE_ID 17 intrusion detection 68 ISMP see InstallShield MultiPlatform IT security management 108 item priority 36
proxy relay 19 server 25 snapshot 22
M
maintenance team 109 MASS see Method for Architecting Secure Solutions master administrator 34 Method for Architecting Secure Solutions 51 Microsoft Excel reports 76 Microsoft Word reports 76 monitoring 151 multi-processor support 117
N
network zone 32 controlled 58 restricted 58 secured 58 uncontrolled 57
J
JAAS 26, 66 JAC database 118 Java Authentication and Authorization Service see JAAS Java programmer 114 Java Sockets 104 Java Virtual Machine 16 JDBC driver 118 JVM see Java Virtual Machine
O
object rights 142 operational reports 22, 73, 112, 142, 160 modification 161 organizational level security control 4 OS hardening 101
P
password lenght 4 performance calculation 105 tuning 31, 120 phased project approach 97 physical components architecture 29 communication configuration 29 Crystal Enterprise server 106 proxy relay 32, 106 server 31, 105 platform subject matter experts 114 policy 8, 14, 21, 28, 65 admin 126 attachment 44 bundle 21
L
logging 99 logical components 12 administration 28 administration console 28 client 14 collector 17 command line interface 28 compliance evaluation 20 compliance report 22 data collection 13 operational reports 22 policy 21
Index
193
development 34, 116 generation 37 import 34 management 112 schedule 37 violations 11 Policy Import Time report 77 Policy Violations Trends report 77 port usage 29 practices 8 privacy 101 procedures 8 process consultant 114 process level security control 4 project manager 113 organization 112 phases 53 proxy collector 41 proxy relay 19, 28, 30, 33, 58, 106 access control list 20 installation 41 routing path 43 pull client 1415, 30, 32, 57 push client 1415, 29, 32
management 5, 89 Risk Manager 68 collector code 173 integration 87, 101, 150 monitoring 151 policy 159 RMI 29 ROI 93 role 64, 107 role based access control 125 Roles and Permissions Information report 77 root authority 14, 25 root certificate 18 routing path 43 RUN_STATS 120
S
scalability 101 schedule 37 scmaddgroupclient 123 scmimportpolicy 34 scmlistclients 124 scmregisterclient 61, 123 scmregisterpolicycollectors 21 scmsignpolicycollectors 21 secondary controls 71 secure communication 26, 101 secured network 58 security audit team 109 controls 4 deviation notification 150 management role 108 policy 4, 52, 59, 7071 threats 68 violation 108 zones 99 security / IT architect 113 Security Vulnerability Index 179 self-service interface 99 Senior Admin Role 126 separation of duties 4, 7 server 105 client communication 15 component 25, 31 configuration 117 installation 33, 54, 117 management 28
R
Redbooks Web site 189 Contact us xi redundancy 99 registration 40 Remote Method Invocation see RMI report 70 Collector Run Information 75 completeness 74 development 160 evaluation 111 HTML access 75 operational 73, 142 retention time 99 reporting 22, 55 response file 38 responsibility matrix 107 restricted network 58 retention time 98 risk 66 acceptance 71, 77
194
secure communication 27 silent install 62 silent mode 39 snapshot 22, 74, 108, 111 creation 45 reports 76 Snapshot Creation Completion report 77 SQL statement 35 SSL 14, 26 configuration for IBM HTTP Server 129 standards 8 suppression 46, 77 system administration 108
T
technical implementation 115 technical security control 4 threats 68 throughput calculation 105 Tivoli Access Manager see Access Manager Tivoli Risk Manager see Risk Manager trend report 99 tuning 31
U
uncontrolled network 57 user 28 management 111 roles 107 User Group Membership report 77
V
violation 75, 108 message 45 vulnerabilities 11
W
walkthrough 32
Index
195
196
(0.2spine) 0.17<->0.473 90<->249 pages
Back cover
Deployment Guide Series:
IBM Tivoli Security Compliance Manager

Business context and legal compliance discussion Best practices in a banking customer scenario Complete deployment guide with hands-on
The process that ensures that the security policies and standards of a company are adhered to is called compliance management. It requires the ability to report on the current compliance status of the security controls of any installed system and to react to any observed deviations. Most businesses today heavily rely on their IT systems, and damage incurred to their critical systems through downtime can force a company out of business. It is a good business practice to minimize the risk to IT systems in proportion to their importance to the business. The factors that influence how much compliance you need can be based on economical, technological, regulatory, or legal reasons. This IBM Redbook discusses the business context for security compliance management. It introduces the logical and physical components of Tivolis solution offering. We explain the planning steps and describe how to deploy IBM Tivoli Security Compliance Manager (ITSCM) Version 5.1 in a banking environment and how to integrate it with IBM Tivoli Access Manager and IBM Tivoli Risk Manager. This book is a valuable resource for security administrators and architects who wish to understand and implement a centralized security infrastructure.
INTERNATIONAL TECHNICAL SUPPORT ORGANIZATION
BUILDING TECHNICAL INFORMATION BASED ON PRACTICAL EXPERIENCE 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-6450-00 ISBN 0738490067

Deployment Guide Series IBM Tivoli Security Compliance Manager Sg246450

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Deployment Guide Series IBM Tivoli Security Compliance Manager Sg246450

Uploaded by

Copyright:

Available Formats

Front cover

Deployment Guide Series:

IBM Tivoli Security Compliance Manager

Axel Buecker Hendrik H. Fulda Dieter Riexinger

Copyright IBM Corp. 2005. All rights reserved.

Deployment Guide Series: IBM Tivoli Security Compliance Manager

Deployment Guide Series: IBM Tivoli Security Compliance Manager

Copyright IBM Corp. 2005. All rights reserved.

Deployment Guide Series: IBM Tivoli Security Compliance Manager

The team that wrote this redbook

Copyright IBM Corp. 2005. All rights reserved.

Figure 1 From left: Dieter, Axel, and Hendrik

Deployment Guide Series: IBM Tivoli Security Compliance Manager

Become a published author

Send your comments in an e-mail to:

Deployment Guide Series: IBM Tivoli Security Compliance Manager

Architecture and design

Copyright IBM Corp. 2005. All rights reserved.

Deployment Guide Series: IBM Tivoli Security Compliance Manager

Business context for security compliance management

Copyright IBM Corp. 2005. All rights reserved.

1.1 Introduction to compliance management

Deployment Guide Series: IBM Tivoli Security Compliance Manager

1.2 Why compliance management?

Chapter 1. Business context for security compliance management

1.3 Determining the how: influencing factors

Deployment Guide Series: IBM Tivoli Security Compliance Manager

Chapter 1. Business context for security compliance management

Deployment Guide Series: IBM Tivoli Security Compliance Manager

1.4 General challenges

Chapter 1. Business context for security compliance management

Deployment Guide Series: IBM Tivoli Security Compliance Manager

Tivoli Security Compliance Manager design and structure

Copyright IBM Corp. 2005. All rights reserved.

2.1 Logical component architecture

Deployment Guide Series: IBM Tivoli Security Compliance Manager

Compliance Report Components

ITSCM Operational Report

ITSCM Admin GUI Administration Components

ITSCM ITSCM Server Server

Compliance Evaluation Components ITSCM Policies

2.1.1 Data collection components

Chapter 2. Tivoli Security Compliance Manager design and structure

The data collection components are: Client Collector Proxy relay

Security Compliance Manager client

Deployment Guide Series: IBM Tivoli Security Compliance Manager

Chapter 2. Tivoli Security Compliance Manager design and structure

Client type DHCP push client

Securing the Security Compliance Manager client

Deployment Guide Series: IBM Tivoli Security Compliance Manager

Chapter 2. Tivoli Security Compliance Manager design and structure

ITSCM Client win.any.local_group.jar

Figure 2-2 Security compliance data stored in collector-specific database tables

Securing the collector system

Deployment Guide Series: IBM Tivoli Security Compliance Manager

Figure 2-3 Required collector certificate

Chapter 2. Tivoli Security Compliance Manager design and structure

ITSCM Client com.ibm.jac.server.JAC Proxy.jar

ITSCM Client win.any.local_group.jar

Figure 2-4 Security Compliance Manager client configured as proxy relay

Securing the proxy relay system

2.1.2 Compliance evaluation components

Deployment Guide Series: IBM Tivoli Security Compliance Manager