Qué registra el proveedor de identidad y qué no llega al SIEM

Cada fila del registro de inicios de sesión (la tabla SigninLogs en el proveedor que usa esta empresa) trae la hora, la cuenta, la dirección de origen, la aplicación, el cliente con que se entró y un código de resultado, ResultType. El código 0 significa que el proveedor de identidad aceptó el inicio de sesión. Cualquier otro valor es un fallo con su motivo.

Esa frase tiene una trampa para quien escribe reglas: un 0 no dice que quien entró fuera la persona dueña de la cuenta, y un fallo no dice que alguien atacara. Una persona que se equivoca de contraseña genera un fallo normal; un atacante con la contraseña correcta genera un 0. Las detecciones de identidad se construyen sobre combinaciones de campos, no sobre un campo solo.

Abre la tabla en la consola con la consulta de abajo y mira las columnas y las doce filas.

SigninLogs

El código de resultado es el motivo escrito del fallo y es la materia prima de casi toda regla de identidad. Hay códigos para contraseña equivocada, para cuenta deshabilitada, para segundo factor no superado y para bloqueo por una directiva de acceso condicional. Una regla de fuerza bruta mira unos códigos; una de fatiga de MFA mira otros. Si la regla usa un código equivocado, no se dispara nunca o se dispara siempre.

La tabla codigos del laboratorio trae los de esta muestra. Léela completa antes de escribir nada.

codigos

Antes de afinar una regla se mira cuánto ruido hay. summarize agrupa filas y count() las cuenta; juntos responden «cuántos fallos de cada tipo tuve esta mañana». Sirve de línea base: si ya hay unos pocos fallos de contraseña normales por mañana, una regla que se dispare con dos fallos va a ser una fábrica de falsas alarmas.

SigninLogs | where ResultType != "0" | summarize fallos = count() by ResultType

Un proveedor de identidad separa lo que la persona hace de lo que su cliente hace por ella. En el primer grupo están las entradas con contraseña y segundo factor; en el segundo, las renovaciones silenciosas de sesión con un token, que ocurren sin que nadie escriba nada. Son tablas distintas y se envían al SIEM por separado, y es frecuente que solo se configure la primera.

La tabla fuentes_de_registro lista cada fuente de la empresa, su tabla en el proveedor y si se está ingiriendo. Filtra las que no.

fuentes_de_registro | where ingerida == "no"

Una fuente sin ingerir no es un detalle de configuración: es una regla que no se puede escribir. Para el ingeniero de identidad, el inventario de fuentes es el primer entregable, porque dice qué ataques se pueden ver y cuáles no, aunque la regla esté perfecta.