Las alertas de DLP salen de la cola el 12 de octubre: la tabla donde quedan puede estar vacía

El 12 de octubre se enciende sola, en tu tenant, una regla que ya está escrita: las alertas de prevención de pérdida de datos de Purview dejan de ser alertas y pasan a ser comportamientos. No se borran —eso dice el aviso—. Dejan de entrar en la cola de incidentes de Defender XDR. El aviso lo acompaña de una frase tranquilizadora —las señales siguen disponibles para búsqueda avanzada en las tablas BehaviorInfo y BehaviorEntities— y es justo esa frase la que conviene leer despacio, porque la página que documenta esa tabla dice que la pueblan otros dos servicios, y que sin ellos la consulta no devuelve nada.

Vamos a hacer algo que probablemente no esperas de un post sobre este cambio: no te vamos a decir que desactives la regla. El diagnóstico de Microsoft nos parece correcto, y rebajar ruido es exactamente el criterio con el que montamos monitorización. Lo que no nos parece correcto es el «por defecto», y que de las dos salidas que ofrece el aviso, la que te deja seguir trabajando dentro de la consola de seguridad dependa de una pieza que mucha gente no tiene. Todo lo que viene sale de leer seguidas tres páginas de documentación de Microsoft y un aviso del Centro de mensajes; las citas van en su idioma original para que puedas comprobarlas.

La regla, con la cita delante

Microsoft lo mete en un recuadro de aviso, arriba del todo, en el artículo que explica cómo investigar alertas de pérdida de datos en Defender XDR. La página se actualizó el 31 de agosto de 2026 y dice, literalmente: «A built-in alert tuning rule for DLP signals will take effect in early October 2026. In Microsoft Defender XDR, the rule sets these signals as behaviors instead of alerts, so they don't generate alerts or appear in the incident queue.» Y a continuación: «The signals remain available for advanced hunting in the BehaviorInfo and BehaviorEntities tables.»

Fíjate en lo que esa nota no dice: no dice el día. Dice «early October 2026». El día sale del aviso del Centro de mensajes MC1465771, publicado el 1 de septiembre de 2026, que fija el 12 de octubre de 2026 y da el nombre exacto del interruptor: la regla se llama Set-As-Behavior - Data Loss Prevention (DLP) Alerts. La ruta para apagarla sí está en la documentación, al final del mismo recuadro: Settings > Microsoft Defender XDR > Alert tuning. Si tu calendario de cambios depende de fechas exactas, apunta esta asimetría: la fecha que te permite planificar no está en la documentación pública, está en un aviso que caduca y desaparece del portal.

Qué es un «comportamiento», y qué deja de ocurrir

No es un término de marketing: es una de las tres acciones que puedes elegir al crear tu propia regla de ajuste de alertas, y Microsoft la define en la página de investigación de alertas. «Set as behavior: Converts matching signals into behaviors. They won't appear in the alert queue or trigger incidents. Data remains in BehaviorInfo and BehaviorEntities tables for hunting. This action isn't supported for Defender for Cloud or Microsoft Defender for Office 365 alerts.» Las otras dos son Hide alert (solo para alertas de Defender para Endpoint) y Resolve alert.

La parte importante de esa definición son tres palabras: «or trigger incidents». En Defender XDR el incidente no es un adorno del listado, es el objeto del que cuelga todo lo demás: la correlación con alertas de Endpoint, de Office 365, de Identity o de Sentinel bajo una sola historia; la asignación a un analista; las etiquetas; el estado; y, en la práctica de mucha gente, el ticket que nace automáticamente cuando aparece un incidente nuevo. Una señal que no crea incidente no activa nada de eso. La tabla de orígenes de alerta de Microsoft asigna a las de pérdida de datos el prefijo dl{GUID} —con la advertencia, en esa misma página, de que esos prefijos son propios de las experiencias unificadas—: lo que ya tienes recogido no se borra, pero si algo tuyo se alimenta de ese flujo, a partir del día 12 deja de entrarle nada nuevo por ahí.

Hay un matiz que conviene no exagerar, y lo decimos porque va en contra de la lectura alarmista: la misma página afirma que las reglas integradas «suppress alerts without affecting other features like AIR investigations and email notifications». Es decir, Microsoft sostiene que apagar la alerta en la cola no apaga las notificaciones por correo. Lo que la documentación no aclara es si ahí incluye las notificaciones que generan las propias políticas de alerta de Purview, que viajan por otro camino. Nosotros no lo sabemos y no lo vamos a escribir como si lo supiéramos: lo hemos puesto en la lista de comprobaciones de más abajo, que es donde deben ir las cosas que se verifican en tu tenant y no en un artículo.

El plan B tiene letra pequeña

Aquí está lo que nos hizo escribir este post. La frase «las señales siguen disponibles en BehaviorInfo» suena a red de seguridad. Así que fuimos a la página de referencia de esa tabla. Dice tres cosas. Una: está en vista previa y no está disponible para GCC. Dos, y es la que importa: «This advanced hunting table is populated by records from both Defender for Cloud Apps and UEBA. If your organization doesn't deploy these services in Microsoft Defender, queries that use the table won't work or return any results.» Tres: entre sus columnas no aparece ninguna específica de pérdida de datos.

Seamos justos con la fuente: esa página de referencia se actualizó por última vez el 14 de junio de 2026, casi tres meses antes del aviso. Es perfectamente posible que Microsoft la amplíe y que las señales de DLP escriban ahí igual que escriben las de Defender for Cloud Apps. No lo afirmamos ni lo negamos, porque no lo sabemos. Lo que sí sabemos es esto: el aviso te dice dónde van tus datos, la referencia de esa tabla dice de dónde salen sus datos, y las dos frases no encajan. Comprobarlo cuesta dos minutos y el 12 de octubre es tarde para hacerlo, porque entonces ya no tendrás alertas con las que comparar.

Hay una segunda puerta, y la señala la propia guía de DLP: la tabla CloudAppEvents, que según Microsoft «contains all audit logs across all locations like SharePoint, OneDrive, Exchange and Devices» y para la que la misma página te pide explícitamente tener acceso porque es la que contiene «Microsoft Purview DLP audit data». Con un límite declarado en la propia página: la búsqueda avanzada te deja explorar hasta 30 días de registros de auditoría. Treinta días es mucho para un triaje y muy poco para una investigación que arranca con una carta del abogado de la otra parte. Y con una pega que decimos aunque debilite nuestro propio argumento: esa segunda puerta cierra con la misma llave, porque la referencia de CloudAppEvents declara también que la pueblan los registros de Defender for Cloud Apps, y la propia guía de DLP te manda a conectar Microsoft 365 con ese servicio antes de empezar.

La salida que sí es segura (y por qué casi nadie la cuenta)

El aviso ofrece dos salidas, no una, y la segunda es la que no corre ningún riesgo de depender de piezas que no tengas: las alertas de DLP siguen estando, íntegras, en el portal de Purview. Ahí no cambia nada. Si alguien de tu organización entra en Purview con una frecuencia escrita y hace algo con lo que encuentra, el día 12 no te pasa nada —y entonces este post te sobra, que también es un resultado honesto. Decimos esto porque la mayoría de las coberturas de este cambio se quedan en la frase de la tabla de búsqueda avanzada, que suena más técnica, y se saltan la que de verdad resuelve el problema para quien ya trabaja en Purview.

El problema aparece cuando la respuesta a «¿quién entra en Purview?» es la que damos casi todos: nadie entra, porque para eso está la cola. La cola de Defender es donde mira el que tiene la guardia. Purview es donde mira el que hace la auditoría anual. Son dos personas distintas y, en una empresa mediana, muchas veces una sola persona con dos sombreros y tiempo para uno.

Por qué no te decimos que la desactives

Porque Microsoft tiene razón en el diagnóstico. El DLP, cuando se despliega de verdad y no de adorno, produce volumen: cada adjunto con un número de cuenta, cada documento con un DNI copiado a un USB, cada enlace compartido fuera del dominio. Pon la cifra que quieras —doscientos avisos al día, cien, cuarenta—: a partir de cierto punto una cola así no se triagea, se ignora. Y una cola ignorada es peor que no tener cola, porque desde fuera —desde dirección, desde el comité, desde la auditoría— parece que alguien mira. Llevamos monitorización con un criterio que no ha cambiado en años: alertas que importan, no ruido.

La diferencia entre apagar y silenciar no está en el resultado —en los dos casos la pantalla se queda en blanco— sino en lo que queda escrito. Cuando apagas tú, hay una frase que dice qué dejas de ver, por qué, y quién lo mira en su lugar. Cuando lo apaga el valor por defecto de un fabricante, no hay esa frase. El «por defecto» es una decisión de diseño tomada para la media de millones de tenants, y tu tenant no es la media: una gestoría con cinco personas y datos de nómina de trescientas empresas no tiene el mismo perfil de riesgo que una cadena de tiendas. Ya vimos este mismo mecanismo cuando Defender cambió el disparo manual de sus investigaciones automáticas: el cambio no rompe nada el primer día, y por eso nadie lo ve.

La tercera vía que la propia documentación deja abierta

En la misma sección de reglas integradas hay una línea que casi nadie cita y que cambia el problema entero: «Built-in alert tuning rules don't apply to alerts from custom detection rules and Custom TI.» Léelo otra vez. La regla que Microsoft va a encender no toca las alertas que nacen de una regla de detección personalizada. Y una regla de detección personalizada no es más que una consulta de búsqueda avanzada a la que le dices «cuando esto devuelva filas, créame una alerta».

Eso convierte una decisión de todo o nada —me las trago todas o me quedo a ciegas— en una decisión de diseño: vuelves a meter en la cola solo lo que de verdad justifica despertar a alguien. La política de nóminas, no todas. El destino externo, no el interno. La etiqueta de confidencialidad alta, no cualquier coincidencia. Esto no sale gratis, y conviene decir el precio entero: la consulta tiene que cumplir los requisitos del asistente de detecciones personalizadas —devolver marca de tiempo e identificador de registro, y una entidad con la que mapear el activo—, hace falta permiso de administración de configuración de seguridad para crearla, y, sobre todo, hereda el problema anterior: se escribe contra una de las dos tablas que acabamos de poner en duda, así que solo sirve si la comprobación 2 o la 3 te devolvieron filas. Si no, esta vía no existe para ti y la decisión se reduce a las otras dos.

Cuatro comprobaciones antes del día 12

En orden, y con la regla de que ninguna se responde con un «sí» de memoria. La segunda y la tercera se hacen en la consola de búsqueda avanzada y tardan lo que tardes en pegarlas.

1. ¿Tienes DLP generando alertas de verdad? Si tus políticas de Purview no tienen las alertas activadas, o no tienes una de las licencias que Microsoft exige para investigar DLP en el portal de Defender —Office 365 E5/A5, Microsoft 365 E5/A5, E5/A5 Compliance o E5/A5 Information Protection and Governance—, este cambio no te afecta hoy. Te afectará el día que despliegues DLP de verdad, con la regla ya puesta y nadie recordando que está.

2. ¿La tabla del plan B devuelve algo en tu tenant? El objetivo de esta consulta no es el dato: es saber si hay filas. Si devuelve vacío hoy, con las alertas aún activas, difícilmente va a llenarse sola el día 12. Repite lo mismo cambiando BehaviorInfo por BehaviorEntities, que es la tabla hermana que cita el aviso: te interesan las dos, porque la primera te da el qué y la segunda el quién y el sobre qué.

BehaviorInfo
| where Timestamp > ago(7d)
| summarize Senales = count() by ServiceSource, DetectionSource, ActionType
| order by Senales desc

3. ¿Tienes acceso a la tabla de auditoría, y con cuánta ventana? Es la otra puerta, la que la guía de DLP señala explícitamente. Sustituye el filtro por los tipos de acción que veas en tu tenant: los nombres exactos dependen de las cargas de trabajo que tengas conectadas.

CloudAppEvents
| where Timestamp > ago(30d)
| where ActionType has "DLP"
| summarize Eventos = count() by ActionType, Application
| order by Eventos desc

4. Decide por escrito, y con nombre. Solo hay tres salidas honestas y las tres son defendibles: dejar la regla puesta y escribir quién entra en el portal de Purview, con qué frecuencia y qué hace si encuentra algo; desactivar la regla asumiendo el volumen, con alguien que lo triagee de verdad; o escribir una detección personalizada con dos o tres condiciones y dejar la regla puesta para el resto. La única salida que no vale es la cuarta, la que se toma sola: no hacer nada y que el día 12 la cola se quede en silencio sin que nadie lo haya decidido.

Lo que esto se parece

Hace unos días escribimos sobre una técnica de inyección que no generó ninguna alerta en cuatro EDR distintos, y la conclusión era que cuando la detección falla —y falla— lo único que queda es telemetría guardada y alguien que la consulte. Aquí la detección no falla: funciona perfectamente, y alguien decide que lo que detecta no merece entrar en la cola. El resultado operativo es idéntico, y por eso la pregunta útil es la misma: ¿cuánto tiempo guardas la señal y quién la mira? En DLP esa pregunta tiene además una pata legal, porque el registro que demuestra qué salió y cuándo es exactamente el que te van a pedir; ya avisamos de que una retención no es una copia de seguridad, y una tabla de búsqueda avanzada con treinta días tampoco lo es.

Nueve días

Eso es lo que queda. No hace falta una reunión: hacen falta dos consultas pegadas en una pantalla y una frase escrita con un nombre al lado. Si el resultado de las consultas es bueno y alguien entra en Purview cada semana, no hagas nada y duerme tranquilo: también es una decisión, siempre que la hayas tomado tú.

Fuentes (verificadas el 3 de octubre de 2026): el recuadro de aviso con la cita de «early October 2026», las tablas de destino, la ruta para desactivar la regla, los requisitos de licencia, la tabla CloudAppEvents como origen de los datos de auditoría de DLP y la ventana de 30 días salen de Investigate data loss alerts with Microsoft Defender XDR (Microsoft Learn, actualizado el 31-08-2026). La definición literal de «Set as behavior», las tres acciones de ajuste de alertas, la frase sobre AIR y notificaciones por correo, la exclusión de las reglas de detección personalizadas y Custom TI, y la tabla de prefijos de origen de alerta con dl{GUID} salen de Investigate alerts in Microsoft Defender XDR (actualizado el 16-09-2026). Que BehaviorInfo está en vista previa, no disponible para GCC, y que la pueblan Defender for Cloud Apps y UEBA —con la frase sobre consultas que no devuelven resultados— sale de BehaviorInfo table in the advanced hunting schema (actualizado el 14-06-2026). La fecha del 12 de octubre de 2026 y el nombre exacto de la regla proceden del aviso MC1465771 del Centro de mensajes de Microsoft 365, publicado el 01-09-2026. Los nombres de columna de las consultas son los que documenta Microsoft; los valores concretos dependen de tu tenant.