Visão geral do modelo unificado de dados

Compatível com:

Google SecOps SIEM

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

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

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

Confira alguns dos benefícios do UDM:

• 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 fácil oferecer suporte a tipos de registros de novos dispositivos.

Observação: o mecanismo de regras do Google SecOps usa os mesmos nomes de campo da UDM. Você pode usar esses mesmos nomes de campo ao criar regras.

Embora seja possível pesquisar eventos com uma pesquisa de registros brutos, uma pesquisa UDM funciona mais rápido e com mais precisão devido à sua especificidade. O Google SecOps coleta dados de registro brutos e armazena os detalhes do log de eventos no esquema UDM. A UDM oferece 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 da UDM

Os eventos da UDM são compostos por várias seções. A primeira seção encontrada em todos os eventos da UDM é a de metadados. Ele fornece uma descrição básica do evento, incluindo o carimbo de data/hora de quando ele ocorreu e de quando 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, independente do registro específico do produto. Com apenas os campos de metadados, você pode começar a pesquisar os dados rapidamente.

Além da seção de metadados, outras seções descrevem aspectos adicionais do evento. Se uma seção for desnecessária, ela não será incluída, economizando 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 por que os eventos passam, como um servidor proxy ou um redirecionamento SMTP.
• observer: sistemas como sniffers de pacotes que monitoram o tráfego de forma passiva.

Formatar um evento do UDM

Para formatar um evento da UDM e prepará-lo para envio ao Google, siga estas etapas:

1. Especifique o tipo de evento: o tipo de evento selecionado determina quais campos também precisam ser incluídos com o 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, incluindo detalhes sobre os riscos e ameaças encontrados por um sistema de segurança. 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

O valor mais importante definido para qualquer evento enviado no formato UDM é o tipo de evento, especificado usando um dos valores possíveis disponíveis para "Metadata.event_type". Isso inclui valores como PROCESS_OPEN, FILE_CREATION, USER_CREATION, NETWORK_DNS etc. Para conferir a lista completa, consulte Metadata.event_type. Cada tipo de evento exige que você preencha um conjunto de outros campos e valores com as informações vinculadas ao evento original. Consulte Campos obrigatórios e opcionais para cada tipo de evento da UDM para saber quais campos incluir em 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 representa ano, mês, dia, hora, minuto, segundo e o deslocamento do horário UTC. O deslocamento do 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 da 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 um roteador). Substantivos também representam objetos como URLs ou anexos.

Atenção: para eventos da 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 da 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 da máquina CrowdStrike) ou do usuário (por exemplo, nome de usuário) e, opcionalmente, detalhes do processo. Ela NÃO pode incluir nenhum dos seguintes campos: e-mail, arquivos, chaves ou valores de registro.

Se toda a atividade ocorrer 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 sejam a origem do 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 principal ator 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 injeta no processo D, C é o principal e D é o destino.

Principal x destino na UDM

O exemplo a seguir ilustra como os campos de uma meta são preenchidos:

target {
   ip: "198.51.100.31"
   port: 80
}

Inclua outras informações disponíveis no bloco destino, como o nome do host, endereços IP ou MAC adicionais e identificadores de recursos proprietários.

O principal e o destino (e outros substantivos) podem se referir 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 os dois nos blocos respectivos.

• src:representa o objeto de origem em que a ação está sendo realizada 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 a atividade. Isso inclui dispositivos como sniffers de pacotes ou verificadores de vulnerabilidade baseados 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 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 da UDM incluem informações sobre os vários participantes (dispositivos, usuários, objetos como URLs, arquivos etc.) descritos no evento. A UDM do Google Security Operations tem requisitos obrigatórios para preencher os campos de substantivo. Esses requisitos estã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

Você pode especificar os resultados de segurança preenchendo os campos "SecurityResult", incluindo detalhes sobre riscos e ameaças à segurança encontrados pelo sistema de segurança, bem como as ações tomadas para mitigar esses riscos e ameaças. Confira alguns exemplos de tipos de eventos de segurança que exigem o preenchimento dos campos "SecurityResult":

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

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

• Um sandbox de malware detectou spyware (SOFTWARE_MALICIOUS) em um anexo de arquivo cinco minutos depois que o sistema entregou (ALLOW) o e-mail na Caixa de entrada do usuário.

Exemplos de pesquisas UDM

Esta seção fornece exemplos de pesquisas UDM que demonstram um pouco da sintaxe, dos recursos e das funcionalidades básicas da pesquisa UDM.

Exemplo: pesquisar logins bem-sucedidos do Microsoft Windows 4624

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

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

Exemplo: pesquisar todos os logins concluídos

A pesquisa a seguir lista todos os eventos de login bem-sucedidos, independente do fornecedor ou 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 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 os dados da sua rede

O exemplo a seguir pesquisa dados de rede para eventos 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 seus servidores, procure instâncias do comando net.exe e procure 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. Você também pode adicionar um campo na seção "Sobre" com a descrição do código de evento 1 do Microsoft Sysmon (ProcessCreate).

Esta é a pesquisa UDM:

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

Opcionalmente, você pode adicionar os seguintes campos de pesquisa da UDM:

• principal.user.userid: identifique o usuário que está emitindo 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 target.user.department não esteja diretamente conectado aos eventos de login do usuário, ele ainda está presente nos dados LDAP ingeridos sobre seus usuários.

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

Objetos lógicos: evento e entidade

O esquema da UDM descreve todos os atributos disponíveis que armazenam dados. Cada registro da UDM identifica se 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 qual valor é definido no campo metadata.event_type ou metadata.entity_type.

• Evento UDM: armazena dados de uma ação que ocorreu no ambiente. O log de eventos original descreve a ação conforme ela foi gravada 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 única fonte de verdade.

Confira duas representações visuais de alto nível dos modelos de dados de evento e de entidade.

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 "ativo" são os nomes dos campos em que os dados são armazenados.

Figura: modelo de dados de entidade

Estrutura de um evento da UDM

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

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

• extensões

  

  Figura: modelo de dados de eventos

A seção metadados armazena o carimbo de data e 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, um usuário ou um 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 nele.

A seção Rede armazena informações relacionadas à atividade de rede, como comunicação por e-mail e relacionada à 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 sobre e extensões armazenam informações adicionais sobre eventos específicos do fornecedor que não são capturadas pelas outras seções. A seção extensions é um conjunto de pares de chave-valor de formato livre.

Cada evento do UDM armazena valores de um evento de registro bruto original. Dependendo do tipo de evento, alguns atributos são obrigatórios e 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 não houver dados armazenados em uma seção do registro UDM, por exemplo, a seção de extensões, ela não vai aparecer no registro.

Os campos de metadados

Esta seção descreve os campos obrigatórios em um evento da UDM.

O campo "event_timestamp"

Os eventos da UDM precisam incluir dados para 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: RFC 3339 ou carimbo de data/hora Proto3.

Os exemplos a seguir ilustram como especificar a marcação de tempo 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). O deslocamento do 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 da UDM é metadata.event_type. Esse valor identifica o tipo de ação realizada e é independente do fornecedor, do produto ou da plataforma. Exemplos de valores incluem PROCESS_OPEN, FILE_CREATION, USER_CREATION, e NETWORK_DNS. Para conferir a lista completa, consulte o documento Lista de campos da UDM.

O valor metadata.event_type determina quais campos obrigatórios e opcionais adicionais precisam ser incluídos no registro da UDM. Para informações sobre quais campos incluir em cada tipo de evento, consulte o guia de uso da 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 os objetos envolvidos na atividade, conforme registrado no registro bruto original. Pode ser o dispositivo ou usuário que realizou a atividade, o dispositivo ou usuário que é o destino da atividade. Também pode descrever um dispositivo de segurança que observou a atividade, como um proxy de e-mail ou um 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 é afetado.

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

Os campos auxiliares são:

• intermediary: qualquer objeto que atuou 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 scanner de vulnerabilidades ou um dispositivo farejador de pacotes.
• about: quaisquer outros objetos que participaram do 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 ou identificadores específicos do produto, como um GUID da máquina CrowdStrike) ou do usuário (por exemplo, nome de usuário) e, opcionalmente, detalhes do processo. Ela 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 seria 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 Windows em que um 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 principal ator 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.

Em uma injeção de 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 mais informações estiverem disponíveis no registro bruto original, como nome do host, endereços IP e MAC adicionais e identificadores de recursos proprietários, elas também deverão ser incluídas nos campos "Destino" e "Principal".

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

O atributo src

Representa um objeto de origem em que o participante está agindo, junto com o contexto de dispositivo ou processo do objeto de origem (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, o arquivo A e a máquina X serão especificados na parte "src" do evento da UDM.

O atributo intermediário

Representa detalhes sobre um ou mais dispositivos intermediários que processam a atividade descrita no evento. Isso pode incluir detalhes sobre dispositivos como servidores proxy e 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 scanner de vulnerabilidades baseado em rede.

O atributo "about"

Este repositório detalha 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 no corpo do e-mail.
• DLLs carregadas durante um evento PROCESS_LAUNCH.

O atributo security_result

Esta seção contém informações sobre riscos e ameaças à segurança encontrados por um sistema de segurança e as ações tomadas para mitigar esses riscos e ameaças.

Confira 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 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 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 "extensions"

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

Estrutura de uma entidade do UDM

Um registro de entidade da 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 vai armazenar informações sobre um recurso, como estação de trabalho, laptop, smartphone 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 da 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 atributo da entidade armazenam informações sobre a entidade específica, como nome do host e endereço IP se for um recurso, ou windows_sid e endereço de e-mail se for um usuário. O nome do campo é entity, mas o tipo é 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 "relation" armazenam informações sobre outras entidades relacionadas à entidade principal. Por exemplo, se a entidade principal for um usuário e ele tiver recebido um notebook. O laptop é uma entidade relacionada. As informações sobre o notebook 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 do usuário com o laptop, especificamente que o usuário é proprietário do laptop. O campo relation.entity_type armazena o valor ASSET porque o laptop é um dispositivo.

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