Formatar dados de registro como UDM

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

• Entidades: os dispositivos, usuários e processos envolvidos em um evento.
• Metadados do evento: mostra quando o evento ocorreu, o tipo, a origem dele etc.
• Metadados de rede: metadados de rede de alto nível para eventos orientados por rede, além de detalhes de protocolo em submensagens:
  • Metadados do e-mail: informações nos campos "Para", "De", "Cc", "Cco" e outros campos do e-mail.
  • Metadados HTTP: Método, reference_url, useragent etc.
• Resultados de segurança: qualquer classificação ou ação realizada por um produto de segurança.
• Metadados adicionais: todos os dados de eventos importantes específicos do fornecedor que não puderem 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 o Modelo de dados unificado (UDM, na sigla em inglês).

Codificação UDM

Os eventos de UDM precisam ser enviados às Operações de segurança do Google usando um dos seguintes formatos:

• JSON (https://developers.google.com/protocol-buffers/docs/proto3#json)
• Proto3

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()"

Formatar um evento de UDM

Para formatar um evento de UDM e preparar o envio para o Google, siga estas etapas:

1. Especificar o tipo de evento: o tipo de evento selecionado determina quais campos também precisam ser incluídos no evento.
2. Especificar o carimbo de data/hora do evento: especifique o carimbo de data/hora do evento.
3. Especificar substantivos (entidades): cada evento precisa incluir pelo menos um substantivo que descreva o dispositivo ou usuário do participante envolvido no evento.
4. Especificar o resultado da segurança: (opcional) especifique os resultados de segurança incluindo detalhes sobre riscos de segurança e ameaças encontradas por um sistema de segurança, bem como as ações tomadas para mitigá-los.
5. Preencha o restante das informações obrigatórias e opcionais do evento nos 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 acessar a lista completa, consulte Metadata.event_type. Cada tipo de evento exige que você também 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 de UDM para saber detalhes sobre 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
}

Especificação do carimbo de data/hora do evento

É preciso 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. Para este exemplo, aaaa-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"
}

Como especificar substantivos (entidades)

Para cada evento de UDM, você precisa definir um ou mais substantivos. Um substantivo representa um participante ou uma entidade em um evento de UDM. Um substantivo pode ser, por exemplo, o dispositivo/usuário que realiza a atividade descrita em um evento ou o dispositivo/usuário alvo da atividade descrita no evento. Substantivos também podem ser coisas como 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 roteador de rede).

Um evento de UDM precisa ter um ou mais dos seguintes substantivos especificados:

principal: representa a entidade que atua 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 do CrowdStrike) ou detalhes do usuário (por exemplo, nome do usuário). Também é possível incluir detalhes do processo. NÃO pode incluir nenhum destes campos: e-mail, arquivos, chaves ou valores de registro.

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

Observação: um dispositivo de segurança pode originar um evento, mas não estaria descrito no campo "principal", mas sim nos campos 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 do Windows em que o malware foi detectado), esse dispositivo também será o principal.

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" }
}

O exemplo acima descreve tudo o que é conhecido sobre o dispositivo e o usuário que foi o principal ator descrito no evento. Esse exemplo inclui o endereço IP e o número da porta do dispositivo, além do nome do host. Ele também inclui um identificador de ativos específico do fornecedor (da Sophos), que é um identificador 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 com o dispositivo B, A é descrita como principal e B como 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 destino no UDM

O exemplo a seguir ilustra como os campos de uma segmentação são preenchidos:

target {
   ip: "198.51.100.31"
   port: 80
}

Novamente, se mais informações estiverem disponíveis, como nome do host, endereços IP adicionais, endereços MAC, identificadores de recursos reservados etc., elas também deverão ser incluídas em target.

Tanto principal quanto target (assim como outros substantivos) podem fazer referência a atores na mesma máquina. Por exemplo, o processo A (principal) executado na máquina X atua no processo B (destino) também na máquina X.

• src: representa um objeto de origem em que o participante atua, bem como o contexto do dispositivo ou 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.
• intermediário:representa detalhes sobre a atividade de processamento de um ou mais dispositivos intermediários descrita no evento. Isso inclui detalhes do dispositivo sobre um servidor proxy, servidor de redirecionamento SMTP, etc.
• observador:representa um dispositivo observador (por exemplo, um sniffer de pacote ou verificação de vulnerabilidades baseada em rede), que não é um intermediário direto, mas que observa e relata o evento em questão.
• about: usado para armazenar detalhes em todos os objetos referenciados pelo evento que não são descritos de outra forma em participant, src, target, intermediário ou observer. Por exemplo, ele pode ser usado para rastrear o seguinte:
  • Anexos de arquivos por 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 de UDM incluem informações sobre os vários participantes (dispositivos, usuários, objetos como URLs, arquivos etc.) descritos no evento. O UDM das Operações de segurança do Google tem requisitos obrigatórios para preencher campos de substantivos. Esses requisitos estão descritos nos Campos obrigatórios e opcionais para cada tipo de evento de UDM. O conjunto de campos de entidade que precisam ser preenchidos varia de acordo com o tipo de evento.

Como especificar o resultado de segurança

Você também pode especificar resultados de segurança preenchendo os campos SecurityResult, incluindo detalhes sobre riscos de segurança e ameaças encontradas pelo sistema de segurança, bem como as ações tomadas para mitigar esses riscos e ameaças. Veja a seguir exemplos de alguns dos tipos de ocorrências de segurança que exigem o preenchimento de campos SecurityResult:

• Um proxy de segurança de e-mail detectou uma tentativa de phishing (MAIL_PHISHING) e bloqueou (BLOQUEAR) o e-mail.
• Um firewall de proxy de segurança de e-mail detectou dois anexos infectados (SOFTWARE_MALICIOUS) e os colocou em quarentena e desinfetados (QUARANTINE, ALLOW_WITH_MODIFICATION) desses anexos, depois encaminhou o e-mail desinfetado.
• Um sistema SSO facilitou um login (AUTH_VIOLATION) que foi bloqueado (BLOCK).
• Uma sandbox para malware detectou spyware (SOFTWARE_MALICIOUS) em um anexo de arquivo cinco minutos depois que o arquivo foi entregue (ALLOW) para o usuário em sua caixa de entrada.