仮想パッチの記事では、脆弱性が公開されてからパッチを当てるまでの間をどう守るかを書きました。ただ、その手前に「外から見えている自社のサーバや機器を、そもそも全部つかめているのか」という問題があります。今回は、そこを受け持つ EASM（ASM）について、経済産業省のガイダンスと各社の公開資料を読み比べながら、しくみと運用の流れを図にしてみました。
- なぜ今、外から見える資産の把握が問題になっているのか
- EASM（ASM）とは何か。脆弱性診断や CAASM とどう違うのか
- EASM を使うと、どんなものが見つかるのか
- 各社の製品に共通するしくみ（6つの層）と、製品によって違うところ
- 導入の進め方と、日々の運用・優先順位の付け方
この記事は、次の製品の公開資料（製品ページ、ドキュメント、データシートなど）を2026年10月時点で読み比べ、共通する考え方を一般化してまとめたものです。本文は特定の製品の実装ではなく、「こういう構成が考えられる」「こういう関係になっていることが多い」という一般例として書いています。
- CyCognito（CyCognito）
- CrowdStrike Falcon Exposure Management の EASM 機能（旧 Falcon Surface）
- TrendAI Vision One（トレンドマイクロ）の Cyber Risk Exposure Management（旧 Attack Surface Risk Management）
- Microsoft Defender External Attack Surface Management（Defender EASM）と、Microsoft Security Exposure Management との連携
- Palo Alto Networks Cortex Xpanse
- Tenable One Attack Surface Management、Censys の ASM、Qualys CyberSecurity Asset Management の EASM
- 国内のサービスの発表資料（NRIセキュア「ASMimosa」、GMOサイバーセキュリティ by イエラエ「GMOサイバー攻撃 ネット de 診断 ASM」）
製品ごとの機能・方式・名称・提供状況は変わることがあり、この記事の説明がそのまま当てはまらない製品もあります。特定の製品を勧めたり、性能や効果を保証したりするものでもありません。導入や比較を検討するときは、必ずメーカーの最新のドキュメントを確認し、メーカーや販売店に問い合わせてください。
なぜ今、外から見える資産が問題になるのか
以前は、守る対象の多くが社内のデータセンターにあり、インターネットとの出入り口はファイアウォールなど数か所に絞られていました。今は、クラウドに立てたサーバ、委託先が作ったキャンペーンサイト、拠点ごとに置いた VPN 機器、開発中のサービスなど、インターネットから直接見える入口があちこちにあります（図1）。
入口が増えると、それぞれが今どうなっているか（誰が管理しているか、ソフトウェアは最新か、まだ使っているのか）を追いきれなくなります。担当者が異動したり、委託先との契約が終わったりすると、動いているのに誰も見ていない資産ができてしまいます。
攻撃者は公開情報から入口を探している
攻撃者は、いきなり侵入を試みるわけではありません。まず、インターネットで誰でも見られる情報から、狙えそうな入口を探します。たとえば DNS（ドメイン名と IP アドレスを対応づけるしくみ）や、証明書透過性（CT：Certificate Transparency）のログです。
CT は、Web サイトなどで使う TLS サーバ証明書が発行されたことを公開のログに記録し、不正な発行がないかを誰でも確かめられるようにするしくみです（RFC 9162）。便利なしくみですが、裏を返すと「新しいドメイン名がいつ使われ始めたか」も公開されることになります。図2は、新しいサーバを公開してから外から調べられるまでの流れです。
- ①〜③：開発担当者が新しいサブドメイン用の証明書を申請します。認証局（CA）は発行の記録を CT ログに登録し、証明書を発行します。CT ログにはドメイン名が載ります。
- ④：担当者がサーバに証明書を入れ、サービスを公開します。
- ⑤〜⑥：攻撃者の自動スキャンは CT ログを見張っていて、新しく載ったドメイン名を拾います。
- ⑦：拾った名前を DNS で引き、IP アドレスを調べます。
- ⑧〜⑨：その IP アドレスに、開いているポートや表示される画面、ソフトウェアのバージョンを調べに行きます。
2018年に発表された研究では、CT のおとりとして証明書を発行したところ、発行から数分後にはそのドメインを狙った調査（スキャン）が届いたと報告されています。攻撃者は「設定が終わってから見に来る」のではなく、公開された直後から見に来ると考えておいたほうがよさそうです。こうした調べ物は、フロンティアAIのコラムで書いたように、AI によってさらに自動化しやすくなっています。
狙われやすいのは台帳にない資産
社内の管理台帳と、インターネットから実際に見えている資産を重ねると、図3のようにずれていることがよくあります。台帳にあって外からも見える資産は、ふだんからパッチや設定の管理が回っていることが多いです。問題になりやすいのは、台帳にないのに外から見えている資産です。
最近は、ここに AI 関係のものも加わっています。たとえば MCP（Model Context Protocol：AI エージェントが外部のツールやデータにつなぐための共通の決まり）のサーバです。クラウドセキュリティ企業の Wiz は2026年7月、MCP を使っているクラウド環境のおよそ6分の1で、インターネットに公開された MCP サーバが見つかり、公開されたもののおよそ7割は、認証していない相手にも使えるツールの一覧を返したと報告しています。試しに立てた API がそのまま残る、という昔からある問題が、AI でもくり返されていると言えます。
EASM（ASM）とは
EASM（External Attack Surface Management：外部アタックサーフェス管理）は、インターネットから見える自社の IT 資産を、攻撃者と同じ「外側」から見つけて、そこにあるリスクを継続的に確かめていく取り組みと、そのためのツールです。アタックサーフェス（攻撃面）は、攻撃者が狙える入口の集まりのことです。
経済産業省の「ASM（Attack Surface Management）導入ガイダンス」は、ASM を「組織の外部（インターネット）からアクセス可能な IT 資産を発見し、それらに存在する脆弱性などのリスクを継続的に検出・評価する一連のプロセス」としています。国内では、外部に限った意味で単に ASM と呼ぶことも多いので、この記事では EASM と ASM をほぼ同じ意味で使います。
建物にたとえると、EDR（端末の中の不審な動きを見張るしくみ）や社内の監視は、建物の中に付けた防犯カメラです。EASM は、建物の外周を歩いて回り、開いたままの勝手口や壊れた窓がないかを外から点検する人にあたります（図4）。
防犯カメラは、入ってきた人の動きを見つけるのが得意です。外周の点検は、入られる前に入口そのものを減らすためのものです。どちらかがあればよいのではなく、受け持つ場所が違います。
脆弱性診断とのちがい
よく比べられるのが脆弱性診断です。ガイダンスでは、対象、脆弱性の確かさ、相手への影響の3点で違いを整理しています。年に1回などの頻度で深く調べる脆弱性診断に対して、EASM は未把握のものも含めて広く、くり返し見ます（図5）。
| 比べる点 | 脆弱性診断 | EASM（ASM） |
|---|---|---|
| 対象 | 把握している資産（診断を申し込んだもの） | 未把握のものを含め、インターネットから届く資産 |
| 脆弱性の確かさ | 攻撃をまねたリクエストを送って応答を見るので、確度が高い | 画面やバージョン表示など、ふつうのアクセスで得た情報から判断するので「可能性がある」にとどまることが多い |
| 相手への影響 | 監視装置がアラートを出したり、システムに負荷がかかったりすることがある | ほとんどない |
| 頻度 | 年1回や、大きな改修のときなど | 継続的（毎日〜毎週など） |
EASM で「見つける」、気になるものを脆弱性診断で「深く確かめる」と組み合わせるのが自然な使い方です。なお、製品によっては EASM の中に、承認したうえで確認用のリクエストを送る機能を持つものもあります（あとの「リスクを判断する」で説明します）。
EASM・ASM・CAASM のちがい
名前が似たものに CAASM（Cyber Asset Attack Surface Management）があります。EASM が外から見るのに対して、CAASM は EDR、AD（Active Directory）などの ID 管理、クラウドの管理画面、CMDB（構成管理データベース）など、社内ですでに使っている道具と API でつなぎ、資産の情報を集めて重複をまとめるものです（図6）。
| 呼び方 | 見る向き | 主な対象 | 主な情報源 |
|---|---|---|---|
| EASM（ASM） | 外（インターネット）から内へ | 公開しているドメイン、IP アドレス、Web サイト、VPN、API、クラウドのストレージなど | DNS、WHOIS などの登録情報、証明書（CT）、外からの走査 |
| CAASM | 社内のデータを集めて俯瞰 | 社内・社外の IT 資産、クラウドのアカウント、ID、端末 | EDR、AD、クラウドの管理、CMDB などとの API 連携 |
最近は、EASM、CAASM、脆弱性管理、攻撃経路の分析などを1つの基盤にまとめ、「エクスポージャー管理（Exposure Management：攻撃にさらされている状態をまとめて管理すること）」と呼ぶ製品が増えています。EASM がその中の1つの機能として提供されていることも多いです。
EASM で見つかるもの
EASM は、組織名やドメイン名を手がかりに、そこからつながる公開資産をたどって並べ、それぞれの気になる点を出していきます。イメージは図7のとおりです。
各社の資料に挙がっている検出の例を、よく見つかるものから並べると次のようになります。
| 見つかるもの | よくある例 | なぜ危ないか |
|---|---|---|
| 忘れられた Web サイト・開発環境 | 終わったキャンペーンサイト、テスト用のサブドメイン、古い CMS のまま残ったサイト | 更新されず、古い脆弱性が残りやすい。ログイン画面が公開されていることもある |
| リモート接続の入口 | 放置された VPN 機器、インターネットに開いた RDP（Windows のリモートデスクトップ）や SSH | パスワードの総当たりや、VPN 機器の脆弱性を突いた侵入の入口になりやすい |
| 想定していないポート・サービス | データベースやファイル共有（SMB）など、外に出すつもりのなかったサービス | 設定ミスで公開されたものは、認証が弱いままのことが多い |
| 公開設定のストレージ | 誰でも読める設定になったクラウドのストレージ | 中のファイルがそのまま漏れる |
| 証明書・ドメインの不備 | 期限切れや期限間近の証明書、古い TLS や弱い署名、更新を忘れたドメイン | 利用者への警告、通信の安全性の低下。手放したドメインを他人に取られることもある |
| 認証のない AI の API | 試しに立てた LLM（大規模言語モデル）の API、MCP サーバ | 誰でもツールを呼べたり、つながった先のデータが読めたりする |
「うちは台帳で管理しているから大丈夫」と考えている組織ほど、台帳の外にあるものに気づきにくいのが、EASM が必要とされる理由です。
各社の製品に共通するしくみ
調べた製品は、名前も画面の見せ方もそれぞれ違いますが、中で行っていることを並べてみると、図8の6つの層に整理できます。ここからは、この6つを順に見ていきます。
| 層 | 何をするか | 主な情報・機能 |
|---|---|---|
| ① 起点を決める | 探し始める手がかり（シード）を決める | ドメイン名、IP アドレスの範囲、ASN、組織名、WHOIS の登録者 |
| ② 集める | 手がかりからつながる情報を集める | DNS、WHOIS などの登録情報、証明書（CT・共有している証明書）、経路情報、外からの走査、Web ページの巡回、クラウドとの連携 |
| ③ 自社のものか見分ける | 見つかったものが自社やグループ会社のものかを判定する | つながりの証拠、確からしさ（信頼度）、人による確認 |
| ④ 台帳にする | 確かめた資産を一覧にして、状態と持ち主を管理する | 確認済み・候補・除外などの状態、部門や子会社のラベル |
| ⑤ リスクを判断する | 台帳の資産をくり返し調べ、気になる点に優先度を付ける | ポートとサービス、バージョン、証明書、ログイン画面、CVE、悪用の状況、資産の重要度 |
| ⑥ 確かめて直す | 直す人に届け、直ったかを確かめる | （製品により）無害な検証、チケット管理や SIEM との連携、再スキャン |
起点を決めて、つながりをたどる（①②）
多くの製品は、シード（起点）と呼ぶ手がかりから探し始めます。シードには、自社のドメイン名、IP アドレスの範囲、ASN（Autonomous System Number：インターネットの経路制御で組織のネットワークに付く番号）、組織名、WHOIS（ドメインの登録情報）の登録者などを使います。
EASM は、シードからつながる情報を何段もたどって、資産を広げていきます（図9）。たとえば、ドメインの証明書から別のサブドメインが見つかり、DNS の A レコード（名前から IP アドレスを引く記録）から IP アドレスが分かり、その IP アドレスが入っている範囲から別のホストが見つかる、という具合です。こうしたつながりを、グラフ（点と線の関係）として持っている製品が多いようです。
データの集め方にも違いがあります。自前でインターネット全体を定期的に走査し、どのアドレスでどんなサービスが動いているかを貯めておく製品もあれば、DNS や証明書の情報を中心に、登録した範囲を調べる製品もあります。クラウドの管理と API でつなぎ、クラウド上の資産を直接取り込める製品もあります。
利用者がシードを登録する形の製品と、組織名などから提供側（製品や調査チーム）が起点を用意して広げる形の製品があります。前者は調べる範囲を自分で決めやすく、後者は始めるまでの手間が少ない反面、見つかったものが本当に自社のものかを確かめる作業が増えます。新しく登録したシードが結果に出てくるまで、数日かかる製品もあります。
自社のものか見分けて、台帳にする（③④）
たどった先には、他社のものも混ざります。経済産業省のガイダンスも、CDN（コンテンツ配信ネットワーク）やクラウドでは IP アドレスが変わることがあり、DNS の状態によっては他社の資産が検出されることがあると注意しています。そこで各社の製品は、つながりの証拠や確からしさ（信頼度）を付け、確からしいものは自動で、迷うものは人が確認する形をとっています。
確かめた結果は、資産の状態として管理します（図10）。呼び方は製品で違いますが、「確認済み（台帳に入れる）」「候補」「要確認」「除外」のような分け方が多いです。SaaS や委託先のサービスのように、自社では直せないものを「依存先」として分けておける製品もあります。台帳に入れた資産には部門や持ち主のラベルを付けておき、あとの通知や修正の依頼に使います。
リスクを判断する（⑤⑥）
台帳に入れた資産は、くり返し調べます。確認済みの資産は毎日調べ直す製品が多いようです。ここでは、開いているポートとサービス、表示されるソフトウェアの名前とバージョン、証明書の期限や暗号の強さ、ログイン画面の有無などを集め、脆弱性の情報と照らし合わせます（図11）。
- ①〜③：EASM が確認済みの資産に、Web ページを開く、TLS でつなぐといったふつうのアクセスをし、画面、HTTP ヘッダ、証明書などの応答を受け取ります。
- ④：応答から、動いているソフトウェアとバージョンを推定します。
- ⑤〜⑦：脆弱性の情報（CVE、悪用が確認されたものの一覧、悪用される見込みなど）と照らし合わせ、当てはまりそうなものを「可能性あり」として記録します。
- ⑧〜⑪：製品によっては、担当者が許可した資産に限り、無害な確認用のリクエストを送って、本当に突けるかを判定します。
①〜⑦はふつうのアクセスで得た情報から判断するため、ガイダンスにもあるとおり、結果は「脆弱性がある可能性」です。バージョン表示を隠しているサーバや、修正だけを取り込んだサーバもあるので、ないのに出る（偽陽性）ことも、あるのに出ない（偽陰性）こともあります。
⑧〜⑪の検証は、ふつうのアクセスより一歩踏み込むので、製品側も事前の承認を前提にしています。使う前に、自社のものと確認できた資産だけを対象にすること、委託先やクラウド事業者の規約に触れないかを確かめておくことが大切です。ガイダンスも、他社が管理するシステムを調べる前には承認をとるよう勧めています。
製品によって違うところ
共通するしくみの上で、製品ごとに考え方が分かれているところもあります。図12の3つの軸で見ると整理しやすくなります。
| 軸 | 選ぶときに確かめたいこと |
|---|---|
| 起点の決め方 | 登録できるシードの種類と上限、反映されるまでの時間、子会社やブランドをどう扱うか |
| 製品の位置づけ | 今使っている EDR・脆弱性管理・SIEM などの基盤とつながるか、社内の資産や攻撃経路と合わせて見る必要があるか |
| 確かめ方 | 検証の機能があるか、既定で動くのか、止められるのか。調べる頻度と、調べるポートの範囲 |
使い始めてから回るまでの流れ
EASM は、ツールが資産を見つけるだけでは何も直りません。見つけたものを持ち主に届け、直してもらい、直ったかを確かめるところまでが1つの流れです。登場する人と道具を並べると、図13のようになります。
| 手順 | 誰が・どこで | 何をするか |
|---|---|---|
| ①〜② | セキュリティ担当 → EASM | シード（ドメイン、IP アドレスの範囲など）を登録する。EASM がつながりをたどって資産を集める |
| ③〜④ | EASM → セキュリティ担当 | 見つかった候補を確かめ、自社のものは承認、他社のものや誤検知は除外する |
| ⑤〜⑦ | EASM ⇔ 公開資産 | 確認済みの資産を定期的に調べ、新しい資産や設定の変化、リスクを見つけて優先度を付ける |
| ⑧ | EASM → セキュリティ担当 | 優先度の高いものから通知する |
| ⑨〜⑩ | セキュリティ担当 → チケット管理 → 持ち主 | 修正のチケットを起票し、期限を付けて持ち主に依頼する。EASM からチケットを自動で起票できる製品もある |
| ⑪〜⑫ | 資産の持ち主 | パッチの適用、設定の変更、使っていなければ停止する。終わったら完了を報告する |
| ⑬〜⑭ | EASM → 公開資産 | もう一度調べて（再スキャン）、本当に解消したかを確かめて記録する |
①〜④は最初に一度まとめて行い、⑤〜⑭はくり返します。新しく見つかった資産は、③〜④と同じように確かめてから台帳に入れます。
導入の進め方
導入は、次の4つの STEP で進めると整理しやすいです。いきなりグループ全体に広げず、小さく始めて、回るようになってから広げていきます。
範囲を決める（図13の①）
最初は、本社の主要なドメインと IP アドレスの範囲だけをシードにして始めます。グループ会社やブランド、海外拠点、買収した会社などは、運用が回り始めてから足していきます（図14）。
あわせて、検証の機能を使うかどうか、子会社や委託先が持つ資産をどう扱うか、見つかったときに誰に連絡するかも決めておきます。他社が管理しているシステムを調べるときは、事前に相手の承認をとるのがガイダンスの勧めです。
候補を確かめて台帳にする（図13の②〜④）
初めて動かすと、思った以上に多くの候補が出てきます。まず他社のもの、CDN、誤検知を除外し、自社のものだけを確認済みにします。そのうえで、使っていないもの、出すつもりのなかったものを洗い出します（図15）。
ここで迷うものを無理に判断する必要はありません。「要確認」にしておき、次の STEP で持ち主に聞きます。
持ち主を決める（図13の⑨〜⑩の前提）
EASM の運用でいちばん手間がかかるのが、見つかった資産の持ち主（アセットオーナー）を決める作業です。ガイダンスで紹介されている企業の事例でも、ツールで見つかった資産がどの部門のものかを特定するのが難しいという声が多く挙がっていました。DNS や証明書の申請記録、クラウドのアカウント、ページの内容、契約の記録などを手がかりにたどります（図16）。
どうしても分からないものは、セキュリティ担当がいったん預かり、期限を決めて止めるか残すかを判断します。持ち主が決まらないままの資産は、通知を出しても誰も直さないので、いつまでも残ってしまいます。
ふだんの流れにつなぐ（図13の⑤〜⑭）
最後に、EASM の結果をふだん使っている道具の流れに乗せます。修正の依頼はチケット管理に、ログとして見たいものは SIEM に、台帳は CMDB や CAASM と合わせます（図17）。EASM の画面を誰かが見に行かないと何も起きない、という形にしないのがポイントです。
どの道具とつなげられるか、どの情報が渡せるか（すべての資産か、確認済みの資産だけか）は製品によって違うので、導入前に確かめておきます。
入れたあとの運用
EASM は、入れて一度きれいにしたら終わり、というものではありません。新しいサイトやクラウドのサーバは毎日のように増え、新しい脆弱性も毎日公開されます。ここでは、役割分担、周期、優先順位の付け方を見ていきます。
役割分担：見つける人と直す人
多くの組織では、EASM の結果を見る人（社内の SOC や、運用を委託した MSSP などの運用者）と、実際に資産を直す人（情報システム部門、事業部、委託先などの持ち主）が別です。この間の受け渡しを決めておくことが、運用が回るかどうかを左右します（図18）。
| 担当 | 主な仕事 |
|---|---|
| 運用者（SOC・MSSP など） | 誤検知や他社のものを外す。悪用の状況などの情報を付けて判断する。影響と直し方を整理してチケットを起票する。直ったかをもう一度調べる |
| 資産の持ち主（IT・事業部・委託先） | 実機を調べる。パッチの適用、設定の変更、使っていないものの停止を行う。すぐに直せないときは、代わりの対策と期限を決めてリスク受容（リスクを分かったうえで受け入れること）を申請する |
どの周期で何をするか
やることを周期で分けておくと、毎日の確認が重くなりすぎません（図19）。下の表は一般的な例なので、組織の規模や体制に合わせて変えてください。
| 周期 | 主にやること | 主な担当 |
|---|---|---|
| 日次 | 新しく見つかった資産の確認、悪用が確認された脆弱性やゼロデイ（修正がまだない脆弱性）に当てはまるかの確認、優先度の高い通知の一次判断 | 運用者（SOC・CSIRT） |
| 週次 | 新しい資産の承認・除外、悪用の見込みが変わったものの確認、期限を過ぎたチケットの確認 | 運用者 ＋ IT 部門 |
| 月次 | 持ち主が分からない資産の追跡、直ったかの再確認、期限内に直せた割合や直るまでの日数の集計と報告 | セキュリティの責任者 |
| 四半期・年次 | シードの見直し（新しいドメイン、買収した会社など）、運用ルールの見直し | CISO・セキュリティ部門長 |
参考までに、米国では CISA（米国のサイバーセキュリティ・インフラストラクチャセキュリティ庁）が2022年に出した拘束力のある運用指令 BOD 23-01 で、連邦政府機関に対し、資産の自動での洗い出しを7日ごと、見つかった資産の脆弱性の洗い出しを14日ごとに行うよう求めています。民間企業に向けた決まりではありませんが、周期を考えるときの目安になります。
優先順位の付け方
EASM を動かすと、通知はかなりの数になります。CVSS（共通脆弱性評価システム：脆弱性の深刻度を 0.0〜10.0 で表す指標）の点数だけで並べると、全部が急ぎに見えてしまいます。そこで、次の3つを組み合わせて絞り込む考え方がよく使われます。
- 外から直接届くか：EASM が見つけた資産は、もともと外から見えているものですが、ログイン画面の奥にしかない機能などは別に考えます。
- 悪用が確認されているか：CISA の KEV カタログ（Known Exploited Vulnerabilities：実際に悪用が確認された脆弱性の一覧）に載っているか。CISA も、KEV を優先順位の判断の材料にするよう呼びかけています。
- 悪用されやすいか：FIRST の EPSS（Exploit Prediction Scoring System：今後30日以内に悪用される見込みを 0〜1 の確率で毎日出す指標）と、CVSS の深刻度。
これを判断の順番にすると、図20のようになります。
| 優先度 | 当てはまるもの | 期限の例 |
|---|---|---|
| P1 緊急 | 外から直接届き、KEV に載っている（悪用が確認されている） | 数日以内（24〜72時間など） |
| P2 優先 | 外から直接届き、EPSS が高い、または CVSS で「重大」（9.0 以上） | 1週間程度 |
| P3 計画 | 悪用の見込みが低いもの、軽い設定の不備 | 1〜3か月 |
| P4 受容 | WAF などの代わりの対策があり、期限付きで受け入れを承認したもの | 期限と理由を記録し、見張りを続ける |
期限は、組織のルールとして決めるものです。表の数字は考え方の例として見てください。P4 の代わりの対策としては、仮想パッチも選択肢になります。
つまずきやすい点
| つまずき | 何が起きるか | 対策 |
|---|---|---|
| 最初から全部を対象にする | 候補が多すぎて確認が終わらず、運用が始まらない | 本社の主要なドメインから始め、回り始めてから広げる |
| 結果をそのまま信じる | 他社の資産や、バージョンの見誤りによる誤検知に振り回される | 確からしさの低いものは人が確かめる。気になるものは脆弱性診断で深く確かめる |
| 持ち主を決めない | 通知は出るが誰も直さない | 台帳に入れるときに持ち主を決める。不明なものは期限付きで預かる |
| 深刻度だけで並べる | 通知が多すぎて、本当に急ぐものが埋もれる | 外から届くか、KEV、EPSS を組み合わせて絞る |
| 検証の機能を確かめずに使う | 委託先やクラウド事業者の規約に触れる、相手のシステムに負荷をかける | 自社のものと確認できた資産に限り、承認をとってから使う |
| 入れて終わりにする | 新しい資産が増え、すぐに元の状態に戻る | 周期ごとの作業を決め、シードを定期的に見直す |
CTEM との関係
最近は、EASM を含む考え方として CTEM（Continuous Threat Exposure Management：継続的な脅威エクスポージャー管理）という言葉もよく聞きます。Gartner が提唱した、範囲を決める（Scoping）、発見（Discovery）、優先順位付け（Prioritization）、検証（Validation）、動員（Mobilization：関係する人を動かして直すこと）の5段階をくり返す取り組みです。EASM は、この輪の中で主に「発見」を受け持ち、製品によっては優先順位付けや検証の一部まで受け持ちます（図21）。
CTEM は製品の名前ではなく、取り組み方の名前です。EASM を入れただけで CTEM になるわけではなく、範囲の決め方や、直す人を動かす仕組みまで含めて回すことが求められます。
まとめ
EASM は、外から見える自社の資産を攻撃者と同じ外側から見つけ、リスクを継続的に確かめていくための取り組みです。この記事の内容を表にまとめます。
| ポイント | 内容 |
|---|---|
| なぜ必要か | 入口が社内の境界の外に散らばり、攻撃者は CT ログなどの公開情報から入口を探しに来る。台帳にない資産ほど狙われやすい |
| EASM とは | インターネットから見える自社の資産を外から見つけ、リスクを継続的に確かめる。脆弱性診断は深く、EASM は広く。CAASM は社内の道具のデータから集める |
| 共通するしくみ | 起点を決める → 集める → 自社のものか見分ける → 台帳にする → リスクを判断する → 確かめて直す、の6つの層 |
| 製品による違い | 起点の決め方（シードを登録する／組織名から広げる）、位置づけ（単体／基盤の一部）、確かめ方（ふつうのアクセスで推定／承認のうえ検証） |
| 導入 | 本社の主要なドメインから小さく始め、候補を確かめ、持ち主を決め、ふだんの道具につなぐ |
| 運用 | 見つける人と直す人の受け渡しを決める。周期ごとの作業を決める。外から届くか・KEV・EPSS で優先順位を絞る |
まずは、自社のドメインと IP アドレスの範囲を一覧にして、「外から自社がどう見えているか」を知るところから始めるのがよいと思います。
参考にした資料
この記事は、次の資料で内容を確かめて書きました。製品の公開資料は、しくみを一般化するために読み比べたもので、記事の本文は特定の製品の説明ではありません。仕様や名称、提供状況は変わることがあるので、最新の情報はリンク先とメーカーへの問い合わせで確かめてください。
- ASM (Attack Surface Management) 導入ガイダンス（経済産業省）：ASM の定義、発見・情報収集・リスク評価の流れ、脆弱性診断との違い、他社の資産の検出や持ち主の特定などの留意点
- RFC 9162: Certificate Transparency Version 2.0（IETF）：証明書透過性のしくみ
- The Rise of Certificate Transparency and Its Implications on the Internet Ecosystem（arXiv）：CT ログの情報が、証明書の発行から数分後のスキャンに使われていたという調査
- The risk hiding behind exposed MCP servers（Wiz）：インターネットに公開された MCP サーバの割合と、認証のない相手にツールの一覧を返す割合
- Binding Operational Directive 23-01 – Improving Asset Visibility and Vulnerability Detection on Federal Networks（CISA）：資産の洗い出しを7日ごと、脆弱性の洗い出しを14日ごとに求める指令
- Reducing the Significant Risk of Known Exploited Vulnerabilities（CISA）：KEV カタログの位置づけと、優先順位の判断への使い方
- Exploit Prediction Scoring System (EPSS)（FIRST）：今後30日以内に悪用される見込みを確率で示す指標
- Common Vulnerability Scoring System version 4.0: Specification Document（FIRST）：CVSS のスコアの範囲と、深刻度の区分（9.0〜10.0 が Critical）
- What is Attack Surface Management?・What Is Continuous Threat Exposure Management (CTEM)?（IBM）：ASM の考え方、CTEM の5つの段階
- The Main Components of an Attack Surface Management (ASM) Strategy（Rapid7）：EASM と CAASM の情報の集め方の違い
- Continuous Black-box Asset Discovery・Continuous Security Validation（CyCognito）：組織名から始める探索、つながりのグラフ、安全性を確かめたうえでのテスト
- Secure Your External Attack Surface | CrowdStrike EASM（CrowdStrike）：インターネット全体を継続的に調べて公開資産を見つける方式、エクスポージャー管理の一部としての提供
- Seed Management（トレンドマイクロ）：シードの種類と、反映までの時間
- What is discovery?・External attack surface management initiative（Microsoft Learn）：シードからの再帰的な探索、確からしさによる資産の状態の分け方、エクスポージャー管理との連携
- Asset Attribution・Attack Surface Testing（Palo Alto Networks）：提供側が用意する起点と、機械学習と人による帰属の判断、承認したうえでの無害な検証
- Tenable One Attack Surface Management（Tenable）・Seed Your Attack Surface（Censys）・External Attack Surface Management (EASM)（Qualys）：インターネットの地図を持つ方式、シードの種類、確からしさの区分
- NRIセキュア、セキュリティ担当者に“やさしい”ASMソリューション「ASMimosa」を提供（クラウド Watch）・ホワイトハッカーのノウハウを活用した新機能『ドメイン棚卸』をリリース（GMOサイバーセキュリティ by イエラエ）：国内のサービスの探索の考え方と、関係のない資産が混ざる場合があるという注意
あとがき
各社の資料を並べて読んでみると、資産を見つける部分の作りはかなり違うのに、最後に効いてくるのは「誰が直すのか」を決める地味な作業だと感じました。ガイダンスの事例で、見つかった資産の持ち主の特定に苦労したという声が多かったのも、うなずけます。製品を比べる前に、自社のドメインと IP アドレスの範囲を一覧にしてみるだけでも、気づくことがあると思います。
コメント