Microsoft Sentinel: il beneficio delle Watchlist
Le watchlist in Microsoft Sentinel consentono agli analisti di sicurezza di correlare e arricchire in modo efficiente i dati degli eventi.
Questa funzionalità offre in modo flessibile per gestire i dati di riferimento, ad esempio elenchi di asset critici / di valore elevato o dipendenti che hanno dato le dimissioni. Integrare le watchlist nelle regole di rilevamento, nella ricerca delle minacce e nei flussi di lavoro di risposta per ridurre i falsi positivi e rispondere alle minacce informatiche nel più breve tempo possibile.
Le watchlist vengono “archiviate” in Microsoft sentinel in una tabella con l’associazione nome e valore, e vengono memorizzate nella chache per ottenere prestazioni ottimali delle query a bassa latenza.
Quando usare le watchlist?
È consigliabile utilizzare le watchlist di Microsoft Sentinel in uno dei seguenti scenari:
- Analizzare le minacce e rispondere rapidamente agli imprevisti importando indirizzi IP, hash di file e altri dati da file CSV. Dopo aver importato i dati, utilizzare coppie nome e valore della lista di controllo per eseguire join e filtri nelle regole di avviso, rilevamento delle minacce.
- Importare i dati aziendali come lista di controllo. Ad esempio, importare elenchi di utenti con accesso al sistema con privilegi o elenchi di dipendenti che hanno dato le dimissioni. Usare quindi l’elenco di controllo per creare elenchi di elementi consentiti e elenchi di blocchi per rilevare o impedire a tali utenti di accedere alla rete.
- Ridurre i falsi positivi degli Alert. Creare elenchi per eliminare gli avvisi generati da un gruppo di utenti, ad esempio, le login degli utenti che provengono da indirizzi IP autorizzati che eseguono attività che normalmente attivano l’avviso. Impedire che eventi non dannosi creano solamente rumore.
- Arricchire i dati dell’evento. Usare watchlist per aggiungere combinazione nome-valore da origini dati esterne ai dati dell’evento.
Limitazioni delle watchlist
Vi riporto a titolo informativo tutte le limitazioni che attualmente sono presenti per le watchlist
| Limitazione | Dettagli |
| Lunghezza del nome e dell’alias della watchlist | I nomi e gli alias watchlist devono essere compresi tra 3 e 64 caratteri. Il primo e l’ultimo carattere devono essere alfanumerici; spazi, trattini e caratteri di sottolineatura consentiti tra. |
| Uso previsto | Usare watchlist solo per i dati di riferimento. Le watchlist non sono progettate per volumi di dati di grandi dimensioni. |
| Numero massimo di elementi watchlist attivi | È possibile avere un massimo di 10 milioni di elementi watchlist attivi in tutte le watchlist in un’area di lavoro. Gli elementi eliminati non vengono conteggiati. Per volumi più grandi, usare i log personalizzati. |
| Conservazione dei dati | I dati nella tabella Watchlist di Log Analytics vengono conservati per 28 giorni. |
| Intervallo di aggiornamento | Gli elenchi di controllo vengono aggiornati ogni 12 giorni, aggiornando il TimeGenerated campo. |
| Gestione tra aree di lavoro | La gestione delle watchlist tra aree di lavoro con Azure Lighthouse non è supportata. |
| Dimensioni di caricamento file locali | I caricamenti di file locali sono limitati ai file fino a 3,8 MB. |
| Dimensioni di caricamento dei file di Archiviazione di Azure (anteprima) | I caricamenti di Archiviazione di Azure sono limitati ai file fino a 500 MB. |
| Restrizioni relative a colonne e tabelle | Gli elenchi di controllo devono seguire le restrizioni di denominazione delle entità KQL per colonne e nomi. |
Come posso creare le watchlist?
Per procedere alla creazione delle watchlist in Microsoft Sentinel:
- Caricamento di un file da una cartella locale o dall’account di archiviazione di Azure
- Scaricare un modello watchlist da Microsoft Sentinel, aggiungere i dati e quindi caricare il file quando si crea l’elenco di controllo
Per creare una watchlist da un file di grandi dimensioni (fino a 500 MB), caricare il file nell’account di archiviazione di Azure, creare un URL di firma di accesso condiviso in modo che Microsoft Sentinel possa recuperare i dati.
Per eventuali approfondimenti vi rimando alla documentazione ufficiale Microsoft:
- Create new watchlists – Microsoft Sentinel | Microsoft Learn
- Schemas for Microsoft Sentinel watchlist templates | Microsoft Learn
- Grant limited access to data with shared access signatures (SAS) – Azure Storage | Microsoft Learn
Per darvi evidenza di questa funzionalità utilizzerò una Subscription Azure in cui è presente un Workspace di Microsoft Sentinel, ed una Virtual Machine di cui tramite DCR (Data Collection Rule) collezioniamo solo gli eventi di Login Failed e Login Success di una VM in Microsoft Azure:

Figura 1: Workspace di Microsoft Sentinel presente nella Subscription Azure

Figura 2: Data Collection Rule che colleziona i log in Microsoft Sentinel Relative alle login

Figura 3: Azure VM che invia i log di Login tramite DCR a Microsoft Sentinel
Ora vi fornisco la KQL (Kusto Query) che permette di identificare in Microsoft Sentinel le login fallite verso la macchina ITBGSERVER01 da cui prenderemo la lista di IP simulando dei tentativi di Brute Force:
|
1 2 3 4 |
SecurityEvent | where Computer == "ITBGSERVER01" | where EventID == 4625 |
Questa query recupera tutti gli eventi con ID 4625 (Login Failed) verso la macchina ITBGSERVER01

Figura 4: Risultati della KQL eseguita

Figura 5: KQL che mostra come risultato anche gli Indirizzi IP
Visto che a noi interessano solo gli indirizzi IP modifichiamo la KQL con il comando “distinct” per avere come risultato solo ed esclusivamente tutti gli indirizzi IP senza ripetizioni
|
1 2 3 4 5 |
SecurityEvent | where Computer == "ITBGSERVER01" | where EventID == 4625 | distinct IpAddress |

Figura 6: Con il comando distinct recuperiamo gli indirizzi IP senza duplicati
Ora procediamo ad esportare i risultati in un file csv

Figura 7: Export dei risultati in CSV

Figura 8: Eseguito Download dei risultati

Figura 9: File CSV con i risultati esportati
Procediamo ad inserire nel file un’altra colonna descrittiva, nel mio caso inserirò “Descrizione” con indicato “BTIP” ovvero Brute Force IP

Figura 10: File CSV modificato inserendo la colonna con la descrizione degli indirizzi IP
Ora procederemo a creare una watchlist, che conterrà questi IP pubblici considerati tentativi di Brute Force e quindi malevoli e genereremo un alert quando ci sarà un tentativo di connessione da questi IP arricchendo di fatto la correlazione dei nostri eventi e miglioriamo la Detection, rechiamoci all’interno del portale di Microsoft Defender

Figura 11: Selezioniamo la sezione di Microsoft Sentinel per configurare la watchlist

Figura 12: Creazione di una nuova watchlist

Figura 13: Scegliamo un nome, una descrizione parlante ed un alias che servirà per “richiamare” la watchlist

Figura 14: Scegliamo la tipologia di file

Figura 15: Selezioniamo il file da caricare

Figura 16: Selezioniamo la “SearchKey” che sarà il valore da ricercare e proseguiamo con la configurazione

Figura 17: Review e creazione della watchlist

Figura 18: Watchlist creata correttamente, sarà necessario del tempo prima che sia operativa

Figura 19: Watchlist presente all’interno del portale di Defender dopo la sua creazione

Figura 20: Status della watchlist che è stata creata, nel mio caso ci sono voluti all’incirca 5 minuti
Come possiamo vedere il contenuto della Watchlist attraverso una KQL?
All’interno di Microsoft Sentinel possiamo eseguire una KQL con questo template “_GetWatchlist(‘nome’)” quindi nel mio caso “_GetWatchlist(‘BruteForceIP’)”

Figura 21: Visualizzazione contenuto watchlist attraverso la KQL
Ora dovremmo procedere a creare una KQL per generare un Incident nel momento in cui uno di questi indirizzi IP viene utilizzato per una connessione verso la nostra macchina virtuale, utilizzerò questa KQL:
|
1 2 3 4 5 6 7 8 9 10 11 |
let WL = _GetWatchlist("BruteForceIP") | project WL_IP = tostring(SearchKey); SecurityEvent | where EventID == 4625 | where Computer == "ITBGSERVER01" | where isnotempty(IpAddress) | extend SrcIP = tostring(IpAddress) | join kind=inner (WL) on $left.SrcIP == $right.WL_IP | project TimeGenerated, Computer, Account, EventID, SrcIP, LogonType, Activity |
Prima di procedere vorrei darvi evidenza di cosa sono le regole NRT in Microsoft Sentinel, questa tipologia di regole offrono una ricerca nel giro di un minuto e sono state progettate per essere altamente reattive eseguendo le query in questo arco temporale, proprio per questo è “near” real time e non in tempo reale.
Sostanzialmente recupero il contenuto della watchlist ed eseguo una inner join tra le tabelle della watchlist e la security event per trovare le connessioni provenienti dagli indirizzi IP inclusi nella watchlist

Figura 22: Creiamo una Analytics rule in NRT (Near Real Time)

Figura 23: Selezioniamo un nome ed una descrizione parlante, una severity e le eventuali tecniche di attacco

Figura 24: Copiamo la nostra KQL vista in precedenza all’interno dell’Editor
Ora dovremmo configurare il mapping delle entità, inserisco come “Host” il computer a cui gli IP tentano il collegamento, che nel mio caso sarà sempre “ITBGSERVER01”, come IP mappo “SrcIP” che è l’indirizzo che esegue il collegamento, e come “Account” il nome utente utilizzato dagli attaccanti per eseguire il collegamento

Figura 25: Entity mapping configurato correttamente

Figura 26: Scegliamo di “raggruppare” tutti gli eventi in un singolo Alert

Figura 27: Scegliamo di generare un Incident quando viene eseguito il match con questa regola

Figura 28: Al momento scelgo di non eseguire nessuna automazione da applicare alla regola

Figura 29: Eseguo il salvataggio della regola

Figura 30: Regola salvata correttamente

Figura 31: E-mail che mi avvisa della creazione dell’Incident

Figura 32: Incident presenti all’interno del portale di Microsoft Defender che sono stati generati dalla regola creata in precedenza
Conclusioni
L’utilizzo combinato delle Watchlist di Microsoft Sentinel e delle Analytics Rule permette di passare da un approccio reattivo a uno proattivo e e ricco di governance delle detection.
Le watchlist consentono quindi di avere più fonti da cui recuperare dati utili a migliorare le regole, basti pensare per esempio a degli indicatori che popolano in modo automatico le watchlist.
Integrandole all’interno delle analytics rule:
- si riduce il numero di falsi positivi
- si accelera la risposta agli incidenti
- si semplifica l’aggiornamento delle detection senza dover modificare le regole
Questo approccio rende Microsoft Sentinel non solo un SIEM ed un SOAR, ma una vera piattaforma di detection engineering, dove in modo estremamente semplice la correlazione e la generazione di Incident può essere ottimizzata e personalizzabile secondo le esigenze dell’organizzazione.