You need to manage the privileged identities

You need to manage the privileged identities for every system in your network You need to manage the privileged identities for every system in your network

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.

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 and cannot discover or control privileged identities.

Lieberman Software 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.
• Purchases that led to years of expensive service engagements yet never delivered the agreed scope of work.

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.

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.

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 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 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?

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.

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.

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.

Expect your vendor to provide:
• A detailed, written analysis of your organisation’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.

Opinion piece submitted by Phillip Lieberman, president and CEO of Lieberman Software