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 transférer 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 les considérations suivantes 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 des règles.
• Examinez les règles qui n’ont pas déclenché d’alertes au cours des six à douze 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’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 des ressources communautaires telles que le SOC Prime Threat Detection Marketplace pour vérifier 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. Consultez la correspondance des règles pour créer de nouvelles 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 apprendre à créer des règles à partir de modèles intégrés, voir Créer des règles d’analytique 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éclenchement et l’action de la 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 les références fournies par votre SIEM hérité pour mapper la syntaxe des requêtes ArcSight vers KQL.

     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 que la règle a été migrée. Créez un playbook pour votre action de règle le cas échéant. Pour créer et utiliser des playbooks pour les actions de règles, voir Automate threat response with playbooks dans Microsoft Sentinel.

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

• Règles d’analyse planifiée dans Microsoft Sentinel : Utilisez le regroupement d’alertes pour réduire la fatigue des alertes en regroupant celles qui surviennent dans un délai donné.
• Mapper les champs de données vers les entités dans Microsoft Sentinel : Permettre aux ingénieurs SOC de définir des entités comme faisant partie des preuves à suivre lors d’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.
• Enquêter sur les incidents avec des données UEBA : À titre d’exemple de la façon d’utiliser les preuves pour mettre en avant des événements, des alertes et tout favori associé à un incident particulier dans le panneau d’aperçu des incidents.
• Langage de requête Kusto (KQL) : Vous pouvez utiliser KQL pour envoyer des requêtes en lecture seule à votre base de données Log Analytics afin de traiter les données et de 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 de règle dans Microsoft Sentinel par rapport à ArcSight.

Mettre en correspondance et comparer des exemples de règles

Utilisez les exemples suivants pour comparer les règles de détection ArcSight avec les requêtes Microsoft Sentinel équivalentes écrites en Kusto Query Language (KQL).

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 filtrage avec les conditions AND en 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 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 OR conditions dans ArcSight.

Exemple de filtre (OR) : KQL

Voici quelques façons de rédiger la règle de filtrage avec des conditions OR 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 de rédiger la règle de filtrage avec des conditions OR 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

Considerations

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

Exemple de liste active (recherche) : KQL

La requête KQL suivante utilise la liste de surveillance Cyber-Ark Comptes d’exception pour filtrer les résultats de recherche.

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

L’exemple KQL suivant montre comment implémenter la règle de corrélation de correspondance ArcSight dans Microsoft Sentinel.

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

Bonnes 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

L’exemple KQL suivant implémente une règle de corrélation avec une fenêtre de temps équivalente à l’exemple 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

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

La requête KQL suivante montre comment détecter trois correspondances ou plus à l’aide de l’agrégation.

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

Étape suivante