A recent report has drawn attention to the risks associated with permitting guest accounts overly broad access to data in Salesforce Experience Cloud (a.k.a. Digital Experiences). Significant misconfigurations have resulted in exposing numerous customers’ sensitive data across a number of their public Salesforce Community sites.
Organizations that store personal or sensitive information in Salesforce are at risk of this data being accessible to anyone on the Internet. Once the data is exposed, it's out there for good, making it essential to monitor the darker corners of the Internet for any leaked data. External users may also cause additional issues by deleting or altering data, which requires SaaS response and recovery using Own Recover. These risks are particularly costly for highly regulated organizations such as healthcare providers, financial institutions, and insurers, highlighting the value of Own's (formerly OwnBackup) full suite of solutions.
Misconfigurations within Salesforce are one of the most common data security challenges that we help organizations with through our Secure product. In the context of shared responsibility, Salesforce treats this problem as a customer configuration issue. However, fixing this problem is not as simple as disabling guest account access since some organizations require this feature of Salesforce Community to function. In addition, Salesforce has yet to fix some inherent coding type vulnerabilities introduced by the ability to see unintended object information by modifying the Salesforce Community URL.
Ensuring your SaaS security posture
This problem stems from Salesforce embedding access privileges within Profiles. This makes it difficult to determine who sees what, making it harder to review and manage user access and permissions. Further, those with more mature Salesforce orgs are likely to have the most Profiles persistently over-assigning access and not implemented per the Principle of Least Privilege.
Here is where cybersecurity ends and data security starts, as articulated in the Data Security Maturity Model (DSMM) and illuminated by Own Secure’s Who Sees What (WsW) Module.
First, you must manage the access and permissions granted to your community and guest user profiles. To validate that Profiles & Permission Sets used by external users are correctly configured from both a permissions and access perspective all in one place, Own Secure’s WsW P/PS/PSG lens is invaluable. Figures 1 and 2 below illustrate viewing this valuable information in a simple, exportable view. Having this information organized in one view empowers you to maintain least privileged access, i.e., that external accounts only have the minimum necessary access or permissions to base object and field-level objects.
Other WsW lenses and Security Insights provided by our Secure product give you visibility into additional risks, including system security issues, high-risk accounts, objects that should be monitored, and access/permissions at the Object and Field levels.
Next, you need to review sharing mechanisms to determine if they are appropriate for your Salesforce Community implementation. You can do this with Salesforce Portal Health Check to review Org-Wide Defaults, Sharing Rules, and Sharing Sets, as shown in Figure 3 below. If the default access is not set to Private, make sure you have not granted excessive sharing.
Finally, it is important to review custom code in Salesforce, which requires specialized skills and tools. Even if the Salesforce security model is set up appropriately, it is remarkably easy to introduce Apex code that can undermine user authorization. Own customers can request a Guided Risk Assessment that includes scanning their code to identify potential vulnerabilities, particularly on Apex classes that interact with Salesforce Community implementations.
For longer-term risk management, use Secure for ongoing observability in case someone accidentally opens access again. High-Risk Permission Assignment alerts are configured as shown in Figure 4 and fire once a Security Insights analysis job has run. Users subscribed to these alerts will receive notification(s) when high-risk permissions have been assigned that include both the permission and the impacted users or profiles/permission sets. Suppose one knows they have a Salesforce Community configured for their org and the profile(s) used with it. In that case, this can be an easy way to keep aware of changes to the external profiles that increase the risk/likelihood of an incident with Salesforce Community.
Next steps
In addition to misconfigurations, there are other security gaps that Own Secure helps mitigate. In our webinar, “Top 5 Salesforce Security Gaps Our Risk Assessments Revealed”, we reveal the five most common misconfigurations and vulnerabilities you should be aware of in Salesforce, summarize the findings, and show you how Own can help you mitigate these risks in the most efficient way possible.
Watch on-demand or request a demo below.
