diff --git a/raw-migrated-files/docs-content/serverless/security-spaces.md b/raw-migrated-files/docs-content/serverless/security-spaces.md deleted file mode 100644 index 763c285db3..0000000000 --- a/raw-migrated-files/docs-content/serverless/security-spaces.md +++ /dev/null @@ -1,14 +0,0 @@ -# Spaces and {{elastic-sec}} [security-spaces] - -{{elastic-sec}} supports the organization of your security operations into logical instances with the [spaces](../../../deploy-manage/manage-spaces.md) feature. Each space in {{kib}} represents a separate logical instance of {{elastic-sec}} in which detection rules, rule exceptions, value lists, alerts, Timelines, cases, and {{kib}} advanced settings are private to the space and accessible only by users that have role privileges to access the space. For details about privileges for {{elastic-sec}} and specific features, refer to [{{elastic-sec}} requirements](../../../solutions/security/get-started/elastic-security-requirements.md). - -For example, if you create a `SOC_prod` space in which you load and activate all the {{elastic-sec}} prebuilt detection rules, these rules and any detection alerts they generate will be accessible only when visiting the {{security-app}} in the `SOC_prod` space. If you then create a new `SOC_dev` space, you’ll notice that no detection rules or alerts are present. Any rules subsequently loaded or created here will be private to the `SOC_dev` space, and they will run independently of those in the `SOC_prod` space. - -::::{note} -By default, alerts created by detection rules are stored in {{es}} indices under the `.alerts-security.alerts-` index pattern, and they may be accessed by any user with role privileges to access those {{es}} indices. In our example above, any user with {{es}} privileges to access `.alerts-security.alerts-SOC_prod` will be able to view `SOC_prod` alerts from within {{es}} and other {{kib}} apps such as Discover. - -To ensure that detection alert data remains private to the space in which it was created, ensure that the roles assigned to your {{elastic-sec}} users include {{es}} privileges that limit their access to alerts within their space’s alerts index. - -:::: - - diff --git a/raw-migrated-files/security-docs/security/security-spaces.md b/raw-migrated-files/security-docs/security/security-spaces.md deleted file mode 100644 index 32dfdff19d..0000000000 --- a/raw-migrated-files/security-docs/security/security-spaces.md +++ /dev/null @@ -1,14 +0,0 @@ -# Spaces and {{elastic-sec}} [security-spaces] - -{{elastic-sec}} supports the organization of your security operations into logical instances with the [spaces](../../../deploy-manage/manage-spaces.md) feature. Each space in {{kib}} represents a separate logical instance of {{elastic-sec}} in which detection rules, rule exceptions, value lists, alerts, Timelines, cases, and {{kib}} advanced settings are private to the space and accessible only by users that have role privileges to access the space. For details about privileges for {{elastic-sec}} and specific features, refer to [*{{elastic-sec}} requirements*](../../../solutions/security/get-started/elastic-security-requirements.md). - -For example, if you create a `SOC_prod` space in which you load and activate all the {{elastic-sec}} prebuilt detection rules, these rules and any detection alerts they generate will be accessible only when visiting the {{security-app}} in the `SOC_prod` space. If you then create a new `SOC_dev` space, you’ll notice that no detection rules or alerts are present. Any rules subsequently loaded or created here will be private to the `SOC_dev` space, and they will run independently of those in the `SOC_prod` space. - -::::{note} -By default, alerts created by detection rules are stored in {{es}} indices under the `.alerts-security.alerts-` index pattern, and they may be accessed by any user with role privileges to access those {{es}} indices. In our example above, any user with {{es}} privileges to access `.alerts-security.alerts-SOC_prod` will be able to view `SOC_prod` alerts from within {{es}} and other {{kib}} apps such as Discover and Lens. - -To ensure that detection alert data remains private to the space in which it was created, ensure that the roles assigned to your {{elastic-sec}} users include {{es}} privileges that limit their access to alerts within their space’s alerts index. - -:::: - - diff --git a/raw-migrated-files/toc.yml b/raw-migrated-files/toc.yml index 2936a41867..827073fd56 100644 --- a/raw-migrated-files/toc.yml +++ b/raw-migrated-files/toc.yml @@ -507,7 +507,6 @@ toc: - file: docs-content/serverless/security-session-view.md - file: docs-content/serverless/security-shared-exception-lists.md - file: docs-content/serverless/security-signals-to-cases.md - - file: docs-content/serverless/security-spaces.md - file: docs-content/serverless/security-third-party-actions.md - file: docs-content/serverless/security-threat-intelligence.md - file: docs-content/serverless/security-timeline-templates-ui.md @@ -893,7 +892,6 @@ toc: - file: security-docs/security/security-assistant.md - file: security-docs/security/security-posture-faq.md - file: security-docs/security/security-posture-management.md - - file: security-docs/security/security-spaces.md - file: security-docs/security/self-healing-rollback.md - file: security-docs/security/session-view.md - file: security-docs/security/shared-exception-lists.md diff --git a/solutions/security/get-started/spaces-elastic-security.md b/solutions/security/get-started/spaces-elastic-security.md index e635bf64a9..da5ae14548 100644 --- a/solutions/security/get-started/spaces-elastic-security.md +++ b/solutions/security/get-started/spaces-elastic-security.md @@ -4,11 +4,15 @@ mapped_urls: - https://www.elastic.co/guide/en/serverless/current/security-spaces.html --- -# Spaces and Elastic Security +# Spaces and {{elastic-sec}} [security-spaces] -% What needs to be done: Lift-and-shift +{{elastic-sec}} supports the organization of your security operations into logical instances with the [spaces](../../../deploy-manage/manage-spaces.md) feature. Each space in {{kib}} represents a separate logical instance of {{elastic-sec}} in which detection rules, rule exceptions, value lists, alerts, Timelines, cases, and {{kib}} advanced settings are private to the space and accessible only by users that have role privileges to access the space. For details about privileges for {{elastic-sec}} and specific features, refer to [{{elastic-sec}} requirements](elastic-security-requirements.md). -% Use migrated content from existing pages that map to this page: +For example, if you create a `SOC_prod` space in which you load and activate all the {{elastic-sec}} prebuilt detection rules, these rules and any detection alerts they generate will be accessible only when visiting the {{security-app}} in the `SOC_prod` space. If you then create a new `SOC_dev` space, you’ll notice that no detection rules or alerts are present. Any rules subsequently loaded or created here will be private to the `SOC_dev` space, and they will run independently of those in the `SOC_prod` space. -% - [ ] ./raw-migrated-files/security-docs/security/security-spaces.md -% - [ ] ./raw-migrated-files/docs-content/serverless/security-spaces.md \ No newline at end of file +::::{note} +By default, alerts created by detection rules are stored in {{es}} indices under the `.alerts-security.alerts-` index pattern, and they may be accessed by any user with role privileges to access those {{es}} indices. In our example above, any user with {{es}} privileges to access `.alerts-security.alerts-SOC_prod` will be able to view `SOC_prod` alerts from within {{es}} and other {{kib}} apps such as Discover. + +To ensure that detection alert data remains private to the space in which it was created, ensure that the roles assigned to your {{elastic-sec}} users include {{es}} privileges that limit their access to alerts within their space’s alerts index. + +::::