OpenBASからOpenAEVへ刷新された背景とセキュリティ担当者が押さえるべき基本概念

OpenBASからOpenAEVへ刷新された背景とセキュリティ担当者が押さえるべき基本概念

セキュリティ検証ツールの世界では、単発のテストから継続的な脅威エクスポージャー管理（CTEM）へとパラダイムが大きくシフトしています。その変化を象徴するのが、Filigran社が提供するオープンソースプラットフォームのリブランドです。従来のOpenBAS（Breach and Attack Simulation）は、2025年10月に「OpenAEV（Adversarial Exposure Validation）」へと名称を変更しました。この変更は単なるブランド刷新にとどまらず、プラットフォームの思想そのものが攻撃シミュレーションからエクスポージャー検証へと拡張されたことを意味します。ここではまず、OpenAEVを正しく理解するために不可欠な背景知識と基本概念を整理します。

2025年10月のリブランド発表に至ったBASからAEVへの市場パラダイム転換

Filigran社は2025年10月29日、OpenBASをOpenAEVへリブランドするとともにEnterprise Edition（EE）の提供開始を公式に発表しました。この名称変更の根底にあるのは、サイバーセキュリティ業界全体で起きている「BAS（Breach and Attack Simulation）からAEV（Adversarial Exposure Validation）への移行」というトレンドです。従来のBASは、あらかじめ定義した攻撃手法をシミュレーションし、その検知可否を確認するという単発的なアプローチが中心でした。しかし現在の脅威環境では、攻撃対象領域を継続的に評価し、脅威インテリジェンスと連動して優先順位を付けながら検証・修復を繰り返す一連のサイクルが求められています。OpenAEVはこのAEVパラダイムに対応するために再設計されており、単なるテストツールから脅威エクスポージャー管理の基盤プラットフォームへと進化しました。

Filigran社が掲げるXTMスイート構想におけるOpenAEVの位置づけと役割分担

OpenAEVを提供するFiligran社は、2022年にフランス・パリで設立されたサイバーテック企業です。2025年10月にはシリーズCで5,800万ドルを調達し、累計資金調達額は1億ドルを超えています。同社は「eXtended Threat Management（XTM）」スイートという製品群を展開しており、OpenAEVはその中核コンポーネントの一つです。XTMスイートは主に3つの製品で構成されています。1つ目のOpenCTIは脅威インテリジェンスの収集・分析・運用を担うプラットフォームで、6,000以上の組織が利用しています。2つ目がOpenAEVで、OpenCTIの出力する脅威情報をもとに攻撃シナリオを作成し、検証を実行する役割を果たします。3つ目として開発中のOpenGRCがあり、脅威に基づくサイバーリスク管理を担う予定です。つまりOpenAEVは、インテリジェンスの「理解」と「対策」をつなぐ橋渡し役として位置づけられています。

シナリオ・インジェクト・シミュレーションで構成されるOpenAEV独自の3層モデル

OpenAEVのアーキテクチャを理解するうえで重要な概念が、シナリオ・インジェクト・シミュレーションの3層構造です。最上位の「シナリオ」は、特定の脅威コンテキストに基づいて設計されたテンプレートの役割を持ちます。シナリオにはドキュメントやメディアファイルなどの背景資料を紐づけることができ、演習参加者に文脈を提供します。中間層の「インジェクト」は、シナリオ内の個別アクションを定義する最小単位です。エンドポイント上でコマンドを実行するもの、メールやSMSを送信するもの、フィッシングメールを模倣するものなど、多様なタイプが用意されています。そして「シミュレーション」は、シナリオを実際の環境で実行するランタイムです。ワンショット実行と定期スケジュール実行の両方に対応しており、同じシナリオから複数のシミュレーションを繰り返し実施することで、経時的な改善を追跡できます。この3層モデルにより、テンプレートの再利用性と実行の柔軟性を両立しています。

MITRE ATT&CKフレームワーク準拠で攻撃手法を体系化するシナリオ設計の基本思想

OpenAEVのシナリオ設計は、MITRE ATT&CKフレームワークに準拠しています。MITRE ATT&CKは、実際の攻撃者が使用する戦術・技術・手順（TTPs）を体系化したナレッジベースであり、セキュリティ業界で事実上の標準として広く採用されています。OpenAEVではインジェクトを作成する際、対応するMITRE ATT&CKテクニックをフィルター条件として指定できるため、特定のテクニックIDに関連するテストケースを素早く選択可能です。たとえば「T1005（Data from Local System）」のようにテクニックIDを指定してインジェクトを絞り込み、シナリオに組み込む運用が想定されています。また、OpenAEVのキュレーション済みペイロードに加え、Red Canary社が提供するAtomic Red Teamのテストライブラリもビルトインで利用できるため、MITRE ATT&CKの幅広いテクニックを網羅した検証が実施可能です。この標準化された設計思想により、組織間でのシナリオ共有や業界ベンチマークとの比較が容易になります。

技術レイヤーと人的レイヤーの両面を1プラットフォームで検証できる設計上の優位性

多くのBAS製品がエンドポイントやネットワークの技術的検証に特化しているのに対し、OpenAEVは技術レイヤーと人的レイヤーの両方を単一プラットフォーム上で検証できる点に設計上の大きな特徴があります。技術レイヤーでは、エンドポイント上でのペイロード実行やネットワーク侵入のエミュレーション、EDR・XDRによる検知の自動検証が行えます。一方の人的レイヤーでは、ビルトインの机上演習（テーブルトップエクササイズ）機能を通じて、SOCアナリストやIT管理者、経営層がインシデント発生時にどう判断・行動するかを評価できます。たとえばフィッシングメールの模擬送信に対して誰がアラートを上げたか、エスカレーション手順は正しく機能したかといった人的対応の結果が記録され、スコア化されます。この統合アプローチにより、ツールの検知性能だけでなくプロセスと人を含めた組織全体のレジリエンスを定量的に把握できる仕組みが実現しています。

攻撃シナリオの自動生成からEDR連携まで網羅するOpenAEVの主要機能と技術構成

OpenAEVは多機能なプラットフォームですが、実際にどのような技術的仕組みで動作し、どこまでの自動化が可能なのかを正確に理解している担当者は多くありません。ここでは、AI支援によるシナリオ生成からエージェントの実行基盤、外部セキュリティツールとの連携アーキテクチャまで、OpenAEVの技術的な中核要素を掘り下げます。

AIアシスタントがCERTレポートから数分で攻撃シナリオを自動生成する仕組み

OpenAEV Enterprise Edition（EE）には、AIを活用したシナリオ自動生成機能が搭載されています。この機能は、CERTレポートや脅威インテリジェンスレポートを入力として受け取り、それを実行可能な攻撃シナリオへ自動的に変換する仕組みです。従来、セキュリティチームがシナリオを設計する際には、脅威レポートの内容をMITRE ATT&CKテクニックにマッピングし、インジェクトの順序と依存関係を定義し、ペイロードを選択するという一連の作業を手動で行う必要がありました。AIアシスタントはこのプロセスを大幅に短縮し、レポートの内容から関連する攻撃手法を抽出してシナリオの骨格を数分で組み立てます。生成されたシナリオはすべてカスタマイズ可能であり、ペイロードの差し替えやタイミングの調整を自由に行えます。これによりセキュリティ人材が限られた組織でも、最新の脅威に対応した検証を迅速に開始できるようになっています。

インジェクターとコレクターの2種類で外部システムと双方向接続する統合アーキテクチャ

OpenAEVが外部システムと連携する際の基盤となるのが、「インジェクター」と「コレクター」という2種類のコネクタです。インジェクターは、ターゲット環境に対してアクションを送り込む役割を担います。具体的には、エンドポイント上でのペイロード実行をトリガーするタイプや、メール・SMSなどの通信チャネルを通じて参加者にメッセージを配信するタイプがあります。新たなインジェクターを独自に開発して環境やワークフローに合わせた拡張も可能です。一方のコレクターは、セキュリティツールからアラートやイベントデータを収集する受信側の仕組みです。EDRやXDRプラットフォームから取得したテレメトリを、シミュレーションで定義された「期待値（エクスペクテーション）」とマッピングすることで、注入された攻撃が実際に検知されたかどうかを構造的に評価できます。この双方向アーキテクチャにより、OpenAEVは攻撃の発射と結果の収集を一貫して管理するハブとして機能します。

Windows・Linux・macOS対応のエージェント型ペイロード実行における技術要件

OpenAEVでは、エンドポイント上でのシミュレーションを実行するために専用エージェントをインストールする方式が採用されています。このエージェントはWindows、Linux、macOSの3つの主要OSに対応しており、混在環境でも統一的な検証が行えます。技術的には、エージェントがインプラント（中間実行モジュール）をデタッチドプロセスとして起動し、インプラントが実際のペイロードを実行するという多段構成です。エージェント自体は攻撃を直接行わないニュートラルな設計のため、アンチウイルスに検知されにくく、シナリオの継続実行が担保されます。エージェントのインストールは、OpenAEVのダッシュボード右上のパネルからOS別の手順を確認でき、指示に従って配布する運用が想定されています。なお、Enterprise Editionではエージェントレスの実行方式も利用できます。CrowdStrikeやTaniumなど既存のEDRエージェントを活用してシミュレーションを実行できるため、リソースが限られたエンドポイントに追加のソフトウェアをインストールする必要がありません。環境の制約やセキュリティポリシーに応じて、エージェント型とエージェントレス型を使い分けられる柔軟性がOpenAEVの技術的な強みの一つです。

CrowdStrikeやSplunk向け検知ルール自動生成で修復を短縮するAI支援機能

Enterprise Editionで提供されるAI支援機能は、シナリオ生成だけにとどまりません。シミュレーション実行後の修復フェーズにおいても、AIが重要な役割を果たします。具体的には、検証で発見された脆弱性やギャップに対して、CrowdStrikeやSplunkといった主要セキュリティ製品向けの検知ルールを自動的に生成する機能が含まれています。従来のBASツールでは「脆弱性が見つかりました。アップグレードしてください」という一律的な推奨にとどまるケースが多かったのに対し、OpenAEVは「どのように修復すべきか」という具体的な手段まで提示するアプローチを採用しています。AIによるリスクベースの優先順位付けにより、最もクリティカルな問題から順に対処できるため、SOCチームの修復時間（Time-to-Remediate）の短縮に直結します。さらに、修復ナレッジは組織内で標準化・蓄積されるため、属人的な対応からの脱却も促進されます。

定期スケジュール実行とアラート通知で検知精度の経時劣化を可視化するモニタリング設計

セキュリティ対策は導入直後が最も効果が高く、時間の経過とともに検知精度が劣化するリスクがあります。設定変更やルールの陳腐化、新たな攻撃手法の出現などが原因です。OpenAEVはこの課題に対して、シナリオの定期スケジュール実行とアラート通知を組み合わせたモニタリング機能を提供しています。同じシナリオを日次・週次・月次で自動的に再実行し、防御（Prevention）と検知（Detection）の両方の結果を前回と比較します。スコアが悪化した場合にのみメール通知を送信する設定も可能なため、状態が安定している間は不要なアラートに煩わされることがありません。ダッシュボードでは経時的なスコア推移がグラフ化されるため、特定のシナリオに対する検知率のトレンドを一目で把握できます。このモニタリング設計は、CTEMが求める「継続的な検証と改善のサイクル」をプラットフォームレベルで支える基盤であり、防御態勢の劣化を早期に発見するうえで極めて重要な役割を果たしています。

無償Community版と有償Enterprise版で異なる機能範囲と組織別の選定基準

OpenAEVには無償のCommunity Edition（CE）と有償のEnterprise Edition（EE）の2つのエディションが存在します。導入を検討する際、どちらのエディションを選択すべきかは組織の規模やセキュリティ成熟度によって大きく異なります。ここでは両エディションの具体的な違いと、選定にあたって考慮すべき判断基準を解説します。

Apache 2.0ライセンスで商用利用も可能なCommunity版の機能範囲と制約

OpenAEV Community Edition（CE）は、Apache 2.0ライセンスのもとで公開されているオープンソースソフトウェアです。Apache 2.0は商用利用を明示的に許可しているライセンスであり、企業環境での導入に法的な障壁はありません。CE版では、シナリオの作成・編集・実行、インジェクトの定義、シミュレーションの実施とダッシュボードによる結果確認、OpenCTIとの連携、XTM Hubのシナリオライブラリ活用、カスタムダッシュボードの構築といったコア機能が利用可能です。Atomic Red Teamのペイロードもビルトインで使用でき、MITRE ATT&CKベースの検証を開始するための基本的な機能は揃っています。一方で、AI支援によるシナリオ自動生成や修復ガイダンス、既存EDRエージェントを利用したエージェントレス実行、SaaSデプロイメント、専任のカスタマーサポートといった高度な機能はCE版には含まれません。評価目的やPoC実施にはCE版で十分対応できますが、大規模な本番運用にはEE版の検討が必要になるケースが多いです。

既存EDRエージェント連携やSaaS提供を含むEnterprise版限定の5大追加機能

Enterprise Edition（EE）はCE版の全機能に加え、大規模組織向けの高度な機能を提供します。主要な追加機能を以下の比較表で整理します。

CrowdStrikeやTaniumとの連携によるエージェントレス実行は、リソース制約のあるエンドポイントで特に効果を発揮します。AIによるシナリオ生成と修復ガイダンスは、セキュリティ人材が限られた組織の運用工数を大幅に削減する機能です。SaaS環境はFiligran社がホストし、セルフサービスプロビジョニングと専任サポートが含まれます。これらの機能が自組織にとって必要かどうかを事前に明確にすることが、エディション選定の出発点になります。

セキュリティ専任者が3名以下の中小組織がCE版で運用を始める際の現実的な限界

CE版は無償で利用できるため、予算の限られた中小組織にとって魅力的な選択肢です。しかし、セキュリティ専任者が3名以下の体制で本格的に運用しようとすると、いくつかの現実的な壁に直面します。まず、シナリオの設計と維持に相応の専門知識と工数が必要です。AIによる自動生成機能がないCE版では、MITRE ATT&CKテクニックへのマッピングやインジェクトの順序設計をすべて手動で行わなければなりません。次に、エージェントのデプロイメントと管理も手動対応が基本となるため、対象エンドポイントが数十台を超えるとオペレーション負荷が急増します。さらに、シミュレーション結果の分析と修復アクションの優先順位付けもAI支援なしでは属人的な判断に依存しがちです。加えて、公式の専任サポートがないため、トラブル発生時にはGitHubのIssueやSlackコミュニティでの自力解決が前提になります。こうした制約を考慮すると、CE版は概念実証やスモールスタートには適していますが、継続的な運用には体制の整備が不可欠です。

年間ライセンス費用と自社構築コストを比較したEE版導入の費用対効果の判断軸

EE版の具体的なライセンス価格はFiligran社への個別問い合わせが必要ですが、費用対効果を判断する際には総所有コスト（TCO）の視点が重要です。CE版をオンプレミスで運用する場合、インフラの調達・維持費用、エージェント管理の人件費、シナリオ設計の工数、トラブルシューティングの時間といったコストが発生します。特にシナリオの設計・更新にかかる人的コストは見落とされがちですが、セキュリティエンジニアの工数として月あたり数十時間に達するケースも珍しくありません。EE版のSaaSオプションを選択すれば、インフラ管理は不要になり、AIによるシナリオ自動生成で設計工数も大幅に削減されます。また、修復ガイダンスの自動化によってインシデント対応時間が短縮されれば、SOCの運用効率向上という形でリターンが得られます。判断軸としては、対象エンドポイント数が100台を超える場合や、複数拠点でのシミュレーションが必要な場合にEE版のROIが高まる傾向があります。

設定画面からEE機能を即時トライアルできる評価プロセスと本番移行時の注意点

OpenAEVの特徴的なポイントとして、CE版のインストール後にプラットフォームの設定画面からEnterprise Edition機能を直接有効化してトライアルできる仕組みがあります。サインアップや別途のインストール作業が不要であり、CE版の環境をそのまま使って高度な機能を試せるため、評価のハードルが非常に低く設定されています。トライアル中はAIシナリオ生成や修復ガイダンスなどのEE限定機能を実際のデータで検証できるため、自組織の環境での有効性を具体的に判断できます。ただし、本番移行時にはいくつかの注意点があります。トライアル期間中に作成されたEE固有のデータやワークフローが、ライセンス未契約の状態でどう扱われるかを事前に確認しておく必要があります。また、SaaSへの移行を選択する場合、オンプレミス環境のデータ移行手順や、テナント分離のポリシーについてFiligran社と事前に合意しておくことが推奨されます。

OpenCTIとの双方向連携で実現する脅威インテリジェンス駆動型の検証ワークフロー

OpenAEVの最大の差別化要因の一つが、同じFiligran社が提供するOpenCTIとの緊密な連携です。脅威インテリジェンスプラットフォームとエクスポージャー検証プラットフォームが双方向に接続されることで、「何が脅威か」を理解するだけでなく「その脅威に対して防御が機能しているか」を継続的に検証するワークフローが実現します。

OpenCTIの優先脅威情報をOpenAEVのシナリオへ自動変換する連携フローの全体像

OpenCTIとOpenAEVの連携は、XTMスイートの統合設計の中核をなす機能です。OpenCTIは多様なソースから収集した脅威インテリジェンスを集約し、優先情報要件（Priority Intelligence Requirements: PIR）に基づいて脅威情報に優先順位を付けます。この優先順位付けされた脅威情報が、OpenAEVのシナリオ作成アシスタントに渡されます。Enterprise Editionを利用している場合、AIが脅威情報から関連するMITRE ATT&CKテクニックを自動的に抽出し、対応するインジェクトを選択してシナリオの骨格を構築します。Community Editionでもシナリオとインジェクトの手動作成は可能ですが、自動変換機能はEE限定となります。この一方向のフローに加え、OpenAEVでの検証結果がOpenCTIにフィードバックされる双方向の接続も実装されています。つまり、脅威の発見から検証、修復、再検証までの一連のループがプラットフォーム間で自動的に回る設計です。

脅威インテリジェンスに基づくリスクベース優先順位付けで検証対象を絞り込む判断基準

すべての脅威を網羅的に検証することは、リソースの観点から現実的ではありません。OpenAEVでは、OpenCTIから得られる脅威インテリジェンスに基づいてリスクベースの優先順位付けを行い、検証対象を効率的に絞り込むアプローチを採用しています。判断基準として重要なのは、まず自組織の業種・地域に対する脅威アクターの活動頻度です。OpenCTIが追跡する脅威アクターのプロファイルと自組織の属性を照合することで、最も蓋然性の高い攻撃シナリオを特定できます。次に、既知の脆弱性情報と自組織のアセット情報を突き合わせ、実際にエクスプロイト可能な経路が存在するかを評価します。さらに、過去のシミュレーション結果で検知率が低かったテクニック領域を優先的に再検証する運用も有効です。このリスクベースアプローチにより、限られたリソースで最大の効果を得るための検証計画が立案でき、網羅的なテストに比べてセキュリティチームの負荷を大幅に軽減しながら実効性の高い検証を継続的に実施できます。

XTM Hubのキュレーション済みシナリオライブラリ活用で初期構築を3日で完了する方法

OpenAEVの導入を加速する手段として、XTM Hubが提供するキュレーション済みシナリオライブラリの活用が挙げられます。XTM Hubは、Filigranのユーザーコミュニティがアクセスできる中央リソースプラットフォームであり、MITRE ATT&CKテクニックをカバーする事前構築済みのシナリオが多数公開されています。初日はOpenAEVの環境構築とエージェントのデプロイに充てます。Docker Composeによるインストールであれば、環境変数の設定からプラットフォーム起動まで数時間で完了できます。2日目にXTM Hubからシナリオをインポートし、自組織のアセットとチームメンバーの紐づけを行います。OpenAEVにはStarter Packも内蔵されており、テーブルトップ型・エージェントレス型・エージェント型の事前構築済みシナリオが用意されているため、ゼロから設計する必要がありません。3日目には最初のシミュレーションを実行し、ダッシュボードで結果を確認するところまで到達できます。この3日間のプロセスはあくまで初期構築であり、本番運用に向けたチューニングは別途必要です。

検証結果をOpenCTIへフィードバックして防御態勢の改善サイクルを自動化する実装例

OpenAEVとOpenCTIの双方向連携の最も実践的な活用法が、検証結果のフィードバックによる改善サイクルの自動化です。たとえば、ある脅威アクターが使用するラテラルムーブメント手法に対するシミュレーションを実施した結果、EDRでの検知率が60%にとどまったとします。この結果はOpenAEVのダッシュボードに記録されると同時に、OpenCTI側でも該当する脅威アクターやテクニックに紐づいた形で可視化されます。SOCチームは検知率が低かったテクニックに対して、検知ルールの追加やEDRポリシーの調整を行い、修復完了後に同じシナリオを再実行して検知率の改善を確認します。この一連のサイクルが「評価→検証→修復→再検証」のCTEMループとして定着すると、脅威インテリジェンスが単なる「知識」ではなく「防御力の継続的な向上」に直結するアウトプットとなります。定期実行をスケジュールしておけば、修復後の効果測定もさらに自動化されます。

連携設定で頻出するAPIトークン認証エラーとネットワーク疎通不良の2大トラブル対処法

OpenCTIとOpenAEVの連携構築において、最も頻繁に報告されるトラブルは大きく2つに分類されます。1つ目はAPIトークンの認証エラーです。OpenAEVの環境変数OPENAEV_ADMIN_TOKENにはUUID v4形式のトークンを設定する必要がありますが、形式の不備や設定ファイル間での不一致が原因で認証に失敗するケースがあります。Docker Composeの.envファイルと、XTM Composerの環境変数OPENAEV__TOKENの値が完全に一致しているかを確認することが第一歩です。2つ目はネットワーク疎通の問題です。Docker環境ではコンテナ間の名前解決が重要であり、OpenAEVコンテナとOpenCTIコンテナが同一のDockerネットワーク上に存在しない場合、通信が確立できません。docker-compose.yml内のOPENAEV__URLがコンテナ名ベースの内部URL（例：http://openaev:8080）で正しく設定されているかを確認してください。これらの基本的なチェックポイントを押さえることで、連携設定の大半のトラブルは解消できます。

Dockerオンプレミス構築からSaaS利用まで対応するOpenAEV導入手順と前提条件

OpenAEVの導入にあたっては、Docker Composeによるオンプレミス構築とFiligranホストのSaaS利用という2つの主要な選択肢があります。どちらを選ぶにしても、依存コンポーネントの理解やリソース要件の把握は欠かせません。ここでは具体的な構築手順と、本番運用で躓きやすいポイントを詳しく解説します。

PostgreSQLやMinIOなど5つの必須依存コンポーネントの役割とリソース要件

OpenAEVの動作には5つの必須依存コンポーネントが必要です。公式ドキュメントに記載されている構成は以下のとおりです。Java Runtime（OpenJDK推奨）はプラットフォーム本体の実行環境として不可欠です。PostgreSQL（バージョン17推奨）はプラットフォームのコアデータを格納するリレーショナルデータベースとして機能します。Elasticsearch（バージョン8.x推奨）は、プラットフォームデータのインデックス作成と検索を担当し、Kibanaと組み合わせた可観測性の向上にも利用できます。RabbitMQ（バージョン4推奨）は、Pythonインジェクターとプラットフォーム間の非同期メッセージングを管理するキューシステムです。MinIOはオブジェクトストレージとして、シミュレーションのアーティファクトやドキュメント類を保存します。Docker Compose環境ではこれらに加えRSA鍵生成サービスとXTM Composerが連携基盤として稼働します。ハードウェアリソースについては、コミュニティの導入ガイドにおいてCPU 8vCPU以上、メモリ16GB以上、ストレージ250GB SSDが一つの目安として紹介されています。

Docker Composeによるオンプレミス環境構築で最低限変更すべき4つの環境変数

Docker Composeを使った構築は、公式のDockerリポジトリをクローンするところから始まります。git clone https://github.com/OpenAEV-Platform/docker.gitを実行し、ディレクトリ内の.env.sampleを.envにコピーして環境変数を設定します。サンプルファイルの大部分はテスト用途ではそのまま利用できますが、最低限4つの変数を変更する必要があります。第1にOPENAEV_HOSTで、プラットフォームにアクセスするIPアドレスまたはホスト名を設定します。第2にOPENAEV_ADMIN_EMAILで、管理者アカウントの有効なメールアドレスを指定します。第3にOPENAEV_ADMIN_PASSWORDで、十分に複雑なパスワードを設定します。第4にOPENAEV_ADMIN_TOKENで、UUID v4形式のトークンをオンラインジェネレーターなどで生成して設定します。これらを設定した後、docker compose up -dを実行すれば、依存コンポーネントを含むすべてのサービスが起動し、http://OPENAEV_HOST:8080でプラットフォームにアクセスできるようになります。

Starter Pack活用でエージェント登録から初回シミュレーション実行までの手順

プラットフォームの初回起動が完了したら、OpenAEVに内蔵されているStarter Packを活用して素早く最初のシミュレーションを実行できます。手順は大きく4つのステップで構成されます。

1. ダッシュボード右上のアイコンからエージェントのインストール画面を開き、対象エンドポイントのOSに合わせた手順でエージェントをデプロイする
2. Starter Packに含まれる事前構築済みシナリオ（テーブルトップ型・エージェントレス型・エージェント型）から検証目的に合ったものを選択する
3. 対象のエンドポイントとチームメンバーをシナリオに紐づけたうえで「Launch now」をクリックしてシミュレーションを実行する
4. Atomic Testingの概要画面でペイロードの実行成否と検知結果を確認し、エクスペクテーションの検証を行う

初回は最もシンプルなエージェント型のAtomicペイロードシナリオが推奨されます。エージェントをデプロイすると、プラットフォームのアセット一覧に登録済みエンドポイントが表示されるため、紐づけ作業はドラッグ操作で直感的に行えます。このプロセスにより、プラットフォームの基本的な動作確認と初期データの取得をスムーズに完了させることが可能です。

SaaS版を選択した場合のデータ保管場所やテナント分離に関するセキュリティ確認事項

EE版のSaaSオプションを選択した場合、Filigran社がホストするマネージド環境でOpenAEVを利用することになります。オンプレミスの構築・運用負荷がなくなる一方で、セキュリティ部門として確認すべき事項が複数存在します。第1に、データの保管場所です。シミュレーションの結果やシナリオ情報には組織のセキュリティ態勢に関する機密情報が含まれるため、データセンターの所在地域とデータレジデンシーの要件を事前に確認する必要があります。第2に、テナント分離の方式です。マルチテナント環境の場合、論理的な分離が十分に担保されているか、物理的な分離オプションが提供されているかを確認します。第3に、データの暗号化方式（転送中および保存時）と鍵管理の仕組みについてです。第4に、データの保持期間と削除ポリシーについても契約前に合意しておくことが重要です。これらの確認事項は、自組織のセキュリティポリシーやコンプライアンス要件と照合して、SaaS導入の可否を判断するための基礎情報となります。

本番運用前に見落としやすいSMTP設定不備とElasticsearchメモリ不足の障害例

OpenAEVの環境構築自体はDocker Composeで比較的スムーズに完了しますが、本番運用に移行する段階で頻出する障害パターンが2つあります。1つ目はSMTP設定の不備です。OpenAEVはフィッシングシミュレーションやアラート通知にメール送信機能を使用するため、SMTP（およびIMAP）の設定が正しくないとシミュレーションの中核機能が動作しません。特にGmailを利用する場合、二要素認証が有効なアカウントではアプリ固有パスワードの生成が必須となります。.envファイルのSMTPセクションで、ホスト・ポート・認証情報・SSL/TLSの各設定を正確に記述しているか入念に確認してください。2つ目はElasticsearchのメモリ不足です。.envファイルのELASTIC_MEMORY_SIZEのデフォルト値では、大量のシミュレーションデータを扱う本番環境では不足する場合があります。Elasticsearchがメモリ不足でクラッシュすると、プラットフォーム全体の検索・インデックス機能が停止するため、運用規模に応じたメモリ割り当ての見直しが不可欠です。

SOCチームの検知率検証から経営層向け机上演習まで広がるOpenAEVの実務活用シナリオ

OpenAEVは汎用性の高いプラットフォームですが、具体的にどのような場面で活用できるのかをイメージできなければ導入の判断は困難です。ここでは、技術的な検知率検証から組織全体の危機管理演習まで、実際の運用で効果を発揮する代表的な活用シナリオを紹介します。

EDR検知率を定量スコア化してセキュリティ投資の妥当性を経営層へ報告する活用例

セキュリティ投資の効果を経営層に説明する際、「EDRを導入しているから安全」という定性的な説明だけでは不十分です。OpenAEVを活用すれば、特定の攻撃シナリオに対するEDRの検知率を定量的なスコアとして提示できます。たとえば、自社が属する業種を標的とする脅威アクターの上位5つのTTPsに対してシミュレーションを実行し、防御率80%・検知率65%・人的対応率40%という結果が得られたとします。このスコアをダッシュボードからエクスポートし、経営報告に組み込めば、投資の効果と残存リスクを数値で示すことが可能です。さらに定期実行の結果を時系列で並べれば、四半期ごとのスコア改善をトラッキングでき、追加投資の必要性やセキュリティ施策のROIを客観的に議論する基盤が得られます。この活用法は、CISOが経営層とセキュリティリスクについて建設的な対話を行ううえで非常に有効であり、セキュリティ投資の正当性を数値で裏付ける説得力のあるアプローチとして多くの組織で導入が進んでいます。

ランサムウェアやフィッシングなど脅威ベクター別に再現する5種類のシミュレーション分類

OpenAEVで実施できるシミュレーションは、脅威ベクターに応じて大きく5つのカテゴリに分類できます。

• ネットワーク侵入シミュレーション：外部からのスキャンや脆弱性エクスプロイトを通じた初期侵入を再現し、境界防御の有効性を検証する
• ラテラルムーブメントシミュレーション：内部ネットワークでの水平展開を模倣し、セグメンテーションや内部検知の有効性を評価する
• フィッシングシミュレーション：実際のメールチャネルを使って従業員の反応を測定し、セキュリティ意識の水準を定量化する
• エンドポイント・ゲートウェイ攻撃シミュレーション：マルウェアやランサムウェアのペイロードを実行し、EDRの防御・検知能力をテストする
• テーブルトップエクササイズ：技術的なテストを伴わず、インシデント発生時の判断力・対応力・連携能力を演習形式で評価する

これらのカテゴリは単独で実施することも、複数を組み合わせて多段階の攻撃チェーンとして構成することも可能です。たとえばフィッシングによる初期侵入からラテラルムーブメントを経てランサムウェア展開に至る一連のシナリオを構築すれば、キルチェーン全体にわたる防御態勢を包括的に検証できます。

スイス連邦外務省が170拠点で実施した危機管理演習に学ぶ大規模展開の成功要因

OpenAEVの大規模導入事例として、スイス連邦外務省（FDFA）の事例が公式に紹介されています。FDFAは世界各地の大使館や領事館を含む170拠点を管轄しており、各拠点が直面する脅威はその地域の地政学的状況によって大きく異なります。従来の年次ベースの危機管理演習では、これほど多様な環境への対応は物理的に困難でした。FDFAがOpenAEVを採用した主な理由は、シミュレーションの標準化とスケーラビリティです。共通のシナリオテンプレートを作成し、各拠点の状況に合わせてパラメーターを調整することで、一貫した品質の演習をグローバルに展開できるようになりました。この事例から得られる教訓は3つあります。第1にシナリオの再利用性を重視した設計が大規模展開の鍵であること、第2に拠点ごとの脅威プロファイルの違いをパラメーター化して吸収する柔軟性が必要であること、第3に演習結果を本部で集約・比較するダッシュボードの活用が組織横断的な改善を促進することです。

Atomic Red Team活用のエンドポイント単体テストで検証精度を高める手法

OpenAEVには、Red Canary社が提供するAtomic Red Teamのテストライブラリがビルトインで統合されています。Atomic Red Teamは、MITRE ATT&CKマトリックスにマッピングされた小規模で焦点を絞ったテストの集合体であり、多くのテストが5分以内に実行できる設計です。OpenAEVでの活用方法としては、シナリオを介さずにAtomic Testingセクションから個別のインジェクトを直接実行する単体テストが効果的です。たとえば、特定のMITRE ATT&CKテクニックID（例：T1005 Data from Local System）に対応するAtomicペイロードを選択し、対象のエンドポイントで実行します。結果はエクスペクテーションとの突き合わせにより、EDRが防御できたか・検知できたかが自動判定されます。この単体テストを繰り返し実行することで、個々のテクニックに対する検知カバレッジを網羅的にマッピングでき、シナリオ全体のシミュレーションでは見落とされがちな個別の検知ギャップを高い精度で特定できます。

演習結果のダッシュボードから防御・検知・人的対応の3軸でギャップを特定する分析手順

OpenAEVのダッシュボードは、シミュレーション結果を「防御（Prevention）」「検知（Detection）」「人的対応（Human Response）」の3つの軸で構造化して表示します。分析手順としては、まずグローバル概要ダッシュボードで組織全体のセキュリティ態勢をスコアとして確認します。次に、個別のシミュレーション結果画面に移動し、タイムラインビューでインジェクトごとの成否を時系列で追跡します。防御スコアが低いインジェクトについては、EDRのポリシー設定やシグネチャの更新状況を確認して修復アクションを特定します。検知スコアが低い場合は、SIEMのログ収集設定やアラートルールの見直しが必要です。人的対応スコアが低いケースでは、インシデント対応手順書の周知不足やエスカレーションパスの不明確さが原因として考えられます。3軸それぞれのギャップに対して異なるアプローチが求められるため、ダッシュボードの結果を軸ごとに分解して分析する習慣を持つことが、継続的な改善の出発点となります。

BASツールとの比較で見えるOpenAEV導入判断に必要な評価項目と組織適合条件

OpenAEVの導入を最終的に判断するには、既存のBASツールや競合のAEVプラットフォームとの比較が不可欠です。ここでは、従来型BASの構造的課題を踏まえつつ、OpenAEVが適合する組織の条件やPoC時の評価指標、段階的な導入ロードマップを提示します。

従来型BAS製品が抱える単発テスト偏重とコンテキスト不足という2つの構造的弱点

OpenAEVの価値を正しく評価するためには、従来型BAS製品の構造的な弱点を理解しておく必要があります。第1の弱点は、単発テストへの偏重です。多くのBAS製品は「定義されたテストケースを実行して結果を返す」という一回限りのサイクルを前提として設計されており、検証の頻度や継続性が担保されていません。テスト結果がその場で確認されるだけで、時間経過に伴う検知精度の変化をトラッキングする仕組みが弱いのが実情です。第2の弱点は、脅威コンテキストの不足です。テストケースが汎用的なライブラリから選択されるだけで、自組織を実際に標的としている脅威アクターのTTPsや、業界固有の攻撃トレンドとの紐づけが行われていないケースが多く見られます。結果として「テストには合格したが、本当に危険な攻撃を防げるかはわからない」という状況に陥りがちです。OpenAEVはこれらの弱点を、脅威インテリジェンス連携と継続的検証のアーキテクチャで解消しようとしています。

商用AEVプラットフォームと比較したOpenAEVのオープンソースモデル固有の利点と制約

OpenAEVのオープンソースモデルは、商用AEVプラットフォームと比較した場合にいくつかの明確な利点を持ちます。最大の利点は透明性です。ソースコードが完全に公開されているため、プラットフォームの動作を自ら監査でき、ベンダーロックインのリスクがありません。カスタマイズの自由度も高く、独自のインジェクターやコレクターを開発して自社環境に最適化することが可能です。コスト面でも、CE版は無償で利用できるため、初期投資を抑えた段階的な導入が実現します。一方で制約も存在します。商用製品のような手厚いオンボーディング支援や24時間体制のサポートはCE版には含まれません。また、UIの洗練度やドキュメントの充実度において商用製品に劣る部分がある場合があります。EE版でもSaaS提供やサポートが付帯しますが、グローバル規模のサポート体制は大手商用ベンダーと比べるとまだ発展途上の面があります。自組織のセキュリティチームの技術力とサポート要件を踏まえたうえで、オープンソースモデルの利点を活かせるかどうかを見極めることが重要です。

導入前に確認すべきSOC成熟度レベルとOpenAEV活用効果が出やすい組織の3条件

OpenAEVはすべての組織に等しく効果を発揮するわけではなく、活用効果が出やすい組織にはいくつかの共通条件があります。第1の条件は、EDRやSIEMが既に導入・運用されていることです。OpenAEVはこれらのツールの検知能力を検証するプラットフォームであるため、検証対象となるセキュリティスタックが存在しなければ十分な価値を引き出せません。第2の条件は、SOCチームまたはそれに準じるセキュリティ運用体制が構築されていることです。シミュレーション結果の分析と修復アクションの実行には、専門知識を持つ担当者が継続的に関与する必要があります。第3の条件は、セキュリティ態勢の定量的な可視化に対する経営層のニーズが存在することです。OpenAEVのダッシュボードが生成するスコアは、経営層への報告や投資判断の材料として活用されるときに最も大きな価値を発揮します。これらの条件を満たしていない段階の組織は、まず基盤となるセキュリティスタックの整備とSOC体制の構築を優先すべきです。

PoC期間中に検証すべきシナリオ再現性・EDR連携精度・レポート出力の3評価指標

OpenAEVのPoC（概念実証）を実施する際、評価すべき指標を事前に明確にしておくことが成功の鍵です。第1の評価指標はシナリオ再現性です。同一のシナリオを複数回実行した場合に、結果が一貫しているかどうかを検証します。環境依存の要因でテスト結果がばらつく場合、継続的なベースライン比較が信頼できなくなるためです。第2の評価指標はEDR連携精度です。コレクターが収集したアラートやイベントが、シミュレーションで定義したエクスペクテーションと正しくマッピングされているかを確認します。誤検知や見逃しの割合が高い場合は、コレクターの設定調整やEDR側のログ出力設定の見直しが必要です。第3の評価指標はレポート出力の実用性です。ダッシュボードで確認できる情報が自組織の報告フォーマットに変換しやすいか、経営層向けの要約と技術チーム向けの詳細データの両方が得られるかを評価します。これら3つの指標で合格水準を事前に設定し、PoCの結果を定量的に判断することが推奨されます。

段階的に運用範囲を拡大するための6か月ロードマップと各フェーズの達成基準

OpenAEVの導入を成功させるためには、一度にすべてを展開するのではなく、段階的に運用範囲を拡大するアプローチが有効です。6か月間のロードマップを3つのフェーズで構成します。第1フェーズ（1〜2か月目）は環境構築と初期検証の段階です。Docker Composeによるプラットフォーム構築、エージェントの試験デプロイ（5〜10台）、Starter PackとAtomic Red Teamを使った最初のシミュレーション実行を達成基準とします。第2フェーズ（3〜4か月目）は運用定着の段階です。自組織の脅威プロファイルに基づいたカスタムシナリオの作成、OpenCTIとの連携設定の完了、定期実行スケジュールの確立、SOCチームへの運用手順の引き渡しを目標とします。第3フェーズ（5〜6か月目）は拡張と最適化の段階です。エージェントの展開対象を全重要エンドポイントに拡大し、経営層向けの月次レポートフォーマットを確立し、テーブルトップエクササイズの初回実施を完了させます。各フェーズの達成基準を事前に合意しておくことで、プロジェクトの進捗を客観的に評価できます。