Before you upgrade Elastic Security, take the necessary preparation steps, which will vary depending on what version you are upgrading to:
Rolling upgrades are unsupported in Elastic Security, which runs within the Kibana application. To upgrade, you must shut down all Kibana instances, install the new software, and restart Kibana. Upgrading while older Kibana instances are running can cause data loss or upgrade failures.
Upgrading multiple Kibana instancesedit
When upgrading several Kibana instances connected to the same Elasticsearch cluster, ensure that all outdated instances are shut down before starting the upgrade.
Rolling upgrades are unsupported in Kibana. However, when outdated instances are shut down, you can start all upgraded instances in parallel, which allows all instances to participate in the upgrade migration in parallel.
For large deployments with more than 10 Kibana instances and more than 10,000 saved objects, you can reduce the upgrade downtime by bringing up a single Kibana instance and waiting for it to complete the upgrade migration before bringing up the remaining instances.
You can upgrade to pre-release versions for testing, but upgrading from a pre-release to the Generally Available version is unsupported. You should use pre-release versions only for testing in a temporary environment.
Preparing for migrationedit
Take these extra steps to ensure you are ready for migration.
Ensure your Elasticsearch cluster is healthyedit
Problems with your Elasticsearch cluster can prevent Kibana upgrades from succeeding.
During the upgrade process, Kibana creates new indices into which updated documents are written. If a cluster is approaching the low watermark, there’s a high risk of Kibana not being able to create these. Reading, transforming, and writing updated documents can be memory intensive, using more available heap than during routine operation. You must ensure that enough heap is available to prevent requests from timing out or throwing errors from circuit breaker exceptions. You should also ensure that all shards are replicated and assigned.
A healthy cluster has:
Enough free disk space, at least twice the amount of storage taken up by the
- Sufficient heap size
- A "green" cluster status
Ensure that all Kibana instances are the sameedit
When you perform an upgrade migration of different Kibana versions, the migration can fail. Ensure that all Kibana instances are running the same version, configuration, and plugins.
Back up your dataedit
Be sure to have a snapshot of all your data before migrating, so that if something goes wrong during migration, you can restore from the snapshot and try again.
Review the common causes of Kibana upgrade failures and how to prevent them.
Upgrade from an earlier 8.x versionedit
Review the breaking changes for each product you use and make the necessary changes so your code is compatible with 8.10.0.
- If you use any Elasticsearch plugins, ensure each plugin has a version compatible with Elasticsearch version 8.10.0.
- Test the upgrade in an isolated environment before upgrading your production cluster.
Ensure you have a current snapshot before you start the upgrade.
You cannot downgrade Elasticsearch nodes after upgrading. If you cannot complete the upgrade process, you will need to restore from the snapshot.
- If you use a separate monitoring cluster, you should upgrade the monitoring cluster before the production cluster. Generally, the monitoring cluster and the clusters being monitored should be running the same Elastic Stack version. A monitoring cluster cannot monitor production clusters running newer stack versions. If necessary, the monitoring cluster can monitor production clusters running the latest release of the previous major version.
Considerations when upgrading to 8.8edit
After you upgrade to 8.8 or later, frequency settings for rule actions created in 8.7 or earlier are automatically moved from the rule level to the action level. The action schedules remain the same and will continue to run on their previously specified frequency (
On each rule execution,
Upgrade from 7.17 to an 8.x versionedit
This section provides the necessary steps you need to take before upgrading to 8.x. It also contains new requirements and other pertinent information that affect various features in the Elastic Security app.
First, review the breaking changes for each product you use and make the necessary changes so your code is compatible with 8.10.0.
Re-enable disabled rulesedit
Any active rules when you upgrade from 7.17 to 8.0.1 or newer are automatically disabled, and a tag named
auto_disabled_8.0 is added to those rules for tracking purposes. Once the upgrade is complete, you can filter rules by the newly added tag, then use bulk actions to re-enable them:
- Go to the Rules page (Detect → Rules).
From the Tags dropdown, search for
- Click Select all x rules, or individually select the rules you want to re-enable.
- Click Bulk actions → Enable to re-enable the rules.
Alternatively, you can use the Bulk rule actions API to re-enable rules.
Full Disk Access (FDA) approval for Elastic Endpointedit
When you manually install Elastic Endpoint, you must approve a system extension, kernel extension, and enable Full Disk Access (FDA). There is a new FDA requirement in 8.x. Refer to Elastic Endpoint requirements to review the required permissions.
Requirements to display Data views in the Elastic Security appedit
To make the Data view option appear in an environment with legacy alerts, a user with elevated role privileges must visit the Elastic Security app, open a page that displays alert data (such as the Overview page), then refresh the page. The user’s role privileges must allow them to enable the detections feature in a Kibana space. Refer to Enable and access detections for more information.
If new alerts are generated in an upgraded environment without legacy alerts, refreshing any page with alert data in Elastic Security will make the Data view option appear in the Elastic Security UI.
New alert schemaedit
The system index for detection alerts has been renamed from
.alerts-security.alerts-<space-id> and is now a hidden index. Therefore, the schema used for alert documents in Elastic Security has changed. Users that access documents in the
.siem-signals indices using the Elastic Security API must modify their API queries and scripts to operate properly on the new 8.x alert documents. Refer to how to query alert indices and review the new Alert schema.
New privileges required to view alerts and preview rulesedit
To view alerts, users need
view_index_metadataprivileges to two new indices,
.internal.alerts-security.alerts. Existing users who are upgrading to 8.x can retain their privileges to the
To preview rules, users need
readaccess to the new
.preview.alerts-security.alertsindex. Refer to Detections prerequisites and requirements for more information.
Updates to indictor match rulesedit
Changes to the indicator match rule’s default threat indicator path might require you to update existing rules or create new ones after upgrading to 8.x. Be mindful of the following:
If an indicator match rule’s default threat indicator path was not defined before the upgrade, it will default to
threatintel.indicatorafter the upgrade. This allows the rule to continue using indicator data ingested by Filebeat version 7.x. If a custom value was defined before the upgrade, the value will not change.
If an existing indicator match rule was configured to use threat indicator indices generated from Filebeat version 7.x, updating the default threat indicator path to
threat.indicatorafter you upgrade to Elastic Stack version 8.x and Elastic Agent or Filebeat version 8.x configures the rule to use threat indicator indices generated by those later versions.
- You must create separate rules to query threat intelligence indices created by Filebeat version 7.x and version 8.x because each version requires a different default threat indicator path value. Review the recommendations for querying alert indices.
Upgrade from 7.16 or earlier to an 8.x versionedit
To upgrade from 7.16.0 or earlier to 8.10.0, you must first upgrade your Elastic Stack and Elastic Agents to 7.17 (refer to Upgrade Fleet-managed Elastic Agents). This enables you to use the Upgrade Assistant to prepare for the upgrade. Before you upgrade, you must resolve all critical issues identified by the Upgrade Assistant. Afterwards, you can upgrade to 8.x.
Initially, Elastic Agents will be version 7.17. This is fine because Elastic Security 8.x supports the last minor release in 7.x (7.17) and any subsequent Elastic Endpoint versions in 8.x. After the Elastic Stack upgrade, you can decide whether to upgrade Elastic Agents to 8.x, which is recommended to ensure you get the latest features.
You do not need to shut down your Elastic Agents or endpoints to upgrade the Elastic Stack.