Formatar dados de registro como UDM

Compatível com:

Google SecOps SIEM

Todos os eventos do Modelo de dados unificado (UDM) 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: dispositivos, usuários e processos envolvidos em um evento.
• Metadados do evento: quando o evento ocorreu, o tipo de evento, de onde ele veio etc.
• Metadados de rede: metadados de rede de alto nível para eventos orientados a rede, além de detalhes de protocolo em submensagens:
  • Metadados do e-mail: informações nos campos para, de, cc, bcc e outros.
  • 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.
• Outros metadados: qualquer dado de evento importante específico do fornecedor que não possa ser representado adequadamente nas seções formais do modelo UDM pode ser adicionado 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).

Codificação de UDM

Os eventos do UDM precisam ser enviados ao Google Security Operations em 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()"}
      ]
    }
  }
}

Está documentado da seguinte maneira:

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

Como formatar um evento do UDM

Para formatar um evento do UDM e enviar ao Google, siga estas etapas:

1. Especificação do tipo de evento: o tipo de evento selecionado determina quais campos você também precisa incluir no evento.
2. Como especificar o carimbo de data/hora do evento: especifique o carimbo de data/hora do evento.
3. Especificação de substantivos (entidades): cada evento precisa incluir pelo menos um substantivo que descreva um dispositivo ou usuário participante envolvido no evento.
4. Especificação do resultado de segurança: (opcional) especifique os resultados de segurança incluindo detalhes sobre os riscos e ameaças de segurança encontrados 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 usando os campos de evento do UDM.

Como 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. Eles incluem valores como PROCESS_OPEN, FILE_CREATION, USER_CREATION, NETWORK_DNS etc. Para conferir a lista completa, consulte Metadata.event_type. Cada tipo de evento também 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 do 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
}

Como 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 selo 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: ano, mês, dia, hora, minuto, segundo e a diferença em relação ao horário UTC. O deslocamento em relação ao UTC é de menos 8 horas, indicando o PST.

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

Como especificar substantivos (entidades)

Para cada evento do UDM, é necessário definir um ou mais substantivos. Um substantivo representa um participante ou uma entidade em um evento do 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 alvo dessa atividade descrita no evento. Os 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 roteador de rede).

Um evento do 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 do usuário (por exemplo, nome do usuário) e, opcionalmente, detalhes do processo. Ele NÃO deve incluir nenhum dos seguintes campos: e-mail, arquivos, chaves de registro ou valores.

Se todos os eventos ocorrerem na mesma máquina, ela 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 ele não será descrito no campo principal. Ele será descrito 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 sabemos sobre o dispositivo e o usuário que foi o principal ator descrito no evento. Este 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 recursos específico do fornecedor (do 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 para o dispositivo B, A é descrito como o principal e B é descrito como o alvo. Para 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.

Princípio versus destino no UDM

O exemplo a seguir ilustra como os campos de uma meta 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 ativos reservados etc., elas também precisarão ser incluídas no alvo.

Tanto principal quanto alvo (assim como outros substantivos) podem referenciar atores na mesma máquina. Por exemplo, o processo A (principal) em execução na máquina X atua no processo B (alvo) também na máquina X.

• src:representa um objeto de origem que está sendo modificado pelo participante, junto 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 da máquina X para o arquivo B da máquina Y, o arquivo A e a máquina X serão especificados na parte src do evento da UDM.
• Intermediário:representa detalhes sobre uma ou mais atividades de processamento de dispositivos intermediários descritas no evento. Isso inclui detalhes do dispositivo sobre um servidor proxy, um servidor redirecionamento SMTP etc.
• Observador: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 relata 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 acompanhar o seguinte:
  • Anexos de arquivos em e-mails
  • Domínios/URLs/IPs incorporados no corpo de um e-mail
  • DLLs que são 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 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.

Como especificar o resultado de segurança

Você pode especificar os resultados de segurança preenchendo os campos SecurityResult, incluindo detalhes sobre os riscos e ameaças de segurança encontrados pelo sistema de segurança, além das ações tomadas para mitigá-los. Confira abaixo exemplos de alguns tipos de eventos de segurança que exigem o preenchimento de campos de SecurityResult:

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