So far we have described the Restrict Access and Protect Credentials aspects of the Privileged User Lifecycle. So far any administrator managing a device is authorized to be there and uses strong credentials. But what happens when they get there? Do they get free reign? Should you just give them root or full Administrator rights and have done with it? What could possibly go wrong with that?

Clearly you should make sure administrators only perform authorized functions on managed devices. This protects against a couple of scenarios you probably need to worry about:

  1. Insider Threat: A privileged user is the ultimate insider, as he/she has the skills and knowledge to compromise a system and take what they want, cover their tracks, etc. So it makes sense to provide a bit more specificity over what admins and groups can do, and block them from doing everything else.
  2. Separation of Duties: Related to the Insider Threat, optimally you should make sure no one person has the ability to take down your environment. So you can logically separate duties, where one group can manage the servers but not the storage. Or one admin can provision a new server but can’t move data onto it.
  3. Compromised Endpoints: You also can’t assume any endpoint isn’t compromised. So even an authenticated and authorized user may not be who you think they are. You can protect yourself from this scenario by restricting what the administrator can do. So even in the worst case, where an intruder is in your system as an admin, they can’t wreck everything.

Smaller organizations may lack the resources to define administrator roles with real granularity. But the more larger enterprises can restrict administrators to particular functions the harder it becomes for a bad apple to take everything down.

Policy Granularity

You need to define roles and responsibilities – what administrators can and can’t do – with sufficient granularity. We won’t go into detail on the process of setting policies, but you will either adopt a whitelist approach: defining legitimate commands and blocking everything else; or block specific commands (a blacklist), such as restricting folks in the network admin group from deleting or snapshotting volumes in the data center.

Depending on your needs, you could also define far more granular polices, similar to the policy options available for controlling access to the password vault. For example you might specify that a sysadmin can only add user accounts to devices during business hours, but can add and remove volumes at any time. Or you could define specific types of commands authorized to flow from an application to the back-end database to prevent unauthorized data dumps.

But granularly brings complexity. In a rapidly changing environment it can be hard to truly nail down a legitimate set of allowable actions for specific administrators. So getting too granular is a problem too – similar to the issues with application whitelisting. And the higher up the application stack you go, the more integration is required, as homegrown and highly customized applications need to be manually integrated into the privileged user management system.

Location, Location, Location

As much fun as it is to sit around and set up policies, the reality is that nothing is protected until the entitlements are enforced. There are two main approaches to actually enforcing entitlements. The first involves implementing a proxy in between the admin and the system, which acts as a man in the middle to interpret and then either allow or block each command. Alternatively, entitlements can be enforced on the end devices via agents that intercept commands and enforce policy locally.

We aren’t religious about either approach, and each has pros and cons. Specifically, the proxy implementation is simpler – you don’t need to install agents on every device, so you don’t have to worry about OS compatibility (as long as the command syntax remains consistent) or deal with incompatibilities every time an underlying OS is updated. Another advantage is that unauthorized commands are blocked before reaching the managed device, so even if the attacker has elevated privileges, management commands can only come through the proxy. On the other hand the proxy serves as a choke point, which may introduce a single point of failure.

Similarly, an agent-based approach offers advantages such as preventing attackers from back-dooring devices by defeating the proxy or gaining physical access to the devices. The agent runs on each device, so even being at the keyboard doesn’t kill it. But agents require management, and consume processing resources on the managed systems.

Pick the approach that makes the most sense for your environment, culture, and operational capabilities. At this point in the lifecycle privileged users should be pretty well locked down. But as a card-carrying security professional you don’t trust anything. Keep an eye on exactly what the admins are doing – we will cover privileged user monitoring next.

Share: