1.4リスク・脅威・脆弱性・エクスプロイトの比較

これら4語は日常では雑に混ぜて使われますが、SOCとリスク管理では厳密に区別しないと対策の議論がかみ合いません。「脆弱性を潰す」のと「脅威を減らす」のと「リスクを受容する」のは別の意思決定です。この節では、脅威・脆弱性・エクスプロイト・リスクの関係を一本の線で結び、ある対策が4つのどこに作用するのか、対策後に何が残るのかを判断できるようにします。

1.4.14つの定義と関係

• 脅威（threat）＝資産に害を与え得る潜在的な原因/主体/事象（攻撃者、マルウェア、災害など）。存在するだけでは被害は出ないが、突く先があれば害になり得る。基本的に外部要因で、こちらが直接消せないことが多い（攻撃者の存在自体はなくせない）。
• 脆弱性（vulnerability）＝脅威に突かれ得る弱点/欠陥（未パッチのバグ、弱いパスワード、誤設定など）。こちら側にあり、対処（パッチ・設定変更）で減らせる。脅威と違い、多くはコントロール可能。
• エクスプロイト（exploit）＝脆弱性を実際に突く手段/コード/行為。脅威が脆弱性を害へ変換する「橋渡し」。脆弱性があってもそれを突くエクスプロイトが成立しなければ被害には至らない。
• リスク（risk）＝脅威が脆弱性を突いて損害が生じる可能性と、その影響の大きさの組み合わせ（おおむね可能性×影響）。脅威・脆弱性・資産価値がそろって初めてリスクになる。ゼロにはできず、低減・移転・受容・回避で扱う。

1.4.2どの対策がどこに効くか

• パッチ適用・設定強化・入力検証は脆弱性を減らす対策。脅威（攻撃者）そのものは消えないが、突く先が無くなればリスクは下がる。多くの技術的対策は脆弱性側に効くと押さえる。
• 保険は損害を移転しリスクの影響面を扱う（脅威も脆弱性も消さない）。重要データを持たない/そのシステムを廃止するのは回避。残った小さなリスクをそのまま抱えるのは受容。「対策後に何が残るか」を残留リスクとして明示するのが要点。

あなたのチームは、外部公開しているWebサーバに、既知の脆弱性（未パッチのリモートコード実行バグ）があると脆弱性スキャンで判明しました。経営会議で「攻撃者（脅威）をどう排除するのか」と問われますが、ここで区別が効きます——インターネット上の攻撃者という脅威そのものは基本的に消せません。こちらがコントロールできるのは脆弱性の側です。既にこのバグを突くエクスプロイトコードが出回っているとの脅威インテリジェンスがあれば、「脅威が脆弱性を突いて損害が出る可能性」は高く、公開サーバで顧客データを扱う以上影響も大、したがってリスクは高、と評価できます。対策の第一は当然パッチ適用（脆弱性の除去）ですが、業務都合で即時適用できない場合、WAFで当該エクスプロイトのパターンを一時的に遮断して可能性を下げる、RBAの観点でこのサーバを最優先にする、といった段階を踏みます。ここで重要なのは、WAFを入れても脆弱性自体は残っている＝残留リスクがあると正しく認識することです。「WAFを入れたのでこのリスクはゼロになった」と報告するのは誤りで、正しくは「エクスプロイト成立の可能性を下げたが、根本の脆弱性はパッチ適用まで残る」です。また保険加入は損害の影響を移転する手立てで、脆弱性も脅威も減らしません。4語を混同しないことで、「今どの作用点に手を打ち、何が残っているか」を経営にも正確に伝えられ、対策の抜けを防げます。

1.4.3この節のまとめ

• 脅威（害を与え得る潜在原因・多くは外部）と脆弱性（こちら側の弱点・減らせる）は別物。エクスプロイトが両者を害へ橋渡しする
• リスク＝可能性×影響。ゼロ化できず低減・移転・受容・回避で扱う。多くの技術的対策は脆弱性側に効く
• 対策後に残るのが残留リスク。「WAFを入れたからゼロ」ではなく「可能性を下げたが脆弱性はパッチまで残る」と正確に捉える