Présentation de la latence sur Security Command Center

Cette page présente le processus d'activation a lieu lorsque vous activez Security Command Center. Elle a pour objectif de répondre aux questions courantes suivantes :

  • Que se passe-t-il lorsque Security Command Center est activé ?
  • Pourquoi y a-t-il un délai avant le début des premières analyses ?
  • Combien de temps prend généralement l'exécution de la première analyse et des analyses en cours ?
  • Quelle est l'incidence de la modification des ressources et des paramètres sur les performances ?

Présentation

Lorsque vous activez Security Command Center pour la première fois, un processus d'activation doit se terminer avant que Security Command Center puisse commencer à analyser vos ressources. Ensuite, les numérisations à effectuer avant d'obtenir un ensemble complet de résultats environnement Google Cloud.

La durée du processus d'activation et des analyses dépend de un certain nombre de facteurs, comme le nombre d'éléments et de ressources environnement et si Security Command Center est activé au niveau de l'organisation ou au niveau du projet.

Pour les activations au niveau de l'organisation, Security Command Center doit répéter certaines étapes du processus d'activation pour chaque projet du organisation. En fonction du nombre de projets dans une organisation, le temps requis pour le processus d'activation peut varier de minutes à heures. Pour les organisations comptant plus de 100 000 projets, de nombreuses ressources dans chaque projet, et d'autres facteurs de complication, et les analyses initiales peuvent prendre jusqu'à 24 heures.

Lorsque Security Command Center est activé au niveau du projet, l'activation est beaucoup plus rapide, car il est limité à un seul projet dans lequel Security Command Center est activé.

Facteurs pouvant entraîner une latence lors du démarrage des analyses, du traitement les modifications des paramètres et l'exécution des analyses sont abordés dans les sections .

Topology

L'illustration ci-dessous offre une vue d'ensemble générale des processus d'intégration et d'activation.

Illustration du processus d'intégration de Security Command Center (cliquez pour agrandir)
Illustration du processus d'intégration de Security Command Center (cliquez pour agrandir)

Latence d'intégration

Avant le début des analyses, Security Command Center découvre et indexe vos ressources.

Les services indexés incluent App Engine, BigQuery, Cloud SQL, Cloud Storage, Compute Engine, Identity and Access Management et Google Kubernetes Engine.

Pour les activations de Security Command Center au niveau du projet, la détection et l'indexation est limitée au projet unique dans lequel Security Command Center est activé.

Pour les activations au niveau de l'organisation, Security Command Center détecte et indexe les ressources de votre organisation.

Au cours de ce processus d'intégration, deux étapes essentielles ont lieu.

Analyse des éléments

Security Command Center lance une analyse initiale des éléments pour identifier le nombre total, l'emplacement et l'état des projets, des dossiers, des fichiers, des clusters, des identités, des stratégies d'accès, des utilisateurs inscrits et des autres ressources. Ce processus prend généralement quelques minutes.

Activation de l'API

À mesure que des ressources sont détectées, Security Command Center active les composants Google Cloud requis pour le bon fonctionnement de Security Health Analytics, d'Event Threat Detection, de Container Threat Detection et de Web Security Scanner. Certains services de détection nécessitent l'activation d'API spécifiques sur des projets protégés.

Lorsque vous activez Security Command Center au niveau du projet, l'activation de l'API prend généralement moins d'une minute.

Avec les activations au niveau de l'organisation, Security Command Center effectue des itérations tous les projets que vous sélectionnez pour analyse afin d'activer les API nécessaires.

Le nombre de projets au sein d'une organisation détermine en grande partie la durée des processus d'intégration et d'activation. Étant donné que les API doivent être activées une par une pour les projets, cette tâche est généralement la plus chronophage, en particulier pour les organisations comptant plus de 100 000 projets.

Le temps nécessaire pour activer les services sur plusieurs projets évolue de manière linéaire. En règle générale, l'activation des services et des paramètres de sécurité d'une organisation comportant 30 000 projets prend deux fois plus de temps qu'une organisation qui en possède 15 000.

Pour une organisation comptant 100 000 projets, l'intégration et l'activation Le niveau Premium devrait être terminé en moins de cinq heures. Votre temps peut varient en fonction de nombreux facteurs, y compris le nombre de projets ou de conteneurs que vous utilisez et le nombre de services Security Command Center que vous choisissez d'activer.

Latence de l'analyse

Lorsque vous configurez Security Command Center, vous décidez quels services intégrés doivent être activés, puis vous sélectionnez les ressources Google Cloud à analyser ou à vérifier afin de détecter les menaces et les failles. Lorsque les API sont activées pour les projets, les services sélectionnés lancent leurs analyses. La durée de ces analyses dépend également du nombre de projets dans une organisation.

Les résultats des services intégrés sont disponibles à mesure que les analyses initiales sont terminées. La latence des services est décrite ci-dessous.

  • Container Threat Detection présente les latences suivantes :
    • Latence d'activation pouvant atteindre 3,5 heures pour les nouveaux projets ou organizations.
    • Latence d'activation de plusieurs minutes pour les clusters nouvellement créés.
    • Latence de détection de plusieurs minutes pour les menaces dans les clusters qui ont été activés
  • L'activation d'Event Threat Detection s'effectue en quelques secondes et les détecteurs de fumée. Cela peut prendre jusqu'à 15 minutes pour les nouveaux détecteurs personnalisés ou ceux qui ont été mis à jour pour que vos modifications soient prises en compte. En pratique, il faut en général moins de cinq étapes minutes.

    Pour les détecteurs intégrés et personnalisés, les latences sont généralement inférieures à 15 minutes à partir du moment où un journal est écrit quand un résultat est disponible dans Security Command Center.

  • Les analyses de Security Health Analytics commencent environ une heure après l'activation du service. Les premières analyses de Security Health Analytics peuvent prendre jusqu'à 12 heures. Ensuite, la plupart des détections sont exécutées en temps réel sur les modifications de configuration des éléments. Les exceptions à cette règle sont décrites dans la section Latence de détection de Security Health Analytics.

  • VM Threat Detection a une latence d'activation pouvant atteindre 48 heures pour les à des organisations intégrées. Pour les projets, la latence d'activation est de 15 minutes.

  • L'évaluation des failles pour Amazon Web Services (AWS) commence à analyser les ressources dans un compte AWS environ 15 minutes après l'exécution Le modèle CloudFormation est le premier déployées dans le compte. Lorsqu'une faille logicielle est détectée dans le compte AWS, le résultat correspondant devient disponible dans Security Command Center environ 10 minutes plus tard.

    Le temps nécessaire pour effectuer une analyse dépend du nombre d'EC2 Compute Engine. En règle générale, l'analyse d'une seule instance EC2 prend moins de 5 minutes

  • Un délai maximal de 24 heures peut être nécessaire pour que les analyses de Web Security Scanner se lancent après l'activation du service et son exécution hebdomadaire suivant l'analyse initiale.

Security Command Center exécute des détecteurs d'erreurs qui détectent les erreurs de configuration liées à Security Command Center et à ses services. Ces détecteurs d'erreurs sont activés par défaut et ne peuvent pas être désactivés. Les latences de détection varient en fonction du détecteur d'erreurs. Pour en savoir plus, consultez la page Erreurs Security Command Center.

Les rôles IAM pour Security Command Center peuvent être attribués au niveau de l'organisation, d'un dossier ou d'un projet. Votre capacité à afficher, modifier, créer ou mettre à jour des résultats, des éléments, et les sources de sécurité dépendent du niveau d'accès accordé. Pour apprendre Pour en savoir plus sur les rôles de Security Command Center, consultez la page Contrôle des accès.

Résultats préliminaires

Certains résultats peuvent s'afficher dans la console Google Cloud pendant la phase initiale les analyses sont effectuées, mais avant la fin du processus d'intégration.

Les résultats préliminaires sont précis et exploitables, mais ils ne sont pas exhaustifs. Il est déconseillé de les utiliser pour une évaluation de conformité dans les premières 24 heures.

Analyses ultérieures

les modifications apportées à votre organisation ou à votre projet, telles que le déplacement de ressources ; ou, pour les activations au niveau de l'organisation, l'ajout de dossiers et de projets, n'ont généralement pas d'impact significatif sur le temps de découverte des ressources ou l'exécution des analyses. Toutefois, certaines analyses s'effectuent selon des planifications définies, qui déterminent la vitesse à laquelle Security Command Center détecte les modifications.

  • Event Threat Detection et Container Threat Detection : ces services s'exécutent en temps réel lorsqu'ils sont activés, et détectent immédiatement de nouvelles ressources ou des ressources modifiées, telles que les clusters, les buckets ou les journaux, dans les projets activés.
  • La fonctionnalité Rapid Vulnerability Detection effectue des analyses hebdomadaires à compter de la date du la première analyse. Si de nouvelles ressources sont ajoutées à des projets entre les analyses, aucune faille ne sera découverte avant la prochaine analyse.
  • Security Health Analytics : s'exécute en temps réel lorsqu'elle est activée, et détecte les nouvelles ressources ou les ressources modifiées en quelques minutes, à l'exclusion des détections répertoriées ci-dessous.
  • VM Threat Detection: pour l'analyse de la mémoire, VM Threat Detection analyse chaque instance de VM. immédiatement après le est créée. De plus, VM Threat Detection analyse chaque instance de VM toutes les 30 minutes.
    • Pour la détection du minage de cryptomonnaie, VM Threat Detection en génère un résultats par processus, par VM et par jour. Chaque résultat n'inclut que les menaces associées qui est identifié par le résultat. Si VM Threat Detection détecte les menaces, mais ne peut les associer à aucun processus, il regroupe pour chaque VM toutes kes menaces non associées dans un seul résultat qu'il émet une fois toutes les 24 heures. Pour les menaces qui durent plus de 24 heures, VM Threat Detection génère les nouveaux résultats toutes les 24 heures.
    • Pour la détection des rootkits en mode noyau, qui est en version preview, VM Threat Detection en génère un les résultats par catégorie et par VM tous les trois jours.

    Pour l'analyse des disques persistants, qui détecte la présence de logiciels malveillants connus, VM Threat Detection analyse chaque instance de VM au moins une fois par jour.

  • L'évaluation des failles pour AWS exécute des analyses trois fois par jour.

    Le temps nécessaire pour effectuer une analyse dépend du nombre d'EC2 Compute Engine. En règle générale, l'analyse d'une seule instance EC2 prend moins de 5 minutes

    Lorsqu'une faille logicielle est détectée dans un compte AWS, le résultat correspondant devient disponible dans Security Command Center environ 10 minutes plus tard.

  • Web Security Scanner : s'exécute chaque semaine, le même jour que l'analyse initiale. Étant donné qu'il s'exécute toutes les semaines, Web Security Scanner en temps réel. Si vous déplacez une ressource ou modifiez une application, vous devrez attendre jusqu'à une semaine avant que la modification puisse être détectée. Vous pouvez exécuter des analyses à la demande pour vérifier les ressources nouvelles ou modifiées entre les analyses planifiées.

Les détecteurs d'erreurs de Security Command Center s'exécutent régulièrement en mode de traitement par lot. Les fréquences d'analyse par lots varient en fonction du détecteur d'erreurs. Pour en savoir plus, consultez la page Erreurs Security Command Center.

Latence de détection de Security Health Analytics

Les détections de Security Health Analytics s'exécutent régulièrement en mode de traitement par lot une fois le service activé, ainsi que lorsqu'un élément de configuration associé change. Une fois Security Health Analytics activé, toute modification de configuration d'une ressource concernée entraîne une mise à jour des résultats de la configuration incorrecte. Dans certains cas, les mises à jour peuvent prendre plusieurs minutes en fonction du type d'élément et de la modification qui y est apportée.

Certains détecteurs de Security Health Analytics ne sont pas compatibles avec le mode d'analyse immédiat, par exemple lorsqu'une détection est exécutée sur des informations situées en dehors de la configuration d'une ressource. Ces détections, répertoriées dans le tableau ci-dessous, s'exécutent régulièrement et identifient les erreurs de configuration dans les 12 heures. Pour en savoir plus sur les détecteurs de Security Health Analytics, consultez la page Failles et résultats.

Détections de Security Health Analytics non compatibles avec le mode d'analyse en temps réel
COMPUTE_PROJECT_WIDE_SSH_KEYS_ALLOWED
MFA_NOT_ENFORCED (précédemment nommé 2SV_NOT_ENFORCED)
OS_LOGIN_DISABLED
SQL_NO_ROOT_PASSWORD
SQL_WEAK_ROOT_PASSWORD

Simulations de chemin d'attaque

Les simulations de chemin d'attaque sont exécutées toutes les six heures environ. En tant que d'une organisation Google Cloud de plus en plus vaste ou complexe, le temps entre les intervalles peut augmenter.

Lorsque vous activez Security Command Center pour la première fois, utilisez un ensemble de ressources à forte valeur par défaut, qui inclut toutes les types de ressources compatibles de votre organisation.

Lorsque vous commencez à définir votre propre ensemble de ressources à forte valeur configuration de la valeur de ressource, vous pouvez voir le délai entre la simulation d'intervalles diminuent si le nombre d'instances de ressources dans votre est nettement inférieure à l'ensemble par défaut.

Étape suivante