Escribir reglas de detección

La lógica de una regla de detección es el SQL que define lo que busca. Esta página explica cómo funcionan las reglas, cómo elegir un enfoque para patrones de detección comunes y cómo delimitar el alcance de una regla a la ventana de datos correcta. Para los pasos de la interfaz para crear una regla, consulta Crear y gestionar reglas de detección.

Cómo funcionan las reglas de detección

Cada regla de detección en Lakewatch se ejecuta según una programación. Cuando se ejecuta una regla, ejecuta tu SQL de detección durante una ventana temporal y genera una señal para cada coincidencia. Escribes la consulta completa, incluida la FROM cláusula, para que una regla pueda unir tablas, escanear una tabla entera o calcular agregados. Una regla se ejecuta en un almacén SQL que proporciones, o en computación sin servidor; consulta Configurar un almacén de detección.

Estableces el calendario de una regla y calculas cuando la creas. Consulta Crear y gestionar reglas de detección.

Elección de un enfoque

Esta tabla asigna patrones comunes de detección a cómo elaboras cada uno:

Aplicar las reglas a un intervalo temporal

Siempre que sea posible, ajusta una regla a un rango de tiempo relevante en lugar de escanear toda una tabla. Usa la IN_TIMERANGE() función para expresar esa ventana y deja que la ejecución suministre los límites:

SELECT *
FROM process_activity
WHERE IN_TIMERANGE(time)
  AND activity_id = 1
  AND endswith(lower(process.name), '\\hashcat.exe')

IN_TIMERANGE(time) devuelve true cuando un evento cae dentro del rango de tiempo efectivo de la ejecución actual. El intervalo es semiabierto: se incluye un evento cuya marca de tiempo es igual al inicio de la ventana, pero se excluye uno que sea igual al final, por lo que las ejecuciones adyacentes nunca cuentan dos veces el límite. No escribes tú mismo los horarios de inicio y fin en la consulta SQL. En su lugar, Lakewatch proporciona el rango basado en cómo se ejecuta la consulta:

• En una regla de detección, la ventana se deriva de la programación de la regla y termina en el momento de activación de la ejecución. Una regla que se repite cada 15 minutos cubre una porción de 15 minutos. Puedes ampliar ese segmento extend_lookback para incluir los registros que llegan con retraso.
• En la página de consulta (que puedes usar para desarrollar una regla), seleccionas la ventana usando el selector de fecha/hora. Como SQL escrito en la página de consulta no contiene el rango de tiempo, puede desplegarse como una regla de detección sin cambios.

Extender la ventana con extend_lookback

IN_TIMERANGE() filtra por la hora del evento, pero los registros suelen llegar a la tabla minutos después de que ocurra el evento. Una fila puede aterrizar después de que la ejecución cuya ventana cubrió su tiempo de evento ya haya terminado, y las ejecuciones posteriores escanean los tiempos de evento más recientes, creando una brecha de cobertura. extend_lookback, una configuración opcional por regla, mueve el inicio de la ventana hacia atrás para que cada ejecución vuelva a examinar un segmento del tiempo del evento más antiguo y capture las filas que han llegado desde la última ejecución. Solo cambia el límite más temprano; el último límite se mantiene en el momento de disparo de la ejecución. Ponlo a una duración como 30s, 10m, o 2h. La ventana que examina una regla programada es la cadencia de su programación más extend_lookback:

Si no configuras extend_lookback, Lakewatch aplica un valor por defecto de 15 minutos. La mayoría de los orígenes empresariales entregan en pocos minutos, pero pocos garantizan un límite superior, por lo que el valor predeterminado absorbe las llegadas tardías típicas sin necesidad de ajuste.

extend_lookback no tiene un campo de formulario dedicado. Configúralo editando la regla como YAML ( véase Crear y gestionar reglas de detección) y añadiendo un bloque de nivel superior timerange :

timerange:
  extend_lookback: 30m

Elige la columna de tiempo adecuada

El tiempo de evento (time) combinado con extend_lookback es el enfoque adecuado para casi todas las reglas. Estima el retardo de ingestión de tu fuente y configura extend_lookback para cubrirlo, o confía en el valor predeterminado de 15 minutos para las fuentes que entregan puntualmente.

Si la latencia de ingestión de una fuente es tan variable que ninguna sola extend_lookback la cubre de forma fiable, puedes en su lugar definir la regla sobre el tiempo de ingestión. En tablas producidas por una fuente de datos de Lakewatch, la lw_meta.ingestion_time columna registra cuándo Lakewatch escribió cada fila tras la ingestión, de modo que una ventana sobre ella no se ve afectada por retrasos en la entrega:

WHERE IN_TIMERANGE(lw_meta.ingestion_time)

Recurra a esto solo cuando el tiempo del evento más extend_lookback no pueda hacer el trabajo. Cada ejecución cubre entonces una porción fija del tiempo de ingestión en lugar del tiempo del evento , por lo que la marca temporal propia de un evento puede quedar fuera de la ventana nominal de la ejecución, lo que puede sesgar las agregaciones por intervalos de tiempo. Intente resolverlo primero con el tiempo del evento.

Evitar anclar a NOW() o CURRENT_TIMESTAMP()

Un patrón común escribe a mano la ventana frente al tiempo actual del reloj:

-- Avoid this
WHERE time BETWEEN CURRENT_TIMESTAMP() - INTERVAL 24 HOUR AND CURRENT_TIMESTAMP()

Esto funciona para una ejecución rutinaria, pero puede crear problemas:

• Puede omitir datos o contarlos dos veces. Una ventana como "la última hora" está anclada al momento en que se dispara la ejecución, no al corte que debía cubrir. Si una ejecución de 3:00 se retrasa a 3:12, escanea 2:12–3:12, deja un hueco de 2:00–2:12 y puede solaparse con la siguiente ejecución. IN_TIMERANGE() deriva la ventana a partir del segmento programado, eliminando ese riesgo de brechas y solapamientos.
• No se adapta a los cambios de horario. Si cambias una regla de cada 15 minutos a cada 30 minutos, un código INTERVAL 15 MINUTES fijo está mal hasta que recuerdas editarlo. Con IN_TIMERANGE(), la ventana sigue la programación.
• No se puede volver a enventanar. Rellenar un periodo perdido, volver a ejecutar tras una corrección de datos o previsualizar una nueva regla contra datos antiguos ejecutan la misma regla en una ventana diferente. Una consulta bloqueada en NOW() no puede hacerlo sin ediciones manuales.
• Es más difícil de reproducir. Con los mismos límites, IN_TIMERANGE() escanea las mismas filas en cada ejecución, por lo que los resultados son repetibles. Una consulta vinculada a NOW() cambia con cada ejecución.

Reserva NOW() y CURRENT_TIMESTAMP() para los casos en los que necesites hacer referencia a la hora real, como calcular la antigüedad de un evento respecto al momento presente.

Haga referencia a la ventana de la ejecución con TIMERANGE_NOW()

Cuando necesites un valor "ahora" que respete la ventana de ejecución en lugar del reloj de pared, usa TIMERANGE_NOW(). Devuelve la hora del desencadenador de la ejecución y recurre a la hora actual real cuando no se establece ninguna ventana (por ejemplo, en la página de consultas). Úsela para crear a mano una ventana que IN_TIMERANGE() no pueda expresar, como desplazar la ventana o examinar dos períodos no adyacentes en una sola ejecución:

Esta tabla resume cuándo usar cada función: