Regole di analisi pianificate in Microsoft Sentinel

Per gran parte il tipo più comune di regola di analisi, regole di pianificate sono basate su query Kusto configurate per l'esecuzione a intervalli regolari ed esaminare i dati non elaborati da un periodo di "lookback" definito. Le query possono eseguire operazioni statistiche complesse sui dati di destinazione, rivelando baseline e outlier in gruppi di eventi. Se il numero di risultati acquisiti dalla query supera la soglia configurata nella regola, la regola genera un avviso.

Questo articolo illustra come vengono compilate le regole di analisi pianificate e presenta tutte le opzioni di configurazione e i relativi significati. Le informazioni contenute in questo articolo sono utili in due scenari:

Importante

Microsoft Sentinel è disponibile al pubblico nel portale di Microsoft Defender nella della piattaforma operativa di sicurezza unificata Microsoft. Per altre informazioni, vedere Microsoft Sentinel nel portale di Microsoft Defender.

Modelli di regole di analisi

Le query in modelli di regole pianificati sono state scritte da esperti di sicurezza e data science, Microsoft o dal fornitore della soluzione che fornisce il modello.

Usare un modello di regola di analisi selezionando un nome di modello dall'elenco dei modelli e creando una regola basata su di essa.

Ogni modello include un elenco delle origini dati necessarie. Quando si apre il modello, le origini dati vengono controllate automaticamente per la disponibilità. La disponibilità indica che l'origine dati è connessa e che i dati vengono inseriti regolarmente attraverso di esso. Se una delle origini dati necessarie non è disponibile, non sarà consentito creare la regola e potrebbe essere visualizzato anche un messaggio di errore.

Quando si crea una regola da un modello, viene aperta la creazione guidata delle regole in base al modello selezionato. Tutti i dettagli vengono compilati automaticamente ed è possibile personalizzare la logica e altre impostazioni delle regole in base alle esigenze specifiche. È possibile ripetere questo processo per creare più regole in base al modello. Quando si raggiunge la fine della creazione guidata delle regole, le personalizzazioni vengono convalidate e la regola viene creata. Le nuove regole vengono visualizzate nella scheda Regole attive nella pagina Analisi. Analogamente, nella scheda Modelli di regola, il modello da cui è stata creata la regola viene ora visualizzato con il tag In use.

I modelli di regola di analisi vengono costantemente gestiti dagli autori, per correggere i bug o per perfezionare la query. Quando un modello riceve un aggiornamento, tutte le regole basate su tale modello vengono visualizzate con il tag Update e si ha la possibilità di modificare tali regole per includere le modifiche apportate al modello. È anche possibile ripristinare le modifiche apportate in una regola alla versione originale basata su modello. Per altre informazioni, vedere Gestire le versioni dei modelli per le regole di analisi pianificate in Microsoft Sentinel.

Dopo aver familiarità con le opzioni di configurazione in questo articolo, vedere Creare regole di analisi pianificate dai modelli.

Il resto di questo articolo illustra tutte le possibilità per personalizzare la configurazione delle regole.

Configurazione delle regole di analisi

Questa sezione illustra le considerazioni chiave da tenere in considerazione prima di iniziare a configurare le regole.

Nome e dettagli della regola di analisi

La prima pagina della procedura guidata delle regole di analisi contiene le informazioni di base della regola.

Nome: il nome della regola come viene visualizzato nell'elenco delle regole e in qualsiasi filtro basato su regole. Il nome deve essere univoco nell’area di lavoro.

Descrizione: una descrizione in formato testo libero dello scopo della regola.

ID: GUID della regola come risorsa di Azure, usata in richieste e risposte API, tra le altre cose. Questo GUID viene assegnato solo quando viene creata la regola, quindi viene visualizzato solo quando si modifica una regola esistente. Poiché si tratta di un campo di sola lettura, viene visualizzato come disattivato e non può essere modificato. Non esiste ancora quando si crea una nuova regola, da un modello o da zero.

Gravità: una valutazione per assegnare gli avvisi generati da questa regola. La gravità di un'attività è un calcolo del potenziale impatto negativo dell'occorrenza dell'attività.

Gravità Descrizione
Informativo Nessun impatto sul sistema, ma le informazioni potrebbero essere indicative di passaggi futuri pianificati da un attore di minacce.
Basso L'impatto immediato sarebbe minimo. È probabile che un attore di minacce debba eseguire più passaggi prima di ottenere un impatto su un ambiente.
Medium L'attore di minacce potrebbe avere un impatto sull'ambiente con questa attività, ma potrebbe essere limitato nell'ambito o richiedere attività aggiuntive.
Alto L'attività identificata fornisce all'attore di minaccia un accesso ampio per eseguire azioni sull'ambiente o viene attivato dall'impatto sull'ambiente.

Le impostazioni predefinite del livello di gravità non sono una garanzia del livello di impatto attuale o ambientale. Personalizzare i dettagli dell'avviso per personalizzare la gravità, le tattiche e altre proprietà di una determinata istanza di un avviso con i valori di tutti i campi pertinenti di un output della query.

Le definizioni di gravità per i modelli di regole di analisi di Microsoft Sentinel sono rilevanti solo per gli avvisi creati dalle regole di analisi. Per gli avvisi inseriti da altri servizi, la gravità viene definita dal servizio di sicurezza di origine.

MITRE ATT&CK: una specifica delle tattiche e delle tecniche di attacco rappresentate dalle attività acquisite da questa regola. Si basano sulle tattiche e sulle tecniche del framework MITRE ATT&CK®.

Le tattiche e le tecniche MITRE ATT&CK definite qui nella regola si applicano a tutti gli avvisi generati dalla regola. Si applicano anche a tutti gli eventi imprevisti creati da questi avvisi.

Per altre informazioni sull'ottimizzazione della copertura del panorama delle minacce MITRE ATT&CK, vedere Informazioni sulla copertura della sicurezza da parte del framework MITRE ATT&CK®.

Stato: quando si crea la regola, il relativo Stato è Abilitato per impostazione predefinita, il che significa che viene eseguito immediatamente dopo averlo creato. Se non si vuole eseguirlo immediatamente, sono disponibili due opzioni:

  • Selezionare Disabilitato e la regola viene creata senza eseguire. Quando si vuole che la regola venga eseguita, trovarla nella scheda Regole attive e abilitarla da questa posizione.
  • Pianificare la prima esecuzione della regola in una data e un'ora specifiche. Questo metodo è attualmente in ANTEPRIMA. Vedere Pianificazione query più avanti in questo articolo.

Query delle regole

Questa è l'essenza della regola: si decide quali informazioni si trovano negli avvisi creati da questa regola e come vengono organizzate le informazioni. Questa configurazione ha effetti di follow-on sull'aspetto degli eventi imprevisti risultanti e su quanto siano facili o difficili da analizzare, correggere e risolvere. È importante rendere gli avvisi il più ricco possibile di informazioni e rendere tali informazioni facilmente accessibili.

Visualizzare o immettere la query Kusto che analizza i dati di log non elaborati. Se si crea una regola da zero, è consigliabile pianificare e progettare la query prima di aprire questa procedura guidata. È possibile compilare e testare query nella pagina Log.

Tutto ciò che si digita nella finestra di query delle regole viene convalidato immediatamente, quindi è possibile individuare immediatamente se si verificano errori.

Procedure consigliate per le query sulle regole di analisi

  • È consigliabile usare un parser ASIM (Advanced Security Information Model) come origine query, anziché usare una tabella nativa. In questo modo, la query supporta qualsiasi origine dati corrente o futura pertinente o famiglia di origini dati, anziché basarsi su una singola origine dati.

  • La lunghezza della query deve essere compresa tra 1 e 10.000 caratteri e non può contenere "search *" o "union *". È possibile usare funzioni definite dall'utente per superare la limitazione della lunghezza della query, in quanto una singola funzione può sostituire decine di righe di codice.

  • L'uso delle funzioni ADX per creare query di Esplora dati di Azure all'interno della finestra di query di Log Analytics non è supportato.

  • Quando si usa la funzione bag_unpack in una query, se si proiettano le colonne come campi usando "project field1" e la colonna non esiste, la query avrà esito negativo. Per evitare questo problema, è necessario proiettare la colonna come indicato di seguito:

    project field1 = column_ifexists("field1","")

Per altre informazioni sulla creazione di query Kusto, vedere linguaggio di query Kusto in Microsoft Sentinel e Procedure consigliate per le query del linguaggio di query Kusto.

Miglioramento degli avvisi

Per visualizzare i risultati degli avvisi in modo che possano essere immediatamente visibili negli eventi imprevisti e monitorati e esaminati in modo appropriato, usare la configurazione di miglioramento dell'avviso per visualizzare tutte le informazioni importanti negli avvisi.

Questo miglioramento dell'avviso ha il vantaggio aggiunto di presentare i risultati in modo facilmente visibile e accessibile.

Sono disponibili tre tipi di miglioramenti per gli avvisi che è possibile configurare:

  • Mapping di entità
  • Dettagli personalizzati
  • Dettagli avviso (noto anche come contenuto dinamico)

Mapping di entità

Le entità sono i giocatori su entrambi i lati di qualsiasi storia di attacco. L'identificazione di tutte le entità in un avviso è essenziale per rilevare e analizzare le minacce. Per assicurarsi che Microsoft Sentinel identifichi le entità nei dati non elaborati, è necessario eseguire il mapping dei tipi di entità riconosciuti da Microsoft Sentinel nei campi nei risultati della query. Questo mapping integra le entità identificate nel campo Entità nello schema di avviso.

Per altre informazioni sul mapping delle entità e per ottenere istruzioni complete, vedere Eseguire il mapping dei campi dati alle entità in Microsoft Sentinel.

Dettagli personalizzati

Per impostazione predefinita, solo le entità di avviso e i metadati sono visibili negli eventi imprevisti senza eseguire il drill-down negli eventi non elaborati nei risultati della query. Per assegnare agli altri campi la visibilità immediata dei risultati della query negli avvisi e negli eventi imprevisti, definirli come dettagli personalizzati. Microsoft Sentinel integra questi dettagli personalizzati nel campo ExtendedProperties negli avvisi, causando la visualizzazione prima degli avvisi e in tutti gli eventi imprevisti creati da tali avvisi.

Per altre informazioni sulla visualizzazione dei dettagli personalizzati e per ottenere istruzioni complete, vedere Dettagli dell'evento personalizzato di Surface negli avvisi in Microsoft Sentinel.

Dettagli dell'avviso

Questa impostazione consente di personalizzare le proprietà degli avvisi standard in base al contenuto di vari campi in ogni singolo avviso. Queste personalizzazioni sono integrate nel campo ExtendedProperties negli avvisi. Ad esempio, è possibile personalizzare il nome o la descrizione dell'avviso per includere un nome utente o un indirizzo IP in primo piano nell'avviso.

Per altre informazioni sulla personalizzazione dei dettagli dell'avviso e per ottenere istruzioni complete, vedere Personalizzare i dettagli dell'avviso in Microsoft Sentinel.

Nota

Nella piattaforma unificata per le operazioni di sicurezza, il motore di correlazione Defender XDR è esclusivamente responsabile della denominazione degli eventi imprevisti, pertanto tutti i nomi di avviso personalizzati possono essere ignorati quando vengono creati eventi imprevisti da questi avvisi.

Pianificazione query

I parametri seguenti determinano la frequenza con cui verrà eseguita la regola pianificata e il periodo di tempo che esaminerà ogni volta che viene eseguito.

Impostazione Comportamento
Eseguire query ogni Controlla l’intervallo di query: con quale frequenza viene eseguita la query.
Cerca dati dai più recenti Determina il periodo di ricerca: il periodo di tempo coperto dalla query.
  • L'intervallo consentito per entrambi questi parametri è compreso tra 5 minuti e 14 giorni.

  • L'intervallo di query deve essere più breve o uguale al periodo di ricerca. Se è più breve, i periodi di query si sovrappongono e ciò può causare una duplicazione dei risultati. La convalida della regola non consentirà di impostare un intervallo più lungo del periodo di lookback, tuttavia, in quanto causerebbe lacune nella copertura.

L'impostazione Avvia l'esecuzione, ora in ANTEPRIMA, consente di creare una regola con stato Abilitato, ma di ritardare la prima esecuzione fino a una data e un'ora predeterminate. Questa impostazione è utile se si vuole regolare l'esecuzione delle regole in base a quando si prevede che i dati vengano inseriti dall'origine o quando gli analisti SOC iniziano la giornata lavorativa.

Impostazione Comportamento
Automatico La regola verrà eseguita per la prima volta immediatamente dopo la creazione e successivamente all'intervallo impostato nell’impostazione Esegui query ogni.
In un momento specifico (anteprima) Impostare una data e un'ora per la prima esecuzione della regola, dopo la quale verrà eseguita a intervalli impostati nell'impostazione Esegui query ogni.
  • L’orario di avvio dell'esecuzione deve essere compreso tra 10 minuti e 30 giorni dopo l'ora di creazione o abilitazione della regola.

  • La riga di testo sotto l'impostazione Avvia esecuzione (con l'icona delle informazioni a sinistra) riepiloga e impostazioni correnti di pianificazione delle query e lookback.

    Screenshot dell'interruttore e delle impostazioni avanzate della pianificazione.

Nota

Ritardo inserimento

Per tenere conto della latenza che può verificarsi tra la generazione di un evento all'origine e l'inserimento in Microsoft Sentinel e per garantire la copertura completa senza duplicazione dei dati, Microsoft Sentinel esegue regole di analisi pianificate in un ritardo di cinque minuti dall'ora pianificata.

Per altre informazioni, vedere Gestire il ritardo di inserimento nelle regole di analisi pianificate.

Soglia di avviso

Molti tipi di eventi di sicurezza sono normali o addirittura previsti in piccoli numeri, ma sono un segno di una minaccia in numeri maggiori. Diverse scale di numeri elevati possono significare diversi tipi di minacce. Ad esempio, due o tre tentativi di accesso non riusciti nello spazio di un minuto sono un segno di un utente che non ricorda una password, ma cinquanta in un minuto potrebbero essere un segno di un attacco umano e mille è probabilmente un attacco automatizzato.

A seconda del tipo di attività che la regola sta tentando di rilevare, è possibile impostare un numero minimo di eventi (risultati della query) necessari per attivare un avviso. La soglia viene applicata separatamente a ogni esecuzione della regola, non collettivamente.

La soglia può anche essere impostata su un numero massimo di risultati o su un numero esatto.

Raggruppamento di eventi

Esistono due modi per gestire il raggruppamento di eventi in avvisi:

  • Raggruppa tutti gli eventi in un singolo avviso: Questa è l'impostazione predefinita. La regola genera un singolo avviso ogni volta che viene eseguito, purché la query restituisca più risultati rispetto alla specificata soglia di avviso illustrata nella sezione precedente. Questo singolo avviso riepiloga tutti gli eventi restituiti nei risultati della query.

  • Attivare un avviso per ogni evento: la regola genera un avviso univoco per ogni evento (risultato) restituito dalla query. Questa modalità è utile se si desidera che gli eventi vengano visualizzati singolarmente o se si desidera raggrupparli in base a determinati parametri, ad esempio utente, nome host o altro. È possibile definire questi parametri nella query. |

Le regole di analisi possono generare fino a 150 avvisi. Se Raggruppamento di eventi è impostato su Attivare un avviso per ogni evento e la query della regola restituisce più di 150 eventi, i primi 149 eventi genereranno un avviso univoco (per 149 avvisi) e il 150° avviso riepilogherà l'intero set di eventi restituiti. In altre parole, il 150° avviso è quello che sarebbe stato generato se Raggruppamento di eventi fosse stato impostato su Raggruppare tutti gli eventi in un singolo avviso.

L'impostazione Attivare un avviso per ogni evento potrebbe causare un problema per cui i risultati della query sembrano mancanti o diversi dal previsto. Per altre informazioni su questo scenario, vedere Regole di analisi della risoluzione dei problemi in Microsoft Sentinel | Problema: non vengono visualizzati eventi nei risultati della query.

Eliminazione degli avvisi

Se si vuole che questa regola interrompa il funzionamento per un periodo di tempo dopo la generazione di un avviso, attivare Arresta l'esecuzione della query dopo la generazione dell'avviso impostazione On. È quindi necessario impostare Interrompere l'esecuzione della query per sulla quantità di tempo in cui la query deve interrompere l'esecuzione, fino a 24 ore.

Simulazione dei risultati

La procedura guidata per la regola di analisi consente di testarne l'efficacia eseguendola nel set di dati corrente. Quando si esegue il test, la finestra Simulazione risultati mostra un grafico dei risultati che la query avrebbe generato negli ultimi 50 volte che sarebbe stata eseguita, in base alla pianificazione attualmente definita. Se si modifica la query, è possibile eseguire di nuovo il test per aggiornare il grafico. Il grafico mostra il numero di risultati nel periodo di tempo definito, determinato dalla pianificazione della query definita.

Ecco l'aspetto della simulazione dei risultati per la query nello screenshot precedente. Il lato sinistro è la visualizzazione predefinita e il lato destro è quello che viene visualizzato quando si passa il puntatore del mouse su un punto nel tempo sul grafico.

Screenshot delle simulazioni dei risultati.

Se si nota che la query attiverebbe troppi avvisi o troppo frequenti, è possibile sperimentare le impostazioni di pianificazione e soglia ed eseguire di nuovo la simulazione.

Impostazioni degli eventi imprevisti

Scegliere se Microsoft Sentinel trasforma gli avvisi in eventi imprevisti interattivi.

La creazione di eventi imprevisti è abilitata per impostazione predefinita. Microsoft Sentinel crea un singolo evento imprevisto separato da ogni avviso generato dalla regola.

Se non si vuole che questa regola comporti la creazione di incidenti (ad esempio, se questa regola serve solo per raccogliere informazioni per l'analisi successiva), impostare questa opzione su Disabilitato.

Importante

Se è stato eseguito l'onboarding di Microsoft Sentinel nella piattaforma unificata per le operazioni di sicurezza, Microsoft Defender XDR è responsabile della creazione di eventi imprevisti. Tuttavia, se si vuole che Defender XDR crei eventi imprevisti per questo avviso, è necessario lasciare questa impostazione come Abilitata. Defender XDR accetta l'istruzione definita qui.

Questo non deve essere confuso con il tipo sicurezza Microsoft di regola di analisi che crea eventi imprevisti per gli avvisi generati nei servizi Microsoft Defender. Queste regole vengono disabilitate automaticamente quando si esegue l'onboarding di Microsoft Sentinel nella piattaforma unificata per le operazioni di sicurezza.

Se si vuole creare un singolo evento imprevisto da un gruppo di avvisi, anziché uno per ogni singolo avviso, vedere la sezione successiva.

Alert grouping

Scegliere se raggruppare gli avvisi in eventi imprevisti. Per impostazione predefinita, Microsoft Sentinel crea un evento imprevisto per ogni avviso generato. È possibile raggruppare diversi avvisi in un singolo evento imprevisto.

L'evento imprevisto viene creato solo dopo la generazione di tutti gli avvisi. Tutti gli avvisi vengono aggiunti all'evento imprevisto immediatamente dopo la creazione.

È possibile raggruppare fino a 150 avvisi in un singolo evento imprevisto. Se più di 150 avvisi vengono generati da una regola che li raggruppa in un singolo evento imprevisto, viene generato un nuovo evento imprevisto con gli stessi dettagli dell'evento imprevisto originale e gli avvisi in eccesso vengono raggruppati nel nuovo evento imprevisto.

Per raggruppare gli avvisi, impostare l'impostazione di raggruppamento degli avvisi su Abilitato.

Esistono alcune opzioni da considerare quando si raggruppano gli avvisi:

  • Intervallo di tempo: per impostazione predefinita, gli avvisi creati fino a 5 ore dopo il primo avviso in un evento imprevisto vengono aggiunti allo stesso evento imprevisto. Dopo 5 ore viene creato un nuovo evento imprevisto. È possibile modificare questo periodo di tempo in qualsiasi punto tra 5 minuti e 7 giorni.

  • Criteri di raggruppamento: scegliere come determinare quali avvisi sono inclusi nel gruppo. La tabella seguente illustra le possibili scelte:

    Opzione Descrizione
    Raggruppa gli avvisi in un singolo evento imprevisto se tutte le entità corrispondono Gli avvisi vengono raggruppati se condividono valori identici per ognuna delle entità mappate definite in precedenza. Questa è l'impostazione consigliata.
    Raggruppa tutti gli avvisi generati da questa regola in un singolo incidente Tutti gli avvisi generati da questa regola vengono raggruppati insieme anche se non condividono valori identici.
    Raggruppamento degli avvisi in un singolo evento imprevisto in caso di corrispondenza dei tipi di entità e dei dettagli selezionati Gli avvisi vengono raggruppati se condividono valori identici per tutte le entità mappate, dettagli dell'avviso e dettagli personalizzati selezionati per questa impostazione. Scegliere le entità e i dettagli dagli elenchi a discesa visualizzati quando si seleziona questa opzione.

    È possibile usare questa impostazione se, ad esempio, si desidera creare eventi imprevisti separati in base agli indirizzi IP di origine o di destinazione oppure se si desidera raggruppare avvisi che corrispondono a un'entità e una gravità specifiche.

    Nota: quando si seleziona questa opzione, è necessario avere almeno un'entità o un dettaglio selezionato per la regola. In caso contrario, la convalida della regola ha esito negativo e la regola non viene creata.
  • Riaprire gli eventi imprevisti: se un incidente è stato risolto e chiuso e successivamente viene generato un altro avviso che deve appartenere a tale incidente, impostare questa impostazione su Abilitato se si vuole riaprire l'incidente chiuso e lasciare Disabilitato se si vuole che il nuovo avviso crei un nuovo incidente.

    L'opzione per riaprire gli eventi imprevisti chiusi è non disponibile se è stato eseguito l'onboarding di Microsoft Sentinel nella piattaforma unificata per le operazioni di sicurezza.

Risposta automatica

Microsoft Sentinel consente di impostare risposte automatizzate in modo che si verifichino quando:

  • Un avviso viene generato da questa regola di analisi.
  • Un evento imprevisto viene creato dagli avvisi generati da questa regola di analisi.
  • Un evento imprevisto viene aggiornato con gli avvisi generati da questa regola di analisi.

Per informazioni sui diversi tipi di risposte che possono essere create e automatizzate, vedere Automatizzare la risposta alle minacce in Microsoft Sentinel con regole di automazione.

Nell'intestazione Regole di automazione, la procedura guidata visualizza un elenco delle regole di automazione già definite nell'intera area di lavoro, le cui condizioni si applicano a questa regola di analisi. È possibile modificare una di queste regole esistenti oppure creare una nuova regola di automazione applicabile solo a questa regola di analisi.

Usare le regole di automazione per eseguire valutazione di base, assegnazione, flusso di lavoro e chiusura degli eventi imprevisti.

Automatizzare attività più complesse e richiamare risposte da sistemi remoti per correggere le minacce chiamando playbook da queste regole di automazione. È possibile richiamare playbook per eventi imprevisti e per singoli avvisi.

  • Per altre informazioni e istruzioni sulla creazione di playbook e regole di automazione, vedere Automatizzare le risposte alle minacce.

  • Per altre informazioni su quando usare il trigger creato evento imprevisto, il trigger aggiornato evento imprevisto o il trigger creato avviso, vedere Usare trigger e azioni nei playbook di Microsoft Sentinel.

  • Nell'intestazione Automazione avvisi (versione classica) potrebbe essere visualizzato un elenco di playbook configurati per l'esecuzione automatica usando un metodo precedente a causa della deprecata nel mese di marzo 2026. Non è possibile aggiungere nulla a questo elenco. Tutti i playbook elencati qui devono avere regole di automazione create, in base al trigger creato avviso, per richiamare i playbook. Dopo aver completato questa operazione, selezionare i puntini di sospensione alla fine della riga del playbook elencato qui e selezionare Rimuovi. Per le istruzioni complete, vedere Eseguire la migrazione dei playbook di attivazione degli avvisi di Microsoft Sentinel alle regole di automazione.

Passaggi successivi

Quando si usano le regole di analisi di Microsoft Sentinel per rilevare le minacce nell'ambiente, assicurarsi di abilitare tutte le regole associate alle origini dati connesse per garantire la copertura completa della sicurezza per l'ambiente in uso.

Per automatizzare l'abilitazione delle regole, eseguire il push delle regole in Microsoft Sentinel tramite API e PowerShell, anche se questa operazione richiede ulteriore sforzo. Quando si usa l'API o PowerShell, è prima necessario esportare le regole in JSON prima di abilitare le regole. L'API o PowerShell può essere utile quando si abilitano regole in più istanze di Microsoft Sentinel con impostazioni identiche in ogni istanza.

Per altre informazioni, vedi:

Inoltre, sono fornite informazioni su un esempio dell'uso di regole di analisi personalizzate durante il monitoraggio di Zoom con un connettore personalizzato.