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.

Security Compliance Manager provides a role-based access control system. As a first step, users are grouped in Security Compliance Manager user groups. A user group should contain users requiring the same access rights in Security Compliance Manager. The next step is to define

roles

. The access rights of a role are defined by adding objects and functions to the role. For example, you can define read access for client groups and managing rights for policies. Finally, assigning roles to user groups provides the members of a user group with the corresponding access rights. Security Compliance Manager's role-based access control system is depicted in Figure 3-6.

Figure 3-6 Security Compliance Manager's role-based access control concept

Several default roles are defined to permit users to be granted a subset of those that are useful for controlling access to the access control management:

򐂰 Senior Admin

Has permission to perform all actions. This role cannot be changed.

򐂰 Junior Admin

Has permission to perform most actions, but excludes the collector, user, user group, and role actions.

򐂰 User Admin

Has permission to perform all user, user group, and role actions.

򐂰 Client Admin

Has permission to perform all client actions.

򐂰 Policy Admin

Has permission to perform all policy actions.

򐂰 Snapshot Admin

Has permission to perform all actions associated with snapshots.

򐂰 Reporting Admin

Has permission to perform all report actions.

Users _GroupsUser

Admin_South Admin_North Security Audit Management Roles Admin_Role Audit-Role Mgmt_Role Objects Functions Read Create Manage Delete Policy Collector Client Group Report Add/Remove Assign Add/Remove

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

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)

plug-in that handles the authentication of users. You can find more information about JAAS at:

http://java.sun.com/products/jaas

Security Compliance Manager provides a sample JAAS plug-in as part of the server component. The sample JAAS plug-in is only for demonstrating the functionality of using an external authentication service. It obtains login information from a text file containing unencrypted user IDs and passwords. In 6.2.1, “Tivoli Access Manager integration” on page 146, we describe how to integrate Security Compliance Manager with an actual access management system using Tivoli Access Manager.

IBM Tivoli Access Manager is a policy-based access control solution for e-business and enterprise applications. By providing a centralized, flexible, and scalable access control solution, Tivoli Access Manager allows you to build highly secure and well-managed network-based applications. Figure 3-7 shows the components required to integrate Security Compliance Manager with Tivoli Access Manager.

Figure 3-7 Authentication of users using Tivoli Access Manager JAAS module On the Security Compliance Manager server system, you have to install the Access Manager Java Runtime environment and configure the JAAS

authentication to be used by Security Compliance Manager. The integration with Tivoli Access Manager has many advantages, for example:

򐂰 User accounts and passwords are stored in a common directory.

򐂰 Access Manager supports sophisticated password rules.

򐂰 You can define allowed login times for administrators and users individually.

򐂰 You can define maximum login attempts.

Security Compliance Manager server

Access Manager Java Runtime Environment JAAS Module IBM GSKit Access Manager Runtime Environment Access Manager Server Components Access Manager Policy Database

SSL connection _DirectoryLDAP Authentication request

In document IBM Tivoli Security Compliance Manager (Page 77-82)