Microsoft Defender for Endpoint integration

Version 4.14.0 (View all)
Managed integration release status GA
Subscription level
What's this?
Basic
Developed by
What's this?
Elastic
Ingestion method(s) API, File
Minimum Kibana version(s) 9.1.2
8.19.3
Important - Managed integrations on Elastic Cloud Hosted

You can use this integration as an Elastic Managed integration on Elastic Cloud Hosted deployments running this version or later.

This integration is for Microsoft Defender for Endpoint logs.

Microsoft Defender for Endpoint integration collects data for Alert, Baseline, Configuration, Information Gathering, Machine, Machine Action and Vulnerability logs using REST API.

For a demo, refer to the following video (click to view).

Microsoft Defender for Endpoint integration video

This integration collects the following logs:

  • Alert - Retrieves alerts generated by Microsoft Defender for Endpoint.
  • Baseline - Retrieves security baseline compliance assessment snapshots per device, profile, and configuration.
  • Configuration - Retrieves secure configuration assessment snapshots per device from the SecureConfigurationsAssessmentByMachine API.
  • Information Gathering - Retrieves per-device TVM information gathering posture snapshots (AV health, emerging threat mitigations, and attack surface telemetry) via the InfoGatheringExport API.
  • Machine - Retrieves machines that have communicated with Microsoft Defender for Endpoint.
  • Machine Action - Retrieves logs of actions carried out on machines.
  • Vulnerability - Retrieves vulnerability change events (new, updated, and fixed) using the delta API.

Elastic Managed integrations allow you to collect data without having to manage Elastic Agent in your cloud. They make manual agent deployment unnecessary, so you can focus on your data instead of the agent that collects it. For more information, refer to Elastic Managed integrations and the Elastic Managed integrations FAQ.

Elastic Managed deployments are only supported in Elastic Serverless and Elastic Cloud environments. This functionality is in beta and is subject to change. Beta features are not subject to the support SLA of official GA features.

Elastic Agent must be installed. For more details, check the Elastic Agent installation instructions. You can install only one Elastic Agent per host.

To allow the integration to ingest data from the Microsoft Defender API, you need to create a new application on your Azure domain. The procedure to create an application is found on the Create a new Azure Application documentation page.

When the application is granted the API permissions listed in the table below, it will receive only the necessary access to collect logs nothing more within the Azure domain.

Data stream API Permissions
Alert Alert.Read.All
Baseline SecurityBaselinesAssessment.Read.All
Configuration Vulnerability.Read.All, Vulnerability.Read
Information Gathering Vulnerability.Read.All, Vulnerability.Read
Machine Machine.Read.All
Machine Action Machine.Read.All
Vulnerability Vulnerability.Read.All, Vulnerability.Read

After the application has been created, it should contain 3 values that you need to apply to the module configuration.

These values are:

  • Client ID
  • Client Secret
  • Tenant ID
  1. In Kibana navigate to Management > Integrations.
  2. In the search bar, type Microsoft Defender for Endpoint.
  3. Select the Microsoft Defender for Endpoint integration and add it.
  4. Add all the required integration configuration parameters, including the Client ID, Client Secret, Tenant ID to enable data collection.
  5. Select "Save and continue" to save the integration.

The vulnerability data stream collects vulnerability change events from the SoftwareVulnerabilityChangesByMachine delta API, resuming from a saved sinceTime cursor. Every change to a vulnerability on a machine is a new document, so the source stream grows with change volume rather than with the size of the estate, and the latest_cdr_vuln transform maintains the current state of each vulnerability. The other data streams collect incrementally and follow the default lifecycle for their destination indices.

The package bounds the growth of these source data streams with a retention that depends on the deployment type:

Data stream Self-managed and Elastic Cloud Hosted (ILM policy) Serverless (data stream lifecycle)
logs-microsoft_defender_endpoint.vulnerability-* logs-microsoft_defender_endpoint.vulnerability-default_policy: roll over after 7d, delete 7d after rollover delete 7d after rollover

On self-managed and Elastic Cloud Hosted deployments the ILM policy applies. The data stream lifecycle shipped with the package is not used there. ILM counts the delete age from the rollover of a backing index, so a document can remain for up to the rollover age plus the delete age. On Serverless, ILM is not available and the data stream lifecycle applies instead. It also works per backing index: Elasticsearch rolls the write index over automatically on age, size, or document count, and deletes a backing index once the retention has passed since it rolled over. A document therefore stays for the retention plus up to one rollover interval. The rollover age is derived from the retention and is an implementation detail that Elasticsearch may change. Where the package installs a transform, the transform's destination indices are not affected by either.

To keep data for a different period:

  • Self-managed and Elastic Cloud Hosted: edit the ILM policy in Kibana under Stack Management → Index Lifecycle Policies, or with PUT _ilm/policy/<policy name>. A package upgrade reinstalls the package's ILM policies, so check your change after upgrading.
  • Serverless: set the retention on the data stream, for example PUT _data_stream/logs-microsoft_defender_endpoint.vulnerability-default/_lifecycle with the body {"data_retention": "90d"}. Replace default with your namespace.
Note

The user or service account associated with the integration must have the following index privileges on the relevant index: delete, delete_index

Defender for Endpoint fields ECS Fields
alertCreationTime @timestamp
aadTenantId cloud.account.id
category threat.technique.name
computerDnsName host.hostname
description rule.description
detectionSource observer.name
evidence.fileName file.name
evidence.filePath file.path
evidence.processId process.pid
evidence.processCommandLine process.command_line
evidence.processCreationTime process.start
evidence.parentProcessId process.parent.pid
evidence.parentProcessCreationTime process.parent.start
evidence.sha1 file.hash.sha1
evidence.sha256 file.hash.sha256
evidence.url url.full
firstEventTime event.start
id event.id
lastEventTime event.end
machineId cloud.instance.id
title message
severity event.severity

The values used in event.severity are consistent with Elastic Detection Rules.

Severity Name event.severity
Low (or Informational) 21
Medium 47
High 73
Critical 99

The vulnerability data stream uses Microsoft Defender for Endpoint's delta API, which returns change events including remediated (Fixed) vulnerabilities. Each record carries a vulnerability.status field with one of the following values: open, fixed, or unknown.

Until the Kibana Vulnerability Findings page adds a default filter on this field, remediated vulnerabilities will appear alongside open findings. To exclude them, add the following filter to the Findings page or any saved search:

NOT vulnerability.status: fixed
		

This is equivalent to showing only currently active vulnerabilities.

This is the log dataset.

This is the machine dataset.

This is the machine action dataset.

This is the vulnerability dataset.

This is the configuration dataset.

This is the baseline dataset.

This is the information_gathering dataset.

This integration includes one or more Kibana dashboards that visualizes the data collected by the integration. The screenshots below illustrate how the ingested data is displayed.