Salesforce Security Blind Spots: Security Execs Uncover What’s Often Overlooked

DigitSec Founder and CEO, Waqas Nazir and our guest Andy Ognenoff, Managing Director, Global Salesforce Security Lead at Accenture took the time to discuss common Salesforce security blind spots, why companies should focus on these and provided recommendations on how to minimize these blind spots.

This presentation provided valuable information that generated a lot of great questions around making Salesforce more secure.

Waqas kicks off the discussion chatting about the topic of security and how many have misunderstandings and misconceptions around Salesforce security. Andy’s first point about why security blind spots exist is because many people simply ignore security.

This is because they don’t understand the Salesforce Shared Responsibility Model that states the platform is responsible for security out-of-the-box, but “it really is up to the client and implementation team to use all the tools available so you’re not exposing data and having security issues that are really your responsibility at the end of the day,” states Andy. This is how companies many times “put their heads in the sand” around security.

The complexity element is a key reason why there are blind spots, according to Waqas. These SaaS platforms are constantly being updated with new functionalities based on customer demand. Customers assume all the necessary security controls are put in place by the platform and this leads to an unhealthy security environment because that assumption is wrong. There’s responsibility on both sides to put the right security controls in place with each addition, customization, 3rd-party integration, etc.

After some more initial discussion, Waqas and Andy move into the blind spots themselves. Some discussed are:

• Data leakage through overprovisioned users, misconfigured security settings or insecure coding practices.
• How UI can be a blind spot when companies think just because it’s not in the UI, it’s not accessible.
• Permission attributes and guest privileges, when not configured correctly, can leave you open to attack.
• Not staying-up-to-date with release updates and the importance of understanding the WHY an update was made.
• Not understanding the supply chain within Salesforce and 3rd-party apps/integrations/code you may be using in your environment.

The session concluded with Andy and Waqas answering multiple questions from the audience with topics ranging from how to engage security teams about blind spots to technical questions around specific Salesforce features and packages.

Please watch the full presentation above to get details on each of the blind spots as well as how to mitigate the risks associated with them.

Full transcription below.

Welcome

Andy Montoya (Event Host) (00:03):
Hello everyone. And thank you so much for being here with us today. My name is Andy and I’m on the marketing team at DigitSec. And today I’m very excited because we have two seasoned security professionals with us that are gonna uncover and teach us about Salesforce security blind spots. And we’re gonna discover what’s often overlooked. So without further ado, I’ll go ahead and pass things over to Waqas to introduce himself as well as our guest, Andy Ogenoff.

Waqas Nazir (DigitSec CEO) (00:32):
Hello everyone. Good morning my name is Waqas Nazir. I’m the founder and CEO of DigitSec. I’ve been doing security work for the last 15 years and specifically on Salesforce for the last 10 years. And I’m excited to be here today because we’re talking about a very important topic. Salesforce, as you all know, is a critical system within many enterprises, and we’re excited to share some of the insights that we’ve seen across the industry. So with that, I’ll hand it over to Andy to introduce himself.

Andy Ogenoff (Accenture) (01:13):
Hey everyone, my name is Andy Ogenoff. I’m a managing director at Accenture and I lead our global Salesforce security practice. I’ve been in the Salesforce ecosystem for 18 years and I am also a Salesforce, certified technical architect. So I get involved with all the “hairy” implementations, and security happens to be a passion area of mine. So I’ve been working in this space for quite a while and looking forward to having the discussion today with Waqas on some of the things you really need to be thinking about when it comes to Salesforce and security.

Waqas Nazir (DigitSec CEO) (01:53):
That’s wonderful. Thanks Andy, for making the time and joining us today, like you said, it’s a very passionate topic. People have, rightfully so, a lot of sometimes misunderstandings and misconceptions when it comes to Salesforce security. So let’s start there like why this, this title for talk like security blind spots. Some people may find that to be a dichotomy when it comes to Salesforce. So let’s start there. Why do you think there are blind spots in Salesforce to begin with?

Security for SaaS relies on Shared Responsibility

Andy Ogenoff (Accenture) (02:30):
I think there’s a couple of areas that I see around blind spots in Salesforce security. One is that people just ignore it completely because they don’t fully understand the concept of the shared responsibility model in SaaS applications. So, I think if you’ve been around the Salesforce world or other SaaS applications, you’ll realize that there’s a big chunk of the security responsibilities that the provider will provide. So Salesforce is providing a secure platform, but it really is up to the client and the implementation team to make sure that you’re using all the tools available to you to make sure that you’re not exposing data and having security issues that are really your responsibility at the end of the day. So part of it is kind of putting your head in the sand around what you need to be doing. The other is that Salesforce is an extremely complex platform with all the acquisitions and all the new features that have come out over the years. There’s just a lot of knobs and dials that you can play with, set inappropriately or appropriately. So, it’s a very complex system to truly understand and make sure that you have it set up securely. What about you? What do you think?

Waqas Nazir (DigitSec CEO) (03:55):
No, you’re right. I think the complexity element that you shared is one of the key reasons. I think there are a lot of blind spots because most of these SaaS platforms have a history of starting off as like very out of the box, canned functionality in features, but with every release, with every demand that a customer has, there are new features being added and there’s new implications from a security perspective for those features and many, a times given that these platforms are, you know, put in this bucket of SaaS, the assumption is made that all the security controls will be implemented by the provider themselves. So that leads to a very, very unhealthy, environment from a security perspective, because a fundamental assumption is being made, which is essentially wrong. So thank you for sharing your perspective. Cause I know sometimes people struggle with this on the outset, that why even talk about blind spots in a platform which is provided by a third party and not realizing that puts you in a difficult spot. So you talked about like the importance on the reason why there are blind spots, but let’s maybe play the devil’s advocate here a little bit. Some people think that Salesforce security is a “good to have”. Like, it’s, it’s nice to do it, but it’s not really that important that you should actually focus on it. So I’d like to get your thoughts on that too.

Breaches Do Happen and You are a Target. Be Proactive!

Andy Ogenoff (Accenture) (05:32):
Sure this is another one of those areas where, because until very recently there hasn’t been a lot of press about big time breaches happening in the Salesforce world or the SaaS world. So there’s this perception that because we don’t hear about it in the news, all that often you don’t think it’s gonna happen to you. That’s called your normalcy bias. So understanding that it hasn’t happened to me before, so it probably isn’t gonna happen to me in the future. What we’re seeing is that because Salesforce is a critical platform for a lot of companies, very large enterprises, we’re putting the crown jewels into a third party provider, which again is a secure platform, but you are responsible for that configuration, that secure coding. And so when we end up with this perception that it’s not gonna happen to me and we don’t hear about it all that often. The idea is that, maybe I can do a little bit of security here, a little bit of security there, but I’m really just checking compliance boxes to make sure that my security team doesn’t yell at me. That kind of attitude is what will end you up in the news.

Andy Ogenoff (Accenture) (06:52):
And the articles that are being written about breaches happening in this space probably are not gonna be mentioning Salesforce. They’ll say a CRM system was attacked or a system that houses customer data was attacked. But under the hood, you know, some of these companies are getting hit with attacks on their Salesforce implementations.

Waqas Nazir (DigitSec CEO) (07:18):
So that’s a very good point. I think sometimes people don’t realize the importance Salesforce plays within an enterprise and the tentacles that it grows outside of the box. And it gets integrated into critical components of an enterprise, for example, like core product, features being distributed through Salesforce, like some element of it. So if that was to be attacked or compromised, essentially the entire enterprise will be at risk, not just the customer PII, which is the crown jewel anyways, from an hacker’s perspective. So I think it’s a great point that you bring up is like, just because you’re not being attacked today or not, you don’t have this understanding that you are perhaps, you know, already compromised or what have you, doesn’t mean that you have to sit back and wait for that moment to happen.

Waqas Nazir (DigitSec CEO) (08:17):
Because that’s the worst you can do from a security perspective: is wait and see. Which is sometimes a very unhealthy approach for any Salesforce implementation. One is just from purely security perspective. The second also is like the longer you wait, the harder it will be for you to change those entrenched implementations. And then you’ve seen really bad design decisions be made on features and things like that. So with that, let’s jump into the meat of this. Like, let’s talk about these blind spots. And I think we touched on the sort of the elephant in the room which is, you know, data leakage in Salesforce. So let’s start there. There’s very interesting attack scenarios and a big blind spot for many companies, because this is where you may end up in the news. You may have compliance fines, you may have loss of trust for your brand if this happens. So let’s talk about some of the scenarios that you play out when it comes to data leakage in Salesforce.

Data Leakage. A Common Pitfall

Andy Ogenoff (Accenture) (09:21):
Yeah. This is a bread and butter for Salesforce security. In my mind, there’s really three main ways that data leakage happens in Salesforce. It’s going to manifest itself over a lot of different avenues, but it really boils down to either over-provisioned users, misconfigured security settings, or insecure coding practices. And there’s lots of different ways that that manifests, like I said, lots of different security settings that are gonna leak different parts of your data. But those three things are the big areas. And I think that there’s some of the obvious things that a lot of people go after exporting reports, maybe locking down API access, or, understanding your sharing model, making sure that it’s as closed as possible still allowing you to do business. But I think that the less obvious ways that data leakage happens is around custom code flows.

Andy Ogenoff (Accenture) (10:31):
A lot of times we think that just because we wrote some code or, or we’re using declarative out of the box features of Salesforce, like flow, that there aren’t security issues with that. And it’s really not the case. There’s quite a few areas that you can actually execute code that you may not; that maybe you shouldn’t be; execute flows that maybe you shouldn’t be; through the aura endpoint, custom web services. Lots of different ways to do that. I think the key thing to be thinking about as you’re developing, as you’re configuring and building out logic is who should have access to it, the data to the class, to the flow, whatever it is, and implement that concept of least privilege. So yes, it’s a little bit more work. Yes it’s complex, but it’s gonna limit the amount of damage that can be done. When we’re talking about over-provisioned users, this one happens all the time. So people have too many permissions. Admins or developers don’t really know what the permission does or why a user might need it. And so you end up with just making it easy on yourself and giving away permissions that really shouldn’t be in the hands of end users. So those are some of the key areas that I see all the time from a data leakage perspective.

Waqas Nazir (DigitSec CEO) (12:02):
Yeah, and I think you touched on a very good point that just because you think there isn’t an interface into executing some portion of your customization, it’s already enabled or it’s apex services. So somebody has to actually write a client to get to that API is a pretty dangerous assumption within Salesforce, right? And we’re seeing more and more that there are data sets that can be accessed by the framework. Just because it’s not in the UI doesn’t mean that it’s not accessible. And given the fact that Salesforce is a customizable SaaS platform, it is actually quite predictable on how to get to that data from an attacker’s perspective. Right? So that’s another very dangerous, I would say, assumption to make when you’re writing customizations on top of Salesforce, especially with code is to say that since I’m not publicly putting this API somewhere, nobody’s gonna get to it.

Permissions, Permissions, Permissions!

Andy Ogenoff (Accenture) (13:02):
If you’re using experience cloud, I can’t even tell you how many times I go in and do an assessment and they have standard pages turned on. So if you didn’t lock down your sharing model externally, and you’re relying on the UI to prevent users from doing things with the data or accessing data that maybe they shouldn’t, the UI is not going to be an appropriate way to protect that data. You need to start with field level security, CRUD, then the sharing model, just like you do on the internal side of things. But then on the external side, there are site settings that a lot of people just completely ignore. Lightning features for guest users is one allowing standard pages is another, which allows you to just access page layouts directly from the community, even if you have a totally custom lightning UI. So those are all things that you really should be looking at to make sure that you’re not exposing extra ways into your data and logic that you didn’t intend for.

Waqas Nazir (DigitSec CEO) (14:06):
That’s a very good point. And I think the second point you raised was around permissioning. And that’s a very interesting one because it’s not just data leaks. You can actually have all sorts of interesting attacks in Salesforce from like escalation of privileges to the ability to deploy code, if that permission is given. So I was actually looking at the number of permissions that there are in Salesforce. I don’t know if you know off-hand, but since I looked it up, I can share there’s about like roughly 290 plus, permissions sets, right? Like permission attributes that you can have. And with every release, Salesforce adds a couple and typically they’re added to further lockdown the platform. So I wanted to get your take on, like, for example, you know, last year was the big, you know, “Remove View, All,” “Modify All” for guest users, where it’s like a blatant attack that you can do on any implementation if they have this permission set for a guest user. So that was taken away. So that actually helped the overall ecosystem. But from an implementation standpoint, do you think that really is a good approach to addressing this problem of data leakage? It is to keep taking permissions away and eventually you’ll have a secure state.

Locking Down Guest User is Great, Not an Invitation to Build a Workaround

Andy Ogenoff (Accenture) (15:23):
Let’s talk a little bit about the guest user issue because it’s something that Salesforce has been investing heavily in over the past couple of years. First, they started with secure guest record access. Then they started taking permissions away. Like you said, this is all in an effort to make sure that the anonymous internet doesn’t get access to your data unintentionally. However, a lot of times I see people. They don’t test this stuff. They wait for the release update to automatically be enforced at a period in the future. Everybody knew about some of these changes that were coming, but a lot of times what I see is rather than understand why those changes are being made, people are trying to figure out how to work around them. And so you end up creating guest sharing rules, you end up running… Not necessarily going and cleaning up some of the data.

Andy Ogenoff (Accenture) (16:17):
So an example would be a release update where guest users are not allowed to own records anymore, but that didn’t change anything with the records that were already owned by guest users. So that’s still all out there. So we see this kind of put your head in the sand mentality of “Salesforce is gonna secure the platform”. The release update happened. It’s like a patch, but you also have the opportunity to work around the patch. And people are doing that without realizing the risk they’re putting their orgs in. So it’s one of those things where yes, you need to stay up-to-date on the release updates, but rather than just turning it on and figuring out what you need to change to make your logic continue to work exactly what it was, you need to figure out why that change was being made, and then how to securely use your logic in the context of that new world. So removing permissions et cetera, I think is actually a really good thing. I wish that it would’ve been done by default upfront. But without understanding “the why,” it’s really going to be up to that admin and developer and architect community to make sure they know what that impact is not just on the, “how do I make it continue to work?”, But “how do I make it to continue to work securely?”.

Waqas Nazir (DigitSec CEO) (17:39):
Right. And I think that’s the challenge with any implementation, right? There’s so much of historic legacy, you know, features that have been implemented, which are actually being used and there’s a business use case for it. So to completely turn it off on a given date without completely understanding what this is going to do typically ends up having a workaround, which actually puts you in the same state you were before that was pushed out. So I think that’s a very good point that you make: Staying up-to-date with what’s being turned off and more importantly, why would help implementations be more secure going forward. So it’s a very good point.

Waqas Nazir (DigitSec CEO) (18:21):
Before we jump on, I know there’s like this blind spot in itself is not just like a blind spot. It’s like, perhaps, a blind Panorama! There’s so much that you can talk about here. But before we move on from this little thing, the discussion around data leakage is typically what can you do to prevent it, right? One of the ways of preventing something is actually looking for it, right. What has your experience been around people looking for this type of behavior within Salesforce and what are some insights in that?

Knowing is Half the Battle

Andy Ogenoff (Accenture) (19:00):
So I was gonna mention this earlier in our discussion around people not really understanding that attacks are happening. And the main reason people don’t understand that attacks are happening on their systems is because they’re not monitoring for it. So one of my favorite products that Salesforce has that is very much underused is Event Monitoring. So it comes as part of Shield, or you can buy it individually. Event Monitoring has just a ton of data about what is happening on your system, not just from a security perspective, but performance and what users are doing. You use it for adoption reporting, all that kind of stuff. But from a security perspective, if you integrate that with your security operations center or outsource that, so that you have experts looking at these logs and understanding the use cases that attackers are really going after, you would be very surprised to understand that you probably have people attacking your system on a daily basis and you don’t even know it right now.

Andy Ogenoff (Accenture) (20:06):
Now, what are you gonna do with that information? Depends on what kind of attack it is. And if they’re successful. If you know that somebody is poking around your experience cloud site, [you] probably want to take a little bit of extra time to go and make sure that where they’re poking around is as locked down as it possibly can be. If you do happen to have a security incident event, monitoring is what is gonna help you understand the forensics of that. So what did they get access to? What/who do I need to notify? All of that kind of stuff is gonna be available to you in Event Monitoring. So that is like one of the top products I think out there. And obviously that’s just the raw data. You need something: people, processes, [both] people and tools to take that data and turn it into insights around the kind of attacks that might be happening to you.

Waqas Nazir (DigitSec CEO) (20:59):
That’s a very good point. I think it’s a great feature that is often not implemented. And I think from a security perspective… It’s sort of given the current climate. It’s sort of a necessity to look at what’s happening from an external standpoint, especially if you’re exposing things on the internet with Experience Cloud or custom web services, or what have you… Apex services and things like that. So, I know we spent like a good chunk of time on this and rightfully so. I think it’s a very important topic, and very important area to look at because it often [is] something that is not discussed in depth. And that’s why we wanted to give some more perspective on this and then.. And Andy you’ve really given really good explanations of what you see and what are some of the reasons behind this issue within Salesforce.

Waqas Nazir (DigitSec CEO) (21:57):
We had a few more to cover, so we can try to address them, but perhaps at a later time we can invest some more as well.

Supply Chain Blind Spots. Third Party Risk is Real

Waqas Nazir (DigitSec CEO) (22:07):
One of the things that we see often with a platform like Salesforce is not understanding what are some of the supply chain risks within Salesforce. We feel as if Salesforce is self-contained, and if you’re customizing on top of it, it gets deployed within a contained environment. And therefore there’s no real third-party risk or as you know, access risk with supply chain. What are some of the things that you’ve seen? I personally can tell you that we see that there is a vast supply chain within Salesforce, which people sometimes don’t realize that there is.

Waqas Nazir (DigitSec CEO) (22:50):
And that shapes as managed packages, unmanaged packages, you know, things, apps, popular apps from the app exchange, to third-party code that you may be utilizing yourself. What are some of the things that you see and why do you think that’s a blind spot?

Andy Ogenoff (Accenture) (23:09):
I think there’s two main areas that I would cover with this. And I’ll try to go as quickly as possible on this. You mentioned third party-apps in terms of app exchange packages. Those obviously go through Security Review. They change all the time. And, the one area that I think is a big blind spot for people is that those third-party app exchange apps can sometimes introduce third-party apps to them, even JavaScript libraries. And so they’re either getting loaded as a static resource or they’re getting loaded-in dynamically from off-platform. So you, as the customer, have no control over what version of that JavaScript library. Is it using an outdated version of J-Query that has known vulnerabilities? Does it have… Is it using an old version of Angular that has been deprecated and it doesn’t have any of the new security capabilities in it?

Andy Ogenoff (Accenture) (24:03):
So not even thinking about that kind of risk, I think is a huge blind spot. But then the one that I see most often being surprising for people are third-party connected apps. So by default, your end users are gonna have API access. If you don’t have API access control turned on, I’ll talk about that in a second, your end users can connect up any app they want to and use that app to access any of the data that they’re configured for. So even if you have a locked down sharing model, you and your user has API access, maybe they need the mobile app. And so you need API access turned on, you end up giving them permissions to go to the app store, the iOS or, or Android app stores and download mobile apps that have a Salesforce connector. I mean, even Excel these days has a built-in connector to Salesforce!

Connected Apps Require Careful Management

Andy Ogenoff (Accenture) (25:00):
So literally all they need to do is login through the Excel connector and you can dump as much data as that user has access to, even if they don’t have access for export reports. So you end up with this situation where you have unvetted, third-party apps… [They] haven’t gone through compliance review, haven’t gone through legal review. You have no idea what they’re gonna be doing with their data. They could be storing your credentials or your access tokens insecurely. And now you end up with an attack vector that you really have no visibility into. So the recommendation for this is to use API access control. That is actually a feature, if you’re not familiar with it, it’s probably because Salesforce requires you to submit a case to have it turned on. So do that. Then it allows you to kind of flip the model on its head and say, alright, we’re gonna tell you that by default your users cannot connect any apps and you have to explicitly allow them that takes some regression testing and making sure your integrations and all that’s gonna still work, but especially in a Greenfield implementation where you’re just starting out…Turn that on and start secure from the beginning, rather than allowing for your users to go and hook up whatever app they want to, and then having to take it away from them, which is always a harder conversation.

Waqas Nazir (DigitSec CEO) (26:24):
That’s a very good point. And I think you can touch on the elements of escalating your privileges through connected apps, because for sure, the granularity of a connected app, even with a connected app that you’ve locked through API access control is not there, right. As a user, the connected app is taking the permissions that you give it when you install it. And that could be like API web, you know, even, you know, refresh tokens or what have you. So it has actually kind of like an unwarranted [and] unbridled access to a lot of stuff that you may not want to give to a connected app. But given that you’re giving this trust to this third-party, you still need to be aware of what’s happening. You don’t have governance around what’s happening with that. [It] can be a big blind spot for you because this is where you can use the analogy like you’re as strong as the weakest link in your chain, for sure.

Waqas Nazir (DigitSec CEO) (27:20):
Because you may be doing the things right, and you internally, you may have API access, you know, locked down and not allowing users to just connect applications as they feel. You may still be exposed to third-party risks through the connected application itself and your users may have more access through the connected app just because it’s not anywhere in access control. So that’s actually an area that we see a lot of implementations do not even consider this as an important aspect of insecurity. So it’s a big blind spot. So we’re coming up on time and I know we have some few questions, so I think we had some more blind spots to talk about, and I think they’re gonna remain a blind spot unless you’re already aware of it. But perhaps we can do a follow up session at some point in future. Talk about more of the blind spots that we observe within the Salesforce environment. So we can maybe switch some gears here, take some questions if that’s okay, Andy?

Andy Ogenoff (Accenture) (28:32):
Maybe we can cover some of those blind spots. And if somebody has questions about it, we’ll see if we can work them in.

Andy Montoya (Event Host) (28:40):
Absolutely, Gentlemen! So great information so far! And I know this is really resonating with the audience just based on the great questions that are coming through. So the first one we have is “it seems like users either know security or they know Salesforce… Crossing over between them seems rare. So how do we reconcile our expert security personnel who have no idea how to even begin to look at Salesforce security?”

Security is Part of the Solution Not the Problem

Andy Ogenoff (Accenture) (29:04):
That is a great question. And something that a lot of clients and consulting partners grapple with. Right? There is… and it really comes down to starting to collaborate early on your program. So tap into those security experts, point them at Trailhead internally. We actually at Accenture, we have a trail mix that we point our security folks to that lays out all the security related modules for Salesforce. when they get involved in a security program Salesforce project. Helping your Salesforce team realize the security team is not there to slow you down and say, “no”. I think that’s a critical misunderstanding. There’s a great quote from Gabriel Friedlander, a security professional, who said that the point of security is not to slow you down or make you make you stop just like brakes are not put on cars because they want you to stop. It’s to allow you to go fast. And that’s exactly what security should be within your organization. We want to make sure that you’re doing things securely, so that down the road, if you run into issues regulatory concerns or compliance issues, and you get shut down, that’s gonna be a lot slower than the security work that you might have needed to implement as you went through the process.

Waqas Nazir (DigitSec CEO) (30:39):
And I can add that understanding from security personnel when it comes to Salesforce… A great resource is the Salesforce security guide for the security personnel to bring them up to speed. Because sometimes they think that Salesforce is an entirely different beast, which it really is, but it’s vulnerable to the typical web application attacks that you’ll find in like your OWASP Top 10 or the CWE Top 25. But it’s always a struggle between a new platform that is being onboarded and the security team, you know, needs to evaluate. And then you can create friction between them.

Andy Montoya (Event Host) (31:27):
Thank you gentlemen. So moving on to the next question, Andy mentioned a bit of a lift and possibly a heavier process that will ultimately ensure greater control in security, which is what the business wants. But what’s a good way to communicate to devs and admins that this new process may seem like more work, but will ultimately be better for the whole team in the business?

Doing Nothing is Not Faster. Build and Test at the Same Time

Andy Ogenoff (Accenture) (31:49):
So I think it comes down to what we were just talking about. It’s all about speed, right? The perception is that if I don’t have to do anything, it’s faster, that’s true. But it’s never the case that you don’t have to do anything. That’s just putting your head in the sand. If you don’t take care of the security concerns up front, you’re gonna be doing it on the back end, which is gonna be more work, more expensive and cause more delays. [Like] when you run into a penetration test that came up with a whole bunch of stuff that now you have to go re-architect a bunch of things. So if you think about the access, the threats, right, it’s the practice domain area is called threat modeling. We do it every day as Salesforce professionals, but you don’t might not be calling it that.

Andy Ogenoff (Accenture) (32:32):
What it really comes down to is what are the different ways that this thing that I’m building could be attacked and how can I mitigate it? So as an admin, a developer, et cetera, it’s really important that you be, you’re thinking about that upfront. Like if you have checklists for your user stories for “How do I know when I have good acceptance criteria?” If you don’t have security acceptance criteria in all of your stories, you’re probably missing something. Who should have access to it? How should they get access to it? All of that kind of stuff should be done at the user story level. And so in terms of telling your devs and admins why it’s gonna be faster because they’re gonna do it eventually. And if they don’t do it, eventually they’re gonna end up with a security incident and it’s gonna turn into something even broader and potentially even shut down the project. I’ve seen that happen. So it really… you’re gonna pay up front, or you’re gonna pay on the back end. Paying up front is a lot faster and a lot less expensive.
Andy Montoya (Event Host) (33:42):
Okay, great, thank you, Andy. Next one coming up is: What’s the most common vulnerability you find in Salesforce.? What’s the most dangerous and what’s the most interesting?

Understand the Data Model and Permissions

Waqas Nazir (DigitSec CEO) (33:54):
So I think Andy, you can chime in as well. So the most common thing that I found… I typically see within a Salesforce implementation is just the lack of understanding of the data model and running your code with basically system access. You know, without sharing and not implementing any CRUD checks. That is quite common. I would say one of the most common bugs that we see across implementations, and the most dangerous thing that that we’ve seen is we found, we actually made a little video of this exploit where somebody can actually exploit Salesforce by a feature called web-to-lead and then escalate privileges and basically gain system admin access through that exploit. That was perhaps the most scary thing that we’ve seen and actually exploited within Salesforce. And then, you know, the common themes within Salesforce are the easiest exploitable things are around, you know, just poking at the APIs and getting the data back due to a broken access model or issues with guest users.

Andy Ogenoff (Accenture) (35:14):
For me, I would say the most common vulnerability is over-provisioned users, for sure. And that, again takes many forms, but I think the most dangerous, attacks like most dangerous kind of attacks for me are IDOR vulnerabilities. So this is “Insecure Direct Object References”. If you ever are the subject of a penetration test, you will probably hear that term quite a bit. Basically it means that the input to whatever it is that you’ve built, it could be flows, It could be apex controllers, [it] could be any number of things… [They] take input in such a way that allows somebody to guess what other valid input might be. So maybe you’re passing around IDs in the query string. Maybe you are, have a lightning component that takes a JSON payload of an application or something like that. And you’re gonna modify a loan based on that. Well, if I just guess what the next Salesforce ID is in that payload, I might be able to modify somebody else’s loan, or I might be able to access somebody else’s patient information, or I might be able to access who knows [what]. So that kind of vulnerability, I think, is one of the most dangerous, because it’s not super obvious and it is very prevalent.

Waqas Nazir (DigitSec CEO) (36:37):
That’s a very good point. And, it’s a manifestation of the exploit that I was talking about before.

Andy Montoya (Event Host) (36:48):
All right, gentlemen, the next one up is: Are there good places, blogs slash websites, to monitor awareness of remediable exploits?

We Don’t Talk About Exploits…For a Reason

Waqas Nazir (DigitSec CEO) (37:04):
I think there are some great resources on Salesforce itself. The Trailhead that Andy mentioned is a great resource for learning about, you know, some of the new things that you should be aware of within the Salesforce security world. As far as specific blogs on Salesforce security, We maintain some content on our blog as well, but there isn’t a blog dedicated, at least to my knowledge, specifically for Salesforce. Typically Salesforce is laid, you know, within the larger security landscape.

Andy Ogenoff (Accenture) (37:53):
I would say there’s a handful of authors out there that are doing a really good job. Putting out technical content around Salesforce security. The challenge that I see with this particular topic, and I ask Salesforce all the time to put out stuff like this, but you run this risk of, if you put out the information of exactly how to exploit this, you’ve also got a whole bunch of customers that are not gonna secure their systems quickly enough. And therefore you basically gave the keys to the kingdom, to the attacking community. So I will say that OWASP Top 10 [that’s] O-W-A-S-P Top 10; SANS Institutes, CIS, has a great list of things that you should be looking at in Salesforce. They have the CIS framework. They have a guide for Salesforce now. I think in general, we’re starting to see some articles here and there come out about specific topics, but they’re like Waqas said, I don’t think there’s a specific conglomeration of Salesforce security specific things, although that’s a great idea.

Andy Montoya (Event Host) (39:14):
All right, gentlemen. Any comments on Salesforce security center?

Andy Ogenoff (Accenture) (39:22):
I’m not gonna get into specific products today. I will say in general that the idea of monitoring for configuration settings that security center and a number of other products do is really, really good. We should be doing it. We should be doing it as part of our dev lifecycle. We should be understanding where we are introducing risk through code and through configuration and especially in a multi-org environment, you need something that can look across all of your Salesforce instances. So there’s a number of solutions out there. And the one that makes sense for you is gonna be based on the complexity of your orgs, the maturity of your security and your Salesforce organization and your budget. So I’ll leave it at that.

Andy Montoya (Event Host) (40:19):
Okay, great. Next one. Up CASB was supposed to be a solution for cloud DLP at one time, has CASB matured. And is this a valid mitigation now?

CASB Can Contribute to Defense in Depth

Waqas Nazir (DigitSec CEO) (40:35):
I think what we’ve realized, if anything, is the limitations of CASB now, than the features, because I think the features have been quite well documented around monitoring. If your users access and where they’re logging in from geographic anomalies and things like that, which is a good control to have. But it still has the limitations of not looking deeply into a platform and just looking at the surface level indicators of what might be going wrong. Which, you know, then creates the need of actually looking at what you’re doing in the platform more deeply. Like what is your data access model? What is, you know, what are some of the avenues that your data can be accessed from through third-parties and what have you. So if anything, um, relying on solely CASB solutions now would not be an effective control from a security perspective because you’re only getting a part of your DLT strategy through them.

Andy Ogenoff (Accenture) (41:41):
My perspective on CASB is that it’s a part of your defense in depth strategy, right? No one solution, no one thing is gonna be the “be all end all” of securing your platform. It starts at design and goes all the way through monitoring. CASB can be a great addition to that. [It] can be implemented in a couple of different ways, as a proxy. So you’re gonna push all your traffic through it and monitor that way. Sometimes that’ll work really well for your internal use cases. It’s not gonna work super well to try to proxy all that for an experience cloud site, you might need to use a CDN reverse proxy kind of thing. Or you can have it be more reactive where it’s ingesting logs and again, you would need event monitoring to really make that useful. So I think there’s absolutely a place for it, but it doesn’t supplant all the other things you should be doing from a security perspective in a Salesforce program. And it starts with people and processes and then goes to tooling and monitoring.

Andy Montoya (Event Host) (43:03):
Awesome guys. Yes. Thank you. There’s still a couple questions and attendance is still high. So I think people are really enjoying this. Next question up: “Between protected custom metadata and protected custom settings, what do you recommend for storing sensitive information? Either option would remain in an unmanaged package.”

Stored Credentials: Custom Metadata vs. Custom Setting

Andy Ogenoff (Accenture) (43:24):
So this was one of our blind spots that we didn’t get to talk about. So usually you’re gonna be storing some sort of credential or application secret. Let’s call it an application secret. So first major misconception, if you have a protected custom setting and a protected custom metadata type in an unmanaged package or in your main name space, that protected flag does absolutely nothing. It doesn’t protect anything! The only thing that that is there for is: if it is in the context of a managed package, then only code that is in that same name space can access the data in that custom setting or custom metadata type. So if the choice is custom setting or custom metadata type in the context of an unprotected, or sorry… In the context of an unmanaged package, I wouldn’t choose either to be honest, I would be more likely using named credentials.

Andy Ogenoff (Accenture) (44:29):
If you had to use one of those though, for whatever reason, I would go with custom settings because you can encrypt using shield and you cannot do that with a custom metadata type. So if you are gonna put down credentials or API keys, secrets, things like that, that are sensitive in nature, wherever you are putting them, they should be locked down to the fewest number of people if possible. Even take away admins and just do it with a permission set, if you can. Custom settings and custom metadata types, if you’ve got a customized application or view all custom settings, those are gonna open it up. So ideally you’re gonna use named credentials where once you put it in, you can’t see it. And you can, it’s also a misconception that named credentials have to do the call out. You can actually just use it to store usernames and passwords securely and then access them directly in your code. So that would be my approach. I would not be using an unprotected UN… I would not be using custom metadata types or custom settings outside the context of a managed package. If I didn’t have complete control over who’s gonna have access to those things. Because that protected flag does absolutely nothing.

Waqas Nazir (DigitSec CEO) (45:52):
And one thing that I can add is not using cross tenant secrets. So you’ve seen the reason why you might want to put hard code, like an API key or something is because you’re gonna use that secret cross tenant. So that’s a really dangerous implementation that you can do with this. And one of the reasons you should be using named credentials is it’ll try you either for the customer to input it or create per tenant credentials. So that would basically not make that as part of your development pipeline where you’re actually using one secret across tenants, because you’ve seen one gets compromised and all the tenants are now at risk because your data is being shared through that. So that’s another important implementation consideration.

Andy Ogenoff (Accenture) (46:43):
I saw a comment in there about custom metadata types for keys. If you’re gonna encrypt using the apex crypto class, that’s great. We’re gonna store the crypto class key that you’re using. That’s gotta go somewhere. Right? So that would be my only concern with that approach. Just a PSA never, ever, ever use custom labels. I see that way too often. It’s not encrypted. It ends up in your source control. Anybody with View Setup and Configuration can see it. It’s like one of the worst places to use that, to use custom labels.

Data Classification is your Friend

Andy Montoya (Event Host) (47:25):
Okay, great. Thanks Andy for that tip. Next one! Would you recommend that an organization leverage the field level data classification slash sensitivity attributes?

Andy Ogenoff (Accenture) (47:40):
Yep.

Waqas Nazir (DigitSec CEO) (47:40):
I think that’s a good idea. That’s a good feature to implement.

Andy Ogenoff (Accenture) (47:43):
Yeah. For a couple of reasons. One is it forces you to think about it. So if part of your user story acceptance criteria is, what is my data classification and what is the usage? That right there is gonna help you understand what some of your security requirements might be. The other piece about using classification in the system is that down the road, especially like data owner and usage… Down the road a couple of years, you may not remember what you had that field for, right? Or you might be taking advantage of tools down the road that can ingest that information and use it in an interesting way. There are tools out there that will let you encrypt all the fields that you’ve marked as PII or tools that will allow you to understand who has access to PII based on classification. So that kind of thing is all out there. And so I would highly recommend using the data classification features in Salesforce.

Andy Montoya (Event Host) (50:06):
Okay. Next one up. Do you feel that there is room for ISVs to provide easily configurable solutions for enterprise on top of shield and Salesforce APIs to provide clear and concise insight and especially prevention?

Andy Ogenoff (Accenture) (50:23):
You mean for creating security tooling? Is that just a clarification on that? Well, I guess I’ll answer it either way. Both ways, whether you’re talking about creating security tooling or you’re creating the other parts of a solution that utilizes those capabilities. Absolutely. I think there’s a ton of examples of companies that are doing this well. I see the comment about writing transaction security. Yes, I would totally agree. I would also be careful with transaction security policies because now you’re managing security in multiple places. So just keep that in mind, if you’re gonna, I wouldn’t go crazy with transaction security policies is I guess where I’m going with this. So the fact that it’s a little bit more complex to do some of the really hard things might actually be good because we don’t necessarily want to make that too easy that you end up bringing down your system or making it not performant. So, that would be… I would say the opportunity is definitely there though.

Legendary Web to Lead Exploit

Andy Montoya (Event Host) (52:10):
Okay. Next one up: Where can we see the video that exploits web to lead? I’m guessing it applies to web to case as well. What about pre-chat forms?

Waqas Nazir (DigitSec CEO) (52:21):
So I can take that on because I mentioned that. It’s one of the blind spots that we were gonna cover as well today was around trusting all data within Salesforce. So the answer to where the video lives kind of is in line with what Andy said is like, you don’t wanna publish exploits, which could be used en mass against, you know, companies who have not really had the chance to protect them against them. And that was a very specific exploit that we created to demonstrate a vulnerability. So it’s not for public consumption per se, but the point that we’re making is like trusting that all of your data within Salesforce is not tainted or cannot be malicious is a dangerous assumption to make within the platform. And that leads to like common web attacks like SOQL injection, you know, cross site scripting, cross site request for like all kinds of interesting attacks can come from just like the fact that if you make this assumption that all data is hundred percent trusted, it’s not coming from anybody who cannot control this data can lead to a lot of exploitation within Salesforce.

Waqas Nazir (DigitSec CEO) (53:33):
So that is basically our recommendation is to treat all data as untrusted within Salesforce and implement the controls that are available both from a settings perspective and also from a code perspective, because you can implement controls on both layers to make sure you’re not, you know, exploitable, when you implement a solution,

Andy Ogenoff (Accenture) (53:55):
Just to kind of point you in the right direction, without telling you all the details of that particular attack, it all comes down to input and output validation. So understanding what your valid inputs are gonna be, what your valid outputs are gonna be. And is it stored appropriately in the, in the database, in the object. Its up to you as a developer. And so that just happens to be one avenue for exploiting that kind of attack, but it can come in a multitude of ways. So input and output validation are the key and relying on Salesforce to do it alone is probably gonna end you up or land you with a problem. So make sure that you’re, that’s part of your checklist to do input and output validation.

Andy Montoya (Event Host) (54:47):
Great guys, thank you so much! That actually does it for questions. Everything that was left were just great comments about this was better than expected. Great advice, love that it wasn’t a pitch and Andy, your comment about not getting into specific tools is great. So I think this was a successful session. Any parting words, gentlemen, before we go?

Andy Ogenoff (Accenture) (55:09):
I’ll just say thanks for hosting this. I think this is great information for the community to understand there’s a ton more that is out there. And I would say we should probably continue. The broader Salesforce security community really needs to come together, put out content and help the larger ecosystem with this. Because if the platform starts getting a bad name because of breaches or things like that, it affects everybody. So I think the broader Salesforce community really needs to be looking at security as a really important topic.

Waqas Nazir (DigitSec CEO) (55:49):
Yeah, I would echo what Andy mentioned is this is a very important topic and perhaps the time that we had didn’t do justice to it, but we’ll continue to do our part and it will be great for others to get involved in bringing the overall hygiene of the ecosystem by talking about this very important topic and we really appreciate all the questions and the time that you spent with us today.

Andy Montoya (Event Host) (56:15):
All right. Thank you everyone. Thank you guys.

Andy Ogenoff (Accenture) (56:17):
Great. Thanks.

Waqas Nazir (DigitSec CEO) (56:18):
Take care.