Entender a disponibilidade de dados para pesquisa

Compatível com:

Este documento detalha o ciclo de vida da ingestão de dados, incluindo o fluxo e a latência de dados de ponta a ponta, e como esses fatores afetam a disponibilidade de dados ingeridos recentemente para consulta e análise.

Ingerir e processar dados no Google SecOps

Esta seção descreve como o Google SecOps ingere, processa e analisa dados de segurança.

Ingestão de dados

O pipeline de ingestão de dados começa coletando seus dados de segurança brutos de fontes como:

  • Registros de segurança dos seus sistemas internos
  • Dados armazenados no Cloud Storage
  • Sua central de operações de segurança (SOC) e outros sistemas internos

O Google SecOps traz esses dados para a plataforma usando um dos métodos de ingestão seguros.

Os principais métodos de ingestão são:

  • Ingestão Google Cloud direta

    O Google SecOps usa a ingestão Google Cloud direta para extrair automaticamente registros e dados de telemetria da sua organização Google Cloud, incluindo o Cloud Logging, os metadados do Inventário de recursos do Cloud e as descobertas do Security Command Center Premium.

  • APIs de ingestão

    Envie dados diretamente para o Google SecOps usando as APIs públicas de ingestão REST Ingestion APIs. Use esse método para integrações personalizadas ou para enviar dados como registros não estruturados ou eventos do modelo de dados unificado (UDM) pré-formatados.

  • Agente do Bindplane

    Você pode implantar o agente versátil do Bindplane no seu ambiente (local ou outras nuvens) para coletar registros de várias fontes e encaminhá-los ao Google SecOps.

  • Feeds de dados

    No Google SecOps, você configura feeds de dados para extrair registros de fontes de terceiros, como buckets específicos de armazenamento em nuvem de terceiros (como o Amazon S3) ou APIs de terceiros (como o Okta ou o Microsoft 365).

Normalização e enriquecimento de dados

Quando os dados chegam ao Google SecOps, a plataforma os processa nas seguintes etapas:

  1. Análise e normalização

    Um analisador primeiro processa dados de registro brutos para validar, extrair e transformar os dados do formato original no UDM padronizado. A análise e a normalização permitem analisar fontes de dados diferentes (por exemplo, registros de firewall, dados de endpoint, registros de nuvem) usando um esquema único e consistente. O registro bruto original permanece armazenado junto ao evento do UDM.

  2. Indexação

    Após a normalização, o Google SecOps indexa os dados do UDM para oferecer velocidades de consulta rápidas em conjuntos de dados enormes, tornando os eventos do UDM pesquisáveis.

  3. Criação de alias e enriquecimento do UDM

    • O Google SecOps realiza a criação de alias e o enriquecimento do UDM para enriquecer eventos do UDM com contexto valioso, identificando e adicionando dados de contexto e indicadores para entidades de registro. Por exemplo, ele conecta o usuário login name aos vários IP addresses, hostnames e MAC addresses.
    • Geolocalização: o Google SecOps enriquece os endereços IP com dados de geolocalização.

  4. Enriquecimento de ECG

    • O Google SecOps realiza a criação de alias de ECG , que mescla o contexto de várias fontes (como IdPs, CMDBs e inteligência contra ameaças) para criar um perfil de entidade consolidado no gráfico de contexto da entidade.

    • Inteligência contra ameaças: o Google SecOps compara automaticamente os dados de eventos com a vasta inteligência contra ameaças do Google, incluindo fontes como o Google Threat Intelligence e o Navegação Segura, para identificar ameaças maliciosas conhecidas, como domains, IP addresses, e file hashes.

    • WHOIS: o Google SecOps enriquece os nomes de domínio com as informações públicas de registro WHOIS.

Disponibilidade de dados para análise

Depois de processados e enriquecidos, os dados do UDM ficam imediatamente disponíveis para análise:

  • Detecção em tempo real

    O mecanismo de detecção executa automaticamente regras personalizadas e criadas pelo Google ativadas para regras ativas em dados recebidos em tempo real para identificar ameaças e gerar alertas.

  • Pesquisa e investigação

    Um analista pode usar os métodos de pesquisa para pesquisar todos esses dados normalizados e enriquecidos. Por exemplo, usando a pesquisa do UDM para alternar entre entidades relacionadas (como um user, um asset e um domain malicioso) e investigar alertas.

Métodos de pesquisa

O Google SecOps oferece vários métodos distintos para pesquisar seus dados, cada um com uma finalidade diferente.

A pesquisa do UDM é o método de pesquisa principal e mais rápido, usado na maioria das investigações.

  • O que ele pesquisa:consulta os eventos do UDM normalizados e indexados. Como todos os dados são analisados nesse formato padrão, é possível escrever uma consulta para encontrar a mesma atividade (como um login) em todos os seus produtos diferentes (por exemplo, Windows, Okta, Linux).
  • Como funciona:você usa uma sintaxe específica para consultar campos, operadores e valores.

  • Exemplo: principal.hostname = "win-server" AND target.ip = "10.1.2.3"

    Os resultados geralmente ficam disponíveis de 2 a 15 minutos após a ingestão.

Use a pesquisa de registro bruto para encontrar algo na mensagem de registro original e não analisada que talvez não tenha sido mapeada para um campo do UDM. Esse método de pesquisa é otimizado para caças de alta velocidade, geralmente retornando resultados em menos de 2 segundos para indicadores específicos, como hashes de arquivos ou endereços IP.

  • O que ele pesquisa:verifica o texto bruto original dos registros antes de serem analisados e normalizados. Isso é útil para encontrar strings específicas, argumentos de linha de comando ou outros artefatos que não são campos do UDM indexados.
  • Como funciona:você usa o prefixo raw =. Ele pode ser mais lento do que a pesquisa do UDM porque não pesquisa campos indexados.
  • Exemplo (string) raw = "PsExec.exe"
  • Exemplo (regex) : raw = /admin\$/

Use a pesquisa de estatísticas para tendências de longo prazo que agregam milhões de linhas de dados. Como a plataforma precisa realizar análises estatísticas e agrupamentos, espere tempos de carregamento mais longos para essas consultas.

Pesquisa com linguagem natural (Gemini)

A pesquisa com linguagem natural (Gemini) permite que você use o inglês simples para fazer perguntas, que o Gemini traduz para uma consulta formal do UDM.

  • O que ele pesquisa:fornece uma interface conversacional para consultar dados do UDM.
  • Como funciona:você digita uma pergunta, e o Gemini gera a consulta de pesquisa do UDM subjacente, que pode ser executada ou refinada.
  • Exemplo : "Show me all failed logins from user 'bob' in the last 24 hours"

A pesquisa no SOAR é específica para componentes do SOAR. Você a usa para gerenciar incidentes de segurança, não para pesquisar registros.

  • O que ele pesquisa:procura casos e entidades (como usuários, ativos, endereços IP) na plataforma SOAR.
  • Como funciona:você pode usar filtros de texto livre ou baseados em campos para encontrar casos por ID, nome do alerta, status e usuário atribuído, por exemplo.
  • Exemplo:Search for CaseIds:180 or AlertName:Brute Force

Pipeline de ingestão de dados para disponibilidade de pesquisa

A disponibilidade de dados de ponta a ponta é o tempo total entre a ocorrência de um evento e a disponibilidade para pesquisa ou execução de regras no Google SecOps. Essa latência é a soma dos dois componentes a seguir:

  1. Atraso de disponibilidade do lado da origem:o tempo entre a ocorrência de um evento e o momento em que o sistema de origem disponibiliza os dados de registro para ingestão. Esse atraso depende da arquitetura, do processamento, do loteamento e das programações de publicação da API do sistema de origem. O Google SecOps não pode influenciar esse atraso. Os exemplos incluem atrasos quando um sistema grava registros em um bucket de armazenamento ou os publica em um endpoint de API.

  2. Tempo de processamento do Google SecOps:o tempo necessário para o Google SecOps processar os dados após o recebimento. Essa duração inclui etapas internas do pipeline, como ingestão, análise, normalização, indexação e enriquecimento.

Você precisa considerar os dois componentes ao solucionar problemas de cronogramas de visibilidade de dados.

Atrasos originados da fonte de dados

Os seguintes fatores podem influenciar o atraso de disponibilidade do lado da origem:

  • Processamento em lote:alguns sistemas geram registros em lotes em intervalos definidos (por exemplo, por hora).
  • Latência da API:a API de origem pode ter atrasos inerentes na disponibilização de novos eventos para consulta.
  • Tempo de criação e publicação de eventos:um carimbo de data/hora de evento em um registro pode ser muito anterior ao carimbo de data/hora em que o registro é finalizado e fica disponível para coleta.
  • Limitação:os limites de taxa da API do lado da origem podem diminuir a recuperação de dados.
  • Preenchimento inicial:a veiculação e a ingestão de grandes volumes de dados históricos levam tempo.

Esses atrasos variam de acordo com a fonte de dados e o tipo de registro. Para mais detalhes sobre os métodos de ingestão, consulte Visão geral da ingestão de dados. A referência da API de gerenciamento de feeds descreve considerações específicas para tipos de registro, como Microsoft Graph, SentinelOne, Okta e CrowdStrike.

Tempo de processamento do Google SecOps

O sistema processa os dados recém-ingeridos em várias etapas. A duração dessas etapas determina quando os dados recém-ingeridos ficam disponíveis para consulta e análise.

A tabela a seguir detalha as etapas de processamento de dados recém-ingeridos por método de pesquisa. Os dados recém-ingeridos ficam pesquisáveis após a conclusão dessas etapas.

Método de pesquisa Dados pesquisados Etapas de processamento que contribuem para o tempo de disponibilidade
Eventos do UDM normalizados e enriquecidos
  1. Ingestão:o registro chega ao ponto de ingestão do Google SecOps.
  2. Análise:o registro bruto é identificado e processado pelo analisador específico.
  3. Normalização:os dados são extraídos e mapeados para o esquema do UDM.
  4. Indexação (UDM) : o registro do UDM normalizado é indexado para pesquisa rápida e estruturada.
  5. Enriquecimento:o contexto (inteligência contra ameaças, geolocalização, dados de usuário ou de ativos) é adicionado.
Pesquisa de registro bruto Texto de registro original e não analisado
  1. Ingestão:o registro chega ao ponto de ingestão do Google SecOps.
Mecanismo de detecção (regras) Eventos normalizados
  1. Disponibilidade de eventos do UDM:as mesmas etapas listadas para a pesquisa do UDM.
  2. Avaliação de detecção:o mecanismo de regras avalia os registros em "microlotes", geralmente acionando detecções de 5 a 10 minutos após a chegada do evento.
Pesquisa no SOAR Casos e entidades Esse é um ciclo de vida diferente, já que ele pesquisa alertas e casos, não registros. O tempo é baseado em:
  1. Disponibilidade de eventos do UDM:usa as mesmas etapas de processamento listadas para "Pesquisa do UDM".
  2. Detecção: uma regra do mecanismo de detecção precisa corresponder aos eventos do UDM.
  3. Geração de alertas:o sistema cria um alerta formal a partir da detecção.
  4. Criação de casos:a plataforma SOAR ingere o alerta e cria um caso.

Exemplo de fluxo de dados

O exemplo a seguir demonstra como o Google SecOps ingere, processa, aprimora e analisa seus dados de segurança, disponibilizando-os para pesquisas e análises adicionais.

Exemplo de etapas de processamento de dados

  1. Recupera dados de segurança de serviços de nuvem, como o Amazon S3 ou do Google Cloud. O Google SecOps criptografa esses dados em trânsito.
  2. Separa e armazena seus dados de segurança criptografados na sua conta. O acesso é limitado a você e a um pequeno número de funcionários do Google para suporte, desenvolvimento e manutenção de produtos.
  3. Analisa e valida dados de segurança brutos, facilitando o processamento e a visualização.
  4. Normaliza e indexa os dados para pesquisas rápidas.
  5. Armazena os dados analisados e indexados na sua conta.
  6. Enriquece com dados de contexto.
  7. Oferece acesso seguro para que os usuários pesquisem e analisem os dados de segurança.
  8. Compara seus dados de segurança com o banco de dados de malware do Google Threat Intelligence para identificar correspondências. Em uma visualização de eventos do Google SecOps, como a visualização de ativos, clique em Contexto do VT para conferir as informações do Google Threat Intelligence. O Google SecOps não compartilha seus dados de segurança com o Google Threat Intelligence.

Fluxo e tratamento de dados para o Google SecOps

Exemplos do tempo esperado até a disponibilidade da pesquisa

O tempo esperado até que os dados recém-ingeridos fiquem disponíveis para pesquisa é a soma das durações do fluxo ao longo do fluxo de dados.

Por exemplo, um tempo médio típico para disponibilidade de dados na pesquisa do UDM é de aproximadamente 5 minutos e 30 segundos a partir do momento em que os dados são enviados ao serviço de ingestão do Google SecOps.

Etapa do fluxo de dados Descrição Duração do fluxo
Cloud Storage para Registros brutos Ingere registros brutos do Cloud Storage. Menos de 30 segundos
Registros de segurança para Serviço de encaminhamento de dados Transmite registros de segurança de sistemas internos para a plataforma. N/A
Serviço de encaminhamento de dados para Registros brutos Envia dados de segurança brutos recebidos de várias fontes para o pipeline de ingestão. Menos de 30 segundos
Registros brutos para Analisar e validar Analisa e valida registros brutos no formato UDM. Menos de 3 minutos
Analisar e validar para Indexar Indexa os dados do UDM analisados para pesquisa rápida. N/A
Indexar para Dados do cliente analisados Disponibiliza os dados indexados como dados do cliente analisados para análise. Menos de 2 minutos

Solução de problemas

Esta seção fornece orientações para a solução de problemas.

Latência e limites

Os atrasos de processamento e visualização na plataforma Google SecOps estão sujeitos aos seguintes limites arquitetônicos depois que o Google SecOps recebe os dados:

  • Visibilidade da pesquisa:de 2 a 15 minutos após a ingestão.
  • Execução de regras:de 5 a 10 minutos após a chegada do evento.
  • Visualização da interface:para manter o desempenho do navegador, os dados de registro de alto volume estão sujeitos a um limite de visualização de 10.000 linhas.

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