I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.

Please check the box if you want to proceed.

By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

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.

Service, machine and application accounts often have levels of access that can, if used improperly, expose the organization to significant risk.

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.

Join the conversation

5 comments

Register

I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.

Regulate the creation of TLS certificates and SSH keys by policy as the author outlines above. These are the two most commonly used ways for non-users (machines) to authenticate. The authentication mechanism is the important control point over these non-user accounts so keys and certificates are the machine identities you must control.

Continually discover TLS certificates and SSH keys in your environment to see what is in use and how they compare to policy.

Roll out a service that educates and enables all human users that must create or use these machine identities, to serve themselves while ensuring their actions are always policy-compliant.

Fully automate the handling of these TLS certificates and SSH keys so the private keys are always protected and so they can be easily rotated (on demand and on a periodic schedule).

Continually remind and educate your human population on how/why to use these capabilities you've created.

Yes, this is great advice. SSH keys are starting to get more awareness than they used to, but the certificate angle is absolutely on point and more often overlooked. Thank you for the comments and great advice!

Excellent article. At Venafi we refer to what you have described as, Machine Identity Protection, and you’re right to bring this to people’s attention. As you stated, these non-users (machines) often have elevated privileges which makes the job of protecting the keys, certificates,... used for authentication critical. The urgency of this increases when you consider the number of machines is growing exponentially while the number of people is essentially flat.