What to Expect with Cisco Secure Workload version 3.9
User Interface (UI) Improvements
Magnetic User Interface Transition
Phase 1 of the magnetic user interface transition includes reskinning, redesigning, and replacing existing components with magnetic components. The updated UI will have a unique style and layouts using the existing Magnetic Design System foundations, components, and templates. This is being done so that Cisco Secure Workload (CSW) will have a look consistent with other Cisco security products. In addition, this phase includes a cleanup of some UI inconsistencies on some pages.
Connectors - New Features
Google Cloud Platform (GCP) Connector
The Beta tag has been removed from the GCP Connector
Identity Connector - New!
In previous CSW versions, customers could only fetch the User Identity data as part of the ISE and AnyConnect Connectors. In addition, the LDAP configuration was limited to 1 per connector and had to be repeated for each LDAP configuration. The new Identity Connector provides a central place to fetch identity data from OpenLDAP. This new connector has no need for an external appliance. The connector provides an inventory view of all the fetched users within each connector. In addition, this connector is compatible with Secure Connector tunneling.
Future 3.9 patches will add support for Active Directory as a source in Identity Connector. Also, ISE and AnyConnect will be able to leverage the new Identity Connector thus eliminating the need to add the LDAP configuration within each connector and Azure Active Directory (now called Microsoft Entra ID).
Agent Changes and Enhancements
Windows Single Service
The Secure Workload agent on Windows workloads is now defined by a single service named CswAgent, replacing the previous TetSensor and Tetenforcer services. This enhancement streamlines agent service control, eliminates redundant engine processes, and ensures consistency with the Unix Single Agent Service.
Agent Memory Quota
The default value for the Memory Quota Limit for Process Visibility and Forensics in the Agent Config Profile is increased from 256MB to 512MB.
AIX PID Lookup
The AIX agent now supports PID Lookup.
Prevent Older Agent Registration
The platform can now be configured to prevent older agents from registering. For example, if Secure Workload version 3.9 is in use, and the agent you are trying to download or register is on 3.7 or earlier,
the agent fails to download or register. To enable this feature, go to Platform -> Cluster Configuration-> Disable Unsupported Agents.
Inventory Enhancements
Inventory Tagged Subnet/IP Addresses
Subnets that have been labeled as part of the inventory are now visible in the inventory page. If the user clicks on a subnet in the inventory page, the details of the labels associated with the subnet are displayed.
Traffic Flow Search Visibility Enhancements
Full Proxy Visibility
Before version 3.9, when a client workload was using an HTTP or HTTPS proxy to access the Internet, the CSW agent could only capture the flow between the workload and the proxy server - the actual destination of this flow was unknown. Beginning with version 3.9, CSW agents will be able to capture the destination of proxied flows as well. The full flows can be viewed from the Investigate -> Traffic page as related flows. The flow details now include the proxy flow (from the workload to the proxy) and the proxied flow (flow from the workload to the remote FQDN/IP address).
Windows User Identity Available in Flows
Windows user identities are now visible in traffic flows when the CSW agent version 3.9 or greater is installed on a workload . To enable user visibility, you must configure two Agent Config Profile settings in the Manage -> Workloads -> Agents -> Configure page. First, the Flow Analysis Fidelity option must be set to Detailed. Second, the PID/User Lookup option must be set to Enabled.
If the workload is the member of a Windows AD domain, the user is reported in the format Domain Name\Username. If the workload is the not a member of a Windows AD domain, the username is reported in the format Host Name\Username. Agents report User Information and the PID for IPv4 and IPv6 flows for the TCP and UDP protocols.
Segementation Enhancements
Domain-Based Enforcement
Policies can now be created based on specific domain names to allow or deny traffic. Domain-based enforcement leverages the UDP DNS responses that a sensor sees. Domain-based enforcement is supported only with HTTP/HTTPS proxies (no socks proxy). Also, in Windows WAF mode, the agent enforces domains at monitor intervals (every 5 seconds).
Please note that after enforcing a domain using an IP address, the enforcement agent does not clear the IP until either the agent is restarted, or the IP address is removed from the DNS cache that the sensor maintains. Also, a few packets may escape when domain-based policies are enforced for the first time. Domain-based enforcement using a proxy is not yet supported on AIX.
Logging, Alerting, and Monitoring Enhancements
Alert Name Field Added
A new field called Alert Name has been added so that alerts can be given a unique name when they are created. This allows organizations to use an alert naming convention and introduces a structured approach to better facilitate alert management.
Alerts User Interface (UI) Enhancements
Alerts Basic View
Several new filtering options have been added when viewing alerts. Filters are now available for the Status, Type, and Severity fields.
Alerts Advanced View
When filtering alerts using the new Advanced View, users can now combine multiple search attributes using both AND and OR operators for a more refined search experience.
Cluster Hardware and Maintenance Enhancements
RAID5 Support for 39RU-G3
For on-prem deployments, 39RU-G3 B and C nodes will be configured for hardware RAID5 when reimaged using the 3.9 imager or when they are reimaged from the cluster status page when 3.9 is installed on the cluster. B and C nodes (39RU-G3) supplied by the manufacturer with 3.9 will have hardware RAID5 pre-configured. During the bare metal reimaging process, the CIMC pre-configuration script automatically detects the node type and configures the appropriate RAID type. There is no change in storage for the S (39RU-G3) and U (8RU-G3) nodes. They continue to have independent RAID0 drives.
Dual Stack Support for Data Backup and Restore (DBR)
DBR now supports dual stack mode. Note that if you wish to use IPv6 to reach the S3 bucket, the URL specified must be an IPv6-based FQDN - not just an IPv6 address.
DBR Cluster Reset Without Reimaging
A Secure Workload cluster reset reinitializes the services and clears all datastores and returns the cluster to a base image. In previous versions a reset required a complete reimaging of the cluster. A cluster can now be reset without going through the reimaging process.
RPM Staging Prior to Upgrade
Currently, as soon as an RPM is uploaded to a cluster during the upgrade process it is immediately installed. This results in very long maintenance windows to upgrade a cluster due to the time needed just for uploading each RPM. With 3.9, after the tetration_os_rpminstall_k9 RPM is uploaded and installed, all other RPMs can be uploaded (staged) but the actual installations of the RPMs can be done later during a maintenance window.
Migrating from M4/M5 to M6
A workflow has been added to assist customers in migrating from M4/M5 clusters to M6. The workflow consists of using either DBR for full migration support or the openAPI based option for migrating the configuration only.
Miscellaneous
- Ingest Appliances – Previously, only one instance of the same connector type could be enabled on the same ingest appliance. Ingest appliances now support multiple connectors of the same type.
- Inventory Filters – When creating inventory filters, the query can now include domain names.
- M6 Optimized VM Allocation Logic - On M6 hardware, VM allocation logic is optimized when deploying along with 3.9.
- Hadoop Namenode VM - The node running the Hadoop Namenode VM no longer requires manual switchover in the event of failures.
Updated 10 months ago