米国 NIST SP 1800-36 (初期公開ドラフト) 信頼できるIoT機器のネットワーク層の実装とライフサイクル管理：インターネットプロトコルベースのIoT機器とネットワークのセキュリティ強化
こんにちは、丸山満彦です。
NISTがIPベースのIoTデバイスとネットワークのセキュリティ強化のための実践ガイドの初期ドラフトを公表、意見募集をしていますね。。。
2022年12月にA（エグゼクティブサマリー）が、2023年5月にBからEが、そして、2023年9月末はAとDの改訂ドラフト、2022年10月に残りのB, C, Eの改訂ドラフトを出していましたが、今回は全部揃えて、公開し、意見募集ですね...
● NIST - ITL
| NIST SP 1800-36 (Initial Public Draft) 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機器とネットワークのセキュリティ強化 |
| Announcement | 発表 |
| About the Project | プロジェクトについて |
| Provisioning network credentials to IoT devices in an untrusted manner leaves networks vulnerable to having unauthorized IoT devices connect to them. It also leaves IoT devices vulnerable to being taken over by unauthorized networks. Instead, trusted, scalable, and automatic mechanisms are needed to safely manage IoT devices throughout their lifecycles, beginning with secure ways to provision devices with their network credentials—a process known as trusted network-layer onboarding. Trusted network-layer onboarding, in combination with additional device security capabilities, such as device attestation, application-layer onboarding, secure lifecycle management, and device intent enforcement, could improve the security of networks and IoT devices. | 信頼されていない方法でIoTデバイスにネットワーク・クレデンシャルをプロビジョニングすると、ネットワークは無許可のIoTデバイスが接続する脆弱性を残す。また、IoTデバイスが不正なネットワークに乗っ取られる脆弱性も残る。その代わりに、IoTデバイスのライフサイクル全体を安全に管理するために、信頼され、スケーラブルで、自動的なメカニズムが必要とされ、そのためにはまず、デバイスにネットワーク・クレデンシャルをプロビジョニングする安全な方法（信頼されたネットワーク層のオンボーディングとして知られるプロセス）が必要である。信頼されたネットワーク・レイヤのオンボーディングは、デバイス認証、アプリケーション・レイヤのオンボーディング、セキュアなライフサイクル管理、デバイス・インテント実施などの追加のデバイス・セキュリティ機能と組み合わせることで、ネットワークと IoT デバイスのセキュリティを改善することができる。 |
| To help organizations protect both their IoT devices and their networks, the NCCoE collaborated with 11 IoT product and service providers. This joint effort resulted in the development of five functional technology solutions for trusted network-layer onboarding, as well as two factory provisioning builds, which are detailed in the practice guide. | 組織が IoT デバイスとネットワークの両方を保護できるよう、NCCoE は 11 社の IoT 製品およびサービス・プロバイダと協力した。この共同作業の結果、信頼できるネットワーク層のオンボーディングのための5つの機能的な技術ソリューションと、2つのファクトリー・プロビジョニングの構築が開発され、プラクティス・ガイドで詳述されている。 |
| 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 内部報告IR 8425で定義）の間の信頼を確立することは、潜在的な攻撃のリスクを低減するために極めて重要である。攻撃には2つの可能性がある。1つは、デバイスが不正なネットワークに参加するよう説得され、デバイスを制御される場合である。もうひとつは、悪意のあるデバイスによってネットワークに侵入された場合である。信頼は、デバイスにネットワーク・クレデンシャルをプロバイダダとして提供する前に、デバイスとネットワークのアイデンティティとポスチャを認証・検証することで達成される。さらに、デバイスが特定の操作を実行することを許可される前にデバイスのセキュリティ・ポスチャを検証するセーフガードなど、IoT デバイスをそのライフサイクル全体を通じて安全に管理するための拡張可能で自動化されたメカニズムが必要である。この実践ガイドでは、国立サイバーセキュリティ・センター・オブ・エクセレンス（NCCoE）が標準、ベストプラクティス、および商用利用可能な技術を適用して、インターネット・プロトコル・ベースの環境における IoT デバイスの信頼できるネットワーク層オンボーディングのためのさまざまなメカニズムを実証する。このガイドでは、信頼できる方法で IoT デバイスにネットワーク認証情報を提供し、デバイスのライフサイクル全体を通じて安全なデバイスの姿勢を維持する方法を示し、2020 年の IoT サイバーセキュリティ改善法に沿って IoT セキュリティを強化する。 |
 |
1800-36A ipd | Executive Summary | エグゼクティブサマリー |
 |
1800-36B ipd | Approach, Architecture, and Security Characteristics | アプローチ、アーキテクチャ、セキュリティの特徴 |
 |
1800-36C ipd | How-To Guides | ハウツーガイド |
 |
1800-36D ipd | Functional Demonstrations | 機能デモンストレーション |
 |
1800-36E ipd | Risk and Compliance Management | リスク・コンプライアンス・マネジメント |
| 1800-36A ipd | Executive Summary | エグゼクティブサマリー |
| 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 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 Internal Report 8425で定義）の間の信頼を確立することは、潜在的な攻撃のリスクを低減するために極めて重要である。攻撃には2つの可能性がある。1つは、デバイスが不正なネットワークに参加するよう説得され、デバイスを制御される場合である。もうひとつは、悪意のあるデバイスによってネットワークに侵入された場合である。信頼は、デバイスにネットワーク・クレデンシャルをプロバイダダとして提供する前に、デバイスとネットワークのアイデンティティとポスチャを認証・検証することで達成される。さらに、デバイスが特定の操作を実行することを許可される前にデバイスのセキュリティ・ポスチャを検証するセーフガードなど、IoT デバイスをそのライフサイクル全体を通じて安全に管理するための拡張可能で自動化されたメカニズムが必要である。この実践ガイドでは、国立サイバーセキュリティ・センター・オブ・エクセレンス（NCCoE）が標準、ベストプラクティス、および商用利用可能な技術を適用して、インターネット・プロトコル・ベースの環境における IoT デバイスの信頼できるネットワーク層オンボーディングのためのさまざまなメカニズムを実証する。このガイドでは、信頼できる方法で IoT デバイスにネットワーク認証情報を提供し、デバイスのライフサイクル全体を通じて安全なデバイスの姿勢を維持する方法を示し、それによって 2020 年 IoT サイバーセキュリティ改善法に沿った IoT セキュリティを強化する。 |
| CHALLENGE | 課題 |
| With 40 billion IoT devices expected to be connected worldwide by 2025, it is unrealistic to onboard or manage these devices by manually interacting with each device. 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. | 2025年までに世界中で400億台の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 manually input network credentials. 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 and 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, would risk credential disclosure, and cannot be performed at scale. | IoT デバイスをライフサイクルを通じて安全に管理するためのスケーラブルで自動化されたメカニズムが必要であり、特に、IoT デバイスにネットワーク認証情報とアクセス・ポリシーをネットワークへの展開時に提供するための信頼できるメカニズムが必要である。ネットワークがそれ自身を偽って識別するのは簡単だが、多くのIoTデバイスはネットワークの識別を検証せず、それが意図したターゲット・ネットワークであることを確認せずにネットワークにオンボードしている。また、多くのIoTデバイスにはユーザー・インターフェースがないため、ネットワークの認証情報を手動で入力するのが面倒である。オープンな（つまり暗号化されていない）ネットワーク上でクレデンシャルをプロバイダとして提供するためにWi-Fiが使用されることがあるが、このオンボーディング方法はクレデンシャル漏洩のリスクがある。ほとんどのホーム・ネットワークでは、すべてのデバイス間で共有される単一のパスワー ドを使用するため、アクセスはデバイスがパスワードを所有しているかどうかだけで管理さ れ、固有のデバイス ID やデバイスがネットワークに属しているかどうかは考慮されない。この方法はまた、認証情報を無許可の当事者にさらすリスクを増大させる。各デバイスに一意のクレデンシャルを提供することはより安全であるが、一意のクレデンシャルを手動で提供することは、リソース集約的でエラーが発生しやすく、クレデンシャル漏えいのリスクがあり、大規模に実行できない。 |
| 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 receipt of malicious payloads. Once compromised, it may be used to attack other devices on the network. | いったんデバイスがネットワークに接続されると、それが侵害された場合、ネットワークと他の接続デバイスの両方にセキュリティリスクをもたらす可能性がある。そのようなデバイスを最新のソフトウェアとファームウェア・アップデートに更新しておかないと、侵害を受けやすくなる可能性がある。デバイスはまた、悪意のあるペイロードを受信することで攻撃される可能性もある。いったん侵害されると、ネットワーク上の他のデバイスを攻撃するために使用される可能性がある。 |
| OUTCOME | 成果 |
| The outcome of this project is development of example trusted onboarding solutions, demonstration that they support various scenarios, and publication of the findings in this practice guide, a NIST Special Publication (SP) 1800 that is composed of multiple volumes targeting different audiences. | このプロジェクトの成果は、信頼されるオンボーディング・ソリューションの例を開発し、それらが様々なシナリオをサポートすることを実証し、その結果をこの実践ガイド（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 onto 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 the use of 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 that they remain secure. The NCCoE is collaborating 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, | IoTデバイスの信頼されたネットワークレイヤー・オンボーディング、▽同一または異なるネットワークへのデバイスの信頼されたネットワークレイヤー・オンボーディングの繰り返し、 |
| ▪ 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 device manufacturer to device purchaser. | 工場でデバイス認証情報を提供し、デバイスブートストラップ情報をデバイス製造事業者から デバイス購入者に転送する、ソフトウェアベースの方法。 |
| Future capabilities may include demonstrating the integration of trusted network-layer onboarding with zero trust-inspired [Note: See NIST SP 800-207] mechanisms such as ongoing device authorization, renewal of device network credentials, device attestation to ensure that only trusted IoT devices are permitted to be onboarded, device lifecycle management, and enforcement of device communications intent. | 将来の機能には、継続的なデバイス認可、デバイス・ネットワーク認証情報の更新、信頼された IoT デバイスのみがオンボードされることを保証するためのデバイス認証、デバイス・ライフサイクル管理、およびデバイス・コミュニケーション・インテントの実施など、ゼロトラストに触発された [注：NIST SP 800-207 を参照] メカニズムと信頼されたネットワーク層オンボーディングの統合の実証が含まれる可能性がある。 |
| This demonstration follows 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 includes factory builds that simulate activities performed to securely provide device credentials during the manufacturing process, 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 | ケーブルラボ |
| Cisco | シスコ |
| Foundries.io | Foundries.io |
| Kudelski IoT | クデルスキーIoT |
| NquiringMinds | NquiringMinds |
| NXP Semiconductors | NXPセミコンダクターズ |
| Open Connectivity | オープン・コネクティビティ |
| Foundation (OCF) | 財団（OCF） |
| Sandelman Software Works | サンデルマン・ソフトウェア・ワークス |
| SEALSQ, a subsidiary of | 子会社SEALSQ |
| WISeKey | 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 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は、この課題に対処するために一連の商用製品、サービス、および概念実証技術を使用しているが、本ガイドは、これらの特定の製品、サービス、および技術を推奨するものではなく、また、規制イニシアチブへの準拠を保証するものでもない。組織の情報セキュリティ専門家は、既存のツール、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 eference 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: How-To 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 that have been defined to showcase trusted network-layer onboarding and lifecycle management security capabilities and the results of demonstrating these capabilities with each of the example implementations. These use cases may be helpful when developing requirements for systems being developed. | このようなアプローチを実装したいIT専門家は、NIST SP 1800-36C: How-To Guidesを活用することができる。これは、実装例を構築するための製品のインストール、構成、統合の手順を提供するものであり、その全部または一部を複製することができる。また、NIST SP 1800-36D: Functional Demonstrations を使用することもできる。これは、信頼されたネットワーク層のオンボーディングとライフサイクル管理のセキュリティ機能を示すために定義されたユースケースと、各実装例でこれらの機能を実証した結果を提供するものである。これらのユースケースは、開発中のシステムの要件を策定する際に役立つ可能性がある。 |
B
| 1800-36B ipd | Approach, Architecture, and Security Characteristics | アプローチ、アーキテクチャ、セキュリティの特徴 |
目次...
| 1 Summary | 1 概要 |
| 1.1 Challenge | 1.1 課題 |
| 1.2 Solution | 1.2 ソリューション |
| 1.3 Benefits | 1.3 利点 |
| 2 How to Use This Guide | 2 このガイドの使い方 |
| 2.1 Typographic Conventions | 2.1 タイポグラフィの規則 |
| 3 Approach | 3 アプローチ |
| 3.1 Audience | 3.1 対象者 |
| 3.2 Scope | 3.2 範囲 |
| 3.3 Assumptions and Definitions | 3.3 前提条件および定義 |
| 3.3.1 Credential Types | 3.3.1 クレデンシャルタイプ |
| 3.3.2 Integrating Security Enhancements | 3.3.2 セキュリティ強化の統合 |
| 3.3.3 Device Limitations | 3.3.3 デバイスの制限 |
| 3.3.4 Specifications Are Still Improving | 3.3.4 仕様はまだ改善中である。 |
| 3.4 Collaborators and Their Contributions | 3.4 協力者とその貢献 |
| 3.4.1 Aruba, a Hewlett Packard Enterprise Company | 3.4.1 ヒューレット・パッカード・エンタープライズ傘下の Aruba |
| 3.4.2 CableLabs | 3.4.2 ケーブルラボ |
| 3.4.3 Cisco | 3.4.3 シスコ |
| 3.4.4 Foundries.io | 3.4.4 Foundries.io |
| 3.4.5 Kudelski IoT | 3.4.5 クデルスキーIoT |
| 3.4.6 NquiringMinds | 3.4.6 NquiringMinds |
| 3.4.7 NXP Semiconductors | 3.4.7 NXPセミコンダクターズ |
| 3.4.8 Open Connectivity Foundation (OCF) | 3.4.8 オープン・コネクティビティ・ファンデーション（OCF） |
| 3.4.9 Sandelman Software Works | 3.4.9 サンデルマンソフトウェアワークス |
| 3.4.10 SEALSQ, a subsidiary of WISeKey | 3.4.10 SEALSQ、WISeKeyの子会社 |
| 3.4.11 VaultIC408 | 3.4.11 VaultIC408 |
| 3.4.12 Silicon Labs | 3.4.12 シリコンラボ |
| 4 Reference Architecture | 4 リファレンス・アーキテクチャ |
| 4.1 Device Manufacture and Factory Provisioning Process | 4.1 デバイスの製造と工場でのプロビジョニング・プロセス |
| 4.2 Device Ownership and Bootstrapping Information Transfer Process | 4.2 デバイスの所有権とブートストラップ情報転送プロセス |
| 4.3 Trusted Network-Layer Onboarding Process | 4.3 信頼されたネットワーク層のオンボーディング・プロセス |
| 4.4 Trusted Application-Layer Onboarding Process | 4.4 信頼されたアプリケーション層のオンボーディング・プロセス |
| 4.5 Continuous Verification | 4.5 継続的検証 |
| 5 Laboratory Physical Architecture | 5 ラボ物理アーキテクチャ |
| 5.1 Shared Environment | 5.1 共有環境 |
| 5.1.1 Domain Controller | 5.1.1 ドメインコントローラ |
| 5.1.2 Jumpbox | 5.1.2 ジャンプボックス |
| 5.2 Build 1 (Wi-Fi Easy Connect, Aruba/HPE) Physical Architecture | 5.2 ビルド1（Wi-Fi Easy Connect、Aruba/HPE）の物理アーキテクチャ |
| 5.2.1 Wi-Fi Easy Connect Factory Provisioning Build Physical Architecture | 5.2.1 Wi-Fi Easy Connectファクトリー・プロビジョニング・ビルド物理アーキテクチャ |
| 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 Software Works) Physical Architecture | 5.4 ビルド3（BRSKI、Sandelman Software 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 Build 5 (BRSKI, NquiringMinds) 物理アーキテクチャ |
| 5.6.1 BRSKI Factory Provisioning Build Physical Architecture | 5.6.1 BRSKI Factory Provisioning Build 物理アーキテクチャ |
| 6 General Findings | 6 一般的な調査結果 |
| 6.1 Wi-Fi Easy Connect | 6.1 Wi-Fi Easy Connect |
| 6.1.1 Mutual Authentication | 6.1.1 相互認証 |
| 6.1.2 Mutual Authorization | 6.1.2 相互認可 |
| 6.1.3 Secure Storage | 6.1.3 安全なストレージ |
| 6.2 BRSKI | 6.2 BRSKI |
| 6.2.1 Reliance on the Device Manufacturer | 6.2.1 デバイス製造事業者への依存 |
| 6.2.2 Mutual Authentication | 6.2.2 相互認証 |
| 6.2.3 Mutual Authorization | 6.2.3 相互認可 |
| 6.2.4 Secure Storage | 6.2.4 安全なストレージ |
| 6.3 Thread | 6.3 スレッド |
| 6.4 Application-Layer Onboarding | 6.4 アプリケーション層のオンボーディング |
| 6.4.1 Independent Application-Layer Onboarding | 6.4.1 独立したアプリケーション層のオンボーディング |
| 6.4.2 Streamline Application-Layer Onboarding | 6.4.2 アプリケーション・レイヤー・オンボーディングの合理化 |
| 7 Additional Build Considerations | 7 追加の構築に関する考慮事項 |
| 7.1 Network Authentication | 7.1 ネットワーク認証 |
| 7.2 Device Communications Intent | 7.2 デバイス・コミュニケーションの意図 |
| 7.3 Network Segmentation | 7.3 ネットワーク・セグメンテーション |
| 7.4 Integration with a Lifecycle Management Service | 7.4 ライフサイクル管理サービスとの統合 |
| 7.5 Network Credential Renewal | 7.5 ネットワーク・クレデンシャルの更新 |
| 7.6 Integration with Supply Chain Management Tools | 7.6 サプライチェーン管理ツールとの統合 |
| 7.7 Attestation | 7.7 認証 |
| 7.8 Mutual Attestation | 7.8 相互認証 |
| 7.9 Behavioral Analysis | 7.9 行動分析 |
| 7.10 Device Trustworthiness Scale | 7.10 デバイス信頼性尺度 |
| 7.11 Resource Constrained Systems | 7.11 資源制約のあるシステム |
| Appendix A List of Acronyms | 附属書A 略語一覧 |
| Appendix B Glossary | 附属書B 用語集 |
| Appendix C Build 1 (Wi-Fi Easy Connect, Aruba/HPE) | 附属書C 構築1（Wi-Fi Easy Connect、Aruba/HPE） |
| C.1 Technologies | C.1 テクノロジー |
| C.2 Build 1 Architecture | C.2 Build 1アーキテクチャ |
| C.2.1 Build 1 Logical Architecture | C.2.1 ビルド1の論理アーキテクチャ |
| C.2.2 Build 1 Physical Architecture | C.2.2 Build 1 物理アーキテクチャ |
| Appendix D Build 2 (Wi-Fi Easy Connect, CableLabs, OCF) | 附属書D ビルド2（Wi-Fi Easy Connect、CableLabs、OCF） |
| D.1 Technologies | D.1 テクノロジ |
| D.2 Build 2 Architecture | D.2 ビルド2アーキテクチャ |
| D.2.1 Build 2 Logical Architecture | D.2.1 ビルド2の論理アーキテクチャ |
| D.2.2 Build 2 Physical Architecture | D.2.2 ビルド 2 物理アーキテクチャ |
| Appendix E Build 3 (BRSKI, Sandelman Software Works) | 附属書E ビルド3（BRSKI、Sandelman Software Works） |
| E.1 Technologies | E.1 テクノロジー |
| E.2 Build 3 Architecture | E.2 ビルド 3 アーキテクチャ |
| E.2.1 Build 3 Logical Architecture | E.2.1 ビルド 3 論理アーキテクチャ |
| E.2.2 Build 3 Physical Architecture | E.2.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 アーキテクチャ |
| F.2.1 Build 4 Logical Architecture | F.2.1 ビルド 4 論理アーキテクチャ |
| F.2.2 Build 4 Physical Architecture | F.2.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アーキテクチャ |
| G.2.1 Build 5 Logical Architecture | G.2.1 ビルド 5 論理アーキテクチャ |
| G.2.2 Build 5 Physical Architecture | G.2.2 ビルド 5 物理アーキテクチャ |
| Appendix H Factory Provisioning Process | 附属書 H 工場でのプロビジョニングプロセス |
| H.1 Factory Provisioning Process | H.1 工場でのプロビジョニングプロセス |
| H.1.1 Device Birth Credential Provisioning Methods | H.1.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.3.1 BRSKI Factory Provisioning Build Technologies | H.3.1 BRSKI 工場でのプロビジョニング構築技術 |
| H.3.2 BRSKI Factory Provisioning Build Logical Architectures | H.3.2 BRSKI 工場でのプロビジョニング構築論理アーキテクチャ |
| H.3.3 BRSKI Factory Provisioning Build Physical Architectures | H.3.3 BRSKI 工場でのプロビジョニング物理的アーキテクチャ |
| H.4 Wi-Fi Easy Connect Factory Provisioning Build (SEALSQ and Aruba/HPE) | H.4 Wi-Fi Easy Connect工場出荷時プロビジョニング構築（SEALSQおよびAruba/HPE） |
| H.4.1 Wi-Fi Easy Connect Factory Provisioning Build Technologies | H.4.1 Wi-Fi イージーコネクト工場でのプロビジョニング構築技術 |
| H.4.2 Wi-Fi Easy Connect Factory Provisioning Build Logical Architecture | H.4.2 Wi-Fi イージーコネクト工場でのプロビジョニング構築論理アーキテクチャ |
| H.4.3 Wi-Fi Easy Connect Factory Provisioning Build Physical Architecture | H.4.3 Wi-Fi イージーコネクト工場でのプロビジョニング物理アーキテクチャ |
| Appendix I References | 附属書 I 参考文献 |
C
| 1800-36C ipd | How-To Guides | ハウツーガイド |
| 1 Introduction | 1 序文 |
| 1.1 How to Use This Guide … | 1.1 このガイドの使用方法 ... |
| 1.2 Build Overview | 1.2 ビルドの概要 |
| 1.2.1 Reference Architecture Summary | 1.2.1 リファレンスアーキテクチャの概要 |
| 1.2.2 Physical Architecture Summary | 1.2.2 物理アーキテクチャの概要 |
| 1.3 Typographic Conventions | 1.3 タイポグラフィの規則 |
| 2 Build 1 (Wi-Fi Easy Connect, Aruba/HPE) | 2 ビルド 1 (Wi-Fi イージーコネクト、Aruba/HPE) |
| 2.1 Aruba Central/Hewlett Packard Enterprise (HPE) Cloud | 2.1 Aruba Central/Hewlett Packard Enterprise（HPE）クラウド |
| 2.2 Aruba Wireless Access Point | 2.2 Arubaワイヤレス・アクセス・ポイント |
| 2.2.1 Wi-Fi Network Setup and Configuration | 2.2.1 Wi-Fi ネットワークのセットアップと構成 |
| 2.2.2 Wi-Fi Easy Connect Configuration | 2.2.2 Wi-Fi イージーコネクトの設定 |
| 2.3 Cisco Catalyst 3850-S Switch | 2.3 Cisco Catalyst 3850-Sスイッチ |
| 2.3.1 Configuration | 2.3.1 構成 |
| 2.4 Aruba User Experience Insight (UXI) Sensor | 2.4 Aruba User Experience Insight (UXI) センサー |
| 2.4.1 Configuration | 2.4.1 構成 |
| 2.5 Raspberry Pi | 2.5 Raspberry Pi |
| 2.5.1 Configuration | 2.5.1 構成 |
| 2.5.2 DPP Onboarding | 2.5.2 DPP オンボーディング |
| 2.6 Certificate Authority | 2.6 認証局 |
| 2.6.1 Private Certificate Authority | 2.6.1 プライベート認証局 |
| 2.6.2 SEALSQ INeS | 2.6.2 SEALSQ INeS |
| 2.7 UXI Cloud | 2.7 UXIクラウド |
| 2.8 Wi-Fi Easy Connect Factory Provisioning Build | 2.8 Wi-Fi イージーコネクト工場でのプロビジョニング構築 |
| 2.8.1 SEALSQ VaultiC Secure Element | 2.8.1 SEALSQ VaultiC セキュアエレメント |
| 3 Build 2 (Wi-Fi Easy Connect, CableLabs, OCF) | 3 ビルド2（Wi-Fi イージーコネクト、CableLabs、OCF） |
| 3.1 CableLabs Platform Controller | 3.1 CableLabsプラットフォーム・コントローラ |
| 3.1.1 Operation and Demonstration | 3.1.1 操作とデモ |
| 3.2 CableLabs Custom Connectivity Gateway | 3.2 CableLabsカスタム接続ゲートウェイ |
| 3.2.1 Installation and Configuration | 3.2.1 インストールと設定 |
| 3.2.2 Integration with CableLabs Platform Controller | 3.2.2 ケーブルラボプラットフォームコントローラーとの統合 |
| 3.2.3 Operation and Demonstration | 3.2.3 操作とデモ |
| 3.3 Reference Clients/loT Devices | 3.3 リファレンスクライアント/loTデバイス |
| 3.3.1 Installation and Configuration | 3.3.1 インストールと設定 |
| 3.3.2 Operation and Demonstration | 3.3.2 操作とデモ |
| 4 Build 3 (BRSKI, Sandelman Software Works) | 4 ビルド3（BRSKI、サンデルマンソフトウェアワークス） |
| 4.1 Onboarding Router/Join Proxy | 4.1 オンボーディング・ルータ／ジョイン・プロキシ |
| 4.1.1 Setup and Configuration | 4.1.1 セットアップと設定 |
| 4.2 Minerva Join Registrar Coordinator | 4.2 Minerva Joinレジストラコーディネータ |
| 4.2.1 Setup and Configuration | 4.2.1 セットアップと設定 |
| 4.3 Reach Pledge Simulator | 4.3 リーチ誓約シミュレーター |
| 4.3.1 Setup and Configuration | 4.3.1 セットアップと設定 |
| 4.4 Serial Console Server | 4.4 シリアルコンソールサーバー |
| 4.5 Minerva Highway MASA Server | 4.5 Minerva Highway MASAサーバー |
| 4.5.1 Setup and Configuration | 4.5.1 セットアップと設定 |
| 5 Build 4 (Thread, Silicon Labs, Kudelski loT) | 5 ビルド4（スレッド、シリコンラボ、クデルスキーloT） |
| 5.1 Open Thread Border Router | 5.1 オープンスレッドボーダールーター |
| 5.1.1 Installation and Configuration | 5.1.1 インストールと設定 |
| 5.1.2 Operation and Demonstration | 5.1.2 動作とデモ |
| 5.2 Silicon Labs Dev Kit (BRD2601A) … | 5.2 Silicon Labs Dev Kit (BRD2601A) ... |
| 5.2.1 Setup and Configuration | 5.2.1 セットアップと設定 |
| 5.3 Kudelski keySTREAM Service | 5.3 Kudelski keySTREAMサービス |
| 5.3.1 Setup and Configuration | 5.3.1 セットアップと構成 |
| 5.4 AWS IoT Core | 5.4 AWS IoTコア |
| 5.4.1 Setup and Configuration | 5.4.1 セットアップと構成 |
| 5.4.2 Testing | 5.4.2 テスト |
| 6 Build 5 (BRSKI over Wi-Fi, NquiringMinds) | 6 ビルド5（BRSKI over Wi-Fi、NquiringMinds） |
| 6.1 Pledge | 6.1 誓約 |
| 6.1.1 Installation and Configuration | 6.1.1 インストールと設定 |
| 6.1.2 Operation and Demonstration | 6.1.2 操作とデモ |
| 6.2 Router and Logical Services | 6.2 ルータと論理サービス |
| 6.2.1 Installation and Configuration | 6.2.1 設置と設定 |
| 6.2.2 Logical services | 6.2.2 論理サービス |
| 6.3 Onboarding Demonstration | 6.3 オンボーディング・デモンストレーション |
| 6.3.1 Prerequisites | 6.3.1 前提条件 |
| 6.3.2 Onboarding Demonstration | 6.3.2 オンボーディング・デモンストレーション |
| 6.3.3 Continuous Assurance Demonstration | 6.3.3 継続的保証のデモンストレーション |
| 6.4 BRSKI Factory Provisioning Build | 6.4 BRSKIファクトリープロビジョニング構築 |
| 6.4.1 Pledge | 6.4.1 誓約 |
| 6.4.2 Installation and Configuration | 6.4.2 インストールと構成 |
| 6.4.3 Operation and Demonstration | 6.4.3 運用とデモンストレーション |
| List of Figures | 図一覧 |
| Figure 1-1 NCCoE loT Onboarding Laboratory Physical Architecture | 図 1-1 NCCoE loT Onboarding Laboratory 物理アーキテクチャ |
| Figure 6-1 Logical Services for Build 5 | 図 6-1 構築 5 の論理サービス |
| Figure 6-2 Diagram of Physical/Logical Components Used to Demonstrate BRSKI Flow | 図 6-2 BRSKI フローのデモに使用される物理／論理コンポーネント図 |
D
| 1800-36D ipd | Functional Demonstrations | 機能デモンストレーション |
| 1 Introduction | 1 序文 |
| 1.1 How to Use This Guide | 1.1 本ガイドの使用方法 |
| 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 References | 附属書A 参考文献 |
| List of Tables | 表一覧 |
| Table 2-1 Scenario 0 Factory Provisioning Capabilities That May Be Demonstrated | 表 2-1 シナリオ 0 工場出荷時のプロビジョニング機能 |
| Table 2-2 Scenario 1 Trusted Network-Layer Onboarding Capabilities That May Be Demonstrated | 表2-2 実証可能なシナリオ1 信頼されたネットワークレイヤーのオンボーディング機能 |
| Table 2-3 Scenario 2 Trusted Application-Layer Onboarding Capabilities That May Be Demonstrated | 表2-3 実証可能なシナリオ2 信頼されたアプリケーション層のオンボーディング能力 |
| Table 2-4 Scenario 3 Re-Onboarding Capabilities That May Be Demonstrated | 表2-4 シナリオ3 実証可能な再オンボーディング能力 |
| Table 2-5 Scenario 4 Ongoing Device Validation Capabilities That May Be Demonstrated | 表 2-5 実証可能なシナリオ 4 継続的デバイス検証機能 |
| Table 2-6 Scenario 5 Credential and Device Posture Establishment and Maintenance Capabilities That May Be Demonstrated | 表 2-6 実証される可能性のあるシナリオ 5 クレデンシャルおよびデバイス姿勢の確立と保守機能 |
| Table 3-1 Build 1 Capabilities Demonstrated 9 Table 3-2 Build 2 Capabilities Demonstrated | 表 3-1 実証された構築 1 能力 9 表 3-2 実証された構築 2 能力 |
| Table 3-3 Build 3 Capabilities Demonstrated | 表 3-3 実証されたビルド 3 能力 |
E
| 1800-36E ipd | Risk and Compliance Management | リスク・コンプライアンス・マネジメント |
| 1 Introduction | 1 序文 |
| 1.1 How to Use This Guide | 1.1 本ガイドの使用方法 |
| 2 Risks Addressed by Trusted Network-Layer Onboarding and Lifecycle Management |
2 信頼されるネットワーク層のオンボーディングとライフサイクル管理によって対処されるリスク管理 |
| 2.1 Risks to the Network | 2.1 ネットワークに対するリスク |
| 2.1.1 Risks to the Network Due to Device Limitations | 2.1.1 デバイスの制限によるネットワークへのリスク |
| 2.1.2 Risks to the Network Due to Use of Shared Network Credentials | 2.1.2 共有ネットワーククレデンシャルの使用によるネットワークへのリスク |
| 2.1.3 Risks to the Network Due to Insecure Network Credential Provisioning | 2.1.3 安全でないネットワーククレデンシャルプロビジョニングによるネットワークへのリスク |
| 2.1.4 Risks to the Network Due to Supply Chain Attacks | 2.1.4 サプライチェーン攻撃によるネットワークへのリスク |
| 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 Use Cases | 3.1 ユースケース |
| 3.2 Mapping Producers | 3.2 生産者のマッピング |
| 3.3 Mapping Approach | 3.3 マッピングのアプローチ |
| 3.3.1 Mapping Terminology | 3.3.1 マッピング用語 |
| 3.3.2 Mapping Process | 3.3.2 マッピングプロセス |
| 4 Mappings | 4 マッピング |
| 4.1 NIST CSF Subcategory Mappings | 4.1 NIST CSF サブカテゴリーのマッピング |
| 4.1.1 Mappings Between Reference Design Functions and NIST CSF Subcategories | 4.1.1 参照設計機能と NIST CSF サブカテゴリーとの間のマッピング |
| 4.1.2 Mappings Between Specific Onboarding Protocols and NIST CSF Subcategories | 4.1.2 特定のオンボーディング・プロトコルと NIST CSF サブカテゴリーとの間のマッピング |
| 4.1.3 Mappings Between Specific Builds and NIST CSF Subcategories | 4.1.3 特定の構築物と NIST CSF サブカテゴリーとの間のマッピング |
| 4.2 NIST SP 800-53 Control Mappings | 4.2 NIST SP 800-53 コントロールマッピング |
| 4.2.1 Mappings Between Reference Design Functions and NIST SP 800-53 Controls | 4.2.1 参照設計機能と NIST SP 800-53 コントロールとの間のマッピング |
| 4.2.2 Mappings Between Specific Onboarding Protocols and NIST SP 800-53 Controls | 4.2.2 特定のオンボーディング・プロトコルと NIST SP 800-53 コントロールとのマッピング |
| 4.2.3 Mappings Between Specific Builds and NIST SP 800-53 Controls | 4.2.3 特定のビルドと NIST SP 800-53 コントロールとの間のマッピング |
| Appendix A References | 附属書 A 参考文献 |
● まるちゃんの情報セキュリティ気まぐれ日記
米国のサイバーセキュリティラベル
・2024.04.19 米国 NIST NIST IR 8425A（初期公開ドラフト）消費者向けルータ製品に推奨されるサイバーセキュリティ要件
・2024.04.05 米国 意見募集 NIST CSWP 33（初公開ドラフト） 製品開発サイバーセキュリティハンドブック： IoT製品製造者のための概念と考慮事項
・2024.03.20 米国 連邦通信委員会 (FCC) がIoTサイバーセキュリティ表示プログラム（サイバートラストマーク）の規則を採択 (2024.03.14)
・2023.07.19 米国 消費者向けIoT製品のセキュリティ認証制度、サイバートラスト・マーク (U.S. Cyber Trust Mark) を発表
・2023.05.10 米国 ホワイトハウス 重要新興技術に関する国家標準化戦略を発表 (2023.05.04)
・2023.04.25 Five Eyesの国々が安全なスマートシティを作るための共同ガイダンスを発表 (2023.04.20)
・2023.03.04 米国 国家サイバーセキュリティ戦略を発表
・2022.06.19 NISTIR 8425 (ドラフト) 消費者向けIoT製品のIoTコアベースラインのプロファイル
・2022.05.19 NIST IoTセキュリティ関連の文書についてNISTのブログで簡単に説明されていますね。。。
・2022.02.07 NIST ホワイトペーパー ：消費者向けソフトウェアのサイバーセキュリティラベルの推奨規準
・2022.02.06 NIST ホワイトペーパー ：消費者向けIoT製品のサイバーセキュリティラベルの推奨規準
・2021.11.04 NIST 消費者向けソフトウェアのサイバーセキュリティに関するラベリングについての意見募集
英国 PTSI
・2024.04.30 英国 製品セキュリティおよび電気通信インフラストラクチャ（PSTI）法が施行されました...
・2024.01.29 英国 2022年製品セキュリティ・通信インフラ制度のウェブページ（Product Security and Telecommunications Infrastructure Act 2022 関係）
・2023.05.04 英国 インターネットに接続するすべての消費者向け製品に適用される最低セキュリティ基準制度が1年後にはじまりますよ〜 (2023.04.29)
・2022.12.11 英国 製品セキュリティおよび電気通信インフラストラクチャ（PSTI）法成立 at 2022.12.06
・2022.01.27 英国 スマートデバイスのサイバーセキュリティ新法に一歩近づくと発表
・2021.12.09 英国 製品セキュリティおよび電気通信インフラストラクチャ（PSTI）法案 at 2021.11.24
EU CRA...
・2024.03.19 欧州議会 AI法 (2024.03.13) とサイバーレジリエンス法を採択 (2024.03.12)
・2024.02.02 欧州委員会 サイバーセキュリティ認証制度 (EUCC) を採択
・2024.01.17 欧州 欧州議会の投票にかけられるサイバーレジリエンス法案 (Cyber Resilience Act)
・2023.12.04 欧州理事会、欧州議会がサイバーレジリエンス法について政治的合意
・2023.05.31 ENISA 新技術に対応したEUサイバーセキュリティ認証の実現可能性を探る
・2023.04.21 欧州委員会 マネージド・セキュリティサービスの認証にむけたサイバーセキュリティ法の改正案 (2023.04.18)
・2023.03.21 ENISA サイバーセキュリティ認証のウェブページを開設
・2023.01.29 欧州 サイバーレジリエンス法案に対するポジションペーパー by 欧州消費者機構
・2022.09.17 欧州委員会 サイバーレジリエンス法案 製造者は「積極的に悪用される脆弱性」に気づいたら24時間以内にENISAに報告しなければならない...
ドイツのセキュリティ製品の認証
・2022.10.31 ドイツ シンガポール 消費者向けIoT製品のサイバーセキュリティ・ラベルの相互承認 (2022.10.20)
・2022.05.09 ドイツ ITセキュリティラベル for 消費者向けスマート製品
・2022.02.03 ドイツ BSI Mail.deの電子メールサービスにITセキュリティラベルを付与
・2021.07.18 独国 BSIがITセキュリティラベルについてのウェブページを公開していますね。。。
中国
・2022.02.15 中国 国家サイバースペース管理局 専門家の解説 ネットワーク重要機器のセキュリティ認証とセキュリティテストによるネットワークセキュリティの基本ディスクの維持
日本...
・2024.03.17 経済産業省 IoT製品に対するセキュリティ適合性評価制度構築に向けた検討会の最終とりまとめを公表し、制度構築方針案に対する意見公募を開始
・2023.05.17 経済産業省 産業サイバーセキュリティ研究会 WG3 IoT製品に対するセキュリティ適合性評価制度構築に向けた検討会 中間とりまとめ
・2022.11.04 経済産業省 第1回 産業サイバーセキュリティ研究会 ワーキンググループ3 IoT製品に対するセキュリティ適合性評価制度構築に向けた検討会
Comments