13.3 Elastic Defend Administration & Endpoint Policy Controls

Endpoint security represents both the frontline defense and the highest-volume telemetry source in modern enterprise security architectures. The Elastic Defend integration (formerly Endpoint Security) combines kernel-level behavioral monitoring, signatureless machine learning, anti-ransomware defenses, and real-time containment into the unified Elastic Agent. Administering Elastic Defend requires balancing aggressive threat prevention against operational stability: tuning out benign high-volume events, whitelisting proprietary enterprise software, generating diagnostic bundles during operational anomalies, and executing emergency host isolation during active breaches.

---

1. Elastic Defend Architecture & Fleet Policy Orchestration

Unlike legacy endpoint architectures that rely on separate standalone agents for EDR, log forwarding, and osquery, Elastic Defend operates as an integrated extension of the Unified Elastic Agent:

• Fleet Control Plane: Defend configurations are managed entirely through Fleet Agent Policies in Kibana. When an administrator modifies a Defend integration policy (e.g., toggling Ransomware protection from Detect to Prevent), Fleet Server delivers the updated policy to enrolled agents over their outbound HTTPS check-in connection (port 8220 by default).
• User-Space & Kernel Architecture: Elastic Defend consists of an endpoint daemon running in user-space coupled with platform-specific kernel drivers:
  • Windows: A kernel driver that receives process, file, network and registry events.
  • macOS: Apple's Endpoint Security framework through a system extension (which needs Full Disk Access).
  • Linux: Kernel instrumentation such as eBPF (with a tracefs fallback on older kernels) and fanotify for file scanning.

---

2. Protection Engines and Operating Modes

Elastic Defend's policy has four primary protections (plus attack surface reduction settings such as credential hardening on Windows). Each can be independently set to Detect or Prevent (or turned off). Ransomware protection applies to Windows, and the presets other than Data Collection turn on all preventions by default:

+-------------------------------------------------------------------------+
|                        Elastic Defend Integration                       |
+--------------------+--------------------+-------------------------------+|
| Protection Engine  | Operating Mode     | Primary SecOps Detection Scope |
+--------------------+--------------------+-------------------------------+|
| Malware Protection | Detect / Prevent   | Malicious binaries, DLLs via signatures and ML |
| Ransomware Protect | Detect / Prevent   | Mass encryption, canary tampering, VSS purge  |
| Memory Threat Prot | Detect / Prevent   | Shellcode, reflective DLLs, process hollowing |
| Malicious Behavior | Detect / Prevent   | LOLBAS abuse, suspicious process trees, LSASS |
+--------------------+--------------------+-------------------------------+|

Operating Modes: Detect vs. Prevent

• Detect Mode: When an engine detects a threat, it generates a security alert, records full event metadata (process ancestry, hashes, command lines), and transmits the telemetry to Elasticsearch. However, the offending process is permitted to continue execution. Detect mode is critical during initial baselining or when rolling out policies to mission-critical servers, allowing engineers to verify that line-of-business applications are not disrupted.
• Prevent Mode: When a threat is detected, Defend blocks it, for example by stopping the offending process or preventing the malicious file from running, and publishes an alert documenting the prevention action.

Detailed Engine Capabilities

1. Malware Protection: Scans executables, dynamic libraries, and scripts upon creation, modification, or execution. Uses a local signature engine combined with on-device machine learning models to detect known and novel malware variants.
2. Ransomware Protection: Monitors file system activity for behavioral patterns characteristic of ransomware, including rapid file encryption velocities, modification of high-entropy files, tampering with canary files placed in sensitive directories, and execution of volume shadow copy deletion commands (vssadmin.exe delete shadows /all /quiet).
3. Memory Threat Protection: Defends against advanced in-memory exploitation techniques that bypass disk-based scanners. Detects shellcode injection, process hollowing, reflective DLL loading, thread execution hijacking, and asynchronous procedure call (APC) injection.
4. Malicious Behavior Protection: Analyzes live process behaviors targeting living-off-the-land binaries (LOLBAS). Detects suspicious child process relationships (e.g., word.exe spawning powershell.exe with base64 encoded parameters) and attempts to dump credentials from the Local Security Authority Subsystem Service (lsass.exe).

---

3. Diagnostic Bundles & Endpoint Troubleshooting

When an Elastic Agent exhibits communication issues, high resource consumption, or driver conflicts with third-party software, engineers must collect forensic diagnostic data without manual SSH or RDP sessions.

Generating Diagnostic Bundles via Fleet

1. In Kibana, open Fleet → Agents.
2. Locate the affected host, click the Actions menu (...), and select Request diagnostics .zip.
3. Fleet Server dispatches an instruction to the endpoint. The agent collects:
   • Active configuration JSON files (elastic-agent.yml, policy snapshots).
   • Agent daemon logs (elastic-agent.log) and Defend service logs (endpoint-security.log).
   • Driver operational states, kernel extension statuses, and crash dump files.
   • System resource utilization metrics (CPU, memory, handle counts) and network socket tables.
4. The endpoint compresses the diagnostic payload into a zip or tar archive and streams it back through Fleet Server. The administrator can download the bundle directly from the Kibana interface for analysis.

---

4. Policy Tuning: Endpoint Artifacts and Exceptions

Elastic's Optimize Elastic Defend guidance separates four tools. Choosing the wrong one either leaves noise or creates a blind spot.

Trusted Applications

• Purpose: Resolve conflicts and performance problems with other software, usually other antivirus or endpoint security products.
• Effect: Elastic Endpoint stops monitoring the process for threats and generates no events for it, except process events used internally for visualizations. This is an intentional blind spot: attackers can abuse trusted processes, for example through DLL side-loading. Use trusted applications sparingly.
• Matching: One field type per entry: hash (MD5, SHA-1 or SHA-256), full path (wildcards allowed with matches), or, on Windows, the signer name. Entries apply globally or, with Platinum or higher, to specific Elastic Defend policies.

Endpoint Alert Exceptions

• Purpose: Stop false-positive alerts and preventions for a specific, verified behavior.
• Effect: Elastic Endpoint does not generate the alert or stop the process when the exception matches. It keeps monitoring everything else, and checks exceptions early, which can also save CPU. Add one from an Endpoint alert with Take action → Add Endpoint exception.

Event Filters

• Purpose: Reduce storage by keeping noisy, benign event documents out of Elasticsearch.
• Effect: Matching events are not written to Elasticsearch, but Elastic Endpoint still monitors them for threats. Event filters do not lower CPU use on the endpoint.

Blocklist

• Purpose: Extend protection by preventing known-bad applications (by hash, path or signer) from running.
• Effect: Not intended for blocking benign software for non-security reasons.

(Host isolation exceptions are a fifth artifact type. They list IP addresses that isolated hosts may still reach.)

---

5. Host Isolation Mechanics & Emergency Network Containment

During an active incident, such as an adversary running a reverse shell or lateral movement tools, responders must contain the host without losing visibility.

+-------------------------------------------------------------------------+
|                        Host Isolation Engaged                           |
+-------------------------------------------------------------------------+
|  Attacker C2 traffic          -----> [ BLOCKED ]                        |
|  Lateral SMB / RDP to peers   -----> [ BLOCKED ]                        |
|  Internal subnet scans        -----> [ BLOCKED ]                        |
|                                                                         |
|  Data to Elasticsearch/Kibana <====> [ ALLOWED - telemetry continues ] |
|  Host isolation exception IPs <====> [ ALLOWED - e.g. VPN or DNS host ] |
+-------------------------------------------------------------------------+

Mechanism of Host Isolation

When an analyst chooses Isolate host from the alert details flyout, the Endpoints page, or the response console (isolate, Enterprise):

1. Requirements: Host isolation needs a Platinum or Enterprise subscription and the Host Isolation privilege. It is supported on Windows, macOS and supported Linux distributions running Elastic Defend.
2. Network Blocking: The endpoint is blocked from communicating with other hosts on the network, which cuts C2 channels and stops lateral spread.
3. Preserved Visibility: Isolated hosts can still send data to Elasticsearch and Kibana, so responders keep receiving telemetry and can continue response actions.
4. Exceptions: Host isolation exceptions list specific IP addresses that isolated hosts may still reach, for example a VPN concentrator or a DNS server.
5. Release: When remediation is finished, responders choose Release host. Every isolate and release action is recorded in the host's response actions history, and an Isolated status appears next to the agent status.

---

6. Comprehensive Tuning Artifact Comparison