Skip to main content
banner image
venafi logo

Is There a Disconnect Between Your PKI Security and Operations Teams?

Is There a Disconnect Between Your PKI Security and Operations Teams?

pki-security-operations-team-disconnect
January 21, 2021 | Scott Carter

One of the biggest challenges for today’s PKI teams is that they are responsible for machine identities, but they are not the consumers of the certificates that are being used. As a result, PKI people often struggle not as much with the actual certificates but knowing where they are being used. When problems arise (and they do more often than anyone wants to think about), there is a certain amount of forensic work simply identifying who owns the certificate and who should fix the problem.

On PKI side, teams have already put a lot of work into managing machine identities. They are familiar with certificate lifecycles and they know what to expect at each step along the way. They’re doing it every day. But for systems administrators or application owners, they may only interact with certificates once a year or every two years, when they need to renew certificates on the applications that they are responsible for. Because they do it so infrequently, they may not remember exactly what to do and which steps are necessary. So they may accidentally skip a step that leaves the certificate or application vulnerable.

This becomes a big problem when you compare the numbers of different bodies who are handling machine identities. The PKI team often has zero to five people focused on machine identities. But they are often dealing with hundreds of systems administrators who are deploying machine identities on thousands of applications. It’s this disparity that is the root of many PKI problems. 

The disconnect often surfaces when the PKI people look at the Certificate Signing Request (CSR) from a systems administrator. Often, it is not up to policy because the alternate name is wrong or for whatever reason. And that begins an extended back and forth process. The PKI guy returns the CSR to the administrator who tries again and then submit it for approval once again. Sometimes they may actually get the correct attributes. But if they don’t, further PKI concerns go back and forth and may get lost in email. If the exchange goes on long enough, the administrator may lose track and wonder where they left off and fail to remember whether the certificate is okay or not. At that point, they may not know what to do so they may not do anything at all.

Because of this uncertainty, PKI teams understand the need to continually evaluate their certificates to make sure that they comply with enterprise policy and are working as they should. But this effort becomes impractical with bourgeoning certificate populations triggered by factors, such as DevOps tools or cloud migrations. For these implementations, organizations may be more likely to lose track of certificates and, consequently, what's going on with their machine identities.

So, the PKI teams keep looking to verify that policies are correct and that machine identities use the right algorithms, etc. But when they find an issue, the PKI team may not be equipped to fix it. They must identify the application owners to remedy the problem. And those systems administrators are usually not experts on how to deploy and manage certificates. So, there's a disconnect between the PKI team and the application owners and often, this causes machine identities to fall through the cracks.  

When you are not properly managing certificates, they can expire and trigger an application outage. When that happens, the application owners panic and say, “What the heck's going on here?" At that point, the PKI team does some investigation and when they identify the cause, they say it’s the systems administrator’s issue. The application owner, in turn, says “I didn't do anything to cause this”. No one wants to take responsibility. So the PKI team ends up owning the issue and getting blamed for it. Afterall, they are the experts on certificates. So, by default, they become responsible for solving the issue. And that’s all that people generally see.

But the bottom line is it’s not as much whether either team did anything right or right or wrong, but that there's a disconnect between teams—in terms of responsibility, knowledge and experience.

One way to overcome that disconnect is by using a centralized platform to manage all of your machine identities. That way, organizations can ensure policy compliance by eliminating the variables and making certificates self service. By automating this entire process, organizations can ensure that no certificates fall through the cracks.


Related posts

Like this blog? We think you will love this.
what-is-a-private-key
Featured Blog

What Is a Private Key?

How Are Private Keys Used?<

Read More
Subscribe to our Weekly Blog Updates!

Join thousands of other security professionals

Get top blogs delivered to your inbox every week

Subscribe Now

See Popular Tags

You might also like

TLS Machine Identity Management for Dummies
eBook

TLS Machine Identity Management for Dummies

Certificate-Related Outages Continue to Plague Organizations
White Paper

CIO Study: Certificate-Related Outages Continue to Plague Organizations

About the author

Scott Carter
Scott Carter

Scott is Senior Manager for Content Marketing at Venafi. With over 20 years in cybersecurity marketing, his expertise leads him to help large organizations understand the risk to machine identities and why they should protect them

Read Posts by Author
get-started-overlay close-overlay cross icon
get-started-overlay close-overlay cross icon

How can we help you?

Thank you!

Venafi will reach out to you within 24 hours. If you need an immediate answer please use our chat to get a live person.

In the meantime, please explore more of our solutions

Explore Solutions

learn more

Email Us a Question

learn more

Chat With Us

learn more