Control del retraso de ingesta en las reglas de análisis

Aunque Microsoft Sentinel puede ingerir datos de fuentes de datos conectadas, el tiempo de ingestión para cada fuente puede variar según las circunstancias.

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, podría escribir una regla de detección personalizada y configurar los campos Ejecutar consulta cada y Buscar datos de los últimos para que la regla se ejecute cada cinco minutos y consulte los datos de esos últimos cinco minutos:

Los datos consultados desde el último campo definen una configuración conocida como período retrospectivo. 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 la ventana de búsqueda.

Ahora, suponga que hay algún retraso en el origen de datos. En este ejemplo, supongamos que el evento fue ingerido dos minutos después de ser generado. El retraso es de dos minutos:

El evento se genera dentro del primer período de ventana de búsqueda, 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

Use el siguiente enfoque para tener en cuenta el retraso de ingesta en las reglas de análisis programadas.

Para solucionar el problema, necesita conocer el retraso correspondiente a su 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:

• Aumenta el periodo de retroceso: La intuición básica te dice que aumentar el tamaño del periodo de retroceso 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 la ventana de búsqueda incluye ahora el evento que falta:

  

• * Duplicación de manejos: 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:

  

  Como el valor TimeGenerated del evento se encuentra en ambos periodos de retroceso, el evento lanza dos alertas. Debe encontrar una manera de resolver la duplicación.

• Asocia el evento a un periodo de revisión específico: En el primer ejemplo, perdiste eventos porque tus datos no fueron ingeridos cuando se ejecutó la consulta programada. Ha ampliado la ventana de búsqueda para incluir el evento, pero esto ha provocado la duplicación. Tiene que asociar el evento a la ventana que amplió para incluirlo.

  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, para el primer ejemplo, el segundo período de la ventana de búsqueda 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)

Consulta más información sobre los siguientes elementos utilizados en el ejemplo anterior en la documentación de Kusto:

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

Calcular el retraso de ingesta

Por defecto, las reglas de alertas programadas de Microsoft Sentinel están configuradas para tener un periodo de revisión de cinco minutos. Sin embargo, cada fuente de datos puede tener su propio retraso individual en la ingestión. Al combinar varios tipos de datos, debe comprender los diferentes retrasos de cada tipo de datos para configurar correctamente el período de retrospección.

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:

Contenido relacionado

• Crea una regla de análisis programado desde cero
• Personalización de los detalles de la alerta en Microsoft Sentinel
• Gestiona las versiones de las plantillas para tus reglas de análisis programadas en Microsoft Sentinel
• Supervisión del estado de los conectores de datos
• Tiempo de ingesta de datos de registro en Azure Monitor