Stellar Cyber 5.0.3 Release Notes

Updated June 23, 2023

The Stellar Cyber SaaS 5.0.3 release brings the following improvements to the Stellar Cyber Open XDR platform. For detailed information, refer to the Stellar Cyber online documentation.

Highlights

• Introduced the Notification Center and System Action Center for showing the system notifications of the following categories and configuring rules for monitoring those notifications:

  • License Enforcement

  • License Usage

  • Connector Performance

Behavior Changes

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

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 5.0.3, as well as duplicates triggered from the Microsoft 365 alert integration. The duplicates will be removed in a later release.

• The 4.3.6 and 5.0.3 releases begin 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 and 5.0.3.

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

Critical Bug Fixes

• Fixed: Resolved Sophos connector configured, but not receiving data.

• Fixed: Resolved AWS Cloudtrail connector with subtype vpcflow configured, but not receiving data.

Detection/ML Improvements

The following enhancements were introduced in 4.3.6 and now are available in 5.0.3.

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.

• 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

• Introduced the Notification Center and System Action Center for showing the system notifications of the following categories and configuring rules for monitoring those notifications:

  • License Enforcement

  • License Usage

  • Connector Performance

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

• Added a new API for Incident observables.

Connector Enhancements

The follow enhancements were introduced in 4.3.6 and are now available in 5.0.3:

• Enhanced the SentinelOne Connector for better rate limiting handling to reduce overall errors.

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

Known Issues

• 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 do not 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 from 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 is not installed already. If the installation of Visual C++ fails, the Windows Server Sensor may be unable 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.

• 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, statistics for the additional log source IPs 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, 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.

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

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 in batches instead of all at once.

• For Server 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 Server Sensors.

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