Access Management Simplified: Privileged Rights and Authentication Controls A.8.02 – A.8.05

A.8.02 Privileged access rights

Privileged access rights are access rights provided to an identity, a role or a process that allows the performance of activities that typical users or processes cannot perform. The most common example of this is the system administrator roles which typically require privileged access rights.

This control aims to ensure that only authorised users, software components and services are provided with privileged access rights.

In conjunction with control A.5.15 on access rights, the granting of privileged rights should be controlled through an authorisation process where the rights are requested and approved before being granted. They should also be reviewed periodically. Role-based and user-based access rights within systems should be handled the same way. 

When determining which users and accounts have privileged access rights, don’t forget to include any administration accounts or other accounts which may be used for automated tasks, for example application user accounts.
All actions performed by users with privileged access rights should be logged for audit purposes. This can be done as part of the controls implemented as part of A.8.15 - Logging.
 

A.8.03 Information access restriction

This control aims to ensure that only authorised users and accounts have access to information and assets and to prevent unauthorised access.

This starts with determining who needs access to the information, which can in part be assessed through information classification. On top of this, also consider who needs access to the information, and only grant it based on the least privilege.

Things to think about when implementing this control are:

• Ensuring that users need to be authenticated and have appropriate authorisation such as group membership before allowing access to secure information and locations where it is stored. You should think about how you can restrict any sensitive data such as PII within applications. Does the application provide the ability to hide information based on the user’s privileges? If so, then make use of it!
• This should include configuring access to these secure locations to control access including ability to read, write, delete, and execute to only the required identities or groups.
• Access controls for the isolation of sensitive applications, application data or systems. Only allow access to systems and information within them to people who need to use the system.

A.8.04 - Access to source code

This control aims to prevent the introduction of unauthorised functionality, avoid unintentional or malicious changes and to maintain confidentiality of your source code to your software which is valuable intellectual property.

This control expands on the information access restriction control in A.8.03 and specifically refers to securing access to any source code and associated tools that is produced as part of your business. This includes documentation such as software designs, specifications, testing and validation plans as well as tools used within the SDLC such as compilers, builders, integration tools, test environments and platforms.

This control can be achieved by ensuring that your central repository for source code is controlled using a source code management system. This should include establishing a procedure to manage access to source code and libraries where access is granted based on business needs. The procedure should outline change control procedures, which are further outlined in control A.8.32, and only performing changes after appropriate authorization has been received. 

In addition, direct access to change the source code should not be granted to developers, but changes should only be permitted through authorised tools which can be configured to ensure changes have proceeded through the change control procedure.

As with most other change control procedures, audit logs should be kept to ensure traceability of changes to the source code.
 

A.8.05 Secure authentication

This control is to ensure that users are securely authenticated when gaining access to systems and applications. 

The strength of authentication required to access information should be appropriate for the classification of the information. So, stronger authentication should be required for more sensitive data and systems.
When strong authentication or identity verification is required, MFA (Multi-factor authentication) should be used. Multi-factor authentication involves the use of additional factors, such as asking for additional information you know, or using additional devices such as sending an SMS to a mobile phone, or using an authenticator app, such as Google Authenticator which is more secure. 

As part of the MFA controls, you may wish to consider requiring additional authentication before authorising certain actions or accessing data within an application. An example of this is seen in banking applications requiring you to enter a code from an authenticator app, or one sent via SMS before you transfer money, even after you have accessed the app.

When designing a procedure for logging in to a system, it should focus on minimising the risk of unauthorised access. The following points should be considered:

• Passwords or other sensitive information should not be displayed in clear text on the screen, not transmitted over a network in clear text format.
• Any error messages should not give malicious users information on which data may be correct. For example, displaying that a user’s password is incorrect gives a malicious user the indication that the username was correct.
• Preventing brute force attempts to gain access to the system by locking an account after a certain number of unsuccessful login attempts reset.
• Logging all attempts, both successful and unsuccessful, including raising security alerts if a potential login control breach is detected. For example, if a user enters wrong password information more than a certain number of attempts, of if there are DDoS attempts being made through automated tools attempting to login.
• Restricting connection times for high-risk applications to reduce the window of opportunity for unauthorised access.
• Inactive sessions should be securely logged out after inactivity, especially if systems are being accessed from outside the network or on users’ devices.

Other Posts

• Other posts in the series can be found at: A Strategic Approach to ISO 27001 Implementation
• View the previous post in the series: Strengthening User Device Security with Control A.8.01