Keep the Keys: How to Secure Salesforce While Working with Service Providers
Do you allow vendors access to your systems? Most companies do. Enabling service providers can be an effective way to get capabilities you don’t want to build in-house. The problem is when you don’t strictly manage their access. Too often, we run across wealth management companies who are relaxed about vendor access to secure systems. This is particularly risky in this space due to the high degree of Personally Identifiable Information (PII) you handle and store in your databases every day.
At Red Argyle, we invest a lot into the security of our infrastructure. We run background checks, secure our tech stack from the bottom up, and keep up with security best practices. But we’d be upset if you didn’t vet us before giving us access to your Salesforce—that’s just good security.
In fact, nearly all best practices and compliance statutes (for wealth management companies, particular ones of interest are Gramm Leach Bliley Act [GLBA] and FINRA), require a high degree of scrutiny for any service providers that will introduce new stakeholders to your secure systems.
In this post, we’ll cover four general and Salesforce-specific principles you should follow to make sure you’re exercising the proper level of oversight on any vendors with access to your systems.
For more guidance on this and six other core cybersecurity domains, download the whitepaper: Salesforce and Cybersecurity: A Roadmap for Regulatory Compliance in Wealth Management.
4 Security Best Practices for Working with Service Providers
Do you know the best possible way to minimize your risk exposure with vendors? It’s to remove the risk altogether upfront. You can do this by not giving vendors the keys to the kingdom during the engagement. The guidelines below help you set up these safeguards.
1. Practice least privilege security monitoring
You practice least privilege security monitoring (this means giving only the amount of access required to do the job) all the time for internal users—we could argue it’s almost more important with service providers. Why?
When you work with an employee, you have a longer term relationship. You have more control over the relationship. Usually, they’re logging in from an internally managed infrastructure. But when you work with a service provider, you don’t get any of this. They might use a questionable infrastructure. You don’t have the same degree of control and visibility. Their turnover could be high. So be thoughtful about how much access you give vendors. When you do give any vendors access to your Salesforce instance, you can apply the best practices we recommend for employees to vendors.
Here’s how to practice least privilege security monitoring in Salesforce:
- Assign minimal permissions. Only assign vendors minimal permissions possible to execute their project scope. Access should be based on a very specific reason for the right duration of time to accomplish the specific task.
- Use Salesforce Shield Platform Encryption to encrypt data, and do not assign decrypt permissions to vendor users.
[Callout] Vendor access should be for a very specific reason for the right duration of time to accomplish a specific task.
2. Don’t give production environment access.
Do not allow vendors any access to production systems under any circumstances. This is a foundational rule, but a good one to be reminded of—only give vendors access to staging systems, rather than the production environment. Why should this be avoided? In a production environment, your vendors can access all the latest, up-to-date customer data. Even if nothing happens with their access to that data, you’re creating a big liability.
Apply this to Salesforce with these two tips:
- Use sandboxes. You should maintain specific Salesforce environments (sandboxes) which are purpose-built for vendor access and activities. Here, you give vendors a realistic area to build in while keeping them separate from your data. You can also add extra full or partial copy sandboxes to allow them to work efficiently with realistic data.
- Employ Salesforce Data Mask. This is a tool that obfuscates and/or anonymizes any data classified as PII or Sensitive PII (SPII) within these sandboxes. This way you can create a realistic environment for them to work in, but provide no real data.
3. Use only your hardware and software
Another way to stay compliant is to ensure that vendors are only using your organization’s provisioned hardware and software to provide services. Limiting vendors to your own tools means you avoid any risks with their unvetted hardware and software. You maintain end-to-end control of vendor access, allowing you to prevent data loss outside of your perimeter.
Salesforce security can feel like a black box you don’t want to open. We hope this post demystifies some of that for you (there’s more where that came from in our Salesforce and Cybersecurity whitepaper).
4. Run audits.
Once you’ve got the vendor going, check up on them. Don’t set them up and forget them. You should periodically audit their activities to validate they’re operating within acceptable safeguards and performing only required project activities. If this poses a capacity problem for your team, you can employ other third party vendors to conduct these assessments.
In Salesforce, use Event Monitoring to validate vendor activities vs. project scope. This is part of auditing. Compare what the vendor was supposed to be doing with what they are actually doing—what are they downloading or accessing? These reviews ensure you catch any untoward vendor exploration.
When we work with clients on their security, we start with identifying risk. We pinpoint the data people shouldn’t have access to, and then we give you a plan and the power to protect it. Want to learn more?
