Why privileged account management is hard to scale

Why privileged account management is hard to scale

Date: Jun 20, 2014

Many companies do a better job of managing user accounts and passwords than they do of managing the elevated privileges often shared among administrators. According to recent surveys, these practices continue despite the fallout from the high-profile breach of the National Security Agency by Edward Snowden, a former contractor who leaked sensitive information. How can companies securely allow employees to perform tasks that require elevated permissions?

Privileged identity management (PIM) tools enable security professionals to monitor super user accounts and change the credentials on targeted platforms. The mechanisms for discovery and changing embedded passwords can be interactive or programmatic. These tools are often integrated with SIEM and identity management systems.

"There is an entirely different class of identity, known as the super user accounts," said Philip Lieberman, president and chief executive officer of Lieberman Software, in an interview with SearchSecurity at the 2014 RSA Conference. "These are also sometimes called root or administrator, but these are generic accounts. There are also cases where regular user accounts have taken on different attributes or additional power, and in fact have become pseudo super user accounts. [You] would have a user name, which might be associated with a service."

At many organizations, no one is really managing these machine accounts, according to Lieberman, who noted that applications are using these identities and they don't respond to emails or change passwords. In these scenarios, IT and security professionals need to list all of the organization's machines and identities to determine which ones are associated with users, super users and service accounts.  

Once the organization has identified these accounts, IT needs to implement a process to manage those identities and figure out where those credentials are being used. In small organizations, this can often be done manually, according to Lieberman. But for enterprises -- especially those that use virtualization -- the task can be a lot harder. Mergers, acquisitions and widespread outsourcing, which can lead to contractors with elevated privileges to multiple systems, have also contributed to a general loss of control and attribution. Privileged identity management at scale can be hard to do, and tools can help automate the discovery and the change process.

"Today, most organizations are either trying to do this by hand or they are trying to coerce a vault-type of a solution that is effectively a password spreadsheet that stores this information and then trying to merge scripts together with it, and it is pretty hard to do at scale," said Lieberman.

Security professionals need to have a privileged account management process in place and then have the mechanisms to enforce it.

Kathleen Richards: I'm Kathleen Richards from Information Security Magazine and SearchSecurity.com. Thanks for watching this video. Joining me today is Philip Lieberman, Founder and Chief Executive Officer of Lieberman Software. Philip, it's great to have you with us.

Philip Lieberman: Great. Thank you.

Kathleen Richards: Let's talk about privileged identity management or PIM technology, for a few minutes. Many companies seem to do a better job of managing standard user accounts and passwords than privileged accounts. Why is that, and do you see this trend changing?

Philip Lieberman: Sure. The world really is broken up into two different types of identities and completely different ways of managing them. When you think about the typical user experience, you're typically set up using the provisioning system so when you join the company you are given an account. You're getting a password, and then you have a series of processes of attestation and password change that are required. You receive emails for all of these changes, and there's an entire process that's part of G.R.C. that used to manage the lifecycle of a typical user. On the other hand there's an entirely different class of identity that exists known as the super user accounts. These are sometimes called root or administrator, but these are generic accounts. There are also cases where regular user accounts have taken on additional attributes or additional power and in fact become pseudo super user accounts. So we would have a user name which might be associated with a service, and the difference between these accounts that we're talking about, the so called super user accounts and the regular user accounts is that these are machine accounts. And as machine accounts, there's nobody really managing them. There's nobody to talk to. It's really the applications that are using these identities, and they simply don't take email. And they don't change their own passwords. And so it's really up to IT to do a few things. One, they need to characterize the list of machines they have. First, having a good list is great. Secondly, they need to characterize all identities, and then they need to understand how all those identities are being used. Which ones are being used for users and which ones are being used for the so called super user or service accounts. Now once they've identified them, they then need to have a process to change the identities. And so in a small organization you normally do this by hand, but in a large organization or one that's using virtualization to spawn lots and lots of images. The job of identifying and changing those credentials, and by the way, it's not even just changing the credentials that's a challenge; we'll get to that in a second. But if they change the passwords on those credentials, they also have to change them where they're being used which means you have to go in things like services, DCOM, MTS, scripts, and these have to also be modified. So the challenge for IT and the challenge for security is number one, having a really good source of information that is up-to-date which is hard to do by hand. And then the second characteristic is having the domain specific knowledge of not only knowing how to change a credential but also where it's being used. And so in our field in one of the areas that we specialize in is the discovery process and also the change process trying to make that an automated technology. So the way I would break this down in terms of the challenge to IT and the challenge to the C-cell is that today most organizations are trying to do this by hand or they're trying to coerce a vault type of solution that's effectively a spreadsheet password or password spreadsheet that stores this information. And then trying to merge scripts together with it, and it's pretty hard to do at scale. So we've been specializing in the idea of understanding the behavior of users as they set these accounts up, characterizing the identities, and then providing an automated way of changing those credentials. So it's hard to do at scale, easy to do in a small case.

The other challenge that we also see which is interesting in most larger organizations that have grown by mergers and acquisitions and also by the use of contractors is two issues. One, the loss of knowledge within the organization of where these identities are and how they are being used. But number two as companies have moved into outsourcing, they've had to take certain shortcuts. For example, they've had to give their outsourcer access to every privileged identity in the environment. And so they lose attribution, and they begin to lose control simply because without any automation or any process the contractors can do what they want, where they want, to whatever they want, with really very little oversight. So it's a bit of an efficiency requirement, but it also destroys security.

Kathleen Richards: Are regulatory issues and compliance still the primary drivers in the PIM market?

Philip Lieberman: You know, the drivers in the PIM market are interesting. The requirement to have proactive management is really part of every regulatory requirement out there. If you look at PCI, if you look at critical national infrastructure, if you look at banking things like Basel II and Basel III, if you look at the ISO standards, or even the recent NIST standards that were brought out by the president of the United States or the White House in cooperation with NIST, they all say that you have to have proactive management. But the real question is what enforces these processes. So in one case the C-cell will look at this and say, "I'm taking a risk. What is the risk? What is the reward? What is the cost of the mitigation, and what are the silos I have to break down?" So there is a requirement to do it, but companies don't do it. The question is why don't they do it, and the answer is, well, it's hard. And it's also politically charged because remember you have to cross over into a lot of different areas and now implement something new.

Kathleen Richards: Who is responsible for privileged identity management and how should companies go about evaluating PIM?

Philip Lieberman: You know, that actually brings me to the second part of that which is when there's a breach that's, I guess, when we figure out who's responsible for it. And, in fact, that's somewhat the interesting part is being responsible for it and being able to do it are two separate things. So you asked me what drives this. So, sure, regulatory requirements drive it, but cyber warfare, that is, nations, states, and criminals are really what's driving the adoption of privileged identity management. This is the first vector, in fact, that criminals and nations and states go for it because it gives them their land and expand capability. So if a company doesn't have this, they become very easy pickings for governments and for criminals. When do they really begin to address it? Well, two ways. One, there's either fines that they're going to be hit with, or they've been breached and they show up in the press in which case they will figure out a way to solve it, or they will continue to get breached until there's enough turnover. And then finally somebody will eventually implement something. So it's usually by draconian consequence that they begin to actually remediate the problem even though the regulations do exist.

Kathleen Richards: Thanks very much for your time today. This has been a lot of great information.

Philip Lieberman: Thank you.

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: