Putting the Principle of Least Privilege to Work for Web Apps
With an ever-increasing proportion of day-to-day work on the desktop occurring in the form of web-based applications, organizations need to rethink how those applications work. They also need to examine – and in some cases tighten up – how web-based apps (or rather, the processes within which they operate) make use of privileges and access rights for Least Privilege. Let’s ponder this as we consider some basic definitions. Understanding the Principle of Least Privilege I’ve been writing about this principle since the early 2000s (the first edition of our Sybex CISSP Study Guide is copyright 2003; it’s now in its 6th edition). Simply put, the principle of least privilege means that no user, process, or program should have any more privileges than it absolutely needs to do its job. This principle exists to prevent cases where excessive (and unnecessary) privileges can lead to unwanted, unauthorized, and perhaps even damaging use of such privileges can occur. I just learned that this principle is sometimes abbreviated POLP, and takes the principle of minimal privilege (POMP) and the principle of least authority (POLA) as synonyms, thanks to Nate Lord’s excellent discussion at the Digital Guardian. POLP’s Security Implications for Web-based Apps Web-based apps generally run in two or more security contexts, in which one might be characterized as “typical user” and the other as “administrator.” Of course, some Web-based apps (think security portals, cloud or network management consoles, threat and vulnerability reporting and alerting tools, and so forth) may have multiple levels of administrative privilege. Thus, they can distinguish basic admins who maintain and update the runtime environment from senior admins who can install and configure the environment, establish role-based security structures and populate them with groups and accounts, and so forth. Across the board, asserting the principle of least privilege starts with checking the processes and accounts associated with a web app: Do ordinary users run in the typical user context? Do admins run in an appropriate administrator security context? If so, that’s one step in making sure things are working as they should be. If not, it’s time – right now! – to set things right and put accounts into their proper security contexts. But there’s more involved in asserting POLP for web-based apps. Using some kind of audit tool within the access control capabilities of the host platform’s OS, and the security tools for the web-based app itself, it’s essential to get as complete a picture of the privileges available to the web-based app itself (it’s usual runtime context, that is). Then, do likewise for the user accounts and/or groups or roles that are allowed to run this web-based app. Here, you’re looking for grants of access or privileges that exceed the bare minimum that’s needed for the item under consideration (be it user, group, role, process, or program). Of course, if you find anything, you’ll need to trim it back to where it should be. From a forensics and information-gathering perspective, you’ll also want to use logs or other audit tools to get a picture of how privilege is actually being used within the general runtime context for the web-based app as well. Settings that grant access rights or privileges tell you what should be going on within that runtime context. Examination of logs and other audit tools that record, analyze, and report on actual USE of […]
