The NetWitness 12.4.1.0 Release Notes describe new features, enhancements, security fixes, upgrade paths, fixed issues, known issues, end-of-life functionality, build numbers, and self-help resources.
The following sections are a complete list and description of enhancements to specific capabilities:
To locate the documents that are referred to in this section, see https://community.netwitness.com/t5/netwitness-platform-online/netwitness-platform-all-documents/ta-p/676246.
The Product Documentation section has links to the documentation for this release.
The following section describes the new enhancements for ESA component:
The NetWitness Platform enables administrators to perform smooth failovers with minimal processes and tools involved in the entire design, making it easier for the clients to minimize downtime during service interruptions. Administrators can set up an ESA Standby node in the event of a disaster or unplanned outage of the original active ESA Primary node. Recovery involves switching from the active ESA Primary node to the ESA Standby node by taking Mongo and configuration backups of the active ESA Primary system and restoring them to the ESA Standby with the required configurations to ensure uninterrupted access to ESA correlation and context hub services. The new ESA Primary node should be configured with its unique IP and host details, ensuring a seamless setup process that is not hindered by prior configurations.
For more information on how to perform the ESA DR failover, see NetWitness Deployment Guide for 12.4.1.
The following section describes the new enhancements for UEBA component:
NetWitness no longer supports JA3 as an entity for UEBA, starting from version 12.4.1. This change is implemented because JA3 is identified as an unreliable client identification method. The effectiveness of JA3 fingerprinting in determining the true identity of clients is no longer accurate due to the adoption of client TLS extension randomization. With randomization, a single client can have numerous JA3 fingerprints instead of just one. This makes it difficult for UEBA to accurately distinguish between normal and malicious activity.
For more information, see NetWitness UEBA User Guide for 12.4.1.
This section describes the functional improvements made to the Insight component:
This release introduces improvements to the NetWitness Analytics network asset identification process to ensure accurate classification and reduce misconfigurations.
If users are running Port Scanners in their environment, it is important to remember that these Port Scanners can generate significant traffic. Such traffic could impact the NetWitness Analytics and result in misclassification of servers as clients, affecting enterprise network exposure, peer network exposure rankings, asset category, and detection accuracy for each asset. To prevent network asset misclassification, contact NetWitness Customer Support and provide them with the list of Port Scanner IPs. Your information will be used by NetWitness Analytics to improve asset identification and classification.
If users do not follow the RFC 1918 standard and use a different standard to define their internal IP addresses, NetWitness Analytics may not recognize them correctly. As a result, some internal assets may be classified as external assets or vice versa. To avoid this issue, contact NetWitness Customer Support and provide them with your internal IP ranges. Your information will be used by NetWitness Analytics to improve asset identification and classification.
The following enhancements are made for Concentrator, Decoder, Log Collector, and Archiver Services in 12.4.1.0 version:
NetWitness Platform optimizes the Packet Decoders for the most effective detection and investigation, balancing high performance with depth of visibility.
Administrators can now change the scanning depth limit depending on the detected protocol. Additionally, different parse.bytes.max for each protocol can be set to focus on parsing and generating metadata for more valuable sessions.
NetWitness Platform allows parsers to constantly step through a session as tokens are found on a protocol basis to optimize generating meta in appropriately valuable sessions. The Step Scan enables the scan engine to continue scanning from the position of the last token found for the specified number of bytes. This process repeats each time a token is found and continues until the scan reaches the end of the stream or there are no more tokens. Administrators can optimize specific parsing traffic further into a session to get better visibility for protocols more prone to extensive sessions with potential threats.
NetWitness Platform has introduced two new meta keys to track the number of bytes scanned per session. These meta keys are scanned.client and scanned.server, which keeps track of the scanned bytes for the client and server streams. Administrators can review the progress of a session scan and compare it to the set parse limit and session size. This setting is disabled by default, but it can be turned on by ensuring that the parser ScannerAnalytics is enabled. These meta are indexed as UInt64 types with level IndexKeys, so all regular queries relating to integers are applicable.
NetWitness Platform supports the integration of the following event sources to collect and parse logs. Unless specified, these services are supported on NetWitness Platform 12.2.0.0 or later.
For more information on integrating the parser services, see NetWitness Platform Integrations Guide.
IMPORTANT: It is crucial to adhere to security best practices by avoiding the deployment of an Admin server node on a public IP address. This precaution is essential to mitigate the risk of potential directory traversal attacks, particularly through vulnerable endpoints such as /nwrpmrepo and /service-mappings.json files. These files contain sensitive information including private IPs, RPMs, and other executables, which must remain strictly restricted from exposure to the internet. Implementing this safeguard helps prevent unauthorized access to internal NetWitness environments.
For more information on Security Fixes, see https://community.netwitness.com/t5/netwitness-platform-advisories/ct-p/netwitness-advisories#security.
The following upgrade paths are supported for NetWitness 12.4.1.0
NetWitness 12.4.0.0 to 12.4.1.0
NetWitness 12.3.1.0 to 12.4.1.0
NetWitness 12.3.0.0 to 12.4.1.0
NetWitness 12.2.0.1 to 12.4.1.0
NetWitness 12.2.0.0 to 12.4.1.0
For more information on upgrading to 12.4.1.0, see Upgrade Guide for NetWitness 12.4.1.0
IMPORTANT: If you want to upgrade from 11.7.x or 11.7.x.x versions to 12.4.1.0 version, you must first upgrade to 12.2.0.0 or 12.3.0.0 version before upgrading to 12.4.1.
IMPORTANT: The Warehouse connector uses a lockbox to store credentials securely for data integration sources and destinations. However, users upgrading from earlier versions to the 12.4 version cannot start the configured streams without migrating their existing credentials in the new lockbox. As a result, users must manually create a new lockbox key and then refresh the password for their sources and destinations configured in Warehouse Connector, wherever applicable. For detailed instructions on creating the new lockbox key, refer to the Warehouse Connector section under the Post Upgrade Tasks in the Upgrade Guide for NetWitness 12.4.1.0.
See for Product Version Life Cycle for NetWitness Platform a list of versions that reach End of Primary Support (EOPS).