CSF-DOC-PRAA-2 User Access Management Process

User Access Management Process

NIST CSF 2.0 Toolkit: Version 1 ©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 framework addressed The following areas of the Cybersecurity Framework are addressed by this document: •

Protect (PR) o Identity Management, Authentication, and Access Control (PR.AA) ▪ PR.AA-01 ▪ PR.AA-02 ▪ PR.AA-05

General guidance This is an important area that needs adequate consideration as any lack of rigor will invalidate many of your other information security controls. Ensure that appropriate authorization procedures are established to protect your ICT 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.

Version 1

Page 2 of 21

[Insert date]

User Access Management Process [Insert classification]

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.

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.

Version 1

Page 3 of 21

[Insert date]

User Access Management Process [Insert classification]

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 4 of 21

[Insert date]

User Access Management Process [Insert classification]

User Access Management Process

Version 1

DOCUMENT CLASSIFICATION

[Insert classification]

DOCUMENT REF

CSF-DOC-PRAA-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 .........................................................................................................10

2.2

Access approval or rejection .........................................................................................10

2.3

User account creation ...................................................................................................11

2.4

Allocation of secret authentication information ...........................................................11

2.5

User access rights assignment.......................................................................................11

2.6

Informing the user ........................................................................................................11

User access adjustment ............................................................................................ 13 3.1

User access adjustment request ...................................................................................13

3.2

Access approval or rejection .........................................................................................14

3.3

Adjust access rights ......................................................................................................14

3.4

Informing the user ........................................................................................................14

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

5

Management of privileged access rights ................................................................... 18

6

Access reviews .......................................................................................................... 19 6.1

Define scope .................................................................................................................20

6.2

Inform asset owner(s)...................................................................................................20

6.3

Create user access report..............................................................................................20

6.4

Send report to asset owner(s) .......................................................................................20

6.5

Review access and identify changes ..............................................................................21

6.6

Implement changes ......................................................................................................21

Figures Figure 1: Process of user registration ............................................................................................. 9 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

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 [IT Department]. [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 below.

Figure 1: Process of user registration

Version 1

Page 9 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 asset owner for the relevant system(s). This will normally be a manager within the organization with specific responsibility for the security and use of that system. In some circumstances the asset 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 asset owner if required.

Version 1

Page 10 of 21

[Insert date]

User Access Management Process [Insert classification]

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 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 permissions, 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.

2.4 Allocation of secret authentication information 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 a multifactor 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.

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 an out of channel means (for example by phone) 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 post or trusted external courier. For external distribution methods, a recorded delivery

Version 1

Page 11 of 21

[Insert date]

User Access Management Process [Insert classification] 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

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

Version 1

Page 13 of 21

[Insert date]

User Access Management Process [Insert classification] If any of the above items of information are changing (for example 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 asset 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 asset must be approved by the asset 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 asset 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 asset 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.

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, this will be sent to the user by internal post or trusted external courier. For external distribution methods, a recorded delivery

Version 1

Page 14 of 21

[Insert date]

User Access Management Process [Insert classification] 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 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 unauthorized 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 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 immediately.

Version 1

Page 16 of 21

[Insert date]

User Access Management Process [Insert classification]

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 asset 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, for example if the user is in the finance team, 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, for example 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].

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, domain administrator or cloud 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 asset 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 (for example 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 (for example 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, or temporary security credentials (for example using the AWS Security Token Service) should be configured.

When creating such accounts, it should be emphasized 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 authorized personnel, the [IT Department] 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, resources and networks (including cloud infrastructure and services) that will be covered.

6.2 Inform asset owner(s) The owners of the systems, resources 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 all of the authorized users of each system or set of resources together with their current level of access. This should as a minimum state the following information: • • • • • • • • •

Name of system or resource set User name User role title User department User account name Date of user account creation User role(s) assigned Additional access rights assigned 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 asset owner(s) The report should be produced in electronic form (either spreadsheet or document) and securely emailed to the asset owner. In some circumstances it may be appropriate to encrypt the file containing the report, for example if it is to be sent to a remote office via email.

Version 1

Page 20 of 21

[Insert date]

User Access Management Process [Insert classification]

6.5 Review access and identify changes The list will be reviewed by the asset 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.

Asset 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 asset 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 prioritized and carried out according to their urgency. Non-urgent issues may be added to the continual improvement plan as part of a wider program of improvement. A record should be kept of all actions taken.

Version 1

Page 21 of 21

[Insert date]