Les alertes de DLP surten de la cua el 12 d'octubre: la taula on queden pot estar buida

El 12 d'octubre s'encén tota sola, al teu tenant, una regla que ja està escrita: les alertes de prevenció de pèrdua de dades de Purview deixen de ser alertes i passen a ser comportaments. No s'esborren —això diu l'avís—. Deixen d'entrar a la cua d'incidents de Defender XDR. L'avís l'acompanya d'una frase tranquil·litzadora —els senyals continuen disponibles per a cerca avançada a les taules BehaviorInfo i BehaviorEntities— i és justament aquesta frase la que convé llegir a poc a poc, perquè la pàgina que documenta aquella taula diu que la poblen dos serveis diferents, i que sense ells la consulta no retorna res.

Farem una cosa que probablement no esperes d'un article sobre aquest canvi: no et direm que desactivis la regla. El diagnòstic de Microsoft ens sembla correcte, i rebaixar soroll és exactament el criteri amb què muntem monitorització. El que no ens sembla correcte és el «per defecte», i que de les dues sortides que ofereix l'avís, la que et deixa continuar treballant dins la consola de seguretat depengui d'una peça que molta gent no té. Tot el que ve surt de llegir seguides tres pàgines de documentació de Microsoft i un avís del Centre de missatges; les citacions van en el seu idioma original perquè les puguis comprovar.

La regla, amb la citació al davant

Microsoft ho fica en un requadre d'avís, a dalt de tot, a l'article que explica com investigar alertes de pèrdua de dades a Defender XDR. La pàgina es va actualitzar el 31 d'agost del 2026 i diu, literalment: «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.» I tot seguit: «The signals remain available for advanced hunting in the BehaviorInfo and BehaviorEntities tables.»

Fixa't en el que aquella nota no diu: no diu el dia. Diu «early October 2026». El dia surt de l'avís del Centre de missatges MC1465771, publicat l'1 de setembre del 2026, que fixa el 12 d'octubre del 2026 i dona el nom exacte de l'interruptor: la regla es diu Set-As-Behavior - Data Loss Prevention (DLP) Alerts. La ruta per apagar-la sí que és a la documentació, al final del mateix requadre: Settings > Microsoft Defender XDR > Alert tuning. Si el teu calendari de canvis depèn de dates exactes, apunta aquesta asimetria: la data que et permet planificar no és a la documentació pública, és en un avís que caduca i desapareix del portal.

Què és un «comportament», i què deixa de passar

No és un terme de màrqueting: és una de les tres accions que pots triar en crear la teva pròpia regla d'ajust d'alertes, i Microsoft la defineix a la pàgina d'investigació d'alertes. «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.» Les altres dues són Hide alert (només per a alertes de Defender for Endpoint) i Resolve alert.

La part important d'aquella definició són tres paraules: «or trigger incidents». A Defender XDR l'incident no és un adorn del llistat, és l'objecte del qual penja tota la resta: la correlació amb alertes d'Endpoint, d'Office 365, d'Identity o de Sentinel sota una sola història; l'assignació a un analista; les etiquetes; l'estat; i, a la pràctica de molta gent, el tiquet que neix automàticament quan apareix un incident nou. Un senyal que no crea incident no activa res d'això. La taula d'orígens d'alerta de Microsoft assigna a les de pèrdua de dades el prefix dl{GUID} —amb l'advertiment, en aquella mateixa pàgina, que aquests prefixos són propis de les experiències unificades—: el que ja tens recollit no s'esborra, però si alguna cosa teva s'alimenta d'aquell flux, a partir del dia 12 deixa d'entrar-li res de nou per aquí.

Hi ha un matís que convé no exagerar, i ho diem perquè va en contra de la lectura alarmista: la mateixa pàgina afirma que les regles integrades «suppress alerts without affecting other features like AIR investigations and email notifications». És a dir, Microsoft sosté que apagar l'alerta a la cua no apaga les notificacions per correu. El que la documentació no aclareix és si hi inclou les notificacions que generen les mateixes polítiques d'alerta de Purview, que viatgen per un altre camí. Nosaltres no ho sabem i no ho escriurem com si ho sabéssim: ho hem posat a la llista de comprovacions de més avall, que és on han d'anar les coses que es verifiquen al teu tenant i no en un article.

El pla B té lletra petita

Aquí hi ha el que ens va fer escriure aquest article. La frase «els senyals continuen disponibles a BehaviorInfo» sona a xarxa de seguretat. Així que vam anar a la pàgina de referència d'aquella taula. Diu tres coses. Una: està en vista prèvia i no està disponible per a GCC. Dues, i és 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 les seves columnes no n'apareix cap d'específica de pèrdua de dades.

Siguem justos amb la font: aquella pàgina de referència es va actualitzar per darrera vegada el 14 de juny del 2026, gairebé tres mesos abans de l'avís. És perfectament possible que Microsoft l'ampliï i que els senyals de DLP escriguin allà igual que hi escriuen els de Defender for Cloud Apps. No ho afirmem ni ho neguem, perquè no ho sabem. El que sí que sabem és això: l'avís et diu on van les teves dades, la referència d'aquella taula diu d'on surten les seves dades, i les dues frases no encaixen. Comprovar-ho costa dos minuts i el 12 d'octubre és tard per fer-ho, perquè llavors ja no tindràs alertes amb què comparar.

Hi ha una segona porta, i la indica la mateixa guia de DLP: la taula CloudAppEvents, que segons Microsoft «contains all audit logs across all locations like SharePoint, OneDrive, Exchange and Devices» i per a la qual la mateixa pàgina et demana explícitament tenir-hi accés perquè és la que conté «Microsoft Purview DLP audit data». Amb un límit declarat a la mateixa pàgina: la cerca avançada et deixa explorar fins a 30 dies de registres d'auditoria. Trenta dies és molt per a un triatge i molt poc per a una investigació que arrenca amb una carta de l'advocat de l'altra part. I amb una pega que diem encara que afebleixi el nostre propi argument: aquella segona porta tanca amb la mateixa clau, perquè la referència de CloudAppEvents declara també que la poblen els registres de Defender for Cloud Apps, i la mateixa guia de DLP t'envia a connectar Microsoft 365 amb aquell servei abans de començar.

La sortida que sí que és segura (i per què gairebé ningú no l'explica)

L'avís ofereix dues sortides, no una, i la segona és la que no corre cap risc de dependre de peces que no tinguis: les alertes de DLP continuen sent-hi, senceres, al portal de Purview. Allà no canvia res. Si algú de la teva organització entra a Purview amb una freqüència escrita i fa alguna cosa amb el que hi troba, el dia 12 no et passa res —i llavors aquest article et sobra, que també és un resultat honest. Ho diem perquè la majoria de les cobertures d'aquest canvi es queden amb la frase de la taula de cerca avançada, que sona més tècnica, i se salten la que de debò resol el problema per a qui ja treballa a Purview.

El problema apareix quan la resposta a «qui entra a Purview?» és la que donem gairebé tots: ningú no hi entra, perquè per això hi ha la cua. La cua de Defender és on mira qui té la guàrdia. Purview és on mira qui fa l'auditoria anual. Són dues persones diferents i, en una empresa mitjana, sovint una sola persona amb dos barrets i temps per a un.

Per què no et diem que la desactivis

Perquè Microsoft té raó en el diagnòstic. El DLP, quan es desplega de debò i no d'adorn, produeix volum: cada adjunt amb un número de compte, cada document amb un DNI copiat a un USB, cada enllaç compartit fora del domini. Posa-hi la xifra que vulguis —dos-cents avisos al dia, cent, quaranta—: a partir d'un cert punt una cua així no es triatja, s'ignora. I una cua ignorada és pitjor que no tenir-ne, perquè des de fora —des de direcció, des del comitè, des de l'auditoria— sembla que algú mira. Portem monitorització amb un criteri que no ha canviat en anys: alertes que importen, no soroll.

La diferència entre apagar i silenciar no és en el resultat —en tots dos casos la pantalla es queda en blanc— sinó en el que queda escrit. Quan apagues tu, hi ha una frase que diu què deixes de veure, per què, i qui ho mira en lloc teu. Quan ho apaga el valor per defecte d'un fabricant, no hi ha aquesta frase. El «per defecte» és una decisió de disseny presa per a la mitjana de milions de tenants, i el teu tenant no és la mitjana: una gestoria de cinc persones amb dades de nòmina de tres-centes empreses no té el mateix perfil de risc que una cadena de botigues. Ja vam veure aquest mateix mecanisme quan Defender va canviar el dispar manual de les seves investigacions automàtiques: el canvi no trenca res el primer dia, i per això ningú no el veu.

La tercera via que la mateixa documentació deixa oberta

A la mateixa secció de regles integrades hi ha una línia que gairebé ningú no cita i que canvia el problema sencer: «Built-in alert tuning rules don't apply to alerts from custom detection rules and Custom TI.» Llegeix-ho un altre cop. La regla que Microsoft encendrà no toca les alertes que neixen d'una regla de detecció personalitzada. I una regla de detecció personalitzada no és res més que una consulta de cerca avançada a la qual li dius «quan això retorni files, crea'm una alerta».

Això converteix una decisió de tot o res —me les empasso totes o em quedo cec— en una decisió de disseny: tornes a posar a la cua només allò que de debò justifica despertar algú. La política de nòmines, no totes. La destinació externa, no la interna. L'etiqueta de confidencialitat alta, no qualsevol coincidència. Això no surt de franc, i convé dir el preu sencer: la consulta ha de complir els requisits de l'assistent de deteccions personalitzades —retornar marca de temps i identificador de registre, i una entitat amb què mapar l'actiu—, cal permís d'administració de configuració de seguretat per crear-la i, sobretot, hereta el problema anterior: s'escriu contra una de les dues taules que acabem de posar en dubte, així que només serveix si la comprovació 2 o la 3 et van retornar files. Si no, aquesta via no existeix per a tu i la decisió es redueix a les altres dues.

Quatre comprovacions abans del dia 12

En ordre, i amb la regla que cap no es respon amb un «sí» de memòria. La segona i la tercera es fan a la consola de cerca avançada i triguen el que triguis a enganxar-les.

1. Tens DLP generant alertes de debò? Si les teves polítiques de Purview no tenen les alertes activades, o no tens una de les llicències que Microsoft exigeix per investigar DLP al portal de Defender —Office 365 E5/A5, Microsoft 365 E5/A5, E5/A5 Compliance o E5/A5 Information Protection and Governance—, aquest canvi no t'afecta avui. T'afectarà el dia que desplegis DLP de debò, amb la regla ja posada i ningú recordant que hi és.

2. La taula del pla B retorna res al teu tenant? L'objectiu d'aquesta consulta no és la dada: és saber si hi ha files. Si retorna buit avui, amb les alertes encara actives, difícilment s'omplirà tota sola el dia 12. Repeteix el mateix canviant BehaviorInfo per BehaviorEntities, que és la taula germana que cita l'avís: t'interessen totes dues, perquè la primera et dona el què i la segona el qui i el sobre què.

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

3. Tens accés a la taula d'auditoria, i amb quina finestra? És l'altra porta, la que la guia de DLP assenyala explícitament. Substitueix el filtre pels tipus d'acció que vegis al teu tenant: els noms exactes depenen de les càrregues de treball que tinguis connectades.

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

4. Decideix per escrit, i amb nom. Només hi ha tres sortides honestes i totes tres són defensables: deixar la regla posada i escriure qui entra al portal de Purview, amb quina freqüència i què fa si hi troba alguna cosa; desactivar la regla assumint el volum, amb algú que el triatgi de debò; o escriure una detecció personalitzada amb dues o tres condicions i deixar la regla posada per a la resta. L'única sortida que no val és la quarta, la que es pren tota sola: no fer res i que el dia 12 la cua es quedi en silenci sense que ningú ho hagi decidit.

A què s'assembla això

Fa uns dies vam escriure sobre una tècnica d'injecció que no va generar cap alerta en quatre EDR diferents, i la conclusió era que quan la detecció falla —i falla— l'únic que queda és telemetria desada i algú que la consulti. Aquí la detecció no falla: funciona perfectament, i algú decideix que el que detecta no mereix entrar a la cua. El resultat operatiu és idèntic, i per això la pregunta útil és la mateixa: quant temps guardes el senyal i qui el mira? En DLP aquella pregunta té a més una pota legal, perquè el registre que demostra què va sortir i quan és exactament el que et demanaran; ja vam avisar que una retenció no és una còpia de seguretat, i una taula de cerca avançada amb trenta dies tampoc no ho és.

Nou dies

Això és el que queda. No cal una reunió: calen dues consultes enganxades en una pantalla i una frase escrita amb un nom al costat. Si el resultat de les consultes és bo i algú entra a Purview cada setmana, no facis res i dorm tranquil: també és una decisió, sempre que l'hagis presa tu.

Fonts (verificades el 3 d'octubre del 2026): el requadre d'avís amb la citació d'«early October 2026», les taules de destinació, la ruta per desactivar la regla, els requisits de llicència, la taula CloudAppEvents com a origen de les dades d'auditoria de DLP i la finestra de 30 dies surten d'Investigate data loss alerts with Microsoft Defender XDR (Microsoft Learn, actualitzat el 31-08-2026). La definició literal de «Set as behavior», les tres accions d'ajust d'alertes, la frase sobre AIR i notificacions per correu, l'exclusió de les regles de detecció personalitzades i Custom TI, i la taula de prefixos d'origen d'alerta amb dl{GUID} surten d'Investigate alerts in Microsoft Defender XDR (actualitzat el 16-09-2026). Que BehaviorInfo està en vista prèvia, no disponible per a GCC, i que la poblen Defender for Cloud Apps i UEBA —amb la frase sobre consultes que no retornen resultats— surt de BehaviorInfo table in the advanced hunting schema (actualitzat el 14-06-2026). La data del 12 d'octubre del 2026 i el nom exacte de la regla procedeixen de l'avís MC1465771 del Centre de missatges de Microsoft 365, publicat el 01-09-2026. Els noms de columna de les consultes són els que documenta Microsoft; els valors concrets depenen del teu tenant.