Tilbakemeldinger

Azure security baseline for Logic Apps

  • Artikkel
  • 43 minutter å lese

This security baseline applies guidance from the Azure Security Benchmark version 1.0 to Logic Apps. The Azure Security Benchmark provides recommendations on how you can secure your cloud solutions on Azure. The content is grouped by the security controls defined by the Azure Security Benchmark and the related guidance applicable to Logic Apps.

Note

Controls not applicable to Logic Apps, or for which the responsibility is Microsoft's, have been excluded. To see how Logic Apps completely maps to the Azure Security Benchmark, see the full Logic Apps security baseline mapping file.

Network Security

For more information, see the Azure Security Benchmark: Network Security.

1.1: Protect Azure resources within virtual networks

Guidance: Connectors that run in the "global," multi-tenant Logic Apps service are deployed and managed by Microsoft. These connectors provide triggers and actions for accessing cloud services, on-premises systems, or both, including Office 365, Azure Blob Storage, SQL Server, Dynamics, Salesforce, SharePoint, and more. You can use the AzureConnectors service tag when specifying rules on your network security group or Azure Firewall to allow access to related resources.

For logic apps that need direct access to resources in an Azure virtual network, you can create an integration service environment (ISE) where you can build, deploy, and run your logic apps on dedicated resources. Some Azure virtual networks use private endpoints (Azure Private Link) for providing access to Azure PaaS services, such as Azure Storage, Azure Cosmos DB, Azure SQL Database, partner services, or customer services that are hosted on Azure. If your logic apps need access to virtual networks that use private endpoints, you must create, deploy, and run those logic apps inside an ISE.

When you create your ISE, you can choose to use either internal or external access endpoints. Your selection determines whether request or webhook triggers on logic apps in your ISE can receive calls from outside your virtual network. Internal and external access endpoints also affect whether you can view your logic app's run history, including the inputs and outputs for a run, from inside or outside your virtual network.

Make sure that all virtual network subnet deployments related to your ISE have a network security group applied with network access controls specific to your application's trusted ports and sources. When you deploy your logic apps in an ISE, use Private Link. Azure Private Link enables you to access Azure PaaS Services and Azure hosted customer-owned/partner services over a private endpoint in your virtual network. Alternatively, if you have a specific use case, you can meet this requirement by implementing Azure Firewall. To help reduce complexity when you set up security rules, use service tags that represent groups of IP address prefixes for a specific Azure service.

Responsibility: Shared

Microsoft Defender for Cloud monitoring: None

1.2: Monitor and log the configuration and traffic of virtual networks, subnets, and network interfaces

Guidance: If you run logic apps in an integration service environment (ISE) that uses an external access point, you can use a network security group (NSG) to reduce the risk of data exfiltration. Enable NSG flow logs and send logs to an Azure Storage Account for traffic audit. You can also send NSG flow logs to a Log Analytics workspace and use Traffic Analytics to provide insights into traffic flow in your Azure cloud. Some advantages of Traffic Analytics are the ability to visualize network activity and identify hot spots, identify security threats, understand traffic flow patterns, and pinpoint network misconfigurations.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

1.4: Deny communications with known-malicious IP addresses

Guidance: If your logic app uses a request-based trigger, which receives incoming calls or requests, such as the Request or Webhook trigger, you can limit access so that only authorized clients can call your logic app.

If you are running logic apps in an integration service environment (ISE), enable DDoS Protection Standard on the virtual network associated with your ISE to guard against DDoS attacks. Use Microsoft Defender for Cloud Integrated Threat Intelligence to deny communications with known malicious or unused Internet IP addresses.

Deploy Azure Firewall at each of the organization's network boundaries with Threat Intelligence enabled and configured to "Alert and deny" for malicious network traffic.

Use Microsoft Defender for Cloud Just In Time Network access to configure NSGs to limit exposure of endpoints to approved IP addresses for a limited period.

Use Microsoft Defender for Cloud Adaptive Network Hardening to recommend NSG configurations that limit ports and source IPs based on actual traffic and threat intelligence.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

1.5: Record network packets

Guidance: If you are run logic apps in an integration service environment (ISE) that uses an external access point, you can use a network security group (NSG) to reduce the risk of data exfiltration. Enable NSG flow logs and send logs to an Azure Storage Account for traffic audit. You can also send NSG flow logs to a Log Analytics workspace and use Traffic Analytics to provide insights into traffic flow in your Azure cloud. Some advantages of Traffic Analytics are the ability to visualize network activity and identify hot spots, identify security threats, understand traffic flow patterns, and pinpoint network misconfigurations.

To provide further protection and information on network traffic, you can refer to access logs, which are generated only if you've enabled them on each Application Gateway instance. You can use this log to view Application Gateway access patterns and analyze important information. This includes the caller's IP, requested URL, response latency, return code, and bytes in and out.

Otherwise, you can leverage a third-party solution from the marketplace to satisfy this requirement.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

1.6: Deploy network-based intrusion detection/intrusion prevention systems (IDS/IPS)

Guidance: Select an offer from the Azure Marketplace that supports IDS/IPS functionality with payload inspection capabilities. If intrusion detection and/or prevention based on payload inspection is not a requirement, Azure Firewall with Threat Intelligence can be used. Azure Firewall Threat intelligence-based filtering can alert and deny traffic to and from known malicious IP addresses and domains. The IP addresses and domains are sourced from the Microsoft Threat Intelligence feed.

Deploy the firewall solution of your choice at each of your organization's network boundaries to detect and/or deny malicious traffic.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

1.7: Manage traffic to web applications

Guidance: If you are running logic apps in an integration service environment (ISE), deploy Azure Application Gateway.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

1.8: Minimize complexity and administrative overhead of network security rules

Guidance: For resources that need access to your Azure Logic Apps instances, use virtual network service tags to define network access controls on network security groups or Azure Firewall. You can use service tags in place of specific IP addresses when creating security rules. By specifying the service tag name (e.g., LogicApps, LogicAppsManagement) in the appropriate source or destination field of a rule, you can allow or deny the traffic for the corresponding service. Microsoft manages the address prefixes encompassed by the service tag and automatically updates the service tag as addresses change.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

1.9: Maintain standard security configurations for network devices

Guidance: Define and implement standard security configurations for network resources related to your Azure Logic Apps instances with Azure Policy. Use Azure Policy aliases in the "Microsoft.Logic" and "Microsoft.Network" namespaces to create custom policies to audit or enforce the network configuration of your Azure Logic apps instances. You may also make use of built-in policy definitions such as:

  • Diagnostic logs in Logic Apps should be enabled

  • DDoS Protection Standard should be enabled

You may also use Azure Blueprints to simplify large-scale Azure deployments by packaging key environment artifacts, such as Azure Resource Manager templates, Azure role-based access control (Azure RBAC), and policies, in a single blueprint definition. Easily apply the blueprint to new subscriptions and environments, and fine-tune control and management through versioning.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

1.10: Document traffic configuration rules

Guidance: For individual NSG rules, use the "Description" field to specify business need and/or duration (etc.) for any rules that allow traffic to/from a network.

Use any of the built-in Azure Policy definitions related to tagging, such as "Require tag and its value" to ensure that all resources are created with Tags and to notify you of existing untagged resources.

You may use Azure PowerShell or Azure CLI to look up or perform actions on resources based on their Tags.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

1.11: Use automated tools to monitor network resource configurations and detect changes

Guidance: Use the Azure Activity log to monitor network resource configurations and detect changes for network resources related to your Azure Logic Apps instances. Create alerts within Azure Monitor that will trigger when changes to critical network resources take place.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

Logging and Monitoring

For more information, see the Azure Security Benchmark: Logging and Monitoring.

2.2: Configure central security log management

Guidance: To get richer debugging information about your logic apps during runtime, you can set up and use Azure Monitor logs to record and store information about runtime data and events, such as trigger events, run events, and action events in a Log Analytics workspace. Azure Monitor helps you monitor your cloud and on-premises environments so that you can more easily maintain their availability and performance. By using Azure Monitor logs, you can create log queries that help you collect and review this information. You can also use this diagnostics data with other Azure services, such as Azure Storage and Azure Event Hubs.

Alternatively, you may enable and on-board data to Microsoft Sentinel or a third-party SIEM.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

2.3: Enable audit logging for Azure resources

Guidance: To get richer debugging information about your logic apps during runtime, you can set up and use Azure Monitor logs to record and store information about runtime data and events, such as trigger events, run events, and action events in a Log Analytics workspace. Azure Monitor helps you monitor your cloud and on-premises environments so that you can more easily maintain their availability and performance. By using Azure Monitor logs, you can create log queries that help you collect and review this information. You can also use this diagnostics data with other Azure services, such as Azure Storage and Azure Event Hubs.

Alternatively, you may enable and on-board data to Microsoft Sentinel or a third-party SIEM.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: The Azure Security Benchmark is the default policy initiative for Microsoft Defender for Cloud and is the foundation for Microsoft Defender for Cloud's recommendations. The Azure Policy definitions related to this control are enabled automatically by Microsoft Defender for Cloud. Alerts related to this control may require a Microsoft Defender plan for the related services.

Azure Policy built-in definitions - Microsoft.Logic:

Name
(Azure portal)		 Description Effect(s) Version
(GitHub)
Resource logs in Logic Apps should be enabled Audit enabling of resource logs. This enables you to recreate activity trails to use for investigation purposes; when a security incident occurs or when your network is compromised AuditIfNotExists, Disabled 5.0.0

2.5: Configure security log storage retention

Guidance: After you create and run a logic app, you can check that logic app's run status, runs history, trigger history, and performance. For real-time event monitoring and richer debugging, set up diagnostics logging for your logic app by using Azure Monitor logs. This Azure service helps you monitor your cloud and on-premises environments so that you can more easily maintain their availability and performance. You can then find and view events, such as trigger events, run events, and action events. By storing this information in Azure Monitor logs, you can create log queries that help you find and analyze this information. You can also use this diagnostic data with other Azure services, such as Azure Storage and Azure Event Hubs.

In Azure Monitor, set log retention period for logs associated with your Azure Logic Apps instances according to your organization's compliance regulations.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

2.6: Monitor and review logs

Guidance: To set up logging for your logic app, you can enable Log Analytics when you create your logic app, or you can install the Logic Apps Management solution in your Log Analytics workspace for existing logic apps. This solution provides aggregated information for your logic app runs and includes specific details such as status, execution time, resubmission status, and correlation IDs. Then, to enable logging and creating queries for this information, set up Azure Monitor logs.

You can also enable Azure Activity Log diagnostic settings and send the logs to a Log Analytics workspace. Perform queries in Log Analytics to search terms, identify trends, analyze patterns, and provide many other insights based on the Activity Log Data that may have been collected for Azure Logic Apps.

Alternatively, you may enable and on-board data to Microsoft Sentinel or a third-party SIEM.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

2.7: Enable alerts for anomalous activities

Guidance: Use Microsoft Defender for Cloud with Log Analytics for monitoring and alerting on anomalous activity found in security logs and events.

Alternatively, you may enable and on-board data to Microsoft Sentinel.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

Identity and Access Control

For more information, see the Azure Security Benchmark: Identity and Access Control.

3.1: Maintain an inventory of administrative accounts

Guidance: Azure Active Directory (Azure AD) has built-in roles that must be explicitly assigned and are queryable. Use the Azure AD PowerShell module to perform ad hoc queries to discover accounts that are members of administrative groups.

To easily access other resources that are protected by Azure AD and authenticate your identity without signing in, your logic app can use a managed identity (formerly Managed Service Identity or MSI), rather than credentials or secrets. Azure manages this identity for you and helps secure your credentials because you don't have to provide or rotate secrets.

Every request endpoint on a logic app has a Shared Access Signature (SAS) in the endpoint's URL. If you share the endpoint URL for a request-based trigger with other parties, you can generate callback URLs that use specific keys and have expiration dates. That way, you can seamlessly roll keys or restrict access to triggering your logic app based on a specific timespan.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

3.2: Change default passwords where applicable

Guidance: Azure Active Directory (Azure AD) and Azure Logic Apps do not have the concept of default passwords.

If basic authentication is being used, you will need to specify a username and password. When creating these credentials, ensure that you configure a strong password for authentication.

If you are using Infrastructure as Code, avoid storing passwords in code and instead use Azure Key Vault to store and retrieve credentials.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

3.3: Use dedicated administrative accounts

Guidance: Create standard operating procedures around the use of dedicated administrative accounts. Use Microsoft Defender for Cloud Identity and Access Management to monitor the number of administrative accounts.

Additionally, to help you keep track of dedicated administrative accounts, you may use recommendations from Microsoft Defender for Cloud or built-in Azure Policies, such as:

  • There should be more than one owner assigned to your subscription
  • Deprecated accounts with owner permissions should be removed from your subscription
  • External accounts with owner permissions should be removed from your subscription

For more information, see the following references:

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

3.4: Use Azure Active Directory single sign-on (SSO)

Guidance: Use an Azure app registration (service principal) to retrieve a token that can be used to interact with your Recovery Services vaults via API calls.

Many connectors also require that you first create a connection to the target service or system and provide authentication credentials or other configuration details before you can use a trigger or action in your logic app. For example, you must authorize a connection to a Twitter account for accessing data or to post on your behalf.

For connectors that use Azure Active Directory (Azure AD) OAuth, creating a connection means signing into the service, such as Office 365, Salesforce, or GitHub, where your access token is encrypted and securely stored in an Azure secret store. Other connectors, such as FTP and SQL, require a connection that has configuration details, such as the server address, username, and password. These connection configuration details are also encrypted and securely stored.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

3.5: Use multi-factor authentication for all Azure Active Directory-based access

Guidance: Enable Azure Active Directory (Azure AD) multifactor authentication and follow Microsoft Defender for Cloud Identity and Access Management recommendations.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

3.6: Use secure, Azure-managed workstations for administrative tasks

Guidance: Use privileged access workstations (PAW) with multifactor authentication configured to log into and configure Azure resources.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

3.7: Log and alert on suspicious activities from administrative accounts

Guidance: Use Azure Active Directory (Azure AD) Privileged Identity Management (PIM) for generation of logs and alerts when suspicious or unsafe activity occurs in the environment.

In addition, use Azure AD risk detections to view alerts and reports on risky user behavior.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

3.8: Manage Azure resources from only approved locations

Guidance: Use Conditional Access Named Locations to allow access to the Azure portal from only specific logical groupings of IP address ranges or countries/regions.

Additionally, every request endpoint on a logic app has a Shared Access Signature (SAS) in the endpoint's URL. You can restrict your logic app to accept requests only from certain IP addresses.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

3.9: Use Azure Active Directory

Guidance: Use Azure Active Directory (Azure AD) as the central authentication and authorization system for your Azure Logic Apps instances. Azure AD protects data by using strong encryption for data at rest and in transit. Azure AD also salts, hashes, and securely stores user credentials.

Where there is support in Logic Apps, use a managed identity to easily access other resources that are protected by Azure AD and authenticate your identity without signing in, rather than credentials or secrets. Azure manages this identity for you and helps secure your credentials because you don't have to provide or rotate secrets.

Azure Logic Apps supports both system-assigned and user-assigned managed identities. Your logic app can use either the system-assigned identity or a single user-assigned identity, which you can share across a group of logic apps, but not both. Currently, only specific built-in triggers and actions support managed identities, not managed connectors or connections, such as:

  • HTTP
  • Azure Functions
  • Azure API Management
  • Azure App Services

For more information, see the following references:

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

3.10: Regularly review and reconcile user access

Guidance: Azure Active Directory (Azure AD) provides logs to help you discover stale accounts. In addition, use Azure Identity Access Reviews to efficiently manage group memberships, access to enterprise applications, and role assignments. User access can be reviewed on a regular basis to make sure only the right Users have continued access.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

3.11: Monitor attempts to access deactivated credentials

Guidance: Use Azure Active Directory (Azure AD) as the central authentication and authorization system for your Azure Logic Apps instances. Azure AD protects data by using strong encryption for data at rest and in transit. Azure AD also salts, hashes, and securely stores user credentials.

You have access to Azure AD sign-in activity, audit and risk event log sources, which allow you to integrate with Microsoft Sentinel or a third-party SIEM.

You can streamline this process by creating diagnostic settings for Azure AD user accounts and sending the audit logs and sign-in logs to a Log Analytics workspace. You can configure desired log alerts within Log Analytics.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

3.12: Alert on account sign-in behavior deviation

Guidance: Use Azure Active Directory (Azure AD) Risk and Identity Protection features to configure automated responses to detected suspicious actions related to user identities. You can also ingest data into Microsoft Sentinel for further investigation.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

Data Protection

For more information, see the Azure Security Benchmark: Data Protection.

4.1: Maintain an inventory of sensitive Information

Guidance: Use tags to assist in tracking Azure resources that store or process sensitive information.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

4.2: Isolate systems storing or processing sensitive information

Guidance: Connectors that run in the "global," multi-tenant Logic Apps service are deployed and managed by Microsoft. These connectors provide triggers and actions for accessing cloud services, on-premises systems, or both, including Office 365, Azure Blob Storage, SQL Server, Dynamics, Salesforce, SharePoint, and more.

For logic apps that need direct access to resources in an Azure virtual network, you can create an integration service environment (ISE) where you can build, deploy, and run your logic apps on dedicated resources. Some Azure virtual networks use private endpoints (Azure Private Link) for providing access to Azure PaaS services, such as Azure Storage, Azure Cosmos DB, or Azure SQL Database, partner services, or customer services that are hosted on Azure. If your logic apps need access to virtual networks that use private endpoints, you must create, deploy, and run those logic apps inside an ISE.

When you create your ISE, you can choose to use either internal or external access endpoints. Your selection determines whether request or webhook triggers on logic apps in your ISE can receive calls from outside your virtual network.

Additionally, implement isolation using separate subscriptions and management groups for individual security domains such as environment type and data sensitivity level. You can restrict the level of access to your Azure resources that your applications and enterprise environments demand. You can control access to Azure resources via Azure role-based access control (Azure RBAC).

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

4.3: Monitor and block unauthorized transfer of sensitive information

Guidance: Currently not available; data identification, classification, and loss prevention features are not yet available for Azure Logic Apps.

Leverage a third-party solution from Azure Marketplace on network perimeters that monitors for unauthorized transfer of sensitive information and blocks such transfers while alerting information security professionals.

Microsoft manages the underlying infrastructure for Azure Logic Apps and has implemented strict controls to prevent the loss or exposure of customer data.

Responsibility: Shared

Microsoft Defender for Cloud monitoring: None

4.4: Encrypt all sensitive information in transit

Guidance: Encrypt all sensitive information in transit. In Azure Logic Apps, all the data during a logic app run is encrypted during transit by using Transport Layer Security (TLS) and at rest. When you view your logic app's run history, Logic Apps authenticates your access and then provides links to the inputs and outputs for the requests and responses for each run. However, for actions that handle any passwords, secrets, keys, or other sensitive information, you want to prevent others from viewing and accessing that data. For example, if your logic app gets a secret from Azure Key Vault to use when authenticating an HTTP action, you want to hide that secret from view.

The Request trigger supports only Transport Layer Security (TLS) 1.2 for inbound requests. Make sure that any clients connecting to your Azure resources are able to negotiate TLS 1.2 or greater. Outbound calls using the HTTP connector support Transport Layer Security (TLS) 1.0, 1.1, and 1.2.

Follow Microsoft Defender for Cloud recommendations for encryption at rest and encryption in transit, where applicable.

Responsibility: Shared

Microsoft Defender for Cloud monitoring: None

4.5: Use an active discovery tool to identify sensitive data

Guidance: In Azure Logic Apps, many triggers and actions have settings that you can enable to secure inputs, outputs, or both by obscuring that data from a logic app's run history.

Microsoft manages the underlying infrastructure for Azure Logic Apps and has implemented strict controls to prevent the loss or exposure of customer data.

Responsibility: Shared

Microsoft Defender for Cloud monitoring: None

4.6: Use Azure RBAC to control access to resources

Guidance: You can permit only specific users or groups to run specific tasks, such as managing, editing, and viewing logic apps. To control their permissions, use Azure role-based access control (Azure RBAC) so that you can assign customized or built-in roles to the members in your Azure subscription:

  • Logic App Contributor: Lets you manage logic apps, but you can't change access to them.
  • Logic App Operator: Lets you read, enable, and disable logic apps, but you can't edit or update them.

To prevent others from changing or deleting your logic app, you can use Azure Resource Lock. This capability prevents others from changing or deleting production resources.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

4.8: Encrypt sensitive information at rest

Guidance: Azure Logic Apps relies on Azure Storage to store and automatically encrypt data at rest. This encryption protects your data and helps you meet your organizational security and compliance commitments. By default, Azure Storage uses Microsoft-managed keys to encrypt your data.

When you create an integration service environment (ISE) for hosting your logic apps, and you want more control over the encryption keys used by Azure Storage, you can set up, use, and manage your own key by using Azure Key Vault. This capability is also known as "Bring Your Own Key" (BYOK), and your key is called a "customer-managed key".

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

4.9: Log and alert on changes to critical Azure resources

Guidance: Use Azure Monitor with the Azure Activity log to create alerts for when changes take place in Azure Logic Apps as well as other critical or related resources.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

Inventory and Asset Management

For more information, see the Azure Security Benchmark: Inventory and Asset Management.

6.1: Use automated asset discovery solution

Guidance: Use Azure Resource Graph to query/discover all resources (such as compute, storage, network, ports, and protocols etc.) within your subscription(s). Ensure appropriate (read) permissions in your tenant and enumerate all Azure subscriptions as well as resources within your subscriptions.

Although classic Azure resources may be discovered via Resource Graph, it is highly recommended that you create and use Azure Resource Manager resources going forward.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

6.2: Maintain asset metadata

Guidance: Apply tags to Azure resources giving metadata to logically organize them into a taxonomy.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

6.3: Delete unauthorized Azure resources

Guidance: Use tagging, management groups, and separate subscriptions, where appropriate, to organize and track Azure resources. Reconcile inventory on a regular basis and ensure unauthorized resources are deleted from the subscription in a timely manner.

In addition, use Azure Policy to put restrictions on the type of resources that can be created in customer subscription(s) using the following built-in policy definitions:

  • Not allowed resource types
  • Allowed resource types

For more information, see the following references:

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

6.4: Define and maintain inventory of approved Azure resources

Guidance: Create an inventory of approved Azure resources (such as connectors) and approved software for compute resources as per your organizational needs.

Note: Due to Google's data and privacy policies, you can use the Gmail connector only with Google-approved services. This situation is evolving and might affect other Google connectors in the future.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

6.5: Monitor for unapproved Azure resources

Guidance: Use Azure Policy to put restrictions on the type of resources that can be created in your subscription(s).

Use Azure Resource Graph to query/discover resources within their subscription(s). Ensure that all Azure resources present in the environment are approved.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

6.9: Use only approved Azure services

Guidance: Use Azure Policy to put restrictions on the type of resources that can be created in customer subscription(s) using the following built-in policy definitions:

  • Not allowed resource types
  • Allowed resource types

For more information, see the following references:

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

6.10: Maintain an inventory of approved software titles

Guidance: Not applicable; this recommendation is intended for compute resources.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

6.11: Limit users' ability to interact with Azure Resource Manager

Guidance: Configure Azure Conditional Access to limit users' ability to interact with Azure Resource Manager by configuring "Block access" for the "Microsoft Azure Management" App.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

6.12: Limit users' ability to execute scripts within compute resources

Guidance: Not applicable; this recommendation is intended for compute resources.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

6.13: Physically or logically segregate high risk applications

Guidance: Resources related to your Logic Apps that are required for business operations, but may incur higher risk for the organization, should be isolated within its own virtual machine and/or virtual network and sufficiently secured with either an Azure Firewall or Network Security Group.

Logic Apps that are required for business operations, but may incur higher risk for the organization, should be isolated wherever possible via separate resource groups with specific permissions and Azure RBAC boundaries.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

Secure Configuration

For more information, see the Azure Security Benchmark: Secure Configuration.

7.1: Establish secure configurations for all Azure resources

Guidance: Define and implement standard security configurations for your Azure Logic Apps instances with Azure Policy. Use Azure Policy aliases in the "Microsoft.Logic" namespace to create custom policies to audit or enforce the configuration of your Logic Apps instances. For example, you can block others from creating or using connections to resources where you want to restrict access.

Additionally, Azure Resource Manager has the ability to export the template in JavaScript Object Notation (JSON), which should be reviewed to ensure that the configurations meet / exceed the security requirements for your organization.

Also, use secured parameters to protect sensitive data and secrets.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

7.2: Establish secure operating system configurations

Guidance: Not applicable; this guideline is intended for compute resources.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

7.3: Maintain secure Azure resource configurations

Guidance: Use Azure Policy [deny] and [deploy if not exist] to enforce secure settings across your Azure resources.

Define and implement standard security configurations for your Azure Logic Apps instances with Azure Policy. Use Azure Policy aliases in the "Microsoft.Logic" namespace to create custom policies to audit or enforce the configuration of your Logic Apps instances. For example, you can block others from creating or using connections to resources where you want to restrict access.

Additionally, Azure Resource Manager has the ability to export the template in JavaScript Object Notation (JSON), which should be reviewed to ensure that the configurations meet / exceed the security requirements for your organization.

Also, ensure that you secure data in run history by using obfuscation.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

7.4: Maintain secure operating system configurations

Guidance: Not applicable; this guideline is intended for compute resources.

Responsibility: Shared

Microsoft Defender for Cloud monitoring: None

7.5: Securely store configuration of Azure resources

Guidance: If using custom Azure Policy definitions, use Azure DevOps or Azure Repos to securely store and manage your code.

Additionally, Azure Resource Manager has the ability to export the template in JavaScript Object Notation (JSON), which should be reviewed to ensure that the configurations meet / exceed the security requirements for your organization.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

7.6: Securely store custom operating system images

Guidance: Not applicable; this guideline is intended for compute resources.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

7.7: Deploy configuration management tools for Azure resources

Guidance: Use built-in Azure Policy definitions as well as Azure Policy aliases in the "Microsoft.Logic" namespace to create custom policies to alert, audit, and enforce system configurations. Use Azure Policy aliases to create custom policies to audit or enforce the network configuration of your Azure resources. Additionally, develop a process and pipeline for managing policy exceptions.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

7.8: Deploy configuration management tools for operating systems

Guidance: Not applicable; this guideline is intended for compute resources.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

7.9: Implement automated configuration monitoring for Azure resources

Guidance: Use built-in Azure Policy definitions as well as Azure Policy aliases in the "Microsoft.Logic" namespace to create custom policies to alert, audit, and enforce system configurations. Use Azure Policy [audit], [deny], and [deploy if not exist] to automatically enforce configurations for your Azure resources.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

7.10: Implement automated configuration monitoring for operating systems

Guidance: Not applicable; this guideline is intended for compute resources.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

7.11: Manage Azure secrets securely

Guidance: Secure inputs and outputs in logic app run history by using obfuscation. If you deploy across different environments, consider parameterizing the values in your logic app's workflow definition that vary based on those environments. That way, you can avoid hard-coded data by using an Azure Resource Manager template to deploy your logic app, protect sensitive data by defining secured parameters, and pass that data as separate inputs through the template's parameters by using a parameter file. You can use Key Vault to store sensitive data and use secured template parameters that retrieve those values from Key Vault at deployment. You can then reference the key vault and secrets in your parameter file.

When you create an integration service environment (ISE) for hosting your logic apps, and you want more control over the encryption keys used by Azure Storage, you can set up, use, and manage your own key by using Azure Key Vault. This capability is also known as "Bring Your Own Key" (BYOK), and your key is called a "customer-managed key".

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

7.12: Manage identities securely and automatically

Guidance: To easily access other resources that are protected by Azure Active Directory (Azure AD) and authenticate your identity without signing in, your logic app can use a managed identity (formerly Managed Service Identity or MSI), rather than credentials or secrets. Azure manages this identity for you and helps secure your credentials because you don't have to provide or rotate secrets.

Currently, only specific built-in triggers and actions support managed identities, not managed connectors or connections, such as:

  • HTTP
  • Azure Functions
  • Azure API Management
  • Azure App Services

For more information, see the following references:

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

7.13: Eliminate unintended credential exposure

Guidance: Secure inputs and outputs in logic app run history by using obfuscation. If you deploy across different environments, consider parameterizing the values in your logic app's workflow definition that vary based on those environments. That way, you can avoid hard-coded data by using an Azure Resource Manager template to deploy your logic app, protect sensitive data by defining secured parameters, and pass that data as separate inputs through the template's parameters by using a parameter file. You can use Key Vault to store sensitive data and use secured template parameters that retrieve those values from Key Vault at deployment. You can then reference the key vault and secrets in your parameter file.

You can also implement Credential Scanner to identify credentials within code. Credential Scanner will also encourage moving discovered credentials to more secure locations such as Azure Key Vault.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

Malware Defense

For more information, see the Azure Security Benchmark: Malware Defense.

8.1: Use centrally-managed anti-malware software

Guidance: Not applicable; this recommendation is intended for compute resources. Microsoft anti-malware is enabled on the underlying host that supports Azure services (for example, Azure Logic Apps), however it does not run on customer content.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

8.2: Pre-scan files to be uploaded to non-compute Azure resources

Guidance: Microsoft Anti-malware is enabled on the underlying host that supports Azure services (for example, Azure Backup), however it does not run on your content.

Pre-scan any files being uploaded to non-compute Azure resources, such as App Service, Data Lake Storage, Blob Storage, etc.

Use Microsoft Defender for Cloud's Threat detection for data services to detect malware uploaded to storage accounts.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

8.3: Ensure anti-malware software and signatures are updated

Guidance: Not applicable; this guideline is intended for compute resources.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

Data Recovery

For more information, see the Azure Security Benchmark: Data Recovery.

9.1: Ensure regular automated back-ups

Guidance: Implement a disaster recovery (DR) solution in place so that you can protect data, quickly restore the resources that support critical business functions, and keep operations running to maintain business continuity (BC).

This disaster recovery strategy focuses on setting up your primary logic app to fail over onto a standby or backup logic app in an alternate location where Azure Logic Apps is also available. That way, if the primary suffers losses, disruptions, or failures, the secondary can take on the work. This strategy requires that your secondary logic app and dependent resources are already deployed and ready in the alternate location.

Additionally, you should expand your logic app's underlying workflow definition into an Azure Resource Manager template. This template defines the infrastructure, resources, parameters, and other information for provisioning and deploying your logic app.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

9.2: Perform complete system backups and backup any customer-managed keys

Guidance: Implement a disaster recovery (DR) solution in place so that you can protect data, quickly restore the resources that support critical business functions, and keep operations running to maintain business continuity (BC).

This disaster recovery strategy focuses on setting up your primary logic app to fail over onto a standby or backup logic app in an alternate location where Azure Logic Apps is also available. That way, if the primary suffers losses, disruptions, or failures, the secondary can take on the work. This strategy requires that your secondary logic app and dependent resources are already deployed and ready in the alternate location.

Additionally, you should expand your logic app's underlying workflow definition into an Azure Resource Manager template. This template defines the infrastructure, resources, parameters, and other information for provisioning and deploying your logic app.

Every request endpoint on a logic app has a Shared Access Signature (SAS) in the endpoint's URL. If you are using Azure Key Vault to store your secrets, ensure regular automated backups of your keys and URLs.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

9.3: Validate all backups including customer-managed keys

Guidance: Your disaster recovery strategy should focus on setting up your primary logic app to fail over onto a standby or backup logic app in an alternate location where Azure Logic Apps is also available. That way, if the primary suffers losses, disruptions, or failures, the secondary can take on the work. This strategy requires that your secondary logic app and dependent resources are already deployed and ready in the alternate location.

Test restoration of backed up customer-managed keys. Note that this applies to Logic Apps running on integration service environments (ISE) only.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

9.4: Ensure protection of backups and customer-managed keys

Guidance: Your disaster recovery strategy should focus on setting up your primary logic app to fail over onto a standby or backup logic app in an alternate location where Azure Logic Apps is also available. That way, if the primary suffers losses, disruptions, or failures, the secondary can take on the work. This strategy requires that your secondary logic app and dependent resources are already deployed and ready in the alternate location.

Protect backed up customer-managed keys. Note that this applies to Logic Apps running on integration service environments (ISE) only.

Enable Soft-Delete and purge protection in Key Vault to protect keys against accidental or malicious deletion.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

Incident Response

For more information, see the Azure Security Benchmark: Incident Response.

10.1: Create an incident response guide

Guidance: Build out an incident response guide for your organization. Ensure that there are written incident response plans that define all roles of personnel as well as phases of incident handling/management from detection to post-incident review.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

10.2: Create an incident scoring and prioritization procedure

Guidance: Microsoft Defender for Cloud assigns a severity to each alert to help you prioritize which alerts should be investigated first. The severity is based on how confident Microsoft Defender for Cloud is in the finding or the metric used to issue the alert as well as the confidence level that there was malicious intent behind the activity that led to the alert.

Additionally, clearly mark subscriptions (for ex. production, non-prod) using tags and create a naming system to clearly identify and categorize Azure resources, especially those processing sensitive data. It is your responsibility to prioritize the remediation of alerts based on the criticality of the Azure resources and environment where the incident occurred.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

10.3: Test security response procedures

Guidance: Conduct exercises to test your systems’ incident response capabilities on a regular cadence to help protect your Azure resources. Identify weak points and gaps and revise plan as needed.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

10.4: Provide security incident contact details and configure alert notifications for security incidents

Guidance: Security incident contact information will be used by Microsoft to contact you if the Microsoft Security Response Center (MSRC) discovers that your data has been accessed by an unlawful or unauthorized party. Review incidents after the fact to ensure that issues are resolved.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

10.5: Incorporate security alerts into your incident response system

Guidance: Export your Microsoft Defender for Cloud alerts and recommendations using the Continuous Export feature to help identify risks to Azure resources. Continuous Export allows you to export alerts and recommendations either manually or in an ongoing, continuous fashion. You may use the Microsoft Defender for Cloud data connector to stream the alerts to Microsoft Sentinel.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

10.6: Automate the response to security alerts

Guidance: Use the Workflow Automation feature in Microsoft Defender for Cloud to automatically trigger responses via "Logic Apps" on security alerts and recommendations to protect your Azure resources.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

Penetration Tests and Red Team Exercises

For more information, see the Azure Security Benchmark: Penetration Tests and Red Team Exercises.

11.1: Conduct regular penetration testing of your Azure resources and ensure remediation of all critical security findings

Guidance: Follow the Microsoft Rules of Engagement to ensure your Penetration Tests are not in violation of Microsoft policies. Use Microsoft’s strategy and execution of Red Teaming and live site penetration testing against Microsoft-managed cloud infrastructure, services, and applications.

Responsibility: Shared

Microsoft Defender for Cloud monitoring: None

Next steps