A commentary on Privileged User Management

A commentary on Privileged User Management

When I visit customers and prospects, I see an amalgam of priorities, knowledge, organizational dynamics, but most commonly complexity and a feeling that most people don’t know where to start. Ultimately the decision is simple.  There’s no access controls without a consistent identity store.

I’m also surprised on how easy analysts are influenced by vendors. Let’s take for example the topic of passwords; I've  always conceded that shared account password management is needed in the enterprise, but that it only applies in break-glass scenarios, change control or network devices; however, vendors in their effort to expand have positioned their solutions as the “end-all-be-all” (regardless of the true need) which to me is a disservice to the customer or prospect.

My personal philosophy is clear, least privilege management is the right way to go because it applies in most of the cases (the cases would be larger if network devices had better AD integration); however, now that Centrify is in the SAPM business as well, I feel it’s my obligation to position it, but in its proper context and use cases.  This is validated by the fact that most data breaches have components of credential theft; threat agents are counting on somebody that has more power than they should have, to get to the sacred keys of the kingdom.

Here’s what I propose to readers of this post, (I will be the first to admit that I’m just reusing the 80/20 rule) but, I think that if 8 out of 10 privileged actions are part of my day-to-day job and they have been defined with a privileged elevation mechanism, I’m quite happy.  This is becoming increasingly important on Windows, where admin account (e.g. “-a”) accounts are no longer the best practice.  On UNIX/Linux privilege escalation has existed for years in the form of sudo.  What you’re trying to avoid here is that if you implement a password-centric system, users will naturally “camp” or will try to get around the proxy system (forcing the implementation of complex network rules).

This should settle the whole “what’s my goal post” question, and ultimately, it’s up to the organization dynamics to determine if this is a realistic and attainable goal.

Least Privilege Management - Where do I start?

Ultimately, the game it’s all about control.  Here’s a playbook that I often share with customers and prospects:

• First, you have to start with a Common Identity (e.g. AD)
• Then you have to be able to group systems based on a security governance model
  (e.g. web servers, database servers, PCI servers, Financial Systems)
• Implement granular access controls:

• Define where the user can log in as part of their job functions 

• Define how the user can log in to systems (E.g. SSH but not console;  RDP but not console)

• Define any time effectiveness of a role  (E.g. Backup guy should only run tar as root from 5PM to 6AM

• Reuse Processes

• Assign roles to AD groups

• Manage memberships or requests via your ITSM or workflow tool.

• This way you can use that tool for attestation as well.

With least privilege, where I see customers often think that the task will be very large because they must identify and catalog the tasks that users are performing with privilege; but the view is a bit myopic because those things are managed and it is after all a capability (people-process-technology) that should have its own road map.

At Centrify we suggest this:

1. Start with a “broad scope” but with a simple goal:  Eliminate shared account usage.  Maintain status quo as it relates to super users.  Allow them to elevate as root/Administrator; but deny them the knowledge of the password.  
2. As you are able to increase accountability, then start “narrowing the scope”; e.g. “What’s does a Database guy do, with privilege in their day-to-day?” 

As you move to this model, concede that there will be areas of improvement (hence the need for feedback and a road map). This is another area where customers and prospects have misaligned expectations;  you will have to work on privilege management all the time, this is not a "set it and forget it" type of deal.  There are governance and operations components, there's attestation

The other 20%, perhaps break/glass, or access to production systems, I’m happy with proper workflow/approvals and change control.  Otherwise I’m getting in the way of the user’s productivity and they will try to find ways around the “broker” system.

The ever-expanding definition of a Privileged Account

It's not just about root, Administrator, oracle, apache, jboss or xyz service/privileged account.  Your privileged users exist everywhere.   What about your social media accounts?  The embarrassment of losing control of these accounts is evident every day for corporations;  the same with SaaS applications.  Isn't the Sales Admin in Salesforce, or the Finance or CFO lead in Netsuite a privileged user?

In a hybrid enterprise, the rules have changed;  however, I believe that Centrify has you covered.  In the next post we'll continue this series and we'll talk about the Centrify value in the context of Privileged User Management.