From 304d173368a0d105ce6c0000e961bdc217e7c459 Mon Sep 17 00:00:00 2001 From: Joe Peeples Date: Mon, 11 Nov 2024 16:31:20 -0500 Subject: [PATCH 1/2] Nav changes for "Manage Elastic Defend" and "Endpoint response actions" sections (#6073) * Update "Trusted applications" * Update "Event filters" * Update "Host isolation exceptions" * Update "Blocklist" * Update "Isolate a host" * Update "Response actions history" * Update "Configure third-party response actions" * Fix "Configure third-party response actions" * Apply suggestions from Nastasha's review Co-authored-by: Nastasha Solomon <79124755+nastasha-solomon@users.noreply.github.com> * Revise to "navigation menu" --------- Co-authored-by: Nastasha Solomon <79124755+nastasha-solomon@users.noreply.github.com> (cherry picked from commit 5f71cc157e32632ce49a9fc63e23c5dfa3b78734) # Conflicts: # docs/serverless/edr-manage/blocklist.asciidoc # docs/serverless/edr-manage/event-filters.asciidoc # docs/serverless/edr-manage/host-isolation-exceptions.asciidoc # docs/serverless/edr-manage/trusted-apps-ov.asciidoc # docs/serverless/endpoint-response-actions/host-isolation-ov.asciidoc # docs/serverless/endpoint-response-actions/response-actions-config.asciidoc # docs/serverless/endpoint-response-actions/response-actions-history.asciidoc --- docs/management/admin/blocklist.asciidoc | 4 +- docs/management/admin/event-filters.asciidoc | 4 +- .../admin/host-isolation-exceptions.asciidoc | 2 +- .../admin/host-isolation-ov.asciidoc | 6 +- .../admin/response-actions-config.asciidoc | 8 +- .../admin/response-actions-history.asciidoc | 2 +- docs/management/admin/trusted-apps.asciidoc | 2 +- docs/serverless/edr-manage/blocklist.asciidoc | 96 ++++++++++ .../edr-manage/event-filters.asciidoc | 119 +++++++++++++ .../host-isolation-exceptions.asciidoc | 78 +++++++++ .../edr-manage/trusted-apps-ov.asciidoc | 103 +++++++++++ .../host-isolation-ov.asciidoc | 164 +++++++++++++++++ .../response-actions-config.asciidoc | 165 ++++++++++++++++++ .../response-actions-history.asciidoc | 41 +++++ 14 files changed, 779 insertions(+), 15 deletions(-) create mode 100644 docs/serverless/edr-manage/blocklist.asciidoc create mode 100644 docs/serverless/edr-manage/event-filters.asciidoc create mode 100644 docs/serverless/edr-manage/host-isolation-exceptions.asciidoc create mode 100644 docs/serverless/edr-manage/trusted-apps-ov.asciidoc create mode 100644 docs/serverless/endpoint-response-actions/host-isolation-ov.asciidoc create mode 100644 docs/serverless/endpoint-response-actions/response-actions-config.asciidoc create mode 100644 docs/serverless/endpoint-response-actions/response-actions-history.asciidoc diff --git a/docs/management/admin/blocklist.asciidoc b/docs/management/admin/blocklist.asciidoc index be409bbab0..d619e712c2 100644 --- a/docs/management/admin/blocklist.asciidoc +++ b/docs/management/admin/blocklist.asciidoc @@ -16,7 +16,7 @@ The blocklist is not intended to broadly block benign applications for non-secur By default, a blocklist entry is recognized globally across all hosts running {elastic-defend}. If you have a https://www.elastic.co/pricing[Platinum or Enterprise subscription], you can also assign a blocklist entry to specific {elastic-defend} integration policies, which blocks the process only on hosts assigned to that policy. -. Go to **Manage** -> **Blocklist**. +. Find **Blocklist** in the navigation menu or use the {kibana-ref}/introduction.html#kibana-navigation-search[global search field]. . Click **Add blocklist entry**. The **Add blocklist** flyout appears. @@ -49,7 +49,7 @@ NOTE: You can also select the `Per Policy` option without immediately assigning . Click **Add blocklist**. The new entry is added to the **Blocklist** page. . When you're done adding entries to the blocklist, ensure that the blocklist is enabled for the {elastic-defend} integration policies that you just assigned: -.. Go to **Manage** -> **Policies**, then click on an integration policy. +.. Go to the **Policies** page, then click on an integration policy. .. On the **Policy settings** tab, ensure that the **Malware protections** and **Blocklist** toggles are switched on. Both settings are enabled by default. [discrete] diff --git a/docs/management/admin/event-filters.asciidoc b/docs/management/admin/event-filters.asciidoc index f14cf9d388..94a64c0e43 100644 --- a/docs/management/admin/event-filters.asciidoc +++ b/docs/management/admin/event-filters.asciidoc @@ -22,7 +22,6 @@ Create event filters from the Hosts page or the Event filters page. + -- * To create an event filter from the Hosts page: -.. Go to *Explore* -> *Hosts*. .. Select the *Events* tab to view the Events table. + .. Find the event to filter, click the *More actions* menu (*...*), then select *Add Endpoint event filter*. @@ -31,8 +30,7 @@ TIP: Since you can only create filters for endpoint events, be sure to filter th For example, in the KQL search bar, enter the following query to find endpoint network events: `event.dataset : endpoint.events.network`. * To create an event filter from the Event filters page: -.. Go to *Manage* -> *Event filters*. -.. Click *Add event filter*. The *Add event filter* flyout opens. +.. Cick *Add event filter*, which opens a flyout. -- + [role="screenshot"] diff --git a/docs/management/admin/host-isolation-exceptions.asciidoc b/docs/management/admin/host-isolation-exceptions.asciidoc index 273581e35c..eca44717ac 100644 --- a/docs/management/admin/host-isolation-exceptions.asciidoc +++ b/docs/management/admin/host-isolation-exceptions.asciidoc @@ -21,7 +21,7 @@ You must have the *Host Isolation Exceptions* < **Host isolation exceptions**. +. Find **Host isolation exceptions** in the navigation menu or use the {kibana-ref}/introduction.html#kibana-navigation-search[global search field]. . Click **Add Host isolation exception**. . Fill in these fields in the **Add Host isolation exception** flyout: .. `Name your host isolation exceptions`: Enter a name to identify the host isolation exception. diff --git a/docs/management/admin/host-isolation-ov.asciidoc b/docs/management/admin/host-isolation-ov.asciidoc index 7240328094..f199ee7e33 100644 --- a/docs/management/admin/host-isolation-ov.asciidoc +++ b/docs/management/admin/host-isolation-ov.asciidoc @@ -55,7 +55,7 @@ All actions executed on a host are tracked in the host’s response actions hist .Isolate a host from an endpoint [%collapsible] ==== -. Go to *Manage -> Endpoints*, then either: +. Find **Endpoints** in the navigation menu or use the {kibana-ref}/introduction.html#kibana-navigation-search[global search field], then either: * Select the appropriate endpoint in the *Endpoint* column, and click *Take action -> Isolate host* in the endpoint details flyout. * Click the *Actions* menu (*...*) on the appropriate endpoint, then select *Isolate host*. . Enter a comment describing why you’re isolating the host (optional). @@ -112,7 +112,7 @@ image::images/host-isolated-notif.png[Host isolated notification message,350] .Release a host from an endpoint [%collapsible] ==== -. Go to *Manage -> Endpoints*, then either: +. Find **Endpoints** in the navigation menu or use the {kibana-ref}/introduction.html#kibana-navigation-search[global search field], then either: * Select the appropriate endpoint in the *Endpoint* column, and click *Take action -> Release host* in the endpoint details flyout. * Click the *Actions* menu (*...*) on the appropriate endpoint, then select *Release host*. . Enter a comment describing why you're releasing the host (optional). @@ -142,7 +142,7 @@ image::images/host-released-notif.png[Host released notification message,350] To confirm if a host has been successfully isolated or released, check the response actions history, which logs the response actions performed on a host. -Go to *Manage* -> *Endpoints*, click an endpoint's name, then click the *Response action history* tab. You can filter the information displayed in this view. Refer to <> for more details. +Go to the *Endpoints* page, click an endpoint's name, then click the *Response action history* tab. You can filter the information displayed in this view. Refer to <> for more details. [role="screenshot"] image::images/response-actions-history-endpoint-details.png[Response actions history page UI,75%] \ No newline at end of file diff --git a/docs/management/admin/response-actions-config.asciidoc b/docs/management/admin/response-actions-config.asciidoc index e38ab3022a..2ee54f0965 100644 --- a/docs/management/admin/response-actions-config.asciidoc +++ b/docs/management/admin/response-actions-config.asciidoc @@ -43,7 +43,7 @@ Expand a section below for your endpoint security system: . **Install the CrowdStrike integration and {agent}.** Elastic's {integrations-docs}/crowdstrike[CrowdStrike integration] collects and ingests logs into {elastic-sec}. + -.. Go to **Integrations**, search for and select **CrowdStrike**, then select **Add CrowdStrike**. +.. Find **Integrations** in the navigation menu or use the {kibana-ref}/introduction.html#kibana-navigation-search[global search field], search for and select **CrowdStrike**, then select **Add CrowdStrike**. .. Configure the integration with an **Integration name** and optional **Description**. .. Select **Collect CrowdStrike logs via API**, and enter the required **Settings**: - **Client ID**: Client ID for the API client used to read CrowdStrike data. @@ -58,7 +58,7 @@ Expand a section below for your endpoint security system: + IMPORTANT: Do not create more than one CrowdStrike connector. + -.. Go to **Stack Management** → **Connectors**, then select **Create connector**. +.. Find **Connectors** in the navigation menu or use the {kibana-ref}/introduction.html#kibana-navigation-search[global search field], then select **Create connector**. .. Select the CrowdStrike connector. .. Enter the configuration information: - **Connector name**: A name to identify the connector. @@ -92,7 +92,7 @@ Refer to the {integrations-docs}/sentinel_one[SentinelOne integration docs] or S . **Install the SentinelOne integration and {agent}.** Elastic's {integrations-docs}/sentinel_one[SentinelOne integration] collects and ingests logs into {elastic-sec}. + -.. Go to **Integrations**, search for and select **SentinelOne**, then select **Add SentinelOne**. +.. Find **Integrations** in the navigation menu or use the {kibana-ref}/introduction.html#kibana-navigation-search[global search field], search for and select **SentinelOne**, then select **Add SentinelOne**. .. Configure the integration with an **Integration name** and optional **Description**. .. Ensure that **Collect SentinelOne logs via API** is selected, and enter the required **Settings**: - **URL**: The SentinelOne console URL. @@ -105,7 +105,7 @@ Refer to the {integrations-docs}/sentinel_one[SentinelOne integration docs] or S + IMPORTANT: Do not create more than one SentinelOne connector. -.. Go to **Stack Management** → **Connectors**, then select **Create connector**. +.. Find **Connectors** in the navigation menu or use the {kibana-ref}/introduction.html#kibana-navigation-search[global search field], then select **Create connector**. .. Select the **SentinelOne** connector. .. Enter the configuration information: - **Connector name**: A name to identify the connector. diff --git a/docs/management/admin/response-actions-history.asciidoc b/docs/management/admin/response-actions-history.asciidoc index cd71633a28..8b9b4e0b29 100644 --- a/docs/management/admin/response-actions-history.asciidoc +++ b/docs/management/admin/response-actions-history.asciidoc @@ -14,7 +14,7 @@ You must have the *Response Actions History* <> to access this feature. -- -To access the response actions history for all endpoints, go to *Manage* -> *Response actions history*. You can also access the response actions history for an individual endpoint from these areas: +To access the response actions history for all endpoints, find **Response actions history** in the navigation menu or use the {kibana-ref}/introduction.html#kibana-navigation-search[global search field]. You can also access the response actions history for an individual endpoint from these areas: * *Endpoints* page: Click an endpoint's name to open the details flyout, then click the *Response actions history* tab. * *Response console* page: Click the *Response actions history* button. diff --git a/docs/management/admin/trusted-apps.asciidoc b/docs/management/admin/trusted-apps.asciidoc index 57dc0869fc..9a15767810 100644 --- a/docs/management/admin/trusted-apps.asciidoc +++ b/docs/management/admin/trusted-apps.asciidoc @@ -22,7 +22,7 @@ By default, a trusted application is recognized globally across all hosts runnin To add a trusted application: -. Go to *Manage* -> *Trusted applications*. +. Find **Trusted applications** in the navigation menu or use the {kibana-ref}/introduction.html#kibana-navigation-search[global search field]. . Click *Add trusted application*. diff --git a/docs/serverless/edr-manage/blocklist.asciidoc b/docs/serverless/edr-manage/blocklist.asciidoc new file mode 100644 index 0000000000..668cf8b9ba --- /dev/null +++ b/docs/serverless/edr-manage/blocklist.asciidoc @@ -0,0 +1,96 @@ +[[security-blocklist]] += Blocklist + +// :keywords: serverless, security, how-to + +preview:[] + +The blocklist allows you to prevent specified applications from running on hosts, extending the list of processes that {elastic-defend} considers malicious. This helps ensure that known malicious processes aren't accidentally executed by end users. + +The blocklist is not intended to broadly block benign applications for non-security reasons; only use it to block potentially harmful applications. To compare the blocklist with other endpoint artifacts, refer to <>. + +.Requirements +[NOTE] +==== +* In addition to configuring specific entries on the **Blocklist** page, you must also ensure that the blocklist is enabled on the {elastic-defend} integration policy in the <>. This setting is enabled by default. +* You must have the appropriate user role to use this feature. + +// Placeholder statement until we know which specific roles are required. Classic statement below for reference. + +// * You must have the **Blocklist** privilege to access this feature. +==== + +By default, a blocklist entry is recognized globally across all hosts running {elastic-defend}. You can also assign a blocklist entry to specific {elastic-defend} integration policies, which blocks the process only on hosts assigned to that policy. + +. Find **Blocklist** in the navigation menu or use the global search field. +. Click **Add blocklist entry**. The **Add blocklist** flyout appears. +. Fill in these fields in the **Details** section: ++ +.. `Name`: Enter a name to identify the application in the blocklist. +.. `Description`: Enter a description to provide more information on the blocklist entry (optional). +. In the **Conditions** section, enter the following information about the application you want to block: ++ +.. `Select operating system`: Select the appropriate operating system from the drop-down. +.. `Field`: Select a field to identify the application being blocked: ++ +*** `Hash`: The MD5, SHA-1, or SHA-256 hash value of the application's executable. +*** `Path`: The full file path of the application's executable. +*** `Signature`: (Windows only) The name of the application's digital signer. ++ +[TIP] +==== +To find the signer's name for an application, go to **Discover** and query the process name of the application's executable (for example, `process.name : "mctray.exe"` for a McAfee security binary). Then, search the results for the `process.code_signature.subject_name` field, which contains the signer's name (for example, `McAfee, Inc.`). +==== +.. `Operator`: For hash and path conditions, the operator is `is one of` and can't be modified. For signature conditions, choose `is one of` to enter multiple values or `is` for one value. +.. `Value`: Enter the hash value, file path, or signer name. To enter multiple values (such as a list of known malicious hash values), you can enter each value individually or paste a comma-delimited list, then press **Return**. ++ +[NOTE] +==== +Hash values must be valid to add them to the blocklist. +==== +. Select an option in the **Assignment** section to assign the blocklist entry to a specific integration policy: ++ +** `Global`: Assign the blocklist entry to all {elastic-defend} integration policies. +** `Per Policy`: Assign the blocklist entry to one or more specific {elastic-defend} integration policies. Select each policy where you want the blocklist entry to apply. ++ +[NOTE] +==== +You can also select the `Per Policy` option without immediately assigning a policy to the blocklist entry. For example, you could do this to create and review your blocklist configurations before putting them into action with a policy. +==== +. Click **Add blocklist**. The new entry is added to the **Blocklist** page. +. When you're done adding entries to the blocklist, ensure that the blocklist is enabled for the {elastic-defend} integration policies that you just assigned: ++ +.. Go to the **Policies** page, then click on an integration policy. +.. On the **Policy settings** tab, ensure that the **Malware protections** and **Blocklist** toggles are switched on. Both settings are enabled by default. + +[discrete] +[[manage-blocklist]] +== View and manage the blocklist + +The **Blocklist** page displays all the blocklist entries that have been added to the {security-app}. To refine the list, use the search bar to search by name, description, or field value. + +[role="screenshot"] +image::images/blocklist/-management-admin-blocklist.png[] + +[discrete] +[[edit-blocklist-entry]] +=== Edit a blocklist entry + +You can individually modify each blocklist entry. You can also change the policies that a blocklist entry is assigned to. + +To edit a blocklist entry: + +. Click the actions menu (image:images/icons/boxesHorizontal.svg[Actions menu icon]) for the blocklist entry you want to edit, then select **Edit blocklist**. +. Modify details as needed. +. Click **Save**. + +[discrete] +[[delete-blocklist-entry]] +=== Delete a blocklist entry + +You can delete a blocklist entry, which removes it entirely from all {elastic-defend} policies. This allows end users to access the application that was previously blocked. + +To delete a blocklist entry: + +. Click the actions menu (image:images/icons/boxesHorizontal.svg[Actions menu icon]) for the blocklist entry you want to delete, then select **Delete blocklist**. +. On the dialog that opens, verify that you are removing the correct blocklist entry, then click **Delete**. A confirmation message displays. diff --git a/docs/serverless/edr-manage/event-filters.asciidoc b/docs/serverless/edr-manage/event-filters.asciidoc new file mode 100644 index 0000000000..f2154ae32c --- /dev/null +++ b/docs/serverless/edr-manage/event-filters.asciidoc @@ -0,0 +1,119 @@ +[[security-event-filters]] += Event filters + +// :keywords: serverless, security, how-to + +preview:[] + +Event filters allow you to filter out endpoint events that you don't want stored in {es} — for example, high-volume events. By creating event filters, you can optimize your storage in {es}. + +Event filters do not lower CPU usage on hosts; {elastic-endpoint} still monitors events to detect and prevent possible threats, but without writing event data to {es}. To compare event filters with other endpoint artifacts, refer to <>. + +.Requirements +[NOTE] +==== +You must have the appropriate user role to use this feature. + +// Placeholder statement until we know which specific roles are required. Classic statement below for reference. + +// You must have the **Event Filters** privilege to access this feature. +==== + +[IMPORTANT] +==== +Since an event filter blocks an event from streaming to {es}, be conscious of event filter conditions you set and any existing rule conditions. If there is too much overlap, the rule may run less frequently than specified and, therefore, will not trigger the corresponding alert for that rule. This is the expected behavior of event filters. +==== + +By default, event filters are recognized globally across all hosts running {elastic-defend}. You can also assign an event filter to a specific {elastic-defend} integration policy, which would filter endpoint events from the hosts assigned to that policy. + +Create event filters from the Hosts page or the Event filters page. + +. Do one of the following: ++ +** To create an event filter from the Hosts page: ++ +... Select the **Events** tab to view the Events table. +... Find the event to filter, click the **More actions** menu (image:images/icons/boxesHorizontal.svg[More actions menu icon]), then select **Add Endpoint event filter**. ++ +[TIP] +==== +Since you can only create filters for endpoint events, be sure to filter the Events table to display events generated by the {elastic-endpoint}. +For example, in the KQL search bar, enter the following query to find endpoint network events: `event.dataset : endpoint.events.network`. +==== +** To create an event filter from the Event filters page: ++ +... Click **Add event filter**, which opens a flyout. ++ +[role="screenshot"] +image::images/event-filters/-management-admin-event-filter.png[] +. Fill in these fields in the **Details** section: ++ +.. `Name`: Enter a name for the event filter. +.. `Description`: Enter a filter description (optional). +. In the **Conditions** section, depending which page you're using to create the filter, either modify the pre-populated conditions or add new conditions to define how {elastic-sec} will filter events. Use these settings: ++ +.. `Select operating system`: Select the appropriate operating system. +.. Select which kind of event filter you'd like to create: ++ +*** `Events`: Create a generic event filter that can match any event type. All matching events are excluded. +*** `Process Descendants`: Specify a process, and suppress the activity of its descendant processes. Events from the matched process will be ingested, but events from its descendant processes will be excluded. ++ +This option adds the condition `event.category is process` to narrow the filter to process-type events. You can add more conditions to identify the process whose descendants you want to exclude. +.. `Field`: Select a field to identify the event being filtered. +.. `Operator`: Select an operator to define the condition. Available options are: ++ +*** `is` +*** `is not` +*** `is one of` +*** `is not one of` +*** `matches` | `does not match`: Allows you to use wildcards in `Value`, such as `C:\path*\app.exe`. Available wildcards are `?` (match one character) and `*` (match zero or more characters). ++ +[IMPORTANT] +==== +Using wildcards in file paths can impact performance. To create a more efficient event filter using wildcards, use multiple conditions and make them as specific as possible. For example, adding conditions using `process.name` or `file.name` can help limit the scope of wildcard matching. +==== +.. `Value`: Enter the value associated with the `Field`. To enter multiple values (when using `is one of` or `is not one of`), enter each value, then press **Return**. +. To define multiple conditions, click the `AND` button and configure a new condition. You can also add nested conditions with the `Add nested condition` button. For example, the event filter pictured above excludes events whose `event.category` field is `network`, and whose `process.executable` field is as specified. +. Select an option in the **Assignment** section to assign the event filter to a specific integration policy: ++ +** `Global`: Assign the event filter to all integration policies for {elastic-defend}. +** `Per Policy`: Assign the event filter to one or more specific {elastic-defend} integration policies. Select each policy in which you want the events to be filtered. ++ +[NOTE] +==== +You can also select the `Per Policy` option without immediately assigning a policy to the event filter. For example, you could do this to create and review your event filter configurations before putting them into action with a policy. +==== +. Add a comment if you want to provide more information about the event filter (optional). +. Click **Add event filter**. The new filter is added to the **Event filters** list. + +[discrete] +[[manage-event-filters]] +== View and manage event filters + +The **Event filters** page (**Assets** → **Event filters**) displays all the event filters that have been added to the {security-app}. To refine the list, use the search bar to search by filter name, description, comments, or field value. + +[role="screenshot"] +image::images/event-filters/-management-admin-event-filters-list.png[] + +[discrete] +[[edit-event-filter]] +=== Edit an event filter + +You can individually modify each event filter. You can also change the policies that an event filter is assigned to. + +To edit an event filter: + +. Click the actions menu (image:images/icons/boxesHorizontal.svg[Actions menu icon]) for the event filter you want to edit, then select **Edit event filter**. +. Modify details or conditions as needed. +. Click **Save**. + +[discrete] +[[delete-event-filter]] +=== Delete an event filter + +You can delete an event filter, which removes it entirely from all {elastic-defend} integration policies. + +To delete an event filter: + +. Click the actions menu (image:images/icons/boxesHorizontal.svg[Actions menu icon]) on the event filter you want to delete, then select **Delete event filter**. +. On the dialog that opens, verify that you are removing the correct event filter, then click **Delete**. A confirmation message is displayed. diff --git a/docs/serverless/edr-manage/host-isolation-exceptions.asciidoc b/docs/serverless/edr-manage/host-isolation-exceptions.asciidoc new file mode 100644 index 0000000000..1a4a274c37 --- /dev/null +++ b/docs/serverless/edr-manage/host-isolation-exceptions.asciidoc @@ -0,0 +1,78 @@ +[[security-host-isolation-exceptions]] += Host isolation exceptions + +// :keywords: serverless, security, how-to + +preview:[] + +You can configure host isolation exceptions for specific IP addresses that <> are still allowed to communicate with, even when blocked from the rest of your network. Isolated hosts can still send data to {elastic-sec}, so you don't need to set up host isolation exceptions for them. + +Host isolation exceptions support IPv4 addresses, with optional classless inter-domain routing (CIDR) notation. + +.Requirements +[NOTE] +==== +You must have the appropriate user role to use this feature. + +// Placeholder statement until we know which specific roles are required. Classic statement below for reference. + +// You must have the **Host Isolation Exceptions** privilege to access this feature. +==== + +[IMPORTANT] +==== +* Each host isolation exception IP address should be a highly trusted and secure location since you're allowing it to communicate with hosts that have been isolated to prevent a potential threat from spreading. +* If your hosts depend on VPNs for network communication, you should also set up host isolation exceptions for those VPN servers' IP addresses. +==== + +Host isolation requires the Endpoint Protection Complete <>. By default, a host isolation exception is recognized globally across all hosts running {elastic-defend}. You can also assign a host isolation exception to a specific {elastic-defend} integration policy, affecting only the hosts assigned to that policy. + +. Find **Host isolation exceptions** in the navigation menu or use the global search field. +. Click **Add Host isolation exception**. +. Fill in these fields in the **Add Host isolation exception** flyout: ++ +.. `Name your host isolation exceptions`: Enter a name to identify the host isolation exception. +.. `Description`: Enter a description to provide more information on the host isolation exception (optional). +.. `Enter IP Address`: Enter the IP address for which you want to allow communication with an isolated host. This must be an IPv4 address, with optional CIDR notation (for example, `0.0.0.0` or `1.0.0.0/24`, respectively). +. Select an option in the **Assignment** section to assign the host isolation exception to a specific integration policy: ++ +** `Global`: Assign the host isolation exception to all integration policies for {elastic-defend}. +** `Per Policy`: Assign the host isolation exception to one or more specific {elastic-defend} integration policies. Select each policy where you want the host isolation exception to apply. ++ +[NOTE] +==== +You can also select the `Per Policy` option without immediately assigning a policy to the host isolation exception. For example, you could do this to create and review your host isolation exception configurations before putting them into action with a policy. +==== +. Click **Add Host isolation exception**. The new exception is added to the **Host isolation exceptions** list. + +[discrete] +[[manage-host-isolation-exceptions]] +== View and manage host isolation exceptions + +The **Host isolation exceptions** page displays all the host isolation exceptions that have been configured for {elastic-sec}. To refine the list, use the search bar to search by name, description, or IP address. + +[role="screenshot"] +image::images/host-isolation-exceptions/-management-admin-host-isolation-exceptions-ui.png[List of host isolation exceptions] + +[discrete] +[[edit-host-isolation-exception]] +=== Edit a host isolation exception + +You can individually modify each host isolation exception and change the policies that a host isolation exception is assigned to. + +To edit a host isolation exception: + +. Click the actions menu (image:images/icons/boxesHorizontal.svg[Actions menu icon]) for the exception you want to edit, then select **Edit Exception**. +. Modify details as needed. +. Click **Save**. The newly modified exception appears at the top of the list. + +[discrete] +[[delete-host-isolation-exception]] +=== Delete a host isolation exception + +You can delete a host isolation exception, which removes it entirely from all {elastic-defend} integration policies. + +To delete a host isolation exception: + +. Click the actions menu (image:images/icons/boxesHorizontal.svg[Actions menu icon]) on the exception you want to delete, then select **Delete Exception**. +. On the dialog that opens, verify that you are removing the correct host isolation exception, then click **Delete**. A confirmation message is displayed. diff --git a/docs/serverless/edr-manage/trusted-apps-ov.asciidoc b/docs/serverless/edr-manage/trusted-apps-ov.asciidoc new file mode 100644 index 0000000000..3fd5307aff --- /dev/null +++ b/docs/serverless/edr-manage/trusted-apps-ov.asciidoc @@ -0,0 +1,103 @@ +[[security-trusted-applications]] += Trusted applications + +// :keywords: serverless, security, how-to + +preview:[] + +[NOTE] +==== +If you use {elastic-defend} along with other antivirus (AV) software, you might need to configure the other system to trust {elastic-endpoint}. Refer to <> for more information. +==== + +You can add Windows, macOS, and Linux applications that should be trusted, such as other antivirus or endpoint security applications. Trusted applications are designed to help mitigate performance issues and incompatibilities with other endpoint software installed on your hosts. Trusted applications apply only to hosts running the {elastic-defend} integration. + +.Requirements +[NOTE] +==== +You must have the appropriate user role to use this feature. + +// Placeholder statement until we know which specific roles are required. Classic statement below for reference. + +// You must have the **Trusted Applications** privilege to access this feature. +==== + +Trusted applications create blindspots for {elastic-defend}, because the applications are no longer monitored for threats. One avenue attackers use to exploit these blindspots is by DLL (Dynamic Link Library) side-loading, where they leverage processes signed by trusted vendors — such as antivirus software — to execute their malicious DLLs. Such activity appears to originate from the trusted application's process. + +Trusted applications might still generate alerts in some cases, such as if the application's process events indicate malicious behavior. To reduce false positive alerts, add an <>, which prevents {elastic-defend} from generating alerts. To compare trusted applications with other endpoint artifacts, refer to <>. + +Additionally, trusted applications still generate process events for visualizations and other internal use by the {stack}. To prevent process events from being written to {es}, use an <> to filter out the specific events that you don't want stored in {es}, but be aware that features that depend on these process events may not function correctly. + +By default, a trusted application is recognized globally across all hosts running {elastic-defend}. You can also assign a trusted application to a specific {elastic-defend} integration policy, enabling the application to be trusted by only the hosts assigned to that policy. + +To add a trusted application: + +. Find **Trusted applications** in the navigation menu or use the global search field. +. Click **Add trusted application**. +. Fill in the following fields in the **Add trusted application** flyout: ++ +** `Name your trusted application`: Enter a name for the trusted application. +** `Description`(Optional): Enter a description for the trusted application. +** `Select operating system`: Select the appropriate operating system from the drop-down. +** `Field`: Select a field to identify the trusted application: ++ +*** `Hash`: The MD5, SHA-1, or SHA-256 hash value of the application's executable. +*** `Path`: The full file path of the application's executable. +*** `Signature`: (Windows only) The name of the application's digital signer. ++ +[TIP] +==== +To find the signer's name for an application, go to **Discover** and query the process name of the application's executable (for example, `process.name : "mctray.exe"` for a McAfee security binary). Then, search the results for the `process.code_signature.subject_name` field, which contains the signer's name (for example, `McAfee, Inc.`). +==== +** `Operator`: Select an operator to define the condition: ++ +*** `is`: Must be _exactly_ equal to `Value`; wildcards are not supported. This operation is required for the `Hash` and `Signature` field types. +*** `matches`: Can include wildcards in `Value`, such as `C:\path*\app.exe`. This operator is only available for the `Path` field type. Available wildcards are `?` (match one character) and `*` (match zero or more characters). +** `Value`: Enter the hash value, file path, or signer name. To add an additional value, click **AND**. ++ +[NOTE] +==== +You can only add a single field type value per trusted application. For example, if you try to add two `Path` values, you'll get an error message. Also, an application's hash value must be valid to add it as a trusted application. In addition, to minimize visibility gaps in the {security-app}, be as specific as possible in your entries. For example, combine `Signature` information with a known `Path`. +==== +. Select an option in the **Assignment** section to assign the trusted application to a specific integration policy: ++ +** `Global`: Assign the trusted application to all integration policies for {elastic-defend}. +** `Per Policy`: Assign the trusted application to one or more specific {elastic-defend} integration policies. Select each policy in which you want the application to be trusted. ++ +[NOTE] +==== +You can also select the `Per Policy` option without immediately assigning a policy to the trusted application. For example, you could do this to create and review your trusted application configurations before putting them into action with a policy. +==== +. Click **Add trusted application**. The application is added to the **Trusted applications** list. + +[discrete] +[[trusted-apps-list]] +== View and manage trusted applications + +The **Trusted applications** page (**Assets** → **Trusted applications**) displays all the trusted applications that have been added to the {security-app}. To refine the list, use the search bar to search by name, description, or field value. + +[role="screenshot"] +image::images/trusted-apps-ov/-management-admin-trusted-apps-list.png[] + +[discrete] +[[edit-trusted-app]] +=== Edit a trusted application + +You can individually modify each trusted application. You can also change the policies that a trusted application is assigned to. + +To edit a trusted application: + +. Click the actions menu (_..._) on the trusted application you want to edit, then select **Edit trusted application**. +. Modify details as needed. +. Click **Save**. + +[discrete] +[[delete-trusted-app]] +=== Delete a trusted application + +You can delete a trusted application, which removes it entirely from all {elastic-defend} integration policies. + +To delete a trusted application: + +. Click the actions menu (_..._) on the trusted application you want to delete, then select **Delete trusted application**. +. On the dialog that opens, verify that you are removing the correct application, then click **Delete**. A confirmation message is displayed. diff --git a/docs/serverless/endpoint-response-actions/host-isolation-ov.asciidoc b/docs/serverless/endpoint-response-actions/host-isolation-ov.asciidoc new file mode 100644 index 0000000000..151182625a --- /dev/null +++ b/docs/serverless/endpoint-response-actions/host-isolation-ov.asciidoc @@ -0,0 +1,164 @@ +[[security-isolate-host]] += Isolate a host + +// :description: Host isolation allows you to cut off a host's network access until you release it. +// :keywords: serverless, security, defend, how-to, manage + +preview:[] + +Host isolation allows you to isolate hosts from your network, blocking communication with other hosts on your network until you release the host. Isolating a host is useful for responding to malicious activity or preventing potential attacks, as it prevents lateral movement across other hosts. + +Isolated hosts, however, can still send data to {elastic-sec}. You can also create <> for specific IP addresses that isolated hosts are still allowed to communicate with, even when blocked from the rest of your network. + +.Requirements +[NOTE] +==== +* Host isolation requires the Endpoint Protection Complete <>. +* Hosts must have {agent} installed with the {elastic-defend} integration. +* Host isolation is supported for endpoints running Windows, macOS, and these Linux distributions: ++ +** CentOS/RHEL 8 +** Debian 11 +** Ubuntu 18.04, 20.04, and 22.04 +** AWS Linux 2 +* To isolate and release hosts running any operating system, you must have the appropriate user role. +==== + +[role="screenshot"] +image::images/host-isolation-ov/-management-admin-isolated-host.png[Endpoint page highlighting a host that's been isolated] + +You can isolate a host from a detection alert's details flyout, from the Endpoints page, or from the endpoint response console. Once a host is successfully isolated, an `Isolated` status displays next to the `Agent status` field, which you can view on the alert details flyout or Endpoints list table. + +[TIP] +==== +If the request fails, verify that the {agent} and your endpoint are both online before trying again. +==== + +All actions executed on a host are tracked in the host’s response actions history, which you can access from the Endpoints page. Refer to <> for more information. + +[discrete] +[[isolate-a-host]] +== Isolate a host + +.Isolate a host from a detection alert +[%collapsible] +===== +. Open a detection alert: ++ +** From the Alerts table or Timeline: Click **View details** (image:images/icons/expand.svg[View details]). +** From a case with an attached alert: Click **Show alert details** (**>**). +. Click **Take action → Isolate host**. +. Enter a comment describing why you’re isolating the host (optional). +. Click **Confirm**. +===== + +.Isolate a host from an endpoint +[%collapsible] +===== +. Find **Endpoints** in the navigation menu or use the global search field, then either: ++ +** Select the appropriate endpoint in the **Endpoint** column, and click **Take action → Isolate host** in the endpoint details flyout. +** Click the **Actions** menu (_..._) on the appropriate endpoint, then select **Isolate host**. +. Enter a comment describing why you’re isolating the host (optional). +. Click **Confirm**. +===== + +.Isolate a host from the response console +[%collapsible] +===== +[NOTE] +==== +The response console requires the Endpoint Protection Complete <>. +==== + +. Open the response console for the host (select the **Respond** button or actions menu option on the host, endpoint, or alert details view). +. Enter the `isolate` command and an optional comment in the input area, for example: ++ +`isolate --comment "Isolate this host"` +. Press **Return**. +===== + +.Automatically isolate a host using a rule's endpoint response action +[%collapsible] +===== +[NOTE] +==== +The host isolation endpoint response action requires the Endpoint Protection Complete <>. +==== + +[IMPORTANT] +==== +Be aware that automatic host isolation can result in unintended consequences, such as disrupting legitimate user activities or blocking critical business processes. +==== + +. Add an endpoint response action to a new or existing custom query rule. The endpoint response action will run whenever rule conditions are met: ++ +** **New rule**: On the last step of <> creation, go to the **Response Actions** section and select **{elastic-defend}**. +** **Existing rule**: Edit the rule's settings, then go to the **Actions** tab. In the tab, select **{elastic-defend}** under the **Response Actions** section. +. Click the **Response action** field, then select **Isolate**. +. Enter a comment describing why you’re isolating the host (optional). +. To finish adding the response action, click **Create & enable rule** (for a new rule) or **Save changes** (for existing rules). +===== + +After the host is successfully isolated, an **Isolated** status is added to the endpoint. Active end users receive a notification that the computer has been isolated from the network: + +[role="screenshot"] +image::images/host-isolation-ov/-management-admin-host-isolated-notif.png[Host isolated notification message] + +[discrete] +[[release-a-host]] +== Release a host + +.Release a host from a detection alert +[%collapsible] +===== +. Open a detection alert: ++ +** From the Alerts table or Timeline: Click **View details** (image:images/icons/expand.svg[View details]). +** From a case with an attached alert: Click **Show alert details** (**>**). +. From the alert details flyout, click **Take action → Release host**. +. Enter a comment describing why you're releasing the host (optional). +. Click **Confirm**. +===== + +.Release a host from an endpoint +[%collapsible] +===== +. Find **Endpoints** in the navigation menu or use the global search field, then either: ++ +** Select the appropriate endpoint in the **Endpoint** column, and click **Take action → Release host** in the endpoint details flyout. +** Click the **Actions** menu (_..._) on the appropriate endpoint, then select **Release host**. +. Enter a comment describing why you're releasing the host (optional). +. Click **Confirm**. +===== + +.Release a host from the response console +[%collapsible] +===== +[NOTE] +==== +The response console requires the Endpoint Protection Complete <>. +==== + +. Open the response console for the host (select the **Respond** button or actions menu option on the host, endpoint, or alert details view). +. Enter the `release` command and an optional comment in the input area, for example: ++ +`release --comment "Release this host"` +. Press **Return**. +===== + +After the host is successfully released, the **Isolated** status is removed from the endpoint. Active end users receive a notification that the computer has been reconnected to the network: + +[role="screenshot"] +image::images/host-isolation-ov/-management-admin-host-released-notif.png[Host released notification message] + +[discrete] +[[view-host-isolation-details]] +== View host isolation history + +To confirm if a host has been successfully isolated or released, check the response actions history, which logs the response actions performed on a host. + +Go to the **Endpoints** page, click an endpoint's name, then click the **Response action history** tab. You can filter the information displayed in this view. Refer to <> for more details. + +[role="screenshot"] +image::images/host-isolation-ov/-management-admin-response-actions-history-endpoint-details.png[Response actions history page UI] diff --git a/docs/serverless/endpoint-response-actions/response-actions-config.asciidoc b/docs/serverless/endpoint-response-actions/response-actions-config.asciidoc new file mode 100644 index 0000000000..bd521a744c --- /dev/null +++ b/docs/serverless/endpoint-response-actions/response-actions-config.asciidoc @@ -0,0 +1,165 @@ +[[security-response-actions-config]] += Configure third-party response actions + +// :description: Configure {elastic-sec} to perform response actions on hosts protected by third-party systems. +// :keywords: serverless, security, how-to, configure + +preview:[] + +preview::[] + +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 <> to learn which response actions are supported for each system. + +.Prerequisites +[NOTE] +==== +* <>: Endpoint Protection Complete +* <>: **SOC manager** or **Endpoint operations analyst** +* Endpoints must have actively running third-party agents installed. +==== + +Select a tab below for your endpoint security system: + +++++ +
+
+ + +
+
+++++ +//// +/* 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: + +. **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. +*** To isolate and release hosts, the API client must have `Read` access for Alerts, and `Read` and `Write` access for Hosts. +** 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. +** The base URL varies depending on your CrowdStrike account type: +*** US-1: `https://api.crowdstrike.com` +*** US-2: `https://api.us-2.crowdstrike.com` +*** EU-1: `https://api.eu-1.crowdstrike.com` +*** US-GOV-1: `https://api.laggar.gcw.crowdstrike.com` +. **Install the CrowdStrike integration and {agent}.** Elastic's {integrations-docs}/crowdstrike[CrowdStrike integration] collects and ingests logs into {elastic-sec}. ++ +.. Find **Integrations** in the navigation menu or use the global search field, search for and select **CrowdStrike**, then select **Add CrowdStrike**. +.. Configure the integration with an **Integration name** and optional **Description**. +.. 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. +.. Select the **Falcon Alerts** and **Hosts** sub-options under **Collect CrowdStrike logs via API**. +.. 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 {fleet-guide}/agent-policy.html[{agent} policies]. +.. Click **Save and continue**. +.. Select **Add {agent} to your hosts** and continue with the <> 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}. +. **Create a CrowdStrike connector.** Elastic's {kibana-ref}/crowdstrike-action-type.html[CrowdStrike connector] enables {elastic-sec} to perform actions on CrowdStrike-enrolled hosts. ++ +[IMPORTANT] +==== +Do not create more than one CrowdStrike connector. +==== ++ +.. Find **Connectors** in the navigation menu or use the global search field, then select **Create connector**. +.. Select the **CrowdStrike** connector. +.. 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. +.. Click **Save**. +. **Create and enable detection rules to generate {elastic-sec} alerts.** (Optional) Create <> to generate {elastic-sec} alerts based on CrowdStrike events and data. The {integrations-docs}/crowdstrike[CrowdStrike integration docs] 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. + +++++ +
+ +
+++++ diff --git a/docs/serverless/endpoint-response-actions/response-actions-history.asciidoc b/docs/serverless/endpoint-response-actions/response-actions-history.asciidoc new file mode 100644 index 0000000000..6966293814 --- /dev/null +++ b/docs/serverless/endpoint-response-actions/response-actions-history.asciidoc @@ -0,0 +1,41 @@ +[[security-response-actions-history]] += Response actions history + +// :description: The response actions history log keeps a record of actions taken on endpoints. +// :keywords: serverless, security, defend, reference, manage + +preview:[] + +{elastic-sec} keeps a log of the <> performed on endpoints, such as isolating a host or terminating a process. The log displays when each command was performed, the host on which the action was performed, the user who requested the action, any comments added to the action, and the action's current status. + +.Requirement +[NOTE] +==== +You must have the appropriate user role to use this feature. + +// Placeholder statement until we know which specific roles are required. Classic statement below for reference. + +// You must have the **Response Actions History** privilege to access this feature. +==== + +To access the response actions history for all endpoints, find **Response actions history** in the navigation menu or use the global search field. You can also access the response actions history for an individual endpoint from these areas: + +* **Endpoints** page: Click an endpoint's name to open the details flyout, then click the **Response actions history** tab. +* **Response console** page: Click the **Response actions history** button. + +All of these contexts contain the same information and features. The following image shows the **Response actions history** page for all endpoints: + +[role="screenshot"] +image::images/response-actions-history/-management-admin-response-actions-history-page.png[Response actions history page UI] + +To filter and expand the information in the response actions history: + +* Enter a user name or comma-separated list of user names in the search field to display actions requested by those users. +* Use the various drop-down menus to filter the actions shown: ++ +** **Hosts**: Show actions performed on specific endpoints. (This menu is only available on the **Response actions history** page for all endpoints.) +** **Actions**: Show specific actions types. +** **Statuses**: Show actions with a specific status. +** **Types**: Show actions based on the endpoint protection agent type ({elastic-defend} or a third-party agent), and how the action was triggered (manually by a user or automatically by a detection rule). +* Use the date and time picker to display actions within a specific time range. +* Click the expand arrow on the right to display more details about an action. From 39aeb54ae88f1df46b8eac60ba942f52d8a3f8d1 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" Date: Mon, 11 Nov 2024 21:33:50 +0000 Subject: [PATCH 2/2] Delete docs/serverless directory and its contents --- docs/serverless/edr-manage/blocklist.asciidoc | 96 ---------- .../edr-manage/event-filters.asciidoc | 119 ------------- .../host-isolation-exceptions.asciidoc | 78 --------- .../edr-manage/trusted-apps-ov.asciidoc | 103 ----------- .../host-isolation-ov.asciidoc | 164 ----------------- .../response-actions-config.asciidoc | 165 ------------------ .../response-actions-history.asciidoc | 41 ----- 7 files changed, 766 deletions(-) delete mode 100644 docs/serverless/edr-manage/blocklist.asciidoc delete mode 100644 docs/serverless/edr-manage/event-filters.asciidoc delete mode 100644 docs/serverless/edr-manage/host-isolation-exceptions.asciidoc delete mode 100644 docs/serverless/edr-manage/trusted-apps-ov.asciidoc delete mode 100644 docs/serverless/endpoint-response-actions/host-isolation-ov.asciidoc delete mode 100644 docs/serverless/endpoint-response-actions/response-actions-config.asciidoc delete mode 100644 docs/serverless/endpoint-response-actions/response-actions-history.asciidoc diff --git a/docs/serverless/edr-manage/blocklist.asciidoc b/docs/serverless/edr-manage/blocklist.asciidoc deleted file mode 100644 index 668cf8b9ba..0000000000 --- a/docs/serverless/edr-manage/blocklist.asciidoc +++ /dev/null @@ -1,96 +0,0 @@ -[[security-blocklist]] -= Blocklist - -// :keywords: serverless, security, how-to - -preview:[] - -The blocklist allows you to prevent specified applications from running on hosts, extending the list of processes that {elastic-defend} considers malicious. This helps ensure that known malicious processes aren't accidentally executed by end users. - -The blocklist is not intended to broadly block benign applications for non-security reasons; only use it to block potentially harmful applications. To compare the blocklist with other endpoint artifacts, refer to <>. - -.Requirements -[NOTE] -==== -* In addition to configuring specific entries on the **Blocklist** page, you must also ensure that the blocklist is enabled on the {elastic-defend} integration policy in the <>. This setting is enabled by default. -* You must have the appropriate user role to use this feature. - -// Placeholder statement until we know which specific roles are required. Classic statement below for reference. - -// * You must have the **Blocklist** privilege to access this feature. -==== - -By default, a blocklist entry is recognized globally across all hosts running {elastic-defend}. You can also assign a blocklist entry to specific {elastic-defend} integration policies, which blocks the process only on hosts assigned to that policy. - -. Find **Blocklist** in the navigation menu or use the global search field. -. Click **Add blocklist entry**. The **Add blocklist** flyout appears. -. Fill in these fields in the **Details** section: -+ -.. `Name`: Enter a name to identify the application in the blocklist. -.. `Description`: Enter a description to provide more information on the blocklist entry (optional). -. In the **Conditions** section, enter the following information about the application you want to block: -+ -.. `Select operating system`: Select the appropriate operating system from the drop-down. -.. `Field`: Select a field to identify the application being blocked: -+ -*** `Hash`: The MD5, SHA-1, or SHA-256 hash value of the application's executable. -*** `Path`: The full file path of the application's executable. -*** `Signature`: (Windows only) The name of the application's digital signer. -+ -[TIP] -==== -To find the signer's name for an application, go to **Discover** and query the process name of the application's executable (for example, `process.name : "mctray.exe"` for a McAfee security binary). Then, search the results for the `process.code_signature.subject_name` field, which contains the signer's name (for example, `McAfee, Inc.`). -==== -.. `Operator`: For hash and path conditions, the operator is `is one of` and can't be modified. For signature conditions, choose `is one of` to enter multiple values or `is` for one value. -.. `Value`: Enter the hash value, file path, or signer name. To enter multiple values (such as a list of known malicious hash values), you can enter each value individually or paste a comma-delimited list, then press **Return**. -+ -[NOTE] -==== -Hash values must be valid to add them to the blocklist. -==== -. Select an option in the **Assignment** section to assign the blocklist entry to a specific integration policy: -+ -** `Global`: Assign the blocklist entry to all {elastic-defend} integration policies. -** `Per Policy`: Assign the blocklist entry to one or more specific {elastic-defend} integration policies. Select each policy where you want the blocklist entry to apply. -+ -[NOTE] -==== -You can also select the `Per Policy` option without immediately assigning a policy to the blocklist entry. For example, you could do this to create and review your blocklist configurations before putting them into action with a policy. -==== -. Click **Add blocklist**. The new entry is added to the **Blocklist** page. -. When you're done adding entries to the blocklist, ensure that the blocklist is enabled for the {elastic-defend} integration policies that you just assigned: -+ -.. Go to the **Policies** page, then click on an integration policy. -.. On the **Policy settings** tab, ensure that the **Malware protections** and **Blocklist** toggles are switched on. Both settings are enabled by default. - -[discrete] -[[manage-blocklist]] -== View and manage the blocklist - -The **Blocklist** page displays all the blocklist entries that have been added to the {security-app}. To refine the list, use the search bar to search by name, description, or field value. - -[role="screenshot"] -image::images/blocklist/-management-admin-blocklist.png[] - -[discrete] -[[edit-blocklist-entry]] -=== Edit a blocklist entry - -You can individually modify each blocklist entry. You can also change the policies that a blocklist entry is assigned to. - -To edit a blocklist entry: - -. Click the actions menu (image:images/icons/boxesHorizontal.svg[Actions menu icon]) for the blocklist entry you want to edit, then select **Edit blocklist**. -. Modify details as needed. -. Click **Save**. - -[discrete] -[[delete-blocklist-entry]] -=== Delete a blocklist entry - -You can delete a blocklist entry, which removes it entirely from all {elastic-defend} policies. This allows end users to access the application that was previously blocked. - -To delete a blocklist entry: - -. Click the actions menu (image:images/icons/boxesHorizontal.svg[Actions menu icon]) for the blocklist entry you want to delete, then select **Delete blocklist**. -. On the dialog that opens, verify that you are removing the correct blocklist entry, then click **Delete**. A confirmation message displays. diff --git a/docs/serverless/edr-manage/event-filters.asciidoc b/docs/serverless/edr-manage/event-filters.asciidoc deleted file mode 100644 index f2154ae32c..0000000000 --- a/docs/serverless/edr-manage/event-filters.asciidoc +++ /dev/null @@ -1,119 +0,0 @@ -[[security-event-filters]] -= Event filters - -// :keywords: serverless, security, how-to - -preview:[] - -Event filters allow you to filter out endpoint events that you don't want stored in {es} — for example, high-volume events. By creating event filters, you can optimize your storage in {es}. - -Event filters do not lower CPU usage on hosts; {elastic-endpoint} still monitors events to detect and prevent possible threats, but without writing event data to {es}. To compare event filters with other endpoint artifacts, refer to <>. - -.Requirements -[NOTE] -==== -You must have the appropriate user role to use this feature. - -// Placeholder statement until we know which specific roles are required. Classic statement below for reference. - -// You must have the **Event Filters** privilege to access this feature. -==== - -[IMPORTANT] -==== -Since an event filter blocks an event from streaming to {es}, be conscious of event filter conditions you set and any existing rule conditions. If there is too much overlap, the rule may run less frequently than specified and, therefore, will not trigger the corresponding alert for that rule. This is the expected behavior of event filters. -==== - -By default, event filters are recognized globally across all hosts running {elastic-defend}. You can also assign an event filter to a specific {elastic-defend} integration policy, which would filter endpoint events from the hosts assigned to that policy. - -Create event filters from the Hosts page or the Event filters page. - -. Do one of the following: -+ -** To create an event filter from the Hosts page: -+ -... Select the **Events** tab to view the Events table. -... Find the event to filter, click the **More actions** menu (image:images/icons/boxesHorizontal.svg[More actions menu icon]), then select **Add Endpoint event filter**. -+ -[TIP] -==== -Since you can only create filters for endpoint events, be sure to filter the Events table to display events generated by the {elastic-endpoint}. -For example, in the KQL search bar, enter the following query to find endpoint network events: `event.dataset : endpoint.events.network`. -==== -** To create an event filter from the Event filters page: -+ -... Click **Add event filter**, which opens a flyout. -+ -[role="screenshot"] -image::images/event-filters/-management-admin-event-filter.png[] -. Fill in these fields in the **Details** section: -+ -.. `Name`: Enter a name for the event filter. -.. `Description`: Enter a filter description (optional). -. In the **Conditions** section, depending which page you're using to create the filter, either modify the pre-populated conditions or add new conditions to define how {elastic-sec} will filter events. Use these settings: -+ -.. `Select operating system`: Select the appropriate operating system. -.. Select which kind of event filter you'd like to create: -+ -*** `Events`: Create a generic event filter that can match any event type. All matching events are excluded. -*** `Process Descendants`: Specify a process, and suppress the activity of its descendant processes. Events from the matched process will be ingested, but events from its descendant processes will be excluded. -+ -This option adds the condition `event.category is process` to narrow the filter to process-type events. You can add more conditions to identify the process whose descendants you want to exclude. -.. `Field`: Select a field to identify the event being filtered. -.. `Operator`: Select an operator to define the condition. Available options are: -+ -*** `is` -*** `is not` -*** `is one of` -*** `is not one of` -*** `matches` | `does not match`: Allows you to use wildcards in `Value`, such as `C:\path*\app.exe`. Available wildcards are `?` (match one character) and `*` (match zero or more characters). -+ -[IMPORTANT] -==== -Using wildcards in file paths can impact performance. To create a more efficient event filter using wildcards, use multiple conditions and make them as specific as possible. For example, adding conditions using `process.name` or `file.name` can help limit the scope of wildcard matching. -==== -.. `Value`: Enter the value associated with the `Field`. To enter multiple values (when using `is one of` or `is not one of`), enter each value, then press **Return**. -. To define multiple conditions, click the `AND` button and configure a new condition. You can also add nested conditions with the `Add nested condition` button. For example, the event filter pictured above excludes events whose `event.category` field is `network`, and whose `process.executable` field is as specified. -. Select an option in the **Assignment** section to assign the event filter to a specific integration policy: -+ -** `Global`: Assign the event filter to all integration policies for {elastic-defend}. -** `Per Policy`: Assign the event filter to one or more specific {elastic-defend} integration policies. Select each policy in which you want the events to be filtered. -+ -[NOTE] -==== -You can also select the `Per Policy` option without immediately assigning a policy to the event filter. For example, you could do this to create and review your event filter configurations before putting them into action with a policy. -==== -. Add a comment if you want to provide more information about the event filter (optional). -. Click **Add event filter**. The new filter is added to the **Event filters** list. - -[discrete] -[[manage-event-filters]] -== View and manage event filters - -The **Event filters** page (**Assets** → **Event filters**) displays all the event filters that have been added to the {security-app}. To refine the list, use the search bar to search by filter name, description, comments, or field value. - -[role="screenshot"] -image::images/event-filters/-management-admin-event-filters-list.png[] - -[discrete] -[[edit-event-filter]] -=== Edit an event filter - -You can individually modify each event filter. You can also change the policies that an event filter is assigned to. - -To edit an event filter: - -. Click the actions menu (image:images/icons/boxesHorizontal.svg[Actions menu icon]) for the event filter you want to edit, then select **Edit event filter**. -. Modify details or conditions as needed. -. Click **Save**. - -[discrete] -[[delete-event-filter]] -=== Delete an event filter - -You can delete an event filter, which removes it entirely from all {elastic-defend} integration policies. - -To delete an event filter: - -. Click the actions menu (image:images/icons/boxesHorizontal.svg[Actions menu icon]) on the event filter you want to delete, then select **Delete event filter**. -. On the dialog that opens, verify that you are removing the correct event filter, then click **Delete**. A confirmation message is displayed. diff --git a/docs/serverless/edr-manage/host-isolation-exceptions.asciidoc b/docs/serverless/edr-manage/host-isolation-exceptions.asciidoc deleted file mode 100644 index 1a4a274c37..0000000000 --- a/docs/serverless/edr-manage/host-isolation-exceptions.asciidoc +++ /dev/null @@ -1,78 +0,0 @@ -[[security-host-isolation-exceptions]] -= Host isolation exceptions - -// :keywords: serverless, security, how-to - -preview:[] - -You can configure host isolation exceptions for specific IP addresses that <> are still allowed to communicate with, even when blocked from the rest of your network. Isolated hosts can still send data to {elastic-sec}, so you don't need to set up host isolation exceptions for them. - -Host isolation exceptions support IPv4 addresses, with optional classless inter-domain routing (CIDR) notation. - -.Requirements -[NOTE] -==== -You must have the appropriate user role to use this feature. - -// Placeholder statement until we know which specific roles are required. Classic statement below for reference. - -// You must have the **Host Isolation Exceptions** privilege to access this feature. -==== - -[IMPORTANT] -==== -* Each host isolation exception IP address should be a highly trusted and secure location since you're allowing it to communicate with hosts that have been isolated to prevent a potential threat from spreading. -* If your hosts depend on VPNs for network communication, you should also set up host isolation exceptions for those VPN servers' IP addresses. -==== - -Host isolation requires the Endpoint Protection Complete <>. By default, a host isolation exception is recognized globally across all hosts running {elastic-defend}. You can also assign a host isolation exception to a specific {elastic-defend} integration policy, affecting only the hosts assigned to that policy. - -. Find **Host isolation exceptions** in the navigation menu or use the global search field. -. Click **Add Host isolation exception**. -. Fill in these fields in the **Add Host isolation exception** flyout: -+ -.. `Name your host isolation exceptions`: Enter a name to identify the host isolation exception. -.. `Description`: Enter a description to provide more information on the host isolation exception (optional). -.. `Enter IP Address`: Enter the IP address for which you want to allow communication with an isolated host. This must be an IPv4 address, with optional CIDR notation (for example, `0.0.0.0` or `1.0.0.0/24`, respectively). -. Select an option in the **Assignment** section to assign the host isolation exception to a specific integration policy: -+ -** `Global`: Assign the host isolation exception to all integration policies for {elastic-defend}. -** `Per Policy`: Assign the host isolation exception to one or more specific {elastic-defend} integration policies. Select each policy where you want the host isolation exception to apply. -+ -[NOTE] -==== -You can also select the `Per Policy` option without immediately assigning a policy to the host isolation exception. For example, you could do this to create and review your host isolation exception configurations before putting them into action with a policy. -==== -. Click **Add Host isolation exception**. The new exception is added to the **Host isolation exceptions** list. - -[discrete] -[[manage-host-isolation-exceptions]] -== View and manage host isolation exceptions - -The **Host isolation exceptions** page displays all the host isolation exceptions that have been configured for {elastic-sec}. To refine the list, use the search bar to search by name, description, or IP address. - -[role="screenshot"] -image::images/host-isolation-exceptions/-management-admin-host-isolation-exceptions-ui.png[List of host isolation exceptions] - -[discrete] -[[edit-host-isolation-exception]] -=== Edit a host isolation exception - -You can individually modify each host isolation exception and change the policies that a host isolation exception is assigned to. - -To edit a host isolation exception: - -. Click the actions menu (image:images/icons/boxesHorizontal.svg[Actions menu icon]) for the exception you want to edit, then select **Edit Exception**. -. Modify details as needed. -. Click **Save**. The newly modified exception appears at the top of the list. - -[discrete] -[[delete-host-isolation-exception]] -=== Delete a host isolation exception - -You can delete a host isolation exception, which removes it entirely from all {elastic-defend} integration policies. - -To delete a host isolation exception: - -. Click the actions menu (image:images/icons/boxesHorizontal.svg[Actions menu icon]) on the exception you want to delete, then select **Delete Exception**. -. On the dialog that opens, verify that you are removing the correct host isolation exception, then click **Delete**. A confirmation message is displayed. diff --git a/docs/serverless/edr-manage/trusted-apps-ov.asciidoc b/docs/serverless/edr-manage/trusted-apps-ov.asciidoc deleted file mode 100644 index 3fd5307aff..0000000000 --- a/docs/serverless/edr-manage/trusted-apps-ov.asciidoc +++ /dev/null @@ -1,103 +0,0 @@ -[[security-trusted-applications]] -= Trusted applications - -// :keywords: serverless, security, how-to - -preview:[] - -[NOTE] -==== -If you use {elastic-defend} along with other antivirus (AV) software, you might need to configure the other system to trust {elastic-endpoint}. Refer to <> for more information. -==== - -You can add Windows, macOS, and Linux applications that should be trusted, such as other antivirus or endpoint security applications. Trusted applications are designed to help mitigate performance issues and incompatibilities with other endpoint software installed on your hosts. Trusted applications apply only to hosts running the {elastic-defend} integration. - -.Requirements -[NOTE] -==== -You must have the appropriate user role to use this feature. - -// Placeholder statement until we know which specific roles are required. Classic statement below for reference. - -// You must have the **Trusted Applications** privilege to access this feature. -==== - -Trusted applications create blindspots for {elastic-defend}, because the applications are no longer monitored for threats. One avenue attackers use to exploit these blindspots is by DLL (Dynamic Link Library) side-loading, where they leverage processes signed by trusted vendors — such as antivirus software — to execute their malicious DLLs. Such activity appears to originate from the trusted application's process. - -Trusted applications might still generate alerts in some cases, such as if the application's process events indicate malicious behavior. To reduce false positive alerts, add an <>, which prevents {elastic-defend} from generating alerts. To compare trusted applications with other endpoint artifacts, refer to <>. - -Additionally, trusted applications still generate process events for visualizations and other internal use by the {stack}. To prevent process events from being written to {es}, use an <> to filter out the specific events that you don't want stored in {es}, but be aware that features that depend on these process events may not function correctly. - -By default, a trusted application is recognized globally across all hosts running {elastic-defend}. You can also assign a trusted application to a specific {elastic-defend} integration policy, enabling the application to be trusted by only the hosts assigned to that policy. - -To add a trusted application: - -. Find **Trusted applications** in the navigation menu or use the global search field. -. Click **Add trusted application**. -. Fill in the following fields in the **Add trusted application** flyout: -+ -** `Name your trusted application`: Enter a name for the trusted application. -** `Description`(Optional): Enter a description for the trusted application. -** `Select operating system`: Select the appropriate operating system from the drop-down. -** `Field`: Select a field to identify the trusted application: -+ -*** `Hash`: The MD5, SHA-1, or SHA-256 hash value of the application's executable. -*** `Path`: The full file path of the application's executable. -*** `Signature`: (Windows only) The name of the application's digital signer. -+ -[TIP] -==== -To find the signer's name for an application, go to **Discover** and query the process name of the application's executable (for example, `process.name : "mctray.exe"` for a McAfee security binary). Then, search the results for the `process.code_signature.subject_name` field, which contains the signer's name (for example, `McAfee, Inc.`). -==== -** `Operator`: Select an operator to define the condition: -+ -*** `is`: Must be _exactly_ equal to `Value`; wildcards are not supported. This operation is required for the `Hash` and `Signature` field types. -*** `matches`: Can include wildcards in `Value`, such as `C:\path*\app.exe`. This operator is only available for the `Path` field type. Available wildcards are `?` (match one character) and `*` (match zero or more characters). -** `Value`: Enter the hash value, file path, or signer name. To add an additional value, click **AND**. -+ -[NOTE] -==== -You can only add a single field type value per trusted application. For example, if you try to add two `Path` values, you'll get an error message. Also, an application's hash value must be valid to add it as a trusted application. In addition, to minimize visibility gaps in the {security-app}, be as specific as possible in your entries. For example, combine `Signature` information with a known `Path`. -==== -. Select an option in the **Assignment** section to assign the trusted application to a specific integration policy: -+ -** `Global`: Assign the trusted application to all integration policies for {elastic-defend}. -** `Per Policy`: Assign the trusted application to one or more specific {elastic-defend} integration policies. Select each policy in which you want the application to be trusted. -+ -[NOTE] -==== -You can also select the `Per Policy` option without immediately assigning a policy to the trusted application. For example, you could do this to create and review your trusted application configurations before putting them into action with a policy. -==== -. Click **Add trusted application**. The application is added to the **Trusted applications** list. - -[discrete] -[[trusted-apps-list]] -== View and manage trusted applications - -The **Trusted applications** page (**Assets** → **Trusted applications**) displays all the trusted applications that have been added to the {security-app}. To refine the list, use the search bar to search by name, description, or field value. - -[role="screenshot"] -image::images/trusted-apps-ov/-management-admin-trusted-apps-list.png[] - -[discrete] -[[edit-trusted-app]] -=== Edit a trusted application - -You can individually modify each trusted application. You can also change the policies that a trusted application is assigned to. - -To edit a trusted application: - -. Click the actions menu (_..._) on the trusted application you want to edit, then select **Edit trusted application**. -. Modify details as needed. -. Click **Save**. - -[discrete] -[[delete-trusted-app]] -=== Delete a trusted application - -You can delete a trusted application, which removes it entirely from all {elastic-defend} integration policies. - -To delete a trusted application: - -. Click the actions menu (_..._) on the trusted application you want to delete, then select **Delete trusted application**. -. On the dialog that opens, verify that you are removing the correct application, then click **Delete**. A confirmation message is displayed. diff --git a/docs/serverless/endpoint-response-actions/host-isolation-ov.asciidoc b/docs/serverless/endpoint-response-actions/host-isolation-ov.asciidoc deleted file mode 100644 index 151182625a..0000000000 --- a/docs/serverless/endpoint-response-actions/host-isolation-ov.asciidoc +++ /dev/null @@ -1,164 +0,0 @@ -[[security-isolate-host]] -= Isolate a host - -// :description: Host isolation allows you to cut off a host's network access until you release it. -// :keywords: serverless, security, defend, how-to, manage - -preview:[] - -Host isolation allows you to isolate hosts from your network, blocking communication with other hosts on your network until you release the host. Isolating a host is useful for responding to malicious activity or preventing potential attacks, as it prevents lateral movement across other hosts. - -Isolated hosts, however, can still send data to {elastic-sec}. You can also create <> for specific IP addresses that isolated hosts are still allowed to communicate with, even when blocked from the rest of your network. - -.Requirements -[NOTE] -==== -* Host isolation requires the Endpoint Protection Complete <>. -* Hosts must have {agent} installed with the {elastic-defend} integration. -* Host isolation is supported for endpoints running Windows, macOS, and these Linux distributions: -+ -** CentOS/RHEL 8 -** Debian 11 -** Ubuntu 18.04, 20.04, and 22.04 -** AWS Linux 2 -* To isolate and release hosts running any operating system, you must have the appropriate user role. -==== - -[role="screenshot"] -image::images/host-isolation-ov/-management-admin-isolated-host.png[Endpoint page highlighting a host that's been isolated] - -You can isolate a host from a detection alert's details flyout, from the Endpoints page, or from the endpoint response console. Once a host is successfully isolated, an `Isolated` status displays next to the `Agent status` field, which you can view on the alert details flyout or Endpoints list table. - -[TIP] -==== -If the request fails, verify that the {agent} and your endpoint are both online before trying again. -==== - -All actions executed on a host are tracked in the host’s response actions history, which you can access from the Endpoints page. Refer to <> for more information. - -[discrete] -[[isolate-a-host]] -== Isolate a host - -.Isolate a host from a detection alert -[%collapsible] -===== -. Open a detection alert: -+ -** From the Alerts table or Timeline: Click **View details** (image:images/icons/expand.svg[View details]). -** From a case with an attached alert: Click **Show alert details** (**>**). -. Click **Take action → Isolate host**. -. Enter a comment describing why you’re isolating the host (optional). -. Click **Confirm**. -===== - -.Isolate a host from an endpoint -[%collapsible] -===== -. Find **Endpoints** in the navigation menu or use the global search field, then either: -+ -** Select the appropriate endpoint in the **Endpoint** column, and click **Take action → Isolate host** in the endpoint details flyout. -** Click the **Actions** menu (_..._) on the appropriate endpoint, then select **Isolate host**. -. Enter a comment describing why you’re isolating the host (optional). -. Click **Confirm**. -===== - -.Isolate a host from the response console -[%collapsible] -===== -[NOTE] -==== -The response console requires the Endpoint Protection Complete <>. -==== - -. Open the response console for the host (select the **Respond** button or actions menu option on the host, endpoint, or alert details view). -. Enter the `isolate` command and an optional comment in the input area, for example: -+ -`isolate --comment "Isolate this host"` -. Press **Return**. -===== - -.Automatically isolate a host using a rule's endpoint response action -[%collapsible] -===== -[NOTE] -==== -The host isolation endpoint response action requires the Endpoint Protection Complete <>. -==== - -[IMPORTANT] -==== -Be aware that automatic host isolation can result in unintended consequences, such as disrupting legitimate user activities or blocking critical business processes. -==== - -. Add an endpoint response action to a new or existing custom query rule. The endpoint response action will run whenever rule conditions are met: -+ -** **New rule**: On the last step of <> creation, go to the **Response Actions** section and select **{elastic-defend}**. -** **Existing rule**: Edit the rule's settings, then go to the **Actions** tab. In the tab, select **{elastic-defend}** under the **Response Actions** section. -. Click the **Response action** field, then select **Isolate**. -. Enter a comment describing why you’re isolating the host (optional). -. To finish adding the response action, click **Create & enable rule** (for a new rule) or **Save changes** (for existing rules). -===== - -After the host is successfully isolated, an **Isolated** status is added to the endpoint. Active end users receive a notification that the computer has been isolated from the network: - -[role="screenshot"] -image::images/host-isolation-ov/-management-admin-host-isolated-notif.png[Host isolated notification message] - -[discrete] -[[release-a-host]] -== Release a host - -.Release a host from a detection alert -[%collapsible] -===== -. Open a detection alert: -+ -** From the Alerts table or Timeline: Click **View details** (image:images/icons/expand.svg[View details]). -** From a case with an attached alert: Click **Show alert details** (**>**). -. From the alert details flyout, click **Take action → Release host**. -. Enter a comment describing why you're releasing the host (optional). -. Click **Confirm**. -===== - -.Release a host from an endpoint -[%collapsible] -===== -. Find **Endpoints** in the navigation menu or use the global search field, then either: -+ -** Select the appropriate endpoint in the **Endpoint** column, and click **Take action → Release host** in the endpoint details flyout. -** Click the **Actions** menu (_..._) on the appropriate endpoint, then select **Release host**. -. Enter a comment describing why you're releasing the host (optional). -. Click **Confirm**. -===== - -.Release a host from the response console -[%collapsible] -===== -[NOTE] -==== -The response console requires the Endpoint Protection Complete <>. -==== - -. Open the response console for the host (select the **Respond** button or actions menu option on the host, endpoint, or alert details view). -. Enter the `release` command and an optional comment in the input area, for example: -+ -`release --comment "Release this host"` -. Press **Return**. -===== - -After the host is successfully released, the **Isolated** status is removed from the endpoint. Active end users receive a notification that the computer has been reconnected to the network: - -[role="screenshot"] -image::images/host-isolation-ov/-management-admin-host-released-notif.png[Host released notification message] - -[discrete] -[[view-host-isolation-details]] -== View host isolation history - -To confirm if a host has been successfully isolated or released, check the response actions history, which logs the response actions performed on a host. - -Go to the **Endpoints** page, click an endpoint's name, then click the **Response action history** tab. You can filter the information displayed in this view. Refer to <> for more details. - -[role="screenshot"] -image::images/host-isolation-ov/-management-admin-response-actions-history-endpoint-details.png[Response actions history page UI] diff --git a/docs/serverless/endpoint-response-actions/response-actions-config.asciidoc b/docs/serverless/endpoint-response-actions/response-actions-config.asciidoc deleted file mode 100644 index bd521a744c..0000000000 --- a/docs/serverless/endpoint-response-actions/response-actions-config.asciidoc +++ /dev/null @@ -1,165 +0,0 @@ -[[security-response-actions-config]] -= Configure third-party response actions - -// :description: Configure {elastic-sec} to perform response actions on hosts protected by third-party systems. -// :keywords: serverless, security, how-to, configure - -preview:[] - -preview::[] - -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 <> to learn which response actions are supported for each system. - -.Prerequisites -[NOTE] -==== -* <>: Endpoint Protection Complete -* <>: **SOC manager** or **Endpoint operations analyst** -* Endpoints must have actively running third-party agents installed. -==== - -Select a tab below for your endpoint security system: - -++++ -
-
- - -
-
-++++ -//// -/* 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: - -. **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. -*** To isolate and release hosts, the API client must have `Read` access for Alerts, and `Read` and `Write` access for Hosts. -** 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. -** The base URL varies depending on your CrowdStrike account type: -*** US-1: `https://api.crowdstrike.com` -*** US-2: `https://api.us-2.crowdstrike.com` -*** EU-1: `https://api.eu-1.crowdstrike.com` -*** US-GOV-1: `https://api.laggar.gcw.crowdstrike.com` -. **Install the CrowdStrike integration and {agent}.** Elastic's {integrations-docs}/crowdstrike[CrowdStrike integration] collects and ingests logs into {elastic-sec}. -+ -.. Find **Integrations** in the navigation menu or use the global search field, search for and select **CrowdStrike**, then select **Add CrowdStrike**. -.. Configure the integration with an **Integration name** and optional **Description**. -.. 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. -.. Select the **Falcon Alerts** and **Hosts** sub-options under **Collect CrowdStrike logs via API**. -.. 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 {fleet-guide}/agent-policy.html[{agent} policies]. -.. Click **Save and continue**. -.. Select **Add {agent} to your hosts** and continue with the <> 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}. -. **Create a CrowdStrike connector.** Elastic's {kibana-ref}/crowdstrike-action-type.html[CrowdStrike connector] enables {elastic-sec} to perform actions on CrowdStrike-enrolled hosts. -+ -[IMPORTANT] -==== -Do not create more than one CrowdStrike connector. -==== -+ -.. Find **Connectors** in the navigation menu or use the global search field, then select **Create connector**. -.. Select the **CrowdStrike** connector. -.. 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. -.. Click **Save**. -. **Create and enable detection rules to generate {elastic-sec} alerts.** (Optional) Create <> to generate {elastic-sec} alerts based on CrowdStrike events and data. The {integrations-docs}/crowdstrike[CrowdStrike integration docs] 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. - -++++ -
- -
-++++ diff --git a/docs/serverless/endpoint-response-actions/response-actions-history.asciidoc b/docs/serverless/endpoint-response-actions/response-actions-history.asciidoc deleted file mode 100644 index 6966293814..0000000000 --- a/docs/serverless/endpoint-response-actions/response-actions-history.asciidoc +++ /dev/null @@ -1,41 +0,0 @@ -[[security-response-actions-history]] -= Response actions history - -// :description: The response actions history log keeps a record of actions taken on endpoints. -// :keywords: serverless, security, defend, reference, manage - -preview:[] - -{elastic-sec} keeps a log of the <> performed on endpoints, such as isolating a host or terminating a process. The log displays when each command was performed, the host on which the action was performed, the user who requested the action, any comments added to the action, and the action's current status. - -.Requirement -[NOTE] -==== -You must have the appropriate user role to use this feature. - -// Placeholder statement until we know which specific roles are required. Classic statement below for reference. - -// You must have the **Response Actions History** privilege to access this feature. -==== - -To access the response actions history for all endpoints, find **Response actions history** in the navigation menu or use the global search field. You can also access the response actions history for an individual endpoint from these areas: - -* **Endpoints** page: Click an endpoint's name to open the details flyout, then click the **Response actions history** tab. -* **Response console** page: Click the **Response actions history** button. - -All of these contexts contain the same information and features. The following image shows the **Response actions history** page for all endpoints: - -[role="screenshot"] -image::images/response-actions-history/-management-admin-response-actions-history-page.png[Response actions history page UI] - -To filter and expand the information in the response actions history: - -* Enter a user name or comma-separated list of user names in the search field to display actions requested by those users. -* Use the various drop-down menus to filter the actions shown: -+ -** **Hosts**: Show actions performed on specific endpoints. (This menu is only available on the **Response actions history** page for all endpoints.) -** **Actions**: Show specific actions types. -** **Statuses**: Show actions with a specific status. -** **Types**: Show actions based on the endpoint protection agent type ({elastic-defend} or a third-party agent), and how the action was triggered (manually by a user or automatically by a detection rule). -* Use the date and time picker to display actions within a specific time range. -* Click the expand arrow on the right to display more details about an action.