Visão geral de painéis

Compatível com:

Este documento fornece um guia técnico para usar o mecanismo de painéis do Google Security Operations e criar visualizações de dados em fluxos de telemetria diferentes.

A estrutura de painéis é criada em uma arquitetura modular em que widgets individuais (gráficos) interagem com fontes de dados específicas usando a sintaxe YARA-L 2.0. Ao usar as propriedades de esquema e as funções de agregação da YARA-L, é possível criar visualizações para monitoramento em tempo real, análise de ameaças e auditoria operacional.

Para mais detalhes sobre a infraestrutura do painel, consulte a Visão geral dos painéis.

Antes de começar

Confirme se a instância do Google SecOps atende aos seguintes requisitos de configuração:

Permissões necessárias do IAM

As seguintes permissões são necessárias para acessar painéis:

Permissão do IAM Finalidade
chronicle.nativeDashboards.list Confira a lista de todos os painéis.
chronicle.nativeDashboards.get Ver um painel, aplicar um filtro de painel e aplicar o filtro global.
chronicle.nativeDashboards.create Crie um painel.
chronicle.nativeDashboards.duplicate Faça uma cópia de um painel atual.
chronicle.nativeDashboards.update Adicionar e editar gráficos, adicionar um filtro, mudar o acesso ao painel e gerenciar o filtro de período global.
chronicle.nativeDashboards.delete Excluir um painel.

Entender os painéis

Os painéis oferecem insights sobre eventos de segurança, detecções e dados relacionados. Esta seção descreve as fontes de dados compatíveis e explica como o controle de acesso baseado em função (RBAC) afeta a visibilidade e o acesso aos dados nos painéis.

  • investigation
  • response_platform_info
  • case_name
  • feedback_summary
  • feedback_history
  • soar_alert
  • soar_alert_metadata

Fontes de dados compatíveis

Os painéis incluem as seguintes fontes de dados, cada uma com o prefixo YARA-L correspondente:

Fonte de dados Intervalo de tempo da consulta Prefixo YARA-L Esquema Exemplos de painéis
Histórico do caso 365 dias case_history Campos (SOAR) | Modelo Exemplos
Casos e alertas 365 dias case Campos (SOAR) | Modelo Exemplos
Detecções 365 dias detection Campos | Modelo Exemplos
Gráfico de entidade 365 dias graph Campos | Modelo Exemplos
Eventos 90 dias no prefix Campos (UDM) | Modelo Exemplos
Métricas de ingestão 365 dias ingestion Campos | Modelo Exemplos
IoCs 365 dias ioc Campos | Modelo Exemplos
Playbooks 365 dias playbook Campos (SOAR) | Modelo Exemplos
Conjuntos de regras 365 dias ruleset Campos | Modelo Exemplos
Regras Sem limite de tempo rules Campos | Modelo Exemplos
Agente de triagem e investigação 366 dias gemini_investigation, gemini_investigation_feedback Campos | Modelo Exemplos

Impacto do RBAC de dados

O controle de acesso baseado em função (RBAC) de dados é um modelo de segurança que usa funções de usuário individuais para restringir o acesso aos dados em uma organização. Com o RBAC de dados, os administradores podem definir escopos e atribuí-los aos usuários, garantindo que o acesso seja limitado apenas aos dados necessários para as funções de trabalho. Todas as consultas nos painéis seguem as regras de RBAC de dados. Para mais informações sobre controles de acesso e escopos, consulte Controles de acesso e escopos no RBAC de dados. Para mais informações sobre o RBAC de dados para painéis, consulte Configurar o RBAC de dados para painéis.

Eventos, gráfico de entidades e correspondências de IOC

Os dados retornados dessas fontes são restritos aos escopos de acesso atribuídos ao usuário, garantindo que ele veja apenas resultados de dados autorizados. Se um usuário tiver vários escopos, as consultas vão incluir dados de todos os escopos atribuídos. Os dados fora dos escopos acessíveis ao usuário não aparecem nos resultados da pesquisa do painel.

Regras

Os usuários só podem ver regras associadas aos escopos atribuídos a eles.

Detecção e conjuntos de regras com detecções

As detecções são geradas quando os dados de segurança recebidos correspondem aos critérios definidos em uma regra. Os usuários só podem ver detecções originadas de regras associadas aos escopos atribuídos a eles. Os conjuntos de regras com detecções só ficam visíveis para usuários globais.

Fontes de dados do SOAR

Os casos e o histórico de casos oferecem suporte ao controle de acesso baseado em função (RBAC) e filtram automaticamente os dados de visualização para corresponder aos escopos de acesso a dados atribuídos a um usuário. Os playbooks e alertas permanecem visíveis apenas para usuários globais. Observação: a filtragem de RBAC se aplica estritamente a novos casos que contêm dados de escopo. Ela não se aplica de maneira retroativa a casos históricos que não têm dados de escopo.

Métricas de ingestão

Os componentes de ingestão são serviços ou pipelines que trazem registros para a plataforma de feeds de registros de origem. Cada componente coleta um conjunto específico de campos de registro no próprio esquema de métricas de ingestão.

Os administradores podem usar o controle de acesso baseado em função (RBAC) para métricas de ingestão e restringir a visibilidade dos dados de integridade do sistema, como volume de ingestão, erros e capacidade de processamento, com base no escopo comercial de um usuário.

O painel de ingestão de dados e saúde usa escopos de acesso a dados. Quando um usuário com escopo carrega o painel, o sistema filtra automaticamente as métricas para mostrar apenas os dados que correspondem aos rótulos atribuídos.

É possível filtrar usando os seguintes rótulos:

  • Namespace: o método principal de segregação (por exemplo, Eu-Prod, Alpha-Corp).
  • Tipo de registro: segregação com base em função (por exemplo, GCP_VPC_FLOW, CROWDSTRIKE_EDR).
  • Origem da ingestão: rastreamento granular da origem (por exemplo, ID de encaminhador específico).

Tipos de registros inesperados nas métricas de ingestão

Alguns painéis podem mostrar entradas para tipos de registros, como UNSPECIFIED_LOG_TYPE ou identificadores internos, incluindo LT_X (em que X é um número). Esses identificadores LT_X são usados no sistema do Google SecOps para identificar de forma exclusiva os tipos de registros personalizados criados por um cliente.

Essas entradas podem aparecer mesmo que a ingestão de dados ou análise completa para esses tipos de registros específicos não tenha sido concluída. Isso acontece porque algumas métricas do sistema são registradas independente do status final da ingestão.

Para se concentrar nos dados ingeridos e analisados com sucesso, use os recursos de filtragem na interface do painel para excluir ou filtrar especificamente UNSPECIFIED_LOG_TYPE e outros identificadores de tipo de registro interno inesperados das suas visualizações.

Limitações

  • Rótulo personalizado: atribuir um escopo de usuário que contenha um rótulo personalizado, como um rótulo criado usando uma expressão regular da UDM ou tabelas de dados, desativa automaticamente o RBAC para métricas de ingestão desse usuário. Como resultado, o usuário não vai ver nenhum dado nos painéis. Para escopos de monitoramento de ingestão, use apenas rótulos padrão, como tipo de registro, namespace e origem da ingestão.

  • Limitação da origem da ingestão: a filtragem por origem da ingestão se aplica apenas à métrica de contagem de registros. Os gráficos que mostram métricas de largura de banda (bytes) ou taxas de erro podem não exibir dados se forem filtrados estritamente por origem de ingestão. O Google recomenda filtrar por namespace para um monitoramento de integridade mais amplo.

Recursos avançados e monitoramento

Para ajustar as detecções e melhorar a visibilidade, use configurações avançadas, como regras do YARA-L 2.0 e métricas de ingestão. Esta seção explora esses insights de recursos, ajudando você a otimizar a eficiência da detecção e monitorar o processamento de dados.

Propriedades da YARA-L 2.0

O YARA-L 2.0 tem as seguintes propriedades exclusivas quando usado em painéis:

  • Outras fontes de dados, como gráfico de entidades, métricas de ingestão, conjuntos de regras e detecções, estão disponíveis nos painéis. Algumas dessas fontes de dados ainda não estão disponíveis nas regras da YARA-L e na pesquisa do Modelo de dados unificado (UDM).

  • Consulte Funções do YARA-L 2.0 para painéis do Google Security Operations e funções de agregação que incluem medidas estatísticas.

  • A consulta em YARA-L 2.0 precisa conter uma seção match ou outcome, ou ambas.

  • A seção events de uma regra da YARA-L é implícita e não precisa ser declarada em consultas.

  • A seção condition de uma regra da YARA-L não está disponível para dashboards.

  • Os painéis não são compatíveis com regras da categoria "Análise de risco para UEBA".

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