How Policies Prevent Peril for Machine Identities

Let’s see how this works if you are an organization that is more mature in its use of machine identities. You have a complete inventory that you continuously monitor. You have an automated way to renew expiring or vulnerable machine identities. And you can push these machine identities back to their applications where they enable your lighting fast and reliable infrastructure.

Great job, you are well on your way to complete machine identity protection, but you are not done.

You may still have a problem. Your problem could be people, communication or domain expertise. Or maybe it is just the lack of a strict, documented and enforced policy for machine identities.

Let me give you an example. Only last week when I was helping resolve an issue, we witnessed two administrators argue about if they should issue an SHA-1 or a SHA-2 certificate. After letting them discuss amongst themselves for a moment, I politely chimed in that SHA-1 was shown to be weak years ago and according to our industry (and browsers) should not be used. Not to mention that it has been completely deprecated by all major browsers. Sadly, we still see people using SHA-1, even though we realized a long time ago that it was potentially vulnerable. Yet, despite extended news coverage, people are still using it and are seemingly unaware of the potential problems of doing so.

This fact was driven home to me not too long ago when I attended a training by Feisty Duck in London, “The Best TLS Training in The World”. One of my key take-aways from this awesome training was that even if you have strong use of keys utilizing your TLS protocol, you still have some very serious application settings you need to consider. You have some very specific settings that if configured poorly, can jeopardize even the best use of your keys and certificates. Do you know what the strongest settings are? Or better yet, are they documented so others can make good choices setting up the application?

If you don’t already have one, part of your security posture should include a strict and defined policy for machine identities. Your policy should dictate what applications settings are required and how your machine identities should be used.

We all know default settings will be the death of us, and yet we still get caught with them. Strong published, enforced and reviewed policy will not only help your administrators make great decisions, it will help them bridge the gap we all have in not being experts enough in our area of constantly changing technology and responsibility.

Are you helping your people be the best they can be by arming them with policies for machine identities?         

TIP:  If you can define and enforce machine identity policy, you are one step closer to the big dream of automation and achieving operational excellence by removing weak keys and preventing outages.

Related posts

• Will PCI DSS Compliance Give You a Head Start Meeting GDPR Requirements?
• PKI for non-PKI experts: How to Address Compliance Requirements
• 5 Machine Identity Risks You’ll Want to Avoid

Mark Miller

Do your administrators have policies that will help them maximize application security and ensure the safe use of machine identities? If they don’t, you may be setting them up to make mistakes that will end up costing both of you.

This is a lesson that I’ve seen many organizations learn the hard way. My team’s work includes educating the most high-tech security focused groups in the world’s largest organizations about machine identity protection. As such, we are laser-focused on sharing our expertise on x.509 SSL/TLS certificates and SSH keys, including all that can go right and all that can go wrong. In other words, we equip you to protect your machine identities, while avoiding the potential pitfalls of their misuse.