10 considerations in order to ensure business continuity for PKI
Every year, enterprises face unforeseen events that can disrupt operations. These events are rarely predictable and often create significant challenges for IT and security teams, the network, and even hardware supply chains. That’s where business continuity comes in – to ensure that core functions remain intact, despite the disruption. A critical component of business continuity is public key infrastructure (PKI).
At the core of enterprise IT, PKI is a fundamental tool used to protect sensitive data and secure connections across multiple business-critical applications. In fact, the average PKI today supports more than eight different applications, from customer-facing websites and services to private network and VPN access. If PKI is mishandled, though, it can create significant disruption and application downtime.
Business continuity planning must account for your PKI and all applications that depend on it. With increasing pressure on PKI to protect new use cases, such as cloud services, mobile and remote workforces, the ability to support scale, availability and assurance is even more critical.
Below are 10 considerations to ensure business continuity for your PKI:
1. Don’t cut corners during implementation – Sometimes it’s just too easy to click “next, next, next” when configuring a Microsoft CA (certificate authority), but simple missteps can expose your organization to serious risk and service disruptions down the line.
2. Track expiration dates – If your root CA is up for renewal in the next 8-12 months, you should start planning resources appropriately. If your root CA expires, all certificates issued from it expire. Industry-standard practice is to renew the root CA after 10 years, and re-key after 20 years.
3. Plan for physical access to your root CA – The foundation of trust for your PKI, a root CA should be kept offline, air-gapped from the network and protected with an HSM (hardware security module). However, this means that routine maintenance tasks, like publishing a certificate revocation list (CRL), require multiple staff to be physically present. If remote HSM cardholders are miles (not steps) from the root CA server, this becomes much more difficult.
4. Don’t forget about renewals – If a CA is down, you’ll be unable to issue new certificates, but if your CRL is expired, all your certificates become immediately unusable. That’s because most applications need to check the validity of certificates against a CRL or OCSP server. If they cannot reach the CRL server, or if the CRL itself is expired, users will be unable to access their application.
5. Leave a sufficient CRL overlap – There are three points in time that matter when it comes to your CRL: the time you publish it, the time it expires and the period of overlap in between. Remember that CRL publishing is a manual process for offline CAs. The purpose of this overlap is to provide time to manually push the new CRL before the old CRL expires, and to avoid a gap in availability.
6. Make sure your CDPs are internet-routable – When an application checks for revoked certificates, it retrieves the current CRL from a specified CRL distribution point (CDP). After the CRL is retrieved, it’s typically cached until it expires. If users move outside your network, the CDP must be reachable over the Internet to ensure that devices can still retrieve the new CRL when needed. The CRL should be accessible via an HTTP URL.
7. Check the disk space on your issuing CAs – Carefully consider if there is enough disk space on all issuing CA servers to handle expanded use. For example, if you enable thousands of remote workers with certificates for SSL VPN, you must ensure the CA database is equipped to store the influx of certificates and audit logs without latency issues.
8. Ensure regular backups – CA backups aren’t fool proof and need to be regularly tested. If you have a backup of your CA database but not the HSM, the CA can’t be recovered anyway. Ensure that everything is automatically and periodically backed up to ensure resiliency should a system failure occur.
9. Inventory certificates – It’s critical to keep a complete inventory of every certificate issued form both your internal and public CAs. Know where every certificate lives and which applications are dependent on them. If SSL VPN becomes a business-critical application for your workforce, you’ll need to re-assess the risk related to these certificates.
10. Track certificate expirations and ownership – Organizations cannot afford the application downtime or service disruptions caused by expired certificates. However, chasing down application owners to renew their certificates can be challenging if employees work remotely. As you build your inventory, actively monitor certificates, define clear responsibilities and notify owners well before expiration.
Periodic business continuity exercises should be performed to ensure a quick and efficient way to bring business operations back to normal in the case of a disruptive event. Proper access to the facilities and root CA should be reviewed. All documentation should be up to date, tested and understood by all stakeholders who would be involved in business continuity efforts.
If there is a legitimate need for a change, kick off a change control to update any documents. Think of them as living, breathing documents that evolve with the goal of maintaining the PKI’s intended level of assurance.