多くの組織が、サイバーセキュリティプログラムの中核的な要素としてリスクベースの脆弱性管理を導入しており、CVSSのみに基づくトリアージにとどまらず、優先順位付けの枠組みを構築し、 のサイバー脅威インテリジェンスフィード、スキャナー、および の脆弱性修正 ワークフローへの投資を進めています。 しかし、是正措置の待ち行列は依然として機能不全に陥りがちであり、リスクスコアはIT運用部門からの信頼を得ることが難しく、チームは経営陣に対して測定可能なリスク低減を実証することに依然として苦労しています。
この記事では、カバレッジのインフラからスコアリングモデル、チーム間の連携、そしてプログラムがリスクを低減していることを証明するKPIに至るまで、各課題の解消方法について順を追って解説します。これにより、チームは組織が現在直面している脅威に確実に対応できるようになります。
なぜほとんどのRBVMプログラムは、スケールアップする前に停滞してしまうのでしょうか
従来の の脆弱性管理 から移行する組織では、RBVMが克服することを目的として設計されたのと同じ弱点――資産の可視性の不十分さ、検証されていないスキャナーの検出結果、およびセキュリティ部門とIT運用部門間の引き継ぎが不明確であること――を引きずっていることがよくあります。 しかし、ほとんどのチームは、リスクに基づく優先順位付けの原則を理解することの方が、むしろ簡単なことだと感じています。 これらを企業環境全体で一貫して適用することには、さらなる課題が生じます。
その仕組みは単純明快です。 プログラムがうまくいかなくなるのは、実行の段階です。
RBVMの失敗の大部分は、以下の3つのインフラストラクチャ上の課題に起因しています：
- のアセット可視性の不備: 脆弱性データの一部に基づいて算出されたリスクスコアは、不完全な保護しか提供しません。 エンドポイントが管理対象外であったり、スキャンされていなかったり、古いデータを返していたりする場合、リスクキューには、いかなる優先順位付けモデルでも解決できない死角が生じます。
- 検証されていないスキャナーの結果： スキャナーの出力は、確認された被ばく量とは異なります。 スキャンデータが古かったり、資産管理の状態が不十分だったりする環境では、誤検知率が著しく高くなり、IT運用部門がキューへの信頼を失い、対応が全体的に遅れてしまう可能性があります。
- 管理されたハンドオフモデルはありません： Security が識別し、優先順位を決定します。 IT運用部門が是正措置を講じます。 明確な責任の所在、リスクに応じたSLA、および例外管理がなければ、発見事項は宙ぶらりんのまま積み上がってしまいます。
[脅威および脆弱性管理の仕組み、CVSSスコアを超えた優先順位付けが重要な理由、そして検知と是正措置を連携させることで現実のリスクをどのように低減できるかを理解しましょう]
補償の要件
サイバーリスクスコア（ ）の精度は、その算出の基礎となる資産インベントリおよびエンドポイントの状態データの精度に左右されます。 カバー範囲は、資産の数だけで測られるものではありません。 それは、そのシステムの最新の構成、パッチの適用状況、および脆弱性への曝露状況が継続的に把握されているかどうかにかかっています。 それがなければ、優先順位付けモデルは、不完全なリスクの表現に基づいて動作することになります。
補償の空白が生じる場合
企業環境では、予想される箇所でセキュリティの死角が生じます。 管理対象外のデバイス、外部業者のノートパソコン、モバイルデバイス、コンテナ、OTおよびICS資産、IoTデバイス、シャドーIT、ならびにエージェントが古くなっている、またはレポート機能を持たないエンドポイントは、すべて標準的なスキャン対象外となります。
OTおよびICS資産には、それぞれ異なる対策戦略が必要です。 多くの組織では従来型のエージェントを導入できない上、積極的なスキャンは業務の混乱を招く恐れがあり、パッチが提供されていないレガシーソフトウェアも珍しくありません。 こうした資産については、是正措置ではなく、代償的統制がリスク低減の主要な手段となります。そのため、対応計画は当初からその点を反映させる必要があります。
開発環境にも同様の死角が存在します。DevOpsのCI/CDパイプライン を通じて導入された脆弱性 は、本番環境に到達するまで発見されないことが多く、本番環境での修正ははるかに大きな混乱を招くことになります。
200 台の管理対象エンドポイントに検出された脆弱性は、リスクキューに登録されることのない50 台の非管理対象デバイスにも存在する可能性があります。 この写真は完成しているように見えますが、実際の露出範囲は目に見える範囲よりも広くなっています。
スキャンラグが得点に悪影響を及ぼす理由
定期的なスキャンでは、現在の攻撃対象領域ではなく、過去の状態を反映したスコア結果が得られます。 パッチの適用サイクル、デプロイ、および設定の変更が絶えず行われる動的な環境では、スキャンの遅れがわずかであっても、リスクスコアが実際のリスク状況を反映しなくなる恐れがあります。
エンドポイントの状況をリアルタイムで把握することで、定期的なスキャンによる遅延が軽減され、リスクスコアの算出基盤がより正確なものとなります。 の継続的な監視向けに設計されたプラットフォーム（ ）は、頻繁に更新されるエンドポイントのテレメトリデータを提供するため、優先順位の決定は数日前のスナップショットではなく、実際の状況を反映したものとなります。
資産の可視化は、一度きりのプロジェクトではありません。 これは継続的な修練です。 それがなければ、どんなに洗練されたスコアリングモデルであっても、実際のリスク状況を反映していない順位付け結果となってしまいます。
リアルタイムの可視化が実現したら、次に浮かぶ疑問は、「チームが信頼できるリスクスコアをどのように構築するか」ということです。
リスクスコアは実際にはどのように算出されるのか
誰も信用しないリスクスコアは、スコアがないよりも悪いものです。 効果的なリスク評価は、明確かつ透明性の高い方法論から始まります。その方法論においては、入力項目、重み付け、および採点ロジックが、セキュリティチームとIT運用チームの双方に理解されている必要があります。 信頼を築くには、それらの入力値と重み付けがどのように組み合わさってスコアが算出されるのか、その仕組みを明確にすることが必要です。
同様に重要なのは、チームが、基礎となるデータが古いスナップショットではなく、システムのリアルタイムの状態を反映しているという確信を持てることです。そうして初めて、優先順位の決定に基づいて具体的な行動をとることができます。
RBVMのリスクスコアを算出するための4つの主要な入力項目は何ですか？
RBVMリスクスコアは、CVSSの基本深刻度（技術的な欠陥の深刻度）、EPSSの悪用確率（実環境での悪用が発生する可能性）、CISA KEVステータス（悪用が確認されているかどうかの情報）、および資産の重要度（業務機能とデータの機密性）を組み合わせて、実環境におけるリスクの優先順位を決定します。
| 入力 | 測定対象 | なぜそれが重要なのか |
|---|---|---|
| CVSSのベース深刻度 | この脆弱性の技術的な深刻度 | 深刻度の基準値を提供しますが、この基本スコアには実環境の文脈や悪用可能性*は反映されていません。 |
| EPSSの悪用確率 | 野生下での搾取の可能性 | 現在の脅威アクターの行動を反映し、新たなエクスプロイト活動が確認されるたびに変化する動的なシグナル |
| CISA KEVのステータス | その脆弱性が実際に悪用されているかどうか | 実世界における兵器化の二値指標 |
| 資産の重要度 | 業務機能、データの機密性、情報漏洩リスク | アセットが侵害された場合の爆風範囲を決定します |
* CVSS v3.x には、文脈を追加することを目的とした「時間的」および「環境的」なスコア調整係数が含まれていますが、これらは企業のセキュリティプログラムにおいて、大規模に運用されることはほとんどありません。
これらの情報は、新たに公開されたエクスプロイトに関するデータ、新たな攻撃手法、および更新された悪用確率スコアなど、最新の脆弱性インテリジェンスによって継続的に更新される場合に、最も効果を発揮します。 どの業界が積極的に標的とされているか、どのようなエクスプロイトキットが流通しているかといった脅威の状況を把握することで、お客様の特定の環境におけるスコアの重み付けをさらに精緻化することができます。
横方向の移動の可能性（）、すなわち影響を受ける資産のネットワーク上の位置や曝露経路も、さらなるリスク調整要因として作用します。 隔離されたテストサーバー上の脆弱性は、機密性の高い顧客データへのネットワーク経路上にあるドメインコントローラーやアプリケーションサーバー上の同じ脆弱性とは、異なるリスクを伴います。
[脆弱性評価とは何か、ペネトレーションテストとの違い、そして定期的なスキャンよりも継続的な可視性がなぜ重要なのかについて学びましょう]
リスクベースのアプローチの具体例にはどのようなものがありますか？
次の2つの脆弱性について考えてみましょう：
脆弱性 A： 、CVSS 9.8 （重大）、EPSS 0.02 （悪用可能性が低い）、CISA KEVには掲載されておらず、横方向の移動経路がない孤立したテストサーバーに影響を及ぼします。
脆弱性 B： （CVSS 7.5 ：高、EPSS 0.85 ：悪用確率高）、CISA KEV に掲載されており、顧客データベースへの横方向アクセスが可能な本番環境の支払い処理サーバーに影響を及ぼします。
CVSSのみを考慮すれば、AがBよりも優先順位が高くなります。しかし、 のリスクベースのモデル（ ）では、機密データへの横方向の移動経路を持つ本番環境の決済サーバーは、ランサムウェアや恐喝キャンペーンが日常的に狙うことで知られる、価値が高く、攻撃可能な標的であるため、Bの優先順位を正しく引き上げています。
その転換こそが、リスクベースのプログラムにおける脆弱性の優先順位付けの真の意義なのです。
しかし、優先順位付けだけでは、是正措置が実施され、その完了が確認されない限り、リスクを低減することはできません。
[リスクベースのパッチ適用、段階的な展開、および継続的なコンプライアンス追跡が、脆弱性の開示から悪用されるまでのギャップを企業が埋めるのにどのように役立つかをご覧ください]
具体的な重み付けの比率は組織やリスク許容度によって異なりますが、一般的な原則として、動的な脅威シグナルやビジネス上の状況は、静的な深刻度よりも優先されるべきであり、またそうすべきです。
スコアリングは、優先順位の決定だけでなく、是正措置の実行を管理する上でも重要な役割を果たしています。 プログラムが自動化に向けて成熟するにつれ、信頼性スコアリングを活用することで、人間の確認なしに大規模に展開しても安全なアクションと、段階的な導入や手動による承認が必要なアクションを見極めることができます。
リスクスコアは高いものの、特定のOSバージョンにおけるパッチの安定性について不確実性がある脆弱性については、直ちに適用するよりも、段階的な展開を行う方が適切である場合があります。 信頼性の閾値を是正ワークフローに整合させることで、組織は運用リスクを高めることなく自動化を拡大することができます。
しかし、たとえ構成の整ったスコアであっても、その根底にある調査結果が真実でなければ意味がありません。 そこで、検証が重要になってきます。
行動を起こす前に、エクスポージャーを確認する
スキャナーによる陽性反応は、感染が確認されたこととは異なります。 検証されていない調査結果に基づいて行動することは、是正措置の能力を浪費するだけでなく、RBVMプログラムの基盤となるチーム間の信頼を損なうことになります。 検証とは、そのギャップが拡大する前に、チームがそのギャップを埋めるための方法です。
[脆弱性スキャンツールの仕組み、企業環境における評価方法、そして「検知」と「実証済みのリスク低減」の違いについてご紹介します]
「バリデーション」とは何か
「確認済みの曝露」とは、現在のエンドポイントの状態および構成データに基づき、エンドポイント上に存在することが確認され、かつ代償的対策によってすでに軽減されていないと判明した事象を指します。 バリデーションは、次の3つの疑問に答えます：
- の脆弱性が確認されているソフトウェア「 」のバージョンは、実際にインストールされており、動作しているのでしょうか？
- 補償制御によって、すでにリスクは軽減されているのでしょうか？ ネットワークのセグメンテーション、WAFルール、および設定の堅牢化は、いずれも悪用されるリスクを低減することができます。
- その資産は現在も稼働しており、アクセス可能でしょうか？
このレベルの信頼性があれば、組織は、その過程で新たなリスクをもたらすことなく、 修正手順を 安全に自動化することができます。
なぜ誤検知が信頼を損なうのか
企業環境においては、スキャナーの設定、資産の状態、およびスキャンが実施された時期によって、誤検知率は大きく異なります。 正確な数値がどうであれ、大規模な環境において、たとえわずかな偽陽性率であっても、検出結果が是正措置の待ち行列に入る前に検証されなければ、IT運用部門の処理能力を圧倒してしまう可能性があります。 脆弱性スキャンの情報が古くなっていること、是正措置が考慮されていないこと、およびすでに運用を終了した資産などが、すべて要因となっています。
IT運用部門に報告される誤検知1件ごとに、リスクの是正に充てられたはずの時間が失われてしまいます。 時間が経つにつれて、ITチームはこのキューに対して懐疑的な見方をし始めます。 対応が遅くなり、待ち行列の信頼性が失われてしまいます。
例外処理こそが、整然としたキューと雑多なキューを分ける要素です。 許容リスク、補償済みのエクスポージャー、および廃止措置済みの資産に関する調査結果を排除する正式なワークフローにより、アクティブなキューには、実際に未解決のエクスポージャーのみが反映されるようになります。 この仕組みがなければ、優先順位が適切に設定されたキューであっても、ノイズが蓄積され、時間の経過とともにIT運用担当者の信頼を損なうことになります。
信頼を取り戻すためには、組織にはより優れたランキングモデル以上のものが必要です。 彼らは、特定された問題が最新の状況を反映していること、および是正措置が効果的であることを確信する必要があります。
つまり、是正措置によって、単にチケットのクローズやステータスの更新にとどまらず、システムの状態に確認可能な変化が生じたかどうかを追跡するということです。
[真に継続的な脆弱性管理プログラムと、単に頻繁にスキャンを行うだけのプログラムとの違いについてご確認ください]
Taniumがリスクベースの脆弱性管理をどのように支援するか
ほとんどの組織は、どの脆弱性が最も重要であるかをすでに把握しています。 より難しいのは、その知見に基づいて、迅速かつ一貫性を持って、かつ大規模に行動を起こすことです。 Tanium Exposure Management は、リスクベースの脆弱性管理プログラムの停滞を招く実行上のギャップを解消し、リアルタイムの可視化、優先順位付け、是正措置、および検証を単一のプラットフォーム上で統合します。
IT資産のリアルタイムな可視化
Taniumは、エンドポイント、管理対象外のデバイス、コンテナレジストリ、およびKubernetesワークロードについて、脆弱性やコンプライアンス上の不備がないか継続的に監視します。 Tanium Cloud Workloadsは、イメージレジストリの可視化や脆弱性スキャン、ランタイムコンテナ分析、Kubernetesポリシーの適用を通じて、この対応範囲をコンテナ化された環境にまで拡大します。 このプラットフォームは、他のツールが見逃してしまう資産を検知するため、カバー範囲の空白が縮小します。
現状に基づいたリスクスコアリング
エンドポイントレベルおよび組織レベルのリスクスコアは、静的なCVSSスコアでは把握できない「脆弱性の深刻度」「資産の重要度」「コンプライアンス違反」「横方向の移動リスク」といった要素に加え、業界内の同業他社とのベンチマーク結果を組み合わせて算出されます。 スコアは、定期的な特定の時点のスナップショットではなく、エンドポイントの現在の状態を反映しています。 Tanium Benchmark を利用することで、セキュリティ責任者は自社のリスク状況を業界の同業他社と比較することができ、脆弱性データを、経営陣やコンプライアンスチームが必要とする成果重視の指標に変換することができます。
統合的な修復
各チームは、同じプラットフォーム上で、評価から実行へと移行します。 パッチの適用、設定の変更、その他の管理措置を、ツールを切り替えることなく大規模に実施することができます。 Tanium Comply は、SCAP および OVAL コンテンツに加え、毎日更新される Tanium 独自のコンテンツライブラリを活用し、オペレーティングシステム、アプリケーション、ソフトウェアサプライチェーン、およびセキュリティ設定に対する脆弱性評価とコンプライアンスチェックをサポートしています。
管理された自動化
Tanium Automate を利用することで、チームは、反復的な是正タスクを自動化するノーコードおよびローコードのプレイブックを作成することができます。 プレイブックは、実行前にオペレーターの承認を必要とすることができ、大規模な運用においても責任の所在を明確に保つことができます。
閉ループ検証
修正が適用された後、Comply評価を実行することで、脆弱性が解消されたかどうかを確認し、それに応じてリスクスコアを更新します。 Taniumでは、完全な定期スキャンサイクルを実行する必要はなく、オンデマンドでこの評価を実行することができます。
ITとセキュリティを統合したワークスペース
両チームは、単一の統合プラットフォーム上で、同じリスクスコア、同じ優先順位付けデータ、そして同じ是正状況を基に業務を行っています。 この共有運用モデルにより、セキュリティ部門とIT運用部門が別々のツールやデータソースに依存している場合に、問題の是正を遅らせる調整の負担を軽減することができます。
Tanium Guardian
Tanium Guardianは、Tanium脆弱性緊急対応チーム（VERT）の専門家が厳選したガイダンス「 」を通じて、新たな脅威を明らかにし、各チームがゼロデイ攻撃や時間的制約のあるリスクに自信を持って対応できるよう支援します。 各チームは、Tanium Autonomous IT Platform 内で直接、是正措置を実行することができます。
これらの機能が連携することで、問題の発見から検証済みの是正措置の実施に至るまでのサイクルを短縮します。 Ring Power Corp.（ ）は、Taniumを活用して、すべてのエンドポイントにわたるLog4j 件の脆弱性を約30 分で洗い出しました。同社チームによると、従来のツールを使用していた場合、この作業には数ヶ月を要していたと見込まれています。
検出、優先順位付け、および是正措置が単一のプラットフォーム上で統合されることで、リスクベースの脆弱性管理プログラムは、脅威の状況が求めるスピードで進めることができます。
[継続的な脅威への曝露管理の仕組み、なぜ検証がパッチ適用よりも重要なのか、そしてそれが実際のセキュリティリスクの低減にどのように役立つのかについて理解しましょう]
リスクベースの脆弱性管理に関するよくある質問
よく理解されているフレームワークであっても、実際の導入にあたっては疑問が生じることがありますが、RBVMも例外ではありません。 以下の回答では、チームがRBVMを実践する際に直面する、最もよくある疑問点について解説しています。
RBVMは、従来の脆弱性管理とどのように異なるのでしょうか？
従来の脆弱性管理では、CVSSの深刻度スコアのみに基づいて優先順位を決定しますが、RBVMでは、悪用される可能性や資産の重要度も考慮し、実際のビジネスリスクをもたらす脆弱性に焦点を当てています。 例えば、悪用されやすい支払いサーバー上のCVSS 7.5 の脆弱性は、隔離されたテストシステム上のCVSS 9.8 の脆弱性よりも優先順位が高くなる可能性があります。
リスクベースの脆弱性管理は、サイバーセキュリティ対策にどのような改善をもたらすのでしょうか？
RBVMは、攻撃者が現在積極的に悪用している、あるいは悪用される可能性が最も高い脆弱性に対して、修正リソースを集中的に投入することで、防御体制を強化します。 これにより、最も重大な脆弱性に対する是正までの平均所要時間を短縮し、IT運用部門が真のリスクを伴う発見事項に注力できるようになります。
[ITの自動化がどのように機能するのか、なぜ運用リスクを低減できるのか、そしてITチームがより付加価値の高い業務に集中できるようになる仕組みについてご紹介します]
リスクベースの脆弱性管理を実施するには、どのようなツールが最適でしょうか？
効果的なRBVMプログラムには、通常、以下のいくつかの分野にわたる機能が求められます。すなわち、継続的な資産の検出とインベントリ管理、脆弱性スキャンと情報補完（EPSSスコアやCISA KEVステータスを含む）、是正措置の割り当てのためのITSMツールとのワークフロー統合、および導入された修正措置によって問題が解決されたことの検証です。
組織によっては、複数の単機能ツールを組み合わせて、こうした機能を実現しています。 また、資産の可視化、リスク評価、および是正措置を単一のワークフロー・プラットフォームに統合している企業もあります。 適切なアプローチは、既存のツールスタックやチームの体制、そしてエンドポイントの可視化がすでに解決済みの課題であるかどうかに依存します。
Tanium Autonomous IT Platformは、リアルタイムのエンドポイント情報を統合されたワークフローや是正措置と結びつけ、セキュリティチームやITチームが、共有された正確なリスク状況に基づいて業務を行えるよう支援します。
チームは、手動でのフォローアップや古いデータに頼ることなく、より迅速に対応し、引き継ぎの遅れを短縮し、環境全体にわたる是正措置の結果を確認することができます。
どの脆弱性が最も重要かを把握することは、問題の半分に過ぎません。 これらの課題を迅速かつ一貫性を持って、かつ大規模に解決することこそが、多くのプログラムが行き詰まる原因となっています。
今すぐ無料のカスタマイズされたデモをご予約ください 。Taniumが、リアルタイムの可視化、優先順位付け、および是正措置を単一のプラットフォームでどのように連携させているかをご確認ください。
