By Andy Mason
Recent events have meant remote working has become widespread a little sooner than anticipated, and CRM users all over the world are now accessing Salesforce and its data on their personal devices.
Though we’re all trying to stick as close to business-as-usual as possible, circumstances have changed dramatically. In the face of increased remote working and a growing reliance on digital systems, businesses need to step up their efforts to protect their data from both internal and external threats.
To help you safeguard your Salesforce data, we spoke to data infrastructure and security experts from across the Salesforce ecosystem to find out what users should be doing to ensure maximum data security.
Now is the time to secure your cloud applications
“Cybercriminals are taking advantage of the chaos to steal data and infiltrate networks, so to prevent critical data loss, now is the time to secure your cloud applications. Enacting the right precautions now can protect your Salesforce system during this crisis and take you from reactive to proactive when it comes to data security in the future.”
Before we get started, here’s a quick Q&A to help you understand how Salesforce security works.
“Run the Salesforce Security Health Check. It’ll provide you with a baseline of where you are versus best practices.”
Need to get a detailed, fast overview of your security standing? Salesforce offers a tool called Health Check that grades your baseline security across many categories, producing a percentage score and giving recommendations to help you address weaknesses quickly.
Any vulnerabilities unearthed are split into classes—High-Risk, Medium-Risk, Low-Risk—so you can prioritize the most impactful changes.
“Salesforce provides a security check tool that everyone should run in their org. It identifies key settings and vulnerabilities in your org. Running that gives you a good checklist of items to review and fix. Salesforce is built on a robust security model, so there are numerous settings, and added to frequently. This tool describes the setting, it’s potential impact, and reference material to educate you.”
The tool uses a proprietary formula to score how well your security settings size up to the Salesforce Baseline Standard.
For example, Salesforce’s Baseline Standard for maximum invalid login attempts is three. If you have a higher number set for your instance, Health Check will flag this as high-risk, give you a recommendation to mitigate the risk, and create a shortcut for you to action this change.
Other settings Health Check might flag include:
You can also set your own custom baseline, but bear in mind that Salesforce’s Baseline Standard is industry-leading, so be careful not to fall into the trap of thinking you know better than the pros!
“Understand that Salesforce was built with industry best practices in mind. While Salesforce is extremely flexible and customizable, care should be taken when changing core pieces of Salesforce. It’s often better to review your internal processes to see if you should update the process to match Salesforce standards, rather than overly customize Salesforce to fit your processes.”
What makes the tool even more useful is that is updates its Baseline Standard all the time, adapting to new threats and changes in best practice, so be sure to run Health Checks on a regular schedule!
To get started, search for Health Check in the Quick Find box of your Setup page.
“Turn on Two Factor Authentication! It’s a built-in feature of Salesforce that is easy to enable and provides a great added level of security.”
If you haven’t already turned on two-factor authentication for your org, you should flip that switch now. Requiring your users to go through a second level of authentication for every login is one of the most effective ways of protecting your Salesforce accounts.
With TFA, users download an app such as Salesforce Authenticator on their phone, or receive a text message, then relay the unique code issued by Salesforce to confirm that it is indeed them that’s trying to access the account. Passwords can be shared, lost, guessed; TFA adds an additional barrier between bad actors and your Salesforce instance.
There are two ways you can roll out TFA:
To get even more out of the TFA functionality, admins can also set IP restrictions that prevent access to Salesforce from specific IP ranges, or at certain times of day, further ensuring that only authorized users can get into your instance.
In addition to field- and object-level security, it’s good practice to have a role hierarchy in place within your org.
An often underused functionality, a well-architected role hierarchy can blanket your Salesforce instance in an extra layer of security by obfuscating data based on a user’s role.
A role hierarchy lets admins grant read and write access to data based on their position within their department or the business. Rather than dictating which fields are accessible to users, role hierarchy determines the records, reports, and dashboards that can be viewed and edited by users in a particular role.
Your role hierarchy will likely look similar to your organization’s hierarchy, but it doesn’t have to match precisely. Even if you’re a “flat” organization or your structure is a little looser than average, Salesforce hierarchies are still super useful for security purposes because they help selectively protect sensitive data.
“There are so many powerful out-of-the-box security features. Make sure that you’re using them to the best of their ability. From things as simple as profiles, permission sets, object CRED and FLS, these are powerful tools to protect your data. Need something even more secure? You can require high-assurance security for sensitive operations.”
For example, if you have a team of five people all doing the same sales job, and you don’t want them to be able to access each other’s data, you can assign them all the same role, which hands them the same privileges and restrictions.
Those five peoples’ supervisor, however, would be assigned a different role further up the hierarchy, enabling them to see the data of all their team members. Role hierarchies also allow you to extend field editing permissions from the record owner to their immediate supervisor, but no one else.
Think of your hierarchy like a tree, with each department, team, and so on as its own branch.
Setting this role-based grading means that a user can only access what’s “below” them. Their manager, on the other hand, would sit further up the branch and be able to see everything related to their sub-branches. Someone higher up in the hierarchy, like a CEO, for example, would be able to see the whole “tree.”
Not only does setting up a strong hierarchy mean better data security, but it can also make reporting and forecasting a lot easier if all users in your org are properly aligned.
There’s an argument for steering away from hosting your data in different systems, and instead integrating it with one comprehensive tool like Salesforce. But even Salesforce can need extra security, which should come in the form of a third-party virus scanner app.
Lockdown your environments with a non-native solution
“Due to the number of security vulnerabilities via unsecured devices, as well as multiple areas of entry into a Salesforce environment (think communities, sites, attachment uploads, email-to-case), the only way to truly fend off malicious content is to connect a third-party (or non-native) virus scanner to Salesforce environments. Unfortunately, Salesforce doesn’t include an inherent virus scanner, so it’s really important to lock down your environments with a non-native solution such as EZProtect.”
Salesforce Shield is a three-pronged tool, created to help admins and developers bolster business-critical apps with additional layers of security. It also allows many Salesforce security policies to be automated.
It’s admin-friendly and doesn’t require any complex setup, and is an incredibly useful tool for financial and health organizations to help protect their sensitive information.
React and optimize
“Finance and healthcare industries are at major risk as these industries are highly regulated and tech modernization is often slow. I recently read a quote that stated, ‘Rapid digital transformation has been led by COVID-19 and not the CIO or CTO.’ This means they must react and optimize their systems for the new climate.””
Here’s how you can up your security levels with Salesforce Shield.
Salesforce Shield’s encryption features are more comprehensive than you’d find in Salesforce Classic.
With Shield, you can encrypt standard fields and unstructured content like files, with no limit on file size. Plus, Shield’s encryption supports platform functions like search, validation rules, and workflows, so that the encryption processes doesn’t interrupt these actions as Salesforce’s basic encryption does.
Users maintain control over encryption keys, and you can set permissions to keep especially sensitive data from the eyes of unauthorized users.
Another standard area of Salesforce to which Shield brings richer and more exhaustive functionality is event monitoring. Salesforce Classic comes with a change logging feature, but for larger clients or those with more complex auditing needs, Shield takes things to the next level.
Shield’s event monitoring gives you a more granular overview of user behavior and app performance, showing you every interaction so you can see who is accessing what, where, and when. It generates logs within 24 hours and is accessible via APIs so that the data can be digested in the third-party data visualization tool of your choice.
Invest in change monitoring
“According to Trend Micro, misconfiguration is the biggest risk to cloud environments. As Salesforce environments are modified to minimize business disruption, it’s important to consider how these changes are being documented and verified so as not to introduce additional risk. Invest in the proper technology that can manage and monitor all the changes being made to avoid misconfiguration as well as what data users are accessing.”
Field audit trails
Salesforce Shield spectacularly blows open the scope for tracking, letting you see the state and value of data going back up to a decade across custom objects, accounts, cases, contacts, leads, and opportunities. Especially useful for tightly regulated sectors with extensive audit requirements. You can also set triggers to notify you when certain data is deleted.
As you might already know, clickjacking is a type of hack that attempts to lure a user into clicking an object such as a button or link that they believe to be safe, but that has, in reality, been programmed to perform malicious actions. With Salesforce, clickjacking can be used to access and modify instance data.
Salesforce provides customizable levels of protection against clickjacking by restricting the use of iframes on your site pages. Standard Salesforce pages are safeguarded against clickjacking by default, but it’s recommended that you roll out additional protection to customer Visualforce pages by enabling clickjack protection in your Session Settings.
One of the greatest things about Salesforce is that it can be easily integrated with other apps and services, allowing you to share data and bolster your functionality. But not every app you connect to Salesforce might be as safe as Salesforce itself, and can potentially create unsecured doors into your instance.
You should always look into the security model of any API you connect to Salesforce before you give it access; after all, it’s primarily your responsibility to ensure your platform is safe.
“Remember that you as a Salesforce customer are responsible for the security and integrity of your data. Backup and restore in the cloud is complex. Luckily there are many great partners in the ecosystem who can help, like my company Odaseva. I would recommend that everyone read our Salesforce backup and recovery tips.”
APIs can leave you vulnerable to issues like:
Since granting access to a shady or unsecured API could lead to hacks, data breaches, and compliance issues, you must have measures in place to help you take advantage of APIs while remaining protected.
Here are a few steps you can take right now:
Enable App Whitelisting
Don’t leave the power to connect apps in users’ hands. To prevent even well-meaning users from creating vulnerabilities, enable Salesforce’s App Whitelisting feature so that your admins can specify which apps can and cannot have access to your instance.
Designate an integration user
An API that accesses your Salesforce instance and passes data back and forth should be treated like any other “user,” meaning you tightly control what it can and can’t do.
A good way to achieve this is to create a dedicated integration user; a user account solely for that API with its own profile and permission sets.
You can then set the user permissions to “API only,” ensuring the integration can’t access your instance in any other way and grant the appropriate permissions so that the API can’t view or modify data it shouldn’t be near.
You should always abide by the principle of Least Privilege when it comes to user permissions: each user should only be granted access to the bare minimum of data that they need to do their jobs, and APIs are no different.
And never, ever give any integration System Admin access.
Double down on access controls for integration users
As we mentioned above, you should only give an integration access to the bare minimum of data it needs to operate. But there are a few other ways you can restrict APIs access to your Salesforce instance to reduce risk.
For example, we already discussed restricting logins by IP range, and you can go one better in this case and lockdown the integration user to ensure it’s accessing your instance legitimately. You can do this by restricting the API’s access so it can only log in from its own partner or vendor’s servers.
User passwords in Salesforce must be at least eight characters by default. You may have already made this requirement longer (which is great best practice), but you should consider demanding even more robust passwords for integration users: at least 20 random characters, including upper and lowercase letters, numbers, and special symbols is recommended.
Keep an eye on API access
Taking these additional steps when it comes to API access is a good start, but actioning them doesn’t mean you can take your eye off the ball. Once again, treat your integration user like any other user, logging their behavior, and conducting regular audits to hone in on any anomalous activities.
Now, we’ve already talked about restricting access to Salesforce outside of specific IP addresses and set business hours—but in these unprecedented circumstances, your users may well need to access your instance from different locations and at different times than they normally would.
Luckily, Salesforce has a feature that helps safeguard against illegitimate logins, while still giving your authorized users access even under unusual conditions.
Custom login flows let you put additional authentication steps in place if a user’s login attempts are in some way unusual. For example, if a user tries to log in from a restricted IP or out of hours, you can set a flow to be triggered that would require the user to meet extra security requirements, like answering a secret question.
A flow could also include sending a notification to an admin so they can look into and validate the login attempt. These flows help keep your instance safe without preventing authorized users from doing their jobs.
There are a lot of default user access settings and requirements in Salesforce that you can, and should, tighten up to bolster your instance security, especially now that more users are working from home.
Don’t let home workers fall through the gaps
“We also encourage organizations to work with employees to be sure they’re updated regularly; remote employees often delay updates which allows for the slip.”
Away from the office environment, users can often forget that best practices still apply, and the security measures that had previously been drilled into them are still needed even though they’re physically isolated.
Of course, you need to tread a fine line between security and user experience; having your users reset their passwords once a week may be super secure, but it’ll also infuriate your workforce.
Here are a few ways you can up your digital safeguarding game without impinging on user experience.
Password best practices
Length: By default, Salesforce asks for a minimum of 8 characters for passwords, but security experts now recommend at least 15 characters for extra security; the longer the password, the longer it takes to crack.
Complexity: In terms of security, password length tends to be more important than complexity, but requirements like numbers and special characters are always a good bet. Salesforce offers six different levels of complexity so you can choose the best one for your org.
Expiration: Salesforce’s default password expiration setting is 90 days, which is roughly the number of days it takes to crack the average password. You can opt to shorten this period; if you do, you should also turn on Salesforce’s Enforce password history setting so your users can’t reuse the same one over and over. Salesforce will then remember (and block the use of) a user’s three previous passwords. You can amend this number if necessary.
Password hints: You can also prevent users from setting their actual password as their password hint (thus revealing their password to anyone who asks to see the password hint). Salesforce does not prevent users from adding their password to their security question by default, so make sure to turn on the Cannot Contain Password setting.
Autocomplete: We’ve all been saved from forgotten password nightmare by a web page’s autocomplete form, but when your Salesforce data is in the mix, you don’t want your users to have that option. Make sure you disable caching and autocomplete on your Salesforce login page.
Head on over to the Manage Password Policies page to enact these changes.
Salesforce is hugely into knowledge sharing and collaboration, and its Communities tool is a big part of facilitating these things.
Communities enable you to share information and connect with those outside of your Salesforce org; people like customers, partners, or non-Salesforce user employers, for example.
As useful as it can be to share your Salesforce features and data with others, though, it’s vitally important that you’re mindful of exactly what you’re sharing.
“Any org that is running a community should review their external sharing and security model, including that of guest users. When you’re potentially exposing Salesforce data to external users through a community, you want to take extra care to lockdown records, objects and permissions. It’s not uncommon to have overly permissive security and sharing here.”
If you’re utilizing Communities, take a moment to audit your configuration and make certain that you’re using the Least Privilege approach so that both authenticated and unauthenticated Communities Users can only access what you want them to. The last thing you want is to expose customer data to external users.
Mason Frank Salesforce blog
Official Salesforce security documentation
Trailblazer Community articles on security
Salesforce Developers blog posts on security
Trailhead security trails
SFDC Fanboy blog
Salesforce Weekly blog
Admin Hero blog
Automation Champion blog
With over 35 pages of insights, advice, and best practices from industry professionals, our Overcoming unprecedented business challenges with Salesforce white paper is the ultimate guide to optimizing your business with Salesforce.
Sign up for Salesforce tips