Visão geral do modelo de dados unificado

Compatível com:

Google SecOps SIEM

Este documento contém uma visão geral do Modelo de dados unificado (UDM, na sigla em inglês). Para mais detalhes sobre os campos UDM, incluindo uma descrição de cada um, consulte o campo UDM lista. Para mais informações sobre o mapeamento de analisador, consulte Campos importantes de UDM para o mapeamento de analisador.

O UDM é uma estrutura de dados padrão das Operações de Segurança do Google que armazena informações sobre os dados recebidos de fontes. Ele também é chamado de esquema. As operações de segurança do Google armazenam os dados originais recebidos em dois formatos: como o registro bruto original e como um registro estruturado do UDM. O registro UDM é um registro estruturado do registro original.

Se existir um analisador para o tipo de registro especificado, o registro bruto será usado para criar um registro UDM. Os clientes também podem transformar registros brutos em um formato UDM estruturado antes de enviar os dados para as Operações de segurança do Google usando a API Ingestion.

Alguns dos benefícios do UDM incluem:

• Armazena o mesmo tipo de registro de fornecedores diferentes usando o mesmo semântica.
• É mais fácil identificar as relações entre usuários, hosts e endereços IP porque os dados são normalizados no esquema padrão do UDM.
• Regras mais fáceis de escrever porque podem ser independentes de plataforma.
• Agora é mais fácil oferecer suporte a tipos de registro de novos dispositivos.

Observação: o mecanismo de regras das operações de segurança do Google usa os mesmos nomes de campo do UDM. Você pode use esses mesmos nomes de campo ao criar regras.

Embora seja possível pesquisar eventos com uma pesquisa de registro bruto, uma pesquisa UDM funciona mais rápido e com mais precisão devido à especificidade.

As Operações de segurança do Google usam o esquema UDM para todos os eventos coletados. O UDM inclui milhares de campos usados para descrever e categorizar eventos. Por exemplo, o UDM pode lidar com eventos de processos de endpoint tão facilmente e eventos de comunicação.

Estrutura do UDM

Os eventos de UDM são compostos de várias seções. A primeira seção encontrada O evento de UDM é a seção de metadados. Ela fornece uma descrição básica do evento, incluindo a data e a hora em que o evento ocorreu ingeridos nas Operações de segurança do Google. Ele também inclui as informações, a versão e a descrição do produto. O analisador de transferência classifica cada evento com base em um tipo de evento predefinido, independentemente do registro de produto específico. Com os campos de metadados, você pode começar a pesquisar os dados rapidamente.

Além da seção de metadados, outras seções descrevem outros aspectos do evento. Se uma seção for desnecessária, ela não será incluída, economizando memória.

• principal: entidade que origina a atividade no evento. Seções que fazem referência à origem (src) e ao destino (target) também são incluídas.
• intermediary: sistemas por onde os eventos passam, como um proxy ou de redirecionamento SMTP.
• observer: sistemas como sniffers de pacotes que de forma passiva monitorar pelo tráfego.

Exemplos de pesquisas do UDM

Esta seção fornece exemplos de pesquisas do UDM que demonstram alguns dos a sintaxe, os recursos e as funcionalidades básicas da pesquisa UDM.

Exemplo: pesquisa de logins bem-sucedidos do Microsoft Windows 4624

A pesquisa a seguir lista os eventos de login bem-sucedidos do Microsoft Windows 4624, e quando os eventos foram gerados, com base em apenas dois campos de UDM:

metadata.event_type = "USER_LOGIN" AND metadata.product_event_type = "4624"

Exemplo: pesquisar todos os logins bem-sucedidos

A pesquisa a seguir lista todos os eventos de login bem-sucedidos, independentemente do fornecedor ou aplicativo:

metadata.event_type = "USER_LOGIN" AND security_result.action = "ALLOW" AND target.user.userid != "SYSTEM" AND target.user.userid != /.*$/

Exemplo: pesquisa de logins de usuário bem-sucedidos

O exemplo a seguir ilustra como pesquisar por userid "fkolzig" e determinar quando o usuário com esse ID fez login. Você pode conclua essa pesquisa usando a seção de destino. A seção de segmentação inclui subseções e campos que descrevem o destino. Por exemplo, o destino caso é um usuário e tem uma série de atributos associados, mas o alvo pode também pode ser um arquivo, uma configuração de registro ou um ativo. Este exemplo procura "fkolzig" usando o campo target.user.userid.

metadata.event_type = "USER_LOGIN" AND metadata.product_event_type = "4624" AND target.user.userid = "fkolzig"

Exemplo: pesquisar os dados da rede

O exemplo a seguir pesquisa dados de rede para eventos de RDP com um target.port

de 3389 e um principal.ip de 35.235.240.5 Ele também inclui um campo UDM da seção de rede, a direção dos dados (network.direction).

metadata.product_event_type = "3" AND target.port = 3389 AND network.direction = "OUTBOUND" and principal.ip = "35.235.240.5"

Exemplo: pesquisar um processo específico

Para examinar os processos criados nos servidores, procure instâncias do comando net.exe e procure esse arquivo específico no caminho esperado. O que você está procurando é target.process.file.full_path. Para essa pesquisa, inclua o comando específico emitido no target.process.command_line.

da segurança cibernética na nuvem. Você também pode adicionar um campo na seção "Sobre", que é a descrição do código de evento do Microsoft Sysmon 1 (ProcessCreate).

Esta é a pesquisa do UDM:

metadata.product_event_type = "1" AND target.process.file.full_path = "C:\Windows\System32\net.exe"

Opcionalmente, adicione os seguintes campos de pesquisa do UDM:

• principal.user.userid: identifica o usuário que emitiu o comando.
• principal.process.file.md5: identificar o hash MD5.
• principal.process.command_line: linha de comando.

Exemplo: pesquisar logins de usuário bem-sucedidos associados a um departamento específico

O exemplo a seguir pesquisa logins de usuários (metadata.event_type é USER_LOGIN) associados ao departamento de marketing (target.user.department é marketing) da sua empresa. Embora target.user.department não seja diretamente estiver conectado a eventos de login do usuário, ele ainda estará presente nos dados LDAP ingeridos sobre seus usuários.

metadata.event_type = "USER_LOGIN" AND target.user.department = "Marketing"

Objetos lógicos: evento e entidade

O esquema do UDM descreve todos os atributos disponíveis que armazenam dados. Cada registro do UDM identifica se ele descreve um evento ou uma entidade. Os dados são armazenados em campos diferentes dependendo se o registro descreve um evento ou Entity e também qual valor é definido nos metadados.event_type ou metadata.entity_type.

• Evento de UDM: armazena dados de uma ação que ocorreu no de nuvem. O registro de eventos original descreve a ação conforme foi gravada pelo dispositivo, como firewall e proxy da Web. Estes são os dados do evento de UDM um modelo de machine learning.
• Entidade de UDM: representação contextual de elementos como recursos, usuários e recursos do ambiente. Ele é extraído de uma fonte de verdade. Esse é o modelo de dados de entidade do UDM.

Confira duas representações visuais de alto nível do modelo de dados de eventos e do modelo de dados de entidades.

Figura: modelo de dados de eventos

Observação: o termo Noun descreve o tipo de atributo. Os termos principal, target, src, intermediário, observer e about são os nomes de campo em que os dados são armazenados.

Figura: modelo de dados da entidade

Observação: o termo substantivo descreve o tipo de atributo. Os termos ativo, usuário e recursos são os nomes dos campos em que os dados são armazenados.

Estrutura de um evento de UDM

O evento UDM contém várias seções que armazenam um subconjunto dos dados de um único registro. As seções são:

• metadados
• participante
• target
• src
• observador
• intermediário
• sobre
• network
• security_result

• extensions

  

  Figura: modelo de dados de eventos

A seção metadados armazena o carimbo de data/hora, define o event_type e descreve o dispositivo.

As solicitações principal, target, src armazenamento das seções observer e intermediary informações sobre os objetos envolvidos no evento. Um objeto pode ser um dispositivo, usuário ou processo. Na maioria das vezes, apenas um subconjunto dessas seções é usado. Os campos que armazenam dados são determinados pelo tipo de evento e pelo função que cada objeto desempenha no evento.

A seção rede armazena informações relacionadas à atividade de rede, como e-mail e comunicação relacionada à rede.

• Dados de e-mail: informações nos campos to, from, cc, bcc e outros campos de e-mail.
• Dados HTTP: como method, referral_url e useragent.

A seção security_result armazena uma ação ou classificação registrada por um produto de segurança, como um antivírus.

As seções sobre e extensões armazenam outras informações de evento específicas do fornecedor que não são capturadas pelas outras seções. A seção extensions é uma conjunto de pares de chave-valor em formato livre.

Cada evento de UDM armazena valores de um evento de registro bruto original. Dependendo tipo de evento, alguns atributos são obrigatórios e outros são opcionais. O atributos obrigatórios e opcionais são determinados pelo campo metadata.event_type . O Google Security Operations lê metadata.event_type e realiza a validação de campo específica para esse tipo de evento depois que os registros são recebidos.

Se nenhuma informação for armazenada em uma seção do registro do UDM, por exemplo, a seção de extensões, essa seção não vai aparecer no registro do UDM.

Campos de metadados

Esta seção descreve os campos obrigatórios em um evento de UDM.

O campo event_timestamp

Os eventos de UDM precisam incluir dados para o metadata.event_timestamp, que é o carimbo de data/hora GMT em que o evento ocorreu. O valor precisa ser codificado usando um dos seguintes padrões: carimbo de data/hora RFC 3339 ou Proto3.

Os exemplos a seguir ilustram como especificar o carimbo de data/hora usando o RFC 3339 formato, yyyy-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 é menos oito horas, indicando PST.

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

metadata {
  event_timestamp: "2021-02-23T04:00:00.000Z"
}

Também é possível especificar o valor usando o formato de época.

metadata {
event_timestamp: {
  "seconds": 1588180305
 }
}

O campo event_type

O campo mais importante no evento da UDM é metadata.event_type. Esse valor identifica o tipo de ação realizada e é independente do fornecedor, produto ou plataforma. Os exemplos de valores incluem PROCESS_OPEN, FILE_CREATION, USER_CREATION e NETWORK_DNS. Para conferir a lista completa, consulte o documento Lista de campos da UDM.

O valor metadata.event_type determina quais outras solicitações e campos opcionais precisam ser incluídos no registro UDM. Para informações sobre quais campos incluir para cada tipo de evento, consulte Uso do UDM guia.

Os atributos principal, de destino, src, intermediário, observer e "about"

As solicitações principal, target, src Os atributos intermediary e observer descrevem os recursos que estão envolvidas no evento. Cada armazena informações sobre objetos envolvidos em a atividade, conforme registrado pelo registro bruto original. Pode ser o dispositivo ou usuário que realizou a atividade, o dispositivo ou usuário que é o alvo da atividades. Também pode descrever um dispositivo de segurança que tenha observado a atividade, como um proxy de e-mail ou roteador de rede.

Os atributos mais usados são:

• principal: objeto que realizou a atividade.
• src: objeto que inicia a atividade, se for diferente de o principal.
• target: objeto que recebe uma ação.

Cada tipo de evento exige que pelo menos um desses campos contenha dados.

Os campos auxiliares são:

• intermediary: qualquer objeto que atuou como intermediário na evento. Isso pode incluir objetos como servidores proxy e de e-mail.
• observer: qualquer objeto que não interaja diretamente com o tráfego em questão. Pode ser um scanner de vulnerabilidade ou um dispositivo de sniffer de pacotes.
• about: qualquer outro objeto que tenha desempenhado um papel no evento e seja opcional.

Os atributos principais

Representa a entidade que atua ou o dispositivo que originou a atividade. O princípio precisa incluir pelo menos um detalhe de máquina (nome de host, endereço MAC, endereço IP, identificadores específicos do produto, como um GUID de máquina do CrowdStrike) ou de usuário (por exemplo, nome de usuário) e, opcionalmente, detalhes do processo. Ele deve não incluir nenhum destes campos: e-mail, arquivos, chaves ou valores de registro.

Se o evento ocorrer em uma única máquina, ela é descrita no apenas para o atributo principal. A máquina não precisa ser descrita no target ou src.

Observação :um dispositivo de segurança pode gravar um evento, mas ele não está descrito nas o atributo principal. Isso seria descrito no 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 Windows em que o malware foi detectado), o dispositivo Windows será o principal.

O snippet JSON a seguir ilustra como o atributo principal podem ser preenchidos.

"principal": {
  "hostname": "jane_win10",
  "asset_id" : "Sophos.AV:C070123456-ABCDE",
    "ip" : "10.10.2.10",
    "port" : 60671,
    "user": {  "userid" : "john.smith" }
}

Esse atributo descreve tudo o que é conhecido sobre o dispositivo e o usuário que foi ator principal no evento. Esse exemplo inclui o endereço IP do dispositivo, número da porta e nome do host. Ele também inclui um identificador de recursos específico do fornecedor, do Sophos, que é um identificador exclusivo gerado pelo serviço de produto.

Os atributos de destino

Representa um dispositivo de destino sendo referenciado pelo evento, ou um objeto na dispositivo de destino. Por exemplo, em uma conexão de firewall do dispositivo A para o dispositivo B, o dispositivo A é capturado como o principal e o dispositivo B é capturado como o alvo.

Para uma injeção de processo pelo processo C no processo de destino D, o processo C é o principal e o processo D é o destino.

Figura: principal versus destino

O exemplo a seguir ilustra como o campo de destino pode ser preenchido.

target {
   ip: "192.0.2.31"
   port: 80
}

Se houver mais informações disponíveis no registro bruto original, como nome do host, endereços IP adicionais, endereços MAC e identificadores de ativos proprietários, também devem ser incluídos nos campos de destino e principal.

O principal e o alvo podem representar atores na mesma máquina. Por exemplo: o processo A (principal) executado na máquina X também pode atuar no processo B (destino), na máquina X.

O atributo src

Representa um objeto de origem sendo acionado pelo participante junto com o do dispositivo ou do processo para o objeto de origem (a máquina em que a 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, o arquivo A e a máquina X serão especificados na parte src do evento UDM.

O atributo intermediário

Representa detalhes sobre a atividade de processamento de um ou mais dispositivos intermediários descritas no evento. Isso pode incluir detalhes sobre dispositivos, como os servidores proxy e os servidores de redirecionamento SMTP.

O atributo observer

Representa um dispositivo de observador que não é um intermediário direto, mas que observa e informa sobre o evento em questão. Isso pode incluir um sniffer de pacotes ou um scanner de vulnerabilidade baseado em rede.

O atributo "about"

Este repositório de detalhes sobre um objeto referenciado pelo evento que não está descritos nos campos principal, src, target, intermediário ou observador. Para por exemplo, ela pode capturar o seguinte:

• Anexos de arquivos de e-mail.
• Domínios, URLs ou endereços IP incorporados no corpo de um e-mail.
• DLLs que são carregadas durante um evento PROCESS_LAUNCH.

O atributo security_result

Essa seção contém informações sobre riscos de segurança e ameaças encontrados por um sistema de segurança e as ações tomadas para mitigar esses riscos e ameaças à segurança.

Estes são os tipos de informações que seriam armazenadas no atributo security_result:

• Um proxy de segurança de e-mail detectou uma tentativa de phishing (security_result.category = MAIL_PHISHING) e bloqueado (security_result.action = BLOCK) o e-mail.
• Um firewall de proxy de segurança de e-mail detectou dois anexos infectados (security_result.category = SOFTWARE_MALICIOUS) e colocado em quarentena e desinfetado (security_result.action = QUARANTINE ou security_result.action = ALLOW_WITH_MODIFICATION) esses anexos e, em seguida, encaminhou os e-mails desinfetados.
• Um sistema de SSO permite um login (security_result.category = AUTH_VIOLATION) que foi bloqueado (security_result.action = BLOCK).
• Um sandbox de malware detectou spyware (security_result.category = SOFTWARE_MALICIOUS) em um anexo de arquivo cinco minutos depois que o arquivo foi enviado (security_result.action = ALLOW) para o usuário na caixa de entrada.

O atributo de rede

Os atributos de rede armazenam dados sobre eventos relacionados à rede e detalhes sobre protocolos em submensagens. Isso inclui atividades, como e-mails enviados e recebidas e solicitações HTTP.

O atributo "extensões"

Os campos sob esse atributo armazenam metadados adicionais sobre o evento capturado no registro bruto original. Ele pode conter informações sobre vulnerabilidades informações adicionais relacionadas à autenticação.

Estrutura de uma entidade de UDM

Um registro de entidade do UDM armazena informações sobre qualquer entidade dentro de uma organização. Se metadata.entity_type for USER, o registro armazenará informações sobre a usuário no atributo entity.user. Se o metadata.entity_type for ASSET, o registro armazena informações sobre um recurso, como estação de trabalho, laptop, smartphone e máquina virtual.

Figura: modelo de dados de eventos

Campos de metadados

Esta seção contém campos obrigatórios em uma entidade do UDM, como:

• collection_timestamp: a data e hora em que o registro foi coletado.
• entity_type: o tipo de entidade, como recurso, usuário e recurso.

Atributo de entidade

Os campos do atributo da entidade armazenam informações sobre a entidade específica, como nome de host e endereço IP se for um recurso ou windows_sid e endereço de e-mail se for um usuário. Observe que o nome do campo é "entity", mas o tipo de campo é substantivo. Um substantivo é uma estrutura de dados usada com frequência que armazena informações em entidades e eventos.

• Se o metadata.entity_type for USER, os dados serão armazenados no atributo entity.user.
• Se metadata.entity_type for ASSET, os dados serão armazenados no entity.asset.

O atributo de relação

Os campos do atributo de relação armazenam informações sobre outras entidades relacionadas à entidade principal. Por exemplo, se a entidade principal for um usuário e um laptop será atribuído ao usuário. O laptop é uma entidade relacionada. As informações sobre o laptop são armazenadas como uma "entidade" gravar com um metadata.entity_type = RECURSO. As informações sobre o usuário são armazenadas como um registro de "entidade" com metadata.entity_type = USER.

O registro de entidade do usuário também captura a relação entre o usuário e o laptop, usando campos no atributo "relation". O campo relation.relationship armazena a relação que o usuário tem com o laptop, especificamente que o usuário é o proprietário do laptop. O camporelation.entity_type armazena o valor ASSET, porque o laptop é um dispositivo.

Os campos sob o atributo relacionais.entity armazenam informações sobre o laptop, como nome do host e endereço MAC. Novamente, o nome do campo "entity" e o tipo de campo é um substantivo. Um substantivo é uma estrutura de dados usada com frequência. Os campos sob o atributo relacional.entity armazenam informações sobre o laptop.

O campo relacional.direction armazena a direção da relação entre o usuário e o laptop, especificamente se a relação é bidirecional versus unidirecional.