CTEM実装ガイドとは？5ステージとEASMから始める現実的な進め方

CTEM実装とは何か

「CTEM とは」ではなく「運用プログラム」として捉える

「CTEM」は「Continuous Threat Exposure Management」の略で、Gartner が整理した 「5段階」 の継続フレームとして語られることが多いです。ただし、実務で本当に重要なのは単語の意味ではありません。何を対象にし、どの 露出リスク を優先し、どう検証し、誰の仕事へ戻すかを固定できるかどうかです。

XM Cyber↗は、CTEM を 攻撃者の横移動 と 重要資産 への 経路 で 露出リスク を見直すフレームとして説明しています。さらにMicrosoft Security Exposure Management↗は、施策s、指標、recommendations、イベント を一つの pipeline へ集約し、「何が見つかったか」だけでなく「どの 施策 をどう改善するか」を追える形にしています。つまり CTEM は、findings を増やす活動ではなく、修正の意思決定を変えるための運用プログラムです。

「Scoping / Discovery / 優先順位付け / Validation / Mobilization」を実務に置き換える

5ステージはカタカナで覚えると抽象的に見えますが、実務の日本語に翻訳するとかなり扱いやすくなります。 「Scoping」 は守る対象と意思決定者を決める工程、 「Discovery」 は台帳と外部観点の差分を掴む工程、 「優先順位付け」 は「今週直すべき 露出リスク」を決める工程、 「Validation」 は本当に 経路 が切れたかを確かめる工程、 「Mobilization」 は findings を 対応票 と見直しへ戻す工程です。

特に「Validation」と「Mobilization」は、用語だけ知っていても実装されないことが多い部分です。修正依頼を出しただけで 検証 と見なしたり、月次資料へ載せただけで 改善実行 と見なしたりすると、CTEM はすぐに形骸化します。

なぜ CTEM は導入でつまずきやすいのか

ツール導入を「CTEM 実装」だと誤解しやすい

CTEM 導入が止まりやすい一番の理由は、可視化製品を入れた瞬間に「CTEM を始めた」と感じてしまうことです。確かに 把握 を支える製品は重要です。しかし CTEM の成否は、可視化の量よりどこまで意思決定が変わったかで決まります。

露出リスク を 500 件見つけても、そこから誰が、いつまでに、どの evidence で、どの基準で 完了 するかが決まらなければ CTEM は始まっていません。逆に 20 件しか見えていなくても、その 20 件に 優先度 を付け、管理責任者を置き、翌週再確認できるなら、運用プログラムとしては前進しています。

最初から全資産・全露出を統合しようとして止まる

もう一つの典型的な失敗は、最初から「全部入り」を目指すことです。cloud、endpoint、identity、SaaS、委託先、子会社、M&A 後資産、公開面、内部資産、CMDB、ITSM を一度に統合しようとすると、対象範囲 が曖昧になりやすくなります。

XM Cyber の CTEM 解説でも、scoping は「何を見るか」だけではなく、business-重要資産s、access 経路s、stakeholder を deliberate に合わせる工程だとされています。ここを飛ばすと、発見される 露出リスク は増えても、優先度 の意味がなくなります。

CTEM の 5ステージを実務へどう落とし込むか

Scoping で「守る対象 / 期間 /管理責任者」を決める

「Scoping」は単なる監視対象リスト作りではありません。ここでは少なくとも、何を守るか、どこまでを見るか、今回の判断対象をいつまでにするか、誰が 優先度 を承認するかの 4 点を決める必要があります。止まると売上や会員導線へ影響するシステム、ブランドに直結する公開導線、認証や管理権限に近い面を最初に言語化しておくと、後の prioritization が severity だけの議論になりにくくなります。

Discovery は EASM と既存台帳を突き合わせて現実を見る

「Discovery」は発見量を増やす工程というより、台帳の論理と外から見える現実の差を見つける工程です。ここで最も扱いやすい入口が EASM、つまり外部観点の公開面把握です。公開面の観測は、社内 CMDB が未整備でも始められます。

たとえばサブドメイン監視、DNS セキュリティチェック、SSL証明書の期限監視で扱っている domain、DNS、HTTP、TLS、証明書、公開管理画面は、外部観点の基準線を作りやすい領域です。この結果を既存台帳と突き合わせることで、「台帳にはないのに見える」「止めたはずなのにまだ見える」という差分が findings になります。

優先順位付け は「攻撃の成立しやすさ / 事業影響 /外部観点」で決める

「優先順位付け」は CVSS の高低を並べる工程ではありません。実務では、 「攻撃の成立しやすさ」 、 「事業影響」 、 「外部観点可視性」 の 3 軸で考えると整理しやすくなります。CISA の KEV Catalog↗も、現実の攻撃環境で で exploitation が確認された脆弱性を prioritization の入力へ使うべきだと明示しています。つまり「存在する脆弱性」と「実際に悪用されている脆弱性」は分けて考えるべきです。

XM Cyber は、自社研究として 露出リスクs の多くは dead end で、重要資産 へつながるものは一部だと示しています。ここから読めるのは、全部を 緊急対応 にするのは運用として間違いだということです。優先度とは、影響が大きいからではなく、そこから 攻撃者の横移動 が起きるから高くなるものです。

Validation は「攻撃経路 / 再観測 / 証拠」で確度を上げる

「Validation」は最も軽視されやすい工程です。多くの現場では、対応票 を 完了 した瞬間に「直った」と見なします。しかし CTEM はそこを厳しく扱います。別 経路 が残る、古い route が生きる、設定 drift が起きる、部分修正で lateral movement が残る、といったことが珍しくないからです。

XM Cyber は 検証 を、是正対応 が本当に attack 経路 を壊したかを確認する工程として説明しています。外部公開面なら設定変更後に再クロールや再観測を行い、本当に見えなくなったかを確認する必要があります。Validation は「修正完了メール」ではありません。外部観点で再観測できた、経路 が成立しなくなった、証拠を残せた、まで含めて初めて 完了 に近づきます。

Mobilization は「対応票 / due date /見直し」へ戻す

「Mobilization」は、CTEM をただの発見活動で終わらせない最後の工程です。発見された 露出リスク を security チームだけの知見として閉じず、誰の仕事か、いつまでか、どの会議で追うかへ戻します。

Tenable の Mobilization Quick Reference Guide↗でも、改善実行 は prioritized CTEM findings を 事業影響 のある action に変換する stage と整理されています。またCensys の ServiceNow VR 連携↗も、露出リスクs と vulnerabilities を triage、prioritization、remediation へ流す前提で設計されています。製品は違っても、finding を 表計算シート に残さず、運用の仕事へ戻すことが 改善実行 の本質です。

日本企業が EASM から始めると失敗しにくい理由

台帳が不完全でも外部観点で始められる

日本企業で CTEM が止まりやすいのは、内部台帳がそろうまで待ってしまうからです。けれど初動で必要なのは完璧な統合基盤ではなく、攻撃者から見える面をまず掴むことです。外部観点の利点は、観測開始のハードルが低いことにあります。正規ドメイン、主要ブランド、既知のサブドメインがあれば、まず公開面の現状確認ができます。

外部公開面は短期成果を示しやすい

公開面監視は、導入初期の 短期成果 を作りやすい領域です。不要サブドメインの停止、dangling DNS の解消、証明書切れの予防、公開管理画面の是正、管理責任者不明資産の整理などは、「実際に減った」と説明しやすいからです。しかもこの領域は、セキュリティだけでなくインフラ、Web、情シス、事業管理責任者と会話しやすく、優先度 を business side へ接続する入口になります。

CAASM や内部全面統合は後段でよい

もちろん EASM だけで CTEM が完成するわけではありません。XM Cyber も、EASM は 可視性 を出すが analysis は edge で止まりやすいと説明しています。CTEM ではその外側だけでなく、entry point が内部の misconfiguration、identity、経路 へどうつながるかまで見る必要があります。

ただし day one から CAASM、identity、cloud、ITSM の全面統合を目指す必要はありません。順番としては、EASM で基準線を作る、high-value use case で 優先度 と 検証 を回す、改善実行 を定着させる、必要な内部統合を増やすの方が現実的です。

最初の 90 日でやるべきこと

以下の 90 日プランは、XM Cyber の 5ステージ解説、Microsoft Security Exposure Management の 施策s / 指標 / recommendations / イベント の考え方、CISA の prioritization 観点を踏まえて、日本企業向けに再構成した実務プランです。目的は 90 日で完成させることではなく、1周目を回して運用の型を作ることにあります。

0-30 日で「対象範囲」と対象ドメインを固定する

最初の 30 日でやるべきことは、見えるものを増やす前に守る対象を固定することです。主要ブランド、主要ドメイン、critical service、weekly見直し参加者、高優先度の判断条件を小さく定義します。high 優先度 の条件は作り込みすぎず、「重要資産 に近い」、「外から見えやすい」、「悪用経路が説明しやすい」の 3 条件程度で十分です。

31-60 日で 把握 と prioritize を回す

次の 30 日では、公開面と既存台帳を突き合わせて差分を findings に変えます。新規に見えた FQDN、管理責任者不明の公開面、証明書や DNS の危険変更、exposed admin / staging、既に 攻撃の成立しやすさ が高い known 露出リスク を同じ 課題一覧 に載せ、「今週直すべきもの」を決めます。この段階で 課題一覧 の見せ方を統一しておくと、dead end と本当の 経路 が見えやすくなります。

61-90 日で validate と mobilize を定着させる

90 日目までに最低限作りたいのは、完了 の定義と見直しの 頻度 です。修正後の再観測条件、対応票 の必須項目、許容リスク の記録ルール、monthly見直しの agenda、summary と appendix の分け方を固定します。ここまで来て初めて CTEM は「たくさん見つけた」から「改善を回している」へ変わります。

誰が何を持つと CTEM は回るのか

セキュリティ、インフラ、アプリ、事業管理責任者の役割分担

CTEM は セキュリティ担当 だけでは回りません。最低でも、対象範囲 と 優先度 を持つセキュリティ、DNS / TLS / 公開基盤の remediation を引き取るインフラ、管理画面や認証導線を触るアプリ / Web 運用、重要度 と 許容リスク を判断する事業管理責任者の 4 役が必要です。

weekly / monthly見直しで止めるべき論点

CTEM見直しは件数共有ではなく、次の行動を決める会議にするべきです。weekly では「新規 high 優先度 露出リスク」、「管理責任者未設定」、「due date 超過」、「検証 待ち」を見ます。monthly では「施策 / KPI の変化」、「許容リスク の aging」、「再発パターン」、「次月の 対象範囲見直し」を見ます。weekly は「誰が何を持つか」、monthly は「何を変えるか」を決める場だと考えると崩れにくくなります。

CTEM の KPI と定例運用はどう設計するか

「有効検知率 /管理責任者設定率 / validated 露出リスク rate / remediation lead time」

KPI は多くても 4〜6 個に抑えた方がよいです。初期段階でおすすめなのは、 「有効検知率」 、 「管理責任者設定率」 、 「validated 露出リスク rate」 、 「remediation lead time」 の 4 指標です。

この 4 指標のよいところは、悪化したときに次の打ち手が見えることです。有効検知率が低ければ 把握 が広すぎるか prioritization が弱い。管理責任者設定率が低ければ責任分界が曖昧。validated 露出リスク rate が低ければ 完了 定義が弱い。lead time が長ければ 改善実行 が詰まっています。単に「何件見つかったか」より、改善へつながりやすい指標です。

「許容リスク」と再検証条件を別管理する

「許容リスク」は 課題一覧 の掃除箱にしてはいけません。認めるなら、誰が承認したか、いつ再評価するか、なぜ今は直さないか、何が変われば reopen するかを最低限残すべきです。Microsoft の 露出リスク 施策s も、指標 や イベント を通じて 態勢 変化を追う設計になっています。つまり 許容リスク は「見なかったことにする」のではなく、「別枠で aging を追う」方が正しいです。

CTEM導入を失敗させる典型パターン

脆弱性件数だけを追って prioritize が壊れる

CTEM を 脆弱性件数 の延長で見ると、まず失敗します。件数は 可視性 の目安にはなりますが、優先度 の根拠にはなりません。件数中心の運用になると、「数を減らしやすい 露出リスク」が先に処理され、重要資産 へつながる 経路 が残るという逆転が起きます。

Validation を飛ばして全部 緊急対応 にする

導入初期は見えたもの全部が怖く見えます。しかし 緊急対応 を乱発すると、修正チームはどれを本気でやるべきか分からなくなります。しかも 完了 の証明が弱いので、翌月同じものが戻ってきます。Validation は「ここは本当に閉じた」と言える根拠を残す工程であり、ここを軽くすると CTEM は「怖い話をする活動」で終わります。

Mobilization が弱く、対応票 と見直しへ戻らない

発見結果が セキュリティ担当 の中に留まり、対応票 化、due date、例外承認、monthly見直しへ戻っていない状態です。この形になると、どれだけ 把握 が優れていても 態勢 は変わりません。むしろ「見えるのに直らない」という疲弊だけが残ります。CTEM を実装するなら、改善実行 を 把握 と同じ重さで扱う必要があります。

CTEM運用の土台づくりなら ASM診断 PRO

CTEM を day one からフルスコープで回すのは現実的ではありません。最初の 90 日で重要なのは、何が正規の公開面か、何が今見えているか、どこに 優先度 を置くかの基準線を作ることです。ASM診断 PRO は CTEM 専用製品ではありませんが、この「EASM first」の入口をかなり作りやすくします。

無料診断から入ると、外から見える domain、subdomain、TLS、HTTP、公開面の状況を外部観点で把握できます。これは 把握 の最初の材料として相性が良く、「台帳では把握していたはずだが外からまだ見える」、「管理責任者が曖昧」、「証明書や DNS の危険変更がある」といった差分を掴みやすくなります。CTEM の初動では、この差分こそが prioritization の起点になります。

また CTEM を止めにくくするには、セキュリティ担当 だけで閉じない evidence が必要です。ASM診断 PRO は外部観点の公開面を「いま見えている事実」として説明しやすいので、weekly見直しでインフラ、Web、情シス、事業管理責任者と話す前提に向いています。CTEM の最初の一周目で必要なのは、完璧な統合より実際に回る入り口です。

まずは無料診断で外から見える公開面を確認し、今回の quarter はどこまでを 対象範囲 にするかを決めてください。そこから管理責任者、優先度、検証、monthly見直しを足していく方が、CTEM は概念で終わらず実装へ進みます。関連する全体像は機能解説とExposure Management の整理記事から確認できます。

よくある質問（FAQ）

CTEM と脆弱性管理は何が違いますか

脆弱性管理は主に既知資産と CVE を中心に優先順位を付ける運用です。CTEM はそこから一歩進み、misconfiguration、identity、公開面、attack 経路、事業影響 まで含めて「何を今直すべきか」を決めます。件数ではなく、到達可能性と影響の大きさで remediation を変えるのが CTEM の特徴です。

EASM だけでは CTEM になりませんか

なりません。EASM は CTEM の入口として非常に有効ですが、基本は外から見える可視化です。CTEM では、その entry point が内部の 経路、identity、権限、重要資産 へどうつながるか、修正後に本当に risk が減ったかまで扱います。EASM は「始めやすい入口」ですが「ゴール」ではありません。

5 ステージは同時に回すべきですか

最初から同じ濃さで回す必要はありません。むしろ初期は「Scoping」と「優先順位付け」を明確にし、「Validation」と「Mobilization」を薄くてもよいから固定する方が重要です。Discovery を増やしすぎると、かえって運用が止まります。

中堅企業でも CTEM を始められますか

始められます。大事なのは 全面的な対象範囲 で始めないことです。最初は公開面と主要ドメインに絞り、weekly見直しを 30 分、high 優先度 露出リスク のみにする形でも十分です。CTEM は豪華な統合基盤ではなく、「優先順位と remediation の質を上げる運用」と捉えると着手しやすくなります。

ペンテストや BAS は CTEM のどこで使いますか

主に「Validation」と「優先順位付け」の補強で使います。CTEM 自体は continuous な運用フレームですが、ペンテストや BAS は特定の 経路 や control の有効性を深く確かめるのに向いています。つまり CTEM の代替ではなく、「ここは本当に危ないのか」「修正は効いたのか」を補強する役割です。

まとめ

CTEM 実装で重要なのは、5ステージの言葉を覚えることではありません。何を守るか、何を今週直すか、本当に閉じたか、誰の仕事へ戻すかを固定し続けることです。そのためには、最初から全部を統合するより、EASM を入口にして公開面の基準線を作り、90 日で一周回せる運用の型を作る方が現実的です。

今日から始めるなら、まず対象範囲 を インターネット-facing 露出リスク に限定する、weekly見直しで管理責任者と due date を固定する、完了 の条件に再観測と 検証 を含めるの 3 つに絞ってください。この 3 つができるだけで、CTEM は概念説明から実装へ移ります。