Stellar Cyber 5.2.0 Release Notes

Software Release Date: July 26, 2024
Release Note Updated: August 8, 2024

This release note lists and describes all the exciting improvements in the Stellar Cyber Open XDR platform in the 5.2.0 release.

The release notes are organized into the following sections:

Highlights

The 5.2.0 release introduces several key features and improvements that enhance the Stellar Cyber Open XDR platform:

Alert Enrichment and Detection

  • Enhanced alert enrichment for SMB traffic: Provides deeper insights into SMB Read/Write Anomalies.

  • Detailed IDS rule enrichment: Adds comprehensive threat intelligence for various exploit anomalies.

  • New ML alert type for abnormal Windows account password resets: Enables proactive security measures.

  • Customizable time ranges for correlation: Provides customization of the correlation window in which new events are associated with an existing case, allowing more granular tuning of alerts and notifications and improved detection of slow-rate attacks and short-term user accounts.

  • File Hash Enrichment: Provides more details on file hashes for Threat Intelligence.

Reporting and Visualization

  • Faster alert reporting: Improves response times for Impossible Travel Anomaly and User Login Location Anomaly.

  • Enhanced case analysis graphs: Offers clearer visualization of complex attack scenarios.

  • Refined correlation strategy: Ensures every alert is assigned to a case.

Integrations and Standards

Usability Enhancements

  • Usability enhancements: Includes new case management dashboards, bulk actions, visibility into enriched fields, and enhanced observable insights, enabling faster triage and investigation of alerts as part of a case.

  • Data visibility improvements: Features human-readable JSON timestamps and automatic log parser sync.

  • Field Customization: Introduces key field customization for alerts created from Automated Threat Hunting (ATH) rules, empowering analysts with easier access to critical context information.

Platform and Infrastructure

  • Product Roadmap Portal: Introduces a new product roadmap portal where you can request features and bug fixes, view and comment on others' requests, and vote for features you want to prioritize.

  • Platform enhancements: Adds new API endpoints and single sign-on with Rippling to automate tasks and simplify user management.

  • Sensor and connector enhancements: Introduces new ingestion ports and expanded connector support.

  • System Action Center: Enhances the System Action Center with Slack responses and many new rule types.

Data Processing and Parsers

  • Data processor improvements: Offers tailored threat detection and increased context accuracy.

  • New and improved parsers: Broadens the range of log sources monitored for more accurate threat detection and comprehensive security solutions.

Actions Required

  • If you're using the Duo Security connector, update any custom Automated Threat Hunting (ATH) rules that use Duo Security fields to instead use the "duosecurity" namespace. For more information, see AELDEV-45957 in Improvements: Connectors.

  • Update any egress firewall rules to allow Network Time Protocol (NTP) traffic on UDP port 123 to the updated list of NTP servers.

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

Behavior Changes

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

  • If any uses of the public API rely on the API layer to add parameters automatically (such as global case settings, for example), they must be updated.

  • The srcip_type and dstip_type fields in documents might have a change of value based on srcip and dstip MAC address values.

  • The alert types with Azure AD have been renamed to Microsoft Entra ID. This change only applies to the display name of the affected alert types (xdr_event.display_name). The internal event name (xdr_event.name) remains unchanged. The following alert types have this name change: Azure AD Apps Modified To Allow Multi-Tenant Access → Microsoft Entra Apps Modified To Allow Multi-Tenant Access, Azure AD Custom Domains Changed → Microsoft Entra Custom Domains Changed, and AzureADRiskDetection → Microsoft Entra RiskDetection (third-party alert integration) This name change also applies to alert descriptions and other display strings in alerts and rules.

  • Trend Micro Apex Central CEF parser – deviceprocessname is moved from msg_data to the vendor field.

  • McAfee Firewall parser – Unsupported values in the protocol field are moved into vendor namespace while those with supported values are still normalized as proto.

  • Netflow parser: This parser no longer puts all the fields into msg_data. Except for the srcip, dstip, srcport, dstport, proto, inbytes_delta, and inpkts_delta fields, all other fields are now under netflow.

  • Barracuda Firewall parser – proto_name is normalized into proto when possible.

  • Mako Networks Firewall parser – A proto: <proto-name> key-value pair is parsed as proto: <proto-name> when the value is icmp, igmp, tcp, or udp. Any other value is stored under vendor namespace.

  • Mako Networks Firewall parser – The action field moved from the msg_data to the top level.

  • Ubiquiti UAP-AC-Pro parser – The whole message part is kept in the log.event_description field for wcad logs.

  • Ubiquiti UAP-AC-Pro parser – The ubiquiti.wevent_type field is renamed as ubiquiti.event_type.

  • ProofPoint parser – The following key list was added: ["process_name", "process_id", "s", "m", "x", "mod", "cmd", "rule", "dkimresult", "spfresult", "duration", "value", "routes", "rcpt_routes", "rcpt_notroutes", "data_routes", "data_notroutes", "to", "delay", "xdelay", "mailer", "tls_verify", "tls_version", "cipher", "pri", "relay", "dsn", "stat", "from", "size", "class", "nrcpts", "msgid", "proto", "daemon", "auth", "version", "verify", "bits", "reply", "ctladdr", "STARTTLS", "msg"]

  • Any fields that come from key-value pairs that aren't in the list are stored in msg_data.

  • Sophos Firewall parser – device is normalized into sophos.device.

  • Cisco Meraki parser – device is normalized into cisco.device.

  • The schema for the PUT /connect/api/v1/users/{id} API endpoint no longer requires the name field as of the 5.2.0 release. Existing API requests that include the name field will not break in 5.2.0. The name field is simply ignored if included in a PUT or PATCH request to the users API endpoint.

  • Users should no longer be configured with duplicate email addresses. Currently, the username and email addresses are discrete fields, with the former being the unique identifier. In an upcoming release, these fields will be consolidated with the email address field becoming the unique identifier for a user. Administrators should begin updating their user accounts to ensure no two users have the same email address.

  • In previous releases, the names of applications and protocols appeared in the user interface in uppercase, mixed case, and lowercase formats, sometimes resulting in multiple similar entries differing only by case. For example, syslog, SYSLOG, Sylog, SysLog. To reduce the number of entries, Stellar Cyber now combines them into one entry with a lowercase name: syslog, SYSLOG, Sylog, SysLog → syslog. A possible exception to the use of lowercase application names is user-configured custom applications (System | Traffic Filters | Custom Applications). For custom applications, Stellar Cyber displays the name in whatever case the user defined it

Deprecations

  • The Company Trends page is no longer available.

  • Azure Security Center was renamed and this content type is deprecated from Azure Event Hub connector.

  • The Sophos alert type for Malware on Disk, which also has a detection for Windows Defender for Endpoint, is deprecated. The new Sophos alert integration covers the same alerts.

  • The normalization fields sha256, group, and threat are deprecated and will be changed in a future release.

Critical Bug Fixes

Detection/ML

New Features

  • Integrated Avanan alerts into the Stellar Cyber Platform. The integration supports alerts from both delivered and quarantined categories:

    • Avanan (Delivered) with the assigned technique; for example, Avanan (Delivered): Phishing
    • Avanan (Quarantined) with the assigned technique; for example, Avanan (Quarantined): Spam

  • Implemented a new feature that enables the ingestion of HYAS Protect logs. This integration includes support for detecting specific DNS queries to certain websites or top-level domains (TLDs). The enhancement includes new detection rules and alert types based on HYAS Protect DNS logging.

  • Added HYAS Protect logs into the existing Stellar Cyber detection of newly registered domains (alert type: Recently Registered Domains).

  • Introduced the following key enhancements:

    • Expanded Sources for IOC Ingestion: File hash IOCs are pulled from respected threat intelligence feeds including AlienVault, DHS, http://Abuse.ch Threatfox, and Emerging Threats.
    • Regular Synchronization: The ingestion process for file hash IOCs is synchronized on a regular schedule. This ensures that the most current and relevant threat data is integrated into the Stellar Cyber Platform, enhancing the timeliness and relevance of threat detection.
    • Enhanced File Reputation Functionality: Integrating these file hash IOCs into detection pipelines ,significantly improves the ability of Stellar Cyber to assess and respond to file-based threats. This leads to more accurate and effective file reputation assessments throughout the network.

  • Added Suricata IDS rule information to the alerts of the following IDS-related Alert Types in ids.rule: Private to Private Exploit Anomaly, Private to Public Exploit Anomaly, Public to Public Exploit Anomaly, Public to Private Exploit Anomaly, Internal IDS Signature Spike, and External IDS Signature Spike. These additions include instances where such alerts did not previously contain correlated IDS rule data, thus enhancing visibility and context for security analysts. The update encompasses both internal and external IDS anomaly alert types across various network traffic.

  • Added more nuanced detection capabilities to both User Login Failure and Account Login Failure alerts. The following key enhancements were added:

    • Daily Alerts During Prolonged Attacks: Stellar Cyber generates daily alerts for ongoing prolonged attack attempts, ensuring continuous monitoring and prompt response.
    • Detection of Lower Login Failure Rates: Added alerts for attack scenarios that exhibit lower rates of login failures. This enhancement helps in identifying and mitigating threats that might otherwise go undetected due to their subtlety.
    • Adaptive Alert Logic: The detection model now more effectively follows the distribution of data, which can change constantly. It accumulates scores based on user activities, and an alert is triggered if the accumulated score crosses a predetermined threshold. This dynamic approach allows for more accurate detection of anomalies over various time frames without the need for a separate training period.

  • configurable correlation timeout

    Lets you specify the time window within which new alerts are considered for correlation into both new and currently open cases.

  • Enhanced External/Internal User Login Failure Anomaly and External/Internal Account Login Failure Anomaly alert types with specific subtypes to refine detection capabilities. Original record queries were refined for better precision, allowing a clearer analysis of the raw events that contribute to an alert. This update provides finer granularity in alerts and improves the accuracy and relevance of the original records presented.

  • Improved the integration with Carbon Black alerts by ensuring that alerts without the threat_cause_category field are now mapped to the appropriate stage in the Killchain. This update enhances threat visibility and response by addressing an issue where certain alerts were previously excluded from Killchain mapping.

  • Enhanced machine learning alert types to integrate firewall IPS threat logs. Now firewall IPS threat logs contribute to alert types of Private/Public to Private/Public Exploit Anomalies, and Private/Public to Private/Public IPS Signature Spikes. The currently supported firewall IPS threat log sources are Fortigate, Palo Alto Networks, and SonicWall.

  • Implemented a new alert subtype “SMB User Based” to alert type “User Asset Access Anomaly”. This identifies unusual user-asset access patterns over SMB traffic.

  • Released new rules for Azure, sourced from SigmaHQ, to perform rule-based detection. These rules detect suspicious Azure activity using key detection fields, such as resourceId and operationName, from Azure Activity Log. The following 21 new alert types are added in this release:

    • Azure Application Gateway Changed
    • Azure DNS Zone Changed
    • Azure New CloudShell Created
    • Azure Security Configuration Changed
    • Microsoft Entra Application Deleted
    • Microsoft Entra Hybrid Health AD FS New Server
    • Microsoft Entra Hybrid Health AD FS Service Deleted
    • Microsoft Entra ID MFA Disabled
    • Microsoft Entra Owner Removed From Application
    • Suspicious Azure Account Permission Elevation
    • Suspicious Azure Deployment Activity
    • Suspicious Azure Device Activity
    • Suspicious Azure Firewall Activity
    • Suspicious Azure Key Vault Activity
    • Suspicious Azure Kubernetes Activity: Credential Access
    • Suspicious Azure Kubernetes Activity: Defense Evasion
    • Suspicious Azure Kubernetes Activity: Impact
    • Suspicious Azure Kubernetes Activity: Persistence
    • Suspicious Azure Kubernetes Activity: Privilege Escalation
    • Suspicious Azure Network Activity
    • Suspicious Azure Service Principal Activity

  • Modified UBA alert types to use write_time for querying login events, reducing detection latencies for alert types like Login Time and Login Failure. This enhancement also addresses a detection edge case where certain data sources with very long delays in reporting login events, such as several hours of delays for example, might not be always covered.

  • Added a new detection system for identifying anomalous password reset activity on Windows systems. It currently supports one subtype: Windows Account Password Reset Anomaly, which detects abnormal password resets for Windows accounts. It's aimed at spotting potential security breaches by scrutinizing password reset patterns and generating alerts for activities that deviate from the norm, thereby improving the capability to preemptively mitigate account compromise risks.

  • Threat Intelligence

    Introduced a new threat intelligence processing capability to significantly reduce the time lag between the identification of malware or threats and the ingestion of the corresponding Indicators of Compromise (IOCs). This feature is disabled by default and includes the following key enhancements:

    • Faster IOC Ingestion: Increased the speed at which threat intelligence data is processed and incorporated into Stellar Cyber, ensuring more effective threat detection and continuous monitoring.

    • Proactive Threat Hunting: The accelerated ingestion rates let security teams identify and mitigate threats more quickly, enhancing overall detection and response capabilities.

    • Custom Feed Integration with TAXII 2.0 and STIX Compatibility: Provided support for user-defined threat intelligence feeds using formats like TAXII and TSV. This enhancement leverages the TAXII 2.0 standard for seamless cyber threat intelligence exchange over HTTPS and is fully compatible with STIX 2.0. These improvements provide greater flexibility in ingesting and structuring threat intelligence to meet specific organizational needs.

  • Integrated Microsoft Defender for Cloud Apps (MCAS) into the Stellar Cyber Platform to receive alerts. This enhancement allows Stellar Cyber to receive and analyze MCAS-native alerts, enhancing visibility over potential security threats.

  • Integrated Microsoft Defender for Cloud alerts into the Stellar Cyber Platform. This enhancement allows Stellar Cyber to receive and analyze Microsoft Defender for Cloud alerts from Azure Event Hub, enhancing visibility over potential security threats.

  • Introduced the following three passthrough alerts for HYAS Protect:

    • Domain tagged with Suspicious Registrar with the alert type prefix HYAS Protect (Watch Engine)
    • Domain tagged as blocked by the HYAS Engine with the alert type prefix HYAS Protect (Block)
    • Domain tagged as Highly Suspicious with the alert type prefix HYAS Protect (Highly Suspicious)

  • When alerts are triggered from SMB traffic with path-related metadata decoded by Modular Sensors, Stellar Cyber enriches External/Internal SMB Read/Write Anomaly alert types for accessed file paths in event_summary.smb_path_list. Stellar Cyber ranks the significance of the paths—for example, system paths or user paths—by their uniqueness and access frequency during the detection period. Alerts now display significant file paths based on visit frequency and folder properties, enhancing the understanding of the alert triggers.

Improvements

Usability

New Features

  • a Case Health API endpoint

    Implemented a new endpoint, GET /cases/health, to let you check the health status of the Case API. This endpoint returns a JSON response indicating the status (working or not working) and the version of the backend. The public API always returns a 200 HTTP status code, but the response content reflects the actual state of the Case backend.

  • Implemented a feature where the modified_at field of a case is now automatically updated whenever a comment or some evidence is added, updated, or deleted. This ensures accurate tracking of case modifications and enhances API filtering capabilities for updated cases. The change does not affect case score calculations.

  • Implemented a new UI feature that allows users to set distinct time ranges for each layer within a correlation rule to address use cases such as the detection of short-term accounts. This feature facilitates the creation of more precise and effective security correlation rules by enabling time-specific queries across multiple layers.

  • query for alerts not associated with cases

    Added a new query capability that allows you to filter alerts not correlated to any cases. To enable a more efficient workflow for identifying and addressing potential security incidents, this feature supports complex case management and improved visibility into uncorrelated alerts.

  • Case Management dashboards

    Introduced a basic Case Management Dashboard to facilitate quick insight into case metrics without extensive complexity. Features include Total Case Number with a pivot on severity (line or bar chart), Case Breakdowns by Severity and Status (pie charts), Case Assignee Chart, and Case Breakdown by Alert Number (line or bar chart), complemented by a Case List table at the bottom.

  • bulk actions in the Case table

    The Case Table supports bulk edits to the Status, Tags, or Assignee of multiple cases. Once you apply a bulk action to one or more cases, Stellar Cyber displays a success or failure message at the top of the display and keeps track of its progress in the Task List.

Improvements

Stellar Cyber Platform

New Features

Improvements

Sensors

New Features

Improvements

Connectors

New Features

Improvements

Parsers

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.

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

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

  • To upgrade Windows Server Sensors, use the software upgrade feature (System | Sensors | <sensor-name> | Manage | Software Upgrade) . 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 but not for upgrades.

  • Currently, administrators need to use the Stellar Cyber UI to upgrade existing 4.2.2 Windows agent sensors. 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 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.

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

  • If you configure a sensor's 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.2.0. You must:

For more detailed instructions, refer to the Stellar Cyber online documentation section Upgrading Software.

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 Stellar Cyber Platform to 5.2.0

To upgrade the Stellar Cyber Platform to 5.2.0 from a version earlier than 4.3.7, first upgrade to 4.3.7.

  1. Select Admin | Software Upgrade.

  2. Choose 5.2.0.

  3. Select Start Upgrade.

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

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.