Partager via

Agréger des données Microsoft Sentinel avec des règles récapitulatives (préversion)

  • Article
  • S’applique à:
    Microsoft Sentinel in the Azure portal, Microsoft Sentinel in the Microsoft Defender portal

Utilisez des règles récapitulatives dans Microsoft Sentinel pour agréger de grands jeux de données en arrière-plan et bénéficier ainsi d’une expérience d’opérations de sécurité plus fluide parmi tous les niveaux de journal. Les données récapitulatives sont précompilées dans des tables de journaux personnalisées, et fournissent des performances de requête rapides, y compris les requêtes exécutées sur des données dérivées des niveaux de journal à faible coût. Les règles récapitulatives peuvent vous aider à optimiser vos données aux fins suivantes :

  • Analyse et rapports, en particulier sur des jeux de données volumineux et des intervalles de temps, comme requis pour l’analyse de la sécurité et des incidents, les rapports commerciaux mensuels ou annuels, et ainsi de suite.
  • Économies de coûts sur les journaux détaillés, que vous pouvez conserver aussi peu ou aussi longtemps que nécessaire dans un niveau de journal moins coûteux, et envoyer des données résumées uniquement vers une table Analytics à des fins d’analyse et de création de rapports.
  • Sécurité et confidentialité des données, en supprimant ou en obfusquant les détails de confidentialité dans les données partageables résumées et en limitant l’accès aux tables avec des données brutes.

Accédez aux résultats des règles récapitulatives via le langage de requête Kusto (KQL) dans les activités de détection, d’investigation, de repérage et de création de rapports. Utilisez les résultats des règles récapitulatives pour des périodes plus longues dans les activités d’investigation historique, de repérage et de conformité.

Les résultats des règles récapitulatives sont stockés dans des tables distinctes sous le plan de données Analytique, et facturés en conséquence. Pour plus d’informations sur les plans de données et les coûts de stockage, consultez Sélectionner un plan de table en fonction des modèles d’utilisation dans un espace de travail Log Analytics.

Important

Les règles récapitulatives sont actuellement en PRÉVERSION. Consultez l’Avenant aux conditions d’utilisation pour les préversions de Microsoft Azure pour connaître les conditions juridiques supplémentaires s’appliquant aux fonctionnalités Azure sont en version bêta, en préversion ou non encore en disponibilité générale.

Microsoft Sentinel est désormais en disponibilité générale dans la plateforme d’opérations de sécurité unifiée Microsoft du portail Microsoft Defender. Pour en savoir plus, consultez Microsoft Sentinel dans le portail Microsoft Defender.

Prérequis

Pour créer des règles récapitulatives dans Microsoft Sentinel :

Nous vous recommandons d’expérimenter votre requête de règle récapitulative dans la page Journaux avant de créer votre règle. Vérifiez que la requête n’approche pas et n’atteint pas la limite de requête, et qu’elle produit le schéma prévu et les résultats attendus. Si la requête est proche des limites de requête, envisagez d’utiliser une binSize plus petite pour traiter moins de données par bac. Vous pouvez également modifier la requête pour retourner moins d’enregistrements ou supprimer des champs avec un volume plus élevé.

Créer une règle récapitulative

Créez une règle récapitulative pour agréger un grand jeu de données spécifique dans une table dynamique. Configurez la fréquence de votre règle pour déterminer la fréquence à laquelle votre jeu de données agrégé est mis à jour à partir des données brutes.

  1. Dans le portail Azure, dans le menu de navigation Microsoft Sentinel, sous Configuration, sélectionnez Règles récapitulatives (préversion). Dans le portail Defender, sélectionnez Microsoft Sentinel > Configuration > Règles récapitulatives (préversion). Par exemple :

    Capture d’écran de la page Règles récapitulatives dans le portail Azure.

  2. Sélectionnez + Créer et entrez les détails suivants :

    • Nom. Entrez un nom explicite pour votre règle.

    • Description. Entrer une description facultative.

    • Table de destination. Définissez la table de journal personnalisée dans laquelle vos données sont agrégées :

      • Si vous sélectionnez Table de journal personnalisée existante, sélectionnez la table que vous souhaitez utiliser.

      • Si vous sélectionnez Nouvelle table de journal personnalisée, entrez un nom explicite pour votre table. Le nom de table complet utilise la syntaxe suivante : <tableName>_CL.

  3. Nous vous recommandons d’activer les paramètres de diagnostic SummaryLogs sur votre espace de travail afin d’obtenir une visibilité sur les exécutions et les échecs historiques. Si les paramètres de diagnostic SummaryLogs ne sont pas activés, vous êtes invité à les activer dans la zone Paramètres de diagnostic.

    Si les paramètres de diagnostic SummaryLogs sont déjà activés, mais que vous souhaitez modifier les paramètres, sélectionnez Configurer les paramètres de diagnostic avancés. Lorsque vous revenez à la page de l’Assistant Règle récapitulative, veillez à sélectionner Actualiser pour actualiser les détails de vos paramètres.

    Important

    Les paramètres de diagnostic SummaryLogs ont des coûts supplémentaires. Pour plus d’informations, consultez Paramètres de diagnostic dans Azure Monitor.

  4. Sélectionnez Suivant : Définir la logique récapitulative > pour continuer.

  5. Dans la page Définir la logique récapitulative, entrez votre requête récapitulative. Par exemple, pour extraire du contenu à partir de Google Cloud Platform, vous pouvez entrer :

    GCPAuditLogs
| where ServiceName == 'pubsub.googleapis.com'
| summarize count() by Severity

    Pour plus d’informations, consultez Exemples de scénarios de règle récapitulative et Langage de requête Kusto (KQL) dans Azure Monitor.

  6. Sélectionnez Aperçu des résultats pour afficher un exemple des données que vous collecteriez avec la requête configurée.

  7. Dans la zone Planification des requêtes, définissez les détails suivants :

    • La fréquence à laquelle vous souhaitez que la règle s’exécute.
    • Si vous souhaitez que la règle s’exécute avec un certain délai, en minutes.
    • Le moment où vous souhaitez que la règle commence à s’exécuter.

    Les heures définies dans la planification sont basées sur la colonne timegenerated de vos données.

  8. Sélectionnez Suivant : Vérifier + créer >>Enregistrer pour terminer la création de la règle récapitulative.

Les règles récapitulatives existantes sont répertoriées dans la page Règles récapitulatives (préversion), où vous pouvez passer en revue l’état de vos règles. Pour chaque règle, sélectionnez le menu d’options à la fin de la ligne pour effectuer l’une des actions suivantes :

  • Afficher les données actuelles de la règle dans la page Journaux, comme si vous deviez exécuter la requête immédiatement.
  • Afficher l’historique des exécutions de la règle sélectionnée.
  • Désactiver ou activer la règle.
  • Modifier la configuration de la règle.

Pour supprimer une règle, sélectionnez la ligne de la règle, puis Supprimer dans la barre d’outils en haut de la page.

Remarque

Azure Monitor prend également en charge la création de règles récapitulatives via l’API ou un modèle ARM (Azure Resource Monitor). Pour plus d’informations, consultez Créer ou mettre à jour une règle récapitulative.

Exemples de scénarios de règles récapitulatives

Cette section passe en revue les scénarios courants de création de règles récapitulatives dans Microsoft Sentinel, et fournit quelques recommandations concernant la configuration de chaque règle. Pour plus d’informations et d’exemples, consultez Utiliser des règles récapitulatives avec des journaux auxiliaires (exemple de processus) et Sources de journal à utiliser pour l’ingestion de journaux auxiliaires.

Rechercher rapidement une adresse IP malveillante dans votre trafic réseau

Scénario : Vous êtes un chasseur de menaces, et l’un des objectifs de votre équipe consiste à identifier toutes les instances de l’interaction d’une adresse IP malveillante dans les journaux de trafic réseau suite à un incident actif, au cours des 90 derniers jours.

Défi : Microsoft Sentinel ingère actuellement plusieurs téraoctets de journaux réseau par jour. Vous devez les parcourir rapidement afin de trouver des correspondances pour l’adresse IP malveillante.

Solution : Nous vous recommandons d’utiliser des règles récapitulatives pour effectuer les opérations suivantes :

  1. Créez un jeu de données récapitulatif pour chaque adresse IP liée à l’incident, y compris SourceIP, DestinationIP, MaliciousIP, RemoteIP, chacun répertoriant des attributs importants, tels que IPType, FirstTimeSeen et LastTimeSeen.

    Le jeu de données récapitulatif vous permet de rechercher rapidement une adresse IP spécifique, et de limiter l’intervalle de temps où l’adresse IP est détectée. Vous pouvez le faire même lorsque les événements recherchés se sont produits il y a plus de 90 jours, ce qui est au-delà de leur période de rétention dans l’espace de travail.

    Dans cet exemple, configurez le récapitulatif pour qu’il s’exécute quotidiennement, afin que la requête ajoute de nouveaux enregistrements récapitulatifs chaque jour jusqu’à son expiration.

  2. Créez une règle analytique qui s’exécute pendant moins de deux minutes sur le jeu de données récapitulatif, et explore rapidement l’intervalle de temps spécifique lorsque l’adresse IP malveillante a interagi avec le réseau d’entreprise.

    Veillez à configurer des intervalles d’exécution allant jusqu’à cinq minutes au minimum, afin de prendre en charge différentes tailles de charge utile récapitulative. Cela garantit qu’il n’y a aucune perte même en cas de retard d’ingestion d’événement.

    Par exemple :

    let csl_columnmatch=(column_name: string) {
CommonSecurityLog
| where isnotempty(column_name)
| extend
    Date = format_datetime(TimeGenerated, "yyyy-MM-dd"),
    IPaddress = column_ifexists(column_name, ""),
    FieldName = column_name
| extend IPType = iff(ipv4_is_private(IPaddress) == true, "Private", "Public")
| where isnotempty(IPaddress)
| project Date, TimeGenerated, IPaddress, FieldName, IPType, DeviceVendor
| summarize count(), FirstTimeSeen = min(TimeGenerated), LastTimeSeen = min(TimeGenerated) by Date, IPaddress, FieldName, IPType, DeviceVendor
};
union csl_columnmatch("SourceIP")
    , csl_columnmatch("DestinationIP") 
    , csl_columnmatch("MaliciousIP")
    , csl_columnmatch("RemoteIP")
// Further summarization can be done per IPaddress to remove duplicates per day on larger timeframe for the first run
| summarize make_set(FieldName), make_set(DeviceVendor) by IPType, IPaddress

  3. Exécutez une recherche ou une corrélation ultérieure avec d’autres données pour terminer l’histoire d’attaque.

Générer des alertes sur les correspondances de veille des cybermenaces par rapport aux données réseau

Générez des alertes sur les correspondances de veille des cybermenaces par rapport aux données réseau bruyantes, à volume élevé et à faible valeur de sécurité.

Scénario : Vous devez créer une règle analytique pour les journaux de pare-feu afin de mettre en correspondance les noms de domaine du système qui ont été visités, en prenant comme référence une liste de noms de domaine de veille des cybermenaces.

La plupart des sources de données sont des journaux bruts bruyants et dont le volume est élevé, mais qui ont une valeur de sécurité inférieure, notamment les adresses IP, le trafic Pare-feu Azure, le trafic Fortigate, et ainsi de suite. Le volume total quotidien est d’environ 1 To.

Défi : La création de règles distinctes nécessite plusieurs applications logiques, nécessitant des frais de configuration et de maintenance supplémentaires.

Solution : Nous vous recommandons d’utiliser des règles récapitulatives pour effectuer les opérations suivantes :

  1. Résumez les journaux de pare-feu McAfee toutes les 10 minutes, en mettant à jour les données dans la même table personnalisée lors de chaque exécution. Les fonctions ASIM peuvent être utiles dans la requête récapitulative lors de l’interaction avec vos journaux McAfee.

  2. Créez une règle analytique pour déclencher une alerte chaque fois qu’un nom de domaine mentionné dans les données récapitulatives correspond à une entrée de la liste de veille des cybermenaces. Par exemple :

    //let timeRange = 5m;
//let httpstrim = "https://";
//let httptrim = "http://";
let timeRangeStart = now (-10m);
let timeRangeEnd = (timeRangeStart + 10m);
//Take visited domains from McAfee proxy
adx('https://adxfwlog01.northeurope.kusto.windows.net/nwlogs').MappedMcAfeeSyslog
| where timestamp between (timeRangeStart .. timeRangeEnd)
| where isnotempty(URL)
| extend URLDomain = parse_url(URL).Host
| extend URLDomain = iff(isempty(URLDomain),URL,URLDomain)
| extend URLDomain = extract(@"([0-9a-zA-Z-]{1,}\.[0-9a-zA-Z-]{2,3}\.[0-9a-zA-Z-]{2,3}|[0-9a-zA-Z-]{1,}\.[0-9a-zA-Z-]{2,10})$", 0, URLDomain)
| where isnotempty(URLDomain)
| summarize by URLDomain
//Match visited domains with TI DomainName list
| join kind=inner (ThreatIntelligenceIndicator
    | where isnotempty(DomainName)
    | where Active == true
    | where ExpirationDateTime > now()
    | summarize LatestIndicatorTime = arg_max(TimeGenerated, *) by DomainName
      ) on $left.URLDomain == $right.DomainName
| extend LogicApp = "SOC-McAfee-ADX-DstDomainAgainstThreatIntelligence"
| project LatestIndicatorTime, TI_Domain = DomainName, Description, ConfidenceScore, AdditionalInformation, LogicApp

Utiliser des règles récapitulatives avec des journaux auxiliaires (exemple de processus)

Cette procédure décrit un exemple de processus d’utilisation de règles récapitulatives avec des journaux auxiliaires, en utilisant une connexion personnalisée créée via un modèle ARM pour ingérer des données CEF provenant de Logstash.

  1. Configurez votre connecteur CEF personnalisé à partir de Logstash :

    1. Déployez le modèle ARM suivant sur votre espace de travail Microsoft Sentinel pour créer une table personnalisée avec des règles de collecte de données (DCR) et un point de terminaison de collecte de données (DCE) :

      Déployer dans Azure

    2. Notez les détails suivants dans la sortie du modèle ARM :

      • tenant_id
      • data_collection_endpoint
      • dcr_immutable_id
      • dcr_stream_name

    3. Créez une application Microsoft Entra et notez l’ID client et le secret de l’application. Pour plus d’informations, consultez Tutoriel : Envoyer des données aux journaux Azure Monitor avec l’API d’ingestion des journaux (Portail Azure).

    4. Utilisez notre exemple de script pour mettre à jour votre fichier de configuration Logstash. Les mises à jour configurent Logstash de façon à envoyer les journaux CEF à la table personnalisée créée par le modèle ARM, en transformant les données JSON au format DCR. Dans ce script, veillez à remplacer les valeurs d’espace réservé par vos propres valeurs pour la table personnalisée et l’application Microsoft Entra que vous avez créées.

  2. Vérifiez que vos données CEF circulent à partir de Logstash comme prévu. Par exemple, dans Microsoft Sentinel, accédez à la page Journaux et exécutez la requête suivante :

    CefAux_CL
| take 10

  3. Créez des règles récapitulatives qui agrègent vos données CEF. Par exemple :

    • Recherchez des données d’incident de compromission (IoC) : recherchez des IoC spécifiques en exécutant des requêtes récapitulatives agrégées pour faire apparaître les occurrences uniques, puis interrogez uniquement ces occurrences afin d’obtenir des résultats plus rapides. L’exemple suivant montre un exemple illustrant comment apporter un flux Source Ip unique avec d’autres métadonnées, qui peuvent ensuite être utilisées lors des recherches IoC :

      // Daily Network traffic trend Per Destination IP along with Data transfer stats 
// Frequency - Daily - Maintain 30 day or 60 Day History. 
  Custom_CommonSecurityLog 
  | extend Day = format_datetime(TimeGenerated, "yyyy-MM-dd") 
  | summarize Count= count(), DistinctSourceIps = dcount(SourceIP), NoofByesTransferred = sum(SentBytes), NoofBytesReceived = sum(ReceivedBytes)  
  by Day,DestinationIp, DeviceVendor

    • Interrogez une base de référence récapitulative afin de détecter les anomalies. Au lieu d’exécuter vos requêtes sur de longues périodes historiques, telles que 30 ou 60 jours, nous vous recommandons d’ingérer des données dans des journaux personnalisés, puis d’interroger uniquement les données de base de référence récapitulatives, comme pour les détections d’anomalies de série chronologique. Par exemple :

      // Time series data for Firewall traffic logs 
let starttime = 14d; 
let endtime = 1d; 
let timeframe = 1h; 
let TimeSeriesData =  
Custom_CommonSecurityLog 
  | where TimeGenerated between (startofday(ago(starttime))..startofday(ago(endtime))) 
  | where isnotempty(DestinationIP) and isnotempty(SourceIP) 
  | where ipv4_is_private(DestinationIP) == false 
  | project TimeGenerated, SentBytes, DeviceVendor 
  | make-series TotalBytesSent=sum(SentBytes) on TimeGenerated from startofday(ago(starttime)) to startofday(ago(endtime)) step timeframe by DeviceVendor

Contenu connexe