ASM (Attack Surface Management) #

ASM (Attack Surface Management、攻撃対象領域管理) は 「攻撃者から見えている自組織の入口 (= attack surface) を継続的に発見し、棚卸しし、優先度をつけて潰す」 ことを目的にしたセキュリティ分野。「外部から自社を観たときに何が見えているか」を、攻撃者より先に自分で把握するという発想が中核にある。

ASM が独立した分野・市場として確立したのは 2018-2020 年頃 とごく最近で、それまでは脆弱性管理 (Vulnerability Management) や資産管理 (IT Asset Management) の一部として扱われていた。クラウド・SaaS・M&A・シャドー IT・リモートワークの普及で、企業が 「自分が持っている資産すら把握できない」 状況が常態化したことが、独立した分野が必要になった直接の理由。「知らない資産は守れない (You can't protect what you don't know exists)」 という現場感覚が業界共通の標語になっている。

本稿は 「ASM とは何か」「なぜいま独立した分野として必要なのか」 を軸に、Attack Surface の定義 / EASM・CAASM・DRPS の 3 分類 / 発見の技法 (SVG 1) / 3 つの層の住み分け (SVG 2) / ASM ライフサイクル / 代表事件 / 主要ベンダー / 現場の落とし穴 を整理する。「侵入された後の対応」ではなく「侵入される前の地形把握」 という、ランサムウェアや Trojan の記事とは違う角度の話。

1. Attack Surface とは何か — 定義と区分 #

Attack Surface (攻撃対象領域) は 「攻撃者が組織に対して何らかの操作を試みられるすべての地点 (入口) の集合」。教科書的には NIST が「攻撃者がシステムへ侵入を試みたりデータを抽出したりするのに使える経路の集合」と定義している。実務的には次の区分で整理されることが多い:

ASM が特に重視するのは「External × Unknown × Digital」のセル — インターネットから攻撃者が見ているが、自分は持っていることすら把握していない資産。Capital One (2019) / MOVEit (2023) / Snowflake (2024) など近年の大規模事件の多くは、まさにこのセルに属する資産が起点になっている。

「Attack Surface はサイズで測るものではない」点も重要。サーバ 1 万台より 1 つの忘れられた管理画面の方が攻撃対象として致命的になりうる。量より「どこに何があり、何が攻撃者から見えているか」という地形把握が ASM の本質。

2. なぜ ASM が独立分野として登場したのか #

ASM が「Vulnerability Management の一部」から独立した分野になった背景には、2010 年代後半から 2020 年代にかけて、企業の Attack Surface が構造的に変質したという事実がある。

(1) クラウドと SaaS の爆発: オンプレ時代は 「会社の IP レンジ = 攻撃対象領域」 とほぼ等号で結べた。AWS / Azure / GCP のアカウントは数十〜数百個に分散し、SaaS テナント (Salesforce / Workday / Slack / Notion / Snowflake) はマーケが勝手に契約する。ネットワーク境界が消え、「自社の IP レンジ」という概念自体が成立しなくなった。

(2) M&A: 大企業の Attack Surface の 30-50% は買収した子会社のものになることが多い。買収側は子会社のすべての資産を即座には棚卸しできないため、未知の入口が一気に増える。Marriott が 2018 年に開示した 5 億件流出事件は、買収した Starwood の予約システム が侵害源で、買収時に既に侵害されていたことが後に判明した。

(3) シャドー IT: 部署が CISO の承認なく AWS アカウントを開き、PoC を立て、放置する。ドメイン担当者が退職して、登録更新だけ続いている古いサブドメインが会社の名前で生き続ける。「誰が立てたか分からないが、確かに自社の名前で動いている」資産が常に発生し続けている。

(4) リモートワーク: COVID-19 (2020) 以降、社内サーバを VPN 経由で公開したり、従業員宅の機器が業務に組み込まれるようになった。境界型防御が前提にしていた「内 / 外の区別」が物理的に崩壊した。

(5) 攻撃者の経済構造の変化: Initial Access Broker (IAB) が 「侵入できる足場」を商品として売る市場が成熟し、Shodan / Censys で発見した脆弱資産を即座に他のグループが買って攻撃する流通が確立した。「Attack Surface に新たな穴を開けた瞬間にスキャンが始まる」 — Shodan の統計では 新しい公開 IP が立つと中央値で 30 分以内に最初のスキャンが届く。

これらが組み合わさった結果、「自社の Attack Surface を完全に把握している企業はもはや存在しない」という前提に立つしかなくなった。ASM はこの前提から逆算した分野である — 「完全な棚卸し」は諦め、「攻撃者と同じ視点で外から見続けて差分を検知する」 という発想に切り替えた。

3. EASM / CAASM / DRPS — 3 つのサブ分野 #

ASM は実は単一分野ではなく、3 つの近接した市場が ASM の傘の下に並んでいる:

3 つの違いを一言で:

• EASM は 「自社のフットプリントを外から見る」 — 攻撃者と同じ視点でインターネットからスキャン。未知の公開資産発見が主目的
• CAASM は 「持っているデータを統合する」 — 既存のセキュリティ・IT ツールの API を集めて統合インベントリを構築。「EDR 未導入の端末を抽出」のような横断クエリができる
• DRPS は 「組織にまつわる外部の脅威を観る」 — ダークウェブ / フィッシングドメイン / SNS なりすまし / リーク掲示板。自社の資産ではないが組織に関連する脅威を扱う

2024 年以降は Gartner が提唱した CTEM (Continuous Threat Exposure Management) のフレームワーク下に ASM 全体を再配置する動きが進んでいる。「発見」から「優先度付け」「検証 (= ペンテスト)」「動員 (= 対応)」までを 1 サイクルに統合するアプローチ。

4. 発見の技法 — シードからどう Attack Surface が広がるか #

EASM が「ドメイン 1 個 (= seed) だけ与えられて、企業全体の Attack Surface を発見する」のはどうやっているのか。攻撃者のレコン技法をスケールさせて自動化したもので、複数の情報源をピボット (pivoting) で連鎖させていく:

ここで決定的に重要なのが ⑤ の帰属判定 (Attribution) — 「本当にその資産は対象組織のものか」 を確度付きで判定すること。間違って他社の資産を「これはあなたの会社のものです」と報告してしまうと、ASM の信頼性が崩れる。EASM ベンダーが差を出すのは 発見の網羅性ではなく帰属の精度 という側面が強い。

よく使われる帰属シグナル:

• favicon hash (MurmurHash3): 同じファビコン画像を返すサイト群 → 同じ組織のテンプレート由来の蓋然性
• JARM (TLS フィンガープリント): 同じ TLS スタック設定 → 同一インフラ上の蓋然性
• 証明書 SAN (Subject Alternative Name): 1 枚のワイルドカード証明書に並ぶドメイン群 → 確度高
• HTML テンプレート類似: 同じ社内ベース HTML を使っているサイト群
• WHOIS / RDAP 連絡先: 連絡先メール・組織名で逆引き (ただし WHOIS プライバシで匿名化されていることが多い)
• DNS NS 共通: 同じ権威 DNS サーバを使っているサイト群

Censys / Shodan / SecurityTrails / DomainTools といった データ提供基盤 がこの土台。EASM ベンダー自身もスキャンするが、業界の事実上のスキャンインフラは Shodan / Censys が握っている — 多くの EASM ツールが裏で API を叩いている。

5. ASM ライフサイクル — 「発見だけ」では終わらせない #

ASM が機能するための運用サイクルは 「Discover → Inventory → Classify → Prioritize → Remediate → 継続」 の 5 + 1 段。多くの ASM 導入失敗の原因は 「① Discover で止まる」 こと — 見つけただけのリストを CISO に渡しても誰も動けない。

「持ち主が分からない資産」 は ASM 運用で最大の壁になる。ドメイン担当者が退職 / 部署が解散 / M&A で組織が変わった などで、「会社のものではあるが誰の管理下にあるか分からない」資産が出る。「とりあえず塞ぐ」と業務影響が出て怒鳴られ、「塞がない」と侵害される というジレンマで止まる。

KEV (CISA Known Exploited Vulnerabilities) カタログ を 優先度の上位条件にするのが現代の標準。「攻撃者が現実に悪用している脆弱性」 は CVSS スコアにかかわらず最優先。CISA BOD 22-01 (2021) で米連邦機関は KEV カタログ掲載脆弱性を期限内に修正する義務を負う。民間でも KEV を SLA の基準にする組織が増えている。

6. 攻撃者視点との関係 — ASM ≒ Defender 側の Recon #

ASM が使う技法は 攻撃者の Reconnaissance (偵察) フェーズ とほぼ同じ。MITRE ATT&CK の TA0043 (Reconnaissance) のサブ技法 — Gather Victim Network Information / Search Open Websites / Search Open Technical Databases — はそのまま EASM の動作にあたる。

違いは「誰がやるか」「結果を何に使うか」だけ:

Bug bounty / Pentest との関係: Bug bounty hunter は外部の ASM 部隊として機能する。HackerOne / Bugcrowd の登録範囲 (scope) に「全 ASM 範囲内」のような書き方をする企業が増えており、ハンターが発見した未知資産の脆弱性が報告されることで、組織自身の ASM の穴が埋まる。Defender が ASM ベンダーを買い、追加でハンターを雇うという構図。

Pentest との違い: Pentest は「与えられた範囲を深く掘る」 のに対し、ASM は「範囲そのものを決める」 — つまり ASM の出力が次のペンテストの入力になる関係。Pentest を依頼するときに 「うちのスコープって何でしたっけ?」がそもそも答えられないというのが多くの企業の現実で、ASM はその前提を埋める。

7. 代表事件 — ASM が機能していれば防げた / 早く気づけたもの #

共通するパターン: 「公開されていることに本人が気づいていない / パッチ責任者がいない / SaaS は対象外と思っている」資産が起点。Attack Surface に新しい穴が開いた瞬間に攻撃者の自動化スキャンが見つけるため、気づくスピード勝負になっている。Shodan の「タダで観測できるデータ」 を攻撃者と防御者が同じ速度で見ているのが現代。

8. 主要ベンダーとツール — 商用と OSS #

ASM 関連の市場は急成長中で、Gartner Magic Quadrant にも 2022 年から EASM が独立カテゴリとして登場している。

商用 EASM:

• Cortex Xpanse (Palo Alto Networks、旧 Expanse) — 業界の先駆者 (2012-)、米国防総省などが採用
• Microsoft Defender EASM (旧 RiskIQ、2021 買収) — Microsoft 365 / Defender エコシステムと統合
• CrowdStrike Falcon Surface (旧 Reposify、2023 買収)
• Censys ASM — Censys のスキャン基盤を活かした EASM プラットフォーム
• Mandiant Advantage Attack Surface Management (Google Cloud)
• Tenable Attack Surface Management — 脆弱性管理ベンダーが ASM 領域へ拡張
• Qualys CyberSecurity Asset Management (CSAM) + EASM
• IONIX (旧 Cyberpion) — サプライチェーン側の Attack Surface に強み

商用 CAASM:

• Axonius — CAASM の代名詞的存在 (400+ コネクタ)
• JupiterOne — グラフ DB で資産関係を表現 (Drata に買収、2024)
• runZero — エージェントレスなアクティブスキャンも組み合わせる
• Sevco / Lansweeper / Panaseer

商用 DRPS:

• Recorded Future — 統合的なインテリジェンス + DRPS
• ZeroFox — SNS / ブランド成りすまし
• Flashpoint / Cyberint / Intel 471 — ダークウェブ寄り

OSS / 攻撃者ツールでもある OSS (Bug bounty / Pentest で日常的に使われる):

OSS の組み合わせで EASM 相当の機能は組める — Shodan + amass + nuclei で「自社の公開資産 + そこにある KEV 脆弱性」までは無料で観測可能。商用ベンダーが提供しているのは継続実行 + ダッシュボード + 帰属精度 + チケット連携であり、技術的なコアは OSS にも揃っている。

# 最小限の OSS ASM パイプライン例 (Bug bounty でも使われる)
echo "example.com" | subfinder -silent | dnsx -silent | httpx -silent -title -tech-detect | nuclei -t cves/

# 自社の Shodan 観測
shodan search "org:\"Example Corp\""

# Censys で証明書から関連ドメインを発見
censys search "names: *.example.com"

9. 落とし穴と限界 — 「発見しただけで終わる」を回避する #

ASM の現場では次の落とし穴が繰り返し報告される:

• 帰属の誤検知: 「これはあなたの資産」と報告されたものが実は他社 (例えば AWS 上の同 IP に乗っている別組織)。「持ち主証明」を求めずに塞ぐと業務影響 が出る。EASM ベンダーの帰属信頼度 (confidence score) を見て、low confidence は人間がレビューする運用が必須
• チケット詰まり: 大量の脆弱性チケットが所有者不明で滞留する。「所有者を決定するワークフロー」を ASM 導入前に整えるべき (組織図 / CMDB / 連絡ルート)
• 「全部 High 優先度」問題: CVSS だけで並べると High が数千件 になり優先度が機能しない。KEV カタログ + 公開度 + ビジネス重要度 の 3 軸で実行可能な順位にする
• SaaS が対象外になりがち: 「自社のドメインで動いていないから」と SaaS テナントを ASM から外す と、Snowflake 事件のような MFA 漏れが残る。CAASM 側で SaaS API を統合するのが現代の解
• クラウドのエフェメラル資産: コンテナ・サーバレス・スポットインスタンスのように 数時間で消える資産は ASM のスナップショットでは追えない。クラウド構成管理 (CSPM / CNAPP) と組み合わせる 必要がある
• M&A 子会社の盲点: 買収側の Active Directory に統合される前の子会社は ASM スコープに入りにくい。Marriott / Starwood の失敗を繰り返さない ためには 買収時点で seed を追加する プロセス
• 「発見」と「ペンテスト」のギャップ: ASM が 「ある」 こと は発見しても、実際に侵入できるかは別問題。CTEM (Continuous Threat Exposure Management) が**「発見後の検証 (validation)」を 1 サイクルに含める**のはこのギャップを埋めるため
• 検知ノイズと SOC 疲労: DRPS 由来のフィッシングドメインアラートは日に数百件になることがあり、SOC が捌けない。「自動でテイクダウン申請」「明らかなノイズはフィルタ」 の自動化が前提

ASM は 「自社の Attack Surface は完全には把握できない」という前提から逆算した分野で、クラウド・SaaS・M&A・シャドー IT で構造的に未知資産が増え続ける 2020 年代の企業環境に対する答えとして 2018-2020 年に独立した市場として確立した。

EASM (外から見る) / CAASM (内外の API を統合) / DRPS (組織を取り巻く脅威環境) の 3 つが ASM の傘の下に並び、2024 年以降は CTEM (Continuous Threat Exposure Management) のフレームワークの中で発見 → 優先度付け → 検証 → 動員まで統合される方向に動いている。

技術的には 攻撃者の Recon と全く同じ手法 — Certificate Transparency / Passive DNS / Shodan / Censys / favicon hash / JARM をスケールさせて自動化したもの — を 「先に自分で」やるのが本質。商用ベンダーが提供しているのは継続性 + 帰属精度 + チケット連携 + ダッシュボードであり、OSS の組み合わせでも基本機能は実現可能。

ASM が機能するかどうかは「発見の後の運用」で決まる: 持ち主が決まり、優先度が KEV を含めて並べられ、チケットがクローズされ、再発がスキャンで検知される — このサイクルが回らないと「見つかったリスト」だけが積み上がる。Equifax / Capital One / ProxyLogon / MOVEit / Snowflake といった事件はすべて、サイクルのどこかが切れていたことの結果である。