Space awareness for Elastic Defend

solutions/security/configure-elastic-defend/elastic-defend-feature-privileges.md

@@ -19,10 +19,9 @@ You can create user roles and define privileges to manage feature access in {{el
 To configure roles and privileges, find **Roles** in the navigation menu or by using the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md). For more details on using this UI, refer to [](/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-role-management.md) for {{stack}}, or to [Custom roles](/deploy-manage/users-roles/cloud-organization/user-roles.md) for {{serverless-short}}.
 
 ::::{note}
-{{elastic-defend}}'s feature privileges must be assigned to **All Spaces**. You can’t assign them to an individual space.
+{applies_to}`stack: ga 9.1` {{elastic-defend}}'s feature privileges can be assigned on a per-space basis. For information about how to apply permissions to particular spaces, refer to [Fleet roles and privileges](/reference/fleet/fleet-roles-privileges.md).
 ::::
 
-
 To grant access, select **All** for the **Security** feature in the **Assign role to space** configuration UI, then turn on the **Customize sub-feature privileges** switch.
 
 ::::{important}

solutions/security/get-started/spaces-elastic-security.md

@@ -13,7 +13,13 @@ products:
 
 # 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](elastic-security-requirements.md).
+{{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. 
+
+::::{note}
+{applies_to}`stack: ga 9.1` You can control user access to features in and managed by {{fleet}} (including {{elastic-defend}}) on a per-space basis. This granularity helps you fine-tune which components each user can access and which actions they can perform. To learn more, refer to [Fleet roles and privileges](/reference/fleet/fleet-roles-privileges.md), and [{{elastic-sec}} requirements](elastic-security-requirements.md).
+
+To learn more, refer to [Spaces and {{elastic-sec}}](spaces-security-faq.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.
 

solutions/security/get-started/spaces-security-faq.md

@@ -0,0 +1,234 @@
+---
+applies_to:
+  stack: preview 9.1
+  serverless:
+    security: all
+products:
+  - id: security
+  - id: cloud-serverless
+---
+
+# Spaces and {{elastic-sec}} FAQ [security-spaces-faq]
+
+This page introduces {{elastic-sec}} space awareness and answers frequently asked questions about how {{elastic-defend}} integration policies, {{elastic-endpoint}} artifacts, and {{elastic-endpoint}} response actions function when utilizing {{kib}} spaces.
+
+::::{admonition} Key points
+* Artifacts such as trusted applications, event filters, and response action history are scoped by space to provide granular control over access.
+* Role-Based Access Control (RBAC) defines who can manage global and space-specific resources. Users can view, edit, or manage artifacts based on their role privileges and the space context. 
+* You need the global management privilege to manage global artifacts (those not associated with specific policies).
+:::: 
+
+::::{note}
+{{elastic-sec}}'s space awareness works in conjunction with {{fleet}}'s space awareness. space awareness is enabled by default in both applications, but for {{stack}} deployments that existed prior to version 9.1, {{fleet}} requires you to manually “opt-in” so that existing data can become space aware. To learn more, refer to [Fleet roles and privileges](/reference/fleet/fleet-roles-privileges.md).
+::::
+
+## General FAQ [spaces-security-faq-general]
+**What are spaces in {{kib}}, and how do they affect what I see?**
+
+spaces allow your organization to segment data and configurations within {{kib}}. If you're working in a specific space, you’ll only see the policies, {{agents}}, {{elastic-endpoint}}s, and data that belong to that space. 
+
+
+**Does this matter to me if my organization doesn't use spaces?**
+
+If your organization doesn't use spaces, the only thing you need to know is that to manage Global Artifacts you need the Global Artifact management privilege.
+
+When you upgrade your {{stack}} deployment to 9.1.0, the Global Artifact Management privilege will be automatically granted to any role that grants the “All” privilege to at least one artifact type.
+
+
+**How do I use spaces with {{elastic-agent}} and {{elastic-defend}}?**
+
+spaces are defined at the {{kib}} level. Once a space is created, {{elastic-agent}} policies can be assigned to it. To do this, go to your list of agent policies in {{fleet}} and select the policy you want to assign. Navigate to the **Settings** tab, find the **spaces** section, and select the space(s) where you want the policy to appear.
+
+Once assigned, the {{agents}}—and {{elastic-defend}} endpoints, if applicable—associated with this policy are visible and manageable only within the designated space(s). 
+
+
+**Can artifacts be assigned to multiple spaces?**
+
+Yes, {{elastic-agent}} policies and all associated artifacts can be assigned to more than one space.
+
+
+## {{elastic-defend}} policies [spaces-security-faq-defend-policies]
+**How do spaces impact the visibility of Endpoints in the security app?**
+
+The list of {{elastic-endpoint}}s that you see depends on your current space. Only {{elastic-endpoint}}s associated with policies in the space you're working in will appear.
+
+
+**How do spaces impact the visibility of {{elastic-defend}} integration policies in {{elastic-sec}}?**
+
+The **Policies** list displays only the policies associated with your current space. The {{elastic-endpoint}} count for each policy includes only the endpoints within that space. 
+
+
+## {{elastic-endpoint}} artifacts [spaces-security-faq-endpoint-artifacts]
+
+**What are Endpoint artifacts?**
+
+Endpoint artifacts are the various objects that can be associated with {{elastic-endpoint}}s and {{elastic-defend}} policies. These include Trusted Applications, Event Filters, Host Isolation Exceptions, and Blocklist items. Artifacts can be global (shared across all policies) or per-policy (specific to individual policies). Per-policy configuration of artifacts is available only with an Enterprise license.
+
+
+**How do global artifacts work across spaces?**
+
+Global artifacts are space agnostic and thus eppear in all spaces.
+
+
+**How do policy-specific artifacts work across spaces?**
+
+Users can assign artifacts to any policies they have access to within their assigned space.
+
+When an artifact entry is created within a space, it is owned by that space. To edit or delete the artifact, you must either be in the owning space or have Global management privileges. 
+
+
+**What happens if my policy uses an artifact owned by a space I don't have access to?**
+
+When viewing a policy, you will still see all artifacts associated with it - regardless of which space they were created in. However, artifacts viewed outside of their owning space will appear as read-only.
+
+If an artifact is associated with a policy that isn't visible in the current space, only the policy's UUID will appear in the "Applied to the following policies" pop-up. For policies accessible within the space, the full policy name will appear.
+
+
+**Why is an endpoint artifact marked as “read-only”?**
+
+An artifact may appear as read-only if:
+- It is a global artifact, and you do not have Global management privileges.
+- The artifact was created in a different space.
+
+In these situations, editing may be disabled, and tooltips will provide additional context.
+
+
+**How can I tell which space “owns” a per-policy artifact?**
+
+Each artifact has a `tag` field, whose value corresponds to the owner space's ID. The format of this tag is `ownerspaceId:<space_id_here>`, for example: `ownerspaceId:default`.
+
+
+## RBAC [spaces-security-faq-rbac]
+
+**How does RBAC work for artifacts assigned to a particular space?**
+
+Specific {{kib}} privileges for each artifact type (such as Event Filters or Trusted Applications) allow you to manage (create, edit, delete, and assign) those artifacts types globally or per policy, but only for policies within the spaces you have access to. These artifact types include 
+
+* Trusted applications
+* Host isolation exceptions
+* Blocklist items
+* Event filters
+
+The `Global Artifact Management` privilege grants full control over artifacts in any space. This privilege by itself does not enable you to manage the different artifact types, but rather grants additional privileged actions to those users that have the “All” privilege to a given artifact type. This includes the ability to:
+
+* Create, edit, and delete global artifacts of any type
+* Manage per-policy artifacts, even if they were created in a different space
+* Convert an artifact between global and per-policy scope
+
+Endpoint Exceptions are global only, so you need the `Global Artifact Management` privilege to create, edit, or delete them.
+
+
+**How do I change which space owns a per-policy artifact?**
+
+Artifact tags enable you to change the owning space of per-policy artifacts (those not assigned globally). When an artifact is created, a tag for the space it was created in is automatically added. The format of this tag is `ownerspaceId:<space_id_here>`, for example: `ownerspaceId:default`. Artifacts can have multiple owner space tags, which enables you to have multiple spaces where you can manage per-policy artifacts.
+
+Updates to owner space tags are supported via API. This type of update requires that you have the `Global Artifact Management` privilege. Refer to the [Security API docs](/solutions/security/apis.md) to learn how to use each artifact type's corresponding API.
+
+
+**What happens if I delete a space that “owns” certain per-policy artifacts?**
+
+When a space is deleted, artifacts that were previously created from the deleted space will continue to be manageable by  users who have the `Global Artifact Management` privilege. Alternatively, you can update their owner space via API, as detailed above.
+
+
+
+## Endpoint response actions [spaces-security-faq-endpoint-response-actions]
+
+**How do spaces impact Response Actions**
+
+Response actions for both {{elastic-defend}} and third-party EDR solutions are associated with the {{fleet}} integration policy that's connected to the {{elastic-agent}} that executed the response action. A user authorized to view the response actions history Log can only view items associated with integration policies that are accessible in the active space. If you share an integration policy with a new space, the associated response actions will automatically become visible in that space. There are some conditions that can result in response action history not being accessible by default-we call these “ophan” response actions (refer to [What are orphan response actions and how can I access them?](#spaces-security-faq-orphan-response-actions)).
+
+
+**How are response actions visible across spaces?**
+
+You can see the response action history for hosts whose Fleet integration policies are visible in the the current space. This includes actions initiated in other spaces; you can see all historical response actions associated with integration policies that are accessible in your current space.
+
+
+**If a policy is deleted, how does that impact my response history?**
+
+When an integration policy is deleted in {{fleet}}, response actions associated with that integration policy will become orphans and will no longer be accessible via the response action history log. You can force these actions to appear in the action history log (refer to [What are orphan response actions and how can I access them?](#spaces-security-faq-orphan-response-actions)).
+
+
+**What happens if my {{agent}} moves to a new integration policy?**
+
+When an {{agent}} moves to a new integration policy, its response actions history will continue to be visible as long as the prior integration policy is not deleted and continues remains accessible from the same spaces that the new integration policy is shared with.
+
+If the new integration policy is not shared with the same spaces as the prior integration policy, then some history may be hidden; you can only view response action history for integration policies you have access to in the current space.
+
+
+**How are automated response actions impacted by spaces?**
+
+Automated response actions (currently supported only for {{elastic-defend}}) work similarly to regular response actions, with a few caveats:
+
+* If you unenroll a host before the detection engine processes an event from that host, the response action will fail. The failed response action will not appear in the UI (either as part of the alert details, or in the response actions history log) because it won't be associated with the agent policy that was running on the host. These actions will become orphans (refer to [What are orphan response actions and how can I access them?](#spaces-security-faq-orphan-response-actions)).
+
+* If a policy that triggered automated response actions moves to a new space or is shared with a new space, links to the detection engine rule that triggered the automated response actions will go to a “rule not found” page. This occurs because the rule is space-specific and not accessible in your current space.
+
+
+**How are third party EDR response actions impacted by spaces?**
+
+Response actions for third party EDR systems behave the same as response actions for {{elastic-defend}}. However, each space must be configured to support the given 3rd party EDR system. For example, each space must have its own connector to the third-party system.
+
+
+**Will third party EDR response actions continue to work if I move (or share) the associated policy to a new space?**
+
+No, response actions will not work unless a connector for the given third party EDR exists in the space where the policy was moved. Connectors are space specific and can not be shared or moved to a new space, thus a new instance of the connector must be created in the new space so that the policy in that space can send response actions to the third party system.
+
+
+## What are orphan response actions? [spaces-security-faq-orphan-response-actions]
+“Orphan” response actions are those associated only with deleted integration policies. These response actions are not visible in the response action history log because it can't be determined whether your current space has visibility of the policy associated with the response actions.
+
+
+**How can I access orphan response actions?**
+
+To make orphan response actions visible in a given space, you can make an API call with the space ID where you want them to appear. Below are several examples:
+
+::::{important}
+in order to use this API, you need {{kib}}'s built-in `superuser` role.
+::::
+
+:::{dropdown} View current orphan response actions space id:
+
+API call:
+`GET /internal/api/endpoint/action/_orphan_actions_space`
+
+Response: 
+```
+{
+  "data": {
+    "spaceId": "admin"
+  }
+}
+```
+:::
+
+:::{dropdown} Update orphan response action space id:
+API call:
+```
+POST /internal/api/endpoint/action/_orphan_actions_space
+{
+  "spaceId": "admin"
+}
+```
+
+Response:
+```
+{
+  "data": {
+    "spaceId": "admin"
+  }
+}
+```
+:::
+
+To remove the space ID where orphan response actions appear, call the API with an empty string for `spaceId`.
+
+
+## Endpoint Detection Rules [spaces-security-faq-endpoint-detection-rules]
+
+By default, prebuilt detection rules use an index pattern that may be too broad for use in a particular space. In order to ensure that the space only shows the desired data in that space, you may need to customize the rule.
+For example, the {{elastic-defend}} rule has an index pattern that picks up all data sent to `logs-endpoint.alerts-*`. This index pattern would pick up all events sent by Elastic Defend which may not be desirable. 
+
+
+## Osquery [spaces-security-faq-osquery]
+
+Osquery artifacts are not yet space aware. They can only exist within a single space.

solutions/toc.yml

@@ -474,6 +474,8 @@ toc:
               - file: security/get-started/agentless-integrations.md
               - file: security/get-started/agentless-integrations-faq.md
           - file: security/get-started/spaces-elastic-security.md
+            children:
+              - file: security/get-started/spaces-security-faq.md
           - file: security/get-started/data-views-elastic-security.md
           - file: security/get-started/create-runtime-fields-in-elastic-security.md
           - file: security/get-started/configure-advanced-settings.md