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.\n\nFirst, let\u2019s 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.\n\nPoLP 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.\n\nSo, in a nutshell, least privilege says that every object in a system \u2013 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.\n\nIn 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.\n\nWhen 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.\n\nYet 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.\n\nThe 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.\n\nBut 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\u2019t 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 \u2013 but it seems it was not a necessary component, to begin with.\n\nMobile applications provide an excellent example of the dangers of ignoring least privilege.\n\nWhy this Android flashlight application needs access to your location or Wi-Fi information is quite questionable.\n\nAnd 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.\n\nWhen new apps are installed, they often request \u2013 and are given \u2013 permission to do things on the device that are not necessary for the application\u2019s 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.\n\nThis isn\u2019t a theoretical scenario. The Android \u201ciRecorder \u2014 Screen Recorder\u201d 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 \u2013 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. \n\nThis is a failure of least privilege.\n\nAnother 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.\n\nNot 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.\n\nThe Internet of Things is not exempt from least privilege \n\nAnother 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. \n\nThis 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 \u2013 and nothing else. But there is no pressure on IoT vendors to put proper controls on their devices at the operating system level \u2013 controls that could limit the damage both for bugs in code and to having the devices subverted by others. \n\nAs 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.\u00a0\n\nSome companies want third-party backup solutions for their cloud services. These vendors require full access to the data \u2013 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.\n\nBackups 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\u2019t 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. \n\nIf 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.\n\nSimilarly, 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.\n\nThis 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 \u2013 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. \n\nIt 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.\n\nThe future is no brighter\n\nNowadays, 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. \n\nCloud 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\u2019s data in the same vendor cloud. But who is talking about protecting corporate data in an AI cloud?\n\nBy 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? \n\nAI is now supporting add-ons and plugins as well, so we have increasingly complex systems that cannot be easily (or ever) debugged today \u2013 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. \n\nWill we rely on AI to secure its own data \u2013 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.\n\nTen recommendations to fix the least privilege conundrum \n\nWe have laid out a lot of the problems. So what can be done? In the Harvard Business Review, Sabina Nawaz writes that it\u2019s time to retire the saying, \u201cDon\u2019t bring me problems, bring me solutions.\u201d But in deference to Ms. Nawaz, we laid out the problem, and here are some tactical and strategic solutions.\u00a0\n\nHistory 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.\n\nThe 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.