Eseguire il Parsing degli Audit Log di Libra Esva in Microsoft Sentinel

All’interno della Community ho parlato di Microsoft Sentinel, SIEM e SOAR di casa Redmond e di come esso può aiutarvi a collezionare log da diverse fonti per permettervi di individuare attività illecite e di estendere la data retention dei log.

Vi lascio a titolo informativo un articolo in cui spiego come poter collezionare log da Server on-prem e salvarli all’interno di Microsoft Sentinel Configurare Microsoft Sentinel per ricevere Log da dispositivi On-Premises – ICT Power.

In questo articolo invece vorrei darvi evidenza di come poter collezionare log da Libra Esva ESG (Email Security Gateway) ed eseguire successivamente il parsing degli stessi per recepire informazioni inerenti alle utenze amministrative che eseguono login sull’appliance.

Prima di procedere vorrei darvi evidenza di cosa è Libra Esva ESG: il prodotto, come dice il nome stesso è un servizio di Email Security che vi permette di proteggere il vostro business dai più sofisticati attacchi informatici che si diffondono tramite le e-mail aziendali

Vi elenco alcune caratteristiche del prodotto:

  • Spoofing Protection: attraverso i controlli dei protocolli SPF,DKIM e DMarc il prodotto blocca i tenantivi di Email Spoofing relativi ai vostri domini di posta elettronica
  • Threat Analysis Portal: Il prodotto mette a disposizione un portale che permette alle organizzazioni di avere delle Dashboard che vi aiutano a capire se la vostra azienda è sotto attacco e vi permette di confrontare i vostri dati di url rewriting o sandboxing con quelli globali
  • Protection Against Malicious Files: I file PDF contenuti all’interno degli allegati Email vengono scansionati e quindi sanificati o bloccati prima di raggiungere la casella di destinazione
  • Threat Remediation: Qualche volta può accadere che elementi malevoli vengano recapitati all’interno delle mailbox di destinazione, aggiornando poi i monitor antispam se questa mail venisse rilevata come malevola la mail viene rimossa dalla mailbox dell’utente e inserita in quarantena in modo completamente trasparente per l’utente
  • Protection Against Malicious Urls: I link contenuti all’interno delle email vengono “riscritti” e analizzati da Esva Labs e se ritenuti malevoli vengono bloccati, in modo tale che gli utenti siano protetti
  • Email Encryption: Possibilità di eseguire cifratura delle email in modo tale da permettere la lettura delle stesse solo a mittente e destinatario evitando attacchi di tipologia “man in the middle”
  • Bec and Impersonation Attacks Protection: Attraverso funzionalità avanzate Evita l’impersonificazione di utenti VIP, evitando quindi attacchi di tipo “CEO Fraud o Whaling”
  • Email Continuity: Libra Esva vi concede l’opportunità di inviare email direttamente dall’appliance loggandovi con credenziali utente evitando il fermo del servizio fondamentale di posta elettronica
  • Respond Quickly to Security Threats: Libra Esva permette tramite SYSLOG l’invio dei propri eventi verso i SIEM

Per eventuali approfondimenti vi invito a prendere visione della pagina del Vendor Libraesva Email Security Gateway Software

 

Svolgimento

Per darvi evidenza di come poter collezionare i log di Audit di Libra Esva all’interno di Microsoft Sentinel utilizzerò un’appliance di Libra Esva una macchina virtuale Linux (LinuxVM) con sistema operativo Ubuntu 22.04 LTS e un workspace di Microsoft Sentinel all’interno di un Tenant Microsoft 365

Figura 1: Appliance di Libra Esva che verrà utilizzata come demo e che inviarà i log a Microsoft Sentinel

Figura 2: LinuxVM che sarà il Gateway che riceverà i log da Libra Esva e li invierà a Microsoft Sentinel

Figura 3: Workspace di Microsoft Sentinel che ospiterà i log di Libra Esva

Il primo step che dovrete eseguire è quello di preparare la macchina Linux ad ospitare i log proveniente dall’appliance di Libra Esva per fare questo dovremmo installare AMA (Azure Monitoring Agent) sulla macchina Linux. Nel mio caso il dispositivo è in hosting presso Microsoft Azure, quindi i passaggi per la configurazione saranno per questa tipologia di configurazione.

Recatevi quindi all’interno del Workspace di Microsoft Sentinel e abilitate il data connector chiamata “SYSLOG“.

Figura 4: Abilitazione Data Connector “SYSLOG” che permetterà di collezionare gli eventi di Libra Esva

Figura 5: Installazione connettore SYSLOG effettuata in modo corretto

Ora dovrete procedere alla configurazione del connettore per la macchina Linux, nel mio caso LINUXVM.

Figura 6: Configurazione connettore SYSLOG (AMA)

Figura 7: Creazione Data Collection Rule che permetteranno alla macchina Linux di eseguire log forwarding verso il workspace di Microsoft Sentinel

Figura 8: Configurazione Data Collection Rule per Linux Log Forwarder

Figura 9: Selezione del dispositivo Forwarder Linux, nel mio caso “LinuxVM” in hosting presso Microsoft Azure

Figura 10: Selezione di quali eventi Linux eseguire il forwarding verso il workspace di Microsoft Sentinel

Figura 11: Salvataggio Data Collection Rule del dispositivo Linux

Figura 12: Salvataggio Data Collection Rule effettuato in modo corretto

Figura 13: Data Collection Rule presente all’interno del connettore SYSLOG

Ora dovrete recuperare l’indirizzo IP Pubblico della macchina LinuxVM che dovrete inserire nell’appliance di Libra Esva nella sezione SYSLOG

Figura 14: Recupero dell’indirizzo IP Pubblico da configurare in Libra Esva

Figura 15: Configurazione Server SYSLOG in Libra Esva ESG; questo permetterà di inviare i log al collector Linux

Ora che avrete configurato l’invio dei log, nella macchina virtuale Forwarder dovrete procedere ad eseguire la creazione di una regola che vi permetterà di rendere raggiungibile la macchina forwarder sulla porta 514 solo ed esclusivamente dagli indirizzi IP dell’appliance di Libra Esva

Figura 16: Apertura porta 514 per consentire a Libra Esva di raggiungere in modo corretto il log forwarder

Ora lato configurazione avrete terminato. Vorrei quindi mostrarvi come poter prendere visione se i log arrivino in modo corretto alla macchina Forwarder:

Figura 17: Comando Linux per “ascoltare” le connessioni in ingresso sulla porta 514

Ora che avrete verificato che i log di Audit dell’appliance di Libra Esva vengono correttamente ricevuti dal Gateway della macchina Linux, dovrete predisporre la KQL (Kusto Query) per identificare solo gli eventi di Login

Figura 18: Kusto Query che esporta solo gli eventi di Login e Logout dell’appliance Libra Esva

Ora che avrete identificato la Query necessaria per eseguire la ricerca ogni ora dovrete creare una Analytics Rule ed eseguire il parsing di questi eventi

Figura 19: Creazione Analytics Rule per il Parsing degli eventi provenienti da Libra Esva

Figura 20: Configurazione del nome della regola di analitica

Figura 21: Configurazione della Regola di Analitica con KQL specifica per la ricerca delle login all’appliance di Libra Esva e configurazione del Parsing per recuperare il nome utente dal messaggio Syslog

Ne approfitto per spiegarvi la KQL

  • SYSLOG: Recupero Log dalla tabella Syslog
  • Where SyslogMessage: recuperiamo solo gli eventi che includono l’evento di Login sull’appliance Libra Esva
  • UserMadeLogin: estrazione dal syslog message dell’utente che ha eseguito la login ed inserito nella variabile UserMadeLogin

Figura 22: Salvataggio regola di Analitica

Figura 23: Alert generato dalla regola di analitica creato in precedenza

Figura 24: Parsing eseguito in modo corretto, in quanto come entità viene mostrato l’utente che ha effettuato la login all’appliance di Libra Esva

Conclusioni

Come avete potuto notare l’integrazione di Microsoft Sentinel, anche con prodotti e servizi di terze parti, permette in modo semplice di eseguire log collection e creare correlazione di eventi che possono essere poi utilizzati lato SOAR per automatizzare risposta ad incidenti di sicurezza.

Il parsing, soprattutto da dispositivi che inviano log con SYSLOG è di fondamentale importanza in quanto vi permette di avere all’interno degli Alert / Incident dei dettagli fondamentali come indirizzo IP di provenienza della login, nome utente che ha eseguito l’accesso, dati che sono incluso all’interno del “Syslog message” e senza il parsing non verrebbero popolati i cambi in modo “user Friendly” e dovreste leggere tutto il messaggio Syslog, operazione non rapida e intuitiva.