Read time: 5 minutes
Common PKI deployment mistakes and challenges:
- Lack of planning and tracking
Structured and well- considered planning is one of the best practices of PKI deployment. Well-defined planning will not only help an organization keep track of their certificates, but it will also decrease the security risks to the PKI.
Once the system has been in place for a while, and if it has not been built in a structured manner, your organization can easily lose track of what certificates have been issued. Many organizations do not pay attention or do not know about the number of certificates they have, their expiry dates, where to find them etc. The consequences of such mismanagement range from failed audits to certificate and key misuse that can ultimately compromise an organization’s systems. An example of this is what happened when attackers pushed a malicious version of ASUS Live Update using ASUS security certificates to install backdoors on over a million PCs.
- Not allocating skilled internal resources
The most prevalent mistake made when deploying PKI is underestimating the resources needed. Running an in-house PKI needs a load of effort, time, and money. It is required to have a dedicated team with skilled resources to run the show. The PKI team should have sufficient resources and skilled owners who can lead and respond effectively to an outage or security incident.
- Security of the Root CA
It is particularly important that the security of the Root CA is well-considered. In PKI deployments all trusts comes from the Certificate authority (CA). The CA issues the Root Certificate which ensures the validity of the cryptographic keys used to verify the authentic identities. The root CA is the foundation of trust for every certificate issued across the organization’s environment. If you cannot trust your root CA, you cannot trust your PKI. As per security guidelines specifying who can obtain the certificate and when the certificate will be revoked is crucial for establishing and maintaining trust in Certificate authorities and avoiding PKI deployment mistakes.
A regular audit of relevant certificate authorities is required to ensure that the certificate practice statements (CPS) is implemented correctly, and to avoid any risk to their network.
As Ted Shorter, the CTO of Certified Security Solutions puts it:
“PKI enjoys a well-defined structure for policy and practices definition, in the form of Certificate Policy (CP) and Certification Practices Statements (CPS). These are excellent frameworks for defining the requirements governing a PKI, and how an implementation would meet those requirements. Creating these documents can be a daunting task. However, it’s important to note that simply copying someone else’s set of CP/CPS documents verbatim will not suffice; these tools only have value if they truly represent your organization’s PKI requirements and operational processes.”
- Bad Certificate Lifecycle management
Another PKI deployment mistake is lack of forward planning for the management of the entire certificate lifecycle.
Poor handling of expired certificates may cause outages and significate expenses. Automating renewal of certificates may help in this case. If the organization is doing a manual effort, then monitoring the expiry of certificates is a must.
Figuring out what is best for your organization and its PKI is a calculation you’ll need to work through, by coming up with an entire plan – an issuance process – that covers not just the initial roll out but the entire certificate lifecycle.
It is also a good idea to figure out how you’re going to handle revocations, key archival, key recovery, and all other contingencies.
- Not storing certificates and keys Securely
Hackers can use a variety of techniques to analyse and detect keys while they are in use or transit. Ensuring the keys are stored securely under FIPS 140-2 level 3 systems is a must.
Bruce Schneier, a universally respected American cryptographer, and security researcher, writes about key security with so much severity that you cannot help but feel a little guilty at everything you are not doing:
“One of the biggest risks in any CA-based system is with your own private signing key. How do you protect it? You almost certainly don’t own a secure computing system with physical access controls, TEMPEST shielding, “air wall” network security, and other protections; you store your private key on a conventional computer. There, it’s subject to attack by viruses and other malicious programs. Even if your private key is safe on your computer, is your computer in a locked room, with video surveillance, so that you know no one but you ever uses it? If it’s protected by a password, how hard is it to guess that password? If your key is stored on a smartcard, how attack-resistant is the card? [Most arevery weak.] If it is stored in a truly attack-resistant device, can an infected driving computer get the trustworthy device to sign something you didn’t intend to sign?”
If you are saving key-strings in a spreadsheet, on a thumb drive, on a normal hard drive, or even somewhere online that is remotely accessible—you are making a mistake. Honestly, you probably should be using an HSM.