User Access Management Process
PCI DSS Toolkit: Version 6 ©CertiKit
User Access Management Process [Insert classification]
Implementation guidance The header page and this section, up to and including Disclaimer, must be removed from the final version of the document. For more details on replacing the logo, yellow highlighted text and certain generic terms, see the Completion Instructions document.
Purpose of this document This document describes how user accounts and access will be created and managed.
Areas of the standard addressed The following areas of the PCI DSS standard are addressed by this document: • •
Requirement 7: Restrict access to cardholder data by business need to know Requirement 8: Identify and authenticate access to system components
General guidance This is an important area that needs adequate consideration as any lack of rigour will invalidate many of your other information security controls. Ensure that appropriate authorisation procedures are established to protect your IT environment. This may involve setup of your request management system to route user creation, change and deletion requests to the right people. Try to ensure segregation of duties in user creation and access rights assignment and make sure that regular audits are carried out to identify any areas for further investigation.
Review frequency We would recommend that this document is reviewed annually and upon significant change to the organization.
Document fields This document may contain fields which need to be updated with your own information, including a field for Organization Name that is linked to the custom document property “Organization Name”. To update this field (and any others that may exist in this document): 1. Update the custom document property “Organization Name” by clicking File > Info > Properties > Advanced Properties > Custom > Organization Name.
Version 1
Page 2 of 21
[Insert date]
User Access Management Process [Insert classification] 2. Press Ctrl A on the keyboard to select all text in the document (or use Select, Select All via the Editing header on the Home tab). 3. Press F9 on the keyboard to update all fields. 4. When prompted, choose the option to just update TOC page numbers. If you wish to permanently convert the fields in this document to text, for instance, so that they are no longer updateable, you will need to click into each occurrence of the field and press Ctrl Shift F9. If you would like to make all fields in the document visible, go to File > Options > Advanced > Show document content > Field shading and set this to “Always”. This can be useful to check you have updated all fields correctly. Further detail on the above procedure can be found in the toolkit Completion Instructions. This document also contains guidance on working with the toolkit documents with an Apple Mac, and in Google Docs/Sheets.
Copyright notice Except for any specifically identified third-party works included, this document has been authored by CertiKit, and is ©CertiKit except as stated below. CertiKit is a company registered in England and Wales with company number 6432088.
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
Version 1
Page 3 of 21
[Insert date]
User Access Management Process [Insert classification] 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 4 of 21
[Insert date]
User Access Management Process [Insert classification]
User Access Management Process
Version 1
DOCUMENT CLASSIFICATION
[Insert classification]
DOCUMENT REF
PCI-DSS-DOC-07-2
VERSION
1
DATED
[Insert date]
DOCUMENT AUTHOR
[Insert name]
DOCUMENT OWNER
[Insert name/role]
Page 5 of 21
[Insert date]
User Access Management Process [Insert classification]
Revision history VERSION
DATE
REVISION AUTHOR
SUMMARY OF CHANGES
Distribution NAME
TITLE
Approval NAME
Version 1
POSITION
SIGNATURE
Page 6 of 21
DATE
[Insert date]
User Access Management Process [Insert classification]
Contents 1
Introduction ........................................................................................................................ 8
2
User registration .................................................................................................................. 9
3
4
2.1
Requesting access ...................................................................................................... 11
2.2
Access approval or rejection ....................................................................................... 11
2.3
User account creation ................................................................................................ 11
2.4
Allocation of secret authentication information .......................................................... 12
2.5
User access rights assignment .................................................................................... 12
2.6
Informing the user ..................................................................................................... 12
User access adjustment ...................................................................................................... 13 3.1
User access adjustment request ................................................................................. 14
3.2
Access approval or rejection ....................................................................................... 14
3.3
Adjust access rights .................................................................................................... 14
3.4
Informing the user ..................................................................................................... 15
User deregistration ............................................................................................................ 16 4.1
Deregistration request ............................................................................................... 16
4.2
Assess urgency........................................................................................................... 17
4.3
Disable user account .................................................................................................. 17
4.4
Retrieve authentication token .................................................................................... 17
4.5
Inactive accounts ....................................................................................................... 17
5
Management of privileged access rights ............................................................................. 18
6
Access reviews ................................................................................................................... 19 6.1
Define scope .............................................................................................................. 20
6.2
Inform system owner(s) ............................................................................................. 20
6.3
Create user access report ........................................................................................... 20
6.4
Send report to system owner(s) ................................................................................. 20
6.5
Review access and identify changes............................................................................ 20
6.6
Implement changes.................................................................................................... 21
Figures Figure 1: Process of user registration .......................................................................................... 10 Figure 2: Access adjustment process ........................................................................................... 13 Figure 3: User deregistration process .......................................................................................... 16 Figure 4: Access review process .................................................................................................. 19
Version 1
Page 7 of 21
[Insert date]
User Access Management Process [Insert classification]
1 Introduction The creation of new user accounts and the on-going management of system access are fundamental to the provision of effective information security. This process describes how user accounts and access rights should be requested, approved, created, amended, reviewed and removed in a secure way which complies with [Organization Name] policies. This control applies to all systems, people and processes that constitute the organization’s information systems, including board members, directors, employees, suppliers and other third parties who have access to [Organization Name] systems. The following policies and procedures are relevant to this document: • • • •
Access Control Policy Mobile Device Policy Remote Working Policy Password Policy
Version 1
Page 8 of 21
[Insert date]
User Access Management Process [Insert classification]
2 User registration This process must be followed for all user creations, including those of users within the IT function. [Organization Name] maintains and supports a wide variety of IT systems and the level of access required by individuals to these systems in order to perform their job role will vary widely across the organization. Although the specifics of how users are created will also vary across systems, the following basic process should always be followed. The process of user registration is shown in the diagram on the next page:
Version 1
Page 9 of 21
[Insert date]
User Access Management Process [Insert classification]
Figure 1: Process of user registration
Version 1
Page 10 of 21
[Insert date]
User Access Management Process [Insert classification] This process is described in more detail in the remainder of this section, including provision for the segregation of duties in line with [Organization Name] information security policy.
2.1 Requesting access 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.2 Access approval or rejection 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.3 User account creation Once an approved request with sufficient details has been received, the [IT Service Desk] will manage the creation of the user account. This account is unique to the user and ‘recycled’ from any other staff member. The creation of the account 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
Version 1
Page 11 of 21
[Insert date]
User Access Management Process [Insert classification] 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.
2.4 Allocation of secret authentication information The [IT Service Desk] will set an initial password. This will be a strong password created in accordance with the Password Policy. 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 according to the Password Policy. If additional authentication tools are to be used (such as a two-factor authentication method) the appropriate procedure for the setup of these items should be followed.
2.5 User access rights assignment Once the user account has been created, the request should be forwarded 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. For a breakdown of rights/privileges per role within the organization, refer to the Access Control Policy.
2.6 Informing the user 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 a hardware 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.
Version 1
Page 12 of 21
[Insert date]
User Access Management Process [Insert classification]
3 User access adjustment 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 Access Control Policy are maintained. The process for user access adjustment is shown below:
Figure 2: Access adjustment process
Version 1
Page 13 of 21
[Insert date]
User Access Management Process [Insert classification]
3.1 User access adjustment request Requests for adjustments to user access to IT systems should be sent to 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 Date adjustment required from
If any of the above items of information are changing (e.g. a move of role or department) then both old and new details should be given). For each system to which access is requested to be amended, further information may be required such as: • • •
Name of an existing user whose access should be duplicated (if amended user will be performing the same or similar role) Modules required Payroll or employee number
Where possible, requests for adjustments to access rights 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.
3.2 Access approval or rejection All requests for adjustments to access rights 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 access rights should be amended 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.
3.3 Adjust access rights 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.
Version 1
Page 14 of 21
[Insert date]
User Access Management Process [Insert classification]
3.4 Informing the user Upon successful completion of the adjustment request the [IT Service Desk] will inform the user via email. If a hardware 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.
Version 1
Page 15 of 21
[Insert date]
User Access Management Process [Insert classification]
4 User deregistration When an employee or contractor leaves the organization, it is vital that access controls are updated promptly to avoid a situation where an unauthorised person retains access to our systems. This will be achieved using the process below:
Figure 3: User deregistration process
4.1 Deregistration request 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
Version 1
Page 16 of 21
[Insert date]
User Access Management Process [Insert classification] 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.
4.2 Assess urgency 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.
4.3 Disable user account 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 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.
4.4 Retrieve authentication token If the deregistered user has a hardware authentication token this should be retrieved as part of the termination process and returned to the [IT Service Desk].
4.5 Inactive accounts If a user account is inactive for a period of 90 days or more, the account will be disabled as per the deregistration process immediately.
Version 1
Page 17 of 21
[Insert date]
User Access Management Process [Insert classification]
5 Management of privileged access rights 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, 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.
Version 1
Page 18 of 21
[Insert date]
User Access Management Process [Insert classification]
6 Access reviews In order to ensure that access to IT systems is only available to authorised personnel, [Organization Name] will carry out a user access review every six months.
Figure 4: Access review process
Version 1
Page 19 of 21
[Insert date]
User Access Management Process [Insert classification]
6.1 Define scope The scope of the review should be defined in terms of the systems and networks that will be covered.
6.2 Inform system owner(s) 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.
6.3 Create user access report The IT Department will create a listing of all 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.
6.4 Send report to system owner(s) 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.
6.5 Review access and identify changes The list will be reviewed by the system owner and any accounts that should not be maintained will be identified. If 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)
Version 1
Page 20 of 21
[Insert date]
User Access Management Process [Insert classification] • • • •
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.
6.6 Implement changes Actions identified 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.
Version 1
Page 21 of 21
[Insert date]
