Présentation des tableaux de bord

Compatible avec :

Ce document fournit un guide technique pour utiliser le moteur de tableaux de bord Google Security Operations afin de créer des visualisations de données sur différents flux de télémétrie.

Le framework des tableaux de bord repose sur une architecture modulaire dans laquelle les widgets individuels (graphiques) interagissent avec des sources de données spécifiques à l'aide de la syntaxe YARA-L 2.0. En utilisant les propriétés de schéma et les fonctions d'agrégation YARA-L, vous pouvez créer des visualisations pour la surveillance en temps réel, l'analyse des menaces et l'audit opérationnel.

Pour une présentation détaillée de l'infrastructure de tableau de bord sous-jacente, consultez la présentation des tableaux de bord.

Avant de commencer

Vérifiez que votre instance Google SecOps répond aux exigences de configuration suivantes :

Autorisations IAM requises

Les autorisations suivantes sont requises pour accéder aux tableaux de bord :

Autorisation IAM Objectif
chronicle.nativeDashboards.list Affichez la liste de tous les tableaux de bord.
chronicle.nativeDashboards.get Afficher un tableau de bord, appliquer un filtre de tableau de bord et appliquer le filtre global.
chronicle.nativeDashboards.create Créer un tableau de bord
chronicle.nativeDashboards.duplicate Créer une copie d'un tableau de bord existant
chronicle.nativeDashboards.update Ajouter et modifier des graphiques, ajouter un filtre, modifier l'accès au tableau de bord et gérer le filtre de temps global.
chronicle.nativeDashboards.delete Supprimer un tableau de bord

Comprendre les tableaux de bord

Les tableaux de bord fournissent des informations sur les événements de sécurité, les détections et les données associées. Cette section présente les sources de données compatibles et explique comment le contrôle des accès basé sur les rôles (RBAC) affecte la visibilité et l'accès aux données dans les tableaux de bord.

Catalogue de tableaux de bord prédéfinis

Google Security Operations fournit des tableaux de bord organisés prêts à l'emploi, conçus pour offrir une visibilité sur différents cas d'utilisation de la sécurité. Vous ne pouvez pas modifier ni supprimer les tableaux de bord sélectionnés, mais vous pouvez en créer une copie et la personnaliser en fonction des besoins spécifiques de votre organisation.

Pour explorer tous les tableaux de bord prédéfinis disponibles, consulter la description de leurs graphiques et afficher les requêtes de recherche sous-jacentes pour chaque widget, consultez le catalogue de tableaux de bord prêts à l'emploi. Pour obtenir des informations opérationnelles sur les tableaux de bord prédéfinis courants, consultez Présentation des tableaux de bord sélectionnés courants.

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

Sources de données compatibles

Les tableaux de bord incluent les sources de données suivantes, chacune avec sa propre limite de temps de requête et son propre préfixe YARA-L :

Source de données Intervalle de temps de la requête Préfixe YARA-L Schéma Exemples de tableaux de bord
Historique de la demande 365 jours case_history Champs (SOAR) | Modèle Exemples
Cas et alertes 365 jours case Champs (SOAR) | Modèle Exemples
Tables de données Pas de limite de temps autonome (définie par la source de données associée) % Définie par l'utilisateur Exemples
Détections 365 jours detection Champs | Modèle Exemples
Graphique des entités 365 jours graph Champs | Modèle Exemples
Événements 90 jours no prefix Champs (UDM) | Modèle Exemples
Métriques d'ingestion 365 jours ingestion Champs | Modèle Exemples
IoCs 365 jours ioc Champs | Modèle Exemples
Playbooks 365 jours playbook Champs (SOAR) | Modèle Exemples
Ensembles de règles 365 jours ruleset Champs | Modèle Exemples
Règles Pas de limite de temps rules Champs | Modèle Exemples
Agent de tri et d'investigation 365 jours gemini_investigation, gemini_investigation_feedback Champs | Modèle Exemples

Impact du RBAC des données

Le contrôle des accès basé sur les rôles (RBAC) pour les données est un modèle de sécurité qui utilise les rôles des utilisateurs individuels pour restreindre leur accès aux données d'une organisation. Le RBAC des données permet aux administrateurs de définir des niveaux d'accès et de les attribuer aux utilisateurs, ce qui garantit que l'accès est limité aux seules données nécessaires à leurs fonctions. Toutes les requêtes dans les tableaux de bord suivent les règles de contrôle des accès basé sur les rôles pour les données. Pour en savoir plus sur les contrôles et les niveaux d'accès, consultez Contrôles et niveaux d'accès dans le RBAC des données. Pour en savoir plus sur le RBAC des données pour les tableaux de bord, consultez Configurer le RBAC des données pour les tableaux de bord.

Événements, graphique des entités et correspondances IoC

Les données renvoyées par ces sources sont limitées aux niveaux d'accès attribués à l'utilisateur, ce qui garantit qu'il ne voit que les résultats des données autorisées. Si un utilisateur dispose de plusieurs champs d'application, les requêtes incluent les données de tous les champs d'application attribués. Les données situées en dehors des champs d'application accessibles de l'utilisateur n'apparaissent pas dans les résultats de recherche du tableau de bord.

Règles

Les utilisateurs ne peuvent voir que les règles associées aux niveaux d'accès qui leur ont été attribués.

Détection et ensembles de règles avec détections

Les détections sont générées lorsque les données de sécurité entrantes correspondent aux critères définis dans une règle. Les utilisateurs ne peuvent voir que les détections provenant de règles associées aux champs d'application qui leur sont attribués. Les ensembles de règles avec des détections ne sont visibles que par les utilisateurs globaux.

Sources de données SOAR

Les tableaux de bord contenant des données SOAR, telles que les cas, l'historique des cas, les playbooks et les alertes, ne sont visibles que par les utilisateurs globaux.

Les tableaux de bord "Cas" et "Historique des cas" ne sont pas compatibles avec les mécanismes d'accès SOAR (comme les environnements et les rôles SOC). Un utilisateur autorisé à accéder aux tableaux de bord peut afficher les demandes dans tous les environnements et rôles SOC.

Métriques d'ingestion

Les composants d'ingestion sont des services ou des pipelines qui importent des journaux dans la plate-forme à partir de flux de journaux sources. Chaque composant collecte un ensemble spécifique de champs de journaux dans son propre schéma de métriques d'ingestion.

Les administrateurs peuvent utiliser le RBAC pour les métriques d'ingestion afin de limiter la visibilité des données sur l'état du système, telles que le volume d'ingestion, les erreurs et le débit, en fonction du champ d'activité d'un utilisateur.

Le tableau de bord "Ingestion et état des données" utilise des niveaux d'accès aux données. Lorsqu'un utilisateur limité charge le tableau de bord, le système filtre automatiquement les métriques pour n'afficher que les données correspondant aux libellés qui lui ont été attribués.

Vous pouvez filtrer les résultats à l'aide des libellés suivants :

  • Espace de noms : méthode principale de ségrégation (par exemple, Eu-Prod, Alpha-Corp).
  • Type de journal : ségrégation basée sur les rôles (par exemple, GCP_VPC_FLOW, CROWDSTRIKE_EDR).
  • Source d'ingestion : suivi précis des sources (par exemple, ID de l'expéditeur spécifique).

Types de journaux inattendus dans les métriques d'ingestion

Certains tableaux de bord peuvent afficher des entrées pour des types de journaux tels que UNSPECIFIED_LOG_TYPE ou des identifiants internes, y compris LT_X (où X est un nombre). Ces identifiants LT_X sont utilisés dans le système Google SecOps pour identifier de manière unique les types de journaux personnalisés créés par un client.

Ces entrées peuvent apparaître même si l'ingestion ou l'analyse complète des données pour ces types de journaux spécifiques n'a pas été effectuée correctement. Cela se produit, car certaines métriques système sont enregistrées, quel que soit l'état d'ingestion final.

Pour vous concentrer sur les données ingérées et analysées correctement, vous pouvez utiliser les fonctionnalités de filtrage de l'interface du tableau de bord afin d'exclure ou de filtrer spécifiquement UNSPECIFIED_LOG_TYPE et d'autres identifiants de types de journaux internes inattendus de vos vues.

Écarts entre le volume de journaux bruts et le volume de journaux du tableau de bord

Le total ingestion.log_volume affiché dans un graphique de tableau de bord (par exemple, une requête filtrant sur ingestion.component = "Ingestion API" pour les 365 derniers jours) peut différer de votre volume cumulé de journaux bruts pour les raisons suivantes :

  • Période et limites de période : l'interface Google SecOps n'affiche pas de compteur d'ingestion cumulée depuis la création de votre instance. Vous ne pouvez pas calculer un total cumulé au-delà de la limite de requête de 365 jours dans les tableaux de bord Google SecOps, même dans le graphique Ingestion – Débit (tous les jours). Pour les instances BYOP (Bring Your Own Project), vous pouvez interroger jusqu'à 24 mois de données dans Cloud Monitoring.
  • Source de données et pipeline : le volume de journaux bruts reflète la taille en octets des lots de journaux bruts stockés. Les tableaux de bord interrogent la table ingestion_metrics, qui collecte les données de télémétrie de manière asynchrone à des intervalles d'environ cinq minutes. Étant donné que le pipeline de métriques peut présenter une latence de collecte ou des baisses temporaires de métriques, considérez les totaux ingestion.log_volume du tableau de bord comme des indicateurs approximatifs plutôt que comme des nombres d'octets exacts. Pour savoir où calculer le volume d'ingestion et comment les valeurs diffèrent d'un outil à l'autre, consultez Où calculer le volume d'ingestion et comment les valeurs diffèrent.

Limites

  • Libellé personnalisé : l'attribution d'un champ d'application utilisateur contenant un libellé personnalisé (par exemple, un libellé créé à l'aide d'une expression régulière UDM ou de tables de données) désactive automatiquement le RBAC pour les métriques d'ingestion pour cet utilisateur. Par conséquent, l'utilisateur ne verra aucune donnée dans ses tableaux de bord. Pour les champs d'application de surveillance de l'ingestion, vous ne devez utiliser que des étiquettes standards telles que le type de journal, l'espace de noms et la source d'ingestion.

  • Limitation de la source d'ingestion : le filtrage par source d'ingestion ne s'applique qu'à la métrique "Nombre de journaux". Les graphiques affichant des métriques sur la bande passante (en octets) ou les taux d'erreur peuvent ne montrer aucune donnée s'ils sont filtrés strictement par source d'ingestion. Google recommande de filtrer par espace de noms pour une surveillance plus large de l'état.

Fonctionnalités avancées et surveillance

Pour affiner les détections et améliorer la visibilité, vous pouvez utiliser des configurations avancées, telles que les règles YARA-L 2.0 et les métriques d'ingestion. Cette section explore ces insights sur les fonctionnalités, ce qui vous aide à optimiser l'efficacité de la détection et à surveiller le traitement des données.

Propriétés YARA-L 2.0

YARA-L 2.0 possède les propriétés uniques suivantes lorsqu'il est utilisé dans des tableaux de bord :

  • Des sources de données supplémentaires, telles que le graphique des entités, les métriques d'ingestion, les ensembles de règles et les détections, sont disponibles dans les tableaux de bord. Certaines de ces sources de données ne sont pas encore disponibles dans les règles YARA-L et la recherche dans le modèle de données unifié (UDM).

  • Consultez Fonctions YARA-L 2.0 pour les tableaux de bord Google Security Operations et les fonctions d'agrégation qui incluent des mesures statistiques.

  • La requête YARA-L 2.0 doit contenir une section match ou outcome, ou les deux.

  • La section events d'une règle YARA-L est implicite et n'a pas besoin d'être déclarée dans les requêtes.

  • La section condition d'une règle YARA-L n'est pas disponible pour les tableaux de bord.

  • Les tableaux de bord ne sont pas compatibles avec les règles de la catégorie "Analyse des risques pour l'UEBA".

Vous avez encore besoin d'aide ? Obtenez des réponses de membres de la communauté et de professionnels Google SecOps.