Protecting Salesforce with Microsofts Enterprise Mobility and Security Suite
Hi folks,
in the last weeks I spent some time trying to protect Salesforce with the Microsoft EMS Stack.
This is a quite extensive topic and I would like to try to cover the following aspects with this blog:
- What is Zero Trust and how does it help us secure Salesforce?
- What are the risks with SaaS services in general and Salesforce in particular?
- Which measures and which Enterprise Mobility & Security Services can be used to counter these risks?
After that I will go into individual aspects that are quite specific to Salesforce and that were and are the greater challenges for me:
- Connection of iOS devices when using the Salesforce Mobile App
- Configuration of policies in MCAS to detect unwanted behavior and threats
Following the Zero Trust Paradigm
This blog is exemplary for securing SaaS services with Microsoft Cloud Security Services. The basic approach is strongly influenced by Microsoft’s interpretation of the Zero Trust Paradigm. For the description of the individual measures in this blog, however, I have chosen to avoid expected risks.
- We want to implement the Verify explicity aspect in such a way that not only a strong authentication and a managed device are required for access, but also the states of the account, the session and the device. The core technology here is conditional access.
- We want to implement the aspect Use Least-Privileged Access by (administrative) authorization concepts. The governance features of Azure AD are of particular help here.
- For the Assume Breach aspect we want to use Microsoft Cloud App Security. There we combine the login data from the Azure AD with logs from the application which we receive via an API connector. MCAS will search for known security violations and detect anomalies.
Recognize the risks
As a first step I made myself familiar with the possible or likely risks regarding Salesforce. Because I suspected that MCAS will play an important role this was my starting point. In the collection of security webinars Microsoft has included a good session about the Threat Protection Features of MCAS. If you want to protect your SaaS Apps (and you should!) this webinar will help you.
I took this overview of the Generic Threats for Cloud Apps from the webinar:
Additional there is this a source in the DOCs which is outlining the Salesforce specific risks and Skyhigh (McAfee) comes to a similar result.
Example: Compromised accounts and insider threats
One of the major issues with services that store valuable data for companies is the handling of compromised accounts and insider risks.
There are many current sources (here, here and here) for examples and classifications on the subject of insider risks, and Microsoft has recently even presented its own portal on the subject.
Mitigate the risks with M365
My strategy for improving the security posture of Salesforce is based on the three pillars App Hardening, Identity-based Security and MCAS API Integration.
Let’s have a look at each topic!
App Hardening and Security Baseline
This is the most difficult part for me because I don’t no much about Salesforce and I’m not using it. But as with any app a combination of security basics (e.g. dedicated admin accounts) and a hardening guide will do a lot.
In general you should try to reduce the attack surface by disable stuff in Salesforce you don’t need like external file sharing. This will help you with all mentioned risks.
Identity-based Security
At first use Azure Active Directory for the account management and Single Sign-On. The integration of Salesforce and Azure AD is well documented and the template in the AAD gallery is useful.
This integration allows you to control the access to Salesforce in the Users and Groups tab of the enterprise application. Often synchronized groups from the OnPrem Active Directory are used, but my recommendation is to work with Access Packages from the Entitlement Management, because in my experience there are always too many people who can edit group memberships in AD and there are usually no processes to check the assigned rights regularly.
Additionally, it is possible and very useful to set up the provisioning of users and groups via SCIM. A function user in Salesforce is required for this. The setup process is also very well described in the Microsoft documentation.
For the provisioning I prefer to only synchronize the needed items from the Users and Groups Tab.
After the successful establishment of AAD as an identity provider for Salesforce, we can directly use the identity-based security features such as strong authentication, identity protection features and conditional access. This will reduce the compromised account risk massive. To make this as effective as possible, it should be enforced that all logins are done through Azure AD and that there are no local accounts in Salesforce. You can enforce this in Salesforce or you can at least generate an alert in MCAS when a login is made directly to Salesforce. (see API Integration)
Use Conditional Access to integrate and enforce all your identity-based security features you enable for all integrated apps.
You could enforce MFA or check the session risk from AAD Identity Protection but most customers I know have decided to enforce trusted devices (with a fallback to a trusted location) for the access to Salesforce for their internal users. Here is some general advice how to build useful rulesets with Conditional Access.
Trusted devices should be marked by Intune Device Compliance Policies — at best including Device Risk from Defender for Endpoints. On the screenshot you see an example of an iOS compliance policy.
- Windows 10 Devices can Fallback to the Hybrid Join Status (or if you’re still using VPN via a Trusted Location) but even if you use SCCM or another Client management tool you should register the devices in AAD and onboard them to Intune to check for compliance.
- For Mobile Devices the situation is bit more complicated because there is no Intune version of the Salesforce App. But fortunately there is a trick to enable the capability to enable device authentication for the mobile app. (see chapter Enabling Device Authentication) If you don’t want to use this trick you could use the Edge Browser as a fallback or a micro VPN like Microsoft Tunnel.
For guest users (or Bring Your Own Device scenarios) you should think about the reverse proxy capabilities of MCAS called Conditional Access App Control.
To implement this you have to create a policy scoped to your guest users and your Salesforce Enterprise Apps and choose the Access Control “Use Conditional Access App Control”
Now the sessions are routed to MCAS and after the onboarding there session policies can be created to prevent e.g. uploads/downloads or copy/paste. This example policy prevents the download of all files.
Additional this enables the capability for scanning for Malware at Up- and Downloads — but I haven’t implemented this so far.
The last and and maybe most important group are the administrative users. In my opinion all administrative accounts (except a monitored emergency account) should be dedicated federated accounts. Treat those admins like all other high privileged accounts, enforce at least MFA and create an Access Review for them. I also have fantasy to use PAGs (see this good blog about the topic) for this but I haven’t had the time to test it here yet.
This measures will help you to reduce these risks:
- Compromised accounts and insider threats
- Data leakage
- Unmanaged bring your own devices
- Elevated privileges
API Integration with MCAS
Connecting MCAS and Salesforce is pretty straight forward will give you a ton of insights. You will see:
- Sign-on and configuration changes as events in the Activity Logs
- Files and their sharing status
- Users, groups and memberships
- In Salesforce integrated 3rd Party OAuth Apps
MCAS Policies
Additional you will get the option to create some policies to detect unwanted / suspicious actions after the integration. In general it makes sense to implement some policies of this areas:
- Anomaly detection
- Sharing Control
- Detect Sensitive Information
- Governance of connected 3rd Party apps
to reduce these risks:
- Compromised accounts and insider threats
- Data leakage
- Insufficient security awareness
- Malicious third-party apps and Google add-ons & Ransomware
- Elevated privileges
This is an early stage and I’m far away from finishing this topic but I want to share my experiences so far because I haven’t found anything regarding this topic in the web. If you’re familiar with this topic and have other or better ideas please contact me!
Useful policies for the beginning are:
- Logins without SSO
Since a large part of our security concept is based on the use of the AAD urgently want to recognize / avoid that logins are made directly to the application. In the activity log a SSO login has the activity type “Single Sign-On Log on”- all other login types are suspected to be direct logins.
To create a policy that detects this logins you just have to filter the activity log for the app, the source and the activity types and then create a new policy from search.
- Alert or revoke rare and uncommon OAuth apps
Users are able to integrate 3rd Party OAuth apps. Depending on your needs you should alert or revoke when this happens.
- Discover sharing in Salesforce
Your users will store files in Salesforce and maybe share them with people outside of your organization. Really interesting is also the new preview for DLP in 3rd Party Apps (what includes Salesforce). I’m still investigating this topic and I will blog more about this in the future.
Enabling Device Authentication for Salesforce Mobile
One of our biggest challenges was to enforce compliant iOS devices because there is no Intune enabled version of the app. The breakthrough came with this blog post that describes how to configure an SSO extension in iOS to achieve this:
How does it work?
AAD identifies a device by the Device ID and does a lookup for the Attribute iscompliant. The Device ID is stored on the device in an anchor app. At iOS this is the Authenticator App and at Android it is the Company Portal App.
From iOS13 on you can use the Microsoft Enterprise SSO plug-in for Apple devices which provides SSO with Azure AD accounts for all application that support Apple’s Enterprise Single Sign-On feature.
iOS Config with Intune
Since the SSO plugin is a part of the Microsoft Authenticator App you just have to configure it. In MEM this is done by a Single sign-on app extension setting (Warning: There are 2 different Settings — it’s not the Single sign-on configuration)
The Single sign-on app extension comes in two flavors:
- The Credential type -> the old stuff (Username+PW, Kerberos)
- The Redirect type -> the modern stuff (OIDC, OAuth2, SAML2)
For Salesforce (and any other at AAD integrated app) we’ll take the Redirect type and have to choose the app extension type:
- Redirect -> The generic approach
- Microsoft Azure AD -> Looks like a template for our use case :-)
Some background and how to configure this extension is well described in this blog.
Salesforce Configuration
The key component in Salesforce is checking the box at the setting Use the native browser for user authentication on iOS/Android in the Authentication Configuration section of the Company Settings. Regarding to the Salesforce documentation this setting will do the following:
Users on iOS and Android devices are redirected to their native browser when using single sign-on authentication with your My Domain URLs.
What is still missing?
Unfortunately I did not find ways to create meaningful alerts for all functions — here are a few examples:
- Assignment of administrative permissions
Although there is an overview of user and group memberships in Salesforce (including sys admins), there is no way to generate alerts based on changes. - Administrative activities
Many administrative tasks can only be interpreted in detail based on their description and MCAS currently does not offer the possibility to filter based on this description.
