Blog

Elastic no Defence Cyber Marvel 2026: uma visão geral técnica do local do exercício

Uma visão geral da infraestrutura de Elastic Security e IA implantada para dar suporte ao principal exercício cibernético do Ministério da Defesa do Reino Unido, o Defence Cyber Marvel 2026.

James Garside
Operações de segurança

Por onde começar. Pelo quarto ano consecutivo, a Elastic teve o privilégio de atuar como uma parceira confiável 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 iteração mais ambiciosa até hoje, e estamos muito felizes por finalmente poder falar sobre o que criamos, como criamos 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 com foco na defesa de redes de TI tradicionais, ambientes corporativos e sistemas de controle industrial complexos em cenários realistas e de alta pressão. Ele demonstra o poder cibernético responsável ao mesmo tempo em que aprimora a prontidão, a interoperabilidade e a resiliência em toda a Defesa e nas nações aliadas. Agora em seu quinto ano, o DCM evoluiu de uma iniciativa da Army Cyber Association para uma operação conjunta de três forças liderada pelo Cyber and Specialist Operations Command (CSOC).

O governo do Reino Unido publicou um comunicado à imprensa oficial sobre o DCM26, que oferece uma excelente visão geral da importância estratégica do exercício. Como destacou o alto-comissário britânico em Singapura, o exercício demonstra a profunda cooperação entre o Reino Unido e parceiros confiáveis, 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 força contra força: as Blue Teams defensoras protegem as redes e a infraestrutura que lhes foram alocadas contra as Red Teams atacantes, usando uma variedade de técnicas. As atividades abrangem desde a alteração de senhas padrão e o fortalecimento de firewalls até a implantação de defesa cibernética de nível empresarial, com tecnologia de IA, usando o Elastic Security. As atividades de cada equipe são monitoradas pela White Team para estabelecer uma pontuação que considera a disponibilidade do sistema, a detecção de ataques, o relatório de incidentes e a restauração do sistema.. Ele desafia as equipes mais experientes e, ao mesmo tempo, oferece um mecanismo de treinamento único para equipes iniciantes em seu primeiro contato com um ambiente cibernético simulado, e esse propósito duplo é o que torna o DCM um exercício tão valioso.

A escala do DCM26

O DCM26 reuniu mais de 2.500 profissionais de 29 países participantes e 70 organizações, coordenados a partir de um Controle de Exercício (EXCON) central sediado em Singapura, com o EXCON recebendo mais de 600 participantes. O exercício foi executado em um ambiente de computação híbrida que abrangeu o cyber range CR14 e a AWS, hospedando mais de 5.000 sistemas virtuais.

O exercício em si durou cinco dias de execução (9–13 de fevereiro de 2026), precedido por um pré-treinamento opcional conduzido por instrutor e verificações de conectividade. O cenário, desenvolvido com base no Ambiente Operacional Indo-Pacífico do Defence Academy Training Environment (DATE), posicionou as equipes como Equipes de Proteção Cibernética que defendiam sistemas militares implantados durante uma crescente crise regional. As Blue Teams estavam geograficamente dispersas, algumas em suas localidades de origem no Reino Unido e no exterior, outras implantadas em outros países, todas se conectando ao range via VPN.

Entre os participantes estavam representantes da Defesa do Reino Unido, departamentos intergovernamentais como a National Crime Agency, o Departamento de Trabalho e Pensões, o Cabinet Office e o Departamento de Negócios e Comércio, além de parceiros internacionais, formando até 40 equipes. Após o sucesso do exercício do ano passado na República da Coreia, Singapura atuou como o centro de exercícios pela primeira vez, refletindo o compromisso do Reino Unido em aprofundar a cooperação com parceiros do Indo-Pacífico em desafios compartilhados de segurança.

Em resumo, é um exercício sério. Alta pressão, força contra força, com consequências reais para a pontuação e resultados reais de aprendizado para cada participante.

As implantações: nossa infraestrutura da Elastic

A infraestrutura deste ano representou uma evolução arquitetônica significativa em relação às iterações anteriores. Em vez de implantar clusters individuais do Elastic Cloud por equipe, migramos para uma única implantação multitenant baseada em espaços do Elastic Cloud para as Blue Teams. Também fornecemos implantações para funções fora das Blue Teams. Deixe-me detalhar cada implantação e por que ela existe.

Blue Teams: Elastic Security multitenant

O elemento central da nossa contribuição foi uma única implantação do Elastic Cloud que atendia todas as 40 Blue Teams de defesa, separadas usando Kibana Spaces e espaços de nome de fluxos de dados. Cada uma das 39 equipes tinha seu próprio espaço de trabalho isolado, incluindo dashboards, agentes e regras de detecção.

Veja como era o recurso do Terraform para criar o espaço de cada equipe:

# Crie 40 espaços da BLue Team
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 = "Espaço isolado para BT-${local.team_numbers[count.index]} com visibilidade da Fleet por espaço"

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

O espaço de cada equipe recebeu um conjunto dedicado de três políticas de agente do Fleet : no dia 1, uma política de rede Deployed (implantada); no dia 2, uma política de rede Host Nation; e, por fim, uma política PacketCapture para monitoramento de tráfego de rede. O controle de acesso em fases foi elegante em sua simplicidade: definir enable_hostnation_network = true em nosso terraform.tfvars e executar terraform apply expandiu as permissões de função de cada equipe e tornou a política de agente Host Nation visível em seus respectivos espaços. O exercício passou de uma rede para duas sem um único clique manual no Kibana.

O isolamento de dados dependia dos espaços de nome de fluxo de dados. Cada política de agente é gravada em espaços de nome específicos da equipe, como bt_01_deployed e bt_01_hostnation, produzindo fluxos de dados que seguem 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_hostnation

A função de segurança do Kibana de cada equipe foi então delimitada apenas àqueles fluxos de dados usando blocos de privilégios de índice dinâmicos:

# Fluxos de dados implantados (sempre concedidos)
indices {
  names = [
    "logs-*-${local.deployed_namespaces[count.index]}",
    "metrics-*-${local.deployed_namespaces[count.index]}",
    ".fleet-*"
  ]
  privileges = ["read", "view_index_metadata"]
}

# Fluxos de dados do HostNation (condicional a 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 era realizada via SSO do Keycloak, 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 foram naturalmente simples. Cada equipe recebeu: System para telemetria do núcleo do SO, Elastic Defend para Endpoint Detection and Response, Windows event forwarding, Auditd para logging de auditoria do Linux e integrações do Network Packet Capture. São mais de 400 políticas de integração gerenciadas como código via Elastic Stack Terraform Provider.

Uma observação sobre o Elastic Defend: devido à eficácia da proteção de endpoint da Elastic — na qual o DoD e a CI dos EUA confiam em produção; saiba mais sobre isso aqui — e ao fato de que ninguém em sã consciência desperdiça exploits de dia zero em um exercício de treinamento, fomos forçados a limitar o Elastic Defend desativando o modo "Evitar" e deixando-o apenas no modo "Detectar". As equipes recebem alertas quando algo malicioso acontece, mas sem mitigação automática. Também desativamos completamente a prevenção e detecção de ameaças à memória, pois isso descobre a maioria dos implantes e beacons da equipe de ataque, o que estragaria o jogo para as Red Teams. Mais para o fim do exercício, demos às equipes a liberdade de usar o Elastic Defend com toda a sua capacidade, mas não antes de permitir que as Red Teams conseguissem uma presença sólida.

Também pré-instalamos as regras de detecção pré-criadas da Elastic em cada espaço da equipe — o conjunto completo do Elastic Security Labs, atualizado continuamente em um repositório aberto. Essas regras foram configuradas para garantir que consultassem apenas índices permitidos pelas permissões da equipe com escopo de espaço de nome, evitando qualquer vazamento de dados entre equipes na execução das regras de detecção.

Além disso, cada espaço de equipe tinha seu índice padrão do Security Solution configurado para limitar as regras de detecção apenas aos fluxos de dados daquela equipe, em vez do padrão abrangente. Isso foi feito por um "null_resource" do Terraform que chamou a API de configurações internas do Kibana para definir "securitySolution:defaultIndex" para cada espaço.

No pico, essa implantação estava ingerindo 800 mil eventos por segundo (EPS) em todas as 40 equipes. É uma quantidade considerável de dados, e o cluster lidou com isso tranquilamente graças aos recursos de redimensionamento automático do Elastic Cloud. Dito isso, em 2018 estávamos fazendo 5 milhões de eventos por segundo com o eBay.

O ciclo de vida dos dados era gerenciado por uma política de gestão de ciclo de vida do índice (ILM) que fazia o rollover dos índices após um dia ou "50" GB (o que ocorresse primeiro), movia-os para uma fase warm após dois dias para otimização somente leitura e force-merge, e depois excluía os dados após dez dias. Como resultado, os custos de armazenamento foram minimizados enquanto mantinham os requisitos da janela de exercício. Confira abaixo um exemplo de como a política de 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 shard: comprovando o multi-tenancy em larga escala

Antes de nos comprometermos com essa arquitetura para um exercício militar ao vivo, precisávamos provar que ela seria capaz de atender aos nossos requisitos e ter um failover adequado implementado em caso de problemas. A transição de implantações separadas para um único cluster multilocatário trouxe riscos reais: contenção de recursos, gargalos de ingestão, vazamento de dados entre spaces devido a erros de configuração, grande número de conexões TCP nos nós do Elasticsearch e uma contagem de shards significativamente maior, já que cada equipe gera seu próprio conjunto de índices.

Então, construímos uma bancada de testes dedicada. O plano era simples: implantar 50 Kibana Spaces, criar uma política de agente em cada espaço, executar 6.000 instâncias do EC2 (120 por tenant, em seis sub-redes em três zonas de disponibilidade) e fazer testes de carga em tudo. Monitoramos tudo com o AutoOps e o Stack Monitoring.

O fluxo de implantação funcionou assim: o Terraform criou a VPC e as sub-redes em três zonas de disponibilidade, provisionou os 50 espaços do Kibana e suas políticas do Fleet com escopo de espaço, gerou tokens de inscrição e depois executou instâncias do EC2 em lotes. Cada instância instalou o Elastic Agent na inicialização e se inscreveu com seu token específico do espaço.

Encontramos alguns desafios interessantes ao longo do caminho. Na época, o provedor padrão do Elastic Stack para Terraform não oferecia suporte a operações do Fleet com reconhecimento de espaços. Por isso, fizemos um fork dele e adicionamos o tratamento de ID de espaço aos recursos do Fleet — sem essa modificação, todos os agentes teriam sido registrados no espaço padrão, independentemente da alocação de políticas. Não foi a primeira vez que tivemos que estender o provedor para um exercício; há dois anos, para o DCM2, adicionamos a fonte de dados "elasticsearch_cluster_info". Felizmente, desde então, o provedor upstream adicionou "support for space_id"` na versão "0.12.2".

Também nos deparamos com limites de taxa da API do AWS EC2 ao tentar inicializar todas as 6 mil instâncias ao mesmo tempo. Por isso, agrupamos as implantações em lotes de 500 instâncias com períodos de espera de cinco minutos entre os lotes.

Os resultados foram animadores. Todos os 6.000 agentes eram normalmente registrados em até 20 minutos após a implantação. Em nossos testes, o isolamento de espaços funcionou conforme o esperado, sem nenhum vazamento de dados observado entre os tenants. As atualizações de política do Fleet foram propagadas para todos os agentes em até 60 segundos. As consultas de busca com escopo definido para espaços individuais permaneceram rápidas sob carga total. E a distribuição multi-AZ provou ser resiliente durante falhas simuladas de zonas de disponibilidade.

Esses testes nos deram a confiança necessária para nos comprometer com a arquitetura para o exercício ao vivo.

Red teams: observabilidade de implante de C2

Uma implantação separada e dedicada do Elastic foi configurada para as Red Teams, com foco na observabilidade de implantes de comando e controle (C2). Isso deu às equipes de ataque visibilidade sobre suas próprias operações, incluindo status de implantes, callbacks de beacon e progresso operacional, sem nenhum risco de contaminação cruzada com os dados da Blue Team. As Red Teams usaram o Tuoni como seu C2, que é um framework desenvolvido pela Clarified Security para red teaming. No DCM3, trabalhamos com a Clarified Security para garantir o suporte adequado ao Elastic Common Schema, tornando futuras integrações com o Elastic muito mais fáceis.

NSOC: Exercise Network Security Operations Centre

O exercício principal, o Network Security Operations Centre (NSOC), foi executado na própria implantação da Elastic, oferecendo à equipe de controle do exercício uma visão abrangente da integridade do range, monitoramento de segurança em toda a infraestrutura e, fundamentalmente, logging de auditoria para todos os serviços de IA que implantamos. Cada invocação da API do Bedrock foi registrada em log no CloudWatch e observável nesta implantação, o que significa que o NSOC tinha visibilidade total sobre o que estava sendo solicitado aos agentes de IA e por quem . Mais 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 autoscaling, 40 Kibana Spaces, 120 políticas de agente do 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ções do Keycloak, políticas de ILM para retenção de dados, 41 usuários do AWS IAM para conectores de GenAI do Bedrock (um por espaço de equipe mais um padrão), 41 conectores de ação de GenAI do Kibana, guardrails do AWS Bedrock, túneis do 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 do Security Solution por espaço. Todo o estado foi armazenado em um backend criptografado do S3.

Para a implantação do agente e do proxy nos sistemas reais do range, usamos o Catapult, uma excelente ferramenta open source desenvolvida pela equipe da Clarified Security. O Catapult encapsula o Ansible com um modelo de execução baseado em containers desenvolvido especialmente para implantações de cyber range. Ele cuidou da instalação e da inscrição dos Elastic Agents em toda a infraestrutura do range. A configuração de servidores proxy (cada equipe tinha um proxy Squid dedicado para sua rede implantada, isso para simular um ponto único de saída como seria no mundo real. O tráfego era roteado por endpoints como "http://elastic-proxy.dsoc.XX.dcm.ex:3128"), e a implantação de túneis da Cloudflare para conectividade com o Tines.

Durante o provisionamento, os seguintes itens foram gravados no HashiCorp Vault pelo Terraform e consumidos pelo Catapult: credenciais, tokens de registro, chaves de API, configurações de proxy, credenciais da conta de serviço do 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", facilitando para os playbooks do Catapult extrair as credenciais corretas para cada equipe.

Treinamento: preparando equipes para o sucesso

Implantar a plataforma é uma coisa; garantir que as pessoas possam realmente usá-la é outra. Fornecemos treinamento on-range ministrado por instrutor para as Blue Teams durante a fase de pré-exercício. Isso abrangeu os fundamentos do Elastic Security, navegação pelo team space no Kibana, trabalho com regras de detecção pré-criadas, uso do Discover para análise de logs e threat hunting, criação de dashboards customizados, compreensão dos alertas do Elastic Defend e familiarização com a ferramenta de investigação Timeline.

A própria instrução do exercício destacou que este treinamento era opcional, mas "altamente recomendado", e, pelo que vimos, as equipes que participaram começaram a todo vapor no primeiro dia de execução. Treinamento e capacitação são tão importantes quanto a implantação da tecnologia. Entregar a uma equipe ferramentas de segurança de nível empresarial que ela não sabe usar não teria ajudado ninguém.

O serviço de IA On-Range: em conformidade, auditado, com proteções

Este ano marcou nossa estreia no fornecimento de acesso à IA para a linha DCM. Fornecemos um serviço de IA em conformidade diretamente no range, respaldado por modelos do AWS Bedrock hospedados no Reino Unido — especificamente o Claude 3.7 Sonnet em execução na região eu-west-2 (Londres). Não foi IA por mero capricho; foi um serviço cuidadosamente arquitetado com guardrails, logging de auditoria completo e controles de acesso compatíveis com RBAC. Recebemos a confiança para executar esse serviço devido à experiência da Elastic no espaço de IA.

O serviço de IA tinha vários consumidores no range, e essa é uma distinção importante. O conector em conformidade do Bedrock que provisionamos no espaço de cada equipe não estava apenas capacitando nossos agentes personalizados — ele também alimentava os recursos nativos de IA da Elastic, especificamente:

Elastic AI Assistant for Security

O Elastic AI Assistant estava disponível em todos os espaços da Blue Team, conectado ao nosso conector do Bedrock no range. Isso deu às equipes uma interface de chat com reconhecimento de contexto diretamente no Elastic Security, onde elas podiam fazer perguntas sobre seus alertas, obter ajuda para escrever consultas ES|QL, investigar processos suspeitos e receber etapas de remediação guiadas. O AI Assistant usa retrieval-augmented generation (RAG) com o recurso Knowledge Base da Elastic, que é pré-preenchido com artigos do Elastic Security Labs. As equipes também puderam adicionar à Knowledge Base os próprios documentos, como SOPs específicos do range, inteligência sobre ameaças ou notas da equipe, para ancorar 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 AI de ajudar analistas menos experientes a entender o que estavam vendo. Um analista júnior lidando com seu primeiro beacon de implante ativo poderia pedir ao assistente para explicar o alerta, sugerir etapas de investigação e até ajudar a redigir o relatório de incidentes. As configurações de anonimização de dados garantiram que os valores de campos sensíveis pudessem ser ofuscados antes de serem enviados ao provedor de LLM.

Elastic Attack Discovery

O Attack Discovery foi outro consumidor significativo do nosso serviço de IA on-range. O Attack Discovery usa LLMs para analisar alertas no ambiente de uma equipe e identificar ameaças correlacionando alertas, comportamentos e caminhos de ataque. Cada "descoberta" representa um potencial ataque e descreve as relações entre múltiplos alertas — indicando às equipes quais usuários e hosts estão envolvidos, como os alertas são mapeados para a matriz MITRE ATT&CK, e qual ator de ameaça pode ser responsável.

Para um exercício cibernético no qual as Red Teams executaram ativamente ataques coordenados, o Attack Discovery foi transformador. Em vez de fazer a triagem manual de centenas de alertas individuais, as Blue Teams podiam executar o Attack Discovery para identificar narrativas de ataque de alto nível, por exemplo, "estes 15 alertas fazem parte de uma cadeia de movimento lateral do host X para o host Y, provavelmente pelo autor da ameaça Z", e concentrar o tempo de investigação onde era mais importante. É o tipo de recurso que reduz diretamente o tempo médio de resposta e combate a fadiga de alertas, que é exatamente o que você precisa quando está sob ataque contínuo por cinco dias seguidos.

Os 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 é o framework da Elastic para criar agentes de IA personalizados que combinam instruções de LLM com ferramentas modulares e reutilizáveis, sendo cada ferramenta uma consulta ES|QL, um recurso de busca integrado, uma execução de fluxo de trabalho ou uma integração externa via MCP. Os agentes analisam solicitações em linguagem natural, selecionam as ferramentas adequadas, executam-nas e iteram até fornecerem uma resposta completa, tudo isso gerenciando o contexto com dados dentro do Elasticsearch. Você pode ler mais sobre o framework na documentação do Agent Builder e na análise aprofundada do Elasticsearch Labs.

Os três principais componentes do Agent Builder que aproveitamos foram:

Agentes: instruções personalizadas de LLM e um conjunto de ferramentas alocadas que definem a persona, as capacidades e os limites de comportamento do agente. Cada agente tem um prompt de sistema que controla sua missão, as ferramentas que ele pode acessar e a estrutura das respostas.

Ferramentas: funções modulares que os agentes usam para buscar, recuperar e manipular dados do Elasticsearch. Criamos ferramentas ES|QL personalizadas que consultavam índices específicos contendo documentação de exercícios, playbooks e relatórios.

Chat do agente: A interface conversacional - tanto a UI integrada do Kibana quanto a API programática - que os participantes usaram para interagir com os agentes.

As configurações de agente e ferramentas são definidas como JSON e gerenciadas por meio das APIs do Agent Builder, tornando todo o ciclo de vida do agente — da engenharia de prompts à vinculação de ferramentas — reproduzível e passível de controle de versão. Compartilharemos a configuração do agente GrantPT e as definições de ferramentas em um post complementar para quem quiser replicar essa abordagem — fique de olho.

Veja o que cada agente fez:

1. GrantPT - O assistente de finalidade geral

Disponível para todos os ~2.500 participantes do exercício, o GrantPT foi nosso principal agente de IA e a melhor demonstração de como o Agent Builder torna simples colocar em funcionamento um assistente capaz e específico de domínio. A configuração do agente consistia em um objeto JSON que definia seu prompt do sistema, persona e um array 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 deu ao GrantPT sua profundidade foi o conjunto de ferramentas. 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 da base de conhecimento aceitava um "target_index" e um parâmetro semântico "query", executando uma consulta ES|QL parametrizada em nossos índices "dcm5-grantpt-*" com classificação por busca semântica:

FROM dcm5-grantpt-* METADATA _score, _index
| WHERE _index == ?target_index
| WHERE content: ?query
| SORT _score DESC
| LIMIT 10

Uma ferramenta separada de descoberta de índices permitia que o agente enumerasse dinamicamente os índices disponíveis da 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 descobria na próxima interação.

Também criamos uma ferramenta de integração com o Jira que realizava buscas semânticas nos chamados de help desk ingeridos, permitindo que o GrantPT apresentasse um contexto relevante para a solução de problemas a partir de solicitações de suporte anteriores. Isso foi particularmente útil para os analistas de help desk, que podiam perguntar ao GrantPT sobre problemas recorrentes e receber respostas baseadas no histórico real dos chamados, em vez de orientações genéricas.

O comportamento de resposta personalizado por RBAC resultou de uma combinação do prompt de sistema do agente, que o instruiu a contextualizar respostas com base na função do usuário, e do modelo de segurança do Elasticsearch. Como a consulta ES|QL de cada ferramenta é executada dentro do contexto de segurança do usuário, o agente só pode revelar documentos acessíveis à função do usuário. Um membro da Blue Team que perguntasse sobre procedimentos de exercícios obteria resultados com escopo limitado aos índices acessíveis à sua equipe, enquanto um HelpDesk Analyst veria resultados de índices específicos de helpdesk. O agente não precisava de uma lógica explícita de alternância de funções; a segurança em nível do documento nativa do Elasticsearch cuidou do escopo, e o agente só trabalhou com os resultados que foram retornados. Essa é uma das coisas que torna o Agent Builder genuinamente elegante — ao herdar o modelo de segurança do Elasticsearch, você obtém uma IA com suporte a 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 Red Teams. O REDRock seguiu o mesmo padrão do Agent Builder: um prompt do sistema dedicado definindo sua persona adversária, vinculado ao próprio conjunto de ferramentas ES|QL personalizadas que consultavam índices específicos do Red Team. Esses índices continham os playbooks do Red Team, a documentação do Tuoni C2, vulnerabilidades no sistema conhecidas no ambiente do range e informações sobre serviços implantados. As definições de ferramenta espelhavam o mesmo padrão de busca semântica parametrizada usado pelo GrantPT, mas tinham o escopo restrito a índices acessíveis apenas a funções do Red Team. Os operadores do Red Team podiam consultar vetores de ataque, verificar pontos fracos conhecidos em sistemas-alvo e obter orientação contextual sobre seus planos operacionais. Era, francamente, como dar aos invasores um oficial de operações extremamente bem instruído.

3. RefPT - A ferramenta do árbitro

Criado especificamente para o White Team (os árbitros e avaliadores do exercício), o RefPT foi vinculado a ferramentas que consultam índices contendo relatórios do Blue Team, eventos de cenários e os critérios de pontuação. O objetivo era garantir uma pontuação uniforme e justa em todas as mais de 40 equipes. O prompt de sistema do agente foi ajustado para cruzar relatórios enviados com eventos de cenários conhecidos e rubricas de pontuação, ajudando os avaliadores a identificar inconsistências ou lacunas. Quando você tem avaliadores avaliando dezenas de equipes simultaneamente, ter uma IA capaz de correlacionar relatórios com um índice de pontuação estruturado é genuinamente transformador para a consistência.

Tines: automação de fluxo de trabalho com IA

O Tines também era um consumidor do serviço de IA on-range. Cada Blue Team tinha uma instância dedicada do Tines, com conectores de ação do Tines provisionados em seu espaço do Kibana. O Tines podia aproveitar os recursos de IA baseados no Bedrock para automação inteligente de fluxos de trabalho, como enriquecimento automatizado 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 do 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: proteções e auditoria

Todas as interações de IA entre todos esses consumidores eram regidas por proteções rigorosas do AWS Bedrock. Implantamos proteções com filtragem de conteúdo (ódio, insultos, conteúdo sexual e violência em limites MEDIUM), proteção de informações de identificação pessoal (PII) (bloqueando endereços de e-mail, números de telefone, nomes, endereços, números do National Insurance do Reino Unido, números de cartão de crédito e endereços IP), filtragem baseada em tópicos para evitar discussões sobre operações sigilosas reais e filtragem de palavrões. Aqui está um snippet da configuração de proteções do nosso Terraform:

resource "aws_bedrock_guardrail" "dcm5_elastic" {
  name        = "dcm5-prod-elastic-guardrail"
  description = "Guardrails para conectores de GenAI do Elastic Kibana DCM5 Prod"

  content_policy_config {
    filters_config {
      input_strength  = "MEDIUM"
      output_strength = "MEDIUM"
      type            = "HATE"
    }
    # ... filtros de conteúdo adicionais para INSULTOS, SEXUAL, VIOLÊNCIA
  }

  sensitive_information_policy_config {
    pii_entities_config {
      action = "BLOCK"
      type   = "UK_NATIONAL_INSURANCE_NUMBER"
    }
    pii_entities_config {
      action = "BLOCK"
      type   = "IP_ADDRESS"
    }
    # ... filtros adicionais de PII
  }

  topic_policy_config {
    topics_config {
      name       = "classified-information"
      definition = "Discussões sobre operações classificadas reais, atividades militares atuais do mundo real ou inteligência operacional."
      type       = "DENY"
    }
  }
}

Cada espaço da Blue Team tinha o próprio usuário do IAM para acesso ao Bedrock, e a configuração "genAiSettings:defaultAIConnectorOnly" do Kibana foi aplicada para evitar que as equipes configurassem os próprios conectores. Isso significava que cada chamada de API podia ser rastreada até uma equipe específica via CloudWatch, e o NSOC tinha total visibilidade de auditoria. O grupo de logs do CloudWatch "/aws/bedrock/grantpt-prod/invocations" capturava todos os eventos de invocação e de salvaguarda.

Os números de todos os consumidores de IA falam por si: 3 agentes de IA personalizados, 2.797 conversas e 785 milhões de tokens de IA consumidos ao longo do exercício.

Monitoramento em tempo real no jogo

No cenário do exercício, cada equipe tinha acesso ao RocketChat como seu cliente de mensagens no ambiente de simulação. Cada Blue Team recebeu seu próprio canal, a capacidade de enviar mensagens diretas para qualquer participante do exercício e a liberdade de criar novos canais conforme necessário. Mais importante ainda para a tradição do DCM, isso incluía o canal de memes — a espinha dorsal de todas as provocações entre as equipes e o humor criativo para elevar o moral que inevitavelmente surge quando você coloca alguns milhares de operadores cibernéticos sob pressão durante uma semana.

Todos esses dados de comunicação representavam uma excelente janela em tempo real para a saúde do range, o sentimento da equipe e os tópicos em alta em todo o exercício. Parecia bom demais para deixar passar, então ingerimos todo o corpus de conversas do RocketChat no Elastic em tempo real e o colocamos para trabalhar.

Análise de sentimentos e reconhecimento de entidades nomeadas

Para o reconhecimento de entidades nomeadas, implantamos o dslim/bert-base-NER modelo do Hugging Face em um nó de machine learning na implantação do NSOC usando o cliente Elastic ELAND. Isso foi então conectado a um pipeline de ingestão do Elasticsearch pelo qual todas as mensagens do RocketChat passavam na ingestão. Pegamos as entidades extraídas e destacamos as mais comuns como temas do dashboard, nos dando uma visão em tempo real do fluxo e refluxo dos tópicos de conversa ao longo do exercício.

Também analisamos a atividade dos grupos, as estatísticas dos usuários e os padrões gerais de comunicação para traçar um panorama dos padrões de vida de cada equipe — participantes mais ativos, volume de mensagens ao longo do tempo e tendências de sentimento detalhadas por usuário. Ao todo, isso nos deu insights realmente interessantes sobre o que estava acontecendo no ambiente de testes quase em tempo real. Quando colocamos o Elastic Agent no modo de prevenção, por exemplo, uma nuvem de palavras no nosso dashboard imediatamente destacou "Elastic" como o tema mais discutido em todos os canais — Blue Teams discutindo sua eficácia, e as Red Teams lamentando a perda de seus beacons. Foi bastante satisfatório.

Análise de memes (sim, de verdade)

Finalmente — e isso causou espanto — coletamos 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 passamos pelo modelo de inferência de REN zero-shot para gerar descrições temáticas do conteúdo de cada meme. A lógica era que essas saídas poderiam se mostrar úteis mais tarde para filtragem, moderação ou outras interações no jogo. Se a análise dos memes gerou inteligência operacionalmente crítica é discutível. Mas certamente foi divertido.

Cortando problemas pela raiz

Por mais que esperássemos que tudo funcionasse sem problemas durante a semana de exercícios, as coisas inevitavelmente falham, não são totalmente compreendidas ou precisam de mais personalização para se adequar à forma como uma equipe específica quer usá-las. Para isso, tínhamos nossa própria subseção do helpdesk in-range, onde solicitações específicas de Elastic e GenAI podiam ser abertas por qualquer equipe.

Operamos esse helpdesk durante toda a duração do exercício, fornecendo orientação, documentação, depuração de problemas e recomendações específicas para o range. Vale a pena aprofundar esse último ponto. Às vezes, o que um Blue Team estava vendo na Elastic não era realmente um problema da Elastic, mas sim a Elastic mostrando fielmente algo no range que justificava uma investigação mais aprofundada (as Red Teams podem causar um verdadeiro caos, e a telemetria não mente). Ao longo do exercício, atendemos a 125 solicitações individuais de suporte de equipes que pediram ajuda especificamente a nós da Elastic.

Depuração preventiva com o Tines

Além de visitar as equipes por VTC ou pessoalmente no EXCON, também trabalhamos com a Tines para tentar algo um pouco mais proativo. Extraímos o corpo do chamado das solicitações recebidas, tentamos categorizar o problema, executamos a categorização em nosso corpus de chamados já resolvidos e fizemos a GenAI produzir uma resposta inicial resumida com o objetivo de solucionar o problema do usuário antes que a triagem o levasse para nossa fila.

Aliás, esse é um padrão que adotamos da nossa própria organização de suporte na Elastic, em que fornecemos um recurso semelhante usando nossa ampla base de conhecimento de problemas já resolvidos como um repositório para o contexto dos agentes de IA. A ideia é simples: usar soluções anteriores para fazer uma primeira tentativa embasada, gerada por máquina, de resolver um problema e evitar que um engenheiro de suporte precise assumir manualmente cada chamado. Isso não resolveu tudo; alguns problemas realmente precisavam de uma pessoa com contexto mais amplo, mas reduziu significativamente a pressão na fila e gerou respostas mais rápidas às equipes que precisavam delas. Foi um sucesso tão grande com nossos chamados e fila que estendemos o escopo para toda a central de atendimento na parte final do exercício, ajudando a reduzir a carga dos outros grupos da Green Team que davam suporte ao exercício.

Parcerias do setor: juntos e ainda melhores

Uma das coisas que mais nos orgulha é como nosso ecossistema de parceiros cresceu ano após ano. O DCM não é apenas uma iniciativa da Elastic; é uma verdadeira coalizão de parceiros do setor, 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 endpoint.

Ano 2 (DCM3) - Trouxemos a Endace, fornecendo capacidade de captura de pacotes 1:1. A captura completa de pacotes, juntamente com a visibilidade de rede da Elastic, deu às equipes a capacidade de realizar análises forenses aprofundadas que a análise baseada em logs por si só não consegue oferecer.

Ano 3 (DCM4) - A Tines se juntou à família, trazendo a automação de fluxos de trabalho para o cenário. As Blue Teams agora podiam criar playbooks de resposta automatizada, fluxos de trabalho de triagem e cadeias de notificação, todos integrados diretamente ao seu ambiente Elastic via conector nativo do Tines.

Ano 4 (DCM26, antigo DCM5) - A AWS se juntou ao projeto, fornecendo acesso ao Bedrock para nossos agentes de IA e contribuindo com financiamento para as implantações da Elastic. Esse foi um marco importante; ter um hyperscaler diretamente investido no sucesso do exercício liberou recursos (como inferência de IA em conformidade e hospedada no Reino Unido com salvaguardas completas e logging de auditoria) que não seriam possíveis de outra forma. A integração do Tines este ano também foi aprimorada com a adição do acesso on-range a LLMs. A série DCM também alcançou um marco este ano, fazendo a transição de suas origens como iniciativa da Army Cyber Association para um programa oficialmente financiado sob o Cyber and Specialist Operations Command.

Às equipes da Endace, Tines e AWS - nossos sinceros agradecimentos. Este exercício melhorou graças às suas contribuições, e todas as equipes estão mais preparadas graças à plataforma que construímos juntos. Já estamos no planejamento do DCM27. Um agradecimento a todos vocês.

Cultura, destaques e as partes que fazem valer a pena

As moedas de desafio

Cunhamos challenge coins personalizadas para o DCM26. Para quem conhece, sabe que as challenge coins são uma tradição militar de longa data, e criar uma especialmente para o exercício pareceu a maneira ideal de comemorar nosso quarto ano de participação.

A festa de coquetel

Também ficamos muito gratos por termos sido convidados para o coquetel do Alto Comissariado oferecido pelo alto-comissário britânico em Singapura. Há algo bastante surreal em discutir a contagem de shards do Elasticsearch e o gerenciamento de estado do Terraform segurando um gim tônica a convite do embaixador. Foi uma noite brilhante, um lembrete genuíno de que esses exercícios existem na interseção da tecnologia com a diplomacia e de que os relacionamentos construídos aqui vão muito além do aspecto técnico.

Resumo

A arquitetura multilocatária se provou sob carga sustentada; os recursos nativos do Elastic AI (AI Assistant e do Attack Discovery) deram à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 do setor em exercícios de Defesa gera resultados que nenhuma organização conseguiria alcançar sozinha.

O Defence Cyber Marvel 2026 foi uma edição marcante de um exercício que continua a crescer em ambição, complexidade e impacto. Para a Elastic, ter a confiança para fornecer a plataforma central de segurança defensiva para 40 Blue Teams de 29 nações e, este ano, a capacidade de IA também, é algo que levamos muito a sério. O exercício desenvolve habilidades reais para pessoas reais que defenderão redes reais, e fazer parte dessa missão é genuinamente significativo.

Como o comunicado de imprensa do governo do Reino Unido destacou, o DCM demonstra o valor prático de cenários da vida real que reforçam parcerias internacionais. Não poderíamos concordar mais.

Voltaremos no próximo ano, e suspeito que teremos ainda mais sobre o que conversar. Enquanto isso, continuaremos a aprimorar o produto para que o suporte a ambientes como o Defence Cyber Marvel se destaque ano após ano.

Nos vemos no range.

Acompanhe a história da DCM26 nas redes sociais:

Facebook | LinkedIn | Instagram

Para ler mais

Elastic Security e IA

Infraestrutura e ferramentas

Contexto do exercício

Quão útil foi este conteúdo?

Reportar um problema