Episode 26: Org Security with Doug Merrett | Salesforce Developers Podcast

As developers, we need to be aware of what security features are available in Salesforce and how we can keep the organization safe and secure. Today, Doug Merrett, Manager of Security and Compliance Advisors for Salesforce in Australia, joins me to talk about org security. Together we explore the importance of keeping your data safe, how to keep it safe, and why you should be doing your own backups in addition to Salesforce daily exports.

Show Highlights:

Some of the things you should be considering regarding field-level security, including maintaining a level of confidentiality for users within your company or organization.
What to do if somebody has stolen your org credentials and gets in the “front door.”
Using IP restrictions and two-factor authentication as layers of org security.
How two-factor authentication and the Salesforce authenticator application work.
What you should consider when it comes to securing an auth loop within a connected app.
Some day-to-day procedures you can do to make sure your data is going to be safe.
Event monitoring and how it materially increases the security of your Salesforce org.

Resources:

Episode Transcript

00:07

Doug: And so you know, you need to be aware of what security features are in Salesforce and, and how you can help the company be safe and secure because you don’t want to be responsible for a data leak, right? Yeah, that heaven forbid, right? That would be very, very bad having your company up on the on the press saying, you know, 8000 credentials stolen from company x.

00:27

Josh: That is Doug Merrett, manager of the security and compliance advisors in Australia for Salesforce. I’m Josh Birk, a developer evangelist at Salesforce. And here on the Salesforce developer podcast, you’ll hear stories and insights from developers for developers. I have known Doug for years and today, I will bring a conversation on that very topic, security, specifically org security. Now, this will be one of our longer episodes, because with a topic like this, I didn’t really want to edit out much. And we started the ground level talking about field level security.

00:55

Doug: Yeah, that’s that’s very important as a first part of keeping your data safe, right? Making sure that People who should see the data can’t see the data. And people who shouldn’t see the data can’t see the data. So fill up security is really key you need to understand who are the user communities in your company. So you’ve got the finance folks, you’ve got the sales folks, you’ve got the management folks, you’ve got the, you know, the people on the road, that if you’ve got people out there doing service field service stuff, you need all these different communities of people need to understand what they need to do to do their job. And maybe the finance folks need to see the the outstanding debt on the account, but the field service folks that need to see that. And so you need to sort of minimize the data visibility to people because it just reduces your attack vector into your data, right? If you can minimize what people see. You can’t get rid of it all clubs are gonna do their job, but you got to give them what they need, but not too much.

01:54

Josh: Because I mean, this is baked into the data layer, so Heck, yeah, also terrible thing. But if some Like got my credentials got into Salesforce, at least they’re only getting the particular keys of the kingdom that I would actually have access to.

02:07

Doug: That’s very true. How about we can talk about how we can stop them using your credentials, even if I did steal them?

02:14

Josh:Let’s do that. But let’s really quickly code wise from a field level security point of view, or are there some specific things I should be considering?

02:22

Doug: Well, yeah, when code runs by default, it runs as an as God inside your Salesforce instance. So we can see everything inside your Salesforce org, right? So that you need to do that sometimes, because the payroll clock shouldn’t necessarily know what the CEOs pay is, but they got to run the job to actually generate the pay. So write an Apex class behind it means be able to see that stuff but the person running that job doesn’t need to see it. So that’s why Apex runs as God by default, but you can do the width sharing, and the width sharing part of the apex class then enforces the end users sharing rules apply Hold on, I’ve got a visibility rules upon that Apex limits that Apex capability to just what that person can do and see which is wonderful.

03:07

Josh: And also love to give a shout out to the episode that we did a while ago with Chris Peterson on Spring 20 features which was heavily centered around security, including the with security and forced to clause for SOQL being rolled out, as well as the strip inaccessible with the Apex in order to strip out fields that people aren’t supposed to see.

03:29

Doug: Yep, those two features make a big difference, right? So make sure that you keep on top of all the the release notes, right. I know, it’s a big read. But every developer should read all the release notes every single time that I’ve printed, I’ve actually kept 11 and a half years of Salesforce release notes on my PC in PDF format, because you never know when things get released. And you’ll go back and make sure that you understood this correctly. So right. Yeah, always read the release notes, folks. It’s something which I strongly suggest is a good idea.

04:00

Josh: So then going back to that previous point, if you have somebody who’s, you know, somebody’s stolen their credentials that are in through the front door, what are some things that you can do?

04:10

Doug: Well, actually, you can stop them getting in the front door by doing a few things better, right? Don’t let them just put lock the door, right. So one of the things you can do in Salesforce is, is use IP restrictions. So on each profile, there’s an ability to add IP address ranges, which are allowed to access. So what we suggest you do is every company obviously hooks onto the internet and they normally have a small range of IP addresses that they own right when they if you access the internet from their company, because it goes out through one, one network cable normally, and so what we suggest you do is put that IP range into the profiles that you have inside your inside Salesforce. And that way, you must log in from your corporate network, which is wonderful. So that way, you can Limit people’s browser access to your corporate IP address. So that means if someone steals your credentials in the in country x overseas who’s not a nice country, they can’t actually log in because they’re not part of that IP address. Now, that’s one way of doing it, which is one step. But also what you should look at doing is using two factor authentication, which is free of charge. Now Salesforce has got a great two factor authentication application, and I’ll talk about in a sec. But another thing also is my domain and using single sign on, if you set up my domain, set up, single sign on and do IP restrictions, that basically means that it’s going to be very, very difficult for people to get into your version of Salesforce, they’ve got to get into your corporate network, they’ve got to then get the credentials are gonna be able to log on and do that sort of stuff through your single sign on tool. So it adds a lot more steps for the hacker to get in. And as usual, right, you don’t need to be the most secure in the whole world or you need to be more secure than everybody else in your fight.

05:58

Josh: Right? Well, that’s interesting because I think a lot of people consider Single Sign On and might have been to be features which are not necessarily associated with security, like, like my domain is something that as a developer, I mostly think about when it comes to like lightning web components. And then the way namespaces are going to work out within my code. And when it comes to single sign on, I think of that as well, I think of it as authentication but more of a luxury of authentication to make it easier to sign it not necessarily to make it more secure.

06:27

Doug: What’s the side effect, right? It makes it easy for the users to use Salesforce, but also it makes it more secure. And just on that note, people want to talk about IP restrictions. People think, oh, what about mobile devices? Well, that’s a different kettle of fish because Salesforce mobile actually has the ability to do different IP settings. So you can say, must be inside the corporate network all the time. Or you can say I need to be on a corporate network when I first authenticate, which is how we do it at Salesforce. So when I want to use my Salesforce mobile on my phone for work, I’ve got to be on the corporate network. On the VPN to actually initially authenticate with Salesforce, but then I can go to any IP address because I’m walking around the streets using my cell cellular connection to actually to do Salesforce. So the mobile is not affected as such by the IP restrictions for browser there two separate settings. But what you should do is blend them together so restricted for your browser, but then on your mobile, probably the best setting most people tend to use is the you have to be on the corporate network to initially authenticate, but it can go any way you like afterwards,

07:32

Josh: because I assume that that lines up with something just adjacent to what we’re talking about in the sense that, you know, the presumption there is I was on the network, I authenticated as Josh. And now that my mobile device is still with me, that mobile device is secure. And so the layer of device security would probably be an addendum there.

07:53

Doug: Exactly. Because I’m Salesforce by itself can actually inflict some extra security upon your device I can make you have a longer passcode, that sort of stuff as well. So it can make the make your mobile device a little bit more strong, which is great. And that’s something which people really worry about. But Salesforce mobile has got a great security white paper, you can go to do a search for Salesforce mobile security, and it will give you a nice white paper explaining exactly how we do security on a mobile device. So we encrypt the stuff at rest, you can wipe it remotely automatically, etc, etc. All those sort of stuffs available to you.

08:30

Josh: Cool focusing on that mobile phone. How does two factor authentication and the Salesforce authenticator application actually work?

08:38

Doug: great segue, Josh. So with the two factor authentication app that Salesforce has, it’s free of charge on the app exchange, sorry, on Google Play or on Apple’s App Store. And what it does, it uses the standard industry standard algorithm for doing two factor authentication which is a time based protocol. Time sorry, time based

09:05

on the time of it

09:07

to TP what the heck’s that stand for my brains gone guacamole.

09:10

Oh, to TP. God,

09:15

it’s on the tip of my tongue.

09:16

I sorted my car to time based one time password. There you go.

09:21

Josh: There you go.

09:23

Doug: Right, let’s go back. So hopefully they can edit that last little bit out and stick in this bit. So Salesforce uses a standard industry algorithm called RFC 6238 uses a time based one time, password. And that’s a really cool thing because everybody uses that sort of stuff now. So Salesforce is authenticator can actually work with other tools. So on my authenticator app on my phone, I actually use it with ionic for Salesforce, obviously, but also for PayPal, my Microsoft accounts, and Amazon, I’ve got an Amazon account as well. It’s all in there plus a couple of other other systems out there. That use that sort of technology to do two factor authentication. And two factor authentication is actually quite good because it relies upon two things, what’s called two factor. Well, the first factor is something you know, which is normally your password. And the second factor is something you have, which is your device, which has the token on it. And that’s how you have the two factor authentication. And the way it works is really cool. Because with Salesforce is two factor authentication, you can type in the six digit code, which changes every 30 seconds. Or if it’s a Salesforce. org, trying to connect, it’ll actually just pop up saying, hey, do you want to get led into this org and you hit hit accept. And it makes it a lot more of a pleasant experience for the end user to actually be able to just hit that authenticate button rather than having to type in a six digit code and maybe get it wrong. So it makes it really nice user experience. But the nice thing is as well, Salesforce, actual backup all your codes to the cloud. And if you lose your phone, you can actually restore your two factor codes onto your new phone, which is wonderful because if anybody’s ever lost your two factor authenticator and you had to go through an Amazon reset for your two factor authentication. They want to really make sure that they say you are right. And so it’s not. It’s what they call non trivial. So if you lose it, so that’s where our authenticator backing things up is great. So even if you’re not using Salesforce is a bit of a plug. We’ll probably walk in this in this podcast, but use your authenticator for everything else as well. PayPal, Amazon, Salesforce, it’s a great product.

11:28

Josh: Yeah, I mean, it’s kind of the security equivalent of locking both your keys and your driver’s license in the door.

11:35

11:39

Okay, well, we’ll kind of on the idea of front doors, although I suppose this is a little bit more of a side door. We we’ve been talking mostly about Salesforce as an application, related app and features. But there’s a there’s a lot that we can do from that API first model when it comes to connecting Back to the platform with third party applications, mobile applications, other web applications, etc. That’s all going through a connected app in order to identify the app. What should What should we be considering when it comes to securing down that? oauth loop in that connected app?

12:17

Doug: Yeah. So what happens is, by default, Salesforce allows, I want apps to connect to your org. And the administrator then has the ability to then to turn them off. So if they notice that someone’s logged in with dodgy Dave’s discount data extractor tool, right, then then, you know, they can actually disable that some of our bigger customers and some of our more security focused customers may actually want to ask tech support to actually enable whitelisting on the on the OAuth access. Now, this has got some interesting side effects, right. So what that actually means is, by default, you can’t connect to any app to your version of Salesforce by the API. Zero, which that means you have to actually whitelist every app, you want to let into your version of Salesforce. And that’s a good thing. But it does add extra administration capabilities on to the admins role, right. And that’s where being technical again, it’s one of these things, right? If you’re a mom and pop shop, and it just two or three people in the company, then you may not need to have that level of, of, of security focus. But if you’re a large multinational bank, you probably do want to stop people getting in and actually pulling out data they can see via any any unknown app. So the whitelisting thing is really quite powerful. You need to raise a case and get it enabled in your org. But then what’ll happen is you have to whitelist every app you want to connect. And then if you have an old app that only uses the soap API, you need to create a connected app for that and actually, make sure that the users have use any app API. ticked, this little option turns out when you do this, and that’s fine. But then also that sort of does let them use any app to get into the into your version of Salesforce. So you sort of got to trust that particular user not to do stuff they shouldn’t do. So in all honesty, you should be making sure that folks actually are using up to date apps using a wolf as the authentication protocol that makes it a heck of a lot easier for everyone concerned. But somehow back end systems that have to use soap, you may want to just limit that to one particular app, add API user, and tie down the IP addresses and tie everything else down so you know that they can’t do anything else.

14:36

Josh: So keep the side door open, but only for like one particular identity.

14:41

Doug: Yeah, exactly. And also limit the IP ranges coming from to make sure it only comes from this particular machine or this particular external customer who needs access via soap.

14:50

Josh: Because all of this stuff is it’s like abstraction of trust. If you’re a small five to 10 person, company, see everybody all day all day long. Anyway, you probably kind of trust everybody who’s around. around the dinner table, that when you’re a 50,000 employee company, and you just kind of don’t know what people are looking up to, you might want to start battening down the hatches a little bit more.

15:11

Doug: Yeah, definitely. And it’s not a case of you must do that. It’s one of those things, but you need to balance the risk and the reward, right? And that’s one of the things you want. So security is never about yes or no, it’s about how much risk is there? And how much risk Am I willing to take?

15:25

Josh: Right? Do you want to walk to the you want to walk or drive a car or catch an airplane, there’s actually inherent risk in all those three. And so you need to work out which is the least risky for you and which one you’re willing to take that risk on? And that’s the same thing with security is never a hard and fast yes or no, it’s more about what level of greater you want.

15:44

In in while we’re on that tangent. I mean, this is true for people in their day to day lives. I mean, anybody who has you know, use Facebook on a day to day basis. You’re constantly having to weigh in that question of do I trust this app? And do I still trust this app or should it be revoked

16:00

Doug: Yeah, exactly. So I actually use Facebook myself for sharing photos and sort of stuff. But I’ve turned off all app access to my Facebook account.

16:08

Josh: Yeah, because I mean this that has some pretty famous examples of, you know, somebody trying to figure out what character from a movie they might be, but they’re also giving a random company in a random country, all their personal data.

16:22

Doug: Yeah. Which is a wonderful, right. And people don’t understand that. That’s one of the things where I think a lot of people need to understand a lot more about security, because even even things like all of these IoT connected devices and having a clever front door that lets people in and out of your house, that sort of stuff. myself, personally, I’ve got a mechanical key. No way. There’s no way in this cotton pickin world, I’m going to have some form of electronics sticking on my front door is gonna let people in and out because I build electronics. I build software, I make mistakes. I’m not doing the same thing. Right?

16:52

Josh: Well, let’s go back and frame that for everybody because you know, you have done a lot of it in the past. Have you I mean, you’ve literally built a robot. So it’s not the you you have a lot of success in that area. But it’s still not something you want the good old analog when it comes to your front door security.

17:12

Doug: Yeah, exactly. I mean, yes, you can’t pick a lock, but it takes a different set of skills. With these connected front doors, right, you need to make sure the product you’re buying is a secure product, and also has been vetted and has updates quite regularly. Right? If you buy a no name brand from somewhere, you never know where that’s come from, who wrote the code? How secure is it isn’t going to be updated? And can somebody driving past one of these double quotes script kiddies who drive past with a Wi Fi device and hop onto your front door and unlock it and walk right in? And I think if people read their insurance policies, it’s quite interesting. If there’s no sign of forced entry, it’s not a threat, not a robbery.

17:51

Josh: Not a break in and entry.

17:52

Doug: Not to make an entry. Exactly. So you know, you might end up losing all your stuff and you can’t claim it back on insurance.

17:57

Josh: Yeah, I think that’s interesting. It’s like I You know, I’m a huge fan of like Alexa and a lot of like the voice assistant technology and things like that. And I looked into you know, there’s a lot of, that’s the right way to put it, there’s a lot of discomfort around some of these devices that can always be on are always listening. But at the same time, like, if you look at the list of really bad culprits, it’s the devices that fit into that camp that you just described. It’s the you know, $29.99 web camera that you picked up from Best Buy that probably has a PHP server running off of localhost 3000 using a PHP version that’s like 15, you know, releases old kind of thing. And you’re just letting that sit on the internet and also within your house.

18:47

Doug: Yeah, exactly. Right. And so, it’s all about risk and reward. That’s the whole point right? If you want to have the benefit of being able to walk in front door and and and tap your smart card and get straight in or use your phone to unlock it to let someone drop a parcel in the front. In the front porch, that’s great, but just be aware as well, right? You’ve got to balance a risk and reward around that sort of stuff. And like you say that the smart speakers brain idea, I love the whole concept. And my risk reward difference is a bit different from other folks. I’m a little bit on the, I’m not sure. At the moment, when I have my computing power to do it all locally, then I’ll probably be a lot happier.

19:24

Josh: Gotcha. So well, let’s talk about the risk itself. The core thing that we’re talking about here, especially from an enterprise perspective, is the data itself, which is like, you know, the goal of your business, and people have it, some people have a lot of it, what are some day to day procedures in tips that people can do to kind of make sure that that their data is going to be okay.

19:52

Doug: That’s a great thing. That’s a great question, Josh. Actually, one of the things that Salesforce introduced a couple of years back now is called the OG security health check. So Every admin can run this, if you go to the setup area and look up health check, it runs a little report that actually gives you a percentage on how good your security is inside your version of Salesforce. And it’s, it’s based upon what we consider to be the absolute minimum best practice. Now, obviously, some big enterprises say, hey, that’s a good idea, but I’m a little bit more strict than then then we want to be a little bit more strict in certain areas than Salesforce is they want to have like a 15, character, password versus AI, or whatever. And so because of that, they can actually upload their own baseline, and then they will compare their orgs against that baseline. So if they have many roles in the company, they can then compare them all against that. So the org, health check is a really, really easy thing to run. And it gives you a bit of an idea on what’s how your setup is because you may not realize that there’s a setting that’s been released that does X, Y, and Z and you’ve got to change it right. So that could be quite cool thing to look at.

20:54

Josh: Well, and specifically when it comes to passwords, what the concept of what is secure. It is It changes almost year to year it feels like

21:03

Doug: Yeah, exactly. I mean, personally, this house was actually just changed our policy recently. And I think that’s quite a quite a valid one. Because if you have a strong password, and you have a two factor authentication, that’s probably better than making somebody guess, a new eight character password every three weeks. Right? Because you got to forget the password. You gotta write a bit of sticky paper stick on the audio monitor. And that doesn’t help anybody.

21:29

Josh: So as many spy movies are proven…

21:32

Doug: Exactly. And I love it, the spy movies how these kids can walk up and just in two seconds cracking passwords, like really? I can’t remember password.

21:40

Josh: I can’t even crack my own password that Well, sometimes.

21:43

Doug: Exactly. I mean, when Apple does an upgrade, you’ve got to type the passcode from before it’s like, oh my gosh, what was that, you know? So, you know, that’s one thing where the whole password thing is something which I think if you make it longer, but make it a bit more complex, so Maybe people think about having a decent password but then have two factor and that means your password isn’t as important now because now you’ve got two factors to make it more secure. So if you have a password that’s maybe 15 characters long, but you could make it you could get something like, you know, your your, your your favorite Teacher’s pet dogs first name. Yes, I think that that’s probably bad because probably being dictionary somewhere, but it will make up a word, right? If you like, if you like, like, Kids TV shows, they’re always talking gobbledygook, right? It’s just like a makeup of a sound that you think you can spell and use that as your password.

22:37

Josh: Right? It’s interesting that we’re moving into I’ve read a couple of security blogs about this where we’re slowly getting into a point of technology, where passwords will almost be obsolete because we’ll have this level of trust in two factor authentication, and in biometrics, and so it won’t be what you could remember it is actually like who you are.

23:00

Doug: Yeah, exactly. So who you are, and a two factor authentication with that. So, you know, something, you know, is your thumbprint. And then something you have is your two factor authentication code that turns every 30 seconds. Right. And I think that makes a lot of sense because passwords, if you got rid of passwords, there goes all the credential sales on the dark web. Right? Right. Right. And it stops credential stuffing, it’s the stops everything. So the sooner we get rid of passwords, the better. And I think, on a side note to hear el Gamal who was one of the CO inventors of SSL when he worked at Netscape is actually one of our chief security officers in Salesforce. And, and he said, I’m terribly sorry, I’m sort of the one to blame for doing passwords.

23:42

Josh: Because and so, yeah, so I think that’s correct. Anyway, seemed like a good idea at the time, I’m sure.

23:49

Doug: It seemed like a good idea at the time. Exactly. It’s one of those things where everything’s a good idea and people realize, actually, this probably wasn’t a good idea, but you don’t know about it at the time. So it’s all good intentions, right. But yeah, other things Which which people should look at, especially developers, right? When you come to look at making sure you’re Aug safe, is, when you use point and click in Salesforce, we look after the security. So we make sure that you can’t type in stuff into Salesforce that will then crash it and get you access to, you know, secretive bits of Salesforce data from different different uses in your org, for example, right, right. We take care of that for you like we stopped the SQL injection type stuff. That’s what we do. But when you write code as a developer, we can’t actually stop you doing something silly, unfortunately. Right? Well, obviously you won’t do it, but but other folks may do. Right. So yeah. So obviously, everyone out here is a wonderful developer.

24:43

Josh: And I I will say, and I think this is this is where you’re heading to. I have learned a lot about security as a as a as a web developer and as an app developer from from doing the security checks and having to go through a security review.

24:57

Doug: Oh, heck yeah. So I mean looking at so my credit went really I didn’t catch that, oh my gosh. And so with, there’s a product out there in the market called check marks, which is industry renowned as being a very, very good static code analysis tool, right and Salesforce have partnered with them to actually give everybody out there, the ability to actually run a static code analysis over any code you’ve written inside your Salesforce org. And I think that’s mandatory, right? That’s a brilliant bit of kit. Because what it will let you do is it’ll catch those silly mistakes you may have done, or obviously you didn’t do them, your colleague did them. Right. Yeah. And, and what that will do is, is highlight some things which you need to look at more safely because it can’t tell if it’s actually if you’ve written code to actually protect against the thing that it thinks may happen, right? That makes sense, right? So it may give you a false positive. But the point is, what you should do is if you get one of these alerts from the scan, you should look at the code and go actually no written code around that to protect against that. Fred over there has verified that what I’ve done will work. So you put a comment in there saying this will trigger a false positive However, it’s been vetted by X, Y and Z. Right? And that way people can check when they go to put it into production that actually yes, it does file the security check. But it’s okay. Because it’s been verified.

26:16

Josh: Yeah. And it’s I think that’s, that’s one of the like, that’s a that’s a huge learning moment, because it does force you to take a step back and be like, Wait, did I did I bat down that hatch? Did I lock that door? In I remember having a conversation with the security team. Back when I was at model metrics or working on the partner portal, and he was reviewing my code after we had done a check marks and he’s and I was trying to like, explain, like, why, why I did what I did, because I was going to protect everything. And I think his exact words were something like, yeah, you had really good intentions. But like, let me explain to you why this is not, you know, nearly enough to to defend what you were doing and had something to do with me. Not Fully stripping out the right things to protect from SQL injection, things like that. So it’s, it’s, yeah, it’s a really great learning experience. And I agree even if I think a lot of people get into it, when either they’re, they’re going to go into a managed package or something like that, but it’s just, you know, it’s it’s a, it’s a great thing that makes you a better developer that everybody should be doing.

27:18

Doug: Okay, and you learn so much. I remember back in the day reading a lot of Doctor jobs journal for software developers, which is a pretty cool magazine, which is unfortunately shut down now. But they used to have a little article every, every month in the magazine saying, What’s wrong with a C code? And it used to have, you know, use that point of redirects go the wrong way into having a buffer overflow, that sort of stuff. Right, right. And, and this sort of stuff is is hard to catch. This is where these tools like checkmarks actually help out quite a lot. But obviously, it is static code analysis. So if you do dynamic sock, all that sort of stuff, or dynamic apex, that’s a little bit more tricky to catch. And you really got to have someone do a code review with you to actually verify what you’ve done is correct and they shouldn’t be sitting beside you. They used to go away sit in a room and look at it and thoroughly check it away from you so that you can’t influence them. Right, right.

28:09

Josh: Well, speaking of tools, what does event monitoring do and how does it help protect works?

28:14

Doug: Right event monitoring one of my little pet soapbox stories, okay? event monitoring is a fantastic product, which Salesforce released a little while ago. And what it does for you, it actually is part of the shield suite of products, which you may have heard on before, which includes the field audit trail and platform encryption. And event monitoring will actually materially increase the security of your Salesforce org. And the reason I can say that is because what event monitoring does is two things one, it lets you look at all the things happening inside your Salesforce org so it can see exactly who’s seen which record, not who’s edited it, but who has actually seen which record and who has run which report And who’s gone to which page. So it’s a fantastic analysis tool to help you understand a for security, but also be for adoption. So it lets you see who’s run which bit of code and how fast it ran. So you could Oh, hang on a sec, this bit of code isn’t working as fast as it did before what’s going on here, maybe I need to do some modifications to it, because my data is different than I expected it to be or whatever. So it’s great for adoption. It’s a wonderful tool for that. But the thing I’m more focused about is the compliance part of it, the security compliance part. And that’s where you can see who’s seen which records we’ve got some customers in Australia who have got some very holding information on on on kids inside their version of Salesforce to government departments. And obviously, that’s extremely secure data needs to be protected from everybody. So event monitoring will actually help with people who have access to the data to do the job. Because the field level security lets them do that in their profile. Let’s undo that and assure him to listen see it because you’ve got to be able to see it do the job like a call center operative. Right? type an operative of a major motor motor vehicle manufacturer, you’re gonna have politicians, sports stars, you know, celebrities as your customers, right? So you’re storing the information in your version of Salesforce. But if you have a service rep on the the call center site doing gratuitous searches for, you know, Angelina Jolie or whatever, right? That’s, yeah, yeah, sure enough, she may call in but the point is, if you do a search for Angela, then Brad, then Arnold Schwarzenegger, then it? Probably not, they’re not calling in. Right. So, you know, you’re probably doing things you shouldn’t be doing with the data. Yeah. So um, so this is where the whole who’s seen which records really cool. And that’s, that’s one part of it monitoring. Now the logs we have, you need to do something with them. And we have a nice Salesforce provides the Iceland analytics dashboard to help you look at 15 different reports around that sort of data, which is fantastic. Some of our partners out there, take our data and do a lot more with it. So If you’re looking at event monitoring, maybe you should look at one of our partners on the app exchange to enhance what you can do with this log file. But the other key part, which is, which is something that nobody else can do is part of monitoring is called transaction security. And this is this is, in my personal view, the creme de la creme feature of event monitoring, because what it will help you do is put policies in place to stop people doing stuff they shouldn’t do with data they’re allowed to see. So here’s an example. You want to be able to let people run a report and export some data down to excel so they can mess about with it because no one wants to mess about with Excel, right? And that’s great. But if they export, say, 250 contact records, that’s fine. But if they start exporting 5000, probably not right. So what you want to do is let them have access to all that data, but not actually export the data out of Salesforce. They can run the report, see it on the screen and do you know data All the good stuff. But you don’t be able to actually say hit X, Excel export. Now you can do a large hammer approach and turn off exporting for everybody. But that sort of stopped sales forces utility, right? You want to give people stuff to do their job, but you want to stop them doing things that shouldn’t do. So which production security you can put in policies in place that’s very, very granular, because you can do it either in code or with point and click now. But in code, you can go really deep and say, what’s the profile of this user? What’s the role of this user? And, or even What’s his user’s name? And you can go down to the user level and say, okay, so Josh can actually export 250 contact records, but Doug can export 25. And when it hits 26, it’ll actually either block me or report me to somebody and that sort of stuff. With some code. You can even build approval processes around it so that if I know I need to export 2000 Records, I can put a request in someone can approve it, and then I can actually run it once and I should be export.

32:56

Josh: Nice. All right. Well, that’s some Pretty cool stuff. Is there any other final pieces of advice or tips that you really think people should know?

33:08

Doug: Not specifically about security. But one thing about your data, right? You should make sure you do your own backups. Salesforce provides weekly exports, that sort of stuff, which is a wonderful thing. And we do a lot of backups, obviously, as part of providing a service to our customers. We do backups all the time, you know, we keep them for 90 days and do all the good stuff with that. And if something goes wrong, we can restore from backup, which had to do a couple times in the past. And that’s what backups are for. Right? Right. The thing is, though, if you mess up accidentally, that’s how you do an admin and you and you think you’re in a full copy sandbox, and you delete all the data. Oops.

33:45

Right.

33:45

So you know, that’s one thing you can’t necessarily get back. And so you need to have a backup somewhere. So Salesforce gives you a weekly export for free and you can use a Data Loader, either manually to do it, or you could use one of our partners to actually do an export to local database or Other things like storing in the cloud or whatever, but you really should look at your data because it is your crown jewels, folks. So I have talked about keeping it safe, but how about you keep it safe as well by doing backups and keeping them somewhere secure.

34:12

And that’s our show. I want to thank Doug for the great conversation and the advice on security. Now, in lieu of highlighting any of Doug’s non technical hobbies, I really want to feature one of his technical ones. See, Doug was a fixture at the IoT zones. I the IoT cabins, the bear labs IoT Grove so at dreamforce and TX, his little opportunity fulfilling robot arm Sparky was a fit basically our unofficial mascot. And I want to thank Doug personally because I witnessed people who hadn’t had the chance to really experience IoT get there that interest, no pun intended, sparked. So thank you, Doug, for all of the excitement that you gave people when it came to interesting and new technology. And thank you for listening. If you want to learn more about this podcast head on over developer sales. force.com slash podcasts where you can hear old episodes, see show notes, and also have links to your favorite podcast services. Thanks again and I’ll talk to you next week.

Get notified of new episodes with the new Salesforce Developers Slack app.