Cisco Stealthwatch Learning Network License Configuration Guide

Anomaly Detail Overview

The anomaly detail view contains in-depth information about an anomaly, and context to help you understand it. The information includes information about the anomaly, and visual graphs with details about the anomalous behavior.

You can take several actions from the anomaly detail view, including:

downloading packet data
viewing the details for the previous or next anomaly in the inbox
assigning relevance feedback for the anomaly
configuring a mitigation based on this anomaly

Summary Information

The summary information displays much of the same information as the anomaly inbox. This allows you to review pertinent anomaly information at a glance. The summary information also displays the first time a user accessed the in-depth anomaly information.

In the summary information pane, you can add a comment to the anomaly, assign relevance feedback, as well as navigate to the previous or next anomaly's details.

Summary Information Fields
Viewing Other Anomaly Details

Reviewing and Adding Comments

Summary Information Fields

Field	Description
Description	The reason the system considered this traffic anomalous, the anomalous traffic directionality, and the target host.
Id	The anomaly's ID number.
Agent	The agent that reported the anomaly.
Date, time	The date and time the anomaly started.
Severity	The system's rating for the possibility of negative impact upon your network.
Seen	The date and time a user first viewed this anomaly's details.

Viewing Other Anomaly Details

You have the following options:

To view the next anomaly's details, click the next icon ().
To view the previous anomaly's details, click the previous icon ().

Anomaly Whitelist Rules

Anomaly whitelist rules act as an inbox filter, hiding anomalies that match the rule. You can whitelist based on anomalies involving hosts you know to be safe. This reduces the false positives that the system displays.

When you configure a whitelist rule, the system populates the rule with multiple characteristics, including:

the detected cluster, target host IP address, and application group
the flow direction
whether or not the conversation involves an external host
detected anomalous features
agents that detected the anomaly

This narrowly-defined rule matches very specific traffic. You can remove characteristics to expand the scope of the rule.

Note

If you remove too many characteristics and create a broad whitelist rule, the system may suppress relevant anomalies in addition to irrelevant anomalies. For example, if you remove the specified cluster, the rule defaults to matching any cluster. If you then remove IP address and application group, the rule suppresses all anomalies. If you create a broad whitelist rule, you may also create overlap with other whitelist rules. Plan your whitelist rules carefully, to prevent rule overlap and only suppress anomalies you want to suppress.

A whitelist rule does not suppress any matching anomalies reported prior to rule creation, nor does it suppress the anomaly you used to create the rule. It does suppress every matching anomaly detected in the future, and remains in effect until you remove the rule.

You can view all configured whitelist rules from the whitelist rule table in the anomaly inbox.

Whitelist Rule Fields
Whitelist Rule Validation
Whitelists, Relevance Feedback, and Mitigations
Creating a Whitelist Rule

Whitelist Rule Fields

Table 1 Whitelist Rule Fields
Column	Description
Cluster	the cluster containing the target host
IP address	the target host IP address
App. group	the application group over which the target host and other host transferred traffic
Bidirectional conversation	whether the anomalous conversation is unidirectional or bidirectional
With external host	whether the anomalous conversation involves a host external to the branch
Features	the detected anomalous features
Agents	the agents that detected the anomaly

Whitelist Rule Validation

When you create a whitelist rule, the system validates it using the following criteria:

You must define at least one Cluster, IP address, or App. group.
You do not have to define With external host, Bidirectional conversation, Features, or Agents.

When the system evaluates the whitelist rule, it matches traffic that matches all defined criteria. However, if you define multiple Features, multiple Agents, or multiple Features and Agents, the rule only has to match one of the defined features or one agent associated with an anomaly to filter the anomaly from the inbox.

Whitelists, Relevance Feedback, and Mitigations

Whitelist rules do not directly affect relevance feedback or mitigations. While relevance feedback trains the system to report more relevant anomalies, and mitigations take action on traffic directly, whitelist rules only suppress anomalies from appearing in the anomaly inbox.

If you create a whitelist rule, the system does not interpret that as relevance feedback. You can assign relevant feedback () or irrelevant feedback () to an anomaly, then subsequently configure a whitelist rule based on that anomaly. However, you can create a situation where you train the system to report a certain type of anomaly, then whitelist that type of anomaly. The system continues to report this type of anomaly, but the whitelist rule suppresses it from the anomaly inbox. This can severely impact system functionality.

While whitelist rules suppress anomalies from the controller anomaly inbox, agents apply mitigations to traffic. Mitigations always take effect before whitelist rules. If you create a whitelist rule and a mitigation, and both contain criteria that match the same traffic, the whitelist rule never triggers because the agent always applies the mitigation first.

For more information on using whitelist rules and relevance feedback, see Relevance Feedback and Whitelist Rule Use.

Creating a Whitelist Rule

Step 1	Select Inbox.
Step 2	Select an anomaly to view the anomaly's details.
Step 3	Click Whitelist.
Step 4	If you want to remove criteria from the whitelist rule, click the delete icon ().
Step 5	Click Submit Query to create the whitelist rule.

Packet Buffer Capture

When an agent detects an anomaly, it creates packet capture data (PCAP) files relevant to the anomaly. The packet buffer capture feature allows you to download these PCAP files from the controller web UI for further inspection.

Upon anomaly detection, an agent creates PCAP files of the packets each source or destination IP address involved in an anomalous flow transmitted during the anomaly time frame. Each PCAP covers up to 1 minute's worth of traffic, and is up to 10 MB in size, uncompressed.

Note

If the disk has less than 15 MB of free space, the agent may create PCAPs smaller than 10 MB in size.

Based on the anomaly length of time, the agent may create multiple PCAP files to capture relevant information, for up to the first five minutes of the anomaly.

The agent then compresses all PCAP files related to an anomaly into an archive. On a regular basis, the agent prunes the oldest stored PCAP archive files if agent disk storage runs low.

Users logged into the controller web UI can download an anomaly's PCAP files. The controller web UI retrieves the PCAP archive file from the agent and directs the agent to delete the archive file for storage considerations. The controller web UI then provides an HTTP URL from which the user can download the PCAP archive file.

Note

Disable browser pop-up blockers if you want to download PCAP files.

Downloading PCAPs

Downloading PCAPs

Step 1	Select Inbox.
Step 2	Click an anomaly's description.
Step 3	Click Get PCAP files. Wait for the controller to retrieve the PCAP from the agent.
Step 4	Click Download to download the PCAP file.

Anomaly Facts Pane

The Facts pane in the anomaly detail view provides the same information as the expanded description in the Inbox. These facts provide additional context around the anomaly, including information about the anomaly traffic, and hosts and clusters involved.

Anomaly Facts Displayed
Application Groups

Related References

Anomaly Facts Displayed

For the target host, and the other host communicating with the target host, the anomaly facts include the:

host IP address, or hostname if available
geolocation information, if available
host's cluster, and number of additional hosts in the cluster
number of anomalies the host was previously involved with

For the target host, the anomaly facts include the number of communications with other hosts in other clusters.

For the anomalous communication between the hosts, the anomaly facts include the:

directionality of the communication
applications used
most common frequency of this traffic type that the system detects

Application Groups

Application Group	Description	Examples
`auth`	Applications used for user authentication and authorization	Active Directory, LDAP, RADIUS
`cloud`	Applications that store information and files in a cloud service	Hotmail, Dropbox, Google Docs
`collab`	Applications that enable collaborative interaction between users	ICQ, Skype, Gtalk
`darknet`	Applications that provide access to a darknet	Tor
`database`	Applications that provide access to and interaction with databases	SQL Server, MySQL, Sybase
`dns`	Applications related to the Domain Name System (DNS)	DNS
`file-xfer`	File transfer applications	FTP, NFS, Gopher
`game`	Game and gaming-related applications	Call of Duty, Maple Story, Steam
`icmp`	Internet Control Message Protocol (ICMP)-related applications	ICMP
`infra`	Applications used to test and configure network infrastructure	Ping, DHCP, Endpoint Mapper
`media`	Media streaming applications	Netflix, Hulu, Pandora
`network`	Protocols and applications used for routing internet traffic	BPG, OSPF, IGRP
`ntp`	Network Time Protocol (NTP)-related applications	NTP
`office`	Applications used for office work, such as email	SMTP, IMAP, NMAP
`other`	Applications that do not belong to other defined application groups	remotefs, IIOP, VPP
`other-ip-proto`	Internet Protocol-related applications that do not belong to other defined application groups	Sprite Remote Procedure Call, Message Posting Protocol, Storage Management Services Protocol
`p2p`	Peer-to-peer file sharing applications	Gnutella, BitTorrent, eDonkey
`print`	Printing-related applications	Network Printing Protocol, Internet Printing Protocol, Printer
`proxy`	Proxy server applications	Socket Secure (SOCKS)
`remote`	Applications used to access hosts remotely	Citrix, X Window System, pcAnywhere
`shell`	Applications used to access operating systems, including CLIs	Telnet, SSH, Secure Telnet
`social`	Social networking applications	Facebook, LinkedIn, Twitter
`syslog`	Syslog-related applications	syslog
`tunneling`	Applications used to create a tunnel and transmit traffic across it	Hamachi, ISAKMP, SCTP
`unknown`	Unknown applications	Unknown
`unknown-tcp`	Unknown TCP applications	unknown-tcp
`unknown-udp`	Unknown UDP applications	unknown-udp
`windows`	Microsoft Windows-related applications	Windows Update, Common Internet File System (CIFS), NetBIOS
`www`	Websites on the World Wide Web	Rotten Tomatoes, Reuters, Stack Overflow

Conversations

The Conversations pane contains all traffic related to this anomaly, including:

anomalous flows involving the target host
non-anomalous flows involving the target host within the same time frame, provided for context

Conversations may be unidirectional or bidirectional, based on the traffic. The system groups conversations at the edge-level, by source, destination, and application group. The system also displays aggregate network statistics for each conversation. Traffic from source to destination is labeled with a right arrow (), and from destination to source is labeled with a left arrow ().

If one of the anomalous features involves a DNS request having a domain that is too long, you can view all DNS requests associated with the anomalous conversation.

You can expand each edge-level group to view individual conversations and flows. For each conversation or flow in the pane, you can view detailed connection information. You can also view a graphical timeline, showing when and how hosts transferred packets.

Conversation Fields
Filtering Conversations

Conversation Fields

Table 2 Edge-level Conversation Fields
Field	Description
App. group	The application group that contains the application used in the conversation.
Source	The source host IP address or hostname, and if available, the source cluster and geolocation information.
Destination	The destination host IP address or hostname, and if available, the source cluster and geolocation information.
(Show Details)	Click this to show the Bytes (sum), Packets (sum), and Bitrate (avg) fields.
Bytes (sum)	The total number of bytes transmitted in all related conversations and flows over this application group.
Packets (sum)	The total number of packets transmitted in all related conversations and flows over this application group.
Bitrate (avg)	The average speed for all related conversations and flows in bits per second (bps), kilobits per second (Kbps), or megabits per second (Mbps).
Anomalous Features	The anomalous characteristics this edge displays.

Table 3 Individual Conversation and Flow Fields
Field	Description
Protocol & Application	The protocol and application used in the conversation or flow.
Source port	The source host port.
Destination port	The destination host port.
Bytes	The number of bytes transmitted in this conversation or flow.
Packets	The number of packets transmitted in this conversation or flow.
Bitrate	The average connection speed for this conversation or flow in bps, Kbps, or Mbps.

Host Detail Panes
Cluster Detail Panes

Host Detail Panes

In a conversation, you can click on a host's IP address or hostname to view more information. This information includes the cluster the host belongs to, and if available, geolocation, user identity, and threat intelligence. If the system previously detected an anomaly, and it involved this host, the pane displays a count of these anomalies, and if available, additional information on these anomalies. You can click a cluster name to view details about that cluster.

Host Detail Fields

Host Detail Fields

Table 4 Host Detail Pane Fields
Field	Description
Cluster	The cluster to which the selected host belongs.
Member since	The date and time the system added the selected host to this cluster.
Country	If available, the country where this host is located.
State	If available, the state where this host is located.
City	If available, the city where this host is located.
Threat intel	The host's reputation, based on Talos analysis.
ISE	User identity information collected from the Identity Services Engine (ISE) deployment, including user name, device type, MAC address, department, and role.

Cluster Detail Panes

In a conversation, you can click on a cluster's name to view more information, including:

the cluster display name and internal name
a bar chart that shows the proportion of application traffic that hosts transfer in the cluster
the total number of hosts
additional information for up to 50 hosts within the cluster, including geolocation, hostname, and threat flag

You can click a host name to view details about that host.

You can also download a comma-separated value (CSV) file which contains up to 50 hosts in the cluster. The downloaded CSV file contains Talos threat intelligence and ISE identify information associated with the host IP addresses.

Cluster Names
Cluster Detail Fields
Downloading Hosts in a CSV File

Cluster Names

Cluster names describe the attributes common to all hosts within the cluster. Each agent creates clusters based on these common attributes. Depending on the deployment, number of detected hosts, and shared attributes, the cluster names may be general, containing whether a host is Internal or External to the branch (directionality relative to the branch), and whether the host is newly detected. The name may also be more specific, containing branch directionality, geolocation information, application groups common among the cluster's hosts, subnet, and other information. Some clusters may also contain only hosts that fall within certain IANA-defined IP ranges, or untracked hosts.

Note

Branch directionality depends on the Network Element Internal or External interface direction configuration.

For cluster names, the agent assigns the branch directionality, and whether the cluster contains new or known hosts. It may also include one or more common application groups, as well as either the /24 subnet, or country and region location, but not both.

Cluster names follow the pattern [new]{internal | external}[<application-groups>][subnet <subnet> | <country>, <region>], seen in the following examples:

new internal http clients - new hosts within the branch, using HTTP clients
new external dns servers in Turkey - new hosts external to the branch, identified as DNS servers, geolocation information identifies the host in Turkey
new internal email servers and ssh servers in subnet 203.0.113.0 - new hosts within the branch, identified as email servers and ssh servers, part of the 203.0.113.0/24 subnet
external p2p clients - known hosts external to the branch, using peer-to-peer clients
internal mixed hosts in subnet 203.0.113.0 - known hosts within the branch, using a variety of applications, part of the 203.0.113.0/24 subnet
external ntp hosts in Taiwan - known hosts external to the branch, using NTP, geolocation information identifies the host in Taiwan

The cluster name may relate to an IANA-defined IP range, such as linklocal or mcast (multicast). In these clusters, the IP range is the only common attribute the agent uses to assign hosts to the cluster.

The cluster name may also be untracked, in which case the agent is not tracking hosts at the same level of granularity as with other clusters. There are three reasons the agent assigns a host to the untracked cluster:

the host is detected over an interface is not configured as Internal or External, and the agent cannot determine the host's branch directionality
the agent has not detected traffic transmitted from the host
the agent has observed too many hosts within too small a period of time and cannot track all hosts at the same level of detail

As the agent assigns more hosts to a cluster based on shared attributes, it may subdivide the cluster. For example, if a cluster named external dns servers, based on branch directionality and application group, grows too large, the system may subdivide by country: external dns servers in United States, external dns servers in France, and external dns servers in China.

Cluster Name Attributes

Cluster Name Attributes

Table 5 Cluster Name Attributes

Attribute Name

Description

new

hosts are recently detected, and the agent cannot yet identify the applications most often used by the hosts

internal

hosts are internal to the branch

external

hosts are external to the branch

subnet <subnet>

hosts belong to the /24 subnet listed in <subnet>

<country>

hosts are located in <country>, based on the geolocation database

<region>

hosts are located in <region> within <country>, based on the geolocation database

<application-groups>

hosts send and receive traffic most often over applications within these application groups, or mixed if the hosts send and receive traffic over a variety of applications and application groups, without a majority of traffic sent over a specific application

Note

A cluster name may contain more than one application group.

<IANA-special-range>

hosts have an IP address within a special range, as defined by IANA:

reserved - IP addresses reserved for benchmarking, loopback, limited broadcast, IETF protocol assignments, and documentation
linklocal - link local IP addresses
mcast - multicast IP addresses
external - IP addresses reserved for shared address spaces, 6to4 relay anycast, AS112, and automatic multicast tunneling

See http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml and http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml for more information.

untracked

hosts are not tracked by the agent, because:

the host is detected over an interface is not configured as Internal or External, and the agent cannot determine the host's branch directionality
the agent has not detected traffic transmitted from the host
the agent has observed too many hosts within too small a period of time and cannot track all hosts

Cluster Detail Fields

Table 6 Cluster Detail Pane Fields
Field	Description
Country	The geolocation flag icon representing the country in which the host is located.
Host	The host IP address, or hostname if available.
Threat Flag	Whether threat intelligence from Talos identified this host as malicious.

Downloading Hosts in a CSV File

Step 1	From an agent dashboard or an anomaly's details, click a cluster name.
Step 2	Click Download as CSV.

Filtering Conversations

Step 1	Select Inbox, then click an anomaly's Description.
Step 2	If it is collapsed, click the expand arrow () to expand the Filters pane.
Step 3	Check the filter check boxes corresponding to the criteria you want to filter on.

Anomalous Features Graph

The Anomalous Features graph combines a radar chart with a heat map to show how anomalous traffic compares to baseline traffic. The graph combines all anomalous features detected for all related anomalous conversations

For each anomalous feature type, the graph plots an axis at one of three levels:

cluster-level - all conversations from a source cluster of an application group
edge-level - all conversations of an edge and application group
graph-level - all conversations of an application group

Along each axis, the heat map shows the frequency for that traffic type. The darker the color, the more frequent that quantity of traffic. The system plots the anomalous traffic as a dot along the axis. The farther the system plots the dot from the baseline traffic, the less common the traffic is. You can hover over the anomalous traffic dot to view more information about it, or you can view the descriptions of each anomalous feature.

If the timeline displays the anomaly's duration in multiple sections, you can navigate through the timeline to update the anomalous features graph. You can then see the anomaly's progression over time.

Anomalous Feature Types

Anomalous Feature Types

Table 7 Anomalous Feature Types
Anomalous Feature	Description
DNS request subpart length	In the DNS lookup for an anomalous conversation, one of the domains within the domain name is longer than what the agent learned about domain names.
Number of bytes	The number of bytes in an anomalous conversation is smaller or larger than what the agent learned about conversations.
Number of bytes per packet	The number of bytes per packet in an anomalous conversation is smaller or larger than what the agent learned about conversations.
Number of flows	The number of flows in an anomalous conversation is smaller or larger than what the agent learned about conversations.
Number of packets	The number of packets in an anomalous conversation is smaller or larger than what the agent learned about conversations.
Number of packets per flow	The number of packets per flow in an anomalous conversation is smaller or larger than what the agent learned about conversations.
Total flow duration	The flow duration is longer or shorter than what the agent learned about flows.
Unexpected created edge	The anomalous edge involves an application not previously detected between the clusters by the agent.
Unusual time of day	The anomalous edge saw traffic at a time of day either rarely seen or not seen at all, according to what the agent has learned about the edge.

Anomaly Graph

The anomaly graph displays the anomalous and related traffic in a graphical format. Source clusters are displayed to the left, and destination clusters to the right. Application groups are listed in the middle. A line connecting a source and destination cluster represents an edge; anomalous edges are highlighted. If you hover your pointer over a cluster, the graph updates to display only those edges where the cluster is a source or destination.

Mitigation from an Anomaly

You can configure mitigations from an anomaly. If you do this, the system prepopulates two mitigation policies. One mitigation policy applies to traffic to the target host detected in the anomaly. The other policy applies to traffic from the target host. You can apply these policies with the prepopulated values, or you can modify them before applying.

Configuring a Mitigation from an Anomaly

Configuring a Mitigation from an Anomaly

Step 1	Select Inbox.
Step 2	Click an anomaly's description.
Step 3	Click Mitigate this anomaly in the Mitigate pane. The system prepopulates two mitigation policies with information matching the anomaly.
Step 4	If you only want to apply a mitigation policy in one direction: uncheck the Mitigate forward check box to only mitigate traffic incoming to the target host. uncheck the Mitigate backward check box to only mitigate traffic outgoing from the target host.
Step 5	If you want to change the anomaly duration, update the Duration.
Step 6	Click Create mitigation policies.

Book Title

Chapter Title

Results

Chapter: Anomaly Detail

Anomaly Detail

Anomaly Detail Overview