Win-win Policies that Simplify Your Machine Identity Protection

Win-win Policies that Simplify Your Machine Identity Protection
Tue, 03/12/2019 – 09:49

As I’ve written before, there’s an easy way to avoid these types of problems. When you craft policies that support business goals and objectives as opposed to hindering people, you actually make it easier for everyone to be secure. To illustrate how this works, let me share an example from a large financial services organization that I’ve been working with.

AWS Builder Community Hub

This organization had already established a series of policies that governed machine identities. But they were having trouble getting their users to comply with those policies. Like I often say, “If you can’t enforce policies, you don’t actually have policies. You have recommendations.” One of the policies that this financial services organization was struggling with was one that forbid the use of wildcard certificates. But they had no way to enforce this policy, so people ended up doing whatever they wanted to anyway. And they would use wildcards because they were fast and easy, and following policies against wildcards would just slow these users down.

Venafi helped this organization put together policies that made it very easy for users, while ensuring that they were using the most secure machine identities. The new policy was actually simpler as well as stronger and easier to enforce. It simply requires that whoever you are, you’re going to get a certificate in one of two ways: If you’re a person, you get this machine identity through a self-service GUI (that enforces strong security attributes) and if you’re a machine, you get it through an API. 

The message to users was welcome, if not long overdue: “We’ve made it super simple for you. You no longer need to generate keys, you no longer need to generate a CSR. We have a policy and procedure that does all that for you. So it’s a win for you, the user, because you don’t have to do all that manual slow stuff that you don’t like to do. And it’s a win for us, the security team, because now you’re following policies and procedures that are very secure.”

Building policies into these automatic processes simplifies something people have to do anyway. It makes it easy for them. They don’t have to do all these steps, they don’t have to think about it, they don’t even have to understand what they need to do. It’s all automated for them. And your machine identities are automatically more secure as well.

Are you ready for win-win automation for your machine identities?

Related posts

security automation, key management system, certificate manager
Mark Sanders

In my last blog, I discussed how implementing policies for machine identities can actually help you avoid insider threats that result from employees taking shortcuts that leave your organization exposed. Before I share more about the power of policies, let me give you a few more examples of the hazards of your users pushing the easy button for their keys and certificates.

Imagine if I used the same SSH key across different cloud systems because I just wanted to make that easier on myself. Copying one key onto another system would not only be easier for me, it would be easier for cyber criminals. Or, let’s say for convenience I create a machine identity on one cloud system, then clone it or otherwise duplicate it onto several new systems. And now those same machine identities are being replicated across multiple cloud instances with identities they shouldn’t be using.

Another big one is reusing the same private key. When a certificate is going to expire, technically you can reuse the same private key when you renew the certificate. That is certainly not the best practice, which is getting a new key when you renew the certificate. But if someone is pressed for time, they can just change out the certificate without modifying the keys. In that case, you have a bad problem with man-in-the-middle, because if someone has the private key and you don’t change the private key then they can still decrypt your data.

*** This is a Security Bloggers Network syndicated blog from Rss blog authored by kdobieski. Read the original post at: