Stellar Cyber 4.3.6 Release Notes

Updated February 20, 2024

The Stellar Cyber 4.3.6 release brings the following improvements to the Stellar Cyber Open XDR platform. For detailed information, refer to the links in the text below.

Highlights

• Introduced a new Sigma Rule Engine supporting detection rules in the Sigma format.

• Introduced multiple third-party alert integrations.

• Introduced File Integrity Monitoring by Windows server sensors.

Actions Required

• The following CLI commands used to configure Port Relay settings in 4.3.5 no longer work in 4.3.6:

  • set logforwarder device-ip

  • unset logforwarder device-ip

  Before upgrading sensors from 4.3.5 to 4.3.6, use the show logforwarder port-ingestion command to check whether they have Port Relay settings configured in the CLI. For those that do, use the instructions in Migration Steps in Ingesting Logs to move their port relay configuration from the 4.3.5 CLI to the Log Sources page in the 4.3.6 user interface.

• Before upgrading network/security/modular sensors to 4.3.6, additional firewall settings are needed to allow software to be downloaded from the following public domains. Refer to Firewall Requirements for more information.

  • archive.ubuntu.com

  • security.ubuntu.com

  • esm.ubuntu.com

  • ppa.launchpad.net

  • dl.stellarcyber.ai

Behavior Changes

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

• When an ATH playbook has an All Tenants association, only connectors, email recipients, and scripts configured in Root tenant are available for actions. In previous versions, connectors in any tenant can be selected. Execution of existing ATH playbooks are not affected.

• Set a one-year retention for Stellar Cyber Incidents. Incidents that have not been updated with new alerts for over a year are now deleted.

• In SER records, the event_name field is deprecated and is replaced by xdr_event.name. In 4.3.6, the event_name field is dropped in the following alerts:

  • Outbytes Anomaly

  • Abnormal Parent / Child Process

  • DNS Tunneling Anomaly

  • Outbound Destination Country Anomaly

  • External / Internal User Agent Anomaly

  • Application Usage Anomaly

  • External / Internal User Application Usage Anomaly

  • External / Internal User Data Volume Anomaly

  • User Asset Access Anomaly

  • User Process Usage Anomaly

• In SER records, the srcip2 field is mapped to IP type so that one can use CIDR notation to filter alerts.

• In AWS Cloudtrail logs, the requestParameters field has moved to requestParameters_str.

• Enhanced the Sophos Central and VMware Carbon Black connectors to discover assets from security logs.

• Updated the Windows Server Sensor event normalization. Sysmon Event ID 1 field event_data.Hashes is replaced with three individual hash fields. Existing dashboard and queries referring to event_data.Hashes should be updated.

• In System | Settings | Authentication Settings, it is mandatory to include http:// or https:// in the Issuer URL field.

• In previous releases, Stellar Cyber categorized all logs from sensors with a log source of sensor. Starting with 4.3.6, Stellar Cyber replaces the previous sensor log source with different categories for each sensor type (network_sensor, linux_agent, security_sensor, windows_agent, or modular_sensor). As a result of this change, the Top Log Sources graph in the Investigate | Threat Hunting view does not show any 4.3.6+ log sources under the sensor category. Only logs from pre-4.3.6 sensors appear in this category.

  In addition, any queries configured to use the sensor log source must be reconfigured to use the new categories in order to work with 4.3.6+ sensors.

  The image below shows the new log source categories for different sensor types:

  

Deprecations

• The following alert types are being deprecated because they are now covered by the Microsoft 365 alert integration:

  • Office 365 Access Governance Anomaly

  • Office 365 Blocked User

  • Office 365 Data Exfiltration Attempt Anomaly

  • Office 365 Data Loss Prevention

  Note that there will still be alerts triggered from these four alert types in 4.3.6, as well as duplicates triggered from the Microsoft 365 alert integration. The duplicates will be removed in a later release.

• The 4.3.6 release begins to replace the External / Internal User Agent Anomaly alert types with new External / Internal Suspected Malicious User Agent alert types, switching them from an unsupervised model to a supervised model in the process. Note that the existing External / Internal User Agent Anomaly alert types are still viewable in 4.3.6.

• The Company Trends page, under Visualize | Predefined is deprecated. The page will be removed in the upcoming 4.3.8 and 5.1.0 releases.

• The Visualize | Predefined | Legacy Kill Chain dashboard is no longer available. Use the XDR Kill Chain home page introduced in 4.1 instead.

Critical Bug Fixes

• Fixed: A sensor’s engid is changed without any configuration change by users.

• Fixed: IDS/Malware events captured in VLANs are associated with the wrong sensors.

• Fixed: Alerts are triggered for Microsoft Office 365 login events with username Not Available. Alerts should be suppressed for events of user type UserType4.

• Fixed: A Windows server sensor does not recover after network communication with the Data Processor is interrupted for an extended period.

• Fixed: Cannot reset the password of a tenant user when the tenant authentication is local and the global authentication is SSO.

• Fixed: Modular sensor process allow_flow frequently restarts after a fresh deployment.

• Fixed: A Sophos Central connector stops working after changing the Content Type in the configuration.

• Fixed: An ATH webhook may fail because of a short timeout.

• Fixed: The ids.signatures are not seen on the Exploited C&C alert page.

• Fixed: A scheduled report is affected by the built-in event_status filter. The solution is a new option to disable the global event_status filter in the Chart Builder.

• Fixed: The Run Script action cannot be triggered in ATH when many actions are scheduled.

• Fixed: Logs are dropped in a sensor due to an insufficient buffer.

• Fixed: Nested aggregation does not work in an ATH playbook.

• Fixed: On a Windows server, filtering on event IDs may not work due to a processing bug.

• Fixed: The Ingestion Dashboard does not list all log sources.

• Fixed: Japanese fonts are not properly installed and displayed.

• Fixed: The Exclude event ID 0 option in a Windows server sensor profile does not take effect.

• Fixed: A Hillstone connector response can fail due to a bug in API authentication.

• Fixed: Juniper SRX logs are not parsed properly and sent to the Traffic index.

• Fixed: Queries based on event_type_id in Threat Hunting do not work properly due to an incorrectly assigned data type.

• Fixed: Data corruption in the event of DL-master failover due to incomplete data replication configuration.

• Fixed: The incident score change event threshold was reset after a service restart. The defect could lead to excessive custom alerts from custom ATH rules.

Detection/ML Improvements

New Sigma Rule Engine and Rule Alert Types

• Introduced a new Sigma Rule Engine, supporting detection rules in the Sigma format. The first batch of rule-based alert types include:

  • Suspicious PowerShell Script alert with 140+ built-in Sigma rules.

  • Suspicious Process Creation Commandline alert with 200+ built-in Sigma rules.

  • Every alert triggered from the rule-based alert types comes with an alert subtype showing the title of the triggered rule and a link to the KB entry with more details.

  • Introduced a new stellar.rule_id alert field for searching and filtering alerts triggered by built-in Sigma rules.

• Abnormal Parent / Child Process alerts can now be triggered independently from either an ML model or 60+ built-in Sigma rules:

  • If triggered from an ML model, the alerts have an alert subtype of Machine Learning Anomaly Detection.

  • If triggered from built-in Sigma rules, the alerts have an alert subtype of the triggered rule's name.

    The full list of rules triggering this alert type can be found in the following KB article: Rules Contributing to Parent/Child-based Suspicious Process Creation Alert.

New and Improved ML Alert Types

• Introduced the External / Internal IDS Signature Spike alert types where the amount of unique IDS signatures with their severities are periodically calculated per source host. If there are any spiky behaviors in the data pattern, a corresponding IDS Signature Spike alert is triggered.

• Introduced new External / Internal Password Spraying ML alert types for password spraying attacks in Windows.

• Replaced the External / Internal User Agent Anomaly alert with External / Internal Suspected Malicious User Agent. The User Agent Anomaly alert will continue to exist as an alert type for compatibility but no further alerts of that type will be generated.

  • Introduced a new stellar.confidence alert field in the External / Internal Suspected Malicious User Agent alert. This field indicates the classifier's confidence in the prediction used to make the alert. It is not the same as Fidelity, although it does factor into the fidelity score. Alerts with lower fidelity scores will still have relatively high values for confidence.

• Introduced a port scan alert type based on a connection spike in firewall and Windows logs. The External / Internal IP / Port Scan Anomaly now has two subtypes:

  • Connection Failure Anomaly based on Sensor traffic

  • Connection Spike Anomaly based on firewall and Windows traffic

• Enhanced the Application Usage Anomaly alert as follows:

  • Improved the ML model. Once deployed, the ML first queries 14-day data and then starts training. The training phase can take several hours. Once the model is trained, it is retrained every week by querying the past 14-day data.

  • Reduced the false alert rate and improved detection fairness to enhance detection of anomalous applications with low traffic that may not have been previously reported.

  • Improved the alert presentation to provide an intuitive explanation in the alert description.

• Improved the Outbytes Anomaly and External / Internal User Data Volume Anomaly alerts by separating firewall and non-firewall data sources.

• Improved the Login Time Anomaly alert to use event_data.TargetUserName as the detected field for Windows logins. The existing model values will be preserved so there will be no downtime from the upgrade. This addresses an issue where srcip_usersid is unintuitively used to track logins because it is not derived directly from the login event and is different from the login username in some cases. Non-Windows logins are unchanged.

• Improved the User Login Failure Anomaly and Account User Login Failure Anomaly alert types to reduce false positives.

• Improved the Abnormal Parent / Child Process, Outbound Destination Country Anomaly, User Application Usage Anomaly, and User Process Usage Anomaly alert types to reduce false positives.

• Improved the Sensor Data Ingestion Anomaly alert type on Windows server sensors to reduce false positives.

• Addressed false Abnormal Parent / Child Process and Uncommon Process Anomaly alert types by removing alerts related to Stellar Cyber processes.

Other Detection Improvements

• Enhanced alert enrichment to support multiple Tactics, Techniques, and Procedures tagging.

• Introduced a new related_alert key field to the External / Internal Brute-Forced Successful User Login alert to link to the related User Login Failure alert. When finding the original records of the detection, failed logins that contributed to the related User Login Failure Alert are included.

• Enhanced the following alerts by including both failed and successful logins in the original records:

  • External User Login Failure Anomaly

  • Internal User Login Failure Anomaly

  • Internal Account Login Failure Anomaly

  • External Account Login Failure Anomaly

  • Account MFA Login Failure Anomaly

• Added an engid_gateway key field to the Impossible Travel alert.

• Added a src_host key field to the External Firewall Denial Anomaly alert.

• Enhanced the detection for Windows logs collected from the NXlog parser. This feature requires customized NXlog configuration. Refer to Configuring NXLog for HostIP Field for details.

• Allowed alerts to be made from logs collected by the Windows server sensor on a Windows Event Collector (WEC) server by improving the integration in the Active Directory (AD) connector.

• Due to the underlying detection algorithm changes, the following existing alert types will retrain their models after the 4.3.6 upgrade with data from the past 14 days prior to the upgrade:

  • Application Usage Anomaly

    After retraining, new alerts will show a different set of metadata fields reflecting the new underlying algorithm logic, including a stellar.threshold field indicating the actual threshold the algorithm calculates for the alert.

  • Uncommon Process Anomaly

    After retraining, days_silent in new alerts will reset to start from 14 days prior.

  • Sensor Data Ingestion Anomaly

Usability Improvements

• Allowed an administrator to create a Disable User action directly in the User Actions page.

• Added port relay configuration to the System | Collection | Log Sources page in the user interface so that logs from multiple products can be received and parsed on a single TCP/UDP port in a Stellar Cyber Network, Security, or Modular sensor.

• Enhanced the ATH Webhook action configuration to support @ and . in usernames and passwords.

• Introduced the following new built-in dashboards in the General Reports page:

  • Executive Overview

  • Alert Categorizations

  • Operational - All Ingestion Sources

  • SLA Dashboard

Platform Enhancements

• Added OCI object storage as a supported Data Sink type.

• Introduced system monitoring with the built-in Grafana tool.

• Introduced new APIs for the provisioning and management of tenants and tenant groups.

• Added a new API for Incident observables.

Sensor Improvements

• Increased data fidelity and visibility in SMB traffic metadata by adding the ability to collect additional metadata filename and path information for SMB traffic. You may notice a small increase in ingestion as part of this enhancement.

• Added Windows event channels PortalGuard and DNS-Server/Analytical in Other Channels in the Windows server sensor profile configuration.

• Enhanced the Modular sensors to support Packet Mirroring in AWS, GCP, and OCI.

• Introduced Linux server sensor support for the following:

  • Oracle Linux 8.5

  • SUSE Linux 15 SP4

• Enhanced the Linux server sensor to monitor bonded interfaces.

Connector Enhancements

• Introduced the OCI connector to collect Oracle Cloud Infrastructure (OCI) logs.

• Introduced the Thinkst Canary connector to collect audit logs.

• Introduced the Indusface connector to collect Indusface WAF logs.

• Enhanced the Microsoft Defender for Endpoint connector to support the Contain Host action.

• Enhanced the Azure Event Hub connector to collect custom content types.

• Improved the Azure AD connector with memory usage optimization.

• Improved the AWS Cloudwatch connector with performance optimization.

• Enhanced the AD connector to automatically collect computer assets. This enhancement allows alerts to be made from Windows events collected from a WEC server.

Parser Improvements

• Introduced a new built-in log parser for Extreme Controller NX 7500.

• Introduced a new built-in log parser for ServiceNow NowPlatform.

• Introduced a new built-in log parser for Ruckus ZoneDirector 1200.

• Introduced a new built-in log parser for Peplink.

• Introduced a new built-in log parser for Centos Audit Log.

• Introduced a new built-in log parser for Perception Point X-Ray.

• Introduced a new built-in log parser for Apache HTTP Server.

• Introduced a new built-in log parser for Oracle Solaris Syslog.

• Introduced a new built-in log parser for Impero Software Solutions ContentKeeper.

• Introduced a new built-in log parser for OPNsense.

• Introduced a new built-in log parser for Array Networks ASF.

• Introduced a new built-in parser for Fortinet FortiEDR 5.2.0.

• Introduced a new built-in parser for Trend Micro Tipping Point.

• Introduced a new built-in log parser for Fortinet FortiAuthenticator.

• Introduced a new built-in log parser for HanDreamnet VIPM.

• Introduced a new built-in log parser for Trend Micro Interscan Messaging. Currently the parser only supports log formats: msgtra.imss.xxxx, Polevt.imss.xxxx, sysevt.imss.xxxx, and others.

• Enhanced the CEF parser as follows:

  • Moved fields clapp, sourceservicename, requestclientapplication, requestmethod, and postbody to vendor-specific in Incapsula CEF log parsing.

  • In the Imperva/Incapsula CEF log parsing, when the Vendor and Product of the CEF headers are Incapsula and SIEMintegration, the fields dev_type, msg_origin.source, are changed from incapsula to imperva, the dev_class and msg_class are changed from incapsula to imperva_security_logs. When the cef_name is Normal and the cef_severity is 0, the dev_class and msg_class will be imperva_access_logs.

• Enhanced the Aqtronix Webknight parser to support new log formats.

• Enhanced the Cisco Meraki parser with IDS event detection enrichment.

• Enhanced the Hillstone parser to support new log formats.

• Updated the Wazuh parser as follows:

  • Normalized wazuh.agent.ip to hostip.

  • Normalized wazuh.agent.name to hostip_host.

  • Normalized event_data.parentImage to parent_proc_name when event_id is 1.

  • Normalized event_data.user to srcip_username and hostip_username when event_id is 1.

  • Normalized data.win.IpAddress to srcip.

  • Normalized agent.ip to srcip if data.win.IpAddress does not exist.

  • Normalized agent.ip to dstip.

• Enhanced the Fortinet Fortigate parser to support new log formats.

• Enhanced the Barracuda Web firewall parser to support new log formats.

• Enhanced the NXLog parser to support new log formats for Apache Tomcat Server logs.

• Updated the Cisco Firepower parser as follows:

  • Added new log format support.

  • Normalized protocol and proto_name field to proto.

  • Removed the multi-line log support through TCP.

• Updated the Cisco ASA parser by normalizing the severity field to cisco.severity.

• Updated the Mikrotik parser as follows:

  • Supported the new log formats.

  • Normalized protocol to proto.

  • Normalized log.syslog.event_description to log.event_description.

• Updated the Hillstone parser as follows:

  • Normalized the field data_time to log.syslog.timestamp.

  • Moved vsys, log_msg_id, src_interface, and dst_interface, whole_flag, custom_value_1 to Hillstone namespace.

• Updated the Zscaler ZIA normalization for more accurate alerts as follows:

  • Normalized the field nwapp to appid_name.

  • Normalized the field rule_label to fw_policy_id.

• Updated the Cylance parser as follows:

  • Normalized the field Event Id to cylance.event_id.

  • Normalized the field Instigating Process ImageFileSha256 to instigating_process_imagefilesha256.

  • Normalized the field Event Timestamp to event.timestamp.

  • Normalized the field Target Process Command Line to process.command_line.

• Updated the Cisco CUCM parser as follows:

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

  • Normalized the field syslog_time to log.syslog.timestamp.

  • Normalized the field event_description to log.event_description.

  • Normalized the field event_time to event.timestamp.

  • Normalized the field username to user.name.

  • Normalized the field protocol to proto.

  • Moved the field hostname to msg_data instead of abandoned when log_hostname exists.

• Updated the Fortinet Fortigate parser as follows:

  • Supported new log formats.

  • Normalized the field ad.utmaction to fortinet.ad.utmaction.

• Enhanced the Syslogjson parser to support winlogbeat logs.

• Enhanced regex in the Barracuda Firewall parser to support new log formats.

• Improved the Juniper Switch parser to support new log formats.

• Updated the pfSense firewall parser as follows:

  • Supported Snort logs.

  • Normalized the field proto_name to proto when its value is icmp, igmp, tcp, udp, or their corresponding Protocol Numbers. Invalid proto_name will be moved into the vendor namespace.

  • Added check for the fields srcip, dstip, srcport, and dstport. They will be moved into the vendor namespace when their value is invalid.

  • Renamed vendor fields tos, ttl, and offset to tos_str, ttl_str, and offset_str.

• In the Palo Alto Networks parser, if srcip is empty, will search public_ip then public_ipv6 to fill this field.

Known Issues

• The Sensor content type for Cybereason's 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 Cybereason's Query Sensors API, the Cybereason connector may not always be able to retrieve host IP addresses, resulting in missing host information in alerts and incomplete incident correlation.

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

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

• In the rare cases when the Stellar Cyber menu options have been significantly reorganized, such as in v4.3.0, 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 or Restore 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 task.

• 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.6. 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 re-installations 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.6. 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.

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

• When a modular sensor was configured as a Log Forwarder only sensor (Network Traffic and other features are not enabled), Log Forwarder may restart periodically if the sensor memory is not enough. It is suggested 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.

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

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

• 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 Customer Success for assistance.

• Deleting the Root Tenant's ES data in the System | Data Processor | Data Management | Advanced tab, deletes unexpected tenant's data.