Analyse des risques pour UEBA

Compatible avec :

Ce document présente les ensembles de règles de la catégorie "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 en évaluant les sources de journaux compatibles.

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èle détecté :

Authentification

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

Analyse du trafic réseau

  • Octets entrants anormaux par appareil : une quantité importante de données a récemment été importée dans une seule entité d'appareil par rapport à son utilisation historique.
  • Octets sortants anormaux par appareil : une quantité importante de données a récemment été téléchargée à partir d'une seule entité d'appareil par rapport à son utilisation historique.
  • Octets totaux 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 seule entité utilisateur a récemment téléchargé une quantité importante de données par rapport à son utilisation historique.
  • Octets totaux 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.
  • Force brute, puis connexion réussie par l'utilisateur : une seule entité utilisateur provenant d'une adresse IP a généré plusieurs tentatives d'authentification infructueuses pour une application avant de se connecter.

Détections basées sur des groupes de pairs

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

  • 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 groupe) pour un utilisateur créé récemment. Cette activité utilise l'heure de création des données contextuelles 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 était beaucoup plus élevé que les modèles 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 capacités d'exfiltration de données : activité anormale ou excessive pour les processus associés à des capacités d'exfiltration de données telles que les enregistreurs de frappe, les captures d'écran et l'accès à distance. Cette activité utilise l'enrichissement des métadonnées de fichiers à partir de VirusTotal.

Données requises par la catégorie "Analyse des risques pour UEBA"

Cette section décrit 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 leurs avantages. Pour obtenir la liste complète des 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 les données de journal à partir d'Azure AD Directory Audit (AZURE_AD_AUDIT) ou de Windows Event (WINEVTLOG).

Pour WINEVTLOG, vous devez configurer votre configuration de collecte de données pour inclure les Event IDs Windows suivants dans le Channel du journal des événements Security. Ces événements sont directement mappés aux Event types (par exemple, USER_LOGIN ou PROCESS_LAUNCH) utilisés par le moteur de détection.

Exigences concernant l'ID d'événement Windows

Type d'événement ID d'événement Windows
USER_LOGIN 529, 4624, 4625, 4626, 4648, 4672, 4768, 4769, 4770, 4771, 4777, 4820, 4821, 4964
USER_CREATION 4720
NETWORK_CONNECTION 4096, 4097, 4321, 5156, 5632, 5633, 5157
GROUP_MODIFICATION 4728, 4729, 4732, 4733, 4735, 4737, 4745, 4746, 4747, 4750, 4751, 4752, 4755, 4756, 4757, 4760, 4761, 4762, 4764, 4784, 4785, 4786, 4787, 4788, 4791
PROCESS_LAUNCH 4688
PROCESS_OPEN 4663, 4670, 4691, 8002

Analyse du trafic réseau

Pour utiliser l'un de ces ensembles de règles, collectez les 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 des groupes de pairs

Pour utiliser l'un de ces ensembles de règles, collectez les données de journal à 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 journal à 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 journal qui capturent les activités de point 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 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, 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 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 savoir comment procéder, 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 pour 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 d'exemple effectue également une déduplication automatique à 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 une fenêtre de quatre heures, aucune nouvelle détection n'est créée.

Les seules fenêtres de risque possibles pour les règles de score de risque d'entité sont de 24 heures ou de 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 d'entité sont stockées séparément des données contextuelles d'entité. Pour utiliser les deux dans une règle, celle-ci doit comporter deux événements d'entité distincts, un pour le contexte d'entité et un pour le score de risque d'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 auprès des membres de la communauté et des professionnels Google SecOps.