csf-mapping

CSF マッピング — NIST Cybersecurity Framework 2.0 の態勢評価

セキュリティ態勢を、すべての CISO、取締役会、監査人、保険会社がすでに理解している言葉で表現します。特定の問題を見つける監査スキルとは異なり、このスキルは認知されたフレームワークに照らしてプログラムを評価し、ガバナンスに活用できる成果物を作成します。

2024 年時点で、NIST CSF 2.0 は CSF 1.1 に取って代わったフレームワークです。6 つ目の機能である Govern が追加され、ガバナンスの支えなしには他の機能が機能しないことが認識されました。

6 つの機能：

機能	対象範囲
Govern（GV）	サイバーセキュリティ戦略、役割、ポリシー、監督、サプライチェーンリスク
Identify（ID）	資産インベントリ、ビジネス環境、リスク評価、サプライチェーン
Protect（PR）	アクセス制御、意識向上、データセキュリティ、ベースライン構成、保守、保護技術
Detect（DE）	継続的な監視、異常検知、有害事象の分析
Respond（RS）	インシデント管理、分析、緩和、報告、コミュニケーション
Recover（RC）	復旧計画、改善、コミュニケーション

各機能にはカテゴリ（例：PR.AA — ID 管理、認証、アクセス制御）が含まれ、各カテゴリにはサブカテゴリ（例：PR.AA-01 — 認可されたユーザー、サービス、ハードウェアの ID と認証情報が管理されている）が含まれます。

このスキルは、実際の状況をこれらのサブカテゴリにマッピングします。

相互参照：このリポジトリ内のすべての監査スキル（このスキルで「現状」の項目となる証拠を作成します）、iam-audit（主に PR.AA）、siem-detection（主に DE）、incident-triage（主に RS）、threat-modeling（ID.RA のリスク評価に役立ちます）、breach-patterns（教訓に基づく ID.IM の改善に役立ちます）。

認可

ユーザー自身の組織、またはユーザーが業務を請け負ったクライアントを、提供された証拠、あるいは提示された証拠に基づいてマッピングします。このスキルはポリシー、設定、監査結果を読み取りますが、システムをプローブすることはありません。証拠は評価の範囲内で扱い、公開情報から他組織の態勢を推測しないでください。

方法

ステップ 1 — スコープを定める

CSF 評価の対象範囲は限定されます。次のうち、どれを評価するかを決めてください。

• 組織全体 — すべてのシステム、すべての事業部門
• 1 つの製品／サービス — ベンダーのデューデリジェンス質問票（SIG、CAIQ）向け
• 1 つの環境 — 本番クラウドのみ、または PCI 対象範囲のみ
• 規制対象範囲 — HIPAA の対象システム、FedRAMP の境界など

対象範囲に含めるものと含めないものを記録してください。CSF 評価の多くは、スコープの逸脱によって失敗します。

ステップ 2 — CSF プロファイルを選択する

CSF 2.0 では、組織プロファイルが導入されました。「すべてのサブカテゴリを同じ比重で採点する」のではなく、重要な項目に合わせて調整します。

• 現状プロファイル — 実際の現在の状態
• 目標プロファイル — 目指す状態（ビジネス目標、規制要件、リスク許容度に基づく）
• コミュニティプロファイル — 業界向けの事前構築済みプロファイル（製造、医療、金融サービスなど。NIST などが公開）

初回評価では、業界向けのコミュニティプロファイルがあれば、それを使って開始し、その後に調整してください。

ステップ 3 — 各サブカテゴリを評価する

対象範囲内の各サブカテゴリについて、次の項目を記録します。

項目	記録する内容
ID	例：PR.AA-05
サブカテゴリの文言	NIST の文言をそのまま記載するか、言い換えて記載
現状	今日実際に行っていること（願望ではなく、証拠に基づく内容）
証拠	現状を証明する文書／システム／プロセス
ティア	部分的／リスク情報に基づく／再現可能／適応型（1～4）
目標ティア	目指す状態
ギャップ	現状との差分
計画	ギャップを埋めるための取り組み
担当者	説明責任を負う人
スケジュール	実施時期

CSF 実装ティア

ティア	名称	特徴
1	部分的	場当たり的で事後対応が中心、文書化されていません。認識は非公式です
2	リスクを考慮	リスク管理は承認されていますが、組織全体には浸透していません。一部のチームではプロセスを繰り返し実施できます
3	再現可能	組織全体で文書化されたポリシー、一貫したプロセス、リスクを考慮した予算編成
4	適応的	継続的な改善、定量的なリスク評価、インシデント（自社および同業他社）の教訓を反映するサイバーセキュリティ文化

ティア 4 はまれで、コストもかかります。成熟した SaaS 組織のほとんどは、大半のサブカテゴリーでティア 3 を目標にしています。見栄えのよさではなく、事業に実際に必要なものに基づいて目標を設定してください。

ステップ 4 — ギャップを特定して優先順位を付ける

各ギャップについて、次の点を確認します。

• 悪用された場合、または未対処の場合の影響（規制、評判、財務）
• 現在の脅威状況と自社固有のリスクに基づく可能性
• 解消コスト（エンジニアリング工数、ツール、人員）
• 先に解消する必要がある他のギャップとの依存関係

リスク × 解消コストに基づいて優先順位を付けます。リスクだけで判断してはいけません。重大なリスクを伴う項目の中には、解消に 1 年と 3 社のベンダーが必要なものもあれば、スプリント 1 回で実際のリスクを低減できる手軽な改善策もあります。

ステップ 5 — ロードマップを作成する

CSF のロードマップは通常、年次目標を設定し、四半期ごとに進めます。次のような構成が役立ちます。

• 今後 30 日間 — 早急に対処するギャップ（手軽な改善策、低コストでリスクの高い項目）
• 今後 90 日間 — 中程度の工数が必要な項目、担当者の明確化、成功基準の設定
• 今後 12 か月間 — 予算承認、ツールの選定、人員が必要となる戦略的なギャップ
• 年次レビュー — 全体の再評価、プロファイルの更新、ティアの引き上げ

ロードマップの各項目には、解消するサブカテゴリー、担当者、予算、成功指標、レビュー日を記載します。

このリポジトリ内のスキルとのサブカテゴリー対応表

便利な近道として、各 CSF サブカテゴリーのエビデンスを生成する監査スキルを以下に示します。

CSF サブカテゴリー	監査スキル	エビデンスの種類
GV.SC（サプライチェーンリスク）	dependency-audit	CVE インベントリ、ベンダー一覧、サプライチェーンリスク登録簿
ID.AM（アセット管理）	cloud-audit、container-audit、recon	アセットインベントリの出力
ID.RA（リスク評価）	threat-modeling、breach-patterns	脅威モデル、侵害パターンの網羅状況に関する文書
ID.IM（過去のインシデントからの改善）	incident-triage の事後検証、breach-patterns	インシデント後のレビュー、適用した教訓
PR.AA（ID・アクセス制御）	iam-audit	IAM 監査レポート、ロールインベントリ
PR.DS（データセキュリティ）	crypto-audit、secrets-audit	暗号化の状況、シークレット管理の状況
PR.PS（プラットフォームセキュリティ）	container-audit、cloud-audit	K8s の強化、クラウドのセキュリティ状況
PR.IR（インフラストラクチャのレジリエンス）	container-audit、cloud-audit	ネットワークポリシー、セグメンテーション、バックアップの状況
DE.CM（継続的な監視）	siem-detection、soc-operations	SIEM の網羅状況、ATT&CK Navigator のエクスポート
DE.AE（異常・イベント分析）	siem-detection、threat-hunting	検知ルールのインベントリ、ハンティングの調査結果
RS.MA（インシデント管理）	incident-triage、soc-operations	IR 計画、ランブック、最近のインシデントレポート
RS.AN（分析）	disk-forensics、incident-triage	フォレンジック分析の出力
RS.MI（緩和）	finding-triage、incident-triage	トリアージの判断、緩和策の追跡
RC.RP（復旧計画）	（直接対応するものはありません — BCP/DR の個別作業が必要です）	BCP / DR 計画、復旧テスト

スキルで直接対応していないサブカテゴリーでは、通常、「技術面の詳細な対応力はあるが、プログラムレベルの成果物がない」というギャップがあります。たとえば、RC.RP-01（インシデント中または発生後に復旧計画を実行する）には、文書化され、テスト済みの BCP/DR 計画が必要です。incident-triage を実行しても、それだけで計画が作成されるわけではありません。

多くの組織に見られる重大なギャップ

CSF 評価で繰り返し見られるパターンです。すべての組織に当てはまるわけではありませんが、出発点として役立ちます。

• GV.OC-04（重要な目標、能力、サービスが特定され、共有されている） — ほとんどの組織では、セキュリティ、IT、エンジニアリングの各部門で一貫して最重要システムを挙げることができません
• GV.SC（サプライチェーンリスク管理カテゴリ） — ベンダーリスクプログラムがまったくないか、書類上は存在していても、実際には調達の可否を左右していません
• ID.AM-08（システム、ハードウェア、ソフトウェア、サービス、データがライフサイクル全体を通じて管理されている） — 資産インベントリは「SaaS ベンダーのリスト」と「記憶しているもの」です
• ID.IM-04（インシデント対応計画が訓練されている） — 計画はありますが、最後にテストしたのは 3 年前です
• PR.AA-05（最小権限の原則を取り入れ、アクセス権限と認可が管理されている） — 四半期ごとのアクセスレビューはポリシーにはありますが、実際には行われていません
• PR.DS-01（保存データの機密性、完全性、可用性が保護されている） — 保存時の暗号化は「はい」ですが、鍵管理については「AWS に聞いてください」という状態です
• DE.AE-08（有害事象が定義された基準を満たした場合、インシデントとして宣言される） — 基準は実際には定義されておらず、「そのときになれば分かる」という状態です
• RS.CO-02（社内外の関係者にインシデントが通知される） — 通知マトリックスが誰かの頭の中にあります
• RC.RP-01（復旧計画が実行される） — 文書化されていますが、テストされたことはありません

出力形式

# NIST CSF 2.0 Posture Assessment
## Organization: [name]
## Scope: [what's in / out]
## Date: [date]
## Assessor: [name]

## Executive summary
[2-3 paragraphs in plain English — overall posture, top 3 risks, top 3 wins, recommended 90-day priorities]

## Profile

### Tier summary across functions
| Function | Current tier | Target tier |
|----------|--------------|-------------|
| GV | 2 | 3 |
| ID | 2 | 3 |
| PR | 3 | 3 |
| DE | 2 | 3 |
| RS | 3 | 3 |
| RC | 1 | 2 |

### Per-Subcategory detail
| Subcategory | Current state | Evidence | Tier | Target | Gap | Owner | Timeline |
|-------------|---------------|----------|------|--------|-----|-------|----------|

## Prioritized roadmap

### Next 30 days
- [Item, owner, success metric]

### Next 90 days
- [Item, owner, success metric]

### Next 12 months
- [Item, owner, success metric]

## Cross-references
[Links to evidence — audit reports, IR plans, IAM reports, etc.]

取締役会向けの表現に置き換える

取締役会が知りたいのはサブカテゴリ ID ではありません。次の 3 つの問いへの答えです。

1. どのようなリスクにさらされていますか？（重大なリスクの上位 3～5 件）
2. そのリスクにどう対処していますか？（具体的な投資、担当者の明示、日付）
3. 改善をどう確認できますか？（定量的な指標、目標日）

CSF 評価は、詳細な根拠資料として使用します。取締役会向け資料は、1 ページのヒートマップと優先事項をまとめた 3 枚のスライドです。評価結果は付録に記載します。

適用範囲

• このスキルが作成するのはガバナンス関連の成果物とロードマップであり、エクスプロイトではありません
• CSF 評価は、規制上の意味での監査（SOC 2 監査、FedRAMP 評価、ISO 27001 認証監査はそれぞれ別のプロセスです）ではありません。CSF マッピングはそれらに役立ちますが、代わりにはなりません
• 監査対象の環境（PCI、HIPAA、FedRAMP）では、監査人が指定するフレームワークが正式な基準です。CSF マッピングは有用な補完情報です
• 証拠なしにティア評価を引き上げることは拒否してください。ティア 3 は「組織全体で文書化されたプロセスがあることを示す証拠」を意味し、「いつか実施したいと願っている」という意味ではありません
• 評価によって即時対応が必要な指摘事項（進行中のインシデント、公開されたシステムなど）が判明した場合は、incident-triage または該当する監査スキルに引き継いでください

参考資料

• NIST Cybersecurity Framework 2.0（nist.gov/cyberframework）
• NIST CSF 2.0 クイックスタートガイド
• NIST CSF コミュニティプロファイル（セクター別の出発点）
• NIST SP 800-53（管理策カタログ。CSF サブカテゴリに対応する具体的な管理策を提供します）
• ISO 27001:2022（代替の ISMS フレームワーク。両方を導入する組織では、CSF と照合されることがよくあります）
• CIS Critical Security Controls v8（代替となる優先順位付け済みフレームワーク。CSF と高い重複があります）
• Cybersecurity Maturity Model Certification（CMMC）— DoD の請負業者向け。CSF と NIST 800-171 を使用します
• 「Cybersecurity Risk Management: Mastering the Fundamentals Using the NIST Cybersecurity Framework」— Cynthia Brumfield