はじめに
CISSPを学習する中で、様々なフレームワークが登場するため、自身の整理を目的に記事にまとめていきます。
今回は RMF（Risk Management Framework） を取り上げます。
なお、記事の執筆・調査にはAIを活用しているため、内容に誤りが含まれている可能性があります。
参考程度にご覧いただき、正確な情報は一次ソース（NIST公式ドキュメント等）でご確認ください。
RMFとは何か？
RMF（Risk Management Framework） は、組織が情報システムのセキュリティリスクとプライバシーリスクを体系的に管理するための、構造化されたプロセスです。
主なドキュメントは NIST SP 800-37 で、セキュリティ管理策の詳細カタログである NIST SP 800-53 と組み合わせて使用されます。
| ドキュメント | 役割 |
|---|---|
| NIST SP 800-37 | RMFの実施手順・プロセスを定義 |
| NIST SP 800-53 | RMFで選択・実装するセキュリティ管理策のカタログ（1,000超の管理策） |
誕生の背景と歴史
なぜ生まれたのか
2002年に米国で制定された FISMA（連邦情報セキュリティ管理法） は、連邦政府機関に対して情報システムのセキュリティ確保を義務付けました。
この法律を受け、NISTが具体的なリスク管理の標準・ガイドラインの策定を担うことになった経緯があります。
それ以前、米国防省では DIACAP（DoD情報保証認定・認可プロセス） という独自の枠組みが使われていましたが、政府全体で統一されたアプローチが求められるようになったようです。
誰が作ったか
RMFは 合同タスクフォース（JTF） によって開発されました。JTFのメンバーは以下の通りです。
- NIST（National Institute of Standards and Technology：米国国立標準技術研究所）
- IC（米国インテリジェンスコミュニティ）
- DoD（米国防省）
- CNSS（国家安全保障システム委員会）
米国政府の主要なセキュリティ関連機関が一堂に会して策定した、官民共通の標準ということになります。
年表
| 時期 | 出来事 |
|---|---|
| 2002年 | FISMA制定。NISTにリスク管理標準の策定を義務付け |
| 2010年2月 | NIST SP 800-37 初版公開（RMFの正式スタート） |
| 2018年12月 | NIST SP 800-37 Rev.2 公開（「Prepare」ステップを追加し7ステップ化） |
| 2025年8月 | NIST SP 800-53 Release 5.2.0 公開（最新版） |
RMFのコアコンセプト
RMFの本質は 「リスクを一度評価して終わり」ではなく、システムのライフサイクル全体を通じてリスクを継続的に管理する という考え方です。
RMFの定義（NIST SP 800-37より）
セキュリティ・プライバシーリスク管理のための、規律ある・構造化された・柔軟なプロセス。情報セキュリティの分類、管理策の選定・実装・評価、システムの運用承認（ATO）、継続的モニタリングを含む。
3つのキーワードで整理すると頭に入りやすいと思います。
| キーワード | 意味 |
|---|---|
| 統合（Integration） | セキュリティをシステム開発ライフサイクル（SDLC）の最初から組み込む |
| 継続（Continuous） | 一度承認したら終わりではなく、常時モニタリングして変化に対応する |
| 階層（Tiered） | 組織全体・ミッション/業務・システムの3階層でリスクを管理する |
7つのステップ詳解
RMFはRev.2以降、以下の7ステップで構成されます。
① Prepare（準備）
Rev.2で追加された最初のステップ
RMFを効果的・効率的に実行するための組織的な準備を整えるステップです。
- リスク管理の役割・責任者の定義
- 組織全体のリスク許容度の設定
- 共通管理策の特定
- 継続的モニタリング戦略の策定
ポイント： このステップが追加されたことで、「システム単位の対応」から「組織全体のリスク戦略」へと視野が広がりました。Rev.2以前の6ステップ版を参照している資料もあるので注意が必要です。
② Categorize（カテゴリ化）
システムが処理・保存・伝送する情報のセキュリティカテゴリを決定するステップです。
評価軸はCIAトライアド（機密性・完全性・可用性）で、それぞれに影響レベルを設定します。
| 影響レベル | 説明 |
|---|---|
| Low（低） | 影響が限定的 |
| Moderate（中） | 重大な影響 |
| High（高） | 壊滅的または重大な影響 |
参照規格： FIPS 199
③ Select（選択）
カテゴリ化の結果をもとに、適切なセキュリティ管理策を選択するステップです。
NIST SP 800-53のカタログから、影響レベルに応じたベースライン管理策を選定し、組織の状況に合わせてテーラリング（調整）します。
管理策の種類：
- System-Specific（システム固有）：特定のシステムだけに適用
- Common（共通）：複数システムが継承できる管理策
- Hybrid（ハイブリッド）：上記の組み合わせ
④ Implement（実装）
選択した管理策を実際にシステムに実装するステップです。
- 管理策の具体的な実装
- 実装内容をセキュリティ計画・プライバシー計画に文書化
⑤ Assess（評価）
実装した管理策が正しく・効果的に機能しているかを独立した立場で評価するステップです。
- 評価は通常、独立した評価者（3PAO等）が実施
- 発見された欠陥は POA&M（Plan of Action and Milestones） として記録・管理
⑥ Authorize（承認）
評価結果を踏まえ、上位の責任者（Authorizing Official）がシステムの運用を承認するステップです。
これを ATO（Authority to Operate：運用承認） と呼びます。残存リスクが許容範囲内であると判断された場合にATOが付与されます。
ポイント： ATOは「永続的な安全保証」ではなく、「現時点での許容判断」という点が重要
⑦ Monitor（モニタリング）
ATOを取得した後も、継続的に管理策の有効性を確認し、環境変化に対応するステップです。
- セキュリティ状態の継続的な監視
- 変更管理（システム変更時の再評価）
- 定期的なコントロールアセスメント
- インシデント対応・報告
ポイント： このステップが「ループの始まりに戻る」性質を持つことで、RMFが単発のプロセスではなく継続的なサイクルになっている。
架空シナリオで理解するRMF
抽象的なままだとイメージしにくかったので、AIに架空のシナリオを作ってもらって整理してみました。
🏥 シナリオ：地域病院の電子カルテシステム導入
架空の「さくら総合病院」が、新たに 電子カルテシステム（EHR） を導入するケースで考えてみます。
① Prepare（準備）
IT部長の田中さんが、病院全体のリスク管理方針を策定します。
「患者データ漏えいは経営危機に直結する。個人情報に関わるシステムは最優先で管理する」とリスク許容度を定め、CISO（情報セキュリティ責任者）を任命します。
② Categorize（カテゴリ化）
EHRが扱う情報を分析します。
| 情報の種類 | 機密性 | 完全性 | 可用性 |
|---|---|---|---|
| 患者氏名・連絡先 | High | Moderate | Moderate |
| 診断・処方情報 | High | High | High |
| 請求情報 | Moderate | High | Moderate |
最も影響度が高い分類が採用されるため、このシステムは 「High」 に分類されます。
③ Select（選択）
「High」ベースラインに対応する管理策をNIST SP 800-53から選択します。例えば：
- AC-2（アカウント管理）：医師・看護師・事務の役割別アクセス制御
- AU-2（監査イベント）：全アクセスログの記録
- IA-5（認証子管理）：多要素認証の必須化
- SC-28（保存データの保護）：ストレージの暗号化
④ Implement（実装）
選択した管理策をシステムに組み込みます。
- Active Directory で役割ベースのアクセス制御（RBAC）を設定
- SIEMツールで全アクセスを記録・アラート
- 医師・看護師へのICカード＋PIN認証を導入
- データベースのストレージを AES-256 で暗号化
⑤ Assess（評価）
外部のセキュリティ会社が、実装された管理策を検証します。
「監査ログは取得できているが、異常検知のアラートしきい値が適切でない。POA&Mとして記録し、90日以内に改善すること」
⑥ Authorize（承認）
病院長（AO：Authorizing Official）が評価レポートを確認し、残存リスクが許容範囲内と判断。ATOを付与し、EHRの本番運用を承認します。
⑦ Monitor（モニタリング）
運用開始後も継続的に監視を続けます。
- 毎月：アクセスログのレビュー
- 四半期：脆弱性スキャン
- 年次：フルセキュリティアセスメント
半年後、新たな脆弱性がEHRのミドルウェアに発見されました。変更管理プロセスに従い、影響評価→パッチ適用→再評価→AOへの報告、というサイクルが回ります。
ユースケース：どんな場面で使われるか
RMFはもともと米国連邦政府機関向けに策定されましたが、現在はより広い範囲で活用されています。
| ユースケース | 詳細 |
|---|---|
| 米国連邦政府機関（必須） | FISMA準拠のため、すべての連邦機関はRMF適用が法律上の義務 |
| 政府系請負業者・ベンダー | 連邦データを扱う民間企業もFISMA準拠が求められる |
| FedRAMP準拠 | クラウドサービスが連邦政府に提供する際のセキュリティ承認プロセスにRMFを活用 |
| 医療・金融などの民間組織 | HIPAA・PCI DSSなど他の規制要件とのマッピングにRMFを活用 |
| 防衛・重要インフラ事業者 | DoD系契約では特にRMFへの準拠が重視される |
| グローバルな民間企業 | RMFのベストプラクティスをISO 27001等と組み合わせてGRCプログラムの基盤として採用 |
他のフレームワークとの比較
学習中に「RMFとCSFって何が違うの？」と混乱したので、主要フレームワークを並べて整理しました。
| フレームワーク | 主な対象 | 特徴 |
|---|---|---|
| NIST RMF（SP 800-37） | 連邦機関・政府系組織 | 7ステップの構造化プロセス、FISMA準拠に必須 |
| NIST CSF | 民間企業を含む幅広い組織 | Identify/Protect/Detect/Respond/Recoverの5機能、戦略的な枠組み |
| ISO/IEC 27001 | グローバルな民間企業 | 国際標準、認証取得可能、ISMSの構築を規定 |
| COBIT | IT ガバナンス全般 | ビジネス目標とITの整合性に注力 |
RMFとCSFは相補的な関係にあります。CSFを戦略的なコミュニケーションツールとして使い、RMFで具体的なシステム承認プロセスを実行する、という使い方が連邦機関では一般的なようです。
まとめ
| 項目 | 内容 |
|---|---|
| 作成組織 | NIST主導のJTF（NIST・IC・DoD・CNSS） |
| 初版公開 | 2010年2月（NIST SP 800-37） |
| 最新版 | Rev.2（2018年12月）、SP 800-53 Release 5.2.0（2025年8月） |
| コア概念 | SDLCへのセキュリティ統合、継続的モニタリング、階層的リスク管理 |
| 7ステップ | Prepare → Categorize → Select → Implement → Assess → Authorize → Monitor |
| 主なユースケース | 米国連邦機関（法的義務）、政府系ベンダー、FedRAMP、民間企業のGRC |