Formate os dados de registo como UDM

Compatível com:

Google secops SIEM

Campos de eventos da UDM comuns

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. Estes campos incluem o seguinte:

• Entidades: dispositivos, utilizadores e processos envolvidos num evento.
• Metadados do evento: quando o evento ocorreu, o tipo de evento, a origem, etc.
• Metadados da rede: metadados da rede de alto nível para eventos orientados para a rede, bem como detalhes do protocolo em submensagens:
  • Metadados de email: informações nos campos para, de, cc, bcc e outros campos de email.
  • Metadados HTTP: método, referral_url, useragent, etc.
• Resultados de segurança: qualquer classificação ou ação realizada por um produto de segurança.
• Metadados adicionais: quaisquer dados de eventos importantes específicos do fornecedor que não possam ser representados adequadamente nas secções formais do modelo de UDM podem ser adicionados através de um campo de payload JSON de forma livre.

As secções seguintes descrevem como codificar e formatar eventos para o GDM.

Codificação UDM

Os eventos UDM têm de ser enviados para o Google Security Operations através de um dos seguintes formatos:

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

Para efeitos deste documento, os campos são representados através de 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 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 de modo a prepará-lo para envio para a Google, tem de concluir os seguintes passos:

1. Especifique o tipo de evento: o tipo de evento selecionado determina os campos que também tem de incluir no evento.
2. Especifique o carimbo de data/hora do evento: especifique o carimbo de data/hora do evento.
3. Especifique substantivos (entidades): cada evento tem de incluir, pelo menos, um substantivo que descreva um dispositivo ou um utilizador participante envolvido no evento.
4. Especificar o resultado de segurança: (opcional) especifique os resultados de segurança incluindo detalhes sobre os riscos e as ameaças de segurança que foram encontrados por um sistema de segurança, bem como as ações realizadas para mitigar esses riscos e ameaças.
5. Preencha as restantes informações de eventos obrigatórias e opcionais através dos campos de eventos da UDM.

Especifique o tipo de evento

O valor mais importante definido para qualquer evento enviado no formato UDM é o tipo de evento, especificado através de um dos valores possíveis disponíveis para Metadata.event_type. Estes incluem valores como PROCESS_OPEN, FILE_CREATION, USER_CREATION, NETWORK_DNS, etc. (para a lista completa, consulte Metadata.event_type). Cada tipo de evento requer que também preencha um conjunto de outros campos e valores com as informações associadas ao evento original. Consulte o artigo Campos obrigatórios e opcionais para cada tipo de evento da UDM para ver detalhes sobre os campos a incluir para cada tipo de evento. O exemplo seguinte ilustra como especificar PROCESS_OPEN como o tipo de evento através da notação de texto Proto3:

metadata {
    event_type: PROCESS_OPEN
}

Especifique a data/hora do evento

Tem de especificar a data/hora GMT para qualquer evento enviado no formato UDM através de Metadata.event_timestamp. A indicação de tempo tem de ser codificada através de uma das seguintes normas:

• Para JSON, use RFC 3339
• Data/hora Proto3

O exemplo seguinte ilustra como especificar a data/hora através do formato RFC 3339. Para este exemplo, aaaa-mm-ddThh:mm:ss+hh:mm: ano, mês, dia, hora, minuto, segundo e a diferença horária entre UTC e um determinado local e data. A diferença para UTC é de menos 8 horas, o que indica PST.

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

Especifique substantivos (entidades)

Para cada evento da UDM, tem de definir um ou mais substantivos. Um substantivo representa um participante ou uma entidade num evento UDM. Um substantivo pode ser, por exemplo, o dispositivo/utilizador que realiza a atividade descrita num evento ou o dispositivo/utilizador que é o alvo dessa atividade descrita no evento. Os substantivos também podem ser coisas como anexos ou URLs. Por último, 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 email ou um router de rede).

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

principal: representa a entidade ou o dispositivo que origina a atividade descrita no evento. O principal tem de incluir, pelo menos, um detalhe da máquina (nome do anfitrião, MACs, IPs, porta, identificadores específicos do produto, como um GUID da máquina CrowdStrike) ou um detalhe do utilizador (por exemplo, nome do utilizador) e, opcionalmente, incluir detalhes do processo. NÃO pode incluir nenhum dos seguintes campos: email, ficheiros, chaves ou valores de registo.

Se todos os eventos estiverem a ocorrer na mesma máquina, só é necessário descrever essa máquina em principal. A máquina também não tem de ser descrita em target nem em src.

Nota: um dispositivo de segurança pode originar um evento, mas não seria descrito no campo principal. Seria descrito nos campos observer ou intermediary. Se o software de segurança (por exemplo, o Carbon Black) for executado no mesmo dispositivo que originou a atividade (por exemplo, um ponto final do Windows onde foi detetado software malicioso), esse dispositivo também seria o principal.

O exemplo seguinte 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 utilizador que foi o principal ator no evento. Inclui o endereço IP, o número da porta e o nome do anfitrião do dispositivo, juntamente com 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, numa ligação de firewall do dispositivo A para o dispositivo B, A é descrito como o principal e B é descrito 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 versus alvo no UDM

O exemplo seguinte ilustra como os campos de um alvo são preenchidos:

target {
   ip: "198.51.100.31"
   port: 80
}

Mais uma vez, se estiverem disponíveis mais informações, como o nome do anfitrião, endereços IP adicionais, endereços MAC, identificadores de recursos proprietários, etc., estas também devem ser incluídas em target.

Tanto o principal como o alvo (bem 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 sobre o qual o participante está a agir, juntamente com o contexto do dispositivo ou do processo para o objeto de origem (a máquina onde o objeto de origem reside). Por exemplo, se o utilizador U copiar o ficheiro A no computador X para o ficheiro B no computador Y, o ficheiro A e o computador X seriam especificados na parte src do evento UDM.
• intermediary: representa detalhes sobre um ou mais dispositivos intermédios que processam a atividade descrita no evento. Isto inclui detalhes do dispositivo sobre um servidor proxy, um servidor de transmissão de SMTP, etc.
• observer: representa um dispositivo observador (por exemplo, um analisador de pacotes ou um verificador de vulnerabilidades baseado na rede), que não é um intermediário direto, mas que observa e comunica o evento em questão.
• about: usado para armazenar detalhes sobre todos os objetos referenciados pelo evento que não são descritos de outra forma em participant, src, target, intermediary ou observer. Por exemplo, pode ser usado para acompanhar o seguinte:
  • Anexos de ficheiros de email
  • Domínios/URLs/IPs incorporados no corpo de um email
  • DLLs carregadas durante um evento PROCESS_LAUNCH

As secções de entidades dos eventos UDM incluem informações sobre os vários participantes (dispositivos, utilizadores, objetos como URLs, ficheiros, etc.) descritos no evento. O UDM do Google Security Operations tem requisitos obrigatórios no que diz respeito ao preenchimento dos campos de substantivos. Estes requisitos são descritos no artigo Campos obrigatórios e opcionais para cada tipo de evento do UDM. O conjunto de campos de entidades que têm de ser preenchidos varia consoante o tipo de evento.

Especifique o resultado de segurança

Opcionalmente, pode especificar os resultados de segurança preenchendo os campos SecurityResult, incluindo detalhes sobre os riscos e as ameaças de segurança que foram encontrados pelo sistema de segurança, bem como as ações realizadas para mitigar esses riscos e ameaças. Seguem-se exemplos de alguns dos tipos de eventos de segurança que requerem o preenchimento dos campos SecurityResult:

• Um proxy de segurança de email detetou uma tentativa de phishing (MAIL_PHISHING) e bloqueou (BLOCK) o email.
• Uma firewall de proxy de segurança de email detetou dois anexos infetados (SOFTWARE_MALICIOUS), colocou-os em quarentena e desinfetou-os (QUARANTINE, ALLOW_WITH_MODIFICATION). Em seguida, encaminhou o email desinfetado.
• Um sistema de SSO facilitou um início de sessão (AUTH_VIOLATION) que foi bloqueado (BLOCK).
• Um sandbox de software malicioso detetou spyware (SOFTWARE_MALICIOUS) num anexo de ficheiro cinco minutos após o ficheiro ter sido entregue (ALLOW) ao utilizador na respetiva caixa de entrada.

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