Salesforce is one of the leaders of Software as a Service (SaaS). You may remember their old mascot – the dancing “No Software” icon-come-to-life that personified the concept that you could have powerful software outfitted over the web. No need to install executables! It was certainly radical when they first got going, and it’s taken quite a while for the rest of the industry to catch up.
One of the implicit elements baked into SaaS is the Shared Responsibility Model. At every layer of the stack, both the provider and the consumer have some sort of responsibility. In Salesforce’s case, you (the consumer) own the configuration and the customizations. Salesforce is flexible in that you can change the default settings and make it do what you want. But by doing so, you should also know that a single misstep could make you vulnerable. In this article, you’ll learn about four actions you can take today to secure Salesforce.
1. Review Access to External Users
When we talk about access and permissions for all users (both internal and external), we recommend relying on the “Principle of Least Privilege”. As you design your system, you want to give the least number of users the minimum amount of privilege within that system.
We certainly recognize that opportunities to make careful design decisions usually happen during the early stages of the development and deployment of Salesforce. If you are reading this post, it’s likely you work with a Salesforce org that’s been up and running for some time. So it makes sense to start checking the external users found in your system to see how they are able to interact with the data and objects within your org.
Ideally, you want to make sure that user profiles are given the very lowest level of privilege. Then use permission sets to layer any additional access. Salesforce orgs often extend entry to external users because they are trusted partners, vendors, or members of a community. But they also represent a user base that is fundamentally tangential to your core organization – it’s critical that you have a firm grip on their availability to your data and their ability to manipulate it.
To better secure Salesforce access and permissions, ensure that:
- Material with sensitive data is not shared with external guest users.
- Guest users don’t have “View All Users” permission.
- Guest users don’t have access to objects via manual sharing rules.
- Guest users are not part of public groups or queues.
- Guest users don’t own any records in your organization.
- Sensitive files don’t have access to “All Users.”
2. Evaluate Your Custom Code Against OWASP Top 10
If you write your own code for Salesforce, there is the possibility of introducing a security vulnerability that could ultimately expose sensitive information, or even giving malicious users the opportunity to infiltrate your system.
If you aren’t sure where to begin when evaluating your code for risk, start by looking at the OWASP Top 10. The Open Web Application Security Project is dedicated to helping create a secure internet. Their compilation of top threats is based on real-world observations and provided by their broad community of developers and system administrators. As you introduce custom code into your environment, you should evaluate how that code interacts with Salesforce, and if it opens itself up to vulnerabilities.
For instance, item number three on the OWASP list of vulnerabilities is “injection”. As a browser-based application, Salesforce must protect the attack surface from application code all the way to the user interface. Cross Site Scripting and SOSL/SOQL injection attacks are both coding vulnerabilities in the Salesforce context that are in the OWASP Top 10 list.
This is a great place to start when you’re checking and testing every line of your code against an exhaustive and updated list of vulnerabilities that might be prohibitive. More information about OWASP can be found here.
3. Audit Third-Party Access to Your Salesforce Org
Does your organization use a third-party system like Mailchimp, LinkedIn, or Dropbox? When you link such systems, you give them a certain level of permission to exchange data with Salesforce. Be sure to review and document this access on a regular basis.
Moreover, it’s important to keep a current inventory of said systems. Organizations often make a decision to discontinue using a service, but forget to terminate their access. Regularly updating audits and reviews can help your organization document that access and provide a clear sense of your expanded security perimeter.
Salesforce will continue to be a leader in SaaS and pioneers of software provisioned over the web. But as their Shared Responsibility Model states, you’re responsible for the vulnerabilities you create by customizing and developing on the platform. With this understanding (and by taking the three actions mentioned earlier), you’ll have some quick wins in your Salesforce security roadmap.
4. Security Health Check
Security requires constant vigilance. Every check and test completed today will need to be run again tomorrow to ensure nothing has changed. It’s important to leverage tools and systems that can quickly give you an objective understanding of your Salesforce security. A great place to start is the Salesforce Security Health Check. This tool can give you insight into your Salesforce configuration settings and allow you to track them on a regular basis. You will likely need other tools to evaluate all aspects of your Salesforce security, such as any custom code or apps you have deployed.
Summary
Do you secure Salesforce on a regular basis? If not, take charge! As discussed earlier, the Shared Responsibility Model of SaaS requires both developers and admins to strategize ways to protect their data and security. Remember, SaaS won’t do it for you! The four actions you can take today are the first steps to a healthy security regimen.
Document the permissions assigned to external users and make sure their access is minimized to only allow required functionality. Build your awareness of security flaws and review your code regularly to safekeep against new or existing vulnerabilities. Make a habit of regularly reviewing all the systems and software that have access to your Salesforce. Finally, gather a collection of tools that will help you run these checks on a frequent and automated basis. Then you’ll be well on your way to a secure Salesforce org.