Eseguire la migrazione delle regole di rilevamento di Splunk a Microsoft Sentinel

Le regole di rilevamento di Splunk sono componenti di gestione delle informazioni e degli eventi di sicurezza (SIEM) che corrispondono alle regole analitiche di Microsoft Sentinel. Questo articolo descrive i concetti per identificarli, confrontarli ed eseguirne la migrazione a Microsoft Sentinel. Il modo migliore per eseguire la migrazione delle regole di rilevamento di Splunk a Microsoft Sentinel consiste nell'iniziare con l'esperienza di migrazione SIEM, che identifica le regole di analisi predefinite (OOTB) per la traduzione automatica.

Per eseguire la migrazione della distribuzione di Splunk Observability, vedere altre informazioni su come eseguire la migrazione da Splunk a Monitoraggio di Azure Logs.

Regole di controllo

Microsoft Sentinel usa l'analisi di Machine Learning per creare eventi imprevisti ad alta fedeltà e interattivi. Alcuni dei rilevamenti di Splunk esistenti potrebbero essere ridondanti in Microsoft Sentinel, quindi non eseguirne la migrazione ciecamente. Esamina le seguenti considerazioni sulla verifica delle regole mentre identifichi le tue regole di rilevamento esistenti.

• Assicurarsi di selezionare i casi d'uso che giustificano la migrazione delle regole, considerando la priorità aziendale e l'efficienza.
• Verifica di comprendere i tipi di regole di Microsoft Sentinel.
• Verificare di comprendere la terminologia delle regole.
• Esaminare le regole obsolete che non dispongono di avvisi negli ultimi 6-12 mesi e determinare se sono ancora pertinenti.
• Eliminare le minacce o gli avvisi di basso livello che si ignorano regolarmente.
• Microsoft Sentinel Analytics richiede che il tipo di dati sia presente nell'area di lavoro Log Analytics prima dell'abilitazione di una regola. Verificate che le origini dati richieste siano collegate e controllate i metodi di connessione dei dati. Rivedere le conversazioni di raccolta dati per garantire profondità e ampiezza dei dati nei casi d'uso che si prevede di rilevare. Usare quindi l'esperienza di migrazione SIEM per assicurarsi che il mapping delle origini dati venga eseguito in modo appropriato.

Eseguire la migrazione delle regole

Dopo aver identificato i rilevamenti di Splunk da migrare, esaminare le considerazioni seguenti sul processo di migrazione:

• Confrontare le funzionalità esistenti delle regole di analisi OOTB di Microsoft Sentinel con i casi d'uso correnti. Usa l'esperienza di migrazione SIEM per vedere quali rilevazioni di Splunk vengono convertite automaticamente in template OOTB.
• Tradurre i rilevamenti che non sono allineati alle regole di analisi OOTB. Il modo migliore per tradurre automaticamente i rilevamenti di Splunk consiste nell'esperienza di migrazione SIEM.
• Scoprire altri algoritmi per i casi d'uso esplorando le risorse della community, ad esempio soc Prime Threat Detection Marketplace.
• Tradurre manualmente i rilevamenti se le regole predefinite non sono disponibili o non vengono tradotte automaticamente. Crea le nuove query KQL ed esamina la mappatura delle regole.

Per altre informazioni, vedere procedure consigliate per la migrazione delle regole di rilevamento.

Procedura di migrazione delle regole

Seguire questa procedura per convalidare, convertire e testare ogni regola di rilevamento di Splunk durante la migrazione a Microsoft Sentinel.

1. Verificare di disporre di un sistema di test per ogni regola di cui si vuole eseguire la migrazione.

   1. Preparare un processo di convalida per le regole di cui è stata eseguita la migrazione, inclusi scenari di test completi e script.

   2. Assicurarsi che il team disponga di risorse utili per testare le regole di cui è stata eseguita la migrazione.

   3. Verificare di avere le origini dati necessarie connesse ed esaminare i metodi di connessione dati.

2. Verificare se i rilevamenti sono disponibili come modelli OOTB in Microsoft Sentinel:

   • Usare l'esperienza di migrazione SIEM per automatizzare la traduzione e l'installazione dei modelli OOTB.

     Per altre informazioni, vedere Usare l'esperienza di migrazione SIEM.

   • Se i casi d'uso non sono riportati nei rilevamenti, creare regole per la propria area di lavoro con modelli di regole OOTB.

     In Microsoft Sentinel, vai a Hub contenuti.

     Filtra Tipo di contenuto per i modelli delle regole di Analytics.

     Trova e installa/aggiorna ogni soluzione di Content hub corrispondente o il modello di regola di analisi autonomo corrispondente.

     Per altre informazioni, vedere Rilevare subito le minacce.

   • Se sono presenti rilevamenti non coperti dalle regole OOTB di Microsoft Sentinel, provare prima di tutto l'esperienza di migrazione SIEM per la traduzione automatica.

   • Se né le regole OOTB né la migrazione SIEM traducono completamente il rilevamento, creare la regola manualmente. Per creare la regola, seguire questa procedura:

     1. Identificare le origini dati da usare nella regola. Identificare le Microsoft Sentinel tabelle su cui si vuole eseguire una query creando una tabella di mapping tra origini dati e tabelle dati.

     2. Identificare eventuali attributi, campi o entità nei dati che si desidera usare nelle regole.

     3. Identificare i criteri e la logica delle regole. Quando si identificano i criteri e la logica delle regole, è consigliabile usare i modelli di regola come esempi per creare query KQL.

        Si considerino filtri, regole di correlazione, elenchi attivi, set di riferimento, watchlist, anomalie di rilevamento, aggregazioni e così via. È possibile usare i riferimenti forniti da SIEM legacy per comprendere come eseguire il mapping migliore della sintassi di query.

     4. Identificare la condizione di attivazione e l'azione della regola, quindi costruire e rivedere la query KQL. Quando analizzi la query, considera le risorse di riferimento per l'ottimizzazione KQL.

3. Testare la regola con ognuno dei casi d'uso pertinenti. Se non fornisce i risultati previsti, esaminare e modificare il KQL e testarlo di nuovo.

4. Quando si è soddisfatti, si può considerare la regola migrata. Creare un playbook per l'azione della regola in base alle esigenze. Per ulteriori informazioni, vedere Automatizzare la risposta alle minacce con i playbook in Microsoft Sentinel.

Altre informazioni sulle regole di analisi:

• Creare regole di analisi personalizzate per rilevare le minacce. Usare il raggruppamento degli avvisi per ridurre l'affaticamento degli avvisi raggruppando gli avvisi che si verificano entro un determinato intervallo di tempo.
• Mappare i campi dati alle entità in Microsoft Sentinel per consentire agli ingegneri SOC di definire le entità come parte degli elementi probatori da monitorare durante un'indagine. Il mapping delle entità consente inoltre agli analisti SOC di sfruttare un intuitivo [grafico di investigazione](investigate-cases.md#use-the-investigation-graph-to-deep-dive), che può contribuire a ridurre il tempo e l'impegno necessari.
• Analizzare gli eventi imprevisti con dati UEBA, come esempio di come usare le prove per visualizzare eventi, avvisi ed eventuali segnalibri associati a un evento imprevisto specifico nel riquadro di anteprima degli eventi imprevisti.
• Linguaggio di query Kusto (KQL) che è possibile usare per inviare richieste di sola lettura al database di Log Analytics per elaborare i dati e restituire i risultati. KQL viene usato anche in altri servizi Microsoft, ad esempio Microsoft Defender per endpoint e Application Insights.

Confrontare la terminologia delle regole

La tabella di confronto seguente illustra in che modo una regola basata su KQL in Microsoft Sentinel corrisponde a un rilevamento basato su SPL in Splunk.

Mappare e confrontare campioni di regole

Usa gli esempi seguenti di conversione da SPL a KQL per confrontare e mettere in corrispondenza le regole tra Splunk e Microsoft Sentinel in vari scenari.

Comandi di ricerca comuni

La tabella seguente esegue il mapping dei comandi di ricerca SPL comuni ai relativi equivalenti KQL in Microsoft Sentinel.

lookup comando: esempio di KQL

Nell'esempio KQL seguente viene externaldata usato per replicare il modello SPL lookup filtrando gli utenti in base a un'origine dati esterna.

Users 
| where UserID in ((externaldata (UserID:string) [
@"https://storageaccount.blob.core.windows.net/storagecontainer/users.txt" 
h@"?...SAS..." // Secret token to access the blob 
])) | ... 

stats comando: esempio KQL

Nell'esempio KQL seguente, summarize viene usato per contare le transazioni e sommare i totali, raggruppati per frutto e mese.

Sales 
| summarize NumTransactions=count(), 
Total=sum(UnitPrice * NumUnits) by Fruit, 
StartOfMonth=startofmonth(SellDateTime) 

mstats comando: esempio KQL

L'esempio KQL seguente raggruppa i valori di metrica in fasce di prezzo e calcola il numero di record in ciascuna fascia.

T | summarize count() by price_range=bin(price, 10.0) 

transaction comando: esempio SPL

L'esempio di SPL seguente raggruppa gli eventi di avvio e arresto correlati in una singola transazione in base all'ID attività.

sourcetype=MyLogTable type=Event
| transaction ActivityId startswith="Start" endswith="Stop"
| Rename timestamp as StartTime
| Table City, ActivityId, StartTime, Duration

transaction comando: esempio KQL

L'esempio KQL seguente replica il raggruppamento di transazioni SPL aggiungendo eventi di avvio e arresto in un ID attività condivisa e calcolando la durata.

let Events = MyLogTable | where type=="Event";
Events
| where Name == "Start"
| project Name, City, ActivityId, StartTime=timestamp
| join (Events
| where Name == "Stop"
| project StopTime=timestamp, ActivityId)
on ActivityId
| project City, ActivityId, StartTime, 
Duration = StopTime – StartTime

Usare row_window_session() per calcolare i valori di inizio sessione per una colonna in un set di righe serializzato.

...| extend SessionStarted = row_window_session(
Timestamp, 1h, 5m, ID != prev(ID))

eventstats comando: esempio SPL

Nel seguente esempio SPL vengono calcolati i conteggi degli eventi per categoria in intervalli di un minuto e quindi viene aggiunto un totale per ciascun intervallo di tempo usando eventstats.

… | bin span=1m _time
|stats count AS count_i by _time, category
| eventstats sum(count_i) as count_total by _time

eventstats comando: esempio di KQL

Ecco un esempio con l'istruzione join :

let binSize = 1h;
let detail = SecurityEvent 
| summarize detail_count = count() by EventID,
tbin = bin(TimeGenerated, binSize);
let summary = SecurityEvent
| summarize sum_count = count() by 
tbin = bin(TimeGenerated, binSize);
detail 
| join kind=leftouter (summary) on tbin 
| project-away tbin1

Ecco un esempio con l'istruzione make_list :

let binSize = 1m;
SecurityEvent
| where TimeGenerated >= ago(24h)
| summarize TotalEvents = count() by EventID, 
groupBin =bin(TimeGenerated, binSize)
|summarize make_list(EventID), make_list(TotalEvents), 
sum(TotalEvents) by groupBin
| mvexpand list_EventID, list_TotalEvents

anomalydetection comando: esempio SPL

L'esempio SPL seguente rileva le anomalie nei dati cronologici dei prezzi di chiusura in un periodo di 10 anni.

sourcetype=nasdaq earliest=-10y
| anomalydetection Close _ Price

anomalydetection comando: esempio di KQL

L'esempio KQL seguente usa le funzioni di analisi delle serie temporali per rilevare le anomalie nelle tendenze di accesso dell'account disabilitato in un periodo di lookback di sette giorni.

let LookBackPeriod= 7d;
let disableAccountLogon=SignIn
| where ResultType == "50057"
| where ResultDescription has "account is disabled";
disableAccountLogon
| make-series Trend=count() default=0 on TimeGenerated 
in range(startofday(ago(LookBackPeriod)), now(), 1d)
| extend (RSquare,Slope,Variance,RVariance,Interception,
LineFit)=series_fit_line(Trend)
| extend (anomalies,score) = 
series_decompose_anomalies(Trend)

Comandi comuni eval

La tabella seguente esegue il mapping delle funzioni SPL eval comuni ai relativi equivalenti KQL in Microsoft Sentinel.

case(X,"Y",…) Esempio di SPL

L'esempio SPL seguente restituisce una stringa di messaggio diversa in base al codice di errore HTTP.

case(error == 404, "Not found",
error == 500,"Internal Server Error",
error == 200, "OK")

case(X,"Y",…) Esempio KQL

Nell'esempio KQL seguente viene case() usato per assegnare un messaggio in base al valore del codice di errore.

T
| extend Message = case(error == 404, "Not found", 
error == 500,"Internal Server Error", "OK") 

if(X,Y,Z) Esempio KQL

L'esempio KQL seguente usa iif() per indicare se un timestamp appartiene al giorno corrente.

iif(floor(Timestamp, 1d)==floor(now(), 1d), 
"today", "anotherday")

isint(X) Esempio KQL

Nell'esempio KQL seguente viene verificato se X dispone di un tipo compatibile con integer tramite gettype e iif.

iif(gettype(X) =="long","TRUE","FALSE")

isstr(X) Esempio KQL

Nell'esempio KQL seguente viene verificato se X è un valore stringa usando gettype e iif.

iif(gettype(X) =="string","TRUE","FALSE")

like(X,"y") Esempio

I seguenti esempi KQL mostrano diversi operatori per la corrispondenza delle stringhe che è possibile usare per replicare la corrispondenza dei modelli SPL like.

… | where field has "addr"

… | where field contains "addr"

… | where field startswith "addr"

… | where field matches regex "^addr.*"

min(X,…) Esempio KQL

Gli esempi KQL seguenti illustrano diversi modi per calcolare i valori minimi usando min_of, mine arg_min.

min_of (expr_1, expr_2 ...)

…|summarize min(expr)

…| summarize arg_min(Price,*) by Product

mvfilter(X) Esempio KQL

L'esempio KQL seguente usa mv-apply per filtrare e ridurre il contenuto multivalore, simile alla funzione SPL mvfilter .

T | mv-apply Metric to typeof(real) on 
(
 top 2 by Metric desc
)

mvjoin(X,Y) Esempio KQL

Nell'esempio KQL seguente viene strcat_array usato per unire gli elementi della matrice in una singola stringa con un separatore personalizzato.

strcat_array(dynamic([1, 2, 3]), "->")

relative time(X,Y) Esempio KQL

Nell'esempio KQL seguente viene convertito un valore datetime in un periodo Unix per i calcoli relativi al tempo.

let toUnixTime = (dt:datetime)
{
(dt - datetime(1970-01-01))/1s 
};

replace(X,Y,Z) Esempio KQL

Nell'esempio KQL seguente viene replace() usato con un modello regex per scambiare le parti mese e giorno di una stringa di data.

replace( @'^(\d{1,2})/(\d{1,2})/', @'\2/\1/',date)

strptime(X,Y) Esempio KQL

L'esempio KQL seguente usa format_datetime per visualizzare solo le ore e i minuti di un valore datetime.

format_datetime(datetime('2017-08-16 11:25:10'),
'HH:mm')

time() Esempio KQL

L'esempio KQL seguente formatta un valore datetime come stringa di ora che mostra ore, minuti e secondi.

format_datetime(datetime(2015-12-14 02:03:04),
'h:m:s')

tostring(X,Y) Descrizione

Restituisce un valore di campo di X come stringa.

• Se il valore di X è un numero, X viene riformattato in un valore stringa.
• Se X è un valore booleano, X viene riformattato in TRUE o FALSE.
• Se X è un numero, il secondo argomento Y è facoltativo e può essere hex (converte X in un formato esadecimale), commas (formati X con virgole e due posizioni decimali) o duration (converte X da un formato temporale in secondi in un formato di ora leggibile: HH:MM:SS).

tostring(X,Y) Esempio di SPL

L'esempio SPL seguente tostring restituisce:

foo=615 and foo2=00:10:15:

… | eval foo=615 | eval foo2 = tostring(
foo, "duration")

urldecode(X) Esempio di SPL

L'esempio SPL seguente decodifica una stringa con codifica URL nel formato originale.

urldecode("http%3A%2F%2Fwww.splunk.com%2Fdownload%3Fr%3Dheader")

Esempio KQL dei comandi comuni stats

La tabella seguente esegue il mapping delle funzioni di aggregazione SPL stats comuni ai relativi equivalenti KQL in Microsoft Sentinel.

Passaggi successivi

Si è appreso come identificare, confrontare ed eseguire il mapping delle regole di rilevamento di Splunk alle regole di analisi Microsoft Sentinel. Continuare a eseguire la migrazione dell'automazione SOAR.