Visão geral do Modelo de dados unificado

Este documento contém uma visão geral do Modelo de dados unificado (UDM, na sigla em inglês). Para mais detalhes sobre os campos de UDM, incluindo uma descrição de cada um, consulte a lista de campos de UDM. Para saber mais sobre o mapeamento do analisador, consulte Campos importantes do UDM para o mapeamento do analisador.

O UDM é uma estrutura de dados padrão das Operações de segurança do Google que armazena informações sobre dados recebidos de fontes. Ele também é chamado de esquema. O Google Security Operations armazena os dados originais recebidos em dois formatos, como o registro bruto original e como um registro UDM estruturado. O registro 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 UDM. Os clientes também podem transformar registros brutos em um formato UDM estruturado antes de enviar os dados para as operações de segurança do Google 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 de identificar relações entre usuários, hosts e endereços IP porque os dados são normalizados no esquema UDM padrão.
• Regras mais fáceis de escrever porque podem ser independentes de plataforma.
• Suporte a tipos de registro de novos dispositivos mais fácil.

Observação: o mecanismo de regras do Google Security Operations 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 bruta, uma pesquisa UDM funciona com mais rapidez e precisão devido à sua especificidade.

As Operações de segurança do Google usam o esquema UDM para todos os eventos coletados. O UDM inclui milhares de campos usados para descrever e categorizar eventos. Por exemplo, o UDM pode lidar com eventos de processos de endpoint tão facilmente quanto eventos de comunicação de rede.

Estrutura do UDM

Os eventos de UDM são compostos de várias seções. A primeira seção encontrada em cada evento de UDM é a seção de metadados. Ela fornece uma descrição básica do evento, incluindo o carimbo de data/hora de quando o evento ocorreu e o de quando ele foi ingerido nas operações de segurança do Google. 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, independentemente do registro de produto específico. Com os campos de metadados sozinhos, 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 por onde 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 de UDM

Esta seção fornece exemplos de pesquisas do UDM que demonstram algumas das sintaxes, recursos e funções básicos da pesquisa do UDM.

Exemplo: pesquisa de logins bem-sucedidos do Microsoft Windows 4624

A pesquisa a seguir lista os eventos de login bem-sucedido do Microsoft Windows 4624 e quando eles 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

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

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

Exemplo: pesquisa de 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. É possível 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 seus dados de rede

O exemplo a seguir pesquisa dados de rede em busca de eventos 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 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 target.process.command_line

da segurança cibernética na nuvem. Também é possível adicionar um campo na seção "Sobre", que é a descrição do código de evento Sysmon 1 (ProcessCreate) do Microsoft.

Esta é a pesquisa do UDM:

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

Também é possível adicionar os seguintes campos de pesquisa do UDM:

• principal.user.userid: identifica 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ário bem-sucedidos associados a um departamento específico

O exemplo a seguir pesquisa logins pelos 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 a eventos de login de usuário, ele ainda está presente nos dados LDAP ingeridos sobre os usuários.

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

Objetos lógicos: evento e entidade

O esquema 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 qual valor é 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 conforme ela foi gravada pelo dispositivo, como firewall e proxy da Web. Esse é o modelo de dados de eventos de UDM.
• Entidade UDM: representação contextual de elementos como recursos, usuários e recursos no seu ambiente. Eles vêm de uma fonte de dados de fonte de verdade. Esse é o modelo de dados de entidade do UDM.

Aqui estão duas representações visuais de alto nível do modelo de dados de evento e do modelo de dados de entidade.

Figura: modelo de dados de eventos

Observação: o termo Noun descreve o tipo de atributo. Os termos principal, destino, src, intermediário, observador e sobre são os nomes de campos em que os dados são armazenados.

Figura: modelo de dados da entidade

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

Estrutura de um evento de UDM

O evento de UDM contém várias seções, cada uma armazenando um subconjunto dos dados para um único registro. As seções são:

• metadados
• participante
• destino
• src
• observador
• intermediário
• about
• 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 pelo papel que cada objeto desempenha no evento.

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

• Dados de e-mail: informações em 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 produto antivírus.

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

Cada evento de 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 versus opcionais são determinados pelo valor metadata.event_type. As Operações de segurança do Google lêem metadata.event_type e realizam a validação de campo específica para esse tipo de evento depois que os registros são recebidos.

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

Campos de metadados

Esta seção descreve 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 a diferença do horário UTC). A diferença do UTC é de menos oito 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 de UDM é metadata.event_type. Esse valor identifica o tipo de ação realizada e não depende 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 do UDM.

O valor metadata.event_type determina quais campos extras obrigatórios e opcionais precisam ser incluídos no registro UDM. Para informações sobre quais campos incluir para cada tipo de evento, consulte o Guia de uso do UDM.

Os atributos principal, target, src, intermediário, observador e "Sobre"

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 o registro bruto original. Pode ser o dispositivo ou usuário que executou a atividade ou o dispositivo ou usuário alvo da atividade. 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 são:

• principal: objeto que executou a atividade.
• src: objeto que inicia a atividade, se for diferente do principal.
• target: objeto que recebe ações.

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 servidores de e-mail.
• observer: qualquer objeto que não interaja diretamente com o tráfego em questão. Ele pode ser um verificador de vulnerabilidades ou um dispositivo sniffer de pacotes.
• about: todos os outros objetos que tiveram um papel no evento e são opcionais.

Os atributos principais

Representa a entidade que atua 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 da máquina CrowdStrike) ou detalhes do usuário (por exemplo, nome do usuário). Como opção, é possível incluir detalhes do processo. Ele não pode incluir nenhum destes 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 de destino ou src.

Observação: um dispositivo de segurança pode gravar um evento, mas ele não é descrito no atributo principal. É descrito no atributo do 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 é conhecido sobre o dispositivo e o usuário que foi o ator principal no evento. Esse 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 recursos 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 principal, e o dispositivo B como destino.

No caso de 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 meta

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 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 com o 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, tanto o arquivo A quanto a máquina X serão especificados na parte src do evento UDM.

O atributo intermediário

Representa os detalhes sobre a atividade de processamento de um ou mais dispositivos intermediários descritas no evento. Isso pode incluir detalhes do dispositivo sobre dispositivos como servidores proxy e servidores de redirecionamento SMTP.

O atributo do observador

Representa um dispositivo observador que não é um intermediário direto, mas que observa e relata o evento em questão. como um sniffer de pacote ou um verificador de vulnerabilidades baseado em rede.

O atributo "about"

Esse armazenamento contém detalhes sobre um objeto referenciado pelo evento que não está descrito nos campos principal, src, target, intermediário ou observador. Por exemplo, ela 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 riscos e ameaças de segurança encontrados por um sistema de segurança e as ações tomadas para mitigar esses riscos e ameaças.

Veja 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).
• Um firewall de proxy de segurança de e-mail detectou dois anexos infectados (security_result.category = SOFTWARE_MALICIOUS) e os colocou em quarentena e desinfetados (security_result.action = QUARANTINE ou security_result.action = ALLOW_WITH_MODIFICATION) desses anexos. Em seguida, encaminhou o e-mail desinfetado.
• Um sistema 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) para o usuário na caixa de entrada dele.

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 "extensões"

Os campos sob esse 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 de UDM

Um registro de entidade do UDM armazena informações sobre qualquer entidade dentro de uma organização. Se o metadata.entity_type for USER, o registro 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, smartphone e máquina virtual.

Figura: modelo de dados de eventos

Campos de metadados

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

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

Atributo de entidade

Os campos sob o atributo de 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. Observe que o nome do campo é "entity", mas o tipo do campo é um substantivo. 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 metadata.entity_type for ASSET, os dados serão armazenados no atributo "entity.asset".

O atributo de relação

Os campos sob o atributo de relação armazenam informações sobre outras entidades a que a entidade principal está relacionada. 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 de "entity" com um metadata.entity_type = ASSET. As informações sobre o usuário são armazenadas como um registro de "entidade" com o formato 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 relacional.relacionamento armazena a relação que o usuário tem com o laptop, especificamente que o usuário é o proprietário do laptop. O campo relacional.entity_type armazena o valor RECURSO porque o laptop é um dispositivo.

Os campos sob o atributo relacionals.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 sob o atributo relacional.entity armazenam informações sobre o laptop.

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