If you’re an IT or InfoSec executive in an enterprise that relies on secure communications to protect its data and operation, you need to read NIST Special Publication 1800-16, which provides essential guidance for managing TLS (Transport Layer Security) certificates and was recently published for public review.
If you’re wondering, “What is he talking about? We use TLS but what’s the big deal?”, the NIST guidance is for you.
Whatever business you’re in, your organization relies on TLS and TLS certificates to secure nearly ALL your communications and authenticate nearly ALL servers inside and outside your network boundaries. If you don’t have a formal TLS certificate management program in place, your organization is at risk of outages and breaches.
There are three major risks you face if you don’t effectively manage TLS certificates across your enterprise:
- Application Downtime: Significant outages of business applications due to expired certificates. Nearly every organization has experienced major business application outages due to mismanaged TLS certificates.
- Pivoting: Attackers moving undetected from system to system across your network after an initial intrusion because you lack visibility inside TLS-encrypted communications. Most of the sensitive data that attackers want is deep inside your networks so they have to pivot from system to system to get to it and to get it back out. They do that through encrypted TLS connections today.
- Lack of Crypto-Agility: The need to halt business operations because of inability to change large numbers of TLS certificates in response to a cryptographic issue such as a weak algorithm or bugs in cryptographic libraries. Challenges eliminating the use SHA-1 should have served as a wake-up call to organizations that they need to improve their crypto-agility.
Unlike most security technologies that are deployed and managed by central InfoSec teams, TLS is individually implemented and managed on each system where it is used; and each system requires a unique cryptographic credential, called a TLS certificate. This means every department that deploys/manages systems is deploying and managing TLS certificates themselves. Many organizations have a central team responsible for certificates (typically called the PKI team) but these teams are typically understaffed and, more importantly, don’t have the right processes and technology in place to effectively support all of the teams using TLS certificates to ensure that security and operational risks are mitigated.
Even if you’ve already invested in establishing a formal TLS certificate management program and feel like you’re doing pretty well, the NIST guidance can still help you. Because the use of TLS to secure communications is rapidly increasing to encompass all major business applications in organizations, this guidance will help you ensure your TLS certificates management program will effectively scale with the expanded use of TLS to address outages and security threats.
To make sure the guidance is clear and comprehensive, NIST has released it for public review and feedback. Considering the central role TLS plays in your organization’s security, it’s critical that the guidance provide your organization everything needed to effectively manage TLS certificates and contain risk. NIST needs your feedback on whether it meets that objective.
I recommend executives read 1800-16 Volume A. It provides a high-level view of TLS certificate risks and outlines an action plan for addressing them. Volume B provides more detailed background on TLS, TLS certificates, risks, and effective strategies for effectively managing TLS certificates across your enterprise. You should ask your team (security directors, managers, and architects) to read that volume and come back to you with a plan for how your organization will implement an effective TLS certificate management program.
As a result of poor TLS certificate management, many organizations are experiencing outages, finger pointing, and undetected pivoting by attackers because nearly all traffic is encrypted with TLS and InfoSec groups can’t see malicious traffic between systems. This guidance from NIST is designed to help you eliminate these issues. Read it, start implementing, and provide your feedback on anything you feel is missing.
In addition to the new SP 1800-16 guidance, NIST has been busy updating their other key and certificate management guidance and happen to have recently released a second draft of 800-57 Part 2 (Recommendation for Key Management, Part 2: Best Practices for Key Management Organizations) for public review. I’ll provide background on that in a separate post.