米国 NIST CSWP 40（初期公開ドラフト） NISTプライバシー枠組み 1.1 (2025.04.14)

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

NISTが、CSWP 40（初期公開ドラフト） NISTプライバシー枠組み 1.1 を公表し、意見募集をしていますね...

● NIST - ITL

・NIST CSWP 40 (Initial Public Draft) NIST Privacy Framework 1.1

NIST CSWP 40 (Initial Public Draft) NIST Privacy Framework 1.1	NIST CSWP 40（初期公開ドラフト） NISTプライバシー枠組み 1.1
Announcement	発表
The NIST Privacy Framework is a “living” tool meant to evolve to meet stakeholder needs, and the time has come to update to Version 1.1. This update builds on the success of Privacy Framework 1.0 by responding to current privacy risk management needs, realigning with NIST Cybersecurity Framework (CSF) 2.0, and enhancing usability.	NISTプライバシーフレームワークは、ステークホルダーのニーズに応えるべく進化する「生きた」ツールであり、バージョン1.1への更新の時期が到来した。今回の更新は、プライバシーリスクマネジメントの現在のニーズへの対応、NISTサイバーセキュリティフレームワーク（CSF）2.0との再調整、およびユーザビリティの向上により、プライバシーフレームワーク1.0の成功を基盤としている。
The following resources are included with the Privacy Framework 1.1 IPD release:	プライバシーフレームワーク1.1 IPDリリースには、以下のリソースが含まれている。
・Privacy Framework 1.1 IPD Highlights video that summarizes the development process and reviews key updates	・開発プロセスを要約し、主な更新内容をレビューする「プライバシーフレームワーク1.1 IPDハイライト」ビデオ
・Mapping of Privacy Framework 1.0 Core to Privacy Framework 1.1 Core to help organizations trace changes to Core Categories and Subcategories between Framework versions	・フレームワークのバージョン間でコアカテゴリーおよびサブカテゴリーの変更点を追跡するのに役立つ「プライバシーフレームワーク1.0コアからプライバシーフレームワーク1.1コアへのマッピング
NIST welcomes stakeholder feedback on the Privacy Framework 1.1 IPD by June 13, 2025.	NISTは、2025年6月13日までにプライバシーフレームワーク1.1 IPDに関する利害関係者のフィードバックを歓迎する。
Abstract	要約
The NIST Privacy Framework 1.1 is a voluntary tool developed in collaboration with stakeholders intended to help organizations identify and manage privacy risk to build innovative products and services while protecting individuals’ privacy. It provides high-level privacy risk management outcomes that can be used by any organization to better understand, assess, prioritize, and communicate its privacy activities. This document introduces the Privacy Framework and privacy risk management practices, highlights the Framework’s basic elements, and offers examples of how it can be used.	NISTプライバシーフレームワーク1.1は、ステークホルダーとの協働により開発された自主的なツールであり、個人のプライバシーを防御しながら革新的な製品やサービスを構築するために、組織がプライバシーリスクを識別および管理することを支援することを目的としている。このフレームワークは、プライバシー活動の理解、アセスメント、優先順位付け、およびコミュニケーションを改善するために、あらゆる組織が利用できるプライバシーリスクマネジメントの成果を提供する。本書では、プライバシーフレームワークとプライバシーリスクマネジメントの実践を紹介し、フレームワークの基本要素を強調し、その使用方法の例を示す。

・[PDF] CSWP.40.ipd

目次の図表一覧

Executive Summary	エグゼクティブサマリー
1. Privacy Framework Introduction	1. プライバシー枠組みの序文
1.1. Overview of the Privacy Framework	1.1. プライバシー枠組みの概要
1.2. Privacy Risk Management	1.2. プライバシーリスクマネジメント
1.2.1. Cybersecurity and Privacy Risk Management	1.2.1. サイバーセキュリティとプライバシーリスクマネジメント
1.2.2. Artificial Intelligence and Privacy Risk Management	1.2.2. 人工知能とプライバシーリスクマネジメント
1.2.3. Privacy Risk Assessment	1.2.3. プライバシーリスクアセスメント
1.3. Document Overview	1.3. 文書概要
2. Privacy Framework Basics	2. プライバシー枠組みの基本
2.1. Core	2.1. コア
2.2. Profiles	2.2. プロファイル
2.3. Tiers	2.3. ティア
3. How to Use the Privacy Framework	3. プライバシーフレームワークの利用方法
References	参考文献
Appendix A. Privacy Framework Core	附属書 A. プライバシーフレームワークのコア
Appendix B. Glossary	附属書 B. 用語集
Appendix C. Acronyms	附属書 C. 略語
Appendix D. Privacy Risk Management Practices	附属書 D. プライバシーリスクマネジメントの実践
Appendix E. Tiers Definitions.	附属書 E. ティアの定義
List of Tables	表の一覧
Table 1: Privacy Framework 1.1 Function and Category Unique Identifiers	表 1: プライバシーフレームワーク 1.1 機能とカテゴリー 固有の識別子
Table 2: Privacy Framework Core	表 2: プライバシーフレームワークのコア
Table 3: Privacy Engineering and Security Objectives	表 3: プライバシーエンジニアリングとセキュリティの目標
List of Figures	図の一覧
Figure 1: Core, Organizational Profiles, and Tiers	図1：コア、組織プロファイル、およびティア
Figure 2: Cybersecurity and Privacy Risk Relationship	図2：サイバーセキュリティとプライバシーリスクの関係
Figure 3: Relationship Between Privacy Risk and Enterprise Risk	図3：プライバシーリスクとエンタープライズリスクの関係
Figure 4: Privacy Framework Core Structure	図4：プライバシー枠組みのコア構造
Figure 5: Relationship Between Core and Profiles	図5：コアとプロファイルの関係
Figure 6: Privacy Framework Tiers	図6：プライバシー枠組みのティア

Executive Summary	エグゼクティブサマリー
For more than two decades, the Internet and associated information technologies have driven unprecedented innovation, economic value, and improvement in social services. Many of these benefits are fueled by data about individuals that flow through a complex ecosystem. As a result, individuals may not realize the potential consequences for their privacy as they interact with systems, products, and services. At the same time, organizations may not realize the full extent of these consequences for individuals, for society, or for their enterprises, which can affect their brands, their finances, and their future prospects for growth.	インターネットと関連情報技術は、過去20年以上にわたり、かつてない革新、経済的価値、社会サービスの改善を推進してきた。これらの恩恵の多くは、複雑なエコシステムを通じて流れる個人に関するデータによってもたらされている。その結果、個人にとっては、システム、製品、サービスとやりとりする際に、プライバシーに潜在する影響について認識していない可能性がある。同時に、組織は、個人、社会、またはエンタープライズに及ぼす影響の全容を把握していない可能性があり、それはブランド、財務、および将来の成長見通しに影響を及ぼす可能性がある。
Following a transparent, consensus-based process including both private and public stakeholders, the National Institute of Standards and Technology (NIST) has updated the Privacy Framework to Version 1.1 (Privacy Framework 1.1), to meet stakeholder privacy risk management needs, maintain alignment with the NIST Cybersecurity Framework 2.0	国立標準技術研究所（NIST）は、民間および公共の利害関係者を含む透明性のある合意に基づくプロセスを経て、プライバシーフレームワークをバージョン1.1（プライバシーフレームワーク1.1）に更新した。これは、利害関係者のプライバシーリスクマネジメントのニーズに応えるとともに、NISTサイバーセキュリティフレームワーク2.0（
(Cybersecurity Framework or CSF 2.0), and provide information on artificial intelligence (AI) and privacy risk management. Privacy Framework 1.1 updates include:	（サイバーセキュリティ枠組みまたは CSF 2.0）との整合性を維持し、人工知能（AI）とプライバシーリスクマネジメントに関する情報を提供することを目的としている。プライバシー枠組み 1.1 の更新内容は以下の通りである。
• Targeted revisions and restructuring of the Core	• コアの改訂と再構成
• A new Section (1.2.2) on AI and privacy risk management	• AI とプライバシーリスクマネジメントに関する新しいセクション（1.2.2）
• Relocation of Section 3 guidelines from front matter to the NIST Privacy Framework website[1]	• 第 3 項のガイドラインを前文から NIST プライバシー枠組みウェブサイト[1] に移行
The Privacy Framework can support organizations in:	プライバシー・フレームワークは、以下のような形で組織を支援することができる。
• Building customers’ trust by supporting ethical decision-making in product and service design or deployment that optimizes beneficial uses of data while minimizing adverse consequences for individuals’ privacy and society as a whole;[2]	• 個人プライバシーや社会全体に及ぼす悪影響を最小限に抑えつつ、データの有益な利用を最適化する製品やサービスの設計や展開における倫理的な意思決定を支援することで、顧客の信頼を構築する。[2]
• Fulfilling current compliance obligations, as well as future-proofing products and services to meet these obligations in a changing technological and policy environment; and	• 現在のコンプライアンス義務を満たし、また、技術や政策環境の変化に応じて、これらの義務を満たすための製品やサービスを将来にわたって保証する。
• Facilitating communication about privacy practices with individuals, business partners, assessors, and regulators.	• 個人、ビジネスパートナー、評価者、規制当局とのプライバシー慣行に関するコミュニケーションを促進する。
Deriving benefits from data while simultaneously managing risks to individuals’ privacy is not well-suited to one-size-fits-all solutions. Like building a house, where homeowners make layout and design choices while relying on a well-engineered foundation, privacy protection should allow for individual choices, as long as effective privacy risk mitigations are already engineered into products and services. The Privacy Framework—through a risk- and outcome-based approach—is flexible enough to address diverse privacy needs, enable more innovative and effective solutions that can lead to better outcomes for individuals and organizations, and stay current with technology trends.	データから利益を引き出すと同時に、個人のプライバシーに対するリスクを管理することは、画一的なソリューションには適していない。住宅建設と同様に、住宅所有者が設計やレイアウトを選択する際に、しっかりと設計された基礎に頼るように、プライバシー保護は、効果的なプライバシーリスク緩和策がすでに製品やサービスに組み込まれている限り、個人の選択を可能にするべきである。プライバシーフレームワークは、リスクおよび成果に基づくアプローチにより、多様なプライバシーニーズに対応できる柔軟性を備え、個人および組織により良い成果をもたらすより革新的で効果的なソリューションを実現し、テクノロジーのトレンドに追随することができる。
Privacy Framework 1.1 follows the structure of CSF 2.0 [1] to facilitate the use of both frameworks together. Like the Cybersecurity Framework, the Privacy Framework is composed of three components: Core, Organizational Profiles, and Tiers. Each component reinforces privacy risk management through the connection between business and mission drivers, organizational roles and responsibilities, and privacy protection activities.	プライバシーフレームワーク1.1は、CSF 2.0 [1] の構造に従っており、両方のフレームワークを併用しやすくしている。プライバシー枠組みは、サイバーセキュリティ枠組みと同様に、コア、組織プロファイル、ティアの3つの要素で構成されている。各要素は、ビジネスとミッション推進要因、組織の役割と責任、プライバシー保護活動の関連性を通じて、プライバシーリスクマネジメントを強化する。
• The Core enables a dialogue—from the executive level to the implementation/operations level—about important privacy protection activities and desired outcomes.	• コアは、経営レベルから実装/運用レベルまで、重要なプライバシー保護活動と期待される成果について対話することを可能にする。
• Organizational Profiles enable the prioritization of the outcomes and activities that best meet organizational privacy values, mission or business needs, and risks.	• 組織プロファイルは、組織のプライバシー価値、ミッション、ビジネスニーズ、リスクに最も適した成果と活動の優先順位付けを可能にする。
• Tiers support decision-making and communication about the sufficiency of organizational processes and resources to manage privacy risk.	• プライバシーリスクを管理するための組織プロセスとリソースの十分性に関する意思決定とコミュニケーションを支援する。
In summary, the Privacy Framework is intended to help organizations build better privacy foundations by bringing privacy risk into parity with their broader enterprise risk portfolio.	まとめると、プライバシーフレームワークは、プライバシーリスクをより広範なエンタープライズリスクポートフォリオと同等に扱うことで、組織がより優れたプライバシー基盤を構築するのを支援することを目的としている。
[1] For more information on using the Privacy Framework 1.1, visit https://www.nist.gov/privacy-framework/using-privacy-framework-11.	[1] プライバシー枠組み1.1の使用に関する詳細情報については、https://www.nist.gov/privacy-framework/using-privacy-framework-11を参照のこと。
[2] There is no objective standard for ethical decision-making; it is grounded in the norms, values, and legal expectations in a given society.	[2] 倫理的な意思決定のための客観的な標準は存在しない。それは、特定の社会における規範、価値観、法的期待に基づいている。

追加情報

 Comment Template

 Privacy Framework homepage

 Guide for Using NIST PF 1.1

---

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

・2025.03.10 米国 NIST IR 8286 Rev. 1（初期公開草案） サイバーセキュリティとエンタープライズリスクマネジメント（ERM）の統合他 (2025.02.26)

・2024.12.26 米国 NIST IR 8467 (第２次公開ドラフト) ゲノムデータのサイバーセキュリティとプライバシーフレームワーク コミュニティプロファイル (2024.12.16)

・2024.11.14 米国 NIST CSWP 34（初公開ドラフト）テレヘルス・スマートホーム統合におけるサイバーセキュリティとプライバシーリスクの低減： ヘルスケア及び公衆衛生部門のリスクマネジメントのアプローチ

・2024.05.24 米国 NIST SP 800-229 2023会計年度サイバーセキュリティとプライバシー年次報告書

・2024.03.07 米国 NSIT サイバーセキュリティ・フレームワーク（CSF）2.0 関連 SP 1299, 1300, 1301, 1302, 1303, 1305 (2024.02.26)

・2024.03.06 米国 NIST CSWP 32（初期公開ドラフト）サイバーセキュリティフレームワーク 2.0： コミュニティプロファイル作成ガイド (2024.02.26)

・2024.01.28 米国 NIST Privacy Framework 1.1への改定に向けて活動を開始...

・2023.08.19 米国 NIST IR 8477（初公開ドラフト）：文書標準、規制、フレームワーク、ガイドライン間の関係をマッピングする： サイバーセキュリティとプライバシーの概念マッピングの開発

・2023.08.19 米国 NIST サイバーセキュリティフレームワーク 2.0リファレンスツール

欧州委員会 汎用AI実践規範の第3ドラフトを発表 (2025.03.11)

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

欧州委員会が、汎用AI実践規範の第３ドラフトを発表しています...

第2ドラフトで持ち込んだKPIをひっこめましたね...

そしてテーマごとに４分冊になりました...

最初のドラフトの発表が11.14、第2ドラフトの発表が12.19ですね...2025年5月までに、汎用AI実践規範を完成する必要がありますので、これから作業がどんどん進んでいくのでしょうね...

● European Commission - General-Purpose AI Code of Practice

・2025.03.11 Third Draft of the General-Purpose AI Code of Practice published, written by independent experts

Third Draft of the General-Purpose AI Code of Practice published, written by independent experts	独立専門家による汎用AI実践規範の第3ドラフトが発表された
The Chairs and the Vice-Chairs of the General-Purpose AI Code of Practice present the third draft of the Code.	汎用AI実践規範の議長および副議長が、実践規範の第3ドラフトを発表した。
This kicks off the last drafting round as the Code will be finalised based on stakeholder feedback to this proposal. Compared to the previous two drafts, this version of the Code features a more streamlined structure with refined commitments and measures.	このドラフトは、利害関係者からの本提案に対するフィードバックに基づいて実践規範が最終化されるため、最後のドラフト作成段階の開始となる。前2ドラフトと比較すると、今回の実践規範のバージョンでは、より洗練されたコミットメントと対策により、より合理化された構造となっている。
The draft is based on a concise list of high-level commitments and provides more detailed measures to implement each commitment. These are 2 Commitments related to transparency and copyright for all providers of general-purpose AI models, and further 16 Commitments related to safety and security only for providers of general-purpose AI models classified as general-purpose AI models with systemic risk.	このドラフトは、簡潔なハイレベルのコミットメントのリストに基づいており、各コミットメントを実施するためのより詳細な手段が提示されている。これらは、汎用AIモデルのすべてのプロバイダを対象とした透明性と著作権に関する2つのコミットメント、および、システムリスクのある汎用AIモデルに分類された汎用AIモデルのプロバイダのみを対象とした安全性とセキュリティに関するさらに16のコミットメントである。
The improvements are based on the feedback received on the second draft published on 19 December 2024. Together with the third draft, the Chairs and Vice-Chairs also propose a dedicated executive summary and interactive website. This facilitates stakeholders to provide feedback to the draft in writing and in the upcoming discussions in working groups and dedicated workshops. The final Code should be ready in May, as a tool for general-purpose AI model providers to demonstrate compliance with the AI Act, incorporating state-of-the-art practices.	改善は、2024年12月19日に発表された第2次ドラフトに対するフィードバックに基づいている。第3ドラフトとともに、議長と副議長は、専用のエグゼクティブサマリーとインタラクティブなウェブサイトも提案している。これにより、利害関係者はドラフトに対するフィードバックを書面で提出し、今後のワーキンググループや専用のワークショップでの議論に貢献しやすくなる。最終的な規範は、汎用AIモデルプロバイダがAI法への準拠を実証するためのツールとして、5月までに完成する予定である。この規範は、最先端の慣行を取り入れたものとなる。
Details of the third draft	第3ドラフトの詳細
The first two sections of the draft Code detail transparency and copyright obligations for all providers of general-purpose AI models, with notable exemptions from the transparency obligations for providers of certain open-source models in line with the AI Act. Related to transparency, Chairs have included a user-friendly Model Documentation Form which allows signatories to easily document the necessary information in a single place. The section on copyright contains core measures from the second draft but in a simplified and clearer form.	この規範の最初の2つのセクションでは、汎用AIモデルのすべてのプロバイダに対する透明性と著作権に関する義務について詳細に説明しており、AI法に沿って、特定のオープンソースモデルのプロバイダには透明性に関する義務の適用除外が認められている。透明性に関連して、議長は、署名者が必要な情報を1か所で簡単に文書化できる、ユーザーフレンドリーなモデル文書フォームを盛り込んだ。著作権に関するセクションには、第2ドラフトの主要な対策が盛り込まれているが、より簡潔でわかりやすい形になっている。
The third section of the Code is only relevant for a small number of providers of most advanced general-purpose AI models that could pose systemic risks, in accordance with the classification criteria in Article 51 of the AI Act. Here the Code outlines measures for systemic risk assessment and mitigation, including model evaluations, incident reporting, and cybersecurity obligations.	実践規範の第3章は、AI法第51条の分類規準に従い、システミック・リスクをもたらす可能性のある最も高度な汎用AIモデルを提供するプロバイダの少数のみに関連する。ここでは、実践規範は、モデル評価、インシデント報告、サイバーセキュリティ義務を含む、システミック・リスクのアセスメントと緩和のための措置を概説している。
In light of the evolving state of the art, Chair stress the need to balance clear commitments with the flexibility to adapt as technology evolves, next to the need for further development of ecosystems for AI governance and risk management.	技術の進化を踏まえ、議長は、明確なコミットメントと技術の進化に合わせて適応する柔軟性のバランスを取る必要性を強調し、AIのガバナンスとリスクマネジメントのためのエコシステムのさらなる開発の必要性についても言及した。
Complementary actions by the AI Office/the Commission	AIオフィス/委員会による補完的な行動
In parallel and independently from the Code, regarding the template for an adequate public summary of the training data envisaged in Article 53(1)d) AI Act, the AI Office outlined earlier this year a preliminary approach for its possible content and structure. During the Code of Practice working group, the AI Office will report on the feedback received from stakeholders and outline next steps for the adoption of the template.	実践規範とは並行して独立して、AI法第53条(1)d)項で想定されている訓練データの適切な公開要約のテンプレートに関して、AIオフィスは今年初めにその内容と構造の予備的なアプローチを概説した。実践規範作業部会において、AIオフィスはステークホルダーから得たフィードバックを報告し、テンプレートの採択に向けた次のステップを概説する予定である。
Furthermore, the AI Office is dedicated to ensuring a holistic understanding of the AI Act rules for general-purpose AI, complementing the drawing-up of the Code. Therefore, the AI Office will publish guidance in due time, clarifying the scope of the rules. This can be expected to relate to the definitions of general-purpose AI model, placing of models on the market and provider, including clarifications to responsibilities along the value chain, such as to what extent rules apply to downstream actors modifying or fine-tuning a general-purpose AI model. In addition, the guidance will address the exemption for models provided under free and open-source license, the effects of the AI Act on models placed on the market before August 2025 and possibly other elements of importance for providers to obtain clarity necessary for the future implementation of the rules for general- purpose AI models.	さらに、AIオフィスは、汎用AIに関するAI法の規則について包括的な理解を確保することに専念しており、実践規範の策定を補完する。そのため、AIオフィスは、規則の適用範囲を明確にするガイダンスを適時公表する予定である。これは、汎用AIモデルの定義、モデルの上市およびプロバイダ、バリューチェーンに沿った責任の明確化（汎用AIモデルを修正または微調整する下流の関係者にどの程度規則が適用されるかなど）に関連すると予想される。さらに、ガイダンスでは、フリーおよびオープンソースライセンスで提供されるモデルの適用除外、2025年8月以前に上市されたモデルに対するAI法の影響、および、プロバイダが汎用AIモデルの規則を将来的に実施するために必要な明確性を得るために重要なその他の要素についても取り扱う予定である。
For now, the AI Office provides clarifications in the dedicated Q&A, which has been updated with the third draft of the Code.	現時点では、AIオフィスは、実践規範の第3ドラフトとともに更新された専用Q&Aで明確化を行っている。
Background	背景
Each draft of the Code of Practice is a work in progress and reflects the views of stakeholders participating in the Code of Practice Working Groups and Provider Workshops, consisting of around 1000 stakeholders, including EU Member State representatives and European and international observers.	実践規範の各ドラフトは進行中の作業であり、実践規範ワーキンググループおよびプロバイダワークショップに参加する利害関係者の意見を反映している。実践規範ワーキンググループおよびプロバイダワークショップには、EU加盟国の代表者および欧州および国際的なオブザーバーを含む約1000人の利害関係者が参加している。
Next steps	今後のステップ
In addition to the written feedback received by Sunday, 30 March 2025, Chairs and Vice-Chairs will participate in further discussions in line with the tentative timeline published by the AI Office, which will be updated with specific dates as soon as possible.	2025年3月30日（日）までに受け取った書面によるフィードバックに加え、議長および副議長は、AI事務局が発表した暫定的なスケジュールに沿って、さらなる議論に参加する。このスケジュールは、具体的な日付が判明次第、できるだけ早く更新される予定である。
All stakeholders in the Code of Practice Plenary will have the opportunity to participate in the respective Working Group discussions. Dedicated workshops will be offered to general-purpose AI model providers and Member State representatives in the AI Board Steering Group	実践規範全体会議のすべての利害関係者は、それぞれの作業部会の議論に参加する機会を持つ。汎用AIモデルプロバイダおよびAI理事会運営グループの加盟国代表者向けに、専用のワークショップが提供される。
In addition, the Chairs plan to invite civil society organisations and downstream industry to additional workshops to allow for even more targeted interactions.	さらに、議長らは、市民社会組織および下流産業を追加のワークショップに招待し、よりターゲットを絞った交流を行う予定である。

1 - Commitments　（コミットメント）

・[DOCX][PDF] 仮訳

2 - Transparency　（透明性）

・[DOCX][PDF] 仮訳

3 - Copyright　（著作権）

・[DOCX][PDF] 仮訳

4 - Safety and Security　（安全性とセキュリティ）

・[DOCX][PDF] 仮訳

---

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

・2025.03.13 欧州委員会 AI法における汎用AIモデル - Q&A (2025.03.10)

・2025.02.08 欧州委員会 規則（EU）2024/1689（AI法）が定める人工知能の禁止行為に関する欧州委員会ガイドライン

・2024.12.22 欧州委員会 汎用AI実践規範の第2ドラフトを発表 (2024.12.19)

・2024.12.06 欧州委員会 AI法における汎用AIモデル - Q&A (2024.11.20)

・2024.11.17 欧州委員会 汎用AI実践規範の最初のドラフトを発表 (2024.11.14)

・2024.10.30 欧州 AI法の調和標準の策定について...

・2024.09.08 欧州評議会 AI条約の署名開始... (2024.09.05)

・2024.08.05 欧州AI法が施行された... (2024.08.01)

・2024.07.19 ドイツ BfDI フランス CNIL オランダ AP EU AI法関連

・2024.07.16 EU 2024.07.12にAI法がEU官報に掲載された

・2024.05.22 EU 欧州理事会がAI法を承認...まもなく発効されますね...

・2024.03.19 欧州議会 AI法 (2024.03.13) とサイバーレジリエンス法を採択 (2024.03.12)

・2023.12.10 欧州委員会、欧州議会がAI法について政治的合意

・2022.12.08 EU理事会 AI法に関する見解を採択

・2022.09.30 欧州委員会 AI責任指令案

・2021.12.05 欧州理事会 AI法改正案を欧州議会に提出

・2021.08.08 EU議会 BRIEFING 人工知能法 at 2021.07.26

・2021.04.24 欧州委員会がAIへの規制を提案 → 欧州データ保護官は歓迎するけど、公共空間での遠隔生体認証についての規制も入れてね

米国 NIST SP 800-228（初期公開ドラフト）クラウドネイティブシステムのAPI防御ガイドライ

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

NISTがSP 800-228（初期公開ドラフト）クラウドネイティブシステムのAPI保護ガイドライを公表し、意見募集をしていますね...

組織のシステムがクラウドに移行に、各システムの連携がAPIを通じて行われるようになると、APIをいかに守るかということは開発者にとっても、利用者にとっても重要となりますよね...

● NIST - ITL

・2025.03.25 NIST SP 800-228 (Initial Public Draft) Guidelines for API Protection for Cloud-Native Systems

NIST SP 800-228 (Initial Public Draft) Guidelines for API Protection for Cloud-Native Systems	NIST SP 800-228（初期公開ドラフト）クラウドネイティブシステムのAPI保護ガイドライ
Announcement	発表
Modern enterprise IT systems rely on a family of application programming interfaces (APIs) for integration to support organizational business processes. Hence, a secure development and deployment of APIs is critical for overall enterprise security. This, in turn, requires the identification of risk factors or vulnerabilities in various phases of the API life cycle and the development of controls or protection measures to prevent their exploits.	現代のエンタープライズITシステムは、組織のビジネスプロセスをサポートする統合のために、アプリケーション・プログラミング・インターフェース（API）ファミリーに依存している。したがって、APIの安全な開発と展開は、エンタープライズ全体のセキュリティにとって極めて重要である。そのためには、APIのライフサイクルの様々な段階におけるリスク要因や脆弱性を特定し、その悪用を防ぐための管理策や防御策を開発する必要がある。
This document addresses the following aspects for achieving that goal:	この文書では、その目標を達成するために、次の側面を取り上げる：
a. The identification and analysis of risk factors or vulnerabilities introduced during various activities of API development and runtime,	a. API の開発と実行時の様々な活動中に導入されるリスク要因や脆弱性の特定と分析、
b. Recommended basic and advanced controls and protection measures during the pre-runtime and runtime stages of APIs, and	b. API の実行前と実行時の段階における、推奨される基本的で高度な制御と保護対策、
c. An analysis of the advantages and disadvantages of various implementation options (i.e., patterns) for those controls to enable security practitioners to adopt an incremental, risk-based approach to securing their APIs.	c. セキュリティ担当者が、API の安全性を確保するために、段階的でリスクに基づいたアプローチを採用できるようにするための、 これらの制御の様々な実装オプション（すなわち、パターン）の利点と欠点の分析。
Abstract	概要
Modern enterprise IT systems rely on a family of application programming interfaces (APIs) for integration to support organizational business processes. Hence, a secure deployment of APIs is critical for overall enterprise security. This, in turn, requires the identification of risk factors or vulnerabilities in various phases of the API life cycle and the development of controls or protection measures. This document addresses the following aspects of achieving that goal: (a) the identification and analysis of risk factors or vulnerabilities during various activities of API development and runtime, (b) recommended basic and advanced controls and protection measures during pre-runtime and runtime stages of APIs, and (c) an analysis of the advantages and disadvantages of various implementation options for those controls to enable security practitioners to adopt an incremental, risk-based approach to securing their APIs.	現代のエンタープライズITシステムは、組織のビジネスプロセスをサポートするために、アプリケーション・プログラミング・インターフェース（API）ファミリーの統合に依存している。したがって、APIの安全な展開は、エンタープライズ全体のセキュリティにとって極めて重要である。そのためには、API のライフサイクルの様々な段階におけるリスク要因や脆弱性を特定し、管理策や保護策を開発する必要がある。この文書では、その目標を達成するために、以下の側面を取り上げる：(a) API の開発及び実行時の様々な活動におけるリスク要因又は脆弱性の特定と分析、(b) API の実行前及び実行時の段階における、推奨される基本的及び高度な管理及び保護対策、(c) セキュリティ実務者が API の安全性を確保するために、段階的でリスクに基づいたアプローチを採用できるようにするための、これらの管理に関する様々な実装オプションの利点と欠点の分析。

・[PDF] NIST.SP.800-228.ipd

目次...

Executive Summary	エグゼクティブサマリー
1. Introduction	1. 序文
1.1. Building Blocks and Structures	1.1. ビルディングブロックと構造
1.2. Zero Trust and APis: The Vanishing Perimeter	1.2. ゼロトラストとAPI：
1.3. API Life Cycle	1.3. APIのライフサイクル
1.4. Document Goals…	1.4. 文書の目標...
1.5. Relationship to Other NIST Documents	1.5. 他の NIST 文書との関係
1.6. Document Structure	1.6. 文書構造
2. API Risks — Vulnerabilities and Exploits	2. API リスク - 脆弱性とエクスプロイト
2.1. Lack of Visibility of APis in the Enterprise Inventory	2.1. エンタープライズインベントリにおける API の可視性の欠如
2.2. Missing, Incorrect, or Insufficient Authorization	2.2. 認可の欠落、不正確、不十分
2.3. Broken Authentication	2.3. 破られた認証
2.4. Unrestricted Resource Consumption	2.4. 無制限のリソース消費
2.4.1. Unrestricted Compute Resource Consumption	2.4.1. 無制限の計算リソース消費
2.4.2. Unrestricted Physical Resource Consumption	2.4.2. 制限のない物理リソースの消費
2.5. Leaking Sensitive Information to Unauthorized Callers	2.5. 権限のない発信者への機密情報の漏洩
2.6. Insufficient Verification of Input Data	2.6. 入力データの不十分な検証
2.6.1. Input Validation	2.6.1. 入力妥当性確認
2.6.2. Malicious Input Protection	2.6.2. 悪意のある入力保護
2.7. Credential Canonicalization- Preparatory Step for Controls	2.7. クレデンシャルの正規化 - コントロールの準備ステップ
2.7.1. Gateways Straddle Boundaries	2.7.1. ゲートウェイは境界をまたぐ
2.7.2. Requests With a Service Identity but No User ldentity	2.7.2. サービスIDを持つがユーザ IDを持たないリクエスト
2.7.3. Requests With a User Identity But No Service Identity	2.7.3. ユーザーIDを持つがサービスIDを持たないリクエスト
2.7.4. Requests With Both User and Service Identities	2.7.4. ユーザーIDとサービスIDの両方を持つリクエスト
2.7.5. Reaching Out to Other Systems	2.7.5. 他のシステムへのリーチアウト
2.7.6. Mitigating the Confused Deputy	2.7.6. 混乱した代理の緩和
2.7.7. Identity Canonicalization	2.7.7. アイデンティティの正規化
3. Recommended Controls for APls	3. APls
3.1. Pre-Runtime Protections	3.1. 実行前の防御
3.1.1. Basic Pre-Runtime Protections	3.1.1. 基本的なプレランタイム防御
3.1.2. Advanced Pre-Runtime Protections	3.1.2. 高度なプレランタイム防御
3.2. Runtime Protections	3.2. ランタイム防御
3.2.1. Basic Runtime Protections	3.2.1. 基本的なランタイム防御
3.2.2. Advanced Runtime Protections	3.2.2. 高度なランタイム防御
4. Implementation Patterns and Trade-Offs for API Protections	4. API防御の実装パターンとトレードオフ
4.1. Centralized API Gateway	4.1. 集中型APIゲートウェイ
4.2. Hybrid Deployments	4.2. ハイブリッド展開
4.3. Decentralized Gateways	4.3. 非中央集権化ゲートウェイ
4.4. Related Technologies	4.4. 関連技術
4.4.1. Web Application Firewalls	4.4.1. ウェブアプリケーションファイアウォール
4.4.2. Bot Detection	4.4.2. ボット検知
4.4.3. Distributed Denial of Service (DDoS) Mitigation	4.4.3. 分散型サービス拒否（DDoS）緩和
4.4.4. API Endpoint Protection,	4.4.4. API エンドポイント防御、
4.4.5. Web Application and API Protection (WAAP)	4.4.5. ウェブアプリケーション・API防御(WAAP)
4.5. Summary of Implementation Patterns	4.5. 実装パターンのまとめ
5. Conclusions and Summary	5. 結論とまとめ
References	附属書
Appendix A. API Classification Taxonomy	附属書A. APIの分類分類法
A.1. API Classification Based on Degree of Exposure	A.1. エクスポージャーの程度に基づくAPIの分類
A.2. API Classification Based on Communication Patterns	A.2. コミュニケーションパターンに基づくAPI分類
A.3. API Classification Based on Architectural Style or Pattern (API Types)	A.3. アーキテクチャスタイルまたはパターン（APIタイプ）に基づくAPI分類
Appendix B. DevSecOps Phase and Associated Class of API Controls	附属書B. DevSecOpsのフェーズとAPIコントロールの関連クラス

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

Executive Summary	エグゼクティブサマリー
Application programming interfaces (APIs) provide the means to integrate and communicate with the modern enterprise IT application systems that support business processes. However, a lack of due diligence can introduce vulnerabilities and risk factors that exploit the connectivity and accessibility features of APIs. If these vulnerabilities are not identified, analyzed and addressed through control measures, attack vectors could threaten the security posture of the application systems spanned by these APIs. A systematic and effective means of identifying and addressing these vulnerabilities is only possible by treating the development and deployment of APIs as an iterative life cycle using paradigms like DevSecOps.	アプリケーションプログラミングインタフェース（API）は、ビジネスプロセスをサポートする最新のエンタープライズITアプリケーションシステムと統合し、コミュニ ケーションするための手段を提供する。しかし、デューディリジェンスの欠如は、APIの接続性とアクセシビリティ機能を悪用する脆弱性とリスク要因を導入する可能性がある。これらの脆弱性が特定され、分析され、管理策を通じて対処されない場合、攻撃ベクトルは、これらのAPIによってスパンされるアプリケーションシステムのセキュリティ体制を脅かす可能性がある。これらの脆弱性を特定し、対処する体系的で効果的な手段は、DevSecOps のようなパラダイムを使用して、 API の開発と展開を反復的なライフサイクルとして扱うことによってのみ可能である。
This document provides guidance and recommendations on controls and protection measures for secure API deployments in the enterprise. In addition, an analysis of the advantages and disadvantages of various implementation options (called patterns) for those controls enable security practitioners to choose the most effective option for their IT ecosystem.	本文書は、エンタープライズにおける安全なAPI展開のためのコントロールと保護対策に関するガイダンスと推奨を提供する。加えて、これらの管理策の様々な実装オプション（パターンと呼ばれる）の長所と短所を分析することで、セキュリティ担当者が、ITエコシステムに最も効果的なオプションを選択できるようにする。
Developing these controls and analyzing their implementation options should be guided by several overarching principles:	このような管理策の策定と実装オプションの分析は、いくつかの包括的な原則によって導 かれなければならない：
The guidance for controls should cover all APIs, regardless of whether they are exposed to customers/partners or used internally within the enterprise.	管理策のガイダンスは、API が顧客／パートナーに公開されているか、エンタープライズ内部で使用されているかに関係なく、すべての API を対象とすべきである。
With the vanishing of perimeters in modern enterprise IT applications, all controls should incorporate the concept of zero trust.	現代のエンタープライズITアプリケーションでは境界がなくなりつつあるため、全ての管理はゼロトラストの概念を取り入れるべきである。
The controls should span the entire API life cycle and be classified into (a) pre-runtime protections and (b) runtime protections that are then subdivided into basic and advanced protections to enable incremental risk-based adoption.	コントロールはAPIのライフサイクル全体に及び、(a)実行前の防御と(b)実行時の防御に分類され、さらにリスクベースの段階的な導入を可能にするために、基本的な防御と高度な防御に細分化されるべきである。
1. Introduction	1. 序文
Application programming interfaces (APIs) represent an abstraction of the underlying implementation of a digital enterprise. Given the spatial (e.g., on-premises, multiple clouds) and logical (e.g., microservices) nature of current enterprise applications, APIs are needed to integrate and establish communication pathways between internal and third-party services and applications. Informally, APIs are the lingua franca of modern IT systems: they describe what actions users are allowed to take. They are also used in every type of application, including server-based monolithic, microservices-based, browser-based client, and IoT.	アプリケーション・プログラミング・インターフェース（API）は、デジタル・エ ンタープライズの基本的な実装を抽象化した代表者である。現在のエンタープライズ・アプリケーションの空間的（例：オンプレミス、複数のクラウド）かつ論理的（例：マイクロサービス）な性質を考慮すると、APIは内部とサードパーティ・サービスおよびアプリケーション間のコミュニケーション経路を統合し確立するために必要である。非公式に言えば、APIは現代のITシステムの共通語であり、ユーザーがどのようなアクションを取ることができるかを記述している。また、サーバーベースのモノリシック、マイクロサービスベース、ブラウザベースのクライアント、IoTなど、あらゆるタイプのアプリケーションで使用されている。
1.1. Building Blocks and Structures	1.1. ビルディング・ブロックと構造
An Application Programming Interface (API) defines how any two pieces of software communicate – they are ubiquitous in software. An API is a collection of commands or endpoints that operate on data or objects via some protocol. Network-based APIs are APIs built to be consumed by remote applications over the network. Because they’re exposed and consumed over the network, they present a unique set of challenges. The growth of (micro-) service-oriented architectures, coupled with Software-as-a-Service (SaaS) becoming commonplace – which are nearly always delivered via APIs – has resulted in an explosion in network-based APIs across organizations. This document focuses on controls for network-based APIs.	アプリケーション・プログラミング・インターフェース（API）は、2つのソフトウェアがどのようにコミュニケーションするかを定義する。APIは、何らかのプロトコルを介してデータやオブジェクトを操作するコマンドやエンドポイントの集合体である。ネットワークベースのAPIは、ネットワークを介してリモート・アプリケーションから消費されるように作られたAPIだ。ネットワーク上で公開され、消費されるため、APIには独特の課題がある。(マイクロ)サービス指向アーキテクチャの成長と、SaaS(Software-as-a-Service)の一般化(これらはほぼ常にAPI経由で提供される)が相まって、組織全体でネットワークベースのAPIが爆発的に増加した。この文書では、ネットワークベースの API のコントロールに焦点を当てる。
Before we can discuss API controls, we need a common understanding and language for the building blocks, and how they relate to each other. The taxonomy is: an API is composed of a set of API Endpoints; API Endpoints are implemented by Services; at runtime, Requests to a specific API Endpoint are served by Service Instances. An API Gateway hosts many APIs and is responsible for mapping each Request to its target API Endpoint, applying policy for that Endpoint (e.g. authentication and rate limiting), then routing that Request to a Service Instance which implements that API Endpoint.	APIのコントロールについて議論する前に、構成要素とそれらがどのように互いに関連しているかについての共通の理解と言語が必要である。APIはAPIエンドポイントのセットで構成され、APIエンドポイントはサービスによって実装され、実行時に特定のAPIエンドポイントへのリクエストはサービスインスタンスによって処理される。APIゲートウェイは多くのAPIをホストし、各リクエストをターゲットのAPIエンドポイントにマッピングし、そのエンドポイントのポリシー（認証やレート制限など）を適用し、そのAPIエンドポイントを実装するサービスインスタンスにそのリクエストをルーティングする。
Fig. 1. API, API Endpoint, Service and Service Instance	Fig. API、APIエンドポイント、サービス、サービスインスタンス
Traditionally, we think of network-based APIs as being customer-oriented, partner-oriented, or internal – often called “third-party”, “second-party”, and “first-party” APIs, respectively. Second- and third-party APIs are typically exposed to callers outside of the organization via an API gateway. First-party APIs can be exposed to callers inside of the organization on the same API gateway, but they are also often consumed directly by internal callers without traversing a dedicated API serving stack.	伝統的に、我々はネットワークベースのAPIを顧客指向、パートナー指向、内部指向、それぞれ「サードパーティ」、「セカンドパーティ」、「ファーストパーティ」APIと呼ばれることが多いと考える。セカンドパーティとサードパーティのAPIは通常、APIゲートウェイを介して組織外の呼び出し元に公開される。ファーストパーティAPIは同じAPIゲートウェイ上で組織内部の呼び出し元に公開されることもあるが、専用のAPIサービングスタックを経由せずに内部の呼び出し元によって直接消費されることも多い。
An API is a set of API Endpoints, and a Service implements a set of API Endpoints – so every Service implements some API. We call these Service APIs. Most first-party API integrations happen via the Service API, i.e. they map to a single service. On the other hand, APIs hosted by the API gateway typically have Endpoints that map to many different Services. This is especially common for second- and third-party APIs. We call these Facade APIs, because they present a single facade to an outside caller over (potentially many) different Service APIs. Finally, it’s common that multiple Services are grouped together into an Application – typically along organizational lines (often an Application maps to a team). Schematic diagrams of a Service API, Façade API and an Application (Monolithic) API are given below:	APIはAPIエンドポイントの集合であり、サービスはAPIエンドポイントの集合を実装する。私たちはこれらをサービスAPIと呼んでいる。ほとんどのファーストパーティAPI統合はサービスAPIを介して行われる。一方、APIゲートウェイによってホストされるAPIは通常、多くの異なるサービスにマッピングされるエンドポイントを持っている。これは特にセカンドパーティやサードパーティのAPIによく見られる。このようなAPIをファサードAPIと呼ぶ。なぜなら、ファサードAPIは、（潜在的に多くの）異なるサービスAPI上の単一のファサードを外部の呼び出し元に提示するからである。最後に、複数のサービスがアプリケーションにグループ化されるのはよくあることで、通常は組織的な線に沿っている（多くの場合、アプリケーションはチームにマッピングされる）。サービスAPI、ファサードAPI、アプリケーション（モノリシック）APIの概略図を以下に示す：
Fig. 2. (Top to Bottom) Service API, Façade API, Service and Application (Monolithic)	図2（上から下へ）サービスAPI、ファサードAPI、サービス、アプリケーション（モノリシック）
Less formally: we can think of the APIs we expose outside the organization as a facade over a set of Services. Those Services implement internal APIs (Service APIs). Services in the organization communicate with each other via those internal APIs – sometimes directly, and sometimes via an API gateway. The API Gateway is responsible for some policies, like authentication and rate limiting, as well as being responsible for mapping the facade APIs for external clients to internal APIs. Then, to get a handle on things organizationally, we often group related Services into a bucket called an Application.	あまり形式的ではないが、組織の外部に公開するAPIは、一連のサービスを覆うファサードと考えることができる。これらのサービスは内部API（サービスAPI）を実装する。組織内のサービスは、これらの内部APIを介して、時には直接、時にはAPIゲートウェイを介して相互にコミュニケーションする。APIゲートウェイは、認証やレート制限のようなポリシーを担当し、外部クライアントのためのファサードAPIを内部APIにマッピングする役割も担っている。それから、組織的に物事を把握するために、関連するサービスをアプリケーションと呼ばれるバケットにグループ化することが多い。
While we tend to think of APIs in the context of exposing functionality to clients or partners, APIs don’t exist solely at the edge of our infrastructure. Any time systems communicate, there’s some API involved. Even if that API is something like CSV over FTP. The examples in SP focus primarily on “modern” APIs exposed via mechanisms like HTTP/REST, gRPC, or SOAP, but we believe the principals in this SP are universal and should be applied to all APIs.	APIというと、クライアントやパートナーに機能を公開するという文脈で考えがちだが、APIはインフラの端だけに存在するわけではない。システムがコミュニケーションするときには、必ずAPIが関係している。たとえそのAPIがFTP経由のCSVのようなものであってもだ。SPの例は、主にHTTP/REST、gRPC、SOAPのようなメカニズムで公開される 「最新の 」APIに焦点を当てているが、このSPの原則は普遍的であり、すべてのAPIに適用されるべきだと考えている。
1.2. Zero Trust and APIs: The Vanishing Perimeter	1.2. ゼロトラストとAPI 消滅する境界
APIs are built out of services that communicate with each other via APIs, similar to how the internet is a “network of networks.” One of the most important implications of zero trust is that there is no meaningful distinction between an “internal” and “external” caller because the perimeter is the service instance itself. Rather, all callers are trusted if they are authorized to be trusted. This contrasts with traditional approaches to API security in which the only “APIs” are those exposed to “external” callers, and API-oriented controls are only enforced at the perimeter, typically via an API gateway.	APIは、インターネットが 「ネットワークのネットワーク 」であるのと同様に、APIを介して相互にコミュニケーショ ンするサービスから構築される。ゼロトラストの最も重要な意味の1つは、境界がサービスインスタンスそのものであるため、「内部」と「外部」の呼び出し者の間に意味のある区別がないということである。むしろ、すべての呼び出し元は、信頼されることが認可されていれば信頼される。これは、「API」だけが「外部」呼び出し元に公開され、API指向の制御が境界でのみ、典型的にはAPIゲートウェイを介して実施される、APIセキュリティへの従来のアプローチとは対照的である。
NIST Special Publication (SP) 800-207A [6] discusses zero trust at runtime and the principle of shrinking the perimeter to the service instance using the five runtime controls of identity-based segmentation:	NIST 特別刊行物（SP）800-207A [6]は、実行時のゼロトラストと、ID ベースのセグメンテーションの 5 つの実行時コントロールを使用して、境界をサービスインスタンスに縮小する原則について論じている：
1. Encryption in transit — To ensure message authenticity and prevent eavesdropping, thus preserving confidentiality	1. 転送中の暗号化 - メッセージの認証を保証し、盗聴を防止することで、機密性を保持する
2. Authenticate the calling service — Verify the identity of the software sending requests	2. 呼び出し元サービスの認証 - リクエストを送信するソフトウェアのIDを検証する
3. Authorize the service — Using that authenticated identity, check that the action or communication being performed by the service is allowed	3. サービスを認可する - 認証されたIDを使用して、サービスによって実行され るアクションまたはコミュニケーションが許可されていることを確認する
4. Authenticate the end user — Verify the identity of the entity triggering the software to send the request, often a non-person entity (NPE) (e.g., service account, system account)	4. エンドユーザーを認可する - リクエストを送信するソフトウェアのトリガーとなる事業体（多くの場 合、非人間事業体(NPE)（サービスアカウント、システムアカウントなど）のIDを検証する
5. Authorize the end user to resource access — Using the authenticated end-user identity, check that they are allowed to perform the requested action on the target resource	5. エンドユーザーをリソースアクセスに認可する - 認証されたエンドユーザーアイデンティティを使用して、ターゲッ トリソース上で要求されたアクションを実行することが許可されていることを確認する
Achieving a zero-trust runtime requires applying these five controls to all API communications. This guidance further describes additional controls that are necessary for safe and secure API operations beyond identity-based segmentation. These controls should be enforced on all APIs in a system, including those exposed to the outside world (i.e., public APIs) and those intended only for other applications in a given infrastructure (i.e., internal APIs).	ゼロトラストランタイムを達成するには、これら5つの制御をすべてのAPIコミュニケーションに適用する必要がある。本ガイダンスではさらに、ID ベースのセグメンテーションを超えた、安全でセキュアな API 操作に必要な追加のコントロールについて説明する。これらの管理は、外部に公開されるAPI（すなわち公開API）や、特定のインフラストラクチャー内の他のアプリケーショ ンだけを対象とするAPI（すなわち内部API）を含め、システム内のすべてのAPIに対して実施されるべきである。
1.3. API Life Cycle	1.3. APIのライフサイクル
Like all software, APIs grow and change over time as requirements drift and usage patterns change. They also go through a continuous, iterative life cycle, including:	すべてのソフトウェアと同様に、APIは、要求が変化し、使用パターンが変わるにつれて、時間とともに成長し、変化する。APIもまた、以下のような、継続的で反復的なライフサイクルを経る：
• Plan, Develop, Build, Test, Release — These “pre-runtime” life cycle phases lead to a service that can be deployed in production.	- 計画、開発、ビルド、テスト、リリース - これらの 「プレランタイム 」ライフサイクルのフェーズは、本番環境に展開できるサービスにつながる。
• Deploy, Operate, Monitor, Feedback — These “runtime” life cycle phases involve running and operating a service in production.	- デプロイ、運用、監視、フィードバック - これらの「ランタイム」ライフサイクルフェーズでは、本番環境でのサービスの実行と運用を行う。
DoD Enterprise DevSecOps Fundamentals [1] provides a detailed description of each phase of the software development life cycle. Application of the DevSecOps paradigm in the context of cloud-native applications can be found in [4][5].	DoD Enterprise DevSecOps Fundamentals [1]は、ソフトウェア開発ライフサイクルの各フェーズの詳細な説明を提供する。クラウドネイティブアプリケーションのコンテキストにおける DevSecOps パラダイムの適用については、[4][5]を参照されたい。
Fig. 3. DevSecOps life cycle phases	図3. DevSecOps ライフサイクルのフェーズ
1.4. Document Goals	1.4. 文書の目標
The goal of this document is to recommend guidance or controls for API protection. These controls are classified into two categories:	この文書の目標は、API 保護のためのガイダンスやコントロールを推奨することである。これらのコントロールは2つのカテゴリーに分類される：
1. Pre-runtime API protections — These controls need to be applied when designing and building APIs.	1. ランタイム前のAPI防御 - これらの防御は、APIを設計・構築する際に適用する必要がある。
2. Runtime API protections — These controls need to be applied to every API request that an infrastructure serves, not just at the perimeter.	2. ランタイムAPI防御 - これらの防御は、インフラが提供する全てのAPIリクエストに適用される必要がある。
Each of these two categories is further divided into two subcategories based on organizational maturity (i.e., basic and advanced), which enables enterprises to adopt them based on an incremental risk-based approach.	これら2つのカテゴリーはそれぞれ、組織の成熟度（ベーシックとアドバンス）に基づいてさらに2つのサブカテゴリーに分けられ、エンタープライズがリスクベースのアプローチに基づいて段階的に導入できるようになっている。
A prerequisite for defining any API protection measure or policy irrespective of its category or sub-category is that the protections must be expressed in terms of nouns and verbs that pertain to API components, API endpoint components, API requests, and API responses that in turn contain references to resources/data and operations on those resources. These nouns and verbs form the fundamental surface that is exposed to the consumers of APIs and API endpoints.	カテゴリーやサブカテゴリーに関係なく、API 保護対策やポリシーを定義するための前提条件は、保護が API コンポーネント、API エンドポイントコンポーネント、API リクエスト、API レスポンスに関連する名詞と動詞で表現されなければならないことである。これらの名詞と動詞は、APIとAPIエンドポイントの消費者に公開される基本的な表面を形成する。
1.5. Relationship to Other NIST Documents	1.5. 他のNIST文書との関係
Today, most enterprise software development and integration are based on APIs. Section 1.3 articulated the close relationship between software and APIs, demonstrated that API development and deployment follow the same iterative life cycle as the software, and provided NIST guidance on DevSecOps.	今日、ほとんどのエンタープライズソフトウェアの開発と統合はAPIに基づいている。セクション1.3は、ソフトウェアとAPIの密接な関係を明確にし、APIの開発と展開がソフトウェアと同じ反復的なライフサイクルに従うことを示し、DevSecOpsに関するNISTのガイダンスを提供した。
Another distinguishing feature of the controls recommended for protecting APIs is the capacity to provide assurance for conforming to the principles of zero trust. This is because there is no distinction between internal and external API requests/calls due to the absence of an identifiable network perimeter and the distributed nature of applications on-premises and multiple clouds. This security assurance can be achieved using authentication and authorization controls using identity-based segmentation [2]. Documents that provide recommendations on the configuration of authentication and authorization controls in the context of cloud-native applications (e.g., [2][3]) are also relevant in the context of configuring controls for API protection.	APIを保護するために推奨される防御のもう一つの特徴は、ゼロトラストの原則に適合する保証を提供する能力である。これは、識別可能なネットワーク境界が存在せず、オンプレミスや複数のクラウドに分散したアプリケーションの性質のため、内部と外部のAPIリクエスト／コールの区別がないためである。このセキュリティ保証は、ID ベースのセグメンテーションを使用した認証と認可のコントロールを使用して達成することができる [2]。クラウドネイティブアプリケーションの文脈における認証と認可の制御の構成に関する推奨を提供する文書（例えば、 [2][3]）は、API 保護のための制御の構成の文脈にも関連する。
1.6. Document Structure	1.6. 文書構成
This document is organized as follows:	本文書の構成は以下の通りである：
• Section 2 looks at the risk factors and vulnerabilities associated with APIs and the attack vectors that could exploit those vulnerabilities.	・セクション 2 は、API に関連するリスク要因と脆弱性、及び、それらの脆弱性を悪用する攻撃ベクターについて見ている。
• Section 3 recommends controls to protect APIs and classifies them into basic and advanced categories that need to be applied prior to runtime or enforced during runtime.	・セクション 3 は、API を保護するための防御策を推奨し、実行前に適用する必要がある、あるいは実行中に強制 する必要がある、基本的なカテゴリーと高度なカテゴリーに分類する。
• Section 4 provides a detailed analysis of implementation options or patterns for the controls described in Sec. 3 and outlines the advantages and disadvantages of each pattern.	・セクション4は、セクション3で説明したコントロールの実装オプションやパターンを詳細に分析し,各パターンの長所と短所を概説する。
• Section 5 provides the summary and conclusions.	・セクション5は、要約と結論を提供する。
• Appendix A provides the classification taxonomy for APIs.	・附属書Aは、APIの分類分類法を提供する。
• Appendix B illustrates the API controls related to each DevSecOps phase	・附属書Bは、DevSecOps の各フェーズに関連する API の管理方法を示している。

米国 NIST IR 8523（初期公開ドラフト） 刑事司法情報システムのための多要素認証： 刑事司法情報を保護するための実装上の考慮事項 (2025.03.13)

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

NISTが、IR 8523（初期公開ドラフト） 刑事司法情報システムのための多要素認証： 刑事司法情報を保護するための実装上の考慮事項を公表し、意見募集をしていますね...

刑事司法情報システムには、多要素認証が義務付けられているということです...

米国は合衆国ですから、連邦政府、州政府、地方自治体でそれぞれ警察機構があり、指名手配犯、失踪者、盗難等の事件関係の情報や、顔写真、指紋といった情報が共有できる仕組みとなっていますから、データへのアクセス管理は重要ですよね...

日本ではこのあたりの情報の保護ってどのようになっているんでしょうね...

● NIST - ITL

・2025.03.13 NIST IR 8523 (Initial Public Draft) Multi-Factor Authentication for Criminal Justice Information Systems: Implementation Considerations for Protecting Criminal Justice Information

NIST IR 8523 (Initial Public Draft) Multi-Factor Authentication for Criminal Justice Information Systems: Implementation Considerations for Protecting Criminal Justice Information	NIST IR 8523（初期公開ドラフト） 刑事司法情報システムのための多要素認証： 刑事司法情報を保護するための実装上の考慮事項
Announcement	発表
Criminal and non-criminal justice agencies in the U.S. require the use of multi-factor authentication (MFA) to protect access to criminal justice information (CJI). MFA is important for protecting against credential compromises and other cyber risks such as attacks by cybercriminals or other adversaries that threaten CJI.	米国の刑事司法機関および非刑事司法機関は、刑事司法情報（CJI）へのアクセスを保護するために多要素認証（MFA）の使用を義務付けている。MFA は、クレデンシャルの漏洩や、CJI を脅かすサイバー犯罪者やその他の敵による攻撃などのサイバーリスクから保護するために重要である。
CJI is commonly accessed using computer-aided dispatch (CAD) and record management system (RMS) software, which communicate with a state-level message switch application. MFA architectures will likely need to integrate with one or both technologies. As agencies around the country begin to implement MFA solutions, the approaches they use require careful consideration and planning. This document provides a general overview of MFA, outlines design principles and architecture considerations for implementing MFA to protect CJI, and offers specific examples of use cases that agencies face today. It also outlines how CAD/RMS and message switch technologies can support standards and best practices that provide agencies with maximum optionality to implement MFA in a way that promotes security, interoperability, usability, and cost savings.	CJI は一般に、コンピュータ支援発送（CAD）および記録管理システム（RMS）ソフトウェアを使用してアクセスされ、これらは州レベルのメッセージ・スイッチ・アプリケーション と通信する。MFAアーキテクチャは、おそらくどちらか、あるいは両方の技術と統合する必要があるだろう。国内の各機関がMFAソリューションの実装を始めるにあたり、どのようなアプローチを用いるかについては、慎重な検討と計画が必要である。本文書は、MFA の一般的な概要を提供し、CJI を保護するために MFA を実装するための設計原則とアーキテ クチャの考慮事項を概説し、今日、各省庁が直面しているユースケースの具体例を提供する。また、CAD/RMSとメッセージ・スイッチ技術が、セキュリティ、相互運用性、ユーザビリティ、コスト削減を促進する方法でMFAを実装するために、機関に最大限の選択肢を提供する標準とベスト・プラクティスをどのようにサポートできるかを概説する。
Abstract	概要
Most recent cybersecurity breaches have involved compromised credentials. Migrating from single-factor to multi-factor authentication (MFA) reduces the risk of compromised credentials and unauthorized access. Both criminal and noncriminal justice agencies need to access criminal justice information (CJI); to reduce the risk of unauthorized access, the Criminal Justice Information Services (CJIS) Security Policy now requires the use of MFA when accessing CJI. This document provides practical guidance to agencies that are implementing MFA, reflecting on lessons learned from agencies around the country and from CJI-related technology vendors.	最近のサイバーセキュリティ侵害のほとんどは、漏洩した認証情報が関与している。単要素認証から多要素認証（MFA）への移行は、クレデンシャルの漏洩と不正アクセスのリスクを低減する。刑事司法機関と非刑事司法機関の両方が刑事司法情報（CJI）にアクセスする必要がある。不正アクセスのリスクを低減するため、刑事司法情報サービス（CJIS）セキュリティ・ポリシーは現在、CJIにアクセスする際にMFAを使用することを義務付けている。本書は、MFA を導入する機関に対し、全国の機関および CJI 関連技術ベンダ ーから学んだ教訓を反映した実践的なガイダンスを提供するものである。

・IR.8523.ipd

目次...

Executive Summary	エグゼクティブサマリー
1. Introduction	1. 序文
1.1. Approach	1.1. アプローチ
1.2. How to Use This Document	1.2. この文書の使い方
2. An Overview of MFA Technologies and Concepts	2. MFA の技術とコンセプトの概要
2.1. Introduction to MFA	2.1. MFA の序文
2.2. CJIS Requirements for MFA	2.2. MFA に対する CJIS 要件
2.3. Identity Providers	2.3. ID プロバイダ
2.4. Single Sign-On and Identity Federation	2.4. シングルサインオンと ID フェデレーション
2.4.1. Benefits of Identity Federation	2.4.1. ID フェデレーションの利点
2.4.2. Benefits of Single Sign-On	2.4.2. シングルサインオンの利点
2.5. The Importance of Phishing Resistance	2.5. フィッシング耐性の重要性
3. Choosing an MFA Implementation for Protecting CJ	3. CJを保護するためのMFA実装の選択
3.1. MFA Design Principles	3.1. MFA 設計原則
3.1.1. Principle 1: Authenticator Reusability	3.1.1. 原則 1：認証の再利用性
3.1.2. Principle 2: Authenticator Optionality	3.1.2. 原則 2：認証者のオプション性
3.1.3. Principle 3: Minimize the Passing of Memorized Secrets	3.1.3. 原則 3：記憶された秘密の受け渡しの最小化
3.1.4. Principle 4: Ensure MFA Is Integrated to Protect CJI	3.1.4. 原則 4：MFAの統合によるCJIの確実な保護
3.2. MFA Requirements Assessment	3.2. MFA 要件アセスメント
3.2.1. MFA Users	3.2.1. MFA ユーザ
3.2.2. IT Support Staff	3.2.2. IT サポートスタッフ
3.2.3. Other Agencies	3.2.3. 他の省庁
3.2.4. Procurement Teams	3.2.4. 調達チーム
3.2.5. Compliance Teams	3.2.5. コンプライアンスチーム
3.2.6. Legal Team	3.2.6. 法務チーム
3.2.7. Technology Vendors	3.2.7. 技術ベンダー
3.3. Phased MFA Deployment	3.3. 段階的 MFA 展開
3.4. Choosing Where to Deploy MFA	3.4. MFA を展開する場所の選択
3.4.1. Local Agency MFA Architectures	3.4.1. 地方機関の MFA アーキテクチャ
3.4.2. State MFA Deployments	3.4.2. 州の MFA 展開
3.4.3. Implementing MFA with VPNs	3.4.3. VPN による MFA の実装
4. Key Takeaways	4. キーポイント
References	参照文書
Appendix A. Technology Components Relevant to MA for CJIS Access	附属書 A. CJIS アクセスの MA に関連する技術要素
Appendix B. Federated Identity Architectures	附属書 B. フェデレーテッド ID アーキテクチャ
B. 1. Establishing Federation Trust	B.1. フェデレーション信頼の確立
B.2. Challenges in Using Federation Technologies for Message Switch Use Cases	B.2. メッセージ交換ユースケースにフェデレーション技術を使用する際の課題
B.3. Meeting FAL Requirements in Complex Federation Scenarios	B.3. 複雑なフェデレーションシナリオにおける FAL 要件の達成
B.4. Federated Architectures for Access to CJ	B.4. CJへのアクセスのための統合アーキテクチャ
B.4.1. Both CAD/RMS Web App & IdP at the State Agency	B.4.1. 州機関における CAD/RMS ウェブ・アプリと IdP の両方
B.4.2. CAD Thick Client at the County with the IdP at the State Agency	B.4.2. 郡の CAD シッククライアントと州機関の IdP
B.4.3. Both the CAD/RMS Web App and IdP at a County Agency	B.4.3. 郡庁における CAD/RMS ウェブ・アプリと IdP の両方
B.4.4. Integrations with Auth 2.0 and OIDC	B.4.4. Auth 2.0 および OIDC
B.5. VPN Integration	B.5. VPNの統合
B.5.1. VPN Integration with Kerberos but without Federation	B.5.1. フェデレーションを使用しない、Kerberos との VPN 統合
B.5.2. VPN Integration with an Identity Provider	B.5.2. ID プロバイダとの VPN 統合
Appendix C. Questions to Ask Your Technology Vendors	附属書 C. テクノロジベンダ向け質問票
C.1. Questionnaire for CAD/RMS Vendors	C.1. CAD/RMS ベンダ向け質問票
C.2. Questionnaire for Identity Services Vendors	C.2. アイデンティティサービスベンダ向け質問票
C.3. Questionnaire for Message Switch Vendors	C.3. メッセージスイッチベンダ向け質問票
C.4. Questionnaire for VPN Vendors	C.4. VPNベンダー向け質問票
Appendix D. List of Symbols, Abbreviations, and Acronyms	附属書D. 記号、略語、および頭字語のリスト

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

Executive Summary	エグゼクティブサマリー
The Criminal Justice Information Services (CJIS) Security Policy versions 5.9.2 and later [1] require the use of multi-factor authentication (MFA) to protect access to criminal justice information (CJI). MFA is important for protecting against credential compromises and other cyber risks that may threaten CJI. Criminal and non-criminal justice agencies around the country will need to work with their technology vendors to implement this CJIS requirement.	刑事司法情報サービス（CJIS）セキュリティポリシバージョン5.9.2以降[1]は、刑事司法情報 （CJI）へのアクセスを保護するために多要素認証（MFA）の使用を義務付けている。MFA は、CJI を脅かす可能性のあるクレデンシャルの漏洩およびその他のサイバー・リ スクから保護するために重要である。全国の刑事司法機関および非刑事司法機関は、この CJIS 要件を実装するために、テクノロジー・ベンダーと協力する必要がある。
CJI is commonly accessed using computer-aided dispatch (CAD) and record management system (RMS) software, which communicate with a state-level message switch application. CJI MFA architectures will likely need to integrate with one or both of these technologies. As agencies around the country begin to implement MFA solutions, the approaches they use require careful consideration and planning. This document provides a general overview of MFA, outlines design principles and architecture considerations for implementing MFA to protect CJI, and offers specific examples of use cases that agencies face today. It also outlines how CAD/RMS and message switch technologies can support standards and best practices that provide agencies with maximum optionality to implement MFA in a way that promotes security, interoperability, usability, and cost savings.	CJIは一般に、コンピュータ支援派遣（CAD）と記録管理システム（RMS）ソフトウェアを使用してアクセスされ、これらのソフトウェアは州レベルのメッセージスイッチアプリケーションと通信する。CJI MFAアーキテクチャーは、おそらくこれらの技術の一方または両方と統合する必要があろう。国内の各機関がMFAソリューションの導入を始めるにあたり、どのようなアプローチを採用するかについては、慎重な検討と計画が必要である。本文書は、MFA の一般的な概要を提供し、CJI を保護するために MFA を実装するための設計原則とアーキテクチャの考慮事項を概説し、今日、各省庁が直面しているユースケースの具体例を提示している。また、CAD/RMS とメッセージ・スイッチ技術が、セキュリティ、相互運用性、使いやすさ、 およびコスト削減を促進する方法で MFA を実装するために、機関に最大限の選択肢を提供する標準とベスト・プラクティスをどのようにサポートできるかを概説する。

序文...

1. Introduction	1. 序文
Credential compromises represent a critical and pervasive cybersecurity threat, serving as a gateway for malicious actors to infiltrate networks and systems, thus gaining access to sensitive data. Whether through phishing, brute-force attacks, or exploiting vulnerabilities in authentication mechanisms, credential compromise poses a significant risk to organizations and individuals alike. To mitigate this threat, version 5.9.2 and subsequent versions of the Federal Bureau of Investigation (FBI) Criminal Justice Information Services (CJIS) Security Policy [1] require multi-factor authentication (MFA) for all users when accessing criminal justice information (CJI). Both criminal and noncriminal justice agencies that receive CJI are subject to this requirement. In this document, we refer to these organizations generically as agencies.	クレデンシャルの侵害は、サイバーセキュリティの重要かつ広範な脅威であり、悪意のあるアクター がネットワークやシステムに侵入し、機密データにアクセスするためのゲートウェイとなる。フィッシング、ブルートフォース攻撃、認証メカニズムの脆弱性の悪用のいずれにせよ、クレデンシャルの危殆化は、組織にとっても個人にとっても重大なリスクである。この脅威を緩和するために、連邦捜査局（FBI）刑事司法情報サービス（CJIS）セキュリティ・ポリシーのバージョン 5.9.2 およびそれ以降のバージョン [1]では、刑事司法情報（CJI）にアクセスするすべてのユーザに多要素認証（MFA）を要求している。CJI を受け取る刑事司法機関と非刑事司法機関の両方が、この要件の対象となる。本文書では、これらの機関を一般的に「機関」と呼ぶ。
As agencies around the country begin to implement this requirement, they face several challenges that require careful consideration and planning. The purpose of this document is to help agencies identify and address their MFA implementation needs by providing insight into MFA architectures and how they can be used to meet law enforcement-specific use cases.	全米の機関がこの要件を実施し始めると、慎重な検討と計画を必要とするいくつかの課題に直面する。本文書の目的は、MFA アーキテクチャと、それらが法執行機関特有のユースケースを満たすた めにどのように利用できるかについての洞察を提供することにより、MFA 実装のニーズを特定し、取 り組むことを支援することである。
1.1. Approach	1.1. アプローチ
To ensure the relevance of this document’s contents, the NIST and FBI CJIS team engaged with agencies around the country on their current and future MFA implementations, as well as law enforcement technology vendors on their current and future support for MFA standards and best practices. The architectures, use cases, technologies, and challenges in this document are heavily based on those discussions. Though this document will promote standards and best practices for MFA and identity federation, the overarching goal of this guidance is to meet agencies “where they are” by providing practical MFA implementation considerations that help agencies make sound risk decisions while also considering cost, functional requirements, and the potential for centralized and shared MFA services.	本文書の内容の妥当性を確保するため、NIST と FBI の CJIS チームは、現在お よび将来の MFA 実装について、また MFA 標準とベスト・プラクティスに対する現在お よび将来のサポートについて、法執行技術ベンダーと同様に、全米の機関と協力し た。本文書のアーキテクチャ、ユースケース、技術、および課題は、これらの議論に大きく基づい ている。本文書は MFA および ID フェデレーションの標準とベスト・プラクティスを促進するが、このガイダ ンスの包括的な目標は、コスト、機能要件、および集中型 MFA サービスと共有型 MFA サービスの可 能性も考慮しながら、機関が適切なリスクを決定するのに役立つ実用的な MFA 実装の考慮事項を提 供することによって、機関が「現在いる場所」に対応することである。
1.2. How to Use This Document	1.2. 本文書の使用方法
The guidance in this document is intended to aid agencies in their MFA implementations but does not guarantee that their implementation will meet CJIS Security Policy requirements or will pass a CJIS audit. All questions about how a specific MFA implementation can meet the CJIS Security Policy should be directed to the CJIS Information Security Officer (ISO) team at iso@fbi.gov.	本文書のガイダンスは、機関が MFA を導入する際の助けとなることを意図してい るが、その導入が CJIS セキュリティポリシー要件を満たすこと、あるいは CJIS 監査に合格することを保証するものではない。特定の MFA の実装がどのように CJIS セキュ リティポリシーを満たすことができるかに関するすべての質問は、CJIS 情報セキュ リティオフィサー（ISO）チーム（iso@fbi.gov）に直接問い合わせること。
Many of the challenges discussed in this document require collaboration between state, local, tribal, and territorial (SLTT) agencies, as well as collaboration with law enforcement technology providers. Agencies should engage all relevant stakeholders to discuss MFA implementation plans to ensure this collaboration can occur.	この文書で議論されている課題の多くは、州、地方、部族、および準州（SLTT）機関間の協 力、ならびに法執行技術プロバイダとの協力を必要とする。各省庁は、関係するすべての利害関係者を巻き込んで MFA の実施計画を議論し、このような協力が確実に行えるようにする必要がある。
Section 2 of this document provides an overview of MFA concepts and the importance of MFA as a cybersecurity control.	本文書のセクション 2 では、MFA の概念とサイバーセキュリティ管理としての MFA の重要性について概説する。
Section 3 of this document details MFA design principles, agency stakeholders that should be part of MFA requirements development, considerations for a phased MFA rollout, and examples of where agencies might choose to implement MFA.	本文書のセクション3では、MFA の設計原則、MFA 要件策定に参加すべき省庁の利害関係者、段階的な MFA 導入のための考慮事項、および省庁が MFA の導入を選択する可能性のある場所の例について詳述する。
Section 4 collects the key considerations for agencies from throughout the document.	セクション4では、この文書全体から、各省庁が考慮すべき重要事項を集めている。
The Appendices of this document include detailed MFA architectures and questionnaires that agencies can use to engage their vendors.	この文書の附属書には、詳細なMFAアーキテクチャーと、各省庁がベンダーを関与させるた めに使用できる質問表が含まれている。

米国 NIST NIST SP 1308（初期公開ドラフト） NIST サイバーセキュリティフレームワーク 2.0： サイバーセキュリティ、エンタープライズリスクマネジメント、要員マネジメント クイックスタートガイド (2025.03.12)

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

NISTが NIST サイバーセキュリティフレームワーク 2.0： サイバーセキュリティ、エンタープライズリスクマネジメント、要員マネジメント クイックスタートガイドのドラフトが公開され、意見募集がされています...

2023年3月に経産省から公表して、サイバーセキュリティ経営ガイドラインはVer3.0は、ERMとサイバーセキュリティの融合を意識しました。Cybersecurity Framework 2.0もERMとの連携を意識しています。加えて、Workforce Management（要員マネジメント）との融合を目指していますね...

● NIST - ITL

・2025.03.12 NIST SP 1308 (Initial Public Draft) NIST Cybersecurity Framework 2.0: Cybersecurity, Enterprise Risk Management, and Workforce Management Quick Start Guide

NIST SP 1308 (Initial Public Draft) NIST Cybersecurity Framework 2.0: Cybersecurity, Enterprise Risk Management, and Workforce Management Quick Start Guide	NIST SP 1308（初期公開ドラフト） NIST サイバーセキュリティフレームワーク 2.0： サイバーセキュリティ、エンタープライズリスクマネジメント、要員マネジメント クイックスタートガイド
Announcement	発表
This document shows how the Workforce Framework for Cybersecurity (NICE Framework) and the Cybersecurity Framework (CSF) 2.0 can be used together to address cybersecurity risk. It is the newest of the CSF 2.0 Quick Start Guides (QSG) released since February 26, 2024; these resources provide different audiences with tailored pathways into the CSF 2.0, making it easier to implement.	この文書は、サイバーセキュリティのためのワークフォースフレームワーク（NICE フレームワーク）とサイバーセキュリティフレームワーク（CSF）2.0 をどのように併用してサイバーセキュリティリスクに対処できるかを示している。これは、2024 年 2 月 26 日以降にリリースされた CSF 2.0 クイックスタートガイド（QSG）の最新版である。これらのリソースは、CSF 2.0 の導入を容易にするために、様々な対象者に CSF 2.0 の導入方法を提供する。
This QSG draws on three key NIST resources to enable users to align their cybersecurity, ERM, and workforce management practices in a streamlined process:	この QSG は、ユーザが合理的なプロセスでサイバーセキュリティ、ERM、および要員管理の実務を整 備できるように、NIST の 3 つの主要なリソースを活用している：
・Cybersecurity Framework	・サイバーセキュリティフレームワーク
・NICE Framework	・NICEフレームワーク
・NIST IR 8286 series, Integrating Cybersecurity and Enterprise Risk Management (ERM)	・NISTIR 8286 シリーズ、サイバーセキュリティとエンタープライズリスクマネジメント（ERM）の統合
The public comment period is open through Friday, April 25, 2025.	パブリックコメント募集期間は 2025 年 4 月 25 日（金）までである。
Abstract	概要
This Quick Start Guide (QSG) shows how the NICE Workforce Framework for Cybersecurity and the Cybersecurity Framework (CSF) can be used together to facilitate communication across business units and improve organizational processes where cybersecurity, enterprise risk management (ERM), and workforce management intersect.	本クイックスタートガイド（QSG）は、NICE のサイバーセキュリティのためのワークフォースフレームワークとサイバーセキュリティフレームワーク（CSF）を併用することで、事業部門間のコミュニケーションを促進し、サイバーセキュリティ、エンタープライズリスクマネジメント（ERM）、要員マネジメントが交差する組織プロセスを改善する方法を示す。

・[PDF] NIST.SP.1308.ipd

序文...

INTRODUCTION	序文
Purpose of this Guide	本ガイドの目的
This Quick Start Guide (QSG) shows how the NICE Workforce Framework for Cybersecurity and the Cybersecurity Framework (CSF) can be used together to facilitate communication across business units and improve organizational processes where cybersecurity, enterprise risk management (ERM), and workforce management intersect.	本クイックスタートガイド（QSG）は、NICEサイバーセキュリティのためのワークフォースフレームワークとサイバーセキュリティフレームワーク（CSF）を併用することで、事業部門間のコミュニケーションを促進し、サイバーセキュリティ、エンタープライズリスクマネジメント（ERM）、要員マネジメントが交差する組織プロセスを改善する方法を示す。
Overview of Risk	リスクの概要
Risk is the effect of uncertainty on business objectives. Cybersecurity risk is an important type of risk that all enterprises face, alongside others including financial, legal, reputational, and safety risks. Although cybersecurity risks frequently intersect with additional risk types — in the form of lost revenue or stakeholder trust, for example — some organizations do not conduct cybersecurity risk management with the same consistency and rigor that are applied to other types of risk.	リスクとは、事業目標に対する不確実性の影響である。サイバーセキュリティリスクは、財務リスク、法的リスク、評判リスク、安全リスクなど他のリスクと並んで、すべてのエンタープライズが直面する重要なリスクの一種である。サイバーセキュリティリスクは、例えば、収益の損失や利害関係者の信頼といった形で、他のリスクタイプと交差することが多いが、一部の組織では、他のリスクタイプに適用されるのと同じような一貫性と厳格さでサイバーセキュリティリスクマネジメントを行っていない。
CSF Organizational Profiles	CSF 組織プロファイル
An Organizational Profile describes an organization’s current and/or target cybersecurity posture in terms of cybersecurity outcomes from the CSF Core. Organizational Profiles are used to understand, tailor, assess, and prioritize cybersecurity risk based on an organization’s mission objectives, stakeholder expectations, threat landscape, and requirements. The organization can then act strategically to achieve those outcomes. Organizational Profiles can also be used to assess progress toward targeted outcomes and to communicate pertinent information to stakeholders. This QSG assumes that an Organizational Profile has been completed already.	組織プロファイルは、CSF コアのサイバーセキュリティの成果という観点から、組織の現 在のサイバーセキュリティ態勢および／または目標とするサイバーセキュリティ態勢を記述する。組織プロファイルは、組織のミッション目標、利害関係者の期待、脅威の状況、要件に基づいて、サイバーセキュリティリスクを理解し、調整し、アセスメントし、優先順位を付けるために使用される。そして、組織はこれらの成果を達成するために戦略的に行動することができる。組織プロファイルは、目標とする成果に対する進捗状況を評価し、利害関係者に適切な情報を伝達するためにも使用できる。この QSG では、組織プロファイルがすでに完成していることを前提としている。
Integrating Cybersecurity, ERM, and Workforce Management	サイバーセキュリティ、ERM、および要員マネジメントの統合
Once current and/or target cybersecurity posture in terms of CSF cybersecurity outcomes is documented, you can then use the NICE Framework to dentify the people and skills needed to implement the outcomes. People, processes, and technology combine to achieve acceptable levels of enterprise and cybersecurity risk. The NICE Framework focuses on people, providing a common language for describing cybersecurity work, including the Work Roles an organization’s cybersecurity staff must perform.	CSF のサイバーセキュリティ成果の観点から、現在および／または目標とするサイバーセキュリティ態勢が文書化されたら、次に NICE フレームワークを使用して、成果を実施するために必要な人材とスキルを明確にすることができる。エンタープライズリスクとサイバーセキュリティリスクの許容レベルを達成するためには、人材、プロセス、テクノロジを組み合わせる必要がある。NICE フレームワークは「人」に焦点を当て、組織のサイバーセキュリティ担当者が果たすべきワーク・ロールを含め、サイバーセキュリティ業務を記述するための共通言語を提供する。

クイックスタートのウェブページ...

・SF 2.0 Quick Start Guides

利用可能なガイド:

Available Guides:	Language
CSF 2.0 Overview	En	Ja
Organizational Profiles	En	Ja
Community Profiles	En
Small Business	En	Ja
Cybersecurity SCRM	En	Ja
Tiers	En	Ja
Enterprise Risk Management	En	Ja
Cybersecurity, ERM and Workforce Management	En

---

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

CSF 2.0

・2024.02.28 米国 NIST CSWP 29 NISTサイバーセキュリティフレームワーク（CSF）2.0

IR8286

・2025.03.10 米国 NIST IR 8286 Rev. 1（初期公開草案） サイバーセキュリティとエンタープライズリスクマネジメント（ERM）の統合他 (2025.02.26)

・2024.03.10 米国 NIST IR 8286C エンタープライズリスクマネジメントと政府監視のためのサイバーセキュリティリスクのステージング

・2022.11.22 NISTIR 8286D リスクの優先順位付けと対応を行うためのビジネス影響分析の使用

・2022.09.16 NISTIR 8286C エンタープライズ・リスク・マネジメント (ERM) とガバナンスの監督のためのサイバーセキュリティ・リスクのステージング

・2022.06.14 NISTIR 8286D (ドラフト) リスクの優先順位付けと対応にビジネスインパクト分析を使用する方法 (2022.06.09)

・2022.02.13 NISTIR 8286B エンタープライズ・リスク・マネジメント (ERM) のためのサイバーセキュリティ・リスクの優先順位付け

・2022.01.28 NISTIR 8286C （ドラフト）エンタープライズ・リスク・マネジメント (ERM) とガバナンスの監督のためのサイバーセキュリティ・リスクのステージング

・2021.11.15 NISTIR 8286A エンタープライズ・リスク・マネジメント (ERM) のためのサイバーセキュリティ・リスクの識別と推定

・2021.09.03 NISTIR 8286B（ドラフト）エンタープライズ・リスク・マネジメント (ERM) のためのサイバーセキュリティ・リスクの優先順位付け

・2021.07.08 NISTIR 8286A （ドラフト）エンタープライズ・リスク・マネジメント (ERM) のためのサイバーセキュリティ・リスクの識別と推定（第2ドラフト）

・2020.10.22 NISTIR 8286 Integrating Cybersecurity and Enterprise Risk Management (ERM)

・2020.07.12 NISTIR 8286 (Draft) Integrating Cybersecurity and Enterprise Risk Management (ERM) (2nd Draft)

・2020.03.20 NISTIR 8286(Draft) Integrating Cybersecurity and Enterprise Risk Management (ERM)

SP800-221関係...

・2023.11.20 NIST SP 800-221 情報通信技術リスクのエンタープライズへの影響：エンタープライズリスクポートフォリオにおけるICTリスクプログラムのガバナンスとマネジメント, NIST SP 800-221A 情報通信技術（ICT）リスクの成果： ICTリスクマネジメントプログラムとエンタープライズリスクポートフォリオの統合

・2022.07.25 NIST SP 800-221 (ドラフト) 情報通信技術リスクのエンタープライズへの影響：エンタープライズ・リスクポートフォリオの中でのICTリスクプログラムの統治と管理 SP 800-221A (ドラフト) 情報通信技術 (ICT) リスクの成果：ICTリスクマネジメントプログラムとエンタープライズリスクポートフォリオの統合

経営ガイドライン Veer3.0

・2023.11.09 IPA サイバーセキュリティ経営ガイドライン Ver 3.0実践のためのプラクティス集 (2023.10.31)

・2023.03.26 経済産業省 サイバーセキュリティ経営ガイドラインVer 3.0

・2022.12.10 経団連 「サイバーセキュリティ経営ガイドライン Ver3.0 (案) 」に対する意見

米国 NIST IR 8546（初期公開ドラフト）サイバーセキュリティフレームワーク2.0 半導体製造プロファイル (2025.02.27)

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

NISTがサイバーセキュリティフレームワーク2.0にそった半導体製造プロファイルのドラフトを公表していますね...

PDFで136ページあります...

より一般の製造業のプロファイル（IR8183）をベースに開発をしているようです...

Fig.1 半導体製造エコシステム...

⚫︎ NIST - ITL

・2025.02.27 NIST IR 8546 (Initial Public Draft) Cybersecurity Framework Version 2.0 Semiconductor Manufacturing Profile

NIST IR 8546 (Initial Public Draft) Cybersecurity Framework Version 2.0 Semiconductor Manufacturing Profile	NIST IR 8546（初期公開ドラフト）サイバーセキュリティフレームワーク・バージョン 2.0 半導体製造プロファイル
Announcement	発表
This draft CSF 2.0 Profile provides a voluntary, risk-based approach for managing cybersecurity activities and reducing cybersecurity risk to semiconductor manufacturing. The semiconductor manufacturing environment is a complex ecosystem of device makers, equipment OEMs, suppliers and solution providers. This Profile focuses on desired cybersecurity outcomes and can be used as a guideline to improve the current cybersecurity posture of the semiconductor manufacturing ecosystem.	この CSF 2.0 プロファイル草案は、サイバーセキュリティ活動をマネジメントし、半導体製造のサイバーセキュリティリスクを低減するための自主的なリスクベースのアプローチを提供する。半導体製造環境は、デバイスメーカー、装置 OEM、サプライヤ、ソリューションプロバイダからなる複雑なエコシステムである。このプロファイルは、望ましいサイバーセキュリティの成果に焦点を当て、半導体製造エコシステムの現在のサイバーセキュリティ態勢を改善するためのガイドラインとして利用できる。
The NCCoE is planning a virtual workshop on Thursday, March 13, 2025, to provide an overview of the draft NIST Internal Report (IR) 8546, Cybersecurity Framework 2.0 Semiconductor Manufacturing Community Profile, gather feedback on the Profile, identify additional resources to support the adoption of the profile, and share next steps.	NCCoEは2025年3月13日（木）にバーチャルワークショップを計画しており、NIST内部報告書（IR）8546「サイバーセキュリティフレームワーク2.0半導体製造コミュニティプロファイル」（ドラフト）の概要を説明し、プロファイルに関するフィードバックを集め、プロファイルの採用を支援するための追加リソースを特定し、次のステップを共有する。
Abstract	概要
This document defines a Cybersecurity Framework (CSF) 2.0 Community Profile with a voluntary, risk-based approach to managing cybersecurity activities and reducing cyber risks for semiconductor development and manufacturing. Collaboratively developed in support of the National Cybersecurity Implementation Plan Version 2, the Semiconductor Manufacturing Profile can be used as a roadmap for reducing cybersecurity risks for semiconductor manufacturers in alignment with sector goals and industry best practices. It is built on top of the Manufacturing Profile documented in NIST IR 8183, Revision 1. The Profile is meant to enhance but not replace current cybersecurity standards and industry guidelines that the manufacturer is embracing.	本文書は、サイバーセキュリティ活動をマネジメントし、半導体開発・製造のサイバーリスクを低減するための自主的なリスクベースのアプローチを備えたサイバーセキュリティフレームワーク（CSF）2.0コミュニティプロファイルを定義する。National Cybersecurity Implementation Plan Version 2 を支援するために共同開発された半導体製造プロファイルは、半導体製造事業者のサイバーセキュリティリスクを削減するためのロードマップとして、この分野の目標や業界のベストプラクティスに沿って使用することができる。このプロファイルは、NIST IR 8183, Revision 1 に文書化された製造プロファイルの上に構築されている。このプロファイルは、製造事業者が採用している現行のサイバーセキュリティ標準や業界ガイドラインを強化するものであるが、取って代わるものではない。

・[PDF] NIST.IR.8546.ipd

Fig.2 半導体製造エコシステムの機能領域

Fig.3 半導体サイバーセキュリティの要素

Executive Summary	エグゼクティブサマリー
1. Introduction	1. 序文
1.1. Purpose	1.1. 目的
1.2. Semiconductor Fabrication Ecosystem Functional Domains	1.2. 半導体製造エコシステム機能領域
1.2.1. Development of Secure Equipment and Tooling	1.2.1. セキュアな装置および工具の開発
1.2.2. Fab Environment	1.2.2. 製造環境
1.2.3. Enterprise IT Infrastructure in Semiconductor Manufacturing	1.2.3. 半導体製造におけるエンタープライズITインフラ
1.3. Security of Semiconductor Manufacturing	1.3. 半導体製造のセキュリティ
1.4. Relationship to CS Core and Manufacturing Profile	1.4. CSコアおよび製造プロファイルとの関係
1.5. Document Organization	1.5. 文書構成
2. Overview of Semiconductor Manufacturing and Operational Systems	2. 半導体製造および運用システムの概要
2.1. Importance of NIST CSF 2.0 in Semiconductor Manufacturing	2.1. 半導体製造におけるNIST CSF 2.0の重要性
3. Overview of CSF 2.0	3. CSF 2.0の概要
3.1. The CSF Core	3.1. CSF コア
3.2. Community Profiles	3.2. コミュニティ・プロファイル
3.3. Applying the NIST CS to Semiconductor Manufacturing	3.3. NIST CSの半導体製造への適用
4. Applying Business and Mission Objectives to Profile Creation	4. プロファイル作成への事業およびミッション目標の適用
4.1. Semiconductor Manufacturing Business and Mission Objectives	4.1. 半導体製造の事業およびミッション目標
4.1.1. Objective 1: Maintain Environmental Safety	4.1.1. 目的 1：環境の安全性を維持する
4.1.2. Objective 2: Maintain Human Safety	4.1.2. 目的 2：人間の安全を維持する
4.1.3. Objective 3: Maintain Production Goals	4.1.3. 目的 3：生産目標を維持する
4.1.4. Objective 4: Maintain the Quality of Semiconductors	4.1.4. 目的 4：半導体の品質を維持する
4.1.5. Objective 5: Protect Sensitive Information	4.1.5. 目的 5：機密情報を保護する
4.2. Aligning Subcategories to Meet Business and Mission Objectives	4.2. ビジネスおよびミッションの目的を達成するためのサブカテゴリーの調整
4.2.1. Govern	4.2.1. ガバナンス
4.2.2. Identify	4.2.2. 識別
4.2.3. Protect	4.2.3. 防御
4.2.4. Detect	4.2.4. 検知
4.2.5. Respond	4.2.5. 対応
4.2.6. Recover	4.2.6. 回復
5. Semiconductor Manufacturing Community Profile Subcategory Guidance	5. 半導体製造コミュニティのプロファイル サブカテゴリーのガイダンス
5.1. Govern	5.1. ガバナンス
5.2. Identify	5.2. 識別
5.3. Protect	5.3. 防御
5.4. Detect	5.4. 検知
5.5. Respond	5.5. 対応
5.6. Recover	5.6. 回復
References	参考文献
Appendix A. Selected Bibliography	附属書 A. 主要参考資料
Appendix B. List of Symbols, Abbreviations, and Acronyms	附属書 B. 記号、略語、および頭字語の一覧
Appendix C. Glossary	附属書 C. 用語集
Appendix D. Figure Descriptions	附属書 D. 図の説明

---

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

NIST IR 8183

・2020.10.13 NIST NISTIR 8183 Rev. 1 Cybersecurity Framework Version 1.1 Manufacturing Profile

・2020.03.05 NISTIR 8183 Rev. 1(Draft) Cybersecurity Framework Version 1.1 Manufacturing Profile

半導体関係...

・2022.02.24 半導体製造業界：SEMI E187 - ファブ装置のサイバーセキュリティに関する仕様 ・ SEMI E188 - マルウェアフリー機器統合のための仕様

・2021.06.11 U.S. White House サプライチェーンの途絶に対処するための取り組み...

米国 NIST IR 8286 Rev. 1（初期公開草案） サイバーセキュリティとエンタープライズリスクマネジメント（ERM）の統合他 (2025.02.26)

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

NISTのIR 8286といえば、サイバーセキュリティとERMを統合させる文書として有名ですが...

以下のように確定版と改訂ドラフトが公表されています...

CSF2.0への改訂に合わせて行われたものですね...

Draft	IR	8286 Rev.1	Integrating Cybersecurity and Enterprise Risk Management (ERM)	サイバーセキュリティとエンタープライズ・リスクマネジメント（ERM）の統合
Draft	IR	8286A Rev.1	Identifying and Estimating Cybersecurity Risk for Enterprise Risk Management	エンタープライズ・リスクマネジメントのためのサイバーセキュリティリスクの識別と評価
Final	IR	8286B	Prioritizing Cybersecurity Risk for Enterprise Risk Management	エンタープライズ・リスクマネジメントのためのサイバーセキュリティリスクの優先順位付け
Draft	IR	8286C Rev.1	Staging Cybersecurity Risks for Enterprise Risk Management and Governance Oversight	エンタープライズ・リスクマネジメントとガバナンスの監督のためのサイバーセキュリティリスクの段階的評価
Final	IR	8286D	Using Business Impact Analysis to Inform Risk Prioritization and Response	ビジネスインパクト分析によるリスクの優先順位付けと対応策の策定

関係...

経済産業省のサイバーセキュリティ経営ガイドライン Ver.3.0もこれを意識して策定されていますね...

⚫︎ NIST - ITL

まずは、本編のドラフト...

・2025.02.26 NIST IR 8286 Rev. 1 (Initial Public Draft) Integrating Cybersecurity and Enterprise Risk Management (ERM)

NIST IR 8286 Rev. 1 (Initial Publi% Draft)　Integrating Cybersecurity and Enterprise Risk Management (ERM)	NIST IR 8286 Rev. 1（初期公開草案） サイバーセキュリティとエンタープライズ・リスクマネジメント（ERM）の統合
Announcement	発表
The NIST Interagency Report (IR) 8286 series of publications helps practitioners better understand the close relationship between cybersecurity and enterprise risk management (ERM). All five publications in the series have been updated to align more closely with the Cybersecurity Framework (CSF) 2.0 and other updated NIST guidance. The updated series puts greater emphasis on cybersecurity governance to highlight the importance of ensuring cybersecurity capabilities support the broader mission through ERM.	NISTの内部報告書（IR）8286シリーズは、サイバーセキュリティとエンタープライズ・リスクマネジメント（ERM）の密接な関係について、実務担当者がより深く理解するのに役立つ。このシリーズの全5刊は、サイバーセキュリティ枠組み（CSF）2.0およびその他の更新されたNISTガイダンスにさらに密接に整合するように更新された。更新されたシリーズでは、サイバーセキュリティ能力がERMを通じてより広範なミッションを確実にサポートすることの重要性を強調するために、サイバーセキュリティガバナンスがより重視されている。
The five updated IR 8286 series publications are:	更新されたIR 8286シリーズの5つの刊行物は以下の通りである。
NIST IR 8286r1 (Revision 1) initial public draft (ipd), Integrating Cybersecurity and Enterprise Risk Management (ERM) — This document is intended to help individual organizations within an enterprise improve their cybersecurity risk information, which they provide as inputs to their enterprise’s ERM processes through communications and risk information sharing.	NIST IR 8286r1（改訂1）初期公開草案（IPD）、サイバーセキュリティとエンタープライズ・リスクマネジメント（ERM）の統合 — この文書は、エンタープライズ内の個々の組織が、コミュニケーションやリスク情報の共有を通じて、エンタープライズのERMプロセスへの入力情報として提供するサイバーセキュリティリスク情報の改善に役立つことを目的としている。
View the publication and submit comments by April 14, 2025.	この文書は2025年4月14日まで閲覧可能であり、意見を提出することができる。
NIST IR 8286Ar1 ipd, Identifying and Estimating Cybersecurity Risk for Enterprise Risk Management  — This document details the context, scenario identification, and analysis of the likelihood and impacts of cybersecurity risk.	NIST IR 8286Ar1 ipd、エンタープライズ・リスクマネジメントのためのサイバーセキュリティリスクの識別と評価 — この文書では、サイバーセキュリティリスクの可能性と影響の文脈、シナリオの識別、分析について詳細に説明している。
View the publication and submit comments by April 14, 2025.	この文書は2025年4月14日まで閲覧可能であり、意見を提出することができる。
NIST IR 8286B-upd1 (Update 1), Prioritizing Cybersecurity Risk for Enterprise Risk Management — This document describes ways to apply risk analysis to help prioritize cybersecurity risk, evaluate and select appropriate risk responses, and communicate risk activities as part of an enterprise cybersecurity risk management strategy.	NIST IR 8286B-upd1 (Update 1)、エンタープライズ・リスクマネジメントのためのサイバーセキュリティリスクの優先順位付け — この文書では、エンタープライズサイバーセキュリティリスクマネジメント戦略の一環として、サイバーセキュリティリスクの優先順位付け、適切なリスク対応の評価と選択、リスク活動のコミュニケーションに役立つリスク分析の適用方法を説明している。
NIST IR 8286Cr1 ipd, Staging Cybersecurity Risks for Enterprise Risk Management and Governance Oversight — This document describes processes for aggregating information from CSRM activities throughout the enterprise.	NIST IR 8286Cr1 ipd、エンタープライズ・リスクマネジメントおよびガバナンスの監督のためのサイバーセキュリティリスクの段階的評価 — この文書では、企業全体にわたるCSRM活動からの情報を集約するプロセスについて説明している。
View the publication and submit comments by April 14, 2025.	この文書を表示し、2025年4月14日までにコメントを提出する。
NIST IR 8286D-upd1, Using Business Impact Analysis to Inform Risk Prioritization and Response — This document describes considerations for documenting and analyzing business impacts that result in a full or partial loss of the confidentiality, integrity, or availability of a mission-essential resource.	NIST IR 8286D-upd1、リスクの優先順位付けと対応策の決定におけるビジネスインパクト分析の利用 — この文書では、ミッションに不可欠なリソースの機密性、完全性、可用性の全部または一部の喪失につながるビジネスへの影響を文書化および分析する際の考慮事項について説明している。
Abstract	概要
The increasing frequency, creativity, and severity of cybersecurity attacks means that all enterprises should ensure that cybersecurity risk is receiving appropriate attention within their enterprise risk management (ERM) programs. This document is intended to help individual organizations within an enterprise improve their cybersecurity risk information, which they provide as inputs to their enterprise’s ERM processes through communications and risk information sharing. By doing so, enterprises and their component organizations can better identify, assess, and manage their cybersecurity risks in the context of their broader mission and business objectives. This document focuses on the use of risk registers to set out cybersecurity risk and explains the value of rolling up measures of risk that are usually addressed at lower system and organizational levels to the broader enterprise level.	サイバーセキュリティ攻撃の頻度、巧妙さ、深刻さが増していることを踏まえ、すべての企業は、サイバーセキュリティリスクが自社のエンタープライズ・リスクマネジメント（ERM）プログラム内で適切な注意を払われていることを確認すべきである。本書は、コミュニケーションやリスク情報の共有を通じて、エンタープライズ・リスクマネジメント（ERM）プロセスにインプットとして提供されるサイバーセキュリティリスク情報の改善を、企業内の各組織が図ることを目的としている。これにより、企業とその構成組織は、より広範なミッションやビジネス目標の観点から、サイバーセキュリティリスクをより適切に識別、アセスメント、管理することが可能となる。本書では、サイバーセキュリティリスクを特定するためのリスクレジスターの利用に焦点を当て、通常はシステムや組織のより低いレベルで対処されるリスクの測定値を、より広範なエンタープライズレベルに集約することの価値について説明している。

・[PDF] NIST.IR.8286r1.ipd

目次...

Executive Summary	エグゼクティブサマリー
1. Introduction	1. 序文
1.1. Purpose and Scope	1.1. 目的と範囲
1.2. Document Structure	1.2. 文書構成
2. Gaps in Managing Cybersecurity Risk as an ERM Input	2. ERM インプットとしてのサイバーセキュリティリスク管理におけるギャップ
2.1. Overview of ERM	2.1. ERM の概要
2.1.1. Common Use of ERM	2.1.1. ERM の一般的な利用
2.1.2. ERM Framework Steps	2.1.2. ERM の枠組みのステップ
2.2. The Gap Between CSRM Output and ERM Input	2.2. CSRM アウトプットと ERM インプットのギャップ
3. Cybersecurity Risk Considerations Throughout the ERM Process	3. ERM プロセス全体におけるサイバーセキュリティリスクの考慮事項
3.1. Identify the Context	3.1. 状況の識別
3.1.1. Notional Risk Management Roles	3.1.1. 概念上のリスクマネジメントの役割
3.1.2. Risk Management Strategy	3.1.2. リスクマネジメント戦略
3.2. Identify the Risks	3.2. リスクの識別
3.2.1. Inventory and Valuation of Assets	3.2.1. 資産の目録作成と評価
3.2.2. Determination of Potential Threats	3.2.2. 潜在的な脅威の特定
3.2.3. Determination of Exploitable and Susceptible Conditions	3.2.3. 悪用可能な状況および脆弱な状況の特定
3.2.4. Evaluation of Potential Consequences	3.2.4. 潜在的な結果の評価
3.3. Analyze the Risks	3.3. リスクの分析
3.3.1. Risk Analysis Types	3.3.1. リスク分析の種類
3.3.2. Techniques for Estimating Likelihood and Impact of Consequences	3.3.2. 結果の発生可能性と影響度を推定する手法
3.4. Prioritize Risks	3.4. リスクの優先順位付け
3.5. Plan and Execute Risk Response Strategies	3.5. リスク対応戦略の計画と実行
3.5.1. Applying Security Controls to Reduce Risk Exposure	3.5.1. リスクエクスポージャーを低減するためのセキュリティ管理策の適用
3.5.2. Responding to Residual Risk	3.5.2. 残留リスクへの対応
3.5.3. When a Risk Event Passes Without Triggering the Event	3.5.3. リスク事象が発生したが、事象がトリガーされることなく経過したずに過場合
3.6. Monitor, Evaluate, and Adjust	3.6. 監視、評価、および調整
3.6.1. Continuous Risk Monitoring	3.6.1. 継続的なリスク監視
3.6.2. Key Risk Indicators and Key Performance Indicators	3.6.2. 主なリスク指標および主な業績評価指標
3.6.3. Continuous Improvement	3.6.3. 継続的な改善
3.7. Considerations of Positive Risks as an Input to ERM	3.7. ERMへのインプットとしてのポジティブリスクの考慮
3.8. Creating and Maintaining an Enterprise-Level Cybersecurity Risk Register	3.8. エンタープライズレベルのサイバーセキュリティリスクレジスターの作成と維持
3.9. Cybersecurity Risk Data Conditioned for Enterprise Risk Roll-Up	3.9. エンタープライズ・リスクの集約に適したサイバーセキュリティリスクデータ
4. Cybersecurity Risk Management as Part of a Portfolio View	4. ポートフォリオの視点の一部としてのサイバーセキュリティ・リスクマネジメント
4.1. Applying the Enterprise Risk Register and Developing the Enterprise Risk Profile	4.1. エンタープライズ・リスクレジスターの適用とエンタープライズ・リスクプロファイルの策定
4.2. Translating the Risk Profile to Inform Leadership Decisions	4.2. リスクプロファイルを経営陣の意思決定に反映させる
4.3. Information and Decision Flows in Support of ERM	4.3. ERMをサポートする情報と意思決定の流れ
4.4. Conclusion	4.4. 結論
References	参考文献
Appendix A. List of Symbols, Abbreviations, and Acronyms	附属書 A. 記号、略語、および頭字語の一覧
Appendix B. Glossary	附属書 B. 用語集
Appendix C. Federal Government Sources for Identifying Risks	附属書 C. リスクを識別するための連邦政府の情報源
Appendix D. Notional Enterprise Risk Register	附属書 D. 想定エンタープライズ・リスクレジスター
Appendix E. Change Log	附属書 E. 変更履歴
List of Tables	表の一覧
Table 1. Descriptions of notional cybersecurity risk register template elements	表1. 想定サイバーセキュリティリスクレジスターテンプレートの要素の説明
Table 2. Response types for negative cybersecurity risks	表2. ネガティブなサイバーセキュリティリスクに対する対応の種類
Table 3. Examples of proactive risk management activities	表3. 積極的なリスクマネジメント活動の例
Table 4. Response types for positive cybersecurity risks	表4. ポジティブなサイバーセキュリティリスクへの対応の種類
Table 5. Excerpt from a notional enterprise risk register	表5. 想定エンタープライズ・リスクレジストリからの抜粋
Table 6. Descriptions of the notional enterprise risk register elements	表6. 想定エンタープライズ・リスクレジストリ要素の説明
Table 7. Illustrative example of a risk profile (derived from [3])	表7. リスクプロファイルの例示 [3]
Table 8. Notional enterprise risk portfolio view for a private corporation	表8. 非公開企業の想定エンタープライズ・リスクポートフォリオビュー
Table 9. Notional enterprise risk register	表9. 想定エンタープライズ・リスクレジストリ
List of Figures	図の一覧
Fig. 1. Enterprise hierarchy for cybersecurity risk management	図1. サイバーセキュリティ・リスクマネジメントのためのエンタープライズ階層
Fig. 2. Notional risk management life cycle	図2. 想定リスクマネジメントライフサイクル
Fig. 3. Risk register information flow among system, organization, and enterprise levels	図3. システム、組織、エンタープライズレベル間のリスクレジスター情報フロー
Fig. 4. Notional cybersecurity risk register template	図4. 想定サイバーセキュリティ・リスクレジスター・テンプレート
Fig. 5. Likelihood and impact matrix derived [15]	図5. 発生可能性と影響度マトリックス[15]
Fig. 6. Example of a quantitative risk matrix	図6. 定量的リスクマトリックスの例
Fig. 7. Excerpt from a notional cybersecurity risk register	図7. 想定サイバーセキュリティ・リスクレジスターからの抜粋
Fig. 8. Integration of CRRs into enterprise risk profile	図8. エンタープライズ・リスクプロファイルへのCRRの統合
Fig. 9. Notional information and decision flows diagram from the CSF	図9. CSF からの想定情報および意思決定フロー図
Fig. 10. Notional information and decision flows diagram with numbered steps	図10. 番号付きステップによる想定情報および意思決定フロー図

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

Executive Summary	エグゼクティブサマリー
For federal agencies, the Office of Management and Budget (OMB) Circular A-11 defines risk as “the effect of uncertainty on objectives” [1]. The effect of uncertainty on enterprise mission and business objectives may then be considered an “enterprise risk” that must be similarly managed. An enterprise is an organization that exists at the top level of a hierarchy with unique risk management responsibilities. Managing risks at that level is known as enterprise risk management (ERM) and calls for understanding the core risks that an enterprise faces, determining how best to address those risks, and ensuring that the necessary actions are taken. In the Federal Government, ERM is considered “an effective agency-wide approach to addressing the full spectrum of the organization’s significant risks by understanding the combined impact of risks as an interrelated portfolio rather than addressing risks only within silos” [1].	連邦政府機関にとって、行政管理予算局（OMB）の通達A-11ではリスクを「目的に対する不確実性の影響」と定義している[1]。 企業ミッションや事業目的に対する不確実性の影響は、「エンタープライズ・リスク」とみなされ、同様に管理される必要がある。 エンタープライズとは、独自のリスクマネジメント責任を担う階層構造の最上位に位置する組織である。そのレベルでのリスクマネジメントはエンタープライズ・リスクマネジメント（ERM）と呼ばれ、企業が直面する主要なリスクを理解し、それらのリスクに最適に対処する方法を決定し、必要な措置が確実に講じられるようにすることが求められる。連邦政府では、ERMは「組織の重要なリスクの全領域に対処するための効果的な機関全体のアプローチであり、リスクをサイロの中でのみ対処するのではなく、相互に関連するポートフォリオとしてリスクの複合的な影響を理解する」ものとされている[1]。
Cybersecurity risk is an important type of risk for any enterprise. Other risks include but are not limited to financial, legal, legislative, operational, privacy, reputational, safety, strategic, and supply chain risks [2]. As part of an ERM program, senior leaders (e.g., corporate officers, government senior executive staff) often have fiduciary and reporting responsibilities that other organizational stakeholders do not, so they have a unique responsibility to holistically manage the combined set of risks, including cybersecurity risk. The individual organizations that comprise every enterprise are experiencing an increase in the frequency, creativity, and severity of cybersecurity attacks. All organizations and enterprises, regardless of size or type, should ensure that cybersecurity risks receive appropriate attention as they carry out their ERM functions. Since enterprises are at various degrees of maturity regarding the implementation of risk management, this document offers NIST’s cybersecurity risk management (CSRM) expertise to help organizations improve the cybersecurity risk information they provide as inputs to their enterprise’s ERM programs.	サイバーセキュリティリスクは、あらゆるエンタープライズにとって重要なリスクのひとつである。その他のリスクには、財務、法律、規制、業務、プライバシー、評判、安全、戦略、サプライチェーンリスクなどがあるが、これらに限定されるものではない。ERMプログラムの一環として、シニアリーダー（企業役員、政府高官など）は、他の組織のステークホルダーにはない受託者責任や報告義務を負うことが多いため、サイバーセキュリティリスクを含む複合的なリスクを総合的に管理する独自の責任を負っている。あらゆる企業を構成する個々の組織は、サイバーセキュリティ攻撃の頻度、巧妙さ、深刻さが増していることを経験している。規模や業種に関わらず、すべての組織や企業は、ERM機能を実行する際に、サイバーセキュリティリスクが適切に考慮されるようにすべきである。企業はリスクマネジメントの導入に関してさまざまな成熟度にあるため、本書では、NISTのサイバーセキュリティ・リスクマネジメント（CSRM）の専門知識を提供し、組織がエンタープライズERMプログラムへのインプットとして提供するサイバーセキュリティリスク情報の改善に役立ててもらう。
Many resources document ERM frameworks and processes, such as well-known frameworks from the Committee of Sponsoring Organizations (COSO), Office of Management and Budget (OMB) circulars, and the International Organization for Standardization (ISO). They generally include similar approaches: identify context, identify risks, analyze risks, estimate risk importance, determine and execute risk response, and identify and respond to changes over time. A critical risk document used to track and communicate risk information for all of these steps throughout the enterprise is called a risk register [1].[1] The risk register provides a formal communication vehicle for sharing and coordinating cybersecurity risk activities as an input to ERM decision-makers. For example, cybersecurity risk registers are key aspects of managing and communicating about those particular risks.[2]	ERMの枠組みやプロセスを文書化したリソースは数多くあり、その中には、委員会組織委員会（COSO）の有名な枠組み、行政管理予算局（OMB）の通達、国際標準化機構（ISO）などがある。これらは一般的に、状況の識別、リスクの識別、リスクの分析、リスクの重要度の推定、リスク対応の決定と実行、そして時間の経過に伴う変化の識別と対応といった、同様のアプローチを含んでいる。これらのステップすべてについて、エンタープライズ全体でリスク情報を追跡し、コミュニケーションを行うために使用される重要なリスク文書は、リスクレジスターと呼ばれる。[1] リスクレジスターは、ERMの意思決定者へのインプットとして、サイバーセキュリティリスク活動を共有し、調整するための正式なコミュニケーション手段を提供する。例えば、サイバーセキュリティリスクレジスターは、それらの特定のリスクを管理し、コミュニケーションを行う上での重要な要素である。[2]
At higher levels in the enterprise structure, those cybersecurity and other risk registers are aggregated, normalized, and prioritized into risk profiles. A risk profile is defined by OMB Circular A-123 as “a prioritized inventory of the most significant risks identified and assessed through the risk assessment process versus a complete inventory of risks” [3]. While it is critical that enterprises address potential negative impacts on mission and business objectives, it is equally critical (and required for federal agencies) that enterprises plan for success. OMB states in Circular A-123 that “the [Enterprise Risk] profile must identify sources of uncertainty, both positive (opportunities) and negative (threats).” Enterprise-level decision-makers use the risk profile to choose which enterprise risks to address, allocate resources, and delegate responsibilities to appropriate risk owners. ERM programs should define terminology, formats, criteria, and other guidance for risk inputs from lower levels of the enterprise.	エンタープライズ構造の上位レベルでは、それらのサイバーセキュリティおよびその他のリスクレジスターは集約され、標準化され、リスクプロファイルとして優先順位付けされる。リスクプロファイルは、OMB通達A-123により、「リスクアセスメントプロセスを通じて識別およびアセスメントされた最も重大なリスクの優先順位付きインベントリであり、リスクの完全なインベントリではない」と定義されている[3]。企業がミッションや事業目標に対する潜在的な悪影響に対処することは極めて重要であるが、企業が成功を計画することも同様に重要である（連邦政府機関には必須である）。OMBは通達A-123において、「（エンタープライズ・リスク）プロファイルは、ポジティブな（機会）側面とネガティブな（脅威）側面の両方における不確実性の原因を識別しなければならない」と述べている。 エンタープライズレベルの意思決定者は、リスクプロファイルを使用して、どのエンタープライズ・リスクに対処するかを決定し、リソースを割り当て、適切なリスクオーナーに責任を委任する。 ERMプログラムは、エンタープライズのより下位レベルからのリスクインプットに関する用語、フォーマット、規準、その他のガイダンスを定義すべきである。
Cybersecurity risk inputs to ERM programs should be documented and tracked in written cybersecurity risk registers[3] that comply with the ERM program guidance. However, many enterprises do not communicate their cybersecurity risk guidance or risk responses in consistent, repeatable ways. Methods such as quantifying cybersecurity risk in dollars and  aggregating cybersecurity risks are often ad hoc and are sometimes not performed with the same rigor as methods for quantifying other types of risk within the enterprise.	ERMプログラムへのサイバーセキュリティリスクのインプットは、ERMプログラムのガイダンスに準拠した書面によるサイバーセキュリティリスクレジスター[3]に記録し、追跡すべきである。しかし、多くの企業はサイバーセキュリティリスクのガイダンスやリスク対応について、一貫性のある再現可能な方法でコミュニケーションを行っていない。サイバーセキュリティリスクを金額で定量化したり、サイバーセキュリティリスクを集約したりする方法は、多くの場合、その場限りの対応であり、企業内の他のタイプのリスクを定量化する方法ほど厳密に実施されていないこともある。
In addition to widely using cybersecurity risk registers, improving the risk measurement and analysis methods used in CSRM will boost the quality of the risk information provided to ERM. In turn, this practice promotes better management of cybersecurity at the enterprise level and correlates directly with the enterprise’s objectives.	サイバーセキュリティリスクレジストリを広く使用することに加え、CSRMで使用されるリスク測定および分析方法を改善することで、ERMに提供されるリスク情報の質が向上する。その結果、この手法はエンタープライズレベルでのサイバーセキュリティのより良い管理を促進し、企業の目標と直接相関する。
CSRM and ERM are concurrent cycles with many points of commonality and integration. NIST framework documents, specifically the Cybersecurity Framework (CSF) 2.0 and Special Publication (SP) 800-221A, provide methods for performing CSRM and integrating the results. The concepts detailed in this IR 8286 series are directly incorporated into both the CSF 2.0 (CSRM) and SP 800-221A (integrating with ERM) frameworks. Improving the measurement and communications methods used (e.g., using cybersecurity risk registers) can improve the quality of risk information, promote enterprise-wide CSRM, and support enterprise-level decision making in language that is already understood by senior executives. Improved communications will also help executives and corporate officers understand the challenges that cybersecurity professionals face when providing the information that they are accustomed to receiving for other types of risk.	CSRMおよびERMを改善することは、多くの共通点と統合点を持つ同時進行のサイクルである。NIST枠組み文書、特にサイバーセキュリティ枠組み（CSF）2.0および特別刊行物（SP）800-221Aは、CSRMの実行と結果の統合のための方法を提供している。IR 8286シリーズで詳細に説明されている概念は、CSF 2.0（CSRM）およびSP 800-221A（ERMとの統合）の両方の枠組みに直接組み込まれている。使用する測定およびコミュニケーションの方法（例えば、サイバーセキュリティリスクレジストリの使用）を改善することで、リスク情報の質が向上し、全社的なCSRMが促進され、経営幹部がすでに理解している言語で企業レベルの意思決定をサポートすることができる。また、コミュニケーションの改善は、経営陣や企業役員が、サイバーセキュリティの専門家が他の種類のリスクについて受け取ることになれている情報と同じものを入手する際に直面する課題を理解する上でも役立つ。
[1] OMB Circular A-11 defines a risk register as “a repository of risk information including the data understood about risks over time” [1].	[1] OMB通達A-11では、リスクレジストリを「リスクに関する経時的な理解データを含むリスク情報の保管場所」と定義している。[1]
[2] Organizations creating a risk management program for the first time should not wait until the risk register is completed before addressing obvious issues. However, over time, it should become the ordinary means of communicating risk information.	[2] 初めてリスクマネジメントプログラムを作成する組織は、明らかな問題に対処する前にリスクレジストリが完成するのを待つべきではない。しかし、時が経つにつれ、リスク情報を伝達する通常の手段となるべきである。
[3] Formats include risk register data displayed on dashboards, GRC tools, and file formats for communicating risk register data, such as the spreadsheet (CSV) and JSON formats.	[3] フォーマットには、ダッシュボードに表示されるリスクレジストリデータ、GRCツール、リスクレジストリデータを伝達するためのファイルフォーマット（スプレッドシート（CSV）やJSONフォーマットなど）がある。

リスクマネジメントの全体像...

システム、組織、エンタープライズの各レベルにおけるリスクレジストリの情報フロー

---

・2025.02.25 NIST IR 8286A Rev. 1 (Initial Public Draft Identifying and Estimating Cybersecurity Risk for Enterprise Risk Management

NIST IR 8286A Rev. 1 (Initial Public Draft) Identifying and Estimating Cybersecurity Risk for Enterprise Risk Management	NIST IR 8286A Rev. 1（初期公開草案） エンタープライズ・リスクマネジメントのためのサイバーセキュリティリスクの識別と評価
Abstract	概要
This document supplements NIST Interagency Report 8286, Integrating Cybersecurity and Enterprise Risk Management (ERM), by providing additional detail regarding risk guidance, identification, and analysis. This report offers examples and information to illustrate risk tolerance, risk appetite, and methods for determining risks in that context. To support the development of an Enterprise Risk Register, this report describes documentation of various scenarios based on the potential impact of threats and vulnerabilities on enterprise assets. Documenting the likelihood and impact of various threat events through cybersecurity risk registers integrated into an enterprise risk profile helps to later prioritize and communicate enterprise cybersecurity risk response and monitoring. This document has been updated to reflect changes in other NIST documentation (IR 8286 series, SP 800-221/221A, and Cybersecurity Framework 2.0).	本書は、NIST内部報告書8286「サイバーセキュリティとエンタープライズ・リスクマネジメント（ERM）の統合」を補足するものであり、リスクに関する指針、識別、分析に関する詳細情報を提供する。本報告書では、リスク許容度、リスク選好度、およびその文脈におけるリスクの決定方法を示すための例や情報を提供する。エンタープライズ・リスクレジストリの開発を支援するために、本報告書では、企業資産に対する脅威や脆弱性の潜在的な影響に基づくさまざまなシナリオの文書化について説明する。サイバーセキュリティリスクレジストリをエンタープライズ・リスクプロファイルに統合することで、さまざまな脅威事象の可能性と影響を文書化し、その後のエンタープライズサイバーセキュリティリスク対応とモニタリングの優先順位付けとコミュニケーションに役立てることができる。この文書は、他のNIST文書（IR 8286シリーズ、SP 800-221/221A、およびサイバーセキュリティフレームワーク2.0）の変更を反映して更新されている。

・[PDF] NIST.IR.8286Ar1.ipd

 

目次...

Executive Summary	エグゼクティブサマリー
1. Introduction	1. 序文
1.1. Supporting CSRM as an Integrated Component of ERM	1.1. ERMの統合要素としてのCSRMのサポート
1.2. Purpose and Scope	1.2. 目的と範囲
1.3. Document Structure	1.3. 文書構成
2. Cybersecurity Risk Considerations Throughout the ERM Process	2. ERMプロセス全体におけるサイバーセキュリティリスクの考慮事項
2.1. Risk Scope, Context, and Criteria	2.1. リスクの範囲、コンテクスト、規準
2.1.1. Risk Appetite and Risk Tolerance	2.1.1. リスク選好度とリスク許容度
2.1.2. Enterprise Strategy for Cybersecurity Risk Coordination	2.1.2. サイバーセキュリティリスク調整のためのエンタープライズ戦略
2.1.3. Detailed Risk Integration Strategy	2.1.3. 詳細なリスク統合戦略
2.1.4. Enterprise Strategy for Cybersecurity Risk Reporting	2.1.4. サイバーセキュリティリスク報告のためのエンタープライズ戦略
2.2. Risk Identification	2.2. リスクの識別
2.2.1. Inventory and Valuation of Assets	2.2.1. 資産の目録作成と評価
2.2.1.1. Business Impact Analysis	2.2.1.1. 事業への影響分析
2.2.1.2. Determination of High-Value Assets	2.2.1.2. 高価値資産の決定
2.2.1.3. Automation Support for Inventory Accuracy	2.2.1.3. 目録の正確性を確保するための自動化サポート
2.2.2. Determination of Potential Threats	2.2.2. 潜在的な脅威の特定
2.2.2.1. Threat Enumeration	2.2.2.1. 脅威の列挙
2.2.2.2. Reducing Unwanted Bias in Threat Considerations	2.2.2.2. 脅威の考慮における不要なバイアスの低減
2.2.2.3. Threat Enumeration Through SWOT Analysis	2.2.2.3. SWOT分析による脅威の列挙
2.2.2.4. Use of Gap Analysis to Identify Threats	2.2.2.4. ギャップ分析による脅威の識別
2.2.2.5. Technical Threat Enumeration	2.2.2.5. 技術的な脅威の列挙
2.2.3. Vulnerability Identification	2.2.3. 脆弱性の識別
2.2.3.1. Determination of Vulnerabilities and Predisposing Conditions	2.2.3.1. 脆弱性および素因状態の特定
2.2.3.2. System Complexity as a Vulnerability	2.2.3.2. 脆弱性としてのシステムの複雑性
2.2.3.3. Vulnerability Identification Automation	2.2.3.3. 脆弱性の自動識別
2.2.4. Determining Potential Impact	2.2.4. 潜在的な影響の特定
2.2.5. Recording Identified Risks	2.2.5. 識別されたリスクの記録
2.2.6. Risk Categorization	2.2.6. リスクの分類
2.3. Detailed Risk Analysis	2.3. 詳細なリスク分析
2.3.1. Selecting Risk Analysis Methodologies	2.3.1. リスク分析方法の選択
2.3.2. Techniques for Estimating Likelihood and Impact	2.3.2. 発生可能性と影響度の推定手法
2.3.2.1. Improving Estimation Based on Knowledge of Prior Events	2.3.2.1. 過去の事象に関する知識に基づく推定の改善
2.3.2.2. Three-Point Estimation	2.3.2.2. 三点推定
2.3.2.3. Event Tree Analysis	2.3.2.3. イベントツリー分析
2.3.2.4. Monte Carlo Simulation	2.3.2.4. モンテカルロ・シミュレーション
2.3.2.5. Bayesian Analysis	2.3.2.5. ベイズ分析
2.4. Determination and Documentation of Risk Exposure	2.4. リスクエクスポージャーの決定と文書化
3. Conclusion	3. 結論
References	参考文献
Appendix A. List of Symbols, Abbreviations, and Acronyms Appendix B. Notional Example of a Risk Detail Record (RDR)	附属書 A. 記号、略語、および頭字語の一覧 附属書 B. リスク詳細レコード（RDR）の想定例
Appendix C. Change Log	附属書 C. 変更履歴
List of Tables	表一覧
Table 1. Notional examples of risk appetite and risk tolerance	表1. リスク選好度とリスク許容度の想定例
Table 2. Inputs and outputs for ERM governance and integrated CSRM	表2. ERM ガバナンスと統合 CSRM の入力と出力
Table 3. Example threat modeling analysis	表3. 脅威モデリング分析の例
Table 4. Example bias issues to avoid in risk management	表4. リスクマネジメントで回避すべきバイアス問題の例
Table 5. Example SWOT analysis	表5. SWOT分析の例
Table 6. Cybersecurity Framework current state profiles help consider threats	表6. サイバーセキュリティ枠組みの現状プロファイルは脅威の検討に役立つ
Table 7. Example sources of threat information	表7. 脅威情報の情報源の例
Table 8. Example negative and positive impact scenarios	表8. ネガティブおよびポジティブな影響シナリオの例
Table 9. Example risk tolerance results assessment	表9. リスク許容度の結果アセスメントの例
Table 10. Notional risk detail record	表10. 想定リスク詳細レコード
List of Figures	図の一覧
Fig. 1. IR 8286 series publications describe detailed CSRM/ERM integration	図1. IR 8286シリーズの出版物は、詳細なCSRM/ERM統合について説明している
Fig. 2. IR 8286A activities as part of CSRM/ERM integration	図2. IR 8286Aの活動は、CSRM/ERM統合の一部である
Fig. 3. Integration of various risk management activities into the enterprise risk register and risk profile	図3. エンタープライズ・リスクレジスタおよびリスクプロファイルへの各種リスクマネジメント活動の統合
Fig. 4. Notional cybersecurity risk register template	図4. 想定されるサイバーセキュリティリスクレジスタのテンプレート
Fig. 5. Illustration of enterprise risk and coordination	図5. エンタープライズ・リスクと調整の説明
Fig. 6. Continuous interaction between ERM and CSRM using the risk register	図6：リスクレジストリを使用したERMとCSRMの継続的な相互作用
Fig. 7. CSRR highlighting risk description column	図7：リスク説明欄を強調したCSRR
Fig. 8. Inputs to risk scenario identification	図8：リスクシナリオの特定への入力
Fig. 9. Threats as an input to risk scenario identification (Part B)	図9：リスクシナリオの特定への入力としての脅威（パートB）
Fig. 10. Vulnerability inputs to risk scenario identification (Part C)	図10：リスクシナリオの特定への入力としての脆弱性（パートC）
Fig. 11. Adverse impact inclusion in risk scenario identification (Part D)	図11：リスクシナリオの特定への悪影響の包含（パートD）
Fig. 12. Example risk register with sample risk descriptions	図12：リスク記述のサンプルを含むリスクレジストリの例
Fig. 13. CSRR highlighting risk category and current assessment columns	図13：リスクカテゴリーと現在のアセスメント欄を強調したCSRR
Fig. 14. Example three-point estimate graph (triangle distribution)	図14：3点推定グラフの例（三角分布
Fig. 15. Example three-point estimate graph (normal distribution)	図15：3点推定グラフの例（正規分布
Fig. 16. Example event tree analysis	図16：イベントツリー分析の例
Fig. 17. Illustration of a histogram from a Monte Carlo estimation simulation	図17：モンテカルロ推定シミュレーションによるヒストグラムの例
Fig. 18. Example quantitative analysis results	図18. 定量的分析結果の例
Fig. 19. Example qualitative analysis results	図19. 定性的分析結果の例
Fig. 20. Use of a cybersecurity risk register improves risk communications	図20. サイバーセキュリティリスクレジストリの利用によるリスクコミュニケーションの改善

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

Executive Summary	エグゼクティブサマリー
All organizations face a broad array of risks, including cybersecurity risk. For federal agencies, the Office of Management and Budget (OMB) Circular A-11 defines risk as “the effect of uncertainty on objectives.” An organization’s mission and business objectives can be impacted by such effects and must be managed at various levels within the organization.	あらゆる組織は、サイバーセキュリティリスクを含むさまざまなリスクに直面している。連邦政府機関の場合、行政管理予算局（OMB）の通達A-11では、リスクを「目的に対する不確実性の影響」と定義している。組織のミッションや事業目標は、このような影響を受ける可能性があり、組織内のさまざまなレベルで管理する必要がある。
This report highlights aspects of cybersecurity risk management (CSRM) inherent to enterprises, organizations, and systems. The terms organization and enterprise are often used interchangeably; however, without an understanding of organizational structure, effective risk management is impossible. For the purposes of this document, an organization is defined as an entity of any size, complexity, or position within a larger organizational structure. The enterprise exists at the top level of the hierarchy where senior leaders have unique risk governance responsibilities. Each enterprise, such as a corporation or government agency, is comprised of organizations supported by systems. This report describes CSRM activities at each level.	本レポートでは、企業、組織、システムに内在するサイバーセキュリティ・リスクマネジメント（CSRM）の側面を強調する。組織とエンタープライズという用語は、しばしば互換的に使用されるが、組織構造を理解しなければ、効果的なリスクマネジメントは不可能である。本書では、組織を、より大きな組織構造内のあらゆる規模、複雑性、または位置付けの事業体と定義する。エンタープライズは、シニアリーダーが独自のリスクガバナンス責任を負う階層の最上位に存在する。企業や政府機関などの各エンタープライズは、システムによってサポートされる組織によって構成される。本報告書では、各レベルにおけるCSRMの活動を説明する。
Note that there may be iterative levels within the enterprise and that positions may be relative. For example, a given enterprise (e.g., a bureau or corporate division) may represent an organization to the overarching agency or corporation.	エンタープライズ内に反復的なレベルが存在する場合や、役職が相対的な場合があることに留意されたい。例えば、特定のエンタープライズ（局や企業ディビジョンなど）が、包括的な機関や企業に対する組織の代表者となる場合がある。
Enterprise risk management (ERM) calls for understanding the core (i.e., significant) risks that an organization faces, and this document provides supplemental guidance for aligning cyber security risks within an organization’s overall ERM program. Lessons learned from historical cybersecurity incidents demonstrate the importance of collaboration among CSRM and ERM. This document helps enterprises to apply, improve, and monitor the quality of that cooperation and communication.	エンタープライズ・リスクマネジメント（ERM）では、組織が直面する主要な（すなわち、重要な）リスクを理解することが求められる。本書では、組織の全体的なERMプログラム内でサイバーセキュリティリスクを調整するための補足的なガイダンスを提供する。過去のサイバーセキュリティインシデントから得られた教訓は、CSRMとERM間の連携の重要性を示している。本書は、企業が連携とコミュニケーションの質を適用、改善、監視するのに役立つ。
This NIST Interagency Report (IR) is part of a series of publications supporting IR 8286, Integrating Cybersecurity and Enterprise Risk Management (ERM) [1]. Each publication in the series, illustrated in Fig. 1, provides additional detail and guidance to supplement topics in that document:	このNIST機関間報告書（IR）は、IR 8286『サイバーセキュリティとエンタープライズ・リスクマネジメント（ERM）の統合』[1]をサポートする一連の出版物の一部である。図1に示されているように、このシリーズの各出版物は、その文書のトピックを補足する追加の詳細とガイダンスを提供している。
• IR 8286A (this report) provides additional detail regarding risk context, scenario identification, and analysis of likelihood and impact. It also includes methods to convey risk information, such as through cybersecurity risk registers (CSRRs) and risk detail records (RDRs). Similar processes, and the general use of risk registers, are helpful to identify and manage other types of risk, including those for Cyber Supply Chain and Privacy.	• IR 8286A（本書）では、リスクの背景、シナリオの識別、可能性と影響の分析に関する詳細が提供されている。また、サイバーセキュリティリスクレジストリ（CSRR）やリスク詳細レコード（RDR）などを通じたリスク情報の伝達方法も記載されている。同様のプロセスやリスクレジストリの一般的な使用は、サイバーサプライチェーンやプライバシーに関するリスクなど、他のタイプのリスクの識別や管理にも役立つ。
• IR 8286B [2] describes ways to apply risk analysis to prioritize cybersecurity risk, evaluate and select appropriate risk response, and communicate risk activities as part of an enterprise CSRM strategy.	• IR 8286B [2] では、企業 CSRM 戦略の一環として、リスク分析を適用してサイバーセキュリティリスクの優先順位付けを行い、適切なリスク対応を評価・選択し、リスク活動のコミュニケーションを行う方法を説明している。
• IR 8286C [3] describes processes for aggregating information from CSRM activities throughout the enterprise. As that information is integrated and harmonized, organizational and enterprise leaders monitor achievement of risk objectives, consider any changes to risk strategy, and use the combined information to maintain awareness of risk factors and positive risks (or opportunities).	• IR 8286C [3] では、企業全体における CSRM 活動からの情報を集約するプロセスを説明している。その情報が統合され、調整されると、組織およびエンタープライズのリーダーはリスク目標の達成状況を監視し、リスク戦略の変更を検討し、統合された情報を使用してリスク要因とポジティブリスク（または機会）に対する認識を維持する。
• IR 8286D [4] describes specific considerations for the documentation and analysis of business impacts that result in a full or partial loss of the confidentiality, integrity, or availability of a mission-essential resource.	• IR 8286D [4] は、ミッションに不可欠なリソースの機密性、完全性、または可用性の全部または一部の損失につながる事業への影響の文書化と分析に関する具体的な考慮事項を説明している。
Fig. 1. IR 8286 series publications describe detailed CSRM/ERM integration	図1 IR 8286シリーズの刊行物は、CSRM/ERM統合の詳細を説明している
A key CSRM success factor is setting leadership expectations, such as through risk appetite and risk tolerance. Section 2.1 of this report provides examples of setting and communicating those expectations and provides input into Sec. 2.2, which describes methods for identifying CSRM scenarios. Each of the potential risk scenarios are analyzed, as described in Sec. 2.3, to consider specific likelihood and impact on the organization. Throughout these processes, risk data is developed and recorded in cybersecurity risk registers (and risk detail records) in support of ongoing risk communication. This information becomes the input to risk prioritization and response, which is described in IR 8286B.	CSRMの成功要因の鍵となるのは、リスク許容度やリスク許容度などを通じたリーダーシップの期待値の設定である。本報告書のセクション2.1では、これらの期待値の設定とコミュニケーションの例を示し、セクション2.2のCSRMシナリオの識別方法に関するインプットを提供する。各潜在的なリスクシナリオは、セクション2.3で説明されているように分析され、組織への具体的な可能性と影響を考慮する。これらのプロセス全体を通じて、リスクデータは、継続的なリスクコミュニケーションを支援するために、サイバーセキュリティリスクレジストリ（およびリスク詳細記録）に開発され、記録される。この情報は、リスクの優先順位付けと対応への入力となり、これはIR 8286Bで説明されている。

---

・2025.02.25 NIST IR 8286B Prioritizing Cybersecurity Risk for Enterprise Risk Management

NIST IR 8286B Prioritizing Cybersecurity Risk for Enterprise Risk Management	NIST IR 8286B エンタープライズ・リスクマネジメントのためのサイバーセキュリティリスクの優先順位付け
Abstract	概要
This document is the second in a series that supplements NIST Interagency Report (IR) 8286, Integrating Cybersecurity and Enterprise Risk Management (ERM). This series provides additional detail regarding the enterprise application of cybersecurity risk information; the previous document, NIST IR 8286A, provided detail regarding stakeholder risk guidance and risk identification and analysis. This second publication describes the need for determining the priorities of each of those risks in light of their potential impact on enterprise objectives, as well as options for properly treating that risk. This report describes how risk priorities and risk response information are added to the cybersecurity risk register (CSRR) in support of an overall enterprise risk register. Information about the selection of and projected cost of risk response will be used to maintain a composite view of cybersecurity risks throughout the enterprise, as detailed in NIST IR 8286C. These composite views may be used to confirm and, if necessary, adjust risk strategy to ensure mission success.	本書は、NIST 内部報告書（IR）8286「サイバーセキュリティとエンタープライズ・リスクマネジメント（ERM）の統合」を補足するシリーズの第2巻である。このシリーズでは、サイバーセキュリティリスク情報のエンタープライズ・アプリケーションに関する詳細情報を提供する。前巻のNIST IR 8286Aでは、利害関係者のリスクガイダンスとリスクの識別および分析に関する詳細情報を提供した。この第2の文書では、エンタープライズの目標に対する潜在的な影響を考慮して、それらのリスクの優先順位を決定する必要性、およびリスクを適切に処理するための選択肢について説明している。この報告書では、エンタープライズ全体のリスクレジストリをサポートするために、リスクの優先順位とリスク対応情報がサイバーセキュリティリスクレジストリ（CSRR）に追加される方法について説明している。リスク対応の選択と予測コストに関する情報は、NIST IR 8286Cで詳細に説明されているように、エンタープライズ全体のサイバーセキュリティリスクの複合的な見解を維持するために使用される。これらの複合的な見解は、ミッションの成功を確実にするためにリスク戦略を確認し、必要に応じて調整するために使用される可能性がある。

・[PDF] NIST.IR.8286B-upd1

・[DOCX][PDF] 仮訳

目次...

Executive Summary	エグゼクティブサマリー
1. Introduction	1. 序文
1.1. Purpose and Scope	1.1. 目的と範囲
1.2. Supporting the Risk Management Cycle	1.2. リスクマネジメント・サイクルの支援
1.3. Supporting the Enterprise Cybersecurity Risk Life Cycle	1.3. エンタープライズのサイバーセキュリティリスクライフサイクルの支援
1.4. Document Structure	1.4. 文書構造
2. Cybersecurity Risk Considerations	2. サイバーセキュリティリスクに関する考察
2.1. Assessment, Response, and Monitoring Across Enterprise Levels	2.1. エンタープライズ・レベルでのアセスメント、対応、モニタリング
2.2. Prioritizing Cybersecurity Risks	2.2. サイバーセキュリティリスクの優先順位付け
2.2.1. Factors Influencing Prioritization	2.2.1. 順位付けに影響を与える要因
2.2.2. Cybersecurity Risk Optimization	2.2.2. サイバーセキュリティリスクの最適化
2.2.3. Cybersecurity Risk Priorities at Each Enterprise Level	2.2.3. 各エンタープライズレベルにおけるサイバーセキュリティリスクの優先順位
2.2.4. Considerations of Positive Risks as an Input to ERM	2.2.4. ERMのインプットとしてのポジティブ・リスクの検討
2.2.5. Visualizing Risk Priority	2.2.5. リスクの優先順位を可視化する
2.3. Selection of Risk Response Types	2.3. リスク対応タイプの選択
2.3.1. Risk Acceptance	2.3.1. リスクの受容
2.3.2. Risk Avoidance	2.3.2. リスク回避
2.3.3. Risk Transfer	2.3.3. リスク移転
2.3.4. Risk Mitigation	2.3.4. リスク緩和
2.3.5. Relationship of Risk Response to Risk Strategy	2.3.5. リスク対応とリスク戦略の関係
2.3.6. Implicit Acceptance	2.3.6. 暗黙の受容
2.3.7. Responding to Positive Risk Scenarios	2.3.7. 積極的なリスクシナリオへの対応
2.4. Finalizing the Cybersecurity Risk Register	2.4. サイバーセキュリティリスク登録簿の最終化
2.4.1. Risk Response Cost	2.4.1. リスク対応コスト
2.4.2. Risk Response Description	2.4.2. リスク対応
2.4.3. Risk Owner	2.4.3. リスクオーナー
2.4.4. Status	2.4.4. ステータス
2.5. Conditioning Cybersecurity Risk Register for Enterprise Risk Rollup	2.5. エンタープライズリスクロールアップのためのサイバーセキュリティリスク登録の調整
3. Conclusion	3. 結論
References	参考文献
Appendix A. List of Symbols, Abbreviations, and Acronyms	附属書A. 記号、略語、頭字語のリスト
Appendix B. Change Log	附属書B. 変更履歴

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

Executive Summary	エグゼクティブサマリー
All organizations face a broad array of risks, including cybersecurity risks. For U.S. Federal Government agencies, the Office of Management and Budget (OMB) Circular A-11 defines risk as “the effect of uncertainty on objectives” [1]. An organization’s business objectives can be impacted by such effects, so this uncertainty must be managed at various hierarchical levels.	すべての組織は、サイバーセキュリティリスクを含む広範なリスクに直面している。米国連邦政府機関の場合、行政管理予算局（OMB）の通達 Circular A-11 では、リスクを定義している 「性の影響」と目的に対する不確実[1]。組織の事業目標はこのような影響によって影響を受ける可能性があるため、この不確実性はさまざまな階層レベルで管理されなければならない
This report highlights Cybersecurity Risk Management (CSRM) aspects that are inherent to enterprises, organizations, and systems. The terms organization and enterprise are often used interchangeably; for the purposes of this document, both an organization and an enterprise are defined as an entity of any size, complexity, or positioning within a larger organizational structure. The term enterprise level refers to the top level of the hierarchy where senior leaders have unique risk governance responsibilities. Each enterprise, such as a corporation or government agency, is comprised of organizations supported by systems.[1] The term organizational level refers to the various middle levels of the hierarchy between the system level (lowest level) and the enterprise level (highest level).	本報告書では、エンタープライズ、組織、システムに固有のサイバーセキュリティリスクマネジメント（CSRM） の側面に焦点を当てる。用語は組織とエンタープライズという、しばしば互換的に使用される。本書では、両方を組織とエンター プライズの、より大きな組織構造の中でのあらゆる規模、複雑さ、位置づけの事業体として定義する。用語はエンタープライズレベルという、シニアリーダーが独自のリスクガバナンス責任を有する 階層の最上位レベルを指す。企業や政府機関などの各エンタープライズは、構成されている�システムに支えられた組織で[1]�組織レベルという用語は、間の階層の様々な中間レベルを指す。 システムレベル（最下位レベル）とエンタープライズレベル（最上位レ ベル）の階層の様々な中間レベルを指す。
Enterprise risk management (ERM) calls for understanding the key risks that an organization faces. This document provides supplemental guidance for aligning cybersecurity risks with an organization’s overall ERM program. To minimize the extent to which cybersecurity risks impede enterprise missions and objectives, there must be effective collaboration among CSRM and ERM managers. This document helps enterprises apply, improve, and monitor the quality of that cooperation and communication.	エンタープライズリスクマネジメント（ERM）では、組織が直面する主要なリスクを理解することが求められる。本文書は、サイバーセキュリティリスクを組織の ERM プログラム全体と整合させるための補足ガイダンスを提供する。サイバーセキュリティリスクがエンタープライズのミッションや目標を阻害する程度を最小化するためには、CSRM と ERM のマネジャーが効果的に連携する必要がある。本書は、エンタープライズがその協力とコミュニケーションの質を適用、改善、監視することを支援するものである。
This NIST Interagency Report (IR) is part two of a five-part series supporting NIST IR 8286, Integrating Cybersecurity and Enterprise Risk Management (ERM) [2].	このNIST Interagency Report（IR）は、NIST IR 8286「を支援する5部構成のシリーズの第2部である。 サイバーセキュリティとエンタープライズリスクマネジメント（ERM）の統合」[2]
Fig. 1. NIST IR 8286 series publications describe detailed CSRM/ERM integration	図1. NIST IR 8286シリーズ刊行物には、CSRM/ERM統合の詳細が記載されている。
Fig. 1 illustrates that additional detail and guidance are provided in each report:	図1は、各レポートに追加の詳細とガイダンスがプロバイダとして提供されていることを示している：
• NIST IR 8286A [3] provides detail regarding cybersecurity risk context, scenarios, and analysis of likelihood and impact. It includes methods to convey risk information, such as cybersecurity risk registers (CSRRs) and risk detail records (RDRs).	• NIST IR 8286A [3]は、サイバーセキュリティリスクの背景、シナリオ、可能性と影響の分析に関する詳細を提 供する。また、サイバーセキュリティリスクレジス タ（CSRR）やリスク詳細記録（RDR）など、リスク情報を伝達する方法も含まれている。
• NIST IR 8286B (this report) describes ways to apply risk analysis to help prioritize cybersecurity risk, evaluate and select appropriate risk response, and communicate risk activities as part of an enterprise CSRM strategy.	• NIST IR 8286B（本報告書）では、エンタープライズ CSRM 戦略の一環として、サイバーセキュリティリスクの優先順位付け、適切なリスク対応の評価と選択、リスク活動のコミュニケーションに役立つリスク分析の適用方法を説明している。
• The next document in this series, NIST IR 8286C [4], describes processes for aggregating information from CSRM activities throughout the enterprise. As that information is integrated and harmonized, organizational and enterprise leaders monitor the achievement of risk objectives, consider any changes to risk strategy, and use the	• 本シリーズの次の文書であるNIST IR 8286C [4]では、エンタープライズ全体のCSRM活動からの情報を集約するためのプロセスについて記述している。これらの情報が統合され調和されるにつれて、組織及びエンタープライズのリーダーは、リスク目標の達成状況を監視し、リスク戦略の変更を検討し、CSRM活動から得られた情報を活用する。
combined information to maintain awareness of risk factors and positive risks (or opportunities).	リスク要因とポジティブなリスク（または機会）に対する認識を維持するために、情報を組み合わせる。
• NIST IR 8286D [5] describes the identification and management of risk as it propagates from system to organization and from organization to enterprise, which in turn better informs ERM deliberations. It expands typical business impact analysis (BIA) discussions to inform risk prioritization and response by quantifying the organizational impact and enterprise consequences of compromised IT assets.	• NIST IR 8286D [5]では、システムから組織へ、組織からエンタープライズへと伝播するリスクの識別とマネジメントについて説明しており、ERMの検討によりよい情報を提供する。これは、典型的なビジネスインパクト分析（BIA）の議論を拡張し、危殆化したIT資産が組織に与える影響とエンタープライズに与える影響を定量化することによって、リスクの優先順位付けと対応に情報を提供するものである。
All participants in the enterprise who play a role in CSRM and/or ERM should use consistent methods to prioritize and respond to risk, including methods for communicating results. This report provides guidance for applying a consistent risk strategy at all enterprise levels (Section 2.1). Based on the risk identification and risk analysis described in NIST IR 8286A and the BIA conducted in NIST IR 8286D, NIST IR 8286B provides recommendations for determining, responding to, and reporting the relative priorities of risks, as documented in the CSRR, in light of the enterprise’s risk strategy (Section 2.2), selecting risk response actions (Section 2.3), finalizing the CSRR (Section 2.4), and conditioning results in preparation for risk report aggregation (Section 2.5). These enriched CSRRs can be aggregated, normalized, analyzed, and optimized as detailed in NIST IR 8286C.	CSRM及び／又はERMの役割を果たすエンタープライズのすべての参加者は、結果のコミュニケーショ ン方法を含め、リスクの優先順位付けと対応に一貫した方法を用いるべきである。本報告書は、すべてのエンタープライズレベルで一貫したリスク戦略を適用するためのガイダンスを提供する（セクション2.1）。NIST IR 8286Aに記載されたリスク識別及びリスク分析、並びにNIST IR 8286Dで実施されたBIAに基づき、NIST IR 8286Bは、CSRRに文書化されたリスクの相対的な優先順位を、決定、対応及び報告するための推奨事項推奨事項ための推奨ための推奨）を提供している。エンタープライズのリスク戦略に照らして（セクション2.2）、選択するためのリスク対応アクションを（セクション2.3）、CSRRを最終化する事項（セクション2.4）、リスク報告書の集計に備えて結果を調整する事項（セクション2.5これらの強化された CSRR は、NIST IR 8286C に詳述されているように、集計、正規化、分析、及び最適化することができる。
[1] A system is defined as “a discrete set of information resources organized expressly for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information.”	[1]システムとは、「定義される情報の収集、処理、保守、利用、共有、普及、処分のために明示的に組織された。 情報資源の個別集合

---

・2025.02.25 NIST IR 8286C Rev. 1 (Initial Public Draft) Staging Cybersecurity Risks for Enterprise Risk Management and Governance Oversight

NIST IR 8286C Rev. 1 (Initial Public Draft) Staging Cybersecurity Risks for Enterprise Risk Management and Governance Oversight	NIST IR 8286C Rev. 1（初期公開ドラフト） エンタープライズ・リスクマネジメントおよびガバナンスの監督のためのサイバーセキュリティリスクの段階的評価
Abstract	概要
This document is the third in a series that supplements NIST Interagency Report (IR) 8286, Integrating Cybersecurity and Enterprise Risk Management (ERM). This series provides additional details regarding enterprise application of cybersecurity risk information; the previous documents, IRs 8286A and 8286B, provide details regarding stakeholder risk direction and methods for assessing and managing cybersecurity risk in light of enterprise objectives. This report, IR 8286C, describes how information recorded in cybersecurity risk registers (CSRRs) may be integrated as part of a holistic approach to ensuring that risks to information and technology are properly considered for the enterprise risk portfolio. This cohesive understanding supports an enterprise risk register and enterprise risk profile that, in turn, support the achievement of enterprise objectives.	本書は、NIST 内部報告書（IR）8286「サイバーセキュリティとエンタープライズ・リスクマネジメント（ERM）の統合」を補足するシリーズの第3巻である。このシリーズでは、サイバーセキュリティリスク情報のエンタープライズ・アプリケーションに関する追加情報を提供する。これに先立つIR 8286Aおよび8286Bでは、エンタープライズの目標に照らしたサイバーセキュリティリスクのアセスメントおよびマネジメントの方法と、利害関係者のリスク方針に関する詳細が提供されている。本報告書IR 8286Cでは、情報およびテクノロジーに対するリスクが企業リスクポートフォリオにおいて適切に考慮されることを保証するための包括的なアプローチの一環として、サイバーセキュリティリスクレジストリ（CSRR）に記録された情報を統合する方法について説明している。この統合的な理解は、企業リスクレジストリおよび企業リスクプロファイルを支え、ひいては企業目標の達成を支援する。

・[PDF] NIST.IR.8286Cr1.ipd

目次...

Executive Summary	エグゼクティブサマリー
1. Introduction	1. 序文
1.1. Purpose and Scope	1.1. 目的と範囲
1.2. Document Structure	1.2. 文書構成
2. Aggregation, Normalization, and Analysis of Cybersecurity Risk Registers (CSRRs)	2. サイバーセキュリティリスクレジストリ（CSRR）の集約、標準化、分析
2.1. Aggregation of Cybersecurity Risk Information	2.1. サイバーセキュリティリスク情報の集約
2.2. Normalization of Cybersecurity Risk Registers	2.2. サイバーセキュリティリスクレジストリの標準化
2.3. Analysis of Cybersecurity Risk Registers	2.3. サイバーセキュリティリスクレジストリの分析
2.4. Integrating CSRR Details	2.4. CSRR 詳細の統合
3. Determining Top-Down Priority: Integration of Cybersecurity Risk into the ERR/ERP	3. トップダウンによる優先順位の決定：ERR/ERP へのサイバーセキュリティリスクの統合
3.1. Enterprise Value of Incorporating Enterprise CSRRs into the ERP	3.1. エンタープライズ CSRR を ERP に統合するエンタープライズバリュー
3.2. Considerations in Priority: Operational Objectives and Enterprise Impact of Cybersecurity	3.2. 優先順位を決定する際の考慮事項：サイバーセキュリティの運用目標とエンタープライズへの影響
3.3. Considerations in Priority: Dependencies Among Enterprise Functions and Technology Systems	3.3. 優先順位付けにおける考慮事項：企業機能とテクノロジーシステム間の依存関係
4. Risk Governance as the Basis for Cybersecurity Risk Management	4. サイバーセキュリティリスク管理の基礎としてのリスクガバナンス
4.1. Frameworks in Support of Risk Governance and Risk Management	4.1. リスクガバナンスとリスクマネジメントを支援する枠組み
4.2. Adjustments to Risk Direction	4.2. リスクの方向性の調整
4.2.1. Adjustments to Cybersecurity Program Budget Allocation	4.2.1. サイバーセキュリティプログラムの予算配分の調整
4.2.2. Adjustments to Risk Appetite and Risk Tolerance	4.2.2. リスク許容度とリスク耐性の調整
4.2.3. Reviewing Whether Constraints Are Overly Stringent	4.2.3. 制約が厳しすぎるかどうかの見直し
4.2.4. Adjustments to Priority	4.2.4. 優先順位の調整
5. Cybersecurity Risk Monitoring, Evaluation, and Adjustment	5. サイバーセキュリティリスクの監視、評価、調整
5.1. Key CSRM Mechanisms	5.1. CSRMの主なメカニズム
5.2. Monitoring Risks	5.2. リスクの監視
5.3. Evaluating Risks	5.3. リスクの評価
5.4. Adjusting Risk Responses	5.4. リスク対応の調整
5.5. Monitor, Evaluate, and Adjust Examples	5.5. 監視、評価、調整の例
References	参考文献
Appendix A. List of Symbols, Abbreviations, and Acronyms Appendix B. Change Log	附属書 A. シンボル、略語、および頭字語の一覧 附属書 B. 変更履歴
List of Tables	表の一覧
Table 1. Examples of cybersecurity risk analysis	表1. サイバーセキュリティリスク分析の例
Table 2. Examples of risk oversight functional roles and responsibilities	表2. リスク管理機能の役割と責任の例
Table 3. CSF steps as aligned with CSRM/ERM integration	表3. CSRM/ERM 統合に整合する CSF のステップ
Table 4. Examples of proactive risk management evaluation activities	表4. プロアクティブなリスクマネジメント評価活動の例
Table 5. Notional examples of MEA activities	表5. MEA 活動の概念例
List of Figures	図の一覧
Fig. 1. IR 8286 [6] series publications describe CSRM/ERM integration	図1. IR 8286 [6] シリーズの出版物は、CSRM/ERM統合について説明している
Fig. 2. IR 8286C activities as part of CSRM/ERM integration	図2. CSRM/ERM統合の一部としてのIR 8286Cの活動
Fig. 3. Moving CSRRs through the aggregation, normalization, and analysis phases	図3. 集約、標準化、分析の各段階におけるCSRRの移動
Fig. 4. OMB A-11 strategic planning concepts	図4. OMB A-11戦略計画の概念
Fig. 5. Bottom-up integration of risk registers to create E-CSRR, ERR, and ERP Fig. 6. Notional risk breakdown structure depicting enterprise risk impacts	図5：E-CSRR、ERR、ERPを作成するためのボトムアップ型リスクレジスター統合 図6：エンタープライズ・リスクの影響を示す概念上のリスクブレークダウン構造
Fig. 7. Notional ERP example	図7：概念上のERPの例
Fig. 8. CSF steps in support of CSRM integration	図8：CSRM統合を支援するCSFのステップ
Fig. 9. Illustration of enterprise CSRM and coordination	図9：エンタープライズCSRMと調整の説明図
Fig. 10. Monitor-Evaluate-Adjust cycle	図10：モニタリング、評価、調整サイクル

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

Executive Summary	エグゼクティブサマリー
This NIST Interagency Report (IR) explores methods for integrating disparate cybersecurity risk management (CSRM) information from throughout the enterprise to create a composite enterprise risk profile to inform company executives’ and agency officials’ enterprise risk management (ERM) deliberations, decisions, and actions. It describes the inclusion of cybersecurity risks as part of financial, valuation, mission, and reputation exposure. Figure 1 expands the enterprise risk cycle from previous reports to remind the reader that the input and sentiments of external stakeholders are a critical element of risk decisions.	このNIST機関間報告書（IR）では、企業全体にわたるサイバーセキュリティ・リスクマネジメント（CSRM）のさまざまな情報を統合し、複合的なエンタープライズ・リスクプロファイルを作成して、企業幹部および政府機関職員のエンタープライズ・リスクマネジメント（ERM）の審議、決定、行動に役立てるための方法を検討する。また、財務、評価、ミッション、および評判のエクスポージャーの一部としてサイバーセキュリティリスクを含めることについても説明する。図1は、以前の報告書からエンタープライズ・リスクサイクルを拡大し、外部利害関係者の意見や感情がリスク判断の重要な要素であることを読者に思い出させる。
Fig. 1. IR 8286 [6] series publications describe CSRM/ERM integration	図1 IR 8286 [6] シリーズの出版物は、CSRM/ERMの統合について説明している
The importance of information and technology risks to the enterprise risk posture makes it critical to ensure broad visibility about risk-related activities to protect enterprise reputation, finances, and objectives. A comprehensive enterprise risk register (ERR) and enterprise risk profile (ERP) support communication and disclosure requirements. The integration of CSRM activities supports understanding of exposures related to corporate reporting (e.g., income statements, balance sheets, and cash flow) and similar requirements (e.g., reporting for appropriation and oversight authorities) for public-sector entities.	企業リスクの状況に対する情報および技術リスクの重要性から、企業評価、財務、目標を防御するために、リスク関連の活動について幅広い可視性を確保することが極めて重要となる。包括的なエンタープライズ・リスクレジスター（ERR）とエンタープライズ・リスクプロファイル（ERP）は、コミュニケーションと情報開示の要件をサポートする。 CSRM活動の統合は、企業報告（損益計算書、貸借対照表、キャッシュフローなど）に関連するエクスポージャーの理解をサポートし、公共部門の事業体に対する同様の要件（認可当局や監督当局への報告など）にも対応する。
This document explores the methods for integrating disparate CSRM information from throughout the enterprise to create a composite understanding of the various cyber risks that may have an impact on the enterprise’s objectives. The report continues the discussion where  IR 8286B [7] concluded by focusing on the integration of data points to create a comprehensive view of opportunities and threats to the enterprise’s information and technology.  Notably, because cybersecurity risk is only one of dozens of risk types in the enterprise risk universe, that risk understanding will itself be integrated with similar aggregate observations of other collective risk points.	本書では、企業の目的に影響を及ぼす可能性のあるさまざまなサイバーリスクを総合的に理解するために、企業全体から収集したさまざまなCSRM情報を統合する方法について検討する。本書では、IR 8286B [7] の議論を継続し、企業の情報およびテクノロジーに対する機会と脅威の包括的なビューを作成するために、データポイントの統合に焦点を当てる。 特に、サイバーセキュリティリスクは、企業リスクの全体像における数多くのリスクの1つにすぎないため、そのリスクの理解自体が、他の集合的なリスクポイントの類似した集約的な観察結果と統合されることになる。
This document discusses how risk governance elements such as enterprise risk strategy, appetite, tolerance, and capacity direct risk performance. By monitoring the results of CSRM activities at each hierarchical level, senior leaders can adjust various governance components (e.g., policy, procedures, workforce skills) to achieve risk objectives. This report describes how the CSRM Monitor, Evaluate, and Adjust (MEA) process supports ERM and a repeatable and consistent use of terms, including how the context of various terms can vary depending on the enterprise’s perspective. That understanding helps to ensure effective CSRM communication and coordination.	本書では、エンタープライズ・リスク戦略、リスク選好度、リスク許容度、リスク対応力などのリスクガバナンスの要素がリスクパフォーマンスにどのように影響するかを論じている。各階層レベルにおける CSRM 活動の結果をモニタリングすることで、シニアリーダーはリスク目標を達成するために、さまざまなガバナンス要素（ポリシー、手順、従業員のスキルなど）を調整することができる。本レポートでは、ERM をサポートする CSRM のモニタリング、評価、調整（MEA）プロセスについて説明し、企業の視点によってさまざまな用語のコンテクストがどのように異なる可能性があるかを含め、用語の反復可能かつ一貫した使用方法についても説明する。こうした理解は、効果的な CSRM コミュニケーションと調整を確実に行うのに役立つ。
While ERM is a well-established field, there is an opportunity to expand and improve the body of knowledge regarding coordination among cybersecurity risk managers and those managing risk at the most senior levels. This series is intended to introduce this integration while recognizing the need for additional research and collaboration. Further points of discussion include IR 8286D’s focus on business impact analysis (BIA), which is a foundation of understanding exposure and opportunity [8]. NIST also continues to perform extensive research and publication development regarding metrics, a topic that will certainly support ERM/CSRM performance measurement, monitoring, and communication.	ERMは確立された分野であるが、サイバーセキュリティリスク管理者と最高経営責任者レベルのリスク管理者の間の調整に関する知識体系を拡大し改善する余地がある。このシリーズは、さらなる研究と協力の必要性を認識しながら、この統合を紹介することを目的としている。さらに議論すべき点として、エクスポージャーと機会を理解するための基礎であるビジネスインパクト分析（BIA）にIR 8286Dが重点を置いていることが挙げられる[8]。また、NISTは、ERM/CSRMのパフォーマンス測定、モニタリング、コミュニケーションを確実にサポートするトピックであるメトリクスに関する広範な研究と出版物の開発も継続している。
This document continues the discussion regarding the inclusion of CSRM priorities and results in support of an improved understanding about organization and enterprise impacts of cybersecurity risks on financial, reputation, and mission considerations.	本書では、財務、評判、ミッション上の懸念に対するサイバーセキュリティリスクの組織およびエンタープライズへの影響に関する理解の改善を目的として、CSRMの優先事項と結果の組み込みに関する議論を継続している。

---

・2025.02.25 NIST IR 8286D Using Business Impact Analysis to Inform Risk Prioritization and Response

NIST IR 8286D Using Business Impact Analysis to Inform Risk Prioritization and Response	NIST IR 8286D ビジネスインパクト分析によるリスクの優先順位付けと対応の決定
Abstract	概要
While business impact analysis (BIA) has historically been used to determine availability requirements for business continuity, the process can be extended to provide a broad understanding of the potential impacts of any type of loss on the enterprise mission. The management of enterprise risk requires a comprehensive understanding of mission-essential functions (i.e., what must go right) and the potential risk scenarios that jeopardize those functions (i.e., what might go wrong). The process described in this publication helps leaders determine which assets enable the achievement of mission objectives and evaluate the factors that render assets as critical and sensitive. Based on those factors, enterprise leaders provide risk directives (i.e., risk appetite and tolerance) as input to the BIA. System owners then apply the BIA to developing asset categorization, impact values, and requirements for the protection of critical or sensitive assets. The output of the BIA is the foundation for the Enterprise Risk Management (ERM)/Cybersecurity Risk Management (CSRM) integration process, as described in the NIST Interagency Report (IR) 8286 series, and enables consistent prioritization, response, and communication regarding information security risk.	ビジネスインパクト分析（BIA）は、従来、事業継続のための可用性要件を決定するために使用されてきたが、このプロセスを拡張することで、あらゆる種類の損失が企業ミッションに及ぼす潜在的な影響について、より広範な理解を得ることができる。 エンタープライズ・リスクの管理には、ミッションに不可欠な機能（すなわち、何が正しく行われなければならないか）と、それらの機能を脅かす潜在的なリスクシナリオ（すなわち、何が間違って行われる可能性があるか）についての包括的な理解が必要である。本書で説明されているプロセスは、リーダーがミッション目標の達成を可能にする資産を特定し、資産を重要かつ機密性の高いものとする要因を評価するのに役立つ。エンタープライズリーダーは、それらの要因に基づいて、BIAへのインプットとしてリスク指令（リスク許容度やリスク許容範囲など）を提供する。システム所有者は、BIA を資産分類、影響値、および重要または機密資産の防御要件の策定に適用する。BIA の結果は、NIST 内部報告書（IR）8286 シリーズで説明されているように、エンタープライズ・リスクマネジメント（ERM）／サイバーセキュリティ・リスクマネジメント（CSRM）統合プロセスの基礎となり、情報セキュリティリスクに関する一貫した優先順位付け、対応、およびコミュニケーションを可能にする。

・[PDF] NIST.IR.8286D-upd1

 

・[DOCX][PDF] 仮訳

目次...

Executive Summary	エグゼクティブサマリー
1. Introduction	1. 序文
1.1. Benefits of Extending the BIA for Risk Types	1.1. リスクタイプのBIAを拡張するメリット
1.2. Foundational Practices for Business Impact Analysis	1.2. ビジネスインパクト分析のための基本的なプラクティス
1.3. Document Structure	1.3. 文書構造
2. Cataloging and Categorizing Assets Based on Enterprise Value	2. エンタープライズ価値に基づく資産のカタログ化と分類
2.1. Identification of Enterprise Business Asset Types	2.1. エンタープライズ・ビジネス資産タイプの特定
2.2. The Business Impact Analysis Process	2.2. ビジネスインパクト分析プロセス
2.3. Determining Asset Value to Support CSRM Activities	2.3. CSRM活動を支える資産価値の決定
2.4. Determining Loss Scenarios and Their Consequences	2.4. 損失シナリオとその結果の決定
2.5. Business Impact Analysis in Terms of Criticality and Sensitivity	2.5. 重要度と感度の観点からのビジネスインパクト分析
2.6. Using a BIA to Record Interdependencies	2.6. BIAを使った相互依存関係の記録
2.7. Consistent Business Impact Analysis Through an Enterprise Approach	2.7. エンタープライズ・アプローチによる一貫したビジネスインパクト分析
2.8. Using a BIA to Support an Enterprise Registry of System Assets	2.8. BIAを使用したシステム資産のエンタープライズレジストリの支援
3. Conclusion	3. 結論
References	参考文献
Appendix A. List of Symbols, Abbreviations, and Acronyms	附属書A. 記号、略語、頭字語のリスト
Appendix B. Change Log	附属書B. 変更履歴

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

Executive Summary	エグゼクティブサマリー
Risk is measured in terms of impact on enterprise mission, so it is vital to understand the various information and technology (IT) assets whose functions enable that mission. Each asset has a value to the enterprise. For government enterprises, many of those IT assets are key components for supporting critical services provided to citizens. For corporations, IT assets directly influence enterprise capital and valuation, and IT risks can have a direct impact on the balance sheet or budget. For each type of enterprise, it is both vital and challenging to determine the conditions that will truly impact a mission. Government agencies must provide critical services while adhering to priority directives from senior leaders. In the commercial world, mission priority is often driven by long-term goals and factors that might impact the next quarter’s earnings call. Therefore, it is highly important to continually analyze and understand the enterprise resources that enable enterprise objectives and that can be jeopardized by cybersecurity risks.	リスクは、エンタープライズのミッションへの影響という観点から測定されるため、そのミッションを可能にする機能を持つ様々な情報・技術（IT）資産を理解することが不可欠である。各資産はエンタープライズにとって価値がある。ガバナンス・エンタープライズにとって、IT資産の多くは、市民に提供される重要なサービスを支える重要なコンポーネントである。企業にとっては、IT資産がエンタープライズの資本や評価に直接影響し、ITリスクは貸借対照表や予算に直接的な影響を与える可能性がある。それぞれのタイプのエンタープライズにとって、ミッションに真に影響を与える条件を見極めることは、極めて重要であると同時に困難でもある。ガバナンスの政府機関は、上級指導者からの優先的な指示を守りつつ、重要なサービスを提供しなければならない。商業の世界では、ミッションの優先順位は、長期的な目標や、次の影響するかもしれない要因によって左右されることが多い四半期の。したがって、企業の目標を実現し、サイバーセキュリティリスクによって危険にさらされる可能性のあるエンタープライズリソースを。 継続的に分析し、理解することが非常に重要である。
The NIST Interagency Report (IR) 8286 series has coalesced around the risk register as a construct for storing and a process for communicating risk data [NISTIR8286]. Another critical artifact of risk management that serves as both a construct and a means of communication with the risk register is the Business Impact Analysis (BIA) Register. The BIA examines the potential impacts associated with the loss or degradation of an enterprise’s technology-related assets based on a qualitative or quantitative assessment of the criticality and sensitivity of those assets and stores the results in the BIA Register. An asset criticality or resource dependency assessment identifies and prioritizes the information assets that support the enterprise’s critical missions. Similarly, assessments of asset sensitivity identify and prioritize information assets that store, process, or transmit information that must not be modified or disclosed to unauthorized parties. In the cybersecurity realm, the use of the BIA has historically been limited to calculations of quality-based and time-based objectives for incident handling (including continuity of operations and disaster recovery).	NISTの省庁間報告書（IR）8286シリーズは、リスクデータを保存し、コミュニケーションするための プロセスとして、リスク登録簿を中心にまとめられた[NISTIR8286]。リスクレジスターの構成要素とコミュニケーション手段の両方の役割を果たすリスクマネジメントのもう一つの重要な成果物は、ビジネスインパクト分析（BIA）レジスターである。BIAは損失又は関連する潜在的な影響を検討、エンタープライズの技術関連資産の、それらの資産の重要性及び感受性の定性的又は定量的な評価に基づいてし、その結果をBIA登録簿に保存する。資産の重要性または資源依存性のアセスメントは、支える情報資産を特定し、優先順位をつける劣化にエンタープライズの重要なミッションを。同様に、資産の機密性のアセスメントでは、無権限者に変更または開示されてはならない情報を保存、処理、または送信する情報資産を特定し、優先順位を付ける。サイバーセキュリティの領域では、BIAの使用は歴史的に、インシデントハンドリング（事業継続と災害復旧を含む）のための品質ベースと時間ベースの目標の計算に限られてきた。
Because the BIA serves as a nexus for understanding risk (which is the measurement of uncertainty on the mission), it provides a basis for risk appetite and tolerance values as part of the enterprise risk strategy.[1] That guidance supports performance and risk metrics based on the relative value of enterprise assets to communicate and monitor Cybersecurity Risk Management[2] (CSRM) activities, including measures determined to be key performance indicators (KPIs) and key risk indicators (KRIs). The BIA supports asset classification that drives requirements, risk communications, and monitoring.	BIAはリスク（ミッション上の不確実性の測定である）を理解するための結節点として機能するため、エンタープライズリスク戦略の一部としてリスク選好度と許容値の基礎を提供する。[1]このガイダンスは、サイバーセキュリティリスクマネジメントコミュニケーションし監視するために、エンタープライズ資産の相対的価値に基づくパフォーマンスとリスクの指標を支援するもので[2] ）活動をあり、これには主要業績評価指標（KPI）や主要リスク指標（KRI）として決定された指標も含まれる。BIA は、要件、リスクコミュニケーション、モニタリングを推進する資産分類を支援する。
Expanding use of the BIA to include confidentiality and integrity considerations supports comprehensive risk analysis. The basis of asset valuation on enterprise impact helps to better align risk decisions to enterprise risk strategy. CSRM/ERM integration helps to complete the risk cycle by informing future iterations of impact analysis based on previous information gained through cybersecurity risk register (CSRR) aggregation, as detailed in NIST IR 8286C. As organizational and enterprise leaders gain an understanding of aggregate risk exposure and composite impact, that information helps adjust risk expectations (including business impact guidance to ensure an ongoing balance among asset value, resource optimization, and risk considerations).	BIAの利用を拡大し、機密性と完全性の検討を含めることで、包括的なリスク分析を支援する。エンタープライズに与える影響を資産評価の基礎とすることで、エンタープライズリスク戦略に対するリスク決定の整合性を高めることができる。CSRM/ERM の統合は、NIST IR 8286C に詳述されているように、サイバーセキュリティリスクレジス タ（CSRR）の集計を通じて得られた過去の情報に基づき、影響度分析の将来の反復に情報を提供することによって、リスクサイクルを完成させるのに役立つ。組織やエンタープライズのリーダーは、リスクエクスポージャーと複合的な影響の総和を理解するようになるため、その情報はリスクに対する期待値（資産価値、リソースの最適化、リスクへの配慮の間の継続的なバランスを確保するためのビジネス影響ガイダンスを含む）を調整するのに役立つ。
The BIA process enables system owners to record the benefits provided by an asset by considering the contribution to the enterprise, particularly in terms of mission, finance, and reputational aspects. Once informed about how each asset supports enterprise value, system owners can then work with risk managers to determine the implications of uncertainty on those assets.	BIAプロセスにより、システム所有者は、特にミッション、財務、評判の側面から、エンタープライズへの貢献を考慮することで、資産からプロバイダが提供される利益を記録することができる。各資産がどのようにエンタープライズの価値を支えているかを知ることができれば、システムオーナーはリスクマネジメントと協力して、それらの資産に不確実性がもたらす影響を判断することができる。
It is more critical than ever to have centralized and reliable asset information recorded in the BIA Register since enterprises rely on various types of information and communications technology (ICT) resources, which are increasingly targeted by adversaries. The BIA process provides information that can be consistently recorded in a centralized registry of important asset management information, such as system ownership, contact information for key stakeholders, and characteristics of the physical devices (or services). Since asset management is an important element of cybersecurity risk management, this information is quite valuable for protecting the asset, detecting cyber events, responding quickly to potential issues, and recovering services when necessary.	エンタープライズがさまざまな種類の情報通信技術（ICT）リソースに依存しており、敵対勢力に狙われることが多くなっているため、BIA登録簿に記録される一元化された信頼できる資産情報がこれまで以上に重要になっている。BIAプロセスは、システムの所有権、主要な利害関係者の連絡先情報、物理的装置（またはサービス）の特性など、重要な資産管理情報を集中登録簿に一貫して記録できる情報を提供する。資産管理はサイバーセキュリティ・リスクマネジメントの重要な要素であるため、この情報は資産を保護し、サイバーイベントを検知し、潜在的な問題に迅速に対応し、必要な場合にはサービスを回復するために非常に価値がある。
Public- and private-sector enterprises must maintain a continual understanding of potential business impacts, the risk conditions that might lead to those impacts, and the steps being taken to address those impacts (as recorded in various risk registers and, ultimately, in the Enterprise Risk Profile). In many cases, when a company or agency is asked about risks, they are actually being asked to describe potential impacts. Companies must describe the risk factors that could have a material adverse effect on the enterprise’s financial position, its ability to operate, or its corporate cash flow. Agencies must report to legislative and regulatory stakeholders about adverse impacts that could impair agency missions and funding. Use of the BIA methodology to categorize the criticality and sensitivity of enterprise assets enables effective risk management and the subsequent integration of reporting and monitoring at the enterprise level to ensure that risk and resource utilization are optimized in light of the value of those assets.	公共部門及び民間部門のエンタープライズは、潜在的な事業への影響、それらの影響につながる可 能性のあるリスク状況、及びそれらの影響に対処するための措置（様々なリスク登録簿に記 録され、最終的にはエンタープライズ・リスク・プロファイルに記録される）を継続的に理 解し続けなければならない。多くの場合、企業や機関がリスクについて問われるとき、実際には潜在的な影響について問われる。企業は、エンタープライズの財政状態、経営能力、または企業のキャッシュフローに重大な悪影響を及ぼす可能性のあるリスク要因を記述しなければならない。省庁は、省庁の使命や資金調達を損なう可能性のある悪影響について、立法・規制上の利害関係者に報告しなければならない。エンタープライズ資産の重要性と機密 性を分類するためにBIA手法を使用することにより、効果的なリスクマネジメントと、それに続くエンタープライズレベルでの報告とモニタリングの統合が可能となり、それらの資産の価値に照らしてリスクと資源利用が最適化されることが保証される。
[1] Office of Management and Budget (OMB) Circular A-123 defines risk appetite as “the broad-based amount of risk an organization is willing to accept in pursuit of its mission/vision. It is established by the organization’s most senior level leadership and serves as the guidepost to set strategy and select objectives.” The same document defines risk tolerance as “the acceptable level of variance in performance relative to the achievement of objectives.”	[1]行政管理予算局（OMB）サーキュラーA-123は、リスク定義している選好度を組織が許容する広範なリスク量」とそのミッション／ビジョンを。リスク選好度は追求するために、組織の最上位レベルのリーダーシップによって設定され、戦略を設定し、目標を選択するための道標の」と定義している。役割を果たす同文書では、定義しているリスク許容度を「許容レベル目標達成に対する。 業績のばらつきの
[2] Cybersecurity Risk Management, or CSRM, is the process of managing uncertainty on or within information and technology.	[2]サイバーセキュリティ・リスクマネジメント（CSRM）とは、情報や技術に関する不確実性を管理するプロセスである。

---

参考...

● Committee of Sponsoring Organizations; COSO

・Enterprise Risk Management; ERM

・[PDF] Exsecutive Summary

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

IR 8286

・2024.03.10 米国 NIST IR 8286C エンタープライズリスクマネジメントと政府監視のためのサイバーセキュリティリスクのステージング

・2022.11.22 NISTIR 8286D リスクの優先順位付けと対応を行うためのビジネス影響分析の使用

・2022.09.16 NISTIR 8286C エンタープライズ・リスク・マネジメント (ERM) とガバナンスの監督のためのサイバーセキュリティ・リスクのステージング

・2022.06.14 NISTIR 8286D (ドラフト) リスクの優先順位付けと対応にビジネスインパクト分析を使用する方法 (2022.06.09)

・2022.02.13 NISTIR 8286B エンタープライズ・リスク・マネジメント (ERM) のためのサイバーセキュリティ・リスクの優先順位付け

・2022.01.28 NISTIR 8286C （ドラフト）エンタープライズ・リスク・マネジメント (ERM) とガバナンスの監督のためのサイバーセキュリティ・リスクのステージング

・2021.11.15 NISTIR 8286A エンタープライズ・リスク・マネジメント (ERM) のためのサイバーセキュリティ・リスクの識別と推定

・2021.09.03 NISTIR 8286B（ドラフト）エンタープライズ・リスク・マネジメント (ERM) のためのサイバーセキュリティ・リスクの優先順位付け

・2021.07.08 NISTIR 8286A （ドラフト）エンタープライズ・リスク・マネジメント (ERM) のためのサイバーセキュリティ・リスクの識別と推定（第2ドラフト）

・2020.10.22 NISTIR 8286 Integrating Cybersecurity and Enterprise Risk Management (ERM)

・2020.07.12 NISTIR 8286 (Draft) Integrating Cybersecurity and Enterprise Risk Management (ERM) (2nd Draft)

・2020.03.20 NISTIR 8286(Draft) Integrating Cybersecurity and Enterprise Risk Management (ERM)

SP800-221関係...

・2023.11.20 NIST SP 800-221 情報通信技術リスクのエンタープライズへの影響：エンタープライズリスクポートフォリオにおけるICTリスクプログラムのガバナンスとマネジメント, NIST SP 800-221A 情報通信技術（ICT）リスクの成果： ICTリスクマネジメントプログラムとエンタープライズリスクポートフォリオの統合

・2022.07.25 NIST SP 800-221 (ドラフト) 情報通信技術リスクのエンタープライズへの影響：エンタープライズ・リスクポートフォリオの中でのICTリスクプログラムの統治と管理 SP 800-221A (ドラフト) 情報通信技術 (ICT) リスクの成果：ICTリスクマネジメントプログラムとエンタープライズリスクポートフォリオの統合

経営ガイドライン Veer3.0

・2023.11.09 IPA サイバーセキュリティ経営ガイドライン Ver 3.0実践のためのプラクティス集 (2023.10.31)

・2023.03.26 経済産業省 サイバーセキュリティ経営ガイドラインVer 3.0

・2022.12.10 経団連 「サイバーセキュリティ経営ガイドライン Ver3.0 (案) 」に対する意見

米国 NIST （意見募集）IR 8011 Vol. 1 Rev. 1（初期公開草案） テスト可能な管理策および継続的なモニタリングのためのセキュリティ機能：第1巻 - 概要と方法論

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

評価も含めたコントロールズ（統制手続、管理策）についての文書の改訂版のドラフトです。ただし、タイトルから変更するほどの大きな変更ですね...

これだけでも、100ページ超あります。

おそらくこれはこれから重要です。企業側でセキュリティのための管理策を設計する人にとっても、それを評価（管理部門、監査部門、外部監査人）する人にとっても重要な文書になると思われます。

そして、監査の研究者にとっても重要だと思います。本当は、監査研究者も理解してもらい、批判的に分析してもらいたいところではあります...

もちろん、ISMS等の認証に関わる監査人、これからの経産省のサプライチェーンリスクを低減するための星制度を考える人にも是非、目を通してもらいたい資料だと思うんですよね...

管理策（統制手続、controls）の評価を構造的に考えるというのは重要な観点だと思うんですよね...

なかなか野心的な文書だと思います...

● NIST - ITL

・2025.02.20 NIST IR 8011 Vol. 1 Rev. 1 (Initial Public Draft) Testable Controls and Security Capabilities for Continuous Monitoring: Volume 1 — Overview and Methodology

NIST IR 8011 Vol. 1 Rev. 1 (Initial Public Draft) Testable Controls and Security Capabilities for Continuous Monitoring: Volume 1 — Overview and Methodology	NIST IR 8011 Vol. 1 Rev. 1（初期公開草案） テスト可能な管理策および継続的なモニタリングのためのセキュリティ機能：第1巻 - 概要と方法論
Announcement	アナウンス
Summary	概要
The NIST Risk Management Framework (RMF) Team has released the initial public draft (ipd) version of NIST Internal Report (IR) 8011v1r1 (Volume 1, Revision 1), Testable Controls and Security Capabilities for Continuous Monitoring: Volume 1 — Overview and Methodology.	NISTリスクマネジメント枠組み（RMF）チームは、NIST内部報告書（IR）8011v1r1（第1巻、改訂1）の最初の公開草案（ipd）バージョン「テスト可能な管理策および継続的なモニタリングのためのセキュリティ機能：第1巻 - 概要および方法論）」を公開した。
Details	詳細
IR 8011 provides a methodology for identifying testable controls – SP 800-53 controls that can be assessed and monitored using automatable tests – and for creating such tests in support of information security continuous monitoring. These testable controls are organized by continuous monitoring security capabilities which are sets of controls with a common defense purpose.	IR 8011は、テスト可能な管理策（自動化可能なテストを使用してアセスメントおよびモニタリングが可能なSP 800-53の管理策）を識別する方法と、情報セキュリティの継続的なモニタリングを支援するテストを作成する方法を規定している。これらのテスト可能な管理策は、共通の防御目的を持つ一連の統制であるセキュリティ能力の継続的なモニタリングによって体系化されている。
Using a six-step adversarial attack model, the methodology breaks down security capabilities into levels of abstraction towards the identification of smaller, targeted capabilities called sub-capabilities which offer optimal level of granularity for the development of control tests. These tests are created for controls that share common defense objectives and are grouped to support specific security capabilities for continuous monitoring.	6段階の敵対的攻撃モデルを使用して、この手法ではセキュリティ能力を抽象度のレベルに分解し、制御テストの開発に最適な粒度を提供する、より小さく、より対象を絞った能力であるサブ能力を特定する。これらのテストは、共通の防御目的を共有する管理策に対して作成され、継続的なモニタリングのための特定のセキュリティ能力をサポートするためにグループ化される。
Volume 1 introduces key terminology and foundational concepts, describes the methodology, and discusses conceptual operational considerations for a potential IR 8011 implementation. NIST uses these concepts and methodology to identify the sample control tests for security capabilities that are featured in subsequent volumes in the Series.	第1巻では、主要な用語と基礎となる概念を紹介し、その方法論を説明し、IR 8011の潜在的な実装に関する概念的な運用上の考慮事項について議論している。NISTは、これらの概念と方法論を使用して、シリーズのその後の巻で取り上げられるセキュリティ機能のためのサンプルの統制テストを識別する。
IR 8011v1r1 represents a major revision of the first and key volume in the multi-volume IR 8011 series. The NIST Risk Management Framework (RMF) Team welcomes feedback and input on any aspect of IR 8011v1r1 and additionally proposes a list of non-exhaustive questions and topics for consideration:	IR 8011v1r1は、複数巻からなるIR 8011シリーズの第1巻および主要巻の大幅な改訂版である。NISTリスクマネジメント枠組み（RMF）チームは、IR 8011v1r1のあらゆる側面に関するフィードバックや意見を歓迎し、さらに、考慮すべき非網羅的な質問やトピックのリストを提案している。
・Have you or your organization ever implemented the IR 8011 methodology? If so, under what capacity (developer/adopter)?	・あなたまたはあなたの組織は、IR 8011の方法論を導入したことがあるか？ もしある場合、どのような立場（開発者／採用者）で導入したか？
・Are you a developer of security or continuous monitoring tools that would be interested in incorporating the IR 8011 methodology into a solution?	・IR 8011の方法論をソリューションに組み込むことに興味がある、セキュリティまたは継続的なモニタリングツールの開発者か？
・Is the IR 8011 methodology sound, logical and actionable?	・IR 8011の方法論は、健全で論理的であり、実行可能か？
・Is the language in this revision clear or is there any specific content that requires clarification?	・この改訂版の表現は明確か、または明確化が必要な特定のコンテンツはあるか？
・Are there any additional conceptual implementation considerations that you would propose to be included in the final version of this guide?	・このガイドの最終版に含めるべき、追加の概念的な実装に関する考慮事項はありますか？
・If an IR 8011 community of interest is established in the future, would you be interested in participating? (If so, please leave a contact information).	・将来、IR 8011 に関心を持つコミュニティが設立された場合、参加することに興味がありますか？（参加する場合は、連絡先をご記入ください）。
・What are opportunities for improvement?	・改善の余地はありますか？
・Any other feedback on:	・その他、以下の点についてご意見はありますか？
・・Updates to the IR 8011 methodology	・・IR 8011 方法論の更新
・・Updates to the IR 8011 terminology and general language	・・IR 8011 用語および一般言語の更新
・・Typos and errors	・・誤字脱字
Following the feedback received on this call for comments, the NIST RMF Team plans to issue a final version of IR 8011v1r1. If major changes to the ipd are necessary, a final public draft may be issued for another round of public comment before the publication is finalized. The intent is to publish guidance that can help operationalize the IR 8011 methodology.	本意見募集で寄せられたフィードバックを踏まえ、NIST RMF チームは IR 8011v1r1 の最終版を発行する予定である。 IR 8011 の大幅な変更が必要な場合は、最終版を発行する前に、最終パブリックドラフトを発行して、再度パブリックコメントを募集する場合がある。 IR 8011 の手法を運用化する上で役立つ指針を発行することが目的である。
Abstract	要約
According to the NIST Risk Management Framework (RMF) methodology, SP 800-53 security and privacy controls are selected, implemented, assessed, and monitored to help achieve security and privacy objectives. Due to the sheer size, complexity, and scope of information technology footprints, the automation of control assessment and monitoring tasks is desired but not easily achieved. IR 8011 provides a method for identifying SP 800-53 controls that can be tested via automated means based on the assessment objectives and potential assessment methods in SP 800-53A. The IR 8011 methodology also includes a process for developing the actual tests for each testable control. This first volume in the IR 8011 multi-volume series introduces foundational concepts — including the concept of security capability for continuous monitoring — and describes each step of the IR 8011 methodology. This revision includes a new section on the envisioned operationalization of IR 8011 for the development and adoption of potential solutions. Subsequent volumes in the IR 8011 series provide a sample set of testable controls and automatable tests for specific security capabilities for continuous monitoring.	NISTリスクマネジメント枠組み（RMF）の方法論に従い、セキュリティおよびプライバシーの目的を達成するために、SP 800-53のセキュリティおよびプライバシー管理策が選択、実装、アセスメント、および監視される。情報テクノロジーの規模、複雑性、および適用範囲の広さにより、コントロールの評価とモニタリングのタスクの自動化が望まれているが、容易に実現できるものではない。IR 8011は、SP 800-53Aのアセスメントの目的と潜在的なアセスメントの方法に基づいて、自動化された手段でテストできるSP 800-53のコントロールを識別する方法を提供する。IR 8011の方法論には、テスト可能な各管理策に対する実際のテストを開発するプロセスも含まれている。IR 8011の複数巻シリーズの第1巻では、基礎となる概念（継続的なモニタリングのためのセキュリティ能力の概念を含む）を紹介し、IR 8011の方法論の各ステップを説明している。今回の改訂では、潜在的なソリューションの開発と採用に向けたIR 8011の運用化構想に関する新しいセクションが追加されている。IR 8011シリーズの今後の刊行物では、継続的なモニタリングのための特定のセキュリティ能力について、テスト可能な管理策と自動化可能なテストのサンプルセットを提供する。

Executive Summary	エグゼクティブサマリー
1. IR 8011 Overview	1. IR 8011の概要
1.1. Background	1.1. 背景
1.2. Purpose and Scope	1.2. 目的と範囲
1.3. Target Audience	1.3. 対象読者
1.4. IR 8011 Series Organization	1.4. IR 8011シリーズの構成
2. IR 8011 Fundamentals	2. IR 8011の基本
2.1. How to Use IR 8011	2.1. IR 8011 の使用方法
2.2. When to Use IR 8011	2.2. IR 8011 の使用タイミング
2.3. Foundational Concepts	2.3. 基本概念
2.3.1. Boundaries	2.3.1. 境界
2.3.2. Security Capabilities for Continuous Monitoring	2.3.2. セキュリティの継続的なモニタリング機能
2.3.3. Sub-Capabilities	2.3.3. サブ機能
2.3.4. Adversarial Attack Step Model	2.3.4. 敵対的攻撃ステップモデル
2.3.4.1. Attack Step	2.3.4.1. 攻撃ステップ
2.3.4.2. Defend Step	2.3.4.2. 防衛ステップ
2.3.5. Test Automation in IR 8011	2.3.5. IR 8011 におけるテスト自動化
2.3.5.1. Actual State	2.3.5.1. 現状
2.3.5.2. Desired State Specification	2.3.5.2. 望ましい状態の仕様
3. IR 8011 Methodology	3. IR 8011 メソッド
3.1. Objective #1: Sub-Capability Test Development	3.1. 目的 #1: サブ機能テストの開発
3.1.1. Identify Attack Steps	3.1.1. 攻撃ステップの識別
3.1.2. Identify Defend Steps	3.1.2. 防衛手順の識別
3.1.3. Determine Sub-Capabilities	3.1.3. サブ能力の決定
3.1.4. Identify Control Items	3.1.4. 管理項目の識別
3.1.5. Identify Determination Statements	3.1.5. 決定文の識別
3.1.6. Create Sub-Capability Tests	3.1.6. サブ能力テストの作成
3.1.6.1. Sub-Capability Test Types	3.1.6.1. サブ能力テストの種類
3.1.6.2. Data Quality Measures	3.1.6.2. データ品質測定
3.1.6.3. Sub-Capability Test Creation	3.1.6.3. サブ能力テストの作成
3.1.6.4. Sub-Capability Test Non-Conformance	3.1.6.4. サブキャパシティテストの不適合
3.1.6.5. Root Cause Analysis	3.1.6.5. 根本原因分析
3.2. Objective #2: Capability Control Identification	3.2. 目標 #2：能力統制の識別
3.2.1. Identify Testable Controls	3.2.1. テスト可能な管理策の識別
3.2.2. Group Testable Controls	3.2.2. テスト可能な管理策のグループ化
3.3. Methodology Summary	3.3. 方法論のまとめ
4. Conceptual IR 8011 Implementation and Considerations	4. 概念的な IR 8011 の実装と考慮事項
4.1. IR 8011 Solution Developer's Perspective	4.1. IR 8011 ソリューション開発者の視点
4.1.1. Build a Custom IR 8011 Solution	4.1.1. カスタムIR 8011ソリューションの構築
4.1.1.1. Design for Automated Control Testing	4.1.1.1. 自動統制テストの設計
4.1.1.2. Determine Necessary Data Sources.	4.1.1.2. 必要なデータソースの決定。
4.1.1.3. Define Data Relationships.	4.1.1.3. データ関係の定義。
4.1.1.4. Define Solution Functionalities	4.1.1.4. ソリューション機能の定義
4.1.1.5. Analysis and Reporting	4.1.1.5. 分析とレポート
4.1.1.6. Develop, Use, and Maintain an IR 8011 Database.	4.1.1.6. IR 8011 データベースの開発、使用、および維持
4.1.1.7. Control Search (via Keywords)	4.1.1.7. （キーワードによる）統制検索
4.1.2. Integrate IR 8011 Sub-Capability Tests into Existing Solutions	4.1.2. IR 8011 サブ機能テストを既存のソリューションに統合する
4.1.3. Derive Sub-Capability Tests Outside of IR 8011 Scope	4.1.3. IR 8011 の適用範囲外のサブ機能テストの導出
4.1.4. Control Testing as a Service	4.1.4. コントロール・テスト・アズ・ア・サービス
4.2. IR 8011 Solution Adopter's Perspective	4.2. IR 8011 ソリューション採用者の視点
4.2.1. Roles and Responsibilities	4.2.1. 役割と責任
4.2.2. Buy or Build Considerations	4.2.2. 購入または構築の検討事項
4.2.3. Support for Internal Automated Control Testing	4.2.3. 内部自動コ統制テストの支援
4.2.4. Support for External Independent Automated Control Testing	4.2.4. 外部の独立した自動統制テストの支援
4.2.5. Integration Into Existing Continuous Monitoring Programs	4.2.5. 既存の継続的モニタリングプログラムへの統合
4.3. Understanding Limitations to IR 8011 Operationalization	4.3. IR 8011 の運用上の制限事項の理解
4.4. Implementation Validation	4.4. 実装の妥当性確認
References	参考文献
Appendix A. Glossary	附属書 A. 用語集
Appendix B. List of Abbreviations and Acronyms	附属書 B. 略語および頭字語の一覧
Appendix C. NIST RMF-Related Publications and Their Relationships to IR 8011	附属書 C. NIST RMF 関連の出版物と IR 8011 との関係
Appendix D. Benefits of Breaking Down Security Capabilities Into Elements	附属書 D. セキュリティ機能を要素に分解することの利点
D.1. Supports the Strong Systems Engineering of Security Capabilities	D.1. セキュリティ機能の強力なシステムエンジニアリングをサポートする
D.2. Supports Guidance for Control Selection	D.2. 統制の選択に関する指針をサポートする
D.3. Simplifies Understanding of the Overall Protection Process	D.3. 全体的な防御プロセスの理解を単純化する
D.4. Enables Testing of Control Outcomes at a Higher Level Than Individual Controls	D.4. 個々の統制よりも高いレベルで統制の結果をテストすることを可能にする
D.5. Improves Risk Management by Measuring Control Outcomes	D.5. 統制の結果を測定することでリスクマネジメントを改善する
D.6. Helps Organizations Address Organizational, Mission, and Business Risks	D.6. 組織が組織、ミッション、およびビジネスリスクに対処するのを支援する
Appendix E. Considerations for IR 8011 Implementation Validation	附属書 E. IR 8011 実施妥当性確認に関する考慮事項
Appendix F. Change Log	附属書 F. 変更履歴

Executive Summary	エグゼクティブサマリー
This NIST Internal Report (IR) provides a methodology for using automation to test the implementation of NIST Special Publication (SP) 800-53 security and privacy controls in support of security capabilities for continuous monitoring. Security capabilities represent foundational defense capabilities against potential cyber attacks to systems and organizations. The IR 8011 methodology explores these security capabilities using an attack step model for the purpose of identifying more detailed and specific capabilities, called sub-capabilities, that can be tested. Subsequent volumes in this multi-volume series, published separately, present a sample collection of sub-capabilities, sub-capability tests, and associated controls that support specific security capabilities, one capability per volume. All volumes in the IR 8011 series provide a blueprint for the development and adoption of a potential IR 8011 solution.	この NIST 内部報告書（IR）は、自動化を使用して NIST 特別刊行物（SP）800-53 のセキュリティおよびプライバシー管理策の実施をテストし、セキュリティ能力をサポートしてセキュリティの継続的なモニタリングを行うための方法論を提供する。セキュリティ機能は、システムや組織に対する潜在的なサイバー攻撃に対する基本的な防御機能である。IR 8011の方法論では、テスト可能なより詳細かつ具体的な機能（サブ機能と呼ばれる）を識別することを目的として、攻撃ステップモデルを使用してこれらのセキュリティ機能を調査する。この複数巻シリーズの続巻は、個別に発行され、特定のセキュリティ機能をサポートするサブ機能のサンプルコレクション、サブ機能テスト、および関連制御を、巻ごとに1つの機能ごとに提示する。IR 8011シリーズのすべてのボリュームは、潜在的なIR 8011ソリューションの開発と採用に向けた青写真を提供する。
The IR 8011 methodology was designed to be used with the NIST Risk Management Framework (RMF), specifically in support of the Assess and Monitor steps. Each control in the SP 800-53 control catalog has an associated assessment procedure in SP 800-53A, which is leveraged for the development of sub-capability tests. It is possible to apply the IR 8011 methodology using controls other than those from the SP 800-53 catalog following a different framework or methodology as long as controls have associated assessment procedures. The assessment procedures provide the necessary determination statements to support the development of sub-capabilities tests.	IR 8011の方法は、特に「評価」と「監視」のステップをサポートする目的で、NISTリスクマネジメント枠組み（RMF）と併用できるように設計されている。SP 800-53の管理カタログに記載されている各管理には、SP 800-53Aに関連するアセスメント手順が記載されており、これはサブ能力テストの開発に活用される。SP 800-53 カタログ以外のコントロールを使用して、異なる枠組みや方法論に従って IR 8011 の方法論を適用することも可能である。ただし、コントロールに関連するアセスメント手順が存在することが条件となる。アセスメント手順は、サブ能力テストの開発をサポートするのに必要な判定文を提供する。
This major revision to IR 8011, Volume 1, preserves the original methodology first introduced in 2017 and focuses on improving the way in which the methodology is presented to facilitate understanding of the foundational concepts and the purpose of the methodology. Key terms and visual aids, such as diagrams and other graphics, were updated to better describe IR 8011 processes and their elements. A dedicated section on an envisioned IR 8011 operationalization has been added to provide conceptual implementation examples and considerations for IR 8011 solution developers and adopters. These examples are intended to illustrate how IR 8011 concepts work to strengthen the understanding of the methodology and facilitate implementation.	IR 8011 第1巻のこの大幅な改訂では、2017年に初めて導入された当初の方法論を維持し、方法論の基礎となる概念と目的の理解を促進するために、方法論の提示方法を改善することに重点が置かれている。 重要な用語や、図やその他のグラフィックなどの視覚資料は、IR 8011のプロセスとその要素をより適切に説明するために更新された。IR 8011 の運用化に関する想定される専用セクションが追加され、IR 8011 ソリューションの開発者および採用者向けに概念的な実装例と考慮事項が提供されている。これらの例は、IR 8011 の概念がどのように機能し、方法論の理解を深め、実装を促進するかを説明することを目的としている。

1. IR 8011 Overview	1. IR 8011 の概要
1.1. Background	1.1. 背景
The IR 8011 methodology was designed to work with the NIST Risk Management Framework (RMF) and supporting technical publications,9 including the [SP800-53] control catalog, [SP800-53A] control assessment guidance and procedures, [SP800-53B] control baselines, and [SP800-137] continuous monitoring concepts.	IR 8011 手法は、NIST リスクマネジメント枠組み（RMF）および、[SP800-53] 統制カタログ、[SP800-53A] 統制アセスメントの指針および手順、[SP800-53B] 統制ベースライン、[SP800-137] 継続的モニタリングの概念を含む技術文書9をサポートするものとして設計された。
9 See Appendix C for a listing of NIST RMF-related publications and their relationships to IR 8011.	9 NIST RMF 関連の出版物および IR 8011 との関係については、附属書 C を参照のこと。
An essential aspect of the NIST RMF is the use of security and privacy controls to safeguard information handled by an organizational system and ensure that security and privacy objectives are met. These controls are assessed and monitored periodically to verify that they are in place, operating as expected, and meeting security and privacy objectives.	NIST RMF の重要な要素は、組織のシステムが取り扱う情報を保護し、セキュリティおよびプライバシーの目標が確実に達成されるようにするためのセキュリティおよびプライバシー管理策の使用である。これらの管理策は、適切に導入され、期待通りに運用され、セキュリティおよびプライバシーの目標を達成していることを検証するために、定期的にアセスメントおよびモニタリングされる。
Monitoring all selected controls as frequently10 as needed using manual methods is impractical and unrealistic for most organizations due to the sheer size, complexity, and scope of their information technology footprint. The rapid deployment of new technologies may spawn new risks that make the manual or procedural monitoring of controls unattainable for many organizations.	ほとんどの組織では、情報技術の規模、複雑さ、範囲が大きすぎるため、手動の方法で必要な頻度10で選択したすべての統制を監視することは非現実的であり、不可能である。新しい技術の急速な展開により、多くの組織では手動または手順による統制の監視が不可能になるという新たなリスクが生じる可能性がある。
10 The frequency is enough to maintain ongoing awareness of control effectiveness.	10 この頻度は、統制の有効性に対する継続的な認識を維持するのに十分である。
Control assessment objectives for items in the base control and control enhancements, referred to as control items, are provided in [SP800-53A]. The potential assessment methods examine, interview, and/or test (see Table 1), are used to compare the actual state (i.e., what is in place; see Sec. 2.3.5.1) against the desired state specification (i.e., what is expected to be implemented; see Sec. 2.3.5.2). The organization uses the results of the assessments — regardless of the method used — to support the determination of control existence, functionality, correctness, and completeness, as well as the potential for improvement over time.	基本統制および統制強化の項目（統制項目と呼ばれる）の統制アセスメントの目的は、[SP800-53A]に記載されている。潜在的なアセスメント方法である調査、インタビュー、および/またはテスト（表1参照）は、実際の状態（すなわち、現状のもの、すなわち、セクション2.3.5.1参照）と望ましい状態の仕様（すなわち、実装が期待されるもの、すなわち、セクション2.3.5.2参照）を比較するために使用される。組織は、使用した方法に関わらず、アセスメントの結果を、統制の存在、機能性、正確性、完全性、および将来的な改善の可能性を判断する根拠として使用する。
Table 1. Potential assessment methods [SP800-53A]	表1. 潜在的なアセスメント方法 [SP800-53A]
Method : Definition	方法：定義
Examine : The process of checking, inspecting, reviewing, observing, studying, or analyzing one or more assessment objects to facilitate understanding, achieve clarification, or obtain evidence.	調査：理解を深め、明確化を図り、または証拠を入手するために、1つまたは複数のアセスメント対象を検査、点検、レビュー、観察、調査、または分析するプロセス。
Interview : The process of conducting discussions with individuals or groups within an organization to facilitate understanding, achieve clarification, or lead to the location of evidence.	インタビュー：理解を深め、明確化を図り、または証拠の所在を突き止めるために、組織内の個人またはグループと話し合いを行うプロセス。
Test 11: The process of exercising one or more assessment objects under specified conditions to compare actual with expected behavior.	テスト 11：特定の条件下で1つまたは複数のアセスメント対象を実行し、実際の動作と期待される動作を比較するプロセス。
11 The implementation of a continuous monitoring program considers the test assessment method whenever it is applicable. Use of the automated test method may provide more accurate and repeatable results when constructed and implemented correctly. It is more difficult to automate the examine and interview assessment methods, which require more complex systems to enable capture and accurate interpretation of the input (from examination of artifacts and interviews). Organizations might employ the examine and/or interview methods for root cause analysis (see Sec. 3.1.6) of other than satisfied controls or if greater assurance, depth, or coverage is needed.	11 継続的なモニタリングプログラムを実施する際には、適用可能な場合は常にテストアセスメント方法を考慮する。自動テスト方法を使用すると、正しく構築および実施された場合には、より正確で再現性のある結果が得られる可能性がある。 テストおよびインタビューによるアセスメント方法を自動化することはより難しく、入力（アーティファクトの調査やインタビューによる）の取得と正確な解釈を可能にするには、より複雑なシステムが必要となる。 組織は、満足のいく統制以外の根本原因分析（第3.1.6項参照）や、より高い保証、深度、または網羅性が必要な場合、テストおよび/またはインタビューによる方法を採用することがある。
1.2. Purpose and Scope	1.2. 目的と適用範囲
The IR 8011 series offers an approach for automating control testing to support continuous monitoring that focuses on the test assessment method [SP800-53A] as the method with most potential for automation in support of the RMF Assess and Monitor steps. IR 8011 supports the testing of controls using automation, which is beyond the scope of SP 800-53A.12 IR 8011 is not about automating the implementation of security and privacy controls (RMF Implement step). This volume introduces fundamental concepts and proposes a methodology for creating automatable tests for monitoring SP 800-53 controls by leveraging the determination statements in SP 800-53A13 assessment procedures as the basis for the tests. These tests are traced to specific continuous monitoring security capabilities14, which are groups of controls with a common defense purpose. The key elements of the IR 8011 methodology are illustrated in Fig. 1, from the development of sub-capability15 tests to the identification of testable controls with a shared common purpose for a specific security capability.	IR 8011 シリーズは、RMF のアセスメントおよびモニタリング手順をサポートする自動化の可能性が最も高い方法として、テスト評価方法[SP800-53A]に焦点を当てた継続的なモニタリングをサポートする、統制テストの自動化アプローチを提供する。IR 8011 は、SP 800-53A の適用範囲を超える自動化による統制のテストをサポートする。IR 8011 は、セキュリティおよびプライバシー統制の実施（RMF 実施ステップ）の自動化に関するものではない。本書では、SP 800-53A13 のアセスメント手順における決定文をテストの基礎として活用し、SP 800-53 の管理策を監視するための自動化可能なテストを作成するための基本的な概念と方法論を提案している。これらのテストは、特定の継続的なセキュリティのモニタリング能力14、すなわち共通の防御目的を持つ管理策のグループにまで遡ることができる。IR 8011 方法論の主要な要素は、サブ能力15テストの開発から、特定のセキュリティ能力に対する共通の目的を持つテスト可能な統制の特定に至るまで、図1に示されている。
12 [SP800-53A] states that “detailed scripts may need to be developed for the specific operating system, network component, middleware, or application employed within the system to adequately assess certain characteristics of a particular security or privacy control. Such test scripts are at a lower level of detail than provided by the assessment procedures contained in SP 800-53A and are beyond the scope of SP 800-53A.”	12 [SP800-53A] では、「特定のセキュリティまたはプライバシー管理の特性を適切に評価するために、システム内で使用される特定のオペレーティングシステム、ネットワークコンポーネント、ミドルウェア、またはアプリケーションについて、詳細なスクリプトを開発する必要がある場合がある。このようなテストスクリプトは、SP 800-53A に記載されているアセスメント手順で提供されるものよりも詳細度が低く、SP 800-53A の適用範囲を超える」と述べている。
13 Although these tests derive from SP 800-53A assessment procedures that have been designed to assess SP 800-53 controls, IR 8011 is primarily a continuous monitoring initiative.	13 これらのテストは、SP 800-53 コントロールを評価するために設計された SP 800-53A アセスメント手順に由来するものであるが、IR 8011 は主に継続的なモニタリングのイニシアティブである。
14 Security capabilities are discussed in more detail in Sec. 2.3.	14 セキュリティ能力については、セクション 2.3 でさらに詳しく説明する。
15 Sub-capabilities are discussed in more detail in Sec. 2.3.	15 サブ能力については、セクション 2.3 でさらに詳しく説明する。
Section 3 describes each element in Fig. 1 and their contributions toward meeting the methodology’s two main objectives:	第3項では、図1の各要素と、方法論の2つの主要目的の達成に向けた貢献について説明する。
1. Sub-capability test development	1. サブ能力テストの開発
2. Capability control identification	2. 能力統制の特定
These objectives are highlighted by the arrows in Fig. 2 and described in detail in Sec. 3.1 and Sec. 3.2.	これらの目的は図2の矢印で強調されており、セクション3.1およびセクション3.2で詳細に説明されている。

対象読者...

1.3. Target Audience	1.3. 対象読者
The primary target audience for this publication are the two groups involved with the potential implementation of an automated control testing solution in support of an organization’s continuous monitoring program: solution developers/providers and adopters.	この文書の主な対象読者は、組織の継続的モニタリングプログラムを支援する自動統制テストソリューションの導入を検討している2つのグループ、すなわちソリューション開発者/プロバイダと採用者である。
Solution developers/providers	ソリューション開発者/プロバイダ
Solution developers or providers are the actual implementers of the IR 8011 methodology.	ソリューション開発者またはプロバイダは、IR 8011 方法論を実際に導入する立場にある。
They take the IR 8011 blueprints and package test functionalities into a product or solution. Solution providers are system integrators and/or service providers that offer solutions based on the methodology provided in this overview volume to solution adopters, whether as a stand-alone solution or integrated into another product. The automated control testing strategy used by the organization may leverage commercial off-the-shelf, community-built, in-house developed products, or any combination of the three. An IR 8011 solution could be, for instance, an add-on feature to an existing security management application, such as a Governance, Risk, and Compliance (GRC) application.	IR 8011 の設計図を基に、テスト機能を製品またはソリューションにパッケージ化する。ソリューションプロバイダは、システムインテグレータおよび/またはサービスプロバイダであり、この概要で提供されている方法論に基づくソリューションを、ソリューション採用者に単独ソリューションとして、または他の製品に統合した形で提供する。組織が使用する自動制御テスト戦略は、市販の既製品、コミュニティで構築された製品、社内開発製品、またはこれら3つの組み合わせを活用することができる。IR 8011ソリューションは、例えば、ガバナンス、リスク、コンプライアンス（GRC）アプリケーションなどの既存のセキュリティ管理アプリケーションへの追加機能として実装することができる。
Solution adopters	ソリューションの採用者
Solution adopters are the users or consumers of the product or service solution. Adopters may also be the entity that commissions custom IR 8011 solutions, whether developed inhouse or externally contracted. Within the solution-adopting organization, there are additional roles that are identified for a specific security capability, such as operational and managerial roles for a capability (e.g., Device Manager [DM]; Desired State Managers and Authorizers [DSM]; Risk Executive, System Owner, and/or Authorizing Official [RiskExec]). These roles complement existing SP 800-37-defined risk management responsibilities and continuous monitoring operational responsibilities. The capability-specific roles are identified in each capability-specific volume.	ソリューションの採用者は、製品またはサービスソリューションのユーザーまたは消費者である。採用者は、カスタム IR 8011 ソリューションを委託する事業体である可能性もあり、そのソリューションは社内開発または外部委託のいずれかである。ソリューションを採用する組織内には、特定のセキュリティ機能ごとに識別される追加の役割があり、例えば、機能の運用および管理の役割（例えば、デバイス管理者（DM）、望ましい状態管理者および認可者（DSM）、リスクエグゼクティブ、システム所有者、および/または認可当局者（RiskExec）など）がある。これらの役割は、SP 800-37で定義された既存のリスクマネジメント責任および継続的な監視の運用責任を補完するものである。能力に特化した役割は、各能力に特化したボリュームで識別される。
A potential third group may or may not be involved with the actual operationalization (implementation) of the IR 8011 methodology: cybersecurity researchers.	潜在的な第3のグループは、IR 8011の方法論の実際の運用化（実装）に関与する場合も、関与しない場合もある。サイバーセキュリティ研究者。
Cybersecurity researchers	サイバーセキュリティ研究者
Cybersecurity researchers16 constitute a potential third audience group due to the existence of opportunities for further research related to the IR 8011 methodology. Cybersecurity research can contribute to the growth and expansion of the IR 8011 methodology with increased speed and accuracy in mind. For example, research into the use of machine learning and natural language processing to identify control items17 based on context or description could improve the control search process by not relying on the developer to elaborate keywords and the logic behind the keyword search rules. Reliance on an individual’s knowledge of a control or a control catalog may result in inaccurate or incomplete identification of controls and limit the full potential of the IR 8011 methodology. This third audience group is not necessarily defined to support NIST’s research on improving the IR 8011 methodology, although comments on the methodology are always welcomed. Cybersecurity researchers can be embedded within solution development or adoption teams and contribute problem-solving and innovations that pertain to the development or implementation of an IR 8011 solution.	サイバーセキュリティ研究者16は、IR 8011 方法論に関連するさらなる研究の機会が存在するため、潜在的な第3の対象グループとなる。サイバーセキュリティ研究は、より迅速かつ正確なことを念頭に、IR 8011 方法論の成長と拡大に貢献できる。例えば、文脈や記述に基づいて統制項目を識別する機械学習や自然言語処理の使用に関する研究は、開発者がキーワードやキーワード検索規則の背後にあるロジックを詳しく説明することに頼らずに、統制の検索プロセスを改善できる可能性がある。統制に関する個人の知識や統制カタログに頼ることは、統制の識別が不正確または不完全になる可能性があり、IR 8011 方法論の潜在能力を十分に発揮できない可能性がある。この第3の対象グループは、必ずしもNISTによるIR 8011手法の改善に関する研究を支援するために定義されたものではないが、手法に関するコメントは常に歓迎される。 サイバーセキュリティの研究者は、ソリューションの開発または導入チームに組み込まれ、IR 8011ソリューションの開発または実装に関連する問題解決やイノベーションに貢献することができる。
16  This refers to cybersecurity researchers outside of NIST.	16 これは、NIST以外のサイバーセキュリティ研究者に関するものである。
17  The control item identification process is discussed in Sec. 3.1.4.	17 管理項目の識別プロセスについては、セクション3.1.4で説明されている。
All target audience groups are encouraged to collaborate and communicate requirements, requirement specifications, maintenance and support strategies, and other development and acquisition concerns to ensure adherence to any applicable organizational requirement for managing security and privacy risks. This may include determining how the solution developers or solution providers keep up with NIST updates to SP 800-53 controls and SP 800-53A assessment procedures and how the products or solutions are kept up to date.	セキュリティおよびプライバシーリスクの管理に関する組織の要件を確実に満たすため、すべての対象グループは、要件、要件仕様、保守およびサポート戦略、その他の開発および取得に関する懸念事項について、協力しコミュニケーションを図ることが推奨される。これには、ソリューション開発者またはソリューションプロバイダが、NISTによるSP 800-53管理およびSP 800-53Aアセスメント手順の更新にどのように対応しているか、また、製品またはソリューションがどのように最新の状態に保たれているかを判断することが含まれる。
Individuals who are responsible for the design, development, and implementation of continuous monitoring and control assessment processes may also find interest in the IR 8011 series, including those in the following roles:	継続的な監視および制御アセスメントプロセスの設計、開発、実装を担当する個人も、IR 8011シリーズに関心を持つ可能性がある。以下のような役割の個人も含まれる。
• Solution development and integration (e.g., software developers, service providers)	• ソリューションの開発および統合（例：ソフトウェア開発者、サービスプロバイダ）
• System development and integration (e.g., program managers, system developers, system integrators, enterprise architects, security and privacy architects)	• システム開発および統合（例：プログラムマネージャー、システム開発者、システムインテグレーター、エンタープライズアーキテクト、セキュリティおよびプライバシーアーキテクト）
• System management (e.g., senior leaders, risk executives, authorizing officials, chief information officers, chief information security officers, chief privacy officers, system owners, security and privacy officers, data managers)	• システム管理（例：上級リーダー、リスク管理責任者、認可当局者、最高情報責任者、最高情報セキュリティ責任者、最高プライバシー責任者、システムオーナー、セキュリティおよびプライバシー担当責任者、データ管理者）
• Control assessment and monitoring (e.g., system evaluators, control assessors, control assessment teams, independent verification and validation assessors, auditors, testers, security operations center personnel)	• 統制の評価およびモニタリング（例：システム評価者、統制アセスメント担当者、統制アセスメントチーム、独立検証および妥当性確認アセスメント担当者、監査人、テスター、セキュリティ・オペレーション・センター職員）
• Security and privacy control implementation and operations (e.g., system owners; common control providers; information owners or stewards; mission and business process owners; security and privacy architects; security and privacy engineers; security and privacy officers; system, network, database, or application administrators)	• セキュリティおよびプライバシー管理の実施と運用（例：システム所有者、共通管理プロバイダ、情報所有者またはスチュワード、ミッションおよびビジネスプロセスの所有者、セキュリティおよびプライバシーアーキテクト、セキュリティおよびプライバシーエンジニア、セキュリティおよびプライバシーオフィサー、システム、ネットワーク、データベース、またはアプリケーションの管理者）
• Information technology modernization (e.g., chief modernization officers, chief transformation officers, continuous process improvement managers or specialists)	• 情報技術の近代化（例：最高近代化責任者、最高変革責任者、継続的プロセス改善マネージャーまたは専門家）

ちなみに現在のバージョンは...

IR	8011	Automation Support for Security Control Assessments	セキュリティ管理策アセスメントの自動化サポート	発行日
	Vol. 1	Volume 1: Overview	第1巻：概要	2017.06.06
	Vol. 2	Volume 2: Hardware Asset Management	第2巻：ハードウェア資産管理	2017.06.06
	Vol. 3	Software Asset Management	ソフトウェア資産管理	2018.12.06
	Vol. 4	Software Vulnerability Management	ソフトウェア脆弱性管理	2020.04.28

---

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

IR 8011

・2023.12.11 NIST CSWP 30 コントロール・アセスメントの自動化支援プロジェクトの最新情報とビジョン

・2023.02.26 NIST 「NISTIR 8011 Vol.1. セキュリティコントロールアセスメントの自動化支援：第1巻：概要」についての意見募集

総務省 意見募集 「eシールに係る認定制度の関係規程策定のための有識者会議取りまとめ（案）」及び 「eシールに係る認証業務の認定に関する規程（案）」

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

総務省が、「eシールに係る認定制度の関係規程策定のための有識者会議取りまとめ（案）」及び 「eシールに係る認証業務の認定に関する規程（案）」を公表し、意見募集をしていますね...

eシールは会社印のようなもので、欧州ではeIDASの中で電子シールとして規定されているものですね...日本でもその制度化に向けて動き出しているというところです...

紙で社印をおしていた文書が電子化されるとeシールをついたデータということだと思いますが、紙と異なり電子だとそれが本物だということを証明するのに、少し手間がかかりますね。。。それでも、紙に印刷して社印を押すという作業と比較すれば、ずいぶんと時間とコストの削減にはなると思うんですけどね...

eシールがついたデータは出所又は起源がわかり、そのデータが改変が行われていないことがわかるということですよね...

PKIの監査については、ちゃんとしたルールを作った方が良いですよね...一般的に認定のための確認作業についての一定のルールが必要だと思うんですよね...WebTrustのような...

できれば、保証水準に段階があればよいと思います...

eシール認証業務の認定基準は総務省告示の予定です...

告示の根拠は、総務省設置法4条第1項第60号の規定

58 符号、音響、影像その他の情報の電磁的方式による発信、伝送又は受信（以下「情報の電磁的流通」という。）のための有線又は無線の施設の設置及び使用の規律並びにこれらの施設の整備の促進に関すること。
59 国際放送その他の本邦と外国との間の情報の電磁的流通の促進に関すること。
60 前二号に掲げるもののほか、情報の電磁的流通の規律及び振興に関すること。

ということのようです...

● 総務省

・2025.01.27 「eシールに係る認定制度の関係規程策定のための有識者会議取りまとめ（案）」及び 「eシールに係る認証業務の認定に関する規程（案）」に対する意見募集

意見募集対象ですが...

・別紙1「eシールに係る認定制度の関係規程策定のための有識者会議取りまとめ（案）」

・別紙2 「eシールに係る認証業務の認定に関する規程（案）」

・eシールに係る認定制度の関係規程策定のための有識者会議

・開催に関する報道発表（令和6年6月3日）
・「eシールに係る認定制度の関係規程策定のための有識者会議取りまとめ（案）」及び「eシールに係る認証業務の認定に関する規程（案）」対する意見募集に関する報道発表（令和7年1月27日）
 

・第1回（令和6年6月13日）
・第2回（令和6年6月27日）
・第3回（令和6年7月23日）
・第4回（令和6年8月20日）
・第5回（令和6年9月30日）
・第6回（令和6年10月24日）
・第7回（令和6年11月14日）
・第8回（令和6年12月18日）

---

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

・2024.07.12 総務省 「ICTサイバーセキュリティ政策の中期重点方針」（案）に対する意見募集 (2024.07.01)

・2024.04.23 総務省 「eシールに係る検討会 最終取りまとめ」、「eシールに係る指針（第2版）」及び意見募集の結果の公表 (2024.04.16)

・2023.04.13 総務省 我が国におけるeシールサービスの状況等に関する情報提供依頼

・2020.12.06 ENISA 第19条専門家グループ第16回会合：eIDAS監督機関等の53名の専門家が信託サービスのセキュリティとインシデント報告に関する情報を交換

・2020.11.13 JIPDEC 第98回JIPDECセミナー 「eシールとは？ —内外での活用状況からJIPDECの取組みまで」資料公開

・2020.04.21 会社認印電子版？＝＞総務省 組織が発行するデータの信頼性を確保する制度に関する検討会

---

Continue reading "総務省 意見募集 「eシールに係る認定制度の関係規程策定のための有識者会議取りまとめ（案）」及び 「eシールに係る認証業務の認定に関する規程（案）」"

米国 NIST IR 8374 Rev.1（初期公開ドラフト）ランサムウェアのリスクマネジメント： サイバーセキュリティフレームワーク2.0コミュニティ (2025.01.13)

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

NISTが、サイバーセキュリティフレームワーク Ver. 2.0 を利用したコミュニティプロファイルを公表し、意見募集をしていますね...

ランサムウェア対策についてのポイントは次のように考えているようです...

1. ランサムウェアの感染を避けるために従業員を教育する。
2. ランサムウェアに悪用されるような脆弱性をシステムに持たないようにする。
3. ランサムウェア攻撃や感染を迅速に検知し、阻止する。
4. ランサムウェアが広がりにくくする。
5. 将来ランサムウェアが発生した場合に、保存されている情報の復旧を容易にする。

● NIST - ITL

・2025.01.13 Ransomware Risk Management: CSF 2.0 Community Profile | Draft NIST IR 8374r1 Available for Comment

Ransomware Risk Management: CSF 2.0 Community Profile | Draft NIST IR 8374r1 Available for Comment	ランサムウェアのリスクマネジメント： CSF 2.0 コミュニティプロファイル｜ドラフト NIST IR 8374r1 コメント募集中
The National Cybersecurity Center of Excellence (NCCoE) has published an initial public draft of NIST Interagency Report (NIST IR) 8374 Revision 1, Ransomware Risk Management: A Cybersecurity Framework 2.0 Community Profile. Organizations at home and abroad use NIST IR 8374 to guard against ransomware. We are seeking your feedback on the publication’s contents and the future direction of NIST’s ransomware guidance.	国立サイバーセキュリティ・センター・オブ・エクセレンス（NCCoE）は、NIST Interagency Report（NIST IR）8374 Revision 1「ランサムウェアのリスクマネジメント」の初期公開ドラフトを公表した：サイバーセキュリティフレームワーク2.0 コミュニティプロファイル」である。国内外の組織がランサムウェア対策にNIST IR 8374を利用している。本書の内容およびNISTのランサムウェア・ガイダンスの今後の方向性について、皆様からのご意見を募集している。
NIST IR 8374 reflects changes made to the Cybersecurity Framework (CSF) from CSF 1.1 to CSF 2.0 which identifies security objectives that support managing, detecting, responding to, and recovering from ransomware events. Ransomware can attack organizations of all sizes from any sector. You can use this publication to gauge your organization’s readiness to counter ransomware threats, mitigate potential consequences of a ransomware event, and to develop a ransomware countermeasure playbook.	NIST IR 8374は、CSF 1.1からCSF 2.0へのサイバーセキュリティ枠組み（CSF）の変更を反映しており、ランサムウェアイベントの管理、検知、対応、復旧をサポートするセキュリティ目標を特定している。ランサムウェアは、あらゆる業種のあらゆる規模の組織を攻撃する可能性がある。本書は、ランサムウェアの脅威に対抗するための組織の準備態勢を評価し、ランサムウェアイベントの潜在的な影響を緩和し、ランサムウェア対策プレイブックを作成するために使用できる。

・2025.01.13 NIST IR 8374 Rev. 1 (Initial Public Draft) Ransomware Risk Management: A Cybersecurity Framework 2.0 Community

NIST IR 8374 Rev. 1 (Initial Public Draft) Ransomware Risk Management: A Cybersecurity Framework 2.0 Community	NIST IR 8374 Rev.1（初期公開ドラフト）ランサムウェアのリスクマネジメント： サイバーセキュリティフレームワーク2.0コミュニティ
Announcement	発表
This draft Ransomware Community Profile reflects changes made to the Cybersecurity Framework (CSF) from CSF 1.1 to CSF 2.0 which identifies security objectives that support managing, detecting, responding to, and recovering from ransomware events. Ransomware can attack organizations of all sizes from any sector. You can use this publication to gauge your organization’s readiness to counter ransomware threats, mitigate potential consequences of a ransomware event, and to develop a ransomware countermeasure playbook.	このランサムウェアコミュニティプロファイルのドラフトは、ランサムウェアイベントの管理、検知、対応、回復をサポートするセキュリティ目標を特定するサイバーセキュリティフレームワーク（CSF）1.1からCSF2.0への変更を反映している。ランサムウェアは、あらゆる業種のあらゆる規模の組織を攻撃する可能性がある。本書は、ランサムウェアの脅威に対抗するための組織の準備態勢を評価し、ランサムウェアイベントの潜在的な影響を緩和し、ランサムウェア対策プレイブックを作成するために使用できる。
Per the "Note to Reviewers" starting on line 104 of the draft, NIST is interested in answers to the following questions:	ドラフトの104行目から始まる「査読者への注記」によると、NISTは以下の質問に対する回答に関心を示している：
1. What elements of this Community Profile have been helpful?	1. このコミュニティプロファイルのどのような要素が役に立ったか？
2. Where could this Community Profile be improved?	2. このコミュニティプロファイルのどこを改善できるか？
3. Are supplemental documents, such as quick start guides, useful? If so, how? If not, why?	3. クイック・スタート・ガイドなどの補足資料は有用か。役立つとすれば、どのように役立つか？そうでない場合、その理由は？
4. What type of prioritization would be most helpful? Control baselines? high/medium/low criticality? Mapping to specific organizational outcomes? Other?	4. どのような優先順位付けが最も有用か。管理ベースライン、重要度の高・中・低？特定の組織の成果へのマッピング？その他？
5. What other ransomware resources have you or your organization used to improve your ransomware risk mitigation strategy? How have those resources been helpful?	5. ランサムウェアのリスク緩和戦略を改善するために、あなたまたはあなたの組織は他にどのようなランサムウェアのリソースを利用したか？それらのリソースはどのように役立ったか？
General comments on the draft are also welcome.	ドラフトに関する一般的なコメントも歓迎する。
Abstract	概要
Ransomware is a type of malicious attack where attackers encrypt an organization’s data and demand payment to restore access. Attackers may also steal an organization’s information and demand an additional payment in return for not disclosing the information to authorities, competitors, or the public. This Cybersecurity Framework (CSF) 2.0 Community Profile identifies the security objectives from the NIST CSF 2.0 that support governing management of, identifying, protecting against, detecting, responding to, and recovering from ransomware events. The Profile can be used as a guide to managing the risk of ransomware events. That includes helping to gauge an organization’s level of readiness to counter ransomware threats and to deal with the potential consequences of events. This Profile can be leveraged in developing a ransomware countermeasure playbook.	ランサムウェアは、攻撃者が組織のデータを暗号化し、アクセスを回復するために支払いを要求する悪意のある攻撃の一種である。攻撃者はまた、組織の情報を盗み出し、当局、競合他社、または公衆に情報を開示しない見返りとして、追加の支払いを要求することもある。このサイバーセキュリティフレームワーク（CSF）2.0コミュニティプロファイルは、ランサムウェアイベントの管理、識別、防御、検知、対応、回復をサポートするNIST CSF 2.0のセキュリティ目標を特定するものである。このプロファイルは、ランサムウェアのリスクをマネジメントするためのガイドとして利用できる。これには、ランサムウェアの脅威に対抗し、イベントの潜在的な結果に対処するための組織の準備態勢のレベルを測定するのに役立つことも含まれる。このプロファイルは、ランサムウェア対策プレイブックを作成する際に活用できる。

・[PDF] NIST.IR.8374r1.ipd

目次...

1. Introduction	1. 序文
1.1 The Ransomware Challenge	1.1 ランサムウェアの課題
1.2 Basic Ransomware Tips	1.2 ランサムウェアの基本的なヒント
2. The Ransomware Community Profile	2. ランサムウェア・コミュニティ・プロファイル
Appendix A. Additional NIST Ransomware Resources	附属書 A. その他の NIST ランサムウェアリソース

ランサムウェアに関する基本的なヒント

BASIC RANSOMWARE TIPS	ランサムウェアに関する基本的なヒント
Even without undertaking all the measures described in this Ransomware Community Profile, there are some basic preventative steps that an organization can take now to protect against and recover from the ransomware threat. These include:	このランサムウェアコミュニティプロファイルに記載されているすべての対策を実施しなくても、ランサムウェアの脅威から保護し、回復するために組織が今すぐ実施できる基本的な予防策がいくつかある。以下がその例である：
1. Educate employees on avoiding ransomware infections.	1. ランサムウェアの感染を避けるために従業員を教育する。
• Don’t open files or click on links from unknown sources unless you first run an antivirus scan or look at links carefully.	- まずウイルス対策スキャンを実行したり、リンクを注意深く見たりしない限り、不明なソースからのファイルを開いたり、リンクをクリックしたりしないこと。
• Avoid using personal websites and personal apps – like email, chat, and social media – from work computers.	- 個人のウェブサイトや個人用アプリ（電子メール、チャット、ソーシャルメディアなど）を業務用コンピュータから使用しないようにする。
• Don’t connect personally owned devices to work networks without prior authorization.	- 事前の認可なしに、個人所有のデバイスを職場のネットワークに接続しない。
2. Avoid having vulnerabilities in systems that ransomware could exploit.	2. ランサムウェアに悪用されるような脆弱性をシステムに持たないようにする。
• Keep relevant systems fully patched. Run scheduled checks to identify available patches and install these as soon as feasible.	- 関連システムのパッチを完全に適用しておく。利用可能なパッチを特定するために定期的なチェックを行い、可能な限り早急にパッチをインストールする。
• Employ zero trust principles in all networked systems. Manage access to all network functions, and segment internal networks where practical to prevent malware from proliferating among potential target systems.	- すべてのネットワークシステムでゼロトラスト原則を採用する。すべてのネットワーク機能へのアクセスを管理し、潜在的な標的システム間でマルウェアが拡散するのを防ぐため、現実的な場合には内部ネットワークをセグメント化する。
• Allow installation and execution of authorized apps only. Configure operating systems and/or thirdparty software to run only authorized applications. This can also be supported by adopting a policy for reviewing, then adding or removing authorized applications on an allow list.	- 認可されたアプリケーションのインストールと実行のみを許可する。認可されたアプリケーションのみを実行するように、オペレーティング・システムやサードパーティ製ソフトウェアを設定する。これは、許可リストで許可されたアプリケーションをレビューし、追加または削除するポリシーを採用することでも対応できる。
• Inform your technology vendors of your expectations (e.g., in contract language) that they will apply measures that discourage ransomware attacks.	- テクノロジーベンダーに、ランサムウェア攻撃を阻止する対策を適用することを期待する旨を（契約文言などで）伝える。
3. Quickly detect and stop ransomware attacks and infections.	3. ランサムウェア攻撃や感染を迅速に検知し、阻止する。
• Use malware detection software, such as antivirus software at all times. Set it to automatically scan emails and flash drives.	- ウイルス対策ソフトなどのマルウェア検知ソフトを常時使用する。電子メールやフラッシュドライブを自動的にスキャンするように設定する。
• Continuously monitor directory services (and other primary user stores) for indicators of compromise or active attack.	- ディレクトリ・サービス（およびその他のプライマリ・ユーザー・ストア）を継続的に監視し、侵害や活発な攻撃の兆候がないか確認する。
• Block access to untrusted web resources. Use products or services that block access to server names, IP addresses, or ports and protocols that are known to be malicious or suspected to be indicators of malicious system activity. This includes using products and services that provide integrity protection for the domain component of addresses (e.g., hacker@poser.com).	- 信頼できないWebリソースへのアクセスをブロックする。悪意のあることが知られている、または悪意のあるシステム活動の指標であると疑われるサーバー名、IPアドレス、ポートおよびプロトコルへのアクセスをブロックする製品やサービスを使用する。これには、アドレスのドメイン・コンポーネントに完全性保護を提供する製品やサービス（例：hacker@poser.com）を使用することも含まれる。
4. Make it harder for ransomware to spread.	4. ランサムウェアが広がりにくくする。
• Use standard user accounts with multi-factor authentication versus accounts with administrative privileges whenever possible.	- 可能な限り、管理者権限を持つアカウントではなく、多要素認証を持つ標準ユーザーアカウントを使用する。
• Introduce authentication delays or configure automatic account lockout as a defense against automated attempts to guess passwords.	- パスワードを推測する自動的な試みに対する防御として、認証の遅延を導入するか、自動的なアカウントのロックアウトを設定する。
• Assign and manage credential authorization for all enterprise assets and software and periodically verify that each account has only the necessary access following the principle of least privilege.	- すべてのエンタープライズ資産とソフトウェアに対してクレデンシャルの認可を割り当てて管理し、最小特権の原則に従って、各アカウントが必要なアクセス権のみを持っていることを定期的に検証する。
• Store data in an immutable format (so that the database does not automatically overwrite older data when new data is made available).	- データを不変形式で保存する（新しいデータが利用可能になったときに、データベースが古いデータを自動的に上書きしないようにする）。
• Allow external access to internal network resources via secure virtual private network (VPN) connections only.	- 安全な仮想プライベートネットワーク（VPN）接続経由でのみ、内部ネットワークリソースへの外部アクセスを許可する。
5. Make it easier to recover stored information from a future ransomware event.	5. 将来ランサムウェアが発生した場合に、保存されている情報の復旧を容易にする。
• Make an incident recovery plan. Develop, implement, and regularly exercise an incident recovery plan with defined roles and strategies for decision making. This can be part of a continuity of operations plan. The plan should identify mission-critical and other business-essential services to enable recovery prioritization, and business continuity plans for those critical services.	- インシデント復旧計画を立てる。意思決定のための役割と戦略を明確にしたインシデント復旧計画を策定し、実施し、定期的に実施する。これは、事業継続計画の一部とすることができる。この計画では、復旧の優先順位付けを可能にするために、ミッションクリティカルなサービスやその他のビジネスに不可欠なサービスを特定し、それらの重要なサービスの事業継続計画を策定する。
• Back up data, secure backups, and test restoration. Carefully plan, implement, and test a data backup and restoration strategy—and secure and isolate backups of important data.	- データのバックアップ、バックアップのセキュリティ確保、リストアのテストを行う。データのバックアップとリストア戦略を慎重に計画、実施、テストし、重要なデータのバックアップを安全に隔離する。
• Keep your contacts. Maintain an up-to-date list of internal and external contacts for ransomware attacks, including law enforcement, legal counsel, and incident response resources.	- 連絡先を保持する。法執行機関、法律顧問、インシデント対応リソースなど、ランサムウェア攻撃に関する社内外の連絡先の最新リストを維持する。

---

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

CSF Ver2.0 コミュニティプロファイル関係

・2024.12.26 米国 NIST IR 8467 (第２次公開ドラフト) ゲノムデータのサイバーセキュリティとプライバシーフレームワーク コミュニティプロファイル (2024.12.16)

・2024.07.31 米国 NIST SP 800-218A 生成的AIとデュアルユース基盤モデルのための安全なソフトウェア開発プラクティス： SSDFコミュニティプロファイル

・2024.04.05 米国 意見募集 NIST SP 800-61 Rev.3（初期公開ドラフト） サイバーセキュリティリスクマネジメントのためのインシデント対応の推奨と考慮事項： CSF 2.0 コミュニティプロファイル

・2024.03.06 米国 NIST CSWP 32（初期公開ドラフト）サイバーセキュリティフレームワーク 2.0： コミュニティプロファイル作成ガイド (2024.02.26)

CSF Ver2.0 関係

・2024.04.26 NISTサイバーセキュリティフレームワークバージョン2への移行のポイントと日本語訳

・2024.02.28 米国 NIST CSWP 29 NISTサイバーセキュリティフレームワーク（CSF）2.0