Cisco Tetration Analytics Release Notes, Release 3.1.1.59

Cisco Tetration Analytics Release Notes, Release 3.1.1.59

This document describes the features, caveats, and limitations for the Cisco Tetration Analytics software.

The Cisco Tetration Analytics platform is designed to address number of data center operational and security challenges comprehensively using rich traffic telemetry collected from servers, Cisco Nexus® switches and end point devices (such as laptops, desktops, and smart phones). The platform performs advanced analytics using an algorithmic approach to offer a wholistic workload protection platform. This algorithmic approach includes unsupervised machine-learning techniques and behavioral analysis. The platform provides a ready-to-use solution supporting the following use cases:

■      Provide behavior-based application insight to automate allowed-list policy generation

■      Provide application segmentation to enable efficient and secure zero-trust implementation

■      Provide consistent policy enforcement across on-premises data centers and private and public clouds

■      Identify process behavior deviations and software vulnerabilities and exposure to reduce attack surface

■      Identify application behavior changes and policy compliance deviations in near-real time

■      Support comprehensive telemetry processing in a heterogeneous environment to provide actionable insight within minutes

■      Comprehensive network performance metrics based on the telemetry collected from both switches and the servers

■      Enable long-term data retention for deep forensics, analysis, and troubleshooting

To support the analysis and various use cases within the Cisco Tetration Analytics platform, consistent telemetry is required from across the data center infrastructure. Rich Cisco Tetration Analytics telemetry is collected using sensors. There are different types of sensors available to support both existing and new data center infrastructures. This release supports the following sensor types:

■      Software sensors installed on virtual machine, baremetal, or container hosts

■      Embedded hardware sensors in Cisco Nexus 9000 cloudscale series switches

■      ERSPAN sensors that can generate Cisco Tetration telemetry from copied packets

■      Netflow sensors that can generate Cisco Tetration telemetry based Netflow v9 or IPFIX records

■      Cisco AnyConnect proxy to collect telemetry from endpoints, such as laptops, desktops, and smartphones

Software sensors also act as the policy enforcement point for the application segmentation. Using this approach, the Cisco Tetration Analytics platform provides consistent enforcement across public, private, and on-premises deployments. Sensors enforce the policy using native operating system capabilities, thereby eliminating the need for the sensor to be in the data path and providing a fail-safe option. Additional product documentation is listed in the "Related Documentation" section.

The release notes are sometimes updated with new information about restrictions and caveats. See the following website for the most recent version of this document:

https://www.cisco.com/c/en/us/support/security/tetration/products-release-notes-list.html

Table 1 shows the online change history for this document.

Table 1 Online History Change

 

 

Contents

This document includes the following sections:

■      New and Changed Information

■      Caveats

■      Compatibility Information

■      Usage Guidelines

■      Related Documentation

New and Changed Information

This section lists the new and changed features in this release and includes the following topics:

■      New Software Features

■      Changes in Behavior

New Software Features

This patch release does not include any new software features.

Changes in Behavior

This patch release includes the following changes in behavior:

 

■      The port to access Kafka from outside of the Cisco Tetration cluster has been changed from 9093 to 443. This change applies to all 3.1.1.x releases. Due to this change, you must re-download the Datasinks and Managed Data Taps (MDT) certifications to get the most updated tar.gz file that contains the port change in kafkaBrokerIps.txt file.

Caveats

This section contains lists of open and resolved caveats and known behaviors.

■      Open Caveats

■      Resolved Caveats

■      Known Behaviors

Open Caveats

The following table lists the open caveats in this release. Click the bug ID to access the Bug Search Tool and see additional information about the bug.

Table 2 Open Caveats

Resolved Caveats

The following table lists the resolved caveats in this release. Click the bug ID to access the Bug Search Tool and see additional information about the bug.

Table 3 Resolved Caveats

Known Behaviors

The following list contains the known behaviors in this release:

■      Deployment and Upgrade

o    The configuration fields for syslog (syslog server and syslog port) are deprecated in the Upgrade/Deploy GUI. Changes to these fields can only be made in the TAN GUI.

o    The configuration fields for remote CA (remote CA, remote CA URL, remote CA username, and remote CA password) are not supported on physical and ESX form factors.

■      TAN

o    User App alerts are not supported with the TAN virtual appliance.

o    Large size alerts(>64k) cannot be sent over UDP to the syslog server.

■      Data Taps/Kafka

o    On 8 rack unit deployments and ESXi cluster configurations, Cisco Tetration runs only 1 instance of the Kafka broker. Because of this, if there is a decommission or re-commission of the bare metal or VM that is hosting the instance, there will be data loss.

■      Enforcement

o    When enforcement is enabled and then disabled, agents will flush all of the rules and keep the catchall as ALLOW for both ingress and egress.

o    Agents will store the last known good policy from the backend, and will reload the policy upon service restart.

o    During a network policy update, the agent on Linux will reprogram the ipset list in a more atomic fashion by swapping the ipset's content with the new content instead of flushing and reprogramming. This reduces the chances of traffic drops.

o    During a network policy update, the agent on Windows will first set the Windows firewall inbound and outbound default policies to ALLOW, then proceed as before by removing the current rules, programming the new rules, and programming the inbound and outbound default policy as specified by the network policy configuration. This reduces the chances of traffic drops in the case of a DENY catchall policy.

o    Whenever enforcement is stopped in an enforced workspace, users should not delete objects in that workspace for approximately 15 minutes after enforcement was stopped. This ensures that pipelines have ample time to refresh the state about that workspace. User inventory filters or scopes referenced by the deleted application will not be deletable for 15 to 20 minutes after the deletion of an application.

■      Data leak

o    Data leak detection has 5-minute latency, hence data leak scores have a 5 minute delay compared to the data leak event time.

o    Data leak events are not currently shown in the Forensics Analysis page.

■      Process Hash Anomaly

o    Frequency analysis (and thus the output score) is done only at the rootscope level.

o    Analysis is run once per hour.

■      AnyConnect

o    Multiple AnyConnect proxies getting data from the same AnyConnect endpoint machine is not encouraged. If you have a use case that needs this mode, contact Cisco.

o    The same endpoint can connect to different proxies at different points in time as long as the endpoint does not flip-flop between different proxies. If a flip-flop occurs, the AnyConnect proxy will limit the scenario so that there should be at least 7 days when such a flip-flop happens. If there is a flip-flop use case in which an endpoint is alternating connections between 2 different proxies, contact Cisco.

■      Policy Publish on Kafka

o    For client applications, which utilize this feature, we do not recommend that you use the 8 rack unit deployment and ESXi cluster configuration, because this configuration has only one instance of the Kafka broker. If there is a de-/recommission of the bare metal or VM that is hosting the application, the created policy stream will not be recovered correctly and will become inoperational. Instead, use the 39 rack unit cluster configuration for higher availability of the policy stream.

■      ADM

o    An ADM run will no longer generate policies for flows that are already covered by manually created policies in the current application.

o    Clusters can no longer be used as a provided service. Existing clusters that are marked as public and referenced by an external application will be converted into inventory filters. Inventory filters become the only way to indicate a service provided by the scope or application.

o    When a cluster is promoted to an inventory filter, the cluster will be removed from the Conversations view. A new ADM run will be needed to generate an updated IP address-to-filter mapping.

o    Exclusion filters will be carried over across ADM runs. If clusters are used as part of an exclusion filter, the flows will only be removed if the application is primary.

o    A SLB upload for the Citrix load balancer configuration does not allow * as a port range. The configuration expects a single port to be specified in the configuration.

■      TIM Configuration

o    When F5s are configured in high availability mode:

§  The TIM F5 plugin fetches the configuration from only one F5 out of the configured list of hosts. All features of the F5 where this configuration differs between the primary and standby REST endpoints may experience delays after a switchover until TIM connects to the new primary.

o    Citrix configuration when Netscalers are configured in HA mode:

§  The TIM Citrix plugin fetches the configuration from only one Netscaler out of the configured list of hosts. All features of the Netscaler where this configuration differs between the primary and secondary REST endpoints may experience delays after a switchover until TIM connects to the new primary.

o    When VMware vCenter HA mode is active:

§  The TIM VMware vCenter plugin only fetches the configuration from one VMware vCenter endpoint at a time. The VMware vCenter HA mode and behaviour of the TIM VMware vCenter plugin is untested.

Compatibility Information

This patch requires Cisco Tetration to be running software release 3.1.1.53, 3.1.1.54, or 3.1.1.55.

For information about the 3.1.1.53 release, see the following Release Notes:

https://www.cisco.com/c/en/us/td/docs/security/workload_security/tetration-analytics/sw/release-notes/cta_rn_3_1_1_53.html

For information about the 3.1.1.54 release, see the following Release Notes:

https://www.cisco.com/c/en/us/td/docs/security/workload_security/tetration-analytics/sw/release-notes/cta_rn_3_1_1_54.html

For information about the 3.1.1.55 release, see the following Release Notes:

https://www.cisco.com/c/en/us/td/docs/security/workload_security/tetration-analytics/sw/release-notes/cta_rn_3_1_1_55.html

Usage Guidelines

This section lists usage guidelines for the Cisco Tetration Analytics software.

■      You must use the Google Chrome browser version 40.0.0 or later to access the web-based user interface.

■      This release supports the collection of telemetry and analytics from hardware sensors on Cisco Nexus 9300-EX switches. However, you must define the collection rules.

■      After setting up your DNS, browse to the URL of your Cisco Tetration Analytics cluster: https://<cluster.domain>

Verified Scalability Limits

For the verified scalability limits, see the Cisco Tetration Analytics, Release 3.1.1.53, Release Notes at the following location:

https://www.cisco.com/c/en/us/td/docs/security/workload_security/tetration-analytics/sw/release-notes/cta_rn_3_1_1_53.html

Related Documentation

The Cisco Tetration Analytics documentation can be accessed from the following websites:

Cisco Tetration Platform Datasheet: https://www.cisco.com/c/en/us/products/security/tetration/datasheet-listing.html

General Documentation: https://www.cisco.com/c/en/us/support/security/tetration/tsd-products-support-series-home.html

The documentation includes installation information and release notes.

Table 5 Installation Documentation

 

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2019 Cisco Systems, Inc. All rights reserved.