Data security is a hot topic in today’s digital world with more sophisticated hackers, breaches, policies, requirements and private information (e.g. PII, ePHI, etc.) moving to the cloud. Salesforce is one of the major cloud platforms companies are storing private information on, and as Salesforce experts, we get asked a lot about the security of the platform.
Well Salesforce is just that – a platform, not a product. Salesforce does a great job of making their platform highly secure with fundamental security tools, BUT it’s a platform and you can still make mistakes on the platform that can increase your risk exposure.
Have your developers customized the platform in a way allowing information to be moved or copied to disjointed systems that you don’t know about? The platform becomes more complex and custom as admins and developers tailor your instance to your business needs. It’s easy to lose track of how your information is being used and where it’s going when your main focus is on improving the business.
So how do you know if your Salesforce information is at risk? Companies need an action plan to validate their current security standing. In this post, we’ll walk you through some high-level steps of how we identify risk and ensure long-term sustainable Salesforce data security for our customers.
Phase 1: Is your security stance well-defined?
During this phase, you’ll need to define what security means to you with regard to Salesforce and data stored in the cloud. First, talk with your security, compliance and legal teams to make sure everyone has a full understanding of all the implications involved with storing certain information in the cloud vs on-premise.
The key to this conversation is to talk about how you want Salesforce to work in the future, not only how it’s currently being used. Don’t look to change anything until you have a clear and objective view of where you want to be from a data protection standpoint. Take everything into consideration like industry, obligations to investors or shareholders, and regulatory compliance needs (i.e. SOC, SOX, PCI, GDPR, FINRA, HIPAA).
The only thing constant about your Salesforce org is that it will constantly change. It’s important to define a stance and establish rules that are adaptable, while also maintaining core security principles.
Phase 2: How is your company really using Salesforce, and how does that align to your security stance?
Know what data is in your system
Data Classification Exercise: Now that you know where you want to be (your security stance), let’s find out where you are today. Conduct a data classification exercise to understand what’s currently in your system. Start by looking at the information currently being stored on the platform. Is there PII, PHI, etc.?
Security at Rest: Review the data types and if highly sensitive information is secure at rest. We may recommend Shield Security Platform Encryption if you don’t already have it. If you do, you can use Own Secure to identify what’s needed and how to do a quick business impact assessment regarding the introduction of database-level encryption.
Beyond the “Health Check” feature: How exposed is your data? Do you know what your developers are doing and what your data exposure footprint looks like? This is beyond a health check. This is an objective review of the code and configuration in the org (more than just checking the default settings) from a security perspective including:
Look at the code and configuration: Salesforce has a “health check” feature in the setup menu that checks against industry best practices and the switches and settings Salesforce has made available to you. It checks to see how many you’re leveraging at a highly secure level (session settings, password policies, etc.).
However, you must go beyond the health check. The health check won’t look at the actual code developed by software developers or point-and-click configuration done by admins that can leave you exposed at a high degree. You must conduct an objective review of the code and configuration in the org (more than just checking the default settings) from a security perspective and look at:
- API integrations outbound from Salesforce (sending out to other third party or other in-house systems)
- Publicly addressable APEX web services that may have been developed that could be sending out sensitive information in plain text when it shouldn’t be
- Workflow outbound messages
- Any manual sharing that may have inadvertently shared information with people who shouldn’t have it
- TLS and other org wide settings
Interview Process
We’ll then perform an interview process with people that are using the system to look for custom integrations to the Salesforce API (e.g. billing systems) and the security of data storage in external objects. The purpose of this interview process is to make sure the external databases are secured appropriately.
Is your Salesforce security model well documented and kept up-to-date?
Lastly, we’ll document the Salesforce security model and review the implementation. Most organizations don’t really know what, when and why everyone in the company is seeing and doing things in Salesforce so it’s important to map everything out to create a security command center:
- Roles
- Profiles
- Permission sets
- Org wide defaults
- Sharing rules
Properly documenting and understanding this can often shed light on things that shouldn’t be happening. It could be a major compliance risk or something you just don’t want happening, like employees seeing each other’s salaries.
Phase 3: What's your action plan to achieve your security goals?
After we review the documentation and make sure everyone has a solid understanding of how the organization is currently using Salesforce, we’ll provide recommendations and create an action plan based on the security stance we helped define.
An action plan is a series of mitigation activities to close the gap between your current Salesforce use and your security goals. Our action plan includes user stories, epics and an implementation timeline with estimated hours for each activity.
Now’s the time to make sure your Salesforce instance is secure by applying this process to your company.Request a free Guided Risk Assessment for Salesforce today, or schedule a demo below.
