Salesforce Security Blind Spots: All Input Is Evil

Full Transcript Below

Andy Montoya (00:08):
Hello everyone, and thank you so much for being here with us today for our next session in our Salesforce Security Blind Spot series. My name is Andy with DigitSec, and today is all about the Evils of Inputs. And without further ado, I’ll go ahead and pass things off to our two security experts today. Waqas Nazir, Founder and CEO at DigitSec and Tyler Walker, lead solution engineer at WithSecure.

Waqas Nazir (00:34):
Hello everyone. It’s great to be back talking about another blind spot when it comes to Salesforce security, and today I’m particularly excited to welcome Tyler Walker from WithSecure. I was going to delve into an area of Salesforce, which is often overlooked. As you all know, my name is Waqas Nazir, I’m the Founder and CEO of DigitSec. We’re a application security testing company in Salesforce. We analyze the security of code and configurations on top of Salesforce and identify security issues that come with those, with that I’ll turn it over to Tyler to introduce himself.

Tyler Walker (01:17):
Hi everyone. I’m Tyler Walker. I’m a lead solution engineer at WithSecure. We provide a cloud protection product for Salesforce that really helps Salesforce customers to make sure that any files that come in; any URLs that come in; are safe for consumption inside their Salesforce orgs.

Waqas Nazir (01:37):
Awesome. Welcome Tyler. So basically today we’re touching upon this notion of input when it comes to Salesforce. What’s the responsibility of those implementing Salesforce when it comes to data validation and things like that. I can tell you that most, if not many, of the exploits that are available in a given day or in an attack kind of stem from malicious input, right? So the fundamental understanding when it comes to input from an application development standpoint is you consider everything evil, right? Or bad. So every piece of information, every input field that’s coming into your application needs to be validated. That’s sort of a baseline when it comes to developing web applications, but when it comes to Salesforce, that can be interesting. Do you see any challenges when people have this switch between traditional web app development versus when they go to Salesforce?

Tyler Walker (02:47):
Absolutely, and I think Salesforce is its own subsection of Information Technology, I think. And this is something that we see a lot as we speak to a lot of companies. One of the things that I’ve noticed, and I’ve been in the Salesforce ecosystem for just over six years now, started as an admin and worked my way all the product management, and now I’m doing the whole sales engineering solution engineering thing. Well, one of the things that I’ve noticed, and especially over the last few years is that Salesforce has this really incredible ability to move quickly and it’s because it’s a business owned application. So the business, the ones who are using it on a daily basis, they’re the ones who are providing these requirements and saying, “Hey, we need this because we need to be able to do this to move faster and bring more revenue.”

(03:35):
And that’s why they buy Salesforce is they want to get more value, they want to move quicker, all those kinds of things. And that’s wonderful! The problem is when an application is business facing and business owned, sometimes security falls off to the wayside. And that’s in a lot of ways, that’s because the security teams aren’t as entrenched with those same application teams like the Salesforce team, they would be in a traditional IT infrastructure. And so what you end up with is these blind spots within security because Salesforce is owned by the Salesforce team that’s business facing. And so you just end up with a lot of gaps in essentially what you’re looking at.

Waqas Nazir (04:20):
You also see that there’s a bit of a gap between the understanding of the way Salesforce works from a IT security perspective, and the business of course understands the feature set because they’re asking for these requirements. So they sometimes are more versed in the capabilities of the platform from an IT standpoint, while the IT security team may be lacking in their understanding or may not be there in their purview to even look at Salesforce. Right?

Tyler Walker (04:54):
Yeah. So in a lot of ways, sorry, can you rephrase the question? I got lost as we got through the half of it.

Waqas Nazir (05:01):
Basically, the challenge with implementing any security control is first the realization that there’s a need, otherwise there won’t be any incentive to do anything to address an area of security where there’s presumed no need. So do you feel like IT security may be not on the same wavelength when it comes to Salesforce and they may be actually lacking in some cases compared to their knowledge of the business owners who build on top of Salesforce?

Tyler Walker (05:43):
I do. I think that working in the Salesforce ecosystem, you have such a very interesting niche piece of knowledge. So much of what you’re doing is very specific. A Salesforce developer knows Apex; they know all these really great customizations. They can do really incredible things within the platform. Compare that to a traditional engineer. Well, you have full stack engineers, front end engineers, backend engineers. There’s a whole different subset of engineering that happens versus Salesforce. And Salesforce has a truly equal level of difficulty and really this domain knowledge that you have to have. And so when you start to try and integrate security protocol into Salesforce, there’s a lot of this back and forth of saying, well, we don’t have to worry about that because this is how Salesforce does this. But I think in that there actually lies a little bit of a trap, and it’s this idea of the Shared Responsibility Model, which I’m sure everyone who’s ever used Google; used AWS; has used any kind of cloud architecture is really familiar with. Which is this idea that as the customer or really as the vendor as Salesforce: “We promise we will make sure that the architecture, the infrastructure that underlies the Salesforce ecosystem is secure,”

(07:03):
“We’ll make sure that you’re not going to have an external breach that comes through our end into your multi-tenant atmosphere.” But the problem is, if you think of it like an iceberg, that’s a very small tip of the iceberg. It’s really easy to see. Those are the SOC questions that we get, but the real question comes in is, well, “What about the bottom half of the ice of the glacier?” Well, the bottom half of the ice of the glacier is ‘How do we control for our customers?’, ‘How do we control for our internal users?’ And that’s where you have things like MFA (Multi-Factor Authentication) and use policies, and we don’t bring your own device, but you can’t dictate that to the customer. And so that’s where I think there’s this big gap is: Salesforce is not going to do the scanning for you. It’s not going to check the data that’s coming in, and it’s just like inside of a DevOps lifecycle. They’re not going to go in and double check your code and make sure it’s not creating a vulnerability inside of your code base. It’s not accidentally opening up and an API that doesn’t need to be opened up to the world. And I think that’s really where that domain knowledge while also leveraging some of the best practices and repeatable patterns that security knows, and finding a way to marry those together can actually be hugely valuable to teams.

Waqas Nazir (08:25):
Yeah, I think the important aspect of this is understanding that while Salesforce may be positioned as just a very easy platform to customize, it actually has the same capabilities as any platform would.

Tyler Walker (08:44):
Absolutely.

Waqas Nazir (08:45):
You can deploy server side code, you can just write client side applications, you can have file storage, and then we’ll get into that in a little bit here. You can have really rich feature sets where you are interacting with many different applications. So talk to me a little bit about the way you’ve seen Salesforce being extended, especially when it comes to security. What are some of the more riskier areas? If you start delving into those, you start to really pay attention. Not to say people sometimes think every user on Salesforce is trusted. Then I remind them that one third of attacks come from trusted users. It is an important point, but some areas, of course are riskier for customization versus others. And if you want to maybe touch upon some of those and create a bit more context once we start jumping into more input validation and stuff like that.

Tyler Walker (09:50):
Absolutely. So especially with us coming up on Dreamforce, I’m sure everyone is going to hear the words “Customer 360” about 900 times if you attend Dreamforce, because that’s ALWAYS what Salesforce emphasizes. The Customer 360, they’re adding in AI and data cloud, and they’ve got all these wonderful things that they’re starting to add. But the problem is, is the Customer 360 actually creates more gaps. It creates more opportunities, I should say, for misconfigurations, for input evils, things like that. So as we start to talk about, okay, well, what are the things that I see the most often is most often and the things that I run across on my day to day is we see a lot of customers who aren’t looking at every single file and URL that’s coming into their system. And where are they coming in? So they’re coming in through web-to-case; email-to-case; web-to-lead; email-to-lead; experience portals, both the authenticated user login and the non-authenticated user login.

(10:51):
So those daily user logins, we see a ton of threats coming in that way. In fact, at the end of last year, we did a six month study of a whole bunch of Salesforce customers, and we asked them, “Have you seen any kind of incidents inside of your system?” And actually, over 50% of respondents couldn’t tell us. They just didn’t know. And it’s because again, they weren’t monitoring for those things. And it’s really, again, that idea of a gap. But what we also found is there’s a 250% increase in the number of attacks coming in that we monitored. And, of course, our company does a lot of things other than Salesforce, but what we were seeing is the trend is that because Salesforce is becoming so much more mission critical, because it is truly turning into this 360 degree customer experience, and there’s so many more channels for customers to provide feedback; for customers to provide files; for customers to provide videos; all these different things and ways that you’re interacting with your customers to actually generate more revenue and optimize the business.

(11:58):
The problem is, is because Salesforce is becoming so much more mission critical, you’re actually seeing that the trickle down effects of all of those inputs and especially inputs that are not validated or checked, you’re starting to see actually a great increase in the number of attacks that are actually starting to come into Salesforce and actually utilizing Salesforce as they’re jumping off board into internal infrastructure, which because Salesforce is a trusted system inside many infrastructures, it actually creates a vulnerability inside smaller systems or other systems, I should say, like (Microsoft) 365 and other internal systems, and it actually creates breaches and ransomware attacks on your internal infrastructure because of that.

Waqas Nazir (12:44):
That’s a very good point. So I think you mentioned Salesforce is almost like a sort of a pivot point, right? In any attack, there’s that lateral movement everybody wants. It’s cool to get your malicious binary into a system, but what can you do with it? And that’s where I think the bridge exists within an enterprise with these SaaS platforms and quote-unquote internal resources or systems used by employees, is that while these SaaS services are publicly available, once you get onto them, you have ability to then move laterally within the environment. So it’s interesting that the features that you mentioned like Web-to-case, web-to-lead, community sites; once you enable these, basically your Salesforce instance is available, even if it’s authenticated or not, the endpoints from a design perspective can be poked at from anybody on the internet. So it becomes basically a publicly facing application, not just an internal CRM system,

Tyler Walker (13:54):
Absolutely. Well, and especially with the advent and really the adoption of Lightning, in fact, at the end of this past year, we actually saw a really significant attack on Lightning, and it was a significant vulnerability that was identified by our team out on a customer in Japan where essentially Lightning was allowing guest user access to orgs that had guest users turned off. And these, as you’re utilizing Lightning if you’re not making sure that all of these settings are correct, and that’s where adding security into a DevOps process as well as in your production monitoring is so important is because of the level of risk that can be really accepted by Salesforce customers. Security has to be a part of the conversation from the very beginning, even in a dev hub, so that you can make sure that by the time it gets to production, it’s not only been vetted five or six times, but also whenever you do the monitoring, you have all the use cases monitoring correctly.

Waqas Nazir (15:01):
And I think you mentioned sometimes there are implications of enabling a feature which are not even evident, and that can be a very difficult challenge to address. If you were a security practitioner, you have business telling you, “Hey, I need this feature enabled,” right? And all of a sudden that feature is enabled, and now you may be exposed to an attack vector which you did not have visibility into. So it’s interesting to see how input into Salesforce is being abused in very creative ways. For example, recently we saw this issue with abusing the email service, right? For example, when an email comes, it’s pretty common that email alerts are generated by Salesforce. You get them all the time. You don’t think twice about them. It’s coming from a Salesforce address. It’s probably my sandbox or some environments talking to me and it’s easy for me to communicate. But now attackers are actually using that same email service to launch, for example, phishing attacks and getting malware distributed through them. So again, abusing the trust that comes with the platform, and it kind of is in line with what we’re talking about today, is do you trust everything that comes in or out of Salesforce? And if the answer is “yes”, then you have a big blind spot.

(16:38):
So speak to me a little bit about when somebody enables the ability to, let’s say, ingest content from a third party, whether it’s files like URLs, just structured data or unstructured data, what are some of the things that customers can do to ensure that that data is not malicious, it doesn’t affect the security of their users, and how can they do that sort of in a proactive way?

Tyler Walker (17:12):
Absolutely. So there’s a lot of different ways that you can do it, but the real simple answer is you can scan everything that comes in. You have to essentially adopt a zero trust policy with anything that’s coming in from an external user. So let’s take the example of a partner portal. You’ve gone to all of this effort to architect and design and experience that provides the partner with the right information at the right time. Okay, well, all of a sudden your partner is logging in at 3:00 AM at a time when they don’t normally log in and they are uploading a file saying, “Hey, I have a case. Here’s a snapshot of what I’m seeing inside of your org, and it’s showing me that I can’t access this information. I need to download something from your org,” right? Well, what they don’t tell you is that they’re not actually one of your partners.

(18:08):
They actually spoofed their email or they stole their credential because it happens all the time. And we’re not all as brilliantly secure as we think we are. I myself have had passwords stolen before, and it’s always fun to go through. But as part of that, this hacking group has gotten a hold of their password. It is a multi-pronged, multi-layered attack, and as part of it, what they’re going to do is they’re going to say, “Hey, here’s the website I went to in order to try and perform this action, and here’s a recording of that. And also, here’s a PDF of exactly the steps that I went through in order to reproduce this issue.” Well, all of a sudden we have multiple files that we’re unsure of their security, and once they get into our Salesforce, that’s not the end of the attack because like we said, it’s a multi-layered attack.

(19:01):
Now, when those files come into Salesforce, there’s multiple things that they can do on upload those files might have extra scripts added to them. Those extra scripts might make changes to an APEX class. It might add or open up an API backend through multiple different functions. There’s a lot of things that can actually be done through those files as they sit as content versions in your file repository inside of Salesforce. But where we’re actually seeing the most attacks, or really the most malicious scans actually being done is through URLs. URLs is one of the easiest, most simple ways to actually get people in to a dangerous pattern because what we see is these hacking groups will send a seemingly innocuous URL, it’ll go into the Salesforce, a service agent trying to move through and move their SLAs quickly and make sure they’re responding things because that’s what they’re being graded on.

(20:04):
That’s what they’re being looked at for. They’re clicking on a link and they’re going to this and it says, “Hey, you need to log into your Salesforce.” Okay, lemme go ahead and log in. Well, guess what? Now they’ve captured what your Salesforce login is. Now they can actually gain access to your Salesforce, and who knows what they’re going to do from there? They might go in and I mean, one of the easiest ways that companies will or hacking groups will actually utilize Salesforce data is they’ll open up the public API and they’ll use a curl script on a Lightning enabled page to actually go out and pull down all of the available information, including any master detail relationships, all of these powerful pieces of the Salesforce platform then become fodder for this attack. What we also see is sometimes they’ll use URLs that are time delayed or even files that are time delayed or situation or conditionally delayed.

(20:54):
So they’re waiting for, let’s say, Waqas to actually open up this file inside of Salesforce? Because he is trying to jump in on a big case, trying to make sure that he’s aware of what’s going wrong because maybe he has some knowledge, you have some knowledge of exactly what this problem might be. Well, the problem is is you have a ton of visibility to everything in your Salesforce. You’re the CEO, well, you have some information in your Salesforce I’m sure that you don’t really want to share with anyone else. Well, all of a sudden, some of that information gets exposed because that script that was waiting for the right person to click on it with the right level of visibility, all of a sudden does it. And all of these changes are now made in your org and they fill up your audit trail, so you can’t go back and find exactly what change it was.

(21:39):
There’s a lot of different ways these things can come in and attack, and we’re seeing it more and more basically every month we’re actually seeing a rise in it, and I can actually track it over time on how many attacks we’re seeing. I mean, last six months of last year is a 250% increase. We saw about the same in terms of an additional increase. So compounding increase the next six months. So we’re seeing this huge number of attacks that are actually coming through Salesforce because Salesforce is now being understood by these traditional app developers that are now hackers saying, well, hold on. We can use some of the oldest tricks in the book, things like polymorphic viruses to attack some of the newest systems, which would be Salesforce. So we’re seeing the oldest attacks in the newest of ways through the channels that companies want to leverage to get more value out of Salesforce.

Waqas Nazir (22:34):
Yeah, I think that’s a very good point around the old attack on the new system because people always think that they’re always sophisticated attacks, but if an old trick works, why reinvent the wheel? Which is why we’ve seen, we’ve documented some instances where a simple web form in Salesforce can potentially work through an attack chain to gain access as a system administrator through as simple a bug as cross site scripting, simple as… simple attack, which has been there since forever. What’s interesting also is the platform itself gives you some controls around what type of files you can receive, what’s allowed, what’s not allowed when you do click on a link, what type of warning you get. So how much of this is also an important aspect for a team to understand that this is a threat. We may have controls to mitigate this threat, but how freely should they be clicking on links and downloading attachments from Salesforce in a community portal and things like that. So part of that is user, end-user education. So do you think that plays a role as well, or what are some of the ways of doing that in a proactive way? In a Salesforce environment?

Tyler Walker (24:10):
You can’t ever go wrong with some SOPs, some Orders of Procedures. So I think that employee education is kind of the first rung is educating your employees on what is it that we are facing? What are the threats that are actually coming in, and how do we as a company address them? I think keeping everyone on the same page in terms of what your organization is actually doing actually helps your organization to identify new threats when they come in. So almost this teach your employees to be suspicious of anything that’s coming in. If it doesn’t look right, if it doesn’t smell right, report it and make that easy. So make that a part of what you’ve actually built into Salesforce is this ease of reporting, this ease of communication. And then once you’ve educated them, then it becomes understanding really what the use case is.

(25:07):
And I actually, I had a conversation with the Director of Experience called Practice over at Slalom. It was a couple of weeks ago, and I’ve actually writing a few articles about it, and we talked about there’s really, when you’re designing a customer experience, it really starts with architecting the experience first, and that’s understanding what data is being exposed or has to be exposed because again, the principle of least privilege is what we’re trying to go for here. And so understanding what do my customers need to have the experience we want them to have, and then what else can we turn off and remove? And kind of following that principle of least privilege within the features that you turn on, the data that you expose actually will do a lot after you have trained your employees to actually help them understand, well, this person is asking for the ability to upload a Excel sheet. Okay, tell them to upload it as a PDF or whatever it is that you’re following. But because they can have these scripts additional to that Excel sheet, that might place us at risk. But it really comes down to imagining how are we going to be attacked and understanding that the oldest tricks are probably still effective in Salesforce because the security side is really still kind of in its infancy, even though the security world is moving apace.

Waqas Nazir (26:36):
And I think, I don’t know, correct me if I’m wrong, but it’s been a while, I used to wonder why would Salesforce allow upload of binaries? They used to have this feature where you could select executables as enabled. So for the longest time I was like, what is the use case for somebody to upload an executable or a binary into Salesforce? So I was surprised. I mean, I’m sure it came with legacy support for some feature back In the day.

Tyler Walker (27:07):
Oh yeah, something that needed it.

Waqas Nazir (27:08):
Yeah. But now why would you allow end users to upload binary unless you were using a software distribution channel, which you can probably, but nonetheless, it was very interesting to see elements like that, which somebody would say is a big red flag still exists within the platform where people can trip over and actually create a lot of issues. So the other element I think we can briefly touch on is Third Party Systems, right? Sometimes you are not really interacting directly with end users. Salesforce allows you to create pretty rich customizations and integrations, and that allows you to then ingest data or use data in different ways. What are some of the ways you’ve seen these third party integrations play a role when it comes to input, validation or attacks such as malware and stuff like that?

Tyler Walker (28:15):
Absolutely. So some of the most frequent ones that we’ve run across especially is we talked to larger companies. So the ones who are, they’re accepting a lot of customer support cases or they’re dealing with a lot of these basically where they have to accept a lot of files. And so what they start to see is, well, our files, they’re growing larger than two gigabytes because maybe it’s a whole host of things that they’re accepting and they’re saying, well, we want it to be in a zip file, but even the zip file is over large. Okay, well, what we start to see is they start integrating with things like (Amazon) S3 three or Box, these external data repositories… or even SharePoint or things like that. And those are wonderful, except some of them don’t have malware scanning either. And so there’s a little bit of, again, that same gap that’s coming in where they’re the provider, they’re providing a safe data repository, but that safe data repository doesn’t account for the unstructured data that’s coming in.

(29:15):
Salesforce is truly the medium of communication. You also have Salesforce integrating with the SAPs and the Workdays and all these other different systems, and that information may flow across. For example, at one point I worked for a large gym and they had just purchased Salesforce. Early in my career, I was a Salesforce admin, and I was blown away by how they had built this integration between a kiosk, a Salesforce, a membership system, and then back to Salesforce then created this really non-functioning, I should say, in a flow of integrations. And what was crazy is there were these customer documents that were being uploaded across these integrations multiple times. And as I started to look into more of the security side of what they had built, I realized that there was a huge amount of lack of security, I should say a huge amount of lack in the security posture that they had.

(30:14):
And again, came back to security wasn’t consulted as part of the build. Security didn’t get to take part in the implementation, they were just consulted on the initial purchase. And I think in a lot of ways, as Salesforce is being used, it’s being used as this great, it’s becoming the great integrator between all of your different systems so you can derive more value from it. I think that we’re starting to see people realizing how much of a risk Salesforce is placing them at if they’re not performing the right levels of validations at every step of the process, not just on upload, but also on the download or also on the API connection providing essentially this wraparound Salesforce because it’s the great integrator to provide protection for the SAPs and the Workday so that you’re not infecting multiple systems and then receiving that same ransomware attack into your internal email system, your internal network architecture. Because again, these are all trusted sites that are inside of your firewall, and I think that’s really where the danger lies,

Waqas Nazir (31:26):
Right? Yeah. So I think coming towards the end of our time here, one thing that we can kind of agree to and hope to take it home with this session is to not make any assumption when it comes to validation of outside input into Salesforce, whether it’s URLs, files, just data strings, input fields. The way you would handle that in any platform should be the same security controls you would have in Salesforce. And it is not to say if you don’t do anything over there, you don’t need to do it anything here. But the point is the same attack vectors exist for Salesforce. So as consumers of Salesforce, it’s our responsibility to make sure that the content that is coming in is being validated and is being sanitized and being presented to users is kosher and clean for them to interact with. And if they don’t do that, they’re opening themselves up to an attack and potentially their entire enterprise. So appreciate Tyler, you walking us through this very interesting and unique and complex blind spot hope. We shared some information which is valuable to folks who are struggling with the same challenges or may not be aware of them, but now can gain some understanding of it. We’re available here to ask any questions or any comments, so we’ll turn it over to Andy to moderate those.

Andy Montoya (33:07):
Yes, thank you gentlemen. We do have a couple of questions that came through, so I’ll go ahead and start with the first one. Does Salesforce itself have settings or tools to check for to check inputs?

Tyler Walker (33:20):
So if you’re talking about field inputs, yes, you can do validation rules, things like that inside the fields, but if you’re talking about unstructured data, so file uploads, even checking URL safety. No, it does not. And that’s the big gap that we’re solving for.

Waqas Nazir (33:37):
Yeah, there’s small controls like Tyler mentioned. For example, if you create a pick list, you have validation rules, like some structured data, you can control what comes into your system. But once you open it up to freeform fields like input fields, rich text fields, files as Tyler mentioned, and then links, I think the only control they have is that alert saying, “Hey, you’re about to leave Salesforce and go somewhere else,” but it doesn’t tell you whether where you are going to is safe or not. So good question.

Andy Montoya (34:11):
Thank you both. Alright, so we have another one here. Can you explain the term least privilege?

Tyler Walker (34:19):
Yes. So the Principle of Least Privilege, if you’re familiar with any kind of Salesforce literature, they talk about this a lot. So it’s the idea that you should only provide access to the level that is required to perform the function. So if I am a service agent, I’m working in customer service, I really only need access to the cases that I own or the case queue that I’m a part of or anything that I own inside of the org. I don’t need access to reports and dashboards that I don’t view. I don’t need access to any data that’s not my own. The idea here is that we don’t want to expose anything inside of our salesforce org that is not directly related to the job function that we complete. And we do that so that we aren’t accidentally causing a breach. We aren’t accidentally exposing information to people who don’t need it. And there’s actually, I saw an article as I was getting on here about there was a data leak at X or formerly Twitter and it was caused by an internal person, and it really comes down to the Principle of Least Privilege. We want to provide the least amount of data to the person who needs it so that they can do their job, but they can’t access anything else that they don’t need.

(35:44):
I hope that makes sense.

Andy Montoya (35:47):
Absolutely. Thank you, Tyler. So we got two more here on the docket. Next one is ‘How can I check inputs or files that already exist in my org?’

Tyler Walker (36:00):
Absolutely. So that’s actually something that you can find partners on the app exchange for. You can just look up cloud protection for Salesforce, things like that. But there are tools on the app exchange. I’m trying not to be real commercial here, but there are tools that can actually do the manual scanning for you. They’ll go out, they’ll check all of your URLs and files inside of your org to make sure that they are safe, and then if they are dangerous, they’ll actually remove them, place them in the recycling bin and make them get them out of the way without actually disturbing the functions and customizations you actually built into your system.

Waqas Nazir (36:44):
One thing that I can also add is that content actually needs to be rendered. So even though it may just be saved in the backend on render, you can still sanitize, right? For example, if it’s malicious input before you load it on a screen or on a page, you can basically validate that before presenting it to the end user. So that’s sort of like the best principle when it comes to implementing input. Validation is one is you validate, but then you also sanitize. So you have a multi-layered protection that you just not have one point of failure, whereas where you’re just ingesting something. But also when you’re displaying it or when it’s going up to the end user, you can actually still validate it at that point or encode it or what have you, or remove it if need be. So that’s another strategy.

Andy Montoya (37:40):
Okay, great. Thank you both. I got one here. So ‘W use Salesforce in almost every department, but I don’t think anyone talks about security, how can I get started, how do I start getting everyone to think about security, including input issues, et cetera?’

Tyler Walker (38:00):
That’s a really incredible question actually. And this is one that I face on a pretty typical day. It really starts to come down to the first person to realize that there’s a problem. Once you’ve realized that there’s a problem, you can bring that problem to the movers and shakers in your organization if you’re not an Enterprise App director, if you’re someone who’s an admin, but you’re thinking on that level of how do we provide this protection for everyone inside of our organization? That’s where really just bringing the problem to the people who make the decisions is how you can do it. And really, there’s two prongs here, because again, like we said in the beginning, Salesforce is business owned, it’s business facing. The business makes a lot of the decisions for it. But go ahead and try and buy a new vendor for Salesforce, buy a new app on Salesforce.

(38:59):
I guarantee your security team is going to want to get involved or be required to get involved. So what you can always do is you can bring the problem to security team, but also to whoever owns your Salesforce instance, whether that’s a platform owner, enterprise app director, and then of course your security team and say, ‘Hey, when’s the last time that we actually assessed for this?’Because I think we might be at risk.’ And thankfully, generally, if you bring a problem to a team, they’ll, a lot of times they’ll listen to you and actually allow for some open discourse around it.

Waqas Nazir (39:35):
And also you have to realize the challenges that we spoke about is not realizing that there’s a threat is a big challenge. So for you to realize that I think is a step in the right direction because the same assumptions or same, I would say same status quo may exist in other parts of your company where they think you don’t have to worry about Salesforce security, but if you do, I think bringing them along with the same journey would help you address this problem. And that I think would be a systematic way of addressing it, is creating that awareness versus just saying, Hey, you have a problem and what have you.

Andy Montoya (40:30):
Thank you both. Okay, we had a couple more come through, but I think these last two should be it. One, ‘Do you have one or two tips for showing the value or the dollar value of security and products like DigitSec for colleagues, managers, and clients?’ Thank you.

Waqas Nazir (40:50):
So I mean, there’s the scary answer to that. We all know how much a breach costs, and that’s the typical answer that you’ll get whenever somebody says you have to invest in security. But I think more importantly, when you look at security, you’re mitigating your exposure or you can look at it, it is enabling you to do faster things with more confidence, right? So if you have the right controls in place, you can actually innovate at a faster pace. For example, if you enforce a certain baseline of security when you’re developing within Salesforce, you’ll have the confidence to ship quicker versus the unknowns or having to deal with incidents when they happen in production. So while you can try to justify investment in security saying, “Hey, it’s going to cost us $5 million if you lose this data,” that’s one way of presenting your argument. Second is saying, “Hey, we don’t have these controls in place for these areas of development, and once we do, we’re actually be faster in our implementations because we know that we have controls around here, and so we can expose them. We don’t have to worry about our security team to step in every step of the way and say, ‘Hey, now what you’re doing,’ or ‘why are you doing that?'” Right? So if you have those baseline controls where you’re analyzing the security of your changes, analyzing the input that’s coming, the content that you’re consuming, then you’ll be able to do that in a quicker way.

Andy Montoya (42:36):
Awesome. Thank you Waqas. And then last question we have is, “Is there any specific feature present in Salesforce that will scan content as it’s being uploaded to Salesforce so that it doesn’t contain any malicious code?”

Tyler Walker (42:52):
So as far as on the production side, so things coming in from communities, web-to-case, email-to-case, there’s no out of the box functionality of Salesforce that scans your content and they’re very clear about that. The shared responsibility model, it really covers that piece, which is you’re receiving content into your tenant instance of Salesforce. We’re not going to scan that. That’s your responsibility to make sure that that’s not malicious, but there are partners on the app exchange that can provide that level of protection. And of course DigitSec can talk to the pre-production side of that scan as well.

Andy Montoya (43:37):
Alright, gentlemen, I think that does it for questions. Thank you so much. Any last parting words before we go?

Waqas Nazir (43:46):
I’ll let you go first, Tyler.

Tyler Walker (43:48):
Alright, well it’s been an absolute pleasure. I do thank you so much for the opportunity to come out here and talk about security. I really do think, especially when it comes to content, it’s one of the most overlooked pieces of the Salesforce platform as far as the security conversation goes. People just aren’t thinking about the content, the files, the URLs that are coming into their Salesforce. So the opportunity to actually share that and talk about it and obviously do that with our partner, DigitSec, has been great.

Waqas Nazir (44:18):
Thank you very much, Tyler. It’s been a pleasure to have you. Thank you for making time. I think you definitely shared an area that is a Blind Spot for a lot of folks, so hopefully we’re enlightening the path for folks to implement security. Thanks once again, everybody was here and we appreciate your time.

Andy Montoya (44:39):
Sounds good. Thank you everyone. Take care.

Waqas Nazir (44:41):
Bye.

Tyler Walker (44:42):
Thanks.