L'EDR aïlla l'equip tot sol; la regla que el torna a la xarxa s'escriu abans

El 3 de setembre a les 20:19 UTC, algú de Microsoft va afegir una frase a la documentació de Defender for Endpoint. El 4 de setembre a les 19:06 UTC ja no hi era. Va viure menys d'un dia i deia: «This issue can also occur when device isolation is triggered as full isolation by automatic attack disruption. To have automatic attack disruption use selective isolation, define an isolation exclusion rule».

Ho explica el repositori públic on Microsoft escriu aquesta documentació: un commit la posa el dia 3, i el següent que toca el fitxer —titulat «Resolve syncing conflicts from repo_sync_working_branch to public»— la deixa fora. No sabem si la van treure expressament o es va perdre en una sincronització, i no farem veure que ho sabem. El que sí que podem comprovar és que els dos fets que aquella frase unia continuen avui publicats, cadascun en un lloc diferent, i que ajuntar-los ara et toca a tu.

Un aclariment de vocabulari abans de continuar, perquè el producte es diu d'una manera i tothom l'anomena d'una altra. La funció es diu attack disruption (interrupció automàtica d'atacs) i fa diverses coses diferents. Les dues que ens ocupen aquí són contenir i aïllar, que no són sinònims i de la diferència de les quals depèn la resta de l'article.

On viu la barrera quan «contens» un equip

Aïllar actua sobre l'equip: li talla la xarxa des de dins, deixant-li connectivitat amb els serveis de seguretat necessaris. Contenir fa el contrari del que el seu nom suggereix. La documentació descriu l'acció per a un equip no gestionat que està o pot estar compromès, i diu: «When you contain a device, all Defender for Endpoint onboarded devices block incoming and outgoing communication with that device». La política s'aplica a la resta de màquines.

D'aquí en surten tres coses pràctiques, dues d'escrites i una de nostra. Les escrites: pot trigar fins a cinc minuts que els detalls d'un equip acabat de contenir arribin a la resta del parc donat d'alta, i Microsoft recomana no passar de cent equips continguts alhora perquè hi pot haver problemes de rendiment als que apliquen el bloqueig. La nostra, i la marquem com a deducció: si la barrera viu a les altres màquines, el que no estigui donat d'alta —l'hipervisor, la cabina, el NAS, el switch, la impressora, el Linux que ningú no recorda— continua parlant amb l'equip contingut igual que ahir.

Aquesta deducció és la que converteix una decisió de seguretat en una tasca d'inventari, i l'inventari té un parany que ja ens ha mossegat: un agent pot constar en verd a la consola fent setmanes que no envia telemetria. Un equip que consta com a donat d'alta i no ho està no bloqueja res, i a sobre compta al teu percentatge de cobertura.

El que s'aïlla tot sol són llocs d'usuari

L'objecció que ens posen a les reunions sol ser «no vull que una IA em desconnecti el servidor de fitxers». Aquesta concretament no passa. Ho diuen dues pàgines diferents amb la mateixa frase: «Automatic device isolation works only on end-user workstations that are onboarded and managed by Microsoft Defender for Endpoint». Llocs d'usuari, donats d'alta i gestionats. I les dues pàgines marquen a més l'aïllament automàtic com a vista prèvia, cosa que importa per planificar: nosaltres una funció en vista prèvia la pilotem en un grup petit i la documentem com a reversible.

Als servidors crítics els passa l'altra cosa. La secció de contenció d'actius crítics diu que «Device containment supports critical asset types like domain controllers, DNS servers, and DHCP servers» i que allà la contenció «blocks only specific ports and communication directions», amb l'objectiu declarat que l'actiu continuï funcionant. Al controlador de domini no se li talla la xarxa: se li talla una part molt concreta.

Els dos fets que la frase esborrada unia

El primer fa temps que està publicat i hi continua avui, a la llista de punts a tenir en compte de l'aïllament. El citem sencer, perquè la segona meitat matisa la primera i ometre-la seria fer trampa: «In environments that use web proxies (including Proxy Auto Configuration (PAC), WPAD, or static/direct proxy configurations), devices might not be able to recover from network isolation. Use selective isolation in such cases. When using selective isolation, exclusion settings aren't required to avoid this scenario».

Llegit així, per a l'aïllament manual el problema està resolt: tries tu el mode, tries selectiu, i ni tan sols calen regles d'exclusió. El segon fet és a una altra secció, la de l'aïllament automàtic, i és una nota: «When an isolation exclusion rule is defined, automatic attack disruption uses selective isolation by default and isolates the device according to the configured isolation exclusion rules».

Hi ha dues coses més sobre aquestes regles que convé saber abans de tocar l'interruptor. Una, que les regles d'exclusió d'aïllament es defineixen a Settings > Endpoints > Advanced features > Isolation Exclusion Rules, i que en habilitar la funció les exclusions incorporades per a Microsoft Teams, Outlook i Skype deixen d'aplicar-se i la llista arrenca buida a totes les plataformes (Skype, aclareix la mateixa documentació, està en desús i ja no entra en cap exclusió per defecte). Si vols que Teams i Outlook continuïn funcionant durant un aïllament, els escrius tu.

I dues, la limitació que decideix el moment en què aquesta feina serveix d'alguna cosa: «Changes to exclusion rules only impact new isolation requests. Devices that were already isolated remain with the exclusions that were defined when they were applied». Amb l'equip ja aïllat, aplicar una regla nova exigeix alliberar-lo i tornar-lo a aïllar. Amb l'incident en marxa, la palanca no es mou.

Un límit honest de tot això: la documentació diu que «Exclusions, such as e-mail, messaging application, and other applications for both macOS and Linux isolation aren't supported», i l'aïllament selectiu està disponible a Windows, Azure Stack HCI i macOS. És a dir que «escriu la regla abans» resol la part Windows del parc i deixa fora Linux. Si tens llocs Linux donats d'alta, aquell tros del pla s'ha de resoldre per una altra banda.

El camí de tornada, punt per punt

L'acció d'anada es dispara sola i en segons. La tornada està repartida entre diverses seccions de la documentació i, posada en fila, es llegeix diferent:

• Alliberar l'equip és manual, des del portal, amb Release from isolation. Per fer servir la funció d'aïllament la documentació demana com a mínim el rol Active remediation actions i accés a l'equip segons la configuració de grups de dispositius.
• Si ningú no l'allibera, hi ha rellotge, però no el mateix en tots dos casos. L'aïllament manual s'aixeca als set dies. Per al disparat per attack disruption la documentació diu només «after a defined time window», sense donar la xifra. La contenció d'un usuari per attack disruption sí que la dona: cinc dies.
• Si l'equip deixa de respondre aïllat, hi ha un script d'alliberament forçat amb tres condicions: es descarrega des de la pàgina d'aquell equip, caduca als tres dies i només funciona a Windows amb versions i KB concrets. L'executen administradors o qui tingui permisos de gestió de configuració de seguretat, que no són exactament els mateixos permisos que alliberar des del portal.
• A Linux el risc va en direcció contrària: un equip aïllat surt de l'aïllament quan un administrador modifica o afegeix una regla d'iptables. L'ordre amb què un company intenta ajudar tomba la contenció sense que ningú ho decideixi.
• Un equip aïllat darrere d'una VPN de túnel complet no arriba al servei al núvol de Defender. La recomanació escrita és túnel dividit per al trànsit de Defender for Endpoint i de la protecció al núvol de l'antivirus.

Dos efectes colaterals que no surten a la demo

El primer és per a qui virtualitza a Windows: «Isolating a server running on Microsoft Hyper-V blocks network traffic to all child virtual machines of the server». Aïllar un amfitrió Hyper-V deixa sense xarxa totes les seves màquines virtuals. Això és aïllament manual, i tot i així descriu amb precisió l'error que es comet a les tres de la matinada: un nom en una llista no diu què hi ha a dins. És de la mateixa família que la redundància que no sobreviu al procediment.

El segon és per a qui vigila el directori. Contenir un usuari s'aplica a l'extrem i no deshabilita el compte al proveïdor d'identitat: bloqueja trànsit entrant en protocols d'atac —inicis de sessió de xarxa, RPC, SMB, RDP—, talla sessions remotes en curs i tanca les connexions RDP existents. La nota marcada com a important ve després: «Once a Contain user action is enforced on a domain controller, it starts a GPO update on the Default Domain Controller policy», i aquell canvi arrenca una sincronització entre els controladors de domini. Desfer l'acció reverteix la GPO i n'arrenca una altra. Qui monitoritzi canvis de GPO rebrà alertes de la resposta automàtica al mateix sistema amb què pensava investigar-la.

Tres palanques per excloure, i la que gairebé ningú toca

Aquí és on més gent s'equivoca d'eina, nosaltres inclosos la primera vegada. La pàgina d'exclusions ofereix exclusions de comptes d'usuari, de rangs d'IP i de grups de dispositius, i obre amb un avís de tipus CAUTION: «Excluding assets from automated responses isn't recommended». Però el selector de grups de dispositius no té dues posicions, en té cinc: Full, tres variants de Semi que continuen investigant automàticament i només demanen aprovació per remeiar, i No automated response. L'avís que excloure un grup «also impacts automated investigation and response actions» mossega de debò a l'últim graó.

I hi ha una tercera palanca, en vista prèvia, que gairebé ningú toca perquè viu en una altra pestanya del portal: policy applications and exclusions. Crees una etiqueta de dispositiu —amb regles dinàmiques per tipus d'equip, sistema operatiu o altres propietats—, crees una regla per a aquella etiqueta i desactives només els controls que vulguis. La documentació té una secció dedicada a excloure únicament l'acció Isolate device per a una etiqueta: la resta d'attack disruption continua funcionant, i quan el sistema identifica com a compromès un equip exclòs, l'acció apareix amb estat Skipped a l'Action center. L'objectiu declarat és «Keep most disruption controls active while selectively disabling specific protections».

La nostra recomanació, que va com a opinió i amb la font en contra a la vista: Microsoft suggereix «using automatic attack disruption exclusions to reduce the likelihood of isolating devices that can't tolerate interruption», i alhora desaconsella excloure en general. Les dues frases conviuen perquè parlen de granularitats diferents. Nosaltres preferim l'etiqueta i l'exclusió per acció abans que abaixar el nivell d'automatització d'un grup sencer: el primer camí es paga un cop, en configurar-lo, i el segon es paga en visibilitat tots els dies de l'any. I apagar-ho tot es demana per suport: cal obrir un cas al portal de Defender amb l'assumpte Attack disruption opt-out i explicar per què.

Set preguntes abans d'encendre-ho

Això és el que repassem nosaltres. Ordena el que la documentació de Microsoft té repartit, per poder contestar-ho en una reunió de mitja hora:

1. Quin nivell d'automatització té cada grup de dispositius, avui, mirant-ho? És a Settings > Microsoft Defender XDR > Automated responses > Devices, pestanya de grups. Ningú no recorda de memòria el que hi va deixar fa dos anys.
2. El parc fa servir PAC, WPAD o proxy estàtic? Si és que sí, la regla d'exclusió d'aïllament deixa de ser opcional per als llocs Windows.
3. Quants llocs Linux hi ha donats d'alta? Per a aquests, les exclusions d'aïllament no estan admeses i el pla ha de ser un altre.
4. La VPN és de túnel complet? Aleshores la decisió és anterior: túnel dividit per al trànsit de Defender, o assumir que l'equip aïllat no parla amb el núvol.
5. Si activem les exclusions d'aïllament, qui reescriu les regles de Teams i Outlook, i quan? La llista arrenca buida.
6. Quin percentatge del parc està realment donat d'alta, i què hi ha a la llista del que no? Aquí és on la contenció té forats, i aquesta llista gairebé mai no està escrita.
7. Qui pot alliberar un equip fora d'horari, i sap monitorització que una contenció d'usuari en un controlador de domini genera un canvi de GPO i la seva sincronització?

Les set són preguntes d'operació, i per això cauen entre les cadires: qui compra la llicència no les coneix i qui respon de matinada no era a la reunió de compra. És la mateixa escletxa que vam descriure parlant del pla de continuïtat que ningú ha assajat: el document existeix, la cadena de decisions no.

El que sí que diu el 99%

Microsoft publica una xifra sobre attack disruption i la publica clara: «For containment actions, Defender maintains a confidence level of 99% or higher based on real production data». És precisió del detector, mesurada com a relació senyal-soroll, i ve amb el detall que els detectors es validen primer en mode auditoria i es despleguen de manera gradual. Ens sembla un número honest i no tenim motiu per discutir-lo.

El que aquell 99% no diu és quantes vegades l'any es dispararà al teu parc. Aquesta taxa no la publica ningú, i tampoc no es dedueix de la precisió del detector: són dues coses que es mesuren diferent. Així que la discussió sobre si et refies del model, tingui la resposta que tingui, deixa intacta la pregunta que de debò costa diners el dia de l'incident: com torna la màquina, qui la retorna i amb quina regla escrita.

Ens agrada attack disruption i no farem veure el contrari per tenir un article més picant. En un ransomware, els minuts que triga una persona a assabentar-se'n, entendre-ho i actuar són els mateixos minuts que separen un equip compromès d'una carpeta xifrada. La funció fa bé la seva feina. El camp de qui té el rol un dissabte a les tres l'omples tu.

Si prefereixes començar pel bàsic, la porta d'entrada és la de sempre: saber què hi ha a la teva xarxa i què està realment protegit. D'això va la nostra pràctica de ciberseguretat, i cap resposta automàtica compensa no tenir-ho.

Nota de fonts

Cal separar dos grups de citacions. Primer, la frase del titular, que avui NO està publicada: el text «This issue can also occur when device isolation is triggered as full isolation by automatic attack disruption. To have automatic attack disruption use selective isolation, define an isolation exclusion rule» es va afegir al fitxer defender-endpoint/respond-machine-alerts.md del repositori públic MicrosoftDocs/defender-docs al commit f2685dde («Update respond-machine-alerts.md», 3 de setembre de 2026, 20:19 UTC) i no apareix al commit següent que toca aquell fitxer, 2f51dff1 («Resolve syncing conflicts from repo_sync_working_branch to public», 4 de setembre de 2026, 19:06 UTC); tampoc no és a la versió publicada avui, que hem descarregat i comprovat. Si el motiu va ser un descuit de sincronització o una decisió, no ho sabem, i ho diem així. Segon, tota la resta, que sí que està publicada avui i l'hem consultada el 15 de setembre de 2026 en aquest mateix repositori: el 99% i el mode auditoria, l'avís CAUTION sobre excloure actius, els cinc nivells d'automatització, l'advertiment sobre la investigació automatitzada, les policy applications and exclusions en vista prèvia i el procediment de baixa amb l'assumpte Attack disruption opt-out són a Automatic attack disruption in Microsoft Defender i a Exclude assets from automated response in attack disruption; la nota dels llocs d'usuari, la contenció d'actius crítics, el comportament de Contain device, els cinc minuts, els cent equips, els set dies de l'aïllament manual, els cinc dies de contenció d'usuari, l'script de tres dies, el comportament d'iptables a Linux, la VPN de túnel complet, l'efecte sobre les màquines virtuals d'un amfitrió Hyper-V, la nota de la GPO, la no compatibilitat d'exclusions a macOS i Linux, la nota de l'aïllament selectiu per defecte i l'exclusió de l'acció Isolate device per etiqueta són a Take response actions on a device in Microsoft Defender for Endpoint; els dos modes d'aïllament, la ruta de les regles, el buidatge de les exclusions de Teams, Outlook i Skype i la limitació que els canvis només afecten noves peticions són a Network isolation exclusions in Microsoft Defender for Endpoint; i la marca de vista prèvia de l'aïllament automàtic apareix tant a Take response actions on a device in Microsoft Defender for Endpoint com a Configure automatic attack disruption in Microsoft Defender XDR. El que en aquest article és deducció nostra va marcat com a tal: que allò que no està donat d'alta continua parlant amb un equip contingut, i la preferència per l'exclusió per etiqueta enfront d'abaixar el nivell d'un grup. No hem trobat cap xifra publicada sobre amb quina freqüència es dispara attack disruption en un parc, i per això no en donem cap.