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:

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:

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:

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:

  

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

  

• 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:

  

  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:

  

  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:

  

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:

Pasos siguientes

Para más información, consulte:

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