Service Operations

4. Service Operation Processes

^4.1EVENT

^4.2INCIDENT

^4.3REQUEST FULFILLMENT

^4.4PROBLEM

^4.5 ACCESS

^4.6OTHER OPERATIONS

4.5 Access Management

Access Management is the process of granting authorized users the right to use a service, while preventing access to non-authorized users. It has also been referred to as Rights Management or Identity Management in different organizations.

4.5.1 Purpose, Goals and Objectives

Access Management provides the right for users to be able to use a service or group of services. It is therefore the execution of policies and actions defined in Security and Availability Management.

4.5.2 Scope

Access Management is effectively the execution of both Availability and Information Security Management, in that it enables the organization to manage the confidentiality, availability and integrity of the organization's data and intellectual property. Access Management ensures that users are given the right to use a service, but it does not ensure that this access is available at all agreed times - this is provided by Availability Management.

Access Management is a process that is executed by all Technical and Application Management functions and is usually not a separate function. However, there is likely to be a single control point of coordination, usually in IT Operations Management or on the Service Desk.

Access Management can be initiated by a Service Request through the Service Desk.

4.5.3 Value to Business

Access Management provides the following value:

Controlled access to services ensures that the organization is able to maintain more effectively the confidentIality of its information
Employees have the right level of access to execute their jobs effectively
There is less likelihood of errors being made in data entry or in the use of a critical service by an unskilled user (e.g. production control systems)
The ability to audit use of services and to trace the abuse of services
The ability more easily to revoke access rights when needed - an important security consideration
May be needed for regulatory compliance (e.g. SOX, HIPAA, COBIT).

4.5.4 Policies, Principles and Basic Concepts

Access Management is the process that enables users to use the services that are documented in the Service Catalogue. It comprises the following basic concepts:

Access refers to the level and extent of a service's functionality or data that a user is entitled to use.
Identity refers to the information about them that distinguishes them as an individual and which verifies their status within the organization. By definition, the Identity of a user is unique to that user. (This is covered in more detail in paragraph 4.5.7.1.)
Rights (also called privileges) refer to the actual settings whereby a user is provided access to a service or group of services. Typical rights, or levels of access, include read, write, execute, change, delete.
Services or service groups. Most users do not use only one service, and users performing a similar set of activities will use a similar set of services. Instead of providing access to each service for each user separately, it is more efficient to be able to grant each user - or group of users - access to the whole set of services that they are entitled to use at the same time. (This is discussed in more detail in paragraph 4.5.7.2.)
Directory Services refers to a specific type of tool that is used to manage access and rights. These are discussed in section 5.8.

4.5.5 Process Activities, Methods And Techniques

4.5.5.1 Requesting Access

Access (or restriction) can be requested using one of any number of mechanisms, including:

A standard request generated by the Human Resource system. This is generally done whenever a person is hired, promoted, transferred or when they leave the company
A Request for Change
A Service Request submitted via the Request Fulfillment system
By executing a pre-authorized script or option (e.g. downloading an application from a staging server as and when it is needed).

Rules for requesting access are normally documented as part of the Service Catalogue.

4.5.5.2 Verification

Access Management needs to verify every request for access to an IT service from two perspectives:

That the user requesting access is who they say they are
That they have a legitimate requirement for that service.

The first category is usually achieved by the user providing their username and password. Depending on the organization's security policies, the use of the username and password are usually accepted as proof that the person is a legitimate user. However, for more sensitive services further identification may be required (biometric, use of an electronic access key or encryption device, etc.).

The second category will require some independent verification, other than the user's request. For example:

Notification from Human Resources that the person is a new employee and requires both a username and access to a standard set of services
Notification from Human Resources that the user has been promoted and requires access to additional resources
Authorization from an appropriate (defined in the process) manager
Submission of a Service Request (with supporting evidence) through the Service Desk
Submission of an RFC (with supporting evidence) through Change Management, or execution of a pre-defined Standard Change
A policy stating that the user may have access to an optional service if they need it.

For new services the Change Record should specify which users or groups of users will have access to the Service. Access Management will then check to see that all the users are still valid and automatically provide access as specified in the RfC.

4.5.5.3 Providing Rights

Access Management does not decide who has access to which IT services. Rather, Access Management executes the policies and regulations defined during Service Strategy and Service Design. Access Management enforces decisions to restrict or provide access, rather than making the decision.

As soon as a user has been verified, Access Management will provide that user with rights to use the requested service. In most cases this will result in a request to every team or department involved in supporting that service to take the necessary action. If possible, these tasks should be automated.

The more roles and groups that exist, the more likely that Role Conflict will arise. Role Conflict in this context refers to a situation where two specific roles or groups, if assigned to a single user, will create issues with separation of duties or conflict of interest. Examples of this include:

One role requires detailed access, while another role prevents that access
Two roles allow a user to perform two tasks that should not be combined (e.g. a contractor can log their time sheet for a project and then approve all payment on work for the same project).

Role Conflict can be avoided by careful creation of roles and groups, but more often they are caused by policies and decisions made outside of Service Operation - either by the business or by different project teams working during Service Design. In each case the conflict must be documented and escalated to the stakeholders to resolve.

Whenever roles and groups are defined, it is possible that they could be defined too broadly or too narrowly. There will always be users who need something slightly different from the pre-defined roles. In these cases, it is possible to use standard roles and then add or subtract specific rights as required - similar to the concept of Baselines and Variants in Configuration Management (see Service Transition publication). However, the decision to do this is not in the hands of individual operational staff members. Each exception should be coordinated by Access Management and approved through the originating process.

Access Management should perform a regular review of the roles and groups that it has created and manage to ensure that they are appropriate for the services that IT delivers and supports - and obsolete or unwanted roles/groups should be removed.

4.5.5.4 Monitoring Identity Status

As users work in the organization, their roles change and so also do their needs to access services. Examples of changes include:

Job changes. In this case the user will possibly need access to different or additional services.
Promotions or demotions. The user will probably use the same set of services, but will need access to different levels of functionality or data.
Transfers. In this situation, the user may need access to exactly the same set of services, but in a different region with different working practices and different sets of data.
Resignation or death. Access needs to be completely removed to prevent the username being used as a security loophole.
Retirement. In many organizations, an employee who retires may still have access to a limited set of services, including benefits systems or systems that allow them to purchase company products at a reduced rate.
Disciplinary action. In some cases the organization will require a temporary restriction to prevent the user from accessing some or all of the services that they would normally have access to. There should be a feature in the process and tools to do this, rather than having to delete and reinstate the user's access rights.
Dismissals. Where an employee or contractor is dismissed, or where legal action is taken against a customer (for example for defaulting on payment for products purchased on the Internet), access should be revoked immediately. In addition, Access Management, working together with Information Security Management, should take active measures to prevent and detect malicious action against the organization from that user.

Access Management should understand and document the typical User Lifecycle for each type of user and use it to automate the process. Access Management tools should provide features that enable a user to be moved from one state to another, or from one group to another, easily and with an audit trail.

4.5.5.5 Logging And Tracking Access

Access Management should not only respond to requests. It is also responsible for ensuring that the rights that they have provided are being properly used.

In this respect, Access Monitoring and Control must be included in the monitoring activities of all Technical and Application Management functions and all Service Operation processes.

Exceptions should be handled by Incident Management, possibly using Incident Models specifically designed to deal with abuse of access rights. It should be noted that the visibility of such actions should be restricted. Making this information available to all who have access to the Incident Management system will expose vulnerabilities.

Information Security Management plays a vital role in detecting unauthorized access and comparing it with the rights that were provided by Access Management. This will require Access Management involvement in defining the parameters for use in Intrusion Detection tools.

Access Management may also be required to provide a record of access for specific Services during forensic investigations. If a user is suspected of breaches of policy, inappropriate use of resources, or fraudulent use of data, Access Management may be required to provide evidence of dates, times and even content of that user's access to specific Services. This is normally provided by the Operational staff of that service, but working as part of the Access Management process.

4.5.5.6 Removing Or Restricting Rights

Just as Access Management provides rights to use a Service, it is also responsible for revoking those rights. Again, this is not a decision that it makes on its own. Rather, it will execute the decisions and policies made during Service Strategy and Design and also decisions made by managers in the organization.

Removing access is usually done in the following circumstances:

Death
Resignation
Dismissal
When the user has changed roles and no longer requires access to the service
Transfer or travel to an area where different regional access applies.

In other cases it is not necessary to remove access, but just to provide tighter restrictions. These could include reducing the level, time or duration of access. Situations in which access should be restricted include:

When the user has changed roles or been demoted and no longer requires the same level of access
When the user is under investigation, but still requires access to basic services, such as e-mail. In this case their e-mail may be subject to additional scanning (but this would need to be handled very carefully and in full accordance with the organization's security policy)
When a user is away from the organization on temporary assignment and will not require access to that service for some time.

4.5.6 Triggers, Input And Output / Interprocess Interfaces

Access Management is triggered by a request for a user or users to access a service or group of services. This could originate from any of the following:

An RFC. This is most frequently used for large-scale service introductions or upgrades where the rights of a significant number of users need to be updated as part of the project.
A Service Request. This is usually initiated through the Service Desk, or directly into the Request Fulfillment system, and executed by the relevant Technical or Application Management teams.
A request from the appropriate Human Resources Management personnel (which should be channelled via the Service Desk). This is usually generated as part of the process for hiring, promoting, relocating and termination or retirement.
A request from the manager of a department, who could be performing an HR role, or who could have made a decision to start using a service for the first time.

Access Management should be linked to the Human Resource processes to verify the user's identify as well as to ensure that they are entitled to the services being requested.

Information Security Management is a key driver for Access Management as it will provide the security and data protection policies and tools needed to execute Access Management.

Change Management plays an important role as the means to control the actual requests for access. This is because any request for access to a service is a change, although it is usually processed as a Standard Change or Service Request (possibly using a model) once the criteria for access have been agreed through SLM.

SLM maintains the agreements for access to each service. This will include the criteria for who is entitled to access each service, what the cost of that access will be, if appropriate and what level of access will be granted to different types of user (e.g. managers or staff).

There is also a strong relationship between Access Management and Configuration Management. The CMS can be used for data storage and interrogated to determine current access details.

4.5.7 Information Management

4.5.7.1 Identity

The identity of a user is the information about them that distinguishes them as an individual and which verifies their status within the organization. By definition, the identity of a user is unique to that user. Since there are cases where two users share a common piece of information (e.g. they have the same name), identity is usually established using more than one piece of information, for example:

Name
Address
Contact details, e.g. telephone, e-mail address, etc.
Physical documentation, e.g. driver's licence, passport, marriage certificate, etc.
Numbers that refer to a document or an entry in a database, e.g. employee number, tax number, government identity number, driver's licence number, etc.
Biometric information, e.g. fingerprints, retinal images, voice recognition patterns, DNA, etc.
Expiration date (if relevant).

A user identity is provided to anyone with a legitimate requirement to access IT services or organizational information. These could include:

Employees
Contractors
Vendor staff (e.g. account managers, support personnel, etc.)
Customers (especially when purchasing products or services over the Internet).

Most organizations will verify a user's identity before they join the organization by requesting a subset of the above information. The more secure the organization, the more types of information are required and the more thoroughly they are checked.

Many organizations will be faced with the need to provide access rights to temporary or occasional staff or contractors/suppliers. The management of access to such personnel often proves problematic - closing access after use is often as difficult to manage, or more so, than providing access initially. Well-defined procedures between IT and HR should be established that include failsafe checks that ensure access rights are removed immediately they are no longer justified or required.

When a user is granted access to an application, it should already have been established by the organization (usually the Human Resources or Security Department) that the user is who they say they are.

At this point, all that information is filed and the file is associated with a corporate identity, usually an employee or contractor number and an identity that can be used to access corporate resources and information, usually a user identity or 'username' and an associated password.

4.5.7.2 Users, Groups, Roles And Service Groups

While each user has an individual identity, and each IT service can be seen as an entity in its own right, it is often helpful to group them together so that they can be managed more easily. Sometimes the terms 'user profile' or 'user template' or 'user role' are used to describe this type of grouping.

Most organizations have a standard set of services for all individual users, regardless of their position or job (excluding customers - who do not have any visibility to internal services and processes). These will include services such as messaging, office automation, Desktop Support, telephony, etc. New users are automatically provided with rights to use these services. However, most users also have some specialized role that they perform. For example, in addition to the standard services, the user also performs a Marketing Management role, which requires that they have access to some specialized marketing and financial modelling tools and data.

Some groups may have unique requirements - such as field or home workers who may have to dial in or use Virtual Private Network (VPN) connections, with security implications that may have to be more tightly managed.

To make it easier for Access Management to provide the appropriate rights, it uses a catalogue of all the roles in the organization and which services support each role^R. This catalogue of roles should be compiled and maintained by Access Management in conjunction with HR and will often be automated in the Directory Services tools (see section 5.8).

In addition to playing different roles, users may also belong to different groups. For example, all contractors are required to log their timesheets in a dedicated Time Card System, which is not used by employees. Access Management will assess all the roles that a user plays as well as the groups that they belong to and ensure that they provide rights to use all associated services.

4.5.8 Metrics

Metrics that can be used to measure the efficiency and effectiveness of Access Management include:

Number of requests for access (Service Request, RFC, etc.)
Instances of access granted, by service, user, department, etc.
Instances of access granted by department or individual granting rights
Number of incidents requiring a reset of access rights
Number of incidents caused by incorrect access settings.

4.5.9 Challenges, Critical Success Factors and Risks

Conditions for successful Access Management include:

The ability to verify the identity of a user (that the person is who they say they are)
The ability to verify the identity of the approving person or body
The ability to verify that a user qualifies for access to a specific service
The ability to link multiple access rights to an individual user
The ability to determine the status of the user at any time (e.g. to determine whether they are still employees of the organization when they log on to a system)
The ability to manage changes to a user's access requirements
The ability to restrict access rights to unauthorized users
A database of all users and the rights that they have been granted.