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

Cet article explique comment identifier, comparer et migrer vos règles de détection QRadar vers les règles intégrées de Microsoft Sentinel. Il vous guide dans l'inventaire de vos détections existantes, la comparaison de la terminologie des règles entre QRadar et Microsoft Sentinel, et le choix du bon chemin de migration — que ce soit en adoptant des modèles d'analyses intégrés depuis le Content Hub, en convertissant des requêtes avec un outil en ligne, ou en rédigeant des requêtes personnalisées en langage de requêtes Kusto (KQL). À la fin, vous disposerez d'une approche structurée pour migrer vos règles de détection tout en tirant parti des analyses d'apprentissage automatique de 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 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 vérifiez si les règles analytiques 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 le hub de contenu :

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

     1. Dans Microsoft Sentinel, accédez à Gestion du contenu > Hub de contenu.
     2. Recherchez et installez la règle d’analyse appropriée.

     Pour plus d’informations, consultez Découvrir et gérer le contenu Microsoft Sentinel prêt à l’emploi et 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 disponibles dans le Hub de contenu, essayez un convertisseur de requête 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 solutions du hub de contenu 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ègles comme exemples pour construire 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ée pour comprendre comment mapper au mieux la syntaxe de vos requêtes.

     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 plus d’informations, consultez Automatiser la réponse aux menaces avec des playbooks dans Microsoft Sentinel.

Pour plus d’informations sur les règles d’analytique Microsoft Sentinel et KQL, consultez les ressources suivantes :

• 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) : que vous pouvez utiliser 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 d’une règle dans Microsoft Sentinel par rapport à QRadar. Les types de règles Microsoft Sentinel incluent les requêtes planifiées, Fusion (qui corrélée automatiquement les alertes provenant de plusieurs sources de données en incidents grâce au machine learning), Sécurité Microsoft et l’analyse du comportement en Machine Learning (ML).

Mettre en correspondance 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. Les requêtes d’exemple sont écrites en Kusto Query Language (KQL), le langage de requête utilisé par Microsoft Sentinel.

Syntaxe commune des tests de propriétés

Voici la syntaxe QRadar pour une règle de test de propriété commune.

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

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

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

Voici la règle d’exemple dans QRadar :

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

Voici la règle commune des tests de propriétés avec une expression régulière en KQL.

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

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

Voici la syntaxe d’une règle d’exemple 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 la règle d’exemple dans QRadar :

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

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

CommonSecurityLog
| where SourceIP == '10.1.1.10'

Exemple de tests courants de propriété : égal/pas égal (QRadar)

Voici la syntaxe d’un exemple de règle des tests de propriétés communes de 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 :

Exemple de tests de propriété courants : égalité/inégalité (KQL)

Voici la règle des tests de propriété communs 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 date/heure :

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

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

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

Voici la règle d’exemple dans QRadar :

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

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

SecurityEvent
 | where dayofmonth(TimeGenerated) < 4

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

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

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

Voici la règle d’exemple dans QRadar :

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

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

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

Tests de date/heure : après/avant/à l’exemple (QRadar)

Voici la syntaxe d’une règle exemple de tests date/heure de QRadar qui utilise , afterbefore, ou at opérateur :

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

Voici la règle d’exemple dans QRadar :

Exemple de tests de date/heure avec after/before/at (KQL)

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

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

TimeGenerated est en UTC/GMT.

Syntaxe des tests sur les propriétés d’événement

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

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

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

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

Voici la règle d’exemple dans QRadar :

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

Voici la règle des tests de propriétés d’événement avec un filtre de protocole IP dans 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’une règle d’exemple de tests de propriétés d’événements QRadar qui utilise une Event Payload valeur de chaîne :

and when the Event Payload contains <this string>

Voici la règle d’exemple dans QRadar :

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

Voici la règle des tests de propriétés d’événement avec la chaîne Event Payload dans KQL. Pour optimiser les performances, évitez d’utiliser la search commande si vous connaissez déjà le nom de la table.

CommonSecurityLog
| where DeviceVendor has "Palo Alto"

search "Palo Alto"

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’une règle d’exemple de fonctions QRadar qui utilise un nombre défini de propriétés d’événements 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 la règle d’exemple dans QRadar :

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

Voici la règle des compteurs avec la propriété d’événement et les conditions temporelles dans 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 d’une règle d’exemple 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 sont basées sur ces règles :

Voici un exemple de la règle des conditions négatives basée sur les deux règles QRadar précédemment définies (Test2 et Test6) :

Exemple de conditions négatives (KQL)

Voici la règle des conditions négatives avec une rightanti jointure dans 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 d’une règle d’exemple de fonctions QRadar qui utilise des conditions simples :

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

Voici la règle d’exemple dans QRadar :

Exemple de conditions simples (KQL)

Voici la règle des conditions simples dans KQL :

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

Syntaxe des tests IP/port

Voici la syntaxe QRadar pour une règle de tests IP/port :

Tests IP/port : exemple de port source (QRadar)

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

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

Voici la règle d’exemple dans QRadar :

Tests IP/port : exemple de port source (KQL)

Voici la règle des tests IP/port avec un filtre de port source dans KQL :

CommonSecurityLog
| where SourcePort == 20

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

Voici la syntaxe d’une règle QRadar d’exemple spécifiant une IP source :

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

Voici la règle d’exemple dans QRadar :

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

Voici la règle des tests IP/port avec un filtre IP source dans 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 test source de journal :

Exemple de source de log (QRadar)

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

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

Voici la règle d’exemple dans QRadar :

Exemple de source de journal (KQL)

Voici la règle des tests de source de journal dans KQL.

OfficeActivity
| where OfficeWorkload == "Exchange"

Étape suivante