Microsoft Defender for Endpoint (MDE) è la componente di endpoint protection ed EDR di Microsoft Defender XDR. Nell’esame MS-102 non ti viene chiesto di configurarlo a mano riga per riga: ti viene chiesto di scegliere il metodo di onboarding giusto per il parco macchine descritto e la policy giusta per il requisito descritto.

Metodi di onboarding a confronto

Il pacchetto di onboarding si scarica dal portale Microsoft Defender in Settings > Endpoints > Onboarding, scegliendo il sistema operativo e il metodo di deployment.

Metodo Scenario tipico Limiti da ricordare
Microsoft Intune Client Windows già enrolled in Intune / co-managed Richiede la connessione MDE–Intune attiva; è il metodo raccomandato per dispositivi cloud-managed
Script locale Test, pilot, pochi dispositivi Supportato fino a 10 dispositivi; non usarlo per deployment di produzione
Criteri di gruppo (GPO) Dispositivi joined al dominio Active Directory on-premises, non gestiti da Intune Nessuna gestione centralizzata delle policy di sicurezza da Intune
Configuration Manager Estate ibrido gestito da MECM Onboarding via policy Client Settings / Endpoint Protection
Script VDI Sessioni non persistenti Script dedicato, non quello locale standard

Per Windows Server e per macOS/Linux/iOS/Android esistono pacchetti dedicati (per i server anche l’onboarding tramite Defender for Cloud / Azure Arc).

Sequenza corretta per client Windows già gestiti da Intune

  1. Attiva la connessione servizio-a-servizio: nel portale Defender, Settings > Endpoints > Advanced features > Microsoft Intune connection → On.
  2. Nell’interfaccia di amministrazione Intune, Endpoint security > Microsoft Defender for Endpoint: verifica lo stato Connected e imposta Allow Microsoft Defender for Endpoint to enforce Endpoint Security Configurations su On.
  3. Crea una policy Endpoint detection and response (Endpoint security > Endpoint detection and response) con Microsoft Defender for Endpoint client configuration package type = Auto from connector e assegnala ai gruppi di dispositivi.
  4. Solo dopo, crea le policy di superficie d’attacco (ASR, network protection) e antivirus.

Il punto chiave: senza la connessione attivata prima, il blob di onboarding “Auto from connector” non è disponibile e la policy fallisce.

Le policy che devi saper mappare al requisito

  • Attack surface reduction (ASR) rules — bloccano comportamenti (macro Office che creano processi figli, esecuzione di script offuscati, furto di credenziali da LSASS, eseguibili da client di posta/webmail). Stati: Not configured / Audit / Block / Warn / Disabled. Richiedono Microsoft Defender Antivirus come AV primario con real-time protection attiva.
  • Network protection — blocca connessioni a domini e IP a bassa reputazione, incluse le connessioni da browser e da qualsiasi processo. Anch’essa ha modalità Audit e Block, e richiede protezione in tempo reale + cloud-delivered protection.
  • EDR in block mode — permette a MDE di rimediare artefatti rilevati post-breach anche quando Defender Antivirus è in modalità passiva (cioè quando c’è un antivirus di terze parti come AV primario). Si attiva in Settings > Endpoints > Advanced features.
  • Automated investigation and response (AIR) — indaga automaticamente gli alert e propone/applica remediation. I livelli di automazione si impostano per device group: Full – remediate threats automatically, Semi – require approval (for any/core folders/non-temp folders), No automated response.
  • Device group — in Settings > Endpoints > Device groups. Ogni gruppo ha regole di appartenenza (tag, dominio, OS, nome), un livello di remediation e i gruppi Microsoft Entra ID che possono accedervi. I gruppi sono ordinati per rank: vale la prima regola che corrisponde, e un dispositivo appartiene a un solo gruppo. Il fallback è il gruppo Ungrouped devices, sempre ultimo.

I device tag si assegnano dal portale, via Intune, o via registro (HKLM\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection\DeviceTagging\Group), e sono il criterio più usato per pilotare l’appartenenza ai gruppi.

Trappole tipiche d’esame

  • Scenario: “Abbiamo distribuito le regole ASR ma gli eseguibili malevoli girano ancora.” → Le regole sono in Audit: l’audit registra soltanto nell’Event Viewer e in Advanced Hunting, non blocca nulla. Serve impostarle su Block.
  • Scenario: “Il gruppo Server-EU deve avere remediation completamente automatica, i client PoC solo semi-automatica.” → Non è una policy Intune: si configura il livello di automazione sul device group, e l’appartenenza al gruppo è determinata dal tag del dispositivo e dal rank della regola.
  • Scenario: “Un analista deve poter approvare le azioni di remediation pendenti nell’Action center.” → Non basta la sola visibilità: serve un ruolo Defender/Defender XDR con il permesso Active remediation actions (o Security Administrator / Global Administrator). Chi ha solo View data può vedere ma non approvare.
  • Scenario: “Abbiamo un antivirus di terze parti e vogliamo comunque che MDE rimuova i file malevoli rilevati.” → EDR in block mode, che opera con Defender Antivirus in modalità passiva. Le regole ASR, invece, non funzionano in quello scenario.
  • Scenario: “Onboarding di 400 client Windows non ancora gestiti da Intune ma joined al dominio.” → Criteri di gruppo (o Configuration Manager). Lo script locale è supportato fino a 10 dispositivi ed è la risposta sbagliata classica.