Visão geral do modelo de dados unificado

Compatível com:

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.

O 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.

Alguns dos benefícios da 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 fácil oferecer suporte a tipos de registros de novos dispositivos.

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 registro 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, a versão e a descrição do produto. 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 onde 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.

Exemplos de pesquisas do UDM

Esta seção fornece exemplos de pesquisas UDM que demonstram algumas das sintaxes, recursos e funcionalidades básicos 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ário 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 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", que é a descrição do código de evento 1 do Microsoft Sysmon (ProcessCreate).

Esta é a pesquisa do 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 registro 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.

Modelo de dados de eventos

Figura: modelo de dados de eventos

Modelo de dados de entidade

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

    Modelo de dados de eventos

    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 e-mails e comunicações relacionadas à 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: 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). 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 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 um roteador de rede.

Os atributos mais usados 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 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 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, 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".

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 D de destino, o processo C é o principal e o processo D é o destino.

principal x 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 "target" 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 na rede.

O atributo "about"

Essa loja 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 de um 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 da 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.

Modelo de dados de entidade

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 da 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 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 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 notebook, especificamente que o usuário é proprietário do notebook. 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 notebook.

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.