Inside Privileged Access Management

Wary of intrusions, data compromise and theft, organizations increasingly are deploying privileged access management solutions. Idan Shoham of Hitachi ID Systems offers the essential do's and don'ts.

Breach prevention is one of the key business drivers, says Shoham, CTO and founder of Hitachi ID Systems. But there also is concern to avoid regulatory penalties or negative publicity that could result from the wrong person accessing privileged data.

"At the end of the day, these are all dimensions of security," Shoham says. "People are basically worried about securing their infrastructure and their data."

And fair warning, he adds: The biggest deployment challenges are not technical; they're organizational.

In an interview about privileged access management, Shoham discusses:

• The business drivers for privileged access management;
• The essential do's and don'ts;
• How to prioritize a PAM deployment.

In his role as Chief Technology Officer, Shoham is responsible for defining product and technology strategy and the overall development of Hitachi ID Systems solutions. He works closely with his talented team to ensure that the solutions that Hitachi ID Systems delivers to the market are of the highest quality. Prior to founding Hitachi ID Systems in 1992, Shoham provided network security consulting services to large organizations such as Shell, Amoco, BP Canada and Talisman Energy. He holds a Masters degree in Electrical and Computer Engineering.

Drivers for Privileged Access Management

TOM FIELD: Talk to me a little bit about what you see as the business drivers for organizations today to deploy a privileged access management system.

IDAN SHOHAM: The main driver really is security. Organizations are concerned about unauthorized access or a data disclosure, exfiltration of data, sensitive data, out of their organization. They're concerned about people hacking in and causing damage to their IT systems, causing service outages.

In a financial sense, people are concerned about misdated financial statements because of compromise in a privacy sense. People are worried about compromise of the privacy of data about employees or partners or customers.

These are all basically security concerns. More tactically, people are worried about audit failures, meaning where there's a security vulnerability. And that may refer to internal audit or external auditors, and quite often there is an audit finding, and that creates pressure from the board of directors to resolve these problems.

In a few cases, we've talked to organizations that have actually experienced a break-in, so that they're actually trying to close the gate through which people have already broken in. And in some cases, we talked to organizations where there hasn't been a break-in locally, but they've heard about break-ins at similar organizations or in the media, and they just don't want to be the next victim that shows up on the news.

And overriding all this is some desire for avoiding regulatory compliance problems. If audit finds a problem, then pretty soon the regulator may find a problem, too, so you don't want things to get that far, because as soon as regulators catch wind of problems, there could be more serious consequences, penalties and so forth.

So, really at the end of the day, these are all different dimensions of security, but people are basically worried about securing their infrastructure and their data.

Threat Impact

FIELD: In what ways do you see the current threat environment impacting what organizations want or how they deploy a PAM system?

SHOHAM: What's funny is nobody ever thinks of something as a problem until they can consequentualize the solution. I'd say something like 10 years ago, when privileged access management systems started to appear on the market, people started to understand that static passwords and weak passwords and plain text passwords to administrative accounts and other accounts are a security problem. They've been a security problem all along, but until about 10 years ago, I'd say nobody really had solutions, so people took that to just mean business as usual and tolerated it.

Today, there are robust solutions in the market, and that means it's just no longer acceptable to leave these things alone. So that's kind of on the solution side of the equation.

At the same time, cyber-threats are kind of escalating every year. Before, you were worried about kind of kids hacking in for kicks and giggles. Now, you're really worried about state-level actors and organized criminal gangs and malicious insiders, really more professional attackers, and that increases the threat profile.

So you've got a convergence of, on one hand, the threat profiles increased; on the other hand, the awareness of the problem and the availability of solutions has increased, and so there's an increased movement to close the back door as it were.

I guess a third trend is organizations increasingly make strategic investments in IT. It doesn't matter if you're a retail organization, a healthcare organization, a financial organization, it seems like information really is the lifeblood of every organization, and so the more IT you have, the more consequential vulnerabilities and security exploits could be.

Do's and Don'ts

FIELD: Idan, given your experience with privileged access management, what do you see as some of the essential do's and don'ts of these systems, and where do you see organizations typically encounter challenges when deploying?

SHOHAM: I want to start by saying that the technology is actually relatively simple. A privileged access management system has to do a few things and needs to do them well: It needs to discover privileged accounts; it needs to change their passwords to random values on some kind of regular schedule; it needs to store those randomized passwords in a secure, encrypted, access-controlled credential vault; and then it needs to control access to these privileged accounts by people and by software agents. We make software that does that and, frankly, so do other vendors.

So technologically, the only real kind of "gotcha" to worry about is reliability. Basically, once you set all these passwords to random values, nobody knows what the passwords are, and you can't afford to lose the vaults, you can't afford to destroy the vaults, you can't afford to lose access to the vaults, because that would just be an IT disaster, to mean that you're locked out of your own infrastructure.

So that means you have to replicate those passwords across multiple servers, and they should be in different locations, and they should be in kind of an active-active replicated set-up so that in the event that you lose one of these servers, it's a nuisance, not a disaster.

But that's relatively straightforward; the real challenges I would say are not technological, they're organizational.

So one challenge is, frankly, you'll be deploying this forever. I don't mean to be an alarmist or anything, or negative, but in [many] organization, there are so many systems running on so many different platforms, and so many privileged accounts, that it just takes a long time to integrate all of those with a privileged access management system. There are also a lot of features that you may want to deploy over time. It's not just admin accounts that are used by people to configure or maintain their systems; there are service accounts, there are embedded accounts, there is a desire to record activity with these accounts and be able to search and play it back later; there's forensic audits, there's risk models.

So if you think of this as a sort of a matrix where the systems that you want to secure are kind of one access, and the things that you want to do to secure them - randomizing passwords, recording sessions, injecting new passwords into services or applications - are the other access, it's a big space. And sometimes a vendor or a consultant might promise rainbows and unicorns; they'll say, 'Oh, yeah, we can deploy that thing in your environment and be done in a week,' but that either means that they're dishonest or incompetent, so really, these deployments don't really end. You deploy something and then it works great, and the business comes back and say, 'Well, what about this other thing?' and then you deploy that and it works great, and the business comes back and says, 'Well, here's yet another thing that we'd like automated,' and it kind of goes on and on like that.

So that means from the business point of view, privileged access management should be thought of as a program; it's not a project, it's persistent. It should have a permanently assigned team; it should have permanent funding that rolls over from year to year. And the challenge is really just to convince the business to come up with that kind of commitment to investment; otherwise, you deploy a simple system that has limited scope, it works, and it covers 5-10 percent of your problem, and it leaves the other 95 percent of your problem insecure. So it's a problem of permanent commitment and funding, I'd say.

Essential PAM Skills

FIELD: What are the essential skills that you need, and how should organizations be approaching the staff up for that?

SHOHAM: Well, most organizations will start with external consultants, like integrators or vendors, initially, and then they ought to transition more and more of the maintenance and expansion of the system to an in-house team over time, and frankly, it's more sustainable and less expensive.

Typically, you have two skill sets: you've got somebody that's a project manager or a program manager, and they help to organize the communication with the business and prioritize what to deliver next, and that sort of is the front person, the communication point for what's being deployed.

And then the second person or team-type of person, I suppose, is more the technologist. These are the people that are implementing the system and configuring integrations and diagnosing problems and so forth.

So on PAM side, the skill set is just a standard project, a program manager; it's nothing exotic. On the technology side, again, it's nothing too exotic, but here's kind of a laundry list of things that you need:

You need to understand web services; you need to understand networks, which includes addresses and routing and name resolution and firewalls, data flow across the infrastructure basically. You probably need some scripting capability to deal with unusual integrations that are called X business rules. You need to understand directories, LDAP, active directory, things like that. You should have really strong diagnostic skills.

Think of this way: If you're managing privileged access on 10,000 systems on any given day, a few of them will break -- it's just the nature of the infrastructure -- and you need to have the skills to figure out why those things broke and coordinate with the owners of each system and fix the problems. So, strong diagnostic skills.

So basically, you need to have kind of a strong technologist, and perhaps one or two such people to support an active and constantly-growing PAM system. It's interesting that PAM is not really the same as identity and access management, in the sense that a PAM system doesn't generally create or delete access; it only temporarily connects people to pre-existing security rights. But their skill sets are very much the same. You need a permanent program; you need a PM kind of individual, and you need a technologist kind of individual, so in terms of the team, it's very similar to IAM.

How Does PAM Scale?

FIELD: So, Idan, I can hear some of our audience members from the larger enterprises saying, "What about me?" So how does a privileged access management system really scale up to be able to serve a large enterprise as well as it does a smaller organization?

SHOHAM: And we're certainly very interested in scaling PAM systems up to the enterprise, and actually larger to the cloud.

So in some sense, this is one of the differences between PAM systems and IAM, in the sense that the number of integrations is very much larger. So a PAM system could easily have 100,000 integrated endpoints: servers, network devices, applications, databases, clients, laptops. So the number of integrations is very large, and the PAM system needs to be able to talk to pretty much every one of those systems at least every day.

So how do you on-board 100,000 integrations? Well, clearly, you need automation. You can't realistically on-board or deactivate individual servers if you're going to do 100,000 of them, and certainly not if you're going to on-board or deactivate hundreds or thousands of servers every single day. So you need automation that can discover systems, which implies that you have a data source, or perhaps multiple data sources; you need to integrate this with your CMDB or your directory to get a list of systems that exist in your environments.

And knowing that a system exists is great, but it's not enough. You also need rules to figure out what credentials to use for the PAM system to connect to each of these systems, to talk to it. And then the PAM system needs to connect to each of these systems, and we call this probing; it has to probe them to see what services they have, what groups exist there, what accounts exist on each and every one of these integrated systems. And probing systems is not something that you can do once and forget about it; you actually have to do it on a recurring basis to see what changed.

And so after you collect all this data - systems, inventory, accounts, groups and services - from each system, then you need some kind of rules engine to apply rules to the data that you discovered and automatically figure out which of these systems to manage, which accounts to manage, what policies to attach them to, what access rules to attach them to and so on. So you need discovery and you need rules in order to automatically manage the infrastructure; really, nothing else is plausible large scale.

And again, like I said before, you need a distributed architecture; it has to be active-active and replicated so that in the event that something bad happens in one of your locations -- let's say you have a flood in a data center; I mean, this has happened to our customers -- you can't have an outage, you can't lose access to all these privileged accounts and passwords, so you need multiple PAM servers in multiple locations that are always available, so that if something bad happens -- and somewhere in the world, something bad happens every day -- this doesn't cause an IT disaster.

And I suppose the other thing that you need for scalability is a robust access control mechanism. So one kind of access control is these users can access these accounts and these systems whenever they need to. If you're a Windows admin and you want to sign in to a Windows box to configure something, you shouldn't have to go asking for permission to just do your job, so that's persistent access.

And separately from that, you need a one-off access mechanism, so you need a way, for example, for a developer to say 'Hey, Friday nights for four hours, I need access to a prod server to do a production migration, or somebody in the data center needs access to diagnose an emergency problem in the middle of the night, or a vendor needs access to come in and help you fix something.' So these are all one-off access scenarios, and for the PAM system to really be useful at scale, it has to support those.

Where to Begin

FIELD: Given everything we've talked about here today, the question that comes to me is where do you begin? How do organizations prioritize their implementation, and where do you see them sort of starting; where do they go first?

SHOHAM: You know, that's a great question, because we all know it's like a truism in IT: Don't boil the ocean. If you try to do everything at once, you'll actually accomplish nothing.

So you've got lots of options. What to do first? Do you organize this by application, by platform, by business process, by location, by user community? Lots of options.

What we see most of our customers do is they organize it by platform. So they might do their Windows plat first, and then they might do all their Linux servers next, then they might do, let's say, Oracle databases after that, and so on.

And generally, you layer on that by business process. So you might do basic discovery in password randomization and disclosure in the first go, and then you'll come back and do things like session monitoring and playback, or Windows service account password management as a deployment phase, or you might stand up an infrastructure to replace passwords embedded in scripts and applications.

And what's important is to do the most important thing first, and at any given time, the next phase should be the most important thing that's left. And the priorities are not really static. I mean, organizations are kind of evolving creatures, and so what we recommend and what's really the best practice is for organizations to reevaluate their priorities after each deliverable. So you might, for example, start with securing admin accounts on Windows servers as a phase, and when you finish doing that, and it shouldn't take that long, reevaluate your priorities and figure out what to do next. And maybe next you do, I don't know, Cisco devices, or maybe next you do Linux, or maybe next you do Windows service account passwords. So whatever it is, you do that, then you come back and you reevaluate priorities.

Role of Emerging Technologies

FIELD: So final question for you: If we look forward at some of the emerging technologies in the marketplace today -- I'm thinking mobility, cloud, the Internet of Things -- how do you see them impacting the future of privileged access management systems?

SHOHAM: Well, privileged access management is a part of the IT ecosystem, so certainly every IT trend has an impact.

Mobility has an impact in that people want to gain privileged access from their phone, and if you think about it, people's phones are outside the network. So even if I'm physically in the office, my phone's on a data plan, so it's attached to the public internet, not to the corporate network.

So you have this sort of dichotomy, where on the one hand, people do explicitly want to gain access to sensitive credentials on their BYOD; on the other hand, that's dangerous. You're intentionally leaking credentials outside your corporate perimeter. So there's some kind of balance there between utility and security risk, and many organizations are actually starting to allow controlled leakage of credentials out of the perimeter because it's just useful.

Clouds, well, cloud means that something else operates something: either your infrastructure or your application. So by that, I mean that there's infrastructure as a service, and there's software as a service. Software as a service really is not that big a deal; it's just for each SAS application that you want to secure, it's just one or two more credentials that your PAM system has to connect to; just more connections, more integrations, nothing special.

Infrastructure as a service is more interesting, and that's true for both public cloud, but also, private cloud or on-premise, because when you have large numbers of virtual machines, regardless of whether they're in-house or outside, you tend to run into situations where you're on-boarding and deactivating VMs very, very quickly. So the pace of on-boarding and deactivating systems, not people, accelerates by order of magnitude And that has an impact on the PAM system, because it needs to on-board and deactivate connections with these systems at the same pace.

And the Internet of Things is a whole other topic, I guess. I mean, people talk about Internet of Things in some type of generic sense, but if you think about it, we're talking about sensors and actuators, and they're small and inexpensive and cheap devices that exist by the million; you go order them from retailers operating out of Hong Kong and China for next to nothing. And cheap often means cheaply made, not terribly well designed, so all these distributed devices with on-board IP addresses and on-board web servers, they may not be terribly secure. The profit margins are so thin that there's just no room for robust security architectures.

So we're talking about poorly designed, poorly secured devices that might be inside your corporate perimeter that might exist in the thousands. It might quite diverse; there's many different types -- and so they're just sort of inherently insecure, these things -- and privileged access management is a reasonable strategy to help remediate that. So if all these little web cameras and all these little motors and actuators are deployed on your network, then the least you could do is discover them and change their passwords regularly so they're not the same from one device to the next, and there's some audit trail to access a device.

It's by no means a comprehensive solution to securing large numbers of inexpensive devices, but it certainly is a step in the right direction.