Set up response to malware scanning

Set up automated responses to move or remove malicious files or to move/ingest clean files to another destination. Select the preferred response option that fits your scenario architecture.

With malware scanning, you can build your automation response using the following scan result options:

• Defender for Cloud security alerts
• Event Grid events
• Blob index tags

Tip

We invite you to explore the malware scanning feature in Defender for Storage through our hands-on lab. Follow the Ninja training instructions for a detailed, step-by-step guide on how to set up and test malware scanning end-to-end, including configuring responses to scanning results. This is part of the 'labs' project that helps customers get ramped up with Microsoft Defender for Cloud and provide hands-on practical experience with its capabilities.

Here are some response options that you can use to automate your response:

Block access to unscanned or malicious files using ABAC (attribute-based access control)

You can block access to malicious and unscanned files with Microsoft Entra Attribute-based access control (ABAC) authorization. It allows you to set conditional access to blobs based on the scanning results, and allow applications and users to access only scanned files that are clean.

To set it up, follow the instructions in the following video.

Delete or move a malicious blob

You can use code or workflow automation to delete or move malicious files to quarantine.

Prepare your environment for delete or move

• Delete the malicious file - Before setting up automated deletion, enabling soft delete on the storage account is recommended. It allows to "undelete" files if there are false positives or in cases where security professionals want to investigate the malicious files.

• Move the malicious file to quarantine - You can move files to a dedicated storage container or storage account that are considered as "quarantine". You might want only certain users, such as a security admin or a SOC analyst, to have permission to access this dedicated container or storage account.

  • Using Microsoft Entra ID to control access to blob storage is considered a best practice. To control access to the dedicated quarantine storage container, you can use container-level role assignments using Microsoft Entra role-based access control (RBAC). Users with storage account-level permissions might still be able to access the "quarantine" container. You can either edit their permissions to be container-level or choose a different approach and move the malicious file to a dedicated storage account.
  • If you must use other methods, such as SAS (shared access signatures) tokens on the protected storage account, it's best practice to move malicious files to another storage account (quarantine). Then, it's best only to grant Microsoft Entra permission to access the quarantined storage account.

Set up automation

Option 1: Logic App based on Microsoft Defender for Cloud security alerts

Logic App based responses are a simple, no-code approach to setting up response. However, the response time is slower than the event-driven code-based approach.

1. Deploy the DeleteBlobLogicApp Azure Resource Manager (ARM) template using the Azure portal.

2. Select the Logic App you deployed.

3. To allow the Logic App to delete blobs from your storage account, add a role assignment:

   1. Go to Identity in the side menu and select Azure role assignments.

      

   2. Add a role assignment in the subscription level with the Storage Blob Data Contributor role.

   3. Create workflow automation for Microsoft Defender for Cloud alerts:

      1. Go to Microsoft Defender for Cloud in the Azure portal.
      2. Go to Workflow automation in the side menu.
      3. Add a new workflow: In the Alert name contains field, fill in Malicious file uploaded to storage account and choose your Logic app in the Actions section.
      4. Select Create.

      

Option 2: Function App based on Event Grid events

A Function App provides high performance with a low latency response time.

1. Create a Function App in the same resource group as your protected storage account.

2. Add a role assignment for the Function app identity.

   1. Go to Identity in the side menu, make sure the System assigned identity status is On, and select Azure role assignments.

   2. Add a role assignment in the subscription or storage account levels with the Storage Blob Data Contributor role.

3. Consume Event Grid events and connect an Azure Function as the endpoint type.

4. When writing the Azure Function code, you can use our premade function sample - MoveMaliciousBlobEventTrigger, or write your own code to copy the blob elsewhere, then delete it from the source.

For each scan result, an event is sent according to the following schema.

Event message structure

The event message is a JSON object that contains key-value pairs that provide detailed information about a malware scanning result. Here's a breakdown of each key in the event message:

• id: A unique identifier for the event.

• subject: A string that describes the resource path of the scanned blob (file) in the storage account.

• data: A JSON object that contains additional information about the event:

  • correlationId: A unique identifier that can be used to correlate multiple events related to the same scan.

  • blobUri: The URI of the scanned blob (file) in the storage account.

  • eTag: The ETag of the scanned blob (file).

    • scanFinishedTimeUtc: The UTC timestamp when the scan was completed.

    • scanResultType: The result of the scan, for example, Malicious or No threats found.

    • scanResultDetails: A JSON object containing details about the scan result:

      1. malwareNamesFound: An array of malware names found in the scanned file.

      2. sha256: The SHA-256 hash of the scanned file.

• eventType: A string that indicates the type of event, in this case, Microsoft.Security.MalwareScanningResult.

• dataVersion: The version number of the data schema.

• metadataVersion: The version number of the metadata schema.

• eventTime: The UTC timestamp when the event was generated.

• topic: The resource path of the Event Grid topic that the event belongs to.

Here's an example of an event message:

{
  "id": "aaaa0000-bb11-2222-33cc-444444dddddd",
  "subject": "storageAccounts/<storage_account_name>/containers/app-logs-storage/blobs/EICAR - simulating malware.txt",
  "data": {
    "correlationId": "aaaa0000-bb11-2222-33cc-444444dddddd",
    "blobUri": "https://<storage_account_name>.blob.core.windows.net/app-logs-storage/EICAR - simulating malware.txt",
    "eTag": "0x000000000000000",
    "scanFinishedTimeUtc": "2023-05-04T11:31:54.0481279Z",
    "scanResultType": "Malicious",
    "scanResultDetails": {
      "malwareNamesFound": [
        "DOS/EICAR_Test_File"
      ],
      "sha256": "AA11BB22CC33DD44EE55FF66AA77BB88CC99DD00"
    }
  },
  "eventType": "Microsoft.Security.MalwareScanningResult",
  "dataVersion": "1.0",
  "metadataVersion": "1",
  "eventTime": "2023-05-04T11:31:54.048375Z",
  "topic": "/subscriptions/<subscription_id>/resourceGroups/<resource_group_name>/providers/Microsoft.EventGrid/topics/<event_grid_topic_name>"
}

By understanding the structure of the event message, you can extract relevant information about the malware scanning result and process it accordingly.

Make your applications and data flows aware of malware scanning scan results

Malware scanning is near real-time, and usually, there's a small time window between the time of the upload and the time of the scan. Because storage is noncompute, there's no risk that malicious files are executed in your storage. The risk is users or applications accessing malicious files and spreading them throughout the organization.

There are a few methods to make your applications and data flows aware of malware scanning scan results. These methods ensure that files can't be accessed or processed before scanning is complete, scan results are consumed, and appropriate actions are taken based on those results.

Applications ingest data based on the scan result

Option 1: Apps checking "Index tag" before processing

One way to get ingested data is to update all the applications that access the storage account. Each application checks the scan result for each file, and if the blob Index tag scan result is no threats found, the application reads the blob.

Option 2: Connect your application to a Webhook in Event Grid events

You can connect your application to a Webhook in Event Grid events and use those events to trigger the relevant processes for files that have no threats found scan results. Learn more about using Webhook event delivery and validating your endpoint.

Use an intermediary storage account as a DMZ

You can set up an intermediary storage account for untrusted content (DMZ) and direct uploading traffic to the DMZ. On the untrusted storage account, enable malware scanning and connect Event Grid and Function App to move only blobs scanned with the "no threat found" result to the destination storage account.

Next step

Learn how to understand results from malware scanning in Microsoft Defender for Storage.