Por onde começar? Pelo quarto ano consecutivo, a Elastic teve o privilégio de atuar como parceira de confiança do setor no Exercise Defence Cyber Marvel, a principal série de exercícios cibernéticos do Ministério da Defesa do Reino Unido. O DCM26 foi, sem dúvida, a versão mais ambiciosa até agora, e estamos muito contentes por finalmente podermos falar sobre o que construímos, como o construímos e o que aprendemos ao longo do caminho.
O que é o Defence Cyber Marvel?
Para quem não conhece, o Defence Cyber Marvel (DCM) é a maior série de exercícios cibernéticos militares do Reino Unido, focada na defesa de redes de TI tradicionais, ambientes corporativos e sistemas complexos de controle industrial em cenários realistas e de alta pressão. Isso demonstra o poder cibernético responsável, ao mesmo tempo que aprimora a prontidão, a interoperabilidade e a resiliência em toda a Defesa e nações aliadas. Agora em seu quinto ano, o DCM evoluiu de uma iniciativa da Associação Cibernética do Exército para uma operação conjunta das três forças armadas, liderada pelo Comando de Operações Cibernéticas e Especializadas (CSOC).
O Governo do Reino Unido publicou um comunicado de imprensa oficial sobre a DCM26, que oferece uma excelente visão geral da importância estratégica do exercício. Como observou o Alto Comissário Britânico em Singapura, o exercício demonstra a profunda cooperação entre o Reino Unido e parceiros de confiança, um lembrete da força das parcerias estratégicas compartilhadas em um cenário de segurança cada vez mais complexo.
Em sua essência, o DCM é um exercício cibernético de combate entre duas forças: as equipes azuis (Blue Teams) protegem suas redes e infraestrutura designadas contra ataques das equipes vermelhas (Red Teams), utilizando uma variedade de técnicas. As atividades abrangem desde a alteração de senhas padrão e o reforço da segurança de firewalls até a implementação de defesa cibernética de nível empresarial, baseada em IA, com o Elastic Security. As atividades de cada equipe são monitoradas pela Equipe Branca para estabelecer uma pontuação que leva em consideração a disponibilidade do sistema, a detecção de ataques, o relato de incidentes e a restauração do sistema. O exercício desafia as equipes mais experientes, ao mesmo tempo que oferece um mecanismo de treinamento exclusivo para equipes juniores em seu primeiro contato com um ambiente de simulação cibernética, e essa dupla finalidade é o que torna o DCM um exercício tão valioso.
A escala de DCM26
O DCM26 reuniu mais de 2.500 pessoas de 29 países participantes e 70 organizações, coordenadas a partir de um Centro de Controle de Exercícios (EXCON) com sede em Singapura, com o EXCON hospedando mais de 600 participantes. O exercício foi realizado em um ambiente de computação híbrido que abrangia o campo de testes cibernéticos CR14 e a AWS, hospedando mais de 5.000 sistemas virtuais.
O exercício em si teve duração de cinco dias (de 9 a 13 de fevereiro de 2026), precedido por treinamento prévio opcional conduzido por instrutores e verificações de conectividade. O cenário, baseado no Ambiente Operacional Indo-Pacífico do Ambiente de Treinamento da Academia de Defesa (DATE), colocou equipes como Equipes de Proteção Cibernética defendendo sistemas militares implantados durante uma crise regional crescente. As Equipes Azuis estavam geograficamente dispersas, algumas em suas localidades de origem no Reino Unido e internacionalmente, outras implantadas no exterior, todas conectadas ao ambiente de simulação via VPN.
Os participantes incluíram representantes da Defesa do Reino Unido, departamentos intergovernamentais como a Agência Nacional de Combate ao Crime, o Departamento de Trabalho e Pensões, o Gabinete do Governo e o Departamento de Negócios e Comércio, juntamente com parceiros internacionais formando até 40 equipes. Após o sucesso do exercício realizado no ano passado na República da Coreia, Singapura serviu como centro de treinamento pela primeira vez, refletindo o compromisso do Reino Unido em aprofundar a cooperação com os parceiros da região Indo-Pacífica em desafios de segurança compartilhados.
Resumindo, é um exercício sério. Alta pressão, confronto direto, com consequências reais para a pontuação e resultados de aprendizagem concretos para cada participante.
As implantações: Nossa infraestrutura elástica
A infraestrutura deste ano representou uma evolução arquitetônica significativa em relação às versões anteriores. Em vez de implantar clusters Elastic Cloud individuais por equipe, optamos por uma implantação única e multilocatária do Elastic Cloud baseada em espaço para as Equipes Azuis. Também realizamos implantações para funções fora das Equipes Azuis. Vou explicar cada implementação e o motivo de sua existência.
Equipes Azuis: Segurança Elástica Multilocatária
A peça central da nossa contribuição foi uma única implementação do Elastic Cloud servindo todas as 40 equipes azuis de defesa, separadas usando Kibana Spaces e namespaces de fluxo de dados. Cada uma das equipes 39 tinha seu próprio espaço de trabalho isolado, incluindo painéis, agentes e regras de detecção.
Eis como o recurso Terraform se parecia para criar o espaço de cada equipe:
# 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"
}O espaço de cada equipe recebeu um conjunto dedicado de três políticas de agentes Fleet : no primeiro dia, uma política de rede implantada; no segundo dia, uma política de rede do país anfitrião; e, por fim, uma política PacketCapture para monitoramento do tráfego de rede. O controle de acesso em fases era elegante em sua simplicidade: definir enable_hostnation_network = true em nosso terraform.tfvars e executar terraform apply expandia as permissões de função de cada equipe e tornava sua política de agente do país anfitrião visível em seu espaço. O exercício passou de uma para duas redes sem um único clique manual no Kibana.
O isolamento de dados dependia de namespaces de fluxo de dados. Cada política de agente é escrita em namespaces específicos da equipe, como bt_01_deployed e bt_01_hostnation, produzindo fluxos de dados seguindo o padrão:
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_hostnationA função de segurança do Kibana de cada equipe foi então restringida apenas aos fluxos de dados que utilizam blocos de privilégios de índice dinâmico:
# 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"]
}
}A autenticação foi feita via Keycloak SSO, com mapeamentos de funções do Elasticsearch conectando grupos do Keycloak a funções do 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]}"
}
})
}As políticas de integração padrão eram simples por definição. Cada equipe recebeu: Sistema para telemetria do sistema operacional principal, Elastic Defend para detecção e resposta de endpoints, encaminhamento de eventos do Windows, Auditd para registro de auditoria do Linux e integrações de captura de pacotes de rede. Isso representa mais de 400 políticas de integração gerenciadas como código por meio do provedor Terraform do Elastic Stack.
Uma observação sobre o Elastic Defend: devido à eficácia da proteção de endpoints da Elastic — que é utilizada em produção pelo Departamento de Defesa e pela Comunidade de Inteligência dos EUA (saiba mais aqui ) — e ao fato de que ninguém em sã consciência usaria exploits de dia zero em um exercício de treinamento, somos obrigados a limitar o Elastic Defend desativando o modo Prevent e deixando-o apenas no modo Detect. As equipes recebem alertas quando algo malicioso acontece, mas sem nenhuma mitigação automática. Desativamos completamente a Prevenção e Detecção de Ameaças na Memória, pois isso descobre a maioria dos implantes e beacons das equipes atacantes, o que prejudicaria o jogo para as Equipes Vermelhas. Na fase final do exercício, permitimos que as equipes utilizassem o Elastic Defend em toda a sua capacidade, mas não sem antes dar às equipes vermelhas uma posição sólida.
Também pré-instalamos as regras de detecção predefinidas da Elastic em cada espaço de equipe — o conjunto completo do Elastic Security Labs, continuamente atualizado em um repositório aberto. Essas regras foram configuradas para garantir que consultassem apenas os índices permitidos pelas permissões de escopo de namespace da equipe, evitando qualquer vazamento de dados entre equipes durante a execução das regras de detecção.
Além disso, cada espaço de equipe teve seu índice padrão da Solução de Segurança configurado para restringir as regras de detecção apenas aos fluxos de dados daquela equipe, em vez do padrão amplo padrão. Isso foi tratado por um Terraform null_resource que chamou a API de configurações internas do Kibana para definir securitySolution:defaultIndex para cada espaço.
No pico, esta implementação estava ingerindo 800.000 eventos por segundo (EPS) em todas as equipes 40 . Trata-se de uma quantidade considerável de dados, e o cluster lidou com isso sem problemas graças aos recursos de escalonamento automático do Elastic Cloud. Dito isto, em 2018 estávamos a fazer 5 milhões de eventos por segundo com o eBay.
O ciclo de vida dos dados era gerenciado por uma política de Gerenciamento do Ciclo de Vida do Índice (ILM) que rotacionava os índices após um dia ou 50 GB (o que ocorresse primeiro), os movia para uma fase ativa após dois dias para otimização somente leitura e fusão forçada e, em seguida, excluía os dados após dez dias. Como resultado, os custos de armazenamento foram minimizados, mantendo-se os requisitos da janela de tempo para exercícios. Segue abaixo um exemplo de como a política ILM foi implementada.
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
}
}
}O teste de estresse de fragmentação: comprovando a multilocação em escala
Antes de nos comprometermos com essa arquitetura para um exercício militar real, precisávamos comprovar que ela seria capaz de atender aos nossos requisitos e de ter um sistema de contingência adequado em caso de problemas. A transição de implantações individuais para um único cluster multi-inquilino introduziu riscos reais: disputa por recursos, gargalos de ingestão, vazamento de dados entre espaços devido a configurações incorretas, grande número de conexões TCP nos nós do Elasticsearch e um número significativamente maior de shards, já que cada equipe gera seu próprio conjunto de índices.
Então construímos uma plataforma de testes dedicada. O plano era simples: implantar 50 Espaços Kibana, criar uma política de agente em cada espaço, iniciar 6.000 instâncias EC2 (120 por locatário, em seis sub-redes em três zonas de disponibilidade) e testar a carga de todas elas. Monitoramos tudo com AutoOps e Stack Monitoring.
O fluxo de implantação funcionou da seguinte forma: o Terraform criou a VPC e as sub-redes em três zonas de disponibilidade, provisionou os Espaços Kibana 50 e suas políticas Fleet com escopo de espaço, gerou tokens de inscrição e, em seguida, lançou instâncias EC2 em lotes. Cada instância instalava o Elastic Agent na inicialização e se registrava com seu token específico do espaço.
Enfrentamos alguns desafios interessantes ao longo do caminho. O provedor Terraform padrão do Elastic Stack não suportava operações do Fleet com reconhecimento de espaço na época, então fizemos um fork e adicionamos o gerenciamento de IDs de espaço aos recursos do Fleet - sem essa modificação, todos os agentes teriam se inscrito no espaço padrão, independentemente da atribuição de política. Esta não foi a primeira vez que tivemos que estender o provedor para um exercício; dois anos atrás, para o DCM2, adicionamos a fonte de dados elasticsearch_cluster_info . Felizmente, o fornecedor upstream adicionou support for space_ids na versão 0.12.2.
Também nos deparamos com limites de taxa da API EC2 da AWS ao tentar iniciar todas as 6.000 instâncias simultaneamente, então agrupamos as implantações em 500 instâncias com períodos de espera de cinco minutos entre os lotes.
Os resultados foram tranquilizadores. Normalmente, todos os 6.000 agentes eram cadastrados em até 20 minutos após a implantação. Em nossos testes, o isolamento espacial funcionou conforme o esperado, sem vazamento de dados observado entre os inquilinos. As atualizações de política da frota foram propagadas para todos os agentes em até 60 segundos. As consultas de pesquisa restritas a espaços individuais permaneceram rápidas mesmo sob carga máxima. E a distribuição multi-AZ demonstrou resiliência durante falhas simuladas de zonas de disponibilidade.
Esses testes nos deram a confiança necessária para adotar a arquitetura para o exercício em tempo real.
Equipes Vermelhas: Observabilidade do implante C2
Uma implementação Elastic separada e dedicada foi criada para as Equipes Vermelhas, com foco na observabilidade de implantes de Comando e Controle (C2). Isso permitiu que as equipes atacantes tivessem visibilidade de suas próprias operações, incluindo o status dos implantes, os retornos de chamada dos beacons e o progresso operacional, sem qualquer risco de interferência com os dados da Equipe Azul. As equipes vermelhas usaram o Tuoni como seu C2, que é uma estrutura desenvolvida pela Clarified Security para testes de intrusão. No DCM3, trabalhamos com a Clarified Security para garantir que ele suportasse adequadamente o Elastic Common Schema, facilitando muito a integração futura com o Elastic.
NSOC: Centro de Operações de Segurança de Rede para Exercícios
O exercício principal, o Centro de Operações de Segurança de Rede (NSOC), foi executado em sua própria implementação Elastic, fornecendo à equipe de controle do exercício uma visão abrangente da integridade do ambiente, monitoramento de segurança em toda a infraestrutura e, crucialmente, registro de auditoria para todos os serviços de IA que implantamos. Nesta implementação, todas as invocações da API do Bedrock foram registradas no CloudWatch e puderam ser observadas, o que significa que o NSOC tinha visibilidade completa do que estava sendo solicitado aos agentes de IA e por quem. Mais detalhes sobre isso na seção de IA abaixo.
Automação de infraestrutura: Terraform e Catapult
Tudo o que você viu acima foi gerenciado como Infraestrutura como Código. Nosso provider.tf dá uma ideia do ecossistema de provedores que estávamos orquestrando:
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
}
}A pegada total de recursos gerenciada pelo Terraform foi substancial: uma implantação do Elastic Cloud com escalonamento automático, 40 Kibana Spaces, 120 políticas de agente Fleet (três por equipe), mais de 400 políticas de integração, 40 funções de segurança do Kibana, 40 mapeamentos de função do Keycloak, políticas ILM para retenção de dados, 41 usuários do AWS IAM para conectores do Bedrock GenAI (um por espaço de equipe mais um padrão), 41 conectores de ação do Kibana GenAI, guardrails do AWS Bedrock, túneis Cloudflare Zero Trust para acesso ao Tines, conectores de ação do Tines por espaço de equipe, contas de serviço de detecção armazenadas no HashiCorp Vault e configuração de índice padrão da solução de segurança por espaço. Todo o estado foi armazenado em um backend S3 criptografado.
Para a implantação do agente e do proxy nos sistemas de alcance reais, utilizamos o Catapult, uma excelente ferramenta de código aberto desenvolvida pela equipe da Clarified Security. O Catapult integra o Ansible com um modelo de execução baseado em contêineres, desenvolvido especificamente para implantações em ambientes de testes cibernéticos. A função era responsável pela instalação e inscrição de Agentes Elásticos em toda a infraestrutura. A configuração dos servidores proxy (cada equipe tinha um proxy Squid dedicado para sua rede implantada; isso simulava um único ponto de saída, como ocorreria no mundo real). O tráfego estava sendo roteado por meio de endpoints como http://elastic-proxy.dsoc.XX.dcm.ex:3128), e a implantação de túneis Cloudflare para conectividade Tines.
Durante o provisionamento, os seguintes itens foram gravados no HashiCorp Vault pelo Terraform e consumidos pelo Catapult: credenciais, tokens de inscrição, chaves de API, configurações de proxy e credenciais da conta de serviço Tines. Os caminhos do Vault seguiam uma estrutura consistente como dcm/gt/elastic/prod/enrollment_tokens/BT-XX-Deployed e dcm/gt/elastic/tines-sa/tines-sa-btXX, tornando simples para os playbooks do Catapult obterem as credenciais corretas para cada equipe.
Treinamento: preparando equipes para o sucesso
Implantar a plataforma é uma coisa; garantir que as pessoas realmente consigam usá-la é outra. Fornecemos treinamento prático, conduzido por instrutores, às Equipes Azuis durante a fase de pré-exercício. Este treinamento abordou os fundamentos do Elastic Security , a navegação no espaço da equipe no Kibana, o trabalho com as regras de detecção predefinidas, o uso do Discover para análise de logs e busca de ameaças, a criação de painéis personalizados, a compreensão dos alertas do Elastic Defend e a familiarização com a ferramenta de investigação Timeline.
As instruções do exercício indicavam que esse treinamento era opcional, mas "altamente recomendado", e, pelo que vimos, as equipes que participaram começaram com o pé direito já no primeiro dia de execução. O treinamento e a capacitação são tão importantes quanto a própria implementação da tecnologia. Entregar a uma equipe ferramentas de segurança de nível empresarial que eles não sabem como usar não teria sido útil para ninguém.
O serviço On-Range AI: Em conformidade, auditado e protegido.
Este ano marcou nossa estreia no fornecimento de acesso por IA à linha DCM. Fornecemos um serviço de IA compatível diretamente no ambiente, com suporte de modelos AWS Bedrock hospedados no Reino Unido - especificamente o Claude 3.7 Sonnet em execução na região eu-west-2 (Londres). Não se tratava de IA pela IA em si; era um serviço cuidadosamente arquitetado com mecanismos de proteção, registro completo de auditoria e controles de acesso compatíveis com RBAC. Nos foi confiada a gestão deste serviço devido à experiência da Elastic na área de IA.
O serviço de IA tinha vários consumidores na área de atuação, e essa é uma distinção importante. O conector Bedrock compatível que provisionamos no espaço de cada equipe não apenas alimentava nossos agentes personalizados, como também os recursos nativos de IA da Elastic, especificamente:
Elastic AI Assistant for Security
O Assistente de IA Elástico estava disponível em todos os espaços da Equipe Azul, conectado ao nosso conector Bedrock de alcance. Isso proporcionou às equipes uma interface de bate-papo contextual diretamente no Elastic Security, onde elas podiam fazer perguntas sobre seus alertas, obter ajuda para escrever consultas ES|QL, investigar processos suspeitos e receber instruções guiadas para a correção dos problemas. O Assistente de IA utiliza a Geração Aumentada por Recuperação (RAG) com o recurso Base de Conhecimento da Elastic, que é pré-populado com artigos do Elastic Security Labs. As equipes também podem adicionar seus próprios documentos, como procedimentos operacionais padrão específicos para cada área de atuação, informações sobre ameaças ou anotações da equipe, à Base de Conhecimento para fundamentar ainda mais as respostas do assistente em seu contexto operacional.
O que tornou isso particularmente valioso no contexto do exercício foi a capacidade do Assistente de IA de ajudar os analistas menos experientes a entender o que estavam vendo. Um analista júnior que se depara com seu primeiro alerta de implante ativo pode pedir ao assistente que explique o alerta, sugira etapas de investigação e até mesmo ajude a redigir o relatório do incidente. As configurações de anonimização de dados garantiram que os valores dos campos sensíveis pudessem ser ocultados antes de serem enviados ao provedor do LLM.
Descoberta de Ataque Elástico
A detecção de ataques foi outro consumidor significativo do nosso serviço de IA em campo. A ferramenta de Descoberta de Ataques utiliza Modelos de Aprendizagem Baseados em Liderança (LLMs) para analisar alertas no ambiente de uma equipe e identificar ameaças, correlacionando alertas, comportamentos e caminhos de ataque. Cada "descoberta" representa um ataque potencial e descreve as relações entre vários alertas, informando às equipes quais usuários e hosts estão envolvidos, como os alertas se relacionam com a matriz MITRE ATT&CK e qual agente de ameaça pode ser o responsável.
Para um exercício cibernético no qual as Equipes Vermelhas lançaram ativamente ataques coordenados, o Attack Discovery foi transformador. Em vez de analisar manualmente centenas de alertas individuais, as equipes de segurança (Blue Teams) poderiam executar a Descoberta de Ataques para revelar as narrativas gerais do ataque, por exemplo, "estes 15 alertas fazem parte de uma cadeia de movimentação lateral do host X para o host Y, provavelmente pelo agente de ameaça Z", e concentrar seu tempo de investigação onde é mais importante. É o tipo de capacidade que reduz diretamente o tempo médio de resposta e combate a fadiga de alerta, que é exatamente o que você precisa quando está sob ataque contínuo por cinco dias seguidos.
Agentes de IA personalizados: Elastic Agent Builder
Além dos recursos nativos do Elastic AI, criamos três agentes de IA personalizados usando o Elastic Agent Builder. O Agent Builder é a estrutura da Elastic para criar agentes de IA personalizados que combinam instruções LLM com ferramentas modulares e reutilizáveis, sendo cada ferramenta uma consulta ES|QL, uma capacidade de pesquisa integrada, execução de fluxo de trabalho ou uma integração externa via MCP. Os agentes analisam solicitações em linguagem natural, selecionam as ferramentas apropriadas, executam-nas e iteram até conseguirem fornecer uma resposta completa, tudo isso enquanto gerenciam o contexto com dados dentro do Elasticsearch. Você pode ler mais sobre a estrutura na documentação do Agent Builder e no estudo aprofundado do Elasticsearch Labs.
Os três componentes principais do Agent Builder que utilizamos foram:
Agentes: Instruções LLM personalizadas e um conjunto de ferramentas atribuídas que definem a personalidade, as capacidades e os limites de comportamento do agente. Cada agente possui um comando de sistema que controla sua missão, as ferramentas às quais pode ter acesso e a estrutura de suas respostas.
Ferramentas: Funções modulares que os agentes usam para pesquisar, recuperar e manipular dados do Elasticsearch. Criamos ferramentas ES|QL personalizadas que consultavam índices específicos contendo documentação de exercícios, manuais e relatórios.
Chat do agente: A interface conversacional — tanto a interface de usuário integrada do Kibana quanto a API programática — que os participantes usavam para interagir com os agentes.
As configurações do agente e da ferramenta são definidas em JSON e gerenciadas pelas APIs do Agent Builder, tornando todo o ciclo de vida do agente — desde a engenharia de prompts até a vinculação da ferramenta — reproduzível e com controle de versão. Compartilharemos a configuração do agente GrantPT e as definições da ferramenta em uma publicação futura para aqueles que desejam replicar essa abordagem — fiquem atentos.
Eis o que cada agente fez:
1. GrantPT - O assistente de propósito geral
Disponível para todos os cerca de 2.500 participantes do exercício, o GrantPT foi nosso principal agente de IA e a melhor demonstração de como o Agent Builder facilita a criação de um assistente capaz e específico para um domínio. A configuração do agente consistia em um objeto JSON que definia seu prompt do sistema, sua persona e uma matriz de IDs de ferramentas vinculadas - só isso. Sem código de aplicação personalizado, sem camada de API sob medida, apenas configuração declarativa.
O que conferiu profundidade à GrantPT foram as ferramentas utilizadas. Definimos uma combinação de ferramentas integradas da plataforma e ferramentas ES|QL personalizadas, cada uma registrada com uma descrição, uma consulta parametrizada e definições de parâmetros tipados. Por exemplo, a ferramenta de base de conhecimento aceitou um parâmetro target_index e um parâmetro semântico query , executando uma consulta ES|QL parametrizada em nossos índices dcm5-grantpt-* com classificação de pesquisa semântica:
FROM dcm5-grantpt-* METADATA _score, _index
| WHERE _index == ?target_index
| WHERE content: ?query
| SORT _score DESC
| LIMIT 10Uma ferramenta separada de descoberta de índices permitia que o agente enumerasse dinamicamente os índices disponíveis na base de conhecimento no início de cada conversa, o que significava que podíamos adicionar novos índices de documentação durante o exercício sem reconfigurar o agente; ele simplesmente os descobriria na próxima interação.
Também desenvolvemos uma ferramenta de integração com o Jira que realizava buscas semânticas nos tickets de suporte recebidos, permitindo que a GrantPT exibisse o contexto relevante para a solução de problemas a partir de solicitações de suporte anteriores. Isso foi particularmente útil para os analistas do HelpDesk, que podiam consultar a GrantPT sobre problemas recorrentes e obter respostas baseadas no histórico real dos chamados, em vez de orientações genéricas.
O comportamento de resposta adaptado ao RBAC resultou de uma combinação do prompt do sistema do agente, que o instruía a contextualizar as respostas com base na função do usuário, e do modelo de segurança subjacente do Elasticsearch. Como a consulta ES|QL de cada ferramenta é executada dentro do contexto de segurança do usuário, o agente só pode exibir documentos acessíveis à função do usuário. Um membro da Equipe Azul que perguntasse sobre procedimentos de exercícios receberia resultados restritos aos índices acessíveis à sua equipe, enquanto um Analista de HelpDesk veria resultados de índices específicos do helpdesk. O agente não precisava de uma lógica explícita de troca de funções; a segurança nativa do Elasticsearch em nível de documento cuidava do escopo, e o agente simplesmente trabalhava com quaisquer resultados retornados. Essa é uma das características que torna o Agent Builder verdadeiramente elegante: ao herdar o modelo de segurança do Elasticsearch, você obtém IA compatível com RBAC sem escrever uma única linha de código de autorização.
2. REDRock - O companheiro do adversário
Este agente estava disponível exclusivamente para as Equipes Vermelhas. A REDRock seguiu o mesmo padrão do Agent Builder, um prompt de sistema dedicado que define sua persona adversária, vinculado ao seu próprio conjunto de ferramentas ES|QL personalizadas que consultam índices específicos da Equipe Vermelha. Esses índices continham os manuais de procedimentos da Equipe Vermelha, a documentação do C2 da Tuoni, as vulnerabilidades conhecidas do sistema no ambiente de teste e informações sobre os serviços implantados. As definições das ferramentas refletiam o mesmo padrão de busca semântica parametrizada usado pelo GrantPT, mas eram restritas a índices acessíveis apenas às funções da Equipe Vermelha. Os operadores da Equipe Vermelha podiam consultar vetores de ataque, verificar vulnerabilidades conhecidas nos sistemas-alvo e obter orientação contextual para seus planos operacionais. Sinceramente, foi como entregar aos atacantes um oficial de operações extremamente bem informado.
3. RefPT - A ferramenta do árbitro
Construído especificamente para a Equipe Branca (os árbitros e avaliadores do exercício), o RefPT foi integrado a ferramentas que consultavam índices contendo relatórios da Equipe Azul, eventos do cenário e os critérios de pontuação. Seu objetivo era garantir uma pontuação uniforme e justa em todas as mais de 40 equipes. O sistema do agente foi configurado para comparar os relatórios enviados com eventos de cenário conhecidos e critérios de avaliação, ajudando os avaliadores a identificar inconsistências ou lacunas. Quando você tem avaliadores analisando dezenas de equipes simultaneamente, contar com uma IA capaz de correlacionar relatórios com um índice de pontuação estruturado é verdadeiramente transformador para a consistência.
Tines: Automação de fluxo de trabalho com inteligência artificial
Tines também era consumidor do serviço de IA disponível no local. Cada Equipe Azul tinha uma instância dedicada do Tines, com conectores de ação do Tines provisionados em seu espaço do Kibana. A Tines poderia aproveitar os recursos de IA apoiados pela Bedrock para automação inteligente de fluxos de trabalho, como enriquecimento automático de alertas, decisões de triagem assistidas por IA, resumos em linguagem natural em fluxos de trabalho de notificação e criação de fluxos de trabalho em linguagem natural. O conector Tines foi configurado por equipe com credenciais armazenadas no 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/"
})
}Garantindo a conformidade: diretrizes e auditoria
Todas as interações de IA entre todos esses consumidores foram regidas pelas rigorosas diretrizes do AWS Bedrock Guardrails. Implementamos mecanismos de proteção com filtragem de conteúdo (ódio, insultos, conteúdo sexual e violência em níveis MÉDIOS), proteção de informações pessoais (bloqueio de endereços de e-mail, números de telefone, nomes, endereços, números do Seguro Nacional do Reino Unido, números de cartão de crédito e endereços IP), filtragem baseada em tópicos para impedir discussões sobre operações classificadas reais e filtragem de palavrões. Aqui está um trecho da configuração do guardrail do nosso 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"
}
}
}Cada espaço da Equipe Azul tinha seu próprio usuário IAM para acesso ao Bedrock, e a configuração genAiSettings:defaultAIConnectorOnly do Kibana foi imposta para impedir que as equipes configurassem seus próprios conectores. Isso significava que cada chamada de API podia ser rastreada até uma equipe específica por meio do CloudWatch, e o NSOC tinha visibilidade completa da auditoria. O grupo de logs do CloudWatch /aws/bedrock/grantpt-prod/invocations capturou cada evento de invocação e proteção.
Os números para todos os consumidores de IA falam por si: 3 agentes de IA personalizados, 2.797 conversas e 785 milhão de tokens de IA consumidos durante o exercício.
Monitoramento em tempo real durante o jogo
No cenário do exercício, cada equipe tinha acesso ao RocketChat como seu cliente de mensagens para uso no campo de treinamento. Cada Equipe Azul tinha seu próprio canal, a possibilidade de enviar mensagens diretas para qualquer pessoa no exercício e a liberdade de criar novos canais conforme necessário. De forma crucial para a tradição da DCM, isso incluía o canal de memes – a espinha dorsal espiritual de todas as brincadeiras entre as equipes e o humor criativo que inevitavelmente surge ao colocar alguns milhares de operadores cibernéticos sob pressão durante uma semana.
Todos esses dados de comunicação representaram uma excelente visão em tempo real da saúde do campo de treinamento, do sentimento da equipe e dos tópicos que estavam em alta durante o exercício. A oportunidade era irresistível, então incorporamos todo o conjunto de conversas do RocketChat no Elastic em tempo real e o colocamos para funcionar.
Análise de sentimentos e reconhecimento de entidades nomeadas
Para o reconhecimento de entidades nomeadas, implementamos o modelo dslim/bert-base-NER da Hugging Face em um nó de aprendizado de máquina na implementação do NSOC usando o cliente Elastic ELAND. Em seguida, esse sistema foi integrado a um pipeline de ingestão do Elasticsearch, pelo qual todas as mensagens do RocketChat passavam durante a ingestão. Selecionamos as entidades extraídas e destacamos as mais comuns como temas do painel, o que nos proporcionou uma visão em tempo real do fluxo e refluxo dos tópicos de conversa ao longo do exercício.
Analisamos também a atividade do grupo, as estatísticas dos usuários e os padrões gerais de comunicação para construir um panorama dos padrões de vida de cada equipe: os participantes mais ativos, o volume de mensagens ao longo do tempo e as tendências de sentimento analisadas por usuários individuais. Em suma, isso nos proporcionou uma visão realmente interessante do que estava acontecendo no campo de tiro em tempo quase real. Quando ativamos o modo Prevent do Elastic Agent, por exemplo, uma nuvem de palavras em nosso painel imediatamente exibiu "Elastic" como o tema mais discutido em todos os canais - equipes de defesa discutindo sua eficácia e equipes de rastreamento lamentando a perda de seus beacons. Bastante satisfatório, isso.
Análise de memes (sim, sério)
Por fim — e isso causou alguma surpresa — reunimos todos os memes enviados aos canais, vetorizamos as imagens e executamos avaliações de vizinhos mais próximos para agrupar memes e tópicos semelhantes. Também os submetemos ao modelo de inferência NER zero-shot para gerar descrições temáticas do conteúdo de cada meme. A lógica era que esses resultados poderiam ser úteis posteriormente para filtragem, moderação ou outras interações dentro do jogo. Se a análise de memes forneceu informações operacionalmente críticas é algo discutível. Se foi divertido ou não, já não sei.
Cortar o mal pela raiz
Apesar de esperarmos que tudo corresse bem durante a semana de treinamento, inevitavelmente surgem problemas, as coisas não são totalmente compreendidas ou precisam de ajustes para se adequarem à forma como uma determinada equipe deseja utilizá-las. Para isso, tínhamos nossa própria subseção no helpdesk interno, onde solicitações específicas da Elastic e da GenAI podiam ser feitas por qualquer equipe.
Mantivemos esse serviço de suporte técnico em funcionamento durante toda a duração do exercício, fornecendo orientação, documentação, depuração de problemas e recomendações específicas para cada faixa de valores. Vale a pena aprofundar esse último ponto. Às vezes, o que uma equipe azul via no Elastic não era, na verdade, um problema do Elastic, mas sim o Elastic revelando fielmente algo no ambiente de teste que justificava uma investigação mais aprofundada (as equipes vermelhas podem causar um verdadeiro caos, e a telemetria não mente). Ao longo do exercício, atendemos a 125 solicitações de suporte individuais de equipes que pediram especificamente ajuda da Elastic.
Depuração preventiva com Tines
Além de visitar as equipes por videoconferência ou pessoalmente na EXCON, também trabalhamos com a Tines para tentar algo um pouco mais proativo. Extraímos o conteúdo dos tickets recebidos, tentamos categorizar o problema, comparamos a categorização com nosso conjunto de tickets resolvidos anteriormente e solicitamos ao GenAI que gerasse uma resposta inicial resumida, com o objetivo de solucionar o problema do usuário antes que a triagem o encaminhasse para nossa fila.
Na verdade, esse é um padrão que adotamos da nossa própria organização de suporte na Elastic, onde oferecemos uma funcionalidade semelhante usando nossa extensa base de conhecimento de problemas resolvidos anteriormente como um repositório para dar suporte ao contexto do Agente de IA. A ideia é simples: usar soluções anteriores para fornecer uma primeira tentativa automatizada e informada de resolver um problema, eliminando a necessidade de um engenheiro de suporte analisar cada chamado manualmente. Não resolveu tudo; alguns problemas realmente precisavam de um humano com conhecimento do contexto, mas reduziu significativamente a pressão na fila e proporcionou respostas mais rápidas às equipes que precisavam delas. Isso foi um sucesso tão grande com nossos próprios tickets e filas específicos que, na última parte do exercício, ampliamos o escopo para toda a central de atendimento, ajudando a reduzir a carga sobre os outros grupos da equipe Verde que davam suporte ao exercício.
Parcerias com a indústria: Juntos somos melhores.
Uma das coisas de que mais nos orgulhamos é de como nosso ecossistema de parcerias cresceu ano após ano. O DCM não é apenas um evento da Elastic; é uma verdadeira coalizão de parceiros da indústria, cada um trazendo algo único para a plataforma de segurança.
Ano 1 (DCM2) - A Elastic entrou como parceira do setor, fornecendo a plataforma de monitoramento de segurança e detecção de endpoints.
Ano 2 (DCM3) - Implementamos o Endace, fornecendo capacidade de captura de pacotes 1:1. A captura completa de pacotes, juntamente com a visibilidade de rede da Elastic, permitiu que as equipes realizassem análises forenses detalhadas que a análise baseada em logs sozinha não consegue fornecer.
Ano 3 (DCM4) - Tines juntou-se à família, trazendo a automação do fluxo de trabalho para a mesa. As equipes de segurança agora podem criar manuais de resposta automatizados, fluxos de trabalho de triagem e cadeias de notificação, tudo integrado diretamente ao seu ambiente Elastic por meio do conector nativo Tines.
Ano 4 (DCM26, anteriormente DCM5) - A AWS entrou em cena, fornecendo acesso ao Bedrock para nossos agentes de IA e contribuindo com financiamento para as implantações do Elastic. Este foi um marco significativo; ter um hiperescalador diretamente investido no sucesso do projeto desbloqueou capacidades (como inferência de IA compatível com as normas do Reino Unido, com todas as salvaguardas e registro de auditoria) que simplesmente não seriam possíveis de outra forma. A integração da Tines este ano também foi aprimorada com a adição de acesso direto aos LLMs (Locais de Aprendizagem de Longo Alcance) no campo de tiro. A série DCM também alcançou um marco este ano, passando de uma iniciativa da Associação Cibernética do Exército para um programa oficialmente financiado pelo Comando de Operações Cibernéticas e Especializadas.
Às equipes da Endace, Tines e AWS, nossos sinceros agradecimentos. Este exercício ficou melhor graças às suas contribuições, e todas as equipes estão mais bem preparadas graças à plataforma que construímos juntos. Já estamos planejando para o DCM27. Um brinde a todos vocês!
Cultura, destaques e os elementos que fazem valer a pena.
As Moedas de Desafio
Mandamos cunhar moedas comemorativas personalizadas para o DCM26. Quem conhece o assunto sabe que as moedas comemorativas são uma tradição militar antiga, e mandar fazer uma para o exercício pareceu a maneira ideal de marcar nosso quarto ano de participação.
A festa de coquetel
Ficamos também gratos por termos sido convidados para o coquetel oferecido pelo Alto Comissário Britânico em Singapura. Há algo de surreal em discutir a quantidade de shards do Elasticsearch e o gerenciamento de estado do Terraform enquanto se toma um gim-tônica a convite do embaixador. Foi uma noite brilhante, um verdadeiro lembrete de que esses exercícios existem na interseção entre tecnologia e diplomacia, e que os relacionamentos construídos aqui vão muito além do aspecto técnico.
Wrapping up
A arquitetura multi-inquilino provou seu valor sob carga sustentada; os recursos nativos de IA da Elastic (Assistente de IA e Descoberta de Ataques) proporcionaram às equipes capacidades que seriam ficção científica há alguns anos; e os agentes de IA personalizados superaram nossas expectativas de adoção. O modelo de parceria continua a demonstrar que o envolvimento da indústria em exercícios de defesa gera resultados que nenhuma organização sozinha conseguiria alcançar.
O Defence Cyber Marvel 2026 foi uma iteração marcante de um exercício que continua a crescer em ambição, complexidade e impacto. Para a Elastic, a confiança depositada em nós para fornecer a plataforma central de segurança defensiva para 40 equipes azuis de 29 nações, e este ano, também a capacidade de IA, é algo que levamos muito a sério. O exercício desenvolve habilidades reais em pessoas reais que irão defender redes reais, e fazer parte dessa missão é verdadeiramente significativo.
Conforme declarado no comunicado de imprensa do governo do Reino Unido , o DCM demonstra o valor prático de cenários da vida real que reforçam as parcerias internacionais. Não poderíamos concordar mais.
Estaremos de volta no ano que vem, e suspeito que teremos ainda mais assuntos para conversar. Entretanto, continuaremos a aprimorar o produto para que o suporte a ambientes como o Defence Cyber Marvel seja cada vez melhor ano após ano.
Nos vemos no campo de tiro.
Acompanhe a história da DCM26 nas redes sociais:
Facebook | LinkedIn | Instagram
Para ler mais
Segurança elástica e IA
- Elastic Security - A plataforma que impulsiona as implementações da Equipe Azul.
- Assistente de IA para Segurança - Chat de IA contextualizado dentro do Elastic Security
- Descoberta de ataques - Correlação de alertas e geração de narrativas de ameaças com tecnologia LLM
- Construtor de Agentes - Framework para criar agentes de IA personalizados com Elasticsearch
Infraestrutura e Ferramentas
- Provedor Terraform para Elastic Stack - Infraestrutura como Código para o Elastic Stack
- Guia da Frota Elástica - Gerenciando Agentes Elásticos de forma centralizada e em escala
- Catapult da Clarified Security - Provisionamento de ambiente cibernético baseado em Ansible
Contexto do exercício
- Comunicado de imprensa do governo do Reino Unido sobre o DCM26 - Visão geral oficial do exercício