Muting Detection & Response (XDR) Stories

This article discusses how to create a rule that mutes Detection & Response (XDR) stories so that they do not appear on the Stories Workbench.

Overview

The Detection & Response correlation engines analyze traffic data to find matches for potential threats or network degradation. If a match is identified, a story is generated in the Stories Workbench to help you understand and analyze the issue. If you do not want a story to be created you can configure a Mute Stories rule. This reduces the generation of false positive stories and helps you focus your analysis on actual potential threats or network issues. Stories can be muted for a specific or unlimited time range

You can mute stories created by these engines:

  • Threat Prevention

  • Threat Hunting

  • Network XDR

  • Usage Anomaly

  • Events Anomaly​​

For a story to be muted, it must have an exact match or contain the predicates inserted on the Mute Stories rule. For example, if a rule contains 3 domains but only 2 are in the story, the story is muted. If a rule contains 2 domains and the story contains 3, it is not muted.

Note

Note: For MDR customers, please contact to define Mute Stories rules for your account.

Muting Threat Prevention and Threat Hunting Stories

You can define traffic from a trusted resource which is then excluded from a story. For example, XDR stories are generated for detection of potential scanning attempts, but the source of the scanning is known-benign penetration testing. After a Mute Stories rule is created for the penetration testing traffic, no further stories are generated for it.

There are two ways to add Mute Stories rules for Threat Prevention and Threat Hunting stories:

  • Create a rule in the Detection & Response page

  • Create a rule from a story in the Stories Workbench. This method is helpful when you notice specific traffic in a story that you know is benign

Muting UEBA Usage Anomaly and Events Anomaly Stories

There are two ways to add Mute Stories rules for Usage Anomaly and Events Anomaly stories:

  • Create a rule in the Detection & Response page

  • Create a rule from a story in the Stories Workbench. This method is helpful when you notice specific traffic in a story that you know is benign

The following sections describe useful settings that are available for Usage Anomaly and Events Anomaly Mute Stories rules.

Understanding Mute Stories Settings for Usage Anomaly Stories

The XDR Usage Anomaly engine Identifies anomalies related to unusual usage in applications, and generates a story when an anomaly is detected. The Mute Stories policy lets you configure a rule for a Usage Anomaly story by specifying applications or application categories for the XDR engines to exclude. For example, if you know that a specific user uploads unusual amounts of data on OneDrive as part of their work requirements, create a rule configured with the specific User as the Source and OneDrive as the Application.

It is possible for a Usage Anomaly story to involve more than one application. In such a case, the configured Application refers to the top application in the story. For example, if you configure the Application as OneDrive, this means that if the top application in the Usage Anomaly story is OneDrive, the XDR engine won't generate the story. However, if the top application is a different application, such as Dropbox, and OneDrive has the second-highest usage, then the story will still be generated.

Understanding Mute Stories Settings for Events Anomaly Stories

The XDR Events Anomaly engine detects anomalies that involve an entity on the network triggering an unusual number of security events, and generates a story when an anomaly is detected. The Mute Stories policy lets you configure a rule for an Events Anomaly story by specifying event types for the XDR engines to exclude. You can then further specify to exclude only the events generated by particular rules or IPS threats.

For example, if a user generates an unusually large number of WAN Firewall events when performing known-benign activity, create a rule with the User configured as the Source and configure the Events Anomaly Metric as the Event Type of WAN Firewall. Then specify the rule within the WAN Firewall rulebase.

Muting Network Stories

You can mute stories generated by specific network issues. For example, if you know a local ISP has a planned outage, you can mute stories generated by the Site down indication for the period of the outage.

Stories are generated, but are filtered out of the Stories Workbench.

You can identify whether a story has been muted in the Muted column in the Incident Timeline of a story.

Muted.png

You can add Mute Stories rules for Network stories by creating a rule in the Detection & Response page.

Prerequisites

The following story types require an XDR Pro or MDR license:

  • Threat Hunting

  • Usage Anomaly

  • Events Anomaly

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. For more about these engines and the types of stories they detect, see Using the Indications Catalog

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.

For more about Indications, see Using the Indications Catalog.

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.

  • For Network stories, you can select the time zone that the time frame applies to.

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

  • Network stories

    • 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

(Threat Prevention, Threat Hunting, Usage Anomaly, and Events Anomaly stories)

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

Events Anomaly Metric

(Events Anomaly stories)

Select the type of event to be muted. After you select the event type, you can specify a rule name or threat name.

You can select one of the following event types:

  • WAN Firewall

  • Internet Firewall

  • IPS

  • Anti-Malware

  • NG Anti-Malware

  • Any

In addition to the above settings, the following information is shown for each Mute Stories rule:

  • Author - The user name of the user who created the rule.

  • Created At - Date the rule was created.

Showing the Detection & Response Mute Stories Rulebase

To show the Detection & Response Mute Stories rulebase:

  1. From the navigation menu, click Home > Detection & Response Policy.

Detection_Response_Allow_List.png

Creating a Mute Stories Rule in the Detection & Response Page

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

Detection_Response_Allow_List_Add_to_Allowlist.png

To create a Detection & Response Mute Stories rule:

  1. From the navigation menu, click Home > Detection & Response Policy.

  2. Select the Mute Stories tab.

  3. Click New. The Add to Mute Stories panel opens.

  4. Configure the settings for the rule as described above.

  5. Click Save. The rule is added to the Mute Stories rulebase.

Creating a Mute Stories Rule from a Story

Note

Note: This is only support for Threat Prevention and Threat Hunting Stories

View the story drill-down in the Stories Workbench and use the Story Actions panel to create a Mute Stories rule.

The following rule settings are autofilled based on data from the story:

  • Direction

  • Source

    • If the story contains multiple types of data for the source, they are all added in the Source setting. For example, if the story identified an IP and Site for a source, then both an IP and Site are autofilled in the Source section for the rule.

  • Destination - Autofilled based on the story Targets

    • If the story identified multiple Targets, they are all added in the Destination setting

To create a Mute Stories rule from a story:

  1. From the navigation menu, click Home > Stories Workbench.

  2. Click the story to open the drill-down page for the story.

  3. Click More_icon.png to open the Story Actions panel.

  4. Click Add to New Mute Stories. The Add to New Mute Stories Rule panel opens.

    Detection_Response_Allow_List_from_Story.png

  5. Configure the settings for the rule as described above.

  6. Click Save. The rule is added to the Mute Stories rulebase.

  7. To show the Detection & Response Mute Stories rulebase, from the navigation menu click Home > Detection & Response Policy.

Was this article helpful?

0 out of 0 found this helpful

0 comments