Stay up to date
Stay up to date with the latest threat reports, articles & mistakes to avoid.
Simple, yet important content.
No salesy pitches and all that, promise!
Here is a simple illustration of how the principle of least privilege works. Remember when you installed Whatsapp? You most likely got a prompt asking you to click “Allow” so the app could access your media, run in the background, or manage contacts. In that instance, you were extending privileged access to the application, so it runs effectively for you.
Just as privilege implies the special authorisation given to users or technologies to bypass certain security restraints, least privilege means the opposite. The principle of least privilege is the practice of restricting the access rights of systems, users, accounts, and computing processes to the required resources only that are sufficient to perform specific activities.
Least privilege access, also called the Principle of Least Privilege (PoLP), when applied to users, suggests enforcing the minimum level of user rights, or basic clearance level, that enables the user to perform his/her role.
In a world where data breaches and privacy infringements have serious consequences on the business, the principle of least privilege is one of the topmost security best practices that systems and companies need to follow. The principle of least privilege (PoLP) is the foundation of a business’s cyber security structure.
This blog will explain the least privilege principle, the difference between privileged and non-privileged accounts and famous breaches due to negligence in this area. We will also explore the benefits of least privileged access and talk about least privilege best practices.
What is the principle of least privilege?
The principle of least privilege, or “least privilege access,” is a cyber security best practice that requires limiting users to the privileges necessary to perform a specific task. The least privilege access control as applied to security is the basis of the zero-trust model; however zero-trust model is much more comprehensive. Security professionals usually regard this principle as concerning user accounts’ access rights, admin privileges and computer security frameworks. However, the least privilege principle has a broader application range, including access controls & security throughout an organisation. PoLP even applies to scenarios outside the work environment.
Principle of least privilege example
An example of the least privilege principle is where an external contractor has been provided with just enough privileges to perform their tasks. Over-privileged third-party contractors could gain unfettered access that could have potentially dangerous consequences.
The principle of least privilege functions by allowing systems just enough access to perform their required tasks. It thrives on the concept of a “need-to-know” basis. Networks, users, software should only have access to data they need to know. The information they access must be relevant to their functions.
Adhering to the least privilege in network security eliminates an intruder’s risk of gaining access to critical secrets or networks hosting sensitive data. It basically increases the difficulty of lateral movement and attacks within a network.
Implementing least privilege access limits attacks from infiltrating further in the enterprise networks or internal networks, stopping them from spreading to the wider areas within an organisation.
Although the PoLP is straightforward, it can be a bit challenging to implement the least privilege effectively, especially when you consider variables such as:
- Varying operating systems (Windows, macOS, Linux, Unix.)
- Increasing numbers and varieties of apps, networks and endpoints, ranging from desktops, laptops, tablets, smartphones, network and security devices and IoT.
- Various computing environments (cloud, virtual, hybrid)
- Different types of user account variables such as identities, roles (human, applications, machine)
Concerning user identities, Forrester research shows that machine identities of privileged accounts are growing exponentially compared to human identities. If left unmanaged and unidentified, these identities can serve as hosts from where hackers enjoy access and launch further attacks.
A 2016 Forrester study also found that 80% of information security threats involve accounts with privileged access. Another reason why the principle of least privilege, also the Principle of least authority, is essential security control.
Ensuring the least privilege is instrumental in mitigating information security threats, protecting sensitive data and minimising business disruptions that may result from system errors or malicious threats such as ransomware attacks, Denial of Service (DoS) attacks.
Cloud and virtualized environments provide numerous benefits, the simple truth why we see an exponential rise in cloud adoption.
Insecure privileged access management is likely the case during a hybrid environment where legacy applications, services are used.
Latest systems such as AWS, Office 365, Azure portals provide granular access with multiple privileges and roles to allow control and scalability. However, with multiple sites and multi-cloud implementations, it can be quite a task for the teams, leaving them with more confusion and gaps without a lack of strict processes, including tools.
Difference between user and admin accounts (privileged and non-privileged accounts)
Privileged accounts enjoy elevated, non-restricted access to target systems, services or accounts that non-privileged accounts don’t have access to. Organisations often allot privileges to users based on two parameters:
- Business unit or job function (e.g. Customer service department, HR unit, IT officials
- Rank or level (Executive Directors get privilege over primary staff).
Aside from these two, factors such as; time of day, special circumstances, unique assignments, various operating systems, etc., also come into play from time to time.
There are 3 common types of user accounts;
- Superuser accounts (Most privileged such as domain administrator accounts)
- Standard user accounts (such as domain user accounts)
- Guest/ Non-user accounts (none, anonymous or little privileges)
These accounts are for administration and monitoring security and top-ranking IT employees. Also termed the “root account”, this account often has unlimited privileges over a system network. Such rights may include read-write execute rights and the power to perform system-wide changes across a network. These include reconfiguring core system settings, adding and deleting users and data, installing & uninstalling files and software, among others.
A superuser account in a Linux or Unix system has an all-encompassing presence on the network. It has unrestricted user access to all processes, commands, sensitive information and system resources. These admin accounts can even impact other user accounts by changing access controls.
Due to their privileged credentials and the extent of the damage they can cause, root accounts should only be accessed by IT admins when extremely necessary. A single error or malicious attack can paralyse the entire system or entirely disrupt an enterprise.
Hence, admins should also have standard accounts for routine tasks to ensure system security.
Standard user accounts
Standard user accounts are also known as the least privilege to user accounts or limited user accounts (LUA). These accounts possess a limited set of privileges. They can run programs on networks and computers, modify simple processes and run minor and specific system functions. These are often allocated to staff in an organisation for routine tasks in different departments such as HR, IT, Finance, Admin.
In an enterprise that observes the least privilege model, most users should be operating standard accounts 100% of the time. For example, a user on a standard level (e.g. Sales rep) shouldn’t have access to a company server like the core IT repo with software installs, licensing and setup information.
Guest or Non-user accounts
These accounts have zero to minimal privileges. They only have access to bare minimal functions, for instance, running simple programs. Some organisations define guest accounts with more than normal access, such as internet browsing, access to certain file shares, etc. Such guest accounts (for one-time contractors) are most suited for internal processes or services or sometimes part of default privileges.
There is a different definition of guest accounts when it comes to services or applications. Some applications name a user session as a guest account based on cookies assigned under unauthenticated sessions.
Guest account in Windows
The guest account lets other users use your computer without changing any settings, access private files, or installing any applications. Windows 10 no longer offers a guest account to share your PC, but you can create a restricted account (the equivalent of a guest account).
Discuss your concerns today
Famous breaches due to privileged access abuse
Malware, insider threats, third-party vendors & partners, and privileged user errors account for the most common privileged access abuse faced by enterprises.
This short review of some cyber attack situations that companies have faced in the past is included here. It will help you understand how to avoid similar occurrences in your organisation.
These are some of the famous examples of how threat actors took advantage of privileged access in the real world;
Target breach, 2013
In 2013, an international retail enterprise – Target – was targeted by attackers. They rendered infiltrated the companys’ internal systems without raising any alarms to defensive teams. In a cyber attack that affected 70 million customers, the infiltrators stole credentials from a third-party vendor – an HVAC company. This contractor had access to far more privileges than needed to execute its maintenance tasks on the Target network. This is why the importance of cyber security best practices for eCommerce organisations is greater than before.
Target could have avoided this breach if it had reviewed access provisions for its suppliers and staff regularly. The outcome may have been different by limiting access permissions to the least resources and areas needed by the heating and ventilation company. Restricting third-party vendor access has been a challenging security control for many organisations. However, to avoid scenarios similar to Target’s, companies must give such rules utmost importance. Enterprises should provide access only when vendors need access.
SolarWinds (solorigate incident), 2020
In 2020, nation state backed attackers compromised SolarWinds, a major United States IT firm. This infiltration went undetected for almost a year, giving attackers access to SolarWinds’ (rights reserved) sensitive data and its clients. Most of these clients were US department agencies and corporates. The attackers worked by inserting malicious code into the SolarWinds Orion code. When SolarWinds unknowingly sent out regular software updates containing the malicious code, it created a backdoor that the attackers used to spy on customers.
This attack was possible because of the unrestricted access to critical systems that SolarWinds Orion requires to operate efficiently. The software requires global shared administrator access to work, a common requirement with legacy applications like Orion.
The least privilege principle is difficult – impossible really – to implement with systems like this where either by functionality or by misconfiguration, privileged access is trusted on to the software in use. The systems require privileged access to function properly, which creates ample room for trust internally because none of the logging and alerting mechanism will flag such an event.
While such incidents may be quite hard to avoid in this context, enterprises can mitigate such occurrences to a degree by choosing to screen vendors or applications that require access and ensuring stricter information security measures. As much as possible, organisations should enforce the least privilege application and access management by removing excessive application privileges. This applies to critical assets such as databases also (MySQL, MSSQL, etc.).
What are the benefits of the Least Privilege Model?
The benefits of the principle of least privilege (PoLP) model are numerous. Cyber threats are real, and when they become successful attacks – their effects are crippling. Access management is of the highest importance today. Here are some benefits enterprises gain when they follow the principle of least privilege;
Limited access = Limited attack surface = Increased difficulty
By restricting access and user privileges to a role-based process, organisations automatically reduce unauthorised access and infiltration chances. It is an effective way for companies to reduce their systems from being exploited. Even in an attack, the attack surface range is minimal and limited abuse of system or systems take place, leaving attackers with hardly any choice.
Enterprises can better protect themselves, their users, and clients from privacy infringements and data leaks by implementing the least privilege principle. PoLP ensures stricter security controls raising entire organisations’ internal profile. High-clearance staff should be the only ones with admin rights to sensitive areas of the system, and they should use this access with caution. On a broader level, this principle can be extended to physical access controls and other areas of access control within an organisation (at user, object, service, system, network and environment levels).
Reduces malware infection
The least privilege principle significantly reduces malware spread and infection as it starves the malware of access points to infiltrate. This way, malware (such as spyware) cannot expand its attacks around the internal systems.
When regulatory agencies perform security audits, organisations that synchronise the principle of least privilege in their systems have a better chance of being cleared and adhering to compliance requirements such as PCI DSS, ISO 27001, GDPR, to name a few. Not only it is a security best practice, increasingly, many compliance regulations across various fields also require it for systems security.
For instance, in the Payments industry, the PCI DSS Compliance requirements state that “To ensure critical data can only be accessed by authorised personnel, systems and processes must be in place to limit access on a need-to-know basis and according to job responsibilities.”
Limitations of the least privilege model
Keep in mind that the PoLP is just one dot connecting to others in a defensive controls strategy. Let’s take this example where a financial controller in an organisation requires a privileged account to make changes in the internal departments’ finance portal. Active Directory integrated portal allocates privileged access to the controller without reviewing the privileges that allow him higher access around the windows network too. In case of a spear-phishing attack targeted at this controller, threat actors could gain administrator-level access due to the controller’s underlying account. On the contrary, an attacker would have normal user-level access if the financial controller was supplied with a different account to be used for privileged tasks only or via a jump box used for privileged tasks only.
Therefore, the security controls strategy must consider multiple other areas such as user education, endpoint protection, network and web protection, safe & secure communications within an organisation.
Organisations should consider other protective technologies to support the least privilege principle, such as firewalls that prevent connections, antivirus, host-based intrusion detection systems and software restriction processes that limit what applications can install and execute. This practice should be deployed at the environment, networks, systems, services down to user/role level.
Discuss your concerns today
Least privilege access best practices to follow
Here is a list of five practices for enterprises to adopt while implementing the least privilege principle;
- Usage: Use administrator accounts only when necessary. The risks are higher when operating these accounts, so use should be limited to sensitive tasks and where possible internally.
- Regular audit: Carry out an audit of privileged and least privileged accounts. Ensure you account for, manage and regularly review employee, vendor and freelancer credentials.
- Default: Eliminate default admin and anonymous rights. Users should be entitled to the least necessary privileges by default. If specific job roles require higher access, users should request elevated privileges relevant to their particular tasks. Account privileges should be limited to necessary functions only.
- Segmentation: Create a system and network segments based on the asset category or classes. These should separate users from processes and rank them based on access requirements and privilege groups, thereby minimising malware’s attack surface.
- Adopt a just-in-time (JIT) strategy: Privileged access should preferably be limited and time-bound. Implement one-time use privileges to ensure most users do not have unbridled access to the system’s sensitive areas. Access should last only as long as needed for the completion of specific tasks.
That’s not the end of this. Regular reviews must be performed to ensure the access management strategy is in line with functional requirements.
- Ensure that privileged account usage audit events are carefully selected not to overwhelm the monitoring teams and mechanisms. It includes logging of success or failure or both the events in logons, objects access, directory services, passwords change, unusual service access, etc.
- Perform privilege account audits and ensure processes are in place to remove them after use.
- Follow strict change management procedures to ensure no exceptions are allowed, and all requests comply with relevant processes and approvals.
Get in touch to discuss your security concerns, security strategy or any other challenges around the subject.