Visão geral do UDM

Compatível com:

Google SecOps SIEM

Este documento apresenta uma visão geral do modelo de dados unificado (UDM). Para mais detalhes sobre os campos de UDM, incluindo uma descrição de cada um, consulte a lista de campos de UDM. Para mais informações sobre o mapeamento do analisador, consulte Campos importantes do UDM para mapeamento do analisador.

O UDM é uma estrutura de dados padrão do Google Security Operations que armazena informações sobre os dados recebidos de fontes. Ele também é chamado de esquema. O Google SecOps armazena os dados originais que recebe em dois formatos: como o registro bruto original e como um registro UDM estruturado. O registro do UDM é uma representação estruturada do registro original.

Se houver um analisador para o tipo de registro especificado, o registro bruto será usado para criar um registro de UDM. Os clientes também podem transformar registros brutos no formato UDM estruturado antes de enviar os dados para o Google SecOps usando a API Ingestion.

Alguns dos benefícios do UDM incluem:

• Armazena o mesmo tipo de registro de diferentes fornecedores usando a mesma semântica.
• É mais fácil identificar relações entre usuários, hosts e endereços IP porque os dados são normalizados no esquema UDM padrão.
• É mais fácil escrever regras, já que elas podem ser independentes da plataforma.
• Mais facilidade para oferecer suporte a tipos de registro de novos dispositivos.

Observação : o mecanismo de regras do Google SecOps usa os mesmos nomes de campo do UDM. É possível usar esses mesmos nomes de campo ao criar regras.

Embora seja possível pesquisar eventos com uma pesquisa de registro bruto, uma pesquisa de UDM funciona mais rápido e com mais precisão devido à especificidade. O Google SecOps coleta dados de registro brutos e armazena os detalhes do log de eventos no esquema do UDM. O UDM fornece um framework abrangente de milhares de campos para descrever e categorizar diversos tipos de eventos, por exemplo, eventos de processo de endpoint e eventos de comunicação de rede.

Estrutura do UDM

Os eventos do UDM são compostos por várias seções. A primeira seção encontrada em todos os eventos do UDM é a seção de metadados. Ele fornece uma descrição básica do evento, incluindo o carimbo de data/hora de quando o evento ocorreu e o carimbo de data/hora de quando ele foi ingerido no Google SecOps. Ele também inclui as informações do produto, a versão e a descrição. O analisador de ingestão classifica cada evento com base em um tipo de evento predefinido, independentemente do registro do produto específico. Com os campos de metadados, é possível começar a pesquisar os dados rapidamente.

Além da seção de metadados, outras seções descrevem outros aspectos do evento. Se uma seção for desnecessária, ela não será incluída, o que economiza memória.

• principal: entidade que origina a atividade no evento. As seções que fazem referência à origem (src) e ao destino (target) também estão incluídas.
• intermediary: sistemas pelos quais os eventos passam, como um servidor proxy ou um redirecionamento SMTP.
• observer: sistemas como sniffers de pacotes que monitoram passivamente o tráfego.

Formatar um evento de UDM

Para formatar um evento de UDM e deixá-lo pronto para ser enviado ao Google, siga estas etapas:

1. Especifique o tipo de evento: o tipo de evento selecionado determina quais campos você também precisa incluir no evento.
2. Especifique o carimbo de data/hora do evento.
3. Especifique substantivos (entidades): cada evento precisa incluir pelo menos um substantivo que descreva um dispositivo ou usuário participante envolvido no evento.
4. Opcional: especifique o resultado de segurança: inclua detalhes sobre os riscos e as ameaças que um sistema de segurança encontra. Inclua as ações específicas tomadas para mitigar esses riscos e ameaças.
5. Preencha o restante das informações de evento obrigatórias e opcionais usando os campos de evento do UDM.

Especificar o tipo de evento

Sempre especifique o tipo de evento para cada evento enviado no formato UDM. Especifique esse valor usando um dos valores possíveis disponíveis para metadata.event_type. Isso inclui valores como PROCESS_OPEN, FILE_CREATION, USER_CREATION e NETWORK_DNS (para ver a lista completa, consulte Metadata.event_type). Cada tipo de evento também exige que você preencha um conjunto de outros campos e valores com as informações vinculadas ao evento original. Para saber quais campos incluir em cada tipo de evento, consulte Campos obrigatórios e opcionais para cada tipo de evento.

O exemplo a seguir ilustra como especificar PROCESS_OPEN como o tipo de evento usando a notação de texto Proto3:

metadata {
    event_type: PROCESS_OPEN
}

Especificar o carimbo de data/hora do evento

É necessário especificar o carimbo de data/hora GMT para qualquer evento enviado no formato UDM usando Metadata.event_timestamp. O carimbo precisa ser codificado usando um dos seguintes padrões:

• Para JSON, use RFC 3339
• Carimbo de data/hora do Proto3

O exemplo a seguir ilustra como especificar o carimbo de data/hora usando o formato RFC 3339. Neste exemplo, aaaa-mm-ddThh:mm:ss+hh:mm: ano, mês, dia, hora, minuto, segundo e a diferença em relação ao horário UTC. A diferença em relação ao UTC é de menos 8 horas, indicando PST.

metadata {
  event_timestamp: "2019-09-10T20:32:31-08:00"
}

Especificar substantivos (entidades)

Defina um ou mais substantivos para cada evento de UDM. Os substantivos representam participantes ou entidades, como o usuário que realiza a atividade, o destino da ação ou o dispositivo de segurança que observa o evento (por exemplo, um proxy de e-mail ou roteador). Os substantivos também representam objetos, como URLs ou anexos.

Atenção : para eventos de UDM, os campos de nome do host têm um limite de 256 caracteres (por exemplo, principal.hostname ou target.hostname). O mapeamento de registros brutos (de uma fonte como o ArcSight) que excedem esse limite resulta em falhas de validação e registros descartados. Isso não é específico de analisadores individuais.

Um evento de UDM precisa ter um ou mais dos seguintes substantivos especificados:

principal: representa a entidade ou o dispositivo que origina a atividade descrita no evento. O principal precisa incluir pelo menos um detalhe da máquina (nome do host, MACs, IPs, porta, identificadores específicos do produto, como um GUID de máquina do CrowdStrike) ou do usuário (por exemplo, nome de usuário) e, opcionalmente, detalhes do processo. NÃO pode incluir nenhum dos seguintes campos: e-mail, arquivos, chaves de registro ou valores.

Se todas as atividades ocorrerem em uma única máquina, descreva apenas essa máquina no bloco principal. Não duplique os detalhes da máquina em target ou src.

Observação: não descreva dispositivos de segurança no campo principal, mesmo que eles tenham originado o evento. Em vez disso, use os campos observer ou intermediary. Se o software de segurança for executado no mesmo dispositivo que originou a atividade (como um agente de EDR em um endpoint do Windows), esse dispositivo ainda será o principal.

O exemplo a seguir ilustra como os campos principal podem ser preenchidos:

principal {
  hostname: "jane_win10"
  asset_id: "Sophos.AV:C070123456-ABCDE"
      ip: "10.0.2.10"
      port: 60671
      user {  userid: "john.smith" }
}

Este exemplo fornece detalhes sobre o dispositivo e o usuário que foi o ator principal no evento. Ele também inclui um identificador de recurso específico do fornecedor (da Sophos), que é um ID exclusivo gerado pelo produto de segurança de terceiros.

target: representa o dispositivo ou objeto referenciado pelo evento. Em uma conexão de firewall do dispositivo A para o dispositivo B, A é o principal e B é o destino. Em uma injeção de processo em que o processo C é injetado no processo D, C é o principal e D é o destino.

Principal versus destino no UDM

O exemplo a seguir ilustra como os campos de um destino são preenchidos:

target {
   ip: "198.51.100.31"
   port: 80
}

Inclua todas as outras informações disponíveis no bloco target, como o nome do host, outros endereços IP ou endereço MAC e identificadores de recursos reservados.

Tanto principal quanto target (e outros substantivos) podem fazer referência a atores na mesma máquina. Por exemplo, se o processo A (principal) em execução na máquina X agir no processo B (destino) também na máquina X, descreva ambos nos respectivos blocos.

• src: representa o objeto de origem que está sendo processado e o contexto dele, como a máquina em que ele reside. Por exemplo, se o usuário U copiar o arquivo A na máquina X para o arquivo B na máquina Y, especifique o arquivo A e a máquina X no bloco src.

• intermediary: contém detalhes de um ou mais dispositivos que processaram a atividade descrita no evento. Isso inclui informações para dispositivos, como servidores proxy e redirecionamentos SMTP.

• observer: representa um dispositivo que não é um intermediário direto, mas monitora e informa sobre atividades. Isso inclui dispositivos como analisadores de pacotes ou verificações de vulnerabilidades baseadas em rede.

• about: armazena detalhes de todos os objetos referenciados pelo evento que não se encaixam em participant, src, target, intermediary ou observer. Use-o para acompanhar itens como:

  • Anexos de arquivos de e-mail
  • Domínios/URLs/IPs incorporados no corpo do e-mail
  • DLLs carregadas durante um evento PROCESS_LAUNCH

As seções de entidade dos eventos do UDM incluem informações sobre os vários participantes (dispositivos, usuários, objetos como URLs, arquivos etc.) descritos no evento. O UDM do Google Security Operations tem requisitos obrigatórios para preencher campos de substantivos. Esses requisitos são descritos em Campos obrigatórios e opcionais para cada tipo de evento do UDM. O conjunto de campos de entidade que precisam ser preenchidos varia de acordo com o tipo de evento.

Especificar o resultado de segurança

Se quiser, você pode especificar os resultados de segurança preenchendo os campos SecurityResult, incluindo detalhes sobre riscos e ameaças de segurança encontrados pelo sistema de segurança, bem como as ações tomadas para mitigar esses riscos e ameaças. Veja a seguir exemplos de alguns tipos de ocorrências de segurança que exigem o preenchimento dos campos SecurityResult:

• Um firewall de proxy de segurança de e-mail detectou dois anexos infectados (SOFTWARE_MALICIOUS). Ele colocou os arquivos em quarentena e os desinfectou (QUARANTINE, ALLOW_WITH_MODIFICATION) e, em seguida, encaminhou o e-mail desinfectado.

• Um sistema de SSO facilitou uma tentativa de login que resultou em um AUTH_VIOLATION e foi bloqueado (BLOCK).

• Um sandbox de malware detectou spyware (SOFTWARE_MALICIOUS) em um anexo de arquivo cinco minutos após o sistema entregar (ALLOW) o e-mail à caixa de entrada do usuário.

Exemplos de pesquisas de UDM

Nesta seção, apresentamos exemplos de pesquisas de UDM que demonstram algumas das sintaxes, recursos e capacidades básicas da pesquisa de UDM.

Exemplo: pesquisar logins bem-sucedidos do Microsoft Windows 4624

A pesquisa a seguir lista os eventos de login bem-sucedidos do Microsoft Windows 4624, além de quando os eventos foram gerados, com base em apenas dois campos de UDM:

metadata.event_type = "USER_LOGIN" AND metadata.product_event_type = "4624"

Exemplo: pesquisar todos os logins bem-sucedidos

A pesquisa a seguir lista todos os eventos de login bem-sucedidos, independentemente do fornecedor ou do aplicativo:

metadata.event_type = "USER_LOGIN" AND security_result.action = "ALLOW" AND target.user.userid != "SYSTEM" AND target.user.userid != /.*$/

Exemplo: pesquisar logins de usuários bem-sucedidos

O exemplo a seguir ilustra como pesquisar userid "fkolzig" e determinar quando o usuário com esse ID fez login. Você pode concluir essa pesquisa usando a seção de destino. A seção de destino inclui subseções e campos que descrevem o destino. Por exemplo, o destino neste caso é um usuário e tem vários atributos associados, mas o destino também pode ser um arquivo, uma configuração de registro ou um recurso. Este exemplo pesquisa "fkolzig" usando o campo target.user.userid.

metadata.event_type = "USER_LOGIN" AND metadata.product_event_type = "4624" AND target.user.userid = "fkolzig"

Exemplo: pesquisar dados de rede

O exemplo a seguir pesquisa dados de rede em busca de eventos de RDP com um target.port de 3389 e um principal.ip de 35.235.240.5. Ele também inclui um campo UDM da seção de rede, a direção dos dados (network.direction).

metadata.product_event_type = "3" AND target.port = 3389 AND network.direction = "OUTBOUND" and principal.ip = "35.235.240.5"

Exemplo: pesquisar um processo específico

Para examinar os processos criados nos servidores, procure instâncias do comando net.exe e pesquise esse arquivo específico no caminho esperado. O campo que você está procurando é target.process.file.full_path. Para essa pesquisa, inclua o comando específico emitido no campo target.process.command_line. Também é possível adicionar um campo na seção "Sobre", que é a descrição do código de evento 1 do Microsoft Sysmon (ProcessCreate).

Esta é a pesquisa de UDM:

metadata.product_event_type = "1" AND target.process.file.full_path = "C:\Windows\System32\net.exe"

Se quiser, adicione os seguintes campos de pesquisa de UDM:

• principal.user.userid: identifica o usuário que emite o comando.
• principal.process.file.md5: identifique o hash MD5.
• principal.process.command_line: linha de comando.

Exemplo: pesquisar logins de usuários bem-sucedidos associados a um departamento específico

O exemplo a seguir pesquisa logins de usuários (metadata.event_type é USER_LOGIN) associados ao departamento de marketing (target.user.department é marketing) da sua empresa. Embora o target.user.department não esteja diretamente conectado aos eventos de login do usuário, ele ainda está presente nos dados do LDAP ingeridos sobre seus usuários.

metadata.event_type = "USER_LOGIN" AND target.user.department = "Marketing"

Objetos lógicos: evento e entidade

O esquema do UDM descreve todos os atributos disponíveis que armazenam dados. Cada registro de UDM identifica se ele descreve um evento ou uma entidade. Os dados são armazenados em campos diferentes, dependendo se o registro descreve um evento ou uma entidade e também de qual valor está definido no campo metadata.event_type ou metadata.entity_type.

• Evento de UDM: armazena dados de uma ação que ocorreu no ambiente. O log de eventos original descreve a ação como ela foi registrada pelo dispositivo, como firewall e proxy da Web.
• Entidade UDM: representação contextual de elementos como recursos, usuários e recursos no seu ambiente. Ele é obtido de uma fonte de dados de fonte de verdade.

Confira duas representações visuais de alto nível do modelo de dados de eventos e do modelo de dados de entidades.

Observação: o termo "substantivo" descreve o tipo de atributo. Os termos principal, target, src, intermediary, observer e about são os nomes dos campos em que os dados são armazenados.

Figura: modelo de dados de eventos

Observação: o termo "substantivo" descreve o tipo de atributo. Os termos "recurso", "usuário" e "recurso" são os nomes dos campos em que os dados são armazenados.

Figura: modelo de dados de entidade

Estrutura de um evento de UDM

O evento do UDM contém várias seções que armazenam um subconjunto dos dados de um único registro. As seções são:

• metadados
• participante
• destino
• src
• observador
• intermediário
• sobre
• rede
• security_result

• extensões

  

  Figura: modelo de dados de eventos

A seção metadata armazena o carimbo de data/hora, define o event_type e descreve o dispositivo.

As seções principal, target, src, observer e intermediary armazenam informações sobre os objetos envolvidos no evento. Um objeto pode ser um dispositivo, usuário ou processo. Na maioria das vezes, apenas um subconjunto dessas seções é usado. Os campos que armazenam dados são determinados pelo tipo de evento e pela função que cada objeto desempenha no evento.

A seção rede armazena informações relacionadas à atividade da rede, como comunicação relacionada a e-mail e rede.

• Dados de e-mail: informações nos campos to, from, cc, bcc e outros campos de e-mail.
• Dados HTTP: como method, referral_url e useragent.

A seção security_result armazena uma ação ou classificação registrada por um produto de segurança, como um antivírus.

As seções about e extensions armazenam outras informações de eventos específicas do fornecedor que não são capturadas pelas outras seções. A seção extensions é um conjunto de formato livre de pares de chave-valor.

Cada evento do UDM armazena valores de um evento de registro bruto original. Dependendo do tipo de evento, alguns atributos são obrigatórios, enquanto outros são opcionais. Os atributos obrigatórios e opcionais são determinados pelo valor metadata.event_type. O Google SecOps lê metadata.event_type e realiza a validação de campo específica para esse tipo de evento depois que os registros são recebidos.

Se nenhum dado for armazenado em uma seção do registro do UDM, por exemplo, a seção de extensões, ela não vai aparecer no registro do UDM.

Os campos de metadados

Nesta seção, descrevemos os campos obrigatórios em um evento de UDM.

O campo event_timestamp

Os eventos de UDM precisam incluir dados para o metadata.event_timestamp, que é o carimbo de data/hora GMT de quando o evento ocorreu. O valor precisa ser codificado usando um dos seguintes padrões: carimbo de data/hora RFC 3339 ou Proto3.

Os exemplos a seguir ilustram como especificar o carimbo de data/hora usando o formato RFC 3339, yyyy-mm-ddThh:mm:ss+hh:mm (ano, mês, dia, hora, minuto, segundo e o deslocamento do horário UTC). A diferença em relação ao UTC é de menos 8 horas, indicando PST.

metadata {
  "event_timestamp": "2019-09-10T20:32:31-08:00"
}

metadata {
  event_timestamp: "2021-02-23T04:00:00.000Z"
}

Também é possível especificar o valor usando o formato de época.

metadata {
event_timestamp: {
  "seconds": 1588180305
 }
}

O campo event_type

O campo mais importante no evento do UDM é metadata.event_type. Esse valor identifica o tipo de ação realizada e é independente de fornecedor, produto ou plataforma. Exemplos de valores incluem PROCESS_OPEN, FILE_CREATION, USER_CREATION e NETWORK_DNS. Para ver a lista completa, consulte o documento Lista de campos do UDM.

O valor metadata.event_type determina quais campos obrigatórios e opcionais adicionais precisam ser incluídos no registro do UDM. Para saber quais campos incluir em cada tipo de evento, consulte o guia de uso do UDM.

Os atributos principal, target, src, intermediary, observer e about

Os atributos principal, target, src, intermediary e observer descrevem os recursos envolvidos no evento. Cada um armazena informações sobre objetos envolvidos na atividade, conforme registrado pelo registro bruto original. Pode ser o dispositivo ou usuário que realizou a atividade, o dispositivo ou usuário que é o destino da atividade. Ele também pode descrever um dispositivo de segurança que observou a atividade, como um proxy de e-mail ou roteador de rede.

Os atributos mais usados com frequência são:

• principal: objeto que realizou a atividade.
• src: objeto que inicia a atividade, se for diferente do principal.
• target: objeto que sofre a ação.

Cada tipo de evento exige que pelo menos um desses campos contenha dados.

Os campos auxiliares são:

• intermediary: qualquer objeto que tenha atuado como intermediário no evento. Isso pode incluir objetos como servidores proxy e de e-mail.
• observer: qualquer objeto que não interaja diretamente com o tráfego em questão. Pode ser um verificador de vulnerabilidades ou um dispositivo de detecção de pacotes.
• about: quaisquer outros objetos que desempenharam um papel no evento e são opcionais.

Os atributos principais

Representa a entidade ou o dispositivo que originou a atividade. O principal precisa incluir pelo menos um detalhe da máquina (nome do host, endereço MAC, endereço IP, identificadores específicos do produto, como um GUID de máquina do CrowdStrike) ou do usuário (por exemplo, nome de usuário) e, opcionalmente, detalhes do processo. Ele não pode incluir nenhum dos seguintes campos: e-mail, arquivos, chaves ou valores de registro.

Se o evento ocorrer em uma única máquina, ela será descrita apenas no atributo principal. A máquina não precisa ser descrita nos atributos target ou src.

Observação : um dispositivo de segurança pode registrar um evento, mas ele não será descrito no atributo principal. Ele seria descrito no atributo de observador ou intermediário. Se o software de segurança (por exemplo, Carbon Black) for executado no mesmo dispositivo que originou a atividade (por exemplo, um endpoint do Windows em que o malware foi detectado), o dispositivo Windows será o principal.

O snippet JSON a seguir ilustra como o atributo principal pode ser preenchido.

"principal": {
  "hostname": "jane_win10",
  "asset_id" : "Sophos.AV:C070123456-ABCDE",
    "ip" : "10.10.2.10",
    "port" : 60671,
    "user": {  "userid" : "john.smith" }
}

Esse atributo descreve tudo o que se sabe sobre o dispositivo e o usuário que foi o ator principal no evento. Este exemplo inclui o endereço IP, o número da porta e o nome do host do dispositivo. Ele também inclui um identificador de recurso específico do fornecedor, da Sophos, que é um identificador exclusivo gerado pelo produto de segurança de terceiros.

Os atributos de destino

Representa um dispositivo de destino referenciado pelo evento ou um objeto no dispositivo de destino. Por exemplo, em uma conexão de firewall do dispositivo A para o dispositivo B, o dispositivo A é capturado como o principal e o dispositivo B é capturado como o destino.

Para uma injeção de processo pelo processo C no processo de destino D, o processo C é o principal e o processo D é o destino.

Figura: principal x destino

O exemplo a seguir ilustra como o campo de destino pode ser preenchido.

target {
   ip: "192.0.2.31"
   port: 80
}

Se houver mais informações disponíveis no registro bruto original, como nome do host, outros endereços IP, endereços MAC e identificadores de recursos reservados, elas também precisarão ser incluídas nos campos de destino e principal.

Tanto o principal quanto o destino podem representar atores na mesma máquina. Por exemplo, o processo A (principal) em execução na máquina X pode atuar no processo B (destino) também na máquina X.

O atributo src

Representa um objeto de origem que está sendo usado pelo participante, além do contexto do dispositivo ou do processo para o objeto de origem (a máquina em que o objeto de origem reside). Por exemplo, se o usuário U copiar o arquivo A na máquina X para o arquivo B na máquina Y, o arquivo A e a máquina X serão especificados na parte src do evento UDM.

O atributo intermediário

Representa detalhes sobre uma ou mais atividades de processamento de dispositivos intermediários descritas no evento. Isso pode incluir detalhes sobre dispositivos como servidores proxy e servidores de redirecionamento SMTP.

O atributo observer

Representa um dispositivo observador que não é um intermediário direto, mas que observa e informa sobre o evento em questão. Isso pode incluir um sniffer de pacotes ou um verificador de vulnerabilidades baseado em rede.

O atributo about

Armazena detalhes sobre um objeto referenciado pelo evento que não é descrito nos campos principal, src, target, intermediary ou observer. Por exemplo, ele pode capturar o seguinte:

• Anexos de arquivos de e-mail.
• Domínios, URLs ou endereços IP incorporados ao corpo do e-mail.
• DLLs que são carregadas durante um evento PROCESS_LAUNCH.

O atributo security_result

Esta seção contém informações sobre riscos e ameaças de segurança encontrados por um sistema de segurança e as ações tomadas para mitigá-los.

Veja alguns tipos de informações que seriam armazenadas no atributo security_result:

• Um proxy de segurança de e-mail detectou uma tentativa de phishing (security_result.category = MAIL_PHISHING) e bloqueou (security_result.action = BLOCK) o e-mail.
• Um firewall de proxy de segurança de e-mail detectou dois anexos infectados (security_result.category = SOFTWARE_MALICIOUS), colocou em quarentena e desinfectou (security_result.action = QUARANTINE or security_result.action = ALLOW_WITH_MODIFICATION) esses anexos e, em seguida, encaminhou o e-mail desinfectado.
• Um sistema de SSO permite um login (security_result.category = AUTH_VIOLATION) que foi bloqueado (security_result.action = BLOCK).
• Um sandbox de malware detectou spyware (security_result.category = SOFTWARE_MALICIOUS) em um anexo de arquivo cinco minutos depois que o arquivo foi entregue (security_result.action = ALLOW) ao usuário na caixa de entrada.

O atributo de rede

Os atributos de rede armazenam dados sobre eventos relacionados à rede e detalhes sobre protocolos em submensagens. Isso inclui atividades como e-mails enviados e recebidos e solicitações HTTP.

O atributo de extensões

Os campos desse atributo armazenam metadados adicionais sobre o evento capturado no registro bruto original. Ele pode conter informações sobre vulnerabilidades ou outras informações relacionadas à autenticação.

Estrutura de uma entidade do UDM

Um registro de entidade de UDM armazena informações sobre qualquer entidade em uma organização. Se o metadata.entity_type for USER, o registro vai armazenar informações sobre o usuário no atributo entity.user. Se o metadata.entity_type for ASSET, o registro armazenará informações sobre um recurso, como estação de trabalho, laptop, telefone e máquina virtual.

Figura: modelo de dados de eventos

Os campos de metadados

Esta seção contém campos obrigatórios em uma entidade UDM, como:

• collection_timestamp: a data e a hora em que o registro foi coletado.
• entity_type: o tipo de entidade, como recurso, usuário e recurso.

O atributo de entidade

Os campos no Attribute Store de entidade armazenam informações sobre a entidade específica, como nome do host e endereço IP, se for um ativo, ou windows_sid e endereço de e-mail, se for um usuário. O nome do campo é entity, mas o tipo de campo é um substantivo. Um substantivo é uma estrutura de dados usada com frequência que armazena informações em entidades e eventos.

• Se o metadata.entity_type for USER, os dados serão armazenados no atributo entity.user.
• Se o metadata.entity_type for ASSET, os dados serão armazenados no atributo entity.asset.

O atributo de relação

Os campos no atributo de relação armazenam informações sobre outras entidades relacionadas à entidade principal. Por exemplo, se a entidade principal for um usuário e ele tiver recebido um laptop. O laptop é uma entidade relacionada. As informações sobre o laptop são armazenadas como um registro entity com um metadata.entity_type = ASSET. As informações sobre o usuário são armazenadas como um registro entity com metadata.entity_type = USER.

O registro da entidade do usuário também captura a relação entre o usuário e o laptop, usando campos no atributo relation. O campo relation.relationship armazena a relação que o usuário tem com o laptop, especificamente que o usuário é o proprietário do laptop. O campo relation.entity_type armazena o valor ASSET, porque o notebook é um dispositivo.

Os campos no atributo relations.entity armazenam informações sobre o laptop, como o nome do host e o endereço MAC. Observe novamente que o nome do campo é entity e o tipo de campo é um substantivo. Um substantivo é uma estrutura de dados usada com frequência. Os campos no atributo relation.entity armazenam informações sobre o laptop.

O campo relation.direction armazena a direcionalidade da relação entre o usuário e o laptop, especificamente se a relação é bidirecional ou unidirecional.

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