Como usar o gráfico de contexto da entidade (ECG)

Compatível com:

Google SecOps SIEM

Este documento é uma visão geral abrangente do gráfico de contexto de entidade (ECG, na sigla em inglês), das fontes de dados, do pipeline de processamento e das 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 em cada ambiente do Google SecOps.

Além disso, o ECG calcula métricas de resumo para entidades, como prevalência (com que frequência uma entidade específica ocorre nos seus dados da UDM em comparação com outras entidades), first-seen-time e last-seen-time de uma entidade, bem como principais fontes de enriquecimento e indicadores de comprometimento (IOCs), como dados do Google Threat Intelligence (GTI), Navegação Segura, WHOIS e 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 ECG

O 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 gerenciamento 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 inteligência de ameaças e dados de reputação internos e externos. Por exemplo: Ingere e armazena dados da Inteligência do Google contra ameaças. 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 ECG

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

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

Em seguida, a fusão de ECGs cria um perfil completo e confiável para cada entidade, combinando o contexto de várias origens (como provedores de identidade, bancos de dados de gerenciamento de configuração [CMDBs, na sigla em inglês], feeds de inteligência de ameaças e contexto derivado) em um único perfil de entidade consolidado. A fusão de eletrocardiogramas adiciona novas conexões, propriedades e relações ao eletrocardiograma, além de criar e atualizar o contexto derivado.

O ECG cria entidades temporais e atemporais. O ECG avalia entidades com carimbo de data/hora nos intervalos de tempo especificados da regra e da pesquisa, enquanto avalia entidades atemporais sem considerar o intervalo de tempo da pesquisa ou da regra.

O eletrocardiograma mescla registros de contexto combinando identificadores de chave comuns, como hostname, MAC address, user ID ou email address, nessas diferentes fontes de dados. Ele 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 "chaves de mesclagem":

• 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

Quando há valores conflitantes com qualquer um dos campos acima durante o processo de fusão, o pipeline de ECG seleciona o valor com o horário de início mais recente para atualizar a entidade.

O eletrocardiograma cria dados de contexto de entidade com uma janela de lookback de cinco dias. Esse processo processa dados atrasados e cria um tempo de vida implícito para dados de contexto de entidade.

O ECG distingue entre dados contextuais (ativos, usuários, recursos, grupos) e indicadores de comprometimento (IOCs, na sigla em inglês).

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

O Google SecOps ingere dados de usuários 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]) para criar uma entidade de usuário jdoe unificada no ECG, que contém atributos de todas as três fontes.

Exemplo: eliminar dados redundantes para criar uma entidade comum

Para criar uma entidade combinada comum, o ECG elimina dados redundantes por eliminação de duplicação. Isso é feito gerando 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.

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 os 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 de 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 do 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 da entidade do Duo (DUO_CONTEXT) e do 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 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 dos dados para verificar a integridade deles.	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 são aqueles que atuam 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 e gateway de e-mail.	principal.user.userid, principal.user.email_addresses, target.user.userid, principal.ip
  Rede	Firewall, VPN, DNS, registros de fluxo de 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

Os dados de ECG dependem desses campos do UDM para unir dados de ECG e 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 dinâmicos de inferência orientada a eventos com base nos dados de eventos da sua organização para cada entidade em todos os namespaces. 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 usando um IP address). Esse processo adiciona um contexto valioso para melhorar os perfis de entidades.

Por exemplo, ele adiciona entity.file.sha256 a entidades file (hash) e (principal or target).ip_geo_artifact.location.country_or_region a entidades network (geolocation).

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 entidades, como estatísticas de prevalência, e métricas temporais, como first-seen-time e last-seen-time.

Estatísticas de prevalência

O ECG também é responsável por analisar 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 em todo o ambiente. Isso ajuda você a identificar atividades raras ou incomuns, já que as entidades mais populares geralmente têm menos probabilidade de serem maliciosas.

O Google SecOps atualiza essas estatísticas regularmente e as armazena em um contexto de entidade separada. 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 é a pontuação máxima de prevalência do artefato durante o dia (um dia é definido como das 0h00 às 23h59 UTC).
• rolling_max é a pontuação máxima de prevalência por dia (ou seja, day_max) do artefato na janela de 10 dias anterior.
• O sistema usa day_count para calcular rolling_max, e o valor é sempre 10.

Quando o sistema calcula esses valores 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 levar a 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 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 de 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.

Com esses campos derivados, é possível correlacionar a atividade em entidades de domain, file hash, asset, user ou IP address.

O sistema armazena esses valores 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 de 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 da Inteligência de ameaças do Google (GTI, na sigla em inglês) e fornece 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 da 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 de sistemas operacionais 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.

O sistema armazena esses dados contextuais 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 de validade

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. Se o Google SecOps gerar uma detecção no dia 1, em qualquer dia no futuro, o Google SecOps vai gerar a mesma detecção para o dia 1 durante uma retrocaça.

As fontes de dados atemporais não têm um período associado. Isso porque você só precisa considerar o conjunto de dados mais recente. Normalmente, o sistema usa fontes de dados atemporais 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 poderá ser gerada para o dia 1 durante uma retrocaça no dia 2 porque uma nova entrada foi 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. Os dados do nó de saída do Tor são marcados com carimbo de data/hora.

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, que agentes maliciosos usam com frequência. Essas ferramentas geralmente são 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"

Enriquecer 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: a Navegação segura só pode ser usada 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. O sistema define esse campo 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 sistema executa o enriquecimento de dados do WHOIS diariamente como uma função essencial. Os dados do WHOIS são temporais e atemporais.

Durante a ingestão dos 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 com o registro da entidade do domínio. Para cada entidade com entity.metadata.entity_type = DOMAIN_NAME, o Google SecOps a enriquece com informações do WHOIS.

O Google SecOps preenche os seguintes campos no registro da entidade com dados enriquecidos do WHOIS:

• 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 de dados unificado.

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 o desempenho das regras, inclua um filtro nas que usam dados de fontes de enriquecimento de contexto global para identificar o tipo ou a fonte de enriquecimento específica.

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").

Limitações e sugestões do gráfico de contexto de entidade

Ao usar dados enriquecidos contextualizados, considere o seguinte comportamento do eletrocardiograma:

• Não adicione intervalos aos dados de entidades. Em vez disso, deixe o ECG criar intervalos. Isso ocorre porque 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 os eventos iguais e manter a entidade mais recente.
• Para garantir que as regras ativas e as pesquisas retroativas funcionem conforme o esperado, ingira entidades pelo menos uma vez por dia.
• Se você não ingerir entidades diariamente, mas apenas uma vez a cada dois dias ou mais, as regras ativas 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 mais 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.