Stellar Cyber 4.3.1 Release Notes

Stellar Cyber 4.3.1 brings improvements to the Stellar Cyber Open XDR platform, including new features, improvements, enhancements, key fixes, and known issues. Upgrade instructions follow all of that great information.

For an overview, see the Stellar Cyber 4.3.1 Preview Video

Highlights

• Introduced new connectors for integration with Cynet EDR, GuardDuty, Proofpoint on Demand, HanDreamnet, Barracuda Email, and Cybereason.

• Introduced new log parsers and many improvements in existing log parsers.

• Introduced alerts based OneLogin activities.

• Allowed import and restore operations from configured data sinks.

• Enhanced the asset license usage page with better visibility and detailed asset information for further investigation.

• Introduced a high level Product Roadmap embedded into the Knowledge Base where users can see high priority features, their state of development, and provide feedback directly to the Stellar Cyber Product Management team

Deprecations

• Deception sensors are deprecated as of 2022.

Behavior Changes

• All Windows Events are now included as inputs for Brute Forcer classification on hosts (previously only some Windows Events were used). The classification logic is unchanged – in order to be classified as Brute Forcer, there must be 50 login failures or more from a single IP address in a five minute period. By expanding the data inputs, there may be an increase in Brute Force related alerts since more hosts may be classified with Brute Forcer.

Parser Enhancements

• Introduced support for Cribl logs with the Syslog JSON parser.

• Introduced a new parser for OPNSense Zenarmor plugin logs on ingestion port 5604.

• Introduced a new parser for NXlog on ingestion port 5601.

• Introduced a new parser for Android syslogs on ingestion port 5605.

• Introduced a new parser for the Airgap Ransomware Kill Switch log on ingestion port 5602.

• Introduced support for multi-tenant log ingestion for one sensor to be shared across multiple tenants.

• Added support for both Cisco ASA and Cisco Firepower log parsing on port 5168.

• Updated the CEF log parser to support ZScaler syslogs.

• Improved the Nasuni parser to recognize more log messages.

• Improved the Hewlett-Packard EL Switch parser to cover more log types.

• Modified the Syslog JSON parser to not store the JSON content as “json_content” if it was parsed successfully.

• Moved the following fields from msg_data to the vendor namespace for Zscaler CEF log ingestion on port 5143: 'riskscore', 'dept', 'urlcat', 'malwareclass', 'malwarecat', 'threatname', 'md5hash', 'reason', 'sourcetranslatedaddress', 'requestcontext', 'outcome', 'requestclientapplication', 'requestmethod', 'spriv', 'externalid', 'filetype', 'destinationservicename', 'devicedirection', 'rulelabel', 'ruletype', 'urlclass', and 'devicemodel'.

• Enhanced the Checkpoint firewall parser to support more log formats.

• Enhanced the CyberArk CEF log parser: Moved the “extradata”, “eventid”, “ptalink”, “externallink”, “suspicioussessionactivity”, and “detectiondate” fields to the vendor namespace.

• Enhanced the F5 Big-IP log parser:

  • Normalized the field “event_time“ to “event.timestamp“ when its value can be parsed into an epoch and to “event.time_str“ when its value can’t be parsed.

  • Supported a new format of key-value pairs.

  • Enhanced the Cisco ISE parser, Proofpoint parser, NetIQ Access Manager parser, and Sophos Firewall parser:

  • Logs that contain 5-Tuple are now sent to the traffic index. Other logs are sent to the syslog index.

• Renamed the “log.syslog.pri” field to “log.syslog.priority”

• Enhanced the VMware parser:

  • Improved the VMware parser to cover more types of logs.

  • Moved the fields “event“ and “event_description“ to the vendor namespace.

  • The field “event_time” will be parsed as an epoch stored in the field “event.timestamp“, it will be stored as-is in the field “event.time_str“ when it can’t be parsed.

  • The field “timestamp“ is now in milliseconds.

• Enhanced the Palo Alto Networks Firewall parser:

  • Added support for all types of version 10.1.

  • Removed the key “session_owner“ from the key list of the “THREAT“ log.

  • Moved the “serial_number“ field to “user_device_serial_number“ for the “TRAFFIC“, “THEART“, and “GLOBALPROTECT“ logs.

  • To prevent conflicts, the error report record only contains the following fields: “dev_type“, “timestamp“, “parser_err_msg“, and “parser_raw_msg“.

  • Mapped the “protocol“ field to a normalized integer “proto” field. If a mapping is not defined in the list below, “protocol” is moved into the vendor namespace.

  • The mappings for “protocol“ to “proto“ are as follows:

  • icmp => 1

  • igmp => 2

  • tcp => 6

  • udp => 17

  • Changed the data type of the “palo_alto_networks.sequence_number“ field from integer to string.

• Enhanced ForeScout parser:

  • Added "dev_class: forescout" and "msg_origin_category: asset".

  • Normalize the "event_time" to be "event.timestamp", "syslog_time" to be "log.syslog.timestamp", "pri" to be "log.syslog.priority".

  • Moved the "severity" to the vendor namespace.

  • Moved the fields with the overlength name to "msg_data".

Connector Enhancements

• Introduced response integration with Cynet EDR , supporting both Contain Host and Shutdown Host actions.

• Enhanced the SentinelOne connector to use an API key for authentication instead of username and password.

• Introduced a new GuardDuty connector that integrates with AWS GuardDuty using direct APIs.

• Introduced response integration with HanDreamnet, supporting Block an IP actions.

• Introduced a new Proofpoint on Demand connector to ingest logs.

• Enhanced the Office 365 connector with improved statistics and error reporting.

• Introduced a new Barracuda Email connector that allows administrators to create a Barracuda incident directly from ingested Barracuda Email logs.

• Introduced a new Cybereason connector that collects syslogs and supports the Isolate a Machine (Contain Host) response action.

• Enhanced the Azure Event Hub connector to include SQLServer AuditEvents.

• Renamed the G Suite connector to Google Workspace.

• Renamed the BlueCoat WSS connector to Broadcom (Blue Coat / Symantec) WSS.

• Renamed the Windows Defender connector to Windows Defender for Endpoint.

• Renamed the Sophos connector to Sophos Central.

• Moved the Box connector from the PaaS category to SaaS.

• Updated the TrendMicro Cloud One Workload Security connector to use API URL.

Detection/ML Improvements

• Introduced account login anomaly alerts based on OneLogin activities.

• Improved the GEOLocation model for more accurate location based alert types.

• Improved the External Brute-Forced Successful User Login alert types. Previously untriggered alerts can now be triggered.

• Improved the External/Internal alert separation of alerts from Windows login events.

• Introduced new fields that assist to search credential stuffing alerts:

  • ​​unknown_users_to_login_failures_raw

  • login_failure_rate_raw

  • unknown_users_rate_raw

• Prior to v4.3.1, the login_type field reported with an Account Login Failure Anomaly for OKTA MFA and, sometimes Azure AD MFA, may have been reported as type okta_log. Now, for this alert type, the login_type value will be one of: azure_ad_mfa_log, one_login_otp or okta_mfa_log. If you have scripts that rely on the previous field value, you must update them accordingly.

Platform Enhancements

• Introduced support to Restore and Import cold data from data sinks. As part of this update, the existing System | Data Management interface was reorganized as follows:

  • Added new Data Sink Import and Data Sink Restore tabs.

  • Renamed the Backup/Restore tab to Snapshot Backup/Restore.

  • Renamed the External Storage Configuration tab to Snapshot Storage Configuration.

  • Renamed the Cold Storage Imports tab to Snapshot Import.

• Introduced a new Rest API for updating alert tags.

• Introduce a new CLI to clear the DA cache.

• Introduce a new CLI to change the DL CNI address to avoid conflicts.

Usability Improvements

• Added support for Whois Lookup for public IP addresses and host names.

• Changes you make in the Time Filter are now preserved within your local browser's session storage. If you log out of Stellar Cyber and log back in, or if you switch users, the time setting remains the same as you left it. Storage for different browser types is independent, so the time setting you make while using one type does not affect the time setting in another type (such as when you switch between use of Chrome and Firefox).

• Introduced a configuration page to manage imported SSL certificates and allow CA certs to be installed in both the DP and sensors.

• Introduced a feature that allows admin users to assign multiple tags to an asset.

• Enhanced the asset license usage page with better visibility and detailed asset information for further investigation.

• Added new operators start with and end with and contains and does not contain to support ATH queries.

• Enhanced the incident graph summarization to also support processes, files, and URLs.

• Introduced the capability to collect data for usability improvements.

• To improve security in v4.3.1, the Recipient for webhooks no longer supports embedding username and passwords as part of a URL construct. The URL is constructed internally so the credentials are not exposed. Instead, enter the username and password in the Basic Authentication section, without use of @ in either field and without use of dot (.) in the username field.

Critical Bug Fixes

• Fixed a bug that prevents Windows sensors from collecting events in Chinese, Japanese, and Spanish versions of Windows Servers.

• Fixed an issue where old standby backup files were not properly cleaned up.

• Fixed an issue where scheduled reports did not show Closed/Ignored alerts.

• Fixed an issue where assets with NULL MAC addresses were incorrectly classified as routers.

• Fixed the broken sensor CLI “set tenant_id” in 4.2.1.

• Fixed an issue where the Tenable.io connector could fail to ingest data.

• Fixed a bug where debug data could fill up a modular sensor’s disk.

• Fixed a bug where a modular sensor's receiver IP was not updated with the aggregator IP.

• Fixed the “Unknown error” seen when clicking the Test button of the Sonicwall Firewall connector.

Known Issues

• In the rare case when the Stellar Cyber menu options have been significantly reorganized, it is possible that administrators will need to review settings for their custom user RBAC profiles. For example, any changed path to User Management, Connectors, or Visualize is considered by Stellar Cyber to be a "new feature." So if you have user profiles with Behavior for New Features in Future Releases set to No Access, they will not be able to access these features. Since the menu options were significantly changed in v4.3.0, migrations from older releases to v4.3.x and beyond warrant this review.

• Prior to v4.3.1, the login_type field reported with an Account Login Failure Anomaly for OKTA MFA and, sometimes Azure AD MFA, may have been reported as type okta_log. Now, for this alert type, the login_type value will be one of: azure_ad_mfa_log, one_login_otp or okta_mfa_log.

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

• In certain rare situations, the UI may not be accessible after upgrading to 4.3.1. If this happens, contact the Customer Success team for assistance in restarting the user interface service.

• Deleting a Data Sink Import task and then creating a new one with the same dates results in duplicate data for any pre-4.3.1 data requested by the import.

• Use the System | Sensors | Manage | Software Upgrade feature to upgrade Windows Server Sensors running 3.7.x and later to 4.3.1. Although you can use the System | Agents | Windows page to download MSI and/or MST files for Windows Server Sensor installations, these files should only be used for fresh installations and reinstallations and not for upgrades.

• As of v4.3.0, the availability of certain components (such as charts, correlations, ATH rules) with tenant visibility settings has changed. Specifically, the top level component cannot have a less restrictive visibility than its children components.

  • For any component, such as a query you create, with visibility set to All Tenants, then all its sub-components (such as a lookup list) must also be set to All Tenants.

  • Similarly, if a component is set for a specific tenant, then all its sub-components must be specified for either that tenant or All Tenants.

• Operators are enabled in pick list menus when they are supported with the selected field or rule. For this reason, use the menu-based queries rather than the Search keyword field with these operators. Examples include contains, does not contain, and is operators. Additional fields / rule support will be added in the future.

• During upgrade to v4.x and later, the alert type definitions are migrated to a new internal format, but the alert name remains the same in the UI. If the data you are viewing contains alerts generated from prior to the upgrade, be advised that those will be treated as separate from the alerts generated by the new, migrated definition (even though the alert name appears to be the same). Optionally, rename your alerts to more easily identify alerts generated from the old definitions from those created post upgrade.

• Currently, administrators need to use the Stellar Cyber UI to upgrade existing 4.2.2 Windows agent sensors to version 4.3.0. Download the GPO configuration in UI System | Agents | Windows only for new sensor installation or sensor re-installation.

• Although data sink performance is improved, adding a data sink can still reduce DA performance by 30% - 40%, and data sink performance heavily depends on the I/O bandwidth between DA nodes and data sink storage.

• You cannot delete a Data Sink that has an active import or restore in the Data Sink Import or Data Sink Restore tabs. Delete any active import/restore tasks for the data sink, wait at least ten minutes, and then delete the data sink.

• With improvements made to the table management, some saved columns may not appear and users need to readjust columns.

• Log Forwarder only collects statistics for up to 100 different log source IPs per Log Forwarder worker. If the total number of log source IPs exceed 100, the additional log source IPs' statistics will be aggregated into a catch-all IP “0.0.0.0”.

• A modular sensor upgrade will fail when the associated modular sensor profile has the IDS or Sandbox features enabled and the corresponding feature license is not assigned to the sensor. Workaround: Authorize the sensor with an IDS and Sandbox license, or in the modular sensor profile, disable the IDS and the Sandbox features and try to upgrade again.

• Stellar Cyber recommends using the same CPU and Memory specifications for DL nodes. Variations in specifications across worker nodes can cause Data Lake stability issues.

• For deployments with HTTP proxy configured for Sensors or Data Processors, note that the vendor APIs Stellar Cyber relies on for the following connectors do not support communication through a proxy: Proofpoint, Cisco Umbrella, VMware Carbon Black, Duo Security, Tenable.io, Prisma Cloud, AWS Cloudtrail, BlueCoat WSS, Proofpoint on Demand and Azure Event Hub: Proofpoint, Cisco Umbrella, VMware Carbon Black, Duo Security, Tenable.io, Prisma Cloud, AWS Cloudtrail, BlueCoat WSS, and Azure Event Hub.

• When multiple traffic filters are defined for a tenant with the same combination of IP, port, protocol, and layer 7 rules, the filter may fail to take effect. Administrators should review the defined traffic filters and make sure there are no duplicate definitions.

• Files may not be assembled by Security Data Sensors for traffic mirrored from physical interfaces on Cisco Nexus 9K models. As a workaround, configure VLAN mirroring on the Cisco switch.

• Sensor installation on Linux servers running CentOS 6 fails because the official CentOS 6 package download link is no longer available.

• If you change the network interface configuration of a sensor’s VM after deployment, the eth0 interface may be remapped to a new interface. If this happens, the management network is disconnected. Contact Technical Support for assistance.

Upgrading

You can only upgrade Stellar Cyber from 4.2.x or 4.3.0 to 4.3.1. You must:

• Prepare for the upgrade

• Upgrade the DP

• Upgrade the sensors

• Verify the upgrade

Please refer to the online documentation section Upgrading Software for more detailed instructions.

Preparing for the Upgrade

To prepare for the upgrade:

• Back up the data and configuration
• Make sure the sensors are up and running
• Take note of the ingestion rate
• Take note of the number of alerts
• Make sure the system health indicator shows
• Run the pre-upgrade check

Upgrading the DP to 4.3.1

1. Click Admin | Software Upgrade.

2. Choose 4.3.1.

3. Click Start Upgrade.

 Review Alert/Machine Learning Training Time for guidance on training time of updated ML models.

Upgrading Sensors

New features, updated ML algorithms, and enhanced configurations may change ingestion and detection patterns. We recommend the following to ensure a smooth upgrade:

• Upgrade security sensors before network sensors, because network sensors send data to security sensors for additional processing.
• Upgrade sensors in batches instead of all at once.
• For agent sensors:
  • Upgrade a small set of sensors that cover non-critical assets.
  • After 24 hours, ensure that your ingestion is as expected, then upgrade a larger set.
  • After 24 hours, ensure that your ingestion is as expected, then upgrade the remaining agent sensors.

To upgrade Linux-based or Windows-server sensors:

1. Click System | Sensors. The Data Sensor List appears.

2. Click 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. Click Submit.

Verifying the Upgrade

To verify that the upgrade was successful:

• Check the Current Software Version on the Admin | Software Upgrade page.
• Make sure the sensors are up and running.
• Check the ingestion rate and make sure it is as expected.
• Check the number of alerts and make sure it is as expected.
• Check the system health indicator:
  • indicates a perfectly healthy system.
  • indicates minor issues. Monitor the system for 30 minutes. If the issues remain, investigate further.
  • indicates major issues. Contact Technical Support.