The cloud presents an enticing opportunity for businesses – it makes important resources available anywhere, allows them to offshore the cost of storage, and can even save them on hardware costs by hosting applications. But the cloud, inextricably tied to the internet, also presents its own risks.
The same applications the cloud allows you to access from anywhere can also potentially be accessed by anyone if there are no proper access controls. Microsoft Defender for Cloud Apps was created to prevent such unauthorized access from occurring. However, if you’re using it alongside passwords, your application security may still be at risk of compromise.
What is Microsoft Defender for Cloud Apps and How Does it Work?
Microsoft Defender for Apps is a Cloud Access Security Broker (CASB). Put simply, it gates access to your organization’s cloud-hosted applications to ensure only authorized parties can utilize them.
It works in conjunction with Azure’s Conditional Access App Control. Once configured, user sessions are redirected to Microsoft Defender for Cloud Apps, which acts as a reverse proxy, instead of going directly to the app. While a session is protected by proxy, all relevant URLs and cookies are replaced by Defender. For example, if the app returns a page with links whose domains end in myapp.com, the link’s domain is suffixed with something like myapp.com.mcas.ms.
Microsoft Defender for Cloud Apps does much more than just reverse proxy connections. You can review more of what it does in Microsoft’s documentation on the topic.
The end user doesn’t notice anything different. They log into their SSO portal like MyApps (user’s authentication information is stored in Azure AD) as usual, and simply select the application they want to use from there. Using a single set of credentials to access multiple applications is undoubtedly convenient for the end user, but if all you’re relying on to protect your applications is a single username and password per user, there are numerous risks to consider.
What are conditional access policies?
Conditional access policies are a powerful tool to check if certain requirements are being met before allowing access. Using conditional access policies allows tighter access control and enforces organizational policies.
Azure enables administrators to implement such policies quickly. We’ll provide examples below.
Setting Conditional Access
Conditional Access Settings in Azure
Administrators can configure if a user or group will access a sensitive application through Microsoft Defender for Cloud Apps policy. To do so, they can follow these steps:
1. In the Azure Conditional Access Policy blade, select which users or groups will need to gain application access through Defender.
2. Specify which applications will be protected by Defender.
3. Set up a session control transfer to Defender by checking the box which says Use Conditional Access App Control. Select ‘Use Custom Policy’ from the drop-down.
The applications that need to be protected by Defender for Cloud Apps are now placed under Conditional Access App Control of Azure. This means that the Conditional Access Policy from Azure transfers the Session control to Defender for Cloud Apps for these select applications only.
We’ll describe what that looks like. As an illustration, imagine that an administrator has placed O365 under conditional access app control of Azure. When this application is accessed, the session is transferred to Defender.
Conditional Access Settings in Microsoft Defender for Cloud Apps
In addition to Azure, administrators need to set requirements for application access within Microsoft Defender for Cloud Apps. We’ll include a couple of example policies for illustration.
Example Condition One: Blocking access to a protected app’s browser version if the user produces an invalid certificate.
To trigger this condition, administrators can set the device tag to be anything that doesn’t equal a valid certificate. Administrators can also choose the specific application this condition applies to; in this case, we’ve chosen O365’s browser version.
Example Condition Two: Blocking access to a protected app’s mobile and desktop version if the user produces an invalid certificate.
This condition is set up similarly to the previous one. The only difference is that the administrator chooses the mobile and desktop versions of the specific application (O365 in this case) instead of the browser version.
Is Microsoft Defender for Cloud Apps Secure?
On its own, Microsoft Defender for Cloud Apps is still an excellent addition to your Azure ecosystem. However, it can’t necessarily protect you from the dangers of insecure passwords.
Having usernames and passwords as an authentication method for all your cloud applications isn’t a secure strategy. Passwords expose you to a range of unnecessary risks.
They can be easily stolen in phishing campaigns or cracked with other types of attacks, such as Man-in-the-Middle attacks. Verizon’s 2020 Data Breach Investigations Report found that 80% of hacking-related breaches were due to password use. Tying security to passwords is so insecure, that even Microsoft itself has advised against it.
Security aside, credentials also make for a poor end-user experience. Designating a password in the first place can be frustrating when an organization has complexity requirements. Once a password has been set, it’s likely employees will need to come up with a new one every several weeks as it expires, which is also a common requirement. And if someone fails to establish a new password prior to it expiring, they may be disconnected from work-related resources temporarily, decreasing their productivity.
The alternative is X.509 digital certificates. They require a Public Key Infrastructure (PKI) to manage, but with modern automation technology like that provided by SecureW2, this doesn’t have to be a daunting prospect.
The Benefits of Passwordless Authentication with Defender for Apps
Certificates answer every weakness that passwords have, and passwordless benefits are numerous. For starters, they present an improved experience for your end-users.
Users no longer need to come up with complex credentials, which saves them time. They also no longer need to manually enter passwords every time they log in, creating a more seamless experience. Because certificates can be set to expire and renew automatically at specific times, employees also don’t need to deal with the frustration of password-related disconnects and interruptions to productivity.
But the benefits extend beyond user experience, too. Passwordless authentication is also significantly more secure than its credential-based counterpart. Digital certificates generally cannot be stolen and reused by hackers. Because fewer packets are exchanged during certificate-based authentication, the process is also faster and more streamlined.
Going passwordless empowers organizations striving for a Zero Trust framework, because certificates provide the basis for contextually aware decisions. By using certificates, administrators can restrict access to critical applications. Organizations can set many different security policies, such as requiring devices to have the latest antivirus, OS, and browser version in order to be enrolled for certificates in the first place.
Implementing such policies ensures that only trusted, secure devices have the ability to access critical business applications. Restricting access to trusted devices in this manner drastically reduces an organization’s attack surface and prevents application misuse.
How Passwordless Authentication & Defender for Cloud Apps Work Together
Passwordless authentication largely follows the same steps as password-based authentication. However, instead of having to enter credentials, the user will be able to choose to log into an official SSO portal like My Apps with a certificate instead, thanks to a neat feature called Azure AD CBA (Certificate-Based Authentication).
A quick overview of how it works looks like this:
- The user enters their user ID to log into My Apps.
- If CBA is enabled, they are presented with the option of choosing a certificate to log in with.
- After choosing the correct certificate, the user is logged into My Apps.
We’ll take a more in-depth look at the process below.
Step 1: The user enters their User ID – email ID to log into My Apps.
Defender will perform a handshake and policy check for them set in Azure Conditional Access. The user will then be asked to present their certificate, which can come from any third-party PKI such as SecureW2’s.
Step two: The user selects the certificate they would like to authenticate with.
This user has been enabled by her Azure Admin for CBA. The user also has Digital Certificates installed on her device. Because of this, the user immediately gets a browser pop-up to choose an appropriate certificate to get into My Apps.
In this case, the correct certificate is the first one, so the user will select the first certificate in our illustration.
Step three: The user is granted access to My Apps.
After choosing the right certificate in the pop-up, the user is granted access to My Apps. They can now select whichever application they need.
Accessing Office 365 with Certificates
Office 365 is a particularly sensitive application, so some organizations may implement policies further restricting access to it. For that reason, users may need a separate certificate from the one used to access My Apps to access O365.
The certificate for sensitive apps such as O365 is Azure AD SSO in our illustration, which is designated by the organization. In our scenario, let’s assume the user already has the correct certificate and can select it from the pop-up window.
As we mentioned in the beginning, notice the change in URL: mcas.ms. This proves that the Defender for Cloud Apps policy is kicking in.
The user will now be able to access O365, and will again choose which app they’d like to use once they’re signed in.
Guard Your Cloud Applications with SecureW2’s Simple Passwordless Solution
In the past, organizations have been hesitant to deploy certificates because having to maintain their own PKIs was a challenge. Now, however, modern services like SecureW2 make it simple and fast to deploy your own PKI for certificate-based authentication.
Rather than building your own PKI from scratch – which costs time, effort, and oftentimes quite a bit of money – you can use our managed PKI. It integrates with your current infrastructure, can be deployed rapidly, and is managed through a single-pane interface.
Our solutions work well in Azure environments. Contact us to see for yourself how easy we make passwordless security.
