从何处开始。Elastic 连续第四年荣幸地作为值得信赖的行业合作伙伴，参与英国国防部的旗舰级网络系列演习——Exercise Defence Cyber Marvel。DCM26 毫无疑问是迄今为止最具雄心的一次迭代，我们非常高兴终于能够畅谈我们构建了什么、是如何构建的，以及在此过程中学到的经验。

什么是 Defence Cyber Marvel？

为不熟悉的人介绍一下：Defence Cyber Marvel (DCM) 是英国规模最大的军方网络系列演习，专注于在逼真的高压场景中防御传统 IT 网络、企业环境和复杂的工业控制系统。它展现了负责任的网络力量，同时提升了国防部门及盟国的战备能力、互操作性和弹性。如今已进入第五年，DCM 已从陆军网络协会 (Army Cyber Association) 的一项举措演变为由网络与专业作战司令部 (CSOC) 领导的三军联合行动。

英国政府发布了关于 DCM26 的正式新闻稿，对该演习的战略重要性进行了精彩概述。正如英国驻新加坡高级专员所指出的，该演习展示了英国与值得信赖的合作伙伴之间的深度合作，彰显了在日益复杂的安全态势中共享战略伙伴关系的力量。

DCM 的核心是一项实兵对抗网络演习：防守方蓝队运用一系列技术，保护其负责的网络和基础架构免受进攻方红队的攻击。活动范围涵盖更改默认密码和加固防火墙，直至部署由 AI 驱动的使用 Elastic Security 的企业级网络防御。各团队的活动均由白队监测，以确定评分，该评分会考虑系统可用性、攻击检测、事件报告和系统恢复。它既考验最有经验的团队，也为初次接触网络靶场的初级团队提供独特的培训机制；这种双重目的正是 DCM 成为如此有价值的演习的原因。

DCM26 的扩展

DCM26 汇聚了来自 29 个参演国家和 70 个组织的 2,500 多名人员，由设在新加坡的中央演习控制中心 (EXCON) 统一协调，其中 EXCON 接纳了 600 多名参与者。该演习在横跨 CR14 网络靶场和 AWS 的混合计算环境中运行，托管了 5,000 多个虚拟系统。

演习本身执行了五天（2026 年 2 月 9–13 日），此前进行了可选的讲师主讲预培训和连通性检查。该场景基于国防学院训练环境 (DATE) 的印太作战环境构建，在不断升级的地区危机期间，设定各团队为负责防御已部署军事系统的网络保护团队。蓝队分布在不同地理位置，有些位于英国及国际上的本地地点，另一些部署在海外，所有团队均通过 VPN 连接到靶场。

参与者包括来自英国国防部门、跨政府部门（如英国国家犯罪调查局、就业与养老金部、内阁办公厅以及商业贸易部）的代表，以及国际合作伙伴，总共组成了多达 40 支团队。继去年在韩国成功举行演习之后，新加坡首次担任演习枢纽，这体现了英国致力于深化与印太伙伴在共同安全挑战方面的合作。

简而言之，这是一项严肃的演习。高压、实兵对抗，评分具有实际影响，并让每位参与者获得切实的学习成果。

部署：我们的 Elastic 基础架构

今年的基础架构相较于之前的迭代版本，经历了重大的架构演进。我们不再为每个团队单独部署 Elastic Cloud 集群，而是改为为蓝队提供基于空间的单一多租户 Elastic Cloud 部署。我们还为蓝队之外的职能部门提供了部署。让我逐一分析每个部署及其存在的原因。

蓝队：多租户 Elastic Security

我们贡献的核心是一个单一的 Elastic Cloud 部署，该部署为所有 40 支防守蓝队提供服务，并通过 Kibana Spaces 和数据流命名空间实现隔离。39 支团队中的每一支都拥有自己独立的隔离工作区，包括仪表板、智能体和检测规则。

用于为每个团队创建空间的 Terraform 资源如下：

# 创建 40 个蓝队空间
resource "elasticstack_kibana_space" "blue_team" {
  count = var.team_count

  space_id    = local.space_ids[count.index]
  name        = "蓝队 ${local.team_numbers[count.index]}"
  description = "用于 BT-${local.team_numbers[count.index]} 的隔离空间，具有空间感知 Fleet 可见性"

  disabled_features = []
  color             = "#0077CC"
}

每个团队的空间都分配了一组专用的 3 个 Fleet 智能体策略：第 1 天是部署网络策略，第 2 天是主办国网络策略，最后是用于网络流量监测的抓包策略。分阶段访问控制非常简洁优雅：只需在我们的 terraform.tfvars 中设置 enable_hostnation_network = true 并运行 terraform apply，就能扩展每个团队的角色权限，并使其主办国智能体策略在其空间中可见。该演习从一个网络扩展到两个网络，在 Kibana 中无需进行任何一次手动点击。

数据隔离依赖于数据流命名空间。每个智能体策略都会写入特定于团队的命名空间（如 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 安全角色限定为仅针对那些数据流：

# 已部署的数据流（始终授予）
indices {
  names = [
    "logs-*-${local.deployed_namespaces[count.index]}",
    "metrics-*-${local.deployed_namespaces[count.index]}",
    ".fleet-*"
  ]
  privileges = ["read", "view_index_metadata"]
}

# HostNation 数据流（以 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 单点登录身份验证处理，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]}"
    }
  })
}

默认集成策略本身设计简单。每个团队都收到了：用于核心操作系统遥测的系统、用于终端检测和响应的 Elastic Defend、Windows 事件转发、用于 Linux 审计日志的 Auditd 以及网络数据包捕获集成。这意味着通过 Elastic Stack Terraform 提供程序 以代码形式管理了 400 多个集成策略。

关于 Elastic Defend 的说明：由于 Elastic 的终端保护非常有效——该保护已获 美国国防部和情报界，点击此处了解更多 信赖并用于生产环境——再加上没有哪个神志正常的人会在训练演习中耗费零日漏洞，我们不得不通过禁用防止模式来削弱 Elastic Defend，使其保持在仅检测模式。发生恶意事件时，团队会收到告警，但不会自动缓解。我们还完全禁用了内存威胁防护和检测，因为它会发现攻击团队的大多数植入程序和信标，这会让红队的演练大打折扣。演习接近尾声时，我们允许各团队充分发挥 Elastic Defend 的全部功能，但在此之前，我们先让红队站稳脚跟。

我们还预安装了 Elastic 的 预构建检测规则 到每个团队空间中——全套规则均来自 Elastic Security Labs，并在开放存储库中持续更新。设置这些规则是为了确保它们仅查询团队命名空间范围权限所允许的索引，从而防止在检测规则执行过程中发生任何跨团队数据泄露。

此外，每个团队空间的安全解决方案默认索引均已配置为将检测规则的范围限定为仅该团队的数据流，而非默认的宽泛模式。这是通过 Terraform null_resource 处理的，它调用 Kibana 内部设置 API，为每个空间设置 securitySolution:defaultIndex。

在峰值时期，此部署在全部 40 个团队中每秒采集 800,000 个事件 (EPS)。这是相当庞大的数据量，得益于 Elastic Cloud 的自动扩展功能，集群轻松应对了这一挑战。话虽如此，早在 2018 年，我们就与 eBay 实现了每秒处理 500 万个事件。

数据生命周期由索引生命周期管理 (ILM) 策略进行管理：在 1 天或 50 GB 后对索引进行滚动更新（以先达到的条件为准），在 2 天后将其移至温阶段 (Warm phase) 进行只读优化和强制合并，并在 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，在每个空间中创建智能体策略 (Agent Policy)，启动 6,000 个 EC2 实例（每个租户 120 个，分布在三个可用区的六个子网中），并对整体进行负载测试。我们使用 AutoOps 和 Stack Monitoring 监测一切。

部署流程如下：Terraform 跨 3 个可用区创建了 VPC 和子网，配置了 50 个 Kibana Space 及其空间范围的 Fleet 策略，生成了注册令牌，然后分批启动了 EC2 实例。每个实例在启动时安装 Elastic Agent，并使用其对应空间的特定令牌进行注册。

在此过程中，我们遇到了一些有趣的挑战。当时，标准的 Elastic Stack Terraform 提供程序并不支持可感知空间的 Fleet 操作，因此我们对其进行了分叉 (fork)，并为 Fleet 资源添加了空间 ID 处理功能——若不进行该修改，无论策略如何分配，每个智能体都会注册到默认空间中。这并不是我们第一次为了演习而不得不扩展该提供程序；两年前，针对 DCM2，我们就添加了 elasticsearch_cluster_info 数据源。幸运的是，上游提供程序此后已在 0.12.2 版本中添加了 support for space_ids。

我们在尝试同时启动全部 6,000 个实例时，也遇到了 AWS EC2 API 速率限制，因此我们按每批 500 个实例进行批量部署，并在各批次之间设置了 5 分钟的冷却期。

结果令人安心。部署后，通常可在 20 分钟内完成所有 6,000 个智能体的注册。在我们的测试中，空间隔离按预期运行，未观察到租户之间出现数据泄露。Fleet 策略更新会在 60 秒内传播到所有智能体。在满负载情况下，限定在各个空间内的搜索查询仍然保持快速。而且，多可用区分布在模拟可用区故障期间证明了其弹性。

这次测试让我们有信心在实际演习中采用该架构。

红队：C2 植入程序可观测性

为红队建立了一个独立的专用 Elastic 部署，侧重于命令与控制 (C2) 植入程序的可观测性。这让攻击团队能够了解自身作战行动的情况，包括植入程序状态、信标回连和行动进展，同时不会与蓝队的数据发生任何交叉污染。红队使用 Tuoni 作为其 C2；Tuoni 是 Clarified Security 为红队演练开发的框架。在 DCM3 中，我们与 Clarified Security 合作，确保其能够正确支持 Elastic Common Schema，从而大幅简化未来与 Elastic 的集成。

NSOC：演习网络安全作战中心

核心演习——网络安全作战中心 (NSOC)——在其独立的 Elastic 部署上运行，为演习控制人员提供了靶场运行状况的总体视图、整个基础架构的安全监测，以及至关重要的、针对我们所部署的所有 AI 服务的审计日志。每次 Bedrock API 调用都会记录在 CloudWatch 中 并且可在此部署中观测，这意味着 NSOC 能够全面了解向 AI 智能体提出了哪些请求，以及请求者是谁。下方的 AI 部分将对此进行详细介绍。

基础架构自动化：Terraform 和 Catapult

您在上面看到的所有内容都是作为基础架构即代码来进行管理的。我们的 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 生成式 AI 连接器的 41 个 AWS IAM 用户（每个团队空间 1 个，外加 1 个默认用户）、41 个 Kibana GenAI 操作连接器、AWS Bedrock 护栏、用于 Tines 访问的 Cloudflare Zero Trust 隧道、每个团队空间的 Tines 操作连接器、存储在 HashiCorp Vault 中的检测服务帐户，以及按空间配置的安全解决方案默认索引。所有状态都存储在加密的 S3 后端中。

为了将智能体和代理部署到实际的靶场系统上，我们使用了 Catapult，这是 Clarified Security 团队构建的一款出色的开源工具。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 访问支持。我们直接在靶场上提供了合规的 AI 服务，由英国租户的 AWS Bedrock 模型提供支持——具体为在 eu-west-2（伦敦）区域运行的 Claude 3.7 Sonnet。这并非为了 AI 而 AI；它是一项经过精心架构的服务，具备安全护栏、完整的审计日志以及支持基于角色的访问控制 (RBAC) 的访问控制。得益于 Elastic 在 AI 领域的丰富经验，我们受托运行这项服务。

AI 服务在靶场上有多个使用者，这是一个重要的区别。我们在每个团队的空间中配置的合规 Bedrock 连接器不仅为我们的自定义智能体提供支持——它还支持了 Elastic 的原生 AI 功能，具体包括：

Elastic AI Assistant for Security

Elastic AI Assistant 在每个蓝队空间中均可使用，并连接到了我们靶场内的 Bedrock 连接器。这直接在 Elastic Security 中为团队提供了一个具备上下文感知能力的聊天界面，他们可以在其中询问有关其告警的问题、获取编写 ES|QL 查询的帮助、调查可疑进程并获得具有指导性的补救步骤。AI 助手将检索增强生成 (RAG) 与 Elastic 的知识库功能结合使用，该功能已预先填充来自 Elastic Security Labs 的文章。团队还可以将自己的文档（例如靶场特定的 SOP、威胁情报或团队笔记）添加到知识库中，以便让助手的响应更紧密地立足于其实际作战上下文。

在演习场景中，这项功能尤其有价值之处在于 AI 助手能够帮助经验较浅的分析师了解他们所查看的内容。初级分析师在面对其首个实际植入信标时，可以让助手解释告警、建议调查步骤，甚至协助起草事件报告。数据匿名化设置确保在将敏感字段值发送给 LLM 提供商之前对其进行模糊处理。

Elastic Attack Discovery

Attack Discovery 也是我们靶场实操 AI 服务的另一重要使用方。Attack Discovery 使用大语言模型 (LLM) 分析团队环境中的告警，并通过关联告警、行为和攻击路径来识别威胁。每次“发现”都代表一次潜在攻击，并描述多个告警之间的关系——告知团队涉及哪些用户和主机、告警如何映射到 MITRE ATT&CK 矩阵，以及可能对此负责的威胁行为者。

在一场红队主动发起协同攻击的网络演习中，Attack Discovery 带来了颠覆性的改变。蓝队无需手动对数百条独立告警逐一进行分类，而是可以运行 Attack Discovery 来梳理出高层级的攻击叙事（例如，"这 15 条告警都是从主机 X 到主机 Y 的横向移动链的一部分，很可能是威胁主体 Z 所为"），从而将调查时间集中在最关键的地方。这项功能能够直接缩短平均响应时间并缓解告警疲劳，而这正是您在连续五天遭受持续攻击时所急需的。

自定义 AI 智能体：Elastic Agent Builder

除了原生的 Elastic AI 功能之外，我们还使用 Elastic Agent Builder 构建了三个定制的 AI 智能体。Agent Builder 是 Elastic 用于构建自定义 AI 智能体的框架，它将 LLM 指令与模块化、可重用的工具相结合，各工具可以是 ES|QL 查询、内置搜索功能、工作流执行或通过 MCP 进行的外部集成。智能体可以解析自然语言请求、选择适当的工具、执行这些工具并进行迭代，直至能够提供完整的答案，同时利用 Elasticsearch 内部的数据来管理上下文。您可以在 Agent Builder 文档 以及 Elasticsearch Labs 深度解析 中了解关于该框架的更多信息。

我们利用的 Agent Builder 三个关键组件是：

智能体：自定义 LLM 指令以及一组分配的工具，用于定义智能体的角色、能力和行为边界。每个智能体都有一个系统提示，用于控制其使命、可访问的工具以及响应结构。

工具：智能体用于搜索、检索和操作 Elasticsearch 数据的模块化函数。我们构建了自定义 ES|QL 工具，用于查询包含演习文档、操作手册和报告的特定索引。

智能体聊天：参与者用于与智能体交互的对话式界面——包括内置 Kibana UI 和以编程方式使用的 API。

智能体和工具配置均定义为 JSON，并通过 Agent Builder API 进行管理，这使得整个智能体生命周期——从提示词工程到工具绑定——都可复现且支持版本控制。对于希望复现该方法的用户，我们将在后续博文中分享 GrantPT 智能体配置和工具定义——敬请关注。

以下是各智能体的操作：

1. GrantPT - 通用助手

GrantPT 面向全部约 2,500 名演习参与者开放，是我们主要的 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 遵循了相同的 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 GenAI 连接器的护栏"

  content_policy_config {
    filters_config {
      input_strength  = "MEDIUM"
      output_strength = "MEDIUM"
      type            = "HATE"
    }
    # ... 针对侮辱、性、暴力内容的附加过滤器
  }

  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 = "讨论实际的机密行动、当前现实世界的军事活动或作战情报。"
      type       = "DENY"
    }
  }
}

每个蓝队空间都有自己的用于 Bedrock 访问的 IAM 用户，并且强制实施 genAiSettings:defaultAIConnectorOnly Kibana 设置，以防止各团队配置自己的连接器。这意味着每一次 API 调用都可以通过 CloudWatch 追溯到特定团队，并且 NSOC 拥有完整的审计可见性。CloudWatch 日志组 /aws/bedrock/grantpt-prod/invocations 捕获了每一次调用和护栏事件。

所有 AI 使用方的数据不言自明：整个演习过程中共涉及 3 个自定义 AI 智能体、2,797 次对话，并消耗了 7.85 亿个 AI 词元。

游戏内实时监控

在演习场景中，每个团队都可以使用 RocketChat 作为其靶场内的即时通讯客户端。每个蓝队都拥有自己的专属频道、向演习中的任何人发送私信的权限，以及根据需要随时创建新频道的自由。最关键的是，按照 DCM 的传统，这还包括“热梗”频道——这是团队之间相互调侃的精神支柱，也是将数千名网络作战人员置于为期一周的高压之下时必然会迸发出的、鼓舞士气的创意幽默。

所有这些通信数据都为我们提供了一个绝佳的实时窗口，使我们能够了解靶场运行状况、团队情绪以及整个演习期间的热门话题。这个机会实在太好了，不容错过，因此我们将整个 RocketChat 对话语料库实时采集到 Elastic 中，并加以利用。

情感分析和命名实体识别

为了进行命名实体识别，我们使用 Elastic ELAND 客户端 将 dslim/bert-base-NER 模型从 Hugging Face 部署到 NSOC 部署上的机器学习节点中。然后将其接入 Elasticsearch 采集管道中，每条 RocketChat 消息在摄取时都会经过该管道。我们提取出这些实体，并将最常见的实体以仪表板主题的形式呈现，从而让我们能够在整个演习过程中实时了解对话主题的消长起伏。

我们还分析了群组活动、用户统计数据和一般的沟通模式，以描绘出每个团队的日常模式画像——最活跃的参与者、随时间推移的消息量，以及按单个用户透视的情绪趋势。总而言之，它让我们能够近乎实时地洞察靶场上发生的情况，获得了非常有趣的见解。例如，当我们将 Elastic Agent 切换到“防止”模式时，仪表板上的词云立即亮起，“Elastic”成为所有频道中讨论最多的话题——蓝队在讨论其成效，红队则在哀叹他们丢失的信标。这确实令人心满意足。

热梗分析（是的，真的）

最后——这一点让人有些意外——我们提取了提交到各个频道的每一条热梗图文，对图像进行向量化，并运行了最近邻评估，将相似的表情包和主题集聚到一起。我们还将它们传入零样本 NER 推理模型，以生成每个热梗内容的主题描述。背后的逻辑是，这些输出日后可能会在筛选、内容审核或其他游戏内互动中派上用场。热梗分析是否产生了具有关键作战价值的情报尚存争议。但它无疑十分有趣。

防患于未然

尽管我们希望在演习周期间一切顺利运行，但难免会出现故障、未被完全理解的问题，或需要进一步定制以适应特定团队的使用方式。为此，我们在覆盖范围内的服务台中设立了自己的子版块，任何团队都可以在其中提出与 Elastic 和生成式 AI 相关的请求。

在整个演习期间，我们一直负责运营该服务台，提供指导、文档、问题调试以及针对靶场的具体建议。最后一点值得展开阐述。有时，蓝队在 Elastic 中看到的问题实际上根本不是 Elastic 本身的问题，而是 Elastic 如实呈现了靶场中值得进一步调查的异常情况（红队可能会造成巨大的混乱，遥测数据不会说谎）。在演习过程中，我们处理了来自各团队的 125 个单独支持请求，这些团队专门向我们 Elastic 寻求帮助。

利用 Tines 进行预防式故障排查

除了通过 VTC 或亲临 EXCON 拜访团队外，我们还与 Tines 合作，尝试采取一些更积极主动的措施。我们从传入请求中提取工单正文，尝试对问题进行分类，将分类结果与我们此前已解决工单的语料库进行比对，并让生成式 AI 生成一份摘要性的初步响应，旨在于分流过程将其转入我们的队列之前解决用户的问题。

这实际上是我们从自己的 Elastic 支持组织 借鉴的一种模式，在其中，我们利用包含以往已解决问题的庞大知识库作为支持 AI 智能体上下文的存储库，提供了类似的功能。其思路非常明确：利用以往的解决方案，由机器生成有根据的初步尝试来解决问题，从而避免了支持工程师必须手动接手每个工单的需求。它并没有解决所有问题；有些问题确实需要具备广泛上下文背景的人员来处理，但它显著减轻了队列压力，并让需要解答的团队更快地获得了答案。这在我们特定的工单和队列中取得了极大的成功，以至于我们在演习后期实际上将范围扩大到了整个服务台，从而帮助减轻了支持该演习的绿队中其他小组的负担。

行业合作伙伴：携手并进

我们最引以为豪的成就之一是，我们的合作伙伴生态系统逐年发展壮大。DCM 不仅仅是 Elastic 的一场展示；它是真正由行业合作伙伴组成的联盟，每个合作伙伴都为安全平台带来了独特价值。

第 1 年 (DCM2) - Elastic 作为行业合作伙伴加入，提供了安全监测和终端检测平台。

第二年 (DCM3) - 我们引入了 Endace，提供 1:1 数据包捕获能力。完整数据包捕获结合 Elastic 的网络可见性，使团队能够开展仅凭基于日志的分析所无法提供的深入取证。

第 3 年 (DCM4) - Tines 加入了这个大家庭，带来了工作流自动化。蓝队现在可以构建自动化响应剧本、分流工作流以及通知链，所有这些都通过原生 Tines 连接器直接集成到其 Elastic 环境中。

第 4 年（DCM26，旧称 DCM5） - AWS 加入进来，为我们的 AI 智能体提供 Bedrock 访问权限，并为 Elastic 部署提供资金支持。这是一个重要的里程碑；一家超大规模云服务提供商直接投资于该演习的成功，使我们得以获得原本根本不可能实现的能力（例如具备完整防护措施和审计日志的合规英国租户托管 AI 推理）。今年，随着增加了靶场内 LLM 访问权限，Tines 的集成也得到了增强。DCM 系列今年也达到了一个里程碑，从最初作为陆军网络协会的一项倡议，转变为网络与特种作战司令部下获得官方资助的项目。

谨向 Endace、Tines 和 AWS 团队致以由衷的感谢。因为有了大家的贡献，本次演习更加出色，而且得益于我们共同构建的平台，所有团队都得到了更好的支持。我们已经在规划 DCM27。为各位欢呼喝彩！

文化、亮点以及使其值得一看的点滴

挑战币

我们为 DCM26 定制铸造了挑战币。懂的人自然懂，挑战币是一项历史悠久的军事传统，为此次演习定制一枚挑战币，正是纪念我们参与其中第四个年头的绝佳方式。

鸡尾酒会

我们也很荣幸受邀参加由英国驻新加坡高级专员举办的高级专员公署鸡尾酒会。在受大使邀请手持金汤力酒的同时讨论 Elasticsearch 分片数量和 Terraform 状态管理，让人感到颇具超现实色彩。这是一个精彩的夜晚，它真切地提醒着我们，这些演习处于技术与外交的交汇处，并且在此建立的关系远不止于技术层面。

总结

多租户架构在持续负载下证明了自身实力；原生 Elastic AI 功能 (AI Assistant 和 Attack Discovery) 为团队赋予了在几年前还如同科幻般的能力；自定义 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 对话
• Attack Discovery - 由 LLM 驱动的告警关联和威胁叙事生成
• Agent Builder - 用于借助 Elasticsearch 构建自定义 AI 智能体的框架

基础架构和工具

• Elastic Stack Terraform Provider - 适用于 Elastic Stack 的基础架构即代码
• Elastic Fleet 指南 - 大规模集中管理 Elastic Agent
• Catapult by Clarified Security - 基于 Ansible 的网络靶场配置

演习背景

• 英国政府 DCM26 新闻稿 - 该演习的正式概述