Stellar Cyber 4.2.0 Release Notes

Stellar Cyber 4.2.0 brings major 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.

Note: As of the 4.1.0 release, the following data model terminology is standardized in Stellar Cyber products and documentation:

  • Raw Events: Raw or enriched records from traffic or log ingestion.

  • Alert Types and Alerts: Alert Types categorize security alerts generated by a set of analytics or machine learning algorithms. An alert is a triggered instance of an alert type. Alert Types can be classified by XDR Kill Chain Stage > ATT&CK Tactic > ATT&CK Technique..

  • Incidents: Multiple alerts grouped into an incident for efficient and effective SoC investigation.

Highlights

  • Introduced a log parser for IPFIX and many other log ingestion enhancements.

  • Introduced a Qualys connector.

  • Enhanced the SentinelOne connector with response capabilities.

  • Introduced a new partner admin support to give an aggregated view of the tenant group and more easily switch between different tenants.

  • The Collect | Sensor Overview page now lets you open a CLI window to issue sensor CLI commands for easier troubleshooting. Most CLI commands are supported except set proxy.

  • Allow users to download DP logs easily for troubleshooting purposes.

  • Improved the Brute Force Login and Impossible Travel detections.

  • Updated Kubernetes to address a certificate expiration issue.

Parser Enhancements

  • Introduced a log parser for IPFIX with support for UDP.

  • Introduced the following new log parsers:

    • OneLogin

    • FatPipe

    • Dell-S3128 switch

    • McAfee ATD

    • HP UX

    • jSonar

    • Mailboarder

  • Moved the reason and csmtrpatterndisposition sub-fields from msg_data to the vendor namespace in CrowdStrike CEF log ingestion.

  • Enhanced Fortinet CEF log parsing by moving the following fields from msg_data to vendor namespace: start, logver, deviceseverity, ad.eventtime, ad.tz, ad.logdesc, ad.direction, deviceinboundinterface, ad.srcintfrole, deviceoutboundinterface, ad.dstintfrole, externalid, ad.policyid, ad.dstcountry, ad.srccountry, ad.trandisp, ad.app, ad.duration, ad.sentpkt, ad.rcvdpkt, ad.appcat.

  • Enhanced the Palo Alto Networks log parser to support the new syslog timestamp format with + in front of the timezone.

  • Made the following enhancements to the Juniper SSG parser:

    • Changed tag in conf file from ssg to juniper_ssg

    • Supported new log format

    • Changed the data type of the following fields to integer: duration, proto, inbytes_total, outbytes_total, srcport, dstport, pri.

  • Verified that the CEF log parser works with Cynet logs.

  • Enhanced the Checkpoint Firewall Parser on port 5519 to support new log formats.

  • Moved Juniper SRX events to the Traffic index.

  • Enhanced the Cisco ESA parser to support new log formats.

  • Added support for timestamp parsing. Note that we do not support some timezone abbreviations that can represent multiple different time zones. We recommend that you use UTC offsets (for example, +05:00) to parse the time zone abbreviations. We also recommend that you set your sensor's local time zone to your local time zone.

  • Improvements on Linux parsers:

    • Improved the Linux syslog parser to cover more types of logs.

    • Moved the linux_syslog.user.name and linux_syslog.user.id fields to the top level for the Linux syslog parser.

    • Added dev_class and msg_origin.category fields to the Linux parser.

  • Improvements on Cisco Firepower parser:

    • Improved the Cisco Firepower parser to cover more types of logs.

    • Added a new rule for those supported logs that have key-value pairs inside. Fields not found in the predefined fields list are moved into msg_data.

    • Normalize accesscontrolrulename as fw_policy_id and accesscontrolruleaction as action.

  • Improvements on the Cisco WLC log parser:

    • Improved the Cisco WLC parser to cover more types of logs.

    • Added the dev_class and msg_origin.category fields to the Cisco WLC parser.

    • Moved the process_name, apmac, offend_mac, and event_name fields to vendor-specific in the Cisco WLC log ingestion.

    • Normalized the following fields for the Cisco WLC parser:

      • pri => log.syslog.priority

      • hostname => log.syslog.hostname

      • event_description => log.event_description

      • username => user.name

  • Supported Infocyte CEF log parsing with normalization:

    • Moved the following fields from msg_data to the vendor namespace: commandline, parentprocessname, path, user, sha1, av, synapsescore, severity, and description.

    • Moved the tenant and tenantid fields to the top level in Infocyte CEF log ingestion.

  • Improvements on the Check Point firewall parser:

    • Cover more types of logs.

    • Added the msg_origin.category field to the Check Point firewall parser.

  • Improved the following log parsers to parse the log.syslog.version field as an integer:

    • Graylog

    • Palo Alto Networks

    • Red Hat Openshift

    • Accops

    • F5 Silverline

    • McAfee ePO

    • Pulse Secure

  • Improved the WatchGuard Firewall parser to normalize policy_name as fw_policy_id.

Connector Enhancements

  • Introduced a Qualys connector that collects assets and asset vulnerabilities.

  • Enhanced SentinelOne connector with the following response capabilities: Contain Host (Isolate Endpoint), Initiate Scan, Kill Threat, Quarantine Threat, Remediate Threat.

Usability Improvements

  • Partner admin users can now view dashboards and configurations with aggregated data of the Tenant Group scope.

  • Enhanced the alert view with Incident links so that users can view and follow a link to the associated incident page.

  • Improved chart management with the ability to show or hide System charts and clone all charts in a dashboard.

  • Improved the status messages and error feedback from ATH playbook executions.

  • Replaced line charts with bar charts in alert pages for better presentation.

  • Added license usage reports under Respond | Reports | License Usage.

  • Improved the GEO location visibility of alerts by introducing a heatmap in the alert views.

  • Allow users to easily download DP logs for troubleshooting purposes.

  • Custom parsers installed after 4.2.0 support display of version numbers in the Custom Log Parsers table.

  • Allow admins to export an incident to an archive file that includes a list of alerts, incident graphs, and incident metadata.

  • The Collect | Sensor Overview page now lets you open a CLI window to issue sensor CLI commands for easier troubleshooting. Most CLI commands are supported except set proxy.

  • Admins can now download sensor logs from UI for sensor troubleshooting.

  • Per-tenant ATH rules can now use an alert as an action.

  • The Event Status filter is now pinned to the top of the Stellar Cyber navigation pane.

  • Debug logs can now be collected from the Sensors page.

  • SSH Tunnel connection is moved to the Configure |Data Processor | Resources page.

  • Stellar Cyber Knowledge Base has been revamped to facilitate navigation and learning. Review the Knowledge Base Intro topic for details. Note that any bookmarks you may have made for Knowledge Base topics in previous releases will need to be recreated.

Detection/Machine Learning Improvements

  • Extended the Brute Force Login detection to include data sources from Salesforce, Okta, G Suite, Office 365, Azure, and AWS Cloudtrail.

  • Improved Impossible Travel detections with better handling of imprecise GEO location data.

Platform Enhancements

  • To improve the security of the Stellar Cyber product, configuration of an HTTP port is disabled. HTTP connections are still redirected to the HTTPS port.

  • Introduced a new REST API to retrieve a list of configured connectors.

  • Allow users to issue tcpdump, traceroute, dig, telnet, and ping commands from the DP CLI.

  • Updated Kubernetes to address a certificate expiration issue.

Critical Bug Fixes

  • Improved the data lake’s GC (Garbage Collection) efficiency to avoid system performance degradation.

Known Issues

  • The heatmap widget in the 4.2.0 release is a complete replacement of the one used in previous releases and includes new geolocation capabilities. Note that any existing dashboards using a heatmap chart continue to use the old heatmap widget until you edit the charts manually using this procedure.

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

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

  • The stellar_syswatcher service may be missing after a new installation or upgrade of a Windows agent sensor for Windows Server 2008 R2. This is due to a required patch from Microsoft . Patch target Windows Server 2008 R2 hosts before you install or upgrade so you can leverage traffic information from the Windows agent sensor.

Upgrading

You can upgrade Stellar Cyber from 4.1.5 (or later) to 4.2.0. Upgrades to 4.1.5 are supported from 4.1.0, 4.1.1, and 4.1.2.

You must:

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

To upgrade the DP from 4.10, 4.1.1, or 4.1.2, you must first upgrade to 4.1.5:

  1. Click Admin | Software Upgrade.

  2. Choose 4.1.5.

  3. Click Start Upgrade.

Upgrading the DP to 4.2.0

Once you've upgraded to 4.1.5, use the following procedure to upgrade to 4.2.0:

  1. Click Admin | Software Upgrade.

  2. Choose 4.2.0.

  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 Windows-based sensors:

If your deployment is already running v3.12.1 or 4.1.2, you do not need to upgrade your Windows-based sensors. For deployments running older versions, you can manually download and upgrade using the 3.12.1 Windows installers listed below.

The Collect | Sensor Overview | Software Upgrade page does not list a Windows upgrade package. Also, you cannot download the .msi installation file from the Configure | Agents | Windows tab in this release.

To upgrade Linux-based sensors:

  1. Click Collect | Sensor Overview. The Data Sensor List appears.
  2. Click the MANAGE drop-down and choose SOFTWARE UPGRADE. The DATA SENSOR SOFTWARE UPGRADE panel appears.
  3. Choose the 4.2.0 image.
  4. Choose the sensors to upgrade.
  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.