Learn how to enable safer selling in Salesforce with Microsoft Cloud App Security — Part 1: Building a Lab Environment
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.
Let’s start with our lab!
Components setup
The first step to secure an app like Salesforce is to create a good test environment in which you can operate completely freely. This helps to gain first experiences, to test functions and to simulate special scenarios or changes.
Salesforce Tenant
Fortunately, it’s relatively easy to create a developer account for Salesforce that — for my purposes — has no limitations. I wish more services would offer that…
M365 Tenant
For the M365 environment, it makes sense to create / use a tenant with at least the following features:
- EMS E5 (für AAD, MCAS und Intune)
- Azure Subscription (für Sentinel und ggf. Clients)
I like to use the demo environments from Microsoft for this.
Microsoft Cloud App Security
The quick setup of MCAS is well described in the Microsoft documentation, but of course you should study such a cool tool like MCAS in detail and aim to become a ninja!
Azure Sentinel
Also for Sentinel there is documentation for a quick setup in the DOCs but I think every opportunity to learn something about Sentinel should be taken.
So here are some very good resources:
- Microsoft Azure Sentinel: not your daddy’s Splunk | by Maarten Goet | Medium
- Azure Sentinel: design considerations | by Maarten Goet | Medium
And of course the sensational Ninja training:
If you’re familiar with Sentinel and tired of clicking you maybe should have a look at this automatic deployment option: video & blog
Integration
After having administrative control in both environments and getting a little familiar with each other the first step is to connect the two tenants. I have found so far 5 integration possibilities that can be useful for us.
1. AAD <-> Salesforce: Single Sign-on
The SSO integration is the basis for the whole scenario. It allows us the use of Conditional Access, e.g. to restrict access to (Intune) Managed Devices. Through this integration we can also use CA App Control whereby we can see significantly more activities and use Access and Session Policies in MCAS.
The integration is now very well automated and described in the MS docs:
After setup, it’s then a matter of deciding whether a form-based login is also possible in addition to the AAD login. For the test environment, I like to leave this on to make sure I don’t accidentally lock myself out.
In a production environment you may want to keep a Break Glass Account for cases like a broken SAML trust. For this account you should configure MFA in Salesforce — it works with the Microsoft Authenticator App.
In the next part I will describe how to detect and alerts logins from this account.
2. AAD <-> Salesforce: User Provisioning
In the further course of this blog I would like to test scenarios where user provisioning can be very advantageous. On the one hand, provisioning can help us a lot in assigning administrative permissions and on the other hand, with a high degree of automation, it is easy to detect manual interventions and alert accordingly.
3. MCAS <-> Salesforce: API Integration
One of the core functions of MCAS is to address other services via API. For Salesforce, this includes fetching information (users, logs, files) and triggering (a few) actions in Salesforce.
In addition to the described permissions, it is useful to configure on the profile that the password does not expire.
Patience is important when setting up the coupling. Even with an empty Salesforce environment, it can take several hours for the first activities, files and entities to arrive.
4. AAD <-> MCAS <-> Salesforce: Conditional Access App Control
The use of the reverse proxy from MCAS has two advantages:
- We can use access and session policies and thus control them much more granularly than “only” with conditional access.
- The amount of events in MCAS increases dramatically and we can use e.g. Activity Policies better.
Salesforce is very quick and easy to set up as a “featured app”.
I first configure the session control of the conditional access policy to monitoring. This way, the app is automatically on-boarded in CaaC after the first user login and there are first logs. If this works, it makes sense to create a first simple session policy and change the session control in Conditional Access to Custom Policy.
Important: As long as there is no access or session policy that matches the custom policy, the session completely bypasses MCAS and we do not see any logs from which we can create further policies.
5. Sentinel <-> Salesforce: API Integration
Since Sentinel has much better possibilities for the evaluation of logs than MCAS, it is desirable to integrate the logs there as well. Relatively new to this is this connector — but unfortunately I could not get it to work yet :-(
6. Sentinel <-> MCAS
An alternative / additional approach is the integration of MCAS and Sentinel. This is generally a good idea to consolidate the management of alarms.
In Sentinel there is already a connector to connect MCAS. This is quick and easy to set up, but only includes alerts and discovery data:
To be able to evaluate entities and activities in Sentinel, there is also the possibility to query the API of MCAS with a Logic App and store it in a workspace of Sentinel. I will discuss this in a separate blog, since I have not built a general coupling so far but rather worked use case related.
Until then, I recommend this very good blog by Sami Lamppu — he describes the coupling in it for an Azure use case:
Summary and Outlook
Now that the lab is up and running, in the next part I will look at the different policy types and how they can be used to secure Salesforce. After that, we combine them to useful scenarios and I will take a look at why and how we can use Sentinel.
Stay tuned!
P.S.: I’d like to thank Michael, Oliver and Sami for inspiration, review and input !
