从哪里开始Elastic 连续第四年有幸成为英国国防部旗舰网络演习系列 "国防网络奇迹演习"（Exercise Defence Cyber Marvel）值得信赖的行业合作伙伴。毫无疑问，DCM26 是迄今为止最雄心勃勃的一次迭代，我们很高兴终于能够谈谈我们做了什么、怎么做的以及一路上学到了什么。
什么是防御网络奇迹？
对于那些不熟悉网络演习的人来说，"国防网络奇迹"（DCM）是英国最大的军事网络演习系列，其重点是在逼真的高压场景中防御传统 IT 网络、企业环境和复杂的工业控制系统。它展示了负责任的网络力量，同时加强了国防和盟国的战备状态、互操作性和应变能力。如今，DCM 已进入第五个年头，从陆军网络协会的一项倡议发展成为由网络和专家行动指挥部 (CSOC) 领导的三军行动。
英国政府为 DCM26 发布了一份官方新闻稿，对这次演习的战略重要性进行了很好的概述。正如英国驻新加坡高级专员所指出的那样，这次演习展示了英国与可信赖的合作伙伴之间的深度合作，提醒人们在日益复杂的安全环境中共享战略伙伴关系的力量。
DCM 的核心是 "兵力对兵力 "的网络演习：防守的 "蓝队 "利用一系列技术保护其指定网络和基础设施免受 "红队 "的攻击。活动包括更改默认密码和加固防火墙，以及利用Elastic Security 部署企业级人工智能网络防御。白队对每个小组的活动进行监控，并根据系统可用性、攻击侦测、事件报告和系统恢复等因素进行评分。它既能锻炼最有经验的团队，又能为首次接触网络靶场的初级团队提供独特的培训机制，这种双重目的使 DCM 成为一项非常有价值的演习。
DCM26 的规模
DCM26 汇集了来自 29 参与国和 70 组织的 2,500 多名人员，由设在新加坡的中央演习控制中心（EXCON）协调，EXCON 接待了超过 600 的参与者。演习在跨越 CR14 网络范围和 AWS 的混合计算环境中进行，托管了 5000 多个虚拟系统。
演习本身为期五天（2026 年 2 月 9 日至 13 日），演习前进行了可选的教员指导预培训和连通性检查。该情景模拟以国防学院训练环境（DATE）印度洋-太平洋作战环境为基础，在不断升级的地区危机中，将各小组安排为网络保护小组，保卫已部署的军事系统。
参与者包括英国国防部、国家犯罪署等跨政府部门、就业和养老金部、内阁办公室、商业和贸易部的代表，以及由国际合作伙伴组成的多达 40 团队。继去年在大韩民国成功举行演习之后，新加坡首次成为演习中心，这反映出英国致力于深化与印度洋-太平洋地区伙伴在共同安全挑战方面的合作。
总之，这是一项严肃的工作。高压、强对强，对每个参与者都有真实的评分结果和真实的学习成果。
部署：我们的弹性基础设施
与以往相比，今年的基础设施在架构上有了重大改进。我们没有为每个团队部署单独的弹性云集群，而是为蓝队部署了一个基于空间的多租户弹性云。我们还为 "蓝队 "以外的职能部门提供部署服务。让我来分析一下每种部署及其存在的原因。
蓝色团队：多租户弹性安全
我们的核心贡献是使用 Kibana Spaces 和数据流命名空间将所有 40 defending Blue Teams 分隔开来，为其提供单一的弹性云部署服务。 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"
}每个团队的空间都有一套专门的三项舰队代理策略：第一天是部署网络策略，第二天是主机国网络策略，最后是用于网络流量监控的 PacketCapture 策略。分阶段访问控制简单而优雅：在我们的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 安全角色只适用于使用动态索引权限块的数据流：
# 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]}"
}
})
}默认集成策略设计简单。每个团队都获得了用于核心操作系统遥测的 System、用于端点检测和响应的 Elastic Defend、Windows 事件转发、用于 Linux 审计日志的 Auditd 以及网络数据包捕获集成。通过Elastic Stack Terraform Provider 以代码形式管理的集成策略超过 400 。
关于 Elastic Defend 的说明：由于 Elastic 的端点保护非常有效（ 美国国防部和集成电路 在生产中对其非常信任 ，请点击此处了解更多信息 ），而且没有正常人会在培训演习中使用零日漏洞，因此我们不得不通过禁用预防模式来对 Elastic Defend 进行手把手的培训，使其处于仅检测模式。当发生恶意事件时，团队会收到警报，但不会自动缓解。我们还完全禁用了 "内存威胁防御和检测"，因为它会发现大部分攻击队的植入物和信标，这反而会破坏红队的游戏。在演习接近尾声时，我们允许各小组自由发挥 Elastic Defend 的全部能力，但在此之前不能让红队站稳脚跟。
我们还在每个团队空间中预装了 Elastic 的 预建检测规则 - 来自 Elastic 安全实验室的全套 规则 ，并在开放的资源库中不断更新。这些规则的设置可确保它们只查询团队名称空间范围权限允许的索引，从而防止在执行检测规则时出现任何跨团队的数据泄漏。
此外，每个团队空间都配置了安全解决方案默认索引，以将检测规则的范围限定为该团队的数据流，而不是默认的广泛模式。这由 Terraformnull_resource 处理，它调用 Kibana 内部设置 API 为每个空间设置securitySolution:defaultIndex 。
在高峰期，所有 40 团队每秒都要接收 800,000 个事件 (EPS)。这是一个巨大的数据量，由于 Elastic Cloud 的自动扩展功能，集群可以轻松地处理这些数据。鉴于此，早在 2018 时，我们就与 eBay 合作，每秒处理 5 万个事件。
数据生命周期由索引生命周期管理（ILM）策略管理，该策略在一天后或50 GB（以先到者为准）后滚动索引，在两天后将其转入预热阶段进行只读优化和强制合并，然后在十天后删除数据。因此，在维持演习窗口要求的同时，存储成本也降到了最低。下面举例说明如何实施 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，在每个空间创建一个代理策略，启动 6000 个 EC2 实例（每个租户 120 个，跨越三个可用性区域的六个子网），并对这些实例进行负载测试。我们使用 AutoOps 和 Stack Monitoring 监控一切。
部署流程是这样的：Terraform 跨三个可用区创建了 VPC 和子网，配置了 50 Kibana Spaces 及其空间范围内的 Fleet 策略，生成了注册令牌，然后分批启动了 EC2 实例。每个实例在启动时都安装了 Elastic Agent，并根据其特定空间的令牌进行注册。
一路上，我们遇到了一些有趣的挑战。标准的 Elastic Stack Terraform Provider 当时并不支持空间感知的 Fleet 操作，因此我们对其进行了分叉，并在 Fleet 资源中添加了空间 ID 处理功能--如果不做这一修改，每个代理都会注册到默认空间，而不管策略分配如何。这并不是我们第一次为演习扩展提供程序；两年前，我们为 DCM2 增加了elasticsearch_cluster_info 数据源。幸运的是，上游供应商在0.12.2 版本中添加了support for space_ids 。
在尝试同时启动所有 6000 个实例时，我们还遇到了 AWS EC2 API 速率限制，因此我们在 500 实例上进行了分批部署，并在批次之间设置了 5 分钟的冷却期。
结果令人欣慰。所有 6000 个代理通常在部署后 20 分钟内完成注册。在我们的测试中，空间隔离效果符合预期，没有观察到租户之间的数据泄漏。机群策略更新在 60 秒内传播到所有代理。在满负荷情况下，针对单个空间的搜索查询速度仍然很快。事实证明，多可用区分布在模拟可用区故障时具有弹性。
这次测试给了我们信心，使我们能够在实际演练中采用该架构。
红队C2 植入可观察性
为 "红队 "单独建立了一个专门的 Elastic 部署，重点是指挥和控制（C2）植入可观察性。这样，攻击小组就能看到自己的行动，包括植入状态、信标回调和行动进展，而不会有与蓝队数据交叉污染的风险。红队使用 Tuoni 作为他们的 C2，这是由 Clarified Security 为红队开发的一个框架。在 DCM3 中，我们与 Clarified Security 合作，确保其正确支持 Elastic 通用模式，使未来与 Elastic 的集成更加容易。
NSOC： 网络安全运行中心演习
核心演习网络安全运行中心（NSOC）在自己的 Elastic 部署上运行，为演习控制人员提供范围健康状况的总体视图、整个基础设施的安全监控，以及我们部署的所有人工智能服务的审计日志。在此部署中，每一次Bedrock API 调用都会被记录在 CloudWatch 中，并且可以被观察到，这意味着 NSOC 可以完全了解向人工智能代理提出了什么要求以及由谁提出的要求。下文人工智能部分将对此进行详细介绍。
基础设施自动化：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 管理的总资源足迹非常可观：一个带自动扩展功能的弹性云部署、 40 Kibana Spaces、 120 Fleet 代理策略（每个团队三个）、400 多个集成策略、 40 Kibana 安全角色、 40 Keycloak 角色映射、用于数据保留的 ILM 策略、 41 用于 Bedrock GenAI 连接器的 AWS IAM 用户（每个团队空间一个，外加一个默认用户）、 41 Kibana GenAI 操作连接器、AWS Bedrock 护栏、用于 Tines 访问的 Cloudflare 零信任隧道、每个团队空间的 Tines 操作连接器、存储在 HashiCorp Vault 中的检测服务帐户以及每个空间的安全解决方案默认索引配置。所有状态都存储在加密的 S3 后端。
在实际范围系统上部署代理和代理时，我们使用了Catapult，这是一款由 Clarified Security 团队开发的优秀开源工具。Catapult 使用基于容器的执行模型对 Ansible 进行包装，该模型专为网络范围部署而设计。它负责在整个基础设施范围内安装和注册弹性代理。代理服务器的配置（每个团队都为其部署的网络配置了专用的 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 警报以及熟悉时间线调查工具。
演习指导本身指出，这次培训是可选的，但"强烈推荐，" ，从我们所见，参加培训的团队在第一天的执行中就完全进入了状态。培训和启用与技术部署本身同样重要。把企业级的安全工具交给一个不知道如何使用的团队，对任何人都没有帮助。
在线人工智能服务：合规、审计、防护
今年是我们首次为 DCM 系列提供人工智能接入服务。我们在英国租用的 AWS Bedrock 模型（特别是在 eu-west-2（伦敦）地区运行的 Claude 3.7 Sonnet）的支持下，直接提供了符合要求的人工智能服务。这不是为了人工智能而人工智能；这是一种精心架构的服务，具有防护栏、完整的审计日志和 RBAC 感知访问控制。由于 Elastic 在人工智能领域拥有丰富的经验，我们获得了运行这项服务的信任。
人工智能服务的范围内有多个消费者，这是一个重要的区别。我们为每个团队的空间配置的合规 Bedrock 连接器不仅为我们的自定义代理提供动力，还特别为 Elastic 的原生人工智能功能提供动力：
Elastic AI Assistant for Security
Elastic AI Assistant可在每个 Blue Team 空间中使用，并与我们的在线 Bedrock 连接器相连。这为团队提供了一个直接在 Elastic Security 中进行上下文感知的聊天界面，他们可以在这里询问有关警报的问题，获得编写 ES|QL 查询的帮助，调查可疑进程，并获得指导性补救步骤。人工智能助理使用检索增强生成（RAG）和 Elastic 的知识库功能，知识库中预先填充了来自Elastic 安全实验室的文章。各小组还可以在知识库中添加自己的文件，如针对特定范围的 SOP、威胁情报或小组说明，使助理的响应更符合其行动背景。
在演习中，人工智能助理能够帮助经验不足的分析师理解他们正在观察的内容，这一点尤其宝贵。初级分析师第一次面对实时植入信标时，可以请助理解释警报，建议调查步骤，甚至帮助起草事件报告。数据匿名化设置可确保敏感字段值在发送给 LLM 提供商之前被混淆。
弹性攻击发现
攻击发现 "是我们在役人工智能服务的另一个重要客户。攻击发现使用 LLM 来分析团队环境中的警报，并通过关联警报、行为和攻击路径来识别威胁。每个"discovery" 代表一种潜在攻击，并描述多个警报之间的关系--告诉团队涉及哪些用户和主机，警报如何映射到 MITRE ATT& CK 矩阵 ，以及哪个威胁行为者可能对此负责。
在红队积极发起协调攻击的网络演习中，"攻击发现 "是一次变革。蓝队可以运行 "攻击发现"（Attack Discovery）来揭示高层次的攻击叙事，而不是手动分流数百个单个警报，例如，"，这些 15 警报都是从主机 X 到主机 Y 的横向移动链的一部分，很可能是由威胁行为者 Z" ，并将调查时间集中在最重要的地方。这种能力可以直接缩短平均反应时间，消除警戒疲劳，而这正是连续五天受到持续攻击时所需要的。
自定义人工智能代理弹性代理生成器
除了原生的 Elastic AI 功能外，我们还使用 Elastic Agent Builder 构建 了三个定制的 AI 代理 。Agent Builder 是 Elastic 用于构建自定义人工智能代理的框架，它将 LLM 指令与模块化、可重复使用的工具相结合，每个工具都是 ES|QL 查询、内置搜索功能、工作流执行或通过 MCP 进行外部集成。代理可解析自然语言请求、选择适当的工具、执行这些工具并进行迭代，直到能够提供完整的答案，同时利用 Elasticsearch 中的数据管理上下文。您可以在Agent Builder 文档和Elasticsearch Labs 深入研究中阅读有关该框架的更多信息。
我们利用了 Agent Builder 的三个关键组件：
代理：自定义 LLM 指令和一套指定工具，用于定义代理的角色、能力和行为边界。每个代理都有一个系统提示，控制着它的任务、可以使用的工具以及反应的结构。
工具：代理用于搜索、检索和操作 Elasticsearch 数据的模块化功能。我们构建了定制的 ES|QL 工具，可查询包含练习文档、操作手册和报告的特定索引。
代理聊天：对话界面--包括内置的 Kibana UI 和编程 API--参与者用来与代理进行交互。
代理和工具配置定义为 JSON 格式，并通过代理生成器 API 进行管理，从而使整个代理生命周期（从提示工程到工具绑定）都具有可复制性和版本可控性。我们将在后续文章中分享 GrantPT 代理配置和工具定义，供希望复制这种方法的用户参考--敬请留意。
以下是每位特工的工作：
1.GrantPT - 通用助手
GrantPT 是我们最主要的人工智能代理，也是 Agent Builder 如何直接建立一个功能强大的特定领域助手的最佳演示。代理的配置由一个 JSON 对象组成，该对象定义了代理的系统提示、角色和一个绑定工具 ID 数组，仅此而已。无需自定义应用程序代码，无需定制 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 安全模型，系统提示指示代理根据用户的角色和底层 Elasticsearch 安全模型确定答案的上下文。由于每个工具的 ES|QL 查询都是在用户的安全上下文中执行的，因此代理只能显示用户角色可访问的文档。蓝队成员在询问演习程序时，会得到其团队可访问指数的结果，而服务台分析员则会看到服务台特定指数的结果。代理不需要明确的角色切换逻辑；Elasticsearch 的本地文档级安全性处理了范围界定，代理只需处理返回的任何结果即可。这也是 Agent Builder 真正优雅的原因之一--通过继承 Elasticsearch 的安全模型，你无需编写任何授权代码就能获得 RBAC 感知的人工智能。
2.REDRock - 对手的伙伴
该特工只供红队使用。REDRock 采用了相同的代理生成器模式，即通过专用系统提示来定义其敌对角色，并与自己的一套定制 ES|QL 工具绑定，以查询红队专用索引。这些索引包含红队手册、Tuoni C2 文档、靶场环境中已知的系统漏洞以及已部署服务的相关信息。工具定义与 GrantPT 使用的参数化语义搜索模式相同，但其范围仅限于红队角色可访问的索引。红队操作员可以查询攻击载体，检查目标系统的已知弱点，并获得有关其行动计划的背景指导。坦率地说，这就好比给袭击者配备了一个非常熟悉情况的作战参谋。
3.RefPT - 裁判工具
RefPT 专为白队（演习裁判和评估员）而建，与包含蓝队报告、情景事件和评分标准的索引查询工具绑定。其目的是确保所有 40 多支队伍的评分统一、公平。代理的系统提示经过调整，可将提交的报告与已知的情景事件和评分标准进行交叉比对，帮助评估人员找出不一致或差距。当评估员同时评估几十个团队时，如果有一个人工智能能根据结构化评分指标对报告进行关联，就能真正实现一致性的变革。
Tines：人工智能驱动的工作流程自动化
Tines 也是在线人工智能服务的消费者。每个蓝队都有一个专用的 Tines 实例，并在其 Kibana 空间中配置了 Tines 行动连接器。Tines 可利用 Bedrock 支持的人工智能功能实现智能工作流程自动化，如自动警报丰富化、人工智能辅助分流决策、通知工作流程中的自然语言摘要以及自然语言工作流程创建。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/"
})
}确保合规：防护栏和审计
所有这些消费者之间的每一次人工智能交互都受到严格的 AWS Bedrock Guardrails 监管。我们部署了防护栏，包括内容过滤（仇恨、侮辱、性内容和暴力的中等阈值）、PII 保护（阻止电子邮件地址、电话号码、姓名、地址、英国国民保险号码、信用卡号码和 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"
}
}
}每个蓝色团队空间都有自己的 IAM 用户来访问 Bedrock，并强制执行genAiSettings:defaultAIConnectorOnly Kibana 设置，以防止团队配置自己的连接器。这意味着每个 API 调用都可以通过 CloudWatch 追溯到特定的团队，NSOC 拥有完全的审计可视性。CloudWatch 日志组/aws/bedrock/grantpt-prod/invocations 捕获了每个调用和护栏事件。
所有人工智能消费者的数据不言自明： 3 自定义人工智能代理、2,797 次对话以及在整个活动中消耗的 785 百万人工智能代币。
游戏内实时监控
在演习场景中，每个团队都可以使用 RocketChat 作为他们的远程信息客户端。每个 "蓝队 "都有自己的频道，可以直接向演习中的任何人发送信息，还可以根据需要自由创建新的频道。对于 DCM 传统来说，最重要的是包括 "memes "频道--它是所有团队间调侃的精神支柱，也是鼓舞士气的创造性幽默，当你把几千名网络操作员放在压力下一周时，就不可避免地会出现这种幽默。
所有这些通信数据都是一个绝佳的实时窗口，让我们可以了解整个演习的健康状况、团队情绪和话题趋势。这种感觉太好了，所以我们将整个 RocketChat 会话语料库实时导入 Elastic 并投入使用。
情感分析和命名实体识别
在命名实体识别方面，我们使用 Elastic ELAND 客户端 将来自 Hugging Face 的 dslim/bert-base-NER 模型部署到 NSOC 部署的机器学习节点中。然后将其连接到 Elasticsearch 的摄取管道中，每条 RocketChat 消息在摄取时都会经过该管道。我们将提取的实体作为仪表板主题，并将最常见的实体浮出水面，这样我们就能实时了解整个活动中对话主题的起伏。
我们还分析了群组活动、用户统计数据和一般交流模式，以了解每个团队的生活模式--最活跃的参与者、随时间变化的信息量以及以单个用户为中心的情感趋势。总之，它让我们真正有趣地了解了近乎实时的靶场情况。例如，当我们将 Elastic Agent 切换到 "预防 "模式时，仪表板上的词云立即亮了起来，"Elastic" ，成为所有渠道中讨论最多的主题--蓝队讨论其有效性，红队哀叹信标丢失。相当令人满意。
备忘录分析（是的，真的）
最后--这一点引起了一些人的注意--我们调出了提交到频道的所有备忘录，对图像进行了矢量化处理，并进行了最近邻评估，以便将相似的备忘录和主题聚类在一起。我们还将这些内容通过零镜头 NER 推理模型，以生成每个备忘录内容的主题描述。这样做的逻辑是，这些输出可能会在以后的过滤、审核或其他游戏内互动中被证明是有用的。对备忘录的分析是否产生了对行动至关重要的情报还值得商榷。至于是否好玩，就不得而知了。
将问题消灭在萌芽状态
尽管我们希望在演习周期间一切都能顺利进行，但还是不可避免地会出现一些问题，或者没有完全理解，或者需要进一步定制以适应特定团队的使用方式。为此，我们在in-range 服务台中设立了自己的分区，任何团队都可以在这里提出针对 Elastic 和 GenAI 的请求。
在整个演习期间，我们都在这个服务台值班，提供指导、文件、问题调试和针对具体范围的建议。最后一点值得进一步说明。有时，蓝队在 Elastic 中看到的问题实际上根本不是 Elastic 的问题，而是 Elastic 在范围内忠实地显示了需要进一步调查的东西（红队可能会造成绝对的混乱，遥测不会说谎）。在这次演习中，我们覆盖了 125 个人支持请求，这些请求来自专门向我们 Elastic 寻求帮助的团队。
使用 Tines 进行抢先调试
除了通过 VTC 或在 EXCON 上亲自访问团队外，我们还与Tines合作，尝试一些更积极主动的方式。我们从接收到的请求中提取票单正文，尝试对问题进行分类，将分类结果与我们以前解决过的票单语料库进行比对，并让 GenAI 在分流将用户的问题提交到我们的队列之前，生成旨在解决用户问题的第一道摘要回复。
这实际上是我们从 Elastic 自己的 支持组织 中借鉴的一种模式，我们在那里提供了类似的功能，将我们以前解决过的问题的广泛知识库作为支持人工智能代理上下文的资料库。这个想法很简单：利用过去的解决方案，让机器在知情的情况下第一时间解决问题，缩短支持工程师手动处理每张单子的时间。这并不能解决所有问题；有些问题确实需要一个有范围背景的人工来解决，但它有效地减少了排队压力，并为需要的团队提供了更快的答案。在我们自己的特定票单和队列中取得了如此大的成功，以至于在演习的后半段，我们实际上将范围扩大到了整个服务台，帮助减轻了绿色团队中支持演习的其他小组的负担。
行业伙伴关系：携手共进
最令我们自豪的是，我们的合作伙伴生态系统逐年发展壮大。DCM 不仅仅是一个 Elastic 展会；它是一个真正的行业合作伙伴联盟，每个合作伙伴都为安全平台带来了独特的东西。
1 (DCM2)- Elastic 作为行业合作伙伴加入，提供安全监控和端点检测平台。
2 (DCM3)- 我们引入了 Endace，提供 1:1 数据包捕获能力。全数据包捕获和 Elastic 的网络可视性为团队提供了进行深度取证的能力，这是基于日志的分析所无法提供的。
3 (DCM4)- Tines 加入了这个大家庭，带来了工作流程自动化。现在，Blue Teams 可以构建自动响应工作簿、分流工作流和通知链，所有这些都通过本地 Tines 连接器直接集成到 Elastic 环境中。
4 年（DCM26，前身为DCM5）--AWS 加入，为我们的人工智能代理提供 Bedrock 访问权限，并为弹性部署提供资金。这是一个重要的里程碑；超级分频器直接投资于演习的成功，从而释放了各种能力（例如，符合规定的、英国租用的人工智能推理，以及完整的防护和审计日志），如果没有超级分频器，这些能力根本无法实现。今年，Tines 的整合工作也因增加了对 LLM 的在线访问而得到加强。DCM 系列今年还达到了一个里程碑，从最初的陆军网络协会倡议过渡到网络和专家行动指挥部下的官方资助计划。
衷心感谢 Endace、Tines 和 AWS 团队。有了你们的贡献，这项工作才会做得更好；有了我们共同搭建的平台，所有团队才会有更好的装备。我们已经在为 DCM27 做准备了。为你们干杯
文化、亮点和值得一去的地方
挑战硬币
我们为 DCM26 铸造了定制挑战币。如果你知道，你就会知道，挑战硬币是一个由来已久的军事传统，为这次演习制作一枚挑战硬币是纪念我们参与演习第四年的正确方式。
鸡尾酒会
我们还应邀参加了英国驻新加坡高级专员举办的高级专员公署鸡尾酒会。在大使的邀请下，我们一边喝着杜松子酒和奎宁水，一边讨论 Elasticsearch 的碎片数量和 Terraform 的状态管理，这种感觉很不真实。这是一个精彩的夜晚，它真切地提醒人们，这些演习存在于技术与外交的交汇点，在这里建立的关系远远超出了技术层面。
Wrapping up
多租户架构在持续负载下证明了自己的能力；本地弹性人工智能功能（人工智能助理和攻击发现）为团队提供了几年前还属于科幻小说的能力；定制人工智能代理的采用超出了我们的预期。伙伴关系模式继续证明，工业界参与国防演习所取得的成果是任何一个组织都无法单独实现的。
国防网络奇迹 2026 是一次具有里程碑意义的演习，其雄心、复杂性和影响都在不断扩大。对于 Elastic 来说，能够为 40 Blue Teams（来自 29 国家的蓝队）提供核心防御安全平台以及今年的人工智能能力，是我们不可轻视的。演习为真正的人培养了真正的技能，这些人将继续保卫真正的网络，而参与这项任务是真正有意义的。
正如英国政府的新闻稿所说，DCM 展示了加强国际伙伴关系的真实情景的实用价值。我们完全同意。
明年我们还会再来，我想我们会有更多的话题。与此同时，我们将继续改进产品，使对防御网络奇迹等环境的支持逐年增强。
靶场见
在社交媒体上关注 DCM26 的故事：
Facebook | LinkedIn | Instagram
延展阅读
弹性安全& AI
- 弹性安全- 支持 "蓝色小组 "部署的平台
- 人工智能安全助手--Elastic Security 中的情境感知人工智能聊天工具
- 攻击发现- 由 LLM 支持的警报关联和威胁描述生成
- 代理生成器- 利用 Elasticsearch 构建自定义人工智能代理的框架
基础设施& 工具
- 弹性堆栈 Terraform 提供商--弹性堆栈的基础设施即代码
- 弹性机群指南- 大规模集中管理弹性代理
- Clarified Security 的 Catapult- 基于 Ansible 的网络范围配置
练习背景
- 英国政府 DCM26 新闻稿--演习官方概述