When least privilege is the most important thing

In the ever-evolving realm of information security, the principle of Least Privilege stands out as the cornerstone of safeguarding sensitive data. However, this fundamental concept, emphasizing limited access to resources and information, has been progressively overlooked, placing our digital ecosystems at greater risk.

First, let’s define our terms. The principle of least privilege (PoLP) is an information security concept that maintains that a user or entity should only have access to the specific data, resources, and applications needed to complete a required task. Organizations that follow the principle of least privilege can improve their security posture by significantly reducing their attack surface and risk of malware spread.

PoLP is also a fundamental pillar of zero trust network access (ZTNA) 2.0. Within a ZTNA 2.0 framework, the principle of least privilege provides the ability to accurately identify applications and specific application functions across any and all ports and protocols, including dynamic ports, regardless of the IP address or fully qualified domain name (FQDN) an application uses. The principle of least privilege within ZTNA 2.0 eliminates the need for administrators to think about network constructs and enables fine-grained access control to implement comprehensive least-privileged access.

So, in a nutshell, least privilege says that every object in a system – whether a user, a process, or an application – must be able to access only the information and resources that it needs, and no more. In truth, we ignore least privilege at our peril. And, yes, we are ignoring it.

In the early days of Windows operating systems up through Windows XP, almost any program a user would launch would have administrator-level privileges. It was assumed that every program, by default, needs this level. But this opened the applications for attacks that could easily subvert the entire OS. There were countless types of attacks, from accidentally downloading malware to a webpage that exploited a browser bug and more. The result was that it was straightforward, at times elementary, for malicious software to own the entire system.

When this no longer became tenable, Microsoft led the way and started its Trustworthy Computing initiative in 2002. In the original Trustworthy Computing white paper, the four goals of the initiative were security, privacy, reliability, and business integrity.

Yet even in the twenty-one years of Trustworthy Computing, least privilege is still not given the attention it deserves. And with that, information security suffers significantly.

The SolarWinds exploit of 2020 shows how enforcing least privilege could have stopped one of the worst security events in history. The supply chain attack zeroed in on a single component of the SolarWinds Orion IT management tool, used by over 30,000 customers, that sent small amounts of telemetry data back to the vendor. Therefore, it was not regarded as unusual when outbound data was seen.

But why did SolarWinds even need this data to begin with? Undoubtedly, it helps them build a better product, but that does not directly benefit the customer. It violates PoLP because that data wasn’t necessary for Orion to work. Indeed, SolarWinds clients who enforced least privilege by not allowing any outbound data from the software except that which was explicitly whitelisted were not susceptible to the attack at all. A seemingly minor component of the software suite was the one that was exploited – but it seems it was not a necessary component, to begin with.

Mobile applications provide an excellent example of the dangers of ignoring least privilege.

Why this Android flashlight application needs access to your location or Wi-Fi information is quite questionable.

And look at this sample of the end-user license agreement (EULA) for the flashlight app, which shows significant data-gathering requirements for a simple flashlight.

When new apps are installed, they often request – and are given – permission to do things on the device that are not necessary for the application’s normal use, or only rarely. For example, many apps say they require access to the camera or microphone. But does anyone ask why ESPN needs access to the camera? Maybe it can read QR codes for particular reasons that are rarely used, but once it is given permission, it has permission all the time. If the app gets compromised, the bad guys have unlimited access to the mic and camera.

This isn’t a theoretical scenario. The Android “iRecorder — Screen Recorder” app was discovered in May 2023 to spy on its users, recording audio and uploading it to a server every fifteen minutes. This is frightening – but anyone who refused to install a screen recorder app because it has no business accessing the mic would not have fallen prey to this issue. 

This is a failure of least privilege.

Another problem with mobile application security is the speed with which individuals can develop and deploy new apps. Enterprise software companies and large corporations usually have some level of security built into their software development lifecycle; but on mobile the entire SDLC could be a day or a week between the initial idea and deployment. Unless security is mandated by policy or regulations, developers will place least privilege and other security principles as their lowest priority.

Not to say that this is only a problem with mobile app development. Software vendors too often place profits and being first to market before security. The developers are pressured to deliver code, often before it has been adequately tested for security vulnerabilities, threat modeling, and more. Writing secure code which addresses PoLP is often not prioritized.

The Internet of Things is not exempt from least privilege 

Another nightmare is built into the Internet of Things (IoT). We are allowing devices everywhere, from private homes and businesses, to hospitals, public buildings, and much more. Many of these IoT devices have no internal security to speak of, yet we are giving them access to our networks and often to the Internet. 

This is a potential disaster fueled by ignoring least privilege, and right now, the only way to combat it is by monitoring network traffic and limiting their access to only the devices they need to communicate to – and nothing else. But there is no pressure on IoT vendors to put proper controls on their devices at the operating system level – controls that could limit the damage both for bugs in code and to having the devices subverted by others. 

As we move to the cloud, there are new potential nightmares. Cloud vendors like Microsoft Azure and Amazon Web Services want to make sure that their clouds are interoperable with third-party vendors, so there is a slew of add-ins you can choose from, but the vendors often request excessive permissions, and customers have little recourse but to allow them because the vendor will not support their products if they are not implemented according to their requirements. 

Some companies want third-party backup solutions for their cloud services. These vendors require full access to the data – backup requires reading all the data from everywhere, and restore requires the ability to write data anywhere, which is essentially giving the keys of the kingdom to the vendor unless you add additional controls.

Backups are done regularly, but data restoration is generally a rare task. So why not divide up the functions and give the backup function read-only rights while the rarely used restore function, which would be used only in emergencies, would have the only write rights? Yet when a sampling of cloud backup vendors was asked this question, it wasn’t even something they had considered. Meaning that if a heretofore unknown cloud worm compromises the backup function, it could overwrite company data, very possibly without anyone noticing. 

If sophisticated ransomware had access to the software, under that scenario, it could ensure that the backups themselves become the source of malware. And there are countless other possibilities where non-enforced PoLP could be maliciously used.

Similarly, a compliance tool that plugs into corporate cloud email systems demands read-and-write access to all user mailboxes. Read access makes sense; write access does not. This was a design decision by the vendor, but that decision itself violates PoLP, and the solution should be re-architected.

This is a failure of cloud vendors to even consider the foundational security principle of least privilege. However, the owners of the cloud ecosystems are not able to determine whether the vendor is demanding excessive rights – we are trusting vendors themselves to say that these are requirements, and as we have seen, vendors often choose to demand more permissions than spend the time to create a secure architecture for their code, to begin with. 

It is not far-fetched to imagine a cloud worm that will take advantage of these excessive permissions, and the potential damage would be orders of magnitude worse than any previous security event.

The future is no brighter

Nowadays, everyone is talking about artificial intelligence (AI). And AI, like every new technology, brings its own set of unique challenges to the concept of least privilege. 

Cloud vendors are by now quite comfortable with separating databases for different clients, and there is far less concern about mistakes being made where one client could (accidentally or deliberately) read or write a competitor’s data in the same vendor cloud. But who is talking about protecting corporate data in an AI cloud?

By their nature, many AI systems are acquisitive and want to get as much data as possible (think exabytes) to add to their learning model and make better decisions. What controls exist for AI products that access private company data to keep that data confidential? In virtually all cases, AI would upload the corporate data into the vast AI database to help the customer make better decisions, but can others craft a query to fool the AI into sharing your company data with them? 

AI is now supporting add-ons and plugins as well, so we have increasingly complex systems that cannot be easily (or ever) debugged today – and their complexity is increasing exponentially. Traditional security methods that rely on data center and database-level controls will not work in this new world. 

Will we rely on AI to secure its own data – and can we trust that it can do that? These are all failures of least privilege today, and only a minority of AI solutions vendors are addressing these issues.

Ten recommendations to fix the least privilege conundrum 

We have laid out a lot of the problems. So what can be done? In the Harvard Business Review, Sabina Nawaz writes that it’s time to retire the saying, “Don’t bring me problems, bring me solutions.” But in deference to Ms. Nawaz, we laid out the problem, and here are some tactical and strategic solutions. 

1. Customers must insist that their vendors, and those writing the underlying system code, take these problems seriously before a catastrophe occurs. Vendors who build secure systems today will be in a much better position when a disaster occurs. The vendors must be told clearly during the research phase that they will lose the sale if they lack basic PoLP and other security controls.
2. Similarly, if you already use third-party applications that violate least privilege, put in feature requests to the vendors asking for them to adhere to PoLP. 
3. Implement compensating controls. Don’t only filter incoming firewall traffic but also limit the outbound traffic from critical systems to only the essential targets they need to communicate with, typically the vendor site itself, for software updates. 
4. While least privilege is considered at the system level, it is also relevant to data. And you have to ensure that you have complete data discovery and classification of all of your confidential data. Knowing precisely what confidential data you have and its location is far from a trivial task. Having this understanding of where your data is makes the process of ensuring least privilege much easier.
5. Another essential, if imperfect, control is to increase logging on all layers of the technology stack that you can. Anomaly detection tools can help save time or detect unusual patterns. Especially monitor your tools that have access to all your internal networks.
6. It is essential to create standard, secure builds for your operating systems that eliminate unnecessary bloatware, plug-ins, and protocols. This reduces your attack surface by orders of magnitude.
7. This is such a no-brainer and so elementary that we debated including it. But you have to remove inactive user accounts. You can’t have least privilege if you have user accounts for users that are no longer with the organization. Attackers target inactive accounts as it gives them access under the guise of being a legitimate user. 
8. Role-based access control (RBAC) is paramount to ensure privileges are not escalated. And RBAC is supported by all the major cloud vendors and every operating system.
9. Review your company’s own software development policies and procedures and ensure that the code you develop adheres to the principle of least privilege.
10. Finally, user monitoring, specifically privileged accounts, is paramount. You need to understand what these users are doing and what systems and data they are accessing.

History tells us that least privilege problems are not seriously attacked until significant incidents pressure vendors to do what they should have done, to begin with. Most of us do not have the luxury of waiting for vendors to wake up. Assume, and plan for, the worst.

The history of information security also makes it eminently clear that data breaches and disasters are not a matter of if but when. And the best time to prepare for that inevitability is now.