DATA SECURITY KNOWLEDGE BASE

The principle of least privilege is the idea that at any user, program, or process should have only the bare minimum privileges necessary to perform its function. For example, a user account created for pulling records from a database doesn’t need admin rights, while a programmer whose main function is updating lines of legacy code doesn’t need access to financial records. The principle of least privilege can also be referred to as the principle of minimal privilege (POMP) or the principle of least authority (POLA). Following the principle of least privilege is considered a best practice in information security.

How the Principle of Least Privilege Works

The principle of least privilege works by allowing only enough access to perform the required job. In an IT environment, adhering to the principle of least privilege reduces the risk of attackers gaining access to critical systems or sensitive data by compromising a low-level user account, device, or application. Implementing the POLP helps contain compromises to their area of origin, stopping them from spreading to the system at large.

Examples of the Principle of Least Privilege

The principle of least privilege can be applied to every level of a system. It applies to end users, systems, processes, networks, databases, applications, and every other facet of an IT environment. Below are just a few examples of how the principle can work (or fail) in practice.

• User Account with Least Privilege: With the principle of least privilege, an employee whose job is to enter info into a database only needs the ability to add records to that database. If malware infects that employee’s computer or if the employee clicks a link in a phishing email, the malicious attack is limited to making database entries. If that employee has root access privileges, however, the infection can spread system-wide.
• MySQL Accounts with Least Privilege: A MySQL setup follows the principle of least privilege when it employs several different accounts to perform unique tasks. Ideally, an online form that lets users sort data should use a MySQL account that only has sorting privileges. That way, an attacker who exploits the form has only gained the power to sort records. Conversely, if the account is given the power to delete records, the attacker can now wipe out the entire database.
• Using Just in Time Least Privilege: A user who only rarely needs root privileges should work with reduced privileges the rest of the time. To increase traceability, that user can retrieve root access credentials from a password vault as needed. Using disposable credentials tightens the security achieved by just in time least privilege.

Benefits of the Principle of Least Privilege

There are many benefits of implementing the principle of least privilege:

• Better security: Edward Snowden was able to leak millions of NSA files because he had admin privileges, though his highest-level task was creating database backups. Since the Snowden leaks, the NSA has employed the principle of least privilege to revoke higher-level powers from 90% of its employees.
• Minimized attack surface: Hackers gained access to 70 million Target customer accounts through an HVAC contractor who had permission to upload executables. By failing to follow the principle of least privilege, Target had created a very broad attack surface.
• Limited malware propagation: Malware that infects a system bolstered by the principle of least privilege is often contained to the small section where it entered first.
• Better stability: Beyond security, the principle of least privilege also bolsters system stability by limiting the effects of changes to the zone in which they’re made.
• Improved audit readiness: The scope of an audit can be reduced dramatically when the system being audited is built on the principle of least privilege. What’s more, many common regulations call for POLP implementation as a compliance requirement.

Best Practices for the Principle of Least Privilege (How to Implement POLP)

1. Conduct a privilege audit. Check all existing accounts, processes, and programs to ensure that they only have the permissions required to do the job.
2. Start all accounts with least privilege. The default for all new account privileges should be set as low as possible. Only add specific higher-level powers as needed to perform the job.
3. Enforce the separation of privileges. Separate admin accounts from standard accounts, and higher level system functions from lower ones.
4. Use just in time privileges. Wherever possible, restrict raised privileges only to moments when they are needed. Implement on expiring privileges and one-time-use credentials.
5. Make individual actions traceable. User IDs, one-time passwords, monitoring, and automatic auditing can make it easier to track and limit damage.
6. Make it regular. Auditing privileges regularly prevents a situation where older users, accounts, and processes accumulate privileges over time, whether they still need those things or not.