• Cloud, Guide, Microsoft 365, Sicurezza
• 9 Agosto 2024

La funzionalità di Summary Rule in Microsoft Sentinel attualmente è in Public Preview, ma cosa è questa nuova funzionalità introdotta dalla casa di Redmond ?

Usare le Summary Rule in Microsoft Sentinel, vi permette di “aggregare” un set di dati, presenti in Microsoft Sentinel, in Background e quindi senza dover ogni volta eseguire KQL (Kusto Query).

I set di dati estratti con questa funzionalità vengono salvati all’interno di tabelle personalizzate, e posso essere utilizzate per ottimizzare la lettura di di dati all’interno dei seguenti scenari:

• Analisi e report: Utili per report Aziendali annuali o mensili, oppure per analisi durante un incident di sicurezza.
• Risparmio dei Costi: avrete un risparmio di costi quando si devono “estrarre” log dettagliati, che è possibile conservare all’interno di Tabelle del Workspace che hanno costi inferiori (Dati a Freddo)
• Sicurezza e Privacy dei dati: all’interno di questa funzionalità è possibile “offuscare” determinati dettagli e limitare l’accesso alle tabelle

L’uso di questa funzionalità permette quindi di ottimizzare i costi dei dati, per eventuali approfondimenti sui piani di fatturazione delle tabelle dei dati di Microsoft Sentinel vi rimando all’articolo ufficiale di Microsoft Select a table plan based on data usage in a Log Analytics workspace – Azure Monitor | Microsoft Learn.

Prerequisiti

Naturalmente esistono dei prerequisiti che dovrete rispettare per sfruttare la funzionalità di Summary Rule in Microsoft Sentinel, che per comodità riporto di seguito:

• Microsoft Sentinel deve essere attivo almeno in un Workspace e deve essere abilitato a ricevere i log con i connettori utili a tracciare i log di cui avete necessità
• Necessità di accedere a Microsoft Sentinel con il ruolo di Microsoft Sentinel Contributor
  Roles and permissions in Microsoft Sentinel | Microsoft Learn
• Per poter procedere con la creazione di Summary Rule in Microsoft Defender Portal, dovrete eseguire l’onboarding del Workspace di Sentinel verso Unified Security Operation Platforms Connect Microsoft Sentinel to Microsoft Defender XDR – Microsoft Defender XDR | Microsoft Learn

Prima di procedere alla creazione di una Summary Rule il consiglio che vi posso fornire è quello di eseguire la KQL (Kusto Query) all’interno della tab LOG di Microsoft Sentinel, per verificarne il corretto funzionamento.

Scenario

Ora vi vorrei dare evidenza di quale sia lo scenario per sfruttare al meglio questa funzionalità messa a disposizione dalla casa di Redmond. Presupponete di dover ricercare nelle login RDP del vostro domain controller, nel mio caso SRVDC04, un IP di collegamento malevolo per eventualmente bloccare le connessioni a livello Firewall da quel determinato Indirizzo IP.

Figura 1: Workspace di Microsoft Sentinel utilizzato per Demo con i Security Event del domain controller per seguire le verifiche sulle connessioni RDP

Figura 2: Domain Controller (SRVDC04) utilizzato per demo per le login in RDP che invia il log a Microsoft Sentinel

Gli step necessari per la ricerca di un IP malevolo all’interno di questo scenario saranno sostanzialmente due:

• Creare una Summary Rule che include ed estrapoli informazioni di fondamentale importanza per la nostra ricerca, come ad esempio:
  • Date: Indica la data in cui è stato generato l’evento di login in RDP
  • TimeGenerated: Indica l’orario (comprensivo della data) in cui è stata generato l’evento di login RDP al nostro domain controller
  • Account: Indica l’account che ha tentato di accedere al nostro domain controller in RDP
  • IPAddresses: Indica l’indirizzo IP (privato o pubblico) da cui proviene la richiesta di connessione RDP
  • Activity: Indica l’attività svolta in quel determinato evento (Successfully Logon, Account Failed to Logon)
• Creare una Analytic Rule che vada ad “interrogare” il set di dati creato con la Summary Rule e che venga eseguita, nel mio caso 5 minuti, per la ricerca dell’IP considerato malevolo

Svolgimento

Il primo passaggio che dovrete effettuare è quello di collegare il Workspace di Microsoft Sentinel verso la parte di Unified Security Operations Platforms, quindi recatevi all’interno del portale di Microsoft Defender Settings – Microsoft Defender

Figura 3: Connessione Workspace di Microsoft Sentinel all’interno di Defender Portal

NB: E’ fondamentale, prima di eseguire questa operazione, di configurare il connettore di Defender XDR altrimenti non vi permette l’aggiunta con l’errore sotto riportato

Figura 4: Errore nella connessione del Workspace all’interno del portale di Defender

Per installare il connettore di Defender XDR dovrete recarvi all’interno di Microsoft Sentinel nella sezione content Hub installare e configurare il connettore

Figura 5: Installazione e Configurazione del connettore Microsoft Defender XDR

Figura 6: Configurazione connettore di Microsoft Defender XDR

Figura 7: Connessione Connettore di Microsoft Defender XDR

Figura 8: Connettore Microsoft Defender XDR attivato correttamente

Bene, ora che avrete rispettato tutti i requirements richiesti, potrete accedere al portale di Defender per “agganciare” il Workspace con il portale stesso per sfruttare le funzionalità.

Figura 9: Connessione del Workspace al portale di Defender ora avviene in modo corretto senza errore

Figura 10: Conferma dell’aggancio del Workspace con il portale di Defender

Figura 11: Workspace di Microsoft Sentinel Collegato in modo corretto al portale di Defender

Ora potete procedere con la creazione della Summary Rule indicata, come suggerito in precedenza vi consiglio di seguire la KQL all’interno della tab Logs vi spiegherò anche quella che ho creato per darvi evidenza di quanto richiesto.

Figura 12: KQL per ricerca delle login RDP Fallite eseguita come test nella sezzione di Log

Vorrei anche però spiegarvi nel dettaglio questa Kusto Query per farvi capire esattamente cosa fa.

• SecurityEvent | where TimeGenerated > startofday(ago(7d)) à Ricerca nella tabella di SecurityEvent (Eventi di Windows) negli ultimi 7 giorni
• where Account contains “m365-demo” and EventID == 4625 and isnotempty(IpAddress) and not(IpAddress contains “:”) and not(IpAddress contains “-“) à recupera solo i risulta quando l’account che esegue la login appartenente, nel mio caso al dominio “m365-demo” e che l’evento Windows sia ID 4625 (login fallita) verifichi che l’IP di provenienza non sia vuoto e non sia IPv6
• extend | Date = format_datetime(TimeGenerated, “yyyy-MM-dd”) à configura la data con il formata yyyy-MM-dd
• project Date,TimeGenerated,Account,IpAddress,Activity à raggruppa i risultati della KQL per i campi Data,Orario Evento, Account, IPAddress e Attività eseguita

Ora che avrete testato la vostra KQL per la ricerca delle login fallita, potete procedere a creare la Summary Rule

Figura 13: Creazione Summary Rule

Ora dovrete procedere ad inserire i seguenti parametri:

• Name: Nome della Summary Rule
• Description: il consiglio che vi fornisco è quello di inserire sempre una descrizione “parlante”, in modo tale che in futuro riuscite a capire velocemente cosa fa quella determinata regola
• Destination Table: Tabella di destinazione della ricerca nel mio caso ne creo una nuova che si chiamerà RDPFailed_CL

Figura 14: Creazione Summary Rile con nome, descrizione, e creazione della tabella

Inserite ora la KQL creata in procedenza e configurate le tempistiche che volete applicare per indicare ogni quanto la regola deve essere eseguita, avete la possibilità anche di eseguire una preview dei risultati

Figura 15: Configurazione Summary Rule con KQL di cui avete eseguito in precedenza il test di corretto funzionamento

Figura 16: Salvataggio Summary Rule

Figura 17: Creazione della Summary Rule avvenuta in modo corretto

Ora dovrete procedere a creare le regola di Analitica, che vi permette di eseguire questa summary rule ogni tot tempo ricercando l’IP che volete ricercare come malevolo che nel mio caso sarà un IP Microsoft perché ho eseguito una RDP da un altro dispositivo in Hosting presso Azure con l’utente non esistente m365-demo\UserTOR

Figura 18: Creazione Regola di Analitica per ricercare IP Considerato Malevolo e per far generare un INCIDENT ad ogni match della regola

Figura 19: Creazione Regola di Analitica

Ora dovrete “richiamare” la tabella creata con la Summary Rule, nel mio caso chiamata RDPFailed_CL solo quando l’IP Adressess è quello considerato malevolo, nel mio caso “52.137.55.26”

Figura 20: Inseriemtno KQL per regola di Analitica

Figura 21: Generazione di un Incident Sentinel ogni volta che questa regola restituisce risultati

Potrete decidere anche di inserire un’automazione, per esempio escludere il PC dalla possibilità di eseguire connessioni verso la vostra organizzazione, nel mio caso non configuro nessuna automazione

Figura 22: Eventuale Inserimenti di una regola di automazione quando viene eseguita la regola di analitica

Figura 23: Dopo la validazione potete creare la regola

Figura 24: Regola di Analitica salvata in modo corretto

Ora dovrete attendere che la regola “giri” e vedere se viene generato l’incident

Figura 25: Incident creato in modo corretto dopo che la regola di analitica ha fatto il suo flusso

Conclusioni

Avere a disposizione una funzionalità che vi permettere di ricercare dati di grandi dimensioni e di inserirli all’interno di una tabella di Microsoft Sentinel personalizzata è un vantaggio non indifferente, questa funzionalità vi permette quindi di ricercare diversi parametri su un set di dati molto esteso in tempo molto più veloce e con un risparmi non indifferente di costi, nel mio caso il set di dati era limito , in quanto ambiente di demo, ma pensate ai milioni di log raccolti dalle organizzazioni.

Vorrei darvi evidenza anche di altri possibili scenari utili per questo servizio:

• Ricerca IP Dannosi o Eseguibili malevoli all’interno del perimetro Aziendale
• Correlazioni ancora più precisa e puntuale degli Incident
• Automatizzare in modo più preciso le Remediation agli incident

Una funzionalità ancora in Preview, ma con un grosso potenziali a mio avviso.