米国 NIST SP 1800-36 信頼できるIoT機器のネットワーク層の実装とライフサイクル管理:インターネットプロトコルベースのIoT機器とネットワークセキュリティの強化 (2025.11.25)
こんにちは、丸山満彦です。
NISTがSP 1800-36 信頼できるIoT機器のネットワーク層の実装とライフサイクル管理:インターネットプロトコルベースのIoT機器とネットワークセキュリティの強化 を公表していますね...
IoTデバイスに関する攻撃は2つあるとしていますね...
- デバイスが不正なネットワークに参加するよう誘導され、そのデバイスが制御される場合
- 悪意のあるデバイスがネットワークに侵入する場合
で、このような攻撃の影響を受けないようにするためには、
- デバイスとネットワークの身元および状態を証明・検証した上で、デバイスにネットワーク認証情報を提供するプロセス
- デバイスのライフサイクル全体を通じてIoTデバイスを安全に管理するための、スケーラブルで自動化されたメカニズム
が必要となりますね...
● NIST - ITL
| NIST SP 1800-36 Trusted Internet of Things (IoT) Device Network-Layer Onboarding and Lifecycle Management: Enhancing Internet Protocol-Based IoT Device and Network Security | NIST SP 1800-36 信頼できるIoT機器のネットワーク層のオンボーディングとライフサイクル管理:インターネットプロトコルベースのIoTデバイスとネットワークセキュリティの強化 |
| Abstract | 要約 |
| Establishing trust between a network and an Internet of Things (IoT) device (as defined in NIST Internal Report 8425) prior to providing the device with the credentials it needs to join the network is crucial for mitigating the risk of potential attacks. There are two possibilities for attack. One happens when a device is convinced to join an unauthorized network, which would take control of the device. The other occurs when a network is infiltrated by a malicious device. Trust is achieved by attesting and verifying the identity and posture of the device and the network before providing the device with its network credentials—a process known as network-layer onboarding. In addition, scalable, automated mechanisms are needed to safely manage IoT devices throughout their lifecycles, such as safeguards that verify the security posture of a device before the device is permitted to execute certain operations. In this practice guide, the National Cybersecurity Center of Excellence (NCCoE) applies standards, best practices, and commercially available technology to demonstrate various mechanisms for trusted network-layer onboarding of IoT devices in Internet Protocol based environments. This guide shows how to provide network credentials to IoT devices in a trusted manner and maintain a secure device posture throughout the device lifecycle, thereby enhancing IoT security in alignment with the IoT Cybersecurity Improvement Act of 2020. | ネットワークとIoT機器(NIST内部報告書8425で定義)の間に、デバイスがネットワークに参加するために必要な認証情報を提供する前に信頼関係を確立することは、潜在的な攻撃のリスクを緩和するために極めて重要である。攻撃の可能性は二つある。一つは、デバイスが不正なネットワークに参加するよう誘導され、そのデバイスが制御される場合である。もう一つは、悪意のあるデバイスがネットワークに侵入する場合である。信頼は、デバイスとネットワークの身元および状態を証明・検証した上で、デバイスにネットワーク認証情報を提供するプロセス(ネットワーク層オンボーディングと呼ばれる)によって達成される。さらに、デバイスのライフサイクル全体を通じてIoTデバイスを安全に管理するための、スケーラブルで自動化されたメカニズムが必要である。例えば、デバイスが特定の操作を実行することを許可する前に、そのセキュリティ状態を検証する保護手段などである。本実践ガイドでは、国立サイバーセキュリティ・センター・オブ・エクセレンス(NCCoE)が、標準、ベストプラクティス、市販技術を活用し、インターネットプロトコルベース環境におけるIoTデバイスの信頼できるネットワーク層オンボーディングを実現する様々なメカニズムを示す。本ガイドは、信頼できる方法でIoTデバイスにネットワーク認証情報をプロバイダし、デバイスライフサイクルを通じて安全なデバイス状態を維持する方法を示す。これにより、2020年IoTサイバーセキュリティ改善法に沿ったIoTセキュリティの強化を図る。 |
・[PDF] NIST.SP.1800-36
エグゼクティブサマリー...
| Executive Summary | エグゼクティブサマリー |
| Establishing trust between a network and an Internet of Things (IoT) device (as defined in NIST Internal Report 8425) prior to providing the device with the credentials it needs to join the network is crucial for mitigating the risk of potential attacks. There are two possibilities for attack. One happens when a device is convinced to join an unauthorized network, which would take control of the device. The other occurs when a malicious device infiltrates a network. Trust is achieved by attesting and verifying the identity and posture of the device and the network before providing the device with its network credentials—a process known as network-layer onboarding. In addition, scalable, automated mechanisms are needed to safely manage IoT devices throughout their lifecycles, such as safeguards that verify the security posture of a device before the device is permitted to execute certain operations. In this practice guide, the National Cybersecurity Center of Excellence (NCCoE) applies standards, best practices, and commercially available technology to demonstrate various mechanisms for trusted network-layer onboarding of IoT devices in Internet Protocol-based environments. This guide shows how to provide network credentials to IoT devices in a trusted manner and maintain a secure device posture throughout the device lifecycle, thereby enhancing IoT security. | ネットワークとモノのインターネット(IoT)デバイス(NIST内部報告書8425で定義されるもの)の間に、デバイスがネットワークに参加するために必要な認証情報をプロバイダする前に信頼関係を確立することは、潜在的な攻撃リスクの緩和のために極めて重要である。攻撃の可能性は二つある。一つは、デバイスが不正なネットワークに参加するよう誘導され、そのデバイスが制御される場合だ。もう一つは、悪意のあるデバイスがネットワークに侵入する場合である。 信頼は、デバイスとネットワークの身元および状態を証明・検証した上で、デバイスにネットワーク認証情報を提供するプロセス(ネットワーク層オンボーディングと呼ばれる)によって達成される。さらに、デバイスのライフサイクル全体を通じてIoTデバイスを安全に管理するための、スケーラブルで自動化されたメカニズムが必要である。例えば、デバイスが特定の操作を実行することを許可する前に、そのセキュリティ状態を検証する保護手段などである。 本実践ガイドでは、国立サイバーセキュリティ・センター・オブ・エクセレンス(NCCoE)が、標準、ベストプラクティス、市販技術を活用し、インターネットプロトコルベース環境におけるIoTデバイスの信頼性のあるネットワーク層オンボーディングを実現する様々なメカニズムを示す。本ガイドは、信頼性のある方法でIoTデバイスにネットワーク認証情報をプロバイダし、デバイスのライフサイクルを通じて安全な状態を維持する方法を示し、それによってIoTセキュリティを強化する。 |
| CHALLENGE | 課題 |
| With tens of billions of IoT devices connected worldwide and more being connected every day, it is unrealistic to onboard or manage a network of these devices manually. In addition, providing local network credentials at the time of manufacture requires the manufacturer to customize network-layer onboarding on a build-to-order basis, which prevents the manufacturer from taking full advantage of the economies of scale that could result from building identical devices for its customers. | 世界中で数百億台のIoTデバイスが接続され、日々さらに増加している現状では、これらのデバイスネットワークを手動でオンボーディングまたは管理することは非現実的である。さらに、製造時にローカルネットワーク認証情報を提供するには、製造事業者が受注生産ごとにネットワーク層のオンボーディングをカスタマイズする必要があり、顧客向けに同一デバイスを製造することで得られる規模の経済を十分に活用できなくなる。 |
| There is a need to have a scalable, automated mechanism to securely manage IoT devices throughout their lifecycles and, in particular, a trusted mechanism for providing IoT devices with their network credentials and access policy at the time of deployment on the network. It is easy for a network to falsely identify itself, yet many IoT devices onboard to networks without verifying the network’s identity and ensuring that it is their intended target network. Also, many IoT devices lack user interfaces, making it cumbersome to input network credentials manually. Wi-Fi is sometimes used to provide credentials over an open (i.e., unencrypted) network, but this onboarding method risks credential disclosure. Most home networks use a single password shared among all devices, so access is controlled only by the device’s possession of the password. This type of access does not consider a unique device identity or whether the device belongs on the network. This method also increases the risk of exposing credentials to unauthorized parties. Providing unique credentials to each device is more secure, but providing unique credentials manually would be resource-intensive and error-prone, risk credential disclosure, and cannot be performed at scale. | IoTデバイスのライフサイクル全体を通じて安全に管理するスケーラブルな自動化メカニズム、特にネットワーク展開時に信頼できる認証情報とアクセスポリシーを提供するプロバイダが必要だ。ネットワークは容易に偽装できるにもかかわらず、多くのIoTデバイスはネットワークの身元を確認せず、意図したターゲットネットワークであることを保証せずに接続してしまう。 また、多くのIoTデバイスにはユーザーインターフェースがなく、ネットワーク認証情報を手動で入力するのは面倒だ。Wi-Fiを使ってオープン(つまり暗号化されていない)ネットワーク経由で認証情報をプロバイダする場合もあるが、このオンボーディング方法では認証情報の漏洩リスクがある。 家庭用ネットワークの多くは全デバイスで共通のパスワードを使用するため、アクセス管理は単にパスワードの所持有無に依存している。この方式ではデバイス固有の識別やネットワークへの所属適格性が考慮されない。また認証情報を不正な第三者に晒すリスクも高まる。各デバイスに固有の認証情報をプロバイダする方が安全だが、手動での付与はリソースを大量に消費し、エラーが発生しやすく、認証情報漏洩のリスクもあり、大規模な運用には向かない。 |
| Once a device is connected to the network, if it becomes compromised, it can pose a security risk to both the network and other connected devices. Not keeping such a device current with the most recent software and firmware updates may make it more susceptible to compromise. The device could also be attacked through the receipt of malicious payloads. Once compromised, it may be used to attack other devices on the network or become part of a larger botnet, potentially participating in distributed denialof-service (DDoS) attacks or other malicious activities across the internet. | デバイスがネットワークに接続された後、侵害されるとネットワーク全体や他の接続デバイスにセキュリティリスクをもたらす可能性がある。最新のソフトウェアやファームウェア更新を適用しないまま放置すると、侵害されやすくなる。 デバイスは悪意のあるペイロードの受信を通じて攻撃される可能性もある。侵害された場合、ネットワーク上の他のデバイスを攻撃するために利用されたり、大規模なボットネットの一部となり、分散型サービス拒否(DDoS)攻撃やインターネット上のその他の悪意のある活動に参加する可能性がある。 |
| OUTCOME | 成果 |
| The outcome of this project is to enhance the security of systems by helping IoT device users, manufacturers, and vendors understand how to carry out trusted network layer onboarding. This project has developed examples of trusted onboarding solutions and demonstrated these solutions using sample technologies and various scenarios. The NCCoE has published the findings in this practice guide, a NIST Special Publication (SP) 1800 series composed of multiple volumes targeting different audiences. | 本プロジェクトの成果は、IoTデバイス利用者、製造事業者、ベンダーが信頼できるネットワーク層オンボーディングの実施方法を理解することで、システムのセキュリティを強化することである。本プロジェクトでは、信頼できるオンボーディングソリューションの事例を開発し、サンプル技術と様々なシナリオを用いてこれらのソリューションを実証した。NCCoEは、この実践ガイド(NIST 特別刊行物(SP)1800シリーズの一部であり、異なる対象者向けに複数の巻で構成される)に調査結果を公表した。 |
| This practice guide can help IoT device users: | この実践ガイドは、IoTデバイス利用者が以下のことを行うのに役立つ: |
| Understand how to onboard their IoT devices in a trusted manner to: | 信頼できる方法でIoTデバイスをオンボーディングする方法を理解し、以下の目的を達成する: |
| § Ensure that their network is not put at risk as new IoT devices are added to it | § ネットワークに新たなIoTデバイスが追加されても、ネットワークがリスクにさらされないようにする |
| § Safeguard their IoT devices from being taken over by unauthorized networks | § 不正なネットワークによるIoTデバイスの乗っ取りを防ぐ |
| § Provide IoT devices with unique credentials for network access | § IoTデバイスにネットワークアクセス用の固有認証情報を付与する |
| § Provide, renew, and replace device network credentials in a secure manner | § デバイスネットワーク認証情報を安全な方法で提供、更新、交換する |
| § Support ongoing protection of IoT devices throughout their lifecycles | § IoTデバイスのライフサイクル全体を通じた継続的な防御を支援する |
| This practice guide can help manufacturers and vendors of semiconductors, secure storage components, IoT devices, and network onboarding equipment: | この実践ガイドは、半導体、セキュアストレージコンポーネント、IoTデバイス、ネットワークオンボーディング機器の製造事業者およびベンダーが以下のことを行うのに役立つ: |
| Understand the desired security properties for supporting trusted network-layer onboarding and explore their options with respect to recommended practices for: | 信頼できるネットワーク層オンボーディングを支援するための望ましいセキュリティ特性を理解し、以下の推奨実践に関する選択肢を検討する: |
| § Providing unique credentials into secure storage on IoT devices at the time of manufacture to mitigate supply chain risks (i.e., device credentials) | § 製造事業者時にIoTデバイスのセキュアストレージへ固有の認証情報をプロバイダすることで、サプライチェーンリスクを緩和する(例:デバイス認証情報) |
| § Installing onboarding software on IoT devices | § IoTデバイスへのオンボーディングソフトウェアのインストール |
| § Providing IoT device purchasers with information needed to onboard the IoT devices to their networks (i.e., device bootstrapping information) | § IoTデバイス購入者に対し、自社のネットワークへIoTデバイスをオンボーディングするために必要な情報をプロバイダすること(例:デバイスブートストラップ情報) |
| § Integrating support for network-layer onboarding with additional security capabilities to provide ongoing protection throughout the device lifecycle | § ネットワーク層オンボーディングのサポートを、デバイスのライフサイクル全体を通じて継続的な防御を提供する追加のセキュリティ機能と統合すること |
| SOLUTION | 解決策 |
| The NCCoE recommends using trusted network-layer onboarding to provide scalable, automated, trusted ways to provide IoT devices with unique network credentials and manage devices throughout their lifecycles to ensure they remain secure. The NCCoE collaborated with technology providers and other stakeholders to implement example trusted network-layer onboarding solutions for IoT devices that: | NCCoEは、信頼できるネットワーク層オンボーディングを利用することを推奨する。これにより、IoTデバイスに固有のネットワーク認証情報を提供し、デバイスのライフサイクルを通じて管理する、スケーラブルで自動化された信頼できる方法を実現し、デバイスの安全性を確保する。NCCoEは技術プロバイダやその他の関係者と協力し、IoTデバイス向けの信頼できるネットワーク層オンボーディングソリューションの例を実装した。その内容は以下の通りである: |
| § provide each device with unique network credentials, | § 各デバイスに固有のネットワーク認証情報を付与する |
| § enable the device and the network to mutually authenticate, | § デバイスとネットワークの相互認証を可能にする |
| § send devices their credentials over an encrypted channel, | § 暗号化されたチャネルを介してデバイスに資格情報を送信する、 |
| § do not provide any person with access to the credentials, and | § いかなる人物の認証情報へのアクセス権の提供者ともなってはならない、 |
| § can be performed repeatedly throughout the device lifecycle. | § デバイスのライフサイクルを通じて繰り返し実行可能である。 |
| The capabilities demonstrated include: | 実証された機能には以下が含まれる: |
| § trusted network-layer onboarding of IoT devices, | § IoTデバイスの信頼できるネットワーク層でのオンボーディング、 |
| § repeated trusted network-layer onboarding of devices to the same or a different network, | § 同一または異なるネットワークへのデバイスの繰り返し信頼ネットワーク層オンボーディング、 |
| § trusted application-layer onboarding (i.e., automatic establishment of an encrypted connection between an IoT device and a trusted application service after the IoT device has performed trusted network-layer onboarding and used its credentials to connect to the network), and | § 信頼されたアプリケーション層でのオンボーディング(すなわち、IoTデバイスが信頼されたネットワーク層でのオンボーディングを実行し、その認証情報を使用してネットワークに接続した後、IoTデバイスと信頼されたアプリケーションサービス間の暗号化された接続を自動的に確立すること)、および |
| § software-based methods to provide device credentials in the factory and transfer device bootstrapping information from the device manufacturer to the device purchaser. | § ソフトウェアベースの手法による、工場でのデバイス認証情報のプロバイダ、およびデバイス製造事業者から購入者へのデバイス初期化情報の転送。 |
| Future capabilities could build upon this project by demonstrating the integration of trusted networklayer onboarding with additional zero trust-inspired [Note: See NIST SP 800-207] mechanisms beyond those currently demonstrated. Additionally, the Connectivity Standards Alliance Matter protocol was released after the initiation of this project, and therefore, it was not incorporated into the current capabilities. However, future community efforts could involve exploring the integration of this standard to enhance security and interoperability. | 将来の機能は、本プロジェクトを基盤として、信頼できるネットワーク層のオンボーディングと、現在実証されているものを超える追加のゼロトラストに基づく[注:NIST SP 800-207参照]メカニズムの統合を実証することで発展させられる。さらに、Connectivity Standards AllianceのMatterプロトコルは本プロジェクト開始後に公開されたため、現在の機能には組み込まれていない。しかし、将来のコミュニティ活動では、セキュリティと相互運用性を強化するため、この標準の統合を検討することが考えられる。 |
| This demonstration followed an agile methodology of building implementations (i.e., builds) iteratively and incrementally, starting with network-layer onboarding and gradually integrating additional capabilities that improve device and network security throughout a managed device lifecycle. This demonstration includes factory builds that simulate activities performed to securely provide device credentials during manufacturing, and five network-layer onboarding builds that demonstrate the Wi-Fi Easy Connect, Bootstrapping Remote Secure Key Infrastructure (BRSKI), and Thread Commissioning protocols. These builds also demonstrate both streamlined and independent trusted application-layer onboarding approaches, along with policy-based continuous assurance and authorization. The example implementations use technologies and capabilities from our project collaborators (listed below). | 本実証はアジャイル手法に従い、実装(ビルド)を反復的・漸進的に構築した。ネットワーク層オンボーディングから開始し、管理対象デバイスのライフサイクル全体を通じてデバイスとネットワークのセキュリティを向上させる追加機能を段階的に統合した。 本実証には、製造工程でデバイス認証情報を安全に提供する活動を模擬する工場ビルドと、Wi-Fi Easy Connect、Bootstrapping Remote Secure Key Infrastructure(BRSKI)、Thread Commissioningプロトコルを実証する5つのネットワーク層オンボーディング ビルドが含まれる。これらのビルドは、合理化された信頼できるアプリケーション層オンボーディング手法と独立した手法、およびポリシーベースの継続的保証と認可も実証している。実装例では、プロジェクト協力者(下記参照)の技術と機能を活用している。 |
| Collaborators | 協力者 |
| Aruba, a Hewlett Packard Enterprise company | Aruba(ヒューレット・パッカード・エンタープライズ傘下) |
| CableLabs | CableLabs |
| Cisco | Cisco |
| Foundries.io | Foundries.io |
| Kudelski IoT | クデルスキーIoT |
| NquiringMinds | NquiringMinds |
| NXP Semiconductors | NXPセミコンダクターズ |
| Open Connectivity | オープン・コネクティビティ |
| Foundation (OCF) | Foundation (OCF) |
| Sandelman Software Works | Sandelman Software ワークス |
| SEALSQ, a subsidiary of WISeKey | SEALSQ、WISeKeyの子会社 |
| Silicon Labs | シリコンラボ |
| While the NCCoE uses a suite of commercial products, services, and proof-of-concept technologies to address this challenge, this guide does not endorse these particular products, services, and technologies, nor does it guarantee compliance with any regulatory initiatives. Your organization's information security experts should identify the products and services that will best integrate with your IoT products, existing tools, IT and IoT system infrastructure, and operations. Your organization can adopt these solutions or one that adheres to these guidelines in whole, or you can use this guide as a starting point for tailoring and implementing parts of a solution. | NCCoE はこの課題に対処するため、一連の商用製品、サービス、概念実証技術を利用しているが、本ガイドはこれらの特定の製品、サービス、技術を推奨するものではなく、また、いかなる規制イニシアチブへの準拠を保証するものでもない。 組織の情報セキュリティ専門家は、自社の IoT 製品、既存ツール、IT および IoT システムインフラ、運用に最適に統合できる製品やサービスを識別すべきだ。組織はこれらのソリューション、あるいは本ガイドラインに完全に準拠したソリューションを採用することも、本ガイドを起点としてソリューションの一部をカスタマイズ・実装することも可能だ。 |
| HOW TO USE THIS GUIDE | 本ガイドの使用方法 |
| Depending on your role in your organization, you might use this guide in different ways: | 組織内での役割に応じて、このガイドの活用方法は異なる: |
| Business decision makers, such as chief information security, product security, and technology officers, can use this part of the guide, NIST SP 1800-36A: Executive Summary, to understand the project’s challenges and outcomes, as well as our solution approach. | 最高情報セキュリティ責任者、製品セキュリティ責任者、最高技術責任者などの経営意思決定者は、本ガイドの一部であるNIST SP 1800-36A:エグゼクティブサマリーを活用し、プロジェクトの課題と成果、ならびに当社のソリューションアプローチを理解できる。 |
| Technology, security, and privacy program managers who are concerned with how to identify, understand, assess, and mitigate risk can use NIST SP 1800-36B: Approach, Architecture, and Security Characteristics. This part of the guide describes the architecture and different implementations. Also, NIST SP 1800-36E: Risk and Compliance Management, maps components of the trusted onboarding reference architecture to security characteristics in broadly applicable, well-known cybersecurity guidelines and practices. | リスクの識別、理解、アセスメント、緩和の方法に関心を持つ技術、セキュリティ、プライバシープログラムの管理者は、NIST SP 1800-36B: アプローチ、アーキテクチャ、セキュリティ特性を利用できる。このガイドの部分では、アーキテクチャと様々な実装について説明している。 また、NIST SP 1800-36E「リスクとコンプライアンス管理」は、信頼できるオンボーディング参照アーキテクチャの構成要素を、広く適用可能な著名なサイバーセキュリティガイドラインや実践におけるセキュリティ特性にマッピングしている。 |
| IT professionals who want to implement an approach like this can make use of NIST SP 1800-36C: HowTo Guides. It provides product installation, configuration, and integration instructions for building example implementations, allowing them to be replicated in whole or in part. They can also use NIST SP 1800-36D: Functional Demonstrations, which provides the use cases defined to showcase trusted network-layer onboarding and lifecycle management security capabilities and the results of demonstrating these capabilities with each example implementation. These use cases may be helpful when developing requirements for systems being developed. | このようなアプローチを実装したいIT専門家は、NIST SP 1800-36C「ハウツーガイド」を活用できる。これは例示実装を構築するための製品インストール、設定、統合手順を提供し、全体または一部を複製することを可能にする。 また、NIST SP 1800-36D: 機能実証も利用できる。これは信頼できるネットワーク層オンボーディングとライフサイクル管理のセキュリティ機能を実証するために定義されたユースケースと、各 実装例を用いた機能実証結果を提供する。これらのユースケースは、開発中のシステム要件を策定する際に役立つ可能性がある。 |
| COLLABORATORS | 協力者 |
| Collaborators participating in this project submitted their capabilities in response to an open call in the Federal Register for all sources of relevant security capabilities from academia and industry (vendors and integrators). Those respondents with relevant capabilities or product components signed a Cooperative Research and Development Agreement (CRADA) to collaborate with NIST in a consortium to build this example solution. | このプロジェクトに参加した協力者は、学術界および産業界(ベンダーおよびインテグレーター)の関連セキュリティ機能に関するあらゆる情報源を募集する連邦官報の公募に応じて、その能力を提出した。関連能力または製品コンポーネントを有する対応者は、このサンプルソリューションを構築するためのコンソーシアムにおいて NIST と協力するため、共同研究開発契約(CRADA)に署名した。 |
| Certain commercial entities, equipment, products, or materials may be identified by name or company logo or other insignia in order to acknowledge their participation in this collaboration or to describe an experimental procedure or concept adequately. Such identification is not intended to imply special status or relationship with NIST or recommendation or endorsement by NIST or the NCCoE; neither is it intended to imply that the entities, equipment, products, or materials are necessarily the best available for the purpose. | 特定の商業事業体、機器、製品、または材料は、この共同作業への参加を認めるため、あるいは実験手順や概念を適切に説明するために、名称、会社のロゴ、その他の記章で識別される場合がある。このような識別は、NIST または NCCoE との特別な地位や関係、あるいは NIST または NCCoE による推奨や支持を意味するものではない。また、その事業体、機器、製品、または材料が、その目的に必ずしも最適であることを意味するものでもない。 |
目次...
| SP1800-36 Volume A: Executive Summary | SP1800-36A: エグゼクティブサマリー |
| SP1800-36 Volume B: Approach, Architecture, and Security Characteristics | SP1800-36B: アプローチ、アーキテクチャ、およびセキュリティ特性 |
| 1 Summary | 1 概要 |
| 1.1 Challenge | 1.1 課題 |
| 1.2 Soluon | 1.2 解決策 |
| 1.3 Benefits | 1.3 メリット |
| 2 How to Use This Guide | 2 このガイドの使用方法 |
| 2.1 Typographic Convenons | 2.1 組版上の慣例 |
| 2.2 Publicaon Structure | 2.2 出版物の構成 |
| 3 Approach | 3 アプローチ |
| 3.1 Audience | 3.1 対象読者 |
| 3.2 Scope | 3.2 適用範囲 |
| 3.3 Assumpons and Definions | 3.3 前提条件と定義 |
| 3.4 Collaborators and Their Contribuons | 3.4 協力機関とその貢献 |
| 4 Reference Architecture | 4 参照アーキテクチャ |
| 4.1 Device Manufacture and Factory Provisioning Process | 4.1 デバイス製造および工場プロビジョニングプロセス |
| 4.2 Device Ownership and Bootstrapping Informaon Transfer Process | 4.2 デバイス所有権とブートストラップ情報転送プロセス |
| 4.3 Trusted Network-Layer Onboarding Process | 4.3 信頼されたネットワーク層オンボーディングプロセス |
| 4.4 Trusted Applicaon-Layer Onboarding Process | 4.4 信頼されたアプリケーション層オンボーディングプロセス |
| 4.5 Connuous Verificaon | 4.5 継続的検証 |
| 5 Laboratory Physical Architecture | 5 実験室物理アーキテクチャ |
| 5.1 Shared Environment | 5.1 共有環境 |
| 5.2 Build 1 (Wi-Fi Easy Connect, Aruba/HPE) Physical Architecture | 5.2 ビルド 1 (Wi-Fi Easy Connect、Aruba/HPE) 物理アーキテクチャ |
| 5.3 Build 2 (Wi-Fi Easy Connect, CableLabs, OCF) Physical Architecture | 5.3 ビルド2(Wi-Fi Easy Connect、CableLabs、OCF)物理アーキテクチャ |
| 5.4 Build 3 (BRSKI, Sandelman Soware Works) Physical Architecture | 5.4 ビルド 3 (BRSKI、Sandelman Soware Works) 物理アーキテクチャ |
| 5.5 Build 4 (Thread, Silicon Labs, Kudelski IoT) Physical Architecture | 5.5 ビルド 4 (Thread、Silicon Labs、Kudelski IoT) 物理アーキテクチャ |
| 5.6 Build 5 (BRSKI, NquiringMinds) Physical Architecture | 5.6 ビルド 5 (BRSKI、NquiringMinds) 物理アーキテクチャ |
| 6 General Findings | 6 一般的な所見 |
| 6.1 Wi-Fi Easy Connect | 6.1 Wi-Fi Easy Connect |
| 6.2 BRSKI | 6.2 BRSKI |
| 6.3 Thread | 6.3 Thread |
| 6.4 Applicaon-Layer Onboarding | 6.4 アプリケーション層オンボーディング |
| 7 Addional Build Consideraons | 7 追加の構築上の考慮事項 |
| 7.1 Network Authencaon | 7.1 ネットワーク認証 |
| 7.2 Device Communicaons Intent | 7.2 デバイス通信意図 |
| 7.3 Network Segmentaon | 7.3 ネットワークセグメンテーション |
| 7.4 Integraon with a Lifecycle Management Service | 7.4 ライフサイクル管理サービスとの統合 |
| 7.5 Network Credenal Renewal | 7.5 ネットワーク認証情報の更新 |
| 7.6 Integraon with Supply Chain Management Tools | 7.6 サプライチェーン管理ツールとの統合 |
| 7.7 Atestaon | 7.7 認証 |
| 7.8 Mutual Atestaon | 7.8 相互認証 |
| 7.9 Behavioral Analysis | 7.9 行動分析 |
| 7.10 Device Trustworthiness Scale | 7.10 デバイス信頼性尺度 |
| 7.11 Resource Constrained Systems | 7.11 リソース制約システム |
| 8 References | 8 参考文献 |
| Appendix A | 附属書A 略語一覧 |
| Appendix B | 附属書B 用語集 |
| Appendix C Build 1 (Wi-Fi Easy Connect, Aruba/HPE) | 附属書C ビルド1(Wi-Fiイージーコネクト、Aruba/HPE) |
| C.1 Technologies | C.1 技術 |
| C.2 Build 1 Architecture | C.2 ビルド 1 アーキテクチャ |
| Appendix D Build 2 (Wi-Fi Easy Connect, CableLabs, OCF) | 附属書D ビルド2(Wi-Fiイージーコネクト、ケーブルラボズ、OCF) |
| D.1 Technologies | D.1 技術 |
| D.2 Build 2 Architecture | D.2 ビルド 2 アーキテクチャ |
| Appendix E Build 3 (BRSKI, Sandelman Soware Works) | 附属書 E ビルド 3 (BRSKI, Sandelman Soware Works) |
| E.1 Technologies | E.1 採用技術 |
| E.2 Build 3 Architecture | E.2 ビルド 3 アーキテクチャ |
| Appendix F Build 4 (Thread, Silicon Labs-Thread, Kudelski KeySTREAM) | 附属書F ビルド 4 (Thread、Silicon Labs-Thread、Kudelski KeySTREAM) |
| F.1 Technologies | F.1 技術 |
| F.2 Build 4 Architecture | F.2 ビルド4 アーキテクチャ |
| Appendix G Build 5 (BRSKI over Wi-Fi, NquiringMinds) | 附属書G ビルド 5 (BRSKI over Wi-Fi、NquiringMinds) |
| G.1 Technologies | G.1 技術 |
| G.2 Build 5 Architecture | G.2 ビルド5 アーキテクチャ |
| Appendix H Factory Provisioning Process | 附属書H 工場出荷時プロビジョニングプロセス |
| H.1 Factory Provisioning Process | H.1 工場出荷時プロビジョニングプロセス |
| H.2 Factory Provisioning Builds – General Provisioning Process | H.2 工場プロビジョニング構築 – 一般的なプロビジョニングプロセス |
| H.3 BRSKI Factory Provisioning Builds (NquiringMinds and SEALSQ) | H.3 BRSKIファクトリプロビジョニングビルド(NquiringMindsおよびSEALSQ) |
| H.4 Wi-Fi Easy Connect Factory Provisioning Build (SEALSQ and Aruba/HPE) | H.4 Wi-Fi Easy Connect ファクトリー・プロビジョニング・ビルド(SEALSQ および Aruba/HPE) |
| SP1800-36 Volume C: How-To Guides | SP1800-36C: ハウツーガイド |
| 1 Introduction | 1 序論 |
| 1.1 How to Use This Guide | 1.1 本ガイドの使用方法 |
| 1.2 Build Overview | 1.2 構築の概要 |
| 1.3 Typographic Conventions | 1.3 表記規則 |
| 2 Build 1 (Wi-Fi Easy Connect, Aruba/HPE) | 2 ビルド 1 (Wi-Fi Easy Connect、Aruba/HPE) |
| 2.1 Aruba Central/Hewlett Packard Enterprise (HPE) Cloud | 2.1 Aruba Central/Hewlett Packard Enterprise (HPE) Cloud |
| 2.2 Aruba Wireless Access Point | 2.2 Aruba ワイヤレスアクセスポイント |
| 2.3 Cisco Catalyst 3850-S Switch | 2.3 Cisco Catalyst 3850-S スイッチ |
| 2.4 Aruba User Experience Insight (UXI) Sensor | 2.4 Aruba User Experience Insight (UXI) センサー |
| 2.5 Raspberry Pi | 2.5 ラズベリーパイ |
| 2.6 Certificate Authority | 2.6 認証機関 |
| 2.7 UXI Cloud | 2.7 UXI Cloud |
| 2.8 Wi-Fi Easy Connect Factory Provisioning Build | 2.8 Wi-Fi Easy Connect ファクトリープロビジョニング構築 |
| 3 Build 2 (Wi-Fi Easy Connect, CableLabs, OCF) | 3 ビルド 2 (Wi-Fi Easy Connect、CableLabs、OCF) |
| 3.1 CableLabs Platform Controller | 3.1 CableLabsプラットフォームコントローラー |
| 3.2 CableLabs Custom Connectivity Gateway | 3.2 CableLabsカスタム接続ゲートウェイ |
| 3.3 Reference Clients/IoT Devices | 3.3 リファレンスクライアント/IoTデバイス |
| 4 Build 3 (BRSKI, Sandelman Software Works) | 4 ビルド 3 (BRSKI、Sandelman Software Works) |
| 4.1 Onboarding Router/Join Proxy | 4.1 オンボーディングルーター/参加プロキシ |
| 4.2 Minerva Join Registrar Coordinator | 4.2 Minerva Join レジストラコーディネーター |
| 4.3 Reach Pledge Simulator | 4.3 Reach Pledge Simulator |
| 4.4 Serial Console Server | 4.4 シリアルコンソールサーバー |
| 4.5 Minerva Highway MASA Server | 4.5 ミネルバ・ハイウェイ MASA サーバー |
| 5 Build 4 (Thread, Silicon Labs, Kudelski IoT) | 5 ビルド 4 (Thread、Silicon Labs、Kudelski IoT) |
| 5.1 Open Thread Border Router (OTBR) | 5.1 Open Thread Border Router (OTBR) |
| 5.2 Silicon Labs Dev Kit (BRD2601A) | 5.2 Silicon Labs開発キット(BRD2601A) |
| 5.3 Kudelski keySTREAM Service | 5.3 Kudelski keySTREAM サービス |
| 5.4 AWS IoT Core | 5.4 AWS IoT Core |
| 6 Build 5 (BRSKI over Wi-Fi, NquiringMinds) | 6 ビルド 5 (BRSKI over Wi-Fi、NquiringMinds) |
| 6.1 Pledge | 6.1 プレッジ |
| 6.2 Router and Logical Services | 6.2 ルーターと論理サービス |
| 6.3 Onboarding Demonstration | 6.3 オンボーディングデモ |
| 6.4 BRSKI Factory Provisioning Build | 6.4 BRSKI ファクトリプロビジョニングビルド |
| Appendix A | 附属書A 略語一覧 |
| Appendix B | 附属書B 参考文献 |
| SP1800-36 Volume D: Functional Demonstrations | SP1800-36D: 機能実証 |
| 1 Introduction | 1 序論 |
| 1.1 How to Use This Guide | 1.1 本ガイドの使用方法 |
| 1.2 Typographic Conventions | 1.2 表記規則 |
| 2 Functional Demonstration Playbook | 2 機能実証プレイブック |
| 2.1 Scenario 0: Factory Provisioning | 2.1 シナリオ 0: 工場プロビジョニング |
| 2.2 Scenario 1: Trusted Network-Layer Onboarding | 2.2 シナリオ 1: 信頼されたネットワーク層オンボーディング |
| 2.3 Scenario 2: Trusted Application-Layer Onboarding | 2.3 シナリオ 2: 信頼されたアプリケーション層オンボーディング |
| 2.4 Scenario 3: Re-Onboarding a Device | 2.4 シナリオ 3: デバイスの再オンボーディング |
| 2.5 Scenario 4: Ongoing Device Validation | 2.5 シナリオ 4: デバイスの継続的妥当性確認 |
| 2.6 Scenario 5: Establishment and Maintenance of Credential and Device Security Posture Throughout the Lifecycle | 2.6 シナリオ 5:ライフサイクル全体における認証情報とデバイスのセキュリティ態勢の確立と保守 |
| 3 Functional Demonstration Results | 3 機能実証結果 |
| 3.1 Build 1 Demonstration Results | 3.1 ビルド1の実証結果 |
| 3.2 Build 2 Demonstration Results | 3.2 ビルド 2 の実証結果 |
| 3.3 Build 3 Demonstration Results | 3.3 ビルド 3 の実証結果 |
| 3.4 Build 4 Demonstration Results | 3.4 ビルド 4 の実証結果 |
| 3.5 Build 5 Demonstration Results | 3.5 ビルド 5 の実証結果 |
| Appendix A | 附属書A 参考文献 |
| SP1800-36 Volume E: Risk and Compliance Management | SP1800-36E: リスク及びコンプライアンス管理 |
| 1 Introduction | 1 序論 |
| 1.1 How to Use This Guide | 1.1 本ガイドの使用方法 |
| 1.2 Typographic Conventions | 1.2 表記規則 |
| 2 Risks Addressed by Trusted Network-Layer Onboarding and Lifecycle Management | 2 信頼できるネットワーク層オンボーディングとライフサイクル管理が対処するリスク |
| 2.1 Risks to the Network | 2.1 ネットワークに対するリスク |
| 2.2 Risks to the Device | 2.2 デバイスに対するリスク |
| 2.3 Risks to Secure Lifecycle Management | 2.3 セキュアなライフサイクル管理に対するリスク |
| 2.4 Limitations and Dependencies of Trusted Onboarding | 2.4 信頼できるオンボーディングの制限と依存性 |
| 3 Mapping Use Cases, Approach, and Terminology | 3 マッピングのユースケース、アプローチ、および用語 |
| 3.1 Uses for Mappings of Build Functions to CSF 2.0 and SP 800-53 | 3.1 CSF 2.0 および SP 800-53 への構築機能マッピングの用途 |
| 3.2 Mapping Producers | 3.2 マッピング作成者 |
| 3.3 Mapping Approach | 3.3 マッピング手法 |
| 4. Mapping | 4. マッピング |
| 4.1 NIST CSF Subcategory Mappings | 4.1 NIST CSFサブカテゴリー対応表 |
| 4.2 NIST SP 800-53 Control Mappings | 4.2 NIST SP 800-53 コントロール対応表 |
| 5 References | 5 参考文献 |
● まるちゃんの情報セキュリティ気まぐれ日記
・2025.12.12 米国 NIST CSWP 42 IoTセキュリティの自動化に向けて:信頼できるネットワーク層オンボーディングの実装 (2025.11.25)
・2025.12.09 米国 NIST IR 8350 信頼できるIoTデバイスのネットワーク層オンボーディングにおける基礎概念:インターネットプロトコルベースのIoTデバイスとネットワークのセキュリティ強化 (2025.11.25)
・2024.06.08 米国 NIST SP 1800-36 (初期公開ドラフト) 信頼できるIoT機器のネットワーク層の実装とライフサイクル管理:インターネットプロトコルベースのIoT機器とネットワークのセキュリティ強化
・2023.11.03 NIST SP 1800-36 (初期ドラフト第2版) 信頼できるIoT機器のネットワーク層の実装とライフサイクル管理:インターネットプロトコルベースのIoT機器とネットワークのセキュリティ強化 (B,C,E)
・2023.09.30 NIST SP 1800-36 (初期ドラフト第2版) 信頼できるIoT機器のネットワーク層オンボーディングとライフサイクル管理:インターネットプロトコルベースのIoT機器とネットワークのセキュリティ強化 (A,D)
« 米国 カリフォルニア州消費者プライバシー法 2018年の2026年1月1日改正 | Main | 米国 NIST CSWP 42 IoTセキュリティの自動化に向けて:信頼できるネットワーク層オンボーディングの実装 (2025.11.25) »

Comments