米国 NIST SP 1800-37 エンタープライズ内におけるTLS 1.3の可視性課題への対応:概要文書
こんにちは、丸山満彦です。
NISTがNIST SP 1800-37 エンタープライズ内におけるTLS 1.3の可視性課題への対応:概要文書を公表していますね...
TLS 1.3環境下でも通信の可視性を確保するための複数の技術的アプローチを提示するものですね...
● NIST - ITL
・2025.09.17 NIST SP 1800-37 Addressing Visibility Challenges with TLS 1.3 within the Enterprise: High-Level Document
| NIST SP 1800-37 Addressing Visibility Challenges with TLS 1.3 within the Enterprise: High-Level Document | NIST SP 1800-37 エンタープライズ内におけるTLS 1.3の可視性課題への対応:概要文書 |
| Abstract | 要約 |
| The Transport Layer Security (TLS) protocol is widely deployed to secure network traffic. TLS 1.3 protects the contents of its previous TLS communications even if a TLS-enabled server is compromised. This is known as forward secrecy. The approach used to achieve forward secrecy in TLS 1.3 may interfere with passive decryption techniques that enterprises rely on to have visibility into their TLS 1.2 traffic. Enterprises’ authorized network security staff rely on that visibility to protect its data and systems with critical cybersecurity controls to meet operational needs and legal requirements. Adoption of the TLS 1.3 protocol can disrupt current approaches to observing and monitoring internal network communications within an enterprise. | トランスポート層セキュリティ(TLS)プロトコルは、ネットワーク通信を保護するために広く展開されている。TLS 1.3は、TLS対応サーバーが侵害された場合でも、過去のTLSコミュニケーションの内容を防御する。これはフォワードシークレシー(前方秘匿性)として知られる。TLS 1.3で前方秘匿性を実現する手法は、エンタープライズがTLS 1.2トラフィックの可視性を確保するために依存する受動的復号技術と干渉する可能性がある。エンタープライズの認可されたネットワークセキュリティ担当者は、業務上の必要性と法的要件を満たすために、重要なサイバーセキュリティ対策でデータとシステムを保護する上で、この可視性に依存している。TLS 1.3プロトコルの採用は、エンタープライズ内ネットワーク通信を監視・観察する現行の手法を妨げる恐れがある。 |
| The NCCoE, in collaboration with technology providers and enterprise customers, initiated a project to demonstrate options for maintaining visibility within the TLS 1.3 protocol using several standards-compliant builds that enterprises can use for real-time and post-facto systems monitoring and analytics capabilities. | NCCoEは、技術プロバイダやエンタープライズ顧客と連携し、エンタープライズがリアルタイムおよび事後的なシステム監視・分析機能に利用できる複数の標準ビルドを用いて、TLS 1.3プロトコル内での可視性を維持する選択肢を実証するプロジェクトを開始した。 |
| This publication contains demonstrated proofs of concept along with links to detailed technical information online on NIST pages. This publication also includes links to mappings of TLS 1.3 visibility principles to commonly used security standards and guidelines. | 本資料には実証済みの概念実証(PoC)と、NISTページ上の詳細技術情報へのリンクが含まれる。また、TLS 1.3可視性原則と一般的なセキュリティ標準・ガイドラインのマッピングへのリンクも掲載されている。 |
・[PDF] NIST.SP.1800-37
目次...
| 1 Executive Summary | 1 エグゼクティブサマリー |
| 2 Introduction | 2 序論 |
| 2.1 Audience | 2.1 対象読者 |
| 2.2 How to use this Guide | 2.2 本ガイドの利用方法 |
| 3 Project Overview | 3 プロジェクト概要 |
| 3.1 Background | 3.1 背景 |
| 3.2 Solution | 3.2 ソリューション |
| 4 Architecture and Builds | 4 アーキテクチャとビルド |
| 4.1 Project Collaborators | 4.1 プロジェクト協力者 |
| 4.1.1 AppViewX | 4.1.1 AppViewX |
| 4.1.2 DigiCert | 4.1.2 DigiCert |
| 4.1.3 F5 | 4.1.3 F5 |
| 4.1.4 JPMorgan Chase & Co. | 4.1.4 JPMorgan Chase & Co. |
| 4.1.5 Mira Security | 4.1.5 Mira Security |
| 4.1.6 NETSCOUT | 4.1.6 NETSCOUT |
| 4.1.7 Not for Radio | 4.1.7 Not for Radio |
| 4.1.8 Thales Trusted Cyber Technologies | 4.1.8 Thales Trusted Cyber Technologies |
| 4.2 Architecture and Builds | 4.2 アーキテクチャと構築 |
| 4.2.1 System Architecture Functions | 4.2.1 システムアーキテクチャの機能 |
| 4.2.2 High-Level Passive Inspection Architecture Overview | 4.2.2 高レベル受動検査アーキテクチャの概要 |
| 4.2.3 High-Level Middlebox Architecture Overview | 4.2.3 高レベルミドルボックスアーキテクチャの概要 |
| 5 Build Implementation | 5 構築の実装 |
| 5.1 Passive Inspection Architecture Builds | 5.1 受動検査アーキテクチャの構築 |
| 5.1.1 Bounded-Lifetime Key Pair (Bounded-Lifetime Diffie-Hellman) | 5.1.1 有効期限付き鍵ペア(有効期限付きディフィー・ヘルマン) |
| 5.1.2 Decryption Using Exported Session Keys | 5.1.2 エクスポートセッション鍵を用いた復号 |
| 5.2 Break and Inspect Using Middleboxes | 5.2 ミドルボックスを用いた解読と検査 |
| 5.2.1 Real-Time (RT) Decryption | 5.2.1 リアルタイム(RT)復号 |
| 5.2.2 Post-Facto Decryption (follows RT Decryption steps) | 5.2.2 事後復号(RT復号手順に続く) |
| 5.2.3 Middlebox Laboratory Build Components | 5.2.3 ミドルボックス実験室構築コンポーネント |
| 5.2.4 Installation and Configuration for Active Middlebox Approach | 5.2.4 アクティブミドルボックスアプローチのインストールと設定 |
| 5.3 NCCoE Laboratory Physical Architecture | 5.3 NCCoE実験室物理アーキテクチャ |
| 5.4 Specific Details | 5.4 具体的な詳細 |
| 6. Functional Demonstrations | 6. 機能実証 |
| 6.1 Usage Scenarios Supported | 6.1 サポートされる使用シナリオ |
| 6.1.1 Troubleshooting Scenario | 6.1.1 トラブルシューティングシナリオ |
| 6.1.2 Performance Monitoring Scenario | 6.1.2 パフォーマンス監視シナリオ |
| 6.1.3 Cybersecurity Threat Triage and Forensics Scenario | 6.1.3 サイバーセキュリティ脅威のトリアージとフォレンジックシナリオ |
| 6.1.4 Monitoring for Compliance and Hygiene Scenario | 6.1.4 コンプライアンスと衛生状態の監視シナリオ |
| 6.2 Example Demonstration Events | 6.2 実証イベントの例 |
| 7. Risk and Compliance Management | 7. リスクマネジメント |
| 7.1 Threats | 7.1 脅威 |
| 7.2 Vulnerabilities | 7.2 脆弱性 |
| 7.3 Risk | 7.3 リスク |
| 7.4 Security Control Map | 7.4 セキュリティ制御マップ |
| 8. Demonstration and Future Considerations | 8. デモンストレーションと将来の検討事項 |
| 8.1 General Findings and Observations | 8.1 一般的な所見と観察 |
| 8.2 Future Build Considerations | 8.2 将来の構築に関する考慮事項 |
| 8.2.1 Planning for Visibility with Post-Quantum Cryptography (PQC) | 8.2.1 耐量子暗号(PQC)を用いた可視性の計画 |
| 8.2.2 Client-Based Monitoring | 8.2.2 クライアントベースの監視 |
| Appendix A: Glossary | 附属書 A: 用語集 |
| Appendix B: List of Acronyms | 附属書 B: 略語一覧 |
| Appendix C: References | 附属書 C: 参考文献 |
| Appendix D: Description of the Architectures | 附属書 D: アーキテクチャの説明 |
| D.1 Passive Inspection using Bounded-lifetime DH Server Keys | D.1 有効期限付きDHサーバーキーを用いた受動的検査 |
| D.2 Passive inspection using Exported Session Keys | D.2 エクスポートセッションキーを用いた受動的検査 |
| D.3 Active Inspection using a Break-and-Inspect Middlebox | D.3 侵入型ミドルボックスを用いた能動的検査 |
| Appendix E: Descriptions of the Build Implementations | 附属書E: ビルド実装の説明 |
| E.1 Shared Components Across All Builds | E.1 全ビルド共通の共有コンポーネント |
| E.2 Implementation of the Bounded Lifetime DH Key Architecture | E.2 有効期限付きDHキーアーキテクチャの実装 |
| E.3 Implementation of the Exported Session Key Architecture | E.3 エクスポートされたセッションキーアーキテクチャの実装 |
| E.4 Implementation of Middlebox Architecture Implementations | E.4 ミドルボックスアーキテクチャの実装 |
| Appendix F: Details of the Functional Demonstrations and Results | 附属書F: 機能実証の詳細と結果 |
| F.1 Traffic Visibility to Support Troubleshooting | F.1 トラブルシューティング支援のためのトラフィック可視化 |
| F.2 Traffic Visibility to Support Performance Monitoring | F.2 パフォーマンス監視支援のためのトラフィック可視化 |
| F.3 Traffic Visibility to Support Cybersecurity Threat Triage and Forensics | F.3 サイバーセキュリティ脅威のトリアージおよびフォレンジック支援のためのトラフィック可視化 |
| F.4 Traffic Visibility to Support Monitoring for Compliance and Hygiene | F.4 コンプライアンスおよび衛生状態監視支援のためのトラフィック可視化 |
| F.5 Functional Demonstration Scripts and Results | F.5 機能実証スクリプトと結果 |
| F.5.1 Scenario 1.1 – Identify Failed Network Traffic Due to Expired TLS PKI Certificates (Layer 4) | F.5.1 シナリオ 1.1 – 期限切れの TLS PKI 証明書による失敗したネットワークトラフィックの識別 (レイヤ4) |
| F.5.2 Scenario 1.2 – Identify and Log Protocol-Specific Distinct Characteristics of Layer 5, 6, and 7-type Service Utilization and Consumption Information | F.5.2 シナリオ1.2 – レイヤ5、6、7型サービスの利用・消費情報におけるプロトコル固有の識別特徴を特定し記録する |
| F.5.3 Scenario 1.3 – Identify, Collect, and Report on Protocol-Specific Error Status Codes for Services (Layer 5, 6, and 7-type status codes) | F.5.3 シナリオ1.3 – サービス向けプロトコル固有のエラーステータスコード(レイヤ5、6、7型ステータスコード)を特定、収集、報告する |
| F.5.4 Scenario 2.1 – Identify, Collect, and Report on Protocol-Specific Error Status Codes for Services. | F.5.4 シナリオ 2.1 – サービスのプロトコル固有エラー状態コードを識別、収集、報告する |
| F.5.5 Scenario 2.2 – Identify the Propagation of Performance Issues Throughout a System by Correlating Error Status Codes Across Component Services | F.5.5 シナリオ 2.2 – コンポーネントサービス間のエラー状態コードを相関分析し、システム全体におけるパフォーマンス問題の伝播を特定する |
| F.5.6 Scenario 2.3 – Develop Baselines for Traffic Performance Characteristics for Each Server | F.5.6 シナリオ 2.3 – 各サーバーのトラフィック性能特性に関するベースラインを開発する |
| F.5.7 Scenario 3.1 – Scan Network Flows Content for Malware | F.5.7 シナリオ 3.1 – ネットワークフローの内容をスキャンし、マルウェアを検出する |
| F.5.8 Scenario 3.2 – Scan Network Traffic for Unauthorized Encrypted Connections (i.e., unexpected encryption types, unauthorized encryption protocols, unencrypted traffic, traffic that can’t be decrypted, etc.) | F.5.8 シナリオ 3.2 – ネットワークトラフィックをスキャンし、不正な暗号化接続(予期しない暗号化タイプ、不正な暗号化プロトコル、暗号化されていないトラフィック、復号化できないトラフィックなど)を検出する |
| F.5.9 Scenario 3.3 – Scan Network Traffic Content for Known Command-andControl or Exfiltration Protocols | F.5.9 シナリオ 3.3 – 既知のコマンドアンドコントロールまたは情報漏洩プロトコルをネットワークトラフィック内容からスキャンする |
| F.5.10 Scenario 3.4 – Scan Network Traffic for Un-Sanitized User Input | F.5.10 シナリオ 3.4 – サニタイズされていないユーザー入力をネットワークトラフィックからスキャンする |
| F.5.11 Scenario 4.1 – Identify and Report on the Use of Outdated Protocols (and/or 'practices') | F.5.11 シナリオ 4.1 – 旧式プロトコル(および/または「慣行」)の使用を識別し報告する |
| Appendix G: Security Control Mapping | 附属書G: セキュリティ制御マッピング |
| List of Figures | 図一覧 |
| Figure 4-1 Middlebox (Break and Inspect) Functional Architecture | 図 4-1 ミドルボックス(解読・検査)機能アーキテクチャ |
| Figure 4-2 Passive Inspection - Exported Session Key Functional Architecture | 図 4-2 受動的検査 - 輸出セッションキー機能アーキテクチャ |
| Figure 4-3 Middlebox (Break and Inspect) Functional Architecture | 図 4-3 ミドルボックス(解読・検査)機能アーキテクチャ |
| Figure 5-1 Real-Time Bounded-Lifetime DH Passive Inspection Flow | 図 5-1 リアルタイム有限寿命DH受動的検査フロー |
| Figure 5-2 Post-Facto Bounded-Lifetime DH Passive Inspection Flow | 図 5-2 事後有限寿命DH受動的検査フロー |
| Figure 5-3 Passive Inspection Using Exported Session Keys | 図 5-3 エクスポートセッション鍵を用いた受動的検査 |
| Figure 5-4 Middlebox Break and Inspect Demonstration Elements | 図 5-4 ミドルボックス解読・検査実証要素 |
| Figure 8-1 Sample use of PQC KEM in TLS 1.3 Handshake | 図 8-1 TLS 1.3 ハンドシェイクにおける PQC KEM の使用例 |
| List of Tables | 表一覧 |
| Table 5-1: Build Components for the Passive Decryption Using Bounded Life-time Server Keys Reference Architecture | 表 5-1: 有限寿命サーバー鍵を用いた受動的復号化参照アーキテクチャの構築コンポーネント |
| Table 5-2: Build Components for the Passive Decryption Using Exported Session Keys Reference Architecture | 表 5-2: エクスポートセッション鍵を用いた受動的復号化のための構築コンポーネント(参照アーキテクチャ) |
| Table 5-3: Build Components for the Break and Inspect Decryption Reference Architecture (Layer 3 Implementation) | 表 5-3: 傍受・検査型復号化のための構築コンポーネント(参照アーキテクチャ)(レイヤ 3 実装) |
| Table 5-4: Build Components for the Break and Inspect Decryption Reference Architecture (Layer 2 Implementation) | 表 5-4: 傍受・検査型復号化のための構築コンポーネント(参照アーキテクチャ)(レイヤ 2 実装) |
| Table 6-1: Demonstration Events | 表 6-1: デモンストレーションイベント |
エグゼクティブサマリー...
| 1 Executive Summary | 1 エグゼクティブサマリー |
| There are sector specific requirements that call for organizations to monitor network activity, protect sensitive data, and demonstrate security controls. Enterprises leverage network traffic visibility in their security operations centers to prevent, detect, and respond to cybersecurity threats. Enterprises moving to newer network security protocol standards such as TLS 1.3 will face challenges for maintaining network traffic visibility. | 業界固有の要件により、組織はネットワーク活動を監視し、機密データを防御し、セキュリティ制御を実証することが求められる。企業はセキュリティ・オペレーションセンターにおいてネットワークトラフィックの可視性を活用し、サイバーセキュリティ脅威の防止、検知、対応を行っている。TLS 1.3などの新しいネットワークセキュリティプロトコル標準に移行するエンタープライズは、ネットワークトラフィックの可視性を維持する上で課題に直面する。 |
| Modern protocol designers have changed protocols to strengthen security properties that protect the secrecy of historical network traffic. This is possible even if the servers’ long-term secret keys are compromised—a property known as forward secrecy. However, forward secrecy has created significant challenges for the network visibility strategies used by enterprises. | 現代のプロトコル設計者は、過去のネットワークトラフィックの機密性を保護するセキュリティ特性を強化するためにプロトコルを変更した。これは、サーバーの長期秘密鍵が侵害された場合でも可能であり、フォワードシークレシーとして知られる特性である。しかし、フォワードシークレシーは、エンタープライズが使用するネットワーク可視性戦略に重大な課題をもたらした。 |
| The National Cybersecurity Center of Excellence (NCCoE), in collaboration with technology providers and enterprise customers, initiated a project demonstrating options for maintaining visibility within an enterprise adopting these new security protocols. The demonstrations are suitable for voluntary adoption across a wide range of enterprise architectures. They are scalable, actionable, and application protocol-agnostic, as well as usable in real-time following post-packet capture. | 国立サイバーセキュリティ・センター・オブ・エクセレンス(NCCoE)は、技術プロバイダやエンタープライズ顧客と連携し、これらの新セキュリティプロトコルを採用するエンタープライズ内での可視性維持オプションを実証するプロジェクトを開始した。これらの実証は、幅広いエンタープライズアーキテクチャにおける自主的な採用に適している。拡張性があり、実用可能で、アプリケーションプロトコルに依存せず、パケットキャプチャ後でもリアルタイムで使用可能だ。 |
| Enterprises using the Transport Layer Security (TLS) 1.2 protocol without forward secrecy deploy tools and architectural solutions that provide visibility into enterprise traffic within their network. Enterprises have regulatory and compliance requirements to maintain visibility into received network traffic to enable the organization’s security monitoring, analysis, and management policies. An enterprise will not be able to use its deployed tools and architectural solutions that provide visibility into enterprise TLS 1.2 traffic to have visibility into TLS 1.3 traffic. This publication includes demonstrated approaches for enterprises to adopt TLS 1.3 to allow enterprises to benefit from the security functionality of TLS 1.3 while maintaining the visibility into received network traffic. | フォワードシークレシーなしのTLS 1.2プロトコルを使用するエンタープライズは、ネットワーク内のエンタープライズトラフィック可視化を提供するツールやアーキテクチャソリューションを展開している。エンタープライズは、組織のセキュリティ監視・分析・管理ポリシーを可能にするため、受信ネットワークトラフィックの可視性を維持する規制およびコンプライアンス要件を抱えている。エンタープライズは、TLS 1.2トラフィックの可視化を提供する展開済みのツールやアーキテクチャソリューションを、TLS 1.3トラフィックの可視化に流用することはできない。本公開資料では、エンタープライズがTLS 1.3を採用し、受信ネットワークトラフィックの可視性を維持しつつTLS 1.3のセキュリティ機能を活用するための実証済みアプローチを提示する。 |
| This publication describes the motivation, approach, architecture, build implementation, demonstration scenarios, results, and risk and compliance management characteristics for the demonstrated proofs of concept. The top-level overview provides links to technical details that are contained in online NIST pages. The linked files provide detailed technical information for each demonstration that TLS visibility implementers can adopt in their own environments. The demonstrations in this publication to maintain visibility are not intended as a recommended default or even for common use but to assist in those areas where, as OMB M 22-09 states: “…as agencies segment their networks, move away from intranets, and permit access to enterprise services from any network, inspecting traffic in these environments will become less practical and less valuable over time. In other places, deep traffic inspection may be more valuable and can create less of an increase in attack surface.” | 本公開資料では、実証された概念実証(PoC)の動機、アプローチ、アーキテクチャ、構築実装、実証シナリオ、結果、リスクおよびコンプライアンス管理特性について記述する。トップレベルの概要には、オンラインのNISTページに含まれる技術詳細へのリンクが提供されている。リンク先ファイルには、TLS可視化実装者が自環境で採用可能な、各実証に関する詳細な技術情報が記載されている。本出版物における可視性維持のデモンストレーションは、推奨されるデフォルト設定や一般的な使用を意図したものではない。OMB M 22-09 が述べるように、「…政府機関がネットワークをセグメント化し、イントラネットから移行し、あらゆるネットワークからのエンタープライズサービスへのアクセスを許可するにつれて、こうした環境におけるトラフィックの検査は、時間の経過とともに実用的ではなくなり、価値も低下する」領域を支援することを目的としている。他の場所では、深層トラフィック検査がより価値を持ち、攻撃対象領域の増加を抑えられる可能性がある。」 |
● まるちゃんの情報セキュリティ気まぐれ日記
・2024.02.01 米国 NIST 意見募集 SP 1800-37(第2次初期ドラフト) エンタープライズにおけるTLS 1.3による可視性の課題への対応
・2023.05.14 米国 NIST 意見募集 SP 1800-37(ドラフト)TLS 1.3による可視性の課題への対応 [初期ドラフト]
« 国家サイバー統括室 (NCO) 「被害報告一元化に関するDDoS事案及びランサムウェア事案報告様式」(案)に関する意見の募集結果 (2025.09.25) | Main | NIST IR 8588(初期公開ドラフト) コミュニティ主導の差分プライバシー展開事例レポジトリ »

Comments