![New NIST TLS Management Guidelines for InfoSec [Expert Advice] - cover graphic](/_next/image/?url=https%3A%2F%2Fcdn.venafi.com%2F994513b8-133f-0003-9fb3-9cbe4b61ffeb%2Ff9831317-a388-4bab-868c-39000f422953%2Faid_field_img__179af0687059b3305e97e07d40b387ea.jpg%3Fw%3D864%26h%3D370%26fm%3Dwebp%26q%3D75%26fit%3Dcrop&w=3840&q=75&dpl=dpl_3EAuLccmwaq4KZ9GcZftJq5NbwLA){kind=small}
If you’re an InfoSec director, manager, or architect, here are a few questions for you:
- Have you ever had a breach where attackers were able to pivot from system to system inside your network because you weren’t monitoring activity inside of encrypted TLS connections?
- Has your organization ever had any high-profile application outages because of expired TLS certificates? If so, who did executive management berate and task with making sure it didn’t happen again:
- The business unit responsible for the system/application where the certificate was deployed?
- The security group/PKI team?
If you answered yes to either of these questions and answered that the security group got blamed for the certificate outage, NIST has just released guidance (Special Publication 1800-16B TLS Server Certificate Management) that you need to read. With organizations realizing they need to authenticate all machines and encrypt all communications, the use of TLS has exploded and the number of TLS certificates has risen into the thousands for many organizations. With the increased security organizations have gained with TLS, other risks have arisen related to TLS certificates.
Here’s the list of TLS certificate-related risks I included in a recent post for executives:
- 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: Business operations can actually come to a halt 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.
Many organizations have struggled to effectively manage TLS certificates and mitigate these risks because TLS certificates are so broadly deployed across a wide variety of systems that are managed by different IT groups and business units. I’ve talked with many organizations where security/PKI teams get blamed for certificate-related outages, even when they might have sent multiple email alerts to the group responsible for the certificate that expired.
If you’ve been feeling this pain, you need to read SP 1800-16B and talk to your executive chain about implementing the recommendations.
SP 1800-16B provides clear guidance on how to establish a TLS certificate management program to enable organizations to continue to broaden their use of TLS while minimizing any TLS certificate-related incidents and risks. The guidance includes:
- Certificate Policy Examples: There’s a lot involved in effectively managing TLS certificates. Many organizations have policies for things like minimum key lengths but don’t have policies for management-related topics, such as ensuring an inventory of all deployed certificates, renewing certificates before expiration, changing private keys/certificates when administrators are terminated, etc. SP 1800-16B provides a clear set of policies that organizations can leverage to establish clear governance.
- Recommended Responsibilities: As I’ve mentioned earlier, PKI teams are often blamed for certificate-related issues, even though they don’t have sufficient resources or access to address those issues (e.g., they don’t have the necessary system access to install a new certificate and private key before the existing one expires). SP 1800-16B provides recommended responsibilities for each policy so that organizations can ensure everyone knows what they’re supposed to do.
- Establishing a Certificate Service: Manually managing TLS certificates isn’t practical due to the large number of them that are being deployed. Consequently, organizations must provide IT groups and business units automated tools and central support. SP 1800-16B provides a blueprint for establishing a central certificate service that supports all groups.
- Making and Action Plan: Implementing an effective certificate management program across an enterprise involves many milestones and cooperation between groups. SP 1800-16B provides recommendations on how to setup a plan that will better ensure a successful certificate management program.
- Importance of Executive Involvement: Effective TLS certificate requires the cooperation of IT groups and business units that manage systems where TLS certificates are deployed. Gaining this cooperation is often challenging because these groups think the PKI team should be taking care of certificate related issued.
While you’re reading SP 1800-16B, you might consider sending SP 1800-16A to your executives. It provides an executive overview of the risks, challenges, and solutions for TLS certificates. Getting support and active engagement from executive management is critical to a successful certificate management program.
NIST SP 1800-16 A and B are both up for public review. If, as you’re reading them, you have any suggestions on how to make them better, please submit that feedback to NIST at this link.
Find out why you need machine identity management
Related posts