How to Architect for Salesforce Experience Cloud with Security in Mind

With Experience Cloud in mind, I sat down with Tyler Ochsner, Director of the Experience Cloud practice at Slalom to chat about all things Experience Cloud. We talked through a number of topics around improving and maintaining Experience Cloud’s cyber security defenses, not only from an external perspective, but also from an internal one. According to Tyler, “it’s easy to create vulnerabilities with Experience Cloud, so we need to be intentional about the data surfaced and the data ingested through the digital experiences we create.” Working with customers to help cover their cyber security gaps daily here at WithSecure, I have to agree. If you want to read the start of our conversation, check out my previous post

Architecture vs Design

To the newcomer’s eye, architecture and design should be almost synonymous, but from a cyber security perspective, they couldn’t be more different. Architecture is thinking about the types of data that a customer needs to have a truly great experience on your portal or website. It is also thinking about what the experience needs to allow your customers to do with that information, but most importantly, what do you need to protect your customers from being able to do accidentally. The power of Experience Cloud to expose anything that you can think of inside your Salesforce to your customers is also its largest cyber security vulnerability. This means that adopting a security first mindset when architecting your user experiences is really the biggest step in reducing the danger of this potential attack vector.

Design is all about thinking how the user will need to interact with a page. If architecture is thinking about what types of data need to be exposed or available and how that data should be brought in, design is thinking about how the customer will actually interact with that data. How can you – the experience builder – create a truly great, sticky experience that keeps customers on your page longer so that you can continue to wow them? That’s the question the Experience designers are asking themselves. It is a mix of art and science at that point, but a very delicate mix that can easily lead to unintentional exposures.

This is why architecture has to be our first step in the process of rolling out or assessing an Experience Cloud site or project.

Breaking Down Your Requirements

Any time you start something new, what is the first thing you do? Start asking questions. If you don’t know, now you know. It is no different in building an experience or auditing an existing one. Who, what, when, where, why and most importantly how are your best friends in architecting or building the structure of data your Experience will rely on. These questions also allow you to place yourself in the shoes of cyber criminals who want to steal that data. Not only do you need to consider how your customer would use your site, but you also need to consider how a malicious actor might leverage the experience to find potential attack vectors.

I asked Tyler if there were any major cyber security threats or attacks that he had run across in his time with Slalom or just in the Salesforce ecosystem. As we discussed earlier, the power and configurability of Experience Cloud is both a blessing and a curse. An easily configurable platform makes it easy to create these great experiences, but it also means that it is easy for someone to make a simple change that has a complex waterfall of problems and cyber security issues. Some examples that Tyler threw out were Guest User sharing rules, Public API access, not properly marking pages that shouldn’t be crawled by Google or other search engines, malicious files and URLs being uploaded through Experience sites, and the list goes on.

As you break down the requirements for your Experience site, always approach it from the perspective of “what is the least amount of data or objects I can expose on my site that still allows my users to do what they need to do?” By following the Principle of Least Privilege, you can avoid many of the cyber security pitfalls of powerfully customizable sites on Experience Cloud, but you also need to be careful of other org-wide settings that could create a waterfall of consequences for your Experience site. This is where we tackle the exercise of an Architectural Audit.

Architectural Audit

An audit of your org is time consuming. It doesn’t matter if your org is 10 years old or 10 months old, there are a lot of settings, org-wide defaults, permission sets, profiles, roles, sharing rules, etc. to pour through as you assess your cyber security readiness or security level in Experience Cloud.

For each and every setting and control within your org, you need to have a reason or function that is documented and understood. For any setting that doesn’t have a reason, you need to restrict it. This is the Principle of Least Privilege. So much of cyber security is simply understanding what all of your parts and pieces are doing at any one moment of time. This is actually why “Plan” is the first stage in the Five Steps of DevOps.

Once you understand what everything is doing in your org and what data is being used, now you can go about adjusting those settings to grant access to build your Experience. As you can see, an architecture audit really is the logical first step to a successful and cyber secure Experience Cloud rollout.

Threat Vectors

You now have a solid understanding of what everything is doing in your org, who has access to what, what API is used for what actions and what your org is constructed to do including the pieces of it that aren’t being used (think Guest User Access). Now we need to think about how cyber criminals might exploit various entry points into our org. For this exercise, we can actually look at the points on our attack surface where those attackers have been successful in the past.

The lowest hanging fruit and often the first place a hacker will look to exploit an opening in your cyber security defenses is the Public API. The Public API is often overlooked as many teams either don’t use it or they leverage it for everything. The problem with exposing everything through the Public API is that you risk exposing more CRM data than you think or want. One of the ways that this has been seen is practice is through the use of a cURL script to utilize that Public API to pull as much data as possible from an org.

Keeping this Public API threat in mind, effective threat hunting will also consider your Org-Wide Defaults and what the relationships between objects may accidentally expose. One of the most often overlooked methods of exposure is through the accidental sharing of a Master object in a master-detail object relationship. When you share a Master object, the detail objects are included in that sharing rule. You can see how these cyber security risks can compound.

Speaking of sharing rules, think about the data you don’t want to share widely across all of your various partners. You have built a great partner community, but you don’t want to expose your partners’ information to each other. This is where your ability to imagine every possible threat vector comes into play.

Finally, one of the easiest methods cyber criminals have to attack your Salesforce is through the purpose-built channels built into the platform. Web-to-case, email-to-case, Experience portals, etc. all of these methods represent a significant cyber security threat to your Salesforce ecosystem. Each of these channels can accept files and URLs as part of their submittals. Removing the ability to upload files as part of a submission can remove some of the value you have Experience Cloud for. The easiest solution is to protect and invest in cyber security like you have for email and for endpoint. Thankfully, there are some easy to install and use solutions like WithSecure’s CPSF that can have you protected in less than 5 minutes.

Security 360

Now that you are aware of all of the channels you need to keep an eye on. You can begin to architect your Security 360. Just as Salesforce has created a Customer 360, you need to create a Security 360 that your team can reference and utilize when making their design and change decisions. Salesforce may be an incredible business facing tool, but it requires a comprehensive communication and change management plan to ensure your cyber security team is equally aware of the risks and threat vectors associated with Salesforce as they are aware of every other system in your overall enterprise technology stack.

Looking to get started with URL and file protection? Check out WithSecure Cloud Protection for Salesforce. Get started by filling out the Content Risk Assessment.