Defining the Principle of Least Privilege (POLP)
The Principle of Least Privilege, or POLP, is the idea that any user, program, or even process should only be provided the bare minimum of privilege for them to perform their function. For example, a new user created for the purpose of pulling records from a database may not need administrative privileges, while a programmer who updates lines of legacy code does not need access to financial records. The main principle of POLP is also known as the Principle of Least Authority, or POLA, and the Principle of Minimal Privilege, or POMP.
Following POLP is considered best practice for information security.
How It Works
The POLP works by granting just enough access to perform a specific task. Within an IT environment, this reduces the risk of malicious attacks gaining access to critical systems, as well as sensitive data, due to a low-level account user, a single device, or an application being compromised. By implementing the Principle of Least Privilege, this contains the compromise to the area of origin, which stops it from spreading.
Examples of Principle of Least Privilege (POLP)
The Principle of Least Privilege is applicable on every level of a system, including end users, devices, processes, networks, applications, systems, and all other facets of the IT environment. Here are examples of how POLP can work in practice.
User Accounts With POLP
An employee who’s tasked to enter information into a database requires access to the specific database. If a malware is able to infect this employee’s device, the infection would be limited to this database because that employee does not have access to other databases or systems.
MySQL Account With POLP
A MySQL account can use POLP by employing several different accounts to do a unique task. An online form that allows users to sort data should only use an account with sorting privileges. This way, if an attacker gains access, they are only granted one specific privilege. However, if that account has the ability to delete records, for example, the attacker would be able to wipe out the entire database.
“Just in Time” Least Privilege
A user who rarely needs root privileges should only be granted such freedom when working on a specific task. Otherwise, those privileges should be pulled. Disposable credentials are a great way to implement POLP and increase security.
POLP was established for enhanced security and so carries many benefits.
- Enhanced Security – Edward Snowden was able to access and take millions of NSA files because he had administrator privileges even though his task was simply to create backups. Ever since, the NSA has implemented POLP.
- Limit Malware Attacks – If a system or device is infected by malware, POLP is able to contain it to the original infection and prevent it from spreading throughout the network.
- Improve Audits – The scope of an audit will dramatically reduce when POLP is in effect. On top of that, several regulations actually require companies to abide by this principle.
- Improved Stability – The Principle of Least Privilege increases the system stability by limiting the effects of changes.
POLP Best Practices
- Do a privilege audit – Check all current accounts, programs, and processes to see if they have the right privileges or too much.
- Create accounts with least privilege – By default, new user accounts created should have the least possible privilege set and higher ones to be set later on.
- Separate privileges – There should be separate administrative accounts from standard ones and higher accounts from low-level system functions.
- Use “just in time” privilege – When possible, you should restrict raised privileges in moments of need only.
- Trace individual actions – Automatic auditing can simplify tracking and mitigation of damage.
- Regularize – In the practice of POLP, privilege audits should be done regularly to prevent old user accounts and processes from accumulating privileges they do not need.
Julia Sowells960 Posts
Julia Sowells has been a technology and security professional. For a decade of experience in technology, she has worked on dozens of large-scale enterprise security projects, and even writing technical articles and has worked as a technical editor for Rural Press Magazine. She now lives and works in New York, where she maintains her own consulting firm with her role as security consultant while continuing to write for Hacker Combat in her limited spare time.