diff --git a/docs/serverless/billing.asciidoc b/docs/serverless/billing.asciidoc index 5d3cb4c08e..5ebe05c4a9 100644 --- a/docs/serverless/billing.asciidoc +++ b/docs/serverless/billing.asciidoc @@ -34,7 +34,7 @@ You pay based on the number of protected endpoints you configure with the {elast Cloud Protection is an _optional_ add-on to Security Analytics that provides value-added protection capabilities for cloud assets. Cloud Protection is available in two tiers of carefully selected features to enable common cloud security operations: * **Cloud Protection Essentials** — Protects your cloud workloads, continuously tracks posture of your cloud assets, and helps you manage risks by detecting configuration issues per CIS benchmarks. -* **Cloud Protection Complete** — Adds response capabilities and configuration drift prevention for Cloud Workloads. +* **Cloud Protection Complete** — Adds response capabilities. Your total cost depends on the number of protected cloud workloads and other billable cloud assets you configure for use with Elastic Cloud Security. @@ -60,8 +60,6 @@ For <>, billing is based on how many Kubernetes nodes (`agen For <>, billing is based on how many cloud assets (`cloud.instance.id` s) you monitor. -For <>, billing is based on how many agents (`agent.id` s) you use. - Logs, events, alerts, and configuration data ingested into your security project are billed using the **Ingest** and **Retention** pricing described above. For more details about {elastic-sec} serverless project rates and billable assets, refer to Cloud Protection in the https://cloud.elastic.co/cloud-pricing-table?productType=serverless&project=security[Elastic Cloud pricing table]. diff --git a/docs/serverless/cloud-native-security/cloud-native-security-overview.asciidoc b/docs/serverless/cloud-native-security/cloud-native-security-overview.asciidoc index e32b1fb326..46c1c11bd8 100644 --- a/docs/serverless/cloud-native-security/cloud-native-security-overview.asciidoc +++ b/docs/serverless/cloud-native-security/cloud-native-security-overview.asciidoc @@ -34,14 +34,6 @@ Scans your cloud workloads for known vulnerabilities. When it finds a vulnerabil <>. -[discrete] -[[security-cloud-native-security-overview-cloud-workload-protection-for-kubernetes]] -== Cloud Workload Protection for Kubernetes - -Provides cloud-native runtime protections for containerized environments by identifying and (optionally) blocking unexpected system behavior in Kubernetes containers. These capabilities are sometimes referred to as container drift detection and prevention. The solution also captures detailed process and file telemetry from monitored containers, allowing you to set up custom alerts and protection rules. - -<>. - [discrete] [[security-cloud-native-security-overview-cloud-workload-protection-for-vms]] == Cloud Workload Protection for VMs diff --git a/docs/serverless/cloud-native-security/cloud-workload-protection.asciidoc b/docs/serverless/cloud-native-security/cloud-workload-protection.asciidoc index 79fa318a46..dd9ab8b743 100644 --- a/docs/serverless/cloud-native-security/cloud-workload-protection.asciidoc +++ b/docs/serverless/cloud-native-security/cloud-workload-protection.asciidoc @@ -21,5 +21,4 @@ To continue setting up your cloud workload protection, learn more about: * <>: configure {elastic-defend} to protect your hosts. Be sure to select one of the "Cloud workloads" presets if you want to collect session data by default, including process, file, and network telemetry. * <>: examine Linux process data organized in a tree-like structure according to the Linux logical event model, with processes organized by parentage and time of execution. Use it to monitor and investigate session activity, and to understand user and service behavior on your Linux infrastructure. -* <>: Explore an overview of your protected Kubernetes clusters, and drill down into individual sessions within your Kubernetes infrastructure. * <>: Capture the environment variables associated with process events, such as `PATH`, `LD_PRELOAD`, or `USER`. diff --git a/docs/serverless/cloud-native-security/d4c-get-started.asciidoc b/docs/serverless/cloud-native-security/d4c-get-started.asciidoc deleted file mode 100644 index 3b28a2c0b8..0000000000 --- a/docs/serverless/cloud-native-security/d4c-get-started.asciidoc +++ /dev/null @@ -1,91 +0,0 @@ -[[security-d4c-get-started]] -= Get started with CWP - -// :description: Secure your containerized workloads and start detecting threats and vulnerabilities. -// :keywords: security, how-to, get-started, cloud security - - -beta:[] - -This page describes how to set up Cloud Workload Protection (CWP) for Kubernetes. - -.Requirements -[NOTE] -==== -* Kubernetes node operating systems must have Linux kernels 5.10.16 or higher. -==== - -[discrete] -[[security-d4c-get-started-initial-setup]] -== Initial setup - -First, you'll need to deploy Elastic's Defend for Containers integration to the Kubernetes clusters you wish to monitor. - -. Find **Container Workload Security** in the navigation menu or use the global search field. Click **Add D4C Integration**. -. Name the integration. The default name, which you can change, is `cloud_defend-1`. -. Optional — make any desired changes to the integration's policy by adjusting the **Selectors** and **Responses** sections. (For more information, refer to the <>). You can also change these later. -. Under **Where to add this integration**, select an existing or new agent policy. -. Click **Save & Continue**, then **Add {agent} to your hosts**. -. On the {agent} policy page, click **Add agent** to open the Add agent flyout. -. In the flyout, go to step 3 (**Install {agent} on your host**) and select the **Kubernetes** tab. -. Download or copy the manifest (`elastic-agent-managed-kubernetes.yml`). -. Open the manifest using your favorite editor, and uncomment the `#capabilities` section: -+ -[source,console] ----- -#capabilities: -# add: -# - BPF # (since Linux 5.8) allows loading of BPF programs, create most map types, load BTF, iterate programs and maps. -# - PERFMON # (since Linux 5.8) allows attaching of BPF programs used for performance metrics and observability operations. -# - SYS_RESOURCE # Allow use of special resources or raising of resource limits. Used by 'Defend for Containers' to modify 'rlimit_memlock' ----- -. From the directory where you saved the manifest, run the command `kubectl apply -f elastic-agent-managed-kubernetes.yml`. -. Wait for the **Confirm agent enrollment** dialogue to show that data has started flowing from your newly-installed agent, then click **Close**. - -[discrete] -[[d4c-get-started-threat]] -== Get started with threat detection - -One of the <> sends process telemetry events (`fork` and `exec`) to {es}. - -In order to detect threats using this data, you'll need active <>. Elastic has prebuilt detection rules designed for this data. (You can also create your own <>.) - -To install and enable the prebuilt rules: - -. Find **Detection rules (SIEM)** in the navigation menu or use the global search field, then click **Add Elastic rules**. -. Click the **Tags** filter next to the search bar, and search for the `Data Source: Elastic Defend for Containers` tag. -. Select all the displayed rules, then click **Install _x_ selected rule(s)**. -. Return to the **Rules** page. Click the **Tags** filter next to the search bar, and search for the `Data Source: Elastic Defend for Containers` tag. -. Select all the rules with the tag, and then click **Bulk actions → Enable**. - -[discrete] -[[d4c-get-started-drift]] -== Get started with drift detection and prevention - -{elastic-sec} defines container drift as the creation or modification of an executable within a container. Blocking drift restricts the number of attack vectors available to bad actors by prohibiting them from using external tools. - -To enable drift detection, you can use the default D4C policy: - -. Make sure the <> is active. -. Make sure you enabled at least the "Container Workload Protection" rule, by following the steps to install prebuilt rules, above. - -To enable drift prevention, create a new policy: - -. Find **Container Workload Security** in the navigation menu or use the global search field, then select your integration. -. Under **Selectors**, click **Add selector → File Selector**. By default, it selects the operations `createExecutable` and `modifyExecutable`. -. Name the selector, for example: `blockDrift`. -. Scroll down to the **Responses** section and click **Add response → File Response**. -. Under **Match selectors**, add the name of your new selector, for example: `blockDrift`. -. Select the **Alert** and **Block** actions. -. Click **Save integration**. - -[IMPORTANT] -==== -Before you enable blocking, we strongly recommend you observe a production workload that's using the default D4C policy to ensure that the workload does not create or modify executables as part of its normal operation. -==== - -[discrete] -[[d4c-get-started-validation]] -== Policy validation - -To ensure the stability of your production workloads, you should test policy changes before implementing them in production workloads. We also recommend you test policy changes on a simulated environment with workloads similar to production. This approach allows you to test that policy changes prevent undesirable behavior without disrupting your production workloads. diff --git a/docs/serverless/cloud-native-security/d4c-kubernetes-dashboard-dash.asciidoc b/docs/serverless/cloud-native-security/d4c-kubernetes-dashboard-dash.asciidoc deleted file mode 100644 index f883ec0c21..0000000000 --- a/docs/serverless/cloud-native-security/d4c-kubernetes-dashboard-dash.asciidoc +++ /dev/null @@ -1,8 +0,0 @@ -:append: -d4c - -[id="security-kubernetes-dashboard-dash{append}"] -= Kubernetes dashboard - -include::../dashboards/kubernetes-dashboard-dash.asciidoc[tag=content] - -:append!: diff --git a/docs/serverless/cloud-native-security/d4c-overview.asciidoc b/docs/serverless/cloud-native-security/d4c-overview.asciidoc deleted file mode 100644 index fbfe188b13..0000000000 --- a/docs/serverless/cloud-native-security/d4c-overview.asciidoc +++ /dev/null @@ -1,87 +0,0 @@ -[[security-d4c-overview]] -= Container workload protection - -// :description: Identify and block unexpected system behavior in Kubernetes containers. -// :keywords: security, cloud, reference, manage - - -beta:[] - -Elastic Cloud Workload Protection (CWP) for Kubernetes provides cloud-native runtime protections for containerized environments by identifying and optionally blocking unexpected system behavior in Kubernetes containers. - -[discrete] -[[d4c-use-cases]] -== Use cases - -[discrete] -[[security-d4c-overview-threat-detection-and-threat-hunting]] -=== Threat detection & threat hunting - -CWP for Kubernetes sends system events from your containers to {es}. {elastic-sec}'s prebuilt security rules include many designed to detect malicious behavior in container runtimes. These can help you detect events that should never occur in containers, such as reverse shell executions, privilege escalation, container escape attempts, and more. - -[discrete] -[[security-d4c-overview-drift-detection-and-prevention]] -=== Drift detection & prevention - -Cloud-native containers should be immutable, meaning that their file systems should not change during normal operations. By leveraging this principle, security teams can detect unusual system behavior with a high degree of accuracy — without relying on more resource-intensive techniques like memory scanning or attack signature detection. Elastic’s Drift Detection mechanism has a low rate of false positives, so you can deploy it in most environments without worrying about creating excessive alerts. - -[discrete] -[[security-d4c-overview-workload-protection-policies]] -=== Workload protection policies - -CWP for Kubernetes uses a flexible policy language to restrict container workloads to a set of allowlisted capabilities chosen by you. When employed with Drift and Threat Detection, this can provide multiple layers of defense. - -[discrete] -[[security-d4c-overview-support-matrix]] -== Support matrix: - -|=== -| | EKS 1.24-1.27 (AL2022)| GKE 1.24-1.27 (COS) - -| Process event exports -| ✓ -| ✓ - -| Network event exports -| ✓ -| ✓ - -| File event exports -| ✓ -| ✓ - -| File blocking -| ✓ -| ✓ - -| Process blocking -| ✓ -| ✓ - -| Network blocking -| ✗ -| ✗ - -| Drift prevention -| ✓ -| ✓ - -| Mount point awareness -| ✓ -| ✓ -|=== - -[discrete] -[[security-d4c-overview-how-cwp-for-kubernetes-works]] -== How CWP for Kubernetes works - -CWP for Kubernetes uses a lightweight integration, Defend for Containers (D4C). When you set up the D4C integration, it gets deployed by {agent}. Specifically, the {agent} is installed as a DaemonSet on your Kubernetes clusters, where it enables D4C to use eBPF Linux Security Modules (https://docs.kernel.org/bpf/prog_lsm.html[LSM]) and tracepoint probes to record system events. Events are evaluated against LSM hook points, enabling {agent} to evaluate system activity against your policy before allowing it to proceed. - -Your D4C integration policy determines which system behaviors (for example, process execution or file creation or deletion) will result in which actions. _Selectors_ and _responses_ define each policy. Selectors define the conditions which cause the associated responses to run. Responses are associated with one or more selectors, and specify one or more actions (such as `log`, `alert`, or `block`) that will occur when the conditions defined in an associated selector are met. - -The default D4C policy sends data about all running processes to your {es} cluster. This data is used by {elastic-sec}'s prebuilt detection rules to detect malicious behavior in container workloads. - -[IMPORTANT] -==== -To learn more about D4C policies, including how to create your own, refer to the <>. -==== diff --git a/docs/serverless/cloud-native-security/d4c-policy-guide.asciidoc b/docs/serverless/cloud-native-security/d4c-policy-guide.asciidoc deleted file mode 100644 index 54b7ec101e..0000000000 --- a/docs/serverless/cloud-native-security/d4c-policy-guide.asciidoc +++ /dev/null @@ -1,162 +0,0 @@ -[[security-d4c-policy-guide]] -= Container workload protection policies - -// :description: Learn to build policies for cloud workload protection for Kubernetes. -// :keywords: security, cloud, reference, manage, cloud security - - -To unlock the full functionality of the Defend for Containers (D4C) integration, you'll need to understand its policy syntax. This will enable you to construct policies that precisely allow expected container behaviors and prevent unexpected behaviors — thereby hardening your container workloads' security posture. - -D4C integration policies consist of _selectors_ and _responses_. Each policy must contain at least one selector and one response. Currently, the system supports two types of selectors and responses: `file` and `process`. -Selectors define which system operations to match and can include multiple conditions (grouped using a logical `AND`) to precisely select events. Responses define which actions to take when a system operation matches the conditions specified in an associated selector. - -The default policy described on this page provides an example that's useful for understanding D4C policies in general. Following the description, you'll find a comprehensive glossary of selector conditions, response fields, and actions. - -[discrete] -[[d4c-default-policies]] -== Default policies: - -The default D4C integration policy includes two selector-response pairs. It is designed to implement core container workload protection capabilities: - -* **Threat Detection:** The first selector-response pair is designed to stream process telemetry data to your {es} cluster so {elastic-sec} can evaluate it to detect threats. Both the selector and response are named `allProcesses`. The selector selects all fork and exec events. The associated response specifies that selected events should be logged. -* **Drift Detection & Prevention:** The second selector-response pair is designed to create alerts when container drift is detected. Both the selector and response are named `executableChanges`. The selector selects all `createExecutable` and `modifyExecutable` events. The associated response specifies that the selected events should create alerts, which will be sent to your {es} cluster. You can modify the response to block drift operations by setting it to block. - -[role="screenshot"] -image::images/d4c-policy-guide/-cloud-native-security-d4c-policy-editor.png[The defend for containers policy editor with the default policies] - -[discrete] -[[d4c-selectors-glossary]] -== Selectors - -A selector requires a name and at least one operation. It will select all events of the specified operation types, unless you also include _conditions_ to narrow down the selection. Some conditions are available for both `file` and `process` selectors, while others only available for one type of selector. - -[discrete] -[[security-d4c-policy-guide-common-conditions]] -=== Common conditions - -These conditions are available for both `file` and `process` selectors. - -// [cols="1,1", options="header"] - -|=== -| Name| Description - -| containerImageFullName -| A list of full container image names to match on. For example: `docker.io/nginx`. - -| containerImageName -| A list of container image names to match on. For example: `nginx`. - -| containerImageTag -| A list of container image tags to match on. For example: `latest`. - -| kubernetesClusterId -| A list of Kubernetes cluster IDs to match on. For consistency with KSPM, the `kube-system` namespace's UID is used as a cluster ID. - -| kubernetesClusterName -| A list of Kubernetes cluster names to match on. - -| kubernetesNamespace -| A list of Kubernetes namespaces to match on. - -| kubernetesPodName -| A list of Kubernetes pod names to match on. Trailing wildcards supported. - -| kubernetesPodLabel -| A list of resource labels. Trailing wildcards supported (value only), for example: `key1:val*`. -|=== - -[discrete] -[[security-d4c-policy-guide-file-selector-conditions]] -=== File-selector conditions - -These conditions are available only for `file` selectors. - -// [cols="1,1", options="header"] - -|=== -| Name| Description - -| operation -| The list of system operations to match on. Options include `createExecutable`, `modifyExecutable`, `createFile`, `modifyFile`, `deleteFile`. - -| ignoreVolumeMounts -| If set, ignores file operations on _all_ volume mounts. - -| ignoreVolumeFiles -| If set, ignores operations on file mounts only. For example: mounted files, `configMaps`, and secrets. - -| targetFilePath -| A list of file paths to include. Paths are absolute and wildcards are supported. The `*` wildcard matches any sequence of characters within a single directory, while the `**` wildcard matches any sequence of characters across multiple directories and subdirectories. -|=== - -[NOTE] -==== -In order to ensure precise targeting of file integrity monitoring operations, a `TargetFilePath` is required whenever the `deleteFile`, `modifyFile`, or `createFile` operations are used within a selector. -==== - -[discrete] -[[security-d4c-policy-guide-process-selector-conditions]] -=== Process-selector conditions - -These conditions are available only for `process` selectors. - -// [cols="1,1", options="header"] - -|=== -| Name| Description - -| operation -| The list of system operations to match on. Options include `fork` and `exec`. - -| processExecutable -| A list of executables (full path included) to match on. For example: `/usr/bin/cat`. Wildcard support is same as targetFilePath above. - -| processName -| A list of process names (executable basename) to match on. For example: `bash`, `vi`, `cat`. - -| sessionLeaderInteractive -| If set to `true`, will only match on interactive sessions (defined as sessions with a controlling TTY). -|=== - -[discrete] -[[security-d4c-policy-guide-response-fields]] -=== Response fields - -A policy can include one or more responses. Each response is comprised of the following fields: - -// [cols="1,1", options="header"] - -|=== -| Field| Description - -| match -| An array of one or more selectors of the same type (`file` or `process`). - -| exclude -| Optional. An array of one or more selectors to use as exclusions to everything in `match`. - -| actions -| An array of actions to perform when at least one `match` selector matches and none of the `exclude` selectors match. Options include `log`, `alert`, and `block`. -|=== - -[discrete] -[[security-d4c-policy-guide-response-actions]] -=== Response actions - -D4C responses can include the following actions: - -|=== -| Action | Description - -| log -| Sends events to the `logs-cloud_defend.file-*` data stream for file responses, and the `logs-cloud_defend.process-*` data stream for process responses. - -| alert -| Writes events (file or process) to the `logs-cloud_defend.alerts-*` data stream. - -| block -a| Prevents the system operation from proceeding. This blocking action happens prior to the execution of the event. It is required that the alert action be set if block is enabled. - -**Note:** Currently, block is only supported on file operations. -|=== diff --git a/docs/serverless/cloud-native-security/session-view.asciidoc b/docs/serverless/cloud-native-security/session-view.asciidoc index 18ee98712d..b8c4514f1f 100644 --- a/docs/serverless/cloud-native-security/session-view.asciidoc +++ b/docs/serverless/cloud-native-security/session-view.asciidoc @@ -19,11 +19,6 @@ Session View has the following features: * **Alerts:** Process, file, and network alerts in the context of the events which caused them. * **Terminal output:** Terminal output associated with each process in the session. -[NOTE] -==== -To view Linux session data from your Kubernetes infrastructure, you'll need to set up the <>. -==== - [discrete] [[enable-session-view]] == Enable Session View data diff --git a/docs/serverless/cloud-native-security/vuln-management-dashboard-dash.asciidoc b/docs/serverless/cloud-native-security/vuln-management-dashboard-dash.asciidoc index e0934f04ff..cdc9e7ce02 100644 --- a/docs/serverless/cloud-native-security/vuln-management-dashboard-dash.asciidoc +++ b/docs/serverless/cloud-native-security/vuln-management-dashboard-dash.asciidoc @@ -1,8 +1,4 @@ -:append: -2 - -[id="security-kubernetes-dashboard-dash{append}"] -= Kubernetes dashboard += Cloud Native Vulnerability Management dashboard include::../dashboards/vuln-management-dashboard-dash.asciidoc[tag=content] -:append!: diff --git a/docs/serverless/dashboards/kubernetes-dashboard-dash.asciidoc b/docs/serverless/dashboards/kubernetes-dashboard-dash.asciidoc deleted file mode 100644 index b2b4b83837..0000000000 --- a/docs/serverless/dashboards/kubernetes-dashboard-dash.asciidoc +++ /dev/null @@ -1,110 +0,0 @@ -[[security-kubernetes-dashboard-dash]] -= Kubernetes dashboard - -// :description: The Kubernetes dashboard provides insight into Linux process data from your Kubernetes clusters. -// :keywords: serverless, security, overview, cloud security - -:append: - -// tag::content[] - -++++ -Kubernetes -++++ - - -The Kubernetes dashboard provides insight into Linux process data from your Kubernetes clusters. It shows sessions in detail and in the context of your monitored infrastructure. - -[role="screenshot"] -image::images/kubernetes-dashboard/-dashboards-kubernetes-dashboard.png[The Kubernetes dashboard, with numbered labels 1 through 3 for major sections] -The numbered sections are described below: - -. The charts at the top of the dashboard provide an overview of your monitored Kubernetes infrastructure. You can hide them by clicking **Hide charts**. -. The tree navigation menu allows you to navigate through your deployments and select the scope of the sessions table to the right. You can select any item in the menu to show its sessions. In Logical view, the menu is organized by Cluster, Namespace, Pod, and Container image. In Infrastructure view, it is organized by Cluster, Node, Pod, and Container image. -. The sessions table displays sessions collected from the selected element of your Kubernetes infrastructure. You can view it in fullscreen by selecting the button in the table's upper right corner. You can sort the table by any of its fields. - -You can filter the data using the KQL search bar and date picker at the top of the page. - -From the sessions table's Actions column, you can take the following investigative actions: - -* View details -* <> -* <> -* <> -* <> - -Session View displays Kubernetes metadata under the **Metadata** tab of the Detail panel: - -[role="screenshot"] -image::images/kubernetes-dashboard/-dashboards-metadata-tab.png[The Detail panel's metadata tab] - -The **Metadata** tab is organized into these expandable sections: - -* **Metadata:** `hostname`, `id`, `ip`, `mac`, `name`, Host OS information -* **Cloud:** `instance.name`, `provider`, `region`, `account.id`, `project.id` -* **Container:** `id`, `name`, `image.name`, `image.tag`, `image.hash.all` -* **Orchestrator:** `resource.ip`, `resource.name`, `resource.type`, `namespace`, `cluster.id`, `cluster.name`, `parent.type` - -[discrete] -[id="k8s-dash-setup{append}"] -== Setup - -To get data for this dashboard, set up <> for the clusters you want to display on the dashboard. - -.Requirements -[NOTE] -==== -* Kubernetes node operating systems must have Linux kernels 5.10.16 or higher. -==== - -**Support matrix**: -This feature is currently available on GKE and EKS using Linux hosts and Kubernetes versions that match the following specifications: - -|=== -| | | - -| -| EKS 1.24-1.26 (AL2022) -| GKE 1.24-1.26 (COS) - -| Process event exports -| ✓ -| ✓ - -| Network event exports -| ✗ -| ✗ - -| File event exports -| ✓ -| ✓ - -| File blocking -| ✓ -| ✓ - -| Process blocking -| ✓ -| ✓ - -| Network blocking -| ✗ -| ✗ - -| Drift prevention -| ✓ -| ✓ - -| Mount point awareness -| ✓ -| ✓ -|=== - -[IMPORTANT] -==== -This dashboard uses data from the `logs-*` index pattern, which is included by default in the <>. To collect data from multiple {es} clusters (as in a cross-cluster deployment), update `logs-*` to `*:logs-*`. -==== - -// end::content[] - -:append!: diff --git a/docs/serverless/dashboards/vuln-management-dashboard-dash.asciidoc b/docs/serverless/dashboards/vuln-management-dashboard-dash.asciidoc index 9458445f8b..548c48ea80 100644 --- a/docs/serverless/dashboards/vuln-management-dashboard-dash.asciidoc +++ b/docs/serverless/dashboards/vuln-management-dashboard-dash.asciidoc @@ -9,7 +9,7 @@ // tag::content[] ++++ -Cloud Native Vulnerability Management +Cloud Native Vulnerability Management dashboard ++++ diff --git a/docs/serverless/index.asciidoc b/docs/serverless/index.asciidoc index 5ccd27d722..378abf008a 100644 --- a/docs/serverless/index.asciidoc +++ b/docs/serverless/index.asciidoc @@ -103,10 +103,6 @@ include::./cloud-native-security/vuln-management-get-started.asciidoc[leveloffse include::./cloud-native-security/vuln-management-findings.asciidoc[leveloffset=+4] include::./cloud-native-security/vuln-management-dashboard-dash.asciidoc[leveloffset=+4] include::./cloud-native-security/vuln-management-faq.asciidoc[leveloffset=+4] -include::./cloud-native-security/d4c-overview.asciidoc[leveloffset=+3] -include::./cloud-native-security/d4c-get-started.asciidoc[leveloffset=+4] -include::./cloud-native-security/d4c-policy-guide.asciidoc[leveloffset=+4] -include::./cloud-native-security/d4c-kubernetes-dashboard-dash.asciidoc[leveloffset=+4] include::./cloud-native-security/cloud-workload-protection.asciidoc[leveloffset=+3] include::./cloud-native-security/environment-variable-capture.asciidoc[leveloffset=+4] include::./cloud-native-security/ingest-cncf-data.asciidoc[leveloffset=+3] @@ -126,7 +122,6 @@ include::./explore/siem-field-reference.asciidoc[leveloffset=+3] include::./dashboards/dashboards-overview.asciidoc[leveloffset=+2] include::./dashboards/overview-dashboard.asciidoc[leveloffset=+3] include::./dashboards/detection-response-dashboard.asciidoc[leveloffset=+3] -include::./dashboards/kubernetes-dashboard-dash.asciidoc[leveloffset=+3] include::./dashboards/cloud-posture-dashboard-dash.asciidoc[leveloffset=+3] include::./dashboards/detection-entity-dashboard.asciidoc[leveloffset=+3] include::./dashboards/data-quality-dash.asciidoc[leveloffset=+3] diff --git a/docs/serverless/security-ui.asciidoc b/docs/serverless/security-ui.asciidoc index e17bcbfc20..b2421b829a 100644 --- a/docs/serverless/security-ui.asciidoc +++ b/docs/serverless/security-ui.asciidoc @@ -202,8 +202,6 @@ The Assets section allows you to manage the following features: ** <>: View and manage the blocklist, which allows you to prevent specified applications from running on hosts, extending the list of processes that {elastic-defend} considers malicious. ** <>: Find the history of response actions performed on hosts. * <> -+ -** <>: Identify and block unexpected system behavior in Kubernetes containers. [discrete] [[security-ui-ml-cap]]