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

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

Identifier et migrer des règles

Microsoft Sentinel utilise l’analytique machine learning pour créer des incidents haute fidélité et actionnables, et certaines de vos détections existantes peuvent être redondantes dans Microsoft Sentinel. Par conséquent, ne migrez pas toutes vos règles de détection et d’analytique à l’aveugle. Passez en revue ces considérations lorsque vous identifiez vos règles de détection existantes.

• Veillez à sélectionner des cas d’usage qui justifient la migration des règles, en tenant compte de la priorité métier et de l’efficacité.
• Vérifiez que vous comprenez Microsoft Sentinel types de règles.
• Vérifiez que vous comprenez la terminologie de la règle.
• Passez en revue les règles qui n’ont déclenché aucune alerte 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 case activée si les règles d’analyse intégrées de Microsoft Sentinel peuvent répondre à 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.
• Confirmez les sources de données connectées et passez en revue vos méthodes de connexion de données. Revisitez les conversations de collecte de données pour garantir la profondeur et l’étendue des données dans les cas d’usage que vous prévoyez de détecter.
• Explorez les ressources de la communauté telles que soc Prime Threat Detection Marketplace pour case activée si vos règles sont disponibles.
• Déterminez si un convertisseur de requêtes 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. Passez en revue le mappage des règles pour créer des requêtes.

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

Pour migrer vos règles d’analyse vers Microsoft Sentinel :

1. Vérifiez qu’un système de test est en place pour chaque règle que vous souhaitez migrer.

   1. Préparez un processus de validation pour vos règles migrées, y compris les scénarios de test complets et les scripts.

   2. Vérifiez que votre équipe dispose de ressources utiles pour tester vos règles migrées.

   3. Vérifiez que toutes les sources de données requises sont connectées et passez en revue vos méthodes de connexion de données.

2. Vérifiez si vos détections sont disponibles en tant que modèles intégrés dans Microsoft Sentinel :

   • Si les règles intégrées sont suffisantes, utilisez des modèles de règles intégrés pour créer des règles pour votre propre espace de travail.

     Dans Microsoft Sentinel, accédez à l’onglet Modèles de règle Analyse >> de configuration, puis créez et mettez à jour chaque règle d’analyse pertinente.

     Pour plus d’informations, consultez Créer des règles d’analyse planifiées à partir de modèles.

   • Si vous avez des détections qui ne sont pas couvertes par les règles intégrées de Microsoft Sentinel, essayez un convertisseur de requêtes en ligne, tel que Uncoder.io pour convertir vos requêtes en KQL.

     Identifiez la condition de déclencheur et l’action de règle, puis construisez et examinez votre requête KQL.

   • Si ni les règles intégrées ni le convertisseur de règles en ligne ne sont suffisants, vous devez 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 mappage entre des sources de données et des tables de données dans Microsoft Sentinel pour identifier les tables que vous souhaitez interroger.

     2. Identifiez les attributs, champs ou entités de vos données que vous souhaitez utiliser dans vos règles.

     3. Identifiez vos critères et votre logique de règle. À ce stade, vous pouvez utiliser des modèles de règle comme exemples pour la construction de vos requêtes KQL.

        Considérez les filtres, les règles de corrélation, les listes actives, les ensembles de références, les watchlists, les anomalies de détection, les agrégations, etc. Vous pouvez utiliser des références fournies par votre siem hérité pour comprendre comment mapper au mieux la syntaxe de votre requête.

     4. Identifiez la condition de déclencheur et l’action de règle, puis construisez et examinez votre requête KQL. Lorsque vous examinez votre requête, tenez compte des ressources de conseils d’optimisation KQL.

3. Testez la règle avec chacun de vos cas d’usage pertinents. S’il ne fournit pas les résultats attendus, vous pouvez examiner le KQL et le tester à nouveau.

4. Lorsque vous êtes satisfait, vous pouvez considérer la règle migrée. Créez un playbook pour votre action de règle en fonction des besoins. Pour plus d’informations, consultez Automatiser la réponse aux menaces avec des playbooks dans Microsoft Sentinel.

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

• Règles d’analyse planifiées dans Microsoft Sentinel. Utilisez le regroupement d’alertes pour réduire la fatigue des alertes en regroupant les alertes qui se produisent dans une période donnée.
• Mapper des champs de données à des entités dans Microsoft Sentinel pour permettre aux ingénieurs SOC de définir des entités dans le cadre de la preuve à suivre pendant une enquête. Le mappage d’entités permet également aux analystes SOC de tirer parti d’un graphique d’investigation intuitif qui peut aider à réduire le temps et les efforts.
• Examinez les incidents avec des données UEBA, comme exemple d’utilisation des preuves pour faire apparaître des événements, des alertes et des signets associés à un incident particulier dans le volet d’aperçu de l’incident.
• Langage de requête Kusto (KQL) que vous pouvez utiliser pour envoyer des requêtes en lecture seule à votre base de données Log Analytics afin de traiter des données et de retourner des 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 de règle dans Microsoft Sentinel par rapport à ArcSight.

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.

Exemple de filtre (AND) : ArcSight

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

Exemple de filtre (AND) : KQL

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

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

Cette règle part du principe que l’agent ama (Azure Monitoring Agent) collecte les événements Sécurité Windows. Par conséquent, la règle utilise la table Microsoft Sentinel SecurityEvent.

Tenez compte des meilleures pratiques suivantes :

• Pour optimiser vos requêtes, évitez, dans la mesure du possible, les opérateurs ne respectant pas la casse : =~.
• Utilisez == si la valeur ne respecte pas 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 OR conditions dans ArcSight.

Exemple de filtre (OR) : KQL

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

Comme première option, utilisez l’instruction in :

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

Comme 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 matière de performances, nous vous recommandons la première option, qui est plus facile à lire.

Exemple de filtre imbriqué : ArcSight

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

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

Exemple de filtre imbriqué : KQL

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

Comme première option, utilisez un filtre direct avec une where instruction :

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

Comme deuxième option, utilisez une fonction KQL :

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

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

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

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

Comme troisième option, utilisez une fonction de paramètre :

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

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

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

3. La parameter fonction a la requête suivante :

       Tbl
       | where SubjectUserName !~ "AutoMatedService"
   

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

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

Comme quatrième option, utilisez la join fonction :

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 where instruction (première option) en raison de sa simplicité. Pour optimiser les performances, évitez d’utiliser join (quatrième option).
• Pour optimiser vos requêtes, évitez les opérateurs et !~ ne respectant pas la =~ casse 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.

Exemple de liste active (recherche) : KQL

Cette règle part du principe que la watchlist Cyber-Ark Exception Accounts 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 ArcSight 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) : KQL

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

Meilleures pratiques :

• Pour optimiser votre requête, vérifiez que la table plus petite se trouve sur le côté gauche de la join fonction.
• 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 Wait time filtre.

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 en 10 minutes.

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.