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

Cet article décrit comment identifier, comparer et migrer vos règles de détection QRadar vers des règles intégrées 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 :

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

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

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

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 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 (investigate-cases.md#use-the-investigation-graph-to-deep-dive) 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 à QRadar.

	QRadar	Microsoft Sentinel
Type de règle	• Événements • Flux • Courant • Infraction • Règles de détection des anomalies	• Requête planifiée • Fusion • Sécurité Microsoft • Analytique comportementale du Machine Learning
Critères	Définir dans la condition de test	Définir dans KQL
Condition de déclencheur	Définir dans la règle	Seuil : le nombre de résultats de la requête
Action	• Créer une infraction • Distribuer un nouvel événement • Ajouter à un jeu ou des données de référence • 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 de QRadar à Microsoft Sentinel dans différents scénarios.

Règle	Syntaxe	Exemple de règle de détection (QRadar)	Exemples de requête KQL	Ressources
Tests de propriétés courantes	Syntaxe QRadar	• Exemple d’expression régulière • Exemple de requête de filtre AQL • Exemple equals/not equals	• Exemple d’expression régulière • Exemple de requête de filtre AQL • Exemple equals/not equals	• Expression régulière : matches regex • Requête de filtre AQL : opérateurs de chaîne • equals/not equals : opérateurs de chaîne
Tests de date/heure	Syntaxe QRadar	• Exemple de jour du mois sélectionné • Exemple de jour de la semaine sélectionné • Exemple after/before/at	• Exemple de jour du mois sélectionné • Exemple de jour de la semaine sélectionné • Exemple after/before/at	• Opérateurs de date et d’heure • Jour du mois sélectionné : dayofmonth() • Jour de la semaine sélectionné : dayofweek() • after/before/at : format_datetime()
Tests de propriétés d’événement	Syntaxe QRadar	• Exemple de protocole IP • Exemple de chaîne de charge utile d’événement	• Exemple de protocole IP • Exemple de chaîne de charge utile d’événement	• Protocole IP : opérateurs de chaîne • Chaîne de charge utile d’événement : has
Fonctions : compteurs	Syntaxe QRadar	Exemple de propriété et d’heure d’événement	Exemple de propriété et d’heure d’événement	summarize
Fonctions : conditions négatives	Syntaxe QRadar	Exemple de conditions négatives	Exemple de conditions négatives	• join() • Opérateurs de chaîne • Opérateurs numériques
Fonctions : simples	Syntaxe QRadar	Exemple de conditions simples	Exemple de conditions simples	or
Tests d’adresses IP/de ports	Syntaxe QRadar	• Exemple de port source • Exemple d’adresse IP source	• Exemple de port source • Exemple d’adresse IP source
Type de source de journal	Syntaxe QRadar	Exemple de source de journal	Exemple de source de journal

Syntaxe des tests de propriétés courantes

Voici la syntaxe QRadar pour une règle de tests de propriétés courantes.

Tests de propriétés courantes : exemple d’expression régulière (QRadar)

Voici la syntaxe d’un exemple de règle de tests de propriétés courantes QRadar qui utilise une expression régulière :

when any of <these properties> match <this regular expression>

Voici l’exemple de règle dans QRadar.

Tests de propriétés courantes : exemple d’expression régulière (KQL)

Voici la règle de tests de propriétés courantes avec une expression régulière dans KQL.

CommonSecurityLog
| where tostring(SourcePort) matches regex @"\d{1,5}" or tostring(DestinationPort) matches regex @"\d{1,5}"

Tests de propriétés courantes : exemple de requête de filtre AQL (QRadar)

Voici la syntaxe d’un exemple de règle de tests de propriétés courantes QRadar qui utilise une requête de filtre AQL.

when the event matches <this> AQL filter query

Voici l’exemple de règle dans QRadar.

Tests de propriétés courantes : exemple de requête de filtre AQL (KQL)

Voici la règle de tests de propriétés courantes avec une requête de filtre AQL dans KQL.

CommonSecurityLog
| where SourceIP == '10.1.1.10'

Tests de propriétés courantes : exemple equals/not equals (QRadar)

Voici la syntaxe d’un exemple de règle de tests de propriétés courantes QRadar qui utilise l’opérateur equals ou not equals.

and when <this property> <equals/not equals> <this property>

Voici l’exemple de règle dans QRadar.

Tests de propriétés courantes : exemple equals/not equals (KQL)

Voici la règle de tests de propriétés courantes avec l’opérateur equals ou not equals dans KQL.

CommonSecurityLog
| where SourceIP == DestinationIP

Syntaxe des tests de date/heure

Voici la syntaxe QRadar pour une règle de tests de date/heure.

Tests de date/heure : Exemple de jour du mois sélectionné (QRadar)

Voici la syntaxe d’un exemple de règle de tests de date/heure QRadar qui utilise un jour sélectionné du mois.

and when the event(s) occur <on/after/before> the <selected> day of the month

Voici l’exemple de règle dans QRadar.

Tests de date/heure : Exemple de jour du mois sélectionné (KQL)

Voici la règle de tests de date/heure avec un jour du mois sélectionné dans KQL.

SecurityEvent
 | where dayofmonth(TimeGenerated) < 4

Tests de date/heure : Exemple de jour de la semaine sélectionné (QRadar)

Voici la syntaxe d’un exemple de règle de tests de date/heure QRadar qui utilise un jour sélectionné de la semaine :

and when the event(s) occur on any of <these days of the week{Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday}>

Voici l’exemple de règle dans QRadar.

Tests de date/heure : Exemple de jour de la semaine sélectionné (KQL)

Voici la règle de tests de date/heure avec un jour de la semaine sélectionné dans KQL.

SecurityEvent
 | where dayofweek(TimeGenerated) between (3d .. 5d)

Tests de date/heure : exemple after/before/at (QRadar)

Voici la syntaxe d’un exemple de règle de tests de propriétés courantes QRadar qui utilise l’opérateur after, before ou at.

and when the event(s) occur <after/before/at> <this time{12.00AM, 12.05AM, ...11.50PM, 11.55PM}>

Voici l’exemple de règle dans QRadar.

Tests de date/heure : exemple after/before/at (KQL)

Voici la règle de tests de date/heure qui utilise l’opérateur after, before ou at dans KQL.

SecurityEvent
| where format_datetime(TimeGenerated,'HH:mm')=="23:55"

TimeGenerated est au format UTC/GMT.

Syntaxe des tests de propriétés d’événement

Voici la syntaxe QRadar pour une règle de tests de propriétés d’événement.

Tests de propriétés d’événement : exemple de protocole IP (QRadar)

Voici la syntaxe d’un exemple de règle de tests de propriétés d’événement QRadar qui utilise un protocole IP.

and when the IP protocol is one of the following <protocols>

Voici l’exemple de règle dans QRadar.

Tests de propriétés d’événement : exemple de protocole IP (KQL)

CommonSecurityLog
| where Protocol in ("UDP","ICMP")

Tests de propriétés d’événement : exemple de chaîne de charge utile d’événement (QRadar)

Voici la syntaxe d’un exemple de règle de tests de propriétés d’événement QRadar qui utilise une valeur de chaîne Event Payload.

and when the Event Payload contains <this string>

Voici l’exemple de règle dans QRadar.

Tests de propriétés d’événement : exemple de chaîne de charge utile d’événement (KQL)

CommonSecurityLog
| where DeviceVendor has "Palo Alto"

search "Palo Alto"

Pour optimiser les performances, évitez d’utiliser la commande search si vous connaissez déjà le nom de la table.

Fonctions : syntaxe des compteurs

Voici la syntaxe QRadar pour une règle de fonctions qui utilise des compteurs.

Compteurs : exemple de propriété et d’heure d’événement (QRadar)

Voici la syntaxe d’un exemple de règle de fonctions QRadar qui utilise un nombre défini de propriétés d’événement en un nombre défini de minutes.

and when at least <this many> events are seen with the same <event properties> in <this many> <minutes>

Voici l’exemple de règle dans QRadar.

Compteurs : exemple de propriété et d’heure d’événement (KQL)

CommonSecurityLog
| summarize Count = count() by SourceIP, DestinationIP
| where Count >= 5

Fonctions : syntaxe des conditions négatives

Voici la syntaxe QRadar pour une règle de fonctions qui utilise des conditions négatives.

Exemple de conditions négatives (QRadar)

Voici la syntaxe pour un exemple de règle de fonctions QRadar qui utilise des conditions négatives.

and when none of <these rules> match in <this many> <minutes> after <these rules> match with the same <event properties>

Voici deux règles définies dans QRadar. Les conditions négatives seront basées sur ces règles.

Voici un exemple de règle de conditions négatives basée sur les règles ci-dessus.

Exemple de conditions négatives (KQL)

let spanoftime = 10m;
let Test2 = (
CommonSecurityLog
| where Protocol !in ("UDP","ICMP")
| where TimeGenerated > ago(spanoftime)
);
let Test6 = (
CommonSecurityLog
| where SourceIP == DestinationIP
);
Test2
| join kind=rightanti Test6 on $left. SourceIP == $right. SourceIP and $left. Protocol ==$right. Protocol

Fonctions : syntaxe des conditions simples

Voici la syntaxe QRadar pour une règle de fonctions qui utilise des conditions simples.

Exemple de conditions simples (QRadar)

Voici la syntaxe pour un exemple de règle de fonctions QRadar qui utilise des conditions simples.

and when an event matches <any|all> of the following <rules>

Voici l’exemple de règle dans QRadar.

Exemple de conditions simples (KQL)

CommonSecurityLog
| where Protocol !in ("UDP","ICMP") or SourceIP == DestinationIP

Syntaxe des tests d’adresse IP/de port

Voici la syntaxe QRadar pour une règle de test d’adresse IP/de port.

Tests d’adresse IP/de port : exemple de port source (QRadar)

Voici la syntaxe d’un exemple de règle QRadar spécifiant un port source.

and when the source port is one of the following <ports>

Voici l’exemple de règle dans QRadar.

Tests d’adresse IP/de port : exemple de port source (KQL)

CommonSecurityLog
| where SourcePort == 20

Tests d’adresse IP/de port : exemple d’adresse IP source (QRadar)

Voici la syntaxe d’un exemple de règle QRadar spécifiant une adresse IP source.

and when the source IP is one of the following <IP addresses>

Voici l’exemple de règle dans QRadar.

Tests d’adresse IP/de port : exemple d’adresse IP source (KQL)

CommonSecurityLog
| where SourceIP in (“10.1.1.1”,”10.2.2.2”)

Syntaxe des tests de source de journal

Voici la syntaxe QRadar pour une règle de tests de source de journal.

Exemple de source de journal (QRadar)

Voici la syntaxe d’un exemple de règle QRadar spécifiant des sources de journal.

and when the event(s) were detected by one or more of these <log source types>

Voici l’exemple de règle dans QRadar.

Exemple de source de journal (KQL)

OfficeActivity
| where OfficeWorkload == "Exchange"

Étapes suivantes

Dans cet article, vous avez appris à mapper vos règles de migration de QRadar vers Microsoft Sentinel.

Migrer votre automatisation SOAR