Learn how to enable safer selling in Salesforce with Microsoft Cloud App Security— Part 3: Combining the Use Cases
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.
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.
Real World Scenarios
Almost more important than good use cases is a reasonable combination of these to ensure a level of protection appropriate to the situation. In the following scenarios, I started from the basic idea that a high level of access management with only a few DLP measures is sufficient to enable higher usability.
This is best illustrated by comparing a managed device and a bring your own device. On the managed device, we can take measures to ensure the integrity of the device and protect the data — on a BYOD, this is only possible in rudimentary form.
Even with partners and customers who access the system — e.g. via a guest account — in the AAD, we only have limited control over the end devices and admins are generally often subject to different rules than normal users.
Which restrictions to use is of course always a question of environment and usage but I will suggest a possible policy combination for each scenario.
Some policies I use regardless of the scenarios for all users:
- Detect direct Logins
- Built-in policies like Anomaly Detection
- Detect Mass Downloads
- Detect shared Files
Access for internal users with managed devices
For internal users, we have powerful tools with Azure AD Identity Protection to detect whether the user or session is currently posing a threat, and ideally MCAS also detects from the logs of Office 365 and possibly via Mirosoft Defender for Identities whether the user is exhibiting conspicuous behavior.
What is a managed device?
In my opinion, the ideal managed device is Azure AD joined, Intune Managed and protected with Microsoft Defender for Endpoint (MDE). Device Compliance and Device Risk enable us to determine the current state of the device and take it into account when accessing it via Conditional Access.
On a managed device, we also have a realistic chance of detecting whether the device has been compromised.
Managed Devices und DLP
With Windows 10, we have a very high level of transparency through MDE as to what data is stored on the device, and we can also do a lot to prevent data leakage through Endpoint DLP.
endpoint dlp | Matt Soseman’s Blog (wordpress.com)
For mobile devices, I think the biggest problem is that the Salesforce app can’t be protected with app protection policies, so we can’t ensure that the data doesn’t leak.
Recommendation
In this scenario, users are most likely to be able to “work freely” because we can use strong tools for implementing the zero trust strategy. I therefore recommend implementing only comparatively loose policies in MCAS for this scenario. However, the prerequisite for this is that it can be ensured that the devices are managed devices.
Example Policy
- Block activities (Sharing)
- Block downloads (by size)
- Block upload (Malware & Unlabeled)
Access for internal users with BYOD
As described above, we can infer the behavior of internal users relatively well. However, the device must be considered a risk factor from both an information protection and a threat protection perspective.
Unfortunately, this applies to all device platforms because, as I said, we can’t use App Protection for the Salesforce app.
BYOD und DLP
With BYOD, we realistically have no way to restrict anything on the device.
Recommendation
In this scenario it makes sense to restrict activities via MCAS or to protect files via AIP. MFA should be enforced in any case with Conditional Access.
Example Policy
- Block activities (Printing & Sharing & Cut/Copy)
- Block downloads (generic)
- Block uploads (generic)
Access for external users
In any case, all access by external users should run via Azure AD instead of creating accounts in Salesforce. The external users can be conveniently invited and managed via the guest function of the AAD.
This has many advantages:
- Authorization for access can be managed via Access Packages. (see here)
- Conditional Access can enforce MFA and confirmation of Terms of Use.
- Sessions can be routed through the MCAS reverseproxy.
For externals, we usually have to assume that we cannot distinguish whether it is a managed device or not. However, even if we can (see here), we must rely on the configuration of the device and cannot configure our own policies.
Recommendation
First and foremost, least privilege in Salesforce is extremely important for external access. Depending on the activities that the externals have in Salesforce, you should try to implement as many of the use cases as possible to limit the possible actions.
Example Policy
Variant with Cert-based-Auth:
- Block activities (Sharing)
- Block downloads (by size)
- Block uploads (Malware & Unlabeled)
Variant without Cert-based-Auth:
- Block activities (Printing & Sharing & Cut/Copy)
- Block downloads (generic)
- Block uploads (generic)
Summary and Outlook
I hope to be able to give a basis for most environments with the scenarios and example policies shown here, which can then be adapted to the respective needs. The next topic I will look at is a concrete use case of what added value an integration with Sentinel can deliver.
Stay tuned!
