Brian Soby, AppOmni CTO Talks About Guest User Access in Salesforce

By Brian Soby, CTO and Co-Founder, AppOmni

Video Transcript:

My name is Brian Soby. I’m the CTO at AppOmni. We are a SaaS security company. Most of us over here at AppOmni come from in-house security teams at large SaaS vendors, whether that’s Salesforce or ServiceNow, Slack, or similar organizations. So we’ve really felt the pain that customers have had in working with these systems and how hard it is to, as a security team, keep track of what’s going on in all the different SaaS systems that you use within an organization. And that’s really the challenge that AppOmni helps you address, to do that across your organization.

This morning we, like probably most of you, got an email from Salesforce, talking about guest user data access. It was a security alert saying we’ve made some changes related to guest users, and here’s what you need to do to assess whether or not you have these issues yourselves.

So first, let’s back up a bit and talk a little bit about what a guest user is in a Salesforce system. “Guest user” is the context in which the anonymous world accesses your data or your environments. Salesforce has a huge number of external interfaces that are intended for collaboration between your internal users and your internal environments – and then with the external world. Those interfaces are customer community portals, where customers can come open support tickets or cases and follow up with their cases.

Lots of organizations also may have partner portals. With these, you may have a totally custom business process running on top of Salesforce, where you may have a product portal. You could have a place where folks come to, to look at knowledge bases or information about your company or products. And many of those have external users that come in and they create accounts and they can interact with their cases. But there’s also this concept of the anonymous context – that is a guest context. That is…what is the context of the login page itself? Or if you have something that is promoting externally consumable content, like a knowledge base article, where folks don’t have to log in, that is retrieving data from your internal Salesforce configuration and your objects and exposing it to the outside world. Specifically, what data should be exposed? Let’s say only those knowledge-based articles that are published should be exposed. So you would configure only publish articles to be exposed to the guest user. And that’s going to say that those external entities can access only those. Salesforce will, as it always does, very faithfully execute its configuration. And it will say, the guest user is, or is not allowed to access these particular articles.

So a couple of big challenges come in here. One is that most organizations have many guest users. It’s not just, there’s one single context for the anonymous world. Every time you create a community, typically that creates something called a “site.” A site is an anonymous interface, that’s something that’s going to be associated with a guest user in every one of those sites has its own guest user context. There’s actually a secret kind of hidden user that really represents a guest user. And you can figure that like you do any other user in your system. It has its own profile. You can assign it to various things. For a while it could own records, it could be in queues, it could be in public groups – all those things that you use within a Salesforce environment to expose records externally. So, one of the challenges that people have is Salesforce is a very robust product. You can put any conceivable business process on it, but with that robustness comes a level of configuration flexibility. And you need to, at all times be aware of what data in what elements of that system have been configured to be exposed to a broad audience.

That broader audience could potentially include your guest users. You could have – previous to some changes that Salesforce made probably about a year ago – a guest user who if they came and somebody anonymously opened a case on your site, the guest user would continue to own that case. And because the guest user really represents the entire anonymous world, what that meant is the entire anonymous world could bring back up any previously filed case from anything – such as partner deal registrations, or other things like that. 

So Salesforce, very smartly made some changes that were intended to prevent guest users from owning records. They changed some defaults. So guest users didn’t by default have the ability to be involved in certain record level considerations. But a couple of things that kind of went unstated is that you have a responsibility. You as a customer, have a responsibility to take that the rest of the way. If somebody had previously, if you previously had that partner deal registration or anonymous case submission, and the guest user submitted those because it was done by virtue of somebody not being logged in, they would continue to own it, even after these changes that Salesforce made. So they made changes to stop the bleeding, so to speak, to say that guest users, as of this moment, all of their data must always be assigned to some other user. But if you had 2 million cases or deal registrations or other things that existed previous to those changes being introduced, then the anonymous world would continue to own them. Within Salesforce, “ownership” gives you the ability to read something. Additionally, it’s usually a reason that you can edit it, delete it, and do other things.

So really, I think what that email is highlighting is that there are other steps to take. And one of the things that it didn’t really address was that this fix is not a one-time thing. This is like any living system, which is what a lot of your SaaS systems are, you need to know on an ongoing basis, what is happening with it. Because it’s entirely possible that at some point you will have a big project. You will do all these steps and you will make sure that everything’s good today, but you’re making changes in these systems, and the vendors like Salesforce are making changes to their platform and improving it all the time. You also have – certainly in the Salesforce ecosystem – quite a few third party packages that connect to the system and they can make changes. All of these things are continuously introducing new changes. And so you need to be aware at any given point, are your systems still configured to do those things that you intended? If you have a business rule that says only knowledge base articles are intended to be published externally, how do you know that that’s actually remaining true?

That’s one of the big challenges within SaaS. When we work with customers and prospects, we have a very quick process where we connect the AppOmni for Salesforce module to their Salesforce environments. And we can within an hour or so, give them a full scope evaluation of what their risks are. And just really highlight that in these living systems, you need to be aware of what’s being exposed and how. Because it is a very powerful, very robust platform and it will do what it’s configured to do. It doesn’t matter if, for example you’ve hidden the buttons to things, or if your knowledge base site doesn’t have a link to go retrieve your accounts, your contacts, your opportunities, all of your internal records. If the platform has been configured to expose those things, Salesforce will absolutely faithfully execute that configuration. We have a number of articles published by security researchers out there showing step by step, how you as the anonymous user go and do that.

So that’s really what that email covers – it’s just bringing this issue to your attention. Something that has been an ongoing challenge for a lot of organizations. We’ve had a lot of organizations contact us after they either they have some sort of a data leak or a data breach, or a security researcher brings something to their attention. They realize that that is the tip of the iceberg. Hey, if this is exposed to the anonymous world, what about all my customers? What about my partners? What about internal users? How are my third party integrations working? Do they have access to more things than they should? This is just how SaaS works. While SaaS takes care of a lot of the responsibilities that you have – you don’t have to maintain infrastructure, things like that. You are still responsible for your configuration. And that’s where we’ve been helping customers address these problems to let them know, “Given this specific configuration, here’s the effect of it. Is this consistent with your intent? There are potentially some security best practices that aren’t necessarily being adhered to based on this configuration.”

It is a challenging problem. I’ve been a security practitioner, my whole career. If you are a security team, you don’t generally have the opportunity to specialize. You don’t get the chance to say, I am going to be a security person only for these one or two SaaS products. Your IT counterparts very often do specialize in specific of certifications. They may spend a good portion, their career just in Salesforce, but your security teams are generally going to be responsible for 15, 20, all of the SaaS products that you use. And it’s tough. It’s tough when you’re covering that many systems to have deep visibility into the things that you need to be concerned about, or even awareness of what the things you need to be concerned about are. That’s how we’ve been helping customers. That’s how we’ve been addressing problems like this guest user stuff, as well as other problems related to SaaS.

Related Resources