Microsoft AZ-500: Microsoft Sentinel e operazioni di sicurezza — Guida allo studio

By Laurynas Brazys · 11 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

Fa parte della Microsoft Azure Security Engineer Associate AZ-500 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Panoramica

Microsoft Sentinel è la piattaforma SIEM e SOAR cloud-native di Azure, basata su Azure Monitor Log Analytics. Centralizza la telemetria di sicurezza, applica l’analisi per rilevare le minacce, genera incident per il triage da parte degli analisti e orchestra la risposta automatizzata con Logic Apps. L’efficacia operativa dipende da un’architettura delle aree di lavoro ben progettata, un inserimento dei dati ponderato, una conservazione attenta ai costi, un’analisi e una mappatura delle entità precise, e un regime di automazione e ottimizzazione che allinei gli avvisi ai flussi di lavoro del SOC e al rischio aziendale.

Architettura e Gestione dei Dati di Sentinel

• Aree di lavoro e considerazioni multi-tenant

  • Sentinel opera per singola area di lavoro Log Analytics. Scegliere i confini dell’area di lavoro in base alla sovranità dei dati, alla latenza e all’isolamento amministrativo. Un’unica area di lavoro “SOC centrale” semplifica la correlazione e la gestione dei contenuti; più aree di lavoro possono essere appropriate per requisiti di residenza dei dati stringenti, autonomia o modelli MSSP/Lighthouse. Le query tra aree di lavoro diverse sono supportate ma aggiungono latenza e costi; preferire il consolidamento quando la correlazione tra entità è critica.
  • Utilizzare l’RBAC basato sul contesto delle risorse sull’area di lavoro per separare i compiti: Sentinel Reader per le dashboard, Responder per la gestione degli incident, Contributor per la gestione dei contenuti e Automation Contributor per i playbook.

• Percorsi di inserimento

  • I dati entrano nelle tabelle dell’area di lavoro tramite connettori nativi, agenti di Azure Monitor o API. Preferire i connettori nativi per le origini Microsoft (schema ottimizzato, affidabilità) e l’accoppiata AMA+DCR per Windows/Syslog per ottenere il filtraggio e il controllo del piano per singola tabella. Per i dispositivi di terze parti, instradare il formato CEF su Syslog verso la tabella CommonSecurityLog per beneficiare dei parser e dei contenuti di analisi integrati.

• Conservazione, archiviazione e ricerca

  • Configurare la conservazione per singola tabella per mantenere i dati “hot” (analisi interattiva) per la finestra di rilevamento operativo (comunemente 30-120 giorni). Archiviare i dati più vecchi nel livello Archive di Log Analytics fino a 7 anni per soddisfare la conformità a un costo drasticamente inferiore; utilizzare Search Jobs o Restore per le indagini. Ragionamento operativo: conservare solo ciò su cui gli analisti fanno regolarmente perno; archiviare il resto per soddisfare i requisiti di audit/normativi senza gonfiare la spesa per i dati “hot-path”.

• Controlli dei costi

  • I piani di impegno (prenotazioni di capacità) riducono in modo prevedibile i costi di inserimento per volumi costanti; abilitarli dopo aver stabilito una baseline di 30-60 giorni per evitare un impegno eccessivo.
  • Piani di fatturazione a livello di tabella: utilizzare la modalità Analytics per le tabelle critiche per la sicurezza (SecurityEvent, SignInLogs, CommonSecurityLog). Utilizzare i Log di base (Basic Logs) per la diagnostica verbosa e di basso valore che si interroga raramente; non inserire mai tabelle di sicurezza ad alto segnale in modalità Basic perché perdono le funzionalità di query complete e non sono idonee per gli avvisi.
  • Le trasformazioni al momento dell’inserimento con le DCR eliminano o mascherano campi e righe (minimizzazione delle PII, riduzione del rumore) prima della fatturazione. Operativamente, eliminare il rumore prima dell’inserimento è il controllo più potente su costi e fedeltà dei dati.
  • Impostare limiti giornalieri per l’area di lavoro e avvisi su picchi anomali per intercettare configurazioni errate o attacchi che generano tempeste di log.

Connettori di Dati e Inserimento

• Azure Activity

  • Utilizzare il connettore Azure Activity per inviare in streaming le operazioni del piano di controllo a livello di sottoscrizione nella tabella AzureActivity tramite le impostazioni di diagnostica (Diagnostic settings). Ragionamento: cattura le modifiche ai ruoli, gli aggiornamenti delle policy e le distribuzioni, indicatori primari di escalation dei privilegi o manomissione da parte di un utente malintenzionato.

• Microsoft Entra ID (Azure AD)

  • Abilitare i connettori AuditLogs e SignInLogs. Opzionalmente, inserire i log arricchiti di Azure AD (Enriched Azure AD logs) se si possiede la licenza. Ragionamento: l’identità è la principale superficie di attacco; le anomalie di accesso e le modifiche alla directory sono alla base della maggior parte dei rilevamenti e dell’UEBA.

• Prodotti Microsoft Defender

  • I connettori di Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps e Defender for Cloud importano avvisi e telemetria ad alta fedeltà. Ragionamento: gli avvisi di sicurezza Microsoft sono profondamente correlati e aumentano la qualità degli incident; inserirli per alimentare Fusion e le regole di sicurezza Microsoft con un’ottimizzazione minima.

• Eventi di Windows

  • Utilizzare l’Azure Monitor Agent (AMA) con una DCR: eventi di sicurezza di Windows (Windows Security Events) nella tabella SecurityEvent (livello Common, Minimal o All) per i DC e i server critici; canali generici di eventi di Windows (Windows Event) nella tabella WindowsEvent secondo necessità. Ragionamento: la tabella SecurityEvent è la spina dorsale per l’auditing dell’autenticazione e dei processi; il filtraggio tramite DCR riduce il rumore (ad es. escludere l’evento 4688 senza CommandLine).

• Syslog e CEF

  • Per Linux, una DCR per Syslog con AMA seleziona facility e livelli di severità da inviare alla tabella Syslog. Per firewall/IDS/EDR di terze parti, inoltrare il formato CEF al forwarder basato su agente di Log Analytics o tramite l’inserimento basato su AMA che popola la tabella CommonSecurityLog; utilizzare i contenuti del parser del fornitore. Ragionamento: il formato CEF mantiene i campi normalizzati e riduce l’onere di parsing; la tabella CommonSecurityLog sblocca i rilevamenti preconfigurati.

• Igiene operativa

  • Sincronizzazione dell’ora (NTP) e fusi orari coerenti sui dispositivi per una correlazione accurata.
  • Deduplicare le origini sovrapposte (ad es. non inserire sia i duplicati grezzi che quelli normalizzati).
  • Convalidare lo schema con le Watchlist o query di esempio prima di abilitare le regole di analisi per evitare falsi positivi.

Analisi, Rilevamento e Indagine

• Tipi di regole di analisi

  • Regole pianificate: KQL su dati storici a una cadenza definita (es. ogni 5 minuti, con un periodo di analisi retroattiva di 1 ora). Da usare per la maggior parte dei rilevamenti; ottimizzare il periodo di analisi retroattiva affinché superi la latenza tipica dei dati per evitare mancate rilevazioni.
  • Near-real-time (NRT): rilevamento in meno di un minuto con KQL limitato e un breve periodo di analisi retroattiva fisso. Usare con parsimonia per pattern ad alta urgenza dove i secondi contano (es. assegnazione massiva di ruoli). Operare con join minimi e filtri semplici per ottimizzare le prestazioni.
  • Fusion: correlazione multi-stadio basata su ML tra i segnali Microsoft (Defender, Entra, Cloud Apps). Logica: riduce drasticamente l’affaticamento da alert producendo un singolo incident per una kill chain di un attacco.
  • Regole di anomalia: baseline di utenti/entità con soglie dinamiche. Forniscono risultati rapidi per pattern insoliti di geolocalizzazione, volume o processi; mantenere liste di esclusione per anomalie autorizzate (es. finestre di manutenzione).
  • Regole di sicurezza Microsoft: creano automaticamente incident dagli alert di Defender. Mantenerle abilitate e regolare le regole di automazione per l’instradamento/severità; forniscono segnali ad alta affidabilità con un basso overhead di ottimizzazione.

• Mappatura delle entità e incident

  • Mappare le colonne di output KQL alle entità (Account, Host, IP, URL, File) nella configurazione della regola per alimentare i grafi degli incident e UEBA. Una mappatura scadente degrada la fedeltà dell’indagine.
  • La policy di raggruppamento degli alert influenza il volume e il contesto degli incident. Raggruppare per entità/finestra temporale per combinare alert correlati, riducendo il rumore di fondo e preservando il filo conduttore degli eventi.

• Indagine e UEBA

  • Gli incident presentano la timeline, le prove e le entità correlate; il grafo di indagine costruisce automaticamente le relazioni partendo dalla mappatura delle entità e dalle ricerche sui dati.
  • Abilitare UEBA per arricchire le entità con baseline dei peer, ruoli dei dispositivi e segnali di rischio. Logica: il contesto riduce i tempi di triage e definisce l’ambito della risposta.

• Fondamenti di KQL per il detection engineering

  • Filtraggio e proiezione

    SignInLogs
    | where TimeGenerated > ago(24h) and ResultType != 0
    | project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ResultType
    ```

  - Parsing e normalizzazione

CommonSecurityLog
| extend Url = extract(@"request=([^;\s]+)", 1, AdditionalExtensions)
| parse DeviceCustomString1 with * "cmd=" CommandLine
```

• Join

    SecurityEvent
    | where EventID == 4624 and AccountType == "User"
    | summarize logons = count() by Account, bin(TimeGenerated, 1h)
    | join kind=inner (
        SignInLogs
        | summarize aad_logons = count() by UserPrincipalName, bin(TimeGenerated, 1h)
    ) on $left.Account == $right.UserPrincipalName, TimeGenerated
    ```

  - Aggregazione e analisi su finestre temporali

SignInLogs
| where TimeGenerated between (ago(1d) .. now())
| summarize attempts = count(), byIP = dcount(IPAddress) by UserPrincipalName
| where attempts > 50 or byIP > 10
```

Ricerca delle minacce (Hunting), Automazione, Threat Intelligence, Reporting e Ottimizzazione del SOC

• Flusso di lavoro per la ricerca delle minacce (threat hunting)

  • Query di ricerca (hunting): Iniziare dai modelli di Sentinel; evolverle con whitelist specifiche dell’ambiente. Salvare le piste promettenti come query personalizzate per il riutilizzo.
  • Segnalibri (Bookmark): Catturano prove e punti di snodo (pivot) durante le ricerche; in seguito, vengono allegati agli incident per conservare il contesto dell’analista.
  • Livestream: Eseguire un filtro KQL in modo continuo per individuare gli eventi non appena si verificano; ideale durante gli incident attivi per confermare il contenimento.
  • Watchlist: Caricare set di autorizzazione/negazione/priorità basati su CSV (utenti VIP, IP sanzionati, livelli di asset). Fare riferimento con la funzione _GetWatchlist per l’arricchimento e la soppressione.

• Regole di automazione e playbook

  • Le regole di automazione effettuano il triage alla creazione dell’incident/alert: impostano la gravità, assegnano un proprietario, aggiungono tag, chiudono con una classificazione o attivano i playbook in base a condizioni (nome della regola, tattiche, entità).
  • I playbook (Logic Apps) implementano il SOAR: arricchiscono con VirusTotal/MDTI, notificano in Teams, aprono ticket (ServiceNow/Jira), isolano gli endpoint (MDE) o disabilitano gli account (Entra). Utilizzare identità gestite e RBAC con privilegi minimi (ruolo Sentinel Responder sul workspace; ruoli con ambito limitato per i sistemi di destinazione). Motivazione: azioni codificate e ripetibili riducono l’MTTR e gli errori manuali.

• Threat intelligence (TI)

  • Ingerire indicatori di TI utilizzando i provider integrati, il caricamento manuale, l’automazione di GitHub o i collettori TAXII (STIX 2.0/2.1). Normalizzare i campi (tipo di indicatore, pattern, confidenza, TLP) e impostare una scadenza per prevenire corrispondenze obsolete.
  • Corrispondenza degli indicatori: abilitare le regole di analisi basate su TI per confrontare IP/domini/URL/hash con la telemetria (CommonSecurityLog, DNS, Proxy, SignInLogs). Utilizzare soglie di confidenza ed eccezioni tramite watchlist per ridurre il rumore. Motivazione: la TI restringe lo spazio di ricerca agli elementi noti come malevoli, ma deve essere curata per evitare falsi positivi.

• Workbook e reporting

  • Costruire dashboard operative con Azure Monitor Workbooks. Parametrizzare per sottoscrizione, workspace o intervallo di tempo; aggregare i dati in anticipo (summarize, make-series) per mantenere le query efficienti.
  • Fornire viste a più livelli: postura a livello dirigenziale (incident per gravità/SLA), operazioni del SOC (aperti vs. chiusi, invecchiamento della coda, carico degli analisti), stato dei rilevamenti (stato dei connettori, latenza dei dati) e copertura dei controlli (mappatura MITRE). Motivazione: viste specifiche per ruolo supportano il processo decisionale senza sommergere gli utenti di eventi grezzi.

• Ottimizzazione e procedure del SOC

  • Riduzione dei falsi positivi: affinare i predicati KQL, aggiungere baseline (soglie dinamiche), sfruttare le allowlist di entità (watchlist) ed escludere le sorgenti benigne. Convalidare ogni soppressione con un controllo di compensazione.
  • Normalizzazione della gravità: mappare la gravità della regola all’impatto e alla confidenza, non alla frequenza. ‘High’ (Alta) dovrebbe implicare una chiamata in reperibilità; ‘Medium’ (Media) un triage tempestivo; ‘Low’ (Bassa) una ricerca nel backlog.
  • Escalation e passaggio di consegne: definire stati degli incident, proprietari e SLA; arricchire e instradare automaticamente alla coda corretta; aprire ticket ITSM tramite playbook con aggiornamenti bidirezionali. Documentare i passaggi di contenimento per ogni tattica (disabilitare l’utente, isolare l’endpoint, revocare i token, bloccare gli indicatori).

Scenario pratico

Contoso Ltd. sperimenta un eccesso di alert (alert fatigue) e una risposta lenta dopo aver integrato più origini dati in Microsoft Sentinel. Gli incident sono numerosi, raggruppati in modo inefficiente e privi di automazione. Il CISO impone una riduzione del 50% del tempo medio di risposta (MTTR) senza perdere la fedeltà dei rilevamenti.

1. Riprogettare l’ingestione dei dati con filtri DCR e piani per le tabelle

• Azione: Spostare i Windows Security Events su AMA+DCR con il preset “Common” sui DC; passare le tabelle di diagnostica verbose ai Basic Logs; abilitare la conservazione ‘hot’ per 90 giorni e l’archivio per 1 anno.
• Motivazione: Riduce il rumore e i costi del percorso ‘hot’ preservando i dati di sicurezza utilizzabili, liberando cicli di analisi e budget per rilevamenti a più alta fedeltà.

2. Abilitare i connettori Microsoft Defender e Fusion

• Azione: Connettere MDE, MDI, MDO, MDC e Cloud Apps; assicurarsi che le analisi di sicurezza Microsoft e Fusion siano attivi.
• Motivazione: Gli alert ad alta confidenza e la correlazione tramite ML uniscono gli alert duplicati in un unico incident ricco di informazioni, riducendo l’onere del triage.

3. Standardizzare la mappatura delle entità e il raggruppamento degli alert

• Azione: Aggiornare le regole pianificate per mappare Account, Host, IP e URL; configurare il raggruppamento per Account e una finestra di 4 ore per gli alert correlati.
• Motivazione: Una mappatura corretta alimenta i grafici di investigazione e l’UEBA; il raggruppamento riduce il volume degli incident preservando il contesto per le catene di attacco.

4. Implementare regole di automazione per il triage e playbook mirati

• Azione: Creare regole di automazione per aggiungere tag automatici per tattica, impostare la gravità in base alla confidenza, assegnare alle code e attivare i playbook: arricchire gli indicatori (MDTI), aprire ticket su ServiceNow, isolare i dispositivi (MDE) e sospendere gli utenti a rischio (Entra) previa approvazione.
• Motivazione: Un triage deterministico unito ad azioni SOAR abbrevia l’MTTR e standardizza le risposte; le approvazioni impongono dei limiti (guardrail) per le azioni ad alto impatto.

5. Introdurre watchlist e corrispondenza TI con un processo di cura

• Azione: Creare watchlist per utenti VIP e servizi sanzionati; aggiungere un feed TAXII curato con confidenza >= 70 e scadenza a 7 giorni; abilitare le regole di corrispondenza TI su proxy/DNS.
• Motivazione: Dà priorità ai target di alto valore e utilizza TI aggiornata e affidabile per focalizzare le indagini e ridurre i falsi positivi.

6. Pubblicare workbook e SLA basati sui ruoli

• Azione: Creare workbook per dirigenti, operazioni SOC e stato dei rilevamenti; impostare SLA per gli incident (Alta 4h, Media 24h, Bassa 3g) e segnalare le violazioni.
• Motivazione: Visibilità e responsabilità promuovono la disciplina operativa; dashboard mirate evitano il cambio di contesto e gli sforzi sprecati.

7. Stabilire una cadenza di ottimizzazione continua

• Azione: Revisione settimanale degli incident chiusi come falsi positivi; modificare regole, soppressioni ed esclusioni con giustificazioni documentate; monitorare le anomalie di ingestione e le prestazioni delle query.
• Motivazione: Le operazioni di sicurezza vanno alla deriva senza cicli di feedback; un affinamento continuo mantiene la qualità del segnale man mano che l’ambiente si evolve.

Eseguendo questi passaggi, Contoso allinea i rilevamenti al rischio aziendale, riduce il rumore alla fonte e automatizza le attività ripetitive, ottenendo una risposta agli incident più rapida e coerente senza sacrificare la copertura.

← Gestione della postura di sicurezza e governance · Tutti i domini · Sicurezza delle applicazioni e DevSecOps →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →

Sfoglia Microsoft →