ほとんどの脆弱性管理プログラムは、「脆弱性が見つかった」や「パッチを適用した」という段階で終わってしまいます。 CTEMでは、ほとんどのプログラムが省略してしまう手順、すなわち、エクスポージャーが実際に閉じられていること、および制御機能が意図したとおりに動作していることを検証する手順を追加しています。
この記事では、エンタープライズ規模において各段階で何が必要か、プログラムが通常どこで停滞しがちか、そしてCTEMの取り組みがリスクを低減しているのか、それとも単に活動量を増やしているだけなのかをどのように測定すべきかについて詳しく解説しています。
CTEMについて
継続的な脅威への曝露管理は、5つの段階からなるフレームワークです。 ガートナーは、組織がセキュリティ上のリスクを体系的に低減できるよう支援するため、「 」を導入しました。 5つの段階は、スコープ設定、ディスカバリー、優先順位付け、検証、そして展開です。
による定期的な脆弱性評価 は、主に発見事項のリストを作成するものですが、CTEM では、脆弱性が実際に悪用可能かどうか、また現実的に対処可能かどうか、さらに における脆弱性の是正措置 や対策によって、その実情が測定可能な形で変化するかどうかを重視しています。 CTEMでは、実際の攻撃の実現可能性、是正措置、資産の重要度、および攻撃経路の到達可能性を優先順位付けに組み込んでおり、これはCVSSスコアだけでは得られない文脈情報です。
CTEMは、定期的な評価やチケット発行という方式から、重要な事項を特定し、脆弱性が悪用されたり横方向の移動を可能にしたりするかどうかを検証し、対策の有効性を確認し、責任の所在を明確にした上で是正措置を講じるという継続的なサイクルへと移行することで、運用モデルをプロアクティブなアプローチへと転換します。
従来の脆弱性管理では、CVEを特定し、CVSSの深刻度に基づいてランク付けを行います。 それによって調査結果は得られますが、セキュリティ責任者が実際に気にかけている疑問、すなわち「攻撃者が重要な資産に到達するために、現実的にどの脆弱性を悪用できるのか」という問いには答えられません。
CTEMでは、「エクスポージャー」の定義を脆弱性にとどまらず、緩和措置を必要とするあらゆるギャップまで拡大しています。 包括的な脆弱性評価では、パッチが適用されていないCVEだけでなく、設定ミス、ID関連のリスク、過剰な権限、外部に公開されている資産、シャドーIT、あるいは攻撃者が悪用しうるあらゆる状況も考慮されます。 目的は、さらに多くの問題を見つけることではありません。 お客様の特定の環境において最も重要な脆弱性に、是正措置の重点を置いています。
[エクスポージャー管理が、より広範なセキュリティ戦略の中でどのような位置づけにあるのかを探ってみましょう]
CTEMは、脆弱性管理の代わりとなるものではありません。 これは、ビジネス上の文脈に基づいた既存のスキャン、優先順位付け、および是正措置のワークフローを包括的にサポートし、それらの効果を高めるための体系的なプログラムです。 その結果、未対処の脆弱性が減少し、是正措置が迅速化され、リスクが最も高い分野にセキュリティ投資が集中するようになりました。
CTEMがどのような付加価値をもたらすかを理解するには、まず従来のアプローチの限界を認識することから始まります。
従来の脆弱性管理が不十分である理由
そのギャップは、プロセスの網羅性にあるわけではありません。 これは確認です。 多くの成熟した 脆弱性管理 プログラムでは、通常、スキャン、優先順位付け、および是正措置のワークフローが整備されていますが、一部のプログラムでは、修正プログラムを適用した時点で是正措置が完了したとみなしており、実際に脆弱性が解消されたかどうかを確認しないままにしておくケースが依然として見受けられます。
[自動化された脆弱性修正の仕組み、ガバナンスの境界が重要な理由、そして段階的な導入が、新たな運用リスクを生み出すことなく、組織が脆弱性のリスクを解消するのにどのように役立つかについてご紹介します]
これにより、行動と結果の間に重大な盲点が生まれます。 継続的な検証が行われない場合、チームは、デプロイの失敗、設定のずれ、または不完全な修正によって根本的な脆弱性が依然として残っているにもかかわらず、リスクが軽減されたと誤解してしまう可能性があります。
定期的な評価モデルは、この格差をさらに広げてしまいます。 多くの環境において、スケジュールされたスキャンでは、特に変化の激しいクラウド、SaaS、およびID管理環境において、新たなリスクや変更されたリスクが、次回の収集サイクルまで残ってしまう余地が生じることがあります。 攻撃者は、あなたのスキャンスケジュールを待ってはくれません。
ツールがサイロ化されると、文脈が断片化されてしまいます。 スキャナー、侵入テスト報告書、資産台帳、およびチケット管理システムは、多くの場合、データを共有していません。 セキュリティチームは、実際にどのようなリスクが存在するのかを包括的に把握するために、連携していない各ツールから得られた調査結果を手作業で照合することになってしまいます。
深刻度のみによる優先順位付けでは、実用不可能なバックログが生じてしまいます。 CVSSスコアは、その脆弱性が理論上どれほど深刻になり得るかを示すものです。 その脆弱性が、ドメインコントローラーにアクセス可能な資産に存在するかどうか、あるいはその脆弱性を悪用するコードが実際に流通しているかどうかについては、明記されていません。
コントロールが実際に機能しているかどうかを確認する検証が行われていません。 ほとんどのプログラムでは、パッチが適用されたかどうかを追跡しています。 そのエクスポージャーが実際にクローズされたかどうかを確認する人は少ないです。 設定ミスのあるシステムにおいて、修正済みのCVEであっても、別の経路を通じて依然としてアクセス可能である可能性があります。
CTEMの用語では、「検証」には、その脆弱性が実際にその環境で悪用可能かどうかを確認すること、関連する攻撃手法に対する対策の適用範囲を確認すること、および是正措置実施後の特定の資産や状態を再確認することが含まれます。
組織的なギャップ。 セキュリティチームは調査結果をまとめます。 IT運用チームが是正措置を担当します。 ワークフローやガバナンスが共有されていない場合、検証済みのエクスポージャーは、セキュリティ部門が把握できない変更ウィンドウを待つまま、キューに滞留してしまいます。
CISOにとって、この組織的なギャップは、往々にして解決が最も困難な問題となります。 これは、技術的な課題であると同時に、ガバナンス、リスク管理、および説明責任に関する課題でもあります。
CTEMは、 のリスクへの曝露 の低減を、継続的かつ統合的なプログラムとして位置づけることで、これらの課題のそれぞれに対処しています。 次のセクションでは、各段階の仕組みについて詳しく解説します。
CTEMの5つの段階
CTEMプロセスの5つの段階は、連続したサイクルを形成しています。 各段階は次の段階へとつながり、環境の変化や新たな脅威の出現に伴い、スコープ設定、発見、検証の優先順位を見直す必要が生じるにつれて、このサイクルが繰り返されます。
初期の範囲設定から検証済みの是正措置に至るまで、CTEMサイクルの全ライフサイクルを理解することは、単なる繰り返しの活動にとどまらず、測定可能なリスク低減をもたらすプログラムを設計するために不可欠です。
1. 範囲の定義
スコープ設定では、環境のどの部分を評価対象とするか、および曝露をどのように測定するかを定めます。 これは単なる技術的な演習というだけではありません。 これには、技術的なリスクだけでなく、ビジネス目標にも基づいて、各サイクルにおいてどの資産階層を対象とするかについて、セキュリティ部門とビジネス部門のステークホルダー間で合意を形成する必要があります。
事業の優先順位が変化するにつれて、スコープに関する決定は定期的に見直すべきです。 合併、新製品の発売、あるいはリモートワークへの移行といった変化は、いずれもどの資産が最も重要であるか、ひいてはどのリスクに最も早急な対応が必要かを左右する可能性があります。
分散環境においてすべてを継続的にスキャンすることには、ネットワークへの影響やアラートの量など、さまざまなトレードオフが伴います。 スコープの決定には、どの資産階層を継続的に対象とするか、どの資産階層を定期的に評価するか、そして環境の変化に応じてスコープを調整する権限を誰が持つかについて、協議を経て合意を形成する必要があります。
運用上の観点から、「継続的」とはどういう意味でしょうか？
CTEMプログラム内のすべての信号が、同じ周波数で更新されるわけではありません。 エンドポイントの状態やテレメトリなど、一部のデータソースはほぼリアルタイムで取得できますが、 の脆弱性スキャン（）など、他のデータソースは依然として定期的な取得となります。 組織は、各資産階層について、許容可能なデータの鮮度に関する閾値を定義しなければなりません。 データソースが常に古くなっている場合は、再検証が行われるまで、その出力結果は信頼度が低いものとして扱うべきです。
CTEMプログラムは、チームがすべての入力情報が同等に最新であると仮定してしまうと、しばしば機能しなくなります。 実際には、正確性を維持するためには、在庫データを継続的に更新し、資産の所有権や状況を確認し続ける必要があります。
脅威インテリジェンスの情報は、どの資産タイプが積極的に標的とされているかを明らかにすることで、対象範囲の決定に役立てられます。 脅威の状況が変化するにつれて（例えば、脅威アクターがVPNアプライアンスを積極的に標的にし始めた場合など）、それらの資産タイプは、そのサイクルの対象範囲における優先順位が上昇します。
[サイバー脅威インテリジェンスがセキュリティ上の意思決定にどのように役立つかをご覧ください]
初期段階でよく見られる失敗の一つは、スコープの定義を「すべてを列挙する」ことだと捉えてしまうことです。 CTEMにおいて、スコープ設定では、 何が重要であり、成功をどのように測定するかを定義し、 ディスカバリーでは、そのスコープ内に何が存在するかを洗い出します。
2。 発見
CTEMにおけるアセット検出は、従来のアセットインベントリの枠を超え、脆弱性、設定ミス、外部に公開されているアセット、シャドーIT、およびID情報の漏洩などを網羅して、攻撃対象領域を可視化します。
大規模で複雑な環境において、50,000台以上のエンドポイントにわたる状況把握を行うには、通常、エンドポイントのテレメトリ（管理対象の場合）、ネットワークおよびスキャナーのデータ、クラウドやSaaSのコントロールプレーンからのデータ（API）など、複数の収集手法を組み合わせる必要があります。 エージェントベースのアプローチとエージェントレスなアプローチには、それぞれ一長一短があり、オンプレミス、クラウド、ハイブリッドといった異なる環境では、それぞれ特有の課題が生じます。 また、各手法は、特に短命な資産について、対象範囲、最新性、信頼性の点で異なります。
シャドーITや管理対象外のデバイスは、標準的なスキャン範囲から完全に外れているため、可視性のギャップが最も大きくなりやすく、その結果、検出されないリスクが潜んでいる可能性が最も高いのです。
SaaSアプリケーションも同様の課題を抱えています。 各事業部門では、IT部門やセキュリティ部門を巻き込まずにクラウドベースのツールを導入することが頻繁にあり、その結果、従来の資産台帳には決して反映されないリスクが生じています。
資産の識別情報と所有権は、最優先で特定すべき情報に含まれます。 飼い主との関連性が確認できない被曝の所見については、通常、対応が停滞してしまいます。 技術的な識別子（ホスト名、インスタンスID、アカウント、アプリテナント）と、それらを管理するビジネスチームとの間の、信頼性の高い対応関係を維持してください。
こうした理由から、外部攻撃対象領域管理（EASM）は、発見段階において重要な要素となっています。 EASMツールは、社内インベントリには記載されていない可能性のある資産を含め、インターネットに公開されている資産について、継続的な可視性を提供します。
ID情報の漏洩を防ぐには、エンドポイントのスキャンだけでなく、IDプロバイダーのデータとの連携が必要です。 ドメイン管理者権限を持つサービスアカウントで、 18 か月間使用されていないものは、たとえ脆弱性スキャンに検出されなくても、セキュリティ上のリスクとなる可能性があります。
3。 優先順位付け
優先順位付けでは、CVSSの深刻度のみではなく、悪用可能性、潜在的な影響、および攻撃者との関連性に基づいてリスクをランク付けします。
文脈が不明確な大量の発見結果は、実用化が難しい場合が多くあります。優先順位付けを行うには、資産の重要度、悪用兆候、制御の文脈、および到達可能な経路との関連性を考慮し、取り組みの焦点を絞る必要があります。 実環境において効果的な優先順位付けを行うには、以下のことが必要です：
- 資産の重要度レベル： スキャナーではなく、組織によって定義されます
- エクスプロイトの発生状況に関する情報： EPSS（エクスプロイト予測スコアリングシステム）やCISAの「既知の悪用済み脆弱性」カタログなどと同様に
- 攻撃経路の分析： これにより、 による横方向の移動 が、最重要資産に到達することを可能にする脆弱性が特定されます。
実用的な優先順位付けの手順として、インターネットからアクセス可能なエクスポージャーと、横方向の移動を可能にする内部からアクセス可能なエクスポージャーとを区別することが挙げられます。
インターネットに関連するリスクは、即座に注目を集める傾向があります。 しかし、ID関連のリスク、過度な権限、設定ミスのある信頼関係など、内部からアクセス可能な脆弱性は、重要な資産に対する影響の大きい攻撃経路となり得ます。
効果的な優先順位付けでは、その両方を考慮に入れます。 この手法では、単に抽象的な深刻度だけでなく、到達可能性や、攻撃者の侵入を可能にする上でのその役割に基づいて、脆弱性の重み付けを行います。
アタックパス分析とは、攻撃者が複数の脆弱性を連鎖させて、重要度の高い標的に到達する経路を明らかにするプロセスです。 この文脈は意思決定において不可欠です。これにより、優先順位の決定が、単なる機械的な採点作業から、どのリスクが重要な事業資産に対して最も現実的な脅威をもたらすかについて、リスク情報を踏まえた判断へと移行するのです。 ドメインコントローラー（ ）に隣接する資産におけるCVSSスコア6 のCVEは、隔離された開発用マシン上のCVSSスコア9 のCVEよりも優先度を高く設定すべき場合があります。
4。 検証
検証では、セキュリティ対策が優先順位付けされた脆弱性に関連する手法を検知または遮断できるかどうかをテストし、それらの脆弱性が当該環境において実際の攻撃リスクとなるかどうかを確認します。 また、パープルチーム、ターゲット型テスト、侵害・攻撃シミュレーション（BAS）などの手法を用いて、統制措置がこれらのリスクを効果的に軽減しているかどうかも確認します。
エンタープライズ規模では、2つの検証モードがそれぞれ異なる目的を果たします：
- 敵対的検証： レッドチーム活動およびBASテストでは、現実的な攻撃者の行動をシミュレートすることで、重要資産に対する特定の攻撃シナリオを検証します。 これは定期的に実行され、リソースを多く消費しますが、信頼性の高い結果をもたらします。
- 継続的な是正措置の検証（資産／状態の再確認）： 特定の資産において、特定の脆弱性が解消されたことを確認します。 修正処理の後（テレメトリとワークフローが対応している場合）、自動的に実行され、継続的な保証を提供します。
実際には、組織は通常、これらを組み合わせるのではなく、どちらか一方の方法を重視する傾向があります。 敵対的検証は通常、定期的に（重要度の高いシナリオでは年次または四半期ごとに）実施され、多大なリソースを要しますが、信頼性の高い結果をもたらします。一方、継続的な是正措置の検証は、実施の徹底度が低い傾向にあります。
よく知られている例として、侵入テストが挙げられます。これは、ある時点において攻撃者が脆弱性をどのように悪用しうるかについて貴重な知見を提供しますが、環境の変化に伴い、その脆弱性が解消されたままであるかどうかを確認するものではありません。 Q1 で実施されたペネトレーションテストは、Q3における統制の状態を検証するものではありません。
そのため、バリデーションでは以下の2つの条件を満たしていることを確認する必要があります：
- その脆弱性が現在の環境下で実際に悪用される可能性があるのか、あるいは適切な対策によってその攻撃手法が阻止されるのか
- 設定のずれ、再デプロイ、あるいはリスクを再導入する可能性のあるポリシーの変更などを考慮した上で、そのエクスポージャーが長期的に閉じた状態を維持できるかどうか
この2つの確認を行わないと、是正措置が完了したように見えても、実際にはリスク要因が知らぬ間に再び生じている可能性があります。
5。 動員
モビライゼーションは、セキュリティチームとITチームを横断して、是正措置の取り組みを調整します。 調査結果は、明確な責任の所在とスケジュールを定めて、具体的な行動へと結びつけられます。
是正措置の優先順位は、事業目標を反映すべきです。 収益に直結するシステムで確認された脆弱性については、重要度の低い社内ツールにおける同様の脆弱性とは異なる対応スケジュールが必要となります。
この段階で、多くの企業のCTEMプログラムが停滞してしまいます。 次のセクションでは、この点について詳しく取り上げます。
動員格差
セキュリティ部門が問題の発見を担当し、IT運用部門が是正措置を担当しているにもかかわらず、引き継ぎの責任がどちらの部門にもない場合、モビライゼーションは失敗に終わります。
その流れはよく知られたものです。セキュリティ部門が検証済みの脆弱性を特定し、チケットを作成して待機する一方で、IT運用部門はそれをバックログに追加し、将来の 変更ウィンドウに合わせてスケジュールを組むのです。 それまでの間、エクスポージャーは未決済のままとなります。
効果的なモビライゼーションには、明確な例外処理も必要です。 検証済みの曝露のすべてが、標準的な変更期間を待てるわけではありません。
組織は、高リスクの不具合が通常の展開サイクルを迂回する場合の基準を定義するとともに、明確な承認およびロールバックのプロセスを定める必要があります。 こうした例外的な対応策がなければ、検証済みの被ばく事案は日常業務と競合することになり、優先順位が付けられているにもかかわらず、未解決のまま放置されることがよくあります。
自動化された是正措置に関するガバナンス要件。 すべての発見結果が、 の自動修復機能（）を起動するわけではありません。 組織では、どの種類の不具合が自動的に修正可能で、どの種類が変更管理の審査を必要とするかについて、明確な方針を定める必要があります。
段階的なリングベースの展開順序により、影響範囲を最小限に抑えることができます。 段階的なリングベースの展開とは、変更が展開リング（テスト、高優先度、そして広範囲展開）を経て段階的に進められることを意味します。 各リングは、次のリングが始まる前に安定性を確認します。
ITSMとの統合の成否が、モビリティ化の成否を左右します。 CTEMの調査結果は、IT運用部門が別途のトリアージ手順を経ることなく対応できるよう、十分な背景情報を付加した上で、既存のチケット管理システム（ServiceNow Vulnerability Responseなどが代表的な例です）に連携される必要があります。
チケットには、具体的なリスクの暴露状況と影響を受けた資産、業務上の背景および資産の重要度、推奨される是正措置、ならびに検証済みのリスクに基づくSLAを記載する必要があります。
| メートル法 | 測定対象 |
|---|---|
検証済みの重大な不備に対する平均修復時間（MTTR） | 検証から是正措置の完了までの所要時間 |
| 所有権譲渡率 | SLA内で担当者が割り当てられた検証済み所見の割合 |
| 再認定の合格率 | 是正措置を完了し、再検証に合格した指摘事項と、再検証を行わずに終了した指摘事項との比較 |
動員とは、検証済みの調査結果に基づいて、是正措置を協調的に実施することです。 これは、現在進行中の脅威によって引き起こされるインシデント対応ではありません。 この区別は、ガバナンスやワークフローの設計において重要です。
とはいえ、検証済みのCTEMの調査結果は、対応計画の策定に反映されるべきです。 自組織が抱える最もリスクの高い脆弱性を把握している組織は、是正措置が完了する前にそれらの脆弱性が悪用された場合でも、インシデントの拡大を食い止め、復旧に向けた対応をより円滑に進めることができます。
動員における格差を解消するには、プロセスの変更だけでは不十分です。 また、検証の仕組みについても見直す必要があります。
実際の被ばく量の検証
検証のギャップこそが、多くのプログラムが誤った自信を生み出す原因となっています。 パッチの適用状況を追跡することは、エクスポージャーの解消を確認することとは異なります。 パッチが適用されたシステムであっても、基盤となる設定やアクセス経路に変更がない限り、別の攻撃経路を通じて依然としてアクセス可能となる可能性があります。
ある攻撃手法を阻止することを目的としたファイアウォールのルールであっても、実際にはそれを阻止できない場合があります。 だからこそ、検証は、セキュリティ対策が導入されていることを確認するだけにとどまってはならないのです。 それらは、攻撃者が特定の脆弱性を悪用するために用いるであろう具体的な手法に対して有効であることを確認しなければなりません。 検証により、単なる理論上の深刻度だけでなく、実世界におけるリスクも確認されます。
2つの検証モードには、それぞれ異なる目的があります：
- 敵対的検証： レッドチーム活動およびBASは、重要な資産に対して特定の攻撃経路が成功するかどうかを検証します。 リソースを多く消費する作業であり、通常は四半期ごとまたは年1回実施されます。
- 継続的な是正措置の検証（資産／状態の再確認）： 特定の資産において、特定の脆弱性が解決されたことを確認します。 修復処理の後、自動的に実行され、継続的な保証を提供します。
攻撃経路の分析によって、この2つが結びつきます。 これは、どのエクスポージャーを連鎖させることで、 の最重要資産であるにアクセスできるようになるかを示しています。 この状況により、優先順位が変わります。 ドメインコントローラーへの経路となる資産に存在する中程度の深刻度の脆弱性は、孤立したシステム上の重大な脆弱性よりも優先度が高いです。
管理の有効性の測定。 そのセキュリティ対策（ファイアウォールのルール、EDRポリシー、パッチ）は、その脆弱性に関連する攻撃手法を実際に阻止できるのでしょうか？ それとも、別の技を封じつつ、肝心の技は通してしまうのでしょうか？
検証体制が整ったところで、次の課題は、CTEMを皆様がすでに運用されているツールやワークフローにどのように組み込むかということです。
CTEMを既存のワークフローに統合する
CTEMを並行して実施することは、IT運用において優先順位の衝突を引き起こす最も早い方法です。 セキュリティ部門は直ちに対策を講じるよう求めていますが、IT部門は2週間ごとの変更サイクルで運用を行っています。 目標は、既存のワークフローに統合することであり、それに並行して新たな流れを作ることではありません。
適切に運用されれば、CTEMは手作業による引き継ぎを削減し、重複するトリアージ手順を省き、検証済みの所見を迅速に是正措置へとつなげることで、業務の効率化に寄与します。
- ITSMとの連携： のCTEM調査結果は、お客様の既存のチケット管理システムに連携されます。 チケットの構成は重要です。IT運用部門が二次的な引き継ぎなしにすぐに対応できるよう、十分な背景情報（資産の重要度、検証済みのリスク、推奨される対応策、SLA）が記載されている必要があります。
- スコープ設定および発見の参考情報としてのSIEM： SIEMデータは、 アクティブな脅威活動 および異常な挙動を明らかにし、現在のCTEMサイクルの対象となる資産を特定する手がかりとなります。 これはプログラムへの入力であり、プログラムの代わりになるものではありません。
- 並行プロセスの問題を回避する： CTEMを独立したセキュリティプログラムとして運用している組織では、IT運用において優先順位の矛盾が生じてしまいます。 セキュリティ部門は、直ちに対策を講じることを求めています。 IT部門は2週間ごとの変更サイクルで運用されています。 重大な検証結果に対する例外処理がない限り、この矛盾は構造的なものです。
- IT変更管理との互換性： ガバナンスモデルが適切に設計されていれば、段階的かつリング方式による展開および変更ウィンドウは、CTEMの導入と互換性があります。 重要なのは、次回の予定された対応期間まで待てない、検証済みの重大な不具合に対して、例外的な対応策を講じることです。
CTEMは、セキュリティスタック全体にわたる連携層として機能する場合に最も効果を発揮します。つまり、SIEM、脆弱性スキャナー、IDプロバイダー、資産管理システムから情報を収集し、優先順位付けされ、検証済みの調査結果をITSMに提供することで、協調的な是正措置を可能にするのです。
こうした統合型ワークフローへの移行は、より広範な市場動向を反映しています。 企業では、断片化された単機能ツールから離れ、発見、優先順位付け、検証、是正措置を統合したプラットフォームへの移行が進んでいます。 その目的は、検証済みのリスクを協調的な行動へと結びつけ、先を見越したセキュリティ文化を醸成することにあります。
CTEMを既存のワークフローに組み込んだら、次のステップは、現在のプログラムの状況を評価することです。
CTEMプログラムの成熟度
現在、そのプログラムはどのような状況にありますか？ 3つの成熟度レベルが、自己評価の枠組みを提供しています。
レベル1：その場しのぎ／事後対応型
脆弱性スキャンは定期的に実行されます。 発見事項は、CVSSのみに基づいて優先順位が付けられます。 汚染対策の責任の所在が不明確です。 修正が機能していることを裏付ける正式な検証はありません。 このレベルでは、セキュリティリスクへの対応は、体系的な継続的なプログラムを通じて行われるのではなく、通常、インシデントや監査結果が判明した後に事後的に行われます。 セキュリティ部門とIT部門は、別々のシステムで運用されており、手作業による引き継ぎが行われています。
レベル 2：周期的／構造化
定義されたスキャンスケジュールは、資産の重要度レベルと紐付けられています。 リスクに基づく優先順位付け では、資産の背景情報が考慮されます。 セキュリティ部門とIT部門の間には、正式なチケット処理ワークフローが設けられています。 ペネトレーションテストまたはBASは、少なくとも年に1回実施されます。 重大な不具合については、MTTRを追跡しています。
レベル 3：連続／自動
レベル 3では、本プログラムは継続的かつ自己強化型のシステムとして稼働します。具体的には、エンドポイント全体にわたるリアルタイムの可視化、EPSSおよびCISA KEVデータを活用した自動優先順位付け、自動チケット作成とSLA追跡機能を備えたITSMとの統合、 による継続的な是正措置の検証、リングベースの展開ガバナンス、およびプログラムレベルで報告される動員指標などが含まれます。 その結果、リスクの低減が「想定」ではなく「測定可能」なセキュリティ運用が実現されます。
組織をレベル1からレベル 2へと引き上げる要因 は、通常、ガバナンス上の決定であり、ツールの選択によるものではありません。 資産の重要度レベルを定義し、所有権モデルを確立し、正式な引き継ぎワークフローを作成するのに、新しい技術は必要ありません。
組織をレベル 2 からレベル3へと引き上げる要因 は、通常、ツールや統合に関する決定によるものです。 リアルタイムの可視化、自動化された優先順位付け、および継続的な検証には、 の定期的なスキャンツール（ ）では提供されないプラットフォーム機能が必要となります。
成熟度レベルにかかわらず、目標は同じです。つまり、測定可能なリスク低減につながらない活動を行うのではなく、ビジネスにとって現実的に最大のリスクをもたらす脆弱性にセキュリティ対策を集中させることです。
成熟度レベルは、自己評価のための枠組みとなります。 指標は、進捗状況を把握するための手段となります。
CTEMの成果を測定する方法
重要な指標は、活動指標ではなく、成果指標です。 チケットの件数とスキャン頻度から、そのプログラムの稼働状況がわかります。 検証済みの重大な所見に対するMTTRは、その対策が機能しているかどうかを示してくれます。
| メートル法 | 測定対象 | 成熟度レベル |
|---|---|---|
| 検証済みの重大な所見に関するMTTR | 検証から是正措置の完了までの所要時間 | レベル2以上 |
| 露光時間の長さ | 優先度の高いリスクが未対処のまま放置される期間 | レベル2以上 |
| 検証カバレッジ | 現在のサイクルにおいて検証された重要資産および攻撃経路の割合 | レベル 3 |
| 偽陽性率の低減 | 検証の結果、実際に活用できないことが確認された知見の減少 | レベル 3 |
| リスクスコアの推移 | 一貫した評価手法を用いた、経時的な組織のセキュリティ態勢 | レベル2以上 |
レベル 2 の組織では、通常、MTTRやリスクスコアの推移を把握しています。 レベル 3 の組織では、検証範囲とエクスポージャー期間を主要な指標として追加しています。
CTEMに何が求められているか、また進捗をどのように測定すべきかが明確になったところで、最後の疑問は、各プラットフォームがこのフレームワークをどのようにサポートしているかということです。
Taniumが継続的な脅威への曝露管理をどのように支援するか
多くのCTEMプログラムが停滞してしまうのは、問題点を特定するツールと、それを解決するツールが別物であるためです。 Taniumは、そのギャップを埋めるお手伝いをいたします。
Taniumの自律型ITプラットフォーム「 」は、セキュリティチームおよびITチームに対し、検出、優先順位付け、是正措置、および是正後の検証を行うための単一の統合プラットフォームを提供します。これにより、連携していないシステムへの引き継ぎや、古いスキャンデータの更新を待つことなく、サイクルを円滑に進めることができます。
リアルタイムのエンドポイントインテリジェンスによる継続的な検出
Taniumは、管理対象のエンドポイントの状態をリアルタイムで可視化するため、チームは定期的なスキャンだけに頼るのではなく、資産や変更が発生したその場でそれらを特定することができます。 Taniumは、オンプレミス、リモート、クラウド環境にわたる管理対象外のデバイスにも保護範囲を拡大することができ、シャドーITにしばしば伴う死角の削減に貢献します。
状況に基づいたリスクを考慮した優先順位付け
Taniumは、いくつかの機能を通じて、リスクに基づいた優先順位付けをサポートしています。 例えば、 Tanium Benchmark では、リアルタイムのリスクスコアを算出し、顧客の指標を同業他社と比較することができます。これにより、チームは自社の環境においてリスクが最も高い箇所に焦点を当てて是正措置を講じることが可能になります。 Tanium Guardian は、リアルタイムのエンドポイント分析と、Taniumのセキュリティ専門家による厳選された分析および是正措置を組み合わせることで、組織がゼロデイ脆弱性や緊急を要する脆弱性に対処できるよう支援します。
評価から実行まで、単一のプラットフォーム上で
Tanium を利用すれば、チームはツールやデータソースを切り替えることなく、リスクの特定から対策の実施へと移行することができます。 検出結果に対しては、 のパッチ管理 や設定変更など、同じプラットフォーム内で対応を行うことが可能であり、これにより、検出から是正措置までの遅延を短縮することができます。
リスク低減の継続的な検証
Taniumは、是正措置が有効であると仮定するのではなく、検出に使用されるのと同じリアルタイムデータを用いて、措置実施後のエンドポイントの状態の変化をチームが確認できる機能を提供します。 これにより、是正措置が完了として記録されたかどうかだけでなく、曝露が実際に低減されたかどうかについても、継続的な検証が可能となります。
CTEMに関するよくある質問
CTEMプログラムを構築するにあたっては、CTEMのメリット、既存の体制との比較、プログラムを運用するために実際に何が必要か、そしてその投資が測定可能なリスク低減につながるかどうかといった、現実的な疑問が生じます。 知っておくべきことは以下の通りです。
CTEMと従来の脆弱性管理にはどのような違いがあるのでしょうか？
脆弱性管理では、既知の脆弱性（多くの場合、CVE）を特定し、予定通りに是正措置を講じることに重点が置かれています。
CTEMは、重要な要素を継続的に特定し、攻撃対象領域全体にわたる脆弱性の状況を把握し、現実的な攻撃の可能性やビジネスへの影響に基づいて優先順位を付け、悪用可能性や対策の有効性を検証し、責任の所在を明確にした上で是正措置を講じる、より広範な運用モデルです。
ASMとCTEMの違いは何ですか？
アタック・サーフェス・マネジメント（ASM）は、外部に公開されている資産や脆弱性の発見および棚卸しに重点を置いているのに対し、CTEMは、内部および外部のリスク要因を網羅した包括的なプログラムとして機能し、それらが現実的なリスクとなるかどうかを検証し、既存のITワークフローを通じて是正措置を調整します。
CTEMプログラムを支援するツールにはどのようなものがありますか？
CTEMは製品カテゴリーではなく、サイクルの5つの段階それぞれに関連付けられた、複数のツールタイプにまたがって実施されるプログラムです：
- のスコープ設定では、脅威インテリジェンスプラットフォーム、CMDB、の資産インベントリシステム（）、およびSIEMデータを活用し、各サイクルにおいて対象となる資産階層や、最も積極的に標的とされている資産を特定します。
- 「Discovery 」には、脆弱性スキャナー、エージェント型エンドポイントプラットフォーム、EASMツール、およびIDプロバイダーのデータが必要です。
- 優先順位付けツール（ ）には、CVSSスコアだけでなく、EPSSやCISAのKEVカタログ、さらには攻撃経路分析も組み込む必要があります。
- の検証（最も一般的なギャップ）には、単にパッチが適用されたかどうかだけでなく、特定の修正措置によって特定の脆弱性が解消されたことを確認するための、侵害・攻撃シミュレーション（BAS）ツール、あるいは継続的な是正措置の検証機能が必要となります。
- の稼働には、ITSMとの統合（）が不可欠です。ServiceNowは、多くの企業で採用されているソリューションです（）。各チケットには十分な背景情報が記載されているため、IT運用部門は二次的なトリアージ手順を経ることなく対応することができます。
そして、その最後の機能――エクスポージャーが実際に閉じられていることを確認すること――こそが、多くのツールスタックでは依然として一貫して提供されていない点なのです。
継続的な脅威への曝露管理は、サイバーセキュリティのレジリエンスをどのように向上させるのでしょうか？
CTEMは、高リスクの曝露が発生してから、その曝露が解消されたことが確認されるまでの期間を短縮することで、レジリエンスの向上を目指しています。 継続的なサイクルにより、新しい脆弱性が数日あるいは数週間も発見されないままになってしまうような、定期的なスキャンスケジュールに取って代わります。 資産の重要度、攻撃手法の利用可能性、および攻撃経路の分析を組み込んだリスクに基づく優先順位付けにより、抽象的な深刻度スコアに基づいてランク付けされた未対応事項を積み上げるのではなく、実際に重要資産に到達し得る脆弱性への是正措置に注力することができます。
がもたらす、あまり知られていないサイバーレジリエンス上のメリット は、制御の有効性が実証されているという点です。 設定ミスのあるホスト上のパッチが適用されたシステムであっても、別の攻撃経路を通じて悪用される可能性があります。 CTEMの検証段階では、是正措置が完了として記録されたという事実だけでなく、特定の曝露に関連する具体的な手法に対して対策が有効に機能しているかどうかが確認されます。
継続的に検証を行っている組織は、インシデント対応の際により有利な立場に立つことができます。なぜなら、最も重要な局面になって初めて判明するのではなく、現実的な条件下でどの安全対策が有効であるかを、あらかじめ確認済みだからです。
リアルタイムのエンドポイントインテリジェンスが、CTEMプログラムをどのように支援するかをご覧ください。 デモのご予約はこちら から、Taniumが継続的な可視化と統合された是正措置を通じて、組織のリスクを低減する方法をご確認ください。
