With so much changing in the world, it’s important to stay up to date with the best ways to keep certificates safe. That’s one of the reasons that NIST 1800-16 outlines the most recent official guidelines. These best practices should be standard implementation for any professional organization dealing with certificate management. While the full version can be found here, the following few standards provide a good head start.
Part 1—Establishing TLS Server Certificate Policies
Inventory: NIST recommends one central inventory location to keep track of all TLS server certificates.
This recommendation presupposes that visibility of all certificates has been acquired through an environment scan and that all existing certificates have been found. Proper visibility involves accounting for the following:
- Certificate Authorities (CAs), which provide most certificates. Solution should sync with both internal and external CAs.
- Devices and endpoints on which a certificate can be found
- Key and certificate stores. Certificates should not be linked to a port can be hidden here.
Visibility should also provide ownership information for each certificate, as well as mapping certificates back to their servers. Once certificates are accounted for and aggregated into that one inventory, it is important to organize the findings for maximum efficacy. You can group the certificates by environment—such as ‘test’ and ‘production’—or by business function, which will allow for easier tracking.
CIO Study: Outages Escalating with Massive Growth in Machine Identities
Private Key Security: The private key to any TLS server must always remain uncompromised.
Many times, private keys are stored in plaintext files, and even when encrypted, the passwords to these files are themselves stored in plaintext. In previous blogs, I have recommended that you store private keys in equipment regulated to the FIPS 140-2 standard. This would include Hardware Security Models (HSMs). However, many organizations have not adopted this practice due to the large number of TLS servers that require private keys.
When the system is mission-critical however, the protocol is to secure the private key in an HSM. In all other situations, access to plaintext-stored passwords should only be given to authorized personnel who have completed training on private key security practices. This should be on a strictly role-based, least privilege approach.
Proactive Certificate Renewal: Certificates should be renewed prior to expiration.
This involves a multi-step process: requesting, installation and testing. These should be initiated proactively well before the expiration date—if something goes awry, the old certificate can be used to plug the gap (if not expired) until the new one can be installed correctly. This avoids last minute fire drills on the part of supporting teams, as well as preventable downtime should the certificate expire. In regulation, NIST puts it thus:
- Renewal, installation and testing of certificates should be completed at least 30 days prior to the expiration date.
- If the certificate lifespan is under 60 days, the renewal process should be completed prior to 80% of the total validity period elapsing.
Part 2—Establish a Certificate Service
Automated Enrollment and Installation: Several options for automation in certificate management should be provided.
This is due to the inherent risks of manual certificate management and the need to spin up instances quickly in the cloud. The following options are possible avenues for automation:
- Programmatic Automation—Use APIs that enable certificate renewal, revocation, reporting, etc. These should integrate with other DevOps frameworks.
- Standard Protocol Support—Use the following protocols when requesting certificates: Simple Certificate Enrollment Protocol (SCEP), 1253 Automated Certificate Management Environment (ACME), and Enrollment over Secure Transport.
- Proprietary Automation—Create your own approach (via APIs, command-line utilities, etc.) to authentication and enrollment automation should your system not support the first two methods.
- Secure Key Transport –If your organization supports TLS traffic monitoring and decryption, automated systems for transporting TLS private keys from TLS servers to the decryption devices should be in place.
- HSM Integration—Automation should allow you to integrate with HSMs when they are being used to store private keys.
Reporting and Analytics: Reporting should be implemented to spot anomalies and plan for certificate management risks.
Triggered automated notifications serve well to warn of immediate risks, but dashboards help in pre-planning. Adequate reporting should cover the following areas:
- Custom Reporting—Reports should be customizable to be of most effective use to parties involved (custom data, filtering, timing of execution, etc.)
- Dashboards—Should proactively alert to risks (expirations, weak keys/algorithms, anomalies, trends and threats)
- Interfaces—Automated incident response systems should be used to alert responsible parties of errors and next steps within the certificate management process
This watchdog approach ensures that in an environment where certificates are automatically being requested, renewed, and deployed, something doesn’t mistakenly slip off the tracks and remain undetected. This takes full advantage of the vast amount of data automation gathers and synthesizes it in a way that is easy to catch outlying, and potentially dangerous, trends.
Continuous Monitoring: The certificates, along with all certificate management processes, should be monitored for incident or error.
Continuous monitoring ensures gaps get watched within the PKI structure surrounding your certificate management. This ties together all areas—the elements of your certificate management process, all CAs and automation. The best monitoring systems will present easy-to-read dashboards warning of expiration times and alerting responsible parties of mission-critical next tasks. Forgetting the details, at the tip of the spear monitoring should be actionable. The three areas outlined by NIST are:
- Expiration Monitoring—Notifications should be sent out with time enough to renew certificates before their expiration deadlines (at 30, 60 and 90 days prior). If no action is taken, alerts should be automatically sent to a central compliance team.
- Configuration Monitoring—Any deviation from the normal state of the certificate configuration process should be reported once that state is established.
- Policy Compliance—Alerts should be sent when any deployed certificates are out of compliance.
Conclusion
There are a few unifying themes among so many individual standards and guidelines—three of these are visibility, intelligence and automation. One cannot protect what one cannot see (visibility). One cannot organize what one does not know (intelligence/reporting), and the risks are too great if one does it all by hand (automation). If most of this seems like monitoring and oversight, you’re right. It is.
Once correct security levels have been put in place (key lengths, correct storing of private keys, etc.), then the most important part of keeping certificate management running is to simply automate all correct processes and watch for flaws. For example, there isn’t a need for a hundred single-handed mechanics, when ten mechanics on an assembly line will do. Set up your ‘assembly line’ of automation, free up the other 90 employees, and monitor for errors. Anything else, now, would be below industry standard for contemporary certificate management.
Venafi TLS Protect is a solution that discovers all certificates within your environment, providing the intelligence necessary to fully automate your certificate installation and management process. Interested in learning more? Download the TLS Protect Data Sheet today.
Get a 30 Day Free Trial of TLS Protect Cloud, Automated Certificate Management.
Related posts