This article discusses how you can use the Stories Workbench to review Network stories for connectivity and performance issues on your network.
Cato Detection & Response (XDR) identifies network issues such as degradation, in addition to potential security threats. The advanced Network XDR engine detects different indications and metrics related to connectivity and performance, and generates stories that correlate data for issues concerning the network. For example, if a WAN link is intermittently experiencing high packet loss, the engine will create a single story with all the relevant data for the link.
The Stories Workbench page shows the details of each story to help you understand and analyze the issues. You can sort and filter the stories to find the most important incidents, and then drill-down on a story to further investigate the details to resolve the issue.
These are the indications of network connectivity and performance issues that are detected by the Network XDR engine to generate stories:
|
Indication |
Description |
Threshold for Generating a Story |
|---|---|---|
|
Site down |
The site disconnected from the Cato Cloud. |
All links down for 2.5 minutes |
|
Link is down |
One of the WAN links for a site disconnected from the Cato Cloud, the site is still connected. |
A link is down for 2.5 minutes or a link had 5 shorter disconnections in a 10 minute period |
|
BGP session disconnected |
A BGP session unexpectedly disconnected, and can impact app connectivity and the user experience. |
One BGP disconnection event |
|
LAN monitoring - host unreachable |
A monitored host behind a site isn’t responding to keep-alive packets from the PoP, and is considered unreachable. Requires a LAN Monitoring rule configured for the host. |
One LAN Monitoring Unreachable event |
|
Link quality SLA |
The link SLA quality threshold for a site is exceeded. This can impact user experience. The SLA thresholds are configured for Quality Health Rules. |
One Quality Health Rule event |
|
Socket HA Not Ready status |
There is an issue with the Socket High Availability (HA) configuration, and the status is Not Ready. |
If one of the following Socket HA Not Ready conditions occurs:
For more about these conditions, see What is Socket High Availability (HA) |
|
PoP reconnect to improve connectivity |
The site was forced to reconnect to the PoP to optimize performance. Reconnecting to the PoP can impact user experience. |
One reconnect event with this message: Performance issue detected, reconnected to a different service node in the Cato Cloud For more about event message fields, see Understanding Socket Connectivity Event Message Fields |
|
LAN port down |
One of the LAN ports disconnected |
The port is down for 2.5 minutes |
|
Alt. WAN Link down |
The Alt.WAN link for a site is disconnected from the Cato Cloud, the site is still connected. |
The link is down for 2.5 minutes |
This is an example use case for an admin identifying and resolving a network story with the Stories Workbench:
-
Filtered the Stories Workbench to show open network stories grouped by site
-
Identified a high criticality story for the New York site, with the indication Link is down
-
Opened the drill-down page for the story, reviewed the story data and discovered the site's WAN 01 link was disconnected from the Cato Cloud
-
Reviewed the relevant playbook to investigate and troubleshoot the issue
-
After checking the physical Socket at the New York site, discovered the WAN 01 link cable was faulty
-
Replaced the cable, confirmed the link was up and connected, and continued to monitor the story for possible recurrence of the issue
-
Story automatically closed after two hours with no recurrence
The Stories Workbench page shows a summary of the XDR Network and Security stories for your account.
|
Column |
Description |
|---|---|
|
ID |
Unique Cato ID for this story |
|
Status |
The statuses for a Network XDR story represent different stages throughout the story lifecycle, from the initial issue that triggered the story, through the final resolution. The Network XDR engine automatically updates the status when it detects the relevant changes in the network incident. These are the status types:
|
|
Created |
Date of the first traffic flow for the story |
|
Updated |
Date of the most recent traffic flow for the story |
|
Criticality |
|
|
Indication |
|
|
Source |
|
|
Occurrences |
The number of times the issue occurred, including recurrences after a temporary resolution. For example, if a link repeatedly disconnects and reconnects, each disconnection counts as an occurrence |
|
Engine Type |
The XDR engine that created the story. For Network stories, the engine is Network XDR |
To provide context when reviewing the stories, you can show the stories in groups defined by details including Sources, Indication, Status, and Type. For example, you can show together all of the stories related to a specific source site, or all of the Link quality SLA stories. This gives you a broader perspective when analyzing the stories, and can help you more quickly understand and resolve issues.
For Network XDR stories, Sources are sites in your network.
We recommend as a best practice to begin your analysis of Network stories by grouping by Sources.
Each group highlights the criticality levels for the stories in that group, including the number of high, medium, and low criticality stories.
There are three ways to filter the data in the Stories Workbench:
-
Select a preset filter
-
Automatically update the filter with a selected item
-
Manually configure the filter
You can select a preset filter to focus on either Network Operations or Security Operations stories. When you select a preset filter, the story columns most relevant for that type of story are shown by default.
As you hover over an item or field where a filter option is available, the button appears. Click the icon to show the filter options:
-
Add to Filter - Adds the item to the filter, and the Stories Workbench now only shows stories that include this item. For example, if you filter for a specific Criticality score, the page only shows stories with that Criticality.
-
Exclude from Filter - Updates the filter to exclude this item, and the Stories Workbench now only shows stories that do NOT include this item.
You can continue to add items to the filter, click again to update the filter and drill-down further.
The default time range for the Stories Workbench is the previous two days. You can select a different time range to show a longer or shorter time period. For more information, see Setting the Time Range Filter.
The maximum date range for the Stories Workbench is 90 days.
You can manually configure the story filter for greater granularity to analyze the stories. After you configure the filter, it is added to the stories filter bar and the page is automatically updated to show the stories that match the new filter.
To create a filter:
-
In the filter bar, click
.
-
Start typing or select the Field.
-
Select the Operator, which determines the relationship between the Field and the Value you are searching for.
-
Select the Value.
-
Click Add Filter. The filter is added to the filter bar and the Stories Workbench is updated to show stories based on the filters.
You can click on a story in the Stories Workbench to drill-down and investigate the details in a different page. This page contains a number of widgets that help you evaluate the potential issue identified by the Network XDR engine.
The Stories Workbench drill-down includes a link to a playbook that provides steps to investigate, troubleshoot, and resolve the issue. Each Network XDR story links to a playbook for the story's specific indication. For example, a playbook for stories with the indication Socket HA Not Ready status.
The Stories Workbench drill-down includes a tool that lets you create a natural language story description generated by AI, which provides rich context and helps you quickly assess the story. The story summary is generated dynamically to reflect the current state of the story. If the story updates with new information, you can regenerate the summary to reflect the changes.
For more about generating AI story summaries, see below.
-
The AI story summary is generated only on-demand by the admin
For robust data security during the transmission of story data to third-party AI services, Cato uses tokenization to ensure all sensitive data remains in the Cato XDR platform. This involves replacing sensitive information with unique identifiers, or "tokens," rendering the data meaningless to unauthorized entities. Sensitive data is never exposed to third-party services. This approach ensures the confidentiality of the story's details, aligning with our commitment to robust data privacy and security standards.
Note
Note: Due to the limitations of generative AI, the information provided in story summaries may occasionally contain inaccuracies.
These are the story drill-down widgets:
|
Item |
Name |
Description |
|---|---|---|
|
1 |
Story summary |
A summary of basic information about the story, including:
|
|
2 |
Shows a timeline of changes in the story status |
|
|
3 |
Story Details |
Basic information for analyzing the story, including a story description, when the story was created and updated with new related network incidents, and information about the site. |
|
4 |
Current Site Overview |
Information about the site in your network impacted by the story. The widget includes a link to view recent connection logs for the site, and drop-down menus with shortcuts to Site Configuration and Site Monitoring pages. This widget is the same as the Site Information Panel on the Topology page. |
|
5 |
Incident Timeline |
A list of the detected incidents for issues and resolutions in the story. For example, the Incident Timeline for a Link is down story includes these incidents:
These are the columns for the Incident Timeline:
|
The XDR Response Policy helps you monitor XDR stories by defining when email notifications for stories are sent to admins. You can create rules that define the story criteria for when notifications are sent, and can use mailing lists to configure which admins receive the notifications. For example, you can create a rule to send notifications for a Network XDR story with high Criticality, and define the mailing list to include a helpdesk email address to automatically open a support ticket.
For more about creating Response Policy rules, see Creating the Response Policy for XDR Stories
0 comments
Please sign in to leave a comment.