Como usar o gráfico de contexto da entidade (ECG, na sigla em inglês)

Compatível com:

Google SecOps SIEM

Este documento oferece uma visão geral do Entity Context Graph (ECG), abordando as fontes de dados, o pipeline de processamento e as aplicações em regras e pesquisa. O ECG é um modelo de dados de entidade principal que fornece contexto essencial para detecção, investigação e caça de ameaças avançadas em regras de detecção, pesquisa e painéis. O pipeline de processamento de ECG mescla informações contextuais de todos os ambientes do Google SecOps.

O ECG também calcula métricas de resumo para entidades. Isso inclui a prevalência (com que frequência uma entidade específica ocorre nos dados da UDM em comparação com outras entidades) e o first-seen-time e o last-seen-time de uma entidade. Ele também identifica fontes de enriquecimento e indicadores de comprometimento (IOCs) importantes, como dados do Google Threat Intelligence (GTI), do Navegação segura, do WHOIS e do VirusTotal.

O eletrocardiograma usa eventos da UDM para fazer o seguinte:

• Crie uma visão enriquecida, correlacionada e abrangente de entidades internas (ativos e usuários) e externas (IOCs).
• Identifique as relações entre essas entidades.

Fontes de dados do eletrocardiograma

O pipeline de ECG combina dados das seguintes fontes:

Origem do contexto	Origem	Descrição
Contexto da entidade	Fornecido pelo cliente	O Google SecOps ingere diretamente dados organizacionais estruturados, como detalhes confiáveis sobre usuários e recursos, de sistemas externos. Essas fontes incluem provedores de identidade (IDPs), sistemas de banco de dados de gerenciamento de configuração (CMDBs), como ServiceNow CMDB e contexto do usuário do Duo, e sistemas de gestão de vulnerabilidades.
Contexto derivado	Gerado pelo Google SecOps	O Google SecOps gera dados estatísticos com base na análise da atividade ingerida. Ele enriquece eventos e entidades de várias fontes no seu ambiente (por exemplo, Windows AD, Azure AD, Okta, Google Cloud, IAM). Por exemplo: Calcula e enriquece cada entidade com uma estatística de prevalência que indica a popularidade dela no ambiente. Calcula e enriquece o horário da primeira e da última visualização da entidade.
Contexto global	Google-sourced	As fontes globais fornecem dados de reputação e inteligência contra ameaças internas e externas. Por exemplo: Ingere e armazena dados do Google Threat Intelligence. Enriquece entidades com informações das listas de ameaças da Navegação segura. Aprimora entidades com dados do WHOIS.

Pipeline de tratamento de dados de eletrocardiograma

O pipeline de tratamento de dados de ECG cria um perfil completo e confiável para cada entidade. Isso é feito mesclando o contexto de várias origens (como provedores de identidade, bancos de dados de gerenciamento de configuração [CMDBs], feeds de inteligência contra ameaças e contexto derivado) em um único perfil de entidade consolidado. A fusão de eletrocardiogramas permite o seguinte:

• Adicionar novas conexões, propriedades e relações ao ECG.
• Criar e atualizar o contexto derivado.

O processo geral envolve primeiro a normalização de eventos de segurança brutos em estruturas da UDM usando alias e enriquecimento da UDM e, em seguida, a fusão desses dados de eventos com várias fontes contextuais para criar perfis de entidades avançados.

Pseudônimos do UDM e fusão de ECG

Primeiro, o pipeline de alias e enriquecimento da UDM ingere eventos de segurança brutos e os normaliza em estruturas da UDM.

Observação: "fusão de ECG" não é o mesmo que "pseudônimos de UDM". Enquanto o alias da UDM enriquece eventos adicionando identificadores (por exemplo, mapeando um endereço IP para um nome do host em um evento), o ECG mescla o contexto de várias fontes (como IdPs, CMDBs e inteligência contra ameaças) para criar um único perfil de uma entidade.

Entidades com e sem tempo

O ECG cria entidades temporais e atemporais. As entidades com carimbo de data/hora são avaliadas nos intervalos de tempo especificados da regra e da pesquisa. As entidades atemporais são avaliadas sem considerar o período da pesquisa ou da regra.

Chaves de fusão de ECG

O eletrocardiograma mescla registros de contexto combinando identificadores de chave comuns em diferentes fontes de dados. Exemplos desses identificadores incluem hostname, MAC address, user ID ou email address. O ECG mescla registros que correspondem a qualquer um desses valores para criar uma visão abrangente e enriquecida de uma entidade.

O aliasing de ECG usa os seguintes campos da UDM como merge-keys:

• Asset
  • entity.asset.product_object_id
  • entity.asset.hostname
  • entity.asset.asset_id
  • entity.asset.mac
• User
  • entity.user.product_object_id
  • entity.user.userid
  • entity.user.windows_sid
  • entity.user.email_addresses
  • entity.user.employee_id
• Resource
  • entity.resource.product_object_id
  • entity.resource.name
• Group
  • entity.group.product_object_id
  • entity.group.email_addresses
  • entity.group.windows_sid

Como mesclar tipos de entidades específicas (arquivo, URL, domínio)

Além das merge-keys, o ECG mescla o contexto de tipos de entidades específicos (arquivo, URL e domínio) usando os seguintes identificadores exclusivos:

• File

  • entity.file.md5
  • entity.file.sha1
  • entity.file.sha256
  • (e entity.file.product_object_id, se fornecido)

• URL

  • entity.url.url
  • (e entity.url.product_object_id, se fornecido)

• Domain

  • entity.domain.domain
  • (e entity.domain.product_object_id, se fornecido)

O ECG só mescla um registro de contexto de entidade para um File, URL ou Domain com outro registro se todos os identificadores exclusivos presentes nos dois registros forem iguais.

Por exemplo, se o ECG considerar dois contextos de entidade File para uma fusão:

• Se ambos tiverem um hash md5, o ECG vai exigir que eles correspondam.
• Se um tiver um md5 e o outro um sha256, o eletrocardiograma não vai mesclar os dados com base no hash.
• Se um product_object_id for fornecido, o ECG também precisará corresponder a ele se estiver presente nos dois registros comparados, além dos identificadores baseados em conteúdo (como md5, url ou domain).

Isso significa que, para esses tipos, campos como entity.file.md5, entity.url.url e entity.domain.domain precisam estar presentes e corresponder ao processo de mesclagem, além de qualquer product_object_id fornecido.

Resolução de conflitos

Durante o processo de fusão, se os campos tiverem valores conflitantes, o ECG vai atualizar a entidade selecionando o valor com o horário de início mais recente. Quando o ECG atualiza um atributo de entidade com um novo valor, ele retém o valor anterior nos resultados da pesquisa durante o intervalo em que esse valor era válido. Consequentemente, uma consulta de pesquisa que abrange um período em que um atributo mudou pode retornar vários contextos de entidade para essa entidade.

Eliminação de duplicação e intervalos de tempo

Para criar uma entidade combinada comum, o ECG elimina dados redundantes por eliminação de duplicação. Os duplicados são identificados pela correspondência de todos os identificadores exclusivos relevantes de uma entidade em diferentes fontes de contexto. Ele gera intervalos de tempo em vez de corresponder a carimbos de data/hora exatos.

Por exemplo, considere duas entidades e1 e e2 com carimbos de data/hora t1 e t2, respectivamente. Se e1 e e2 forem idênticos, o ECG vai remover as duplicidades ignorando as diferenças de carimbo de data/hora nos seguintes campos:

• collected_timestamp
• creation_timestamp
• interval

Observação: se houver conflitos em campos não repetidos, os dados da entidade mais recente serão usados.

Janela de lookback

O eletrocardiograma cria dados de contexto de entidade com uma janela de lookback de cinco dias. Esse processo ajuda a lidar com dados que chegam atrasados e estabelece um tempo de vida implícito para dados de contexto de entidade.

O ECG distingue entre dados contextuais (assets, users, resources, groups) e indicadores de comprometimento (IOCs).

Exemplo: fusão de dados do usuário com fusão de eletrocardiograma

Por exemplo, o Google SecOps ingere dados do usuário para jdoe de três fontes: Okta, Azure AD e um scanner de vulnerabilidades. O ECG mescla esses três registros com base em identificadores correspondentes (como [e-mail]). Isso cria uma entidade de usuário jdoe unificada no ECG, que contém atributos de todas as três fontes.

Fontes de dados de ECG de contexto de evento e entidade crítica

O Google SecOps exige várias fontes de dados específicas para criar e atualizar entidades.

Fontes de dados de eletrocardiograma de contexto de entidade crítica

As fontes de dados confiáveis para usuários e recursos do seu ambiente fornecem os dados de registro mais importantes para criar um modelo de dados de entidade. Exemplo:

Categoria	Fontes de dados críticas	Entidades preenchidas
Gerenciamento de identidade e acesso	Active Directory, Azure AD, Okta, Google Cloud Identity	user, group
Inventário de recursos	CMDBs, JAMF, Microsoft Intune	asset
Inteligência contra ameaças	Feeds personalizados ou de terceiros, Google Threat Intelligence (GTI)	ip_address, domain_name, file

Exemplo de pesquisa

Para listar analisadores que oferecem suporte a cada categoria:

1. Acesse Tipos de registros compatíveis com um analisador padrão.

2. Digite uma categoria na barra de pesquisa, por exemplo:

   • Para analisadores relevantes para o inventário de recursos, digite inventory ou asset.
   • Para analisadores relevantes para gerenciamento de identidade e acesso, digite identity.
   • Para analisadores relevantes para inteligência contra ameaças, digite IOC.

Fontes de dados e campos críticos do UDM para criação de perfil de entidade

O Google SecOps melhora os perfis de entidades com base em fontes de dados de contexto de entidades confiáveis e campos críticos do UDM:

Tipo da entidade	Fontes de dados	Campos críticos da UDM (para alias e indexação)
Processo	Os registros de endpoint fornecem o PSPI (`principal.process.product_specific_process_id`), um identificador estável crucial para um alias de processo robusto. Exemplos incluem CrowdStrike EDR (CS_EDR) e Windows Sysmon (WINDOWS_SYSMON).	source.process.product_specific_process_id
User	Essas fontes fornecem atributos do usuário e informações de identidade. Por exemplo, dados de contexto de entidade do Duo (DUO_CONTEXT) e Okta (OKTA).	source.user.userid, source.user.email_address, source.user.windows_sid, source.user.product_object_id
Ativo ou endpoint	Essas fontes fornecem informações confiáveis sobre os recursos. Por exemplo, ServiceNow CMDB (SERVICENOW_CMDB) e Tanium Asset (TANIUM_ASSET).	source.ip, source.hostname, source.asset_id, principal.asset.hostname
Hash do arquivo	Fornece uma "impressão digital" exclusiva do conteúdo de dados para verificar a integridade de dados.	source.file.sha256, source.file.sha1, source.file.md5

Campos de UDM de dados de contexto de eventos críticos

O Google SecOps exige vários campos UDM de dados de contexto de eventos críticos.

• Os campos mais importantes do UDM funcionam como identificadores e indicadores de relacionamento estáveis (campos principal.*, target.*, src_* e dst_*).

• Confira a lista de campos principais do UDM pertencentes à área de recursos Entity graph.

• Para criar um eletrocardiograma abrangente, priorize fontes de dados que contribuam com identificadores de alto valor e dados de relacionamento. Exemplo:

  Tipo de entidade	Fontes de dados críticas	Campos críticos da UDM para criação de entidades
  Recurso (host)	EDR e XDR, DNS e DHCP, firewall,registros de auditoria do console Google Cloud	metadata.event_type, principal.asset.asset_id, principal.asset.hostname, principal.ip
  User	Registros do provedor de identidade (IdP), feed de RH (contexto), registros do Cloud Identity, gateway de e-mail	principal.user.userid, principal.user.email_addresses, target.user.userid, principal.ip
  Rede	Firewall, VPN, DNS, registros de fluxo da VPC	principal.ip, target.ip, src_ip, dst_ip, network.direction
  Arquivo e processo	EDR e XDR, registros de aplicativos	target.file.full_path, target.process.file.full_path, target.process.command_line

Exemplo

O ECG depende desses campos do UDM para unir dados de contexto de entidade e dados de eventos do UDM em regras, pesquisas e painéis.

Por exemplo, é possível combinar dados de contexto do usuário em uma regra de monitoramento de "força bruta" para gerar um alerta somente se o usuário envolvido também fizer parte do grupo "Administradores do domínio" e o recurso envolvido for um controlador de domínio:

events:
  $fail.metadata.event_type = "USER_LOGIN"
  $fail.metadata.vendor_name = "Microsoft"
  $fail.principal.hostname = $hostname
  $fail.target.user.userid = $target_user
  $fail.security_result.action = "BLOCK"
  $fail.metadata.product_event_type = "4625"
 
  $fail.metadata.event_timestamp.seconds < $success.metadata.event_timestamp.seconds
 
  $success.metadata.event_type = "USER_LOGIN"
  $success.metadata.vendor_name = "Microsoft"
  $success.target.user.userid = $target_user
  $success.principal.hostname = $hostname
  $success.security_result.action = "ALLOW"
  $success.metadata.product_event_type = "4624"
  $user.graph.entity.user.userid = $target_user
  $user.graph.metadata.entity_type = "USER"
  $user.graph.metadata.source_type = "ENTITY_CONTEXT"
  any $user.graph.relations.entity.group.group_display_name = "Domain Admins"

  $asset.graph.entity.asset.hostname = $hostname
  $asset.graph.metadata.entity_type = "ASSET"
  $asset.graph.metadata.source_type = "ENTITY_CONTEXT"
  any $asset.graph.relations.entity.group.group_display_name = "Domain Controllers"
 
match:
  $target_user, $hostname over 15m
condition:
  #fail > 4 and $success and $user and $asset

Enriquecimentos de contexto derivados

O Google SecOps gera dados de inferência dinâmicos e orientados a eventos para cada entidade em todos os namespaces dos dados de eventos da sua organização. Ele usa informações de alias, dados de processos internos de enriquecimento e dados de ocorrência de segurança para estabelecer relações (por exemplo, um asset associado a um IP address).

Esse processo adiciona um contexto valioso para melhorar os perfis de entidades. Por exemplo, é possível adicionar:

• entity.file.sha256 a file (hash) entidades
• (principal or target).ip_geo_artifact.location.country_or_region para network (geolocation) entidades

O Google SecOps analisa vários indicadores na atividade ingerida para enriquecer os eventos com informações de contexto. Ele executa funções de enriquecimento críticas para gerar, por exemplo, métricas de raridade de entidade, como estatísticas de prevalência, e métricas temporais, como first-seen-time e last-seen-time.

Estatísticas de prevalência

O pipeline de ECG analisa dados atuais e recebidos para calcular e armazenar métricas de prevalência como um campo de contexto derivado. Essas métricas representam um valor numérico de "popularidade" para entidades como domain, file hash ou IP address no seu ambiente. Isso ajuda a identificar atividades raras ou incomuns, já que as entidades mais populares geralmente representam menos risco.

O Google SecOps atualiza essas estatísticas regularmente e as armazena em um contexto de entidade separado. O mecanismo de detecção pode usar esses valores, e você pode pesquisar por eles usando a sintaxe de consulta da UDM. No entanto, o console não mostra esses valores com outros detalhes da entidade.

Você pode usar os seguintes campos ao criar regras do mecanismo de detecção.

Tipo de entidade	Campos do UDM
Domínio	entity.domain.prevalence.day_count entity.domain.prevalence.day_max entity.domain.prevalence.day_max_sub_domains entity.domain.prevalence.rolling_max entity.domain.prevalence.rolling_max_sub_domains
Arquivo (hash)	entity.file.prevalence.day_count entity.file.prevalence.day_max entity.file.prevalence.rolling_max
Endereço IP	entity.artifact.prevalence.day_count entity.artifact.prevalence.day_max entity.artifact.prevalence.rolling_max

O Google SecOps calcula os valores de day_max e rolling_max de maneira diferente, da seguinte forma:

• day_max representa a pontuação máxima de prevalência do artefato durante o dia (um dia é definido como das 00:00:00 às 23:59:59 UTC).
• rolling_max representa a pontuação máxima de prevalência por dia (ou seja, day_max) do artefato na janela de 10 dias anterior.
• day_count é usado para calcular rolling_max, e o valor dele é sempre 10.

Quando esses valores são calculados para um domain, a diferença entre day_max e day_max_sub_domains (e rolling_max versus rolling_max_sub_domains) é a seguinte:

• rolling_max e day_max representam o número de endereços IP internos únicos diários que acessam um determinado domínio (subdomínios excluídos).
• rolling_max_sub_domains e day_max_sub_domains representam o número de endereços IP internos exclusivos que acessam um determinado domínio (incluindo subdomínios).

O Google SecOps calcula estatísticas de prevalência usando dados de entidade recém-ingeridos. O Google SecOps não faz cálculos retroativos em dados ingeridos anteriormente. O Google SecOps leva aproximadamente 36 horas para calcular e armazenar as estatísticas.

Atenção: incluir o argumento prevalence pode aumentar significativamente os dados consultados, o que pode causar um erro de regra. Se você encontrar um erro de regra, refine os parâmetros dela. Por exemplo, adicione mais filtros ou reduza o período especificado na seção match.

Exemplo

O pipeline de ECG exige esses campos do UDM para unir os dados de contexto relevantes a uma regra ou pesquisa. Você precisa unir explicitamente todos os dados relacionados ao ECG aos dados de eventos da UDM.

Por exemplo, é possível usar dados prevalence no ECG para determinar conexões com domínios "raros" nos seus registros de segurança:

    $dns.metadata.event_type = "NETWORK_DNS"
    $dns.network.dns.questions.name != ""
    $dns.network.dns.questions.name = $domain
    $prevalence.graph.metadata.entity_type = "DOMAIN_NAME"
    $prevalence.graph.metadata.source_type = "DERIVED_CONTEXT"
    $prevalence.graph.entity.hostname = $domain
    $prevalence.graph.entity.domain.prevalence.day_count = 10
    $prevalence.graph.entity.domain.prevalence.rolling_max > 0
    $prevalence.graph.entity.domain.prevalence.rolling_max <= 3

  match:
    $domain over 5m
  condition:
    $dns and $prevalence

Observação: a Pesquisa e os Painéis aceitam no máximo uma junção, e as Regras aceitam no máximo duas.

Observação: incluir o argumento prevalence pode fazer com que a pesquisa consulte muito mais dados.

Horários da primeira e da última visualização de entidades

O Google SecOps analisa os dados recebidos para enriquecer os registros de contexto da entidade com os seguintes campos críticos:

• first-seen-time:a data e a hora em que a entidade foi detectada pela primeira vez no seu ambiente.
• last-seen-time:a data e a hora da observação mais recente.

Esses campos derivados permitem correlacionar a atividade em entidades domain, file hash, asset, user ou IP address.

Esses valores são armazenados nos seguintes campos da UDM:

Tipo de entidade	Campos do UDM
Domínio	entity.domain.first_seen_time entity.domain.last_seen_time
Arquivo (hash)	entity.file.first_seen_time entity.file.last_seen_time
Endereço IP	entity.artifact.first_seen_time entity.artifact.last_seen_time
Recurso	entity.asset.first_seen_time
Usuário	entity.user.first_seen_time

Exceções para cálculos de data e hora da primeira e da última visualização:

• Para entidades asset e user, o Google SecOps preenche apenas o campo first_seen_time, e não o campo last_seen_time.
• O Google SecOps não calcula as estatísticas de cada entidade em namespaces individuais.
• O Google SecOps não exporta essas estatísticas para o esquema events do Google SecOps no BigQuery.
• O Google SecOps não calcula esses valores para outros tipos de entidades, como um group ou resource.

Enriquecimentos de contexto global

Essas fontes incluem inteligência contra ameaças externas e dados de reputação de fontes globais internas e de terceiros.

Ingerir dados do Google Threat Intelligence

O Google SecOps ingere dados de fontes de dados do Google Threat Intelligence (GTI), fornecendo informações contextuais para investigar atividades no seu ambiente.

Consulte as seguintes fontes de dados:

• Nós de saída do Tor da GTI:endereços IP conhecidos como nós de saída do Tor.
• Binários benignos do GTI:arquivos que fazem parte da distribuição original do sistema operacional ou foram atualizados por um patch oficial do sistema operacional. Alguns binários oficiais do sistema operacional que foram usados indevidamente por um adversário em atividades comuns em ataques de living-off-the-land são excluídos dessa fonte de dados, como aqueles focados em vetores de entrada inicial.
• Ferramentas de acesso remoto do GTI:arquivos usados com frequência por agentes maliciosos. Essas ferramentas geralmente são aplicativos legítimos que às vezes são usados indevidamente para se conectar remotamente a sistemas comprometidos.

Os dados contextuais são armazenados globalmente como entidades. É possível consultar os dados usando regras do mecanismo de detecção. Inclua os seguintes campos e valores da UDM na regra para consultar essas entidades globais:

• graph.metadata.vendor_name = Google Threat Intelligence
• graph.metadata.product_name = GTI Feed

Observação: nas seções a seguir, substitua o marcador de posição <variable_name> pelo nome de variável exclusivo usado em uma regra para identificar um registro da UDM.

Fontes de dados do Google Threat Intelligence com e sem prazo

As fontes de dados do Google Threat Intelligence incluem tipos com prazo ou sem prazo.

Cada entrada nas fontes de dados com carimbo de data/hora tem um período associado. Por exemplo, se o Google SecOps gerar uma detecção no dia 1, é esperado que ele gere a mesma detecção para o dia 1 durante uma retrocaça em qualquer dia futuro.

As fontes de dados atemporais não têm um período associado, já que apenas o conjunto de dados mais recente precisa ser considerado. Essas fontes de dados são usadas normalmente para dados que não devem mudar, como hashes de arquivos. Se o Google SecOps não gerar uma detecção no dia 1, ela ainda poderá ser gerada para o dia 1 durante uma busca retroativa no dia 2 se uma nova entrada for adicionada à fonte de dados atemporal.

Dados sobre endereços IP de nós de saída do Tor

O Google SecOps ingere e armazena endereços IP que são nós de saída do Tor conhecidos. Os nós de saída do Tor são pontos em que o tráfego sai da rede. Esses dados são temporizados.

O Google SecOps armazena informações ingeridas dessa fonte de dados nos seguintes campos do UDM:

Campo do UDM	Descrição
<variable_name>.graph.metadata.vendor_name	Armazena o valor Google Threat Intelligence.
<variable_name>.graph.metadata.product_name	Armazena o valor GTI Feed.
<variable_name>.graph.metadata.threat.threat_feed_name	Armazena o valor Tor Exit Nodes.
<variable_name>.graph.entity.artifact.ip	Armazena o endereço IP ingerido da fonte de dados do GTI.

Exemplo de pesquisa

graph.metadata.source_type ="GLOBAL_CONTEXT"
graph.metadata.product_name = "GTI Feed"
graph.metadata.threat.threat_feed_name = "Tor Exit Nodes"

Dados sobre arquivos benignos do sistema operacional

O Google SecOps ingere e armazena hashes de arquivos da fonte de dados GTI Benign Binaries. O Google SecOps armazena as informações ingeridas dessa fonte de dados nos seguintes campos da UDM. Os dados de binários benignos são atemporais.

Campo do UDM	Descrição
<variable_name>.graph.metadata.vendor_name	Armazena o valor Google Threat Intelligence.
<variable_name>.graph.metadata.product_name	Armazena o valor GTI Feed.
<variable_name>.graph.metadata.threat.threat_feed_name	Armazena o valor Benign Binaries.
<variable_name>.graph.entity.file.sha256	Armazena o valor de hash SHA256 do arquivo.
<variable_name>.graph.entity.file.sha1	Armazena o valor de hash SHA-1 do arquivo.
<variable_name>.graph.entity.file.md5	Armazena o valor de hash MD5 do arquivo.

Exemplo de pesquisa

graph.metadata.source_type ="GLOBAL_CONTEXT"
graph.metadata.product_name = "GTI Feed"
graph.metadata.threat.threat_feed_name = "Benign Binaries"

Dados sobre ferramentas de acesso remoto

As ferramentas de acesso remoto incluem hashes de arquivos para ferramentas conhecidas, como clientes VNC usados com frequência por agentes maliciosos. Essas ferramentas são geralmente aplicativos legítimos que às vezes são usados indevidamente para se conectar remotamente a sistemas comprometidos. O Google SecOps armazena as informações ingeridas dessa fonte de dados nos seguintes campos do UDM. Os dados das ferramentas de acesso remoto são atemporais.

Campo do UDM	Descrição
<variable_name>.graph.metadata.vendor_name	Armazena o valor Google Threat Intelligence.
<variable_name>.graph.metadata.product_name	Armazena o valor GTI Feed.
<variable_name>.graph.metadata.threat.threat_feed_name	Armazena o valor Remote Access Tools.
<variable_name>.graph.entity.file.sha256	Armazena o valor de hash SHA256 do arquivo.
<variable_name>.graph.entity.file.sha1	Armazena o valor de hash SHA-1 do arquivo.
<variable_name>.graph.entity.file.md5	Armazena o valor de hash MD5 do arquivo.

Exemplo de pesquisa

graph.metadata.source_type ="GLOBAL_CONTEXT"
graph.metadata.product_name = "GTI Feed"
graph.metadata.threat.threat_feed_name = "Remote Access Tools"

Aprimorar entidades com informações das listas de ameaças da Navegação segura

O Google SecOps ingere dados da Navegação segura relacionados a hashes de arquivos. O Google SecOps armazena os dados de cada arquivo como uma entidade e fornece mais contexto sobre ele. É possível criar regras de mecanismo de detecção que consultam esses dados de contexto da entidade para criar análises com reconhecimento de contexto.

Observação: só é possível usar o Navegação segura em regras, e os dados são considerados atemporais.

O Google SecOps armazena as seguintes informações com o registro de contexto da entidade.

Campo do UDM	Descrição
entity.metadata.product_entity_id	Um identificador exclusivo da entidade.
entity.metadata.entity_type	Esse valor é FILE, indicando que a entidade descreve um arquivo.
entity.metadata.collected_timestamp	A data e a hora em que a entidade foi observada ou o evento ocorreu.
entity.metadata.interval	Armazena o horário de início e de término em que esses dados são válidos. Como o conteúdo da lista de ameaças muda com o tempo, o start_time e o end_time refletem o intervalo em que os dados sobre a entidade são válidos. Por exemplo, um hash de arquivo foi considerado malicioso ou suspeito entre start_time e end_time.
entity.metadata.threat.category	O SecurityCategory do Google SecOps está definido como um ou mais dos seguintes valores: SOFTWARE_MALICIOUS: indica que a ameaça está relacionada a malware. SOFTWARE_PUA: indica que a ameaça está relacionada a software indesejado.
entity.metadata.threat.severity	Este é o ProductSeverity do Google SecOps. Se o valor for CRITICAL, isso indica que o artefato parece malicioso. Se o valor não for especificado, não haverá confiança suficiente para indicar que o artefato é malicioso.
entity.metadata.product_name	Armazena o valor Google Safe Browsing.
entity.file.sha256	O valor de hash SHA256 do arquivo.

Exemplo de regra

events:
    // find a process launch event, match on hostname
    $execution.metadata.event_type = "PROCESS_LAUNCH"
    $execution.target.process.file.sha256 != ""
    $execution.principal.hostname = $hostname

    // join execution event with Safe Browsing graph
    $sb.graph.entity.file.sha256 = $execution.target.process.file.sha256

    // look for files deemed malicious
    $sb.graph.metadata.entity_type = "FILE"
    $sb.graph.metadata.threat.severity = "CRITICAL"
    $sb.graph.metadata.product_name = "Google Safe Browsing"

  match:
    $hostname over 5m

  condition:
    $execution and $sb

Aprimorar entidades com dados do WHOIS

O Google SecOps realiza o aprimoramento diário de dados do WHOIS, uma função essencial, usando dados temporais e atemporais.

Durante a ingestão de dados do dispositivo, o Google SecOps avalia os domínios em relação aos dados do WHOIS. Quando os domínios correspondem, o Google SecOps armazena os dados relacionados do WHOIS no registro da entidade do domínio. Para cada entidade com entity.metadata.entity_type = DOMAIN_NAME, o Google SecOps enriquece o registro com informações do WHOIS.

O Google SecOps preenche o registro da entidade com dados enriquecidos do WHOIS nos seguintes campos:

• entity.domain.admin.attribute.labels
• entity.domain.audit_update_time
• entity.domain.billing.attribute.labels
• entity.domain.billing.office_address.country_or_region
• entity.domain.contact_email
• entity.domain.creation_time
• entity.domain.expiration_time
• entity.domain.iana_registrar_id
• entity.domain.name_server
• entity.domain.private_registration
• entity.domain.registrant.company_name
• entity.domain.registrant.office_address.state
• entity.domain.registrant.office_address.country_or_region
• entity.domain.registrant.email_addresses
• entity.domain.registrant.user_display_name
• entity.domain.registrar
• entity.domain.registry_data_raw_text
• entity.domain.status
• entity.domain.tech.attribute.labels
• entity.domain.update_time
• entity.domain.whois_record_raw_text
• entity.domain.whois_server
• entity.domain.zone

O Google SecOps aprimora entidades domain (entity.metadata.entity_type = "DOMAIN_NAME") com dados registrant, creation e expiration time de registros WHOIS global context.

Para descrições desses campos, consulte o documento da lista de campos do Modelo Unificado de Dados.

Exemplo de pesquisa

graph.metadata.source_type ="GLOBAL_CONTEXT"
graph.metadata.product_name = "WHOISXMLAPI Simple Whois"
graph.entity.domain.registry_data_raw_text != b""

Práticas recomendadas: identificar fontes de dados enriquecidas com contexto global

Para melhorar a performance das regras, inclua um filtro nas regras que usam dados das fontes de enriquecimento de contexto global. Esse filtro precisa identificar o tipo ou a origem específica do enriquecimento.

Os seguintes parâmetros de filtro identificam o tipo ou a origem do enriquecimento: entity_type, product_name e vendor_name.

Por exemplo, inclua os seguintes campos de filtro na seção events da regra que une dados do WHOIS:

$enrichment.graph.metadata.entity_type = "DOMAIN_NAME"
$enrichment.graph.metadata.product_name = "WHOISXMLAPI Simple Whois"
$enrichment.graph.metadata.vendor_name = "WHOIS"

Observação: conhecer a origem do enriquecimento pode ser tão valioso quanto os próprios dados, e um único campo da UDM pode ter várias origens de enriquecimento. Você pode conferir essas informações no Visualizador de eventos ou usando uma pesquisa de eventos do UDM (por exemplo, principal.hostname="john.doe.desktop" metadata.event_type="NETWORK_CONNECTION").

Práticas recomendadas de ECG

Ao usar dados enriquecidos contextualizados, considere as seguintes práticas recomendadas de ECG:

• Não adicione intervalos aos dados de entidades. Em vez disso, deixe o pipeline de eletrocardiograma criá-los. O Google SecOps gera intervalos durante a remoção de duplicação, a menos que especificado de outra forma.
• Se você especificar os intervalos, o Google SecOps vai remover apenas eventos idênticos e manter a entidade mais recente.
• Para garantir que as regras ativas e as retrocaças funcionem como esperado, ingira entidades pelo menos uma vez por dia.
• Se você não fizer a ingestão de entidades diariamente, mas apenas uma vez a cada dois dias ou mais, as regras ativas ainda poderão funcionar como esperado. No entanto, as retrocaças podem perder alguns contextos de eventos.
• Se você ingerir entidades idênticas mais de uma vez por dia, o Google SecOps vai remover as duplicadas e criar uma única entidade.
• Se os dados de eventos estiverem faltando em um dia, o Google SecOps usará temporariamente os dados do dia anterior para garantir que as regras ativas funcionem corretamente.

Para detalhes sobre os limites gerais do serviço Google SecOps, consulte Limites do serviço.

Conteúdo externo relacionado

• Usar o gráfico de entidade como uma lista multidimensional
• Pseudônimos no Chronicle SIEM
• IOCs expirando no gráfico de entidades
• Navegação segura do Google no Chronicle SIEM

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