Four mistakes that can plague PKI administrators
FYI, this story is more than a year old
Article by Venafi security strategy and threat intelligence vice president Kevin Bocek
With the increasing need to encrypt more network traffic to improve security, public key infrastructure (PKI) administrators are under intense pressure.
In most organisations, very small teams of PKI experts manage thousands of TLS keys and certificates and small mistakes can have disastrous results.
Without the right technology and processes in place, it’s easy for the sheer volume of changes impacting these critical security assets, which serve as machine identities, to overwhelm even the most knowledgeable administrators.
You can’t run in the cloud, use Kubernetes, deploy IoT fleets and more without using PKI; however, for most IT professionals, machine identities are a dark art with few masters.
CISOs can’t leave identity and access management (IAM) programs to chance, so PKI must be operated safely.
Ultimately, PKI should be the root of robust machine identity protection programs; businesses use it to identify and authorise the flow of data to trusted machines.
There are four common errors organisations make that increase security risks and negatively impact the reliability and availability of business-critical network resources.
These mistakes include:
Forgetting internal and intermediate private certificate authorities
If an organisation’s root-signing of intermediate certificate authority (CA) goes offline for any reason, administrators must know where it’s located.
There have been instances where organisations have set up a root CA on a virtual machine and then allow that machine to go dormant.
When IT ops teams come along to tidy up dormant virtual machines, they inadvertently disable the entire PKI by deleting the virtual machine which housed the forgotten root or intermediate CA.
Without the right technology, this error could take months to fix.
Failing to revoke certificates and remove keys
Application owners and system administrators that don’t work with certificates frequently try to install certificates in the wrong place, make errors in requests, or forget to remove unneeded or unused certificates.
These unnecessary certificates may not be revoked, and the corresponding keys never removed.
In some organisations, thousands of unnecessary machine identities are littered across hundreds of servers.
This provides bad actors with plenty of opportunities to find and abuse these legitimate certificates.
Consistently extending certificate expiration periods
Managing certificates manually can be both time and resource-intensive, especially if organisations use spreadsheets, internal scripts or CA dashboards with limited functionality. It can be tempting to reduce this problem by extending certificate expiration periods.
While this technique may save organisations some time in the short term, it also significantly increases organisational security risk.
Longer certificate lifespans give attackers more time to target the private keys.
Not tracking wild-card certificates
Wild-card certificates are so easy to use they are often employed indiscriminately; many organisations don’t even track them.
If PKI administrators don’t know which machines are using wild-card certificates, it’s nearly impossible to renew every instance before they expire.
When these certificates eventually expire, every machine on which they were installed will stop communicating at the same time.
This eventuality can disrupt business and requires extensive resources to track each installation down and reinstall new certificates.
It’s all too easy to make common PKI mistakes, which can have serious implications for businesses.
By highlighting some of the things that can go terribly wrong, more PKI administrators can avoid the nightmares described above.
The best way to eliminate all major errors that plague PKI is to build a machine identity protection program that provides the visibility, intelligence and automation necessary to reduce security risks and increase reliability and availability.