--- title: 米国戦争省の新しいリスク管理フレームワーク（CSRMC概説） tags: author: [MUNEAKI NISHIMURA](https://image.docswell.com/user/nishimunea) site: [Docswell](https://www.docswell.com/) thumbnail: https://bcdn.docswell.com/page/VJNYVGN178.jpg?width=480 description: 米国戦争省の新しいリスク管理フレームワーク（CSRMC概説） by MUNEAKI NISHIMURA published: July 28, 26 canonical: https://image.docswell.com/s/nishimunea/K7N19G-CSRMC --- # Page. 1 ![Page Image](https://bcdn.docswell.com/page/VJNYVGN178.jpg) ⽶国戦争省の新しいリスク管理フレームワーク（CSRMC概説） 2026年7⽉28⽇ ISACA東京⽀部 情報セキュリティ研究会 ⻄村 宗晃 nishimunea@gmail.com # Page. 2 ![Page Image](https://bcdn.docswell.com/page/YE9P6WRYJ3.jpg) Disclaimer 本資料は、⽶国戦争省（DoW）が2025年9⽉24⽇に公表したCSRMCに関するニュースリリースを基に、筆者の考察を加 えたものです。内容の正確性を保証するものではありませんので、最新および正確な情報についてはDoWの公式発表をご参 照ください。 本資料に記載されている意⾒や⾒解は筆者個⼈に帰属するものであり、筆者が所属する組織・団体の公式な⾒解を⽰すも のではありません。 # Page. 3 ![Page Image](https://bcdn.docswell.com/page/GE8DZNWKED.jpg) https://www.war.gov/News/Releases/Release/Article/4314411/department-of-war-announces-new-cybersecurity-risk-management-construct/ # Page. 4 ![Page Image](https://bcdn.docswell.com/page/LELMDPNP7R.jpg) https://www.war.gov/News/Releases/Release/Article/4314411/department-of-war-announces-new-cybersecurity-risk-management-construct/ # Page. 5 ![Page Image](https://bcdn.docswell.com/page/4JMYP4X2JW.jpg) 1. CSRMCとは # Page. 6 ![Page Image](https://bcdn.docswell.com/page/PJR91WN579.jpg) CSRMC（Cybersecurity Risk Management Construct） 概要 DoWが2025年9⽉に公表した、新たなサイバーセキュリティ・リスク管理フレームワーク（RMF） ⽬的 既存のRMFを動的・⾃動化・継続的な枠組みへと移⾏させ、現代戦に求められる速度でサイバー防御を可能とすること 構成 5段階のシステム開発運⽤ライフサイクルと、10の基本原則（Tenets）で構成（※詳細は後述） # Page. 7 ![Page Image](https://bcdn.docswell.com/page/PEXQYPNXJX.jpg) 既存のRMF（NIST SP800-37 + CNSSI No.1253） NIST SP 800-37※1のRMFプロセスにCNSSI No.1253※2を組み合わせ、国家安全保障システム（NSS）に最適化した プロセスを適⽤。分類および選択フェーズではFIPS 199※3のHWM（High-Water Mark）の代わりにC-I-Aの個別格付け を採⽤。NIST SP 800-53※4からNSS向け管理策および制御パラメータを定義する。管理策の選定に際しては、NSS組織 の内部脅威の存在、および標的型攻撃（APT）が既にNSS内に潜伏している可能性を前提条件としている 最⻑3年（認可期間満了 → 再認可） NIST SP800-37 準備 分類 選択 実装 評価 認可 監視 Prepare Categorize Select Implement Assess Authorize Monitor 差し替え CNSSI No.1253 • FIPS 199のHWMに代わるC-I-A個別格付け • NIST SP 800-53からNSS向け管理策を選定 • 上記管理策に対し、NSS向けの組織定義パラメータ値を設定 • システム特性に応じて管理策を補完・具体化するオーバレイの導⼊ ※1 https://csrc.nist.gov/pubs/sp/800/37/r2/final ※2 https://www.dcsa.mil/portals/91/documents/ctp/nao/CNSSI_No1253.pdf ※3 https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.199.pdf ※4 https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final # Page. 8 ![Page Image](https://bcdn.docswell.com/page/3EK93DN9ED.jpg) 既存のRMFにおける改善点 既存のRMFは、静的なチェックリストと⼿作業のプロセスに過度に依存しており、運⽤上のニーズやサイバー⽣存性の要件が ⼗分に組み込まれていなかった。認可プロセスにおいても、3年に⼀度の特定時点におけるスナップショット評価にとどまり、評価 の頻度が不⼗分であった。結果として、NSSは⾼度な敵対者に対して脆弱な状態に置かれ、安全な能⼒を迅速に現場へ届 ける⾜枷となっていた 最⻑3年（認可期間満了 → 再認可） NIST SP800-37 評価の頻度が不⼗分 準備 分類 選択 実装 評価 認可 監視 Prepare Categorize Select Implement Assess Authorize Monitor 差し替え CNSSI No.1253 静的なチェックリストと⼿作業 のプロセスに過度に依存 • FIPS 199のHWMに代わるC-I-A個別格付け • NIST SP 800-53からNSS向け管理策を選定 • 上記管理策に対し、NSS向けの組織定義パラメータ値を設定 • システム特性に応じて管理策を補完・具体化するオーバレイの導⼊ # Page. 9 ![Page Image](https://bcdn.docswell.com/page/L73WGRV975.jpg) 参考）組織定義パラメータとオーバレイ SP 800-53の各管理策には、⾃組織が運⽤に応じて値を定めるパラメータ（組織定義パラメータ）が⽳埋めの形で⽤意 されている。DoWでは、これをCNSSI No.1253が定めるパラメータ値で⽳埋めし、全システムの共通基準としている。さらに、 システム特性に応じて管理策の追加や除外、パラメータの具体化を⾏う仕組みがオーバレイである。⼀例として、DoD Zero Trust Overlays※1では、ゼロトラストの概念に基づき、各管理策を厳格なパラメータ値に調整している SP 800-53管理策 CNSSI No.1253 AC-17(9) Disconnect / Disable Access （Time Period ）にリモートアクセスを 切断・無効化すること DoD Zero Trust Overlays Security Control Parameter Values for NSS 定義 Time Period = ※1 https://dodcio.defense.gov/Portals/0/Documents/Library/DoD-ZTStrategy.pdf ※2 機密性や完全性がHighに分類されるシステムの場合 10分以内※2 Overlay-specific Parameter Values 上書き Time Period = 即時 # Page. 10 ![Page Image](https://bcdn.docswell.com/page/87DK1Y88JG.jpg) CSRMCにおける10の基本原則（Tenets） https://media.defense.gov/2025/Sep/24/2003808111/-1/-1/1/DOD-CIO-CYBER-SECURITY-RISK-MANAGEMENT-CONSTRUCT-STRATEGIC-TENETS.PDF # Page. 11 ![Page Image](https://bcdn.docswell.com/page/VJPKQ68WE8.jpg) CSRMCにおける10の基本原則（Tenets）に基づく既存RMFの改善⽅針 ⾃動化 プロセスの効率化、ヒューマンエラー削減、効率性向上を通じた ⾃動化により、リスク管理を強化 重要管理策 トレーニング RMF実務者向けに役割別研修プログラムを強化し、パフォーマ ンスの⼀貫性、サイバーセキュリティ知識、標準を確保 組織全体と継承 特定された重要管理策の遵守と適応型リカバリ戦略により防御 を強化し、業務継続性の確保と機密資産の保護を実現 セキュリティ管理策・ポリシー・リスクの共有により、実績のあるフ レームワークの導⼊促進、コンプライアンス負担の軽減、運⽤の ⼀貫性を維持 継続的モニタリング、管理、および運⽤承認 運⽤化・実⽤化 継続的モニタリングを通じ、脅威・脆弱性・コンプライアンスギャッ プのリアルタイムな可視化を提供 DevSecOps 脅威検知、インシデント対応、コンプライアンス管理、プロアクティ ブなモニタリングを通じ、進化する脅威への防御を強化 相互承認 継続的な開発・テスト・デプロイを通じたセキュリティと⾃動化の 統合により、安全な配信を加速 互いのセキュリティ評価を受け⼊れてシステムリソースを再利⽤、 または評価済みセキュリティポスチャを相互承認して情報共有を 促進 サイバー⽣存性 サイバーセキュリティ評価 強⼒な暗号化、多要素認証、継続的モニタリング、インシデント 対応計画により、サイバー脅威・障害・データ侵害から保護 脅威に基づくテスト⼿法とミッション適合型リスク管理プロセスを 統合し、包括的なサイバーセキュリティ評価プログラムを構築 # Page. 12 ![Page Image](https://bcdn.docswell.com/page/2EVV53N9EQ.jpg) 2. CSRMCにおける開発運⽤ライフサイクル # Page. 13 ![Page Image](https://bcdn.docswell.com/page/57GL63K4EL.jpg) CSRMCにおける開発運⽤ライフサイクル https://media.defense.gov/2025/Sep/24/2003808112/-1/-1/1/DOD-CIO-CYBER-SECURITY-RISK-MANAGEMENT-CONSTRUCT.PDF # Page. 14 ![Page Image](https://bcdn.docswell.com/page/4EQY45NRJP.jpg) PHASE 1: DESIGN（設計） 既存RMFの準備・分類・選択に相当し、任務に必要な能⼒に基づき要件・管理策を選定する。従来のサイバーセキュリティ要 件に加え、サイバー⽣存性（Cyber Survivability）要件が加味される点が特徴。あわせて、ミッション・システムオーナー、 PM、エンジニア、CSSP（DoWの情報ネットワークにおける監視・防御の専⾨組織）からなるチームを本段階で組成。監視や 防御の担当組織を設計当初から参画させることが重要となる # Page. 15 ![Page Image](https://bcdn.docswell.com/page/KJ4WQ9GQ71.jpg) PHASE 2: BUILD（構築） 既存RMFの実装フェーズに相当し、選定した要件・管理策をシステムに実装する。開発・下位環境での構築を経て、システム が初期運⽤能⼒（IOC）に達した段階から、システムのデータを、監視設備（ISCM）に送出する。本番運⽤に先⽴って 監視のパイプラインに接続し、データを流し始める点が特徴 # Page. 16 ![Page Image](https://bcdn.docswell.com/page/LE1YPKDL7G.jpg) PHASE 3: TEST（テスト） 既存RMFの評価フェーズに相当する。システムが全機能を展開し、完全運⽤能⼒（FOC）に達した時点で、システムのアセ スメントと指摘事項の是正対応を⾏う。評価は⽂書ベースではなく、⾃動テストの結果レポートやダッシュボードの分析を通 じて実施する。あわせて、監視内容が任務遂⾏能⼒に合致するよう、ISCMの調整を⾏う # Page. 17 ![Page Image](https://bcdn.docswell.com/page/GEWG2DYQJ2.jpg) PHASE 4: ONBOARD（受⼊） 既存RMFの認可フェーズに相当する。システムの運⽤承認を経て本番環境へ展開するとともに、CSSPが当該システムを ISCMに受け⼊れ（オンボード）、継続監視の対象とする。オンボードには、完全受け⼊れのほか、追加リスクレビューなどを伴 う部分受け⼊れなどの形態が存在する。デプロイと同時に⾃動化された監視が開始され、動的・継続的な運⽤承認の維持 に移⾏する # Page. 18 ![Page Image](https://bcdn.docswell.com/page/47ZLDGX3J3.jpg) PHASE 5: OPERATIONS（運⽤） 既存RMFの監視フェーズに相当する。運⽤中のシステムをリアルタイムのダッシュボードと⾃動アラートにより継続的に監視し、 受⼊フェーズで得たcATO（継続的運⽤承認）を維持する。⾼リスクのアラートは速やかにエスカレーションされ、CSSPの監 視責任者（Watch Officer）が必要に応じてDoWの情報ネットワークからシステムの切断（cATOの取消に相当）を⾏ う。事前に定めたプレイブックに沿って、リスクを継続的に管理し続ける点が特徴 cATO（継続的運⽤承認） # Page. 19 ![Page Image](https://bcdn.docswell.com/page/YJ6W1Y4ZJV.jpg) ここまでのまとめ • CSRMCは、既存のRMFに代わるDoWの新たなサイバーセキュリティリスク管理フレームワーク • ⾃動化や継続的監視を含む10の基本原則（Tenets）に基づき、現代戦に求められるスピードでサイバー防御を実現 • 本資料の執筆時点（2026年7⽉）では、公開されている情報は限定的 • ⾃動化・継続的監視の具体的⼿法を読み解く鍵は、cATO（継続的運⽤承認）の仕組み # Page. 20 ![Page Image](https://bcdn.docswell.com/page/GJ5M4GQ9J4.jpg) 3. CSRMCを⽀えるcATOの仕組み # Page. 21 ![Page Image](https://bcdn.docswell.com/page/9E29VYP57R.jpg) cATO（Continuous Authorization to Operate） 2022年に公表※1された、新しい運⽤承認の仕組み。既存RMFにおいて、最⻑3年ごとに⾏われていた再認可のプロセスを置 き換え、継続的監視（ConMon）・能動的サイバー防御（ACD）・DevSecOps／サプライチェーンの能⼒が維持されてい ることを前提に、リアルタイムかつ継続的な評価に基づき、運⽤承認を維持し続ける⽅式への転換を可能とする 継続的運⽤承認 NIST SP800-37 cATO※2 準備 分類 選択 実装 評価 認可 監視 Prepare Categorize Select Implement Assess Authorize Monitor • 評価者の特定と訓練 • 評価基準とスコアリングの策定 • 技術、⼈、 プロセスの評価 ※1 https://dodcio.defense.gov/Portals/0/Documents/Library/20220204-cATO-memo-Signed-Cleared.pdf ※2 https://dodcio.defense.gov/Portals/0/Documents/Library/cATO-EvaluationCriteria.pdf?ver=A8tLIfPjmp3RpemU6JOhJw%3d%3d • cATOの承認 • リスクの継続監視 • 問題検知時の対応 # Page. 22 ![Page Image](https://bcdn.docswell.com/page/D7Y43G56EM.jpg) cATOの運⽤承認評価基準 cATOの継続的な運⽤承認は、先述のConMon・ACD・DevSecOps／サプライチェーンの能⼒により判断※1,2される。 評価は各能⼒について、技術（DSOP︓DevSecOpsプラットフォーム）・組織（プロセス）・⼈の観点で⾏われる。技 術評価では、DoWのDevSecOpsリファレンス設計への準拠が求められる。既にcATO承認済みのDSOPを利⽤する場合、 準拠済みの管理策を継承でき、DSOP上で開発される個々のシステムのcATO取得にかかる負担を下げることが可能となる 継続的監視（ConMon） 能動的サイバー防御（ACD） DevSecOps／サプライチェーン 技術（DSOP） ⾃動化された監視基盤とダッシュ ボードを通じて、機械可読な証 跡をほぼリアルタイムに⽣成・分 析・表⽰ ⾃動化により証跡とアラートを⽣ 成し、不正コンテナを⾃動停⽌。 クラウド環境ではCNAPPの導⼊ が必須 承認済みDevSecOpsリファレン ス設計に準拠したDSOPの利⽤ により、サプライチェーンの保護・ ポリシー・ゲート管理の強制 組織（プロセス） リスク管理戦略を定め、脅威・脆 弱性などを継続的に監視。監査 ログの分析などを通じ、監視プロ セスを定期的に検証 第三者による侵⼊テストの実施 に加え、継続的かつ⾃動的なサ イバー防御耐性評価の戦略策 定と予算の確保 IaCなどを⽤いて環境ドリフトを 防⽌。各ゲートの条件やアラート 発⽣時、リスク許容度超過時の 対応⼿順の策定 ⼈（チーム） DoDM 8140.03認定のセキュ リティ専⾨家が全期間にわたり関 与。検知された脆弱性やアラー トへの対応体制の確⽴と訓練 CSSPを開発チームに統合。 ACDの防御アプローチの理解に 基づき、侵⼊検知・対応能⼒の 実効性の確保 組織図に基づき、職務分離と最 ⼩権限原則の適⽤。机上演習 などを通じて、全関係者が DevSecOpsプロセスに習熟 ※1 https://dodcio.defense.gov/Portals/0/Documents/Library/cATO-EvaluationCriteria.pdf?ver=A8tLIfPjmp3RpemU6JOhJw%3d%3d ※2 https://dodcio.defense.gov/Portals/0/Documents/Library/DoDCIO-ContinuousAuthorizationImplementationGuide.pdf # Page. 23 ![Page Image](https://bcdn.docswell.com/page/VENYVG41J8.jpg) DSOP（DevSecOpsプラットフォーム）のリファレンス設計 イ ン フ ラ ・ ソ フ ト ウ ェ ア フ ァ ク ト リ （ SWF ） ・ ア プ リ ケ ー シ ョ ン の 3 層 で 構 成 さ れ る 。 Cloud Native Computing Foundation（CNCF）認定のKubernetesを標準構成とすることにより、ベンダーロックインを避け、クラウド・オンプレミスなど 様々な環境へ同⼀構成で展開可能としている。開発時に⽤いるCI/CDパイプラインに加え、実⾏環境でコンテナ単位のゼ ロトラストを実現するためのサイドカーの採⽤などが必須とされる アプリケーション テスト環境 結合環境 本番環境 ワークフロー 構築 SWF インフラ SAST／単体テスト アーティファクト公開 各種環境へのデプロイ DevSecOpsサービス コンテナサービス 運⽤サービス • コード・アーティファクト管理 • パイプライン制御 • ビルド／テスト／デリバリー • 3 rdパーティツール連携 • Kubernetes • デプロイ • スケーリング • ログ取得 • モニタリング DoWクラウド DoWデータセンター https://dodcio.defense.gov/Portals/0/Documents/Library/DoD%20Enterprise%20DevSecOps%20Reference%20Design%20%20CNCF%20Kubernetes%20w-DD1910_cleared_20211022.pdf サイドカーコンテナ セキュリティスタック • ログエージェント • コンテナポリシー強制 • ランタイム防御 • サービスメッシュプロキシ • 脆弱性管理 • Pod単位のゼロトラスト ベアメタルサーバー # Page. 24 ![Page Image](https://bcdn.docswell.com/page/Y79P6WQYE3.jpg) 参考）承認済みDevSecOpsマネージドサービス “Platform One” ⽶空軍が運営するDoW初の承認済みDevSecOpsマネージドサービス。ソースコードを管理するRepo One、ハードニング済 みコンテナイメージを管理するIron Bank、SWFの展開を⾃動化するIaC/CaC（Helmチャート）のBig Bang、Big Bang で構築されたマルチテナント型PaaSのParty Busから構成される。利⽤者はParty Busを⽤いることで、CI/CDから本番運 ⽤までの環境と管理策を継承でき、個々のシステムのcATO取得にかかる負担を下げることができる https://docs-bigbang.dso.mil/latest/bigbang-training/docs/1_bigbang-101/p1-introduction/#how-p1-services-fit-together # Page. 25 ![Page Image](https://bcdn.docswell.com/page/G78DZNGK7D.jpg) 参考）ハードニング済みコンテナレジストリ “Iron Bank” Platform Oneが運営するハードニング済みコンテナイメージのレジストリ。Dockerfileを専⽤のパイプラインでビルドし、脆弱性 スキャンなどを⾏なった上で公開している。コンテナイメージの利⽤者は、リファレンス設計への準拠状態とその評価結果を継承 できる。以下のUbuntu Linuxの例では、STIGを適⽤済みのイメージが公開されており、STIGへの準拠状態の監査と⾃動 是正が継続的に⾏われるようになっている DISAのSTIGに準拠 https://repo1.dso.mil/dsop/canonical/ubuntu/pro-cis-stig-22.04/ubuntu-pro-cis-stig-22.04/-/tree/development # Page. 26 ![Page Image](https://bcdn.docswell.com/page/L7LMDPGPJR.jpg) 4. 管理策の⾃動評価を可能とするSTIGの仕組み # Page. 27 ![Page Image](https://bcdn.docswell.com/page/4EMYP4Q2EW.jpg) STIG（Security Technical Implementation Guides） ⽶国国防情報システム局（DISA）が発⾏する、製品ごとのセキュリティ設定基準。SP 800-53の管理策やSRG （Security Requirements Guide）が⽰す技術分野共通の要件を、各製品に固有の具体的な設定値と確認⼿順ま で落とし込んだもので、OS・ミドルウェア・コンテナなど著名製品のSTIGがDISAのWebサイトで公開されている。XCCDF形式 で提供され、判定ロジックを含むSCAP版が⽤意された製品は、OpenSCAPなどのツールによる⾃動監査が可能 著名製品のSTIGが ダウンロード可能 https://www.cyber.mil/stigs/downloads # Page. 28 ![Page Image](https://bcdn.docswell.com/page/PER91W85J9.jpg) 参考）Ubuntu LinuxのSTIG実装 STIGはXCCDF形式で記述され、監査ルールごとに深刻度、タイトル、管理策との対応関係を⽰すCCI、是正⽅法、監査⽅ 法への参照が定義されている。参照先には機械可読な監査ロジックが記述されており、以下の例ではOSにtelnetdが存在し ないことが監査通過の条件となっている <xccdf:Group id="xccdf_mil.disa.stig_group_V-270647"> <xccdf:Rule severity="high"> <xccdf:title> Ubuntu 24.04 LTSにtelnetパッケージがインストールされていてはならない。 </xccdf:title> 監査ルール名 <xccdf:ident> CCI-000197 </xccdf:ident> 管理策との対応関係 <xccdf:fixtext> 以下のコマンドを実⾏して、telnetパッケージを削除します: $ sudo apt remove telnetd </xccdf:fixtext> 是正⽅法 <xccdf:check> <xccdf:check-content-ref name=" oval:mil.disa.stig.ubuntu2404os:def:270647 " 監査⽅法への参照 /> </xccdf:check> <dpkginfo_test check_existence="none_exist" check="all"> <object object_ref="oval:mil.disa.stig.linux:obj:23832600"/> <name>telnetd</name> https://www.stigviewer.com/stigs/canonical_ubuntu_2404_lts/2026-05-14/finding/V-270647 監査ロジック # Page. 29 ![Page Image](https://bcdn.docswell.com/page/P7XQYP8XEX.jpg) SP 800-53の管理策とSTIGの関係 STIGの各ルールには、CCI（Control Correlation Identifier）が付与されており、DISAが公開するCCI Listを介して SP 800-53の管理策と対応付けられる。これにより、⾃動監査で検出された設定不備を管理策の準拠状況へ変換でき、 RMFツール（eMASSなど）上で、STIGの不適合事項がSP 800-53管理策の⾮準拠事項として可視化可能となる スキャン結果（CKL/CKLB形式） CCI List（XML形式） https://www.youtube.com/watch?v=nU_RzMg6xhI RMFツール（eMASSなど） # Page. 30 ![Page Image](https://bcdn.docswell.com/page/37K93DK97D.jpg) 参考）MITRE Heimdallによる管理策準拠状況の可視化の例 SP 800-53管理策のSC-8が⾮準拠 https://saf.mitre.org/apps/heimdall # Page. 31 ![Page Image](https://bcdn.docswell.com/page/LJ3WGRZ9J5.jpg) 5. まとめ # Page. 32 ![Page Image](https://bcdn.docswell.com/page/8JDK1YR8EG.jpg) まとめ DoWのRMFはcATO、CSRMCを経て、⼈⼿による特定時点の評価から、⾃動化を前提とした継続的なリスク管理へと移⾏ しつつある。また、これを⽀える技術基盤として、DevSecOpsのリファレンス設計やSTIGなどの機械可読な基準、⾃動監査の 仕組みの整備が進む。同様の⽅向性は軍事分野に限らず、⽶国連邦政府のクラウドセキュリティ認可制度であるFedRAMP などにも⾒られ、今後の認可の在り⽅を把握する上での重要な参考情報となりえる 既存のRMF cATO（2022年情報公開） CSRMC（2025年情報公開） 認可⽅針 ⼀定期間（最⻑3年）ごとに 運⽤承認を再取得 初回の運⽤承認はRMFと同様。 セキュリティ状態の継続的評価 に基づき、運⽤承認を継続 cATOを前提とし、運⽤開始時点 から継続的認可を開始 評価⽅法 静的なチェックリストに基づく 特定時点での評価 技術・組織・⼈の能⼒を 動的スコアリング評価 ⾃動テストの結果とダッシュボードの 分析に基づく動的評価 期限内に是正 スコア未達を契機にレビューを実施。 レビュー結果に基づきcATOを取消 （既存RMFの運⽤承認に縮退） 監視責任者の判断の下、 DoWの情報ネットワークから システムを切断 問題検知時の対応