Integrar seus próprios feeds de inteligência contra ameaças
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_timeeend_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 AdminouChronicle 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.intervalenvolve 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 (comograph.entity.ip) e o prefixograph.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:
Siga o procedimento de integração para seu formato ou provedor de feed de ameaças específico:
- STIX/TAXII: consulte
Coletar registros de inteligência contra ameaças STIX
ou implante o conector sem servidor em
Usar scripts de ingestão implantados como funções do Cloud Run (STIX/TAXII)
(tipo de registro
STIX). - MISP: consulte
Coletar registros de IoC do MISP
ou
Usar scripts de ingestão implantados como funções do Cloud Run (MISP)
(tipo de registro
MISP_IOC). - Feeds CSV personalizados: consulte
Coletar arquivos CSV personalizados de IoC
(tipo de registro
CSV_CUSTOM_IOC). - ThreatConnect: consulte
Coletar registros de IoC do ThreatConnect
ou
Coletar registros de IoC do ThreatConnect usando a API v3
(tipos de registro
THREATCONNECT_IOCeTHREATCONNECT_IOC_V3). - Recorded Future: consulte
Coletar registros de IoC do Recorded Future
(tipo de registro
RECORDED_FUTURE_IOC). - Anomali ThreatStream: consulte
Coletar registros de IoC do Anomali ThreatStream
(tipo de registro
ANOMALI_IOC). - CrowdStrike Falcon Intelligence: consulte
Coletar registros de IoC do CrowdStrike
(tipo de registro
CROWDSTRIKE_IOC). - Proofpoint Emerging Threats Pro: consulte
Coletar registros de IoC do Proofpoint Emerging Threats Pro
(tipo de registro
ET_PRO_IOC). - Outros feeds comerciais e de código aberto: encontre o guia de integração e o tipo de registro do seu fornecedor em Tipos de registros e analisadores padrão compatíveis.
- STIX/TAXII: consulte
Coletar registros de inteligência contra ameaças STIX
ou implante o conector sem servidor em
Usar scripts de ingestão implantados como funções do Cloud Run (STIX/TAXII)
(tipo de registro
Atribua o tipo de registro de IoC correspondente (como
STIX,MISP_IOC,CSV_CUSTOM_IOCouTHREATCONNECT_IOC) aos dados de feed recebidos para que o analisador padrão extraia atributos de indicador para campos de entidade do UDM.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
Entityda 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, comoDOMAIN_NAME,IP_ADDRESS,FILEouURL. - Tipo de origem (
metadata.source_type): a classificação da fonte de dados, que precisa ser definida comoENTITY_CONTEXTpara feeds de inteligência de ameaças ingeridos pelo cliente. - Identificador do artefato (
entity.*): o valor do indicador em si, comograph.entity.ip,graph.entity.hostname,graph.entity.domain.name,graph.entity.file.sha256(oumd5esha1) ougraph.entity.url. - Metadados de ameaça (
metadata.threat): atributos contextuais que descrevem a ameaça, incluindothreat_feed_name,threat_name,category,severityeconfidence. 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.
Verificar os dados de IoC ingeridos usando a pesquisa de UDM
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:
- No menu de navegação do Google SecOps, selecione Investigação > Pesquisar.
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>"
Clique em Pesquisar ou pressione Enter.
Clique no card da entidade retornada e confirme se os campos
threateintervalcontê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:
- No menu de navegação do Google SecOps, selecione Detecção > Regras e detecções e clique em Novo.
- 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). 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çãomatch:(por exemplo,$ip over 5m).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:
- No menu de navegação do Google SecOps, selecione Detecção > Regras e detecções.
- Localize sua regra personalizada de inteligência contra ameaças na lista de regras.
- Clique em para mais opções de regras e selecione RetroHunt YARA-L.
- 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.
- Clique em Executar.
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:
- No menu de navegação do Google SecOps, selecione Detecção > Correspondências de IoC.
- 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).
- 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.
- 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:
- No menu de navegação do Google SecOps, selecione Detecção > Alertas e IoCs para ver alertas de regras priorizados.
- 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.
- 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:
- No menu de navegação do Google SecOps, selecione Detecção > Ameaças emergentes.
- 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 :
- Como criar regras com sua própria inteligência contra ameaças (parte 1)
- Como criar regras com sua própria inteligência contra ameaças (Parte 2)
- Noções básicas de YARA-L
- Variáveis de regra YARA-L
- Operadores e modificadores da YARA-L
- Criar uma regra de evento único usando uma expressão regular
- Como criar uma regra de vários eventos: união de eventos
- Navegação no editor de regras
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.intervalativa. Os indicadores com valoresend_timeexpirados 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:
- Abra Detecção > Regras e detecções e clique na sua regra para abrir o Editor de regras.
- 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.
- Inspecione as detecções de teste retornadas para confirmar se as variáveis
outcome(como$threat_namee$source_feed) são preenchidas conforme o esperado.
A seguir
- Saiba mais sobre o contexto da entidade na pesquisa.
- Confira Como começar a usar a YARA-L e Regras de eventos únicos e múltiplos na YARA-L.
- Entenda as detecções especializadas da inteligência aplicada contra ameaças.
Precisa de mais ajuda? Receba respostas de membros da comunidade e profissionais do Google SecOps.