Learn how to enable safer selling in Salesforce with Microsoft Cloud App Security — Part 2: MCAS Policies
Hi,
In this blog I want to share with you my experience in making Salesforce a little more secure with Microsoft Security tools. Since I’ve covered a lot of topics on this journey, this blog has become so long that I’ve split it into several parts.
- In part 1, we will set up a lab environment in which we can test everything else.
- In part 2, we’ll look primarily at the capabilities of Microsoft Cloud App Security and how they can benefit Salesforce.
- Part 3 is about combining the use cases developed in Part 2 into meaningful scenarios, e.g., to enable the use of BYOD.
- In part 4, Sentinel has to come to the rescue for a use case that I could not handle with MCAS.
This series was preceded by a blog in which I focused on the risks to Salesforce, sensible conditional access policies, and securing the mobile app.
The blog is aimed at IT admins with a solid basic knowledge of M365 / Azure services and can be used e.g. as an aid to rebuild. I try to link sources wherever possible and instead of detailed instructions I will rather go into the why and the stumbling blocks.
In this second part I will try to define some use cases and combine them to sample scenarios. My main focus is here on blocking / limiting sessions and detecting suspicious activities.
About Salesforce
In this blog post I will focus on Salesforce — but I think most of it is well transferable to other apps. Salesforce is a good candidate for this because it has a very high adoption rate and most companies consider the data in Salesforce to be valuable and worth protecting.
I have observed two types of files in Salesforce so far. Files that are stored, edited and shared in Salesforce (like in SharePoint) and (volatile) downloads of reports. The files are accessible for MCAS via the API and can be monitored / controlled with file policies. Here is a little overview what you can do with files in Salesforce. The downloads of the reports are only visible in the sessions. Especially the reports can contain very valuable data (e.g. all customers).
The administration of Salesforce is primarily done through so-called Profiles. Those Salesforce profiles consist of ‘Roles’ + ‘Permissions’. MCAS imports the standard profiles and also self-generated profiles regularly via the API integration. Particularly interesting here is the profile System Administrator.
Built-in Policies — independent from Salesforce
Due to the integration of MCAS and Salesforce, several MCAS policies are directly active that detect suspicious behavior and anomalies. These policies benefit strongly from the data from Azure Active Directory, but also use data from the API Connector and from its own reverse proxy.
All anomaly detections regarding the session (IPs, locations, browser, impossible travel) are working as expected.
According to the documentation, the monitoring of some unusual activities also work. However, these can only be simulated in a lab with a great deal of effort, since machine learning determines a “normal” behavior over a longer period of time and alerts the user in the event of deviations.
Detection of Malware and Ransomware activity is not (yet?) supported for MCAS + Salesforce — but we can use session policies to detect / block.
MCAS Policy Types and Categories
Before we go into the use cases let’s have a look a the different types and categories of policies and how they can be used in general.
Different types of policies means different functions and triggers.
In this blog part I will focus mainly on:
- Activity Policies for detection and alerting of suspicious and unwanted actions
- Access and Session Policies for detection, limitation and block of unwanted actions
- File Policies for the detection of overshared Files
Different categories help you to plan and sort your policies by different risks. This will help you e.g. at incident response or reporting
So far I have not detected any technical influence of the categorization but you can already see the differentiation in the reports (left MCAS, right Compliance Center)
Scoping / Filtering options
The available options for filtering are depending on the policy type.
- In activity policies you can choose between single and repeated activities and define thresholds and timeframes.
- In session policies you have additional filtering options like IP addresses or user agents and you can filter on the content depending on the session control type
Filtering on instances
In addition to the app Salesforce it seems reasonable to filter on the instance of the app. This is especially useful if you don’t have a separate MCAS tenant for your lab or if you want to test stuff in your sandbox.
But unfortunately this is not always possible because the integrated app in the Conditional Access App Control is not aware of multiple instances. Salesforce as a “Featured App” will appear as Salesforce -General with a bunch of prepopulated URLs including your instances…
In all policies working on the API (like activity and file) you can filter on the instance. In all policies working on the Reverseproxy you can’t filter on the instance — this includes activity policies working on events from the Reverseproxy.
Alerts and actions
With regard to Salesforce, we generally have the following options in the policies to respond:
- In Session and Access Policies actions can be blocked and in Session Policies for downloads files can be protected.
- In File and Activity Policies, actions can be triggered in Salesforce via the API connector. In addition, file and activity policies can trigger actions in Azure AD or other services connected via API.
Governance actions to control connected apps | Microsoft Docs - Alarms can (additionally) be generated in all policies and in almost all policies, alerts can be passed to Power Automate to start runbooks.
Alerts
While it is only partially useful for access and session policies, alarms should be generated for all other policies. These alarms can then be managed directly in the MCAS portal. If you want to handle the alerts this way I think it is very useful to make sure that there are email notifications. This can be done per Admin in the Notification Settings of MCAS.
Alternatively, you can (and should) use M365 Defender (XDR) and / or Azure Sentinel (SIEM) as an entry point for alerting.
Are you still confused with them? See Azure Sentinel vs. Microsoft Defender | LinkedIn and XDR versus SIEM — afraIT.
In the M365 Defender Portal — it is included in your MCAS license — all alerts from MCAS are automatically displayed, grouped and linked. Among many other advantages (which would go beyond the scope of this article), it is very easy to configure policies for notifications in the Defender portal.
In Sentinel is a predefined connector to pull the MCAS alerts — I think I will write a separate blog about Sentinel & MCAS — and if you’re using another SIEM there is a generic connector in MCAS.
In summary, there are many options how to deal with the alerts from MCAS and strongly depend on the alerting strategy. But in any case it is important to generate them.
Use Cases
Use cases help me to plan an appropriate combination of measures and are meant as a proposal for demos. For every use case I will propose a category / severity and useful combinations. Additional I will provide the dependencies, a situation / threat and a suggestion.
Detect direct Logins
Type: activity, Category: access control, Severity: high, Dependency: API Integration
Why should I care?
One of the most important use cases, as many security measures are implemented through Azure AD and can be subverted through direct logins. I have described useful measures in Conditional Access in this blog. In short: Limit access to the app to Managed Devices and check the risk levels.
What do I need to do to use this?
A standard user will generate when connect to Salesforce an event from type Single sign-on log on. Direct logins are creating events from type Log on — and this is what I use as the main filter for the detection.
You can check if this filter will work for you or if you will have false positives using the preview results feature. An example would be if you’re using the user impersonation feature for support (I wouldn’t recommend — privacy!) you have to change this filter.
Exceptions should only be made for a Break Glass account and the MCAS API user — although it makes sense to create a separate policy for the Break Glass account.
The minimum action here is to create an alert. The rest depends on your environment.
Detect logins from Break Glass Account
Type: activity, Category: access control, Severity: high, Dependency: API Integration
Why should I care?
For apps that are connected via federation, such as Salesforce, it makes a lot of sense to also perform administration with federated accounts. However, there may be situations where it is necessary to log in to the app directly with an administration account, e.g. to repair the federation trust.
This account should be treated as a break glass account, i.e. logging in with the account is only done in exceptional cases. It is very useful to generate an alarm when this account logs in.
What do I need to do to use this?
The activity policy required for the alert can be generated very easily from the search generated by a filter. Simply log in with the Break Glass account, filter on the account and filter on the activity log in and create a policy with the action Alert.
This policy can be refined later if needed when alerts due to failed logins (by attackers) occur frequently.
Detect Mass Downloads
Type: activity, Category: threat detection, Severity: high, Dependency: Conditional Access App Control
Why should I care?
This use case targets both intruders and malicious insiders as it is likely that some data in Salesforce is quite valuable and a major export may be the target of an attack.
What do I need to do to use this?
The template Mass download by a single user is a good starting point because it already includes the needed activity types. For testing and introducing these policies it is good to scope the policy to the app and a defined user group.
The main challenge with this policy is to find useful thresholds for your environment. For testing purposes it is useful to take low numbers like 5 activities per minute but for the rollout you have to adapt to the behavior of your user.
I think eventually this should be an anomaly detection — but for the beginning static thresholds are a good starting point. If you have experiences how good this works please contact me.
After finding good thresholds you should generate alerts as action.
Block activities: Printing, Sharing, Cut/Copy
Type: session, Category: DLP, Severity: low, Dependency: Conditional Access App Control
Why should I care?
For example, if you want to enable BYOD use in Salesforce, it’s a good idea to block some activities. And do you really want to use Salesforce as a platform for file sharing?
What do I need to do to use this?
The template Block cut/copy and paste… is a good starting point because it already includes the most of the needed configuration. The session control type has to be block activities and the filters for the app and a pilot group can be applied as usual.
I find the activities printing, sharing and cut/copy a good combination but of course it is also possible to create single policies or block only a part of the actions.
Our goal for the action is definitely to block the activities and present a (customized) block message to the User. For the start the Test-Mode can also be very useful.
How is the user experience?
Great… have a look:
Block (specific) Downloads
Type: session, Category: DLP, Severity: low, Dependency: Conditional Access App Control
Why should I care?
For example, if you want to enable BYOD use in Salesforce, it’s a good idea to block or restrict downloads.
What do I need to do to use this?
The template Block download based on… is a good starting point because it already includes the most of the needed configurations. This policy can block all downloads or you can filter
- on attributes of the file like a name, an extension, a sensitivity label or the file size.
- on the content e.g. using the sensitive information types from O365 DLP.
How is the user experience?
As an example for my demo environment I have created a policy to block files over 1MB.
The action is to block the download and present a (customized) block message to the User.
Are there any limitations?
Yes — unfortunately there are some…
Images are not detected as downloads because MCAS can’t differentiate today between images as part of the website and an image file.
If you’re using any(!) policy with content inspection there are many reasons to let this fail. Examples are: >50MB, encrypted Files, >1M characters,… In this case the configured default behavior will be applied — what is in default Allow.
So for now I would recommend not using policies with inspection if you want to block downloads unless you want to change the default behavior setting to Block — but keep in mind: this setting is actually implemented for downtimes of MCAS.
Block upload of malware
Type: session, Category: threat detection, Severity: high, Dependency: Conditional Access App Control
Why should I care?
Since Salesforce is also a platform for unstructured data / files in addition to structured data, but unfortunately has no antivirus functionality (incredible for a SaaS service…) it is appropriate to think about measures.
What do I need to do to use this?
For the malware detection you can use the template Block upload of potential malware (based on Microsoft Threat Intelligence) add a custom block message (and filter on App and pilot group if you want). In addition to the block action I strongly propose to create an alert.
Are there any limitations?
Yes — in my tests I discovered that the old edge browser is able to upload files and the policies are not triggered. A workaround is to build block policies for outdated browser versions — see this blog from Jan Bekker on this topic.
My advice is to build the policy as described in the blog and another one blocking user agents containing Edge/18 — because the old edge is not tagged as an outdated browser.
How is the user experience?
Block upload of unlabeled files
Type: session, Category: compliance, Severity: low, Dependency: Conditional Access App Control
Why should I care?
This functionality can be used to ensure that only approved files (recognizable by a label) may be uploaded.
What do I need to do to use this?
To enforce labeled files the template Block upload based on… is a good starting point because it already includes the most of the needed configurations.
After scoping the policy to Salesforce and maybe your testing group you just have to select for which filetypes you want to enforce the label and to exclude files with your label(s).
In my demo example I’ve defined that only Word documents with the dedicated label are good. In a real environment you may want to extend the filetypes and integrate your existing label taxonomy. Since this is a block policy, this should of course also be the action (with a custom notification).
Are there any limitations?
Yes — in my tests I discovered that the extension filter can be easily tricked by renaming the file and appending a .tmp for example. So it makes sense to build additional policies to control the allowed filetypes.
How is the user experience?
Protect on Download
Type: session, Category: DLP/threat detection, Severity: low, Dependency: Conditional Access App Control, Azure Information Protection Integration
Why should I care?
In contrast to Office 365, it is generally not possible to edit Office documents in the browser in Salesforce. In order to allow users to open the documents and at the same time prevent data from being leaked, it makes sense to restrict the rights to the downloads.
What do I need to do to use this?
MCAS can integrate Azure RMS in two different ways to encrypt the files before download: with Sensitivity Labels or direct with Custom Permissions. I think which option you want to use depends primarily on whether or not you already have AIP in use.
For my demo policy I decided to use Custom Permissions. There you can select the permission levels known from the Sensitivity Labels. The policy is created in the same way as the block download policy described above, but with the action protect instead of block.
Are there any limitations?
Unfortunately, this action is limited to only a few file types and you have to decide how to deal with the others.
How is the user experience?
Additional Certificate Based Authentication
Type: access, Category: Access Control, Severity: low, Dependency: Conditional Access App Control
Why should I care?
This is an interesting use case for partner integration, as it allows us to detect managed devices outside our tenant based on a certificate issued by the partner PKI.
What do I need to do to use this?
To implement this use case for a partner, the following steps are required:
- Creation of a dynamic group in AAD and import into MCAS
My approach here is to create a dynamic group for the partners to have client certificates in use. This can be done relatively easily via the mail domain and can be extended very easily:
(user.mail -contains “PartnerWithCerts.com”)This group can then (if no Access Packages are used for it) also be used well in App Assignment or in Conditional Access Policies.
Patience is required here. After creating a group, it can take quite a while until they appear in the import of MCAS.
2. Upload of the partner’s root certificate in MCAS
Here it has proven practical to work directly with someone from the partner during the setup, as all the necessary information can be viewed / exported on the client in the certificate management console. Since both user and client certificates can be used, the first task is to search for the appropriate certificate in the console under Personal Certificates. From there, the certification path can be viewed directly and the certificates of the issuing certification authorities can be exported. When exporting, it is important that the file is Base-64 encoded and that all sub-CAs are included. For merging and converting certificates I like to use XCA.
3. Creation of an access policy
The first important thing to note here is that we need an access policy instead of a session policy. The policy is filtered on the app, the imported group and the crucial filter is the device tag Valid client certificate. The action is block with custom message.
Are there any limitations?
This use case sounds very good in theory, but it has its pitfalls as it is not really intuitive and strongly dependent on the platforms and browsers used. In my experience, the support of mobile devices is limited to the Safari browser — in other words, no mobile apps.
In addition, a certificate issued once (which may also be exported) is of course significantly inferior compared to device compliance, as we only have a snapshot here. The better solution would be to be able to access the compliance status of the devices from the home tenant (I think I heard something like that at Ignite 2020…).
How is the user experience?
If the client has one or more matching certs a window will pop up direct after the login asking you to select the cert.
This will happen only the very first time you are accessing the page and the exact behavior depends on the used browser.
Likewise, depending on the browser, there are ways to increase the user experience. This is described quite well in this blog and must be done on client side.
All accesses from devices that do not have a suitable certificate are blocked. A customized block message helps a lot to give the users an orientation where the problem might be.
Detect shared Files
Type: file, Category: DLP, Severity: low, Dependency: API
Why should I care?
As already mentioned, Salesforce is also a file sharing platform and you would do well to have a look at what files are there and who has access to them outside the company.
What do I need to do to use this?
A file policy has to be created with the filter on App, Instance and Access level. Due to the lack of actions via the API, we can unfortunately only inform about this — whether this is done in the form of an alert and/or to the file owner depends a bit on the company policies and culture. I am more of a friend of direct feedback to the user, so I would definitely choose this option and create an alert if necessary.
Are there any limitations?
Compared to SharePoint there are unfortunately a lot of limitations. File related API actions are not possible and files cannot be quarantined. In addition, the detection by the mechanism is quite sluggish — i.e. you should additionally block the sharing via session policies.
How is the user experience?
When MCAS detects one or more files that match the policy criteria, an email is sent to the file owner (if configured). The links in the email work and take the user directly to the affected files to fix the problem.
Since there is currently no possibility to customize these mails, e.g. to provide further instructions / help, it makes sense to inform / train the users in advance.
Summary and Outlook
These use cases are a snapshot of the capabilities of MCAS. However, as they are extended almost monthly, I strongly assume that this blog is just an introduction and will soon be outdated ;-)
In the next part, I will combine the use cases into example policies for different scenarios.
Stay tuned!
P.S.: I’d like to thank Michael, Oliver and Sami for inspiration, review and input !
