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. Let’s ponder this as we consider some basic definitions.
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.
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:
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 privileges or access rights can show you if things are occurring that fall outside those controls.
Hopefully, you won’t find anything like this at all. But if you do, your next step should be to declare a security incident and bring in the security team (or its equivalent) to investigate:
This can be a grim and time-consuming task, so be prepared to invest significant time and effort in the time between declaring and incident and closing that incident.
First and foremost, the organization must conduct a thorough audit of the assignment and use of privilege for all accounts, processes, and programs associated with the web-based app. If adjustments to any of them show themselves to be justified, make them as soon as possible.
Going forward, all new accounts should default to minimal privileges, with higher-level permissions granted only to those who need them (and in the context of separate, audited accounts used only to exercise such higher-level permissions).
The principle of “just-in-time privileges” plays into the preceding item. This states the case where elevated privileges only come into play (and become available) when and as they’re used. Users default to typical user privileges for everyday work. Only when they perform admin tasks, do they obtain higher-level privileges, which they then surrender as soon as that admin task is completed.
Make everyone (and everything) accountable, so that user accounts, logging and monitoring, and automatic auditing for any kind activity that involves elevated privileges keeps things visible and transparent.
Last, it’s important to audit at periodic intervals for privilege assignments. Over time, many security objects (users, groups, processes, and applications) experience “privilege creep.” This describes a steady and almost unnoticeable build-up of added privileges or elevated access rights over time. Here again, these must be reset to the bare minimum to keep things secure and ship-shape.
Paying attention to assignment and use of privileges and access rights is the key to asserting and maintaining POLP. This works for web-based applications as it does for the rest of your IT infrastructure.
