All posts

Core Security Precept: Principle of Least Privilege

The word “rule” is overused; so, I went with “precept” — a rule or principle that defines how one should think or act.

Let’s start by assuming that eventually, everything will be compromised.

The Principle of Least Privilege (PoLP), which looks like it should be pronounced “polyp”, but would be a really unfortunate name, is a core concept in cybersecurity and access control. It means that users, processes, systems, and applications should be given only the minimum level of access necessary to perform their required tasks and nothing more. The PoLP is enshrined in a number of data privacy laws that further reenforces the idea that it should be done.

The PoLP states that a subject (user, process, system, application, etc) should only have the permissions needed to complete its assigned function, and those permissions should exist only for as long as necessary. This reduces the risk that accounts, systems, or applications can cause damage — whether accidentally or maliciously.

As a simple analogy, think of least privilege like giving someone keys to a building. Instead of giving every employee a master key that opens every door in the building, you give them access only to:

  • the office they work in
  • shared spaces they need
  • nothing else

This limits both accidents and abuse. This also provides a real world analogy that people can related to. Why would any less be done with information technology?

Applying least privilege helps protect systems in several ways:

  • Limits damage from compromise (if an attacker compromises an account with limited permissions, the attacker can only access limited resources).
  • Prevents accidental misuse (users cannot accidentally modify or delete systems they shouldn’t touch).
  • Reduces insider threat risk (even trusted users cannot access data outside their role).
  • Supports compliance (many regulatory frameworks require least-privilege controls, including GDPR, HIPAA, PCI-DSS).

Some examples include:

  • Operating Systems: Users operate with standard user accounts, not administrator accounts. Only administrators receive elevated access.
  • Cloud Environments: Cloud platforms enforce least privilege through role-based permissions. Ever tried to add the minimum AWS Permissions needed to get some feature to work? Often takes longer than the time needed to get the feature itself working.
  • Databases: Applications should only have permissions that are needed.

An organization can enforce least privilege using several mechanisms:

  • Role-Based Access Control (RBAC): Users are assigned roles with predefined permissions.
  • Just-In-Time (JIT) Privileges: Access can be granted temporarily when needed. Usually accomplished through some type of tooling (possibly, through a PAM solution) or a feature within a software product (or service) being used.
  • Privileged Access Management (PAM): Special tools (read, usually, expensive and complex) control high-risk accounts and log all actions.
  • Segmentation and Isolation: Systems are isolated so that access to one system does not automatically grant access to others (network segmentation, container isolation, environment isolation)

Many breaches occur because organizations violate the PoLP. Common failure points of the applying the PolP include:

  • Privilege creep (permissions accumulate over time). Yearly manager access attestations and clean user mover / leaver processes can address this.
  • Shared administrator accounts (can be compromised, how do you track down who did what?). Don’t use these.
  • Shared service accounts (can be compromised, how do you track down who did what?). Don’t use these.
  • Applications running as root/admin (applications can be compromised through vulnerability. Don’t do this.
  • Excessive database access (an account can be compromised). Don’t do this.
  • API keys with admin rights (these can be leaked). Avoid this. Can’t do it? Let’s reevaluate the application’s identity architecture.

Summary

The PoLP minimizes risk by ensuring that users, processes, systems, and applications operate with only the permissions they absolutely need, and only for the time they need them.

Notes:

  • AI / GenAI / ChatGPT / etc were not used to generate this article.
  • I used em dashes in my writing before the current GenAI wave was a thing. Not planning on changing now..
  • Names have been changed to protect the guilty.
  • None of the hostname or users used in examples actually exist.
  • Feel free to post any comments or suggestions below.

Originally published on Medium.