Che cosa vuol dire “configurare” per un analista

Configurare Microsoft Defender for Endpoint, nel ruolo di security operations analyst, non è fare l’onboarding dei sensori: è decidere tre cose. Quali capacità del prodotto sono attive (advanced features), quali eccezioni, indicatori e raccolte dati modificano il comportamento di default (rules settings e data collection), e infine chi vede quali macchine e con quanta autonomia agisce l’automazione su di esse (device group). Le prime due famiglie di impostazioni sono di tenant e valgono per tutti; la terza è l’unica leva che consente di trattare in modo diverso un domain controller e un portatile di sala riunioni. Tutte vivono nella sezione endpoint del portale unificato Microsoft Defender XDR, accanto alle impostazioni degli altri workload.

Advanced features: ogni interruttore è un trade-off

Le advanced features abilitano capacità che ampliano l’indagine ma anche la superficie di rischio, e per questo l’esame le presenta quasi sempre come scelte condizionate. Live response dà all’analista una shell remota sul dispositivo: esiste come toggle separato per i server e come ulteriore toggle per l’esecuzione di script non firmati, perché sono decisioni di rischio distinte. EDR in block mode serve quando Microsoft Defender Antivirus è in passive mode perché c’è un AV di terze parti: consente il blocco post-breach di ciò che l’AV primario ha lasciato passare. I custom network indicators funzionano solo se network protection è attiva, e la capacità di allow/block di un file richiede Microsoft Defender Antivirus in modalità attiva con cloud-delivered protection e sample submission: sono dipendenze, non dettagli. Tamper protection protegge le impostazioni del sensore dalla manomissione. Le integrazioni (Defender for Cloud Apps, Defender for Identity, Microsoft Defender for Cloud, Intune) arricchiscono la correlazione cross-workload e alimentano scenari di device compliance. Infine, restrict correlation to within scoped device groups limita la correlazione degli alert al perimetro di un device group: utile per SOC regionali o MSSP, dannoso se serve una vista globale dell’attacco.

Rules settings e custom data collection

I rules settings sono il posto dove l’analista interviene senza cambiare policy di sicurezza aziendali. Gli indicators (hash di file, IP/URL/dominio, certificati) applicano azioni di allow, audit o block-and-remediate e possono essere scopati a specifici device group: un indicator agisce, mentre una custom detection rule rileva. Le alert suppression rule riducono rumore noto e vanno scopate (dispositivo singolo o gruppo) invece che applicate a tutto il tenant. Il web content filtering ragiona per categorie. Le esclusioni relative all’automated investigation (cartelle e tipi di file caricati per l’analisi) evitano che processi legittimi vengano rimediati o che contenuti sensibili lascino l’endpoint.

Sul fronte della custom data collection, le decisioni riguardano cosa viene raccolto oltre al minimo: sample collection, modalità di device discovery (basic vs standard) per far emergere i dispositivi non gestiti, e l’export dei raw event verso storage o Microsoft Sentinel quando serve conservarli oltre la retention del portale — è lì, e non nelle impostazioni di Defender for Endpoint, che si risolvono i requisiti di conservazione a lungo termine, oggi anche tramite Sentinel Data lake.

Device group: scoping dei permessi e livello di automazione

Un device group si definisce con regole di appartenenza (nome, dominio, sistema operativo, tag) e ha un rank: la prima regola che corrisponde vince, e i dispositivi che non corrispondono a nulla finiscono nel gruppo di default degli ungrouped devices, valutato per ultimo. A ogni gruppo si assegnano i gruppi di Microsoft Entra ID che possono vederlo e agirci — è così che si costruisce il least privilege nel SOC — e il livello di automazione: full (remediation automatica), le varianti semi che richiedono approvazione (per tutte le remediation, per le core folder o per le cartelle non temporanee) e “no automated response”. Le azioni in attesa si approvano nell’Action center. Il punto chiave: essendo l’automazione una proprietà del gruppo, i server critici possono restare in semi-automatico mentre le workstation vengono rimediate da sole.

Trappole tipiche d’esame

  • Server critici che non devono essere rimediati senza approvazione → device group dedicato con automation level semi: il livello di automazione si imposta per gruppo, non per tenant; abbassarlo globalmente per proteggere i server rallenta anche le workstation.
  • Il team regionale deve vedere solo le proprie macchine → device group + gruppo Entra ID assegnato: ricorda che attivare l’RBAC di Defender for Endpoint toglie l’accesso a chi lo aveva come read-only globale finché non riceve un ruolo esplicito.
  • Bloccare un hash o un IP noto-malevolo → indicator, non custom detection rule: la custom detection rule genera un alert a partire da una query di advanced hunting; l’indicator applica l’azione di blocco.
  • Misurare l’impatto di una regola prima di bloccare → modalità Audit delle attack surface reduction rule: Block impedisce subito, Warn chiede all’utente, Disabled non fa nulla; solo Audit produce telemetria senza rompere i processi di business.
  • AV di terze parti in passive mode e serve comunque il blocco post-breach → EDR in block mode: non basta l’onboarding del sensore, va accesa la advanced feature.
  • Alert ricorrente e benigno da un’app interna → suppression rule scopata al device group interessato: disattivare la feature o escludere una cartella intera dall’automated investigation crea un buco molto più ampio del rumore che si voleva togliere.
  • Conservare la telemetria endpoint oltre la retention del portale → export verso Microsoft Sentinel: le impostazioni di Defender for Endpoint non sono la sede della retention di lungo periodo.