Cisco Stealthwatch Learning Network License Configuration Guide
- Updated:
- July 11, 2016
Chapter: Anomaly Detail
Anomaly Detail
The following describes how to review an anomaly's detailed information.
- Anomaly Detail Overview
- Summary Information
- Anomaly Whitelist Rules
- Packet Buffer Capture
- Anomaly Facts Pane
- Conversations
- Anomalous Features Graph
- Anomaly Graph
- Mitigation from an Anomaly
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
|
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
).
).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
|
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
). 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
| 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
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 |
|
|
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
|
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. |
|
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. |
(Show Details)|
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
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
|
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 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
|
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
|
||
|
<IANA-special-range> |
hosts have an IP address within a special range, as defined by IANA:
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:
|
Cluster Detail 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
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 |
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.
Feedback