The Principle of Least Privilege (PoLP) dictates that users receive only essential permissions for their tasks. For example, a user account designed for database record retrieval shouldn't possess admin rights, while someone updating code lines needn't access financial data. This approach minimizes risks by preventing unnecessary, potentially harmful access.
In this blog, we’ll review several least privilege examples commonly seen in enterprise organizations. They involve violations of least privilege best practices by business users, IT teams, and third parties. By outlining and diagramming these least privilege examples, you’ll see where integrating access security controls would have prevented compliance violations and mitigated the risk of a successful breach.
If you saw a file marked, “all employee salaries”, would you click on it?
Maybe that’s an extreme example, but it’s certainly a risk of not following the Principle of Least Privilege. Sometimes people see things they can’t unsee.
Such is the case when employees have excess access rights. Without least privilege, a well-intended search on the company intranet could expose information meant to stay private. Sensitive information, like Personally Identifiable Information (PII) and IP, should only be seen—let alone accessed, changed, or downloaded—by a small, known group of people.
It takes a systematic approach to prevent this type of least privilege security breach. A standard mitigation strategy includes conducting discovery to find out where sensitive data is housed, whether it requires admin rights to be accessed, and who has those access rights.
Once that is known, it becomes a matter of layering security controls to ensure least privilege: Controlling initial access and privilege elevation, incorporating allow and deny lists for applications, and monitoring privileged user behavior. You should always be able to track and report on privileged behavior related to sensitive information.
Other least privilege examples to prevent misuse include limiting the types of actions a user can take with sensitive information, such as using a USB stick or accessing file shares, and adding extra monitoring controls, such as scanning all email attachments.
One of the most common ways ransomware enters an organization is through end-user workstations and devices.
Why does this happen?
IT organizations often use golden images to provision user endpoints (like devices and workstations) with a common configuration. While this approach improves efficiency, when done improperly, it can create a gaping security hole: users who should have standard credentials instead are set up with privileged credentials.
As local administrators, business users can change settings, run any programs, and install any software they want on their endpoints—including applications that could leak data or have other security risks. The problem is, any cybercriminal who gains access to that endpoint will have that ability too.
Images with default passwords cause other problems too. Default passwords are rarely changed, resulting in the same password being used across thousands of systems for years on end. If each local domain account, guest account, or other built-in accounts and local domain groups have the same default passwords, and those passwords aren’t updated, someone who gains access to the default information would then have access to any number of devices.
Now, assume the average end-user with local admin rights clicks on a phishing email or downloads a malicious application. Suddenly, the bad guys have access.
If that end-user has broader access rights, the cyber criminal can leverage these access rights to reach more systems in the IT network—for example, servers that house sensitive, critical data. An attacker may exfiltrate data and hold it for ransom. Those same access rights can then be used to cover the cyber criminal’s tracks and avoid capture.
In this example, had the Principle of Least Privilege been followed, the laptop would only have had standard privileges, not local admin rights. The individual laptop would have been compromised, but the ransomware would not have been able to progress.
The best least privilege security practice is to ensure local admin group membership is used appropriately. Taking a lifecycle approach to managing privileges also includes regular audits and culling unneeded or elevated administrator rights.
To avoid a least privilege violation like this example, even your IT administrators should have different accounts for different use cases. Instead of “one account to rule them all,” they should have specific, privileged accounts used for access or running certain applications such as updates, access databases or backups, as well as a standard account to use for general purposes.
When implementing the Principle of Least Privilege, application control policies help end-users maintain productivity by allowing trusted applications and commands to run and denying those known to be malicious. You can specify which software is allowed to execute and which should never be run, and you can sandbox any software that is ambiguous or hasn’t yet been tested. Validation occurs in the background, invisible to end-users.
Segregation of Duties (SoD) is an important concept in enterprise risk management, required by regulations such as the Sarbanes-Oxley Act. It involves dividing an activity or transaction into different parts, to prevent any one person from gaining excessive control and having the power to defraud an organization.
In an example of SoD, one employee on a finance team would be responsible for payroll accounting, and another for signing off on checks. In another example, one person would be assigned for each sub-ledger in the accounting process, but not the entire process. Importantly, different people would be required for multiple layers of review, coming into an accounting process at different times.
In this example of least privilege, you would grant one person in the process access to certain applications or certain capabilities within the application while granting another person a completely different type of access. You might also put time limits on access to prevent anyone from changing numbers in the General Ledger after the month has closed.
Increasingly, IT teams are outsourcing work to third-party contractors. Let's say a third party is granted access for ongoing maintenance of your servers. Since it’s an ongoing contract, you don't want to keep having to manually grant and revoke their privileges, so you just set them up with full-time access to everything.
Now consider that the vendor has a team that shares responsibilities, all of whom work remotely. Any one of these people may use the credentials you gave them. Some people join and leave the team, but the credentials remain the same. Thanks to these shared credentials, new people never have to ask, "Hey, what's the password?”
This short-sighted sharing of credentials is a clear example of a violation of least privilege that should make you cringe for many reasons:
According to the Principle of Least Privilege, vendors should never have broad admin rights on your network. This is especially true if you don't manage the devices vendors use to access your network.
As a starting point, third-party vendor credentials should always be limited in terms of time and scope. Rather than providing blanket privileges, have vendors log in using a standard vendor account and provide a mechanism to elevate their privileges for specific use cases or applications only, and for a limited time. Any elevation to privileged access should be just-enough (JEP) and just-in-time (JIT).
Any user accessing your network using vendor credentials should be subjected to an “always verify and always monitor” policy. “Always verifying” means that each time a vendor attempts to access a resource on your network, they are forced to authenticate using Multi-Factor Authentication (MFA). That also goes for subsequent access to other resources or privilege elevation.
An “always monitor” policy ensures that all actions a vendor takes are recorded by default, and available for later audit or review.
The average number of APIs in an organization grew 82% last year. They are ubiquitous in organizations. Because they underpin and pull together so many digital, back-end services, APIs are prime targets for cyber criminals. Overly permissive APIs lead to security breaches.
Your APIs should be treated as super-users and protected with the same precautions. You can also relegate them to “average user” and operate on the principle of least privilege. Then, you would only give the requesting entity (the person interfacing with the app) what they need. Keep the rest of those super-connecting superpowers disabled.
Now that you know some common least privilege risks to avoid, the good news is you still have time to make changes.
Get started on a least privilege program for your organization.
If you're unsure of your least privilege posture, the best way to get the unvarnished truth is to run a Discovery scan of your IT environment. Delinea's free Least Privilege Discovery Tool indicates which accounts may be overprivileged and vulnerable to insider threats and malware attacks.
After running the least privilege scan, you'll get a customized report that highlights issues with user workstations, IT infrastructure, services, operating systems, and applications.
The prioritized results will help you:
For more examples of least privilege security and guidance on planning your least privilege strategy, check out our eBook, Least Privilege Cybersecurity for Dummies.