What security leaders need to do about privileged account blind spots

How is your organization addressing Identity and Access Management (IAM)? More important, how are you handling administrative and service accounts?

A lot of organizations are pumping money into Identity and Access Management (IAM). Yet many of those same companies tend struggle to address the challenge of managing the administrative and service accounts. It’s not uncommon to see password-protected spreadsheets and notebooks stored in a locked desk drawer.

The challenge is for many is what to do with Privileged Identity Management. Turns out part of the challenge might be the way we’re thinking about it.

Jonathan Sander (@sanderiam, LinkedIn),VP of Product Strategy at Lieberman Software, takes a different approach. He’s an enterprise security veteran with over 20 years of experience. He’s worked with some of the world’s largest and smallest organizations to improve their programs and results. Currently working in the Privileged Identity Management space running product strategy for Lieberman, he did the same for STEALTHbits Technologies, and built what became the Quest One Identity Suite from the ground up with Quest Software and then Dell.

His experience is remarkable. But even better is the conversation. Jonathan is witty, sharp, and always brings value to the table. That’s why I trust him as an advisor to me (disclosure: I consider Jonathan a friend and an advisor. He’s not a client. I’m not his client. He’s just that good). This time was no different…

In our opening, he caught my attention by suggesting that privileged identity is a blind spot in the reality of Identity and Access Management (IAM). Or maybe that’s how I heard it…

Explain how the reality of IAM creates a blind spot for privileged identity management

Securing privileged identities, all the admin credentials, root accounts, enable accounts, and everything that has lots of power like that, has been a big hole in many security programs. I’m not sure I would call it a blind spot because if you ask any security pro about this, they will absolutely agree there is a terrible risk associated with these accounts.

The problem is how we frame the issues and solutions. Privileged identity management is seen as a subcategory of identity management. Whether or not it is is an academic debate, but the effect has put it in competition for budget and resources with single sign on projects, multi-factor authentication roll outs, provisioning programs, and other items that are connected to end user security. When you give the security teams and IT folks a choice of locking down the end users or the admins, it’s not too hard to guess who they will choose. Of course they go after the end users.

Another effect of being a subcategory of IAM is privileged identity hard to fit into the models and approaches people use.

Policies in identity are strongly linked to humans. You are provisioned an entitlement because of who you are and what roles you play. Systems make rules about how and when your authentications are valid based on the same ideas. Ultimately, the policies of IAM revolve around individuals. Linking policies to control privileged identities to people is an anti-pattern. Sure, you may have rules about what humans can handle what privileges. But the privileged identities themselves need to be locked down and those policies need to revolve around the risk associated with the underlying systems and data to which they are closely linked.

I recently spoke with a CIO who told me their research applications all run under one specific account. I pressed him about who has access to the account, and it boiled down to just about every admin. At some point they required it, and since that account was so widely used they couldn’t really change its password or other attributes. So every admin in the company was running with scissors and the way this guy slept at night was “we have two factor for all the initial logins.”

The policy about people requiring two factor doesn’t do a thing to actually protect against accidental – or malicious – use of this very powerful account. People are simply too trusting of their admins in many cases.

How does the trust factor impact the way we think about privileged identity management?

Trust plays a big role in how people approach the privilege problem. It makes sense that people trust their staff. They hired them. They work with them every day. From a simple, psychological viewpoint, people are wired to trust those they are in constant contact with and in whom they have something invested like the thought “I hired them so they must be a good choice.”

But recent history – and headlines – are littered with examples of people who went from trusted employee to insider threat in the space of one misplaced comment or change in HR policy. And if you don’t buy the massive scale of insider threat, then you have to realize that no one is perfect. If everyone runs around with scissors, eventually someone’s going to put someone’s eye out.

What’s really interesting is what often happens when we get the over trusting executives together with the admins in whom they are placing that trust. IT leaders very often came from the IT ranks. I’m old enough to remember when having the root password was a sign of being one of the cool kids. Lots of executives still think that their admin users want to have that cool factor.

They trust them, and they want them to be happy. So they let them keep what they see as a perk. But the odd thing is that a massive majority of smart admins today don’t want it. They have come up in the times of a new breach every day and see the direct connection privilege has to that.

When you offer the notion of a system that will lock all those risky accounts without interrupting operations or their day to day lives, they’re all over it. The admins see automated security as a lot cooler than a memorized root password.

They’re also smart enough to know that when the breach or the big “oops” happens, if they can prove they were *not* the last one with their hand on the stove, then they will be a lot better off. The bigger adjustment is often for the more senior folks and the leaders who still think of privilege in terms of the superintendent of a building.

Share your example about the “superintendent of the building”

When many people think about IT administrators, they picture the super in a building. What’s one of the first things you picture when you think “building super?” It’s likely the big ring of keys they have on their belt. The super has this big keyring so they can get into any room in the building to do what they need to do any time they need to do it.

This is pretty much exactly how we have been treating privileged identity. The admin has a big keyring filled with passwords, SSH keys, certs, and more. They have unfettered access to it. They may even pass it around to be used by a whole group of folks.

However, there is one huge problem with the superintendent metaphor. When a super uses a key from the keyring and then leaves, the key goes away, too. Often when an admin uses her key to get into a system, a piece of that key is left behind. On Windows it’s a ticket. On other systems it may be a key, a record in a log, or some other fragment.

Those little pieces are a big problem.

The bad guys can land on a system through a phishing email filled with malware and luck out to find a ticket left there from a helpdesk engineer who recently got on the system to clean on this luser’s last bout of malware infection. Once they have that key left behind, they can use it to start spreading out, going lateral, and that’s what the bad guys are really after.

Because of the superintendent image, many folks have focused on the wrong part of the privilege challenge.

They figure, like with IAM policies, if they can lock down the user then they have controlled that keyring the user has as well. That thinking is fraught with problems, but the worst problem is that the keys on that keyring have a whole life of their own outside of being on the super’s belt. Bad guys know that and they are ransacking our properties with keys they basically find on the ground every time they get someone to click on the wrong email.

You suggest a better way is to think about the way security guards handle keys. How does that work?

If the superintendent is the wrong image, then we need to get a better one. My suggestion is to think about all the administrators more like security guards in a locked down facility. We’ve all seen it in movies, and maybe some of us have seen it in real life.

In a facility like that, the keys aren’t on anyone’s belt. They live in a locked box in a locked room.

If you need a key, you go there, go through a sign out process, and you get the key on a provisional basis. If that key isn’t back in the box in a certain amount of time, then someone is going to go looking for it because that means there is something wrong. Someone is going to find that key, and whoever has got their hands on it.

This is exactly how you can envision privileged identity management in your shop. Now all the credentials are locked up in a secured library. When they are needed, people and systems can check them out. Some maybe just require a simple log in to check out, maybe others require prior authorization or approval steps.

And the key part is what happens after that.

Once the checkout expires, then the credential must be rotated. The password must be changed, or the account swapped, or whatever makes sure that the access which was granted is now revoked. And that rotation is not just for checkouts. The people we deal with who have the highest levels of security awareness are rotating their privileged identities aggressively all the time.

That helps protect against the “key on the floor” problem. You can’t stop Windows from keeping a copy of that ticket, but if you’re rotating that account aggressively then you’ll pull the rug out from under that bad guy who found it on the floor and tries to use it. Not to mention that if you integrate the PIM system with your SIEM and analytics, you could know for sure that someone using that key right now is not using it in tandem with a valid checkout. That means you should go get ‘em. That’s someone doing something wrong.

One thing people often think is this will cause a lot of problems for your admins and automated systems. Of course, you could implement the wrong solution or the right solution the wrong way and get that result. But executed well, PIM shouldn’t disturb anything. It will put a layer of abstraction between admins and privileges – they don’t have that keyring on their belt anymore. But most of them don’t even want that is the high risk world we have today.

As for automation, PIM goes with that like a hand in a glove when you do it well. You can actually make the automation and orchestration more efficient by hooking it up to a highly automated PIM system rather than relying on humans to update every single place a password or other credential needs to be touched. The system won’t forget a spot once it’s set up and let loose.

This has actually led to some of our most advanced customers hooking up PIM to their DFIR systems. Security has moved fast into a “detect and respond” mindset to fight automated foes, but the “respond” side has largely been about smart security analysts doing things. With PIM in place, in response to any credible threat they can rotate all the connected credentials. This does nothing to the good guys since they would be going to the lock box to get the keys anyway, and the box is as up to date as the last rotation all the time. The bad guys, however, are now starting from zero again as we just pulled the rug out from under them.

To get started – perhaps in realigning PIM with incident response – it starts with a conversation

If you’re starting from zero or even starting over after doing the wrong thing with your privilege approach, then my suggestion is you find your best administrator and talk to them. I’m not talking about the security person or even that person in operations who is always talking about security. Find that one person everyone recognizes as the one who knows it all. Every shop has one or two of these folks. Ask her how privilege is really used. Have her map out how admins use it, where it’s used in automated systems like backups and updates, and all the likely surprising spots where your team has found to tuck away privileged identities to make all the IT magic happen smoothly.

That’s going to be your actual set of requirements. Starting from the idea that you should get a “vault” and build out from there is a broken mindset. The problem is not the place you’ll put all these privileged identities, it’s how you’re going to get them integrated into your real processes and actual operations.

Solving the privileged identity management challenges isn’t all that different than all the other big problems IT has taken on over the years. It will take a deep understanding of the requirements, commitment to a layered solution, and all that jazz. But if you start from the point of view of your fighter pilot level admins and go after the use cases they think have the biggest risk impact, then you’re doing things right. If the system you build can knock over those big challenges, then the simple stuff will be easy.