Eseguire la migrazione delle regole di rilevamento di QRadar a Microsoft Sentinel
Questo articolo descrive come identificare, confrontare ed eseguire la migrazione delle regole di rilevamento di QRadar alle regole predefinite di Microsoft Sentinel.
Microsoft Sentinel usa l'analisi di Machine Learning per creare eventi imprevisti ad alta fedeltà e pratica e alcuni rilevamenti esistenti possono essere ridondanti in Microsoft Sentinel. Pertanto, non eseguire la migrazione di tutte le regole di rilevamento e analisi in modo cieco. Esaminare queste considerazioni durante l'identificazione delle regole di rilevamento esistenti.
- Assicurarsi di selezionare i casi d'uso che giustificano la migrazione delle regole, considerando la priorità aziendale e l'efficienza.
- Verificare di aver compreso i tipi di regole di Microsoft Sentinel.
- Verificare di aver compreso la terminologia delle regole.
- Esaminare le regole che non hanno attivato avvisi negli ultimi 6-12 mesi e determinare se sono ancora pertinenti.
- Eliminare le minacce o gli avvisi di basso livello che normalmente si ignorano.
- Usare le funzionalità esistenti e verificare se le regole di analisi predefinite di Microsoft Sentinel potrebbero risolvere i casi d'uso correnti. Poiché Microsoft Sentinel usa l'analisi di Machine Learning per produrre eventi imprevisti ad alta fedeltà e pratica, è probabile che alcuni rilevamenti esistenti non siano più necessari.
- Verificare le origini dati connesse ed esaminare i metodi di connessione dati. Rivedere le conversazioni di raccolta dati per garantire la profondità e l'ampiezza dei dati nei casi d'uso che si prevede di rilevare.
- Esplorare le risorse della community, ad esempio SOC Prime Threat Detection Marketplace, per verificare se le regole sono disponibili.
- Valutare se un convertitore di query online, ad esempio Uncoder.io, potrebbe funzionare per le regole.
- Se le regole non sono disponibili o non possono essere convertite, devono essere create manualmente usando una query KQL. Esaminare il mapping delle regole per creare nuove query.
Altre informazioni sulle procedure consigliate per la migrazione delle regole di rilevamento.
Per eseguire la migrazione delle regole di analisi a Microsoft Sentinel:
Verificare di disporre di un sistema di test per ogni regola di cui si vuole eseguire la migrazione.
Preparare un processo di convalida per le regole di cui è stata eseguita la migrazione, inclusi scenari di test completi e script.
Assicurarsi che il team disponga di risorse utili per testare le regole di cui è stata eseguita la migrazione.
Verificare di disporre di origini dati necessarie connesse ed esaminare i metodi di connessione dati.
Verificare se i rilevamenti sono disponibili come modelli predefiniti in Microsoft Sentinel:
Se le regole predefinite sono sufficienti, usare i modelli di regola predefiniti per creare regole per la propria area di lavoro.
In Microsoft Sentinel passare a Configurazione > Analisi > Modelli di regole e creare e aggiornare ogni regola di analisi pertinente.
Per altre informazioni, vedere Rilevare le minacce predefinite.
Se sono presenti rilevamenti non coperti dalle regole predefinite di Microsoft Sentinel, provare un convertitore di query online, ad esempio Uncoder.io per convertire le query in KQL.
Identificare la condizione del trigger e l'azione della regola, quindi costruire ed esaminare la query KQL.
Se non sono sufficienti né le regole predefinite né un convertitore di regole online, sarà necessario creare la regola manualmente. In questi casi, seguire questa procedura per iniziare a creare la regola:
Identificare le origini dati da usare nella regola. È consigliabile creare una tabella di mapping tra origini dati e tabelle dati in Microsoft Sentinel per identificare le tabelle di cui si vuole eseguire la query.
Identificare gli attributi, i campi o le entità nei dati da usare nelle regole.
Identificare i criteri e la logica delle regole. In questa fase, è possibile usare i modelli di regola come esempi per creare query KQL.
Prendere in considerazione filtri, regole di correlazione, elenchi attivi, set di riferimenti, watchlist, anomalie di rilevamento, aggregazioni e così via. È possibile usare i riferimenti forniti dal sistema SIEM legacy per comprendere come eseguire il mapping ottimale della sintassi della query.
Identificare la condizione del trigger e l'azione della regola, quindi costruire ed esaminare la query KQL. Quando si esamina la query, prendere in considerazione le risorse di ottimizzazione KQL.
Testare la regola con ogni caso d'uso pertinente. Se non fornisce risultati previsti, è possibile esaminare il KQL e testarlo di nuovo.
Quando si è soddisfatti, è possibile considerare la regola di cui è stata eseguita la migrazione. 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 di avvisi per ridurre l'affaticamento degli avvisi raggruppando gli avvisi che si verificano entro un determinato intervallo di tempo.
- Eseguire il mapping dei campi dati alle entità in Microsoft Sentinel per consentire ai tecnici SOC di definire le entità come parte dell'evidenza da tracciare durante un'indagine. Il mapping delle entità consente anche agli analisti SOC di sfruttare un [grafico di indagine] intuitivo (investigate-cases.md#use-the-investigation-graph-to-deep-dive) che può aiutare a ridurre il tempo e il lavoro.
- Esaminare gli eventi imprevisti con i dati UEBA (analisi del comportamento degli utenti e delle entità), come esempio di come usare l'evidenza per visualizzare eventi, avvisi ed eventuali segnalibri associati a un evento imprevisto specifico nel riquadro di anteprima dell'evento imprevisto.
- KQL (Linguaggio di query Kusto), 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.
Questa tabella aiuta a chiarire il concetto di regola in Microsoft Sentinel rispetto a QRadar.
QRadar | Microsoft Sentinel | |
---|---|---|
Tipo di regola | • Eventi • Flusso • Comuni • Violazione • Regole di rilevamento anomalie |
• Query pianificata • Fusione • Microsoft Security • Analisi del comportamento di Machine Learning (ML) |
Criteri | Definire nella condizione di test | Definire in KQL |
Condizione trigger | Definire nella regola | Soglia: numero di risultati della query |
Azione | • Creare una violazione • Inviare un nuovo evento • Aggiungere al set di riferimenti o ai dati • E altro ancora |
• Creare un avviso o un evento imprevisto • Si integra con App per la logica |
Usare questi esempi per confrontare ed eseguire il mapping delle regole da QRadar a Microsoft Sentinel in vari scenari.
Ecco la sintassi QRadar per una regola di test delle proprietà comuni.
Ecco la sintassi per una regola di test delle proprietà comuni QRadar di esempio che usa un'espressione regolare:
when any of <these properties> match <this regular expression>
Ecco la regola di esempio in QRadar.
Ecco la regola dei test delle proprietà comuni con un'espressione regolare in KQL.
CommonSecurityLog
| where tostring(SourcePort) matches regex @"\d{1,5}" or tostring(DestinationPort) matches regex @"\d{1,5}"
Ecco la sintassi per una regola di test delle proprietà comuni QRadar di esempio che usa una query di filtro AQL.
when the event matches <this> AQL filter query
Ecco la regola di esempio in QRadar.
Ecco la regola dei test delle proprietà comuni con una query di filtro AQL in KQL.
CommonSecurityLog
| where SourceIP == '10.1.1.10'
Ecco la sintassi per una regola di test delle proprietà comuni QRadar di esempio che usa l'operatore equals
o not equals
.
and when <this property> <equals/not equals> <this property>
Ecco la regola di esempio in QRadar.
Ecco la regola dei test delle proprietà comuni con l'operatore equals
o not equals
in KQL.
CommonSecurityLog
| where SourceIP == DestinationIP
Ecco la sintassi QRadar per una regola di test di data/ora.
Ecco la sintassi per una regola di test di data/ora QRadar di esempio che usa un giorno del mese selezionato.
and when the event(s) occur <on/after/before> the <selected> day of the month
Ecco la regola di esempio in QRadar.
Ecco la regola di test di data/ora con un giorno del mese selezionato in KQL.
SecurityEvent
| where dayofmonth(TimeGenerated) < 4
Ecco la sintassi per una regola di test di data/ora QRadar di esempio che usa un giorno della settimana selezionato:
and when the event(s) occur on any of <these days of the week{Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday}>
Ecco la regola di esempio in QRadar.
Ecco la regola di test di data/ora con un giorno della settimana selezionato in KQL.
SecurityEvent
| where dayofweek(TimeGenerated) between (3d .. 5d)
Ecco la sintassi per una regola di test di data/ora QRadar di esempio che usa l'operatore after
, before
o at
.
and when the event(s) occur <after/before/at> <this time{12.00AM, 12.05AM, ...11.50PM, 11.55PM}>
Ecco la regola di esempio in QRadar.
Ecco la regola di test di data/ora che usa l'operatore after
, before
o at
in KQL.
SecurityEvent
| where format_datetime(TimeGenerated,'HH:mm')=="23:55"
TimeGenerated
è in UTC/GMT.
Ecco la sintassi QRadar per una regola di test delle proprietà dell'evento.
Ecco la sintassi per una regola di test delle proprietà dell'evento QRadar di esempio che usa un protocollo IP.
and when the IP protocol is one of the following <protocols>
Ecco la regola di esempio in QRadar.
CommonSecurityLog
| where Protocol in ("UDP","ICMP")
Ecco la sintassi per una regola di test delle proprietà dell'evento QRadar di esempio che usa un valore di stringa Event Payload
.
and when the Event Payload contains <this string>
Ecco la regola di esempio in QRadar.
CommonSecurityLog
| where DeviceVendor has "Palo Alto"
search "Palo Alto"
Per ottimizzare le prestazioni, evitare di usare il comando search
se si conosce già il nome della tabella.
Ecco la sintassi QRadar per una regola di funzioni che usa contatori.
Ecco la sintassi per una regola di funzioni QRadar di esempio che usa un numero definito di proprietà dell'evento in un numero definito di minuti.
and when at least <this many> events are seen with the same <event properties> in <this many> <minutes>
Ecco la regola di esempio in QRadar.
CommonSecurityLog
| summarize Count = count() by SourceIP, DestinationIP
| where Count >= 5
Ecco la sintassi QRadar per una regola di funzioni che usa condizioni negative.
Ecco la sintassi per una regola di funzioni QRadar di esempio che usa condizioni negative.
and when none of <these rules> match in <this many> <minutes> after <these rules> match with the same <event properties>
Ecco due regole definite in QRadar. Le condizioni negative saranno basate su queste regole.
Ecco un esempio di regola di condizioni negative basata sulle regole precedenti.
let spanoftime = 10m;
let Test2 = (
CommonSecurityLog
| where Protocol !in ("UDP","ICMP")
| where TimeGenerated > ago(spanoftime)
);
let Test6 = (
CommonSecurityLog
| where SourceIP == DestinationIP
);
Test2
| join kind=rightanti Test6 on $left. SourceIP == $right. SourceIP and $left. Protocol ==$right. Protocol
Ecco la sintassi QRadar per una regola di funzioni che usa condizioni semplici.
Ecco la sintassi per una regola di funzioni QRadar di esempio che usa condizioni semplici.
and when an event matches <any|all> of the following <rules>
Ecco la regola di esempio in QRadar.
CommonSecurityLog
| where Protocol !in ("UDP","ICMP") or SourceIP == DestinationIP
Ecco la sintassi QRadar per una regola di test di IP/porta.
Ecco la sintassi per una regola QRadar di esempio che specifica una porta di origine.
and when the source port is one of the following <ports>
Ecco la regola di esempio in QRadar.
CommonSecurityLog
| where SourcePort == 20
Ecco la sintassi per una regola QRadar di esempio che specifica un IP di origine.
and when the source IP is one of the following <IP addresses>
Ecco la regola di esempio in QRadar.
CommonSecurityLog
| where SourceIP in (“10.1.1.1”,”10.2.2.2”)
Ecco la sintassi QRadar per una regola di test di origine log.
Ecco la sintassi per una regola QRadar di esempio che specifica le origini di log.
and when the event(s) were detected by one or more of these <log source types>
Ecco la regola di esempio in QRadar.
OfficeActivity
| where OfficeWorkload == "Exchange"
In questo articolo è stato illustrato come eseguire il mapping delle regole di migrazione da QRadar a Microsoft Sentinel.