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

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

En este artículo se describe cómo el retraso de ingesta puede afectar a las reglas de análisis programadas y cómo puede corregirlas para solucionar estos problemas.

Por qué el retraso es significativo

Por ejemplo, puede escribir una regla de detección personalizada, estableciendo las opciones Ejecutar consulta cada y Búsqueda de datos de los últimos para que la regla se ejecute cada cinco minutos, buscando datos de los últimos cinco minutos:

Captura de pantalla que muestra el Asistente para reglas de Analytics: ventana Crear nueva regla.

El campo Buscar datos de los últimos define una configuración conocida como ventana de búsqueda. Idealmente, cuando no hay ningún retraso, esta detección no pierde ningún evento, como se muestra en el diagrama siguiente:

Diagrama que muestra una ventana de cinco minutos atrás.

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 para el origen de datos. En este ejemplo, supongamos que el evento se ingirió dos minutos después de haberse generado. El retraso es de dos minutos:

Diagrama que muestra ventanas de cinco minutos atrás con un retraso 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 se produjo hace más de cinco minutos. En este caso, la regla no activa 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, vea Detección rápida de amenazas 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 reconocer el retraso mediante la funcióningestion_time() Kusto y calcular la diferencia entre el momento de generación, TimeGenerated, y el tiempo de ingesta. Para más información, consulte Cálculo del retraso en la ingesta.

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

  • Aumente el período de la ventana de búsqueda. La intuición básica le indica que aumentar el tamaño del período de la ventana de búsqueda será útil. Puesto que el período de la ventana de búsqueda es de cinco minutos y el retraso es de dos minutos, establecer el período de la ventana de búsqueda en siete minutos le ayudará a solucionar este problema. Por ejemplo, en la configuración de la regla:

    Captura de pantalla que muestra cómo establecer la ventana de búsqueda en siete minutos

    En el diagrama siguiente se muestra cómo la ventana de búsqueda incluye ahora el evento que falta:

    Diagrama que muestra ventanas de búsqueda de siete minutos con un retraso de dos minutos.

  • Controlar la duplicación. Solo aumentar el período de la ventana de búsqueda atrás puede crear duplicación, ya que las ventanas de búsqueda se superponen. Por ejemplo, un evento diferente puede tener el aspecto que se muestra en el diagrama siguiente:

    Diagrama que muestra cómo las ventanas de búsqueda superpuestas crean duplicación.

    Puesto que el valor TimeGenerated (hora de generación) del evento se encuentra en ambas ventanas de búsqueda, el evento activa dos alertas. Debe encontrar una manera de resolver la duplicación.

  • Asocie el evento a una ventana de búsqueda específica. En el primer ejemplo, perdió eventos porque los datos no se ingirieron 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 original look-back = 5m. Esta configuración asocia el evento a la primera ventana de búsqueda. Por ejemplo:

    Diagrama que muestra cómo establecer la restricción «ago» (hace) evita la duplicación.

    La restricción de tiempo de ingesta ahora recorta los dos minutos adicionales que agregó al período de la ventana de búsqueda. Y, para el primer ejemplo, el segundo período de la ventana de búsqueda de ejecución captura ahora el evento:

    Diagrama que muestra cómo establecer la restricción «ago» (hace) captura el evento.

En la consulta de ejemplo siguiente se resume la solución para resolver problemas de retraso en la 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)

Cálculo del retraso en la ingesta

Por defecto, las reglas de alertas programadas de Microsoft Sentinel están configuradas para tener un período de 5 minutos de ventana de búsqueda. Sin embargo, cada origen de datos puede tener su propio retraso individual de ingesta. Al unir varios tipos de datos, debe reconocer los distintos retrasos de cada tipo de datos para configurar correctamente el período de la ventana de búsqueda.

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

Por ejemplo:

Captura de pantalla del informe de uso del área de trabajo que muestra la latencia de un extremo a otro por tabla

Pasos siguientes

Para más información, consulte: