mcpField
C
conducting-cyber-risk-assessment-with-nist-800-30

conducting-cyber-risk-assessment-with-nist-800-30

github.com/mukul975セキュリティ35.2k109 回インストール8 週間前に更新
リポジトリ

conducting-cyber-risk-assessment-with-nist-800-30 について

NIST SP 800-30 Rev. 1 に基づくサイバーリスク評価のスキルです。セキュリティおよびリスク担当者が、範囲設定や脅威分析から、リスクの順位付け、対応判断、再評価まで進められます。

主な機能

  1. 01NIST 800-30 の評価手順
  2. 02脅威・脆弱性・影響の分析
  3. 03可能性とリスクのスコアリング
  4. 04優先順位付きリスク台帳と報告書
  5. 05リスク対応と再評価

活用シーン

  1. 01CSF、ISO、SOC 2 向けのリスク分析文書化
  2. 02稼働前システムの評価
  3. 03経営層向けリスクの順位付け
  4. 04インシデントや変更後の評価更新

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/mukul975/anthropic-cybersecurity-skills --skill conducting-cyber-risk-assessment-with-nist-800-30

インストール後、Claude Code で/conducting-cyber-risk-assessment-with-nist-800-30を入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

LICENSE
assets/
template.md
references/
standards.md
scripts/
process.py

詳細

NIST SP 800-30 によるサイバーリスク評価の実施

使用する場面

  • フレームワークに対する成熟度スコアではなく、具体的な脅威、発生可能性、影響を分析する実際のリスク評価が組織に必要な場合。(成熟度評価ではプラクティスの成熟度がわかります。リスク評価では、何がどの程度の損害をもたらし得るかがわかります。)
  • 別のフレームワークで、文書化されたリスク分析が必須の入力として求められる場合:NIST CSF(ID.RA)、ISO 27001(箇条 6.1.2)、NIST RMF / 800-37(準備および選択のステップ)、SOC 2(CC3)、PCI DSS、または HIPAA(§164.308(a)(1)(ii)(A))。
  • システムの導入時や大幅な変更時に、承認または本番稼働の前にリスクを把握する必要がある場合。
  • 経営陣から、取締役会や規制当局に根拠を説明できる、優先順位付けされた組織の主要なリスクを求められた場合。
  • 全社的なリスク登録簿を作成または更新する場合。

前提条件

  • 対象範囲内の資産、システム、それらが扱う情報の種類のインベントリ(システム境界が定義されていること)。
  • 脅威イベントの発生可能性を実際に観測された行動に基づいて評価するための、脅威インテリジェンスへのアクセス(社内のインシデント履歴、業界 ISAC のフィード、MITRE ATT&CK)。
  • 対象範囲内のシステムの脆弱性データ(スキャン結果、ペネトレーションテストの所見、構成/アーキテクチャレビュー)。
  • ビジネスコンテキスト:システムがどのミッション/プロセスを支えているか、また機密性、完全性、可用性への影響がビジネス上どのような意味を持つか。
  • スコアリングの前に、リスクモデルと尺度について合意しておくこと。これにより、結果を比較可能かつ再現可能にできます(references/standards.md を参照)。
  • NIST SP 800-39 の3階層のリスク管理コンテキスト(組織、ミッション/ビジネスプロセス、情報システム)について理解していること。

ワークフロー

NIST SP 800-30 Rev 1 では4つのステップが定義されています。ステップ1と4が評価の始まりと締めくくりで、ステップ2が分析の中核です。

1. 評価の準備

次の項目を定義し、文書化します。

  • 目的(例:承認判断の支援、管理策の選定への情報提供、ISO 6.1.2 の要件への対応)。
  • 範囲 — 組織階層(Tier 1/2/3)、システム、期間。
  • 前提と制約(例:能力が中程度の外部の敵対的脅威を想定する)。
  • 情報源 — 脅威、脆弱性、影響に関する入力情報。
  • リスクモデルと分析アプローチ — 要因(脅威の発生源、脅威イベント、脆弱性、発生可能性、影響)と尺度(定性的な「非常に低い」〜「非常に高い」、または半定量的な 0〜10)。これらをここで確定します。
2. 評価の実施

分析タスクを順番に実施します。800-30 の付録(D〜I)に参照用の分類体系が示されています。

2a. 脅威源の特定(付録 D)。 種類ごとに分類します。敵対的(個人、グループ、国家。能力、意図、標的を特徴づける)、偶発的(ユーザーのミス)、構造的(機器やソフトウェアの障害)、環境的(自然災害、インフラの停止)です。

2b. 脅威イベントの特定(付録 E)。 脅威源が実行しうる具体的な行為です(例:「攻撃者がフィッシングで認証情報を窃取し、その後横展開する」)。敵対的なイベントは、追跡可能性のために MITRE ATT&CK の手法にマッピングします。

2c. 脆弱性と素因となる条件の特定(付録 F)。 弱点(MFA の欠如、パッチ未適用のサービスなど)と、悪用の可能性を高めたり低めたりする条件(インターネットへの公開、フラットなネットワーク、セグメンテーションの欠如など)です。

2d. 可能性の判定(付録 G)。 脅威イベントが開始される(敵対的)または発生する(非敵対的)可能性と、脆弱性を前提に悪影響をもたらす可能性を評価します。両者を合わせ、合意済みの尺度で全体的な可能性を求めます。

2e. 影響の判定(付録 H)。 イベントが成功した場合の被害の大きさを、業務、資産、個人、他の組織、または国家への影響の観点で評価します。合意済みの尺度を用い、ビジネス上の言葉で表現します。

2f. リスクの判定(付録 I)。 リスクは可能性と影響の関数です。各脅威イベントをリスクマトリクス上にプロットします(例:可能性 × 影響 → 非常に低い … 非常に高い)。リスクレベル、寄与要因、不確実性と前提条件を記録します。

3. 結果の共有と伝達

リスク登録簿と経営層向けのブリーフィング資料を作成します。各リスクについて、脅威イベント、影響を受ける資産、可能性、影響、リスクレベル、主要な寄与脆弱性、推奨される対応策を記載します。意思決定者が最も重要なリスクを最初に把握できるよう、リスクレベル順に並べます。

4. 評価の維持

リスクは固定的なものではありません。見直しの周期と、再評価を要するトリガー(新システムの導入、アーキテクチャの大きな変更、重大インシデント、新たな脅威インテリジェンスなど)を定義します。リスク受容の決定と対応の進捗を、時間を通じて追跡します。

5. 対応策の決定

順位付けされた登録簿をリスクオーナーに引き渡します。各リスクについて対応策を選択します。低減(管理策の追加・強化)、移転(保険、契約による移転)、回避(活動の停止)、受容(承認者の署名付きで残留リスクを文書化)のいずれかです。計画された管理策の実施後に残留リスクを再評価し、対応後の状況を示します。

主要概念

概念定義
脅威源脅威イベントの原因。敵対的、偶発的、構造的、環境的のいずれか。
脅威イベント害を引き起こしうる具体的な行為または事象(敵対的ケースでは ATT&CK にマッピング)。
脆弱性脅威イベントが悪用しうる弱点。
素因となる条件悪影響の可能性を高めたり低めたりする条件(例:インターネットへの公開)。
可能性脅威イベントが開始・発生し、かつ悪影響をもたらす確率。
影響イベントが成功した場合の被害の大きさ。
リスク可能性と影響の関数。組織にとっての予想される損害。
固有リスクと残留リスク計画・実施された管理策の前後のリスク。
リスク許容度 / リスク選好経営層が受容しようとするリスクの水準。
リスク登録簿リスク、スコア、オーナー、対応策を優先順位付きで記録したもの。

ツールとシステム

  • NIST SP 800-30 Rev 1 — 方法論、および付録 D~I の分類体系(脅威源、事象、脆弱性、可能性、影響、リスク)。
  • NIST SP 800-39 — エンタープライズリスク管理のコンテキスト(3 つの階層)。
  • MITRE ATT&CK — 敵対的な脅威事象を、観測された TTP に基づいて列挙し、根拠付けるために使用します。
  • 脆弱性スキャナー/ペネトレーションテストのレポート — 実証に基づく脆弱性の入力情報。
  • 脅威インテリジェンスソース — 業界 ISAC、ベンダーのフィード、社内のインシデント履歴を、可能性の根拠付けに使用します。
  • GRC/リスク登録簿ツール — スプレッドシート、または ServiceNow GRC、Archer、OneTrust などのプラットフォームを使用して、登録簿を保存・追跡します。
  • FAIR(任意)— 経営陣がリスクを定性的な区分ではなく金額の幅で表したい場合に使用する定量モデルです。

よくあるシナリオ

  • CSF/ISO/SOC 2 でリスク分析が必要な場合。 800-30 を実施して、これらのフレームワークが入力情報として求める、文書化された評価を作成し、その後、結果を各フレームワークの管理策にマッピングします。
  • システムの稼働開始前。 システムのアーキテクチャに照らして脅威事象を評価し、結果を認可(RMF の選定/認可)の判断に反映します。
  • 取締役会が主要なリスクを求めている場合。 ビジネス上の影響と明確な対応策の推奨を含む、優先順位付けされた登録簿を作成します。
  • インシデント発生後。 影響を受けたシステムを再評価します。インシデントによって可能性の根拠となる情報が更新され、新たな脅威事象が明らかになる場合があります。
  • 年次更新。 最新の脅威インテリジェンスと管理策の変更に基づいて再評価し、残余リスクの前年比の推移を示します。

出力形式

assets/template.md を使用して、以下を含むリスク評価レポートを作成します。

  1. 目的、範囲、階層 — 評価対象とその理由。
  2. 前提、制約、リスクモデル — 使用した要素と尺度(結果を再現できるようにするため)。
  3. 脅威源 — 敵対的な特性の説明を含むタイプ別の一覧。
  4. 脅威事象 — それぞれに影響を受ける資産と、敵対的な場合は ATT&CK へのマッピングを記載します。
  5. 脆弱性と素因となる条件 — 脅威事象に関連付けます。
  6. リスク登録簿 — 表の項目:ID、脅威事象、資産、可能性、影響、リスクレベル、関連する脆弱性、推奨される対応、担当者、残余リスク。
  7. 主要リスクの概要 — 経営陣向けに、ビジネス上の表現で優先順位を付けて記載します。
  8. 維持計画 — 更新頻度と再評価のトリガー。

scripts/process.py を使用して、リスク入力 JSON から登録簿のスコアを算出し(可能性 × 影響 → 設定可能なマトリックスに基づくリスクレベル)、リスクに順位を付け、登録簿の表を出力します。

コメント