News for Microsoft Sentinel

Negli ultimi mesi Microsoft Sentinel è cambiato parecchio, e non parlo solo di qualche nuova regola nel Content Hub. È cambiato il modo in cui si fa onboarding, il modo in cui si gestisce la retention, il portale da cui lo si usa e, non meno importante, come si scrivono e si distribuiscono le detection.

Quest'oggi vorrei fare il punto sulle novità che ho trovato più interessanti, prendendo come riferimento la pagina ufficiale Novità di Microsoft Sentinel | Microsoft Learn. Non le riporto tutte, ma solo quelle che a mio avviso hanno un impatto reale su chi gestisce un SOC o segue progetti Sentinel per i clienti, con qualche considerazione pratica nata dall'utilizzo quotidiano.

Prima di tutto: le date da non perdere

Parto da qui perché è la parte meno "divertente" ma quella che rischia di fare più danni. Alcune scadenze sono già passate, quindi se non le avete gestite vale la pena fare una verifica:

Data	Cosa succede	Cosa verificare
Giugno 2026	Ritiro delle vecchie versioni API usate da Sentinel Repositories	Script o pipeline che creano connessioni ai repository devono usare la 2025-09-01 o la 2025-06-01
1 luglio 2026	Standardizzazione del nome dell'entità Account in incident e alert (prefisso UPN)	Automation rule, playbook, workbook e query che confrontano l'UPN completo
14 settembre 2026	Disabilitazione dell'agente containerizzato del connettore SAP	Migrazione al connettore SAP agentless (in GA)
31 marzo 2027	Sentinel non sarà più supportato nel portale di Azure	Pianificare la transizione al portale di Microsoft Defender

Sull'ultimo punto faccio una precisazione: inizialmente la data annunciata era luglio 2026, poi Microsoft l'ha spostata al 31 marzo 2027. Ricordo inoltre che Sentinel nel portale Defender è disponibile anche per chi non ha Defender XDR o una licenza E5, quindi la scusa "non abbiamo le licenze" non regge più.

Il cambio del campo AccountName: attenzione alle automazioni

Questa è la modifica che nei progetti che seguo ha generato più domande. Quando in una regola di analisi viene mappato un UPN completo (ad esempio mario.rossi@contoso.com) nel campo Account Name, Sentinel ora restituisce sempre e solo il prefisso (mario.rossi). Prima il comportamento non era coerente, a volte arrivava il prefisso e a volte l'UPN intero.

Nell'entità Account della tabella SecurityAlert vengono aggiunti anche i campi UserPrincipalName, UPNSuffix e il prefisso UPN. Se avete automation rule o Logic App con una condizione del tipo AccountName Equals utente@dominio, quella condizione non scatterà più. Il consiglio di Microsoft, che condivido, è di passare a operatori come Contains o Starts with e di confrontare il suffisso in modo separato.

Lato KQL, per le query che lavorano sulle entità Account potete usare la funzione coalesce() per rispettare l'ordine di precedenza (prefisso UPN, poi Name, poi DisplayName):

coalesce(Account.UPNprefix, Account.Name, Account.DisplayName)

Come sempre, testate le modifiche in un workspace non di produzione prima di portarle in esercizio.

Data lake: niente più onboarding separato

Dal 23 settembre 2026 il data lake è integrato direttamente nell'onboarding di Sentinel. Non serve più un percorso di attivazione e fatturazione dedicato: si fa l'onboarding di Sentinel, si collega il workspace al portale Defender e da lì si abilita il livello lake tabella per tabella.

Il punto di ingresso è la pagina Gestione tabelle del portale Defender. Selezionando una tabella e poi Conservazione potete replicare i dati dal livello Analytics al livello Data Lake oppure impostare una retention solo nel lake per i dati storici.

Una cosa da sapere per i clienti già esistenti che non avevano mai attivato il data lake: dopo l'onboarding la conservazione passa dal vecchio modello basato su archivio a quello basato sul data lake. Non è un dramma, anzi, ma conviene spiegarlo prima al cliente per evitare sorprese quando guarda le impostazioni.

La parte che uso di più è la possibilità di interrogare il lake direttamente da Advanced Hunting, sotto Investigation & Response. Fare threat hunting su dati di qualche mese fa senza doverli prima riportare nel livello Analytics è un bel passo avanti, soprattutto durante un'attività di incident response dove il tempo conta.

Microsoft Fabric entra nel gioco

Sempre a settembre è arrivata l'integrazione con Microsoft Fabric, che si articola in tre scenari:

Mirroring verso OneLake: si selezionano le tabelle del workspace da esporre in Fabric. Non viene creata una copia dei dati e non ci sono costi aggiuntivi per il mirroring
Federazione dei dati: si interrogano i dati dove si trovano già (Azure Databricks, AWS S3, Google Cloud Storage, ADLS Gen2) quando motivi di costo, governance o compliance impediscono di spostarli
Analisi personalizzate: KQL, notebook Spark, job pianificati e grafi in Fabric, con la possibilità di riportare i risultati in Sentinel tramite DCR e Logs Ingestion API

Questo è uno scenario che vedo più adatto a realtà strutturate con un team dati interno, però il tema della federazione è molto interessante anche in ottica NIS2, dove spesso i clienti hanno vincoli precisi su dove i log possono risiedere.

Filtro e split in fase di ingestion

Ad aprile è arrivata in preview la possibilità di usare filtro e split nativi dal portale Defender. In pratica potete ridurre il rumore prima che i dati vengano ingeriti e decidere quale parte di un flusso va nel livello Analytics e quale nel Data Lake.

Chi ha fatto almeno un progetto Sentinel sa che la prima domanda del cliente, dopo la demo, è sempre "quanto mi costa?". Avere uno strumento nativo per instradare i log verbosi (firewall, proxy, DNS) verso il lake, tenendo in Analytics solo quello che serve alle regole, cambia parecchio la discussione economica.

Scoping: RBAC a livello di riga

Altra novità di aprile, ancora in preview, che a mio avviso è sottovalutata. Sentinel ora supporta lo scoping, cioè un controllo degli accessi a livello di riga. Gli amministratori definiscono degli ambiti logici, i dati vengono contrassegnati in fase di ingestion e utenti o gruppi vengono assegnati agli ambiti tramite l'RBAC unificato di Defender.

Fino ad oggi, per separare la visibilità tra team diversi (ad esempio più società di un gruppo, o un team interno e un SOC esterno) la strada era quasi sempre quella di creare workspace separati, con tutto quello che ne consegue in termini di gestione e correlazione. Con lo scoping si può lavorare su un ambiente condiviso mantenendo la separazione. La configurazione si fa dal portale Defender.

UEBA: dai log grezzi ai comportamenti

La componente UEBA è quella che ha ricevuto più aggiornamenti nel corso dell'anno. Il livello dei comportamenti è in GA da febbraio e l'idea è semplice: invece di leggere centinaia di eventi CloudTrail o log di firewall, l'analista vede un comportamento già aggregato e mappato su MITRE ATT&CK, del tipo "sessione di gestione remota in ingresso da indirizzo esterno".

Le novità più recenti che vi segnalo sono queste:

Nuove impostazioni UEBA (maggio): c'è una scheda dedicata nelle impostazioni di Sentinel che raccoglie UEBA e comportamenti in un'unica vista
Collegamento dei comportamenti agli incident (giugno, preview): dalla tabella BehaviorInfo in Advanced Hunting potete collegare un risultato a un incident nuovo o esistente, con entità e metadati compilati in automatico
Anomalie sui comportamenti (agosto, preview): i record di comportamento vengono arricchiti con informazioni su attività mai viste prima, volumi anomali, valori poco comuni e corrispondenze con la threat intelligence
Nuove sorgenti (agosto, preview): oltre 40 comportamenti per le attività amministrative su Fortinet FortiGate e dieci nuove regole di anomalia per firewall, VPN e proxy Check Point, Fortinet e Zscaler da CommonSecurityLog, più il supporto per i rilevamenti AWS GuardDuty legati alle identità

Il supporto a FortiGate e Check Point per me è la notizia più concreta, perché sono firewall che trovo nella maggior parte dei clienti italiani. Gli accessi VPN anomali o falliti sono uno dei primi segnali che guardiamo quando gestiamo un incidente, averli già evidenziati da UEBA fa risparmiare tempo.

Detection as Code: Repositories e custom detection

A marzo Sentinel Repositories è passato in General Availability, e a luglio è arrivato in preview il supporto alle regole di rilevamento personalizzate (le custom detection di Defender) come codice, su GitHub o Azure DevOps, tramite l'estensione Bicep Microsoft Security. Le regole possono essere sincronizzate con la funzionalità Repositories oppure distribuite direttamente con la CLI di Bicep.

Questo è un argomento su cui sto lavorando nel mio ambiente e a cui dedicherò un articolo specifico, con la demo completa del collegamento a GitHub. Per ora mi limito a dire che, se gestite più di una manciata di regole, versionarle su un repository non è più un "nice to have": revisione delle modifiche, storico e rollback diventano gestibili come qualsiasi altro codice.

Ricordo solo, come riportato nella tabella iniziale, che chi usa le API REST per creare le connessioni ai repository deve essere passato alle versioni 2025-09-01 o 2025-06-01. Le connessioni già esistenti continuano comunque a funzionare.

Le novità basate su AI

Non poteva mancare la parte AI, che ormai attraversa tutto il prodotto. Quelle che hanno raggiunto la GA o che meritano attenzione sono:

Generazione dei playbook con AI (GA a maggio): il generatore crea workflow di automazione in Python, costruiti in modo conversazionale con un agente di coding
Strumento di migrazione SIEM (GA ad aprile): esperienza assistita per migrare da Splunk e QRadar
Entity Analyzer (GA ad aprile): valutazione del rischio per URL e identità tramite il server MCP di Sentinel. Attenzione: dal 1 aprile 2026 il suo utilizzo consuma Security Compute Unit (SCU), quindi va considerato nei costi
Graph tool nel server MCP (giugno, preview): esplorazione a grafo delle relazioni tra identità, dispositivi, minacce e segnali
Grafi personalizzati (aprile, preview): grafi costruiti sui dati del lake, interrogabili in GQL dalla sezione Grafici del portale Defender
Connector builder agent per VS Code (aprile, preview): un agente low-code per creare connettori personalizzati in pochi minuti

Sul connector builder sono curioso di fare qualche prova seria, perché i connettori per applicativi custom sono da sempre uno dei punti dove i progetti rallentano. Lo strumento di migrazione, invece, l'ho visto funzionare bene come punto di partenza, ma la revisione delle regole convertite resta un lavoro da fare a mano.

Per chi ha SAP

Chiudo con una nota per chi ha ambienti SAP. Oltre al ritiro dell'agente containerizzato già citato, a ottobre è arrivata in preview una regola di analisi per SAP BTP che correla il report delle vulnerabilità applicative con i log di audit, per rilevare l'utilizzo di app personalizzate con vulnerabilità aperte di gravità alta o critica (soglia CVSS predefinita 7.0, lookback di 14 giorni).

Conclusioni

Se dovessi riassumere l'anno di Sentinel in una frase, direi che Microsoft ha smesso di trattarlo come "il SIEM su Azure" e lo sta trasformando in una piattaforma dati di sicurezza dentro al portale Defender. Data lake integrato, Fabric, grafi e server MCP vanno tutti in quella direzione.

Nella mia esperienza però il valore immediato non sta nelle funzionalità più spettacolari, ma in quelle meno appariscenti: il tiering dei log con filtro e split, lo scoping per evitare la proliferazione di workspace, le detection versionate su repository e una UEBA che finalmente copre i firewall che troviamo davvero nei clienti.

Il mio consiglio pratico è di partire dalla tabella delle scadenze, sistemare automazioni e query sul campo AccountName se non l'avete già fatto, e pianificare per tempo il passaggio al portale Defender. Marzo 2027 sembra lontano, ma in un progetto con più workspace e automazioni personalizzate non lo è affatto.

Vi lascio di seguito i link alla documentazione ufficiale per approfondire:

Benvenuti in tech-cloud.it

Guido Imperatore, autore presso ICT Power

Cerca nel blog