New Features
The following new features are categorized
by product component.
High Availability
Cortex XSOAR 6.1 introduces High Availability for both single-instance
and multi-tenant deployments. In a High Availability architecture, you
have both data and application server redundancy. You can install
multiple app servers that all work with an Elasticsearch database.
Feature | Description |
|---|---|
Maximum times to recover a Playbook | In a HA environment, to protect the server
from a rogue playbook which keeps crashing it, the playbook will
not be recovered when reaching the maximum number of attempts to
recover. |
Supports custom installation path | When installing Cortex XSOAR by default, some data
files are saved in /var/lib/demisto . When
deploying HA app servers, these files are required to be shared
between them. To achieve this, the user must create/mount a shared
folder in the /var/lib/demisto path on all
app servers before installation. If you would like to use a different
path, you can specify the custom path using the data-dir installer
flag. |
Temp folder flag | When installing Cortex XSOAR, data from
the Cortex XSOAR service (such as Content Packs for accounts, configuration
for hosts, etc) is added to the temp folder,
located in /var/lib/demisto/temp . Due to
permission or security issues the temp folder may not be accessible.Add
the -temp-folder flag at installation which
replaces the demisto temp folder with temp-folder .
Useful for HA, so the new directory is accessible outside the shared
folder system. |
Block starting a host until upgrade | When a database has already been upgraded by
an app server, another app server is prevented from starting until
the host/app server is upgraded. |
Elasticsearch
As of version 6.1, if you are using Elasticsearch as
your database, all of your data is stored in Elasticsearch. In addition,
you can use the inherent Elasticsearch features to provide data
redundancy and backup your information. Also, as of this version,
any XSOAR service that is using Elasticsearch database will no longer run
automatic backups.
When downloading the Elasticsearch migration tool, make
sure to add the
downloadName=elasticsearch_migration_tool
parameter.Feature | Description |
|---|---|
Show previous results in an elastic migration | When migrating to Elasticsearch, if the migration
is partially completed, you can now see a breakdown of completed,
partially migrated and not completed items. |
Support migration of a specific partition
Database | When migrating to Elasticsearch, you can add
a partitions flag so specific database partitions can be migrated. For
example, go run ./cmd/elasticMigrator -config-path ./conf_for_systemtests_elasticsearch --migrate-all -y -partitions 122020,092020 |
Data is no longer automatically purged when
uninstalling Cortex XSOAR | When using Elasticsearch as your database and
uninstalling Cortex XSOAR, data is no longer automatically purged
from the /var/lib/data directory. This can be useful when the data
is part of a shared drive and automatically removing the data would
affect the other servers using the directory. To remove the
data, when uninstalling, you have to include a purge-mounted-fs flag to
explicitly indicate that you want to delete the data. |
Limitations
The migration to Elasticsearch includes the following limitations:
- You no longer have the option to use Elasticsearch to only manage your indicators. If you were using Cortex XSOAR with Elasticsearch before version 6.1, you must migrate your entire database as part of the upgrade. For more information, see the section about migrating an existing Elasticsearch deployment in the Administrator’s Guide.
- Once you migrate to Elasticsearch, you cannot roll back and use BoltDB.
- Objects, such as incidents, indicators, evidence, custom fields, etc. that includes an invalid data value, for example, a field that is defined as text but the field contains an object, the invalid value will not be migrated.
- As the messages feature was deprecated in Cortex XSOAR version 6.0, existing messages will not be migrated.
Indicator Extraction
The new indicator extraction feature enables you to
extract indicators from incident fields for each incident type.
Extracting indicators can adversely affect system performance.
In each incident type, you can now select when to extract an indicator
(on incident creation and upon a field change) and which indicator
types to extract from each incident field. For each incident field,
you can select which indicator types to extract according to one
of the following rules:
- None.
- All indicator types with regex.
- One or more indicator types with regex.
- Any indicator based on the field value.
For example:
Marketplace
Cortex XSOAR Marketplace is the central location for
installing, exchanging, contributing, and managing all of your content,
including playbooks, integrations, automations, fields, layouts,
and more. Cortex XSOAR 6.1 introduces the following features to
the Marketplace.
- You can update multiple content packs in a single update operation. From the Content Pack library, select all of the packs that you want to update (and for which there is an available update), and clickUpdate. The content packs and any required dependencies are displayed for you to review before confirming the installation (update).While the updates are installing, you can continue working in other parts of the Cortex XSOAR platform.
Threat Intel Management
These features do not require a threat intel management
license, they are available to all Cortex XSOAR users.
Feature | Description |
|---|---|
Helpful message when a feed takes a long
time to fetch indicators | The error message that displays when a feed indicator
ingestion takes a long time, clearly explains that this occurs either
because there are many indicators, or because there is a problem
with the integration instance configuration. |
Case Management
Feature | Description |
|---|---|
Incident Read-Only Role | You can now grant read-only access to investigations,
so roles that have read-only access cannot edit an incident or take
part in the War Room. For example, when an incident is in triage (phase
1), you may want all Tier-2 analysts to have read-only access, so
that Tier-1 can edit the incident. When the phase changes to phase
2, Tier-1 has read-only access. |
Share engines and load-balancing groups
between tenants ( Multi-tenant ) | In the main account, you can now share engines
and load-balancing groups with tenants for integration instances. |
Engine Login page removal | When using an engine in a communication task,
if a user deleted the suffix in the link to the engine, a login
page appeared. Although the user could not login, this page has
now been deleted. |
Account Creation Indication for Automatically
Assigned Roles ( Multi-tenant ) | When creating a new account in the Main Account, by
default, administrator roles (with read and write permissions) are
automatically added to the account. You can change the default behavior
when creating or editing an account by removing the administrator
role. |
Propagate configuration values upon host
creation ( Multi-tenant ) | When creating an account or host in the Main Account
all configuration parameters are now propagated from the Main Account
to the host or tenant. |
Block a tenant ( Multi-tenant ) | In the main account, you can now block/unblock
a tenant account at proxy level (from the main server). You can
still access the tenant account via the port, which enables you
to fix any problems, without affecting the main account. |
RBAC Control for Shared Dashboards | Added the ability to share and grant permissions
to dashboards by user role. Permission level is either read-only
or edit. |
Exclusions Lists | It is now possible to add IPv6 CIDR ranges
to exclusion lists. |
Machine Learning improvements | When training a model using the machine learning feature,
you now have the ability to view an advanced analysis of its evaluation,
which enables you to decide whether, and how, to use the trained model.
A detailed breakdown is provided, showing what is the expected performance
of the model at each class, by displaying different metrics, such
as precision, coverage, suggestions for applying a confidence threshold,
etc. |
Toggle for incident layout tabs ( Mobile ) | In the Cortex XSOAR Web app, when customizing incident
layout visibility settings, you can decide whether you want each
tab to appear in the mobile app by selecting the Show
this tab on Cortex XSOAR mobile App if role allows checkbox.
Only mobile supported tabs have this checkbox (for example, Work
Plan and the Evidence tabs do not have the checkbox and will not
appear in the mobile app). By default, all mobile supported tabs
have the checkbox selected and appear in the mobile app. You
can also create new tabs and add fields to them as required. |
Scriptable buttons ( Mobile ) | You can now run commands such as escalation
or enrichment in the mobile app by adding a script button to the
tab when customizing incident layouts in the web. It is useful to
add a button when you are undertaking war room commands or other
custom actions in the mobile app. |
Enhanced Audit Trail | The Audit Trail information
now contains:
|
Support for the Role argument in
the AssignAnalystToIncident command | In the AssignAnalystToIncident command,
while adding the assignBy argument with values
such as machine-learning, top-user, less-busy-user ,
etc, you can now assign according to role when adding the roles argument. |
Using Demisto REST API out of the box | You can now send read only requests using Demisto REST
API without adding and enabling an instance. For example, if you
run an API command in a Playbook (which is run by Dbot), it has
read only permissions, and you cannot modify data. |
Block starting a host until the Database
is upgraded | ( Multi-tenant ) When a database has already
been upgraded by an app server, another app server is prevented
from starting until the database is upgraded to block data corruption. |
Platform
Feature | Description |
|---|---|
Attach and Detach incident types | By default, when installing a Content Pack, incident
types are attached (cannot be edited). To customize the incident
type, such as changing the layout, the default playbook, extract indicators,
etc you need to detach it. When detached, the incident type
is not updated by the Content Pack, which may be useful when you
want to update the playbook without breaking customization. When
upgrading to version 6.1, by default, all out of the box incident
types (from a Content Pack) are detached. To receive content updates
for detached incident types, reattach the incident type. |
Multiple Load-Balancing Engine Groups | You can use separate load-balancing groups for
different integrations and instances. Users can create load balancing
groups for certain tasks, which can help segregate the infrastructure
of critical integrations. This is useful for example:
|
Deploy multiple engines on the same machine | ( Shell installation ) Install multiple engines
on the same machine without having numerous engine installation
files and manage those engines in different environments. In
a multi-tenant environment, users may want to deploy engines for
different tenants on the same machine. |
User Interface improvements |
|
Report date range | In the Reports page, when viewing the reports
list, you can now select the incident date range when generating
a report. You no longer need to duplicate the report and then change
the date range. |
Setting up the Fetch Interval Field for
integrations | You can now add the Incident Fetch Interval
field to any incident fetching integration that is not included out
of the box. This enables you to control the interval in which an
integration instance reaches out to fetch incidents, from ingesting
into the Cortex XSOAR platform and from 3rd party platforms. |
Dependency Check for Remote Repositories | When pushing content from the development to production
environments, you can now review and select dependencies before
pushing the content. This level of granularity enables you to select
only those dependencies that you want in your production environment. |
UI improvements for remote repositories | General User interface improvements when pushing content
to a remote repository, such as dependencies are expanded by default. |
Inline edit for Reputation and Expiration
Widgets | The Indicator Summary page now supports inline editing
for reputation and expiration widgets, which makes the editing process
simpler. |
Updated data in incident table | When a user makes changes to the incident such
as status, owner, etc, the changes immediately appear in the incident
table for all users. |
Marketplace improvements |
|
Exclude dependencies for a Contribution
Pack | In the Contribution Pack Editor ,
you can now select which dependencies to include. |
Limit indicator timeline content | In the Indicator timeline, content details
are truncated where there are many changes, which makes it easier
to view. You can configure the timelime for multi-value (multi-select
and tags) field, HTML, markdown, long and short text fields. |
Display an error when a script widget fails | When a script fails for a widget, an error
message now appears which enables the user to fix the script rather
than showing a spinning wheel. |
Run actions after an incident is closed | When an incident is closed, if users click
an action button there is now an option to reopen the incident. |
Add installer log to the log bundle | For better debugging and analysis, there is
now an installer log when installing Cortex XSOAR. |
Support for Podman on CentOS v8 and RHEL
v8 | Cortex XSOAR now supports Podman. If running CentOS
v8 and higher or RHEL v8 and higher, Cortex XSOAR now installs Podman
packages automatically and configures the operating system to enable Podman
in rootless mode. Upgrades from a previous Cortex XSOAR
version are not affected and continue to use Docker. |
Clear/Reset integration context data | In the Instance settings dialog box, for some integrations,
you can now clear old or unnecessary data from the integration context. |
