I recently saw a posting on LinkedIn that said something like “with zero trust we can consider all access as privileged access”.
While this could be considered true, I also made the same argument 15+ years ago before zero trust was a thing people cared about; my argument was “if I can login to a server then I can run commands, impact applications (eg chew up CPU), fork bomb, etc; surely that means all access is privileged”.
Now while that is true enough, it’s not necessarily a helpful stance. The term “privileged access” has a lot of connotations, especially in regulated industries where auditors want you to have strong controls in place.
After all, with zero trust in place your personal access your email is something that’s evaluated and permissions need to be in place. We don’t always consider this to be privileged.
Technology view
So businesses may next start thinking about how privileged access may work.
On a Unix machine having the ability to do things as root is normally the
first place we end up. If the company is smart they’ll use something like
sudo (or equivalent) to provide some finer grained control. Users log in
with a low privileges and then use these tools to escalate their privileges;
a user that can do this is a privileged user. And then the control expands
to cover the oracle account, the service/functional account used to run
your app, and so on.
On Windows we might deploy a privileged escalation tool to do similar to what Unix does, or we might have “admin” accounts in a privileged group and put those passwords in a controlled vault. On Oracle we might do similar with DBA privileges.
But in all of these solutions we’re looking at this from a technology perspective; if the platform considers activity privileged then we classify access to this as privileged.
Weakness of this
The problem with the technology view is that it brings a lot of people into
scope for stricter controls (e.g. more frequent recertification, enhanced
activity oversight) than is necessary. It also frequently leads to “laziness”;
oh if I’ve got to jump through these hoops then I might as well just do sudo su.
A simple example is from Solaris; on this platform (at least Solaris 8 and
before), ifconfig -a will not show the MAC addresses of the interfaces;
you need to be root to see that information. So now if you grant someone
sudo ifconfig -a (being careful to ensure that’s all they can do!) you’ve
granted someone a technology privilege, but are they really a privileged
user?
Another example might be the df command; if a mount point is hidden then
the disk may not show up in the output, but if run as root it will.
% ls -ld /tmp/dir1
drwx------ 3 root root 4096 Aug 26 15:42 /tmp/dir1
% df | grep dir1
% sudo df | grep dir1
/dev/shm 249720 0 249720 0% /tmp/dir1/mountpoint
Is this really privileged access? Knowledge that the mountpoint exists
may be exposed elsewhere (eg /proc/mounts); we really only need elevated
privileges because of how df works (it can’t do a stat() on the mountpoint
because the parent directory doesn’t allow the user access).
Business privilege
So let’s look at this from a business perspective, instead.
The goal of all these controls is to provide the CIA triad; confidentiality, integrity, availability.
We need to evaluate the risk of activities under this umbrella, and what is considered an unacceptable risk to one business may not be one to another.
We might decide that sudo ifconfig is privileged because you can make changes
(e.g. change IP address) but sudo ifconfig -a is unprivileged because it’s
not exposing sensitive data. This is a business decision.
So now our definition of privilege can be rewritten in business terms; perhaps something like “activity that exposes or modifies sensitive data, or impact the running of the business”.
OK, that’s pretty weak but it’s a starting point; a customer can access their own data (eg bank transactions) but that’s not considered privileged. However a bank teller can access multiple people’s transactions and so is privileged.
So this definition can (and should!) be refined. This is potentially hard.
But it’s important to note that the way we’re defining this isn’t in technology terms, it’s in business terms.
Now we can look at access rules and determine if they’re business privileged or not. We can take a risk based approach.
Of course this does require help from the platforms we’re trying to control; the finer grained the controls can be, the better we can limit access, and the fewer people need to be considered “privileged”.
Entitlements vs privilege
In order to advance the discussion we need to change the terminology a little as well. In the opening statement (“all access may be considered privileged”) we’re really conflating entitlement with privilege.
An entitlement is the ability to do something (read your email, get your payslip from Workday, login to an application…)
A collection of entitlements may be consolidated into a role. e.g.
“Unix system admin” may be a role that has entitlements of “can login as
themselves”, “can sudo df” and similar. People will have multiple roles,
and some of what are sometimes considered “birthright”; e.g. as an “Employee”
you automatically are granted “Can read email”, “can get their payslip”.
Note that these are business roles and not technology roles. Windows has roles exposed as security groups (eg “Backup Operators”) which are collections of entitlements (eg “Backup files and directories”, “Restore files and directories”). It’s important not to consider these as roles from a business perspective; this is just a group of entitlements.
Note that entitlements and roles may be constrained in scope, and the larger the company the more likely this will be; e.g. “Unix system admins in North America” can not login to EMEA systems. This is why it’s important to distinguish business roles from technology roles even if they have the same name.
A role may be considered privileged if it allows members of the role to perform a business privileged action; “Bank teller” is a privileged role because members can see transactions for multiple people.
Finally a person is privileged if they are a member of a privileged role or if they have a business privileged action directly assigned to them.
So now we could validly argue that the first statement isn’t really accurate; not all entitlements are privileged so not all access is privileged.
This all comes back to the definition of “privilege” as a business function not a technology function.
Conclusion
This is hard work.
Defining and maintaining these roles isn’t easy; evaluating every entitlement to determine if it’s business privileged or not (or if the business accepts the risk of considering this non-privileged), whether the technology is capable of creating sufficient fine grained access is hard and time consuming. Role management, in particular, is very hard to get right.
Even if you don’t define privilege along business lines, thinking in business terms (business roles, instead of technology roles) can bring benefits; you gain some ability to provide minimum necessary access to systems, you can reduce audit overhead, access requests become simpler, access is more normalized and can be automated easier.
These benefits also apply to zero trust environments (indeed the rules may be made simpler) and to zero standing access setups (which can control if the entitlements are currently granted; your role determines what entitlements are available).