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 utilizzati per identificare, confrontare e migrare le regole di rilevamento Splunk su 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. Alcune delle tue rilevazioni Splunk esistenti potrebbero essere ridondanti in Microsoft Sentinel, quindi non migrare tutte le rilevazioni Splunk alla cieca. 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 li 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 andare all'Hub dei 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 Rilevamento predefinito delle 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, considerare completata la migrazione della regola. Creare un playbook per l'azione della regola in base alle esigenze. Per altre 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 le tabelle di esempio SPL-to-KQL e gli esempi in questa sezione per confrontare e mappare le regole da Splunk a Microsoft Sentinel in vari scenari.

Confronta i comandi di ricerca Splunk comuni con esempi KQL

Questa tabella mappa i comandi di ricerca SPL comuni ai loro equivalenti KQL in Microsoft Sentinel.

lookup comando: esempio di KQL

Questo esempio KQL viene utilizzato externaldata per replicare il pattern SPL lookup filtrando gli utenti su una fonte di 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 di KQL

Questo esempio di KQL serve summarize a contare transazioni e sommare totali, raggruppati per frutta e mese.

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

mstats comando: esempio di KQL

Questo esempio KQL inserisce i valori metrici in fascie di prezzo e conta i record in ciascuna fascia.

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

transaction comando: esempio SPL

Questo esempio SPL raggruppa eventi di inizio e arresto correlati in una singola transazione per ID attività.

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

transaction comando: esempio di KQL

Questo esempio KQL replica il raggruppamento delle transazioni SPL unendo gli eventi di start e stop su un ID di attività condiviso 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

Questo esempio SPL calcola i conteggi di eventi per categoria in bins di un minuto e poi aggiunge un totale per bin temporale 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

Questo esempio SPL rileva anomalie nei dati storici sui prezzi di chiusura su un periodo di 10 anni.

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

anomalydetection comando: esempio di KQL

Questo esempio di KQL utilizza funzioni di analisi delle serie temporali per rilevare anomalie nelle tendenze di accesso con account disabilitati durante un periodo di revisione 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)

Confronta i comandi Splunk eval comuni con gli equivalenti KQL

Questa tabella mappa le funzioni SPL eval comuni ai loro equivalenti KQL in Microsoft Sentinel.

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

Questo esempio SPL restituisce una stringa di messaggi diversa basata sul codice di errore HTTP.

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

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

Questo esempio di KQL serve case() ad assegnare un messaggio basato sul 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

Questo esempio di KQL serve iif() a indicare se un timestamp coincide con il giorno corrente.

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

isint(X) Esempio KQL

Questo esempio di KQL verifica se X ha un tipo intero compatibile usando gettype e iif.

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

isstr(X) Esempio KQL

Questo esempio di KQL verifica se X è un valore di stringa usando gettype e iif.

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

like(X,"y") Esempio

Questi esempi KQL mostrano diversi operatori di corrispondenza che puoi usare per replicare il pattern matching SPL like .

… | where field has "addr"

… | where field contains "addr"

… | where field startswith "addr"

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

min(X,…) Esempio KQL

Questi esempi KQL mostrano modi diversi per calcolare valori minimi usando min_of, min, e arg_min.

min_of (expr_1, expr_2 ...)

…|summarize min(expr)

…| summarize arg_min(Price,*) by Product

mvfilter(X) Esempio KQL

Questo esempio di KQL serve mv-apply a filtrare e ridurre contenuti multivalore, in modo simile alla funzione SPL mvfilter .

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

mvjoin(X,Y) Esempio KQL

Questo esempio di KQL serve strcat_array per unire elementi dell'array in una singola stringa con un separatore personalizzato.

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

relative time(X,Y) Esempio KQL

Questo esempio KQL converte un valore data-time in tempo di epoca Unix per calcoli in tempo relativo.

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

replace(X,Y,Z) Esempio KQL

Questo esempio di KQL utilizza replace() un pattern regex per scambiare le parti di mese e giorno di una stringa di date.

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

strptime(X,Y) Esempio KQL

Questo esempio KQL serve format_datetime solo a visualizzare le ore e i minuti da un valore datatime.

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

time() Esempio KQL

Questo esempio KQL formatta un valore data-ora come una stringa di tempo che mostra ore, minuti e secondi.

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

tostring(X,Y) Descrizione

La funzione SPL tostring(X,Y) converte i valori in stringhe e supporta diverse opzioni di formattazione. 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

Questo tostring esempio SPL restituisce:

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

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

urldecode(X) Esempio di SPL

Questo esempio SPL decodifica una stringa codificata URL alla sua forma originale.

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

Confronta i comandi Splunk stats comuni con gli equivalenti KQL

Questa tabella mappa le funzioni comuni di aggregazione SPL stats ai loro 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.