For years now, we’ve been talking about the importance of managing and protecting machine identities. We most often use the analogy of user identities to explain what we mean by machine identities. In case you’ve missed any of my past rants on this topic, let me tell you the story again.
Simply put, there are two actors on a network. People and machines. In general, people rely on usernames and passwords to identify themselves to machines so they can have access to networks and data. Well, machines are no different. They also need to identify themselves to one another. But they are not using usernames and passwords. Instead, they are using machine identities. Both are important. But we spend about 8 billion dollars a year protecting user identities, while spending just a fraction of that protecting machine identities.
Even though organizations are clearly focusing more attention on protecting user identities, they may still suffer from some lax practices surrounding user and service identities—and this can impact the security of machine identities. For example, anyone out there who thinks a certificate is just a certificate—like a user identity is just a username and password—is not only sorely mistaken but is in for a rude awakening one day.
And if you have any user identity problems, then your machine identity problems are likely to be at least ten-fold. Not to mention the fact that user identities can’t be considered safe if you can’t trust your machine identities—validating users on a machine they shouldn’t trust is a recipe for disaster. And that’s even worse for service account identities.
Machine identities, such as TLS keys and certificates and SSH keys, act as the foundation of your security. But certificates alone are not enough. If just having any old certificate as your machine identity was the only problem, then the solution would be so easy even an IT caveman could do it. But it’s not.
Machine Identities protect each connection that passes user Identities and other sensitive information over, in or out of your network. We know that the perimeter of your network should not be your last line of defense. So, it is important that the foundation of your trust be protected. The most effective way to do this is through a machine identity management platform that can automatically do business as you define it. Just like defining how your business uses machine identities, you need define how your organization uses user accounts and service accounts.
That being said, managing user and service accounts—including security rules—can be challenging!
Our security teams in IT are on the look-out for exploiters and intruders. For privileged access, a lot of people use solutions such as our partner CyberArk to help manage their accounts. Some also use one of the many other password safes out there. If passwords for user identities were the only thing we had to worry about, maybe this would be a simple problem and solution.
Find out why protecting service account machine identities really matters.
It turns out, user identities are not all that simple. What kind of challenges can you expect with user identities? Well in my world, I will tell you:
How do you decide what is or is not a service account? Do your administrators with full permissions simply enter their account to make sure it will just work? What happens when their positions change? Does your service account expire or is it required to change passwords? Are your administrators or services accounts granted login permissions? Do you applications rely on multiple different accounts to get the job done such as an application account and a database account?
But if you do, you are not alone. There are several methodologies out there and each option has its own set of challenges. I have seen several scenarios that have put bumps in the road for IT experts in the aforementioned areas. We shouldn’t blame anyone; it can be tricky business to get work done in the middle of a vast and complex network.