ASM (Attack Surface Management) は「攻撃者から見えている自組織の入口を継続的に発見し、棚卸しし、優先度をつけて潰す」セキュリティ分野。クラウド・SaaS・M&A・シャドー IT・リモートワークで 「自分が持っている資産すら把握できない」 状況が常態化した 2018-2020 年頃に独立した市場として確立した。本稿は EASM / CAASM / DRPS という 3 つのサブ分野の住み分け、発見技法、運用サイクル、代表事件、主要ベンダー、現場の落とし穴を一通り扱う。
難しく見えても本質は次の 3 つだけ。(1) ASM は 「攻撃者と同じ目線で、自社の入口 (Attack Surface) を見続ける」セキュリティ分野。(2) 一番危ないのは 「会社のものなのに、自分でも把握していない資産」 — 退職した担当者の AWS アカウント、買収子会社の古いサーバ、開発で立てて放置したテスト環境。(3) 攻撃者は 新しく公開された IP を平均 30 分以内にスキャンしている — だから自社の Attack Surface を 継続的に観察し、新しい穴に最短で気付くのが ASM の本質。— ここを土台に各章を順に開いていけばいい。
Attack Surface とは何か #
Attack Surface (攻撃対象領域) は 「攻撃者が組織に対して何らかの操作を試みられるすべての地点 (入口) の集合」。NIST は「攻撃者がシステムへ侵入を試みたりデータを抽出したりするのに使える経路の集合」と定義する。実務では次の 3 軸で整理する。
家を泥棒視点で見ると、玄関 / 勝手口 / 窓 / 換気扇 / 屋根の隙間 / 鍵を隠してある植木鉢の下などすべてが「入口」になりうる。Attack Surface はこれの会社版で、(外部) Web / VPN / メールサーバ / 公開 API、(内部) 社内サーバ / AD / 業務 PC がすべて入る。一番危ないのは「自分でも入口があると気付いていない場所」 — 玄関の鍵には目を配っても、勝手口の鍵を閉め忘れているのが事故の典型パターン。「Capital One / MOVEit / Snowflake」のような大事件は、ほぼこのパターン。
| 軸 | 区分 | 例 |
|---|---|---|
| 見え方 | External (外部) | Web / API / VPN / メールゲートウェイ / 公開 S3 |
| Internal (内部) | AD / 業務サーバ / 端末 / 印刷機 / IoT | |
| 把握状況 | Known (既知) | CMDB / Inventory に載っている資産 |
| Unknown (未知) ★ | シャドー IT / 旧プロジェクト残骸 / M&A 子会社 | |
| 媒体 | Digital / Physical / Human | サーバ・建物・従業員 |
インターネットから攻撃者には見えているが、自分は持っていることすら把握していない 資産。Capital One (2019) / MOVEit (2023) / Snowflake (2024) など大規模事件の多くはこのセルから発生している。
「Attack Surface はサイズで測るものではない」点も重要。サーバ 1 万台より 1 つの忘れられた管理画面の方が致命的になりうる。量より「どこに何があり、何が見えているか」という地形把握が ASM の本質。
なぜ独立分野として登場したのか #
ASM が「Vulnerability Management の一部」から独立した分野になった背景には、2010 年代後半から 2020 年代にかけて企業の Attack Surface が構造的に変質した事実がある。
- クラウドと SaaS の爆発 — オンプレ時代は「会社の IP レンジ = 攻撃対象領域」だったが、AWS / Azure / GCP のアカウントは数百個に分散し、SaaS テナント (Salesforce / Workday / Slack / Snowflake) はマーケが勝手に契約する。「自社の IP レンジ」という概念自体が成立しなくなった。
- M&A — 大企業の Attack Surface の 30-50% は買収子会社のもの。Marriott の 5 億件流出 (2018) は買収した Starwood の予約システムが侵害源で、買収時点で既に侵害されていた。
- シャドー IT — 部署が CISO の承認なく AWS アカウントを開き、PoC を立て、放置する。ドメイン担当者が退職して登録更新だけ続いている古いサブドメインが残り続ける。
- リモートワーク — COVID-19 以降、社内サーバを VPN 経由で公開したり、従業員宅の機器が業務に組み込まれる。境界型防御の前提が崩壊した。
- 攻撃者の経済構造 — Initial Access Broker (IAB) が「侵入できる足場」を商品として売る市場が成熟。Shodan では新規公開 IP に中央値 30 分以内に最初のスキャンが届く。
「自社の Attack Surface を完全に把握している企業はもはや存在しない」という前提から逆算した分野が ASM。完全な棚卸しは諦め、攻撃者と同じ視点で外から見続けて差分を検知する発想に切り替えた。
EASM / CAASM / DRPS — 3 つのサブ分野 #
ASM は単一分野ではなく、3 つの近接した市場が ASM の傘の下に並んでいる。
名前が略語で並ぶと頭が痛くなるが、「どこを見ているか」で分けるとシンプル。EASM = 「外 (インターネット) から自社を見る」 — 攻撃者と同じ視点、これが ASM の本命。CAASM = 「内側の各ツールの情報を統合する」 — AD / EDR / クラウドの API を全部繋いで「EDR が入っていない PC はどれ?」のような横断クエリを可能にする。DRPS = 「自社の外で起きていることを見る」 — ダークウェブで自社の漏洩クレデンシャルが売られていないか、SNS で偽アカウントが立てられていないか。迷ったらまず EASM、と覚えればよい。
| EASM | CAASM | DRPS | |
|---|---|---|---|
| 正式名 | External ASM | Cyber Asset ASM | Digital Risk Protection Services |
| 視点 | 外部 (インターネット) から観察 | 内部 + 外部の API 集約 | 組織を取り巻く外部脅威 |
| 主な入力 | 会社名 / seed domain 1 つ | AWS / AD / EDR / SaaS API | ダークウェブ / SNS / リーク掲示板 |
| 主な出力 | 未知の公開資産リスト | 統合資産インベントリ | 漏洩クレデンシャル / なりすまし |
| 強み | エージェント不要、M&A 直後でも発見可 | カバレッジギャップ可視化 | 自社の資産でない脅威も検知 |
| 代表ベンダー | Cortex Xpanse / Defender EASM / Censys ASM / Mandiant | Axonius / JupiterOne / runZero | Recorded Future / ZeroFox / Flashpoint |
- EASM は 「自社のフットプリントを外から見る」 — 攻撃者と同じ視点でインターネットからスキャンし、未知の公開資産発見が主目的
- CAASM は 「持っているデータを統合する」 — 既存ツールの API を集めて統合インベントリを構築。「EDR 未導入の端末を抽出」のような横断クエリができる
- DRPS は 「組織にまつわる外部の脅威を観る」 — 自社の資産ではないが組織に関連する脅威 (フィッシングドメイン / 漏洩クレデンシャル / SNS なりすまし) を扱う
2024 年以降は Gartner 提唱の CTEM (Continuous Threat Exposure Management) のフレームワーク下に ASM 全体を再配置する動きが進む。発見 → 優先度付け → 検証 (= ペンテスト) → 動員 (= 対応) までを 1 サイクルに統合するアプローチ。
発見の技法 — seed から芋づる式に広がる #
EASM が「ドメイン 1 個 (seed) だけ与えられて、企業全体の Attack Surface を発見する」のはどうやっているのか。攻撃者のレコン技法をスケールさせて自動化したもので、複数の情報源を pivoting で連鎖させていく。
会社名 1 個 (= 種) から始まり、「あの会社の電話番号で登録された他のドメインは?」「同じファビコンを使うサイトは?」「Let's Encrypt の公開証明書ログに名前が載っているサーバは?」と探偵のように聞き込みで枝を広げていく。これらの情報源は すべてインターネット上に公開されているので、攻撃者も全く同じ手順で観察できる — だから防御側も 「先に同じことを自分でやる」のが ASM の発想。「攻撃者が一晩で組み立てる地図を、防御側が継続的に組み立て直す」競争、と捉えると分かりやすい。
example.com → example.co.jp / example-corp.com / 買収企業の旧ドメインへ拡張。dev.example.com / staging-2019.example.com / vpn-test.example.com を抽出。結果として数千〜数万の資産マップが得られる — その大半は「持っていることすら把握していなかった」古い管理画面 / 開発環境 / 買収前残骸 / シャドー IT クラウド。
よく使われる帰属シグナル #
- favicon hash (MurmurHash3) — 同じファビコン画像を返すサイト群 = 同組織のテンプレート由来の蓋然性
- JARM (TLS フィンガープリント) — 同じ TLS スタック設定 = 同一インフラ上の蓋然性
- 証明書 SAN — 1 枚のワイルドカード証明書に並ぶドメイン群 (確度高)
- HTML テンプレート類似 — 同じ社内ベース HTML を使うサイト群
- WHOIS / RDAP 連絡先 — 連絡先メール・組織名で逆引き (WHOIS プライバシで匿名化されがち)
- DNS NS 共通 — 同じ権威 DNS サーバを使うサイト群
EASM ベンダー自身もスキャンするが、多くの EASM ツールが裏で Censys / Shodan / SecurityTrails / DomainTools の API を叩いている。
ASM ライフサイクル #
ASM が機能するための運用サイクルは Discover → Inventory → Classify → Prioritize → Remediate → 継続 の 5+1 段。多くの ASM 導入失敗の原因は 「Discover で止まる」 こと — 見つけただけのリストを CISO に渡しても誰も動けない。
多くの企業が ASM ツールを買って 「見つかった脆弱性リストが出てきた、でも誰が直すか分からないので放置」という詰みパターンに陥る。ASM の本当の価値は「発見」ではなく「発見 → 担当者 → 修正 → 確認」のサイクルを回し切ること。発見した資産には必ず 「持ち主」を割り当てる。割り当てられないものは「持ち主不明」という所有者を一旦作り、ベテランが定期レビューする。「とにかく見つけた」で終わらせないのが、ASM 導入を成功させる唯一の鍵。
| 段階 | 内容 | よくある失敗 |
|---|---|---|
| ① Discover | seed → 拡張で資産を発見 | ベンダーを買って満足 |
| ② Inventory | CMDB / 統合インベントリに登録 (CAASM 領域) | EASM と CMDB が同期しない |
| ③ Classify | どの事業部 / 部署 / 責任者の資産かを特定 | 「持ち主が分からない」資産が残る |
| ④ Prioritize | 脆弱性 + 公開度 + ビジネス重要度 + KEV で並べる | CVSS だけで並べて KEV を無視 |
| ⑤ Remediate | 持ち主にチケット発行 → 修正 → 確認 | チケットが滞留してクローズしない |
| ⑥ Continuous | 新規資産が増える前提で観測サイクルを回す | 1 回スキャンして終了 |
ドメイン担当者が退職、部署が解散、M&A で組織が変わったなどで、「会社のものではあるが誰の管理下にあるか分からない」資産が出る。「とりあえず塞ぐ」と業務影響で怒鳴られ、「塞がない」と侵害されるジレンマで止まる。
KEV カタログを優先度の上位条件にする #
KEV (CISA Known Exploited Vulnerabilities) カタログを優先度の上位条件にするのが現代の標準。「攻撃者が現実に悪用している脆弱性」は CVSS スコアにかかわらず最優先。CISA BOD 22-01 (2021) で米連邦機関は KEV カタログ掲載脆弱性を期限内に修正する義務を負う。民間でも KEV を SLA 基準にする組織が増えている。
攻撃者視点との関係 — ASM ≒ Defender 側の Recon #
ASM が使う技法は 攻撃者の Reconnaissance フェーズ とほぼ同じ。MITRE ATT&CK の TA0043 (Reconnaissance) のサブ技法 — Gather Victim Network Information / Search Open Websites / Search Open Technical Databases — はそのまま EASM の動作にあたる。
| 攻撃者の Recon | EASM (Defender) | |
|---|---|---|
| 手法 | Shodan / Censys / amass / subfinder / WHOIS | Shodan / Censys / amass / subfinder / WHOIS |
| 目的 | 弱点を見つけて侵入 | 弱点を見つけて自分で潰す |
| 継続性 | ターゲット選定時 (1 回) | 24/7 継続 |
| スコープ | 標的にした組織のみ | 自社のみ |
HackerOne / Bugcrowd の登録 scope に「全 ASM 範囲内」のような書き方をする企業が増えており、ハンターが発見した未知資産の脆弱性が報告されることで組織自身の ASM の穴が埋まる。Defender が ASM ベンダーを買い、追加でハンターを雇うという構図。
Pentest との違い: Pentest は「与えられた範囲を深く掘る」のに対し、ASM は「範囲そのものを決める」。ASM の出力が次のペンテストの入力になる関係で、「うちのスコープって何でしたっけ?」がそもそも答えられないという企業の現実を埋める。
代表事件 — ASM が機能していれば早く気づけたもの #
| 年 | 事件 | ASM 観点での教訓 |
|---|---|---|
| 2017 | Equifax (1.4 億件) | インターネット公開の Apache Struts ポータルにパッチ未適用 (CVE-2017-5638)。公開資産インベントリと脆弱性管理が同期していなかった |
| 2019 | Capital One (1 億件) | AWS の WAF 設定不備で SSRF 成立 → S3 のクレデンシャル流出。「外から見えている AWS リソース」の棚卸しが機能していなかった |
| 2020 | SolarWinds Orion | 攻撃対象は SolarWinds 製品を入れている企業群。「サードパーティ製品も Attack Surface」という認識を業界に広めた |
| 2021 | ProxyLogon / ProxyShell | インターネット公開の Exchange サーバが世界に約 25 万台。Shodan で即列挙可能。ASM があれば優先パッチできた |
| 2021 | Colonial Pipeline | 初期侵入は使われていなかったが生きていた古い VPN アカウント。「忘れられた認証エンドポイント」 |
| 2023 | MOVEit Transfer (Cl0p) | インターネット公開の MOVEit ファイル転送サーバの 0day。Shodan で約 2,500 台が確認され、ASM ベンダーは公開直後に顧客通知 |
| 2023 | Citrix Bleed (CVE-2023-4966) | Citrix NetScaler / ADC の公開資産。LockBit が大規模悪用、Boeing / ICBC などが被害 |
| 2024 | Snowflake 顧客侵害 (UNC5537) | MFA 未設定の Snowflake テナント — 167 社以上 (AT&T / Ticketmaster / Santander)。SaaS テナントも ASM の対象 |
| 2024 | Fortinet / Ivanti / ScreenConnect 連発 | 公開された VPN / リモート管理ツールのゼロデイ連発。Edge device の網羅的棚卸しが ASM の中核タスクに |
「公開されていることに本人が気づいていない / パッチ責任者がいない / SaaS は対象外と思っている」資産が起点。Attack Surface に新しい穴が開いた瞬間に攻撃者の自動化スキャンが見つけるため、気づくスピード勝負。Shodan の「タダで観測できるデータ」を攻撃者と防御者が同じ速度で見ているのが現代。
主要ベンダーと OSS #
ASM 関連市場は急成長中で、Gartner Magic Quadrant にも 2022 年から EASM が独立カテゴリとして登場した。
商用 ASM ツール (Cortex Xpanse / Defender EASM) は中堅企業以上向け。個人 / Bug Bounty / 小規模なら OSS の組合せで基本機能は実現可能。最小構成は 3 ツール: (1) subfinder でサブドメイン列挙、(2) httpx で生きてるか確認 + 技術スタック検出、(3) nuclei で KEV 脆弱性チェック。echo "自社.com" | subfinder | httpx | nuclei -t cves/ の 1 行で「自社の公開資産 + そこにある既知脆弱性」が出る。商用は継続実行 / ダッシュボード / チケット連携を買っている、と理解すると棲み分けが分かる。
商用 #
- EASM — Cortex Xpanse (Palo Alto) / Defender EASM (Microsoft、旧 RiskIQ) / CrowdStrike Falcon Surface / Censys ASM / Mandiant ASM / Tenable / Qualys CSAM / IONIX
- CAASM — Axonius (400+ コネクタ) / JupiterOne / runZero / Sevco / Lansweeper / Panaseer
- DRPS — Recorded Future / ZeroFox / Flashpoint / Cyberint / Intel 471
OSS (Bug bounty / Pentest でも日常的に使われる) #
| ツール | 用途 |
|---|---|
| Amass (OWASP) | サブドメイン列挙 + ASN ピボット + パッシブ DNS 統合 |
| subfinder (ProjectDiscovery) | サブドメイン列挙の定番 (パッシブのみ) |
| dnsx / httpx / naabu / katana | 解決・HTTP プローブ・ポートスキャン・クロール |
| nuclei | 発見した資産に対する脆弱性テンプレート照合 (KEV テンプレが豊富) |
| aquatone / httpx-toolkit | 一括スクリーンショット |
| gau / waybackurls | 過去 URL を Wayback Machine から取得 |
| trufflehog / gitleaks | GitHub 漏洩クレデンシャル発見 |
| shodan / censys CLI | スキャン基盤 API クライアント |
# seed から公開資産 + KEV 脆弱性まで一気通貫
$ 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"Shodan + amass + nuclei で「自社の公開資産 + そこにある KEV 脆弱性」までは無料で観測可能。商用ベンダーが提供しているのは継続実行 + ダッシュボード + 帰属精度 + チケット連携であり、技術的なコアは OSS にも揃っている。
落とし穴と限界 #
- 帰属の誤検知 — 「これはあなたの資産」と報告されたものが実は他社 (例: AWS 上の同 IP に乗っている別組織)。EASM ベンダーの confidence score を見て low confidence は人間がレビューする運用が必須
- チケット詰まり — 大量の脆弱性チケットが所有者不明で滞留。「所有者を決定するワークフロー」を ASM 導入前に整える
- 「全部 High 優先度」問題 — CVSS だけで並べると High が数千件になる。KEV + 公開度 + ビジネス重要度の 3 軸で実行可能な順位にする
- SaaS が対象外になりがち — Snowflake 事件のような MFA 漏れが残る。CAASM 側で SaaS API を統合するのが現代の解
- クラウドのエフェメラル資産 — コンテナ・サーバレス・スポットインスタンスは数時間で消える。CSPM / CNAPP と組み合わせる必要がある
- M&A 子会社の盲点 — 買収側 AD に統合される前の子会社は ASM スコープに入りにくい。Marriott / Starwood の失敗を繰り返さないため、買収時点で seed を追加するプロセスが必要
- 「発見」と「ペンテスト」のギャップ — ASM が「ある」ことは発見しても実際に侵入できるかは別問題。CTEM が「発見後の検証」を 1 サイクルに含めるのはこのギャップを埋めるため
- 検知ノイズと SOC 疲労 — DRPS 由来のフィッシングドメインアラートは日に数百件になる。「自動でテイクダウン申請」「明らかなノイズはフィルタ」の自動化が前提
まとめ #
- ASM は「自社の Attack Surface は完全には把握できない」という前提から逆算した分野。2018-2020 年に独立市場として確立
- EASM (外から見る) / CAASM (内外の API を統合) / DRPS (組織を取り巻く脅威環境) の 3 つが ASM の傘の下に並ぶ
- 2024 年以降は CTEM のフレームワーク下で発見 → 優先度付け → 検証 → 動員まで統合される方向
- 技術的には攻撃者の Recon と全く同じ手法 (CT / Passive DNS / Shodan / Censys / favicon hash / JARM) を「先に自分で」やる
- 商用ベンダーが提供しているのは継続性 + 帰属精度 + チケット連携 + ダッシュボード。OSS の組み合わせでも基本機能は実現可能
- 機能するかどうかは「発見の後の運用」で決まる。Equifax / Capital One / ProxyLogon / MOVEit / Snowflake はすべてサイクルのどこかが切れていた結果
