Visão geral do modelo de dados unificado

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 do UDM, incluindo uma descrição de cada um, consulte a lista de campos do UDM. Para mais informações sobre o mapeamento de analisador, consulte Campos importantes de UDM para o mapeamento de analisador.

O UDM é uma estrutura de dados padrão do Google Security Operations que armazena informações sobre os dados recebidos das fontes. Também é chamado de esquema. As operações de segurança do Google armazenam os dados originais recebidos em dois formatos: como o registro bruto original e como um registro estruturado do UDM. O registro do 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 UDM. Os clientes também podem transformar registros brutos no formato estruturado do UDM antes de enviar os dados para o Google Security Operations usando a API Ingestion.

Alguns dos benefícios do UDM incluem:

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

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

Embora seja possível pesquisar eventos com uma pesquisa de registro bruto, uma pesquisa UDM funciona mais rápido e com mais precisão devido à especificidade.

As operações de segurança do Google usam o esquema do UDM para todos os eventos coletados. O UDM inclui milhares de campos usados para descrever e categorizar eventos. Por exemplo, o UDM pode processar eventos de processo de endpoint com a mesma facilidade que 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 em que o evento ocorreu e o carimbo de data/hora em que ele foi ingerido nas operações de segurança do Google. Ele também inclui as informações, a versão e a descrição do produto. O analisador de transferência classifica cada evento com base em um tipo de evento predefinido, independentemente do registro de produto específico. Com os campos de metadados, você pode 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, economizando memória.

• principal: entidade que origina a atividade no evento. Seções que fazem referência à origem (src) e ao destino (target) também sã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.

Exemplos de pesquisas do UDM

Esta seção apresenta exemplos de pesquisas UDM que demonstram alguns dos recursos, recursos e sintaxe básicos da pesquisa 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 da 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 nesse 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 procura "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 de RDP com um target.port de 3389 e um principal.ip de 35.235.240.5. Ele também inclui um campo de 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 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 do Microsoft Sysmon 1 (ProcessCreate).

Esta é a pesquisa do UDM:

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

Opcionalmente, adicione os seguintes campos de pesquisa do UDM:

• principal.user.userid: identifica o usuário que emitiu o comando.
• principal.process.file.md5: identificar 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 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 do 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 é definido no campo metadata.event_type ou metadata.entity_type.

• Evento do UDM: armazena dados de uma ação que ocorreu no ambiente. O registro de eventos original descreve a ação conforme foi gravada pelo dispositivo, como firewall e proxy da Web. Este é o modelo de dados de eventos do UDM.
• Entidade do UDM: representação contextual de elementos, como recursos, usuários e recursos no seu ambiente. Ele é extraído de uma fonte de dados da verdade. Este é o modelo de dados da entidade UDM.

Confira 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

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

Figura: modelo de dados de entidade

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

Estrutura de um evento do UDM

O evento 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/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 pelo papel que cada objeto desempenha nele.

A seção rede armazena informações relacionadas à atividade de rede, como e-mail e comunicação 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 outras informações de evento específicas 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 da 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 Security Operations 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 nenhuma informação for armazenada em uma seção do registro do UDM, por exemplo, a seção de extensões, essa seção não vai aparecer no registro do UDM.

Os campos de metadados

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

O campo event_timestamp

Os eventos do UDM precisam incluir dados para o metadata.event_timestamp, que é o carimbo de data/hora GMT 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 em relação ao horário UTC). O deslocamento em relação ao UTC é de menos 8 horas, o que indica o 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, produto ou plataforma. Os 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 precisam ser incluídos no registro do UDM. Para saber quais campos incluir em cada tipo de evento, consulte o guia de uso da UDMM.

Os atributos principal, de destino, src, intermediário, 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 o usuário que realizou a atividade, o dispositivo ou o usuário que é o alvo 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 recebe ação.

Em cada tipo de evento, pelo menos um desses campos precisa ter 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 vulnerabilidade ou um dispositivo sniffer de pacotes.
• about: qualquer outro objeto que tenha desempenhado um papel no evento e seja opcional.

Os principais atributos

Representa a entidade que está agindo ou o dispositivo que originou a atividade. O princípio precisa incluir pelo menos um detalhe de máquina (nome de host, endereço MAC, endereço IP, identificadores específicos do produto, como um GUID de máquina do CrowdStrike) ou de 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 de registro ou valores.

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. Ela seria descrita no atributo de observador ou intermediário. Se o software de segurança (por exemplo, o Carbon Black) for executado no mesmo dispositivo que originou a atividade (por exemplo, um endpoint Windows em que o malware foi detectado), o dispositivo Windows será o principal.

O snippet de 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, do 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 alvo.

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 versus 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 adicionais, endereços MAC e identificadores de recursos reservados, elas também precisarão ser incluídas nos campos de destino e principal.

O principal e o alvo 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 que está sendo acessado pelo participante com o contexto de dispositivo ou processo do 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 de redirecionamento SMTP.

O atributo observer

Representa um dispositivo de 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 vulnerabilidade baseado em rede.

O atributo "about"

Armazena detalhes sobre um objeto referenciado pelo evento que não é descrito nos campos principal, src, target, intermediário ou observador. 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 que são carregadas durante um evento PROCESS_LAUNCH.

O atributo security_result

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

Confira os 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 proxy de firewall de segurança de e-mail detectou dois anexos infectados (security_result.category = SOFTWARE_MALICIOUS) e os colocou em quarentena e desinfetou (security_result.action = QUARANTINE ou security_result.action = ALLOW_WITH_MODIFICATION) esses anexos e, em seguida, encaminhou o e-mail descontaminado.
• 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 enviado (security_result.action = ALLOW) para o 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 outras informações relacionadas à autenticação.

Estrutura de uma entidade do UDM

Um registro de entidade do 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 armazena 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 do 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 do atributo da entidade armazenam informações sobre a entidade específica, como nome de 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 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 do atributo de relação armazenam informações sobre outras entidades relacionadas à entidade principal. Por exemplo, se a entidade principal for um usuário e o usuário tiver recebido um laptop. O laptop é uma entidade relacionada. As informações sobre o laptop são armazenadas como um registro de "entidade" com um metadata.entity_type = ASSET. As informações sobre o usuário são armazenadas como um registro de "entidade" com metadata.entity_type = USER.

O registro de 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 laptop é um dispositivo.

Os campos do 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 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.