Analyse des risques pour UEBA
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è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é utilisateur unique a récemment enregistré de nombreuses tentatives de connexion infructueuses par rapport à son utilisation historique.
Analyse du trafic réseau
- Nombre d'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.
- Nombre d'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 anormal par appareil : une entité d'appareil a récemment importé et téléchargé une quantité importante de données par rapport à l'utilisation historique.
- Octets entrants anormaux par utilisateur : une entité mono-utilisateur 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.
- Force brute, puis connexion réussie par l'utilisateur : une entité utilisateur unique provenant d'une adresse IP a tenté de s'authentifier plusieurs fois sans succès auprès d'une application avant de réussir à se connecter.
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éé. Cette option 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 groupes) pour un utilisateur récemment créé. Cette option 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, connexion bloquée, logiciel malveillant détecté) ont été signalées pour une entité utilisateur, ce qui était beaucoup plus élevé que les tendances historiques.
Il s'agit d'événements pour lesquels le champ UDM
security_result.actionest défini surBLOCK.
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, comme les enregistreurs de frappe, les captures d'écran et l'accès à distance. Cette fonctionnalité utilise l'enrichissement des métadonnées de fichiers à partir de VirusTotal.
Données requises par l'analyse des risques pour la catégorie UEBA
Cette section détaille 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 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).
Pour WINEVTLOG, vous devez configurer votre configuration de collecte de données afin d'inclure les Event IDs Windows suivants dans le journal des événements Security Channel.
Ces événements correspondent directement aux Event types (par exemple, USER_LOGIN ou PROCESS_LAUNCH) utilisés par le moteur de détection.
Exigences concernant les 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 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
Chaque ensemble de règles de ce groupe utilise 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).
Dépendances des champs
Cette section décrit les métriques et les champs de dimension utilisés par les règles Google SecOps UEBA.
Dépendances des métriques
Le tableau suivant liste les métriques et les requêtes de recherche UDM correspondantes qui définissent les événements contribuant à chaque métrique.
| Métrique | Requête de recherche UDM pour les événements contribuant à la métrique |
|---|---|
AUTH_ATTEMPTS_FAIL |
metadata.event_type = "USER_LOGIN" |
AUTH_ATTEMPTS_SUCCESS |
metadata.event_type = "USER_LOGIN" |
AUTH_ATTEMPTS_TOTAL |
metadata.event_type = "USER_LOGIN" |
DNS_BYTES_OUTBOUND |
network.sent_bytes > 0 |
DNS_QUERIES_FAIL |
network.dns.id > 0 |
DNS_QUERIES_SUCCESS |
network.dns.id > 0 |
DNS_QUERIES_TOTAL |
network.dns.id > 0 |
FILE_EXECUTIONS_FAIL |
metadata.event_type = "PROCESS_LAUNCH" |
FILE_EXECUTIONS_SUCCESS |
metadata.event_type = "PROCESS_LAUNCH" |
FILE_EXECUTIONS_TOTAL |
metadata.event_type = "PROCESS_LAUNCH" |
HTTP_QUERIES_FAIL |
network.http.method != "" |
HTTP_QUERIES_SUCCESS |
network.http.method != "" |
HTTP_QUERIES_TOTAL |
network.http.method != "" |
NETWORK_BYTES_INBOUND |
network.received_bytes > 0 |
NETWORK_BYTES_OUTBOUND |
network.sent_bytes > 0 |
NETWORK_BYTES_TOTAL |
(network.received_bytes > 0 AND network.received_bytes < 1000000000000000) |
NETWORK_FLOWS_INBOUND |
network.received_bytes > 0 |
NETWORK_FLOWS_OUTBOUND |
network.sent_bytes > 0 |
NETWORK_FLOWS_TOTAL |
(network.received_bytes > 0 AND network.received_bytes < 1000000000000000) |
RESOURCE_READ_FAIL |
(metadata.event_type = "FILE_OPEN" OR metadata.event_type = "RESOURCE_READ") |
RESOURCE_READ_SUCCESS |
(metadata.event_type = "FILE_OPEN" OR metadata.event_type = "RESOURCE_READ") |
RESOURCE_READ_TOTAL |
(metadata.event_type = "FILE_OPEN" OR metadata.event_type = "RESOURCE_READ") |
RESOURCE_WRITTEN_FAIL |
(metadata.event_type = "FILE_CREATION" OR metadata.event_type = "RESOURCE_CREATION") |
RESOURCE_WRITTEN_SUCCESS |
(metadata.event_type = "FILE_CREATION" OR metadata.event_type = "RESOURCE_CREATION") |
RESOURCE_WRITTEN_TOTAL |
(metadata.event_type = "FILE_CREATION" OR metadata.event_type = "RESOURCE_CREATION") |
Dépendances des dimensions
Le tableau suivant liste les dimensions et les options de champ UDM correspondantes disponibles pour le filtrage ou le regroupement.
| Dimension | Options de champ |
|---|---|
| Appareil principal | principal.asset.asset_idprincipal.asset.hostnameprincipal.asset.ipprincipal.asset.macprincipal.asset.product_object_id |
| Appareil cible | target.asset.asset_idtarget.asset.hostnametarget.asset.iptarget.asset.mactarget.asset.product_object_id |
| Utilisateur principal | principal.user.email_addressesprincipal.user.employee_idprincipal.user.product_object_idprincipal.user.useridprincipal.user.windows_sid |
| Utilisateur cible | target.user.email_addressestarget.user.employee_idtarget.user.product_object_idtarget.user.useridtarget.user.windows_sid |
| Service cible | target.application |
| Adresse IP cible | target.ip |
| Chemin d'accès au fichier du processus principal | principal.process.file.full_path |
| Hachage du fichier de processus principal | principal.process.file.sha256 |
| Hachage du fichier principal | principal.file.sha256 |
| Pays principal | principal.ip_geo_artifact.location.country_or_region |
| Catégorie de sécurité | security_result.category |
| Nom de l'organisation du réseau principal | principal.ip_geo_artifact.network.organization_name |
| Nom de l'organisation du réseau cible | target.ip_geo_artifact.network.organization_name |
| Hachage du certificat client | network.tls.client.certificate.sha256 |
| Type de requête DNS | network.dns.questions.type |
| Domaine DNS | network.dns_domain |
| User-agent HTTP | network.http.user_agent |
| Type d'événement | metadata.event_type |
| Système d'exploitation | principal.platform |
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 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 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 déduplication automatique à 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 renvoie 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 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
}
Étapes suivantes
Vous avez encore besoin d'aide ? Obtenez des réponses de membres de la communauté et de professionnels Google SecOps.