Lieberman Software
Monday September 1st 2014
Innovation Leaders in Privileged Management

Why Privileged Identity Management Implementations Fail

As veterans of the privileged identity management (PIM) field, my colleagues and I hear some unsettling stories from organizations whose privileged identity management deployments did not provide the expected business value. We’ve also heard from organizations whose purchases led to years of expensive service engagements yet never delivered the agreed scope of work.

At the heart of this problem is that many organizations seem to grasp too late that implementing a privileged identity management solution is too important a process to delegate to a rubber-stamp RFP or a battle of vendor check boxes.

If handled correctly your implementation can enable you to close critical security loopholes; help make staff members accountable for actions that impact IT service and data security; and lower the cost of regulatory compliance.

Yet the wrong choices too often turn into expensive shelf-ware – or worse.

The Simple Truth

The truth is that privileged identity management (or privileged account password management) software is not a commodity and should not be purchased based on checkboxes and up-front fees alone. Vendor claims to the contrary, not all solutions perform equally well under vastly different deployment conditions that can include:

  • wide varieties of managed computers – Windows, Linux, UNIX, and mainframes along with numerous network appliance platforms, backup infrastructure, and other hardware to be secured;
  • large numbers of frequently changing target systems that can be separated by slow, unreliable, or expensive WAN links;
  • significant numbers of custom-designed and legacy applications that might be poorly documented and whose designs may pose significant vulnerabilities if not properly remediated;
  • complex organizational structures demanding solutions with the flexibility to handle overlapping and frequently-changing lines of delegation and control.

If any of these scenarios sound like your organization, you should disregard all vendors’ claims and instead focus on:

  • trial deployments that encompass, at the very least, a test environment with a realistic sampling of your target systems, applications, and user roles;
  • engaging in in-depth conversations with reference customers whose deployments realistically match the diversity and scale of your own organization, and whose managed applications at least reasonably approximate your own;
  • getting the facts from those reference customers about true timeframes and back-end costs of vendor deployments so that you can budget your project accordingly.

As you proceed with your evaluation be aware that vendor checkboxes often lie. Craftily written marketing pieces can suggest that a product’s capabilities with respect to one target platform, application or deployment scenario extend to all areas where the vendor claims coverage, and salespeople often believe their organization’s own marketing hype.

Ask very explicit questions – both of vendor engineers and reference customers – about how individual target platforms, managed applications and use case scenarios are configured and deployed. In each case was the vendor’s capability delivered out-of-the box, only through custom development, or never at all?

How the Process Should Work

Your choice of a PIM solution should start with an honest discussion among all process stakeholders including the CSO, CIO, IT administrators, and anyone else involved in the management of sensitive accounts.  Your key stakeholders should be those that will suffer the most damage should the solution take too long to implement, unnecessarily add to staff workloads, or provide insufficient coverage. Define your project goals and then decide who on the team is best suited to determine whether each proposed solution is really a fit.

Be aware that privileged identity management requires not only the introduction of technology, but also some fundamental changes in how sensitive credentials are disclosed, changed and attributed to those who use them.  Regardless of whether a solution can lower staff workloads, individuals who once enjoyed unlimited, anonymous access will probably resist being held accountable. For this reason the project is likely to succeed only with the active sponsorship of top management.

You’d never choose a doctor based solely on cost, nor would you trust a physician who writes a prescription before taking the time to diagnose your condition, check your medical history, and perhaps run some tests. The same holds true for choosing a PIM vendor. Expect your vendor to provide:

  • a detailed, written analysis of your organization’s business goals;
  • explicit documentation of your needs with respect to systems, applications, and lines of control;
  • a trial evaluation of the proposed solution in a realistic test environment;
  • a clear statement of work that details the time and cost required to bring unsecured privileged accounts present in your target systems and applications under control.

The investment to license virtually any of today’s privileged identity management software is small compared to the cost of failed audits and leaving the organization vulnerable to external and internal attacks. Above all it’s the cost of a failed, protracted implementation that should be your motivation to perform every bit of due diligence you can, before your purchase decision is made.

Reader Feedback

One Response to “Why Privileged Identity Management Implementations Fail”

  1. Good piece. Few quick additions that come to mind:
    • Assuming that compliance is particularly high on your agenda, ensure that you clearly understand your compliance requirements in details before defining your solution requirements. As you know, compliance is a complex and shifting realm (and cannot be viewed as just one single “checkbox”). For example, identify the specific compliance controls that will need to be supported by the solution, and what type of support are you looking for (e.g., out-of-the-box reporting, enforcement of segregation of duties, password policies…etc). Also, is the solution flexible enough to extend and support additional compliance requirements as new ones get introduced?
    • Give more preference to solutions that capitalize on your existing investments and easily extend/integrate with your critical infrastructure (e.g., Active Directory, LDAP, you user provisioning tool…etc). This can be verified during the trial evaluation
    • Find out from the vendors what recommendations and best practice processes they offer on how to implement, maintain, and manage privileged identities

    Shirief Nosseir
    CA Technologies

Leave a Reply


− six = 3