4.2.1 User registration and de-registration  

A formal user registration and de-registration process should be implemented to enable assignment of access rights.  

• Require using unique user IDs to enable users to be linked to and held responsible for their actions. The use of shared IDs should only be permitted where they are necessary for business or operational reasons and should be approved and documented.
• Immediately disable or remove user IDs of users who have left the organization.
• Ensure that redundant user IDs are not issued to other users.

See also CIS Control 5 Account Management and CIS Control 6 Access Control Management.

4.2.2 User access provisioning

A formal user access provisioning process should be implemented to assign or revoke access rights for all user types to all systems and services.

• For assigning or revoking access rights granted to user IDs, obtain authorization from the owner of the information system or service for the use of the information system or service. Separate approval for access rights from management may also be appropriate.
• Verify that the level of access granted are appropriate to the access policies.
• Ensure that access rights are not activated before authorization procedures are completed.
• Maintain a central record of access rights granted to a user ID to access information systems and services.
• Adapt access rights of users who have changed roles or jobs. Immediately remove or block access rights of users who have left the organization.
• Periodically review access rights with owners of the information systems or services.

4.2.3 Management of privileged access rights   

The allocation and use of privileged access rights should be restricted and controlled.

• Identify the privileged access rights associated with each system or process, e.g. operating system, database management system and each application.
• Allocate privileged access rights to users on a need-to-use basis and on an event-by-event basis, i.e. based on the minimum requirement for their functional roles.
• Maintain an authorization process and a record of all privileges allocated. Privileged access rights should not be granted until the authorization process is complete.
• Define requirements for expiry of privileged access rights.
• Assign privileged access rights to a user ID different from those used for regular business activities. Regular business activities should not be performed from privileged ID.
• For generic administration user IDs, maintain the confidentiality of secret authentication information when shared (e.g. changing passwords frequently and as soon as possible when a privileged user leaves or changes job, communicating them among privileged users with appropriate mechanisms).

4.2.4 Management of secret authentication information of users

The allocation of secret authentication information should be controlled through a formal management process.  

• Require users to sign a statement to keep personal secret authentication information confidential and to keep group (i.e. shared) secret authentication information solely within the members of the group.
• When users are required to maintain their own secret authentication information, they should be provided initially with secure temporary secret authentication information, which they are forced to change on first use.
• Establish procedures to verify the identity of a user prior to providing new, replacement or temporary secret authentication information.
• Give temporary secret authentication information to users in a secure manner.
• Users should acknowledge receipt of secret authentication information.
• Alter default vendor secret authentication information following the installation of systems or software.

4.2.5 Review of user access rights   

Asset owners should review users’ access rights at regular intervals.

• Review users’ access rights at regular intervals and after any changes, such as promotion, demotion or termination of employment.
• Review user access rights and re-allocated when moving from one role to another within the same organization.
• Authorizations for privileged access rights should be reviewed at more frequent intervals.
• Check privilege allocations at regular intervals to ensure that unauthorized privileges have not been obtained. Log changes to privileged accounts for periodic review.

4.2.6 Removal or adjustment of access rights   

The access rights of all employees and external party users to information and information processing facilities should be removed upon termination of their employment, contract or agreement, or adjusted upon change.

• Remove or suspend the access rights of an individual to information and assets associated with information processing facilities and services upon termination.
• Reflect the changes of employment in removal of all access rights that were not approved for the new employment.
• Make sure that the removal or adjustment of access rights include those of physical and logical access.

4.3.1 Use of secret authentication information   

Users should be required to follow the organization’s practices in the use of secret authentication information.  

• Advise all users to: 
  a) keep secret authentication information confidential, ensuring that it is not divulged to any other parties, including people of authority;
  b) avoid keeping a record (e.g. on paper, software file or hand-held device) of secret authentication information, unless the method of storing has been approved (e.g. password vault);
  c) change secret authentication information whenever there is any indication of its possible compromise;
  d) when passwords are used as secret authentication information, select quality passwords with sufficient minimum length which are easy to remember, not vulnerable to dictionary or person related information attacks;
  e) change temporary passwords at the first log-on;
  f) use different secret authentication information for business and non-business purposes.

4.4.1 Information access restriction   

Access to information and application system functions should be restricted in accordance with the access control policy.  

• Create the access restrictions based on individual business application requirements and in accordance with the defined access control policy. 
• Consider the following in order to support access restriction requirements:
  a) providing menus to control access to application system functions;  
  b) controlling which data can be accessed by a particular user;  
  c) controlling the access rights of users, e.g. read, write, delete and execute;  
  d) controlling the access rights of other applications;  
  e) limiting the information contained in outputs.

4.4.2 Secure log-on procedures   

Where required by the access control policy, access to systems and applications should be controlled by a secure log-on procedure.

• Choose a suitable authentication technique to substantiate the claimed identity of a user. Where strong authentication and identity verification is required, use authentication methods alternative to passwords, such as cryptographic means, smart cards, tokens or biometric means. ·
• Design the procedure for logging into a system or application to minimize the opportunity for unauthorized access. A good log-on procedure should:
  a) not display system or application identifiers until the log-on process has been successfully completed;
  b) display a general notice warning that the computer should only be accessed by authorized users;
  c) not provide help messages during the log-on procedure that would aid an unauthorized user;
  d) validate the log-on information only on completion of all input data. If an error condition arises, the system should not indicate which part of the data is correct or incorrect;
  e) protect against brute force log-on attempts;
  f) log unsuccessful and successful attempts;
  g) raise a security event if a potential attempted or successful breach of log-on controls is detected;
  h) after a successful log-on, display the date and time of the previous successful log-on and details of any unsuccessful log-on attempts;
  i) not display a password being entered;
  j) not transmit passwords in clear text over a network.

4.4.3 Password management system   

Password management systems should be interactive and should ensure quality passwords.

• Enforce the use of individual user IDs and passwords to maintain accountability. ·
• Allow users to select and change their own passwords and include a confirmation procedure for input errors.
• Enforce a choice of quality passwords and force users to change their passwords at the first log-on.
• Enforce regular password changes and as needed.
• Maintain a record of previously used passwords and prevent re-use.
• Do not display passwords on the screen when being entered.
• Store password files in protected form and separately from application system data.

4.4.4 Access control to program source code   

Access to program source code should be restricted.

• Control access to program source code and associated items (such as designs, specifications, verification plans and validation plans) in order to prevent the introduction of unauthorized functionality and to avoid unintentional changes. For program source code, this can be achieved by controlled central storage of such code, preferably in program source libraries.
• Consider the following guidelines to control access to such program source libraries in order to reduce the potential for corruption of computer programs:
  a) where possible, do not hold program source libraries in operational systems;
  b) support personnel should not have unrestricted access to program source libraries;
  c) perform the updating of program source libraries and associated items and the issuing of program sources to programmers only after appropriate authorization has been received;
  d) hold the program listings in a secure environment;
  e) maintain an audit log of all accesses to program source libraries.