Formatar dados de registro como UDM

Compatível com:

Campos comuns de eventos da UDM

Todos os eventos do Modelo de dados unificado (UDM) têm um conjunto de campos e mensagens comuns que os parceiros podem preencher, independente do tipo de evento. Esses campos incluem o seguinte:

  • Entidades: dispositivos, usuários e processos envolvidos em um evento.
  • Metadados do evento: quando o evento ocorreu, o tipo dele, de onde ele veio etc.
  • Metadados de rede: metadados de rede de alto nível para eventos orientados à rede, além de detalhes do protocolo em submensagens:
    • Metadados de e-mail: informações nos campos "Para", "De", "Cc", "Cco" e outros campos de e-mail.
    • Metadados HTTP: método, referral_url, useragent etc.
  • Resultados de segurança: qualquer classificação ou ação feita por um produto de segurança.
  • Metadados adicionais: todos os dados de eventos importantes específicos do fornecedor que não podem ser representados adequadamente nas seções formais do modelo UDM podem ser adicionados usando um campo de payload JSON de formato livre.

As seções a seguir descrevem como codificar e formatar eventos para a UDM.

Codificação da UDM

Os eventos da UDM precisam ser enviados ao Google Security Operations usando um dos seguintes formatos:

Para os fins deste documento, os campos são representados usando uma notação de ponto. Por exemplo, a seguinte sintaxe JSON:

{"menu":
  {
    "id": "file",
    "value": "File",
    "popup": {
      "menuitem": [
        {"value": "New", "onclick": "CreateNewDoc()"}
      ]
    }
  }
}

É documentado da seguinte forma:

menu.id = "file"
menu.value = "File"
menu.popup.menuitem.value = "New"
menu.popup.menuitem.onclick = "CreateNewDoc()"

Como formatar um evento da 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: 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. Especifique o resultado de segurança: (opcional) inclua detalhes sobre riscos e ameaças à segurança encontrados por um sistema de segurança, bem como as ações tomadas para reduzir 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)

Para cada evento da UDM, é necessário definir um ou mais substantivos. Um substantivo representa um participante ou uma entidade em um evento da UDM. Um substantivo pode ser, por exemplo, o dispositivo/usuário que realiza a atividade descrita em um evento ou o dispositivo/usuário que é o destino dessa atividade descrita no evento. Substantivos também podem ser anexos ou URLs. Por fim, um substantivo também pode ser usado para descrever um dispositivo de segurança que observou a atividade descrita no evento (por exemplo, um proxy de e-mail ou um roteador de rede).

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. Ele NÃO pode incluir nenhum dos seguintes campos: e-mail, arquivos, chaves ou valores de registro.

Se todos os eventos estiverem ocorrendo na mesma máquina, ela só precisará ser descrita em principal. A máquina não precisa ser descrita em target ou src.

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 inclui o endereço IP, o número da porta e o nome do host do dispositivo, além de um identificador de recurso específico do fornecedor (da Sophos), que é um ID exclusivo gerado pelo produto de segurança de terceiros.

target: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, A é descrito como o principal e B é descrito como o destino. Em uma injeção de processo pelo processo C no processo de destino D, o processo C é descrito como o principal e o processo D é descrito como o destino.

principal x target no udm

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
}

Se houver mais informações disponíveis, como nome do host, endereços IP adicionais, endereços MAC, identificadores de ativos proprietários etc., elas também deverão ser incluídas em target.

O principal e o destino (assim como outros substantivos) podem se referir a atores na mesma máquina. Por exemplo, o processo A (principal) executado na máquina X age no processo B (destino) também na máquina X.

  • src:representa um objeto de origem que está sendo manipulado pelo participante, além do 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.
  • intermediary:representa detalhes sobre um ou mais dispositivos intermediários que processam a atividade descrita no evento. Isso inclui detalhes do dispositivo sobre um servidor proxy, um servidor de redirecionamento SMTP etc.
  • observer:representa um dispositivo observador (por exemplo, um sniffer de pacotes ou um scanner de vulnerabilidades baseado em rede), que não é um intermediário direto, mas observa e informa sobre o evento em questão.
  • about:usado para armazenar detalhes sobre todos os objetos referenciados pelo evento que não são descritos em participant, src, target, intermediary ou observer. Por exemplo, ele pode ser usado para rastrear o seguinte:
    • Anexos de arquivos de e-mail
    • Domínios/URLs/IPs incorporados no corpo de um 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 proxy de segurança de e-mail detectou uma tentativa de phishing (MAIL_PHISHING) e bloqueou (BLOCK) o e-mail.
  • Um firewall proxy de segurança de e-mail detectou dois anexos infectados (SOFTWARE_MALICIOUS), colocou em quarentena e desinfectou (QUARANTINE, ALLOW_WITH_MODIFICATION) esses anexos e encaminhou o e-mail desinfectado.
  • Um sistema de SSO facilitou um login (AUTH_VIOLATION) que foi bloqueado (BLOCK).
  • Um sandbox de malware detectou spyware (SOFTWARE_MALICIOUS) em um anexo de arquivo cinco minutos depois que o arquivo foi entregue (ALLOW) ao usuário na Caixa de entrada.

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