Anomaly Detail. Anomaly Detail Overview. The following describes how to review an anomaly's detailed information.

Transcription

1 The following describes how to review an anomaly's detailed information. Overview, page 1 Summary Information, page 2 Anomaly Whitelist Rules, page 3 Packet Buffer Capture, page 5 Anomaly Facts Pane, page 6 Conversations, page 8 Anomalous Features Graph, page 14 Anomaly Graph, page 15 Mitigation from an Anomaly, page 16 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 1

2 Summary Information 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. Related Topics Assigning Relevance Feedback for an Anomaly Reviewing and Adding Comments Summary Information Fields Field Id Agent Date, time Severity Seen The reason the system considered this traffic anomalous, the anomalous traffic directionality, and the target host. The anomaly's ID number. The agent that reported the anomaly. The date and time the anomaly started. The system's rating for the possibility of negative impact upon your network. The date and time a user first viewed this anomaly's details. Viewing Other s 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 ( ). 2

3 Anomaly Whitelist Rules 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 Table 1: Whitelist Rule Fields Column Cluster IP address App. group Bidirectional conversation the cluster containing the target host the target host IP address the application group over which the target host and other host transferred traffic whether the anomalous conversation is unidirectional or bidirectional 3

4 Whitelist Rule Validation Column With external host Features Agents whether the anomalous conversation involves a host external to the branch the detected anomalous features 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. 4

5 Creating a Whitelist Rule 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. 5

6 Downloading PCAPs Downloading PCAPs Step 1 Step 2 Step 3 Step 4 Select Inbox. Click an anomaly's description. Click Get PCAP files. Wait for the controller to retrieve the PCAP from the agent. 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. Related Topics Anomaly Facts Displayed, on page 6 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 auth Applications used for user authentication and authorization Examples Active Directory, LDAP, RADIUS 6

7 Application Groups Application Group cloud collab darknet database dns file-xfer game icmp infra media network ntp office other other-ip-proto p2p Applications that store information and files in a cloud service Applications that enable collaborative interaction between users Applications that provide access to a darknet Applications that provide access to and interaction with databases Applications related to the Domain Name System (DNS) File transfer applications Game and gaming-related applications Internet Control Message Protocol (ICMP)-related applications Applications used to test and configure network infrastructure Media streaming applications Protocols and applications used for routing internet traffic Network Time Protocol (NTP)-related applications Applications used for office work, such as Applications that do not belong to other defined application groups Internet Protocol-related applications that do not belong to other defined application groups Peer-to-peer file sharing applications Examples Hotmail, Dropbox, Google Docs ICQ, Skype, Gtalk Tor SQL Server, MySQL, Sybase DNS FTP, NFS, Gopher Call of Duty, Maple Story, Steam ICMP Ping, DHCP, Endpoint Mapper Netflix, Hulu, Pandora BPG, OSPF, IGRP NTP SMTP, IMAP, NMAP remotefs, IIOP, VPP Sprite Remote Procedure Call, Message Posting Protocol, Storage Management Services Protocol Gnutella, BitTorrent, edonkey 7

8 Conversations Application Group print proxy remote shell social syslog tunneling unknown unknown-tcp unknown-udp windows www Printing-related applications Proxy server applications Applications used to access hosts remotely Applications used to access operating systems, including CLIs Social networking applications Syslog-related applications Applications used to create a tunnel and transmit traffic across it Unknown applications Unknown TCP applications Unknown UDP applications Microsoft Windows-related applications Websites on the World Wide Web Examples Network Printing Protocol, Internet Printing Protocol, Printer Socket Secure (SOCKS) Citrix, X Window System, pcanywhere Telnet, SSH, Secure Telnet Facebook, LinkedIn, Twitter syslog Hamachi, ISAKMP, SCTP Unknown unknown-tcp unknown-udp Windows Update, Common Internet File System (CIFS), NetBIOS 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. 8

9 Conversation Fields 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 Table 2: Edge-level Conversation Fields Field App. group Source Destination (Show Details) Bytes (sum) Packets (sum) Bitrate (avg) Anomalous Features The application group that contains the application used in the conversation. The source host IP address or hostname, and if available, the source cluster and geolocation information. 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. The total number of bytes transmitted in all related conversations and flows over this application group. The total number of packets transmitted in all related conversations and flows over this application group. The average speed for all related conversations and flows in bits per second (bps), kilobits per second (Kbps), or megabits per second (Mbps). The anomalous characteristics this edge displays. Table 3: Individual Conversation and Flow Fields Field Protocol & Application Source port Destination port The protocol and application used in the conversation or flow. The source host port. The destination host port. 9

10 Conversation Fields Field Bytes Packets Bitrate The number of bytes transmitted in this conversation or flow. The number of packets transmitted in this conversation or flow. 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 Table 4: Host Detail Pane Fields Field Cluster Member since Country State City Threat intel ISE The cluster to which the selected host belongs. The date and time the system added the selected host to this cluster. If available, the country where this host is located. If available, the state where this host is located. If available, the city where this host is located. The host's reputation, based on Talos analysis. 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: 10

11 Conversation Fields 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 servers and ssh servers in subnet new hosts within the branch, identified as servers and ssh servers, part of the /24 subnet external p2p clients - known hosts external to the branch, using peer-to-peer clients internal mixed hosts in subnet known hosts within the branch, using a variety of applications, part of the /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. 11

12 Conversation Fields Cluster Name Attributes 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. Table 5: Cluster Name Attributes Attribute Name new internal external subnet <subnet> <country> <region> <application-groups> hosts are recently detected, and the agent cannot yet identify the applications most often used by the hosts hosts are internal to the branch hosts are external to the branch hosts belong to the /24 subnet listed in <subnet> hosts are located in <country>, based on the geolocation database hosts are located in <region> within <country>, based on the geolocation database 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. 12

13 Conversation Fields Attribute Name <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 iana-ipv4-special-registry/ iana-ipv4-special-registry.xhtml and 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 Country Host Threat Flag The geolocation flag icon representing the country in which the host is located. The host IP address, or hostname if available. Whether threat intelligence from Talos identified this host as malicious. 13

14 Filtering Conversations Downloading Hosts in a CSV File Step 1 Step 2 From an agent dashboard or an anomaly's details, click a cluster name. Click Download as CSV. Filtering Conversations Step 1 Step 2 Step 3 Select Inbox, then click an anomaly's. If it is collapsed, click the expand arrow ( ) to expand the Filters pane. 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. 14

15 Anomalous Feature Types Anomalous Feature Types Table 7: Anomalous Feature Types Anomalous Feature DNS request subpart length Number of bytes Number of bytes per packet Number of flows Number of packets Number of packets per flow Total flow duration Unexpected created edge Unusual time of day 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. The number of bytes in an anomalous conversation is smaller or larger than what the agent learned about conversations. The number of bytes per packet in an anomalous conversation is smaller or larger than what the agent learned about conversations. The number of flows in an anomalous conversation is smaller or larger than what the agent learned about conversations. The number of packets in an anomalous conversation is smaller or larger than what the agent learned about conversations. The number of packets per flow in an anomalous conversation is smaller or larger than what the agent learned about conversations. The flow duration is longer or shorter than what the agent learned about flows. The anomalous edge involves an application not previously detected between the clusters by the agent. 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 15

16 Mitigation from an Anomaly 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 Step 1 Step 2 Step 3 Step 4 Select Inbox. Click an anomaly's description. Click Mitigate this anomaly in the Mitigate pane. The system prepopulates two mitigation policies with information matching the anomaly. 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 Step 6 If you want to change the anomaly duration, update the Duration. Click Create mitigation policies. 16