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 "Analyse des risques pour l'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 de 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 l'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 à l'historique d'utilisation.
  • Authentifications échouées par appareil: une entité à appareil unique a enregistré de nombreuses tentatives de connexion infructueuses récemment, par rapport à l'historique d'utilisation.
  • Authentifications échouées par utilisateur: une entité à usage unique a récemment enregistré de nombreuses tentatives de connexion infructueuses, par rapport à l'historique d'utilisation.

Analyse du trafic réseau

  • Octets entrants anormaux par appareil: quantité importante de données récemment importées vers une entité d'appareil unique, par rapport à l'historique d'utilisation.
  • 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'historique d'utilisation.
  • Nombre total d'octets anormal par appareil: une entité d'appareil a récemment importé et téléchargé une quantité importante de données, par rapport à l'historique d'utilisation.
  • Octets entrants anormaux par utilisateur: une entité à usage unique a récemment téléchargé une quantité importante de données, par rapport à l'historique d'utilisation.
  • Octets totaux anormaux par utilisateur: une entité utilisateur a récemment importé et téléchargé une quantité importante de données, par rapport à l'historique d'utilisation.
  • Attaque par force brute, puis connexion réussie de l'utilisateur: une entité à usage unique disposant d'une adresse IP a effectué plusieurs tentatives d'authentification infructueuses sur une application donnée avant de réussir à se connecter.

Détections basées sur les groupes de pairs

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

  • Actions suspectes anormales ou excessives pour un nouvel utilisateur : 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 créé récemment. Cette valeur 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 nouveaux comptes utilisateur.
  • Alertes excessives par l'utilisateur: un grand nombre d'alertes de sécurité provenant d'un antivirus ou d'un appareil de point de terminaison (par exemple, connexion bloquée, logiciel malveillant détecté) ont été signalées pour une entité utilisateur, ce qui était beaucoup plus important que les tendances historiques. Il s'agit d'é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 fonctionnalités d'exfiltration de données: activité anormale ou excessive pour les processus associés à des fonctionnalités d'exfiltration de données telles que les enregistreurs de frappe, les captures d'écran et l'accès à distance. Cette fonctionnalité utilise l'enrichissement des métadonnées de fichier de VirusTotal.

Données requises par l'analyse des risques pour la catégorie UEBA

La section suivante décrit les données nécessaires aux ensembles de règles de chaque catégorie pour en tirer le meilleur parti. Pour obtenir la liste de tous les analyseurs par défaut compatibles, consultez la section Types de journaux et analyseurs par défaut compatibles.

Authentification

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

Analyse du trafic réseau

Pour utiliser l'un de ces ensembles de règles, collectez des données de journal 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 des données de journal à partir d'Azure AD Directory Audit (AZURE_AD_AUDIT) ou d'un événement Windows (WINEVTLOG).

Actions suspectes

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

Règle de création de compte excessive par appareil

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

Ensemble de règles "Alertes excessives par utilisateur"

Pour utiliser ce jeu de règles, collectez des données de journal 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 des données de journal 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 avec les valeurs metadata.event_type suivantes: PROCESS_LAUNCH, PROCESS_OPEN et PROCESS_MODULE_LOAD.

Les alertes de réglage renvoyées par la règle définissent 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 d'exclusions de règles.

Une exclusion de règle définit les critères utilisés pour exclure un événement de l'évaluation 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 la section Configurer des exclusions de règles.

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

L'exemple suivant montre comment créer une règle pour générer des détections sur tout 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
}

Cet exemple de règle effectue également une auto-déduplication à l'aide de la section de correspondance. Si une détection de règle peut se déclencher, mais que le nom d'hôte et le score de risque restent inchangés dans un délai 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 24 heures ou 7 jours (86 400 ou 604 800 secondes respectivement). Si vous n'incluez pas la taille de la fenêtre de risque dans la règle, celle-ci renvoie des résultats inexacts.

Les données de score de risque des entités sont stockées séparément des données de contexte 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 illustré 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
}

Étape suivante

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