米国 NIST SP 800-126 第4版（初期公開ドラフト）セキュリティコンテンツ自動化プロトコル（SCAP）の技術仕様：SCAPバージョン1.4、SP 800-126A 第4版（初期公開ドラフト）SCAP 1.4 コンポーネント仕様バージョン更新：NIST SP 800-126第4版の附属書

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

米国のNISTが、

• SP 800-126 第4版（初期公開ドラフト）セキュリティコンテンツ自動化プロトコル（SCAP）の技術仕様：SCAPバージョン1.4
• SP 800-126A 第4版（初期公開ドラフト）SCAP 1.4 コンポーネント仕様バージョン更新：NIST SP 800-126第4版の附属書

を公表し、意見募集をしていますね...

SCAPが日本でももっと広がればよいですね...　JVNが利用されていますが、自動化処理まではいっていない..IPAでは2015年につくった説明のウェブページがあります...2010年にIPAの研究員として寺田さんが作成した資料もありますね...

人間が設定をしようとすると、ミスが生じるし、時間もかかる、そしてコストも...リソース的にできないということにして、やらない...

Machine Readableにして自動化...これは重要だと思います...

SCAPは「標準化」と「機械可読性」を通じて脆弱性の発見やシステムの設定チェック、セキュリティの遵守を自動化することを目指していますね...

コンポーネントとしては....

カテゴリー	仕様名	概要	正式名称	役割と具体的な内容
言語	XCCDF	チェックリストを記述（XML）	Extensible Configuration Checklist Description Format	チェックリスト（ベンチマーク）の記述フォーマット。CISベンチマークなどのセキュリティチェックリストを、機械可読な形式で定義。「何を」検査するか（ルール）、結果をどう評価するか（採点）、修復手順などを記述。
	OVAL	脆弱性やセキュリティ設定のチェック	Open Vulnerability and Assessment Language	具体的なチェックロジックの記述言語。XCCDFの各ルールについて、「どのように」システムをチェックするか（例：特定のレジストリキーの値、ファイルのハッシュ、ソフトウェアバージョン）をXMLで詳細に定義。評価結果は「True（問題あり）」「False（問題なし）」「Error」など。
	OCIL	人間による確認項目の質問形式	Open Checklist Interactive Language	対話型の質問調査を記述する言語。ユーザーへの質問（例：「ファイアウォールは有効か？」）と想定回答を定義し、手動確認を標準化する。
識別子	CPE	製品の識別	Common Platform Enumeration	ハードウェア、OS、アプリケーション等の製品に一意の名称を付与する命名体系。評価対象を一意に正確に特定する。
	CVE	脆弱性の識別	Common Vulnerabilities and Exposures	公開されたソフトウェア脆弱性に一意のID（例：CVE-2021-44228）を付与する共通リスト。SCAPツールはこのIDを参照して、システムに該当脆弱性が存在するかチェックする。
	CCE	セキュリティ設定の識別	Common Configuration Enumeration	セキュリティ設定の推奨事項や問題点に一意のIDを付与するリスト。例：「パスワードの最小長」という設定項目をCCE-12345と特定し、ベンチマーク間で一貫した議論を可能にする。
評価尺度	CVSS	脆弱性の深刻度	Common Vulnerability Scoring System	脆弱性の深刻度を0.0〜10.0のスコアで定量化する共通基準。攻撃の難易度、影響範囲など複数の指標から計算され、リスク対応の優先順位付けに活用する。
報告形式	ARF	評価結果の出力	Asset Reporting Format	評価結果を標準的なXML形式で出力するためのスキーマ。資産情報、チェック内容、結果を全て含み、異なるツール間でレポートを交換・集約することを可能にする。

• 定義（入力）: XCCDFがチェックリスト全体を、OVALが具体的な検査手順を定義し、CVE, CCE, CPEで用語を統一する。

• 実行（プロセス）: SCAPツールがOVALに従ってシステムをスキャンし、セキュリティ状態を判定する。

• 報告（出力）: 結果をCVSSで格付けし、ARF形式でまとめて報告する。

こんなかんじでしょうかね...

● NIST - ITL

・2025.12.11 NIST SP 800-126 Rev. 4 (Initial Public Draft) Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.4

NIST SP 800-126 Rev. 4 (Initial Public Draft) Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.4	NIST SP 800-126 第4版（初期公開ドラフト）セキュリティコンテンツ自動化プロトコル（SCAP）の技術仕様：SCAPバージョン1.4
Announcement	発表
About SCAP	SCAPについて
The Security Content Automation Protocol (SCAP) is a suite of interoperable specifications for the standardized expression, exchange, and processing of security configuration and vulnerability information. SCAP enables consistent automation and reporting across products and environments by defining machine-readable content and associated processing requirements.	セキュリティコンテンツ自動化プロトコル（SCAP）は、セキュリティ構成および脆弱性情報の標準化された表現、交換、処理のための相互運用可能な仕様群である。SCAPは、機械可読コンテンツと関連する処理要件を定義することで、製品や環境を跨いだ一貫した自動化と報告を可能にする。
About the Publications	出版物について
SP 800-126r4 — Updates the SCAP technical specification to focus on SCAP Version 1.4 by removing backward compatibility requirements for earlier SCAP versions, revising digital signature requirements, and eliminating unused requirements. This revision also updates requirements regarding  Open Vulnerability and Assessment Language (OVAL) references and related component specification (i.e., redirecting OVAL references to the OVAL Community GitHub).  Hyperlinks and schema references are also updated to the current SCAP 1.4 resources.	SP 800-126r4 — SCAP技術仕様を更新し、SCAPバージョン1.4に焦点を当てる。具体的には、以前のSCAPバージョンに対する下位互換性要件を削除し、デジタル署名要件を改訂し、未使用の要件を排除する。本改訂では、Open Vulnerability and Assessment Language（OVAL）参照および関連コンポーネント仕様に関する要件も更新する（例：OVAL参照をOVALコミュニティGitHubへリダイレクト）。ハイパーリンクとスキーマ参照も現行のSCAP 1.4リソースへ更新する。
SP 800-126Ar4 (updated annex) — Aligns the annex with SCAP Version 1.4.  Informative notes and change logs are refreshed, and the document structure and normative references are revised to conform to the latest NIST templates and editorial policies.	SP 800-126Ar4（更新された附属書）— 附属書をSCAPバージョン1.4に整合させる。 参考情報と変更履歴を更新し、文書構造と規範的参照を最新のNISTテンプレートおよび編集方針に準拠するよう改訂した。
Abstract	概要
The Security Content Automation Protocol (SCAP) is a suite of specifications that standardize the format and nomenclature by which software flaw and security configuration information is communicated, both to machines and humans. This publication, along with its annex (NIST Special Publication 800-126Ar1) and a set of schemas, collectively define the technical composition of SCAP version 1.4 in terms of its component specifications, their interrelationships and interoperation, and the requirements for SCAP content.	セキュリティコンテンツ自動化プロトコル（SCAP）は、ソフトウェアの欠陥やセキュリティ設定情報を機械と人間の双方に伝達するための形式および命名規則を標準化する一連の仕様である。本出版物、その附属書（NIST 特別刊行物800-126Ar1）、および一連のスキーマは、SCAPバージョン1.4の技術的構成を、その技術仕様、相互関係と相互運用性、ならびにSCAPコンテンツの要件に関して、総合的に定義するものである。

・[PDF] SP.800-126r4.ipd

エグゼクティブサマリー...

Executive Summary	エグゼクティブサマリー
The Security Content Automation Protocol (SCAP) is a suite of specifications that standardize the format and nomenclature by which security configuration information is communicated to both machines and humans.  SCAP is a multi-purpose framework of specifications that support automated configuration, vulnerability and patch checking, technical and managerial control compliance activities, and security measurement. Goals for the development of SCAP include standardizing system security management, promoting the interoperability of security products, and fostering the use of standard expressions of security content.	セキュリティコンテンツ自動化プロトコル（SCAP）は、セキュリティ設定情報を機械と人間の双方に伝達するための形式と命名規則を標準化する一連の仕様である。SCAPは、自動化された設定、脆弱性およびパッチのチェック、技術的・管理的制御のコンプライアンス活動、セキュリティ測定を支援する多目的仕様枠組みである。SCAP開発の目標には、システムセキュリティ管理の標準化、セキュリティ製品の相互運用性の促進、セキュリティコンテンツの標準表現の使用促進が含まれる。
Security configuration in SCAP format is curated and managed by the NIST National Checklist Program (NCP), which is described in NIST Special Publication (SP) 800-70r5 (Revision 5). This document, its annex [SP800-126Ar1], and a set of schemas collectively define the technical composition of SCAP version 1.4 in terms of its component specifications and requirements. The technical specification for SCAP describes the conventions for ensuring the consistent and accurate exchange of SCAP-conformant content and the ability to reliably use the content with SCAP-conformant products.	SCAP形式のセキュリティ構成は、NIST 特別刊行物（SP）800-70r5（改訂5）で説明されているNIST国家チェックリストプログラム（NCP）によって管理・運営されている。本文書、その附属書［SP800-126Ar1］、および一連のスキーマは、構成要素の仕様と要件の観点から、SCAPバージョン1.4の技術的構成を包括的に定義する。SCAPの技術仕様は、SCAP準拠コンテンツの一貫性と正確な交換を確保する規約、およびSCAP準拠製品でコンテンツを確実に利用する能力を規定する。
Organizations that develop SCAP 1.4-based content or products should adhere to the following recommendations:	SCAP 1.4ベースのコンテンツまたは製品を開発する組織は、以下の推奨事項に従うべきである：
• Follow the requirements listed in this document, its annex, and the associated component specifications and set of schemas.	• 本文書、その附属書、関連する構成要素仕様およびスキーマ群に記載された要件に従うこと。
Organizations should ensure that their implementation and use of SCAP 1.4 complies with the requirements detailed in each component specification, this document, its annex, and the set of schemas.	組織は、SCAP 1.4の実装および使用が、各コンポーネント仕様、本文書、その附属書、およびスキーマセットに詳述された要件に準拠していることを保証すべきである。
If requirements conflict between component specifications, this document will provide clarification. If a component specification conflicts with this document, the requirements in this document take precedence. If a component specification or this document conflicts with the annex, the requirements in the annex take precedence. If a specification and a schema conflict, the requirements in the specification take precedence.	コンポーネント仕様間で要件が矛盾する場合、本文書が明確化を提供する。コンポーネント仕様が本文書と矛盾する場合、本文書の要件が優先される。コンポーネント仕様または本文書が付属文書と矛盾する場合、付属文書の要件が優先される。仕様とスキーマが矛盾する場合、仕様の要件が優先される。
• When creating SCAP content, adhere to the conventions specified in this document and its annex.	• SCAPコンテンツを作成する際は、本文書およびその附属書で規定された規約に従うこと。
Security products and checklist authors assemble content from SCAP data repositories to create SCAP-conformant security guidance.  Organizations that produce SCAP content to be shared between tools should adhere to the conventions described in this specification to ensure the highest degree of interoperability.	セキュリティ製品およびチェックリスト作成者は、SCAPデータリポジトリからコンテンツを組み立ててSCAP準拠のセキュリティガイダンスを作成する。ツール間で共有されるSCAPコンテンツを生産する組織は、最高度の相互運用性を確保するため、本仕様で記述された規約に従うべきである。

目次...

Executive Summary	エグゼクティブサマリー
1. Introduction	1. 序論
1.1. Purpose and Scope	1.1. 目的と範囲
1.2. Audience	1.2. 対象読者
1.3. Document Structure	1.3. 文書の構成
1.4. Document Conventions	1.4. 文書における表記規則
2. SCAP 1.4 Definition	2. SCAP 1.4 定義
2.1. Product Conformance	2.1. 製品の適合性
2.2. Source Content Conformance	2.2. ソースコンテンツの適合性
3. SCAP Content Requirements and Recommendations	3. SCAP コンテンツの要件と推奨事項
3.1. SCAP Source Data Stream	3.1. SCAP ソースデータストリーム
3.1.1. Source Data Stream Data Model	3.1.1. ソースデータストリームのデータモデル
3.1.2. Source Data Stream Collection Validation	3.1.2. ソースデータストリームの収集妥当性確認
3.1.2.1. Informative Notes	3.1.2.1. 参考情報
3.1.3. Globally Unique Identifiers	3.1.3. グローバル固有識別子
3.2. Extensible Configuration Checklist Description Format (XCCDF)	3.2. 拡張可能構成チェックリスト記述形式（XCCDF）
3.2.1. General	3.2.1. 概要
3.2.2. The <xccdf:Benchmark> Element	3.2.2. <xccdf:Benchmark>要素
3.2.3. The <xccdf:Profile> Element	3.2.3. <xccdf:Profile>要素
3.2.4. The <xccdf:Rule> Element	3.2.4. <xccdf:Rule>要素
3.2.4.1. The <xccdf:ident> Element	3.2.4.1. <xccdf:ident>要素
3.2.4.2. The <xccdf check> Element	3.2.4.2. <xccdf check>要素
3.2.4.3. Use of a Patches Up-To-Date Rule	3.2.4.3. パッチ適用状況ルール（Patches Up-To-Date Rule）の使用
3.2.4.4. CVSS and CCSS Scores	3.2.4.4. CVSS および CCSS スコア
3.2.5. The <xccdf: Value> Element	3.2.5. <xccdf:Value> 要素
3.2.6. The <xccaf:Group> Element	3.2.6. <xccaf:Group> 要素
3.3. Open Vulnerability and Assessment Language (OVAL)	3.3. オープン脆弱性評価言語 (OVAL)
3.4. Open Checklist Interactive Language (OCIL)	3.4. オープンチェックリスト対話言語 (OCIL)
3.5. Common Platform Enumeration (CPE)	3.5. 共通プラットフォーム一覧表 (CPE)
3.6. Common Configuration Enumeration (CCE)	3.6. 共通構成列挙 (CCE)
3.7. Common Vulnerabilities and Exposures (CVE)	3.7. 共通脆弱性およびエクスポージャー (CVE)
3.8. Common Vulnerability Scoring System (CVSS)	3.8. 共通脆弱性評価システム (CVSS)
3.9. Common Configuration Scoring System (CCSS)	3.9. 共通構成評価システム (CCSS)
3.10. XML Digital Signature	3.10. XML デジタル署名
3.10.1. Signature Location	3.10.1. 署名の位置
3.10.2. Signature Representation	3.10.2. 署名の表現
3.10.3. Signature Requirements	3.10.3. 署名の要件
3.10.4. Key Information	3.10.4. 鍵情報
4. SCAP Content Processing Requirements and Recommendations	4. SCAP コンテンツ処理の要件と推奨事項
4.1. Legacy Support	4.1. レガシーサポート
4.2. Source Data Streams	4.2. ソースデータストリーム
4.3. XCCDF Processing	4.3. XCCDF 処理
4.3.1. CPE Applicability Processing	4.3.1. CPE 適用性処理
4.3.2. Checking System Usage	4.3.2. システム使用状況の確認
4.4. SCAP Result Data Streams	4.4. SCAP 結果データストリーム
4.4.1. The Component Reports	4.4.1 コンポーネントレポート
4.4.2. The Target Identification	4.4.2 ターゲット識別
4.4.3. The Source Data Stream	4.4.3 ソースデータストリーム
4.4.4. The Relationships	4.4.4 関係性
4.5. XCCDF Results	4.5 XCCDF結果
4.5.1. Assigning Identifiers to Rule Results	4.5.1 ルール結果への識別子割り当て
4.5.2. Mapping OVAL Results to XCCDF Results	4.5.2 OVAL結果からXCCDF結果へのマッピング
4.6. OVAL Results	4.6 OVAL結果
4.7. OCIL Results	4.7 OCIL結果
4.8. Result Data Stream Signing	4.8. 結果データストリームの署名
4.8.1. Signature Location	4.8.1. 署名の位置
4.8.2. Signature Representation	4.8.2. 署名の表現
4.8.3. Signature Requirements	4.8.3. 署名の要件
4.8.4. Key information	4.8.4. 鍵情報
4.8.5. Countersigning	4.8.5. 共同署名
5. Source Data Stream Content Requirements for Use Cases	5. ユースケースにおけるソースデータストリームの内容要件
5.1. Compliance Checking	5.1. 適合性チェック
5.2. Vulnerability Scanning	5.2. 脆弱性スキャン
5.3. Inventory Scanning	5.3. インベントリスキャン
Appendix A. Security Considerations	附属書 A. セキュリティに関する考慮事項
Appendix B. List of Symbols, Abbreviations, and Acronyms	附属書 B. 記号、略語、頭字語の一覧
Appendix C. Glossary	附属書 C. 用語集
Appendix D. Normative References	附属書 D. 規範的参照
Appendix E. Change Log	附属書 E. 変更履歴

---

・2025.12.11 NIST SP 800-126A Rev. 4 (Initial Public Draft) SCAP 1.4 Component Specification Version Updates: An Annex to NIST Special Publication 800-126 Revision 4

NIST SP 800-126A Rev. 4 (Initial Public Draft) SCAP 1.4 Component Specification Version Updates: An Annex to NIST Special Publication 800-126 Revision 4	NIST SP 800-126A 第4版（初期公開ドラフト）SCAP 1.4 コンポーネント仕様バージョン更新：NIST SP 800-126第4版の附属書
Abstract	概要
The Security Content Automation Protocol (SCAP) is a multi-purpose framework of component specifications that support automated configuration, vulnerability, patch checking, security measurement, and technical control compliance activities. The SCAP version 1.4 specification is defined by the combination of NIST SP 800-126r4, a set of schemas, and this document. This document allows the use of particular minor version updates to SCAP 1.4 component specifications and particular Open Vulnerability and Assessment Language (OVAL) schema versions to provide additional functionality for SCAP 1.4 without causing any loss of existing functionality.	セキュリティコンテンツ自動化プロトコル（SCAP）は、自動化された構成、脆弱性、パッチチェック、セキュリティ測定、技術的制御コンプライアンス活動を支援するコンポーネント仕様の多目的枠組みである。SCAPバージョン1.4仕様は、NIST SP 800-126r4、一連のスキーマ、および本文書の組み合わせによって定義される。本文書は、SCAP 1.4コンポーネント仕様の特定のマイナーバージョン更新および特定のOpen Vulnerability and Assessment Language（OVAL）スキーマバージョンの使用を許可し、既存の機能を損なうことなくSCAP 1.4に追加機能を提供する。

・[PDF] NIST.SP.800-126Ar4.ipd

目次...

1. Introduction	1. 序論
1.1. Purpose and Scope	1.1. 目的と範囲
1.2. Document Structure	1.2. 文書の構成
2. Minor Version Updates in SCAP 1.4-Component Specifications	2. SCAP 1.4 コンポーネント仕様におけるマイナーバージョン更新
2.1. Criteria for Potential Inclusion	2.1. 潜在的な包含規準
2.2. Approved Minor Version Updates and SCAP 1.4 Requirements	2.2. 承認済みマイナーバージョン更新と SCAP 1.4 要件
2.3. XML Schema and Schematron Schema Locations	2.3. XML スキーマと Schematron スキーマの場所
3. Document Management	3. 文書管理
3.1. Composition	3.1. 構成
3.2. Rationale	3.2. 根拠
3.3. Update Cadence	3.3. 更新頻度
3.4. Conformance and Assessment	3.4. 適合性評価
Appendix A. List of Symbols, Abbreviations, and Acronyms	附属書 A. 記号、略語、頭字語一覧
Appendix B. Glossary	附属書 B. 用語集
Appendix C. Change Log	附属書 C. 変更履歴

---

NISTの文書等はここから辿れます...

・Security Content Automation Protocol SCAP

関連文書

・Publications

---

● IPA 

・2015.07.22 セキュリティ設定共通化手順SCAP概説

---

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

・2023.07.16 NIST SP 800-219r1 macOSセキュリティ・コンプライアンス・プロジェクト（mSCP）による自動化された安全な構成のガイダンス

・2011.07.15 NIST パブコメ Trust Model for Security Automation Data 1.0 (TMSAD)

・2008.02.13 IPA 脆弱性情報共有フレームワークに関する調査報告書　～中小規模組織における脆弱性対策促進への各国の取り組み～

ASKUL ランサムウェア攻撃の影響調査結果および安全性強化に向けた取り組みの報告 (2025.12.12)

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

アスクルがランサムウェア攻撃を受け出荷等に影響がでましたが、12日に攻撃の影響調査結果と安全性強化に向けた取り組みについて公表していますね...その中で、攻撃手法の分析、初動対応、原因分析と再発防止策、システム復旧と安全性確保、今後のセキュリティ強化に向けたロードマップ（短期・中期・長期）にわけて説明していて、他社の参考に資する部分も多いのではないかと思い紹介です...

環境については、新しい環境を作り直したみたいですね...

これからはNISTのセキュリティフレームワークに基づくセキュリティ強化をするようですね...

原因分析の点では、

（１）不正アクセス；例外的に多要素認証を適用していなかった業務委託先に対して付与していた管理者アカウントのIDとパスワードが漏洩し不正利用された可能性が高い

（２）侵入検知の遅れ：侵害が発生したデータセンターではサーバにEDRが未導入、24時間監視も未実施で即時検知ができなかった

（３）復旧の長期化：オンラインバックアップで一部バックアップも暗号化された。一部OSバージョンアップ作業に時間を要した

攻撃されたのが委託先のアカウント経由、そして業務のサプライチェーンに影響を与えたということでサプライチェーン・セキュリティ強化の重要性が確認された感じですかね...

そして、認証については多要素認証は必要...

資産管理、脆弱性管理は即時に把握できないといけない...

適時監視も重要...

オフラインバックアップは必須...

● ASKUL

・2025.12.12 ランサムウェア攻撃の影響調査結果および安全性強化に向けた取り組みのご報告（ランサムウェア攻撃によるシステム障害関連・第 13 報） (downloaded)

---

・2025.12.12 ランサムウェア攻撃の影響調査結果および安全性強化に向けた取り組みのご報告（ランサムウェア攻撃によるシステム障害関連・第 13 報） (downloaded)

・2025.12.03 サービスの復旧状況について（ランサムウェア攻撃によるシステム障害関連・第 12 報） (downloaded)

・2025.12.01 （適時）2026年5月期第2四半期決算発表の延期に関するお知らせ (downloaded)

・2025.11.28 サービスの復旧状況について（ランサムウェア攻撃によるシステム障害関連・第 11 報） (downloaded)

・2025.11.19 サービスの復旧状況について（ランサムウェア攻撃によるシステム障害関連・第 10 報 (downloaded)

・2025.11.14 ３PL 事業に関する情報流出の可能性について（ランサムウェア攻撃によるシステム障害関連・第９報） (downloaded)

・2025.11.12 サービスの復旧状況について（ランサムウェア攻撃によるシステム障害関連・第８報）  (downloaded)

・2025.11.11 情報流出に関するお知らせとお詫び（ランサムウェア攻撃によるシステム障害関連・第７報）  (downloaded)

・2025.11.06 サービスの復旧状況について（ランサムウェア攻撃によるシステム障害関連・第６報）  (downloaded)

・2025.10.31 ランサムウェア攻撃による情報流出に関するお詫びとお知らせ（ランサムウェア攻撃によるシステム障害関連・第 5 報） (downloaded)

・2025.10.31 一部報道について（ランサムウェア攻撃によるシステム障害関連・第 4 報） (downloaded)

・2025.10.29 一部商品の出荷トライアル運用の開始について（ランサムウェア感染によるシステム障害関連・第３報） (downloaded)

・2025.10.29 （適時）2026年5月期10月度月次業績のお知らせ (downloaded)

・2025.10.28 （適時）2026年5月期10月度月次業績につきまして (downloaded)

・2025.10.22 ランサムウェア感染によるシステム障害について（第２報） (downloaded)

・2025.10.20 （適時）ランサムウェア感染によるシステム障害発生について (downloaded)

---

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

・2025.11.30 アサヒホールディングス サイバー攻撃によるシステム障害発生についての記者会見他 (2025.11.27)

米国 NIST SP 800-70 第5版 (初期公開ドラフト) IT製品向け国家チェックリストプログラム：チェックリスト利用者および開発者向けガイドライン

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

NISTがSP 800-70 第5版 (初期公開ドラフト) IT製品向け国家チェックリストプログラム：チェックリスト利用者および開発者向けガイドラインを公開し、意見募集をしていますね...

米国だからできるのかもしれませんが...

● NIST - ITl

・2025.12.05 NIST SP 800-70 Rev. 5 (Initial Public Draft) National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

NIST SP 800-70 Rev. 5 (Initial Public Draft) National Checklist Program for IT Products: Guidelines for Checklist Users and Developers	NIST SP 800-70 第5版 (初期公開ドラフト) IT製品向け国家チェックリストプログラム：チェックリスト利用者および開発者向けガイドライン
Announcement	発表
NIST established the National Checklist Program (NCP) to facilitate the generation of security checklists from authoritative sources, centralize the location of checklists, and make checklists broadly accessible. SP 800-70r5 ipd describes the uses, benefits, and management of checklists and checklist control catalogs, as well as the policies, procedures, and general requirements for participation in the NCP.	NISTは国家チェックリストプログラム（NCP）を設立している。これは権威ある情報源からのセキュリティチェックリスト作成を促進し、チェックリストの場所を一元化し、チェックリストを広く利用可能にするためである。SP 800-70r5 ipd は、チェックリスト及びチェックリスト管理カタログの用途、利点、管理方法、並びに NCP への参加に関する方針、手順、及び一般的な要件を説明する。
Why Security Configuration Checklists Matter	セキュリティ構成チェックリストの重要性
A security configuration checklist is a document or technical content that contains instructions or procedures for securely configuring an IT product to match an operational environment’s risk tolerance, verifying that the product has been configured properly, and/or identifying unauthorized changes to the product. Using these checklists can minimize the attack surface, reduce vulnerabilities, lessen the impacts of successful attacks, and identify changes that might otherwise go undetected.	セキュリティ構成チェックリストとは、運用環境のリスク許容度に合わせてIT製品を安全に構成するための手順や指示、製品の適切な構成確認、および製品への不正変更の特定を含む文書または技術的コンテンツである。これらのチェックリストを使用することで、攻撃対象領域を最小化し、脆弱性を減らし、攻撃成功時の影響を軽減し、検出されにくい変更を識別できる。
What’s New in Revision 5?	改訂版5の新機能
This revision introduces significant updates to improve usability, automation, and alignment with modern cybersecurity practices.	本改訂版では、使いやすさ、自動化、現代的なサイバーセキュリティ慣行との整合性を向上させるための大幅な更新を導入した。
Key Highlights	主なハイライト
Traceability and Compliance: Enhanced mapping concepts between checklist settings, NIST Cybersecurity Framework (CSF) 2.0 outcomes, SP 800-53 controls, and Common Configuration Enumeration (CCE) identifiers for evidence-ready automation and reporting	トレーサビリティとコンプライアンス：チェックリスト設定、NISTサイバーセキュリティフレームワーク（CSF）2.0の成果、SP 800-53の制御、共通構成列挙（CCE）識別子間のマッピング概念を強化し、証拠対応型の自動化と報告を実現
Expanded Coverage: Guidance that includes cloud platforms, IoT, and AI systems and reflects the latest NIST research and federal requirements	適用範囲の拡大：クラウドプラットフォーム、IoT、AIシステムを含むガイダンスを拡充。最新のNIST研究及び連邦政府要件を反映
Modernized Automation: Explicit support for a wide range of automated checklist formats	自動化の近代化：多様な自動化チェックリスト形式への明示的サポート
Control Catalog Approach: Encourages developers to use catalogs of controls for rapid, consistent checklist generation and easier tailoring to different risk postures	コントロールカタログ方式：開発者が制御カタログを活用し、迅速かつ一貫性のあるチェックリスト生成と、異なるリスク態勢への容易な適応を促進
Operational Environment Tailoring: Detailed recommendations for customizing checklists to fit stand-alone, managed (enterprise), specialized security-limited functionality (SSLF), and legacy environments	運用（OT）環境への適合：スタンドアロン環境、管理対象（エンタープライズ）環境、特殊セキュリティ限定機能（SSLF）環境、レガシー環境に合わせてチェックリストをカスタマイズするための詳細な推奨事項
Checklist Life Cycle: Clear procedures for checklist development, testing, documentation, submission, public review, maintenance, and archival	チェックリストのライフサイクル：チェックリストの開発、テスト、文書化、提出、公開レビュー、保守、アーカイブに関する明確な手順
Intended Audience	対象読者
This document is intended for users and developers of security configuration.	本ドキュメントは、セキュリティ構成のユーザーおよび開発者を対象とする。
For checklist users, this document makes recommendations on how they should select checklists from the NIST National Checklist Repository, evaluate and test checklists, and apply them to IT products.	チェックリストユーザーに対しては、NIST国家チェックリストリポジトリからのチェックリスト選定方法、チェックリストの評価・テスト方法、IT製品への適用方法に関する推奨事項を示す。
For checklist developers, this document sets forth the policies, procedures, and general requirements for participation in the NCP.	チェックリスト開発者に対しては、NCP（国家チェックリストプログラム）への参加に関する方針、手順、および一般的な要件を定める。
Abstract	概要
A security configuration checklist is a document or technical content that contains instructions or procedures for securely configuring an IT product to match an operational environment’s risk tolerance, verifying that the product has been configured properly, and/or identifying unauthorized changes to the product. Using these checklists can minimize the attack surface, reduce vulnerabilities, lessen the impact of successful attacks, and identify changes that might otherwise go undetected. NIST established the National Checklist Program (NCP) to facilitate the generation of security checklists from authoritative sources, centralize the location of checklists, and make checklists broadly accessible. This publication explains how to use the NCP to find and retrieve checklists and describes the policies, procedures, and general requirements for participation in the NCP.	セキュリティ構成チェックリストとは、運用環境のリスク許容度に合わせてIT製品を安全に構成するための手順や指示、製品の適切な構成確認方法、および製品への不正変更の識別方法を記載した文書または技術的コンテンツである。これらのチェックリストを使用することで、攻撃対象領域を最小化し、脆弱性を低減し、攻撃成功時の影響を軽減し、検出されにくい変更を識別することが可能となる。NISTは、権威ある情報源からのセキュリティチェックリスト作成を促進し、チェックリストの場所を一元化し、チェックリストを広く利用可能にするため、国家チェックリストプログラム（NCP）を設立した。本出版物は、NCPを使用してチェックリストを検索・取得する方法を説明し、NCPへの参加に関する方針、手順、および一般的な要件を記述するものである。

・[PDF] NIST.SP.800-70r5.ipd

エグゼクティブサマリー...

Executive Summary	エグゼクティブサマリー
A security configuration checklist (also called a lockdown, hardening guide, or benchmark) is a series of instructions or procedures for securely configuring an IT product to a particular risk tolerance for an operational environment, verifying that the product has been configured properly, and/or identifying unauthorized changes to the product. The checklist may be for a commercial, open-source, or government-off-the-shelf (GOTS) IT product.	セキュリティ構成チェックリスト（ロックダウン、強化ガイド、ベンチマークとも呼ばれる）とは、運用環境における特定のリスク許容度に合わせてIT製品を安全に構成するための一連の指示や手順である。製品が適切に構成されていることを確認し、あるいは製品への不正な変更を識別することを目的とする。チェックリストは、商用製品、オープンソース製品、政府向け既製品（GOTS）のIT製品を対象とする場合がある。
Checklists can comprise a mix of templates, automated scripts, patch information, Extensible Markup Language (XML) files, and other procedures. Typically, checklists are created by IT vendors for their own products; however, checklists are also created by other organizations, such as academia, consortia, and government agencies. The use of well-written, standardized checklists can markedly reduce the attack surface and vulnerability exposure of IT products.	チェックリストは、テンプレート、自動化スクリプト、パッチ情報、拡張マークアップ言語（XML）ファイル、その他の手順を組み合わせて構成されることがある。通常、チェックリストはITベンダーが自社製品向けに作成するが、学術機関、コンソーシアム、政府など他の組織によって作成される場合もある。適切に作成された標準化されたチェックリストの使用は、IT製品の攻撃対象領域と脆弱性のエクスポージャーを著しく低減できる。
NIST maintains the National Checklist Repository, which is a publicly available resource of security configuration checklists for IT products. The repository is located at https://checklists.nist.gov/ and contains metadata describing each checklist. The repository links to the website where a checklist is hosted. Users can browse and search the repository to locate a particular checklist using a variety of criteria. Having a centralized checklist repository makes it easier for organizations to find current, authoritative versions of security checklists and to determine which ones best meet their needs.	NISTはIT製品向けセキュリティ構成チェックリストの公開リソースである国家チェックリスト・レポジトリを管理している。リポジトリは https://checklists.nist.gov/ に所在し、各チェックリストを記述するメタデータを含む。リポジトリはチェックリストがホストされているウェブサイトへリンクする。ユーザーは様々な規準を用いてリポジトリを閲覧・検索し、特定のチェックリストを特定できる。中央集約型のチェックリストリポジトリが存在することで、組織は最新の権威あるセキュリティチェックリストを見つけ、自社のニーズに最も適合するものを判断しやすくなる。
This document is intended for users and developers of security configuration.  For checklist users, this document makes recommendations on how they should select checklists from the NIST National Checklist Repository, evaluate and test checklists, and apply them to IT products. For checklist developers, this document sets forth the policies, procedures, and general requirements for participation in the NIST National Checklist Program (NCP).	この文書は、セキュリティ構成のユーザーおよび開発者を対象とする。チェックリスト利用者向けには、NIST国家チェックリストリポジトリからのチェックリスト選定方法、評価・テスト手法、IT製品への適用方法に関する推奨事項を示す。開発者向けには、NIST国家チェックリストプログラム（NCP）への参加に関する方針、手順、基本要件を定める。
Major recommendations made in this document for checklist users and developers include the following:	本文章がチェックリストのユーザーと開発者に対して行う主な推奨事項は以下の通りである：
• Organizations should apply checklists to operating systems and applications to reduce the number of vulnerabilities that attackers can attempt to exploit and to lessen the impact of successful attacks.	• 組織は、攻撃者が悪用を試みうる脆弱性の数を減らし、攻撃が成功した場合の影響を軽減するために、オペレーティングシステムやアプリケーションにチェックリストを適用すべきである。
• When selecting checklists, users should carefully consider each checklist’s degree of automation, source, use of standards, and other relevant characteristics.	• チェックリストを選択する際、ユーザーは各チェックリストの自動化の程度、出典、標準の使用状況、その他の関連特性を慎重に考慮すべきである。
• Checklist users should customize and test checklists before applying them to production systems.	• チェックリスト利用者は、本番システムに適用する前にチェックリストをカスタマイズしテストすべきである。
• Checklist users should consider their operational environments when selecting checklists.,.	• チェックリスト利用者は、チェックリストを選択する際に自組織の運用環境を考慮すべきである。
• Checklist creators are encouraged to adopt a “catalog of controls” approach for products to facilitate custom checklist re-use.	• チェックリスト作成者は、製品向けに「制御カタログ」アプローチを採用し、カスタムチェックリストの再利用を容易にするよう推奨される。
• NIST strongly encourages IT product vendors to develop security configuration checklists for their products and contribute them to the NIST National Checklist Repository.	• NISTは、IT製品ベンダーが自社製品向けのセキュリティ構成チェックリストを開発し、NIST国家チェックリストリポジトリへ寄稿することを強く推奨する。

目次...

Executive Summary	エグゼクティブサマリー
1. Introduction	1. 序論
1.1. Purpose and Scope	1.1. 目的と範囲
1.2. Document Organization	1.2. 文書の構成
2. NIST National Checklist Program	2. NIST国家チェックリストプログラム
2.1. Overview of the NCP	2.1. NCPの概要
2.2. Security Configuration Checklists	2.2. セキュリティ構成チェックリスト
2.3. Benefits of Using Security Checklists	2.3. セキュリティチェックリスト利用の利点
2.4. Types of Checklists Listed by NCP	2.4. NCPが列挙するチェックリストの種類
3. Operational Environments for Checklists	3. チェックリストの運用環境
3.1. Stand-Alone Environment	3.1. スタンドアローン環境
3.2. Managed Environment (Enterprise)	3.2. 管理環境（エンタープライズ）
3.3. Custom Environments	3.3. カスタム環境
3.3.1. Specialized Security-Limited Functionality Environment	3.3.1. 特殊なセキュリティ制限機能環境
3.3.2. Legacy Environment	3.3.2. レガシー環境
4. Checklist Usage	4. チェックリストの使用方法
4.1. Determining Local Requirements	4.1. ローカル要件の決定
4.2. Browsing and Retrieving Checklists	4.2. チェックリストの閲覧と取得
4.3. Reviewing, Customizing, Documenting, and Testing Checklists	4.3. チェックリストのレビュー、カスタマイズ、文書化、テスト
4.4. Applying Checklists to IT Products	4.4. IT製品へのチェックリスト適用
4.5. Providing Feedback on Checklists	4.5. チェックリストへのフィードバック提供
5. Checklist Development	5. チェックリスト開発
5.1. Developer Steps for Creating, Testing, and Submitting Checklists	5.1. チェックリスト作成、テスト、提出のための開発者手順
5.2. Initial Checklist Development	5.2. 初期チェックリスト開発
5.3. Checklist Testing	5.3. チェックリストテスト
5.4. Checklist Documented	5.4. チェックリストの文書化
5.5. Checklist Submitted to NIST	5.5. NISTへのチェックリスト提出
5.6. NIST Steps for Reviewing and Finalizing Checklists for Publication	5.6. 公開に向けたチェックリストのNISTによる審査と最終化手順
5.7. NIST Screening of the Checklist Package	5.7. チェックリストパッケージのNISTによるスクリーニング
5.8. Public Review and Feedback for the Candidate Checklist	5.8. 候補チェックリストの公開レビューとフィードバック
5.9. Final Listing on Checklist Repository	5.9. チェックリストリポジトリへの最終掲載
5.10. Checklist Maintenance and Archival	5.10. チェックリストの保守とアーカイブ
References	参考文献
Appendix A. Checklist Program Operational Procedures	附属書A. チェックリストプログラム運用手順
A.1. Overview and General Considerations	A.1. 概要と一般的な考慮事項
A.2. Checklist Submission and Screening	A.2. チェックリストの提出とスクリーニング
A.3. Candidate Checklist Public Review	A.3. 候補チェックリストの公開レビュー
A.4. Final Checklist Listing	A.4. 最終チェックリストの掲載
A.5. Final Checklist Update, Archival, and Delisting	A.5. 最終チェックリストの更新、アーカイブ、および掲載解除
A.6. Record Keeping	A.6. 記録の保管
Appendix B. Participation and Logo Usage Agreement Form	附属書B. 参加およびロゴ使用に関する合意書
Appendix C. Automating NIST CSF 2.O	附属書C. NIST CSF 2.0 の自動化
C.1. How the Path Connects Policy to Automation	C.1. パスがポリシーと自動化をどう結びつけるか
C.2. Implementation and Traceability	C.2. 実装とトレーサビリティ
C.3. Checklist Development Guidance	C.3. チェックリスト開発ガイダンス
C.4. Operational Environment Tailoring and Considerations	C.4. 運用環境の調整と考慮事項
C.5. Checklist Submission and Maintenance	C.5. チェックリストの提出と保守
C.6. Appendix References	C.6. 附属書の参考文献
Appendix D. List of Symbols, Abbreviations, and Acronyms	附属書D. 記号、略語、頭字語一覧
Appendix E. Glossary	附属書E. 用語集
Appendix F. Change Log	附属書F. 変更履歴
List of Tables	表一覧
Table 1. Checklist Description Form Fields	表 1. チェックリスト説明フォームのフィールド
List of Figures	図一覧
Fig. 1. Checklist user process overview	図 1. チェックリスト利用者プロセスの概要

国家チェックリストプログラム

・2017.02.15 National Checklist Program NCP

チェックリストのレポジトリ...

・Checklist Repository

全部で853のチェックリストがあります（2025.12.13確認時）

例えば、MacOSOS (Tahoe) 26.0.0を選んだ画面...

でマッチしたのが、

https://ncp.nist.gov/repository?product=Apple+macOS+%28Tahoe%29+26.0.0&sortBy=modifiedDate%7Cdesc

でこれをクリックすると

・2025.09.17 Tahoe Guidance Revision 1.0 Checklist Details 

ダウンロード

・・[ZIP] Download ZIP - Tahoe Guidance, Revision 1.0

ダウンロードして内容を確認してみてくださいませ。充実した内容となっております...

こんな感じでファイルが格納されています...

例えば、

SP800-53

・800-53r5_high.html (downloaded)

 

国家安全保障システム委員会 (Committee on National Security Systems; CNSS) 用のCNSSI-1253チェックリスト

・CNSSI - 1253_high.html (downloaded)

● Github

・usnistgov/macos_security

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

・2023.07.16 NIST SP 800-219r1 macOSセキュリティ・コンプライアンス・プロジェクト（mSCP）による自動化された安全な構成のガイダンス

米国 NIST SP 800-57 第6版（初期公開ドラフト）鍵管理に関する推奨事項：第1部－一般事項 (2025.12.05)

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

NISTがSP 800-57 第6版（初期公開ドラフト）鍵管理に関する推奨：第1部－一般を公表し、意見募集をしていますね...

耐量子計算機暗号移行の問題もあって話題な領域かも (^^) 

三部作の第一部です。でも、第一部だけでも200ページくらいあります...

● NIST - ITL

・2025.12.05 NIST SP 800-57 Rev. 6 (Initial Public Draft) Recommendation for Key Management: Part 1 – General

NIST SP 800-57 Rev. 6 (Initial Public Draft) Recommendation for Key Management: Part 1 – General	米国 NIST SP 800-57 第6版（初期公開ドラフト）鍵管理に関する推奨事項：第1部－一般事項
Announcement	発表
The initial draft of NIST SP 800-57 Part 1 Revision 6 is available for comment through February 5, 2026. Some of the proposed changes from Revision 5 include:	NIST SP 800-57 第1部 第6改訂版の初期ドラフトが、2026年2月5日まで意見募集のために公開されている。第5版からの主な変更点には以下が含まれる：
・Ascon, as specified in SP 800-232, and the new quantum-resistant algorithms specified in FIPS 203, 204, and 205 have been included.	・SP 800-232で規定されたAscon、およびFIPS 203、204、205で規定された新たな量子耐性アルゴリズムが追加された。
・The keys used for both key establishment and key storage are now discussed separately.	・鍵確立と鍵保存に使用される鍵について、別々に論じられるようになった。
・The security categories used in the PQC competition have been included, along with the quantum-resistant algorithms.	・量子耐性アルゴリズムと共に、PQCコンペティションで使用されたセキュリティカテゴリーが追加された。
・The time frames for algorithm approval status have been removed and replaced with references to SP 800-131A.	・アルゴリズム承認ステータスの時間枠は削除され、SP 800-131Aへの参照に置き換えられた。
・A section has been added to discuss keying material storage and mechanisms.	・鍵材料の保存とメカニズムについて論じるセクションが追加された。
See Appendix F for a more complete list of changes.	変更点のより完全なリストについては附属書Fを参照のこと。
Abstract	要約
This recommendation provides cryptographic key-management guidelines in three parts. Part 1 provides general guidelines and best practices for the management of cryptographic keying material, including definitions for the security services that may be provided when using cryptography and the algorithms and key types that may be employed, specifications for the protection that each type of key and other cryptographic information requires and methods for providing this protection, discussions about the functions involved in key management, and discussions about a variety of key-management issues to be addressed when using cryptography. Part 2 provides guidance on policy and security planning requirements for U.S. Government agencies. Part 3 provides guidelines for using the cryptographic features of current systems.	本勧告は暗号鍵管理ガイドラインを3部構成で提供する。第1部では、暗号鍵材料の管理に関する一般的なガイドラインとベストプラクティスを提供する。これには、暗号技術使用時に提供可能なセキュリティサービスの定義、採用可能なアルゴリズムと鍵の種類、各種鍵及びその他の暗号情報に必要な防御仕様とその提供方法、鍵管理に関わる機能に関する考察、暗号技術使用時に対処すべき多様な鍵管理課題に関する考察が含まれる。第2部では、米国政府機関向けのポリシー及びセキュリティ計画要件に関する指針を提供する。第3部では、現行システムの暗号機能利用に関するガイドラインを提供する。

・[PDF] NIST.SP.800-57pt1r6.ipd

エグゼクティブサマリー...

Executive Summary	エグゼクティブサマリー
Cryptography is used to secure communications over networks, to protect information stored in databases, and for many other critical applications. Cryptographic keys play an important part in the operation of cryptography. These keys are analogous to the combination of a safe. If a safe combination is known to an adversary, the strongest safe provides no security against penetration.	暗号技術は、ネットワーク上の通信の保護、データベースに保存された情報の保護、その他多くの重要な用途に使用される。暗号鍵は暗号技術の運用において重要な役割を果たす。これらの鍵は金庫の暗証番号に類似している。敵対者が金庫の暗証番号を知っている場合、最も強固な金庫であっても侵入に対する防御効果は皆無である。
The proper management of cryptographic keys is essential to the effective use of cryptography for security. Poor key management may easily compromise strong algorithms. This recommendation provides guidelines for the management of a cryptographic key throughout its life cycle, including its secure generation, storage, distribution, use, and destruction.	暗号鍵の適切な管理は、セキュリティのための暗号技術の有効な利用に不可欠である。鍵管理が不十分だと、強力なアルゴリズムも容易に破られる。本 推奨は、暗号鍵のライフサイクル全体（安全な生成、保管、配布、使用、破棄を含む）における管理ガイドラインを提供する。
Ultimately, the security of information protected by cryptography directly depends on the strength of the keys, the effectiveness of cryptographic mechanisms and protocols associated with the keys, and the protection provided to the keys. Secret and private keys need to be protected against unauthorized disclosure, and all keys need to be protected against modification.	結局のところ、暗号技術で保護される情報の安全性は、鍵の強度、鍵に関連する暗号メカニズムとプロトコルの有効性、そして鍵自体への保護に直接依存する。秘密鍵と公開鍵は不正開示から防御され、全ての鍵は改変から防御されなければならない。
Cryptographic keys are used across a broad range of systems and applications in enterprises, many of which are managed by individuals who may not have expertise in key management. Consequently, organizations must ensure that clear guidance and oversight is provided for the proper management of keys, as well as controls to ensure that the guidance is being followed and implemented.	暗号鍵はエンタープライズの幅広いシステムやアプリケーションで使用されるが、その多くは鍵管理の専門知識を持たない個人によって管理されている。したがって組織は、鍵の適切な管理に向けた明確な指針と監督を提供するとともに、その指針が遵守・実施されていることを保証する統制を確立しなければならない。
Organizations and developers are presented with many choices in their use of cryptographic mechanisms. Inappropriate choices may result in an illusion of security but with little or no real security for the protocol or application. This recommendation provides background information and establishes a framework to support appropriate decisions when selecting and using cryptographic mechanisms.	組織や開発者は暗号メカニズムの利用において多くの選択肢に直面する。不適切な選択は、プロトコルやアプリケーションに対する実質的なセキュリティがほとんど、あるいは全くないにもかかわらず、セキュリティの幻想をもたらす可能性がある。本 推奨は背景情報を提供し、暗号メカニズムの選択と利用時に適切な判断を支援する枠組みを確立する。
Cryptographic modules are used to perform cryptographic operations using these keys. This recommendation does not address the implementation details for cryptographic modules that may be used to achieve the security requirements identified herein. These details are addressed in Federal Information Processing Standards (FIPS) Publication 140 [FIPS 140-3] and its associated implementation guidance and derived test requirements, which are available at https://csrc.nist.gov/projects/cmvp.	暗号モジュールは、これらの鍵を用いて暗号操作を実行するために使用される。本 推奨は、ここで識別されたセキュリティ要件を達成するために使用される暗号モジュールの実装詳細には触れない。これらの詳細は、連邦情報処理標準（FIPS）出版物140［FIPS 140-3］および関連する実装ガイダンスと派生テスト要件で扱われており、https://csrc.nist.gov/projects/cmvp で入手可能である。
This recommendation is divided into three parts:	本推奨は三つの部分に分かれる：
• Part 1 — General contains basic key-management guidelines	• 第1部 — 基本：基本的な鍵管理ガイドラインを含む
• Part 2 — Best Practices for Key Management Organizations provides a framework and general guidance to support establishing cryptographic key management.	• 第2部 — 鍵管理組織のためのベストプラクティス：暗号鍵管理の確立を支援する枠組みと一般的な指針を提供する
• Part 3 — Application-Specific Key Management Guidance addresses the key278 management issues associated with currently available implementations that use cryptography.	• 第3部 — アプリケーション固有の鍵管理ガイダンス：現在利用可能な暗号技術を用いた実装に関連する鍵管理の問題に対処する

目次...

Executive Summary	エグゼクティブサマリー
1. Introduction	1. 序論
1.1. Purpose	1.1. 目的
1.2. Audience	1.2. 対象読者
1.3. Scope	1.3. 範囲
1.4. Preliminary Discussion of Terms	1.4. 用語の予備的考察
1.5. Content and Organization	1.5. 内容と構成
2. Security Services	2. セキュリティサービス
2.1. Confidentiality	2.1. 機密性
2.2. Data Integrity	2.2. データ完全性
2.3. Authentication	2.3. 認証
2.4. Authorization	2.4. 認可
2.5. Non-Repudiation	2.5. 否認防止
2.6. Support Services	2.6. サポートサービス
2.7. Combining Services	2.7. サービスの組み合わせ
3. Cryptographic Algorithms	3. 暗号アルゴリズム
3.1. Cryptographic Hashing Methods	3.1. 暗号ハッシュ手法
3.2. Symmetric-Key Algorithms	3.2. 対称鍵アルゴリズム
3.3. Asymmetric-Key Algorithms	3.3. 非対称鍵アルゴリズム
3.4. Random Bit Generation	3.4. 乱数生成
4. General Key-Management Guidelines	4. 鍵管理の一般ガイドライン
4.1. Key Types and Other Information	4.1. 鍵の種類とその他の情報
4.1.1. Cryptographic Keys	4.1.1. 暗号鍵
4.1.2. Other Related Information	4.1.2. その他の関連情報
4.2. Key Usage	4.2. 鍵の使用期間
4.3. Cryptoperiods	4.3. 暗号期間
4.3.1. Factors Affecting Cryptoperiods	4.3.1. 暗号期間に影響する要因
4.3.2. Consequence Factors Affecting Cryptoperiods	4.3.2. 暗号期間に影響する結果要因
4.3.3. Other Factors Affecting Cryptoperiods	4.3.3. 暗号期間に影響するその他の要因
4.3.4. Asymmetric Key Usage Periods and Cryptoperiods	4.3.4. 非対称鍵の使用期間と暗号期間
4.3.5. Symmetric Key Usage Periods and Cryptoperiods	4.3.5. 対称鍵の使用期間と暗号期間
4.3.6. Cryptoperiod Recommendations for Specific Key Types	4.3.6. 特定の鍵タイプに対する暗号期間の推奨
4.4. Assurances	4.4. 保証（アシュアランス）
4.4.1. Assurance of Integrity (Integrity Protection)	4.4.1. 完全性の保証（完全性保護）
4.4.2. Assurance of Algorithm Parameter Validity	4.4.2. アルゴリズムパラメータの有効性の保証
4.4.3. Assurance of Public-Key Validity	4.4.3. 公開鍵の有効性の保証
4.4.4. Assurance of Private-Key Possession	4.4.4. 秘密鍵の所有の保証
4.4.5. Key Confirmation	4.4.5. 鍵の確認
4.5. Compromise of Keys and Other Keying Material	4.5. 鍵及びその他の鍵材料の侵害
4.5.1. Implications	4.5.1. 影響
4.5.2. Protective Measures	4.5.2. 保護措置
4.6. Guidelines for Cryptographic Algorithm and Key-Size Selection	4.6. 暗号アルゴリズム及び鍵サイズの選定に関する指針
4.6.1. Cryptographic Algorithm Security Strengths	4.6.1. 暗号アルゴリズムのセキュリティ強度
4.6.2. Using Algorithm Suites and the Effective Security Strength	4.6.2. アルゴリズムスイートの使用と実効セキュリティ強度
4.6.3. Projected Algorithm and Security Strength Approval Status	4.6.3. 予測されるアルゴリズム及びセキュリティ強度の承認状況
4.6.4. Transitioning to New Algorithms and Key Sizes in Systems	4.6.4. システムにおける新アルゴリズムおよび鍵サイズへの移行
4.6.5. Decrease in Security Over Time	4.6.5. 時間の経過に伴うセキュリティの低下
5. Protection Requirements for Key Information	5. 鍵情報の防御要件
5.1. Protection and Assurance Requirements	5.1. 防御および保証要件
5.1.1. Summary of Protection and Assurance Requirements for Cryptographic Keys	5.1.1. 暗号鍵の防御および保証要件の概要
5.1.2. Summary of Protection Requirements for Other Related Information	5.1.2. その他の関連情報の防御要件の概要
5.2. Protection Mechanisms	5.2. 防御メカニズム
5.2.1. Protection Mechanisms for Key Information in Transit	5.2.1. 伝送中の鍵情報の防御メカニズム
5.2.2. Protection Mechanisms for Key Information in Storage	5.2.2. 保管中の鍵情報の防御メカニズム
5.2.3. Metadata for Keys	5.2.3. 鍵のメタデータ
6. Key States and Transitions	6. 鍵の状態と遷移
6.1. Pre-Activation State	6.1. 事前活性化状態
6.2. Active State	6.2. 活性化状態
6.3. Suspended State	6.3. 一時停止状態
6.4. Compromised State	6.4. 侵害状態
6.5. Destroyed State	6.5. 破棄状態
7. Key-Management Phases and Functions	7. 鍵管理のフェーズと機能
7.1. Pre-Operational Phase	7.1. 運用前フェーズ
7.1.1. Entity Registration Function	7.1.1. 事業体登録機能
7.1.2. System Initialization Function	7.1.2. システム初期化機能
7.1.3. Initialization Function	7.1.3. 初期化機能
7.1.4. Keying-Material Installation Function	7.1.4. 鍵材料インストール機能
7.1.5. Key-Establishment Function	7.1.5. 鍵確立機能
7.1.6. Key Registration Function	7.1.6. 鍵登録機能
7.2. Operational Phase	7.2. 運用フェーズ
7.2.1. Normal Operational Storage Function	7.2.1. 通常運用時保存機能
7.2.2. Continuity of Operations Function	7.2.2. 運用継続機能
7.2.3. Key Change Function	7.2.3. 鍵変更機能
7.2.4. Key Derivation Methods	7.2.4. 鍵導出方法
7.3. Post-Operational Phase	7.3. 運用終了後フェーズ
7.3.1. Key Archive and Key Recovery Functions	7.3.1. 鍵アーカイブ及び鍵復旧機能
7.3.2. Entity De-Registration Function	7.3.2. 事業体登録解除機能
7.3.3. Key De-Registration Function	7.3.3. 鍵登録解除機能
7.3.4. Key Destruction Function	7.3.4. 鍵破棄機能
7.3.5. Key Revocation Function	7.3.5. 鍵失効機能
7.4. Destroyed Phase	7.4. 破棄段階
8. Additional Considerations	8. 追加考慮事項
8.1. Access Control and Identity Authentication	8.1. アクセス管理と身元認証
8.2. Inventory Management	8.2. 在庫管理
8.2.1. Key Inventories	8.2.1. 鍵在庫
8.2.2. Certificate Inventories	8.2.2. 証明書在庫
8.3. Accountability	8.3. 説明責任
8.4. Audit	8.4. 監査
8.5. Key-Management System Survivability	8.5. 鍵管理システムの生存性
8.5.1. Backed Up and Archived Key	8.5.1. バックアップおよびアーカイブされた鍵
8.5.2. Key Recovery	8.5.2. 鍵の復旧
8.5.3. System Redundancy/Contingency Planning…	8.5.3. システムの冗長性／緊急時対応計画…
8.5.4. Compromise Recovery	8.5.4. 侵害からの復旧
References	参考文献
Appendix A. Cryptographic and Non-Cryptographic Integrity and Source Authentication Mechanisms	附属書 A. 暗号的および非暗号的完全性およびソース認証メカニズム
Appendix B. Key Recovery	附属書 B. 鍵の復旧
B.1. General Discussion	B.1. 一般的な考察
B.1.1. Recovery From Stored Keying Material	B.1.1. 保存された鍵材料からの回復
B.1.2. Recovery by Reconstruction of Keying Material	B.1.2. 鍵材料の再構築による回復
B.1.3. Conditions Under Which Keying Material Needs to be Recoverable	B.1.3. 鍵材料の回復が必要となる条件
B.1.4. Key-Recovery Systems	B.1.4. 鍵回復システム
B.1.5. Key-Recovery Policy	B.1.5. 鍵回復ポリシー
B.2. Digital Signature Key Pair	B.2. デジタル署名鍵ペア
B.2.1. Private Signature Key	B.2.1. 秘密署名鍵
B.2.2. Public Signature-Verification Key	B.2.2. 公開署名検証鍵
B.3. Authentication Keys	B.3. 認証鍵
B.3.1. Symmetric Authentication Key	B.3.1. 対称認証鍵
B.3.2. Authentication (Asymmetric) Key Pair	B.3.2. 認証（非対称）鍵ペア
B.4. Random Number Generation Key	B.4. 乱数生成鍵
B.5. Key-Derivation/Master Key	B.5. 鍵導出／マスター鍵
B.6. Key Establishment (Automated)	B.6. 鍵確立（自動化）
B.6.1. Symmetric Key-Wrapping Key	B.6.1. 対称鍵ラッピング鍵
B.6.2. Key-Transport Key Pair	B.6.2. 鍵伝送鍵ペア
B.6.3. Symmetric Key-Agreement Key	B.6.3. 対称鍵合意鍵
B.6.4. Static Key-Agreement Key Pair	B.6.4. 静的鍵合意鍵ペア
B.6.5. Ephemeral Key-Agreement Key Pair	B.6.5. 一時的鍵合意鍵ペア
B.6.6. Static Encapsulation/Decapsulation Key Pair	B.6.6. 静的カプセル化/デカプセル化鍵ペア
B.6.7. Ephemeral Encapsulation/Decapsulation Key Pair	B.6.7. 一時的なカプセル化/デカプセル化鍵ペア
B.7. Symmetric Data Encryption/Decryption Keys	B.7. 対称データ暗号化/復号化鍵
B.7.1. Encryption/Decryption of Data in Transit	B.7.1. 転送中のデータの暗号化/復号
B.7.2. Encryption/Decryption of Data at Rest	B.7.2. 保存データの暗号化/復号
B.8. Keying Material Storage	B.8. 鍵材料の保存
B.8.1. Symmetric Key Wrapping/Unwrapping Key	B.8.1. 対称鍵ラッピング/アンラッピング鍵
B.8.2. Asymmetric Key Encryption/Decryption Key Pair	B.8.2. 非対称鍵暗号化/復号化鍵ペア
B.8.3. Encapsulation/Decapsulation Key Pair	B.8.3. カプセル化/デカプセル化鍵ペア
B.9. Authorization	B.9. 認可
B.9.1. Symmetric Authorization Key	B.9.1. 対称認可鍵
B.9.2. Authorization Key Pair	B.9.2. 認可鍵ペア
B.10. Other Related Information	B.10. その他の関連情報
B.10.1. Algorithm Parameters	B.10.1. アルゴリズムパラメータ
B.10.2. Initialization Vector (IV)	B.10.2. 初期化ベクトル（IV）
B.10.3. Shared Secret	B.10.3. 共有秘密
B.10.4. Seed	B.10.4. シード
B.10.5. Other Public and Secret Information	B.10.5. その他の公開情報および秘密情報
B.10.6. Intermediate Results	B.10.6. 中間結果
B.10.7. Key-Control Information/Metadata	B.10.7. 鍵制御情報／メタデータ
B.10.8. Random Numbers	B.10.8. 乱数
B.10.9. Password	B.10.9. パスワード
B.10.10. Audit Information	B.10.10. 監査情報
Appendix C. Security Strength Categories for Post-Quantum Algorithms	附属書 C. 耐量子アルゴリズムのセキュリティ強度カテゴリー
Appendix D. List of Abbreviations and Acronyms	附属書 D. 略語および頭字語一覧
Appendix E. Glossary	附属書 E. 用語集
Appendix F. Change Log	附属書 F. 変更履歴
List of Tables	表一覧
Table 1. Suggested cryptoperiods for key types	表 1. 鍵タイプに対する推奨暗号期間
Table 2: Security Strength Categories for Post-quantum Algorithms	表 2: 耐量子アルゴリズムのセキュリティ強度カテゴリー
Table 3: Security strengths of symmetric block cipher algorithms	表 3: 対称ブロック暗号アルゴリズムのセキュリティ強度
Table 4: Security strengths of classical asymmetric-key algorithms…	表4：古典的非対称鍵アルゴリズムのセキュリティ強度…
Table 5:Security strengths of quantum-resistant asymmetric-key algorithms	表5：量子耐性非対称鍵アルゴリズムのセキュリティ強度
Table 6: Maximum security strengths for hash methods and hash-based functions	表6：ハッシュ手法およびハッシュベース機能の最大セキュリティ強度
Table 8. Protection requirements for cryptographic keys	表8．暗号鍵の防御要件
Table 9. Protection requirements for other related information	表9．その他の関連情報の防御要件
Table 10. Backup of keys	表10．鍵のバックアップ
Table 11. Backup of other related information	表11．その他の関連情報のバックアップ
Table 12. Archive of keys	表12. 鍵のアーカイブ
Table 13. Archive of other related information	表13. その他の関連情報のアーカイブ
List of Figures	図の一覧
Figure 1. Symmetric-key cryptoperiod	図1. 対称鍵暗号の期間
Figure 2. Algorithm originator-usage period example	図2. アルゴリズム作成者-使用期間の例
Figure 3. Key state and transition example	図3. 鍵の状態と遷移の例
Figure 4. Key-management phases	図4. 鍵管理のフェーズ
Figure 5. Key-management states and phases	図5. 鍵管理の状態とフェーズ
Figure 6: Example of a tree of keys in storage	図6: 保存中の鍵のツリーの例

---

暗号鍵の管理についてはIPAからも

● IPA

SP800-57の第5版をベースにしています...

・2023.08.30 暗号鍵設定ガイダンス〜暗号鍵の鍵長選択方法と運用方法〜

（これはSP800-130をベースにしています。）...

・2025.04.25 暗号鍵管理ガイドライン

IPAの翻訳も...

・SP 800-57 Part 1 Rev. 5 鍵管理における推奨事項 第一部：一般事項 Recommendation for Key Management Part 1: General

・・2021.05 [PDF] SP 800-57 Part 1 Rev. 5

・SP 800-57 Part 3 Rev. 1 鍵管理における推奨事項 第三部：アプリケーション特有の鍵管理ガイダンス Recommendation for Key Management Part 3: Application-Specific Key Management Guidance

・・2016.11 [PDF] SP 800-57 Part 3 Rev. 1

---

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

・2022.07.13 IPA 暗号鍵設定ガイダンス～暗号鍵の鍵長選択方法と運用方法～

・2020.05.08 NIST SP 800-57 Part 1 Rev. 5 Recommendation for Key Management: Part 1 – General

・2008.07.26 IPA 「MD5 の安全性の限界に関する調査研究」に関する報告書・「安全な暗号鍵のライフサイクルマネージメントに関する調査」に関する報告書を公表

米国 OSCAL NIST CSWP 53（初期公開ドラフト）NIST OSCALの進路を示す (2025.12.02)

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

セキュリティについての準拠性チェック（監査も含む）について、コントロールが自動化されつつある中で、準拠性チェックも自動化すればよいではないか...というのが、Open Security Controls Assessment Language (OSCAL) の考えなのですかね...

セキュリティ全体を担保する上では、コントロールの実装・運用のみならず、その保証（アシュアランス）も重要となるのですが、日本では保証（アシュアランス）の話に至る前の段階なんですかね...ISMAPも含めてこれからOSCALが重要となってくると思われるので、日本でももっと検討がすすめばよいですね...

● NIST - ITL

・2025.12.02 NIST CSWP 53 (Initial Public Draft) Charting the Course for NIST OSCAL

NIST CSWP 53 (Initial Public Draft) Charting the Course for NIST OSCAL	NIST CSWP 53（初期公開ドラフト）NIST OSCALの進路を示す
Announcement	発表
This paper introduces the Open Security Controls Assessment Language (OSCAL) — an open-source, machine-readable language that standardizes security documentation for better monitoring and risk management.	本稿は、監視とリスクマネジメントの改善に向けたセキュリティ文書の標準化を目的としたオープンソースの機械可読言語「オープンセキュリティ制御評価言語（OSCAL）」を紹介する。
OSCAL was developed to modernize manual, paper-based cybersecurity compliance through automated, scalable processes and continuous assessments. This draft describes OSCAL’s layered architecture, its growing global adoption, and its future integration with emerging technologies (e.g., digital twins, agentic AI) for autonomous risk reasoning and continuous assurance.	OSCALは、手動・紙ベースのサイバーセキュリティコンプライアンスを、自動化・拡張可能なプロセスと継続的アセスメントによって近代化するために開発された。本ドラフトでは、OSCALの階層型アーキテクチャ、世界的な普及の進展、自律的リスク推論と継続的保証のための新興技術（例：デジタルツイン、エージェント型AI）との将来的な統合について説明する。
Abstract	要約
This document introduces the Open Security Controls Assessment Language (OSCAL), a NIST-developed, open-source, machine-readable language that modernizes manual, paper-based cybersecurity compliance by enabling automated and scalable processes. OSCAL standardizes security documentation for easier monitoring and risk management across different tools. It can also be extended and integrated with numerous capabilities, including software supply chain standards using OSCAL SBOMs, digital twin technology and AI-driven compliance. Overall, OSCAL helps organizations improve efficiency, accuracy, and collaboration in cybersecurity.	本稿は、NISTが開発したオープンソースの機械可読言語「Open Security Controls Assessment Language（OSCAL）」を紹介する。OSCALは自動化・拡張可能なプロセスを実現することで、手作業の紙ベースのサイバーセキュリティコンプライアンスを近代化する。OSCALはセキュリティ文書を標準化し、異なるツール間での監視とリスクマネジメントを容易にする。また、OSCAL SBOMを用いたソフトウェアサプライチェーン基準、デジタルツイン技術、AI駆動型コンプライアンスなど、数多くの機能との拡張・統合が可能である。全体として、OSCALは組織のサイバーセキュリティにおける効率性、正確性、協働性の向上に寄与する。

・[PDF] NIST.CSWP.53.ipd

1. Introduction	1. 序論
2. The OSCAL Ecosystem	2. OSCALエコシステム
3. OSCAL as the Shipping Container of Cybersecurity	3. サイバーセキュリティの輸送コンテナとしてのOSCAL
3.1. OSCAL's Layered Architecture and Models	3.1. OSCALの階層型アーキテクチャとモデル
3.2. The OSCAL Advantage: Standardized Efficiency and Interoperability	3.2. OSCALの利点：標準効率性と相互運用性
4. Global Momentum and the OSCAL Foundation: Scaling the Mission	4. グローバルな勢いとOSCAL財団：ミッションの拡大
5. Beyond Control Assessments: Augmenting and Integrating Capabilities	5. 制御アセスメントを超えて：能力の拡張と統合
5.1. OSCAL and Software Bills of Materials: A Natural Fit	5.1. OSCALとソフトウェア部品表：自然な適合性
5.2. Elevating Assessment Automation: The Power of OSCAL and Emerging Technologies	5.2. 評価自動化の高度化：OSCALと新興技術の力
5.2.1. From Static Security Artifacts to Intelligent Digital Twins	5.2.1. 静的なセキュリティアーティファクトからインテリジェントなデジタルツインへ
5.2.2. Autonomous Risk Reasoning with Agentic Al	5.2.2. エージェント型AIによる自律的なリスク推論
5.2.3. Generative Al: Simulating, Predicting, and Remediating	5.2.3. 生成的AI：シミュレーション、予測、修復
5.2.4. Real-Time Feedback Loops and Continuous Assurance	5.2.4. リアルタイムフィードバックループと継続的保証
5.3. Federated and Scalable Intelligence	5.3. 連合型かつ拡張可能なインテリジェンス
6. Why You Should "OSCAL-ize" Your Data	6. データを「OSCAL化する」べき理由
6.1. Join the OSCAL Community and Transform Compliance Together	6.1. OSCALコミュニティに参加し、共にコンプライアンスを変革する
6.2. Benefits of OSCAL Adoption	6.2. OSCAL導入のメリット
7. Final Thoughts: Build the Future of Compliance with OSCAL References	7. まとめ：OSCALでコンプライアンスの未来を構築する参考文献
List of Tables	表一覧
Table 1. Alignment of OSCAL data objects with SPDX and CycloneDX	表1. OSCALデータオブジェクトとSPDXおよびCycloneDXの対応関係
List of Figures	図一覧
Fig. 1. OSCAL Ecosystem Diagram	図1. OSCALエコシステム図
Fig. 2. OSCAL Foundation contribution workflow	図2. OSCAL財団への貢献ワークフロー
Fig. 3. OSCAL component definition outline	図3. OSCALコンポーネント定義の概要
Fig 4: Digital twin-based intelligent continuous system resilience management	図4: デジタルツインベースのインテリジェント継続的システムレジリエンス管理
Fig. 5. OSCAL's continuous self-healing process	図5. OSCALの継続的自己修復プロセス

エコシステム

1. Introduction	序論
In a digital world defined by rapid cloud adoption, intricate system dependencies, and evolving threats, the traditional and proprietary methods of cybersecurity compliance methods no longer scale effectively. The burden of paper-based documentation, manual assessments, and proprietary tools limits security data portability. As systems have evolved, the complexity of this work has increased significantly, and understanding interdependencies, control inheritance, and risk mitigation across layered systems is a monumental task.	クラウドの急速な普及、複雑なシステム依存関係、進化する脅威によって特徴づけられるデジタル世界において、従来のサイバーセキュリティコンプライアンス手法や独自手法はもはや効果的に拡張できない。紙ベースの文書化、手動評価、独自ツールの負担がセキュリティデータの移植性を制限している。システムが進化するにつれ、この作業の複雑さは著しく増大し、階層化されたシステム全体における相互依存関係、制御の継承、リスク緩和を理解することは途方もない課題となっている。
To address these challenges, the National Institute of Standards and Technology (NIST) has collaborated with industry partners to develop the Open Security Controls Assessment Language (OSCAL) [1], which is an open-source, machine-readable language designed to digitize security information and support dynamic risk management. This solution supports fast, costeffective, accurate, and continuous assessments and monitoring of critical systems. It also meets the urgent need for standardized, machine-readable documentation and portable, automated compliance processes.	これらの課題に対処するため、米国国立標準技術研究所（NIST）は業界パートナーと協力し、セキュリティ情報をデジタル化し動的リスクマネジメントを支援するオープンソースの機械可読言語「Open Security Controls Assessment Language（OSCAL）」[1]を開発した。このソリューションは、重要システムの迅速・低コスト・高精度・継続的なアセスメントと監視を支援する。また、標準の機械可読文書化と、移植性のある自動化されたコンプライアンスプロセスの緊急ニーズにも応える。
Developed with flexibility and operational excellence at its core, OSCAL began as a federalfocused project but has quickly grown into a global initiative. It enables the shift from manual to machine-driven, continuous assessments for a broad range of compliance domains. OSCAL’s rapid international adoption includes collaborations with organizations from the information technology industry and span multiple vertical markets, including international governments, public sectors, and financial services. Its use cases in privacy, safety, and accessibility across a variety of regulatory frameworks highlights its groundbreaking role in advancing proactive system resilience assessments.	柔軟性と運用効率を中核に開発されたOSCALは、連邦政府向けプロジェクトとして始まったが、急速にグローバルな取り組みへと発展した。これにより、幅広いコンプライアンス領域において、手動評価から機械駆動型の継続的アセスメントへの移行が可能となる。OSCALの急速な国際的普及には、情報技術産業の組織との連携が含まれ、国際政府、公共部門、金融サービスを含む複数の垂直市場に及んでいる。様々な規制枠組みにおけるプライバシー、安全性、アクセシビリティでの活用事例は、先制的なシステムレジリエンス評価を推進する画期的な役割を浮き彫りにしている。
2. The OSCAL Ecosystem	2. OSCALエコシステム
OSCAL is a community-driven initiative to standardize and automate security assessments and risk management processes. The OSCAL ecosystem features a broad network of government agencies, private-sector vendors, open-source contributors, and standards bodies working together to advance and mature the language. This ecosystem relies on key resources in several categories, as shown in Fig. 1:	OSCALは、セキュリティ評価とリスクマネジメントプロセスの標準・自動化を目指すコミュニティ主導のイニシアチブである。OSCALエコシステムは、政府機関、民間ベンダー、オープンソース貢献者、標準団体からなる広範なネットワークを特徴とし、言語の進化と成熟化に向けて協働している。このエコシステムは、図1に示すように、いくつかのカテゴリーにおける主要リソースに依存している：
• OSCAL models/schemas [2]: Define the structure of the language, and provide a standardized framework for continuous risk management	• OSCALモデル/スキーマ[2]：言語の構造を定義し、継続的リスクマネジメントのための標準化された枠組みを提供する
• Content (OSCAL artifacts) [3]: Standardized digital representations of information that support risk management processes (e.g., requirement, controls, safeguards), including their selection, implementation, and continuous assessment	• コンテンツ（OSCALアーティファクト）[3]： リスクマネジメントプロセス（要件、統制、保護手段など）を支援する情報の標準化されたデジタル表現。これには選択、実装、継続的アセスメントが含まれる。
• Editorial tools [4]: Support the creation, editing, and management of OSCAL content	• 編集ツール [4]: OSCALコンテンツの作成、編集、管理を支援する
• GRC (governance, risk, and compliance) tools: Enable the practical application and use of OSCAL to offer a consistent format for describing security requirements	• GRC（ガバナンス、リスク、コンプライアンス）ツール: OSCALの実践的適用と利用を可能にし、セキュリティ要件を記述するための一貫したフォーマットを提供する
• Operationalized content: Automated DevOps processes, such as continuous integration and continuous deployment (CI/CD) pipelines that leverage OSCAL’s native traceability and updatability (e.g., change management through granular unique identifiers systems).	• 運用化コンテンツ：OSCALの固有のトレーサビリティと更新可能性（例：細粒度の一識別子システムによる変更管理）を活用する継続的インテグレーション／継続的展開（CI/CD）パイプラインなどの自動化されたDevOpsプロセス。
Fig. 1. OSCAL Ecosystem Diagram	図1. OSCALエコシステム図
As the official owner and primary authority responsible for OSCAL, NIST leads the development and maintenance of the OSCAL models/schemas, which form the structure of the framework. In addition, NIST produces OSCAL content, including foundational artifacts that support implementation across a variety of use cases. In Fig. 1, the darker gray boxes represent NIST’s primary responsibilities in the OSCAL ecosystem. This content is made freely available as opensource resources to promote accessibility and adoption.	OSCALの公式所有者かつ主要な責任機関として、NISTは枠組みの構造を構成するOSCALモデル/スキーマの開発と維持を主導する。さらにNISTは、様々なユースケースでの実装を支援する基盤的成果物を含むOSCALコンテンツを生産する。図1において、濃い灰色のボックスはOSCALエコシステムにおけるNISTの主要な責任範囲を示す。このコンテンツは、アクセシビリティと採用を促進するため、オープンソースリソースとして自由に利用可能である。
While NIST retains ownership and governance over OSCAL, it actively promotes a collaborative, community-driven model that encourages contributions from other organizations, including the following key stakeholders:	NISTはOSCALの所有権とガバナンスを保持しつつ、他の組織からの貢献を奨励する協働的・コミュニティ主導モデルを積極的に推進している。主なステークホルダーは以下の通りである：
• Guideline/regulatory authors: Entities responsible for creating and publishing regulatory documents, such as policies, control catalogs, profiles, baselines, and overlays. These actors define, customize, and tailor requirements and controls to guide organizations in managing cybersecurity risks.	• ガイドライン／規制策定者：ポリシー、制御カタログ、プロファイル、ベースライン、オーバーレイなどの規制文書の作成・公開を担当する事業体。これらの主体は、組織がサイバーセキュリティリスクを管理するための指針として、要件や制御を定義・カスタマイズ・適応させる。
• Security professionals: Entities responsible for documenting the implementation of requirements or controls and demonstrating their effectiveness within information systems. They ensure that safeguards (i.e., implemented controls) are properly applied and meet required standards to mitigate identified risks.	• セキュリティ専門家：要件や制御の実装を文書化し、情報システム内での有効性を実証する責任を負う事業体。識別されたリスクを緩和するため、保護手段（実装された制御）が適切に適用され、要求される標準を満たしていることを保証する。
• Assessors/auditors: Independent entities responsible for evaluating the claimed satisfaction of requirements or control implementation to determine whether systems meet the risk management objectives of system owners or authorizing officials. This role involves analyzing documentation, verifying implementation, and identifying gaps or vulnerabilities.	• 評価者／監査者：要求事項や統制実施の主張された充足度を評価し、システムがシステム所有者や認可担当者のリスク管理目標を満たしているかを判断する独立した事業体である。この役割には、文書の分析、実施状況の検証、ギャップや脆弱性の特定が含まれる。
• Tool developers: Entities that develop editorial or GRC tools that automate and streamline risk management processes to improve efficiency and precision. Such tools empower security teams to perform their tasks more effectively and at scale.	• ツール開発者：リスクマネジメントプロセスを自動化・効率化し、効率性と精度を向上させる編集ツールやGRCツールを開発する事業体である。こうしたツールはセキュリティチームが業務をより効果的かつ大規模に遂行することを可能にする。
These participants generate content, develop tools, and operationalize use across systems. Their expertise is essential to advancing the maturity of the language and preparing it for international standardization. Any proposed changes to OSCAL or OSCAL-related content must be transparently reviewed and vetted by the community before being adopted or implemented by NIST.	これらの参加者はコンテンツを生成し、ツールを開発し、システム全体での運用を実現する。彼らの専門知識は、言語の成熟度を高め、国際標準に向けた準備を進める上で不可欠である。OSCALまたはOSCAL関連コンテンツへの変更提案は、NISTによる採用または実装前に、コミュニティによる透明性のある審査と検証を経なければならない。
Two essential tool categories in the ecosystem are crucial to the success and global adoption of OSCAL: editorial tools and GRC tools. Editorial tools support the generation, editing, and management of OSCAL content. GRC tools, which can be developed by vendors, then operationalize that content by integrating it into real-world workflows, enabling automation, and supporting security assessments and compliance reporting. Without editorial tools, creating and maintaining content would not be possible. Without GRC tools, that content would remain static and unusable in practice. Together, they enable organizations to fully utilize and accomplish the benefits of security automation and standardized compliance.	OSCALの成功と世界的な普及には、エコシステム内の2つの重要なツールカテゴリーが不可欠である。編集ツールとGRCツールだ。編集ツールはOSCALコンテンツの生成、編集、管理を支援する。ベンダーが開発可能なGRCツールは、そのコンテンツを実世界のワークフローに統合し、自動化を実現し、セキュリティアセスメントやコンプライアンス報告を支援することで運用化する。編集ツールがなければ、コンテンツの作成と維持は不可能だ。GRCツールがなければ、そのコンテンツは静的なまま実運用では使えない。両者が連携することで、組織はセキュリティ自動化と標準化されたコンプライアンスの利点を最大限に活用し達成できるのだ。
The OSCAL community is also strengthened by a wide range of supporters, such as the OSCAL	OSCALコミュニティは、幅広い支援者によっても強化されている。例えば2025年1月に業界主導のコンソーシアムとして設立されたOSCAL
Foundation [5], which was established in January 2025 as an industry-led consortium. The Foundation focuses on key areas to accelerate growth, maturation, and adoption, including content generation, model maturation, and community-consensus building. Specifically, it is working to achieve six core objectives: adoption, education, community engagement, development, extension, and internationalization.	財団[5]がそれだ。同財団は成長・成熟・普及を加速する重要領域に注力している。具体的にはコンテンツ生成、モデル成熟化、コミュニティ合意形成などだ。特に以下の6つの核心目標達成に取り組んでいる：普及、教育、コミュニティ関与、開発、拡張、国際化。
3. OSCAL as the Shipping Container of Cybersecurity	3. サイバーセキュリティの輸送コンテナとしてのOSCAL
To better understand how OSCAL streamlines complex security processes, compare it to something familiar: a shipping container. Historically, transporting goods by sea was timeconsuming, extensive, and labor-intensive. The introduction of standardized shipping container sizes in 1956 dramatically changed the industry by maximizing the use of space, simplifying transfers, speeding up loading and unloading operations, and reducing shipping costs.	OSCALが複雑なセキュリティプロセスをいかに効率化するか理解するには、身近な例である輸送コンテナと比較すると良い。歴史的に、海上輸送は時間がかかり、手間がかかり、労働集約的であった。1956年に標準輸送コンテナサイズが導入されたことで、空間利用の最大化、移送の簡素化、積み下ろし作業の迅速化、輸送コストの削減が実現し、業界は劇的に変化した。
Before container standardization, every shipment required custom handling. Today, cybersecurity documentation faces a similar challenge. Documents are often created in a range of formats that require manual restructuring before being shared or reused across systems. OSCAL solves this by introducing a common, machine-readable format — just like the standardized shipping container — that makes it easier to store, transfer, and automate compliance data across platforms and organizations.	コンテナ標準化以前、各輸送には個別対応が必要だった。今日のサイバーセキュリティ文書も同様の課題に直面している。文書は多様な形式で作成されることが多く、システム間で共有・再利用する前に手作業で再構築が必要だ。OSCALは、標準化された輸送コンテナと同様に、共通の機械可読形式を導入することでこの問題を解決する。これにより、プラットフォームや組織を跨いだコンプライアンスデータの保存、転送、自動化が容易になる。
OSCAL enables:	OSCALが実現するもの：
• Vendors to document the security controls implemented in their products	• ベンダーが自社製品に実装したセキュリティ制御を文書化すること
• System owners or policy makers to define standardized “playbooks” for system components	• システム所有者や政策立案者がシステムコンポーネント向けの標準「プレイブック」を定義すること
• System owners to test, review, and provisionally authorize system components	• システム所有者がシステムコンポーネントをテスト、レビューし、暫定的に認可すること
• The reuse of authorized components across different systems	• 承認済みコンポーネントを異なるシステム間で再利用すること
• Streamlined documentation generation to automate the traditionally manual and human-intensive labor of generating system security plans (SSPs)	• 従来手作業で人的リソースを要したシステムセキュリティ計画（SSP）作成を自動化する、効率化された文書生成
OSCAL’s implementation layer divides systems into modular components that can be reassembled or evaluated based on different needs, such as functionality or role. Think of OSCAL as “documentation as code” or “compliance as code,” which is essentially the digital equivalent of standardizing shipping containers. It is designed to carry security information about controls, baselines, their implementation, and assessments, and it enables DevOps-style automation in the traditionally manual world of security governance.	OSCALの実装層は、システムをモジュール化されたコンポーネントに分割する。これらは機能や役割など、異なるニーズに基づいて再構築または評価可能だ。OSCALを「ドキュメンテーション・アズ・コード」あるいは「コンプライアンス・アズ・コード」と捉えよう。これは本質的に、標準の輸送コンテナのデジタル版に相当する。これは、制御、ベースライン、その実装、アセスメントに関するセキュリティ情報を運ぶように設計されており、従来手作業だったセキュリティガバナンスの世界にDevOpsスタイルの自動化をもたらす。
3.1. OSCAL’s Layered Architecture and Models	3.1. OSCALの階層型アーキテクチャとモデル
OSCAL is organized into multiple layers, each containing specific models that serve distinct operational purposes and roles. Each model defines structured ways to represent how data is organized, known as information structures. Together, these structures form an information model, which is bound to multiple serialization formats, such as XML, JSON, and YAML. These serialization formats represent a concrete data model that specifies how an OSCAL information model is represented. Although the syntax of each format differs, all formats for a given model represent the exact same information. This means that OSCAL content that is written in one supported format (i.e., XML, JSON, or YAML) can be translated into any of the other formats without data loss.	OSCALは複数の層で構成され、各層には特定の運用目的と役割を果たすモデルが含まれる。各モデルは、データの組織化方法を構造化して表現する方法を定義しており、これは情報構造と呼ばれる。これらの構造が集合して情報モデルを形成し、XML、JSON、YAMLなどの複数のシリアライゼーション形式に紐付けられる。これらのシリアライゼーション形式は、OSCAL情報モデルの表現方法を規定する具体的なデータモデルを表す。各形式の構文は異なるが、特定のモデルに対する全形式は全く同一の情報を表現する。これは、あるサポート形式（XML、JSON、YAML）で記述されたOSCALコンテンツが、データ損失なく他の形式へ変換可能であることを意味する。
The NIST OSCAL website offers an overview of the OSCAL project, including resources, tutorials, detailed documentation, workshops, references, downloads, and more to support users at every level. The OSCAL specification is maintained in a live versioned format.	NIST OSCALウェブサイトでは、リソース、チュートリアル、詳細なドキュメント、ワークショップ、参考文献、ダウンロードなど、あらゆるレベルのユーザーを支援するOSCALプロジェクトの概要を提供している。OSCAL仕様はライブバージョン管理形式で維持されている。
Current OSCAL layers and released models are:	現在のOSCALレイヤーと公開済みモデルは以下の通りだ：
• Control Layer	• コントロールレイヤー
o Catalog Model	o カタログモデル
o Profile Model	o プロファイルモデル
• Implementation Layer	• 実装レイヤー
o Component Definition Model	o コンポーネント定義モデル
o System Security Plan (SSP) Model	o システムセキュリティ計画（SSP）モデル
• Assessment Layer	• 評価レイヤー
o Assessment Plan Model	o 評価計画モデル
o Assessment Results Model	o 評価結果モデル
o Plan of Action and Milestones (POA&M) Model	o 行動計画とマイルストーン（POA&M）モデル
In addition to the currently released OSCAL models, NIST is working with community members to expand OSCAL’s capabilities through new models, such as the Control Mapping Model and Shared Responsibility Model.	現在公開されているOSCALモデルに加え、NISTはコミュニティメンバーと連携し、制御マッピングモデルや共有責任モデルなどの新規モデルを通じてOSCALの機能拡張を進めている。
The OSCAL schemas, which define the “language” of OSCAL, are publicly hosted on the OSCAL GitHub Repository.[1] Community members are encouraged to participate by forking the repository, making improvements, and submitting pull requests to contribute to the ongoing development of OSCAL.	OSCALの「言語」を定義するスキーマは、OSCAL GitHubリポジトリで公開されている。[1] コミュニティメンバーは、リポジトリをフォークし、改善を行い、プルリクエストを提出することで、OSCALの継続的な開発に貢献するよう奨励されている。
NIST also publishes key cybersecurity documents in OSCAL, including the Cybersecurity Framework v2.0 [6], NIST Special Publication (SP) 800-53 [7], SP 800-53B [8], and 800-53A [9], NIST Special Publication (SP) 800-171 [10] and NIST Special Publication (SP) 800-218 [11]. These OSCAL artifacts contain structured sets of requirements and are maintained on the public OSCAL Content Repository. NIST OSCAL team will continue to work on converting more NIST special publications of interest to our community.	NISTはまた、サイバーセキュリティフレームワークv2.0[6]、NIST 特別刊行物(SP)800-53[7]をOSCALで公開している。SP 800-53B [8]、800-53A [9]、NIST 特別刊行物(SP) 800-171 [10]、NIST 特別刊行物(SP) 800-218 [11]などである。これらのOSCAL成果物は構造化された要件セットを含み、公開OSCALコンテンツリポジトリで管理されている。NIST OSCALチームは、今後もコミュニティにとって有益なNIST特別刊行物の変換作業を継続する。
3.2. The OSCAL Advantage: Standardized Efficiency and Interoperability	3.2. OSCALの利点：標準化された効率性と相互運用性
By automating documentation, assessments, and risk tracking, OSCAL addresses numerous realworld challenges, including:	文書化、アセスメント、リスク追跡を自動化することで、OSCALは以下のような現実世界の課題に対処する：
• Faster, cheaper, and more accurate audits	• より迅速で、低コストかつ正確な監査
• Tool interoperability and reduced vendor lock-in	• ツール間の相互運用性とベンダーロックインの低減
• Reuse of common controls and scalability across environments	• 共通制御の再利用と環境横断的な拡張性
• Automated validation and continuous monitoring	• 自動妥当性確認と継続的モニタリング
In addition to its core capabilities, OSCAL offers an open, machine-readable set of formats in XML, JSON, and YAML that make it easier to integrate into existing workflows and empower organizations to:	中核機能に加え、OSCALはXML、JSON、YAML形式のオープンで機械可読なフォーマット群を提供し、既存ワークフローへの統合を容易にする。これにより組織は以下が可能となる：
• Digitize and automate compliance documentation	• コンプライアンス文書のデジタル化と自動化
• Accelerate audits and Authority to Operate (ATO) processes	• 監査と運用許可（ATO）プロセスの加速化
• Reduce errors and manual effort	• エラーと手作業の削減
• Improve efficiency and consistency across security and compliance activities	• セキュリティおよびコンプライアンス活動全体の効率性と一貫性の向上
OSCAL defines a comprehensive ecosystem of digital artifacts, including control catalogs and profiles, SSPs, component definitions, and assessment plans and results. This ecosystem delivers unprecedented transparency throughout the compliance life cycle and helps organizations manage and demonstrate their security posture with greater confidence and clarity.	OSCALは、制御カタログとプロファイル、SSP、コンポーネント定義、アセスメント計画と結果を含む、デジタルアーティファクトの包括的なエコシステムを定義する。このエコシステムは、コンプライアンスライフサイクル全体に前例のない透明性をもたらし、組織がより確信と明確さをもってセキュリティ態勢を管理し、実証することを支援する。
[1] Additional OSCAL-related GitHub repositories are also available on NIST’s GitHub enterprise, though they are not covered in this document.	[1] OSCAL関連の追加GitHubリポジトリはNISTのGitHubエンタープライズ上でも利用可能だが、本ドキュメントでは扱わない。

OSCALのウェブページ

・Open Security Controls Assessment Language OSCAL

---

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

・2025.09.15 JASA セキュリティ監査自動化に向けた現状と可能性

・2025.06.21 監査（評価）はどんどん自動化される？ CSAのAIをつかった妥当性確認 (Valid-AI-ted) (2025.06.09)

・2025.04.09 米国 一般調達局 FedRAMP 20X (2025.03.24)

・2024.07.22 米国 これからはFedRampも含めて監査は自動化 (automate.fedramp.gov) !キーワードはOSCAL

・2024.04.22 内部監査人協会 意見募集 トピック別要求事項：サイバーセキュリティ (2024.04.11)/

・2024.04.02 米国 FedRAMPの新しいロードマップ(2024-2025)

・2020.07.16 JIPDEC ”米国のプライバシー保護に関する動向”

OSCALについての日本語の参考サイト

● PwC Japan

・2025.08.06 セキュリティ監査の自動化

・2024.02.02 OSCAL：進化するサイバーセキュリティ評価と管理プロセス OSCALの概要と国際的影響

● NRI

・2025.09 NIST OSCALによる内部統制の効率化・高度化に期待

・・[PDF]

● JASA - クラウドセキュリティ推進会議

・2025.01.16 セキュリティ監査の自動化への取り組み

● SecureNavi

・OSCAL Lab

2024.12.30	海外から学ぶOSCALの実用事例
2024.11.14	OSCALが変えるセキュリティ評価とコンプライアンス管理の未来
2024.11.09	Google内部でOSCALがどう活用されているのか
2024.11.09	ISOなどの標準文書や規格を生成するMetanormaとは
2024.11.09	OSCALを活用し、CISやCSAのマッピングに挑む
2024.11.07	OSCALの今後のビジョンと戦略を中の人が語る
2024.11.05	はじめてのNIST OSCAL：概要と国内での必要性
2024.11.04	OSCALを巡る文化とセキュリティカルチャー
2024.11.01	セキュリティの専門家は「目立たないヒーロー」（4th OSCAL Conference 基調講演より）
2024.10.31	KPMGにおけるOSCALのユースケース
2024.10.30	AWSにおける顧客体験の重要性とOSCALの採用
2024.10.16	EUのサイバーセキュリティ認証（EUCS）におけるOSCALの活用
2024.10.14	IBMが提供するSecurity and Compliance Center(SCC)とOSCALとの関係性
2024.10.13	GitHub Actionsを利用したOSCALモデルの操作デモ
2024.10.12	OSCAL導入プロジェクトの進め方
2024.10.10	OSCALを活用した NIST SP 800-53 Rev.4 から Rev.5 への移行
2024.10.07	NIST SP800-53の進化（Rev6を見据えて）
2024.10.05	OSCALを活用したFedRAMP自動化の背後にある技術
2024.10.03	爆発的な技術革新とOSCALの進化（3th OSCAL Workshop 基調講演より）

・Note

・・2021.11.04 NISTが開発する、セキュリティ対策をJSON等で記述する技術「OSCAL」とはなにか

米国 NIST CSWP 42 IoTセキュリティの自動化に向けて：信頼できるネットワーク層オンボーディングの実装 (2025.11.25)

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

NISTがIoTセキュリティの自動化に向けて、信頼できるネットワーク層オンボーディングの実装に関するホワイトペーパーを公表していますね...

セキュリティに関してはセキュリティ設定のできる限りの自動化がまずは重要なのだろうと思います。

現在のIoTオンボーディングの課題...

---

1. IoTデバイスへのネットワーク認証情報の手動プロビジョニングは、特に大規模な場合、エラーが発生しやすく、時間がかかり、しばしば安全でない。
2. 共有されたネットワーク認証情報は、脅威がネットワーク全体に容易に拡散することを許す。
3. 多くのIoTデバイスにおける限定的なユーザーインターフェースは、手動での認証情報入力を困難または不可能にする。
4. ネットワーク認証情報のプロビジョニングに利用されるオープンWi-Fiネットワークは、盗聴や不正アクセスのリスクを高める。
5. デバイス認証の欠如により、接続デバイスが当該ネットワークに真正に属するかどうかをネットワークが検証できない。

---

信頼されたネットワーク層オンボーディングが解決する課題

---

信頼されたネットワーク層オンボーディングとは、デバイスにネットワーク認証情報を安全にプロビジョニングする自動化された仕組みである。信頼されたネットワーク層オンボーディングとライフサイクル管理は、これらの課題に対処する4つの主要な機能を提供する：

1. デバイスごとの固有ネットワーク認証情報

• 攻撃対象領域を縮小し、潜在的な被害を制限する。
• 個々の侵害されたデバイスを容易に除去できる。
• デバイス間の認証情報再利用を防止する

2. ゼロタッチオンボーディング

• 自動化され拡張性のあるデバイスオンボーディングを実現する。
• IoTデバイスへのネットワーク認証情報の手動プロビジョニングを不要とする。
• エンタープライズと消費者向け双方のユースケースでプロセスを簡素化する。

3. 設定可能な信頼ポリシー

• 特定のユースケースに基づいた信頼定義のカスタマイズを可能とする。・様々なセキュリティ要件への柔軟な適応を可能とする。
• 異なるシナリオ向けのオンボーディング方法をカプセル化する

4. 継続的保証

• ゼロトラスト原則を実装する。
• 継続的なポリシーベースのデバイス認可を可能にする。
• 信頼ポリシー違反時に即時デバイス削除を許可する。

これらの機能は連携して以下を実現する：

• デバイスとネットワーク間の相互認証を可能にする。
• 暗号化チャネル経由でネットワーク認証情報を安全に伝送する。
• ネットワーク認証情報への不正アクセスを防止する。
• デバイスライフサイクル全体での反復的なオンボーディングをサポートする。

---

● NIST

・2025.11.25 NIST CSWP 42 Towards Automating IoT Security: Implementing Trusted Network-Layer Onboarding

NIST CSWP 42 Towards Automating IoT Security: Implementing Trusted Network-Layer Onboarding	NIST CSWP 42 IoTセキュリティの自動化に向けて：信頼できるネットワーク層オンボーディングの実装
Abstract	概要
This document provides an overview of trusted Internet of Things (IoT) device network-layer onboarding—a capability for securely providing IoT devices with their local network credentials in a manner that helps to ensure that the network is not put at risk as new IoT devices are connected to it. Additionally, the paper demonstrates the security benefits of trusted network-layer onboarding and how it can address problems with current IoT device onboarding practices.	本稿は、信頼されたIoTデバイス向けネットワーク層オンボーディングの概要を説明する。これは、新たなIoTデバイスが接続される際にネットワークがリスクに晒されないよう、IoTデバイスにローカルネットワーク認証情報を安全に提供する機能である。さらに、信頼されたネットワーク層オンボーディングのセキュリティ上の利点と、現行のIoTデバイスオンボーディング手法の問題点を解決する方法を示す。

・[PDF] NIST.CSWP.42

Audience	対象読者
This paper is intended for individuals and organizations who use IoT devices (e.g., to collect data from a variety of systems and locations in order to enable quick identification of potential issues and rapid response and management of them). IoT devices could measure real-time data to detect component faults, measure toxins, or detect infrastructure breaches. Whether these IoT devices are used on complex operational networks or relatively simple home networks, the goal is to avoid exposing those networks and devices to additional threats.	本稿は、IoTデバイスを利用する個人や組織を対象としている（例：様々なシステムや場所からデータを収集し、潜在的な問題を迅速に特定し、それに対する迅速な対応と管理を可能にするため）。IoTデバイスは、リアルタイムデータを測定して部品の故障を検知したり、毒素を測定したり、インフラの侵害を検知したりできる。これらのIoTデバイスが複雑な運用ネットワークで使用されるか、比較的単純な家庭内ネットワークで使用されるかにかかわらず、目的はそれらのネットワークやデバイスを追加の脅威に晒さないことである。
Overview	概要
When an IoT device is deployed, it must be connected to a local network. To connect to that local network securely, the device must be provided with network credentials. If those network credentials are not unique to the device or are not provided in a secure manner, the network will be at increased risk of unauthorized or malicious devices connecting to it. Along the same lines, if an IoT device is not able to establish trust in the network it is joining, it could be put at risk of onboarding to malicious networks.	IoTデバイスが展開される際、ローカルネットワークに接続する必要がある。安全に接続するためには、デバイスにネットワーク認証情報をプロバイダしなければならない。この認証情報がデバイス固有でない場合や、安全な方法で提供されない場合、不正なデバイスや悪意のあるデバイスが接続するリスクが高まる。同様に、IoTデバイスが接続先のネットワークへの信頼を確立できない場合、悪意のあるネットワークに組み込まれるリスクに晒される可能性がある。
What are the current IoT onboarding challenges?	現在のIoTオンボーディングの課題は何か？
With nearly 30 billion IoT devices forecasted to be connected worldwide by 2030 [1], there is a need for an automated, secure solution to network-layer onboarding. Current IoT device onboarding practices present many challenges to individuals and organizations, including:	2030年までに世界で300億台のIoTデバイスが接続されると予測されている[1]ことから、ネットワーク層のオンボーディングに対する自動化された安全なソリューションが必要である。現在のIoTデバイスオンボーディング手法は、個人や組織に多くの課題を提示している。具体的には：
1. Manual provisioning of network credentials to IoT devices is error-prone, time-consuming, and often insecure, especially at scale.	1. IoTデバイスへのネットワーク認証情報の手動プロビジョニングは、特に大規模な場合、エラーが発生しやすく、時間がかかり、しばしば安全でない。
2. Shared network credentials allow threats to propagate easily across the network.	2. 共有されたネットワーク認証情報は、脅威がネットワーク全体に容易に拡散することを許す。
3. Limited user interfaces on many IoT devices make manual credential input challenging or impossible.	3. 多くのIoTデバイスにおける限定的なユーザーインターフェースは、手動での認証情報入力を困難または不可能にする。
4. Open Wi-Fi networks used for the provisioning of network credentials increase the risk of eavesdropping and unauthorized access.	4. ネットワーク認証情報のプロビジョニングに利用されるオープンWi-Fiネットワークは、盗聴や不正アクセスのリスクを高める。
5. Lack of device authentication means that networks cannot verify if connecting devices truly belong on that network.	5. デバイス認証の欠如により、接続デバイスが当該ネットワークに真正に属するかどうかをネットワークが検証できない。
Trusted network-layer onboarding can provide important security benefits to individuals and organizations experiencing these challenges.	信頼されたネットワーク層オンボーディングは、こうした課題に直面する個人や組織に重要なセキュリティ上の利点をもたらす。
How does trusted network-layer onboarding address the problem?	信頼されたネットワーク層オンボーディングはどのように問題を解決するのか？
Trusted network-layer onboarding is an automated mechanism for securely provisioning network credentials to a device. Trusted network-layer onboarding and lifecycle management offer four key capabilities to address these challenges:	信頼されたネットワーク層オンボーディングとは、デバイスにネットワーク認証情報を安全にプロビジョニングする自動化された仕組みである。信頼されたネットワーク層オンボーディングとライフサイクル管理は、これらの課題に対処する4つの主要な機能を提供する：
1. Unique per-device network credentials	1. デバイスごとの固有ネットワーク認証情報
・ Reduces attack surface and constrains potential damage.	・ 攻撃対象領域を縮小し、潜在的な被害を制限する。
・ Allows easy removal of individual compromised devices.	・ 個々の侵害されたデバイスを容易に除去できる。
・ Prevents credential reuse between devices	・ デバイス間の認証情報再利用を防止する
2. Zero-touch onboarding	2. ゼロタッチオンボーディング
・ Enables automated, scalable device onboarding.	・自動化され拡張性のあるデバイスオンボーディングを実現する。
・ Eliminates the need for manual provisioning of network credentials to IoT devices.	・IoTデバイスへのネットワーク認証情報の手動プロビジョニングを不要とする。
・ Simplifies the process for both enterprise and consumer use cases.	・エンタープライズと消費者向け双方のユースケースでプロセスを簡素化する。
3. Configurable trust policies	3. 設定可能な信頼ポリシー
・ Allows customization of trust definitions based on specific use cases. ・ Enables flexible adaptation to various security requirements.	・ 特定のユースケースに基づいた信頼定義のカスタマイズを可能とする。・様々なセキュリティ要件への柔軟な適応を可能とする。
・ Encapsulates the onboarding method for different scenarios	・ 異なるシナリオ向けのオンボーディング方法をカプセル化する
4. Continuous assurance	4. 継続的保証
・ Implements zero-trust principles.	・ ゼロトラスト原則を実装する。
・ Enables ongoing policy-based device authorization.	・ 継続的なポリシーベースのデバイス認可を可能にする。
・ Allows for immediate device removal if trust policies are breached.	・ 信頼ポリシー違反時に即時デバイス削除を許可する。
These capabilities work together to:	これらの機能は連携して以下を実現する：
・ Enable mutual authentication between devices and networks.	・ デバイスとネットワーク間の相互認証を可能にする。
・ Securely transmit network credentials over encrypted channels.	・ 暗号化チャネル経由でネットワーク認証情報を安全に伝送する。
・ Prevent unauthorized access to network credentials.	・ ネットワーク認証情報への不正アクセスを防止する。
・ Support repeated onboarding throughout a device’s lifecycle.	・ デバイスライフサイクル全体での反復的なオンボーディングをサポートする。
By authenticating the identity of each device before providing the device with its network credentials, ensuring that each device receives unique credentials, and having those credentials encrypted while they are in-transit to the device, trusted network-layer onboarding helps ensure that the network will not be put at risk as new IoT devices are connected to it.	各デバイスの身元を認証した上でネットワーク認証情報をプロバイダし、各デバイスが固有の認証情報を受け取ることを保証し、デバイスへの転送中にそれらの認証情報を暗号化することで、信頼されたネットワーク層オンボーディングは、新たなIoTデバイスが接続されてもネットワークがリスクに晒されないことを確実に支援する。
How can I use trusted network-layer onboarding?	信頼されたネットワーク層オンボーディングをどう活用できるか？
The NIST National Cybersecurity Center of Excellence (NCCoE), in collaboration with 11 technology organizations, demonstrated the application of trusted IoT device network-layer onboarding. This project implemented and demonstrated two different trusted network-layer onboarding protocols: Wi-Fi Easy Connect [2] and Bootstrapping Remote Secure Key Infrastructure (BRSKI) [3]. Wi-Fi Easy Connect leverages public-key cryptography to ensure secure authentication and supports both Wi-Fi Protected Access 2 (WPA2) and WPA3 security standards, while BRSKI makes use of manufacturer-installed X.509 certificates and a registrar to establish mutual trust between the device and the network. The Wi-Fi Easy Connect protocol is particularly useful for devices with limited or no user interfaces, such as IoT devices in smart homes or enterprise settings, whereas BRSKI is designed for environments where devices need to be securely onboarded without user intervention, making it applicable to large-scale deployments.	NIST国立サイバーセキュリティ・センター・オブ・エクセレンス（NCCoE）は、11のテクノロジー組織と連携し、信頼できるIoTデバイス向けネットワーク層オンボーディングの適用を実証した。このプロジェクトでは、2種類の信頼できるネットワーク層オンボーディングプロトコルを実装・実証した：Wi-Fi Easy Connect [2] と Bootstrapping Remote Secure Key Infrastructure (BRSKI) [3] である。Wi-Fi Easy Connectは公開鍵暗号技術を活用して安全な認証を確保し、Wi-Fi Protected Access 2（WPA2）とWPA3のセキュリティ標準をサポートする。一方BRSKIは、製造事業者がインストールしたX.509証明書とレジストラを利用し、デバイスとネットワーク間の相互信頼を確立する。Wi-Fi Easy Connectプロトコルは、スマートホームやエンタープライズ環境におけるIoTデバイスなど、ユーザーインターフェースが限定的または存在しないデバイスに特に有用である。一方BRSKIは、ユーザー介入なしにデバイスを安全にオンボーディングする必要がある環境向けに設計されており、大規模展開に適用可能だ。
Wi-Fi Easy Connect and BRSKI can be used to provide trusted network-layer onboarding in a manner that is secure and easy to use.	Wi-Fi Easy ConnectとBRSKIは、安全かつ使いやすい方法で信頼できるネットワーク層オンボーディングを提供するために利用できる。
・ IoT Device Manufacturers: To leverage these protocols, IoT devices should be manufactured with support for the selected protocol.	・ IoTデバイスメーカー：これらのプロトコルを活用するには、選択したプロトコルをサポートするようにIoTデバイスを製造する必要がある。
・ Networks: Target networks must be equipped with compatible onboarding components (e.g., Wi-Fi Easy Connect-enabled access point or a BRSKI-enabled registrar).	・ ネットワーク：対象ネットワークは互換性のあるオンボーディングコンポーネント（例：Wi-Fi Easy Connect対応アクセスポイントまたはBRSKI対応レジストラ）を備えている必要がある。
・ IoT Device User: The user can select a protocol that aligns with their specific network requirements and the type of devices being onboarded. Individuals and organizations that want to take advantage of the enhanced security benefits offered by trusted network-layer onboarding may use either one of these protocols.	・ IoTデバイス利用者：利用者は、自身のネットワーク要件とオンボーディング対象デバイスの種類に合致するプロトコルを選択できる。信頼されたネットワーク層オンボーディングによる強化されたセキュリティ効果を活用したい個人や組織は、いずれかのプロトコルを利用できる。
What else should I know about trusted network-layer onboarding?	信頼されたネットワーク層オンボーディングについて他に知っておくべきことは？
Trusted network-layer onboarding is a continuous or recurring activity. Any given IoT device may need to be onboarded multiple times throughout its lifecycle, for example, to replace network credentials that need to be refreshed or to enable a device to be securely provisioned with credentials for a different network after being resold or repurposed. If a device supports Wi-Fi Easy Connect or BRSKI, these protocols may be used to provision the device with network credentials repeatedly as needed throughout its lifetime.	信頼されたネットワーク層オンボーディングは継続的または反復的な活動である。特定のIoTデバイスは、ライフサイクルを通じて複数回のオンボーディングが必要となる場合がある。例えば、更新が必要なネットワーク認証情報を置き換えるため、あるいは再販や再利用後に異なるネットワークの認証情報を安全にプロビジョニングするためなどだ。デバイスがWi-Fi Easy ConnectまたはBRSKIをサポートしている場合、これらのプロトコルを用いて、必要に応じてライフサイクルを通じて繰り返しネットワーク認証情報をプロビジョニングできる。
Mutual Authentication	相互認証
It is easy for a network to falsely identify itself, yet many IoT devices onboard to networks without first verifying the network’s identity to ensure that it is their intended target network. By authenticating the network (in addition to authenticating the device), trusted network-layer onboarding helps protect the device from joining and being taken over by an unauthorized, imposter network.	ネットワークは容易に偽装できるが、多くのIoTデバイスは、自身が接続すべき対象ネットワークであることを確認せずにネットワークにオンボーディングする。デバイス認証に加えネットワーク認証を行う信頼されたネットワーク層オンボーディングは、不正な偽装ネットワークへの接続や乗っ取りからデバイスを防御するのに役立つ。
Device Management Support	デバイス管理サポート
Once an IoT device is connected to the network, if it becomes compromised, it can pose a security risk to both the network and other connected devices. Failing to keep a device current with the most recent software and firmware updates may make it more susceptible to compromise. Once compromised, it may be used to attack other devices on the network. While trusted network-layer onboarding is essential to the security of an IoT device and its network, it is important to also deploy additional security measures (e.g., digital signatures of firmware, secure boot, and secure over-the-air updates) to securely update and manage IoT devices throughout the duration of their connection to the network to ensure that they remain secure.	IoTデバイスがネットワークに接続された後、侵害された場合、ネットワークと他の接続デバイス双方にセキュリティリスクをもたらす。デバイスを最新のソフトウェアおよびファームウェアで更新し続けることができないと、侵害を受けやすくなる可能性がある。侵害されたデバイスは、ネットワーク上の他のデバイスを攻撃するために悪用される可能性がある。信頼できるネットワーク層オンボーディングは、IoTデバイスとそのネットワークのセキュリティに不可欠だが、同時に追加のセキュリティ対策（ファームウェアのデジタル署名、セキュアブート、セキュアな無線更新など）の展開を行い、ネットワーク接続期間を通じてIoTデバイスを安全に更新・管理し、その安全性を維持することが重要である。
Application-layer Onboarding	アプリケーション層オンボーディング
Trusted network-layer onboarding can provide a secure foundation for additional security measures used to protect the device and its network on an ongoing basis. For example, it can provide a foundation for trusted application-layer onboarding by providing the secure exchange of application-layer onboarding bootstrapping information between a device and an application server to which it needs to connect securely. Trusted network-layer onboarding can be immediately and automatically followed by trusted application-layer onboarding, ensuring that a device is securely provisioned not only with its network credentials, but also with application-layer credentials. The device’s application server may then be used to securely download the most recent version of the device’s application to it, as well as to provide ongoing lifecycle management for the device, updating and patching its software as needed to maintain a secure posture on an ongoing basis. The example implementations built as part of the NCCoE Trusted IoT Device Network-Layer Onboarding project demonstrated IoT devices automatically performing several types of trusted application-layer onboarding following successful trusted network-layer onboarding and network connection.	信頼できるネットワーク層オンボーディングは、デバイスとそのネットワークを継続的に防御するための追加セキュリティ対策の基盤となる。例えば、デバイスが安全に接続する必要があるアプリケーションサーバーとの間で、アプリケーション層オンボーディングのブートストラップ情報を安全に交換する基盤を提供することで、信頼できるアプリケーション層オンボーディングの基盤を構築できる。信頼されたネットワーク層オンボーディングは、直ちに自動的に信頼されたアプリケーション層オンボーディングに続くことが可能であり、デバイスがネットワーク認証情報だけでなくアプリケーション層認証情報も安全にプロビジョニングされることを保証する。その後、デバイスのアプリケーションサーバーを利用して、デバイス向けアプリケーションの最新バージョンを安全にダウンロードできる。さらに、デバイスの継続的なライフサイクル管理を提供し、必要に応じてソフトウェアを更新・パッチ適用することで、常に安全な状態を維持する。NCCoE Trusted IoT Device Network-Layer Onboardingプロジェクトの一環として構築された実装例では、信頼されたネットワーク層オンボーディングとネットワーク接続の成功後、IoTデバイスが自動的に複数の信頼されたアプリケーション層オンボーディングを実行する様子が示された。
Beyond the examples of trusted network-layer onboarding integrated with application-layer onboarding demonstrated in this project, like Wi-Fi Easy Connect and Open Connectivity Foundation’s (OCF) IoTivity, there are additional methods of demonstrating this capability. An example of this is the integration of the Wireless Broadband Alliance’s (WBA) OpenRoaming framework with the FIDO Device Onboard (FDO) protocol, developed by the FIDO Alliance, which uses asymmetric public-key cryptography to provide a secure method for onboarding IoT devices to any device application-layer management system [4]. Another application-layer protocol in this space is Matter, developed by the Connectivity Standards Alliance (CSA). It incorporates built-in components for secure device application-layer onboarding, utilizing device identity and certificate-based authentication. This application-layer onboarding protocol supports various network transports, including Wi-Fi, Thread, and Ethernet, making it a versatile option for a variety of IoT device network-layer onboarding protocols [5].	本プロジェクトで示したWi-Fi Easy ConnectやOpen Connectivity Foundation（OCF）のIoTivityといった、アプリケーション層のオンボーディングと統合された信頼できるネットワーク層のオンボーディングの例以外にも、この機能を示す方法は存在する。その一例として、Wireless Broadband Alliance（WBA）のOpenRoaming枠組みと、FIDO Allianceが開発したFIDO Device Onboard（FDO）プロトコルの統合が挙げられる。FDOは非対称公開鍵暗号技術を用い、IoTデバイスをあらゆるデバイスのアプリケーション層管理システムに安全にオンボーディングする手法を提供する[4]。この分野における別のアプリケーション層プロトコルとして、コネクティビティ標準化アライアンス（CSA）が開発したMatterがある。これはデバイスIDと証明書ベースの認証を活用し、セキュアなデバイスアプリケーション層オンボーディングのための組み込みコンポーネントを統合している。このアプリケーション層オンボーディングプロトコルはWi-Fi、Thread、イーサネットを含む様々なネットワークトランスポートをサポートしており、多様なIoTデバイス向けネットワーク層オンボーディングプロトコルとして汎用性の高い選択肢となっている[5]。
Additional Security Capabilities	追加のセキュリティ機能
Trusted network-layer onboarding can also provide a secure foundation for additional security mechanisms, such as device communications intent enforcement (e.g., Manufacturer Usage Description—MUD [6]). MUD provides a standard way to specify the network communications that an IoT device requires to perform its intended functions. For example, the Wi-Fi Easy Connect protocol is specifically designed with the option of securely conveying the MUD file URL from the device to the network. If the network is equipped to support MUD, the Wi-Fi Easy Connect trusted network-layer onboarding process can securely provide the network with the device intent information it needs to ensure that only traffic required for the device to fulfill its designated purpose will be permitted to be sent from and received by the device (see NIST SP 1800-15, Securing Small-Business and Home IoT Devices: Mitigating Network-Based Attacks Using MUD [7]).	信頼されたネットワーク層オンボーディングは、追加のセキュリティ機構（例：デバイス通信意図の強制（Manufacturer Usage Description—MUD [6])）のための安全な基盤も提供し得る。MUDは、IoTデバイスが意図された機能を実行するために必要なネットワーク通信を指定する標準を提供する。例えば、Wi-Fi Easy Connectプロトコルは、デバイスからネットワークへMUDファイルURLを安全に伝達するオプションを特に備えて設計されている。ネットワークがMUDをサポートする機能を備えている場合、Wi-Fi Easy Connectの信頼できるネットワーク層オンボーディングプロセスは、デバイスが指定された目的を達成するために必要なトラフィックのみがデバイスから送信され、受信されることを保証するために必要なデバイス意図情報をネットワークに安全に提供できる（NIST SP 1800-15「中小企業および家庭用IoTデバイスのセキュリティ確保： ネットワークベース攻撃のMUDによる緩和[7]）。
One of the example implementations built as part of the NCCoE project demonstrated several zero trustinspired capabilities for performing continuous device authorization after the completion of trusted networklayer onboarding. This build performed a set of ongoing policy-based assurance checks and removed the device from the network if, for example:	NCCoEプロジェクトの一環として構築された実装例の一つは、信頼されたネットワーク層オンボーディング完了後の継続的なデバイス認可を実現する、ゼロトラストに着想を得たいくつかの機能を実証した。この構築では継続的なポリシーベースの保証チェックを実施し、例えば以下の場合にデバイスをネットワークから除外した：
・ the vulnerability score (e.g., using the Common Vulnerability Scoring System [CVSS]) for the device’s software bill of materials is determined to be above a set threshold,	・デバイスのソフトウェア部品表に対する脆弱性スコア（例：共通脆弱性評価システム［CVSS］使用）が設定閾値を超過した場合
・ the device attempted to contact an IP address that is on a denylist, or	・デバイスが拒否リスト登録IPアドレスへの接続を試みた場合
・ the manufacturer of the device is no longer trusted according to criteria determined by the network owner.	・ネットワーク所有者が定めた規準に基づき、デバイスの製造事業者が信頼されなくなった場合
For background information on the NCCoE Trusted IoT Device Network-Layer Onboarding project, including the functionality supported by five example trusted IoT device onboarding implementations prototyped within the demonstration lab environment, see NIST SP 1800-36, Volume B, Trusted IoT Device Network-Layer Onboarding and Lifecycle Management: Approach, Architecture, and Security Characteristics.	NCCoEの「信頼できるIoTデバイス向けネットワーク層オンボーディング」プロジェクトに関する背景情報（実証実験環境内でプロトタイプ化された5つの信頼できるIoTデバイスオンボーディング実装例がサポートする機能を含む）については、NIST SP 1800-36 Volume B「信頼できるIoTデバイス向けネットワーク層オンボーディングおよびライフサイクル管理：アプローチ、アーキテクチャ、セキュリティ特性」を参照のこと。
References	参考文献
[1] Vailshery L (2024) Number of Internet of Things (IoT) connections worldwide from 2022 to 2023, with forecasts from 2024 to 2033. Statista. Available at [web]	[1] Vailshery L (2024) 世界のモノのインターネット（IoT）接続数：2022年から2023年、および2024年から2033年までの予測。Statista。 [web]
[2] Wi-Fi Alliance (2020) Wi-Fi Easy Connect™ Specification Version 3.0. Available at [web]	[2] Wi-Fi Alliance (2020) Wi-Fi Easy Connect™ 仕様バージョン3.0。[web]
[3] Pritikin M, Richardson M, Eckert T, Behringer M, Watsen K (2021) Bootstrapping Remote Secure Key Infrastructure (BRSKI). (RFC Editor), Request for Comments (RFC) RFC 8995. [web]	[3] Pritikin M, Richardson M, Eckert T, Behringer M, ワッツン K (2021) リモートセキュアキーインフラストラクチャのブートストラップ (BRSKI). (RFC Editor), 意見要求 (RFC) RFC 8995. [web]
[4] Wireless Broadband Alliance (2025) Openroaming for IoT — FIDO Device Onboard Framework. Available at: [web]	[4] ワイヤレスブロードバンドアライアンス (2025) IoT向けオープンローミング — FIDOデバイス搭載枠組み. 入手先: [web]
[5] Connectivity Standards Alliance (2025). Matter: The Foundation for Connected Things. Available at: [web]	[5] Connectivity Standards Alliance (2025). Matter: The Foundation for Connected Things. 入手先: [web]
[6] Lear E, Droms R, Romascanu D (2019) Manufacturer Usage Description Specification. (RFC Editor), Request for Comments (RFC) RFC 8520. [web]	[6] Lear E、Droms R、Romascanu D (2019) 製造事業者使用説明仕様。(RFC Editor)、意見要求 (RFC) RFC 8520。[web]
[7] Dodson DF, Montgomery DC, Polk WT, Ranganathan M, Souppaya MP, Johnson S, Kadam A, Pratt C, Thakore D, Walker M, Lear E, Weis B, Barker WC, Coclin D, Hojjati A, Wilson C, Jones T, Baykal A, Cohen D, Yeich K, Fashina Y, Grayeli P, Harrington J, Klosterman J, Mulugeta B, Symington S, Singh J (2021) Securing Small-Business and Home Internet of Things (IoT) Devices: Mitigating Network-Based Attacks Using Manufacturer Usage Description (MUD). (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 1800-15. [web]	[7] Dodson DF、Montgomery DC、Polk WT、Ranganathan M、 Souppaya MP、Johnson S、Kadam A、Pratt C、Thakore D、Walker M、Lear E、Weis B、Barker WC、Coclin D、Hojjati A、ウィルソン C、Jones T、Baykal A、Cohen D、Yei K、Fashina Y、Grayeli P、Harrington J、Klosterman J、Mulugeta B、Symington S、Singh J (2021) 中小企業および家庭用モノのインターネット（IoT）デバイスのセキュリティ確保：製造事業者使用説明（MUD）を用いたネットワークベースの攻撃の緩和。（国立標準技術研究所、メリーランド州ゲイサーズバーグ）、NIST 特別刊行物（SP）1800-15。[web]

関連するNIST文書

• SP 1800-36 Trusted Internet of Things (IoT) Device Network-Layer Onboarding and Lifecycle Management: Enhancing Internet Protocol-Based IoT Device and Network Securit
  
  
• IR 8350 Foundational Concepts in Trusted IoT Device Network-Layer Onboarding: Enhancing Internet Protocol-Based IoT Device and Network Security

---

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

・2025.12.12 米国 NIST SP 1800-36 信頼できるIoT機器の ネットワーク層の実装とライフサイクル管理：インターネットプロトコルベースのIoT機器とネットワークセキュリティの強化 (2025.11.25)

・2025.12.09 米国 NIST IR 8350 信頼できるIoTデバイスのネットワーク層オンボーディングにおける基礎概念：インターネットプロトコルベースのIoTデバイスとネットワークのセキュリティ強化 (2025.11.25)

・2024.06.08 米国 NIST SP 1800-36 (初期公開ドラフト) 信頼できるIoT機器のネットワーク層の実装とライフサイクル管理：インターネットプロトコルベースのIoT機器とネットワークのセキュリティ強化

・2023.11.03 NIST SP 1800-36 (初期ドラフト第2版) 信頼できるIoT機器のネットワーク層の実装とライフサイクル管理：インターネットプロトコルベースのIoT機器とネットワークのセキュリティ強化 (B,C,E)

・2023.09.30 NIST SP 1800-36 (初期ドラフト第2版) 信頼できるIoT機器のネットワーク層オンボーディングとライフサイクル管理：インターネットプロトコルベースのIoT機器とネットワークのセキュリティ強化 (A,D)

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

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

米国 NIST SP 1800-36 信頼できるIoT機器のネットワーク層の実装とライフサイクル管理：インターネットプロトコルベースのIoT機器とネットワークセキュリティの強化 (2025.11.25)

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

NISTがSP 1800-36 信頼できるIoT機器のネットワーク層の実装とライフサイクル管理：インターネットプロトコルベースのIoT機器とネットワークセキュリティの強化 を公表していますね...

IoTデバイスに関する攻撃は２つあるとしていますね...

• デバイスが不正なネットワークに参加するよう誘導され、そのデバイスが制御される場合
• 悪意のあるデバイスがネットワークに侵入する場合

で、このような攻撃の影響を受けないようにするためには、

• デバイスとネットワークの身元および状態を証明・検証した上で、デバイスにネットワーク認証情報を提供するプロセス
• デバイスのライフサイクル全体を通じてIoTデバイスを安全に管理するための、スケーラブルで自動化されたメカニズム

が必要となりますね...

● NIST - ITL

・2025.11.25 NIST SP 1800-36 Trusted Internet of Things (IoT) Device Network-Layer Onboarding and Lifecycle Management: Enhancing Internet Protocol-Based IoT Device and Network Security

NIST SP 1800-36 Trusted Internet of Things (IoT) Device Network-Layer Onboarding and Lifecycle Management: Enhancing Internet Protocol-Based IoT Device and Network Security	NIST SP 1800-36 信頼できるIoT機器のネットワーク層のオンボーディングとライフサイクル管理：インターネットプロトコルベースのIoTデバイスとネットワークセキュリティの強化
Abstract	要約
Establishing trust between a network and an Internet of Things (IoT) device (as defined in NIST Internal Report 8425) prior to providing the device with the credentials it needs to join the network is crucial for mitigating the risk of potential attacks. There are two possibilities for attack. One happens when a device is convinced to join an unauthorized network, which would take control of the device. The other occurs when a network is infiltrated by a malicious device. Trust is achieved by attesting and verifying the identity and posture of the device and the network before providing the device with its network credentials—a process known as network-layer onboarding. In addition, scalable, automated mechanisms are needed to safely manage IoT devices throughout their lifecycles, such as safeguards that verify the security posture of a device before the device is permitted to execute certain operations. In this practice guide, the National Cybersecurity Center of Excellence (NCCoE) applies standards, best practices, and commercially available technology to demonstrate various mechanisms for trusted network-layer onboarding of IoT devices in Internet Protocol based environments. This guide shows how to provide network credentials to IoT devices in a trusted manner and maintain a secure device posture throughout the device lifecycle, thereby enhancing IoT security in alignment with the IoT Cybersecurity Improvement Act of 2020.	ネットワークとIoT機器（NIST内部報告書8425で定義）の間に、デバイスがネットワークに参加するために必要な認証情報を提供する前に信頼関係を確立することは、潜在的な攻撃のリスクを緩和するために極めて重要である。攻撃の可能性は二つある。一つは、デバイスが不正なネットワークに参加するよう誘導され、そのデバイスが制御される場合である。もう一つは、悪意のあるデバイスがネットワークに侵入する場合である。信頼は、デバイスとネットワークの身元および状態を証明・検証した上で、デバイスにネットワーク認証情報を提供するプロセス（ネットワーク層オンボーディングと呼ばれる）によって達成される。さらに、デバイスのライフサイクル全体を通じてIoTデバイスを安全に管理するための、スケーラブルで自動化されたメカニズムが必要である。例えば、デバイスが特定の操作を実行することを許可する前に、そのセキュリティ状態を検証する保護手段などである。本実践ガイドでは、国立サイバーセキュリティ・センター・オブ・エクセレンス（NCCoE）が、標準、ベストプラクティス、市販技術を活用し、インターネットプロトコルベース環境におけるIoTデバイスの信頼できるネットワーク層オンボーディングを実現する様々なメカニズムを示す。本ガイドは、信頼できる方法でIoTデバイスにネットワーク認証情報をプロバイダし、デバイスライフサイクルを通じて安全なデバイス状態を維持する方法を示す。これにより、2020年IoTサイバーセキュリティ改善法に沿ったIoTセキュリティの強化を図る。

・[PDF] NIST.SP.1800-36

エグゼクティブサマリー...

Executive Summary	エグゼクティブサマリー
Establishing trust between a network and an Internet of Things (IoT) device (as defined in NIST Internal Report 8425) prior to providing the device with the credentials it needs to join the network is crucial for mitigating the risk of potential attacks. There are two possibilities for attack. One happens when a device is convinced to join an unauthorized network, which would take control of the device. The other occurs when a malicious device infiltrates a network. Trust is achieved by attesting and verifying the identity and posture of the device and the network before providing the device with its network credentials—a process known as network-layer onboarding. In addition, scalable, automated mechanisms are needed to safely manage IoT devices throughout their lifecycles, such as safeguards that verify the security posture of a device before the device is permitted to execute certain operations. In this practice guide, the National Cybersecurity Center of Excellence (NCCoE) applies standards, best practices, and commercially available technology to demonstrate various mechanisms for trusted network-layer onboarding of IoT devices in Internet Protocol-based environments. This guide shows how to provide network credentials to IoT devices in a trusted manner and maintain a secure device posture throughout the device lifecycle, thereby enhancing IoT security.	ネットワークとモノのインターネット（IoT）デバイス（NIST内部報告書8425で定義されるもの）の間に、デバイスがネットワークに参加するために必要な認証情報をプロバイダする前に信頼関係を確立することは、潜在的な攻撃リスクの緩和のために極めて重要である。攻撃の可能性は二つある。一つは、デバイスが不正なネットワークに参加するよう誘導され、そのデバイスが制御される場合だ。もう一つは、悪意のあるデバイスがネットワークに侵入する場合である。 信頼は、デバイスとネットワークの身元および状態を証明・検証した上で、デバイスにネットワーク認証情報を提供するプロセス（ネットワーク層オンボーディングと呼ばれる）によって達成される。さらに、デバイスのライフサイクル全体を通じてIoTデバイスを安全に管理するための、スケーラブルで自動化されたメカニズムが必要である。例えば、デバイスが特定の操作を実行することを許可する前に、そのセキュリティ状態を検証する保護手段などである。 本実践ガイドでは、国立サイバーセキュリティ・センター・オブ・エクセレンス（NCCoE）が、標準、ベストプラクティス、市販技術を活用し、インターネットプロトコルベース環境におけるIoTデバイスの信頼性のあるネットワーク層オンボーディングを実現する様々なメカニズムを示す。本ガイドは、信頼性のある方法でIoTデバイスにネットワーク認証情報をプロバイダし、デバイスのライフサイクルを通じて安全な状態を維持する方法を示し、それによってIoTセキュリティを強化する。
CHALLENGE	課題
With tens of billions of IoT devices connected worldwide and more being connected every day, it is unrealistic to onboard or manage a network of these devices manually. In addition, providing local network credentials at the time of manufacture requires the manufacturer to customize network-layer onboarding on a build-to-order basis, which prevents the manufacturer from taking full advantage of the economies of scale that could result from building identical devices for its customers.	世界中で数百億台のIoTデバイスが接続され、日々さらに増加している現状では、これらのデバイスネットワークを手動でオンボーディングまたは管理することは非現実的である。さらに、製造時にローカルネットワーク認証情報を提供するには、製造事業者が受注生産ごとにネットワーク層のオンボーディングをカスタマイズする必要があり、顧客向けに同一デバイスを製造することで得られる規模の経済を十分に活用できなくなる。
There is a need to have a scalable, automated mechanism to securely manage IoT devices throughout their lifecycles and, in particular, a trusted mechanism for providing IoT devices with their network credentials and access policy at the time of deployment on the network. It is easy for a network to falsely identify itself, yet many IoT devices onboard to networks without verifying the network’s identity and ensuring that it is their intended target network. Also, many IoT devices lack user interfaces, making it cumbersome to input network credentials manually. Wi-Fi is sometimes used to provide credentials over an open (i.e., unencrypted) network, but this onboarding method risks credential disclosure. Most home networks use a single password shared among all devices, so access is controlled only by the device’s possession of the password. This type of access does not consider a unique device identity or whether the device belongs on the network. This method also increases the risk of exposing credentials to unauthorized parties. Providing unique credentials to each device is more secure, but providing unique credentials manually would be resource-intensive and error-prone, risk credential disclosure, and cannot be performed at scale.	IoTデバイスのライフサイクル全体を通じて安全に管理するスケーラブルな自動化メカニズム、特にネットワーク展開時に信頼できる認証情報とアクセスポリシーを提供するプロバイダが必要だ。ネットワークは容易に偽装できるにもかかわらず、多くのIoTデバイスはネットワークの身元を確認せず、意図したターゲットネットワークであることを保証せずに接続してしまう。 また、多くのIoTデバイスにはユーザーインターフェースがなく、ネットワーク認証情報を手動で入力するのは面倒だ。Wi-Fiを使ってオープン（つまり暗号化されていない）ネットワーク経由で認証情報をプロバイダする場合もあるが、このオンボーディング方法では認証情報の漏洩リスクがある。 家庭用ネットワークの多くは全デバイスで共通のパスワードを使用するため、アクセス管理は単にパスワードの所持有無に依存している。この方式ではデバイス固有の識別やネットワークへの所属適格性が考慮されない。また認証情報を不正な第三者に晒すリスクも高まる。各デバイスに固有の認証情報をプロバイダする方が安全だが、手動での付与はリソースを大量に消費し、エラーが発生しやすく、認証情報漏洩のリスクもあり、大規模な運用には向かない。
Once a device is connected to the network, if it becomes compromised, it can pose a security risk to both the network and other connected devices. Not keeping such a device current with the most recent software and firmware updates may make it more susceptible to compromise. The device could also be attacked through the receipt of malicious payloads. Once compromised, it may be used to attack other devices on the network or become part of a larger botnet, potentially participating in distributed denialof-service (DDoS) attacks or other malicious activities across the internet.	デバイスがネットワークに接続された後、侵害されるとネットワーク全体や他の接続デバイスにセキュリティリスクをもたらす可能性がある。最新のソフトウェアやファームウェア更新を適用しないまま放置すると、侵害されやすくなる。 デバイスは悪意のあるペイロードの受信を通じて攻撃される可能性もある。侵害された場合、ネットワーク上の他のデバイスを攻撃するために利用されたり、大規模なボットネットの一部となり、分散型サービス拒否（DDoS）攻撃やインターネット上のその他の悪意のある活動に参加する可能性がある。
OUTCOME	成果
The outcome of this project is to enhance the security of systems by helping IoT device users, manufacturers, and vendors understand how to carry out trusted network layer onboarding. This project has developed examples of trusted onboarding solutions and demonstrated these solutions using sample technologies and various scenarios. The NCCoE has published the findings in this practice guide, a NIST Special Publication (SP) 1800 series composed of multiple volumes targeting different audiences.	本プロジェクトの成果は、IoTデバイス利用者、製造事業者、ベンダーが信頼できるネットワーク層オンボーディングの実施方法を理解することで、システムのセキュリティを強化することである。本プロジェクトでは、信頼できるオンボーディングソリューションの事例を開発し、サンプル技術と様々なシナリオを用いてこれらのソリューションを実証した。NCCoEは、この実践ガイド（NIST 特別刊行物（SP）1800シリーズの一部であり、異なる対象者向けに複数の巻で構成される）に調査結果を公表した。
This practice guide can help IoT device users:	この実践ガイドは、IoTデバイス利用者が以下のことを行うのに役立つ：
Understand how to onboard their IoT devices in a trusted manner to:	信頼できる方法でIoTデバイスをオンボーディングする方法を理解し、以下の目的を達成する：
§  Ensure that their network is not put at risk as new IoT devices are added to it	§  ネットワークに新たなIoTデバイスが追加されても、ネットワークがリスクにさらされないようにする
§  Safeguard their IoT devices from being taken over by unauthorized networks	§  不正なネットワークによるIoTデバイスの乗っ取りを防ぐ
§  Provide IoT devices with unique credentials for network access	§  IoTデバイスにネットワークアクセス用の固有認証情報を付与する
§  Provide, renew, and replace device network credentials in a secure manner	§  デバイスネットワーク認証情報を安全な方法で提供、更新、交換する
§  Support ongoing protection of IoT devices throughout their lifecycles	§  IoTデバイスのライフサイクル全体を通じた継続的な防御を支援する
This practice guide can help manufacturers and vendors of semiconductors, secure storage components, IoT devices, and network onboarding equipment:	この実践ガイドは、半導体、セキュアストレージコンポーネント、IoTデバイス、ネットワークオンボーディング機器の製造事業者およびベンダーが以下のことを行うのに役立つ：
Understand the desired security properties for supporting trusted network-layer onboarding and explore their options with respect to recommended practices for:	信頼できるネットワーク層オンボーディングを支援するための望ましいセキュリティ特性を理解し、以下の推奨実践に関する選択肢を検討する：
§  Providing unique credentials into secure storage on IoT devices at the time of manufacture to mitigate supply chain risks (i.e., device credentials)	§  製造事業者時にIoTデバイスのセキュアストレージへ固有の認証情報をプロバイダすることで、サプライチェーンリスクを緩和する（例：デバイス認証情報）
§  Installing onboarding software on IoT devices	§  IoTデバイスへのオンボーディングソフトウェアのインストール
§  Providing IoT device purchasers with information needed to onboard the IoT devices to their networks (i.e., device bootstrapping information)	§  IoTデバイス購入者に対し、自社のネットワークへIoTデバイスをオンボーディングするために必要な情報をプロバイダすること（例：デバイスブートストラップ情報）
§  Integrating support for network-layer onboarding with additional security capabilities to provide ongoing protection throughout the device lifecycle	§  ネットワーク層オンボーディングのサポートを、デバイスのライフサイクル全体を通じて継続的な防御を提供する追加のセキュリティ機能と統合すること
SOLUTION	解決策
The NCCoE recommends using trusted network-layer onboarding to provide scalable, automated, trusted ways to provide IoT devices with unique network credentials and manage devices throughout their lifecycles to ensure they remain secure. The NCCoE collaborated with technology providers and other stakeholders to implement example trusted network-layer onboarding solutions for IoT devices that:	NCCoEは、信頼できるネットワーク層オンボーディングを利用することを推奨する。これにより、IoTデバイスに固有のネットワーク認証情報を提供し、デバイスのライフサイクルを通じて管理する、スケーラブルで自動化された信頼できる方法を実現し、デバイスの安全性を確保する。NCCoEは技術プロバイダやその他の関係者と協力し、IoTデバイス向けの信頼できるネットワーク層オンボーディングソリューションの例を実装した。その内容は以下の通りである：
§  provide each device with unique network credentials,	§  各デバイスに固有のネットワーク認証情報を付与する
§  enable the device and the network to mutually authenticate,	§  デバイスとネットワークの相互認証を可能にする
§  send devices their credentials over an encrypted channel,	§  暗号化されたチャネルを介してデバイスに資格情報を送信する、
§  do not provide any person with access to the credentials, and	§  いかなる人物の認証情報へのアクセス権の提供者ともなってはならない、
§  can be performed repeatedly throughout the device lifecycle.	§  デバイスのライフサイクルを通じて繰り返し実行可能である。
The capabilities demonstrated include:	実証された機能には以下が含まれる：
§  trusted network-layer onboarding of IoT devices,	§  IoTデバイスの信頼できるネットワーク層でのオンボーディング、
§  repeated trusted network-layer onboarding of devices to the same or a different network,	§  同一または異なるネットワークへのデバイスの繰り返し信頼ネットワーク層オンボーディング、
§  trusted application-layer onboarding (i.e., automatic establishment of an encrypted connection between an IoT device and a trusted application service after the IoT device has performed trusted network-layer onboarding and used its credentials to connect to the network), and	§  信頼されたアプリケーション層でのオンボーディング（すなわち、IoTデバイスが信頼されたネットワーク層でのオンボーディングを実行し、その認証情報を使用してネットワークに接続した後、IoTデバイスと信頼されたアプリケーションサービス間の暗号化された接続を自動的に確立すること）、および
§  software-based methods to provide device credentials in the factory and transfer device bootstrapping information from the device manufacturer to the device purchaser.	§  ソフトウェアベースの手法による、工場でのデバイス認証情報のプロバイダ、およびデバイス製造事業者から購入者へのデバイス初期化情報の転送。
Future capabilities could build upon this project by demonstrating the integration of trusted networklayer onboarding with additional zero trust-inspired [Note: See NIST SP 800-207] mechanisms beyond those currently demonstrated. Additionally, the Connectivity Standards Alliance Matter protocol was released after the initiation of this project, and therefore, it was not incorporated into the current capabilities. However, future community efforts could involve exploring the integration of this standard to enhance security and interoperability.	将来の機能は、本プロジェクトを基盤として、信頼できるネットワーク層のオンボーディングと、現在実証されているものを超える追加のゼロトラストに基づく[注：NIST SP 800-207参照]メカニズムの統合を実証することで発展させられる。さらに、Connectivity Standards AllianceのMatterプロトコルは本プロジェクト開始後に公開されたため、現在の機能には組み込まれていない。しかし、将来のコミュニティ活動では、セキュリティと相互運用性を強化するため、この標準の統合を検討することが考えられる。
This demonstration followed an agile methodology of building implementations (i.e., builds) iteratively and incrementally, starting with network-layer onboarding and gradually integrating additional capabilities that improve device and network security throughout a managed device lifecycle. This demonstration includes factory builds that simulate activities performed to securely provide device credentials during manufacturing, and five network-layer onboarding builds that demonstrate the Wi-Fi Easy Connect, Bootstrapping Remote Secure Key Infrastructure (BRSKI), and Thread Commissioning protocols. These builds also demonstrate both streamlined and independent trusted application-layer onboarding approaches, along with policy-based continuous assurance and authorization. The example implementations use technologies and capabilities from our project collaborators (listed below).	本実証はアジャイル手法に従い、実装（ビルド）を反復的・漸進的に構築した。ネットワーク層オンボーディングから開始し、管理対象デバイスのライフサイクル全体を通じてデバイスとネットワークのセキュリティを向上させる追加機能を段階的に統合した。 本実証には、製造工程でデバイス認証情報を安全に提供する活動を模擬する工場ビルドと、Wi-Fi Easy Connect、Bootstrapping Remote Secure Key Infrastructure（BRSKI）、Thread Commissioningプロトコルを実証する5つのネットワーク層オンボーディング ビルドが含まれる。これらのビルドは、合理化された信頼できるアプリケーション層オンボーディング手法と独立した手法、およびポリシーベースの継続的保証と認可も実証している。実装例では、プロジェクト協力者（下記参照）の技術と機能を活用している。
Collaborators	協力者
Aruba, a Hewlett Packard Enterprise company	Aruba（ヒューレット・パッカード・エンタープライズ傘下）
CableLabs	CableLabs
Cisco	Cisco
Foundries.io	Foundries.io
Kudelski IoT	クデルスキーIoT
NquiringMinds	NquiringMinds
NXP Semiconductors	NXPセミコンダクターズ
Open Connectivity	オープン・コネクティビティ
Foundation (OCF)	Foundation (OCF)
Sandelman Software Works	Sandelman Software ワークス
SEALSQ, a subsidiary of WISeKey	SEALSQ、WISeKeyの子会社
Silicon Labs	シリコンラボ
While the NCCoE uses a suite of commercial products, services, and proof-of-concept technologies to address this challenge, this guide does not endorse these particular products, services, and technologies, nor does it guarantee compliance with any regulatory initiatives. Your organization's information security experts should identify the products and services that will best integrate with your IoT products, existing tools, IT and IoT system infrastructure, and operations. Your organization can adopt these solutions or one that adheres to these guidelines in whole, or you can use this guide as a starting point for tailoring and implementing parts of a solution.	NCCoE はこの課題に対処するため、一連の商用製品、サービス、概念実証技術を利用しているが、本ガイドはこれらの特定の製品、サービス、技術を推奨するものではなく、また、いかなる規制イニシアチブへの準拠を保証するものでもない。 組織の情報セキュリティ専門家は、自社の IoT 製品、既存ツール、IT および IoT システムインフラ、運用に最適に統合できる製品やサービスを識別すべきだ。組織はこれらのソリューション、あるいは本ガイドラインに完全に準拠したソリューションを採用することも、本ガイドを起点としてソリューションの一部をカスタマイズ・実装することも可能だ。
HOW TO USE THIS GUIDE	本ガイドの使用方法
Depending on your role in your organization, you might use this guide in different ways:	組織内での役割に応じて、このガイドの活用方法は異なる：
Business decision makers, such as chief information security, product security, and technology officers, can use this part of the guide, NIST SP 1800-36A: Executive Summary, to understand the project’s challenges and outcomes, as well as our solution approach.	最高情報セキュリティ責任者、製品セキュリティ責任者、最高技術責任者などの経営意思決定者は、本ガイドの一部であるNIST SP 1800-36A：エグゼクティブサマリーを活用し、プロジェクトの課題と成果、ならびに当社のソリューションアプローチを理解できる。
Technology, security, and privacy program managers who are concerned with how to identify, understand, assess, and mitigate risk can use NIST SP 1800-36B: Approach, Architecture, and Security Characteristics. This part of the guide describes the architecture and different implementations. Also, NIST SP 1800-36E: Risk and Compliance Management, maps components of the trusted onboarding reference architecture to security characteristics in broadly applicable, well-known cybersecurity guidelines and practices.	リスクの識別、理解、アセスメント、緩和の方法に関心を持つ技術、セキュリティ、プライバシープログラムの管理者は、NIST SP 1800-36B: アプローチ、アーキテクチャ、セキュリティ特性を利用できる。このガイドの部分では、アーキテクチャと様々な実装について説明している。 また、NIST SP 1800-36E「リスクとコンプライアンス管理」は、信頼できるオンボーディング参照アーキテクチャの構成要素を、広く適用可能な著名なサイバーセキュリティガイドラインや実践におけるセキュリティ特性にマッピングしている。
IT professionals who want to implement an approach like this can make use of NIST SP 1800-36C: HowTo Guides. It provides product installation, configuration, and integration instructions for building example implementations, allowing them to be replicated in whole or in part. They can also use NIST SP 1800-36D: Functional Demonstrations, which provides the use cases defined to showcase trusted network-layer onboarding and lifecycle management security capabilities and the results of demonstrating these capabilities with each example implementation. These use cases may be helpful when developing requirements for systems being developed.	このようなアプローチを実装したいIT専門家は、NIST SP 1800-36C「ハウツーガイド」を活用できる。これは例示実装を構築するための製品インストール、設定、統合手順を提供し、全体または一部を複製することを可能にする。 また、NIST SP 1800-36D: 機能実証も利用できる。これは信頼できるネットワーク層オンボーディングとライフサイクル管理のセキュリティ機能を実証するために定義されたユースケースと、各 実装例を用いた機能実証結果を提供する。これらのユースケースは、開発中のシステム要件を策定する際に役立つ可能性がある。
COLLABORATORS	協力者
Collaborators participating in this project submitted their capabilities in response to an open call in the Federal Register for all sources of relevant security capabilities from academia and industry (vendors and integrators). Those respondents with relevant capabilities or product components signed a Cooperative Research and Development Agreement (CRADA) to collaborate with NIST in a consortium to build this example solution.	このプロジェクトに参加した協力者は、学術界および産業界（ベンダーおよびインテグレーター）の関連セキュリティ機能に関するあらゆる情報源を募集する連邦官報の公募に応じて、その能力を提出した。関連能力または製品コンポーネントを有する対応者は、このサンプルソリューションを構築するためのコンソーシアムにおいて NIST と協力するため、共同研究開発契約（CRADA）に署名した。
Certain commercial entities, equipment, products, or materials may be identified by name or company logo or other insignia in order to acknowledge their participation in this collaboration or to describe an experimental procedure or concept adequately. Such identification is not intended to imply special status or relationship with NIST or recommendation or endorsement by NIST or the NCCoE; neither is it intended to imply that the entities, equipment, products, or materials are necessarily the best available for the purpose.	特定の商業事業体、機器、製品、または材料は、この共同作業への参加を認めるため、あるいは実験手順や概念を適切に説明するために、名称、会社のロゴ、その他の記章で識別される場合がある。このような識別は、NIST または NCCoE との特別な地位や関係、あるいは NIST または NCCoE による推奨や支持を意味するものではない。また、その事業体、機器、製品、または材料が、その目的に必ずしも最適であることを意味するものでもない。

目次...

SP1800-36 Volume A: Executive Summary	SP1800-36A： エグゼクティブサマリー
SP1800-36 Volume B: Approach, Architecture, and Security Characteristics	SP1800-36B： アプローチ、アーキテクチャ、およびセキュリティ特性
1 Summary	1 概要
1.1 Challenge	1.1 課題
1.2 Soluon	1.2 解決策
1.3 Benefits	1.3 メリット
2 How to Use This Guide	2 このガイドの使用方法
2.1 Typographic Convenons	2.1 組版上の慣例
2.2 Publicaon Structure	2.2 出版物の構成
3 Approach	3 アプローチ
3.1 Audience	3.1 対象読者
3.2 Scope	3.2 適用範囲
3.3 Assumpons and Definions	3.3 前提条件と定義
3.4 Collaborators and Their Contribuons	3.4 協力機関とその貢献
4 Reference Architecture	4 参照アーキテクチャ
4.1 Device Manufacture and Factory Provisioning Process	4.1 デバイス製造および工場プロビジョニングプロセス
4.2 Device Ownership and Bootstrapping Informaon Transfer Process	4.2 デバイス所有権とブートストラップ情報転送プロセス
4.3 Trusted Network-Layer Onboarding Process	4.3 信頼されたネットワーク層オンボーディングプロセス
4.4 Trusted Applicaon-Layer Onboarding Process	4.4 信頼されたアプリケーション層オンボーディングプロセス
4.5 Connuous Verificaon	4.5 継続的検証
5 Laboratory Physical Architecture	5 実験室物理アーキテクチャ
5.1 Shared Environment	5.1 共有環境
5.2 Build 1 (Wi-Fi Easy Connect, Aruba/HPE) Physical Architecture	5.2 ビルド 1 (Wi-Fi Easy Connect、Aruba/HPE) 物理アーキテクチャ
5.3 Build 2 (Wi-Fi Easy Connect, CableLabs, OCF) Physical Architecture	5.3 ビルド2（Wi-Fi Easy Connect、CableLabs、OCF）物理アーキテクチャ
5.4 Build 3 (BRSKI, Sandelman Soware Works) Physical Architecture	5.4 ビルド 3 (BRSKI、Sandelman Soware Works) 物理アーキテクチャ
5.5 Build 4 (Thread, Silicon Labs, Kudelski IoT) Physical Architecture	5.5 ビルド 4 (Thread、Silicon Labs、Kudelski IoT) 物理アーキテクチャ
5.6 Build 5 (BRSKI, NquiringMinds) Physical Architecture	5.6 ビルド 5 (BRSKI、NquiringMinds) 物理アーキテクチャ
6 General Findings	6 一般的な所見
6.1 Wi-Fi Easy Connect	6.1 Wi-Fi Easy Connect
6.2 BRSKI	6.2 BRSKI
6.3 Thread	6.3 Thread
6.4 Applicaon-Layer Onboarding	6.4 アプリケーション層オンボーディング
7 Addional Build Consideraons	7 追加の構築上の考慮事項
7.1 Network Authencaon	7.1 ネットワーク認証
7.2 Device Communicaons Intent	7.2 デバイス通信意図
7.3 Network Segmentaon	7.3 ネットワークセグメンテーション
7.4 Integraon with a Lifecycle Management Service	7.4 ライフサイクル管理サービスとの統合
7.5 Network Credenal Renewal	7.5 ネットワーク認証情報の更新
7.6 Integraon with Supply Chain Management Tools	7.6 サプライチェーン管理ツールとの統合
7.7 Atestaon	7.7 認証
7.8 Mutual Atestaon	7.8 相互認証
7.9 Behavioral Analysis	7.9 行動分析
7.10 Device Trustworthiness Scale	7.10 デバイス信頼性尺度
7.11 Resource Constrained Systems	7.11 リソース制約システム
8 References	8 参考文献
Appendix A	附属書A 略語一覧
Appendix B	附属書B 用語集
Appendix C Build 1 (Wi-Fi Easy Connect, Aruba/HPE)	附属書C ビルド1（Wi-Fiイージーコネクト、Aruba/HPE）
C.1 Technologies	C.1 技術
C.2 Build 1 Architecture	C.2 ビルド 1 アーキテクチャ
Appendix D Build 2 (Wi-Fi Easy Connect, CableLabs, OCF)	附属書D ビルド2（Wi-Fiイージーコネクト、ケーブルラボズ、OCF）
D.1 Technologies	D.1 技術
D.2 Build 2 Architecture	D.2 ビルド 2 アーキテクチャ
Appendix E Build 3 (BRSKI, Sandelman Soware Works)	附属書 E ビルド 3 (BRSKI, Sandelman Soware Works)
E.1 Technologies	E.1 採用技術
E.2 Build 3 Architecture	E.2 ビルド 3 アーキテクチャ
Appendix F Build 4 (Thread, Silicon Labs-Thread, Kudelski KeySTREAM)	附属書F ビルド 4 (Thread、Silicon Labs-Thread、Kudelski KeySTREAM)
F.1 Technologies	F.1 技術
F.2 Build 4 Architecture	F.2 ビルド4 アーキテクチャ
Appendix G Build 5 (BRSKI over Wi-Fi, NquiringMinds)	附属書G ビルド 5 (BRSKI over Wi-Fi、NquiringMinds)
G.1 Technologies	G.1 技術
G.2 Build 5 Architecture	G.2 ビルド5 アーキテクチャ
Appendix H Factory Provisioning Process	附属書H 工場出荷時プロビジョニングプロセス
H.1 Factory Provisioning Process	H.1 工場出荷時プロビジョニングプロセス
H.2 Factory Provisioning Builds – General Provisioning Process	H.2 工場プロビジョニング構築 – 一般的なプロビジョニングプロセス
H.3 BRSKI Factory Provisioning Builds (NquiringMinds and SEALSQ)	H.3 BRSKIファクトリプロビジョニングビルド（NquiringMindsおよびSEALSQ）
H.4 Wi-Fi Easy Connect Factory Provisioning Build (SEALSQ and Aruba/HPE)	H.4 Wi-Fi Easy Connect ファクトリー・プロビジョニング・ビルド（SEALSQ および Aruba/HPE）
SP1800-36 Volume C: How-To Guides	SP1800-36C： ハウツーガイド
1 Introduction	1 序論
1.1 How to Use This Guide	1.1 本ガイドの使用方法
1.2 Build Overview	1.2 構築の概要
1.3 Typographic Conventions	1.3 表記規則
2 Build 1 (Wi-Fi Easy Connect, Aruba/HPE)	2 ビルド 1 (Wi-Fi Easy Connect、Aruba/HPE)
2.1 Aruba Central/Hewlett Packard Enterprise (HPE) Cloud	2.1 Aruba Central/Hewlett Packard Enterprise (HPE) Cloud
2.2 Aruba Wireless Access Point	2.2 Aruba ワイヤレスアクセスポイント
2.3 Cisco Catalyst 3850-S Switch	2.3 Cisco Catalyst 3850-S スイッチ
2.4 Aruba User Experience Insight (UXI) Sensor	2.4 Aruba User Experience Insight (UXI) センサー
2.5 Raspberry Pi	2.5 ラズベリーパイ
2.6 Certificate Authority	2.6 認証機関
2.7 UXI Cloud	2.7 UXI Cloud
2.8 Wi-Fi Easy Connect Factory Provisioning Build	2.8 Wi-Fi Easy Connect ファクトリープロビジョニング構築
3 Build 2 (Wi-Fi Easy Connect, CableLabs, OCF)	3 ビルド 2 (Wi-Fi Easy Connect、CableLabs、OCF)
3.1 CableLabs Platform Controller	3.1 CableLabsプラットフォームコントローラー
3.2 CableLabs Custom Connectivity Gateway	3.2 CableLabsカスタム接続ゲートウェイ
3.3 Reference Clients/IoT Devices	3.3 リファレンスクライアント／IoTデバイス
4 Build 3 (BRSKI, Sandelman Software Works)	4 ビルド 3 (BRSKI、Sandelman Software Works)
4.1 Onboarding Router/Join Proxy	4.1 オンボーディングルーター／参加プロキシ
4.2 Minerva Join Registrar Coordinator	4.2 Minerva Join レジストラコーディネーター
4.3 Reach Pledge Simulator	4.3 Reach Pledge Simulator
4.4 Serial Console Server	4.4 シリアルコンソールサーバー
4.5 Minerva Highway MASA Server	4.5 ミネルバ・ハイウェイ MASA サーバー
5 Build 4 (Thread, Silicon Labs, Kudelski IoT)	5 ビルド 4 (Thread、Silicon Labs、Kudelski IoT)
5.1 Open Thread Border Router (OTBR)	5.1 Open Thread Border Router (OTBR)
5.2 Silicon Labs Dev Kit (BRD2601A)	5.2 Silicon Labs開発キット（BRD2601A）
5.3 Kudelski keySTREAM Service	5.3 Kudelski keySTREAM サービス
5.4 AWS IoT Core	5.4 AWS IoT Core
6 Build 5 (BRSKI over Wi-Fi, NquiringMinds)	6 ビルド 5 (BRSKI over Wi-Fi、NquiringMinds)
6.1 Pledge	6.1 プレッジ
6.2 Router and Logical Services	6.2 ルーターと論理サービス
6.3 Onboarding Demonstration	6.3 オンボーディングデモ
6.4 BRSKI Factory Provisioning Build	6.4 BRSKI ファクトリプロビジョニングビルド
Appendix A	附属書A 略語一覧
Appendix B	附属書B 参考文献
SP1800-36 Volume D: Functional Demonstrations	SP1800-36D： 機能実証
1 Introduction	1 序論
1.1 How to Use This Guide	1.1 本ガイドの使用方法
1.2 Typographic Conventions	1.2 表記規則
2 Functional Demonstration Playbook	2 機能実証プレイブック
2.1 Scenario 0: Factory Provisioning	2.1 シナリオ 0: 工場プロビジョニング
2.2 Scenario 1: Trusted Network-Layer Onboarding	2.2 シナリオ 1: 信頼されたネットワーク層オンボーディング
2.3 Scenario 2: Trusted Application-Layer Onboarding	2.3 シナリオ 2: 信頼されたアプリケーション層オンボーディング
2.4 Scenario 3: Re-Onboarding a Device	2.4 シナリオ 3: デバイスの再オンボーディング
2.5 Scenario 4: Ongoing Device Validation	2.5 シナリオ 4: デバイスの継続的妥当性確認
2.6 Scenario 5: Establishment and Maintenance of Credential and Device Security Posture Throughout the Lifecycle	2.6 シナリオ 5：ライフサイクル全体における認証情報とデバイスのセキュリティ態勢の確立と保守
3 Functional Demonstration Results	3 機能実証結果
3.1 Build 1 Demonstration Results	3.1 ビルド1の実証結果
3.2 Build 2 Demonstration Results	3.2 ビルド 2 の実証結果
3.3 Build 3 Demonstration Results	3.3 ビルド 3 の実証結果
3.4 Build 4 Demonstration Results	3.4 ビルド 4 の実証結果
3.5 Build 5 Demonstration Results	3.5 ビルド 5 の実証結果
Appendix A	附属書A 参考文献
SP1800-36 Volume E: Risk and Compliance Management	SP1800-36E： リスク及びコンプライアンス管理
1 Introduction	1 序論
1.1 How to Use This Guide	1.1 本ガイドの使用方法
1.2 Typographic Conventions	1.2 表記規則
2 Risks Addressed by Trusted Network-Layer Onboarding and Lifecycle Management	2 信頼できるネットワーク層オンボーディングとライフサイクル管理が対処するリスク
2.1 Risks to the Network	2.1 ネットワークに対するリスク
2.2 Risks to the Device	2.2 デバイスに対するリスク
2.3 Risks to Secure Lifecycle Management	2.3 セキュアなライフサイクル管理に対するリスク
2.4 Limitations and Dependencies of Trusted Onboarding	2.4 信頼できるオンボーディングの制限と依存性
3 Mapping Use Cases, Approach, and Terminology	3 マッピングのユースケース、アプローチ、および用語
3.1 Uses for Mappings of Build Functions to CSF 2.0 and SP 800-53	3.1 CSF 2.0 および SP 800-53 への構築機能マッピングの用途
3.2 Mapping Producers	3.2 マッピング作成者
3.3 Mapping Approach	3.3 マッピング手法
4. Mapping	4. マッピング
4.1 NIST CSF Subcategory Mappings	4.1 NIST CSFサブカテゴリー対応表
4.2 NIST SP 800-53 Control Mappings	4.2 NIST SP 800-53 コントロール対応表
5 References	5 参考文献

---

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

・2025.12.12 米国 NIST CSWP 42 IoTセキュリティの自動化に向けて：信頼できるネットワーク層オンボーディングの実装 (2025.11.25)

・2025.12.09 米国 NIST IR 8350 信頼できるIoTデバイスのネットワーク層オンボーディングにおける基礎概念：インターネットプロトコルベースのIoTデバイスとネットワークのセキュリティ強化 (2025.11.25)

・2024.06.08 米国 NIST SP 1800-36 (初期公開ドラフト) 信頼できるIoT機器のネットワーク層の実装とライフサイクル管理：インターネットプロトコルベースのIoT機器とネットワークのセキュリティ強化

・2023.11.03 NIST SP 1800-36 (初期ドラフト第2版) 信頼できるIoT機器のネットワーク層の実装とライフサイクル管理：インターネットプロトコルベースのIoT機器とネットワークのセキュリティ強化 (B,C,E)

・2023.09.30 NIST SP 1800-36 (初期ドラフト第2版) 信頼できるIoT機器のネットワーク層オンボーディングとライフサイクル管理：インターネットプロトコルベースのIoT機器とネットワークのセキュリティ強化 (A,D)

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

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

米国 カリフォルニア州消費者プライバシー法 2018年の2026年1月1日改正

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

カリフォルニア州の改正版消費者プライバシー法2018年が2026年1月1日（一部は2027年1月1日）から施行されますね...

AIの進歩、子どものプライバシー保護の強化、実効性の強化等が背景にあるのでしょうかね...

主な改正内容...

・オプトアウト優先シグナル

ブラウザ開発者は、ユーザーが個人情報の販売または共有をオプトアウトできる「オプトアウト優先シグナル」を送信する、明確で見つけやすい設定を提供しなければならない。（ブラウザ機能要件については2027年1月1日より施行）

・機微な個人情報の定義の拡大

• 16歳未満と事業者が実際に知っている消費者の個人情報すべて
• 神経データ(neural data)も機密情報に追加

・第三者データ移転に関する契約要件

事業者は、消費者データを受け取るすべての第三者、サービスプロバイダー、または契約者と契約を締結しなければならない。（契約では、情報移転が限定された目的でのみ行われることを明記し、受領者に法律で要求される同等のプライバシー保護を提供する義務を課す）

・オプトアウト確認の義務化

消費者が個人情報の販売または共有をオプトアウトする要求を行った場合、事業者はその要求が処理されたことの確認を提供しなければならない

・開示義務の拡大

• プライバシーポリシーへのリンクを、ホームページだけでなく個人情報を収集するすべてのウェブページに設置
• 事業者は、収集時またはその前に、個人情報カテゴリーが販売または共有されるかどうかを開示しなければならない

・ダークパターンの禁止例の追加

• 消費者がデータを削除することを困難、誤解を招く、または混乱させる濫用的慣行を対象

・ 消費者の権利の明確化

• データへのアクセス、削除、訂正の権利を維持
• 事業者は検証可能な消費者要求に45日以内に応答し、合理的に必要な場合は45日間の延長が可能
• アクセス要求への応答期間が過去12ヶ月の制限を超えて拡大

新規追加...

・サイバーセキュリティ監査要件(2027.01.01以降)

・・対象企業:

• 前暦年収益の50%以上を個人情報の販売・共有から得ている事業者
• 年間総収益が2,500万ドル超で、かつ25万人以上の消費者の個人情報を処理、または5万人以上の機密な個人情報を処理する事業者

・・監査期限(企業収益別):

• 1億ドル超:2028.04.01
• 5,000万~1億ドル:2029.04.01
• 5,000万ドル未満:2030.04.01

・リスク評価要件

個人情報処理が消費者の「重大なプライバシーリスク」を伴う場合、事業者はリスク評価をしなければならない

・・重大なプライバシーリスク

• 個人情報の販売・共有
• 機微な小書院情報の処理
• 一定の条件の元での自動意思決定技術 (ADMT) の使用

・自動意思決定技術(ADMT)規制(2027.01.01日施行)

• 消費者に関する「重要な決定」を行うためにADMTを使用する企業は、事前通知、オプトアウト権、アクセス権を提供しなければならない 
• ADMTの動作方法、決定への影響、代替プロセスの説明義務

● California Privacy Protection Agency

・[PDF] CALIFORNIA CONSUMER PRIVACY ACTOF 2018 effective 01/01/2026 – AB 137, AB 566 

・[DOCX][PDF] 仮訳

参考

モバイル広告IDとオプトアウト・プラットフォーム（DROP） について

・2025.12.02 Understanding Mobile Advertising IDs and DROP

2020年のものですが、個人情報保護委員会の訳

● 個人情報保護委員会

・[PDF]「カリフォルニア州消費者プライバシー法 2018年」2020年1月1日施行版の仮日本語訳

同法施行前の米国カリフォルニア州議会上院及び下院による修正決議（上院2018年法律第1121号、下院2019年法律第25号、同2019年法律第874号、同2019年法律第1146号、同2019年法律第1355号及び同2019年法律第1564号）の修正条項を反映したもの

牛島総合法律事務所が簡単な改正の記事をかいていますね...

● 牛島総合法律事務所

・2025.11.17 2025年におけるCCPA（カリフォルニア州消費者プライバシー法）及びCCPA規則の改正

米国 FBI/IC3 SNSにアップされた写真を改変した仮想誘拐詐欺についての警告 (2025.12.05)

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

FBIが、SNSにアップされた写真を利用し、仮想誘拐詐欺事件で身代金請求時の生存証明に利用しているようです...犯罪者もいろいろと考えますね...生成的AIの発展により犯罪も幅がひろがりますね...

● IC3

・2025.12.05 Criminals Using Altered Proof-of-Life Media to Extort Victims in Virtual Kidnapping for Ransom Scams (I-120525-PSA)

Criminals Using Altered Proof-of-Life Media to Extort Victims in Virtual Kidnapping for Ransom Scams	犯罪者が改変した生存証明メディアを悪用し、仮想誘拐による身代金詐欺で被害者を脅迫
The Federal Bureau of Investigation (FBI) warns the public about criminals altering photos found on social media or other publicly available sites to use as fake proof of life photos in virtual kidnapping for ransom scams. The criminal actors pose as kidnappers and provide seemingly real photos or videos of victims along with demands for ransom payments.	連邦捜査局（FBI）は、犯罪者がソーシャルメディアやその他の公開サイトから入手した写真を改変し、仮想誘拐による身代金詐欺で偽の生存証明写真として使用していることを一般に警告している。犯罪者は誘拐犯を装い、被害者の本物らしき写真や動画と共に身代金の支払いを要求する。
The Scam	詐欺の手口
Criminal actors typically will contact their victims through text message claiming they have kidnapped their loved one and demand a ransom be paid for their release. Oftentimes, the criminal actor will express significant claims of violence towards the loved one if the ransom is not paid immediately. The criminal actor will then send what appears to be a genuine photo or video of the victim’s loved one, which upon close inspection often reveals inaccuracies when compared to confirmed photos of the loved one. Examples of these inaccuracies include missing tattoos or scars and inaccurate body proportions. Criminal actors will sometimes purposefully send these photos using timed message features to limit the amount of time victims have to analyze the images.	犯罪者は通常、被害者に「身内を誘拐した」とテキストメッセージで連絡し、解放のための身代金を要求する。身代金が即座に支払われない場合、身内への深刻な暴力をほのめかすことも多い。その後、犯罪者は被害者の身内を装った本物らしき写真や動画を送信するが、よく見ると身内の確認済み写真と比べて不自然な点が多い。不一致の例としては、タトゥーや傷跡の欠如、体のプロポーションの不自然さなどが挙げられる。犯罪者は意図的にタイムスタンプ付きメッセージ機能を使い、被害者が画像を分析する時間を制限する場合もある。
Tips to Protect Yourself	身を守るためのヒント
・When posting missing person information online, be mindful that scammers may contact you with fake information regarding your loved one.	・オンラインで行方不明者の情報を投稿する際は、詐欺師が偽の家族情報を用いて連絡してくる可能性があることに注意せよ。
・Avoid providing personal information to strangers while traveling.	・旅行中は見知らぬ人に個人情報を提供しないこと。
・Establish a code word only you or your loved ones know that you can use to communicate.	・あなたや家族だけが知る合言葉を決めて、連絡手段として使うこと。
・Scammers portray a false sense of urgency. Stop and think; do the kidnapper’s claims make sense?	・詐欺師は偽の緊急性を演出する。立ち止まって考えよ。誘拐犯の主張は理にかなっているか？
・Screenshot or record proof of life photos whenever possible.	・可能な限り生存証明写真をスクリーンショットまたは録画すること。
・Always attempt to contact your loved one before considering paying any ransom demand.	・身代金要求に応じる前に、必ずまず身内と直接連絡を取ろう。
Report It	通報する
If you believe you have been a victim of a virtual kidnapping scam, please report the incident to the FBI's Internet Crime Complaint Center at www.ic3.gov. Be sure to submit as much information as possible about the interaction including phone numbers, payment information, text and audio communications, and proof of life photos.	仮想誘拐詐欺の被害に遭ったと思われる場合は、FBIのインターネット犯罪苦情センター（www.ic3.gov）にインシデントを通報してください。電話番号、支払い情報、テキストや音声によるコミュニケーション記録、生存証明写真など、やり取りに関する可能な限りの情報を提出するようにしてください。

 

米国 NIST IR 8350 信頼できるIoTデバイスのネットワーク層オンボーディングにおける基礎概念：インターネットプロトコルベースのIoTデバイスとネットワークのセキュリティ強化 (2025.11.25)

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

米国のNISTが信頼できるIoTデバイスの信頼できるネットワーク層オンボーディングについて定義していますね...

IRですが、参考になる部分は多くありますね...

● NIST - ITL

・2025.11.25 NIST IR 8350 Foundational Concepts in Trusted IoT Device Network-Layer Onboarding: Enhancing Internet Protocol-Based IoT Device and Network Securit

NIST IR 8350 Foundational Concepts in Trusted IoT Device Network-Layer Onboarding: Enhancing Internet Protocol-Based IoT Device and Network Securit	NIST IR 8350 信頼できるIoTデバイスのネットワーク層オンボーディングにおける基礎概念：インターネットプロトコルベースのIoTデバイスとネットワークのセキュリティ強化
Abstract	要約
Internet of Things (IoT) devices are typically connected to a network. The steps performed to provision a device with its network credentials are referred to as network-layer onboarding (or simply, onboarding, assuming the network-layer context is understood). This paper proposes a definition for trusted network-layer onboarding. This paper is intended to introduce the reader to trusted network-layer onboarding; describe its capabilities, characteristics, and benefits; and explain the important role that onboarding can play in the protection of IoT devices and networks throughout the device lifecycle. By providing a common language that describes and clarifies various onboarding capabilities, this paper assists with discussion, characterization, and development of trusted onboarding solutions. This paper also describes a generic trusted onboarding process, defines onboarding functional roles and responsibilities, discusses onboarding-related aspects of IoT device lifecycle management, and explains how onboarding can enhance security capabilities that protect the device throughout its lifecycle.	IoTデバイスは通常、ネットワークに接続される。デバイスにネットワーク認証情報を付与する手順は、ネットワーク層オンボーディング（あるいは単にオンボーディング、ネットワーク層の文脈が理解されていると仮定する場合）と呼ばれる。本論文は、信頼できるネットワーク層オンボーディングの定義を提案する。本論文は、信頼できるネットワーク層オンボーディングを読者に紹介し、その機能、特性、利点を説明し、デバイスのライフサイクル全体を通じてIoTデバイスとネットワークの防御においてオンボーディングが果たす重要な役割を解説することを目的とする。様々なオンボーディング機能を記述・明確化する共通言語を提供することで、本稿は信頼できるオンボーディングソリューションの議論、特性化、開発を支援する。また、汎用的な信頼できるオンボーディングプロセスを説明し、オンボーディングの機能的役割と責任を定義し、IoTデバイスライフサイクル管理におけるオンボーディング関連の側面を議論し、オンボーディングがデバイスのライフサイクル全体を通じて保護するセキュリティ機能を強化する方法を説明する。

・[PDF] 

・[DOCX][PDF] 仮訳

図1 – オンボーディング概念の全体概要

図5 – オンボーディング視点からのIoTデバイスライフサイクルにおける上市前段階