Microsoft Defender for Cloud Integration for Elastic

The Microsoft Defender for Cloud integration allows you to monitor security alert events and assessments. When integrated with Elastic Security, this valuable data can be leveraged within Elastic for analyzing the resources and services that users are protecting through Microsoft Defender.

Use the Microsoft Defender for Cloud integration to collect and parse data from Azure Event Hub, Azure REST API, and then visualize that data in Kibana.

The Microsoft Defender for Cloud integration uses the Azure REST API. It uses the 2021-06-01 API version for retrieving assessments and the 2019-01-01-preview API version for retrieving sub-assessments.

For the assessment data stream, the /assessments endpoint retrieves all available assessments for the provided scope, which can be a Subscription ID or a Management Group Name. For each assessment, if sub-assessments are available, we will make another call to collect them. We will aggregate the results from both calls and publish them.

This integration collects log messages of the following types:

• Event: allows users to preserve a record of security events that occurred on the subscription, which includes real-time events that affect the security of the user's environment. For further information connected to security alerts and type, refer to the security alerts reference guide.
• Assessment: collect security assessments on all your scanned resources inside a scope from the Assessments and Sub Assessments endpoints.

Integrating Microsoft Defender for Cloud with Elastic SIEM provides advanced threat protection and security assessments for your cloud services. It monitors security events in real time, offers actionable recommendations to improve your security posture, and helps ensure compliance with industry standards. Leveraging Defender for Cloud integration allows organizations to enhance their cloud security and mitigate potential risks.

Version 3.0.0 of the Microsoft Defender for Cloud integration adds Elastic latest transforms. For more details, check the Transform setup and requirements.

Configure the Microsoft Defender for Cloud on Azure subscription. For more detail, refer to the link here.

• Configure continuous export to stream security events to your Azure Event Hub.

When the Elastic Agent must reach Azure Event Hubs through an HTTP/HTTPS proxy, set the Event Hubs transport protocol to AMQP-over-WebSockets. This routes Event Hub traffic over HTTPS (port 443) instead of AMQP (port 5671), which allows the proxy to handle it. Selecting AMQP-over-WebSockets automatically sets the processor version to v2.

Requirements:

• Elastic Agent 8.19.10, 9.1.10, 9.2.4, or later.
• Set HTTPS_PROXY and, if needed, NO_PROXY in the Elastic Agent process environment (for example, a systemd drop-in file or container environment variable). These variables apply to the entire agent process, not just this integration. Use NO_PROXY to exclude traffic that should bypass the proxy.

Proxy allowlist: the proxy must allow HTTPS (port 443) connections to:

• *.servicebus.windows.net — Event Hub traffic. Sovereign clouds use a different suffix (for example, *.servicebus.usgovcloudapi.net for Azure Government).
• *.blob.core.windows.net — checkpoint storage. Sovereign clouds use the storage suffix derived from Authority Host (for example, *.blob.core.usgovcloudapi.net for Azure Government).
• The authority host (default login.microsoftonline.com) — required for client secret authentication.

TLS-intercepting proxies: if the proxy performs TLS interception, the corporate CA certificate must be present in the system trust store on the agent host.

Sovereign clouds: users on Azure Government, Azure China, or Azure Germany must set the Authority Host to the correct login endpoint. Processor v2 derives the storage endpoint suffix from this setting. The Resource Manager Endpoint setting is used only by processor v1 and is ignored by v2.

Note on processor version: selecting AMQP-over-WebSockets moves the processor from v1 to v2 if the agent was previously running v1. Existing checkpoints are migrated automatically. However, switching back to v1 afterwards resumes from stale v1 checkpoints and may cause duplicate events.

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.

• Register a new Azure Application.
• Assign the required permission: user_impersonation in Azure Service Management.
• Assign the built-in Reader role to the new application for the required scope, which will be used in the API to retrieve the assessments. For more details, check out the role assignment using the Azure portal documentation.
• Once the application is registered, note the following values for use during configuration:
  • Client ID
  • Client Secret
  • Tenant ID

This integration supports both Elastic Managed and Agent-based installations.

Elastic Managed integrations are only supported on Elastic Cloud Serverless and Elastic Cloud Hosted deployments. An Elastic Managed integration lets you ingest data from a cloud source while avoiding the orchestration, management, and maintenance associated with standard ingest infrastructure. Elastic runs the collector for you, so you can focus on your data instead of the infrastructure that collects it.

For more information, refer to Elastic Managed integrations and the Elastic Managed integrations FAQ.

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

1. In the top search bar in Kibana, search for Integrations.

2. In the search bar, type Microsoft Defender for Cloud.

3. Select the Microsoft Defender for Cloud integration from the search results.

4. Select Add Microsoft Defender for Cloud to add the integration.

5. Enable and configure only the collection methods which you will use.

   • To Collect Microsoft Defender Cloud logs via API, you'll need to:

     • Configure Client ID, Client Secret and Tenant ID. Configure either Subscription ID or Management Group Name as the scope.

   • To Collect logs from Azure Event Hub, you'll need to:

     • Choose Authentication type: Connection String (default) or Client Secret (Microsoft Entra ID). For Connection String: configure Azure Event Hub, Connection String, Storage Account, and storage_account_key. For Client Secret: configure Azure Event Hub, Consumer Group, Tenant ID, Client ID, Client Secret, Event Hub namespace, and Storage Account (no storage key). For client secret setup and required RBAC roles (Azure Event Hubs Data Receiver, Storage Blob Data Contributor), see the Azure Logs integration or Filebeat azure-eventhub input documentation.

6. Select Save and continue to save the integration.

1. In the top search bar in Kibana, search for Dashboards.
2. In the search bar, type microsoft_defender_cloud.
3. Select a dashboard for the dataset you are collecting, and verify the dashboard information is populated.

1. In the top search bar in Kibana, search for Transforms.
2. Select the Data / Transforms from the search results.
3. In the search bar, type microsoft_defender_cloud.
4. All transforms from the search results should indicate Healthy under the Health column.

For more information on architectures that can be used for scaling this integration, check the Ingest Architectures documentation.

{
    "@timestamp": "2025-09-18T10:09:59.903Z",
    "agent": {
        "ephemeral_id": "c4193e13-66e4-4dd8-9ab2-551ab726ae37",
        "id": "9e17cadb-6a42-481f-bd75-3e84c91d6b7a",
        "name": "elastic-agent-57167",
        "type": "filebeat",
        "version": "8.19.4"
    },
    "cloud": {
        "account": {
            "id": "5abcdef6-1234-5678-8912-e1234abcdef1"
        },
        "instance": {
            "id": "/subscriptions/5abcdef6-1234-5678-8912-e1234abcdef1/resourceGroups/DEFENDER_CLOUD_GROUP/providers/Microsoft.Compute/virtualMachines/vm-for-defender-cloud-test",
            "name": "vm-for-defender-cloud-test"
        },
        "provider": "azure",
        "service": {
            "name": "Microsoft.Compute"
        }
    },
    "data_stream": {
        "dataset": "microsoft_defender_cloud.assessment",
        "namespace": "72994",
        "type": "logs"
    },
    "ecs": {
        "version": "8.17.0"
    },
    "elastic_agent": {
        "id": "9e17cadb-6a42-481f-bd75-3e84c91d6b7a",
        "snapshot": true,
        "version": "8.19.4"
    },
    "event": {
        "agent_id_status": "verified",
        "category": [
            "configuration"
        ],
        "dataset": "microsoft_defender_cloud.assessment",
        "id": "/subscriptions/5abcdef6-1234-5678-8912-e1234abcdef1/resourceGroups/DEFENDER_CLOUD_GROUP/providers/Microsoft.Compute/virtualMachines/vm-for-defender-cloud-test/providers/Microsoft.Security/assessments/fabcdef2-5678-1234-8382-21234567890d",
        "ingested": "2025-09-18T10:10:02Z",
        "kind": "state",
        "original": "{\"id\":\"/subscriptions/5abcdef6-1234-5678-8912-e1234abcdef1/resourceGroups/DEFENDER_CLOUD_GROUP/providers/Microsoft.Compute/virtualMachines/vm-for-defender-cloud-test/providers/Microsoft.Security/assessments/fabcdef2-5678-1234-8382-21234567890d\",\"name\":\"fabcdef2-5678-1234-8382-21234567890d\",\"properties\":{\"additionalData\":{\"Can onboard to BYOL\":\"true\"},\"displayName\":\"Machines should have a vulnerability assessment solution\",\"resourceDetails\":{\"Id\":\"/subscriptions/5abcdef6-1234-5678-8912-e1234abcdef1/resourceGroups/DEFENDER_CLOUD_GROUP/providers/Microsoft.Compute/virtualMachines/vm-for-defender-cloud-test\",\"NativeResourceId\":\"/subscriptions/5abcdef6-1234-5678-8912-e1234abcdef1/resourceGroups/DEFENDER_CLOUD_GROUP/providers/Microsoft.Compute/virtualMachines/vm-for-defender-cloud-test\",\"ResourceName\":\"vm-for-defender-cloud-test\",\"ResourceProvider\":\"Microsoft.Compute\",\"ResourceType\":\"virtualMachines\",\"Source\":\"Azure\"},\"status\":{\"cause\":\"mdeTvm\",\"code\":\"Healthy\",\"description\":\"The machine is onboarded to Microsoft defender vulnerability management\"}},\"type\":\"Microsoft.Security/assessments\"}",
        "outcome": "success",
        "reason": "The machine is onboarded to Microsoft defender vulnerability management",
        "type": [
            "info"
        ]
    },
    "host": {
        "name": "vm-for-defender-cloud-test"
    },
    "input": {
        "type": "cel"
    },
    "message": "Machines should have a vulnerability assessment solution",
    "microsoft_defender_cloud": {
        "assessment": {
            "additional_data": {
                "can_onboard_to_byol": true
            },
            "class": "misconfiguration",
            "display_name": "Machines should have a vulnerability assessment solution",
            "id": "/subscriptions/5abcdef6-1234-5678-8912-e1234abcdef1/resourceGroups/DEFENDER_CLOUD_GROUP/providers/Microsoft.Compute/virtualMachines/vm-for-defender-cloud-test/providers/Microsoft.Security/assessments/fabcdef2-5678-1234-8382-21234567890d",
            "name": "fabcdef2-5678-1234-8382-21234567890d",
            "resource_details": {
                "id": "/subscriptions/5abcdef6-1234-5678-8912-e1234abcdef1/resourceGroups/DEFENDER_CLOUD_GROUP/providers/Microsoft.Compute/virtualMachines/vm-for-defender-cloud-test",
                "native_resource_id": "/subscriptions/5abcdef6-1234-5678-8912-e1234abcdef1/resourceGroups/DEFENDER_CLOUD_GROUP/providers/Microsoft.Compute/virtualMachines/vm-for-defender-cloud-test",
                "resource_name": "vm-for-defender-cloud-test",
                "resource_provider": "Microsoft.Compute",
                "resource_type": "virtualMachines",
                "source": "Azure"
            },
            "status": {
                "cause": "mdeTvm",
                "code": "Healthy",
                "description": "The machine is onboarded to Microsoft defender vulnerability management"
            },
            "type": "Microsoft.Security/assessments"
        }
    },
    "observer": {
        "vendor": "Microsoft Defender for Cloud"
    },
    "related": {
        "hosts": [
            "vm-for-defender-cloud-test"
        ]
    },
    "resource": {
        "id": "/subscriptions/5abcdef6-1234-5678-8912-e1234abcdef1/resourceGroups/DEFENDER_CLOUD_GROUP/providers/Microsoft.Compute/virtualMachines/vm-for-defender-cloud-test",
        "name": "vm-for-defender-cloud-test",
        "sub_type": "virtualMachines",
        "type": "Microsoft.Compute"
    },
    "result": {
        "evaluation": "passed"
    },
    "rule": {
        "name": "Machines should have a vulnerability assessment solution",
        "uuid": "GWgODMK4x9cVQi6d4ipRByaXvpE="
    },
    "tags": [
        "preserve_original_event",
        "preserve_duplicate_custom_fields",
        "forwarded",
        "microsoft_defender_cloud-assessment"
    ]
}

These inputs are used in this integration:

• azure-eventhub
• cel

This integration dataset uses the following APIs:

• Assessments: Azure REST API.
• Sub Assessments: Azure REST API.

The data streams below collect a full snapshot of Microsoft Defender for Cloud assessments on every polling interval, so their backing indices hold one copy of each record per interval. The default polling interval is 24 hours.

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

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_cloud.assessment-default/_lifecycle with the body {"data_retention": "90d"}. Replace default with your namespace.

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.