Deployment guide series ibm tivoli security compliance manager sg246450

  • 1,614 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,614
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
6
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Front coverDeployment Guide Series:IBM Tivoli SecurityCompliance ManagerBusiness context and legal compliancediscussionBest practices in a bankingcustomer scenarioComplete deploymentguide with hands-on Axel Buecker Hendrik H. Fulda Dieter Riexingeribm.com/redbooks
  • 2. International Technical Support OrganizationDeployment Guide Series: IBM Tivoli SecurityCompliance ManagerAugust 2005 SG24-6450-00
  • 3. 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 ComplianceManager (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 ADPSchedule Contract with IBM Corp.
  • 4. Contents Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiPart 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
  • 5. 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 . . . . . . . . . . . . . . . . . 77Part 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151iv Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 6. 6.2.4 Report development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 6.3 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169Part 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 v
  • 7. vi Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 8. NoticesThis 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. Consultyour 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 IBMproduct, program, or service may be used. Any functionally equivalent product, program, or service thatdoes not infringe any IBM intellectual property right may be used instead. However, it is the usersresponsibility 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 licenseinquiries, 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 provisionsare inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDESTHIS 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 disclaimerof 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 madeto the information herein; these changes will be incorporated in new editions of the publication. IBM maymake improvements and/or changes in the product(s) and/or the program(s) described in this publication atany time without notice.Any references in this information to non-IBM Web sites are provided for convenience only and do not in anymanner serve as an endorsement of those Web sites. The materials at those Web sites are not part of thematerials 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 withoutincurring any obligation to you.Information concerning non-IBM products was obtained from the suppliers of those products, their publishedannouncements or other publicly available sources. IBM has not tested those products and cannot confirmthe accuracy of performance, compatibility or any other claims related to non-IBM products. Questions onthe 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 themas 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 businessenterprise is entirely coincidental.COPYRIGHT LICENSE:This information contains sample application programs in source language, which illustrates programmingtechniques on various operating platforms. You may copy, modify, and distribute these sample programs inany form without payment to IBM, for the purposes of developing, using, marketing or distributing applicationprograms conforming to the application programming interface for the operating platform for which thesample 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 ofdeveloping, using, marketing, or distributing application programs conforming to IBMs applicationprogramming interfaces.© Copyright IBM Corp. 2005. All rights reserved. vii
  • 9. TrademarksThe 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 orits affiliated companies in the United States and other countriesJava, JDBC, JVM, Solaris, Sun, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. inthe United States, other countries, or both.Excel, Microsoft, Natural, Windows NT, Windows, and the Windows logo are trademarks of MicrosoftCorporation 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 10. 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 Tivoli®’s 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.© Copyright IBM Corp. 2005. All rights reserved. ix
  • 11. 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.x Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 12. 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 USBecome 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. Youll team with IBM technical professionals, Business Partners, and customers. Your efforts will help increase product acceptance and customer satisfaction. As a bonus, youll 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.htmlComments 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
  • 13. Mail your comments to: IBM Corporation, International Technical Support Organization Dept. JN9B Building 003 Internal Zip 2834 11400 Burnet Road Austin, Texas 78758-3493xii Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 14. Part 1Part 1 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.© Copyright IBM Corp. 2005. All rights reserved. 1
  • 15. 2 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 16. 1 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.© Copyright IBM Corp. 2005. All rights reserved. 3
  • 17. 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.4 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 18. 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. 1 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 5
  • 19. 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?6 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 20. 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 thedimensions above, has to be done are influenced by the threats in the externalenvironment 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 Chapter 1. Business context for security compliance management 7
  • 21. 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.8 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 22. 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. Chapter 1. Business context for security compliance management 9
  • 23. 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 24. 2 Chapter 2. Tivoli Security Compliance Manager design and structure IBM Tivoli Security Compliance Manager is IBM’s 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.© Copyright IBM Corp. 2005. All rights reserved. 11
  • 25. 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 26. Compliance Report Components ITSCM ITSCM Report Operational Report ITSCM Admin GUI ITSCM Snapshots Administration Components ITSCM ITSCM ITSCM Compliance Evaluation Server Server Database Components ITSCM ITSCM Admin CLI Policies ITSCM Client ITSCM ITSCM Proxy ITSCM ITSCM Collector Collector Collector ITSCM Client ITSCM ITSCM Collector Windows Registry Collector Configuration Router File Executable Firewall Data Collection Components Figure 2-1 IBM Tivoli Security Compliance Manager logical component architecture2.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
  • 27. 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 the14 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 28. same schedule and parameters, to every client that is a member of the clientgroup or a member of any nested group. Similarly, adding a policy to a clientgroup adds collector instances for every collector used in the policy to everyclient that is a member of the client group or a member of any nested group. Theschedule and parameters for each collector instance are set in the policy and thesame values are used for each client. You can take advantage of this collectorinheritance by adding policies and individual collectors to a small set of groups,rather than adding them to large numbers of individual clients. Inheritancepermits a large number of clients to run the same set of collectors using thesame parameters at the same scheduled times. When a policy or a collector isremoved from a client group, all related collector instances and any collecteddata are removed from all the clients in the client group and all the clients in anynested subgroups. Similarly, removing a client from a client group results in thecollector instances, and any collected data that was collected as a result of apolicy or collector added at the group level, to be removed as well.Client-server communicationClients can be categorized into one of three types. Table 2-1 describes the clienttypes.Table 2-1 Security Compliance Manager client types Client type Description Push client 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. Pull client 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. Chapter 2. Tivoli Security Compliance Manager design and structure 15
  • 29. Client type Description DHCP push A DHCP push client has a dynamic IP address that permits client 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 clients 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 server’s 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 the16 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 30. client (first contact trust). This certificate is used to verify the server’s unique identity and to encrypt all traffic within the Tivoli Security Compliance Manager environment.CollectorA collector is a Java language-based software module, packaged as a JavaArchive (JAR) file, that collects specific information from a client system. Acollector is designed to have a short execution time and to be non-invasive. Thecollector may use different methods for collecting data depending on thecompliance 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 Managercollectors. The first time a collector is deployed to a client, the JAR file for thecollector is sent from the server to the client, along with the collector scheduleand any associated parameters (1). Multiple instances of a collector can bedeployed to a client. Subsequent instances of the collector share the same JARfile, but run on their own schedule and with their own parameters. Each instanceof a collector is uniquely identified by a collector instance number(INSTANCE_ID). According to its schedule, the collector starts to read securitycompliance data from its corresponding data source, for example, the WindowsRegistry (2). Data collected by each collector instance is queued by the clientand delivered to the server on a periodic basis, by default every minute (3).Delivery of collected data is determined by two configurable settings in theclient.pref file: flush.interval (the default is 60 seconds) and flush.threshold (thedefault is 100 messages).The collected data is not stored on disk, but kept in memory until the connectionto the server is established. The server stores the information received from theclient into one or more tables in the database. The data in the database table isuniquely identified by the client identification number (CLI_ID) and the collectorinstance number (INSTANCE_ID) (4). When a collector instance is removedfrom a client, any data associated with that instance of the collector is removedfrom the database tables by the server. Chapter 2. Tivoli Security Compliance Manager design and structure 17
  • 31. 1 3 ITSCM Client ITSCM Server win.any.local_group.jar 4 2 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 32. Unsigned collectors collector Collectors signed with IBM certificate denied IBM collector ITSCM Client Collectors signed with IBM and authorization certificates accepted IBM collector ACFigure 2-3 Required collector certificateProxy relayThe IBM Tivoli Security Compliance Manager proxy relay provides a solution forthe scenario of a server separated from destination clients by one or moreintermediary networks because of firewall policies or address space concerns.The goal of the proxy relay is to permit the server to successfully connect to andcommunicate with each destination client system.Figure 2-4 on page 20 illustrates that any Security Compliance Manager clientmay be used as a proxy relay if a special collector calledcom.ibm.jac.server.JACProxy.jar is added to the Security Compliance Managerclient using the Security Compliance Manager administration tools. The proxyrelay collector permits a client to act as an intermediary, or proxy, between theserver and a number of clients behind a firewall. The collector does not collectdata in the usual sense, but does gather statistics on the clients using the proxyrelay and the amount of data being transferred. Chapter 2. Tivoli Security Compliance Manager design and structure 19
  • 33. 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 site’s 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 34. Security Compliance Manager policyA Security Compliance Manager policy consists of one or more specially writtenSQL queries that are used to reveal compliance or violation of system securityrequirements. The combined results of all the queries in the policy indicate thelevel of adherence to the security policy. Policies can be applied to one or moreclient groups. Each SQL query in a policy is called a compliance query. Acompliance query extracts, from one or more collector tables, data specificallycollected for the compliance query, analyzes that data, and then returns the listof clients that are in violation of that specific security requirement. A compliancequery is created to return a list of violations. The results of all the compliancequeries associated with a policy can be used to provide a picture, or snapshot, ofthe level of compliance for all clients in a client group. The results of thecompliance queries directly depend on the data extracted from the collectortables. When a policy is added to a client group, all the collectors required by thepolicy are added to the client group and inherited by all the member clients andclient groups. The clients must run these collectors and return the data back tothe server before the policy can produce meaningful snapshot reports. A policyconsists 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 addressesPolicies are created using the Policies page of the administration console. After apolicy has been created, it can be exported to a special binary file called a policybundle. The policy bundle contains everything needed to re-create the policy: thecompliance queries, the collectors, including their authorization keys, the defaultcollector schedules, and any collector parameters. The maximum data sizeassociated with the collector tables is saved also. The policy bundle does notcontain information regarding the snapshot schedule. Importing a policy bundleon the same or a different server results in the collectors being installed with theirdefault schedules and parameters, only if the collectors are not already installed,and the compliance queries are made available. Also note that more recentversions of collectors that might already be present on a server are not replacedby collectors bundled with the policy. Before a policy can be used, the collectorsassociated with the policy might need to be signed with one or moreauthorization keys. All the collectors must be registered. To authorize thecollectors, if necessary, use the Collectors page of the administration console, orthe scmsignpolicycollectors command. To register the collectors associatedwith a policy, use the Collectors page or the scmregisterpolicycollectorscommand. Chapter 2. Tivoli Security Compliance Manager design and structure 21
  • 35. 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 the22 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 36. subdirectory doc. Additional information can be found athttp://www.businessobjects.com/products/platform/enterprise.asp. report development publishing reports Design Crystal Crystal Web GUI Reports Enterprise Interface Report save import ReportDeveloper report report User templates templates Operational Report Operational operational Report report templateFigure 2-5 Security Compliance Manager report development using Crystal productsBusiness Objects, the company that created Crystal Reports and CrystalEnterprise, offers different product suites. According to Business Objects, thebaseline product is Crystal Reports, which is associated with reportdevelopment. The report developer uses Crystal Reports for creating databaseconnections, selecting database records, and designing new reports. The reportscan then be saved to file as report templates and imported into CrystalEnterprise. Crystal Enterprise consists of multiple server components thatprovide the ability to schedule the creation of reports, to manage users and usergroups, to configure security settings, and to organize reports using reportfolders. 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. Chapter 2. Tivoli Security Compliance Manager design and structure 23
  • 37. 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 38. Figure 2-6 Example for operational report: Client Violations2.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 Chapter 2. Tivoli Security Compliance Manager design and structure 25
  • 39. 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 Manager’s 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 server’s 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 40. 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 server’s 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 server’s 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 Manager’s 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 aresecured using 128-bit Secure Sockets Layer (SSL) encryption. The cipher suitesused are RSA_WITH_RC4_128_SHA, RSA_WITH_RC4_128_MD5, andRSA_WITH_3DES_EDE_CBC_SHA. Chapter 2. Tivoli Security Compliance Manager design and structure 27
  • 41. 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 42. 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 Manager’s 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 Manager’s 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 Manager’s 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 server’s 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. Chapter 2. Tivoli Security Compliance Manager design and structure 29
  • 43. 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 ITSCM ITSCM Admin GUI Admin CLI Operational Report 1955 RMI Naming 1951 1952 logcmd JLOG port ITSCM PUSH Clients ITSCM Database Server ITSCM Server 1950 1950 1960 1950 1950 1960 Client port Client port Proxy port Client port Client port Proxy port 1953 logcmd 1953 logcmd 1953 logcmd 1953 logcmd JLOG port JLOG port JLOG port JLOG port ITSCM PUSH Client ITSCM PUSH Client (Proxy) ITSCM PULL Client ITSCM PULL Client (Proxy) 1950 1950 1960 1950 1950 1960 Client port Client port Proxy port Client port Client port Proxy port 1953 logcmd 1953 logcmd 1953 logcmd 1953 logcmd JLOG port JLOG port JLOG port JLOG port ITSCM PULL Client ITSCM PULL Client (Proxy) ITSCM PULL Client ITSCM PULL Client (Proxy) permanent connection temporary connection (required) temporary connection (optional) Figure 2-8 Communication port usage30 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 44. 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. 1 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. Chapter 2. Tivoli Security Compliance Manager design and structure 31
  • 45. 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 46. 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 Managerinfrastructure and complete an initial security compliance check. itsosec3 ITSCM PUSH Client Win2000 itsosec6 itsosec4 ITSCM ITSCM ITSCM PULL Client Server Admin GUI Win2000 AIX itsosec2 itsosec7 ITSCM ITSCM ITSCM Database PULL Client PULL Proxy DB2 LINUX AIX Production Management DMZ Network NetworkFigure 2-9 Security Compliance Manager deployment exampleDatabase installationWe install IBM DB2 Version 8.1 on AIX using the db2setup utility and create adb2instance called db2inst1. The IBM DB2 Universal Database Installation andConfiguration Supplement Version 8, GC09-4837 provides details on how toinstall and configure DB2®. The Security Compliance Manager installationprogram will create the database and perform the required configuration. Fornow, it is important to know the user ID and password of the DB2 instance thatwill be used for Security Compliance Manager.Security Compliance Manager server installationWe install the Security Compliance Manager server on the same system wherewe installed the DB2 database. 6.1.1, “Planning and installing the server” onpage 117 provides details on how to install the Security Compliance Managerserver. During the installation procedure, we have to specify the DB2 instance IDand password. Security Compliance Manager creates the Security ComplianceManager database JAC, configures the table spaces, and creates and configures Chapter 2. Tivoli Security Compliance Manager design and structure 33
  • 47. 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 administrator’s 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 companys 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 Security34 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 48. Compliance Manager provides an efficient way of integrating and maintaining thesecurity policy by splitting this task into the parts data collection and complianceevaluation. Data collection is the process of gathering current system controlsettings. Compliance evaluation compares the current system settings to thesettings required by the security policy. 6.2.3, “Collector development” onpage 151 describes how to develop collectors gathering additional securityrelated data. In our example, the data collectors provide enough information toimplement the basic Security Compliance Manager policy. So we canconcentrate on the compliance evaluation part. Tivoli Security ComplianceManager uses compliance objects in order to perform compliance control. Eachcompliance object consists of a single SQL statement. The SQL statementscompare data collected by the Security Compliance Manager collectors withshould-be values defined in the security policy. In most cases, changes of thesecurity policy require nothing but adjusting the values specified in the SQLqueries.Let us demonstrate the implementation of a specific security policy at theexample of Windows 2000. The enterprise security policy in our examplerequires the settings in Table 2-2.Table 2-2 Security policy detailsControl No Control description Required setting Severity1 Minimum password length Eight characters High2 Maximum password age Three months Normal3 Antivirus run frequency Weekly Normal4 Security log retention time 180 days LowThe following steps show you how to create a new policy based on the policyimported 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. Chapter 2. Tivoli Security Compliance Manager design and structure 35
  • 49. 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 50. Perform the same steps for the other operating systems (AIX and Linux®). Nowwe have a complete set of Security Compliance Manager policies that reflect ourenterprise security policy.The final step is to generate a complete policy consisting of Java data collectorsand compliance objects. Select the policy Windows2000_Policy, go to theCollectors tab, and click Generate Collector List, as shown in Figure 2-11.Security Compliance Manager now selects all required Java data collectors thatare referenced by the compliance objects and creates a complete policy. Youcan export this policy into a JAR file containing data collectors and complianceobjects. Click Save Collector List.Figure 2-11 Example of collector list generated for a policyScheduling policiesFor each policy, we assign a schedule that defines when the data collectorsshould be executed by the Security Compliance Manager clients. The defaultschedule for the policies executes the collectors daily. To view the currentschedule, go to the Policies tab, select one of the policies, and open theCollectors tab on the right. The collectors and their schedules are sorted bycompliance queries, as shown in Figure 2-12 on page 38. Chapter 2. Tivoli Security Compliance Manager design and structure 37
  • 51. 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 method38 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 52. shortens the installation time considerably and ensures a homogenousdeployment on all systems. For our installation, the response file for the Windowsplatforms is shown in Example 2-1.Example 2-1 Sample response file for pull clients on Windows platforms-P installLocation="C:applicationsSCM-W setupTypeSelectionPanel.selectedSetupTypeId=clientSetup"-W clientConfigPanel.clientPort="1950"-W clientConfigPanel.pushPull="pull"-W clientServerConfig.serverHostname=""-W clientServerConfig.serverPort="1951"Using the response file, the command for client installation is:scm_win32 -silent -options win_response_fileThe 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 installLocation="/opt/IBM/SCM-W setupTypeSelectionPanel.selectedSetupTypeId=clientSetup"-W clientConfigPanel.clientPort="1950"-W clientConfigPanel.pushPull="push"-W clientServerConfig.serverHostname="itsosec6.itsc.austin.ibm.com"-W 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. Chapter 2. Tivoli Security Compliance Manager design and structure 39
  • 53. 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 54. Figure 2-13 Client groups showing active and inactive clientsProxy relay installationNext, we configure the system itsosec7.itsc.austin.ibm.com as the SecurityCompliance Manager proxy relay in order to connect to systems in the DMZ. Forthis purpose, we could use any Security Compliance Manager client in thisnetwork. 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 pullclient. 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. Chapter 2. Tivoli Security Compliance Manager design and structure 41
  • 55. 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 client42 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 56. 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 Added line Description Inbound 9.3.5.166/32:1960 Specify the Security Compliance Manager server itsosec6 as the only source of requests using port 1960. Outbound 9.3.4.162/32:1950 Specify the DMZ client itsosec2 as the only Security Compliance Manager client to contact using port 1950. Proxy Port 1960 By default, the proxy relay listens on 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 Chapter 2. Tivoli Security Compliance Manager design and structure 43
  • 57. 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 schedule44 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 58. Snapshot creationAfter the collectors return the collected data to the server, a snapshot can becreated to show the level of compliance of the clients with the security policy.You can create snapshots immediately in the administration console, or schedulesnapshots to occur on a regular basis. To immediately create a snapshot, selecta group or client in the Groups/Clients window, right-click an attached policy, andselect Create Snapshot.After the snapshot is created, a new folder is created under the Snapshot folderin the Policies window. The name of the folder indicates when the snapshot wastaken, the number of violations identified, the name of the client group, and if thesnapshot was restricted to a specific group. Figure 2-18 shows a snapshot for thegroup WIN2K_Group.Figure 2-18 Snapshot and violated compliance objectsSelecting a compliance object under the snapshot displays the violationmessage and the affected hosts. The color of the compliance objects indicateswhether or not violations of the security policy were found and whether violationsare being suppressed. We assigned a priority to each compliance object whenwe defined it. Violations uncovered by the compliance query are shown indifferent colors to indicate the severity of the violation. The colors of thecompliance queries have the meanings shown in Table 2-4 on page 46. Chapter 2. Tivoli Security Compliance Manager design and structure 45
  • 59. Table 2-4 Color coding for violations Color Meaning Green No violations and no suppressions. The WIN2K NAV Run Frequency compliance object has no violations and no suppressions. Bold Red 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. Red Normal priority violation. The WIN2K Max Password Age compliance object is of normal priority and has two violations associated with it. Orange Low priority violation. The WIN2K Security Logs Retention compliance object is of low priority and has two violations. 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 is46 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 60. displayed in the Suppressions window to indicate why the specified client is beingexempted 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 clientAs a last step, we click Display Query to generate the SQL statement based onthe information specified on the window. The resulting SQL is displayed in theSQL Query statement field. The SQL string can be modified as needed.Performing a new snapshot reduces the number of violations associated to thecompliance object WIN2K Security Logs Retention to one.Export reportWe can now export the security compliance report to a file in HTML format.Right-click the snapshot and select Export Snapshot to HTML file. Theresulting report is shown in Figure 2-20 on page 48. Chapter 2. Tivoli Security Compliance Manager design and structure 47
  • 61. 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 62. 3 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.© Copyright IBM Corp. 2005. All rights reserved. 49
  • 63. 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 Manager’s 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 64. 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. IBM’s 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 today’s 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
  • 65. Legal & Regulatory Requirements Enterprise Security Policy (for example: Sarbanes Oxley Act) Security health check Business Requirements solution 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 66. 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. Chapter 3. Architecting a Security Compliance Management solution 53
  • 67. 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 68. 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 serverinfrastructure and roll out the Security Compliance Manager clients. Theadaptation of the Security Compliance Manager policies that come with theproduct require knowledge of your enterprise security policy and SQL skills tomodify the compliance objects.Project phase 2Typically, project phase 2 enhances the Security Compliance Manager policies tofully cover the security controls defined in the enterprise security policy. Thisphase might require you to develop additional collectors in order to gather moresecurity related data from the Security Compliance Manager clients. Anothertask of phase 2 can be the implementation of operational reports, trend reports,and other statistics to fulfill business requirements and optimize the securitycompliance management process.Project phase 2 requires Java implementation skills for the collectordevelopment, SQL skills for policy development, and Crystal Report developmentskills for modifying and creating operational reports. Platform specific skills arerequired to identify the sources of security data to be gathered by the SecurityCompliance Manager collectors. Chapter 3. Architecting a Security Compliance Management solution 55
  • 69. 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 70. 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 phases3.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 Chapter 3. Architecting a Security Compliance Management solution 57
  • 71. 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 72. Other networksKeep in mind that the network examples we are using do not necessarily includeall possible situations. There are organizations that extensively segmentfunctions into various networks. However, in general, the principles discussedhere may be easily translated into appropriate architectures for suchenvironments.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 basedupon an existing/planned network infrastructure and levels of trust among thecomputing components within the organization. While requirement issues mayoften be complex, especially with regard to the specific behavior of certainapplications, with a bit of knowledge about the organization’s networkenvironment and its security policies, reasonable component placements areusually easily identifiable.Figure 3-4 on page 60 summarizes the general Security Compliance Managercomponent type relationships to the network zones discussed above. It alsodepicts the transport classifications. Chapter 3. Architecting a Security Compliance Management solution 59
  • 73. The clients in this zone should be configured as pull Organizations may set Some organizations The Security Compliance clients to avoid up specialized set up special Manager clients in this zone connection setup in restricted zones for networks to separate should be configured as pull more trusted production systems that various management clients to avoid connection networks. Proxy The specific level of may include Security components from setup in more trusted relays may be trust in an internal Compliance Manager production systems. networks. No Security placed in this zone network dictates how components. Clients in The Security Compliance Manager to connect to Security Compliance this zone may set up Compliance Manager components other than pull Security Compliance Manager clients push connections to the server should be clients should be placed in Manager clients in communicate with the Security Compliance placed here if this zone this zone. external networks. server. Manager server. exists. Uncontrolled Controlled Controlled Restricted Secured Zone Zone Zone Zone Zone Production Management Internet Internet DMZ Intranet Network Network Public Managed Trusted LESS SECURE MORE SECUREFigure 3-4 Network zones and Security Compliance Manager component placement3.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 will60 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 74. maintain a central database to administrate its assets. This asset database is anideal point to start the rollout process. One of the first steps after setting up theSecurity Compliance Manager server infrastructure is the registration andgrouping of Security Compliance Manager clients. Instead of waiting until thepush clients register themselves, you can start to pre-load all SecurityCompliance Manager clients in a single step. Security Compliance Managerprovides the CLI command scmregisterclient to register Security ComplianceManager clients in batch. In “Tracking of the rollout progress” on page 124, wedescribe how to use Security Compliance Manager to track the rollout progressand provide example reports to support this task.Registration and grouping of clientsEstablishing groups of clients that represent organizational units that fit into thesecurity compliance management process is an important task. Doing this workright saves all parties involved in the security compliance management processtime 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. SecurityCompliance Manager supports the grouping of clients by offering client groupsand group inheritance.A client group is a container used to group one or more clients together. Clientscan be members of one or more client groups. A client group itself can be amember of one or more client groups. A client must be a member of at least oneclient group in order for a policy to be applied to the client.Adding policies and collectors to client groups is a powerful feature because ofgroup inheritance. Every client that is a member of the client group, or a memberof a subgroup of the client group, inherits the collectors and policies added to thegroup. Adding a collector to a client group adds a collector instance, with thesame schedule and parameters, to every client that is a member of the clientgroup or a member of any nested group. Figure 3-5 on page 62 shows anexample of group inheritance. In this example there are two different securitylevels defined having different control settings and security compliance checkfrequency requirements. We use this criterion for the first grouping level. In thenext level, we differentiate the clients by operating system types. Usually, thereare so many differences between the operating systems, that for each differenttype another policy has to be defined. The next level represents theorganizational units of the enterprise. We have to attach the policies only to theoperating system groups. All child groups inherit the policy and the collectorsattached to an operating system group. Later on in the security compliancemanagement process, we can make a single snapshot for the operating systemgroup SL1.AIX, which performs compliance checks for all clients in all subgroups,or create different snapshots for the organizational units. Chapter 3. Architecting a Security Compliance Management solution 61
  • 75. Security Level 1 AIX Policy Level 1 SL1.AIX 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 AIX Policy Level 2 Security Level 2 SL2.AIX SL2.AIX.North Host9.ab_bank.com Host10.ab_bank.com SL2.AIX.South 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 from62 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 76. 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 Manager’s 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. Chapter 3. Architecting a Security Compliance Management solution 63
  • 77. 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 Managers role-based access control system is depicted in Figure 3-6. User Roles Group Client Users Groups Report Objects Collector Policy Add/Remove Assign Admin_South Admin_Role Admin_North Add/Remove Audit-Role Security Audit Mgmt_Role Management Read Delete Functions Manage Create Figure 3-6 Security Compliance Managers 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 78. 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 Chapter 3. Architecting a Security Compliance Management solution 65
  • 79. 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 80. plug-in that handles the authentication of users. You can find more informationabout JAAS at: http://java.sun.com/products/jaasSecurity Compliance Manager provides a sample JAAS plug-in as part of theserver component. The sample JAAS plug-in is only for demonstrating thefunctionality of using an external authentication service. It obtains logininformation from a text file containing unencrypted user IDs and passwords. In6.2.1, “Tivoli Access Manager integration” on page 146, we describe how tointegrate Security Compliance Manager with an actual access managementsystem using Tivoli Access Manager.IBM Tivoli Access Manager is a policy-based access control solution fore-business and enterprise applications. By providing a centralized, flexible, andscalable access control solution, Tivoli Access Manager allows you to buildhighly secure and well-managed network-based applications. Figure 3-7 showsthe components required to integrate Security Compliance Manager with TivoliAccess Manager. Security Compliance Manager server Access Authentication request Access Manager Manager Server Components Policy JAAS Module Database Access Manager Access Manager Java Runtime Environment Runtime Environment LDAP SSL connection IBM GSKit DirectoryFigure 3-7 Authentication of users using Tivoli Access Manager JAAS moduleOn the Security Compliance Manager server system, you have to install theAccess Manager Java Runtime environment and configure the JAASauthentication to be used by Security Compliance Manager. The integration withTivoli 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. Chapter 3. Architecting a Security Compliance Management solution 67
  • 81. 3.2.8 Integration with Tivoli Risk Manager In todays 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 82. raw event Risk Network Intrusion Risk Manager Manager Detection System Agent Adapter summarized events or correlated Reporting Risk incidents Host Intrusion Risk Manager Manager Detection System Agent Adapter Risk Risk Database Risk Manager Risk Manager Manager Manager Auditing Agent Correlation events Database Adapter and incidents Risk Logging Risk Manager Manager Infrastructure Agent Real-Time Adapter Display (TEC GUI) Risk Manager compliance Tivoli Security issues Adapter for Risk Manager Compliance Security Agent Manager Compliance Manager 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. Chapter 3. Architecting a Security Compliance Management solution 69
  • 83. System Security System administration System 7.Request Policy administration administration exceptions 1. Apply security policy Security Audit Team 5. Correct 4. Report 3. Document health settings deviations check and deviations 6. Report compliance status 9. Document accepted 8. Ask for risk accaptance deviations 2. Check control settings and compare to Authority security policy 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 84. 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 companys security policy. Security policies are living documents that are adapted continuously to a changing environment. Security Compliance Manager’s 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 Chapter 3. Architecting a Security Compliance Management solution 71
  • 85. 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 86. Security Compliance Manager goes even a step further and supports detectionof configuration changes. If enabled, delta monitoring monitors changes to theconfiguration data. Each time the collector instance collects data and sends it tothe server, the server compares the newly received data with the data stored inthe collector table. If the data has changed, the new data is appended to thedelta table and then the collector table itself is updated.Document security compliance managementThe security compliance management process requires documenting thatcompliance checks are performed regularly, within the required intervals, andthat they are complete. (Complete means that all security control settings on allsystems are actually checked.) Some environments even require archiving thedata used for the security compliance management process and not only theresult of the compliance check. Security Compliance Manager supports thedocumentation 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. Chapter 3. Architecting a Security Compliance Management solution 73
  • 87. 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 88. 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 settingsUsually, the security auditor informs the computer system owners about securityfindings and provides information about deviations and required correctivesettings. Security Compliance Manager supports this task with the followingoptions: Operational reports via Web access Operational reports that list audit issues can be provided as HTML reports using a Web interface. Chapter 3. Architecting a Security Compliance Management solution 75
  • 89. 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 90. 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 Chapter 3. Architecting a Security Compliance Management solution 77
  • 91. 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 92. 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 anException Documentation activity:Compliance to the security standards is achieved by either making a systemcompliant or by documenting and approving any exceptions to the securitystandard. Because sometimes application configuration requirements are inconflict with the security configuration parameters, some systems can only begreen once an exception has been filed. Chapter 3. Architecting a Security Compliance Management solution 79
  • 93. 80 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 94. Part 2Part 2 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.© Copyright IBM Corp. 2005. All rights reserved. 81
  • 95. 82 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 96. 4 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.© Copyright IBM Corp. 2005. All rights reserved. 83
  • 97. 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 ABBC’s 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 98. 4.2 Current IT architecture ABBC is operating world-wide and is represented in all continents and major cities. ABBC’s 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. ABBC’s current IT architecture is depicted in Figure 4-1. Internet Production Network Asia Intranet DMZ Production Network Europe Production Network USA WebSEAL WebSEAL Server Server AIX Windows Appl. Servers Appl. Servers Mail Router Linux DB2 Appl. Servers Appl. Servers Tivoli Access LDAP Manager Server Corp. Directory Network Systems Tivoli Risk Management Management Manager Management Network - Headquarter Austin/Texas Figure 4-1 ABBC’s current IT environment There are four zones in our drawing to represent the common divisions for ABBC’s 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
  • 99. 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 ABBC’s intranet. Only system monitoring teams are allowed to access systems in the management network. ABBC’s IT infrastructure is made of many interdependent components, such as: Operating systems ABBC’s 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 ABBC’s 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 ABBC’s 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 100. 4.2.1 Existing security infrastructure The following components of ABBC’s 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 ABBC’s 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 ABBC’s 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 ABBC’s 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, Chapter 4. Armando Brothers Banking Corp. 87
  • 101. 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 102. 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. Chapter 4. Armando Brothers Banking Corp. 89
  • 103. 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 104. 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 ABBC’s 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. Chapter 4. Armando Brothers Banking Corp. 91
  • 105. Minimize the number of new hardware systems. ABBC’s 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 106. 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 Manager’s 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. Chapter 4. Armando Brothers Banking Corp. 93
  • 107. 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 108. 5 Chapter 5. Security Compliance Manager design This chapter describes the implementation architecture of ABBC’s security compliance management solution and discusses the project organization for the deployment phase. To build a system that truly meets management’s 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 ABBCs production environment and provide enough flexibility to react on future enhancements of the IT infrastructure systems.© Copyright IBM Corp. 2005. All rights reserved. 95
  • 109. 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 110. 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 ABBC’s 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 ABBC’s 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 ABBC’s security policy standards that can be automated. Phase II refines security reporting to support ABBC’s 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 ABBC’s roadmap for strategic system platforms. Chapter 5. Security Compliance Manager design 97
  • 111. Table 5-1 Platform requirements for project phases I and II System type Platform Number of Automation systems Phase 1 Phase 2 Operating Red Hat Linux 857 857 - systems SUSE Linux 1314 1314 - Linux/390 6 6 - AIX 1930 1930 - Solaris™ 941 941 - Windows NT 312 312 - Windows 2000 745 745 - Windows 2003 546 546 - HP-UX 4 - - AIX Firewall 25 25 - Total number of IT systems: 6676 - Middleware & DB2 87 - 87 Applications Oracle 22 - 22 SQL Server 2 - - Tivoli Risk 27 - 27 Manager 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 112. Support of different security zones ABBC’s 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 ABBC’s IT infrastructure.The project team defines the following functional requirements for securitycompliance 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. Chapter 5. Security Compliance Manager design 99
  • 113. 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 ABBC’s 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 ABBC’s 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 ABBC’s security platform based on Tivoli Access Manager by exploiting the sophisticated access control features. Develop a user access model that reflects ABBC’s 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 ABBC’s heterogeneous, multi-layered enterprise makes it a challenge to manage compliance with ABBC’s 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 114. 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. Chapter 5. Security Compliance Manager design 101
  • 115. 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. ABBC’s 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 threats102 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 116. from the Internet, they must have as little vulnerabilities as possible towardsattacks. Therefore, one of the protective measures taken is that only the absoluteminimum 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 servicesinstalled, but on the other hand, it is obviously necessary to check thecompliance status of those systems carefully and often. As a result, the questionneeded to be analyzed is whether it is a higher risk to install additional software,the Security Compliance Manager client, for compliance checking, using someother solution or not checking the systems automatically. The latter alternative,no or manual compliance checking, was quickly ruled out by the IT Securitydepartment, so that the only question that remained was if Security ComplianceManager clients could be used or some other solution would be preferable.A risk analysis of the Security Compliance Manager client components identifiedand 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 Chapter 5. Security Compliance Manager design 103
  • 117. – 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 project’s 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. ABBC’s network is separated into different security 2 http://classic.sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert%2F57555&zone_32=categor y%3Asecurity104 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 118. 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 ABBC’s 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 3 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. Chapter 5. Security Compliance Manager design 105
  • 119. 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 ABBC’s headquarter in Austin. Access for the administrative users from ABBC’s intranet is protected by SSL.106 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 120. Internet Production Network Asia Intranet DMZ Production Network Europe ITSCM Client Production Network USA Tivoli Access ITSCM Client ITSCM Client Manager WebSEAL WebSEAL AIX Windows Server Server Appl. Servers Appl. Servers ITSCM Client ITSCM Client ITSCM ITSCM Client ITSCM Client Proxy Server Security Auditor Mail Router as Linux DB2 ITSCM Proxy Appl. Servers Appl. Servers ITSCM Client ITSCM Client Tivoli Access Manager Policy LDAP ITSCM Reporting Server Corp. Directory Server Server ITSCM Client ITSCM Client ITSCM Client Mgmt Database Server Network Systems Tivoli Risk Management Management Manager Management Network - Headquarter Austin/TexasFigure 5-1 Physical components of the security compliance solution5.3.2 User roles and responsibilities The user roles and responsibility matrix for ABBC’s security compliance project can be derived from the security compliance process. Figure 5-2 on page 108 depicts the main process steps. Chapter 5. Security Compliance Manager design 107
  • 121. Development and Test Environment provide policies test and and reports develop register new systems, Maintenance Development report suppressions team team request policy and report changes ITSCM ad-hoc Server and snapshots Database schedule accomodate Security Administration snapshots policy changes Policy teams retrieve compliance Security Audit Team information Crystal Enterprise schedule reports Reporting Server escalate compliance request control security issues risk acceptance compliance status confirm risk acceptance IT Management Figure 5-2 ABBC’s 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 122. 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 ABBC’s 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, view reports, schedule reports schedule reports Security Audit Team ITSCM administrative ITSCM Server administrative ITSCM Maintenance team Operational and access access Reports Database Development team view the team’s IT System Administration IT systems teams create snapshotsFigure 5-3 User roles’ access requirements on ITSCM server and operational reportsDelegated administration conceptABBC is operating world-wide and organized its IT service infrastructure by thegeographical regions USA, Europe, and Asia. Within each region, there aredifferent administration teams for each system platform. For phase I of the Chapter 5. Security Compliance Manager design 109
  • 123. 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, ABBC’s 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 124. Administration USA Team UNIX (USA) Register clients/groups UNIX Systems Administration Manage operational reports Team Windows Manage policies (USA) Manage collectors Schedule snapshots Windows Systems Administration Team DB2 (USA) DB2 Systems Central Manage clients Monitoring Team Create ad-hoc snapshots Europe Manage ITSCM reports View operational reports UNIX Systems Administration Team UNIX (Europe) Windows Systems Administration Team Windows (Europe) DB2 Systems Administration Team DB2 (Europe)Figure 5-4 Administration delegation at the example of USA and EuropeThe project team decides to delegate the following functions to the localadministration 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. Chapter 5. Security Compliance Manager design 111
  • 125. 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 126. ABBC ABBC IT IT Department Department Project Manager Security Process Architect Consultant ITSCM Platform 1 ITSCM/Java Subject Subject Programmer Matter Expert Matter Expert Platform 2 Subject Matter Expert Platform N Subject Matter ExpertFigure 5-5 Project organization diagramThe 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. Chapter 5. Security Compliance Manager design 113
  • 127. 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 128. 6 Chapter 6. Technical implementation This chapter describes the implementation of ABBC’s 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 ABBC’s 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.© Copyright IBM Corp. 2005. All rights reserved. 115
  • 129. 6.1 Deployment phase I Deployment phase I of ABBC’s security compliance project aims to achieve the following targets: Set up the Security Compliance Manager server infrastructure. Roll out Security Compliance Manager clients in ABBC’s world-wide IT infrastructure. Adapt Security Compliance Manager policies provided by IBM to cover ABBC’s 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 End of project phase I: 01/01/2005 phase I: 28/02/2005 Figure 6-1 ABBC’s project plan for deployment phase I The following sections describe the steps required for deployment phase I.116 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 130. 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. ABBC’s 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 Database Server DB2 ITSCM Server JDBC JAC component driver ITSCM DB configuration 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
  • 131. 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 Manager’s 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 Manager’s server.ini file. The installer starts the Security Compliance Manager server automatically.118 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 132. 5. Verify the Security Compliance Manager server installation Stop the Security Compliance Manager server and set the debug parameter in the server’s 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 startedStop the server again, reset the debug value back to false, and restart the server. Chapter 6. Technical implementation 119
  • 133. 6.1.2 DB2 maintenance tasks According to ABBC’s 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 Database table Changes depending on... JAC_IDATA All tables ... run frequency of related collectors JAC_SYS VIOLATIONS ... run frequency of snapshots SNA_CLI_TAB_METADATA SNAPSHOTS COMPLIANCE_SQL_STATE JAC_SYS DELTA_TABLES ... number of configuration changes on Security Compliance Manager clients 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 134. 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) ABBC’s 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 Chapter 6. Technical implementation 121
  • 135. avoiding unnecessary administration overhead in the security compliance process. The project team starts analyzing the ABBC’s 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 ITSCM console 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 Production zone Admin team 3 (Windows) Production zone Admin team 4 (Databases) Production zone oba_p1.ab_bank.com Figure 6-3 Mapping of ABBC’s 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 136. Figure 6-3 on page 122 also depicts the mapping of the organizational entities toSecurity Compliance Manager client groups. The first level of groups separatesthe different administration teams. Access to the first level provides access to allsystems in the subgroups of the team. The second level differentiates betweengroups having different security policies. An important feature of SecurityCompliance Manager is the possibility to add one Security Compliance Managerclient to different groups. For example, the UNIX administration team1 managesthe system oba_p1.ab_bank.com. The database team4 is managing the samesystem 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 amember of the group US.Team4.DB2. Both administration teams have access tothe same Security Compliance Manager client, but are using different policiesattached to the corresponding group.Bulk registration of clientsHaving created the group schema in the Security Compliance Managerdatabase, the project team starts to upload the IT systems to the SecurityCompliance Manager database. The IT systems are listed in a central database,including all relevant information required for registering with the SecurityCompliance Manager server. The project team wants to automate theregistration process in the beginning of the project, as several thousandmachines are involved. They export the list of IT systems in a comma separatedvalue (CSV) format. Based on this list, there are two options to automaticallyregister 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 Manager’s database, which is very useful for the initial upload of many IT systems at once. This method requires a restart of the Security Compliance Chapter 6. Technical implementation 123
  • 137. 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 ABBC’s 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 138. Example 6-1 Result of the scmlistclients commandRegistered clients for server: abbc_scm1Client name: cc_p1.ab_bank.com (ID = 1) - activeClient name: webs1.ab_bank.com (ID = 2) - activeClient name: webs2.ab_bank.com (ID = 3) - inactiveClient name: webs3.ab_bank.com (ID = 4) - activeClient name: oba_p1.ab_bank.com (ID = 5) - inactiveClient name: oba_p2.ab_bank.com (ID = 6) - inactiveThe client list, including the clients’ status, provides enough information for theproject team to control if the Security Compliance Manager client software isinstalled and if the client connectivity is configured correctly at the firewallsbetween the Security Compliance Manager server and the subnetworks.Alternatively, the project team can create a Security Compliance Managerinternal report querying the Security Compliance Manager client’s operatingsystem version. When the Security Compliance Manager client is connectedsuccessfully, the client provides the operating system version to the SecurityCompliance Manager server, which stores the value in the column OS_NAME ofthe Security Compliance Manager database table jac_sys.clients. Thecorresponding report uses the following SQL statement:select cli_id, alias, primary_ip from jac_sys.clients where OS_NAME is nullThis query lists all clients that were never connected to the Security ComplianceManager server.Implementing delegated administrationSecurity Compliance Manager provides a role based access control system thatis conceptually described in 3.2.5, “Delegated administration” on page 63. Theproject team implements the administration model depicted in Figure 6-4. Functions: Manage snapshots Execute reports Test collector User Groups Roles View clients Administrationteam US_Team1 Group Objects: System Admin Role US.Team1.AIX.DMZ (Template) US.Team1.AIX.PROD US_Team1 US-Team1 US.Team1.Solaris US_Team2 US-Team2 US_Team3 US-Team3 Policy Objects: Maintenance team … ... ABBC_AIX_PROD ABBC_AIX_DMZ Maintenance Senior Admin Role ... Audit Snapshot Admin Role Policy Admin Role Security Audit TeamFigure 6-4 Administration concept for Security Compliance Manager server Chapter 6. Technical implementation 125
  • 139. 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 Manager’s 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 Role126 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 140. Click OK and select the functions for each function type as required. For theadministration teams select View groups, Test collectors, Manage snapshots,and Execute reports. Click Save Role Information. In the next step, you haveto create an administration team role. Click Create Role again and specify therole name US-Team1. This time, select Normal as the role type. Right-click thenewly created role and select Inherit permissions from template, as shown inFigure 6-6.Figure 6-6 Inheriting permissions from a templateThe 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. Inthe Add Resources windows, select the groups belonging to the administrationteam, and click OK.Figure 6-7 Adding objects to the team roleYou have to perform the same actions for the policies and reports required by theadministration team and store the role by clicking the Save Role Informationbutton. If a large number of client and group objects have to be added to a role, Chapter 6. Technical implementation 127
  • 141. 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 Administrator’s 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 142. 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 DB2 Database Server Crystal Enterprise IBM Components JAC HTTP Server APS CE90Figure 6-8 Components for the reporting environmentInstallation of IBM HTTP ServerThe IBM HTTP Server can be downloaded from IBM’s Web site using thefollowing URL: http://www.ibm.com/software/webservers/httpservers/In our example, we use IBM HTTP 1.3.28. The installation instructions areavailable 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 ServerABBC’s security guidelines require you to encrypt the traffic containing usercredentials and security compliance data. Therefore, the project team configuresSSL to be used for all communications. The following steps describe how toconfigure 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. Chapter 6. Technical implementation 129
  • 143. 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 Filesibmgsk5bingsk5ikm.exe. In our example, we use self-signed certificates. Create the directory C:Program FilesIBM HTTP Serverkeytab, where you will store the server’s 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. ABBC’s 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 144. 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>htdocsen_USmanualibmindex.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 ServerListen 443<VirtualHost report_s1.pzone.abbc.com:443>ServerName report_s1.pzone.abbc.comSSLEnableKeyfile "c:/program files/ibm http server/keytab/test.kdb"SSLV2Timeout 100SSLV3Timeout 1000DocumentRoot "C:/Program Files/IBM HTTP Server/crystal"SSLClientAuth none</VirtualHost> Chapter 6. Technical implementation 131
  • 145. 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 146. Figure 6-11 DB2 Client configuration assistantIn the Welcome window, select Add Database. In the following window(Figure 6-12), select Manually configure a connection to a database and clickNext.Figure 6-12 DB2 Add Database Wizard: SourceSelect TCP/IP as the communication protocol to the DB2 database server andclick Next. Chapter 6. Technical implementation 133
  • 147. 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 148. Figure 6-15 DB2 Add Database Wizard: Database configurationThe next window (Figure 6-16) confirms that the connection configuration wasadded successfully.Figure 6-16 DB2 configuration confirmationThe next step is to test the connection. You have to make sure that theconnection works correctly before continuing with the installation of the reportingserver. Select Test Connection and specify the user ID and password for theSecurity Compliance Manager database. If the connection can be establishedsuccessfully, the window shown in Figure 6-17 on page 136 appears. Chapter 6. Technical implementation 135
  • 149. 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 150. Figure 6-18 Crystal Enterprise: setup windowWe select Next, accept the Crystal Enterprise 9 for Tivoli license agreement (seeFigure 6-19), and select Next.Figure 6-19 Crystal Enterprise: license agreementIn the next window (Figure 6-20 on page 138), select the Custom installationoption. The New option would install the complete set of Crystal Enterprise Chapter 6. Technical implementation 137
  • 151. 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 152. Figure 6-21 Crystal Enterprise: custom installation windowDeselect the database drivers as well; they are not needed. Click Next. In thefollowing window, you have to specify that you do not want to cluster the APSwith an existing cluster, as this is the first installation of Crystal Enterprise 9. Thenext window asks for the database driver you want to use. Select the DB2Database driver and click Next, as shown in Figure 6-22.Figure 6-22 Crystal Enterprise: APS database type selection Chapter 6. Technical implementation 139
  • 153. 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 154. Figure 6-24 Crystal Enterprise: configuration managerConfigure IBM HTTP Server for Crystal Enterprise 9The installation program of Crystal Enterprise 9 installs the Web connector filesso no special installation is required. All that is needed is to configure the IBMHTTP Server for Crystal Enterprise 9. In our example, IBM HTTP Server andCrystal Enterprise are installed on the same system. We already modified thehttpd.conf file in Example 6-3 on page 131. You have to add the configurationlines marked in bold, as shown in Example 6-4.Example 6-4 IBM HTTP Server configuration for Crystal EnterpriseAlias /viewer/ "C:/Program Files/Common Files/CrystalDecisions/2.0/crystalreportviewers"Alias /crystalreportviewers "C:/Program Files/Common Files/CrystalDecisions/2.0/crystalreportviewers"Alias /crystal/Enterprise9/ "C:/Program Files/Crystal Decisions/WebContent/Enterprise9/"Listen 443<VirtualHost report_s1.pzone.abbc.com:443>ServerName report_s1.pzone.abbc.comSSLEnableKeyfile "c:/program files/ibm http server/keytab/test.kdb"SSLV2Timeout 100SSLV3Timeout 1000DocumentRoot "C:/Program Files/IBM HTTP Server/crystal"SSLClientAuth noneAddType Magnus-Internal/rpt .rptAddType Magnus-Internal/csp .csp Chapter 6. Technical implementation 141
  • 155. 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 administrators 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 The user or group is not able to access the object. View Allows you to view the folder and the objects contained in the folder. Schedule Allows you to view the object or folder and its contents, and to generate instances by scheduling the object. The user or group142 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 156. 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 reportsThe project team decides to follow the recommendations in the administrator’sguide. They define user groups based on the access requirements depicted inFigure 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 ManagementConsole (CMC). The access rights are configured on the folder level. Go to thefolder containing the reports and select the menu entry Rights, as shown inFigure 6-25. In the Rights view shown in Figure 6-27 on page 145, click theAdd/Remove... button. Figure 6-26 on page 144 shows the window that allowsyou 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 movethem to the list on the right side. Chapter 6. Technical implementation 143
  • 157. 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 158. Figure 6-27 Granting access permissions for user groups6.2 Deployment phase II Deployment phase II of ABBC’s security compliance project aims to achieve the following targets: Integrate the Security Compliance Manager infrastructure into ABBC’s IT environment. – Reconfigure the Security Compliance Manager server to exploit Tivoli Access Manager’s sophisticated authentication mechanism. – Integrate Security Compliance Manager with Tivoli Risk Manager. Enhance the Security Compliance Manager policies to cover ABBC’s 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. Chapter 6. Technical implementation 145
  • 159. 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 ABBC’s 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 ABBC’s 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, ABBC’s project team decides to integrate Security Compliance Manager with the existing Tivoli Access146 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 160. Manager environment and exploit its sophisticated access control mechanisms.The following sections describe the three installation and configuration steps: Install and configure Access Manager’s Java Runtime Environment (JRE). Configure Security Compliance Manager’s JRE for Access Manager authentication. Configure Security Compliance Manager server to use JAAS authentication.Install and configure the Access Manager JREInstallation, configuration, and testing the Access Manager Java RuntimeEnvironment (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 Manager’s 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 Manager’s JREjava 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 beunique. Other instances of the application running on this or other systemsmust 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 Chapter 6. Technical implementation 147
  • 161. 4. Before integrating the Security Compliance Manager application, we recommend testing the Access Manager’s JRE setup using a sample application. You can use the example provided by Sun™’s 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 Manager’s 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 Manager’s 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 162. 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/jars6. Move the Security Compliance Manager provided jaas.jar to jaas.jar.SCM using the following command: mv jaas.jar jaas.jar.SCM7. 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.jar8. Change to the /opt/IBM/SCM/jars/boot directory using the following command: cd /opt/IBM/SCM/jars/boot9. Move US_export_policy.jar, ibmjcefw.jar, ibmjceprovider.jar, ibmjsse.jar, and local_policy.jar to .SCM extensions using the following command: mv US_export_policy.jar US_export_policy.jar.SCM mv ibmjcefw.jar ibmjcefw.jar.SCM mv ibmjceprovider.jar ibmjceprovider.jar.SCM mv ibmjsse.jar ibmjsse.jar.SCM mv local_policy.jar local_policy.jar.SCMConfigure server to use JAAS authenticationThe final step is the re-configuration of the Security Compliance Manager serverto use the JAAS authentication module.1. Change to the /opt/IBM/SCM/server directory using the following command: cd /opt/IBM/SCM/server2. 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 Chapter 6. Technical implementation 149
  • 163. 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 Manager’s 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 Manager’s 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 164. 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 ABBC’s 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. Chapter 6. Technical implementation 151
  • 165. Collector design guidelines ABBC’s 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 system’s 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 166. Completeness of collected dataThe collector has to return data that can be interpreted by the SQL statement ofthe compliance object without uncertainty. If there are any errors during the datacollection phase the returned data has to reflect this situation. If a collector doesnot return any data, the compliance object assumes that the execution of thecollector failed.Use one collector for all platforms or single platform collectorsObviously, the answer to this question depends on the diversity of the platforms.In most cases, we recommend implementing single platform collectors if thereare changes between the platforms. Implementing cross platform collectorsresults 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 aplatform, for example, differences between AIX V4.3 and AIX 5L™ V5.1 orbetween Windows NT and Windows 2000. To cover this design option, IBMprovides collector naming conventions in the IBM Tivoli Security ComplianceManager Version 5.1 Collector Development Guide, SC32-1595 that tell you onwhich platforms the collector is able to run. Additionally, during execution, thecollectors return a list of supported operating systems.Collector design phaseDuring the collector design phase, the development team has to answer thefollowing 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? Chapter 6. Technical implementation 153
  • 167. Platform coverage The development team inspects ABBC’s 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 Manager’s 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 Manager’s 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 168. 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 Agent’s process rmagent is running. Data indicating that the current Risk Manager policy is in use It is important for the security of ABBC’s environment that the Tivoli Risk Manager agents react to specific events according to ABBC’s security policy. In ABBC’s 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 decisionsBased on the alternatives listed in the previous sections, ABBC’s developmentteam 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. Chapter 6. Technical implementation 155
  • 169. – Risk Manager runtime information. The collector gathers runtime information using commands on Windows and UNIX systems. – A hash of the Risk Manager’s ruleset. The collected data is stored in a database table using the following columns: TYPE The column TYPE defines the type of the returned data. VERSION 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. VALUE 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. 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 170. Collector implementation phaseA collector is a Java language-based software module, packaged as a JavaArchive (JAR) file. The classes and methods specific to Tivoli SecurityCompliance Manager collectors are provided in the client.jar file. The client.jarfile is installed with the client component of Tivoli Security Compliance Manager.Any additional classes required to implement the collector have to be included inthe collector’s JAR file. The collectors library environment is depicted inFigure 6-31. ITSCM Java collector (JAR file) ITSCM Java collector class Java libraries required by the ITSCM’s client.jar collector Java SDK 1.3.1Figure 6-31 Security Compliance Manager Java collector JAR fileCollectors run in the Java Virtual Machine (JVM) of the Tivoli SecurityCompliance Manager client, which uses Java Version 1.3.1. Each collectorinstance runs in its own thread. On UNIX systems, the collectors run with rootauthority. On Microsoft Windows systems, the collectors run using the localsystem account. A collector extends the com.ibm.jac.CollectorV2 class that isimplemented in the client.jar file. The collector needs to implement a set ofrequired methods, which are called by the Security Compliance Manager client,the Security Compliance Manager server, or the Security Compliance Manageradministration utilities.During installation and registration of the collector at the Security ComplianceManager server, and for display at the administration console, the followingmethods 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 getCompatibleOS returns the list of operating systems and platforms supported by the collector. Chapter 6. Technical implementation 157
  • 171. getDescription getDescription returns the text description of the collector. It is used to provide information about the collector in the administration console. getParameters 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 getTables returns the names and structures of the database tables that are populated by the data that the collector collects. 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 172. required methods optional methods (not implemented by the TivoliRiskManager collector) Collector Client instance component TivoliRiskManagerV1 TivoliRiskManagerV1() setParameters(…) start() executeV2() stop()Figure 6-32 Functions called by the Security Compliance Manager Client componentThe TivoliRiskManager collector to be implemented consists of one class,TivoliRiskManagerV1, which extends the class com.ibm.jac.CollectorV2. Thecomplete source code and documentation is listed in Appendix A, “Developing acustom collector” on page 173.Risk Manager policyHaving implemented and tested the Security Compliance Manager collectors,you can define a new policy for Tivoli Risk Manager. Using the SecurityCompliance Manager administration console, go to the Policies tab and create anew policy named ABBC Risk Manager Policy. For each control, you define aCompliance Object, as shown in Figure 6-33.Figure 6-33 Tivoli Risk Manager policy Chapter 6. Technical implementation 159
  • 173. 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 Manager’s 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 ABBC’s 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 project’s reporting requirements except for the organizational structure. The operational reports provide information about all the registered machines. ABBC’s 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 174. report development publishing reports Design Crystal Crystal Web GUI Reports Enterprise Interface Report save import Report Developer report report User templates templates Operational Report Operational operational Report report templateFigure 6-34 Report development and publishing overviewModifying operational reportsThe 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 locationLet us demonstrate the modifications of the example of the reportClientViolations.rpt. Having started the Crystal Report application, we load thereport. The initial view is depicted in Figure 6-35 on page 162. Chapter 6. Technical implementation 161
  • 175. 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 176. Figure 6-36 Selecting the JAC database as a new data sourceClose the Set Datasource Location window and press F5 to refresh the reportdata. The Crystal Report application connects to the JAC database and loads thedata required by the report.Modify the database commandThe report includes an SQL command that loads the violations from the SecurityCompliance Manager database. You have to modify the SQL statement so thatthe additional fields group name and group ID are loaded from the database. Themodifications of the statement are shown in bold and italic in Example 6-7 onpage 164. Chapter 6. Technical implementation 163
  • 177. 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 entry164 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 178. Parameter Fields and select New..., which opens the Create Parameter Fieldwindow, as shown in Figure 6-37. Enter the name of the new parameter Group IDand the prompting text. Select the Value type Number and Allow multiplevalues. Click OK and the new parameter is added to the list of parameter fieldswithout a green tick. The green tick indicates that the control is already used inthe report.Figure 6-37 Adding a group parameterYou also have to modify the report to actually include the new parameter. Fromthe menu, select Report → Select Expert..., which opens the Select Expertwindow showing the rules that reduce the number of records selected for thereport. Click the <New> tab and the Choose Field window appears. Select theGROUP_ID that is available (due to the modified database command), shown inExample 6-7 on page 164. Chapter 6. Technical implementation 165
  • 179. 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 Expert166 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 180. Click OK and the parameter field Group ID has a green tick indicating that it isactually used in the report.Modifying the report layoutThe report should display the group information that is covered by the newreport. For this reason, you need to add a new parameter field of type Stringcalled Admin Team. This parameter allows to specify the name of theadministration team during the deployment of the report. In order to display theteam’s name in the report, you have to drag and drop the parameter field into theheader section of the report.Testing the reportPress F5 to refresh the report data. In the Refresh Report Data window, selectPrompt 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 USUNIX administration team, as shown in Figure 6-40.Figure 6-40 Specifying group parameters for the UNIX administration team Chapter 6. Technical implementation 167
  • 181. 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:reportslogs -loglevel 4168 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 182. 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. Chapter 6. Technical implementation 169
  • 183. 170 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 184. Part 3Part 3 Appendixes© Copyright IBM Corp. 2005. All rights reserved. 171
  • 185. 172 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 186. A 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.© Copyright IBM Corp. 2005. All rights reserved. 173
  • 187. 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 188. }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
  • 189. 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 the176 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 190. * 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
  • 191. 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/SG246450178 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 192. B 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.© Copyright IBM Corp. 2005. All rights reserved. 179
  • 193. 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 IBMs 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 IBMs 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, IBM’s monitoring service detects 100 million suspected or actual attacks against customers each month. The IBM Security Intelligence Services Team collects a broad range of IBMs 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
  • 194. http://www.ibm.com/services/us/index.wss/so/bcrs/a1008776This Web site also contains sample reports.The IBM Tivoli Security Compliance Manager Security Index Enablement Packcan be downloaded from the IBM Tivoli Security Compliance Manager 5.1Utilities 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=enThe 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
  • 195. 182 IBM Tivoli Compliance Manager Design and Deployment Guide
  • 196. C 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.© Copyright IBM Corp. 2005. All rights reserved. 183
  • 197. Using the Web material The additional Web material that accompanies this redbook includes the following files: File name Description SG246450.zip 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 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 198. GlossaryBasel II. A round of deliberations by central Common Criteria. The Common Criteria is thebankers from around the world, under the auspices result of the integration of information technologyof the Basel Committee on Banking Supervision and computer security criteria. In 1983, the US(BCBS) in Basel, Switzerland, aimed at producing issued the Trusted Computer Security Evaluationuniformity in the way banks and banking regulators Criteria (TCSEC), which became a standard inapproach risk management across national borders. 1985. Criteria developments in Canada andThe Basel II European ITSEC countries followed the original US(http://www.bis.org/publ/bcbs107.htm) TCSEC work. The US Federal Criteria developmentdeliberations began in January 2001, driven largely was an early attempt to combine these other criteriaby concern about the arbitrage issues that develop with the TCSEC, and eventually led to the currentwhen regulatory capital requirements diverge from pooling of resources towards production of theaccurate economic capital calculations. Common Criteria.Basel II recommends three pillars: risk appraisaland control, supervision of the assets, and The Common Criteria is composed of three parts:monitoring of the financial market, to bring stability to the Introduction and General Model (Part 1), thethe financial system. Security Functional Requirements (Part 2), and the Security Assurance Requirements (Part 3). WhileCERT. Computer Emergency Response Team. Part 3 specifies the actions that must be performedThe CERT/CC is a major reporting center for to gained assurance, it does not specify how thoseInternet security problems. Staff members provide actions are to be conducted; to address this issue,technical advice and coordinate responses to the Common Evaluation Methodology (CEM) wassecurity compromises, identify trends in intruder created for the lower levels of assurance.activity, work with other security experts to identifysolutions to security problems, and disseminate More information can be found atinformation to the broad community. The CERT/CC http://niap.nist.gov/cc-scheme/index.html.also analyzes product vulnerabilities, publishestechnical documents, and presents training courses. Compliance query. An SQL query that extracts specific data from the server database and returns aThe CERT/CC is located at the Software list of clients that are in violation of specific securityEngineering Institute (SEI), a federally funded requirements.research and development center (FFRDC)operated by Carnegie Mellon University (CMU). Delta table. A database table used for saving changed data from subsequent runs of a collector.For more detailed information about the CERT/CC,see Meet the CERT/CC at Disinherit. To remove actions from a role thathttp://www.cert.org/meet_cert/meetcertcc.html. were originally copied from a template.Collector. A software module that runs on a client Inherit. To copy actions to a role from a template.system and gathers data. This data is subsequentlysent to a server.© Copyright IBM Corp. 2005. All rights reserved. 185
  • 199. JAAS. The Java Authentication and AuthorizationService (JAAS) is a set of APIs that enable servicesto authenticate and enforce access controls uponusers. It implements a Java technology version ofthe standard Pluggable Authentication Module(PAM) framework, and supports user-basedauthorization. More information can be found athttp://java.sun.com/products/jaas/.Policy. A set of one or more compliance queriesused to demonstrate the level of adherence tospecific security requirements.Policy bundle. A file containing the informationassociated with a policy, such as the compliancequeries, the collectors, and the associatedschedules. A policy bundle permits the policy to besaved and subsequently applied to other servers.Proxy relay. A special pull client that acts as arelay between the server and one or more clients. Aproxy relay is used to reach a limited number ofclients that are located behind a firewall, or that arein an IP-address range that is not directlyaddressable by the server.Pull client. A client that permits communicationwith the server to be initiated by only the server.Push client. A client that permits communicationwith the server to be initiated by either the client orthe server.Snapshot. The result of running all of thecompliance queries in a policy against a set ofclients. A snapshot shows the number of violationsand indicates what clients are not adhering to thesecurity requirements being tested by thecompliance queries.186 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 200. 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© Copyright IBM Corp. 2005. All rights reserved. 187
  • 201. 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: http://www.ibm.com/support/docview.wss?rs=2004&context=SSVHZU&dc=D400&uid=s wg24007082&loc=en_US&cs=utf-8&lang=en – 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 OptimizationOnline 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: http://www.ibm.com/support/docview.wss?rs=2004&context=SSVHZU&dc=D400&uid=s wg24007082&loc=en_US&cs=utf-8&lang=en 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.asp188 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 202. 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-1How 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
  • 203. Help from IBM IBM Support and downloads ibm.com/support IBM Global Services ibm.com/services190 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 204. Index group inheritance 14A grouping 39access control list 20 identification number 17access control lists 43 installation 38, 54access control management system 66 organization 121access control system 64 pull 14–15, 32, 57Access Manager 67 push 14–15, 32 integration 146 registration 40, 112 Java Runtime environment 67 rollout 116 Java Runtime Environment installation 147 secure communication 16, 27ad-hoc snapshot 108, 111 security 16administration 63, 108 server communication 15 components 28 silent install 62 delegation 109, 125 status monitoring 111administration console 28 update 63 installation 34 updates 16Administrative Activity report 76 Client Group Membership report 76Adobe Acrobat reports 76 Client Violations report 76anti-virus software 68 collector 17, 28, 100audit 70, 99 certificates 18 team 109 code for Risk Manager 173authentication 26, 66, 100, 146 design 153authorization certificate 18 design guidelines 152Automated Process Scheduler 128 development 72, 151automation 77 distribution 72 instance number 17B management 112Basel II 5 proxy collector 41bulk registration 123 schedule 38business context 3 updates 16business process 69 Collector Run Information report 75–76business requirements 53, 90, 95 commands scmaddgroupclient 123 scmimportpolicy 34C scmlistclients 124Changes to Roles and Permissions report 76 scmregisterclient 61, 123CLI_ID 17 scmregisterpolicycollectors 21client 14 scmsignpolicycollectors 21 adding to a role using SQL 128 Common Criteria 51 bulk registration 123 communication 15, 26, 101 deployment 60, 121 configuration 29 deployment options 62 compliance 6 DHCP push 16 deviation notification 150 group 14, 61 evaluation 71© Copyright IBM Corp. 2005. All rights reserved. 191
  • 205. exception 71, 77 DB2 legal 7 RUN_STATS 120 object 35, 65 delegated administration 63, 109, 125 proof of ... 22 delta monitoring 73, 75 query 21, 75 deployment 115 report 71, 76, 99, 108 example 33compliance evaluation components 20 design policy 21 decisions 32 snapshot 22 objectives 100compliance management process 51 influencing factors 6 development introduction 4 of a collector 151compliance report components 22 reports 160 operational reports 22 team 109Compliant and Non-compliant Systems report 76 deviation 75components deviation notification 150 administration 28 DHCP push client 16 compliance evaluation 20 DMZ 58 compliance report 22 documentation 73 data collection 13 server 25configuration E enterprise security policy 52, 70 changes 73 exception 71, 77 server component 117 handling 4control 6 external authentication service 67controlled network 58cost considerations 66 F management 89 firewall 14, 29, 68Crystal Enterprise 22, 106 fix pack 34 Automated Process Scheduler 128 four eyes principle 4 installation 128 functional requirements 96, 100 object rights 142Crystal Reports 76 G group 39D client organization 121data collection 44, 71 registration 112data collection components 13 client 14 H collector 17 hardening of the OS 101 proxy relay 19 health check 105database heartbeat 16 access 26 installation 33, 117 JAC 33 I security 102 IBM DB2 server 31 see DB2 tables 28 IBM HTTP Server installation 129192 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 206. IBM Tivoli Access Manager proxy relay 19 see Access Manager server 25IBM Tivoli Risk Manager snapshot 22 see Risk ManagerIBM’s Method for Architecting Secure Solutions 51implementation architecture 95, 104 M maintenanceimport team 109 policy 34 MASSinheritance see Method for Architecting Secure Solutions client groups 14 master administrator 34installation Method for Architecting Secure Solutions 51 client 121 Microsoft Excel reports 76 server 117 Microsoft Word reports 76InstallShield MultiPlatform 38 monitoring 151 silent mode 39 multi-processor support 117INSTANCE_ID 17intrusion detection 68ISMP N see InstallShield MultiPlatform network zone 32IT security management 108 controlled 58item priority 36 restricted 58 secured 58 uncontrolled 57JJAAS 26, 66JAC O database 118 object rights 142Java Authentication and Authorization Service operational reports 22, 73, 112, 142, 160 see JAAS modification 161Java programmer 114 organizational level security control 4Java Sockets 104 OS hardening 101Java Virtual Machine 16JDBC driver 118 PJVM password lenght 4 see Java Virtual Machine performance calculation 105L tuning 31, 120logging 99 phased project approach 97logical components 12 physical components administration 28 architecture 29 administration console 28 communication configuration 29 client 14 Crystal Enterprise server 106 collector 17 proxy relay 32, 106 command line interface 28 server 31, 105 compliance evaluation 20 platform subject matter experts 114 compliance report 22 policy 8, 14, 21, 28, 65 data collection 13 admin 126 operational reports 22 attachment 44 policy 21 bundle 21 Index 193
  • 207. development 34, 116 management 5, 89 generation 37 Risk Manager 68 import 34 collector code 173 management 112 integration 87, 101, 150 schedule 37 monitoring 151 violations 11 policy 159Policy Import Time report 77 RMI 29Policy Violations Trends report 77 ROI 93port usage 29 role 64, 107practices 8 role based access control 125privacy 101 Roles and Permissions Information report 77procedures 8 root authority 14, 25process consultant 114 root certificate 18process level security control 4 routing path 43project RUN_STATS 120 manager 113 organization 112 phases 53 S scalability 101proxy collector 41 schedule 37proxy relay 19, 28, 30, 33, 58, 106 scmaddgroupclient 123 access control list 20 scmimportpolicy 34 installation 41 scmlistclients 124 routing path 43 scmregisterclient 61, 123pull client 14–15, 30, 32, 57 scmregisterpolicycollectors 21push client 14–15, 29, 32 scmsignpolicycollectors 21 secondary controls 71R secure communication 26, 101Redbooks Web site 189 secured network 58 Contact us xi securityredundancy 99 audit team 109registration 40 controls 4Remote Method Invocation deviation notification 150 see RMI management role 108report 70 policy 4, 52, 59, 70–71 Collector Run Information 75 threats 68 completeness 74 violation 108 development 160 zones 99 evaluation 111 security / IT architect 113 HTML access 75 Security Vulnerability Index 179 operational 73, 142 self-service interface 99 retention time 99 Senior Admin Role 126reporting 22, 55 separation of duties 4, 7response file 38 server 105responsibility matrix 107 client communication 15restricted network 58 component 25, 31retention time 98 configuration 117risk 66 installation 33, 54, 117 acceptance 71, 77 management 28194 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 208. secure communication 27silent install 62silent mode 39snapshot 22, 74, 108, 111 creation 45 reports 76Snapshot Creation Completion report 77SQL statement 35SSL 14, 26 configuration for IBM HTTP Server 129standards 8suppression 46, 77system administration 108Ttechnical implementation 115technical security control 4threats 68throughput calculation 105Tivoli Access Manager see Access ManagerTivoli Risk Manager see Risk Managertrend report 99tuning 31Uuncontrolled network 57user 28 management 111 roles 107User Group Membership report 77Vviolation 75, 108 message 45vulnerabilities 11Wwalkthrough 32 Index 195
  • 209. 196 Deployment Guide Series: IBM Tivoli Security Compliance Manager
  • 210. Deployment Guide Series: IBM Tivoli Security Compliance Manager (0.2”spine) 0.17”<->0.473” 90<->249 pages
  • 211. Back cover ®Deployment Guide Series:IBM Tivoli SecurityCompliance ManagerBusiness context The process that ensures that the security policies andand legal compliance standards of a company are adhered to is called compliance INTERNATIONALdiscussion management. It requires the ability to report on the current TECHNICAL compliance status of the security controls of any installed SUPPORTBest practices in a system and to react to any observed deviations. Most ORGANIZATION businesses today heavily rely on their IT systems, andbanking customer damage incurred to their critical systems through downtimescenario can force a company out of business. It is a good business practice to minimize the risk to IT systems in proportion to BUILDING TECHNICALComplete their importance to the business. The factors that influence INFORMATION BASED ONdeployment guide PRACTICAL EXPERIENCE how much compliance you need can be based on economical,with hands-on technological, regulatory, or legal reasons. IBM Redbooks are developed by This IBM Redbook discusses the business context for security the IBM International Technical compliance management. It introduces the logical and Support Organization. Experts physical components of Tivoli’s solution offering. We explain from IBM, Customers and Partners from around the world the planning steps and describe how to deploy IBM Tivoli create timely technical Security Compliance Manager (ITSCM) Version 5.1 in a information based on realistic banking environment and how to integrate it with IBM Tivoli scenarios. Specific Access Manager and IBM Tivoli Risk Manager. recommendations are provided to help you implement IT solutions more effectively in This book is a valuable resource for security administrators your environment. and architects who wish to understand and implement a centralized security infrastructure. For more information: ibm.com/redbooks SG24-6450-00 ISBN 0738490067