In software security circles, the concept of ‘least privilege’ is well-known. The idea is that users and applications should only have access to privileges required to perform the job or function at hand. And, when possible, these rights should be revoked after a certain amount of time. Least privilege is similar to following a “need-to-know” policy.
The reason to adopt the least privilege approach is that superfluous rights can needlessly widen a company’s attack surface. Software applications that dole away unnecessary permissions are at risk of over-permissive states and data overexposure. Without fine-grained authorization controls, hackers could leverage administrative privileges to perform an account takeover, exfiltrate sensitive information, execute malicious code, and perform other malicious operations.
Least privilege is a fundamental cybersecurity principle that’s been around for decades. But it’s worth revisiting nowadays — especially as companies move infrastructure to the cloud and cater to new remote working conditions, both of which beckon new policy types. Applying the rule of least privilege will also be pivotal to protecting user data privacy within new Web3 and Metaverse projects.
Understanding The Principle
So, what exactly is the principle of least privilege? Least privilege can be thought of as assigning access levels to meet the bare minimum to view or interact with software. It’s a computer programming principle that was first established in the 1970s.
“The principle of least privilege states that only the minimum access necessary to perform an operation should be granted, and that access should be granted only for the minimum amount of time necessary.” – Viega and McGraw, Guiding Principles for Software Security.
To put it in other words, “only the minimum necessary rights should be assigned to a subject that requests access to a resource,” explains the Cybersecurity & Infrastructure Security Agency (CISA). In a least privilege model, no superfluous rights are assumed, and the few rights that are granted are set to expire after the shortest duration possible.
For example, say a social media web application is supposed to only let you view your friends’ activity while logged in. And, since you’re not necessarily connected with friends of your friends, you don’t need access to their private activities as well. A system that did not use a least privilege approach might leave this activity open for anyone to view. This lack of authorization control would be a grave data privacy concern if it broke the terms of use.
Benefits of Least Privilege
If a subject does not require access to a resource, it’s good not to supply this access by default. As another example, suppose a healthcare application can read, overwrite, or append data to a patient profile. Giving complete authority to a healthcare practitioner to input or delete erroneous data may be required. However, by law, a patient would not be allowed the same privileges as they could potentially alter test results to fake an illness. On the other hand, a third-party application might append data taken daily from a sensor at home but doesn’t require the ability to read historical data to perform its function.
Keeping a least privilege security model that only supplies capabilities on a “need-to-know” basis for each entity ensures the integrity of the software system. It can also bring many other benefits:
- Least privilege reduces your overall attack surface. First and foremost, limiting the number of privileges you provide to a user reduces the number of possible attack vectors. Logically, if there are fewer open doors to attack a system, the total attack area is lessened.
- Least privilege decreases the risk of abuse. Perhaps your application has read and write capabilities, but not all users require both. Supplying administrative rights only to those with the proper credentials reduces the likelihood of an attacker using a sensitive action for a nefarious purpose.
- Least privilege decreases the risk of second-party abuse. Picture a real-world example where you let a friend borrow keys to your apartment while you’re away, but they accidentally lose them. They could then fall into the hands of the wrong person. Similarly, limiting the actions of a user lessons the risks involved if they accidentally expose their keys online.
- Least privilege reduces the occurrences of unwanted or accidental uses of privilege. A least privilege policy can avoid damage from well-intentioned users too. If users lack knowledge of a system, giving them powerful capabilities may be dangerous, as it could lead to data deletion or corruption. The same goes for infrastructure teams, too — engineers who aren’t accustomed to the nuances of a software deployment pipeline, for example, could cause harm if there are no guardrails in place.
- Least privilege can reduce operational overhead. Software requires a degree of flexibility for change. Further, following the rule of least privilege can reduce some of the burdens involved in auditing and change management. If fewer privileges are in use, it takes less time and energy to discover them and revoke them when they expire.
Implementing Least Privilege
The least privilege principle underpins many modern cybersecurity implementations. It’s also part and parcel of the ongoing zero-trust movement, which seeks to treat both internal and external actors with the same level of scrutiny. However, a least privilege policy could become an annoyance to professionals who just want to “get the job done” with less oversight. So, striking a balance between trust and access will be key.
One potential downside is the upfront effort it takes to design systems with least privilege in mind. Not all cloud service providers, for example, have secure-by-default settings. Vendors may supply out-of-the-box configuration templates for setting up role-based access control (RBAC), but it’s often on the application developers themselves to assign these roles and map them to their user types, as each business case is variable.
Least privilege requires implementing fine-grained access scopes, but for years in software development, there was no leading vendor-neutral standard method to do so. This led to many ad-hoc custom proprietary solutions. Nowadays, however, many companies are moving toward handling authorization with open standards like OAuth 2.0 and OpenID Connect. Systems that utilize these standards exchange encrypted JSON Web Tokens (JWTs) that delimit the scopes of the requesting party. Another standard gaining popularity is Open Policy Agent (OPA), used to set policies for administrators, like programmers or DevOps engineers, tasked with operating core cloud-native infrastructure.
Why is This Relevant Now?
The principle of least privilege is a storied tenant of software security, among the ranks of other principles such as secure design, defense in depth, securing the weakest link, and zero-trust. Though the least privilege concept has been around for decades, it still holds sway as a vital factor to consider when building permissions into software products. This is especially valid since, as of 2021, OWASP ranks Broken Access Control as the most common application vulnerability.
“The Principle of Least Privilege states that a subject should be given only those privileges needed for it to complete its task,” – Matt Bishop, Computer Security: Art and Science
Ensuring least privilege is quite relevant in the move to the cloud, where misconfigurations and insecure default settings plague many software deployments. It’s also a well-needed response to the nature of today’s distributed systems, wherein connectivity is crucial. Such software networks are often made accessible to a mixture of internal developers, end-users, third-party SaaS vendors, and external contractors. With so many hands in the pot, the potential for data security risks is at an all-time high. Thus, applying least privilege is a helpful method to reduce over-permissive conditions to curate who has access to what and for what reason.
Want more cybersecurity insights? Visit the Cybersecurity channel:
