Integrar seus próprios feeds de inteligência contra ameaças

Compatível com:

Este guia é destinado a engenheiros de segurança e detecção que querem integrar indicadores personalizados de comprometimento (IoCs, na sigla em inglês) e feeds de inteligência de ameaças de terceiros ao Google Security Operations. Ele explica como ingerir feeds de ameaças, normalizar indicadores no gráfico de contexto de entidade (ECG) do modelo de dados unificado (UDM) e correlacionar entidades de indicadores com telemetria de eventos de streaming. Ao seguir esse método, você automatiza a detecção de ameaças em todo o ambiente e elimina as pesquisas manuais de indicadores. A integração bem-sucedida reduz os tempos de triagem de alertas e fortalece a postura de segurança da sua organização com a detecção de ameaças em tempo real e retroativa.

Ao integrar feeds personalizados de inteligência contra ameaças, sua equipe de operações de segurança pode combinar fluxos de indicadores externos (como a plataforma de compartilhamento de informações sobre malware [MISP, na sigla em inglês], STIX/TAXII ou feeds comerciais) com sua telemetria de segurança interna. Depois de normalizadas no ECG, as entidades de ameaças oferecem suporte à correspondência automática de indicadores e a regras de correlação personalizadas de vários eventos do YARA-L 2.0.

Terminologia importante

  • Gráfico de contexto de entidade (ECG): a camada de armazenamento contextual no Google SecOps que mantém registros de entidade com estado (como recursos, usuários e indicadores de ameaça) para correlação com registros de ocorrência de segurança.
  • Modelo de dados unificado (UDM): o esquema padronizado que o Google SecOps usa para normalizar registros de eventos brutos e dados contextuais de entidades.
  • Intervalo do ciclo de vida do indicador (metadata.interval): a janela de validade limitada por tempo (start_time e end_time) que define quando um indicador de ameaça está ativo no ECG.
  • Correspondência automática de IoC: uma descoberta gerada pelo sistema criada quando um ocorrência de segurança recebido corresponde a uma entidade de indicador ativa no ECG, exibida na página Correspondências de IoC.
  • Retrohunt da YARA-L: uma pesquisa histórica sob demanda que executa uma regra de detecção da YARA-L 2.0 em até 30 dias de telemetria de segurança anterior.

Casos de uso comuns

Os casos de uso a seguir mostram como trazer sua própria inteligência contra ameaças aborda objetivos comuns de operações de segurança.

Correspondência automática de indicadores em tempo real

  • Objetivo: avaliar automaticamente eventos de segurança de streaming em relação a indicadores ingeridos de terceiros sem manter regras de correlação personalizadas.
  • Valor: elimina a manutenção manual de regras para feeds de ameaças de alto volume e mostra correspondências imediatas na página Correspondências de IoC.

Regras de correlação e retrocaça personalizadas do YARA-L

  • Objetivo: associar entidades de inteligência contra ameaças no ECG com telemetria de vários eventos e verificar até 30 dias de dados históricos usando retrocaças.
  • Valor: detecta ataques de várias etapas e descobre comprometimentos históricos que ocorreram antes de um indicador ser adicionado aos seus feeds de ameaças.

Antes de começar

Antes de começar, confirme se os seguintes pré-requisitos foram atendidos:

  • Permissões: você precisa ter permissões do Identity and Access Management para gerenciar feeds de dados e regras de detecção de autoria no Google SecOps (por exemplo, Chronicle API Admin ou Chronicle API Editor). Para detalhes sobre os papéis necessários, consulte Configurar o acesso a recursos.
  • Verificação do ambiente: confirme se você tem uma instância ativa do Google SecOps e credenciais de API ou URLs de endpoint válidos para seu provedor externo de inteligência contra ameaças (como MISP, STIX/TAXII ou buckets do Cloud Storage).
  • Funcionalidade de pesquisa x regra: a pesquisa do UDM permite inspecionar registros de entidades brutas armazenados no ECG, independente da janela ativa. Já as regras de detecção da YARA-L e a correspondência automática avaliam apenas indicadores cujo metadata.interval envolve o carimbo de data/hora do evento.
  • Prefixos de painel e campo de pesquisa: ao consultar entidades de inteligência contra ameaças na pesquisa do UDM, em painéis ou em regras YARA-L, use o prefixo graph.entity. para valores de indicadores (como graph.entity.ip) e o prefixo graph.metadata.threat. para campos de atribuição de ameaças.

Ingerir indicadores de inteligência contra ameaças

Selecione e configure um mecanismo de ingestão para trazer fluxos de indicadores externos para o Google SecOps.

Selecionar um mecanismo de ingestão de feed

É possível ingerir feeds de inteligência contra ameaças usando qualquer um dos seguintes mecanismos compatíveis:

  • Analisadores padrão pré-criados: o Google SecOps inclui analisadores padrão para muitas plataformas de inteligência contra ameaças. Para uma lista de analisadores compatíveis categorizados em IOC, consulte Tipos de registros e analisadores padrão compatíveis. Os fornecedores compatíveis incluem MISP, ThreatConnect, Intel471 e Cyjax.
  • API Feed Management: configure feeds no console do Google SecOps ou usando a API Feed Management para extrair indicadores periodicamente de endpoints HTTPS externos, do Cloud Storage ou do Amazon S3.
  • API Ingestion: envie payloads de entidades pré-estruturadas diretamente para o Google SecOps usando a API Ingestion.
  • Agente do Bindplane: colete e encaminhe registros de indicadores de ambientes locais ou na nuvem usando o agente do Bindplane.
  • Funções do Cloud Run: implante scripts de ingestão sem servidor usando funções do Cloud Run para buscar indicadores de APIs externas (como STIX/TAXII ou MISP) e transmitir para o Google SecOps. Para mais detalhes, consulte Usar scripts de ingestão implantados como funções do Cloud Run.
  • Integrações de resposta do Google SecOps: ingira indicadores usando conectores do Hub de conteúdo para sincronizar listas de ameaças como parte de playbooks automatizados. Para mais detalhes, consulte Usar o Hub de conteúdo.

Integrar feeds de inteligência contra ameaças

Para ingerir registros de indicadores do seu provedor de inteligência contra ameaças no Google SecOps:

  1. Siga o procedimento de integração para seu formato ou provedor de feed de ameaças específico:

  2. Atribua o tipo de registro de IoC correspondente (como STIX, MISP_IOC, CSV_CUSTOM_IOC ou THREATCONNECT_IOC) aos dados de feed recebidos para que o analisador padrão extraia atributos de indicador para campos de entidade do UDM.

  3. Abra o painel Ingestão de dados e verifique se as entradas de registro recebidas aparecem sem erros de registro não analisados.

Preencher e validar o gráfico de contexto de entidade

Quando os indicadores de ameaça entram no Google SecOps, o pipeline de análise os normaliza em registros de entidade da UDM e preenche o ECG. Para detalhes sobre como o enriquecimento de entidades funciona, consulte Como o Google SecOps enriquece dados de eventos e entidades.

Mapeamento de dados estruturados e não estruturados

Dependendo de como você envia dados de inteligência contra ameaças para o Google SecOps, siga o fluxo de trabalho de mapeamento de campos adequado:

  • Ingestão de dados estruturados: ao enviar registros de entidades da UDM pré-estruturados diretamente usando a API Ingestion, formate cada payload de acordo com o esquema Entity da UDM antes da ingestão.
  • Ingestão de dados não estruturados e semiestruturados: ao enviar registros brutos (como CSV, JSON, STIX ou CEF) usando feeds, o agente Bindplane ou encaminhadores, atribua um analisador padrão pré-criado ou crie mapeamentos de campos personalizados usando extensões de analisador para extrair valores de indicadores e mapeá-los para os campos de entidade UDM necessários.

O que torna uma entidade um IoC

Para que um registro de entidade no ECG seja reconhecido como um IoC acionável por regras de correspondência e detecção automáticas, o analisador ou a carga útil da API precisa preencher os seguintes cinco grupos de campos da UDM:

  • Tipo de entidade (metadata.entity_type): o tipo de entidade de indicador compatível, como DOMAIN_NAME, IP_ADDRESS, FILE ou URL.
  • Tipo de origem (metadata.source_type): a classificação da fonte de dados, que precisa ser definida como ENTITY_CONTEXT para feeds de inteligência de ameaças ingeridos pelo cliente.
  • Identificador do artefato (entity.*): o valor do indicador em si, como graph.entity.ip, graph.entity.hostname, graph.entity.domain.name, graph.entity.file.sha256 (ou md5 e sha1) ou graph.entity.url.
  • Metadados de ameaça (metadata.threat): atributos contextuais que descrevem a ameaça, incluindo threat_feed_name, threat_name, category, severity e confidence.
  • Intervalo do ciclo de vida (metadata.interval):

    • metadata.interval.start_time: o carimbo de data/hora em que o indicador fica ativo.
    • metadata.interval.end_time: o carimbo de data/hora em que o indicador expira.

Para definições de esquema, consulte a lista de campos da UDM para Entity e EntityMetadata.

Normalmente, os indicadores ficam disponíveis para pesquisa na UDM de 2 a 5 minutos após a ingestão e a análise. Verifique se os indicadores preenchem o ECG executando uma pesquisa de UDM:

  1. No menu de navegação do Google SecOps, selecione Investigação > Pesquisar.
  2. No campo de pesquisa, insira uma consulta direcionada ao gráfico de entidades para um valor de indicador ingerido:

    • Endereço IP:

      graph.entity.ip = "<var>IP_ADDRESS</var>"
      
    • Domínio:

      graph.entity.hostname = "<var>DOMAIN_NAME</var>"
      
    • Hash do arquivo (SHA-256):

      graph.entity.file.sha256 = "<var>SHA256_HASH</var>"
      
    • Produto de origem:

      graph.metadata.source_product = "<var>SOURCE_PRODUCT_NAME</var>"
      
  3. Clique em Pesquisar ou pressione Enter.

  4. Clique no card da entidade retornada e confirme se os campos threat e interval contêm os metadados e os carimbos de data/hora ativos esperados.

Correlacionar telemetria e detectar ameaças

Depois que os indicadores de ameaça preencherem o ECG, correlacione-os com eventos de segurança recebidos e históricos.

Ativar a correspondência automática de IoC

O Google SecOps inclui um mecanismo de correspondência automatizado que opera de forma independente das regras de detecção personalizadas. Quando a telemetria de eventos corresponde a um indicador ativo no eletrocardiograma:

  • Correspondências geradas pelo sistema: a plataforma cria um registro de correspondência de IoC automaticamente sem exigir manutenção de regras personalizadas.
  • Tempo estimado após a ingestão (estimativa aproximada):
    • Eventos de streaming: depois que um indicador preenche o ECG (geralmente de 5 a 15 minutos após a ingestão), o Google SecOps avalia os eventos de streaming recebidos e mostra as correspondências na página Correspondências de IoC em 5 a 15 minutos.
    • Eventos históricos: o mecanismo de correspondência automatizado também avalia os indicadores recém-ingeridos de forma retroativa em relação à telemetria histórica em ciclos de lote. As correspondências iniciais geralmente aparecem em 1 a 4 horas, e a correlação histórica completa é concluída em 24 horas.
  • Aplicação de intervalo: o mecanismo de correspondência avalia eventos estritamente em relação a indicadores ativos em que o carimbo de data/hora do evento está dentro de metadata.interval.

Criar regras de correlação YARA-L 2.0

Escreva regras de detecção YARA-L 2.0 para unir a telemetria de eventos (como conexões de rede, consultas DNS ou inicializações de processos) com entidades de indicadores no ECG. Com as regras personalizadas, você pode combinar correspondências de indicadores com limites comportamentais, contexto do recurso e listas de exclusão:

  1. No menu de navegação do Google SecOps, selecione Detecção > Regras e detecções e clique em Novo.
  2. Na seção events: da regra, defina uma variável de marcador de posição para unir um campo de evento da UDM (como $net.target.ip = $ip) com o campo de entidade correspondente do ECG (como $ioc.graph.entity.ip = $ip).
  3. Filtre a variável de entidade por atributos de ameaça (como $ioc.graph.metadata.threat.category) e especifique um período de correlação na seção match: (por exemplo, $ip over 5m).

  4. Clique em Salvar nova regra.

Executar uma retrocaça para detectar comprometimentos históricos

Os feeds de inteligência contra ameaças geralmente contêm indicadores usados por adversários dias ou semanas antes de sua organização ingerir o feed. Enquanto as regras ativas avaliam a nova telemetria recebida, uma retrocaça YARA-L aplica a lógica da regra de forma retroativa a até 30 dias de eventos de segurança históricos:

  1. No menu de navegação do Google SecOps, selecione Detecção > Regras e detecções.
  2. Localize sua regra personalizada de inteligência contra ameaças na lista de regras.
  3. Clique em para mais opções de regras e selecione RetroHunt YARA-L.
  4. Na caixa de diálogo Retrocaça YARA-L, selecione os horários de início e término da sua pesquisa histórica. Verifique se o período selecionado é maior ou igual à janela de correspondência especificada na regra.
  5. Clique em Executar.
  6. Abra a guia Detecções da regra para monitorar o progresso e inspecionar correspondências históricas.

Para mais detalhes, consulte Executar uma regra em dados históricos.

Investigar correspondências e alertas

Analise as descobertas geradas pela correspondência automática e pelas regras de correlação personalizadas em visualizações dedicadas no Google SecOps.

Analisar hits automáticos na página de correspondências de IoC

Para investigar correspondências automáticas de indicadores:

  1. No menu de navegação do Google SecOps, selecione Detecção > Correspondências de IoC.
  2. Use os controles de filtro para definir o escopo das descobertas por tipo de indicador (domínios, endereços IP, hashes de arquivo ou URLs).
  3. Clique em qualquer linha de indicador para abrir o painel de detalhes da correspondência, que mostra:
    • Ativos internos e nomes de usuários associados.
    • Carimbos de data/hora do primeiro e do último evento.
    • Fonte de feed de inteligência contra ameaças e atribuição de confiança.
  4. Clique em Ver na pesquisa da UDM para inspecionar todos os eventos de telemetria bruta associados ao indicador.

Para mais detalhes, consulte Ver IoCs usando o Applied Threat Intelligence.

Faça a triagem de ocorrências de regras nas páginas "Alertas" e "Detecções"

As detecções geradas por regras personalizadas da YARA-L aparecem nas páginas Alertas e Detecções:

  1. No menu de navegação do Google SecOps, selecione Detecção > Alertas e IoCs para ver alertas de regras priorizados.
  2. Clique no nome de um alerta para abrir a página Detalhes do alerta e inspecione a tabela Detecções, que lista as linhas de eventos correlacionados e os atributos da entidade ECG.
  3. Para regras silenciosas (em que os alertas estão desativados) ou retrocaças concluídas, abra Detecção > Regras e detecções, clique no nome da regra e inspecione a guia Detecções.

Correlacionar indicadores personalizados com o Centro de Ameaças Emergentes

Você também pode usar a Central de Ameaças Emergentes para investigar como suas correspondências personalizadas de IoC se relacionam a campanhas de adversários e famílias de malware mais amplas:

  1. No menu de navegação do Google SecOps, selecione Detecção > Ameaças emergentes.
  2. Revise as campanhas e os avisos de ameaças ativas e faça uma rotação para a pesquisa da UDM para verificar se os indicadores dos seus feeds de ameaças personalizados se sobrepõem à atividade observada da campanha.

Para mais detalhes, consulte Visão geral da Central de Ameaças Emergentes.

Acessar recursos e referências avançados

Use os snippets e recursos de referência da YARA-L 2.0 a seguir ao criar regras personalizadas de inteligência contra ameaças.

Conexão de rede de saída correspondente a um endereço IP malicioso

Essa regra correlaciona eventos de saída NETWORK_CONNECTION com indicadores de IP ativos no ECG:

rule custom_ioc_network_connection {
  meta:
    author = "Security Operations"
    description = "Detects connections to IPs matching custom threat intel"
    severity = "HIGH"
    priority = "HIGH"

  events:
    $net.metadata.event_type = "NETWORK_CONNECTION"
    $net.target.ip = $ip

    $ioc.graph.entity.ip = $ip
    $ioc.graph.metadata.threat.category = "SUSPICIOUS_NETWORK"

  match:
    $ip over 5m

  outcome:
    $risk_score = max(85)
    $threat_name = array_distinct($ioc.graph.metadata.threat.threat_name)
    $source_feed = array_distinct($ioc.graph.metadata.source_product)
    $principal_hostname = array_distinct($net.principal.asset.hostname)

  condition:
    $net and $ioc
}

Consulta DNS correspondente a um domínio malicioso

Essa regra identifica pesquisas de NETWORK_DNS para domínios sinalizados como maliciosos nos feeds de ameaças ingeridos:

rule custom_ioc_malicious_domain_query {
  meta:
    author = "Security Operations"
    description = "Detects DNS queries for domains matching threat intel"
    severity = "MEDIUM"
    priority = "MEDIUM"

  events:
    $dns.metadata.event_type = "NETWORK_DNS"
    $dns.network.dns.questions.name = $domain

    $ioc.graph.entity.hostname = $domain

  match:
    $domain over 10m

  outcome:
    $threat_name = array_distinct($ioc.graph.metadata.threat.threat_name)
    $source_feed = array_distinct($ioc.graph.metadata.source_product)
    $client_ip = array_distinct($dns.principal.ip)

  condition:
    $dns and $ioc
}

Execução de processo correspondente a um hash de arquivo SHA-256 malicioso

Essa regra é acionada quando um evento PROCESS_LAUNCH corresponde a um hash de arquivo SHA-256 malicioso conhecido armazenado no ECG:

rule custom_ioc_malicious_file_execution {
  meta:
    author = "Security Operations"
    description = "Detects process launches matching malicious file hashes"
    severity = "CRITICAL"
    priority = "HIGH"

  events:
    $process.metadata.event_type = "PROCESS_LAUNCH"
    $process.target.process.file.sha256 = $sha256

    $ioc.graph.entity.file.sha256 = $sha256

  match:
    $sha256 over 5m

  outcome:
    $threat_name = array_distinct($ioc.graph.metadata.threat.threat_name)
    $file_path = array_distinct($process.target.process.file.full_path)
    $hostname = array_distinct($process.principal.asset.hostname)
    $user = array_distinct($process.principal.user.userid)

  condition:
    $process and $ioc
}

Blogs da comunidade e outros recursos

Para mais exemplos sobre como criar regras YARA-L e correlacionar feeds personalizados de inteligência de ameaças, consulte os seguintes recursos da comunidade Google Cloud :

Solução de problemas

Use esta seção para gerenciar as expectativas de desempenho e resolver problemas comuns ao integrar feeds de inteligência contra ameaças e criar regras de correlação.

Latência, cota de serviço e limites

  • Indexação de pesquisa do UDM e ingestão: os indicadores recém-ingeridos geralmente aparecem na pesquisa do UDM em 2 a 5 minutos. Aguarde pelo menos 5 minutos após a ingestão do feed antes de resolver problemas com registros de entidades ausentes.
  • Latência da correspondência automática de IoC: depois que um indicador preenche o ECG, as correspondências com eventos de streaming recebidos aparecem na página Correspondências de IoC em 5 a 15 minutos. A correspondência retroativa em lote com eventos históricos geralmente leva de 1 a 4 horas (e até 24 horas para correlação histórica completa).
  • Janela de correlação do gráfico de contexto da entidade: a correspondência automática de IoC e as regras de correlação do YARA-L avaliam os indicadores estritamente dentro da janela metadata.interval ativa. Os indicadores com valores end_time expirados não geram correspondências.
  • Janela de pesquisa do Retrohunt: as retrohunts YARA-L verificam até 30 dias de telemetria histórica por execução. O tempo de conclusão depende da complexidade da regra e da disponibilidade de recursos do sistema.

Correção de erros

Use esta tabela para diagnosticar e resolver problemas durante a integração da inteligência contra ameaças e a criação de regras de detecção.

Problema Descrição do problema Corrigir
Registros de IoC não analisados O status do feed mostra os dados recebidos, mas os registros não são analisados em entidades da UDM. Confirme se o tipo de registro do feed corresponde ao seu analisador (por exemplo, STIX, MISP_IOC ou CSV_CUSTOM_IOC). Verifique o painel Ingestão de dados para ver erros de esquema brutos.
Resultados da pesquisa UDM ausentes Os registros de indicadores são analisados sem erros, mas a pesquisa da UDM não retorna registros de entidade. Verifique se a consulta tem como destino campos graph.entity.* (como graph.entity.ip) em vez de campos de eventos udm.principal.*.
A regra não é acionada em um indicador conhecido O evento e o indicador existem na pesquisa da UDM, mas a regra YARA-L não produz detecções. Confirme se metadata.interval.start_time e metadata.interval.end_time no indicador incluem o carimbo de data/hora do evento.
Alertar sobre inundação durante a retrohunt Executar uma retrocaça cria centenas de alertas e casos duplicados de SOAR. Desative a opção de alerta da regra antes de iniciar uma RetroHunt. Analise as detecções na página Detecções antes de reativar os alertas em tempo real.
Alto volume de falsos positivos Indicadores ruidosos acionam detecções em scanners internos benignos ou hosts administrativos. Adicione uma exclusão de lista de referência à sua regra (por exemplo, not $net.principal.ip in %benign_scanner_ips) e exija o contexto do evento comportamental.

Validação e teste

Antes de ativar uma regra personalizada de inteligência contra ameaças no modo de alertas ativos, verifique a lógica dela usando o recurso integrado Testar regra:

  1. Abra Detecção > Regras e detecções e clique na sua regra para abrir o Editor de regras.
  2. Clique em Testar regra no painel inferior para avaliar a regra com base em dados de eventos históricos recentes e entidades de ECG ativas sem gerar alertas ou casos de SOAR.
  3. Inspecione as detecções de teste retornadas para confirmar se as variáveis outcome (como $threat_name e $source_feed) são preenchidas conforme o esperado.

A seguir

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