Controlar el retraso de ingesta en las reglas de análisis programadas

Importante

Las detecciones personalizadas ahora son la mejor manera de crear nuevas reglas en Microsoft Sentinel Microsoft Defender XDR SIEM. Con las detecciones personalizadas, puede reducir los costos de ingesta, obtener detecciones ilimitadas en tiempo real y beneficiarse de una integración sin problemas con Defender XDR datos, funciones y acciones de corrección con la asignación automática de entidades. Para obtener más información, lea este blog.

Aunque Microsoft Sentinel pueden ingerir datos de varios orígenes, el tiempo de ingesta de cada origen de datos puede diferir en circunstancias diferentes.

En este artículo se describe cómo el retraso de ingesta podría afectar a las reglas de análisis programadas y cómo puede corregirlas para cubrir estas brechas.

¿Por qué el retraso es significativo?

Por ejemplo, puede escribir una regla de detección personalizada, establecer la consulta Ejecutar cada y Buscar datos de los últimos campos para que la regla se ejecute cada cinco minutos y buscar datos de esos últimos cinco minutos:

Los datos de búsqueda del último campo definen una configuración conocida como período de retención . Lo ideal es que, cuando no haya ningún retraso, esta detección no pierda ningún evento, como se muestra en el diagrama siguiente:

El evento llega a medida que se genera y se incluye en el período de devolución de la vista .

Ahora, suponga que hay algún retraso en el origen de datos. En este ejemplo, supongamos que el evento se ingerió dos minutos después de que se generara. El retraso es de dos minutos:

El evento se genera en el primer período de espera, pero no se ingiere en el área de trabajo de Microsoft Sentinel en la primera ejecución. La próxima vez que se ejecute la consulta programada, ingiere el evento, pero el filtro generado por el tiempo quita el evento porque ocurrió hace más de cinco minutos. En este caso, la regla no desencadena una alerta.

Cómo controlar el retraso

Nota:

Puede resolver el problema mediante el proceso descrito a continuación o implementar las reglas de detección casi en tiempo real (NRT) de Microsoft Sentinel. Para obtener más información, consulte Detectar amenazas rápidamente con reglas de análisis casi en tiempo real (NRT) en Microsoft Sentinel.

Para solucionar el problema, debe conocer el retraso del tipo de datos. En este ejemplo, ya sabe que el retraso es de dos minutos.

Para sus propios datos, puede comprender el retraso mediante la función Kusto ingestion_time() y calcular la diferencia entre TimeGenerated y el tiempo de ingesta. Para obtener más información, vea Calcular el retraso de ingesta.

Después de determinar el retraso, puede solucionar el problema de la siguiente manera:

• Aumente el período de vista atrás. La intuición básica le indica que aumentar el tamaño del período de vista atrás le ayudará. Dado que el período de espera es de cinco minutos y el retraso es de dos minutos, establecer el período de retención en siete minutos ayudará a solucionar este problema. Por ejemplo, en la configuración de la regla:

  

  En el diagrama siguiente se muestra cómo el período de look-pack contiene ahora el evento perdido:

  

• Controlar la duplicación. Solo aumentar el período de vista atrás puede crear duplicación, ya que las ventanas de vista atrás ahora se superponen. Por ejemplo, un evento diferente puede ser similar al que se muestra en el diagrama siguiente:

  

  Dado que el valor timegenerated del evento se encuentra en ambos períodos de vista atrás, el evento desencadena dos alertas. Debe encontrar una manera de resolver la duplicación.

• Asocie el evento a un período de retención específico. En el primer ejemplo, se han perdido eventos porque los datos no se ingerieron cuando se ejecutó la consulta programada. Ha ampliado la vista atrás para incluir el evento, pero esto ha provocado la duplicación. Tiene que asociar el evento a la ventana que ha ampliado para contenerlo.

  Para ello, establezca ingestion_time() > ago(5m), en lugar de la regla look-back = 5moriginal . Esta configuración asocia el evento a la primera ventana de vista atrás. Por ejemplo:

  

  La restricción de tiempo de ingesta ahora recorta los dos minutos adicionales que agregó al período de espera. Y en el primer ejemplo, el segundo período de vista atrás de ejecución captura ahora el evento:

  

En la consulta de ejemplo siguiente se resume la solución para resolver problemas de retraso de ingesta:

let ingestion_delay = 2min;
let rule_look_back = 5min;
CommonSecurityLog
| where TimeGenerated >= ago(ingestion_delay + rule_look_back)
| where ingestion_time() > ago(rule_look_back)

Vea más información sobre los siguientes elementos usados en el ejemplo anterior, en la documentación de Kusto:

• let (instrucción)
• where (operador)
• ago() (función)

Calcular el retraso de ingesta

De forma predeterminada, Microsoft Sentinel reglas de alerta programadas están configuradas para tener un período de retención de 5 minutos. Sin embargo, cada origen de datos puede tener su propio retraso de ingesta individual. Al combinar varios tipos de datos, debe comprender los diferentes retrasos de cada tipo de datos para configurar el período de retención correctamente.

El informe de uso del área de trabajo, que se proporciona en Microsoft Sentinel de serie, incluye un panel que muestra la latencia y los retrasos de los distintos tipos de datos que fluyen al área de trabajo.

Por ejemplo:

Siguientes pasos

Para más información, vea:

• Creación de reglas de análisis personalizadas para detectar amenazas
• Personalización de los detalles de alerta en Azure Sentinel
• Administración de versiones de plantilla para las reglas de análisis programadas en Azure Sentinel
• Uso del libro de supervisión de estado
• Tiempo de ingesta de datos de registro en Azure Monitor