Stellar Cyber 5.3.0 Release Notes

Software Release Date: November 14, 2024
Release Note Updated: November 14, 2024

The Stellar Cyber 5.3.0 release brings the following exciting improvements to the Stellar Cyber Open XDR platform.

The release notes are organized into the following sections:

Highlights

Actions Required

  • The new Query Builder introduces an updated schema. Make sure to update any queries in the new query table that are using the old schema flow. They will be flagged for review.

  • Update any configurations with field changes noted in the Behavior Changes section.

Behavior Changes

Changes that affect the way you interact with the product or interpret results are listed below.

  • The aella_flow module is now optional for Linux-based sensors; it can be disabled with the Network Traffic option in a standard sensor profile.

  • Do not rely on free-disk-space checks performed by server sensors. Instead, set log rotation policies appropriate for the log volume of the server workloads.

  • Fortigate CEF parser – Fields were moved from msg_data to the vendor namespace.

  • Epay parser – Two timestamps are now parsed: one in the Logstash header and one in the message section.

  • Checkpoint Harmony Endpoint parser – The attack_status and service_domain fields were relocated from under msg_data to the checkpoint container.

  • Aliyun parser – Fields were moved from msg_data to the vendor container.

  • ESET PROTECT parser – The group_description field was relocated to the vendor container.

  • Palo Alto Networks Prisma Cloud parser – The CVE, CVSS, and package path fields are now extracted into separate fields in the vendor namesapace.

  • Cisco ASA parser – Support for permitted as an action field value was added and dst_service is now normalized as dstport.

  • Sophos parser – An additional ten fields are now extracted from msg_data.

  • Incapsula SIEM Integration parser – Seven additional fields are now normalized.

  • Aliyun parser – Six additional fields are now normalized.

  • OpenVPN parser – The field openvpn.detial_message has been renamed to openvpn.detail_message to ensure the proper parsing of logs.

Deprecated Features

The following features have been deprecated in this release.

Detection/ML

New Features

Improvements

Platform

New Features

Improvements

Sensors

New Features

Improvements

Connectors

New Features

Improvements

Parsers

New Features

Improvements

Usability

New Features

Improvements

Operational Notes

  • Keep in mind that the global Status filters available at the left of most Stellar Cyber tables (All Open, New, In Progress, Ignored, and Closed) apply only to security events (alerts). They do not apply to cases. You can apply Status filters to cases, too, but only from the Cases interface itself. The names of the Status filters for cases are also slightly different from those available for alerts.

  • Lookup strings for hash values should not include the SHA= or MD5= prefix. Enter these strings using just the hash value itself.

Resolved Issues

Known Issues

  • A query might not produce consistent search results if the field is set for a time, the value includes millseconds, and the operator is set as is or is not. Workaround: When you define a query with a time field and a value that includes milliseconds, it’s not recommended to use is or is not as the operator. For more consistent search results, use one of the following operators instead: greater than, greater than or equal to, less than, less than or equal to, or in range.

  • When searching the Asset Analytics tab for an IP address, make sure you set the Search Column to Friendly Name, IP, or IP History. Searches for IP addresses with the Search column set to its default value of All don't work correctly. This will be fixed in a later release.

  • The Cylance responder is unable to perform the Contain Host action due to a limitation in the Cylance REST API. All requests return a 500 Internal Server error response.

  • Stellar Cyber recommends that you do not use the same login credentials to configure Azure or Azure Active Directory connectors for multiple tenants in the same company.

  • Windows Server Sensor installation can trigger the installation of Microsoft Visual C++ on the host machine if it isn't installed already. If the installation of Visual C++ fails, the Windows Server Sensor might not be able to decode the token used to authorize and configure its installation, leaving it unable to register with stellarcyber.cloud. If this happens, use the following steps to proceed:

    1. Update and restart the host Windows machine to repair the Microsoft Visual C++ installation.

    2. Either reinstall the Windows Server Sensor or use the set token command in the Sensor CLI to authorize and configure the existing installation.

  • The Log Forwarder only collects statistics for up to 100 different log source IP addresses per Log Forwarder worker. If the total number of log source IP addresses exceeds 100, statistics for the additional log source IP addresses are aggregated into the catch-all IP address of 0.0.0.0.

  • When multiple traffic filters are defined for a tenant with the same combination of IP address, port, protocol, and layer 7 rules, the filter might fail to take effect. If this happens, review the defined traffic filters and make sure there are no duplicate definitions.

  • If you change the network interface configuration of a sensor VM after deployment, the eth0 interface might be remapped to a new interface. If this happens, the management network is disconnected. Contact Stellar Cyber Customer Success for assistance.

  • The Sensor content type for the Cybereason connector requires the System Admin role and Sensor Admin L1 role (if your Cybereason environment uses sensor grouping) to collect.

  • Due to an ongoing issue with the Cybereason Query Sensors API, the Cybereason connector might not always be able to retrieve host IP addresses, resulting in missing host information in alerts and incomplete case correlation.

  • When a new tenant is onboarded, the rare-type alerts (anomaly_tag:rare) triggered from Private/Public to Private/Public Exploit Anomaly, Scanner Reputation Anomaly, External / Internal Non-Standard Port Anomaly, Carbon Black:XDR Anomaly, and CylanceOPTICS:XDR Anomaly may have an unusually large days_silent and a higher than usual fidelity. This issue will be addressed in a future release.

  • If you use a Cynet connector to perform a Contain Host or Shutdown Host on a host that is already disabled, shutdown, or otherwise not reachable, Cynet returns a status that the request was successful which is reported in the Stellar Cyber UI. If you are not certain whether an action was successful, you may verify it in the Cynet dashboard.

  • Operators are enabled in pick list menus when they are supported with the selected field or rule. For this reason, use the menu-based queries rather than the Search keyword field with these operators. Examples include contains, does not contain, and is operators. Additional fields/rule support will be added in the future.

  • Log Forwarder only collects statistics for limited different log source IP addresses per Log Forwarder worker. If the total number of log source IP addresses exceeds the limit, the additional log source IP address statistics will be aggregated into a catch-all IP address of 0.0.0.0. Note: In releases prior to 5.1.1, the limit had been 100 sensors, but it was increased to 200 sensors with more than 8 GB of memory in the 5.1.1 release.

  • When a modular sensor is configured as a Log Forwarder-only sensor (Network Traffic and other features are not enabled), the Log Forwarder might periodically restart if there isn't enough sensor memory. Stellar Cyber recommends that the sensor memory (in GB) be at least 1.5 times the CPU core number. For example, if the sensor has a total of 8 cores, the sensor should have at least 8 * 1.5 = 12 GB of memory.

  • 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.

  • When multiple traffic filters in different tenants are defined with the same combination of IP, port, protocol, and layer 7 rules, the sensor only takes the filter belonging to the same tenant with the sensor and ignores the others. Administrators should review the defined traffic filters and avoid creating duplicate definitions.

  • Files might 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.

  • If you change the network interface configuration of a sensor VM after deployment, the eth0 interface might be remapped to a new interface. If this happens, the management network becomes disconnected. Contact Customer Success for assistance.

  • If you configure a sensor aggregator using its hostname instead of its IP address, you can not see the aggregator in the Sensor List. This does not affect the sensor's ability to communicate with the DP through the aggregator.

  • Deleting Elasticsearch data from the Root Tenant in the System | Data Management | Advanced tab deletes data from sub-tenants as well.

Upgrading the Stellar Cyber Platform

You can upgrade the Stellar Cyber Platform from 4.3.7 or later to 5.3.0. You must:

  • Prepare for the upgrade

  • Upgrade the Stellar Cyber Platform to 5.3.0

  • Upgrade the sensors

  • Verify the upgrade

For more detailed instructions, refer to Upgrading Software.

Prepare 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

Upgrade the Stellar Cyber Platform to 5.3.0

To upgrade the Stellar Cyber Platform to 5.3.0 from a version earlier than 4.3.7, first upgrade to 4.3.7.
  1. Select Admin | Software Upgrade.

  2. Choose 5.3.0.

  3. Select Start Upgrade.

Upgrade the 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 sensors with the Sandbox and IDS features enabled before sensors with the only the Network Traffic feature enabled. Sensors with Network Traffic enabled send data to sensors with Sandbox and IDS enabled for additional processing.
  • Upgrade sensors in batches instead of all at once.
  • For server sensors (agents):
    • 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 server sensors.
    • Because Windows Server Sensors running 5.1.0 do not support sensor profiles that contain text in Unicode but Windows Server Sensors running 5.1.1 or later do, if you want to use Unicode in your sensor profiles, be sure to upgrade to 5.1.1 or later before downloading any profiles with Unicode to your Windows Server Sensors.

To upgrade Linux or Windows Server Sensors:

If you are upgrading a Windows Server Sensor, complete any pending updates for the host Windows machine before upgrading the Server Sensor.

  1. Select System | Sensors.

    The Data Sensor List appears.

  2. Select Software Upgrade in the Manage dropdown.

    The Data Sensor Software Upgrade page appears.

  3. Choose the target software version.

  4. Choose the target sensors.

  5. Submit.

Verify 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.