Search
Close this search box.

5 Ways Salesforce Admins Can Secure Their Salesforce Org

Illustrated Developer at desk
Red Argyle logo

In the first post of this three-part blog series, we covered the basics of Salesforce security, privacy, and compliance. Below, we walk through some actionable steps (that any level Salesforce admin can manage) to quickly improve your organization’s Salesforce security.

Before jumping in, we recommend establishing a proper testing program before changing Salesforce security settings. Tightening security can sometimes introduce regressions which are best caught before they hit production.

We also recommend getting your copy of our resource, Salesforce Cybersecurity: Climbing the Mountain, a collection of tools to help you secure your organization.

Now. Let’s get into some fixes and recommendations!

#1 Salesforce Health Check

Salesforce Health Check allows Salesforce administrators to see how their organization’s security settings align with Salesforce recommendations. This dashboard is easy to read, and changes are mostly checkboxes within Setup.

All you Salesforce admins out there will appreciate the numeric [health] score provided by Health Check. This Health Check score is valuable when reporting to stakeholders because it’s easy to show how well your organization meets Salesforce Baseline Standards. Any security or setting changes are documentable when Health Check is rerun. As you see the difference in your Health Check score, you can gauge the impact of your security efforts.

Screenshots from the Salesforce Health Check score screens. 74 percent is considered good. After adjustments 94 percent is considered excellent.

Salesforce Health Check Frequency

How often you run your Health Check depends on how often changes are made at your organization. For some companies, it might make sense to do this monthly. For those organizations with documented security goals and higher levels of awareness, their Health Check may run less frequently.

Here at Red Argyle, we recommend that clients run a Salesforce Health Check once a release or once a quarter. Again, this should be adjusted to your specific organization.

Salesforce Health Check Tip: Some changes can be made automatically by checking a box under “Fix Risks.” Adjustments to password policies and adding Clickjack protection can make a big difference.

Learn more about running a Salesforce Health Check by taking this Trailhead learning module.

#2 Salesforce Optimizer

Salesforce Optimizer is an out-of-the-box tool that reports the metadata in your organization (e.g., fields, security settings, automations). The report identifies several factors: field usage, unassigned page layouts, inactive automations, and insecure Experience site sharing settings.

The report also provides recommendations on optimizing your Salesforce instance, either by deleting unused fields or limiting the level of access external users have to your Experiences site.

Salesforce Optimizer is a great way to identify security threats, especially if you use Experience sites. External users (i.e., users who don’t have access to your instance’s internal applications) should only have the access they need to perform their functions. Improper record access due to a poor sharing model can compromise your data.

Learn more about getting started with Salesforce Optimizer.

#3 PMD Scan or Checkmarx (if your org contains code)

A PMD Scan is a free code analyzer to find programming issues in your code. It supports Apex, Java, and Javascript, among several programming languages.

The PMD Scan consists of rules designed to identify problems in your code; the output of a PMD Scan is a CSV file report. If you’re using custom code, running the scan is a good idea, as it serves as a helpful code check, which is useful, especially before deploying into production.

You can find more information about using the PMD Scan here.

Checkmarx is another resource for checking custom code. Salesforce has partnered with Checkmarx to provide this free code scanning resource, which checks your code for quality and security issues (e.g., Cross Site Scripting and SOQL/SOSL Injection).

Go to force.com Checkmarx security scanner help article for more information about using the Checkmarx resource.

#4 General Sharing Model and Personas

Let’s start with Salesforce Sharing settings. You can find your Salesforce Sharing setting under the Setup tab and in Sharing Settings. Learn more about controlling data access in this Salesforce training: Control Access to Objects.

So, what does a secure sharing model look like?

If you don’t have an Experience site (formerly a community), then it’s likely that everything on the right side of your Sharing Settings should be private.

Salesforce Sharing Settings Tips

  • Not using that Salesforce object at all? Then, default to Private.
  • Not everyone should see an object, but you’re unsure how to get the right people to see it?
    • Default to Private.
    • Learn about Sharing Rules.
    • Learn about field-level security.

The Sharing Model includes Sharing Settings, which define the baseline default access for each Salesforce object and can be opened further with sharing rules.

Above, the Lead object is left completely public (often not a good practice). In this case, you wouldn’t have a use for sharing rules because everything is already open to everyone.
In the above example, the Lead was made Private. Now you can open it with a sharing rule, where you have more control about who can and can’t see records, depending on ownership and other criteria.

Your sharing settings, sharing rules, and Role Hierarchy work together to control access. Learn more about Role Hierarchy.

Profiles function to group users who need similar permissions for their work in Salesforce. Most admins will know that you can look at your Profiles in setup.

But you can also build custom List Views from this page to focus on specific permissions. This could be useful for tracking something like your MFA rollout if you have to do it with portions of users at a time. To do this, you’ll have to enable Enhanced Permission Set Component Views and Enhanced Profile List Views.

Or to ensure only admins have admin permissions.

#5 Multifactor Authentication (MFA)

The short version of MFA is that it’s real and coming. In the Salesforce Summer ‘22 release, Salesforce announced that true technical enforcement is coming sometime this year.

MFA is easier to deal with in advance rather than reactively. So it’s vital to get in compliance ASAP!

What is MFA?

It stands for Multi-Factor Authentication (formerly called 2FA for two-factor authentication).

What does MFA mean to my organization?

You need more than one “factor” to access Salesforce. One factor would be something such as your username and password (Credentials). You need at least one more thing besides that. MFA generally relies on:

  • Something you have (like a phone or physical key)
  • Something you know (a secret)
  • Something you are (your fingerprint or an eye scan), BUT…

Options for Enabling MFA

Salesforce does not accept every single form of MFA out there. So, here are your options for enabling MFA:

Salesforce supports username or password, plus:

  • Physical Key
  • Phone Apps (theirs or another one)

If you use Single-Sign-On for all your human Salesforce users, some Single Sign-On solutions require an additional factor already, so that can be MFA compliant for Salesforce as well, but is harder to implement.

How to get compliant with MFA

A Simple MFA plan is possible if you have:

  • A smaller number of users
  • Ability to use cell phone apps or to buy physical keys
  • Savvy groups of users
  • No concerns about integrations, connected apps, etc. that could break
  • Ambitious or experienced Admins to manage the process

If this sounds like your organization, you can probably read up on the Salesforce documentation, make a plan, communicate to users, and roll out MFA with a phone app or physical key.

But if you have a more complex scenario, such as:

  • Your organization has integrations, connected apps, packages, automations, and you’re not sure about what might or might not break
  • A large population of users
  • Accidental Admin without much formal Salesforce training
  • Not allowed to use phone apps and can’t buy everyone a physical key
  • Want to configure a SAML SSO (Single Sign On) or SSO Auth Provider but haven’t done that before
  • Don’t have much time and can’t afford to figure things out as you go
  • Have an SSO, but don’t know if it’s compliant/don’t know if it can be configured to be compliant

You may need professional help to make your MFA process run more smoothly. (Consider whether there are other aspects of your org you want to clean up or improve, so you can bundle some of that in.)

For more information about MFA compliance, check out this Salesforce Multi-Factor Authentication FAQ Help article.

Conclusion

Illustrated Developer at desk

Salesforce security isn’t a one-and-done event. It’s something ongoing that needs to be monitored and adjusted depending on your needs and environment.

In addition to ongoing risk assessment and technical fixes, an appropriate security policy can greatly benefit any security program. The policy isn’t just a binder on a shelf, though; it’s a playbook to help govern cadences and security-minded activities in the future. In the last post of this blog series, we’ll discuss best practices for creating your security policy.

There’s a policy checklist within the Salesforce Cybersecurity: Climbing the Mountain resource. Get your copy now!

You might feel overwhelmed by all this talk about sharing models and MFA. Don’t be! Get in touch to see how Red Argyle can help!

Red Argyle logo
Red Argyle logo

Related Blog Posts