Microsoft Sentinel è la piattaforma di SIEM-SOAR che aiuta a tenere sotto controllo tutto quello che succede all’interno della nostra infrastruttura, che essa sia on-premises o su cloud, su Microsoft Azure o su AWS, in dominio o workgroup e, chiaramente indistintamente che sia Windows o Linux. Grazie alla presenza di oltre 300 connettori, è possibile ricevere informazioni di ogni genere su quello che sta succedendo alle nostre risorse; ad esempio, possiamo sapere se viene rilevato un file malevolo sul nostro file server, grazie all’integrazione con Microsoft Defender XDR, oppure sapere se il nostro storage account è stato compromesso, grazie all’integrazione con Microsoft Defender for Cloud.
Insomma, una miriade di sensori che inviano informazioni al fine di avere una piattaforma di SOC a tutti gli effetti. Microsoft Sentinel analizza le informazioni che si trovano all’interno di un Log Analytics Workspace, un database che ospita tutto quello che viene caricato dai connettori, ma che può essere usato per collezionare log di applicativi propri.
Per fare un po’ di storia, Log Analytics in passato si chiamava Operations Management Suite (prima ancora System Center Advisor) e lo si può considerare il papà di Sentinel, in quanto era possibile raccogliere eventi e performance al fine di fare query, generare alert e tutto il necessario per monitorare e gestire la propria infrastruttura.
Con l’arrivo di Sentinel, in una prima fase, la soluzione non è mai stata vista molto bene come prodotto di auditing e questo perchè in passato l’integrazione, per l’invio dei dati, veniva fatto attraverso il Microsoft Management Agent (MMA) ovvero un derivato dell’agent presente in System Center Operations Manager che, in modo molto piatto, prendeva tutti i dati e li mandava verso il suo gateway di raccolta dati – Log Analytics appunto – senza distinzioni.
L’impossibilità di poter scegliere cosa raccogliere, e per quali oggetti, aveva due impatti: quantità di dati a volte non utili, costi enormi del workspace.
Il tempo passa, il progetto si evolve, Log Analytics diventa sempre più un database, Sentinel diventa sempre più un SIEM-SOAR e, grazie all’introduzione di Azure Arc, arriva il salto di qualità.
Pensato per scopi molto più ampi del monitoring, Azure Arc utilizza una logica molto più intelligente di integrazione ma, soprattutto, per la parte di collect utilizza Azure Monitor Agent (AMA). Attraverso le Data Collection Rules, è ora possibile definire cosa raccogliere e per quale server; questo porta a diversi benefici tra cui risparmi sui costi, un’esperienza di gestione semplificata e sicurezza e prestazioni migliorate.
Configurazione Data Collection Rules
Le Data Collection Rules si creano all’interno di Microsoft Azure. Nella schermata principale si può subito notare la differenza con il passato, in cui non era possibile fare regole diversificate per server o per modalità di log raccogliere.
L’unica accortezza da usare è sapere subito cosa voler fare e, ancora più importante, usare una Naming Convention per le oggetti, così da capire subito cosa fa quella determinata regola.
Le risorse da collegare sono altrettanto importanti in base a come impostate la logica di cattura informazioni (es. se volete catturare i log di sistema scegliete solo i Domain Controller).
Ultimo step è quello di scegliere i Data Source, ovvero cosa raccogliere a livello di Windows Event Logs. Se volessimo raccogliere i log di accesso, dovremmo selezionare gli Audit Success e Failure.
E se volessi aggiungere un server o modificare la modalità di dati da raccogliere? L’operazione è molto facile e consiste nell’editare la DCR creata, aggiungendo/togliendo dei server o modificando lo scope degli elementi da catturare.
Analisi Log
L’analisi dei log va fatta tramite Log Analytics utilizzando le Kusto Query Language (KQL), che permettono non solo di estendere la ricerca, incrociando più sorgenti, ma anche trasformando i risultati in tabelle formattate a livello grafico. Se volete maggiori informazioni su questo tema, potete fare riferimento a questo articolo – Panoramica del Linguaggio di query Kusto (KQL) – Azure Data Explorer & Real-Time Analytics | Microsoft Learn.
Quando si effettua una query, si deve sempre partire dallo scope di ricerca: nel caso degli eventi di sicurezza, si richiama la classe SecurityEvent.
Per vedere lo stato degli aggiornamenti da installare sui server, si richiama la classe Update.
Chiaramente questi sono esempi molto basilari, ma attraverso KQL è possibile fare molte cose in modo super dettagliato e completo.
Integrazione con Microsoft Sentinel
Ma in tutto questo, come si integra Sentinel? Partiamo da un punto molto importante, ovvero che non è necessario Sentinel per collezionare log di sistema o per sapere se ci sono eventi critici sui nostri server, perchè questa cosa è fatta da Azure Arc e Log Analytics. Tuttavia, Sentinel è importante perchè grazie ai Data Connectors si possono attivare facilmente sia gli Azure Workbook che le sonde per catturare gli eventi sospetti, che possono andare a scatenare avvisi o remediation.
Anche gli Azure Workbook sono esterni a Microsoft Sentinel e possono essere creati per mettere in una singola area, la visualizzazione di un determinato scope – ad esempio se volessimo avere una vista dei nostri file server, scoprendo le attività maggiori, i file più modificati o gli utenti più attivi.
Non a caso, gli Azure Workbook non sono altro che delle query fatte in KQL e messe atterra in modo graficamente diverso.
Il Content Hub di Microsoft Sentinel è sicuramente il punto di partenza per poter importare non solo i Workbook ma anche Analytics Rules, necessarie per intercettare le attività anomale – quest’ultime possono essere attivate anche senza la presenza dei Workbook.
Ad esempio, la solution chiamata Windows Server DNS ci aiuta a capire se all’interno della nostra infrastruttura vengono eseguite delle query verso DNS malevoli o se vengono eseguite scansioni interne/esterne atipiche. Tramite il Content Hub, non solo sarà possibile attivare facilmente i Workbook ma anche Hunting Query necessarie a rilevare le minacce. Le uniche cose non attive di default, sono le Analytics Rules che dovranno invece essere sbloccate a mano – questo per evitare un flood di allarmi e per dare consapevolezza all’utente di cosa sta attivando.
Conclusioni
L’utilizzo di Azure Arc e sicuramente fondamentale per estendere la gestione della propria infrastruttura e per poter sfruttare al meglio le varie soluzioni offerte dal cloud, come può essere la raccolta dei log o l’aggiornamento centralizzato dei server. Nei prossimi articoli andremo a vedere più nel dettaglio come costruire alcune logiche di cattura dei log per gli scenari più comuni nelle aziende.