I’ll start by apologizing that there hasn’t been a blog post in a long time. Me and my family have been sick with COVID-19 but fortunately we have recovered, which we are grateful for.
This article will be the first of a series of articles around Microsoft Cloud App Security (MCAS).
MCAS is an extremely powerful tool that can, among other things, support maintaining business requirements over how we can control our information in/to different cloud services.
Three common business cases
Click on the video to see it with the correct resolution.
Block certain information to be uploaded to the cloud
This video shows how we allow/block upload to the cloud based on the sensitivity of the file
Blocking certain information for cloud storage is a prerequisite for most of the organizations in the public sector to even start using cloud services.
The organization needs to have an information classification in place, which is always the first step to get control of their information.
We can then block certain sensitive information in different ways to be stored in the cloud. EndPoint DLP is most commonly used for managed devices, while MCAS is the perfect solution for setting the same regulatory framework for other non corporate devices.
Block download of sensitive information
This video shows how we allow/block download from the cloud to an unmanaged device based on the sensitivity of the file
We can use Sensitivity Labels to block downloads from sensitive Team and SharePoint sites, but if we want to control downloading based on sensitivity MCAS can achieve this. A good example is when there is public information that is allowed to be downloaded regardless of device and we want to make sure that sensitive information from the same Team/Site are blocked from being downloaded to, for example, a home computer.
Block sensitive information in chat
This video shows how we can block users from sharing passwords
Another example concerns sensitive information written in posts/Chat where we may detect certain expressions indicating that a user is about to expose their password.
How does this work?
Let’s start by looking at how we can use Conditional Access and Session Control with a custom rule in MCAS.
To proxy the traffic, we start by creating a Conditional Access rule for the users and devices to which this should apply. In my case this affect all unmanaged devices accessing Office 365 SharePoint Online. We then Configure this as a Session rule with a custom policy.
This CA rule will redirect the session to MCAS. In MCAS we have created a couple of Session policies for the above scenarios.
If we take a look at the policy blocking uploading of sensitive data, we have defined the affected sensitivity labels that we want to block. We filter out the managed devices where we have EndPoint DLP to control the same thing. We have also created a customized block message for the end-users. It is very important that we clearly describe why something is blocked with guidelines on how to do instead or where they can find more information.
We can also create an alarm when this occurs for follow-up of this type of actions. In several cases, this can be a good start before we start blocking anything to get a good overview of the scope of this rule. As you can see in the above picture we got an overview of number of alerts that these policies triggers.
In the last video we see the end result of the above configuration when a user tries to access the URL – teams.microsoft.com
This URL gets redirected to .cas.ms and the user get information about that this access is monitored.
I hope this article has supported you in your efforts to maintain all business requirements
In the next article, we’ll take a closer look at how MCAS can detect threats and automatically mitigate them to protect our identities and our environment.
Pingback: MCAS and AAD Identity Protection threat detection and automatic response | IT-Säkerhetsguiden