Study guide
3.3 Fleet Server & Elastic Agent Integration Management
Elastic Certified SIEM Analyst Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview & Study Strategy
1.1 Elastic Certified SIEM Analyst Exam Facts, Objectives & Study Plan
2 Chapter 2: Elastic Stack Architecture & SIEM Foundations
2.1 Elastic Stack Architecture for Security Operations 2.2 Telemetry Ingestion Architecture & Data Pipelines 2.3 Security Data Storage, Data Streams & ILM
3 Chapter 3: Elastic Common Schema (ECS) & Ingestion Normalization
3.1 ECS Structure, Core Principles & Essential Field Sets 3.2 Ingest Pipelines, Processors & Normalization Workflows 3.3 Fleet Server & Elastic Agent Integration Management
4 Chapter 4: Discover, Data Views & Security Query Languages
4.1 Kibana Discover, Security Data Views & Runtime Fields 4.2 Kibana Query Language (KQL) & Lucene for SecOps 4.3 ES|QL for Multi-Stage Security Analysis
5 Chapter 5: Security Visualizations & Threat Analytics
5.1 Metric, Aggregation & Histogram Visualizations for SOC 5.2 Data Tables, Heatmaps & Specialized Security Charts 5.3 Elastic Maps & Geospatial Telemetry Analysis
6 Chapter 6: Kibana Lens for Security Workflows
6.1 Lens Architecture & Multi-Layer Telemetry Visualizations 6.2 Lens Formulas, Ratios & Anomaly Baseline Metrics 6.3 Operationalizing Lens in SOC Triage & Drilldowns
7 Chapter 7: Security Dashboards & SOC Operations
7.1 Security Dashboard Architecture & SOC Layout Design 7.2 Interactive Controls, Time Sync & Cross-Filtering 7.3 Dashboard Exporting, Reporting & Spaces Sharing
8 Chapter 8: The Elastic Security App: Capabilities, Explore & Dashboards
8.1 Security App Capabilities & the Explore Pages (Hosts, Network, Users) 8.2 Monitoring with the Security App Dashboards
9 Chapter 9: Elastic Security Detection Engine & Core Rules
9.1 Detection Engine Architecture & Prebuilt Rule Management 9.2 Custom Query & Threshold Detection Rules 9.3 Event Correlation Rules with Event Query Language (EQL)
10 Chapter 10: Advanced Detection Rules, ML & Rule Tuning
10.1 Threat Intelligence & Indicator Match Rules 10.2 New Terms, ES|QL & Machine Learning Detection Rules 10.3 Detection Rule Tuning, Exceptions & Alert Suppression
11 Chapter 11: Alert Triage, Timelines & Investigation Workflows
11.1 Alert Triage Workflow & the Alert Details Flyout 11.2 Elastic Security Timeline & Timeline Templates 11.3 Visual Event Analyzer & Session View Forensics
12 Chapter 12: Case Management, Integrations & AI Assistant
12.1 Elastic Security Case Management & Triage Workflows 12.2 Case Connectors & External Incident Escalation 12.3 Elastic AI Assistant for Security & Attack Discovery
13 Chapter 13: Security Administration, RBAC & Kibana Spaces
13.1 Kibana Spaces for SOC Multitenancy & Segmentation 13.2 Role-Based Access Control, Feature Privileges & Index Security 13.3 Elastic Defend Administration & Endpoint Policy Controls
14 Chapter 14: End-to-End Threat Hunting & Incident Investigation Capstone
14.1 Hypothesis-Driven Threat Hunting & Baselining in Elastic 14.2 Investigating Lateral Movement & Credential Access Campaigns 14.3 Data Exfiltration, C2 Detection & Incident Reconstruction
3.3 Fleet Server & Elastic Agent Integration Management
Key Takeaways Explain This Topic AI
Elastic Agent replaces individual standalone Beats with a single unified binary that provides endpoint security, log ingestion, and metric telemetry.
Fleet Server provides a centralized, scalable control plane that manages agent configurations, policy revisions, and enrollment over secure outbound HTTPS connections.
Agent policies declaratively configure integrations, automatically routing ingested telemetry into granular data streams adhering to 'type-dataset-namespace' naming.
The Elastic Defend integration adds malware, ransomware, memory threat and malicious behavior protections plus endpoint telemetry, configured through presets from Data Collection to Complete EDR.
Fleet continuously monitors agent statuses (Healthy, Unhealthy, Updating, Offline, Inactive, Unenrolled) and supports remote diagnostic collection and rolling binary upgrades.
Last updated: September 2026
Centralized Fleet Architecture vs. Standalone Beats
In legacy Elastic Stack deployments, monitoring an enterprise estate required deploying, configuring, and updating multiple standalone Beats on every server: Filebeat for logs, Metricbeat for host performance, Packetbeat for network flows, Auditbeat for Linux audit trails, and standalone Endpoint Security agents. Each Beat required its own local YAML configuration file, separate binary updates, and independent service management. Across thousands of enterprise endpoints, configuration drift and update management became major operational bottlenecks.
The Elastic Agent unifies all telemetry collection capabilities into a single binary. Rather than manually managing local configuration files on endpoints, Elastic Agents are centrally governed through Fleet in Kibana and coordinated by Fleet Server .
Fleet Architecture and Communication Model
The Fleet architecture consists of four interconnected components:
Kibana Fleet UI : The centralized administrative console where SOC teams configure agent policies, add integration packages, monitor agent health, and trigger remote diagnostics.
Fleet Server : A scalable backend control plane (deployed as an Elastic Agent process with the Fleet Server integration enabled) that brokers communication between thousands of managed Elastic Agents and Elasticsearch.
Elasticsearch : The central datastore that houses agent policies, enrollment tokens, integration packages, and the ingested telemetry data streams.
Elastic Agent : The endpoint binary installed on servers, workstations, and cloud instances. It establishes an outbound HTTPS connection to Fleet Server (default port 8220 ), retrieves policy revisions, executes configured integrations, and ships normalized telemetry directly to Elasticsearch (default port 9200 ).
Because Elastic Agents initiate outbound connections to Fleet Server, managed endpoints located in protected enclaves, branch offices, or cloud VPCs do not require inbound firewall openings.
Enrollment Tokens and Agent Policies
To onboard an Elastic Agent into Fleet, the endpoint must be registered using an Enrollment Token associated with an Agent Policy .
Declarative Agent Policies
An Agent Policy is a centralized configuration document that dictates an agent's runtime behavior:
Enabled Integrations : Specific modules configured for the host (e.g., Windows Event Logs, Linux System, Elastic Defend, AWS, Zeek).
Collection Settings : Polling intervals, target log file paths, and parsing pipelines.
Output Destination : The target Elasticsearch cluster and credentials used for data shipping.
Policies use automated revision versioning. When an administrator modifies an integration in the Fleet UI, Fleet increments the policy revision number. Connected Elastic Agents receive the update via long-polling, validate the new specification, and apply it atomically without restarting the host or dropping active telemetry streams.
Enrollment Tokens
Enrollment tokens authenticate agents during initial onboarding:
Each token is permanently bound to a designated Agent Policy.
Tokens can be scoped by environment (e.g., Production-Linux-Token , DMZ-Firewall-Token ).
If an enrollment token is compromised or a deployment campaign completes, administrators can revoke the token in the Fleet UI without affecting already-enrolled agents.
- To install and enroll an Elastic Agent via the command line: sudo ./elastic-agent install \
- -url=https://fleet-server.corp.internal:8220 \
- -enrollment-token=QUJjMTIzWHl6... \
- -certificate-authorities=/etc/pki/ca.crt
- Integrations and Data Stream Architecture
Integrations are modular software packages downloaded from the Elastic Package Registry (EPR) that provide input configuration, ingest pipelines, index mappings and, often, Kibana dashboards.
The Elastic Defend Integration
For security analysts, the Elastic Defend (formerly Endpoint Security) integration is the primary endpoint protection mechanism. Adding Elastic Defend to an Agent Policy enables:
Malware Protection : Scans executables when they are written or run and uses an on-host machine-learning model, plus signatures and your blocklist, to detect or block malware.
Ransomware Protection : Detects and halts unauthorized mass encryption of user documents, canary files, and filesystem structures.
Behavioral Protection : Detects suspicious process ancestry, API hooking, memory injection (process hollowing, thread injection), and credential dumping against LSASS.
Configuration Presets : When you add Elastic Defend for Traditional Endpoints , you choose a preset that you can customize later:
Data Collection : all events, no preventions.
Next-Generation Antivirus (NGAV) : process events plus all preventions.
Essential EDR : process, network and file events plus all preventions.
Complete EDR : all events plus all preventions.
Every preset except Data Collection enables the malware, ransomware, memory threat, malicious behavior and credential theft preventions by default. The separate Cloud Workloads presets target cloud Linux hosts, collect process, network and file events with session data, and start with preventions disabled.
Data Stream Naming: type-dataset-namespace
Fleet-managed agents write all telemetry into Elasticsearch Data Streams . Data streams enforce a three-part naming hierarchy:
type − dataset − namespace \text{type}-\text{dataset}-\text{namespace} type − dataset − namespace
type : Broad category of telemetry. Standard values are logs , metrics , synthetics , and traces .
dataset : The specific log or telemetry source defined by the integration (e.g., windows.sysmon_operational , system.auth , aws.cloudtrail , endpoint.events.process ).
namespace : An administrator-defined grouping reflecting an environment, tenant, or business unit (e.g., production , pci , development , default ).
For example, Windows Sysmon telemetry collected from production servers routes to: logs-windows.sysmon_operational-production
This granular naming convention allows administrators to attach distinct Index Lifecycle Management (ILM) retention policies, ingest pipelines, and Role-Based Access Controls (RBAC) to specific datasets and namespaces independently.
Agent Lifecycle and Troubleshooting
Fleet provides real-time visibility into the operational state of every managed endpoint.
Elastic Agent Statuses and Remediation Matrix
Agent Status Operational Meaning Common Root Causes Remediation Procedure
Healthy Agent is running normally and checking in with Fleet. Normal operation. None required; monitor ingestion volume.
Unhealthy Agent is running but has errors or a degraded component or integration. Missing permissions, invalid log paths, resource exhaustion, component crash. Run elastic-agent status locally, check integration health in Fleet, collect diagnostics.
Updating Agent is updating its policy or binary, or enrolling or unenrolling. Policy change or Fleet-initiated upgrade. Wait for completion; investigate if it does not finish.
Offline Agent has stopped checking in for a period; its API keys remain valid. Host powered off, network path to Fleet Server blocked, service stopped. Verify the route to Fleet Server and the local service ( systemctl status elastic-agent or Windows Services).
Inactive Agent has been offline longer than the policy's inactivity timeout; it is hidden from the main Fleet view. Decommissioned or long-disconnected host. Unenroll it if it is no longer valid.
Unenrolled Agent was manually unenrolled and its API keys were removed. Intentional removal. Re-enroll with a new enrollment token if needed.
Endpoint CLI Diagnostics and Enterprise Proxy Support
When investigating an unhealthy or non-responsive agent directly on an endpoint:
Inspect Component Health : sudo elastic-agent status Displays the granular status of each managed component process (e.g., filebeat , metricbeat , endpoint-security ).
Generate Diagnostic Bundle : sudo elastic-agent diagnostics Writes a diagnostics .zip archive containing configuration snapshots, component logs and runtime metrics. Administrators can also collect this remotely from Fleet with the agent's Request diagnostics .zip action, without host SSH access.
Enterprise Proxy Configuration : For endpoints operating in restricted enclaves without direct routing to Fleet Server, agents support HTTP/HTTPS forward proxies, set at install time or in Fleet proxy settings: sudo ./elastic-agent install --url=https://fleet-server.corp.internal:8220 \