Stellar Cyber 4.2.1 Release Notes

Stellar Cyber 4.2.1 brings improvements to the Stellar Cyber Open XDR platform, including new features, improvements, enhancements, key fixes, and known issues. Upgrade instructions follow all of that great information.

For an overview, see the Stellar Cyber 4.2.1 Preview Video

Platform Security Enhancements

Addressed the Log4j2 vulnerability (CVE-2021-44228) by disabling format msg lookup in all applications where Log4j2 is included.

Server Sensor Enhancements

The Linux Server Sensor now supports Debian 11.

Parser Enhancements

Improved data normalization in the following parsers:

  • The Corelight parser

  • The CEF parser for SentinelOne logs

  • The Cylance log parser

  • The Nginx log parser

  • The OneLogin log parser

Connector Enhancements

  • Introduced a new AWS CloudWatch connector that can collect AWS ECS/EKS and Amazon GuardDuty logs. In this release, the AWS CloudWatch connector must be configured with only one log group specified. If more than one log group requires data collection, one AWS CloudWatch connector must be configured for each log group. This limitation will be addressed in a future release.

  • Introduced a new OneLogin connector that collects OneLogin events and user data.

  • Enhanced the Azure AD connector to support response action of disabling users (re-enable by reverting the action).

  • Introduced a Cisco Meraki Firewall connector that supports response actions to block (and revert a block) against an IP address using the outbound firewall rules.

  • Enhanced the Office 365 connector to:

    • Collect DLP.ALL events.

    • Specify the Subscription plan type, including Enterprise, GCC Government, GCC High Government, and DoD Government plans.

    • Support the .us, .de, and .cn authentication endpoints.

    • Enhanced the msg_class field to include content type.

  • Enhanced the Azure EventHub connector to collect Azure Activity Logs.

  • Enhanced the Active Directory connector to support LDAP over SSL (LDAPS).

  • Enhanced data normalization in the VMware Carbon Black Cloud and SentinelOne connectors.

Detection/ML Improvements

Improvements were made to handle EDR alerts ingested from log parsers or collectors configured for VMWare Carbon Black, SentinelONE, and Blackberry Cylance as follows:

  • SentinelOne EDR alerts are deduplicated and then mapped to Stellar Cyber alerts.

  • BlackBerry CylanceProtect EDR events are filtered to a specific set of high fidelity alerts which are then enriched and deduplicated before mapping to Stellar Cyber alerts..

  • VMWare Carbon Black events are filtered to a specific set of alerts, which are then enriched and deduplicated before mapping to Stellar Cyberalerts. Events with a threat category of UNKNOWN are processed directly through Stellar Cyber Machine Learning to generate Stellar Cyber ML-based alerts.

  • CrowdStrike alerts are mapped directly to Stellar Cyber alerts (this functionality already existed but is included here for clarity regarding EDR alerts).

  • A new alert type has been added for VMWare Carbon Black Cloud (Refer to the Machine Learning Details topic in the Knowledge Base).

Platform Enhancements

  • Add status in the System Health page to indicate DL performance issues caused by imbalanced shards. Introduced a CLI command to trigger shard balance.

  • Cold data stored in AWS/Azure archive storage types can be restored. Please contact the Stellar Cyber Customer Success team for detailed instructions.

  • Improved platform scalability to allow more connectors to run in parallel.

Usability Improvements

  • Event details display has been reworked to improve usability. The functions below the header block are now accessed from a static menu that allows the objects to be displayed in a scrolling pane rather than the menu options scrolling. It is now easier to access Interflow JSON and details, Key Details, and Actions. Additionally, a menu option has been added to the Event Details that lists the incidents related to that alert, if any.

  • The default columns for Threat Hunting and Alert tables have been reduced to a smaller set, to improve readability. If you have previously modified your column settings those are preserved.

Critical Bug Fixes

  • Fixed a known issue in 4.1.2 and 4.2.0 that prevented users from switching tenants after inadvertently triggering display of the Stellar Cyber UI page https://<StellarCyberUI>/investigate/404.

  • GoogleDNS data filters now work correctly.

  • Improved the DGA detection and reduced the false positives of DGA alerts.

  • Restored the Source/Destination IP GEO Location in the Alert Details page which were missing in 4.1.2.

  • Applied additional data normalization in the Nginx parser to avoid data drops in the ingestion pipeline.

  • Fixed the “Failed to parse field [ModifiedProperties]” error in the Office 365 connector.

  • Fixed a defect that caused inaccurate data to be shown in the Ingestion Usage table.

Known Issues

  • A modular sensor upgrade will fail when the associated modular sensor profile has the IDS or Sandbox features enabled and the corresponding feature license is not assigned to the sensor. Workaround: Authorize the sensor with an IDS and Sandbox license, or in the modular sensor profile, disable the IDS and the Sandbox features and try to upgrade again.

  • Stellar Cyber recommends using the same CPU and Memory specifications for DL nodes. Variations in specifications across worker nodes can cause Data Lake stability issues.

  • The proxy settings do not work in the following connectors: Cisco Umbrella, VMware Carbon Black, Duo Security, Tenable.io, Prisma Cloud, AWS Cloudtrail, BlueCoat WSS, and Azure Event Hub.

  • The heatmap widget in the 4.2.0 release is a complete replacement of the one used in previous releases and includes new geolocation capabilities. Note that any existing dashboards using a heatmap chart continue to use the old heatmap widget until you edit the charts manually.

  • When multiple traffic filters are defined for a tenant with the same combination of ip, port, protocol, and layer 7 rules, the filter may fail to take effect. Administrators should review the defined traffic filters and make sure there are no duplicate definitions among filters.

  • Files may not be assembled by Security Data Sensors for traffic mirrored from physical interfaces on Cisco Nexus 9K models. As a workaround, configure VLAN mirroring on the Cisco switch.

  • Sensor installation on Linux servers running CentOS 6 fails because the official CentOS 6 package download link is no longer available.

  • If you change the network interface configuration of a sensor’s VM after deployment, the eth0 interface may be remapped to a new interface. If this happens, the management network is disconnected. Contact Technical Support for assistance.

  • The stellar_syswatcher service may be missing after a new installation or upgrade of a Windows agent sensor for Windows Server 2008 R2. This is due to a required patch from Microsoft . Patch target Windows Server 2008 R2 hosts before you install or upgrade so you can leverage traffic information from the Windows agent sensor.

Upgrading

You can only upgrade Stellar Cyber from 4.1.5 or 4.2.0 to 4.2.1. You must:

Please refer to the online documentation section Upgrading Software for more detailed instructions.

Preparing for the Upgrade

To prepare for the upgrade:

  • Back up the data and configuration
  • Make sure the sensors are up and running
  • Take note of the ingestion rate
  • Take note of the number of alerts
  • Make sure the system health indicator shows
  • Run the pre-upgrade check

Upgrading the DP to 4.2.1

To upgrade the DP to 4.2.1 you must first upgrade to 4.1.5 or 4.2.0.

  1. Click Admin | Software Upgrade.

  2. Choose 4.1.5 (or 4.2.0).

  3. Click Start Upgrade.

  4. After this base upgrade is completed, repeat the upgrade process and select 4.2.1.

 Review Alert/Machine Learning Training Time for guidance on training time of updated ML models.

Upgrading Sensors

New features, updated ML algorithms, and enhanced configurations may change ingestion and detection patterns. We recommend the following to ensure a smooth upgrade:

  • Upgrade security sensors before network sensors, because network sensors send data to security sensors for additional processing.
  • Upgrade sensors in batches instead of all at once.
  • For agent sensors:
    • Upgrade a small set of sensors that cover non-critical assets.
    • After 24 hours, ensure that your ingestion is as expected, then upgrade a larger set.
    • After 24 hours, ensure that your ingestion is as expected, then upgrade the remaining agent sensors.

To upgrade Windows-based sensors:

 If your deployment is already running v3.12.1 or 4.1.2, you do not need to upgrade your Windows-based sensors. For deployments running older versions, you can manually download and upgrade using the 3.12.1 Windows installers listed below.

 The Collect | Sensor Overview | Software Upgrade page does not list a Windows upgrade package. Also, you cannot download the .msi installation file from the Configure | Agents | Windows tab in this release.

To upgrade Linux-based sensors:

  1. Click Collect | Sensor Overview. The Data Sensor List appears.
  2. Click the MANAGE drop-down and choose SOFTWARE UPGRADE. The DATA SENSOR SOFTWARE UPGRADE panel appears.
  3. Choose the target software version.
  4. Choose the sensors to upgrade.
  5. Click Submit.

Verifying the Upgrade

To verify that the upgrade was successful:

  • Check the Current Software Version on the Admin | Software Upgrade page.
  • Make sure the sensors are up and running.
  • Check the ingestion rate and make sure it is as expected.
  • Check the number of alerts and make sure it is as expected.
  • Check the system health indicator:
    • indicates a perfectly healthy system.
    • indicates minor issues. Monitor the system for 30 minutes. If the issues remain, investigate further.
    • indicates major issues. Contact Technical Support.