La consulta y la regla

En KQL, summarize ... by produce una fila por cada combinación distinta de las columnas de agrupación, y un where posterior filtra esas filas ya agrupadas. Antes de agrupar, el where del tiempo deja fuera lo que cae fuera de la ventana: el límite inferior se incluye y el superior no.

Unir lo que pasó en dos tablas por la identidad o por la dirección cuenta la historia completa: los fallos seguidos y el acierto están en una tabla, y lo que hizo la cuenta una vez dentro está en la tabla de actividad de Azure. La dirección de origen es el hilo que las ata.

Una consulta cuenta exactamente los eventos que su filtro nombra. Un registro se puede debilitar de más de una forma, y cada forma es un evento distinto: lo que no está en la lista del filtro no entra en el resultado aunque el efecto sea parecido. Leer una consulta es también preguntarse qué se le escapa.

Una regla portable habla con nombres de campo comunes, y un conversor los traduce a los del SIEM con un mapa. Si un campo de la regla no está en el mapa, la conversión falla o, peor, descarta esa condición en silencio y la regla deja de ser la que se escribió.

Cada regla se prueba con casos que deben avisar y casos que no deben. Una prueba falla cuando lo esperado y lo obtenido no coinciden, y los que fallan por no avisar son los más caros: un atacante, o un descuido, pasa sin que nadie se entere.