Entender a disponibilidade de dados para pesquisa

Compatível com:

Google SecOps

Este documento detalha o ciclo de vida da ingestão de dados, incluindo o fluxo de dados e a latência 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 segura.

Os principais métodos de transferência 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, metadados do Inventário de recursos do Cloud e descobertas do Security Command Center Premium.

• APIs de ingestão

  Envie dados diretamente para o Google SecOps usando as APIs de ingestão REST públicas. Use esse método para integrações personalizadas ou para enviar dados como registros não estruturados ou eventos pré-formatados do Modelo Unificado de Dados (UDM, na sigla em inglês).

• Agente do Bindplane

  É possível implantar o agente Bindplane versátil 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 de armazenamento em nuvem específicos de terceiros (como o Amazon S3) ou APIs de terceiros (como o Okta ou o Microsoft 365).

Normalização e aprimoramento de dados

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

1. Análise e normalização

   Primeiro, um analisador 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 da nuvem) usando um esquema único e consistente. O registro bruto original permanece armazenado com o evento da 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 massivos, tornando os eventos do UDM pesquisáveis.

3. Pseudônimos e enriquecimento de UDM

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

4. Enriquecimento de ECG

   • O Google SecOps realiza aliasing 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 de 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 Google Threat Intelligence e 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 da UDM ficam imediatamente disponíveis para análise:

• Detecção em tempo real

  O Detection Engine executa automaticamente regras personalizadas e criadas pelo Google com a regra ativa em dados ativos recebidos 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, use 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, e cada um tem uma finalidade diferente.

Pesquisa do UDM

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 normalizados e indexados da UDM. Como todos os dados são analisados nesse formato padrão, você pode 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.

Pesquisa de registros brutos

Use a Pesquisa de registros brutos para encontrar algo na mensagem de registro original e não analisada que talvez não tenha sido mapeada para um campo de 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 arquivo ou endereços IP.

• O que ele pesquisa:ele verifica o texto original e bruto 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 de UDM indexados.
• Como funciona:você usa o prefixo raw =. Ela pode ser mais lenta do que a pesquisa do UDM porque não pesquisa campos indexados.
• Exemplo (string): raw = "PsExec.exe"
• Exemplo (regex): raw = /admin\$/

Pesquisa de estatísticas

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)

Com a pesquisa em linguagem natural (Gemini), você pode usar o inglês simples para fazer perguntas, que o Gemini traduz em uma consulta formal da UDM.

• O que ela pesquisa:oferece uma interface de conversa para consultar dados da UDM.
• Como funciona:você digita uma pergunta, e o Gemini gera a consulta de pesquisa UDM correspondente, que pode ser executada ou refinada.
• Exemplo: "Mostre todos os logins com falha do usuário 'bob' nas últimas 24 horas"

Pesquisa no SOAR

A pesquisa de SOAR é específica para componentes de SOAR. Ela é usada para gerenciar incidentes de segurança, não para procurar em registros.

• O que ele pesquisa:casos e entidades (como usuários, recursos, 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:pesquise CaseIds:180 ou AlertName:Brute Force.

Pipeline de ingestão de dados para pesquisar disponibilidade

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

1. Atraso na 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 agrupamento em lotes e dos cronogramas de publicação da API do sistema de origem. O Google SecOps não pode influenciar esse atraso. Por exemplo, 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 que o Google SecOps leva para processar os dados depois de recebê-los. 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 na fonte de dados

Os seguintes fatores podem influenciar o atraso na 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 ao tornar novos eventos consultáveis.
• Horário de criação e publicação do evento: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 disponibilizaçã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 métodos de ingestão, consulte Visão geral da ingestão de dados. A referência da API Feed Management descreve considerações específicas para tipos de registros, 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 tratamento dos dados recém-ingeridos por método de pesquisa. Os dados recém-ingeridos ficam disponíveis para pesquisa depois que essas etapas são concluídas.

Método de pesquisa	Dados pesquisados	Etapas de processamento que contribuem para o tempo de disponibilidade
Pesquisa do UDM Pesquisa em linguagem natural (Gemini)	Eventos de UDM normalizados e enriquecidos	Ingestão:o registro chega ao ponto de ingestão do Google SecOps. Análise:o registro bruto é identificado e processado pelo analisador específico. Normalização:os dados são extraídos e mapeados para o esquema do UDM. Indexação (UDM): o registro UDM normalizado é indexado para uma pesquisa rápida e estruturada. Enriquecimento:o contexto (inteligência contra ameaças, geolocalização, dados de usuários ou recursos) é adicionado.
Pesquisa de registro bruto	Texto do registro original e não analisado	Ingestão:o registro chega ao ponto de ingestão do Google SecOps.
Detection Engine (regras)	Eventos normalizados	Disponibilidade de eventos da UDM:siga as mesmas etapas listadas para a pesquisa da UDM. Avaliação de detecção:o mecanismo de regras avalia os registros em "microbatches", geralmente acionando detecções em 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 horário é baseado em: Disponibilidade de eventos da UDM:usa as mesmas etapas de processamento listadas para "Pesquisa de UDM". Detecção:uma regra do mecanismo de detecção precisa corresponder aos eventos da UDM. Geração de alertas:o sistema cria um alerta formal com base na detecção. Criação de caso: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, melhora e analisa seus dados de segurança, disponibilizando-os para pesquisas e análises adicionais.

Exemplo de etapas de tratamento 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 os 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 evento do Google SecOps, como a visualização de recursos, clique em Contexto do VT para conferir informações do Google Threat Intelligence. O Google SecOps não compartilha seus dados de segurança com o Google Threat Intelligence.

Exemplos do tempo esperado até a disponibilidade da Pesquisa

O tempo esperado até que os dados recém-ingeridos fiquem disponíveis para a 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 da UDM é de aproximadamente 5 minutos e 30 segundos desde o envio dos dados para o serviço de ingestão do Google SecOps.

Etapa de 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
Logs brutos para Analisar e validar	Analisa e valida registros brutos no formato UDM.	Menos de 3 minutos
Analisar e validar para Index	Indexa os dados analisados do UDM para uma 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 solução de problemas.

Latência e limites

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

• Visibilidade na pesquisa:de 2 a 15 minutos após a ingestão.
• Execução da regra:de 5 a 10 minutos após a chegada do evento.

Observação: para intervalos de pesquisa maiores que 30 dias, os eventos ingeridos recentemente podem levar mais tempo para aparecer. Para resultados quase em tempo real, selecione um período de 30 dias ou menos.

Observação: esses horários começam depois que o Google SecOps recebe os dados. A disponibilidade de dados de ponta a ponta também depende de atrasos originados na fonte de dados que ocorrem antes da entrada dos dados no pipeline do Google SecOps.

Atenção: se uma mudança não aparecer imediatamente na UI, isso não indica necessariamente uma falha de sincronização. Se o evento ocorreu há menos de 15 minutos para pesquisa ou 10 minutos para regras, os dados provavelmente ainda estão no pipeline de processamento padrão. O atraso não indica uma falha no sistema.

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