SIM.4 - Teste de Detecção de IOCs e IOAs

Controle SIM.4 do grupo SIM (Simulação de Ataques), derivado do Capítulo 15 do Framework CTH.
Define a verificação periódica de que as regras de detecção de IOC e IOA realmente disparam quando os indicadores e comportamentos correspondentes aparecem no ambiente.
No programa integrado, protege o catálogo de regras contra degradação silenciosa e conecta o pipeline de detecção do controle AUT.3 à métrica de cobertura consolidada no SIM.5.

1. Contexto e Posicionamento no Framework CTH

O Framework CTH alerta que uma regra de detecção que não é testada regularmente pode falhar
silenciosamente devido a mudanças na infraestrutura, atualizações de software ou degradação de dados,
deixando a organização exposta sem que ninguém perceba. O catálogo de regras é o ativo operacional mais
dinâmico do programa de detecção: cresce, é alterado, migra de plataforma e envelhece enquanto o ambiente
à sua volta muda. Sem teste contínuo, nenhuma declaração sobre cobertura desse catálogo tem valor.

Dentro do grupo SIM, este controle é o mais próximo da rotina da engenharia de detecção. Enquanto SIM.1
e SIM.2 avaliam a postura com cenários mais amplos, o SIM.4 responde a perguntas granulares, técnica por
técnica e regra por regra, e é a fonte de evidência mais usada nos exercícios purple team de SIM.3. A
escala recomendada pelo controle é mensal, validando pelo menos 20 por cento das regras ativas (SIM.4.1),
o que garante que o catálogo completo seja reavaliado ao longo de cada semestre.

2. Por Que Testar Detecções Antes de Precisar Delas

A lógica do controle é a mesma da engenharia tradicional: software sem teste não entrega garantia, apenas
intenção. Uma regra de detecção é software, com lógica, dependências de campo, janelas de agregação e
formatos de entrada que mudam sem aviso. Quando o primeiro teste de uma regra acontece durante um
incidente real, o custo do erro é o maior possível: o adversário está dentro e a ferramenta não viu.

Testar antes do incidente transforma cada mudança do ambiente em pergunta objetiva. A fonte de logs
continua alimentando os campos que a regra usa? O parser sobreviveu ao upgrade? A watchlist de IOC ainda é
atualizada pelo feed? O EDR ainda envia o evento que a correlação espera? Cada resposta negativa
encontrada em laboratório é um incidente evitado, e cada resposta positiva acumula evidência auditável da
capacidade defensiva, que serve a auditorias, a clientes e à liderança.

3. O Que Testar: IOC, IOA, Correlações e Playbooks

O objeto de teste não se limita à regra isolada; o controle cobre a cadeia completa, do indicador bruto
até a ação de resposta. A tabela organiza os quatro conjuntos e os métodos de validação correspondentes.

Dois conjuntos costumam ficar fora do escopo por descuido e merecem atenção explícita. As correlações
falham de formas diferentes das regras simples, por janela de tempo, por ordem de chegada ou por campo
ausente em uma das fontes; testá-las exige simular a sequência completa, não o evento isolado. E os
playbooks são validados apenas na ponta final da cadeia; um alerta perfeito que não aciona a notificação
correta falha como detecção end-to-end, na medida exigida pelo nível avançado SIM.4.5.

4. Biblioteca de Testes com Atomic Red Team

O Atomic Red Team é a biblioteca aberta de referência para testes pontuais por técnica, mantida no padrão
ATT&CK. Cada técnica da biblioteca contém um ou mais testes numerados, com descrição, pré-requisitos,
comandos por executor (PowerShell, CMD, sh) e comando de limpeza. Essa estrutura é ideal para validar
detecções uma a uma: o analista executa o teste, verifica a telemetria e o alerta no SIEM, e registra o
resultado na ficha do controle.

A sequência de comandos abaixo ilustra o ciclo de execução pontual em um host de laboratório Windows.

# Importar o módulo de execução no host de teste
Import-Module "C:\ART\invoke-atomicredteam\Invoke-AtomicRedTeam.psd1"
# Listar os testes disponíveis para a técnica escolhida
Invoke-AtomicTest T1053.005 -ShowDetailsBrief
# Executar o primeiro teste, com log de execução em JSON
Invoke-AtomicTest T1053.005 -TestNumbers 1 -ExecutionLogPath "C:\ART\logs\T1053.005-1.json"
# Verificar no SIEM a telemetria e o alerta gerados na janela da execução
# Remover os artefatos criados pelo teste
Invoke-AtomicTest T1053.005 -TestNumbers 1 -Cleanup

A leitura do resultado segue o mesmo esquema dos demais controles do grupo: primeiro a telemetria no SIEM
(o evento correspondente foi indexado com os campos que a regra usa?), depois o alerta (a regra disparou,
com qual severidade?), e por fim o veredito do EDR, quando aplicável. O log em JSON da execução é anexado
à ficha, garantindo que o teste seja reproduzível e que a ficha tenha evidência associada.

5. Casos de Teste Próprios a Partir de Incidentes Reais

A biblioteca pública valida o comportamento genérico, mas os incidentes reais da organização são a fonte
mais valiosa de casos de teste, porque retratam o adversário que efetivamente atinge o ambiente, com as
ferramentas, os horários e os padrões específicos de cada campanha. Cada incidente encerrado deve gerar ao
menos um caso de teste que reproduza a técnica ou o padrão observado, em versão inofensiva, para que a
organização nunca seja pega duas vezes pelo mesmo comportamento.

A construção segue um caminho direto. Da linha do tempo do incidente extraem-se as técnicas ATT&CK
observadas; de cada técnica deriva-se um teste, preferencialmente reaproveitando um teste público
equivalente ou escrevendo uma variante própria com os mesmos artefatos; e do ajuste de detecção feito após
o incidente deriva-se a detecção esperada, que o caso de teste passará a validar em cada rodada. Variantes
benignas, como a mesma execução iniciada por processo legítimo, complementam o caso e medem a taxa de
falsos positivos da regra, exigida no nível intermediário SIM.4.3.

6. Testes de Regressão Após Mudanças

Toda mudança relevante no ambiente é um evento de risco para o catálogo de detecções, e o teste de
regressão é a resposta estruturada a esse risco. As mudanças que obrigam a rodada de regressão incluem:
upgrade ou migração do SIEM, com parsers e índices novos; atualização de versão do EDR ou de sua política;
publicação ou alteração de regras no pipeline; mudança de formato ou de nomes de campos em fontes de log;
e atualizações do sistema operacional que alterem a telemetria de eventos conhecidos.

O padrão operacional recomendado é manter um conjunto de testes de smoke, com as dez a vinte detecções mais
críticas da organização, executado automaticamente após cada uma dessas mudanças, antes da declaração de
sucesso da janela de manutenção. Essa prática transforma o teste de detecção em critério de aceite da
mudança, e não em verificação posterior, e é o elo operacional entre este controle e o pipeline de
integração contínua do AUT.3, que versiona as regras e pode disparar os testes em laboratório a cada
alteração de código.

7. Registro de Resultados e Cálculo de Taxa

O resultado de cada teste é registrado em um vocabulário fechado, para que os números sejam somáveis
entre rodadas. A tabela define os cinco estados possíveis e a ação correspondente a cada um.

Com o vocabulário fechado, a métrica central é direta: a taxa de detecção do período é o número de testes
detectado dividido pelo número de testes válidos, multiplicado por cem. Um mês com 40 testes executados,
30 detectados, 6 só telemetria, 2 não detectados e 2 falsos positivos produz taxa de 75 por cento e uma
fila de trabalho com dez itens, cada um com técnica, regra e responsável. Esses números alimentam diretamente
o SIM.5 e, por meio dele, os indicadores do grupo MET.

8. Integração com AUT.3 e SIM.5

A relação com o AUT.3 é estrutural: os casos de teste são código, as fichas são artefatos versionados e a
execução periódica é um job do pipeline de detecção. No nível avançado SIM.4.4, o pipeline executa os
testes diária ou semanalmente e gera relatórios de cobertura automáticos, com tendência por regra. A regra
que entra no catálogo sem teste associado deve ser rejeitada no review do pipeline, do mesmo modo que o
código sem teste é rejeitado no desenvolvimento de software convencional.

A relação com o SIM.5 é de insumo e consumo: cada resultado válido atualiza o estado de cobertura da
técnica testada, distinguindo detecção declarada de detecção testada. Essa distinção é um dos pontos mais
valiosos do controle, porque a maior parte das lacunas reais de um programa maduro não está nas técnicas
que ninguém escreveu, e sim nas detecções declaradas que deixaram de funcionar sem que ninguém soubesse.

9. Implementação Prática e Salvaguardas por Nível

O Framework CTH define salvaguardas progressivas para o teste de detecção, que orientam a maturação da
prática. A tabela apresenta cada salvaguarda com sua descrição e a prática de mercado correspondente.

10. Erros Comuns e Pontos de Atenção

• Testar apenas o que é fácil: o catálogo de testes tende a acumular técnicas de execução simples e evitar
  correlações complexas; a seleção mensal deve ser proporcional ao risco, não à conveniência.
• Confiar no resultado sem conferir a janela: alerta que chega fora do tempo-alvo não atende ao critério;
  o timestamp do evento e do alerta precisam constar da ficha.
• Deixar de testar os feeds: watchlist vazia por feed vencido é falha comum e silenciosa; a verificação da
  atualização das fontes de IOC é parte da rodada.
• Misturar teste com ataque real: os testes usam marcadores, hosts dedicados e contas próprias; quando o
  teste imita demais o adversário sem marcação, o SOC gasta triagem real com atividade falsa.
• Medir volume em vez de cobertura: executar mil testes de dez técnicas diferentes infla o número e não
  diz nada sobre a postura; a métrica do controle é por técnica e por regra.

11. Integração com Outros Controles do Framework CTH

Este controle consome do grupo DAT a garantia de coleta e dos campos obrigatórios, do grupo ANA os
indicadores e TTPs que viram casos de teste próprios, e do AUT.3 o pipeline que versiona regras e executa
testes de forma automatizada. Os resultados alimentam SIM.5 na consolidação da cobertura, os exercícios
purple team de SIM.3 como catálogo de execuções prontas, e o grupo MET com a taxa de detecção mensal e a
taxa de falsos positivos por regra.

O grupo IR é beneficiário direto: regras testadas reduzem o tempo de detecção e a chance de incidentes
silenciosos, e os casos de teste derivados de incidentes encerrados tornam-se a memória técnica da
organização. Por fim, o grupo GOV utiliza o histórico de cobertura testada como evidência de diligência
em auditorias e revisões, em substituição a declarações genéricas de eficácia das ferramentas.