Stellar Cyber 6.3.0 Release Notes

Software Release Date:
Release Note Updated:

The Stellar Cyber 6.3.0 release deepens autonomous decision-making by enriching context, empowering analysts, and improving triage precision across identity, detections, and workflows.

The release notes are organized into the following sections:

Highlights

Usability and UX Enhancements

  • Query Manager Import/Export: Adds import and export support to share and reuse queries easily across instances and tenants.

  • “Add to Watchlist” Experience: Simplifies adding entities to watchlists directly from investigation workflows, improving speed and usability.

Detections and Machine Learning

  • User Login Location Anomaly Enrichment: Enhances login anomaly detections with ASN and User Agent data for greater triage accuracy.

  • Fortinet UTM Enhancements: Expands and refines Fortinet UTM detection coverage for improved visibility into network-based threats.

Integrations

  • XDR Connect Webhook: Enables streamlined ingestion of third-party alerts through a flexible, webhook-based integration framework.

  • Domain Service: Introduces centralized domain management for connectors to improve scalability and reliability.

Actions Required

There are no actions required in this release.

Behavior Changes

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

  • DATA-3110: Updated the Forcepoint Data Loss Prevention (CEF) parser to align field mappings with the normalized data model. The parser now maps duser to dstip_username and sourceHost to srcip_host, ensuring Forcepoint DLP logs conform to the standard naming convention used across normalized data sources. The existing mapping from destinationHosts to dstip_host remains available. These changes improve field consistency for correlation and reporting. Saved queries, dashboards, or detections that referenced the legacy field names now display values under the updated normalized fields. No configuration changes are required, and the new fields populate automatically when present in incoming CEF messages.

  • DATA-2986: Corrected event category mapping in the Cynet 360 (CEF) parser. The msg_origin.category field now maps to endpoint instead of xdr to align with the standardized taxonomy used across Stellar Cyber parsers. This correction ensures consistent classification for filtering, dashboards, and correlation across endpoint and detection data sources. Saved searches, reports, or dashboards that reference msg_origin.category:xdr should be updated to use endpoint. Existing detections and automated workflows are unaffected.

  • DATA-2966: Normalized vendor-derived identifiers in Common Event Format (CEF) parser output. The default values for msg_origin.source, msg_class, dev_type, and dev_class now apply stricter normalization rules derived from cef_device_vendor. Normalization allows only lowercase letters, digits, and underscores, removes invalid characters, and prefixes values beginning with a digit with cef. These changes ensure consistent and valid field naming across correlated data and prevent ingestion errors. Saved filters, queries, or dashboards that reference vendor-derived field values containing invalid characters may display updated normalized values.

Deprecated Features

The following feature is planned for deprecation in a future version.

Upcoming Deprecation: Netskope Connector (API V1) – The Netskope connector supports API V1 and V2, but Netskope has deprecated API V1 so Stellar Cyber will retire the V1 API in a future release. Begin planning to migrate to the V2 API.

Detection/ML

New Features

Improvements

  • Updated Golden Certificate alerts to display all user accounts involved in suspicious Kerberos authentication events, instead of only one, to provide a complete view of affected users during investigations.

  • Updated the login-related detections to include Virtual Private Network (VPN) login events, specifically for the User Login Location Anomaly, Impossible Travel Anomaly, and Login Time Anomaly alert types.

  • Implemented evidence storage for detections suppressed by silent mode across Stellar Cyber AI (SCAI) Machine Learning, SCAI Rule Engine, and Alert Integration. When a detection is suppressed, the corresponding signal includes the stellar.suppressed_reason field set to SILENT_MODE. This enhancement preserves visibility into detections that were triggered but silenced, allowing you to investigate them through the Threat Hunting view by filtering on stellar.suppressed_reason:SILENT_MODE. Guardrails control evidence volume to prevent ingestion spikes from high-frequency detections, ensuring efficient indexing and consistent system performance.

  • Enhanced normalization for Fortinet SSL VPN and administrative login events to populate the login_result field consistently. Stellar Cyber now maps success and failure outcomes from vendor fields such as status, logdesc, and action, enabling reliable failed-login detection across Fortinet log formats. You can query login_result: fail with username and source context from srcip or remote_ip to identify failed logins or unknown-user attempts. This improvement standardizes Fortinet authentication data for use in rule-based detections and correlation.

  • Enhanced severity derivation for Bitdefender (Syslog JSON) events to ensure consistent normalization when no native severity is provided. Stellar Cyber now derives severity from the event category, detection, and action fields using a prioritized fallback sequence. This improvement provides more reliable severity classification for correlation, dashboards, and reporting.

  • Prioritized correlation by user identity for alerts with msg_class values office365_audit_azureactivedirectory and azure_ad_risk_detection for consistent case grouping. Correlation continues to evaluate the same user identifiers, including email address and user ID, but now normalizes email addresses to lowercase for consistent matching across data sources. When a user node already appears in a graph and the related host node has no incoming edges, the user node connects to the host even if the event is not User Behavior Analytics (UBA). By default, user nodes are not displayed in graphs; they appear only when required for correlation. These changes apply only to newly ingested alerts.

  • Improved destination IP aggregation for Oracle Cloud Infrastructure (OCI) Secure Shell (SSH) scanner alerts. When multiple private destinations receive rejected SSH traffic from the same source, the alert now lists all unique destination IP addresses in a single view. This improvement helps you identify the full scope of targeted destinations without navigating between separate alerts. No configuration change is required.

  • Enhanced User Login Location Anomaly and Impossible Travel Anomaly to use Autonomous System Number (ASN) and user agents. To improve triage of location-based alerts, Stellar Cyber will begin collecting user history for ASN, ASN org, and user agents (if available from Microsoft 365), and then use this history to enrich alerts.

  • Adjusted ESET alert severity scoring to account for remediation status. When a threat is successfully handled, the alert severity is automatically reduced, helping you focus attention on unresolved or active threats without additional configuration.

  • Prioritized System Monitor (Sysmon) Event ID 1 when both Sysmon Event ID 1 and Windows Security event ID 4688 are detected in a Suspicious Windows Process Creation alert. This update ensures that alert details display richer Sysmon data, such as file hash and process path, letting you analyze process creation events with more complete forensic context. If Sysmon Event ID 1 is unavailable, Event ID 4688 continues to populate alert details.

Stellar Cyber Platform

New Features

Improvements

  • Fixed inaccuracies in heartbeat security detection reporting to ensure consistent per-tenant metrics. Aggregation now correctly captures all detection types, and retries no longer produce inconsistent totals. This improvement provides more reliable visibility into detection volume and trend changes by tenant.

  • Implemented the automatic removal of sensors when a tenant is removed from Stellar Cyber. Previously, sensors that later reconnected using the deleted tenant identifier (for example, cust_id) were set to root tenant. From this release, they will be rejected and deleted at connection. To retain a sensor, re-enroll it under another tenant before deletion or re-register it after removing the original tenant.

  • Expanded the tenant name field to support names up to 256 characters and full UTF-8 encoding across Stellar Cyber. The update ensures that long or non-ASCII tenant names display and function correctly in both the API and user interface. In mixed-version environments, components on older releases might reject or truncate values longer than 50 characters, so align names to the lowest supported limit in these cases.

Sensors

New Features

  • Introduced parsing of the Netskope-defined GENEVE options that carry per-packet user or site identifiers. The Modular Sensor now extracts the USER_ID or SITE_ID TLV added by the Netskope Cloud TAP stitcher from the outer GENEVE header and associates each identifier with its corresponding flow inside the tunnel. Because parsing occurs at the packet level, multiple users sharing the same tunnel are correctly recognized. Normalization maps the Netskope user identifier to srcip_username and the Netskope site identifier to srcip_siteid. No UI configuration is required, as the option identifier is fixed. Traffic from Netskope Cloud TAP is automatically parsed, and normalized fields are forwarded to the Data Processor for correlation and analytics.

Improvements

  • Introduced a new set logforwarder apply-custom-parser CLI command that forces the Sensor log forwarder to redownload and apply custom parsers. The enhancement lets you refresh parser and configuration files without manual intervention, ensuring that updated or corrected parsers are immediately applied. If no custom parser exists or a parser is invalid, the command reports the condition and skips changes. This capability helps maintain parser consistency across tenants and is supported on sensors in both SaaS and on-premises deployments.

  • Added SSL connectivity status to the show receiver debug command in the Sensor CLI. Run show receiver for a quick status check, or show receiver debug to view certificate details and identify SSL inspection or certificate mismatches.

  • Added a help command to the local CLI to display all available commands for a sensor. In a local CLI session, run help to view the complete command list, or help <command> to see syntax and parameters. The output reflects commands currently supported by the connected sensor, including module-specific commands when available. The help all option is supported in direct CLI sessions but not in remote CLI sessions.

    This feature complements the existing CLI support for the ? and help suffixes when used with a top-level show, set, unset, copy, or exec command (for example, set ? or set help). These techniques are available in a remote CLI session.

  • Introduced configuration change logging for device configurations received from Configuration Manager. During initialization, each sensor writes a baseline configuration snapshot to config_change.log. Subsequent updates record ADDED, DELETED, and MODIFIED entries with paths and values, including previous and new values. Logs reside at /var/log/aella/config_change.log on Linux and C:\ProgramData\StellarCyber\Windows Agent Sensor\log\config_change.log on Windows. The file is included in phonehome logs for remote diagnostics. If Filebeat is enabled, modified Filebeat settings also appear in configuration_conf.log.

  • Added timestamped logging for CLI commands that execute actions rather than displaying information. Each log entry records the executed command and parameters in JSON format with a timestamp, letting you review administrative activity for auditing and troubleshooting. Logs can be viewed through the CLI with the show history command or accessed in the aella_cli_set.log file for offline analysis.

  • Added support for deploying the Windows Server Sensor on Microsoft Windows Server 2025. The enhancement extends compatibility for event collection from Windows Event Log and File Integrity Monitoring (FIM), letting you maintain continuous monitoring and detection coverage when upgrading to the 2025 operating system. All existing detection and correlation rules apply without reconfiguration.

  • Added compatibility with Oracle Linux 9.x to the Linux Server Sensor using the standard installation procedure. You can deploy a 6.3.0 Linux Server Sensor on hosts that report Oracle Linux 9.x in /etc/os-release with no installer edits required.

Connectors

New Features

Improvements

Parsers

New Features

  • Added a built-in parser for ingesting ManageEngine PAM360 logs in RFC 3164 syslog format on port 6062. Parsed events populate standard fields such as event_type, action, user, resource, result, src_ip, and dst_ip to enable search, correlation, and reporting. This parser improves visibility into privileged-access activity, enabling accurate correlation and reporting for PAM360 security events.

  • Added a built-in parser for ingesting NetScout Omnis Cyber Intelligence logs in CEF on port 6063. The parser supports NetScout-specific variations of CEF messages, including those that deviate from standard formatting, to ensure accurate field extraction. Parsed fields include event, network, and MITRE ATT&CK attributes such as technique, tactic, device, and initiator or responder details. This parser improves detection context and enriches network threat visibility for NetScout Omnis data.

  • Added a built-in parser for ingesting SonicWall NSa logs in Common Event Format (CEF) on port 6064. The parser accounts for SonicWall-specific formatting variations, such as unescaped equal signs in request values, to prevent key-value parsing errors and ensure complete field extraction. This parser improves normalization accuracy and reliability for SonicWall NSa firewall telemetry.

  • Added a built-in parser for ingesting Akamai Web Application Firewall (WAF) logs in Common Event Format (CEF) on port 6060. The parser extracts traffic-related fields, including source and destination information, action, and severity, to improve normalization and visibility into web traffic security events. This parser enhances correlation and detection for application-layer threats originating from Akamai WAF sources.

  • Added a built-in parser for ingesting KVH CommBox Edge Gateway logs in key-value pair (KVP) format on port 6059. The parser normalizes gateway telemetry fields to support accurate investigation and correlation of network data. This parser enhances visibility into satellite and maritime network traffic managed by KVH CommBox Edge Gateway systems.

  • Added a built-in parser for ingesting PCI MVApp (Postal Center International Mail Verification Application) logs in RFC 5424 syslog format on port 6061. The parser extracts structured-data elements into standard key-value pairs and normalizes core fields for search and detection. It supports multiple structured-data sections within a single event to ensure complete field extraction. This parser improves normalization accuracy and visibility for Postal Center International MVApp system activity.

  • Added a built-in parser for ingesting Hisun Global Core Banking logs on port 6058. The parser supports financial transaction and audit events in product-specific message and JSON formats, including DCP_payment operations. It normalizes inconsistent field names and handles duplicate or nested data structures to ensure consistent field mapping. This parser improves the accuracy and reliability of transaction log ingestion from banking systems, enabling more complete visibility into core-banking activity.

  • Added a built-in parser for ingesting Tenable AD logs in RFC 3164 format on port 5955. The parser converts visual indicators such as checkbox and list symbols to standardized boolean or empty values and parses complex fields like DangerousAceList as structured data. This parser improves the accuracy and readability of Active Directory audit data, ensuring consistent normalization for security analytics and reporting.

  • Added a built-in parser for ingesting Trend Micro Deep Security logs in Log Event Extended Format (LEEF) on port 5956. The parser supports both Deep Security Manager and Deep Security Agent and uses the product header to populate key attributes, including dev_type, dev_class, msg_origin.source, and msg_class. Event categories derive from defined event ID ranges for intrusion prevention, firewall, integrity monitoring, log inspection, anti-malware, web reputation, application control, and device control.

  • Added a built-in parser for ingesting Fortinet FortiGate Firewall (Windows Agent Filebeats) logs in Beats format on ports 5957–6057. The parser extracts key firewall fields including logid, subtype, sessionid, policyid, and action, and maps them to standard attributes. The update also adds normalization for login events, extracting and standardizing fields such as user, src_ip, dst_ip, src_port, dst_port, result, event_type, and reason from authentication records. This parser improves processing efficiency and accuracy for FortiGate logs forwarded through Windows Filebeat agents, ensuring consistent field normalization and visibility in firewall traffic analysis.

Improvements

  • DATA-3110: Improved field normalization in the Forcepoint Data Loss Prevention (CEF) parser.

    Updated field normalization in Forcepoint Data Loss Prevention (DLP) Common Event Format (CEF) parser. The parser maps duser to dstip_username and sourceHost to srcip_host so that they align with the normalized data model. The existing mapping from destinationHosts to dstip_host remains available. Queries, dashboards, and detection rules now use dstip_username and srcip_host in place of legacy field names. No configuration changes are required, and these fields populate automatically when present in incoming CEF messages.

  • Enhanced the Infoblox Data Connector parser for CEF logs on ports 5143 and 5870. The update supports long extension keys and Infoblox-specific field names, improving KVP regex handling to correctly parse quoted values and escaped characters. These changes eliminate key-length errors that previously caused dropped fields. Parsed fields such as InfobloxAnCount, InfobloxB1Network, and InfobloxB1DHCPFingerprint now populate reliably for search and analytics. Existing syslog integrations require no configuration changes.

  • Added support for ingesting Zscaler Internet Access (ZIA) Firewall and Web logs in CSV format. The ZIA Firewall parser accepts quoted, comma-delimited records with up to 39 fields, and the ZIA Web parser supports up to 34 fields. Field values map to standardized network, application, and policy attributes for analytics and correlation. Headerless records parse when the field order matches the ZIA CSV export. This enhancement expands log format coverage for ZIA data while maintaining compatibility with existing JSON ingestion.

  • Added normalization for Sophos firewall logs so that the parser takes log entries where the msg_data.name field equals connevent and maps the associated string value into the normalized sophos.connevent field. This enables consistent representation of connection lifecycle values such as Start and End. These normalized values can be used in searches, correlation rules, and dashboards to analyze firewall session activity. No configuration changes are required.

  • Enhanced the Infoblox Common Event Format (CEF) parser to extract additional fields from msg_data. The parser now parses and normalizes infobloxb1dnstags (event categories), dvchost (source hostname), infobloxb1policyname (policy name), infobloxb1threatindicator (indicator of compromise), and infobloxthreatlevel (threat severity). Parsed values populate the infoblox.* namespace, while dvchost remains available at the top level. The infobloxthreatlevel field parses as an integer (0–100) to support threshold-based detection and filtering. These improvements enhance search accuracy, correlation, and dashboard analytics for Infoblox events.

  • Improved the parser for Fortinet FortiClient Endpoint Management Server (EMS) Cloud logs to support additional log formats. The parser now recognizes more message variants and timestamp patterns and maps fields to the standard schema for analytics and detection. No action is required for existing log sources.

  • Improved parsing for Ubiquiti UniFi Dream Machine Pro (UDM Pro) logs to support additional message types and Common Event Format (CEF) events. The update enables parsing of Netfilter entries even when IN or OUT fields are empty, with extraction of fields such as PROTO, SPT, DPT, UID, GID, and MARK. It also adds normalization for UniFi-specific CEF attributes including UNIFIclientIp, UNIFIclientMac, UNIFIwifiName, UNIFIlastConnectedToDeviceName, UNIFIwifiChannel, UNIFInetworkVlan, and UNIFIduration. These improvements ensure accurate field extraction and consistent correlation for both Netfilter and CEF-based events.

  • Unified normalization of the seq (sequence) field across multiple parsers to ensure consistent event representation and prevent TCP misclassification in ICMP and vendor-specific logs. Sequence values now normalize to vendor-specific namespaces, as shown below:

    • Airgap Ransomware Kill Switch: airgap_ransomware_kill_switch.seq

    • Aviatrix Firewall: aviatrix_firewall.seq

    • Ericsson Cradlepoint Router: ericsson_cradlepoint_router.seq

    • Mako Firewall: mako_fw.seq

    • Netfilter: netfilter.seq

    • Ubiquiti: ubiquiti.seq

    • Ubiquiti USG: ubiquiti_usg.seq

    • VMware NSX Edge Firewall: vmware_nsx_edge_firewall.seq

    This update improves event consistency, parsing accuracy, and correlation reliability for ICMP and other non-TCP network activity across these devices.

  • Expanded normalization in the Forcepoint Data Loss Prevention (DLP) Common Event Format (CEF) parser. The parser now maps fields such as sourceservicename, analyzedby, severitytype, productversion, maxmatches, and eventid to the forcepoint namespace, and promotes sourceip and destinationhosts to the top-level fields srcip and dstip_host. These improvements ensure consistent field naming and allow Forcepoint DLP data to be searched, visualized, and correlated alongside other security event types.

  • DATA-2986: Corrected event category mapping in the Cynet 360 (CEF) parser.

    Corrected the msg_origin.category mapping in the Cynet 360 parser for Common Event Format (CEF). The parser assigns endpoint rather than xdr to align with the Stellar Cyber taxonomy and ensure consistent filtering, dashboards, and correlation. Saved searches, reports, dashboards, and custom content that reference msg_origin.category:xdr need to be updated to use endpoint. Existing detections remain unaffected.

  • DATA-2966: Normalized vendor-derived identifiers in Common Event Format (CEF) parser output.

    Implemented strict normalization for vendor-derived identifiers generated by the CEF parser. Normalization now permits only lowercase letters, digits, and underscores, requiring a starting letter or underscore. Values beginning with a digit are prefixed with cef, and invalid characters such as periods are removed. This ensures valid field naming for msg_origin.source, msg_class, dev_type, and dev_class, preventing ingestion errors and maintaining consistent source naming across correlated data.

Usability

New Features

  • Added a Show All control to the Tasks widget that opens the Task Management page in list view. The control lets you view all tasks in one place, improving navigation efficiency when managing multiple tasks. You can also display the same page by selecting System | Task Management from the main menu.

  • Introduced an Add to Watchlist option on the Alert Details page so you can add values to a watchlist without having to navigate away from Alert Details to the Watchlists page in the UI. Simply select Add to Watchlist for a value and choose an existing watchlist filtered by compatible type or create a new list. Supported inputs include IP addresses, file hashes (MD5, SHA-1, SHA-256), URLs, and domain names.

  • Introduced the ability to export and import saved queries in Query Builder for use across instances and tenants. The enhancement lets you export queries, including associated watchlists, as JSON files that can be imported into another Stellar Cyber instance or tenant. During import, you can choose how to handle matching watchlists by overwriting, merging, or retaining existing ones. This capability streamlines collaboration across environments and ensures consistency of queries without requiring manual recreation.

Improvements

  • Optimized CSV report exports to include only the fields required for each dataset. The improvement reduces memory usage and prevents export failures when processing large reports. Scheduled reports and exportable dashboards now complete more consistently, improving performance and reliability for CSV downloads and emailed report outputs.

  • Implemented user-scoped API token support for the /connect/api/data/{index}/_search and /connect/api/data/{index}/_count endpoints. User-scoped tokens enforce Role-Based Access Control and tenant scope to ensure that users can retrieve only data permitted by their assigned roles. Queries support time-range filters and Lucene syntax for flexible search. Access applies to indices such as traffic, assets, syslog, and alerts. Direct document reads via /connect/api/data/{index}/_doc remain restricted when using user-scoped tokens, while legacy API key methods continue to function for backward compatibility.

  • Enhanced report generation to use absolute timestamps for time range calculations, ensuring that retriggered reports reproduce the same dataset as the original run. When a report runs, Stellar Cyber now records both the selected relative range and the resolved absolute start and end times. Templates that specify relative ranges continue to convert automatically at generation time.

  • Added a historical listing of reports that lets you view details for each time a report was run, including configuration, start time, duration, status, request ID, and retention information. Report history tracks jobs per tenant, letting you view and rerun reports for individual tenants without regenerating all tenant reports. You can filter the history by report ID or status, view entries, and rerun selected reports. Failed reports now retry automatically after interruptions such as process restarts or memory errors, and queued jobs resume in order once earlier tasks finish. This enhancement lets you track past report activity and rerun reports directly from one place.

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.

The following are the EAP features in this release:

XDR Connect Webhook Ingestion

This is a simple webhook framework that lets you post JSON data directly from any external system into Stellar Cyber, accelerating custom integrations and expanding your visibility across the entire security stack. The XDR Connector is in Public Preview in this release.

Operational Notes

There are no operational notes in this release.

Resolved Issues

  • Fixed the rejection of numeric values greater than 10 in the Comparison settings in the Condition Configuration section of a Automated Threat Hunting (ATH) playbook. The field now supports the full valid range of numeric thresholds, enabling more flexible condition logic in automation rules. Existing configurations were preserved and require no update.

  • Fixed removal of Saved query from Threat Hunting filters. Changing or deselecting the Saved query now updates the filter state immediately. Users can clear the applied Saved query without using Clear all. Navigate to Threat Hunting | Filters and adjust Saved query as needed; results refresh to reflect the current selection.

  • Resolved an issue in Threat Hunting where certain filter conditions returned incorrect results when using the is, starts with, or ends with operators. The fix corrects how condition values are parsed so that query testing and the Save as function now preserve complete values and produce accurate results. Queries that were previously saved with truncated values should be reviewed and updated to restore the full conditions.

  • Fixed an issue that caused incorrect button labels to appear in unsaved changes confirmation dialog boxes after performing other actions, such as tenant deletion. Each confirmation now displays the correct label for its context, ensuring that prompts for unsaved changes show accurate options and operate independently across pages.

  • Improved the upgrade process for Modular Sensors deployed on resource-constrained hosts. The upgrade now manages memory usage more efficiently and prevents Out-of-Memory (OOM) terminations during package installation. Sensors configured for log forwarding proceed without restarting packet inspection components, allowing upgrades to complete successfully on low-memory virtual machines. For environments with one vCPU or limited memory, Stellar Cyber recommends enabling only log forwarding before upgrade or allocating additional memory to avoid service disruption. The upgrade status and running services can be verified on the Sensor Details page. This improvement applies to current and future upgrades and does not change existing configuration defaults.

  • Added virtual scrolling for the Name column filter list to prevent rendering thousands of options in large environments. The Alert Filters page now responds promptly when listing, searching, and editing filters. No configuration changes are required. Performance scales with high filter counts and remains consistent during pagination and column filter interactions.

  • Resolved an issue where some Login Location Anomaly alerts displayed a distance value of “–1” or referenced an invalid prior login location. The fix ensures that distance is calculated only when a valid previous login exists within the configured reset window. If no recent location is available, the login initializes a new baseline instead of generating an inaccurate alert. This change improves the accuracy of distance-based anomaly detection and reduces false positives for accounts with infrequent logins.

  • Added the per-organization storage for user records in the Activity Log (System | ORGANIZATION MANAGEMENT | Users | Activity Log). Stellar Cyber automatically retains the latest two million entries for each organization, pruning older records on a weekly schedule at 02:00 UTC on Sunday. In multi-tenant deployments,Stellar Cyber now isolates records by organization to avoid cross-tenant volume constraints..

  • Fixed underreporting of assets in multi-tenant inventories. Asset inventory now shows accurate totals per tenant and across tenants. Dashboards and reports reflect consistent counts, ensuring accurate visibility of asset distribution.

  • Improved resilience of asset-to-alert synchronization for consistent enrichment and risk scoring. The enrichment pipeline now auto-recovers after cache disconnects and exposes a synchronization health check. Alerts populate asset_id when an IP address, MAC address, or hostname matches known assets, enabling accurate risk calculations.

  • Resolved an intermittent display failure that prevented the API documentation from loading correctly on the Stellar Cyber API Reference page (Help | API Docs), causing an Unable to render this definition message to appear. The API Reference page now loads consistently on first access.

  • Fixed an issue that prevented ATH rules from generating alerts when conditions were met, including when hit counts fell within specific ranges such as zero. The correction ensures alerts now trigger reliably according to configured thresholds.

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:

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.

Deployment Type Resource Host DL DA MDS
Recommended (Production)
(DL and DA VMs)		 CPU/vCPU 44 physical (88 cores/hyperthreads) 40 44 -
RAM (GB) 256 136 64 -
OS SSD Disk Space 1 TB 500 GB 500 GB -
Data Lake SSD Disk Space 16 TB 12+ TB - -
Integrated Data Processor
(DL, DA, and MDS VMs)		 CPU/vCPU 44 physical (88 cores/hyperthreads) 28 28 28
RAM (GB) 256 136 64 32
OS SSD Disk Space 1 TB 500 GB 500 GB 500 GB
Data Lake SSD Disk Space 16 TB 12+ TB - -
Minimum Configuration for Separate DP VMs
You can still deploy separate DL and DA VMs so long as the ESXi host is provisioned with sufficient CPUs to support the following minimum configuration:		 CPU/vCPU 16 16 -
RAM (GB) 128 64 -
OS SSD Disk Space 500 GB 500 GB -
Data Lake Disk Space 2+ TB - -

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 6.1.0 or later to 6.3.0. You must:

  • Prepare for the upgrade

  • Upgrade the Stellar Cyber Platform to 6.3.0

  • Upgrade the sensors

  • Verify the upgrade

For more detailed instructions, refer to Upgrading Software.

Due to additional functionality and features, resource utilization (CPU and memory) might increase depending on your usage patterns. You can keep tabs on the platform's CPU and disk usage by clicking the Node List button in the System | Data Management | Data Analyzer page. If necessary, you can scale up your platform by adding DA and DL worker nodes, as described here for AWS, GCP, and OCI.

Important Note for Air-Gapped Environments: The 6.3.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 6.3.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 6.3.0

To upgrade the Stellar Cyber Platform to 6.3.0 from a version earlier than 6.10.0, first upgrade to 6.1.0.

  1. Select Settings | ORGANIZATION MANAGEMENT | Software Upgrade.

  2. Choose 6.3.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 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 sensors:

You can upgrade a sensor to the most recent release from the two previous releases. This means that you can upgrade a sensor to the 6.3.0 release from any 6.1.x or 6.2.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 | DATA SOURCE MANAGEMENT | Sensors | Sensors.

    The Sensor List appears.

  2. Select Manage | Software Upgrade.

    The Sensor Software Upgrade page appears.

  3. Choose the target software version.

  4. Choose the target sensors.

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