Enterprise identity management is in a state of transition: It's become both significantly more complicated than...
in years past and, in equal measure, more important. It's more complicated because, while establishing and maintaining identities for internal resources is just as complicated as it's ever been, cloud services (some that use internal identity and others that do not) have increased in prevalence.
Meanwhile, the rise of external identity providers and increased use of mobile have muddied the waters. At the same time, enterprises are now more "externalized," meaning that identity is increasingly the arbiter of access. Some have even said that "identity is the new perimeter;" this refers to enforcement of boundaries through identity rather than via the architectural and topological means of yesteryear.
The point? Identity is a big deal -- and it's likely to become an even bigger deal as time passes. As one would expect given these trends, security teams are increasingly focused on shoring up how they handle enterprise identity management and governance. They're doing this by investing in the technical elements that support enterprise identity management and also through the policy and governance artifacts that support those efforts. Despite all of this, there is one area that is receiving less attention: non-user identity -- in particular, service, application and machine accounts.
But what about non-user identity?
Ensuring that the identities of these entities factor into your overall identity governance equation is just as critical as it is for users. Service, machine and application accounts, just like privileged user accounts, often have levels of access that can, if used improperly, expose the organization to significant risk. Likewise, the mechanisms that they use to authenticate to resources -- and the mechanisms that resources employ to ensure that they have appropriate levels of access -- are in many cases equivalent (or similar) to those of users. However, unlike accounts assigned to users, they may have different requirements, protection mechanisms and safeguards surrounding their usage because of the different way in which they are employed.
Before getting into the nitty gritty of how you might account for these in your strategic identity planning, it's helpful to first explain exactly what we mean here for those who are unfamiliar. In a Microsoft Windows context, the most straightforward example would be service accounts. These are the accounts created as the context within which services run. That might be the most familiar example, but it is by no means the only one. Consider an automated file transfer that uses SSH to exchange data: Instead of a user logging in to the machine and initiating the transfer, access might be programmatic in nature -- an automated process. In this case, the transaction could employ a stored password to initiate the transaction or, because storing passwords can be a dicey proposition, it might use a stored SSH key pair.
Another example? An application accessing a data store: The application might itself run within the context of one user -- for example, a managed service account -- while using a different user ID and password, ideally unique to the application, to connect to the data repository on the back end. A web service might employ a client certificate to authenticate itself to back-end transactions via Transport Layer Security. The list goes on and on. Authentication and access-control decisions for these automated processes occur just like they would for users; and, just like there are multiple options for how users might authenticate themselves to various resources, so too are there options for how an application, service or automated process might.
In a large enterprise, there are probably thousands of accounts -- and corresponding situations and uses -- where these identities are employed. It's important then to factor them into the overall identity picture and to have a plan for how they interact and how they're used. But how? While a fully fleshed-out strategy will of course vary depending on your organization's security goals, environment and organization-specific factors, (e.g., type of systems used, specific technology in place and so on) there are a few general guidelines and strategies that can help you start getting a handle on this.
A fruitful starting point is to clearly and unambiguously establish -- for example, via policy -- what your organization's expectations are with respect to these accounts. If you expect that they will employ robust authentication, document that. For example, if you expect that passwords (when they're used) for service accounts periodically change and have robust characteristics, document that too. Include any other expectations you have: that they be auditable and traceable, that they not be embedded in source code, that they be cryptographically protected and so on. The goal is to ensure expectations are crystal clear so that there is no ambiguity. Then, anyone who deals with these secrets -- developers, operations teams or whomever -- can design around those expectations. You can start with existing policy to ensure it is drafted in such a way as to include these accounts and state explicitly that they are not exempt. A review here also ensures that you think through various enterprise identity management goals and how they pertain to these non-user identities.
After policy, mechanisms
Once you've set the policy for enterprise identity management, it's useful to establish a mechanism to know if, and where, these accounts are employed. This helps you enforce your policy and validate conformance. In the case of a Windows environment, for example, you might start by listing out service accounts -- managed or otherwise -- that are already present. This is a useful first step, but keep in mind that there are numerous other situations over and above those where they may be at play -- the SSH and application examples we used above, for instance. If you haven't ever looked at these accounts before, it might be a fairly long list, so begin with what you know about and expand as opportunities allow. You might start with managed service accounts and build on that list as you review applications, conduct audits and conduct other review activities.
Lastly, you'll want to set an enforcement strategy for situations where these accounts exist but may be non-conformant with policy expectations. A useful way to approach this is through a workmanlike examination. For a new deployment, such as a new application, you might use a tool, like application threat modeling, to systematically analyze applications, including any accounts required for it to operate. For a widely distributed and often-used tool like SSH, you might choose to have internal staff such as technology auditors look specifically at those accounts. This can be a useful strategy to employ in the context of a larger effort, such as a larger audit or examination of SSH administrative access and privileged accounts -- since, if you're not looking at that already, you probably should. As you learn what usage scenarios are common and which are outliers, you can evaluate specific tools to help. For example, look at privileged identity management products that offer functionality in this area or secrets-management tools that help you protect what you find.
Whatever approach you ultimately employ, the important part is awareness. Retain awareness that these accounts exist and that they are every bit as relevant to your overall identity strategy as user accounts are. Resist the temptation to let them fall into the background. Having that awareness of these front of mind ensures you're accounting for them in the day-to-day security hygiene activities and planning you do already. From there, opportunities to develop and mature your approach to enterprise identity management will come in time.