パブコメ

2024.06.19

米国 NIST IR 8505(初期公開ドラフト) クラウドネイティブ・アプリケーションのためのデータ保護アプローチ (2024.06.14)

こんにちは、丸山満彦です。

NISTが、IR 8505(初期公開ドラフト) クラウドネイティブ・アプリケーションのためのデータ保護アプローチを公表し、意見募集をしていますね。。。

静止状態でのデータ防御技術(正規表現など)に加えて、サービスやネットワーク・プロトコルを横断して移動するデータを能動的に監視して保護するために、リアルタイムでデータ分析を実行する移動中のデータ分類を開発することが不可欠になっていることから、WebAssembly(WASM)の機能を利用した効果的なデータ保護のための実用的なフレームワークについて 概説しているのが、この文書ということのようです...

 

NIST - ITL

・2024.06.14 NIST IR 8505 (Initial Public Draft) A Data Protection Approach for Cloud-Native Applications

 

NIST IR 8505 (Initial Public Draft) A Data Protection Approach for Cloud-Native Applications NIST IR 8505(初期公開ドラフト) クラウドネイティブ・アプリケーションのためのデータ保護アプローチ
Announcement 発表
Cloud-native applications, which are generally based on microservices-based application architecture, involve the governance of thousands of services with as many inter-service calls. In this environment, ensuring data security involves more than simply specifying and granting authorization during service requests. It also requires a comprehensive strategy to categorize and analyze data access and leakage as data travels across various protocols (e.g., gRPC, REST-based), especially within ephemeral and scalable microservices implemented as containers. クラウドネイティブ・アプリケーションは、一般的にマイクロサービス・ベースのアプリケーション・アーキテクチャをベースにしており、何千ものサービスのガバナンスが必要であり、サービス間の呼び出しも多い。このような環境では、データ・セキュリティの確保は、単にサービス・リクエスト時に認可を指定・付与するだけではない。また、特にコンテナとして実装されたエフェメラルでスケーラブルなマイクロサービス内で、データが様々なプロトコル(gRPC、RESTベースなど)を横断する際に、データアクセスと漏えいを分類・分析する包括的な戦略も必要となる。
Hence, in addition to techniques for protecting data at rest (e.g., regular expressions), it has become essential to develop in-transit data categorization that performs real-time data analysis to actively monitor and secure data as it moves across services and network protocols. This IR outlines a practical framework for effective data protection using the capabilities of WebAssembly (WASM) — a platform-agnostic, in-proxy approach with compute and traffic processing capabilities (in-line, network traffic analysis at layers 4–7) that can be built and deployed to execute at native speed in a sandboxed and fault-tolerant manner. したがって、静止状態でのデータ防御技術(正規表現など)に加えて、サービスやネットワーク・プロトコルを横断して移動するデータを能動的に監視して保護するために、リアルタイムでデータ分析を実行する移動中のデータ分類を開発することが不可欠になっている。このIRでは、WebAssembly(WASM)の機能を利用した効果的なデータ保護のための実用的なフレームワークについて概説する。このフレームワークは、プラットフォームにとらわれないインプロキシアプローチであり、計算機能とトラフィック処理機能(インライン、レイヤー4~7でのネットワークトラフィック分析)を備えている。
Abstract 概要
This document addresses the need for effective data protection strategies in the evolving realm of cloud-native network architectures, including multi-cloud environments, service mesh networks, and hybrid infrastructures. By extending foundational data categorization concepts, it provides a framework for aligning data protection approaches with the unknowns of data in transit. Specifically, it explores service mesh architecture, leveraging and emphasizing the capabilities of WebAssembly (WASM) in ensuring robust data protection as sensitive data is transmitted through east-west and north-south communication paths. 本書は、マルチクラウド環境、サービスメッシュ・ネットワーク、ハイブリッド・インフラなど、進化するクラウドネイティブ・ネットワークアーキテクチャの領域における効果的なデータ保護戦略の必要性に取り組むものである。基本的なデータ分類の概念を拡張することで、転送中のデータの未知数にデータ保護アプローチを整合させるためのフレームワークを提供する。具体的には、WebAssembly(WASM)の機能を活用し、機密データが東西および南北の通信経路を経由して伝送される際に、堅牢なデータ保護を確保するためのサービスメッシュアーキテクチャを探求している。

 

・[PDF] NIST.IR.8505.ipd

20240619-62718

 

目次...

1. Introduction 1. 序文
1.1. Existing Approaches to Data Protection and Their Limitations 1.1. データ保護に対する既存のアプローチとその限界
1.2. In-Proxy Application for Data Protection 1.2. データ防御のためのインプロキシ・アプリケーション
1.3. Objective and Scope of This Document 1.3. この文書の目的と範囲
1.4. Organization of This Document 1.4. 本文書の構成
2. Web Assembly Background 2. ウェブアセンブリの背景
2.1. Origin 2.1. 起源
2.2. Progression Into Server-Side Environments 2.2. サーバーサイド環境への移行
2.2.1. Development and Deployment Process 2.2.1. 開発と展開のプロセス
2.3. Proxies as WASM Platforms 2.3. WASMプラットフォームとしてのプロキシ
2.4. Proxy-WASM 2.4. Proxy-WASM
2.4.1. Role of WASM in Different Service Mesh Architectures 2.4.1. 異なるサービスメッシュ・アーキテクチャにおけるWASMの役割
2.5. WASI-HTTP 2.5. WASI-HTTP
2.6. eBPF 2.6. eBPF
3. Data Protection in Transit 3. トランジットにおけるデータ防御
3.1. Data Categorization Techniques 3.1. データ分類技術
3.2. Techniques for Data Protection 3.2. データ防御のテクニック
3.2.1. Web Traffic Data Protection 3.2.1. ウェブ・トラフィック・データの防御
3.2.2. API Security 3.2.2. APIセキュリティ
3.2.3. Microsegmentation 3.2.3. マイクロセグメンテーション
3.2.4. Log Traffic Data Protection 3.2.4. ログ・トラフィック・データの防御
3.2.5. LLM Traffic Data Protection 3.2.5. LLMトラフィックデータ防御
3.2.6. Credit Card-Related Data Protection 3.2.6. クレジットカード関連データの防御
3.2.7. Monitoring Tools to Visualize Sensitive Data Flows 3.2.7. 機密データの流れを可視化する監視ツール
4. Security Analysis of WASM Modules 4. WASMモジュールのセキュリティ分析
4.1. WASM Security Goals and Security Feature Sets 4.1. WASMのセキュリティ目標とセキュリティ機能セット
4.1.1. User-Level Security Features 4.1.1. ユーザーレベルのセキュリティ機能
4.1.2. Security Primitives for Developers 4.1.2. 開発者のためのセキュリティ・プリミティブ
4.2. Memory Model and Memory Safety 4.2. メモリ・モデルとメモリ安全性
4.3. Execution Model and Control Flow Integrity 4.3. 実行モデルと制御フローの完全性
4.4. Security of API Access to OS and Host Resources 4.4. OSとホスト・リソースへのAPIアクセスの安全性
4.5. Protection From Side-Channel Attacks 4.5. サイドチャンネル攻撃からの防御
4.6. Protection Against Code Injection and Other Attacks 4.6. コード・インジェクションやその他の攻撃に対する防御
4.7. Deployment and Operating Security 4.7. 配備と運用のセキュリティ
5. Summary and Conclusions 5. まとめと結論
References 参考文献
Appendix A. Execution Model for Web Assembly in Browsers 附属書A. ブラウザにおけるウェブアセンブリの実行モデル
Appendix B. Comparison of Execution Models for Containers and WASM Modules 附属書B. コンテナとWASMモジュールの実行モデルの比較

 

序文...

1. Introduction  1. 序文 
In the constantly evolving landscape of cloud-native application architectures, where data resides in multiple locations (i.e., on-premises and on the cloud), ensuring data security involves more than simply specifying and granting authorization during service requests. It also involves a comprehensive strategy to categorize and analyze data access and leakage as data travels across various protocols (e.g., gRPC, REST-based), especially within ephemeral and scalable microservices applications. As organizations find themselves governing hundreds to tens of thousands of services and the inter-service calls between them, a security void has been identified in observing and protecting sensitive data in transit.   データが複数の場所(すなわち、オンプレミスとクラウド上)に存在するクラウドネイティブ・アプリケーション・アーキテクチャの状況は常に進化しており、データセキュリティの確保には、サービス要求時に単に認可を指定・付与するだけでは不十分である。また、特にエフェメラルでスケーラブルなマイクロサービス・アプリケーション内で、データが様々なプロトコル(gRPC、RESTベースなど)を横断する際に、データ・アクセスと漏えいを分類・分析する包括的な戦略も必要となる。政府は、数百から数万のサービスと、それらの間のサービス間コールをガバナンスしていることに気付くと、転送中の機密データを観察し、保護するセキュリティ上の空白が特定された。 
1.1. Existing Approaches to Data Protection and Their Limitations  1.1. データ保護に対する既存のアプローチとその限界 
Traditionally, regular expressions (regex) have been widely used for data categorization to identify patterns that match predefined categories or data classes with the aid of keywords and validators for enhanced precision. Despite its wide adoption and usage, the approach has notable limitations. The processing time scales linearly with data volume, making it impractical for very large datasets. Regex also lacks the capability for logical computations, which are necessary for complex validations like checksums in credit card numbers. Its effectiveness heavily relies on the correct proximity to specific keywords, leading to potential false positives and considerable noise if not managed correctly.  従来、正規表現(regex)は、精度を高めるためのキーワードやバリデータの助けを借りて、事前に定義されたカテゴリーやデータクラスに一致するパターンを識別するために、データの分類に広く使用されてきた。広く採用され使用されているにもかかわらず、このアプローチには顕著な限界がある。処理時間はデータ量に比例するため、非常に大きなデータセットでは実用的でない。また正規表現には、クレジットカード番号のチェックサムのような複雑なバリデーションに必要な論理計算の機能がない。その有効性は、特定のキーワードに正しく近接しているかどうかに大きく依存しており、正しく管理されなければ誤検出の可能性やかなりのノイズにつながる。
Machine learning (ML) offers a promising enhancement to data categorization by learning from data patterns and improving over time, thus providing a scalable and adaptable solution. ML algorithms can handle both structured and unstructured data, predict data categories based on historical data, and adjust to new patterns without explicit reprogramming. This adaptability significantly reduces the time and computational resources required to manage complex datasets and is effective for both data at rest and in motion.  機械学習(ML)は、データパターンから学習し、時間の経過とともに改善することで、データ分類に有望な強化を提供する。MLアルゴリズムは、構造化データと非構造化データの両方を扱い、過去のデータに基づいてデータカテゴリーを予測し、明示的な再プログラミングなしに新しいパターンに適応することができる。この適応性は、複雑なデータセットを管理するのに必要な時間と計算資源を大幅に削減し、静止しているデータと動いているデータの両方に有効である。
To address and complement the limitations of traditional data-at-rest inventory, in-transit data categorization has recently come to light as the next logical step in data protection. Unlike the former, which only secures stored information, in-transit categorization actively monitors and secures data as it moves across services and network protocols. This shift to real-time data analysis within the network brings new observability capabilities, eliminating the need for traffic mirroring and data duplication.   従来のデータアットレストのインベントリの限界に対処し、補完するために、データ保護の次の論理的ステップとして、移動中のデータ分類が最近注目されるようになった。保存された情報のみを保護する従来の方法とは異なり、移動中のデータ分類は、サービスやネットワーク・プロトコルを移動するデータを積極的に監視し、保護する。ネットワーク内でのリアルタイム・データ分析への移行は、新たな観測可能性をもたらし、トラフィックのミラーリングやデータの複製を不要にする。 
1.2. In-Proxy Application for Data Protection  1.2. データ防御のためのインプロキシ・アプリケーション 
To address the need for data categorization during travel across services, a relatively new class of in-proxy application called the WebAssembly program (also called a WASM module) has been increasingly deployed. A WASM module is a lightweight executable compiled to low-level bytecode. This bytecode can be:  サービス間の移動中にデータを分類する必要性に対処するため、WebAssemblyプログラム(WASMモジュールとも呼ばれる)と呼ばれる比較的新しいクラスのインプロキシ・アプリケーションの導入が進んでいる。WASMモジュールは、低レベルのバイトコードにコンパイルされた軽量の実行ファイルである。このバイトコードには次のようなものがある: 
(a)   Generated from code written in any language using their associated WebAssembly compilers, including C, C++, and Rust  (a) C、C++、Rustなど、関連するWebAssemblyコンパイラを使って任意の言語で書かれたコードから生成する。
(b)  Run using a WASM runtime in an isolated virtual machine (VM) within the proxy, which allows developers to enhance applications with necessary functionality and run them as efficiently as native code in the proxies.  (b) プロキシ内の分離された仮想マシン(VM)内でWASMランタイムを使用して実行する。これにより、開発者は必要な機能を持つアプリケーションを拡張し、プロキシ内でネイティブコードと同様に効率的に実行することができる。
Over the last few years, the Envoy WASM VM has enabled new types of compute and traffic processing capabilities and allowed for custom WASM modules to be built and deployed in a sandboxed and fault-tolerant manner.  ここ数年で、Envoy WASM VMは新しいタイプのコンピュートとトラフィック処理機能を可能にし、サンドボックス化されたフォールトトレラントな方法でカスタムWASMモジュールを構築してデプロイできるようになった。
Additionally, the following features of WebAssembly modules make them particularly effective for data protection:  さらに、WebAssemblyモジュールの次のような特徴は、データ保護に特に効果的である: 
Data Discovery and Categorization: WASM modules can dynamically identify and categorize data as it traverses the network, ensuring that sensitive information is recognized and handled appropriately.  データの発見と分類: WASMモジュールは、ネットワーク上を通過するデータを動的に識別・分類し、機密情報が認識され。適切に処理されるようにすることができる。
Dynamic Data Masking (DDM): WASM modules can apply DDM techniques to redact or mask sensitive information in transit, enhancing privacy and security.  動的データマスキング(DDM): WASMモジュールはDDM技術を適用して、転送中の機密情報を再編集またはマスクし、プライバシーとセキュリティを強化することができる。
User and Entity Behavior Analytics (UEBA): WASM modules can analyze user and entity behaviors in real time, detecting anomalies and potential security threats.  ユーザーと事業体の行動分析(UEBA): WASMモジュールはユーザーや事業体の行動をリアルタイムで分析し、異常や潜在的なセキュリティ脅威を検知することができる。
Data Loss Prevention (DLP): WASM modules can enforce DLP policies by monitoring and controlling data transfers to prevent unauthorized data exfiltration.  データ損失防止(DLP): WASMモジュールは、不正なデータ流出を防ぐためにデータ転送を監視・管理することで、DLPポリシーを実施することができる。
1.3. Objective and Scope of This Document  1.3. この文書の目的と範囲 
All services (e.g., networking, security, monitoring, etc.) for microservices-based applications are provided by a centralized infrastructure called the service mesh, and the data plane for this service mesh — which performs all runtime tasks — consists of proxies. This document outlines a practical framework for effective data protection and highlights the versatile capabilities of WebAssembly (WASM) within service mesh architectures, multi-cloud environments, and hybrid (i.e., a combination of on-premises and cloud-based) infrastructures. By focusing on inline, network traffic analysis at layers 4–7, organizations can enhance security, streamline operations, and utilize adaptive data protection measures.  マイクロサービスベースのアプリケーションのすべてのサービス(ネットワーキング、セキュリティ、モニタリングなど)は、サービスメッシュと呼ばれる集中型インフラストラクチャによって提供され、このサービスメッシュのデータプレーン(すべてのランタイムタスクを実行する)は、プロキシで構成される。このドキュメントでは、効果的なデータ保護のための実用的なフレームワークの概要を示し、サービスメッシュアーキテクチャ、マルチクラウド環境、ハイブリッド(オンプレミスとクラウドベースの組み合わせ)インフラにおけるWebAssembly(WASM)の多用途な機能を強調する。レイヤー4~7におけるインラインのネットワークトラフィック分析に重点を置くことで、企業はセキュリティを強化し、運用を合理化し、適応的なデータ保護対策を利用することができる。
1.4. Organization of This Document  1.4. 本文書の構成 
This document is organized as follows:  本文書の構成は以下の通りである: 
• Section 2 describes the execution environment for WASM modules in detail, including the application infrastructure (i.e., service mesh) under which it runs, the specific host environment (i.e., proxies), the process for generating bytecodes and executables, the processes for executing the modules using a WASM runtime, and an API (i.e., WASI) for accessing OS resources of the underlying platform.  ・セクション2では、WASMモジュールが実行されるアプリケーション基盤(すなわちサービスメッシュ)、特定のホスト環境(すなわちプロキシ)、バイトコードと実行可能ファイルを生成するプロセス、WASMランタイムを使用してモジュールを実行するプロセス、基盤となるプラットフォームのOSリソースにアクセスするためのAPI(すなわちWASI)など、WASMモジュールの実行環境について詳しく説明する。
• Section 3 introduces the concept of data categorization and the use of various data protection techniques (e.g., data masking, redaction, etc.) to ensure the security of data in different domains or application scenarios using WASM modules, such as web traffic data protection, API Security, microsegmentation, log traffic data protection, LLM traffic data protection, and integration with monitoring tools for the visualization of sensitive data flows.  ・セクション3では、データの分類の概念と、ウェブトラフィックデータ保護、APIセキュリティ、マイクロセグメンテーション、ログトラフィックデータ保護、LLMトラフィックデータ保護、機密データフローの可視化のための監視ツールとの統合など、WASMモジュールを使用したさまざまなドメインやアプリケーションシナリオにおけるデータのセキュリティを確保するための、さまざまなデータ保護技術(データマスキング、再編集など)の使用について紹介する。
• Section 4 presents a detailed security analysis of a WASM module by examining its development, deployment, and execution environment to ensure that the module satisfies the properties of a security kernel and can provide the necessary security assurance.  ・セクション4では,WASMモジュールがセキュリティカーネルの特性を満たし、必要なセキュリティ保証を提供できることを保証するために、その開発、実装、実行環境を調査することによって、WASMモジュールの詳細なセキュリティ分析を行う。
• Section 5 provides a summary of the topics covered in this document and discusses how WASM module functionality must continuously evolve to provide the security assurance needed to protect against data breaches and exfiltration in the context of increasingly sophisticated attacks on data.   ・セクション5では,本文書で取り上げたトピックの概要を示し,データに対する攻撃がますます巧妙化する中で、データ侵害や流出から保護するために必要なセキュリティ保証を提供するために、WASMモジュールの機能がどのように継続的に進化していかなければならないかについて議論する。

 

図1. WASMモジュールの生成とその実行

 

20240619-64357

 

 

図2. WASMモジュールの開発とブラウザでの実行

20240619-64540

 

図3. コンテナとWASMモジュールの実行スタックの比較

20240619-64810

 

 

| | Comments (0)

米国 NIST TN 2283(初期公開ドラフト)上下水道部門のサイバーセキュリティ: アーキテクチャを構築する 運用技術 リモートアクセス (2024.06.12)

こんにちは、丸山満彦です。

NISTが、NIST TN 2283(初期公開ドラフト)上下水道部門のサイバーセキュリティ: アーキテクチャを構築する 運用技術 リモートアクセスを公表し、意見募集をていますね.

上下水道システム(WWS)セクターの事業者に共通するサイバーセキュリティ上の課題を特定し、参照サイバーセキュリティ・アーキテクチャを開発し、リスクを軽減・マネジメントするための既存の市販製品の活用を提案するプロジェクトの一環として、上下水道事業者が自主的に活用できるようなサイバーセキュリティリスクに対処するために市販の技術や既存の標準、ベストプラクティスを作成したものということのようです...

超小規模から小規模(25~3,300 の顧客)、中規模から大規模(3,301~100,000 の顧客)に分類して、それぞれのシステムの複雑さ、予算上の制約、運用上の要件などを想定した上で、適切な技術を使用することができようにしているようです...

 

NIST - ITL

・2024.06.12 NIST TN 2283 (Initial Public Draft) Cybersecurity for the Water and Wastewater Sector: Build Architecture. Operational Technology Remote Access

NIST TN 2283 (Initial Public Draft) Cybersecurity for the Water and Wastewater Sector: Build Architecture. Operational Technology Remote Access NIST TN 2283(初期公開ドラフト)上下水道部門のサイバーセキュリティ: アーキテクチャを構築する 運用技術 リモートアクセス
Announcement 発表
The National Cybersecurity Center of Excellence (NCCoE) has undertaken a project to identify common cybersecurity challenges among Water and Wastewater Systems (WWS) sector participants, develop reference cybersecurity architectures, and propose the utilization of existing commercially available products to mitigate and manage risks. The reference cybersecurity architectures outlined in this report can be voluntarily leveraged by water and wastewater utilities to use commercially available technologies and existing standards and best practices to address their cybersecurity risks. 国立サイバーセキュリティ・センター・オブ・エクセレンス(NCCoE)は、上下水道システム(WWS)セクターの事業者に共通するサイバーセキュリティ上の課題を特定し、参照サイバーセキュリティ・アーキテクチャを開発し、リスクを軽減・マネジメントするための既存の市販製品の活用を提案するプロジェクトを実施した。本報告書に概説されている参照用サイバーセキュリティアーキテクチャは、上下水道事業者が自主的に活用することで、サイバーセキュリティリスクに対処するために市販の技術や既存の標準、ベストプラクティスを利用することができる。
The publication is designed for use by those in the water and wastewater systems sector. The architectures presented in this report for water and wastewater utilities are categorized by system size; specifically, from very small to small (25-3,300 customers) and the medium to large (3,301 – 100,000 customer) size ranges. This categorization allows the use of appropriate technologies based on assumptions of system complexity, budgetary constraint, and operational requirements. This proposed guidance does not offer prescriptive solutions but rather showcases example approaches appropriate within each range of system sizes. 本書は、上下水道システムセクターの事業者が使用することを想定して作成されている。具体的には、超小規模から小規模(25~3,300 の顧客)、中規模から大規模(3,301~100,000 の顧客)に分類されている。この分類により、システムの複雑さ、予算上の制約、運用上の要件などを想定した上で、適切な技術を使用することができる。本ガイダンス案は、規定的な解決策を提供するものではなく、むしろ、各システム規模の範囲内で適切なアプローチ例を紹介するものである。
Abstract 概要
This Technical Note describes the product-agnostic remote access security architectures and the example solutions the NIST National Cybersecurity Center of Excellence (NCCoE) plans to demonstrate as part of the Cybersecurity for the Water and Wastewater Sector: A Practical Reference Design for Mitigating Cyber Risk in Water and Wastewater Systems project. These security architectures were developed in collaboration with technology vendors, water utilities, and other experts. The NCCoE continues to work with these collaborators to develop example solutions that demonstrate how these security architectures can be leveraged to address cybersecurity risks associated with remote access to water and wastewater operational technology systems. 本テクニカルノートでは、NIST国立サイバーセキュリティ・センター・オブ・エクセレンス(NCCoE)が上下水道分野のサイバーセキュリティの一環として実証する予定の、製品にとらわれないリモートアクセスセキュリティアーキテクチャとソリューション例について説明する: A Practical Reference Design for Mitigating Cyber Risk in Water and Wastewater Systems)プロジェクトの一環として実証する予定である。これらのセキュリティ・アーキテクチャは、技術ベンダー、水道事業者、その他の専門家と協力して開発された。NCCoE は、上下水道業務技術システムへのリモート・アクセスに関連するサイバーセキュリティ・リスクに対処するために、これらのセキュリティ・アーキテクチャをどのように活用できるかを示すソリューション例を開発するために、これらの協力者と引き続き協力している。
This Technical Note presents a traditional on-premises remote access architecture and two example solutions, one for medium to large water and wastewater systems (WWS) and one for very small to small water and wastewater systems. A cloud-based remote access architecture and example solution are also described. 本テクニカルノートでは、従来のオンプレミス型リモートアクセスアーキテクチャと、中規模から大規模の上下水道システム(WWS)向けと、ごく小規模から小規模の上下水道システム向けの 2 つのソリューション例を示す。また、クラウドベースのリモートアクセスアーキテクチャとソリューション例についても説明する。

 

・[PDF] NIST.TN.2283.ipd

20240619-54617

 

目次...

1. Introduction 1. 序文
1.1. Audience 1.1. 想定読者
1.2. Collaborators 1.2. 協力者
 1.2.1. Report Organization  1.2.1. 報告組織
2. Remote Access Background 2. リモートアクセスの背景
2.1. Remote Access Technologies in the WWS Sector 2.1. WWS分野におけるリモートアクセス技術
2.2. Medium to Large WW 2.2. 中規模から大規模WW
2.3. Very Small to Small WWs 2.3. 超小型から小型WW
2.4. WWS Characteristics Comparison 2.4. WWSの特徴の比較
2.5. WWS Remote Access Cybersecurity Considerations 2.5. WWS リモートアクセスのサイバーセキュリティに関する考察
3. Traditional Remote Access Architecture 3. 従来のリモートアクセス・アーキテクチャ
3.1. Product-Agnostic Remote Access Architecture 3.1. 製品にとらわれないリモートアクセスのアーキテクチャ
3.2. Medium to Large WWS Remote Access Example Solution 3.2. 中規模から大規模WWSリモートアクセスのソリューション例
3.3. Very Small to Small Remote Access Example Solution 3.3. 超小型~小型リモートアクセス ソリューション例
4. Cloud-Based Remote Access 4. クラウドベースのリモートアクセス
4.1. Product-Agnostic Architecture for Cloud-Based Remote Access 4.1. クラウドベースのリモートアクセスのための製品に依存しないアーキテクチャ
 4.1.1. Ed  4.1.1. Ed
 4.1.2. Network  4.1.2. ネットワーク
 4.1.3. Application  4.1.3. アプリケーション
 4.1.4. Security Considerations  4.1.4. セキュリティ
4.2. Cloud-Based Remote Access Example Solution 4.2. クラウドベースのリモートアクセス ソリューション例
5. Summary and Next Steps 5. まとめと次のステップ
References 参考文献
Appendix A. Glossary 附属書 A. 用語集
List of Tables 表一覧
Table 1. Project Collaborators 表1. プロジェクト協力者
Table 2. Size Categories of US Community Water System 表2. 米国の簡易水道の規模カテゴリー
Table 3. WWS Characteristics 表3. WWSの特徴
List of Figures 図一覧
Figure 1. Remote Access Concept 図1. リモートアクセスの概念
Figure 2. Components of a medium to large water system 図2. 中規模から大規模の水道システムの構成要素
Figure 3. Components of a very small to small water system 図3. 超小型から小型の水道システムの構成要素
Figure 4. Traditional Remote Access Architecture 図4. 従来のリモート・アクセス・アーキテクチャ
Figure 5. Remote Access for Medium to Large WWS example solution 図5. 中規模から大規模WWSのためのリモートアクセス ソリューション例
Figure 6. Remote Access for Very Small to Small WWS example solution 図6. 超小型~小型WWS向けリモートアクセス ソリューション例
Figure 7. Cloud-based remote access 図7. クラウドベースのリモートアクセス クラウドベースのリモートアクセス
Figure 8 Cloud-based remote access example solution 図8. クラウドベースのリモートアクセス ソリューション例

 

 

序文...

Introduction  序文 
As described in the preceding NIST NCCoE publication “Cybersecurity for the Water and Wastewater Sector: A Practical Reference Design for Mitigating Cyber Risk in Water and Wastewater Systems” [1], the NCCoE has undertaken a project to identify common cybersecurity challenges among Water and Wastewater Systems (WWS) sector participants, develop reference cybersecurity architectures, and propose the utilization of existing commercially available products to mitigate and manage risks. The reference cybersecurity architectures outlined in this report can be voluntarily leveraged by water and wastewater utilities to use commercially available technologies and existing standards and best practices to address their cybersecurity risks. Specifically, our work focuses on four areas identified by the United States Cybersecurity and Infrastructure Security Agency (CISA) [2][3] as priority:   先行するNIST NCCoE発行の「上下水道セクターのサイバーセキュリティ」[1]に記載されているように、NCCoEは上下水道システムにおけるサイバーリスク軽減のための実践的なリファレンスデザインを策定するプロジェクトを実施した: A Practical Reference Design for Mitigating Cyber Risk in Water and Wastewater Systems」[1]に記載されているように、NCCoE は上下水道システム(WWS)セクターの参加者に共通するサイバーセキュリティの課題を特定し、参照用サイバーセキュリティアーキテクチャを開発し、リスクを低減・管理するための既存の市販製品の活用を提案するプロジェクトを実施した。本報告書で概説する参照用サイバーセキュリティアーキテクチャは、上下水道事業者が自主的に活用できるものであり、サイバーセキュリティリスクに対処するために市販の技術や既存の標準、ベストプラクティスを利用することができる。具体的には、米国サイバーセキュリティ・インフラセキュリティ庁(CISA)[2][3]が優先事項として特定した 4 つの分野に焦点を当てている:  
1. Remote Access – ensure security safeguards are configured to control access based on roles or responsibilities; collect, aggregate, and analyze log information.  1. リモート・アクセス:役割や責任に基づいてアクセスを管理するようにセキュリティ保護措置が設定されていることを確認し、ログ情報を収集、集計、分析する。
2. Network Segmentation – demonstrate open-source products for logical partitions of the operational network, such as firewalls, data diodes, or SDN (software defined networks)  2. ネットワーク・セグメンテーション:ファイアウォール、データ・ダイオード、SDN(ソフトウ ェア定義ネットワーク)など、運用ネットワークの論理パーティション用のオープンソース 製品を実証する。
3. Asset management - discover, identify, categorize, and manage all network-enabled devices: detect potential risks and validate patches and upgrades.  3. 資産マネジメント:すべてのネットワーク対応デバイスを検知、識別、分類、管理する。
4. Data Integrity – protect the integrity of data by detecting lack of protections, provide secure communications, sandboxing techniques, and methods to prevent software modifications.  4. データ・セキュリティ:保護の欠如を検知し、セキュアなコミュニケーション、サンドボックス技術、ソフトウェアの改変を防止する方法を提供することで、データの完全性を保護する。
This first guide addresses the remote access scenario and describes architectures and example solutions allowing authorized access to a water or wastewater utility’s Operational Technology (OT) assets. Subsequent publications will address the other identified risk scenarios and solutions.  この最初のガイドでは、リモートアクセスのシナリオを取り上げ、上下水道事業者の運用技術(OT)資産への認可されたアクセスを可能にするアーキテクチャとソリューション例を説明する。後続の出版物では、その他の識別されたリスクシナリオと解決策を取り上げる予定である。
1.1.  Audience  1.1.  想定読者
The publication is designed for use by those in the water and wastewater systems sector. The architectures presented in this report for water and wastewater utilities are categorized by system size; specifically, from very small to small (25-3,300 customers) and the medium to large (3,301 – 100,000 customer) size ranges. This categorization allows the use of appropriate technologies based on assumptions of system complexity, budgetary constraint, and operational requirements. This proposed guidance does not offer prescriptive solutions but rather showcases example approaches appropriate within each range of system sizes.  本書は、上下水道システム部門関係者の使用を目的としている。具体的には、超小規模から小規模(25~3,300の顧客)、中規模から大規模(3,301~100,000の顧 客)に分類している。この分類により、システムの複雑さ、予算の制約、運営上の必要条件などを前提に、適切な技術を使用することができる。本ガイダンス案は、規定的な解決策を提供するものではなく、各システム規模の範囲内で適切なアプローチ例を紹介するものである。
1.2. Collaborators  1.2. 協力者 
The NCCoE has assembled a team of collaborators who provide products and expertise in formulating remote access architectures and building example solutions. Table 1 lists the cybersecurity product vendors, water and wastewater utilities, professional associations, and industry consultants who have volunteered to collaborate on this project.  NCCoE は、リモートアクセスアーキテクチャの策定とソリューション例の構築において、製品 と専門知識を提供する協力者のチームを編成した。表 1 に、このプロジェクトにボランティアで協力してくれたサイバーセキュリティ製品ベンダー、上下水道事業者、専門家団体、業界コンサルタントを示す。
Table 1. Project Collaborators  表 1. プロジェクトの協力者 
20240619-55823
The NCCoE is using commercial products provided by our collaborators to build secure remote access example solutions. NIST, the NCCoE, and this guide do not endorse these specific products. Your organization should identify and select products that will best integrate with your existing infrastructure. We hope that you will seek products that are congruent with applicable standards and best practices.   NCCoEは、協力者が提供する商用製品を使用して、安全なリモートアクセスのサンプルソリューションを構築している。NIST、NCCoE、および本ガイドは、これらの特定の製品を推奨するものではない。各組織は、既存のインフラストラクチャに最適な製品を特定し、選択する必要がある。適用される標準およびベストプラクティスに合致する製品を求めることを望む。 
1.2.1. Report Organization  1.2.1. 報告書の構成 
This report contains six sections and two appendices. A brief description of each follows:  本報告書は、6つのセクションと2つの附属書から構成されている。それぞれの簡単な説明は以下の通りである: 
• Section 1, this section, provides context for the project scenarios, identifies the report’s intended audience, and lists the project’s collaborator.  ・セクション1では,プロジェクトシナリオの背景を説明し,報告書の対象読者を特定し, プロジェクトの協力者を列挙する。
• Section 2 introduces the concept of remote access and provides background on water and wastewater systems for a range of utility sizes.  ・セクション2では,リモートアクセスの概念を紹介し,様々な規模の上下水道システムの背景を説明する。
• Section 3 presents a traditional product-agnostic remote access architecture and describes two proposed example solution implementations of this architecture, one for medium to large WWS and one for very small to small WWS.  ・第3節では、従来の製品にとらわれないリモートアクセスアーキテクチャを示し、このアーキテクチャの2つのソリューション実装例(1つは中規模から大規模のWWS向け、もう1つは超小規模から小規模のWWS向け)を提案する。
• Section 4 presents a product-agnostic cloud-based Software as a Service (SaaS) architecture for remote access and describes an example solution that is scalable from very small to large WWS.  ・セクション4は、リモートアクセスのための製品にとらわれないクラウドベースのSaaS(Software as a Service)アーキテクチャを提示し、非常に小規模なWWSから大規模なWWSまでスケーラブルなソリューション例を説明する。
• Section 5 summarizes this technical note.  ・セクション5はこのテクニカルノートの要約である。
• Appendix A is a selected bibliography.  ・附属書A:参考文献の一部
• Appendix B provides a glossary of terms.  ・附属書B:用語集
Your organization can adopt the remote access solutions presented in this technical note or ones that adhere to the guidelines presented here. Your organization may use this guide as a starting point for tailoring and implementing parts of the reference architecture to provide a remote access solution that best meets your needs.  あなたの組織は、このテクニカルノートで紹介されているリモートアクセス・ソリューションを採用することもできるし、 ここで紹介されているガイドラインに従ったものを採用することもできる。このガイドを出発点として、リファレンスアーキテ クチャの一部をカスタマイズして実装し、ニーズに最適なリモートアクセスソリューションを提供することもできる。

 

リモートアクセス概念

20240619-60109

 

 

中規模から大規模の水道システムの構成要素

20240619-60206

 

 

超小型から小型の水道システムの構成要素

20240619-60314

 

従来のリモート・アクセス・アーキテクチャ

20240619-60428

 

 

中規模から大規模WWSのためのリモートアクセス ソリューション例

20240619-60647

 

 

超小型~小型WWS向けリモートアクセス ソリューション例

20240619-60842

 

クラウドベースのリモートアクセス

20240619-60941

 

クラウドベースのリモートアクセス ソリューション例

20240619-61101

 

 

| | Comments (0)

2024.06.18

米国 NIST IR 8517(初期公開ドラフト) ハードウェアセキュリティの失敗シナリオ: ハードウェア設計における潜在的な弱点

こんにちは、丸山満彦です。

「ハードウェアは本質的に安全であるという誤った思い込みが広まっている。しかし、この報告書は、ハードウェアに起こりうる数多くの潜在的なセキュリティ障害を文書化したものである。また、ハードウェアが脆弱性を持ちうる多様な方法を示している。」

とのことです...

98の失敗シナリオ...

CWE(Common Weakness Enumeration)の関係...

 

1_20240617191301

右の数字はシナリオの数...

1 Improper Access Control  CWE-284 43
2 Improper Adherence to Coding Standards  CWE-710 14
3 Improper Check or Handling of Exceptional Conditions  CWE-703 5
4 Improper Control of a Resource Through its Lifetime  CWE-664 40
5 Incorrect Comparison  CWE-697 1
6 Insufficient Control Flow Management  CWE-691 11
7 Protection Mechanism Failure  CWE-693 15
      129

 

ハードウェアにもゼロトラスト的な発想で、都度信頼できるかどうかを確かめる(どうやって?)という時代がくるのでしょうかね...それはしんどいですね...

 

NIST - ITL

プレス...

・2024.06.13 Hardware Security Failure Scenarios: Potential Weaknesses in Hardware Design | Draft of NIST IR 8517 is Available for Comment

Hardware Security Failure Scenarios: Potential Weaknesses in Hardware Design | Draft of NIST IR 8517 is Available for Comment ハードウェア・セキュリティの失敗シナリオ: ハードウェア設計における潜在的な弱点|NIST IR 8517のドラフトを公開、コメントを募集中
NIST Internal Report (IR) 8517, Hardware Security Failure Scenarios: Potential Weaknesses in Hardware Design, is now available for public comment. NIST内部報告書(IR)8517「ハードウェア・セキュリティの失敗シナリオ:ハードウェア設計における潜在的な弱点」が、現在パブリックコメントとして入手可能である: ハードウェア設計における潜在的な脆弱性は、現在パブリックコメント用に公開されている。
There is an incorrect and widespread assumption that hardware is inherently secure. However, this report documents numerous potential security failures that can occur in hardware. It also demonstrates the diverse ways in which hardware can be vulnerable. ハードウェアは本質的に安全であるという誤った思い込みが広まっている。しかし、この報告書は、ハードウェアに起こりうる数多くの潜在的なセキュリティ障害を文書化したものである。また、ハードウェアが脆弱性を持ちうる多様な方法を示している。
The authors leveraged existing work on hardware weaknesses to provide a catalog of 98 security failure scenarios. Each of these is a succinct statement that describes how hardware can be exploited, where such an exploitation can occur, and what kind of damage is possible. This should raise awareness of the many types of hardware security issues that can occur. プロバイダは、ハードウェアの弱点に関する既存の研究を活用し、98のセキュリティ障害シナリオのカタログを提供した。これらの各シナリオは、ハードウェアがどのように悪用されうるか、そのような悪用がどこで起こりうるか、どのような損害が起こりうるかを簡潔に記述したものである。これにより、発生しうる多くの種類のハードウェア・セキュリティ問題に対する認識が高まるはずである。

 

 

・2024.06.13 NIST IR 8517 (Initial Public Draft) Hardware Security Failure Scenarios: Potential Weaknesses in Hardware Design

NIST IR 8517 (Initial Public Draft) Hardware Security Failure Scenarios: Potential Weaknesses in Hardware Design NIST IR 8517(初期公開ドラフト) ハードウェアセキュリティの失敗シナリオ: ハードウェア設計における潜在的な弱点
Announcement 発表
There is an incorrect and widespread assumption that hardware is inherently secure. However, this report documents numerous potential security failures that can occur in hardware. It also demonstrates the diverse ways in which hardware can be vulnerable. ハードウェアは本質的に安全であるという誤った思い込みが広まっている。しかし、この報告書は、ハードウェアに起こりうる数多くの潜在的なセキュリティ障害を文書化している。また、ハードウェアが脆弱性を持ち得る多様な方法を示している。
The authors leveraged existing work on hardware weaknesses to provide a catalog of 98 security failure scenarios. Each of these is a succinct statement that describes how hardware can be exploited, where such an exploitation can occur, and what kind of damage is possible. This should raise awareness of the many types of hardware security issues that can occur. プロバイダは、ハードウェアの弱点に関する既存の研究を活用し、98のセキュリティ障害シナリオのカタログを提供した。これらの各シナリオは、ハードウェアがどのように悪用されうるか、そのような悪用がどこで起こりうるか、どのような損害が起こりうるかを簡潔に記述したものである。これにより、発生しうる多くの種類のハードウェア・セキュリティ問題に対する認識が高まるはずである。
... ...
Abstract 概要
Historically, hardware has been assumed to be inherently secure. However, chips are both created with and contain complex software, and software is known to have bugs. Some of these bugs will compromise security. This publication evaluates the types of vulnerabilities that can occur, leveraging existing work on hardware weaknesses. For each type, a security failure scenario is provided that describes how the weakness could be exploited, where the weakness typically occurs, and what kind of damage could be done by an attacker. The 98 failure scenarios provided demonstrate the extensive and broadly distributed possibilities for hardware-related security failures. 歴史的に、ハードウェアは本質的に安全であると想定されてきた。しかし、チップは複雑なソフトウェアと共に作られ、また複雑なソフトウェアを含んでおり、ソフトウェアにはバグがあることが知られている。これらのバグの中には、セキュリティを損なうものもある。本書では、ハードウェアの脆弱性に関する既存の研究を活用し、発生しうる脆弱性のタイプを評価する。各タイプについて、その弱点がどのように悪用されうるか、その弱点が通常どこで発生するか、攻撃者がどのような損害を与えうるかを記述したセキュリティ障害シナリオが提供されている。提供された98の失敗シナリオは、ハードウェア関連のセキュリティ失敗の可能性が広範かつ広範囲に分散していることを示している。



・[PDF] NIST.IR.8517.ipd

20240617-192001

 

目次...

1. Introduction 1. 序文
2. Background 2. 背景
2.1. Weaknesses vs. Vulnerabilities 2.1. 弱点と脆弱性
2.2. Weakness Data Fields 2.2. 弱点のデータフィールド
2.3. Weakness Abstractions 2.3. 弱点の抽象化
2.4. Weakness Views 2.4. 弱点ビュー
 2.4.1. Hardware Design View   2.4.1. ハードウェア設計ビュー 
 2.4.2. Research Concepts View  2.4.2. 研究コンセプト
 2.4.3. Simplified Mapping of Published Vulnerabilities View  2.4.3. 公表された脆弱性の簡易マッピング View
3. Technical Approach 3. 技術的アプローチ
3.1. Concept of Hardware Security Failure Scenarios 3.1. ハードウェア・セキュリティの故障シナリオの概念
 3.1.1. Determining How Weaknesses Occur  3.1.1. 弱点がどのように発生するかを決定する
 3.1.2. Determining Where Weaknesses Occur  3.1.2. どこで弱点が発生するかを決定する
 3.1.3. Determining What Damage Weaknesses Allow  3.1.3. 弱点がどのようなダメージを与えるかを見極める
3.2. Creating Hardware Weakness Subgraphs 3.2. ハードウェアの弱点サブグラフを作成する
4. Hardware Security Failure Scenarios 4. ハードウェアセキュリティの失敗シナリオ
4.1. Improper Access Control 4.1. 不適切なアクセス管理
4.2. Improper Adherence to Coding Standards 4.2. コーディング標準の不適切な遵守
4.3. Improper Check or Handling of Exceptional Conditions 4.3. 例外状態の不適切なチェックまたは処理
4.4. Improper Control of a Resource Through its Lifetime 4.4. リソースのライフタイムを通しての不適切な制御
4.5. Incorrect Comparison 4.5. 不適切な比較
4.6. Insufficient Control Flow Management 4.6. 不十分な制御フロー管理
4.7. Protection Mechanism Failure 4.7. 防御機構の故障
5. Categories of Hardware Design Weaknesses 5. ハードウェア設計の弱点のカテゴリー
5.1. Core and Compute Issues 5.1. コアとコンピュートの問題
5.2. Cross-Cutting Problems 5.2. 横断的な問題
5.3. Debug and Test Problems 5.3. デバッグとテストの問題
5.4. General Circuit and Logic Design Concerns 5.4. 一般的な回路と論理設計の問題
5.5. Integration Issues 5.5. 統合の問題
5.6. Manufacturing and Life Cycle Management Concerns 5.6. 製造とライフサイクル管理に関する問題
5.7. Memory and Storage Issues 5.7. メモリとストレージの問題
5.8. Peripherals, On-chip Fabric, and Interface/10 Problems 5.8. ペリフェラル、オンチップ・ファブリック、インターフェイス/10 の問題
5.9. Physical Access Issues and Concerns 5.9. 物理的アクセスの問題と懸念
5.10. Power, Clock, Thermal, and Reset Concerns 5.10. 電源、クロック、熱、リセットに関する問題
5.11. Privilege Separation and Access Control Issues 5.11. 特権分離とアクセス管理の問題
5.12. Security Flow Issues  5.12. セキュリティ・フローの問題 
5.13. Security Primitives and Cryptography Issues 5.13. セキュリティ・プリミティブと暗号の問題
6. Comparison With Software Weaknesses 6. ソフトウェアの弱点との比較
7. Software Assurance Trends Categories 7. ソフトウェア保証のトレンドカテゴリー
8. Conclusion  8. 結論 
References 参考文献
Appendix A. List of Symbols, Abbreviations, and Acronyms 附属書A. 記号、略語、頭字語のリスト
Appendix B. Analysis of the Complete Hardware Weakness Graph 附属書B. 完全なハードウェア弱点グラフの分析
B.1. Hardware Design Category Overlay B.1. ハードウェア設計カテゴリーオーバーレイ
B.2. Comparison of View-1000 and View-1194 Relationships B.2. View-1000 と View-1194 の関係の比較
Appendix C. Weakness Hierarchy - Improper Access Control 附属書C. 脆弱性の階層 - 不適切なアクセス管理
Appendix D. Weakness Hierarchy - Improper Adherence to Coding Standards 附属書D. 弱点の階層 - コーディング標準の不適切な遵守
Appendix E. Weakness Hierarchy - Improper Check or Handling of Exceptional Conditions  附属書E. 脆弱性の階層 - 例外条件の不適切なチェックや処理 
Appendix F. Weakness Hierarchy - Improper Control of a Resource Through its Lifetime  附属書F.脆弱性の階層 - リソースの有効期間中の不適切なコントロール
Appendix G. Weakness Hierarchy - Incorrect Comparison 附属書G. 弱さの階層 - 不適切な比較
Appendix H. Weakness Hierarchy - Insufficient Control Flow Management 附属書H.弱さの階層 - 不十分なコントロールフロー管理
Appendix I. Weakness Hierarchy - Protection Mechanism Failure 附属書I. 脆弱性階層 - 保護機構の失敗

 

 

弱点 (weaknesses) と脆弱性 (Vulnerabilities)の比較...

2.1. Weaknesses vs. Vulnerabilities  2.1. 弱点と脆弱性の比較 
A weakness can also be defined as a bug or fault type that can be exploited through an operation that results in a security-relevant error [3]. The word ‘type’ is critical as it conveys that a weakness is a concept that can be instantiated in software or hardware; a weakness is not specific to a particular program or chip. A vulnerability, however, is tied to a specific piece of code or chip. A vulnerability is an instantiation of a weakness. Complicating matters, some vulnerabilities arise only in the context of a chain of weaknesses [3].  弱点とは、セキュリティに関連するエラーを引き起こす操作によって悪用される可能性のあるバ グやフォールトの種類と定義することもできる[3]。この「タイプ」という言葉は、弱点がソフトウエアやハードウエアでインスタンス化できる概念であることを伝えるために重要である。しかし脆弱性は、特定のコードやチップと結びついている。脆弱性は弱点のインスタンスなのだ。問題を複雑にしているのは、脆弱性の連鎖の中でしか生じない脆弱性もあることだ [3]。
Vulnerabilities are enumerated in the Common Vulnerabilities and Exposures (CVE) list [6]. The National Vulnerability Database contains details on each CVE [7]. There are over 25,000 CVEs published annually, with the rate usually growing each year. As of February 22, 2024 only 131 of these are HW CVEs.  脆弱性は、CVE(一般的な脆弱性とエクスポージャー)リスト [6]に列挙されている。NVD(国家脆弱性データベース)には、各CVEの詳細が記載されている[7]。毎年25,000以上のCVEが公表されており、その割合は通常、年々増加している。2024年2月22日現在、このうちHW CVEは131件に過ぎない。

 

 

| | Comments (0)

2024.06.08

米国 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

・2024.05.30 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 (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 セキュリティを強化する。

 

20240607-90036 1800-36A ipd  Executive Summary エグゼクティブサマリー
20240607-90046 1800-36B ipd  Approach, Architecture, and Security Characteristics アプローチ、アーキテクチャ、セキュリティの特徴
20240607-90052 1800-36C ipd  How-To Guides ハウツーガイド
20240607-90058 1800-36D ipd Functional Demonstrations 機能デモンストレーション
20240607-90103 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 米国 国家サイバーセキュリティ戦略を発表

・2023.05.07 米国 NIST SP 1800-36 (ドラフト) 信頼できるIoTデバイスのネットワーク層オンボーディングとライフサイクル管理:インターネットプロトコルベースのIoTデバイスとネットワークのセキュリティ強化(初期ドラフト)(2023.05.03)

・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 (0)

2024.05.19

米国 NIST IR 8498(初公開ドラフト) スマートインバータのサイバーセキュリティ: 住宅用および商用簡易太陽光発電システムのガイドライン (2024.05.10)

こんにちは、丸山満彦です。

NISTが、NIST IR 8498(初公開ドラフト) スマートインバータのサイバーセキュリティ: 住宅用および商用簡易太陽光発電システムのガイドライン を発表していますね...

● NIST - ITL

・2024.05.10 NIST IR 8498 (Initial Public Draft) Cybersecurity for Smart Inverters: Guidelines for Residential and Light Commercial Solar Energy Systems

NIST IR 8498 (Initial Public Draft) Cybersecurity for Smart Inverters: Guidelines for Residential and Light Commercial Solar Energy Systems  NIST IR 8498(初公開ドラフト) スマートインバータのサイバーセキュリティ: 住宅用および商用簡易太陽光発電システムのガイドライン
Announcement 発表
The use of small-scale solar energy systems to generate electricity continues to increase. Smart inverters provide two critical functions to a small-scale solar energy system: they convert the direct current (DC) produced by solar panels to the alternating current (AC) used in homes and businesses, and they manage the flow of excess energy to the local electric grid. 小規模太陽光発電システムの利用は増加の一途をたどっている。スマート・インバータは、小規模太陽光発電システムに2つの重要な機能をプロバイダとして提供する。すなわち、ソーラー・パネルで生成された直流(DC)を家庭や企業で使用される交流(AC)に変換し、余剰エネルギーを地域の電力網に流すことを管理する。
This report provides practical cybersecurity guidelines for small-scale solar inverter implementations typically used in homes and small businesses. The report also presents recommendations to smart inverter manufacturers to improve the cybersecurity capabilities in their products. 本報告書では、一般家庭や小規模企業で使用される小規模ソーラーインバーター実装のための実用的なサイバーセキュリティガイドラインを提供する。また、スマートインバーター製造事業者に対し、製品のサイバーセキュリティ機能を改善するための提言も行っている。
These recommendations build on the IoT cybersecurity capability baselines defined in NIST IR 8259A and NIST IR 8259B by providing smart-inverter specific information for all baseline cybersecurity capabilities. これらの提言は、NIST IR 8259AおよびNIST IR 8259Bで定義されたIoTサイバーセキュリティ能力のベースラインに基づいており、すべてのベースラインサイバーセキュリティ能力についてスマートインバータ固有の情報を提供している。
Abstract 概要
The use of residential and light-commercial inverters connected to the distribution network and not directly owned and operated by the utility to generate electricity for homes and small businesses continues to increase. In addition to supplying power to individual homeowners and small business owners these systems can supply power to the electric grid. 配電網に接続され、電力会社が直接所有・運営しない住宅用および商用簡易インバーターの使用は、家庭や小規模事業所向けの発電のために増加し続けている。これらのシステムは、個々の住宅所有者や小規模事業者に電力を供給するだけでなく、電力網に電力を供給することもできる。
Smart inverters provide two critical functions to a small-scale solar energy system; they convert the direct current (DC) produced by solar panels to the alternating current (AC) used on the electric grid, in homes, and businesses. They also manage the flow of excess energy to the electric grid. The “smart” in smart inverter allows these devices to assist the local electric utility in addressing anomalies on the electric grid. However, properly responding to anomalies requires that the smart inverter be configured to behave in a grid-friendly, supportive manner. An improperly configured inverter can respond in inappropriate ways that exacerbate anomalies. スマート・インバータは、小規模な太陽光発電システムに2つの重要な機能を提供する。ソーラー・パネルによって生成された直流(DC)を、電力網や家庭、企業で使用される交流(AC)に変換する。また、余剰エネルギーの電力網への流れを管理する。スマート・インバーターの「スマート」は、これらの機器が地域の電力会社を支援し、電力網の異常に対処することを可能にする。しかし、異常に適切に対応するには、スマート・インバータがグリッドに優しく、支援的な動作をするように設定されている必要がある。不適切に設定されたインバータは、異常を悪化させる不適切な対応をする可能性がある。

 

・[PDF] NIST.IR.8498.ipd

8498-20240518-55948

 

目次...

1. Introduction 1. 序文
1.1. Audience  1.1. 想定読者 
1.2. Report Organization 1.2. 報告書の構成
2. Cybersecurity Guidelines for Owners and Installers 2. 所有者と設置者のためのサイバーセキュリティ・ガイドライン
2.1. Guideline #1: Change Default Passwords and Credentials 2.1. ガイドライン#1: デフォルトのパスワードと認証情報を変更する
2.2. Guideline #2: Use Role-Based Access Control (RBAC)  2.2. ガイドライン#2:役割ベースのアクセス制御(RBAC)を使用する 
2.3. Guideline #3: Record Events in a Log 2.3. ガイドライン#3: ログにイベントを記録する
2.4. Guideline #4: Update Software Regularly 2.4. ガイドライン#4: ソフトウェアを定期的にアップデートする
2.5. Guideline #5: Backup System Information 2.5. ガイドライン#5: システム情報をバックアップする
2.6. Guideline #6: Disable Unused Features 2.6. ガイドライン#6: 使わない機能は無効にする
2.7. Guideline #7: Protect the Communications Connections. 2.7. ガイドライン#7: コミュニケーション接続を防御する。
3. Cybersecurity Recommendations for Smart Inverter Manufacturers 3. スマート・インバータ製造事業者に対するサイバーセキュリティの推奨事項
3.1. Recommended Baseline Cybersecurity Capabilities 3.1. 推奨されるベースライン・サイバーセキュリティ能力
Conclusion  結論 
References 参考文献
Appendix A. Selected Bibliography 附属書 A. 参考文献
Appendix B. List of Symbols, Abbreviations, and Acronyms 附属書 B. 記号、略語、頭字語リスト
Appendix C. Residential and Light Commercial Solar Energy System Setup Cybersecurity Checklist 附属書 C. 住宅用および商用簡易太陽エネルギーシステムのセットアップサイバーセキュリティチェックリスト
Appendix D. Smart Inverter Testing 附属書D. スマートインバータのテスト
D.1. Testing Results for Guideline #1: Change Default Passwords and Credentials  D.1. ガイドライン#1のテスト結果:デフォルトパスワードと認証情報の変更
D.2. Testing Results for Guideline #2: Use Role-Based Access Control D.2. ガイドライン#2のテスト結果:役割ベースのアクセス制御の使用
D.3. Testing Results for Guideline #3: Record Events in a Log  D.3. ガイドライン#3のテスト結果:ログのイベントの記録
D.4. Testing Results for Guideline #4: Update Software Regularly D.4. ガイドライン#4のテスト結果:ソフトウェアの定期的アップデート
D.5. Testing Results for Guideline #5:Backup Systems Information  D.5. ガイドライン#5のテスト結果:システム情報のバックアップ 
D.6. Testing Results for Guideline #6: Disable Unused Features D.6. ガイドライン#6のテスト結果:使用していない機能の無効化
D.7. Testing Results for Guideline #7: Protect the Communications Connections D.7. ガイドライン#7のテスト結果:コミュニケーション接続の防御
Appendix E. Mapping to General Cybersecurity Guidance  附属書E. 一般的なサイバーセキュリティガイダンスへのマッピング 
E.1. General Cybersecurity Guidance that Informs the Guidelines  E.1. ガイドラインに影響を与える一般的なサイバーセキュリティガイダンス
 E.1.1. The NIST Cybersecurity Framework (CSF) Version 2.0  E.1.1. NIST サイバーセキュリティフレームワーク(CSF)バージョン 2.0
 E.1.2. Center for Internet Security Critical Security Controls (CSC) Version 8  E.1.2. Center for Internet Security CSC (Critical Security Controls) バージョン 8
E.1.3. NIST Special Publication 800-53r5 E.1.3. NIST 特別刊行物 800-53r5
E.1.4. NIST Special Publication 800-213A E.1.4. NIST 特別刊行物 800-213A
E.1.5. The MITRE ATT&CK Framework E.1.5. MITRE ATT&CK フレームワーク
E.1.6. ISA/IEC 62443-2-1 E.1.6. ISA/IEC 62443-2-1

 

 

システムの全体像

1_20240519060801

 

 

スマートインバーターの要素...

1_20240519060501

 

 


 

まるちゃんの情報セキュリティ気まぐれ日記

・2021.08.29 NISTIR 8259B IoT非技術的支援能力コアベースライン

・2020.12.17 NIST SP 800-213 (Draft) 連邦政府向け「 IoTデバイスサイバーセキュリティ要件の確立」、NISTIR 8259B、8259C、8259D

・2020.05.30 NIST IoT機器製造者向けセキュリティの実践資料 NISTIR 8259 Foundational Cybersecurity Activities for IoT Device Manufacturers, NISTIR 8259A IoT Device Cybersecurity Capability Core Baseline

| | Comments (0)

2024.05.04

英国 ドイツ チェコ EU ロシア諜報機関による悪質なサイバー活動を非難する声明

こんにちは、丸山満彦です。

英国、ドイツ、チェコ、欧州理事会が、ロシア諜報機関による悪質なサイバー活動を非難する声明を発表していますね。。。

 

英国...

GOV.UK

・2024.05.03 UK joins partners in condemnation of malicious cyber activity by Russian Intelligence Services  : UK government statement

UK joins partners in condemnation of malicious cyber activity by Russian Intelligence Services  : UK government statement 英国は、ロシア諜報機関による悪質なサイバー活動を非難するパートナーに加わる: 英国政府声明
The United Kingdom has joined with its international partners to condemn malicious cyber activity by the Russian Intelligence Services. 英国は、国際的なパートナーとともに、ロシア情報機関による悪質なサイバー活動を非難した。
A UK government spokesperson said: 英国政府の報道官は次のように述べた:
The United Kingdom stands with the European Union, Germany, Czechia and other allies in strongly condemning malicious cyber activity by Russian Intelligence Services. 英国は、欧州連合(EU)、ドイツ、チェコ、その他の同盟国とともに、ロシア情報機関による悪質なサイバー活動を強く非難する。
Today’s statements from our allies demonstrate the scale, persistence, and seriousness of unacceptable Russian behaviours in cyberspace. 今日の同盟国の声明は、サイバー空間におけるロシアの容認できない行動の規模、持続性、深刻さを示している。
Recent activity by Russian GRU cyber group APT28, including the targeting of the German Social Democratic Party executive, is the latest in a known pattern of behaviour by the Russian Intelligence Services to undermine democratic processes across the globe. ドイツ社会民主党幹部を標的にしたことを含む、ロシアGRUのサイバーグループAPT28による最近の活動は、世界中の民主的プロセスを弱体化させようとするロシア情報機関による既知の行動パターンの最新のものである。
On 7 December 2023, the UK exposed a series of attempts by the Russian Intelligence Services to target high-profile UK individuals and entities through cyber operations. At the same time, we sanctioned two Russian nationals responsible for political interference. 2023年12月7日、英国はロシア情報部がサイバー作戦を通じて英国の著名な個人や事業体を標的にした一連の試みを暴露した。同時に、政治干渉に関与した2人のロシア人を制裁した。
With multiple elections around the world in 2024, raising awareness of the threat to the UK and our international partners remains vitally important for our collective resilience. 2024年には世界各地で複数の選挙が予定されており、英国や国際的パートナーに対する脅威に対する認識を高めることは、我々の集団的レジリエンスにとって極めて重要である。
Today, as part of a broad coalition of allies, we are making clear to the Russian state that we will continue to identify, expose, and respond to such unacceptable activity. 今日、同盟国の広範な連合の一員として、我々はロシア国家に対し、このような容認できない活動を特定し、暴露し、対応し続けることを明確にしている。
Background   背景  
View the statements from our international partners: 国際パートナーからの声明を見る
Germany ドイツ
Czechia チェコ
EU EU
APT28 are capable cyber actors who have been active since at least 2004. They are known by industry nicknames including Strontium, Sofacy Group, Pawn Storm, Fancy Bear, and Sednit APT28は、少なくとも2004年から活動している有能なサイバー・アクターである。彼らは、Strontium、Sofacy Group、Pawn Storm、Fancy Bear、Sednitなどの業界のニックネームで知られている。
the UK has previously exposed APT28 as part of the GRU, the Russian military intelligence service, including:   英国は以前、APT28がロシアの軍事情報機関GRUの一部であることを暴露している:  
in 2018, the UK and the Netherlands exposed an attempted attack against the Organisation for the Prohibition of Chemical Weapons (OPCW) by APT28, aimed at disrupting independent analysis of chemicals weaponised by the GRU in the UK 2018年、英国とオランダは、APT28による化学兵器禁止機関(OPCW)に対する攻撃未遂を暴露し、英国のGRUによって兵器化された化学物質の独立分析を妨害することを目的とした。
in 2020, the UK announced sanctions against APT28 and 2 individual GRU officers for their reckless cyber-attacks on Germany’s Parliament in 2015, which affected email accounts belonging to German MPs and the German Vice Chancellor 2020年、英国はAPT28とGRU職員2名に対する制裁を発表した。APT28は2015年にドイツの議会に対して無謀なサイバー攻撃を行い、ドイツの国会議員と副首相の電子メールアカウントに影響を与えた。
in 2023, the UK and US technical communities released a joint advisory to provide details of tactics, techniques and procedures associated with APT28’s exploitation of Cisco routers in 2021 2023年、英米の技術コミュニティは共同勧告を発表し、2021年にAPT28がシスコのルーターを悪用したことに関連する戦術、技術、手順の詳細を提供した。
the UK Government also supports Germany’s assessment that APT28 exploited critical security vulnerabilities in Microsoft Outlook directed against email accounts of the German Social Democratic Party 英国政府はまた、APT28がMicrosoft Outlookの重要なセキュリティ脆弱性を悪用し、ドイツ社会民主党の電子メールアカウントに攻撃を仕掛けたというドイツの評価を支持している。

 

ドイツ連邦政府...

● Bundesregierung

・2024.05.03 [PDF] Erklärung der Bundesregierung zur Attribuierung einer russischen Cyberkampagne

・2024.05.03 [PDF] English version: Statement by the Federal Government on the attribution of a Russian cyber campaign

Attribution of a Russian cyber campaign  ロシアのサイバーキャンペーンを非難する 
The Federal Government condemns in the strongest possible terms – and with the support of the European Union, NATO and international partners – the campaign by the state-sponsored cyber actor APT28 that targeted the Executive Committee of the Social Democratic Party of Germany.  連邦政府は、欧州連合(EU)、北大西洋条約機構(NATO)および国際的パートナーの支援を受けて、ドイツ社会民主党執行委員会を標的にした国家支援によるサイバー行為者APT28によるキャンペーンを、可能な限り強い言葉で非難する。
The Federal Government’s national attribution procedure regarding this campaign has concluded that, for a relatively long period, the cyber actor APT28 used a critical vulnerability in Microsoft Outlook that remained unidentified at the time to compromise numerous email accounts.  このキャンペーンに関する連邦政府の国家帰属手続きは、比較的長期間にわたり、サイバー行為者APT28が、当時未確認であったMicrosoft Outlookの脆弱性を利用して、多数の電子メールアカウントを侵害したと結論づけた。
Based on reliable information provided by our intelligence services, the actor APT28 has been attributed to the Russian Federation, and more specifically to the Russian military intelligence service GRU.  われわれの諜報機関から提供された信頼できる情報に基づき、APT28はロシア連邦、より具体的にはロシア軍事情報機関GRUに帰属するとされている。
What is more, this actor’s campaign also targeted various government authorities and companies in the spheres of logistics, armaments, the air and space industry, and IT services, as well as foundations and associations. It was directed at entities in Germany, other European countries and targets in Ukraine.  さらに、この行為者のキャンペーンは、さまざまな政府当局や、ロジスティクス、軍需、航空・宇宙産業、ITサービスの分野の企業、さらには財団や協会も標的にしていた。ドイツや他の欧州諸国の事業体、ウクライナの標的を狙ったものだった。
APT28 is also responsible for the cyber attack that was perpetrated on the German Bundestag in 2015.   APT28は2015年にドイツ連邦議会で行われたサイバー攻撃にも関与している。 
Such irresponsible actions in cyberspace contravene international cyber norms and deserve special attention, especially in a year in which many countries are holding elections.   サイバー空間におけるこのような無責任な行動は、国際的なサイバー規範に反するものであり、特に多くの国で選挙が行われる今年、特別な注意を払うに値する。 
Cofyber attacks against political parties, state institutions and companies that provide critical infrastructure pose a threat to our democracy, our national security and our liberal-minded society.   政党、国家機構、重要インフラを提供する企業に対するサイバー攻撃は、民主主義、国家安全保障、自由主義社会に対する脅威である。 
The Federal Government most strongly condemns the repeated and unacceptable malicious cyber activities by state-sponsored Russian actors and again calls on Russia to refrain from such behaviour. Germany is determined to work together with its European and international partners to counter such malicious cyber activities.  連邦政府は、国家に支援されたロシア人による度重なる容認しがたい悪質なサイバー活動を最も強く非難し、ロシアに対し、そのような行動を慎むよう改めて求める。ドイツは、欧州および国際的なパートナーと協力して、このような悪意あるサイバー活動に対抗していく決意である。

 

・チェコ

Ministory of Foreign Affairs of the Czech Republic

・2024.05.03 Statement of the MFA on the Cyberattacks Carried by Russian Actor APT28 on Czechia

Cyberattacks Carried by Russian Actor APT28 on Czechia ロシアのAPT28によるチェコへのサイバー攻撃
Czechia jointly with Germany, the European Union, NATO and international partners strongly condemns activities of the Russian state-controlled actor APT28, who has been conducting a long-term cyber espionage campaign in European countries. APT28 is associated with Russian military intelligence service GRU. チェコはドイツ、欧州連合(EU)、北大西洋条約機構(NATO)および国際的パートナーとともに、欧州諸国で長期的なサイバースパイキャンペーンを展開しているロシア国家統制下の行為者APT28の活動を強く非難する。APT28はロシアの軍事情報機関GRUと関連している。
Based on information from intelligence services, some Czech institutions have also been the target of cyber attacks exploiting a previously unknown vulnerability in Microsoft Outlook from 2023. The mode of operation and the focus of these attacks matched the profile of the actor APT28. 諜報機関からの情報によると、チェコのいくつかの機構は、2023年からマイクロソフト・アウトルックのこれまで知られていなかった脆弱性を悪用したサイバー攻撃の標的にもなっている。これらの攻撃の動作モードと焦点は、行為者APT28のプロファイルと一致した。
Affected subjects were offered technical recommendations and cooperation to enhance security measures. The actor APT28 has also been the subject to active measures in Czechia as part of the global operation Dying Ember. 被害を受けた対象者には、セキュリティ対策を強化するための技術的な勧告と協力が提供された。行為者APT28は、世界的な活動「Dying Ember」の一環として、チェコでも積極的な対策の対象となっている。
Czechia has long been targeted by the APT28. Such activities are in violation of the UN norms of responsible state behaviour in cyberspace and other international commitments. In the context of the upcoming European elections, national elections in a number of European countries and the ongoing Russian aggression against Ukraine, these acts are particularly serious and reprehensible. We call on the Russian Federation to refrain from such actions. チェコは以前からAPT28に狙われていた。このような活動は、サイバー空間における国家の責任ある行動に関する国連規範やその他の国際公約に違反している。今度の欧州選挙、多くの欧州諸国の国政選挙、そして現在進行中のロシアのウクライナ侵略という状況の中で、これらの行為は特に深刻であり、非難されるべきものである。我々はロシア連邦に対し、このような行為を控えるよう求める。
Cyber attacks targeting political entities, state institutions and critical infrastructure are not only a threat to national security, but also disrupt the democratic processes on which our free society is based. Czech authorities will continue to take steps to strengthen the resilience of public institutions and the private sector. 政治事業体、国家機構、重要インフラを標的にしたサイバー攻撃は、国家安全保障に対する脅威であるだけでなく、我々の自由な社会が基盤としている民主的プロセスを混乱させるものである。チェコ当局は、公的機関と民間セクターのレジリエンスを強化するための措置を継続する。
Czechia is deeply concerned by these repeated cyber attacks by state actors. We are determined to respond strongly to this unacceptable behaviour together with our European and international partners. チェコは、国家主体による度重なるサイバー攻撃に深い懸念を抱いている。我々は、欧州及び国際的なパートナーとともに、この容認できない行為に強力に対応していく決意である。

 

European Council

・2024.05.03 Cyber: Statement by the High Representative on behalf of the EU on continued malicious behaviour in cyberspace by the Russian Federation

 

Cyber: Statement by the High Representative on behalf of the EU on continued malicious behaviour in cyberspace by the Russian Federation サイバー ロシア連邦によるサイバー空間での悪意ある行動の継続に関するEUを代表する上級代表の声明
The European Union and its Member States, together with international partners, strongly condemn the malicious cyber campaign conducted by the Russia-controlled Advanced Persistent Threat Actor 28 (APT28) against Germany and Czechia. Today, Germany has shared publicly its assessment on APT28 compromise of various e-mail accounts of the German Social Democratic Party executive. At the same time, Czechia announced its institutions have been a target of this cyber campaign. State institutions, agencies and entities in Member States, including in Poland, Lithuania, Slovakia and Sweden have been targeted by the same threat actor before. In 2020, the EU imposed sanctions on individuals and entities responsible for the APT28 attacks targeting the German Federal Parliament in 2015. 欧州連合(EU)および加盟国は、国際的パートナーとともに、ロシアが支配する高度持続的脅威行為者28(APT28)がドイツおよびチェコに対して行った悪質なサイバー脅威キャンペーンを強く非難する。本日、ドイツは、APT28によるドイツ社会民主党幹部のさまざまな電子メールアカウントの侵害に関する評価を公表した。同時に、チェコは自国の機構がこのサイバーキャンペーンの標的になったと発表した。ポーランド、リトアニア、スロバキア、スウェーデンを含む加盟国の国家機関、機関、事業体は、以前にも同じ脅威行為者に狙われている。2020年、EUは2015年にドイツ連邦議会を標的としたAPT28攻撃に関与した個人と事業体に対して制裁を科した。
The malicious cyber campaign shows Russia’s continuous pattern of irresponsible behaviour in cyberspace, by targeting democratic institutions, government entities and critical infrastructure providers across the European Union and beyond. 今回の悪意あるサイバーキャンペーンは、EU域内外の民主的機構、政府事業体、重要インフラプロバイダーを標的にすることで、サイバー空間におけるロシアの継続的な無責任な行動パターンを示している。
This type of behaviour is contrary to the UN norms of responsible state behaviour in cyberspace, such as impairing the use and operation of critical infrastructure. Disregarding international security and stability, Russia has repeatedly leveraged APT28 to conduct malicious cyber activities against the EU, its Member States and international partners, most notably Ukraine. この種の行動は、重要インフラの利用や運用を損なうなど、サイバー空間における国家の責任ある行動に関する国連の規範に反している。国際的な安全保障と安定を無視し、ロシアはAPT28を繰り返し活用し、EU、加盟国、国際的パートナー(特にウクライナ)に対して悪意あるサイバー活動を行ってきた。
The EU will not tolerate such malicious behaviour, particularly activities that aim to degrade our critical infrastructure, weaken societal cohesion and influence democratic processes, mindful of this year’s elections in the EU and in more than 60 countries around the world. The EU and its Member States will continue to cooperate with our international partners to promote an open, free, stable and secure cyberspace. EUは、このような悪意ある行為、特にEUの重要なインフラを劣化させ、社会の結束を弱め、今年のEUおよび世界60カ国以上で実施される選挙を意識した民主的プロセスに影響を及ぼすことを目的とする行為を容認しない。EUおよび加盟国は、開かれた、自由で、安定した、安全なサイバー空間を促進するため、国際的なパートナーと引き続き協力していく。
The EU is determined to make use of the full spectrum of measures to prevent, deter and respond to Russia’s malicious behaviour in cyberspace. EUは、サイバー空間におけるロシアの悪意ある行動を防止し、抑止し、対応するために、あらゆる手段を活用していく決意である。

1_20240503234301 

 

| | Comments (0)

2024.05.01

中国 TC260 意見募集 国家標準 「政府業務におけるデータ処理のセキュリティ要件」案 (2024.04.15)

こんにちは、丸山満彦です。

中国の国家情報セキュリティ標準化技術委員会 (TC260) が「政府業務におけるデータ処理のセキュリティ要件」の草案を公表し、意見募集をしていますね。。。

政府業務なので、米国でいえば、NISTの文書、日本であれば、NISCの統一基準に相当するものなのでしょうかね...

細かく規定されているので、参考になる部分も多いように思います...

 

● 全国信息安全标准化技术委员会

・2024.04.15 关于国家标准《数据安全技术 政务数据处理安全要求》征求意见稿征求意见的通知

意見募集案...

・[PDF] 数据安全技术 政务数据处理安全要求-标准文本

20240430-225850

・[DOCX] [PDF] 仮訳

 

説明...

・[PDF] 数据安全技术 政务数据处理安全要求-编制说明

20240430-230018

 

 

| | Comments (0)

2024.04.30

中国 TC260 意見募集 国家標準 「情報システムの災害復旧仕様」案 (2024.04.15)

こんにちは、丸山満彦です。

中国の国家情報セキュリティ標準化技術委員会 (TC260) が「情報システムの災害復旧仕様」の草案を公表し、意見募集をしていますね。。。

信息安全技术 信息系统灾难恢复规范 (情報セキュリティ技術情報システムの災害復旧に関する仕様)」(GB/T 20988-2007)及び「信息安全技术 灾难恢复中心建设与运维管理规定(情報セキュリティ技術災害復旧センターの建設管理及び運営維持に関する仕様)」(GB/T 30285-2013)に替わるもののようです...

 

わりと細かく規定されているので、参考になる部分も多いように思います...

 

● 全国信息安全标准化技术委员会

・2024.04.15 关于国家标准《网络安全技术 信息系统灾难恢复规范》征求意见稿征求意见的通知

意見募集案...

・[PDF] 网络安全技术 信息系统灾难恢复规范-标准文本

20240430-20041

・[DOCX][PDF] 仮訳

 

説明

・[DOCX] 网络安全技术 信息系统灾难恢复规范-编制说明

 


Continue reading "中国 TC260 意見募集 国家標準 「情報システムの災害復旧仕様」案 (2024.04.15)"

| | Comments (0)

2024.04.23

監査役協会 公認会計士協会 「監査役等と監査人との連携に関する共同研究報告」の改正(公開草案)

こんにちは、丸山満彦です。

日本監査役協会(会計委員会)と、日本公認会計士協会(監査・保証基準委員会)が、「監査役等と監査人との連携に関する共同研究報告」を2005年7月に公表していましたが、状況の変化を踏まえ、改訂するようです。公開草案を公表し、意見募集をしていますね...

前回の改訂が2021年ですから3年目の改訂。

改訂のポイントは、

① 倫理規則(2022年7月改正)

② 上場会社等監査人登録制度(公認会計士法及び金融商品取引法(2022年5月改正)、監査法人のガバナンス・コード(2023年5月改訂))

③ 四半期開示制度の見直し(金融商品取引法(2023年11月改正))

というのがポイントのようです...

 

日本公認会計士協会

・2024.04.22 「監査役等と監査人との連携に関する共同研究報告」の改正(公開草案)の公表について

・[PDF

20240423-113602

 

日本監査役協会

・2024.04.22 (意見募集)「監査役等と監査人との連携に関する共同研究報告」改正公開草案を公表

・・[PDF] ニュースリリース

・・[PDF] 「監査役等と監査人との連携に関する共同研究報告」改正公開草案

 

 

 

 

| | Comments (0)

2024.04.19

米国 NIST NIST IR 8425A(初期公開ドラフト)消費者向けルータ製品に推奨されるサイバーセキュリティ要件

こんにちは、丸山満彦です。

NISTが、連邦政府内部むけの「NIST IR 8425A(初期公開ドラフト)消費者向けルータ製品に推奨されるサイバーセキュリティ要件」を公表し、意見募集をしていますね...

Consumer-Grade Router ”を「消費者向けルータ」と訳していみましたが、

この文書では、

2. Scope of Consumer-Grade Routers  2. 消費者向けルータの範囲 
This profile identifies minimum cybersecurity for consumer-grade routers. Consumer-grade routers are defined as networking devices which are primarily intended for residential use and can be installed by the customer. Routers forward data packets, most commonly Internet Protocol (IP) packets, between networked systems. The profile makes no distinction in its  cybersecurity recommendations with regards to whether the product is owned by the customer or leased from an internet service provider.  このプロファイルは、消費者向けルータの最低限のサイバーセキュリティを特定する。消費者向けルータは、主に家庭での使用を目的とし、顧客が設置できるネットワーキング・デバイスと定義される。ルータはデータパケット(最も一般的なものはインターネットプロトコル(IP)パケット)をネットワークシステム間で転送する。このプロファイルでは、サイバーセキュリティに関する推奨事項の中で、製品が顧客によって所有されているか、インターネット・サービス・プロバイダーからリースされているかについて区別していない。

となっているので、普通に家で使うようにアマゾンとかで買って、自分で設置するルータということのようです。

 

 

● NIST - ITL

・2024.04.17 NIST IR 8425A (Initial Public Draft) Recommended Cybersecurity Requirements for Consumer-Grade Router Products

NIST IR 8425A (Initial Public Draft) Recommended Cybersecurity Requirements for Consumer-Grade Router Products NIST IR 8425A(初期公開ドラフト)消費者向けルータ製品に推奨されるサイバーセキュリティ要件
Announcement 発表
This report presents the consumer-grade router profile, which includes cybersecurity outcomes for consumer-grade router products and associated requirements from router standards. Routers serve as the gatekeepers of our networks, managing the flow of data between devices in the home or office and the internet. A compromised router opens the door to a host of potential exploited vulnerabilities and impacts, making router cybersecurity is of paramount importance in today's interconnected world. 本報告書は、消費者向けルータ製品のサイバーセキュリティの成果と、ルータ規格の関連要件を含む、消費者向けルータのプロファイルを提示する。ルータは、家庭やオフィスの機器とインターネット間のデータの流れを管理し、ネットワークのゲートキーパーとしての役割を果たしている。危殆化したルータは、潜在的に悪用される脆弱性と影響のホストへの扉を開き、ルータのサイバーセキュリティは今日の相互接続された世界において最も重要である。
Recommended Cybersecurity Requirements for Consumer-Grade Router Products includes the following topics: 消費者向けルータ製品に推奨されるサイバーセキュリティ要件には、以下のトピックが含まれる:
・How product components around consumer-grade router devices can vary and be assembled into consumer-grade router products ・消費者向けルータ・機器周辺の製品コンポーネントがどのように変化し、消費者向けルータ製品に組み立てられるか
・Cybersecurity considerations for consumer-grade routers ・消費者向けルータに対するサイバーセキュリティの考慮事項
・Standards and guidance related to cybersecurity outcomes for consumer-grade routers ・消費者向けルータのサイバーセキュリティの成果に関連する規格と指針
・Consideration of cybersecurity approaches for consumer-grade router products not documented in current standards and guidance ・現行の基準およびガイダンスに記載されていない、消費者向けルータ製品のサイバーセ キュリティ・アプローチの検討
Abstract 概要
Ensuring the security of routers is crucial for safeguarding not only individuals’ data but also the integrity and availability of entire networks. With the increasing prevalence of smart home IoT devices and remote work setups, the significance of consumer-grade router cybersecurity has expanded, as these devices and applications often rely on routers in the home to connect to the internet. This report presents the consumer-grade router profile, which includes cybersecurity outcomes for consumer-grade router products and associated requirements from router standards. ルータのセキュリティを確保することは、個人のデータだけでなく、ネットワーク全体の完全性と可用性を保護するためにも極めて重要である。スマートホームIoT機器やリモートワークのセットアップの普及に伴い、これらの機器やアプリケーションはインターネットに接続するために家庭内のルータに依存することが多いため、消費者向けルータのサイバーセキュリティの重要性は拡大している。本レポートでは、消費者向けルータ製品のサイバーセキュリティの成果と、ルータ規格の関連要件を含む、消費者向けルータのプロファイルを紹介する。

 

・[PDF] IR.8425A.ipd

20240419-60120

 

目次...

1. Introduction 1. はじめに
2. Scope of Consumer-Grade Routers 2. 消費者向けルータの範囲
2.1. Cybersecurity Utilizing the Full Product 2.1. 全製品を活用したサイバーセキュリティ
3. Conclusion 3. おわりに
References 参考文献
Appendix A. Crosswalk between Technical Outcomes and Consumer-Grade Router Cybersecurity and Firmware Requirements 附属書 A. 技術的成果と消費者向けルータのサイバーセキュリティおよびファームウェア要件とのクロスウォーク
A.1. Asset Identification A.1. 資産の特定
A.2. Product Configuration A.2. 製品構成
A.3. Data Protection. A.3. データ保護
A.4. Interface Access Control 1 A.4. インターフェイス・アクセス制御 1
A.5. Interface Access Control 2 A.5. インターフェース・アクセス制御 2
A.6. Software Update A.6. ソフトウェアの更新
A.7. Cybersecurity State Awareness A.7. サイバーセキュリティ状態の認識
Appendix B. Non-Technical Outcome Considerations 附属書 B. 技術的な成果以外の考慮事項
Appendix C. Consumer-Grade Router Acquisition Scenarios Discussion 附属書 C. 消費者向けルータ取得シナリオの検討
Appendix D. Crosswalk Between Secure Software Development Tasks and Consumer-Grade Router Product Software Type 附属書 D. セキュアソフトウェア開発タスクと消費者向けルータ製品ソフトウェアタイプの間のクロスウォーク
Appendix E. List of Symbols, Abbreviations, and Acronyms 附属書 E. 記号、略語、および頭字語の一覧
Appendix F. Glossary 附属書 F. 用語集

 

1. Introduction  1. はじめに 
Router cybersecurity is of paramount importance in today's interconnected world, where digital communication plays a central role in both personal and professional spheres. Routers serve as the gatekeepers of our networks, managing the flow of data between devices in the home or office and the internet. A compromised router opens the door to a host of potential exploited vulnerabilities and impacts, ranging from unauthorized access, sensitive information dissemination, to the possibility of malicious attacks on connected devices. Ensuring the security of routers is crucial for safeguarding not only individual privacy and safety, but also the integrity and availability of entire networks. With the increasing prevalence of smart home IoT devices and remote work setups, the significance of consumer-grade router cybersecurity has expanded, as these devices and applications often rely on routers in the home to connect to the internet. A secure home router (i.e., one that is consumer-grade) not only protects U.S. citizens against data theft and other cyberattacks but also contributes to the overall resilience of the global digital infrastructure. As technology advances, the need for robust router cybersecurity becomes ever more critical to maintain a safe and trustworthy digital environment.  ルータのサイバーセキュリティは、デジタル通信が個人と仕事の両方の領域で中心的な役割を果たす、今日の相互接続された世界において最も重要である。ルータはネットワークのゲートキーパーの役割を果たし、家庭やオフィスの機器とインターネット間のデータの流れを管理する。ルータが危険にさらされると、不正アクセスや機密情報の流出、接続機器への悪意ある攻撃の可能性など、潜在的な脆弱性が悪用され、多くの影響がもたらされる可能性がある。ルータのセキュリティを確保することは、個人のプライバシーと安全性だけでなく、ネットワーク全体の完全性と可用性を守るためにも極めて重要である。スマートホームIoT機器やリモートワークのセットアップの普及に伴い、これらの機器やアプリケーションはインターネットに接続するために家庭内のルータに依存することが多いため、消費者向けルータ・サイバーセキュリティの重要性は拡大している。安全な家庭用ルータ(すなわちコンシューマ・グレードのもの)は、データ盗難やその他のサイバー攻撃から米国民を守るだけでなく、グローバルなデジタルインフラ全体の回復力にも貢献する。技術の進歩に伴い、安全で信頼できるデジタル環境を維持するためには、堅牢なルータのサイバーセキュリティの必要性がますます重要になっている。
This report presents the consumer-grade router profile, which recommends cybersecurity outcomes for consumer-grade router products and associated requirements from consumergrade router standards. This profile was developed starting from the outcomes defined for consumer IoT products in Profile of the IoT Core Baseline for Consumer IoT Products, NISTIR 8425 [IR8425]. Though developed for consumer IoT products the NISTIR 8425 outcomes are important cybersecurity guidance for any digital product. Outcomes can be technical (i.e., implemented through hardware and/or software) or non-technical (i.e., implemented as procedures and processes by organizations or individuals). In this context, outcomes are broad, flexible guidelines that can apply, albeit differently, to different use cases and contexts, while requirements are targeted specifications that can define meeting an outcome for a specific use case, context, technology, etc. The guidance in this document has been developed uniquely for consumer-grade routers using cybersecurity considerations and standards specific to that product type. NIST recommends the use of the following standards for the cybersecurity of consumer-grade router products:  本報告書では、消費者向けルータ製品のサイバーセキュリティの成果と、消費者向けルータ規格の関連要件を推奨する、消費者向けルータ・プロファイルを提示する。このプロファイルは、「Profile of the IoT Core Baseline for Consumer IoT Products」(NISTIR 8425 [IR8425])でコンシューマ向け IoT 製品向けに定義された成果を基に開発された。コンシューマ・向け IoT 製品向けに開発されたとはいえ、NISTIR 8425 の成果はあらゆるデジタル製品にとって重要なサイバーセキュリティガイダンスである。アウトカムは、技術的なもの(すなわち、ハードウェアおよび/またはソフトウェアを通じて実装されるもの)であることもあれば、非技術的なもの(すなわち、組織や個人による手順やプロセスとして実装されるもの)であることもある。この文脈では、アウトカムとは、異なるユースケースやコンテクストに異なるとはいえ適用できる広範で柔軟なガイドラインであり、一方、要件とは、特定のユースケース、コンテクスト、技術などに対してアウトカムを満たすことを定義できる的を絞った仕様である。本文書のガイダンスは、その製品タイプに特有のサイバーセキュリティの考慮事項と基準を用いて、消費者向けルータ向けに独自に作成されたものである。NIST は、消費者向けルータ製品のサイバーセキュリティについて、以下の規格の使用を推奨している: 
1. Broadband Forum (BBF) TR-124 Issue 8 – Functional Requirements for Broadband Residential Gateway Devices [BBF]  1. ブロードバンド・フォーラム(BBF)TR-124 Issue 8 - ブロードバンド住宅用ゲートウェイ機器の機能要件 [BBF] 
2. CableLabs (CL) Security Gateway Device Security Best Common Practices [CableLabs]  2. CableLabs (CL) Security Gateway Device Security Best Common Practices [CableLabs] 
3. Federal Office for Information Security (BSI) TR-03148: Secure Broadband Router - Requirements for secure Broadband Routers [BSI]  3. 連邦情報セキュリティ局(BSI)TR-03148:セキュアブロードバンドルータ-セキュアブロードバンドルータの要件 [BSI] 
4. Infocomm Media Development Authority (IMDA) Technical Specification Security Requirements for Residential Gateways [IMDA]  4. Infocomm Media Development Authority (IMDA) Technical Specification Security Requirements for Residential Gateways [IMDA] 
5. Platform Firmware Resiliency Guidelines, SP 800-193 [SP800-193]  5. プラットフォームファームウェアレジリエンシーガイドライン、SP 800-193 [SP800-193] 
6. Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, SP 800-161 Rev. 1 [SP800-161r1]  6. システム及び組織のためのサイバーセキュリティ・サプライチェーン・リスク管理の実践、SP 800-161 Rev. 1 [SP800-161r1] 
7. Secure Software Development Framework (SSDF) Version 1.1: Recommendations for 177  7. セキュアソフトウェア開発フレームワーク(SSDF)バージョン 1.1: 177 のための推奨事項 
8. Information technology — Security techniques — Vulnerability disclosure processes, 179  8. 情報技術 - セキュリティ技術 - 脆弱性開示プロセス
9. Information technology — Security techniques — Vulnerability handling, ISO/IEC 30111 [ISO30111]  9. 情報技術 - セキュリティ技術 - 脆弱性ハンドリング、 ISO/IEC 30111 [ISO30111] 
10. Risk management — Guidelines, ISO 31000 [ISO31000]  10. リスクマネジメント-ガイドライン、ISO 31000 [ISO31000] 
11. Systems and software engineering — Design and development of information for users, ISO/IEC/IEEE 26514 [ISO26514]  11. システム及びソフトウェア工学-利用者のための情報の設計及び開発、ISO/IEC/IEEE 26514 [ISO26514] 
NIST recommends the use of four existing consumer-grade router standards[1] (i.e., items 1 through 4 in the list above). Requirements from the standards for consumer-grade routers focused primarily on the router device, discussing many cybersecurity capabilities appropriate for this equipment. Figure 1 notionally[2] depicts that requirements of the four consumer-grade router device standards were mostly unique and had minimal overlap. Few requirements from the different standards repeat, and each standard’s requirements offer useful details about how cybersecurity outcomes can be met by consumer-grade router devices. Additional technical requirements for firmware are introduced by SP 800-193 (i.e., item 5). Appendix A provides a crosswalk between technical cybersecurity outcomes for consumer-grade router NISTは、4つの既存の消費者向けルータ規格[1](すなわち、上記リストの項目1から4)の使用を推奨している。消費者向けルータに関する規格の要件は、主にルータ機器に焦点を当て、この機器に適した多くのサイバーセキュリティ機能について議論している。図 1 は、概念的に[2]、4 つの消費者向けルータ・機器の規格の要件がほとんど独自であり、重複が最小限であることを示している。また、各規格の要件は、消費者向けルータ機器がどのようにサイ バーセキュリティの成果を満たすことができるかについて、有益な詳細を提供している。ファームウェアに関する追加の技術的要件は、SP 800-193 によって導入された(すなわち、項目 5)。附属書 A は、消費者向けルータの技術的なサイバーセキュリティの成果間のクロスウォークを提供する。
1_20240419063901
Fig. 1. Most requirements from the four consumer-grade router standards do not repeat.   図 1. 4 つの消費者向けルータ規格のほとんどの要件は重複しない 
The requirements from the four router standards address technical cybersecurity for consumer-grade router devices but not the non-technical cybersecurity outcomes nor cybersecurity for product components other than the router device (e.g., backend, mobile application) since they contain few requirements for non-technical supporting capabilities and no requirements for other product components (e.g., mobile application). Therefore, additional standards (i.e., items 6 through 11) are recommended to help fill some of those gaps in the consumer-grade router standards, particularly for non-technical outcomes. Appendix B discusses some additional considerations and guidance for non-technical outcomes.  4 つのルータ規格の要件は、消費者向けルータ機器の技術的なサイバーセキュリティを扱っ ているが、非技術的なサイバーセキュリティの成果や、ルータ機器以外の製品コンポーネント(バックエンド、モ バイルアプリケーションなど)のサイバーセキュリティは扱っていない。そのため、特に非技術的な成果に関して、消費者向けルータ規格のこれらのギャップを埋めるために、追加規格(すなわち、項目 6 から 11)が推奨される。附属書 B では、非技術的な成果に関する追加の考慮事項とガイダンスについて説明する。
This list is intended as a minimum starting point and may not address all the cybersecurity considerations for every consumer-grade router product. Full support of all outcomes in this profile by all consumer-grade router product components is expected. To ensure cybersecurity consideration of all consumer-grade router product components, the Product Development Cybersecurity Handbook [CSWP33] is recommended in addition to the standards indicated above. If a consumer-grade router product has additional product components, such as a smart phone mobile application, additional technical product cybersecurity capability requirements would also be necessary to meet the outcomes for the complete consumer-grade router product. These considerations are discussed generally for digital products in the handbook. Figure 2 shows how the standards listed above relate to cybersecurity outcomes (i.e., the technical vs. non-technical outcomes) and components of consumer-grade router products (i.e., consumer-grade router device vs. other consumer-grade router product components).  このリストは最低限の出発点として意図されたものであり、すべての消費者向けルータ製品に対す るすべてのサイバーセキュリティ上の考慮事項に対応するものではない。すべての消費者向けルータ製品のコンポーネントがこのプロファイルのすべての成果を完全にサポートすることが期待される。すべての消費者向けルータ製品コンポーネントのサイバーセキュリティへの配慮を確実にするために、上 記の基準に加えて、製品開発サイバーセキュリティハンドブック[CSWP33]を推奨する。消費者向けルータ製品に、スマートフォンのモバイルアプリケーションのような追加の製品 コンポーネントがある場合、消費者向けルータ製品全体の成果を満たすためには、追加の 技術的製品サイバーセキュリティ能力要件も必要となる。これらの考慮事項については、ハンドブックにおいてデジタル製品全般について論じている。図 2 は、上記の基準が、サイバーセキュリティの成果(すなわち、技術的な成果と非技術的な成果)お よび消費者向けルータ製品の構成要素(すなわち、消費者向けルータ装置と他のコンシューマ・ グレード・ルータ製品の構成要素)にどのように関連しているかを示している。
2_20240419063901
Fig. 2. Recommended guidance documents and standards support cybersecurity outcomes for all parts of 図 2. 推奨されるガイダンス文書と標準規格は、消費者向けルータ製品のすべての部品に対す るサイバーセキュリティの成果をサポートする。
The rest of this document provides additional discussion of cybersecurity context and expectations related to consumer-grade router products, structured as follows:  本文書の残りの部分では、消費者向けルータ製品に関連するサイバーセキュリティの背景と期 待について、以下のような構成で追加的な議論を行う: 
• Section 2 states the recommended scope of consumer-grade router products.   - セクション 2 では、消費者向けルータ製品の推奨範囲について述べる。 
• Section 3 concludes the document.  - セクション 3 は本文書を締めくくる。

 

[1] These standards primarily focused on technical capabilities for router devices. The Broadband Forum (BBF) TR-124 Issue 8 standard includes requirements outside of the purview of cybersecurity, while the other three standards focused exclusively on cybersecurity requirements. All cybersecurity requirements were examined to create the consumer-grade router profile. Non-cybersecurity requirements from the BBF standard were not analyzed as part of the profiling process.  [1] これらの標準規格は、主にルータ機器の技術的な機能に焦点を当てている。ブロードバンド・フォーラム(BBF)の TR-124 Issue 8 標準は、サイバーセキュリティの範囲外の要件を含むが、他の 3 つの標準は、サイバーセキュリティ要件のみに焦点を当てた。すべてのサイバーセキュリティ要件は、消費者向けルータプロファイルを作成するために検討された。BBF 規格のサイバーセキュリティ以外の要件は、プロファイル作成プロセスの一環として分析されなかった。
[2] The overlap between standards in the graphic is not necessarily equal or proportional to the true overlap (i.e., the number of requirements between each standard that are the same or otherwise redundant).   [2] 図中の規格間の重複は、必ずしも真の重複(すなわち、各規格間で同じ要件またはその他の冗長な要件の数)と等しい、または比例するわけではない。 

 

 


 

● まるちゃんの情報セキュリティ気まぐれ日記

米国...

・2024.04.05 米国 意見募集 NIST CSWP 33(初公開ドラフト) 製品開発サイバーセキュリティハンドブック: IoT製品製造者のための概念と考慮事項

・2024.03.20 米国 連邦通信委員会 (FCC) がIoTサイバーセキュリティ表示プログラム(サイバートラストマーク)の規則を採択 (2024.03.14)

・2023.07.19 米国 消費者向けIoT製品のセキュリティ認証制度、サイバートラスト・マーク (U.S. Cyber Trust Mark) を発表

・2022.09.24 NIST NISTIR 8425 消費者向けIoT製品のIoTコアベースラインのプロファイル、NISTIR 8431 「NIST基礎の上に築く:IoTセキュリティの次のステップ」ワークショップ概要報告書

・2022.06.19 NISTIR 8425 (ドラフト) 消費者向けIoT製品のIoTコアベースラインのプロファイル

・2022.02.07 NIST ホワイトペーパー :消費者向けソフトウェアのサイバーセキュリティラベルの推奨規準

・2022.02.06 NIST ホワイトペーパー :消費者向けIoT製品のサイバーセキュリティラベルの推奨規準

・2021.11.04 NIST 消費者向けソフトウェアのサイバーセキュリティに関するラベリングについての意見募集

・2021.09.02 NIST ホワイトペーパー(ドラフト):消費者向けIoTデバイスのベースライン・セキュリティ基準

・2021.08.29 NISTIR 8259B IoT非技術的支援能力コアベースライン

・2021.05.13 米国 国家のサイバーセキュリティ向上に関する大統領令

・2020.12.17 NIST SP 800-213 (Draft) 連邦政府向け「 IoTデバイスサイバーセキュリティ要件の確立」、NISTIR 8259B、8259C、8259D

・2020.05.30 NIST IoT機器製造者向けセキュリティの実践資料 NISTIR 8259 Foundational Cybersecurity Activities for IoT Device Manufacturers, NISTIR 8259A IoT Device Cybersecurity Capability Core Baseline

・2020.02.06 NISTがIoT機器製造者向けセキュリティの実践資料のドラフト(Ver.2)を公開していますね。。。

 

EU

・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.03.21 ENISA サイバーセキュリティ認証のウェブページを開設

・2023.03.01 IPA 欧州規格 ETSI EN 303 645 V2.1.1 (2020-06)の翻訳の公開

・2023.02.02 ドイツ スペースネットAG社のサービスにITセキュリティラベルを渡す

・2022.12.15 ドイツ フランス IT製品のセキュリティ認証に関する共同文書を発行 (固定時間制認証制度)

・2022.10.31 ドイツ シンガポール 消費者向けIoT製品のサイバーセキュリティ・ラベルの相互承認 (2022.10.20)

・2022.05.09 ドイツ ITセキュリティラベル for 消費者向けスマート製品

・2022.02.03 ドイツ BSI Mail.deの電子メールサービスにITセキュリティラベルを付与

・2021.07.18 独国 BSIがITセキュリティラベルについてのウェブページを公開していますね。。。

 

英国

・2023.05.04 英国 インターネットに接続するすべての消費者向け製品に適用される最低セキュリティ基準制度が1年後にはじまりますよ〜 (2023.04.29)

・2023.04.25 Five Eyesの国々が安全なスマートシティを作るための共同ガイダンスを発表 (2023.04.20)

・2022.12.11 英国 製品セキュリティおよび電気通信インフラストラクチャ(PSTI)法成立 at 2022.12.06

・2022.01.27 英国 スマートデバイスのサイバーセキュリティ新法に一歩近づくと発表

・2021.12.09 英国 製品セキュリティおよび電気通信インフラストラクチャ(PSTI)法案 at 2021.11.24

 

中国

・2022.02.15 中国 国家サイバースペース管理局 専門家の解説 ネットワーク重要機器のセキュリティ認証とセキュリティテストによるネットワークセキュリティの基本ディスクの維持

 

日本

・2024.03.17 経済産業省 IoT製品に対するセキュリティ適合性評価制度構築に向けた検討会の最終とりまとめを公表し、制度構築方針案に対する意見公募を開始

・2023.05.17 経済産業省 産業サイバーセキュリティ研究会 WG3 IoT製品に対するセキュリティ適合性評価制度構築に向けた検討会 中間とりまとめ

・2022.11.04 経済産業省 第1回 産業サイバーセキュリティ研究会 ワーキンググループ3 IoT製品に対するセキュリティ適合性評価制度構築に向けた検討会

 

| | Comments (0)

より以前の記事一覧