Vista geral do modelo de dados unificado

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

O UDM é uma estrutura de dados padrão do Google Security Operations que armazena informações sobre os dados recebidos de origens. Também se denomina esquema. O Google SecOps armazena os dados originais que recebe em dois formatos: o registo não processado original e um registo UDM estruturado. O registo UDM é uma representação estruturada do registo original.

Se existir um analisador para o tipo de registo especificado, o registo não processado é usado para criar um registo de UDM. Os clientes também podem transformar registos não processados no formato UDM estruturado antes de enviar os dados para o Google SecOps através da API de carregamento.

Algumas das vantagens da UDM incluem:

• Armazena o mesmo tipo de registo de diferentes fornecedores usando a mesma semântica.
• É mais fácil identificar relações entre utilizadores, anfitriões e endereços IP, porque os dados são normalizados no esquema UDM padrão.
• É mais fácil escrever regras, uma vez que estas podem ser independentes da plataforma.
• Mais fácil de suportar tipos de registos de novos dispositivos.

Embora possa pesquisar eventos com uma pesquisa de registos não processados, uma pesquisa UDM funciona mais rapidamente e com maior precisão devido à sua especificidade. O Google SecOps recolhe dados de registo não processados e armazena os detalhes do registo de eventos no esquema UDM. A UDM oferece uma estrutura abrangente de milhares de campos para descrever e categorizar diversos tipos de eventos, por exemplo, eventos de processos de pontos finais e eventos de comunicação de rede.

Estrutura da UDM

Os eventos UDM são compostos por várias secções. A primeira secção encontrada em todos os eventos da UDM é a secção de metadados. Fornece uma descrição básica do evento, incluindo a data/hora em que ocorreu e a data/hora em que foi carregado para o Google SecOps. 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 num tipo de evento predefinido, independentemente do registo do produto específico. Com os campos de metadados, pode começar rapidamente a pesquisar os dados.

Além da secção de metadados, outras secções descrevem aspetos adicionais do evento. Se uma secção for desnecessária, não é incluída, o que poupa memória.

• principal: entidade que origina a atividade no evento. Também estão incluídas as secções que fazem referência à origem (src) e ao destino (target).
• intermediary: Sistemas pelos quais os eventos passam, como um servidor proxy ou uma transmissão de SMTP.
• observer: Sistemas como analisadores de pacotes que monitorizam passivamente o tráfego.

Exemplos de pesquisas de UDM

Esta secção apresenta exemplos de pesquisas de UDM que demonstram algumas das sintaxe, funcionalidades e capacidades básicas da pesquisa de UDM.

Exemplo: pesquisar inícios de sessão bem-sucedidos do Microsoft Windows 4624

A seguinte pesquisa lista os eventos de início de sessão bem-sucedidos do Microsoft Windows 4624, juntamente com a data/hora em que os eventos foram gerados, com base apenas em dois campos do UDM:

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

Exemplo: pesquisar todos os inícios de sessão bem-sucedidos

A pesquisa seguinte apresenta todos os eventos de início de sessão com êxito, independentemente do fornecedor ou da aplicação:

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

Exemplo: pesquise inícios de sessão de utilizadores bem-sucedidos

O exemplo seguinte ilustra como pesquisar userid "fkolzig" e determinar quando o utilizador com este ID de utilizador iniciou sessão com êxito. Pode concluir esta pesquisa através da secção de destino. A secção de destino inclui subsecções e campos que descrevem o destino. Por exemplo, o destino neste caso é um utilizador e tem vários atributos associados, mas o destino também pode ser um ficheiro, uma definição de registo 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: pesquise os dados da sua rede

O exemplo seguinte pesquisa dados de rede para eventos RDP com um target.port de 3389 e um principal.ip de 35.235.240.5. Também inclui um campo UDM da secçã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: pesquise um processo específico

Para examinar os processos criados nos seus servidores, procure instâncias do comando net.exe e procure este ficheiro específico no respetivo caminho esperado. O campo que está a pesquisar é target.process.file.full_path. Para esta pesquisa, inclua o comando específico emitido no campo target.process.command_line. Também pode adicionar um campo na secção Acerca de, que é a descrição do código de evento 1 do Microsoft Sysmon (ProcessCreate).

Aqui está a pesquisa da UDM:

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

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

• principal.user.userid: Identificar o utilizador que emite o comando.
• principal.process.file.md5: identificar o hash MD5.
• principal.process.command_line: Linha de comandos.

Exemplo: pesquise inícios de sessão de utilizadores bem-sucedidos associados a um departamento específico

O exemplo seguinte pesquisa inícios de sessão por utilizadores (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 relacionado com eventos de início de sessão do utilizador, continua presente nos dados LDAP carregados acerca dos seus utilizadores.

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

Objetos lógicos: evento e entidade

O esquema de UDM descreve todos os atributos disponíveis que armazenam dados. Cada registo da UDM identifica se descreve um evento ou uma entidade. Os dados são armazenados em campos diferentes consoante o registo descreva um evento ou uma entidade, e também consoante o valor definido no campo metadata.event_type ou metadata.entity_type.

• Evento UDM: armazena dados de uma ação que ocorreu no ambiente. O registo de eventos original descreve a ação tal como foi registada pelo dispositivo, como a firewall e o proxy Web.
• Entidade UDM: representação contextual de elementos como recursos, utilizadores e recursos no seu ambiente. É obtido a partir de uma origem de dados fonte de verdade.

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

Figura: modelo de dados de eventos

Figura: modelo de dados de entidades

Estrutura de um evento de UDM

O evento UDM contém várias secções que armazenam cada uma um subconjunto dos dados para um único registo. As secções são:

• metadados
• capital
• alvo
• src
• observador
• intermediário
• acerca
• rede
• security_result

• extensões

  

  Figura: modelo de dados de eventos

A secção metadata armazena a indicação de tempo, define o event_type e descreve o dispositivo.

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

A secção rede armazena informações relacionadas com a atividade de rede, como comunicação relacionada com a rede e o email.

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

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

As secções about e extensions armazenam informações adicionais de eventos específicos do fornecedor que não são captadas pelas outras secções. A secção extensions é um conjunto de pares de chave-valor de forma livre.

Cada evento do UDM armazena valores de um evento de registo não processado original. Consoante o tipo de evento, determinados atributos são obrigatórios, enquanto outros são opcionais. Os atributos obrigatórios versus opcionais são determinados pelo valor metadata.event_type. O Google SecOps lê metadata.event_type e realiza a validação de campos específica desse tipo de evento após a receção dos registos.

Se não forem armazenados dados numa secção do registo do UDM, por exemplo, a secção de extensões, essa secção não é apresentada no registo do UDM.

Os campos de metadados

Esta secção descreve os campos obrigatórios num evento UDM.

O campo event_timestamp

Os eventos da UDM têm de incluir dados para o elemento metadata.event_timestamp, que é a data/hora em GMT em que o evento ocorreu. O valor tem de ser codificado através de um dos seguintes padrões: RFC 3339 ou data/hora Proto3.

Os exemplos seguintes ilustram como especificar a data/hora através do formato RFC 3339, yyyy-mm-ddThh:mm:ss+hh:mm (ano, mês, dia, hora, minuto, segundo e o desvio em relação à hora UTC). A diferença para UTC é de menos 8 horas, o que indica PST.

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

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

Também pode especificar o valor através do formato de época.

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

O campo event_type

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

O valor metadata.event_type determina que campos adicionais obrigatórios e opcionais têm de ser incluídos no registo UDM. Para informações sobre os campos a incluir para cada tipo de evento, consulte o guia de utilização da UDM.

Os atributos principal, alvo, src, intermediário, observador e acerca de

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 registado no registo não processado original. Pode ser o dispositivo ou o utilizador que realizou a atividade, o dispositivo ou o utilizador que é o destino da atividade. Também pode descrever um dispositivo de segurança que observou a atividade, como um proxy de email ou um router 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 sobre o qual se atua.

Cada tipo de evento requer que, pelo menos, um destes campos contenha dados.

Os campos auxiliares são:

• intermediary: qualquer objeto que atuou como intermediário no evento. Isto pode incluir objetos como servidores proxy e servidores de correio.
• observer: qualquer objeto que não interaja diretamente com o tráfego em questão. Pode ser um scanner de vulnerabilidades ou um dispositivo de monitorizaçã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 tem de incluir, pelo menos, um detalhe da máquina (nome do anfitrião, endereço MAC, endereço IP, identificadores específicos do produto, como um GUID da máquina CrowdStrike) ou um detalhe do utilizador (por exemplo, o nome do utilizador) e, opcionalmente, incluir detalhes do processo. Não pode incluir nenhum dos seguintes campos: email, ficheiros, chaves ou valores de registo.

Se o evento ocorrer numa única máquina, essa máquina é descrita apenas no atributo principal. Não é necessário descrever a máquina nos atributos target ou src.

O seguinte fragmento de JSON 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" }
}

Este atributo descreve tudo o que se sabe sobre o dispositivo e o utilizador que foi o ator principal no evento. Este exemplo inclui o endereço IP do dispositivo, o número da porta e o nome do anfitrião. 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, numa ligação de firewall do dispositivo A para o dispositivo B, o dispositivo A é captado como o principal e o dispositivo B é captado 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: capital principal versus objetivo

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

target {
   ip: "192.0.2.31"
   port: 80
}

Se estiverem disponíveis mais informações no registo não processado original, como o nome do anfitrião, endereços IP adicionais, endereços MAC e identificadores de recursos proprietários, estas também devem ser incluídas nos campos de 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 (alvo) também na máquina X.

O atributo src

Representa um objeto de origem sobre o qual o participante está a agir, juntamente com o contexto do dispositivo ou do processo para o objeto de origem (a máquina onde o objeto de origem reside). Por exemplo, se o utilizador U copiar o ficheiro A na máquina X para o ficheiro B na máquina Y, o ficheiro A e a máquina X seriam especificados na parte src do evento UDM.

O atributo intermediário

Representa detalhes sobre um ou mais dispositivos intermédios que processam a atividade descrita no evento. Isto pode incluir detalhes do dispositivo sobre dispositivos como servidores proxy e servidores de retransmissão SMTP.

O atributo observer

Representa um dispositivo observador que não é um intermediário direto, mas que observa e comunica o evento em questão. Isto pode incluir um analisador de pacotes ou um verificador de vulnerabilidades baseado na rede.

O atributo about

Esta armazena detalhes sobre um objeto referenciado pelo evento que não está descrito nos campos principal, src, destino, intermediário ou observador. Por exemplo, pode captar o seguinte:

• Anexar ficheiros a emails.
• Domínios, URLs ou endereços IP incorporados no corpo de um email.
• DLLs que são carregadas durante um evento PROCESS_LAUNCH.

O atributo security_result

Esta secção contém informações sobre riscos e ameaças de segurança detetados por um sistema de segurança, bem como as ações realizadas para mitigar esses riscos e ameaças.

Seguem-se os tipos de informações que seriam armazenadas no atributo security_result:

• Um proxy de segurança de email detetou uma tentativa de phishing (security_result.category = MAIL_PHISHING) e bloqueou (security_result.action = BLOCK) o email.
• Uma firewall de proxy de segurança de email detetou dois anexos infetados (security_result.category = SOFTWARE_MALICIOUS), colocou-os em quarentena e desinfetou-os (security_result.action = QUARANTINE or security_result.action = ALLOW_WITH_MODIFICATION). Em seguida, encaminhou o email desinfetado.
• Um sistema de SSO permite um início de sessão (security_result.category = AUTH_VIOLATION) que foi bloqueado (security_result.action = BLOCK).
• Um sandbox de software malicioso detetou spyware (security_result.category = SOFTWARE_MALICIOUS) num anexo de ficheiro cinco minutos após o ficheiro ter sido entregue (security_result.action = ALLOW) ao utilizador na respetiva caixa de entrada.

O atributo de rede

Os atributos de rede armazenam dados sobre eventos relacionados com a rede e detalhes sobre protocolos em submensagens. Isto inclui atividade, como emails enviados e recebidos, e pedidos HTTP.

O atributo de extensões

Os campos deste atributo armazenam metadados adicionais sobre o evento capturado no registo não processado original. Pode conter informações sobre vulnerabilidades ou informações adicionais relacionadas com a autenticação.

Estrutura de uma entidade UDM

Um registo de entidade do UDM armazena informações sobre qualquer entidade numa organização. Se o metadata.entity_type for USER, o registo armazena informações sobre o utilizador no atributo entity.user. Se o metadata.entity_type for ASSET, o registo armazena informações sobre um recurso, como uma estação de trabalho, um portátil, um telemóvel e uma máquina virtual.

Figura: modelo de dados de eventos

Os campos de metadados

Esta secção contém campos obrigatórios numa entidade UDM, como:

• collection_timestamp: a data e a hora em que o registo foi recolhido.
• entity_type: o tipo de entidade, como recurso, utilizador e recurso.

O atributo da entidade

Os campos no atributo da entidade armazenam informações sobre a entidade específica, como o nome do anfitrião e o endereço IP, se for um recurso, ou o windows_sid e o endereço de email, se for um utilizador. Tenha em atenção que o nome do campo é entity, mas o tipo de campo é um substantivo. Um substantivo é uma estrutura de dados usada frequentemente que armazena informações em entidades e eventos.

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

O atributo de relação

Os campos no atributo de relação armazenam informações sobre outras entidades às quais a entidade principal está relacionada. Por exemplo, se a entidade principal for um utilizador e tiver sido emitido um portátil para o utilizador. O portátil é uma entidade relacionada. As informações sobre o portátil são armazenadas como um registo entity com um metadata.entity_type = ASSET. As informações sobre o utilizador são armazenadas como um registo entity com metadata.entity_type = USER.

O registo da entidade do utilizador também capta a relação entre o utilizador e o portátil, através de campos no atributo relation. O campo relation.relationship armazena a relação que o utilizador tem com o portátil, especificamente que o utilizador é proprietário do portátil. O campo relation.entity_type armazena o valor ASSET, porque o portátil é um dispositivo.

Os campos no elemento relations.entity armazenam informações sobre o portátil, como o nome do anfitrião e o endereço MAC. Repare novamente que o nome do campo é entity e o tipo de campo é um substantivo. Um substantivo é uma estrutura de dados usada frequentemente. Os campos no atributo relation.entity armazenam informações sobre o portátil.

O campo relation.direction armazena a direcionalidade da relação entre o utilizador e o portátil, especificamente se a relação é bidirecional ou unidirecional.

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