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

Les règles de détection Splunk sont des composants SIEM (Security Information and Event Management) qui se comparent aux règles d’analyse dans Microsoft Sentinel. Cet article décrit les concepts utilisés pour identifier, comparer et migrer les règles de détection Splunk vers Microsoft Sentinel. La meilleure façon de migrer des règles de détection Splunk vers Microsoft Sentinel consiste à commencer par l’expérience de migration SIEM, qui identifie les règles d’analytique prêtes à l’emploi (OOTB) pour la traduction automatique.

Si vous souhaitez migrer votre déploiement d’observabilité Splunk, découvrez comment migrer de Splunk vers Azure Monitor Logs.

Règles d’audit

Microsoft Sentinel utilise l’analytique machine learning pour créer des incidents haute fidélité et actionnables. Certaines de vos détections Splunk existantes peuvent être redondantes dans Microsoft Sentinel, donc ne migrez pas toutes les détections Splunk à l'aveugle. Passez en revue les considérations d’audit des règles 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 de la règle.
• Passez en revue les règles obsolètes qui n’ont pas d’alertes pour les 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.
• Microsoft Sentinel Analytics exigent que le type de données soit présent dans l’espace de travail Log Analytics avant qu’une règle soit activée. Vérifiez que vos sources de données requises sont 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. Utilisez ensuite l’expérience de migration SIEM pour vous assurer que les sources de données sont mappées de manière appropriée.

Migrer les règles

Une fois que vous avez identifié les détections Splunk à migrer, prenez connaissance des points suivants concernant le processus de migration :

• Comparez les fonctionnalités existantes des règles d’analyse OOTB de Microsoft Sentinel avec vos cas d’usage actuels. Utilisez l’expérience de migration SIEM pour voir quelles détections Splunk sont automatiquement converties en modèles OOTB.
• Traduisez les détections qui ne s’alignent pas sur les règles d’analyse OOTB. La meilleure façon de traduire automatiquement les détections Splunk est d’utiliser l’expérience de migration SIEM.
• Découvrez d’autres algorithmes pour vos cas d’usage en explorant les ressources de la communauté, telles que la Place de marché SOC Prime Threat Detection.
• Traduire manuellement les détections si les règles intégrées ne sont pas disponibles ou ne sont pas traduites automatiquement. Créez les nouvelles requêtes KQL et passez en revue le mappage de règles.

Pour plus d’informations, consultez bonnes pratiques pour la migration des règles de détection.

Étapes de migration des règles

Suivez ces étapes pour valider, traduire et tester chaque règle de détection Splunk pendant la migration 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 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 OOTB dans Microsoft Sentinel :

   • Utilisez l’expérience de migration SIEM pour automatiser la traduction et l’installation des modèles OOTB.

     Pour plus d’informations, consultez Utiliser l’expérience de migration SIEM.

   • Si les cas d’usage ne sont pas reflétés dans les détections, créez des règles pour votre propre espace de travail avec des modèles de règles OOTB.

     Dans Microsoft Sentinel, accédez au hub de contenu.

     Filtrer Type de contenu pour modèles de règle d’analytique.

     Recherchez et installez/mettez à jour chaque solution de hub de contenu ou modèle de règle d’analyse autonome correspondant.

     Pour plus d’informations, consultez Détection des menaces prête à l’emploi.

   • Si vous avez des détections qui ne sont pas couvertes par les règles OOTB de Microsoft Sentinel, essayez d’abordl’expérience de migration SIEM pour la traduction automatique.

   • Si ni les règles OOTB ni la migration SIEM ne traduisent complètement la détection, créez la règle manuellement. Pour créer votre règle, procédez comme suit :

     1. Identifiez les sources de données que vous souhaitez utiliser dans votre règle. Identifiez les tables Microsoft Sentinel que vous souhaitez interroger en créant une table de mappage entre les sources de données et les tables de données.

     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. Lorsque vous identifiez vos critères de règle et votre logique, envisagez d’utiliser des modèles de règle 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 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, examinez et modifiez le KQL et testez-le à nouveau.

4. Lorsque vous êtes satisfait, considérez que la règle est 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.

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

• Créez des règles d’analyse personnalisées pour détecter les menaces. 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 [graphe d’investigation] intuitif (investigate-cases.md#use-the-investigation-graph-to-deep-dive) 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 Analyse des journaux base de données pour traiter les données et renvoyer 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

Le tableau de comparaison suivant précise comment une règle basée sur KQL dans Microsoft Sentinel correspond à une détection basée sur SPL dans Splunk.

Mettre en correspondance et comparer des exemples de règles

Utilisez les tables d’exemple SPL-à-KQL et les exemples de cette section pour comparer et mapper les règles de Splunk vers Microsoft Sentinel dans divers scénarios.

Comparez les commandes de recherche Splunk courantes avec des exemples KQL

Ce tableau associe les commandes de recherche SPL courantes à leurs équivalents KQL dans Microsoft Sentinel.

lookup commande : exemple de KQL

Cet exemple KQL sert externaldata à reproduire le motif SPL lookup en filtrant les utilisateurs à partir d’une source de données externe.

Users 
| where UserID in ((externaldata (UserID:string) [
@"https://storageaccount.blob.core.windows.net/storagecontainer/users.txt" 
h@"?...SAS..." // Secret token to access the blob 
])) | ... 

stats commande : exemple de KQL

Cet exemple de KQL sert summarize à compter les transactions et à sommer les totaux, regroupés par fruit et mois.

Sales 
| summarize NumTransactions=count(), 
Total=sum(UnitPrice * NumUnits) by Fruit, 
StartOfMonth=startofmonth(SellDateTime) 

mstats commande : exemple de KQL

Cet exemple KQL regroupe les valeurs métriques dans des fourchettes de prix et compte les enregistrements dans chaque fourchette.

T | summarize count() by price_range=bin(price, 10.0) 

transaction command : exemple SPL

Cet exemple SPL regroupe les événements de démarrage et d’arrêt liés en une seule transaction par identifiant d’activité.

sourcetype=MyLogTable type=Event
| transaction ActivityId startswith="Start" endswith="Stop"
| Rename timestamp as StartTime
| Table City, ActivityId, StartTime, Duration

transaction commande : exemple de KQL

Cet exemple KQL reproduit le regroupement des transactions SPL en associant les événements de début et d’arrêt sur un identifiant d’activité partagé et en calculant la durée.

let Events = MyLogTable | where type=="Event";
Events
| where Name == "Start"
| project Name, City, ActivityId, StartTime=timestamp
| join (Events
| where Name == "Stop"
| project StopTime=timestamp, ActivityId)
on ActivityId
| project City, ActivityId, StartTime, 
Duration = StopTime – StartTime

Utilisez row_window_session() pour calculer les valeurs de début de session pour une colonne dans un jeu de lignes sérialisé.

...| extend SessionStarted = row_window_session(
Timestamp, 1h, 5m, ID != prev(ID))

eventstats command : exemple SPL

Cet exemple SPL calcule les comptes d’événements par catégorie dans des bins d’une minute puis ajoute un total par bin temporel en utilisant eventstats.

… | bin span=1m _time
|stats count AS count_i by _time, category
| eventstats sum(count_i) as count_total by _time

eventstats commande : exemple de KQL

Voici un exemple avec l’instruction join :

let binSize = 1h;
let detail = SecurityEvent 
| summarize detail_count = count() by EventID,
tbin = bin(TimeGenerated, binSize);
let summary = SecurityEvent
| summarize sum_count = count() by 
tbin = bin(TimeGenerated, binSize);
detail 
| join kind=leftouter (summary) on tbin 
| project-away tbin1

Voici un exemple avec l’instruction make_list :

let binSize = 1m;
SecurityEvent
| where TimeGenerated >= ago(24h)
| summarize TotalEvents = count() by EventID, 
groupBin =bin(TimeGenerated, binSize)
|summarize make_list(EventID), make_list(TotalEvents), 
sum(TotalEvents) by groupBin
| mvexpand list_EventID, list_TotalEvents

anomalydetection command : exemple SPL

Cet exemple SPL détecte des anomalies dans les données historiques de cours de clôture sur une période de 10 ans.

sourcetype=nasdaq earliest=-10y
| anomalydetection Close _ Price

anomalydetection commande : exemple de KQL

Cet exemple KQL utilise des fonctions d’analyse de séries temporelles pour détecter des anomalies dans les tendances de connexion des comptes désactivés sur une période de rétrospection de sept jours.

let LookBackPeriod= 7d;
let disableAccountLogon=SignIn
| where ResultType == "50057"
| where ResultDescription has "account is disabled";
disableAccountLogon
| make-series Trend=count() default=0 on TimeGenerated 
in range(startofday(ago(LookBackPeriod)), now(), 1d)
| extend (RSquare,Slope,Variance,RVariance,Interception,
LineFit)=series_fit_line(Trend)
| extend (anomalies,score) = 
series_decompose_anomalies(Trend)

Comparez les commandes Splunk eval courantes avec les équivalents KQL

Ce tableau associe les fonctions SPL eval courantes à leurs équivalents KQL dans Microsoft Sentinel.

case(X,"Y",…) Exemple SPL

Cet exemple SPL renvoie une chaîne de messages différente basée sur le code d’erreur HTTP.

case(error == 404, "Not found",
error == 500,"Internal Server Error",
error == 200, "OK")

case(X,"Y",…) Exemple KQL

Cet exemple KQL sert case() à assigner un message basé sur la valeur du code d’erreur.

T
| extend Message = case(error == 404, "Not found", 
error == 500,"Internal Server Error", "OK") 

if(X,Y,Z) Exemple KQL

Cet exemple KQL sert iif() à indiquer si un horodatage correspond au jour en cours.

iif(floor(Timestamp, 1d)==floor(now(), 1d), 
"today", "anotherday")

isint(X) Exemple KQL

Cet exemple KQL vérifie si X possède un type entier compatible en utilisant gettype et iif.

iif(gettype(X) =="long","TRUE","FALSE")

isstr(X) Exemple KQL

Cet exemple KQL vérifie si X est une valeur de chaîne en utilisant gettype et iif.

iif(gettype(X) =="string","TRUE","FALSE")

like(X,"y") Exemple

Ces exemples KQL montrent plusieurs opérateurs de correspondance de chaînes que vous pouvez utiliser pour reproduire le schéma SPL like .

… | where field has "addr"

… | where field contains "addr"

… | where field startswith "addr"

… | where field matches regex "^addr.*"

min(X,…) Exemple KQL

Ces exemples KQL montrent différentes façons de calculer des valeurs minimales en utilisant min_of, min, et arg_min.

min_of (expr_1, expr_2 ...)

…|summarize min(expr)

…| summarize arg_min(Price,*) by Product

mvfilter(X) Exemple KQL

Cet exemple KQL sert mv-apply à filtrer et réduire le contenu multi-valeur, similaire à la fonction SPL mvfilter .

T | mv-apply Metric to typeof(real) on 
(
 top 2 by Metric desc
)

mvjoin(X,Y) Exemple KQL

Cet exemple KQL sert strcat_array à joindre des éléments de tableau en une seule chaîne avec un séparateur personnalisé.

strcat_array(dynamic([1, 2, 3]), "->")

relative time(X,Y) Exemple KQL

Cet exemple KQL convertit une valeur datetime-time en temps d’époque Unix pour des calculs en temps relatif.

let toUnixTime = (dt:datetime)
{
(dt - datetime(1970-01-01))/1s 
};

replace(X,Y,Z) Exemple KQL

Cet exemple KQL utilise replace() un motif régulier pour échanger les parties mois et jour d’une chaîne de dates.

replace( @'^(\d{1,2})/(\d{1,2})/', @'\2/\1/',date)

strptime(X,Y) Exemple KQL

Cet exemple KQL sert format_datetime uniquement à afficher les heures et les minutes à partir d’une valeur datetime.

format_datetime(datetime('2017-08-16 11:25:10'),
'HH:mm')

time() Exemple KQL

Cet exemple KQL forme une valeur de date-heure comme une chaîne d’heures montrant les heures, minutes et secondes.

format_datetime(datetime(2015-12-14 02:03:04),
'h:m:s')

tostring(X,Y) Description

La fonction SPL tostring(X,Y) convertit les valeurs en chaînes de caractères et prend en charge plusieurs options de formatage. Il retourne une valeur de champ de X sous forme de chaîne.

• Si la valeur de X est un nombre, X est reformatée en valeur de chaîne.
• Si X est une valeur booléenne, X est reformaté en TRUE ou FALSE.
• Si X est un nombre, le deuxième argument Y est facultatif et peut être hex (convertit X en hexadécimal), commas (formats X avec virgules et deux décimales) ou duration (convertit à partir d’un format d’heure en secondes X en format d’heure lisible : HH:MM:SS).

tostring(X,Y) Exemple SPL

Cet tostring exemple SPL donne :

foo=615 and foo2=00:10:15:

… | eval foo=615 | eval foo2 = tostring(
foo, "duration")

urldecode(X) Exemple SPL

Cet exemple SPL décode une chaîne encodée par URL pour revenir à sa forme d’origine.

urldecode("http%3A%2F%2Fwww.splunk.com%2Fdownload%3Fr%3Dheader")

Comparez les commandes Splunk stats courantes avec les équivalents KQL

Ce tableau associe les fonctions d’agrégation SPL stats courantes à leurs équivalents KQL dans Microsoft Sentinel.

Étapes suivantes

Vous avez appris à identifier, comparer et mapper des règles de détection Splunk à des règles d’analyse Microsoft Sentinel. Poursuivez la migration de votre automatisation SOAR.