Americas

  • United States

Asia

Oceania

Privileged Identity Management: 7 tips to make it work for you

Tip
Nov 17, 201012 mins
Access ControlData and Information SecurityIdentity Management Solutions

PIM tools help get a handle on sprawling accounts and disjointed management of privileged access. If you do it right. Here are seven key strategies.

For more background on PIM, see the companion article Too much access? Privileged Identity Management to the rescue.

Develop a long-range and short-range strategy. While your organization may be addressing particular pain points—an audit failure on a particular platform or in a business group, operational problems with a manual process, production interruptions or a data breach inadvertently or intentionally caused by someone with shared credentials—lack of PIM is usually a systemic problem that touches all enterprise systems.

If you choose a PIM product to address a limited objective (for example, pass the next audit or control access to a CRM system), you may wind up buying a solution that will not meet all your needs.

“Shared accounts pose almost the same risk regardless of whether it’s a shared DBA [database administrator] account giving access to a database, or an admin accessing a Cisco router, or a shared-account e-mail admin accessing an Exchange server,” says Cyber-Ark Executive Vice President Adam Bosnian. “If I can use the system, as an admin, to do my bidding, I have a powerful tool to do some real damage.”

Unless you take a global approach, you will not understand how your disparate systems are interconnected and dependent on one another. You will fail to develop policies and processes that will form an effective foundation for your privileged-identity program.

So invest in PIM with the big picture in mind. Take a broad view and develop an enterprise strategy. Then you can prioritize where you will start your implementation based on which systems, applications and platforms, or class of privileged users (such as Windows sysadmins or DBAs) pose the greatest risk, will affect the largest number of users, and so on. Take a phased approach based on a broad, long-term strategy. Each phase is a significant project and will benefit from a strong overall direction and experience in preceding phases.

“You need to take comprehensive look; when you get into IT departments everything is connected to everything,” says Jeff Nielsen, vice president of engineering for BeyondTrust. “Here’s the financial database connected to the CRM database, which is connected to an order-fulfillment app. There’s sensitive data throughout the chain.”

A broad plan with a staged implantation will also help demonstrate to auditors that you have a program and tools in place to that will address shortcomings on a defined schedule.

Require full-platform coverage. A global strategy requires global applicability. You may be focused on Windows administration, for example, in your initial phase, but what about the Unix and Linux server accounts you plan to address in the third quarter? Is your company standardizing on one database platform or network infrastructure vendor, or do you expect to have a heterogeneous environment for the foreseeable future? How will mergers and acquisitions affect the types of accounts you will need to manage?

“We looked at some applications that don’t mange the full breadth of Unix and Linux, or they only do Windows, or they don’t do SQL Server,” says an information-security analyst for a large federal credit union, which is a Lieberman Software customer.

Also consider the difficulty and cost involved in supporting custom applications.

Leverage integration with your existing resources—PIM doesn’t exist in a vacuum. In particular, make sure the PIM products work seamlessly with your identity management (IdM) systems and directories to automatically provision and de-provision user privilege according to corporate policy.

That policy should be reflected in your active directory group memberships or other directory repository of choice, and in role-based provisioning through your IdM. The PIM should automatically update in real time or as close to it as possible to reflect changes in group memberships and assigned group and individual user roles. These assignments can be highly dynamic, as employees are hired, leave, change jobs within the organization, or are granted temporary roles based on need.

One essential difference between IdM and PIM products is the problem of shared privileged accounts, since shared accounts cannot be tied to an individual. PIM addresses the issue by eliminating the need for shared accounts and their shared passwords by controlling access based on individuals’ functions as defined by their roles. So tight integration with IdM is important if PIM is to be effectively automated and scale throughout the enterprise by leveraging existing identity policy and mechanisms.

These policies and their associated processes should include a well-defined change-approval workflow that can be effectively automated, so tight native integration with your ticketing system is another key point to look for. So, for example, when an admin requires authorization to modify the rule sets on a group of firewalls, the access request triggers a well-defined and automated workflow-approval process based on policy and managed through the ticketing system.

Security information and event management (SIEM) integration can also be quite valuable. Since PIM ties administrative privileges to individuals, your SIEM can correlate this information with data from other security systems to detect and analyze anomalous and possibly malicious activity tied to individuals rather than shared, anonymous accounts. Or, if the user has not gained privileged access through the PIM, it may indicate a hacker or automated attack.

Assess your existing processes. Evaluate your existing policies, processes and mechanisms for managing privileged identity, understand the pain points and determine if purchasing and implementing PIM is going to effectively address those issues.

“If the organization has a well-defined process, product deployment is a slam dunk,” says Kris Zupan, e-DMZ’s CTO. “If the existing process is a root password that hasn’t changed in four years, trying to initiate process in addition to adding technology is another matter.”

PIM is of limited value unless it is implemented on a foundation of well-defined policies and processes, which provide a clear understanding of corporate requirements, including:

  • The business requirements for privileged access, defined by system, business unit, and so on.
  • Who should be granted privileges as a matter of course and the circumstances under which exceptions may be made.
  • What level of privilege is actually required, for how long and under what circumstances.
  • The rules for provisioning and de-provisioning privileged access and authorization.
  • The approval workflow process, including verification and audit trail.
  • The triggers and responses when requests or attempts to access violate corporate policy.

“You probably fall short in managing privileged identity,” says the security lead for a midsize manufacturing company, “if the processes you run and the benchmarks you hold yourself to are not well defined or aligned with standards, and if you are not aware of and assessing yourself in terms of those.”

That said, there is some value in a preliminary deployment of PIM software to help determine your organization’s current security posture regarding privileges. It can serve as an initial step toward developing a sound program supported by appropriate technology. If the product has auto-discovery capabilities, you can gain insight into where all your privileged accounts are—there are probably thousands of them, many of which may still be using default admin passwords—and begin to assess how they are shared and used to develop policies and processes for reining them in.

If your privilege-management program is largely manual, examine the weaknesses in your procedures from a security and audit perspective, and consider the cost of the resources dedicated to maintaining it.

“I’ve run into companies that have very successful manual implementations, but there are number of downsides in terms of implementation,” says Phil Lieberman, president and CEO of Lieberman Software. “Some change processes, in terms of retrieving passwords, take 10 to 40 hours.”

For example, organizations will often rotate and secure privileged passwords by committing them to paper and locking them in safes. The problem is, the passwords are still known and can be shared, even if corporate policy says they shouldn’t be, and the time and effort required to repeat this process according to a regular password-rotation schedule for hundreds or thousands of passwords is daunting. Often, change records, authorization requests and fulfillment are managed by spreadsheet, which becomes a bottleneck that can impede business.

Also see How to compare and use legal hold software

Manual systems are, of course, subject to human error and can be bypassed, and are difficult or impossible to prove to an auditor. Moreover, a single system will often have a number of services that are dependent on the password change.

“Our Blackberry Enterprise Server has administrative passwords associated with 28 services,” says a federal credit union analyst. “If had to change the BES password, find the associated services, and change them all by hand, we would lose a key productivity tool for an extended period of time.”

Manual processes may be linked to role-based provisioning, directories and ticketing systems by policy, but can fail because there is no automated dependency management.

Consider the scope of workstations. Local administrator privileges on Windows clients can create security risks and pose operational problems. Users with local admin rights can install applications and make configuration changes that put their computers at risk of being compromised in a way that could extend to other workstations and to sensitive data stores. These changes can also cause functional problems that put a strain on your help desk.

“If you need local admin rights, our first response is, ‘What for?'” says a security officer for one of the world’s largest financial institutions, a BeyondTrust customer. “If you just need to change the clock on your laptop because you travel, we’ll put you in a group for that. You don’t to need to run Regedit or install software.” The initial solution, he says, was to require everyone who felt they needed local admin rights to submit a request; as a control, a home-grown script scanned workstations hourly to see if local admins had been added. Any additions were reconciled with the request system.

One problem, he says, was that users could still violate policy and get local admin rights between scans. More important, he says, was the audit problem. “Reacting to the problem doesn’t solve the problem,” he says. “From an audit perspective, we need to have very detailed records of who has local admin rights and how we are managing them, and [to be able to] prove that the person is removed.” The PIM tool, he says, has allowed the company to effectively remove and prevent unauthorized local admin rights in a way that’s transparent to end users.

Include outsourcing in your PIM policies and processes. Enterprise responsibility for data security doesn’t stop when you outsource IT management, development and infrastructure. You need to be concerned with and extend privilege-management to service providers, from the vendor managing corporate firewalls to the infrastructure-as-a-service cloud provider hosting storage, networking, and networking equipment in support of your operations.

In these common scenarios, concern over privilege extends, for example, to the service providers you let in to remotely manage your on-premise systems as well as the nameless admins working for the cloud-service providers who lay hands on your remote infrastructure. These service providers should be in scope for your policies and processes, and, where possible, controlled through your PIM product. This will require buy-in by the service provider to require its admins to adhere to your corporate policy and be managed by its supporting technology as a condition of doing business. In addition, look for service providers that have well-documented and -audited PIM processes and technology.

Get buy-in from IT, business units and management. This is always sound advice when implementing any new security technology, but perhaps even more important when you’re dealing with privileged accounts.

“I’ve been in IT for about 15 years, and PIM has been an issue all along,” says the credit-union analyst. “I’ve always wrangled with how to handle changing passwords—most IT folks, when presented with that, don’t want to deal it. They don’t understand or don’t see why.”

The issue is in the evolution of privileged access from the mainframe era, in which a core of trusted admins were the only ones who needed accounts and had to know the passwords, to a Windows-based client-server environment and then to the exposure of business applications to the Internet.

“It’s kind of a badge of pride in admin ranks that they know privileged passwords and that the company trusts them,” says BeyondTrust’s Nielsen. “A lot of admins are starting to understand, but there’s a lot of pushback from the technical community: ‘I’ve known the password for 10 years and never misused it.'”

Both IT and the business units they support have to be brought into the discussion from the beginning. The assumption that all the people who have unfettered and unlimited administrative access need it for the sake of the business must be dispelled. You are up against longtime practices, concern over turf, and the fear that business will be impeded and key applications broken if privileged users and accounts are tightly controlled.

This will require you to explain the security and operational issues posed by poor privilege control, point out the applicable regulatory requirements, and demonstrate that the processes and technology will make IT and the business function more smoothly. Above all, you’ll need support from management.

“For us, one of the key items was making sure that what we were working on, from technical point of view, was aligned with and supported in terms of funding and priority with senior managers,” says the manufacturing company security lead. “You have to have enough of a clear business case, based on risk assessment, to get clear support from the executives who control the purse strings.”