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 Vertic Pty Ltd policies.
This control applies to all systems, people and processes that constitute the organisation’s information systems, including board members, directors, employees, suppliers and other third parties who have access to Vertic Pty Ltd systems.
The following policies and procedures are relevant to this document:
Access Control Policy
Mobile Device Policy
User registration
This process must be followed for all user creations, including those of users within IT Department. Vertic Pty Ltd 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
This process is described in more detail in the remainder of this section, including provision for the segregation of duties in line with Vertic Pty Ltd information security policy.
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.
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. If 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.
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.
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.
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.
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 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.
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
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 (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.
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. If 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.
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.
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 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.
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
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.
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.
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.
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.
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 should be configured, using Salesforce’s user security and permissions model.
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.
Access reviews
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 six months.
Figure 4: Access review process
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.
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.
Create user access report
The IT Department will create a listing all the authorised 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.
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.
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 organisation’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.
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.