SentinelOne bidirectional processes, kill-process, and detection …

…rule updates [ESS] (#5735)

* Fix no-op typo in MDX

* Draft all the changes from serverless

* Remove weird extra spaces

* Fix table header row

(cherry picked from commit 9c34da7)

# Conflicts:
#	docs/serverless/endpoint-response-actions/response-actions-config.mdx

docs/management/admin/response-actions-config.asciidoc

@@ -113,16 +113,21 @@ IMPORTANT: Do not create more than one SentinelOne connector.
    - **API token**: The SentinelOne API access token you generated previously, with permission to read SentinelOne data and perform actions on enrolled hosts.
 .. Click **Save**.
 
-. **Create and enable a rule to generate {elastic-sec} alerts.** Create a <<create-custom-rule,custom query detection rule>> to generate {elastic-sec} alerts whenever SentinelOne generates alerts. 
+. **Create and enable detection rules to generate {elastic-sec} alerts.** Create <<create-custom-rule,detection rules>> to generate {elastic-sec} alerts based on SentinelOne events and data. 
 +
-Use these settings when creating the custom query rule to target the data collected from SentinelOne:
+This gives you visibility into SentinelOne without needing to leave {elastic-sec}. You can perform supported endpoint response actions directly from alerts that a rule creates, by using the **Take action** menu in the alert details flyout.
 +
---
-- **Index patterns**: `logs-sentinel_one.alert*`
-- **Custom query**: `observer.serial_number:*`
---
+When creating a rule, you can target any event containing a SentinelOne agent ID field. Use one or more of these index patterns:
 +
-NOTE: Do not include any other index patterns or query parameters.
+[cols="1,1"]
+|===
+|Index pattern                 |SentinelOne agent ID field
+
+|`logs-sentinel_one.alert*`    |`sentinel_one.alert.agent.id`
+|`logs-sentinel_one.threat*`   |`sentinel_one.threat.agent.id`
+|`logs-sentinel_one.activity*` |`sentinel_one.activity.agent.id`
+|`logs-sentinel_one.agent*`    |`sentinel_one.agent.agent.id`
+|===
 +
-This gives you visibility into SentinelOne without needing to leave {elastic-sec}. You can perform supported endpoint response actions directly from alerts that the rule creates, by using the **Take action** menu in the alert details flyout.
-====
+NOTE: Do not include any other index patterns.
+====

docs/management/admin/response-actions.asciidoc

@@ -69,6 +69,7 @@ Example: `release --comment "Release host, everything looks OK"`
 Show information about the host's status, including: {agent} status and version, the {elastic-defend} integration's policy status, and when the host was last active.
 
 [discrete]
+[[processes]]
 === `processes`
 Show a list of all processes running on the host. This action may take a minute or so to complete.
 
@@ -81,7 +82,10 @@ Use this command to get current PID or entity ID values, which are required for
 Entity IDs may be more reliable than PIDs, because entity IDs are unique values on the host, while PID values can be reused by the operating system.
 ====
 
+NOTE: Running this command on third-party-protected hosts might return the process list in a different format. Refer to <<third-party-actions>> for more information.
+
 [discrete]
+[[kill-process]]
 === `kill-process`
 
 Terminate a process. You must include one of the following parameters to identify the process to terminate:
@@ -93,6 +97,13 @@ Required privilege: *Process Operations*
 
 Example: `kill-process --pid 123 --comment "Terminate suspicious process"`
 
+[NOTE]
+====
+For SentinelOne-enrolled hosts, you must use the parameter `--processName` to identify the process to terminate. `--pid` and `--entityId` are not supported.
+
+Example: `kill-process --processName cat --comment "Terminate suspicious process"`
+====
+
 [discrete]
 === `suspend-process`
 

docs/management/admin/third-party-actions.asciidoc

@@ -52,4 +52,15 @@ Refer to the instructions on <<isolate-a-host,isolating>> and <<release-a-host,r
 +
 NOTE: For SentinelOne-enrolled hosts, you must use the password `Elastic@123` to open the retrieved file.
 
+* **Get a list of processes running on a host** with the <<processes, `processes` response action>>. For SentinelOne-enrolled hosts, this command returns a link for downloading the process list in a file.
+
+* **Terminate a process running on a host** with the <<kill-process, `kill-process` response action>>.
++
+[NOTE]
+====
+For SentinelOne-enrolled hosts, you must use the parameter `--processName` to identify the process to terminate. `--pid` and `--entityId` are not supported.
+
+Example: `kill-process --processName cat --comment "Terminate suspicious process"`
+====
+
 * **View past response action activity** in the <<response-actions-history,response actions history>> log.

docs/serverless/endpoint-response-actions/response-actions-config.mdx

@@ -0,0 +1,129 @@
+---
+slug: /serverless/security/response-actions-config
+title: Configure third-party response actions
+description: Configure ((elastic-sec)) to perform response actions on hosts protected by third-party systems.
+tags: ["serverless","security","how-to","configure"]
+---
+
+<DocBadge template="technical preview" />
+
+<DocCallOut template="technical_preview" />
+
+<div id="response-actions-config"></div>
+
+You can direct third-party endpoint protection systems to perform response actions on enrolled hosts, such as isolating a suspicious endpoint from your network, without leaving the ((elastic-sec)) UI. This page explains the configuration steps needed to enable response actions for these third-party systems:
+
+* CrowdStrike
+* SentinelOne
+
+Check out <DocLink slug="/serverless/security/third-party-actions" /> to learn which response actions are supported for each system.
+
+<DocCallOut title="Prerequisites">
+* <DocLink slug="/serverless/elasticsearch/manage-project">Project features add-on</DocLink>: Endpoint Protection Complete
+* <DocLink slug="/serverless/general/assign-user-roles">User roles</DocLink>: **SOC manager** or **Endpoint operations analyst**
+* Endpoints must have actively running third-party agents installed.
+</DocCallOut>
+
+Select a tab below for your endpoint security system:
+
+<DocTabs>
+    <DocTab name="CrowdStrike">
+    {/* NOTE TO CONTRIBUTORS: These DocTabs have very similar content. If you change anything 
+    in this tab, apply the change to the other tabs, too. */}
+    To configure response actions for CrowdStrike-enrolled hosts:
+
+    1. **Enable API access in CrowdStrike.** Create an API client in CrowdStrike to allow access to the system. Refer to CrowdStrike's docs for instructions.
+
+        - Give the API client the minimum privilege required to read CrowdStrike data and perform actions on enrolled hosts. Consider creating separate API clients for reading data and performing actions, to limit privileges allowed by each API client.
+
+        - Take note of the client ID, client secret, and base URL; you'll need them in later steps when you configure ((elastic-sec)) components to access CrowdStrike.<br /><br />
+
+    1. **Install the CrowdStrike integration and ((agent)).** Elastic's [CrowdStrike integration](((integrations-docs))/crowdstrike) collects and ingests logs into ((elastic-sec)).
+        1. Go to **Project Settings** → **Integrations**, search for and select **CrowdStrike**, then select **Add CrowdStrike**.
+        1. Configure the integration with an **Integration name** and optional **Description**.
+        1. Select **Collect CrowdStrike logs via API**, and enter the required **Settings**:
+            - **Client ID**: Client ID for the API client used to read CrowdStrike data.
+            - **Client Secret**: Client secret allowing you access to CrowdStrike.
+            - **URL**: The base URL of the CrowdStrike API.
+        1. Select the **Falcon Alerts** and **Hosts** sub-options under **Collect CrowdStrike logs via API**.
+        1. Scroll down and enter a name for the agent policy in **New agent policy name**. If other agent policies already exist, you can click the **Existing hosts** tab and select an existing policy instead. For more details on ((agent)) configuration settings, refer to [((agent)) policies](((fleet-guide))/agent-policy.html).
+        1. Click **Save and continue**.
+        1. Select **Add ((agent)) to your hosts** and continue with the <DocLink slug="/serverless/security/install-edr" section="enroll-agent">((agent)) installation steps</DocLink> to install ((agent)) on a resource in your network (such as a server or VM). ((agent)) will act as a bridge collecting data from CrowdStrike and sending it back to ((elastic-sec)).<br /><br />
+
+    1. **Create a CrowdStrike connector.** Elastic's [CrowdStrike connector](((kibana-ref))/crowdstrike-action-type.html) enables ((elastic-sec)) to perform actions on CrowdStrike-enrolled hosts.
+
+        <DocCallOut color="warning" title="Important">
+        Do not create more than one CrowdStrike connector.
+        </DocCallOut>
+
+        1. Go to **Stack Management** → **Connectors**, then select **Create connector**.
+        1. Select the **CrowdStrike** connector.
+        1. Enter the configuration information:
+            - **Connector name**: A name to identify the connector.
+            - **CrowdStrike API URL**: The base URL of the CrowdStrike API.
+            - **CrowdStrike Client ID**: Client ID for the API client used to perform actions in CrowdStrike.
+            - **Client Secret**: Client secret allowing you access to CrowdStrike.
+        1. Click **Save**.<br /><br />
+
+    1. **Create and enable detection rules to generate ((elastic-sec)) alerts.** (Optional) Create <DocLink slug="/serverless/security/rules-create">detection rules</DocLink> to generate ((elastic-sec)) alerts based on CrowdStrike events and data. The [CrowdStrike integration docs](((integrations-docs))/crowdstrike) list the available ingested logs and fields you can use to build a rule query.
+
+        This gives you visibility into CrowdStrike without needing to leave ((elastic-sec)). You can perform supported endpoint response actions directly from alerts that a rule creates, by using the **Take action** menu in the alert details flyout.
+    </DocTab>
+
+    <DocTab name="SentinelOne">
+    {/* NOTE TO CONTRIBUTORS: These DocTabs have very similar content. If you change anything 
+    in this tab, apply the change to the other tabs, too. */}
+    To configure response actions for SentinelOne-enrolled hosts:
+
+    1. **Generate API access tokens in SentinelOne.** You'll need these tokens in later steps, and they allow ((elastic-sec)) to collect data and perform actions in SentinelOne.
+
+        Create two API tokens in SentinelOne, and give them the minimum privilege required by the Elastic components that will use them:
+            - SentinelOne integration: Permission to read SentinelOne data.
+            - SentinelOne connector: Permission to read SentinelOne data and perform actions on enrolled hosts (for example, isolating and releasing an endpoint).<br /><br />
+
+        Refer to the [SentinelOne integration docs](((integrations-docs))/sentinel_one) or SentinelOne's docs for details on generating API tokens.<br /><br />
+
+    1. **Install the SentinelOne integration and ((agent)).** Elastic's [SentinelOne integration](((integrations-docs))/sentinel_one) collects and ingests logs into ((elastic-sec)).
+
+        1. Go to **Project Settings** → **Integrations**, search for and select **SentinelOne**, then select **Add SentinelOne**.
+        1. Configure the integration with an **Integration name** and optional **Description**.
+        1. Ensure that **Collect SentinelOne logs via API** is selected, and enter the required **Settings**:
+            - **URL**: The SentinelOne console URL.
+            - **API Token**: The SentinelOne API access token you generated previously, with permission to read SentinelOne data.
+        1. Scroll down and enter a name for the agent policy in **New agent policy name**. If other agent policies already exist, you can click the **Existing hosts** tab and select an existing policy instead. For more details on ((agent)) configuration settings, refer to [((agent)) policies](((fleet-guide))/agent-policy.html).
+        1. Click **Save and continue**.
+        1. Select **Add ((agent)) to your hosts** and continue with the <DocLink slug="/serverless/security/install-edr" section="enroll-agent">((agent)) installation steps</DocLink> to install ((agent)) on a resource in your network (such as a server or VM). ((agent)) will act as a bridge collecting data from SentinelOne and sending it back to ((elastic-sec)).<br /><br />
+
+    1. **Create a SentinelOne connector.** Elastic's [SentinelOne connector](((kibana-ref))/sentinelone-action-type.html) enables ((elastic-sec)) to perform actions on SentinelOne-enrolled hosts.            
+
+            <DocCallOut color="warning" title="Important">
+            Do not create more than one SentinelOne connector.
+            </DocCallOut>
+
+            1. Go to **Stack Management** → **Connectors**, then select **Create connector**.
+            1. Select the **SentinelOne** connector.
+            1. Enter the configuration information:
+                - **Connector name**: A name to identify the connector.
+                - **SentinelOne tenant URL**: The SentinelOne tenant URL.
+                - **API token**: The SentinelOne API access token you generated previously, with permission to read SentinelOne data and perform actions on enrolled hosts.
+            1. Click **Save**.<br /><br />
+
+    1. **Create and enable detection rules to generate ((elastic-sec)) alerts.** (Optional) Create <DocLink slug="/serverless/security/rules-create">detection rules</DocLink> to generate ((elastic-sec)) alerts based on SentinelOne events and data.
+
+        This gives you visibility into SentinelOne without needing to leave ((elastic-sec)). You can perform supported endpoint response actions directly from alerts that a rule creates, by using the **Take action** menu in the alert details flyout.
+
+        When creating a rule, you can target any event containing a SentinelOne agent ID field. Use one or more of these index patterns:
+
+        | Index pattern                 | SentinelOne agent ID field       |
+        | ----------------------------- | -------------------------------- |
+        | `logs-sentinel_one.alert*`    | `sentinel_one.alert.agent.id`    |
+        | `logs-sentinel_one.threat*`   | `sentinel_one.threat.agent.id`   |
+        | `logs-sentinel_one.activity*` | `sentinel_one.activity.agent.id` |
+        | `logs-sentinel_one.agent*`    | `sentinel_one.agent.agent.id`    |
+
+        <DocCallOut title="Note">
+        Do not include any other index patterns.
+        </DocCallOut>
+
+    </DocTab>
+</DocTabs>