Migrer des règles de détection ArcSight vers Microsoft Sentinel

Article
06/01/2023

Cet article explique comment identifier, comparer et migrer vos règles de détection ArcSight vers des règles d’analytique Microsoft Sentinel.

Identifier et migrer des règles

Microsoft Sentinel utilise l’analytique Machine Learning pour créer des incidents de haute fidélité actionnables. Certaines de vos détections existantes peuvent être redondantes dans Microsoft Sentinel. Par conséquent, ne migrez pas aveuglément toutes vos règles de détection et d’analyse. Passez en revue ces considérations quand vous identifiez vos règles de détection existantes.

Veillez à sélectionner les cas d’usage qui justifient la migration des règles, en tenant compte des priorités et de l’efficacité de l’entreprise.
Vérifiez que vous comprenez les types de règles Microsoft Sentinel.
Vérifiez que vous comprenez la terminologie des règles.
Examinez toutes les règles qui n’ont pas déclenché d’alertes au cours des 6 à 12 derniers mois et déterminez si elles sont toujours pertinentes.
Éliminez les menaces ou les alertes de bas niveau que vous ignorez régulièrement.
Utilisez les fonctionnalités existantes et vérifiez si les règles d’analytique intégrées de Microsoft Sentinel peuvent traiter vos cas d’usage actuels. Étant donné que Microsoft Sentinel utilise l’analytique Machine Learning pour produire des incidents haute fidélité et actionnables, il est probable que certaines de vos détections existantes ne soient plus nécessaires.
Vérifiez que vous avez connecté toutes les sources de données requises et passez en revue vos méthodes de connexion de données. Revenez sur les conversations de collecte de données pour vous assurer de la profondeur et de l’étendue des données dans vos cas d’usage.
Explorez les ressources de la communauté telles que la Place de marché de détection des menaces SOC Prime pour vérifier si vos règles sont disponibles.
Déterminez si un convertisseur de requête en ligne tel que Uncoder.io peut fonctionner pour vos règles.
Si les règles ne sont pas disponibles ou ne peuvent pas être converties, elles doivent être créées manuellement à l’aide d’une requête KQL. Examinez le mappage des règles pour créer de nouvelles requêtes.

En savoir plus sur les meilleures pratiques relatives à la migration des règles de détection.

Pour migrer vos règles d’analytique vers Microsoft Sentinel, procédez comme suit :

Vérifiez que vous avez mis en place un système de test pour chaque règle que vous souhaitez migrer.
1. Préparez un processus de validation pour vos règles migrées, y compris des scénarios et des scripts de test complets.
2. Assurez-vous que votre équipe dispose des ressources utiles pour tester vos règles migrées.
3. Confirmez que vous avez connecté toutes les sources de données requises, et révisez vos méthodes de connexion de données.
Vérifiez si vos détections sont disponibles comme modèles intégrés dans Microsoft Sentinel :
- Si les règles intégrées sont suffisantes, utilisez les modèles de règles intégrées pour créer des règles pour votre propre espace de travail.
  
  Dans Microsoft Sentinel, accédez à l’onglet Configuration > Analytique > Modèles de règles, puis créez et mettez à jour chacune des règles d’analytique pertinentes.
  
  Pour plus d’informations, consultez Détection des menaces prête à l’emploi.
- Si certaines de vos détections ne sont pas couvertes par les règles intégrées de Microsoft Sentinel, essayez un convertisseur de requêtes en ligne, par exemple Uncoder.io, pour convertir vos requêtes en KQL.
  
  Identifiez la condition du déclencheur et l’action de la règle, puis créez et passez en revue votre requête KQL.
- Si ni les règles intégrées ni un convertisseur de règles en ligne ne suffisent, vous devrez créer la règle manuellement. Dans ce cas, procédez comme suit pour commencer à créer votre règle :
  1. Identifiez les sources de données que vous souhaitez utiliser dans votre règle. Vous devez créer une table de correspondance entre les sources de données et les tables de données de Microsoft Sentinel pour identifier les tables que vous souhaitez interroger.
  2. Identifiez tous les attributs, champs ou entités de vos données que vous souhaitez utiliser dans vos règles.
  3. Identifiez les critères et la logique de vos règles. À ce stade, vous pouvez utiliser des modèles de règle comme exemples pour construire vos requêtes KQL.
    
    Pensez aux filtres, aux règles de corrélation, aux listes actives, aux ensembles de référence, aux listes de surveillance, aux anomalies de détection, aux agrégations, etc. Vous pouvez utiliser les références fournies par votre SIEM héritée pour comprendre comment mapper au mieux la syntaxe de vos requêtes.
  4. Identifiez la condition du déclencheur et l’action de la règle, puis créez et passez en revue votre requête KQL. Lorsque vous examinez votre requête, tenez compte des aides relatives à l’optimisation de KQL.
Testez la règle avec chacun de vos cas d’usage pertinents. Si elle ne fournit pas les résultats attendus, vous pouvez revoir la requête KQL et la tester à nouveau.
Lorsque vous êtes satisfait, vous pouvez considérer que la règle a été migrée. Créez un playbook pour votre action de règle le cas échéant. Pour plus d’informations, consultez Automatisation de la réponse aux menaces avec des playbooks dans Microsoft Sentinel.

En savoir plus sur les règles d’analytique :

Créez des règles d’analyse personnalisées pour détecter des menaces. Utilisez le regroupement d’alertes pour réduire la fatigue des alertes en regroupant les alertes qui se produisent dans un laps de temps donné.
Mappez les champs de données avec les entités de Microsoft Sentinel pour permettre aux ingénieurs SOC de définir les entités comme faisant partie des preuves à suivre pendant une enquête. Le mappage des entités permet également aux analystes SOC de tirer parti d’un graphique d’investigation intuitif qui peut contribuer à réduire le temps et les efforts.
Examinez les incidents avec les données UEBA, en guise d’exemple d’utilisation de preuves pour faire apparaître les événements, les alertes et les signets associés à un incident particulier dans le volet d’aperçu de l’incident.
Kusto Query Language (KQL), que vous pouvez utiliser pour envoyer des requêtes en lecture seule à votre base de données Log Analytics pour traiter les données et renvoyer les résultats. KQL est également utilisé dans d’autres services Microsoft, tels que Microsoft Defender pour point de terminaison et Application Insights.

Comparer la terminologie des règles

Ce tableau vous aide à clarifier le concept d’une règle dans Microsoft Sentinel par rapport à ArcSight.

	ArcSight	Microsoft Sentinel
Type de règle	• Filtrer la règle • Règle de jointure • Règle de liste active • Et plus	• Requête planifiée • Fusion • Sécurité Microsoft • Analytique comportementale du Machine Learning
Critères	Définissez les conditions de règle	Définir dans KQL
Condition de déclencheur	• Définir en action • Définir dans l’agrégation (pour l’agrégation d’événements)	Seuil : le nombre de résultats de la requête
Action	• Définir le champ de l’événement • Envoyer une notification • Créer un nouveau cas • Ajouter à la liste active • Et plus	• Créer une alerte ou un incident • S’intègre à Logic Apps

Mapper et comparer des exemples de règles

Utilisez ces exemples pour comparer et mapper des règles d’ArcSight à Microsoft Sentinel dans différents scénarios.

Règle	Description	Exemple de règle de détection (ArcSight)	Exemples de requête KQL	Ressources
Filtre (`AND`)	Exemple de règle avec des conditions `AND`. L’événement doit correspondre à toutes les conditions.	Exemple de filtre (AND)	Exemple de filtre (AND)	Filtre de chaînes : • Opérateurs de chaîne Filtre numérique : • Opérateurs numériques Filtre DateHeure : • il y a • DateHeure • entre • maintenant Analyse : • analyser • extrait • parse_json • parse_csv • parse_path • parse_url
Filtre (`OR`)	Exemple de règle avec des conditions `OR`. L’événement peut correspondre à l’une des conditions.	Exemple de filtre (OR)	Exemple de filtre (OR)	• Opérateurs de chaîne • dans
Filtre imbriqué	Exemple de règle avec des conditions de filtrage imbriquées. La règle inclut l’instruction `MatchesFilter`, qui inclut également les conditions de filtrage.	Exemple de filtre imbriqué	Exemple de filtre imbriqué	• Exemple de fonction de KQL • Exemple de fonction de paramètre • joindre • où
Liste active (recherche)	Exemple de règle de recherche qui utilise l’instruction `InActiveList`.	Exemple de liste active (recherche)	Exemple de liste active (recherche)	• Une watchlist est l’équivalent de la fonctionnalité de liste active. En savoir plus sur les watchlists. • Autres façons d’implémenter des recherches
Corrélation (correspondance)	Exemple de règle qui définit une condition par rapport à un ensemble d’événements de base, à l’aide de l’instruction `Matching Event`.	Exemple de corrélation (correspondance)	Exemple de corrélation (correspondance)	opérateur de jointure : • joindre • jointure avec la fenêtre de temps • lecture aléatoire • Diffuser • Union définir l’instruction : • let Agrégation : • make_set • make_list • make_bag • pack
Corrélation (fenêtre de temps)	Exemple de règle qui définit une condition par rapport à un ensemble d’événements de base, à l’aide de l’instruction `Matching Event` et utilise la condition de fitre `Wait time`.	Exemple de corrélation (fenêtre de temps)	Exemple de corrélation (fenêtre de temps)	• joindre • Règles et instruction de jointure Microsoft Sentinel

Exemple de filtre (AND) : ArcSight

Voici un exemple de règle de filtre avec des conditions AND dans ArcSight.

Exemple de filtre (AND) : KQL

Voici la règle de filtre avec des conditions AND dans KQL.

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

Cette règle suppose que Microsoft Monitoring Agent (MMA) ou Azure Monitoring Agent (AMA) collectent les événements de Sécurité Windows. Par conséquent, la règle utilise la table Microsoft Sentinel SecurityEvent.

Prenez en compte ces meilleures pratiques :

Pour optimiser vos requêtes, évitez les opérateurs qui ne respectent pas la casse lorsque cela est possible : =~.
Utilisez == si la valeur n’est pas sensible à la casse.
Triez les filtres en commençant par l’instruction where, qui filtre le plus de données.

Exemple de filtre (OR) : ArcSight

Voici un exemple de règle de filtre avec des conditions OR dans ArcSight.

Diagramme illustrant un exemple de règle de filtre (ou).

Exemple de filtre (OR) : KQL

Voici quelques façons d’écrire la règle de filtre avec des conditions OR dans KQL.

En guise de première option, utilisez l’instruction in :

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

En guise de deuxième option, utilisez l’instruction or :

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

Bien que les deux options soient identiques en niveau de performance, nous vous recommandons la première option, plus facile à lire.

Exemple de filtre imbriqué : ArcSight

Voici un exemple de règle de filtre imbriquée dans ArcSight.

Diagramme illustrant un exemple de règle de filtre (ou).

Voici une règle pour le filtre /All Filters/Soc Filters/Exclude Valid Users.

Diagramme illustrant un filtre Exclure des utilisateurs valides.

Exemple de filtre imbriqué : KQL

Voici quelques façons d’écrire la règle de filtre avec des conditions OR dans KQL.

En guise de première option, utilisez un filtre direct avec une instruction where :

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

En guise de deuxième option, utilisez une fonction KQL :

Enregistrez la requête suivant en tant que fonction KQL avec l’alias ExcludeValidUsers.

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

Utilisez la requête suivante pour filtrer l’alias ExcludeValidUsers.

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

En tant que troisième option, utilisez une fonction de paramètre :

Créez une fonction de paramètre avec ExcludeValidUsers comme nom et alias.

Définissez les paramètres de la fonction. Par exemple :

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

La fonction parameter dispose de la requête suivante :

    Tbl
    | where SubjectUserName !~ "AutoMatedService"

Exécutez la requête suivante pour appeler la fonction de paramètre :

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

En quatrième option, utilisez la fonction 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

Considérations :

Nous vous recommandons d’utiliser un filtre direct avec une instruction where (première option) en raison de sa simplicité. Pour optimiser le niveau de performance, évitez d’utiliser join (quatrième option).
Pour optimiser vos requêtes, évitez les opérateurs qui ne respectent pas la casse =~ et !~ lorsque cela est possible. Utilisez les opérateurs == et != si la valeur ne respecte pas la casse.

Exemple de liste active (recherche) : ArcSight

Voici une règle de liste active (recherche) dans ArcSight.

Diagramme illustrant un exemple de règle de liste active (recherche).

Exemple de liste active (recherche) : KQL

Cette règle suppose que la watchlist des comptes d’exception Cyber-Ark existe dans Microsoft Sentinel avec un champ Compte.

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

Triez les filtres en commençant par l’instruction where, qui filtre le plus de données.

Exemple de corrélation (correspondance) : ArcSight

Voici un exemple de règle qui définit une condition par rapport à un ensemble d’événements de base, à l’aide de l’instruction Matching Event.

Diagramme illustrant un exemple de règle de corrélation (correspondance).

Exemple de corrélation (correspondance) : KQL

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

Meilleure pratique :

Pour optimiser votre requête, assurez-vous que la table plus petite se trouve sur le côté gauche de la fonction join.
Si le côté gauche de la table est relativement petit (jusqu’à 100 000 enregistrements), ajoutez hint.strategy=broadcast pour de meilleures performances.

Exemple de corrélation (fenêtre de temps) : ArcSight

Voici un exemple de règle ArcSight qui définit une condition par rapport à un ensemble d’événements de base, à l’aide de l’instruction Matching Event et utilise la condition de filtre Wait time.

Diagramme illustrant un exemple de règle de corrélation (fenêtre de temps).

Exemple de corrélation (fenêtre de temps) : 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

Exemple d’agrégation : ArcSight

Voici un exemple de règle ArcSight avec les paramètres d’agrégation : trois correspondances dans les 10 minutes.

Diagramme illustrant un exemple de règle d’agrégation.

Exemple d'agrégation : KQL

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

Étapes suivantes

Dans cet article, vous avez appris à mapper vos règles de migration d’ArcSight à Microsoft Sentinel.

Migrer votre automatisation SOAR

Partager via