ASK THE EXPERTS: 9 tips to keep your data secure in Salesforce

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

Before we get started, here’s a quick Q&A to help you understand how Salesforce security works.

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.

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:

• Minimum password complexity
• Forced logouts on session timeouts
• Forced re-logins after an administrator logs in as another user
• Clickjack protection
• Locking sessions to the IP address from which they originated

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!

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.

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:

• You can require users to go through two-factor authentication every time they log in
• You can trigger TFA only when a user meets specific criteria, such as attempting to review particular reports or access a connected app

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.

3. Determine a role hierarchy

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.

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.

4. Implement a virus scanner

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.

5. Utilize Salesforce Shield

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.

Here’s how you can up your security levels with Salesforce Shield.

Platform encryption

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.

Event monitoring

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.

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.

6. Turn on Clickjack protection

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.

7. Secure your APIs

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.

APIs can leave you vulnerable to issues like:

• DoS attacks
• Code injections
• Fraudulent logins
• Unsecured cardholder information
• Replay attacks
• Exposed data in URI keys

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.

8. Use custom login flows

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.

9. Tighten up user access controls

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.

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.

Don’t forget about external users

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.

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.

Useful data security resources

Mason Frank Salesforce blog
Salesforce Ben
Salesforce StackExchange
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