{"id":35176,"date":"2020-05-26T18:00:49","date_gmt":"2020-05-26T18:00:49","guid":{"rendered":"https:\/\/www.microsoft.com\/security\/blog\/?p=91142"},"modified":"2020-05-26T18:00:49","modified_gmt":"2020-05-26T18:00:49","slug":"zero-trust-deployment-guide-for-devices","status":"publish","type":"post","link":"https:\/\/www.threatshub.org\/blog\/zero-trust-deployment-guide-for-devices\/","title":{"rendered":"Zero Trust Deployment Guide for devices"},"content":{"rendered":"

The modern enterprise has an incredible diversity of endpoints accessing their data. This creates a massive attack surface, and as a result, endpoints can easily become the weakest link in your Zero Trust security strategy.<\/p>\n

Whether a device is a personally<\/strong> owned BYOD device or a corporate-owned<\/strong> and fully managed device, we want to have visibility into the endpoints accessing our network, and ensure we\u2019re only allowing healthy and compliant devices to access corporate resources. Likewise, we are concerned about the health and trustworthiness of mobile and desktop apps that run on those endpoints. We want to ensure those apps are also healthy and compliant and that they prevent corporate data from leaking to consumer apps or services through malicious intent or accidental means.<\/p>\n

Get visibility into device health and compliance<\/h3>\n

Gaining visibility into the endpoints accessing your corporate resources is the first step in your Zero Trust device strategy. Typically, companies are proactive in protecting PCs from vulnerabilities and attacks, while mobile devices often go unmonitored and without protections. To help limit risk exposure, we need to monitor every endpoint to ensure it has a trusted identity, has security policies applied, and the risk level for things like malware or data exfiltration has been measured, remediated, or deemed acceptable. For example, if a personal device is jailbroken, we can block access to ensure that enterprise applications are not exposed to known vulnerabilities.<\/p>\n

    \n
  1. To ensure you have a trusted identity for an endpoint, register your devices with Azure Active Directory<\/a> (Azure AD). Devices registered in Azure AD can be managed using tools like Microsoft Endpoint Manager, Microsoft Intune, System Center Configuration Manager, Group Policy (hybrid Azure AD join), or other supported third-party tools (using the Intune Compliance API + Intune license). Once you\u2019ve configured your policy, share the following guidance to help users get their devices registered\u2014new Windows 10 devices<\/a>, existing Windows 10 devices<\/a>, and personal devices<\/a>.<\/li>\n
  2. Once we have identities for all the devices accessing corporate resources, we want to ensure that they meet the minimum security requirements set by your organization before access is granted. With Microsoft Intune, we can set compliance rules<\/a> for devices before granting access to corporate resources. We also recommend setting remediation actions<\/a> for noncompliant devices, such as blocking a noncompliant device or offering the user a grace period to get compliant.<\/li>\n<\/ol>\n

    Restricting access from vulnerable and compromised devices<\/strong><\/p>\n

    Once we know the health and compliance status of an endpoint through Intune enrollment, we can use Azure AD Conditional Access to enforce more granular, risk-based access policies. For example, we can ensure that no vulnerable devices (like devices with malware) are allowed access until remediated, or ensure logins from unmanaged devices only receive limited access to corporate resources, and so on.<\/p>\n

      \n
    1. To get started, we recommend only allowing access to your cloud apps from Intune-managed, domain-joined, and\/or compliant devices<\/a>. These are baseline security requirements that every device will have to meet before access is granted.<\/li>\n
    2. Next, we can configure device-based Conditional Access policies<\/a> in Intune to enforce restrictions based on device health and compliance. This will allow us to enforce more granular access decisions and fine-tune the Conditional Access policies based on your organization\u2019s risk appetite. For example, we might want to exclude certain device platforms from accessing specific apps.<\/li>\n
    3. Finally, we want to ensure that your endpoints and apps are protected from malicious threats. This will help ensure your data is better-protected and users are at less risk of getting denied access due to device health and\/or compliance issues. We can integrate data from Microsoft Defender Advanced Threat Protection (ATP), or other Mobile Threat Defense (MTD) vendors, as an information source for device compliance policies and device Conditional Access rules. Options below:\n<\/li>\n<\/ol>\n

      Enforcing security policies on mobile devices and apps<\/strong><\/p>\n

      We have two options for enforcing security policies on mobile devices: Intune Mobile Device Management (MDM) and Intune Mobile Application Management (MAM). In both cases, once data access is granted, we want to control what the user does with the data. For example, if a user accesses a document with a corporate identity, we want to prevent that document from being saved in an unprotected consumer storage location or from being shared with a consumer communication or chat app. With Intune MAM policies in place, they can only transfer or copy data within trusted apps such as Office 365 or Adobe Acrobat Reader, and only save it to trusted locations such as OneDrive or SharePoint.<\/p>\n

      Intune ensures that the device configuration aspects of the endpoint are centrally managed and controlled. Device management through Intune enables endpoint provisioning, configuration, automatic updates, device wipe, or other remote actions. Device management requires the endpoint to be enrolled with an organizational account and allows for greater control over things like disk encryption, camera usage, network connectivity, certificate deployment, and so on.<\/p>\n

      \"Mobile<\/a><\/p>\n

        \n
      1. First, using Intune, let\u2019s apply Microsoft\u2019s recommended security settings to Windows 10 devices<\/a> to protect corporate data (Windows 10 1809 or later required).<\/li>\n
      2. Ensure your devices are patched and up to date using Intune\u2014check out our guidance for Windows 10<\/a> and iOS<\/a>.<\/li>\n
      3. Finally, we recommend ensuring your devices are encrypted<\/a> to protect data at rest. Intune can manage a device\u2019s built-in disk encryption across both macOS and Windows 10.<\/li>\n<\/ol>\n

        Meanwhile, Intune MAM is concerned with management of the mobile and desktop apps that run on endpoints. Where user privacy is a higher priority, or the device is not owned by the company, app management makes it possible to apply security controls (such as Intune app protection policies) at the app level on non-enrolled devices. The organization can ensure that only apps that comply with their security controls, and running on approved devices, can be used to access emails or files or browse the web.<\/p>\n

        With Intune, MAM is possible for both managed and unmanaged devices. For example, a user\u2019s personal phone (which is not MDM-enrolled) may have apps that receive Intune app protection policies to contain and protect corporate data after it has been accessed. Those same app protection policies can be applied to apps on a corporate-owned and enrolled tablet. In that case, the app-level protections complement the device-level protections. If the device is also managed and enrolled with Intune MDM, you can choose not to require a separate app-level PIN if a device-level PIN is set, as part of the Intune MAM policy configuration.<\/p>\n

        \"Mobile<\/p>\n

          \n
        1. To protect your corporate data at the application level, configure Intune MAM policies for corporate apps<\/a>. MAM policies offer several ways to control access to your organizational data from within apps:\n