Mettre en sourdine les histoires XOps

Cet article explique comment créer une règle qui met en sourdine les histoires XOps afin qu'elles n'apparaissent pas sur le Stories Workbench.

Note

Note : XOps est la couche analytique unifiée de Cato pour la cybersécurité et les opérations, offrant des aperçus et une remédiation guidée. XOps a remplacé XDR, pour plus d'informations, voir FAQ XOps.

Overview

Les moteurs de corrélation XOps analysent les données de trafic pour trouver des correspondances avec des menaces potentielles ou une dégradation du réseau. Si une correspondance est identifiée, une histoire est générée dans le Stories Workbench pour vous aider à comprendre et analyser le problème. Si vous ne souhaitez pas qu'une histoire soit créée, vous pouvez configurer une règle de mise en sourdine des histoires. Cela réduit la génération d'histoires de faux positifs et vous aide à concentrer votre analyse sur de véritables menaces potentielles ou des problèmes de réseau. Les histoires peuvent être mises en sourdine pour une plage de temps spécifique ou illimitée.

Vous pouvez mettre en sourdine les histoires créées par ces moteurs :

Prévention des menaces
Chasse aux menaces
Opérations de site
Anomalie d'usage
Anomalie des événements

Pour qu'une histoire soit mise en sourdine, elle doit avoir une correspondance exacte ou contenir les prédicats insérés dans la règle Muet Histoires. Par exemple, si une règle contient 3 domaines mais que seulement 2 sont dans l'histoire, l'histoire est mise en sourdine. Si une règle contient 2 domaines et que l'histoire en contient 3, elle n'est pas mise en sourdine.

Remarque

Note : Les clients MDR peuvent créer et éditer des règles de mise en sourdine des histoires pour le moteur Opérations de site. Si vous souhaitez définir des histoires mises en sourdine pour d'autres moteurs, veuillez contacter mdr@catonetworks.com.

Muting Threat Prevention and Threat Hunting Stories

Vous pouvez définir le trafic d'une ressource de confiance qui est ensuite exclu d'une histoire. Par exemple, des histoires XOps sont générées pour la détection de tentatives de scan potentiellement malveillantes, mais la source du scan est connue comme étant des tests de pénétration bénignes. Après qu'une règle de mise en sourdine des histoires a été créée pour le trafic de test de pénétration, aucune autre histoire n'est générée pour cela.

Il y a deux façons d'ajouter des règles de mise en sourdine des histoires pour les histoires de prévention des menaces et de chasse aux menaces :

Créer une règle sur la page Detection & Response
Créer une règle à partir d'une histoire dans le Stories Workbench. Cette méthode est utile lorsque vous remarquez un trafic spécifique dans une histoire que vous savez être bénin.

Muting UEBA Usage Anomaly and Events Anomaly Stories

Il y a deux façons d'ajouter des règles de mise en sourdine des histoires pour les histoires d'anomalie d'utilisation et d'anomalie des événements :

Créer une règle sur la page Detection & Response
Créer une règle à partir d'une histoire dans le Stories Workbench. Cette méthode est utile lorsque vous remarquez un trafic spécifique dans une histoire que vous savez être bénin.

Les sections suivantes décrivent les paramètres utiles disponibles pour les règles de mise en sourdine des histoires d'anomalie d'utilisation et d'anomalie des événements.

Understanding Mute Stories Settings for Usage Anomaly Stories

Le moteur d'anomalies d'utilisation XOps identifie des anomalies liées à une utilisation inhabituelle dans les applications et génère une histoire lorsqu'une anomalie est détectée. La politique de mise en sourdine des histoires vous permet de configurer une règle pour une histoire d'anomalie de l'utilisation en spécifiant des applications ou des catégories d'applications à exclure par les moteurs XOps. Par exemple, si vous savez qu'un utilisateur spécifique télécharge des quantités inhabituelles de données sur OneDrive dans le cadre de ses exigences de travail, créez une règle configurée avec l'«Utilisateur» spécifique comme «Source» et «OneDrive» comme «Application».

Il est possible qu'une histoire d'anomalie d'usage implique plus d'une application. Dans ce cas, l'«Application» configurée se réfère à l'application principale dans l'histoire. Par exemple, si vous configurez l'Application comme OneDrive, cela signifie que si l'application principale dans l'histoire d'anomalie d'utilisation est OneDrive, le moteur XOps ne générera pas l'histoire. Cependant, si l'application principale est une application différente, comme Dropbox, et que OneDrive a le deuxième plus grand usage, alors l'histoire sera toujours générée.

Understanding Mute Stories Settings for Events Anomaly Stories

Le moteur d'anomalies d'événements XOps détecte des anomalies impliquant une entité sur le réseau qui déclenche un nombre inhabituel d'événements de cybersécurité et génère une histoire lorsqu'une anomalie est détectée. La politique de mise en sourdine des histoires vous permet de configurer une règle pour une histoire d'anomalie d'événements en spécifiant des types d'événements à exclure par les moteurs XOps. Vous pouvez ensuite préciser davantage pour exclure uniquement les événements générés par des règles particulières ou des menaces IPS.

Par exemple, si un utilisateur génère un nombre inhabituellement grand d'événements de pare-feu WAN en effectuant une activité bénigne connue, créez une règle avec l'«Utilisateur» configuré comme «Source» et configurez la «Métrique d'anomalie des événements» comme le «Type d'événement» de «Pare-feu WAN». Ensuite, précisez la règle dans la base des règles du pare-feu WAN.

Mettre en sourdine les histoires Opérations de site

Vous pouvez mettre en sourdine les histoires générées par des problèmes de réseau spécifiques. Par exemple, si vous savez qu'un ISP local a une panne planifiée, vous pouvez mettre en sourdine les histoires générées par l'indication de site fermé pour la période de la panne.

Les histoires sont générées mais sont filtrées hors du Stories Workbench.

Vous pouvez identifier si une histoire a été mise en sourdine dans la colonne «Silencieux» de la chronologie des incidents d'une histoire.

Vous pouvez ajouter des règles de mise en sourdine pour les histoires Opérations de site en créant une règle sur la page Detection & Response.

Prerequisites

Une licence XOps est requise :

Items in a Detection & Response Mute Stories Rule

The following table explains the items that you can use to define the settings for a Detection & Response Mute Stories rule. When you configure multiple objects in a setting, there is an OR relationship between them. For example, if there is a rule configured with sources including a Site and a User, the rule is applied when the traffic matches either the Site or the User.

Item	Description
Producer	The Detection & Response engine or engines the rule applies to. Pour en savoir plus sur ces moteurs et les types d'histoires qu'ils détectent, voir Utilisation du catalogue d'indications
Indication ID	The identifier for the indication used by the Detection & Response engines. Each Indication ID is associated with a Detection & Response engine query that identifies specific traffic parameters. If you define an Indication ID, the rule only excludes traffic from stories generated by the specific engine query associated with that Indication ID. If no Indication ID is defined, the traffic is excluded from all engine queries that match the rule settings. Pour en savoir plus sur les indications, voir Utilisation du catalogue d'indications.
Direction (Threat Prevention, Threat Hunting, Usage Anomaly, and Events Anomaly stories)	Define the direction of the traffic flow that the rule applies to. Directions include: Inbound - Traffic to your network originating at an external source Outbound - Traffic from your network to an external source WANbound - Traffic from your network to another site on your network All of the above
Time Frame	Select the time frame when the rule applies, or select Unlimited for the rule to continue to apply without expiration. When an expiration date is set: For Threat Prevention and Threat Hunting stories the rule expires at the beginning of that date, in the time zone configured in the user profile settings in the Cato Management Application. Pour les histoires Opérations de site, vous pouvez sélectionner le fuseau horaire auquel le cadre temporel s'applique. Setting an expiration date is a recommended best practice for maintaining an effective security posture.
Source	Source of the traffic for this rule. You can select one or more of the following Source types: Threat Prevention and Threat Hunting stories Site IP IP Range User Any Opérations de site Site Network Interface (LAN link) WAN Link Site Connection Type Any
Device (Threat Prevention, Threat Hunting, Usage Anomaly, and Events Anomaly stories)	The type of device the rule applies to, defined by operating system.
Destination (Histoires de Prévention des menaces, de Chasse aux menaces, d'Anomalies d'utilisation et d'Anomalies d'événements)	Destination of the traffic for this rule. You can select one or more of the following Destination types: IP URL Domain FQDN Application Application Category (for Usage Anomaly stories only) Any Pour les définitions de ces objets, voir Référence pour les objets de règle
Métrique d'Anomalie d'Événements (Histoires d'anomalies d'événements)	Sélectionnez le type d'événement à désactiver. Après avoir sélectionné le type d'événement, vous pouvez spécifier un nom de règle ou un nom de menace. Vous pouvez sélectionner un des types d'événements suivants : Firewall WAN Firewall Internet IPS Anti-Malware NG Anti-Malware N'importe lequel

En plus des paramètres ci-dessus, les informations suivantes sont affichées pour chaque règle de Mute Stories:

Auteur - Le nom d'utilisateur de l'utilisateur qui a créé la règle.
Créé le - Date de création de la règle.

Showing the Detection & Response Mute Stories Rulebase

To show the Detection & Response Mute Stories rulebase:

Dans le menu de navigation, cliquez sur Accueil > Politique de détection & réponse.

Création d'une règle de Mute Stories dans la page de Détection & Réponse

Add a new Mute Stories rule and configure the settings that define the traffic to be disregarded by the Detection & Response engines.

To create a Detection & Response Mute Stories rule:

Dans le menu de navigation, cliquez sur Accueil > Politique de détection & réponse.
Sélectionnez l'onglet Mute Stories.
Cliquez sur Nouveau. Le panneau Ajouter à Mute Stories s'ouvre.
Configurez les paramètres de la règle comme décrit ci-dessus.
Cliquez sur Sauvegarder. La règle est ajoutée à la base de règles de Mute Stories.

Création d'une règle de Mute Stories à partir d'une histoire

Visualisez l'histoire détaillée dans le banc de travail des histoires et utilisez le panneau Actions de l'histoire pour créer une règle de Mute Stories.

Les paramètres de règle suivants sont remplis automatiquement en fonction des données de l'histoire :

Direction
Source
- Si l'histoire contient plusieurs types de données pour la source, ils sont tous ajoutés dans le paramètre Source. Par exemple, si l'histoire a identifié une IP et un Site pour une source, alors aussi bien IP et Site sont remplis automatiquement dans la section Source pour la règle.
Destination - Rempli automatiquement en fonction des Cibles de l'histoire
- Si l'histoire a identifié plusieurs Cibles, elles sont toutes ajoutées dans le paramètre Destination

Pour créer une règle de Mute Stories à partir d'une histoire :

Dans le menu de navigation, cliquez sur Accueil > Banc de Travail des Histoires.
Cliquez sur l'histoire pour ouvrir la page détaillée de l'histoire.
Cliquez sur pour ouvrir le panneau Actions de l'histoire.
Cliquez sur Ajouter à Nouvelles Mute Stories. Le panneau Ajouter à Nouvelle Règle de Mute Stories s'ouvre.
Configurez les paramètres de la règle comme décrit ci-dessus.
Cliquez sur Sauvegarder. La règle est ajoutée à la base de règles de Mute Stories.
Pour afficher la base de règles Muet Histoires Détection & Réponse, dans le menu de navigation, cliquez sur Accueil > Politique de détection & réponse.