Justin Hazard
00:00:00
From Code to the Cloud cuts through the noise to get to what really matters. The insights and tactics that help you maintain a consistently secure and productive DevOps strategy.
Welcome to From Code to Cloud, a DevSecOps podcast focused on the Salesforce ecosystem. I'm Justin Hazard, Principal Security architect at autorabbit and I'll be your host.
My guest today is Matt Myers, a Salesforce Certified Technical Architect, CEO at Easy Protect and a member of the Low Code Security Alliance. Welcome Matt, and thanks for joining us.
Matt Meyers
00:00:34
Thanks Justin. Glad to be here.
Justin Hazard
00:00:37
Before we get started, let's learn a bit more about our guests.
Matt, can you share with us some interesting something interesting about yourself that we can learn from that we can't learn from your LinkedIn profile?
Matt Meyers
00:00:49
Sure. I think we were just talking about that a little bit earlier. I'm actually really big on.
I love cooking and I just planted a garden in my house and I love eating like farm to market types of food. So I think that's kind of one of the things that I try to do when I'm not focusing on Salesforce and data security. I actually love cooking.
That's actually how I relax. Where most people might disagree with that, something to relax, be relaxing. But for me that's kind of how I unwind.
I'll leave that one to the expert on the call because it is not a way that I relax. I can promise that. So let's dive in. Salesforce digital experiences are a major aspect of providing customers with services that they need.
Safeguarding these experiences presents its own set of unique challenges.
How have things and features like multi factor authentication, OAuth based authentication and permission sets evolved in Salesforce and are they still effective?
Justin Hazard
00:01:53
Sure.
I, I mean I, I don't, I mean first of all say I think they, they are still effective and I, because I think they're evolving and that's why they're still effective.
But I think things have changed over, you know since the very beginning because if you look at the very beginning of time of Salesforce I think it was just started out with profiles and that was it. It was some basic permissions and then they started moving this, evolving this permissions on the profile and then started moving certain things.
So some things were even out of the profile. It was a global for the org like IP ranges and things like that. And then they started moving that more and more into the profile.
Then came from permission sets which helping to make those more granular permissions because they found customers had hundreds of profiles. So that was helping to kind of Split that up.
But then, then I think lately with the release of the permission set groups is really helping to get to that that layer to more manageable because I think it was just shifting all those permissions from the profile now to the permission set.
Were just basically creating permission sets that were like profiles and then assigning those to people where now the, the groups are kind of more like the profiles and then you have the individual permissions. So instead of having like the permission set being sales user, the group is sales user.
And if I'm let's say I can perform multiple roles, let's say I can do sales and service. Well I can. You could add me the group, the sales user, service manager, whatever.
And then those permissions below that are, are at the lower level like permission sets like you know, edit cases, view cases, things like that are your permission sets. So I think that all of that is kind of helping.
Salesforce has really helped to to bring it up and make it a lot more manageable because it's had become very unmanageable and now it's getting a lot better.
And then I know recently they just also added some features to Salesforce where you can actually see what permissions people have from the user record itself. And I think there's like a report kind of thing you can run to see what has modify all, who has view all, what has mod, you know, object permissions.
That's great. On the last point of mfa I think you know that that's also helping to.
It's a different kind of permissions permissioning but that's helped to secure orgs a lot better understanding.
I mean the different ways that people could access Org and different ways that I mean you're controlling who can get to it because I mean let's face it passwords nowadays that aren't really that secure and even Microsoft I believe recommends that people don't change their passwords. The day the password is insecure is the day gets hacked and you see a lot of people post its with their passwords.
So instead of focusing around the password focus on all those other factors to to prevent people that can get to those passwords for get in or just create multiple barriers for people to get into Org keeping that data secure.
Matt Meyers
00:04:46
Yeah, it's the evolutionary nature I think. Right.
So I mean as, as things evolve and as threats evolve and as attackers find different ways of accessing an companies are finding different ways to make sure that you aren't over permissioned but at the same time you can get to the level of granularity that you need to in each regard.
Justin Hazard
00:05:07
Yep.
And I'm looking forward to the day when people passwords in general are eradicated since I don't believe passwords are very secure actually and just because of the human factor of it. So if we can get to that point where some other mechanisms exist so people can can it's all like multiple different factors.
Not password, not sending you a link to your email, but something else to maybe biometric authentication or something like that so you truly can understand who is that person versus having password base or other things like that. Because even if you have multi factor if your factors aren't secure then that's. I mean just as bad as a bad password as well.
Matt Meyers
00:05:48
Yeah, I agree. But what are you seeing and what challenges do you see that are remaining despite the standard tools and practice that we have in place currently?
Justin Hazard
00:05:59
I mean, I think going back to just the challenges of misconfiguration in Salesforce really there's so many different options and Salesforce so many different things that you can choose. It's hard to understand or know who has what in. In sell in an org. I think like I mentioned recently, the.
The new features they released where they can.
You can kind of look into users, see what access users have or certain profiles have now, which is nice in the org, but still there's a lot of things I think prior we were talking about like for example sharing rules.
So if you have an apex sharing rule on a record and maybe it applies it when the record's saved, how does that user know that that action they're doing on the record is actually giving access to somebody else? And then how did the dev team that is that you know, is there no like five years later when the original team that built it that that's there.
I think there's a lot of things that are still holes there that it's just hard to. Really hard to know.
And I think that's why penetration testing other things like that are critical because it's not only looking at your configuration, but can you get in from the outside world. Is it actually secure? I think is really the ultimate thing.
Matt Meyers
00:07:15
Yeah. The misconfiguration and the over permissioning is something that we've been seeing a lot of as well.
Especially when a role gets created and then that role is expected to only be used within this application.
But now that role is being used by another application that provides even additional more permissions than were necessarily initially thought or were conceived when the role was created. Right. So what are some of the most common misconfigurations you've seen in the Salesforce Digital experience?
Justin Hazard
00:07:47
Well actually considering I have my book here that I wrote on Salesforce Digital experiences about a story of how one of my customers in my previous life got some unethical hacker reached out to them and told them that their they were able to get to over 5,000 records containing private information and cases. So and that was through the guest user. So if you're, you know want to understand the story, go buy the book on Amazon.
But outside of that I think what I'm seeing mostly is I think a lot of is people just don't understand or don't think about what are the risks when you from a Salesforce Digital experience or even anything in Lightning. Because Lightning is powered by the by APIs just like you can attack do the rest API.
Everything you see on the page layouts, all your fields, where the fields are located and the data in those fields are all run by these APIs that normally you regular customers won't use. But without those APIs are all client side because these days everything's on that client side. Not very, not as much on the server side.
So it's not that it's a risk in Salesforce having all these APIs to exposed, it's the fact that you know, it's you what's used to run the system and instead of locking down the APIs, it's locking down the data. So if you don't lock down the data, people can still get to those APIs. And I think that's what was not has not been communicated very well to people.
I think in the Salesforce ecosystem is that hey, you can't stop people from executing the APIs that can get to your data, but you can stop people to get to the data itself if you configure it correctly.
And I think it's really thinking about that security first mindset of if, if I can, if, if you've configured the user to be able to see case records and see private information case records, even if it's not on the user interface, they can, people can still get to it.
And that's really what happened here was they, they hid these case records because they figured okay, it's not on the ui, they can't see it, no one can get to it because that's the way it used to work before everything became client side.
But actually in reality you can use these lightning APIs to query records, update records, delete records, execute Apex and even Flows So because those records are accessible in the security model, this attacker was able to get those records.
But if you shut down, if you lock down that data and just take that mindset of don't give people access to the data they don't need access to, even if you don't think it can be accessible via the ui, still only give them access to what they need to do to perform their job.
So for example, from the digital experience perspective of the guest user, well, if you are not comfortable with everyone in the world seeing that data, then don't give it the guest user access to that data. And I think that's the mindset you need to take is if everyone can see this data, I'm okay with it.
Or if everyone in this person is, are you okay with this person can see everything you're giving them access to? Because they probably can if they know what they're doing.
So one other interesting thing on this as well, just because this is recent today I I was back to penetration testing.
This is a true way you can know if you do have data exposes run a penetration test against your org about not Salesforce as the platform, but your customizations in Salesforce.
So I actually ran a tool today against just a random, random site that I came across and I actually came found that I was able to access over 2,000 account records and this is publicly imagine your entire account database of all of your accounts in Salesforce are now accessible to the outside world. I mean that, that's pretty much I think as bad as it gets. So. So anyway, moral story here, you know, lock down all your data.
Don't just rely it's because it's not in the ui they can't see it. Always imagine anyone can see the data that you've given access to your users it for those users.
Matt Meyers
00:11:53
So I'm going to go a little off script here because there's a couple of different things that I want to key off on.
The first is and I don't want to get in trouble with the marketing team so I'm not going to say anything too much but I know autorabit is getting ready to release a product and we've teased a little bit about it last couple of weeks that should start to help to understand those permissioning and the over permissioning and where that over permissioning is happening so that you can start to lock those things down or at least have visibility into it, which is extremely difficult as you've laid out earlier. But the other component you hone in and you say this a lot and I'm glad that you do of locking down the data.
And I don't think that I've had a single customer conversation. I don't think I've talked to anybody in the salesforce ecosystem or sphere that has not been talking about agent force or AI in some shape or form.
And I think it's really interesting and I love the point when you continuously say locking down the data because if I'm not mistaken, didn't you recently give a talk at TDX on good agent versus bad agent where if you lock down the data that would not be become a thing. Correct. So you want to talk about that a little bit?
Justin Hazard
00:13:10
Sure, sure.
And I, I mean I, I think just going back to like really, I think everything starts at that DevOps layer though with all of this is, I mean having those repeatable deployment processes, knowing what you've configured, knowing, you know, making sure that people haven't changed what's already there.
So having tools available so you can know what's in your org today and then knowing that you know what you think is in your org is actually what's in your product. I think those kind of tools are really good, really good to have. And then I think AI is going to help with a lot of that as well too going forward.
More stuff be able to help automate some of that stuff. But specifically from the data security on my talk at TDX was bad agent, good agent.
And it's really was around that thing of training your agent correctly just like you would train an employee. So if you don't tell your employee, even if you gave your employee first off, you don't want to give your.
You wouldn't give your employee admin access to your org, so you shouldn't give your agent admin access to your org. So you want to think of your agent like it's your employee.
And then then even after you given them access, you would train your employee to only give out the data that the correct data to the right person.
So for example, you wouldn't tell your employees, for example healthcare claim saying if someone gives me just a claim number, I'm going to give them all the private information about that claim that's that's there. I would ask other things. What's the last four of your social. What is your birth date, maybe your address, maybe your last payment, right?
And so same thing, you need to train your agent to do those same things. Make sure you put those gates up so that they can't just say okay, give Can I see claim 1 or 2? 5. Can I see claim 1 or 2? 6. 1 or 2? 7.
If you don't teach an employee to ask those questions, then they're going to do the same thing.
So that's why you have to, you have first, number one, lock down the data just like you would employ, only give the agent access the data, same as you would employ.
And then beyond that, train the agent not to give away company secrets or secrets of people's information that they shouldn't before authenticating who that person is.
Matt Meyers
00:15:16
It makes sense because eventually you'll just have spillage over spillage after spillage of data, and that's never a good thing, so.
Justin Hazard
00:15:23
Exactly. And then I would say one last thing on top of that is even after you've authenticated them, only give out the information that's necessary.
So like, for example, do I really need to be given my Social Security number when I already know my Social Security number number? That's just exposing data and giving more a, the potential that someone could intercept that and steal that data.
So only give the data that's necessary.
Like, like my claim information, what I, what I did, what's the status of my claim, all that I already know my birthday, I already know my, my, my social. You don't need to give that to me.
Matt Meyers
00:15:56
Yeah, it doesn't make a ton of sense at all.
Justin Hazard
00:15:59
Yeah, exactly.
Matt Meyers
00:16:00
No, but now, okay, so I'm going to ask you a question. It's a little bit more near and dear to my heart because I grew up in detection in the security world.
So which tools and processes are most beneficial for both monitoring security considerations while also providing audit trails for compliance?
Justin Hazard
00:16:20
Sure. I, I think I, I, I'm, I think there's some tools I, I really like out there and others.
But I think from a, just from a monitoring, ongoing monitoring and compliance perspective, I think there's the two lenses. You have the lens of is your salesforce configured correctly?
And you have the lens of, from the outside world to do, you know, can you get in there and can you actually do something if it's not configured correctly? And I think, I mean first, of course I would, as I said before, start with your DevOps and the DevOps tools and all that.
So if you don't, if you're not, if you don't have a good DevOps process in your, you know, CI CD process and how you're managing your code, your changes flowing into your org, I don't think anything else matters, matters because I mean, if you can't stop people from doing changes that aren't authorized, then there's nothing you can do there. Right. And so and I think, I mean without being biased here since hey, this, you know, this is an auto Rabbit blog.
I mean I think autorout is a great tool. I think there's other a lot of great tools out there as well around the DevOps space. Another one I really like is Elements.
I think they tie together really well with all the DevOps tools out there as well because they help understand what's in your org, what's, you know, what's going on, the documentation around it from the security end of it. I really like Varonis actually I like them because they're in my book also I quoted them. They help.
They really have some great tools to understand those misconfigurations in your org, what kind of things you should be looking for. Even have a way to do quasi health check pen test which is really good.
I think they're really knowledgeable also about Salesforce and kind of what you can be doing on some of those things. Those are some of the ones I personally like.
But I know there's a lot of other tools out there for various reasons also I guess being a little bit biased. The tool we produce easy protect. You have virus scanning your files. You should make sure your files are being virus scanned in Salesforce.
I think that's another one to protect your data.
Matt Meyers
00:18:23
So anyway, yeah, I mean again, I'm going to give the little bias plug as well one of the tools that getting ready to come out.
I think the audit trail component of it is going to be super helpful for a lot of different people because it's not always easy to go through Salesforce logs and figure out what happened, where and how it happens.
So I think being able to see changes not only to permissions, but to the organization and records and whatnot is going to be the most important thing. Especially you know, God forbid somebody gets into an incident or a breach scenario. Those things occur.
And you know, we come from a breach first background. So I think thinking through those things so you have an easy way of identifying okay, this happened, which ultimately led to this component.
Justin Hazard
00:19:16
So and I think that's a good point you just said is a breach first mindset of. I think the thing that people always think about is like how do I. How do I make it so I never get a breach? Well, I have bad news for you.
You will get a breach someday. And it's. I think it's just a matter of how you Contain that breach.
I think last time we were talking about castles, I love castles and they have multiple walls and I think it's putting up many different layers of walls. So they don't that once the army storms are castle, they don't get into the, you know, into the center.
They just make it to the outside and then you're able to eradicate them really quickly. And I think there a lot of that is. That's where the monitoring component comes in. And I.
There are a couple I actually forgot to even mention here is shield. Shield, really good one as well. And then there's a lot of tools that work on top of shield as well.
It's like the event monitoring and things like that. And then other people built tools that can dig into that event more and giving you better things.
Also security center and Salesforce too, giving you some of those other, you know, insights. So I think the key here is whatever tool you're using, making sure you're.
You're not only putting those controls in place, but you're constantly monitoring to ensure that those controls are working.
Matt Meyers
00:20:26
Yeah, I mean, I think that's.
Justin Hazard
00:20:30
Yeah, I think actually here's another great, great analogy. I actually, this happened to me the other night.
It's like a little bit of a personal story, but I was asleep in my house and then I forgot to lock my door. And it was like 2am at night. I started hearing noises in the house.
And so first off I did was monitoring to make sure that my security controls were in place and were working correctly. Right. So I could have had an intruder in my house. And so I went and locked the door.
So if you have, you know, you notice that there's a security issue in your org, you go lock your door. Do you just stop there? No. What did I do? Well, it's 2:00am at night, the house is dark. I turn on all the lights.
You turn your lights on, you walk around the house, make sure no one's in your house. Your house is your org. Right.
You want to make sure if you found a security hole, make sure no one's already in your house after you close and lock the door. And I think that's an important lesson for people to be thinking about.
Matt Meyers
00:21:28
Yeah. And. And continuously doing that.
Justin Hazard
00:21:32
Yes. Not all, just. Yeah. Just because you lock the door doesn't mean they won't find another way in.
Every day you should be checking your windows, make sure there's not a broken window somewhere or your lock's not working. And then every day you're locking the Doors.
It's not that, because when people are coming in and leaving, maybe you had someone do some work on the house, maybe they, they opened up something and that lets them in later. So I think you always need to be looking in for any kind of issues at all times.
And then, then I can think the last thing is then of, you know, we're using this analogy here is once you found an issue, what do you do? You call the police or then you, you know, make sure, then you get some people to come in and fix that, that issue and you make sure.
How did that happen? I want to learn from that, that so that doesn't happen again.
So I think it's a full cycle that you need to go through to really understand and be able to maintain, you know, monitor your breaches, fix your breaches and learn from your breaches. So. And keep hardening your system.
Matt Meyers
00:22:27
Yeah.
And you know, off podcast we've had a couple of conversations and one of the things that you've consistently brought up, which I always for from a guy from ir, you bring up pickerel. It's the IR lifecycle, if you will.
But it also applies in the exact same realm of what you're talking about here and taking the entirety of this conversation and kind of putting it into that pickerel mindset. Like P stands for preparation. Right.
So it's hardening your systems, it's hardening all of your permissions and making sure the people that are supposed to have access to data set A and data set B, only the people that are supposed to have access to data set A have access to data set A and so forth for B.
And then, you know, to your analogy of making sure all of your doors and your locks are working and then your windows and the locks and the windows are working and none of the windows are broken and the door jam isn't busted in any way, shape or form, and there isn't a gaping hole in your ceiling that somebody could climb a ladder and jump through or anything else like that. But once you do that, then you get into the identification phase. Right. And the investigation phase.
So using different tools and different things that you have at your disposal, you can go back and say, were we over permissioned? Yes, we were or no we weren't. And what, what potentially happened there so that you can contain, eradicate, remediate, and then do lessons learned. I.
Exactly one point that I will make. Not a lot of people understand me when I initially say this, so I'm gonna just say it and then I'LL explain it real quick.
But even if you have something that could be determined to be an incident or a data breach or compromise, whatever you use, whatever vernacular you use in, in your organization, and it's determined to be non malicious, you should still go through each one of those steps. Leave it all the way through. There's a couple of different reasons why. One, for me, it's practice. You practice going through all the steps.
It's not as difficult when you actually have to do it. The second component is you're going to find value in each one of those steps.
Something is going to happen and you're going to find some form of value in that, especially in the lessons learned component of it. But the third component of it is you're looking at it from a little bit of a different lens. Right.
When you're in an active breach, you know you're sweating all the time.
Justin Hazard
00:24:58
You're in panic mode.
Matt Meyers
00:25:00
Exactly right.
You're probably sleep deprived and there's a ton of stuff going on, but you have a different perspective of it now because you're not necessarily as worried, but you can look at it and you can think through different possible implausible scenarios for permissioning or for MFA or for an API set, whatever the case may be.
You have the ability to look at those perspectives and then potentially contain and eradicate those particular problems and still go through the exact same set. So I think surmising the entirety of this conversation, I would say apply Pickroll no matter what you do.
Thank you for, for teaching me that some 15 years ago. I feel old saying 15 years, but here we go. Matt, anything to add to that?
Justin Hazard
00:25:49
Yeah, actually. So I think it's really interesting because for our company, EasyProtect, as I mentioned, we're doing virus scanning in Salesforce.
We've actually come through our own evolution. When we first started the company, a lot of people don't realize Salesforce isn't scanning for viruses.
So a lot of our customers beat on board and then really what they were looking at was, okay, can you stop once the virus came in, can you stop someone from getting to it? Well, they identified it, we stopped it. Great. But then they don't do anything else.
And what we started learning more and more is like, it's that same thing. It's just because, you know, it's a virus, it's still a threat. There's lots of other threats too, just like we were talking about earlier.
But you really need to. You don't just stop when the threat's found. And you stopped it. You need to look at what was that downstream impact did maybe that person.
It's on the computer and that they've hit other systems. Well, now that same threats in those other systems have eradicated those systems. How did it get it in the first place?
And I think what we're where this is a little bit of a future teaser of what we're working on right now is we're actually working on so you could do incident management in our own platform. It's not just about identifying the threat.
It's creating an incident ticket, regardless if a threat was, you know, actually got to something, or if it didn't, but you're still cataloging that threat and then you're basically having it. So somebody actually has to. Has to sign off on that and check that off, say, hey, yes, this is been addressed.
Or maybe it's like it gets assigned to another team who needs to act on it, and then you have your postmortem on that ticket. So every threat is a ticket, regardless if it actually caused a breach or not.
Because then you're able to say, okay, the everything's good, we learned from this, or it's everything's, I think, still a learning experience. So for us, we were kind of hitting that next evolution of our own product as well, of kind of going using that same framework.
Because it's not just about stopping those. The threats. It's about the whole evolution and stopping future threats as well.
Matt Meyers
00:27:46
Yeah.
I mean, coming from a background of working in a sock and working thousands, if not millions of alerts in my career, one thing that drove me nuts when I was training somebody that's brand new to the, to the SOC environment is they'd be like, oh, well, this is blocked. Okay, how did it get there? Is it supposed. Did it come through a way that it's supposed to.
And do we need to put up some kind of a gate to make sure that that doesn't happen again and get onto a host or into the organization, or did it come in some way that we weren't expecting it to come in, and now all of a sudden we've got a different problem that we've got to look at. So you can look at it from both the how, you know, malware was out here, viruses were out here, and now they're in our organization.
How did that happen? And then also, what happens when you execute it? Right? Like, what does that look like? Is there something that we're missing on that?
Do they have something bundled up that we didn't necessarily see before. So I. I think that's a great point, and I think it's something that absolutely everybody should be looking at and everybody should be doing. So.
Appreciate that.
Justin Hazard
00:28:55
Exactly. Exactly.
Matt Meyers
00:28:57
Well, I want to thank you for joining us on another episode from From Code to Cloud. We'll be releasing informative con conversations with industry leaders every month, so be sure to subscribe to the show wherever you stream podcasts.
You can also Visit us at www.autorabbit.com for show notes, helpful links, and access to every single episode as they're released. Stay out there, stay safe, and we'll see you. See you next time. Thanks, Matt, for joining us.
Justin Hazard
00:29:25
Thank you. I really appreciate the opportunity.
Matt Meyers
00:29:28
Not a problem.
00:00:00
From Code to the Cloud cuts through the noise to get to what really matters. The insights and tactics that help you maintain a consistently secure and productive DevOps strategy.
Welcome to From Code to Cloud, a DevSecOps podcast focused on the Salesforce ecosystem. I'm Justin Hazard, Principal Security architect at autorabbit and I'll be your host.
My guest today is Matt Myers, a Salesforce Certified Technical Architect, CEO at Easy Protect and a member of the Low Code Security Alliance. Welcome Matt, and thanks for joining us.
Matt Meyers
00:00:34
Thanks Justin. Glad to be here.
Justin Hazard
00:00:37
Before we get started, let's learn a bit more about our guests.
Matt, can you share with us some interesting something interesting about yourself that we can learn from that we can't learn from your LinkedIn profile?
Matt Meyers
00:00:49
Sure. I think we were just talking about that a little bit earlier. I'm actually really big on.
I love cooking and I just planted a garden in my house and I love eating like farm to market types of food. So I think that's kind of one of the things that I try to do when I'm not focusing on Salesforce and data security. I actually love cooking.
That's actually how I relax. Where most people might disagree with that, something to relax, be relaxing. But for me that's kind of how I unwind.
I'll leave that one to the expert on the call because it is not a way that I relax. I can promise that. So let's dive in. Salesforce digital experiences are a major aspect of providing customers with services that they need.
Safeguarding these experiences presents its own set of unique challenges.
How have things and features like multi factor authentication, OAuth based authentication and permission sets evolved in Salesforce and are they still effective?
Justin Hazard
00:01:53
Sure.
I, I mean I, I don't, I mean first of all say I think they, they are still effective and I, because I think they're evolving and that's why they're still effective.
But I think things have changed over, you know since the very beginning because if you look at the very beginning of time of Salesforce I think it was just started out with profiles and that was it. It was some basic permissions and then they started moving this, evolving this permissions on the profile and then started moving certain things.
So some things were even out of the profile. It was a global for the org like IP ranges and things like that. And then they started moving that more and more into the profile.
Then came from permission sets which helping to make those more granular permissions because they found customers had hundreds of profiles. So that was helping to kind of Split that up.
But then, then I think lately with the release of the permission set groups is really helping to get to that that layer to more manageable because I think it was just shifting all those permissions from the profile now to the permission set.
Were just basically creating permission sets that were like profiles and then assigning those to people where now the, the groups are kind of more like the profiles and then you have the individual permissions. So instead of having like the permission set being sales user, the group is sales user.
And if I'm let's say I can perform multiple roles, let's say I can do sales and service. Well I can. You could add me the group, the sales user, service manager, whatever.
And then those permissions below that are, are at the lower level like permission sets like you know, edit cases, view cases, things like that are your permission sets. So I think that all of that is kind of helping.
Salesforce has really helped to to bring it up and make it a lot more manageable because it's had become very unmanageable and now it's getting a lot better.
And then I know recently they just also added some features to Salesforce where you can actually see what permissions people have from the user record itself. And I think there's like a report kind of thing you can run to see what has modify all, who has view all, what has mod, you know, object permissions.
That's great. On the last point of mfa I think you know that that's also helping to.
It's a different kind of permissions permissioning but that's helped to secure orgs a lot better understanding.
I mean the different ways that people could access Org and different ways that I mean you're controlling who can get to it because I mean let's face it passwords nowadays that aren't really that secure and even Microsoft I believe recommends that people don't change their passwords. The day the password is insecure is the day gets hacked and you see a lot of people post its with their passwords.
So instead of focusing around the password focus on all those other factors to to prevent people that can get to those passwords for get in or just create multiple barriers for people to get into Org keeping that data secure.
Matt Meyers
00:04:46
Yeah, it's the evolutionary nature I think. Right.
So I mean as, as things evolve and as threats evolve and as attackers find different ways of accessing an companies are finding different ways to make sure that you aren't over permissioned but at the same time you can get to the level of granularity that you need to in each regard.
Justin Hazard
00:05:07
Yep.
And I'm looking forward to the day when people passwords in general are eradicated since I don't believe passwords are very secure actually and just because of the human factor of it. So if we can get to that point where some other mechanisms exist so people can can it's all like multiple different factors.
Not password, not sending you a link to your email, but something else to maybe biometric authentication or something like that so you truly can understand who is that person versus having password base or other things like that. Because even if you have multi factor if your factors aren't secure then that's. I mean just as bad as a bad password as well.
Matt Meyers
00:05:48
Yeah, I agree. But what are you seeing and what challenges do you see that are remaining despite the standard tools and practice that we have in place currently?
Justin Hazard
00:05:59
I mean, I think going back to just the challenges of misconfiguration in Salesforce really there's so many different options and Salesforce so many different things that you can choose. It's hard to understand or know who has what in. In sell in an org. I think like I mentioned recently, the.
The new features they released where they can.
You can kind of look into users, see what access users have or certain profiles have now, which is nice in the org, but still there's a lot of things I think prior we were talking about like for example sharing rules.
So if you have an apex sharing rule on a record and maybe it applies it when the record's saved, how does that user know that that action they're doing on the record is actually giving access to somebody else? And then how did the dev team that is that you know, is there no like five years later when the original team that built it that that's there.
I think there's a lot of things that are still holes there that it's just hard to. Really hard to know.
And I think that's why penetration testing other things like that are critical because it's not only looking at your configuration, but can you get in from the outside world. Is it actually secure? I think is really the ultimate thing.
Matt Meyers
00:07:15
Yeah. The misconfiguration and the over permissioning is something that we've been seeing a lot of as well.
Especially when a role gets created and then that role is expected to only be used within this application.
But now that role is being used by another application that provides even additional more permissions than were necessarily initially thought or were conceived when the role was created. Right. So what are some of the most common misconfigurations you've seen in the Salesforce Digital experience?
Justin Hazard
00:07:47
Well actually considering I have my book here that I wrote on Salesforce Digital experiences about a story of how one of my customers in my previous life got some unethical hacker reached out to them and told them that their they were able to get to over 5,000 records containing private information and cases. So and that was through the guest user. So if you're, you know want to understand the story, go buy the book on Amazon.
But outside of that I think what I'm seeing mostly is I think a lot of is people just don't understand or don't think about what are the risks when you from a Salesforce Digital experience or even anything in Lightning. Because Lightning is powered by the by APIs just like you can attack do the rest API.
Everything you see on the page layouts, all your fields, where the fields are located and the data in those fields are all run by these APIs that normally you regular customers won't use. But without those APIs are all client side because these days everything's on that client side. Not very, not as much on the server side.
So it's not that it's a risk in Salesforce having all these APIs to exposed, it's the fact that you know, it's you what's used to run the system and instead of locking down the APIs, it's locking down the data. So if you don't lock down the data, people can still get to those APIs. And I think that's what was not has not been communicated very well to people.
I think in the Salesforce ecosystem is that hey, you can't stop people from executing the APIs that can get to your data, but you can stop people to get to the data itself if you configure it correctly.
And I think it's really thinking about that security first mindset of if, if I can, if, if you've configured the user to be able to see case records and see private information case records, even if it's not on the user interface, they can, people can still get to it.
And that's really what happened here was they, they hid these case records because they figured okay, it's not on the ui, they can't see it, no one can get to it because that's the way it used to work before everything became client side.
But actually in reality you can use these lightning APIs to query records, update records, delete records, execute Apex and even Flows So because those records are accessible in the security model, this attacker was able to get those records.
But if you shut down, if you lock down that data and just take that mindset of don't give people access to the data they don't need access to, even if you don't think it can be accessible via the ui, still only give them access to what they need to do to perform their job.
So for example, from the digital experience perspective of the guest user, well, if you are not comfortable with everyone in the world seeing that data, then don't give it the guest user access to that data. And I think that's the mindset you need to take is if everyone can see this data, I'm okay with it.
Or if everyone in this person is, are you okay with this person can see everything you're giving them access to? Because they probably can if they know what they're doing.
So one other interesting thing on this as well, just because this is recent today I I was back to penetration testing.
This is a true way you can know if you do have data exposes run a penetration test against your org about not Salesforce as the platform, but your customizations in Salesforce.
So I actually ran a tool today against just a random, random site that I came across and I actually came found that I was able to access over 2,000 account records and this is publicly imagine your entire account database of all of your accounts in Salesforce are now accessible to the outside world. I mean that, that's pretty much I think as bad as it gets. So. So anyway, moral story here, you know, lock down all your data.
Don't just rely it's because it's not in the ui they can't see it. Always imagine anyone can see the data that you've given access to your users it for those users.
Matt Meyers
00:11:53
So I'm going to go a little off script here because there's a couple of different things that I want to key off on.
The first is and I don't want to get in trouble with the marketing team so I'm not going to say anything too much but I know autorabit is getting ready to release a product and we've teased a little bit about it last couple of weeks that should start to help to understand those permissioning and the over permissioning and where that over permissioning is happening so that you can start to lock those things down or at least have visibility into it, which is extremely difficult as you've laid out earlier. But the other component you hone in and you say this a lot and I'm glad that you do of locking down the data.
And I don't think that I've had a single customer conversation. I don't think I've talked to anybody in the salesforce ecosystem or sphere that has not been talking about agent force or AI in some shape or form.
And I think it's really interesting and I love the point when you continuously say locking down the data because if I'm not mistaken, didn't you recently give a talk at TDX on good agent versus bad agent where if you lock down the data that would not be become a thing. Correct. So you want to talk about that a little bit?
Justin Hazard
00:13:10
Sure, sure.
And I, I mean I, I think just going back to like really, I think everything starts at that DevOps layer though with all of this is, I mean having those repeatable deployment processes, knowing what you've configured, knowing, you know, making sure that people haven't changed what's already there.
So having tools available so you can know what's in your org today and then knowing that you know what you think is in your org is actually what's in your product. I think those kind of tools are really good, really good to have. And then I think AI is going to help with a lot of that as well too going forward.
More stuff be able to help automate some of that stuff. But specifically from the data security on my talk at TDX was bad agent, good agent.
And it's really was around that thing of training your agent correctly just like you would train an employee. So if you don't tell your employee, even if you gave your employee first off, you don't want to give your.
You wouldn't give your employee admin access to your org, so you shouldn't give your agent admin access to your org. So you want to think of your agent like it's your employee.
And then then even after you given them access, you would train your employee to only give out the data that the correct data to the right person.
So for example, you wouldn't tell your employees, for example healthcare claim saying if someone gives me just a claim number, I'm going to give them all the private information about that claim that's that's there. I would ask other things. What's the last four of your social. What is your birth date, maybe your address, maybe your last payment, right?
And so same thing, you need to train your agent to do those same things. Make sure you put those gates up so that they can't just say okay, give Can I see claim 1 or 2? 5. Can I see claim 1 or 2? 6. 1 or 2? 7.
If you don't teach an employee to ask those questions, then they're going to do the same thing.
So that's why you have to, you have first, number one, lock down the data just like you would employ, only give the agent access the data, same as you would employ.
And then beyond that, train the agent not to give away company secrets or secrets of people's information that they shouldn't before authenticating who that person is.
Matt Meyers
00:15:16
It makes sense because eventually you'll just have spillage over spillage after spillage of data, and that's never a good thing, so.
Justin Hazard
00:15:23
Exactly. And then I would say one last thing on top of that is even after you've authenticated them, only give out the information that's necessary.
So like, for example, do I really need to be given my Social Security number when I already know my Social Security number number? That's just exposing data and giving more a, the potential that someone could intercept that and steal that data.
So only give the data that's necessary.
Like, like my claim information, what I, what I did, what's the status of my claim, all that I already know my birthday, I already know my, my, my social. You don't need to give that to me.
Matt Meyers
00:15:56
Yeah, it doesn't make a ton of sense at all.
Justin Hazard
00:15:59
Yeah, exactly.
Matt Meyers
00:16:00
No, but now, okay, so I'm going to ask you a question. It's a little bit more near and dear to my heart because I grew up in detection in the security world.
So which tools and processes are most beneficial for both monitoring security considerations while also providing audit trails for compliance?
Justin Hazard
00:16:20
Sure. I, I think I, I, I'm, I think there's some tools I, I really like out there and others.
But I think from a, just from a monitoring, ongoing monitoring and compliance perspective, I think there's the two lenses. You have the lens of is your salesforce configured correctly?
And you have the lens of, from the outside world to do, you know, can you get in there and can you actually do something if it's not configured correctly? And I think, I mean first, of course I would, as I said before, start with your DevOps and the DevOps tools and all that.
So if you don't, if you're not, if you don't have a good DevOps process in your, you know, CI CD process and how you're managing your code, your changes flowing into your org, I don't think anything else matters, matters because I mean, if you can't stop people from doing changes that aren't authorized, then there's nothing you can do there. Right. And so and I think, I mean without being biased here since hey, this, you know, this is an auto Rabbit blog.
I mean I think autorout is a great tool. I think there's other a lot of great tools out there as well around the DevOps space. Another one I really like is Elements.
I think they tie together really well with all the DevOps tools out there as well because they help understand what's in your org, what's, you know, what's going on, the documentation around it from the security end of it. I really like Varonis actually I like them because they're in my book also I quoted them. They help.
They really have some great tools to understand those misconfigurations in your org, what kind of things you should be looking for. Even have a way to do quasi health check pen test which is really good.
I think they're really knowledgeable also about Salesforce and kind of what you can be doing on some of those things. Those are some of the ones I personally like.
But I know there's a lot of other tools out there for various reasons also I guess being a little bit biased. The tool we produce easy protect. You have virus scanning your files. You should make sure your files are being virus scanned in Salesforce.
I think that's another one to protect your data.
Matt Meyers
00:18:23
So anyway, yeah, I mean again, I'm going to give the little bias plug as well one of the tools that getting ready to come out.
I think the audit trail component of it is going to be super helpful for a lot of different people because it's not always easy to go through Salesforce logs and figure out what happened, where and how it happens.
So I think being able to see changes not only to permissions, but to the organization and records and whatnot is going to be the most important thing. Especially you know, God forbid somebody gets into an incident or a breach scenario. Those things occur.
And you know, we come from a breach first background. So I think thinking through those things so you have an easy way of identifying okay, this happened, which ultimately led to this component.
Justin Hazard
00:19:16
So and I think that's a good point you just said is a breach first mindset of. I think the thing that people always think about is like how do I. How do I make it so I never get a breach? Well, I have bad news for you.
You will get a breach someday. And it's. I think it's just a matter of how you Contain that breach.
I think last time we were talking about castles, I love castles and they have multiple walls and I think it's putting up many different layers of walls. So they don't that once the army storms are castle, they don't get into the, you know, into the center.
They just make it to the outside and then you're able to eradicate them really quickly. And I think there a lot of that is. That's where the monitoring component comes in. And I.
There are a couple I actually forgot to even mention here is shield. Shield, really good one as well. And then there's a lot of tools that work on top of shield as well.
It's like the event monitoring and things like that. And then other people built tools that can dig into that event more and giving you better things.
Also security center and Salesforce too, giving you some of those other, you know, insights. So I think the key here is whatever tool you're using, making sure you're.
You're not only putting those controls in place, but you're constantly monitoring to ensure that those controls are working.
Matt Meyers
00:20:26
Yeah, I mean, I think that's.
Justin Hazard
00:20:30
Yeah, I think actually here's another great, great analogy. I actually, this happened to me the other night.
It's like a little bit of a personal story, but I was asleep in my house and then I forgot to lock my door. And it was like 2am at night. I started hearing noises in the house.
And so first off I did was monitoring to make sure that my security controls were in place and were working correctly. Right. So I could have had an intruder in my house. And so I went and locked the door.
So if you have, you know, you notice that there's a security issue in your org, you go lock your door. Do you just stop there? No. What did I do? Well, it's 2:00am at night, the house is dark. I turn on all the lights.
You turn your lights on, you walk around the house, make sure no one's in your house. Your house is your org. Right.
You want to make sure if you found a security hole, make sure no one's already in your house after you close and lock the door. And I think that's an important lesson for people to be thinking about.
Matt Meyers
00:21:28
Yeah. And. And continuously doing that.
Justin Hazard
00:21:32
Yes. Not all, just. Yeah. Just because you lock the door doesn't mean they won't find another way in.
Every day you should be checking your windows, make sure there's not a broken window somewhere or your lock's not working. And then every day you're locking the Doors.
It's not that, because when people are coming in and leaving, maybe you had someone do some work on the house, maybe they, they opened up something and that lets them in later. So I think you always need to be looking in for any kind of issues at all times.
And then, then I can think the last thing is then of, you know, we're using this analogy here is once you found an issue, what do you do? You call the police or then you, you know, make sure, then you get some people to come in and fix that, that issue and you make sure.
How did that happen? I want to learn from that, that so that doesn't happen again.
So I think it's a full cycle that you need to go through to really understand and be able to maintain, you know, monitor your breaches, fix your breaches and learn from your breaches. So. And keep hardening your system.
Matt Meyers
00:22:27
Yeah.
And you know, off podcast we've had a couple of conversations and one of the things that you've consistently brought up, which I always for from a guy from ir, you bring up pickerel. It's the IR lifecycle, if you will.
But it also applies in the exact same realm of what you're talking about here and taking the entirety of this conversation and kind of putting it into that pickerel mindset. Like P stands for preparation. Right.
So it's hardening your systems, it's hardening all of your permissions and making sure the people that are supposed to have access to data set A and data set B, only the people that are supposed to have access to data set A have access to data set A and so forth for B.
And then, you know, to your analogy of making sure all of your doors and your locks are working and then your windows and the locks and the windows are working and none of the windows are broken and the door jam isn't busted in any way, shape or form, and there isn't a gaping hole in your ceiling that somebody could climb a ladder and jump through or anything else like that. But once you do that, then you get into the identification phase. Right. And the investigation phase.
So using different tools and different things that you have at your disposal, you can go back and say, were we over permissioned? Yes, we were or no we weren't. And what, what potentially happened there so that you can contain, eradicate, remediate, and then do lessons learned. I.
Exactly one point that I will make. Not a lot of people understand me when I initially say this, so I'm gonna just say it and then I'LL explain it real quick.
But even if you have something that could be determined to be an incident or a data breach or compromise, whatever you use, whatever vernacular you use in, in your organization, and it's determined to be non malicious, you should still go through each one of those steps. Leave it all the way through. There's a couple of different reasons why. One, for me, it's practice. You practice going through all the steps.
It's not as difficult when you actually have to do it. The second component is you're going to find value in each one of those steps.
Something is going to happen and you're going to find some form of value in that, especially in the lessons learned component of it. But the third component of it is you're looking at it from a little bit of a different lens. Right.
When you're in an active breach, you know you're sweating all the time.
Justin Hazard
00:24:58
You're in panic mode.
Matt Meyers
00:25:00
Exactly right.
You're probably sleep deprived and there's a ton of stuff going on, but you have a different perspective of it now because you're not necessarily as worried, but you can look at it and you can think through different possible implausible scenarios for permissioning or for MFA or for an API set, whatever the case may be.
You have the ability to look at those perspectives and then potentially contain and eradicate those particular problems and still go through the exact same set. So I think surmising the entirety of this conversation, I would say apply Pickroll no matter what you do.
Thank you for, for teaching me that some 15 years ago. I feel old saying 15 years, but here we go. Matt, anything to add to that?
Justin Hazard
00:25:49
Yeah, actually. So I think it's really interesting because for our company, EasyProtect, as I mentioned, we're doing virus scanning in Salesforce.
We've actually come through our own evolution. When we first started the company, a lot of people don't realize Salesforce isn't scanning for viruses.
So a lot of our customers beat on board and then really what they were looking at was, okay, can you stop once the virus came in, can you stop someone from getting to it? Well, they identified it, we stopped it. Great. But then they don't do anything else.
And what we started learning more and more is like, it's that same thing. It's just because, you know, it's a virus, it's still a threat. There's lots of other threats too, just like we were talking about earlier.
But you really need to. You don't just stop when the threat's found. And you stopped it. You need to look at what was that downstream impact did maybe that person.
It's on the computer and that they've hit other systems. Well, now that same threats in those other systems have eradicated those systems. How did it get it in the first place?
And I think what we're where this is a little bit of a future teaser of what we're working on right now is we're actually working on so you could do incident management in our own platform. It's not just about identifying the threat.
It's creating an incident ticket, regardless if a threat was, you know, actually got to something, or if it didn't, but you're still cataloging that threat and then you're basically having it. So somebody actually has to. Has to sign off on that and check that off, say, hey, yes, this is been addressed.
Or maybe it's like it gets assigned to another team who needs to act on it, and then you have your postmortem on that ticket. So every threat is a ticket, regardless if it actually caused a breach or not.
Because then you're able to say, okay, the everything's good, we learned from this, or it's everything's, I think, still a learning experience. So for us, we were kind of hitting that next evolution of our own product as well, of kind of going using that same framework.
Because it's not just about stopping those. The threats. It's about the whole evolution and stopping future threats as well.
Matt Meyers
00:27:46
Yeah.
I mean, coming from a background of working in a sock and working thousands, if not millions of alerts in my career, one thing that drove me nuts when I was training somebody that's brand new to the, to the SOC environment is they'd be like, oh, well, this is blocked. Okay, how did it get there? Is it supposed. Did it come through a way that it's supposed to.
And do we need to put up some kind of a gate to make sure that that doesn't happen again and get onto a host or into the organization, or did it come in some way that we weren't expecting it to come in, and now all of a sudden we've got a different problem that we've got to look at. So you can look at it from both the how, you know, malware was out here, viruses were out here, and now they're in our organization.
How did that happen? And then also, what happens when you execute it? Right? Like, what does that look like? Is there something that we're missing on that?
Do they have something bundled up that we didn't necessarily see before. So I. I think that's a great point, and I think it's something that absolutely everybody should be looking at and everybody should be doing. So.
Appreciate that.
Justin Hazard
00:28:55
Exactly. Exactly.
Matt Meyers
00:28:57
Well, I want to thank you for joining us on another episode from From Code to Cloud. We'll be releasing informative con conversations with industry leaders every month, so be sure to subscribe to the show wherever you stream podcasts.
You can also Visit us at www.autorabbit.com for show notes, helpful links, and access to every single episode as they're released. Stay out there, stay safe, and we'll see you. See you next time. Thanks, Matt, for joining us.
Justin Hazard
00:29:25
Thank you. I really appreciate the opportunity.
Matt Meyers
00:29:28
Not a problem.
