When least privilege is the most important thing

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.