QualysでEMEA地域のVP Risk Technologyを務めるIvan Milenkovic氏が、セキュリティリーダーが意思決定に金額の裏付けを持たせるための経済モデルの作り方を解説します。同氏は、まず少数の損失シナリオを設定し、そこから損失を左右する資産へと掘り下げていく方法を勧めています。
インタビューでは、想定損失額(バリュー・アット・リスク)に基づく修正の優先順位づけ、CFOが求める情報、発生しなかったインシデントの価値の示し方を取り上げています。さらに、1つのモデルで取締役会とサイバー保険の引受担当者の双方に対応する方法にも触れています。
多くのセキュリティチームは、前四半期に何件の脆弱性を修正したかを取締役会に報告できますが、その作業が金額にしてどれほどの価値を生んだかを説明できるチームはごくわずかです。CISOが初めて経済モデルを構築する際、どこでつまずくことが多いのでしょうか。
経済モデルは、価値に関する意思決定を支えるために存在します。しかし、私が見てきたセキュリティモデルの多くは、そこまで到達していません。スコアから始まってスコアで終わり、「これは問題ないか」「赤い項目から先に直すべきか」といった議論に終始します。私たちは努力そのものを称え合うだけで、その努力にどれほどの価値があったのかを、取締役会は何も知ることができません。
信用スコアが参考になります。貸し手のスコアは、金銭に関する問いを土台にしています。この借り手がこの金額を返済しない確率、あるいは期日どおりに返済しない確率はどれくらいか、という問いです。この問いをめぐっては巧みなモデリングが数多くありますが、核心にあるのは価値関数です。数学的な裏付けがあり、潜在的な損失に結びついているからこそ、スコアに意味があります。
セキュリティのスコアリングの多くには、そのような拠り所がありません。私たちは長年、技術がどれほど複雑か、変化にどれだけ追随しなければならないかを測ってきました。ところが、そうした問題が時間の経過とともにビジネスに及ぼす影響をコストとして見積もることには、ほとんど時間を割いてきませんでした。初めて作るモデルが失敗するのはここです。1万件もの検出結果から出発して、金額へとたどり着こうとしてしまうのです。
私は、CISOに順序を逆にすることを提案しています。本当に痛手となるシナリオを少数挙げるのです。たとえば、決済プラットフォームが3日間停止する、顧客データについて規制当局から通知が届く、ある地域全体でランサムウェアが発生する、あるいは自組織に当てはまるものなら何でもかまいません。各シナリオに損失の幅を設定し、そこからその損失を左右する資産やエクスポージャーへと掘り下げていきます。
最初のバージョンは間違っているはずです。初期の信用モデルも誤りを含んでいましたが、実際の結果を取り込み続けたことで改善しました。皆さんのモデルも、入力値がシステムから直接得られるものであれば、同じように改善していきます。CISO時代に私が守っていたルールは、今も変わりません。人の手が加わった数字は信用しない、というものです。
何千件もの検出結果が注目を奪い合うなか、何から修正するかを決めるのは政治的な問題になりがちです。重大な欠陥が価値の低い資産にある場合と、中程度の欠陥が収益を生むシステムにある場合とで、経済モデルはどう判断すべきでしょうか。
政治的になるのは、テーブルに載る根拠が技術的なものだからです。技術的な議論だけで予算をめぐる争いに決着がつくことはまずありません。どのセキュリティチームも、何をするのが「正しい」かは分かっていながら、予算や人員が足りずに実行できなかった経験があります。そうなると、ビジネス側が耳を貸さないせいだと責めたくなるものです。しかし、より良い問いは、取締役会が判断するために何を提示したのか、そしてなぜ説得できなかったのか、というものでしょう。
モデルは、想定損失額、つまり「何を失う可能性があるか」に基づいて判断すべきです。もっと簡単に言えば、この特定のエクスポージャーが、起こりうる将来の損失をどれだけ押し上げるのか、ということです。誰も使っていないテスト用サーバーの重大な欠陥が加える損失は、ほぼゼロです。一方、インターネットに公開された収益システムにある中程度の欠陥は、特に攻撃者がすでに悪用している場合、損失を大きく押し上げる可能性があります。私はかつて、まさにこの理由でグループ内の最下位と評価された事業部門と仕事をしたことがあります。収益と無関係で、CVEだらけのサーバーの山が、決済ゲートウェイと同じスコアで評価されていました。そのため、チームは見当違いのマシンのパッチ適用に時間を費やしていたのです。
こうしたことをモデル化する数学は存在しますが、予測に基づいて動きます。必要なのは軽量なモデルです。そのモデルは、2つの点について素早く、かつ説明のつく見方を示してくれます。1つはリスクがもたらす潜在的な損失、もう1つは対策を講じることで得られる利益で、修正が商業面で可能にすることも含みます。CEOは、社内のほかのあらゆる意思決定で、この種の情報を使っています。
どこまで詳細に示すかも検討に値します。資産レベルや脆弱性レベルの文脈はモデルに取り込む必要があります。優先度や事業への影響という点で、テスト用サーバーと決済ゲートウェイを分けるのはその部分だからです。ただし、取締役会が個々のCVEについて議論すべきではありません。取締役会が問うのは、失う可能性のあるものに対して、全社の統制が適切に拡大しているかどうかです。AIが脆弱性の発見に与えた影響により、この問いに答えるのは難しくなっています。あるフロンティアモデルだけで、1,000以上のオープンソースプロジェクトから、深刻度が高または重大と見られる欠陥の候補が6,000件以上見つかりました。これをすべて修正できる人はいません。今求められる対応は、どの問題が重要かを明示し、見送ると判断した問題には署名を添えることです。
セキュリティ担当者は、起こらなかったインシデントの価値を常に証明しなければなりません。「何も起きなかった」ことを、財務部門が評価するリターンとして分かりやすく示すには、どうすればよいでしょうか。
CFOは日々それを行っています。保険と資本準備金を管理し、最悪の日に備えて計画を立てているからです。サイバー損失は、CFOが考慮すべき損失の一種にすぎません。あらゆるリスクについてCFOが抱く問いはシンプルです。自社のエクスポージャーを踏まえると、損失が限度額を超え、手元資金に打撃を与える可能性はあるか、というものです。
保険と財務部門は、限度額や準備金を決めるために同じ種類のモデリングを使っています。ブローカーの背後にいるアクチュアリーは、すでに皆さんのIT組織に対しても同じモデルを回しています。違いは、残存するサイバーリスクについて、彼らのほうが皆さんより知らないという点です。財務の観点から見れば、皆さんの仕事は、チームやセキュリティ統制、投資を使って起こりうる将来の損失を減らし、財務上の安全網を突破する確率を、事業が定めた限度内に収めることです。
「何も起きなかった」ことが、それだけで証拠になることはありませんし、なるべきでもありません。皆さんも何もしていないわけではありません。ですから、そうした統制は(ダジャレで恐縮ですが)きちんと「勘定」に入れるべきです。財務部門は測定可能な変化を評価します。何が動いたかを報告しましょう。
- 損失シナリオの背後にあるシステムで、重大なエクスポージャーが残存した期間(今四半期と前四半期の比較)
- 修復期限を過ぎたエクスポージャーに、どれだけの想定損失が含まれているか
- テストの際に統制が機能したか(たとえば、リストアが成功した、レッドチーム演習がセグメンテーションの境界で食い止められた、など)
- 市場がどう見ているか(引受担当者は現在、サイバー統制をより細かく評価して価格を決めているため、更新時に条件が改善すれば、それは皆さんのプログラムに対する外部からの評価になります)
これらの指標は、単独では完璧ではありません。見るべきは時間をかけた推移です。そのため、指標は一貫性を保ち、システムから取得し、財務部門が自らの予測を磨くのと同じように四半期ごとに改善していく必要があります。そうすることで、セキュリティは資金配分を決める議論の席を得られるのです。
CFOがセキュリティリーダーに求めているのに、セキュリティリーダーがほぼ必ず持ってこないものは何でしょうか。
CFOが求めているのは、表計算ソフトに入力できる数字です。幅を持たせた数字で、意思決定が添えられているものです。
セキュリティリーダーは、脆弱性、脅威、平均対応時間といったセキュリティの言葉で話します。その語彙の根底にあるのは二値の発想で、安全か安全でないかのどちらかだと考えます。一方、CFOはお金、パーセンテージ、確率の世界で動いており、白黒がはっきりしていることはほとんどありません。このギャップに苛立つCISOは少なくありません。
社内でリスクの専門家なのは私たちだけではない、と思い出すことが役に立ちます。CFO、CRO、財務責任者は、キャリアを通じて不確実性に値段をつけてきた人たちです。その言葉を学び、持ち込みましょう。取締役会やCFOの技術リテラシーは10年前よりはるかに高まっていますが、それでも翻訳は皆さんの仕事です。
実際には、CFOとの対話のたびに次の4点を持参してください。
- 金額で表した損失シナリオ(幅を持たせたもの)
- 今後12か月でその損失が起きる可能性と、その見積もりの根拠
- 支出を提案する金額と、支出した場合に幅がどこまで動くか
- 支出しなかった場合に何が起きるか(その問題を放置することに誰が署名しなければならないかを含む)
最後の点が、CISOが最も忘れやすいものです。CFOは、誰も責任を負っていないリスクを承認することも却下することもできません。損失を自らの予算で吸収する立場の人が受容に署名しなければならなくなれば、対話は一気に変わります。こうしたシナリオは四半期ごとに追跡できるので、CFOは傾向を確認できます。
サイバー保険の引受とリスク定量化は、同じ問いへと収れんしつつあります。取締役会を満足させるモデルは、引受担当者も満足させるのでしょうか。それとも、2通りのストーリーを用意するのでしょうか。
モデルは1つでも、報告する相手は2つあります。取締役会に1つのストーリーを話し、引受担当者に別のストーリーを話すのであれば、プレゼンテーション以上に大きな問題を抱えています。引受担当者に伝えたことは、保険金を請求する日にも通用するものでなければなりません。
変わるのは、それぞれの相手に何を見せるかです。取締役会は、サイバーリスク定量化の議論に付き合う必要はありません。必要なのは、意思決定を行うための情報、あるいは、その財務情報に基づいてなぜその決定が下されたのかを理解するための情報です。取締役会は通常、皆さんが会議室に入る前から資本に関する決定に慣れています。皆さんの役割は、決定の根拠をしっかりと示すことです。一方、引受担当者が求めるのはその下にある証拠、つまり統制の成熟度、エクスポージャーの期間、どれだけ早く復旧できると見込んでいるかです。保険会社は、統制、プライバシーに関するエクスポージャー、新たに浮上するAIリスクについて、より細かく引受審査を行うようになっています。そのため、モデルを動かすのと同じデータを、申込書にも反映させるべきです。
取締役会への報告は、たとえば次のようになります。
「フロンティアAIモデルがこれまでにない規模で脆弱性を発見しており、当社のバックログは第2四半期に200%増加しました。AIを活用した修復に投資しており、来四半期末までにMythos以前の水準に戻る見込みです。限度額についてはCFO傘下のリスク管理部門と見直しを行い、来月ブローカーと面談して引き上げる予定です。タイミングも有利です。市場は軟調なので、保険料の小幅な上昇で補償を追加できると見込んでいます。」
この報告に何が含まれているか見てください。原因、数字、決定、期日、そしてCFO自身の手段とのつながりです。
タイミングの点は注目に値します。英国のサイバー保険の価格は2026年第2四半期を通じて軟調で、強力な統制を証明できる購入者には、より良い条件が提示されました。専門の引受担当者は、今年中に転換点が訪れると警告しています。誠実なモデルを持つ組織は、その状況が続くうちに最良の条件を手にできるでしょう。
翻訳元: https://www.helpnetsecurity.com/2026/10/08/ivan-milenkovic-qualys-cyber-risk-quantification/
