L’esame SC-100 non chiede di configurare i prodotti, ma di giustificare le scelte architetturali: dato un requisito di detection & response, quale combinazione di Microsoft Defender XDR e Microsoft Sentinel raccomandi, e perché. La chiave è ragionare in termini di unified SecOps, l’esperienza convergente nel Microsoft Defender portal che oggi ospita sia gli incidenti XDR sia le funzionalità SIEM di Sentinel in un unico pane-of-glass.

Il principio di design: XDR come motore, SIEM come tetto

Il pattern raccomandato per un tenant Microsoft-centrico è preciso: Microsoft Defender XDR è la sorgente primaria degli incidenti sui carichi coperti nativamente — identità (Defender for Identity), endpoint (Defender for Endpoint), email e collaboration (Defender for Office 365), SaaS (Defender for Cloud Apps) e workload cloud (Defender for Cloud). La correlazione cross-domain avviene nativamente dentro XDR, che unisce alert eterogenei in un singolo incident già arricchito e con automatic attack disruption.

Microsoft Sentinel entra come pane-of-glass unificato per ciò che XDR da solo non copre: log di firewall, apparati di rete, applicazioni custom, workload multi-cloud (AWS, GCP), sorgenti on-prem e SaaS di terze parti tramite data connector e Codeless Connector Platform. Sentinel aggiunge inoltre long-term retention, hunting su larga scala, UEBA e orchestrazione SOAR.

La decisione architetturale centrale è come farli convivere senza duplicare.

Trade-off: correlazione nativa XDR vs regole custom in Sentinel

Ecco il cuore del disegno.

  • Correlazione nativa XDR — Alta fedeltà, bassissimo tuning, incident già pronti per l’analista, attack disruption automatica. Limite: opera solo sui segnali dei prodotti Defender. Non conosce il tuo firewall Palo Alto o la tua app line-of-business.
  • Analytics rules custom in Sentinel — Flessibilità totale via KQL, correlazione tra sorgenti eterogenee, arricchimento con threat intelligence e watchlist. Costo: manutenzione, rischio di false positive e di alert fatigue se le regole sono ridondanti rispetto a XDR.

Raccomandazione di design: non riscrivere in Sentinel logica che XDR fa già meglio nativamente. Usa le regole custom per colmare i gap di copertura, non per replicare detection già presenti. Questo tiene basso il rumore e rispetta il pilastro Operational Excellence dell’Azure Well-Architected Framework: processi ripetibili, meno toil per l’analista.

La trappola della duplicazione degli alert

È lo scenario che l’esame ama nascondere. Quando connetti Sentinel a Defender XDR abilitando il connettore Microsoft Defender XDR, ingerisci gli incident XDR insieme ai singoli alert dei prodotti sottostanti. Se poi qualcuno abilita anche i connettori legacy per-prodotto (es. il vecchio connettore MDE) o scrive Scheduled Analytics rules che matchano gli stessi eventi, ottieni lo stesso alert due o tre volte, con incident sdoppiati e code SOC gonfiate artificialmente.

Design corretto:

  • Abilita un solo connettore, quello unificato Microsoft Defender XDR, e lascia che l’incident bi-directional sync mantenga stato e ownership allineati tra portale Defender e Sentinel.
  • Evita i connettori per-prodotto ridondanti quando il connettore XDR unificato già streamma quegli alert.
  • Onboarda Sentinel nel Defender portal per la unified SecOps experience: gli incident vivono in un solo posto, l’analista non fa context-switching.

Sul piano Cost Optimization del Well-Architected Framework, la duplicazione ha anche un impatto economico diretto: alert e log ridondanti significano ingestion cost più alti. Usa Auxiliary/Data Lake tier per i log verbosi ad alto volume ma bassa fedeltà investigativa, riservando l’Analytics tier ai dati su cui giri detection attive.

Sintesi decisionale

Dato un tenant misto: XDR come sistema di detection & response autoritativo sui domini Microsoft, Sentinel come SIEM di aggregazione, retention e correlazione sulle sorgenti non-Microsoft, un unico connettore unificato, e regole custom solo dove esiste un gap reale. Questo massimizza Security e Reliability minimizzando rumore e costo.

Trappole tipiche d’esame

  • Requisito: ridurre alert fatigue in un SOC con incident duplicati tra i due sistemi → Consolida su unified SecOps nel Defender portal con il solo connettore Microsoft Defender XDR e bi-directional sync; rimuovi connettori per-prodotto e analytics rules ridondanti.
  • Requisito: unico pane-of-glass su Microsoft + firewall di terze parti + AWS → Sentinel come SIEM unificante con data connector per le sorgenti esterne, alimentato dagli incident XDR; non tentare di far coprire il non-Microsoft a Defender XDR.
  • Requisito: response automatica su ransomware sugli endpoint senza scrivere playbook → Automatic attack disruption di Defender XDR (nativa), non una Sentinel automation rule custom.
  • Requisito: retention dei log di sicurezza a 2 anni a costo contenuto → Sentinel con Data Lake/Auxiliary tier per l’archiviazione lunga; XDR non è un archivio di retention.
  • Requisito: correlare un’app custom con i segnali di identità → Analytics rule KQL in Sentinel che unisce i log dell’app agli alert XDR ingeriti; è il caso legittimo di regola custom, non una riscrittura di detection già native.