• Passa al contenuto principale
  • Passa alla barra laterale primaria
  • Passa al piè di pagina

IT Specialist

by Riccardo Corna

  • Home
  • Nuovo? Inizia da qui!
  • Di cosa parlo?
    • Identity and Security
    • Microsoft 365
    • Azure
    • Windows
    • Altro
    • Divagazioni e punti di vista
  • Il Blog
  • Eventi & Community
  • Privacy Policy

Riccardo Corna / Febbraio 2, 2022

Come inviare i Risky Sign-Ins e i Risky Users da Identity Protection a Microsoft Sentinel

Cosa succederebbe se fossimo in grado di unire la ricchezza dei log di Azure AD Identity Protection, con i suoi eventi di Risky Sign-In e i dati sui Risky Users, ad un ulteriore strumento di analisi con cui scatenare, al bisogno, allarmi ed eventuali automazioni di reazione e remediation? Semplice: avremmo in mano un’arma potentissima contro qualunque minaccia alle identità! Vediamo gli ingredienti di questa integrazione.

Azure AD Identity Protection: Risky Sign-Ins e Risky Events

Il rilevamento del rischio in Azure AD Identity Protection è una funzionalità utilissima attraverso cui, analizzando alcuni segnali, è possibile stabilire la probabilità che un’utenza o un’autenticazione siano a rischio. Ne ho parlato super-approfonditamente in questo articolo: Azure AD Identity Protection: cos’è il rischio in Azure AD?

Microsoft Sentinel

Microsoft Sentinel è una soluzione per la gestione di informazioni ed eventi di sicurezza (in poche parole un SIEM: Security Orchestration, Automation, and Response). Attraverso opportuni connettori e query in linguaggio KQL (Kusto Query Language), è possibile andare ad interrogare in maniera molto granulare una grande quantità di log memorizzati dalle varie sorgenti dati a cui Sentinel si aggancia. Inoltre, è possibile impostare delle automazioni di reazione in caso di bisogno. Anche di questo ho parlato in un mio articolo di qualche tempo fa: Come capire Microsoft Sentinel in 5 passaggi.

Perché integrare le due cose?

Perfetto, ora è il momento di fare 1+1: se riuscissi a “redirigere” la ricchissima raccolta di segnali e quant’altro che viene fatta da Azure AD Identity Protection a Microsoft Sentinel, saresti in grado di interrogare in maniera super-granulare questi log attraverso delle query KQL mirate e completamente personalizzabili in base alle esigenze.

Queste query potrebbero essere usate all’interno di un’Analytics Rule, scatenare un allarme e, di conseguenza, un’eventuale automazione attraverso un Playbook, come ad esempio bloccare un utente, inviare mail o messaggi via Teams al SOC di turno, bloccare un IP, e via dicendo. Il limite è solo la fantasia!

Insomma, come dicevo anche ad inizio articolo: avresti a disposizione un’arma potentissima contro eventuali minacce e attacchi portati alle identità.

Perché non è sufficiente l’analytics rule built-in di Identity Protection?

Fermi tutti! Ti starai chiedendo:

“Rick, ma esiste già un data connector integrato per Azure AD Identity Protection e un’analytics rule built-in che è solo da accendere: perché non basta?”

Prima di andare avanti, ti racconto perché non mi piace tantissimo l’analytics rule built-in “Create incidents based on Azure Active Directory Identity Protection alerts” del connettore di Identity Protection. Pur essendo utile attivarla, raccoglie i dati in maniera poco uniforme in ottica di automazione, perché in alcuni casi i Risky Events sono raggruppati e così anche le entità coinvolte negli alert e negli incident. Insomma, non sono allarmi/incident facili da “setacciare” con un Playbook perché ogni alert/incident può contenere informazioni e dati differenti, rendendo quindi difficilmente prevedibile e uniforme il formato stesso dell’alert/incident.

Per scatenare un’automazione, bisogna essere assolutamente sicuri che i dati siano sempre gli stessi e che siano formati e strutturati in maniera identica, possibilmente uno per ogni evento.

Come si ottiene questo? Scrivendo delle query KQL granulari che estraggano i dati nella maniera che noi vogliamo: è l’unico modo per avere il controllo completo dei dati!

Perfetto: finita questa lunghissima premessa (se sei ancora qui a leggere ti ringrazio 😃), ora affrontiamo davvero l’argomento dell’articolo: inviamo i dati grezzi dei Risky Sign-Ins e dei Risky Events da Azure AD Identity Protection a Microsoft Sentinel!

Come si fa a mettere a disposizione questi dati da Identity Protection a Microsoft Sentinel?

È molto più semplice di quanto immagini: attraverso una nuova funzione introdotta da poco nei Diagnostic Settings di Azure AD, è possibile in pochissimi clic inviare alcuni log direttamente a Microsoft Sentinel, letteralmente facendone uno “straming” diretto.

Per impostare questo settaggio, vai sul portale di Azure (https://portal.azure.com) e naviga fino alla seguente sezione:

  • Azure Active Directory –> Diagnostic Settings (si trova più in basso, nella sezione “Monitoring”)
Azure AD Diagnostic Settings

Nella blade che si apre, clicca la voce Add diagnostic setting

Azure AD: aggiungere diagnostic settings

Perfetto, ora è sufficiente configurare le impostazioni come segue:

Aure AD Diagnostic Settings: inviare i dati di Identity Protection a Microsoft Sentinel
  1. dai un nome allo streaming;
  2. seleziona i dati da inviare da Identity Protection a Microsoft Sentinel (RiskyEvents e UserRiskEvents);
  3. seleziona la spunta Send to Log Analytics workspace;
  4. completa la configurazione scegliendo la sottoscrizione Azure e il log analytics workspace corrispondente alla tua istanza di Microsoft Sentinel.

Come verificare che la configurazione sta funzionando? Dopo qualche decina di minuti, tra le tabelle di dati disponibili sul Log Analytics workspace, compariranno queste due voci:

Log Analytics Workspace data tables

Che dici, proviamo a fare un paio di query per capire quali informazioni è possibile ricavare?

Query KQL di esempio sui Risky Sign-Ins

Vediamo, ad esempio, quali sono le tipologie di Risky Event più ricorrenti con la query:

AADUserRiskEvents
| summarize count()by RiskEventType
| render piechart
AADUserRiskEvents da Identity Protection a Microsoft Sentinel

Oppure, è possibile vederli come elenco, ricavando alcune preziose informazioni come:

  • l’utente coinvolto nell’evento rischioso;
  • il suo indirizzo IP;
  • che browser o applicazione stava usando quando si è autenticato;
  • livello di rischio;
  • descrizione del perché l’autenticazione è stata considerata rischiosa.

Vediamo ora se ci sono utenti considerati a rischio da Azure AD.

Query di esempio Risky Users

Interroga la data table in questo modo:

AADRiskyUsers

Ecco i risultati.

AADUserRiskEvents da Identity Protection a Microsoft Sentinel

Anche questi log sono ricchissimi di informazioni.

Un ulteriore step per la vera magia

Ed ecco la vera magia, il motivo per cui attivare lo streaming degli eventi da Identity Protection a Microsoft Sentinel è davvero un’arma potente: incrociando opportunamente queste data table con altre table, come ad esempio, SecurityAlert, SigninLogs e AuditLogs, attraverso una query KQL e qualche join è possibile ricavare informazioni come:

  • UPN dell’utente coinvolto nell’evento a rischio;
  • browser o app che stava utiulizzando per fare l’autenticazione;
  • tipologia di dispositivo da cui l’autenticazione è stata fatta;
  • indirizzo IP;
  • livello di rischio;
  • motivo per cui l’evento e l’utente sono stati calcolati come “a rischio”;
  • location geografica dell’evento: città e paese.

Immagina ora di usare questa query per innescare un alert o un incident che, a sua volta, innesca un’automazione via Playbook: potresti bloccare l’utente, l’IP e, contemporaneamente, avvisare il SOC via Teams o via mail in tempo reale, magari inviando anche un’email all’utente finale.

Quello sopra era solo un esempio: come vedi il limite è la fantasia ed è veramente possibile ricostruire in maniera super-dettagliata il contesto di evento a rischio.

Licensing per attivare lo streaming dei log di Azure AD verso Log Analytics Workspace

Per fare ingestion dei sign-log su Microsoft Sentinel, è necessaria una licenza Azure AD Premium P1 o P2.

  • Connect Azure Active Directory data to Microsoft Sentinel | Microsoft Docs

Per Identity Protection e, quindi, per avere i dati di Risky Sign-Ins e Risky Users è necessaria una licenza Azure AD Premium P2.

Come sempre, se vuoi approfondire ulteriormente l’argomento, ecco altra documentazione utile:

  • Stream Azure Active Directory logs to Azure Monitor logs | Microsoft Docs

Un ringraziamento a Stefano Pescosolido di Microsoft per le utili integrazioni che mi ha fornito sul licensing di questa funzionalità.

Conclusioni

Articolo lungo per una configurazione che, tutto sommato, richiede meno di una decina di click. Quello che però era più importante per me era trasmetterti il motivo per cui questo settaggio è davvero fondamentale per trarre il meglio dall’integrazione tra Identity Protection e Microsoft Sentinel. Spero di avertelo raccontato in maniera completa e chiara.

E tu, usi queste funzionalità? Ti aspetto nei commenti per parlare insieme di Identity Protection e Sentinel! A presto!

Il tuo IT Specialist,
Riccardo

Share on Social Media
linkedin twittertelegramwhatsapp email

Archiviato in:Identity and Security, Il Blog Contrassegnato con: Azure AD Identity Protection, Microsoft Sentinel, Risky Sign-ins, Risky User

Vuoi tenerti aggiornato su quest’argomento?

Iscriviti alla newsletter e ricevi contenuti esclusivi, direttamente alla tua casella di posta.
Poche mail, uniche e speciali, promesso :)

Riccardo Corna

Sono uno specialista IT certificato su tecnologie Microsoft ed Apple con oltre 15 anni di esperienza sul campo.
Aiuto i clienti a costruire il loro Modern Workplace, disegnando ed implementando soluzioni cloud basate su Microsoft 365 ed Azure, secondo un approccio Zero Trust Security e stando al loro fianco durante le fasi decisionali di design ed implementazione. Scopri di più...

Barra laterale primaria

Seguimi!

  • LinkedIn
  • RSS
  • Twitter
  • Youtube

Ciao! Sono Riccardo…

... e supporto il business della tua azienda aiutandoti a sfruttare al meglio servizi e strumenti informatici.
Scopri di più...

Ricerca

Gli ultimi articoli

  • Il video della sessione al Be Connected Day del 15/6/2022: Microsoft Defender for Endpoint
  • Grandi novità per LAPS in Windows 11
  • Adoption kit per Azure AD Application Proxy
  • Microsoft Authenticator Registration Campaign
  • Impressioni sul Be Connected Day #9 – 15 Giugno 2022

Footer

Seguimi!

  • LinkedIn
  • RSS
  • Twitter
  • Youtube

A proposito di me…

Sono un sistemista certificato su tecnologie Microsoft ed Apple con oltre 15 anni di esperienza sul campo.

Scopri di più…

Copyright © 2022 · Digital Pro on Genesis Framework · WordPress · Accedi

  • Vuoi conoscermi meglio? Parti da qui!
  • Privacy Policy