Visão geral do Modelo de dados unificado
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 mapeamento do analisador, consulte Campos importantes do UDM para o analisador mapeamento.
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: registro bruto original e como registro UDM estruturado. 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.
- Facilidade de identificação de relações entre usuários, hosts e endereços IP porque os dados são normalizados no esquema UDM padrão.
- Regras mais fáceis de escrever porque podem ser independentes de plataforma.
- Suporte a tipos de registro de novos dispositivos mais fácil.
Embora seja possível pesquisar eventos com uma pesquisa de registros brutos, uma pesquisa UDM funciona com mais rapidez e precisão, devido à sua especificidade.
As Operações de segurança do Google usam o esquema UDM para todos os eventos coletados. 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 nas Operações de segurança do Google. Ela também inclui informações do produto, versão e descrição. O analisador de ingestão classifica cada evento com base em uma tipo de evento predefinido, independentemente do registro de produto específico. Com o campos de metadados sozinhos, 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 façam 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 de 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
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 pesquisa "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 seus dados de rede
O exemplo a seguir pesquisa dados de rede em busca de eventos RDP com um target.port.
de 3389 e um principal.ip de
35.235.240.5 Também inclui um campo UDM da seção "Rede", a direção do
(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 seus servidores, procure instâncias do
net.exe e pesquise esse arquivo específico no caminho esperado. O
que você está procurando é target.process.file.full_path. Para
nesta pesquisa, inclua o comando específico emitido na 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 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"
Também é possível adicionar os seguintes campos de pesquisa do UDM:
principal.user.userid: identifica o usuário que emite o kubectl.principal.process.file.md5: identifique 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 por usuários (metadata.event_type
é USER_LOGIN) associado 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 UDM descreve todos os atributos disponíveis que armazenam dados. Cada UDM registro 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 log de eventos original descreve a ação como ela 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 é obtido de uma fonte de verdade. Esse é o modelo de dados de entidade do UDM.
Aqui estão duas representações visuais de alto nível do modelo de dados de eventos e as Modelo de dados de entidade.
Figura: modelo de dados de eventos
Figura: modelo de dados da entidade
Estrutura de um evento de UDM
O evento de UDM contém várias seções, cada uma armazenando um subconjunto dos dados para 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 metadata 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 é
usados. 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 network armazena informações relacionadas à atividade da rede, como comunicação relacionada a e-mail e rede.
- Dados de e-mail: informações em
to,from,cc,bcce outros campos de e-mail. - Dados HTTP: como
method,referral_urleuseragent
A seção security_result armazena uma ação ou classificação registrada por um de segurança, como um antivírus.
As seções Sobre e Extensões armazenam eventos adicionais específicos do fornecedor informações nã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ê o campo metadata.event_type e executa específica para esse tipo de evento após o recebimento dos registros.
Se nenhum dado estiver armazenado em uma seção do registro UDM, como as extensões ela não aparecerá no registro 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 deve 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 de UDM é metadata.event_type.
Esse valor identifica o tipo de ação desempenhada e é independente do fornecedor,
produto ou plataforma. Exemplos de valores incluem PROCESS_OPEN,
FILE_CREATION, USER_CREATION
e NETWORK_DNS. Para acessar a lista completa, consulte o campo UDM
list.
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, target, src, intermediário, observador e "Sobre"
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 executou 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 servidores de e-mail.observer: qualquer objeto que não interaja diretamente com o no tráfego em questão. Isso pode ser uma verificação de vulnerabilidades ou um dispositivo interceptador.about: qualquer outro objeto que desempenhou um papel no evento e está opcional.
Os atributos principais
Representa a entidade que atua ou o dispositivo que originou a atividade. O principal deve incluir pelo menos um detalhe da máquina (nome do host, endereço MAC, IP endereço IP, identificadores específicos do produto, como um GUID da máquina CrowdStrike) ou usuário (por exemplo, nome de usuário) e, opcionalmente, incluir detalhes do processo. Ele deve não incluir nenhum destes campos: e-mail, arquivos, chaves de registro ou valores.
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.
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 principal, e o B como destino.
No caso de uma injeção pelo processo C no processo de destino D, o processo C é a principal e o processo D é o alvo.
Figura: principal x meta
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 em máquina Y, tanto o arquivo A quanto a máquina X seriam especificados na parte src do o evento de 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 do observador
Representa um dispositivo observador que não é um intermediário direto, mas que observa e relata o evento em questão. Isso pode incluir um pacote ou verificador de vulnerabilidades com base em rede.
O atributo "sobre"
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 security_result atributo:
- 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 SSO permite um login (security_result.category = AUTH_VIOLATION) que foi bloqueado (security_result.action = BLOCK).
- Uma sandbox para malware detectou spyware (security_result.category = SOFTWARE_MALICIOUS) em um anexo cinco minutos após o arquivo ser entregue (security_result.action = ALLOW) ao usuário na caixa de entrada dele.
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 metadata.entity_type for ASSET, o armazena informações sobre um ativo, como estação de trabalho, laptop, telefone e a máquina virtual.
Figura: modelo de dados de eventos
Campos de metadados
Esta seção contém campos obrigatórios em uma entidade de UDM, como:
- collection_timestamp: a data e hora em que o registro foi coletado.
- entity_type: o tipo da entidade, como ativo, usuário e recurso.
Atributo da entidade
Os campos sob o atributo de entidade armazenam informações sobre a entidade, como nome do host e endereço IP, se for um ativo, 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 metadata.entity_type for USER, os dados serão armazenados no entity.user.
- Se metadata.entity_type for ASSET, os dados serão armazenados no entity.asset.
O atributo de relação
Os campos sob o atributo de relação armazenam informações sobre outras entidades que à qual a entidade principal está relacionada. Por exemplo, se a entidade principal for um usuário e um laptop é concedido 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 "entity" com o campo 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 os campos da "relação" . A relação.relação armazena a relação que o usuário tem com o laptop, especificamente que o usuário é proprietário do laptop. O campo relacional.entity_type armazena o valor ASSET, porque o laptop é um dispositivo.
Os campos sob o atributorelations.entity armazenam informações sobre o laptop, como nome do host e endereço MAC. Observe novamente que 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.