Key Security Best Practices for Salesforce Admins Using Data Cloud

Salesforce Admins Podcast

Today on the Salesforce Admins Podcast, Josh Birk talks to Jagan Nathan, Technical Architect with Customer Success at Salesforce.

Join us as we chat about guest user anomalies and what you can do about them with the Threat Detection app.

You should subscribe for the full episode, but here are a few takeaways from our conversation with Jagan Nathan.

The most important thing for a successful Data Cloud migration

Jagan works as a Technical Architect with the Customer Success Group at Salesforce. He’s focused on helping businesses use Data Cloud to de-silo their data so they can get a full picture of their customers.

Jagan estimates that 60-70% of the time you spend on a Data Cloud migration is used to make sure you understand what needs to be done. That’s because the most important decisions are around what objects and data sources you want to map and how it all fits together. If you need help getting started, his team has put together the Data Cloud Workbook Template to walk you through everything.

What is a guest user anomaly and why is it dangerous for your data security?

The biggest security issues Jagan encounters in orgs come from changes made to profiles and permissions over time. All those consultants can begin to add up! At some point, you need to do an audit of who can see what and apply the principle of least privilege.

And that’s the reason we brought Jagan on the pod, because one way this can happen is through something called a guest user anomaly. Essentially, it’s when a guest user account has more access than it otherwise than it should. For example, an Apex class that allows them pull all of your data. It’s the kind of thing that’s difficult to identify but can leave you primed for a data breach if you don’t know about it.

How the Threat Detection app can help you identify guest user anomalies

The good news is that there’s something you can do about guest user anomalies. If your org has Event Monitoring, you can use the Threat Detection app to identify problematic accounts and take action. It uses the power of machine learning to figure out where the gaps are in your permissions and flag them for you.

In fact, the Threat Detection app can help you monitor all sorts of other anomalies, too. Like if a user who does their reports in the same time window each week suddenly logs in at 3 a.m. to pull a bunch of data, or someone based in Albuquerque logs in from Finland. It can even monitor your APIs. And the best part is that enabling Threat Detection is as easy as turning on the permission set.

Jagan gets into more specifics in our interview, so be sure to take a listen. And don’t forget to subscribe to the Salesforce Admins Podcast so you never miss an episode.

Podcast swag

• Salesforce Admins on the Trailhead Store

Learn more

• Salesforce Security Guide: Threat Detection

• Salesforce Security Guide: Guest User Anomaly

• Salesforce Help: Best Practices for Investigating Guest User Anomalies

• Trailhead: Get Started with Event Monitoring

Admin Trailblazers Group

• Admin Trailblazers Community Group

Social

• Jagan on LinkedIn

• Salesforce Admins on LinkedIn

• Salesforce Admins on X

• Mike on Threads

• Mike on Tiktok

• Mike on X

Full show transcript

Josh Birk: Hello Admins, it's your guest host Josh Birk here. Today, I'm going to welcome Jagan Nathan to talk about some very specific things about security, specifically quirks in security that can sometimes be a little difficult to detect and how we're going to help you detect them. So without further ado, let's go to Jagan. All right. Today on the show we welcome Jagan. Did I do that right, Jagan?

Jagan Nathan : Yes.

Josh Birk: All right. We're going to talk about some very interesting security things, but first of all, welcome to the show.

Jagan Nathan : Thank you, once again, for having me.

Josh Birk: Thanks. All right, well, let's start, once again, in some of your early years. How did you originally get into computing?

Jagan Nathan : Oh, yeah. So back then during school days, we used to play Counter-Strike. We have in-house network connected with a group of friends.

Josh Birk: Nice.

Jagan Nathan : So that is how we started into it. We started in a playful mode and then we slowly started programming and all those aspects to it.

Josh Birk: Did you actually get into modding Half-Life and all that stuff?

Jagan Nathan : Not really.

Josh Birk: Got it. Nice. How did you originally get involved with Salesforce?

Jagan Nathan : Salesforce, initially I got trained in the Java platform and then back then we got a new project on Salesforce and we have been asked if we could try this out and then I initially thought of giving it a try. I initially thought Salesforce is purely sales driven or some sort of MBA-related work, but that is how it was. And then slowly I got into it. It was quite interesting. And then back then it was even more interesting without Trailhead. We had a lot of learnings. We used to push in developer forums. It was quite challenging and interesting. From that point of time, there's no looking back. We just love this platform.

Josh Birk: Nice. How did you find the transition from Java to Apex?

Jagan Nathan : So I was able to correlate most of our things through the basic modules. I usually compare Java-related world with Salesforce Apex related, so that it was easy for me during the transition phase.

Josh Birk: Got it. And how would you describe your current job?

Jagan Nathan : So current job is more of a technical architect part of customer success group. Work with different set of customers. Each customers have their own set of challenges and problems to be solved. So right now I'm even focusing on the Data Cloud related piece of it. Try to stitch in the data from multiple data source what customer is having. They have a lot of silos data across the platform. We are using the power of Data Cloud to bring in and harmonize all those data.

Josh Birk: Got it. I feel like that's a very common thing at the company right now. So welcome to the club. Just as on that topic itself, especially when it comes to Admins, are you finding any particular specific challenges that run into when they start adopting Data Cloud?

Jagan Nathan : Our Data Cloud, the best part is we at Salesforce, we have a template called Data Cloud Workbook Template, which is mainly recommended for all the admins and then whoever is trying to configure Data Cloud. So Data Cloud, what we have seen so far is 60 to 70 percentage of time we need to spend on understanding what needs to be done, like what objects we're going to map, what are the data sources we're going to map. So we have a pretty good decent template out there called Data Cloud Workbook Template, which is highly recommended for our customers so that they spend a lot of time on what needs to be done, what fields needs to be mapped, what should be the data sources. So once we have that in place, admin life looks even more simple.

Josh Birk: Got it. Nice. And I think I'm going to ask this in the right way because I believe I don't know the answer, but since we're talking about security today, does Data Cloud offer any new thoughts on what to be concerned with security, or does it just kind of bolt itself on the platform and the platform is taking care of security like it normally would?

Jagan Nathan : Yes. So Data Cloud currently supports our data spaces. We have this concept called data space filters through which we can set up the security of it so that authorized users can access a particular set of data instead of accessing all Data Cloud data.

Josh Birk: Got it. Before we get into some of the specifics, when you first start talking to clients and customers, are there very common security issues that you find people aren't concerned about or aren't aware of that they should be aware of?

Jagan Nathan : Yeah, so the main concerns or challenges what customer was facing right now is down the line, Salesforce or a lot of consulting companies work for them and then they have tons of changes made on the profiles and the permissions, and then someone got access to something which they are not supposed to. For example, I have seen customers, some marks, they have lot of sales users have export report function permissions and a customer is thinking about do they really need those export reports permission? Definitely not, only a subset of users need that. So it is all about backtracking and trying to find out how did they got this permission? Do we really need to give this user a permission to those reports? That is one of the challenges there.

Josh Birk: Right. Nice. It's amazing how many of the security issues really can be boiled down to the concept of lease privilege.

Jagan Nathan : Oh, yeah. There are a lot of things happening around the permissions and then recently we also rolled out object permissions and permission sets, for example, how the particular permission got assigned to the particular user. Is it through profiles or a permission set? So we have all those enhancements as part of recent releases too.

Josh Birk: Right. Now today we're going to talk about a very specific one, and I'm going to give you credit because I had not heard of this, although I think I was kind of aware of the concept, I swear back from my IoT days, but we're going to talk about what a guest user anomaly is. Let's start at the beginning. Define that for me. What is a guest user anomaly?

Jagan Nathan : So this guest user anomaly, before we talk about it, in the last podcast we discussed about event monitoring in general, what are the events we have as part of event monitoring. For the listeners, to give a quick background, event monitoring is a subscription-based QVF. The beauty of our Salesforce platform is everything is built on top of event-driven architecture, right from the user logs in, logs out, when the user access the list views or reports, all those are captured as events at the backend. So when it comes to threat detection, threat detection is one of the submodule of the event monitoring, which comes free of cost. If customer has event monitoring, then they would be able to use threat detection free of cost. So threat detection has a lot of events built into it and one of the events is a guest user anomaly event. So guest user anomaly is one of the interesting event because there are a lot of customers who are using guest users in their communities or back then they used to have a Force.com site. So they have built a business process surrounding guest user. So here at Salesforce what we thought is why can't we build a guest user anomaly even so that customers would be able to identify if there is any threat around the guest user.

Josh Birk: What sort of traffic is the threat detector picking up that says this is a guest user and then this is a guest user anomaly?

Jagan Nathan : So behind the scenes we have a lot of machine learning methods through which we constantly understand the profile of a guest user, what they are supposed to access. And there are a lot of parameters at the backend, which is quite black box for the customer, which is totally handled at the product side. So at the higher level we use a machine learning algorithm to detect if there are any information which the guest user is not supposed to access to, but due to some different options, if the guest user is able to access it, then we are throwing that as guest user anomaly events to our customers.

Josh Birk: So go down one more level to that for me because it was interesting that, so I've set up a guest user, I expect him to have this set of lease privileges, but you're saying there might be some things that I did in setup that would cause an unexpected ability to access data. Is that what the anomaly is?

Jagan Nathan : For an example to deep dive into it, let's say we have lightning community, which is running on a guest user mode, and then behind the scenes it all starts with the OWD settings. So our recommendation for a default external access is a public read or some customers might have a public read. It depends on the business use cases. Let's say if there is any suspicion even caused by a guest user, for example, if there is a Apex class which runs in without sharing mode for an example, and then if that guest user through some ways, if they are able to get the data, which they are not supposed to get. So in this scenario in general, guest users should not have access to the objects. But in a worst case, if something happens and if there is any Apex class without sharing, if they're able to get some information out of it, so it is inadvertently permitting the guest user to access some data which they are not supposed to.

Josh Birk: Got it. So it's nothing necessarily that the admin would see from a setup point of view when it comes to inspecting profiles or permission sets or anything like that, but it would be access to et cetera, et cetera, something else like an Apex class and then how that was designed is giving them access to something that's outside of their profile.

Jagan Nathan : Exactly. From the admin standpoint, what we recommend is whatever list views which are getting shared, make sure it is getting shared only with a certain set of groups which are set to private. That is one recommendation, what we could say to our customers. And then the next one is make sure to do a proper analysis on all the sharing rules we have. Do we have any sharing rules, which is sharing with any side guest user? That is one option we would recommend.

Josh Birk: What are some inherent risks here? Is it simply access to data that they shouldn't have or can it get more nefarious than that?

Jagan Nathan : Let's say if that guest user is not supposed to access the data what they should have, then what happens at the background, it could lead to a data breach in the near future because there could be some guest user, there could be some data Apex class which runs in without sharing mode, for example. It gives a view all data of all the accounts, then the guest user would get all the accounts. Then that eventually turned out to be a data breach.

Josh Birk: Got it. Got it. In reference to these tools, let's assume that an admin, they're not familiar with it. What does it look like? Is this a report that they're going to run from time to time? Is this an app that's going to alert them that maybe something is wrong? What's the user interface here that's letting them know that there's a red flag?

Jagan Nathan : So it all starts with a permission. So there is a permission called view threat detection event. So once that permission get assigned to us through a permission set, then we will get access to a threat detection app. So threat detection app, once you navigate to a threat detection app, we should be able to see the list of anomalies. For example, if there is any guest user anomaly happens, then we will see a record on the threat detection that says guest user anomaly event. Then it is up to customer to take up a decision if they really think it's a threat, or else, if they think it's not a threat, they can provide feedback back to Salesforce.

Josh Birk: Got it. So it is kind of a constant monitoring, taking action when they feel like that was definitely a set of data that this person shouldn't be able to have access to.

Jagan Nathan : Exactly. So in addition to it, we are also giving customers option to build a transaction security policy as well. Transaction security policy is something like it is automatically monitoring the trades. For example, guest user anomaly is one event. So we have an anomaly event called report anomaly event. For example, user is everyday logging in on a particular time interval and they are working on the reports, but suddenly if the user works over the weekend or suddenly if the user tries to connect from a different VPN network altogether, and if that particular user is trying to export a report, if that report count is more than 10 million rows, for an example, then Salesforce can throw that as an anomaly event and then customer can take up an action. If they really feel it's a threat, then they can block it or else they can add it in some audit log for their purposes.

Josh Birk: Got it. Without going into too much detail, what are some of the other events that the threat detector is monitoring?

Jagan Nathan : One of the event is a session hijacking event. This is more of a customer-focused attack event. For example, if any attacker is trying to steal information from using client access to their web application, then through session hijacking event we would be able to identify if the attacker tries to hijack the client's session by obtaining some session token.

Josh Birk: Got it. How about APIs?

Jagan Nathan : API, that is super important. Thanks for bringing that up. So behind the scenes what we do is once we have the streaming and storage enabled for API anomaly, let's say there's an integration user who periodically runs the API scan and then they get data out for business processes, but suddenly out of nowhere, if the integration user is trying to export more than X number of records or else the way the integration user is pulling the data, for example, the row count might be new or else they might be logging in from a different IP address or some sort of anomalies. So what Salesforce does at the backend is it constantly understand the pattern of how that API user is being used for all the API requests. And if Salesforce thinks the new request is quite different from the existing request in the past, then Salesforce will throw it as an anomaly.

Josh Birk: Got it. So kind of at a high level, because if we look at the session hijacking, that's where I steal your cookie for lack of a better term. I steal your session ID, I hijack your identity, I try to access Salesforce as you, that would be something very difficult for somebody, a human on the Salesforce side to detect, well, that's not Jagan, that's Josh. With the APIs it's sort of similar. It looks like somebody knocking on the door and the fact that they are doing something once that door is open that's anomalous is not something easy for a detect and then finally going back to the guest user. So at a high level, the threat detector is giving us this machine learning eyeball into what the traffic is coming out and saying, "Hey, that thing doesn't..." It's kind of like when you get the fraud alerts, right? It's like you don't normally buy $300 worth of goods in Ohio,. Maybe you should call us before we spend $300. But it gives us this suite of tools to be able to do that kind of investigation.

Jagan Nathan : Yeah, perfect. Exactly.

Josh Birk: Nice. Where can people learn more?

Jagan Nathan : Oh, yeah. So we have a help article, which we'll be adding it in the podcast as well. That help article talks about threat detection and how the machine learning algorithm at high level works and how customers can proactively build a transaction security policy on top of it to play around with the threat detections.

Josh Birk: Nice. And once again, this is not a licensed add-on, it's on a SKU, it's once somebody turns on the permission set, they're good to go.

Jagan Nathan : Yes, exactly.

Josh Birk: Very nice. In general, do you have any security resources that you'd like to share?

Jagan Nathan : Oh, yeah. In general?

Josh Birk: Yeah.

Jagan Nathan : I will add that as well.

Josh Birk: Okay, perfect. Well, Jagan, thank you so much for the great conversation information. That was a lot of fun.

Jagan Nathan : Good. Thank you so much to, Joshua, for having me again.

Josh Birk: I want to thank Jagan for the great conversation information. And as always, I want to thank you for listening. If you want to learn more about this podcast, head on over to admin.salesforce.com and of course you can subscribe to it in the podcast client of your choice. Thanks again for listening everybody. I'll talk to you soon.