Sbloccare la visibilità su M365: perché i connettori SIEM predefiniti ti lasciano al buio

By Mirko Peters · 2026-08-11

Bentornato sul blog! Se gestisci le operazioni di sicurezza per un'organizzazione che utilizza Microsoft 365, è probabile che tu provi una falsa sensazione di sicurezza. Hai cliccato su "en…

Automatically translated with AI from the original post. Read the English original

Bentornato sul blog! Se gestisci le operazioni di sicurezza per un'organizzazione che usa Microsoft 365, probabilmente ti senti al sicuro. Hai cliccato su "abilita" sul connettore M365 predefinito del tuo SIEM, hai verificato che i log arrivino correttamente e hai spuntato la casella per la conformità. Ma sei davvero protetto? La verità scomoda è che i connettori SIEM pronti all'uso lasciano spesso enormi punti ciechi, ignorando completamente i carichi di lavoro cloud avanzati in cui gli attaccanti moderni amano operare. Per approfondire a fondo questo argomento cruciale, ascolta il nostro podcast di accompagnamento, Send Critical Microsoft 365 Logs to Your SIEM, in cui analizziamo nel dettaglio queste lacune.

In questo post approfondiremo perché le configurazioni predefinite non ti tutelano, dove si nascondono i punti ciechi e come costruire una pipeline di acquisizione resiliente ed economica, capace di far emergere rilevamenti ad alto segnale che i tuoi analisti possono effettivamente utilizzare.

I punti ciechi di Microsoft 365 nei principali SIEM

Che tu utilizzi Microsoft Sentinel, Splunk o QRadar, i modelli di acquisizione predefiniti si concentrano di solito sugli accessi di base di Azure Active Directory e sui log essenziali delle attività di Office 365. Questo copre le basi, ma lascia completamente esposti carichi di lavoro critici. Nelle principali piattaforme SIEM compaiono costantemente diversi punti ciechi significativi:

• Exchange: i connettori predefiniti spesso non rilevano l'accesso alle cassette postali da parte di utenti non proprietari, la creazione di regole e inoltri sospetti, le attività SendAs o SendOnBehalf e le modifiche improvvise alle autorizzazioni delle cassette postali.
• SharePoint e OneDrive: potresti vedere i download dei file, ma vedi anche la creazione e l'utilizzo di link esterni e anonimi, le ricondivisioni dei file o le modifiche alle autorizzazioni privilegiate dei siti?
• Teams: gli attaccanti amano collaborare allo scoperto. Le configurazioni predefinite raramente registrano la condivisione esterna tramite canali basati su SharePoint, l'eliminazione e la modifica dei messaggi, le modifiche ai criteri delle riunioni o il sideloading non autorizzato di app.
• Power Platform: la diffusione degli ambienti low-code/no-code porta con sé rischi nascosti. Spesso vengono trascurati i picchi di creazione di flussi e app, l'uso di connettori a rischio (come Outlook, Teams o i connettori HTTP generici) e le elusioni dei criteri di prevenzione della perdita di dati (DLP).
• Riservatezza e DLP: l'applicazione e la rimozione delle etichette, i riscontri dei criteri e le sostituzioni manuali spesso mancano del tutto, a meno che non vengano esplicitamente presi di mira.
• Contesto di Azure AD: il contesto cruciale relativo agli accessi a rischio, agli esiti dei criteri di accesso condizionale e alle anomalie di dispositivo o geografiche viene spesso omesso dalle query standard.

Cause profonde: perché ti mancano gli eventi critici

Perché questi flussi di telemetria critici mancano? Raramente succede per caso; è piuttosto il risultato di scelte architetturali e commerciali compiute sia dai fornitori di piattaforme sia dagli acquirenti aziendali.

In primo luogo, i vincoli di licenza giocano un ruolo fondamentale. Il controllo avanzato, la telemetria granulare di Exchange e la registrazione dettagliata degli eventi di SharePoint sono spesso riservati a licenze di livello superiore come Microsoft 365 E5 o ai componenti aggiuntivi di Advanced Audit. Se il tuo tenant si trova al livello E3, questi eventi semplicemente non vengono generati né conservati.

In secondo luogo, i limiti di ambito dei connettori restringono la raccolta dei dati. I connettori standard di solito acquisiscono i flussi di base "OfficeActivity" ignorando i carichi di lavoro avanzati. In terzo luogo, la limitazione della velocità di trasferimento delle API e i ritardi dovuti al batching possono sovraccaricare i raccoglitori nativi nelle ore di punta, causando la perdita di log. In quarto luogo, le lacune nei parser fanno sì che, anche quando i blob JSON grezzi arrivano nel SIEM, i campi non mappati e le modifiche silenziose allo schema li rendano incomprensibili. Infine, i controlli dei costi applicati dai team attenti al budget escludono silenziosamente le categorie più rumorose senza considerarne le implicazioni per la sicurezza.

Bilanciare il controllo dei costi senza restare al buio

Una delle obiezioni più forti all'acquisizione di una visibilità "completa" su Microsoft 365 riguarda i costi. Acquisire ogni singolo log generato da un grande tenant M365 può far esaurire il budget dello storage di sicurezza. Tuttavia, non devi scegliere tra andare in rovina e restare al buio. Devi filtrare con intelligenza, non ridurre e basta.

Inizia filtrando a monte. Configura i meccanismi di ingestione in modo che includano solo le operazioni ad alto valore informativo, come New-InboxRule, Add-MailboxPermission, o gli eventi di creazione e utilizzo di link anonimi. Deduplica e aggrega gli eventi rumorosi e di scarso valore, come i salvataggi in background delle versioni di SharePoint, prima che arrivino al tuo SIEM.

Implementa strategie di archiviazione a più livelli. Mantieni lo storage "hot" per un periodo breve (da 30 a 60 giorni) per le indagini in corso, e instrada lo storage "cold" o di archivio verso object store meno costosi, così da rispettare gli orizzonti di conservazione richiesti dalla compliance. Inoltre, modella i volumi prima di attivare nuovi flussi. Stima i gigabyte al giorno per ogni fonte e raddoppia queste stime per tenere conto dei picchi di attività aziendale, degli audit trimestrali o dei periodi di discovery legale.

Progettare una pipeline di ingestione resiliente

Affidarsi a connettori fragili che effettuano polling diretto è una ricetta sicura per perdere alert durante gli incidenti di sicurezza più critici. Progetta invece una pipeline resiliente e consapevole dei limiti di throttling. Un pattern solido è questo:

• Sorgente: Raccogli dati dal registro di controllo unificato di Microsoft 365, da Advanced Audit, dai log di accesso e di rischio di Azure AD, da Microsoft Information Protection (MIP), dagli avvisi DLP e dagli avvisi di sicurezza di Microsoft Defender.
• Trasporto: Instrada i dati dalle API Graph o Management verso Azure Event Hub (che funge da buffer e meccanismo di replay) prima di inoltrarli al tuo SIEM.
• Elaborazione: Normalizza e arricchisci i dati già nella landing zone, aggiungendo contesto utente, flag di reparto, designazioni VIP, stati dei dispositivi e dati geografici.
• Governance: Implementa controlli giornalieri di completezza, gestori di backoff per i limiti di frequenza 429, monitoraggio delle modifiche allo schema e alert sulle dead-letter queue.

Normalizzazione e arricchimento per dati pronti per l'analista

I log grezzi di Microsoft 365 sono notoriamente disordinati, pieni di oggetti JSON annidati e con convenzioni di denominazione dei campi incoerenti tra un workload e l'altro. Se consegni i dati grezzi a un analista di Tier 1, passerà metà del turno a decodificare i payload invece di valutare le minacce.

Appiattisci i campi chiave già in fase di ingestione: Actor, Target, Action, ResourcePath, LinkType (anonymous, organization o specific people), ExternalRecipient e LabelName. Mappa questi campi su uno schema unificato, come Azure Monitor Common Security Incident Model (ASIM) o Elastic Common Schema (ECS), in modo che lo sviluppo delle detection copra tutti i workload senza discontinuità. Infine, arricchisci questi eventi con dati HR (ruolo, tipo di rapporto di lavoro, reparto), liste VIP, allowlist dei partner, stati di conformità dei dispositivi e classificazioni di riservatezza.

Detection ad alto valore da implementare subito

Una volta che la pipeline è operativa e i dati sono normalizzati, puoi implementare detection ad alto valore in grado di intercettare comportamenti sofisticati degli attaccanti. Ecco otto detection di base che dovresti attivare subito:

• Esfiltrazione dalla casella: Rileva una nuova regola della casella di posta che inoltra all'esterno o sposta i messaggi in RSS/Posta indesiderata, quando si verifica entro un'ora da un accesso da una nuova posizione geografica o da un dispositivo non riconosciuto.
• Accesso furtivo: Segnala l'accesso alla casella di un account VIP da parte di un utente che non ne è proprietario, quando è accompagnato da un evento Add-MailboxPermission nelle 24 ore precedenti.
• SharePoint Spill: Genera un alert per i link di condivisione anonimi o "persone specifiche" creati su file con etichetta Riservato o Con restrizioni.
• Abuso di link: Rileva un volume elevato di download esterni in una finestra di 15 minuti originati da un link di condivisione appena creato, da un nuovo IP o da un nuovo ASN.
• Teams Pivot: Individua i casi in cui un file viene condiviso all'esterno e lo stesso utente aggiunge un guest esterno al Team entro due ore.
• Abuso di Power Automate: Segnala un improvviso picco di almeno tre creazioni di flussi al giorno da parte di un account non sviluppatore, in particolare quando utilizza i connettori HTTP o Outlook.
• Privilege Creep: Tieni traccia di aggiunte e rimozioni ripetute dei ruoli di membro o amministratore sullo stesso workspace o sito sensibile in una finestra di 24 ore.
• Stale Truth: Rileva quando i dataset dei contenuti di dirigenza o finanza non si aggiornano per due o più cicli, per evitare che la leadership prenda decisioni basate su dati obsoleti.

Il tuo piano di implementazione in 30 giorni per colmare il divario

Correggere la visibilità su Microsoft 365 non richiede un anno. Puoi colmare sistematicamente i gap di visibilità in appena 30 giorni:

• Settimana 1: Attiva Advanced Audit dove necessario, fai l'inventario dei connettori SIEM attuali e mappa le categorie di eventi mancanti.
• Settimana 2: Avvia la pipeline di Event Hub. Instrada la telemetria di Unified Audit Log, Advanced Audit, Azure AD e Defender, e implementa i filtri a monte.
• Settimana 3: Normalizza e arricchisci i flussi di dati, recupera gli ultimi 30 giorni di log critici e distribuisci le sette rilevazioni ad alto segnale elencate sopra, con finestre di soppressione adeguate.
• Settimana 4: Ottimizza i costi eliminando il rumore residuo e regolando i livelli di conservazione. Aggiungi monitor di completezza ed esegui un'esercitazione da tavolo purple-team che verifichi regole delle cassette postali, condivisione esterna e picchi nei flussi.

KPI esecutivi per dimostrare il risultato

Quando la direzione chiede se il budget per la sicurezza speso per migliorare la pipeline ne è valsa la pena, servono metriche che dimostrino il successo. Monitora questi KPI esecutivi:

• Copertura: percentuale delle famiglie di eventi di Microsoft 365 previste che vengono acquisite e analizzate correttamente (obiettivo: 95% o più).
• Velocità: Mean Time to Acknowledge (MTTA) e Mean Time to Resolve (MTTR) per gli incidenti legati a Microsoft 365 (in calo).
• Rumore: rapporto tra avvisi e veri positivi (in crescita, a indicare una qualità del segnale migliore).
• Costo: costo per gigabyte acquisito (in calo di circa il 40% grazie al filtraggio a monte).
• Affidabilità: numero di giorni con interruzioni nell'acquisizione (obiettivo: zero) e SLA per le modifiche allo schema (aggiornamenti dei parser entro sette giorni da una modifica dello schema Microsoft).

Errori comuni e come risolverli

Anche i piani migliori possono incontrare ostacoli. Attenzione a queste insidie ricorrenti:

Spesso i team affermano: "L'abbiamo attivato", ma i log non compaiono mai perché le licenze di Advanced Audit o le baseline di controllo delle cassette postali non sono mai state verificate correttamente. Un altro problema frequente è che le regole del SIEM restano completamente silenziose durante gli attacchi, perché valutano gli eventi in modo isolato invece di correlare la creazione di regole, i cambi di posizione geografica e la condivisione esterna.

Le esplosioni dei costi avvengono quando i pre-filtri vengono saltati. Filtra sempre in anticipo le operazioni più rumorose ed escludi gli eventi di sincronizzazione in background. Il degrado dei parser è un altro killer silenzioso: stabilisci una routine mensile di confronto dello schema ed esegui test unitari su payload di esempio. Infine, la stanchezza degli analisti arriva in fretta se gli avvisi non hanno contesto. Assicurati sempre che gli avvisi includano chi, cosa, dove ed etichette di riservatezza, con link diretti al Microsoft Compliance Center per gli approfondimenti.

Conclusione: smetti di affidarti alla conformità per la protezione

In sintesi: i connettori SIEM predefiniti ti mantengono conforme, ma non ti proteggono. Acquisendo i log giusti di Microsoft 365, normalizzandoli in uno schema unificato, arricchendoli con il contesto di business necessario e svolgendo attività di threat hunting con rilevazioni calibrate sul comportamento reale degli attaccanti, puoi eliminare completamente i punti ciechi. È così che il tuo SIEM smette di perdere la storia e inizia a scriverla. Per approfondire ulteriormente questa strategia, ascolta l'episodio completo su Send Critical Microsoft 365 Logs to Your SIEM e inizia oggi stesso a colmare i tuoi gap di visibilità!