SystemDotDebug is a podcast for Salesforce Developers. Waqas Nazir and Shannon Smith of DigitSec join host Meighan Brodsky (@MeighanSF) and Nate Pepper (@SForceBeWithYou) to “Secure Your Shiz” which focuses on Salesforce security. Below we’ve captured key points from the interview. Watch the full video above or read the transcript below!
Meighan and Nate jump right into it with some great questions, including ones about common misconceptions and errors. One common misconception in the Salesforce community is that adding custom code or making configuration changes to an Org does not impact the Salesforce security posture. The truth is the contrary because it absolutely does! Salesforce developers and Administrators need to always set up guardrails for their code.
A common error that we see in our testing is an Authorization Bypass error where developers don’t set up proper permissions to constrain their Apex controllers. Another common error is trying to bring content into your Org from an outside source and having overly permissive wild-carding on domains.
There are so many ways vulnerabilities are created and they don’t always come from code! Administrators can also create issues. We often see overly permissive sharing rules as a top culprit. When coupled with Guest Access, it can be problematic. Creating rules to gain access to content and bypass good security practices is a recipe for disaster.
You have to be thinking about security before, during and after development. Doing so means that you have already taken care of problems before they become problems. If you only think about the security of your Salesforce Org once your application has gone into production, vulnerabilities are much harder (and more costly) to fix. Your entire CI/CD pipeline, whether it’s dev, test, or sandbox, should be as secure as production. Because Salesforce is a SaaS platform, all of those environments are available via the internet and vulnerable to breaches. You can often find a dev version of Salesforce that’s exposed by simply appending “dash dash dev” to a Salesforce instance domain.
One of the final topics discussed is passwords. It’s often true that people don’t apply the same password rigor to test accounts as they do to regular accounts. Unfortunately, that can be a security vulnerability as well. Password complexity and security are so fundamental yet so many still miss the mark! It’s ironic that such a simple, basic discipline is not practiced more, but many of the panelists agree this continues to be a problem.
Salesforce security needs to be a priority for anyone that uses the platform. One thing DigitSec is focused on is empowering everyone to think about security. In an industry that often has a 500:1 developer-to-security professional ratio, it’s critical that there are tools available in the marketplace like DigitSec’s S4 that help organizations secure their shiz.
Read the full transcript below!
Meighan:
All right. And welcome to System dot Debug, we’re your host @MeighanSF
Nathan:
And @SForceBeWithYou.
Meighan:
We have a special guest today. So, so special. Tell us more Nathan. What are we going to be talking about?
Nathan:
We’re going to be talking about how to secure your shizzle because security is one of the foundations of the trust. That is part of the Salesforce platform. Trust is one of the most important things. I mean, in the past 10 years, I can’t even count how many times big companies have gotten breached. Without security, you might as well just be passing notes in class, so it can be intercepted anywhere. We are going to dig into the nuts and bolts of Salesforce Security.
Meighan:
For real. We have Shannon Smith and Waqas Nazir here from DigitSec to talk with us. What up dudes?
Waqas Nazir:
Hey.
Shannon Smith:
Thanks for having us.
Meighan:
Of course. Welcome. Welcome. First off, Why don’t you tell us who you are? Shannon, let’s start with you. Who are you Shannon? Do you like long walks on the beach?
Shannon Smith:
I do. I just came from the beach and I took long walks every day. Actually, not nearly long enough because I was so hung over, but did take walks on the beach every day. It was very nice. I like security among other things. I always liked security because it kind of pushes the boundaries of what you can do with the computer. That’s fun and exciting because you never know what’s going to happen unless you work with people like Waqas. They always come back with God level access to your stuff every single time. So it’s not as exciting, but it is exciting at the same time.
Shannon Smith:
Yeah. I’m a computer guy. I started back when your friend Paul started way, way back in the day. Hacking code as a little kid and run a bulletin board systems and build an e-commerce and content management systems in the following decade. And then around 2000, I started participating in the cybersecurity industry professionally.
Shannon Smith:
I started doing Salesforce stuff, I guess, 15, 16 years ago, and fascinated by the crazy, amazing community and ecosystem that it is Salesforce and still have a lot to learn, but it’s been exciting and bringing in some of my tech and security knowledge into this ecosystem and interfacing with people and really enjoyed it.
Meighan:
Good.
Shannon Smith:
Lots of learning on both sides.
Meighan:
Nice. What about you Waqas? Tell us about you.
Waqas Nazir:
Similar background…I’m an “interested in tech” person. I came out of college and my first real job was working for a company that produced the most amount of software on the planet. I was part of a team of very skilled hackers who were basically tasked to break software before it was pushed to the world to use.
Waqas Nazir:
I got exposed early on into the world of breaking stuff and ever since then sort of been very attracted to this field. I’m a software guy from background, but as I was working in the software area, I found that the people building the software and the people breaking the software are pretty much same technically. From a technical standpoint. But they look at things from a different lens and that’s where the difference exists. Right?
Waqas Nazir:
So a security guy looks at a piece of software from the lens of like, “How can I break it?” And then the developer looks at like, “How can I build something which works?” Right?
Waqas Nazir:
It’s just a change in the way of looking at the same piece of software. That was pretty fascinating for me. That’s what kept me interested in the field. When I saw Salesforce sort of expand and come up with apex and lightning web components, all these fun stuff, I was really intrigued by it and found that to be quite interesting. That’s what led me to do more security stuff for Salesforce.
Meighan:
So Waqas, I mean, probably one of the first things that comes to mind for me with, as you’ve been working in Salesforce security and with all of the different things that you’ve seen across all these different environments for all these different people, what’s sort of the most common critical items you see in orgs today that’s out there?
Waqas Nazir:
That’s a really good question. The main things that we see quite often is that this understanding that when you start customizing Salesforce by writing your own code, or by changing different configuration, enabling different features, there’s no real impact to the security of the system. Right?
Waqas Nazir:
One of the things that many people don’t realize is that the code that gets deployed, for example, Apex controllers, they get deployed in Salesforce, run with system context, right? So whatever that controller is designed to do will run with no guard rails around it, right? Unless you take things into account that, “Hey, if this controller is being called by a certain user or a certain profile, and if you’re accessing a certain logic, if you don’t validate whether this user should be calling this controller or accessing this object, the controller will happily give you a data because it has access to everything”.
Waqas Nazir:
So one of the most common things that we find is which is called authorization bypass. You design your system, you design your permission sets, you design your profiles, but then you release this controller that kind of breaks everything like the whole security model.
Waqas Nazir:
That’s one of the most common things that we see with customized Salesforce environments is that the controllers are not enforcing proper permissions and validating the user calling them has the ability to do so. That has potentially led to breaches and things like that.
Shannon Smith:
Speaking of escalation privilege… I forgot to mention this is not my father. Before we dive into the tech too deep, I just want to throw this out there. You guys are the hosts. So you tell me when it’s a good time, but we have a demo today of a hack, right? And it’s a short one. It’s basically from a contact us page to admin of your Salesforce in less than five minutes.
Shannon Smith:
At some point, if you guys want to see that I can pull that up and Waqas can take you through it. It’s basically just leveraging only two vulnerabilities. One of which Waqas was just mentioning, which is authorization bypass. And the second one is escalation of privilege.
Shannon Smith:
Oh, sorry. The first one is an injection error. The second one is an escalation of privilege. Right? You basically injection error to get through the contact us form and then low-level user access at that point, but then an escalation of privilege or authorization bypass bug, and shazam!
Meighan:
We’ll definitely get there. We’ll definitely get there.
Shannon Smith:
I’m just letting you know that’s an option. Whenever you guys want to go.
Meighan:
Yeah. Yeah. Waqas, I think you did a great job of pointing out the fact that there’s so much that it’s out there and so many different possibilities, especially when looking at custom code, but there are also a lot of risks declaratively. They can happen with security and they can really put your org at high risk and that people may not realize. They may think, “Well, it’s Salesforce and they gave me this option. So it must be safe”. What are some of those items that you see out there, or some of those items to be aware of that people should be watching out for their org?
Waqas Nazir:
That’s a very good question. I think there’s a lot of things that Salesforce enables you to do, which opens up access, but that also opens up attack surface, right?
Waqas Nazir:
For example, the most, I would say critical thing that you could do is enable sharing rules, which basically share our complete types of data across the board. You can create a profile based sharing rules. So we’ve seen, for example, guest profiles, given a sharing rule, which basically is an invalid sharing rule, but it gives you complete access.
Waqas Nazir:
For example, it’ll say, share this objective ID is equal to ABCD, or something, right? Which never happens. Right? Anybody who has access from that profile perspective can call that data.
Waqas Nazir:
We’ve seen people enable a certain permission sets with basically give them sort of carte blanche access to all records. Right? That’s one that we’ve seen has drastic repercussions, right? If you have, let’s say that sharing rule and you couple that with the fact that you have a force.com site or a community site, then basically anybody can come and say, “Hey, give me all the account objects or give me all the contracts and give me all the documents”.
Nathan:
I’ve seen guest user profiles where they share an object where name is not equal to null.
Waqas Nazir:
Yeah.
Nathan:
If you’ve got a object where, yes, you want to display something, like in a sidebar where you’ve got an amazon.com or you’ve got these categories of things that you’re searching for.
Nathan:
Yes. That makes sense but isn’t it safer to have at least an is active equals true or something-
Meighan:
Right. They have taken away MODIFY ALL and VIEW ALL from the guest profile as well as from community profiles now. So that’s no longer available. Salesforce is making strides there and definitely doing an enforcement of security, at least on the community side. So something to think of. Sorry.
Waqas Nazir:
I think that’s a good step in the right direction because modifying data is even worse than just being able to read data. To Nate’s point, creating those rules, which basically not make sense, but it gives you basically all access, is not something that you should do from a security perspective.
Waqas Nazir:
Even though EDIT and MODIFY ALL have been taken away, seeing people write rules that basically give you read access to everything. So still depending upon the type of object can still expose you to interesting attack vectors. Couple that with a lot of the other config issues like, “Are you managing sessions? How you’re managing credentials? How you’re managing your integrations? What type of integrations are you allowing right?
Waqas Nazir:
There’s many different ways. Remote sites is one thing, right? You’re code being able to call something, but then there’s content security policy, which is what type of content can be loaded within your instance?
Waqas Nazir:
All those things play into the overall security. We’ve seen unfortunately, like wild carding, Google.com or pick large properties being wild carded, which is basically anybody’s content can be loaded within my Salesforce instance. It could be pretty bad from that perspective as well.
Nathan:
Waqas. what was one of the first things that kind of caught your attention when you started using the Salesforce platform? As far as well, for instance, if I came from a sort of a Microsoft background and I went, “Oh my gosh, I don’t need to use LINQ to turn a database object into a logic operable object. That’s amazing”. What was one of those… Could be security could be not, that kind of caught your attention and went, “Wow, they’re doing this well”.
Waqas Nazir:
Yeah. I think the one thing that is really exciting about Salesforce as a platform is the coming together of the code, the environment, and all the associated components in one platform, which is quite unique.
Waqas Nazir:
Back in the day, when I was doing security, we would do whatever we call a code review or a pen test, and then we’ll ship that product and another team would deploy it. And then there will be sort of this disconnect between what we reviewed and what got deployed and things like that.
Waqas Nazir:
But with Salesforce, you’re able to actually look at it holistically, like the data layer, like you said, everything is driven by the data. The code is there, the configs are there and all the moving pieces associated with it.
Waqas Nazir:
That to me was pretty interesting from a technologist perspective, but when I looked at it from a security perspective, it was also more interesting because now the whole puzzle was there. Right? It just had to solve it in a way that it’s secure, but all the pieces were sort of contained within this box. Right.? To me, that was pretty interesting and exciting to tackle the security piece of it.
Nathan:
Yeah. I remember I came into Salesforce as basically an Excel VBA data guy. That unique ID at the end where you could put salesforce.com slash the unique ID, and it goes to the record that was like, “Oh my gosh, we’re cooking with gas now”. That was amazing.
Nathan:
That’s a small thing, but I mean, I would get the Excel connector and pull down a report of stuff. And then I could go, “All right, you got the ID and the name of the contact or account, or tutor student”, that was the first company I worked at as the tutoring company. I could just go, link column equals HTTPS, yada, yada slash, and then point to the ID and boom! You got a link. I was the hero for about a month for that. That was not very security specific, but that was pretty sweet.
Shannon Smith:
In the late nineties, I was building a… Oh, sorry, go ahead.
Meighan:
For me, it was the fact that I wasn’t working in green screen anymore. People didn’t have to use the F keys and tab. I was so excited. It was like, “Whoa, why isn’t the whole world made like this?” I totally changed my mind about what business software has to be. Yeah.
Shannon Smith:
Yeah. That’s what my thing was like. I built what we called ASP. We were an application service provider in the late nineties, built e-commerce system and content management system, ColdFusion and SQL server and all that.
Shannon Smith:
We made it easy for people to do certain things, right? Certain, whatever, list of products, sell a product, list of some basic content management stuff. The cool thing about Salesforce was it was like a paradigm leap beyond that because it allowed you to take business processes and just start creating them in the software. Right?
Shannon Smith:
That’s what struck me the first time I started. I was just using it mostly as this basic CRM for sales in the mid-2000’s. But looking at it from a systematic point of view, kind of like Waqas saying where you have everything. I mean, all the servers, the full SaaS stack, everything all the way to the top and the user.
Shannon Smith:
I mean, the stack was amazing. The ability to map process, business processes through that stack in a very short period of time was just unheard of. From a security point of view, I can see how that would be insanely interesting. Right? Because now you can hit multiple layers of the stack and it’s all part of the same thing, more or less.
Nathan:
Which is something you don’t want to do on a call with a client, because then they can see how fast everything happens. Right?
Nathan:
Yeah. But only when you’re showing it to them, because when you’re not showing it to them, it always takes a little longer, right?
Shannon Smith:
Right.
Nathan:
Oh yeah. Let’s tweak this and like, “Hey, wait, that took five to 10 minutes”.
Meighan:
Hey, we’re not supposed to live bill. Wait.
Nathan:
Sometimes we run into things. It’s only working because you’re looking at it.
Meighan:
It’s deciding out there really quick, jumping to that live build concept. Because Shannon, Waqas because if you’re not regular watchers of us, we do this sidetrack thing.
Meighan:
So building a community. Oh my gosh, one of my favorite things to do is just have a test page and drop a ton of components on there, move around the page and just show them what all the pages can do. You put them nice and neat and orderly on a page. Of course takes time and planning, but at least to demo a component, oh, it’s one of my favorite ways to do it.
Meighan:
Same thing with like, “This is CMS, this is native CMS. Oh my gosh, this is fun”. Plus you get to show it in the community and show all the white space. People love seeing what the white space looks like. Continue on to security. Nate take it away.
Nathan:
I guess what have been some of the things in the last, I don’t know, five year… Gosh, when did permission set groups come out? Five years-
Meighan:
Two years ago.
Nathan:
Two years ago. What have been some of the things in the last five years that have been, “Hey, It was already pretty good, but now it’s getting really good”. Like intricate level. Waqas, I guess. Something in the last five years-
Waqas Nazir:
Yeah. I think from a security perspective, definitely the granularity of permission sets, that was a big feature that enables granular control. Also, some key features, which are not existed in some other platforms.
Waqas Nazir:
For example, structured object search language. You can start to objects, right. From security perspective, that’s very interesting. The way you construct those search queries that could have a security impact on those things.
Waqas Nazir:
Over the years, there’ve been a lot of interesting features that have been added as part of the stack, which are quite interesting from a security perspective. Even with new releases like Salesforce flows, they have this feature of just clicking a small drop down saying, run a system that basically gives… It’s the same thing.
Meighan:
Yeah. What do you think about that? We’re like, “Run as system. Run as user”. But it depends on context. Like, “Which one are you going to pick, man?”
Nathan:
Inherited sharing, inherited from… Yeah.
Waqas Nazir:
Exactly. These small dropped and small clicky things that keep getting added. There’s a security implications of that. From our perspective is always interesting to see in every release as like, “What’s changing and that’s going to impact the overall security”.
Meighan:
Yeah. I don’t think people always realize what a large impact some of those have. Like that run a system. So use case that I used it for, was within a community to allow users to share a user record with the user that they are requesting… Their own user record when they are requesting access to another record within the community, because it was not account-based sharing that was needed, but they wanted it run by community users that run internally.
Meighan:
It’s totally separate from accounts. Totally separate from everything else. They have this random custom object running, sharing, managed by people from all sorts of different accounts. Well, we have to open up the sharing to make that possible, but we wanted to make it individual. So there’s a sub flow that opens up the sharing.
Meighan:
I was like, “I don’t know about the whole thing. [inaudible 00:21:29] is the whole thing then it’s just a little bit of the whole thing”. Yeah. Terrifying man. The more you think about it, the more it trips you up and it just terrifies you what some of these superpowers do. Great power comes great responsibility.
Shannon Smith:
I was going to say that! Great power comes great responsibility. I mean, that’s absolutely true.
Meighan:
Absolutely. I was like, going all “Uncle Ben”..every single Salesforce user, but like, “Watch your super powers. People watch your super powers and use them for good and not evil”. Yeah. Absolutely.
Waqas Nazir:
It reminds of the time when most of the processes on computers were run with system permissions because it was so easy to test. It will never fail. Right? There’ll be [crosstalk 00:22:19]
Meighan:
Wait. We don’t just test as SysAdmin? I thought we only test as SysAdmin?
Nathan:
Or right tests as Sysadmin?
Waqas Nazir:
Yeah, that’s like “classic”approach, right? Is when you’re giving that level of access. It’s like heaven for a SysAdmin because every scenario would work. Every use case would work. It’s excellent for the hacker too, because now they can basically get all the data. So when you say you’re scared, there’s a reason to be scared. It’s something not shouldn’t be given lightly.
Nathan:
Our last episode was about deployment, right? How to prepare for deployment plan, et cetera. One of the things that I’m sure Megan, you and I have all run into is, how do you give permissions? Do you use a profile? Do you use a permission set? Because if you do it via profiles, you might have to make the same changes to several profiles. [crosstalk 00:23:28] If you do it through permission sets though, you have to manage the user… What’s that called? User-
Meighan:
Permission.
Nathan:
…permission.
Meighan:
Is that assignment records?
Nathan:
What does Okta do? User configuration?
Shannon Smith:
Identity access management?
Nathan:
Identity access management… User provisioning. There we go, right? Every time a new person joined.
Meighan:
You got to have permission Nate, either way.
Nathan:
Either way. But if you have it all on the profile, it’s kind of a one and done, everybody’s got the same permissions through-
Meighan:
You don’t want it all on the profile.
Nathan:
Exactly. But it depends on if you’ve got something like that set up. Do you have something to automatically manage permission sets? Do you have an admin that totally does all that and that’s their job or no, it maybe [crosstalk 00:24:21].
Meighan:
It takes a spreadsheet, man. It takes a spreadsheet.
Nathan:
It takes a village.
Shannon Smith:
It takes a SuperCalc spreadsheet. No, I think Nate’s right though. I mean, you got to have your systems in place, if you’re winging every single user onboarding.
Meighan:
That’s why we have a spreadsheet.
Shannon Smith:
Yeah, no spreadsheets are great. I mean, better than no-sheet.
Meighan:
When I was an admin that’s what we had. We had a column for each role. This was back before permission set groups, of course, something like 12 years ago.
Nathan:
But if the sheet’s on a shared drive, you need to secure your sheet as well.
Meighan:
Dude I have my laptop, thank you.
Shannon Smith:
There’s a tongue twiters in here somewhere. Scare your sheets.
Meighan:
She stores her sheet on a shared drive or something like that. Yeah. Yeah. Yeah. Anyway, Waqas what’s your thoughts since you’re the security expert? Sorry now that I’ve bickered at Nathan enough for [crosstalk 00:25:26] for 20 years.
Waqas Nazir:
Yeah. I mean, I think we’re conversation is valid in the sense that the end goal is making sure that the right people have right access to the right resources and not the other way around. What we’ve seen with profiles is notorious. It’s easier to create overly permissive profiles and that people [inaudible 00:25:51] and permission sets tend to be more specific and granular. That’s why they’re perhaps harder to onboard. And then things like that.
Meighan:
Or people don’t change the profile when they change roles.
Waqas Nazir:
Exactly.
Meighan:
Because they think the person can see it. They’re good to go. They’re already logged in, but a permission set they would go in and switch it all up. Yeah.
Waqas Nazir:
Right.
Meighan:
I don’t know. Yeah.
Waqas Nazir:
Yeah. Yeah. I think . I think from a security perspective, what needs to happen is ensuring that your use case is completely covered. With permission sets, in my opinion, it’s much easier to do them with profiles, which tend to be happening. There’s the ideal and then there’s the practicality, right?
Meighan:
You’re right.
Waqas Nazir:
The practicality of it is that, it’s perhaps better to scale with permission sets and things like that.
Meighan:
What’s probably the number one way that people can… As they’re building, ensure they’re building, right? And building securely, I guess I should say. Yeah.
Waqas Nazir:
Well, we, as a company enable that, right? As developers are developing, they’re able to easily assess the security of their code, the configurations of the Salesforce environment, where they deploy the code as part of their build process. But then they use any CICD tool. I think having that-
Meighan:
That’s for the next question. Don’t talk about CICD yet. We’re going to [crosstalk 00:27:38].
Waqas Nazir:
I think from our perspective, developing without security in mind leads to security issues in production, right? And then if they’re found in production it’s hard to fix. Many times the people who develop this stuff have moved on and give us little to no sometimes business context around why it was done.
Waqas Nazir:
It becomes a nightmare really to fix the security bug in production. Ideally people should be building security from the ground up, as they’re thinking about features, as they’re thinking about use cases, they should be thinking about the security implications of those use cases, and then addressing all the threats, right? Putting themselves in the shoes of a hacker to like, “How would somebody break the system?” Right? And then there’ll be able to protect it better. So that’s some of the approaches they can do and of course we have a tool to do that.
Nathan:
And not just escaping SOQL and SOSL right? Let’s put our big people pants on and kind of think of the whole system.
Waqas Nazir:
Exactly. What’s interesting is even that is a pretty common bug that we see. It’s like SOQL Injection or SOSL Injection.
Nathan:
Most of the time, unless it’s getting caught in a security review, it can slip under the radar for years.
Meighan:
Really? Well, so we talked a bit about making sure your stuff and Salesforce is secure. How do you make sure your CICD process and your deployment process is secure because I feel like that’s kind of a gap for a lot of places. People don’t always think about it. Yeah.
Waqas Nazir:
Yeah. What’s interesting is, like you said, Salesforce deployments productions are very valuable, right? So even if people want to secure, that’s where they focus on, but stuff in their sandbox is pretty much identical. Right? And they’re making, sometimes changes in sandbox and not thinking about the security implications of the sandbox, as well as in dev environments, they’re playing with the similar data or sometimes similar data sets.
Waqas Nazir:
So our approach is that dev test sandbox production, all of them should be secure because it’s a SaaS platform, right? it’s available to the world. It’s not like the developer only has access to it on their local machine.
Waqas Nazir:
If you look at any major Salesforce, my domain… Let’s say, awesome.my.salesforce.com and then you add dash dash dev to it. You’ll hit the dev instance. And then there’s a lot of fun stuff to be had because it’s basically the same company’s dev instance, but it’s many times not focused on because they’re focused on the production. If they are at all.
Nathan:
That’s something huge, especially for communities. Meg Ms. Community. If you’re in a sandbox or scratch org, as soon as you publish that anybody can get to it. Don’t think that, if I make a Google sheet publicly available, I can run a script to go, drive.google.com dot let’s just churn through IDs and I’ll eventually get to you, right?
Meighan:
And making your user tests.com with the password of “password” or “Salesforce1” is not the way to go people. Stop using “Salesforce1” and stop using “password”, especially when you have communities. These things are so blatantly obvious. Everybody makes testuser@dev.org or myorg.dev. [crosstalk 00:31:31]
Shannon Smith:
No admins with the password “password”! You should not be able to do that.
Meighan:
Or “Salesforce1”. I’m shocked that Salesforce lets you make Salesforce your password. It just blows my mind, especially because it hits that minimum number of characters for everything. Yeah.
Nathan:
I mean, that’s like ’70s hacking come on.
Meighan:
Whenever I can’t figure out what’s a shared what is, that’s usually what I guess. You wouldn’t believe in the past how many warning I’ve gotten into for shared logins with that. Not even certainly like lastpass or the password1 or the whatchamacallit pass. Google Sheet with all the passwords, wherever people keep passwords.
Shannon Smith:
You could have the best application security CICD pipeline that anybody could ever dream of, and if all your admins have all their passwords as password, it’s not going to matter. You got to have focus on so many different areas to have a good chance of keeping your stuff locked, your shizzle locked down. What does it? Secure your shizzle?
Meighan:
Secure your Shiz.
Shannon Smith:
Sorry.
Nathan:
Secure your sheet.
Waqas Nazir:
I don’t know if this is still the case, but Salesforce back in the day used to allow two character passwords and we used to get a check a lot-
Meighan:
Right. That was so long ago.
Waqas Nazir:
It was always fun to find that out. The reason they have it is because somebody still has it. So that it doesn’t break their system. It’s interesting but that was the case.
Meighan:
Stopping the integration user system admin too. That one drives me nuts. Sorry.
Nathan:
Clone the profile please. Please clone the profile, it only needs access to certain things. Why don’t you tell us… before we wrap, tell us more about DigitSec. What do you guys do? Give us a little spiel on what are some of your ways to help people navigate the very capable, but not often utilized security functionality on the Salesforce platform and beyond.
Waqas Nazir:
That’s a great question. I like to pass it off to Shannon, but I mean, from our perspective, we’re very interested in helping the community overall to enable trust, right? From the get-go as people are developing and changing because the Salesforce and our value proposition is really giving the customers the ease of mind that as they’re making these changes, they’re doing it in a secure manner and they can ship with confidence that whatever we’re putting out in production, we’ve tested and it’s been reviewed and won’t possess security vulnerabilities and things like that. With that, I’ll ask Shannon to chime in-
Shannon Smith:
I’ll just add to that. I think, the number one thing we’re trying to do is, there’s this whole ratio of 500:1. There’s one security person for every 500 developers. I think you could say developers and admins, right? So you have one security person that’s going to try to keep up with 500 people making little mistakes here and there. It’s never going to work. Right?
Shannon Smith:
What we’re all about doing is kind of making everybody security people, right? So that everybody can run scans and make it easy, make it fun, gamify it. Really empower the developers to find their own bugs, understand why they’re bugs, easily be able to fix them and then move beyond that. The more they do that, the more they learn about what not to do. Right? And so the less likely they are to do it.
Shannon Smith:
So you end up with this nice positive feedback cycle at the end of the day. This look has this look of the Milky way or whatever, right? The whole idea is, we want to help developers help themselves. We want to help admins help themselves learn about these things when they get released into production or while they’re in development. Get them fixed as soon as possible. But then over time, it’s less and less likely that anything is ever going to hit production, right.? Because you’re going to catch it in sandbox or staging or testing. So we would just want to continue to push left so that these things are taken out way before they could ever be dangerous.
Nathan:
Fail early and fail often. All right.
Meighan:
Heck Yes!.
Shannon Smith:
I’d definitely say that’s probably the best summary of what we’re trying to do. Specifically for Salesforce. We’re taking 20 years of security app, application security knowledge and trying to laser focus it and purpose-built it for the Salesforce community.
Meighan:
That’s fantastic. All right. Well I know we’ve gone a few minutes over, but I think this was great. We had a great time having you guys on here.
Meighan:
A couple of announcements that I just want to make is also this Saturday 4:17 roads to CTA Salesforce. Saturday, we are going to have costs going through best practices, ways to keep your org secure, as well as going through security Q&A. Bring your toughest questions you can register for that on Eventbrite.
Meighan:
Also there is the Zachary Banks Salesforce salary survey that is going on right now. Make sure you fill that out. Great opportunity to get enrolled with community. Give us some feedback and find out if you are getting paid what you’re worth. And then Nathan, what about you for any announcements?
Meighan:
You’re on mute.
Nathan:
Sorry. I was doing command function A, instead of command shift A. Deploy, deploy, deploy. I’m kind of brain dead right now. I’ve got nothing this week. I’m sure there’s stuff out there, but as soon as we get this shipped, I’m sure I will check the user groups.
Nathan:
I mean the nice thing is because everything is still pretty much a hundred percent virtual. It’s almost a saturation overload as far as things that you can attend. So please check out trailblazercommunitygroups.com. Check out… Was it trailblazer.salesforce.com? There’s so many events going on.
Meighan:
And the community is now in Trailhead Go too on your phones and devices. So check that out. Way fun.
Nathan:
And Trailhead goes available for iOS and Android.
Meighan:
I have it now on Android. Thank you all for coming by. This is awesome. Thank you so much. We’ll talk to you guys-
