Che cosa fa davvero una regola ASR

Le attack surface reduction rules sono un componente di Microsoft Defender for Endpoint che interviene su comportamenti, non su file: un documento di Office che genera un processo figlio, uno script offuscato che parte, contenuto eseguibile scaricato da un client di posta, l’accesso in lettura a lsass per il furto di credenziali, la persistenza tramite WMI event subscription. Non sono firme antimalware e non sono personalizzabili: l’elenco delle regole è predefinito da Microsoft e ciascuna è identificata da un GUID.

Per un security operations analyst questo cambia la natura del rischio. Una regola ASR non “trova malware”: riduce lo spazio in cui una tecnica può funzionare. Il problema non è quindi il falso positivo classico, ma l’applicazione legittima che usa lo stesso comportamento dell’attaccante — la macro che lancia un eseguibile, il tool di deployment che crea processi via PsExec o WMI, l’installer firmato che scrive in cartelle di sistema. Bloccare senza misurare significa fermare la produzione.

Le regole si distribuiscono come policy di endpoint security (tipicamente da Intune, in alternativa GPO, Configuration Manager o PowerShell) e convivono con gli altri controlli di attack surface reduction — network protection, controlled folder access, exploit protection, device control — che le domande d’esame mescolano volentieri nello stesso scenario.

Le quattro modalità e cosa producono

Block applica: il comportamento viene impedito e viene generato l’evento corrispondente.

Audit valuta e registra ciò che la regola avrebbe bloccato, senza bloccare nulla e senza mostrare alcun messaggio all’utente. È l’unica modalità pensata per misurare l’impatto prima di decidere.

Warn blocca, avvisa l’utente e gli lascia la possibilità di sbloccare e proseguire per un intervallo di tempo limitato sul dispositivo. È quindi già visibile e già interferente: non è “un audit più morbido”, è un Block con via d’uscita. Va inoltre ricordato che non tutte le regole supportano Warn: dove non è supportato, la configurazione si comporta come Block.

Disabled / Not configured non applica nulla e, punto decisivo, non produce telemetria ASR: da un endpoint con la regola disabilitata non arriva alcun segnale utilizzabile in advanced hunting.

Il percorso tipico: Audit → analisi → esclusioni → Block

Il metodo che l’esame considera corretto è sequenziale. Si abilita la regola in Audit su un anello pilota rappresentativo e la si lascia per almeno un ciclo di business completo — chiusure mensili, backup, script stagionali producono comportamenti che una settimana di osservazione non intercetta.

Poi si analizza. Gli eventi ASR confluiscono nella telemetria di dispositivo di advanced hunting, dove il campo ActionType distingue le occorrenze Audited da quelle Blocked; per ricostruire la catena si correla con DeviceProcessEvents (processo padre, riga di comando, firma) e DeviceFileEvents. Nel portale Microsoft Defender XDR il report dedicato alle regole ASR aggrega le stesse detection per regola, dispositivo e applicazione: serve a stimare il volume, l’hunting serve a capire chi e perché.

Solo a questo punto si definiscono esclusioni mirate, preferendo quelle per singola regola a quelle globali: un’esclusione globale riapre la superficie su tutte le regole configurate. Alcune regole, inoltre, non supportano esclusioni file/cartella — la reference ufficiale lo indica regola per regola, e va verificata invece che dedotta. Infine si passa a Block, per anelli successivi, mantenendo l’audit sugli anelli non ancora convertiti.

Attenzione al prerequisito che invalida tutto il ragionamento: le regole ASR richiedono Microsoft Defender Antivirus come antivirus primario in active mode con real-time protection attiva (alcune regole si appoggiano anche alla cloud-delivered protection). Con un antivirus di terze parti primario e Defender in passive mode, le regole semplicemente non si applicano.

Trappole tipiche d’esame

  • Misurare l’impatto senza che gli utenti se ne accorgano → Audit: è l’unica modalità che registra e non blocca. Warn è un distrattore ricorrente perché “sembra” intermedio, ma blocca e si vede.
  • Consentire un’eccezione occasionale mantenendo il blocco come default → Warn: ha senso solo per comportamenti raramente legittimi; verifica che la regola scelta supporti Warn, altrimenti degrada a Block.
  • Silenziare il rumore di una regola → Disabled solo se accetti di perdere la visibilità: disabilitando non arriva più nessun evento ASR. Se il segnale serve ancora per l’hunting, la risposta è Audit, non Disabled.
  • Un’applicazione line-of-business viene bloccata da una regola → esclusione mirata, non disabilitazione: disabilitare la regola per l’intero tenant per salvare un’app è la risposta sbagliata; l’esclusione per regola (o l’anello dedicato) è quella giusta.
  • Antivirus di terze parti in uso, le regole “non funzionano” → Defender Antivirus in passive mode: non è un problema di policy né di licenza, è il prerequisito di active mode con real-time protection.
  • Serve rilevare un comportamento non coperto dalle regole predefinite → custom detection rule: l’elenco ASR non è estendibile; il rilevamento personalizzato nasce da una query di Advanced Hunting promossa a custom detection rule in Microsoft Defender XDR.