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

Questo articolo descrive come identificare, confrontare e migrare le regole di rilevamento di QRadar nelle regole predefinite di Microsoft Sentinel. Ti accompagna nell'inventario delle rilevazioni esistenti, nel confronto della terminologia delle regole tra QRadar e Microsoft Sentinel, e nella scelta del percorso di migrazione giusto—che si tratti di adottare modelli di analisi integrati dal Content Hub, convertire query con uno strumento online o scrivere query personalizzate Kusto Query Language (KQL). Alla fine, avrai un approccio strutturato per migrare le tue regole di rilevamento, sfruttando al contempo le analisi di machine learning di Microsoft Sentinel.

Identificare e migrare le regole

Microsoft Sentinel usa l'analisi di Machine Learning per creare eventi imprevisti ad alta fedeltà e interattivi e alcuni rilevamenti esistenti potrebbero essere ridondanti in Microsoft Sentinel. Pertanto, non eseguire la migrazione cieca di tutte le regole di rilevamento e analisi. 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.
• Verifica di comprendere i tipi di regole di Microsoft Sentinel.
• Verificare di comprendere 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 si ignorano regolarmente.
• 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 interattivi, è probabile che alcuni rilevamenti esistenti non siano più necessari.
• Confermare le fonti dati connesse e rivedere 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.
• Esplorate le risorse della community, ad esempio il SOC Prime Threat Detection Marketplace, per verificare se le vostre regole sono disponibili.
• Valuta se un convertitore di query online, come Uncoder.io, possa funzionare con le tue regole.
• Se le regole non sono disponibili o non possono essere convertite, devono essere create manualmente usando una query KQL. Esamina la mappatura delle regole per creare nuove query.

Scopri di più sulle procedure consigliate per la migrazione delle regole di rilevamento.

Per eseguire la migrazione delle regole di analisi 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 tutte le origini dati necessarie connesse ed esaminare i metodi di connessione dati.

2. Verificare se i rilevamenti sono disponibili come modelli predefiniti nell'hub contenuto:

   • Se le regole predefinite sono sufficienti, installare le soluzioni pertinenti e usare i modelli per creare regole per l'area di lavoro.

     1. In Microsoft Sentinel passare a Content management Content hub (Hub del contenuto per la gestione > del contenuto).
     2. Cercare e installare la regola di analisi appropriata.

     Per altre informazioni, vedere Individuare e gestire il contenuto predefinito di Microsoft Sentinel e Creare regole di analisi pianificate dai modelli.

   • Se sono presenti rilevamenti non coperti dalle regole predefinite disponibili nell'hub dei contenuti, provare un convertitore di query online, ad esempio Uncoder.io per convertire le query in KQL.

     Identificate la condizione di attivazione e l'azione della regola, quindi create e rivedete la query KQL.

   • Se né le soluzioni dell'hub contenuto né un convertitore di regole online sono sufficienti, è necessario creare manualmente la regola. In questi casi, seguire questa procedura per iniziare a creare la regola:

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

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

     3. Identificare i criteri e la logica delle regole. In questa fase potrebbe essere opportuno usare i modelli di regole come esempi di come costruire le query KQL come esempi di come costruire le 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 dal sistema SIEM legacy per comprendere come eseguire il mapping ottimale della sintassi della 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, è possibile esaminare il KQL e testarlo di nuovo.

4. Quando si è soddisfatti, si può 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

Per altre informazioni sulle regole di analisi Microsoft Sentinel e KQL, vedere le risorse seguenti:

• Regole di analisi programmate in Microsoft Sentinel: Usa il raggruppamento degli avvisi per ridurre la fatica 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 entità come parte delle prove da monitorare durante un'indagine. Il mapping delle entità consente inoltre agli analisti soc di sfruttare un grafico di analisi intuitivo che consente di ridurre il tempo e l'impegno.
• Indagare sugli incidenti con dati UEBA: come esempio di come utilizzare le prove per far emergere eventi, avvisi e eventuali segnalibri associati a un particolare incidente nel pannello di anteprima dell'incidente.
• Kusto Query Language (KQL): Che puoi usare per inviare richieste di sola lettura al tuo database Log Analytics per elaborare i dati e restituire risultati. KQL viene usato anche in altri servizi Microsoft, ad esempio Microsoft Defender per endpoint e Application Insights.

Confrontare la terminologia delle regole

Questa tabella consente di chiarire il concetto di regola in Microsoft Sentinel rispetto a QRadar. I tipi di regole di Microsoft Sentinel includono query programmate, Fusion (che correla automaticamente gli avvisi da più fonti di dati in incidenti tramite machine learning), Microsoft Security e Machine Learning (ML) Behavior Analytics.

Mappare e confrontare campioni di regole

Usare questi esempi per confrontare e mappare le regole da QRadar a Microsoft Sentinel in vari scenari. Le query di esempio sono scritte nel Kusto Query Language (KQL), il linguaggio di query utilizzato da Microsoft Sentinel.

Sintassi dei test di proprietà comuni

Ecco la sintassi QRadar per una regola di test delle proprietà comune.

Test delle proprietà comuni: esempio di espressione regolare (QRadar)

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:

Test delle proprietà comuni: esempio di espressione regolare (KQL)

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}"

Test delle proprietà comuni: esempio di query di filtraggio AQL (QRadar)

Ecco la sintassi di una regola di esempio dei test di proprietà comuni di QRadar che utilizza una query di filtro AQL:

when the event matches <this> AQL filter query

Ecco la regola di esempio in QRadar:

Test delle proprietà comuni: esempio di query di filtro AQL (KQL)

Ecco la regola comune dei test di proprietà con una query di filtro AQL in KQL:

CommonSecurityLog
| where SourceIP == '10.1.1.10'

Test delle proprietà comuni: esempio uguale/non uguale (QRadar)

Ecco la sintassi di una regola di esempio dei test a proprietà comuni di QRadar che utilizza l'operatore equals o not equals :

and when <this property> <equals/not equals> <this property>

Ecco la regola di esempio in QRadar:

Test sulle proprietà comuni: esempio di uguale/non uguale (KQL)

Ecco la regola dei test di proprietà comuni con l'operatore equals o not equals in KQL:

CommonSecurityLog
| where SourceIP == DestinationIP

Sintassi dei test di data/ora

Ecco la sintassi QRadar per una regola dei test data/ora:

Test di data/ora: esempio di giorno selezionato del mese (QRadar)

Ecco la sintassi di una regola di esempio di test data/ora di QRadar che utilizza un giorno selezionato del mese:

and when the event(s) occur <on/after/before> the <selected> day of the month

Ecco la regola di esempio in QRadar:

Test di data/ora: esempio di giorno del mese selezionato (KQL)

Ecco la regola dei test data/orario con un giorno del mese selezionato in KQL:

SecurityEvent
 | where dayofmonth(TimeGenerated) < 4

Test di data/ora: esempio del giorno della settimana selezionato (QRadar)

Ecco la sintassi per una regola di test di data/ora QRadar di esempio che usa un giorno selezionato della settimana:

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:

Test di data/ora: esempio di giorno della settimana selezionato (KQL)

Ecco la regola dei test data/orario con un giorno della settimana selezionato in KQL:

SecurityEvent
 | where dayofweek(TimeGenerated) between (3d .. 5d)

Test di data/ora: esempio dopo/prima/alle (QRadar)

Ecco la sintassi di una regola di esempio di test data/ora di QRadar che utilizza , afterbefore, o at operatore:

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:

Test di data/ora: esempio di after/before/at (KQL)

Ecco la regola dei test data/ora che utilizza , afterbefore, o at operatore in KQL:

SecurityEvent
| where format_datetime(TimeGenerated,'HH:mm')=="23:55"

TimeGenerated è in formato UTC/GMT.

Sintassi dei test delle proprietà dell'evento

Ecco la sintassi QRadar per una regola dei test di proprietà degli eventi:

Test delle proprietà degli eventi: esempio di protocollo IP (QRadar)

Ecco la sintassi di una regola di esempio dei test di proprietà degli eventi QRadar che utilizza un protocollo IP:

and when the IP protocol is one of the following <protocols>

Ecco la regola di esempio in QRadar:

Test delle proprietà degli eventi: esempio di protocollo IP (KQL)

Ecco la regola dei test delle proprietà degli eventi con un filtro del protocollo IP in KQL:

CommonSecurityLog
| where Protocol in ("UDP","ICMP")

Test della proprietà dell'evento: esempio di stringa del payload dell'evento (QRadar)

Ecco la sintassi di una regola di esempio dei test di proprietà degli eventi QRadar che utilizza un Event Payload valore di stringa:

and when the Event Payload contains <this string>

Ecco la regola di esempio in QRadar:

Test delle proprietà dell'evento: esempio di stringa del payload dell'evento (KQL)

Ecco la regola per testare le proprietà degli eventi con una stringa Event Payload in KQL. Per ottimizzare le prestazioni, evitare di usare il search comando se si conosce già il nome della tabella.

CommonSecurityLog
| where DeviceVendor has "Palo Alto"

search "Palo Alto"

Funzioni: sintassi dei contatori

Ecco la sintassi QRadar per una regola di funzioni che utilizza contatori:

Contatori: esempio di proprietà e tempo dell'evento (QRadar)

Ecco la sintassi di una regola di esempio di funzioni QRadar che utilizza un numero definito di proprietà degli eventi 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:

Contatori: esempio di proprietà e tempo dell'evento (KQL)

Ecco la regola dei contatori con proprietà di evento e condizioni temporali in KQL:

CommonSecurityLog
| summarize Count = count() by SourceIP, DestinationIP
| where Count >= 5

Funzioni: sintassi delle condizioni negative

Ecco la sintassi QRadar per una regola di funzioni che utilizza condizioni negative:

Esempio di condizioni negative (QRadar)

Ecco la sintassi di una regola di esempio per funzioni QRadar che utilizza 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 si basano su queste regole:

Ecco un esempio della regola delle condizioni negative basata sulle due regole QRadar precedentemente definite (Test2 e Test6):

Esempio di condizioni negative (KQL)

Ecco la regola delle condizioni negative con una rightanti join in KQL:

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

Funzioni: sintassi delle condizioni semplici

Ecco la sintassi QRadar per una regola di funzioni che utilizza condizioni semplici:

Esempio di condizioni semplici (QRadar)

Ecco la sintassi di una regola di esempio per le funzioni QRadar che utilizza condizioni semplici.:

and when an event matches <any|all> of the following <rules>

Ecco la regola di esempio in QRadar:

Esempio di condizioni semplici (KQL)

Ecco la semplice regola delle condizioni in KQL:

CommonSecurityLog
| where Protocol !in ("UDP","ICMP") or SourceIP == DestinationIP

Sintassi dei test IP/porta

Ecco la sintassi QRadar per una regola di test IP/porta:

Test IP/porta: esempio di porta di origine (QRadar)

Ecco la sintassi di una regola QRadar di esempio che specifica una porta sorgente:

and when the source port is one of the following <ports>

Ecco la regola di esempio in QRadar:

Test IP/porta: esempio di porta di origine (KQL)

Ecco la regola dei test IP/porta con un filtro della porta sorgente in KQL:

CommonSecurityLog
| where SourcePort == 20

Test IP/porta: esempio di IP di origine (QRadar)

Ecco la sintassi di una regola QRadar di esempio che specifica un IP sorgente:

and when the source IP is one of the following <IP addresses>

Ecco la regola di esempio in QRadar:

Test IP/porta: esempio di IP di origine (KQL)

Ecco la regola dei test IP/porta con un filtro IP sorgente in KQL:

CommonSecurityLog
| where SourceIP in ("10.1.1.1","10.2.2.2")

Sintassi dei test di origine del log

Ecco la sintassi di QRadar per una regola di log source test:

Esempio di origine del log (QRadar)

Ecco la sintassi di una regola di esempio QRadar che specifica le sorgenti 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:

Esempio di origine del log (KQL)

Ecco la regola dei test di sorgente di log in KQL.

OfficeActivity
| where OfficeWorkload == "Exchange"

Passo successivo