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.

Centrify's Value Proposition - Part 3: Privileged User/Identity Management with Least Priviliege

In the third part of this series, we'll discuss how Centrify provides solutions for privileged user/identity management and maintains these principles:

a) Eliminates identity silos

b) Implements strong access controls without interfering with the user experience

c) Use what you have: infrastructure, processes, knowledge (less IT fragmentation)

d) Promotes operational efficiency

e) Provides strategic value, rather than tactical solutions

Organizations come to Centrify for privileged identity management or privileged user management because of combinations of the following challenges or circumstances:

•  Overall: They want to increase accountability and implement strong privileged user identity and access controls based on a common identity repository.
• They have Active Directory and multiple platforms, but primarily for UNIX, Linux and Windows
• They have a traditional (on-premise only) or hybrid (public/private cloud) enterprise
• They want to eliminate the use of shared credentials or persistent administrative accounts (root, administrator, “-a”, etc)
• Their existing solution does not provide flexibility on grouping systems based on a security governance model
• They might have chosen to implement a password-centric approach as their unique strategy and they’ve come to realize that their users are less productive (or supportive), that they’ve duplicated identity silos and that ultimately, their systems (the main goal) aren’t protected by it.
• On UNIX: They understand that using sudo/sudoers, although it’s mature may not be enough for high-risk, highly-regulated enterprises; they are tired of the complexities of managing a sudoers file and want more granularity and flexibility
• They want a higher-degree of control on how their users access systems (beyond just granting/denying access) cross platform.
• On Windows, they want to eliminate the problem of the Local Administrator, are conscious of the “pass the x” attacks and want to eliminate the “camping” issue with “-a” accounts.
• They need to provide separation of duties (operational rights vs governance rights)
• They need timely reporting of who has access to what system(s), what are their privileges, and what granted them access to do this.
• They don’t want to deviate from existing processes or realized that by implementing point solutions or “best of breed” they ended-up fragmenting their IT in the context of processes.
• They have regulatory requirements that they need to meet or exceed.  These may be SOx, PCI DSS, HIPAA, NERC, FERC, etc.
• They want to solve the Shared Account Password issue, but they want a solution that reflects the state of modern trends (they hybrid datacenter, IaaS, mobile-first, etc)
• They have high-security requirements like FIPS, solutions common-criteria certified, perhaps they rely heavily on Smart Cards.
• They want log aggregation that is simple to their native tools (ARCSight, LogLogic, Splunk, etc)
• They may need to go beyond the traditional security operations and provide session capture and replay from anywhere (remote or via console) because today they don't have that capability, are required to have it or simply, they might have gone the "jumpbox" route to realize that they are missing crucial sessions.
• They hate having to invest in multiple solutions to enforce the same basic security principles.  Each time they do, this may mean:
  - Evaluate a product
  - Invest or procure new hardware or software
  - Add additional infrastructure
  - Train or hire specialist
  - Maintain the solution down the road
  - Manage the vendor relationship

Here's a technical demonstration on how Centrify delivers this value:

The key differentiation areas are:

• AD Orientation - implemented in more of 90% of enterprises, users use a unique identity.
• Centrify Zones - unique patented way to create groups of systems in Active Directory
• Granularity of Access Controls - control HOW users log in to systems
• Granularity of Privileges - no need to know the privileged account password.
• Simple privilege elevation:  sudo-like tool in UNIX/Linux, shell and command line on Windows.
• No proprietary magic on how events are stored: no need to have a central system just to know who did what and when - need to rely on a central system to correlate who had a privileged account.
• Quick attestation and robust reporting - the data is in AD.
• Separates the operational tasks versus the governance tasks - to enforce SoD
• Works in multiple core platforms:  UNIX, Linux and Windows
• Protects your systems: Provides end-to-end enforcement of the rules as well as session capture and replay.

Finally, the end user experience is not affected, no identity silos are created  and your AD infrastructure, processes and technology are reused.  We propose that the "least access/least privilege" approach to Privileged Identity/Super User Privilege Management should be used at least in 80% of the use cases.

In the next post we're going to talk about the next 20%, this includes Shared Account Password Management, Proxied/Brokered/JumpBox initiated sessions (what gartner calls Privilege Session Management).

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.

Centrify's Value Proposition - Part 2: The hybrid and heterogeneous enterprise

Organizations with traditional (on-premise) and  hybrid (private/public cloud) with Active Directory, come to Centrify because:

• They have diverse platforms (UNIX, Linux, Macs) in their enterprise (on-premise and in the cloud).
•  They are looking to Centralize the administration (or implement effective controls) for user access in those different platforms.  Their reasons may be due to security, regulation, operational efficiency or simply because they are reacting to an audit or other event.
•  They are also looking to leverage the secure authentication methods provided by Active Directory. 
•  They are looking to find a way to effectively manage UNIX identities by using Active Directory, but preferably, they don’t want any schema extensions to AD or software loaded in Domain Controllers.
• Some other organizations (and this is quite common on the Mac side) are looking for a more robust way to support AD integration and are also looking to use a common management framework (like Active Directory Group Policies) to enforce security policy or configuration management policies.
• Other organizations are looking to focus on their core competencies because perhaps they invested a lot of engineering cycles using open source software (like Samba/Winbind, RedHat’s SSSD, OpenLDAP with MIT Kerberos) and realized that the speed of requirements and diversity of platforms does not align with their goals.  (E.g. a Financial organization spending hundreds of man hours on “manual” identity and access controls rather than portfolio analysis).  These types of organizations are ready for a solution that “just works”
• Organizations want solutions that are friendly to private/public cloud scenarios; this means a toolset that promotes automation.
• The organization may have high-security requirements like smartcard authentication, FIPS encryption or common-criteria certified solutions
•  Finally, some organizations tried to wait as long as they can keeping the status quo; and a compelling event has made them change like:

• Change of leadership

•  A merger or an acquisition

•  A new technology (like BigData)

•  Acknowledgement that advanced persistent threats can’t be ignored

•  Another solution isn’t providing timely updates, proper support or their future is uncertain

• An audit or data-breach

•  Perhaps there’s an old infrastructure (e.g. NIS, LDAP) that found fresh blood that isn’t afraid of “touching the server, who knows what will break”  <= yes, this sadly happens.

Everything I outlined above is core of what some analysts call “Active Directory Bridging” but when you look at it is much more; it is the basis for implementing critical access controls and a management framework that is based on reuse of existing infrastructure and processes rather than point solutions.  It’s also the foundation of making sure users can do their work, without interrupting their flow.

Here’s a technical demonstration on how Centrify provides value:


 A very unique capability that is exclusive to Centrify is the zones technology.  Nobody else can do what Centrify does to group systems in a hierarchical way while consolidating UNIX identities for Users, Groups and NIS Maps.

Note that also, a large number of "born-in-the-cloud" organizations are coming to Centrify for Web Application SSO and Enterprise Mobility.  We will cover that in other entry.

In the next post, we'll focus on how Centrify builds on their AD bridging capabilities to provide Privileged User Management on UNIX, Linux and Windows and how it uses it's Identity Platform for secure access and shared account password management.