Detecciones compuestas
En este documento, se presentan las detecciones compuestas y cómo pueden mejorar los flujos de trabajo de detección de amenazas mediante la correlación de resultados de varias reglas.
Las detecciones compuestas se generan a partir de reglas que usan detecciones de otras reglas como entrada, combinadas con eventos, métricas o indicadores de riesgo de entidades. Luego, estas reglas se combinan con eventos, métricas o indicadores de riesgo de entidades para detectar amenazas complejas de varias etapas que las reglas individuales pueden pasar por alto.
Las detecciones compuestas ayudan a analizar eventos a través de interacciones y activadores de reglas definidos. Esto mejora la precisión, reduce los falsos positivos y proporciona una vista integral de las amenazas de seguridad mediante la correlación de datos de diferentes fuentes y etapas de ataque.
Los siguientes conceptos definen los componentes básicos de las reglas compuestas y aclaran cómo funcionan en los flujos de trabajo de detección:
Reglas compuestas: Usan detecciones o alertas (o ambas) como entrada. De manera opcional, puedes enriquecerlas con eventos, métricas y una amplia variedad de datos contextuales del gráfico de entidades, como datos de prevalencia, inteligencia contra amenazas o una puntuación de riesgo de entidad. Estas reglas siempre deben tener una sección de coincidencias y pueden hacer referencia a metacampos, variables
matchy variablesoutcomede las reglas de entrada.Detección: Es el resultado que se genera cuando se cumplen las condiciones de una regla.
Reglas de solo detección: Son reglas compuestas que usan solo detecciones o alertas como entradas.
Cuándo usar detecciones compuestas
Las detecciones compuestas pueden ser útiles para lograr los siguientes objetivos:
Correlacionar los resultados de dos o más reglas (por ejemplo, vincular una detección de descarga de software malicioso con una alerta posterior de C2 Beaconing del mismo host)
Enriquecer las alertas con datos de eventos relacionados
Reducir la fatiga que generan las alertas activando solo una alerta final cuando una detección ruidosa y de baja confianza ocurre varias veces o en combinación con otra actividad sospechosa
Crear una alerta para un ataque complejo de varias etapas en el que cada etapa ya se identifica con su propia regla
Beneficios de las detecciones compuestas
Las detecciones compuestas tienen los siguientes beneficios:
Desenmascarar ataques de varias etapas: Los ataques cibernéticos suelen ser multifacéticos y estar interconectados. La detección compuesta revela la narrativa de ataque más amplia vinculando eventos de seguridad aparentemente aislados. Por ejemplo, las detecciones compuestas pueden identificar la secuencia completa de un ataque, como una vulneración inicial seguida de una elevación de privilegios y un robo de datos.
Reducir la fatiga que generan las alertas: Las reglas compuestas consolidan y filtran las alertas ruidosas, lo que permite una respuesta más enfocada. Este enfoque ayuda a priorizar los incidentes de alto impacto y reducir la fatiga general que generan las alertas.
Mejorar la precisión de la detección: Combina observaciones de eventos del Modelo de datos unificado (UDM), detecciones de reglas, contexto de entidades, hallazgos de User and Entity Behavior Analytics (UEBA) y tablas de datos para crear una lógica de detección más precisa.
Optimizar la lógica compleja: Divide las situaciones de detección complejas en reglas administrables, interconectadas y reutilizables para simplificar el desarrollo y el mantenimiento.
Usar en paneles: Integra sin problemas las detecciones compuestas como fuentes de datos para los paneles de Google SecOps. Puedes usarlas para crear visualizaciones que resuman patrones de ataque de varias etapas, lo que facilita la comprensión de los riesgos complejos.
Casos de uso habituales
En esta sección, se enumeran algunos casos de uso habituales de las detecciones compuestas.
Enriquece las detecciones con contexto de eventos sin procesar
Este caso de uso implica vincular una alerta de alto nivel de un sistema con registros de eventos de otro sistema.
Objetivo: Identificar la acción local específica que causó una alerta de alto nivel
Ejemplo:
Se activa una alerta en Google Cloud Event Threat Detection porque una carga de trabajo realizó una llamada DNS a un dominio malicioso. Esta es la detección.
Esta detección activa una regla compuesta.
Luego, la regla busca registros sin procesar de Endpoint Detection and Response (EDR) (los eventos) de la misma carga de trabajo en un período de un minuto, en busca de operaciones de línea de comandos que contengan el mismo dominio malicioso.
La alerta final proporciona un contexto enriquecido: muestra que se contactó un dominio malicioso y el comando
sshespecífico que se usó. Esta información hace que el resultado sea mucho más útil que la detección original.
Haz un seguimiento de la actividad del usuario después del acceso
Un caso de uso principal se enfoca en vincular el evento de acceso de un usuario con actividades sospechosas posteriores. Si bien una regla estándar de varios eventos puede hacer un seguimiento de una secuencia corta, una detección compuesta es mejor para crear un perfil de riesgo integral de toda la sesión de un usuario.
Objetivo: Correlacionar un solo evento, como un acceso de alto riesgo, con una amplia variedad de actividades posteriores de "indicador débil" durante un período más largo, como un día completo
Ejemplo: Crea varias reglas que produzcan detecciones de nivel inferior. Luego, usa una regla compuesta con un período de coincidencia largo (por ejemplo, 24 horas) para activar un acceso sospechoso inicial y correlacionarlo con cualquiera de las siguientes detecciones del mismo usuario:
Un usuario que borra su historial de línea de comandos
La creación de una nueva cuenta de administrador local
Una carga de datos grande a un sitio personal de Cloud Storage
Combina con métricas de UEBA
Este caso de uso aprovecha las métricas de UEBA existentes como punto de partida para una detección compuesta para encontrar un comportamiento más complejo y a largo plazo.
Objetivo: Correlacionar un aumento en una métrica de UEBA con otra actividad anómala
Ejemplo:
Una regla de UEBA detecta una cantidad excesiva de errores de acceso para un usuario.
Otra regla de UEBA detecta una gran cantidad de bytes de salida del mismo usuario.
Una detección compuesta vincula estos dos resultados de UEBA separados durante un período de días para identificar una posible vulneración de la cuenta seguida de un robo de datos.
Detecta intentos de robo de datos
Esto implica correlacionar varias acciones distintas del usuario que, cuando se combinan, pueden indicar un intento de robo de datos.
Objetivo: Crear un perfil de manejo de datos riesgosos por parte de un solo usuario en varios dispositivos y acciones
Acciones correlacionadas:
Acceder desde varios dispositivos (por ejemplo, la computadora de la casa y la del trabajo)
Acceder a más fuentes de datos de lo habitual
Descargar, imprimir y enviar datos por correo electrónico de forma simultánea
Contar cuántos documentos clasificados toca un usuario dentro de un período
Haber presentado una carta de renuncia
Detecta software malicioso de varias etapas
Este caso de uso implica identificar software malicioso que opera lentamente durante un período prolongado, lo que es difícil de detectar con reglas únicas que tienen períodos de coincidencia cortos.
Objetivo: Vincular el vector de infección inicial con acciones maliciosas posteriores, incluso si están separadas por horas o días
Ejemplo:
Un usuario visita un sitio web malicioso (evento de red inicial).
Se descarga y ejecuta un "archivo dropper" (primer evento de proceso).
Mucho más tarde, el archivo dropper descarga y ejecuta otro archivo ejecutable (segundo evento de proceso).
Esto requiere un período
matchlargo para conectar los procesos superiores y secundarios, que las detecciones compuestas pueden proporcionar.
Reduce el ruido de las alertas
Este caso de uso implica administrar detecciones que son demasiado "ruidosas" o producen demasiados falsos positivos por sí solas.
Objetivo: Refinar una regla ruidosa sin desactivarla ni crear exclusiones complejas
Ejemplo:
Configura una detección seleccionada ruidosa como "solo detectar" para que ya no genere alertas.
Crea una detección compuesta que use el resultado de esa regla seleccionada como su primera condición.
Agrega una segunda condición para proporcionar una calificación adicional, como "alertar solo si esta detección ocurre 5 veces para el mismo usuario en una hora" o si se combina con una detección de una regla diferente.
Cómo funcionan las detecciones compuestas
Cuando las reglas cumplen con las condiciones predefinidas, generan detecciones. De manera opcional, estas detecciones pueden incluir variables de resultado, que capturan datos específicos o estados de eventos.
Las reglas compuestas usan estas detecciones de otras reglas como parte de sus entradas. La evaluación puede basarse en la información de la sección de metadatos, las variables de resultado y las variables de coincidencia de la regla original.
Según esta evaluación, puedes usar reglas compuestas para crear nuevas detecciones que se usarán como representación intermedia para la investigación y alertas con una regla posterior. Esto ayuda a correlacionar varios factores de diferentes detecciones para identificar amenazas complejas.
Para obtener más información sobre la sintaxis y los ejemplos, consulta Reglas de detección compuestas y Ejemplos.
Define tu estrategia
Antes de comenzar a crear reglas compuestas, planifica tu estrategia para asegurarte de que tus reglas nuevas sean eficaces, eficientes y resuelvan los problemas correctos.
Evalúa tu estrategia de detección actual. Revisa tus reglas existentes para identificar aquellas que son demasiado ruidosas, generan una gran cantidad de falsos positivos o son demasiado complejas y difíciles de administrar.
Determina las situaciones específicas en las que las reglas compuestas pueden proporcionar valor. Esto incluye detectar ataques de varias etapas, correlacionar varias alertas de baja confianza en una sola alerta de alta confianza o enriquecer las detecciones con contexto adicional de otras fuentes de datos.
Según tu evaluación, crea un plan de implementación. Decide qué reglas ruidosas debes refinar, qué reglas complejas debes simplificar y qué nuevas detecciones de varias etapas debes priorizar.
Este plan definido proporciona una hoja de ruta para crear reglas compuestas específicas y eficaces. Considera las siguientes estrategias de alto nivel para obtener el máximo valor de las detecciones compuestas mientras administras las restricciones técnicas.
Selecciona el método adecuado
Antes de crear una detección compuesta, si puedes lograr el resultado requerido con otras alternativas. Analiza si puedes identificar un patrón complejo con una detección de UEBA existente. Si una detección es demasiado compleja, podría aumentar la sobrecarga de mantenimiento y consumir la cuota de reglas.
Usa una detección compuesta cuando: Tu objetivo es correlacionar los resultados finales de dos o más reglas diferentes preexistentes. Esto conecta etapas conceptualmente separadas de un ataque.
Ejemplo: Correlacionar una detección de una regla de descarga de software malicioso con una detección posterior de una regla de C2 Beaconing Detected.
Usa una detección de UEBA existente cuando: Quieres saber cuándo un usuario o dispositivo rompe su patrón de actividad normal.
Ejemplo: Detectar automáticamente que un usuario descargó 100 GB de datos hoy cuando normalmente solo descarga 1 GB.
Administra las cuotas de reglas y las puntuaciones de riesgo
Para administrar los recursos de tu organización, comprende cómo los diferentes tipos de reglas afectan tu cuota de reglas.
Las reglas seleccionadas no se deducen de tu cuota de reglas personalizadas.
Las reglas compuestas y las reglas personalizadas de varios eventos se deducen de tu cuota.
Puedes usar una detección seleccionada configurándola como solo detección. Esto permite que la regla seleccionada realice la detección inicial amplia sin producir alertas. Luego, puedes usar una regla compuesta para aplicar una lógica específica a estos resultados, lo que proporciona más valor mientras administras estratégicamente tu cuota.
Comprende la diferencia entre riesgo y contexto
Cuando diseñes la lógica de detección, distingue entre las reglas que evalúan el riesgo y las reglas que proporcionan contexto.
El riesgo es la evaluación de qué tan peligroso es un conjunto de actividades. Una regla diseñada para el riesgo suele agregar varios eventos o detecciones contextuales para emitir un juicio. Por ejemplo, si bien un solo acceso fallido proporciona contexto, una gran cantidad de ellos indica el riesgo de un ataque de fuerza bruta.
El contexto se refiere a los detalles fácticos que rodean un evento. Una regla diseñada para el contexto enriquece un evento con detalles de otro. Por ejemplo, si bien una regla puede detectar un acceso exitoso del usuario, una regla contextual proporciona el contexto crucial de que este acceso provino de un país nuevo e inusual.
Ejemplo: Una detección inicial puede alertarte sobre un riesgo potencial, como una llamada DNS a un dominio malicioso. Luego, una regla compuesta correlaciona esa alerta con los registros de eventos en Google SecOps para encontrar el proceso específico de la línea de comandos que inició la llamada. Esto enriquece la alerta de riesgo de alto nivel con un contexto crítico y útil.
Usa períodos de coincidencia largos de forma estratégica
Las reglas compuestas configuradas con períodos de coincidencia largos (por ejemplo, 14 días) se ejecutan con menos frecuencia. Su alta latencia puede hacer que no sean adecuadas para alertas sensibles al tiempo. Considera usar estos períodos de larga duración para detectar actividad adversaria lenta y persistente durante períodos prolongados.
Usa detecciones para la visualización
Una estrategia para administrar reglas ruidosas es convertir su resultado en una visualización en un panel. Este enfoque no consume cuota de reglas y puede convertir datos de gran volumen y baja fidelidad en estadísticas valiosas.
Si configuras una regla para que solo detecte y, luego, trazas sus detecciones en un widget del panel, puedes hacer un seguimiento de las tendencias, identificar valores atípicos y obtener una vista de auditoría de alto nivel de la actividad sin que te abrumen las alertas individuales.
Ejemplo: Haz un seguimiento del manejo de datos de PII
Una regla hace un seguimiento de cada vez que un usuario maneja datos de PII sensibles.
En lugar de alertar cada vez, se configura para que solo detecte. Luego, un widget del panel muestra qué usuarios se acercan a un límite de salida diario (por ejemplo, 10,000 bytes). Esto proporciona una vista de auditoría rápida del comportamiento de riesgo sin generar alertas constantes.
Ejemplo: Supervisa riesgos específicos de DLP:
Un widget agrega las puntuaciones de riesgo de un subconjunto muy específico de reglas de DLP. Esto permite que un equipo específico (por ejemplo, los administradores de Prevención de pérdida de datos [DLP]) supervisen solo los riesgos que son relevantes, filtrando el ruido de otros dominios de seguridad.
Crea detecciones compuestas
En el siguiente flujo de trabajo, se describe el recorrido típico para crear una regla compuesta. Para obtener más información sobre la sintaxis y los ejemplos, consulta Reglas de detección compuestas y Ejemplos.
Define la situación de amenaza: Define la amenaza específica que deseas detectar.
Crea o identifica las reglas de entrada: Para cada etapa de la situación de amenaza, crea o identifica una regla de entrada que detecte la actividad específica.
Define las condiciones de unión: Determina la información común que vincula las detecciones de tus reglas de entrada, como etiquetas de reglas, variables o campos de detección.
Crea la regla compuesta: Escribe la regla que ingiere las detecciones de las reglas de entrada.
Define la sección
eventsy haz referencia a las reglas de entrada por su nombre, ID o una etiqueta de metadatos compartida.Define la sección
matchpara especificar la clave de unión y el período para la coincidencia.Define la sección
conditionpara establecer la condición que se debe cumplir para que se active la alerta final.
Prueba e implementa la cadena de reglas: Te recomendamos que ejecutes manualmente una búsqueda retroactiva para cada regla de la secuencia.
Cuando usas la función Probar regla en una regla compuesta, solo se ejecuta en detecciones preexistentes que coinciden con los criterios de entrada de la regla. No ejecuta automáticamente las reglas subyacentes para generar entradas nuevas para la prueba, lo que significa que no puedes validar una cadena de reglas completa en una sola acción.
Para ejecutar una búsqueda retroactiva para la secuencia de reglas, haz lo siguiente:
Inicia manualmente una búsqueda retroactiva desde la primera regla de la secuencia.
Espera a que se complete.
Continúa con la siguiente regla.
Ejemplo:
rule CheckCuratedDetection_with_EDR_and_EG {
meta:
author = "noone@cymbal.com"
events:
$d.detection.detection.rule_name = /SCC: Custom Modules: Configurable Bad Domain/
$d.detection.collection_elements.references.event.network.dns.questions.name = $domain
$d.detection.collection_elements.references.event.principal.asset.hostname = $hostname
$e.metadata.log_type = "LIMACHARLIE_EDR"
$e.metadata.product_event_type = "NETWORK_CONNECTIONS"
$domain = re.capture($e.principal.process.command_line, "\\s([a-zA-Z0-9.-]+\\.[a-zA-Z0-9.-]+)$")
$hostname = re.capture($e.principal.hostname, "([^.]*)")
$prevalence.graph.metadata.entity_type = "DOMAIN_NAME"
$prevalence.graph.metadata.source_type = "DERIVED_CONTEXT"
$prevalence.graph.entity.hostname = $domain
$prevalence.graph.entity.domain.prevalence.day_count = 10
$prevalence.graph.entity.domain.prevalence.rolling_max <= 5
$prevalence.graph.entity.domain.prevalence.rolling_max > 0
match:
$hostname over 1h
outcome:
$risk_score = 80
$CL_target = array($domain)
condition:
$e and $d and $prevalence
}
Visualiza los resultados de la detección compuesta
Puedes ver los resultados de la detección compuesta
en la página Detecciones. Una alerta es una detección compuesta cuando la columna Entradas muestra Detección como fuente y la columna Tipo de detección muestra una etiqueta Alerta con un número junto a ella (por ejemplo, Alert (3)).
Nota: Si tienes SIEM y SOAR, también puedes ver los resultados en la pestaña Casos.
Optimiza las detecciones compuestas
Recomendamos las siguientes prácticas para crear reglas compuestas.
Optimiza la latencia
Para obtener una latencia mínima en las canalizaciones de detección, usa reglas de un solo evento siempre que sea posible, como para el activador inicial. Las reglas compuestas pueden usar sus detecciones para realizar correlaciones más complejas con otros eventos, entidades o detecciones, lo que ayuda a reducir la latencia general.
Usa métodos eficientes para unir detecciones
Recomendamos usar variables de resultado, etiquetas de metadatos y variables de coincidencia para unir detecciones. Estos métodos proporcionan resultados más deterministas y confiables que el uso de muestras de eventos. Las etiquetas de metadatos son particularmente flexibles porque te permiten categorizar reglas para que una regla compuesta pueda segmentar cualquier detección con esa etiqueta.
Por ejemplo, si varias reglas comparten la misma etiqueta de metadatos
tactic: exfiltration, puedes tener una regla compuesta que segmente cualquier detección
en la que la etiqueta de táctica tenga el valor exfiltration.
Cuando usas nocase con variables de unión en detecciones compuestas, es posible que recibas el siguiente error de análisis semántico:
semantic analysis: match variable <variable_name> is not assigned to an event field.
En las detecciones compuestas, la primera asignación de variables (por ejemplo, $username = $fact1...)
define las propiedades de la variable, incluida la falta de distinción entre mayúsculas y minúsculas cuando se usa
nocase. El compilador interpreta la aplicación de nocase a las asignaciones de variables posteriores de la misma variable de unión (por ejemplo, $username = $fact2...) como una redefinición en conflicto o una restricción redundante, lo que genera el error semántico.
Mejora las detecciones con la biblioteca de funciones
Puedes usar la biblioteca de funciones de YARA-L en puntos estratégicos dentro de una regla compuesta para aumentar la señal y agregar una lógica más compleja.
Administra las actualizaciones de reglas
Cuando actualizas una regla que se usa en una o más reglas compuestas, el sistema crea automáticamente una versión nueva de la regla. Las reglas compuestas usan automáticamente la versión nueva. Te recomendamos que pruebes toda la secuencia de reglas actualizadas para verificar el comportamiento previsto.
Limitaciones
Cuando diseñes e implementes detecciones compuestas, ten en cuenta las siguientes limitaciones:
Disponibilidad de datos de casos de SOAR: Las detecciones compuestas no tienen acceso a todos los datos de casos de SOAR. No se admite la lógica de reglas que intenta filtrar o excluir casos según el estado (por ejemplo,
$edetection.feedback_summary.status != "CLOSED").Reglas compuestas: Google SecOps admite una profundidad máxima de 10 para las reglas compuestas. La profundidad es la cantidad de reglas desde una regla base hasta la regla compuesta final.
Reglas de solo detección: Tienen un período máximo de coincidencia de 14 días y están sujetas a un límite de detección diario de 10,000 detecciones por regla.
Variables de resultado: Cada regla está limitada a un máximo de 20 variables de resultado. Además, cada variable de resultado repetida está limitada a 25 valores.
Muestras de eventos: Solo se almacenan 10 muestras de eventos por variable de evento en una regla, como 10 para
$e1y 10 para$e2.
Para obtener más información sobre los límites de detección, consulta Límites de detección.
¿Qué sigue?
Para obtener información sobre cómo crear reglas de detección compuestas, consulta Reglas de detección compuestas y Ejemplos.
¿Necesitas más ayuda? Obtén respuestas de miembros de la comunidad y profesionales de Google SecOps.