• Cloud, Guide, Microsoft 365, Sicurezza
• 23 Dicembre 2024

Microsoft Sentinel e Microsoft Purview: due servizi di casa Microsoft a mio avviso fondamentali. Da una parte abbiamo a disposizione uno strumento che è verticale sulla compliance dei dati della nostra organizzazione e dell’altra abbiamo un servizio che funge da “accentratore” di tutti gli eventi provenienti dal mondo Cloud e On-prem (SIEM) e li “orchestra” (SOAR) in modo del tutto automatizzato.

Quando due strumenti così straordinari cooperano tra di loro è solo un bene sia per i membri IT che per le organizzazioni per difendersi da attacchi informatici sempre più sofisticati e complessi. All’interno di questo articolo vorrei darvi evidenza di come poter eseguire la configurazione della log collection di Mirosoft Purview che consentirà di inviarli a Microsoft Sentinel per poi procedere a creare delle Analytics Rule e degli Incident di Sicurezza basati su questa tipologia di eventi.

Giusto per ricordarvi il ruolo fondamentale che svolgono questi due Workload di Microsoft vi riporto le descrizioni:

• Microsoft Sentinel: è una soluzione di Security Information and Event Management (SIEM) e Security Orchestration, Automation, and Response (SOAR) basata su cloud, progettata per aiutare le organizzazioni a monitorare, rilevare e rispondere alle minacce alla sicurezza nelle loro infrastrutture IT. Fa parte della piattaforma Microsoft Azure ed è pensata per la gestione centralizzata della sicurezza in ambienti complessi e diversificati e per eventuali approfondimenti vi invito a leggere la guida scritta da Nicola Ferrini al seguente link Introduzione a Microsoft Sentinel – ICT Power
• Microsoft Purview: è un set completo di soluzioni che aiuta le organizzazioni a gestire, proteggere e aggiornare i dati ovunque essi si trovino, questo servizio Microsoft offre una copertura integrata e contribuisce a risolvere la mancanza di visibilità che ostacola la protezione e la governance dei dati. Per eventuali approfondimenti inerenti a questo servizio potete consultare l’articolo scritto per la community Microsoft Purview: Information Protection e Sensitivity Labels – ICT Power

Quali licenze sono necessarie per l’integrazione di questi due servizi di casa Redmond?

Per poter sfruttare le potenzialità di entrambi i servizi Microsoft dobbiamo distinguere le licenze necessarie in due, una per l’utilizzo (nel caso specifico di Microsoft Purview: Information Protection e Sensitivity Label) e dell’altra una Subscription di Microsoft Azure che ospiterà il Worspace di Microsoft Sentinel.

Per il calcolo dei costi del servizio di Microsoft Purview che è a consumo potete utilizzare il calcolatore messo a disposizione dalla casa di Redmond che per comodità vi riproto al seguente link Pricing Calculator | Microsoft Azure

Per l’articolo di oggi io utilizzare il servizio di Information Protection (uno dei tanti servizi di Microsoft Purview) che è incluso nella licenza Microsoft 365 E5

Per quanto riguarda invece Microsoft Azure va benissimo una Subscription a consumo.

NB: È importante specificare che il connettore di Microsoft Purview è attualmente in Preview vi lascio anche l’articolo ufficiale Microsoft Microsoft Purview (Preview) connector for Microsoft Sentinel | Microsoft Learn

Per darvi evidenza di quanto concerne l’articolo utilizzerò delle licenze Microsoft 365 E5, una policy di Information Protection ed un Workspace di Microsoft Sentinel utile a collezionare log e procedere poi con le dovute Query (KQL) di ricerca dei nostri dati.

Figura 1: Licenze Microsoft 365 E5 utilizzate per sfruttare le potenzialità di Information Protection

Figura 2: Sensitivity Label che verrà utilizzata per generare i Log per Microsoft Sentinel

Figura 3: Workspace di Microsoft Sentinel utilizzato per la log collection dei dati provenienti da Microsoft Purview

Ora come primo step dovremmo procedere ad aggiungere il connettore di Microsoft Purview in Microsoft Sentinel, quindi rechiamoci al portale di Microsoft Azure

Figura 4: Selezioniamo Microsoft Sentinel all’interno del portale di Azure

Figura 5: Selezioniamo il Workspace che abbiamo creato (nel mio caso C-SOCTechCloud)

Figura 6: Selezioniamo e procediamo all’installazione del connettore di Microsoft Purview

Figura 7: Connettore in fase di installazione

Figura 8: Connettore di Microsoft Purview correttamente installato in Microsoft Sentinel

Ora che avrete installato il connettore relativo a Microsoft Purview, dovrete procedere alla configurazione dello stesso

Figura 9: Rechiamoci nella pagina di configurazione del connettore

Figura 10: Spiegazione dei passaggi da seguire per abilitare il connettore

Non vi preoccupate, ora vedremo insieme come eseguire la configurazione passo passo.

Figura 11: Rechiamoci nella sezione di Azure relativa all’account di Microsoft Purview

Figura 12: Creiamo un account per collezionare i log inerenti a Microsoft Purview

Figura 13: Selezionato la Subscription in cui posizionare il vostro account, il resource group, il nome e la region

Siccome l’account avrà un costo sulla Subscription secondo la dimensione computazionale vi riporto il link ufficiale Microsoft in cui vengono riportati costi e metodi di fatturazione così potete eventualmente approfondire Elastic data map | Microsoft Learn

Figura 14: Validazione in merito alle configurazioni per la creazione dell’account di Microsoft Purview

Figura 15: Validazione Passata e creazione effettiva del nostro account di Microsoft Purview

Figura 16: Creazione Account Microsoft Purview “In Progresss”

Figura 17: Microsoft Purview Account creato correttamente nella Subscription

Figura 18: Selezionate l’account creato e posizionatevi nella sezione di “Diagnostic Settings”

Figura 19: Selezionato quali eventi volete collezzionare, nel mio caso tutti e tutte le metriche e decido di inviarle direttamente al Workspace che ho all’interno della mia istanza di Microsoft Sentinel

Figura 20: Salvataggio della Configurazione andato a Buon fine

Ora dovrete procedere a configurare anche il connettore specifico per Microsoft Information Protection, oltre a quello già configurato di Microsoft Purview

Figura 21: Installazione del connettore specifico per Microsoft Information Protection

Figura 22: Connettore Installato correttamente procediamo alla configurazione

Figura 23: Apertura della pagina relativa al connettore di Information Protection

Figura 24: Connessione degli Audit log di Information Protection verso Microsoft Sentinel

Figura 25: Connessione effettuata correttamente

Ora tutta la configurazione lato Microsoft Sentinel è stata correttamente implementata, potrebbero essere necessarie fino a 48 ore prima di vedere i log all’interno di Sentinel.

Ora simuliamo l’applicazione di una Label da parte dell’utente

Figura 26: Applicazione della Label “Label for Office Documents” da parte di un utente

Figura 27: Utente sceglie di inserire Demo User come visualizzatore del file, mentre un indirizzo gmail come Editor, quindi con permessi in modifica

Figura 28: Label selezionata correttamente applicata al documento

Inoltre un account amministratore del Tenant ha provveduto a creare un’ulteriore Label per la sola parte relativa ad Exchange Online

Figura 29: Ulteriore Label creata dall’utente che vedremo all’interno degli Audit Log

Per gli Audit log il tempo di attesa per eseguire una ricerca è “basso” nel mio caso dopo 30 minuti dalla configurazione erano già disponibili i log

Figura 30: Rechiamoci nella sezione di Logs per scrivere la nostra KQL

La KQL (Kusto Query) sarà composta in questo modo per il connettore di Microsoft Purview:

Nello specifico:

• AuditLogs: è la tabella di rifermento che ci permette di identificare i log di modifiche all’interno del portale di Microsoft Purview
• Where OperationName contains “label”: ci permette di eseguire un filtro sulla tabella per ricercare, nel nostro caso, l’operazione di “ADD LABEL” ovvero di aggiunta di una label in Microsoft Purview

Figura 31: Eseguiamo la Query e verifichiamo i risultati

Per i log inerenti alla parte di etichettatura dovremmo attendere le canoniche 48 ore della documentazione Microsoft, proviamo quindi ad inviare una mail cifrata

Figura 32: Invio Email con Label “Mail Cifrata” da Outlook Web verso un indirizzo gmail.com

Figura 33: Label applicata in modo corretta alla mail

Figura 34: Vista della mail vista dall’account di ricezione gmail

Figura 35: Essendo una mail cifrata il destinatario per leggerla, deve autenticarsi

Figura 36: Una volta autenticato il destinatario riesce a leggere la mail, quindi la mail cifrata è molto utile per inviare dati sensibili perché senza autenticazione la mail risulta illeggibile

Tutte queste attività verranno inviate a Microsoft Sentinel tramite il connettore che avrete creato.

Ora potete recarvi all’interno della sezione log di Microsoft Sentinel ed eseguire una KQL per la ricerca dei log di Information Protection

Figura 37: Scrittura della KQL per estrarre i dati relativi all’applicazione di un’etichetta da parte di un utente

Prima di procedere ad eseguirla, vorrei spiegarvela, la query in se è molto semplice, ma necessita comunque di una spiegazione

• MicrosoftPurviewInformationProtection: Tabella di Microsoft Sentinel che racchiude tutti i log relativi ad Information Protection
• where Operation == “SensitivityLabelApplied”: ricerchiamo solo le attività relative all’applicazione di una label da parte di un utente

Figura 38: Risultati della KQL che ha trovato i due risultati precedentemente simulati, applicazione di una label a file excel ed applicazione di una label alla mail cifrata

Figura 39: Dettagli Relativi alla mail inviata con la Label che includono l’utente che ha eseguito l’attività, l’indirizzo IP di provenienza ecc…

Conclusioni

Il titolo della guida dice “l’unione fa la forza” ed è vero.

Avere a disposizione uno strumento che permette di gestire la protezione e la compliance del dato è di fondamentale importanza, ma allo stesso tempo è importante estendere la retention dei log di questa soluzione in modo tale che essi siano sempre fruibili e leggibili nel momento del bisogno.

Proprio a questa esigenza risponde il SIEM di casa Redmond che permette di estendere la durata di questi Log ed eventualmente creare delle automazioni, generare degli Incident per poi essere correlati con altri log, questo aiuta anche in modo considerevole i reparti SOC delle organizzazioni a mitigare rischi di sicurezza Informatica.