Un accesso insolito nel cuore della notte. Un endpoint che esegue un file mai visto prima. Poco dopo, lo stesso account accede a documenti riservati che normalmente non utilizza.

Presi singolarmente, questi eventi raccontano solo una parte di ciò che sta accadendo. Messi in relazione, possono invece fornire gli elementi per ricostruire un possibile incidente.

È proprio qui che nasce una delle difficoltà più comuni nei moderni ambienti IT. Le informazioni necessarie per un’indagine non arrivano necessariamente dallo stesso sistema.

In molte organizzazioni la sicurezza è cresciuta per stratificazione: prima gli endpoint, poi la posta elettronica, poi il SIEM per centralizzare i log, poi gli strumenti per classificare e proteggere i dati.

Ogni componente può svolgere correttamente il proprio compito. Le cose si complicano quando le diverse piattaforme restano poco integrate tra loro e il team deve ricostruire manualmente la relazione tra identità, dispositivi, applicazioni e informazioni.

È in questo scenario che coordinare Microsoft Defender, Microsoft Sentinel e Microsoft Purview comincia ad avere senso. Non tanto per concentrare strumenti diversi sotto lo stesso marchio, quanto per collegare tre prospettive differenti della sicurezza: sicurezza, monitoraggio e protezione dei dati.

La frammentazione non è solo un problema di console

Un ambiente multivendor non è necessariamente inefficiente: spesso è una scelta legittima, motivata da esigenze tecniche o dalla continuità con investimenti già fatti. Il problema si presenta quando le diverse piattaforme rimangono poco integrate tra loro.

In quel caso, a pagare il conto sono i tempi di analisi — bisogna confrontare a mano alert, log e attività — le sovrapposizioni tra licenze acquisite in momenti diversi, il lavoro necessario per tenere in piedi connettori e automazioni, e la quantità di competenze specialistiche che il team deve mantenere aggiornate su più fronti contemporaneamente.

La domanda giusta, quindi, non è se un’organizzazione debba essere Microsoft-centrica o multivendor: è se l’architettura scelta permette al team di ottenere informazioni coerenti quando servono, non tre giorni dopo.

Defender, Sentinel e Purview: tre ruoli differenti

Per capire dove può essere utile l’integrazione, è importante identificare le funzionalità di ciascun prodotto.

Microsoft Defender: protezione e rilevamento

Microsoft Defender non è un prodotto singolo ma una famiglia — Defender for Endpoint, for Office 365, for Identity, for Cloud Apps, oltre ai servizi collegati alla protezione delle identità. Con Microsoft Defender XDR, i segnali di questi ambiti diversi vengono correlati in incidenti unificati, aiutando l’analista a ricostruire la sequenza degli eventi.

Questo cambia il modo in cui il SOC può affrontare un’indagine.

Un alert sull’endpoint può essere analizzato insieme a segnali relativi all’identità, alla posta elettronica o alle applicazioni cloud, quando questi dati sono disponibili nell’ambiente.

Dire semplicemente “abbiamo Defender” non basta a capire cosa sia davvero coperto: bisogna sapere quali componenti sono effettivamente licenziati, distribuiti e configurati.

Microsoft Sentinel: SIEM e automazione della risposta

Microsoft Sentinel è il SIEM cloud-native di Microsoft: raccoglie dati Microsoft e non Microsoft, supporta rilevamento, threat hunting e automazione della risposta.

Un cambiamento importante riguarda il suo rapporto con il portale Microsoft Defender.

Sentinel è oggi disponibile a livello generale nel portale Defender anche per organizzazioni che non utilizzano Microsoft Defender XDR o una licenza E5. Microsoft ha inoltre stabilito che, dal 31 marzo 2027, Sentinel non sarà più supportato nel portale Azure e sarà disponibile solo nel portale Defender.

Per chi utilizza ancora Sentinel dal portale Azure, questo rende opportuno pianificare per tempo la transizione. Non si tratta soltanto di abituare gli operatori a una nuova interfaccia: vanno verificati ruoli e permessi, modalità operative del SOC, integrazioni, contenuti e funzionalità effettivamente utilizzate. Microsoft segnala inoltre alcune differenze e limitazioni per determinate funzionalità quando Sentinel viene utilizzato nel portale Defender senza altri servizi Defender. 

Quando Sentinel viene integrato con Defender XDR nel portale Defender, gli incidenti possono essere gestiti in modo condiviso e i dati possono essere utilizzati nell’esperienza unificata di sicurezza.

Microsoft Purview: il contesto dei dati

Microsoft Purview interviene su un altro livello: quello delle informazioni.

Le sue funzionalità comprendono classificazione dei dati, sensitivity label, Data Loss Prevention (DLP), audit, eDiscovery, gestione del ciclo di vita e altre funzionalità di sicurezza e compliance, con disponibilità e caratteristiche che dipendono dalle soluzioni e dalle licenze adottate.

Il valore per un’indagine di sicurezza è abbastanza concreto.

Non basta sapere che un utente ha aperto, copiato o condiviso un file. Può essere importante capire anche che tipo di informazione conteneva quel file, se era classificata, se era soggetta a una policy DLP e quali protezioni erano applicate.

Quando l’integrazione tra Purview e Sentinel diventa utile

Portando i dati di Purview dentro Sentinel — tramite connettori, workbook e regole analitiche dedicate — un analista può incrociare log, classificazioni e sensibilità dei dati con i segnali che arrivano da endpoint e identità. Quando le fonti sono collegate e configurate correttamente, questo aiuta a rispondere più in fretta a domande che altrimenti richiedono ore di lavoro manuale: quale utente o dispositivo è coinvolto, quali risorse sono state toccate, se erano presenti dati protetti, cosa contenere per primo.

Attenzione però a non trasformarla in una promessa di correlazione automatica: Sentinel non ricostruisce da solo la relazione tra un evento e un dato sensibile. Servono fonti collegate, log disponibili, classificazioni affidabili e procedure investigative già definite. Il vantaggio reale sta nel ridurre il lavoro per mettere insieme queste informazioni — non nell’eliminarlo.

Copilot e agenti: un nuovo livello di automazione

L’evoluzione più recente della piattaforma Microsoft riguarda l’impiego dell’AI nelle attività di sicurezza.

Microsoft Security Copilot può essere utilizzato insieme a Defender, Sentinel e Purview per attività come la sintesi degli incidenti, l’analisi, il threat hunting e alcune attività di triage. Microsoft documenta inoltre agenti dedicati a specifiche attività operative, compresi scenari di triage, investigation e threat hunting. 

Non tutte le funzionalità hanno però lo stesso livello di maturità. Alcuni agenti e alcune capacità sono ancora in preview e vanno quindi valutati nel contesto del singolo caso d’uso. 

Per un’organizzazione, la domanda utile non è “usiamo l’AI?”, ma quali attività possono essere accelerate senza perdere controllo, tracciabilità e responsabilità dell’analista.

NIS2: la tecnologia può aiutare, ma non equivale alla conformità

L’integrazione tra Defender, Sentinel e Purview può contribuire a sostenere diversi aspetti della gestione del rischio richiesti dalla NIS2: visibilità sugli asset, controllo degli accessi, rilevamento degli incidenti, gestione dei log, protezione dei dati, gestione delle vulnerabilità e capacità di risposta.

Non significa però che l’adozione delle tre piattaforme renda automaticamente un’organizzazione conforme: la direttiva chiede anche governance, formazione, continuità operativa e sicurezza della supply chain, con responsabilità dirette in capo agli organi di gestione. In Italia è stata recepita con il D.Lgs. 138/2024, in vigore dal 16 ottobre 2024.

Attenzione alla scadenza di ottobre 2026

C’è però una precisazione importante rispetto alle informazioni che circolano sulla scadenza del 31 ottobre 2026.

Per i soggetti NIS inseriti nell’elenco nel 2025, la Determinazione ACN 379907/2025 prevede che le misure di sicurezza di base siano adottate entro 18 mesi dalla ricezione della comunicazione di inserimento. La data effettiva, quindi, va verificata per ciascun soggetto e non dovrebbe essere sostituita automaticamente con un generico “31 ottobre 2026”.

Nel 2026, inoltre, ACN ha introdotto termini specifici per i soggetti inseriti per la prima volta nell’elenco nell’anno in corso: per loro l’adozione delle misure di sicurezza è prevista entro il 31 luglio 2027, mentre l’obbligo di notifica degli incidenti significativi decorre dal 1° gennaio 2027.

La configurazione conta quanto la tecnologia

Avere una determinata piattaforma disponibile non significa necessariamente utilizzarne tutte le capacità.

Un assessment ben impostato può far emergere funzionalità già comprese nelle licenze ma mai attivate, fonti dati non collegate a Sentinel, policy Purview da rivedere, regole di rilevamento da ottimizzare o automazioni che possono essere semplificate.

In un assessment di sicurezza vale quindi la pena verificare almeno:

• quali licenze sono realmente attive;
  
  
• quali servizi sono effettivamente configurati;
  
  
• quali asset e identità sono coperti;
  
  
• quali fonti alimentano Sentinel;
  
  
• quali regole di rilevamento sono attive e come vengono sottoposte a tuning;
  
  
• quali automazioni sono state implementate;
  
  
• come sono gestiti ruoli e privilegi;
  
  
• come gli strumenti si inseriscono nei processi di incident response;
  
  
• quali evidenze vengono effettivamente conservate e utilizzate.

È possibile avere un ambiente tecnologicamente ricco ma con una copertura incompleta. Allo stesso modo, è possibile avere molte funzionalità disponibili a livello di licenza che non vengono mai configurate.

Per questo assessment, progettazione, tuning e formazione non sono attività successive ma fanno parte del progetto stesso di sicurezza.

Il contributo di Next04

In Next04 affianchiamo le organizzazioni nella progettazione e nell’evoluzione delle architetture di sicurezza Microsoft, tenendo insieme tecnologia, processi, dati e requisiti di conformità.

L’attività parte dalla situazione reale dell’organizzazione: quali strumenti sono presenti, quali licenze sono disponibili, quali dati vengono raccolti e quali processi il SOC utilizza oggi.

Da qui è possibile definire un’architettura in cui Defender, Sentinel e Purview abbiano ruoli distinti ma complementari, mantenendo dove necessario anche fonti e tecnologie non Microsoft.

Il lavoro comprende anche aspetti spesso meno visibili di un progetto di sicurezza: classificazione dei dati, policy DLP, qualità dei log, tuning delle regole, gestione dei privilegi, automazioni e governance degli agenti AI.

Sul fronte compliance supportiamo i percorsi NIS2 e GDPR tenendo sempre separati gli strumenti tecnologici dagli adempimenti organizzativi, che restano due lavori distinti anche quando riguardano lo stesso progetto.