Análisis de riesgos para UEBA

Compatible con:

En este documento, se proporciona una descripción general de los conjuntos de reglas en la categoría Análisis de riesgos para UEBA, los datos necesarios y la configuración que puedes usar para ajustar las alertas que genera cada conjunto de reglas. Estos conjuntos de reglas ayudan a identificar amenazas mediante la evaluación de las fuentes de registros admitidas.

Descripciones de los conjuntos de reglas

Los siguientes conjuntos de reglas están disponibles en la categoría Análisis de riesgos para UEBA y se agrupan según el tipo de patrones detectados:

Autenticación

  • New Login by User to Device: Un usuario se conectó a un dispositivo nuevo.
  • Anomalous Authentication Events by User: Una sola entidad de usuario tuvo eventos de autenticación anómalos recientemente, en comparación con el uso histórico.
  • Failed Authentications by Device: Una entidad de un solo dispositivo tuvo muchos intentos de acceso fallidos recientemente, en comparación con el uso histórico.
  • Failed Authentications by User: Una entidad de un solo usuario tuvo muchos intentos de acceso fallidos recientemente, en comparación con el uso histórico.

Análisis del tráfico de red

  • Anomalous Inbound Bytes by Device: Una cantidad significativa de datos subidos recientemente a una sola entidad de dispositivo, en comparación con el uso histórico.
  • Bytes de salida anómalos por dispositivo: cantidad significativa de datos descargados recientemente de una sola entidad de dispositivo, en comparación con el uso histórico.
  • Anomalous Total Bytes by Device: Una entidad de dispositivo subió recientemente y descargó una cantidad significativa de datos, en comparación con el uso histórico.
  • Bytes de entrada anómalos por usuario: una entidad de un solo usuario descargó recientemente una cantidad significativa de datos, en comparación con el uso histórico.
  • Anomalous Total Bytes by User: Una entidad de usuario subió y descargó recientemente una cantidad significativa de datos, en comparación con el uso histórico.
  • Brute Force then Successful Login by User: Una entidad de un solo usuario de una dirección IP tuvo varios intentos de autenticación fallidos en una aplicación determinada antes de acceder correctamente.

Detecciones basadas en grupos de pares

  • Anomalous or Excessive Logins for a Newly Created User: Actividad de autenticación anómala o excesiva para un usuario creado recientemente. Esto usa el tiempo de creación de los datos de contexto de AD.

  • Anomalous or Excessive Suspicious Actions for a Newly Created User: Actividad anómala o excesiva (incluida, entre otras, la telemetría HTTP, la ejecución de procesos y la modificación de grupos) para un usuario creado recientemente. Esto usa el tiempo de creación de los datos de contexto de AD.

Acciones sospechosas

  • Creación excesiva de cuentas por dispositivo: una entidad de dispositivo creó varias cuentas de usuario nuevas.
  • Excessive Alerts by User: Se informó una gran cantidad de alertas de seguridad de un antivirus o un dispositivo de extremo (por ejemplo, se bloqueó la conexión o se detectó software malicioso) sobre una entidad de usuario, que fue mucho mayor que los patrones históricos. Estos son eventos en los que el campo UDM security_result.action se establece en BLOCK.

Detecciones basadas en la prevención de pérdida de datos

  • Anomalous or Excessive Processes with Data Exfiltration Capabilities: Actividad anómala o excesiva para procesos asociados con capacidades de robo de datos como registradores de teclas, capturas de pantalla y acceso remoto. Esto usa el enriquecimiento de metadatos de archivos de VirusTotal.

Datos necesarios para la categoría Análisis de riesgos para UEBA

En esta sección, se detallan los datos que requiere cada categoría de conjunto de reglas para un rendimiento óptimo. Si bien las detecciones de UEBA están diseñadas para funcionar con todos los analizadores predeterminados admitidos, el uso de los siguientes tipos de datos específicos maximiza sus beneficios. Para obtener una lista completa de los analizadores predeterminados admitidos, consulta Tipos de registros y analizadores predeterminados admitidos.

Autenticación

Para usar cualquiera de estos conjuntos de reglas, recopila datos de registro de Azure AD Directory Audit (AZURE_AD_AUDIT) o Windows Event (WINEVTLOG).

Para WINEVTLOG, debes configurar la configuración de recopilación de datos para incluir los siguientes Event IDs de Windows en el Channel del registro de eventos Security. Estos eventos se asignan directamente a los Event types (por ejemplo, USER_LOGIN o PROCESS_LAUNCH) que usa el motor de detección.

Requisitos de ID de evento de Windows

Tipo de evento ID de evento de 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

Análisis del tráfico de red

Para usar cualquiera de estos conjuntos de reglas, recopila datos de registro que capturen la actividad de la red. Por ejemplo, de dispositivos como FortiGate (FORTINET_FIREWALL), Check Point (CHECKPOINT_FIREWALL), Zscaler (ZSCALER_WEBPROXY), CrowdStrike Falcon (CS_EDR) o Carbon Black (CB_EDR).

Detecciones basadas en grupos de pares

Para usar cualquiera de estos conjuntos de reglas, recopila datos de registro de Azure AD Directory Audit (AZURE_AD_AUDIT) o Windows Event (WINEVTLOG).

Acciones sospechosas

Los conjuntos de reglas de este grupo usan un tipo de datos diferente.

Conjunto de reglas Excessive Account Creation by Device

Para usar este conjunto de reglas, recopila datos de registro de Azure AD Directory Audit (AZURE_AD_AUDIT) o Windows Event (WINEVTLOG).

Conjunto de reglas Excessive Alerts by User

Para usar este conjunto de reglas, recopila datos de registro que capturen actividades de extremos o datos de auditoría, como los que registran CrowdStrike Falcon (CS_EDR), Carbon Black (CB_EDR) o Azure AD Directory Audit (AZURE_AD_AUDIT).

Detecciones basadas en la prevención de pérdida de datos

Para usar cualquiera de estos conjuntos de reglas, recopila datos de registro que capturen actividades de procesos y archivos, como los que registran CrowdStrike Falcon (CS_EDR), Carbon Black (CB_EDR) o SentinelOne EDR (SENTINEL_EDR).

Los conjuntos de reglas de esta categoría dependen de eventos con los siguientes valores de metadata.event_type: PROCESS_LAUNCH, PROCESS_OPEN, PROCESS_MODULE_LOAD.

Ajusta las alertas que muestran los conjuntos de reglas de esta categoría

Puedes reducir la cantidad de detecciones que genera una regla o un conjunto de reglas mediante las exclusiones de reglas.

Una exclusión de regla define los criterios que se usan para excluir un evento de la evaluación del conjunto de reglas o de reglas específicas del conjunto de reglas. Crea una o más exclusiones de reglas para ayudar a reducir el volumen de detecciones. Consulta Configura exclusiones de reglas para obtener información sobre cómo hacerlo.

Ejemplo de una regla para la categoría Análisis de riesgos para UEBA

En el siguiente ejemplo, se muestra cómo crear una regla para generar detecciones en cualquier nombre de host de entidad cuyo puntaje de riesgo sea superior a 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
}

Esta regla de ejemplo también realiza una deduplicación automática con la sección de coincidencias. Si una detección de regla puede activarse, pero el nombre de host y el puntaje de riesgo permanecen sin cambios en un período de 4 horas, no se crearán detecciones nuevas.

Los únicos períodos de riesgo posibles para las reglas de puntaje de riesgo de entidad son 24 horas o 7 días (86,400 o 604,800 segundos, respectivamente). Si no incluyes el tamaño del período de riesgo en la regla, esta mostrará resultados inexactos.

Los datos del puntaje de riesgo de la entidad se almacenan por separado de los datos de contexto de la entidad. Para usar ambos en una regla, esta debe tener dos eventos de entidad separados, uno para el contexto de la entidad y otro para el puntaje de riesgo de la entidad, como se muestra en el siguiente ejemplo:

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
}

¿Qué sigue?

¿Necesitas más ayuda? Obtén respuestas de miembros de la comunidad y profesionales de Google SecOps.