Stellar Cyber 5.4.0 Release Notes

Software Release Date: January 28, 2025
 Release Note Updated: April 18, 2025

The Stellar Cyber 5.4.0 release brings the following exciting improvements to the Stellar Cyber Open XDR platform.

The release notes are organized into the following sections:

Highlights

  • Reporting and Insights: Stellar Cyber introduces a new reporting engine that enables you to create beautiful PDF reports out-of-the-box and a new scheduler that allows more granular control over report delivery.

  • Expanded Threat Intelligence and Indicators of Compromise (IoCs): Deepen your coverage with fresh support for file hashes, revealing even more insights into known malicious activities.

  • Unified Silent Mode: Rule Based Detections, machine learning (ML) Detections, and Third Party Integrations now share a consistent silent mode experience, letting you refine strategies without the alert noise.

  • Enriched Email and Cloud Observables: Gain a clearer picture of threat narratives with intuitive visualizations and improved email and cloud data correlation.

  • Smarter Domain Controller Correlation: Focus on real offenders rather than routine authentication events. Case correlation logic has been refined to ensure that domain controllers appear only when they're relevant.

  • Network-Based Windows Attack Detection: Strengthen your defense without using a Windows Server Sensor. SMB traffic analysis now uncovers suspicious behavior independently.

  • Location History Retention and Account Creation Alerts: Track unusual user movements and sudden account spikes to catch emerging risks before they escalate.

  • New Log Forwarding Use Cases: Enable lightweight log forwarding from workstation-class Windows operating systems to support small-footprint deployments using syslog forwarding on Windows Server Sensors.

  • Alert Filters for Tenant Groups: Create filters to exclude alerts and apply alert filters to one or more tenant groups in bulk from the root level or to multiple tenants in bulk from the root and partner levels.

  • System Action Center Alerts: Added support for sending individual System Action Center notifications for each matching event instead of consolidated summaries.

  • Connectors: Added the following new connectors: FortiEDR, Juniper Mist, WithSecure Elements, Abnormal Security Email Security, Versa Networks Concerto, AWS Inspector, Trend Micro Email Security, NetFoundry, Fortra Frontline, and Google Cloud Security Command Center.

Actions Required

  • When using correlations that rely on the time boundary feature, switch to the time range configuration on each query, which runs more efficiently.

  • To support processes introduced in 5.4.0 that let Stellar Cyber enable or disable features and fixes already included in the platform, ensure that the Data Lake (DL) and Data Analyzer (DA) components of your on-premises Stellar Cyber Platform, and the web browsers of all Stellar Cyber users can make HTTPS connections to the following domains:

    From an on-premises Stellar Cyber Platform

    • https://sdk-ld.stellarcyber.ai

    • https://stream-ld.stellarcyber.ai

    • https://events-ld.stellarcyber.ai

    From Stellar Cyber users' web browsers

    • https://clientsdk-ld.stellarcyber.ai

    • https://clientstream-ld.stellarcyber.ai

    • https://events-ld.stellarcyber.ai

    Without access to these URLs, your Stellar Cyber Platform still functions, but features and fixes cannot be enabled or disabled, and Early Access Program features will not be available.

  • To use AI Investigator (an Early Access Program feature) in an on-premises Stellar Cyber deployment, the Data Processor must be able to access AI services on TCP port 443 at genai.stellarycyber.cloud.

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

  • The correlation logic that determines how domain controllers show up in cases has been refined. In cases where a domain controller is just doing routine authentication, it’s no longer highlighted as the center of the threat narrative. Instead, the focus is on the systems and accounts genuinely involved in suspicious activity. This results in fewer false leads, better grouping, and more accurate scoring.

  • When using the Palo Alto Networks Firewall parser, note that the threatid field was split into palo_alto_networks.threat_id and palo_alto_networks.threat_name.

  • The CyberArk PTA (CEF) parser now parses the Value and Old Value fields from msg and stores them in the vendor namespace.

  • When using the Zscaler - NSSWeblog (CEF) parser, note that the suser field was renamed to srcip_username, and invalid values for src and dstip are now stored in the vendor namespace.

  • The McAfee ePolicy Orchetrator parser now normalizes the Username field to user.name.

  • The Avanan (HTTP JSON) parser now normalizes the event.entity.entity_payload.internet_message_id field to email.message_id.

  • When parsing Incapsula SIEM Integration (CEF) logs, note that the rule_info field was relocated to the vendor namespace.

  • The Hewlett Packard UNIX parser redirects invalid srcip and dstip field values to a vendor-specific namespace instead of keeping them in the srcip and dstip fields.

  • The Created At filter in the Cases page now defaults to show cases from the last 24 hours. You can set a different range manually, if required.

  • Creating a Security Event Filter using a post to the connect/api/v1/security_event_filters public API endpoint now requires you to include a new tenants parameter, as described in the SecurityEventFilterFormData schema in the public API reference.

Deprecated Features

The following feature has been deprecated in this release.

  • The use of an extended time boundary in correlated queries was deprecated in 5.4.0 because it is no longer needed. It was replaced by time ranges for each correlated query.

Detection/ML

New Features

Improvements

  • Updated the query for azure_18, process_creation_image_26, and windows_security_166 rules to reduce false positives.

  • Modified the rule azure_34 so it's now an alert type named Password Reset By User Account. It had been included in Microsoft Entra Changes to Privileged Account, which was misleading because this rule could be triggered when a user reset their password in Microsoft Entra ID (without knowing if it was a privileged account or not). The severity changed from 50 to 30.

  • Modified the processing of Windows event alerts so that the user field is retained without modification, as it is defined as an object in the metadata. The previous approach of renaming this field to wineventlog_user to avoid conflicts is being phased out. However, to support existing dependencies, user data into the wineventlog_user field is duplicated if the user field is an object. This ensures that integrations relying on wineventlog_user remain functional.

  • Enhanced the enrichment process for sentinelone_activities alerts by aligning computer_name and host.name with sentinelone.data.computerName. This ensures improved correlation of host identifiers across different SentinelOne message classes, such as sentinelone_threat_detection.

  • AELDEV-49242: Enhanced case correlation for domain controllers.

    Improved the case correlation logic for login-related alerts involving domain controllers. Stellar Cyber now distinguishes when a domain controller is merely an authenticator and avoids correlating it as a central entity, reducing noisy cases and preventing inflated case scores. The improved logic applies to Windows events 4624, 4625, 4768, 4769, 4771, and 4776.

  • Expanded the Google Workspace alert integration to include these additional alert types: Gmail phishing, Google identity, User Changes, Access Approvals, Domain-wide takeout, State sponsored Attack, Mobile device management, Security Center rules, Data Loss Prevention, Apps outage, Sensitive Admin Action, Customer abuse, Reporting Rule, Chrome, and Google Mandatory.

  • Enhanced normalization processes for srcip_username and srcip_usersid in Windows events (ID 4624, 4625, 4768, 4771, and 4776). Enrichment logic now excludes enrichment when normalization is absent. Adjustments include shifting enrichment for 4768 and 4771 to TargetSid instead of TargetUserSid and adding normalization for unhandled event IDs. Normalization for approximately 57 new event types were added, resolving existing defects related to incomplete or incorrect srcip_username displays. Changes were implemented to ensure consistent and accurate data handling across supported Windows event logs.

  • Enhanced normalization of the Azure Activity Log to facilitate the correlation of cloud observables. The update ensures that the resourceType.value from Azure data is applied to cloud.resource.type, improving consistency with Microsoft Defender data. A classification process was implemented to categorize unrecognized cloud resource types. This refinement supports clearer UI representation and enriching observables for seamless case management. Adjustments include handling Azure Log data fields to align with use cases and backend processing requirements.

  • Improved the normalization process for Amazon Web Services (AWS) CloudTrail logs by standardizing cloud observables in line with GuardDuty classifications. The update ensures that cloud.resource fields are correctly mapped to recognized types such as S3Bucket. Unrecognized types default to miscellaneous, and when multiple resources exist, prioritization is based on scope, identified by the shortest ARN. This release also assures consistency across related log collectors handling CloudTrail data, reinforcing the reliability of cloud events tracking.

  • Enhanced Amazon Web Services (AWS) GuardDuty normalization to support the case correlation of various cloud observables. The update covers multiple resource types, ensuring proper identification through resource-specific fields like Instance ID, Access Key ID, and ARNs where applicable. To improve overall observability and incident tracking capabilities, these improvements facilitate better precision in handling findings related to instances, access keys, S3 buckets, containers, and more within the GuardDuty ecosystem.

  • Updated the entity-based licensing feature to count public IP addresses designated as private IP addresses in the Data Enrichments page as assets for licensing purposes. This adjustment ensures that public IP addresses designated as private in System | Data Enrichment are counted as assets in the entity-based licensing model, improving the accuracy of the asset count.

  • Added a location history retention mechanism to the User Login Location Anomaly alert type, ensuring that historical location data is periodically reviewed and outdated locations are removed. Additionally, locations that are very common across a tenant can now be used to suppress alerts. This update helps reduce data noise, improves detection accuracy, and ensures that only relevant location data is retained, enhancing overall system performance and monitoring efficiency for user login behaviors.

  • Updated the Emerging Threat alert type to include reputation and reputation source details within the key fields. These changes help in quickly identifying and understanding potential threats.

  • Restructured the User Asset Access Anomaly Detection to monitor Kerberos Ticket Granting Service (TGS) requests, focusing on unusual user-asset relations. By leveraging ML and graph models for improved accuracy, this new alert subtype identifies anomalies when a user accesses an unfamiliar asset. It provides detailed alerts with information about the user, asset, and potential anomalies, enhancing threat detection in Windows environments.

Usability

New Features

Improvements

Stellar Cyber Platform

New Features

  • Made the report name field editable in the user interface. Duplicate names are checked to ensure uniqueness. This update streamlines report management by providing a more flexible user editing experience.

  • Added a flag for logs with timestamps significantly behind or ahead by adding fields to indicate a timestamp mismatch. This enhancement allows for real-time detection via dashboards or automated alerts when the timestamp of a log deviates by over an hour from the current time. The fields tz_offset_records_delta and tz_offset_records_total in message type 32 capture these discrepancies. This update aids in preventing missed detections due to incorrect time settings from sensor timezone differences.

  • Enhanced the tenant onboarding workflow by providing an indication of ingestion readiness. The tenant table shows the status in the new tenant message column to indicate if the system is ready for ingestion. This update ensures that you have clear visibility of the ingestion states of your tenants for more efficient management and operational planning.

  • Added support for Zstandard (zstd) compression to S3 , General S3 , and OCI data sinks, complementing the existing support for gzip. This update offers improved decompression speeds and potentially reduced file sizes. This feature is not enabled by default and is not user-configurable; it requires manual activation by Stellar Cyber Customer Success. Contact the Customer Success team if you are interested in enabling this feature.

Improvements

  • Addressed an issue causing accumulated delays in the execution of scheduled rules. The problem stemmed from resource constraints in the environment affecting both user-defined and migrated rules. Adjustments were made to better handle scheduling under limited resource conditions. Alerts now trigger more reliably without extensive delays, ensuring timely detection and response.

  • Increased fault tolerance to maintain data ingestion even if a data node goes offline. The improvement ensures that SaaS deployments can handle node failures similarly to on-premises deployments, where ingestion is minimally impacted by node outages.

  • Updated sensor profiles to activate the JA3-based rules for coinminers, exploit kits, phishing, adware, and potentially unwanted programs by default. JA3 uses the attributes of a TLS handshake to generate a unique client fingerprint. IDS rules then leverage the JA3 fingerprint to detect threats based on characteristic behaviors of malicious tools, even when communications are encrypted.

  • AELDEV-49729: Deprecated the extended time boundary feature.

    Deprecated the extended time boundary feature because it is no longer needed; Stellar Cyber now supports exact time ranges for each correlated query. If you have correlations that rely on the time boundary feature, switch to a time-range configuration on each query.

  • Added the option to disable private IP Geo enrichment. When you disable this, the enrichment of IP Geo information for private IP addresses does not occur. Disabling Geo enrichment of private IP addresses can reduce redundant data and unnecessary information storage.

  • Added a new annotation field to indicate if the srcip_username is enriched. The update ensures accurate identification of the origin of srcip_username. The annotation marks data as enriched when appropriate, supporting more informed decision-making regarding the reliability of the data. This update applies to all <ip-type>_username fields, enhancing consistency across various IP types.

  • Improved the username enrichment logic to better support IPv6 link-local addresses. This update ensures that such addresses are properly normalized to the srcip field when processing login events. Previously, only certain IPv4 addresses and IPv6 public addresses were handled, but now IPv6 link-local addresses like fe80::xxxx are also included in the enrichment process. This enhancement aids in the accurate enrichment and correlation of login events, particularly for Windows login events with specific event IDs, ensuring better logging and analysis of authentication activity across systems.

  • Implemented a feature that lets you define alert filters based on tenant groups, enhancing manageability for large Managed Security Service Providers (MSSPs). Previously, you had to specify tenants individually, leading to cumbersome conditions for alert exclusions. The update introduces new fields to the alert object, supporting both multiple tenants and tenant groups for a single filter. This facilitates efficient alert management by addressing scalability issues associated with larger client portfolios.

  • Implemented the on-premises license server to serve as the authoritative source for license-related information. It integrates with a feature management tool to create environments if absent and provides an API for interaction with the provision client. The provision client refreshes feature-related components as needed for both new installations and upgrades. These enhancements cater to both on-premises (pre-SaaS) and dark-site/air-gapped deployments.

  • Implemented additional checks to validate domain names against certificate components to prevent potential issues from domain name mismatches. This enhancement ensures certificates are properly vetted, minimizing the risk of misconfiguration that can lead to component operation failures.

  • Revised the license compliance logic to use average daily usage measurements instead of consecutive ones. The new logic tracks average usage over the past three and seven days for warnings and violations respectively. This update helps prevent short-term fluctuations from affecting license compliance states.

Sensors

New Features

  • Removed installation restrictions for the Windows Server Sensor on Windows 10 and Windows 11. This update lets you install the Windows Server Sensor on these operating systems and enable the Filebeat option to use the sensor as a lightweight log forwarder in a site without server infrastructure. This change applies to both on-premises and SaaS environments.

    This is the only scenario where the Windows Server Sensor is supported on a Windows desktop host – when using the Server Sensor as a log forwarder. Keep in mind, however, that when using this feature on a Server Sensor installed on a Windows desktop version, you must enable only the Filebeat option in the Windows tab of the sensor's Standard Sensor Profile.

  • Added support to the Stellar Cyber UI to support updating tokens for sensors in bulk to transfer them between SaaS instances. The update ensures the sensor can apply the new token and connect to the desired instance, with provisions to fallback to the original configuration in case of connection issues.

  • Enhanced Windows FIM event log filtering by allowing detailed filters on the Log Filters UI. You can define filters to include and exclude specific logs, leveraging existing wildcard filename logic with an AND relation. This enables more granular control over data ingestion by excluding precisely defined logs, such as process-id=100 while matching *.exe. Multiple filters can be combined as in current Log Forwarder configurations. Additionally, Windows Server Sensors now keep counters for logs excluded by these filters to facilitate troubleshooting.

Improvements

Connectors

New Features

Improvements

  • Updated the Broadcom Symantec Endpoint Security (SES) connector to let you customize API endpoints by making the hostname field editable.

  • Updated the integration for ExtraHop Reveal(x) 360 detections to utilize the mod_time attribute, addressing the issue of duplicate events due to inherently persistent detection IDs. By altering the query to focus on detections modified in the last five minutes rather than merely active ones, redundancy in reported detections was reduced. This change lowers the overall event volume in the query response. However, this approach might initially overlook older, unmodified detections when onboarding. The update accounts for the semantic differences between long-term detections by ExtraHop Reveal(x) 360 and short-term event alerts by Stellar Cyber.

  • Addressed an issue where changes to the AWS CloudTrail connector prefix were not automatically applied until after the connector was manually restarted. The connector now recognizes prefix updates without requiring a manual restart.

  • Implemented a change to ensure that temporary log files from Cisco Umbrella and AWS CloudTrail are not incorrectly retained in the log collector directories. The change ensures the proper cleanup of downloaded files to avoid unnecessary storage utilization.

  • Updated normalization logic to handle cases where AWS GuardDuty findings with ResourceType as S3Object might not include S3ObjectDetails. The process now first checks for S3ObjectDetails, and if absent, falls back to S3BucketDetails. This enhancement ensures correct normalization of cloud resource data in line with existing AWS metadata structures, even when S3ObjectDetails are missing from the provided data. This change reflects improved adaptability in the processing of AWS GuardDuty findings.

  • Enhanced Office 365 connector normalization and enrichment to improve the Microsoft product alert integration. More elaborate logic was added to the Office 365 connector related to the normalization of fields such as user.name, user.email, user.id, host.name, srcip, and the email object to ensure accurate alerting.

  • Resolved an issue where temporary files in the /work/log-collector/tmp/generic_s3 directory were not being automatically removed, leading to unnecessary space consumption. These files, once downloaded, are now properly cleaned up. This enhancement aligns the Generic S3 connector with logic used for similar connectors, ensuring consistent temporary file management across the Stellar Cyber Platform.

  • Improved Mimecast alert integration to support the correlation of email observables with improved normalization and enrichment processes. This update allows for more effective case correlation by ensuring msgid/MsgId is normalized to email.message_id. This enhancement facilitates a more robust analysis of email events by improving the depth of data available for threat scoring and alert creation.

  • Enhanced the integration of Proofpoint on Demand alerts by improving the normalization and enrichment processes to support the correlation of email observables. This enhancement facilitates better case management by enabling the correlation between different email observables within Proofpoint on Demand data. Additionally, the messageParts data structure is now normalized into a file_list field and the messageID field is normalized to email.message_id. This update provides the necessary framework for improved threat detection and response regarding email-related security incidents.

  • Enhanced the Cyrisma connector to support SaaS deployments and pull Cyrisma data. You need to set up one connector for each CYRISMA tenant from which you want to pull data.

  • Updated the Netskope connector to add a Network content type for ingesting the network activities that Netskope monitors. These include alerts, application events, and network events. The integration is through the Netskope V2 API.

  • Office 365 data enrichment now includes separate fields for users being created and users added to groups in Active Directory. Fields such as user and group attributes are parsed into distinct fields, improving search capabilities within logs. This change enhances the ModifiedProperties structure by converting list entries into distinct objects, facilitating structured searches in Microsoft Entra ID (formerly Azure Active Directory) logs and assisting in comprehensive audit reporting.

  • Updated the CrowdStrike connector to include support for the File Integrity Monitoring (FIM) content type. This enables the collection and processing of FIM event data.

  • Updated the Test button in the Universal Webhook responder for custom webhooks. This lets you test the responder directly within the configuration, eliminating the need for manual tests in alert workflows. You can examine the entirety of the request and response bodies during testing to verify expected results, including raw data return from a third-party system.

  • Added support to the Universal Webhook responder for sending an entire Interflow record as a payload, accommodating receivers expecting full Interflow data. You can select the format by using placeholders such as interflow, interflow_raw, or interflow_str to deliver JSON object or string formats. This enhancement enables integration with programmatic interfaces, ensuring complete data transmission without the need to create payloads manually.

    Note: To use the Universal Webhook responder on a sensor, the sensor must be upgraded to 5.4.0 if the Stellar Cyber Platform is running on 5.4.0.

  • Added support for Assumed Role authentication to the Generic S3 Connector, in addition to the traditional access key and secret key method. This enhancement lets you leverage Identity and Access Management (IAM) roles for more secure and flexible access management.

  • Added support for Assumed Role authentication to the AWS CloudTrail connector. This lets you authenticate with temporary credentials obtained from AWS Identity and Access Management (IAM) roles. This method replaces the previous reliance on a static Access Key ID and Secret Access Key, enhancing security by reducing the need for key rotation and credential management across multiple connectors. You can now specify an IAM role Amazon Resource Name (ARN). The connector will assume the specified role to obtain temporary credentials for accessing AWS resources.

  • Updated the SentinelOne connector to add the Site field to the configuration to allow mapping of Sentinel One site names to Stellar Cyber tenants. The Site field is a string and can be either a site ID or site name.

Parsers

New Features

Improvements

  • Enhanced the Cisco routers and switches parser to parse access list logs and configuration change logs and extract more fields.

  • Modified all Common Event Format (CEF) ingestions on port 5143 to accept a value of - for cef_event_id, which means the log source didn't provide a specific event ID. In the context of CEF logs, a dash ( - ) typically means that a value is not available or not applicable for the log entry.

  • Updated the Palo Alto Networks Firewall parser to preserve the original severity assigned to security events in threat logs. Stellar Cyber also continues to map the original severity to its own severity scale to standardize the normalization of alerts across various log sourse. The original severity is preserved in a vendor-specific namespace palo_alto_networks.severity, and the mapped severity is stored in the ips.severity and ids.severity fields, depending on the type of detection.

  • Added support to the ManageEngine ADAudit Plus parser for logs formatted in the RFC 5424 standard.

  • Added support in the Cisco Firepower parser for a new format for logs that only have a priority and an RFC 5424 timestamp in the header.

  • Enhanced the IBM AS400 parser to support IBM AS/400 logs formatted with RFC 3164 syslog headers with custom fields for the IBM AS/400 journal entry structure.

  • Added support to the VMware vCenter parser to process log entries that span multiple lines rather than treating each line as a separate entry.

  • Enhanced the Trellix FireEye CMS (CEF) and Trellix FireEye - MPS (CEF) parsers to support suser, duser, and sourcednsdomain fields when ingesting CEF logs. Additionally, the ingestion process was updated to store smac and dmac with invalid values in the vendor namespace rather than in msg_data.

  • DATA-2257: Added support for HP ProCurve 2810 logs and srcip and dstip validation checks to the Hewlett Packard UNIX parser.

    Enhanced the Hewlett Packard UNIX parser to support logs from HP ProCurve 2810 switches. Additionally, the parser now validates values in the srcip and dstip fields, only storing valid IPv4 or IPv6 addresses in these fields and moving invalid values to a vendor-specific namespace for reference.

  • DATA-2254: Enhanced the Palo Alto Networks Firewall parser to capture threat identification fields.

    Enhanced the Palo Alto Networks Firewall parser to duplicate the Threat/Content Name (threatid) field into two separate fields:

    • palo_alto_networks.threat_id for numeric threat identifiers (example: 57955)

    • palo_alto_networks.threat_name for textual threat names (example: ZGrab Application Layer Scanner Detection)

    This enhancement was necessary to accommodate a new format for the threatid field, which now appears as string(integer). For example, the original format is (57955), and the new format is "ZGrab Application Layer Scanner Detection(57955)".

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

    Improved the CyberArk PTA (CEF) parser to enhance field parsing and storage within the vendor namespace. The fields request_id, ticket_id, affected_user_name, device_type, database, other_info, externalid, and reason are now parsed and stored. The parser has also been updated to extract Value and Old Value from the msg field when presented in a specific format. Additionally, the parser now recognizes "Cyber-Ark" and "Vault" as valid values for cef_device_vendor and cef_device_product.

  • Added support for a SQL log format that uses pipes ( | ) to separate fields in the message section of a log. Logs in this format include 21 fields, and in some cases, 23 fields: clau, usuari, NomPantalla, ModalitatPantalla, ClauTaulaBase, ip, UsuariWindows, Accio, Funcio, Servidor, BaseDeDades, Navegador, CodiEstadistica, sql, Resultat, Comentaris, IdSessio, Temps, Tag, dataalta, UsuariAlta.

  • Enhanced the Palo Alto Networks Firewall parser to parse srcip and srcip_username from the palo_alto_networks.description field in failed authentication events in SYSTEM logs.

  • DATA-2235: Enhanced the Zscaler - NSSWeblog (CEF) ingestion to parse more fields.

    Enhanced the Zscaler - NSSWeblog (CEF) parser to parse the following fields: zscalernssweblogurlclass, zscalernssweblogdlpdictionaries, contenttype, unscannabletype, deviceowner, devicehostname, keyprotectiontype, urlsupercat, appclass, dlpeng

    In addition, normalization of the suser field was changed to srcip_username, and the invalid values of the src and dstip fields are now stored under the vendor namespace instead of msg_data.

  • Updated the VMware parser to enhance accuracy by addressing issues such as correcting field parsing, standardizing field names, and ensuring proper field types. In addition, the was also enhanced to provide detailed parsing of the message field in log entries, extracting finer details such as usernames and IP addresses from descriptive text. This enrichment breaks down the message content into structured fields, making the logs more actionable and searchable.

  • DATA-2221: Added additional field support and improved normalization for the McAfee ePolicy Orchestrator parser.

    Updated the McAfee ePolicy Orchestrator parser to support additional fields parsed from XML logs.

    MachineInfo.AgentGUID MachineInfo.TimeZoneBias Event.ThreatName
    Event.TimeSZone Event.OPGData Event.UserInfo
    UpdateEvent.Version UpdateEvent.DateTime UpdateEvent.InitiatorID
    UpdateEvent.ProductID UpdateEvent.InitiatorType UpdateEvent.SiteName
    MOVEOpt_Event.EventID MOVEOpt_Event.MOVEOpt_server_state MOVEOpt_Event.MOVEOpt_time_stamp
    MOVEOpt_Event.MOVEOpt_product_id MOVEOpt_Event.EventID MOVEOpt_Event.MOVEOpt_event_name
    MOVEOpt_Event.MOVEOpt_move_err MOVEOpt_Event.MOVEOpt_move_reason MOVEOpt_Event.GMTTime
    MOVEOpt_Event.MOVEOpt_evt_sink MOVEOpt_Event.MOVEOpt_evt_id  

    Additionally, the normalization of the Username field has been updated to user.name for consistency.

  • Added support for CEF logs using the "Octet Counting" frame type on TCP port 5870 for vendor-specific parsers. CEF logs that don't use "Octet Counting" continue to use port 5143, with no changes required for existing ingestions. Additionally, TCP port 5871 was introduced as a new ingestion port supporting the "Octet Counting" frame type for the generic capture parser, which otherwise uses port 5201 to receive logs that don't use octet counting.

  • DATA-2212: Enhanced the normalization of alert data logs transmitted to the Avanan (HTTP JSON) parser.

    Added normalization of the event.entity.entity_payload.internet_message_id field used by the Avanan security system to email.message_id for consistency and improved integration with Case Management for better email event correlation.

  • Added the ability to parse logs in a vendor-customized format that includes an extra syslog header before the message.

  • DATA-2096: Enhanced the Incapsula SIEM Integration (CEF) parser to support more fields and enrichments.

    Enhanced the Incapsula SIEM Integration (CEF) parser to move the rule_info field from msg_data to the vendor namespace. Support was added for the cs9 and cs10 label fields, which are parsed along with their respective labels (cs9label and cs10label) into key-value pairs. Additionally, the parser was updated to enrich event.reason from cef_name and to enrich event.sig_id using the rule_id field from the first JSON entry of rule_info when msg_class is imperva_security_logs.

  • Enhanced the Palo Alto Networks parser to parse the following fields from the description field in System type logs:

    • reason
    • auth_profile
    • vsys
    • server_profile
    • server_address

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.

AI Investigator

The first EAP feature being spotlighted is AI Investigator. AI Investigator leverages generative AI to accelerate threat investigations through natural language queries, automated charts, and a streamlined investigation flow. Enrolling in EAP lets you experience these benefits first and provide direct feedback that influences the final feature. If this sounds exciting, reach out to your Customer Success representative to sign up and start exploring.

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.

  • The currently recommended Windows Server Sensor software version is 5.4.3. You can download this version from the links in Installing a Windows Server Sensor.

Resolved Issues

Known Issues

  • Upgrades of Windows Server Sensors to the 5.4.2 release are only supported from 5.3.0 and 5.4.0. They are not supported from 5.2.0 and lower.

  • 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 don't 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.

Upgrading the Stellar Cyber Platform

You can upgrade the Stellar Cyber Platform from 5.2.0 or later to 5.4.0. You must:

  • Prepare for the upgrade

  • Upgrade the Stellar Cyber Platform to 5.4.0

  • Upgrade the sensors

  • Verify the upgrade

For more detailed instructions, refer to Upgrading Software.

Important Note for Air-Gapped Environments: The 5.4.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.4.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.4.0

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

In a large cluster, expect the upgrade process for the Data Analyzer (DA) and Data Lake (DA) to take more time than in previous upgrades. Due to some architectural changes in the software, the DA might take about 50% longer and the DA about 20% longer. This is normal and not a cause for concern.

  1. Select Admin | Software Upgrade.

  2. Choose 5.4.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.
    • 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:

Upgrades of Windows Server Sensors to the 5.4.2 release are only supported from 5.3.0 and 5.4.0. They are not supported from 5.2.0 and lower.

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