ASMの活用により、外部に公開された資産や脆弱性の可視化は容易になりました。しかし、検出されたリスク要因の中から、自社にとって本当に優先すべきものを判断することは、依然として難しい課題です。
この課題を解決する考え方が、CTEM（継続的脅威エクスポージャー管理）です。CTEMとは、攻撃表面のリスクを継続的に発見し、実際の脅威動向に基づいて優先順位付け・検証・改善を繰り返すフレームワークです。本稿では、脅威インテリジェンスを活用したリスク評価の考え方と、実務でのAI活用のポイントを解説します。
関連記事
ASMとは何か？｜攻撃表面の管理のポイントと運用課題を徹底解説
なぜ今、ASMが注目されているのか
近年、アタックサーフェスマネジメント（Attack Surface Management：ASM）への関心が高まっています。クラウド、SaaS、リモートワーク、外部委託サービスの利用が広がる中で、自社がインターネット上に公開しているIT資産をすべて把握することが難しくなっているためです。
以前であれば、資産台帳に登録されたサーバやシステムを中心に管理していれば、ある程度は対応できていました。しかし現在は状況が変わっています。
さまざまな要因により、資産台帳では把握しきれない資産が生み出されています。
たとえば、事業部門が独自にWebサイトを立ち上げることで資産台帳に登録されない資産が発生するケースがあります。サービス終了後も参照先が存在しないDNSレコードが残り、第三者によるサブドメインテイクオーバーにつながるおそれがある、いわゆる「Dangling DNS」の問題もあります。さらに、本来のリリースプロセスを経ずにテスト環境や管理画面が意図せずインターネットへ公開されてしまうケースもあります。
このように、「把握されずに新たに生まれる資産」「廃棄されずに残り続ける資産」「意図せず公開される資産」が存在することで、組織の攻撃表面は継続的に拡大していきます。
ASMは、こうした課題に対応するための取り組みです。
ASMは単に「資産を探すためのツール」ではありません。外部からアクセス可能な資産を発見し、その資産で利用されている技術を確認し、脆弱性や設定不備がないかを評価し、その状態を継続的にモニタリングする活動です。つまりASMは、「自社が攻撃者からどのように見えているのか」を継続的に確認するプロセスだと言えます。
ASM運用で直面する「優先順位付け」の難しさ
ASMを実際に運用してみると、すぐに別の悩みが出てきます。
「アラートはたくさん出るが、ツールが検知した資産は本当に自社のものなのか」
「検出された脆弱性の中で、自社にとって最も致命的なものは何か」
ASMでは、外部公開サーバ、脆弱なミドルウェア、古いライブラリ、外部に公開された管理画面、不要に開放されたポートなどが検出されます。それぞれの項目には危険度や脆弱性スコアが付与されます。しかし現場では、すべての項目に同時に対応することはできません。資産ごとに担当部門やパッチ適用のタイミングが異なり、サービス停止の影響も考慮しなければなりません。
さらに、ASMはセキュリティ部門が運用することが多い一方で、検出された資産の重要度や、その脆弱性が実際のビジネスに与える影響を最も正確に把握しているのは、必ずしもセキュリティ部門とは限りません。たとえば、あるWebサーバが単なる広報ページなのか、顧客情報と連携する重要なシステムなのか、あるいは特定部門が一時的に運用している検証環境なのかは、セキュリティ部門だけでは判断が難しいことがあります。
そのため重要なのは、「どれだけ多く発見したか」ではなく、「どのような基準で対応の優先順位を判断するか」です。
たとえば、外部公開Webサイトで古いバージョンのJavaScriptライブラリ（jQuery）が検出されたとします。セキュリティツールはこれを脆弱なライブラリとして検出し、セキュリティ部門にアラートを通知するかもしれません。しかし、実際の判断にはもう少し丁寧な確認が必要です。
たとえば、該当する脆弱性の発現条件となる機能を利用しておらず、外部入力との接点も限定的であれば、実際の悪用可能性を踏まえて緊急度を評価できる場合があります。一方で、ユーザ入力を画面に表示する機能、管理者ページ、顧客情報と連携する機能で使われている場合は、リスクの見方が変わります。同じライブラリ、同じバージョンであっても、どこで、どのように使われているかによって、実際のリスクは大きく変わるのです。
ここが実務上の難しいポイントです。
CVSS（Common Vulnerability Scoring System）のような脆弱性スコアは重要です。しかし、この指標だけでは、その脆弱性が「自社のビジネスにとって今すぐ危険なのか」を判断することはできません。実際の攻撃で使われているのか、攻撃者が注目している製品なのか、外部からアクセス可能な場所にあるのか、重要な業務システムとつながっているのか、ほかの弱点と組み合わされる可能性があるのか、といった観点をあわせて見る必要があります。
脅威インテリジェンスが加える「攻撃者の視点」
ここで必要になるのが、外部の脅威動向を収集・分析した脅威インテリジェンス（Threat Intelligence：TI）です。
ASMが「何が外部に露出しているのか」を示すものだとすれば、TIは「その露出が実際の攻撃者にとってどれほど魅力的なのか」を判断するための材料になります。
たとえば、あるサーバに中程度のスコアの脆弱性があったとしても、その脆弱性が近年のサイバー攻撃で繰り返し悪用されているのであれば、対応の優先順位は上がります。反対に、スコアが高い脆弱性であっても、実際に悪用するための条件が厳しく、対象システムでは脆弱な機能を使用しておらず、外部入力ともつながっていないのであれば、即時対応ではなく、社内の計画に沿って適切なタイミングで対応する方が現実的な場合もあります。
重要なのは、「攻撃者は脆弱性スコアを見て動いているわけではない」という点です。
攻撃者は、「侵入しやすいか」「インターネットから直接到達できるか」「侵入後に次のステップへ進めるか」「認証情報や内部システムにつながるか」といった観点で攻撃対象を見ています。
実際に公開されている侵害事例でも、攻撃者は1つの脆弱性だけを使うのではなく、複数の弱点を組み合わせて攻撃経路を作ります。米国のCISA（Cybersecurity and Infrastructure Security Agency）とFBI（Federal Bureau of Investigation）は、Ivanti Cloud Service Applianceの事例において、複数の脆弱性がチェーンとして悪用され、初期アクセス、リモートコード実行、認証情報の取得、Webシェルの設置につながったと説明しています。[i]
この事例は、個別の脆弱性だけを見るのではなく、攻撃者がどのような順序で弱点をつなげるのか、つまり攻撃者の戦術・技術・手順（Tactics, Techniques, Procedures：TTPs）を見る必要があることをよく示しています。
[i]CISA / FBI, “Threat Actors Chained Vulnerabilities in Ivanti Cloud Service Applications,” AA25-022A
https://www.cisa.gov/news-events/cybersecurity-advisories/aa25-022a
ASM運用をCTEMへ発展させる考え方
このように考えると、ASM運用の次のステップは自然に見えてきます。
【ASMの検出結果にTIを加えた後続作業の流れ】
この流れを体系化したフレームワークが継続的脅威エクスポージャー管理（Continuous Threat Exposure Management：CTEM）です。
CTEMは、組織のリスク要因を継続的に発見し、実際の脅威の観点から優先順位を付け、攻撃成立の可能性を検証し、改善につなげるためのセキュリティ運用フレームワークです。CTEMは、従来の脆弱性管理だけにとどまらず、未把握資産の発見、脅威情報、悪用可能性、攻撃経路、実際に攻撃が成立する可能性の検証なども考慮しながら、継続的にリスク低減を図るアプローチとして捉えることができます。
なお、ガートナー（Gartner）は、CTEMのプロセスをScoping（スコープ設定）→Discovery（発見）→Prioritization（優先順位付け）→Validation（検証）→Mobilization（対応・改善の実行）と提唱しています。
【ガートナーが提唱するCTEMのプロセス】
CTEMの5つのステップとASM
まず、どの資産や業務を優先的に守るべきか、対象範囲を定めます。次に、ASMなどを活用して外部に露出している資産や脆弱性を発見します。その後、発見された項目をすべて同じように扱うのではなく、TIを活用して、実際の攻撃動向や自社環境における重要度をもとに優先順位を付けます。
さらに、「発見されたリスク要因が実際に悪用可能なのか」「既存の防御策で防止・検知できるのか」を確認します。最後に、検証結果をもとに担当部門や対応方針を決め、改善後に再確認するサイクルを繰り返します。
重要なのは、CTEMがASMを置き換えるものではないという点です。
ASMは、CTEMを実践するうえで、外部に露出した資産やリスク要因を把握する重要な基盤となります。資産やリスク要因を発見できなければ、優先順位付けも、検証も、改善も始まりません。ただし、ASMの運用で得られた結果を単なるアラート一覧として終わらせるのではなく、「実際に攻撃可能なのか」「自社にとって重要なのか」「どの対応を先に行うべきなのか」までつなげて考える必要があります。
【CTEMにおけるASMのスコープ】
CTEM実務運用におけるAI活用ポイント
CTEMでは、ASMによる資産や脆弱性の発見だけでなく、その情報をもとに影響を評価し、対応方針を決定し、必要に応じて検証まで行う一連のプロセスが求められます。
しかし実務では、それぞれの段階で多くの情報収集や関係者との調整が発生するため、運用負荷が高くなりやすいという課題があります。
たとえば、Prioritization（優先順位付け）の段階では、発見された脆弱性が自社でどの程度のリスクになるのかを判断する必要があります。しかし一般的にはセキュリティ部門がASMを担当している一方で、他部門のシステム構成やビジネス上の重要度まで把握しているとは限りません。そのため実務上は、CVSSなどの脆弱性スコアを中心に優先順位を判断することもあります。
近年は、高度化したAIを活用することで、ASMの検出結果だけでなく、内部資産との接続関係や利用中の技術スタック、システムの利用状況などの情報を組み合わせながら脆弱性の影響を整理し、優先順位付けを支援できるようになりつつあります。人手では時間のかかる情報収集や分析を補助することで、より実態に即した評価が期待できます。
また、Mobilization（対応・改善の実行）の段階では、評価結果を現場の担当部門へ展開し、対応を進めてもらう必要があります。しかし、セキュリティ部門が発信する脆弱性情報は、全社向けの連絡を前提としているため、抽象度が高くなりがちです。その結果、現場では「この脆弱性は自分たちの環境にどう関係するのか」が分からず、「指示されたのでパッチを適用する」といった機械的な対応にとどまるケースもあります。
現場が本当に知りたいのは、「自分たちのシステムではどのような条件で悪用されるのか」「想定される最大の被害は何か」「どの程度急いで対応すべきか」といった情報です。このような内容をセキュリティ部門だけで個別に説明することには限界がありますが、各組織のシステム情報を参照できるAIを活用することで、担当部門ごとの文脈に合わせた説明が可能になります。結果として脆弱性への理解が深まり、パッチ適用が難しい場合でも、システム特性を踏まえた現実的な緩和策を検討しやすくなります。
さらに、Validation（検証）の段階でもAIを活用できる場面があります。脆弱性検証そのものをAIが実施するわけではありませんが、検証前に確認すべき項目の整理や、安全な検証手順のドラフト作成、実施後の確認ポイントのチェックリスト化など、周辺業務の支援には有効です。実際にテストを行うかどうか、実施範囲やサービス影響、承認手続きについては人が判断する必要がありますが、繰り返し発生する情報整理や資料作成をAIが補助することで、Validationの効率化が期待できます。
AIを活用したCTEM自動化への期待は高まっています。しかし現時点では、AIにすべての判断を任せるよりも、人が行う判断の質と速度を高める用途から活用を始める方が現実的です。特に、脆弱性情報を実際のシステム文脈に合わせて解釈し、関係者の理解を支援する領域は、AIとの親和性が高い分野と言えるでしょう。まずはこうした領域から活用を進め、段階的に適用範囲を拡大していくことが、現実的なCTEMにおけるAI活用の第一歩になると考えます。
重要なのは、AIがリスクを代わりに確定するわけではないという点です。実際のテスト実施可否や範囲、サービス影響、例外受容、最終的な対応優先順位は、引き続き人が判断する必要があります。
攻撃表面リスク管理のまとめ
ASMは、自社が外部からどのように見えているかを把握するための重要な取り組みです。しかし、資産や脆弱性を発見するだけでは、限られたリソースの中で何から対応すべきかを判断することはできません。
押さえておきたいのは、発見したリスク要因を実際の脅威や自社環境の文脈の中で評価し、「本当に優先的に対応すべきリスクは何か」を見極めることです。そのための考え方がCTEMであり、ASMはその出発点となります。
また、こうした評価や調整のプロセスは多くの情報収集と関係者との連携を必要とするため、運用負荷が高くなりがちです。AIはそのすべてを自動化するものではありませんが、情報整理や影響分析、関係者への説明を支援することで、CTEM運用の実効性を高める有効な手段になり得ます。
今後の課題は、より多くのリスク要因を発見することではありません。
発見した情報の中から、自社にとって本当に対応すべきリスクを見極め、継続的に改善へつなげていくことです。
CTEMは、そのための意思決定を支える実践的なアプローチと言えるでしょう。
