Data is the modern currency and arguably the most valuable asset on which the value and reputation of any company rests. Unfortunately, in the modern workplace, working anytime, anywhere, and on any device creates a complex ecosystem where just monitoring and recording the online activity of users accessing your data is not enough.
With cyber-attacks getting more ruthless, there is a need to be proactive rather than reactive to ensure your data is well protected. One of the most effective ways to protect data is to control who has access to what information. Conditional access control helps you ensure that employees have access only to data and applications needed to perform their work. For example, an employee from HR will not have access to applications and data from a design team or vice versa. However, to implement access control, there is also the need to ensure the device/user requesting access to your network is authenticated without any doubt or room for ambiguity.
Microsoft Defender for Cloud Apps allows setting up device identification that can help alleviate your network security to a higher degree. This article will cover how device identification in Defender helps implement policies more accurately and directly.
Why Is Setting Up Device ID Important?
To determine the identity of a login session with absolute certainty, more than passwords and user IDs are needed. Credentials can easily be shared or stolen and, therefore, are not a reliable way to authenticate a login.
Device identity is an object that can help make these access control decisions more accurate by providing a better identity context. They can help you determine whether a device is a managed one or a BYOD. This information is crucial in determining what degree of access should be granted for better access and session control in real-time.
Let’s first understand what device Identity is to get a better idea about how it helps improve your network security by aiding policy implementation for robust network access control.
What Is A Device Identity?
Device ID refers to an alphanumeric string that is unique to every device. All mobile devices, such as smartphones, IoT devices, or heart monitoring machines in hospitals, have device IDs.
The serial number displayed in the physical device is not what we call a device ID. It is, in fact, stored in the mobile device itself. This device ID is often also called the device’s model number, and any app that is downloaded or installed on that device can access this ID when communicating with the server. These device IDs are useful for research and development for app companies to understand app performance, customer preference, or user experience. They are also widely used for targeted marketing in digital marketing to understand user behavior, enhance user experience, and provide a more tailored experience.
The Device ID Object in Azure
Device identity, as defined by Microsoft, is an object in the Azure Active Directory like groups, users, or applications. It is assigned to any device upon registering to an organization’s Azure AD (Microsoft Entra ID). It can be assigned to any device type, whether managed or BYOD, desktop to laptop, or phones to tablets, and is not the same as the device ID or the model that is used for mobile app marketing.
Device identity contains specific information about the device that helps administrators make decisions related to access and configuration. Device identity is an essential component in device management that helps implement policies for multi-factor authentication.
For example, suppose a user is trying to access an application from a BYOD. In that case, they can be given limited access or asked to perform an additional authentication step before downloading specific files as opposed to if they are trying to access the same information from a managed device.
How Device Trust and Attestation Helps Improve Security
Device attestation is when a trusted source attests that the devices are not tampered with and confirms that the device identity information, such as serial number, matches the trusted source’s database, which in turn establishes that it is a device that is indeed what it says it is and therefore can be trusted to grant access as per the company policies. One of the best examples of device attestation is Apple Managed Device Attestation, which is explained in the diagram below:
More and more organizations are looking to factor in Device Trust as a core part of their policies and security processes. For example, Device trust helps improve network security in the following ways:
- Providing all the device identity context information that helps enforce network policies in real-time
- Constantly monitoring the device’s condition to ensure there are no breaches
- Checking if the device has the most up-to-date firewall and antivirus installed
- Monitoring information about user/machine behavior to identify any suspicious activity
- Laying the foundation for a zero-trust network architecture
One way to explain this is-
when anyone leaves comments on your office documents, Google will notify you via Slack about it. You can open the Google Doc through Slack if logged in from your managed device, such as a laptop. However, if you try to access the same through a BYOD(personal mobile phone), you will only be able to check the message in Slack. To access the Doc, you will need to request permission from your email address that is assigned to the mobile device.
Because it is a BYOD, access control policies will ask for additional authentication before granting access to the Google doc. Unmanaged devices inherently have a much higher risk, as they aren’t being forced to comply with the same policies that Managed Devices would. So, we want to make sure they will have limited access to specific files or applications, and managed devices can be given access to more and higher sensitivity applications. The device ID is what helps in determining the type of device based on which the relevant policies are implemented, which ultimately helps in creating a more secure network.
Creating a safe network requires controlling who has access to what and the degree of access they are allowed. Implementing Network Access Control requires that the device’s identity is well established, and device attestation is the best way to get that proof. It helps ensure that no spoofed device is granted access to the network and that network policies are applied appropriately depending on the attestation result.
Device Identification in Defender for Cloud Apps
Microsoft Defender for Cloud Apps works with Conditional Access App Control to direct users through a reverse proxy instead of directly to cloud applications. As a result, user requests and responses are routed through Defender instead of through the app. This allows access and sessions to be monitored and controlled in real-time, giving you better control over your network.
While creating policies in Defender for Cloud Apps, you can define policies in a way that can consider the type of device (managed or BYOD). You can define access and session policies to identify specific traits in the device, such as
- Microsoft Intune Compliant devices [only available with Azure AD]
- Hybrid Azure AD joined devices [only available with Azure AD]
- The presence of client certificates in a trusted chain
Intune Compliant and Hybrid Azure AD Joined Devices
With Intune-compliant and Hybrid Azure AD Joined devices, Azure AD conditional Access takes the approach of directly routing the user request exchanges to Defender for Cloud Apps. To further filter the access and session control for a more controlled device management, you can create policies that use the device’s state (such as firewall, antivirus, and certificates are up to date).
Device Management for Client Certificate Authenticated Devices
Defender device management can also be used for devices with client certificates to create access and session policies. To enable this, you use the existing client certificates if your organization already has them installed, or you can enroll your devices with new certificates.
The client certificates have to be verified through a trust chain that has the public key of the certificate authority (CA) that will be used to sign the certificate during each session.
Once the certificate is installed and the policy is created, Defender for Cloud Apps endpoint will request the browser to present the SSL client certificate when a session authentication request is presented. The browser will then provide the certificate that is installed with a private key. This certificate and private key check is done using the PKCS #12 file format, typically .p12 or .pfx.
Defender for Cloud Apps will check for the following conditions at the time of certificate check:
- The client certificate is valid with the correct root or intermediate CA.
- If the certificate revocation list (CRL) is enabled, it will check if the certificate is in the CRL.
Follow the steps below to configure a policy for device management using client certificates:
- Go to Microsoft 365 Defender portal
- Select Settings and choose Cloud Apps.
- Select Device identification under Conditional Access App Control.
- Upload the root or intermediate certificates for the devices that you want.
Better User Identity Context With Certificates
Defender device management with certificate-based authentication helps build a more robust device identity context. With certificates, you can attach additional identity context information that helps define the identity of a user/machine with greater clarity. Managing the certificate lifecycle for an entire organization may seem daunting. However, with the right solutions, it can be a seamless process.
SecureW2’s Managed PKI can be easily integrated with multiple Identity Providers (IdPs) to communicate between Microsoft Defender for Cloud Apps and non-Azure IdPs. If you use multiple Identity Providers (IdPs), SecureW2 can be set up to work with all of them. This will guarantee that all your networks and applications are secure, no matter which IdP they use.
Our cloud-based certificate management software allows network admins to identify users and their devices for managing and segmenting network access. You can view security reports and create custom certificate templates and policies for a more rounded network access control.
Certificate Authority (CA) Management has an easy-to-use graphical interface where you can view your certificates and check information such as the issued date and the device it is attached to or revoke a certificate. Automated Certificate Expiration Notifications from SecureW2’s management portal notify IT about certificate expiry due date in advance with instructions on how to renew certificates.
SecureW2’s gateway APIs natively integrate with MDMs like Intune for managed device certificate auto-issuance and allow end users to use their cloud IDP credentials to self-enroll themselves for certificates. We offer industry-exclusive Identity Lookup with LDAP & SAML Identity Providers that allow the Dynamic Cloud RADIUS server to look up the identity of a user in real time during the authentication process.
SecureW2 provides a cutting-edge solution to facilitate the deployment of certificate-based 802.1X network authentication in a cloud-based environment. This comprehensive solution also enables a deeper insight into device activity, contributing to improved network security.
Defender Device Management With SecureW2
The modern complex environment requires a modern approach to device management for enhanced network security. With users connecting to your network through multiple devices, it becomes necessary to have a well-managed network access control system in place to avoid a network breach. One that provides better visibility and control over all devices and helps understand user behavior for device identity context/machine identity context.
SecureW2 can help you get every device enrolled with certificates for enhanced security. This can be achieved through easy-to-use landing pages and software or by using Mobile Device Management (MDM) systems. By using certificate-based EAP-TLS authentication instead of traditional credentials, we offer a more robust security system. Our certificates can be personalized with user and device identity, ensuring instant device trust upon distribution.
With SecureW2’s management software, network admins can easily monitor all authentication events and remotely resolve user issues. They can also regulate which devices are authorized to receive certificates, giving them better control and visibility over network devices. Our solution for device management is comprehensive and strong, improving network security and delivering greater control and visibility over all devices. Click here to learn more about pricing.
