用語比較
リスク・脅威・脆弱性の違い
一言でいうと
脅威は損害を生む可能性のある事象や原因、脆弱性はその事象に対する弱点、リスクは目的・業務に対する悪影響を発生可能性と影響の大きさから捉えたもの。対象業務、既存対策、根拠と不確実性をそろえて評価し、脅威と脆弱性の単純な掛け算だけで結論を出さない。
リスク・脅威・脆弱性は何が違う？攻撃・誤送信・停止の具体例を3列の表で比較し、発生可能性と業務影響、既存対策、残存リスクの判断を整理します。単純な掛け算やCVSSだけの順位付けを避け、担当・期限・再評価条件を残す方法を、NISTの資料と無料の改善記録で解説します。
- 難易度
- 初級
- 想定読者
- 情シス・ISMS担当・事業責任者・初心者
- 所要時間
- 約12分
- 最終確認
- 2026-10-30
- 1. 対象と事象をそろえる
業務・資産・所有者、脅威の事象、弱点と既存対策を整理する。
- 2. 条件付きで評価する
発生可能性・業務影響、尺度、根拠と不確実性を分けて判断する。
- 3. 対応後も見直す
確認結果・残存リスク、担当・期限、承認者と再評価条件を記録する。
脅威とは
損害を生む可能性のある事象や、その原因となる脅威源。意図した攻撃だけでなく、操作ミスや自然災害等も考慮する。誰が何をするかと、実際に起き得る事象を分けて記述する。
脆弱性とは
脅威の事象によって悪影響につながり得る弱点。ソフトウェアの欠陥だけでなく、構成・手順・管理上の不足も対象になる。CVEがない、診断で未検出という理由だけで弱点がないと判断しない。
リスクとは
対象の目的・業務が受ける悪影響について、発生可能性と影響の大きさを考えたもの。資産、脅威・弱点、既存の対策、前提と不確実性を踏まえて評価し、対応後に残るリスクも追跡する。
違いの比較表
横にスクロールして3つの概念を比較できます。表はキーボードの左右キーでも動かせます。
| 比較軸 | 脅威 | 脆弱性 | リスク |
|---|---|---|---|
| 問うこと | どんな事象が、誰・何によって起き得るか | どんな弱点や条件が悪影響につながるか | どの業務へ、どの程度の悪影響が、どの程度起こり得るか |
| 送信の例 | 操作ミスによる宛先間違い・誤送信 | 宛先や共有先を確認する仕組み・手順の不足 | 機密の誤送信により業務・顧客等へ損害が及ぶ可能性 |
| 根拠 | 過去の事象、公式の注意喚起、現場の観測 | 設定、資産台帳、診断、手順・実施状況 | 根拠、対象・期間、既存対策、影響・発生可能性と不確実性 |
| 数値 | 観測した事象の件数と対象期間を区別 | 検出数や深刻度を、業務リスクそのものと扱わない | 高・中・低等の尺度を定義する。順位を確率や損失額と混同しない |
| 対応 | 事象の監視、注意喚起、発生への備え | 構成・更新・手順・権限等の改善 | 低減・回避・移転等・受容を、業務の条件と責任者で判断 |
| 完了確認 | 事象が未観測でも、将来の発生なしとはしない | 設定したことと、対策が機能したことを分ける | 対策の結果、残存リスク、受容の承認・期限を確認 |
| 記録担当 | 観測した担当が事実と未確認を残す | 資産・構成や業務手順の担当が条件を確認 | 事業・リスク所有者が優先度、対応と受容を判断する |
概念を整理したら、現状と改善の記録へ
対象、現状・目標、業務影響、責任者と期限、確認の証跡をそろえる。判断表で不足した条件を、次の記録へ引き継げます。
無料のリスク判断・改善記録を開く使い分け
- 初めてリスク表を作るなら、資産名だけでなく「何が起き、どの弱点を通じ、業務に何が起きるか」を一文にする。脅威の一覧や脆弱性の件数を、そのまま優先順位表にしない。
- パッチや権限対策を比較するなら、同じ対象業務・既存対策・停止条件をそろえる。対策したい弱点と、減らしたい悪影響を分け、残るリスクを責任者と確認する。
- 侵害や漏えいが疑われるときは、リスク表を完成させる前に正規の報告・初動へ進む。証拠がそろっていないことを、被害なしや安全という判定に置き換えない。
具体例で区別する：脅威源・弱点・業務リスク
リスク評価の対象は、業務、資産・データ、関係者、対象期間を先に決める。「ランサムウェア」の一語だけなら脅威の材料であり、どの資産を通じて何の業務が止まるかまでは示していない。意図的な攻撃、操作ミス、災害などを対象に応じて検討する。
脆弱性もCVE付きの製品欠陥だけではない。宛先・公開範囲を確認する手順、権限の見直し、復元の確認が不足している条件は、それぞれ異なる事象と影響につながる。見つかった弱点と、実際に対策が有効か不明な状態を区別する。
NIST SP 800-30 Rev. 1は2012年の基礎資料、CSF 2.0は2024年、IR 8286 Rev. 1は2025年12月の資料。2026年10月30日に照合した日付を、それらの刊行日や組織の認証・監修の実績とは扱わない。
リスクの計算方法：掛け算と点数の限界を先に決める
NIST SP 800-30は、脅威、弱点・条件、発生可能性、影響等を組み合わせて評価する考え方を示す。「脅威×脆弱性」だけで全組織共通のリスク値が求まるという意味ではない。尺度、組合せ方、根拠、前提と不確実性を明示する。
高・中・低に便宜的な数字を付けても、その数字が確率や損失額になるわけではない。CVSSは技術的な深刻度、EPSSは悪用の観測の予測であり、その単純な積を自社の損失期待値と呼ばない。定性的な優先順位と、データ・仮定に基づく定量評価を混同しない。
同じ尺度で既存対策を確認し、判断材料が不足する場合は確認担当と次の判断機会を設ける。未知の値をゼロにしたり、根拠のない小さな確率で優先度を落としたりしない。法令・契約・安全への影響は点数だけで適用除外にしない。
判断例：停止時間と復旧条件が異なる2つの業務
編集部の仮の例として、業務Aは所有者が停止許容を2時間と定め、業務Bは翌営業日までの復旧を許容するとする。同じ製品の弱点でも、対象データ、依存する業務、代替手段、復元の確認状況をそろえなければ対応順は決まらない。この時間は推奨の共通基準や実測値ではない。
Aに有効な代替手段がなく、停止した場合の影響が大きいなら、業務責任者を含めて優先的に対策・代替運用を検討する。Bも重要な個人情報を扱う、不審なアクセスがある、実際はAの依存先だったと分かれば判断が変わる。「内部向け」「低得点」だけで除外しない。
対応は、弱点を改善して可能性を下げる、機能・利用をやめて回避する、契約等で一部を移転・共有する、条件付きで受容する等から選ぶ。委託や保険で責任・損害がすべて消えるとは説明せず、契約条件と残るリスクを確認する。
リスク評価表の記録方法と、受容・再評価の条件
編集部の記録例は、①対象業務・所有者、②脅威の事象、③弱点・既存対策、④影響・発生可能性と根拠、⑤対応と担当・期限、⑥確認結果と残存リスク、⑦承認者・再評価条件の7項目。実情報は社内の承認済みの保管先へ記録し、CyberLensへ入力しない。
NIST IR 8286 Rev. 1は、リスク登録簿を通じてサイバーリスクを企業全体の目的と判断へつなぐ考え方を示す。対策を設定したことだけでリスク低減の完了とせず、実施した確認と残件を分ける。受容には、組織が定めた権限を持つ責任者の判断と見直し条件を残す。
再評価のきっかけは、業務・公開範囲・依存関係の変更、新しい悪用情報・検知、対策や復旧確認の結果の変化など。無料の改善記録で現状・目標・担当と証跡をそろえ、必要ならチェックリストや学習の続きを使う。記録した件数を安全性や法令遵守の保証にはしない。
よくある誤解
- 脅威は外部の攻撃者だけではなく、操作ミスや災害等の事象も対象に応じて考える。
- CVEがない・診断で未検出という事実から、弱点やリスクがないとは判断しない。
- 脅威・脆弱性・点数の単純な掛け算だけで、自社のリスクや受容可否を決めない。
よくある質問
脅威・脆弱性・リスクを具体例でいうと何ですか？
誤送信という事象が脅威、宛先や共有先を確認する仕組み・手順の不足が弱点、機密の誤送信により業務や顧客へ損害が及ぶ可能性がリスクの例です。対象と既存対策をそろえて影響・発生可能性を評価します。
リスクは脅威と脆弱性を掛ければ計算できますか？
その2つの単純な積だけでは決めません。業務・データへの影響、発生可能性、既存対策、尺度と根拠・不確実性を明示します。順位のための数字を被害確率や損失額と混同しません。
対策を実施すれば、リスク評価は完了ですか？
対策の設定と有効性の確認は別です。確認結果、未確認範囲、残存リスクと受容の承認を記録し、業務・公開範囲の変更、新しい悪用情報や検知、対策結果の変化で再評価します。
編集・確認情報
NIST SP 800-30 Rev. 1、CSF 2.0、IR 8286 Rev. 1とFIRSTのCVSS・EPSS案内を照合し、3概念、尺度、業務判断例、残存リスクと記録を改訂しました。組織の正式なリスク評価、認証審査、実環境での対策検証や個別監修ではありません。 最終確認日は 2026-10-30 です。
参考資料は用語・設計・機能例の確認先です。製品ごとの範囲は異なり、特定製品の推奨や比較全体の公式認定ではありません。資料の公開時点と現行の公式案内も合わせて確認してください。
新しい解説を見逃さない
CVE・KEVの初動対応や実務チェックリストは随時追加しています。使いやすい方法で更新を受け取れます。