Présentation de l'analyse des risques pour la catégorie UEBA

Compatible avec :

Ce document présente les ensembles de règles de la catégorie "Risk Analytics for UEBA" (Analyse des risques pour UEBA), les données requises et la configuration que vous pouvez utiliser pour ajuster les alertes générées par chaque ensemble de règles. Ces ensembles de règles permettent d'identifier les menaces dans les environnements Google Cloudà l'aide des données Google Cloud .

Descriptions des ensembles de règles

Les ensembles de règles suivants sont disponibles dans la catégorie "Analyse des risques pour UEBA" et sont regroupés par type de modèles détectés :

Authentification

  • Nouvelle connexion d'un utilisateur à un appareil : un utilisateur s'est connecté à un nouvel appareil.
  • Événements d'authentification anormaux par utilisateur : une seule entité utilisateur a récemment enregistré des événements d'authentification anormaux par rapport à son utilisation historique.
  • Échecs d'authentification par appareil : une entité à un seul appareil a récemment enregistré de nombreuses tentatives de connexion infructueuses, par rapport à son utilisation historique.
  • Échecs d'authentification par utilisateur : une entité mono-utilisateur a récemment enregistré de nombreuses tentatives de connexion infructueuses par rapport à son utilisation historique.

Analyse du trafic réseau

  • Octets entrants anormaux par appareil : quantité importante de données récemment importées dans une seule entité d'appareil, par rapport à l'utilisation historique.
  • Octets sortants anormaux par appareil : quantité importante de données récemment téléchargées à partir d'une seule entité d'appareil, par rapport à l'utilisation historique.
  • Nombre total d'octets anormaux par appareil : une entité d'appareil a récemment importé et téléchargé une quantité importante de données par rapport à son utilisation historique.
  • Octets entrants anormaux par utilisateur : une entité à utilisateur unique a récemment téléchargé une quantité importante de données par rapport à son utilisation historique.
  • Nombre total d'octets anormaux par utilisateur : une entité utilisateur a récemment importé et téléchargé une quantité importante de données par rapport à son utilisation historique.
  • Connexion réussie après une attaque par force brute : une entité utilisateur unique à partir d'une adresse IP a effectué plusieurs tentatives d'authentification infructueuses pour une application spécifique avant de se connecter avec succès.

Détections basées sur les groupes de pairs

  • Connexions anormales ou excessives pour un utilisateur nouvellement créé : activité d'authentification anormale ou excessive pour un utilisateur récemment créé. Il utilise l'heure de création des données du contexte de l'annonce.

  • Actions suspectes anormales ou excessives pour un utilisateur nouvellement créé : activité anormale ou excessive (y compris, mais sans s'y limiter, la télémétrie HTTP, l'exécution de processus et la modification de groupes) pour un utilisateur récemment créé. Cette option utilise l'heure de création des données de contexte AD.

Actions suspectes

  • Création excessive de comptes par appareil : une entité d'appareil a créé plusieurs comptes utilisateur.
  • Alertes excessives par utilisateur : un grand nombre d'alertes de sécurité provenant d'un antivirus ou d'un appareil de point de terminaison (par exemple, la connexion a été bloquée, un logiciel malveillant a été détecté) ont été signalées concernant une entité utilisateur, ce qui est beaucoup plus élevé que les tendances historiques. Il s'agit des événements pour lesquels le champ UDM security_result.action est défini sur BLOCK.

Détections basées sur la protection contre la perte de données

  • Processus anormaux ou excessifs avec des capacités d'exfiltration de données : activité anormale ou excessive pour les processus associés aux capacités d'exfiltration de données, tels que les enregistreurs de frappe, les captures d'écran et l'accès à distance. Cette méthode utilise l'enrichissement des métadonnées de fichiers de VirusTotal.

Données requises par Risk Analytics pour la catégorie UEBA

Cette section décrit en détail les données requises par chaque catégorie d'ensemble de règles pour des performances optimales. Bien que les détections UEBA soient conçues pour fonctionner avec tous les analyseurs par défaut compatibles, l'utilisation des types de données spécifiques suivants maximise leur efficacité. Pour obtenir la liste complète des analyseurs par défaut compatibles, consultez Types de journaux et analyseurs par défaut compatibles.

Authentification

Pour utiliser l'un de ces ensembles de règles, collectez les données de journaux à partir d'Azure AD Directory Audit (AZURE_AD_AUDIT) ou de Windows Event (WINEVTLOG).

Analyse du trafic réseau

Pour utiliser l'un de ces ensembles de règles, collectez des données de journaux qui capturent l'activité réseau. Par exemple, à partir d'appareils tels que FortiGate (FORTINET_FIREWALL), Check Point (CHECKPOINT_FIREWALL), Zscaler (ZSCALER_WEBPROXY), CrowdStrike Falcon (CS_EDR) ou Carbon Black (CB_EDR).

Détections basées sur les groupes de pairs

Pour utiliser l'un de ces ensembles de règles, collectez les données de journaux à partir d'Azure AD Directory Audit (AZURE_AD_AUDIT) ou de Windows Event (WINEVTLOG).

Actions suspectes

Les ensembles de règles de ce groupe utilisent chacun un type de données différent.

Ensemble de règles "Création excessive de comptes par appareil"

Pour utiliser cet ensemble de règles, collectez les données de journaux à partir d'Azure AD Directory Audit (AZURE_AD_AUDIT) ou de Windows Event (WINEVTLOG).

Ensemble de règles "Alertes excessives par utilisateur"

Pour utiliser cet ensemble de règles, collectez les données de journaux qui capturent les activités des points de terminaison ou les données d'audit, telles que celles enregistrées par CrowdStrike Falcon (CS_EDR), Carbon Black (CB_EDR) ou Azure AD Directory Audit (AZURE_AD_AUDIT).

Détections basées sur la protection contre la perte de données

Pour utiliser l'un de ces ensembles de règles, collectez les données de journaux qui capturent les activités de processus et de fichiers, telles que celles enregistrées par CrowdStrike Falcon (CS_EDR), Carbon Black (CB_EDR) ou SentinelOne EDR (SENTINEL_EDR).

Les ensembles de règles de cette catégorie dépendent des événements dont les valeurs metadata.event_type sont les suivantes : PROCESS_LAUNCH, PROCESS_OPEN, PROCESS_MODULE_LOAD.

Ajuster les alertes renvoyées par les ensembles de règles de cette catégorie

Vous pouvez réduire le nombre de détections générées par une règle ou un ensemble de règles à l'aide des exclusions de règles.

Une exclusion de règle définit les critères utilisés pour empêcher l'évaluation d'un événement par l'ensemble de règles ou par des règles spécifiques de l'ensemble de règles. Créez une ou plusieurs exclusions de règles pour réduire le volume de détections. Pour en savoir plus, consultez Configurer des exclusions de règles.

Exemple de règle pour la catégorie "Analyse des risques pour UEBA"

L'exemple suivant montre comment créer une règle permettant de générer des détections sur n'importe quel nom d'hôte d'entité dont le score de risque est supérieur à 100 :

rule EntityRiskScore {
  meta:
  events:
    $e1.principal.hostname != ""
    $e1.principal.hostname = $hostname

    $e2.graph.entity.hostname = $hostname
    $e2.graph.risk_score.risk_window_size.seconds = 86400 // 24 hours
    $e2.graph.risk_score.risk_score >= 100

    // Run deduplication across the risk score.
    $rscore = $e2.graph.risk_score.risk_score

  match:
    // Dedup on hostname and risk score across a 4 hour window.
    $hostname, $rscore over 4h

  outcome:
    // Force these risk score based rules to have a risk score of zero to
    // prevent self feedback loops.
    $risk_score = 0

  condition:
    $e1 and $e2
}

Cette règle exemple effectue également une auto-déduplication à l'aide de la section "match". Si une détection de règle est susceptible de se déclencher, mais que le nom d'hôte et le score de risque restent inchangés pendant une période de quatre heures, aucune nouvelle détection n'est créée.

Les seules périodes de risque possibles pour les règles de score de risque des entités sont de 24 heures ou de 7 jours (86 400 ou 604 800 secondes, respectivement). Si vous n'incluez pas la taille de la période à risque dans la règle, celle-ci renverra des résultats inexacts.

Les données sur le score de risque des entités sont stockées séparément des données contextuelles des entités. Pour utiliser les deux dans une règle, celle-ci doit comporter deux événements d'entité distincts, l'un pour le contexte de l'entité et l'autre pour le score de risque de l'entité, comme indiqué dans l'exemple suivant :

rule EntityContextAndRiskScore {
  meta:
  events:
    $log_in.metadata.event_type = "USER_LOGIN"
    $log_in.principal.hostname = $host

    $context.graph.entity.hostname = $host
    $context.graph.metadata.entity_type = "ASSET"

    $risk_score.graph.entity.hostname = $host
    $risk_score.graph.risk_score.risk_window_size.seconds = 604800

  match:
    $host over 2m

  outcome:
    $entity_risk_score = max($risk_score.graph.risk_score.normalized_risk_score)

  condition:
    $log_in and $context and $risk_score and $entity_risk_score > 100
}

Étapes suivantes

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