Formatar dados de registro como UDM

Todos os eventos do modelo de dados unificados 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, a origem dele etc.
  • Metadados de rede: metadados de rede de alto nível para eventos orientados por rede, bem como detalhes de protocolo em submensagens:
    • Metadados de e-mail: informações no campo "Para", "Formulário", "Cc", "Cco" e outros campos de e-mail.
    • Metadados HTTP: método, referenciador_url, user agent etc.
  • Resultados de segurança: qualquer classificação ou ação feita por um produto de segurança.
  • Metadados adicionais: todos os dados importantes de eventos específicos de fornecedores que não podem ser representados adequadamente dentro das 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 de UDM

Os eventos do UDM precisam ser enviados ao Chronicle usando um dos seguintes formatos:

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

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

É documentado da seguinte maneira:

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

Como formatar um evento UDM

Para formatar um evento UDM e enviá-lo ao Google, é necessário concluir as seguintes etapas:

  1. Especificar o tipo de evento: o tipo de evento selecionado determina quais campos também precisam ser incluídos no evento.
  2. Specify the Timestamp do evento-metadata-position="body" }: 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.
  4. Como especificar o resultado de segurança (opcional): especifique resultados de segurança incluindo detalhes sobre ameaças e riscos de segurança encontrados por um sistema de segurança, além das ações tomadas para mitigar esses riscos e ameaças.
  5. Preencha as outras informações de evento 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 ver 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 ver 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
}

Como especificar o carimbo de data/hora do evento

Você precisa 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 o RFC 3339
  • Carimbo de data/hora 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. A diferença do fuso horário UTC é de menos 8 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 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. Substantivos também podem ser itens 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 responsável ou o dispositivo de origem da 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), e opcionalmente incluir detalhes do processo. Ele N NOTO pode incluir nenhum dos seguintes campos: e-mail, arquivos, chaves de registro ou valores.

Se todos os eventos ocorrerem na mesma máquina, ela apenas precisará ser descrita como principal. A máquina não precisa ser descrita em target ou em 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" }
}

O exemplo acima descreve tudo que é conhecido sobre o dispositivo e o usuário que foi o ator principal 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 recurso 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 ao B, A é descrito como o principal, e B, como o destino. 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.

principal x meta no UDM Principal em comparação com o destino na UDM

O exemplo a seguir ilustra como os campos de um destino 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 proprietários etc., eles também deverão ser incluídos em target.

Tanto principal quanto alvo, bem 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 que está sendo usado pelo participante com o dispositivo ou o contexto do processo do 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, os arquivos A e a máquina X serão especificados na parte src do evento UDM.
  • intermediary: representa detalhes sobre uma ou mais atividades de processamento de dispositivos intermediários descritos no evento. Isso inclui detalhes do dispositivo sobre um servidor proxy, um servidor de redirecionamento SMTP etc.
  • observador: representa um dispositivo observador (por exemplo, um verificador de pacote ou verificador de vulnerabilidade baseado em rede), que não é um intermediário direto, mas que observa e informa o evento em questão.
  • sobre: Usado para armazenar detalhes em todos os objetos referenciados pelo evento que não são descritos de outra forma emparticipante, src, valor desejado, intermediário ou osobservador de dados. Por exemplo, é possível usá-lo para rastrear o seguinte:
    • Anexos de arquivo de e-mail
    • Domínios/URLs/IPs incorporados em um corpo de e-mail
    • DLLs que são carregadas durante um evento PROCESS_LAUNCH

As seções de entidade dos eventos do UDM incluem informações sobre os vários participantes (dispositivos, usuários, objetos como URLs, arquivos etc.) descritos no evento. O Chronicle UDM tem requisitos obrigatórios para o preenchimento dos campos de substantivo. Esses requisitos são descritos em Campos obrigatórios e opcionais para cada tipo de evento de UDM. O conjunto de campos de entidade que precisa ser preenchido varia de acordo com o tipo de evento.

Como especificar o resultado de segurança

Também é possível especificar resultados de segurança preenchendo os campos de SecurityResult, incluindo detalhes sobre ameaças e riscos de segurança encontrados pelo sistema de segurança, além das ações tomadas para mitigar esses riscos e ameaças. Veja a seguir exemplos de alguns tipos de ocorrências 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 de proxy de segurança de e-mail detectou dois anexos infectados (SOFTWARE_MALICIOUS) e colocou esses anexos em quarentena e desinfetados (QUARANTINE, ALLOW_WITH_MODIFICATION) e encaminhou o e-mail desinfetado.
  • 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 após o arquivo ser entregue (ALLOW) ao usuário na Caixa de entrada.