付録：CSF 2.0
CSF2.0の管理策と実装例
【カテゴリ】組織の状況（GV.OC）:組織のサイバーセキュリティリスクマネジメントの意思決定を取り巻く状況（ミッション、利害関係者の期待、依存関係、法律、規制、契約上の要件）が理解されている。
サブカテゴリ GV.OC-01:組織のミッションが理解され、サイバーセキュリティリスク管理に反映されている。
実装例 例1:組織の使命を（ビジョンや行動指針、マーケティング、サービス戦略などを通じて）共有し、その使命を阻害する可能性のあるリスクを特定するための根拠を事前に提供する。
サブカテゴリ GV.OC-02:社内外の利害関係者が理解され、サイバーセキュリティリスク管理に関する彼らのニーズと期待が理解、考慮される。
実装例
例1:関連する社内の利害関係者と、彼らのサイバーセキュリティに関連する期待を特定する（例えば、役員、取締役、顧問に対する実績とリスクに関する予測、従業員に対する文化的な期待）。
例2:関連する社外の利害関係者と、彼らのサイバーセキュリティに関する期待を特定する（例えば、顧客のプライバシー、ビジネスパートナーの事業、規制当局のコンプライアンス、社会倫理などへの予測について）。
サブカテゴリ
GV.OC-03:サイバーセキュリティに関する法的、規制的、契約上の要件（プライバシーおよび市民的自由の義務を含む）が理解・管理される。
※市民的自由:思想・言論・行動の自由など、権利章典によって保証されている自由のこと。
実装例
例1:個人情報の保護について法的・規制要件を追跡・管理プロセスを決定する（医療保険の相互運用性と説明責任に関する法律、カリフォルニア州消費者プライバシー法、一般データ保護規則など）。
例2:サプライヤー、顧客、パートナーの情報についてサイバーセキュリティ管理に関する契約要件を追跡し管理するプロセスを決定する。
例3:組織のサイバーセキュリティ戦略を、法的・規制的・契約的要件と整合させる。
サブカテゴリ GV.OC-04:ステークホルダーが組織に依存または期待する重要な目的、能力、サービスを理解し、伝達する。
実装例
例1:社内外のステークホルダーから見た能力とサービスの重要性を判断する基準を確立する。
例2:ミッション目標の達成に不可欠な資産および事業活動と、そのような業務の損失（または部分的な損失）による潜在的な影響を判断する（例えば、ビジネスインパクト分析から）。
例3:さまざまな運用状態（例:攻撃時、回復時、通常運用時）において、重要な能力とサービスを提供するための回復目標（例:回復時間目標）を設定し、伝達する。
サブカテゴリ GV.OC-05:組織が依存する成果、能力、サービスが理解、伝達されている。
実装例
例1:組織の外部リソースへの依存度（例:施設、クラウドベースのホスティングプロバイダー）と、組織の資産およびビジネス機能との関係の目録を作成する。
例2:組織の重要な機能およびサービスにとって潜在的な障害となる外部依存関係を特定、文書化し、その情報を適切な要員と共有する。
【カテゴリ】リスクマネジメント戦略（GV.RM）:組織の優先事項、制約事項、リスクの許容と選好度、前提が設定・伝達され、オペレーショナルリスクの意思決定を支援するために使用される。
サブカテゴリ GV.RM-01:リスクマネジメントの目標が設定され、組織の利害関係者によって決定・合意される。
実装例
例1:年次戦略計画の一環として、また大きな変更が発生したときに、短期的および長期的なサイバーセキュリティリスク管理目標を更新する。
例2:サイバーセキュリティリスク管理のための測定可能な目標を設定する（例:ユーザートレーニングの質を管理する、産業用制御システムの適切なリスク保護を確保する）。
例3:シニアリーダーがサイバーセキュリティの目標に合意し、リスクとパフォーマンスの測定・管理に活用している。
サブカテゴリ GV.RM-02:リスク選好度およびリスク許容度が設定され、伝達され、維持されている。
実装例
例1:組織にとっての適切なリスクレベルについての期待を伝えるリスク選好度に関する声明を決定し、伝達する。
例2:リスク選好度を、具体的かつ測定可能で、広く理解可能なリスク許容度に変換する。
例3:既知と残存リスクに基づいて、組織目標とリスク選好度を定期的に見直す。
サブカテゴリ GV.RM-03:サイバーセキュリティリスクマネジメントの活動と成果が、企業のリスクマネジメントプロセスに含まれる。
実装例
例1:他の企業リスク（例:コンプライアンス、財務、業務、規制、風評、安全性）とともに、サイバーセキュリティリスクを集約し、管理する。
例2:企業のリスク管理計画にサイバーセキュリティリスクマネージャーを含める。
例3:企業のリスク管理におけるサイバーセキュリティリスクのエスカレーション基準を設定する。
サブカテゴリ GV.RM-04:適切なリスク対応の選択肢を示す戦略的方策を確立し、伝達する。
実装例
例1:さまざまな分類のデータについて、サイバーセキュリティ上のリスクについて受容および回避の基準を明示する。
例2:サイバーセキュリティ保険に加入するか否かの判断をする。
例3:責任共有モデルが許容される条件を文書化する（例:特定のサイバーセキュリティ機能のアウトソーシング、サードパーティが組織に代わって金融取引を実行する、パブリッククラウドベースのサービスを使用する）。
サブカテゴリ GV.RM-05:サプライヤーやそのほかの第三者からのリスクも含め、サイバーセキュリティリスクに関する組織横断的なコミュニケーションラインを確立する。
実装例
例1:上級管理職、取締役、および経営幹部が、組織のサイバーセキュリティ体制について、合意された間隔で更新する方法を決定する。
例2:経営陣、業務担当者、内部監査員、法務担当者、買収担当者、物理セキュリティ担当者、人事担当者など、組織全体にまたがるすべての部門が、サイバーセキュリティリスクについてどのように互いにコミュニケーションを図るかを明らかにする。
サブカテゴリ GV.RM-06:サイバーセキュリティリスクの算出、文書化、分類、優先順位付けのための標準化された方法を確立し、周知する。
実装例
例1:サイバーセキュリティリスク分析に定量的アプローチを使用するための基準を確立し、確率とエクスポージャーの公式を明示する。
例2:サイバーセキュリティリスク情報（リスクの説明、曝露、処置、所有者など）を文書化するためのテンプレート（リスク登録簿など）を作成し、使用する。
例3:企業内の適切なレベルでリスクの優先順位付けの基準を確立する。
例4:リスクカテゴリの一貫したリストを使用して、サイバーセキュリティリスクの統合、集約、比較をサポートする。
サブカテゴリ GV.RM-07:戦略的機会（すなわち、ポジティブリスク）が特徴づけられ、組織のサイバーセキュリティリスクの議論に含まれる。
実装例
例1:機会を特定し、リスクディスカッションに含めるための、ガイダンスと方法を定義・伝達する（例:強み、弱み、機会、脅威[SWOT]分析）。
例2:ストレッチゴールを特定し、文書化する。
※ストレッチゴール
ビジネスにおける部下育成のための目標設定手法である。現在のスキルや経験に加えて最大限の努力が必要な目標を設定することで、背伸びをした目標を設定することができる。
例3:ポジティブリスクとネガティブリスクを計算、文書化、優先順位付けする。
※ポジティブリスク
資産、知識、改善、またはデータの潜在的な利益を指す。
※ネガティブリスク
潜在的な損失を指す。
【カテゴリ】役割、責任、および権限（GV.RR）:サイバーセキュリティの役割、責任、および説明責任、パフォーマンス評価、および継続的な改善を促進するための権限が確立され、伝達される。
サブカテゴリ GV.RR-01:組織のリーダーシップは、サイバーセキュリティリスクに対する責任と説明責任を負い、リスクを認識し、倫理的で、継続的に改善する文化を醸成する。
実装例
例1:リーダー（取締役など）は、組織のサイバーセキュリティ戦略の策定、実施、評価における各自の役割と責任について合意する。
例2:特に、現在の出来事がサイバーセキュリティリスク管理の肯定的または否定的な例を強調する機会を提供する場合安全で倫理的な文化に関するリーダーの期待を共有する。
例3:リーダーはCISOに、包括的なサイバーセキュリティリスク戦略を維持し、少なくとも年に一度、および主要なイベント後にそれを見直して更新するように指示する。
例4:サイバーセキュリティリスクの管理責任者間で適切な権限と調整を確保するためのレビューを実施する。
サブカテゴリ GV.RR-02:サイバーセキュリティリスク管理に関連する役割、責任、および権限が確立され、伝達され、理解され、実施される。
実装例
例1:リスク管理の役割と責任をポリシーに文書化する。
例2:サイバーセキュリティリスク管理活動の責任者と説明責任、およびそれらのチームと個人にどのように相談し、通知するかを文書化する。
例3:サイバーセキュリティの責任とパフォーマンス要件を人事記述に含める。
例4:サイバーセキュリティリスク管理を担当する要員のパフォーマンス目標を文書化し、定期的にパフォーマンスを測定して改善点を特定する。
例5:業務、リスク機能、内部監査機能におけるサイバーセキュリティの責任を明確にする。
サブカテゴリ GV.RR-03:サイバーセキュリティリスク戦略、役割、責任、ポリシーに見合った適切なリソースを配分する。
実装例
例1:定期的なマネジメントレビューを実施し、サイバーセキュリティリスクマネジメントの責任者に必要な権限が与えられていることを確認する。
例2:リスク許容度と対応に沿ったリソース配分と投資を特定する。
例3:サイバーセキュリティ戦略を支援するために、適切かつ十分な人材、プロセス、技術的リソースを提供する。
サブカテゴリ GV.RR-04:サイバーセキュリティは人事慣行に含まれる。
実装例
例1:サイバーセキュリティリスク管理への配慮を人事プロセス（人事審査、入社手続き、変更通知、退社手続きなど）に組み込む。
例2:サイバーセキュリティの知識は、雇用、トレーニング、定着の決定においてプラス要因であると考える。
例3:機密性の高い役割の従業員をオンボーディングする前に身元調査を実施し、そのような役割の担当者の身元調査を定期的に繰り返す。
例4:各自の役割に関連するセキュリティポリシーを認識し、順守し、維持するための要員の義務を定義し、実施する。
【カテゴリ】ポリシー（GV.PO）:組織のサイバーセキュリティポリシーが確立され、伝達され、実施される。
サブカテゴリ GV.PO-01:サイバーセキュリティリスクの管理方針が、組織の状況、サイバーセキュリティ戦略、優先事項に基づいて策定され、周知され、実施される。
実装例
例1:経営陣の意図、期待、方向性を記述した、理解しやすく使いやすいリスク管理ポリシーを作成、普及、維持する。
例2:ポリシーとそれをサポートするプロセスと手順を定期的に見直して、リスク管理戦略の目標と優先事項、およびサイバーセキュリティポリシーの高レベルの方向性と一致していることを確認する。
例3:ポリシーについて上級管理職の承認を必要とする。
例4:サイバーセキュリティリスク管理ポリシーとそれをサポートするプロセスと手順を組織全体に伝達する。
例5:最初に採用されたとき、毎年、およびポリシーが更新されるたびに、ポリシーの受領を確認するように担当者に要求する。
サブカテゴリ GV.PO-02:サイバーセキュリティリスクの管理方針は、要件、脅威、技術、組織ミッションの変化を反映するよう、見直し、更新、伝達、実施される。
実装例
例1:サイバーセキュリティリスク管理の結果の定期的なレビューに基づいてポリシーを更新し、ポリシーとサポートプロセスと手順がリスクを許容可能なレベルで適切に維持するようにする。
例2:組織のリスク環境に対する変更（リスクや組織のミッション目標の変更など）をレビューするためのタイムラインを提供し、推奨されるポリシーの更新を伝える。
例3:法的要件および規制要件の変更を反映するようにポリシーを更新する。
例4:テクノロジーの変更（人工知能の採用など）とビジネスの変更（新しいビジネスの買収、新しい契約要件など）を反映するようにポリシーを更新する。
【カテゴリ】監視（GV.OV）:組織全体のサイバーセキュリティリスク管理活動と実績の結果が、リスク管理戦略の情報提供、改善、調整に利用される。
サブカテゴリ GV.OV-01:サイバーセキュリティリスク管理戦略の成果をレビューし、戦略と方向性に反映・調整する。
実装例
例1:リスク管理戦略とリスク結果が、リーダーが意思決定を行い、組織の目標を達成するのにどの程度役立ったかを測定する。
例2:運用やイノベーションを阻害するサイバーセキュリティリスク戦略を調整すべきか否かを検討する。
サブカテゴリ GV.OV-02:組織の要求事項とリスクを確実にカバーするために、サイバーセキュリティリスク管理戦略がレビューされ、調整される。
実装例
例1:監査結果を見直して、既存のサイバーサイバーセキュリティ戦略が内部および外部の要件への準拠を確保しているか否かを確認する。
例2:サイバーセキュリティ関連の役割を担う人々のパフォーマンス監視を見直して、ポリシーの変更が必要か否かを判断する。
例3:サイバーセキュリティインシデントを踏まえた戦略の見直し。
サブカテゴリ GV.OV-03:組織のサイバーセキュリティリスク管理のパフォーマンスが評価され、必要な調整のために再確認される。
実装例
例1:重要業績評価指標（KPI）を組織全体のポリシーと手順が目標の達成を保証するために再確認する。
例2:重要リスク指標（KRI）を見直して、組織が直面するリスク（可能性と潜在的な影響を含む）を特定する。
例3:上級管理職にサイバーセキュリティリスク管理に関する指標を収集し、伝達する。
サブカテゴリ GV.SC-01:サイバーセキュリティのサプライチェーンリスク管理プログラム、戦略、目的、方針、およびプロセスが確立され、組織の利害関係者によって合意されている。
実装例
例1:サイバーセキュリティサプライチェーンリスク管理プログラムの目的を表現する戦略を確立する。
例2:プログラムの実施と改善に導く計画（マイルストーンを含む）、ポリシー、手順を含むサイバーセキュリティサプライチェーンリスク管理プログラムを開発し、ポリシーと手順を組織の利害関係者と共有する。
例3:組織の利害関係者が合意し、実行する戦略、目的、ポリシー、および手順に基づいて、プログラムプロセスを開発および実装する。
例4:サイバーセキュリティ、IT、運用、法務、人事、エンジニアリングなど、サイバーセキュリティサプライチェーンのリスク管理に貢献する機能間の整合性を確保するための組織横断的なメカニズムを確立する。
サブカテゴリ GV.SC-02:サプライヤー、顧客、パートナーに対するサイバーセキュリティの役割と責任が確立され、伝達され、社内外で調整される。
実装例
例1:サイバーセキュリティサプライチェーンのリスク管理活動の計画、リソース、および実行に責任を持ち、説明責任を負う1つ以上の特定の役割またはポジションを特定する。
例2:サイバーセキュリティサプライチェーンのリスク管理の役割と責任をポリシーに文書化する。
例3:サイバーセキュリティサプライチェーンのリスク管理活動の全体の責任と説明責任を誰が負うか、そしてそれらのチームと個人にどのように相談し、通知するかを文書化するための責任マトリックスを作成する。
例4:サイバーセキュリティサプライチェーンのリスク管理の責任とパフォーマンス要件を人事記述に含めて、明確にし、また説明責任を向上させる。
例5:サイバーセキュリティリスク管理固有の責任を持つ担当者のパフォーマンス目標を文書化し、定期的に測定してパフォーマンスを実証および改善する。
例6:サプライヤー、顧客、ビジネスパートナーが、該当するサイバーセキュリティリスクに対する共通の責任に対処するための役割と責任を開発し、それらを組織のポリシーと該当するサードパーティ契約に統合する。
例7:サイバーセキュリティサプライチェーンのリスク管理の役割と第三者に対する責任を社内で伝達する。
例8:組織とそのサプライヤー間の情報共有および報告プロセスに関するルールとプロトコルを確立する。
サブカテゴリ GV.SC-03:サイバーセキュリティのサプライチェーンリスクマネジメントは、サイバーセキュリティおよび企業のリスクマネジメント、リスク評価、改善プロセスに統合する。
実装例
例1:サイバーセキュリティとエンタープライズリスク管理との整合性と重複する領域を特定する。
例2:サイバーセキュリティリスク管理とサイバーセキュリティサプライチェーンリスク管理のための統合制御セットを確立する。
例3:サイバーセキュリティサプライチェーンのリスク管理を改善プロセスに統合する。
例4:サプライチェーンにおける重大なサイバーセキュリティリスクを上級管理職にエスカレーションし、企業リスク管理レベルで対処する。
サブカテゴリ GV.SC-04:サプライヤーを把握し、重要度に応じて優先順位を付ける
実装例
例1:サプライヤーによって処理または所有されるデータの機密性、組織のシステムへのアクセスの程度、組織のミッションに対する製品またはサービスの重要性などに基づいて、サプライヤーの重要度の基準を作成する。
例2:すべてのサプライヤーの記録を保持し、重要度基準に基づいてサプライヤーに優先順位を付ける。
サブカテゴリ GV.SC-05:サプライチェーンにおけるサイバーセキュリティリスクに対処するための要件は設定され、順位付けられ、サプライヤーやそのほかの関連する第三者との契約やそのほかの合意に組み込まれる。
実装例
例1:サプライヤー、製品、サービスの重要度レベルと、侵害された場合の潜在的な影響に見合ったセキュリティ要件を確立する。
例2:第三者が従うべきすべてのサイバーセキュリティおよびサプライチェーン要件と、デフォルトの契約言語で要件の順守を確認する方法を含める。
例3:組織とそのサプライヤーおよび契約上のサブ・ティアサプライヤー間の情報共有に関するルールとプロトコルを定義する。
例4:セキュリティ要件の重要性と侵害された場合の潜在的な影響に基づいて、セキュリティ要件を契約に含めることでリスクを管理する。
例5:サプライヤー関係のライフサイクルを通じて許容可能なセキュリティパフォーマンスについてサプライヤーを監視するためのサービスレベルアグリーメント（SLA）でセキュリティ要件を定義する。
例6:契約上、サプライヤーに対して、製品の寿命またはサービスの期間中、自社の製品およびサービスのサイバーセキュリティの特徴、機能、および脆弱性を開示するよう要求する。
例7:重要な製品の最新のコンポーネント在庫（ソフトウェアまたはハードウェアの部品表など）を提供し、維持することをサプライヤーに契約上要求する。
例8:契約上、サプライヤーに従業員を審査し、インサイダー脅威から保護することを要求する。
例9:契約上、サプライヤーに対して、自己証明、既知の標準への準拠、認証、検査などを通じて、許容可能なセキュリティ慣行を実施している証拠を提供するよう要求する。
例10:契約およびその他の合意において、潜在的なサイバーセキュリティリスクに関して、組織、そのサプライヤー、およびそれらのサプライチェーンの権利と責任を明記する。
サブカテゴリ
GV.SC-06:正式なサプライヤーやそのほかの第三者との関係を結ぶ前に、リスクを低減するための計画やデューデリジェンスが実施されている。
※デューデリジェンス企業などに要求される当然に実施すべき注意義務および努力のこと。
実装例
例1:調達計画と整合し、各サプライヤーとの関係のリスク、重要性、複雑さのレベルに見合った、見込みサプライヤーに対する徹底的なデューデリジェンスを実施する。
例2:テクノロジーとサイバーセキュリティ機能の適合性、および将来のサプライヤーのリスク管理慣行を評価する。
例3:ビジネスおよび適用されるサイバーセキュリティ要件に対するサプライヤーリスク評価を実施する。
例4:重要な製品を購入して使用する前に、信頼性、完全性、セキュリティを評価する。
サブカテゴリ
GV.SC-07:サプライヤー、その製品・サービス、そのほかの第三者によってもたらされるリスクを理解し、記録し、優先順位を付け、評価し、対応し、関係を通じて監視する。
実装例
例1:評価の形式と頻度を、第三者の評判と提供する製品またはサービスの重要性に基づいて調整する。
例2:自己証明、保証、認証、そのほかの成果物など、契約上のサイバーセキュリティ要件に準拠しているという第三者の証拠を評価する。
例3:重要なサプライヤーを監視し、検査、監査、テスト、そのほかの形式の評価など、さまざまな方法と手法を使用して、サプライヤー関係のライフサイクル全体を通じてセキュリティ義務を果たしていることを確認する。
例4:重要なサプライヤー、サービス、製品のリスクプロファイルの変化を監視し、それに応じてサプライヤーの重要度とリスクの影響を再評価する。
例5:ビジネスの継続性を確保するために、予期しないサプライヤーとサプライチェーン関連の中断を計画する。
サブカテゴリ
GV.SC-08:インシデント発生時の計画、対応、復旧活動に、関連するサプライヤーやそのほかの第三者が含まれる。
実装例
例1:インシデント対応と復旧活動、および組織とそのサプライヤー間のステータスを報告するためのルールとプロトコルを定義して使用する。
例2:インシデント対応に関する組織とそのサプライヤーの役割と責任を特定し、文書化する。
例3:インシデント対応の演習とシミュレーションに重要なサプライヤーを含める。
例4:組織とその重要なサプライヤーとの間の危機管理コミュニケーションの方法とプロトコルを定義し、調整する。
例5:重要なサプライヤーと共同で教訓セッションを実施する。
サブカテゴリ
GV.SC-09:サプライチェーンセキュリティの実践が、サイバーセキュリティと企業のリスク管理プログラムに統合され、そのパフォーマンスが技術製品とサービスのライフサイクル全体を通じて監視される。
実装例
例1:ポリシーと手順により、取得したすべてのテクノロジー製品およびサービスの来歴記録を必要とする。
例2:買収したコンポーネントが改ざんされていないため、本物であることが証明された方法について、リーダーに定期的にリスクレポートを提供する。
例3:サイバーセキュリティのリスクマネージャーと運用担当者の間で、認証された信頼できるソフトウェアプロバイダーからのみソフトウェアのパッチ、アップデート、アップグレードを取得する必要があることについて定期的に連絡を取る。
例4:ポリシーを見直して、承認されたサプライヤー担当者がサプライヤー製品のメンテナンスを行うことを要求していることを確認する。
例5:ポリシーと手順では、重要なハードウェアのアップグレードに不正な変更がないか確認する必要がある。
サブカテゴリ
GV.SC-10:サイバーセキュリティのサプライチェーンリスクマネジメント計画には、パートナーシップまたはサービス契約締結後に発生する活動に関する規定が含まれる。
実装例
例1:正常な状況と不利な状況の両方で重要な関係を終了するためのプロセスを確立する。
例2:コンポーネントの寿命終了時の保守サポートと陳腐化の計画を定義して実装する。
例3:組織のリソースへのサプライヤーのアクセスが不要になったときに、すぐに非アクティブ化していることを確認する。
例4:組織のデータを含む資産が、タイムリーに、管理された、安全な方法で返却または適切に廃棄されていることを確認する。
例5:サプライヤーとの関係を終了または移行するための計画を策定し、実行し、サプライチェーンのセキュリティリスクとレジリエンスを考慮に入れる。
例6:サプライヤーの終了によって生じるデータとシステムへのリスクを軽減する。
例7:サプライヤーの契約に関連するデータ漏えいリスクを管理する。
【カテゴリ】資産管理（ID.AM）:組織がビジネス目的を達成できるようにする資産（データ、ハードウェア、ソフトウェア、システム、施設、サービス、人など）は、組織の目標と組織のリスク戦略に対する相対的な重要性と一致して特定および管理される。
サブカテゴリ ID.AM-01:組織が管理するハードウェアのインベントリを保持する。
実装例
例1:IT、IoT、OT、モバイルデバイスなど、あらゆる種類のハードウェアの在庫を維持する。
例2:ネットワークを常に監視して新しいハードウェアを検出し、インベントリを自動的に更新する。
サブカテゴリ ID.AM-02:組織が管理するソフトウェア、サービス、システムのインベントリを管理する。
実装例
例1:商用オフザシェルフ、オープンソース、カスタムアプリケーション、APIサービス、クラウドベースのアプリケーションとサービスなど、あらゆる種類のソフトウェアとサービスのインベントリを維持する。
例2:コンテナや仮想マシンを含むすべてのプラットフォームを常時監視し、ソフトウェアとサービスのインベントリの変更を確認する。
例3:組織のシステムのインベントリを維持する。
サブカテゴリ ID.AM-03:組織の許可されたネットワーク通信と内部および外部のネットワークデータフローの表現が維持される。
実装例
例1:組織の有線および無線ネットワーク内の通信とデータフローのベースラインを維持する。
例2:組織とサードパーティ間のコミュニケーションとデータフローのベースラインを維持する。
例3:組織のIaaS（Infrastructure-as-a-Service）の使用に関する通信とデータフローのベースラインを維持する。
例4:許可されたシステム間で通常使用される予想されるネットワークポート、プロトコル、およびサービスのドキュメントを維持する。
サブカテゴリ ID.AM-04:サプライヤーが提供するサービスの在庫を管理する。
実装例
例1:APIのおよびそのほかの外部でホストされているアプリケーションサービス、サードパーティのInfrastructure-as-a-Service（IaaS）、Platform-as-a-Service（PaaS）、Software-as-a-Service（SaaS）オファリングなど、組織が使用するすべての外部サービスのインベントリを作成する。
例2:新しい外部サービスを利用する場合はインベントリを更新して、組織によるそのサービスの使用の適切なサイバーセキュリティリスク管理監視を確保する。
サブカテゴリ ID.AM-05:資産は、分類、重要度、リソース、ミッションへの影響に基づいて優先順位が付けられる。
実装例
例1:各クラスの資産の優先順位付けの基準を定義する。
例2:資産に優先順位付け基準を適用する。
例3:資産の優先順位を追跡し、定期的に更新するか、組織に大幅な変更が発生したときに更新する。
サブカテゴリ ID.AM-06:[撤回:GV.RR-02、GV.SC-02に編入する。]
実装例
サブカテゴリ ID.AM-07:指定されたデータ型のデータと対応するメタデータのインベントリが維持される。
実装例
例1:指定された関心のあるデータタイプ（個人を特定できる情報、保護医療情報、金融口座番号、組織の知的財産、運用技術データなど）のリストを維持する。
例2:アドホックデータを継続的に検出および分析して、指定されたデータタイプの新しいインスタンスを特定する。
例3:タグまたはラベルを使用して、指定したデータ型にデータ分類を割り当てる。
例4:指定されたデータタイプの各インスタンスの出所、データ所有者、およびジオロケーションを追跡する。
サブカテゴリ ID.AM-08: システム、ハードウェア、ソフトウェア、サービス、データは、そのライフサイクル全体を通じて管理される。
実装例
例1:システム、ハードウェア、ソフトウェア、サービスのライフサイクル全体を通じてサイバーセキュリティの考慮事項を統合する。
例2:サイバーセキュリティに関する考慮事項を製品ライフサイクルに統合する。
例3:ミッション目標を達成するためのテクノロジーの非公式な使用（例:「シャドーIT」）を特定する。
例4:組織の攻撃対象領域を不必要に拡大する冗長なシステム、ハードウェア、ソフトウェア、サービスを定期的に特定する。
例5:システム、ハードウェア、ソフトウェア、サービスを本番環境に導入する前に、適切に構成し、保護する。
例6:システム、ハードウェア、ソフトウェア、およびサービスが組織内で移動または転送されたときにインベントリを更新する。
例7:組織のデータ保持ポリシーに基づき、保存されているデータを所定の破棄方法により安全に破棄し、破棄の記録を保持・管理する。
例8:ハードウェアが廃止、廃止、再割り当て、または修理や交換のために送られるときに、データストレージを安全に削除する。
例9:紙、記憶媒体、そのほかの物理的なデータストレージを破壊する方法を提供する。
【カテゴリ】リスク評価（ID.RA）:組織、資産、および個人に対するサイバーセキュリティリスクは、組織によって理解される。
サブカテゴリ ID.RA-01:資産の脆弱性を特定、検証、記録する。
実装例
例1:脆弱性管理テクノロジーを使用して、パッチが適用されていないソフトウェアや誤って構成されたソフトウェアを特定する。
例2:ネットワークとシステムアーキテクチャを評価し、サイバーセキュリティに影響を与える設計と実装の弱点を検出する。
例3:組織が開発したソフトウェアをレビュー、分析、またはテストして、設計、コーディング、およびデフォルト設定の脆弱性を特定する。
例4:重要なコンピューティング資産を収容する施設の物理的な脆弱性とレジリエンスの問題を評価する。
例5:サイバー脅威インテリジェンスのソースを監視して、製品やサービスの新たな脆弱性に関する情報を入手する。
例6:サイバーセキュリティに影響を与えるために悪用される可能性のある弱点について、プロセスと手順を確認する。
サブカテゴリ ID.RA-02:情報共有フォーラムや情報源からサイバー脅威インテリジェンスを受け取る。
実装例
例1:サイバーセキュリティツールとテクノロジーを検出または対応機能で構成し、サイバー脅威インテリジェンスフィードを安全に取り込む。
例2:現在の脅威アクターとその戦術、技術、手順（TTP）に関するアドバイザリを、信頼できる第三者から受け取り、レビューする。
例3:サイバー脅威インテリジェンスのソースを監視して、新興技術が持つ可能性のある脆弱性の種類に関する情報を入手する。
サブカテゴリ ID.RA-03:組織に対する内部および外部の脅威を特定し、記録する。
実装例
例1:サイバー脅威インテリジェンスを使用して、組織を標的にする可能性が高い脅威アクターの種類と、彼らが使用する可能性が高いTTPの認識を維持する。
例2:脅威ハンティングを実行して、環境内の脅威アクターの兆候を探す。
例3:内部の脅威アクターを特定するためのプロセスを実装する。
サブカテゴリ ID.RA-04:脆弱性を悪用する脅威の潜在的な影響と可能性を特定し、記録する。
実装例
例1:ビジネスリーダーとサイバーセキュリティリスクマネジメントの実務者が協力して、リスクシナリオの可能性と影響を見積り、リスク登録簿に記録する。
例2:組織の通信、システム、およびこれらのシステムで処理される、あるいはこれらのシステムによって処理されるデータへの不正アクセスが、ビジネスに及ぼしうる影響を列挙する。
例3:システムのシステムに対する連鎖的な障害の潜在的な影響を考慮する。
サブカテゴリ ID.RA-05:脅威、脆弱性、可能性、影響は、固有のリスクを理解し、リスク対応の優先順位付けを通知するために使用される。
実装例
例1:脅威モデルを開発して、データに対するリスクをよりよく理解し、適切なリスク対応を特定する。
例2:推定される可能性と影響に基づいて、サイバーセキュリティリソースの割り当てと投資に優先順位を付ける。
サブカテゴリ ID.RA-06:リスク対応は選択、優先順位付け、計画、追跡、および伝達される。
実装例
例1:リスクを受け入れるか、移転するか、軽減するか、回避するかを決定するための脆弱性管理計画の基準を適用する。
例2:リスクを軽減するための補償制御を選択するための脆弱性管理計画の基準を適用する。
例3:リスク対応の実施の進捗状況を追跡する（行動計画とマイルストーン[POA&M]、リスク登録、リスク詳細レポートなど）。
例4:リスク評価の結果を使用して、リスク対応の決定とアクションを通知する。
例5:影響を受けるステークホルダーに、優先順位を付けて計画されたリスク対応を伝える。
サブカテゴリ ID.RA-07:変更と例外は管理され、リスクの影響について評価され、記録され、追跡される。
実装例
例1:提案された変更と要求された例外の正式な文書化、レビュー、テスト、および承認のための手順を実装し、それに従う。
例2:提案された各変更を行うか、または行わない場合に発生する可能性のあるリスクを文書化し、変更のロールバックに関するガイダンスを提供する。
例3:リクエストされた各例外に関連するリスクと、それらのリスクに対応するための計画を文書化する。
例4:計画された将来のアクションまたはマイルストーンに基づいて受け入れられたリスクを定期的に見直す。
サブカテゴリ ID.RA-08:脆弱性の開示を受領、分析、対応するためのプロセスを確立している。
実装例
例1:契約で定義されたルールとプロトコルに従って、組織とそのサプライヤー間で脆弱性情報の共有を行う。
例2:サプライヤー、顧客、パートナー、政府のサイバーセキュリティ組織によるサイバーセキュリティの脅威、脆弱性、またはインシデントの開示の処理、影響の分析、および対応のための責任を割り当て、手順の実行を確認する。
サブカテゴリ ID.RA-09:ハードウェアとソフトウェアの真正性と完全性は、取得および使用前に評価される。
実装例 例1:重要なテクノロジー製品およびサービスを取得して使用する前に、信頼性とサイバーセキュリティを評価する。
サブカテゴリ ID.RA-10:重要なサプライヤーは買収前に評価される。
実装例 例1:サプライチェーンを含む、ビジネスおよび適用されるサイバーセキュリティ要件に対してサプライヤーリスク評価を実施する。
【カテゴリ】改善（ID.IM）:組織のサイバーセキュリティリスク管理プロセス、手順、および活動の改善は、すべてのCSF機能で特定される。
サブカテゴリ ID.IM-01:評価から改善点を抽出する。
実装例
例1:現在の脅威とTTPを考慮した重要なサービスの自己評価を実行する。
例2:組織のサイバーセキュリティプログラムの有効性に関する第三者評価または独立した監査に投資して、改善が必要な領域を特定する。
例3:自動化された手段を通じて、選択したサイバーセキュリティ要件への準拠を常に評価する。
サブカテゴリ ID.IM-02:サプライヤーや関連する第三者との連携によるものを含め、セキュリティテストや演習から改善点が特定される。
実装例
例1:インシデント対応評価の結果に基づいて、将来のインシデント対応活動の改善点を特定する（例:机上演習とシミュレーション、テスト、内部レビュー、独立監査）。
例2:重要なサービスプロバイダーや製品サプライヤーと連携して実施された演習に基づいて、将来のビジネス継続性、災害復旧、インシデント対応活動の改善点を特定する。
例3:必要に応じて、社内の利害関係者（上級管理職、法務部門、人事部など）をセキュリティテストと演習に参加させる。
例4:ペネトレーションテストを実施して、リーダーシップによって承認された、選択した高リスクシステムのセキュリティ体制を改善する機会を特定する。
例5:製品またはサービスが契約したサプライヤーまたはパートナーから発信されたものではない、または受領前に変更されたという発見に対応し、回復するための緊急時対応計画を行使する。
例6:セキュリティツールとサービスを使用してパフォーマンスメトリックを収集および分析し、サイバーセキュリティプログラムの改善を通知する
サブカテゴリ ID.IM-03:業務プロセス、手順、活動の実行から改善を特定する。
実装例
例1:サプライヤーとの共同教訓セッションを実施する。
例2:サイバーセキュリティのポリシー、プロセス、手順を毎年見直し、学んだ教訓を考慮に入れる。
例3:メトリクスを使用して、運用上のサイバーセキュリティパフォーマンスを経時的に評価する。
サブカテゴリ ID.IM-04:業務に影響を及ぼすインシデント対応計画およびそのほかのサイバーセキュリティ計画が策定され、伝達され、維持され、改善される。
実装例
例1:運用に支障をきたす、機密情報を漏えいさせる、または組織の使命と実行可能性を危険にさらす可能性のある有害事象への対応と回復のための緊急時対応計画（インシデント対応、事業継続性、災害復旧など）を確立する。
例2:連絡先とコミュニケーションの情報、一般的なシナリオを処理するためのプロセス、優先順位付け、エスカレーション、昇格の基準をすべてのコンティンジェンシープランに含める。
例3:脆弱性管理計画を作成して、あらゆる種類の脆弱性を特定および評価し、リスク対応に優先順位を付け、テストし、実装する。
例4:サイバーセキュリティ計画（更新を含む）を、その実施責任者および影響を受ける当事者に伝達する。
例5:すべてのサイバーセキュリティ計画を毎年、または大幅な改善の必要性が特定された場合に、見直して更新する。
【カテゴリ】ビジネス環境（ID.BE）:撤回:GV.OCに編入する。
サブカテゴリ ID.BE-01:[撤回:GV.OC-05に編入する。]
実装例
サブカテゴリ ID.BE-02:[撤回: GV.OC-01に編入する。]
実装例
サブカテゴリ ID.BE-03:[撤回: GV.OC-01に編入する。]
実装例
サブカテゴリ ID.BE-04:[撤回: GV.OC-04、GV.OC-05に編入する。]
実装例
サブカテゴリ ID.BE-05:[撤回: GV.OC-04に編入する。]
実装例
【カテゴリ】ガバナンス（ID.GV）:撤回:GVに編入する。
サブカテゴリ ID.GV-01:[撤回:GV.PO、GV.PO-01、GV.PO-02に編入する。]
実装例
サブカテゴリ ID.GV-02:[撤回:GV.OC-02、GV.RR、GV.RR-02に編入する。]
実装例
サブカテゴリ ID.GV-03:[撤回:GV.OC-03に移動する。]
実装例
サブカテゴリ ID.GV-04:[撤回:GV.RM-04に移動する。]
実装例
【カテゴリ】リスクマネジメント戦略（ID.RM）:撤回:GV.RMに編入する。
サブカテゴリ ID.RM-01:[撤回:GV.RM-01、GV.RM-06、GV.RR-03に編入する。]
実装例
サブカテゴリ ID.RM-02:[撤回:GV.RM-02、GV.RM-04に編入する。]
実装例
サブカテゴリ ID.RM-03:[撤回: GV.RM-02に移動する。]
実装例
【カテゴリ】サプライチェーンリスク管理（ID.SC）:撤回:ＧＶ.SCに編入する
サブカテゴリ ID.SC-01:[撤回:RM-05、GV.SC-01、GV.SC-06、GV.SC-09、GV.SC-10に編入する。]
実装例
サブカテゴリ ID.SC-02:[撤回: GV.OC-02、GV.SC-03、GV.SC-04、GV.SC-07、ID.RA-10に編入する。]
実装例
サブカテゴリ ID.SC-03:[撤回:GV.SC-05に移動する。]
実装例
サブカテゴリ ID.SC-04:[撤回:GV.SC-07、ID.IM-02に編入する。]
実装例
サブカテゴリ ID.SC-05:[撤回:GV.SC-08、ID.IM-02に編入する。]
実装例
【カテゴリ】ID管理、認証、およびアクセス制御（PR.AA）:物理的および論理的な資産へのアクセスは、許可されたユーザー、サービス、およびハードウェアに限定され、不正アクセスの評価されたリスクに見合った方法で管理される。
サブカテゴリ PR.AA-01:許可されたユーザー、サービス、およびハードウェアのIDとクレデンシャルが組織によって管理される。
実装例
例1:従業員、請負業者、そのほかの新しいアクセスまたは追加のアクセスの要求を開始し、必要に応じてシステムまたはデータ所有者の許可を得て、要求を追跡、レビュー、および実行する。
例2:暗号化証明書とIDトークン、暗号化キー（つまり、キー管理）、およびそのほかの資格情報を発行、管理、および取り消す。
例3:不変のハードウェア特性から各デバイスの一意の識別子を選択するか、デバイスに安全にプロビジョニングされた識別子を選択する。
例4:インベントリとサービスの目的で、承認されたハードウェアに識別子を物理的にラベル付けする。
サブカテゴリ PR.AA-02:アイデンティティは、相互作用のコンテキストに基づいて証明され、クレデンシャルにバインドされる。
実装例
例1:登録時に政府発行のID資格情報（パスポート、ビザ、運転免許証など）を使用して、個人の主張するIDを確認する。
例2:各人に異なる資格情報を発行する（つまり、資格情報を共有しない）。
サブカテゴリ PR.AA-03:ユーザー、サービス、ハードウェアを認証する。
実装例
例1:多要素認証を要求する。
例2:パスワード、PIN、および同様の認証子の最小強度に関するポリシーを適用する。
例3:リスクに基づいてユーザー、サービス、ハードウェアを定期的に再認証する（ゼロトラストアーキテクチャなど）。
例4:緊急時下においてセキュリティ確保に必要不可欠なアカウントにアクセス可能な担当者を確保する。
サブカテゴリ PR.AA-04:アイデンティティ・アサーションは保護、伝達、検証される。
実装例
例1:シングルサインオンシステムを通じて認証とユーザー情報の伝達に使用されるIDアサーションを保護する。
例2:連携システム間で認証とユーザー情報の伝達に使用されるアイデンティティ・アサーションの保護。
例3:権限のある担当者が、緊急時の安全を守るために不可欠なアカウントにアクセスできるようにすること。
サブカテゴリ PR.AA-05:アクセス許可、資格、および権限がポリシーで定義され、管理され、実施され、レビューされ、最小特権と職務分離の原則が組み込まれている。
実装例
例1:論理的および物理的なアクセス権限を定期的に、および誰かがロールを変更したり組織を離れたりするたびに確認し、不要になった権限を速やかに取り消す。
例2:リクエスターとリクエストされたリソースの属性を認証決定に考慮する（ジオロケーション、曜日/時間、リクエスターエンドポイントのサイバーヘルスなど）。
例3:アクセスと権限を必要最小限に制限する（例:ゼロトラストアーキテクチャ）。
例4:重要なビジネス機能に関連する権限を定期的に見直して、職務の適切な分離を確認する。
サブカテゴリ PR.AA-06:資産への物理的なアクセスは、リスクに見合った形で管理、監視、実施される。
実装例
例1:警備員、防犯カメラ、施錠された入り口、警報システム、およびそのほかの物理的制御を使用して、施設を監視し、アクセスを制限する。
例2:リスクの高い資産を含むエリアに対して、追加の物理的セキュリティ制御を採用する。
例3:ビジネスに不可欠な資産を含むエリア内で、ゲスト、ベンダー、そのほかの第三者をエスコートする。
【カテゴリ】意識向上とトレーニング（PR.AT）:組織の要員は、サイバーセキュリティに関する意識向上とトレーニングを受け、サイバーセキュリティ関連の業務を遂行できるようになる。
サブカテゴリ PR.AT-01:要員は、サイバーセキュリティリスクを念頭において一般的な業務を遂行するための知識と技能を有するよう、意識向上とトレーニングを受ける。
実装例
例1:従業員、請負業者、パートナー、サプライヤー、および組織の非公開リソースのそのほかすべてのユーザーに、基本的なサイバーセキュリティの認識とトレーニングを提供する。
例2:ソーシャルエンジニアリングの試みやそのほかの一般的な攻撃を認識し、攻撃や疑わしい活動を報告し、利用規定を順守し、基本的なサイバーハイジーンタスク（ソフトウェアのパッチ適用、パスワードの選択、資格情報の保護など）を実行するように、従業員を訓練する。
例3:サイバーセキュリティポリシー違反の結果について、個々のユーザーと組織全体の両方に説明する。
例4:基本的なサイバーセキュリティの実践に関するユーザーの理解度を定期的に評価またはテストする。
例5:既存のプラクティスを強化し、新しいプラクティスを導入するために、毎年のリフレッシャーを義務付ける。
サブカテゴリ PR.AT-02:専門的な役割を担う個人が、サイバーセキュリティリスクを念頭に置いて関連業務を遂行するための知識と技能を有するよう、意識向上とトレーニングを提供する。
実装例
例1:物理的なセキュリティおよびサイバーセキュリティの担当者、財務担当者、上級管理職、ビジネスクリティカルなデータにアクセスできる人など、追加のサイバーセキュリティトレーニングが必要な組織内の専門的な役割を特定する。
例2:請負業者、パートナー、サプライヤー、そのほかの第三者を含む、専門的な役割を担うすべての人々に、役割ベースのサイバーセキュリティの認識とトレーニングを提供する。
例3:ユーザーがそれぞれの専門的な役割におけるサイバーセキュリティの実践を理解しているか否か、定期的に評価またはテストする。
例4:既存のプラクティスを強化し、新しいプラクティスを導入するために、毎年のリフレッシャーを必須にする。
サブカテゴリ PR.AT-03:[撤回:PR.AT-01、PR.AT-02に編入する。]
実装例
サブカテゴリ PR.AT-04:[撤回:PR.AT-02に編入する。]
実装例
サブカテゴリ PR.AT-05:[撤回:PR.AT-02に編入する。]
実装例
サブカテゴリ PR.DS-01:静止データの機密性、完全性、可用性を保護する。
実装例
例1:暗号化、デジタル署名、暗号化ハッシュを使用して、ファイル、データベース、仮想マシンディスクイメージ、コンテナイメージ、およびそのほかのリソースに格納されたデータの機密性と整合性を保護する。
例2:フルディスク暗号化を使用して、ユーザーエンドポイントに保存されているデータを保護する。
例3:署名の検証によるソフトウェアの整合性を確認する。
例4:リムーバブルメディアの使用を制限してデータ流出を防ぐ。
例5:暗号化されていない機密情報を含む物理的に安全なリムーバブルメディア（施錠されたオフィスやファイルキャビネット内など）。
サブカテゴリ PR.DS-02:転送中のデータの機密性、完全性、および可用性を保護する。
実装例
例1:暗号化、デジタル署名、および暗号化ハッシュを使用して、ネットワーク通信の機密性と整合性を保護する。
例2:データの分類に応じて、機密データを含む送信メールやそのほかの通信を自動的に暗号化またはブロックする。
例3:組織のシステムやネットワークから、個人の電子メール、ファイル共有、ファイルストレージサービス、そのほかの個人のコミュニケーションアプリケーションやサービスへのアクセスをブロックする。
例4:本番環境の機密データ（顧客レコードなど）が開発、テスト、そのほかの非本番環境で再利用されるのを防ぐ。
サブカテゴリ PR.DS-03:[撤回:ID.AM-08、PR.PS-03に編入する。]
実装例
サブカテゴリ PR.DS-04:[撤回:PR.IR-04に移動する。]
実装例
サブカテゴリ PR.DS-05:[撤回:PR.DS-01、PR.DS-02、PR.DS-10に編入する。]
実装例
サブカテゴリ PR.DS-06:[撤回:PR.DS-01、DE.CM-09に編入する。]
実装例
サブカテゴリ PR.DS-07:[撤回:PR.IR-01に編入する。]
実装例
サブカテゴリ PR.DS-08:[撤回:ID.RA-09、DE.CM-09に編入する。]
実装例
サブカテゴリ PR.DS-10:使用中のデータの機密性、完全性、および可用性が保護されている。
実装例
例1:機密を保持する必要があるデータ（プロセッサやメモリなど）が不要になったらすぐに削除する。
例2:同じプラットフォームの他のユーザーやプロセスによるアクセスから使用中のデータを保護する。
サブカテゴリ PR.DS-11:データのバックアップが作成、保護、維持、およびテストされる。
実装例
例1:重要なデータをほぼリアルタイムで継続的にバックアップし、他のデータは合意されたスケジュールで頻繁にバックアップする。
例2:すべての種類のデータソースのバックアップと復元を少なくとも年に1回テストする。
例3:一部のバックアップをオフラインおよびオフサイトに安全に保管して、インシデントや災害によって損傷を受けないようにする。
例4:データバックアップストレージの地理的な分離と地理的な制限を適用する。
【カテゴリ】プラットフォームのセキュリティ（PR.PS）:物理プラットフォームおよび仮想プラットフォームのハードウェア、ソフトウェア（ファームウェア、オペレーティングシステム、アプリケーションなど）、およびサービスが、組織のリスク戦略に従って管理され、機密性、完全性、および可用性を保護する。
サブカテゴリ PR.PS-01:構成管理プラクティスが確立され、適用されている。
実装例
例1:組織のサイバーセキュリティポリシーを適用し、必要な機能のみを提供する強化されたベースラインを確立、テスト、デプロイ、および維持する（つまり、最小機能の原則）。
例2:ソフトウェアをインストールまたはアップグレードする際に、サイバーセキュリティに影響を与える可能性のあるすべてのデフォルト設定を確認する。
例3:実装されたソフトウェアを監視し、承認されたベースラインからの逸脱がないか確認する。
サブカテゴリ PR.PS-02:ソフトウェアはリスクに見合った保守、交換、削除が行われる。
実装例
例1:脆弱性管理計画で指定された期間内に定期的および緊急のパッチ適用を実行する。
例2:コンテナイメージを更新し、既存のインスタンスを更新するのではなく、置き換えるために新しいコンテナインスタンスをデプロイする。
例3:サポートが終了したソフトウェアとサービスのバージョンを、サポートされ保守されているバージョンに置き換える。
例4:過度のリスクをもたらす不正なソフトウェアやサービスをアンインストールして削除する。
例5:攻撃者が悪用する可能性のある不要なソフトウェアコンポーネント（オペレーティングシステムユーティリティなど）をアンインストールして削除する。
例6:ソフトウェアとサービスの保守サポート終了と陳腐化の計画を定義して実装する。
サブカテゴリ PR.PS-03:ハードウェアはリスクに見合った保守、交換、撤去を行う。
実装例
例1:必要なセキュリティ機能がない場合、または必要なセキュリティ機能を備えたソフトウェアをサポートできない場合は、ハードウェアを交換する。
例2:ハードウェアのサポート終了と陳腐化の計画を定義して実装する。
例3:ハードウェアの廃棄を、安全で責任を持って、監査可能な方法で実行する。
サブカテゴリ PR.PS-04:ログ記録を作成し、継続的なモニタリングに利用できるようにする。
実装例
例1:すべてのオペレーティングシステム、アプリケーション、サービス（クラウドベースのサービスを含む）を構成して、ログレコードを生成する。
例2:組織のログ記録インフラストラクチャシステムおよびサービスとログを安全に共有するようにログジェネレーターを構成する。
例3:ゼロトラストアーキテクチャに必要なデータを記録するようにログジェネレーターを設定する。
サブカテゴリ PR.PS-05:不正なソフトウェアのインストールと実行を防止する。
実装例
例1:リスクが正当化される場合は、ソフトウェアの実行を許可された製品のみに制限するか、禁止および許可されていないソフトウェアの実行を拒否する。
例2:新しいソフトウェアをインストールする前に、そのソフトウェアの提供元と完全性を確認する。
例3:既知の悪意のあるドメインへのアクセスをブロックする承認されたDNSサービスのみを使用するようにプラットフォームを構成する。
例4:組織が承認したソフトウェアのみのインストールを許可するようにプラットフォームを構成する。
サブカテゴリ PR.PS-06:セキュアなソフトウェア開発プラクティスを統合し、ソフトウェア開発ライフサイクル全体を通じてそのパフォーマンスを監視する。
実装例
例1:組織が開発したソフトウェアのすべてのコンポーネントを改ざんや不正アクセスから保護する。
例2:組織が作成したすべてのソフトウェアを、リリースの脆弱性を最小限に抑えて保護する。
例3:本番環境で使用するソフトウェアをメンテナンスし、不要になったソフトウェアは安全に廃棄する。
サブカテゴリ PR.IR-01:ネットワークと環境は、不正な論理アクセスや使用から保護されている。
実装例
例1:信頼境界とプラットフォームタイプ（IT、IoT、OT、モバイル、ゲストなど）に従って、組織のネットワークとクラウドベースのプラットフォームを論理的にセグメント化し、セグメント間で必要な通信のみを許可する。
例2:組織のネットワークを外部ネットワークから論理的にセグメント化し、必要な通信のみが外部ネットワークから組織のネットワークに入ることを許可する。
例3:エンドポイントに運用リソースへのアクセスと使用を許可する前に、エンドポイントのサイバーヘルスを確認する。
例4:エンドポイントに運用リソースへのアクセスと使用を許可する前に、エンドポイントのサイバーヘルスを確認する。
サブカテゴリ PR.IR-02:組織の技術資産を環境脅威から保護する。
実装例
例1:洪水、火災、風、過度の熱と湿度などの既知の環境脅威から組織の機器を保護する。
例2:環境の脅威からの保護と、組織に代わってシステムを運用するサービスプロバイダーの要件に、適切な運用インフラストラクチャに関する規定を含める。
サブカテゴリ PR.IR-03:平常時および不利な状況における回復力要件を達成するためのメカニズムが導入されている。
実装例
例1:システムとインフラストラクチャの単一障害点を回避する。
例2:負荷分散を使用して容量を増やし、信頼性を向上させる。
例3:冗長ストレージや電源などの高可用性コンポーネントを使用して、システムの信頼性を向上させる。
サブカテゴリ PR.IR-04:可用性を確保するために十分なリソース容量が維持されていること。
実装例
例1:ストレージ、電源、コンピューティング、ネットワーク帯域幅、そのほかのリソースの使用状況を監視する。
例2:将来のニーズを予測し、それに応じてリソースを拡張する。
【カテゴリ】ID 管理、認証、アクセス制御 (PR.AC):[撤回:PR.AAに移動する。]
サブカテゴリ PR.AC-01:[撤回:PR.AA-01、PR.AA-05に編入する。]
実装例
サブカテゴリ PR.AC-02:[撤回:PR.AA-06に移動する。]
実装例
サブカテゴリ PR.AC-03:[撤回:PR.AA-03、PR.AA-05、PR.IR-01に編入する。]
実装例
サブカテゴリ PR.AC-04:[撤回: PR.IR-01に移動する。]
実装例
サブカテゴリ PR.AC-05:[撤回:PR.IR-01に編入する。]
実装例
サブカテゴリ PR.AC-06:[撤回: PR.IR-02に移動する。]
実装例
サブカテゴリ PR.AC-07:[撤回: PR.IR-03に移動する。]
実装例
【カテゴリ】情報保護のプロセスと手順 (PR.IP):[撤回:他のカテゴリー・機能に組み込まれる。]
サブカテゴリ PR.IP-01:[撤回: PR.PS-01に編入する。]
実装例
サブカテゴリ PR.IP-02:[撤回: ID.AM-08、PR.PS-06に編入する。]
実装例
サブカテゴリ PR.IP-03:[撤回: PR.PS-01、ID.RA-07に編入する。]
実装例
サブカテゴリ PR.IP-04:[撤回:PR.DS-11に移動する。]
実装例
サブカテゴリ PR.IP-05:[撤回:PR.IR-02に移動する。]
実装例
サブカテゴリ PR.IP-06:[撤回:ID.AM-08に編入する。]
実装例
サブカテゴリ PR.IP-07:[撤回:ID.IM、ID.IM-03に編入する。]
実装例
サブカテゴリ PR.IP-08:[撤回:ID.IM-03に移動する。]
実装例
サブカテゴリ PR.IP-09:[撤回: ID.IM-04に移動する。]
実装例
サブカテゴリ PR.IP-10:[撤回:ID.IM-02、ID.IM-04に編入する。]
実装例
サブカテゴリ PR.IP-11:[撤回:GV.RR-04に移動する。]
実装例
サブカテゴリ PR.IP-12:[撤回:ID.RA-01、PR.PS-02に編入する。]
実装例
【カテゴリ】メンテナンス(PR.MA):撤回:ID.AM-08に編入する。
サブカテゴリ PR.MA-01:[撤回:ID.AM-08、PR.PS-03に編入する。]
実装例
サブカテゴリ PR.MA-02:[撤回: ID.AM-08、PR.PS-02に編入する。]
【カテゴリ】保護技術 (PR.PT):撤回:他の保護カテゴリーに組み込まれる。
サブカテゴリ PR.PT-01:[撤回:PR.PS-04に編入する。]
実装例
サブカテゴリ PR.PT-02:[撤回:PR.DS-01、PR.PS-01に編入する。]
実装例
サブカテゴリ PR.PT-03:[撤回:PR.PS-01に編入する。]
実装例
サブカテゴリ PR.PT-04:[撤回:PR.AA-06、PR.IR-01に編入する。]
実装例
サブカテゴリ PR.PT-05:[撤回:PR.IR-03に移動する。]
実装例
【カテゴリ】継続的モニタリング（DE.CM）:異常、侵害の指標、そのほかの潜在的な有害事象を発見するために資産を監視する。
サブカテゴリ DE.CM-01:ネットワークとネットワークサービスは、潜在的に有害な事象を発見するために監視される。
実装例
例1:DNS、BGP、およびそのほかのネットワークサービスで有害事象を監視する。
例2:有線および無線ネットワークを監視して、許可されていないエンドポイントからの接続を確認する。
例3:許可されていないワイヤレスネットワークまたは不正なワイヤレスネットワークのための施設を監視する。
例4:実際のネットワークフローをベースラインと比較して、偏差を検出する。
例5:ネットワーク通信を監視して、ゼロトラストの目的でセキュリティ体制の変更を特定する。
サブカテゴリ DE.CM-02:潜在的に有害な事象を発見するために、物理的環境をモニターする。
実装例
例1:物理的なアクセス制御システム（バッジリーダーなど）からのログを監視して、異常なアクセスパターン（標準からの逸脱など）と失敗したアクセス試行を見つける。
例2:物理的なアクセス記録（訪問者登録、サインインシートなど）を確認および監視する。
例3:物理的なアクセス制御（ロック、ラッチ、ヒンジピン、アラームなど）を監視して、改ざんの兆候がないか確認する。
例4:警報システム、カメラ、警備員を使用して物理的環境を監視する。
サブカテゴリ DE.CM-03:潜在的な有害事象を発見するため、従業員の活動および技術利用を監視する。
実装例
例1:行動分析ソフトウェアを使用して異常なユーザーアクティビティを検出し、内部脅威を軽減する。
例2:論理アクセス制御システムからのログを監視して、異常なアクセスパターンと失敗したアクセス試行を見つける。
例3:ユーザーアカウントを含む欺瞞技術を継続的に監視し、あらゆる使用について監視する。
サブカテゴリ DE.CM-04:[撤回。DE.CM-01およびDE.CM-09に編入する。]
実装例
サブカテゴリ DE.CM-05:[撤回。DE.CM-01およびDE.CM-09に編入する。]
実装例
サブカテゴリ DE.CM-06:外部サービス提供者の活動およびサービスは、潜在的に有害な事象を発見するために監視される。
実装例
例1:外部プロバイダーが組織システムに対して実行するリモートおよびオンサイトの管理および保守活動を監視する。
例2:クラウドベースのサービス、インターネットサービスプロバイダー、およびそのほかのサービスプロバイダーからのアクティビティを監視して、予想される動作からの逸脱を確認する。
サブカテゴリ DE.CM-07:[撤回:DE.CM-01、DE.CM-03、DE.CM-06、DE.CM-09に編入する。]
実装例
サブカテゴリ DE.CM-08:[撤回:ID.RA-01に編入する。]
実装例
サブカテゴリ DE.CM-09:コンピューティングのハードウェアとソフトウェア、ランタイム環境、およびそれらのデータを監視し、潜在的に有害な事象を発見する。
実装例
例1:メール、Web、ファイル共有、コラボレーションサービス、そのほかの一般的な攻撃ベクトルを監視して、マルウェア、フィッシング、データ漏えいと流出、そのほかの有害事象を検出する。
例2:認証の試行を監視して、資格情報に対する攻撃と資格情報の不正な再利用を特定する。
例3:ソフトウェア構成のセキュリティベースラインからの逸脱を監視する。
例4:ハードウェアとソフトウェアを改ざんの兆候がないか監視する。
例5:エンドポイントに存在するテクノロジーを使用して、サイバーヘルスの問題（パッチの欠落、マルウェア感染、未承認のソフトウェアなど）を検出し、アクセスが承認される前にエンドポイントを修復環境にリダイレクトする。
【カテゴリ】有害事象分析（DE.AE）:異常、侵害の指標、そのほかの潜在的な有害事象を分析して事象を特徴づけ、サイバーセキュリティインシデントを検出する。
サブカテゴリ DE.AE-01:[撤回:ID.AM-03に編入する。]
実装例
サブカテゴリ DE.AE-02:潜在的有害事象を分析し、関連する活動をよりよく理解する。
実装例
例1:セキュリティ情報およびイベント管理（SIEM）またはそのほかのツールを使用して、既知の悪意のあるアクティビティや疑わしいアクティビティのログイベントを継続的に監視する。
例2:ログ分析ツールで最新のサイバー脅威インテリジェンスを活用して、検出精度を向上させ、脅威アクター、その方法、および侵害の兆候を特徴づける。
例3:自動化では十分に監視できないテクノロジーのログイベントについて、定期的に手動レビューを実施する。
例4:ログ分析ツールを使用して、調査結果に関するレポートを生成する。
サブカテゴリ DE.AE-03:情報は複数の情報源から関連付けられている。
実装例
例1:他のソースから生成されたログデータを比較的少数のログサーバに常に転送する。
例2:イベント相関技術（SIEMなど）を使用して、複数のソースから取得した情報を収集する。
例3:サイバー脅威インテリジェンスを活用して、ログソース間でイベントを関連付ける。
サブカテゴリ DE.AE-04:有害事象の推定影響と範囲が理解されている。
実装例
例1:SIEMまたはそのほかのツールを使用して、影響と範囲を見積り、見積りを確認して調整する。
例2:人が影響と範囲について自分で見積りを作成する。
サブカテゴリ DE.AE-05:[撤回。DE.AE-08に移動する。]
実装例
サブカテゴリ DE.AE-06:有害事象に関する情報は、権限を与えられたスタッフおよびツールに提供される。
実装例
例1:サイバーセキュリティソフトウェアを使用してアラートを生成し、セキュリティオペレーションセンター（SOC）、インシデント対応者、インシデント対応ツールに提供する。
例2:インシデント対応者およびそのほかの権限のある担当者は、ログ分析の結果にいつでもアクセスできる。
例3:特定の種類のアラートが発生したときに、組織のチケットシステムでチケットを自動的に作成して割り当てる。
例4:技術スタッフが侵害の兆候を発見したときに、組織のチケットシステムでチケットを手動で作成して割り当てる。
サブカテゴリ DE.AE-07:サイバー脅威インテリジェンスとそのほかの文脈情報が分析に統合される。
実装例
例1:サイバー脅威インテリジェンスフィードを検知技術、プロセス、および担当者に安全に提供する。
例2:資産インベントリから検出技術、プロセス、人員まで情報を安全に提供する。
例3:サプライヤー、ベンダー、サードパーティのセキュリティアドバイザリから組織のテクノロジーの脆弱性開示を迅速に取得して分析する。
サブカテゴリ DE.AE-08:インシデントは、有害事象が定義されたインシデント基準を満たす場合に宣言される。
実装例
例1:インシデントを宣言すべきか否かを判断するために、アクティビティの既知および想定される特性にインシデント基準を適用する。
例2:インシデント基準を適用する際に既知の誤検知を考慮に入れる。
【カテゴリ】検出プロセス (DE.DP):[撤回:他のカテゴリーおよび機能に編入する。]
サブカテゴリ DE.DP-01:[撤回:GV.RR-02に編入する。]
実装例
サブカテゴリ DE.DP-02:[撤回:DE.AEに編入する。]
実装例
サブカテゴリ DE.DP-03:[撤回:ID.IM-02に編入する。]
実装例
サブカテゴリ DE.DP-04:[撤回:DE.AE-06に編入する。]
実装例
サブカテゴリ DE.DP-05:[撤回:ID.IM、ID.IM-03に編入する。]
実装例
【カテゴリ】インシデント管理（RS.MA）:検出されたサイバーセキュリティインシデントへの対応を管理する。
サブカテゴリ RS.MA-01:インシデント対応計画は、インシデントが宣言された後、関連する第三者と連携して実行される。
実装例
例1:検知技術が確認済みのインシデントを自動的に報告する。
例2:組織のインシデント対応アウトソーシング業者にインシデント対応支援を依頼する。
例3:インシデントごとにインシデントリードを指名する。
例4:インシデント対応（ビジネス継続性やディザスターリカバリーなど）をサポートするために、必要に応じて追加のサイバーセキュリティ計画の実行を開始する。
サブカテゴリ RS.MA-02:インシデント報告はトリアージされ、検証される。
実装例
例1:インシデントレポートを事前にレビューして、サイバーセキュリティ関連であり、インシデント対応活動が必要であることを確認する。
例2:インシデントの重大度を見積る条件を適用する。
サブカテゴリ RS.MA-03:インシデントは分類と優先順位付けされる。
実装例
例1:インシデントの種類（データ侵害、ランサムウェア、DDoS、アカウント侵害など）に基づいてインシデントをさらにレビューし、分類する。
例2:インシデントの範囲、予想される影響、およびタイムクリティカルな性質に基づいてインシデントに優先順位を付ける。
例3:インシデントから迅速に復旧する必要性と、攻撃者を観察したり、より徹底的な調査を実施したりする必要性とのバランスを取ることで、アクティブなインシデントのインシデント対応戦略を選択する。
サブカテゴリ RS.MA-04:インシデントは必要に応じてエスカレーションまたは昇格される。
実装例
例1:進行中のすべてのインシデントのステータスを追跡して検証する。
例2:インシデントのエスカレーションまたは昇格を、指定された内部および外部の利害関係者と調整する。
サブカテゴリ RS.MA-05:事故復旧の開始基準が適用される。
実装例
例1:インシデントの既知および想定される特性にインシデント復旧基準を適用して、インシデント復旧プロセスを開始する必要があるか否かを判断する。
例2:インシデント復旧活動の運用中断の可能性を考慮に入れる。
【カテゴリ】インシデント分析（RS.AN）:効果的な対応を確保し、フォレンジックと復旧活動をサポートするために調査を実施する。
サブカテゴリ RS.AN-01:[撤回:RS.MA-02に編入する。]
実装例
サブカテゴリ RS.AN-02:[撤回:RS.MA-02、RS.MA-03、RS.MA-04に編入する。]
実装例
サブカテゴリ RS.AN-03:インシデント発生時に何が起こったか、またその根本原因を特定するために分析を行う。
実装例
例1:インシデント中に発生したイベントのシーケンスと、各イベントに関与した資産とリソースを特定する。
例2:インシデントに直接的または間接的に関与した脆弱性、脅威、および脅威アクターの特定を試みる。
例3:インシデントを分析して、根底にある体系的な根本原因を見つける。
例4:サイバーデセプションテクノロジーで攻撃者の行動に関する追加情報を確認する。
サブカテゴリ RS.AN-04:[撤回:RS.MA-03に移動する。]
実装例
サブカテゴリ RS.AN-05:[撤回:ID.RA-08に移動する。]
実装例
サブカテゴリ RS.AN-06:調査中に行われた行為は記録され、記録の完全性と出所は保全される。
実装例
例1:各インシデント対応者と、インシデント対応タスクを実行する他の人（システム管理者、サイバーセキュリティエンジニアなど）に、自分の行動を記録し、記録を不変にするように要求する。
例2:インシデントのリーダーにインシデントを詳細に文書化し、文書化の完全性と報告されるすべての情報のソースを維持する責任を持つように要求する。
サブカテゴリ RS.AN-07:インシデントデータとメタデータを収集し、その完全性と出所を保全する。
実装例 例1:証拠保全とCoC（Chain of Custody）の手続きに基づいて、関連するすべてのインシデントデータとメタデータ（データソース、収集日時など）の完全性を収集、保存、保護する。
サブカテゴリ RS.AN-08:事故の規模を推定し、検証する。
実装例
例1:インシデントのほかの潜在的なターゲットを確認して、侵害の兆候と永続性の証拠を検索する。
例2:ターゲットに対してツールを自動的に実行して、侵害の兆候と永続性の証拠を探す。
【カテゴリ】インシデントレスポンスの報告とコミュニケーション（RS.CO）:対応活動は、法律、規制、またはポリシーの要求に従って、社内外の利害関係者と調整される。
サブカテゴリ RS.CO-01:[撤回:PR.AT-01に編入する。]
実装例
サブカテゴリ RS.CO-02:社内外の利害関係者にインシデントを通知する。
実装例
例1:データ侵害インシデントを発見した後、影響を受けた顧客への通知を含む、組織の侵害通知手順に従う。
例2:契約上の要件に従って、ビジネスパートナーや顧客にインシデントを通知する。
例3:インシデント対応計画の基準と経営陣の承認に基づいて、法執行機関および規制機関にインシデントを通知する。
サブカテゴリ RS.CO-03:指定された社内外のステークホルダーと情報を共有する。
実装例
例1:対応計画と情報共有契約に則った情報を安全に共有する。
例2:攻撃者が観測したTTPに関する情報を、すべての機密データを削除した状態で、情報共有分析センター（ISAC）と自発的に共有する。
例3:悪意のある内部関係者の活動が発生したときに人事部に通知する。
例4:重大インシデントの状況について、上級管理職に定期的に最新情報を提供する。
例5:組織とそのサプライヤー間のインシデント情報共有に関する契約で定義されているルールとプロトコルに従う。
例6:組織とその重要なサプライヤーとの間の危機管理コミュニケーション方法を調整する。
サブカテゴリ RS.CO-04:[撤回:RS.MA-01、RS.MA-04に編入する。]
実装例
サブカテゴリ RS.CO-05:[撤回:RS.CO-03に編入する。]
実装例
【カテゴリ】事故の緩和（RS.MI）:事象の拡大を防ぎ、その影響を緩和するための活動。
サブカテゴリ RS.MI-01:インシデントを封じ込める。
実装例
例1:サイバーセキュリティ技術（ウイルス対策ソフトウェアなど）と他の技術のサイバーセキュリティ機能（オペレーティングシステム、ネットワークインフラストラクチャデバイスなど）は、自動的に封じ込めアクションを実行する。
例2:インシデント対応者が手動で封じ込めアクションを選択して実行できるようにする。
例3:第三者（インターネットサービスプロバイダー、マネージドセキュリティサービスプロバイダーなど）が組織に代わって封じ込めアクションを実行できるようにする。
例4:侵害されたエンドポイントを修復仮想ローカルエリアネットワーク（VLAN）に自動的に転送する。
サブカテゴリ RS.MI-02:インシデントを根絶する。
実装例
例1:サイバーセキュリティ技術と他の技術（オペレーティングシステム、ネットワークインフラストラクチャデバイスなど）のサイバーセキュリティ機能は、自動的に根絶アクションを実行する。
例2:インシデント対応者が手動で根絶アクションを選択して実行できるようにする。
例3:第三者（マネージドセキュリティサービスプロバイダーなど）が組織に代わって根絶アクションを実行できるようにする。
サブカテゴリ RS.MI-03:[ID.RA-06に編入する。]
実装例
【カテゴリ】対応計画(RS.RP):[撤回:RS.MAに編入する。]
サブカテゴリ RS.RP-01:[撤回:RS.MA-01に編入する。]
実装例
【カテゴリ】改善点(RS.IM):[撤回:ID.IMに編入する。]
サブカテゴリ RS.IM-01:[撤回:ID.IM-03、ID.IM-04に編入する。]
実装例
サブカテゴリ RS.IM-02:[撤回:ID.IM-03に編入する。]
実装例
【カテゴリ】インシデント復旧計画の実行（RC.RP）:サイバーセキュリティインシデントの影響を受けたシステムとサービスの運用可用性を確保するための復旧活動を実施する。
サブカテゴリ RC.RP-01:インシデント対応計画の復旧部分は、インシデント対応プロセスから開始されると実行される。
実装例
例1:インシデント対応プロセス中またはインシデント対応プロセス後に復旧手順を開始する。
例2:回復の責任を負うすべての個人に、回復の計画と、計画の各側面を実装するために必要な権限を認識させる。
サブカテゴリ RC.RP-02:復旧アクションの選択、範囲設定、優先順位付け、実行を行う。
実装例
例1:インシデント対応計画と利用可能なリソースで定義された基準に基づいて復旧アクションを選択する。
例2:組織のニーズとリソースの再評価に基づいて計画された復旧アクションを変更する。
サブカテゴリ RC.RP-03:バックアップやそのほかのリストア資産をリストアに使用する前に、その完全性を検証する。
実装例 例1:使用前に、復元資産に侵害、ファイルの破損、そのほかの整合性の問題の兆候がないか確認する。
サブカテゴリ RC.RP-04:重要なミッション機能とサイバーセキュリティのリスク管理は、事故後の運用規範を確立するために考慮される。
実装例
例1:ビジネスへの影響とシステムの分類レコード（サービス提供目標を含む）を使用して、重要なサービスが適切な順序で復元されていることを検証する。
例2:システム所有者と協力して、システムの正常な復元と通常の運用への復帰を確認する。
例3:復元されたシステムのパフォーマンスを監視して、復元の適切性を確認する。
サブカテゴリ RC.RP-05:復旧した資産の完全性が検証され、システムとサービスが復旧し、正常な運用状態が確認される。
実装例
例1:復元された資産で侵害の兆候を確認し、本番環境で使用する前にインシデントの根本原因を修復する。
例2:復元されたシステムをオンラインにする前に、実行された復元アクションの正確性と妥当性を確認する。
サブカテゴリ RC.RP-06:基準に基づいて事故復旧の終了が宣言され、事故関連の文書化が完了する。
実装例
例1:インシデント自体、実行された対応措置と復旧措置、および学んだ教訓を文書化した事後処理レポートを作成する。
例2:基準が満たされたら、インシデント復旧の終了を宣言する。
【カテゴリ】事故復旧コミュニケーション（RC.CO）:復旧活動を社内外の関係者と調整する。
サブカテゴリ RC.CO-01:[撤回:RC.CO-04に編入する。]
実装例
サブカテゴリ RC.CO-02:[撤回:RC.CO-04に編入する。]
実装例
サブカテゴリ RC.CO-03:復旧活動と業務能力回復の進捗状況を、指定された社内外の利害関係者に伝達する。
実装例
例1:復旧の進行状況を含む復旧情報を安全に共有し、対応計画と情報共有契約に則った対応する。
例2:重大インシデントの復旧状況と復旧の進捗状況について、上級管理職に定期的に最新情報を提供する。
例3:組織とそのサプライヤー間のインシデント情報共有に関する契約で定義されたルールとプロトコルに従う。
例4:組織とその重要なサプライヤーとの間の危機管理コミュニケーションを調整する。
サブカテゴリ RC.CO-04:承認された方法とメッセージングを使用し、事故復旧に関する一般向けの最新情報を共有する。
実装例
例1:データ侵害インシデントから回復するための組織の侵害通知手順に従う。
例2:インシデントから回復し、再発を防ぐために実行している手順を説明する。
【カテゴリ】改善点 (RC.IM):撤回:ID.IM に編入する。
サブカテゴリ RC.IM-01:[撤回:ID.IM-03、ID.IM-04に編入する。]
実装例
サブカテゴリ RC.IM-02:[撤回:ID.IM-03に編入する。]
実装例
詳細理解のため参考となる文献（参考文献）
中小企業が、CSF2.0を使用してセキュリティ対策を開始するにあたり、クイックスタートガイド（Small Business Quick-Start Guide）が参考になります。このガイドは、セキュリティ対策が十分でない中小企業に対して、セキュリティ対策を始めるための基本的なステップを提供します。ガバナンス、識別、防御、検知、対応、復旧、各機能それぞれにおいて、段階的に対策を進める方法を示しています。
このガイドは、必要に応じて外部の専門家やサービスの利用を検討するための指針にもなります。
各機能の活動の中から1つを例にとり、どのような内容が記載してあるかを説明します。
ガバナンス
ガバナンス機能は、ビジネスのサイバーセキュリティリスク管理戦略、期待値、ポリシーを確立し、監視するのに役立ちます。
考慮すべきアクション
理解
・サイバーセキュリティリスクが、ビジネスの目標達成をどのように妨げる可能性があるかを理解する。（GV.OC-01）
・法的、規制上、および契約上のサイバーセキュリティ要件を理解する。（GV.OC-03）
・ビジネス内で誰がサイバーセキュリティ戦略を策定し、実行する責任を負うかを理解する。（GV.RR-02）
評価
・ビジネスにとって大事な資産や運営がすべて、または一部失われた場合にどんな影響が出るかを評価する。（GV.0C-04）
・自社にサイバーセキュリティ保険が必要か否かを評価する。（GV.RM-04）
・取引を開始する前に、取引先や他の第三者がもたらすサイバーセキュリティリスクを評価する。（GV.SC-06）
優先
・サイバーセキュリティリスクを、他のビジネスリスクと同じように優先して管理する。（GV.RM-03）
コミュニケーション
・経営陣がリスクに気を配り、倫理的で常に改善を目指す姿勢をサポートしていることを伝える。（GV.RR-01）
・サイバーセキュリティリスクを管理するためのポリシーを伝達し、実施し、維持する。（GV.PO-01）
サイバーセキュリティ統制の始め方
以下の表を使って、サイバーセキュリティ統制戦略について考え始めることができます。
組織の目的や状況の整理
組織の使命や目標
組織の使命や目標の達成を妨げる可能性があるセキュリティリスクは何か？
セキュリティ要件の文書化
法的要件をリスト化する
規制要件をリスト化する
契約上の要件をリスト化する
サイバーセキュリティ統制の始め方
（出典）NIST「NIST Cybersecurity Framework 2.0: Small Business Quick-Start Guide」をもとに作成
考慮すべきポイント
・ビジネスが成長するにつれて、どのくらいの頻度でサイバーセキュリティ戦略を見直していますか？
・既存従業員のスキルアップが必要ですか？または、専門知識を持つ新しい人材を採用するか、外部のパートナーと協力してサイバーセキュリティ計画を確立し、管理する必要がありますか？
・会社のデバイスおよび従業員の私物デバイスが会社の資産にアクセスする際の、適切な利用ポリシーは整っていますか？従業員はこれらのポリシーについて教育を受けていますか？
詳細理解のため参考となる文献（参考文献）
