A second commentary on Privileged User Management - Shared Account Password Challenges

In my first commentary on Privileged User Management, I suggested that organizations looking to implement Privileged Account Management capabilities should aim for the following initial goals:

• >80% the privileged user has tight access and privilege controls that are based on their centralized identity repository (90% of the time Active Directory in enterprises).
• <20% the privileged user may request the use of a shared account, and this is in the context of 
• activities tied to change control  (based on the environment or governance model)
• activities tied to break-glass scenarios
• specialized-purpose systems like network devices (switches, routers, etc)

I also noted that this is not based on any scientific research, just an initial goal, to be adjusted based on the circumstances of the enterprise.  

In addition, in the previous post outlined Centrify's value for privileged user management and showcased how DirectAuthorize can help achieve this goal in Windows, UNIX and Linux systems on premise or on public IaaS scenarios using Active Directory.  In this post, I offer my personal view on the state of the Shared Account solution space.

The other approach for Privileged User/Account management is Shared Account Password space (Gartner calls it Shared Account Password Management or SAPM).  These "vaults" are typically appliances with a secure storage and a web front-end;  they provide also additional capabilities like request handling and approvals, privilege session brokering, recording of the sessions as well.  These solutions are a must have in the modern enterprise.  I've seen organizations get by with highly-sophisticated and solutions as simple as a personal password wallet and a few scripts.  The bottom-line:  when it comes to shared privileged accounts (root, Administrator, Cisco enable password, oracle, etc) there's got to be a way to check-out, check-in, rotate and enforce policies.  I will use the terms vault, jumpbox or SAPM when referring to these solutions.

I've had the chance to speak to many customers and prospects that use shared account password solutions today, and here's the consolidated set of challenges that exist:

• The shared account password management solution is not really protecting their systems
  Keep in mind, the whole goal of information security solutions is to protect information;  when you have a SAPM solution, unless you add complexity to your environment (like firewall rules to make sure all remote sessions are initiated via the jumpbox), the SAPM solution is not really protecting their systems, it's managing passwords, brokering checkouts and rotating the password based on rules, that's it.  The only real way to to protect the system itself, is the existing network client in the box.  If the box only has one human account which is privileged  (like in the case of some network devices) then this solution is perfect; otherwise, if the system has several local and network human users it becomes evident that other mechanisms for access control have to complement these solutions.
• Lowered productivity of their privileged users
  When an organization uses a SAPM solution as the only means for privilege management, a few things become evident:
  a) organizations realize that they have created a bottleneck
  b) end-users start seeing it as being "on the way" of their day-to-day tasks and start trying to find ways to "get around it" or simply, if the rules are very relaxed, "camp" with the privilege credential as long as policy will allow them.
• Most of the time, the SAPM solution itself becomes another identity silo
  Yes, at the beginning it's hard to notice it, but although some have some degree of AD integration, it only exists for the purposes of correlating the AD account's information with their internal identifier.  Ultimately, the identity silo is the shared account and the current encrypted password.
  Any smart organization is looking to decrease identity repositories not looking forward to add new ones.
• Added burden for Security Operations
  When you use a vault or SAPM solution, only the software or appliance knows who had a shared account, when and for what length of time, it will also know in which systems it was used as long as the session is initiated from the jumpbox.   This means the log aggregation and intelligence tools need to be tightly integrated with these solutions.
• Expensive and Inflexible
  The form factor for these devices is typically an appliance; appliances need to be procured, installed, made redundant and available anywhere there's a concentration of privileged users or anywhere the organization has a large set of systems.  These vendors may have complex licensing schemes as well.
  Many organizations think that they will gain time by using a password-first approach, only to realize that it's been months after the PoC and their device isn't ready for prime-time yet.  Also, what about the systems that exist in IaaS infrastructure (e.g. Amazon, Rackspace, Azure, etc).
• As a sole strategy, does not meet security regulations
  We've had the chance to work with highly-regulated prospects and customers that had to rethink their strategy completely due to audit comments and because they thought that a vault was going to address all their regulatory needs (reasons vary between were told by vendor, thought it was an easy way out, just wanted to overcome an audit comment, did not really do their do diligence etc.); the ultimate reality is that you need a password centric approach for the appropriate use case; but that in itself won't be enough.  Unfortunately, highly-publicized data-breaches have a component of "taking advantage of poor password-related practices" but due-diligence is the implementation of preventative, corrective and detective controls around all risk information areas.   
• Legacy remote session access
  Although these solutions do provide RBAC (privileged users can only see the systems that they have access to, and can request access to new ones), however, if a privileged user is remote, they still need VPN connectivity to get to the jumpbox,  another solution  (Citrix-like) or presence on the DMZ.  
• Closed and capability-complacent
  Another challenge with these systems is that although many are feature rich, reliable and mature, they have the same issues of appliance vendors - they are slow to react to market/customer needs (to be fair, not all vendors are the same).  This is due to an enjoyed leadership or simply because the software lifecyle for appliances is slower than traditional software vendors.  Also, because extra, expensive appliances are needed for testing, implementing new features is always higher risk than they good old: "if it ain't broken, don't fix it"; however, the modern enterprise is very dynamic, and this type of thinking is not present in companies that lead, but in companies that follow.  Following may mean to many companies the loss of market share or in the case of security: data breaches.

In the next post I will talk about Centrify's Privilege Service (CPS).  This product has been around since May 2015, and it was built to address the need of these use cases (that I propose should only be the approach 20% or less of the privilege user interactions).  In addition to continue to add value, you'll discover how Centrify has listened to existing customers that have vault solutions to overcome the challenges outlined above.