Access Management Process
Implementation Guidance (this section must be removed from final version of the document)
Purpose of this document This document sets out the access management process including flowchart, activities, reporting and roles and responsibilities.
Areas of the ITIL® Framework addressed The following areas of the ITIL Framework are addressed by this document: Service Operation – Access Management
General Guidance The control of access to systems and services is a vital element of effective security and one which is often the source of publicized breaches. It is important to have a clear, defined process for user creation and access rights amendment which is audited on a regular basis. Many organizations also fail to review who has access to which systems (and their level of access) resulting in a form of “access creep” where employees collect access rights as they move from role to role. It is well worth spending a significant amount of time up front to put an accurate, role-based security framework in place and then ensuring that this is placed under strict change management. For some application systems the definition of roles and authorities is a specialized skill which may require external resource to get right.
Review Frequency We would recommend that this document is reviewed annually.
Toolkit Version Number ITIL® 2011 Service Operation Process and Policy Pack Version 1 ©CertiKit 2015.
Acknowledgements ITIL is a registered trade mark of AXELOS Limited.
Version 1
Page 1 of 35
Insert date Powered by CertiKit
Access Management Process
Copyright notice Except for any third party works included in this document, as identified in this document, this document has been authored by CertiKit, and is Š copyright CertiKit except as stated below. CertiKit is a trading name of Public I.T. Limited, a company registered in England and Wales with company number 6432088 and registered office at 5 Falcons Rise, Belper, Derbyshire, DE56 0QN.
Licence terms This document is licensed on and subject to the standard licence terms of CertiKit, available on request, or by download from our website. All other rights are reserved. Unless you have purchased this product you only have an evaluation licence. If this product was purchased, a full licence is granted to the person identified as the licensee in the relevant purchase order. The standard licence terms include special terms relating to any third party copyright included in this document.
Disclaimer Please Note: Your use of and reliance on this document template is at your sole risk. Document templates are intended to be used as a starting point only from which you will create your own document and to which you will apply all reasonable quality checks before use. Therefore please note that it is your responsibility to ensure that the content of any document you create that is based on our templates is correct and appropriate for your needs and complies with relevant laws in your country. You should take all reasonable and proper legal and other professional advice before using this document. CertiKit makes no claims, promises, or guarantees about the accuracy, completeness, or adequacy of our document templates, assumes no duty of care to any person with respect its document templates or their contents, and expressly excludes and disclaims liability for any cost, expense, loss or damage suffered or incurred in reliance on our document templates, or in expectation of our document templates meeting your needs, including (without limitation) as a result of misstatements, errors and omissions in their contents.
Version 1
Page 2 of 35
Insert date Powered by CertiKit
Access Management Process
Access Management Process
Document Ref. Version: Dated: Document Author: Document Owner:
Version 1
Page 3 of 35
ITILSO0102 1 Insert date
Insert date Powered by CertiKit
Access Management Process
Revision History Version Date
Revision Author
Summary of Changes
Distribution Name
Title
Approval Name
Version 1
Position
Signature
Page 4 of 35
Date
Insert date Powered by CertiKit
Access Management Process
Contents LIST OF FIGURES .............................................................................................................................................. 6 LIST OF TABLES ................................................................................................................................................ 6 1
INTRODUCTION ....................................................................................................................................... 7 1.1 1.2 1.3 1.4
2
VISION STATEMENT .................................................................................................................................. 7 PURPOSE ................................................................................................................................................... 7 OBJECTIVES .............................................................................................................................................. 7 SCOPE ....................................................................................................................................................... 8
ACCESS MANAGEMENT PROCESS..................................................................................................... 9 2.1 OVERVIEW AND PROCESS DIAGRAM ......................................................................................................... 9 2.2 PROCESS TRIGGERS ................................................................................................................................. 11 2.3 PROCESS INPUTS ..................................................................................................................................... 11 2.4 PROCESS ACTIVITIES ............................................................................................................................... 11 2.4.1 Receive Request ............................................................................................................................ 12 2.4.2 Verification ................................................................................................................................... 12 2.4.3 Access Requests ............................................................................................................................ 12 2.4.4 Removal Requests ......................................................................................................................... 14 2.4.5 Check and Monitor Identity Status ............................................................................................... 15 2.4.6 Log and Track Access ................................................................................................................... 15 2.5 PROCESS OUTPUTS .................................................................................................................................. 16 2.6 ACCESS MANAGEMENT TOOLS ............................................................................................................... 16 2.6.1 Service Desk System...................................................................................................................... 17 2.6.2 Application Administration Tools ................................................................................................. 17 2.6.3 Security Audit Tools ...................................................................................................................... 17 2.7 COMMUNICATION AND TRAINING ........................................................................................................... 17 2.7.1 Communication with Users ........................................................................................................... 18 2.7.2 Communication with IT Teams ..................................................................................................... 18 2.7.3 Communication with System Owners ............................................................................................ 18 2.7.4 Process Performance .................................................................................................................... 18 2.7.5 Training for Access Management ................................................................................................. 18
3
ROLES AND RESPONSIBILITIES ....................................................................................................... 20 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8
OPERATIONAL ROLES ............................................................................................................................. 20 RACI MATRIX ........................................................................................................................................ 20 ACCESS MANAGEMENT PROCESS OWNER ............................................................................................... 21 ACCESS MANAGEMENT PROCESS MANAGER .......................................................................................... 21 REQUESTER ............................................................................................................................................. 22 SERVICE DESK ........................................................................................................................................ 22 APPROVER............................................................................................................................................... 22 USER ....................................................................................................................................................... 23
4
ASSOCIATED DOCUMENTATION ..................................................................................................... 24
5
INTERFACES AND DEPENDENCIES ................................................................................................. 25 5.1 5.2
6
PROCESS MEASUREMENTS AND METRICS .................................................................................. 28 6.1 6.2 6.3
7
OTHER SERVICE MANAGEMENT PROCESSES ........................................................................................... 25 BUSINESS PROCESSES ............................................................................................................................. 26
CRITICAL SUCCESS FACTORS .................................................................................................................. 28 KEY PERFORMANCE INDICATORS............................................................................................................ 28 PROCESS REVIEWS AND AUDITS ............................................................................................................. 28
PROCESS REPORTING ......................................................................................................................... 30 7.1 7.2
PROCESS REPORTS .................................................................................................................................. 31 OPERATIONAL REPORTS .......................................................................................................................... 32
Version 1
Page 5 of 35
Insert date Powered by CertiKit
Access Management Process
8
GLOSSARY, ABBREVIATIONS AND REFERENCES ...................................................................... 33 8.1 8.2 8.3
GLOSSARY .............................................................................................................................................. 33 ABBREVIATIONS...................................................................................................................................... 35 REFERENCES ........................................................................................................................................... 35
List of Figures FIGURE 1 - ACCESS MANAGEMENT PROCESS.......................................................................................................... 10
List of Tables TABLE 1 - RACI MATRIX ...................................................................................................................................... 20 TABLE 2 - ASSOCIATED DOCUMENTATION ............................................................................................................ 24 TABLE 3 - INTERFACES WITH OTHER SERVICE MANAGEMENT PROCESSES.............................................................. 26 TABLE 4 - INTERFACES WITH BUSINESS PROCESSES ............................................................................................... 27 TABLE 5 - CRITICAL SUCCESS FACTORS ................................................................................................................. 28 TABLE 6 - KEY PERFORMANCE INDICATORS .......................................................................................................... 28 TABLE 7 - PROCESS REPORTS................................................................................................................................. 31 TABLE 8 - OPERATIONAL REPORTS ........................................................................................................................ 32 TABLE 9 - GLOSSARY OF RELEVANT TERMS ......................................................................................................... 34
Version 1
Page 6 of 35
Insert date Powered by CertiKit
Access Management Process
1 Introduction 1.1
Vision Statement
The vision of [Service Provider] in the area of service management is as follows: [Insert the vision statement defined as part of service strategy] This process forms a key part of the realisation of that vision. 1.2
Purpose
Access management plays a critical part in the secure delivery of services and the protection of [Organization Name] assets such as personal information, financial data, intellectual property and commercially sensitive documents. In an increasingly connected world where cyber-crime is becoming more prevalent, the secure allocation and control of access forms a key cornerstone of our information security approach. But access management is not just about preventing access to unauthorised people; it is also about ensuring that the level of service provided to legitimate users of our systems is responsive as well as secure and that unnecessary delays to the delivery of products and services to customers is avoided. This document defines how the process of access management is implemented within [Organization name]. The purpose of the access management process according to ITIL®1 is:
“to provide the right for users to be able to use a service or group of services.” (Source: “ITIL Service Operation Book 2011. Copyright © AXELOS Limited 2011. Reproduced under license from AXELOS) 1.3
Objectives
The objectives of the access management process are to: 1
Provide authorised users with access to services in line with service level requirements Prevent users from accessing resources to which they are not authorised
ITIL® is a registered trade mark of AXELOS Limited.
Version 1
Page 7 of 35
Insert date Powered by CertiKit
Access Management Process
1.4
Ensure that access to services is controlled according to business requirements at all times Scope
The scope of this process is defined according to the following parameters:
Organizational o [List organizations and parts of those organizations covered] Geographical o [List locations from which access requests will be submitted and managed] Services o [Define the services covered by the process] Technical o [If necessary, cover the technology that will be managed via this process]
This process covers the management of all access by [Service Provider] in support of the customers and users of services defined in the service catalogue. The following areas are specifically excluded from this process: [Describe any areas that need to be clearly stated as outside the scope]
Version 1
Page 8 of 35
Insert date Powered by CertiKit
Access Management Process
2 Access Management Process 2.1
Overview and Process Diagram
The process of access management is shown in Figure 1 and summarised below. Changes to access for individuals may arise for a number of reasons, including new starters, leavers, secondments and promotions and they will therefore be submitted from a number of sources such as Human Resources, line management and the individual themselves. It is important that the rules for granting, removing and amending access are clear and are in line with [Organization Name] information security policies. These rules include who may approve such access and this will vary according to the system or area involved. Access management has a strong link with the request fulfilment process as this will usually be used as the vehicle for processing access requests; a request model will therefore exist for each type of access request and will include the appropriate routing for approval. Checks will be made at each stage of the process to ensure that the people involved are who they say they are and that the correct approvals are given at each stage. The security management information system will be used to enable this. Once checked and approved, the access request will be carried out according to its type (e.g. new, change or removal). Separation of duties between the IT analysts involved will also be in place so that no one person is able to carry out a task on their own e.g. create a new user and provide that account with access to resources. This policy will be implemented with appropriate access restrictions on the members of the team carrying it out. In addition to fulfilling requests related to access management, the process also involves monitoring levels of access and identifying occasions where the access control policy has been violated e.g. when one user uses another’s account to access a system. Such instances will be raised as security incidents via the incident management process. Regular access reports will also be produced to allow system owners to verify that the users and their access levels are correct.
Version 1
Page 9 of 35
Insert date Powered by CertiKit
Access Management Process
Change request
Human resources request
Service request
Application script or request
Receive request
Verification
N
Valid user?
Y
N
Valid request?
Y
Check and monitor Identity status
N
Remove access?
N
Security management information system
Request access?
Y
Y
Remove or restrict rights
Provide rights
Security management information system
Log and track access
Incident?
Y
Incident management
N
End
Figure 1 - Access management process
(Source: “ITIL Service Operation Book 2011. Copyright Š AXELOS Limited 2011. Reproduced under license from AXELOS)
Version 1
Page 10 of 35
Insert date Powered by CertiKit
Access Management Process
2.2
Process Triggers
The access management process is initiated as a result of one or more of the following triggers:
2.3
A request to create a new user account and provide access to specified services A request to remove access to one or more services on a temporary or permanent basis A request to amend the access of an existing user A change request to create, amend or remove access to one or more users, perhaps as part of a project or as a result of a security review As a result of a security breach (i.e. an incident) which requires prompt action to limit the impact to the organization Process Inputs
The process of access management requires a number of inputs in order to be able to function effectively. These may not always be available but will ideally be:
2.4
Information security policies with regard to areas such as: o Access control methods (e.g. single sign-on) o User account naming conventions o Password policies (length, strength etc.) o Internet access Up to date information regarding system and service owners and request approvers and their contact details Information about the user population, including business organisation structure and upcoming changes to it The service catalogue with details of services available and service levels for access management tasks Procedures describing the method of access management for individual systems and services e.g. how to create a user, profile parameters to be specified Incidents (possibly arising from event management) identifying potential security breaches related to access management Change requests where multiple user accounts are involved or the action required is not standard Process Activities
The individual process activities at each step are detailed as follows.
Version 1
Page 11 of 35
Insert date Powered by CertiKit
Access Management Process
2.4.1
Receive Request
Access to IT systems should be requested via the IT Service Desk. Where online or electronic forms are available for specific systems these should be used. In addition to system-specific details, the following should always be given:
Name Role Department Contact Details Name of line manager Start date (and end date if applicable)
For each system to which access is requested, further information may be required such as:
Name of an existing user whose access should be duplicated (if new user is performing the same or similar role) Modules required Payroll or employee number
Where possible, requests for access should be pre-approved by the system owner or line manager before being submitted to the IT Service Desk from the approver’s email address. 2.4.2
Verification
In general the fact that a request has been submitted from an existing user account will be taken as evidence that the submitting user is who they say they are. If a request is submitted via telephone or personal visit then further identification will be required. If this is not available then the request must be submitted via one of the authorised channels such as the service request system as evidence of identity. All requests for access to a specific system must be approved by the system owner. This will normally be a manager within the organization with specific responsibility for the security and use of that system. In some circumstances the system owner may delegate authority to approve requests to the employee’s line manager, but this fact must be recorded and verified on a regular basis. No user accounts should be created without the required approval having been given. In the event that approval is refused, the IT service desk will inform the submitter of the request, together with any reason given. It is up to the requester to discuss the rejection directly with the system owner if required. 2.4.3
Access Requests
Once an approved request with sufficient details has been received, the IT Service Desk will manage the creation of the user account. This may be done by the IT Version 1
Page 12 of 35
Insert date Powered by CertiKit
Access Management Process
Service Desk themselves, or passed to a second or third line team to perform. User accounts should be created in line with the standards established and documented for that specific system. These will detail parameters such as account name format, initial program calls, assigned printers etc. Account creations will be logged via the IT Service Desk System as service requests and tracked through to closure. The name of the IT service desk analyst creating the user account must also be recorded. The IT Service Desk will set an initial password. This will be a strong password according to published guidelines. A random password generation tool may be used if available. The password will be set to expire upon first logon at which point the user will define a new password which is known only to them and which meets the parameters defined for that system. If additional authentication tools are to be used (such as an RSA Token) the appropriate procedure for the setup of these items should be followed. Once the user account has been created, the request should be assigned to a different member of the IT service desk team to assign the access rights to the account. Under no circumstances should the account be created and access rights assigned by the same person. For most systems, this will be achieved by placing the user account in a specific group or role that is specified on the approved request. Upon successful completion of account setup the IT Service Desk will inform the user of the account name via email along with instructions regarding how to set a strong password when changing the initial one set by the IT Service Desk. The initial password should be communicated by telephone directly to the user after verifying the user’s identity. If the user is not available, a message should be left for them to contact the IT service desk. The password should not be left as a message. If an authentication token is also required, this will be sent to the user by internal or external post. For external mail, a recorded delivery service should be used. Correct receipt of the token should be confirmed with the user by the IT service desk before communicating the initial password. The service request will then be closed on the IT Service Management System. Privileged access rights are those that involve a higher level of system access than a typical user. This includes “root” or “domain administrator” access and various types of supervisory access within application systems and databases. The process for managing privileged access rights is basically the same as for other types of user but the approval and review aspects should be treated much more rigorously. The number of people with such rights should be carefully controlled and rights should be removed as soon as they are no longer required. The following factors should be considered by the system owner as part of the approval criteria for such requests: • •
Why does the user need privileged access rights? Is there an alternative way to achieve the desired end result without granting privileged access rights?
Version 1
Page 13 of 35
Insert date Powered by CertiKit
Access Management Process
• • •
Does the user have the necessary training and expertise to avoid mistakes when using the privileged access rights? How long are the rights needed for? Is a documented agreement such as a Non-Disclosure Agreement required (e.g. for third parties)?
A user who requires privileged access rights such as domain admin should request that a separate user account be created with these rights (e.g. john smith admin). Under no circumstances should the password for the default admin user account be issued. If the need for access is temporary then an expiry date should be set on the user account when it is created. When creating such accounts it should be emphasised to the user that they are only for use when a higher level of permissions is needed and their normal, lower access level account should be used most of the time. The need for accounts to hold privileged access rights will be reviewed according to the standard review process but may be performed on a more frequent basis depending on the sensitivity of the system(s) involved. 2.4.4
Removal Requests
It is the responsibility of users and their managers to inform the IT Service Desk in a timely manner when employees leave the organisation and so no longer need access to IT systems. As much advance notice as possible should be given. In those circumstances where an employee has been involuntarily terminated at short notice the IT Service Desk must be informed by telephone immediately. The IT service desk will assess the urgency of the deregistration request based on the information provided and will decide whether to disable the user account straight away or to wait until the user leaves the organization. In general for unfriendly terminations deregistration will be completed immediately whereas for voluntary resignations it will be done on the day the person leaves. For most systems, the IT Service Desk will take the initial step of disabling the user account rather than deleting it. This will prevent access by the user but will retain all of the information associated with the account and its data. At a later date and with the system owner’s permission, the account may be deleted once any outstanding issues have been resolved. All user accounts associated with the user in question should be disabled even if Single Sign On (SSO) is in place e.g. if the user is in Finance, access to Active Directory and the Finance system (and any other systems the user has an account on) should be disabled. This is necessary to prevent the account being used by someone who still has access to the network in future. Accounts should be disabled in order of importance e.g. the Finance system before email.
Version 1
Page 14 of 35
Insert date Powered by CertiKit
Access Management Process
If the deregistered user has an authentication token this should be retrieved as part of the termination process and returned to the IT service desk. 2.4.5
Check and Monitor Identity Status
From time to time there is a need to amend user access rights, often as a result of role changes or promotions. This adjustment must be carried out in a secure manner to ensure that the principles set out in the information security policy are maintained. Once the request has been approved, the request should be allocated to a member of the IT service desk team to assign the amended access rights to the account. For most systems, this will be achieved by placing the user account in a different group or role as specified on the approved request. Upon successful completion of the adjustment request the IT Service Desk will inform the user via email. If an authentication token is also required as a result of the adjusted access rights, this will be sent to the user by internal or external post. For external mail, a recorded delivery service should be used. Correct receipt of the token should be confirmed with the user by the IT service desk before closing the request record on the IT service management system. 2.4.6
Log and Track Access
In order to ensure that access to IT systems is only available to authorised personnel, the [IT Department] will carry out a user access review every 6 months. The scope of the review should be defined in terms of the systems and networks that will be covered. The owners of the systems and networks to be reviewed should be informed of the intention to carry out a review so that adequate time can be allocated to complete it within the target timescale. The [IT Department] will create a listing all of the authorised users of each system together with their current level of access. This should as a minimum state the following information:
Name of system User name User role title User department User account name Date of user account creation User role(s) assigned Additional access rights assigned Are privileged access rights assigned to this account
Where appropriate, supporting information such as the specific permissions associated with each role defined in the system should also be provided.
Version 1
Page 15 of 35
Insert date Powered by CertiKit
Access Management Process
The report should be produced in electronic form (either spreadsheet or document) and securely emailed to the system owner. In some circumstances it may be appropriate to encrypt the file containing the report e.g. if it is to be sent to a remote office via the Internet. The list will be reviewed by the system owner and any accounts that should not be maintained will be identified. In the event that an account is found to have been accessed after an employee has left the organisation, a security incident will be raised and investigated in accordance with documented procedures. System owners will look to identify: • • • • •
People who should not have access (e.g. leavers) User accounts with more access than required by the role User accounts with incorrect role allocations User accounts that do not provide adequate identification e.g. generic or shared accounts Any other issues that do not comply with the organization’s access control policy
A list of issues identified should be compiled by the system owner and sent to the [Information Security Manager]. Any issues that appear to be urgent should be flagged as such without delay so that prompt action may be taken. Incidents should be raised where a breach of information security policy has been identified. Actions resulting from the review should be prioritised and carried out according to their urgency. Non urgent issues may be added to the continual improvement plan as part of a wider programme of improvement. A record should be kept of all actions taken. 2.5
Process Outputs
The outputs of the access management process will be the following: 2.6
New user accounts with appropriate access rights Existing user accounts with amended access rights Removed user accounts with disabled access New incidents where access control policy has been violated Access review assessments and inputs to continual service improvement Access Management Tools
There are a number of key software tools that underpin an effective access management process. These are subject to change as requirements and technology are updated and so specific systems are not described here. However the main types of tools that play a significant part in the process within [Organization Name] are as follows.
Version 1
Page 16 of 35
Insert date Powered by CertiKit
Access Management Process
2.6.1
Service Desk System
The service desk system provides the workflow engine and database to track the core activities within access management. These include:
Request logging Routing and assignment of requests to teams and individuals Recording of actions against requests Updating of request status from open through to closed Definition and selection of request models Assessment of impact and urgency and auto-calculation of priority Email communication with users from within request records Request categorisation to multiple levels Reporting Definition of SLA targets for service request fulfilment Automated request escalation according to SLA Provision of self-service interface for users to submit service requests and view status of open requests Facility to create request records from an email mailbox
The service desk system is integrated with the systems that support various other processes, including incident, change and configuration management. 2.6.2
Application Administration Tools
In most cases the actual creation of user accounts and the assignment of access rights will be achieved using an administrative interface to each individual system. This may vary for those systems where single sign-on is active but an element of local configuration may still be required. For those systems with Role-Based Access Control (RBAC) user setup should be a straightforward two step procedure of user account creation and assignment to a role (note separation of duties required). 2.6.3
Security Audit Tools
Reporting tools may be used to query system logs for access-related messages (e.g. unsuccessful logon attempts) which may give rise to incidents in some circumstances. Audit reports may be generated from within the administrative interface of individual systems. 2.7
Communication and Training
There are various forms of communication that must take place for the access management process to be effective. These are described below. Version 1
Page 17 of 35
Insert date Powered by CertiKit
Access Management Process
2.7.1
Communication with Users
As part of the processing of access management requests there may be communication with the user involved in order to clarify details (such as contact information) and to check that the request has been fulfilled correctly e.g. in the case of a user creation. The name of a new user account and the initial password will also need to be passed on. 2.7.2
Communication with IT Teams
Depending on the user account involved, it may be necessary to pass access requests on to other teams within IT to fulfil all or part of the request. This will be defined in the request model used. 2.7.3
Communication with System Owners
In general, system owners will be required to authorise access requests to the systems they take ownership of and to perform regular checks that the access permissions in place remain appropriate. 2.7.4
Process Performance
It is important that the performance of the access management process is monitored and reported upon on a regular basis in order to assess whether the process is operating as expected. The content of performance reports is set out in section 6 of this document but it is vital that the reports are not only produced but are also communicated to the appropriate audience. This will include the management of IT concerning resource utilisation and allocation. 2.7.5
Training for Access Management
In addition to a well-defined process and appropriate software tools it is essential that the people aspects of access management are adequately addressed. The process requires that training be provided to all participants in order that it runs as smoothly as possible. The main areas in which training will be required for IT staff participating in access management are as follows.   
Information security policies, their content and implications for access management The access management process itself, including the activities, roles and responsibilities involved Access management software tools such as the service desk system and application administrative interfaces
Version 1
Page 18 of 35
Insert date Powered by CertiKit
Access Management Process
The basics of the technology and how it is implemented within [Organization Name] The business, its structure, locations, priorities and people
In addition, training should be provided to the user population regarding how to interface with access management, including:
How to submit an access request via the various means available Use of the self-service portal, including submitting, updating and tracking an access request Use of the self-help service available via the intranet
This training may be provided via short workshops and supplemented by on demand resources such as videos and user guides.
Version 1
Page 19 of 35
Insert date Powered by CertiKit
Access Management Process
3 Roles and Responsibilities This section describes the main operational roles involved in the access management process, their interaction with the process and their detailed responsibilities. 3.1
Operational Roles
The following main roles participate in the access management process:
Requester Service Desk Approver User Process Manager
There may also be interaction with IT and business management at various points in the process. 3.2
RACI Matrix
The table below clarifies the responsibilities of these roles at each step of the access management process using the RACI system, i.e.: R= Responsible
A= Accountable
Role: Requester Step Receive request R Verification I Access requests I Removal requests I Check and monitor I identity status Log and track access
C= Consulted Service desk I R R R R
Approver
R
C
I= Informed User
R I I I
Process Manager A A A A A A
Table 1 - RACI Matrix
Version 1
Page 20 of 35
Insert date Powered by CertiKit
Access Management Process
3.3
Access Management Process Owner
The responsibilities of the access management process owner are:
Sponsoring, designing and change managing the process and its metrics Defining the process strategy Assisting with process design Ensuring that appropriate process documentation is available and current Defining appropriate policies and standards to be employed throughout the process Periodically auditing the process to ensure compliance to policy and standards Periodically reviewing the process strategy to ensure that it is still appropriate and change as required Communicating process information or changes as appropriate to ensure awareness Providing process resources to support activities required throughout the service lifecycle Ensuring process technicians have the required knowledge and the required technical and business understanding to deliver the process and understand their role in the process Reviewing opportunities for process enhancements and for improving the efficiency and effectiveness of the process Addressing issues with the running of the process Identifying improvement opportunities for inclusion in the CSI register Making improvements to the process Working with other process owners to ensure there is an integrated approach to the design and implementation of request fulfilment, problem management, event management, access management and incident management
(Source: “ITIL Service Operation Book 2011. Copyright © AXELOS Limited 2011. Reproduced under license from AXELOS) 3.4
Access Management Process Manager
The responsibilities of the access management process manager are:
Working with the process owner to plan and co-ordinate all process activities Ensuring all activities are carried out as required throughout the service lifecycle Appointing people to the required roles Managing resources assigned to the process Working with service owners and other process managers to ensure the smooth running of services Monitoring and reporting on process performance Identifying improvement opportunities for inclusion in the CSI register
Version 1
Page 21 of 35
Insert date Powered by CertiKit
Access Management Process
Working with the CSI manager and process owner to review and prioritise improvements in the CSI register Making improvements to the process implementation Planning and managing support for access management tools and processes Coordinating interfaces between access management and other service management processes Driving the efficiency and effectiveness of the access management process Producing management information Managing the work of access management staff Monitoring the effectiveness of access management and making recommendations for improvement Developing and maintaining the access management systems Developing and maintaining the access management process and procedures
(Source: “ITIL Service Operation Book 2011. Copyright © AXELOS Limited 2011. Reproduced under license from AXELOS) 3.5
Requester
The person submitting the access management request will:
3.6
Ensure that all required information is provided in support of the request Answer any additional questions posed by the service desk regarding the request Submit requests in sufficient time to allow the request to be processed within the SLA Provide feedback regarding satisfaction levels with the access management process Service Desk
The service desk’s responsibilities with respect to access management are as follows:
3.7
The receipt, verification and management of access requests in line with procedures and the SLA The creation of new user accounts and the assignment of rights to them The amendment of user accounts and access rights The removal of access rights in accordance with approved requests The running of standard reports to monitor the ongoing assignment of access rights Approver
Within the context of the access management process and in their role as system owner, the approver will:
Version 1
Page 22 of 35
Insert date Powered by CertiKit
Access Management Process
3.8
Maintain a clear understanding of the types of users of the systems under their ownership and the access rights required Review access requests for systems under their ownership in a timely manner to allow the SLA to be met Signify their approval or rejection of access requests according to established procedures Nominate one or more deputies to perform their role when they are unavailable User
With respect to access management requests the user will:
Co-operate with the service desk in the fulfilment of the access request, including the provision of additional information when required Test and confirm the successful completion of the access request when asked to do so by the service desk Comply with information security policies at all times
Version 1
Page 23 of 35
Insert date Powered by CertiKit
Access Management Process
4 Associated Documentation The following documentation is relevant to the access management process and should be read in conjunction with it: Document ITIL Service Operation Book Request Fulfilment module user guide Service management system user guide Service management system administration guide Application system administration guides Incident Management Process Change Management Process Request Fulfilment Process
Reference ISBN number
Version 2011
Location [Network drive location] [Network drive location] [Network drive location] [Network drive location]
V1.0 Final
[Network drive location] [Network drive location] [Network drive location]
9780113313075
ITILSO0301
V1.0 Final ITILSO0501
V1.0 Final
Table 2 - Associated Documentation
In the event that any of these items is not available please contact the Service Desk Supervisor.
Version 1
Page 24 of 35
Insert date Powered by CertiKit
Access Management Process
5 Interfaces and Dependencies The access management process has a number of interfaces and dependencies with other processes within service management and the business. These are outlined here and are described in further detail in the relevant procedural documentation. 5.1
Other Service Management Processes
ITIL Lifecycle Stage Service Design
Process Service Level Management Service Catalogue Management
IT Service Continuity Management Information Security Management Service Transition
Change Management Knowledge Management Incident Management
Service Operation
Version 1
Request Fulfilment
Inputs to access management from the named process Targets for the turnaround of access requests Service catalogue listing available services Details of service and system owners Requirements for access when service continuity plans have been invoked Information security policies for access control, separation of duties etc. Change requests raised to create/amend/remove multiple users Information about technology and business Incidents requiring action to be taken by access management Provides the mechanism through which access requests are
Page 25 of 35
Outputs from access management to the named process Reports on achievement against targets Feedback on user population and distribution
Access created for service continuity situations Reports on access management activities for analysis Feedback on changes processed Feedback on user population and distribution Incidents raised as result of detected security breaches Completed requests
Insert date Powered by CertiKit
Access Management Process
ITIL Lifecycle Stage
Process
Event Management Continual Service Improvement
7-Step Improvement Process
Inputs to access management from the named process processed Alerts regarding unauthorised access attempts and breaches Improvement approach
Outputs from access management to the named process Feedback on usefulness of information provided and improvements to it Identified process improvements
Table 3 - Interfaces with other service management processes
5.2
Business Processes
[Business processes will obviously be numerous and highly industry- and organization-specific. We therefore recommend that you only address those that are closely linked to the process in question here.] Business Area
Business Process
Inputs to access management from the named process
Human Resources
Recruitment
Requests for new users to be created Requests for changed access permissions Requests for accounts to be disabled
Employee promotion and secondment Employee termination
Outputs from access management to the named process Notification of completed requests Notification of completed requests Notification of completed requests
Finance Sales and Marketing Production/Operations Legal and Compliance Research and Development Distribution and Logistics
Version 1
Page 26 of 35
Insert date Powered by CertiKit
Access Management Process
Business Area
Business Process
Inputs to access management from the named process
Outputs from access management to the named process
Customer Services Purchasing Public Relations Administration [Insert further business processes here] Table 4 - Interfaces with business processes
Version 1
Page 27 of 35
Insert date Powered by CertiKit
Access Management Process
6 Process Measurements and Metrics In order to determine whether the access management process is working effectively and achieving what we want it to achieve, we must first define our critical success factors and identify how we will determine if they are being fulfilled. 6.1
Critical Success Factors
The following factors are defined as critical to the success of the access management process: Ref. CSF1 CSF2 CSF3
Critical Success Factor Access is provided to those that are legitimately authorised Access is denied to those that are not authorised The process provides value for money
Table 5 - Critical success factors
Achievement of these critical success factors will be measured via the use of relevant Key Performance Indicators (KPIs). 6.2
Key Performance Indicators
The following KPIs will be used on a regular basis to evidence the successful operation of the access management process: CSI Ref. CSF1
KPI Ref. KPI1.1 KPI1.2
CSF2
KPI2.1
CSF3
KPI3.1 KPI3.2
Key Performance Indicator Percentage of access requests processed within SLA targets Percentage of access requests where incorrect access was granted Number and percentage of unauthorised users or access found as a result of regular reviews Number of incidents where inappropriate access was a factor Cost per access request overall Cost per new user request
Table 6 - Key performance indicators
6.3
Process Reviews and Audits
Reviews will be carried out by the process owner in conjunction with the process manager on a three monthly basis to assess whether the access management process is operating effectively and delivering the desired results. These reviews will have the following as input:
Version 1
Page 28 of 35
Insert date Powered by CertiKit
Access Management Process
Follow-up action list from previous reviews Relevant changes and developments within the business and IT KPI reports from the previous period Details of all complaints logged during the period Internal and external audit reports Feedback from users and customers Identified opportunities for improvement
Each review will be documented by the process owner and actions arising agreed and published. Audits will be carried out on an annual basis by the internal auditing department. The scope and timing of the audit will be agreed in advance. Recommendations from the audit will be published and actions discussed and agreed with the process owner. All actions will be followed up by the internal auditor within the agreed timescales for each action.
Version 1
Page 29 of 35
Insert date Powered by CertiKit
Access Management Process
7 Process Reporting It is important that regular reports are produced for two main reasons: 1. to help to assess whether the access management process is meeting its critical success factors (see section 6.1 above) 2. to assist operational supervisors in the day-to-day management of the access management process and its resourcing These two purposes may require different views of the information available and will need to be produced at varying frequencies for differing audiences. The format of the reports produced will also be subject to regular review and amendment as requirements become clearer and the available reporting technology within the business matures. What must be avoided is the continued production of reports that are not read and serve no purpose. It is up to the process owner, in consultation with the process manager, to ensure that all reporting remains focussed and relevant. The following tables show the reports that will be produced together with their purpose, method of production, data source, audience and frequency. Some of the reports listed will be used for multiple purposes.
Version 1
Page 30 of 35
Insert date Powered by CertiKit
Access Management Process
7.1
Process Reports
The following reports are produced by the process manager and are intended to help the process owner assess whether the CSFs for access management are being met. Ref. CSFR1
Report Title SLA met
CSFR2
Incorrect access
CSFR3
Unauthorised users
CSFR4
Access incidents
CSFR5
Request cost
CSFR6
New user cost
Description Percentage of access requests processed within SLA targets Percentage of access requests where incorrect access was granted Number and percentage of unauthorised users or access found as a result of regular reviews Number of incidents where inappropriate access was a factor Cost per access request overall
Cost per new user request
Method of Production Service desk system reporting tool
Data Source Service desk database
Frequency Audience Monthly Process owner
Service desk system reporting tool
Service desk database
Monthly
Process owner
Spreadsheet produced from figures obtained during access reviews
Access review results
Quarterly
Process owner
Service desk system reporting tool
Service desk database
Monthly
Process owner
Service desk system reporting tool Costing information from HR and IT Finance Service desk system reporting tool Costing information from HR and IT Finance
Service desk database Finance model
Quarterly
Process owner
Service desk database Finance model
Quarterly
Process owner
CSFR13 [Insert further reports] Table 7 - Process reports
Version 1
Page 31 of 35
Insert date Powered by CertiKit
Access Management Process
7.2
Operational Reports
The following reports are to provide further ongoing operational information to the process manager. They are in addition to the relevant process reports described above. Ref. OPR1
Report Title Request trend
OPR2
Request time
OPR3
Request sources
OPR4
Requests by system Requests by Analyst [Insert further reports]
OPR5
Description Number of requests processed by type Average time to process an access request, by type Number of requests by source e.g. department Number of requests by application system Number of requests processed by IT analyst
Method of Production Service desk system reporting tool Service desk system reporting tool Service desk system reporting tool Service desk system reporting tool Service desk system reporting tool
Data Source Service desk database Service desk database Service desk database Service desk database Service desk database
Frequency Weekly Monthly Monthly Monthly Weekly
Audience Process manager Process manager Process manager Process manager Process manager
Table 8 - Operational reports
Version 1
Page 32 of 35
Insert date Powered by CertiKit
Access Management Process
8 Glossary, Abbreviations and References 8.1
Glossary
For a full list of terms used and their definitions within ITIL, please refer to the back of any of the books in the ITIL Lifecycle Suite 2011. The following subset of terms is specifically relevant to this document: Term alert application audit
category change closed continual service improvement directory service escalation event identity impact incident incident management information security policy IT service
key performance indicator Version 1
Meaning A notification that a threshold has been reached, something has changed, or a failure has occurred Software that provides functions that are required by an IT service Formal inspection and verification to check whether a standard or set of guidelines is being followed, that records are accurate, or that efficiency and effectiveness targets are being met A named group of things that have something in common The addition, modification or removal of anything that could have an effect on IT services The final status in the lifecycle of an incident, problem, change etc. When the status is closed, no further action is taken A stage in the lifecycle of a service. Continual service improvement ensures that services are aligned with changing business needs by identifying and implementing improvements to IT services that support business processes An application that manages information about IT infrastructure available on a network, and corresponding user access rights An activity that obtains additional resources when these are needed to meet service level targets or customer expectations. A change of state that has significance for the management of an IT service or other configuration item A unique name that is used to identify a user, person or role A measure of the effect of an incident, problem or change on business processes An unplanned interruption to an IT service or reduction in the quality of an IT service The process responsible for managing the lifecycle of all incidents The policy that governs the organisation’s approach to information security management A service provided by an IT service provider. An IT service is made up of a combination of information technology, people and processes A metric that is used to help manage an IT service, process, plan, project or other activity
Page 33 of 35
Insert date Powered by CertiKit
Access Management Process
Term monitoring
priority rights role security management information system service catalogue service desk service level agreement service level target service owner urgency user
vision
Meaning Repeated observation of a configuration item, IT service or process to detect events and to ensure that the current status is known A category used to identify the relative importance of an incident, problem or change Entitlements or permissions granted to a user or role A set of responsibilities, activities and authorities assigned to a person or team A set of tools, data and information that is used to support information security management
A database or structured document with information about all live IT services, including those available for deployment The single point of contact between the service provider and the users An agreement between an IT service provider and a customer A commitment that is documented in a service level agreement A role responsible for managing one or more services throughout their entire lifecycle A measure of how long it will be until an incident, problem or change has a significant impact on the business A person who uses the IT service on a day-to-day basis. Users are distinct from customers, as some customers do not use the IT service directly A description of what the organization intends to become in the future
Table 9 - Glossary of Relevant Terms
(Based on “ITIL Service Operation Book 2011�. Copyright Š AXELOS Limited 2011. Reproduced under license from AXELOS)
Version 1
Page 34 of 35
Insert date Powered by CertiKit
Access Management Process
8.2
Abbreviations
The following abbreviations are used in this document: CSF CSI IT ITIL RBAC SKMS SLA SSO 8.3
Critical Success Factor Continual Service Improvement Information Technology Information Technology Infrastructure Library Role-Based Access Control Service Knowledge Management System Service Level Agreement Single Sign On
References
The following sources have been used in the creation of this process document and should be consulted for more information on particular aspects of it:
ITIL Service Operation Book 2011. Copyright © AXELOS Limited 2011 [Organization Name] IT organization structure, published dd/mm/yy [Organization Name] Business Strategy yyyy-yyyy [Organization Name] IT Strategy yyyy-yyyy [Organization Name] IT Service Management Strategy yyyy-yyyy
Version 1
Page 35 of 35
Insert date Powered by CertiKit