Rechercher
Contactez-nous Suivez-nous sur Twitter En francais English Language
 

Freely subscribe to our NEWSLETTER

Newsletter FR

Newsletter EN

Vulnérabilités

Unsubscribe

Phillip Lieberman, president and CEO of Lieberman Software: Why Privileged Identity Management Implementations Fail

January 2011 by Phillip Lieberman, president and CEO of Lieberman Software

You have security firewalls and antivirus tools. You have role-based access controls and identity management software. You probably even have regulatory compliant applications. But how safe are the servers, storage devices, and network appliances that actually host your data? At this moment can any administrator login to your systems, read and modify records, change device settings, install new code… and more? If there’s a breach, will you know who is responsible? How will you track who did what to which system, and when? Without a method for managing the privileged identities for every system in your network, you are vulnerable to all of these threats posed by unauthorised users and malicious programs.

What are Privileged Identities?

Privileged identities are accounts that hold elevated permission to access files, install and run programs, and change configuration settings. They exist on virtually every server and desktop operating system, business application, database, Web service, and network appliance in your organization.
The ability to manage the accounts that allow privileged access – whether called privileged account password management (PAPM), privileged user password management (PUPM), or shared account password management (SAPM) – is a subset of the broader Identity and Access Management (IAM) category. However, conventional IAM solutions are designed to manage typical end-user account activities (such as provisioning and de-provisioning users, managing login activity, and granting single sign-on rights) and cannot discover or control privileged identities.

As the pioneers of privileged identity management, we at Lieberman Software hear some unsettling stories from customers who purchased other vendors’ solutions. We frequently hear complaints that other vendors’ products:

• Become slow, unresponsive, or difficult to manage when deployed on large networks;

• Don’t complete password changes reliably and fail to report potentially serious error conditions;

• Don’t adequately keep up with changes on the customer network, lapsing in coverage even after predictable changes occur in systems and applications;

• Are sold with low up-front license fees and the promise of easy implementation, only to turn into vastly more expensive, open-ended services engagements;

• Have deployments that result in higher staff workloads and simply fail to perform.

In particular, customers have told us about purchases that led to years of expensive service engagements yet never delivered the agreed scope of work.

The simple truth is that today virtually all IT staff enjoy anonymous, unaudited 24/7 access to your datacentre applications, computers and appliances through use of privileged account credentials. More IT auditors are beginning to notice that this lack of accountability has brought organisations out of compliance with key industry mandates – PCI-DSS, HIPAA and others. The hackers have also taken notice, exploiting these all-powerful and often poorly secured credentials in many of the latest, headline-grabbing breaches that include the attacks on Google and other US technology firms.

Many organisations seem to grasp too late that implementing a privileged identity management solution is too important a process to delegate to a rubber-stamp Request for Proposal (RFP) or a battle of vendor checkboxes. If handled correctly your implementation can help you close critical security loopholes; help make staff members accountable for actions that affect 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 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 organisational 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 organisation, you should downplay 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 organisation, and whose managed applications at least reasonably approximate your own;

• Getting the facts from those customer references 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 many vendor checkboxes simply lie. Craftily written marketing pieces can suggest that a vendor’s capabilities with respect to one target platform, application or deployment scenario extend to all areas where they claim coverage, and salespeople often believe their organisation’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?

More than a Commodity

Here is a scenario that is guaranteed to go wrong: an organisation needs to remediate its processes for managing privileged accounts following a disastrous auditor finding. The organisation has 30 years’ worth of legacy hardware and software to be secured and an ill-defined organisational structure for controlling access and managing change. Management’s goal is to purchase the lowest-cost, appliance-based solution they can find that offers a money-back guarantee and the promise to eliminate those audit failures.

Management assigns a project team to develop an exhaustive RFP spreadsheet that is typically culled from various analysts’ findings. The RFP is sent to a handful of vendors with the request that they provide all information and supporting documentation in two weeks’ time.

How the Process Should Work

Your choice of a privileged identity management 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 determine who on the team is best suited to determine if 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 privileged identity management vendor. Expect your vendor to provide:

• A detailed, written analysis of your organsation’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 organisation 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.


See previous articles

    

See next articles


Your podcast Here

New, you can have your Podcast here. Contact us for more information ask:
Marc Brami
Phone: +33 1 40 92 05 55
Mail: ipsimp@free.fr

All new podcasts