14 Essential Steps to a Secure Salesforce Environment

Originally published by Suridata.

Introduction

Salesforce.com has been so successful that we tend to forget what a breakthrough it was when it debuted 25 years ago. At the time, people were skeptical that you could get enterprise-grade functionality on a browser. They were mistaken. The software-as-a-service (SaaS) revolution that Salesforce had a key role in launching is now so entrenched that it’s hard to recall how bold it was when it started.

Salesforce is now the leading customer relationship management (CRM) platform in the world, by a wide margin, generating over $30 billion in annual revenue from 150,000 customers across the globe. And, CRM is only the start of Salesforce’s offerings. The company is the clear leader in multiple related categories, such as sales and marketing management, service management, and more.

Like any SaaS app, Salesforce is not without risks, with the software factoring into finding that 39% of companies that use SaaS have experienced data breaches. However, Salesforce’s size and the scope of deployments translate into heightened SaaS security risk. Their technology strategy, which includes extensive integration capabilities, a massive partner marketplace, and customization through purpose-built programming languages, further exacerbate its cyber vulnerabilities. This article explores how you might expose yourself to cyber risks by improperly configuring your Salesforce's environment and offers 14 essential steps to secure it.

The security risks of Salesforce

It’s important to state, up front, that Salesforce is a highly professional organization that takes security seriously. The platform embodies a number of vulnerabilities, however, some of which are standard for SaaS, and some of which are particular to Salesforce. In terms of standard risks, Salesforce typically holds data, such as customer account details, that companies want to remain private. That data is at risk for breach from malicious actors, as well as insiders.

This problem is not different from what happens with other SaaS apps, but Salesforce’s deployment is usually so broad and interconnected in an organization that it amplifies the risk. It’s likely that every sales, marketing, and customer support person in a company, as well as their respective managers, has access to Salesforce. That’s a big, diverse group of potential insider threats and identities that can be hijacked by attackers. And, Salesforces is usually integrated with email systems, enterprise resource planning (ERP) platforms, accounting systems, and more. It’s a gateway for attacks.

Salesforce-specific risks include:

• Custom code vulnerabilities—Salesforce enables customers to create custom-coded functions with its Java-like Apex programming language. Apex enables developers to build apps that can call on the Salesforce backend database. While useful, Apex classes potentially expose sensitive Salesforce data to unauthorized database calls through its application programming interface (API). This is of particular concern if Apex is configured “without sharing,” a setting that ignores the user’s permissions and allows to access to records and the ability to change records.
• Configuration weaknesses—It is possible to configure Salesforce in ways that expose data to overly broad access. For example, the Salesforce Community module, which enables customers to set up public sites for their customers, can be configured to allow database access for guest users. Done wrong, this has led to data leakage.
• Integration risks with third-party applications—Salesforce integrates with literally thousands of applications, many of which are created using Salesforce developer tools and APIs. The potential for improper access and malicious activities on the platform is extremely high as a result.
• Social engineering attacks—This threat is not unique to Salesforce, but again the breadth and scope of the app in most organizations makes it vulnerable to hackers who impersonate work colleagues to pry loose access credentials and other data from unsuspecting users.
• API vulnerabilities—Salesforce publishes numerous APIs that give other applications access to data and functionality on the Salesforce platform. While beneficial in business terms, the APIs create risk. One example is problems with object and file level security, where developers might create an API call that does not consider the specific fields that are accessible, updatable, or deleteable on the object invoked by the API. There are also significant risks that arise with the creation of third-party applications that invoke the Salesforce API, but which themselves are deficient in terms of security.

Why you need to invest in Salesforce security

It’s wise to invest in Salesforce security for a variety of reasons. It should be part of your SaaS security program, if nothing else. Salesforce deserves extra attention, however, because of the potential business impacts of a Salesforce security incident. Salesforce customers ranging from Ohio’s Huntington Bank and the State of Vermont, for example, are dealing with the reputational fallout and expense of data leakage from Salesforce Communities they set up. If you don’t want to deal with the kind of problems they’re having, it pays to focus on Salesforce security.

14 Essential Steps to a Secure Salesforce Environment

What can you do to bolster your Salesforce environment’s security? There are many countermeasures available to defend Salesforce. They comprise policies, processes, and technologies. Here are 14 that should be considered high priorities. They fall into three broad categories: User management & permissions, data and application security, and monitoring & logging. Luckily for Salesforce customers, the company offers a rich toolset geared toward securing Salesforce environments.

User Management & Permissions

Managing users and staying on top of access permissions is essential for success with Salesforce security. In particular:

1. Adopt the principle of “Least Privilege”: A Salesforce user should have the fewest possible access privileges. Applying this principle requires some thinking and planning as to user roles and what each role is allowed to access. The principle of “Least Privilege” should also apply to system admins and developers who work on custom Salesforce apps.

2. Implement strong passwords & MFA: The ability for Salesforce users to log in from anywhere, on virtually any device, is good for productivity but bad for security. It is a good policy to require strong passwords and multi-factor authentication (MFA). These countermeasures reduce the risk of malicious actors gaining access by guessing passwords or using stolen login credentials. Salesforce has its own native MFA feature, but customers can also use third-party solutions like Okta and Duo for this purpose.

3. Disable inactive users: It’s smart to purge former employees or other people who no longer need access from Salesforce.com user rolls. Inactive user accounts are ripe for takeover by attackers. This should not be a manual process, but rather something that takes place automatically through integration with identity management solutions that provision/deprovision all system access for employees.

4. Integrate Salesforce.com with IAM solutions: Salesforce has its own self-contained user management system. However, it is not a good idea to let Salesforce be an identity silo, with a Salesforce admin taking care of provisioning/deprovisioning access. It is better to integrate Salesforce with your organization’s identity and access management (IAM) solution, such as Microsoft Active Directory. This integration enables you to switch Salesforce access on or off centrally when employees join or leave the company, or change roles. Allowing single sign-on (SSO) is a variant of this approach, enabling users to log in once and then automatically be signed in to Salesforce and other apps. Salesforce enables SSO through integrations with Okta, Duo, and many other SSO solutions.

5. Map organizational structure and roles to Salesforce access rules: Salesforce functionality and access privileges are hierarchical in nature. For example, a Sales Manager can see the activities of her direct-reports. Her manager, in turn, can see her activities, and so forth. It is a good practice to map your organizational structure carefully to Salesforce role definitions and privileges.

Data and Application Security

6. Implement field-level security: If you are using Apex code or Salesforce APIs, it’s wise to implement field-level security. This control forces you to decide which fields are exposed to access by the API or Apex classes. It is a countermeasure against exposing sensitive data to breach.

7. Implement data encryption: Salesforce offers the Shield Platform Encryption feature, which encrypts data at rest on the Salesforce platform. Using Shield helps you protect your Salesforce data from breach.

8. Implement Data Loss Prevention (DLP): Protecting Salesforce data from loss should be part of your Salesforce security program. DLP for Salesforce can take a variety of forms, but it mostly involves policies and processes like role-based access control (RBAC) and regular backups, which is possible using tools like Veeam.

9. Mitigate third-party application risk: Third-party apps pose a major threat to Salesforce, in part because Salesforce has little control over the quality of development and security of the third-party integration plugins that connect to its platform. SaaS security solutions are able to scan for third-party plug-ins and flag integrations that may be creating risk in the Salesforce environment.

10. Engage in secure app development: If you’re developing applications for Salesforce using Apex or other developer tools, you would be wise to engage in secure development practices. This might mean using the DevSecOps methodology or other approaches to securing the development lifecycle. On a related front, it’s smart to review any AppExchange app carefully for its security before allowing anyone to implement it in your Salesforce environment.

11. Build an IP whitelist: Salesforce enables IP whitelisting natively. This countermeasure enables you to restrict the range of Internet Protocol (IP) addresses that can access Salesforce, e.g., only IP addresses in North America.

12. Focus on API security: APIs are a major attack surface for Salesforce, so it’s a good idea to define and enforce security policies that reduce API-based vulnerabilities. This process may align with existing API security and governance programs occurring in your organization already, so it may not be necessary to spin up API security just for Salesforce. Possible countermeasures include scanning for “rogue” or abandoned Salesforce API integrations, managing API access, perhaps using IAM and privileged access management (PAM) solutions, and using API security tools to discover APIs that are vulnerable to injection attacks, and so forth.

Monitoring & Logging

13. Create audit trails: If you’re not at a large company, this may not be a priority, but in general, it’s useful to create audit trails for review by stakeholders that range from executives to internal auditors and external regulators. Salesforce enables this capability natively in their Audit Trail Tab.

14. Develop and test Salesforce.com incident response processes: There is some probability that you will have a security incident with Salesforce. It pays to be prepared. An incident response process for Salesforce might be the same as you have for other SaaS apps. SaaS security solutions sometimes offer SaaS detection and response (SSDR) capabilities, so you can leverage those to keep things simple.

Making Salesforce Secure

In a perfect world, whatever you’re doing for SaaS security would cover all risks affecting your Salesforce environment. This is not a perfect world. The reality is that Salesforce is so far-reaching in the average organization, and so deeply interconnected, with diverse classes of users, that it embodies a unique level of risk. For this reason, it is a good practice to focus on Salesforce security, taking concrete steps to manage user access and permissions, protect data, and monitor Salesforce for signs of attack.