アメリカ国防総省 サイバーセキュリティの相互承認プレイブック

DoD Cybersecurity Reciprocity Playbook 概要

DoD Cybersecurity Reciprocity Playbookは、アメリカ国防総省（DoD）のシステムにおけるサイバーセキュリティの相互承認（Reciprocity）に関する優先事項を明確かつ信頼性のある情報として提供するために設計されています。このプレイブックは、DoD Instruction 8510.01「DoDシステムのリスク管理フレームワーク（RMF）」に従っています。

The Department of Defense
Cybersecurity Reciprocity Playbook
Version 1.0
March 2024

Cybersecurity Reciprocity Playbook – DoD CIO

このプレイブックは、サイバーセキュリティ相互承認の複雑な状況をナビゲートしようとする組織にとって、貴重な出発点として機能します。しかし、サイバーセキュリティの風景が絶えず変化することを認識し、継続的な改善と協力を奨励します。したがって、改善のための領域を特定したり、このプレイブックに貢献する革新的なアイデアをお持ちの場合は、RMF TAG事務局（osd.pentagon.dod-cio.mbx.rmf-tag-secretariat@mail.mil）と連携することをお勧めします。この継続的な対話と共同の取り組みを通じて、我々の防御を強化し、DoDシステムにおけるサイバーセキュリティ相互承認を実現し続けることができます。

要点

・出発点としてのプレイブック:このプレイブックは、サイバーセキュリティ相互承認を探求する組織にとってのガイドラインとリソースを提供します。

・継続的な改善と協力:サイバーセキュリティの風景の動的な性質を認識し、常に改善と協力を追求することが重要です。

・フィードバックと対話の奨励:改善のための領域を見つけたり、革新的なアイデアを持っている場合は、RMF TAG事務局と積極的に対話することを奨励します。

・共同の取り組みの重要性:継続的な対話と共同の取り組みを通じて、防御を強化し、効果的なサイバーセキュリティ相互承認を実現します。

このプレイブックが提供するガイドラインとリソースを活用し、協力と継続的な改善を通じて、DoDシステムにおけるサイバーセキュリティの相互承認を強化していきましょう。

1. サイバーセキュリティの重要性

サイバーセキュリティは、国の重要な資産、情報、そして運用を保護するための最重要課題です。悪意のあるサイバー活動は国家安全保障、経済の安定、公衆の安全に対する重大な脅威となります。技術が進化し、敵が高度化する中で、機密性、完全性、可用性を確保することが不可欠です。

1.1 RMFの役割

リスク管理フレームワーク（RMF）は、DoDのサイバーセキュリティ戦略の中核を担っています。RMFは、DoDの全体の運用にわたるサイバーリスクを識別、評価、軽減するための包括的なフレームワークを提供します。RMFにより、アプリケーション、システム、ネットワークに関連するリスクを管理するための一貫したアプローチが確立されます。これにより、システムの設計から運用までサイバーセキュリティの考慮が組み込まれます。

FedRAMPの役割

FedRAMP（連邦リスクおよび承認管理プログラム）は、クラウドサービスプロバイダー（CSP）が連邦機関と連携するために遵守すべき標準化されたセキュリティ評価、承認、および継続的な監視のアプローチを提供します。DoDは、クラウドサービス提供のためにFedRAMPまたは独自の暫定承認（Provisional Authorization）を使用します。

インパクトレベル

インパクトレベル（IL）は、データの機密性や重要性に応じてクラウドサービスの使用を分類するための基準です。

  • IL2（インパクトレベル2）: 公開可能なデータまたは限定的な非公開データを扱います。情報の不正開示が限定的な悪影響を及ぼす可能性がある場合に適用されます。
  • IL4（インパクトレベル4）: 非公開の非機密データを扱い、不正開示が深刻な悪影響を及ぼす可能性がある場合に適用されます。これには軍事運用のサポートデータなどが含まれます。
  • IL5（インパクトレベル5）: 非公開の国家安全保障システム（NSS）データまたは高度な保護が必要なデータを扱います。
  • IL6（インパクトレベル6）: 非公開の機密NSSデータ（機密国家安全保障情報）を扱い、不正開示が深刻な悪影響を及ぼす可能性がある場合に適用されます。現時点では、機密指定が「SECRET」以下の情報が対象です。

2. サイバーセキュリティ活動

効果的な監視および分析能力、インシデント対応手順、効率的なコミュニケーション管理と制御、そしてタイムリーな報告は、健全なネットワーク運用を確保するための重要な活動であり、強力なネットワークセキュリティの基盤となります。これらのサイバーセキュリティ活動は、業務の効率化のために簡略化されたり、無視されたりしてはなりません。

RMFの強調と要件

リスク管理フレームワーク（RMF）は、これらのサイバーセキュリティ活動の実施を強調し、能力を運用許可（ATO）を得るための条件として求めています。ATOを持たないすべてのシステムは、システムのライフサイクルステージ（例：取得、運用）に関わらず、RMFプロセスを開始する必要があります。

このセクションでは、サイバーセキュリティ活動の重要性と、RMFがそれらの活動を確実に実施するための役割について説明しています。具体的には、以下の活動が重要とされています。

  1. 効果的な監視および分析能力: ネットワークやシステムの健全な運用を維持するためには、異常や潜在的な脅威を迅速に検出するための監視と分析が必要です。
  2. インシデント対応手順: サイバー攻撃やセキュリティインシデントが発生した場合の迅速かつ効果的な対応手順が不可欠です。
  3. 効率的なコミュニケーション管理と制御: インシデント対応や日常的な運用において、関連するチームや組織との効率的なコミュニケーションが求められます。
  4. タイムリーな報告: 発生したインシデントや監視結果を迅速に報告することで、適切な対応や対策を講じることができます。

3. 相互承認の定義

相互承認（Reciprocity）は、国家安全保障システム指示（CNSSI）4009で定義されているように、「参加組織が互いのセキュリティ評価を受け入れ、システムリソースを再利用し、互いの評価済みのセキュリティ姿勢を受け入れて情報を共有するための合意」です。

相互承認のプロセス

相互承認プロセス中、認可責任者（AOs）は、以下の文書からなる証拠の集合（BoE）をレビューしてシステム認可決定を行います。

  1. システムセキュリティ計画（SSP）
  2. セキュリティ評価報告書（SAR）
  3. リスク評価報告書（RAR）
  4. 行動計画とマイルストーン（POA&M）
  5. 認可決定文書

これらは、CNSSI 1254の付録Cに定義されています。

政策と実践

2016年10月に発行されたDoD CIOのメモランダム（reference g）は、DoDI 8510.01に従って確立されたDoDのサイバーセキュリティ相互承認ポリシーを再確認しました。このメモランダムでは、既にDoDに展開されているシステムの評価と認可には相互承認がデフォルトであると強調されています。また、共通のITシステムやソフトウェアの以前の評価結果と認可を最大限に活用することが期待されています。

2023年3月には、DoDI 8510.01の再発行を支持するメモランダム（reference j）が発行され、コンポーネントが強力なBoEを活用して相互承認を最大限に利用することが強調されました。

改善のための取り組み

CIOは、セキュリティテストの証拠の再利用を相互承認の基盤として強調し、証拠の集合を調べずに認可決定メモを発行する慣行を排除することをポリシーに定めています。DoDI 8510.01は、「DoD情報エンタープライズは、重複するテスト、評価、文書化、および関連する時間とリソースのコストを削減するためにサイバーセキュリティ相互承認を利用する」と述べています。これにより、データが提供され、コンポーネントがリスクに基づいた意思決定を行えるようにし、努力の重複を排除します。

実際の相互承認

相互承認は、他のエンティティからのセキュリティ評価、認証、認可を慎重に考慮せずに受け入れることではありません。むしろ、相互承認は、リスクに基づく評価プロセスと、特定のセキュリティ環境内での適用性と適合性を判断するための証拠の集合の詳細な検査を伴います。

本質的に、相互承認は、BoEの再利用を通じて効率を最大化しながら、強力なセキュリティ姿勢を維持することの重要性を強調しています。したがって、相互承認は、信頼できるパートナーの洞察と努力を活用しながら、システムの整合性を保護し、サイバーセキュリティの回復力を強化するための慎重なアプローチを要求します。

3.1 相互承認の利点

相互承認（Reciprocity）の利点は、評価やアーティファクトの再利用を通じて認可プロセスを迅速化し、コスト削減を実現することにあります。適切に実行されると、相互承認は重複するテスト、評価、文書作成を減らし、それに伴う時間とリソースのコストを削減します。

相互承認をサポートするための取り組み

  • セキュリティ認可パッケージの共有:DoDのコンポーネントは、関連する情報所有者や相互接続システム所有者とセキュリティ認可パッケージを共有します。これにより、AOはシステムの評価を繰り返すことなく、展開予定のシステムに対する評価を受け入れることができます。
  • アーティファクトの再利用:同様の評価から関連するアーティファクトを受け入れることで、コストのかかる評価の数が減り、システムはより迅速かつ効率的に認可されます。

他の組織による能力の展開

場合によっては、ある組織が別の組織によって開発された能力を展開したいと考えることがあります。このような場合、両組織が類似したミッション要件を持ち、同様のデータフローとネットワークアーキテクチャを持つシステムコンポーネントを展開する予定であれば、既存の認可パッケージを活用することができます。

  • 受領組織の役割
    • この場合、受領組織はシステム所有者となり、システムの再認可を必要としませんが、使用認可（ATU）を発行する必要があります。このATUには、受領AOがホスティング/受領システムに接続するための認可を与える声明が含まれています。これらのシステムは、RMFインベントリツール（例：eMASS、Xacta）を通じて継承されてリンクされます。
    • また、実装文書のコピーを認可AOに提供し、システムが許可された構成でのみ運用および/または接続することを通知し、下位サイトにガイダンスを提供します。

全体的な効果

  • リソースの大幅な節約
    • アーティファクトの再利用により、リソースの大幅な節約が実現します。

3.2 相互承認を活用しないリスク

相互承認を最大限に活用しない場合、重複したリソース集約的な作業が発生する可能性があります。他の組織が実施した評価を認識しない場合、組織はシステムやネットワークの包括的な評価を自ら行わなければならなくなります。これにより、時間、人的資源、財政資源が無駄に割り当てられ、組織が効率的にサイバーセキュリティ姿勢を管理および強化する能力が妨げられます。

相互承認の欠如による影響

  • 冗長な評価とリソースの浪費:既に信頼できるパートナーによって実施された同様の評価が存在するにもかかわらず、自ら評価を行わなければならない場合、無駄な時間とリソースが消費されます。
  • 省庁間の協力と情報共有の弱体化:サイバー脅威が急速に進化する時代において、異なる政府機関や組織間でサイバーセキュリティの知見や発見を迅速に共有する能力は非常に重要です。相互承認は協力と信頼の文化を促進し、他の組織の専門知識や視点を活用することで、脅威の検出、予防、および対応能力を向上させます。

相互承認を活用しないことの結果

  • リソースの最適化の阻害:リソースの最適化が妨げられ、協力的な取り組みが妨害されます。
  • 効率と協力の向上の妨げ:相互承認を採用することで効率、省庁間の協力、および情報共有が促進されますが、それを活用しないことでこれらが阻害されます。

相互承認の重要性

  • 効率の向上:相互承認を採用することで、評価や認可のプロセスが効率化され、リソースの無駄が減少します。
  • 協力の促進:相互承認は、異なる組織間での協力と情報共有を促進し、全体的なサイバーセキュリティ姿勢を強化します。
  • 進化する脅威に対応:相互承認を活用することで、進化する脅威環境に対応した強力で堅固なサイバーセキュリティ姿勢を確立することができます。

4. 相互承認の使用例

以下の使用例は、相互承認が活用されるすべての状況を網羅しているわけではありません。セクション4.1から4.5の事例は、国防総省（DoD）内で最も一般的なアプリケーションにおいて相互承認がどのように活用されているかを示しています。

4.1 エンタープライズ – クラウド

FedRAMPの中程度のベースラインで既に承認されたサービス提供を行っているクラウドサービスプロバイダー（CSP）は、DoDによる公的データの相互承認に適格です。レビューのために証拠の集合（BoE）を取得するには、任務所有者（MO）は以下のリンクでFedRAMPパッケージアクセスリクエストフォームを提出する必要があります：https://www.fedramp.gov/assets/resources/documents/Agency_Package_Request_Form.pdf.

データがIL4/5/6に分類される場合、DoDは暫定承認（PA）を発行します。セキュリティ認可パッケージと継承はEnterprise Mission Assurance Support System（eMASS）で利用可能になり、任務所有者（MO）は部門のATOを取得する際にこれを活用できます。

  • IL4およびIL5:MOはeMASSからクラウドサービス提供（CSO）のセキュリティコントロールを継承し、SSP（システムセキュリティ計画）およびSRTM（セキュリティ要件トレーサビリティマトリックス）を使用してコントロール実装ガイダンスを理解し、必要に応じて追加のセキュリティコントロールを評価します。
  • IL2（公的データ）:DISA AOはFedRAMPマーケットプレイスで中程度のベースラインで評価され、認可されたCSOのための相互承認メモを発行しました。そのIL2をIL4/5に引き上げる必要がある場合、DoDスポンサーは以下のリンクでDISAにクラウド認可プロセスを開始するよう依頼します：https://dod365.sharepoint-mil.us/sites/DISA-RE-Apps/cas/SitePages/CASHome.aspx.
  • 全DoD暫定承認（PA）:認可されたCSOに関する全てのDoD PA、IL2相互承認に関するDISAメモランダムを含む、はDCASで確認できます。

4.2 エンタープライズ – ISRMC

DoD情報セキュリティリスク管理委員会（ISRMC）は、DoDシステムおよびネットワークのエンタープライズリスク管理プロセスを監督するための多機能委員会であり、エンタープライズシステムの相互承認の実行およびサポートにおいて重要な役割を果たすステークホルダーの一つです。

「エンタープライズシステム」は、DoD全体の要件を満たすために設計され、DoD情報エンタープライズ全体に複数のDoDコンポーネントに展開されるシステムです。以下の活動は、DoDコンポーネントがエンタープライズシステムを展開する際に相互承認を達成する方法を示しています。

4.2.1 認可組織の活動

a. セキュリティ認可パッケージの開始

  • セキュリティ認可パッケージを開始します。

b. DSAWGへの提出

  • DSAWGの代表を通じて、SSP、SAR、RAR、システムPOA&M、認可決定文書、展開サイトのリストと予定展開日を電子コピーで提供します。
  • 認可AOは、完全なセキュリティ認可パッケージと証拠の集合を受領AOに提供する必要があります。
  • プログラムマネージャー（PM）およびシステム所有者は、複数のDoDコンポーネントにシステムを展開する際に、eMASSやその他の自動評価および認可ツールにセキュリティ認可文書と証拠の集合を投稿することで、計画された受領サイトに認可ステータスと文書の可視性を提供できます。
  • 互換性のない記録管理システムやRMFインベントリツールを継承する組織に対しては、「手動継承」機能を使用します。

c. 情報共有

  • 関係者全員がシステムのセキュリティアーティファクトと文書の可視性を持つことを確認します。
  • DoD組織または他の米国政府機関からの有効な認可を持つシステムを受領組織に提供する場合、受領組織は認可とPOA&Mをレビューし、残留リスクを軽減するための緩和策を適用できることを確認します。追加の検証や確認テストは必要ありません。
  • 新しい環境または異なる環境でシステムを使用することによって導入される構成の違いは、追加のテストが必要です。
  • 基本設定が変更された場合、ローカルAOは追加のテストに基づいて新しい構成を認可する必要があります。
  • 認可組織のシステム所有者とPMは、システム開発の初期から受領組織の代表と協力してシステムセキュリティ要件を調整します。

d. DSAWGへの認可ステータスの報告

  • 要求に応じて、認可ステータスの報告をDSAWGに提供します。

e. セキュリティ評価

  • 受領組織の追加のセキュリティコントロールまたはDSAWGのセキュリティレビューで識別された調整要求に対応するために、受領組織と協力してセキュリティ評価を行います。

f. IAVMプログラムの遵守

g. DoD PPSMレジストリへの登録

h. ISRMCへの報告

  • 計画された展開の60営業日前までに、ISRMCにエンタープライズシステムの承認または不承認のための報告を行います。
  • ISRMCによって承認された場合、認可AOはエンタープライズシステムと展開されるバージョンのATOを発行できます。
  • ISRMCによって不承認とされた場合、認可AOはDSAWGと協力して、ISRMCのガイダンスに従ってエンタープライズシステムを調整し、ATOを受けることができるようにします。

i. 設置および構成要件文書の提供

4.2.2 ISRMCの活動

ISRMC（DoD情報セキュリティリスク管理委員会）は、エンタープライズシステムの接続を承認または不承認する責任を負います。以下はISRMCの主要な活動内容です。

a. エンタープライズシステム接続の承認または不承認

  • DSAWGの勧告および認可組織の決定ブリーフィングで特定された他の要因に基づいて、エンタープライズシステムの接続を承認または不承認します。

b. 承認された場合

  • 残留リスクの受容性を監視:エンタープライズシステムを受領する組織がコンポーネントサイトでの残留リスクの受容性を監視し、DoD Information Network（DoDIN）への接続を認可します。受容性の変更があり、それが緩和できない場合、ISRMCでの再評価が必要です。
  • リスク受容の利用:受領組織は、エンタープライズ能力をシステム認可記録に追加するための変更要求を承認する際に、ISRMCのリスク受容をRMFアーティファクトとして使用します。

c. 不承認された場合

  • ガイダンスの提供:ISRMCは、DSAWGを通じて認可組織に対し、DoDINへの接続を承認するために必要な行動と緩和策に関するガイダンスを提供します。

d. リスク緩和の完了まで承認を保留

  • リスク緩和の要求:ISRMCは、エンタープライズシステムのPOA&Mに記載された残留リスクを認可組織が文書化し、ISRMCの指示に従って緩和策を実施するまで承認を保留します。

4.2.3 受領組織の活動

エンタープライズシステムの相互承認を実行するために、受領組織は以下の活動を行います：

a. 状況認識の維持

  • eMASSなどの自動ツールを使用して、認可されたエンタープライズシステムの評価活動の状況を把握します。

b. セキュリティ認可パッケージの提供

  • システムのセキュリティ認可パッケージを認可組織に提供します。

c. セキュリティ影響の評価

  • 受領システム内での認可エンタープライズシステムの接続のセキュリティ影響を評価し、DSAWG代表を通じて接続を妨げる可能性のある問題（例：割り当てられたセキュリティコントロールの調整要求や追加コントロールの要件）を特定します。

d. セキュリティコントロールのテスト

  1. コントロールと展開ガイドをレビューし、ローカルセキュリティ姿勢が展開条件を満たしていることを確認し、継承されたコントロールを実装し、展開ガイドに従ってシステムを展開します。
  2. システムに組み込まれているセキュリティコントロールは変更せず、再テストは不要です。
  3. ハイブリッドコントロールの継承を確立し、受領システム内での実装をサポートする証拠を提供します。

e. セキュリティコントロールの追加

  1. エンタープライズシステムを受領サイトに展開するために必要なセキュリティコントロールを追加します。
  2. 認可されたシステムの認可文書を必要に応じて更新します。これには、認可組織が提供する設置および構成要件文書、および構成の違いがある場合のテスト結果が含まれます。

f. 文書化された合意の実行

  • 認可組織との文書化された合意（例：覚書（MOU）、協定覚書（MOA）、サービスレベルアグリーメント（SLA））を実行し、システムのセキュリティ姿勢（セキュリティコントロールとサイバーセキュリティサービスプロバイダー（CSSP）を含む）の維持と監視を行います。この合意文書には、運用制約、運用環境、監視要件、セキュリティメンテナンス、脆弱性スキャン、IAVM遵守、ソフトウェアおよびコンポーネントのライフサイクル交換、役割と責任が含まれます。

g. 正式な使用認可の発行

  1. エンタープライズシステムの使用と運用を許可する正式な認可（ATU）を発行します。これは新しいATOではなく、認可されたシステムを受領システムに正式に組み込むものです。
  2. 複数のシステムが再利用されるが、異なる組織によって個別に所有、管理、維持される場合、それらは独立したインスタンスと見なされ、別々の認可が必要です。この場合、受領組織は利用可能な完了したテストおよび評価結果を最大限に活用できます。
  3. 実装文書（例：ATU）のコピーを認可AOに提供します。
  4. 認可されたエンタープライズシステムが受領組織のシステムと接続または運用されることを、更新されたシステムのATO文書に記載された許可された構成内でのみ、下位サイトに通知します。

h. システム認可および接続文書の更新

  • エンタープライズシステムの統合と接続を反映するためにシステム認可および接続文書を更新します。

i. 設置ガイドラインと構成要件の実装

  • 受領組織のすべての部分が主要アプリケーションの設置ガイドラインと適用可能なDoDセキュリティ構成要件を実装することを確認します。

j. 緩和策の実施と維持

  • 認可エンタープライズシステムのPOA&Mに記載された緩和策を実施および維持します。

4.3 コミュニティ – AOのコンソーシアム

複雑な認可環境（例：武器システム、エンタープライズシステム、クラウド、DevSecOps、連合環境、クロスサービス環境など）における相互承認の課題に対処するために、複数のステークホルダーとAO（認可責任者）が関与するAOコンソーシアム（以下「AO委員会」）メソッドが確立されました。この方法は、高いレベルのセキュリティ保証を維持しながら、評価および認可プロセスを効率化するためのツールとして機能します。

AO委員会の主な目的

AO委員会の主な目的は、認可の公平性を持つすべてのステークホルダーがシステムのリスク姿勢に関する洞察を得て、継続的な評価に参加し、システム/能力AOによって設定された継続的監視（CONMON）と優先事項を把握するためのメカニズムを提供することです。これにより、システム/能力の継続的な評価および認可プロセスの一環として、早期に相互承認の課題を特定および判断することができます。AO委員会は、すべての認可ステークホルダーがシステムAOのリスク評価に参加し、理解し、信頼するためのフォーラムと構造を提供し、それを自分たちのリスク許容度と環境に関連付ける能力を持ち、相互承認を成果として達成します。

AO委員会の活動と成果

インターコネクションサービスアグリーメント（ISA）の策定

  • 関係、役割と責任、認可境界および/またはエンタープライズサービス間のギャップを解消する手順、PPSM調整、CSSP識別、インシデント対応、技術および認可ステータスの変更に対応するための合意レビュー要件を定義します。

AO委員会を活用することの成果

成果1:システムのリスク評価の開発に参加するための構造化された方法を提供

  • すべてのステークホルダーが自分たちの認可境界に入るシステムを評価し、合意のための環境、前提条件、および制約を理解し、環境間で必要な合意と引き渡しを通じて作業します。
  • AO間のコミュニケーションを促進し、認可ステークホルダー間の信頼を高め、相互承認の能力を向上させます。
  • アーティファクトのコンプライアンスの狭い視点を超えて、意図とリスク管理の目標に焦点を当てることができます。

成果2:政府間のコラボレーションとサイバーセキュリティコミュニティの統合された取り組みに焦点を当てるメカニズムを提供

  • AO委員会は、通常よりも早くアクションとアイテムを扱い、判断し、主要なレベルで作業する簡単な方法を提供します。

成果3:テストコミュニティ（DOT&EおよびOT&E）がAO委員会に関与する場合

  • すべての当事者によって行われた評価を統合し、AOが判断を下す際に考慮するためのより包括的な入力を提供します。
  • テストコミュニティと提携することで、AOとシステム所有者は、時間の経過に伴ってリスク姿勢を積極的に評価でき、継続的な評価と認可アプローチの一環として分析を優先順位付けすることができます。
  • これにより、リスク姿勢とシステム/能力の保証に対する信頼が高まり、AO間のコラボレーションが強化され、運用上の文脈とリスク許容度に基づいて高優先度のリスクが分析結果によって支持される方法で優先順位付けされる保証が強化されます。

4.4 ワン・トゥ・ワン（アーティファクトの再利用）

ワン・トゥ・ワンシナリオ（アーティファクトの再利用）での相互承認の実行責任は、さまざまなステークホルダー間で共有されます。サイバーセキュリティアーティファクトの再利用を通じて相互承認を活用することにより、効率が向上し、評価プロセスが合理化されると認識されています。このシナリオでは、アーティファクトの交換に関与する認可組織（Granting Organization）および受領組織（Receiving Organization）の両方に主要な責任が発生します。以下は、両組織の責任を詳述したプロセス手順です。

相互承認契約に入る前のタスク

相互承認契約に入る前に、受領組織と認可組織の両方が以下のタスクを完了する必要があります：

  • リソースの提供責任者の特定:システムの管理および運用に必要なリソース（例：資金調達、ハードウェア、ソフトウェア、システムコンポーネントのライフサイクル交換、および人員）の提供責任者を特定します。
  • 相互承認の遵守と維持の確認:認可組織による相互承認の遵守と維持を確認します。
  • 受領組織の適切なセキュリティコントロールの実施:認可パッケージで要求される適切なセキュリティコントロールを受領組織が実施し、認可組織のPOA&Mによって指示された緩和戦略を適用します。
  • 相互接続システムが新しい（または集約された）脆弱性によって悪影響を受けないことの確認:相互接続システムが新しい（または集約された）脆弱性によって悪影響を受けないことを確認します。
  • 正しい構成の確認と維持:システムの正しい構成を確認し、維持します。
  • 完全なセキュリティ認可パッケージへのアクセスの確保:構成仕様を含む完全なセキュリティ認可パッケージへのアクセスをすべてのステークホルダーに確保します。
  • タスクの文書化:完了すべきすべてのタスクと関連する責任組織を、認可組織と受領組織の間の合意の結果として正式に文書化します。

4.4.1 認可組織の責任

相互承認のワン・トゥ・ワンシナリオにおいて、認可組織は以下の責任を負います。

セキュリティ認可パッケージと展開指示の提供:受領組織に現在のPOA&Mを含むセキュリティ認可パッケージと展開指示（またはそれへのアクセス）を提供します。

ライフサイクル中のシステム変更のコミュニケーション:システムのライフサイクル中のすべての変更（例：バージョンアップデート）を受領組織に通知します。

新しい発見の通知:新しい脅威、発見された脆弱性、その他の関連情報を認可ライフサイクル全体を通じて受領組織に通知します。

要件の収集:システム開発前に潜在的な活用組織から要件を収集し、標準化された構成の最も広範な使用を確保し、別個の認可を促進する変更を避けます。

連絡担当者の提供:情報を求める受領組織に対して連絡担当者（POC）を提供します。

再認可イベントの通知:再認可イベントの少なくとも6か月前に受領組織に通知し、受領組織からの意見を考慮します（影響を受ける組織からの受領確認が必要）。

使用計画の通知:システムの使用に影響を与える可能性のある計画（例：廃止、バージョン変更）を受領組織に通知します（影響を受ける組織からの受領確認が必要）。

MOU/MOAの終了を正当化する要因や条件の特定:MOU/MOAの終了を正当化する要因や条件を特定します。

パッチとアップデートの提供:DoDおよびUSCYBERCOMの要件とタイムラインに従ってパッチとアップデートをコミュニケーションし提供し、確立されたDoDおよびUSCYBERCOMのタイムライン内でエンタープライズ能力の認可ベースラインを維持します。

展開場所の管理:認可組織の認可追跡ツール内でシステムの展開場所を管理します。

継続的な監視とパッチ管理の確保:JFHQ-DODIN認定のCSSPを割り当て、継続的な監視、パッチ管理、IAVMプログラム、エンドポイントセキュリティサービス（ESS）監視、セキュリティ情報およびイベント管理（SIEM）監視、運用命令、POA&M、年次レビュー、四半期または月次の認可システムのレビューを確保します。

4.4.2 受領組織の責任

相互承認のワン・トゥ・ワンシナリオにおいて、受領組織は以下の責任を負います：

セキュリティ認可パッケージおよび展開指示の要求:現在のPOA&Mを含むセキュリティ認可パッケージと展開指示（またはそれへのアクセス）を認可組織から要求します。

認可決定のレビューおよび実装:認可組織のAOの認可決定をレビューし、必要な緩和策を講じてエンタープライズ能力を実装するために認可組織と協力します。

システムの展開:セキュリティ認可パッケージおよび展開指示に従った構成要件を使用してシステムを展開します。

継承されたセキュリティコントロールの提供:相互承認認可で要求されるすべての継承されたセキュリティコントロール、緩和策、またはサポート機能を提供します。

必要な認可の取得:組織のネットワーク内でシステムを接続および運用するために必要なすべての認可を取得します。

連絡担当者の提供:認可組織に対して単一の連絡担当者（POC）を提供します。

認可追跡ツールの更新:組織内で必要な認可追跡ツールを更新します。

必要なパッチおよび変更の実装:プロジェクト管理（PM）ガイダンスに従って必要なパッチおよび変更を実装します。

新しい発見の通知:新しい脅威、発見された脆弱性、または認可ライフサイクル全体を通じての類似情報を認可組織に通知します。

POA&Mに従った緩和策の実装:認可情報技術セキュリティPOA&Mに従った緩和策を実装します。

エンタープライズ能力ベースラインの維持:新しいガイダンスがリリースされるたびにIAVAおよびSTIGを適用し、適用できない更新や構成についてPOA&Mを更新してエンタープライズ能力ベースラインを維持します。

追加テストの必要性:すべてのRMF要件を満たすために追加のテストが必要な場合があります。ただし、システムは既存のセキュリティテストおよび評価結果を最大限に再利用しなければならず、認可組織と受領組織はすべての変更または追加に文書で同意する必要があります。

4.4.3 変更管理

相互承認のワン・トゥ・ワンシナリオ（アーティファクトの再利用）における変更管理は、認可されたシステムの管理と運用をサポートするために、すべての組織が技術的な連絡担当者（POC）をMOU、MOA、またはSLAの一部として特定する必要があります。以下のガイドラインに従って、変更管理を実施します。

連絡担当者（POC）の特定と変更通知

POCの特定

  • すべての組織は、認可されたシステムの管理と運用をサポートするために、技術的なPOCを特定します。

変更の通知

  • 認可システムまたはインストールされた環境のセキュリティ姿勢に影響を与える可能性のあるイベントについて、PMおよび元のAOに通知します。合意にはプロセス、タイミング、および通知要件が含まれる必要があります。

通知が必要なイベントの例

  • セキュリティインシデント、災害およびその他の緊急事態
  • システム構成の重大な変更（例：四半期ごとのSTIGリリース）
  • 重要なポジションの人員変更
  • 新しいユーザータイプ（例：外国人）
  • 運用環境の変更（例：オープンストレージ用にクリアされた施設がクリアされなくなった場合）
  • システムが接続されているネットワークがDATO（Authorization to Operateの拒否）を受けた場合
  • IAVMプログラムの報告
  • ライフサイクル交換要件（例：ベンダーによってサポートされなくなったオペレーティングシステムまたは機器ファームウェア）
  • エンタープライズツールまたは能力の変更（例：新しいESSアンチウイルスツールへの移行）

4.5 国防総省（DoD）および情報コミュニティ（IC）

DoDI 8510.01およびIntelligence Community Directive（ICD）503は、能力の移動に伴う構成変更に対する必要なテストを認識しつつ、評価のための相互承認のコンテキストを強調しています。DoDI 8510.01、RMF KS、およびICD 503は、相互承認に関して以下のことを主張しています：

相互承認に関する主張

a. 認可決定文書の提供

  • DoDおよびICの構成要素は、適切な認可決定文書を他のIC要素、DoDの非IC部分（例：軍部、戦闘指揮および防衛機関）、および連邦政府の非IC機関に提供します。

b. セキュリティ評価文書の提供

  • DoDおよびIC構成要素の認可責任者は、システムの適切なセキュリティ評価文書を他のIC要素、DoDの非IC部分、および連邦政府の非IC機関に提供します。

c. 他のコンポーネントのセキュリティ評価の受け入れ

  • DoDおよびIC構成要素は、以下の注意事項を伴い、他のコンポーネントによるシステムのセキュリティ評価を受け入れ、追加の検証または確認テストを要求または実施しません。
    • i. 構成の違いのテスト
      • DoDおよびICのコンポーネントは、新しい環境または異なる環境でシステムを使用することによって導入される構成の違いのみをテストします。
    • ii. 認可決定におけるセキュリティ評価の考慮
      • DoDおよびIC受領組織の認可責任者（AO）および認可責任者指定代表者（AODR）は、認可権限を行使するシステムの新しい部分または追加部分としてシステムを運用に投入する際に、認可組織のセキュリティ評価を考慮します。
    • iii. セキュリティコントロールオーバーレイの追加考慮
      • 情報A（INT-A）、INT-B、INT-C、クロスドメイン転送、クロスドメインアクセス、プライバシーなどのセキュリティコントロールオーバーレイに追加の考慮を与えます。

4.5.1 証拠の集合（BoE）の共有

IC（情報コミュニティ）およびDoD（国防総省）の各機関は、RMF（リスク管理フレームワーク）ドキュメントを管理するために、eMASSやXactaなどの主要なRMFインベントリツールスイートの一部を利用しています。これらのツールは、各機関がワークフロー、必要な情報要素、およびRMF実装内でのポリシーマッピングをカスタマイズできるようにします。

BOE.XMLの標準仕様

ICは、RMFインベントリツール内で証拠の集合（BoE）を保存するための標準として、Extensible Markup Language（XML）データエンコーディング仕様（BOE.XML）をリリースしました。この仕様は、CNSSI 1254および関連するポリシーと密接に整合しており、システムのセキュリティ認可と相互承認を促進するための関連情報を捕捉および伝達するために必要なデータフィールドを提供することを目的としています。

BoEの共有時の考慮事項

各ICおよびDoDのAO（認可責任者）およびCISO（最高情報セキュリティ責任者）は、自らのITエンタープライズの技術的複雑性、サイバーセキュリティの強みと弱み、およびミッションクリティカルな部分を理解しています。各AOは、サイバーセキュリティリスクと重要なミッションの実行の必要性とのバランスを適切に判断する必要があります。そのため、各機関間で異なる可能性のある全体的なサイバーセキュリティリスク項目を考慮し、相互認可のための決定を行う前に検討する必要があります。

相互承認のためのBoE交換を促進するための取り組み

5. 相互承認における各種AOの役割

相互承認の範囲を最も狭く維持するために、AO（認可責任者）には「認可（Granting）」および「受領（Receiving）」の2種類があることを確認しました。これは、DoDの指示（DoDI 8510.01、2022年7月19日付）に従い、「相互承認MOA/MOU」テンプレートで概説されています。このガイドラインは、相互承認を実践する際の基礎として適用されます。

標準オプション：ネイティブ環境でのシステム/アプリケーションの使用

コンポーネントは、各システム/アプリケーションをそのネイティブ環境で使用することが標準オプションです。この使用ケースは「共同使用（co-use）」と呼ばれ、認可組織による認可のみが必要です。認可組織は、共同使用システム、アプリケーション、およびクラウドサービスのサイバーセキュリティインシデントやPII（個人情報の漏洩）などの通知プロセスを確立する責任を負います。

他の環境でのシステム/アプリケーションの使用

1つの環境で認可され、運用されているシステムまたはアプリケーションが他の環境でインストールおよび使用される場合、サイバーセキュリティ相互承認は受領組織による評価および認可の標準的な方法となります。

受領組織のテストまたはリスク評価の前提条件

受領組織の環境でシステムをホストするためのテストまたはリスク評価を開始する前に、受領AOはシステムが他のAOによって認可されているかどうかを確認する責任を負います。現在の認可が存在する場合、受領AOおよびSCAはDoDI 8510.01で要求されるRMF文書に基づいて相互承認を進めます。

必要な文書がない場合の対策

DoDI 8510.01で要求される特定の文書が利用できない場合、受領AOはプログラムオフィスまたはシステム所有者から提供された証拠の集合を検討する必要があります。これには、以下の情報が含まれますが、これに限定されません：

  • エンタープライズ能力POA&M（未解決の脆弱性、正当性、および残留リスクのリスト）
  • 各「高」または「非常に高」リスク脆弱性の残留リスク評価
  • 認可境界図（ネットワーク図とも呼ばれる、プラットフォーム（建物、船、Humvee、指揮センターなど）およびエンクレーブのディフェンスインデプスセキュリティアーキテクチャを示す図）
  • データフロー図、インターフェース図、およびクロスドメインインターフェース（インターフェースの種類、データフローの方向、インラインセキュリティソリューションの仕様）
  • 各「高」または「非常に高」リスク脆弱性の影響および技術的な正当性
  • IAVM計画、運用継続計画（COOP）、災害復旧計画、およびインシデント管理計画
  • ハードウェアおよびソフトウェアリスト、関連するSTIGチェックリスト
  • 検証または確認テストの結果

その他の文書のリクエスト

認可組織のRMFパッケージに含まれていない文書のリクエストは、要求コンポーネントのCISOまたは同等の責任者によって承認された後、受領AOに転送される必要があります。

認可文書の共有

認可AOは、証拠の集合を提供する文書が受領組織と自由に共有されることを確保します。

受領組織の継続的な責任

受領組織は、認可組織がサポートしなくなったシステム、アプリケーション、またはクラウドサービスを引き続き使用する場合、完全な認可を確立および維持する責任を負います。

まとめ

相互承認における各種AOの役割は、協力と情報共有を通じて、システムのセキュリティと整合性を維持し、評価および認可プロセスの効率を高めることです。これにより、システムのセキュリティ姿勢が強固であり、DoDのサイバーセキュリティ目標と一致するようにします。

6. セキュリティ構成ガイドとセキュア構成

国防総省（DoD）内では、セキュリティ構成ガイドはSTIG（セキュリティ技術実装ガイド）やSRG（セキュリティ要件ガイド）などの形で提供されています。これらのガイドは、オペレーティングシステムやアプリケーションからクラウドサービスまで、特定の技術、プラットフォーム、および環境をセキュリティ保護するための詳細なステップバイステップの指示を提供します。これらのガイドに従うことで、コンポーネントは一貫したセキュリティ姿勢の基準を確立し、攻撃対象領域と潜在的な脆弱性を削減し、敵対者による悪用を防ぎます。

セキュリティガイドの役割と相互承認の促進

これらのガイドは、標準化され承認されたセキュリティ構成を提供することにより、相互承認を促進します。システムがこれらのガイドに記載された推奨設定に従う場合、他のコンポーネントはそのシステムのセキュリティを信頼しやすくなり、認可と展開プロセスが加速されます。これにより、運用が合理化され、DoD全体で一貫したセキュリティレベルが維持され、全体的なセキュリティ姿勢が強化されます。

SRGとSTIGの役割

SRGはさまざまな技術ファミリーおよび組織の高レベルの要件を定義し、STIGは特定の製品の詳細なガイドラインを提供します。STIGは、製品の技術分野に定義されたSRGの要件を検証、達成、継続的に遵守するための製品固有の情報を提供します。SRGおよびSTIGに含まれるセキュリティ要件は、一般に、すべてのDoD管理システム、DoDネットワークに接続されたすべてのシステム、およびDoDのために運用および/または管理されるすべてのシステムに適用され、要求されます。この要件は、クラウドサービスでシステムを構築するすべてのミッション所有者にも適用されます。

クラウドサービスにおけるセキュア構成ガイドの役割

クラウドサービスの場合、CSP（クラウドサービスプロバイダー）システムは、NIST SP 800-53セキュリティコントロール「CM-6構成設定」に従ってSTIG/SRGを使用して構成ガイダンスに準拠する必要があります。クラウドコンピューティングSRGのようなセキュア構成ガイドは、クラウド展開がDoDクラウドセキュリティ要件に一致することを確保する上で重要な役割を果たします。DoDがクラウド技術をますます活用するにつれて、これらのガイドはクラウドリソースを構成し、共有セキュリティ責任に対処し、コンプライアンス基準を満たすためのロードマップを提供します。これらのガイドに記載されたセキュア構成を採用することにより、DoDはCSO（クラウドサービスオファリング）への相互承認を自信を持って拡張し、ミッションクリティカルな運用をサポートする安全で機敏なクラウド環境を育成します。

7. eMASS相互承認検索

連邦機関間の相互承認活動を支援するために、eMASS（Enterprise Mission Assurance Support Service）には特定の機能があります。これらの機能の中には、eMASS「相互承認」ユーザー役割があり、各eMASSインスタンスごとに設定された数の相互承認ユーザーが、組織定義のエンタープライズ役割（例：AO、CISO、CIO）によって任命され、eMASS相互承認検索機能へのアクセスを許可されます。相互承認ユーザーは、この機能を利用して、他の組織によって既にRMF評価および認可を受けたシステムの再利用と受け入れを容易にするために、eMASS全体で相互承認システムを検索できます。

eMASS相互承認ジョブエイド

インターエージェンシーパートナー機能

  • 「インターエージェンシーパートナー」機能は、これらのコラボレーションまたは情報共有の取り組みをより良くサポートするために設けられています。組織は、eMASSシステム管理者および組織システム管理者を通じて、適切にユーザーにインターエージェンシーパートナー（IP）役割を割り当てることができます。インターエージェンシーパートナー役割は、ユーザーアカウントに付与できる「追加」役割として表示されます。eMASS Interagency Partner Job Aid (https://rmfks.osd.mil/rmf/HelpandResources/References/Reference%20Library/eMASS_InteragencyPartner_Job_Aid.pdf) は、外部eMASSインスタンスにあるシステムセキュリティ評価を検索および表示するのを支援することを目的としています。

システム登録と相互承認システムの検索

  • デフォルトでは、すべての新しいレコードは登録時に相互承認システムとしてリストされます。ユーザーがオプションを解除する場合、相互承認免除の正当性をリストする必要があります。システムは、「システム情報」ページを通じていつでも相互承認システムとして指定できます。相互承認が有効になっているシステムは、さまざまなeMASSインスタンス全体で特定のユーザーに表示されます。
  • 相互承認ユーザーは、eMASSホームページの「Search Reciprocity Systems」ハイパーリンクを使用して相互承認が有効になっているシステムを検索できます。検索基準を入力してシステムを検索した後、eMASSは結果を表示し、すべての利用可能なシステムと関連する組織をリストします。（システムが廃止されている場合、DATO認可ステータスがある場合、またはeMASS相互承認機能をオプトアウトしている場合は、検索結果に表示されません。）
  • システムが選択されると、ユーザーはシステム情報、セキュリティコントロール評価、POA&Mアイテム、アーティファクト、およびシステムレベルのレポートに対するビューオンリーアクセスを持ちます。この機能は、ユーザーが類似のシステムを見つけ、既存のRMF評価をより簡単に利用できるようにするために設計されています。

さらなる情報

8. エンタープライズAOのリスト

エンタープライズAO（認可責任者）の完全なリストは、以下のリンク先で提供されます：

また、このリストはeMASSの「ヘルプ」セクションにもアップロードされます。

エンタープライズAOのリストは、RMF（リスク管理フレームワーク）に関するポリシーおよびガバナンスを管理するための重要なリソースです。このリストは、相互承認プロセスを支援し、認可に関連するすべての当事者が必要な情報にアクセスできるようにするために役立ちます。

9. 相互承認の紛争解決におけるDoD CIOの役割

エンタープライズAOの完全なリストは、以下のリンク先で提供されます：

2024年3月に国防副長官（DSD）は、サイバーセキュリティテストと相互承認における協力文化の重要性を強調する覚書を発行しました（参考：i）。これは、サイバーセキュリティ基準を維持しながら革新的な能力の提供を加速するためのものです。DSDは、サイバーセキュリティリスクが非常に大きいと証明されない限り、テストの再利用と相互承認を実施することを期待しています。

協力的なサイバーセキュリティ相互承認文化

協力的なサイバーセキュリティ相互承認文化において、AOは互いに信頼し、他のAOが行ったリスク判断を受け入れて能力を展開することを認める傾向があります。したがって、受領AOは認可AOが行ったリスク判断を受け入れるために最大限の努力を払うべきです。ただし、決定を下す前に、受領AOは認可AOが提供したセキュリティ認可パッケージを徹底的にレビューする必要があります。内容は、セキュリティ姿勢、リスク評価、およびリスク判断の理由を明確に示すべきです。

受領AOは、RMF KSで定義されているように、セキュリティ姿勢、システムのリスク評価、およびリスク判断の理由を十分に理解していない内容、またはエンクレーブまたはサイトへの過剰なリスクがある場合、他の組織との相互承認への参加を拒否する権利があります。ただし、受領AOは、この拒否を10営業日以内に認可組織のAOに文書で報告する必要があります。拒否が発生した場合、両組織は可能な限り、ATOパッケージの合意に向けて作業を続けます。AOが再利用と相互承認に関して合意に達することができない場合、以下の解決プロセスを使用して紛争の解決を図ります：

  1. AOレベルでの解決の試み:相互承認の拒否に起因する紛争が発生した場合、AOレベルで解決を試みるべきです。これには、認可AOが新しい評価を実施することなどが含まれます。
  2. RMF TAG事務局の通知:AOレベルで紛争が解決できない場合、RMF TAG事務局に通知し、RMF TAG議長が適切に紛争を仲介することを試みます。
  3. AO評議会へのエスカレーション:RMF TAG議長が解決に至らない場合、この問題はDoD CISOが議長を務めるAO評議会に持ち込まれ、紛争の仲裁を行います。

DoD CIOの戦略的役割

紛争の仲裁に加えて、DoD CIOは相互承認の政策とフレームワークの形成において戦略的な役割を果たします。これには、標準化されたプロセスの推進、ベストプラクティスの採用の促進、他の機関や組織からの信頼された評価を活用することの重要性の擁護が含まれます。戦略的な指針を提供し、一貫したアプローチを促進することにより、DoD CIOは、複雑化する脅威の中で組織全体のサイバーセキュリティのレジリエンスと効果を大幅に向上させるのに貢献します。

投稿者: 二本松 哲也

SPbD:Security&Privacy by Design Founder ー OWASP Member ー ITは人々の生活をあらゆる面でより良い方向に変化させること ー 競争原理から共創原理へ