A big "small" problem

Identity management has evolved to provide incredibly granular and flexible capability with respect to managing user logons, authorizations, and access control, provisioning new users and reliably removing access for expired users. Add in delegated and self-service management capabilities plus sophisticated workflow and auditing capabilities to assure policy is followed when granting access, and IdM can successfully automate processes that are very error prone when done any other way. This provides a tremendous boost in security by assuring that access is only granted when, where and to whom needed, and ends when it should. Identity management has been a big contributor to reaching compliance, allowing automation of quite complex policy driven processes.

There is, however, a category of usernames and passwords that identity management and password management has largely left unmanaged. This is the category of system administration logons for things like root or superuser access to operating systems, router or firewall configuration, hard coded logins to databases embedded in application scripts, etc. This category of system access has quite different characteristics from application and network user access. Among other differences, it is usual for there to be a single logon code that is shared by multiple administrators. This type of access for devices and systems is not usually constructed to track *who* is logging in, only to restrict access to authorized people (defined as anyone who knows the access codes.) These differences mean that managing this set of access requires a different approach than traditional identity management has so far provided.

The key distinction of this type of login authentication is that it is owned not by users, but by one or more systems. As a result this information is used by multiple people - everyone who administers or develops these systems or applications. Most companies today manage these privileged access codes outside of any other access management process. These range from administrators who keep the passwords in their heads, through those who write them down on a piece of paper somewhere, to those who combine them into an encrypted spreadsheet that is in turn passworded - creating a master key to all of the other system master keys.

These privileged passwords comprise a high value target for an unauthorized person who wants to alter how a system behaves for any reason. Compliance auditors are only recently coming to see this category as its own issue to be "brought into compliance" but they are increasingly calling it out as something that must be addressed. It takes little thought to realize that compromising this category of privileged passwords can create an "end run" around most of the security techniques an IT department might deploy.

I was reminded of this "small" problem when I read a recent announcement of a partnership between Courion and CyberArk to address it. I've followed Cyberark for a couple of years now, keeping it on my list of companies with an interesting technology looking for a market. Recently, they have taken on this problem of privileged password management and linking it to identity and they have crafted a unique approach that appears to address the problem in terms system administrators can accept. In the process, they have created an interesting type of provisioning of these system accounts across a network that allows a significant step-up in security as well as identity based tracking of who accessed the administration of what resource when. They have even created the capability for single use passwords for this type of access.

Managing privileged administrative passwords seems like a relatively small problem, as there are usually only a few people who use this type of administrative access. But having passwords live "in the clear" in application scripts, and the master keys live on paper or in spreadsheets creates an environment where administrative access code compromise is nearly untraceable and difficult to detect. Creating and enforcing a password expiration or minimum password strength policy for these administrative entry points is also difficult (which is why it is often done manually).

If you multiply the number of servers, application scripts with embedded passwords, firewalls, VPNs, etc. by the number of authorized administrators, you quickly see that this is a much bigger "exposed surface area" than it may at first seem. I don't know if the marketplace will think that CyberArk has the preferred solution method, but it is clear that identity management must find some way to address this problem if it is to provide the security and compliance capabilities it seeks. At least now there is a way to do it that people can think about, throw darts at, and innovate from - and that's a good thing.