Cisco Tetration Release Notes, Release 3.1.1.61
This document describes the features, caveats, and limitations for the Cisco Tetration software.
The Cisco Tetration 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 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, 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 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
Date |
Description |
March 11, 2019 |
Release 3.1.1.61 became available. |
This document includes the following sections:
■ Caveats
This section lists the new and changed features in this release and includes the following topics:
This patch release does not include any new software features.
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.
■ With this patch release, built-in cloud migration app is being deprecated. Customers can use User Apps as an alternative to achieve the same functionality. Sample user app for this can be found in the link below:
o https://github.com/tetration-exchange/DailyRollupSample
This section contains lists of open and resolved caveats and known behaviors.
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
Bug ID |
Description |
For the Lookout Annotation, if a new rootscope is added, Zeus/Bogon tags are not added to that rootscope unless the UAS service is enabled. |
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
Bug ID |
Description |
A memory leak in python-lvm causes an out of memory issue for the bmmgr after long periods of time. |
|
Update the user guide. |
|
Hourly summary alerts were not sent unless a daily summary alert was also configured. |
|
TAN used the HTTPS proxy by default, this caused issues if the SMTP server was not behind proxy. Implemented a fix that ignores the HTTPS proxy and connects to SMTP if possible. |
|
In the data platform charts, the filter associated with the user-created charts was not being saved. |
|
Remove the 2.* release sensors to make space in /local/. A more detailed clean is in the 3.3 release. |
|
Match the Windows sensor's binaries with the release version. |
|
Avoid flooding the agent log when TSO is detected in the Windows sensor. |
|
Reduce the sensor log verbosity. |
|
Agent upgrade page: Downloading all results also downloads the filtered sensors. |
|
Delay opening NFLOG until enforcement is enabled. |
|
Show the correct release version in title of the Documentation pages. |
|
In Applications, Tetration lists the inventory members that are in the time interval under consideration for an ADM run. Tetration links to a workload profile directly if a Tetration agent is associated with the inventory. |
|
When packets are dropped by the iptable's concrete rule, the drop reason might not be correct in the GUI. |
|
AIX universal sensor installation cannot proceed when <exiting> processes are detected. |
|
Enhance the agent installer script to list the versions and then choose a specific version for installation. |
|
Make the agent enforcer service start after a system reboot. |
|
The TAN syslog message should include priority as part of the message. |
|
The Windows Universal Visibility self-test fails due to an invalid character. |
|
Make "secure connection" an option in the TAN Email configuration for the SMTP server. |
|
A sensor cannot be installed on SLES 11 SP2 and SP3 platforms. |
|
ADM does not capture link-local traffic. |
|
Intermittently, an incorrect firewall profile gets selected upon rebooting the enforcement agent host. |
The following list contains 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 encounters 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 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.
o A cluster that is upgraded from a pre-3.1 release will display the alerts MDT (managed Data Tap) ports as 9093. However, 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, 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.
This patch requires Cisco Tetration to be running software release 3.1.1.53, 3.1.1.54, 3.1.1.55, or 3.1.1.59.
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:
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 in the 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 Analytics, Release 3.1.1.53, Release Notes:
The 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 5 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.