8.8 D4C integration docs

docs/cloud-native-security/cloud-native-security-index.asciidoc

@@ -17,6 +17,11 @@ include::kspm-findings.asciidoc[leveloffset=+2]
 include::kspm-benchmark-rules.asciidoc[leveloffset=+2]
 include::kspm-cloud-posture-dashboard.asciidoc[leveloffset=+2]
 include::kspm-faq.asciidoc[leveloffset=+2]
+
+include::d4c-overview.asciidoc[leveloffset=+1]
+include::d4c-get-started.asciidoc[leveloffset=+2]
+include::d4c-policy-guide.asciidoc[leveloffset=+2]
+
 include::cloud-workload-protection.asciidoc[leveloffset=+1]
 include::session-view.asciidoc[leveloffset=+1]
 include::cloud-nat-sec-kubernetes-dashboard.asciidoc[leveloffset=+1]

docs/cloud-native-security/cloud-workload-protection.asciidoc

@@ -1,15 +1,15 @@
 [[cloud-workload-protection]]
-= Cloud workload protection
+= Cloud workload protection for VMs
 
-Cloud workload protection helps you monitor and protect your Linux hosts and Kubernetes runtimes. It uses the <<install-endpoint,{elastic-defend}>> integration to capture cloud workload telemetry containing process, file, and network activity. In Kubernetes environments, this telemetry is further enriched with metadata that enables you to isolate events in your cloud topography.
+Cloud workload protection helps you monitor and protect your Linux VMs. It uses the <<install-endpoint,{elastic-defend}>> integration to capture cloud workload telemetry containing process, file, and network activity.
 
-This telemetry also enables the automated identification of cloud threats with out-of-the-box detection rules and machine learning models. Alerts based on these detections can reduce the time to identify and remediate threats.
+Use this telemetry with out-of-the-box detection rules and machine learning models to automate processes that identify cloud threats.
 
 [discrete]
 == Use cases
 
 * **Runtime monitoring of cloud workloads:** Provides visibility into cloud workloads, context for detected threats, and the historical data needed for retroactive threat investigations.
-* **Cloud-native threat detection and prevention:** Provides security coverage for Linux, containers, Kubernetes, and serverless applications. Protects from known and unknown threats using on-host detections and protections against malicious behavior, memory threats, and malware.
+* **Cloud-native threat detection and prevention:** Provides security coverage for Linux, containers, and serverless applications. Protects against known and unknown threats using on-host detections and protections against malicious behavior, memory threats, and malware.
 * **Reducing the time to detect and remediate runtime threats:** Helps you resolve potential threats by showing alerts in context, making the data necessary for further investigations readily available, and providing remediation options.
 
 To continue setting up your cloud workload protection, learn more about:

docs/cloud-native-security/d4c-get-started.asciidoc

@@ -0,0 +1,68 @@
+[[d4c-get-started]]
+= Get started with CWP
+
+This page describes how to set up Container Workload Protection (CWP) for various usecases.
+
+[discrete]
+== Initial setup
+
+First, you'll need to deploy Elastic's Defend for Containers integration to the Kubernetes clusters you wish to monitor.
+
+. Go to *Manage > Container Workload Security > 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 <<d4c-policy-guide, Defend for Containers policy guide>>). 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 the step 3 (**Install Elatic 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:
++
+```
+#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*.
+
+[[d4c-get-started-threat]]
+[discrete]
+== Get started with threat detection
+
+One of the <<d4c-default-policies, default D4C policies>> sends process telemetry events (`fork` and `exec`) to {es}.
+
+In order to detect threats using this data, you'll need active <<detection-engine-overview, detection rules>>. Elastic has prebuilt detection rules designed for this data. (You can also create your own <<rules-ui-create, custom rules>>.)
+
+To install and enable Elastic's prebuilt rules:
+
+. Go to *Security > Manage > Rules*, and click *Load Elastic prebuilt rules and timeline templates* (this may take a few minutes).
+. Once the rules have loaded, you will see the Rules management page. Use the *Tags* selector to search for `container`. Select the `Container Workload Protection` tag.
+. Select all the rules with the tag, and then click *Bulk actions > Enable*.
+
+[[d4c-get-started-drift]]
+[discrete]
+== Get started with drift detection and prevention
+
+{elastic-sec} defines container drift as the creation of a new executable or the modification of an existing executable within a container. Blocking drift greatly restricts the number of attack vectors available to bad actors by prohibiting them from using external tools.
+
+One of the <<d4c-default-policies, default D4C policies>> creates alerts in {elastic-sec} when container drift is detected. Before you enable blocking, we strongly recommend that you observe a production workload using the default policy to ensure that the workload does not create or modify executables as part of its normal operation.
+
+To enable blocking:
+
+. Add a new selector called `blockDrift`.
+. Go to *Security > Manage > Container Workload Protection > Your integration name*.
+. Under *Selectors*, click *Add selector > File Selector*. By default it will select 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*.
+
+[[d4c-get-started-validation]]
+[discrete]
+== Policy validation
+To ensure the stability of your production workloads, you should test policy changes before implementing them on production workloads. If possible, you should 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.

docs/cloud-native-security/d4c-overview.asciidoc

@@ -0,0 +1,45 @@
+[[d4c-overview]]
+= Container workload protection
+
+Elastic Container Workload Protection (CWP) provides cloud-native runtime protections for containerized environments by identifying and optionally blocking unexpected system behavior in Kubernetes containers.
+
+[[d4c-use-cases]]
+[discrete]
+== Use cases
+
+[discrete]
+=== Threat detection & threat hunting
+CWP sends system events from your containers to {es}. {elastic-sec}'s prebuilt security rules include many designed to detect malicious behaviors in container runtimes. These can help you detect behaviors that should never take place in containers, such as reverse shell executions, privilege escalation, container escape attempts, and more.
+
+[discrete]
+=== 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]
+=== Workload protection policies
+CWP uses a powerful 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]
+== Support matrix:
+[options="header"]
+|===
+| | 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 | Coming Soon | Coming Soon
+| Network blocking | ✗ | ✗
+| Drift prevention | ✓ | ✓
+| Mount point awareness | ✓ | ✓
+|===
+
+[discrete]
+== How CWP works
+CWP uses a lightweight integration, Defend for Containers (D4C). When you deploy the D4C integration, it gets bundled with and configured by {agent}. The {agent} gets installed as a DaemonSet on your Kubernetes clusters, enabling 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. Each policy is defined by selectors and responses. 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 <<d4c-policy-guide, D4C policies guide>>.

docs/cloud-native-security/d4c-policy-guide.asciidoc

@@ -0,0 +1,96 @@
+[[d4c-policy-guide]]
+= Container workload protection policies
+
+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 an exhaustive glossary of selector conditions, and of response fields and actions.
+
+[[d4c-default-policies]]
+[discrete]
+== 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 events to your {es} cluster, so that {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 the 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.
+
+image::images/d4c-policy-editor.png[The defend for containers policy editor with the default policies]
+
+
+[[d4c-selectors-glossary]]
+[discrete]
+== 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 some are only available for one type of selector.
+
+[discrete]
+=== 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]
+=== 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]
+=== 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]
+=== 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]
+=== Response actions
+D4C responses can include the following actions:
+
+[cols="1,1", options="header"]
+|===
+| 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. 
+|===