Salesforce Security can be compared to driving a car – just as there are blind spots while driving, there are blind spots in your Salesforce security. When learning to drive, you’re taught to pay attention to blind spots as you make turns and change lanes to help keep you safe and encourage defensive (proactive) driving. The same should go for the security of your Salesforce org.
Blind spots need extra attention to ensure your environment is secure. In this article, we will discuss who is responsible for data security, as well as three major security blind spots to be aware of to help avoid risk and keep control of your security posture.
Security Is a Shared Responsibility
Unfortunately, some people ignore these blind spots because they don’t fully understand the concept of the Salesforce Shared Responsibility Model. Protecting data is a joint responsibility between you and Salesforce. Below you can see what Salesforce is responsible for versus the responsibility of the user.
| Salesforce’s Responsibility | User Responsibility |
|---|---|
| Core Application | Personal Identifiable Information (PII) & Other Sensitive Data |
| Network Controls | Custom Code |
| Server OS | 3rd Party Libraries |
| Physical Servers | Configurations |
| Physical Networks | Installed Cartridges |
| Physical Data Center | User Accounts and Permissions |
| Device Security | |
| Compliance Requirements |
There is an assumption that the responsibility of security risks falls solely on Salesforce – this is false! As a result, many companies end up ‘putting their head in the sand’, and security issues are only dealt with when they surface (reactive security).
This mentality leaves security vulnerabilities hidden and obscured, creating a very unhealthy (and potentially costly) security environment. Effective security leaders need to arm their teams with the right tools and processes so they can practice proactive security and always keep security blind spots within the field of vision.
With the understanding that risk is a shared responsibility, we’ll now review three common Salesforce security blind spots to help avoid potential data leakage.
1. Over-Provisioned Users
Too many permissions
One of the most common ways for a data leak to happen is having too many people with too many permissions. This often occurs because many admins and developers may not be aware of which permissions do what and why a user might need access in the first place.
Removing permissions is a good thing and Salesforce Admins, Developers, and Architects need to understand the impact of turning a permission on or off for a specific type of user.
Permission types
Another factor with over-provisioned users is permission types. Salesforce has around 300 types of permissions that can be customized, and with every release, they tend to add or remove permissions in order to keep the anonymous internet from getting access to your data.
The problem is that many companies wait until the update is automatically enforced and don’t test these new additions/removals once they happen. People then become reactive to the updates by creating workarounds instead of taking the time to understand why they were removed by Salesforce in the first place. This leaves permissions unaccounted for and untested, and creates likely security risks.
Companies need to stay up to date with Salesforce releases. They need to research pending changes to understand why the change was made, as well as the security implication behind it. Then they need to adapt their permissions to their users and profiles to maintain their Salesforce org security in the context of the new release.
2. Insecure Coding Practices
Companies often falsely believe that creating custom code or using out-of-the-box tools like Salesforce Flow won’t create security issues. This really isn’t the case as custom code can have security holes, and certain flows can create unintended risk when executed.
These are the key principles to keep in mind when creating configurations and building logic:
- Who will have access to the configurations and data?
- The flow of the data (whether through code or tools like Flow).
- Always implement the concept of least privilege.
This does require more work and the build can be more complex, but it will provide a higher level of protection against damages from breach.
Another insecure coding practice is making the assumption that if an API isn’t made public or if something is hidden behind the UI, it can’t be accessed. That is not true. More and more we’re seeing data sets that are accessed by frameworks – regardless of interface.
Relying on UI to prevent users from accessing and manipulating data is not an appropriate way to protect it. Users need to start with field-level security, enforcing CRUD and reviewing the sharing model – just as you would on the internal side of things.
3. Not Understanding Attacks Are Happening
One of the main reasons companies don’t understand that attacks are happening to their Salesforce org is because they’re not monitoring for it. This goes back to the ‘head in the sand’ mentality around security, because many think that Salesforce alone is responsible. Knowing that this is not the case, companies now need to proactively monitor security on a continuous basis.
A great but underused Salesforce product is Event Monitoring, which comes with Salesforce Shield (or can be purchased individually). Event monitoring can contain a ton of data about what is happening in your system, including security.
Integrating these (or other security scanning tools) into your processes can surface the use cases that attackers are really going after. Many companies performing proactive monitoring can be surprised to learn that hackers are attacking their systems on a daily basis.
Every company needs to practice proactive security – whether that’s people, processes, tools, or a combination of all three. With the knowledge that there are hackers poking around your Salesforce org, you can take the necessary precautions and lock down the areas that need it most.
Final Thoughts
Watching out for blind spots while driving can help avoid crashes – just as accounting for security blind spots in your Salesforce org can avoid data leakage. The first step towards better security is understanding that it is a joint responsibility between you and Salesforce. From there, you’ll need to take steps towards avoiding:
- Over-provisioning users with too many (and unnecessary) permissions.
- Insecure coding practices such as relying on UI to safeguard data.
- The fact you may be under attack daily and need proactive security monitoring.
These blind spots can become more visible if you take the above actions, which will give you back control of your security posture as you inevitably change lanes with your security practices.
Comments: