はじめに
セキュリティアセスメントをする際、このような発言を聞いたことがある方も多いのではないだろうか。
検出されたセキュリティリスクを「影響度☓発生確率」で優先度づけしました！
・・・
セキュリティリスク＝影響度☓発生確率
長く使い古されたフレームワークである。
そしてこう思ったことがあるのではないだろうか。
コンサル・ベンダーがこの式出してきたけどなんか腑に落ちない
セキュリティリスクの発生確率って人によって捉え方が異なり難しい
というかセキュリティリスクの発生確率ってそもそも何？
今日はこの議論に終止符を打つため（言い過ぎ）に筆をしたためる。
「セキュリティリスク＝影響度☓発生確率」は何が誤っているのか
影響度：サイバー攻撃は点ではなく線であるということ
まずは影響度について論じたい。
影響度とはある事象（リスク、課題など）が発生した場合に、状況にどれくらいの損害や変化をもたらすかを示す度合いのことである。
ここで重要になってくるのが、状況にどれくらいの損害や変化をもたらすかという部分である。言い換えると、言い換えると、影響度とは個別課題そのものの属性ではなく、攻撃チェーンが完遂した場合に最終的に到達する資産・業務の重要度で決まるということだ。
具体例
アセスメントの結果として「特権IDが共有されている」という課題が検出されたとする。この課題の影響度はどう評価すべきだろうか。
直感的には「高」と答えたくなる。Domain Adminが乗っ取られれば全システムが掌握される。
しかし特権IDの共有は、それ単体で被害を生む事象ではない。
攻撃者がまず初期アクセスを獲得し、内部ネットワークを探索し、その共有された特権IDの認証情報を窃取し、それを使って横展開する。この一連の攻撃チェーンの中の一つのステップを容易にする要因にすぎない。
問題の本質
ここに「影響度×発生確率」モデルの1つめの問題がある。このモデルは、一つの課題を独立した点として評価することを前提にしている。しかしサイバー攻撃はMITRE ATT&CKやCyber Kill Chainが示す通り、Initial AccessからExfiltrationまでの複数ステップの連鎖として成立する。
個別課題に影響度を割り当てようとすると、二つの問題が起きる。
一つ目は、最終的な被害シナリオの影響度を個別課題に転嫁してしまうこと。
「特権IDが共有されている」の影響度を「高」と評価するとき、実際に評価しているのは特権IDが悪用された結果、全システムが掌握されるという最終シナリオの影響度だ。
しかしそのシナリオが成立するには、初期アクセス、内部探索、認証情報窃取という前提ステップが必要であり、それぞれに別の防御策が存在する。
最終シナリオの影響度を個別課題に貼り付けることは、攻撃チェーンの途中にある他の防御レイヤーを無視していることになる。
二つ目は、逆にすべての課題が「高」になってしまうこと。
どんな課題も、最悪のシナリオまで攻撃チェーンを延長すれば最終的には「情報漏洩」「事業停止」に行き着く。
- パスワードポリシーが弱い→認証突破→横展開→DB窃取→50万件漏洩
- セキュリティ教育が不足→フィッシング成功→マルウェア感染→ランサムウェア→事業停止
こうなると影響度の評価は差別化の機能を失い、意思決定に使えなくなる。
本来評価すべきは、その課題が攻撃チェーンのどの段階に位置し、どの程度そのチェーンの成立を容易にするかだ。
発生可能性：セキュリティリスクは再帰的であるということ
次に発生可能性について論じたい。
こちらは影響度以上に根深い問題を抱えている。
発生可能性とはある事象が実際に起こる見込みの程度である。
自然災害のリスク評価においては、この概念は極めて有効に機能する。
東京で震度6以上の地震が30年以内に発生する確率は、過去の地震データ、プレートの蓄積エネルギー、地質構造などから統計的に推計できる。
そしてここが決定的に重要な点だが、こちらがどのような防災対策を講じようと、地震の発生確率そのものは変わらない。耐震補強をしても、防災訓練をしても、地震は同じ確率で起きる。だからこそ「発生確率×影響度」で事前にリスクを定量化し、対策の優先順位をつけるという手法が成立する。
問題の本質１：攻撃者という「意思を持った変数」の存在
自然災害には意思がない。台風は特定の企業を狙わない。しかしサイバー攻撃の向こう側には、意思と知性を持った攻撃者がいる。
攻撃者は標的を選び、偵察し、最も効率的な攻撃経路を選択する。つまり発生確率は、攻撃者の意図、能力、そして標的としての自組織の魅力度によって動的に決まる。
防衛産業の下請け企業と、地方の小規模小売店では、同じ脆弱性を抱えていても脅威の質が全く異なる。前者は国家支援型APTの標的になりうるが、後者が直面するのは日和見的なランサムウェアが主だろう。「発生確率：中」という評価は、この決定的な差異を覆い隠してしまう。
問題の本質2：防御が確率を変え、確率が攻撃を変える
そしてより本質的な問題がある。
サイバーリスクにおいては、対策そのものが発生確率を変える。
EDRを導入すれば、ある攻撃手法の成功確率は下がる。MFAを有効化すれば、認証情報窃取による侵入の確率は劇的に下がる。
しかし、攻撃者もまたこちらの防御態勢を観測し、適応する。
EDRを検知した攻撃者はEDRを回避する手法に切り替える。MFAが導入されていれば、ソーシャルエンジニアリングでMFA疲労攻撃を仕掛ける。
つまりこちらの対策が攻撃者の行動を変え、攻撃者の行動の変化が再び発生確率を変える。
これは金融市場における「再帰性（reflexivity）」と同じ構造だ。
市場参加者の認識が価格を動かし、動いた価格が参加者の認識をさらに変える。
著名なアナリストが「この株は上がる」と発言すれば、その発言自体が買いを誘発し株価を押し上げ、その結果が「やはり上がった」という認識を強化する。
発生確率と観測者が相互に影響し合うこの構造では、確率を事前に静的な値として確定させることができない。
サイバーリスクもまさにこの再帰的構造の中にある。ある脆弱性の「発生確率」を評価した瞬間、その評価に基づいて対策が講じられ（あるいは講じられず）、対策状況を受けて攻撃者が行動を変え、結果として「発生確率」は評価時点とは別の値になっている。
なぜ私達はこのような過ちを犯してしまうのか
「リスク＝影響度×発生確率」の出自は、ISO 31000やCOSOに代表されるEnterprise Risk Management（ERM）の文脈にある。ERMが対象とするのは、財務リスク、オペレーショナルリスク、コンプライアンスリスク、そして前述した自然災害のようなリスクだ。
これらのリスクには共通する性質がある。発生確率が統計的に（一定程度）推計可能であり、こちらの対策状況によって発生確率そのものが変わらないということだ。
地震の発生確率は耐震補強をしても変わらない。
為替変動のリスクはヘッジ戦略を組んでも為替そのものの変動確率は変わらない。
工場の火災発生率は過去の統計データから合理的に推計できる。
だからこそ発生確率を事前に見積もり、影響度と掛け合わせ、対策の費用対効果を算出するという手法が有効に機能する。
問題は、このERMのフレームワークをそのままサイバーリスクに輸入したことだ。
背景には合理的な理由もある。経営層はERMの「影響度×発生確率」のマトリクスに慣れている。
取締役会への報告フォーマットも、他のリスク領域と統一したい。
リスク管理部門としては、サイバーリスクだけ別のフレームワークで報告するのは管理上の手間が増える。
こうした組織的な力学が、フレームワークの適合性を検証しないままサイバー領域への適用を推し進めてしまったのだと考えている。
しかし前述の通り、サイバーリスクはERMが前提とする性質を持たない。
発生確率は攻撃者の意図により動的に変化し、こちらの対策が確率そのものを変え、さらに攻撃者がそれに適応する。自然災害のような統計的に安定した確率分布は存在しない。どちらも「確率」を扱ってはいるが、その確率の性質が根本的に異なる。
どのようなアプローチを取るべきか
代替案1：セキュリティリスク＝脅威☓脆弱性☓影響度
では何を使うべきか。１つ目はリスクを脅威・脆弱性・影響度の三要素に分解するアプローチだ。
「影響度×発生確率」モデルの問題は、「発生確率」という一つの軸に、攻撃者の意図、攻撃の技術的実現性、既存対策の有効性という本来異なる要素が混在していたことにあった。この三要素モデルはそれを明確に分離することができる。
脅威は「誰が、なぜ、どのように攻撃してくるか」を評価する。攻撃者の意図、能力、自組織を標的とする動機がここに入る。当該業界を狙うAPTグループの活動が確認されているのか、それとも日和見的なボットスキャンが主な脅威なのか。PoCが公開されているのか、攻撃がすでに観測されているのか。これらは防御側の対策とは独立した、攻撃側の変数となる。
脆弱性は「攻撃チェーンの中で、この課題がどの段階に位置し、どの程度そのチェーンの成立を容易にするか」を評価する。影響度のセクションで述べた通り、個別課題は攻撃チェーンの一ステップを容易にする要因だ。であれば評価すべきは、その要因がチェーン全体の成立にどれだけ寄与するかである。
ここで重要になるのが、その課題がチェーンのどの位置にあるかだ。Initial Accessに関わる課題（VPN脆弱性、公開サーバーのRCE）は、チェーンの起点を開くものであり、これが突破されなければ後続のステップはそもそも発生しない。一方、Persistence（永続化）やLateral Movement（横展開）に関わる課題は、チェーンの中盤から終盤を容易にする要因だ。前者はチェーンの成立そのものを左右し、後者はチェーンが進行した場合の被害拡大を左右する。同じ「脆弱性：高」でも、その意味合いが異なる。
さらに、チェーンの各ステップに他の防御レイヤーが存在するかも評価に含まれる。特権IDが共有されていても、そこに至るまでにネットワーク分離、EDRによる検知、SOCの監視といった防御が存在するなら、チェーン全体の成立可能性は下がる。逆にこれらが一切なければ、一つの脆弱性がチェーン全体を成立させてしまう。脆弱性の評価とは、その課題を単体で見ることではなく、攻撃チェーンの中での位置と、周囲の防御レイヤーの有無を含めて判断することが求められる。
影響度は「攻撃チェーンが完遂した場合に何が起きるか」を評価する。前のセクションで論じた通り、これは個別課題の属性ではなく、最終的に到達する資産・業務の重要度（顧客データの規模、事業停止時の損害額、規制上の罰則）で決まる。
ここで「結局、重要な資産に関わる課題は全部影響度が高くなるのでは」と思うかもしれない。その通りだ。
しかしそれでいい。従来モデルで「全部高になる」ことが問題だったのは、影響度が実質的に唯一の差別化軸だったからだ。三要素モデルでは、影響度が同じ「高」であっても、脅威と脆弱性の評価で優先順位が分かれる。同じ顧客DB50万件に至る攻撃チェーンであっても、インターネットから即座に悪用可能な課題と、内部侵入を前提として複数ステップを要する課題では、リスクレベルは全く異なる。影響度は優先順位をつけるための軸ではなく、対策の必要性を判断するための前提条件として機能する。
代替案2：攻撃の成立可能性
代替案1の「脅威×脆弱性×影響度」は非常に実施するのに時間と専門知識が問われる。そのような場合には、攻撃の成立可能性を軸にしたリスクレベル定義が有効である。
考え方はシンプルで、この課題が存在することで、攻撃者はどの程度容易にそのステップを成立させられるかを問う。
| リスクレベル | 判定基準 |
|---|---|
| HIGH | 攻撃ステップの成立条件がほぼ揃っている。悪用される可能性が高い |
| MEDIUM | 潜在的なリスクはあるが、攻撃ステップの成立には追加条件が必要 |
| LOW | ベストプラクティスからの逸脱。直接的な攻撃成立性は低い |
ここで注意すべきは、「攻撃の成立」が意味する範囲だ。これは攻撃チェーン全体の完遂——すなわち最終的な情報漏洩や事業停止——を指しているのではない。その課題が関わる攻撃ステップ単体が成立するかどうかを問うている。
「影響度×発生確率」のマトリクスとの決定的な違いは、評価軸が「確率」ではなく「条件」になっている点だ。「この攻撃が発生する確率は何%か」という、前述の通り原理的に答えられない問いの代わりに、「この攻撃ステップが成立するために、あと何が必要か」という、技術的に検証可能な問いを立てる。
とはいえ「セキュリティリスク＝影響度☓発生確率」が便利なときもある
ここまで「影響度×発生確率」モデルの問題点を論じてきたが、このフレームワークが便利な場面は存在する。
取締役会やCxOへの報告の場で、「この課題はMITRE ATT&CKのInitial Accessに位置する脆弱性で、脅威アクターのTTPsを踏まえると攻撃ステップの成立条件が……」と説明して、果たして何人が最後まで聞いてくれるだろうか。経営層が求めているのは「で、どれくらいヤバいの？」「うちは大丈夫なの？」という問いへのシンプルな回答だ。そしてその回答フォーマットとして、他のリスク領域（財務、法務、コンプライアンス）と統一された「影響度×発生確率」のマトリクスは、確かにわかりやすい。
ここは日本人お得意の本音と建前を使い分ければいい。
建前（経営層向け報告）では、経営層が慣れ親しんだ「影響度×発生確率」のマトリクスで報告し、他のリスク領域と横並びで比較できるようにする。
本音（実務の現場）では「脅威×脆弱性×影響度」と攻撃成立可能性で評価する。アセスメント結果を分析し、対策の優先順位をつけ、具体的な対応計画を策定する。そして経営層に報告する段階で、その結果を「影響度×発生確率」のマトリクスに翻訳する。
重要なのは、この翻訳の方向だ。「影響度×発生確率」で評価してから対策を決めるのではなく、三要素モデルで評価・対策を決めてから、報告用に「影響度×発生確率」に変換する。順序が逆になった瞬間に、すべての問題が再発する。
最後に
私自身、セキュリティアセスメントを提供する立場として心がけていることがある。
まず、自分が携わるプロジェクトでは「影響度×発生確率」のフレームワークを使わない。本当は会社全体でそうしたいが、まずは自分の手が届く範囲から。アセスメントの成果物が実際にクライアントの意思決定に使われるものである以上、その土台となるフレームワークの妥当性は譲れない一線だと考えている。
そしてもう一つ、より重要なことがある。
「セキュリティリスク＝脅威×脆弱性×影響度」で評価するということは、攻撃者の視点でリスクを見るということだ。この脆弱性は実際に悪用可能か。攻撃チェーンのどこに位置するか。他の防御レイヤーで阻止できるか。これらを判断するには、チェックリストの文面を読んでYes/Noをつけるスキルとは根本的に異なる、攻撃の技術的知識が求められる。
だからこそ、アセスメントチームには必ず攻撃者のスキルを持つ人間を入れるようにしている。そしてそのスキルを持たないメンバーには、そこに到達できるよう教育している。フレームワークを変えるということは、求められる人材の質を変えるということでもある。
最後に、この記事を読んでくださった方にお願いがある。
次にコンサルやベンダーから「影響度×発生確率」のマトリクスが出てきたとき、ぜひ一言聞いてみてほしい。
「それ、サイバー攻撃に対しては不適切ではないですか？」
その一言が、形骸化したアセスメントを変える最初の一歩になるかもしれない。