Usar a simulação de eventos para avaliar a cobertura de detecção

Este guia é para equipes de engenharia de detecção e SOC que querem fornecer sequências de ameaças realistas de maneira programática no pipeline de ingestão ao vivo usando a simulação de eventos. A simulação de eventos é uma estrutura de simulação de ameaças e avaliação de cobertura de detecção incorporada diretamente no Google Security Operations. Como um recurso fundamental da arquitetura do Agente de engenharia de detecção (DEA), a simulação de eventos verifica o ciclo de vida da detecção, desde a ingestão e normalização da telemetria até a correlação e o alerta de vários eventos, preservando os fluxos de trabalho operacionais do SOC.

Ao conectar as ferramentas MCP do Google SecOps com a assistência de IA (como o Gemini ou o Claude Code), a simulação de eventos automatiza o ciclo de vida da engenharia de detecção: ingerindo relatórios de ameaças brutos, estruturando táticas de ameaças em oportunidades de detecção de ameaças (TDOs, na sigla em inglês) acionáveis, sintetizando telemetria realista do Modelo de dados unificado (UDM), avaliando a cobertura das regras YARA-L 2.0 em regras de evento único, multi-evento e compostas e criando novas regras de detecção para fechar as lacunas de segurança identificadas.

Principais casos de uso

A simulação de eventos e o Agente de engenharia de detecção (DEA) oferecem suporte aos seguintes fluxos de trabalho principais:

  • Ingestão de pipeline ao vivo e testes de normalização: transmita de maneira programática a telemetria sintética do Modelo de dados unificado (UDM) diretamente por pipelines de ingestão ao vivo, módulos de enriquecimento de contexto e gráficos de entidades para alcançar a preparação completa de detecção de ponta a ponta.
  • Cobertura contínua de ameaças e validação de regressão: avalie as regras gerenciadas e personalizadas do YARA-L 2.0 em relação a táticas, técnicas e procedimentos (TTPs) específicos do adversário, estabelecendo teste de unidade automatizados e testes de regressão contínuos em conjuntos de regras antes da implantação de produção.
  • Geração de telemetria sintética: produza eventos de UDM válidos para o esquema que simulam cadeias de ataques complexas (como exploração de aplicativos da Web, acesso a credenciais ou movimento lateral) para testar regras em ambientes de produção reais.

Principais benefícios e proposta de valor

  • Postura proativa e validação de ameaças: teste as regras YARA-L 2.0 em relação a vulnerabilidades recém-divulgadas e comportamentos de atores de ameaças antes que incidentes reais ocorram.
  • Síntese direta e garantia de ingestão: sintetize eventos de UDM válidos para o esquema diretamente do texto de inteligência contra ameaças que passa pelo pipeline de ingestão do Google SecOps (ImportEvents) para passar por normalização completa, alinhamento de campos e enriquecimento de contexto.
  • Telemetria isolada e segurança de produção: os eventos sintéticos gerados pela simulação de eventos são marcados com metadados de simulação (SIMULATION rótulos de ingestão) e resultam em detecções marcadas como INCLUDES_SIMULATION_DATA. As detecções de dados simulados são excluídas automaticamente de casos de produção, playbooks, fluxos de análise de risco (RBA) e painéis de triagem de alertas.

Entender os conceitos e a arquitetura da simulação de eventos

Os seguintes componentes principais da simulação de eventos e da estrutura do Agente de engenharia de detecção (DEA) são essenciais para a implantação:

  • Oportunidade de detecção de ameaças (TDO): um modelo de dados formalizado que atua como um teste de unidade que identifica, prioriza e categoriza TTPs específicos do adversário extraídos de relatórios de inteligência contra ameaças ou descrições de linguagem natural. Os identificadores de TDO seguem requisitos de formatação rigorosos (por exemplo, t01, t02, correspondendo à expressão regular ^[a-zA-Z]\d{2}$).
  • Eventos sintéticos de UDM: eventos de registro gerados por máquina formatados estritamente no esquema do Modelo de dados unificado (UDM) do Google SecOps. Esses eventos simulam ações específicas do invasor necessárias para testar a lógica da regra de detecção usando ImportEvents.
  • Rotulagem de simulação e marcação de alertas: os eventos sintéticos têm um rótulo de ingestão (metadata.ingestion_labels["SIMULATION"]). No proto Collection, as detecções resultantes de dados simulados são marcadas em tags com INCLUDES_SIMULATION_DATA. Os campos proto de metadados de detecção incluem simulated_event_count (número total de eventos simulados que contribuem para a detecção) e simulated_event_names (o conjunto de valores de rótulo SIMULATION de eventos contribuintes).
  • Visibilidade de dados e supressão de pesquisa: as pesquisas padrão do UDM do Google SecOps suprimem eventos rotulados de simulação por padrão. As consultas de pesquisa e as visualizações da UI podem incluir explicitamente dados simulados usando o parâmetro de configuração simulated_data_visibility ou a opção de preferências do usuário.
  • Operações de longa duração (LROs): um mecanismo de execução de back-end assíncrono (evaluate_rule_coverage_long_running) que orquestra lotes de execução de regras sob demanda sem encontrar tempos limite HTTP da API.

Antes de começar

A simulação de eventos compartilha os pré-requisitos de ambiente subjacentes, as permissões do IAM e a configuração do servidor com o kit de ferramentas do Agente de engenharia de detecção. Antes de começar, confirme se os seguintes pré-requisitos foram atendidos:

Como a telemetria sintética é injetada

A telemetria sintética é injetada no Google SecOps usando o kit de ferramentas do agente MCP ou chamadas diretas da API Chronicle:

  1. Invocação do subagente MCP: chame a ferramenta generate_synthetic_events com IDs de oportunidade de detecção de ameaças (TDO) de destino e especificações de comportamento.
  2. Endpoint da API Chronicle: transmita de maneira programática eventos sintéticos de UDM usando o endpoint de API REST ImportEvents (POST /v1alpha/projects/{project}/locations/{location}/instances/{instance}/events:import).
  3. Rotulagem de simulação: ao chamar a API ImportEvents diretamente, os autores da chamada precisam incluir manualmente metadata.ingestion_labels contendo a chave "SIMULATION" e um identificador de simulação ou execução de teste exclusivo como o valor no payload da solicitação (por exemplo, "key": "SIMULATION", "value": "TEST123" ou "t01"). A API não preenche automaticamente os rótulos de simulação.

Exemplo de chamada de ingestão de UDM

Solicitação HTTP:

POST https://chronicle.googleapis.com/v1alpha/projects/PROJECT_ID/locations/LOCATION/instances/INSTANCE_ID/events:import

Corpo da solicitação:

{
  "events": [
    {
      "metadata": {
        "event_type": "PROCESS_LAUNCH",
        "event_timestamp": "2026-08-05T20:00:00Z",
        "ingestion_labels": [
          {
            "key": "SIMULATION",
            "value": "TEST123"
          }
        ]
      },
      "principal": {
        "user": {
          "userid": "victim_user"
        }
      },
      "target": {
        "process": {
          "command_line": "powershell.exe -ExecutionPolicy Bypass -File dump.ps1"
        }
      }
    }
  ]
}

A simulação de eventos injeta eventos de UDM sintetizados diretamente usando ImportEvents, avaliando a normalização, o enriquecimento de contexto e a detecção de regras do UDM. A análise de registros brutos é testada durante a geração de eventos sintéticos na ferramenta do Agente de engenharia de detecção (DEA).

Configurar as preferências do usuário para dados de teste sintéticos

Para visualizar eventos de teste sintéticos e alertas simulados no Google SecOps na UI, na API ou nas ferramentas MCP, configure a visibilidade de acordo com a interface:

Console do Google SecOps

Para visualizar eventos sintéticos na página Pesquisa do SIEM ou nos consoles da UI:

  1. No console do Google SecOps, clique no avatar do seu perfil na barra de navegação e selecione Preferências do usuário.
  2. Navegue até Visibilidade de dados.
  3. Defina Mostrar dados de teste sintéticos como ATIVADO.
  4. Clique em Salvar.

API Chronicle

Para consultas de API programáticas, forneça simulated_data_visibility = "SIMULATED_DATA_INCLUDED" ao consultar a pesquisa de UDM, regras ou endpoints de detecção usando a API Chronicle:

{
  "query": "metadata.event_type = \"USER_LOGIN\"",
  "simulated_data_visibility": "SIMULATED_DATA_INCLUDED"
}

Valores de enumeração de parâmetros simulated_data_visibility compatíveis:

  • SIMULATED_DATA_EXCLUDED (padrão): suprime eventos e alertas rotulados de simulação.
  • SIMULATED_DATA_INCLUDED: retorna dados de produção e dados de teste sintéticos nos resultados da consulta.

Servidor MCP do Google SecOps

Ao interagir com o Google SecOps usando um cliente MCP (por exemplo, a CLI do Gemini ou o AntiGravity), configure a visibilidade da simulação em todo o locatário no arquivo de contexto do espaço de trabalho (Gemini.md ou settings.json):

Ao usar o servidor MCP do GoogleSecOps, defina simulated_data_visibility = "SIMULATED_DATA_INCLUDED" para todas as pesquisas de UDM, avaliação de regras e ferramentas de consulta de detecção.

Entender o isolamento do sistema downstream

Para garantir que os dados de teste sejam tratados adequadamente no Google SecOps, a simulação de eventos aplica limites de isolamento limpos para componentes downstream:

Sistema ou recurso Tratamento de dados sintéticos Mecanismo de isolamento
Detecções e armazenamento de alertas Isolado e marcado No proto Collection, as detecções resultantes da telemetria simulada são marcadas em tags com INCLUDES_SIMULATION_DATA e incluem campos proto de metadados de detecção simulated_event_count e simulated_event_names. Suprimido das APIs de leitura e lista de detecção padrão, a menos que simulated_data_visibility = "SIMULATED_DATA_INCLUDED" seja solicitado.
Pesquisa e painéis do UDM Oculto por padrão Filtrado, a menos que simulated_data_visibility = "SIMULATED_DATA_INCLUDED" seja especificado.
Casos e triagem de incidentes Excluído As detecções com tags de simulação são ignoradas na criação de casos automatizados.
Playbooks e automação SOAR Excluído Os playbooks SOAR automatizados não são acionados em alertas simulados.
Análise de risco (RBA) Excluído Os pipelines agregados de pontuação de risco de streaming descartam eventos rotulados de simulação.
Agente de caça a ameaças (THA) Excluído As consultas de conjunto de dados de caça a ameaças suprimem automaticamente a telemetria rotulada de simulação.

Recursos do conjunto de ferramentas e do agente

A simulação de eventos aproveita os recursos da ferramenta de subagente expostos pelo servidor MCP do Google SecOps. Para informações detalhadas sobre as ferramentas de subagente disponíveis (incluindo generate_threat_detection_opportunity, generate_synthetic_events, evaluate_rule_coverage_long_running, get_operation, generate_rules, e create_rule), principais entradas e esquemas de saída, consulte Usar o Agente de engenharia de detecção para avaliar a cobertura de ameaças.

Entender o ciclo de vida e o fluxo de trabalho da engenharia de detecção

O fluxo de trabalho de engenharia de detecção de simulação de eventos de ponta a ponta segue um ciclo de vida estruturado de várias etapas:

  1. Processamento de inteligência e ingestão de telemetria: transmita texto de inteligência contra ameaças bruto para generate_threat_detection_opportunity para extrair TDOs estruturados (por exemplo, t01, t02), aplique a mudança de carimbo de data/hora de pré-voo e invoque generate_synthetic_events para transmitir registros de UDM rotulados como SIMULATION pelo pipeline de ingestão do Google SecOps ao vivo (ImportEvents).
  2. Avaliação de cobertura assíncrona: execute evaluate_rule_coverage_long_running para avaliar a cobertura da regra YARA-L 2.0 na telemetria sintética, pesquisando get_operation até a conclusão para recuperar a matriz de correspondência de regras.
  3. Remediação de lacunas e gerenciamento do ciclo de vida de regras: chame generate_rules para qualquer TDO não coberto para produzir rascunhos de regras YARA-L 2.0 validados e implante regras revisadas na produção usando create_rule.

Para payloads de invocação de ferramentas detalhados e exemplos de código completos em cada estágio do ciclo de vida de detecção, consulte Usar o Agente de engenharia de detecção para avaliar a cobertura de ameaças.

Solução de problemas

Esta seção contém algumas perguntas frequentes sobre solução de problemas e respostas para elas.

Por design, as pesquisas padrão do UDM do Google SecOps suprimem eventos que carregam o rótulo de ingestão SIMULATION para preservar a higiene operacional do SOC. Para visualizar eventos sintéticos na pesquisa de UDM ou nos consoles da UI, verifique se a opção Mostrar dados de teste sintéticos está ativada nas preferências do usuário ou defina simulated_data_visibility = "SIMULATED_DATA_INCLUDED" na solicitação de consulta.

P: Como as detecções de dados simulados são impedidas de alertar os analistas do SOC?

Quando uma regra é acionada em eventos sintéticos, o compilador de back-end marca a detecção resultante com INCLUDES_SIMULATION_DATA. As detecções com essa tag são excluídas dos casos de produção, playbooks, análise de risco (RBA) e painéis de triagem de alertas por padrão.

P: Por que evaluate_rule_coverage_long_running retornou 0 correspondências para meus eventos sintéticos?

Verifique se os carimbos de data/hora do evento sintético estão dentro da janela de execução de 1 hora ([StartTime - 1 hour, StartTime]). Verifique se os IDs de TDO estão em conformidade com a expressão regular necessária (^[a-zA-Z]\d{2}$, por exemplo, t01).

P: Como os indicadores atômicos (endereços IP, nomes de domínio, hashes de arquivos) devem ser tratados em relação às regras de comportamento?

Gerencie indicadores atômicos usando a correspondência de IOCs ou tabelas de dados do Google SecOps, em vez de codificar valores de hash ou endereço IP estáticos diretamente nas regras de detecção YARA-L 2.0. Reserve o YARA-L 2.0 para padrões de comportamento e correlação de TTPs.

P: Qual é o tamanho máximo do lote para chamadas de avaliação de cobertura de TDO?

Para otimizar a performance e obedecer aos parâmetros do API Gateway, as solicitações de avaliação de cobertura em lote são limitadas a um máximo de três TDOs ou 40 eventos sintéticos por chamada evaluate_rule_coverage_long_running.

Precisa de mais ajuda? Receba respostas de membros da comunidade e profissionais do Google SecOps.