Addressing Visibility Challenges with TLS 1.3 within the Enterprise FAQs

This project aims to facilitate the adoption of the Internet Engineering Task Force’s TLS 1.3 transport layer security protocol by demonstrating technologies and architectures that can be deployed alongside TLS 1.3 to support continuous security monitoring and analysis of network traffic in enterprise environments. These approaches provide visibility to traffic within internal, enterprise networks while protecting data through encryption in-transit, key management controls, and access control policies.

Many enterprises rely on network monitoring and inspection tools to implement critical cybersecurity, operational, and regulatory controls, such as intrusion detection, troubleshooting, and fraud monitoring.  Some of these organizations have faced challenges supporting TLS 1.3 because some of the techniques that enterprises had used with TLS 1.2 to gain visibility into traffic protected by TLS no longer worked with TLS 1.3. NIST worked with private sector collaborators to demonstrate that necessary visibility within the enterprise can be achieved while implementing TLS 1.3.

NIST developed example visibility-preserving TLS 1.3 implementations as part of a collaborative effort supported by security product and service providers, financial and insurance users of transport layer security, federal cryptographic technology experts, and current and past IETF cryptographic experts.

No. NIST SP 1800-37 is a practice guide. As with all NIST practice guides, it provides example solutions to support particular challenges and use cases driven by industry sectors (in this case financial services and healthcare). NIST SP 1800-37 illustrates practical approaches that users can adopt to gain visibility within enterprise networks into TLS 1.3-protected network traffic.

SP 1800-37 facilitates enterprise migration from TLS 1.2 to the security-enhanced TLS 1.3. It permits enterprises to support their business and security-driven use cases within their control with TLS 1.3, which has a number of security benefits over TLS 1.2. 

Organizations must deploy a variety of cybersecurity tools, policies and practices to protect their people, information, and overall security. One such tool is continuous monitoring of their network traffic to detect threat-based and other anomalies, identify and understand the nature of the anomalies, respond to cybersecurity incidents, and recover from those incidents. 

Organizations also rely on zero trust principles, cybersecurity frameworks, and risk management frameworks to support cybersecurity monitoring and analysis objectives. Many of these organizations are also subject to federal and industry regulations and compliance which require continuous network monitoring and security analysis. Access to both plaintext and ciphertext versions of the traffic is often necessary to achieve institutional security requirements or objectives. 

No. Organizations can choose to meet their security, regulatory, and operational requirements in different ways.  Those that rely on network-based monitoring can adopt the solutions described in this project as they adopt TLS 1.3 in their enterprise. As an example, OMB M-22-09 recommends the use of secure cryptographic protocols like TLS 1.3, and it recognizes the need for deep traffic inspection in application environments with compensating controls to make sure that visibility and privileges are restricted to authorized users who have the need to perform their job. There are cases where the risks of weak or compromised network inspection devices can be higher for networks that service a diverse and dynamic set of users, devices, and network destinations, such as those used by the organization’s staff for day-to-day work. In cases where organizations segment their networks, move away from intranets, and permit access to enterprise services from any network, inspecting traffic in these environments may become more focused and dependent on business cases over time. Fine grained policy control over which sessions are inspected is recommended.

Network traffic that is not decrypted can and should still be analyzed using visible or logged metadata, machine learning techniques, and other heuristics for detecting anomalous activity. This is consistent with the U.S. government’s Trusted Internet Connection initiative.

The solutions described in the practice guide address privacy and security concerns associated with the decrypted data by including the following properties: 

1. They employ software access control mechanisms to restrict access to the information decrypted for security analysis only to individuals authorized by the organization to perform those roles.
2. They store information retained for post-facto analysis only in encrypted form (re-encryption).
3. They securely eliminate keying material used for re-encryption of information retained for post-facto analysis as soon as the analysis of the traffic has been completed.

No. RFC 8446 is the standard for transport layer security. Use of the approaches illustrated in NIST SP 1800-37 to achieve visibility within enterprise data centers into network traffic continue to require conformance to RFC 8446 for protection of traffic.