News Own Your Online External Link Report it
News Own Your Online External Link
  1. Welcome to the National Cyber Security Centre
  2. Protect your organisation
  3. Critical Controls
  4. Principle of least privilege

Principle of least privilege

This control helps organisations to know what access staff have to each network or system, and ensures they only have the access they need to do their jobs. This mitigates the opportunity for vulnerabilities to be exploited.

What is principle of least privilege?

The principle of least privilege means giving people only the access they need to do their job.  This limits the number of things an attacker can do if a user account is compromised.

Many security problems such as credential harvesting and unauthorised access happen when people have more administrative permissions than they need. Getting access to an account with a lot of permissions is great for attackers as they have more access to data and systems. This makes it easier to get more information and easier to go undetected.

These attacks can be mitigated by implementing role-based access control which means:

  • permissions can be assigned to a role, 
  • user accounts can have more than one role assigned, and
  • people can have more than one user account.
     
    For example, if someone needs administrative access, we recommend giving them an administrative user account for those tasks and a second user account with lesser privileges for everyday use. 

Different systems allow differing levels of controls or may use different terms. Check your system documentation for how your system works.

You can also consider implementing just-in-time (JIT) access to mitigate the risk of privileged account access. Using JIT access can help organisations provision access so that users only have access to privileged accounts and resources for a specific timeframe.

How to implement principle of least privilege

Only provide the level of access needed to do a job.

Here are some steps to consider when following this principle.

Decide which permissions users need

You first need to understand what type of access user accounts need. What permissions and system access do each person need to do their job? Look at how staff do their jobs and what tasks they need to do.

Review all system access including:

  • the front-end applications used by your staff, and 
  • the infrastructure that your network and system administrators’ access.
  • Be sure to include user, system, and service accounts in this review.

To understand what permissions and system access an account needs, ask the user or the system owner. Justify any administrative access with an action that they need to take and record that justification. This list could be used later to perform a review. 

For example, a system account might need view permissions to do its job. Giving administrative access is easier because it would have all the permissions they need. But the access is not justified and so shouldn't be given.

When in doubt of what permissions a user needs, give less access and test it. You can grant more permissions later if they don't have access to do specific actions.

Assess system roles and their permissions

Next review the permissions assigned to each role within each of your systems. You'll need to look at how permissions or roles are configured within the system.

Make sure you understand how a role has been set up and which users are assigned that role. This will help you to review if a user has the appropriate, minimum level of permissions for their job.

Review permissions currently provided

Once you understand what access or roles your users need, review the access that is currently given. When reviewing access, you should:

  • check the role(s) configuration. Check to make sure the role(s) only allow the permissions needed to do those tasks,
  • check user access. Compare the roles and permissions a user has with the access they need for their job. Check to make sure they only have the roles and permissions they need to do their job, and
  • check admin access. Check that anyone with administrative permissions has separate user accounts. This is so they only use the account with administrative access when they need to use it. This reduces the risk that the user mistakenly carries out a sensitive action. It also reduces the access an attacker would have if the account was compromised.

Monitor access

Assigned access needs to be reviewed and monitored over time. A regular review of accounts and roles can help you catch any irregularities. Review the permissions of administrative accounts more often, given the sensitivity of their access.

Enable logging of actions taken by accounts with administrative permissions. Send the logs to a centralised logging server for analysis and alerting. Configure rules to send notifications when unexpected actions happen, such as changes during unusual times of the day.

How to measure success

Implementing this control requires you to look at your:

  • systems
  • access methods, and
  • permissions.

The goals for your organisation are to understand access in your environment and to have operational processes in place as detailed below.

High level understanding

Your organisation understands:

  • the minimum level of permissions needed for all jobs within your organisation, and
  • the permissions that are assigned to roles within each system. This will allow you to know if a user with that role has the right permissions for their job.

You or your team has a complete view of:

  • the permissions and roles that every user has for each system, and
  • the systems in your environment and how users access them, either through a front-end application or through the back-end infrastructure. This includes user accounts that your staff use, and system and service accounts that are not regularly accessed by staff.

Operational processes

Your organisation has a method or a process to:

  • identify the permissions a user needs before you give or change any access,
  • review users to make sure they keep the smallest level of permissions needed for their job,
  • identify when a change has happened that may need changes to the permissions, roles, or users in a system,
  • remove user permissions or access that are no longer needed,
  • assign separate accounts to users who need administrative or sensitive permissions. One account has the administrative permissions, and the other has lesser permissions for other aspects of their job, and
  • log actions taken by administrative users and send the logs to a central location. Configure them to send an alert to feed into your incident or change management processes.

Key takeaways

  • If you’re unsure which permissions a user account needs, give less access. If they can’t do an aspect of their job, they can ask for extra permissions. Update any documents you have, to keep track of what permissions a job needs and why.
  • Sometimes it’s challenging to understand what level of access a system account needs. When in doubt, assign a lower level of access and test it. If the service or system account requires administrative permissions, make sure you understand what those permissions are used for and document any changes.
  • Avoid copying access from one user account to another without reviewing it. The copied account might have additional permissions that aren’t necessary for the new person.
  • Be critical of giving out administrative access. It’s OK to ask these users why they may need those permissions and what tasks they need to perform. Instead of giving your CIO administrator access to keep an eye on things, configure alerts and reports so they can monitor use of administrative actions.
  • Log and analyse all administrative actions to identify any suspicious or abnormal behaviour.
  • Take an additional step to protect your user accounts and make sure all internet-facing and administrative services are also protected with multi-factor authentication (MFA).