Cette page a été traduite par l'API Cloud Translation.

Examiner et contrer les menaces

Ce document fournit des conseils informels pour vous aider à examiner les résultats des activités suspectes dans votre environnement Google Cloud provenant d'acteurs potentiellement malveillants. Ce document fournit également des ressources supplémentaires pour mettre en contexte les résultats de Security Command Center. En suivant ces étapes, vous pouvez comprendre ce qui s'est passé lors d'une attaque potentielle et développer les réponses possibles pour les ressources affectées.

L'efficacité des techniques décrites sur cette page n'est pas garantie contre les menaces passées, actuelles ou futures. Pour savoir pourquoi Security Command Center ne fournit pas de conseils officiels pour la résolution des menaces, consultez la page Corriger les menaces.

Avant de commencer

Vous devez disposer des rôles IAM (Identity and Access Management) appropriés pour afficher ou modifier les résultats et les journaux, et pour modifier les ressources Google Cloud. Si vous rencontrez des erreurs d'accès dans Security Command Center, demandez de l'aide à votre administrateur et consultez la section Contrôle des accès pour en savoir plus sur les rôles. Pour résoudre les erreurs de ressources, consultez la documentation des produits concernés.

Comprendre les menaces détectées

Event Threat Detection génère des résultats de sécurité en faisant correspondre les événements de vos flux de journaux Cloud Logging aux indicateurs de compromission (IoC) connus. Les IoC, développés par des sources de sécurité internes de Google, identifient les failles et les attaques potentielles. Event Threat Detection détecte également les menaces en identifiant les tactiques, techniques et procédures antagonistes connues dans votre flux de journalisation, et en détectant les écarts par rapport au comportement passé de votre organisation ou de votre projet. Si vous activez le niveau Premium de Security Command Center au niveau de l'organisation, Event Threat Detection peut également analyser vos journaux Google Workspace.

Container Threat Detection génère des résultats en collectant et en analysant les comportements de bas niveau observés dans le noyau invité des conteneurs.

Les résultats sont écrits dans Security Command Center. Si vous activez le niveau Premium de Security Command Center au niveau de l'organisation, vous pouvez également configurer les résultats à écrire dans Cloud Logging.

Examiner les résultats

Pour examiner les résultats des menaces dans la console Google Cloud, procédez comme suit:

Dans la console Google Cloud, accédez à la page Résultats de Security Command Center.
Accéder
Si nécessaire, sélectionnez votre projet, votre dossier ou votre organisation Google Cloud.
Dans la section Filtres rapides, cliquez sur un filtre approprié pour afficher le résultat dont vous avez besoin dans le tableau Résultats de la requête de résultats. Par exemple, si vous sélectionnez Event Threat Detection ou Container Threat Detection dans la sous-section Nom à afficher pour la source, seuls les résultats du service sélectionné s'affichent dans les résultats.

Le tableau est rempli avec les résultats de la source sélectionnée.
Pour afficher les détails d'un résultat spécifique, cliquez sur le nom du résultat sous Category. Le volet de détails du résultat se développe pour afficher un résumé des détails du résultat.
Pour afficher la définition JSON du résultat, cliquez sur l'onglet JSON.

Les résultats fournissent les noms et les identifiants numériques des ressources impliquées dans un incident, ainsi que les variables d'environnement et les propriétés des éléments. Vous pouvez utiliser ces informations pour isoler rapidement les ressources concernées et déterminer le champ d'application potentiel d'un événement.

Pour faciliter votre enquête, les résultats de la détection de menaces contiennent également des liens vers les ressources externes suivantes :

Entrées du framework MITRE ATT&CK. Le framework décrit les techniques d'attaque contre les ressources cloud et fournit des conseils pour s'en protéger.
VirusTotal, un service appartenant à Alphabet qui fournit du contexte sur les fichiers, URL, domaines et adresses IP potentiellement malveillants. Le champ Indicateur VirusTotal, le cas échéant, fournit un lien vers VirusTotal pour vous aider à examiner plus en détail les problèmes de sécurité potentiels.

VirusTotal est une offre proposée à un prix distinct, avec des limites d'utilisation et des fonctionnalités différentes. Vous êtes tenu de comprendre et de respecter les règles d'utilisation des API de VirusTotal et les coûts associés. Pour en savoir plus, consultez la documentation VirusTotal.

Remarque :VirusTotal ne contient peut-être pas de hachages pour toutes les variantes de logiciels malveillants.

Les sections suivantes décrivent des réponses potentielles aux menaces détectées.

Désactivation des menaces détectées

Une fois que vous avez résolu un problème ayant déclenché une détection de menace, Security Command Center ne définit pas automatiquement l'état de la détection sur INACTIVE. L'état d'une menace détectée reste ACTIVE, sauf si vous définissez manuellement la propriété state sur INACTIVE.

En cas de faux positif, laissez l'état du résultat sur ACTIVE et ignorez-le.

Pour les faux positifs persistants ou récurrents, créez une règle de blocage. Définir une règle de masquage peut réduire le nombre de résultats que vous devez gérer, ce qui facilite l'identification d'une véritable menace lorsqu'elle se produit.

Pour une véritable menace, avant de définir l'état de la découverte sur INACTIVE, éliminez la menace et effectuez une enquête approfondie sur la menace détectée, l'étendue de l'intrusion et toute autre découverte et tout autre problème associé.

Pour désactiver un résultat ou modifier son état, consultez les articles suivants:

Réponses Event Threat Detection

Pour en savoir plus sur Event Threat Detection, consultez la section Fonctionnement d'Event Threat Detection.

Cette section ne contient pas de réponses aux résultats générés par les modules personnalisés pour Event Threat Detection, car votre organisation définit les actions recommandées pour ces détecteurs.

`Evasion: Access from Anonymizing Proxy`

Les accès anormaux d'un proxy anonyme sont détectés en consultant les journaux Cloud Audit pour examiner les modifications apportées aux services Google Cloud provenant d'adresses IP de proxy anonymes, telles que les adresses IP Tor.

Pour répondre à ces résultats, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez un résultat Evasion: Access from Anonymizing Proxy, comme indiqué dans la section Examiner les résultats. Le panneau des détails du résultat s'ouvre et affiche l'onglet Résumé.
Dans l'onglet Summary (Récapitulatif) du panneau "Finding details" (Détails des résultats), examinez les valeurs indiquées dans les sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Adresse e-mail principale: compte ayant effectué les modifications (compte potentiellement piraté).
  - IP: adresse IP du proxy à partir duquel les modifications sont effectuées.
- Ressource concernée
- Liens associés, en particulier les champs suivants :
  - URI Cloud Logging: lien vers les entrées de journalisation.
  - Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
  - Résultats associés: liens vers les résultats associés.
Vous pouvez également cliquer sur l'onglet JSON pour afficher d'autres champs de résultat.

Étape 2 : Étudier les méthodes d'attaque et de réponse

Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Proxy : proxy à sauts multiples.
Contactez le propriétaire du compte dans le champ principalEmail. Confirmez si l'action a été effectuée par le propriétaire légitime.
Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.

`Defense Evasion: Breakglass Workload Deployment Created`

Breakglass Workload Deployment Created est détecté en examinant Cloud Audit Logs pour voir s'il existe des déploiements sur des charges de travail qui utilisent l'indicateur breakglass pour ignorer les contrôles de l'autorisation binaire.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Defense Evasion: Breakglass Workload Deployment Created, comme indiqué dans la section Examiner les résultats. Le panneau des détails de la recherche s'ouvre et affiche l'onglet Récapitulatif.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Adresse e-mail principale: compte ayant effectué la modification.
  - Nom de la méthode: nom de la méthode appelée.
  - Pods Kubernetes: nom et espace de noms du pod.
- Ressource concernée, en particulier le champ suivant :
  - Nom à afficher de la ressource: espace de noms GKE où le déploiement s'est produit.
- Liens associés :
  - URI Cloud Logging: lien vers les entrées de journalisation.
  - Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
  - Résultats associés: liens vers les résultats associés.

Étape 2 : Vérifier les journaux

Dans l'onglet Récapitulatif des détails de la recherche dans la console Google Cloud, accédez à l'explorateur de journaux en cliquant sur le lien dans le champ URI Cloud Logging.
Vérifiez la valeur du champ protoPayload.resourceName pour identifier la demande de signature de certificat spécifique.
Recherchez d'autres actions effectuées par le principal à l'aide des filtres suivants:
- resource.labels.cluster_name="CLUSTER_NAME"
- protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
  
  Remplacez les éléments suivants :
- CLUSTER_NAME: valeur que vous avez indiquée dans le champ Nom à afficher de la ressource dans les détails de la recherche.
- PRINCIPAL_EMAIL: valeur que vous avez indiquée dans le champ Adresse e-mail principale des détails de la recherche.

Étape 3 : Rechercher des méthodes d'attaque et de réponse

Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Defense Evasion: Breakglass Workload Deployment.
Consultez les résultats associés en cliquant sur le lien Résultats associés sur la ligne Résultats associés dans l'onglet Récapitulatif des détails des résultats.
Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.

`Defense Evasion: Breakglass Workload Deployment Updated`

Breakglass Workload Deployment Updated est détecté en examinant Cloud Audit Logs pour voir s'il existe des mises à jour des charges de travail qui utilisent l'option "break-glass" pour ignorer les contrôles de l'autorisation binaire.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Defense Evasion: Breakglass Workload Deployment Updated, comme indiqué dans la section Examiner les résultats. Le panneau des détails de la recherche s'ouvre et affiche l'onglet Récapitulatif.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Adresse e-mail principale: compte ayant effectué la modification.
  - Nom de la méthode: nom de la méthode appelée.
  - Pods Kubernetes: nom et espace de noms du pod.
- Ressource concernée, en particulier le champ suivant :
  - Nom à afficher de la ressource: espace de noms GKE où la mise à jour s'est produite.
- Liens associés :
  - URI Cloud Logging: lien vers les entrées de journalisation.
  - Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
  - Résultats associés: liens vers les résultats associés.

Étape 2 : Vérifier les journaux

Dans l'onglet Récapitulatif des détails de la recherche dans la console Google Cloud, accédez à l'explorateur de journaux en cliquant sur le lien dans le champ URI Cloud Logging.
Vérifiez la valeur du champ protoPayload.resourceName pour identifier la demande de signature de certificat spécifique.
Recherchez d'autres actions effectuées par le principal à l'aide des filtres suivants:
- resource.labels.cluster_name="CLUSTER_NAME"
- protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
  
  Remplacez les éléments suivants :
- CLUSTER_NAME: valeur que vous avez indiquée dans le champ Nom à afficher de la ressource dans les détails de la recherche.
- PRINCIPAL_EMAIL: valeur que vous avez indiquée dans le champ Adresse e-mail principale des détails de la recherche.

Étape 3 : Rechercher des méthodes d'attaque et de réponse

Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Defense Evasion: Breakglass Workload Deployment.
Consultez les résultats associés en cliquant sur le lien Résultats associés sur la ligne Résultats associés dans l'onglet Récapitulatif des détails des résultats.
Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.

`Defense Evasion: Manually Deleted Certificate Signing Request (CSR)`

Une demande de signature de certificat (CSR) a été supprimée manuellement. Les CSR sont automatiquement supprimés par un contrôleur de récupération de mémoire, mais des acteurs malveillants peuvent les supprimer manuellement pour éviter d'être détectés. Si la requête de signature de certificat supprimée concernait un certificat approuvé et émis, l'acteur potentiellement malveillant dispose désormais d'une méthode d'authentification supplémentaire pour accéder au cluster. Les autorisations associées au certificat varient en fonction de l'objet qu'il inclut, mais peuvent être très privilégiées. Kubernetes n'est pas compatible avec la révocation de certificats. Pour en savoir plus, consultez le message de journal de cette alerte.

Examinez les journaux d'audit dans Cloud Logging et les alertes supplémentaires pour les autres événements liés à cette requête de signature de certificat (CSR) afin de déterminer si la requête a été approved et si la création de la requête était une activité attendue de la part du compte principal.
Déterminez s'il existe d'autres signes d'activité malveillante de la part du compte principal dans les journaux d'audit de Cloud Logging. Exemple :
- Le compte principal qui a supprimé la requête de signature de certificat est-il différent de celui qui l'a créée ou approuvée ?
- Le compte principal a-t-il essayé de demander, de créer, d'approuver ou de supprimer d'autres CSR ?
Si l'approbation d'une requête de signature de certificat n'était pas attendue ou si celle-ci est considérée comme malveillante, une rotation des identifiants du cluster est nécessaire pour invalider le certificat. Consultez les instructions pour effectuer une rotation des identifiants de votre cluster.

`Defense Evasion: Modify VPC Service Control`

Cette information n'est pas disponible pour les activations au niveau du projet.

Les journaux d'audit sont examinés afin de détecter les modifications apportées aux périmètres VPC Service Controls, ce qui entraînerait une réduction de la protection offerte par ce périmètre. Voici quelques exemples :

Un projet est supprimé d'un périmètre.
Une stratégie de niveau d'accès est ajoutée à un périmètre existant.
Un ou plusieurs services sont ajoutés à la liste des services accessibles.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Defense Evasion: Modify VPC Service Control, comme indiqué dans la section Examiner les résultats. Le panneau des détails de la recherche s'ouvre et affiche l'onglet Récapitulatif.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Risque détecté, en particulier le champ suivant :
  - Adresse e-mail principale: compte ayant effectué la modification.
- Ressource concernée, en particulier le champ suivant :
  - Nom complet de la ressource: nom du périmètre VPC Service Controls modifié.
- Liens associés :
  - URI Cloud Logging: lien vers les entrées de journalisation.
  - Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
  - Résultats associés: liens vers les résultats associés.
Cliquez sur l'onglet JSON.
Dans le fichier JSON, notez les champs suivants.
- sourceProperties
  - properties
    - name : nom du périmètre VPC Service Controls modifié.
    - policyLink : lien vers la règle d'accès qui contrôle le périmètre
    - delta: modifications, REMOVE ou ADD, d'un périmètre qui a réduit sa protection
    - restricted_resources : projets qui respectent les restrictions de ce périmètre. La protection est réduite si vous supprimez un projet
    - restricted_services : services dont l'exécution est interdite par les restrictions de ce périmètre. La protection est réduite si vous supprimez un service restreint
    - allowed_services : services autorisés à s'exécuter sous les restrictions de ce périmètre. La protection est réduite si vous ajoutez un service autorisé
    - access_levels : niveaux d'accès configurés pour autoriser l'accès aux ressources situées sous le périmètre La protection est réduite si vous ajoutez d'autres niveaux d'accès

Étape 2 : Vérifier les journaux

Dans l'onglet Récapitulatif du panneau "Détails du résultat", cliquez sur le lien URI Cloud Logging pour ouvrir l'explorateur de journaux.
Recherchez les journaux des activités d'administration liés aux modifications de VPC Service Controls à l'aide des filtres suivants :
- protoPayload.methodName:"AccessContextManager.UpdateServicePerimeter"
- protoPayload.methodName:"AccessContextManager.ReplaceServicePerimeters"

Étape 3 : Rechercher des méthodes d'attaque et de réponse

Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Defense Evasion : Modifier Authentication Process.
Consultez les résultats associés en cliquant sur le lien Résultats associés sur la ligne Résultats associés dans l'onglet Récapitulatif des détails des résultats.
Pour élaborer un plan de réponse, combinez les résultats de vos enquêtes avec la recherche MITRE.

Étape 4 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

Contactez le propriétaire de la règle et du périmètre VPC Service Controls.
Envisagez d'annuler les modifications du périmètre jusqu'à la fin de l'enquête.
Envisagez de révoquer les rôles Access Context Manager sur le compte principal qui a modifié le périmètre jusqu'à la fin de l'enquête.
Examinez comment les protections réduites ont été utilisées. Par exemple, si l'API BigQuery Data Transfer Service est activée ou ajoutée en tant que service autorisé, vérifiez qui a commencé à utiliser ce service et ce qu'il transfère.

`Defense Evasion: Potential Kubernetes Pod Masquerading`

Quelqu'un a déployé un pod avec une convention de nommage semblable aux charges de travail par défaut que GKE crée pour le fonctionnement normal du cluster. Cette technique est appelée masquage. Pour en savoir plus, consultez le message de journal de cette alerte.

Vérifiez que le pod est légitime.
Déterminez s'il existe d'autres signes d'activité malveillante de la part du pod ou du compte principal dans les journaux d'audit de Cloud Logging.
Si le compte principal n'est pas un compte de service (IAM ou Kubernetes), contactez le propriétaire du compte pour confirmer que ce propriétaire légitime est bien à l'origine de l'action.
Si le compte principal est un compte de service (IAM ou Kubernetes), identifiez la source de l'action pour déterminer sa légitimité.
Si le pod n'est pas légitime, supprimez-le, ainsi que toutes les liaisons RBAC et comptes de service associés utilisés par la charge de travail qui ont permis sa création.

`Discovery: Can get sensitive Kubernetes object check`

Une personne potentiellement malveillante a tenté d'identifier les objets sensibles dans GKE sur lesquels il peut effectuer des requêtes, à l'aide de la commande kubectl auth can-i get. Plus précisément, l'acteur a exécuté l'une des commandes suivantes:

kubectl auth can-i get '*'
kubectl auth can-i get secrets
kubectl auth can-i get clusterroles/cluster-admin

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Discovery: Can get sensitive Kubernetes object check comme indiqué dans la section Examiner les résultats.
Dans les détails du résultat, dans l'onglet Récapitulatif, notez les valeurs des champs suivants:
- Sous Ce qui a été détecté :
  - Examens d'accès Kubernetes: informations sur l'examen d'accès demandé, en fonction de la ressource k8s SelfSubjectAccessReview.
  - Adresse e-mail principale: compte à l'origine de l'appel.
- Sous Ressource affectée :
  - Nom à afficher de la ressource: cluster Kubernetes dans lequel l'action s'est produite.
- Sous Liens associés :
  - URI Cloud Logging: lien vers les entrées de journalisation.

Étape 2 : Vérifier les journaux

Dans l'onglet Récapitulatif du panneau "Détails du résultat", cliquez sur le lien URI Cloud Logging pour ouvrir l'explorateur de journaux.
Sur la page qui s'affiche, recherchez d'autres actions effectuées par le principal à l'aide des filtres suivants:
- resource.labels.cluster_name="CLUSTER_NAME"
- protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
  
  Remplacez les éléments suivants :
- CLUSTER_NAME: valeur que vous avez indiquée dans le champ Nom à afficher de la ressource dans les détails de la recherche.
- PRINCIPAL_EMAIL: valeur que vous avez indiquée dans le champ Adresse e-mail principale des détails de la recherche.

Étape 3 : Rechercher des méthodes d'attaque et de réponse

Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Découverte.
Vérifiez le degré de sensibilité de l'objet interrogé et déterminez s'il existe d'autres signes d'activité malveillante de la part du compte principal dans les journaux.
Si le compte que vous avez noté dans la ligne Adresse e-mail du compte principal dans les résultats détaillés n'est pas un compte de service, contactez le propriétaire du compte pour confirmer que ce propriétaire légitime est bien à l'origine de l'action.

Si l'adresse e-mail du compte principal est un compte de service (IAM ou Kubernetes), identifiez la source de l'examen d'accès pour déterminer sa légitimité.
Pour élaborer un plan d'intervention, combinez les résultats de vos enquêtes avec la recherche MITRE.

`Execution: Kubernetes Pod Created with Potential Reverse Shell Arguments`

Quelqu'un a créé un pod contenant des commandes ou des arguments couramment associés à un shell inversé. Les pirates informatiques utilisent des shells inversés pour étendre ou maintenir leur accès initial à un cluster et pour exécuter des commandes arbitraires. Pour en savoir plus, consultez le message de journal de cette alerte.

Vérifiez que le pod a une raison légitime de spécifier ces commandes et arguments.
Déterminez s'il existe d'autres signes d'activité malveillante de la part du pod ou du compte principal dans les journaux d'audit de Cloud Logging.
Si le compte principal n'est pas un compte de service (IAM ou Kubernetes), contactez le propriétaire du compte pour confirmer que ce propriétaire légitime est bien à l'origine de l'action.
Si le compte principal est un compte de service (IAM ou Kubernetes), assurez-vous de la légitimité de ce qui a amené le compte de service à effectuer cette action.
Si le pod n'est pas légitime, supprimez-le, ainsi que toutes les liaisons RBAC et comptes de service associés utilisés par la charge de travail qui ont permis sa création.

`Execution: Suspicious Exec or Attach to a System Pod`

Quelqu'un a utilisé les commandes exec ou attach pour obtenir un shell ou exécuter une commande sur un conteneur exécuté dans l'espace de noms kube-system. Ces méthodes sont parfois utilisées à des fins de débogage légitimes. Toutefois, kube-system namespace est destiné aux objets système créés par Kubernetes. L'exécution de commandes ou la création de shells inattendues doivent être examinées. Pour en savoir plus, consultez le message de journal de cette alerte.

Examinez les journaux d'audit dans Cloud Logging pour déterminer s'il s'agissait d'une activité attendue de la part du compte principal.
Déterminez s'il existe d'autres signes d'activité malveillante de la part du compte principal dans les journaux.

Consultez les conseils sur l'utilisation du principe du moindre privilège pour les rôles RBAC et les rôles de cluster ayant autorisé cet accès.

`Exfiltration: BigQuery Data Exfiltration`

Les résultats renvoyés par Exfiltration: BigQuery Data Exfiltration contiennent l'une des deux sous-règles possibles. Chaque sous-règle a une gravité différente:

Sous-règle exfil_to_external_table avec gravité = HIGH :
- Une ressource a été enregistrée en dehors de votre organisation ou de votre projet.
Sous-règle vpc_perimeter_violation avec gravité = LOW :
- VPC Service Controls a bloqué une opération de copie ou une tentative d'accès aux ressources BigQuery.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Exfiltration: BigQuery Data Exfiltration, comme indiqué dans la section Examiner les résultats.
Dans l'onglet Récapitulatif du panneau "Détails des résultats", examinez les valeurs indiquées dans les sections suivantes:
- Éléments détectés :
  - Gravité: la gravité est HIGH pour la sous-règle exfil_to_external_table ou LOW pour la sous-règle vpc_perimeter_violation.
  - Adresse e-mail principale: compte utilisé pour exfiltrer les données.
  - Sources d'exfiltration: détails sur les tables à partir desquelles les données ont été exfiltrées.
  - Cibles d'exfiltration: détails concernant les tables dans lesquelles les données exfiltrées ont été stockées.
- Ressource concernée :
  - Nom complet de la ressource: nom complet du projet, du dossier ou de l'organisation à partir desquels les données ont été exfiltrées.
- Liens associés :
  - URI Cloud Logging: lien vers les entrées de journalisation.
  - Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
  - Résultats associés: liens vers les résultats associés.
  - Chronicle: lien vers Google SecOps.
Cliquez sur l'onglet Propriétés sources et examinez les champs affichés, en particulier les suivants:
- detectionCategory :
  - subRuleName: exfil_to_external_table ou vpc_perimeter_violation.
- evidence :
  - sourceLogId :
    - projectId: projet Google Cloud contenant l'ensemble de données BigQuery source.
- properties
  - dataExfiltrationAttempt
    - jobLink: lien vers la tâche BigQuery qui a exfiltré des données.
    - query: requête SQL exécutée sur l'ensemble de données BigQuery.
Vous pouvez également cliquer sur l'onglet JSON pour obtenir la liste complète des propriétés JSON du résultat.

Étape 2: Analyser dans Google Security Operations

Vous pouvez utiliser Google Security Operations pour examiner ce résultat. Google SecOps est un service Google Cloud qui vous permet d'examiner les menaces et de parcourir les entités associées selon une chronologie unifiée. Google SecOps enrichit les données des résultats, ce qui vous permet d'identifier les indicateurs intéressants et de simplifier les enquêtes.

Vous ne pouvez utiliser Google SecOps que si vous activez Security Command Center au niveau de l'organisation.

Accédez à la page Résultats de Security Command Center dans Google Cloud Console.

Accéder
Dans le panneau Filtres rapides, faites défiler la page jusqu'à Nom à afficher pour la source.
Dans la section Nom à afficher pour la source, sélectionnez Event Threat Detection.

Les résultats d'Event Threat Detection sont insérés dans la table.
Dans le tableau, sous catégorie, cliquez sur un résultat Exfiltration: BigQuery Data Exfiltration. Le panneau des détails du résultat s'ouvre.
Dans la section Liens associés du panneau "Détails du résultat", cliquez sur Examiner dans Chronicle.
Suivez les instructions de l'interface utilisateur guidée de Google SecOps.

Utilisez les guides suivants pour mener des enquêtes dans Google SecOps:

Étape 3 : Vérifier les autorisations et les paramètres

Dans la console Google Cloud, accédez à la page IAM.

Accéder à IAM
Si nécessaire, sélectionnez le projet répertorié dans le champ projectId du fichier JSON des résultats.
Sur la page qui s'affiche, dans la zone Filtre, saisissez l'adresse e-mail répertoriée dans Adresse e-mail principale et vérifiez les autorisations attribuées au compte.

Étape 4 : Vérifier les journaux

Dans l'onglet Récapitulatif du panneau "Détails du résultat", cliquez sur le lien URI Cloud Logging pour ouvrir l'explorateur de journaux.
Recherchez les journaux d'activité d'administration liés aux tâches BigQuery à l'aide des filtres suivants:
- protoPayload.methodName="Jobservice.insert"
- protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"

Étape 5 : Étudier les méthodes d'attaque et de réponse

Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Exfiltration over Web Service: Exfiltration to Cloud Storage (Exfiltration via service Web : Exfiltration vers Cloud Storage).
Consultez les résultats associés en cliquant sur le lien Résultats associés sur la ligne Résultats associés dans l'onglet Récapitulatif des détails des résultats. Les résultats associés sont du même type de résultat, sur la même instance et sur le même réseau.
Pour élaborer un plan de réponse, combinez les résultats de vos enquêtes avec la recherche MITRE.

Étape 6 : Mettre en œuvre votre réponse

Contactez le propriétaire du projet contenant les données exfiltrées.
Envisagez de révoquer les autorisations pour userEmail jusqu'à ce que l'enquête soit terminée.
Pour mettre fin à une exfiltration plus approfondie, ajoutez des stratégies IAM restrictives aux ensembles de données BigQuery concernés (exfiltration.sources et exfiltration.targets).
Pour rechercher des informations sensibles dans les ensembles de données concernés, utilisez la protection des données sensibles. Vous pouvez également envoyer des données de protection des données sensibles à Security Command Center. Selon la quantité d'informations, les coûts liés à la protection des données sensibles peuvent être importants. Suivez les bonnes pratiques pour contrôler les coûts liés à la protection des données sensibles.
Pour limiter l'accès à l'API BigQuery, utilisez VPC Service Controls.
Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

`Exfiltration: BigQuery Data Extraction`

L'exfiltration de données de BigQuery est détectée en examinant les journaux d'audit pour deux scénarios :

Une ressource est enregistrée dans un bucket Cloud Storage extérieur à votre organisation.
Une ressource est enregistrée dans un bucket Cloud Storage accessible au public et appartenant à votre organisation.

Pour les activations au niveau du projet du niveau Premium de Security Command Center, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez un résultat Exfiltration: BigQuery Data Extraction, comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Récapitulatif.
Dans l'onglet Summary (Récapitulatif) du panneau "Finding details" (Détails du résultat), examinez les valeurs indiquées dans les sections suivantes:
- Éléments détectés :
  - Adresse e-mail principale: compte utilisé pour exfiltrer les données.
  - Sources d'exfiltration: détails sur les tables à partir desquelles les données ont été exfiltrées.
  - Cibles d'exfiltration: détails concernant les tables dans lesquelles les données exfiltrées ont été stockées.
- Ressource concernée :
  - Nom complet de la ressource: nom de la ressource BigQuery dont les données ont été exfiltrées.
  - Nom complet du projet: projet Google Cloud contenant l'ensemble de données BigQuery source.
- Liens associés :
  - URI Cloud Logging: lien vers les entrées de journalisation.
  - Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
  - Résultats associés: liens vers les résultats associés.
Dans le panneau des détails du résultat, cliquez sur l'onglet JSON.
Dans le fichier JSON, notez les champs suivants.
- sourceProperties :
  - evidence :
    - sourceLogId :
    - projectId: projet Google Cloud contenant l'ensemble de données BigQuery source.
  - properties :
    - extractionAttempt :
    - jobLink: lien vers la tâche BigQuery qui exfiltre des données.

Étape 2 : Vérifier les autorisations et les paramètres

Dans la console Google Cloud, accédez à la page IAM.

Accéder à IAM
Si nécessaire, sélectionnez le projet répertorié dans le champ projectId du fichier JSON de résultat (à partir de l'étape 1).
Sur la page qui s'affiche, dans la zone Filtre, saisissez l'adresse e-mail répertoriée dans Adresse e-mail principale (à l'étape 1) et vérifiez quelles autorisations sont attribuées au compte.

Étape 3 : Vérifier les journaux

Dans l'onglet Récapitulatif du panneau "Détails du résultat", cliquez sur le lien URI Cloud Logging pour ouvrir l'explorateur de journaux.
Recherchez les journaux d'activité d'administration liés aux tâches BigQuery à l'aide des filtres suivants :
- protoPayload.methodName="Jobservice.insert"
- protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"

Étape 4 : Rechercher des méthodes d'attaque et de réponse

Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Exfiltration over Web Service: Exfiltration to Cloud Storage (Exfiltration via service Web : Exfiltration vers Cloud Storage).
Consultez les résultats associés en cliquant sur le lien de la ligne Résultats associés dans l'onglet Récapitulatif des détails des résultats. Les résultats associés sont du même type de résultat, sur la même instance et sur le même réseau.
Pour élaborer un plan de réponse, combinez les résultats de vos enquêtes avec la recherche MITRE.

Étape 5 : Mettre en œuvre votre réponse

Contactez le propriétaire du projet contenant les données exfiltrées.
Envisagez de révoquer les autorisations du compte principal indiqué sur la ligne Adresse e-mail principale dans l'onglet Récapitulatif des détails du résultat jusqu'à la fin de l'enquête.
Pour mettre fin à toute exfiltration, ajoutez des stratégies IAM restrictives aux ensembles de données BigQuery concernés, qui sont identifiés dans le champ Sources d'exfiltration de l'onglet Récapitulatif des détails des résultats.
Pour rechercher des informations sensibles dans les ensembles de données concernés, utilisez la protection des données sensibles. Vous pouvez également envoyer des données de protection des données sensibles à Security Command Center. Selon la quantité d'informations, les coûts liés à la protection des données sensibles peuvent être importants. Suivez les bonnes pratiques pour contrôler les coûts liés à la protection des données sensibles.
Pour limiter l'accès à l'API BigQuery, utilisez VPC Service Controls.
Si vous êtes le propriétaire du bucket, envisagez de révoquer les autorisations d'accès public.
Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

`Exfiltration: BigQuery Data to Google Drive`

L'exfiltration de données de BigQuery est détectée en examinant les journaux d'audit pour le scénario suivant :

Une ressource est enregistrée dans un dossier Google Drive.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez un résultat Exfiltration: BigQuery Data to Google Drive, comme indiqué dans la section Examiner les résultats.
Dans l'onglet Récapitulatif du panneau "Détails du résultat", examinez les informations des sections suivantes:
- Ce qui a été détecté, y compris :
  - Adresse e-mail principale: compte utilisé pour exfiltrer les données.
  - Sources d'exfiltration: informations sur la table BigQuery à partir de laquelle les données ont été exfiltrées.
  - Cibles d'exfiltration: informations sur la destination dans Google Drive.
- Ressource concernée, y compris :
  - Nom complet de la ressource: nom de la ressource BigQuery dont les données ont été exfiltrées.
  - Nom complet du projet: projet Google Cloud contenant l'ensemble de données BigQuery source.
- Liens associés, y compris :
  - URI Cloud Logging: lien vers les entrées de journalisation.
  - Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
  - Résultats associés: liens vers les résultats associés.
Pour en savoir plus, cliquez sur l'onglet JSON.
Dans le fichier JSON, notez les champs suivants.
- sourceProperties :
  - evidence :
    - sourceLogId :
    - projectId: projet Google Cloud contenant l'ensemble de données BigQuery source.
  - properties :
    - extractionAttempt :
    - jobLink : lien vers la tâche BigQuery qui exfiltre des données.

Étape 2 : Vérifier les autorisations et les paramètres

Dans la console Google Cloud, accédez à la page IAM.

Accéder à IAM
Si nécessaire, sélectionnez le projet répertorié dans le champ projectId du fichier JSON de résultat (à partir de l'étape 1).
Sur la page qui s'affiche, dans la zone Filtre, saisissez l'adresse e-mail répertoriée dans access.principalEmail (à l'étape 1) et vérifiez quelles autorisations sont attribuées au compte.

Étape 3 : Vérifier les journaux

Dans l'onglet Récapitulatif du panneau "Détails du résultat", cliquez sur le lien URI Cloud Logging pour ouvrir l'explorateur de journaux.
Recherchez les journaux d'activité d'administration liés aux tâches BigQuery à l'aide des filtres suivants :
- protoPayload.methodName="Jobservice.insert"
- protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"

Étape 4 : Rechercher des méthodes d'attaque et de réponse

Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Exfiltration over Web Service: Exfiltration to Cloud Storage (Exfiltration via service Web : Exfiltration vers Cloud Storage).
Consultez les résultats associés en cliquant sur le lien Résultats associés sur la ligne Résultats associés dans l'onglet Récapitulatif des détails des résultats. Les résultats associés sont du même type de résultat, sur la même instance et sur le même réseau.
Pour élaborer un plan de réponse, combinez les résultats de vos enquêtes avec la recherche MITRE.

Étape 5 : Mettre en œuvre votre réponse

Contactez le propriétaire du projet contenant les données exfiltrées.
Envisagez de révoquer des autorisations du compte principal dans le champ access.principalEmail jusqu'à la fin de l'enquête.
Pour mettre fin à une exfiltration plus approfondie, ajoutez des stratégies IAM restrictives aux ensembles de données BigQuery concernés (exfiltration.sources).
Pour rechercher des informations sensibles dans les ensembles de données concernés, utilisez la protection des données sensibles. Vous pouvez également envoyer des données de protection des données sensibles à Security Command Center. Selon la quantité d'informations, les coûts liés à la protection des données sensibles peuvent être importants. Suivez les bonnes pratiques pour contrôler les coûts liés à la protection des données sensibles.
Pour limiter l'accès à l'API BigQuery, utilisez VPC Service Controls.
Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

`Exfiltration: Cloud SQL Data Exfiltration`

Il est possible de détecter une exfiltration de données de Cloud SQL en recherchant dans les journaux d'audit deux scénarios différents :

Données d'instance actives exportées vers un bucket Cloud Storage en dehors de l'organisation.
Données d'instance actives exportées vers un bucket Cloud Storage appartenant à l'organisation, mais accessible au public.

Tous les types d'instances Cloud SQL sont compatibles.

Pour les activations au niveau du projet du niveau Premium de Security Command Center, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez un résultat Exfiltration: Cloud SQL Data Exfiltration, comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Récapitulatif.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Adresse e-mail principale : compte utilisé pour exfiltrer les données.
  - Sources d'exfiltration: détails sur l'instance Cloud SQL dont les données ont été exfiltrées.
  - Cibles d'exfiltration: informations sur le bucket Cloud Storage vers lequel les données ont été exportées.
- Ressource concernée, en particulier les champs suivants :
  - Nom complet de la ressource: nom de la ressource Cloud SQL dont les données ont été exfiltrées.
  - Nom complet du projet: projet Google Cloud contenant les données Cloud SQL sources.
- Liens associés, y compris :
  - URI Cloud Logging: lien vers les entrées de journalisation.
  - Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
  - Résultats associés: liens vers les résultats associés.
Cliquez sur l'onglet JSON.
Dans le fichier JSON de la détection, notez les champs suivants:
- sourceProperties :
  - evidence :
  - sourceLogId :
    - projectId: projet Google Cloud contenant l'instance Cloud SQL source.
  - properties
  - bucketAccess : indique si le bucket Cloud Storage est accessible au public ou externe à l'organisation.
  - exportScope: quantité de données exportées (l'instance entière, une ou plusieurs bases de données, une ou plusieurs tables, ou un sous-ensemble spécifié par une requête).

Étape 2 : Vérifier les autorisations et les paramètres

Dans la console Google Cloud, accédez à la page IAM.

Accéder à IAM
Si nécessaire, sélectionnez le projet de l'instance répertoriée dans le champ projectId du fichier JSON du résultat (à partir de l'étape 1).
Sur la page qui s'affiche, dans la zone Filtre, saisissez l'adresse e-mail indiquée sur la ligne Adresse e-mail principale de l'onglet Récapitulatif des détails du résultat (à partir de l'étape 1). Vérifiez les autorisations attribuées au compte.

Étape 3 : Vérifier les journaux

Dans la console Google Cloud, accédez à l'explorateur de journaux en cliquant sur le lien dans URI de journalisation Cloud (étape 1). La page Explorateur de journaux inclut tous les journaux liés à l'instance Cloud SQL concernée.

Étape 4 : Rechercher des méthodes d'attaque et de réponse

Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Exfiltration over Web Service: Exfiltration to Cloud Storage (Exfiltration via service Web : Exfiltration vers Cloud Storage).
Examinez les résultats associés en cliquant sur le lien de la ligne Résultats associés décrite à l'étape 1. Le type des résultats associés est le même, sur la même instance Cloud SQL.
Pour élaborer un plan de réponse, combinez les résultats de vos enquêtes avec la recherche MITRE.

Étape 5 : Mettre en œuvre votre réponse

Contactez le propriétaire du projet contenant les données exfiltrées.
Envisagez de révoquer les autorisations pour access.principalEmail jusqu'à ce que l'enquête soit terminée.
Pour mettre fin à toute exfiltration, ajoutez des stratégies IAM restrictives sur les instances Cloud SQL concernées.
Pour limiter l'accès à l'API Cloud SQL Admin et au module d'exportation, utilisez VPC Service Controls.
Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

`Exfiltration: Cloud SQL Restore Backup to External Organization`

L'exfiltration de données d'une sauvegarde Cloud SQL est détectée en examinant les journaux d'audit pour déterminer si les données de la sauvegarde ont été restaurées sur une instance Cloud SQL en dehors de l'organisation ou du projet. Tous les types d'instance et de sauvegarde Cloud SQL sont compatibles.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez un résultat Exfiltration: Cloud SQL Restore Backup to External Organization, comme indiqué dans la section Examiner les résultats.
Dans l'onglet Récapitulatif du volet "Détails du résultat", examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Adresse e-mail principale: compte utilisé pour exfiltrer les données.
  - Sources d'exfiltration: détails sur l'instance Cloud SQL à partir de laquelle la sauvegarde a été créée.
  - Cibles d'exfiltration: détails sur l'instance Cloud SQL dans laquelle les données de sauvegarde ont été restaurées.
- Ressource concernée, en particulier les champs suivants :
  - Nom complet de la ressource: nom de la ressource de la sauvegarde restaurée.
  - Nom complet du projet: projet Google Cloud contenant l'instance Cloud SQL à partir de laquelle la sauvegarde a été créée.
Liens associés, en particulier les champs suivants:
- URI Cloud Logging: lien vers les entrées de journalisation.
- Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
- Résultats associés: liens vers les résultats associés.
Cliquez sur l'onglet JSON.
Dans le fichier JSON, notez les champs suivants.
- resource :
  - parent_name : nom de ressource de l'instance Cloud SQL à partir de laquelle la sauvegarde a été créée
- evidence :
  - sourceLogId :
    - projectId: projet Google Cloud contenant l'ensemble de données BigQuery source.
- properties :
  - restoreToExternalInstance :
    - backupId : ID de l'exécution de sauvegarde qui a été restaurée

Étape 2 : Vérifier les autorisations et les paramètres

Dans la console Google Cloud, accédez à la page IAM.

Accéder à IAM
Si nécessaire, sélectionnez le projet de l'instance listée dans le champ projectId du fichier JSON du résultat (à partir de l'étape 1).
Sur la page qui s'affiche, dans la zone Filtre, saisissez l'adresse e-mail indiquée dans Adresse e-mail principale (à l'étape 1) et vérifiez quelles autorisations sont attribuées au compte.

Étape 3 : Vérifier les journaux

Dans la console Google Cloud, accédez à l'explorateur de journaux en cliquant sur le lien dans URI de journalisation Cloud (étape 1). La page Explorateur de journaux inclut tous les journaux liés à l'instance Cloud SQL concernée.

Étape 4 : Rechercher des méthodes d'attaque et de réponse

Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Exfiltration over Web Service: Exfiltration to Cloud Storage (Exfiltration via service Web : Exfiltration vers Cloud Storage).
Consultez les résultats associés en cliquant sur le lien de la ligne Résultats associés. (à partir de l'étape 1). Le type des résultats associés est le même, sur la même instance Cloud SQL.
Pour élaborer un plan de réponse, combinez les résultats de vos enquêtes avec la recherche MITRE.

Étape 5 : Mettre en œuvre votre réponse

Contactez le propriétaire du projet contenant les données exfiltrées.
Envisagez de révoquer les autorisations du compte principal indiqué sur la ligne Adresse e-mail principale dans l'onglet Récapitulatif des détails du résultat jusqu'à la fin de l'enquête.
Pour mettre fin à toute exfiltration, ajoutez des stratégies IAM restrictives sur les instances Cloud SQL concernées.
Pour limiter l'accès à l'API Cloud SQL Admin, utilisez VPC Service Controls.
Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

`Exfiltration: Cloud SQL Over-Privileged Grant`

Détecte lorsque tous les droits associés à une base de données PostgreSQL (ou toutes les fonctions ou procédures d'une base de données) sont accordés à un ou plusieurs utilisateurs de la base de données.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Exfiltration: Cloud SQL Over-Privileged Grant, comme indiqué dans la section Examiner les résultats.
Dans l'onglet Résumé du panneau "Détails du résultat", examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Nom à afficher de la base de données: nom de la base de données de l'instance Cloud SQL PostgreSQL affectée.
  - Nom d'utilisateur de la base de données: utilisateur PostgreSQL ayant accordé des droits en excès.
  - Requête de base de données: requête PostgreSQL exécutée ayant accordé les droits.
  - Bénéficiaires de la base de données: bénéficiaires des droits trop larges.
- Ressource concernée, en particulier les champs suivants :
  - Nom complet de la ressource: nom de la ressource de l'instance Cloud SQL PostgreSQL affectée.
  - Nom complet du parent: nom de la ressource de l'instance Cloud SQL PostgreSQL.
  - Nom complet du projet: projet Google Cloud contenant l'instance PostgreSQL Cloud SQL.
- Liens associés, en particulier les champs suivants :
  - URI Cloud Logging: lien vers les entrées de journalisation.
  - Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
  - Résultats associés: liens vers les résultats associés.
Pour afficher le code JSON complet du résultat, cliquez sur l'onglet JSON.

Étape 2 : Vérifier les droits associés à la base de données

Connectez-vous à la base de données PostgreSQL.
Regroupez et affichez les droits d'accès pour les éléments suivants :
- Bases de données. Utilisez la métacommande \l ou \list et vérifiez les droits attribués à la base de données répertoriée dans Database display name (Nom à afficher de la base de données) (voir Étape 1).
- Fonctions ou procédures. Utilisez la métacommande \df et vérifiez les privilèges attribués aux fonctions ou procédures dans la base de données spécifiée dans Nom à afficher de la base de données (voir Étape 1).

Étape 3 : Vérifier les journaux

Dans la console Google Cloud, accédez à l'explorateur de journaux en cliquant sur le lien dans URI de journalisation Cloud (étape 1). La page Explorateur de journaux inclut tous les journaux liés à l'instance Cloud SQL concernée.
Dans l'explorateur de journaux, vérifiez les journaux pgaudit PostgreSQL, qui enregistrent les requêtes exécutées dans la base de données, à l'aide des filtres suivants :
- protoPayload.request.database="var class="edit">database"

Étape 4 : Rechercher des méthodes d'attaque et de réponse

Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Exfiltration over Web Service (Exfiltration via service Web).
Pour déterminer si d'autres mesures correctives sont nécessaires, combinez vos résultats d'enquête avec la recherche MITRE.

Étape 5 : Mettre en œuvre votre réponse

Contactez le propriétaire de l'instance disposant d'autorisations excessives.
Envisagez de révoquer toutes les autorisations des bénéficiaires listés dans Bénéficiaires de la base de données jusqu'à ce que l'enquête soit terminée.
Pour limiter l'accès à la base de données (à partir de l'élément Database display name (Nom à afficher de la base de données) de l'Étape 1, révoquez les autorisations inutiles accordées par les bénéficiaires (à partir de l'élément Database grantees (Bénéficiaires de la base de données) de l'Étape 1.

`Initial Access: Database Superuser Writes to User Tables`

Détecte quand le compte super-utilisateur de la base de données Cloud SQL (postgres pour PostgreSQL et root pour MySQL) écrit dans des tables utilisateur. Le super-utilisateur (un rôle disposant d'un accès très étendu) ne doit généralement pas être utilisé pour écrire dans les tables utilisateur. Un compte utilisateur à accès plus limité doit être utilisé pour les activités quotidiennes normales. Lorsqu'un super-utilisateur écrit dans une table utilisateur, cela peut indiquer qu'un pirate informatique a élevé ses privilèges ou compromis l'utilisateur de base de données par défaut, et qu'il est en train de modifier des données. Il peut également indiquer des pratiques normales, mais non sécurisées.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez un résultat Initial Access: Database Superuser Writes to User Tables, comme indiqué dans la section Examiner les résultats.
Dans l'onglet Récapitulatif du panneau "Détails du résultat", consultez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Nom à afficher de la base de données: nom de la base de données de l'instance Cloud SQL PostgreSQL ou MySQL affectée.
  - Nom d'utilisateur de la base de données: super-utilisateur.
  - Requête de base de données: requête SQL exécutée lors de l'écriture dans les tables utilisateur.
- Ressource concernée, en particulier les champs suivants :
  - Nom complet de la ressource: nom de la ressource de l'instance Cloud SQL concernée.
  - Nom complet parent: nom de la ressource de l'instance Cloud SQL.
  - Nom complet du projet: projet Google Cloud contenant l'instance Cloud SQL.
- Liens associés, en particulier les champs suivants :
  - URI Cloud Logging: lien vers les entrées de journalisation.
  - Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
  - Résultats associés: liens vers les résultats associés.
Pour afficher le code JSON complet du résultat, cliquez sur l'onglet JSON.

Étape 2 : Vérifier les journaux

Dans la console Google Cloud, accédez à l'explorateur de journaux en cliquant sur le lien figurant dans cloudLoggingQueryURI (étape 1). La page Explorateur de journaux inclut tous les journaux liés à l'instance Cloud SQL concernée.
Recherchez les journaux pgaudit PostgreSQL ou les journaux d'audit Cloud SQL pour MySQL, qui contiennent les requêtes exécutées par le super-utilisateur, à l'aide des filtres suivants :
- protoPayload.request.user="SUPERUSER"

Étape 3 : Rechercher des méthodes d'attaque et de réponse

Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Exfiltration over Web Service (Exfiltration via service Web).
Pour déterminer si d'autres mesures correctives sont nécessaires, combinez vos résultats d'enquête avec la recherche MITRE.

Étape 4 : Mettre en œuvre votre réponse

Examinez les utilisateurs autorisés à se connecter à la base de données.
- Pour PostgreSQL, consultez la section Créer et gérer des utilisateurs.
- Pour MySQL, consultez la section Gérer les utilisateurs avec l'authentification intégrée.
Envisagez de modifier le mot de passe du super-utilisateur.
- Pour PostgreSQL, consultez Définir le mot de passe de l'utilisateur par défaut.
- Pour MySQL, consultez Définir le mot de passe de l'utilisateur par défaut.
Envisagez de créer un utilisateur à accès limité pour les différents types de requêtes utilisés sur l'instance.
- N'accordez au nouvel utilisateur que les autorisations nécessaires pour exécuter ses requêtes.
  - Pour PostgreSQL, consultez Grant (commande).
  - Pour MySQL, consultez la section Contrôle des accès et gestion des comptes.
- Mettre à jour les identifiants des clients qui se connectent à l'instance Cloud SQL

`Initial Access: Anonymous GKE resource created from the internet`

Détecte lorsqu'un acteur potentiellement malveillant a utilisé l'un des utilisateurs ou groupes d'utilisateurs par défaut Kubernetes suivants pour créer une ressource Kubernetes dans le cluster:

system:anonymous
system:authenticated
system:unauthenticated

Ces utilisateurs et groupes sont en fait anonymes. Une liaison RBAC (contrôle des accès basé sur les rôles) dans votre cluster a accordé à cet utilisateur l'autorisation de créer ces ressources dans le cluster.

Examinez la ressource créée et la liaison RBAC associée pour vous assurer qu'elle est nécessaire. Si la liaison n'est pas nécessaire, supprimez-la. Pour en savoir plus, consultez le message de journal associé à cette observation.

Pour atténuer ce problème, consultez la section Éviter les rôles et les groupes par défaut.

`Initial Access: GKE resource modified anonymously from the internet`

Détecte lorsqu'un acteur potentiellement malveillant a utilisé l'un des utilisateurs ou groupes d'utilisateurs par défaut Kubernetes suivants pour modifier une ressource Kubernetes dans le cluster:

system:anonymous
system:authenticated
system:unauthenticated

Ces utilisateurs et groupes sont en fait anonymes. Une liaison RBAC (contrôle des accès basé sur les rôles) dans votre cluster a accordé à cet utilisateur l'autorisation de modifier ces ressources dans le cluster.

Examinez la ressource modifiée et la liaison RBAC associée pour vous assurer que la liaison est nécessaire. Si la liaison n'est pas nécessaire, supprimez-la. Pour en savoir plus, consultez le message de journal associé à cette observation.

Pour atténuer ce problème, consultez la section Éviter les rôles et les groupes par défaut.

`Initial Access: Dormant Service Account Action`

Détecte les événements où un compte de service géré par l'utilisateur dormant a déclenché une action. Dans ce contexte, un compte de service est considéré comme dormant s'il est inactif depuis plus de 180 jours.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Initial Access: Dormant Service Account Action, comme indiqué dans la section Examiner les résultats.
Dans les détails du résultat, dans l'onglet Récapitulatif, notez les valeurs des champs suivants.

Sous Risque détecté:
- Adresse e-mail principale: compte de service inactif ayant effectué l'action
- Nom du service: nom de l'API du service Google Cloud auquel le compte de service a accédé
- Nom de la méthode: nom de la méthode appelée.

Étape 2 : Étudier les méthodes d'attaque et de réponse

Utilisez des outils de compte de service, comme Activity Analyzer, pour examiner l'activité du compte de service inactif.
Contactez le propriétaire du compte de service dans le champ Adresse e-mail principale. Vérifiez si l'action a été effectuée par le propriétaire légitime.

Étape 3: Mettre en œuvre votre réponse

Contactez le propriétaire du projet pour lequel l'action a été prise.
Envisagez de supprimer le compte de service potentiellement compromis et d'alterner puis supprimer toutes les clés d'accès au compte de service du projet potentiellement compromis. Après suppression, les applications qui utilisent le compte de service pour l'authentification perdent l'accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les applications concernées et collaborer avec les propriétaires des applications pour assurer la continuité des opérations.
Collaborez avec votre équipe de sécurité pour identifier les ressources inconnues, y compris les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM. Supprimez les ressources qui n'ont pas été créées avec des comptes autorisés.
Répondez à toutes les notifications de l'assistance Google Cloud.
Pour limiter les utilisateurs autorisés à créer des comptes de service, utilisez le service de règles d'administration.
Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

`Initial Access: Dormant Service Account Key Created`

Détecte les événements où une clé de compte de service géré par l'utilisateur dormante est créée. Dans ce contexte, un compte de service est considéré comme dormant s'il est inactif depuis plus de 180 jours.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Initial Access: Dormant Service Account Key Created, comme indiqué dans la section Examiner les résultats.
Dans les détails du résultat, dans l'onglet Récapitulatif, notez les valeurs des champs suivants.

Sous Risque détecté:
- Adresse e-mail principale: utilisateur ayant créé la clé de compte de service
Sous Ressource concernée:
- Nom à afficher de la ressource: clé de compte de service inactif nouvellement créée
- Nom complet du projet: projet dans lequel se trouve ce compte de service inactif

Étape 2 : Étudier les méthodes d'attaque et de réponse

Utilisez des outils de compte de service, comme Activity Analyzer, pour examiner l'activité du compte de service inactif.
Contactez le propriétaire du champ Adresse e-mail principale. Vérifiez si l'action a été effectuée par le propriétaire légitime.

Étape 3: Mettre en œuvre votre réponse

Contactez le propriétaire du projet pour lequel l'action a été prise.
Supprimez l'accès du propriétaire de l'adresse e-mail principale si elle est compromise.
Annulez la validité de la clé de compte de service que vous venez de créer sur la page Service Accounts (Comptes de service).
Envisagez de supprimer le compte de service potentiellement compromis et d'alterner puis supprimer toutes les clés d'accès au compte de service du projet potentiellement compromis. Après suppression, les applications qui utilisent le compte de service pour l'authentification perdent l'accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les applications concernées et collaborer avec les propriétaires des applications pour assurer la continuité des opérations.
Collaborez avec votre équipe de sécurité pour identifier les ressources inconnues, y compris les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM. Supprimez les ressources qui n'ont pas été créées avec des comptes autorisés.
Répondez à toutes les notifications de Cloud Customer Care.
Pour limiter les utilisateurs autorisés à créer des comptes de service, utilisez le service de règles d'administration.
Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

`Initial Access: Leaked Service Account Key Used`

Détecte les événements où une clé de compte de service divulguée est utilisée pour authentifier l'action. Dans ce contexte, une clé de compte de service divulguée est une clé qui a été publiée sur Internet. Par exemple, les clés de compte de service sont souvent publiées par erreur dans un dépôt GitHub public.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Initial Access: Leaked Service Account Key Used, comme indiqué dans la section Examiner les résultats.
Dans les détails du résultat, dans l'onglet Récapitulatif, notez les valeurs des champs suivants.

Sous Risque détecté:
- Adresse e-mail principale: compte de service utilisé pour cette action
- Nom du service: nom de l'API du service Google Cloud auquel le compte de service a accédé
- Nom de la méthode: nom de la méthode de l'action
- Nom de la clé de compte de service: clé de compte de service divulguée utilisée pour authentifier cette action
- Description: description de ce qui a été détecté, y compris l'emplacement sur Internet public où se trouve la clé du compte de service
Sous Ressource concernée:
- Nom à afficher de la ressource: ressource impliquée dans l'action

Étape 2 : Vérifier les journaux

Dans la console Google Cloud, accédez à l'explorateur de journaux en cliquant sur le lien dans URI Cloud Logging.
Dans la barre d'outils de la console Google Cloud, sélectionnez votre projet ou votre organisation.
Sur la page qui s'affiche, recherchez les journaux associés à l'aide du filtre suivant:
- protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
- protoPayload.authenticationInfo.serviceAccountKeyName="SERVICE_ACCOUNT_KEY_NAME"
Remplacez PRINCIPAL_EMAIL par la valeur que vous avez notée dans le champ Adresse e-mail principale des détails de la recherche. Remplacez SERVICE_ACCOUNT_KEY_NAME par la valeur que vous avez notée dans le champ Nom de la clé du compte de service dans les détails de la recherche.

Étape 3: Mettre en œuvre votre réponse

Révoquez immédiatement la clé du compte de service sur la page Comptes de service.
Supprimez la page Web ou le dépôt GitHub sur lesquels la clé du compte de service est publiée.
Envisagez de supprimer le compte de service compromis.
Alternez et supprimez toutes les clés d'accès au compte de service du projet potentiellement compromis. Après suppression, les applications qui utilisent le compte de service pour l'authentification perdent l'accès. Avant de supprimer, votre équipe de sécurité doit identifier toutes les applications concernées et collaborer avec les propriétaires des applications pour assurer la continuité des opérations.
Collaborez avec votre équipe de sécurité pour identifier les ressources inconnues, y compris les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM. Supprimez les ressources qui n'ont pas été créées avec des comptes autorisés.
Répondez à toutes les notifications de Cloud Customer Care.

`Initial Access: Excessive Permission Denied Actions`

Détecte les événements où un principal déclenche à plusieurs reprises des erreurs autorisation refusée dans plusieurs méthodes et services.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Initial Access: Excessive Permission Denied Actions, comme indiqué dans la section Examiner les résultats.
Dans les détails du résultat, dans l'onglet Résumé, notez les valeurs des champs suivants.

Sous Risque détecté:
- Adresse e-mail du principal: compte principal ayant déclenché plusieurs erreurs "Autorisation refusée"
- Nom du service: nom de l'API du service Google Cloud pour lequel l'erreur de refus d'autorisation s'est produite
- Nom de la méthode: méthode appelée lors de la dernière erreur d'autorisation refusée
Dans les détails de la recherche, dans l'onglet Source Properties (Propriétés sources), notez les valeurs des champs suivants dans le fichier JSON:
- properties.failedActions: erreurs d'autorisation refusée qui se sont produites. Pour chaque entrée, les détails incluent le nom du service, le nom de la méthode, le nombre de tentatives échouées et l'heure à laquelle l'erreur s'est produite pour la dernière fois. Un maximum de 10 entrées est affiché.

Étape 2 : Vérifier les journaux

Dans la console Google Cloud, accédez à l'explorateur de journaux en cliquant sur le lien dans URI Cloud Logging.
Dans la barre d'outils de la console Google Cloud, sélectionnez votre projet.
Sur la page qui s'affiche, recherchez les journaux associés à l'aide du filtre suivant:
- protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
- protoPayload.status.code=7
Remplacez PRINCIPAL_EMAIL par la valeur que vous avez notée dans le champ Adresse e-mail principale des détails de la recherche.

Étape 3 : Rechercher des méthodes d'attaque et de réponse

Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Comptes valides : comptes Cloud.
Pour élaborer un plan de réponse, combinez les résultats de vos enquêtes avec la recherche MITRE.

Étape 4 : Mettre en œuvre votre réponse

Contactez le propriétaire du compte dans le champ Adresse e-mail principale. Confirmez si l'action a été effectuée par le propriétaire légitime.
Supprimez les ressources de projet créées par ce compte, comme les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM inconnus.
Contactez le propriétaire du projet associé au compte, et supprimez ou désactivez éventuellement le compte.

`Brute Force: SSH`

Détection d'une attaque par force brute SSH réussie sur un hôte Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez un résultat Brute Force: SSH, comme indiqué dans la section Examiner les résultats.
Dans l'onglet Récapitulatif du panneau "Détails du résultat", examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants:
  - Adresse IP de l'appelant: adresse IP de l'appelant de l'attaque.
  - Nom d'utilisateur: compte utilisé pour la connexion.
- Ressource concernée
- Liens associés, en particulier les champs suivants:
  - URI Cloud Logging: lien vers les entrées de journalisation.
  - Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
  - Résultats associés: liens vers les résultats associés.
  - Chronicle: lien vers Google SecOps.
Cliquez sur l'onglet JSON.
Dans le fichier JSON, notez les champs suivants.
- sourceProperties :
  - evidence :
    - sourceLogId: ID de projet et code temporel permettant d'identifier l'entrée de journal
    - projectId : projet contenant le résultat.
  - properties :
    - attempts :
    - Attempts : nombre de tentatives de connexion.
      - username : compte qui s'est connecté.
      - vmName : nom de la machine virtuelle.
      - authResult : résultat de l'authentification SSH.

Étape 2: Analyser dans Google Security Operations

Vous pouvez utiliser Google Security Operations pour examiner ce résultat. Google SecOps est un service Google Cloud qui vous permet d'examiner les menaces et de parcourir les entités associées selon une chronologie simple à utiliser. Google SecOps enrichit les données des résultats, ce qui vous permet d'identifier les indicateurs intéressants et de simplifier les enquêtes.

Vous ne pouvez utiliser Google SecOps que si vous activez Security Command Center au niveau de l'organisation.

Accédez à la page Résultats de Security Command Center dans Google Cloud Console.

Accéder
Dans le panneau Filtres rapides, faites défiler la page jusqu'à Nom à afficher pour la source.
Dans la section Nom à afficher pour la source, sélectionnez Event Threat Detection.

La table présente les résultats correspondant au type de source que vous avez sélectionné.
Dans le tableau, sous catégorie, cliquez sur un résultat Brute Force: SSH. Le panneau des détails du résultat s'ouvre.
Dans la section Liens associés du panneau "Détails du résultat", cliquez sur Examiner dans Chronicle.
Suivez les instructions de l'interface utilisateur guidée de Google SecOps.

Utilisez les guides suivants pour mener des enquêtes dans Google SecOps:

Étape 3 : Vérifier les autorisations et les paramètres

Dans Google Cloud Console, accédez au tableau de bord.

Accéder au tableau de bord
Sélectionnez le projet spécifié dans projectId.
Accédez à la fiche Ressources, puis cliquez sur Compute Engine.
Cliquez sur l'instance de VM qui correspond au nom et à la zone dans vmName. Examinez les détails de l'instance, y compris les paramètres réseau et d'accès.
Dans le panneau de navigation, cliquez sur Réseau VPC, puis sur Pare-feu. Supprimez ou désactivez les règles de pare-feu trop permissives sur le port 22.

Étape 4 : Vérifier les journaux

Dans la console Google Cloud, accédez à l'explorateur de journaux en cliquant sur le lien dans URI Cloud Logging.
Sur la page qui s'affiche, recherchez les journaux de flux VPC associés à l'adresse IP indiquée sur la ligne Adresse e-mail principale dans l'onglet Récapitulatif des détails de la recherche à l'aide du filtre suivant :
- logName="projects/projectId/logs/syslog"
- labels."compute.googleapis.com/resource_name"="vmName"

Étape 5 : Étudier les méthodes d'attaque et de réponse

Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Comptes valides : comptes locaux.
Consultez les résultats associés en cliquant sur le lien Résultats associés sur la ligne Résultats associés dans l'onglet Récapitulatif des détails du résultat. Les résultats associés sont du même type de résultat, sur la même instance et sur le même réseau.
Pour élaborer un plan de réponse, combinez les résultats de vos enquêtes avec la recherche MITRE.

Étape 6 : Mettre en œuvre votre réponse

Contactez le propriétaire du projet associé à la tentative de force brute réussie.
Examinez l'instance potentiellement compromise et supprimez tous les logiciels malveillants détectés. Pour faciliter la détection et la suppression, utilisez une solution de détection et de gestion des points de terminaison.
Envisagez de désactiver l'accès SSH à la VM. Pour en savoir plus sur la désactivation des clés SSH, consultez la section Restreindre des clés SSH sur des VM. Cette étape peut interrompre l'accès autorisé à la VM. Par conséquent, pensez aux besoins de votre organisation avant de l'appliquer.
N'utilisez l'authentification SSH qu'avec des clés autorisées.
Bloquez les adresses IP malveillantes en mettant à jour les règles de pare-feu ou en utilisant Google Cloud Armor Vous pouvez activer Google Cloud Armor sur la page Services intégrés de Security Command Center. Selon la quantité d'informations, les coûts de Google Cloud Armor peuvent être importants. Pour en savoir plus, consultez le guide des tarifs de Google Cloud Armor.

`Credential Access: External Member Added To Privileged Group`

Cette information n'est pas disponible pour les activations au niveau du projet.

Détecte lorsqu'un membre externe est ajouté à un groupe Google privilégié (groupe doté d'autorisations ou de rôles sensibles). Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez un résultat Credential Access: External Member Added To Privileged Group comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Résumé.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Adresse e-mail principale: compte à l'origine des modifications.
- Ressource concernée
- Liens associés, en particulier les champs suivants :
  - URI Cloud Logging: lien vers les entrées de journalisation.
  - Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
  - Résultats associés: liens vers les résultats associés.
Dans le panneau des détails, cliquez sur l'onglet JSON.
Dans le fichier JSON, notez les champs suivants.
- groupName : groupe Google auquel les modifications ont été apportées
- externalMember : membre externe récemment ajouté
- sensitiveRoles : rôles sensibles associés au groupe

Étape 2 : Vérifier les membres du groupe

Accédez à Google Groupes.

Accéder à Google Groupes
Cliquez sur le nom du groupe que vous souhaitez examiner.
Dans le menu de navigation, cliquez sur Membres.
Si le membre externe récemment ajouté ne doit pas faire partie de ce groupe, cochez la case à côté de son nom, puis sélectionnez Supprimer le membre ou Exclure le membre.

Pour supprimer des membres, vous devez être un administrateur Google Workspace ou avoir le rôle de Propriétaire ou de Gestionnaire dans le groupe Google. Pour en savoir plus, consultez la section Attribuer des rôles aux membres d'un groupe.

Étape 3 : Vérifier les journaux

Dans l'onglet Récapitulatif du panneau "Détails du résultat", cliquez sur le lien URI Cloud Logging pour ouvrir l'explorateur de journaux.
Si nécessaire, sélectionnez votre projet.
Sur la page qui s'affiche, consultez les journaux des modifications apportées à la liste des membres du groupe Google à l'aide des filtres suivants :
- protoPayload.methodName="google.apps.cloudidentity.groups.v1.MembershipsService.UpdateMembership"
- protoPayload.authenticationInfo.principalEmail="principalEmail"

Étape 4 : Rechercher des méthodes d'attaque et de réponse

Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Comptes valides.
Pour déterminer si d'autres mesures correctives sont nécessaires, combinez vos résultats d'enquête avec la recherche MITRE.

`Credential Access: Failed Attempt to Approve Kubernetes Certificate Signing Request (CSR)`

Quelqu'un a tenté d'approuver manuellement une requête de signature de certificat (CSR), mais l'action a échoué. La création d'un certificat pour l'authentification de cluster est une méthode courante utilisée par les pirates informatiques pour créer un accès persistant à un cluster compromis. Les autorisations associées au certificat varient en fonction de l'objet inclus, mais peuvent être très privilégiées. Pour en savoir plus, consultez le message de journal de cette alerte.

Examinez les journaux d'audit dans Cloud Logging et les alertes supplémentaires pour les autres événements liés aux requêtes de signature de certificat (CSR) afin de déterminer si des CSR ont été approved et émises, et si les actions liées aux CSR correspondent à une activité attendue de la part du compte principal.
Déterminez s'il existe d'autres signes d'activité malveillante de la part du compte principal dans les journaux d'audit de Cloud Logging. Exemple :
- Le compte principal qui a tenté d'approuver la requête de signature de certificat était-il différent de celui qui l'a créée ?
- Le compte principal a-t-il essayé de demander, de créer, d'approuver ou de supprimer d'autres CSR ?
Si l'approbation d'une requête de signature de certificat n'était pas attendue ou si celle-ci est considérée comme malveillante, une rotation des identifiants du cluster est nécessaire pour invalider le certificat. Consultez les instructions pour effectuer une rotation des identifiants de votre cluster.

`Credential Access: Manually Approved Kubernetes Certificate Signing Request (CSR)`

Quelqu'un a approuvé manuellement une requête de signature de certificat (CSR). La création d'un certificat pour l'authentification de cluster est une méthode courante utilisée par les pirates informatiques pour créer un accès persistant à un cluster compromis. Les autorisations associées au certificat varient en fonction de l'objet qu'il inclut, mais peuvent être très privilégiées. Pour en savoir plus, consultez le message de journal de cette alerte.

Examinez les journaux d'audit dans Cloud Logging et les alertes supplémentaires pour les autres événements liés aux requêtes de signature de certificat (CSR) afin de déterminer si les actions liées aux CSR sont des activités attendues de la part du compte principal.
Déterminez s'il existe d'autres signes d'activité malveillante de la part du compte principal dans les journaux d'audit de Cloud Logging. Exemple :
- Le compte principal qui a approuvé la requête de signature de certificat était-il différent de celui qui l'a créée ?
- La requête de signature de certificat spécifiait-elle un signataire intégré, mais a-t-elle finalement dû être approuvée manuellement car elle ne respectait pas les critères du signataire ?
- Le compte principal a-t-il essayé de demander, de créer, d'approuver ou de supprimer d'autres CSR ?
Si l'approbation d'une requête de signature de certificat n'était pas attendue ou si celle-ci est considérée comme malveillante, une rotation des identifiants du cluster est nécessaire pour invalider le certificat. Consultez les instructions pour effectuer une rotation des identifiants de votre cluster.

`Credential Access: Privileged Group Opened To Public`

Cette information n'est pas disponible pour les activations au niveau du projet.

Détecte lorsqu'un groupe Google privilégié (groupe disposant de rôles ou d'autorisations sensibles) est modifié pour devenir accessible au grand public. Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez un résultat Credential Access: Privileged Group Opened To Public comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Résumé.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Adresse e-mail principale: compte ayant effectué les modifications, qui peut être piraté.
- Ressource concernée
- Liens associés, en particulier les champs suivants :
  - URI Cloud Logging: lien vers les entrées de journalisation.
  - Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
  - Résultats associés: liens vers les résultats associés.
1. Cliquez sur l'onglet JSON.
2. Dans le fichier JSON, notez les champs suivants.
- groupName : groupe Google auquel les modifications ont été apportées
- sensitiveRoles : rôles sensibles associés au groupe
- whoCanJoin : paramètre de joignabilité du groupe

Étape 2 : Vérifier les paramètres d'accès au groupe

Accédez à la console d'administration de Google Groupes. Vous devez être un administrateur Google Workspace pour vous connecter à la console.

Accéder à la console d'administration
Dans le volet de navigation, cliquez sur Annuaire, puis sélectionnez Groupes.
Cliquez sur le nom du groupe que vous souhaitez examiner.
Cliquez sur Paramètres d'accès, puis, sous Qui peut rejoindre le groupe, vérifiez le paramètre de joignabilité du groupe.
Dans le menu déroulant, modifiez le paramètre de joignabilité si nécessaire.

Étape 3 : Vérifier les journaux

Dans l'onglet Récapitulatif du panneau "Détails du résultat", cliquez sur le lien URI Cloud Logging pour ouvrir l'explorateur de journaux.
Si nécessaire, sélectionnez votre projet.
Sur la page qui s'affiche, consultez les journaux des modifications apportées aux paramètres du groupe Google à l'aide des filtres suivants :
- protoPayload.methodName="google.admin.AdminService.changeGroupSetting"
- protoPayload.authenticationInfo.principalEmail="principalEmail"

Étape 4 : Rechercher des méthodes d'attaque et de réponse

Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Comptes valides.
Pour déterminer si d'autres mesures correctives sont nécessaires, combinez vos résultats d'enquête avec la recherche MITRE.

`Credential Access: Secrets Accessed in Kubernetes Namespace`

Détecte quand le compte de service Kubernetes default d'un pod a été utilisé pour accéder aux objets Secret du cluster. Le compte de service Kubernetes default ne doit pas avoir accès aux objets Secret, sauf si vous lui avez explicitement accordé cet accès avec un objet Role ou un objet ClusterRole.

`Credential Access: Sensitive Role Granted To Hybrid Group`

Détecte les rôles ou autorisations sensibles accordés à un groupe Google avec des membres externes. Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez un résultat Credential Access: Sensitive Role Granted To Hybrid Group comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Récapitulatif.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Adresse e-mail principale: compte ayant effectué les modifications, qui peut être piraté.
- Ressource concernée, en particulier les champs suivants :
  - Nom complet de la ressource: ressource dans laquelle le nouveau rôle a été attribué.
- Liens associés, en particulier les champs suivants :
  - URI Cloud Logging: lien vers les entrées de journalisation.
  - Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
  - Résultats associés: liens vers les résultats associés.
1. Cliquez sur l'onglet JSON.
2. Dans le fichier JSON, notez les champs suivants.
- groupName : groupe Google auquel les modifications ont été apportées
- bindingDeltas: rôles sensibles qui viennent d'être attribués au groupe.

Étape 2 : Vérifier les autorisations du groupe

Accédez à la page IAM de la console Google Cloud.

Accéder à IAM
Dans le champ Filtre, saisissez le nom du compte répertorié dans groupName.
Examinez les rôles sensibles attribués au groupe.
Si le rôle sensible nouvellement ajouté n'est pas nécessaire, révoquez-le.

Vous devez disposer d'autorisations spécifiques pour gérer les rôles dans votre organisation ou votre projet. Pour en savoir plus, consultez la section Autorisations requises.

Étape 3 : Vérifier les journaux

Dans l'onglet Récapitulatif du panneau "Détails du résultat", cliquez sur le lien URI Cloud Logging pour ouvrir l'explorateur de journaux.
Si nécessaire, sélectionnez votre projet.
Sur la page qui s'affiche, consultez les journaux des modifications apportées aux paramètres du groupe Google à l'aide des filtres suivants :
- protoPayload.methodName="SetIamPolicy"
- protoPayload.authenticationInfo.principalEmail="principalEmail"

Étape 4 : Rechercher des méthodes d'attaque et de réponse

Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Comptes valides.
Pour déterminer si d'autres mesures correctives sont nécessaires, combinez vos résultats d'enquête avec la recherche MITRE.

`Malware: Cryptomining Bad IP`

La présence de logiciels malveillants est détectée en examinant les journaux de flux VPC et les journaux Cloud DNS pour détecter les connexions à des domaines de contrôle et de commande connus ainsi qu'à des adresses IP connues. Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez un résultat Malware: Cryptomining Bad IP, comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Récapitulatif.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Adresse IP source: adresse IP de minage de cryptomonnaie suspectée.
  - Port source: port source de la connexion, le cas échéant.
  - Adresse IP de destination: adresse IP cible.
  - Port de destination: port de destination de la connexion, le cas échéant.
  - Protocole: protocole IANA associé à la connexion.
- Ressource concernée
- Liens associés, y compris les champs suivants :
  - URI de journalisation: lien vers les entrées de journalisation.
  - Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
  - Résultats associés: liens vers les résultats associés.
  - Flow Analyzer (Preview): lien vers la fonctionnalité Flow Analyzer de Network Intelligence Center. Ce champ ne s'affiche que lorsque les journaux de flux VPC sont activés.
Dans la vue détaillée du résultat, cliquez sur l'onglet Propriétés sources.
Développez properties (Propriétés) et notez les valeurs du projet et de l'instance dans le champ suivant:
- instanceDetails: notez l'ID du projet et le nom de l'instance Compute Engine. L'ID de projet et le nom de l'instance s'affichent comme illustré dans l'exemple suivant:
```
/projects/PROJECT_ID/zones/ZONE/instances/INSTANCE_NAME
```
Pour afficher le code JSON complet du résultat, cliquez sur l'onglet JSON.

Étape 2 : Vérifier les autorisations et les paramètres

Dans la console Google Cloud, accédez à la page Tableau de bord.

Accéder au tableau de bord
Sélectionnez le projet spécifié dans properties_project_id.
Accédez à la fiche Ressources, puis cliquez sur Compute Engine.
Cliquez sur l'instance de VM correspondant à properties_sourceInstance. Examinez l'instance potentiellement compromise à la recherche de logiciels malveillants.
Dans le panneau de navigation, cliquez sur Réseau VPC, puis sur Pare-feu. Supprimez ou désactivez les règles de pare-feu trop permissives.

Étape 3 : Vérifier les journaux

Dans la console Google Cloud, accédez à l'explorateur de journaux.

Accéder à l'explorateur de journaux
Dans la barre d'outils de la console Google Cloud, sélectionnez votre projet.
Sur la page qui s'affiche, recherchez les journaux de flux VPC liés à Properties_ip_0 à l'aide du filtre suivant :
- logName="projects/properties_project_id/logs/compute.googleapis.com%2Fvpc_flows"
- (jsonPayload.connection.src_ip="Properties_ip_0" OR jsonPayload.connection.dest_ip="Properties_ip_0")

Étape 4 : Rechercher des méthodes d'attaque et de réponse

Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Détournement de ressources.
Pour élaborer un plan de réponse, combinez les résultats de vos enquêtes avec la recherche MITRE.

Étape 5 : Mettre en œuvre votre réponse

Contactez le propriétaire du projet contenant les logiciels malveillants.
Examinez l'instance potentiellement compromise et supprimez tous les logiciels malveillants détectés. Pour faciliter la détection et la suppression, utilisez une solution de détection et de gestion des points de terminaison.
Si nécessaire, arrêtez l'instance compromise et remplacez-la par une nouvelle instance.
Bloquez les adresses IP malveillantes en mettant à jour les règles de pare-feu ou en utilisant Google Cloud Armor Vous pouvez activer Google Cloud Armor sur la page Services intégrés de Security Command Center. Selon le volume de données, les coûts de Google Cloud Armor peuvent être importants. Pour en savoir plus, consultez le guide des tarifs de Google Cloud Armor.

`Initial Access: Log4j Compromise Attempt`

Ce résultat est généré lorsque des recherches Java Naming and Directory Interface (JNDI) dans les en-têtes ou les paramètres d'URL sont détectés. Ces recherches peuvent indiquer des tentatives d'exploitation Log4Shell. Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez un résultat Initial Access: Log4j Compromise Attempt, comme indiqué dans la section Examiner les détails des résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Résumé.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Risque détecté
- Ressource concernée
- Liens associés, en particulier les champs suivants :
  - URI Cloud Logging: lien vers les entrées de journalisation.
  - Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
  - Résultats associés: liens vers les résultats associés.
- Dans la vue détaillée du résultat, cliquez sur l'onglet JSON.
- Dans le fichier JSON, notez les champs suivants.
- properties
  - loadBalancerName: nom de l'équilibreur de charge ayant reçu la recherche JNDI
  - requestUrl : URL de la requête HTTP. Si ce champ est présent, il contient une recherche JNDI.
  - requestUserAgent : user-agent qui a envoyé la requête HTTP. Si ce champ est présent, il contient une recherche JNDI.
  - refererUrl : URL de la page qui a envoyé la requête HTTP. Si ce champ est présent, il contient une recherche JNDI.

Étape 2 : Vérifier les journaux

Dans la console Google Cloud, accédez à l'explorateur de journaux en cliquant sur le lien figurant dans le champ URI de journalisation Cloud de l'étape 1.
Sur la page qui s'affiche, recherchez les jetons de chaîne (tels que ${jndi:ldap://) dans les champs httpRequest qui peuvent indiquer des tentatives d'exploitation possibles.

Pour découvrir des exemples de chaînes à rechercher et un exemple de requête, consultez la section CVE-2021-44228 : Détection de l'exploitation Log4Shell dans la documentation de Logging.

Étape 3 : Rechercher des méthodes d'attaque et de réponse

Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Exploitation d'une application publique.
Consultez les résultats associés en cliquant sur le lien Résultats associés sur la ligne Résultats associés dans l'onglet Récapitulatif des détails des résultats. Les résultats associés sont du même type de résultat, sur la même instance et sur le même réseau.
Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.

Étape 4 : Mettre en œuvre votre réponse

Installez la dernière version de Log4j2.
Suivez les recommandations de Google Cloud pour enquêter sur la faille "Apache Log4j 2" et y répondre.
Mettez en œuvre les techniques d'atténuation recommandées dans Failles de sécurité Apache Log4j.
Si vous utilisez Google Cloud Armor, déployez la ressource cve-canary rule dans une stratégie de sécurité Google Cloud Armor nouvelle ou existante. Pour en savoir plus, consultez la page Règle WAF de Google Cloud Armor pour limiter les failles Apache Log4j.

`Active Scan: Log4j Vulnerable to RCE`

Les analyseurs de failles Log4j compatibles injectent des recherches JNDI obscurcies dans les paramètres HTTP, les URL et les champs de texte avec des rappels aux domaines contrôlés par les analyseurs. Ce résultat est généré lorsque des requêtes DNS sont trouvées pour les domaines non obscurcis. Ces requêtes ne se produisent que si une recherche JNDI a abouti, ce qui indique une faille Log4j active. Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez un résultat Active Scan: Log4j Vulnerable to RCE, comme indiqué dans la section Examiner les détails des résultats. Le panneau d'informations de la non-conformité s'ouvre dans l'onglet Récapitulatif.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Risque détecté
- Ressource concernée, en particulier le champ suivant :
  - Nom complet de la ressource: nom complet de la ressource de l'instance Compute Engine vulnérable au RCE de Log4j.
- Liens associés, en particulier les champs suivants :
  - URI Cloud Logging: lien vers les entrées de journalisation.
  - Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
  - Résultats associés: liens vers les résultats associés.
Dans la vue détaillée du résultat, cliquez sur l'onglet JSON.
Dans le fichier JSON, notez les champs suivants.
- properties
  - scannerDomain : domaine utilisé par l'outil d'analyse dans le cadre de la recherche JNDI. Cela vous indique quel outil d'analyse a identifié la faille.
  - sourceIp : adresse IP utilisée pour effectuer la requête DNS
  - vpcName: nom du réseau de l'instance sur laquelle la requête DNS a été effectuée.

Étape 2 : Vérifier les journaux

Dans la console Google Cloud, accédez à l'explorateur de journaux en cliquant sur le lien figurant dans le champ URI de journalisation Cloud de l'étape 1.
Sur la page qui s'affiche, recherchez les jetons de chaîne (tels que ${jndi:ldap://) dans les champs httpRequest qui peuvent indiquer des tentatives d'exploitation possibles.

Pour découvrir des exemples de chaînes à rechercher et un exemple de requête, consultez la section CVE-2021-44228 : Détection de l'exploitation Log4Shell dans la documentation de Logging.

Étape 3 : Rechercher des méthodes d'attaque et de réponse

Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Exploitation des services à distance.
Consultez les résultats associés en cliquant sur le lien Résultats associés sur la ligne Résultats associés dans l'onglet Récapitulatif des détails des résultats. Les résultats associés sont du même type de résultat, sur la même instance et sur le même réseau.
Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.

Étape 4 : Mettre en œuvre votre réponse

Installez la dernière version de Log4j2.
Suivez les recommandations de Google Cloud pour enquêter sur la faille "Apache Log4j 2" et y répondre.
Mettez en œuvre les techniques d'atténuation recommandées dans Failles de sécurité Apache Log4j.
Si vous utilisez Google Cloud Armor, déployez la ressource cve-canary rule dans une stratégie de sécurité Google Cloud Armor nouvelle ou existante. Pour en savoir plus, consultez la page Règle WAF de Google Cloud Armor pour limiter les failles Apache Log4j.

`Leaked credentials`

Cette information n'est pas disponible pour les activations au niveau du projet.

Ce résultat est généré lorsque des identifiants de compte de service Google Cloud sont accidentellement divulgués en ligne ou compromis. Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez un résultat account_has_leaked_credentials, comme indiqué dans la section Examiner les détails des résultats. Le panneau d'informations de l'anomalie s'ouvre dans l'onglet Récapitulatif.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:

Risque détecté
Ressource concernée

Cliquez sur l'onglet Propriétés sources et notez les champs suivants:
- Compromised_account : compte de service potentiellement compromis.
- Project_identifier : projet contenant les identifiants de compte potentiellement divulgués.
- URL : lien vers le dépôt GitHub.
Pour afficher le code JSON complet du résultat, cliquez sur l'onglet JSON.

Étape 2 : Vérifier les autorisations des projets et des comptes de service

Dans la console Google Cloud, accédez à la page IAM.

Accéder à IAM
Si nécessaire, sélectionnez le projet répertorié dans Project_identifier.
Sur la page qui s'affiche, dans la zone Filtre, saisissez le nom du compte répertorié dans Compromised_account et vérifiez les autorisations attribuées.
Dans la console Google Cloud, accédez à la page Comptes de service.

Accéder à la page "Comptes de service"
Sur la page qui s'affiche, dans le champ Filtre, saisissez le nom du compte de service compromis et vérifiez ses clés ainsi que les dates de création des clés.

Étape 3 : Vérifier les journaux

Dans la console Google Cloud, accédez à l'explorateur de journaux.

Accéder à l'explorateur de journaux
Dans la barre d'outils de la console Google Cloud, sélectionnez votre projet.
Sur la page qui se charge, vérifiez les journaux à la recherche d'activité provenant de ressources Cloud IAM nouvelles ou mises à jour à l'aide des filtres suivants :
- proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
- protoPayload.methodName="SetIamPolicy"
- resource.type="gce_instance" AND log_name="projects/Project_identifier/logs/cloudaudit.googleapis.com%2Factivity"
- protoPayload.methodName="InsertProjectOwnershipInvite"
- protoPayload.authenticationInfo.principalEmail="Compromised_account"

Étape 4 : Rechercher des méthodes d'attaque et de réponse

Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Comptes valides : comptes Cloud.
Consultez les résultats associés en cliquant sur le lien correspondant dans le fichier relatedFindingURI. Les résultats associés sont du même type de résultat, sur la même instance et sur le même réseau.
Pour élaborer un plan de réponse, combinez les résultats de vos enquêtes avec la recherche MITRE.

Étape 5 : Mettre en œuvre votre réponse

Contactez le propriétaire du projet contenant les identifiants divulgués.
Envisagez de supprimer le compte de service compromis et d'alterner puis supprimer toutes les clés d'accès au compte de service du projet compromis. Après suppression, les ressources qui utilisent le compte de service pour l'authentification perdent l'accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les ressources affectées et collaborer avec les propriétaires des ressources pour assurer la continuité des opérations.
Collaborez avec votre équipe de sécurité pour identifier les ressources inconnues, y compris les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM. Supprimez les ressources qui n'ont pas été créées avec des comptes autorisés.
Répondez aux notifications de l'assistance Google Cloud.
Pour limiter les utilisateurs autorisés à créer des comptes de service, utilisez le service de règles d'administration.
Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.
Ouvrez le lien URL et supprimez les identifiants divulgués. Rassemblez plus d'informations sur le compte compromis et contactez le propriétaire.

`Malware`

Les logiciels malveillants sont détectés en examinant les journaux de flux VPC et les journaux Cloud DNS pour détecter les connexions à des domaines de commande et de contrôle connus ainsi qu'à des adresses IP connues. Actuellement, Event Threat Detection fournit une détection générale des logiciels malveillants (Malware: Bad IP et Malware: Bad Domain) et des détecteurs en particulier pour les logiciels malveillants liés à Log4j (Log4j Malware: Bad IP et Log4j Malware: Bad Domain).

Les étapes suivantes décrivent comment examiner et répondre aux résultats basés sur les adresses IP. Les étapes de résolution sont similaires pour les résultats basés sur un domaine.

Étape 1 : Examiner les détails du résultat

Ouvrez la détection de logiciel malveillant concernée. Les étapes suivantes utilisent le résultat Malware: Bad IP, comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Récapitulatif.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Domaine de l'indicateur: pour les résultats Bad domain, domaine ayant déclenché le résultat.
  - Adresse IP de l'indicateur: pour les résultats Bad IP, adresse IP ayant déclenché le résultat.
  - Adresse IP source: pour les résultats Bad IP, adresse IP de commande et de contrôle de logiciel malveillant connue.
  - Port source: pour les résultats Bad IP, port source de la connexion.
  - Adresse IP de destination: pour les résultats Bad IP, adresse IP cible du logiciel malveillant.
  - Port de destination: pour les résultats Bad IP, port de destination de la connexion.
  - Protocole: pour les résultats Bad IP, numéro de protocole IANA associé à la connexion.
- Ressource concernée, en particulier les champs suivants :
  - Nom complet de la ressource: nom complet de la ressource de l'instance Compute Engine concernée.
  - Nom complet du projet: nom complet de la ressource du projet contenant l'anomalie.
- Liens associés, en particulier les champs suivants :
  - URI Cloud Logging: lien vers les entrées de journalisation.
  - Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
  - Résultats associés: liens vers les résultats associés.
  - Chronicle: lien vers Google SecOps.
  - Indicateur VirusTotal: lien vers la page d'analyse VirusTotal.
  - Flow Analyzer (Preview): lien vers la fonctionnalité Flow Analyzer de Network Intelligence Center. Ce champ ne s'affiche que lorsque les journaux de flux VPC sont activés.
1. Cliquez sur l'onglet JSON et notez le champ suivant:
  - evidence :
  - sourceLogId :
    - projectID: ID du projet dans lequel le problème a été détecté.
  - properties :
  - InstanceDetails: adresse de la ressource pour l'instance Compute Engine.

Étape 2: Analyser dans Google Security Operations

Vous pouvez utiliser Google Security Operations pour examiner ce résultat. Google SecOps est un service Google Cloud qui vous permet d'examiner les menaces et de parcourir les entités associées selon une chronologie simple à utiliser. Google SecOps enrichit les données des résultats, ce qui vous permet d'identifier les indicateurs intéressants et de simplifier les enquêtes.

Vous ne pouvez utiliser Google SecOps que si vous activez Security Command Center au niveau de l'organisation.

Accédez à la page Résultats de Security Command Center dans Google Cloud Console.

Accéder
Dans le panneau Filtres rapides, faites défiler la page jusqu'à Nom à afficher pour la source.
Dans la section Nom à afficher pour la source, sélectionnez Event Threat Detection.

La table présente les résultats correspondant au type de source que vous avez sélectionné.
Dans le tableau, sous catégorie, cliquez sur le résultat Malware: Bad IP. Le panneau des détails du résultat s'ouvre.
Dans la section Liens associés du panneau "Détails du résultat", cliquez sur Examiner dans Chronicle.
Suivez les instructions de l'interface utilisateur guidée de Google SecOps.

Utilisez les guides suivants pour mener des enquêtes dans Google SecOps:

Étape 3 : Vérifier les autorisations et les paramètres

Dans la console Google Cloud, accédez à la page Tableau de bord.

Accéder au tableau de bord
Sélectionnez le projet spécifié dans la ligne Nom complet du projet de l'onglet Résumé.
Accédez à la fiche Ressources, puis cliquez sur Compute Engine.
Cliquez sur l'instance de VM qui correspond au nom et à la zone dans Nom complet de la ressource. Vérifiez les détails de l'instance, y compris les paramètres réseau et d'accès.
Dans le panneau de navigation, cliquez sur Réseau VPC, puis sur Pare-feu. Supprimez ou désactivez les règles de pare-feu trop permissives.

Étape 4 : Vérifier les journaux

Dans l'onglet Récapitulatif du panneau "Détails du résultat", cliquez sur le lien URI Cloud Logging pour ouvrir l'explorateur de journaux.
Sur la page qui s'affiche, recherchez les journaux de flux VPC associés à l'adresse IP dans Adresse IP source à l'aide du filtre suivant:
- logName="projects/projectId/logs/compute.googleapis.com%2Fvpc_flows" AND (jsonPayload.connection.src_ip="SOURCE_IP" OR jsonPayload.connection.dest_ip="destIP")
  
  Remplacez les éléments suivants :
  - PROJECT_ID avec le projet répertorié dans projectId.
  - SOURCE_IP par l'adresse IP indiquée sur la ligne Adresse IP source dans l'onglet Résumé des détails de la recherche.

Étape 5: Vérifier l'outil d'analyse des flux

Vous devez activer les journaux de flux VPC pour effectuer la procédure suivante.

Assurez-vous d'avoir mis à niveau votre bucket de journaux pour utiliser l'Analyse de journaux. Pour obtenir des instructions, consultez Mettre à niveau un bucket pour utiliser l'Analyse de journaux. Cette mise à niveau n'entraîne aucuns frais supplémentaires.
Dans la console Google Cloud, accédez à la page Analyseur de flux:

Accéder à Flow Analyzer

Vous pouvez également accéder à Flow Analyzer via le lien URL de Flow Analyzer dans la section Liens associés de l'onglet Récapitulatif du volet Détails de la recherche.
Pour examiner plus en détail les informations concernant le résultat d'Event Threat Detection, utilisez le sélecteur de période dans la barre d'action pour modifier la période. La période doit refléter la date à laquelle le résultat a été signalé pour la première fois. Par exemple, si le résultat a été signalé au cours des deux dernières heures, vous pouvez définir la période sur Dernières six heures. Cela garantit que la période dans l'outil d'analyse des flux inclut l'heure à laquelle le résultat a été signalé.
Filtrez l'analyseur de flux pour afficher les résultats appropriés pour l'adresse IP associée à la découverte d'adresse IP malveillante:
1. Dans le menu Filtre de la ligne Source de la section Requête, sélectionnez IP.
2. Dans le champ Valeur, saisissez l'adresse IP associée à la recherche, puis cliquez sur Exécuter une nouvelle requête.
  
  Si l'analyseur de flux n'affiche aucun résultat pour l'adresse IP, effacez le filtre de la ligne Source, puis exécutez à nouveau la requête avec le même filtre dans la ligne Destination.
Analysez les résultats. Pour en savoir plus sur un flux spécifique, cliquez sur Détails dans le tableau Tous les flux de données pour ouvrir le volet Détails du flux.

Étape 6 : Étudier les méthodes d'attaque et de réponse

Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Résolution dynamique et Commande et contrôle.
Consultez les résultats associés en cliquant sur le lien Résultats associés sur la ligne Résultats associés dans l'onglet Récapitulatif des détails des résultats. Les résultats associés sont du même type de résultat, sur la même instance et sur le même réseau.
Vérifiez les URL et les domaines signalés dans VirusTotal en cliquant sur le lien dans l'indicateur VirusTotal. VirusTotal est un service appartenant à Alphabet qui fournit du contexte sur des fichiers, des URL, des domaines et des adresses IP potentiellement malveillants.
Pour élaborer un plan de réponse, combinez les résultats de vos enquêtes avec la recherche MITRE.

Étape 6 : Mettre en œuvre votre réponse

Contactez le propriétaire du projet contenant les logiciels malveillants.
Examinez l'instance potentiellement compromise et supprimez tous les logiciels malveillants détectés. Pour faciliter la détection et la suppression, utilisez une solution de détection et de gestion des points de terminaison.
Pour suivre l'activité et les failles ayant permis l'insertion de logiciels malveillants, consultez les journaux d'audit et les journaux syslog associés à l'instance compromise.
Si nécessaire, arrêtez l'instance compromise et remplacez-la par une nouvelle instance.
Bloquez les adresses IP malveillantes en mettant à jour les règles de pare-feu ou en utilisant Google Cloud Armor Vous pouvez activer Google Cloud Armor sur la page Services intégrés de Security Command Center. Selon le volume de données, les coûts de Google Cloud Armor peuvent être importants. Pour en savoir plus, consultez le guide des tarifs de Google Cloud Armor.
Pour contrôler les accès et l'utilisation des images de VM, utilisez les stratégies IAM de VM protégée et d'image de confiance.

`Persistence: IAM Anomalous Grant`

Les journaux d'audit sont examinés pour détecter toute attribution d'autorisations IAM (IAM) potentiellement suspecte.

Vous trouverez ci-dessous des exemples d'attributions anormales:

Inviter un utilisateur externe, tel qu'un utilisateur gmail.com, en tant que propriétaire de projet à partir de la console Google Cloud
Compte de service accordant des autorisations sensibles.
Rôle personnalisé accordant des autorisations sensibles.
Compte de service ajouté depuis l'extérieur de votre organisation ou de votre projet

La détection IAM Anomalous Grant est unique en ce sens qu'elle inclut des sous-règles qui fournissent des informations plus spécifiques sur chaque instance de cette détection. La classification de la gravité de ce résultat dépend de la sous-règle. Chaque sous-règle peut nécessiter une réponse différente.

La liste suivante présente toutes les sous-règles possibles et leur sévérité:

external_service_account_added_to_policy :
- HIGH, si un rôle à sensibilité élevée ou un rôle à sensibilité moyenne a été attribué au niveau de l'organisation. Pour en savoir plus, consultez la section Rôles hautement sensibles.
- MEDIUM, si un rôle à sensibilité moyenne a été attribué. Pour en savoir plus, consultez la section Rôles à sensibilité moyenne.
external_member_invited_to_policy : HIGH
external_member_added_to_policy :
- HIGH, si un rôle à sensibilité élevée ou un rôle à sensibilité moyenne a été attribué au niveau de l'organisation. Pour en savoir plus, consultez la section Rôles hautement sensibles.
- MEDIUM, si un rôle à sensibilité moyenne a été attribué. Pour en savoir plus, consultez la section Rôles à sensibilité moyenne.
custom_role_given_sensitive_permissions : MEDIUM
service_account_granted_sensitive_role_to_member : HIGH
policy_modified_by_default_compute_service_account : HIGH

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez un résultat Persistence: IAM Anomalous Grant comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Récapitulatif.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Adresse e-mail du principal: adresse e-mail de l'utilisateur ou du compte de service qui a attribué le rôle.
- Ressource concernée
- Liens associés, en particulier les champs suivants:
  - URI Cloud Logging: lien vers les entrées de journalisation.
  - Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
  - Résultats associés: liens vers les résultats associés.
  - Indicateur VirusTotal: lien vers la page d'analyse VirusTotal.
  - Chronicle: lien vers Google SecOps.
Cliquez sur l'onglet JSON. La représentation JSON complète du résultat s'affiche.
Dans le fichier JSON de la détection, notez les champs suivants:
- detectionCategory :
  - subRuleName: informations plus spécifiques sur le type d'autorisation anormale qui s'est produite. La sous-règle détermine la classification de gravité de ce résultat.
- evidence :
  - sourceLogId :
  - projectId: ID du projet contenant le résultat.
- properties :
  - sensitiveRoleGrant :
    - bindingDeltas :
    - Action: action entreprise par l'utilisateur.
    - Role: rôle attribué à l'utilisateur.
    - member: adresse e-mail de l'utilisateur ayant reçu le rôle.

Étape 2: Analyser dans Google Security Operations

Vous pouvez utiliser Google Security Operations pour examiner ce résultat. Google SecOps est un service Google Cloud qui vous permet d'examiner les menaces et de parcourir les entités associées selon une chronologie simple à utiliser. Google SecOps enrichit les données des résultats, ce qui vous permet d'identifier les indicateurs intéressants et de simplifier les enquêtes.

Vous ne pouvez pas examiner les résultats de Security Command Center dans Chronicle si vous l'activez au niveau du projet.

Accédez à la page Résultats de Security Command Center dans Google Cloud Console.

Accéder
Dans le panneau Filtres rapides, faites défiler la page jusqu'à Nom à afficher pour la source.
Dans la section Nom à afficher pour la source, sélectionnez Event Threat Detection.

La table présente les résultats correspondant au type de source que vous avez sélectionné.
Dans le tableau, sous catégorie, cliquez sur un résultat Persistence: IAM Anomalous Grant. Le panneau d'informations sur la recherche s'ouvre.
Dans la section Liens associés du panneau "Détails du résultat", cliquez sur Examiner dans Chronicle.
Suivez les instructions de l'interface utilisateur guidée de Google SecOps.

Utilisez les guides suivants pour mener des enquêtes dans Google SecOps:

Étape 3 : Vérifier les journaux

Dans l'onglet Récapitulatif du panneau "Détails du résultat", cliquez sur le lien URI Cloud Logging pour ouvrir l'explorateur de journaux.
Sur la page qui s'affiche, recherchez les ressources IAM nouvelles ou mises à jour à l'aide des filtres suivants :
- protoPayload.methodName="SetIamPolicy"
- protoPayload.methodName="google.iam.admin.v1.UpdateRole"
- protoPayload.methodName="google.iam.admin.v1.CreateRole"

Étape 4 : Rechercher des méthodes d'attaque et de réponse

Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Comptes valides: comptes Cloud.
Consultez les résultats associés en cliquant sur le lien de la ligne Résultats associés dans l'onglet Récapitulatif des détails du résultat. Les résultats associés sont du même type de résultat, sur la même instance et sur le même réseau.
Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.

Étape 5 : Mettre en œuvre votre réponse

Contactez le propriétaire du projet contenant le conteneur compromis.
Supprimer le compte de service compromis : et alterner puis supprimer toutes les clés d'accès de compte de service du projet compromis. Après suppression, les ressources qui utilisent le compte de service pour l'authentification perdent l'accès.
Supprimez les ressources de projet créées par des comptes non autorisés telles que les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM inconnus.
Pour limiter l'ajout d'utilisateurs gmail.com, utilisez la règle d'administration.
Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

`Persistence: Impersonation Role Granted for Dormant Service Account`

Détecte les événements où un rôle d'impersonnation est attribué à un principal qui lui permet d'usurper l'identité d'un compte de service géré par l'utilisateur inactif. Dans cette analyse, le compte de service dormant est la ressource concernée. Un compte de service est considéré comme dormant s'il est inactif depuis plus de 180 jours.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Persistence: Impersonation Role Granted for Dormant Service Account, comme indiqué dans la section Examiner les résultats.
Dans les détails du résultat, dans l'onglet Récapitulatif, notez les valeurs des champs suivants.

Sous Risque détecté:
- Adresse e-mail principale: adresse e-mail de l'utilisateur ayant effectué l'action d'octroi
- Offending access grants.Principal name: compte principal auquel le rôle d'impersonation a été attribué
Sous Ressource concernée:
- Nom à afficher de la ressource: compte de service inactif en tant que ressource
- Nom complet du projet: projet dans lequel se trouve ce compte de service inactif

Étape 2 : Étudier les méthodes d'attaque et de réponse

Utilisez des outils de compte de service, comme Activity Analyzer, pour examiner l'activité du compte de service inactif.
Contactez le propriétaire du champ Adresse e-mail principale. Vérifiez si l'action a été effectuée par le propriétaire légitime.

Étape 3 : Vérifier les journaux

Dans l'onglet Récapitulatif du panneau d'informations sur les résultats, sous Liens associés, cliquez sur le lien URI Cloud Logging pour ouvrir l'explorateur de journaux.

Étape 4 : Mettre en œuvre votre réponse

Contactez le propriétaire du projet pour lequel l'action a été prise.
Supprimez l'accès du propriétaire de l'adresse e-mail principale si elle est compromise.
Supprimez le rôle d'impersonation nouvellement attribué au membre cible.
Envisagez de supprimer le compte de service potentiellement compromis et d'alterner puis supprimer toutes les clés d'accès au compte de service du projet potentiellement compromis. Après suppression, les applications qui utilisent le compte de service pour l'authentification perdent l'accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les applications concernées et collaborer avec les propriétaires des applications pour assurer la continuité des opérations.
Collaborez avec votre équipe de sécurité pour identifier les ressources inconnues, y compris les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM. Supprimez les ressources qui n'ont pas été créées avec des comptes autorisés.
Répondez à toutes les notifications de Cloud Customer Care.
Pour limiter les utilisateurs autorisés à créer des comptes de service, utilisez le service de règles d'administration.
Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

`Persistence: Unmanaged Account Granted Sensitive Role`

Détecte les événements où un rôle sensible est accordé à un compte non géré. Les comptes non gérés ne peuvent pas être contrôlés par les administrateurs système. Par exemple, lorsque l'employé correspondant a quitté l'entreprise, l'administrateur ne peut pas supprimer le compte. Par conséquent, attribuer des rôles sensibles à des comptes non gérés crée un risque de sécurité potentiel pour l'organisation.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Persistence: Unmanaged Account Granted Sensitive Role, comme indiqué dans la section Examiner les résultats.
Dans les détails du résultat, dans l'onglet Récapitulatif, notez les valeurs des champs suivants.

Sous Risque détecté:
- Adresse e-mail principale: adresse e-mail de l'utilisateur ayant effectué l'action d'octroi
- Offending access grants.Principal name: compte non géré qui reçoit l'autorisation
- Accès non conformes.Rôle accordé: rôle sensible accordé

Étape 2 : Étudier les méthodes d'attaque et de réponse

Contactez le propriétaire du champ Adresse e-mail principale. Vérifiez si l'action a été effectuée par le propriétaire légitime.
Contactez le propriétaire du champ Offending access grants.Principal name (Accès non autorisé : nom du principal) pour identifier l'origine du compte non géré.

Étape 3 : Vérifier les journaux

Dans l'onglet Récapitulatif du panneau d'informations sur les résultats, sous Liens associés, cliquez sur le lien URI Cloud Logging pour ouvrir l'explorateur de journaux.

Étape 4 : Mettre en œuvre votre réponse

Contactez le propriétaire du projet pour lequel l'action a été prise.
Supprimez l'accès du propriétaire de l'adresse e-mail principale si elle est compromise.
Supprimez le rôle sensible nouvellement attribué du compte non géré.
Envisagez de convertir le compte non géré en compte géré à l'aide de l'outil de transfert, puis de placer ce compte sous le contrôle des administrateurs système.

`Persistence: New API Method`

Une activité d'administrateur anormale par un acteur potentiellement malveillant a été détectée dans une organisation, un dossier ou un projet. Une activité anormale peut être l'une des suivantes:

Nouvelle activité d'un principal dans une organisation, un dossier ou un projet
Activité qui n'a pas été vue depuis un certain temps par un compte principal dans une organisation, un dossier ou un projet

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Persistence: New API Method comme indiqué dans la section Examiner les résultats.
Dans les détails de la recherche, dans l'onglet Récapitulatif, notez les valeurs des champs suivants:
- Sous Ce qui a été détecté :
  - Adresse e-mail principale: compte à l'origine de l'appel
  - Nom du service: nom de l'API du service Google Cloud utilisé dans l'action
  - Nom de la méthode: nom de la méthode appelée.
- Sous Ressource affectée :
  - Nom à afficher de la ressource: nom de la ressource concernée, qui peut être identique à celui de l'organisation, du dossier ou du projet
  - Chemin d'accès à la ressource: emplacement dans la hiérarchie des ressources où l'activité a eu lieu

Étape 2 : Étudier les méthodes d'attaque et de réponse

Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat: Persistance.
Déterminez si l'action était justifiée dans l'organisation, le dossier ou le projet, et si elle a été effectuée par le propriétaire légitime du compte. L'organisation, le dossier ou le projet s'affichent sur la ligne Chemin d'accès aux ressources, et le compte s'affiche sur la ligne Adresse e-mail principale.
Pour élaborer un plan d'intervention, combinez les résultats de vos enquêtes avec les recherches MITRE.

`Persistence: New Geography`

Cette information n'est pas disponible pour les activations au niveau du projet.

Un utilisateur ou un compte de service IAM accède à Google Cloud à partir d'un emplacement anormal, sur la base de la géolocalisation de l'adresse IP à l'origine de la demande.

Étape 1 : Examiner les détails du résultat

Ouvrez un résultat Persistence: New Geography, comme indiqué dans la section Examiner les détails des résultats plus haut sur cette page. Le panneau d'informations du résultat s'ouvre dans l'onglet Résumé.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:

Ce qui a été détecté, en particulier les champs suivants :
- Adresse e-mail principale: compte utilisateur potentiellement compromis.
Ressource concernée, en particulier les champs suivants :
- Nom complet du projet: projet contenant le compte utilisateur potentiellement compromis.
Liens associés, en particulier les champs suivants :
- URI Cloud Logging: lien vers les entrées de journalisation.
- Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
- Résultats associés: liens vers les résultats associés.

Dans la vue détaillée du résultat, cliquez sur l'onglet JSON.
Dans le fichier JSON, notez les champs sourceProperties suivants:
- affectedResources :
  - gcpResourceName : ressource concernée.
- evidence :
  - sourceLogId :
  - projectId: ID du projet contenant le résultat.
- properties :
  - anomalousLocation :
  - anomalousLocation: position actuelle estimée de l'utilisateur.
  - callerIp: adresse IP externe.
  - notSeenInLast: période utilisée pour établir une référence pour un comportement normal.
  - typicalGeolocations: emplacements où l'utilisateur accède généralement aux ressources Google Cloud.

Étape 2 : Vérifier les autorisations du projet et du compte

Dans la console Google Cloud, accédez à la page IAM.

Accéder à IAM
Si nécessaire, sélectionnez le projet répertorié dans le champ projectID du fichier JSON de résultat.
Sur la page qui s'affiche, dans la zone Filtre, saisissez le nom du compte répertorié dans Adresse e-mail principale et vérifiez les rôles attribués.

Étape 3 : Vérifier les journaux

Dans l'onglet Récapitulatif du panneau "Détails du résultat", cliquez sur le lien URI Cloud Logging pour ouvrir l'explorateur de journaux.
Si nécessaire, sélectionnez votre projet.
Sur la page qui s'affiche, vérifiez les journaux d'activité des ressources IAM nouvelles ou mises à jour à l'aide des filtres suivants :
- protoPayload.methodName="SetIamPolicy"
- protoPayload.methodName="google.iam.admin.v1.UpdateRole"
- protoPayload.methodName="google.iam.admin.v1.CreateRole"
- protoPayload.authenticationInfo.principalEmail="principalEmail"

Étape 4 : Rechercher des méthodes d'attaque et de réponse

Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Comptes valides: comptes Cloud.
Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.

Étape 5 : Mettre en œuvre votre réponse

Contactez le propriétaire du projet contenant le conteneur compromis.
Examinez les champs anomalousLocation, typicalGeolocations et notSeenInLast pour vérifier si l'accès est anormal et si le compte a été compromis.
Supprimez les ressources de projet créées par des comptes non autorisés telles que les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM inconnus.
Pour restreindre la création de ressources à des régions spécifiques, consultez Restreindre les emplacements des ressources.
Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

`Persistence: New User Agent`

Cette information n'est pas disponible pour les activations au niveau du projet.

Un compte de service IAM accède à Google Cloud à l'aide d'un logiciel suspect, comme indiqué par un agent utilisateur anormal.

Étape 1 : Examiner les détails du résultat

Ouvrez un résultat Persistence: New User Agent, comme indiqué dans la section Examiner les détails des résultats plus haut sur cette page. Le panneau d'informations du résultat s'ouvre dans l'onglet Résumé.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Adresse e-mail principale: compte de service potentiellement compromis.
- Ressource concernée, en particulier les champs suivants :
  - Nom complet du projet: projet contenant le compte de service potentiellement compromis.
- Liens associés, en particulier les champs suivants :
  - URI Cloud Logging: lien vers les entrées de journalisation.
  - Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
  - Résultats associés: liens vers les résultats associés.
1. Dans la vue détaillée du résultat, cliquez sur l'onglet JSON.
2. Dans le fichier JSON, notez les champs suivants.
- projectId: projet contenant le compte de service potentiellement compromis.
- callerUserAgent: agent utilisateur anormal.
- anomalousSoftwareClassification: type de logiciel.
- notSeenInLast: période utilisée pour établir une référence pour un comportement normal.

Étape 2 : Vérifier les autorisations du projet et du compte

Dans la console Google Cloud, accédez à la page IAM.

Accéder à IAM
Si nécessaire, sélectionnez le projet répertorié dans projectId.
Sur la page qui s'affiche, dans la zone Filtre, saisissez le nom du compte indiqué sur la ligne Adresse e-mail principale de l'onglet Récapitulatif des détails du résultat, puis vérifiez les rôles attribués.
Dans Google Cloud Console, accédez à la page Comptes de service.

Accéder à la page "Comptes de service"
Sur la page qui s'affiche, dans la zone Filtre, saisissez le nom du compte indiqué sur la ligne Adresse e-mail principale de l'onglet Récapitulatif des détails de la recherche.
Vérifiez les clés et les dates de création des clés du compte de service.

Étape 3 : Vérifier les journaux

Dans l'onglet Récapitulatif du panneau "Détails du résultat", cliquez sur le lien URI Cloud Logging pour ouvrir l'explorateur de journaux.
Si nécessaire, sélectionnez votre projet.
Sur la page qui s'affiche, vérifiez les journaux d'activité des ressources IAM nouvelles ou mises à jour à l'aide des filtres suivants :
- proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
- protoPayload.methodName="SetIamPolicy"
- protoPayload.methodName="google.iam.admin.v1.UpdateRole"
- protoPayload.methodName="google.iam.admin.v1.CreateRole"
- protoPayload.authenticationInfo.principalEmail="principalEmail"

Étape 4 : Rechercher des méthodes d'attaque et de réponse

Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Comptes valides : comptes Cloud.
Pour élaborer un plan de réponse, combinez les résultats de vos enquêtes avec la recherche MITRE.

Étape 5 : Mettre en œuvre votre réponse

Contactez le propriétaire du projet contenant le conteneur compromis.
Examinez les champs anomalousSoftwareClassification, callerUserAgent et behaviorPeriod pour vérifier si l'accès est anormal et si le compte a été compromis.
Supprimez les ressources de projet créées par des comptes non autorisés telles que les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM inconnus.
Pour restreindre la création de ressources à des régions spécifiques, consultez Restreindre les emplacements des ressources.
Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

`Privilege Escalation: Changes to sensitive Kubernetes RBAC objects`

Pour élever un privilège, une personne potentiellement malveillante a tenté de modifier un objet RBAC (contrôle des accès basé sur les rôles) ClusterRole, RoleBinding ou ClusterRoleBinding du rôle sensible cluster-admin à l'aide d'une requête PUT ou PATCH.

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Privilege Escalation: Changes to sensitive Kubernetes RBAC objects comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Résumé.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Adresse e-mail principale: compte à l'origine de l'appel.
  - Nom de la méthode: nom de la méthode appelée.
  - Liaisons Kubernetes: liaison Kubernetes sensible ou ClusterRoleBinding modifiée.
- Ressource concernée, en particulier les champs suivants :
  - Nom à afficher de la ressource: cluster Kubernetes dans lequel l'action s'est produite.
- Liens associés, en particulier les champs suivants :
  - URI Cloud Logging: lien vers les entrées de journalisation.
  - Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
  - Résultats associés: liens vers les résultats associés.
Dans la section Ce qui a été détecté, cliquez sur le nom de la liaison dans la ligne Liaisons Kubernetes. Les détails de la liaison s'affichent.
Notez les détails de la liaison dans la liaison affichée.

Étape 2 : Vérifier les journaux

Dans l'onglet Récapitulatif des détails de la recherche dans la console Google Cloud, accédez à l'explorateur de journaux en cliquant sur le lien dans le champ URI Cloud Logging.
Si la valeur de Nom de la méthode était une méthode PATCH, vérifiez le corps de la requête pour voir quelles propriétés ont été modifiées.

Dans les appels update (PUT), l'objet entier est envoyé dans la requête. Les modifications ne sont donc pas aussi claires.
Recherchez d'autres actions effectuées par le principal à l'aide des filtres suivants:
- resource.labels.cluster_name="CLUSTER_NAME"
- protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
  
  Remplacez les éléments suivants :
- CLUSTER_NAME: valeur que vous avez indiquée dans le champ Nom à afficher de la ressource dans les détails de la recherche.
- PRINCIPAL_EMAIL: valeur que vous avez indiquée dans le champ Adresse e-mail principale des détails de la recherche.

Étape 3 : Rechercher des méthodes d'attaque et de réponse

Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Élévation des privilèges.
Vérifiez le degré de sensibilité de l’objet et assurez-vous que la modification est justifiée.
Pour les liaisons, vous pouvez vérifier le sujet et déterminer s'il a besoin du rôle auquel il est lié.
Déterminez s'il existe d'autres signes d'activité malveillante de la part du compte principal dans les journaux.
Si l'adresse e-mail principale n'est pas un compte de service, contactez le propriétaire du compte pour confirmer que ce propriétaire légitime est bien à l'origine de l'action.

Si l'adresse e-mail du compte principal est un compte de service (IAM ou Kubernetes), identifiez la source de la modification pour déterminer sa légitimité.
Pour élaborer un plan de réponse, combinez les résultats de vos enquêtes avec la recherche MITRE.

`Privilege Escalation: Create Kubernetes CSR for master cert`

Pour élever un privilège, une personne potentiellement malveillante a créé une requête de signature de certificat (CSR) maître Kubernetes, ce qui lui permet de disposer de l'accès cluster-admin.

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Privilege Escalation: Create Kubernetes CSR for master cert comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Récapitulatif.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Adresse e-mail principale: compte à l'origine de l'appel.
  - Nom de la méthode: méthode appelée.
- Ressource concernée, en particulier les champs suivants :
  - Nom à afficher de la ressource: cluster Kubernetes dans lequel l'action s'est produite.
- Liens associés, en particulier les champs suivants :
  - URI Cloud Logging: lien vers les entrées de journalisation.
  - Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
  - Résultats associés: liens vers les résultats associés.

Étape 2 : Vérifier les journaux

Dans l'onglet Récapitulatif des détails de la recherche dans la console Google Cloud, accédez à l'explorateur de journaux en cliquant sur le lien dans le champ URI Cloud Logging.
Vérifiez la valeur du champ protoPayload.resourceName pour identifier la demande de signature de certificat spécifique.
Recherchez d'autres actions effectuées par le principal à l'aide des filtres suivants:
- resource.labels.cluster_name="CLUSTER_NAME"
- protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
  
  Remplacez les éléments suivants :
- CLUSTER_NAME: valeur que vous avez indiquée dans le champ Nom à afficher de la ressource dans les détails de la recherche.
- PRINCIPAL_EMAIL: valeur que vous avez indiquée dans le champ Adresse e-mail principale des détails de la recherche.

Étape 3 : Rechercher des méthodes d'attaque et de réponse

Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Élévation des privilèges.
Déterminez si l'accès à cluster-admin était justifié.
Si l'adresse e-mail principale n'est pas un compte de service, contactez le propriétaire du compte pour confirmer que ce propriétaire légitime est bien à l'origine de l'action.

Si l'adresse e-mail du compte principal est un compte de service (IAM ou Kubernetes), identifiez la source de l'action pour déterminer sa légitimité.
Pour élaborer un plan d'intervention, combinez les résultats de vos enquêtes avec la recherche MITRE.

`Privilege Escalation: Creation of sensitive Kubernetes bindings`

Pour élever un privilège, une personne potentiellement malveillante a tenté de créer un objet RoleBinding ou ClusterRoleBinding pour le rôle cluster-admin.

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Privilege Escalation: Creation of sensitive Kubernetes bindings comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Résumé.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Adresse e-mail principale: compte à l'origine de l'appel.
  - Liaisons Kubernetes: liaison Kubernetes sensible ou ClusterRoleBinding créée.
- Ressource concernée, en particulier les champs suivants :
  - Nom à afficher de la ressource: cluster Kubernetes dans lequel l'action s'est produite.
- Liens associés, en particulier les champs suivants :
  - URI Cloud Logging: lien vers les entrées de journalisation.
  - Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
  - Résultats associés: liens vers les résultats associés.

Étape 2 : Vérifier les journaux

Dans l'onglet Récapitulatif des détails de la recherche dans la console Google Cloud, accédez à l'explorateur de journaux en cliquant sur le lien dans le champ URI Cloud Logging.
Recherchez d'autres actions effectuées par le principal à l'aide des filtres suivants:
- resource.labels.cluster_name="CLUSTER_NAME"
- protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
  
  Remplacez les éléments suivants :
- CLUSTER_NAME: valeur que vous avez indiquée dans le champ Nom à afficher de la ressource dans les détails de la recherche.
- PRINCIPAL_EMAIL: valeur que vous avez indiquée dans le champ Adresse e-mail principale des détails de la recherche.

Étape 3 : Rechercher des méthodes d'attaque et de réponse

Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Élévation des privilèges.
Vérifiez le degré de sensibilité de la liaison créée et si les rôles sont nécessaires pour les sujets.
Pour les liaisons, vous pouvez vérifier le sujet et déterminer s'il a besoin du rôle auquel il est lié.
Déterminez s'il existe d'autres signes d'activité malveillante de la part du compte principal dans les journaux.
Si l'adresse e-mail principale n'est pas un compte de service, contactez le propriétaire du compte pour confirmer que ce propriétaire légitime est bien à l'origine de l'action.

Si l'adresse e-mail du compte principal est un compte de service (IAM ou Kubernetes), identifiez la source de l'action pour déterminer sa légitimité.
Pour élaborer un plan d'intervention, combinez les résultats de vos enquêtes avec la recherche MITRE.

`Privilege Escalation: Effectively Anonymous Users Granted GKE Cluster Access`

Quelqu'un a créé une liaison RBAC qui fait référence à l'un des utilisateurs ou groupes suivants:

system:anonymous
system:authenticated
system:unauthenticated

Ces utilisateurs et groupes sont en fait anonymes et doivent être évités lors de la création de liaisons de rôle ou de liaisons de rôle de cluster à des rôles RBAC. Vérifiez la liaison pour vous assurer qu'elle est nécessaire. Si la liaison n'est pas nécessaire, supprimez-la. Pour en savoir plus, consultez le message de journal associé à cette anomalie.

Examinez les liaisons créées qui ont accordé des autorisations d'accès à l'utilisateur system:anonymous, au groupe system:unauthenticated group ou au groupe system:authenticated.
Déterminez s'il existe d'autres signes d'activité malveillante de la part du compte principal dans les journaux d'audit de Cloud Logging.

S'il y a des signes d'activité malveillante, consultez les conseils sur l'examen et la suppression des liaisons ayant autorisé cet accès.

`Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials`

Pour élever un privilège, une personne potentiellement malveillante a émis une requête de signature de certificat (CSR) à l'aide de la commande kubectl, en utilisant des identifiants d'amorçage compromis.

Voici un exemple de commande détectée par cette règle:

kubectl --client-certificate kubelet.crt --client-key kubelet.key --server YOUR_SERVER get csr CSR_NAME

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Résumé.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Adresse e-mail principale: compte à l'origine de l'appel.
  - Nom de la méthode: méthode appelée.
- Sous Ressource affectée :
  - Nom à afficher de la ressource: cluster Kubernetes dans lequel l'action s'est produite.
- Liens associés, en particulier les champs suivants :
  - URI Cloud Logging: lien vers les entrées de journalisation.
  - Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
  - Résultats associés: liens vers les résultats associés.

Étape 2 : Vérifier les journaux

Si le nom de la méthode, que vous avez noté dans le champ Nom de la méthode dans les détails de la recherche, est une méthode GET, procédez comme suit:

Dans l'onglet Récapitulatif des détails de la recherche dans la console Google Cloud, accédez à l'explorateur de journaux en cliquant sur le lien dans le champ URI Cloud Logging.
Vérifiez la valeur du champ protoPayload.resourceName pour identifier la demande de signature de certificat spécifique.

Étape 3 : Rechercher des méthodes d'attaque et de réponse

Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Élévation des privilèges.
Si la CSR spécifique est disponible dans l'entrée de journal, examinez la sensibilité du certificat et déterminez si l'action était justifiée.
Pour élaborer un plan de réponse, combinez les résultats de vos enquêtes avec la recherche MITRE.

`Privilege Escalation: Launch of privileged Kubernetes container`

Un individu potentiellement malveillant a créé un pod contenant des conteneurs privilégiés ou dotés de capacités d'élévation des droits.

Le champ privileged d'un conteneur privilégié est défini sur true. Le champ allowPrivilegeEscalation d'un conteneur doté de fonctionnalités d'élévation des privilèges est défini sur true. Pour en savoir plus, consultez la documentation de référence de l'API SecurityContext v1 Core dans la documentation de Kubernetes.

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Privilege Escalation: Launch of privileged Kubernetes container comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Résumé.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Adresse e-mail principale: compte à l'origine de l'appel.
  - Pods Kubernetes: pod nouvellement créé avec des conteneurs privilégiés.
- Ressource concernée, en particulier les champs suivants :
  - Nom à afficher de la ressource: cluster Kubernetes dans lequel l'action s'est produite.
- Liens associés, en particulier les champs suivants :
  - URI Cloud Logging: lien vers les entrées de journalisation.
  - Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
  - Résultats associés: liens vers les résultats associés.
Dans l'onglet JSON, notez les valeurs des champs du résultat:
- findings.kubernetes.pods[].containers: le conteneur privilégié est apparu dans le pod.

Étape 2 : Vérifier les journaux

Dans l'onglet Récapitulatif des détails de la recherche dans la console Google Cloud, accédez à l'explorateur de journaux en cliquant sur le lien dans le champ URI Cloud Logging.
Recherchez d'autres actions effectuées par le principal à l'aide des filtres suivants:
- resource.labels.cluster_name="CLUSTER_NAME"
- protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
  
  Remplacez les éléments suivants :
- CLUSTER_NAME: valeur que vous avez indiquée dans le champ Nom à afficher de la ressource dans les détails de la recherche.
- PRINCIPAL_EMAIL: valeur que vous avez indiquée dans le champ Adresse e-mail principale des détails de la recherche.

Étape 3 : Rechercher des méthodes d'attaque et de réponse

Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Élévation des privilèges.
Vérifiez que le conteneur créé nécessite un accès aux ressources de l'hôte et aux fonctionnalités du kernel.
Déterminez s'il existe d'autres signes d'activité malveillante de la part du compte principal dans les journaux.
Si l'adresse e-mail du compte principal n'est pas un compte de service, contactez le propriétaire du compte pour confirmer que ce propriétaire légitime est bien à l'origine de l'action.

Si l'adresse e-mail du compte principal est un compte de service (IAM ou Kubernetes), identifiez la source de l'action pour déterminer sa légitimité.
Pour élaborer un plan d'intervention, combinez les résultats de vos enquêtes avec la recherche MITRE.

`Privilege Escalation: Dormant Service Account Granted Sensitive Role`

Détecte les événements où un rôle IAM sensible est attribué à un compte de service géré par l'utilisateur inactif. Dans ce contexte, un compte de service est considéré comme dormant s'il est inactif depuis plus de 180 jours.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Privilege Escalation: Dormant Service Account Granted Sensitive Role, comme indiqué dans la section Examiner les résultats.
Dans les détails du résultat, dans l'onglet Récapitulatif, notez les valeurs des champs suivants.

Sous Risque détecté:
- Adresse e-mail principale: adresse e-mail de l'utilisateur ayant effectué l'action d'octroi
- Offending access grants.Principal name: compte de service inactif ayant reçu le rôle sensible
- Accès non autorisés.Rôle accordé: rôle IAM sensible attribué
Sous Ressource concernée:
- Nom à afficher de la ressource: organisation, dossier ou projet dans lequel le rôle IAM sensible a été accordé au compte de service inactif.

Étape 2 : Étudier les méthodes d'attaque et de réponse

Utilisez des outils de compte de service, comme Activity Analyzer, pour examiner l'activité du compte de service inactif.
Contactez le propriétaire du champ Adresse e-mail principale. Vérifiez si l'action a été effectuée par le propriétaire légitime.

Étape 3 : Vérifier les journaux

Dans l'onglet Récapitulatif du panneau d'informations sur les résultats, sous Liens associés, cliquez sur le lien URI Cloud Logging pour ouvrir l'explorateur de journaux.

Étape 4 : Mettre en œuvre votre réponse

Contactez le propriétaire du projet pour lequel l'action a été prise.
Supprimez l'accès du propriétaire de l'adresse e-mail principale si elle est compromise.
Supprimez le rôle IAM sensible nouvellement attribué du compte de service inactif.
Envisagez de supprimer le compte de service potentiellement compromis et d'alterner puis supprimer toutes les clés d'accès au compte de service du projet potentiellement compromis. Après suppression, les ressources qui utilisent le compte de service pour l'authentification perdent l'accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les ressources affectées et collaborer avec les propriétaires des ressources pour assurer la continuité des opérations.
Collaborez avec votre équipe de sécurité pour identifier les ressources inconnues, y compris les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM. Supprimez les ressources qui n'ont pas été créées avec des comptes autorisés.
Répondez à toutes les notifications de Cloud Customer Care.
Pour limiter les utilisateurs autorisés à créer des comptes de service, utilisez le service de règles d'administration.
Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

`Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity`

L'emprunt d'identité de compte de service anormal est détecté en examinant les journaux d'audit des activités d'administration pour voir si une anomalie s'est produite dans une requête d'emprunt d'identité de compte de service.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity, comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Récapitulatif.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Adresse e-mail du principal: compte de service final de la requête d'usurpation d'identité utilisée pour accéder à Google Cloud.
  - Nom du service: nom de l'API du service Google Cloud impliqué dans la requête d'usurpation d'identité.
  - Nom de la méthode: méthode appelée.
  - Informations de délégation de compte de service: détails des comptes de service dans la chaîne de délégation. Le principal en bas de la liste est l'appelant de la requête d'usurpation d'identité.
- Ressource concernée, en particulier les champs suivants :
  - Nom complet de la ressource: nom du cluster.
- Liens associés, en particulier les champs suivants :
  - URI Cloud Logging: lien vers les entrées de journalisation.
  - Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
  - Résultats associés: liens vers les résultats associés.

Étape 2 : Étudier les méthodes d'attaque et de réponse

Contactez le propriétaire du compte de service dans le champ Adresse e-mail principale. Vérifiez si l'action a été effectuée par le propriétaire légitime.
Examinez les principaux de la chaîne de délégation pour vérifier si la requête est anormale et si un compte a été compromis.
Contactez le propriétaire de l'appelant d'usurpation d'identité dans la liste Informations de délégation du compte de service. Vérifiez si l'action a été effectuée par le propriétaire légitime.

Étape 3: Mettre en œuvre votre réponse

Contactez le propriétaire du projet pour lequel l'action a été prise.
Envisagez de supprimer le compte de service potentiellement compromis et d'alterner puis supprimer toutes les clés d'accès au compte de service du projet potentiellement compromis. Après suppression, les ressources qui utilisent le compte de service pour l'authentification perdent l'accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les ressources affectées et collaborer avec les propriétaires des ressources pour assurer la continuité des opérations.
Collaborez avec votre équipe de sécurité pour identifier les ressources inconnues, y compris les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM. Supprimez les ressources qui n'ont pas été créées avec des comptes autorisés.
Répondez à toutes les notifications de l'assistance Google Cloud.
Pour limiter les utilisateurs autorisés à créer des comptes de service, utilisez le service de règles d'administration.
Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

`Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity`

Anomalous Multistep Service Account Delegation est détecté en examinant les journaux d'audit des activités d'administration pour voir si une anomalie s'est produite dans une requête d'usurpation d'identité de compte de service.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity, comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Résumé.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Adresse e-mail du principal: compte de service final de la requête d'usurpation d'identité utilisée pour accéder à Google Cloud.
  - Nom du service: nom de l'API du service Google Cloud impliqué dans la requête d'usurpation d'identité.
  - Nom de la méthode: méthode appelée.
  - Informations de délégation de compte de service: détails des comptes de service dans la chaîne de délégation. Le principal en bas de la liste est l'appelant de la requête d'usurpation d'identité.
- Ressource concernée
- Liens associés, en particulier les champs suivants :
  - URI Cloud Logging: lien vers les entrées de journalisation.
  - Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
  - Résultats associés: liens vers les résultats associés.

Étape 2 : Étudier les méthodes d'attaque et de réponse

Contactez le propriétaire du compte de service dans le champ Adresse e-mail principale. Vérifiez si l'action a été effectuée par le propriétaire légitime.
Examinez les principaux de la chaîne de délégation pour vérifier si la requête est anormale et si un compte a été compromis.
Contactez le propriétaire de l'appelant d'usurpation d'identité dans la liste Informations de délégation du compte de service. Vérifiez si l'action a été effectuée par le propriétaire légitime.

Étape 3: Mettre en œuvre votre réponse

Contactez le propriétaire du projet pour lequel l'action a été prise.
Envisagez de supprimer le compte de service potentiellement compromis et d'alterner puis supprimer toutes les clés d'accès au compte de service du projet potentiellement compromis. Après suppression, les ressources qui utilisent le compte de service pour l'authentification perdent l'accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les ressources affectées et collaborer avec les propriétaires des ressources pour assurer la continuité des opérations.
Collaborez avec votre équipe de sécurité pour identifier les ressources inconnues, y compris les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM. Supprimez les ressources qui n'ont pas été créées avec des comptes autorisés.
Répondez à toutes les notifications de l'assistance Google Cloud.
Pour limiter les utilisateurs autorisés à créer des comptes de service, utilisez le service de règles d'administration.
Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

`Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access`

Anomalous Multistep Service Account Delegation est détecté en examinant les journaux d'audit de l'accès aux données pour voir si une anomalie s'est produite dans une requête d'usurpation d'identité de compte de service.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access, comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Récapitulatif.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Adresse e-mail du principal: compte de service final de la requête d'usurpation d'identité utilisée pour accéder à Google Cloud
  - Nom du service: nom de l'API du service Google Cloud impliqué dans la requête d'usurpation d'identité
  - Nom de la méthode: méthode appelée
  - Informations de délégation de compte de service: détails des comptes de service dans la chaîne de délégation. Le principal en bas de la liste est l'appelant de la requête d'usurpation d'identité.
- Ressource concernée
- Liens associés, en particulier les champs suivants :
  - URI Cloud Logging: lien vers les entrées de journalisation.
  - Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
  - Résultats associés: liens vers les résultats associés.

Étape 2 : Étudier les méthodes d'attaque et de réponse

Contactez le propriétaire du compte de service dans le champ Adresse e-mail principale. Vérifiez si l'action a été effectuée par le propriétaire légitime.
Examinez les principaux de la chaîne de délégation pour vérifier si la requête est anormale et si un compte a été compromis.
Contactez le propriétaire de l'appelant d'usurpation d'identité dans la liste Informations de délégation du compte de service. Vérifiez si l'action a été effectuée par le propriétaire légitime.

Étape 3: Mettre en œuvre votre réponse

Contactez le propriétaire du projet pour lequel l'action a été prise.
Envisagez de supprimer le compte de service potentiellement compromis et d'alterner puis supprimer toutes les clés d'accès au compte de service du projet potentiellement compromis. Après suppression, les ressources qui utilisent le compte de service pour l'authentification perdent l'accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les ressources affectées et collaborer avec les propriétaires des ressources pour assurer la continuité des opérations.
Collaborez avec votre équipe de sécurité pour identifier les ressources inconnues, y compris les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM. Supprimez les ressources qui n'ont pas été créées avec des comptes autorisés.
Répondez à toutes les notifications de l'assistance Google Cloud.
Pour limiter les utilisateurs autorisés à créer des comptes de service, utilisez le service de règles d'administration.
Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

`Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity`

Anomalous Service Account Impersonator est détecté en examinant les journaux d'audit des activités d'administration pour voir si une anomalie s'est produite dans une requête d'emprunt d'identité de compte de service.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity, comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Récapitulatif.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Risque détecté, en particulier les champs suivants:
  - Adresse e-mail du principal: compte de service final de la requête d'usurpation d'identité utilisée pour accéder à Google Cloud
  - Nom du service: nom de l'API du service Google Cloud impliqué dans la requête d'usurpation d'identité
  - Nom de la méthode: méthode appelée
  - Informations de délégation de compte de service: détails des comptes de service dans la chaîne de délégation. Le principal en bas de la liste est l'appelant de la requête d'usurpation d'identité.
- Ressource concernée
- Liens associés, en particulier les champs suivants:
  - URI Cloud Logging: lien vers les entrées de journalisation.
  - Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
  - Résultats associés: liens vers les résultats associés.

Étape 2 : Étudier les méthodes d'attaque et de réponse

Contactez le propriétaire du compte de service dans le champ Adresse e-mail principale. Vérifiez si l'action a été effectuée par le propriétaire légitime.
Examinez les principaux de la chaîne de délégation pour vérifier si la requête est anormale et si un compte a été compromis.
Contactez le propriétaire de l'appelant d'usurpation d'identité dans la liste Informations de délégation du compte de service. Vérifiez si l'action a été effectuée par le propriétaire légitime.

Étape 3: Mettre en œuvre votre réponse

Contactez le propriétaire du projet pour lequel l'action a été prise.
Envisagez de supprimer le compte de service potentiellement compromis et d'alterner puis supprimer toutes les clés d'accès au compte de service du projet potentiellement compromis. Après suppression, les ressources qui utilisent le compte de service pour l'authentification perdent l'accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les ressources affectées et collaborer avec les propriétaires des ressources pour assurer la continuité des opérations.
Collaborez avec votre équipe de sécurité pour identifier les ressources inconnues, y compris les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM. Supprimez les ressources qui n'ont pas été créées avec des comptes autorisés.
Répondez à toutes les notifications de l'assistance Google Cloud.
Pour limiter les utilisateurs autorisés à créer des comptes de service, utilisez le service de règles d'administration.
Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

`Privilege Escalation: Anomalous Service Account Impersonator for Data Access`

L'emprunt d'identité de compte de service anormal est détecté en examinant les journaux d'audit de l'accès aux données pour voir si une anomalie s'est produite dans une requête d'usurpation d'identité de compte de service.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Privilege Escalation: Anomalous Service Account Impersonator for Data Access, comme indiqué dans la section Examiner les résultats.
Dans les détails de la recherche, dans l'onglet Récapitulatif, notez les valeurs des champs suivants.

Sous Risque détecté:
- Adresse e-mail du principal: compte de service final de la requête d'usurpation d'identité utilisée pour accéder à Google Cloud
- Nom du service: nom de l'API du service Google Cloud impliqué dans la requête d'usurpation d'identité
- Nom de la méthode: méthode appelée
- Informations de délégation de compte de service: détails des comptes de service dans la chaîne de délégation. Le principal en bas de la liste est l'appelant de la requête d'usurpation d'identité.

Étape 2 : Étudier les méthodes d'attaque et de réponse

Contactez le propriétaire du compte de service dans le champ Adresse e-mail principale. Vérifiez si l'action a été effectuée par le propriétaire légitime.
Examinez les principaux de la chaîne de délégation pour vérifier si la requête est anormale et si un compte a été compromis.
Contactez le propriétaire de l'appelant d'usurpation d'identité dans la liste Informations de délégation du compte de service. Vérifiez si l'action a été effectuée par le propriétaire légitime.

Étape 3: Mettre en œuvre votre réponse

Contactez le propriétaire du projet pour lequel l'action a été prise.
Envisagez de supprimer le compte de service potentiellement compromis et d'alterner puis supprimer toutes les clés d'accès au compte de service du projet potentiellement compromis. Après suppression, les ressources qui utilisent le compte de service pour l'authentification perdent l'accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les ressources affectées et collaborer avec les propriétaires des ressources pour assurer la continuité des opérations.
Collaborez avec votre équipe de sécurité pour identifier les ressources inconnues, y compris les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM. Supprimez les ressources qui n'ont pas été créées avec des comptes autorisés.
Répondez à toutes les notifications de l'assistance Google Cloud.
Pour limiter les utilisateurs autorisés à créer des comptes de service, utilisez le service de règles d'administration.
Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

`Privilege Escalation: ClusterRole with Privileged Verbs`

Quelqu'un a créé un objet ClusterRole RBAC contenant les verbes bind, escalate ou impersonate. Un sujet lié à un rôle avec ces verbes peut usurper l'identité d'autres utilisateurs disposant de droits plus élevés, se lier à des objets Role ou ClusterRole supplémentaires contenant des autorisations supplémentaires, ou modifier ses propres autorisations ClusterRole. Cela peut entraîner l'octroi de privilèges cluster-admin à ces sujets. Pour en savoir plus, consultez le message de journal de cette alerte.

Examinez le ClusterRole et le ClusterRoleBindings associé pour vérifier si les sujets ont réellement besoin de ces autorisations.
Si possible, évitez de créer des rôles qui impliquent les verbes bind, escalate ou impersonate.
Déterminez s'il existe d'autres signes d'activité malveillante de la part du compte principal dans les journaux d'audit de Cloud Logging.
Lorsque vous attribuez des autorisations dans un rôle RBAC, appliquez le principe du moindre privilège en n'accordant que les autorisations minimales nécessaires pour effectuer une tâche. Le principe du moindre privilège réduit le risque d'élévation des privilèges si votre cluster est compromis, et réduit la probabilité d'un incident de sécurité en cas d'accès excessifs.

`Privilege Escalation: ClusterRoleBinding to Privileged Role`

Quelqu'un a créé un ClusterRoleBinding RBAC qui fait référence à l'ClusterRole system:controller:clusterrole-aggregation-controller par défaut. Ce ClusterRole par défaut contient le verbe escalate, qui permet aux sujets de modifier les privilèges de leurs propres rôles, ce qui permet d'escalader les privilèges. Pour en savoir plus, consultez le message de journal de cette alerte.

Examinez tous les ClusterRoleBinding qui font référence à l'ClusterRole system:controller:clusterrole-aggregation-controller.
Examinez les modifications apportées à la ClusterRole system:controller:clusterrole-aggregation-controller.
Déterminez s'il existe d'autres signes d'activité malveillante de la part du compte principal qui a créé l'ClusterRoleBinding dans les journaux d'audit de Cloud Logging.

`Privilege Escalation: Suspicious Kubernetes Container Names - Exploitation and Escape`

Quelqu'un a déployé un pod avec une convention d'attribution de noms semblable à celle d'outils courants utilisés pour les échappements de conteneur ou pour exécuter d'autres attaques sur le cluster. Pour en savoir plus, consultez le message de journal de cette alerte.

Vérifiez que le pod est légitime.
Déterminez s'il existe d'autres signes d'activité malveillante de la part du pod ou du compte principal dans les journaux d'audit de Cloud Logging.
Si le compte principal n'est pas un compte de service (IAM ou Kubernetes), contactez le propriétaire du compte pour confirmer que ce propriétaire légitime est bien à l'origine de l'action.
Si le compte principal est un compte de service (IAM ou Kubernetes), identifiez la source de l'action pour déterminer sa légitimité.
Si le pod n'est pas légitime, supprimez-le, ainsi que toutes les liaisons RBAC et comptes de service associés utilisés par la charge de travail qui ont permis sa création.

`Privilege Escalation: Workload Created with a Sensitive Host Path Mount`

Quelqu'un a créé une charge de travail contenant un montage de volume hostPath sur un chemin sensible dans le système de fichiers du nœud hôte. L'accès à ces chemins d'accès sur le système de fichiers hôte peut être utilisé pour accéder à des informations privilégiées ou sensibles sur le nœud et pour échapper aux conteneurs. Si possible, n'autorisez aucun volume hostPath dans votre cluster. Pour en savoir plus, consultez le message de journal de cette alerte.

Examinez la charge de travail pour déterminer si ce volume hostPath est nécessaire pour la fonctionnalité envisagée. Si c'est le cas, veillez à ce que le chemin d'accès soit le plus spécifique possible. (par exemple, /etc/myapp/myfiles au lieu de / ou /etc).
Déterminez s'il existe d'autres signes d'activité malveillante liée à cette charge de travail dans les journaux d'audit de Cloud Logging.

Pour bloquer l'installation de volumes hostPath dans le cluster, consultez les conseils sur l'application des normes de sécurité des pods.

`Privilege Escalation: Workload with shareProcessNamespace enabled`

Quelqu'un a déployé une charge de travail avec l'option shareProcessNamespace définie sur true, ce qui permet à tous les conteneurs de partager le même espace de noms de processus Linux. Cela pourrait permettre à un conteneur non approuvé ou compromis d'élever les droits d'accès en accédant et en contrôlant les variables d'environnement, la mémoire et d'autres données sensibles à partir de processus exécutés dans d'autres conteneurs. Certaines charges de travail peuvent nécessiter que cette fonctionnalité fonctionne pour des raisons légitimes, telles que la gestion des journaux des conteneurs sidecar ou le débogage des conteneurs. Pour en savoir plus, consultez le message de journal de cette alerte.

Vérifiez que la charge de travail nécessite réellement l'accès à un espace de noms de processus partagé pour tous les conteneurs de la charge de travail.
Vérifiez s'il existe d'autres signes d'activité malveillante de la part du compte principal dans les journaux d'audit de Cloud Logging.
Si le compte principal n'est pas un compte de service (IAM ou Kubernetes), contactez le propriétaire du compte pour confirmer qu'il est bien à l'origine de l'action.
Si le compte principal est un compte de service (IAM ou Kubernetes), assurez-vous de la légitimité de ce qui a amené le compte de service à effectuer cette action.

`Service account self-investigation`

Des identifiants de compte de service sont utilisés pour examiner les rôles et les autorisations associés à ce même compte de service. Ce résultat indique que les identifiants du compte de service pourraient être compromis et qu'une action immédiate doit être effectuée.

Étape 1 : Examiner les détails du résultat

Ouvrez un résultat Discovery: Service Account Self-Investigation, comme indiqué dans la section Examiner les détails des résultats plus haut sur cette page. Le panneau d'informations du résultat s'ouvre dans l'onglet Résumé.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Gravité: niveau de risque attribué au résultat. La gravité est HIGH si l'appel d'API qui a déclenché ce résultat n'est pas autorisé. Le compte de service n'est pas autorisé à interroger ses propres autorisations IAM avec l'API projects.getIamPolicy.
  - Adresse e-mail principale: compte de service potentiellement compromis.
  - Adresse IP de l'appelant: adresse IP interne ou externe
- Ressource concernée, en particulier les champs suivants :
  - Nom complet de la ressource:
  - Nom complet du projet: projet contenant les identifiants de compte potentiellement divulgués.
- Liens associés, en particulier les champs suivants :
  - URI Cloud Logging: lien vers les entrées de journalisation.
  - Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
  - Résultats associés: liens vers les résultats associés.
1. Pour afficher le code JSON complet du résultat, cliquez sur l'onglet JSON.

Étape 2 : Vérifier les autorisations des projets et des comptes de service

Dans la console Google Cloud, accédez à la page IAM.

Accéder à IAM
Si nécessaire, sélectionnez le projet répertorié dans le champ projectID du fichier JSON du résultat.
Sur la page qui s'affiche, dans la zone Filtre, saisissez le nom du compte répertorié dans Adresse e-mail principale et vérifiez les autorisations attribuées.
Dans Google Cloud Console, accédez à la page Comptes de service.

Accéder à la page "Comptes de service"
Sur la page qui s'affiche, dans le champ Filtre, saisissez le nom du compte de service compromis et vérifiez ses clés ainsi que les dates de création des clés.

Étape 3 : Vérifier les journaux

Dans l'onglet Récapitulatif du panneau "Détails du résultat", cliquez sur le lien URI Cloud Logging pour ouvrir l'explorateur de journaux.
Si nécessaire, sélectionnez votre projet.
Sur la page qui s'affiche, vérifiez les journaux d'activité des ressources IAM nouvelles ou mises à jour à l'aide des filtres suivants :
- proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
- protoPayload.methodName="SetIamPolicy"
- protoPayload.authenticationInfo.principalEmail="principalEmail"

Étape 4 : Rechercher des méthodes d'attaque et de réponse

Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Découverte de groupes d'autorisations : Groupes Cloud.
Pour élaborer un plan de réponse, combinez les résultats de vos enquêtes avec la recherche MITRE.

Étape 5 : Mettre en œuvre votre réponse

Contactez le propriétaire du projet contenant le conteneur compromis.
Supprimer le compte de service compromis : et alterner puis supprimer toutes les clés d'accès de compte de service du projet compromis. Après suppression, les ressources qui utilisent le compte de service pour l'authentification perdent l'accès.
Supprimez les ressources de projet créées par le compte compromis telles que les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM inconnus.

`Inhibit System Recovery: Deleted Google Cloud Backup and DR host`

Event Threat Detection examine les journaux d'audit pour détecter la suppression d'hôtes exécutant des applications protégées par le service de sauvegarde et de reprise après sinistre. Une fois un hôte supprimé, les applications qui lui sont associées ne peuvent plus être sauvegardées.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Inhibit System Recovery: Deleted Google Cloud Backup and DR host, comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Résumé.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :
- Ce qui a été détecté, en particulier les champs suivants :
  - Nom de l'application: nom d'une base de données ou d'une VM connectée à la sauvegarde et à la reprise après sinistre
  - Nom d'hôte: nom d'un hôte connecté à la sauvegarde et à la reprise après sinistre
  - Principal subject (sujet principal) : utilisateur ayant correctement exécuté une action
- Ressource concernée
  - Nom à afficher de la ressource: projet dans lequel l'hôte a été supprimé
- Liens associés, en particulier les champs suivants :
  - Méthode MITRE ATTACK: lien vers la documentation MITRE ATT&CK
  - URI de journalisation: lien permettant d'ouvrir l'explorateur de journaux

Étape 2 : Étudier les méthodes d'attaque et de réponse

Contactez le propriétaire du compte de service dans le champ Adresse e-mail principale. Vérifiez si l'action a été effectuée par le propriétaire légitime.

Étape 3: Mettre en œuvre votre réponse

Dans le projet pour lequel l'action a été effectuée, accédez à la console de gestion.
Vérifiez que l'hôte supprimé ne figure plus dans la liste des hôtes de sauvegarde et de reprise après sinistre.
Sélectionnez l'option Ajouter un hôte pour ajouter à nouveau l'hôte supprimé.

`Inhibit System Recovery: Google Cloud Backup and DR remove plan`

Security Command Center examine les journaux d'audit pour détecter la suppression anormale d'un plan de sauvegarde du service Backup and DR utilisé pour appliquer des règles de sauvegarde à une application.

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Inhibit System Recovery: Google Cloud Backup and DR remove plan, comme indiqué dans la section Examiner les résultats. Le panneau d'informations de la non-conformité s'ouvre dans l'onglet Récapitulatif.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :
- Ce qui a été détecté, en particulier les champs suivants :
  - Nom de l'application: nom d'une base de données ou d'une VM connectée à la sauvegarde et à la reprise après sinistre
  - Profile name (Nom du profil) : spécifie la cible de stockage pour les sauvegardes des données d'application et de VM.
  - Nom du modèle: nom d'un ensemble de règles qui définissent la fréquence, la planification et la durée de conservation des sauvegardes
- Ressource concernée
  - Nom à afficher de la ressource: projet dans lequel le plan a été supprimé
- Liens Associés, en particulier les champs suivants :
  - Méthode MITRE ATTACK: lien vers la documentation MITRE ATT&CK
  - URI de journalisation: lien permettant d'ouvrir l'explorateur de journaux

Étape 2 : Étudier les méthodes d'attaque et de réponse

Contactez le propriétaire du compte de service dans le champ Adresse e-mail principale. Vérifiez si l'action a été effectuée par le propriétaire légitime.

Étape 3: Mettre en œuvre votre réponse

Dans le projet pour lequel l'action a été effectuée, accédez à la console de gestion.
Dans l'onglet Gestionnaire d'applications, recherchez les applications concernées qui ne sont plus protégées et examinez les règles de sauvegarde pour chacune d'elles.

`Inhibit System Recovery: Google Cloud Backup and DR delete template`

Security Command Center examine les journaux d'audit pour détecter la suppression anormale d'un modèle. Un modèle est une configuration de base pour les sauvegardes qui peut être appliquée à plusieurs applications.

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Inhibit System Recovery: Google Cloud Backup and DR delete template, comme indiqué dans la section Examiner les résultats. Le panneau d'informations de la non-conformité s'ouvre dans l'onglet Récapitulatif.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :
- Ce qui a été détecté, en particulier les champs suivants :
  - Nom du modèle: nom d'un ensemble de règles qui définissent la fréquence, la planification et la durée de conservation des sauvegardes
  - Principal subject (Principal sujet) : utilisateur ayant correctement exécuté une action
- Ressource concernée
  - Nom à afficher de la ressource: projet dans lequel le modèle a été supprimé
- Liens Associés, en particulier les champs suivants :
  - Méthode MITRE ATTACK: lien vers la documentation MITRE ATT&CK
  - URI de journalisation: lien permettant d'ouvrir l'explorateur de journaux

Étape 2 : Étudier les méthodes d'attaque et de réponse

Contactez le propriétaire du compte de service dans le champ Adresse e-mail principale. Vérifiez si l'action a été effectuée par le propriétaire légitime.

Étape 3: Mettre en œuvre votre réponse

Dans le projet dans lequel l'action a été effectuée, accédez à la console de gestion.
Dans l'onglet Gestionnaire d'applications, recherchez les applications concernées qui ne sont plus protégées et examinez les règles de sauvegarde pour chacune d'elles.
Pour ajouter à nouveau un modèle, accédez à l'onglet Plans de sauvegarde, sélectionnez Modèles, puis l'option Créer un modèle.

`Inhibit System Recovery: Google Cloud Backup and DR delete policy`

Les journaux d'audit sont examinés pour détecter la suppression d'une règle. Une stratégie définit comment une sauvegarde est effectuée et où elle est stockée.

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Inhibit System Recovery: Google Cloud Backup and DR delete policy, comme indiqué dans la section Examiner les résultats. Le panneau d'informations de la non-conformité s'ouvre dans l'onglet Récapitulatif.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :
- Ce qui a été détecté, en particulier les champs suivants :
  - Nom de la règle: nom d'une règle unique, qui définit la fréquence, la planification et la durée de conservation des sauvegardes
  - Principal subject (sujet principal) : utilisateur ayant correctement exécuté une action
- Ressource concernée
  - Nom à afficher de la ressource: projet dans lequel la règle a été supprimée
- Liens Associés, en particulier les champs suivants :
  - Méthode MITRE ATTACK: lien vers la documentation MITRE ATT&CK
  - URI de journalisation: lien permettant d'ouvrir l'explorateur de journaux.

Étape 2 : Étudier les méthodes d'attaque et de réponse

Contactez le propriétaire du compte de service dans le champ Adresse e-mail principale. Vérifiez si l'action a été effectuée par le propriétaire légitime.

Étape 3: Mettre en œuvre votre réponse

`Inhibit System Recovery: Google Cloud Backup and DR delete profile`

Les journaux d'audit sont examinés pour détecter la suppression d'une fiche. Un profil définit les pools de stockage utilisés pour stocker les sauvegardes.

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Inhibit System Recovery: Google Cloud Backup and DR delete profile, comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Résumé.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :
- Ce qui a été détecté, en particulier les champs suivants :
  - Profile name (Nom du profil) : spécifie la cible de stockage pour les sauvegardes des données d'application et de VM.
  - Principal subject (sujet principal) : utilisateur ayant correctement exécuté une action
- Ressource concernée
  - Nom à afficher de la ressource: projet dans lequel le profil a été supprimé
- Liens Associés, en particulier les champs suivants :
  - Méthode MITRE ATTACK: lien vers la documentation MITRE ATT&CK
  - URI de journalisation: lien permettant d'ouvrir l'explorateur de journaux

Étape 2 : Étudier les méthodes d'attaque et de réponse

Contactez le propriétaire du compte de service dans le champ Adresse e-mail principale. Vérifiez si l'action a été effectuée par le propriétaire légitime.

Étape 3: Mettre en œuvre votre réponse

`Inhibit System Recovery: Google Cloud Backup and DR delete storage pool`

Les journaux d'audit sont examinés pour détecter la suppression d'un pool de stockage. Un pool de stockage associe un bucket Cloud Storage à la sauvegarde et à la reprise après sinistre.

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Inhibit System Recovery: Google Cloud Backup and DR delete storage pool, comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Résumé.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :
- Ce qui a été détecté, en particulier les champs suivants :
  - Nom du pool de stockage: nom des buckets de stockage dans lesquels les sauvegardes sont stockées
  - Principal subject (Principal sujet) : utilisateur ayant correctement exécuté une action
- Ressource concernée
  - Nom à afficher de la ressource: projet dans lequel le pool de stockage a été supprimé
- Liens Associés, en particulier les champs suivants :
  - Méthode MITRE ATTACK: lien vers la documentation MITRE ATT&CK
  - URI de journalisation: lien permettant d'ouvrir l'explorateur de journaux

Étape 2 : Étudier les méthodes d'attaque et de réponse

Contactez le propriétaire du compte de service dans le champ Adresse e-mail principale. Vérifiez si l'action a été effectuée par le propriétaire légitime.

Étape 3: Mettre en œuvre votre réponse

`Data Destruction: Google Cloud Backup and DR expire image`

Un acteur potentiellement malveillant a demandé à supprimer une image de sauvegarde.

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Inhibit System Recovery: Google Cloud Backup and DR expire image, comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Résumé.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :
- Ce qui a été détecté, en particulier les champs suivants :
  - Nom de la règle: nom d'une règle unique, qui définit la fréquence, la planification et la durée de conservation des sauvegardes
  - Nom du modèle: nom d'un ensemble de règles qui définissent la fréquence, la planification et la durée de conservation des sauvegardes
  - Profile name (Nom du profil) : spécifie la cible de stockage pour les sauvegardes des données d'application et de VM.
  - Principal subject (sujet principal) : utilisateur ayant correctement exécuté une action
- Ressource concernée
  - Nom à afficher pour la ressource: projet dans lequel l'image de sauvegarde a été supprimée
- Liens Associés, en particulier les champs suivants :
  - Méthode MITRE ATTACK: lien vers la documentation MITRE ATT&CK
  - URI de journalisation: lien permettant d'ouvrir l'explorateur de journaux

Étape 2 : Étudier les méthodes d'attaque et de réponse

Contactez le propriétaire du compte de service dans le champ Adresse e-mail principale. Vérifiez si l'action a été effectuée par le propriétaire légitime.

Étape 3: Mettre en œuvre votre réponse

`Data Destruction: Google Cloud Backup and DR expire all images`

Un acteur potentiellement malveillant a demandé à supprimer toutes les images de sauvegarde associées à une application.

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Inhibit System Recovery: Google Cloud Backup and DR expire all images, comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Résumé.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :
- Ce qui a été détecté, en particulier les champs suivants :
  - Nom de la règle: nom d'une règle unique, qui définit la fréquence, la planification et la durée de conservation des sauvegardes
  - Nom du modèle: nom d'un ensemble de règles qui définissent la fréquence, la planification et la durée de conservation des sauvegardes
  - Profile name (Nom du profil) : spécifie la cible de stockage pour les sauvegardes des données d'application et de VM.
  - Principal subject (sujet principal) : utilisateur ayant correctement exécuté une action
- Ressource concernée
  - Nom à afficher pour la ressource: projet dans lequel les images de sauvegarde ont été supprimées
- Liens Associés, en particulier les champs suivants :
  - Méthode MITRE ATTACK: lien vers la documentation MITRE ATT&CK
  - URI de journalisation: lien permettant d'ouvrir l'explorateur de journaux.

Étape 2 : Étudier les méthodes d'attaque et de réponse

Contactez le propriétaire du compte de service dans le champ Adresse e-mail principale. Vérifiez si l'action a été effectuée par le propriétaire légitime.

Étape 3: Mettre en œuvre votre réponse

`Data Destruction: Google Cloud Backup and DR remove appliance`

Les journaux d'audit sont examinés pour détecter la suppression d'un appareil de sauvegarde et de récupération. Un appareil de sauvegarde et de récupération est un composant essentiel pour les opérations de sauvegarde.

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Inhibit System Recovery: Google Cloud Backup and DR remove appliance, comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Résumé.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :
- Ce qui a été détecté, en particulier les champs suivants :
  - Nom de l'appliance: nom d'une base de données ou d'une VM connectée à la sauvegarde et à la DR
  - Principal subject (sujet principal) : utilisateur ayant correctement exécuté une action
- Ressource concernée
  - Nom à afficher de la ressource: projet dans lequel l'appareil a été supprimé
- Liens Associés, en particulier les champs suivants :
  - Méthode MITRE ATTACK: lien vers la documentation MITRE ATT&CK
  - URI de journalisation: lien permettant d'ouvrir l'explorateur de journaux

Étape 2 : Étudier les méthodes d'attaque et de réponse

Contactez le propriétaire du compte de service dans le champ Adresse e-mail principale. Vérifiez si l'action a été effectuée par le propriétaire légitime.

Étape 3: Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de résoudre les menaces détectées. 1. Dans le projet pour lequel l'action a été effectuée, accédez à la console de gestion. 2. Dans l'onglet Gestionnaire d'applications, recherchez les applications concernées qui ne sont plus protégées et examinez les règles de sauvegarde pour chacune d'elles. 3. Pour créer un appareil et réappliquer les protections aux applications non protégées, accédez à "Sauvegarde et reprise après sinistre" dans la console Google Cloud, puis sélectionnez l'option "Déployer un autre appareil de sauvegarde ou de reprise après sinistre". 4. Dans le menu Storage (Stockage), configurez chaque nouvel appareil avec une cible de stockage. Une fois que vous avez configuré un appareil, il s'affiche comme une option lorsque vous créez un profil pour vos applications.

`Impact: Google Cloud Backup and DR reduced backup expiration`

Event Threat Detection examine les journaux d'audit pour déterminer si la date d'expiration d'une sauvegarde sur un appareil de service de sauvegarde et de reprise après sinistre a été réduite.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Impact: Google Cloud Backup and DR reduced backup expiration, comme indiqué dans la section Examiner les résultats. Le panneau d'informations de la recherche s'ouvre dans l'onglet Récapitulatif.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :
- Ce qui a été détecté, en particulier les champs suivants :
  - Description: informations sur la détection
  - Objet principal: compte utilisateur ou de service ayant correctement exécuté une action
- Ressource concernée
  - Nom à afficher de la ressource: projet dans lequel l'expiration de la sauvegarde a été réduite.
- Liens associés, en particulier les champs suivants :
  - Méthode MITRE ATTACK: lien vers la documentation MITRE ATT&CK.
  - URI de journalisation: lien permettant d'ouvrir l'explorateur de journaux.

Étape 2 : Étudier les méthodes d'attaque et de réponse

Contactez le propriétaire du compte de service dans le champ Objet principal. Vérifiez si l'action a été effectuée par le propriétaire légitime.

Étape 3: Mettre en œuvre votre réponse

Dans le projet pour lequel l'action a été effectuée, accédez à la console de gestion.
Dans l'onglet Gestionnaire d'applications, recherchez l'application concernée pour laquelle l'expiration de la sauvegarde a été réduite et vérifiez que l'expiration était prévue par le compte principal.
Pour lancer une nouvelle sauvegarde de l'application, sélectionnez Gérer les configurations de sauvegarde afin de créer une sauvegarde à la demande ou de planifier une nouvelle sauvegarde.

`Impact: Google Cloud Backup and DR reduced backup frequency`

Event Threat Detection examine les journaux d'audit pour détecter si le plan de sauvegarde a été modifié pour réduire la fréquence des sauvegardes.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Impact: Google Cloud Backup and DR reduced backup frequency, comme indiqué dans la section Examiner les résultats. Le panneau d'informations de la recherche s'ouvre dans l'onglet Récapitulatif.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :
- Ce qui a été détecté, en particulier les champs suivants :
  - Description: informations sur la détection
  - Objet principal: compte utilisateur ou de service ayant correctement exécuté une action
- Ressource concernée
  - Nom à afficher de la ressource: projet dans lequel la fréquence de sauvegarde a été réduite.
- Liens associés, en particulier les champs suivants :
  - Méthode MITRE ATTACK: lien vers la documentation MITRE ATT&CK.
  - URI de journalisation: lien permettant d'ouvrir l'explorateur de journaux.

Étape 2 : Étudier les méthodes d'attaque et de réponse

Contactez le propriétaire du compte de service dans le champ Objet principal. Vérifiez si l'action a été effectuée par le propriétaire légitime.

Étape 3: Mettre en œuvre votre réponse

Dans le projet pour lequel l'action a été effectuée, accédez à la console de gestion.
Dans l'onglet Gestionnaire d'applications, recherchez l'application concernée pour laquelle la fréquence de sauvegarde a été réduite et vérifiez que la modification était intentionnelle de la part du principal.
Pour lancer une nouvelle sauvegarde de l'application, sélectionnez Gérer les configurations de sauvegarde afin de créer une sauvegarde à la demande ou de planifier une nouvelle sauvegarde.

`Impact: Suspicious Kubernetes Container Names - Coin Mining`

Quelqu'un a déployé un pod avec une convention d'attribution de noms semblable à celle des mineurs de cryptomonnaies courants. Il peut s'agir d'une tentative d'un pirate informatique qui a obtenu un accès initial au cluster pour utiliser ses ressources à des fins de minage de cryptomonnaie. Pour en savoir plus, consultez le message de journal de cette alerte.

Vérifiez que le pod est légitime.
Déterminez s'il existe d'autres signes d'activité malveillante de la part du pod ou du compte principal dans les journaux d'audit de Cloud Logging.
Si le compte principal n'est pas un compte de service (IAM ou Kubernetes), contactez le propriétaire du compte pour confirmer que ce propriétaire légitime est bien à l'origine de l'action.
Si le compte principal est un compte de service (IAM ou Kubernetes), identifiez la source de l'action pour déterminer sa légitimité.
Si le pod n'est pas légitime, supprimez-le, ainsi que toutes les liaisons RBAC et comptes de service associés utilisés par la charge de travail qui ont permis sa création.

`Lateral Movement: Modified Boot Disk Attached to Instance`

Les journaux d'audit sont examinés pour détecter les mouvements de disque suspects parmi les ressources d'instance Compute Engine. Un disque de démarrage potentiellement modifié a été associé à votre instance Compute Engine.

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Lateral Movement: Modify Boot Disk Attaching to Instance, comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Résumé.
Dans l'onglet Récapitulatif, notez les valeurs des champs suivants.

Sous Risque détecté:
- Adresse e-mail principale: compte de service ayant effectué l'action
- Nom du service: nom de l'API du service Google Cloud auquel le compte de service a accédé
- Nom de la méthode: nom de la méthode appelée.

Étape 2 : Étudier les méthodes d'attaque et de réponse

Utilisez des outils de compte de service, comme Activity Analyzer, pour examiner l'activité du compte de service associé.
Contactez le propriétaire du compte de service dans le champ Adresse e-mail principale. Vérifiez si l'action a été effectuée par le propriétaire légitime.

Étape 3: Mettre en œuvre votre réponse

Contactez le propriétaire du projet pour lequel l'action a été prise.
Envisagez d'utiliser le démarrage sécurisé pour vos instances de VM Compute Engine.
Envisagez de supprimer le compte de service potentiellement compromis et d'alterner puis supprimer toutes les clés d'accès au compte de service du projet potentiellement compromis. Après suppression, les applications qui utilisent le compte de service pour l'authentification perdent l'accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les applications concernées et collaborer avec les propriétaires des applications pour assurer la continuité des opérations.
Collaborez avec votre équipe de sécurité pour identifier les ressources inconnues, y compris les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM. Supprimez les ressources qui n'ont pas été créées avec des comptes autorisés.
Répondez à toutes les notifications de l'assistance Google Cloud.

`Privilege Escalation: AlloyDB Over-Privileged Grant`

Détecte lorsque tous les droits associés à une base de données AlloyDB pour PostgreSQL (ou toutes les fonctions ou procédures d'une base de données) sont accordés à un ou plusieurs utilisateurs de la base de données.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Privilege Escalation: AlloyDB Over-Privileged Grant, comme indiqué dans la section Examiner les résultats.
Dans l'onglet Récapitulatif du panneau "Détails du résultat", examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Nom à afficher de la base de données: nom de la base de données de l'instance AlloyDB pour PostgreSQL concernée.
  - Nom d'utilisateur de la base de données: utilisateur PostgreSQL ayant accordé des droits en excès.
  - Requête de base de données: requête PostgreSQL exécutée ayant accordé les droits.
  - Bénéficiaires de la base de données: bénéficiaires des droits trop larges.
- Ressource concernée, en particulier les champs suivants :
  - Nom complet de la ressource: nom de la ressource de l'instance AlloyDB pour PostgreSQL concernée.
  - Nom complet du parent: nom de la ressource de l'instance AlloyDB pour PostgreSQL.
  - Nom complet du projet: projet Google Cloud contenant l'instance AlloyDB pour PostgreSQL.
- Liens associés, en particulier les champs suivants :
  - URI Cloud Logging: lien vers les entrées de journalisation.
  - Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
Pour afficher le code JSON complet du résultat, cliquez sur l'onglet JSON.

Étape 2 : Vérifier les droits associés à la base de données

Connectez-vous à l'instance AlloyDB pour PostgreSQL.
Regroupez et affichez les droits d'accès pour les éléments suivants :
- Bases de données. Utilisez la métacommande \l ou \list et vérifiez les droits attribués à la base de données répertoriée dans Database display name (Nom à afficher de la base de données) (voir Étape 1).
- Fonctions ou procédures. Utilisez la métacommande \df et vérifiez les privilèges attribués aux fonctions ou procédures dans la base de données spécifiée dans Nom à afficher de la base de données (voir Étape 1).

Étape 3 : Vérifier les journaux

Dans la console Google Cloud, accédez à l'explorateur de journaux en cliquant sur le lien dans URI de journalisation Cloud (étape 1). La page Explorateur de journaux inclut tous les journaux liés à l'instance Cloud SQL concernée.
Dans l'explorateur de journaux, vérifiez les journaux pgaudit PostgreSQL, qui enregistrent les requêtes exécutées dans la base de données, à l'aide des filtres suivants :
- protoPayload.request.database="var class="edit">database"

Étape 4 : Rechercher des méthodes d'attaque et de réponse

Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Exfiltration over Web Service (Exfiltration via service Web).
Pour déterminer si d'autres mesures correctives sont nécessaires, combinez vos résultats d'enquête avec la recherche MITRE.

Étape 5 : Mettre en œuvre votre réponse

Contactez le propriétaire de l'instance disposant d'autorisations excessives.
Envisagez de révoquer toutes les autorisations des bénéficiaires listés dans Bénéficiaires de la base de données jusqu'à ce que l'enquête soit terminée.
Pour limiter l'accès à la base de données (à partir de l'élément Database display name (Nom à afficher de la base de données) de l'Étape 1, révoquez les autorisations inutiles accordées par les bénéficiaires (à partir de l'élément Database grantees (Bénéficiaires de la base de données) de l'Étape 1.

`Privilege Escalation: AlloyDB Database Superuser Writes to User Tables`

Détecte quand le compte super-utilisateur de la base de données AlloyDB pour PostgreSQL (postgres) écrit dans les tables utilisateur. Le super-utilisateur (un rôle disposant d'un accès très étendu) ne doit généralement pas être utilisé pour écrire dans les tables utilisateur. Un compte utilisateur avec des droits d'accès plus limités doit être utilisé pour les activités quotidiennes normales. Lorsqu'un super-utilisateur écrit dans une table utilisateur, cela peut indiquer qu'un pirate informatique a élevé ses privilèges ou compromis l'utilisateur de base de données par défaut, et qu'il est en train de modifier des données. Il peut également indiquer des pratiques normales, mais non sécurisées.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez un résultat Privilege Escalation: AlloyDB Database Superuser Writes to User Tables, comme indiqué dans la section Examiner les résultats.
Dans l'onglet Résumé du panneau "Détails du résultat", examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Nom à afficher de la base de données: nom de la base de données de l'instance AlloyDB pour PostgreSQL concernée.
  - Nom d'utilisateur de la base de données: super-utilisateur.
  - Requête de base de données: requête SQL exécutée lors de l'écriture dans les tables utilisateur.
- Ressource concernée, en particulier les champs suivants :
  - Nom complet de la ressource: nom de la ressource de l'instance AlloyDB pour PostgreSQL concernée.
  - Nom complet du parent: nom de la ressource de l'instance AlloyDB pour PostgreSQL.
  - Nom complet du projet: projet Google Cloud contenant l'instance AlloyDB pour PostgreSQL.
- Liens associés, en particulier les champs suivants :
  - URI Cloud Logging: lien vers les entrées de journalisation.
  - Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
Pour afficher le code JSON complet du résultat, cliquez sur l'onglet JSON.

Étape 2 : Vérifier les journaux

Dans la console Google Cloud, accédez à l'explorateur de journaux en cliquant sur le lien figurant dans cloudLoggingQueryURI (étape 1). La page Explorateur de journaux inclut tous les journaux liés à l'instance AlloyDB pour PostgreSQL concernée.
Recherchez les journaux pgaudit PostgreSQL, qui contiennent les requêtes exécutées par le super-utilisateur, à l'aide des filtres suivants :
- protoPayload.request.user="postgres"

Étape 3 : Rechercher des méthodes d'attaque et de réponse

Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Exfiltration over Web Service (Exfiltration via service Web).
Pour déterminer si d'autres mesures correctives sont nécessaires, combinez vos résultats d'enquête avec la recherche MITRE.

Étape 4 : Mettre en œuvre votre réponse

Vérifiez les utilisateurs autorisés à se connecter à la base de données.
Envisagez de modifier le mot de passe du super-utilisateur.
Envisagez de créer un utilisateur à accès limité pour les différents types de requêtes utilisés sur l'instance.
- N'accordez au nouvel utilisateur que les autorisations nécessaires pour exécuter ses requêtes.
- Mettre à jour les identifiants des clients qui se connectent à l'instance AlloyDB pour PostgreSQL

Détection des métadonnées de l'administrateur Compute Engine

`Persistence: GCE Admin Added SSH Key`

Description Actions

Description	Actions
La clé de métadonnées de l'instance Compute Engine `ssh-keys` a été modifiée sur une instance établie.	La clé de métadonnées de l'instance Compute Engine `ssh-keys` a été modifiée sur une instance créée il y a plus de sept jours. Vérifiez si la modification a été effectuée intentionnellement par un membre ou si elle a été mise en œuvre par une personne mal intentionnée pour créer un nouvel accès à votre organisation.	Vérifiez les journaux à l'aide des filtres suivants : `protopayload.resource.labels.instance_id=INSTANCE_ID` `protoPayload.serviceName="compute.googleapis.com"` `(protoPayload.metadata.instanceMetaData.addedMetadataKey : "ssh-keys" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "ssh-keys" )` `logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity` Remplacez les éléments suivants : `INSTANCE_ID` : valeur `gceInstanceId` répertoriée dans le résultat `ORGANIZATION_ID` : ID de votre organisation.
Événements de recherche qui déclenchent ce résultat : MITRE : https://attack.mitre.org/techniques/T1098/004/

La clé de métadonnées de l'instance Compute Engine ssh-keys a été modifiée sur une instance établie.

La clé de métadonnées de l'instance Compute Engine ssh-keys a été modifiée sur une instance créée il y a plus de sept jours. Vérifiez si la modification a été effectuée intentionnellement par un membre ou si elle a été mise en œuvre par une personne mal intentionnée pour créer un nouvel accès à votre organisation.

Vérifiez les journaux à l'aide des filtres suivants :

protopayload.resource.labels.instance_id=INSTANCE_ID

protoPayload.serviceName="compute.googleapis.com"

(protoPayload.metadata.instanceMetaData.addedMetadataKey : "ssh-keys" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "ssh-keys" )

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity

Remplacez les éléments suivants :

INSTANCE_ID : valeur gceInstanceId répertoriée dans le résultat
ORGANIZATION_ID : ID de votre organisation.

Événements de recherche qui déclenchent ce résultat :

MITRE : https://attack.mitre.org/techniques/T1098/004/

`Persistence: GCE Admin Added Startup Script`

Description Actions

Description	Actions
La clé de métadonnées de l'instance Compute Engine `startup-script` ou `startup-script-url` a été modifiée sur une instance établie.	La clé de métadonnées de l'instance Compute Engine `startup-script` ou `startup-script-url` a été modifiée sur une instance créée il y a plus de sept jours. Vérifiez si la modification a été effectuée intentionnellement par un membre ou si elle a été mise en œuvre par une personne mal intentionnée pour créer un nouvel accès à votre organisation.	Vérifiez les journaux à l'aide des filtres suivants : `protopayload.resource.labels.instance_id=INSTANCE_ID` `protoPayload.serviceName="compute.googleapis.com"` `((protoPayload.metadata.instanceMetaData.addedMetadataKey : "startup-script" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "startup-script" )` `OR (protoPayload.metadata.instanceMetaData.addedMetadataKey : "startup-script-url" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "startup-script-url" ))` `logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity` Remplacez les éléments suivants : `INSTANCE_ID` : valeur `gceInstanceId` répertoriée dans le résultat `ORGANIZATION_ID` : ID de votre organisation.
Événements de recherche qui déclenchent ce résultat : MITRE : https://attack.mitre.org/techniques/T1098/004/

La clé de métadonnées de l'instance Compute Engine startup-script ou startup-script-url a été modifiée sur une instance établie.

La clé de métadonnées de l'instance Compute Engine startup-script ou startup-script-url a été modifiée sur une instance créée il y a plus de sept jours. Vérifiez si la modification a été effectuée intentionnellement par un membre ou si elle a été mise en œuvre par une personne mal intentionnée pour créer un nouvel accès à votre organisation.

Vérifiez les journaux à l'aide des filtres suivants :

protopayload.resource.labels.instance_id=INSTANCE_ID

protoPayload.serviceName="compute.googleapis.com"

((protoPayload.metadata.instanceMetaData.addedMetadataKey : "startup-script" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "startup-script" )

OR (protoPayload.metadata.instanceMetaData.addedMetadataKey : "startup-script-url" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "startup-script-url" ))

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity

Remplacez les éléments suivants :

INSTANCE_ID : valeur gceInstanceId répertoriée dans le résultat
ORGANIZATION_ID : ID de votre organisation.

Événements de recherche qui déclenchent ce résultat :

MITRE : https://attack.mitre.org/techniques/T1098/004/

Détection des journaux Google Workspace

Si vous partagez vos journaux Google Workspace avec Cloud Logging, Event Threat Detection génère des résultats pour plusieurs menaces Google Workspace. Étant donné que les journaux Google Workspace sont au niveau de l'organisation, Event Threat Detection ne peut les analyser que si vous activez Security Command Center au niveau de l'organisation.

Event Threat Detection enrichit les événements des journaux et écrit les résultats dans Security Command Center. Le tableau suivant contient les menaces Google Workspace, les entrées pertinentes du framework MITRE ATT&CK et les détails des événements qui déclenchent des résultats. Vous pouvez également vérifier les journaux à l'aide de filtres spécifiques et combiner toutes les informations pour répondre aux menaces Google Workspace.

`Initial Access: Disabled Password Leak`

Ce résultat n'est pas disponible si vous activez Security Command Center au niveau du projet.

Description Actions

Le compte d'un membre est désactivé, car une fuite de mot de passe a été détectée.

Réinitialisez les mots de passe des comptes concernés et conseillez aux membres de choisir des mots de passe uniques et sécurisés pour les comptes professionnels.

Description	Actions
Le compte d'un membre est désactivé, car une fuite de mot de passe a été détectée.	Réinitialisez les mots de passe des comptes concernés et conseillez aux membres de choisir des mots de passe uniques et sécurisés pour les comptes professionnels.	Vérifiez les journaux à l'aide des filtres suivants : `protopayload.resource.labels.service="login.googleapis.com"` `logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access` Remplacez `ORGANIZATION_ID` par votre ID d'organisation.
Événements de recherche qui déclenchent ce résultat : MITRE : https://attack.mitre.org/techniques/T1078/ Détails de l'événement Workspace : https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#account_disabled_password_leak

Vérifiez les journaux à l'aide des filtres suivants :

protopayload.resource.labels.service="login.googleapis.com"

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access

Remplacez ORGANIZATION_ID par votre ID d'organisation.

Événements de recherche qui déclenchent ce résultat :

MITRE : https://attack.mitre.org/techniques/T1078/
Détails de l'événement Workspace : https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#account_disabled_password_leak

`Initial Access: Suspicious Login Blocked`

Ce résultat n'est pas disponible si vous activez Security Command Center au niveau du projet.

Description Actions

Une connexion suspecte au compte d'un membre a été détectée et bloquée.

Ce compte peut être ciblé par des personnes mal intentionnées. Assurez-vous que le compte utilisateur respecte les consignes de sécurité de votre organisation concernant les mots de passe sécurisés et l'authentification multifacteur.

Description	Actions
Une connexion suspecte au compte d'un membre a été détectée et bloquée.	Ce compte peut être ciblé par des personnes mal intentionnées. Assurez-vous que le compte utilisateur respecte les consignes de sécurité de votre organisation concernant les mots de passe sécurisés et l'authentification multifacteur.	Vérifiez les journaux à l'aide des filtres suivants : `protopayload.resource.labels.service="login.googleapis.com"` `logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access` Remplacez `ORGANIZATION_ID` par votre ID d'organisation.
Événements de recherche qui déclenchent ce résultat : MITRE : https://attack.mitre.org/techniques/T1078/ Détails de l'événement Workspace : https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#suspicious_login

Vérifiez les journaux à l'aide des filtres suivants :

protopayload.resource.labels.service="login.googleapis.com"

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access

Remplacez ORGANIZATION_ID par votre ID d'organisation.

Événements de recherche qui déclenchent ce résultat :

MITRE : https://attack.mitre.org/techniques/T1078/
Détails de l'événement Workspace : https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#suspicious_login

`Initial Access: Account Disabled Hijacked`

Ce résultat n'est pas disponible si vous activez Security Command Center au niveau du projet.

Description Actions

Le compte d'un membre a été suspendu en raison d'une activité suspecte.

Ce compte a été piraté. Réinitialisez le mot de passe du compte d'entreprise et encouragez les utilisateurs à en créer des mots de passe uniques et sécurisés.

Description	Actions
Le compte d'un membre a été suspendu en raison d'une activité suspecte.	Ce compte a été piraté. Réinitialisez le mot de passe du compte d'entreprise et encouragez les utilisateurs à en créer des mots de passe uniques et sécurisés.	Vérifiez les journaux à l'aide des filtres suivants : `protopayload.resource.labels.service="login.googleapis.com"` `logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access` Remplacez `ORGANIZATION_ID` par votre ID d'organisation.
Événements de recherche qui déclenchent ce résultat : MITRE : https://attack.mitre.org/techniques/T1078/ Détails de l'événement Workspace : https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#account_disabled_hijacked

Vérifiez les journaux à l'aide des filtres suivants :

protopayload.resource.labels.service="login.googleapis.com"

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access

Remplacez ORGANIZATION_ID par votre ID d'organisation.

Événements de recherche qui déclenchent ce résultat :

MITRE : https://attack.mitre.org/techniques/T1078/
Détails de l'événement Workspace : https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#account_disabled_hijacked

`Impair Defenses: Two Step Verification Disabled`

Ce résultat n'est pas disponible si vous activez Security Command Center au niveau du projet.

Description Actions

Un membre a désactivé la validation en deux étapes.

Vérifiez si l'utilisateur a essayé de désactiver la validation en deux étapes. Si votre organisation requiert la validation en deux étapes, assurez-vous que l'utilisateur l'active rapidement.

Description	Actions
Un membre a désactivé la validation en deux étapes.	Vérifiez si l'utilisateur a essayé de désactiver la validation en deux étapes. Si votre organisation requiert la validation en deux étapes, assurez-vous que l'utilisateur l'active rapidement.	Vérifiez les journaux à l'aide des filtres suivants : `protopayload.resource.labels.service="login.googleapis.com"` `logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access` Remplacez `ORGANIZATION_ID` par votre ID d'organisation.
Événements de recherche qui déclenchent ce résultat : MITRE : https://attack.mitre.org/techniques/T1562/ Détails de l'événement Workspace : https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#2sv_disable

Vérifiez les journaux à l'aide des filtres suivants :

protopayload.resource.labels.service="login.googleapis.com"

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access

Remplacez ORGANIZATION_ID par votre ID d'organisation.

Événements de recherche qui déclenchent ce résultat :

MITRE : https://attack.mitre.org/techniques/T1562/
Détails de l'événement Workspace : https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#2sv_disable

`Initial Access: Government Based Attack`

Ce résultat n'est pas disponible si vous activez Security Command Center au niveau du projet.

Description Actions

Les pirates informatiques soutenus par un gouvernement ont peut-être tenté de compromettre le compte ou l'ordinateur d'un membre.

Description	Actions
Les pirates informatiques soutenus par un gouvernement ont peut-être tenté de compromettre le compte ou l'ordinateur d'un membre.	Ce compte peut être ciblé par des personnes mal intentionnées. Assurez-vous que le compte utilisateur respecte les consignes de sécurité de votre organisation concernant les mots de passe sécurisés et l'authentification multifacteur.	Vérifiez les journaux à l'aide des filtres suivants : `protopayload.resource.labels.service="login.googleapis.com"` `logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access` Remplacez `ORGANIZATION_ID` par votre ID d'organisation.
Événements de recherche qui déclenchent ce résultat : MITRE : https://attack.mitre.org/techniques/T1078/ Détails de l'événement Workspace : https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#gov_attack_warning

Vérifiez les journaux à l'aide des filtres suivants :

protopayload.resource.labels.service="login.googleapis.com"

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access

Remplacez ORGANIZATION_ID par votre ID d'organisation.

Événements de recherche qui déclenchent ce résultat :

MITRE : https://attack.mitre.org/techniques/T1078/
Détails de l'événement Workspace : https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#gov_attack_warning

`Persistence: SSO Enablement Toggle`

Ce résultat n'est pas disponible si vous activez Security Command Center au niveau du projet.

Description Actions

Le paramètre "Activer SSO" (Authentification unique) a été désactivé pour le compte administrateur.

Les paramètres SSO de votre organisation ont été modifiés. Vérifiez si la modification a été effectuée intentionnellement par un membre ou si elle a été mise en œuvre par une personne mal intentionnée pour créer un nouvel accès à votre organisation.

Description	Actions
Le paramètre "Activer SSO" (Authentification unique) a été désactivé pour le compte administrateur.	Les paramètres SSO de votre organisation ont été modifiés. Vérifiez si la modification a été effectuée intentionnellement par un membre ou si elle a été mise en œuvre par une personne mal intentionnée pour créer un nouvel accès à votre organisation.	Vérifiez les journaux à l'aide des filtres suivants : `protopayload.resource.labels.service="admin.googleapis.com"` `protopayload.metadata.event.parameter.value=DOMAIN_NAME` `logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity` Remplacez les éléments suivants : `DOMAIN_NAME` : valeur `domainName` répertoriée dans le résultat `ORGANIZATION_ID` : ID de votre organisation.
Événements de recherche qui déclenchent ce résultat : MITRE : https://attack.mitre.org/techniques/T1098/ Détails de l'événement Workspace : https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-domain-settings#TOGGLE_SSO_ENABLED

Vérifiez les journaux à l'aide des filtres suivants :

protopayload.resource.labels.service="admin.googleapis.com"

protopayload.metadata.event.parameter.value=DOMAIN_NAME

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity

Remplacez les éléments suivants :

DOMAIN_NAME : valeur domainName répertoriée dans le résultat
ORGANIZATION_ID : ID de votre organisation.

Événements de recherche qui déclenchent ce résultat :

MITRE : https://attack.mitre.org/techniques/T1098/
Détails de l'événement Workspace : https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-domain-settings#TOGGLE_SSO_ENABLED

`Persistence: SSO Settings Changed`

Ce résultat n'est pas disponible si vous activez Security Command Center au niveau du projet.

Description Actions

Les paramètres SSO du compte administrateur ont été modifiés.

Description	Actions
Les paramètres SSO du compte administrateur ont été modifiés.	Les paramètres SSO de votre organisation ont été modifiés. Vérifiez si la modification a été effectuée intentionnellement par un membre ou si elle a été mise en œuvre par une personne mal intentionnée pour créer un nouvel accès à votre organisation.	Vérifiez les journaux à l'aide des filtres suivants : `protopayload.resource.labels.service="admin.googleapis.com"` `protopayload.metadata.event.parameter.value=DOMAIN_NAME` `logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity` Remplacez les éléments suivants : `DOMAIN_NAME` : valeur `domainName` répertoriée dans le résultat `ORGANIZATION_ID` : ID de votre organisation.
Événements de recherche qui déclenchent ce résultat : MITRE : https://attack.mitre.org/techniques/T1098/ Détails de l'événement Workspace : https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-domain-settings#CHANGE_SSO_SETTINGS

Vérifiez les journaux à l'aide des filtres suivants :

protopayload.resource.labels.service="admin.googleapis.com"

protopayload.metadata.event.parameter.value=DOMAIN_NAME

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity

Remplacez les éléments suivants :

DOMAIN_NAME : valeur domainName répertoriée dans le résultat
ORGANIZATION_ID : ID de votre organisation.

Événements de recherche qui déclenchent ce résultat :

MITRE : https://attack.mitre.org/techniques/T1098/
Détails de l'événement Workspace : https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-domain-settings#CHANGE_SSO_SETTINGS

`Impair Defenses: Strong Authentication Disabled`

Ce résultat n'est pas disponible si vous activez Security Command Center au niveau du projet.

Description Actions

La validation en deux étapes a été désactivée pour l'organisation.

La validation en deux étapes n'est plus nécessaire pour votre organisation. Déterminez s'il s'agit d'une modification de règle intentionnelle de la part d'un administrateur, ou s'il s'agit d'une tentative de la part d'une personne mal intentionnée visant à faciliter le piratage du compte.

Description	Actions
La validation en deux étapes a été désactivée pour l'organisation.	La validation en deux étapes n'est plus nécessaire pour votre organisation. Déterminez s'il s'agit d'une modification de règle intentionnelle de la part d'un administrateur, ou s'il s'agit d'une tentative de la part d'une personne mal intentionnée visant à faciliter le piratage du compte.	Vérifiez les journaux à l'aide des filtres suivants : `protopayload.resource.labels.service="admin.googleapis.com"` `logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity` Remplacez `ORGANIZATION_ID` par votre ID d'organisation.
Événements de recherche qui déclenchent ce résultat : MITRE : https://attack.mitre.org/techniques/T1562/ Détails de l'événement Workspace : https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-security-settings#ENFORCE_STRONG_AUTHENTICATION

Vérifiez les journaux à l'aide des filtres suivants :

protopayload.resource.labels.service="admin.googleapis.com"

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity

Remplacez ORGANIZATION_ID par votre ID d'organisation.

Événements de recherche qui déclenchent ce résultat :

MITRE : https://attack.mitre.org/techniques/T1562/
Détails de l'événement Workspace : https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-security-settings#ENFORCE_STRONG_AUTHENTICATION

Réagir aux menaces Google Workspace

Les résultats pour Google Workspace ne sont disponibles que pour les activations de Security Command Center au niveau de l'organisation. Les journaux Google Workspace ne peuvent pas être analysés pour les activations au niveau du projet.

Si vous êtes administrateur Google Workspace, vous pouvez utiliser les outils de sécurité du service pour résoudre ces menaces :

Ces outils incluent des alertes, un tableau de bord de sécurité et des recommandations de sécurité qui peuvent vous aider à examiner et à résoudre les menaces.

Si vous n'êtes pas administrateur Google Workspace, procédez comme suit :

Si vous avez encore accès à votre compte, modifiez ou réinitialisez votre mot de passe et activez la validation en deux étapes.
Contactez votre administrateur Google Workspace ou l'équipe de votre entreprise qui gère votre compte Google Workspace. Utilisez ces résultats pour indiquer qu'un compte peut être compromis.

Détections de menaces Cloud IDS

`Cloud IDS: THREAT_ID`

Les résultats Cloud IDS sont générés par Cloud IDS, un service de sécurité qui surveille le trafic vers et depuis vos ressources Google Cloud à la recherche de menaces. Lorsque Cloud IDS détecte une menace, il envoie des informations à son sujet, telles que l'adresse IP source, l'adresse de destination et le numéro de port, à Event Threat Detection, qui émet ensuite une détection de menace.

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Cloud IDS: THREAT_ID, comme indiqué dans la section Examiner les résultats.
Dans les détails du résultat, dans l'onglet Récapitulatif, examinez les valeurs indiquées dans les sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Protocole: protocole réseau utilisé
  - Heure de l'événement: heure à laquelle l'événement s'est produit
  - Description: informations supplémentaires sur la détection
  - Severity (Gravité) : gravité de l'alerte
  - Adresse IP de destination: adresse IP cible du trafic réseau
  - Port de destination: port cible du trafic réseau.
  - Adresse IP source: adresse IP source du trafic réseau
  - Port source: port source du trafic réseau
- Ressource concernée, en particulier les champs suivants :
  - Nom complet de la ressource: projet contenant le réseau contenant la menace
- Liens associés, en particulier les champs suivants :
  - URI Cloud Logging: lien vers les entrées de journalisation Cloud IDS. Ces entrées contiennent les informations nécessaires pour rechercher dans le Threat Vault de Palo Alto Networks.
- Service de détection
  - Catégorie de résultat : nom de la menace Cloud IDS
Pour afficher le code JSON complet du résultat, cliquez sur l'onglet JSON.

Étape 2: Rechercher des méthodes d'attaque et de réponse

Après avoir examiné les détails de la recherche, veuillez consulter la documentation Cloud IDS sur l'examen des alertes de menace pour déterminer la réponse appropriée.

Pour en savoir plus sur l'événement détecté dans l'entrée de journal d'origine, cliquez sur le lien dans le champ URI Cloud Logging des détails de la recherche.

Réponses Container Threat Detection

Pour en savoir plus sur Container Threat Detection, découvrez le fonctionnement de Container Threat Detection.

`Added Binary Executed`

Un fichier binaire ne faisant pas partie de l'image de conteneur d'origine a été exécuté. Les pirates informatiques installent généralement les outils d'exploitation et les logiciels malveillants après le piratage initial. Il est important de s'assurer que vos conteneurs sont immuables. Il s'agit d'un résultat de faible gravité, car il est possible que votre organisation ne suive pas cette bonne pratique. Des résultats Execution: Added Malicious Binary Executed correspondants sont disponibles lorsque le hachage du binaire est un indicateur de compromission (IoC) connu. Pour répondre à ce résultat, procédez comme suit:

Étape 1 : Examiner les détails du résultat

Ouvrez un résultat Added Binary Executed comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Récapitulatif.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Binaire du programme: chemin d'accès absolu du binaire ajouté.
  - Arguments: arguments fournis lors de l'appel du binaire ajouté.
- Ressource concernée, en particulier les champs suivants :
  - Nom complet de la ressource: nom complet de la ressource du cluster, y compris le numéro de projet, l'emplacement et le nom du cluster.
- Liens associés, en particulier les champs suivants :
  - Indicateur VirusTotal: lien vers la page d'analyse VirusTotal.
Cliquez sur JSON, puis notez les champs suivants:
- resource :
  - project_display_name: nom du projet contenant le cluster.
- sourceProperties :
  - Pod_Namespace: nom de l'espace de noms Kubernetes du pod.
  - Pod_Name: nom du pod GKE.
  - Container_Name: nom du conteneur concerné.
  - Container_Image_Uri: nom de l'image de conteneur en cours de déploiement.
  - VM_Instance_Name: nom du nœud GKE sur lequel le pod a été exécuté.
Identifiez d'autres résultats qui se sont produits à un moment similaire pour ce conteneur. Les résultats associés peuvent indiquer que cette activité était malveillante, et non qu'elle n'était pas conforme aux bonnes pratiques.

Étape 2 : Vérifier le cluster et le nœud

Dans Cloud Console, accédez à la page des clusters Kubernetes.
Accéder à la page "Clusters Kubernetes"
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet listé dans resource.project_display_name, si nécessaire.
Sélectionnez le cluster listé sur la ligne Nom complet de la ressource dans l'onglet Résumé des détails du résultat. Notez toutes les métadonnées concernant le cluster et son propriétaire.
Cliquez sur l'onglet Nœuds. Sélectionnez le nœud répertorié dans VM_Instance_Name.
Cliquez sur l'onglet Détails et notez l'annotation container.googleapis.com/instance_id.

Étape 3 : Examiner le pod

Dans la console Google Cloud, accédez à la page Charges de travail Kubernetes.
Accéder à la page "Charges de travail Kubernetes"
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié dans resource.project_display_name, si nécessaire.
Filtrez le cluster répertorié sur la ligne Nom complet de la ressource dans l'onglet Récapitulatif des détails de l'anomalie et l'espace de noms du pod répertorié dans Pod_Namespace, si nécessaire.
Sélectionnez le pod répertorié dans Pod_Name. Notez les métadonnées concernant le pod et son propriétaire.

Étape 4 : Vérifier les journaux

Dans la console Google Cloud, accédez à l'explorateur de journaux.

Accéder à l'explorateur de journaux
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet listé dans resource.project_display_name, si nécessaire.
Définissez Sélectionner une période sur la période qui vous intéresse.
Sur la page qui s'affiche, procédez comme suit :
1. Recherchez Pod_Name dans les journaux des pods à l'aide du filtre suivant :
  - resource.type="k8s_container"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - resource.labels.namespace_name="Pod_Namespace"
  - resource.labels.pod_name="Pod_Name"
2. Recherchez les journaux d'audit du cluster à l'aide du filtre suivant :
  - logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - Pod_Name
3. Recherchez les journaux de la console de nœud GKE à l'aide du filtre suivant :
  - resource.type="gce_instance"
  - resource.labels.instance_id="instance_id"

Étape 5 : Examiner le conteneur en cours d'exécution

Si le conteneur est toujours en cours d'exécution, il peut être possible d'analyser directement l'environnement du conteneur.

Accédez à Google Cloud Console.

Ouvrir la console Google Cloud
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet listé dans resource.project_display_name, si nécessaire.
Cliquez sur Activer Cloud Shell.
Obtenez les identifiants GKE pour votre cluster en exécutant les commandes suivantes.

Pour les clusters zonaux:
```
  gcloud container clusters get-credentials cluster_name --zone location --project project_name
```
Pour les clusters régionaux:
```
  gcloud container clusters get-credentials cluster_name --region location --project project_name
```
Remplacez les éléments suivants :
- cluster_name : cluster répertorié dans resource.labels.cluster_name
- location : emplacement répertorié dans resource.labels.location
- project_name : nom du projet répertorié dans resource.project_display_name
Récupérez le binaire ajouté en exécutant la commande suivante :
```
  kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
```
Remplacez local_file par un chemin d'accès au fichier local pour stocker le binaire ajouté.
Connectez-vous à l'environnement de conteneur en exécutant la commande suivante :
```
  kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
```
Pour ce faire, une interface système est installée sur le conteneur à l'adresse /bin/sh.

Étape 6 : Étudier les méthodes d'attaque et de réponse

Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Transfert d'outil Ingress, API native.
Vérifiez la valeur de hachage SHA-256 du binaire signalé comme malveillant sur VirusTotal en cliquant sur le lien dans l'indicateur VirusTotal. VirusTotal est un service appartenant à Alphabet qui fournit du contexte sur des fichiers, des URL, des domaines et des adresses IP potentiellement malveillants.
Pour élaborer un plan de réponse, combinez les résultats de votre enquête avec la recherche MITRE et l'analyse VirusTotal.

Étape 7 : Mettre en œuvre votre réponse

Si le binaire devait être inclus dans le conteneur, recréez l'image du conteneur en incluant le binaire. Le conteneur peut ainsi être immuable.
Sinon, contactez le propriétaire du projet contenant le conteneur compromis.
Arrêtez ou supprimez le conteneur compromis et remplacez-le par un nouveau conteneur.

`Added Library Loaded`

Une bibliothèque ne faisant pas partie de l'image de conteneur d'origine a été chargée. Les pirates informatiques peuvent charger des bibliothèques malveillantes dans des programmes existants afin de contourner les protections d'exécution du code et de masquer du code malveillant. Il est important de s'assurer que vos conteneurs sont immuables. Il s'agit d'un résultat de faible gravité, car il est possible que votre organisation ne respecte pas cette bonne pratique. Des résultats Execution: Added Malicious Library Loaded correspondants sont disponibles lorsque le hachage du binaire est un indicateur de compromission (IoC) connu. Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez un résultat Added Library Loaded comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Résumé.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Binaire du programme: chemin d'accès complet du binaire du processus qui a chargé la bibliothèque.
  - Bibliothèques: informations sur la bibliothèque ajoutée.
  - Arguments: arguments fournis lors de l'appel du binaire du processus.
- Ressource concernée, en particulier les champs suivants :
  - Nom complet de la ressource: nom complet de la ressource du cluster.
- Liens associés, en particulier les champs suivants :
  - Indicateur VirusTotal: lien vers la page d'analyse VirusTotal.
Cliquez sur l'onglet JSON et notez les champs suivants:
- resource :
  - project_display_name: nom du projet contenant l'élément.
- sourceProperties :
  - Pod_Namespace: nom de l'espace de noms Kubernetes du pod.
  - Pod_Name: nom du pod GKE.
  - Container_Name: nom du conteneur concerné.
  - Container_Image_Uri: nom de l'image de conteneur en cours d'exécution.
  - VM_Instance_Name: nom du nœud GKE sur lequel le pod a été exécuté.
Identifiez d'autres résultats qui se sont produits à un moment similaire pour ce conteneur. Les résultats associés peuvent indiquer que cette activité était malveillante, et non qu'elle n'était pas conforme aux bonnes pratiques.

Étape 2 : Vérifier le cluster et le nœud

Dans Cloud Console, accédez à la page des clusters Kubernetes.
Accéder à la page "Clusters Kubernetes"
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié dans resource.project_display_name, si nécessaire.
Sélectionnez le cluster répertorié dans resource.name. Notez toutes les métadonnées concernant le cluster et son propriétaire.
Cliquez sur l'onglet Nœuds. Sélectionnez le nœud répertorié dans VM_Instance_Name.
Cliquez sur l'onglet Détails et notez l'annotation container.googleapis.com/instance_id.

Étape 3 : Examiner le pod

Dans la console Google Cloud, accédez à la page Charges de travail Kubernetes.
Accéder à la page "Charges de travail Kubernetes"
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié dans resource.project_display_name, si nécessaire.
Filtrez le cluster répertorié sur la ligne Nom complet de la ressource dans l'onglet Récapitulatif des détails de l'anomalie et l'espace de noms du pod répertorié dans Pod_Namespace, si nécessaire.
Sélectionnez le pod répertorié dans Pod_Name. Notez les métadonnées concernant le pod et son propriétaire.

Étape 4 : Vérifier les journaux

Dans la console Google Cloud, accédez à l'explorateur de journaux.

Accéder à l'explorateur de journaux
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié dans resource.project_display_name, si nécessaire.
Définissez Sélectionner une période sur la période qui vous intéresse.
Sur la page qui s'affiche, procédez comme suit :
1. Recherchez Pod_Name dans les journaux des pods à l'aide du filtre suivant :
  - resource.type="k8s_container"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - resource.labels.namespace_name="Pod_Namespace"
  - resource.labels.pod_name="Pod_Name"
2. Recherchez les journaux d'audit du cluster à l'aide du filtre suivant :
  - logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - Pod_Name
3. Recherchez les journaux de la console de nœud GKE à l'aide du filtre suivant :
  - resource.type="gce_instance"
  - resource.labels.instance_id="instance_id"

Étape 5 : Examiner le conteneur en cours d'exécution

Si le conteneur est toujours en cours d'exécution, il peut être possible d'analyser directement l'environnement du conteneur.

Accédez à Google Cloud Console.

Ouvrir la console Google Cloud
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié dans resource.project_display_name, si nécessaire.
Cliquez sur Activer Cloud Shell.

Obtenez les identifiants GKE pour votre cluster en exécutant les commandes suivantes.

Pour les clusters zonaux:

  gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name

Pour les clusters régionaux:

  gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name

Récupérez la bibliothèque ajoutée en exécutant la commande suivante :
```
  kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
```
Remplacez local_file par un chemin d'accès local au fichier pour stocker la bibliothèque ajoutée.
Connectez-vous à l'environnement de conteneur en exécutant la commande suivante :
```
  kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
```
Pour ce faire, une interface système est installée sur le conteneur à l'adresse /bin/sh.

Étape 6 : Étudier les méthodes d'attaque et de réponse

Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Transfert d'outil Ingress, Modules partagés.
Vérifiez la valeur de hachage SHA-256 du binaire signalé comme malveillant sur VirusTotal en cliquant sur le lien dans l'indicateur VirusTotal. VirusTotal est un service appartenant à Alphabet qui fournit du contexte sur des fichiers, des URL, des domaines et des adresses IP potentiellement malveillants.
Pour élaborer un plan de réponse, combinez les résultats de votre enquête avec la recherche MITRE et l'analyse VirusTotal.

Étape 7 : Mettre en œuvre votre réponse

Si la bibliothèque devait être incluse dans le conteneur, recréez l'image du conteneur en incluant la bibliothèque. Le conteneur peut ainsi être immuable.
Sinon, contactez le propriétaire du projet contenant le conteneur compromis.
Arrêtez ou supprimez le conteneur compromis et remplacez-le par un nouveau conteneur.

`Execution: Added Malicious Binary Executed`

Un fichier binaire malveillant qui ne faisait pas partie de l'image de conteneur d'origine a été exécuté. Les pirates informatiques installent généralement les outils d'exploitation et les logiciels malveillants après le piratage initial. Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez un résultat Execution: Added Malicious Binary Executed comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Récapitulatif.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Binaire du programme: chemin d'accès absolu du binaire ajouté.
  - Arguments: arguments fournis lors de l'appel du binaire ajouté.
  - Containers (Conteneurs) : nom du conteneur concerné.
  - URI des conteneurs: nom de l'image de conteneur en cours de déploiement.
- Ressource concernée, en particulier les champs suivants :
  - Nom complet de la ressource: nom complet de la ressource du cluster, y compris le numéro de projet, l'emplacement et le nom du cluster.
- Liens associés, en particulier les champs suivants :
  - Indicateur VirusTotal: lien vers la page d'analyse VirusTotal.
Cliquez sur l'onglet JSON et notez les champs suivants:
- sourceProperties :
  - VM_Instance_Name: nom du nœud GKE sur lequel le pod a été exécuté.

Étape 2 : Vérifier le cluster et le nœud

Dans Cloud Console, accédez à la page des clusters Kubernetes.
Accéder à la page "Clusters Kubernetes"
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet listé dans resource.project_display_name, si nécessaire.
Sélectionnez le cluster listé sur la ligne Nom complet de la ressource dans l'onglet Résumé des détails du résultat. Notez toutes les métadonnées concernant le cluster et son propriétaire.
Cliquez sur l'onglet Nœuds. Sélectionnez le nœud répertorié dans VM_Instance_Name.
Cliquez sur l'onglet Détails et notez l'annotation container.googleapis.com/instance_id.

Étape 3 : Examiner le pod

Dans la console Google Cloud, accédez à la page Charges de travail Kubernetes.
Accéder à la page "Charges de travail Kubernetes"
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié dans resource.project_display_name, si nécessaire.
Filtrez le cluster répertorié sur la ligne Nom complet de la ressource dans l'onglet Récapitulatif des détails de l'anomalie et l'espace de noms du pod répertorié dans Pod_Namespace, si nécessaire.
Sélectionnez le pod répertorié dans Pod_Name. Notez les métadonnées concernant le pod et son propriétaire.

Étape 4 : Vérifier les journaux

Dans la console Google Cloud, accédez à l'explorateur de journaux.

Accéder à l'explorateur de journaux
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet listé dans resource.project_display_name, si nécessaire.
Définissez Sélectionner une période sur la période qui vous intéresse.
Sur la page qui s'affiche, procédez comme suit :
1. Recherchez Pod_Name dans les journaux des pods à l'aide du filtre suivant :
  - resource.type="k8s_container"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - resource.labels.namespace_name="Pod_Namespace"
  - resource.labels.pod_name="Pod_Name"
2. Recherchez les journaux d'audit du cluster à l'aide du filtre suivant :
  - logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - Pod_Name
3. Recherchez les journaux de la console de nœud GKE à l'aide du filtre suivant :
  - resource.type="gce_instance"
  - resource.labels.instance_id="instance_id"

Étape 5 : Examiner le conteneur en cours d'exécution

Si le conteneur est toujours en cours d'exécution, il peut être possible d'analyser directement l'environnement du conteneur.

Accédez à Google Cloud Console.

Ouvrir la console Google Cloud
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet listé dans resource.project_display_name, si nécessaire.
Cliquez sur Activer Cloud Shell.
Obtenez les identifiants GKE pour votre cluster en exécutant les commandes suivantes.

Pour les clusters zonaux:
```
  gcloud container clusters get-credentials cluster_name --zone location --project project_name
```
Pour les clusters régionaux:
```
  gcloud container clusters get-credentials cluster_name --region location --project project_name
```
Remplacez les éléments suivants :
- cluster_name : cluster répertorié dans resource.labels.cluster_name
- location : emplacement répertorié dans resource.labels.location
- project_name : nom du projet répertorié dans resource.project_display_name
Récupérez le binaire malveillant ajouté:
```
  kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
```
Remplacez local_file par un chemin d'accès local pour stocker le binaire malveillant ajouté.
Connectez-vous à l'environnement de conteneur:
```
  kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
```
Pour ce faire, une interface système est installée sur le conteneur à l'adresse /bin/sh.

Étape 6 : Étudier les méthodes d'attaque et de réponse

Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Transfert d'outil Ingress, API native.
Vérifiez la valeur de hachage SHA-256 du binaire signalé comme malveillant sur VirusTotal en cliquant sur le lien dans l'indicateur VirusTotal. VirusTotal est un service appartenant à Alphabet qui fournit du contexte sur des fichiers, des URL, des domaines et des adresses IP potentiellement malveillants.
Pour élaborer un plan de réponse, combinez les résultats de votre enquête avec la recherche MITRE et l'analyse VirusTotal.

Étape 7 : Mettre en œuvre votre réponse

Contactez le propriétaire du projet contenant le conteneur compromis.
Arrêtez ou supprimez le conteneur compromis et remplacez-le par un nouveau conteneur.

`Execution: Added Malicious Library Loaded`

Une bibliothèque malveillante qui ne faisait pas partie de l'image de conteneur d'origine a été chargée. Les pirates informatiques peuvent charger des bibliothèques malveillantes dans des programmes existants afin de contourner les protections d'exécution du code et de masquer du code malveillant. Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez un résultat Execution: Added Malicious Library Loaded comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Résumé.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Binaire du programme: chemin d'accès complet du binaire du processus qui a chargé la bibliothèque.
  - Bibliothèques: informations sur la bibliothèque ajoutée.
  - Arguments: arguments fournis lors de l'appel du binaire du processus.
  - Containers (Conteneurs) : nom du conteneur concerné.
  - URI des conteneurs: nom de l'image de conteneur en cours de déploiement.
- Ressource concernée, en particulier les champs suivants :
  - Nom complet de la ressource: nom complet de la ressource du cluster.
- Liens associés, en particulier les champs suivants :
  - Indicateur VirusTotal: lien vers la page d'analyse VirusTotal.
Cliquez sur l'onglet JSON et notez les champs suivants:
- sourceProperties :
  - VM_Instance_Name: nom du nœud GKE sur lequel le pod a été exécuté.

Étape 2 : Vérifier le cluster et le nœud

Dans Cloud Console, accédez à la page des clusters Kubernetes.
Accéder à la page "Clusters Kubernetes"
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié dans resource.project_display_name, si nécessaire.
Sélectionnez le cluster listé sur la ligne Nom complet de la ressource dans l'onglet Résumé des détails du résultat. Notez toutes les métadonnées concernant le cluster et son propriétaire.
Cliquez sur l'onglet Nœuds. Sélectionnez le nœud répertorié dans VM_Instance_Name.
Cliquez sur l'onglet Détails et notez l'annotation container.googleapis.com/instance_id.

Étape 3 : Examiner le pod

Dans la console Google Cloud, accédez à la page Charges de travail Kubernetes.
Accéder à la page "Charges de travail Kubernetes"
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié dans resource.project_display_name, si nécessaire.
Filtrez le cluster répertorié sur la ligne Nom complet de la ressource dans l'onglet Récapitulatif des détails de l'anomalie et l'espace de noms du pod répertorié dans Pod_Namespace, si nécessaire.
Sélectionnez le pod répertorié dans Pod_Name. Notez les métadonnées concernant le pod et son propriétaire.

Étape 4 : Vérifier les journaux

Dans la console Google Cloud, accédez à l'explorateur de journaux.

Accéder à l'explorateur de journaux
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié dans resource.project_display_name, si nécessaire.
Définissez Sélectionner une période sur la période qui vous intéresse.
Sur la page qui s'affiche, procédez comme suit :
1. Recherchez Pod_Name dans les journaux des pods à l'aide du filtre suivant :
  - resource.type="k8s_container"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - resource.labels.namespace_name="Pod_Namespace"
  - resource.labels.pod_name="Pod_Name"
2. Recherchez les journaux d'audit du cluster à l'aide du filtre suivant :
  - logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - Pod_Name
3. Recherchez les journaux de la console de nœud GKE à l'aide du filtre suivant :
  - resource.type="gce_instance"
  - resource.labels.instance_id="instance_id"

Étape 5 : Examiner le conteneur en cours d'exécution

Si le conteneur est toujours en cours d'exécution, il peut être possible d'analyser directement l'environnement du conteneur.

Accédez à Google Cloud Console.

Ouvrir la console Google Cloud
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié dans resource.project_display_name, si nécessaire.
Cliquez sur Activer Cloud Shell.

Obtenez les identifiants GKE pour votre cluster en exécutant les commandes suivantes.

Pour les clusters zonaux:

  gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name

Pour les clusters régionaux:

  gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name

Récupérez la bibliothèque malveillante ajoutée:
```
  kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
```
Remplacez local_file par un chemin d'accès local pour stocker la bibliothèque malveillante ajoutée.
Connectez-vous à l'environnement de conteneur:
```
  kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
```
Pour ce faire, une interface système est installée sur le conteneur à l'adresse /bin/sh.

Étape 6 : Étudier les méthodes d'attaque et de réponse

Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Transfert d'outil Ingress, Modules partagés.
Vérifiez la valeur de hachage SHA-256 du binaire signalé comme malveillant sur VirusTotal en cliquant sur le lien dans l'indicateur VirusTotal. VirusTotal est un service appartenant à Alphabet qui fournit du contexte sur des fichiers, des URL, des domaines et des adresses IP potentiellement malveillants.
Pour élaborer un plan de réponse, combinez les résultats de votre enquête avec la recherche MITRE et l'analyse VirusTotal.

Étape 7 : Mettre en œuvre votre réponse

Contactez le propriétaire du projet contenant le conteneur compromis.
Arrêtez ou supprimez le conteneur compromis et remplacez-le par un nouveau conteneur.

`Execution: Built in Malicious Binary Executed`

Un binaire qui a été exécuté, avec le binaire:

Inclus dans l'image de conteneur d'origine.
Identifié comme malveillant d'après les renseignements sur les menaces.

Le pirate informatique contrôle le dépôt d'images de conteneur ou le pipeline de création, où le binaire malveillant est injecté dans l'image de conteneur. Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez un résultat Execution: Built in Malicious Binary Executed comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Récapitulatif.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Binaire du programme: chemin d'accès absolu du binaire intégré.
  - Arguments: arguments fournis lors de l'appel du binaire intégré.
  - Containers (Conteneurs) : nom du conteneur concerné.
  - URI des conteneurs: nom de l'image de conteneur en cours de déploiement.
- Ressource concernée, en particulier les champs suivants :
  - Nom complet de la ressource: nom complet de la ressource du cluster, y compris le numéro de projet, l'emplacement et le nom du cluster.
- Liens associés, en particulier les champs suivants :
  - Indicateur VirusTotal: lien vers la page d'analyse VirusTotal.
Cliquez sur JSON, puis notez les champs suivants:
- sourceProperties :
  - VM_Instance_Name: nom du nœud GKE sur lequel le pod a été exécuté.

Étape 2 : Vérifier le cluster et le nœud

Dans Cloud Console, accédez à la page des clusters Kubernetes.
Accéder à la page "Clusters Kubernetes"
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet listé dans resource.project_display_name, si nécessaire.
Sélectionnez le cluster listé sur la ligne Nom complet de la ressource dans l'onglet Résumé des détails du résultat. Notez toutes les métadonnées concernant le cluster et son propriétaire.
Cliquez sur l'onglet Nœuds. Sélectionnez le nœud répertorié dans VM_Instance_Name.
Cliquez sur l'onglet Détails et notez l'annotation container.googleapis.com/instance_id.

Étape 3 : Examiner le pod

Dans la console Google Cloud, accédez à la page Charges de travail Kubernetes.
Accéder à la page "Charges de travail Kubernetes"
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié dans resource.project_display_name, si nécessaire.
Filtrez le cluster répertorié sur la ligne Nom complet de la ressource dans l'onglet Récapitulatif des détails de l'anomalie et l'espace de noms du pod répertorié dans Pod_Namespace, si nécessaire.
Sélectionnez le pod répertorié dans Pod_Name. Notez les métadonnées concernant le pod et son propriétaire.

Étape 4 : Vérifier les journaux

Dans la console Google Cloud, accédez à l'explorateur de journaux.

Accéder à l'explorateur de journaux
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet listé dans resource.project_display_name, si nécessaire.
Définissez Sélectionner une période sur la période qui vous intéresse.
Sur la page qui s'affiche, procédez comme suit :
1. Recherchez Pod_Name dans les journaux des pods à l'aide du filtre suivant :
  - resource.type="k8s_container"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - resource.labels.namespace_name="Pod_Namespace"
  - resource.labels.pod_name="Pod_Name"
2. Recherchez les journaux d'audit du cluster à l'aide du filtre suivant :
  - logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - Pod_Name
3. Recherchez les journaux de la console de nœud GKE à l'aide du filtre suivant :
  - resource.type="gce_instance"
  - resource.labels.instance_id="instance_id"

Étape 5 : Examiner le conteneur en cours d'exécution

Si le conteneur est toujours en cours d'exécution, il peut être possible d'analyser directement l'environnement du conteneur.

Accédez à Google Cloud Console.

Ouvrir la console Google Cloud
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet listé dans resource.project_display_name, si nécessaire.
Cliquez sur Activer Cloud Shell.
Obtenez les identifiants GKE pour votre cluster en exécutant les commandes suivantes.

Pour les clusters zonaux:
```
  gcloud container clusters get-credentials cluster_name --zone location --project project_name
```
Pour les clusters régionaux:
```
  gcloud container clusters get-credentials cluster_name --region location --project project_name
```
Remplacez les éléments suivants :
- cluster_name : cluster répertorié dans resource.labels.cluster_name
- location : emplacement répertorié dans resource.labels.location
- project_name : nom du projet répertorié dans resource.project_display_name
Récupérez le binaire malveillant intégré:
```
  kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
```
Remplacez local_file par un chemin d'accès local pour stocker le binaire malveillant créé.
Connectez-vous à l'environnement de conteneur:
```
  kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
```
Pour ce faire, une interface système est installée sur le conteneur à l'adresse /bin/sh.

Étape 6 : Étudier les méthodes d'attaque et de réponse

Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Transfert d'outil Ingress, API native.
Vérifiez la valeur de hachage SHA-256 du binaire signalé comme malveillant sur VirusTotal en cliquant sur le lien dans l'indicateur VirusTotal. VirusTotal est un service appartenant à Alphabet qui fournit du contexte sur des fichiers, des URL, des domaines et des adresses IP potentiellement malveillants.
Pour élaborer un plan de réponse, combinez les résultats de votre enquête avec la recherche MITRE et l'analyse VirusTotal.

Étape 7 : Mettre en œuvre votre réponse

Contactez le propriétaire du projet contenant le conteneur compromis.
Arrêtez ou supprimez le conteneur compromis et remplacez-le par un nouveau conteneur.

`Execution: Malicious Python executed`

Un modèle de machine learning a identifié un code Python exécuté comme malveillant. Les pirates informatiques peuvent utiliser Python pour transférer des outils et exécuter des commandes sans binaires. Il est important de s'assurer que vos conteneurs sont immuables. Il s'agit d'une bonne pratique. L'utilisation de scripts pour transférer des outils peut imiter la technique de transfert d'outils d'intrusion des pirates informatiques et entraîner des détections indésirables.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez un résultat Execution: Malicious Python executed comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Récapitulatif.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Binaire du programme: détails sur l'interpréteur qui a appelé le script.
  - Script: chemin d'accès absolu du nom du script sur le disque. Cet attribut n'apparaît que pour les scripts écrits sur le disque, et non pour l'exécution de scripts littéraux (par exemple, python3 -c).
  - Arguments: arguments fournis lors de l'appel du script.
- Ressource concernée, en particulier les champs suivants :
  - Nom complet de la ressource: nom complet de la ressource du cluster, y compris le numéro de projet, l'emplacement et le nom du cluster.
- Liens associés, en particulier les champs suivants :
  - Indicateur VirusTotal: lien vers la page d'analyse VirusTotal.
Dans la vue détaillée du résultat, cliquez sur l'onglet JSON.
Dans le fichier JSON, notez les champs suivants.
- finding :
  - processes :
  - script :
    - contents: contenu du script exécuté, qui peut être tronqué pour des raisons de performances. Cela peut faciliter votre enquête.
    - sha256: hachage SHA-256 de script.contents
- resource :
  - project_display_name: nom du projet contenant l'élément.
- sourceProperties :
  - Pod_Namespace: nom de l'espace de noms Kubernetes du pod.
  - Pod_Name: nom du pod GKE.
  - Container_Name: nom du conteneur concerné.
  - Container_Image_Uri: nom de l'image de conteneur en cours d'exécution.
  - VM_Instance_Name: nom du nœud GKE sur lequel le pod a été exécuté.
Identifiez d'autres résultats qui se sont produits à un moment similaire pour ce conteneur. Par exemple, si le script crée un binaire, recherchez les résultats associés au binaire.

Étape 2 : Vérifier le cluster et le nœud

Dans Cloud Console, accédez à la page des clusters Kubernetes.

Accéder à la page "Clusters Kubernetes"
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet listé dans resource.project_display_name, si nécessaire.
Sélectionnez le cluster listé sur la ligne Nom complet de la ressource dans l'onglet Résumé des détails du résultat. Notez toutes les métadonnées concernant le cluster et son propriétaire.
Cliquez sur l'onglet Nœuds. Sélectionnez le nœud répertorié dans VM_Instance_Name.
Cliquez sur l'onglet Détails et notez l'annotation container.googleapis.com/instance_id.

Étape 3 : Examiner le pod

Dans la console Google Cloud, accédez à la page Charges de travail Kubernetes.

Accéder à la page "Charges de travail Kubernetes"
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet listé dans resource.project_display_name, si nécessaire.
Filtrez le cluster répertorié dans resource.name et l'espace de noms du pod répertorié dans Pod_Namespace, si nécessaire.
Sélectionnez le pod répertorié dans Pod_Name. Notez les métadonnées concernant le pod et son propriétaire.

Étape 4 : Vérifier les journaux

Dans la console Google Cloud, accédez à l'explorateur de journaux.

Accéder à l'explorateur de journaux
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié dans resource.project_display_name, si nécessaire.
Définissez Sélectionner une période sur la période qui vous intéresse.
Sur la page qui s'affiche, procédez comme suit :
1. Recherchez Pod_Name dans les journaux des pods à l'aide du filtre suivant :
  - resource.type="k8s_container"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - resource.labels.namespace_name="Pod_Namespace"
  - resource.labels.pod_name="Pod_Name"
2. Recherchez les journaux d'audit du cluster à l'aide du filtre suivant :
  - logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - Pod_Name
3. Recherchez les journaux de la console de nœud GKE à l'aide du filtre suivant :
  - resource.type="gce_instance"
  - resource.labels.instance_id="instance_id"

Étape 5 : Examiner le conteneur en cours d'exécution

Si le conteneur est toujours en cours d'exécution, il peut être possible d'analyser directement l'environnement du conteneur.

Dans Cloud Console, accédez à la page des clusters Kubernetes.

Accéder à la page "Clusters Kubernetes"
Cliquez sur le nom du cluster affiché dans resource.labels.cluster_name.
Sur la page Clusters, cliquez sur Se connecter, puis sur Exécuter dans Cloud Shell.

Cloud Shell lance et ajoute des commandes pour le cluster dans le terminal.
Appuyez sur Entrée. Si la boîte de dialogue Autoriser Cloud Shell s'affiche, cliquez sur Autoriser.
Connectez-vous à l'environnement de conteneur en exécutant la commande suivante :
```
  kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
```
Pour ce faire, une interface système est installée sur le conteneur à l'adresse /bin/sh.

Étape 6 : Étudier les méthodes d'attaque et de réponse

Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Interpréteur de commandes et de scripts, Transfert d'outils Ingress.
Vérifiez la valeur de hachage SHA-256 du binaire signalé comme malveillant sur VirusTotal en cliquant sur le lien dans l'indicateur VirusTotal. VirusTotal est un service appartenant à Alphabet qui fournit du contexte sur des fichiers, des URL, des domaines et des adresses IP potentiellement malveillants.
Pour élaborer un plan de réponse, combinez les résultats de votre enquête avec la recherche MITRE et l'analyse VirusTotal.

Étape 7 : Mettre en œuvre votre réponse

Si Python apportait des modifications prévues au conteneur, recréez l'image du conteneur de sorte qu'aucune modification ne soit nécessaire. Le conteneur peut ainsi être immutable.
Sinon, contactez le propriétaire du projet contenant le conteneur compromis.
Arrêtez ou supprimez le conteneur compromis et remplacez-le par un nouveau conteneur.

`Execution: Modified Malicious Binary Executed`

Un binaire qui a été exécuté, avec le binaire:

Inclus dans l'image de conteneur d'origine.
Modifié pendant l'environnement d'exécution du conteneur.
Identifié comme malveillant d'après les renseignements sur les menaces.

Les pirates informatiques installent généralement les outils d'exploitation et les logiciels malveillants après le piratage initial. Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez un résultat Execution: Modified Malicious Binary Executed comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Récapitulatif.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Binaire du programme: chemin d'accès absolu du binaire modifié.
  - Arguments: arguments fournis lors de l'appel du binaire modifié.
  - Containers (Conteneurs) : nom du conteneur concerné.
  - URI des conteneurs: nom de l'image de conteneur en cours de déploiement.
- Ressource concernée, en particulier les champs suivants :
  - Nom complet de la ressource: nom complet de la ressource du cluster, y compris le numéro de projet, l'emplacement et le nom du cluster.
- Liens associés, en particulier les champs suivants :
  - Indicateur VirusTotal: lien vers la page d'analyse VirusTotal.
Cliquez sur JSON, puis notez les champs suivants:
- sourceProperties :
  - VM_Instance_Name: nom du nœud GKE sur lequel le pod a été exécuté.

Étape 2 : Vérifier le cluster et le nœud

Dans Cloud Console, accédez à la page des clusters Kubernetes.
Accéder à la page "Clusters Kubernetes"
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet listé dans resource.project_display_name, si nécessaire.
Sélectionnez le cluster listé sur la ligne Nom complet de la ressource dans l'onglet Résumé des détails du résultat. Notez toutes les métadonnées concernant le cluster et son propriétaire.
Cliquez sur l'onglet Nœuds. Sélectionnez le nœud répertorié dans VM_Instance_Name.
Cliquez sur l'onglet Détails et notez l'annotation container.googleapis.com/instance_id.

Étape 3 : Examiner le pod

Dans la console Google Cloud, accédez à la page Charges de travail Kubernetes.
Accéder à la page "Charges de travail Kubernetes"
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié dans resource.project_display_name, si nécessaire.
Filtrez le cluster répertorié sur la ligne Nom complet de la ressource dans l'onglet Récapitulatif des détails de l'anomalie et l'espace de noms du pod répertorié dans Pod_Namespace, si nécessaire.
Sélectionnez le pod répertorié dans Pod_Name. Notez les métadonnées concernant le pod et son propriétaire.

Étape 4 : Vérifier les journaux

Dans la console Google Cloud, accédez à l'explorateur de journaux.

Accéder à l'explorateur de journaux
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet listé dans resource.project_display_name, si nécessaire.
Définissez Sélectionner une période sur la période qui vous intéresse.
Sur la page qui s'affiche, procédez comme suit :
1. Recherchez Pod_Name dans les journaux des pods à l'aide du filtre suivant :
  - resource.type="k8s_container"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - resource.labels.namespace_name="Pod_Namespace"
  - resource.labels.pod_name="Pod_Name"
2. Recherchez les journaux d'audit du cluster à l'aide du filtre suivant :
  - logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - Pod_Name
3. Recherchez les journaux de la console de nœud GKE à l'aide du filtre suivant :
  - resource.type="gce_instance"
  - resource.labels.instance_id="instance_id"

Étape 5 : Examiner le conteneur en cours d'exécution

Si le conteneur est toujours en cours d'exécution, il peut être possible d'analyser directement l'environnement du conteneur.

Accédez à Google Cloud Console.

Ouvrir la console Google Cloud
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet listé dans resource.project_display_name, si nécessaire.
Cliquez sur Activer Cloud Shell.
Obtenez les identifiants GKE pour votre cluster en exécutant les commandes suivantes.

Pour les clusters zonaux:
```
  gcloud container clusters get-credentials cluster_name --zone location --project project_name
```
Pour les clusters régionaux:
```
  gcloud container clusters get-credentials cluster_name --region location --project project_name
```
Remplacez les éléments suivants :
- cluster_name : cluster répertorié dans resource.labels.cluster_name
- location : emplacement répertorié dans resource.labels.location
- project_name : nom du projet répertorié dans resource.project_display_name
Récupérez le binaire malveillant modifié:
```
  kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
```
Remplacez local_file par un chemin d'accès local pour stocker le binaire malveillant modifié.
Connectez-vous à l'environnement de conteneur:
```
  kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
```
Pour ce faire, une interface système est installée sur le conteneur à l'adresse /bin/sh.

Étape 6 : Étudier les méthodes d'attaque et de réponse

Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Transfert d'outil Ingress, API native.
Vérifiez la valeur de hachage SHA-256 du binaire signalé comme malveillant sur VirusTotal en cliquant sur le lien dans l'indicateur VirusTotal. VirusTotal est un service appartenant à Alphabet qui fournit du contexte sur des fichiers, des URL, des domaines et des adresses IP potentiellement malveillants.
Pour élaborer un plan de réponse, combinez les résultats de votre enquête avec la recherche MITRE et l'analyse VirusTotal.

Étape 7 : Mettre en œuvre votre réponse

Contactez le propriétaire du projet contenant le conteneur compromis.
Arrêtez ou supprimez le conteneur compromis et remplacez-le par un nouveau conteneur.

`Execution: Modified Malicious Library Loaded`

Bibliothèque chargée, avec les éléments suivants:

Inclus dans l'image de conteneur d'origine.
Modifié pendant l'environnement d'exécution du conteneur.
Identifié comme malveillant d'après les renseignements sur les menaces.

Les pirates informatiques peuvent charger des bibliothèques malveillantes dans des programmes existants afin de contourner les protections d'exécution du code et de masquer du code malveillant. Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez un résultat Execution: Modified Malicious Library Loaded comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Résumé.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Binaire du programme: chemin d'accès complet du binaire du processus qui a chargé la bibliothèque.
  - Bibliothèques: informations sur la bibliothèque modifiée.
  - Arguments: arguments fournis lors de l'appel du binaire du processus.
  - Containers (Conteneurs) : nom du conteneur concerné.
  - URI des conteneurs: nom de l'image de conteneur en cours de déploiement.
- Ressource concernée, en particulier les champs suivants :
  - Nom complet de la ressource: nom complet de la ressource du cluster.
- Liens associés, en particulier les champs suivants :
  - Indicateur VirusTotal: lien vers la page d'analyse VirusTotal.
Cliquez sur l'onglet JSON et notez les champs suivants:
- sourceProperties :
  - VM_Instance_Name: nom du nœud GKE sur lequel le pod a été exécuté.

Étape 2 : Vérifier le cluster et le nœud

Dans Cloud Console, accédez à la page des clusters Kubernetes.
Accéder à la page "Clusters Kubernetes"
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié dans resource.project_display_name, si nécessaire.
Sélectionnez le cluster répertorié dans resource.name. Notez toutes les métadonnées concernant le cluster et son propriétaire.
Cliquez sur l'onglet Nœuds. Sélectionnez le nœud répertorié dans VM_Instance_Name.
Cliquez sur l'onglet Détails et notez l'annotation container.googleapis.com/instance_id.

Étape 3 : Examiner le pod

Dans la console Google Cloud, accédez à la page Charges de travail Kubernetes.
Accéder à la page "Charges de travail Kubernetes"
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié dans resource.project_display_name, si nécessaire.
Filtrez le cluster répertorié sur la ligne Nom complet de la ressource dans l'onglet Récapitulatif des détails de l'anomalie et l'espace de noms du pod répertorié dans Pod_Namespace, si nécessaire.
Sélectionnez le pod répertorié dans Pod_Name. Notez les métadonnées concernant le pod et son propriétaire.

Étape 4 : Vérifier les journaux

Dans la console Google Cloud, accédez à l'explorateur de journaux.

Accéder à l'explorateur de journaux
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié dans resource.project_display_name, si nécessaire.
Définissez Sélectionner une période sur la période qui vous intéresse.
Sur la page qui s'affiche, procédez comme suit :
1. Recherchez Pod_Name dans les journaux des pods à l'aide du filtre suivant :
  - resource.type="k8s_container"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - resource.labels.namespace_name="Pod_Namespace"
  - resource.labels.pod_name="Pod_Name"
2. Recherchez les journaux d'audit du cluster à l'aide du filtre suivant :
  - logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - Pod_Name
3. Recherchez les journaux de la console de nœud GKE à l'aide du filtre suivant :
  - resource.type="gce_instance"
  - resource.labels.instance_id="instance_id"

Étape 5 : Examiner le conteneur en cours d'exécution

Si le conteneur est toujours en cours d'exécution, il peut être possible d'analyser directement l'environnement du conteneur.

Accédez à Google Cloud Console.

Ouvrir la console Google Cloud
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié dans resource.project_display_name, si nécessaire.
Cliquez sur Activer Cloud Shell.

Obtenez les identifiants GKE pour votre cluster en exécutant les commandes suivantes.

Pour les clusters zonaux:

  gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name

Pour les clusters régionaux:

  gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name

Récupérez la bibliothèque malveillante modifiée:
```
  kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
```
Remplacez local_file par un chemin d'accès local pour stocker la bibliothèque malveillante modifiée.
Connectez-vous à l'environnement de conteneur:
```
  kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
```
Pour ce faire, une interface système est installée sur le conteneur à l'adresse /bin/sh.

Étape 6 : Étudier les méthodes d'attaque et de réponse

Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Transfert d'outil Ingress, Modules partagés.
Vérifiez la valeur de hachage SHA-256 du binaire signalé comme malveillant sur VirusTotal en cliquant sur le lien dans l'indicateur VirusTotal. VirusTotal est un service appartenant à Alphabet qui fournit du contexte sur des fichiers, des URL, des domaines et des adresses IP potentiellement malveillants.
Pour élaborer un plan de réponse, combinez les résultats de votre enquête avec la recherche MITRE et l'analyse VirusTotal.

Étape 7 : Mettre en œuvre votre réponse

Contactez le propriétaire du projet contenant le conteneur compromis.
Arrêtez ou supprimez le conteneur compromis et remplacez-le par un nouveau conteneur.

`Malicious Script Executed`

Un modèle de machine learning a identifié un code Bash exécuté comme malveillant. Les pirates informatiques peuvent utiliser Bash pour transférer des outils et exécuter des commandes sans binaires. Il est important de s'assurer que vos conteneurs sont immuables. Il s'agit d'une bonne pratique. L'utilisation de scripts pour transférer des outils peut imiter la technique de transfert d'outils d'intrusion des pirates informatiques et entraîner des détections indésirables.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez un résultat Malicious Script Executed comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Récapitulatif.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Binaire du programme: détails sur l'interpréteur qui a appelé le script.
  - Script: chemin d'accès absolu du nom du script sur le disque. Cet attribut n'apparaît que pour les scripts écrits sur le disque, et non pour l'exécution de scripts littéraux (par exemple, bash -c).
  - Arguments: arguments fournis lors de l'appel du script.
- Ressource concernée, en particulier les champs suivants :
  - Nom complet de la ressource: nom complet de la ressource du cluster, y compris le numéro de projet, l'emplacement et le nom du cluster.
- Liens associés, en particulier les champs suivants :
  - Indicateur VirusTotal: lien vers la page d'analyse VirusTotal.
Dans la vue détaillée du résultat, cliquez sur l'onglet JSON.
Dans le fichier JSON, notez les champs suivants.
- finding :
  - processes :
  - script :
    - contents: contenu du script exécuté, qui peut être tronqué pour des raisons de performances. Cela peut faciliter votre enquête.
    - sha256: hachage SHA-256 de script.contents
- resource :
  - project_display_name: nom du projet contenant l'élément.
- sourceProperties :
  - Pod_Namespace: nom de l'espace de noms Kubernetes du pod.
  - Pod_Name: nom du pod GKE.
  - Container_Name: nom du conteneur concerné.
  - Container_Image_Uri: nom de l'image de conteneur en cours d'exécution.
  - VM_Instance_Name: nom du nœud GKE sur lequel le pod a été exécuté.
Identifiez d'autres résultats qui se sont produits à un moment similaire pour ce conteneur. Par exemple, si le script crée un binaire, recherchez les résultats associés au binaire.

Étape 2 : Vérifier le cluster et le nœud

Dans Cloud Console, accédez à la page des clusters Kubernetes.

Accéder à la page "Clusters Kubernetes"
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet listé dans resource.project_display_name, si nécessaire.
Sélectionnez le cluster listé sur la ligne Nom complet de la ressource dans l'onglet Résumé des détails du résultat. Notez toutes les métadonnées concernant le cluster et son propriétaire.
Cliquez sur l'onglet Nœuds. Sélectionnez le nœud répertorié dans VM_Instance_Name.
Cliquez sur l'onglet Détails et notez l'annotation container.googleapis.com/instance_id.

Étape 3 : Examiner le pod

Dans la console Google Cloud, accédez à la page Charges de travail Kubernetes.

Accéder à la page "Charges de travail Kubernetes"
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet listé dans resource.project_display_name, si nécessaire.
Filtrez le cluster répertorié dans resource.name et l'espace de noms du pod répertorié dans Pod_Namespace, si nécessaire.
Sélectionnez le pod répertorié dans Pod_Name. Notez les métadonnées concernant le pod et son propriétaire.

Étape 4 : Vérifier les journaux

Dans la console Google Cloud, accédez à l'explorateur de journaux.

Accéder à l'explorateur de journaux
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié dans resource.project_display_name, si nécessaire.
Définissez Sélectionner une période sur la période qui vous intéresse.
Sur la page qui s'affiche, procédez comme suit :
1. Recherchez Pod_Name dans les journaux des pods à l'aide du filtre suivant :
  - resource.type="k8s_container"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - resource.labels.namespace_name="Pod_Namespace"
  - resource.labels.pod_name="Pod_Name"
2. Recherchez les journaux d'audit du cluster à l'aide du filtre suivant :
  - logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - Pod_Name
3. Recherchez les journaux de la console de nœud GKE à l'aide du filtre suivant :
  - resource.type="gce_instance"
  - resource.labels.instance_id="instance_id"

Étape 5 : Examiner le conteneur en cours d'exécution

Si le conteneur est toujours en cours d'exécution, il peut être possible d'analyser directement l'environnement du conteneur.

Dans Cloud Console, accédez à la page des clusters Kubernetes.

Accéder à la page "Clusters Kubernetes"
Cliquez sur le nom du cluster affiché dans resource.labels.cluster_name.
Sur la page Clusters, cliquez sur Se connecter, puis sur Exécuter dans Cloud Shell.

Cloud Shell lance et ajoute des commandes pour le cluster dans le terminal.
Appuyez sur Entrée. Si la boîte de dialogue Autoriser Cloud Shell s'affiche, cliquez sur Autoriser.
Connectez-vous à l'environnement de conteneur en exécutant la commande suivante :
```
  kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
```
Pour ce faire, une interface système est installée sur le conteneur à l'adresse /bin/sh.

Étape 6 : Étudier les méthodes d'attaque et de réponse

Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Interpréteur de commandes et de scripts, Transfert d'outils Ingress.
Vérifiez la valeur de hachage SHA-256 du binaire signalé comme malveillant sur VirusTotal en cliquant sur le lien dans l'indicateur VirusTotal. VirusTotal est un service appartenant à Alphabet qui fournit du contexte sur des fichiers, des URL, des domaines et des adresses IP potentiellement malveillants.
Pour élaborer un plan de réponse, combinez les résultats de votre enquête avec la recherche MITRE et l'analyse VirusTotal.

Étape 7 : Mettre en œuvre votre réponse

Si le script apportait des modifications prévues au conteneur, recréez l'image du conteneur de sorte qu'aucune modification ne soit nécessaire. Le conteneur peut ainsi être immuable.
Sinon, contactez le propriétaire du projet contenant le conteneur compromis.
Arrêtez ou supprimez le conteneur compromis et remplacez-le par un nouveau conteneur.

`Malicious URL Observed`

Container Threat Detection a détecté une URL malveillante dans la liste d'arguments d'un processus exécutable. Les pirates informatiques peuvent charger des logiciels malveillants ou des bibliothèques malveillantes via des URL malveillantes.

Pour répondre à ce résultat, procédez comme suit.

Étape 1 : Examiner les détails du résultat

Ouvrez un résultat Malicious URL Observed comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Récapitulatif.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - URI: URI malveillant observé.
  - Binaire ajouté: chemin d'accès complet du binaire du processus qui a reçu les arguments contenant l'URL malveillante.
  - Arguments: arguments fournis lors de l'appel du binaire du processus.
  - Variables d'environnement: variables d'environnement en vigueur lorsque le binaire du processus a été appelé.
  - Containers (Conteneurs) : nom du conteneur.
  - Pods Kubernetes: nom et espace de noms du pod.
- Ressource concernée, en particulier les champs suivants :
  - Nom à afficher de la ressource: nom de la ressource concernée.
  - Nom complet de la ressource: nom complet de la ressource du cluster. Le nom complet de la ressource inclut les informations suivantes :
    - Projet contenant le cluster: projects/PROJECT_ID
    - Emplacement du cluster: zone/ZONE ou locations/LOCATION
    - Nom du cluster: projects/CLUSTER_NAME
- Liens associés, en particulier les champs suivants :
  - Indicateur VirusTotal: lien vers la page d'analyse VirusTotal.
Dans l'onglet JSON, dans l'attribut sourceProperties, notez la valeur de la propriété VM_Instance_Name.

Étape 2 : Vérifier le cluster et le nœud

Dans Cloud Console, accédez à la page des clusters Kubernetes.

Accéder à la page "Clusters Kubernetes"
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet qui s'affiche dans Nom complet de la ressource (resource.name), si nécessaire. Le nom du projet apparaît après /projects/ dans le nom complet de la ressource.
Cliquez sur le nom du cluster que vous avez noté dans Nom à afficher de la ressource (resource.display_name) du résumé du résultat. La page Clusters s'ouvre.
Dans la section Métadonnées de la page "Détails du cluster", notez toutes les informations définies par l'utilisateur qui pourraient être utiles pour résoudre la menace, telles que les informations permettant d'identifier le propriétaire du cluster.
Cliquez sur l'onglet "Nœuds".
Dans la liste des nœuds, sélectionnez celui qui correspond à la valeur de VM_Instance_Name que vous avez notée dans le fichier JSON de la découverte précédemment.
Dans l'onglet Détails de la page Détails du nœud, dans la section Annotations, notez la valeur de l'annotation container.googleapis.com/instance_id.

Étape 3 : Examiner le pod

Dans la console Google Cloud, accédez à la page Charges de travail Kubernetes.

Accéder à la page "Charges de travail Kubernetes"
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet que vous avez noté dans le nom complet de la ressource (resource.name) du cluster dans le résumé des résultats, si nécessaire.
Cliquez sur Afficher les charges de travail du système.
Filtrez la liste des charges de travail par le nom du cluster que vous avez noté dans Nom complet de la ressource (resource.name) du résumé des résultats et, si nécessaire, par l'espace de noms (kubernetes.pods.ns) du pod que vous avez noté.
Cliquez sur le nom de la charge de travail qui correspond à la valeur de la propriété VM_Instance_Name que vous avez notée dans le fichier JSON de résultat précédemment. La page Détails du pod s'ouvre.
Sur la page Détails du pod, notez toutes les informations sur le pod qui pourraient vous aider à résoudre la menace.

Étape 4 : Vérifier les journaux

Dans la console Google Cloud, accédez à l'explorateur de journaux.

Accéder à l'explorateur de journaux
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet qui s'affiche dans Nom complet de la ressource (resource.name), si nécessaire.
Définissez Sélectionner une période sur la période qui vous intéresse.
Sur la page qui s'affiche, procédez comme suit :
1. Recherchez les journaux de votre pod (kubernetes.pods.name) à l'aide du filtre suivant :
  - resource.type="k8s_container"
  - resource.labels.project_id="PROJECT_ID"
  - resource.labels.location="LOCATION"
  - resource.labels.cluster_name="CLUSTER_NAME"
  - resource.labels.namespace_name="NAMESPACE_NAME"
  - resource.labels.pod_name="POD_NAME"
2. Recherchez les journaux d'audit du cluster à l'aide du filtre suivant :
  - logName="projects/PROJECT_NAME/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="PROJECT_ID"
  - resource.labels.location="LOCATION_OR_ZONE"
  - resource.labels.cluster_name="CLUSTER_NAME/var>"
  - POD_NAME
3. Recherchez les journaux de la console de nœud GKE à l'aide du filtre suivant :
  - resource.type="gce_instance"
  - resource.labels.instance_id="INSTANCE_ID"

Étape 5: Examiner le conteneur en cours d'exécution

Si le conteneur est toujours en cours d'exécution, il peut être possible d'analyser directement l'environnement du conteneur.

Dans Cloud Console, accédez à la page des clusters Kubernetes.

Accéder à la page "Clusters Kubernetes"
Cliquez sur le nom du cluster affiché dans resource.labels.cluster_name.
Sur la page Clusters, cliquez sur Se connecter, puis sur Exécuter dans Cloud Shell.

Cloud Shell lance et ajoute des commandes pour le cluster dans le terminal.
Appuyez sur Entrée. Si la boîte de dialogue Autoriser Cloud Shell s'affiche, cliquez sur Autoriser.
Connectez-vous à l'environnement de conteneur en exécutant la commande suivante :
```
  kubectl exec --namespace=POD_NAMESPACE -ti POD_NAME -c CONTAINER_NAME -- /bin/sh
```
Remplacez CONTAINER_NAME par le nom du conteneur que vous avez noté dans le résumé des résultats précédemment.

Pour ce faire, une interface système est installée sur le conteneur à l'adresse /bin/sh.

Étape 6 : Étudier les méthodes d'attaque et de réponse

Consultez la page État du site dans la navigation sécurisée pour savoir pourquoi l'URL est classée comme malveillante.
Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Transfert d'outil Ingress.
Vérifiez la valeur de hachage SHA-256 du binaire signalé comme malveillant sur VirusTotal en cliquant sur le lien dans l'indicateur VirusTotal. VirusTotal est un service appartenant à Alphabet qui fournit du contexte sur des fichiers, des URL, des domaines et des adresses IP potentiellement malveillants.
Pour élaborer un plan de réponse, combinez les résultats de votre enquête avec la recherche MITRE et l'analyse VirusTotal.

Étape 7 : Mettre en œuvre votre réponse

Contactez le propriétaire du projet contenant le conteneur compromis.
Arrêtez ou supprimez le conteneur compromis et remplacez-le par un nouveau conteneur.

`Reverse Shell`

Un processus a commencé par une redirection de flux vers un socket connecté distant. La génération d'une interface système connectée au réseau peut permettre à un pirate informatique d'effectuer des actions arbitraires après une compromission initiale limitée. Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez un résultat Reverse Shell comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Récapitulatif.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Programme binaire: chemin d'accès absolu du processus, qui a commencé par la redirection du flux vers un socket distant.
  - Arguments: arguments fournis lors de l'appel du binaire du processus.
- Ressource concernée, en particulier les champs suivants :
  - Nom complet de la ressource: nom complet de la ressource du cluster.
  - Nom complet du projet: projet Google Cloud concerné.
- Liens associés, en particulier les champs suivants :
  - Indicateur VirusTotal: lien vers la page d'analyse VirusTotal.
Dans la vue détaillée du résultat, cliquez sur l'onglet JSON.
Dans le fichier JSON, notez les champs suivants.
- resource :
  - project_display_name: nom du projet contenant l'élément.
- sourceProperties :
  - Pod_Namespace: nom de l'espace de noms Kubernetes du pod.
  - Pod_Name: nom du pod GKE.
  - Container_Name: nom du conteneur concerné.
  - VM_Instance_Name: nom du nœud GKE sur lequel le pod a été exécuté.
  - Reverse_Shell_Stdin_Redirection_Dst_Ip : adresse IP distante de la connexion.
  - Reverse_Shell_Stdin_Redirection_Dst_Port : port distant.
  - Reverse_Shell_Stdin_Redirection_Src_Ip : adresse IP locale de la connexion.
  - Reverse_Shell_Stdin_Redirection_Src_Port : port local.
  - Container_Image_Uri: nom de l'image de conteneur en cours d'exécution.

Étape 2 : Vérifier le cluster et le nœud

Dans Cloud Console, accédez à la page des clusters Kubernetes.

Accéder à la page "Clusters Kubernetes"
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié dans resource.project_display_name, si nécessaire.
Sélectionnez le cluster répertorié dans resource.name. Notez toutes les métadonnées concernant le cluster et son propriétaire.
Cliquez sur l'onglet Nœuds. Sélectionnez le nœud répertorié dans VM_Instance_Name.
Cliquez sur l'onglet Détails et notez l'annotation container.googleapis.com/instance_id.

Étape 3 : Examiner le pod

Dans la console Google Cloud, accédez à la page Charges de travail Kubernetes.

Accéder à la page "Charges de travail Kubernetes"
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié dans resource.project_display_name, si nécessaire.
Filtrez le cluster répertorié dans resource.name et l'espace de noms du pod répertorié dans Pod_Namespace, si nécessaire.
Sélectionnez le pod répertorié dans Pod_Name. Notez les métadonnées concernant le pod et son propriétaire.

Étape 4 : Vérifier les journaux

Dans la console Google Cloud, accédez à l'explorateur de journaux.

Accéder à l'explorateur de journaux
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié dans resource.project_display_name, si nécessaire.
Définissez Sélectionner une période sur la période qui vous intéresse.
Sur la page qui s'affiche, procédez comme suit :
1. Recherchez Pod_Name dans les journaux des pods à l'aide du filtre suivant :
  - resource.type="k8s_container"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - resource.labels.namespace_name="Pod_Namespace"
  - resource.labels.pod_name="Pod_Name"
2. Recherchez les journaux d'audit du cluster à l'aide du filtre suivant :
  - logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - Pod_Name
3. Recherchez les journaux de la console de nœud GKE à l'aide du filtre suivant :
  - resource.type="gce_instance"
  - resource.labels.instance_id="instance_id"

Étape 5 : Examiner le conteneur en cours d'exécution

Si le conteneur est toujours en cours d'exécution, il peut être possible d'analyser directement l'environnement du conteneur.

Accédez à Google Cloud Console.

Ouvrir la console Google Cloud
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié dans resource.project_display_name, si nécessaire.
Cliquez sur Activer Cloud Shell.

Obtenez les identifiants GKE pour votre cluster en exécutant les commandes suivantes.

Pour les clusters zonaux:

  gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name

Pour les clusters régionaux:

  gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name

Lancez une interface système dans l'environnement de conteneur en exécutant la commande suivante :
```
  kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
```
Pour ce faire, une interface système est installée sur le conteneur à l'adresse /bin/sh.

Pour afficher tous les processus exécutés dans le conteneur, exécutez la commande suivante dans l'interface système du conteneur :
```
  ps axjf
```
L'exécution de cette commande nécessite l'installation de /bin/ps sur le conteneur.

Étape 6 : Étudier les méthodes d'attaque et de réponse

Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Interpréteur de commandes et de scripts, Transfert d'outils Ingress.
Vérifiez la valeur de hachage SHA-256 du binaire signalé comme malveillant sur VirusTotal en cliquant sur le lien dans l'indicateur VirusTotal. VirusTotal est un service appartenant à Alphabet qui fournit du contexte sur des fichiers, des URL, des domaines et des adresses IP potentiellement malveillants.
Pour élaborer un plan de réponse, combinez les résultats de votre enquête avec la recherche MITRE et l'analyse VirusTotal.

Étape 7 : Mettre en œuvre votre réponse

Contactez le propriétaire du projet contenant le conteneur compromis.
Arrêtez ou supprimez le conteneur compromis et remplacez-le par un nouveau conteneur.

`Unexpected Child Shell`

Container Threat Detection a observé un processus qui a généré de manière inattendue un processus shell enfant. Cet événement peut indiquer qu'un pirate informatique tente d'abuser des commandes et des scripts shell.

Pour répondre à ce résultat, procédez comme suit.

Étape 1 : Examiner les détails du résultat

Ouvrez un résultat Unexpected Child Shell comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Récapitulatif.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Processus parent: processus ayant créé de manière inattendue le processus shell enfant.
  - Processus enfant: processus shell enfant.
  - Arguments: arguments fournis au binaire du processus de shell enfant.
  - Variables d'environnement: variables d'environnement du binaire du processus enfant du shell.
  - Containers (Conteneurs) : nom du conteneur.
  - URI des conteneurs: URI de l'image du conteneur.
  - Pods Kubernetes: nom et espace de noms du pod.
- Ressource concernée, en particulier les champs suivants :
  - Nom à afficher de la ressource: nom de la ressource concernée.
  - Nom complet de la ressource: nom complet de la ressource du cluster. Le nom complet de la ressource inclut les informations suivantes :
    - Projet contenant le cluster: projects/PROJECT_ID
    - Emplacement du cluster: zone/ZONE ou locations/LOCATION
    - Nom du cluster: projects/CLUSTER_NAME
- Liens associés, en particulier les champs suivants :
  - Indicateur VirusTotal: lien vers la page d'analyse VirusTotal.
Cliquez sur l'onglet JSON et notez les champs suivants:

+processes: tableau contenant tous les processus liés à la découverte. Ce tableau inclut le processus de shell enfant et le processus parent. +resource : +project_display_name: nom du projet contenant les éléments. +sourceProperties : +VM_Instance_Name: nom du nœud GKE sur lequel le pod a été exécuté.

Étape 2 : Vérifier le cluster et le nœud

Dans Cloud Console, accédez à la page des clusters Kubernetes.

Accéder à la page "Clusters Kubernetes"
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié dans resource.project_display_name, si nécessaire.
Sélectionnez le cluster répertorié dans resource.name. Notez toutes les métadonnées concernant le cluster et son propriétaire.
Cliquez sur l'onglet Nœuds. Sélectionnez le nœud répertorié dans VM_Instance_Name.
Cliquez sur l'onglet Détails et notez l'annotation container.googleapis.com/instance_id.

Étape 3 : Examiner le pod

Dans la console Google Cloud, accédez à la page Charges de travail Kubernetes.

Accéder à la page "Charges de travail Kubernetes"
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet que vous avez noté dans le nom complet de la ressource (resource.name) du cluster dans le résumé des résultats, si nécessaire.
Cliquez sur Afficher les charges de travail du système.
Filtrez la liste des charges de travail par le nom du cluster que vous avez noté dans Nom complet de la ressource (resource.name) du résumé des résultats et, si nécessaire, par l'espace de noms (kubernetes.pods.ns) du pod que vous avez noté.
Cliquez sur le nom de la charge de travail qui correspond à la valeur de la propriété VM_Instance_Name que vous avez notée dans le fichier JSON de résultat précédemment. La page Détails du pod s'ouvre.
Sur la page Détails du pod, notez toutes les informations sur le pod qui pourraient vous aider à résoudre la menace.

Étape 4 : Vérifier les journaux

Dans la console Google Cloud, accédez à l'explorateur de journaux.

Accéder à l'explorateur de journaux
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet listé dans resource.project_display_name.
Définissez Sélectionner une période sur la période qui vous intéresse.
Sur la page qui s'affiche, procédez comme suit :
1. Recherchez Pod_Name dans les journaux des pods à l'aide du filtre suivant :
  - resource.type="k8s_container"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - resource.labels.namespace_name="Pod_Namespace"
  - resource.labels.pod_name="Pod_Name"
2. Recherchez les journaux d'audit du cluster à l'aide du filtre suivant :
  - logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - Pod_Name
3. Recherchez les journaux de la console de nœud GKE à l'aide du filtre suivant :
  - resource.type="gce_instance"
  - resource.labels.instance_id="instance_id"

Étape 5: Examiner le conteneur en cours d'exécution

Si le conteneur est toujours en cours d'exécution, il peut être possible d'analyser directement l'environnement du conteneur.

Accédez à Google Cloud Console.

Ouvrir la console Google Cloud
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet listé dans resource.project_display_name.
Cliquez sur Activer Cloud Shell.

Obtenez les identifiants GKE pour votre cluster en exécutant les commandes suivantes.

Pour les clusters zonaux, exécutez la commande suivante:

  gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name

Pour les clusters régionaux, exécutez la commande suivante:

  gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name

Pour lancer une interface système dans l'environnement de conteneur, exécutez la commande suivante:
```
  kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
```
Pour ce faire, une interface système est installée sur le conteneur à l'adresse /bin/sh.

Pour afficher tous les processus exécutés dans le conteneur, exécutez la commande suivante dans l'interface système du conteneur :
```
  ps axjf
```
L'exécution de cette commande nécessite l'installation de /bin/ps sur le conteneur.

Étape 6 : Étudier les méthodes d'attaque et de réponse

Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Interpréteur de commandes et de scripts: shell Unix.
Vérifiez la valeur de hachage SHA-256 du binaire signalé comme malveillant sur VirusTotal en cliquant sur le lien dans l'indicateur VirusTotal. VirusTotal est un service appartenant à Alphabet qui fournit du contexte sur des fichiers, des URL, des domaines et des adresses IP potentiellement malveillants.
Pour élaborer un plan de réponse, combinez les résultats de votre enquête avec la recherche MITRE et l'analyse VirusTotal.

Étape 7 : Mettre en œuvre votre réponse

Contactez le propriétaire du projet contenant le conteneur compromis.
Arrêtez ou supprimez le conteneur compromis et remplacez-le par un nouveau conteneur.

Réponse de VM Threat Detection

Pour en savoir plus sur VM Threat Detection, consultez la présentation de VM Threat Detection.

`Defense Evasion: Rootkit`

VM Threat Detection a détecté une combinaison de signaux correspondant à un rootkit en mode kernel connu dans une instance de VM Compute Engine.

La catégorie de résultats Defense Evasion: Rootkit est un sur-ensemble des catégories de résultats suivantes. Par conséquent, cette section s'applique également à ces catégories de résultats.

Defense Evasion: Unexpected ftrace handler (bêta)
Defense Evasion: Unexpected interrupt handler (bêta)
Defense Evasion: Unexpected kernel code modification (bêta)
Defense Evasion: Unexpected kernel modules (bêta)
Defense Evasion: Unexpected kernel read-only data modification (bêta)
Defense Evasion: Unexpected kprobe handler (bêta)
Defense Evasion: Unexpected processes in runqueue (bêta)
Defense Evasion: Unexpected system call handler (bêta)

Pour répondre à ces résultats, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat, comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Résumé.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Risque détecté, en particulier les champs suivants:
  - Nom du rootkit de kernel: nom de la famille du rootkit détecté (par exemple, Diamorphine).
  - Pages de code kernel inattendues: indique si des pages de code kernel sont présentes dans des régions de code kernel ou de module où elles ne sont pas attendues.
  - Gestionnaire d'appels système inattendu: indique si les gestionnaires d'appels système sont présents dans des régions de code de kernel ou de module où ils ne sont pas attendus.
- Ressource concernée, en particulier le champ suivant:
  - Nom complet de la ressource: nom complet de la ressource de l'instance de VM concernée, y compris l'ID du projet qui la contient.
Pour afficher le code JSON complet de ce résultat, dans la vue détaillée, cliquez sur l'onglet JSON.

Étape 2 : Vérifier les journaux

Dans la console Google Cloud, accédez à l'explorateur de journaux.

Accéder à l'explorateur de journaux
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet contenant l'instance de VM, comme indiqué sur la ligne Nom complet de la ressource dans l'onglet Récapitulatif des détails de la recherche.
Recherchez dans les journaux des signes d'intrusion sur l'instance de VM concernée. Par exemple, recherchez des activités suspectes ou inconnues, ainsi que des signes de piratage d'identifiants.

Étape 3 : Vérifier les autorisations et les paramètres

Dans l'onglet Récapitulatif des détails de l'anomalie, dans le champ Nom complet de la ressource, cliquez sur le lien.
Vérifiez les détails de l'instance de VM, y compris les paramètres réseau et d'accès.

Étape 4: Inspectez la VM concernée

Suivez les instructions de la section Inspecter une VM pour détecter les signes de falsification de la mémoire du noyau.

Étape 5 : Étudier les méthodes d'attaque et de réponse

Examinez les entrées du framework MITRE ATT&CK pour Évasion de défense.
Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.

Étape 6 : Mettre en œuvre votre réponse

Contactez le propriétaire de la VM.
Si nécessaire, arrêtez l'instance compromise et remplacez-la par une nouvelle instance.
Pour l'analyse forensique, envisagez de sauvegarder les machines virtuelles et les disques persistants. Pour en savoir plus, consultez la section Options de protection des données dans la documentation Compute Engine.
Supprimez l'instance de VM.
Pour une enquête plus approfondie, envisagez d'utiliser des services de gestion des incidents tels que Mandiant.

`Execution: Cryptocurrency Mining Hash Match`

VM Threat Detection a détecté des activités de minage de cryptomonnaie en faisant correspondre les hachages de mémoire des programmes en cours d'exécution avec des hachages de mémoire connus du logiciel de minage de cryptomonnaie.

Pour répondre à ces résultats, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez un résultat Execution: Cryptocurrency Mining Hash Match, comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Résumé.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Risque détecté, en particulier les champs suivants:
  - Famille binaire: application de cryptomonnaie détectée.
  - Programme binaire: chemin absolu du processus.
  - Arguments: arguments fournis lors de l'appel du binaire du processus.
  - Noms de processus: nom du processus exécuté dans l'instance de VM associé aux correspondances de signature détectées.
  VM Threat Detection peut reconnaître les compilations du noyau des principales distributions Linux. Si elle peut reconnaître la compilation du noyau de la VM concernée, elle peut identifier les détails du processus de l'application et renseigner le champ processes du résultat. Si VM Threat Detection ne peut pas reconnaître le noyau (par exemple, s'il est compilé de manière personnalisée), le champ processes du résultat n'est pas renseigné.
- Ressource concernée, en particulier les champs suivants:
  - Nom complet de la ressource: nom complet de la ressource de l'instance de VM concernée, y compris l'ID du projet qui la contient.
Pour afficher le code JSON complet de ce résultat, dans la vue détaillée, cliquez sur l'onglet JSON.
- indicator
  - signatures :
    - memory_hash_signature: signature correspondant aux hachages de page de mémoire.
    - detections
      - binary: nom du binaire de l'application de cryptomonnaie (par exemple, linux--x86-64_ethminer_0.19.0_alpha.0_cuda10.0)
      - percent_pages_matched: pourcentage de pages en mémoire correspondant aux pages d'applications de cryptomonnaie connues dans la base de données de hachage des pages.

Étape 2 : Vérifier les journaux

Dans la console Google Cloud, accédez à l'explorateur de journaux.

Accéder à l'explorateur de journaux
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet contenant l'instance de VM, comme indiqué sur la ligne Nom complet de la ressource dans l'onglet Récapitulatif des détails de la recherche.
Recherchez dans les journaux des signes d'intrusion sur l'instance de VM concernée. Par exemple, recherchez des activités suspectes ou inconnues, ainsi que des signes de piratage d'identifiants.

Étape 3 : Vérifier les autorisations et les paramètres

Dans l'onglet Récapitulatif des détails de l'anomalie, dans le champ Nom complet de la ressource, cliquez sur le lien.
Vérifiez les détails de l'instance de VM, y compris les paramètres réseau et d'accès.

Étape 4 : Rechercher des méthodes d'attaque et de réponse

Examinez les entrées du framework MITRE ATT&CK pour Exécution.
Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.

Étape 5 : Mettre en œuvre votre réponse

Pour faciliter la détection et la suppression, utilisez une solution de détection et de gestion des points de terminaison.

Contactez le propriétaire de la VM.
Confirmez si l'application est une application de minage :
- Si le nom du processus et du chemin binaire de l'application détectés sont disponibles, tenez compte des valeurs des lignes Program binary (Programme binaire), Arguments (Arguments) et Process names (Noms de processus) dans l'onglet Summary (Récapitulatif) des détails de la recherche dans votre enquête.
- Si les détails du processus ne sont pas disponibles, vérifiez si le nom binaire de la signature de hachage de mémoire peut fournir des indices. Prenons l'exemple d'un binaire nommé linux-x86-64_xmrig_2.14.1. Vous pouvez utiliser la commande grep pour rechercher des fichiers notables dans l'espace de stockage. Utilisez une partie significative du nom binaire dans votre format de recherche, par exemple xmrig. Examinez les résultats de recherche.
- Examinez les processus en cours d'exécution, en particulier les processus avec une utilisation intensive du processeur, pour voir s'ils sont inconnus. Déterminez si les applications associées sont des applications de minage.
- Recherchez dans les fichiers de l'espace de stockage les chaînes courantes utilisées par les applications de minage, telles que btc.com, ethminer, xmrig, cpuminer et randomx. Pour plus d'exemples de chaînes à rechercher, consultez la section Noms des logiciels et règles YARA et la documentation associée pour chaque logiciel répertorié.
Si vous considérez que l'application est une application mineure et que son processus est toujours en cours d'exécution, arrêtez-le. Recherchez le binaire exécutable de l'application dans l'espace de stockage de la VM, puis supprimez-le.
Si nécessaire, arrêtez l'instance compromise et remplacez-la par une nouvelle instance.

`Execution: Cryptocurrency Mining YARA Rule`

VM Threat Detection a détecté des activités de minage de cryptomonnaie en faisant correspondre des modèles de mémoire, tels que les constantes de démonstration de faisabilité, connues pour être utilisées par les logiciels de minage de cryptomonnaie.

Pour répondre à ces résultats, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez un résultat Execution: Cryptocurrency Mining YARA Rule, comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Résumé.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Risque détecté, en particulier les champs suivants:
  - Nom de la règle YARA: règle déclenchée pour les détecteurs YARA.
  - Programme binaire: chemin absolu du processus.
  - Arguments: arguments fournis lors de l'appel du binaire du processus.
  - Noms de processus: nom des processus exécutés dans l'instance de VM associée aux correspondances de signature détectées.
  VM Threat Detection peut reconnaître les compilations du noyau des principales distributions Linux. Si elle peut reconnaître la compilation du noyau de la VM concernée, elle peut identifier les détails du processus de l'application et renseigner le champ processes du résultat. Si VM Threat Detection ne peut pas reconnaître le noyau (par exemple, s'il est compilé de manière personnalisée), le champ processes du résultat n'est pas renseigné.
- Ressource concernée, en particulier les champs suivants:
  - Nom complet de la ressource: nom complet de la ressource de l'instance de VM concernée, y compris l'ID du projet qui la contient.
- Liens associés, en particulier les champs suivants:
  - URI Cloud Logging: lien vers les entrées de journalisation.
  - Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
  - Résultats associés: liens vers les résultats associés.
  - Indicateur VirusTotal: lien vers la page d'analyse VirusTotal.
  - Chronicle: lien vers Google SecOps.
Pour afficher le code JSON complet de ce résultat, dans la vue détaillée, cliquez sur l'onglet JSON.

Étape 2 : Vérifier les journaux

Dans la console Google Cloud, accédez à l'explorateur de journaux.

Accéder à l'explorateur de journaux
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet contenant l'instance de VM, comme indiqué sur la ligne Nom complet de la ressource dans l'onglet Récapitulatif des détails du résultat.
Recherchez dans les journaux des signes d'intrusion sur l'instance de VM concernée. Par exemple, recherchez des activités suspectes ou inconnues, ainsi que des signes de piratage d'identifiants.

Étape 3 : Vérifier les autorisations et les paramètres

Dans l'onglet Récapitulatif des détails de l'anomalie, dans le champ Nom complet de la ressource, cliquez sur le lien.
Vérifiez les détails de l'instance de VM, y compris les paramètres réseau et d'accès.

Étape 4 : Rechercher des méthodes d'attaque et de réponse

Examinez les entrées du framework MITRE ATT&CK pour Exécution.
Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.

Étape 5 : Mettre en œuvre votre réponse

Pour faciliter la détection et la suppression, utilisez une solution de détection et de gestion des points de terminaison.

Contactez le propriétaire de la VM.
Confirmez si l'application est une application de minage :
- Si le nom du processus et du chemin binaire de l'application détectés sont disponibles, tenez compte des valeurs des lignes Program binary (Programme binaire), Arguments (Arguments) et Process names (Noms de processus) dans l'onglet Summary (Récapitulatif) des détails de la recherche dans votre enquête.
- Examinez les processus en cours d'exécution, en particulier les processus avec une utilisation intensive du processeur, pour voir s'ils sont inconnus. Déterminez si les applications associées sont des applications de minage.
- Recherchez dans les fichiers de l'espace de stockage les chaînes courantes utilisées par les applications de minage, telles que btc.com, ethminer, xmrig, cpuminer et randomx. Pour plus d'exemples de chaînes à rechercher, consultez la section Noms des logiciels et règles YARA et la documentation associée pour chaque logiciel répertorié.
Si vous considérez que l'application est une application mineure et que son processus est toujours en cours d'exécution, arrêtez-le. Recherchez le binaire exécutable de l'application dans l'espace de stockage de la VM, puis supprimez-le.
Si nécessaire, arrêtez l'instance compromise et remplacez-la par une nouvelle instance.

`Execution: cryptocurrency mining combined detection`

VM Threat Detection a détecté plusieurs catégories de résultats en une seule journée à partir d'une seule source. Une même application peut déclencher simultanément Execution: Cryptocurrency Mining YARA Rule et Execution: Cryptocurrency Mining Hash Match findings.

Pour répondre à un résultat combiné, suivez les instructions de réponse pour Execution: Cryptocurrency Mining YARA Rule et Execution: Cryptocurrency Mining Hash Match findings.

`Malware: Malicious file on disk (YARA)`

VM Threat Detection a détecté un fichier potentiellement malveillant en analysant les disques persistants d'une VM à la recherche de signatures de logiciels malveillants connues.

Pour répondre à ces résultats, procédez comme suit :

Étape 1 : Examiner les détails du résultat

Ouvrez le résultat Malware: Malicious file on disk (YARA), comme indiqué dans la section Examiner les résultats. Le panneau d'informations du résultat s'ouvre dans l'onglet Résumé.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes:
- Ce qui a été détecté, en particulier les champs suivants :
  - Nom de la règle YARA: règle YARA à laquelle la correspondance a été établie.
  - Files (Fichiers) : UUID de la partition et chemin d'accès relatif du fichier potentiellement malveillant détecté.
- Ressource concernée, en particulier les champs suivants :
  - Nom complet de la ressource: nom complet de la ressource de l'instance de VM concernée, y compris l'ID du projet qui la contient.
Pour afficher le code JSON complet de ce résultat, dans la vue détaillée, cliquez sur l'onglet JSON.
Dans le fichier JSON, notez les champs suivants:
- indicator
  - signatures :
    - yaraRuleSignature: signature correspondant à la règle YARA qui a été mise en correspondance.

Étape 2 : Vérifier les journaux

Dans la console Google Cloud, accédez à l'explorateur de journaux.

Accéder à l'explorateur de journaux
Dans la barre d'outils de la console Google Cloud, sélectionnez le projet contenant l'instance de VM, comme indiqué sur la ligne Nom complet de la ressource dans l'onglet Récapitulatif des détails de l'anomalie.
Recherchez dans les journaux des signes d'intrusion sur l'instance de VM concernée. Par exemple, recherchez des activités suspectes ou inconnues, ainsi que des signes de piratage d'identifiants.

Étape 3 : Vérifier les autorisations et les paramètres

Dans l'onglet Récapitulatif des détails de l'anomalie, dans le champ Nom complet de la ressource, cliquez sur le lien.
Vérifiez les détails de l'instance de VM, y compris les paramètres réseau et d'accès.

Étape 4 : Rechercher des méthodes d'attaque et de réponse

Vérifiez la valeur de hachage SHA-256 du binaire signalé comme malveillant sur VirusTotal en cliquant sur le lien dans l'indicateur VirusTotal. VirusTotal est un service appartenant à Alphabet qui fournit du contexte sur des fichiers, des URL, des domaines et des adresses IP potentiellement malveillants.

Étape 5 : Mettre en œuvre votre réponse

Contactez le propriétaire de la VM.
Si nécessaire, recherchez et supprimez le fichier potentiellement malveillant. Pour obtenir l'UUID de la partition et le chemin d'accès relatif du fichier, consultez le champ Fichiers dans l'onglet Récapitulatif des détails de la recherche. Pour faciliter la détection et la suppression, utilisez une solution de détection et de gestion des points de terminaison.
Si nécessaire, arrêtez l'instance compromise et remplacez-la par une nouvelle instance.

Remarque :Avec le niveau Security Command Center Enterprise, vous pouvez également effectuer cette action via un playbook de réponse aux menaces.
Pour l'analyse forensique, envisagez de sauvegarder les machines virtuelles et les disques persistants. Pour en savoir plus, consultez la section Options de protection des données dans la documentation Compute Engine.
Pour une enquête plus approfondie, envisagez d'utiliser des services de gestion des incidents tels que Mandiant.

Corriger les failles associées

Pour éviter que les menaces ne se reproduisent, examinez et corrigez les résultats de failles et d'erreurs de configuration associés.

Pour trouver d'autres résultats associés, procédez comme suit:

Dans la console Google Cloud, accédez à la page Résultats de Security Command Center.

Accéder
Examinez le résultat de la menace et copiez la valeur d'un attribut susceptible d'apparaître dans tout résultat de faille ou de mauvaise configuration associé, comme l'adresse e-mail principale ou le nom de la ressource affectée.
Sur la page Résultats, ouvrez l'Éditeur de requête en cliquant sur Modifier la requête.
Cliquez sur Ajouter un filtre. Le menu Sélectionner un filtre s'ouvre.
Dans la liste des catégories de filtres sur le côté gauche du menu, sélectionnez la catégorie contenant l'attribut que vous avez noté dans la menace détectée.

Par exemple, si vous avez noté le nom complet de la ressource concernée, sélectionnez Ressource. Les types d'attributs de la catégorie Resource (Ressource) s'affichent dans la colonne de droite, y compris l'attribut Full name (Nom complet).
Parmi les attributs affichés, sélectionnez le type d'attribut que vous avez noté dans le résultat de la menace. Un panneau de recherche des valeurs d'attribut s'ouvre sur la droite et affiche toutes les valeurs trouvées du type d'attribut sélectionné.
Dans le champ Filtre, collez la valeur de l'attribut que vous avez copiée à partir de la menace détectée. La liste des valeurs affichée est mise à jour pour n'afficher que les valeurs correspondant à la valeur collée.
Dans la liste des valeurs affichées, sélectionnez une ou plusieurs valeurs, puis cliquez sur Appliquer. Le panneau Résultats de la requête de résultats est mis à jour pour n'afficher que les résultats correspondants.
Si les résultats contiennent de nombreuses observations, filtrez-les en sélectionnant des filtres supplémentaires dans le panneau Filtres rapides.

Par exemple, pour afficher uniquement les résultats de classe Vulnerability et Misconfiguration contenant les valeurs d'attribut sélectionnées, faites défiler la section Finding class (Classe de résultats) du panneau Quick filters (Filtres rapides), puis sélectionnez Vulnerability (Faille) et Misconfiguration (Mauvaise configuration).

Outre les indicateurs de compromission fournis par Google, les utilisateurs clients de Palo Alto Networks peuvent intégrer la fonctionnalité AutoFocus Threat Intelligence de Palo Alto Networks à la solution Event Threat Detection. AutoFocus est un service de renseignements sur les menaces qui fournit des informations sur les menaces réseau. Pour en savoir plus, consultez la page AutoFocus dans la console Google Cloud.

Résoudre les menaces

Corriger les résultats d'Event Threat Detection et de Container Threat Detection n'est pas aussi simple que de corriger des erreurs de configuration et des failles identifiées par Security Command Center.

Les erreurs de configuration et les violations de conformité identifient les faiblesses des ressources qui pourraient être exploitées. En règle générale, les erreurs de configuration ont des correctifs connus et facilement mis en œuvre, tels que l'activation d'un pare-feu ou la rotation d'une clé de chiffrement.

Les menaces diffèrent des failles dans la mesure où elles sont dynamiques et indiquent une exploitation active possible sur une ou plusieurs ressources. Une recommandation de correction peut ne pas être efficace pour sécuriser vos ressources, car les méthodes exactes utilisées pour exploiter la faille peuvent ne pas être connues.

Par exemple, un résultat Added Binary Executed indique qu'un binaire non autorisé a été lancé dans un conteneur. Une recommandation de correction de base peut vous conseiller de mettre le conteneur en quarantaine et de supprimer le binaire, mais cela peut ne pas résoudre la cause racine sous-jacente qui a permis à l'attaquant d'exécuter le binaire. Vous devez déterminer comment l'image du conteneur a été corrompue pour corriger l'exploitation. Pour déterminer si le fichier a été ajouté via un port mal configuré ou par un autre moyen, une enquête approfondie est nécessaire. Il peut s'avérer nécessaire de demander à un analyste ayant des connaissances approfondies de votre système d'en examiner les faiblesses.

Les acteurs malveillants attaquent des ressources à l'aide de différentes techniques. Par conséquent, l'application d'un correctif pour une attaque spécifique peut ne pas être efficace contre les variantes de cette attaque. Par exemple, en réponse à un résultat Brute Force: SSH, vous pouvez réduire les niveaux d'autorisation pour certains comptes utilisateur afin de limiter l'accès aux ressources. Toutefois, un mot de passe peu sécurisé peut tout de même fournir un vecteur d'attaque.

L'ampleur des vecteurs d'attaque ne permet pas de fournir des mesures correctives qui fonctionnent dans toutes les situations. Dans votre plan de sécurité cloud, Security Command Center identifie les ressources concernées quasiment en temps réel, vous indique les menaces auxquelles vous faites face et vous fournit des preuves et du contexte pour vous aider dans vos recherches. Toutefois, votre personnel de sécurité doit utiliser les informations détaillées des résultats de Security Command Center afin de déterminer les meilleurs moyens de résoudre les failles et de protéger les ressources contre les attaques futures.

Étape suivante

Consultez la présentation d'Event Threat Detection pour en savoir plus sur le service et les menaces qu'il détecte.
Pour en savoir plus sur le fonctionnement du service, consultez la page Présentation de Container Threat Detection.
Consultez la présentation de VM Threat Detection pour en savoir plus sur le service et les menaces qu'il détecte.