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

CTEM実装とは何か

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

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

XM Cyber↗は、CTEM を attacker movement と critical asset への path で exposure を見直すフレームとして説明しています。さらにMicrosoft Security Exposure Management↗は、initiatives、metrics、recommendations、events を一つの pipeline へ集約し、「何が見つかったか」だけでなく「どの initiative をどう改善するか」を追える形にしています。つまり CTEM は、findings を増やす活動ではなく、修正の意思決定を変えるための運用プログラムです。

`Scoping / Discovery / Prioritization / Validation / Mobilization` を実務に置き換える

5ステージはカタカナで覚えると抽象的に見えますが、実務の日本語に翻訳するとかなり扱いやすくなります。Scopingは守る対象と意思決定者を決める工程、Discoveryは台帳と outside-in の差分を掴む工程、Prioritizationは「今週直すべき exposure」を決める工程、Validationは本当に path が切れたかを確かめる工程、Mobilizationは findings を ticket と review へ戻す工程です。

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

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

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

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

exposure を 500 件見つけても、そこから誰が、いつまでに、どの evidence で、どの基準で close するかが決まらなければ CTEM は始まっていません。逆に 20 件しか見えていなくても、その 20 件に priority を付け、owner を置き、翌週再確認できるなら、運用プログラムとしては前進しています。

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

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

XM Cyber の CTEM 解説でも、scoping は「何を見るか」だけではなく、business-critical assets、access paths、stakeholder を deliberate に合わせる工程だとされています。ここを飛ばすと、発見される exposure は増えても、priority の意味がなくなります。

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

Scoping で `守る対象 / 期間 / owner` を決める

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

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

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

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

Prioritization は `exploitability / business impact / outside-in` で決める

`Prioritization` は CVSS の高低を並べる工程ではありません。実務では、exploitability、business impact、outside-in visibilityの 3 軸で考えると整理しやすくなります。CISA の KEV Catalog↗も、wild で exploitation が確認された脆弱性を prioritization の入力へ使うべきだと明示しています。つまり「存在する脆弱性」と「実際に悪用されている脆弱性」は分けて考えるべきです。

XM Cyber は、自社研究として exposures の多くは dead end で、critical asset へつながるものは一部だと示しています。ここから読めるのは、全部を urgent にするのは運用として間違いだということです。優先度とは、影響が大きいからではなく、そこから attacker movement が起きるから高くなるものです。

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

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

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

Mobilization は `ticket / due date / review` へ戻す

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

Tenable の Mobilization Quick Reference Guide↗でも、mobilization は prioritized CTEM findings を business impact のある action に変換する stage と整理されています。またCensys の ServiceNow VR 連携↗も、exposures と vulnerabilities を triage、prioritization、remediation へ流す前提で設計されています。製品は違っても、finding を spreadsheet に残さず、運用の仕事へ戻すことが mobilization の本質です。

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

台帳が不完全でも outside-in で始められる

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

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

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

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

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

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

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

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

0-30 日で `scope` と対象ドメインを固定する

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

31-60 日で discovery と prioritize を回す

次の 30 日では、公開面と既存台帳を突き合わせて差分を findings に変えます。新規に見えた FQDN、owner 不明の公開面、証明書や DNS の危険変更、exposed admin / staging、既に exploitability が高い known exposure を同じ backlog に載せ、「今週直すべきもの」を決めます。この段階で backlog の見せ方を統一しておくと、dead end と本当の path が見えやすくなります。

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

90 日目までに最低限作りたいのは、close の定義と review の cadence です。修正後の再観測条件、ticket の必須項目、accepted risk の記録ルール、monthly review の agenda、summary と appendix の分け方を固定します。ここまで来て初めて CTEM は「たくさん見つけた」から「改善を回している」へ変わります。

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

セキュリティ、インフラ、アプリ、事業 owner の役割分担

CTEM は security team だけでは回りません。最低でも、scope と priority を持つセキュリティ、DNS / TLS / 公開基盤の remediation を引き取るインフラ、管理画面や認証導線を触るアプリ / Web 運用、criticality と accepted risk を判断する事業 owner の 4 役が必要です。

weekly / monthly review で止めるべき論点

CTEM review は件数共有ではなく、次の行動を決める会議にするべきです。weekly では `新規 high priority exposure`, `owner 未設定`, `due date 超過`, `validation 待ち` を見ます。monthly では `initiative / KPI の変化`, `accepted risk の aging`, `再発パターン`, `次月の scope 見直し` を見ます。weekly は「誰が何を持つか」、monthly は「何を変えるか」を決める場だと考えると崩れにくくなります。

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

`有効検知率 / owner 設定率 / validated exposure rate / remediation lead time`

KPI は多くても 4〜6 個に抑えた方がよいです。初期段階でおすすめなのは、有効検知率、owner 設定率、validated exposure rate、remediation lead timeの 4 指標です。

この 4 指標のよいところは、悪化したときに次の打ち手が見えることです。有効検知率が低ければ discovery が広すぎるか prioritization が弱い。owner 設定率が低ければ責任分界が曖昧。validated exposure rate が低ければ close 定義が弱い。lead time が長ければ mobilization が詰まっています。単に `何件見つかったか` より、改善へつながりやすい指標です。

`accepted risk` と再検証条件を別管理する

`accepted risk` は backlog の掃除箱にしてはいけません。認めるなら、誰が承認したか、いつ再評価するか、なぜ今は直さないか、何が変われば reopen するかを最低限残すべきです。Microsoft の exposure initiatives も、metrics や events を通じて posture 変化を追う設計になっています。つまり accepted risk は「見なかったことにする」のではなく、`別枠で aging を追う` 方が正しいです。

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

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

CTEM を vulnerability count の延長で見ると、まず失敗します。件数は visibility の目安にはなりますが、priority の根拠にはなりません。件数中心の運用になると、「数を減らしやすい exposure」が先に処理され、critical asset へつながる path が残るという逆転が起きます。

Validation を飛ばして全部 urgent にする

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

Mobilization が弱く、ticket と review へ戻らない

発見結果が security team の中に留まり、ticket 化、due date、例外承認、monthly review へ戻っていない状態です。この形になると、どれだけ discovery が優れていても posture は変わりません。むしろ「見えるのに直らない」という疲弊だけが残ります。CTEM を実装するなら、mobilization を discovery と同じ重さで扱う必要があります。

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

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

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

また CTEM を止めにくくするには、security team だけで閉じない evidence が必要です。ASM診断 PRO は outside-in の公開面を `いま見えている事実` として説明しやすいので、weekly review でインフラ、Web、情シス、事業 owner と話す前提に向いています。CTEM の最初の一周目で必要なのは、完璧な統合より実際に回る入り口です。

まずは無料診断で外から見える公開面を確認し、今回の quarter はどこまでを scope にするかを決めてください。そこから owner、priority、validation、monthly review を足していく方が、CTEM は概念で終わらず実装へ進みます。関連する全体像は機能解説とExposure Management の整理記事から確認できます。

よくある質問（FAQ）

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

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

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

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

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

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

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

始められます。大事なのは full-scope で始めないことです。最初は公開面と主要ドメインに絞り、weekly review を 30 分、high priority exposure のみにする形でも十分です。CTEM は豪華な統合基盤ではなく、`優先順位と remediation の質を上げる運用` と捉えると着手しやすくなります。

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

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

まとめ

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

今日から始めるなら、まずscope を internet-facing exposure に限定する、weekly review で owner と due date を固定する、close の条件に再観測と validation を含めるの 3 つに絞ってください。この 3 つができるだけで、CTEM は概念説明から実装へ移ります。