Addressing Visibility Challenges with TLS 1.3 within the Enterprise FAQs

NIST SP 1800-37 is a practice guide, not a standard, security guideline, or recommendation (e.g., Federal Information Processing Standard or 800-series Special Publication). NIST SP 1800-37 illustrates practical approaches to allow authorized users can adopt to gain visibility into TLS 1.3-protected network traffic for application servers within their controlled enterprise data centers.

Organizations 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 and understand threats and other anomalies, respond to cybersecurity incidents, and recover from those incidents. Organizations 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, compliance with which requires continuous network monitoring and security analysis. Visibility into both plaintext and ciphertext versions of the traffic is often necessary to comply with regulations and achieve institutional security objectives.

SP 1800-37 promotes enterprise migration from TLS 1.2 to TLS 1.3, which has security benefits over TLS 1.2.  NIST SP 1800-37 documents architectures that enable enterprises using TLS 1.3 to have visibility of TLS 1.3 network traffic. Enterprises who implement an architecture in SP 1800-37 can maintain their real-time and/or post-facto systems monitoring and analytics requirements which increases the probability of early detection of malicious activities and would allow for quicker mitigation and recovery from an attack. 

SP 1800-37 incorporates the actual demonstration scenarios and the proof-of-concept implementation configuration and demonstration steps that were absent in the previous drafts. The high-level approach, architecture, security characteristics, demonstration scenarios, and findings materials are provided in a single NIST SP 1800-37 pdf version. Detailed component configurations, demonstration scenarios and results, and security objective and control mapping information are shown in a web-based version at https://pages.nist.gov/nccoe-tls-visibility/. The intent of this publication approach is to improve accessibility to detailed material for technical managers, while permitting updates to technical implementation details without requiring revision and re-issuance of the entire practice guide.

No. The visibility techniques illustrated by NIST SP 1800-37 are restricted to connections, information, and processes within enterprises, rather than to the protections afforded to network traffic outside the enterprise.

1. The project demonstrates approaches and practices that meet common compliance, operations, and security requirements for network traffic visibility within an enterprise while gaining the performance and capability benefits that TLS 1.3 deployment offers.
2. SP 1800-37 documents the results of a collaborative effort to demonstrate secure management of servers’ cryptographic keys, secure management of recorded traffic, and access considerations to decrypted TLS traffic via a broad set of options, including:             
   1. Key-management mechanisms that defer forward secrecy until all copies of keying material needed to maintain current levels of network visibility are deleted such as copies retained to support passive decryption and inspection, referred to throughout this publication as passive. Passive inspection involves inspecting encrypted traffic without disrupting the data flow or requiring any changes to the network or applications using TLS.
   2. Network architectures that provide visibility, such as using overlays or incorporating middleboxes.

The practice guide’s visibility processes include:

1. Employing software access control mechanisms that restrict access to the information decrypted for security analysis for use by those individuals authorized by the organization to perform those roles.
2. Storing information retained for post-facto analysis only in encrypted form (re-encryption).
3. Securely handling and then eliminating keying material used for re-encryption of information retained for post-facto analysis as soon as the analysis of the traffic has been completed.

Not necessarily. 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—be analyzed using either 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 Connections (TIC) initiative.

No. RFC 8446 is the internet standard for TLS. Use of the approaches illustrated in NIST SP 1800-37 to achieve visibility within enterprise data centers into network traffic requires conformance to RFC 8446 for protection of traffic over the internet.

Processes such as network performance monitoring, application performance monitoring, and security and diagnostics activities require visibility into TLS 1.3-protected network traffic. To gain that visibility, staff should decrypt network data for deep packet inspection, security, and monitoring. Otherwise, security diagnostics are dependent on endpoint information and management tools which may not provide enough visibility into an organization’s network traffic, leaving the enterprise potentially vulnerable.

Some examples include network and data center operators who require network data. This data may provide information or perspectives of which the endpoints are not capable, such as holistic views of sessions that no single platform in the chain can provide. Network data may also be invaluable for determining where issues are occurring relative to middleboxes involved in sessions (e.g., firewalls, routers, proxies, and load balancers) to correlate and compare sub-sessions essential to performing fault domain isolation and general diagnostic triage. Network data is essential for issues that involve multiple platforms and/or organizations. It is even more critical when endpoints are experiencing problems or are in any way compromised.

No. SP 1800-37 assumes and supports using standard network products and libraries.

No. NIST SP 1800-37’s illustrated techniques are restricted to information exchanges within enterprise environments.

No. NIST SP 1800-37’s illustrated techniques are restricted to information exchanges within enterprise environments.

No. NIST SP 1800-37 illustrates techniques for achieving visibility within enterprise data centers and does not include geographically distributed networks of proxy servers.

No. NIST SP 1800-37’s illustrated techniques are restricted to information exchanges within enterprise environments.

NIST SP 1800-37’s illustrated techniques are restricted to information exchanges within enterprise environments. Endpoint solutions must become consistent and reliable recorders of all related events (enhanced logging). Additionally, a separate infrastructure for producing, collecting, storing, and parsing terabytes (or more) of data must be built. None of these steps are a simple proposition. Such an infrastructure will require deep packet inspection for certain data, as well as management of the infrastructure itself. Finally, if the true root cause is occurring at a middlebox device, endpoints will not see this information.

The passive inspection techniques illustrated do not affect the interactions between servers and enterprise clients other than those client systems dedicated to enterprise monitoring and analysis. Incoming traffic is tapped, and the tapped traffic is provided to in-house systems dedicated to network monitoring and analysis functions. Key management support to those functions is managed separately, and access management controls are in place to restrict admission to security monitoring and analytics processors and staff.

The visibility techniques illustrated in NIST SP 1800-37 do not prevent hosts and servers that would otherwise support new TLS 1.3 encryption schemes from using them.

The project envisions no protocol changes. The visibility techniques are illustrated only in scenarios using TLS 1.3.

Forward secrecy is maintained for internet traffic. To support post-facto analysis of network traffic, symmetric keys are retained within the enterprise for a period necessary to perform the analysis and are then destroyed to prevent future disclosure.