Journey with Microsoft Security: From CASB to Project Breeze
CASB Making a new friend
In 2019, I delved deeper into Microsoft Security, encountering the Cloud Access Security Broker (CASB) known as Microsoft Cloud App Security (MCAS), which was later rebranded to Microsoft Defender for Cloud Apps. Initially, all the features were daunting, but over time, we achieved a functional synergy. My only challenge was the proxy, which often led to URL rewriting issues and inconsistent performance.
Transitioning to in-browser protection with Edge for Business
Fast forward to August 2023, I had the opportunity to test a new experience called Project Breeze. Initially, we had to use a browser plugin, which has since become redundant with the advancements in Microsoft Edge for Business. This evolution from the reverse proxy to a more integrated approach in Project Breeze marks a significant improvement in performance and user experience, demonstrating Microsoft’s commitment to refining its security tools.
Enhanced Features and Management
During the process, we received updates enhancing the feature, such as the monitoring of pasting and the detection of malicious downloads and uploads. Beyond monitoring, we now can block such activities. Besides that, we also received support for macOS. The team has diligently worked to ensure the feature is easy to manage and use. The current overview of all the features is as follows:
- Block/Monitor file downloads (all files or sensitive files)
- Block/Monitor file uploads and uploads based on content, such as PII
- Block/Monitor copy/cut, paste, and print actions
- Block/Monitor malware uploads and downloads
Enabling Edge for Business Protection
Settings for Edge for Business protection are enabled by default in the Microsoft Defender XDR Portal. To adjust these settings:
- Navigate to Settings > Cloud Apps.
- Scroll down to Edge for Business protection.
- If disabled, activate by toggling “Turn on Edge for Business browser protection.”
- When required modify the custom message by selecting the radio button at “Customize message”
This is a sample of a customized message:
Configuring Conditional Access Policies
When Edge for Business browser protection is enabled we can forward all traffic through the Microsoft Defender for Cloud App proxy. This can be enabled with a Conditional Access policy. We create a new or edit a current conditional access policy based on the current design decisions, which targets the applications we want to route through the proxy. Here is how to set it up:
- Create a new or edit an existing Conditional Access policy targeting the desired applications.
- In the session control settings, select “Use Conditional Access App Control” and choose “Use custom policy” from the dropdown menu.
Access and session policies
Once the conditional policy is set the data will be delivered to the proxy. The next step would be to set up policies, this is not done from Microsoft Entra ID Conditional Access, but from the Microsoft Defender XDR portal. When we go to configure the policies we have two options. There is the access policy which allows us to configure what happens during the access of an application. We also have a session policy which is more fine-grained and allows us to use all the cool new features.
To create these policies:
- Navigate to Settings > Cloud Apps.
- Scroll down to Policies.
- Click on Policy Management and then the tab Conditional Access.
- Click on Create Policy and select the right policy.
The first option is the access policy, this is the one where we can configure if we want to monitor (Test) or block. We also need to provide a Policy Name, Policy Severity, Category, if we want to trigger alerts, and where we want to assign the policy. Last but not least we have an option to trigger Power Automate playbooks to even trigger more fine-grained playbooks.
Next are the session policies, these have some policy templates to get us started.
But besides the templates let’s go through the fields. Like the access policies, we also need to provide a Policy Name, Policy Severity ,and Category. Next, we need to define the session control type. We have the following types:
- Monitor only
- Block activities
- Control file download (with inspection)
- Control file upload (with inspection)
When we select one of the types we get the field activity source. These are the same as the access policy, except for the Client App, which is only available in the access policy.
By default the filters, filter out the managed devices and configures a filter to add the apps that we want to include. The monitor only control type is the least fine-grained because it is meant to monitor everything. The other 3 control types have settings for content inspection, and the following action types:
- Audit
- Block
- Require step-up authentication
In regards to content inspection, there is one important checkbox that we need to take into account for our design decisions, and that is the following, Always apply the selected action even if data cannot be scanned. This is your fail open or fail close option, do we want to block or allow when items cannot be scanned by content inspection?
While Control file download also adds an option to Protect files by adding a sensitivity label. The Control file download and Control file upload also have a set of file filters, which can make our policies even more fine-grained.
- Extension
- File name
- File size (MB)
- Sensitivity label
And like the access policy, the session policy also ends with the alert options.
Note from the field: activating the policy takes a short moment. In my small demo environment it only took 2 minutes, but in larger environments it could take more minutes.
Design and personal preferences
With a comprehensive understanding of the available policies, we can now tailor them to fit specific security needs. My personal preference leans towards a restrictive approach: allowing web applications only on non-managed devices. This particular policy needs to be configured in Microsoft Entra ID Conditional Access. Furthermore, it’s crucial to implement a policy that monitors traffic from managed devices, with an emphasis on blocking potential data leakage from unmanaged devices. This layered approach ensures a balanced security posture, accommodating both flexibility in access and stringent data protection measures, in line with our overall security framework outlined in the blog.
After setting the policies
When all policies are configured it takes a short time for them to get effective. The main factor of this is the tenant size. When users connect to an application that falls within a policy there are several options. When connecting from a third-party browser, we get the notification with the request to use Microsoft Edge or the customized notification which we could have set earlier.
When we select Continue in the current browser, we get the old proxy:
When switching to Microsoft Edge we get the following notification:
And when we continue from a nonwork profile we get the following notification.
Validating if the session policies are effective
When we run from a work profile, we have the option to verify that the application in the open tab is protected. We can do this by right-clicking the lock icon. The new window should show a suitcase icon because it is managed and the text Microsoft Defender for Cloud Apps.
Another option is to try to open the Developer Tools in the tab. That should be grayed out and also have a suitcase icon.
Showing the moving parts
Once we configured the policies it is time to test them out. When we copy data from a place that we configured to be blocked, this is the notification the users get.
When we do the same for a download, this is the notification the user get.
When we try to drag and drop data, we also get a notification.
For the last test, we uploaded a malware sample which returned the following notification.
Working with the data
During the configuration, we have created some session policies to monitor and block certain actions. We have also configured the policies to generate alerts. We can find the alerts from the Microsoft Defender XDR Portal by going to alerts.
Besides the Alerts, we can also scroll down to Cloud Apps and click on Activity log. In the activity log, we are also able to find all monitored activities.
Monitoring with Kusto
As KustoKing I love to use my data in Kusto. So here is a small guide on how to query the data from KQL. This can be done from the Microsoft Defender XDR portal, or when we ingest the data into Microsoft Sentinel or Azure Data Explorer.
In the table CloudAppEvents, we have a column AuditSource, which shows where the data is from.
The Activity types are in the ActivityType column
Other interesting columns to query are IsAnonymousProxy, UncommonForUser, and SessionData.
Pro Tips
One of the things I ran into was working with guest accounts, who do not have a managed device. I opted to exclude them in the design and remove them from our onboarding Entra ID Conditional Acces Policy.
When we want to manage Microsoft 365 Applications, we should not use the App Microsoft Online Services, but Microsoft 365. When we use Microsoft Online Services the policy will also work on Microsoft Azure and Microsoft Intune.
A good starting point is to prevent modern applications on unmanaged devices and then use session policies to prevent downloads. For managed devices, we can set up a session policy to monitor all activities.
Disable user notifications for the routing through the proxy. This way we do not bother the users to allow it every week.
Closing notes
As always I hope you enjoyed reading my blog and that you have learned something about this new cool feature.
