We are happy to announce a new series, where for the first time we will research and document the issues around privileged user management (PUM). It may not sound as exciting as cloud anything, or iOS data protection, but it’s something you overlook at your own risk. Because administrators (those privileged users) have the keys to your kingdom. A sysadmin with malicious intent can cause a very bad day for you and your organization.

And no, this isn’t just another recycled attempt to bring the insider threat back into vogue – much to the chagrin of the DLP vendors, who drove their first wave of growth based on the nebulous insider threat. First of all, privileged users (P-users) don’t necessarily need to be insiders. And most insiders have limited access and authorization entitlements, while administrators can basically giving themselves access to do whatever they want. That old privilege escalation thing. That’s why we are calling this series Watching the Watchers – because if not properly managed, administrators are Above the Law.

Business Imperatives Changing Privileges

We live in a brave new world of technology. What used to be within your site, in your data center, or running on your big iron, now may or may not be in any or all of those places. Even if your stuff runs in your data center you might not know exactly where and it may not be in your control. It may or may not be running on an operating system you understand. You may or may not control the pipes that lead to that data. And you certainly can’t tell business users and/or business partners that they need to go back to the old model, where you had visibility from the bare metal all the way to the data layer. Times have changed.

Even better, you might not even know who is responsible for managing those specific systems. With layers of virtualization abstracting pretty much all physical networks, storage, and servers, there are many different folks responsible for managing the pieces of what we call an application. Even the term ‘application’ is really a misnomer – applications can be almost anything, processing anywhere, accessing data from anywhere, and presenting information to anyone, anywhere. Times sure have changed. So let’s start by defining what a privileged user is.

Privileged User: Anyone with admin (or root) access to a device.

Based on that definition, every user is a privileged user to some device. That’s a bit broad, so we’ll restrict our discussion (and this research) to users who manage critical devices – running applications, hosting databases, or pushing packets to the places they need to be. Sure, it’s problematic if the P-user in charge of the receptionist’s device (the receptionist) is compromised. But it’s much more serious if someone who can administer the device hosting your customer database gets owned.

Let’s get a bit more specific about the business drivers and the impact on privileged users:

• Reduce Cost – Virtualization/Cloud: Many organizations are under dramatic pressure to continue reducing costs wherever possible. That means embracing technologies like virtualization to make better use of physical hardware, and cloud computing to make better use of data center real estate. The impact of this driver is scale. Now you have a lot more things to manage and they can be spun up and torn down at the click of a button or via script. Throw in the unbounded number of instances that can be run in the public cloud, and the only thing you can be sure of is a massive change management headache.
• Reduce Cost – Outsource: While data centers are virtualizing, organizations are contracting with (lower) cost management to do their (alleged) commodity work. You know, like managing databases and email. All kidding aside, it’s common to see third parties manage wide swaths of an organizations’ IT infrastructure – providing nameless, faceless folks (perhaps on the other end of a SAML link) with access to critical stuff.
• Agility – New Apps: If you think about a typical web app, it’s more ‘assembled’ nowadays than built from the ground up. And parts may be yours, they could be pieces you got from someone else, or they might include data from somewhere else, integrated into your environment via a foreign API. It’s hard to know what an application is nowadays. And if we don’t know what it is it’s generally difficult to manage.

Yes, there are more business drivers, but you get the picture. Anyone with access to manage a device that runs something important (or is a component of something important) is a privileged user, and the change management issues inherent in this escalating complexity requires that administrators continue to become more efficient and leveraged. Which can result in errors, shortcuts, and general violation of good operational practices. Now let’s look at some specific threats these privileged users present.

P-User Risk Assessment

Yeah, we’re old school. We still like to assess risk, or at least run through a quick mental exercise to figure out how many ways we can get killed. So let’s do that with this explosion of devices managed by privileged users. Of course this isn’t an exhaustive list – more a back of the envelope exercise to uncover some of the biggest threats to our environment if these privileged users are compromised. And while we are at it, let’s define a new term, PUPwnage, for a compromised privileged user. Just rolls off the tongue, right?

1. Compromised devices: This one is obvious. If a privileged user is compromised (PUPwned), the attackers gain access to any device they manage, and then the fun begins.
2. Data leakage: PUPwnage can result in any and all data being stolen from the devices they control.
3. Create accounts: PUPwnage allows attackers to create both user and admin accounts on devices, and to pivot through the environment, moving from one compromised device to another – stealing data thefts as they march along.
4. Pollute applications and/or data: PUPwnage also results in application attacks, such as changing code to break functionality, creating backdoor access, deleting or changing data, or otherwise breaking your applications.
5. Operational mayhem (shut down devices): Yup, PUPwnage allows attackers to shut down devices, pin device utilization at the max (effectively a denial of service), wipe disks, or pretty much anything else.
6. Fiasco in the clouds: If you run a bunch of stuff in the cloud and someone gains access to your cloud management console, they can do all of that good stuff we mentioned under operational mayhem. But a new attack, unique to the cloud, is an economic denial of service. By spinning up instances and consuming cloud resources, this attack costs you real money and can continue until you either max out your credit or the provider shuts you down. Fun, right?

As enjoyable as it would be to come up with another 20 problems posed by compromised privileged users, someone very wise once told us “never sell past the close,” so we’ll assume you are sold on the dangers of losing control of your P-Users. But we need to discuss the other issue, which is that P-Users aren’t really that unique because many administrators share accounts and credentials. They justify this behavior with many reasonable sounding excuses like, 1) we need access if Admin1 gets hit by a bus, or 2) it’s too time consuming to create admin credentials for each admin on each device. So admins share and share alike. And the end result isn’t much different than a crack den: pretty messy, and at some points the cops show up to turn out the lights.

To be clear, compliance has been and remains a major driver of all privileged user management. Specifically, PCI-DSS specifies the need for unique IDs, and to ensure that account credentials aren’t shared. SOX requires separation of duties to ensure no one (not even administrators) has the ability to implement financial controls without oversight. And we see the need to audit database administrators as a key driver for Database Activity Monitoring products. That’s one specific use case of privileged user management; we prefer to focus on the security risks and complexity drivers for the technology, but we can’t minimize the old reliable compliance and audit drivers.

To reiterate: privileged user management involves ensuring (only) the right folks access the right resources at the right times. And that you know exactly what they did. Easier said than done, but that’s why we are writing this series – to map out a specific set of activities that can help reduce the risk of P-User Pwnage.

The Elephant in the Room

But the cold hard reality is that most organizations don’t formally manage privileged users. They may do some identity management, but that’s for everyone. Given the potential issues, why doesn’t everyone watch the watchers? Inevitably a higher priority project, or a new device with shinier lights, shows up to divert attention and budget away from this non-revenue and non-cost-saving activity. Until a rogue admin locks you out of your data center or your forensics guys find the back door into your logistics system, anyway. But without throwing around a bunch of FUD, we realize there needs to be a logical, phased approach to solving the problem. Big bangs don’t work with large organizations with lots to do. So this series will lay out a lifecycle to manage your privileged users.

We will go beyond the identity management aspects (provisioning, entitlements, adn authentication) of managing users to also focus on the operational requirements and issues. This means keeping admins (and other folks) from accessing devices they aren’t authorized to manage. If they are authorized for access, you need to make sure they can’t share or otherwise misuse credentials. And finally you want to audit what they do on the devices – which is critical both for forensics after an attack, and to substantiate controls for compliance.

Over the next few weeks we will dig into all these topics in accordance with our Totally Transparent Research methodology. But before we get going, we’d like to thank our pals at Xceedium for sponsoring this research project. Without our sponsors we would be serving coffee at Starbucks, instead of drinking it all day.