Cisco Tetration Release Notes
Release 3.1.1.70
This document describes the features, caveats and limitations for the Cisco Tetration software.
The Cisco Tetration platform is designed to comprehensively address a number of data center operational and security challenges using rich traffic telemetry collected from servers, layer 4 through 7 service elements, 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 security events/forensics processing in a heterogeneous environment to provide actionable insight within minutes
■ Enable long-term data retention for deep forensics, analysis, and troubleshooting
To support the analysis and various use cases within the Cisco Tetration platform, consistent telemetry is required from across the data center infrastructure. Rich Cisco Tetration 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, bare-metal, or container hosts
■ 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 end-points such as laptops, desktops, and smartphones
■ Embedded hardware sensors in Cisco Nexus 9000 Cloud Scale series switches
Software sensors also act as the policy enforcement point for the application segmentation. Using this approach, the Cisco Tetration 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.
These 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.
Date |
Description |
August 13th, 2019 |
Release 3.1.1.70 became available. |
Contents
This document includes the following sections:
■ Caveats
This section lists the new and changed features in this release, and includes the following topics:
This release includes the following enhancement:
■ Enforcement Agent saves latest NPC to disk reducing the stress on memory.
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, as well as known behaviors.
This table lists the open caveats in this release. Click the bug ID to access the Bug Search Tool for additional information about the bug.
Bug ID |
Description |
|
|
This table lists the resolved caveats in this release. Click the bug ID to access the Bug Search Tool for additional information about the bug.
Table 3 Resolved Caveats
Bug ID |
Description |
Install npcap in noncompatible mode |
|
SKU manager script fails with Exception: Invalid SKU:39RU-GEN1, cannot get a blueprint |
|
ADM - AppView doesn't save Policy Conversations unless nodes are added/removed |
|
Missing PID in Flow Search |
|
Anyconnect flows show incorrect LDAP user annotation |
The following list describes the known behaviors in this release:
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.
o A side effect of the fix for bug CSCvn37738 is that the MSI installation might stop in the middle of the agent upgrade, which leaves the agent in a stalled and unrecoverable state. In such a case, you must reinstall the agent. Check the file “migrate.log” (in the logs folder) to confirm if the migration process runs into an error.
■ 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 one instance of the Kafka broker. Because of this, if there is a decommission or recommission of the bare metal or VM that is hosting the instance, there will be data loss.
o Clusters that are upgraded from a pre-3.1.x build will display Alerts MDT (Managed Data Tap) ports as 9093 even though the ports have been changed to 443. The downloadable certificates have the correct port (443) information. This text information will be updated in the next release.
■ 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, do 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 cannot themselves be deleted for 15 to 20 minutes after deletion of the application.
■ Data Leak
o Data leak detection has a five-minute latency; hence data leak scores have a five-minute delay compared to the data leak event time.
o Data leak events are not currently shown on the Forensics Analysis page.
■ Process Hash Anomaly
o Frequency analysis (and thus the output score) is done only at the root-scope level.
o Analysis is run once per hour.
■ AnyConnect
o Multiple AnyConnect proxies getting data from the same AnyConnect endpoint 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 the different proxies. If a flip-flop occurs, the AnyConnect proxy will limit the scenario so that there will be at least seven days between such a flip-flop. If there is a flip-flop use case in which an endpoint is alternating connections between two different proxies, contact Cisco.
■ Policy Publish on Kafka
o For client applications which utilize this feature, we recommend that you do not 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 decommission or recommission of the bare metal or VM that is hosting the application, the created policy stream will not be recovered correctly and will become inoperable. 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 be removed only if the application is primary.
o An 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 in the list of configured 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 NetScaler products are configured in HA mode:
▪ The TIM Citrix plugin fetches the configuration from only one NetScaler in the list of configured 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 fetches the configuration from only one VMware vCenter endpoint at a time. The VMware vCenter HA mode and behavior of the TIM VMware vCenter plugin is untested.
Compatibility Information
This patch requires Cisco Tetration to be running one of the following software releases. You can upgrade to this patch release directly from any of these software versions:
3.1.1.53
3.1.1.54
3.1.1.55
3.1.1.59
3.1.1.61
3.1.1.65
3.1.1.67
For information about the 3.1.1.53 release, see the following Release Notes:
For information about the 3.1.1.54 release, see the following Release Notes:
For information about the 3.1.1.55 release, see the following Release Notes:
For information about the 3.1.1.59 release, see the following Release Notes:
For information about the 3.1.1.61 release, see the following Release Notes:
For information about the 3.1.1.65 release, see the following Release Notes:
For information about the 3.1.1.67 release, see the following Release Notes:
This section lists usage guidelines for the Cisco Tetration 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 cluster: https://<cluster.domain>
For the verified scalability limits, see the Cisco Tetration Release Notes, Release 3.1.1.53 at the following location:
Related Documentation
Cisco Tetration 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 8 Installation Documentation
Document |
Description |
Cisco Tetration Analytics Cluster |
Describes the physical configuration, site preparation, and cabling of a single- and dual-rack installation for M4 based Cisco Tetration (39-RU) platform and Cisco Tetration-M (8-RU). Describes the physical configuration, site preparation, and cabling of a single- and dual-rack installation for M5 based Cisco Tetration (39-RU) platform and Cisco Tetration-M (8-RU). |
Cisco Tetration Cloud Deployment Guide |
Describes the deployment of Cisco Tetration Cloud in Amazon Web Services. Document Link: http://www.cisco.com/c/dam/en/us/td/docs/switches/datacenter/nexus9000/hw/Tetration/b_tetration_cloud_setup.pdf |
Cisco Tetration Cluster Upgrade Guide |
|
Latest Threat Data Sources |
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.