Cyber Range e Ambientes Isolados

Nota da pasta 03 - Validação Contínua de Controles, no Capítulo 19 (Purple Teaming Contínuo).
Trata do cyber range como infraestrutura de teste para emulação e validação, cobrindo arquitetura, redes isoladas, targets realistas, clones, cloud ranges e o equilíbrio entre custo e segurança.
Dialoga com as notas de emulação da pasta 02 e de BAS contínuo da mesma pasta, e com o ambiente de hunting isolado do grupo HNT do Capítulo 15.

1. Contexto e Posicionamento na Biblioteca

Toda a engenharia de emulação descrita no capítulo assume uma premissa que precisa ser construída deliberadamente: um ambiente em que o adversário emulado possa agir sem risco para a produção e com telemetria completa para a defesa observar. Esse ambiente é o cyber range, e a qualidade dele limita diretamente a qualidade do programa de purple teaming contínuo. Um range pobre, com hosts genéricos e logs parciais, produz resultados otimistas que desabam no primeiro incidente real; um range realista é a bancada de ensaio que sustenta as rodadas semanais do BAS.

Esta nota desenha a arquitetura de um range funcional, do hipervisor ao target, e discute as escolhas de custo versus segurança, incluindo os cloud ranges que mudaram a economia desses ambientes. A nota dialoga com o grupo HNT do Capítulo 15, que já trata do ambiente de hunting isolado como controle, e aporta aqui a visão de construção e operação do ambiente. O objetivo final é dar receita concreta: um range mínimo de Active Directory que qualquer equipe pode montar com hardware modesto ou com recursos de nuvem.

2. A Função do Range no Purple Teaming Contínuo

O range cumpre três funções distintas que convém separar mentalmente. A primeira é a bancada de validação: hosts de teste com agentes de telemetria idênticos aos de produção, onde as simulações rodam e as detecções são medidas. A segunda é a rede de observação: sensores de rede, coletores de log e o SIEM de laboratório que recebem a telemetria do range, preferencialmente com as mesmas regras de produção. A terceira é a sala de treino: cenários para formação de analistas e hunters, em que errar é seguro e repetir é barato.

A função de bancada é a que sustenta o capítulo inteiro. Para que a rodada semanal do BAS produza números comparáveis, o range precisa ser estável e reproduzível, com versões de sistema, patches e agentes controlados e documentados. Mudanças não controladas no range introduzem variáveis que contaminam a comparação entre rodadas, e a disciplina de infraestrutura como código é o antídoto.

A função de rede de observação tem uma decisão arquitetural central: o SIEM do range deve ser uma réplica fiel do de produção, ou um sistema próprio. A resposta madura é réplica fiel, com as mesmas regras de detecção versionadas, porque o objetivo é medir as detecções de produção, e não um sistema paralelo. Quando a réplica integral é inviável, replica-se o motor e as regras, aceitando a limitação declarada no relatório de cada rodada.

3. Arquitetura: Hipervisores, Redes Isoladas e Targets Realistas

A base física do range é um hipervisor dedicado ou um cluster segregado. Soluções abertas como Proxmox VE e KVM atendem bem custos baixos, enquanto VMware vSphere domina ambientes corporativos que já possuem licenciamento. O critério decisivo não é a marca, e sim a capacidade de criar redes virtuais isoladas, tirar snapshots e automatizar o ciclo de vida das máquinas por interface de linha de comando ou API. A tabela resume os blocos de arquitetura e suas decisões.

A rede isolada é o coração do desenho. O range precisa de segmentação própria, com VLANs separadas por função e um firewall controlando o pouco tráfego que cruza segmentos, e nenhuma rota para a rede corporativa ou para a internet aberta, salvo um egresso controlado explicitamente para testes de C2, sempre com destinos próprios e monitorados. O DNS interno do range deve resolver nomes plausíveis, porque muitos comportamentos de adversário e muitas regras de detecção dependem de resolução real.

Targets realistas são o que separa range de laboratório de máquina virtual. O target precisa espelhar a produção em versões de sistema, agentes instalados, configuração de log e até em ruído normal de uso, como autenticações simuladas e serviços rodando. Um DC de AD no range deve ter usuários, grupos, GPOs e tarefas agendadas plausíveis, senão cada teste dispara alertas que a produção nunca geraria em igual contexto, e a comparação perde validade.

O controle de egresso merece desenho explícito, porque é o ponto em que ranges mais falham em auditoria. A política recomendada nega por padrão todo tráfego de saída do range, abre exceções nomeadas por cenário, como o egresso controlado do host operador para servidores de C2 do próprio laboratório, e registra tudo em log do firewall. Com essa política, a pergunta da auditoria, o range pode falar com a internet, tem resposta verificável em uma regra nomeada, e o cenário de C2 da pasta 02 roda sem ambiguidade de escopo.

4. Clones, Snapshots e Infraestrutura como Código

A operação diária do range depende de três mecânicas complementares. Snapshots capturam o estado de uma máquina em um ponto e permitem reverter em minutos, o que é o mecanismo padrão de limpeza entre rodadas. Clones vinculados partem de uma imagem base e criam máquinas derivadas com custo mínimo de disco, o que multiplica targets sem multiplicar esforço. Infraestrutura como código, com Terraform, Ansible ou Vagrant, descreve o range inteiro em repositório, permitindo reconstruir o ambiente idêntico em qualquer hipervisor ou nuvem.

A combinação dessas mecânicas produz o ciclo de vida padrão de uma rodada. Antes da rodada, o operador reverte os targets ao snapshot limpo e confirma que os agentes estão ativos. Durante a rodada, os testes executam e a telemetria flui. Depois da rodada, a reversão ao snapshot elimina artefatos, e qualquer mudança de estado desejada, como um patch novo de simular o parque, é feita na imagem base e propagada pelos clones, sempre documentada no repositório.

O bloco a seguir exemplifica o esqueleto de um playbook de Ansible que prepara um target Windows do range, ilustrando o padrão de descrição declarativa.

- name: Preparar target Windows do range
  hosts: lab_windows
  tasks:
    - name: Instalar agente de telemetria na versão de produção
      win_package:
        path: C:\dist\agente-telemetria.msi
        state: present
    - name: Garantir coleta de Security, Sysmon e PowerShell
      win_shell: |
        & C:\dist\config-coleta.ps1 -Profile producao-espelhada
    - name: Criar arquivos armadilha com conteúdo sintético marcado
      win_file:
        path: C:\Users\financas\Documents\planilha-lab.xlsx
        state: touch
    - name: Registrar versão do target no inventário do range
      win_lineinfile:
        path: C:\lab\versao-target.txt
        line: "target-v2025.10-patch2025-09"

A versão do target registrada em arquivo é um detalhe que economiza semanas de investigação. Quando a rodada 41 mostra resultado diferente da rodada 40, a primeira hipótese a eliminar é a mudança de target, e ter a versão escrita no próprio host encerra a dúvida em um comando.

O ruído de fundo é o complemento menos glamouroso e mais importante do target realista. Um range silencioso faz qualquer comportamento anômalo parecer óbvio, inflando a taxa de detecção, e a prática consagrada é gerar tráfego e eventos de fundo contínuos por script, imitando o pulso de um parque real. O bloco a seguir ilustra um gerador simples de ruído para o range de AD.

#!/bin/bash
# Gerador de ruído de fundo do range, executado a cada 5 minutos pelo cron
DOMINIO="lab.corp"
USUARIOS=(financas1 rh2 ti3 compras4 logistica5)
MAQUINAS=(EST-A EST-B SRV-WEB SRV-ARQ)
for i in "${!USUARIOS[@]}"; do
  usuario="${USUARIOS[$i]}"
  maquina="${MAQUINAS[$((RANDOM % ${#MAQUINAS[@]}))]}.${DOMINIO}"
  # autenticação de teste seguida de acesso a arquivo armadilha
  smbclient //${maquina}/publico -U "${DOMINIO}\\${usuario}%SenhaDeLab!$((RANDOM))" \
    -c "get planilha-lab.xlsx" >/dev/null 2>&1
done
# consulta DNS de fundo a nomes internos plausíveis
for nome in intranet lab.corp atualizacao.corp relatorios.lab.corp; do
  dig +short "${nome}" @10.40.0.1 >/dev/null
done

O script é intencionalmente simples: o objetivo não é reproduzir a complexidade de um parque, e sim evitar o silêncio absoluto que distorce as taxas de detecção. A intensidade do ruído fica registrada no repositório do range, e rodadas que mudam a intensidade declaram a mudança, pela mesma razão que declaram mudança de target.

5. Cloud Ranges: Custo versus Segurança

Os provedores de nuvem mudaram a economia dos ranges. Um range em nuvem, com máquinas virtuais, redes virtuais e SIEM gerenciado, elimina o capex de hardware e permite escalar de três para trinta máquinas em minutos, pagando por hora de uso. Plataformas e imagens de mercado aceleram a montagem, e a prática consagrada é usar contas de nuvem separadas, com orçamento teto e alertas de custo, para o range jamais tocar recursos da conta de produção. A tabela resume o dilema entre as duas modalidades.

A decisão madura costuma ser híbrida. O range permanente on-premises, modesto, mantém os targets estáveis que a rodada semanal exige, e os cloud ranges sobem sob demanda para cenários maiores, como avaliações encadeadas trimestrais ou treinos com dezenas de máquinas. Em ambas as modalidades, a regra de ouro é a mesma: nenhum dado real de produção no range, apenas dados sintéticos e marcados, porque o range é, por definição, ambiente de agressão controlada.

O risco específico do cloud range é a configuração errada de rede virtual e peering, que pode expor o range à internet ou conectá-lo à rede de produção. A revisão de configuração por segunda pessoa, antes do primeiro deploy de cada cenário, é o controle barato que previne o incidente caro.

6. Cenários de Treino e de Validação

O mesmo range serve dois públicos com exigências diferentes, e separar os cenários evita conflito de agenda. Os cenários de validação seguem o calendário do BAS contínuo, são executados pelos operadores roxos e têm como produto o índice de resultados. Os cenários de treino seguem o calendário de desenvolvimento de equipe, têm narrativa e objetivos pedagógicos, e o produto é a habilidade do analista, medida por exercícios como os do Capítulo 16 da biblioteca.

Os treinos clássicos incluem caça com hipótese pré-definida em telemetria de um ataque simulado, triagem de incidente encadeado com prazo, e reversa de engenharia de detecção, em que o analista precisa escrever a regra que captura o comportamento que acabou de ver. Cada treino deixa no SIEM um intervalo de telemetria rotulado, que se transforma em material de estudo reutilizável e em baseline para medir a evolução dos analistas.

A validação usa o range de forma mais cirúrgica: reverter, executar o conjunto do ator, verificar alertas, registrar, reverter. Por isso a agenda do range precisa de reserva, e a prática recomendada é reservar os horários de validação semanal no próprio calendário do ambiente, com os treinos ocupando as janelas restantes. Quando um treino quebra o range, a rodada de validação não pode ser vítima, e o snapshot por cenário resolve a convivência.

7. Exemplo: Range Mínimo para Testes de Active Directory

O range mínimo de AD demonstra que o custo de entrada é baixo. Com um servidor físico de 64 GB de RAM ou uma conta de nuvem modesta, o conjunto a seguir sustenta a maior parte das rodadas de emulação em ambiente Windows. O desenho cabe em um bloco textual de referência rápida.

Range mínimo de Active Directory ( rede 10.40.0.0/22, isolada )
  Firewall e DNS      pfSense            10.40.0.1    (2 vCPU, 2 GB)
  DC do laboratório   Windows Server     10.40.1.10   (2 vCPU, 4 GB)
                      AD DS, DNS, 25 usuários, 12 grupos, 6 GPOs
  Servidor membro     Windows Server     10.40.1.20   (2 vCPU, 6 GB)
                      IIS e compartilhamento com arquivos armadilha
  Estação A           Windows 11         10.40.2.10   (2 vCPU, 4 GB)
                      Office de teste, Sysmon e EDR como produção
  Estação B           Windows 11         10.40.2.11   (2 vCPU, 4 GB)
                      clone vinculado da estação A
  Coletor e SIEM      Linux + SIEM       10.40.3.10   (4 vCPU, 12 GB)
                      regras de produção versionadas
  Host ofensivo       Linux              10.40.9.10   (2 vCPU, 4 GB)
                      ferramentas de emulação do capítulo
Regras do ambiente
  nenhuma rota para a rede corporativa
  egresso para internet somente do host ofensivo, para destinos próprios
  snapshots limpos de todas as máquinas antes de cada rodada
  ruído de fundo gerado por script de autenticações e acessos a arquivos

Esse conjunto roda em um servidor físico único com 64 GB ou em qualquer assinatura de nuvem de baixo custo. A partir dele, o range cresce por demanda: adicionar um segundo DC para testar replicação, um servidor de banco de dados para cenários de exfiltração, ou um sensor de rede dedicado para telemetria de fluxo. O princípio é sempre o mesmo, crescer de targets reais para cenários reais, e não o contrário.

8. Erros Comuns e Pontos de Atenção

• Montar targets limpos demais, sem ruído de fundo nem configuração plausível, e medir detecções em um ambiente que a produção nunca terá; target realista é pré-requisito de resultado válido.
• Deixar rota entre range e produção "só por conveniência", transformando o ambiente de agressão controlada em vetor de risco interno; a isolamento é o requisito primeiro.
• Esquecer de reverter snapshots entre rodadas, acumulando persistências de testes anteriores que geram falsos positivos nas rodadas seguintes.
• Rodar o range no mesmo hipervisor da produção sem segregação de recursos, competindo por disco e memória e degradando os dois lados.
• Usar dados reais de clientes ou funcionários em qualquer máquina do range; dados no range são sintéticos e marcados por política.
• Não versionar a configuração do range, tornando impossível reconstruir o ambiente de uma rodada antiga quando uma comparação for exigida.

9. Integração com o Restante da Biblioteca

O range é a infraestrutura sobre a qual rodam todas as notas do capítulo: os frameworks de emulação da pasta 02 executam nele, o BAS contínuo desta pasta agenda nele e o purple teaming de cloud e containers da pasta 04 usa ranges específicos de nuvem e de cluster de teste. O grupo HNT do Capítulo 15 já exige ambiente de hunting isolado como controle, e esta nota fornece o desenho de referência para atendê-lo. Os exercícios práticos do Capítulo 16 assumem um range como palco, e a nota de medição de cobertura consome a telemetria que o range produz.

Para o programa de maturidade, o range é também um argumento de recrutamento e retenção: equipes com bancada segura para experimentar aprendem mais rápido, e a biblioteca de cenários de treino acumulada no range se torna patrimônio do programa. O investimento no ambiente, modesto quando feito com código e snapshots, paga-se na primeira regressão capturada em dias em vez de meses.