Defence Cyber Marvel 2026におけるElastic：演習現場からの技術的概要

James Garside — Thu, 09 Apr 2026 00:00:00 GMT

概略の説明から始めましょう。Elasticは4年連続で、英国国防省が主催する主力サイバー演習シリーズ「Exercise Defence Cyber Marvel」において、信頼できる業界パートナーとして貢献するという栄誉に浴しました。DCM26は間違いなくこれまでで最も意欲的な取り組みであり、当社が何を構築したのか、どのように構築したのか、そしてその過程で何を得たのかについて、ついにご紹介できることを大変嬉しく思います。

Defence Cyber Marvelとは？

ご存じない方のために説明すると、Defence Cyber Marvel（DCM）は、現実的で緊迫したシナリオの下、従来のITネットワーク、企業環境、複雑な産業制御システムの防衛に焦点を当てた、英国軍最大規模のサイバー演習シリーズです。責任あるサイバー能力を示すとともに、国防および同盟国全体の即応性、相互運用性、回復力を強化するものです。5年目を迎えたDCMは、陸軍サイバー協会の取り組みから、サイバー・専門作戦コマンド（CSOC）が主導する3軍合同の作戦へと進化しました。

英国政府は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）インド太平洋運用環境に基づいて構築されたこのシナリオでは、緊迫化する地域危機の中で、チームはデプロイされた軍事システムを防衛するサイバー保護チーム（CPT）として配置されました。ブルーチームは地理的に分散しており、英国各地や海外の拠点にいるチームもあれば、海外に展開するチームもあり、全員がVPN経由で演習環境（レンジ）に接続しました。

参加者には、英国国防省、国家犯罪対策庁、労働・年金省、内閣府、ビジネス・通商省などの各政府省庁の代表者に加え、国際パートナーも含まれ、最大40のチームが結成されました。韓国で実施された昨年の演習の成功を受け、今回はシンガポールが初めて演習の拠点となりました。これは、共通のセキュリティ課題に関してインド太平洋地域のパートナーとの協力を深めるという、英国のコミットメントを反映しています。

要するに、これは本格的な演習です。高い緊迫感の対抗戦形式で行われ、スコアへの実際の影響とともに、すべての参加者に確かな学習成果をもたらします。

デプロイメント：当社のElasticインフラストラクチャー

今年のインフラは、以前のものと比べてアーキテクチャー面で大幅な進化を遂げました。チームごとに個別のElastic Cloudクラスターをデプロイするのではなく、ブルーチーム向けにスペースベースの単一のマルチテナントElastic Cloudデプロイへと移行しました。また、ブルーチーム以外の機能向けにもデプロイを提供しました。各デプロイとその存在理由について詳しく説明します。

ブルーチーム：マルチテナントのElastic Security

当社の貢献の中心となったのは、防衛を担当する40のブルーチームすべてに対応する単一のElastic Cloud導入であり、Kibana Spacesとデータストリームの名前空間を使用して分離されていました。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日目にはDeployedネットワークポリシー、2日目にはHost Nationネットワークポリシー、そして最後にネットワークトラフィック監視用のPacketCaptureポリシーです。段階的なアクセス制御は非常にシンプルでした。terraform.tfvarsでenable_hostnation_network = trueを設定し、terraform applyを実行するだけで、各チームのロール権限が拡張され、それぞれのスペースでHost Nationエージェントポリシーが表示されるようになりました。この演習では、Kibanaで手動クリックを1回も行うことなく、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セキュリティロールのスコープをそれらのデータストリームのみに限定しました。

# デプロイされたデータストリーム（常に付与）
インデックス {
  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] : []
  コンテンツ {
    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 for Endpoint Detection and Response、Windowsイベント転送、監査ログ用のAuditd for Linux、ネットワークパケットキャプチャ統合が提供されました。これは、Elastic Stack Terraform Providerを介してコードとして管理される400以上の統合ポリシーに相当します。

Elastic Defendに関する注意点：Elasticのエンドポイント保護は極めて効果的であり（米国国防総省およびインテリジェンスコミュニティの実環境でも信頼されています。詳細はこちらをご覧ください）また、訓練の演習でわざわざゼロデイエクスプロイトを消費する人はいないという事情もあり、防御モードを無効にして検出専用モードに設定し、Elastic Defendにあえてハンディキャップを課す必要がありました。悪意のあるイベントが発生した際にチームにアラートは届くものの、自動的な対処（緩和）は行われません。また、攻撃チームのインプラントやビーコンの大半が発見されてしまい、レッドチーム側の面白みを損なってしまうのを避けるため、メモリ脅威防御・検出機能も完全に無効化しています。演習の終盤に向けて、チームがElastic Defendの全機能を自由に使用できるようにしましたが、それはレッドチームが強固な足場を築いた後のことでした。

また、Elasticの事前構築済み検出ルールを各チームスペースに事前インストールしました。これはオープンリポジトリで継続的に更新されるElastic Security Labsの完全なセットです。これらのルールは、チームの名前空間スコープの権限で許可されたインデックスのみをクエリするように設定されており、検出ルールの実行時におけるチーム間のデータ漏洩を防御します。

さらに、各チームスペースでは、デフォルトの広範なパターンではなく、そのチームのデータストリームのみに検出ルールのスコープを限定するよう、Security Solutionのデフォルトインデックスが設定されていました。これは、各スペースのsecuritySolution:defaultIndexを設定するためにKibana内部設定APIを呼び出すTerraformのnull_resourceによって処理されていました。

ピーク時には、この展開は40チーム全体で毎秒80万件のイベント（EPS）を取り込んでいました。これは相当な量のデータですが、Elastic Cloudの自動スケーリング機能のおかげで、クラスターは難なく処理できました。とはいえ、2018年にはeBayで毎秒500万件のイベントを処理していました。

データライフサイクルは、インデックスライフサイクル管理（ILM）ポリシーによって管理され、インデックスは1日または50GB（どちらか早い方）の経過後にロールオーバーされ、2日後に読み取り専用の最適化と強制マージのためにウォームフェーズに移行され、その後10日後にデータが削除されました。その結果、演習期間の要件を維持しながら、ストレージコストを最小限に抑えることができました。以下は、ILMポリシーの実装例です。

resource "elasticstack_elasticsearch_index_lifecycle" "dcm5_10day_retention" {
  name = "dcm5-10day-retention"

  ホット {
    min_age = "0ms"

    set_priority {
      priority = 100
    }

    ロールオーバー {
      max_age                = "1d"
      max_primary_shard_size = "50gb"
    }
  }

  ウォーム {
    min_age = "2d"

    set_priority {
      priority = 50
    }

    読み取り専用 {}

    forcemerge {
      max_num_segments = 1
    }
  }

  削除 {
    min_age = "${var.data_retention_days}d"

    削除 {
      delete_searchable_snapshot = true
    }
  }
}

シャードのストレステスト：大規模マルチテナンシーの実証

実動の軍事演習にこのアーキテクチャーを採用する前に、要件を満たせること、そして問題が発生した際に適切なフェイルオーバーが機能することを実証する必要がありました。個別の導入から単一のマルチテナントクラスターへ移行したことで、現実的なリスクが生じました。リソースの競合、データ投入のボトルネック、設定ミスによるスペース間でのデータ漏洩、Elasticsearchノードにおける大量のTCP接続数、そして各チームが独自のインデックスセットを生成することによる大幅なシャード数の増加です。

そこで、専用のテスト装置を構築しました。計画はいたってシンプルで、50件のKibana Spacesをデプロイし、各スペースにエージェントポリシーを作成し、6,000件のEC2インスタンス（3つのアベイラビリティゾーンの6つのサブネットにわたり、テナントごとに120件）を立ち上げ、そのすべてに負荷テストを実施するというものでした。AutoOpsとStack Monitoringを使用して、すべてを監視しました。

展開フローは次のように機能しました。Terraformが3つのアベイラビリティゾーンにわたってVPCとサブネットを作成し、50件のKibana SpaceとそれらのスペーススコープのFleetポリシーを提供し、登録トークンを生成してから、EC2インスタンスをバッチで立ち上げました。各インスタンスは起動時にElastic Agentをインストールし、スペース固有のトークンを使用して登録しました。

その過程で、いくつかの興味深い課題に直面しました。当時、標準のElastic Stack Terraform Providerはスペース対応のFleet操作をサポートしていなかったため、これをフォークし、FleetリソースにスペースIDの処理を追加しました。この変更がなければ、ポリシーの割り当てにかかわらず、すべてのエージェントがデフォルトのスペースに登録されていたでしょう。演習のためにプロバイダーを拡張する必要があったのはこれが初めてではありません。2年前には、DCM2向けにelasticsearch_cluster_infoデータソースを追加していました。幸い、その後アップストリームプロバイダーでは、バージョン0.12.2でsupport for space_idsが追加されました。

また、6,000件のインスタンスすべてを同時に立ち上げようとした際にAWS EC2 APIのレート制限にも達したため、バッチ間に5分間のクールオフ期間を設け、インスタンス500件ずつ導入をバッチ処理しました。

結果は安心できるものでした。通常、6,000件のエージェントすべてが導入から20分以内に登録されました。テストでは、スペース分離は期待どおりに機能し、テナント間でのデータ漏洩は確認されませんでした。Fleetポリシーの更新は、60秒以内にすべてのエージェントに反映されました。個々のスペースを対象とした検索クエリは、負荷が最大に達した場合でも高速に動作しました。また、マルチAZ分散構成は、シミュレートされたアベイラビリティゾーン障害の際にも優れた耐障害性を実証しました。

このテストにより、本番の演習に向けてこのアーキテクチャーを採用する確信を得ることができました。

レッドチーム：C2インプラントのオブザーバビリティ

レッドチーム向けに、コマンド＆コントロール（C2）インプラントのオブザーバビリティに焦点を当てた、独立した専用のElastic展開が立ち上げられました。これにより、攻撃チームはブルーチームのデータと混ざるリスクなしに、インプラントのステータス、ビーコンのコールバック、運用の進捗など、自らの作戦に対する可視性を得ることができました。レッドチームはC2としてTuoniを使用しました。これは、Clarified Securityがレッドチーム演習向けに開発したフレームワークです。DCM3では、Clarified Securityと連携してElastic Common Schemaを適切にサポートできるようにし、将来的なElasticとの統合を大幅に容易にしました。

NSOC：演習「Network Security Operations Centre」

コア演習であるNetwork Security Operations Centre（NSOC）は、独自のElastic展開環境で実行され、演習統制スタッフに対してレンジ全体の稼働状況の包括的な把握、インフラ全体のセキュリティ監視、そして極めて重要なこととして、デプロイしたすべてのAIサービスの監査ログを提供しました。すべてのBedrock API呼び出しはCloudWatchにログ記録され、この導入環境でオブザーバビリティが確保されていたため、NSOCはAIエージェントに対して誰がどのような質問をしているのかを完全に把握することができました。これについて詳しくは、以下のAIセクションをご覧ください。

インフラ自動化：TerraformとCatapult

上記でご紹介した内容はすべて、コードとしてのインフラ（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によって管理された総リソースフットプリントは相当なものでした。自動スケーリングを備えた1つのElastic Cloud導入、40のKibanaスペース、120のFleetエージェントポリシー（チームあたり3つ）、400以上の統合ポリシー、40のKibanaセキュリティロール、40のKeycloakロールマッピング、データ保持用のILMポリシー、Bedrock GenAIコネクター用の41のAWS IAMユーザー（チームスペースあたり1つ＋デフォルト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によって、認証情報、エンロールメントトークン、APIキー、プロキシ設定、Tinesサービスアカウント認証情報がHashiCorp Vaultに書き込まれ、Catapultによって使用されました。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調査ツールの習熟などが含まれていました。

演習の指示書自体にも、このトレーニングは任意であるものの「強く推奨」と記載されていましたが、私たちが確認したところ、参加したチームは実施初日から確実によいスタートを切ることができました。トレーニングと活用支援は、技術導入そのものと同じくらい重要です。使い方がわからないチームにエンタープライズグレードのセキュリティツールを渡しても、誰の役にも立たなかったでしょう。

On-Range 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 Assistantは、Elastic Security Labsの記事があらかじめ登録されているElasticのKnowledge Base機能とともにRetrieval-Augmented Generation（RAG）を使用しています。チームは、レンジ固有のSOP、脅威インテリジェンス、チームメモなどの独自のドキュメントをKnowledge Baseに追加して、アシスタントの応答を運用コンテキストにさらに基づいたものにすることもできました。

演習のコンテキストにおいてこれが特に価値を発揮したのは、経験の浅いアナリストが見ている内容を理解できるように支援するAI Assistantの能力でした。初めて実際のインプラントビーコンに直面したジュニアアナリストは、アシスタントにアラートの説明や調査手順の提案を求めたり、インシデントレポートの下書き作成を支援してもらったりすることさえできました。データ匿名化設定により、機密フィールドの値がLLMプロバイダーに送信される前に確実に難読化されるようになりました。

Elastic Attack Discovery

Attack Discoveryも、当社のレンジ内AIサービスの重要なコンシューマーの1つでした。Attack DiscoveryはLLMを使用してチームの環境内のアラートを分析し、アラート、行動、攻撃経路を相関付けることで脅威を特定します。各「検出」は潜在的な攻撃を表し、複数のアラート間の関係を記述します。これにより、どのユーザーとホストが関与しているか、アラートがMITRE ATT&CKマトリックスにどのようにマッピングされるか、どの脅威アクターが関与している可能性があるかがチームに示されます。

レッドチームが積極的に連携攻撃を仕掛けるサイバー演習において、Attack Discoveryは画期的なツールとなりました。ブルーチームは、数百件の個別の警告を手動でトリアージする代わりに、Attack Discoveryを実行して、たとえば「これらの15件の警告はすべて、おそらく脅威アクターZによるホストXからホストYへの横方向の移動チェーンの一部である」といった高レベルの攻撃シナリオを明らかにし、最も重要な部分に調査時間を集中させることができます。これは、平均対応時間を直接短縮し、アラート疲れを軽減する機能であり、5日間にわたる継続的な攻撃を受けているときにまさに必要となるものです。

カスタムAIエージェント：Elastic Agent Builder

ネイティブのElastic AI機能に加え、Elastic Agent Builderを使用して3つのカスタムAIエージェントを構築しました。Agent Builderは、LLMの指示とモジュール式の再利用可能なツールを組み合わせたカスタムAIエージェントを構築するためのElasticのフレームワークです。各ツールは、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が真に洗練されている理由の1つです。Elasticsearchのセキュリティモデルを継承することで、認証コードを1行も書くことなく、RBACに対応したAIを実現できます。

2. REDRock - 攻撃者の相棒

このエージェントはレッドチーム専用でした。REDRockも同じAgent Builderパターンを踏襲しており、敵対的なペルソナを定義する専用のシステムプロンプトと、レッドチーム固有のインデックスをクエリする独自のカスタムES|QLツールのセットに関連付けられていました。これらのインデックスには、レッドチームのプレイブック、Tuoni C2のドキュメント、レンジ内の既知のシステム脆弱性、展開されたサービスに関する情報が含まれていました。ツール定義は、GrantPTで使用されているものと同じパラメーター化されたセマンティック検索パターンを踏襲していましたが、レッドチームのロールのみがアクセスできるインデックスに対象が限定されていました。レッドチームのオペレーターは、攻撃ベクトルをクエリし、ターゲットシステムの既知の弱点を確認し、運用計画に関するコンテキストに応じたガイダンスを得ることができました。率直に言って、攻撃者に極めて詳細なブリーフィングを受けた作戦責任者を与えたようなものでした。

3. RefPT - 審判用ツール

演習の審判および評価者であるホワイトチーム向けに特別に構築されたRefPTは、ブルーチームのレポート、シナリオイベント、スコアリング基準を含むインデックスをクエリするツールに連携されていました。その目的は、40以上のすべてのチームで統一され、公平なスコアリングを確保することでした。エージェントのシステムプロンプトは、提出されたレポートを既知のシナリオイベントやスコアリングルーブリックと相互参照し、評価者が不整合やギャップを特定できるように調整されていました。評価者が数十のチームを同時に評価する場合、構造化されたスコアリングインデックスに照らしてレポートを関連付けられるAIがあれば、一貫性の面で真に変革的です。

Tines：AIを活用したワークフロー自動化

Tinesもまた、レンジ内AIサービスのコンシューマーでした。各ブルーチームには専用のTinesインスタンスがあり、それぞれのKibanaスペースにはTinesアクションコネクターが提供されていました。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によって制御されていました。コンテンツフィルタリング（MEDIUMのしきい値でのヘイト、侮辱、性的コンテンツ、暴力）、PII保護（メールアドレス、電話番号、名前、住所、英国国民保険番号、クレジットカード番号、IPアドレスのブロック）、実際の機密作戦に関する議論を防御するためのトピックベースのフィルタリング、不適切な表現のフィルタリングを備えたガードレールをデプロイしました。Terraformにおけるガードレール構成のスニペットを以下に示します。

resource "aws_bedrock_guardrail" "dcm5_elastic" {
  name        = "dcm5-prod-elastic-guardrail"
  description = "DCM5 Prod Elastic Kibana生成AIコネクター用ガードレール"

  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"
    }
    # ... 追加のPIIフィルター
  }

  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ユーザーが割り当てられており、チームが独自のコネクターを設定できないように、Kibanaの設定であるgenAiSettings:defaultAIConnectorOnlyが適用されていました。これにより、CloudWatchを介してすべてのAPI呼び出しを特定のチームまで追跡でき、NSOCは完全な監査可視性を確保できました。CloudWatchロググループ/aws/bedrock/grantpt-prod/invocationsは、すべての呼び出しとガードレールイベントを記録しました。

AIコンシューマー全体の数字を見れば、その成果は明らかです。カスタムAIエージェント3件、会話回数2,797回、そして今回の取り組み全体で消費されたAIトークンは7億8,500万個に上ります。

ゲーム内リアルタイム監視

演習シナリオにおいて、各チームはレンジ内でのメッセージングクライアントとしてRocketChatを利用することができました。各ブルーチームには専用のチャンネルが用意され、演習中の誰にでもダイレクトメッセージを送信でき、必要に応じて新しいチャンネルを自由に作成できました。DCMの伝統において最も重要だったのは、ミームチャンネルでした。これは、数千人のサイバーオペレーターを1週間にわたってプレッシャーにさらすと必然的に生まれる、チーム間のからかい合いと士気を高める創造的なユーモアを支える精神的な基盤です。

このすべてのコミュニケーションデータは、レンジの健全性、チームの感情、演習全体でトレンドとなっているトピックをリアルタイムで把握できる優れた窓口となりました。あまりにも魅力的だったため見過ごすことはできず、RocketChatの会話コーパス全体をリアルタイムでElasticにインジェストして活用しました。

センチメント分析と固有表現抽出

固有表現抽出のために、dslim/bert-base-NER というHugging Faceのモデルを、Elastic ELANDクライアントを使用してNSOC導入の機械学習ノードにデプロイしました。その後、これはすべてのRocketChatメッセージがインジェスト時に通過するElasticsearchインジェストパイプラインに組み込まれました。抽出されたエンティティを取得して最も頻出するものをダッシュボードのテーマとして表示し、演習全体を通して会話トピックの推移をリアルタイムで把握できるようにしました。

また、グループのアクティビティ、ユーザー統計、一般的なコミュニケーションパターンを分析し、最もアクティブな参加者、時系列のメッセージ量、個々のユーザーを軸とした感情の傾向など、各チームの活動実態を把握しました。総合すると、レンジ上で何が起きているのかについて、ほぼリアルタイムで実に興味深い洞察を得ることができました。例えば、Elastic Agentを防御モードに切り替えた際には、ブルーチームがその効果を議論し、レッドチームが失われたビーコンを嘆くなど、ダッシュボード上のワードクラウドで全チャンネルを通じて最も議論されたテーマとして「Elastic」がすぐに浮かび上がりました。実に満足のいくものでした。

ミーム分析（はい、本当に）

最後に（少し驚かれたかもしれませんが）、チャンネルに投稿されたすべてのミームを抽出し、画像をベクトル化して、近傍評価を実行して類似するミームやトピックをクラスタリングしました。また、これらをゼロショットNER推論モデルに渡して、各ミームのコンテンツに関するテーマ別の説明を生成しました。その意図は、これらの出力が将来的にフィルタリングやモデレーション、あるいはその他のゲーム内インタラクションに役立つ可能性があると考えたためです。ミーム分析によって運用上重要なインテリジェンスが得られたかどうかには議論の余地がありますが、大いに楽しかったことは確かです。

問題を未然に防ぐ

演習週間中はすべてが順調に進むことを願っていましたが、どうしても故障が発生したり、十分に理解されなかったり、特定のチームがどのように使用したいかに合わせてさらにカスタマイズする必要が生じたりします。このため、レンジ内のヘルプデスクには専用のサブセクションを設け、どのチームもElasticおよび生成AIに関するリクエストを送信できるようにしました。

私たちは演習の全期間を通じてこのヘルプデスクを担当し、ガイダンス、ドキュメント、問題のデバッグ、演習環境に特化した推奨事項を提供しました。この最後のポイントについては、もう少し掘り下げて説明する価値があります。ブルーチームがElasticで確認していた事象は、実際にはElastic自体の問題ではまったくなく、さらなる調査を要する演習環境上の事象をElasticが忠実に可視化していただけということもありました（レッドチームは壊滅的な混乱を引き起こすことがあり、テレメトリは嘘をつきません）。演習期間中、私たちElasticに支援を求めたチームからの個別サポートリクエスト125件に対応しました。

Tinesによる事前デバッグ

VTCまたはEXCONでの対面によるチーム訪問に加え、より予防的な取り組みを試すために、Tinesとも連携しました。受信リクエストからチケット本文を取得し、問題の分類を試み、その分類を過去に解決したチケットのコーパスに照らして実行し、トリアージによってキューに入る前にユーザーの問題を解決することを目的とした要約済みの一次対応を生成AIに作成させました。

これは実際に、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のステート管理について議論することには、どこか非常にシュールなものがありました。素晴らしい夜であり、こうした取り組みがテクノロジーと外交の交差点に存在すること、そしてここで築かれた関係が技術的な領域をはるかに超えて広がることを改めて実感する機会となりました。

まとめ

マルチテナントアーキテクチャは継続的な負荷の下でその実力を発揮しました；ネイティブのElastic AI機能（AI AssistantとAttack Discovery）は数年前ならSFの世界であったような機能をチームにもたらし、カスタムAIエージェントの導入実績は私たちの期待を上回りました。このパートナーシップモデルは、防衛演習への業界の参加が、単一の組織だけでは達成できない成果を生み出すことを実証し続けています。

Defence Cyber Marvel 2026は、意欲、複雑さ、影響力を増し続ける演習の画期的な節目となる回となりました。Elasticにとって、29か国から参加した40のブルーチームに中核となる防御セキュリティプラットフォームを提供し、今年はさらにAI機能も提供するという信頼をいただくことは、決して軽視できない重大な責務です。この演習は、実際にネットワークを守ることになる現場の人々に実践的なスキルを培うものであり、そのミッションの一翼を担えることは実に意義深いことです。

英国政府のプレスリリースで述べられているように、DCMは国際的なパートナーシップを強化する実践的なシナリオの実用的な価値を実証しています。まったく同感です。

来年もまた戻ってまいります。その際には、お話しできることがさらに増えていることと思います。それまでの間、Defence Cyber Marvelのような環境へのサポートが年々さらに優れたものとなるよう、製品の改善を継続してまいります。

レンジでお会いしましょう。

ソーシャルメディアでDCM26のストーリーをフォロー：

Facebook | LinkedIn | Instagram

参考資料

Elastic Security & AI

Elastic Security - ブルーチームの展開を支えるプラットフォーム
AI Assistant for Security - Elastic Security内のコンテキスト認識型AIチャット
攻撃の発見 - LLMを活用したアラートの相関付けと脅威ナラティブの生成
Agent Builder - ElasticsearchでカスタムAIエージェントを構築するためのフレームワーク

インフラとツール

Elastic Stack Terraform Provider - Elastic Stack向けのコードとしてのインフラ
Elastic Fleetガイド - 大規模なElastic Agentの一元管理
Clarified SecurityによるCatapult - Ansibleベースのサイバーレンジプロビジョニング

演習の背景

英国政府のDCM26プレスリリース - 演習の公式概要

セキュリティ運用 - Elastic Security Labs