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.
Machine identities are outpacing the growth of user identities
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.
Machine identity checklist questions
That being said, managing user and service accounts—including security rules—can be challenging!
- Are your user identities employed in ways that can affect your business?
- Do you have a healthy definition of a service account identity vs. user account identity?
- Do Group Policy Objects get pushed without you being aware of the changes and impact?
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.
What challenges can You expect?
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:
- Password/passphrase complexity. Many organizations are challenged to enforce the strength, expiration, restricted purpose or application use of passwords and usernames.
- Internal identity policy and methodology. Different applications and services have different requirements and your policies should reflect that.
- User identity and service account identity confusion. Employing user accounts as service accounts can cause outages or make a phishing attack much more damaging. Services accounts can also be a challenge to use across red tape.
- Account identity permissions and group changes. Users change roles, groups and jobs often causing service or security concerns if you do not adjust permissions accordingly.
- Other security measures and updates. Updating security policies, especially via GPO, can be a strong measure—so strong that you break config files like config in IIS. Are you able to prepare to update security via GPO to ensure no service interruption?
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?
I hope these are not problems you have in your organization.
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.