We’ve all seen those movies where the good guys break into a secure facility. Somehow they sneak right past the guards who always follow the same path and dismiss every single sound – a cough, sneeze, or twig snap – “it’s probably nothing.” But do you ever wonder how well the system behind the ‘secure’ facility is designed? There are cameras, patrols, motion sensors, and door alarms. The system should be robust enough to keep those pesky intruders out.
Hollywood aside, let’s all recognize that vigilance is a never-ending task, and your Salesforce Org is no exception. There are multiple layers of protection that can help to keep your Salesforce Org safe and secure. Let’s take a look.
The Challenge is Real
We may not have to contend with Hollywood writers penetrating our security perimeters, but we should recognize that we do maintain valuable enterprise data in our Salesforce Orgs – especially customer personal data or personally identifiable information (PII).
We have to assume that an attack could come at any moment from a variety of different vectors. Luckily, we have a great partner in Salesforce. This partner delivers an amazing platform that gives professionals like us a secure foundation to build upon.
But it’s important to remember the Salesforce Shared Responsibility Model. In this instance, shared means that as soon as we begin to change configurations, perform custom development, or install apps into our Org, we become responsible for the security of our data and PII.
In short, as soon as we start changing Salesforce and introducing security vulnerabilities, our data becomes an attractive target. It’s our responsibility to protect it.
There are three ‘Layers of Security’ that we are responsible for within the Salesforce Shared Responsibility Model:
Application Layer
- Custom Code (Apex, Visualforce, LWC, Aura)
- Software Libraries (Open Source components like jquery, etc.)
- Runtime (XSS, SOQL & SOSL injection flaws)
- Third-party packages (Managed apps from AppExchange)
Architecture Layer
- User Access Controls – Principle of Least Privilege
- Object Permissions – Access where access is needed
- Auditing, Event Monitoring and Logging
- IAM – Identity and Authorization Management (ie SSO, 2FA, etc)
Data Layer
- Encryption
- Data Masking
- Data Backup and Restore
Answer the Question
Security is the process of maintaining a reasonable level of vigilance to allow you to focus resources on moving your business forward. So, when is your Salesforce Org not secure? It’s when these three important points are missed:
- Not evaluating every external and internal customization.
It may be obvious, but the first step is making sure every custom development effort, configuration modification, or app installation takes advantage of the best security testing available, and doesn’t imperil your Salesforce security posture. For external threats, the scope is Salesforce Community and Force.com sites. For internal threats, the scope is all internally facing Salesforce services. It’s important to check each time a change is made. Inadvertently introducing vulnerabilities will put you at risk. - Not evaluating third-party software libraries.
If your Salesforce development leverages third-party software libraries (e.g. Javascript-related or open-source packages), you’ll need to make sure that they aren’t outdated with posted Common Vulnerabilities & Exposures (CVEs) or public exploits reported on them. When a version of that library is insecure, you need to take action either by patching or replacing the library. - Not regularly monitoring your code base.
You need to regularly monitor your code base and configurations, because any change can impact your perimeter. You need to be aware of any vulnerabilities immediately.
Taking a step back, let’s focus on the point at which everyone in your organization feels confident with the Salesforce security processes in place. How do you get there? Start by asking yourself these questions:
- Do your developers and admins test their work early and often, before deployment?
- Are security and compliance managers assessing your Salesforce security posture continuously?
- Is the security posture status of your PII regularly communicated up to executive leadership?
Salesforce DevSecOps: Security is a Process, Not a Destination
If you have a Salesforce DevSecOps process in place that provides positive answers to the questions above, you’ll know that your security is proactive and your posture is strong. Otherwise, your process is likely reactive and requires reinforcement – you’ll need support from the top in terms of budget and resources.
Talk to your team about the following areas:
- Have new customizations been tested thoroughly for application security flaws?
- When was the last time all third-party libraries in your Org were checked for publicly posted CVEs?
- Configuration changes that were made to your Org that were neither planned nor scanned.
Uncertainty is the clearest way to tell if your Salesforce Org is not secure. However, if your company has established a clear and rigorous process for Salesforce security (with everyone on the team able to test against that standard), you’ll know that your Salesforce Org is proactively protected.
Take Action
Here are some immediate actions you can take to secure your Salesforce Org:
- Make security reviews a regular agenda topic for your Salesforce team.
- Establish a security baseline that everyone in your organization feels comfortable with. Then devise tests and checks that assess your code, libraries, apps, config, and integrations objectively.
- Recognize that this is not a one-off exercise that only needs to happen once a year; it is an evolving process. As technology always changes, security processes require constant adaptation. Even if you make no changes inside your Org today, you’ll find that external vulnerabilities and exploits arise all the time.
Summary
There should be a regular cadence as well as an ad hoc capability to evaluate Salesforce security. This way, you’ll have both the confidence and intelligence that the processes protecting your Org are being followed diligently – while making it harder for the ‘bad guys’ to sneak past!
Further reading for Salesforce Security:
- 7 deadly sins of Salesforce security – CSO
- Why SAST isn’t Fast for DevOps – SalesforceBen
- RoadToCTA Salesforce Saturday – Waqas Nazir on Security – YouTube
- How to Keep Data Secure from Insider Threats to Salesforce – SalesforceBen
- How to help earn customer trust by securing data in Salesforce – PWC
- DigitSec S4 Covers Salesforce Security Concerns with Innovative Tools – SalesforceDevops