Upgrade Elastic Securityedit

We highly recommend that all Elastic Security users keep their deployments up to date with the latest available Elastic Stack version to access new features, security updates, and performance enhancements. This topic describes updates in 8.0 that require changes to your agents, existing data, user privileges, or system preferences.

For upgrading to the latest Elastic Stack version, we recommend using the Kibana Upgrade Assistant.

For detailed information about the 8.0 release, check out the Release notes.

Avoid upgrading to 8.1.1edit

There is a known issue that significantly impacts UI responsiveness. Therefore, we recommend you skip this version.

Upgrade to other 8.x versionsedit

Upgrade Elastic Agentsedit

Upgrade your Elastic Stack and Elastic Agents to 7.17 first (refer to Upgrade Fleet-managed Elastic Agents). Afterwards, you can upgrade the Elastic Stack 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.0, 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.

Update prebuilt detection rules before upgrading to Elastic Stack 8.0 or 8.1edit

If you’re upgrading to Elastic Stack 8.0.x or 8.1.x, you must update your Elastic prebuilt detection rules while your Elastic Stack is at 7.17. To update Elastic prebuilt rules, go to the Rules page and select Update x Elastic prebuilt rules. This ensures that you have the latest prebuilt rules before upgrading the Elastic Stack.

This step isn’t required if you’re upgrading to Elastic Stack 8.2 or later. If you’re unable to update your prebuilt rules at 7.17, upgrade to Elastic Stack 8.2 or later.

Track rules that are automatically disabled when upgradingedit

The following applies to customers who are upgrading from 7.17 to 8.0 only. If you are upgrading to 8.0.1 or newer, refer to the instructions below for re-enabling disabled rules.

Upon upgrading to 8.0, rules are automatically disabled. Once the upgrade completes, you should re-enable them again to avoid gaps in rule coverage. We highly recommend that you track your active rules before upgrading so you can easily find and re-enable them after upgrading to 8.0.

Before upgrading, use the Find rules API to capture a list of enabled rules.

Use curl or another HTTP tool to run Elastic Security API commands.

Here is a curl command that you can run to find enabled rules:

GET /api/detection_engine/rules/_find?per_page=10000&filter=alert.attributes.enabled:true

To re-enable your rules from the Rules page:

  1. Go to the All rules table (Detect → Rules).
  2. Select the rules that you want to enable.
  3. Click Bulk actions → Enable to re-enable the rules.

Re-enable disabled rulesedit

The following applies to customers who are upgrading from 7.17 to 8.0.1 and newer only. If you are upgrading to 8.0., refer to the instructions above for tracking rules prior to upgrading to 8.0.

Any rules that are active 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:

  1. Go to the All rules table (Detect → Rules).
  2. From the Tags dropdown, search for auto_disabled_8.0.
  3. Click Select all x rules, or individually select the rules you want to re-enable.
  4. 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.0. Refer to Install Elastic Endpoint manually 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 .siem-signals-<space-id> to .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.0 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 manage, write, read, and view_index_metadata privileges to two new indices, .alerts-security.alerts and .internal.alerts-security.alerts. Existing users who are upgrading to 8.0 can retain their privileges to the .siem-signals index.
  • To preview rules, users need read access to the new .preview.alerts-security.alerts index. 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.0. 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.indicator after 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.indicator after you upgrade to Elastic Stack version 8.0 and Elastic Agent or Filebeat version 8.0 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.0 because each version requires a different default threat indicator path value. Review the recommendations for querying alert indices.