Stellar Cyber 4.3.2 Release Notes

Stellar Cyber 4.3.2 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.3.2 Preview Video

Highlights

  • Introduced new connectors that collect logs from Symantec Email Security.cloud, Symantec Cloud Workload Protection, and Cloudflare.

  • Renamed Traffic Filters as Custom Applications and Traffic Filter Tags as Application Groups.

  • Introduced alert coverage for Barracuda WAF and Windows Defender Antivirus.

  • Added Google Cloud Storage as a supported Data Sink.

  • Critical alerts are now defined as alerts with an Alert Score greater than or equal to 75.

Behavior Changes

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

  • Review field changes in the Parser Enhancements section below.

  • Improved the counting accuracy of per-tenant daily data volume reported in System | Licensing. These changes may result in increases or decreases for some tenants to more accurately reflect their actual usage.

  • For usability, the traffic filtering options have been reorganized and renamed as indicated in the table below. Note that Tags previously referring to sets of applications are now referred to as Application Groups. Tags you apply to events are unchanged.

    < 4.3.1

    4.3.1

    4.3.2
    Collect > Data Filters > Log Filters Collection > Data Filters>Log Filters Collection> Log Filters

    Collect> Data Filters> Traffic Filters

    Collection> Data Filters>Traffic Filters

    Collection> Traffic Filters>Applications

    Configure>Other>Tag Management

    System>Configuration>Tags

    Collection> Traffic Filters>Application Groups

  • Changed the definition of a critical alert to indicate an alert with an Alert Score of 75 or greater. In previous releases, critical alerts were those with a Fidelity Score of 75 or greater.

  • Stellar Cyber uses the following categories consistently throughout the user interface to group alerts based on their Alert Score:

    Alert Category

    Definition
    Critical Alert Score ≥ 75
    Major Alert Score ≥ 50 and < 75
    Minor Alert Score ≥ 25 and < 50

    Notice

    Alert Score < 25

  • This release also introduces categories for Fidelity Scores, as follows:

    Alert Fidelity Category

    Definition
    High Fidelity Fidelity Score ≥ 75
    Other Fidelity Fidelity Score < 75

    Incidents are also marked as Critical / non-Critical in the home dashboard. This functionality is unchanged from previous versions, and is as follows:

    Incident Category

    Definition
    Critical Incident Score ≥ 75
    Non-Critical Incident Score < 75

  • Tuned fidelity scores for the following alert types based on security research. The fidelity is used in the calculation of alert scores, so a changing fidelity will change the overall alert score.

    • Fidelity scores are tuned down for:

      • External/Internal User Agent Anomaly

      • External/Internal Firewall Policy Anomaly

      • Uncommon Application Anomaly

      • Uncommon Process Anomaly

    • Fidelity scores are tuned up for:

      • External/Internal Scanner Behavior Anomaly

      • External/Internal Non-Standard Port Anomaly

      • Private to Private Exploit Anomaly

      • Private to Public Exploit Anomaly

      • Public to Private Exploit Anomaly

      • Public to Public Exploit Anomaly

      • WAF Rule Violation Anomaly

      • Carbon Black:XDR Anomaly

      • CylanceOPTICS:XDR Anomaly

    Due to model data changes, the 4.3.2 upgrade will immediately trigger retrain for the above alert types. The retraining window will not be noticeable to the user and there will be no gap in alert coverage.

Sensor Improvements

Introduced a new create sensor_clone_template CLI command that temporarily removes the Engine ID from a Linux Server Sensor so that it can be shut down, cloned, and then restarted. Both the source Server Sensor and each of the clones receive new, unique Engine IDs when they are restarted.

Parser Enhancements

  • Introduced new parsers for

    • NetApp logs

    • MONITORAPP AI WAF logs

    • Extreme AirDefense logs

    • ExtremeCloud IQ  Site Engine logs

    • SECUI MFD logs

    • Avaya Switch logs

    • VMware vCenter logs

    • Lepide Logs

    • Windows System Security logs

  • Supported new log format in the Fortigate Analyzer parser

  • Improved the Cisco Firepower parser to cover more log types

  • Enhanced the Cisco Custom VPN parser as follows:

    • Logs that contain 5-tuples are now stored in the Traffic index. Other logs are sent to the Syslog index.

    • Renamed the log.syslog.pri field to log.syslog.priority.

    • Moved the group, user_name, and srcip fields to cisco.tunnel.groupname, cisco.tunnel.username, and cisco.tunnel.ip.

  • Updated the Juniper SSG parser and changed the appid_name field to vendor.service.

  • Enhanced the F5 Silverline parser with normalized field msg_origin.category:

    • waf for the waf log

    • firewall for the other logs

  • Enhanced the Accops parser as follows:

    • Supported more log types.

    • Added a dev_class field with a value of accops.

    • Added a msg_origin.category field with a value of vpn.

    • The error-report record will only have the following fields: dev_type, parser_raw_msg, parser_err_msg, and timestamp.

    • The log.syslog.time_str field will appear only when the syslog timestamp can be parsed to an epoch.

  • Improved the Barracuda firewall parser to cover more types of WAF logs.

    • Moved the service field into the vendor namespace for the NGWF logs in the Barracuda firewall parser.

    • Enriched many fields for WAF logs in the Barracuda firewall parser to support the WAF Internal Attacker alert.

    • Enriched field “proto” as follows: 1 (ICMP), 2 (IGMP), 6 (TCP), 17 (UDP).

  • F5 WAF fields are also now populating the standardized set of fields used by Barracuda WAF, to support more general analysis in the future. The traditional F5 field labels will remain in place for backward compatibility.

  • Updated the Netflow parser to include an in_pkts field.

  • Moved the host field to hostip_host in the F5 Big-IP, Nginx, Cisco Meraki, VMware, Cylance Protect, Cylance Optics, and Forescout log parsers.

  • Moved the location field to the vendor-specific in the Symantec Endpoint Protection log ingestion.

  • Moved the status field to the vendor-specific namespace in Cisco ASA, Forescout, and Netscaler log ingestions.

  • Added TCP/TLS support for Symantec Endpoint and Cisco Meraki log ingestions.

  • Moved the field service to vendor namespace in Fortinet FortiGate and Centrify log ingestion.

  • Supported field inkpts_total in Netflow log parser.

  • Enhanced the Cisco IronPort parser:

    • Renamed the log.syslog.pri field to log.syslog.priority and changed it to an integer data type.

    • Renamed the syslog_timestamp field to log.syslog.timestamp.

    • Renamed the event_timestamp field to event.timestamp.

  • Logs that contain 5-tuples are now stored in the Traffic index. Other logs are sent to the Syslog index.

  • Enhanced the ForeScout parser:

    • Moved the severity field to the vendor namespace.

    • Changed the data type of the log.syslog.priority field to integer.

  • Updated the Mcafee Network Security log parser by changing the data type of fields scrport and dstport to integer.

Connector Enhancements

  • Introduced a new connector that collects events from Symantec Email Cloud Security.

  • Introduced a new connector that collects events from Symantec Cloud Workload Protection.

  • Introduced a new connector that collects logs from Cloudflare.

Detection/ML Improvements

  • Introduced support for mapping Windows Defender Antivirus alerts to Stellar Cyber XDR alerts, with data normalization, enrichment, and deduplication.

  • Enhanced the WAF Rule Violation and WAF Internal Attacker alerts to cover both Barracuda WAF and F5 WAF.

  • Improved the External/Internal SMB Username Enumeration alert accuracy by rotating out login events with old usernames. With this improvement, a customer may see fewer alerts from this Alert Type, and the list of usernames in the alert record may have fewer items.

  • Improved the performance of Geolocation-based alerts and the accuracy with updated distance calculation in the Geolocation model.

Platform Enhancements

  • Added Google Cloud Storage as a supported Data Sink type.

  • Configurations are backed up to the local disk automatically on a daily basis and a maximum of four copies are kept.

Usability Improvements

  • Under System | Traffic Filters, Traffic Filters are renamed as Custom Applications and Traffic Filter Tags are renamed as Application Groups.

  • Added a new Last Activity column in the System | Connectors table to indicate the last time connectors successfully retrieved logs using third-party APIs.

  • Introduced a new Ingestion Dashboard that gives detailed ingestion visibility on sensors, connectors, and log sources. Both bytes per day and average daily bytes over the last 30 days are shown for each data source. This report helps admins and operational analysts understand the ingestion contributions from various data sources.

  • The Alerts table now includes a new High Fidelity column that shows the number of alerts detected for the corresponding alert type with a Fidelity Score of 75 or greater.

Critical Bug Fixes

  • Fixed a defect that a traffic filter with both source IP and destination IP/port could not be successfully applied because of interfering flows that share the same destination IP.

  • Fixed an issue in Azure Eventhub connector that prevented different content types to be collected in parallel.

  • Fixed the issue that incident scores were not updated when new alerts were added to the incident.

  • Upgraded the Tenable.sc connector to work with Tenable.sc 5.20.

  • Fixed the issue that router assets were not included in the CIS Control 1 - Inventory of Hardware Assets Summary report.

  • Fixed a defect that prevented Windows Server Sensor from installing on Spanish Windows servers.

Known Issues

  • In the rare case when the Stellar Cyber menu options have been significantly reorganized, it is possible that administrators will need to review settings for their custom user RBAC profiles. For example, any changed path to User Management, Connectors, or Visualize is considered by Stellar Cyber to be a "new feature." So if you have user profiles with Behavior for New Features in Future Releases set to No Access, they will not be able to access these features. Since the menu options were significantly changed in v4.3.0, migrations from older releases to v4.3.x and beyond warrant this review.

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

  • Deleting a Data Sink Import task and then creating a new one with the same dates results in duplicate data for any pre-4.3.1 data requested by the import.

  • To prevent an inconsistent database state, make sure you delete any active Data Sink import or restore tasks before using the Clear Database option in the System | Data Processor | Data Management | Advanced tab.

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

  • During upgrade to v4.x and later, the alert type definitions are migrated to a new internal format, but the alert name remains the same in the UI. If the data you are viewing contains alerts generated from prior to the upgrade, be advised that those will be treated as separate from the alerts generated by the new, migrated definition (even though the alert name appears to be the same). Optionally, rename your alerts to more easily identify alerts generated from the old definitions from those created post upgrade.

  • Use the System | Sensors | Manage | Software Upgrade feature to upgrade Windows Server Sensors running 3.7.x and later to 4.3.1. Although you can use the System | Agents | Windows page to download MSI and/or MST files for Windows Server Sensor installations, these files should only be used for fresh installations and reinstallations and not for upgrades.

  • Currently, administrators need to use the Stellar Cyber UI to upgrade existing 4.2.2 Windows agent sensors to version 4.3.2. Download the GPO configuration in UI System | Agents | Windows only for new sensor installation or sensor re-installation.

  • You cannot delete a Data Sink that has an active import or restore in the Data Sink Import or Data Sink Restore tabs. Delete any active import/restore tasks for the data sink, wait at least ten minutes, and then delete the data sink.

  • With improvements made to the table management, some saved columns may not appear and users need to readjust columns.

  • Log Forwarder only collects statistics for up to 100 different log source IPs per Log Forwarder worker. If the total number of log source IPs exceed 100, the additional log source IPs' statistics will be aggregated into a catch-all IP “0.0.0.0”.

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

  • For deployments with HTTP proxy configured for Sensors or Data Processors, note that the vendor APIs Stellar Cyber relies on for the following connectors do not support communication through a proxy: Proofpoint, Cisco Umbrella, VMware Carbon Black, Duo Security, Tenable.io, Prisma Cloud, AWS Cloudtrail, BlueCoat WSS, Proofpoint on Demand and Azure Event Hub.

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

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

Upgrading

You can only upgrade Stellar Cyber from 4.2.x or 4.3.x to 4.3.2. 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.3.2

To upgrade the DP to 4.3.2 please first upgrade to 4.2.x or 4.3.x

  1. Click Admin |Software Upgrade.

  2. Choose 4.3.2.

  3. Click Start Upgrade.

 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 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-based or Windows-server sensors:

  1. Click System | Sensors. The Data Sensor List appears.

  2. Click 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. 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.