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

Questo articolo descrive come identificare, confrontare ed eseguire la migrazione delle regole di rilevamento di ArcSight alle regole di analisi 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 le considerazioni seguenti 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 aver compreso la terminologia delle regole.
• Esamina tutte le regole che non hanno attivato alcun avviso negli ultimi sei-dodici mesi e verifica se sono ancora rilevanti.
• 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 in Microsoft Sentinel:

   • Se le regole predefinite sono sufficienti, usare i modelli di regole predefiniti per creare regole per la propria area di lavoro.

     In Microsoft Sentinel, passare alla scheda Configurazione > Analisi > Modelli di regola e creare e aggiornare ogni regola di analisi pertinente.

     Per imparare a creare regole da template integrati, consulta Crea regole di analisi programmate da template.

   • 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.

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

   • Se né le regole predefinite né un convertitore di regole online sono sufficienti, sarà 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, è possibile usare i modelli di regola come esempi per creare le query KQL.

        Si considerino filtri, regole di correlazione, elenchi attivi, set di riferimento, watchlist, anomalie di rilevamento, aggregazioni e così via. Potresti usare i riferimenti forniti dal tuo SIEM legacy per mappare la sintassi delle query di ArcSight su KQL.

     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 creare e utilizzare i playbook per le azioni delle regole, vedi Automatizzare la risposta alle minacce con i playbook in Microsoft Sentinel.

Altre informazioni sulle regole di analisi:

• 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): Puoi usare KQL per inviare richieste di sola lettura al tuo database 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

Questa tabella consente di chiarire il concetto di regola in Microsoft Sentinel rispetto ad ArcSight.

Mappare e confrontare campioni di regole

Utilizzare i seguenti esempi per confrontare le regole di rilevamento di ArcSight con le query equivalenti di Microsoft Sentinel scritte nel Kusto Query Language (KQL).

Esempio di filtro (AND): ArcSight

Ecco una regola di filtro di esempio con AND condizioni in ArcSight.

Esempio di filtro (AND): KQL

Ecco la regola di filtro con AND condizioni in KQL.

SecurityEvent
| where EventID == 4728
| where SubjectUserName =~ "AutoMatedService"
| where isnotempty(SubjectDomainName)

Questa regola presuppone che l'agente di monitoraggio Azure (AMA) raccoglie gli eventi Sicurezza di Windows. Di conseguenza, la regola usa la tabella Microsoft Sentinel SecurityEvent.

Prendere in considerazione queste procedure consigliate:

• Per ottimizzare le query, evitare operatori senza distinzione tra maiuscole e minuscole quando possibile: =~.
• Usare == se il valore non fa distinzione tra maiuscole e minuscole.
• Ordinare i filtri iniziando con l'istruzione where , che filtra la maggior parte dei dati.

Esempio di filtro (OR): ArcSight

Ecco una regola di filtro di esempio con OR condizioni in ArcSight.

Esempio di filtro (OR): KQL

Ecco alcuni modi per scrivere la regola di filtro contenente condizioni OR in KQL.

Come prima opzione, usare l'istruzione in :

SecurityEvent
| where SubjectUserName in
 ("Adm1","ServiceAccount1","AutomationServices")

Come seconda opzione, usare l'istruzione or :

SecurityEvent
| where SubjectUserName == "Adm1" or 
SubjectUserName == "ServiceAccount1" or 
SubjectUserName == "AutomationServices"

Anche se entrambe le opzioni sono identiche per le prestazioni, è consigliabile usare la prima opzione, che è più facile da leggere.

Esempio di filtro annidato: ArcSight

Ecco una regola di filtro annidata di esempio in ArcSight.

Ecco una regola per il /All Filters/Soc Filters/Exclude Valid Users filtro.

Esempio di filtro annidato: KQL

Ecco alcuni modi per scrivere la regola di filtro contenente condizioni OR in KQL.

Come prima opzione, usare un filtro diretto con un'istruzione where :

SecurityEvent
| where EventID == 4728 
| where isnotempty(SubjectDomainName) or 
isnotempty(TargetDomainName) 
| where SubjectUserName !~ "AutoMatedService"

Come seconda opzione, usare una funzione KQL:

1. Salvare la query seguente come funzione KQL con l'alias ExcludeValidUsers .

       SecurityEvent
       | where EventID == 4728
       | where isnotempty(SubjectDomainName)
       | where SubjectUserName =~ "AutoMatedService"
       | project SubjectUserName
   

2. Usare la query seguente per filtrare l'alias ExcludeValidUsers .

       SecurityEvent    
       | where EventID == 4728
       | where isnotempty(SubjectDomainName) or 
       isnotempty(TargetDomainName)
       | where SubjectUserName !in (ExcludeValidUsers)
   

Come terza opzione, usare una funzione di parametro:

1. Creare una funzione di parametro con ExcludeValidUsers come nome e alias.

2. Definire i parametri della funzione. Ad esempio:

       Tbl: (TimeGenerated:datetime, Computer:string, 
       EventID:string, SubjectDomainName:string, 
       TargetDomainName:string, SubjectUserName:string)
   

3. La funzione parameter presenta la seguente query:

       Tbl
       | where SubjectUserName !~ "AutoMatedService"
   

4. Eseguire la query seguente per richiamare la funzione del parametro:

       let Events = (
       SecurityEvent 
       | where EventID == 4728
       );
       ExcludeValidUsers(Events)
   

Come quarta opzione, usare la join funzione :

let events = (
SecurityEvent
| where EventID == 4728
| where isnotempty(SubjectDomainName) 
or isnotempty(TargetDomainName)
);
let ExcludeValidUsers = (
SecurityEvent
| where EventID == 4728
| where isnotempty(SubjectDomainName)
| where SubjectUserName =~ "AutoMatedService"
);
events
| join kind=leftanti ExcludeValidUsers on 
$left.SubjectUserName == $right.SubjectUserName

Considerations

• È consigliabile usare un filtro diretto con un'istruzione where (prima opzione) per la sua semplicità. Per ottimizzare le prestazioni, evitare di usare join (quarta opzione).
• Per ottimizzare le query, evitare se possibile gli operatori =~ e !~ senza distinzione tra maiuscole e minuscole. Usare gli operatori == e != se il valore non distingue tra maiuscole e minuscole.

Esempio di elenco attivo (ricerca): ArcSight

Ecco una regola di elenco (ricerca) attiva in ArcSight.

Esempio di elenco attivo (ricerca): KQL

La seguente query KQL utilizza la watchlist Cyber-Ark Eccezioni Account per filtrare i risultati della ricerca.

let Activelist=(
_GetWatchlist('Cyber-Ark Exception Accounts')
| project Account );
CommonSecurityLog
| where DestinationUserName in (Activelist)
| where DeviceVendor == "Cyber-Ark"
| where DeviceAction == "Get File Request"
| where DeviceCustomNumber1 != ""
| project DeviceAction, DestinationUserName, 
TimeGenerated,SourceHostName, 
SourceUserName, DeviceEventClassID

Ordinare i filtri iniziando con l'istruzione where che filtra la maggior parte dei dati.

Esempio di correlazione (corrispondenza): ArcSight

Ecco una regola ArcSight di esempio che definisce una condizione per un set di eventi di base, usando l'istruzione Matching Event .

Esempio di correlazione (corrispondenza): KQL

Nell'esempio KQL seguente viene illustrato come implementare la regola di correlazione corrispondente ad ArcSight in Microsoft Sentinel.

let event1 =(
SecurityEvent
| where EventID == 4728
);
let event2 =(
SecurityEvent
| where EventID == 4729
);
event1
| join kind=inner event2 
on $left.TargetUserName==$right.TargetUserName

Procedure consigliate

• Per ottimizzare la query, assicurarsi che la tabella più piccola si trova sul lato sinistro della join funzione.
• Se il lato sinistro della tabella è relativamente piccolo (fino a 100.000 record), aggiungere hint.strategy=broadcast per ottenere prestazioni migliori.

Esempio di correlazione (intervallo di tempo): ArcSight

Ecco una regola ArcSight di esempio che definisce una condizione per un set di eventi di base, usando l'istruzione Matching Event e usa la condizione di Wait time filtro.

Esempio di correlazione (intervallo di tempo): KQL

Nell'esempio KQL seguente viene implementata una regola di correlazione con un intervallo di tempo equivalente all'esempio di ArcSight.

let waittime = 10m;
let lookback = 1d;
let event1 = (
SecurityEvent
| where TimeGenerated > ago(waittime+lookback)
| where EventID == 4728
| project event1_time = TimeGenerated, 
event1_ID = EventID, event1_Activity= Activity, 
event1_Host = Computer, TargetUserName, 
event1_UPN=UserPrincipalName, 
AccountUsedToAdd = SubjectUserName 
);
let event2 = (
SecurityEvent
| where TimeGenerated > ago(waittime)
| where EventID == 4729
| project event2_time = TimeGenerated, 
event2_ID = EventID, event2_Activity= Activity, 
event2_Host= Computer, TargetUserName, 
event2_UPN=UserPrincipalName,
 AccountUsedToRemove = SubjectUserName 
);
 event1
| join kind=inner event2 on TargetUserName
| where event2_time - event1_time < lookback
| where tolong(event2_time - event1_time ) >=0
| project delta_time = event2_time - event1_time,
 event1_time, event2_time,
 event1_ID,event2_ID,event1_Activity,
 event2_Activity, TargetUserName, AccountUsedToAdd,
 AccountUsedToRemove,event1_Host,event2_Host, 
 event1_UPN,event2_UPN

Esempio di aggregazione: ArcSight

Ecco una regola ArcSight di esempio con impostazioni di aggregazione: tre corrispondenze entro 10 minuti.

Esempio di aggregazione: KQL

La query KQL seguente mostra come rilevare tre o più corrispondenze usando l'aggregazione.

SecurityEvent
| summarize Count = count() by SubjectUserName, 
SubjectDomainName
| where Count >3

Passo successivo