The principle of least privilege (POLP) requires giving each user, service and application only the permissions needed to perform their work and no more. It is one of the most important concepts in network and system security. No matter how technically skilled or trustworthy a user is, they should have access to only the network resources they need to do the job at hand.
The main benefit of minimizing each user’s level of access is that you can dramatically reduce your security risks and attack surface. By strictly limiting who can access your critical systems, you reduce the risk of unintentional or malicious changes and data leaks — whether by the users themselves or by attackers who take over their credentials. In particular, you’ll minimize the likelihood of rootkits, viruses and malware being installed, since most user accounts won’t have the administrative privileges required to install them.
Another benefit of enforcing least privilege is achieving regulatory compliance. Many standards require organizations to give users only the privileges needed to complete their job functions — especially privileged users. Even if your business is not subject to these regulations, implementation of least privilege is a smart best practice.
In addition, a least privilege model simplifies change and configuration management. Every time someone with administrative privileges logs in to a computer, there's the potential that the system's configuration could be changed inappropriately, either deliberately or accidentally. Least privilege helps you maintain the intended configuration of a system by controlling exactly who can change what. Great examples of administrative restrictions that implement least privilege are the ESAE (“Red Forest”) model in Active Directory and the Just In Time and Just Enough administration concepts in Windows Server.
However, it’s essential to keep in mind that the principle of least privilege is just one layer of a comprehensive defense-in-depth strategy; you should also deploy other critical technologies, such as firewalls that prevent connections, intrusion detection devices that search for malicious code, antivirus or personal security products that look for heuristic behavior, and software restriction policies that limit what application installation and execution. For example, suppose a user has a legitimate need to access certain sensitive data. If keylogging software is installed on that user's machine, that data could be transmitted to a third party without the user's knowledge. The least privilege principle alone will not block this attack path, since the user needs the access rights, but a comprehensive defense-in-depth security strategy would almost certainly prevent the data breach.
To implement the principle of least privilege, you need to set up different types of account for different purposes. These include user accounts, privileged accounts and shared accounts:
Regardless of the type of account, credentials best practices recommend enforcing certain controls on passwords, including the following:
You can read more about passwords and their settings in password best practices.
You should also apply an account lockout policy, as detailed in account lockout best practices.
When someone leaves the company, for any reason, that user’s accounts should be disabled immediately, and then deleted after a period of time. If you delete the account immediately, you might not be able to access important data, and you might even lose some logs associated with the account. You can get more information in user termination best practices.
Trying to manage privileges individually for hundreds or thousands of employees and adhere to the principle of least privilege is a difficult task. A better access control strategy is to place users into groups based on their job roles and then to manage privileges for those groups. For example, suppose your company invests in a new HR application. Instead of having to grant each HR staff member access to the application individually — a time-consuming and error-prone task — you simply give the HR group the appropriate permissions. Similarly, if a user transfers from one department to another, you can simply remove them from certain groups and add them to others, rather than having to manually remove dozens or hundreds of specific access rights and add a similar number of new ones.
Assigning User Working Hours
For employees who work a relatively consistent schedule, another layer of least privilege is to restrict the use of accounts to the individual’s normal working hours. For example, if a given employee generally works from 8 a.m. to 5 p.m., their account should not be usable at 1 a.m. Of course, people fluctuate a bit, so you might want to set up this hypothetical account to be operational from 7 a.m. to 7 p.m.
Using Location-based Restrictions
In many cases, you can also limit which locations an account can be used from. For instance, an account might work fine in the San Francisco office but not work at all from the Los Angeles office.
Using Machine-based Restrictions
Machine-based restrictions are a special type of location-based controls. For instance, you can keep a user who works in the Accounting department on the 4th floor from using machines on the 10th-floor software development area. Again, not all accounts can be locked down like this; for example, some technical support personnel might need to be able to work from almost any computer on the network.
Each system should also be configured so that it is capable of doing only what it is intended to do and no more. Best practices for locking down systems including changing all default passwords and disabling any default accounts and services you don’t use. After all, a simple Google search is all it takes to find the default username and password for any system but changing those credentials is an easy task, and simply shutting down anything that you don’t need will go quite a long way to improving computer security. It is amazing how often real-world system audits turn up systems with default usernames and passwords — even backbone gateway routers or storages with sensitive data that should be password protected and have multifactor authentication implemented.
Setting up the right accounts, assigning them the appropriate privileges and applying any applicable restrictions is a good first step. However, you also need to audit those accounts periodically. Tree types of audits are relevant to accounts: usage audits, privilege audits and change audits.
Usage, privilege and change auditing can be automated by third-party tools like Netwrix Auditor, which will report on all changes in your environment and alert you about changes you deem critical, such as changes to administrative group membership.
Applying the principle of least privilege is hard, even for organizations with high incentives to be secure. It requires constant testing of security boundaries and the monitoring of privileged access. But the benefits are huge: It will help you defend against external attacks and insider threats, comply with regulatory requirements, and simplify change and configuration management.