Securing your PKI (Public Key Infrastructure) is an essential component of any effective machine identity management strategy. Because PKI is used to safeguard connections and communications among so many types of machines, including websites and microservices, you need full visibility into all the certificates your network is using and the intelligence to know where and how they are being used.
But visibility and intelligence are only two legs of the machine identity management stool. Without automation, you leave yourself vulnerable to a host of PKI pitfalls that involve everything from managing the lifecycles of your certificates to enforcing security policies. Here are nine examples of these pitfalls and how automation can enable you to avoid them.
- Outdated security protocols
Once upon a time, websites were unencrypted, and SHA-1 was sufficient to protect internal systems. Those days are long gone, even though many organizations shockingly still have the latter floating around. And eventually, SHA-3 certificates, along with the current standard for encrypting websites TLS 1.3, will be outdated security protocols, vulnerable to hackers. If you can’t easily automate the replacement of certificates using outdated security protocols, you’ll be a sitting duck for hackers.
- Weak key strength
If you use keys that don’t offer a minimum of 2048-bit encryption, you leave yourself open to hackers who can “crack” the encrypted code. A 2048-bit key takes four billion times longer to crack than the previous standard 1024-bit key. It doesn’t make sense to leave your keys open to easy guessing when you can automate the replacement of those keys to the higher standard.
- Self-issued keys and certificates
Self-issued certificates are typically used internally for testing purposes. But if they get used externally, they won’t be trusted and can present a huge security liability. They’re not as robust as CA-issued certificates, they are typically not stored as securely , and they can be difficult to find later on, presenting blind spots for hackers to hide in. Thankfully, you can automate the enforcement of how these certificates are stored and used as well as the removal of these vulnerable certificates before hackers get ahold of them.
- Substandard protection of private keys
There’s no point in installing a lock on your front door if you leave the key peeking out from your doormat. Too often, however, organizations leave their private keys strewn about in places easily accessible to hackers—everything from unencrypted hard drives to spreadsheets and even email! You need to control access to your private keys using strict authentication protocols and zero-trust initiatives. Automating enforcement of these policies means only those who need access to these keys gets it—versus everyone else in the world.
- Wildcard Certificates
A wildcard certificate allows multiple domains to be validated with one umbrella certificate. This can be especially convenient for organizations that rely on manual processes to manage certificate procurement and replacement. But this also leaves organizations open to attacks from spoofed subdomains that can impersonate these sites through DNS. Additionally, wildcard certificates are often used indiscriminately, making them difficult to track down and replace once expired. Automating the lifecycles of your certificates—from procurement to renewal—makes tracking and replacing wildcard certificates painless. It also removes the need for having them in the first place.
- Failure to Revoke Certificates
Unaccounted for certificates can cause a lot of hullabaloo. They may be unused. Or installed in the wrong place. They may contain bugs from their certificate signing requests. If a certificate is not fully operational or has a lifespan that's greater than one year, it should be ferreted out and revoked to prevent malicious, man-in-the middle attacks. Automation simplifies this process dramatically while removing the potential for human error.
- Infrequent Key Rotation
Many know to change out their certificates regularly, and shortened certificate lifespans help ensures this happens. Because certificates can be duplicated, you should also change out their corresponding keys to prevent hackers from leveraging stolen ones. Best practice is to rotate keys and certificates every six months. That may sound like a lot, but it won’t if the task is automated.
- Complicated CA Hierarchies
Keep it simple. With the difficult task of implementing multiple CAs within a PKI environment, the priority should be on securing each certificate—not obsessing over the diagrams and flowcharts. Place them where you need them—root CAs, online CAs, CAs pertaining to policy and others—and move on.
- Rogue Certificates
When organizations implement digital transformation initiatives without updating the way they manage certificates, developers—whose top priority is speed rather than security—may circumvent lengthy, outdated processes for procuring certificates by just grabbing one from, say, Let's Encrypt that InfoSec doesn’t know to track. If these rogue certificates are not located and removed from the network, they could lead to outages or exploitation by savvy threat actors. Automation enables you to streamline certificate procurement and renewal by allowing developers and other end users to grab their own certificates that comply with your security policies without slowing them down.
Don’t forget the automation
In today’s digitally transformed world, it’s impossible to track every machine identity being used in your organization. Automation makes sure that your certificate management policies are enforced and your processes run smoothly, so that you can avoid these and other pitfalls that plague organizations.
The Venafi Trust Protection Platform can help you automate management of your TLS keys and certificates, SSH keys, code signing keys and user certificates across your entire enterprise. Find out how you can secure this avalanche of new and constantly changing machine identities by speaking to one of our experts.