The creation and evolution of the superuser

When I think about managing identities and privileges within an organisation, one of my favorite analogies for the whole privileged identity lifecycle is biblical. Everything starts ‘in the beginning’ with a super user. Whether someone starts with a server or a workstation, creates on-premise solutions for their network infrastructure or builds out a cloud, they’ll always have to start out with an account with god-like power that will control all other accounts accessing that resource going forward in the future.

Now, if you were not there at the set-up of new resources, you’d probably be unaware that there was a super-user account created at the genesis. But that super-user account never goes away and in most cases is used day-to-day, either by someone or something (either applications or automated systems). As time goes on, the knowledge of these super-users accounts, where they are, how they’re being used and so on, gets lost. Just as the history of how the bible originated is a mystery to most people except for scholars, so it goes with privileged identities.

As time goes on, things change in the world of IT and, again, most people don’t understand the implications. Add new appliances, switches, routers and software and new root accounts pop up. Blend that in with new super-user accounts for things like intrusion detection devices, antivirus systems or DLP and you get a whole new layer of privileges added to the environment. People don’t really think about it, they simply interact with it at the user level and the environment continues to evolve and morph.

But when auditors and regulators come in and ask ‘Who created all of this?’ and “Who has access to these accounts?’, you’ve got a good old fashioned debate on par with creationism and evolution; because there’s no one still around who can answer where the accounts came from and no records detailing who can access them.

Mining the infrastructure with privileged identity management

So where does privileged identity management play in this metaphor? I like to think of it like being the archeologist of the bunch. When you’re managing these identities, your job is to go out and mine the infrastructure, looking for ‘fossils,’ or those clues that provide your organisation with a view of where those god-like accounts are, how they’re being used and what they’re being used to do.

It’s an important task, because there are plenty of rogue scientists – hackers out in the field – that know all about these fossils. They’re also looking for DNA in the bones embedded in the rock that can be used to piece together where the original accounts are in your infrastructure. So much information about these super-user accounts is publicly available, waiting to be mined by the bad guys. Don’t believe me? Search Google with the phrase ‘default administrator account’ and see how many websites there are that list the default account information that will get you into most systems if the logins are not changed.

Don’t kid yourself. Those default logins are lurking in the bedrock. The problem with most organisations today is that the person provisioning new users may do so through a root account without even realizing it. Even if they do know what they’re doing, they may not know that these accounts are actually only a subset of all of the privileged accounts out there – many of which have always been accessible through default login information.

The identity management lifecyle

IT folks are somewhat like the priest or the rabbi talking about the bible and conducting well-organized and inspirational services, but not necessarily understanding the history of the materials that they are presenting. Many of the true scholars of the area know information that may shock the flock and those that are leading the flock.

For IT staff, the shock would be if they knew how the process of provisioning and deprovisioning results in many open privileged accounts that can easily be compromised. The process starts with someone getting hired. With a great, wide, wonderful world of systems out there, from an empty mill machine on a factory floor or a key card to get you through the front door, all the way to an SAP system or a really complicated line-of-business system that was written decades ago by an unknown in-house developer, new accounts need to be created to give that employee access to these systems. Some systems may be Windows-based, some Linux-based. It’s a smorgasbord.

So, when HR brings someone on board, they have the problem of governance and access in which they have to get these people enrolled into all of the systems they need. The difficulty is that with all these systems out there -legacy and new – you’ve got to figure out not only what systems they need to access, but what kind of access they’re entitled to. In the Windows world it is fairly easy. You just use Active Directory to classify employees in roles for the applications and level of privilege they need and you’re done. When they leave the company, you delete them from Active Directory and when they change roles you change their group membership. But enterprise applications creep far beyond the Windows platform and that’s the problem. You’ve got all of these other cultures and religions to deal with as well – and believe me, other operating systems are religions – plus the cult of SAP and Salesforce to think about.

And while many applications do have Active Directory connectors built into them, the dark secret of it all is that these connectors don’t work all that well. Further complicating things, when a company adds new systems, takes systems away or updates them, almost universally these provisioning systems stop working and that ends up leading to more manual work. Over time, these systems just fall apart.

One of the most common reasons the systems fail to work is the problem of paperwork. When someone leaves or joins the company there’s usually a mountain of paperwork involved and there is a workflow that has to be taken care of that is partially manual and partially electronic. Now, when people come in to the company, their bosses are screaming for access and that becomes top priority. But when they leave, the sense of urgency just isn’t there.

Similarly, when employees change jobs the demand from up top is for new access but no one pressures for the old access to be turned off. So you run into a queuing problem where you can go into any given organisation and potentially see hundreds of people who have been discharged or who have changed their roles and there is one HR person who has to go through the paperwork and go into the systems to get rid of their accounts. A back log inevitably grows. People forget about accounts that are orphaned and left opened to be used by the previous employee or anyone else that knows about the account. The danger is that not only are there low-level accounts in this back log but also privileged accounts with a direct pipeline into the company’s most important IT assets.