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.

Figure 1: Access management process

2.2 Process triggers

The access management process is initiated as a result of one or more of the following triggers:

• 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

2.3 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:

• 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 organization 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

2.4 Process activities

The individual process activities at each step are detailed as follows.

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 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? • 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 organization 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.

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, [Service Provider] will carry out a user access review every six 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.

[Service Provider] 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 • Username • 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. 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 organization, 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:

• 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

2.6 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.

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.

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 • 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.