Paid features Of all the cybersecurity developments in 2021, the relatively low-key announcement from software company Salesforce.com (SFDC) in March could end up being one of the most significant.
Effective February 1, 2022, “Salesforce will begin requiring customers to enable multi-factor authentication (MFA) to access Salesforce products,” read the announcement. Since then, “all internal users who log in to Salesforce products (including partner solutions) through the user interface must use MFA each time they log in.”
Multi-factor authentication has been the recommended setting for most business visits for years, but no major service provider has ever insisted customers use it as a prerequisite for their service. Even Google and Microsoft, two big advocates of MFA, don’t implement it by default to access their services.
This change has far-reaching implications: Customers who are unable to implement MFA during their visit by the set date can continue to use Salesforce without MFA at their own risk. Salesforce doesn’t just enforce MFA, but as part of its terms and conditions, the decision not to use it is the responsibility of the customer.
“What they’re doing is delegating this aspect of access security to their customers and saying they don’t want to be responsible for it,” commented Danna Bethlehem, director of product marketing for identity and access management at Thales.
In effect, Salesforce is reimagining the shared responsibility model that typically manages cloud services. That said, the customer has certain responsibilities and the service provider has other responsibilities. Changing it for MFA is more than just a tweak. Thales statistics show that 90% of cyberattacks utilize compromised credentials in some way, which, if correct, means that failure to implement MFA on Salesforce could shift responsibility for nearly all cyberattacks involving the service .
“Customers who are not compliant can be held responsible for any violations that occur. That could be a harbinger of what’s to come,” Bethlehem said.
It’s tempting to be skeptical about this shift, but it’s worth looking at the issue from Salesforce’s perspective. Credentials targets have increased dramatically in a few years, and Salesforce is at the top of the target list. Over the years, however, the technology to protect accounts has come in the form of MFA authentication apps, hardware tokens, and password-less options, all powered by Salesforce.
The disturbing fact is that despite the growing number of account breaches, not enough customers have it fully enabled. From now on, the policy will be their problem, not Salesforce’s. There’s no question that Bethlehem is right to believe that others will follow in Salesforce’s footsteps. In a year or two, mandatory MFA could quickly become the norm for many cloud services.
The interesting question might not be how many clients will comply, but why more clients haven’t done so in the face of evidence that MFA is working well. Frankly, why is it necessary to force a good idea?
Every user is a target
This Thales Access Management Index It was found that only about 55% of European IT professionals reported that their organization had adopted MFA, in line with the global average, with the UK figure slightly higher at 64%.
Those numbers sound pretty encouraging until you read that a lot of this MFA usage is related to traditional remote access/VPN applications and privileged users. For cloud access, only 15% of organizations protect more than 50% of their users.
“In today’s threat landscape, every user is a target. Simply having an arbitrary authentication footprint in an organization leaves a large gap,” Bethlehem observed. This approach was outdated a few years ago, even though Salesforce has mandated to keep this in mind. “When organizations implement MFA for Salesforce, they should already be doing it for all users, because all users are the target.”
Of course, telling an organization to implement MFA isn’t the same thing as actually happening, which is probably why Salesforce gave customers 11 months’ notice that they needed to comply. Arguably, that’s not long enough.
Authentication is still complex, starting with a bewildering array of options for different use cases. According to Bethlehem, it’s important not to treat authentication as a special occasion thing, but to approach the technology in a more strategic way.
Often, the problem of implementing MFA strategically is addressed either as a technical problem or as a use case problem. The advantage of the first approach is that it’s a relatively quick way to get up and running if you’re already invested in MFA and the use case isn’t complex. For these customers, launching Salesforce MFA may just expand what they’re already doing.
The second approach is to audit possible use cases, using different approaches depending on the user context. This is suitable for organizations that have not yet widely used MFA or have specific requirements, such as the medical or manufacturing sector, where some techniques may be more convenient or more compliant than others.
“The main priority for Salesforce customers is to implement MFA for Salesforce. But they shouldn’t stop there, and should ideally evaluate what other applications and users they might need to protect in this way,” advises Bethlehem. “We are helping our clients in this discovery process and will be assessing their entire environment.”
Technology selection
The clear message from Salesforce’s MFA FAQ is that some established methods (such as SMS text, phone calls, and email) will no longer be sufficient to authenticate to their platform, nor will VPN access override this requirement. Technologies like SMS have not been considered secure for years, and email has never been so secure, although some people adopt them as a cheap way to achieve the second factor.
This leaves two paths – basic MFA provided by Salesforce or using a third-party provider. This might include FIDO tokens that support WebAuthn and U2F (such as those offered by Thales, Google’s Titan, or YubiKey) or proprietary authentication systems such as Apple’s Touch ID/Face ID or Windows Hello.
That’s great news about today’s MFA environment – there’s no shortage of options to choose from. For most organizations, that means using a smartphone as a core authenticator, or running an app, or using some form of biometrics or FIDO2 WebAuthn. For privileged users, this may be supported by the gold standard for FIDO U2F hardware tokens.
On closer inspection, however, the latter option has some warnings, mostly around the browser, when accessing Salesforce. For example, pre-Chromium versions of Microsoft Edge do not support WebAuthn keys, and only support U2F in Google’s Chrome. Likewise, not all U2F tokens support seamless smartphone access, or not at all.
Ubiquitous Authentication
In Bethlehem’s view, changing user and security needs in many cases mean a custom approach is the only option. What makes an identity and access management specialist like Thales unique is that it can integrate any conceivable combination of hardware and software, including technologies that support organizations already invested in.
“You have to think about how you’re going to manage everything, especially when you’re mixing hardware with software. You need a good management backend, otherwise management becomes stressful,” Bethlehem said.
In most cases, this will mean a mix of hardware and software MFA for different types of users, which is usually where the problem starts. “Many vendors don’t provide integrated hardware, they just support it. If a company wanted to add other types of hardware, they always had to go to another vendor to do it. But in many cases, they didn’t Good management support for these technologies.”
A popular solution for cloud applications like Salesforce is SSO, which puts multiple services behind the front door of a single authentication interface, such as Thales’ own SafeNet Trusted Access. The disadvantage of SSO is that it relies on a single credential, so it needs to be used with MFA, and usually assumes that each user can be managed by a single IAM policy. However, once an organization must support many different use cases, a more sophisticated approach to policy configuration is required. Not all SSO services offer this feature.
“You need a policy engine that will enforce the appropriate level of authentication based on the user’s context, such as accessing regulated sensitive applications. Our policy engine ensures that the correct authentication is always applied for that user and application,” Bethlehem said.
“Thales is the only vendor to sell all options in an integrated manner, including Adaptive Authentication, FIDO Tokens, OTP Tokens, Schema Based Authentication, Authentication Apps, Push Authentication, all with Access management system integration.”
Does the Salesforce policy change have broader implications? In Bethlehem’s view, this is a signal that authentication needs to be employed because it’s the best way to keep users safe, not because they’ve been told to. This will bring about a major change in safety culture. So far, only remote workers or privileged users are protected by MFA, while others are limited to passwords or simple but substandard options such as SMS. Now there’s a case for getting everyone onboard.
“Organizations are now making remote work for all their users part of their day-to-day business operations. Salesforce reminds them that ensuring this requires authentication is no longer a luxury and should be used everywhere.”
Sponsored by Thales.
