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 di 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 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 Creare regole di analisi pianificate 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 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:
- Regole di analisi pianificate in Microsoft Sentinel. 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 tenere traccia durante un'indagine. Il mapping delle entità consente anche agli analisti SOC di sfruttare un grafico di indagine intuitivo che consente di ridurre il tempo e il lavoro.
- Esaminare gli eventi imprevisti con i dati UEBA, 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.
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 | • Filtro regola • Regola di aggiunta • Regola elenco attivo • E altro ancora |
• Query pianificata • Fusione • Microsoft Security • Analisi del comportamento di Machine Learning (ML) |
Criteri | Definire nelle condizioni delle regole | Definire in KQL |
Condizione trigger | • Definire in azione • Definire in 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 un avviso o un evento imprevisto • Si integra con App per la logica |
Eseguire il mapping e confrontare gli esempi di regole
Usare questi esempi per confrontare ed eseguire il mapping delle 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 condizioni AND . L'evento deve corrispondere a tutte le condizioni. |
Esempio di filtro (AND) | Esempio di filtro (AND) | Filtro stringa: • Operatori di stringa Filtro numerico: • Operatori numerici Filtro Datetime: • ago • Datetime • between • now Analisi: • parse • extract • parse_json • parse_csv • parse_path • parse_url |
Filtro (OR ) |
Regola di esempio con condizioni OR . L'evento può corrispondere a qualsiasi condizione. |
Esempio di filtro (OR) | Esempio di filtro (OR) | • Operatori di stringa • in |
Filtro annidato | Regola di esempio con condizioni di filtro annidate. La regola include l'istruzione MatchesFilter , che include anche condizioni di filtro. |
Esempio di filtro annidato | Esempio di filtro annidato | • Funzione KQL di esempio • Funzione parametro di esempio • join • where |
Elenco attivo (ricerca) | Regola di ricerca di esempio che usa l'istruzione InActiveList . |
Esempio di elenco attivo (ricerca) | Esempio di elenco attivo (ricerca) | • Un 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 rispetto a un set di eventi di base, usando l'istruzione Matching Event . |
Esempio di correlazione (corrispondenza) | Esempio di correlazione (corrispondenza) | operatore join: • join • join con intervallo di tempo • shuffle • Broadcast • Union istruzione definisci: 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 filtro Wait time . |
Esempio di correlazione (intervallo di tempo) | Esempio di correlazione (intervallo di tempo) | • join • Regole e istruzioni di join di Microsoft Sentinel |
Esempio di filtro (AND): ArcSight
Ecco una regola di filtro di esempio con condizioni AND
in ArcSight.
Esempio di filtro (AND): KQL
Ecco la regola di filtro con condizioni AND
in KQL.
SecurityEvent
| where EventID == 4728
| where SubjectUserName =~ "AutoMatedService"
| where isnotempty(SubjectDomainName)
Questa regola presuppone che l'agente di monitoraggio di Azure raccoglie gli eventi Sicurezza di Windows. Pertanto, la regola usa la tabella SecurityEvent di Microsoft Sentinel.
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 condizioni OR
in ArcSight.
Esempio di filtro (OR): KQL
Ecco alcuni modi per scrivere la regola di filtro con 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"
Sebbene entrambe le opzioni siano identiche nelle 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 filtro /All Filters/Soc Filters/Exclude Valid Users
.
Esempio di filtro annidato: KQL
Ecco alcuni modi per scrivere la regola di filtro con 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:
Salvare la query seguente come funzione KQL con l'alias
ExcludeValidUsers
.SecurityEvent | where EventID == 4728 | where isnotempty(SubjectDomainName) | where SubjectUserName =~ "AutoMatedService" | project SubjectUserName
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:
Creare una funzione di parametro con
ExcludeValidUsers
come nome e alias.Definire i parametri della funzione. Ad esempio:
Tbl: (TimeGenerated:datetime, Computer:string, EventID:string, SubjectDomainName:string, TargetDomainName:string, SubjectUserName:string)
La funzione
parameter
ha la query seguente:Tbl | where SubjectUserName !~ "AutoMatedService"
Eseguire la query seguente per richiamare la funzione del parametro:
let Events = ( SecurityEvent | where EventID == 4728 ); ExcludeValidUsers(Events)
Come quarta opzione, usare la funzione join
:
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) a causa della sua semplicità. Per ottimizzare le prestazioni, evitare di usarejoin
(quarta opzione). - Per ottimizzare le query, evitare gli operatori
=~
e!~
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.
Esempio di elenco attivo (ricerca): KQL
Questa regola presuppone che l'elenco di controllo Account eccezioni Cyber-Ark 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 rispetto a un set di eventi di base, usando l'istruzione Matching Event
.
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 funzione
join
. - 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 rispetto a un set di eventi di base, usando l'istruzione Matching Event
e usa la condizione di filtro Wait time
.
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 le impostazioni di aggregazione: tre corrispondenze entro 10 minuti.
Esempio di aggregazione: KQL
SecurityEvent
| summarize Count = count() by SubjectUserName,
SubjectDomainName
| where Count >3
Passaggi successivi
In questo articolo è stato illustrato come eseguire il mapping delle regole di migrazione da ArcSight a Microsoft Sentinel.