どこから始めようか。Elasticは4年連続で、英国国防省が主催する主力サイバー演習シリーズである「Exercise Defence Cyber Marvel」において、信頼できる業界パートナーとして貢献できるという栄誉に浴しました。DCM26は間違いなくこれまでで最も意欲的な試みであり、私たちが何を作り上げたのか、どのように作ったのか、そしてその過程で何を学んだのかについて、ようやくお話しできることを大変嬉しく思っています。
防衛サイバーマーベルとは何ですか？
ご存知ない方のために説明すると、ディフェンス・サイバー・マーベル（DCM）は、英国最大の軍事サイバー演習シリーズであり、現実的で高圧的なシナリオにおいて、従来のITネットワーク、企業環境、複雑な産業制御システムを防御することに重点を置いています。これは、責任あるサイバー能力を示すとともに、国防および同盟国全体の即応性、相互運用性、および回復力を強化するものである。今年で5年目を迎えるDCMは、陸軍サイバー協会のイニシアチブから、サイバー・特殊作戦司令部（CSOC）が主導する三軍合同作戦へと発展した。
英国政府はDCM26に関する公式プレスリリースを発表し、この演習の戦略的重要性について優れた概要を提供している。シンガポール駐在英国高等弁務官が指摘したように、今回の演習は英国と信頼できるパートナー国との間の緊密な協力関係を示すものであり、ますます複雑化する安全保障情勢において、共通の戦略的パートナーシップが持つ強さを改めて示すものである。
DCMの本質は、実戦形式のサイバー演習である。防御側のブルーチームは、さまざまな技術を用いて、割り当てられたネットワークとインフラストラクチャを攻撃してくるレッドチームから守る。活動内容は、デフォルトパスワードの変更やファイアウォールの強化から、 Elastic Securityを使用したエンタープライズグレードの AI 搭載型サイバー防御の導入まで多岐にわたります。各チームの活動はホワイトチームによって監視され、システムの可用性、攻撃の検出、インシデント報告、システム復旧などを考慮したスコアが算出される。これは、最も経験豊富なチームにとっても能力を試す機会となるだけでなく、サイバーレンジを初めて体験する若手チームにとって独自の訓練メカニズムを提供するものであり、この二重の目的こそがDCMを非常に価値のある演習にしているのです。
DCM26のスケール
DCM26には、 29 カ国と 70 組織から2,500人以上の人員が集まり、シンガポールに拠点を置く中央演習統制センター（EXCON）が調整を行い、EXCONは 600 以上の参加者を受け入れた。この演習は、CR14サイバーレンジとAWSにまたがるハイブリッドコンピューティング環境で実施され、5,000を超える仮想システムが稼働した。
演習自体は5日間（2026年2月9日～13日）にわたって実施され、その前には任意参加の教官主導の事前訓練と接続確認が行われた。国防アカデミー訓練環境（DATE）インド太平洋作戦環境に基づいて構築されたこのシナリオでは、地域危機が激化する中で、各チームが展開中の軍事システムを防衛するサイバー防護チームとして配置されました。ブルーチームは地理的に分散しており、英国国内や海外の本拠地にいるチームもあれば、海外に展開しているチームもあり、全員がVPN経由で訓練場に接続しました。
参加者には、英国国防省、国家犯罪対策庁、労働年金省、内閣府、ビジネス貿易省などの政府横断的な省庁の代表者、および最大 40 チームを編成した国際的なパートナーが含まれていました。昨年韓国で行われた演習の成功を受け、シンガポールが初めて演習拠点として機能した。これは、共通の安全保障上の課題に関して、インド太平洋地域のパートナーとの協力を深めるという英国の決意を示すものである。
つまり、これは真剣な取り組みだ。プレッシャーのかかる、実力者同士の対戦であり、採点結果に重大な影響を及ぼし、参加者全員にとって真の学習成果につながる。
デプロイメント：当社のElasticインフラストラクチャ
今年のインフラは、以前のバージョンから大幅なアーキテクチャ上の進化を遂げた。各チームごとに個別のElastic Cloudクラスターをデプロイするのではなく、ブルーチーム向けに単一のスペースベースのマルチテナント型Elastic Cloudデプロイメントに移行しました。私たちは、ブルーチーム以外の機能についても展開サービスを提供しました。それぞれの導入事例と、それがなぜ存在するのかを詳しく説明しましょう。
ブルーチーム：マルチテナント型Elastic Security
私たちの貢献の中心は、Kibana Spacesとデータストリーム名前空間を使用して分離された、 40 防御側のブルーチームすべてにサービスを提供する単一のElastic Cloudデプロイメントでした。 39 の各チームは、ダッシュボード、エージェント、検出ルールなどを含む、それぞれ独立したワークスペースを持っていた。
各チームのスペースを作成するために使用したTerraformリソースは以下のとおりです。
# Create 40 Blue Team spaces
resource "elasticstack_kibana_space" "blue_team" {
count = var.team_count
space_id = local.space_ids[count.index]
name = "Blue Team ${local.team_numbers[count.index]}"
description = "Isolated space for BT-${local.team_numbers[count.index]} with space-aware Fleet visibility"
disabled_features = []
color = "#0077CC"
}各チームのスペースには、専用の3つのFleetエージェントポリシーが割り当てられました。1日目には展開済みネットワークポリシー、2日目にはホスト国のネットワークポリシー、そして最後にネットワークトラフィック監視用のPacketCaptureポリシーです。段階的なアクセス制御は、そのシンプルさにおいて洗練されていました。 terraform.tfvarsでenable_hostnation_network = trueを設定し、 terraform applyを実行することで、各チームの役割権限が拡張され、ホスト国のエージェントポリシーが彼らのスペースに表示されるようになりました。この演習では、Kibanaで手動クリックを一切行うことなく、ネットワークを1つから2つに拡張することができました。
データ分離はデータストリームの名前空間に依存していた。各エージェントポリシーは、 bt_01_deployedやbt_01_hostnationのようなチーム固有の名前空間に書き込まれ、次のパターンに従うデータストリームを生成します。
logs-system.auth-bt_01_hostnation
logs-system.syslog-bt_01_hostnation
metrics-system.cpu-bt_01_hostnation
logs-endpoint.events.process-bt_01_hostnation
logs-windows.forwarded-bt_01_hostnation
logs-auditd.log-bt_01_hostnation各チームのKibanaセキュリティロールは、動的インデックス権限ブロックを使用して、特定のデータストリームのみに限定されました。
# Deployed data streams (always granted)
indices {
names = [
"logs-*-${local.deployed_namespaces[count.index]}",
"metrics-*-${local.deployed_namespaces[count.index]}",
".fleet-*"
]
privileges = ["read", "view_index_metadata"]
}
# HostNation data streams (conditional on enable_hostnation_network)
dynamic "indices" {
for_each = var.enable_hostnation_network ? [1] : []
content {
names = [
"logs-*-${local.hostnation_namespaces[count.index]}",
"metrics-*-${local.hostnation_namespaces[count.index]}"
]
privileges = ["read", "view_index_metadata"]
}
}認証はKeycloak SSOを介して行われ、ElasticsearchのロールマッピングによってKeycloakグループとKibanaロールが接続されました。
resource "elasticstack_elasticsearch_security_role_mapping" "blue_team" {
count = var.team_count
name = "bt-${local.team_numbers[count.index]}-keycloak-mapping"
enabled = true
roles = [
elasticstack_kibana_security_role.blue_team[count.index].name
]
rules = jsonencode({
field = {
groups = "${local.keycloak_groups[count.index]}"
}
})
}デフォルトの統合ポリシーは、意図的にシンプルな設計になっていました。各チームには、コアOSテレメトリ用のシステム、エンドポイント検出および対応用のElastic Defend、Windowsイベント転送、Linux監査ログ用のAuditd、およびネットワークパケットキャプチャ統合が提供されました。これは、 Elastic Stack Terraform Providerを介してコードとして管理される 400 超える統合ポリシーです。
Elastic Defend に関する注記: Elastic のエンドポイント保護は、米国国防総省や情報機関が本番環境で信頼して使用しているほど効果的であり（詳細はこちらをご覧ください）、また、訓練演習でゼロデイ攻撃を仕掛けるような正気な人間はいないという事実から、Elastic Defend の保護モードを無効にして検出専用モードにすることで、Elastic Defend の機能を制限せざるを得ません。悪意のある事象が発生した場合、チームはアラートを受け取りますが、自動的な対策は講じられません。また、メモリ脅威防止・検出機能を完全に無効化します。これは、攻撃側のインプラントやビーコンの大部分を検出してしまうため、レッドチームにとってゲームを台無しにしてしまうからです。演習の終盤では、レッドチームが確固たる足場を築く前に、各チームにElastic Defendの機能を最大限に活用する自由を与えた。
また、各チームスペースには、Elastic Security Labsが提供する、オープンリポジトリで継続的に更新されるElasticの事前構築済み検出ルール一式をプリインストールしました。これらのルールは、チームの名前空間スコープの権限で許可されているインデックスのみを照会するように設定されており、検出ルールの実行時にチーム間でデータが漏洩するのを防ぎます。
さらに、各チームスペースのセキュリティソリューションのデフォルトインデックスは、デフォルトの広範なパターンではなく、そのチームのデータストリームのみに検出ルールを限定するように構成されていました。これは、Kibanaの内部設定APIを呼び出して各スペースにsecuritySolution:defaultIndexを設定するTerraform null_resourceによって処理されました。
ピーク時には、このデプロイメントはすべての 40 チームで毎秒80万イベント（EPS）を取り込んでいました。これは相当な量のデータですが、Elastic Cloudの自動スケーリング機能のおかげで、クラスターは難なく処理できました。そうは言っても、 2018 時点では、eBayで毎秒 5 百万件のイベントを処理していました。
データライフサイクルは、インデックスライフサイクル管理（ILM）ポリシーによって管理され、インデックスは1日または50 （どちらか早い方）後にロールオーバーされ、2日後に読み取り専用の最適化と強制マージのためにウォームフェーズに移行され、その後10日後にデータが削除されました。その結果、運動期間の要件を維持しながら、保管コストを最小限に抑えることができた。以下に、ILMポリシーがどのように実施されたかの例を示します。
resource "elasticstack_elasticsearch_index_lifecycle" "dcm5_10day_retention" {
name = "dcm5-10day-retention"
hot {
min_age = "0ms"
set_priority {
priority = 100
}
rollover {
max_age = "1d"
max_primary_shard_size = "50gb"
}
}
warm {
min_age = "2d"
set_priority {
priority = 50
}
readonly {}
forcemerge {
max_num_segments = 1
}
}
delete {
min_age = "${var.data_retention_days}d"
delete {
delete_searchable_snapshot = true
}
}
}シャードのストレステスト：大規模マルチテナンシーの実証
実際の軍事演習にこのアーキテクチャを採用する前に、それが我々の要件を満たし、問題が発生した場合に適切なフェイルオーバー機能が備わっていることを証明する必要がありました。個別のデプロイメントから単一のマルチテナントクラスターへの移行は、リソースの競合、データ取り込みのボトルネック、設定ミスによるスペース間のデータ漏洩、Elasticsearchノード上のTCP接続数の増加、各チームが独自のインデックスセットを生成するためシャード数が大幅に増加するなど、実際のリスクをもたらしました。
そこで、専用のテスト装置を構築しました。計画は単純明快だった。 50 Kibana Spacesをデプロイし、各スペースにエージェントポリシーを作成し、6,000個のEC2インスタンス（テナントごとに120個、3つのアベイラビリティゾーンの6つのサブネットに分散）を起動し、全体をロードテストする。私たちはAutoOpsとStack Monitoringを使ってすべてを監視しました。
デプロイの流れは次のようになります。Terraform は 3 つのアベイラビリティ ゾーンにわたって VPC とサブネットを作成し、 50 Kibana Spaces とそれらのスペース スコープの Fleet ポリシーをプロビジョニングし、登録トークンを生成し、その後 EC2 インスタンスをバッチで起動します。各インスタンスは起動時にElastic Agentをインストールし、それぞれのスペース固有のトークンを使用して登録を行った。
その過程で、いくつかの興味深い課題に直面しました。当時、標準のElastic Stack Terraformプロバイダーはスペースを考慮したFleet操作をサポートしていなかったため、それをフォークしてFleetリソースにスペースIDの処理を追加しました。この変更がなければ、ポリシーの割り当てに関係なく、すべてのエージェントがデフォルトのスペースに登録されてしまうところでした。演習のためにプロバイダーを拡張する必要があったのは今回が初めてではなかった。2年前のDCM2では、 elasticsearch_cluster_infoデータソースを追加した。幸いなことに、上流のプロバイダーはその後、バージョン0.12.2でsupport for space_idsを追加しました。
また、6,000 個のインスタンスすべてを同時に起動しようとした際に AWS EC2 API のレート制限に遭遇したため、 500 のインスタンスでデプロイをバッチ処理し、バッチ間に 5 分間のクールダウン期間を設けました。
結果は安心できるものだった。6,000人のエージェント全員は、通常、配備後 20 分以内に登録されました。我々のテストでは、スペース分離は期待どおりに機能し、テナント間でのデータ漏洩は確認されませんでした。艦隊ポリシーの更新は、 60 秒以内にすべてのエージェントに反映されました。個々のスペースを対象とした検索クエリは、負荷が最大に達した場合でも高速に動作しました。また、マルチAZ構成は、シミュレーションされた可用性ゾーン障害発生時にも高い回復力を発揮した。
このテストのおかげで、本番演習に向けてこのアーキテクチャを採用することに自信を持つことができました。
レッドチーム：C2インプラントの可視性
レッドチーム向けには、コマンド＆コントロール（C2）インプラントの可視性に重点を置いた、専用のElasticデプロイメントが別途構築された。これにより、攻撃チームは、ブルーチームのデータとの混入リスクなしに、インプラントの状態、ビーコンのコールバック、作戦の進捗状況など、自らの作戦状況を把握することができた。レッドチームはC2としてTuoniを使用しました。Tuoniは、Clarified Securityがレッドチーム演習のために開発したフレームワークです。DCM3では、Clarified Securityと協力してElastic Common Schemaを適切にサポートするようにしました。これにより、将来のElasticとの統合がはるかに容易になります。
NSOC：ネットワークセキュリティオペレーションセンター演習
中核となる演習であるネットワークセキュリティオペレーションセンター（NSOC）は、独自のElasticデプロイメント上で稼働し、演習統制スタッフに、レンジ全体の健全性、インフラストラクチャ全体にわたるセキュリティ監視、そして重要な点として、展開したすべてのAIサービスの監査ログを包括的に把握できるようにしました。このデプロイメントでは、すべてのBedrock API 呼び出しが CloudWatch にログ記録され、監視可能であったため、NSOC は AI エージェントに何が要求されているか、そして誰が要求しているかを完全に把握することができました。これについては、下記のAIセクションで詳しく説明します。
インフラストラクチャの自動化：TerraformとCatapult
上記でご紹介した内容はすべて、Infrastructure as Code（IaC）として管理されたものです。私たちが構築していたプロバイダーエコシステムの概要は、 provider.tfで確認できます。
terraform {
required_version = ">= 1.5"
required_providers {
elasticstack = {
source = "elastic/elasticstack"
version = "~> 0.13.1"
}
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
vault = {
source = "hashicorp/vault"
version = "~> 3.20"
}
cloudflare = {
source = "cloudflare/cloudflare"
version = "~> 5.15.0"
}
}
backend "s3" {
bucket = "elastic-terraform-state-dcm5"
key = "prod/terraform.tfstate"
region = "eu-west-2"
encrypt = true
}
}Terraform によって管理されるリソースの総フットプリントは相当なものでした。自動スケーリング付きの Elastic Cloud デプロイメント 1 つ、 40 Kibana スペース、 120 Fleet エージェント ポリシー (チームごとに 3 つ)、400 を超える統合ポリシー、 40 Kibana セキュリティ ロール、 40 Keycloak ロール マッピング、データ保持のための ILM ポリシー、 41 Bedrock GenAI コネクタ用の AWS IAM ユーザー (チーム スペースごとに 1 つとデフォルト)、 41 Kibana GenAI アクション コネクタ、AWS Bedrock ガードレール、Tines アクセス用の Cloudflare Zero Trust トンネル、チーム スペースごとの Tines アクション コネクタ、HashiCorp Vault に保存されている検出サービス アカウント、およびスペースごとの Security Solution デフォルト インデックス構成。すべての状態データは暗号化されたS3バックエンドに保存されました。
エージェントとプロキシを実際のレンジシステムに展開するために、Clarified Securityのチームが開発した優れたオープンソースツールであるCatapultを使用しました。Catapultは、サイバーレンジのデプロイメント専用に構築されたコンテナベースの実行モデルでAnsibleをラップします。これにより、インフラストラクチャ全体にわたるElastic Agentのインストールと登録が処理されました。プロキシサーバーの構成（各チームは展開されたネットワーク用に専用のSquidプロキシを持っており、これは現実世界と同じように単一の出口ポイントをシミュレートするためでした。トラフィックはhttp://elastic-proxy.dsoc.XX.dcm.ex:3128などのエンドポイントを経由してルーティングされ、Tines接続のためにCloudflareトンネルが展開されました。
プロビジョニング中に、TerraformによってHashiCorp Vaultに書き込まれ、Catapultによって利用された以下のデータ：認証情報、登録トークン、APIキー、プロキシ構成、Tinesサービスアカウント認証情報。Vault のパスはdcm/gt/elastic/prod/enrollment_tokens/BT-XX-Deployedやdcm/gt/elastic/tines-sa/tines-sa-btXXのような一貫した構造に従っていたため、Catapult のプレイブックが各チームの適切な認証情報を簡単に取得することができました。
トレーニング：チームを成功に導くための準備
プラットフォームを導入することと、人々が実際にそれを利用できるようにすることは全く別の問題だ。演習前の段階で、ブルーチームに対し、射撃場でのインストラクター主導の訓練を提供しました。この研修では、 Elastic Securityの基本、Kibanaのチームスペースの操作方法、事前構築済みの検出ルールの使い方、ログ分析と脅威ハンティングのためのDiscoverの使用方法、カスタムダッシュボードの構築方法、Elastic Defendアラートの理解、およびTimeline調査ツールの使い方について説明しました。
演習指示書自体には、この訓練は任意だが「強く推奨」と記載されており、我々が目にした限りでは、参加したチームは実行初日からまさに順調に活動を開始していた。トレーニングと活用支援は、技術導入そのものと同じくらい重要です。使い方がわからないエンタープライズグレードのセキュリティツールをチームに渡しても、誰にとっても何の役にも立たなかっただろう。
オンレンジAIサービス：法令遵守、監査済み、安全対策済み
今年は、DCMシリーズへのAIアクセス機能の提供を開始した年となりました。当社は、英国に拠点を置くAWS Bedrockモデル（具体的には、eu-west-2（ロンドン）リージョンで稼働するClaude 3.7 Sonnet）を基盤として、規制に準拠したAIサービスをレンジ上で直接提供しました。これは、AIのためのAIではなく、ガードレール、完全な監査ログ、RBAC（ロールベースアクセス制御）に対応したアクセス制御を備えた、綿密に設計されたサービスだった。Elastic社がAI分野で豊富な経験を有していたため、当社がこのサービスの運営を任されることになりました。
そのAIサービスには複数の利用者がおり、これは重要な違いである。各チームのスペースにプロビジョニングした準拠したBedrockコネクタは、カスタムエージェントを動かすだけでなく、ElasticのネイティブAI機能も動かしていました。具体的には以下のとおりです。
Elastic AI Assistant for Security
Elastic AI Assistantは、ブルーチームのすべてのスペースに設置され、射程内のBedrockコネクタに接続されていました。これにより、チームはElastic Security内に直接、状況に応じたチャットインターフェースを利用できるようになり、アラートに関する質問をしたり、ES|QLクエリの作成に関するヘルプを受けたり、疑わしいプロセスを調査したり、修復手順のガイドを入手したりすることができた。AIアシスタントは、Elasticのナレッジベース機能とRetrieval-Augmented Generation（RAG）を使用しており、 Elastic Security Labsの記事があらかじめ入力されています。チームは、射程範囲固有の標準作業手順書（SOP）、脅威情報、チームメモなどの独自の文書をナレッジベースに追加することで、アシスタントの応答を運用状況にさらに即したものにすることもできます。
演習の文脈においてこれが特に価値があったのは、AIアシスタントが経験の浅いアナリストが何を見ているのかを理解するのを支援できた点である。初めて実際の埋め込み型ビーコンに遭遇した若手アナリストは、アシスタントにアラートの説明を求めたり、調査手順を提案させたり、さらにはインシデントレポートの作成を手伝ってもらったりすることができる。データ匿名化設定により、機密性の高いフィールド値はLLMプロバイダーに送信される前に難読化されることが保証された。
エラスティックアタックディスカバリー
攻撃発見部門も、当社の射程内AIサービスの重要な顧客の一つでした。攻撃検出は、LLM（論理レベルモデル）を使用してチームの環境におけるアラートを分析し、アラート、挙動、攻撃経路を関連付けることで脅威を特定します。それぞれの「発見」は潜在的な攻撃を表し、複数のアラート間の関係性を記述します。これにより、どのユーザーとホストが関与しているか、アラートがMITRE ATT&CKマトリックスにどのように対応しているか、そしてどの脅威アクターが責任者である可能性があるかがチームに示されます。
レッドチームが積極的に連携攻撃を仕掛けるサイバー演習において、攻撃検出ツールは画期的なツールとなった。ブルーチームは、数百件もの個別の警告を手動でトリアージする代わりに、攻撃発見を実行して、例えば「これらの 15 警告はすべて、おそらく脅威アクターZによるホストXからホストYへの横方向の移動チェーンの一部である」といった高レベルの攻撃シナリオを明らかにし、最も重要な部分に調査時間を集中させることができます。これは、平均応答時間を直接短縮し、警戒疲労を軽減する能力であり、5日間連続で継続的な攻撃を受けている状況ではまさに必要なものです。
カスタムAIエージェント：Elastic Agent Builder
Elastic AIのネイティブ機能に加え、 Elastic Agent Builderを使用して3つのカスタムAIエージェントを構築しました。Agent Builderは、Elasticが提供するカスタムAIエージェント構築のためのフレームワークです。LLM命令とモジュール式で再利用可能なツールを組み合わせたもので、各ツールはES|QLクエリ、組み込みの検索機能、ワークフロー実行、またはMCPを介した外部統合のいずれかです。エージェントは自然言語によるリクエストを解析し、適切なツールを選択して実行し、完全な回答を提供できるまでこのプロセスを繰り返します。その際、Elasticsearch内のデータを用いてコンテキストを管理します。フレームワークの詳細については、 Agent BuilderのドキュメントとElasticsearch Labsの詳細解説をご覧ください。
私たちが活用したAgent Builderの3つの主要コンポーネントは以下のとおりです。
エージェント：エージェントのペルソナ、能力、および行動範囲を定義する、カスタマイズされたLLM指示と割り当てられたツールセット。各エージェントには、その任務、アクセスできるツール、および応答の構造を制御するシステムプロンプトが備わっています。
ツール：エージェントがElasticsearchデータを検索、取得、操作するために使用するモジュール式の関数。私たちは、演習ドキュメント、プレイブック、レポートを含む特定のインデックスを照会するカスタムES|QLツールを構築しました。
エージェントチャット：参加者がエージェントとやり取りするために使用する、会話型インターフェース（Kibanaに組み込まれたUIとプログラムによるAPIの両方）。
エージェントとツールの設定はJSON形式で定義され、Agent Builder APIを介して管理されるため、プロンプトの設計からツールのバインディングまで、エージェントのライフサイクル全体が再現可能でバージョン管理も容易になります。このアプローチを再現したい方のために、GrantPTエージェントの設定とツールの定義を後日別の記事で公開しますので、ご期待ください。
各エージェントが行ったことは以下のとおりです。
1. GrantPT - 汎用アシスタント
約2,500名の演習参加者全員が利用できるGrantPTは、私たちの主要なAIエージェントであり、Agent Builderがいかに簡単に有能なドメイン特化型アシスタントを構築できるかを示す最良の例でした。エージェントの設定は、システムプロンプト、ペルソナ、およびバインドされたツールIDの配列を定義するJSONオブジェクトで構成されていた。それだけだ。カスタムアプリケーションコードも、専用のAPIレイヤーも不要。宣言的な設定だけで済みます。
GrantPTに深みを与えていたのは、そのツール群だった。私たちは、組み込みのプラットフォームツールとカスタムES|QLツールを組み合わせた構成を定義しました。それぞれのツールには、説明、パラメータ化されたクエリ、および型付きパラメータ定義が登録されています。例えば、知識ベースツールはtarget_indexと意味パラメータqueryを受け取り、意味検索ランキングを使用して、 dcm5-grantpt-*インデックスに対してパラメータ化されたES|QLクエリを実行します。
FROM dcm5-grantpt-* METADATA _score, _index
| WHERE _index == ?target_index
| WHERE content: ?query
| SORT _score DESC
| LIMIT 10別途用意されたインデックス検出ツールにより、エージェントは各会話の開始時に利用可能な知識ベースインデックスを動的に列挙することができました。つまり、エージェントを再構成することなく、演習中に新しいドキュメントインデックスを追加することができました。エージェントは次のやり取りでそれらを自動的に検出します。
また、取り込まれたヘルプデスクチケット全体にわたって意味検索を実行するJira連携ツールも構築しました。これにより、GrantPTは過去のサポートリクエストから関連するトラブルシューティングのコンテキストを表示できるようになりました。これは特にヘルプデスクのアナリストにとって非常に役立ちました。彼らはGrantPTに繰り返し発生する問題について質問し、一般的なガイダンスではなく、実際のチケット履歴に基づいた回答を得ることができたからです。
RBACに合わせた応答動作は、ユーザーの役割に基づいて回答を文脈化するようにエージェントに指示するエージェントのシステムプロンプトと、基盤となるElasticsearchのセキュリティモデルの組み合わせによって実現された。各ツールのES|QLクエリはユーザーのセキュリティコンテキスト内で実行されるため、エージェントはユーザーの役割でアクセス可能なドキュメントのみを表示できます。演習手順について問い合わせたブルーチームのメンバーは、所属チームがアクセスできるインデックスに絞られた結果を受け取る一方、ヘルプデスクアナリストはヘルプデスク固有のインデックスからの結果を見ることになる。エージェントには明示的な役割切り替えロジックは必要ありませんでした。Elasticsearchのネイティブなドキュメントレベルのセキュリティがスコープを処理し、エージェントは返された結果をそのまま処理するだけでした。これは、Agent Builderを真に洗練されたものにしている要素の一つです。Elasticsearchのセキュリティモデルを継承することで、認証コードを一行も記述することなく、RBAC（ロールベースアクセス制御）に対応したAIを実現できます。
2. REDRock - 敵の仲間
このエージェントはレッドチーム専用でした。REDRockも同様のエージェントビルダーのパターンを採用しており、専用のシステムプロンプトで敵対的なペルソナを定義し、独自のカスタムES|QLツールセットに紐づけて、レッドチーム固有のインデックスを照会する仕組みになっている。これらのインデックスには、レッドチームのプレイブック、Tuoni C2のドキュメント、対象環境内の既知のシステム脆弱性、および展開されたサービスに関する情報が含まれていました。ツール定義はGrantPTで使用されているものと同じパラメータ化されたセマンティック検索パターンを反映していたが、レッドチームの役割を持つユーザーのみがアクセスできるインデックスに限定されていた。レッドチームのオペレーターは、攻撃経路を照会したり、標的システムの既知の脆弱性を確認したり、作戦計画に関する状況に応じたガイダンスを入手したりすることができる。率直に言って、それは攻撃者に極めて詳細な作戦指示を与えた作戦担当官を与えるようなものだった。
3. RefPT - 審判のツール
RefPTは、ホワイトチーム（演習の審判員および評価者）向けに特別に構築され、ブルーチームの報告書、シナリオイベント、および採点基準を含むインデックスを照会するツールと連携するように設計されていた。その目的は、40以上の全チームにおいて、均一かつ公平な採点を保証することであった。エージェントのシステムプロンプトは、提出されたレポートを既知のシナリオイベントや採点基準と照合するように調整されており、評価者が矛盾点や不足点を特定するのに役立つ。評価担当者が同時に数十ものチームを評価する場合、報告書を構造化された採点指標と照合できるAIがあれば、一貫性の確保という点で真に革新的な効果を発揮します。
Tines：AIを活用したワークフロー自動化
タインズ氏もまた、射撃場内AIサービスの利用者だった。各ブルーチームには専用のTinesインスタンスが割り当てられ、TinesアクションコネクタはそれぞれのKibanaスペースにプロビジョニングされていた。Tinesは、Bedrockが支援するAI機能を活用して、自動化されたアラートの強化、AIによるトリアージ判断、通知ワークフローにおける自然言語による要約、自然言語によるワークフロー作成など、インテリジェントなワークフロー自動化を実現できる。Tinesコネクタは、Vaultに保存された認証情報を使用してチームごとに構成されました。
resource "elasticstack_kibana_action_connector" "tines_bt" {
count = var.team_count
name = "BT-${local.team_numbers[count.index]}-Tines"
connector_type_id = ".tines"
space_id = local.space_ids[count.index]
config = jsonencode({
url = "https://tines.dsoc.${local.team_numbers[count.index]}.dcm.ex/"
})
}コンプライアンスの確保：ガードレールと監査
これら全ての顧客とのAIによるやり取りは、厳格なAWS Bedrock Guardrailsによって管理されていました。コンテンツフィルタリング（ヘイトスピーチ、侮辱、性的コンテンツ、暴力を中程度の閾値でフィルタリング）、個人情報保護（メールアドレス、電話番号、氏名、住所、英国国民保険番号、クレジットカード番号、IPアドレスをブロック）、実際の機密作戦に関する議論を防止するためのトピックベースのフィルタリング、および不適切な言葉のフィルタリングといったガードレールを導入しました。以下は、Terraformで作成したガードレール設定の一部です。
resource "aws_bedrock_guardrail" "dcm5_elastic" {
name = "dcm5-prod-elastic-guardrail"
description = "Guardrails for DCM5 Prod Elastic Kibana GenAI connectors"
content_policy_config {
filters_config {
input_strength = "MEDIUM"
output_strength = "MEDIUM"
type = "HATE"
}
# ... additional content filters for INSULTS, SEXUAL, VIOLENCE
}
sensitive_information_policy_config {
pii_entities_config {
action = "BLOCK"
type = "UK_NATIONAL_INSURANCE_NUMBER"
}
pii_entities_config {
action = "BLOCK"
type = "IP_ADDRESS"
}
# ... additional PII filters
}
topic_policy_config {
topics_config {
name = "classified-information"
definition = "Discussions about actual classified operations, current real-world military activities, or operational intelligence."
type = "DENY"
}
}
}各ブルーチームのスペースには、Bedrockへのアクセス用に独自のIAMユーザーが割り当てられており、チームが独自のコネクタを設定できないように、 genAiSettings:defaultAIConnectorOnly Kibana設定が適用されていました。これは、CloudWatchを通じてすべてのAPI呼び出しを特定のチームまで追跡できることを意味し、NSOCは完全な監査可視性を確保できた。CloudWatchロググループ/aws/bedrock/grantpt-prod/invocationsは、すべての呼び出しとガードレールイベントをキャプチャしました。
AI 利用者全体の数字を見れば一目瞭然です。カスタム AI エージェントは 3 、会話数は 2,797 件、そして演習全体で消費された AI トークンは 785 百万個です。
ゲーム内リアルタイムモニタリング
演習シナリオにおいて、各チームは演習場内でのメッセージングクライアントとしてRocketChatを利用することができた。各ブルーチームには専用のチャンネルが与えられ、演習参加者全員に直接メッセージを送信できる機能と、必要に応じて新しいチャンネルを自由に作成できる機能が与えられた。DCMの伝統において最も重要なのは、ミームチャンネルの存在だった。これは、チーム間のあらゆる冗談や、数千人のサイバーオペレーターを1週間プレッシャーにさらしたときに必然的に生まれる、創造的な士気を高めるユーモアの精神的な支柱だった。
これらの通信データはすべて、演習場の健全性、チームの士気、そして演習全体で話題になっているトピックをリアルタイムで把握するための素晴らしい窓口となった。これは見逃すには惜しい機会だと感じたので、RocketChatの会話データ全体をリアルタイムでElasticに取り込み、活用することにした。
感情分析と固有表現認識
固有表現認識のために、Hugging Faceのdslim/bert-base-NERモデルをElastic ELANDクライアントを使用してNSOCデプロイメント上の機械学習ノードにデプロイしました。これはその後、Elasticsearchの取り込みパイプラインに接続され、RocketChatのすべてのメッセージは取り込み時にこのパイプラインを通過するようになった。抽出したエンティティの中から、最も頻繁に出現するものをダッシュボードのテーマとして表示することで、演習全体を通して会話トピックの盛衰をリアルタイムで把握できるようにしました。
また、グループ活動、ユーザー統計、一般的なコミュニケーションパターンを分析し、各チームの活動パターン（最も活発な参加者、時間の経過に伴うメッセージ量、個々のユーザーを中心とした感情傾向など）を把握しました。総合的に見て、それは射撃場で何が起こっているのかをほぼリアルタイムで把握する上で、非常に興味深い洞察を与えてくれた。例えば、Elastic AgentをPreventモードに切り替えたところ、ダッシュボード上のワードクラウドに「Elastic」がすべてのチャネルで最も話題になっているテーマとしてすぐに表示されました。ブルーチームはその有効性について議論し、レッドチームはビーコンを失ったことを嘆いていました。それはなかなか満足のいくことだ。
ミーム分析（本当に！）
最後に、そしてこれは少々驚きをもって受け止められたのですが、各チャンネルに投稿されたすべてのミームを収集し、画像をベクトル化し、最近傍法を用いて類似のミームやトピックをグループ化しました。また、各ミームの内容に関するテーマ別の説明を生成するために、それらをゼロショットNER推論モデルに通しました。その論理は、これらの出力が後々、フィルタリング、モデレーション、あるいはその他のゲーム内インタラクションに役立つ可能性があるというものだった。ミーム分析が作戦上重要な情報をもたらしたかどうかは議論の余地がある。それが楽しかったかどうかは問題ではない。
問題を未然に防ぐ
演習週間中はすべてが順調に進むことを願っていましたが、どうしても故障が発生したり、十分に理解されなかったり、特定のチームがどのように使用したいかに合わせてさらにカスタマイズする必要が生じたりします。このため、私たちは対応範囲内のヘルプデスク内に専用のセクションを設け、どのチームでもElasticおよびGenAI固有のリクエストをそこで受け付けられるようにしました。
私たちは演習期間中ずっとこのヘルプデスクを担当し、ガイダンス、ドキュメントの提供、問題のデバッグ、および範囲に応じた推奨事項を提供しました。最後の点については、もう少し詳しく説明する価値がある。時として、ブルーチームがElastic上で確認していた問題は、実際にはElasticの問題ではなく、Elasticがレンジ上でさらなる調査を必要とする何らかの事象を忠実に表示していただけだった（レッドチームはとんでもない混乱を引き起こすことがあり、テレメトリは嘘をつかない）。今回の演習を通して、Elastic社に支援を求めたチームからの個別のサポート依頼を 125 処理しました。
Tines を使用した事前デバッグ
私たちは、ビデオ会議システム（VTC）やEXCON会場での直接の訪問以外にも、 Tines社と協力して、もう少し積極的なアプローチを試みました。受信したリクエストからチケット本文を抽出し、問題の分類を試み、過去に解決されたチケットのデータセットに対してその分類を実行し、トリアージによってキューに送られる前にユーザーの問題を解決することを目的とした要約された最初の回答をGenAIに生成させました。
これは実は、 Elastic社内のサポート組織から拝借したパターンです。Elastic社では、過去に解決された問題の膨大なナレッジベースをリポジトリとして活用し、AIエージェントのコンテキストをサポートすることで、同様の機能を提供しています。その考え方は単純明快だ。過去の解決策を利用して、機械が生成した情報に基づいた問題解決の第一段階を行い、サポートエンジニアがすべてのチケットを手動で処理する必要性をなくす。全てが解決したわけではありません。一部の問題には、状況を把握できる人間の対応がどうしても必要でしたが、キューの負荷を大幅に軽減し、必要なチームに迅速な回答を提供することができました。これは、我々が抱える特定のチケットやキューに対して非常に大きな成功を収めたため、演習の後半では、その範囲をヘルプデスク全体に拡大し、演習を支援するグリーンチームの他のグループの負担軽減に役立てました。
業界パートナーシップ：共に力を合わせることで、より良い未来が生まれる
私たちが最も誇りに思っていることの一つは、パートナーシップのエコシステムが年々成長していることです。DCMは単なるElasticのイベントではなく、業界パートナー各社がセキュリティプラットフォームに独自の価値をもたらす、真の意味での連携イベントです。
1 年（DCM2） - Elasticが業界パートナーとして参加し、セキュリティ監視およびエンドポイント検出プラットフォームを提供開始。
2 年 (DCM3) - Endaceを導入し、1対1のパケットキャプチャ機能を提供しました。Elasticのネットワーク可視化機能とフルパケットキャプチャを組み合わせることで、ログベースの分析だけでは不可能な、詳細なフォレンジック調査をチームが実施できるようになりました。
3 年 (DCM4) - Tinesがファミリーに加わり、ワークフローの自動化をもたらしました。ブルーチームは、Tinesネイティブコネクタを介してElastic環境に直接統合された、自動対応プレイブック、トリアージワークフロー、通知チェーンを構築できるようになりました。
4 年（DCM26、旧DCM5） - AWSが参加し、AIエージェントにBedrockへのアクセスを提供するとともに、Elasticの導入に向けた資金提供を行いました。これは重要な節目でした。ハイパースケーラーがこの取り組みの成功に直接投資したことで、（完全なガードレールと監査ログを備えた、英国を拠点とする準拠したAI推論など）そうでなければ実現不可能だった機能が解き放たれたのです。Tinesの今年の統合は、LLMへの射撃場内アクセスが追加されたことによっても強化された。DCMシリーズも今年、大きな節目を迎えた。陸軍サイバー協会のイニシアチブとして始まったものが、サイバー・特殊作戦司令部の下で正式に資金提供されるプログラムへと移行したのだ。
Endace、Tines、そしてAWSのチームの皆様に心から感謝申し上げます。皆さんの貢献のおかげで、この演習はより良いものになりました。そして、私たちが共に構築したプラットフォームのおかげで、すべてのチームがより良い準備を整えることができました。私たちはすでにDCM27の計画を進めています。皆さん、おめでとうございます。
文化、見どころ、そして価値ある体験となる要素
チャレンジコイン
DCM26のために特製のチャレンジコインを鋳造しました。ご存知の方ならお分かりでしょうが、チャレンジコインは長年にわたる軍隊の伝統であり、今回の演習のためにチャレンジコインを作ることは、我々が参加して4年目を迎えるにふさわしい方法だと感じました。
カクテルパーティー
また、シンガポール駐在英国高等弁務官主催の高等弁務官事務所のカクテルパーティーにご招待いただき、大変光栄でした。大使の招待でジン・トニックを片手に、Elasticsearchのシャード数やTerraformの状態管理について議論するというのは、何とも非現実的な体験だ。それは素晴らしい夜だった。こうした演習が技術と外交の交差点に位置し、ここで築かれる関係が技術的な領域をはるかに超えるものであることを改めて実感させられた。
Wrapping up
マルチテナントアーキテクチャは、継続的な負荷の下でその性能を証明しました。ネイティブのElastic AI機能（ AIアシスタントと攻撃検出）は、数年前にはSFの世界の話だったような機能をチームにもたらしました。そして、カスタムAIエージェントは、導入率において私たちの予想をはるかに上回りました。パートナーシップモデルは、防衛演習への産業界の関与が、どの単一組織も単独では達成できない成果を生み出すことを引き続き実証している。
防衛サイバーマーベル 2026 は、野心、複雑さ、そして影響力において成長を続ける演習の画期的な事例でした。Elasticにとって、 29 カ国の 40 ブルーチームにコアとなる防御セキュリティプラットフォームを提供するという信頼、そして今年はAI機能の提供も任されたことは、決して軽視できることではありません。この訓練は、将来実際のネットワークを守ることになる人々にとって、実践的なスキルを身につけるためのものであり、その任務に参加することは非常に意義深い。
英国政府のプレスリリースにあるように、DCMは国際的なパートナーシップを強化する現実的なシナリオの実践的な価値を示している。全く同感です。
来年もまた来ます。その時は、もっとたくさんの話をする機会があると思います。その間、私たちは製品の改良を続け、Defence Cyber Marvelのような環境へのサポートが年々向上するように努めていきます。
射撃場で会いましょう。
DCM26の最新情報はソーシャルメディアでチェック！
参考資料
弾力的なセキュリティとAI
- Elastic Security - ブルーチームの展開を支えるプラットフォーム
- セキュリティ向けAIアシスタント- Elastic Security内のコンテキスト認識型AIチャット
- 攻撃検出- LLMを活用したアラート相関と脅威シナリオ生成
- Agent Builder - Elasticsearchを使用してカスタムAIエージェントを構築するためのフレームワーク
インフラストラクチャとツール
- Elastic Stack Terraform プロバイダー- Elastic Stack 用のインフラストラクチャ・アズ・コード
- Elastic Fleet ガイド- 大規模な Elastic Agent を一元管理する
- Clarified Security社のCatapult - Ansibleベースのサイバーレンジプロビジョニング
演習の背景
- 英国政府DCM26プレスリリース- 演習の公式概要