Stellar Cyber 5.5.0 Release Notes

Highlights

• New UI (public preview) – A new user interface introduces a more intuitive navigation structure and a new theme engine that adds a light mode option to the UI.

• Detection Profiles – Through detection profiles, you can tune and customize detections per tenant. Previous detection settings were configured globally, but with the introduction of profiles, these can now be specified at the tenant or tenant group levels.

• User-scoped API Tokens – API tokens are now scoped to specific users and inherit those users' permissions and scopes, allowing you more granular control over permissions linked to each API token.

• RedSense Threat Intelligence Integration – Leverage the RedSense premium threat intelligence feed to enhance detection capabilities with enriched, high-fidelity threat data. To take advantage of this feature, simply use your own RedSense subscription.

• Case Suppression – Through the use of case filters you can apply criteria that, if matched, prevent the creation of cases that don't need to be investigated. This helps reduce noise so you can focus on those cases that do require investigation.

• Pre-DPI Traffic Filtering – A new filtering capability lets you filter out unwanted traffic to reduce processing load before Deep Packet Inspection (DPI) occurs.

• Resource-Intensive Query Warnings – Warnings now appear when resource-intensive queries are constructed. The warnings raise awareness about the types of queries that consume an outsized amount of platform resources and offer suggestions on how to make them more efficient.

• Query Builder Enhancements – Query builders embedded on feature pages now pop out to the full query editor with more screen real estate and testing functionality. The ability to test alert filters and case filters directly from the filter builder has been added as well.

• Case Alert Closure Setting – A new global setting lets you specify whether all alerts related to a case are automatically closed when the case is marked Resolved or Cancelled, including cases closed via the API or InSyncs. Added a global setting that specifies the default behavior for closing alerts when a case is closed.

• Alert Document ID – Alerts now include a globally unique document ID by appending an encoded stellar_index_id to the stellar_uuid. This enhancement enables consistent alert tracking and supports integration with downstream tools.

• Blackberry Cylance Responder Templates – Four new webhook responder templates have been added for Blackberry Cylance, enabling automated actions to add or remove entries from Global Quarantine and Global Safe lists via the Universal Webhook Responder.

Actions Required

• Update any scripts that reference Aliyun/AliCloud fields inside msg_data because the Aliyun/AliCloud parser now places them at the top level of the Interflow record. For the complete list of fields that were moved, see DATA-2339.

• Improved the Aliyun/AliCloud parser to have extra parsing for the following fields, they will be stored as “aliyun.# {original_name} _obj“ instead when they’re JSON or an array of JSONs: ['trail_detail', 'detail', 'object_ref', 'response_status', 'user', 'raw_data'].

• Changed the normalization rule for the process_id field to process.pid for the Aliyun/AliCloud parser.

• If you use correlations that rely on the time boundary feature, switch to the time range configuration on each query, which will run more efficiently.

• If you previously used user-level filters to control access to certain information in the data lake, partition this data into separate tenants to control access to that information more effectively.

Behavior Changes

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

• Normalization for computer_name is now derived from sophos.username for the Sophos Central connector.

• Improved the resolution of the srcip_host field in msgtype99 records by enriching it from additional fields. Previously, srcip_host only reflected the value from the srcip_host field in the original record. The srcip_host field is now enriched using values from hostip_host, host.name, and dstip_host when the srcip matches the hostip, host.ip, or dstip fields in the original record. This enhancement provides more complete hostname resolution in enriched flow records, improving data quality for investigations and analytics.

• Moved the following fields from msg_data under the fortinet field in the Fortinet FortiAnalyzer parser: server, authserver, status, mac, ip, vendor, model, versionmin, versionmax, vulnresult, vulncnt,and version.

• Updated the Ivanti Connect Secure parser to support logs prefixed with an octet count and added new regular expressions for parsing syslog message components.

• Standardized Keycloak parser field locations by moving fields from keycloak.details to keycloak, ensuring consistent normalization across old and new log formats.

• Updated SQL log normalization by changing the ip field from nxlog.ip to the standard srcip field.

• Changed the normalized field for remip from fortinet.remip to remote_ip when the value is a valid IP address.

• Updated normalization rules for the Cisco ISE parser.

  For both on-prem and SaaS versions, the device_ip_address field is no longer normalized as srcip and is now retained in the vendor namespace. Additionally, the calling_station_id field is normalized as srcip when its value is a valid IP address.

  For the SaaS version only, a typo was corrected so that DestinationIPAddress is now normalized as dstip instead of srcip. The device_port field is also retained in the vendor namespace and is no longer normalized as srcport.

• Updated the LEEF parser to align with the format specified in the new LEEF standard for using the proto field. Protocol values such as http, https, ssl, and other values that do not map to standard transport or application protocol fields are now normalized under the vendor namespace as {vendor}.proto_name.

• The fields Action, URL, and Sha256 in Cisco logs are now normalized as action, url, and file.hash.sha256, respectively. All other fields are retained under the cisco vendor namespace.

• In the Fortinet FortiAnalyzer parser, the attack field is now enriched and normalized as threat. Additionally, any log containing a sessionid field is now treated as a firewall log.

• For CyberArk Privileged Threat Analytics (PTA) CEF ingestion, the request_id, ticket_id, affected_user_name, device_type, database, other_info, externalid, and reason fields have been moved from msg_data to the vendor namespace.

  The log.event_description field is now removed when its value can be parsed into cyberark.Value and cyberark.Old_Value.

  In addition, when cef_device_vendor is "CyberArk" or "Cyber-Ark" and cef_device_product is "Vault", the fields dev_type, msg_origin.source, dev_class, and msg_class are set to cyberark_vault, and msg_origin.category is set to iam.

• In the Cisco Router Switch parser, normalization was added for several fields. The cisco.description_obj.user field is now mapped to user.name, and cisco.description_obj.Source is normalized as srcip. The cisco.mnemonic field is enriched as login_type when the value is LOGIN_FAILED or LOGIN_SUCCESS. Additionally, cisco.description_obj.localport is now normalized as dstport.

• The detection previously identified by xdr_event.name as azure_unusual_account_creation and xdr_event.subtype.name as azure_ad_account_created_deleted has been removed. It is replaced by a new detection with xdr_event.name set to account_created_deleted_in_short_timeframe and display name Account Created and Deleted within a Close Timeframe.

• Enabling the Case Filters feature as part of the Early Access Program (EAP) hides the Case Visibility setting in Cases | Global Case Settings. If you used Case Visibility to apply a global filter and then enabled Case Filters, you now need to filter results per context—using saved queries or ad-hoc filters at the table or view level. If you don't enable Case Filters, Case Visibility remains available in this release. If Case Filters becomes generally available, Case Visibility is expected to be removed.

Deprecated Features

There are no deprecated features in this release.

Detection/ML

New Features

This release introduces new detections that might be relevant to your environment. These detections are enabled by default and can result in an increased volume of alerts depending on your deployed data sources and use cases. To ensure the alerts are actionable, Stellar Cyber recommends reviewing the applicability of each detection to your environment. You can then disable, suppress, or apply alert filters to detections that do not align with your operational requirements..

• AELDEV-53497: Implemented an alert closure trigger from ServiceNow in Stellar Cyber integration.

  Enhanced the integration between ServiceNow and Stellar Cyber by including a Close All Alerts field in Insyncs configuration for controlling alert closure. When closing a case in ServiceNow, the field value (True or False) determines if associated alerts in Stellar Cyber will also be closed.

• AELDEV-52772: Changed a rule-based detection (Microsoft Entra Unusual Account Creation) to a correlation detection.

  Fixed an issue in the Microsoft Entra Unusual Account Creation rule (xdr_event.name: azure_unusual_account_creation, xdr_event.subtype.name: azure_ad_account_created_deleted, rule_id: azure_44) that caused it to trigger only when activityDisplayName was “Add user” or “Delete user.” This did not align with the intent of the rule, which is to detect accounts that are both created and deleted within a short period of time. The rule was reimplemented as a correlation rule to accurately evaluate event sequences and timing.

• AELDEV-52560: Introduced a third-party alert integration for ESET Cloud Office Security.

  Introduced a third-party alert integration for ESET Cloud Office Security (ECOS) so Stellar Cyber can ingest the security alerts produced by ECOS. More specifically, ECOS performs a routine check on users' Microsoft 365 (Exchange, OneDrive, SharePoint, and Teams) and Google Workspace (Gmail and Google Drive) apps and reports potential malicious activities. Stellar Cyber parses and ingests the detection logs from ECOS and integrates these alerts into its system. The security alert types associated with ECOS are MALWARE, MALWARE (DETECTED BY ESET LIVEGUARD ADVANCED), PHISHING, and SPAM. See Integration of Third Party Native Alerts.

• AELDEV-51699: Implemented third-party alert integration for Trellix MVISION EDR alerts.

  Added Trellix MVISION alert integration for EDR (endpoint detection and response) alerts.

  For EDR threat events, file hash-related fields are now normalized and can be used for Threat Intelligence Platform (TIP) detections. See Integration of Third Party Native Alerts.

• AELDEV-50516: Added Netskope SASE security alerts to Stellar Cyber.

  Added support for all data types learned through a Netskope SASE integration, including breach, connection, and malsite. This enhancement ensures broader alert coverage and more comprehensive detection capabilities. See Integration of Third Party Native Alerts.

• AELDEV-49807: Enhanced LDAP detection in Sensor traffic metadata.

  Implemented advanced LDAP detections based on network traffic metadata to improve the identification of suspicious LDAP activities. The built-in alert type, Suspicious LDAP Search Request, includes subtypes for Domain Trust Enumeration, All Object Enumeration, and Wildcard Query. Alerts are generated for first-seen suspicious LDAP requests, analyzed using defined subtypes with specific criteria. Additionally, LDAP Plaintext Authentication detection is integrated with existing cleartext password detection. A Sigma rule was also added to detect BloodHound Enumeration Activity. These enhancements strengthen threat monitoring capabilities and improve detection of potential enumeration behaviors and unauthorized access attempts within LDAP network traffic. For the built-in alert type, see Machine Learning Alert Type Details. For the rule-based alert type, see Rule-Based Alert Types.

• AELDEV-49067: Added Cloud Drive Data Exfiltration Anomaly alert type covering downloads from Google Drive, OneDrive, and SharePoint.

  Added a built-in alert type for Cloud Drive Data Exfiltration Anomaly (cloud_drive_data_exfiltration_anomaly). The detection covers Google Drive, OneDrive, and SharePoint, and does inference based on the number of file downloads in a 24 hour period on a per-user basis. Alerts include the number of downloads and also a summary of downloaded file names. For the built-in alert type, see Machine Learning Alert Type Details.

• AELDEV-48853: Enhanced SentinelOne Deep Visibility Event integration.

  Implemented a new alert integration workflow for SentinelOne alerts in which Stellar Cyber ingests SentinelOne deep visibility events. For each new SentinelOne alert, related deep visibility events are found by using the SentinelOne storyline ID. These events, which were ingested before the alert was triggered, can potentially contribute to its root case. The related SentinelOne deep visibility events are further summarized to extract affected entities such as IP addresses, domains, and users. This summarization can help you gain high-level knowledge about the SentinelOne alert to understand the scope of its impact. Furthermore, the correlation between SentinelOne alerts and the deep visibility events also enables Stellar Cyber to select and display the related events for specific SentinelOne alerts directly in the user interface. See Related Events for Alert Types.

• AELDEV-48723: Added case suppression filters.

  Introduced a new case suppression mechanism as an Early Access Program feature that lets you specify granular conditions that control whether or not a case gets created. With this new feature, correlations now result in proto-cases, which are then evaluated against a set of case suppression filters. Proto-cases that don't match any suppression filters become cases. After a proto-case becomes a case, it remains a case even if suppression filter criteria are changed later.

• AELDEV-48296: Added support for RedSense premium feed to the Threat Intelligence Platform.

  Added support for a new premium feed, RedSense, to enable the ingestion of threat intelligence feeds directly into the Stellar Cyber Platform. See Configuring Feeds in the Threat Intelligence Platform.

Improvements

• AELDEV-54861: Enhanced the performance of heavy workload Sigma rules.

  Isolated specific Sigma rules with heavier workloads into separate detection jobs to improve performance in larger deployments. This change ensures that detection and rule settings in the Detection Management module remain valid and do not produce duplicates. Focused on reducing performance bottlenecks while preserving the integrity of existing rules and detections.

• AELDEV-49806: Added Sigma rules for enhanced DNS traffic detection.

  Added Sigma rules into the DNS detection framework. This enhancement allows for improved identification and management of potential security threats within DNS traffic. The update includes integration of new Sigma rules, and adaptation of established rules tailored for DNS environments, ensuring heightened detection capabilities. You can now benefit from advanced threat detection by leveraging these rule integrations, leading to proactive security measures in handling DNS-related anomalies. See Rule-Based Alert Types.

• AELDEV-47764: Added support for multi-tenant Detection Profiles.

  Added Detection Profiles to the Detection Management System to support granular detection rule management in multi-tenant environments. Rules can now be configured as ON, OFF, or SILENT per tenant, with independently adjustable alert suppression intervals. Detection Profiles can be created from a default configuration and applied to multiple tenants. Profile changes automatically propagate to all assigned tenants. See Using the Detection Management System.

• AELDEV-46158: Integrated Netskope alerts to improve overall detection support.

  Normalized the following fields in Netskope alerts to align with standard schema and improve detection:

  • netskopewsg.srcip → srcip

  • netskopewsg.dstip → dstip

  • netskopewsg.user → user.name and username

  • netskopewsg.url → url

  • netskopewsg.useragent → user_agent.original

  • netskopewsg.domain → domain_list

• AELDEV-36261: Added support for MFA logins to the Impossible Travel Anomaly and the User Login Location Anomaly.

  Added support for Impossible Travel and User Login Location Anomalies to use logins that have login_result:mfa_success. A 10% fidelity score reduction is applied to alerts with MFA due to the increased likelihood of the login being authentic. For logins that generate multiple records, a non-MFA record is prioritized for alert generation due to reduced data in MFA records. Impossible travel alerts record whether MFA is present for both logins via the has_mfa and has_mfa2 fields. See Machine Learning Alert Type Details.

  has_mfa and has_mfa2 are best-effort and are not guaranteed to be accurate, specifically when there are ingestion delays.

Usability

New Features

• AELDEV-53588: Added a Recipients field to columns in Office 365 connector reports.

  Added a Recipients array field to the columns for the Office 365 connector, enabling the creation of reports that include this field. Previously unavailable, this enhancement now allows visibility of Recipients data in downloaded reports.

• AELDEV-53452: Implemented an integrated alert workflow for SentinelOne alerts.

  Enhanced the alert system by integrating a Related Events tab in the SentinelOne alert dialog box, which summarizes related raw events. The new tab is available for alerts with msg_class: sentinelone_threat_detection, which lets you view related events and access the Threat Hunting table. This feature requires valid SentinelOne API credentials and proper alert configurations to function correctly.

• AELDEV-53047: Implemented Stellar Cyber Case ID field mapping in the InSyncs Alerts table.

  Added Case ID field mapping to the Alerts table in the InSyncs configuration. Alerts mapped to a case now display the corresponding Case ID. If alerts are associated with multiple cases, they display a list of Case IDs. Alerts not mapped to any case show N/A or No Case Mapped. These enhancements improve the linkage between alerts and case management systems such as ServiceNow, ensuring alert consistency and traceability.

• AELDEV-52889: Implemented email notifications for API key revocation.

  Implemented email notifications to users associated with API keys when their keys are revoked. This applies to the revocation of single or multiple keys, as well as when users revoke their own keys. The feature uses the existing email service to send these notifications, ensuring users are promptly informed about any changes to their API key status.

• AELDEV-52571: Added a global setting to control the default behavior for closing alerts when a case is closed.

  Added a Close all related alerts option to the Case Settings dialog box, which specifies whether all alerts related to a case are closed by default when the status of the parent case changes to either Resolved or Cancelled. When this option is enabled, alerts in cases closed through the API or InSyncs are also closed automatically.

  You can override this default setting for individual cases in the confirmation dialog box that appears when canceling or resolving a case. The Update the status of all alerts to Closed option is automatically set according to whatever you specify for this global default, but you can reverse the setting in the confirmation dialog for an individual case.

• AELDEV-51639: Added Microsoft Entra ID to the ATH Disable User dropdown menu.

  Added Microsoft Entra ID to the Connector dropdown menu that appears when Disable User is selected in the Actions section in Automated Threat Hunting (ATH) Playbook settings (Respond | Automation | Create or Edit). This addition allows increases interoperability in managing user access controls. If you don't see this option, it might need to be enabled. Contact your Stellar Cyber account manager to enable it.

• AELDEV-49024:Introduced per-user API keys, scoped to account RBAC privileges and tenancy.

  Implemented per-user API keys. In previous releases, public API access was only available to users with Root scope and Super Admin privileges. With the introduction of per-user API keys, it's possible to enable more granular control over permissions. An account can only make calls to the public API endpoints available to its assigned RBAC privileges. This approach respects the industry-standard principle of least privilege, enables easy breach isolation, and allows immediate key revocation to contain any unauthorized access quickly.

• AELDEV-48826: Added support for dynamic Alert Instance Descriptions with merge fields.

  Added support for an optional Alert Instance Description in the Create an Alert Type dialog box (Alerts | Create). It supports merge fields that let you include variables that render unique contextual details for each alert instance. When used, the text you enter overrides the text taken by default from the Alert Type Description. The Alert Instance Description appears in the Alert Details side panel and alert instance table.

• AELDEV-48467: Added resource-intensive query warnings.

  Added a system warning that appears when a query is likely to consume excessive resources and affect performance. The warning helps you identify resource-intensive queries and encourages query optimization through best practices such as narrowing time ranges, avoiding full-text search, and reducing use of wildcards or nested aggregations. The warning does not block queries from being executed but does provide advice for improving efficiency.

• AELDEV-47741: Implemented a public API endpoint to retrieve tenant data ingestion.

  Added a public API endpoint that allows the retrieval of data ingestion details per tenant on a daily and monthly basis. The API endpoint GET /storage-usages/daily_and_monthly provides information including tenant name, daily ingestion amounts, monthly ingestion amounts, and tenant ID (referred to as customer ID). This update lets clients access data ingestion metrics programmatically, facilitating enhanced usage tracking and reporting. If you don't see this endpoint, contact your Stellar Cyber account manager and request that it be enabled so you can use it.

• AELDEV-46758: Added a Test button to the alert filter builder and case filter builder.

  Added a Test button to simulate alert and case filters directly in the builder in the Query and Filter Manager (System | Queries and Filters). When creating or editing a filter, the Test button lets you run the filter as a query to show representative results so you can validate the type of results returned.

• AELDEV-46097: Added tenant management to ATH rule through the public API.

  Enhanced the public API to support the addition of tenants to a per-tenant ATH (Automated Threat Hunting) rule. This enhancement lets you automate the addition of tenants to existing ATH rules, facilitating seamless integration post-client PoC (Proof of Concept) processes. The update addresses the need for automation in managing tenant-specific ATH rules, reducing manual interventions. This functionality is accessible through the updated /api/alert_watchers endpoint. If you don't see this option, contact your Stellar Cyber account manager and request that it be enabled so you can use it.

• AELDEV-44239: Updated the public API to support query modifications.

  Updated the public API to support modifications of existing queries. The {{/queries/{id}}} endpoint now supports the PUT verb, which lets you update an existing query.

Improvements

• AELDEV-54018: Enhanced the API to allow case resolution when closing cases.

  Updated the API to so you can set the resolution field when closing a case. You can now designate resolutions as False Positive, Benign, or True Positive. This feature, previously available only in the user interface, provides flexibility for automated workflows. Case closure operations can be performed using the HTTP PUT method, with the resolution specified in the payload. Attempts to set the resolution to unsupported values are disregarded.

• AELDEV-53667: Added the Case ID to Alert Contexts in the UI.

  Made alert context displays consistent by ensuring that associated case IDs are displayed (or available for display) everywhere alerts are shown.

• AELDEV-53083: Enabled user-scoped access for specific public APIs.

  Updated APIs for /storage-usages and /storage-usages/daily_and_monthly to support user-scoped access. This allows tenant and partner users to interact with these APIs. Ownership checks between the requester and target records validating org_id and tenant_id were introduced to enforce this access control and ensure proper authorization. This change expands API accessibility beyond root and super_admin users, while maintaining stringent security protocols.

• AELDEV-53076: Restricted Stormshield SNS Firewall action to incoming traffic only.

  Updated the Stormshield SNS Firewall action (Respond | Actions | Firewall Actions | Create) to apply only to incoming traffic. This change prevents configuration issues with the Stormshield SNS firewall platform.

• AELDEV-52153: Resolved unnecessary refreshes of all dashboard gadgets during edits.

  Addressed the issue where editing or resizing a chart gadget on a dashboard (Visualize | Dashboards) triggered a refresh of all gadgets on the page. This led to excessive queries that potentially impacted performance. With this update, resizing a chart gadget no longer prompts any refresh. During the gadget editing process, only the current gadget is updated, preventing unnecessary operations on the remaining gadgets and optimizing resource usage.

• AELDEV-49772: Added resolution options for dashboard PDF exports.

  Enhanced dashboard PDF export functionality to let you set the resolution (Respond | Reports | Exported Dashboards, select an exported dashboard | Schedule | PDF Type: Preserve Layout | Zoom Level). This addresses previous rendering issues like truncated data and overlapping labels by providing more control over the export appearance.

• AELDEV-49139: Added a light mode UI theme.

  Added a new theme selector that lets you toggle between light and dark color palettes. This feature is in public preview. This feature can be enabled through the feature preview menu (username| Feature preview | Theming: Enable). Once you've enabled the Feature preview for Theming, you can switch between the Light Theme and Dark Theme using the corresponding entries under the user menu at the top right of the main menu.

• AELDEV-47841: Updated global navigation.

  Redesigned the header and side navigation components to improve usability and ease of navigation throughout the platform. This feature is in private preview. This feature can be enabled through the feature preview menu (username| Feature preview | Theming: Enable).

• AELDEV-47369: Removed the Use a query as preset filter option from user settings.

  Removed the previously deprecated Use a query as preset filter option (System | Users | Create or Edit). User-level filters are no longer applicable and any existing filters have no effect.

• AELDEV-46757: Added a link to open the full query editor from embedded views.

  Added the ability to open the full query builder from embedded query builder views, and maintain state between the different editors. This makes it easier for you to build complex queries in context.

• AELDEV-43484: Enhanced the Help menu.

  Added an enhanced help menu in global navigation. This feature can be enabled through the feature preview menu (username | Feature preview | Theming: Enable).

• AELDEV-43483: Enhanced the Notifications menu.

  Added an enhanced Notifications menu in global navigation. This feature can be enabled through the feature preview menu (username | Feature preview | Theming: Enable).

• AELDEV-43482: Enhanced the Tenant Selector menu

  Added an enhanced tenant selector menu in global navigation. his feature can be enabled through the feature preview menu (username | Feature preview | Theming: Enable).

• AELDEV-43481: Enhanced the User menu.

  Added an enhanced user menu in global navigation. his feature can be enabled through the feature preview menu (username | Feature preview | Theming: Enable).

• AELDEV-43480: Enhanced Global Navigation.

  Enhanced global navigation. his feature can be enabled through the feature preview menu (username | Feature preview | Theming: Enable).

Stellar Cyber Platform

New Features

• AELDEV-51287: Implemented a warning prompt when deleting sensor profiles linked to tokens.

  Added a warning prompt when attempting to delete a sensor profile that still has associated installation tokens. You'll be informed that deleting the sensor profile will invalidate these tokens. This enhancement serves as a safeguard to prevent unintentional invalidation of tokens. The implementation introduces a prompt if there are associated tokens, ensuring you're aware of the consequences of this deletion.

• AELDEV-48825: Enabled merge fields in custom alert names and alert descriptions in Automated Threat Hunting rules.

  Implemented support for merge fields in custom alert names and alert descriptions in the Alert Configuration section of an Automated Threat Hunting (ATH) rule (Respond | Automation | Create). You can now dynamically insert contextual information into alerts.

• AELDEV-42968: Added the document ID to alert key fields for unique tracking.

  Added the document ID to the alert key fields, which lets you manage and track alerts using this identifier. This integration assists in event referencing across downstream tools. It appends an encoded stellar_index_id to stellar_uuid to ensure global uniqueness and applies to all alerts.

• AELDEV-41136: Implemented an alert for a log processor buffer full condition.

  Added {{buf_log_usage_percent}} in Sensor Monitoring (message ID 36). It displays the percentage of buffer used. You can create alerts based on the field value. The alert will trigger based on specific criteria, such as exceeding a percentage threshold of buffer usage. It lets you take corrective actions, like increasing buffer size or upgrading sensors. This enhancement provides real-time notifications so you can better manage data flow and avoid data loss during high log volumes.

Improvements

• AELDEV-48447: Added a warning prompt for the deletion of sensor profiles associated with tokens.

  Added a warning prompt that appears when attempting to delete a sensor profile. The prompt informs you if the profile is associated with existing installation tokens. Deleting such profiles will render those tokens invalid. This ensures that you're aware of the impact the deletion has on deployment tokens before proceeding and helps prevent the accidental invalidation of tokens that are still in use.

Sensors

New Features

• AELDEV-43968: Added pre-DPI traffic filtering.

  Added network traffic filters that are enforced before traffic is processed through the Deep Packet Inspection (DPI) engine. This enables more efficient filtering on layer 2-4 attributes, optimizes the utilization of sensor resources, and improves sensor throughput. Note that the pre-DPI filter behavior can vary from source host and destination host filtering. You configure and apply pre-DPI filters in Sensor Profiles.

Improvements

• AELDEV-53942: Updated Filebeat-forwarded logs to include tenant IDs.

  Updated the Filebeat service to include the tenant ID in a log message. This enhancement ensures that tenant-specific identifiers are consistently tracked and recorded in monitoring data, which is crucial for multi-tenant environments.

• AELDEV-52484: Added support for aggregator configuration to the Linux installation script.

  Added support to the Linux installation script for the configuration of primary and secondary aggregators directly via command line parameters. This enhancement simplifies setup by letting you specify aggregator settings during initial deployment without additional steps. To use this feature, pass the appropriate aggregator parameters when executing the ds_linux_install.sh script.

• AELDEV-52377: Added HTTP proxy support to the Windows Server Sensor installer.

  Added support for passing an HTTP proxy parameter during deployment of the Windows Server Sensor using msiexec. If no proxy is specified and no aggregators are configured, the installer attempts to use the system-configured proxy on the Windows host. This enhancement supports use cases such as automated remote installation using tools like Puppet. For example: msiexec /i <full_path_name_of_msi_file> /quiet /norestart CM_HOST=10.1.1.1 TENANT_ID="" AGG_HOST1="" AGG_HOST2="" HTTP_PROXY="1.1.1.1"

• AELDEV-47303: Updated the Tenable Nessus vulnerability scanning sub-agent deployed with Stellar Cyber sensors.

  Updated the Tenable Nessus vulnerability scanning sub-agent deployed with Stellar Cyber sensors to version 10.8.3. If you have a Bring Your Own License (BYOL) agreement, you can benefit from improved compatibility with the latest Tenable.io or Tenable.sc requirements and enhanced vulnerability scanning features.

• AELDEV-31740: Added sensor CLI command support for show interface physical and show netstat commands.

  Added support to the device sensor of the show interface physical command to view detailed physical interface statistics. In addition, the show netstat command was added to view network statistics.

Connectors

New Features

• AELDEV-53382: Added Close All Alerts field in InSyncs Cases table for mapping ServiceNow cases. This lets you choose whether to close alerts automatically.

  Enhanced the ServiceNow-Stellar Cyber integration with a field-mapping feature to manage alert closures upon case resolution. Added a Close All Alerts field to the the InSyncs Cases table. It lets you choose whether to close alerts automatically when you resolve a case. This selection triggers corresponding API calls in Stellar Cyber, ensuring synchronized status updates. Robust error handling and logging were implemented to manage API call failures, accompanied by UI enhancements in ServiceNow for clarity. This improvement streamlines workflows, providing more control and improving efficiency in managing alerts and cases between the platforms. See Using InSyncs.

• AELDEV-53197: Added Case ID field in InSyncs Alerts table for mapping ServiceNow alerts.

  Added a Case ID field to the InSyncs Alerts table. If configured, a case ticket ID is shown in the InSyncs Alerts table when an alert is linked to the case. If an alert is associated with multiple cases, all of the ticket IDs are displayed for that alert in the Alerts table. If no cases are linked to an alert, the Alerts table displays "No Case Mapped" for the alert. This enhancement improves case management visibility directly in alert configurations and further facilitates integration with ServiceNow for managing incidents. See Using InSyncs.

• AELDEV-53054: Introduced bidirectional comment synchronization between Stellar Cyber and ServiceNow.

  Added Comments and Activities fields to the InSyncs Alerts and Cases tables. Implemented bidirectional synchronization of activity logs, allowing comments added in Stellar Cyber to reflect in ServiceNow Work Notes and vice versa. Real-time updates ensure near-instantaneous propagation, with error handling and retry mechanisms to prevent duplication. Comments are securely transmitted via HTTPS and OAuth 2.0, maintaining an audit log for compliance. Changes, including updates and deletions, are handled to preserve consistency across systems, without exceeding 50ms processing time per transaction. See Using InSyncs.

• AELDEV-51687: Introduced the Versa Networks Firewall responder, with functionality for blocking and unblocking IP addresses.

  Introduced the Versa Networks Firewall responder, which allows the automated blocking and unblocking of IP addresses. See Configuring Versa Networks Firewall Connectors.

• AELDEV-42535: Introduced the Barracuda Web Application Firewall (WAF) Cloud connector.

  Introduced a connector to ingest logs from Barracuda Web Application Firewall (WAF) Cloud. See Configuring Barracuda WAF Connectors.

• AELDEV-41853: Introduced the Mimecast API 2.0 connector.

  Introduced a new connector for Mimecast API 2.0. It integrates with Mimecast API 2.0 to query MTA logs. In addition, the existing Mimecast connector was renamed to Mimecast API 1.0. You are encouraged to migrate to continue accessing the latest Mimecast features and improvements. See Configuring Mimecast API 2.0 Connectors.

• AELDEV-41594: Introduced the Sucuri Security connector.

  Introduced a connector to ingest logs from the Sucuri Security Web Application Firewall (WAF). See Configuring Sucuri Security Connectors.

• AELDEV-24063: Introduced the Stormshield SNS Firewall Responder for blocking and unblocking hosts.

  Implemented a responder for Stormshield SNS firewalls enabling host blocking and unblocking. See Configuring Stormshield SNS Firewall Connectors.

• AELDEV-18142: Introduced the Trend Micro Cloud App Security connector.

  Introduced a connector to ingest logs from Trend Micro Cloud App Security. See Configuring Trend Micro Cloud App Security Connectors.

• AELDEV-40782: Added webhook responder templates for Blackberry Cylance.

  Enhanced the Blackberry Cylance connector by introducing four new webhook responder templates via the Universal Webhook Responder. The templates include actions to add to and delete from both the Global Quarantine and Global Safe lists. See Configuring BlackBerry Cylance Connectors.

Improvements

• AELDEV-53691: Updated the Microsoft Entra ID connector manifest for compliance.

  Updated the connector for Microsoft Entra ID (formerly Azure AD) to align with upcoming changes in the manifest configuration. The deprecated manifest attribute allowPublicClient has been replaced with isFallbackPublicClient as per the new requirements. This change ensures continued compatibility with Microsoft identity platform updates. You must adjust your existing configurations to accommodate these changes to avoid disruptions with the service. Refer to Microsoft documentation for additional guidance on how to update the manifest configuration of your application. See Configuring Microsoft Entra ID (formerly Azure Active Directory) Connectors.

• AELDEV-52411: Improved normalization for the Sophos Central connector.

  Updated the normalization logic of the computer_name field in the Sophos Central connector. Previously, it was derived from sophos.username instead of sophos.location. This update corrects the normalization process, ensuring that the computer_name field accurately reflects the associated machine name.

• AELDEV-52198: Improved normalization for the Trend Micro Cloud App Security connector.

  Updated the Trend Micro Cloud App Security normalization process to ensure more accurate and effective data normalization.

• AELDEV-51860: Completed normalization update for Netskope SASE alerts

  Updated the normalization of Netskope SASE alerts in the Stellar Cyber Platform.

• AELDEV-51692: Improved the Oracle Cloud Infrastructure (OCI) Streaming connector timestamp and buffer processing.

  Updated the OCI Streaming connector to improve timestamp normalization and enhance performance under high message volume. The timestamp now uses oracle.time for accuracy.

• AELDEV-51527: Added ATH rule to disable Azure AD users.

  Implemented a new capability that enables the ability to disable users in Microsoft Entra ID using automated rules. This feature has been integrated into Automated Threating Hunting (ATH) rules, so that you can choose the Entra ID connectors from a dropdown list (Respond | Automation | Create or Edit, select Disable User in the Actions section, and then choose Microsoft Entra ID from the Connector list).

• AELDEV-50240: Improved normalization for Google Workspace alerts.

  Added normalizations for Google Workspace alerts for a more consistent and accurate processing of alerts.

• AELDEV-49877: Updated the Sophos connector to normalize "computer_name" correctly.

  Updated the normalization process for the Sophos connector to correctly use the location field for computer_name instead of username. Both Events and Alerts content types now reflect this normalization fix. Configuration updates ensure accurate representation of endpoint data and align with expected Sophos infrastructure identifiers.

• AELDEV-48725: Updated the CrowdStrike connector to support the new EppDetectionSummaryEvent schema.

  Updated the CrowdStrike connector to accommodate the new EppDetectionSummaryEvent schema. The updated schema provides a more detailed structure, enhancing data categorization and potentially increasing alert generation. The connector supports specific event types introduced in the new schema, allowing for continued integration with the evolving endpoint detection capabilities of CrowdStrike. See Configuring CrowdStrike (Hosts/Events) Connectors.

• AELDEV-47718: Enhanced SentinelOne activity alert field normalization.

  Improved field mappings for SentinelOne activity alerts. The sentinelone.data.computerName normalizes to both computer_name and host.name, aligning with other SentinelOne alerts. Additionally, sentinelone.data.ipAddress maps to host.ip, and sentinelone.data.username maps to user.name.

• AELDEV-42673: Added content types to the Trellix MVISION connector.

  Enhanced the Trellix MVISION connector to support EDR Alerts and EDR Threats content types. See Configuring Trellix MVISION Connectors.

Parsers

New Features

• DATA-2635: Introduced a parser for ingesting Cisco Ironport (CEF) logs.

  Added a built-in parser for ingesting Cisco Ironport logs in CEF on port 5143.

• DATA-2618: Introduced a parser for ingesting HTTP Google Kubernetes Engine logs.

  Added a built-in parser for ingesting HTTP Google Kubernetes Engine logs in JSON format on port 5907.

• DATA-2606: Introduced a parser for ingesting Zscaler Deception logs.

  Added a built-in parser for ingesting Zscaler Deception logs on port 5909.

• DATA-2570: Introduced a parser for ingesting HTTPJSON Scx SmartEDR logs.

  Added a built-in parser for ingesting HTTPJSON Scx SmartEDR logs on port 5901.

• DATA-2556: Introduced a parser for ingesting Attrelogix EaziCloud logs.

  Added a built-in parser for ingesting Attrelogix EaziCloud logs on port 5905.

• DATA-2552: Introduced a parser for ingesting Fortanix DSM logs.

  Added a built-in parser for ingesting Fortanix DSM logs on port 5906.

• DATA-2547: Introduced a parser for ingesting Trellix EPO logs.

  Added a built-in parser for ingesting Trellix EPO logs on port 5902.

• DATA-2545: Introduced a parser for ingesting Zimbra Email logs.

  Added a built-in parser for ingesting Zimbra Email logs on port 5899.
  

• DATA-2537: Introduced a parser for ingesting QSAN Storage logs.

  Added a built-in parser for ingesting QSAN Storage logs on port 5898.

• DATA-2534: Introduced a parser for ingesting Fortinet Fortiswitch logs.

  Added a built-in parser for ingesting Fortinet Fortiswitch logs on port 5904.

• DATA-2533: Introduced a parser for ingesting SAP Backup logs.

  Added a built-in parser for ingesting SAP Backup logs on port 5897.

• DATA-2509: Introduced a parser for ingesting Ubiquiti UniFi Security Gateway logs.

  Added a built-in parser for ingesting Ubiquiti UniFi Security Gateway logs on port 5900.

• DATA-2497: Introduced a parser for ingesting HTTP Google Cloud Armor logs.

  Added a built-in parser for ingesting HTTP Google Cloud Armor logs on port 5896.

• DATA-2483: Introduced a parser for ingesting Antaira Switch logs.

  Added a built-in parser for ingesting Antaira Switch logs on port 5895.

• DATA-2470: Introduced a parser for ingesting Forcepoint Next-Generation Firewall (NGFW) logs.

  Added a built-in parser for ingesting Forcepoint Next-Generation Firewall (NGFW) logs on port 5891.

• DATA-2436: Introduced a parser for ingesting Ericsson Cradlepoint Router logs.

  Added a built-in parser for ingesting Ericsson Cradlepoint Router logs on port 5886.

• DATA-2406: Introduced a parser for ingesting ARCON PAM logs.

  Added a built-in parser for ingesting ARCON PAM logs on port 5886.

• DATA-2398: Introduced a parser for ingesting Ahnlab EDR (Endpoint Detection and Response) logs.

  Added a built-in parser for ingesting Ahnlab EDR (Endpoint Detection and Response) logs on port 5883.

• DATA-2379: Introduced a parser for ingesting Sophos Switch logs.

  Added a built-in parser for ingesting Sophos Switch on port 5888.

• DATA-2377: Introduced a parser for ingesting SAP Security Audit logs.

  Added a built-in parser for ingesting SAP Security Audit logs on port 5881.

• DATA-2376: Introduced a parser for ingesting Barracuda WAF logs.

  Added a built-in parser for ingesting Barracuda WAF logs on port 5880.

• DATA-2374:Introduced a parser for ingesting Fortinet FortiManager logs.

  Added a built-in parser for ingesting Fortinet FortiManager logs on port 5894.

• DATA-2353: Introduced a parser for ingesting A10 vThunder Application Delivery Controller (ADC). logs

  Added a built-in parser for ingesting A10 vThunder Application Delivery Controller (ADC) logs on port 5882.

• DATA-2344: Introduced a parser for ingesting Check Point Harmony Email & Collaboration logs.

  Added a built-in parser for ingesting Check Point Harmony Email & Collaboration logs on port 5879.

• DATA-2342: Introduced a parser for ingesting Sangfor Internet Access Gateway (IAG) logs.

  Added a built-in parser for ingesting Sangfor Internet Access Gateway (IAG) logs on port 5890.

• DATA-2313: Introduced a parser for ingesting OpenIAM logs.

  Added a built-in parser for ingesting OpenIAM logs on port 5889.

• DATA-2273: Introduced a parser for ingesting VMWare ESXi logs.

  Added a built-in parser for ingesting VMWare ESXi logs on port 5878.

• DATA-2225: Introduced a parser for ingesting ESET Cloud Office Security logs.

  Added a built-in parser for ingesting ESET Cloud Office Security logs on port 5893.

Improvements

• DATA-2605: Updated fields from "msg_data" to "aruba" fields for the Aruba ClearPass CEF parser.

  Moved the following fields from msg_data to aruba fields for the Aruba ClearPass CEF parser:

  arubaclearpassauthrequestid, arubaclearpassauthapname, arubaclearpassautherrorcode, arubaclearpassauthnasidentifier, arubaclearpassauthnasporttype, arubaclearpassauthssid, arubaclearpassauthauthstatus, arubaclearpasscppmerrorcodeerrorcodedetails, arubaclearpasscppmerrorcodeerrorgroupdetails, authentication_protocol, enforcement_profiles, arubaclearpassradiusarubauserrole, arubaclearpassradiuscallingstationid, arubaclearpassauthtlsversion, arubaclearpassauthauthmethod, arubaclearpassradiusterminationcause, user_name, end_host_id, source, nas_ip, cppm_node, service_name, roles, enf_profiles, calling_station_id, ap_name, framed_ip_address, nas_name, nas_port_type, ssid, tls_version, auth_method, request_status, service_type, alerts, filter, attributes, authentication_source, aruba_user_role, authentication_inner_method, arubaclearpassauthusertype,host_ip

• DATA-2532: Improved the Linux Syslog parser to extract additional fields.

  Improved the Linux Syslog parser to extract additional fields from accepted authentication logs. Added support for parsing and normalizing the method, username, and srcip fields from SSH login events. These fields are extracted into the log.syslog namespace and normalized at the top level for better visibility and consistency. To ensure consistent parsing across different syslog formats, enhancements were validated on common Linux distributions, including Amazon AMI and Ubuntu.

• DATA-2511: Improved EfficientIP SOLIDserver DDI parser to parse additional message parts.

  Expanded the EfficientIP SOLIDserver DDI parser to extract key information from previously unparsed log sections. The parser now captures and normalizes details such as the client IP address, DNS query domain, resource record type, and DNS server IP address. This enhancement provides deeper visibility into DNS request activities and improves the usability of the parsed data for threat hunting and analysis.

• DATA-2503: Fixed an issue where forwarded SonicWall logs were incorrectly attributed to the tenant of the receiving sensor in multi-sensor environments.

  Enhanced SonicWall log parsing to correctly associate forwarded logs with the original tenant and sensor, resolving prior attribution errors. The in_beats.rb file was updated to extract and preserve forwarder_engid, forwarder_engid_name, tenantid, and tenant_name from the originating Windows Sensor, alongside the engid and engid_name of the receiving Modular Sensor. Forwarded SonicWall logs now accurately display both the original and receiving metadata, ensuring proper tenant assignment and data integrity in multi-tenant environments.

• DATA-2499: Expanded the Barracuda Firewall parser to improve field extraction for user and action data.

  Enhanced the Barracuda Firewall parser to accurately extract user and action fields from logs received on port 5524. In addition, the parser now correctly processes cases where action values are missing. These improvements ensure more complete and consistent event parsing for firewall login and authentication activity.

• DATA-2496: Reorganized field parsing in the Fortinet FortiAnalyzer parser by relocating fields from msg_data to the fortinet object.

  Reorganized Fortinet FortiAnalyzer parsing by relocating specific fields from the msg_data object to the nested fortinet object. The affected fields include: server, authserver, status, mac, ip, vendor, model, versionmin, versionmax, vulnresult, vulncnt, and version.

• DATA-2489: Improved the Cisco Firepower parser to parse additional messages in detail.

  Improved the Cisco Firepower parser to parse the following messages in detail:

  • 106001 – A TCP connection was built.

  • 106006 – A TCP connection was denied due to an ACL.

  • 106007 – A TCP connection was denied due to a Layer 3 or Layer 4 filter.

  • 106010 – A TCP connection was closed.

  • 106015 – A TCP connection was torn down.

  • 106018 – An ICMP connection was denied due to an ACL.

  • 106100 – A UDP connection was built.

  • 106102 – A UDP connection was denied due to an ACL.

  • 106103 – A UDP connection was torn down.

• DATA-2471: Added new log format support for the Ivanti Connect Secure parser.

  Updated the Ivanti Connect Secure parser to support logs prefixed with an octet count and added new regular expressions for parsing syslog message components.

• DATA-2465: Improved the Cisco Umbrella parser with additional DNS-related enrichments.

  Enhanced the Cisco Umbrella parser to enrich these fields: dns.question.name, dns.question.registered_domain, and dns.question.top_level_domain using values derived from domain_list. This provides more detailed domain-level context for DNS logs.

• DATA-2461: Added new log format support for the Keycloak parser.

  Standardized Keycloak parser field locations by moving fields from keycloak.details to keycloak, ensuring consistent normalization across old and new log formats.

• DATA-2449: Improved the NXlog parser to have better normalizations for the SQL log.

  Improved the NXlog parser to have different normalizations for the ip field in the SQL log. Instead of moving it into the vendor namespace, it's now normalized as srcip.

• DATA-2447: Updated the normalization rule of the field 'remip' for the Fortinet FortiAnalyzer parser.

  Changed the normalized field for remip from fortinet.remip to remote_ip when the value is a valid IP address. Other values remain in fortinet.remip.

• DATA-2435: Enhanced Ivanti Pulse Secure parser to improve parsing of incomplete and varied log formats.

  Updated the Ivanti Pulse Secure parser to handle logs where optional fields such as Realm and Role are missing. Improved the regular expression to support a broader range of log formats, ensuring detailed parsing even for web request logs, unauthenticated access attempts, and session events. This enhancement increases parser resilience and ensures consistent event normalization across diverse Ivanti Pulse Secure log types.

• DATA-2434: Enhanced Trellix EX (FireEye) CEF parser to extract and normalize the email subject field.

  Updated the Trellix EX (FireEye) CEF parser to extract the flexString2 field, which contains the subject line of an email, and normalize it under the field name subject. This enhancement ensures that email subject information is consistently captured during ingestion, improving visibility for email-based threat investigations.

• DATA-2427: Enhanced IBM i (AS400) parser to support new log formats with flexible message parsing.

  Updated the IBM i (AS400) parser to handle new log formats containing the Accepted (SIM) => prefix, where fields appear in readable message form rather than strict key-value pairs. Enhanced the parser to use regex extraction for these logs and normalized the Time field to event.timestamp. These improvements ensure robust parsing across both traditional and new free-text IBM AS400 log formats.

• DATA-2426: Updated normalization rules for the Cisco ISE parser.

  Adjusted normalization rules for the following fields in the Cisco ISE parser:

  • For both on-prem and SaaS versions, the device_ip_address field is no longer normalized as srcip and is now retained in the vendor namespace. Additionally, the calling_station_id field is normalized as srcip when its value is a valid IP address.

  • For the SaaS version only, a typo was corrected so that DestinationIPAddress is now normalized as dstip instead of srcip. The device_port field is also retained in the vendor namespace and is no longer normalized as srcport.

• DATA-2416: Improved the Fortinet - FortiGate (CEF) parser to parse the "requestmethod" field from msg_data.

  Improved the Fortinet - FortiGate (CEF) parser to parse the requestmethod field from msg_data.

• DATA-2413: Added normalization for key Fortinet FortiMail fields previously embedded in "msg_data".

  Enhanced the Fortinet FortiMail parser by extracting and normalizing several fields previously located in the msg_data object. The updated parser now normalizes the following fields directly: dst_ip, log_part, subject, wf_cat_id, virus_id, virus_name, signature_id, and disposition. This improves data accessibility and consistency for downstream analysis.

• DATA-2397: Extended Trellix FireEye HX parser to support additional log formats.

  Enhanced the Trellix FireEye HX parser to recognize and normalize a broader range of log message types, including custom formats. Updates included regex optimization and parser configuration adjustments to accommodate new message structures.

• DATA-2392: Improved the LEEF parser to clean field formatting and enhance protocol normalization.

  Refined the LEEF parser to automatically remove unnecessary leading and trailing single quotation marks from field values. Additionally, updated the parser to handle the proto field according to the new LEEF standard. Values such as http, https, ssl, and other unsupported protocols are now normalized under the vendor namespace as {vendor}.proto_name.

• DATA-2388: Improved the Palo Alto Networks Firewall parser to extract fields from the "palo_alto_networks.description" field in SYSTEM logs.

  Enhanced the parser to extract key=value pairs from the palo_alto_networks.description field in SYSTEM log messages. These values are now normalized into individual fields and mapped to ECS or custom fields where applicable, improving field-level visibility and supporting more granular analysis.

• DATA-2386: Enhanced Cisco Umbrella parser to support new formats and improve field normalization.

  Expanded the Cisco Umbrella parser to recognize logs with RFC-3164 syslog headers and a common Logstash header format. Added support for seven additional CSV log variants. Improved field normalization by mapping "Action," "URL," and "SHA256" to Stellar Cyber standard fields, while moving other fields into the vendor namespace. The parser now also uses the internal timestamp in the log as the event timestamp to ensure more accurate record alignment.

• DATA-2372: Improved the Cisco routers and switches parser to parse more logs in detail.

  Expanded the Cisco routers and switches parser to recognize and extract fields from additional log message types. This update improves normalization coverage and enables more detailed parsing of operational and access logs across diverse Cisco device configurations.

• DATA-2363: Improved log message parsing to extract more fields in Forescout parser.

  Improved field extraction in the Forescout parser to support updated log formats. Added support for extracting fields such as Function, 802.1x Calling Station ID, 802.1x NAS ID, Credential Vulnerability, Login Credentials, Communication Protocol, and Member Of.

• DATA-2354: Added new log format support for Barracuda Firewall Parser.

  Added new log format support for the Barracuda Firewall parser to address compatibility issues with events sent in key=value format. The update enhances parsing accuracy for logs received over port 5524, including those with variations in header formatting and space alignment. This change ensures successful extraction of fields such as proto, srcIP, dstPort, and others, which previously triggered header-matching errors in the parser.

• DATA-2339: Improved the Aliyun / AliCloud parser to parse more fields.

  Improved the Aliyun / AliCloud parser to extract additional fields when their values are JSON objects or arrays of JSON objects. The fields trail_detail, detail, object_ref, response_status, user, and raw_data are now parsed and stored as aliyun.<original_name>_obj. Additionally, the normalization rule for the process_id field is now mapped to process.pid.

  The following fields were also moved out from the msg_data to the aliyun vendor namespace and other containers within Interflow records: "ali_uid", "api_version", "asset_ip", "asset_port", "audit_id", "bypass_id", "bytes", "cdn_in", "cdn_out", "check_item", "check_item_level", "check_item_name", "check_level", "check_type", "city_id", "class_name", "client_mode", "cmd_line", "connection_type", "container_file_path", "container_host_name", "container_machine_ip", "container_mip", "data_type", "defense_action", "docker_proc_path", "dst_ip_region", "end", "eni-id", "err_msg", "error_message", "file_gid_name", "file_name", "file_path", "file_uid_name", "get_request", "gid", "gid_name", "host_instance_id", "host_ip", "inter_ip", "intranet_in", "intranet_out", "ioc_ip", "ip_version", "k8s_cluster_id", "k8s_name_space", "k8s_node_name", "k8s_pod_name", "kind", "last_login", "metering_datasize", "metering_datasize_ca", "metering_datasize_zrs", "metering_datasize_zrsii", "net_connect_dir", "network_in", "network_out", "ori_path", "ori_source", "ori_topic", "os_name", "os_type", "packets", "parent_cmd_line", "parent_file_name", "parent_file_path", "parent_proc_id", "parent_proc_name", "parent_proc_path", "parent_proc_start_time", "pcmdline", "platform", "proc_id", "process_img", "process_img_size", "project", "put_request", "raw_data", "raw_ts", "remote_ip", "reqeust_path", "request_object", "response_object", "scan_time", "sid", "src_ip_list", "src_ip_region", "srv_cmd", "stage", "stage_time_stamp", "start", "storage", "storage_type", "sub_type_alias_name", "suspicious_event_id", "sync_in", "sync_out", "tcp-flags", "template_id", "transport_protocol_name", "transport_protocol_status", "type_alias_name", "u_name", "unique_info", "verb", "vm-id", "vpc-id", "vswitch-id", "vul_alias_name", "vul_name".

• DATA-2332: Improved the Apache HTTP Server parser to support placeholder fields.

  Enhanced the Apache HTTP Server parser to properly handle placeholder values, such as a dash (-), in fields that might appear empty in logs. This ensures that logs using - for missing values—such as in response_byte—are parsed correctly without generating errors or failing field extraction.

• DATA-2261: Updated the Fortinet FortiAnalyzer parser to improve threat enrichment and log classification.

  Enhanced the Fortinet FortiAnalyzer parser to enrich the attack field as threat. In addition, logs containing a sessionid field are now classified as firewall logs. For these logs, the msg_class, msg_origin.category, and dev_class fields are all set to firewall.

• DATA-2248: Improved the CyberArk - PTA (CEF) ingestion to parse out more fields

  Moved the request_id, ticket_id, affected_user_name, device_type, database, other_info, externalid, and reason fields from msg_data to the vendor namespace.

  The log.event_description field is now removed when its value can be parsed into cyberark.Value and cyberark.Old_Value.

  In addition, when cef_device_vendor is "CyberArk" or "Cyber-Ark" and cef_device_product is "Vault", the fields dev_type, msg_origin.source, dev_class, and msg_class are set to cyberark_vault, and msg_origin.category is set to iam.

• DATA-2228: Added new log format support for the Linux Audit parser.

  Added support for a new log format in the Linux Audit parser that includes a syslog-style header. This header introduces the syslog_appname and syslog_procid fields, allowing for improved attribution of events to originating processes and applications.

• DATA-2216: Added additional normalization for the Cisco Router Switch parser.

  Enhanced the Cisco Router Switch parser by normalizing several additional fields. The cisco.description_obj.user field is now mapped to user.name, and cisco.description_obj.Source is normalized as srcip. The cisco.mnemonic field is enriched as login_type when the value is LOGIN_FAILED or LOGIN_SUCCESS. Additionally, cisco.description_obj.localport is now normalized as dstport.

Early Access Program

If you're interested in testing out new features ahead of general availability, consider joining the Early Access Program (EAP) by contacting your Stellar Cyber Customer Success representative and telling them which EAP feature you want to test. Once you've agreed to the EAP terms and signed up, the EAP feature is unlocked for you.

The purpose of this program is to boost performance and reliability through real-world customer insights, giving you a hands-on role in shaping a Stellar Cyber feature. In return, you'll receive early access to upcoming releases and the chance to guide product development.

Case Suppression

Case Suppression is a new EAP feature that helps reduce noise by automatically hiding low-priority cases based on customizable case filters. This keeps your team focused on what matters most without losing visibility into critical threats. Enrolling in EAP gives you early access to this capability and a chance to shape its development. If you’d like to participate, contact your Customer Success representative.

Operational Notes

There are no operational notes for this release.

Resolved Issues

• AELDEV-55883: Adjusted the logic for ESET alert and case scoring.

  Improved the security calculation for the ESET Protect Threat event by including the critical severity level of the alert.

• AELDEV-55686: Resolved an issue where the ethernet1 IP address configuration wasn't persistent when set through the CLI.

  Corrected an issue preventing IP address assignment to a second network interface set by the set interface ethernet[0..9] CLI command. Previously, you needed to manually configure IP addresses using shell commands to modify the /etc/network/interfaces file for persistent changes. With this fix, the CLI now properly sets the IP address for ethernet1 interface. Note that show interface in the CLI only displays the management interface IP address by design, necessitating a different feature request for visibility of all interface IP addresses.

• AELDEV-55312: Normalized WEC logs to include the originating computer names.

  Updated the computer_name field in Windows Event Collector (WEC) logs to correctly reflect the computer name of the originating host. Previously, the logs displayed the name of the WEC server. This update employs Active Directory computer data for proper enrichment, ensuring visibility of the original event source. The logs now align with the expected format where the computer_name accurately represents the source machine, not the WEC server.

• AELDEV-54876: Updated the query builder field name validator to allow hyphens.

  Updated the field name validator to support field names containing hyphens to ensure compatibility with existing data setups and support hyphenated field names in general. You can now input and save field names with hyphens without encountering issues.

• AELDEV-54493: Updated private IP address enrichment to classify private IP addresses correctly .

  Resolved an issue where certain IP addresses configured as private IP addresses in CIDR notation were still being classified as public addresses. These IP addresses are now correctly identified and marked as private, ensuring that geolocation enrichment is only performed based on the sensor gateway for private IP address ranges.

• AELDEV-54461: Resolved an issue with tenant-specific lookups in alert filters.

  Fixed an issue where tenant-specific lookups were not selectable when creating alert filters for that tenant. Previously, a workaround was needed using tenant queries, which is no longer necessary. If you're employing previous methods, now apply tenant-specific lookups directly to alert filters without additional steps. This update improves the usability and efficiency of alert filter configurations in multi-tenant environments.

• AELDEV-54407: Fixed an issue with geolocation database configuration persistence.

  Corrected an issue that prevented some geolocation database configurations from persisting. Changes were made to ensure they update and persist correctly.

• AELDEV-54395: Resolved an issue that prevented cases from generating for deduplicated alerts.

  Fixed an issue where alerts from Automated Threat Hunting (ATH) rules with deduplication were not generating cases. This prevented proper case management by disrupting the link between alerts and case records. The resolution ensures that only relevant deduplication data is updated, preserving the integrity of the case association. This fix improves reliability when handling customized alerts under ATH rules with deduplication configured.

• AELDEV-54320: Resolved an issue that prevented aella_winlog from starting on DHCP servers.

  Addressed an issue where aella_winlog failed to start on DHCP servers due to a corrupted lock file. The corrupted file is now automatically deleted and the aella_winlog service is restarted to ensure that a new valid lock file is generated without manual intervention.

• AELDEV-54278: Updated the Linux Server Sensor receiver to use an aggregator.

  Corrected an issue that prevented some Server Sensor operations from using the aggregator configuration, bypassing it and attempting to connect directly to the Data Processor. This update ensures all outbound data adheres strictly to aggregator routing.

• AELDEV-53935: Resolved an error when adding an alert to a case.

  Resolved an error that prevented some alerts from being added to a new or existing case.

• AELDEV-53903: Resolved volume usage date inconsistency between graphs and tables.

  Addressed an inconsistency issue where the volume usage graph and the corresponding table displayed different dates due to time zone discrepancies. The fix ensures that both graphs and tables consistently display data for the same date.

• AELDEV-53737: Enhanced TSV feed handling to support a specific size and IoC limits.

  Enhanced the TSV (Tab-Separated Values) feed engine to manage incoming source files smaller than 100 MB and to process up to 25,000 Indicators of Compromise (IoCs) per day. Additionally, the HTTP request timeout for data polling has been set to 30 seconds to improve data retrieval efficiency. These updates aim to enhance the performance and reliability of the TSV feed integration within the Threat Intelligence Platform.

• AELDEV-53684: Resolved a system error in Executive Summary reports.

  Resolved an issue where the Executive Summary report failed to generate when the selected date range exceeded 40 days. The new maximum limit is 60 days.

• AELDEV-53547: Resolved recursive correlation in detection alerts.

  Addressed an issue of recursive behavior in correlation logic for detection alerts. A correction was made to ensure that nested correlation information does not propagate when building alerts from other correlated alert records.

• AELDEV-53518: Fixed an issue where "exploit attempt" alerts failed to trigger at scheduled intervals.

  Improved efficiency for exploit attempt correlation so that they complete within the scheduled execution interval.

• AELDEV-53492: Enabled array fields for column selection in Threat Hunting.

  Added support for array-type fields such as url_list and domain_list in Threat Hunting for both table views and CSV exports.

• AELDEV-53154: Fixed a log forwarder startup issue in Amazon Web Services (AWS).

  Resolved an issue preventing the log forwarder service on some modular sensors from starting up when deployed in AWS.

• AELDEV-52984: Adjusted the Password Resets Anomaly time range for original records.

  Resolved an issue in the Password Resets Anomaly detection where the queried original records did not match the time range specified in the alert description. Now the original records reflect all relevant events within the described 24-hour time frame, providing a more accurate alert representation.

• AELDEV-52192: Improved responsiveness of the alert filter builder with multiple conditions.

  Enhanced the responsiveness of the alert filter builder, especially when multiple conditions are added to filters. This improvement reduces lag when configuring exclusion profiles and other filters and addresses performance issues when working with complex multi-condition filters.

• AELDEV-52095: Increased batch read size for the Windows Security Event Log.

  Increased the batch read size for the Windows Security Event Log to 1024 records. This adjustment aims to address logging delays by allowing more security event records to be processed per batch. Winlogbeat now reads and processes these events using the updated configuration, enhancing the log ingestion rate. This change is applied to systems using the Windows Event Log API, compatible with Microsoft Windows Vista and later versions.

• AELDEV-51726: Reverted an aggregation CSV optimization that caused errors.

  Reverted an aggregation CSV optimization made in the 5.3.0 and 5.4.0 releases that changed the CSV file format and caused errors.

• AELDEV-47787: Applied proxy settings for the Stellar Cyber platform correctly to all components.

  Resolved an issue where proxy settings configured for the Stellar Cyber platform with the set proxy command were not applied correctly to all platform components. This fix is now applied automatically for all new proxy settings. If you already have a proxy configured for your platform, however, you must first clear the existing proxy settings with the unset proxy command before reapplying them with the set proxy command for the fix to take effect.

• AELDEV-46944: Fixed variable substitution in universal webhooks.

  Resolved an issue in the Universal Webhook Responder where multiple variables within a JSON payload string were not processed correctly. The previous logic inadvertently truncated the string to include onsly the first variable replacement, stripping any text and additional variables.

• DATA-2581: Enhanced the host resolution in msgtype99 records.

  Improved the resolution of the srcip_host field in msgtype99 records by enriching it from additional fields. Previously, srcip_host only reflected the value from the srcip_host field in the original record. The srcip_host field is now enriched using values from hostip_host, host.name, and dstip_host when the srcip matches the hostip, host.ip, or dstip fields in the original record. This enhancement provides more complete hostname resolution in enriched flow records, improving data quality for investigations and analytics.

• DATA-2242: Improved the Fortinet FortiAnalyzer parser to parse the URL correctly and recognize fields and values in vendor fields.

  Improved the Fortinet FortiAnalyzer parser to parse the URL more correctly and recognize fields and values for severity, attack, agent, httpmethod, attackid, and ref in vendor fields.

Known Issues

• When you add a connector in 5.5.0 (System | Connectors | Create), XDR and IT Management appear in the Category list. Although no connectors are available within these categories in the Type list, XDR and IT Management do appear as categories in anticipation of a future release. These categories are not functional in 5.5.0 and are intentionally empty. No action is required.

• The unset dns command may not work correctly when DHCP is enabled for a sensor's management interface. Changes to DNS settings with the unset dns command may be overwritten by a DHCP refresh. Use the show dns command a few minutes after running the unset dns command to verify settings.

• In multi-tenancy deployments, when Interflow records lack a tenant_id, the Stellar Cyber Platform incorrectly assigns them to “unknown” instead of assigning them to the same tenant as the sensor that forwarded the records.

• Log filters for the ColorTokens parser cannot be created automatically because the device type contains multiple values. Workaround: After sending a ColorTokens log, find the msg_origin.source field in the event record and use its value when creating the log filter.

• Importing security rules via the Import Custom Security Rules page might cause the upload process to hang without providing a status update. If this happens, refresh the browser.

• A query might not produce consistent search results if the field is set for a time, the value includes milliseconds, 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 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 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.

  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.

Stellar Cyber Platform System Requirements

You must install the Stellar Cyber Platform in an environment that meets or exceeds minimum system requirements. Refer to the following sections for the minimum system requirements for different target environments:

• Amazon Web Services

• Google Cloud Platform

• Oracle Cloud Infrastructure

• Dedicated VMware ESXi (see below)

System Requirements for Cluster Installation in VMware ESXi

You can install the Stellar Cyber platform on a dedicated ESXi server running VMware ESXi 8.0, 7.0 or 6.7. The target ESXi server must have sufficient resources to support separate virtual machines for the Data Analyzer, Data Lake, and, if installing as an Integrated Data Processor, the Modular Sensor. The specifications in the table below are sufficient to support a Stellar Cyber deployment with up to 300GB of daily ingestion.

Keep in mind the following:

• Each VM (DA, DL, and MDS) must be thick-provisioned and requires 500 GB of SSD disk space.

• You can install all three of the VMs in the same datastore if there is sufficient space for both the VMs and the 12+ TB required for the Data Lake's ElasticSearch data. However, Stellar Cyber recommends that the Data Lake uses a dedicated datastore.

Stellar Cyber supports SSD disks for both the OS and Data Lake drives (SATA, SAS, or NVMe). HDD disks introduce latency and are not supported.

Scaling Up Performance with a DP Cluster

You can configure up to ten DP servers to operate in a cluster to achieve improved Stellar Cyber performance. Stellar Cyber cluster testing indicates the following performance guidelines when adding additional DPs to a cluster:

• With data replication disabled, the aggregated ingestion throughput grows linearly with the number of DP servers.

• With data replication enabled (the default), the aggregated ingestion throughput is about 30% lower than the throughput without data replication.

Upgrading the Stellar Cyber Platform

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

• Prepare for the upgrade

• Upgrade the Stellar Cyber Platform to 5.5.0

• Upgrade the sensors

• Verify the upgrade

For more detailed instructions, refer to Upgrading Software.

Important Note for Air-Gapped Environments: The 5.5.0 release requires connectivity to specific external URLs to enable components included in the installation image, such as Early Access Program functionality and various features and fixes. In air-gapped or dark site environments, where external network access is restricted, these components cannot be enabled after installation. Before upgrading to 5.5.0, confirm that the required connectivity to these URLs is available.

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

1. Select Admin | Software Upgrade.

2. Choose 5.5.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.

CentOS 7.1 Prerequisite – Update curl to 7.29.0-59.el7_9.2 or Higher

Before upgrading any Linux Server Sensors running in CentOS 7.1, you must check your curl version and update it to 7.29.0-59.el7_9.2 or higher in order to use the strong encryption required by the Stellar Cyber platform.

1. Check your curl version as shown below:

   yum list installed curl

   \* Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile Installed Packages curl.x86_64 7.29.0-19.el7

2. If the listed version is lower than 7.29.0-59.el7_9.2 (as it is in the example above), use the following commands to update the curl package:

   yum makecache

   yum install curl

3. If installation of the curl package fails, it is most likely because CentOS is trying to use a repo that has reached its end of life. Try updating the base URL and then reinstall curl. The following sed command makes the necessary changes for most environments to ensure that the updated curl package can be installed:

   sudo sed -i.bak -e 's|^mirrorlist=|#mirrorlist=|' -e 's|^#baseurl=http://mirror.centos.org/centos/\$releasever|baseurl=http://archive.kernel.org/centos-vault/7.9.2009|' /etc/yum.repos.d/CentOS-Base.repo

To upgrade Linux or Windows Server Sensors:

You can upgrade a Server Sensor to the most recent release from the two previous releases. This means that you can upgrade a Server Sensor to the 5.5.0 release from any 5.3.x or 5.4.x release.

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 System | ORGANIZATION MANAGEMENT | 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.