ASM（Attack Surface Management）の語源と定義を、EASMとの違いから整理する
Attack Surfaceという言葉の起源、研究・NIST・ISOで異なる定義の粒度、ASMとEASMの対象範囲を整理します。
先に結論: ASMとEASMは何が違うのか
Attack Surfaceは、単なるIT資産一覧でも脆弱性一覧でもありません。対象とするシステムや環境の境界にあり、攻撃者が侵入、影響の付与、データ取得などを試みる際に利用できる接点や経路の集合です。
ASM（Attack Surface Management）は、そのAttack Surfaceを継続的に発見し、所有者や用途を確認し、リスクを評価して対応へつなげる管理活動です。EASM（External Attack Surface Management）は、そのうちインターネットから観測・到達可能な外部範囲を扱います。
この包含関係は、NISTやISOが定めた公式な製品分類ではありません。現在の研究・標準・製品説明を読み比べるための概念整理です。実際には、製品やガイダンスによってASMをEASMとほぼ同じ意味で使う場合もあります。
この記事では、Attack Surfaceを次のように捉えます。
守りたい対象と、それを取り巻く環境との境界にある、攻撃へ利用され得る接点・経路・入力の集合。
ここでいう「環境」には、インターネットだけでなく、内部ネットワーク、利用者、連携システム、運用端末、保守媒体なども含まれます。どこまでを含めるかは、分析対象と想定する攻撃者によって変わります。
例えば、同じWebサービスでも、見る範囲によって次のように表現が変わります。
| 分析対象 | Attack Surfaceとして見るもの | 主な用途 |
|---|---|---|
| Webアプリケーション | ログイン、API、ファイルアップロード、管理機能 | 設計レビュー、脅威モデリング |
| Webシステム | 公開ポート、ロードバランサー、認証基盤、サービス間通信 | アーキテクチャ評価、侵入経路分析 |
| 組織 | ドメイン、IP、クラウド資源、SaaS、第三者接続 | ASM / EASM、資産管理 |
この3行は競合する定義ではありません。同じ対象を異なる倍率で見ています。用語の議論で先に揃えるべきなのは、定義の文言よりも分析の倍率です。
用語を読むときは、最初に次の3点を確認すると混乱しにくくなります。
- 何を対象にしているか。ソフトウェア、システム、環境、組織のどれか
- 境界をどこに置いているか。インターネット境界だけか、内部や物理面も含むか
- Managementに何を含めるか。発見と評価までか、修正・追跡までか
「Attack Surface」はどこから来たのか
サイバーセキュリティの概念としての直接的な起点は、Michael Howardが2003年に示したソフトウェアのAttack Surfaceと整理されています。2018年の体系的文献レビューも、Howardがこの概念を導入したと位置づけています。
同レビューは、attack surfaceという英語表現自体について、1972年の掘削工具の特許に物理的な作用面を指す用例があったとも報告しています。ただし、Howardがその用例を参照したという話ではありません。同じ表現が別分野で使われていたことと、サイバーセキュリティ上の概念の系譜は分けて考える必要があります。
Howardは2004年の記事で、アプリケーションのAttack Surfaceをcode, interfaces, services, protocols, and practicesの集合として説明しました。重視していたのは、インターネット上の資産を探すことではなく、未信頼の利用者に露出するコードや機能を減らすことです。Microsoftのアーカイブ記事では、次の3つがAttack Surface Reductionの原則として示されています。
- デフォルトで実行されるコードを減らす
- 未信頼の利用者から到達可能なコードを減らす
- 悪用された場合の被害を制限する
この考え方は、現在の「外部資産の可視化」よりも、セキュア設計の原則に近いものです。機能を無効化する、管理インターフェースを未信頼ネットワークから切り離す、低い権限でサービスを動かす、といった判断がAttack Surface Reductionになります。
Howardが列挙した5つの要素を、現在のシステムへ置き換えると次のように読めます。
| 要素 | 現在の例 | 減らす判断の例 |
|---|---|---|
| Code | オプション機能、プラグイン、管理用コード | 未使用機能をビルド・配布しない |
| Interfaces | API、管理画面、CLI、ファイル入力 | 管理APIを内部経路へ限定する |
| Services | 常駐プロセス、バックグラウンドサービス | 不要なサービスを停止する |
| Protocols | HTTP、SSH、独自プロトコル | 不要なプロトコルや旧版を無効化する |
| Practices | デフォルト設定、権限、運用手順 | 最小権限と安全な初期値を採用する |
ここから分かるのは、Attack Surfaceの縮小が「資産を削除すること」だけではないという点です。必要な機能を残したまま、到達できる主体を限定する、権限を下げる、入力経路を絞ることでも縮小できます。
なお、Attack Surfaceには現在も単一の定義があるわけではありません。前述のレビューでは、調査した644件の文献のうち71%が定義や参照元を示さずにこの語を使い、定義を6つの系統に分類できたと報告しています。「正しい定義を一つ選ぶ」より、資料が何を対象にしているかを確認する方が実用的です。
定義が揺れるのは、分析する粒度が違うから
Attack Surfaceは、ソフトウェア内部のAPIから、組織全体のドメインやクラウド資源まで、異なる粒度で使われます。
例えば、次の2つはどちらも成り立ちます。
Webサーバーは、組織のAttack Surfaceを構成する資産の一つです。
Webサーバーの公開ポート、API、認証機能、サービス権限が、システムのAttack Surfaceを構成します。
前者はASMで資産を発見・管理する粒度です。後者はソフトウェアやシステムを設計・分析する粒度です。資産自体と、その資産上の接点を同じ言葉で扱う資料があるため、Attack Surface = 資産一覧と短絡すると定義が噛み合わなくなります。
もう一つ注意したいのは、externally visibleを「インターネットに公開されている」とだけ読まないことです。形式モデルにおける外部とは、対象システムの外側を指します。社内システムから見た別システム、ローカルプロセスから見たOS、制御装置から見た保守端末も環境側に置けます。
| 対象 | 想定する環境・攻撃者 | 接点の例 | EASMからの見え方 |
|---|---|---|---|
| 公開Webサービス | インターネット上の利用者 | DNS、TLS、ログイン、API | 見つけやすい |
| 社内人事システム | 社内端末、侵入後の攻撃者 | SSO、内部API、共有ファイル | 通常は見えにくい |
| オフラインの制御端末 | 保守担当者、持込媒体 | USB、保守ポート、更新手順 | 見えない |
EASMの観測範囲はAttack Surfaceの一部であり、Attack Surfaceの定義そのものではありません。この区別がないと、外部資産を網羅した時点で「Attack Surfaceをすべて管理できた」と誤認しやすくなります。
| 資料・用法 | 主な粒度 | Attack Surfaceとして扱うもの |
|---|---|---|
| Michael Howard | アプリケーション、OS | コード、インターフェース、サービス、プロトコル、実践 |
| Howard・Pincus・Wing | 類似システムの比較 | 攻撃対象、通信経路、プロトコル、アクセス権限 |
| Manadhata・Wingら | ソフトウェアシステムと環境 | Entry / Exit Point、Channel、Untrusted Data |
| NIST | システム、要素、環境 | 境界上の点、内部横展開で到達できる箇所など |
| ISO/IEC 15408-1 | 評価対象 | 論理的・物理的インターフェース |
| 現在のASM / EASM | 組織のIT環境 | ドメイン、IP、クラウド資源、アプリ、第三者接続など |
古典的モデルからNIST・ISOまで
Attack Surfaceの定義は、初期の経験的な列挙から、比較モデル、形式モデル、標準上の境界・インターフェースへと広がりました。
相対比較としてのAttack Surface
Howard・Pincus・WingのMeasuring Relative Attack Surfacesは、Attack Surfaceを似たシステムやバージョン間で比較する考え方として扱いました。観点は、攻撃対象と攻撃を支援する資源、通信経路とプロトコル、アクセス権限です。
ここで重要なのは、Attack Surfaceの大きさがシステムの安全性を絶対評価する値ではないことです。同じ環境、攻撃者モデル、評価軸のもとで比較するから意味を持ちます。
論文が示した3つの抽象的な次元は、次のように整理できます。
| 次元 | 何を見るか | 比較例 |
|---|---|---|
| Targets and Enablers | 攻撃対象と、攻撃を可能にする機能 | 有効なサービス、動作コード、アカウント |
| Channels and Protocols | システムへ届く通信経路と規約 | オープンソケット、RPC、HTTP、共有チャネル |
| Access Rights | 接点が持つ権限 | root / 管理者 / 一般ユーザー / 匿名 |
例えば、バージョンアップでAPIの数が変わらなくても、実行権限を管理者から専用の低権限ユーザーへ落とせば、悪用時の被害可能性は小さくなります。逆に、脆弱性件数が同じでも、新しい管理ポートを外部へ公開すれば攻撃機会は増えます。
この比較は「Aは安全、Bは危険」という絶対判定ではありません。環境と脅威モデルを固定し、どちらがより多くの攻撃機会を持つかを説明するためのものです。環境条件が異なるシステム同士を単純な点数で並べても、比較の意味は弱くなります。
<M, C, I>による形式化
Manadhata・Kaynar・Wingは、A Formal Model for a System's Attack SurfaceでAttack Surfaceを次の三つ組として定義しました。
Attack Surface = <M, C, I>
3つの集合は、次のものを表します。
| 集合 | 意味 | Webサービスでの例 |
|---|---|---|
M: Methods | 環境から呼び出せるEntry Pointと、環境へ作用するExit Point | API、ログイン処理、Webhook送信、ファイル出力 |
C: Channels | システムと環境をつなぐ通信路 | TCP socket、HTTP connection、pipe、message queue |
I: Untrusted Data | 環境と共有され、システムが読み書きする未信頼の永続データ項目 | ファイル、Cookie、DBレコード、レジストリエントリ |
例えば、画像変換APIをこのモデルで見ると、POST /imagesがEntry Point、HTTPS接続がChannelです。利用者が共有ストレージへ置き、変換処理が後から読み込む画像ファイルはUntrusted Data Itemに当たります。変換後の画像を外部ストレージへ書き出す処理はExit Pointとして考えられます。
HTTPリクエストのheaderやparameterも、当然ながら入力検証の対象です。ただし、この論文でIと定義されるのは、実行をまたいで環境と共有される永続データです。一般的な「未信頼入力」という広い意味と、形式モデル上のUntrusted Data Itemは分けて読む必要があります。
ここでAPIエンドポイントだけを数えると、ファイル形式、URL参照、キュー経由の入力などが抜けます。逆に、資産台帳だけを見ても、どの入力がどの権限の処理へ到達するかは分かりません。<M, C, I>は、資産の存在から接点の構造へ分析を進めるための枠組みとして使えます。
このモデルでは、Attack Surfaceは対象システムだけで決まりません。同じアプリケーションでも、インターネット公開、VPN限定、社内LAN限定、localhost限定では、環境との関係が変わるためAttack Surfaceも変わります。
また、同論文はAttack Surfaceの測定値がコード品質や脆弱性数を表すものではないと明記しています。大きなAttack Surfaceが、直ちに多くの脆弱性を意味するわけではありません。
そのため、このモデルを「3種類の個数を足せば安全性が分かる式」と読むのは適切ではありません。各要素が持つ権限、到達可能性、データの損傷可能性などを踏まえて比較する必要があります。また、同じMethodが複数のChannelから到達できる場合もあり、単純な重複排除だけでは攻撃機会を表し切れません。
NISTは内部の到達可能性も扱う
NIST CSRC Glossaryは、Attack Surfaceをシステム、システム要素、環境の境界上にあり、攻撃者が侵入、影響の付与、データ取得を試みられる点の集合と定義しています。
NIST SP 800-160 Vol. 2 Rev. 1では、外部公開部分だけでなく、侵入後の横展開で到達可能な内部Exposure、開発・運用・保守環境、サプライチェーン、人やプロセスにも分析範囲を広げています。したがって、NISTのAttack Surfaceをインターネット向け資産だけに限定するのは正確ではありません。
この広さは、侵入の最初の一歩だけでなく、その後に攻撃者が何へ到達できるかを考えるために必要です。公開されたVPN装置を入口として発見しても、認証後に利用できる権限、管理ネットワークへの経路、運用アカウントの関係が分からなければ、影響範囲を評価できません。
また、製品の稼働時だけでなく、開発、配布、更新、保守を含むライフサイクルにも接点があります。ビルド環境、更新サーバー、保守委託先、サポート手順などは、公開サービス一覧には現れなくても、システムへ影響を与え得ます。
ISOは論理面と物理面を含める
ISO/IEC 15408-1:2026は、IT製品のセキュリティ評価における一般モデルを定める規格です。Attack Surfaceを、評価対象とその機能へのアクセスを試みられる点からなる、論理的または物理的インターフェースの集合として扱います。
論理面と物理面を分けると、ネットワークに接続されていない対象にもAttack Surfaceがあることを説明しやすくなります。次の表は、この区分を身近な対象へ当てはめた例です。
| 対象 | 論理的Attack Surface | 物理的Attack Surface |
|---|---|---|
| Webサービス | API、ログイン、アップロード機能 | 運用端末、保守媒体 |
| ネットワーク機器 | 管理画面、通信プロトコル | コンソール、筐体、保守ポート |
| 決済端末 | 認証処理、更新機能 | 筐体、USB、カード読取部 |
| 産業制御装置 | 制御プロトコル、遠隔管理 | シリアルポート、更新媒体 |
Asset、Vector、Vulnerability、Exposureを分ける
Attack Surfaceの説明が曖昧になる原因の一つは、関連用語が同じ意味で使われることです。役割を分けると、次のように整理できます。
この図は概念上の関係であり、NISTやISOの公式な分類図ではありません。特にExposureは資料によって用法が異なります。
Asset
NISTのAsset定義では、Assetは利害関係者にとって価値を持つものです。ハードウェアやソフトウェアだけでなく、データ、人、機能、サービス、評判なども含み得ます。
Attack Vector
Attack Vectorは、攻撃に使われる具体的な経路や手段です。例えば、公開VPNエンドポイントはAttack Surfaceの一部です。そのVPN装置の脆弱性を悪用して侵入することがAttack Vectorになります。
ただし、2003年のHowardらの論文では、オープンソケットや有効なゲストアカウント自体をattack vectorsと呼んでいます。歴史的資料では、現在の用語区分と異なることがあります。
Vulnerability
NISTのVulnerability定義では、脅威源によって悪用または誘発され得るシステム、手続、内部統制、実装上の弱点です。
適切に認証され、既知の脆弱性が見つかっていない公開APIにもAttack Surfaceはあります。反対に、脆弱なライブラリが存在しても、実行されず、想定する攻撃者から到達できなければ、その攻撃経路では悪用できない場合があります。
Exposure
NIST GlossaryはExposureを、組織や利害関係者がリスクの影響を受ける程度などと定義しています。一方、ASM製品では、インターネット公開、設定不備、過剰権限、意図しない到達可能性など、攻撃可能性につながる状態を広くExposureと呼ぶことがあります。
用語の名前だけで同一視せず、その資料内で何を数え、何を減らそうとしているかを確認する必要があります。
一つのシナリオに当てはめる
社外から利用できるファイル共有サービスを例にすると、関連用語は次のように分けられます。
| 用語 | 例 | 判断したいこと |
|---|---|---|
| Asset | 保存された機密文書、共有サービス | 何を守るのか |
| Attack Surface | ログイン、共有URL、アップロードAPI | どこが攻撃へ利用され得るか |
| Vulnerability | 共有URLの権限確認漏れ | どの弱点が悪用され得るか |
| Attack Vector | 推測したURLで他人の文書を取得する | どの経路・手段で攻撃するか |
| Exposure | 機密文書が外部取得可能な状態 | 何がどの程度リスクにさらされるか |
この整理では、脆弱性が未発見でもAttack Surfaceは存在します。ログインやアップロードは、正しく実装されていても環境との接点だからです。一方、脆弱性が存在することだけでは、現在のExposureを決められません。攻撃者からの到達可能性、認証、資産価値、補完統制などを合わせて評価します。
同じ公開APIでも、公開する必要があり、強い認証と監視があり、低い権限で動作するなら、単純に閉じるべきとは限りません。Attack Surfaceを減らすことは有効な原則ですが、必要な機能と引き換えになるため、最小化とリスク管理を分けて考えます。
ASMは何を「管理」するのか
ASMは、スキャン結果を一度作って終わる活動ではありません。資産や構成が変化する前提で、発見から再確認までを繰り返します。
ISOG-J / OWASP Japanのガイダンスは、ASMのプロセスをIT資産の発見、情報収集とリスク評価、リスクへの対応として整理しています。所有者の確認、誤検知の除外、対応優先度、修正依頼、期限や進捗の追跡まで考えると、単なる外部スキャンではなく管理プロセスになります。
実際の運用では、発見と対応の間に複数の判断があります。
| 活動 | 確認すること | 代表的な成果物 |
|---|---|---|
| 発見 | どの資産候補が外部から観測できるか | 候補ドメイン、IP、サービス一覧 |
| 帰属確認 | 自組織の資産か、誰が所有するか | 所有者、根拠、確信度 |
| 情報収集 | 何が動き、どう到達できるか | ポート、技術、証明書、関係資産 |
| リスク評価 | 弱点、設定不備、露出状態があるか | Findings、Exposure、検証結果 |
| 優先順位付け | 何を先に扱うか | 期限、優先度、判断理由 |
| 対応連携 | 誰が閉鎖・修正・受容するか | チケット、例外、担当チーム |
| 再確認 | 状態が変わったか、再発していないか | 修正確認、差分、継続監視 |
とくに帰属確認がないと、他組織の資産を自社の問題として追跡したり、反対に委託先や買収前のドメインを見落としたりします。発見結果は、確定した資産台帳ではなく、調査すべき候補集合として扱う方が安全です。
ただし、修正作業そのものをASMの範囲に含めるかは統一されていません。
| 資料・サービス | 発見 | 評価・優先順位付け | 修正・対応の扱い |
|---|---|---|---|
| Microsoft Security Exposure Management | ○ | ○ | 組織内外のAttack Surfaceを分析し、改善へつなげる |
| Google Cloud Mandiant ASM | ○ | ○ | SIEM、SOAR、ServiceNowなどへ連携する |
| 経済産業省 ASM導入ガイダンス | ○ | ○ | ガイダンス上のASM範囲からは分け、後続管理へつなぐ |
| ISOG-J / OWASP Japan | ○ | ○ | 修正依頼、期限、対応状況の追跡まで扱う |
発見と評価は共通しています。どのチームが修正するか、ASM側がどこまで追跡するかは、導入前に決める必要があります。
CVSS順だけでは優先順位を決められない
ASMで検出した項目をCVSSや製品スコアの降順で並べるだけでは、対応可能な順番にならないことがあります。少なくとも次の観点を合わせます。
- 攻撃者から実際に到達できるか
- 悪用可能な弱点か、バージョンからの推定か
- 認証やネットワーク制限などの補完統制があるか
- その資産が扱うデータと業務上の重要度は何か
- 内部へ進む経路や強い権限につながるか
- 所有者と修正手段が特定できているか
例えば、CVSSが高くても停止中で外部から到達できない検証資産と、CVSSは中程度でも認証なしで機密データへ到達できる本番APIでは、後者を先に扱う判断があり得ます。スコアは入力の一つであり、優先順位そのものではありません。
ISOG-J / OWASP Japanの対応プロセスも、発見資産や脆弱性情報には誤情報が含まれ得るため、関係性の確認、誤検知の除外、資産重要度と外部からの攻撃しやすさを踏まえた優先度、対応状況の追跡を事前に設計するよう説明しています。
EASMで見えるもの、見えないもの
EASMは、外部から組織を見たときに、把握できていなかった資産や意図しない公開状態を見つけることに強みがあります。Microsoft Defender EASMは、既知の資産を起点に関連するドメイン、IPアドレスブロック、ホスト、ASNなどを再帰的に発見し、外部のオンラインインフラを継続的に地図化すると説明しています。
Google CloudもEASMを、インターネット向け資産とクラウド資源を自動・継続的に発見し、技術的関係、脆弱性、設定不備、Exposureを評価するものと定義しています。
EASMの発見は、既知の資産から関係を広げていく処理です。ドメイン登録情報、証明書、DNS、IPブロック、Web上の参照などを手がかりに、次の候補を見つけます。そのため、結果には「自組織らしいが未確認」の資産と、共有基盤や過去の関係によって結びついた無関係な資産が混ざり得ます。
Microsoft Defender EASMのDiscovery説明でも、候補資産を所有関係の強さに応じて扱い、確認された資産を探索の起点にして反復的に地図を広げる考え方が示されています。ここで必要なのは、検出件数を増やすことより、候補を確定・却下できる根拠を残すことです。
経済産業省のASM導入ガイダンスは、ASMを「組織の外部（インターネット）からアクセス可能なIT資産」の継続的な発見・評価として定義しています。内容としてはEASMの範囲です。ISOG-Jのガイダンスも、経済産業省の文書がEASMに注目していると説明しています。
この用法は誤りというより、ガイダンスが扱う対象を外部資産へ限定したものです。ただし、NISTやISOの広いAttack Surface定義と同じ範囲だと解釈すると、内部API、権限関係、横展開経路、物理インターフェースなどが抜け落ちます。
EASMを導入したときに言えるのは、主に次の範囲です。
インターネットから観測・到達可能な外部資産と、そのリスクを継続的に発見・評価している。
EASM単独で、組織内外のすべての資産、権限、Attack Surface、攻撃経路を網羅しているとは通常いえません。IT資産管理、脆弱性管理、クラウドやIDの内部情報と組み合わせて補う必要があります。
| EASMで得意なこと | 別の情報で補うこと |
|---|---|
| 未知のドメイン、IP、公開サービスの候補発見 | 契約・購買・CMDBによる所有者確認 |
| 外部から見えるポート、証明書、技術の把握 | ホスト内部の構成、パッチ、実行状態 |
| 公開設定や既知脆弱性の外形的な評価 | 認証後の機能、内部API、データフロー |
| インターネット境界の継続的な差分検知 | ID権限、横展開経路、クラウド内部関係 |
| 外部視点でのリスク候補の優先付け | 業務影響、データ分類、例外・受容判断 |
また、「インターネットからアクセス可能」と「認証なしで利用できる」は同じではありません。VPN、管理画面、APIが認証で保護されていても、ネットワーク接点としては外部Attack Surfaceに含まれます。認証の強さは、その接点を表面から消すのではなく、悪用可能性を下げる統制として評価します。
Attack Surfaceを実務で整理する手順
定義を比較するだけでは、設計レビューやASM運用のスコープは決まりません。次の順番で書き出すと、ソフトウェア、システム、組織のどの粒度でも議論しやすくなります。
1. 守る対象と目的を決める
最初に、アプリケーション、決済端末、クラウド環境、組織全体など、分析対象を一つの文で置きます。目的も「新旧バージョンの比較」「外部公開資産の把握」「侵入後の経路分析」のように決めます。
対象が曖昧なままでは、ある人はドメイン一覧を、別の人はAPI入力を想像し、同じAttack Surfaceという言葉で別の作業を始めてしまいます。
2. 境界と環境を描く
対象に含むものと外側に置くものを分けます。外側にはインターネットだけでなく、利用者、社内ネットワーク、連携先、CI/CD、保守端末、委託先などを置けます。
境界は固定ではありません。組織全体を対象にすると社内システムは内側ですが、一つのアプリケーションを対象にすると認証基盤やデータベースは環境側の依存先になります。
3. 想定する攻撃者と到達条件を決める
匿名の外部攻撃者、正規アカウントを持つ利用者、侵入後の内部攻撃者、物理アクセス可能な保守担当者では、利用できる接点が変わります。誰が、どの位置から、どの権限で始めるかを置くと、分析対象外とした理由も説明できます。
4. 接点・経路・入力を列挙する
資産名だけで止めず、環境との接点を具体化します。<M, C, I>を使うなら、呼び出せる処理、通信路、未信頼入力を分けます。さらに、接点が持つ権限、認証、外部への出力、他システムへの依存も記録します。
| 確認項目 | 書き出す内容 |
|---|---|
| Entry / Exit | API、ログイン、Webhook、ファイル入出力、管理操作 |
| Channel | TCP、HTTP、queue、pipe、USB、保守ポート |
| Untrusted Data | 環境と共有するfile、cookie、DB record、registry entry |
| Trust Boundary | 認証前後、tenant間、ネットワーク境界、権限昇格点 |
| Privilege | 実行ユーザー、クラウド権限、データアクセス範囲 |
| Dependency | IdP、SaaS、更新元、委託先、ライブラリ配布経路 |
5. 減らす対象と管理する対象を分ける
不要な管理画面、停止できるサービス、廃止済みドメインは閉じる候補です。一方、顧客向けAPIのように必要な接点は、認証、最小権限、入力検証、監視、レート制限などで管理します。
すべてのAttack Surfaceをゼロにはできません。機能を提供する以上、必要な接点は残ります。縮小できる面と、残したうえで統制する面を分けると、Attack Surfaceがある = 問題という誤った結論を避けられます。
6. 変化を検知し、判断を更新する
新しいクラウド資源、証明書、API、委託先、権限変更によってAttack Surfaceは変化します。定期スキャンだけでなく、資産作成イベント、DNS変更、クラウド構成、IAM、デプロイ情報などを組み合わせると、発見から所有者確認までの時間を短縮できます。
運用指標も、検出件数だけでは不十分です。未知資産の確認時間、所有者不明の滞留、重大項目の修正時間、再発率、例外の期限切れなどを見ると、発見後の管理が機能しているかを評価しやすくなります。
まとめ: 定義より先に、対象・境界・攻撃者を置く
Attack Surfaceという言葉は、ソフトウェアの露出機能から組織の外部資産まで、複数の粒度で使われています。だからこそ、用語だけを見て同じ範囲だと判断しないことが重要です。
Attack Surfaceは、対象への攻撃に利用できる接点・経路であり、資産一覧や脆弱性一覧そのものではありませんASMは、Attack Surfaceの発見、分類、評価、優先順位付け、対応連携、再確認を継続する活動ですEASMは、インターネットから観測・到達可能な外部範囲へ対象を絞ります- NISTの定義は内部の到達可能性も扱い、ISOは論理的・物理的インターフェースを含めます
- Managementに修正そのものを含めるかは資料によって異なります
- 発見結果には帰属や検出の不確実性があるため、候補、根拠、所有者、対応状況を継続して管理します
資料や製品説明でAttack SurfaceやASMという言葉を見たら、「対象は何か」「境界はどこか」「想定する攻撃者は誰か」「対応をどこまで管理するか」を先に確認します。その4点が揃えば、異なる定義を無理に一つへ統一しなくても、実務上の比較ができます。
さらに、自分たちの環境へ適用するときは、資産名で止めず、接点・経路・入力・権限まで具体化します。外部から見つけるEASMと、内部情報を持つ資産管理、IAM、クラウド管理、脆弱性管理をつなげることで、発見しただけの一覧から、対応できるAttack Surface Managementへ進めます。
参考資料
- NIST CSRC Glossary: Attack Surface
- NIST SP 800-160 Vol. 2 Rev. 1
- ISO/IEC 15408-1:2026
- Michael Howard: Minimizing the Code You Expose to Untrusted Users
- Howard, Pincus and Wing: Measuring Relative Attack Surfaces
- Manadhata, Kaynar and Wing: A Formal Model for a System's Attack Surface
- Attack Surface Definitions: A Systematic Literature Review
- 経済産業省: ASM導入ガイダンス
- ISOG-J / OWASP Japan: ASM導入検討を進めるためのガイダンス
- Microsoft Defender External Attack Surface Management overview
- Google Cloud: Mandiant Attack Surface Management