What's New?

Orbital Release Types

There are three release types that Orbital can be released under, Service, Node, and Service and Node. They are defined as follows:

Service Release - A Service Release is a release that is focused on maintaining, upgrading, and updating the Orbital Service, or that part of Orbital that is the service that runs in the cloud and provides the user experience. This release type is not concerned with the Orbital Node.

Node Release - A Node Release is a release that has focused on maintaining, upgrading, and updating the Orbital Node that is installed on the client’s endpoint hardware. This release type is not concerned with the Orbital Service.

Service and Node Release - A Service and Node Release is a release that combines the two previous release types.

Note: The identification of a release being a Service, Node, or Service and Node release will start with Service Release 1.20 and will continue forward from there.

Orbital Service Release 1.20, 2022-06-06

Orbital 1.19, 2022-04-11

Orbital Linux Node 1.18, 2022-03-02

Note: For Red Hat Enterprise Linux 6 (and compatible systems), the Secure Endpoint connector version 1.18 is required to install and use Orbital.

Orbital 1.18, 2022-02-09

Note: Orbital does not currently support Apple’s M1 hardware.

Orbital Linux Node 1.17, 2021-12-01

Orbital 1.17, 2021-11-29

Orbital 1.16, 2021-10-19

Known Issues in 1.16

There is an issue in version 4.8.0 and onwards of osquery that can cause an error to be returned when running queries against the windows_eventlog table. The error triggers only when certain log data is present in the Windows Event Log. Subsequent custom queries run against an affected node will return results without issue. Subsequent Orbital catalog queries will also return results but will return an error alongside the query: bookkeeping osquery failed. This will not affect the returned results, however the error will persist until the Orbital node service is restarted on the endpoint.

If this issue is encountered, the WMI class table Win32_NtLogEvent can be used as a workaround for affected queries.

Orbital 1.15, 2021-08-25

Orbital Node, 2021-08-26

Orbital node support for macOS version 10.15 or later.

Note: Customers must be running Secure Endpoint (formerly AMP for Endpoints) Connector version 1.16.0 and enable the Orbital policy. Customers are advised that this release should be considered an in-field Beta and refer to the macOS Troubleshooting page for any issues.

Support for Apple’s current beta of their next major release - Monterrey (v.12) - is not supported at this time.

Orbital Node 1.14, 2021-07-26

Orbital now supports the use of proxy settings that users configure in their Secure Endpoint policy settings.

Note: Secure Endpoint Connector version 7.4.1 or later must be installed before you can use proxies. Refer to your Secure Endpoint users' guide for more information on configuring your Secure Endpoint connector policy settings.

OSQuery version 4.8.0 is included in the Orbital Node 1.14 update.

An Orbital node version policy has been implemented. This policy allows nodes to be identified by Orbital as being Supported, Unsupported, or Rejected.

Refer to the Support Policy for Orbital Node Versions of the Nodes topic for more information on the node version policy

Orbital 1.14, 2021-06-29

Orbital 1.14 provides a number of bug fixes, internal improvements, and user facing features:

Endpoints can now be targeted in queries with a netmask prefix. Several prefixes now support wildcards in both query targeting and node search.

Previously, each time an S3 Remote Data Store (RDS) was created or associated with an Orbital Query, a small ping file was created in the user’s bucket to verify connectivity and write access. Now, S3 RDS pings update a single file named orbital-rds-ping.json, which can be safely removed at any time.

Soon, Secure Endpoint users will have more control over when they upgrade their node. Orbital will categorize nodes into three states according to their version: supported, accepted, and rejected. A range of node versions will be supported, which means they contain the latest features. A range of nodes will be accepted, which means that while they can still connect to the service with the same functionality they’ve always had, they no longer support the latest functionality. The final category are those nodes that are refused connection to Orbital. Rejected nodes must upgrade in order to connect again.

Orbital 1.13, 2021-05-04

Orbital 1.13 provides a number of improvements and bug fixes.

Orbital 1.12, 2021-04-03

Orbital 1.12 provides a number of internal changes in preparation for supporting SecureX.

Orbital 1.11, 2021-01-06

Orbital 1.11 provides a number of bug fixes and improvements.

Orbital 1.10, 2020-10-30

Orbital now supports sending results via Remote Data Store to Splunk and Amazon S3, with a choice of internal payload formats.

Orbital 1.10 also provides a number of bug fixes and internal improvements, and several user facing features:

Orbital 1.9, 2020-09-08

Orbital 1.9 provides a number of bug fixes and internal performance and infrastructure improvements.

Beginning with Orbital 1.9, scheduling a Job with a Remote Data Store will ping the data store to verify it exists and can be authenticated to before allowing the query to proceed. This will prevent avoidable result delivery failures.

This release also begins the process of discovering when multiple endpoints are configured with identical Secure Endpoint Computer GUIDs, so each of those nodes can be uniquely identified. In 1.9, nodes in that scenario will not be allowed to run queries.

Orbital 1.8, 2020-07-10

Orbital 1.8 provides a number of bug fixes and internal improvements.

The Query API allows specifying a random set of nodes as targets for a query.

Orbital 1.7, 2020-06-10

Orbital 1.7 moves our installers from S3 to our own update servers, so Orbital can be installed on hosts under Secure Endpoint host isolation. This lets you investigate a host while it is isolated without having previously enabled Orbital. This change also makes it possible to add Orbital’s installation servers to firewall policies by IP address. (See Required Server Addresses for Proper Secure Endpoint & Threat Grid Operations for more information.)

This update also integrates information from WMI in osquery. This lets us disable our osquery event subscriptions, which were causing performance issues on hosts that had unusually high volumes of Windows events.

The following tables are available in Orbital 1.7 on Windows, in addition to those in osquery, using WMI classes. (The table names are taken directly from their associated WMI classes.)

In addition, we have added the following tables:

We have also had to remove the following tables, which depended on the osquery eventing framework and were nonperformant on hosts with high volumes of Windows log events:

We regret this change, since it may disrupt existing queries and requires changing powershell_events to orbital_powershell_events when using queries from the osquery community.

Orbital 1.6, 2020-05-04

Orbital 1.6 makes some subtle changes in how we identify the type of observable values in query results. Previously, we used a set of regular expressions to make an educated guess about whether a value was a SHA-256 hash, domain name or network address so we can use Cisco Threat Response (CTR) to provide context and actions. Now, Orbital 1.6 will look at the column name infer the type based on some simple rules:

This change does not affect our catalog of stock queries, which already contain metadata that specifies the observable type for each column. With this change, you can now send the results of your custom queries to your CTR Private Intelligence repository. (Previously, you could only send the results of stock queries, which carries metadata that identifies the observable types.)

Frequently Used Observable Types

CTR and the Cisco Threat Intelligence Model (CTIM) define a large number of observable types, here are a few that are frequently used:

For an exhaustive list, see Observables in CTIM Sightings.

Orbital 1.5, 2020-04-07

Orbital 1.5 lets customer administrators authorize other users to use Orbital and introduces support for Windows Server 2016 and later. We have also started aggregating metrics for Cisco SecureX components and APIs. There are a lot of changes below the waterline this release that we are eager to share when SecureX is ready for beta.

Orbital 1.4, 2020-03-11

Orbital 1.4 builds on last month’s release by adding Cisco Threat Response (CTR) pivot menus to common observables and provides support for automatically sending results to private intelligence stores. This advanced feature enables configuring periodic queries associated with current threats to CTR so you can monitor for affected hosts.

We have also exposed the Orbital API v0 which lets customers build applications that can run queries and collect results. This feature is important to our objective of exposing information about your endpoints to your security applications.

Orbital 1.3, 2020-02-14

Orbital 1.3 adds Cisco Threat Response (CTR) to our user interface. We send common observables while you view results to CTR to identify values that are known malicious or innocuous by your team and intelligence providers. This also adds support for Casebook so you can quickly send observables from your query results to CTR for later investigation.

Orbital 1.2, 2020-01-31

Orbital 1.2 introduces independent clouds for EU and APJC customers. We consider your information to be most sensitive, and we want to be sure you can choose the regulatory region that you and your organization can trust. We are growing our operations team to ensure we have coverage around the world in case there are any support issues.