おすすめの外部アタックサーフェス管理ツール7選（2026年）
Ostorlab、Defender EASM、Cortex Xpanse、CyCognitoなど7つの外部アタックサーフェス管理プラットフォームを、アセット検出、検証、修復の観点から比較します。
この2026年版の比較で評価する外部アタックサーフェス管理プラットフォームは、Ostorlab、Microsoft Defender External Attack Surface Management、Palo Alto Networks Cortex Xpanse、CrowdStrike Falcon Exposure Management、CyCognito、Censys Attack Surface Management、Tenable One Attack Surface Managementです。
これらのプラットフォームはいずれもインターネットに公開されたアセットを継続的に検出・監視しますが、帰属判定の手法、検出の深さ、能動的なセキュリティテスト、エクスポージャーの検証、修復ワークフロー、エコシステム連携、そして外部アセットをアプリケーションや脆弱性のデータとどこまで結び付けるかという点で違いがあります。
確認した公開資料の中で、Ostorlabは、Attack Surface製品におけるエージェント型の組織単位の検出と、より広いOstorlabプラットフォームを通じたWebアプリケーション、API、モバイルアプリケーション、ネットワークインフラにまたがる能動的なセキュリティスキャンを連携させている点で際立っています。これにより、未知のアセットの検出から、対象を絞ったスキャンの実行、裏付けとなるエビデンスの確認、修復の割り当て、そしてエクスポージャーが再発しないかの監視まで、一貫した流れが実現します。
編集方針に関する開示
本ガイドはOstorlabが公開しています。比較は一般に公開されているベンダー自身のドキュメントに基づくものであり、検出カバレッジ、検出精度、スキャン速度、誤検知（フォールスポジティブ）率に関する独立したベンチマークではありません。
EASMプラットフォームの比較一覧
| プラットフォーム | 文書化されている重点領域 | 購入者が確認すべき点 |
|---|---|---|
| Ostorlab | 複数のアセットタイプにわたるエージェント型の検出、アセットの帰属判定、継続的な監視、能動的なセキュリティスキャン、脅威に基づく優先順位付け、修復。 | 検出のスコープ、スキャンプロファイル、自動化の上限、アセットの許容数、能動的なテストを管理する制御。 |
| Microsoft Defender EASM | インターネットに公開されたインフラの外部視点での検出とマッピング、アセットの分類、アタックサーフェスに関するインサイト、Microsoftのセキュリティ製品との連携。 | ライセンス、Azureの運用要件、Microsoft Security Exposure Managementとの連携、能動的な検証の深さ。 |
| Cortex Xpanse | インターネット規模の検出、アセットの帰属判定、エクスポージャーの特定、リスクの優先順位付け、自動化された対応プレイブック。 | どの対応機能にActive Responseや別のモジュールが必要か、帰属判定をめぐる異議や所有者のワークフローがどう扱われるか。 |
| CrowdStrike Falcon Exposure Management | 外部アセットの検出と、攻撃者に関するインテリジェンス、AI支援型の優先順位付け、脆弱性管理、Falconプラットフォームのコンテキストの組み合わせ。 | 提案されたFalconパッケージにどのEASM機能とドメイン横断のエクスポージャー機能が含まれるか、隣接する機能にエンドポイントへの導入が必要かどうか。 |
| CyCognito | 外部アセットの検出、ビジネスコンテキストのマッピング、継続的なセキュリティテスト、悪用可能性の検証、修復の優先順位付け。 | 能動的な検証に用いる手法と安全制御、認証が必要なアプリケーションに対するテストのカバレッジ、連携の要件。 |
| Censys Attack Surface Management | インターネット全体のマッピング、全ポートにわたるサービス検出、アセットの帰属判定、過去のエクスポージャーデータ、セキュリティ運用との連携。 | エクスポージャーのインテリジェンスと能動的な脆弱性テストの区別、提案されたパッケージにおけるワークフローと修復の機能。 |
| Tenable One Attack Surface Management | 外部アセットの検出とコンテキスト付与を、Tenable One内の脆弱性とエクスポージャーのデータと統合。 | どの機能に別のTenable製品が必要か、未評価のアセットがどのようにスキャンへ回されるか、ライセンスモデル全体。 |
購入時の核心的な問いは、どのプラットフォームが最も多くのアセット数を出すかではありません。プラットフォームがアセットを正しく帰属判定し、各アセットがなぜその組織に属するのかを説明し、重大なエクスポージャーを特定し、担当チームがリスクの解消を検証できるよう支援できるかどうかです。
外部アタックサーフェス管理とは
外部アタックサーフェス管理（EASM）とは、組織のインターネットからアクセス可能なアセットを、外部からの視点で継続的に検出、帰属判定、評価、監視することです。
外部アタックサーフェスには、次のようなものが含まれます。
- ドメインとサブドメイン
- パブリックIPアドレス、ネットワーク範囲、ASN
- Webアプリケーションとポータル
- APIとAPIゲートウェイ
- モバイルアプリケーションのインベントリ
- クラウドでホストされるサービス
- インターネットに公開されたサーバーとネットワーク機器
- TLS証明書とDNSインフラ
- ストレージサービス
- SaaSインスタンス
- 開発環境とステージング環境のシステム
- 子会社や買収した企業が運用するアセット
- 放置されたインフラとシャドーIT
効果的なEASMシステムは、組織を識別する少数の既知の情報から出発し、ドメイン登録、証明書、DNSレコード、ホスティングインフラ、ブランディング、関連するアプリケーション、その他の帰属判定のエビデンスといった関係性を分析しながら、対象を外側へ広げていきます。
検出だけでは不十分です。有用なプラットフォームは、組織に属するアセットを無関係なインフラと区別し、意味のあるエクスポージャーを特定し、結論の根拠となるエビデンスを保持し、修復を支援する必要があります。
EASMと隣接するセキュリティカテゴリとの違い
| カテゴリ | 主な視点 | 主な目的 |
|---|---|---|
| EASM | 外部から内部へ | 攻撃者が到達し得る、インターネットに公開されたアセットを検出し監視する。 |
| CAASM | 内部から外部へ、連携主導 | 社内のセキュリティシステムやITシステムからアセットの記録を集約し正規化する。 |
| 脆弱性管理 | 既知のアセット | 管理対象のインベントリにすでに含まれているシステム上の脆弱性を特定し、優先順位付けする。 |
| CSPMとCNAPP | クラウドアカウントのコンテキスト | クラウドプロバイダーへのアクセスを用いて、クラウドの構成、アイデンティティ、ワークロード、デプロイのリスクを特定する。 |
| BASと自動化されたセキュリティ検証 | 制御の検証 | 攻撃手法をシミュレートまたは実行し、セキュリティ制御が機能しているかを判定する。 |
| デジタルリスク保護 | ブランドと脅威インテリジェンス | なりすまし、漏えいした認証情報、不正なドメイン、ソーシャルチャネル、ダークウェブ上の活動を監視する。 |
| ペネトレーションテスト（ペンテスト） | 許可されたスコープ内での調査 | アナリスト主導またはエージェント型のテストによって、脆弱性と攻撃経路を調査する。 |
これらのカテゴリは重なり合う部分が増えています。エクスポージャー管理プラットフォームは、EASMを社内の脆弱性データ、クラウドの態勢、エンドポイントのテレメトリ、脅威インテリジェンス、攻撃経路の分析と組み合わせることがあります。
したがって購入者は、製品カテゴリだけに頼るのではなく、実際の運用モデルを評価する必要があります。
企業がEASMプラットフォームで評価すべき点（とよくある落とし穴）
1. シードへの依存度と帰属判定の質
- 評価すべき点：プラットフォームは、最小限のシードデータ（たとえば組織名やメインドメインだけ）から出発して、CMDB、クラウドアカウント、エンドポイントシステムに存在しないアセットを特定できる必要があります。セキュリティチームには、アセットがなぜ結び付けられたのかを説明する明確な帰属判定の経路が必要です。
- よくある落とし穴：帰属判定の精度ではなく、アセットの総数を測ってしまうこと。膨れ上がったアセット数には、無関係な共有ホスト、期限切れのドメイン、パーキングされたIPが含まれていることが多く、対応につながる可視性ではなくアラート疲れを生みます。
2. 継続的な変化の監視とアラート疲れ
- 評価すべき点：外部のインフラは急速に変化します。一時的な環境が立ち上がり、DNSレコードがダングリング状態になり、証明書が期限切れになります。EASMは過去の経緯を時系列で保持し、意味のある変化についてアラートを出す必要があります。
- よくある落とし穴：日常的な技術的変更を優先度の高いインシデントとして扱うこと。アラートのしきい値は、無害なDNSレコードの更新のたびに発報するのではなく、リスクのコンテキストに合わせて調整する必要があります。
3. 能動的な検証と推測によるフィンガープリント
- 評価すべき点：受動的な観測（バナーの照合）と能動的な検証を区別します。能動的なテストを提供するプラットフォームは、明確な安全策、レート制限、透明性のあるテストパラメーター、再現可能な悪用可能性の実証を提供する必要があります。
- よくある落とし穴：ソフトウェアのフィンガープリントを確定した脆弱性として扱うこと。古いパッケージを示すバナーがあっても、到達可能な悪用可能性が実証されたわけではありません。逆に、バナーがないからといって安全が保証されるわけでもありません。
4. 所有者の特定と修復の検証
- 評価すべき点：責任を持つ所有者がいなければ、エクスポージャーは解消できません。効果的なプラットフォームは、コンテキストを伴うエビデンスとともに検出結果をチケット管理システム（Jira、ServiceNow）へ直接送り、修復後に自動で再スキャンして解消を確認します。
- よくある落とし穴：検出と修復を切り離すこと。検証されていない何千件もの検出結果をそのまま修復キューに取り込むと、EASMはエクスポージャーを着実に減らすクローズドループではなく、管理されないバックログになってしまいます。
5. エコシステムとの相互運用性
- 評価すべき点：SIEM、SOAR、CMDB、エクスポージャー管理プラットフォームとの連携がネイティブで双方向か、そしてプラットフォームへの完全なロックインを必要とせずにアセットのコンテキストを示すメタデータを保持できるかを確認します。
- よくある落とし穴：一つのプラットフォームが隣接するすべての制御を置き換えると想定すること。EASMは外部からの視点での検出を提供するものであり、社内の脆弱性管理、CSPM、詳細なペンテストを置き換えるのではなく補完するものです。
外部アタックサーフェス管理の機能マトリクス
以下の用語は控えめな基準で用いています。
- 対応：その機能が、現在のベンダー自身の公開資料に記載されている。
- 統合：その機能が、ベンダーのより広いプラットフォームまたは隣接する製品を通じて提供される。
- 限定的：公開文書に記載されたサポートに、意味のある制約があるか、範囲が狭い。
- 公開文書なし：その機能を確認できるだけの現在のベンダー自身の情報が見つからなかった。これは、その機能が存在しないことを証明するものではない。
| 機能 | Ostorlab（プラットフォーム連携） | Microsoft Defender EASM | Cortex Xpanse | CrowdStrike Falcon | CyCognito（ベンダー文書に基づく） | Censys | Tenable One |
|---|---|---|---|---|---|---|---|
| インターネットに公開されたアセットの継続的な検出 | 対応 | 対応 | 対応 | 対応 | 対応 | 対応 | 対応 |
| ドメイン、ホスト、IP、サービス | 対応 | 対応 | 対応 | 対応 | 対応 | 対応 | 対応 |
| アセットの関係性と帰属判定のエビデンス | 対応 | 対応 | 対応 | 対応 | 対応 | 対応 | 対応 |
| 変化の監視と過去の経緯 | 対応 | 対応 | 対応 | 対応 | 対応 | 対応 | 対応 |
| エージェント型の組織単位の検出 | 対応 | 公開文書なし | 限定的 | 公開文書なし | 公開文書なし | 公開文書なし | 公開文書なし |
| 検出したアセットに対する能動的なセキュリティスキャン | 連携プラットフォームでのスキャン | 限定的 | 公開文書なし | 公開文書なし | 対応（ベンダー表明） | 限定的 | 統合（Tenable WAS/VM） |
| 悪用可能性またはエクスポージャーの検証 | 連携プラットフォームでのスキャン | 限定的 | 公開文書なし | 公開文書なし | 対応（ベンダー表明） | 限定的 | 統合（Tenable One） |
| 脅威インテリジェンスに基づく優先順位付け | 対応 | 統合（Exposure） | 対応 | 対応（ExPRT.AI） | 対応 | 統合 | 統合（ExposureIQ） |
| チケット管理と修復ワークフロー | 対応 | 統合（Azure） | 統合（Active Responseアドオン） | 統合（Falcon Platform） | 対応 | 統合 | 統合（Tenable One） |
| 専用のDAST / MASTアプリケーションテスト | 連携プラットフォームでのスキャン | 公開文書なし | 公開文書なし | 統合（別モジュール） | 限定的 | 公開文書なし | 統合（別モジュール） |
| APIアクセスまたはデータのエクスポート | 対応 | 対応 | 対応 | 対応 | 対応 | 対応 | 対応 |
表の分類に関する注記：対応は、中核となるEASM製品内のネイティブな機能を示します。連携プラットフォームでのスキャンは、検出そのものの自律的な機能ではなく、ベンダーのより広いプラットフォームを通じて実行される統合されたテストを示します。対応（ベンダー表明）は、PoVの期間中に顧客による確認が必要な、ベンダーが文書化している機能（CyCognitoの自律テストに関する主張など）を反映しています。統合（モジュール）は、隣接するプラットフォーム製品、アドオンライセンス、または別のエージェントやスキャナーを必要とする機能を示します。限定的は、範囲が制約されているか、推測のみによる検出であることを示します。公開文書なしは、その機能が現在のベンダー自身の製品ドキュメントで確認されていないことを示します（これは、その機能が存在しないことを証明するものではありません）。
公開ドキュメントや商用パッケージの内容は変わります。購入者は各ベンダーに対し、同じ検出シード、組織のスコープ、帰属判定の決定、エクスポージャーのケース、修復ワークフローで実演するよう求めるべきです。
この比較で何が分かったか
2026年にEASM製品を比較する際に最も重要なのは、次の4つの違いです。
検出モデルは同等ではない
一部のプラットフォームは、インターネット全体の継続的な観測からインベントリを構築します。別のプラットフォームは、顧客が提供したシードから出発し、関係性のグラフをたどって範囲を広げます。両方のアプローチを組み合わせるものもいくつかあります。
有用な指標は、返されたアセットの総数ではありません。正しく帰属判定され、セキュリティ上の意味を持ち、顧客がまだ管理していなかったアセットの数です。
EASMはエクスポージャー管理と融合しつつある
Microsoft、CrowdStrike、Palo Alto Networks、Tenableは、EASMをより広いセキュリティ製品群と結び付けています。これにより社内の貴重なコンテキストが得られる可能性がありますが、購入者は、どの機能がEASM製品に属し、どの機能に追加のライセンスや導入済みのコンポーネントが必要なのかを見極める必要があります。
検証の深さは大きく異なる
一部の製品は、検出と外部のエクスポージャーに関するインテリジェンスに重点を置いています。別の製品は、検出したアセットを能動的にテストするか、脆弱性、アプリケーションセキュリティ、検証の各製品へ回します。
この違いは、プラットフォームが疑わしい弱点を報告するにとどまるのか、それともセキュリティチームが再現できるエビデンスを生み出すのかに直接影響します。
修復は運用モデルの問題である
露出したシステムを見つけることは始まりにすぎません。成果を上げているEASMプログラムは、所有者を明確にし、エビデンスを担当チームへ送り、修復が完了するまでエクスポージャーを追跡し、それがもう存在しないことを検証します。
正確な検出結果を出せても、このワークフローを支えられないプラットフォームは、管理されないキューをまた一つ増やすだけになりかねません。
EASMプラットフォームの詳細評価
Ostorlab
重点領域：Web、モバイル、API、ネットワークのアセットにわたって、エージェント型の組織単位の検出を、能動的なセキュリティスキャンと修復ワークフローと組み合わせる。
Ostorlabは、外部アタックサーフェスの検出を、複数のアプリケーションおよびインフラのアセットタイプにわたる能動的なセキュリティテストと修復ワークフローと組み合わせています。
文書化されているAIエージェントによるアタックサーフェス検出のワークフローでは、ユーザーが自然言語のプロンプトで組織を説明できます。システムは候補となるドメイン、サブドメイン、クラウドリソース、モバイルアプリケーション、SaaSの公開面、関連する組織を生成し、それらの候補を確認または除外のために提示します。
この人間による確認のステップが重要なのは、組織上の関係が必ずしも技術的な所有を証明するわけではないからです。買収、地域ブランド、提供を終了した製品、共有インフラ、サービスプロバイダーは、正当な曖昧さを生む可能性があります。
確認されたアセットは、所有者の管理、フィルタリング、グラフ上の関係性、監視、セキュリティスキャンに対応したインベントリに登録されます。Ostorlabのドキュメントには、インベントリから直接アセットをスキャンする方法も記載されており、Webアプリケーション、ネットワーク範囲、API、モバイルアプリケーション、ソースコードリポジトリ、複数アセットの評価に対応しています。
Ostorlab 2025 Year in Reviewでは、エージェント型のアタックサーフェス検出とThreat Centerの連携が説明されています。新たに悪用された脆弱性や更新されたフィンガープリントを顧客の環境に照らし合わせることで、チームは現在進行中の悪用活動の影響を受けるアセットを特定できます。
Ostorlabはまた、検出結果をチケット管理との連携、自動化ルール、所有者の管理、修復の追跡、再スキャンと結び付けています。これにより、別個の外部インベントリを維持するのではなく、検出から調査、検証までの継続的なワークフローを実現します。
確認すべき点：購入者は、子会社、買収した企業、共有インフラ、提供を終了したドメインを含む複雑な組織構造に対して検出をテストする必要があります。また、どのスキャンプロファイルが含まれるか、能動的なテストがどのように許可されるか、アセット、スキャン、AIの利用量が価格にどう影響するかも確認する必要があります。
Microsoft Defender External Attack Surface Management
重点領域：Microsoft Security Exposure ManagementおよびAzureエコシステムとのネイティブな連携による、インターネットに公開されたインフラの継続的なマッピング。
Microsoft Defender External Attack Surface Managementは、組織のインターネットに公開されたインフラを外部の視点から継続的に検出し、マッピングします。
インベントリには、ドメイン、ホスト、ページ、IPアドレス、IPブロック、自律システム番号、連絡先、SSL証明書が含まれます。Microsoftは各アセットについてコンテキストを示すメタデータを記録し、アセットがなぜその組織に関連付けられたのかをアナリストが理解するのに役立つ検出時の関係性を提示します。
Defender EASMはアセットをインベントリの状態ごとに整理し、承認済みのアセット、候補として検出されたもの、依存関係、除外されたインフラをチームが区別できるようにしています。また、外部から見える状態を特定するためのダッシュボードとAttack Surface Insightsも提供しています。
Microsoftは、アセットの記録とアタックサーフェスのインサイトをエクスポートするためのデータ接続を文書化しています。Defender EASMは、Microsoft Security Exposure ManagementやDefender for Cloudのワークフローに外部視点のコンテキストを提供することもできます。
このプラットフォームは、すでにAzureとMicrosoftのセキュリティエコシステムを広く活用している組織にとって特に適しています。ただし、EASMによる検出と完全な脆弱性の検証は別々の機能であるため、購入者は、どのエクスポージャーが外部から観測されたもので、どれがMicrosoftの他の機能を通じて能動的にテストされたものかを明確にする必要があります。
確認すべき点：Azureのリソースと課金の要件、課金対象アセットの算定方法、データ保持、データのエクスポートの選択肢、Microsoft Security Exposure Managementとの連携、疑わしい脆弱性を検証するためのワークフローを確認します。
Palo Alto Networks Cortex Xpanse
重点領域：インターネット規模の継続的な検出、機械支援による帰属判定、エクスポージャーの検出、Active Responseによる自動化された修復プレイブック。
Palo Alto Networks Cortex Xpanseは、インターネット規模の継続的な検出、機械支援による帰属判定、エクスポージャーの検出、対応を中心に構築された、能動的なアタックサーフェス管理プラットフォームです。
Palo Alto Networksによると、Xpanseはパブリックインターネットを継続的にスキャンし、接続されたシステムと露出したサービスを特定します。教師あり機械学習モデルがアセットを組織に対応付け、修復の優先順位付けを支援します。
Xpanseは、アタックサーフェスのルールを用いて、露出したサービスや脆弱なソフトウェアといった状態を特定します。検出されたインフラがルールで定義された条件に一致すると、プラットフォームはアラートを作成します。
この製品は、シャドークラウド、M&Aの評価、サードパーティのエクスポージャー、ランサムウェアの侵入口、新たに公開された脆弱性の迅速な調査といったユースケースにも対応しています。
Cortex Xpanseは、Active Responseによる組み込みの対応プレイブックを文書化しています。ただし、Active Responseはアドオンとして説明されているため、購入者は自動化された修復がすべてのXpanseパッケージに含まれていると想定すべきではありません。
確認すべき点：購入するXpanseのモジュール、Active Responseの利用権、インターネットスキャンの頻度、帰属判定のレビューワークフロー、対応している修復プレイブック、組織で導入済みのPalo Alto Networks製品との連携を確認します。
CrowdStrike Falcon Exposure Management
重点領域：外部視点でのアセット検出と、攻撃者に関するインテリジェンス、ExPRT.AIによる優先順位付け、統合されたFalconプラットフォームのコンテキストの組み合わせ。
CrowdStrike EASMは、より広いFalcon Exposure Management製品群の中で提供されています。
この製品は、インターネットに公開されたインフラを継続的にマッピングし、既知および未知の外部アセットを特定し、インベントリの変化を追跡し、攻撃者と脆弱性に関するインテリジェンスを適用してエクスポージャーの優先順位付けを行います。
CrowdStrikeは、EASM、脅威インテリジェンス、ITハイジーン、脆弱性管理、その他のFalconプラットフォームの機能の間の連携を文書化しています。同社のExPRT.AIレーティングは、CrowdStrikeの脅威と攻撃者に関するコンテキストを用いて、脆弱性のエクスポージャーの優先順位付けに使われます。
このより広いプラットフォームモデルは、外部視点での検出をエンドポイントや脆弱性のテレメトリと相関させたい組織にとって有用です。それでも購入者は、インターネットの外部観測だけで機能するものと、Falconエージェント、追加モジュール、または社内のデータソースに依存するものとを区別する必要があります。
確認すべき点：EASM、脆弱性管理、攻撃経路、エンドポイント、脅威インテリジェンスのうち、どの機能が提案されたパッケージに含まれるかを確認します。また、各機能がエージェントレスなのか、エージェント支援型なのか、他のFalconモジュールに依存するのかも確認します。
CyCognito
重点領域：外部視点での自律的なアセット検出、ビジネスコンテキストのマッピング、継続的かつ能動的な悪用可能性のテスト。
CyCognito Attack Surface Managementは、外部アセットを検出し、それをビジネスコンテキストに対応付け、セキュリティ上の弱点がないかをテストし、確認されたリスクを優先順位付けすることに重点を置いています。
CyCognitoは、完全な初期インベントリを必要とせずにアセットを特定できるよう設計された、攻撃者の視点に立った検出モデルを文書化しています。このプラットフォームは外部アセットのグラフを構築し、アセットを組織に帰属させ、そのビジネス上の用途を分類します。
CyCognitoの打ち出し方の中心にあるのが、能動的な検証です。同社によると、このプラットフォームは複数のセキュリティカテゴリにわたって外部アセットをテストし、外部から発見可能で、攻撃者にとって魅力的で、悪用可能であることが検証されたエクスポージャーを優先します。
このモデルは推測に基づくリスクへの依存を減らせる一方で、テストの透明性と運用上の安全性が特に重要になります。顧客は、どのテストが実行されるのか、認証の境界がどのように扱われるのか、悪用可能性の結論をどのようなエビデンスが裏付けているのかを正確に理解しておく必要があります。
確認すべき点：能動的なテストに関する許可と安全のモデル、対応しているアセットタイプ、認証が必要なアプリケーションのカバレッジ、帰属判定のレビュー制御、エビデンスの質、チケット管理システムおよび脆弱性管理システムとの連携を確認します。
Censys Attack Surface Management
重点領域：全65,535ポートにわたるインターネット全体の網羅的なスキャン、精度の高いサービスインテリジェンス、過去のエクスポージャーのマッピング。
Censys Attack Surface Managementは、Censysのインターネット全体のマッピングとサービス観測のインフラの上に構築されています。
Censysは、全65,535ポートにわたるスキャンによって、インターネットに公開されたホスト、サービス、証明書、エクスポージャーを特定することを文書化しています。これらは、検出が主にDNSレコードや一般的なポートのスキャンに依存している場合には見落とされる可能性があるものです。
このプラットフォームは組織のシードデータから出発し、関係性のエビデンスが帰属判定の信頼度のしきい値を超えると、アタックサーフェスを拡張します。検出経路により、アナリストは候補アセットが既知の組織のアセットとどのように結び付けられたのかを確認できます。
Censysはまた、過去のインターネットデータを保持し、セキュリティツールと連携することで、チームが特定されたエクスポージャーを調査し対処できるようにしています。
この製品の中核的な強みは、インターネットの可視性とアセットのインテリジェンスです。それでも購入者は、観測されたエクスポージャー、ソフトウェアの推測、オンデマンドの検証、そして完全な脆弱性テストやアプリケーションセキュリティテストを区別する必要があります。
確認すべき点：関連するプロトコルのスキャン頻度、IPv6とクラウドのカバレッジ、帰属判定のしきい値、過去データの保持期間、能動的な検証の機能、APIの制限、利用可能な修復関連の連携を確認します。
Tenable One Attack Surface Management
重点領域：Tenableの脆弱性管理、エクスポージャーのスコアリング、評価ワークフローと直接統合された、外部視点でのアセットのマッピング。
Tenable One Attack Surface Managementは、インターネットに公開されたアセットを継続的にマッピングし、それらをより広いTenable Oneプラットフォーム内の脆弱性とエクスポージャーの情報と結び付けます。
この製品は、ドメインと関連するインターネット上のアセットを特定し、変化を監視し、検出したシステムにコンテキストを示すメタデータを付与します。Tenableは、未評価の外部アセットをスキャンに回し、アタックサーフェスの情報を他のTenableのエクスポージャーデータと組み合わせる機能を文書化しています。
この統合は、すでにTenable Vulnerability ManagementやTenable Oneを利用している組織に適しています。外部の検出によって管理対象のインベントリに含まれていなかったシステムを特定することで、脆弱性管理プログラムのスコープを広げられます。
購入者は、Tenable Attack Surface Managementと隣接するTenable製品との境界がどこにあるのかを確認する必要があります。検出、脆弱性評価、Webアプリケーションテスト、クラウドのコンテキスト、統合されたエクスポージャースコアリングには、それぞれ別の技術要件やライセンス要件がある場合があります。
確認すべき点：どのTenable Oneコンポーネントが必要か、検出したアセットがどのようにライセンスされるか、どのスキャンエンジンがそれらを評価するか、外部の記録が既存のアセットとどのように重複排除されるか、修復状況がどのように検証されるかを確認します。
信頼できるEASMの価値実証（PoV）を実施する方法
EASMの価値実証では、スクリーンショットやベンダーが提示するアセット数を比べるのではなく、運用サイクル全体をテストする必要があります。
| 評価領域 | 検証手順 |
|---|---|
| シードへの依存度 | メインドメインと社名だけを提供し、プラットフォームがどの有効な未知のアセットを検出するかを記録する。 |
| 帰属判定の質 | 確認済み、候補、依存、除外の各アセットからサンプルを選んでレビューし、それぞれの関係性を裏付けるエビデンスを調べる。 |
| 子会社の検出 | 買収した企業、地域ブランド、または所有の経緯が複雑な部分的に独立した子会社を含める。 |
| クラウドの検出 | CMDBに存在しない一時的なホスト、クラウドサービス、ストレージのエンドポイント、開発環境をプラットフォームが見つけられるかをテストする。 |
| サービスのカバレッジ | 標準ポートと非標準ポートにわたる検出結果を比較し、観測されたサービスデータの鮮度を調べる。 |
| エクスポージャーの検証 | 優先度の高いエクスポージャーをいくつか選び、それぞれが推測されたものか、安全に検証されたものか、能動的にテストされたものか、別の製品で確認されたものかを判定する。 |
| 変化の監視 | 許可された一時的なテスト用アセットを作成または公開し、その構成を変更して、プラットフォームが両方のイベントをどれだけ早く検知するかを測定する。 |
| 所有者のワークフロー | エクスポージャーを担当チームに割り当て、エビデンス、アセットのコンテキスト、修復の指示が引き継ぎ後も失われないことを確認する。 |
| 修正の検証 | テスト用のエクスポージャーを修正し、プラットフォームがその変化を検知して、検出結果を適切にクローズまたは更新することを確認する。 |
| APIとエクスポート | アセット、関係性、検出結果、所有者、ステータスのデータを、組織の運用システムにエクスポートする。 |
信頼できる価値実証は、次の5つの問いに答えるものでなければなりません。
- 組織がまだ把握していなかったもので、プラットフォームは何を検出したか。
- それらのアセットをどれだけ正確に帰属判定したか。
- 重大な意味を持つエクスポージャーはどれだったか。
- エクスポージャーが実在することを、どのようなエビデンスが示したか。
- ワークフローは、担当チームがそれらを修復し検証するのに役立ったか。
よくある質問
最適な外部アタックサーフェス管理プラットフォームはどれか
この比較で評価したEASMプラットフォームは、Ostorlab、Microsoft Defender EASM、Palo Alto Networks Cortex Xpanse、CrowdStrike Falcon Exposure Management、CyCognito、Censys Attack Surface Management、Tenable One Attack Surface Managementです。これらは、検出の手法、帰属判定、能動的な検証、脅威のコンテキスト、修復、エコシステム連携の点で異なります。
外部アタックサーフェス管理とは何か
外部アタックサーフェス管理とは、組織のインターネットに公開されたアセットを、外部からの視点で継続的に検出、帰属判定、評価、監視することです。未知のインフラ、シャドーIT、露出したサービス、構成上の弱点、その他外部から観測可能なリスクの特定に役立ちます。
EASMプラットフォームはどのようなアセットを検出できるか
EASMプラットフォームは、ドメイン、サブドメイン、パブリックIPアドレス、ネットワーク範囲、ASN、Webアプリケーション、API、モバイルアプリケーション、証明書、DNSインフラ、クラウドサービス、ストレージのエンドポイント、その他組織に関連するインターネットからアクセス可能なアセットを検出できます。
EASMはどのように未知のアセットを検出するのか
EASMプラットフォームは、ドメイン、社名、IP範囲、クラウドの情報といった組織の識別情報から出発し、技術的およびコンテキスト上の関係性をたどって範囲を広げます。こうした関係性には、DNSレコード、証明書、登録データ、ホスティングインフラ、関連するサービス、ブランディング、観測されたインターネット上の活動が含まれます。
EASMと脆弱性管理の違いは何か
EASMは、管理対象のインベントリに現れないシステムも含め、インターネットに公開されたアセットを組織の外部から特定します。脆弱性管理は主に、すでに登録されているか、スキャン対象として提供された既知のアセットを評価します。
EASMとCAASMの違いは何か
EASMは外部からのインターネット観測によってアセットを検出するのに対し、CAASMは社内のセキュリティ、クラウド、アイデンティティ、IT管理の各システムからアセット情報を集約し相関させます。この2つのアプローチは、外部からの可視性と社内の記録を突き合わせることで、互いを補完できます。
EASMは脆弱性を能動的にテストするのか
セキュリティ上のエクスポージャーを能動的にテストまたは検証するEASMプラットフォームもあれば、検出、フィンガープリンティング、外部のインテリジェンスに重点を置くものもあります。購入者は、各検出結果が推測されたものか、受動的に観測されたものか、安全に検証されたものか、能動的に悪用されたものかを見極める必要があります。
EASMにエージェントは必要か
EASMの中核となる検出は、パブリックインターネットからアセットを観測するため、一般にエージェントレスです。より広いエクスポージャー管理の機能では、エンドポイント、クラウド、脆弱性、ビジネスのコンテキストを追加するために、エージェントや社内連携を用いる場合があります。
EASMでシャドーITを見つけられるか
はい。承認済みのインベントリに含まれていない、外部からアクセス可能なインフラを見つけることは、EASMの主要なユースケースです。これには、忘れられたドメイン、一時的なクラウドシステム、開発環境、買収により取得したインフラ、通常のガバナンスプロセスの外でデプロイされたサービスが含まれます。
外部アタックサーフェスはどのくらいの頻度で監視すべきか
インターネットに公開されたアセットとその構成は頻繁に変化するため、外部アタックサーフェスは継続的に監視すべきです。組織はリスクに基づいてアラートのしきい値を定め、重大なエクスポージャーには対応しつつ、不要な運用上のノイズを生まないようにする必要があります。
組織はEASMプラットフォームをどのように比較すべきか
組織は、同じ限られたシードデータ、帰属判定のサンプル、テスト用のエクスポージャー、子会社、クラウド環境、修復ワークフローを用いてEASMプラットフォームを比較すべきです。評価では、有効な未知のアセットの検出、帰属判定の精度、エビデンスの質、優先順位付け、所有者の管理、修正の検証を測定する必要があります。
EASMはペンテストに取って代わるのか
いいえ。EASMはインターネットに公開された広範なエクスポージャーを継続的に検出・監視するのに対し、ペンテストは許可されたスコープの中でより深い調査を行います。EASMは、アプリケーションテスト、エクスプロイトの検証、あるいは焦点を絞ったペンテストに値する対象を特定し、優先順位付けできます。
Ostorlabからの最終的な推奨
最も価値のあるEASMプラットフォームは、必ずしも最も多くのアセットを返すものではありません。組織が検出、帰属判定、セキュリティ評価、所有者の明確化、修復、検証を着実に進められるよう支援するものです。
Ostorlabは、これらの段階を一つのアプリケーションセキュリティプラットフォーム内で結び付けることで、差別化されたアプローチを提供します。
- エージェント型の検出：組織の説明を、候補となるドメイン、サブドメイン、クラウドリソース、モバイルアプリケーション、SaaSの公開面、関連するエンティティへと変換できます。
- 人間による確認の制御：提案されたアセットが管理対象のアタックサーフェスに登録される前に、アナリストがそれを確認または除外できます。
- 能動的なセキュリティテスト：検出したアセットを、Web、API、ネットワーク、モバイル、ソースコード、複数アセットのスキャン機能と結び付けます。
- 脅威に基づくコンテキスト：新たに悪用された脆弱性や更新された技術のフィンガープリントに関連するアセットを、チームが特定するのに役立ちます。
- 修復ワークフロー：エビデンスを、アセットの所有者、自動化ルール、チケット管理、監視、再スキャンと結び付けます。
EASMを単なる外部インベントリ以上のものとして評価している組織にとって、決め手となる問いは次のとおりです。
そのプラットフォームは、未知のアセットを検出し、それがなぜ組織に属するのかを実証し、何が露出しているのかを明らかにし、担当チームがリスクの解消を検証できるよう支援できるか。