Dashboards overview

Supported in:

This document explains how to use the Dashboards feature of Google Security Operations to build visualizations over different data sources. It's composed of different charts, which are populated using YARA-L 2.0 properties.

Before you begin

Ensure that your Google SecOps instance has the following enabled:

IAM permissions required

The following permissions are required to access dashboards:

IAM permission Purpose
chronicle.nativeDashboards.list View the list of all dashboards.
chronicle.nativeDashboards.get View a dashboard, apply a dashboard filter, and apply the global filter.
chronicle.nativeDashboards.create Create a new dashboard.
chronicle.nativeDashboards.duplicate Make a copy of an existing dashboard.
chronicle.nativeDashboards.update Add and edit charts, add a filter, change dashboard access, and manage the global time filter.
chronicle.nativeDashboards.delete Delete a dashboard.

Understand dashboards

Dashboards provide insights into security events, detections, and related data. This section outlines the supported data sources and explains how role-based access control (RBAC) affects visibility and data access within the dashboards.

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

Data sources supported

Dashboards include the following data sources, each with its corresponding YARA-L prefix:

Data source Query time interval YARA-L prefix Schema
Events 90 days no prefix Fields
Entity graph 365 days graph Fields
Ingestion metrics 365 days ingestion Fields
Rule sets 365 days ruleset Fields
Detections 365 days detection Fields
IOCs 365 days ioc Fields
Rules No Time limit rules Fields
Cases and alerts 365 days case Fields
Playbook 365 days playbook Fields
Case history 365 days case_history Fields

Impact of data RBAC

Data role-based access control (RBAC) is a security model that uses individual user roles to restrict user access to data within an organization. Data RBAC lets administrators define scopes and assign them to users, ensuring access is limited to only the data necessary for their job functions. All queries in dashboards follow data RBAC rules. For more information about access controls and scopes, see Access controls and scopes in data RBAC. For more information about data RBAC for dashboards, see Configure data RBAC for dashboards

Events, entity graph, and IOC matches

The data returned from these sources is restricted to the user's assigned access scopes, ensuring that they only see results from authorized data. If a user has multiple scopes, queries include data from all assigned scopes. Data outside the user's accessible scopes doesn't appear in dashboard search results.

Rules

Users can only see rules that are associated with their assigned scopes.

Detection and rulesets with detections

Detections are generated when incoming security data matches the criteria defined in a rule. Users can only see detections that originate from rules associated with their assigned scopes. The rulesets with detections are only visible to global users.

SOAR data sources

Cases and alerts, playbooks, and case history are only visible to global users.

Ingestion metrics

Ingestion components are services or pipelines that bring logs into the platform from source log feeds. Each component collects a specific set of log fields within its own ingestion metrics schema.

Administrators can use RBAC for ingestion metrics to restrict visibility of system health data, such as ingestion volume, errors, and throughput, based on a user's business scope.

The Data Ingestion and Health dashboard uses Data Access scopes. When a scoped user loads the dashboard, the system automatically filters metrics to show only data that matches their assigned labels.

You can filter using the following labels:

  • Namespace: The primary method for segregation (for example, Eu-Prod, Alpha-Corp).
  • Log Type: Role-based segregation (for example, GCP_VPC_FLOW, CROWDSTRIKE_EDR).
  • Ingestion Source: Granular source tracking (for example, specific forwarder ID).

Limitations

  • Custom label: Assigning a user scope that contains a custom label—such as a label created using UDM regular expression or data tables—automatically disables RBAC for ingestion metrics for that user. As a result, the user won't see any data in their dashboards. For ingestion monitoring scopes, you must use only standard labels such as Log Type, Namespace, and Ingestion Source.

  • Ingestion source Limitation: Filtering by ingestion source applies only to the Log Count metric. Charts displaying bandwidth (bytes) or error rates metrics might show no data if filtered strictly by ingestion source. Google recommends filtering by Namespace for broader health monitoring.

Advanced features and monitoring

To fine-tune detections and improve visibility, you can use advanced configurations, such as YARA-L 2.0 rules and ingestion metrics. This section explores these feature insights, helping you optimize detection efficiency and monitor data processing.

YARA-L 2.0 properties

YARA-L 2.0 has the following unique properties when used in dashboards:

  • Additional data sources, such as entity graph, ingestion metrics, rule sets, and detections are available in dashboards. Some of these data sources are not yet available in YARA-L rules and Unified Data Model (UDM) search.

  • See YARA-L 2.0 functions for Google Security Operations dashboards and aggregate functions that include statistical measures.

  • The query in YARA-L 2.0 must contain a match or an outcome section, or both.

  • The events section of a YARA-L rule is implied and does not need to be declared in queries.

  • The condition section of a YARA-L rule is not available for dashboards.

Need more help? Get answers from Community members and Google SecOps professionals.