Skip to main content
banner image
venafi logo

New NIST TLS Management Guidelines for InfoSec [Expert Advice]

New NIST TLS Management Guidelines for InfoSec [Expert Advice]

NIST TLS Infosec Guidelines
December 11, 2018 | Paul Turner

If you’re an InfoSec director, manager, or architect, here are a few questions for you: 

  1. 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? 

  2. 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: 

  3. The business unit responsible for the system/application where the certificate was deployed? 

  4. 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: 

  1. 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. 

  1. 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. 

  1. 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

Related posts 

Subscribe to our Weekly Blog Updates!

Join thousands of other security professionals

Get top blogs delivered to your inbox every week

See Popular Tags

You might also like

NIST Guidelines TLS

What Executives Need to Know about New NIST Guidelines for TLS Management

Best Practices for Securing SSH: Defining SSH Policies

ssh key management

Best Practices for Securing SSH: Creating a Roadmap for Securing SSH

About the author

Paul Turner
Paul Turner

Paul Turner writes for Venafi's blog and is an expert in machine identity protection.

Read Posts by Author
get-started-overlay close-overlay cross icon
get-started-overlay close-overlay cross icon
Venafi Risk assessment Form Image

Sign up for Venafi Cloud


Venafi Cloud manages and protects certificates



* Please fill in this field Please enter valid email address
* Please fill in this field Password must be
At least 8 characters long
At least one digit
At last one lowercase letter
At least one uppercase letter
At least one special character
(@%+^!#$?:,(){}[]~`-_)
* Please fill in this field
* Please fill in this field
* Please fill in this field
*

End User License Agreement needs to be viewed and accepted



Already have an account? Login Here

×
get-started-overlay close-overlay cross icon

How can we help you?

Thank you!

Venafi will reach out to you within 24 hours. If you need an immediate answer please use our chat to get a live person.

In the meantime, please explore more of our solutions

Explore Solutions

learn more

Email Us a Question

learn more

Chat With Us

learn more
Chat