の脆弱性管理プログラムのほとんど は、自らを「継続的」と称しています。 実際にそうである人はほとんどいません。 この違いは重要です。毎週スキャンを行うにもかかわらず、自らを「継続的」と称するプログラムは、誤った安心感を生み出します。その結果、スキャンサイクルの合間にリスクが放置されたままになる一方で、経営陣は対策が万全であると誤解してしまうのです。
継続的脆弱性管理（CVM）とは、組織のITインフラ全体にわたるセキュリティ上の弱点を発見、分析、優先順位付け、および是正するための、継続的かつ自動化されたプロセスです。 定期的なスキャンとレポートのサイクルとは異なり、CVMは資産の状態や脆弱性の状況をリアルタイムで把握し続けることで、攻撃者が新たに公表された脆弱性を悪用できる時間を短縮します。
本記事では、既存のプログラムが「継続的」という言葉が示す運用基準を満たしているかどうかを評価するための診断フレームワークをご紹介します。ここでは、真に継続的なプログラムと、単に頻度の高いプログラムとを区別する具体的な条件、指標、および調整体制について解説します。
「連続的」という言葉が実際に何を意味するのか、そしてなぜほとんどのプログラムがその条件を満たさないのか
「継続的」と称するプログラムのほとんどは、依然として週単位または月単位のスキャンサイクルで動作しています。 彼らは優先順位付けを一括で行い、手動でチケットを作成し、確認もせずに修正が成功したと決めつけています。 一方、 の攻撃対象領域（ ）は絶えず変化しています。新しい資産が立ち上がり、設定がずれていき、新たに公開されたCVEによって、週次スキャンサイクルでは塞ぐことのできない脆弱性の窓が生じています。
の定期プログラムでは、スキャンやバッチ処理の優先順位付けをスケジュールし、手動でチケットを作成します。 継続的なプログラム「 」は、リアルタイムの状態把握を維持し、条件が変化した際に優先順位付けを行い、閉ループチェックを通じて是正措置の有効性を検証します。
真に連続的なプログラムとは、以下のすべての条件を満たすものです：
- 新しい資産は、数日ではなく、数時間以内に検出され、台帳に登録されます
- 新たに発見された脆弱性については、定義されたSLAに基づき、資産目録全体に対して評価が行われます
- 修復状況は、仮定ではなく、プログラムによって確認されます
ほとんどのプログラムは、これらの特性のうち少なくとも1つを満たせていませんが、その理由は通常、モニタリングの成熟度スペクトル上のどの位置にあるかによって決まります。
[脆弱性の修正プロセスの仕組みについて、修正の順序付けや自動化の管理から、各パッチによって実際に脆弱性が解消されたかどうかの検証に至るまで、詳しくご紹介します]
監視の継続性には、定期的、高頻度、リアルタイムの3つのレベルがあります。
継続的な脆弱性監視という観点において、自社のプログラムがどの位置にあるかを把握することで、「継続的」であることに実際にどれほどのコストがかかるのか、またどのような課題が残っているのかが明確になります。
レベル1： 定期的なスキャン。 スケジュールされたスキャンは、毎週、毎月、または四半期ごとに実行されます。 脆弱性の検出にかかる時間は、数日から数週間単位で測定されます。 各サイクル間には保障の空白期間が存在します。 このアプローチは、安定していて変化の少ない環境では有効ですが、サイクルの途中で生じる脆弱性を見逃してしまいます。
レベル 2： 高周波スキャン。 毎日、あるいはほぼ毎日のスキャンサイクルにより、検出までの遅延が数時間に短縮されます。 動的な環境に対する検出範囲は向上していますが、コンテナや自動スケーリングされるクラウドインスタンス（1回のスキャン間隔内に起動・終了する可能性のある、Kubernetesクラスターで実行されているワークロードを含みます）のような一時的なリソースは、依然としてスキャンウィンドウの間に存在し、検出されないままになる可能性があります。
レベル 3： リアルタイムのエージェントベースの状態監視。 永続エージェントは、アセットの状態や設定情報を継続的に報告します。 検知までの遅延時間が数分に短縮されます。 一時的なアセットや、オフラインから再接続されるアセットも対象となります。 その代償として、エージェントの導入や管理にかかるオーバーヘッドが生じます。
| レベル | 検出遅延 | 資産のカバー率 | 最適なサイズ |
|---|---|---|---|
| 定期的な | 数日から数週間 | サイクル間の間隔 | 安定しており、変化の少ない環境 |
| 高周波 | 営業時間 | 一時的な資産が見落とされています | ダイナミックでありながら予測可能なインフラ |
| リアルタイム | 議事録 | オフライン／一時的なアセットに対応しています | 大規模な環境、分散型環境、または急速に変化する環境 |
ほとんどの企業向けプログラムはレベル1または 2 で運用されており、「継続的」であることを前提としています。 Taniumのシングルエージェントアーキテクチャは、リアルタイムの状態データを提供し、 による定期的な脆弱性スキャンに固有の遅延のギャップを解消します。。 問題は、どのレベルが「一番良い」かということではありません。 それは、ご自身の環境のリスクプロファイルや変化の速度にどのレベルが合致するかということです。
監視レベルによって、脆弱性を発見できる速さが決まります。 これから何が起こるかによって、彼らを見つけることが重要かどうかが決まります。
[従来のパッチ適用や脆弱性管理ツールにはどのような課題があるのか、また最新のソリューションが可視性、スピード、および是正措置の確実性の面でどのようなメリットをもたらすのかをご確認ください]
企業のCVMプログラムが機能しなくなる要因：IT部門とSecOps部門の連携不足
検知だけを行って是正措置を講じなければ、それは単にコストのかかる「認識」に過ぎません。 エンタープライズCVMにおける最大の継続性上の問題点は、技術的な問題ではありません。 これは、プログラムが求めるスピードで、チームが検出された脆弱性を是正できない原因となっている調整上の問題です。 こうした連携の不備は、現実的な影響をもたらします。調査によると、多くのデータ漏洩は、検出されていない脆弱性によるものではなく、セキュリティ部門とIT部門の間の引き継ぎ責任の所在が不明確だったために、既知の脆弱性に対するパッチが適用されずに放置されていたことが原因であることが一貫して示されています。
セキュリティチームは脆弱性を検出します。 問題の是正は、それぞれ異なる優先順位、異なるSLA、そして異なる変更管理プロセスを有するIT運用チームに依存しています。 「発見した」と「修正した」の間のギャップこそが、リスクが潜む場所なのです。
チケットシステムの連携に不具合が生じました。 脆弱性の発見に伴い手動でチケットを作成する必要がある場合、数日単位の遅延が生じることがよくあります。 統合型チケット管理は、従来の方法とは異なります。調査結果に基づき、深刻度、資産に関する情報、および是正措置の指針が添付されたチケットが自動的に生成されます。 手作業による引き継ぎは、何千件もの所見にわたり累積していく摩擦を生み出します。
[脆弱性評価の仕組み、優先順位付けが重要な理由、そして継続的な可視化が、攻撃者が既知の弱点を悪用する前に組織がリスクを軽減するのにどのように役立つかについて解説します]
SLAの位置ずれ。 セキュリティでは、CVSS またはリスクスコアに基づいて重要度を定義しています。 IT部門は、変更ウィンドウの空き状況とビジネスへの影響度に基づいて優先順位を決定します。 SLAの階層が共有されていないと、重大な脆弱性が処理待ちの状態のまま放置され、チーム間で対応の優先順位をめぐって議論が交わされることになります。
実用的なSLAの構成例としては、次のようなものがあります：
- ティア1（重大、現在悪用されている）： 24時間以内の是正措置に関するSLA
- ティア 2 （高、脆弱性の悪用が可能）： 7 日間の SLA（自動化されたパッチ適用により大規模環境でも達成可能。環境の複雑さに応じて調整してください）
- Tier 3 （中～低）： リスク許容範囲内、または予定されたメンテナンス期間
所有権の不明確さ。 修正作業の成果について、最初から最後まで責任を持つ担当者がいない場合、脆弱性はチケットの待機リストで放置されたままになります。 明確に定義された是正措置のプロセスでは、次の3つの質問に答えます。「チケットの担当者は誰ですか？」 検証の所有権は誰にあるのでしょうか？ 是正措置が先送りされた場合、その責任は誰が負うのでしょうか？
では、真に連続的なプログラムとは、実際にはどのようなものなのでしょうか？ 次のセクションでは、これを5つの検証可能な条件に分解しています。
真に連続的なプログラムが満たすべき5つの条件
以下はライフサイクルではなく、チェックリストとしてお考えください。 各条件は、満たされているか、満たされていないかのいずれかです。 部分的な正解でも、リスクは軽減されません。
1. 完全かつリアルタイムな資産台帳
このプログラムでは、一時的な資産、遠隔地の資産、およびオフラインの資産を網羅した、 の最新状態のインベントリ（ ）を管理しています。 現実から数日や数週間も遅れをとってしまうようなCMDBではありません。
テスト： 新たに公開された重大なCVEが、御社の環境内の資産に影響を及ぼしているかどうかを、1時間以内に確認できますか？ もし「まずはスキャンを実行する必要があります」という答えが返ってきた場合、連続性の不備があります。
2。 イベント駆動型検出
新たな脆弱性が公開されると、次のスキャン期間を待たずに、直ちに検出ワークフローが実行されます。 これには、 の脅威インテリジェンス フィードや、CISAのKEV更新情報、NVDの公開情報、Microsoftの「パッチ・チューズデー」やLinuxディストリビューションのアドバイザリといったベンダー固有のセキュリティアドバイザリなどとの積極的な連携が必要となります。これにより、スケジュールされたスキャンを待つのではなく、情報開示イベントが発生した時点で自動的に資産評価が開始されるようになります。
テスト： 重大なCVEが公開された場合、御社のプログラムがすべての資産に対してそのCVEに基づく評価を行うまでに、どれくらいの時間がかかりますか？ 営業時間は通しです。 「Days」は頻繁に登場します。 「週」は周期的なものです。
3。 ワークフローに統合された文脈に応じた優先順位付け
優先順位付けには、資産の重要度、EPSSやCISA KEVなどの悪用可能性を示す指標、および脅威インテリジェンス（ 、CVSSスコアはまだ高くないものの、実環境において積極的に悪用されている新たな脅威 などが含まれます）が活用されます。 エクスプロイト予測スコアリングシステム（EPSS）は、脆弱性が 30 日以内に実環境で悪用される確率を推定し、CVSSの深刻度だけでは把握できない将来を見据えた指標を提供します。 これは、 のリスクベースの脆弱性管理（）の分野であり、その方法論について解説しています。
4。 クローズドループ検証を用いた修正
すべての是正措置は、プログラムによって検証されます。 修正が確認されるまで、この脆弱性は「解決済み」とはみなされません。 脆弱性の自動修正に関する記事「 」では、実装手法について解説しています。
5。 継続的な測定と報告
このプログラムでは、独自のパフォーマンス指標を追跡し、定められた頻度でステークホルダーに報告しています。 監査人が尋ねてきたときだけではありません。 「重大な脆弱性の修正にかかる平均時間はどれくらいですか？」という質問に答えられない場合は、 カスタムレポートを作成しなくても、このプログラムはオンデマンドでレポートを作成しており、継続的に計測しているわけではありません。
いずれかの条件を満たさない場合、リスクが生じます。 検出精度は完璧でも検証が行われていないプログラムは、活動状況を報告しているだけで、成果を報告しているわけではありません。
5つの条件のうち、検証はほとんどのチームが完全に省略してしまうものです。 それでは、なぜそれが重要なのかを見てみましょう。
検証：ほとんどのプログラムで省略されてしまうCVMのステップ
多くのチームでは、脆弱性を「解決済み」とマークするのは、パッチが適用された時点であり、その脆弱性が確実に解消されたことが確認された時点ではありません。 「修正を適用した」という時点と「修正が実際に効果を発揮した」という時点との間のギャップこそが、誤った自信の源となっているのです。
修復前
修復工事前の確認
脆弱性を是正対象として指定する前に、スキャナーが検出した内容が、実際に悪用可能な脆弱性であることを確認してください。 誤検知でも、設定による影響でもありません。 この手順では、スキャナーによって脆弱性として検出される設定ミスの検出も可能です。これらは、パッチの適用ではなく設定の変更が必要な問題であり、事前の是正措置のトリアージを省略すると、誤った処理経路に振り分けられてしまう可能性があります。 この手順を省略すると、ITリソースが無駄になり、時間の経過とともにVMプログラムに対する信頼が損なわれてしまいます。
修正プログラムの展開後
修復後の検証
のセキュリティパッチ（ ）または設定変更の適用後、プログラムによって、その脆弱性が実際に解消されていることを確認してください。 再スキャンまたはエージェントベースの状態チェックにより、当該アセットにおいて脆弱な状態がもはや存在しないことが確認されます。 「チケットはクローズされました」というのは、確認にはなりません。
高額資産の場合
敵対的検証
高価値な資産や重要な是正措置の節目においては、ペネトレーションテストは、自動化された検証では再現できない、攻撃者視点による検証の層を提供します。 プログラムによる再スキャンでは、特定の脆弱な状態が解消されたことが確認されますが、対象を絞ったテストではさらに踏み込んだ検証が行われます。 自動チェックにより、その案件が完了していることが確認されました。 彼らは、被ばくがなくなったことを確認できません。
修復が不可能な場合
例外処理
レガシーシステムや、変更凍結が適用されている業務上不可欠なアプリケーションなど、修正できない脆弱性については、正式な例外処理手順を定めてください。 リスクの受容、代償的統制、レビューの頻度、および有効期限を文書化してください。 有効期限のない例外は、恒久的なリスクとなります。
是正措置の有効性を実証できないCVMプログラムは、セキュリティではなく、単に「忙しさ」を測定しているに過ぎません。
検証により、個々の修正が有効だったかどうかが判明します。 指標は、プログラム自体が機能しているかどうかを示すものです。 見分ける方法は以下の通りです。
CVMプログラムが効果を上げているかどうかを測定する方法
指標こそが、真に継続的なプログラムと、単に頻度の高いプログラムとを区別する唯一の手段です。 以下の項目を追跡し、定期的に報告するとともに、それらを活用して改善を推進してください。 これらの指標を総合的に見ることにより、経営陣は組織のセキュリティ態勢について定量的に把握することができます。これは、単に未解決のチケットの現状を示すだけでなく、プログラムが実際に のサイバーリスク を長期的に低減させているかどうかを示す傾向を示すものです。
| メートル法 | 測定対象 | 健全なベンチマーク |
|---|---|---|
| スキャン範囲の割合 | 積極的なモニタリングの対象となっている既知の資産の割合 | 100％に近づいていますが、例外が記録されています |
| CVEの公開から影響の確認までの時間 | 重大なCVEの対応時間は「時間」単位であり、「日」単位ではありません | |
| 平均修復時間（MTTR） | 深刻度別の、検出から確認済み解決までの所要時間 | 定義されたSLA階層の範囲内で |
| 偽陽性率 | 悪用できない発見の割合 | 時間の経過とともに減少しています |
| 例外率 | リスク許容と是正措置の対象となった指摘事項の割合 | 横ばいか減少傾向か、すべて記録されています |
| 修復の妥当性確認率 | プログラムによって検証された「解決済み」の指摘事項の割合 | 「重大／高」の割合が 100％に近づいています |
脆弱性の経過時間（ ）は、オプションの7番目の指標です。これは、環境全体において、脆弱性がどのくらいの期間未解決のまま残っているかを示すものです。 健全な分布は、迅速な解決を重視する傾向にあり、各深刻度レベルごとに許容可能な最大期間が明確に定められ、是正措置のスケジュールについても明確な期待が示されています。
コンプライアンス部門から求められた場合にのみ、経営陣が脆弱性データを確認するのであれば、そのプログラムは「オンデマンドでの報告」に留まっており、継続的な測定やリスクの積極的な管理が行われていないことになります。
指標は、そのプログラムが機能しているかどうかを示してくれます。 それらは、導入を困難にする運用上の現実を考慮に入れていません。 環境自体が複雑で分散している場合、プログラムがこれらの要件をどのように満たすかは異なります。
複雑かつ規制の厳しい環境におけるCVM
複雑な環境であっても、プログラムは前述の継続性の条件から免除されるわけではありません。 これらは、プログラムが対応している運用上の制約となります。
- 分散型およびオフラインのエンドポイント： リモートエージェントは、接続が断続的な状態で動作する場合があります。 継続的なプログラムでは、再接続時の状態の同期、キューに格納された是正措置、および定義された閾値を超えてオフライン状態にある資産のカバレッジギャップの追跡を通じて、この処理を行っています。
- OT/IT統合型エンドポイント： によるスキャンは、運用技術（OT）システムに支障をきたす可能性があります。 継続的なプログラムは、OT環境が許容する範囲で、パッシブモニタリング、エージェントレス、または読み取り専用エージェントモードに対応し、OT資産向けの個別の検知および是正ワークフロー、ならびに補償措置を伴う明確な除外ポリシーを備えています。
- 規制対象業界（NIST、PCI DSS、HIPAA）： CVMは、継続的な証拠の収集、調査結果と管理要件との自動マッピング、および規制上の文脈を踏まえた文書化された例外管理を通じて、コンプライアンスフレームワークにマッピングされた監査対応可能な証拠を生成します。
連続性の基準は変わりません。 実装はそれに応じて適応します。
環境の複雑性への対応が済んだところで、最後の疑問は、CVMがセキュリティおよびITスタック内の他の要素とどのように連携するかということです。
CVMを既存のセキュリティおよびITワークフローに連携させる
継続的なプログラムは、既存のセキュリティおよびITツールを置き換えるのではなく、それらと連携して機能します。 その価値は、統合の質によって決まります。
- SIEM/SOAR： 脆弱性の検出結果は、重大な検出事項に対する自動アラート、SIEMイベントにおけるコンテキスト情報の充実、およびパッチ適用や設定変更のアクションをトリガーするSOARプレイブックを通じて、セキュリティ運用ワークフローに組み込まれます。
- ITSM／チケット管理： 是正措置は、IT部門の変更管理プロセスに組み込まれます。 「調整のギャップ」のセクションに記載されているSLAおよびチケット発行に関する要件が、ここにも適用されます。
- CI/CDおよびDevOpsパイプライン： リリースサイクルが短い組織では、脆弱性チェックはデプロイ後に実行するのではなく、デプロイパイプラインに組み込まれています。 DevSecOpsモデルでは、シフトレフトにより、開発段階でセキュリティ上の問題点が明らかになります。
- パッチ管理： 継続的なプログラムでは、発見された問題を解決済みのリスクへと転換するために、適切に機能するパッチ管理ワークフローが不可欠です。 OSのパッチ適用は、最も広範な資産を網羅しています。一方、アプリケーションのパッチ適用は、悪用される脆弱性の相当な割合を占めるものの、OSに重点を置いたワークフローからはしばしば除外されがちな、サードパーティ製ソフトウェア、ブラウザ、およびオフィススイートを対象としています。 両レイヤーにわたって体系的な パッチ適用プロセス が確立されていないと、検知データが蓄積されるだけで、是正措置にはつながりません。
- エンドポイント管理： CVMプラットフォームは、エンドポイント管理とデータを共有するか、または同じエージェントインフラストラクチャ上で動作するため、個別のスキャンエージェントが不要となり、脆弱性を検出したのと同じコンソールから是正措置を講じることができます。
Taniumが継続的な脆弱性管理をどのように支援するか
以上の内容は、連続プログラムに必要な要件について述べたものです。 脆弱性を検知してから、その修正が確認されるまでの間に、ほとんどのプログラムは継続性を失ってしまいます。そして、そのプログラムが実際に成果を上げられるかどうかは、プラットフォームのアーキテクチャによって決まるのです。
検出ツールが問題を見つけ出します。 是正措置には、別のチーム、別のツール、そして別の優先順位リストが必要となります。 何千もの調査結果に繰り返し見られるその引き継ぎこそが、「継続的」なプログラムを周期的なものに変えてしまうのです。
の「Tanium Autonomous IT Platform」（ ）は、検知、優先順位付け、是正措置、検証を単一のデータセット上で一元的に管理することで、そのギャップを解消します。 セキュリティチームとITチームは、同じリアルタイムのエンドポイントデータに基づいて作業を行うため、「発見」から「修正」までのタイムラグが解消されます。 重大なCVEが公表された際、Taniumは、チームが環境全体にわたってほぼ瞬時に の「修復状況の可視化」 を確認できるよう設計されており、問題の特定からパッチ適用へと直接移行できるよう支援します。
運用面では、これはCVMのライフサイクル全体にわたって展開されます：
- リアルタイムの資産状況把握により、古いスキャンデータに取って代わります： Taniumは、管理対象、非管理対象、およびオフラインから再接続中のデバイスを含め、エンドポイントから現在の状態を直接取得します。 つまり、資産インベントリには、前回のスキャン期間に存在していたものではなく、現時点で実際に存在するものが反映されているということです。
- 検出が行われた場所で即座に是正措置が実施されます： 検出結果は、同じプラットフォーム内のパッチ適用および設定ワークフローに直接反映されます。 手動でのチケット作成が不要で、引き継ぎの遅れもなく、セキュリティ部門とIT部門の間で責任の所在が曖昧になることもありません。
- クローズドループ検証は、単なる展開だけでなく、修正の有効性も確認します： Taniumは、再スキャンをスケジュールすることなく、プログラムによって修正の有効性を検証します。 エージェントベースの状態データにより、脆弱な状態が継続しているかどうかが確認されるため、エンドポイントで修正が確認された場合にのみ、その脆弱性は「解決済み」としてマークされます。 チケットの販売終了時には、そうではありません。
大規模な環境全体へのエージェントの初期導入には、特に変更管理が厳格な環境においては計画が必要ですが、複数のスキャンツールや修復ツールを維持管理する必要がなくなることで、継続的な運用上の負担は相殺されます。
それらは単なる理論上の区別ではありません。 Recovery Centers of America（ ）は、Taniumを活用して、2,200 台のエンドポイント全体で、これまで検出されていなかった400,000 件の脆弱性を発見しました。 その後、Taniumは、わずか2週間余りで、同組織がその件数を 80 パーセント削減できるよう支援しました。 RCAはまた、TaniumとServiceNowの連携を活用し、個別のツールを統合するとともに、リアルタイムのエンドポイントデータをチケット管理、変更管理、および資産管理のワークフローに取り込みました。 「」の事例研究をご覧ください。
Taniumの統合プラットフォームアーキテクチャは、ほとんどのCVMプログラムが真の継続性を実現できない原因となっている構造的な問題、すなわち 、検知と検証済みの是正措置との間のギャップに対処します。
Taniumは、エンドポイントの状態データをリアルタイムで管理し、セキュリティチームやITチームが単一のシステムから検知、優先順位付け、是正、検証を行えるようにすることで、「継続的」なプログラムを「頻繁な」プログラムにしてしまうような、調整の遅れやツール切り替えに伴う手間を解消します。 組織は、新たに公開されたCVEが自社の環境に影響を与えるかどうかを数時間以内に判断し、是正措置が完了したことをプログラムによって確認するという運用能力を獲得します。これら2つの条件こそが、継続的なプログラムと単なる目標に留まるプログラムとを区別するものです。
継続的な脆弱性管理に関するよくある質問
真の継続性を実現するには、検知から検証済みの是正措置までのギャップを埋めることが不可欠です。 以下の質問は、チームがCVMプログラムを評価または構築する際に直面する、最も一般的な課題について取り上げたものです。
継続的な脆弱性管理とは何でしょうか？
継続的な脆弱性管理とは、組織のITインフラ全体にわたるセキュリティ上の弱点を発見、分析、優先順位付け、および是正するための、継続的かつ自動化されたプロセスであり、定期的なスキャンサイクルに依存することなく、 資産の状態 および脆弱性の状況をリアルタイムで可視化し続けるものです。
継続的な脆弱性管理は、既存のセキュリティツールとどのように連携するのでしょうか？
継続的な脆弱性管理では、SIEM/SOARプラットフォームを通じて既存のセキュリティおよびITツールと連携し、アラート通知と対応ワークフローの自動化を実現します。また、ITSM/チケット管理システムによる是正措置の追跡、パッチ管理プラットフォームによる自動展開と検証、さらにエンドポイント管理インフラを活用することで、重複するエージェントを排除し、単一のデータセット上で検知と是正措置を統合します。
継続的な脆弱性管理は、サイバーセキュリティ戦略においてどのような位置づけになるのでしょうか？
継続的な脆弱性管理は、攻撃対象領域に対するリアルタイムの可視性を維持し、悪用可能性やビジネス上の状況を踏まえて是正措置の優先順位を決定し、 でのエクスポージャーの傾向を継続的に測定することで、セキュリティ戦略を測定可能なリスク低減へと結びつける運用層としての役割を果たします。 これにより、より広範なリスク管理上の意思決定に役立つ情報を提供します。
継続的な脆弱性管理は、セキュリティ態勢をどのように向上させるのでしょうか？
継続的な脆弱性管理は、脆弱性の開示から検証済みの是正措置までの期間を短縮し、定期的なスキャンによって生じるカバー範囲のギャップを解消するとともに、平均検出時間（Mean Time to Detection）、平均修正時間（ ）、平均是正時間（）、および脆弱性の経過傾向といった指標を通じて、リスク低減の測定可能な証拠を経営陣に提供することで、セキュリティ態勢を向上させます。
継続的な脆弱性管理の成果は、どのように測定すればよいでしょうか？
そのプログラムが、時間の経過とともに被ばく量を明らかに低減させているかどうかによって、その成功が評価されます。 本記事の前半で取り上げた6つの主要指標（スキャンカバレッジ率、検出までの平均時間、是正までの平均時間、誤検知率、例外率、および是正の検証率）が、測定可能な証拠となります。 プログラムが機能しているとは、リーダーシップ層が、単に未解決のチケットの現状だけでなく、対応期間の短縮を示す傾向線を確認できる状態を指します。
継続的な脆弱性管理は、製品カテゴリーではありません。 これは運用上の基準です。 問題は、 ツールがスキャンを実行するかどうかではありません。。 重要なのは、御社のプログラムが、今この瞬間に、どの資産が危険にさらされているか、そして昨日の修正が実際に効果があったかどうかを判断できるかどうか、ということですね。 これが、「頻繁」と「継続的」の違いです。
Taniumの統合プラットフォームは、セキュリティチームやITチームに対し、その基準を満たすために必要なリアルタイムの可視性とクローズドループ検証を提供し、多くのプログラムが真の継続性を実現できない原因となっている連携のギャップを解消します。 お客様の環境にどのように活用できるかをご確認いただくため、個別デモをご予約ください。。
