Aggregare i dati di Microsoft Sentinel con regole di riepilogo (anteprima)
Usare le regole di riepilogo in Microsoft Sentinel per aggregare grandi set di dati in background per un'esperienza di operazioni di sicurezza più fluida in tutti i livelli di log. I dati di riepilogo sono precompilati nelle tabelle di log personalizzate e offrono prestazioni di query veloci, incluse le query eseguite sui dati derivati da livelli di log a basso costo. Le regole di riepilogo consentono di ottimizzare i dati per:
- Analisi e report, in particolare in set di dati di grandi dimensioni e intervalli di tempo, in base alle esigenze di analisi della sicurezza e degli eventi imprevisti, ai report aziendali mensili o annuali e così via.
- Risparmio sui costi nei log dettagliati, che è possibile conservare per il minimo o fino a quando è necessario in un livello di log meno costoso e inviare dati riepilogati solo a una tabella di Analisi per l'analisi e i report.
- Sicurezza e privacy dei dati rimuovendo od offuscando i dettagli sulla privacy in dati riepilogati condivisibili e limitando l'accesso alle tabelle con dati non elaborati.
Accedere ai risultati delle regole di riepilogo tramite KQL (Kusto Query Language) tra le attività di rilevamento, indagine, ricerca e creazione di report. Usare i risultati delle regole di riepilogo per periodi più lunghi nelle indagini cronologiche, nella ricerca e nelle attività di conformità.
I risultati delle regole di riepilogo vengono archiviati in tabelle separate nel piano dati Analisi e vengono addebitati di conseguenza. Per altre informazioni sui piani dati e sui costi di archiviazione, vedere Selezionare un piano di tabella in base ai modelli di utilizzo in un'area di lavoro Log Analytics
Importante
Le regole di riepilogo sono attualmente in ANTEPRIMA. Vedere le Condizioni per l'utilizzo supplementari per le anteprime di Microsoft Azure per altre condizioni legali applicabili alle funzionalità di Azure disponibili in versione beta, in anteprima o non ancora rilasciate nella disponibilità generale.
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.
Per creare regole di riepilogo in Microsoft Sentinel:
Microsoft Sentinel deve essere abilitato in almeno un'area di lavoro e usare attivamente i log.
È necessario essere in grado di accedere a Microsoft Sentinel con le autorizzazioni di Collaboratore di Microsoft Sentinel. Per altre informazioni, vedere Ruoli e autorizzazioni in Microsoft Sentinel.
Per creare regole di riepilogo nel portale di Microsoft Defender, è prima necessario eseguire l'onboarding dell'area di lavoro nella piattaforma unificata per le operazioni di sicurezza. Per altre informazioni, vedere Connettere Microsoft Sentinel a Microsoft Defender XDR.
È consigliabile provare la query della regola di riepilogo nella pagina Log prima di creare la regola. Verificare che la query non raggiunga o si avvicini al limite di query e verificare che la query produca lo schema e i risultati previsti. Se la query è vicina ai limiti delle query, è consigliabile usare un binSize
più piccolo per elaborare meno dati per bin. È anche possibile modificare la query per restituire un minor numero di record o rimuovere campi con un volume superiore.
Creare una nuova regola di riepilogo per aggregare un set di dati di grandi dimensioni specifico in una tabella dinamica. Configurare la frequenza delle regole per determinare la frequenza con cui il set di dati aggregati viene aggiornato dai dati non elaborati.
Nel portale di Azure, scegliere Regole di riepilogo (anteprima) dal menu di spostamento di Microsoft Sentinel in Configurazione. Nel portale di Defender selezionare Microsoft Sentinel > Configurazione > Regole di riepilogo (anteprima). Ad esempio:
Selezionare + Crea e immettere i dettagli seguenti:
Nome. Immettere un nome significativo per la regola.
Descrizione. Immettere una descrizione facoltativa.
Tabella di destinazione. Definire la tabella di log personalizzata dove vengono aggregati i dati:
Se si seleziona Tabella log personalizzata esistente, selezionare la tabella da usare.
Se si seleziona Nuova tabella di log personalizzata, immettere un nome significativo per la tabella. Il nome completo della tabella usa la sintassi seguente:
<tableName>_CL
.
È consigliabile abilitare le impostazioni di diagnostica SummaryLogs nell'area di lavoro per ottenere visibilità per le esecuzioni e gli errori cronologici. Se le impostazioni di diagnostica SummaryLogs non sono abilitate, viene richiesto di abilitarle nell'area Impostazioni di diagnostica.
Se le impostazioni di diagnostica SummaryLogs sono già abilitate, ma si desidera modificare le impostazioni, selezionare Configura impostazioni di diagnostica avanzate. Quando si torna alla pagina della procedura guidata Riepilogo regole, assicurarsi di selezionare Aggiorna per aggiornare i dettagli dell'impostazione.
Importante
Le impostazioni di diagnostica SummaryLogs comportano costi aggiuntivi. Per altre informazioni, vedere Impostazioni di diagnostica in Monitoraggio di Azure.
Selezionare Avanti: Impostare la logica di riepilogo> per continuare.
Nella pagina Imposta logica di riepilogo, immettere la query di riepilogo. Ad esempio, per eseguire il pull dei contenuti da Google Cloud Platform, è possibile immettere:
GCPAuditLogs | where ServiceName == 'pubsub.googleapis.com' | summarize count() by Severity
Per altre informazioni, vedere Esempi di scenari di regole di riepilogo e KQL (Kusto Query Language) in Monitoraggio di Azure.
Selezionare Anteprima risultati per visualizzare un esempio dei dati raccolti con la query configurata.
Nell'area Pianificazione query definire i dettagli seguenti:
- Frequenza di esecuzione della regola
- Se si vuole che la regola sia eseguita con qualsiasi tipo di ritardo, in minuti
- Quando si vuole avviare l'esecuzione della regola
I tempi definiti nella pianificazione sono basati sulla colonna
timegenerated
nei datiSelezionare Avanti: Rivedi e crea >>Salva per completare la regola di riepilogo.
Le regole di riepilogo esistenti sono elencate nella pagina Regole di riepilogo (anteprima), in cui è possibile esaminare lo stato della regola. Per ogni regola, selezionare il menu opzioni alla fine della riga per eseguire una delle azioni seguenti:
- Visualizzare i dati correnti della regola nella pagina Log, come se si volesse eseguire immediatamente la query
- Visualizzare la cronologia di esecuzione per la regola selezionata
- Disabilitare o abilitare la regola.
- Modificare la configurazione della regola
Per eliminare una regola, selezionare la riga della regola e quindi selezionare Elimina nella barra degli strumenti nella parte superiore della pagina.
Nota
Monitoraggio di Azure supporta anche la creazione di regole di riepilogo tramite API o un modello di Monitoraggio risorse di Azure. Per altre informazioni, vedere Creare o aggiornare una regola di riepilogo.
Questa sezione esamina gli scenari comuni per la creazione di regole di riepilogo in Microsoft Sentinel e i suggerimenti su come configurare ogni regola. Per altre informazioni ed esempi, vedere Usare regole di riepilogo con log ausiliari (processo di esempio) e Origini log da usare per l'inserimento dei log ausiliari.
Scenario: fingendosi un cacciatore di minacce, uno degli obiettivi del team consiste nell'identificare tutte le istanze di quando un indirizzo IP dannoso interagisce nei log del traffico di rete da un incidente attivo negli ultimi 90 giorni.
Sfida: Microsoft Sentinel attualmente inserisce più terabyte di log di rete al giorno. È necessario spostarsi rapidamente tra di essi per trovare le corrispondenze per l'indirizzo IP dannoso.
Soluzione: è consigliabile usare le regole di riepilogo per eseguire le operazioni seguenti:
Creare un set di dati di riepilogo per ogni indirizzo IP correlato all'evento imprevisto, tra cui
SourceIP
,MaliciousIP
DestinationIP
,RemoteIP
, ognuno che elenca attributi importanti, ad esempioIPType
,FirstTimeSeen
eLastTimeSeen
.Il set di dati di riepilogo consente di cercare rapidamente un indirizzo IP specifico e restringere l'intervallo di tempo in cui viene trovato l'indirizzo IP. È possibile farlo anche quando gli eventi ricercati si sono verificati più di 90 giorni fa, oltre il periodo di conservazione dell'area di lavoro.
In questo esempio, configurare il riepilogo per l'esecuzione giornaliera, in modo che la query aggiunga nuovi record di riepilogo ogni giorno fino alla scadenza.
Creare una regola di analisi eseguita per meno di due minuti rispetto al set di dati di riepilogo, eseguendo rapidamente l’esplorazione dell'intervallo di tempo specifico quando l'indirizzo IP dannoso interagisce con la rete aziendale.
Assicurarsi di configurare intervalli di esecuzione fino a cinque minuti minimo per supportare dimensioni di payload di riepilogo diverse. In questo modo si garantisce che non si verifichi alcuna perdita anche quando si verifica un ritardo di inserimento degli eventi.
Ad esempio:
let csl_columnmatch=(column_name: string) { CommonSecurityLog | where isnotempty(column_name) | extend Date = format_datetime(TimeGenerated, "yyyy-MM-dd"), IPaddress = column_ifexists(column_name, ""), FieldName = column_name | extend IPType = iff(ipv4_is_private(IPaddress) == true, "Private", "Public") | where isnotempty(IPaddress) | project Date, TimeGenerated, IPaddress, FieldName, IPType, DeviceVendor | summarize count(), FirstTimeSeen = min(TimeGenerated), LastTimeSeen = min(TimeGenerated) by Date, IPaddress, FieldName, IPType, DeviceVendor }; union csl_columnmatch("SourceIP") , csl_columnmatch("DestinationIP") , csl_columnmatch("MaliciousIP") , csl_columnmatch("RemoteIP") // Further summarization can be done per IPaddress to remove duplicates per day on larger timeframe for the first run | summarize make_set(FieldName), make_set(DeviceVendor) by IPType, IPaddress
Eseguire una ricerca o una correlazione successiva con altri dati per completare la storia di attacco.
Generare avvisi sulle corrispondenze di Intelligence sulle minacce con i dati di rete di tipo rumoroso, elevato volume e valore di sicurezza basso.
Scenario: è necessario creare una regola di analisi per i log del firewall in modo che corrispondano ai nomi di dominio nel sistema visitati rispetto a un elenco dei nomi di dominio di Intelligence per le minacce.
La maggior parte delle origini dati sono log non elaborati che sono rumorosi e hanno un volume elevato, ma hanno un valore di sicurezza inferiore, inclusi gli indirizzi IP, il traffico di Firewall di Azure, il traffico Fortigate e così via. È presente un volume totale di circa 1 TB al giorno.
Sfida: la creazione di regole separate richiede più app per la logica, che richiedono costi e costi aggiuntivi per la configurazione e la manutenzione.
Soluzione: è consigliabile usare le regole di riepilogo per eseguire le operazioni seguenti:
Riepilogare i log del firewall McAfee ogni 10 minuti, aggiornando i dati nella stessa tabella personalizzata con ogni esecuzione. Le funzioni ASIM potrebbero essere utili nella query di riepilogo durante l'interazione con i log di McAfee.
Creare una regola di analitica per attivare un avviso per ogni volta che un nome di dominio nei dati di riepilogo corrisponde a una voce nell'elenco di intelligence per le minacce. Ad esempio:
//let timeRange = 5m; //let httpstrim = "https://"; //let httptrim = "http://"; let timeRangeStart = now (-10m); let timeRangeEnd = (timeRangeStart + 10m); //Take visited domains from McAfee proxy adx('https://adxfwlog01.northeurope.kusto.windows.net/nwlogs').MappedMcAfeeSyslog | where timestamp between (timeRangeStart .. timeRangeEnd) | where isnotempty(URL) | extend URLDomain = parse_url(URL).Host | extend URLDomain = iff(isempty(URLDomain),URL,URLDomain) | extend URLDomain = extract(@"([0-9a-zA-Z-]{1,}\.[0-9a-zA-Z-]{2,3}\.[0-9a-zA-Z-]{2,3}|[0-9a-zA-Z-]{1,}\.[0-9a-zA-Z-]{2,10})$", 0, URLDomain) | where isnotempty(URLDomain) | summarize by URLDomain //Match visited domains with TI DomainName list | join kind=inner (ThreatIntelligenceIndicator | where isnotempty(DomainName) | where Active == true | where ExpirationDateTime > now() | summarize LatestIndicatorTime = arg_max(TimeGenerated, *) by DomainName ) on $left.URLDomain == $right.DomainName | extend LogicApp = "SOC-McAfee-ADX-DstDomainAgainstThreatIntelligence" | project LatestIndicatorTime, TI_Domain = DomainName, Description, ConfidenceScore, AdditionalInformation, LogicApp
Questa procedura descrive un processo di esempio per l'uso di regole di riepilogo con log ausiliari, usando una connessione personalizzata creata tramite un modello ARM per inserire dati CEF da Logstash.
Configurare il connettore CEF personalizzato da Logstash:
Distribuire il modello di Resource Manager seguente nell'area di lavoro di Microsoft Sentinel per creare una tabella personalizzata con regole di raccolta dati (DCR) e un endpoint di raccolta dati (DCE):
Prendere nota dei dettagli seguenti dall'output del modello di Resource Manager:
tenant_id
data_collection_endpoint
dcr_immutable_id
dcr_stream_name
Creare un'applicazione Microsoft Entra e prendere nota dell'ID client e del segreto dell'applicazione. Per altre informazioni, vedere Esercitazione: Inviare dati ai log di Monitoraggio di Azure con l'API di inserimento log (portale di Azure).
Usare lo script di esempio per aggiornare il file di configurazione Logstash. Gli aggiornamenti configurano Logstash per inviare i log CEF alla tabella personalizzata creata dal modello di Resource Manager, trasformando i dati JSON in formato DCR. In questo script, assicurarsi di sostituire i valori segnaposto con i propri valori per la tabella personalizzata e l'app Microsoft Entra creata in precedenza.
Verificare che i dati CEF vengano trasmessi da Logstash come previsto. Ad esempio, in Microsoft Sentinel passare alla pagina Log ed eseguire la query seguente:
CefAux_CL | take 10
Creare regole di riepilogo che aggregano i dati CEF. Ad esempio:
Ricerca dei dati riguardanti l’incidente motivo di preoccupazione (IoC):cercare IoC specifici eseguendo query di riepilogo aggregate per portare occorrenze univoche e quindi eseguire query solo su tali occorrenze per ottenere risultati più veloci. L'esempio seguente mostra un esempio di come portare un feed univoco
Source Ip
insieme ad altri metadati, che possono quindi essere usati per le ricerche IoC:// Daily Network traffic trend Per Destination IP along with Data transfer stats // Frequency - Daily - Maintain 30 day or 60 Day History. Custom_CommonSecurityLog | extend Day = format_datetime(TimeGenerated, "yyyy-MM-dd") | summarize Count= count(), DistinctSourceIps = dcount(SourceIP), NoofByesTransferred = sum(SentBytes), NoofBytesReceived = sum(ReceivedBytes) by Day,DestinationIp, DeviceVendor
Eseguire una query su una linea di base di riepilogo per rilevare le anomalie. Anziché eseguire query su periodi cronologici di grandi dimensioni, ad esempio 30 o 60 giorni, è consigliabile inserire dati in log personalizzati e quindi eseguire query solo sui dati di base di riepilogo, ad esempio per i rilevamenti di anomalie delle serie temporali. Ad esempio:
// Time series data for Firewall traffic logs let starttime = 14d; let endtime = 1d; let timeframe = 1h; let TimeSeriesData = Custom_CommonSecurityLog | where TimeGenerated between (startofday(ago(starttime))..startofday(ago(endtime))) | where isnotempty(DestinationIP) and isnotempty(SourceIP) | where ipv4_is_private(DestinationIP) == false | project TimeGenerated, SentBytes, DeviceVendor | make-series TotalBytesSent=sum(SentBytes) on TimeGenerated from startofday(ago(starttime)) to startofday(ago(endtime)) step timeframe by DeviceVendor