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 ed eseguire la migrazione delle 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.
  • Verificare di comprendere Microsoft Sentinel tipi di regole.
  • 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 origini dati connesse ed esaminare i metodi di connessione dati. Rivedere le conversazioni di raccolta dati per garantire profondità e 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:

  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 Modelli di regola di Configuration > Analytics > e creare e aggiornare ogni regola di analisi pertinente.

      Per altre informazioni, vedere Creare regole di analisi pianificata dai modelli.

    • 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 creare ed esaminare 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. È possibile usare i riferimenti forniti da SIEM legacy per comprendere come eseguire il mapping migliore della sintassi di query.

      4. Identificare la condizione del trigger e l'azione della regola, quindi creare ed esaminare la query KQL. Quando si esamina la query, prendere in considerazione le risorse guida 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, è 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:

Confrontare la terminologia delle regole

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

ArcSight Microsoft Sentinel
Tipo di regola • Regola di filtro
• Regola di join
• Regola elenco attivo
• E altro ancora		 • Query pianificata
•Fusione
• Sicurezza Microsoft
• Analisi del comportamento di Machine Learning (ML)
Criteria Definire in condizioni di regola Definire in KQL
Condizione del trigger • Definire in azione
• Definire nell'aggregazione (per l'aggregazione di eventi)		 Soglia: numero di risultati della query
Azione • Imposta campo evento
• Invia notifica
• Creare un nuovo caso
• Aggiungi all'elenco attivo
• E altro ancora		 • Creare avvisi o eventi imprevisti
• Si integra con App per la logica

Eseguire il mapping e il confronto di esempi di regole

Usare questi esempi per confrontare e mappare le regole da ArcSight a Microsoft Sentinel in vari scenari.

Regola Descrizione Regola di rilevamento di esempio (ArcSight) Query KQL di esempio Risorse
Filtro (AND) Regola di esempio con AND condizioni. L'evento deve corrispondere a tutte le condizioni. Esempio di filtro (AND) Esempio di filtro (AND) Filtro stringa:
• Operatori stringa

Filtro numerico:
• Operatori numerici

Filtro datetime:
• fa
• Datetime
• tra
• ora

Analisi:
• analizzare
• estrarre
• parse_json
• parse_csv
• parse_path
• parse_url
Filtro (OR) Regola di esempio con OR condizioni. L'evento può corrispondere a qualsiasi condizione. Esempio di filtro (OR) Esempio di filtro (OR) • Operatori stringa
• in
Filtro annidato Regola di esempio con condizioni di filtro annidate. La regola include l'istruzione MatchesFilter , che include anche le condizioni di filtro. Esempio di filtro annidato Esempio di filtro annidato • Funzione KQL di esempio
• Funzione parametro di esempio
• partecipare
• dove
Elenco attivo (ricerca) Regola di ricerca di esempio che usa l'istruzione InActiveList . Esempio di elenco attivo (ricerca) Esempio di elenco attivo (ricerca) • Una watchlist è l'equivalente della funzionalità elenco attivo. Altre informazioni sulle watchlist.
• Altri modi per implementare le ricerche
Correlazione (corrispondenza) Regola di esempio che definisce una condizione per un set di eventi di base, usando l'istruzione Matching Event . Esempio di correlazione (corrispondenza) Esempio di correlazione (corrispondenza) Operatore join:
• partecipare
• partecipare con intervallo di tempo
• mischiare
• Trasmissione
• Unione

istruzione define:
• let

Aggregazione:
• make_set
• make_list
• make_bag
• bag_pack
Correlazione (intervallo di tempo) Regola di esempio che definisce una condizione rispetto a 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) Esempio di correlazione (intervallo di tempo) • partecipare
• Microsoft Sentinel regole e l'istruzione join

Esempio di filtro (AND): ArcSight

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

Diagramma che illustra una regola di filtro di esempio.

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.

Diagramma che illustra una regola di filtro di esempio (o).

Esempio di filtro (OR): KQL

Ecco alcuni modi per scrivere la regola di filtro con OR le condizioni 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.

Diagramma che illustra una regola di filtro annidata di esempio.

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

Diagramma che illustra un filtro Escludi utenti validi.

Esempio di filtro annidato: KQL

Ecco alcuni modi per scrivere la regola di filtro con OR le condizioni 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 parameter funzione ha la query seguente:

        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

Considerazioni:

  • È 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 gli =~ operatori senza distinzione tra maiuscole e !~ minuscole quando possibile. Usare gli == operatori e != se il valore non fa distinzione tra maiuscole e minuscole.

Esempio di elenco attivo (ricerca): ArcSight

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

Diagramma che illustra una regola di elenco attiva di esempio (ricerca).

Esempio di elenco attivo (ricerca): KQL

Questa regola presuppone che l'elenco di controllo Cyber-Ark Exception Accounts esista in Microsoft Sentinel con un campo Account.

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 .

Diagramma che illustra una regola di correlazione di esempio (corrispondenza).

Esempio di correlazione (corrispondenza): KQL

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

Diagramma che illustra una regola di correlazione di esempio (intervallo di tempo).

Esempio di correlazione (intervallo di tempo): KQL

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.

Diagramma che illustra una regola di aggregazione di esempio.

Esempio di aggregazione: KQL

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

Passaggi successivi

In questo articolo si è appreso come eseguire il mapping delle regole di migrazione da ArcSight a Microsoft Sentinel.

Eseguire la migrazione dell'automazione SOAR

  • Last updated on