From fc42e15ff0c4b53a780b9db86ae1fcb560643872 Mon Sep 17 00:00:00 2001 From: natasha-moore-elastic <137783811+natasha-moore-elastic@users.noreply.github.com> Date: Tue, 26 Nov 2024 13:03:25 +0000 Subject: [PATCH] Backport updated upgrade guides to 8.1 (#6234) --- docs/upgrade/upgrade-7.17-8.x.asciidoc | 162 +++++++++++++++++++++ docs/upgrade/upgrade-security.asciidoc | 188 ++++++++++++++----------- 2 files changed, 270 insertions(+), 80 deletions(-) create mode 100644 docs/upgrade/upgrade-7.17-8.x.asciidoc diff --git a/docs/upgrade/upgrade-7.17-8.x.asciidoc b/docs/upgrade/upgrade-7.17-8.x.asciidoc new file mode 100644 index 0000000000..3b0495c598 --- /dev/null +++ b/docs/upgrade/upgrade-7.17-8.x.asciidoc @@ -0,0 +1,162 @@ +[[upgrade-7.17-8x]] +== Upgrade from 7.17 to an 8.x version + +[float] +=== Why it's important to upgrade + +Upgrading provides you access to {elastic-sec}'s latest features, enhancements, and bug fixes, many of which enable you to save your organization money, respond faster to potential threats, and improve the tools you use to investigate and analyze your data. For more benefits, check out our blog, https://www.elastic.co/blog/top-5-reasons-to-upgrade-elastic-security[Top 5 reasons to upgrade Elastic Security]. Also, it's important to ensure that your deployment is fully maintained and supported. For more information, refer to https://www.elastic.co/support/eol[Elastic's Product End of Life Dates]. + +[float] +=== Plan for your upgrade + +Before upgrading to {elastic-sec} 8.x, consider the following recommendations: + +* Plan for an appropriate amount of time to complete the upgrade. Depending on your configuration and the size of your cluster, the process can take up to a week to complete. + +* Open a https://support.elastic.co[support case] with Elastic to alert our Elastic Support team of your system change. If you need additional assistance, https://www.elastic.co/consulting[Elastic Consulting Services] provides the technical expertise and step-by-step approach for upgrading your Elastic deployment. + +* Choose a version to upgrade to. We recommend the latest minor and patch version. Be sure to upgrade your development or non-production deployment to the same version as your production deployment. + +* Ensure that you have {kibana-ref}/xpack-monitoring.html[stack monitoring] enabled in {kib}. Take note of your current index and search rate. + +* Review your selected version's features, Elastic connectors, integrations, and detection rules to determine if you can replace any customized content with out-of-the-box functionality. This can help reduce your workload and the complexity of your upgrade. + +* If your organization sends alerts (formerly known as signals) to an external SOAR (security orchestration, automation, and response) platform, you may need to change your workflows to accommodate the new <> used in 8.x. + +* Review release notes, deprecations, and breaking changes for {security-guide}/release-notes.html[{elastic-sec}], {ref}/es-release-notes.html[{es}], {kibana-ref}/release-notes.html[{kib}], and, if applicable, {fleet-guide}/release-notes.html[{fleet} and {agent}], {beats-ref}/release-notes.html[{beats}], and {logstash-ref}/releasenotes.html[{ls}]. Identify any issues that might affect your deployment. Work with your Elastic team on any questions you may have. Start with breaking changes for your solution and platform components, such as {es} and {kib}. + +* Schedule a system maintenance window within your organization. + +[float] +=== Pre-upgrade steps + +To prepare for the upgrade process, follow these steps before you start: + +. Do a software version inventory across your entire Elastic deployment, including {es}, {kib}, {agent}, {beats}, and {ls}. + +. If you're running any versions earlier than 7.17, you must first upgrade them all to the latest 7.17.x patch release before upgrading to 8.x. This enables you to use the Upgrade Assistant to upgrade to 8.x. ++ +NOTE: If you're managing your deployments using {ece-ref}/ece-upgrade.html[{ece}] (ECE) or {eck-ref}/k8s-upgrading-eck.html[{eck}] (ECK), you may need to upgrade the system clusters first. + +. Note that alerts in 8.x are written using the `kibana_system` user instead of the `current user`, so any user-modified ingest pipelines configured against the alert index (this is uncommon) will use the `kibana_system` user privileges, which may break your ingest pipeline. If you encounter this issue, please do not update your ingest pipeline. Instead, contact your Elastic Support rep for assistance. + +. If you're upgrading to {stack} 8.0.x or 8.1.x, you must update your Elastic prebuilt detection rules _while your {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 {stack}. ++ +NOTE: This step isn't required if you're upgrading to {stack} 8.2 or later. If you're unable to update your prebuilt rules at 7.17, upgrade to {stack} 8.2 or later. + +. Run the {kibana-ref}/upgrade-assistant.html[Upgrade Assistant]. Take note of any critical error messages, then work with your Elastic Support rep to resolve them. ++ +.Requirements +[sidebar] +-- +To run the Upgrade Assistant, you must have the `superuser` role on the cluster. +-- + +. If you're not using {ref}/snapshots-take-snapshot.html#automate-snapshots-slm[{slm} (SLM)], you must set up and configure a policy, then run the policy to create at least one {ref}/snapshot-restore.html[snapshot] -- a backup of indices taken from a running cluster. If you need to roll back during the upgrade process, use a recent snapshot to avoid data loss. Snapshots are {ref}/snapshot-restore.html#how-snapshots-work[incremental] -- depending on the cluster size and the input/output rate, the initial snapshot may take several hours to complete. If you're using SLM, {ref}/snapshots-take-snapshot.html#check-slm-history[check the SLM history] to ensure that snapshots are completing successfully. + +[float] +=== Perform an 8.x upgrade on a deployment + +IMPORTANT: We strongly recommend performing the following steps on a non-production deployment first to address any potential issues before upgrading your production deployments. If you're using a cross-cluster search environment, upgrade your remote deployments first. + +. If you haven't already done so, back up your cluster data to a {ref}/snapshots-take-snapshot.html[snapshot]. + +. We recommend you <> in case there are issues with the detection engine after the upgrade. + +. Upgrade {es}. +** If you're using {ecloud}, we recommend upgrades with no downtime. Refer to {cloud}/ec-upgrade-deployment.html[these instructions]. +** If you're using {ece} (ECE), refer to {ece-ref}/ece-upgrade-deployment.html[these instructions]. +** If you're using {eck} (ECK), refer to {eck-ref}/k8s-upgrading-stack.html[these instructions]. +** If you're upgrading a self-orchestrated deployment, refer to {stack-ref}/upgrading-elasticsearch.html[these instructions] and upgrade the data nodes tier by tier in this order: +... Frozen tier +... Cold tier +... Warm tier +... Hot tier +... Any other nodes not in a tier +... All remaining nodes that are neither master-eligible nor data nodes +... Master-eligible nodes + +. Upgrade {kib}. Refer to {stack-ref}/upgrading-kibana.html[these instructions]. ++ +NOTE: If you're using Elastic Cloud Hosted or {ece}, this is already included in the {es} upgrade. + +. Validate that {es} and {kib} are operating as expected by completing the following checks: +.. For {es}: +... Check the status of your clusters and ensure that they're green by running a `GET _cat/health` API request. For more information, refer to the {ref}/cat-health.html[cat health API documentation]. +... Ensure that the index and search rate are close to what they were before upgrading. To view these, find **Stack Monitoring** in the navigation menu or by using the {kibana-ref}/introduction.html#kibana-navigation-search[global search field], then select **{es}** → **Overview**. ++ +TIP: You can also check the index document count using the {ref}/cat-indices.html[cat index API]. +... Verify that {slm} SLM is taking snapshots by {ref}/snapshots-take-snapshot.html#check-slm-history[checking the SLM history]. +... If you use {ml}, ensure that it is up and running. +.. For {kib}: +... Ensure that you and your users can successfully log in to {kib} and access desired pages. +... Check {kibana-ref}/discover.html[Discover] and verify that the index patterns you typically use are available. +... Verify that your commonly used {kibana-ref}/dashboard.html[dashboards] are available and working properly. +... If you use any Watcher-based {kib} scheduled {kibana-ref}/reporting-getting-started.html[reporting], ensure that it's working properly. + +. Upgrade your ingest components (such as {ls}, {fleet} and {agent}, {beats}, etc.). For details, refer to the {stack-ref}/upgrading-elastic-stack.html[Elastic Stack upgrade docs]. + +. Validate that ingest is operating correctly. +.. Open *Discover*, go through data views for each of your expected ingest data streams, and ensure that data is being ingested in the expected format and volume. + +. Validate that {elastic-sec} is operating correctly. +.. On the **Rules** page, re-enable your desired SIEM detection rules (**Rule Management** tab), and ensure that enabled rules are running without errors or warnings (**Rule Monitoring** tab). +.. Ensure that any SOAR workflows that consume alerts are working. +.. Verify that any custom dashboards your team has created are working properly, especially if they operate on alert documents. + +. If you performed these steps on a non-production deployment, repeat these same steps on your production environment. If you're using a cross-cluster search environment and performed these steps on your remote clusters, repeat these same steps on your other deployments. +. Confirm with your appropriate stakeholders that the upgrade process has been successful. + +[float] +=== Post-upgrade steps + +The following sections describe procedures to complete after upgrading {elastic-sec} to 8.x. + +[float] +[[reenable-rules-upgrade]] +==== Re-enable disabled rules + +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 new tag, then use bulk actions to re-enable them: + +. Find **Detection rules (SIEM)** in the navigation menu or by using the {kibana-ref}/introduction.html#kibana-navigation-search[global search field]. +. From the *Tags* dropdown, search for `auto_disabled_8.0`. +. 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 <> API to re-enable rules. + +[float] +[[fda-upgrade]] +==== Full Disk Access (FDA) approval for {elastic-endpoint} + +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 <> to review the required permissions. + +[float] +[[data-views-upgrade]] +==== Requirements to display Data views in the {security-app} + +To make the *Data view* option appear in an environment with legacy alerts, a user with elevated role privileges must visit the {security-app}, open a page that displays alert data (at least one alert must be present), and then refresh the page. The user's role privileges must allow them to enable the detections feature in a {kib} space. For more information, refer to <>. + +[float] +[[alert-schema-upgrade]] +==== New alert schema + +The system index for detection alerts has been renamed from `.siem-signals-` to `.alerts-security.alerts-` and is now a hidden index. Therefore, the schema used for alert documents in {elastic-sec} has changed. Users that access documents in the `.siem-signals` indices using the {elastic-sec} API must modify their API queries and scripts to operate properly on the new 8.x alert documents. Refer to <> and review the new <>. + +[float] +[[preview-upgrade]] +==== New privileges required to view alerts and preview rules + +* To view alerts, users need `manage`, `write`, `read`, and `view_index_metadata` privileges for two new indices, `.alerts-security.alerts` and `.internal.alerts-security.alerts`. Existing users who are upgrading to 8.x can retain their privileges to the `.siem-signals` index. + +* To <>, users need `read` access to the new `.preview.alerts-security.alerts` index. Refer to <> for more information. + +[float] +[[im-rules-upgrade]] +==== Updates to indicator match rules + +Changes to the indicator match rule type's <> 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.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 {stack} version 8.x and {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 <>. \ No newline at end of file diff --git a/docs/upgrade/upgrade-security.asciidoc b/docs/upgrade/upgrade-security.asciidoc index f627776a12..7899e811fb 100644 --- a/docs/upgrade/upgrade-security.asciidoc +++ b/docs/upgrade/upgrade-security.asciidoc @@ -1,119 +1,147 @@ -[chapter] [[upgrade-intro]] -= Upgrade {elastic-sec} += Upgrade {elastic-sec} to {version} -We highly recommend that all {elastic-sec} users keep their deployments up to date with the latest available {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. +Before you upgrade {elastic-sec}, take the necessary preparation steps, which will vary depending on what version you are upgrading to: -For upgrading to the latest {stack} version, we recommend using the {kibana-ref}/upgrade-assistant.html[Kibana Upgrade Assistant]. +* <> +* <> +* <> -NOTE: For detailed information about the 8.0 release, check out the <>. +WARNING: Avoid upgrading to 8.1.1. There is a known issue that significantly impacts UI responsiveness. Therefore, we recommend you skip this version. -[discrete] -[[upgrade-8.1.1]] -== Avoid upgrading to 8.1.1 +Rolling upgrades are unsupported in {elastic-sec}, which runs within the {kib} application. To upgrade, you must shut down all {kib} instances, install the new software, and restart {kib}. +Upgrading while older {kib} instances are running can cause data loss or upgrade failures. -IMPORTANT: There is a known issue that significantly impacts UI responsiveness. Therefore, we recommend you skip this version. - -[discrete] -[[upgrade-reqs]] -== Upgrade to other 8.x versions +[WARNING] +==== +When required, {kib} automatically migrates {kibana-ref}/saved-object-migrations.html[saved objects]. +In case of an upgrade failure, you can roll back to an +earlier version of {kib}. To roll back, you **must** have a +{ref}/snapshot-restore.html[backup snapshot] that includes the `kibana` feature +state. By default, snapshots include the `kibana` feature state. +==== [float] -[[upgrade-agents]] -=== Upgrade {agent}s - -Upgrade your {stack} and {agent}s to 7.17 first (refer to {fleet-guide}/upgrade-elastic-agent.html[Upgrade Fleet-managed Elastic Agents]). Afterwards, you can {stack-ref}/upgrading-elastic-stack.html[upgrade the {stack}] to 8.x. Initially, {agent}s will be version 7.17; this is fine because {elastic-sec} 8.x supports the last minor release in 7.x (7.17) and any subsequent {elastic-endpoint} versions in 8.x. After the {stack} upgrade, you can decide whether to upgrade {agent}s to 8.0, which is recommended to ensure you get the latest features. +== Upgrading multiple {kib} instances +When upgrading several {kib} instances connected to the same {es} cluster, +ensure that all outdated instances are shut down before starting the upgrade. -NOTE: You do not need to shut down your {agent}s or endpoints to upgrade the {stack}. - -[float] -[[update-prebuilt-rules]] -=== Update prebuilt detection rules before upgrading to {stack} 8.0 or 8.1 +Rolling upgrades are unsupported in {kib}. 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. -If you're upgrading to {stack} 8.0.x or 8.1.x, you must update your Elastic prebuilt detection rules _while your {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 {stack}. +For large deployments with more than 10 {kib} instances and more than 10,000 saved objects, +you can reduce the upgrade downtime by bringing up a single {kib} instance and waiting for it to +complete the upgrade migration before bringing up the remaining instances. -This step isn't required if you're upgrading to {stack} 8.2 or later. If you're unable to update your prebuilt rules at 7.17, upgrade to {stack} 8.2 or later. +IMPORTANT: 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. [float] -[[track-rules-upgrade]] -=== Track rules that are automatically disabled when upgrading +=== Ensure that all {kib} instances are the same +When you perform an upgrade migration of different {kib} versions, the migration can fail. +Ensure that all {kib} instances are running the same version, configuration, and plugins. -IMPORTANT: 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 <>. - -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_. +[float] +== Support for Elastic prebuilt detection rule automatic updates +<> are supported for the current {elastic-sec} version and the latest three previous minor releases. For example, if you’re upgrading to {elastic-sec} 8.10, you’ll be able to use the Rules UI to update your prebuilt rules until {elastic-sec} 8.14 is released. After that point, you can still manually download and install updated prebuilt rules, but you must upgrade to the latest {elastic-sec} version to receive automatic updates. -Before upgrading, use the <> to capture a list of enabled rules. +[float] +[[upgrade-8x-8x]] +== Upgrade from an 8.x to an 8.x version -NOTE: Use curl or another HTTP tool to run {elastic-sec} API commands. +Follow this guide to upgrade from an earlier 8.x version to a later 8.x version. -Here is a curl command that you can run to find enabled rules: +[float] +=== Plan for your upgrade -[source,console] --------------------------------------------------- -GET /api/detection_engine/rules/_find?per_page=10000&filter=alert.attributes.enabled:true --------------------------------------------------- +Before upgrading from an earlier 8.x version, consider the following recommendations: -To re-enable your rules from the Rules page: +* Plan for an appropriate amount of time to complete the upgrade. Depending on your configuration and the size of your cluster, the process can take up to a week to complete. -. Go to the All rules table (*Detect -> Rules*). -. Select the rules that you want to enable. -. Click *Bulk actions -> Enable* to re-enable the rules. +* Open a https://support.elastic.co[support case] with Elastic to alert our Elastic Support team of your system change. If you need additional assistance, https://www.elastic.co/consulting[Elastic Consulting Services] provides the technical expertise and step-by-step approach for upgrading your Elastic deployment. -[float] -[[reenable-rules-upgrade]] -=== Re-enable disabled rules +* Choose a version to upgrade to. We recommend the latest minor and patch version. Be sure to upgrade your development or non-production deployment to the same version as your production deployment. -IMPORTANT: 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 <>. +* Ensure that you have {kibana-ref}/xpack-monitoring.html[stack monitoring] enabled in {kib}. Take note of your current index and search rate. -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: +* Review your selected version's features, Elastic connectors, integrations, and detection rules to determine if you can replace any customized content with out-of-the-box functionality. This can help reduce your workload and the complexity of your upgrade. -. Go to the All rules table (*Detect -> Rules*). -. From the *Tags* dropdown, search for `auto_disabled_8.0`. -. Click *Select all _x_ rules*, or individually select the rules you want to re-enable. -. Click *Bulk actions -> Enable* to re-enable the rules. +* Review release notes, deprecations, and breaking changes for {security-guide}/release-notes.html[{elastic-sec}], {ref}/es-release-notes.html[{es}], {kibana-ref}/release-notes.html[{kib}], and, if applicable, {fleet-guide}/release-notes.html[{fleet} and {agent}], {beats-ref}/release-notes.html[{beats}], and {logstash-ref}/releasenotes.html[{ls}]. Identify any issues that might affect your deployment. Work with your Elastic team on any questions you may have. Start with breaking changes for your solution and platform components, such as {es} and {kib}. -Alternatively, you can use the <> API to re-enable rules. +* Schedule a system maintenance window within your organization. [float] -[[fda-upgrade]] -=== Full Disk Access (FDA) approval for {elastic-endpoint} - -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 <> to review the required permissions. +=== Pre-upgrade steps -[float] -[[data-views-upgrade]] -=== Requirements to display Data views in the {es-sec-app} +To prepare for the upgrade process, follow these steps before you start: -To make the *Data view* option appear in an environment with legacy alerts, a user with elevated role privileges must visit the {es-sec-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 <> for more information. +. Do a software version inventory across your entire Elastic deployment, including {es}, {kib}, {agent}, {beats}, and {ls}. -NOTE: If new alerts are generated in an upgraded environment without legacy alerts, refreshing any page with alert data in {elastic-sec} will make the *Data view* option appear in the {es-sec-ui}. +. If you're not using {ref}/snapshots-take-snapshot.html#automate-snapshots-slm[{slm} (SLM)], you must set up and configure a policy, then run the policy to create at least one {ref}/snapshot-restore.html[snapshot]—a backup of indices taken from a running cluster. If you need to roll back during the upgrade process, use a recent snapshot to avoid data loss. Snapshots are {ref}/snapshot-restore.html#how-snapshots-work[incremental]—depending on the cluster size and the input/output rate, the initial snapshot may take several hours to complete. If you're using SLM, {ref}/snapshots-take-snapshot.html#check-slm-history[check the SLM history] to ensure that snapshots are completing successfully. [float] -[[alert-schema-upgrade]] -=== New alert schema - -The system index for detection alerts has been renamed from `.siem-signals-` to `.alerts-security.alerts-` and is now a hidden index. Therefore, the schema used for alert documents in {elastic-sec} has changed. Users that access documents in the `.siem-signals` indices using the {elastic-sec} API must modify their API queries and scripts to operate properly on the new 8.0 alert documents. Refer to <> and review the new <>. +=== Perform an 8.x to 8.x upgrade on a deployment + +IMPORTANT: We strongly recommend performing the following steps on a non-production deployment first to address any potential issues before upgrading your production deployments. If you're using a cross-cluster search environment, upgrade your remote deployments first. + +. If you haven't already done so, back up your cluster data to a {ref}/snapshots-take-snapshot.html[snapshot]. + +. We recommend you <> in case there are issues with the detection engine after the upgrade. + +. Upgrade {es}. +** If you're using {ecloud}, we recommend upgrades with no downtime. Refer to {cloud}/ec-upgrade-deployment.html[these instructions]. +** If you're using {ece} (ECE), refer to {ece-ref}/ece-upgrade-deployment.html[these instructions]. +** If you're using {eck} (ECK), refer to {eck-ref}/k8s-upgrading-stack.html[these instructions]. +** If you're upgrading a self-orchestrated deployment, refer to {stack-ref}/upgrading-elasticsearch.html[these instructions] and upgrade the data nodes tier by tier in this order: +... Frozen tier +... Cold tier +... Warm tier +... Hot tier +... Any other nodes not in a tier +... All remaining nodes that are neither master-eligible nor data nodes +... Master-eligible nodes + +. Upgrade {kib}. Refer to {stack-ref}/upgrading-kibana.html[these instructions]. ++ +NOTE: If you're using Elastic Cloud Hosted or {ece}, this is already included in the {es} upgrade. + +. Validate that {es} and {kib} are operating as expected by completing the following checks: +.. For {es}: +... Check the status of your clusters and ensure that they're green by running a `GET _cat/health` API request. For more information, refer to the {ref}/cat-health.html[cat health API documentation]. +... Ensure that the index and search rate are close to what they were before upgrading. Go to **Stack Monitoring** -> **{es}** -> **Overview**. ++ +TIP: You can also check the index document count using the {ref}/cat-indices.html[cat index API]. +... Verify that {slm} (SLM) is taking snapshots by {ref}/snapshots-take-snapshot.html#check-slm-history[checking the SLM history]. +... If you use {ml}, ensure that it is up and running. +.. For {kib}: +... Ensure that you and your users can successfully log in to {kib} and access desired pages. +... Check {kibana-ref}/discover.html[Discover] and verify that the index patterns you typically use are available. +... Verify that your commonly used {kibana-ref}/dashboard.html[dashboards] are available and working properly. +... If you use any Watcher-based {kib} scheduled {kibana-ref}/reporting-getting-started.html[reporting], ensure that it's working properly. + +. Upgrade your ingest components (such as {ls}, {fleet} and {agent}, {beats}, etc.). For details, refer to the {stack-ref}/upgrading-elastic-stack.html[Elastic Stack upgrade docs]. + +. Validate that ingest is operating correctly. +.. Open *Discover*, go through data views for each of your expected ingest data streams, and ensure that data is being ingested in the expected format and volume. + +. Validate that {elastic-sec} is operating correctly. +.. On the **Rules** page, re-enable your desired SIEM detection rules (**Rule Management** tab), and ensure that enabled rules are running without errors or warnings (**Rule Monitoring** tab). +.. Ensure that any SOAR workflows that consume alerts are working. +.. Verify that any custom dashboards your team has created are working properly, especially if they operate on alert documents. + +. If you performed these steps on a non-production deployment, repeat these same steps on your production environment. If you're using a cross-cluster search environment and performed these steps on your remote clusters, repeat these same steps on your other deployments. +. Confirm with your appropriate stakeholders that the upgrade process has been successful. [float] -[[preview-upgrade]] -=== New privileges required to view alerts and preview rules - -* 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. +[[upgrade-7.16-8.x]] +== Upgrade from 7.16 or earlier to an 8.x version -* To <>, users need `read` access to the new `.preview.alerts-security.alerts` index. Refer to <> for more information. +To upgrade from 7.16.0 or earlier to {version}, you must first upgrade your {stack} and {agent}s to 7.17 (refer to {fleet-guide}/upgrade-elastic-agent.html[Upgrade Fleet-managed Elastic Agents]). This enables you to use the {kibana-ref}/upgrade-assistant.html[Upgrade Assistant] to prepare for the upgrade. Before you upgrade, you must resolve all critical issues identified by the Upgrade Assistant. Afterwards, you can <>. -[float] -[[im-rules-upgrade]] -=== Updates to indictor match rules - -Changes to the indicator match rule's <> might require you to update existing rules, or create new ones, after upgrading to 8.0. Be mindful of the following: +Initially, {agent}s will be version 7.17. This is fine because {elastic-sec} 8.x supports the last minor release in 7.x (7.17) and any subsequent {elastic-endpoint} versions in 8.x. After the {stack} upgrade, you can decide whether to upgrade {agent}s to 8.x, which is recommended to ensure you get the latest features. -* 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 {stack} version 8.0 and {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 <>. +NOTE: You do not need to shut down your {agent}s or endpoints to upgrade the {stack}. -[float] -[[prebuilt-rule-updates]] -=== Support for Elastic prebuilt detection rule automatic updates -<> are supported for the current {elastic-sec} version and the latest three previous minor releases. For example, if you’re upgrading to {elastic-sec} 8.10, you’ll be able to use the Rules UI to update your prebuilt rules until {elastic-sec} 8.14 is released. After that point, you can still manually download and install updated prebuilt rules, but you must upgrade to the latest {elastic-sec} version to receive automatic updates. +include::upgrade-7.17-8.x.asciidoc[] \ No newline at end of file