Spaces Elastic Security

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

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
+::::{note} 
+By default, alerts created by detection rules are stored in {{es}} indices under the `.alerts-security.alerts-<space-name>` 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.
+
+::::