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: 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 a rede, além de detalhes de protocolo em submensagens:
  • Metadados do e-mail: informações nos campos "Para", "De", "Cc", "Cco" 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 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 do UDM e enviar ao 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. 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. 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 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
}

Especificação do 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: 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 alvo da 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 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 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. 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 para o dispositivo B, A é descrito como o principal e B é descrito como o alvo. 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.

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 target (assim como outros substantivos) podem fazer referência a 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 acessado 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, 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 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 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. 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ê 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. 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 (BLOCK) 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 após o envio do arquivo (ALLOW) para o usuário na caixa de entrada dele.