The conversation unfolds with an exploration of the intricate balance between security and functionality within the Salesforce ecosystem. Chris Peifer, a seasoned consultant, shares his insights into the critical nature of security in DevOps practices, emphasizing that the foundation of any secure system must begin with a comprehensive understanding of risk profiles and threat assessments. As organizations vary in their sensitivity to data breaches, the discussion delves into the necessity of customizing security measures that align with both the operational realities and budget constraints of diverse organizations. Chris articulates the importance of fundamental security practices, such as ensuring that object-level and field-level security settings are meticulously enforced to prevent catastrophic data exposure incidents. He highlights the frequent oversight in misconfiguring Salesforce settings, which can lead to significant vulnerabilities, particularly when organizations overlook the implications of granting excessive access to guest users in their systems. The dialogue further addresses the evolving role of security teams within organizations, as they increasingly engage in the configuration and deployment processes, reinforcing the narrative that security must not be an afterthought but rather a collaborative endeavor integrated from the outset of any project.

Takeaways:

• The podcast emphasizes the importance of understanding the unique security challenges present in Salesforce architecture and configurations.
• I discussed my extensive experience in the Salesforce ecosystem, which spans over 16 years and involves various organizations.
• A fundamental approach to DevSecOps involves balancing ease of use with stringent security controls to protect sensitive data.
• Security teams are increasingly engaging with Salesforce implementations to ensure compliance and address potential vulnerabilities effectively.
• The necessity of thorough risk assessments and threat evaluations is paramount when tailoring security solutions for diverse organizations.
• Implementing proactive security measures, such as regular audits and automated checks, can significantly mitigate risks associated with misconfigurations.

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 Salesforce ecosystem. I'm Justin Hazard, Deputy CISO at Autorabbit. My guest today is Chris Peifer of Attain Partners. Welcome, Chris. Thanks, Justin.

Glad to be here.

Before we get started, let's learn a little bit more about our guests. Chris, can you share something that's interesting about yourself that we Couldn't find on LinkedIn?

You couldn't find on LinkedIn?

When I was between middle school and high school, I built a canoe with my father and I really appreciate woodworking as a counterpoint to all of the crazy that is day to day consulting life.

Did you. Okay, I have a quick question.

Did you, did you do the old Native American style where you took a trunk down and burned it out or did you do like paneled?

It was actually cedar strips. So it's as these like, like one and a half inch strips of cedar.

And then you, you put it up on a frame, you carve it smooth, cover it with fiberglass and epoxy resin. Um, it's, it's like an 18 foot canoe.

Still use it today hanging in my garage and, and was far more useful than anything I was going to do at the end of middle school. So I'm very glad to have it.

That's a fair point. That's, that is, that's probably the most interesting fact that I've learned thus far. So kudos to you. That's, that's pretty awesome.

I'm excited to talk to you. We got a chance to talk last week and get to know each other a little bit.

But I think your breadth of experience and depth of experience over the last 16ish years in Salesforce is going to be a really interesting conversation. So without much further ado, let's jump right into it. So, as a consultant, you get to see a wide array of different environments.

You get to see the big, the small, the in between nonprofit. And you also get to see different budget sizes, constraints because of regulations and modes of operating.

Because we all know that every organization operates in a different realm.

One of the things that I'm wondering, as you build out these solutions and tailor it specifically for your customers, how do you go about working security teams and security into those solutions and advising your customers in ensuring that they're doing the right things? Sure.

So this type of thing, it's gotta always Start with fundamentals.

It's gotta start with risk profile, with threat assessment, with like, who is this organization, what's the sensitivity of the data that they're working with, who wants to get in and how motivated are they. So you know, you always have to be striking a balance between.

Ease of.

Use between and an appropriate set of regulatory or appropriate set of controls that are going to ensure that the system isn't easily compromised. So you know that Salesforce is weird and great when it comes from an AppSec point of view.

You've got a really solid foundation, far more solid than most organizations start with. But then there are these holes that sit out there that are often the source of problems.

So really a key role as a consultant for me is, is figuring out what's the right set of controls to apply for each of the common, common weaknesses or common challenges that you have when you implement Salesforce.

So you know, some of that is going to be real basic stuff like you need to make sure you have a mechanism and a process that's necessary, you know, to ensure field level, object level security is properly being enforced. It's so easy to miss a checkbox. And in some cases that can have catastrophic security implications.

Especially if you're like you're configuring the guest user, you accidentally check that read all and suddenly you've exposed your entire account data set to the world. And what's interesting is that, you know, I often play a role of student doing a security review of proposed configuration.

It can be so easy to just sort of, you know, what is it? The path to hell is paved with good intentions.

And so you're thinking, okay, well we've got this, we need to have this widget that allows you to search for a subset of accounts and make sure that the guest user can do that. And so then you're like, oh, we're having an access control problem. Great, great, let's just grant access to all of them.

And then you, you never work backwards to find out where that problem.

Oh, it works, it works. So you know, and, and this is also where like that, in my mind, that's an unacceptable configuration no matter what.

There are a bunch of different strategies or alternatives we can take that would, would bypass that particular configuration problem. Um, but again, like, you know, it, it should be really, really built around what's the risk profile of the organization and who wants to get in.

So if you're talking about a small nonprofit that isn't on the radar of a lot of, a lot of folks, you're really, you know, meat and potato stuff. Make sure that you've got, you know, good, good solid passwords. Make sure that you've got.

In fact, I think simplicity is critical in your implementation. Making sure that the client actually understands what they have in a way that they're not going to accidentally check their own checkbox.

And then that scales of course.

So when you get to we at attain partners, we tend to work with enterprise scale in the nonprofit higher ed sector, I believe, universities, organizations that actually do have a pretty big target on their back. And so, you know, in that setting you actually have to have some proactive activities.

You know, just a simple Python script that runs through all the Salesforce IDs that are, are typically, you know, the, the Salesforce ID namespace I guess would be the way that I would describe it that that hits the Org and checks to see is there any object that's publicly exposed. You can have that run nightly and suddenly you've got an alert saying, oh, hey, somebody's done something wrong. So I mean, I don't know.

That's sort of some of the common things that we do. And it is really critical that you don't go too far with smaller organizations and you go far enough with larger organizations.

I mean, that makes sense. I've worked in both very small shops and very large shops. So every small shop wants to do what the large shop's doing.

They're just not ready for it yet because there is, there is a level of agility that you still need when you're still small. So I completely understand that. I completely get it. I felt that at my core way too many times. Are you seeing? Are you seeing?

And what do we have there? Are you starting to see that or has it been like a ramp up or has it always been there for you before?

So it's interesting we are seeing more engagement from security teams. Um, in particular, you know, it used to be.

And, and it's, it's often that like we as the consulting partner are like, hey, we want to be engaged with you.

We want to, we want to be working with your security team because the security team is ultimately responsible for compliance after we, after we hand off the solution. So they've got to be in the weeds.

And, and you know, it is really easy when you know, in a pre sales process we get a checklist of, you know, does your solution do the following and you can just say yes, Salesforce does all these things. You know, okay, we're deploying shield. It's got encryption at rest.

We're you know, all and, and not have a critical conversation of, well, it does these things but we can misconfigure it or you can misconfigure it so that data is vulnerable, you know. Oh, you've bought Shield. Great. Have you enabled field level encryption on anything?

The number of orgs that we've seen coming in after another partner, another vendor or the client implemented and they bought shield, it checked an encryption checkbox and nobody ever actually went in and encrypted the data on individual fields. It's unfortunate and it's sad.

Now of all of the risk profile, the likelihood of Salesforce infrastructure breach is far lower than say misconfiguration or you know, an add on app that's a problem or all those other things.

But still, like you bought the product, you're not really able to check the checkbox of compliance unless you've done the configuration steps that are necessary.

Yeah, yeah. I mean that's the biggest, I would say, I want to say misnomer.

Mm.

But misnomer. Right.

Yeah.

And you know, I've talked to a few of our customers and I've specifically said, I was like, think about it like a Coke bottle. The infrastructure for Salesforce is the bottle itself and they filled up the liquid and everything else like that.

It's not getting, you're not getting into that pretty in any easy way. Like nation states can try and script, kitties can try. It's going to be difficult. Like they've got a pretty good security operation over there.

But there is that hole at the top. That hole at the top is yours and it's all of your configurations.

You can tighten it and flip it over and see if any liquid drops out and you can tighten it a little bit more and in a little bit more there is this.

And it's always been the case with security or at least from the Security perspective is you've got business operations and you've got security and you don't hinder business operations. So what do you do? You try and figure out what that happy medium is between the two. I mean, that's the world that I live in. Yeah. Yeah.

My chief product officer is like, like, hey, I want to do this one thing. And I'm like, do you know what kind of risk that exposes? All right, we'll.

We'll do that thing, but we're going to do X, Y and Z before we do that particular thing. So understanding and, and I think a lot of the. I don't want to say confusion, because confusion is not the right word.

A lot of the misunderstanding from security teams is that's where it's at. And, and one of our.

One of our VPs of product, he and I were talking a while back, shortly after I got here, I was like, I need you to understand something. Salesforce is not new. And the problems that Salesforce has for their. Their customers have. I don't wanna say Salesforce. Let me, Let me correct.

Yeah, yeah, it's really. But the problems that sales.

The problem that Salesforce customers have, they're identical to the exact same problems that we have had in the security industry for. For other things. Permission sets are a prime example.

I keep using Active directory and all of the things that we went through with groups and permissions and inheritance and all of those things. We're seeing the exact same problem set with Salesforce today.

And you were talking about the opening all or read all for Guest and everything else like that, I think S three buckets. Yeah, right.

Yeah.

Like making them publicly accessible. Right. Like we, we've seen this.

That's all it is.

Exactly. So I'm sitting here in a situation where I continuously tell our VP of product, like, hey, what's old is new.

Again for security teams, if you can analogize this and you can liken it to something that they've already seen, which at this point in time of the security industry, which is now about 35 years old. Yeah, we've seen a lot. We've seen quite a few of the things.

So pulling those threads and pulling those things in and saying, hey, it's very similar to this. Here's where the differences are. That's where I find, like when I'm training up security teams, that's where I find the most benefit.

And it's literally just a translation layer. Right? Like, that's all it really is.

Because Salesforce just like AWS just Like Azure, just like gp, Google Cloud or gcp, they all, they all have their own vernacular for the exact same thing. Exactly.

And so like, you know, the security team comes in and they're like, they're asking a question that would be correct for Active directory. And really like the Salesforce folks would be like, oh, well, we don't, you know, we don't use that language.

So no, that's not a problem when in fact it is a problem. It's just with different language and the security team doesn't know to ask.

And so you know, if you're part of a security team that's reviewing Salesforce and the vendor that you're talking to says, oh, we're good, we don't do those things. That's a red flag. That's a big red flag.

Because when we do all of those things, you know, I mean even like yes, Salesforce, Salesforce does have some nice unique out of the box protections for OWASP top 10 vulnerabilities.

So like yes, you're, you know, there's, there's good, you know, some good stuff around SQL injection things but you know, there are, it's even still possible like if you write bad code, if you misconfigure an app, it's just different language and, and a different way to, to think about the exact same problem.

And you know, I mean the other thing that comes to mind that I, that I wanted to bring up, you know, I, I'm somebody who, I'm a huge fan of the Phoenix project as a book. If y' all haven't read that, it's old now. I mean we're talking about a decade old technology book that maybe is going out of fashion these days.

But like, I mean that book resonated with me viscerally and there's one of the characters that is the change. The most in that book is the security guy.

And because he has transitioned from like I have a massive checklist and I need to check all the checkboxes to I have a view and a role in business value and my root view.

You know, there's an enormous contribution to overall business value that we didn't just share our entire customer account list with the world and you know what, like that checkbox around some obscure thing maybe, maybe less important. So it's all about being able to focus on, understand what is the business impact and making sure that's well understood.

You know, risk frameworks are really valuable here as well. But anybody who hasn't read that book, who sort of like, I really strongly recommend folks read it, even if it's older.

I think it's even more valuable today looking at vibe coding and AI and all these other factors in the picture.

No, absolutely. And like, the first of all, let me step back because there's a little funny anecdote that I have because it literally happened to me yesterday.

That character, the security character in the project. One of the things that's really interesting to me is, and I'll use the analogy of yesterday, we were going through.

I'm going to call her out, our senior director of Project management, Kylie. She's one of my favorite people at Auto Rabbit. Love her to death, but she got a little upset with me yesterday.

We were having a conversation with a group of us and the question came to me of hey, what's the security implication of this? And I was like, it depends. And she was like, what do you mean?

Very consultant answer. But yes,.

That's all I really am on a day. Like if you cut through all of the things that are happening on a day in and day out basis, I consult more than I do anything, right?

Like I advise on strategy and then I implement said strategy. But the, the fact of the matter is, is like I, I need the context, right? So we were, we were talking about.

Yeah, we were talking about Salesforce instances. And they were like, well, we're seeing that this thing has, this instance has 703 regulated fields. And I was like, okay.

And they're like, does that worry you? And I was like, yeah, I mean it worries me, but I need the context behind it. Are all of those fields populated?

What's the data that's sitting in those fields? Who has access to it? All of those things.

Proper audit controls and. Yeah, yeah.

And my concern level goes down a significant margin now if you tell me we have 703 regulated fields, they're fully populated, related with credit card numbers, Social Security numbers, phi, any of those types of things and it's publicly exposed. Yeah, my concern level jacks, right? Like I might be in the world of a heart attack range at that point in time.

Like, it puts me in a situation where like I have a significant, like, what are we doing? We need to shut this thing down immediately and reevaluate all of the things that we're doing at the exact same time. So.

And the thing that I've learned over 16 years in the security industry is, it depends. Is the most relevant answer in almost every given situation and people hate it. But then I, because it depends what's the context.

And here's the things that I'm thinking about. Regulatory framework.

What are the legal implications if we do this? You know, do we have. Yeah. Do we have CVVs sitting on disk? Do we have like all, all these things matter enormously.

And, and I think that like, it's very easy to, to see, to see something as simple.

So I mean, we have a client, former client, actually not going to disclose a name here, but they were adamant that Social Security number was the unique identifier for people. Yes, yes, full Social Security number. And you know, and it's one of these really interesting moments where like.

We.

Can be as direct we can be. You know, we're, we're an outside vendor. We can provide this sort of quiet sidebar. Hey, this is a risk.

Then you, then you move on to the like public sidebar. Hey, we're in a, in a project planning meeting. This is a risk. Then we move into the escalation framework. We get into the executive sponsor.

Hey, this is a risk. And of course spelling out all of the implications if in fact this data is breached.

And then finally, you know, finally we get to the point where we, we basically ask for an executive level person at the organization to sign off on a piece of paper that says this is the risk. And we accept it and we agree that attained partners is not liable because we were fully improperly advised of the risk.

And that's one of the, one of the interesting differences around being outside versus being inside at an organization. Like, you know, occasionally we'll reach a point where we just say we're not willing to do this.

Like, you're going to have to find another vendor because the risk is just too high for even with that, that sign off. It's just this, you know, you just shouldn't be doing this. And you know, people are so set in their ways and you know, somebody's been.

And, and yeah, but somebody overseas can't touch that card catalog.

Exactly. Yeah.

Like within a matter of seconds, like there's a drastic, like, again, it depends. It depends. Like a company I used to work at, I came in, I was their security operations manager. And our DLP system kept on going crazy.

And I was like, what is going on? So I went and investigated. I Asked our analyst. I was like, why do we see so many alerts for this? And they're like, you're not going to believe this.

And I was like, okay, tell me. And I was like. They were like, our UUID is nine digits. And I was like, what do you mean?

And I were like, our UUIDs for all of our customers are nine digits.

So when we've got developer A sending a set of UUIDs for our customer base to developer B, while they're troubleshooting something and they're trying to fix something, it's picking up on the Social Security number, the op alert. And I was. I. I went to our head of development, our head of product, and I said, you're gonna hate me and I need you to do something for me. Yeah.

And he said. And he said, what's that? And I said, I either A, need you to encrypt every single Social Security number in transit, not bulked. And.

And I need it to be on a singular level for each. What's it called? Or whatever. And he was like, why? And I was like, because we're breaking and inspecting for DLP purposes and it won't be.

And inspect when you hit the tr. The encryption here versus here. And he was like, okay. Or what's her other option? I was like, you change your entire UUID system.

They changed their entire UUID system. They spent three months and changed their entire UUID system. And they were like, you know what?

When they stepped back and they looked at it, they were like, we should make sure it's a GUID that we're using for UUID. So they went to. I think it was like 24 characters with dashes and everything else like that. Exactly. They went.

He stopped all feature releases and had everybody work on the GUID solution and then revamped all of the code and went back. And I think it took us like three to six months to get everything done, but the CTO signed off on it. Everybody signed off on it.

And they were like, this is the smart thing to do. And I was like, oh, okay. And then I hear somebody's using Social Security numbers as the user identifier. That. That's a first. I'll be honest with you.

That's a first. And I think I would have some pretty significant problems with that. But no, that's a. That's a really interesting one.

But no, I'm Seeing security teams getting more and more involved, I've had a couple of buddies reach out to me that they, they work at organizations that have Salesforce. And when everything popped from Google over the summer last year, and every instance thereof, they're asking me, what are you doing?

How do you know about this? What do you think about this? How are you thinking about it? And then I'm like translating it for em. I'm like, hey, you know when your.

Your Salesforce dev is saying this? They're like, yeah. And I was like, it means this. And they were like, oh, really? That's easy. And I was like, that's what I'm saying. My.

My buddy and I were talking the other day and he goes, our Salesforce devs are telling us like, it's so difficult and everything else like that to work in Apex and da da da, da da. And I was like, it is like Apex is a really weird language. Like, I'm gonna be very honest with you. Yeah.

I was like, but you know what one of the most prevalent things is that we find. And he said, what's that? And I said, soco queries that, you know, you could do an injection on. And he goes, what's a Soko query?

And I was like, basically SQL.

SQL.

And he goes, yeah, so it's a SQL injection. I was like, yeah. I was like, this stuff will map into your appsec pipeline without much fanfare. And he was like, are you kidding me?

Like, we've been stressing over this for the last couple of months of like, how we're going to handle this. I was like, you're going to have to do a little work to understand language. You're going to have to do a little work to understand vernacular.

But if you can do the translation, like, you'll. You'll be 100% fine. I was like, permission sets are permissions and groups and inheritance and everything else like that from ad time frame.

And I was like, at the same time, like, you're looking at things like objects and fields. I was like, it's no, it's really no different than a database. Exactly, exactly. It was like, there's no difference here.

And he was like, oh man, this is so much easier than I thought it was going to be.

And I was like, listen, when I came to Auto Rabbit many, many moons ago, 16 months, I was like, I have no idea what Salesforce is, but as I started talking to people in product and some of our developers and our engineering team and our SRE team, and I got to Know, like what we're doing and how we're doing it. I was like, oh, this is just another day in security land for me. So, you know, there's one thing that.

I want to add to that, which is I think there is a unique. I mean it's not a, it's not unique as that.

Like denial of service exists elsewhere obviously in the world, but there is a unique set of challenges with the platform related to denial of service conditions because Salesforce is so aggressive on resource utilization limits.

And so one of the things that we see, and this is part of what makes my job fun, you know, the core platform doesn't scale in the same way as a lot of people expect.

So you start getting weird performance issues when you have 10,000 child records associated with a single parent or when you have a single user owning a huge percentage of the records in the system, like say a migration user. And one of the critical things so in that space, architecture matters an enormous amount.

And that's a place where I wouldn't expect a standard security team to be able to look at it and say, oh, well, you've got really a data model problem here. And if you have, say, I mean, you know, really good example. We did a project with The Boston Marathon. 30,000 Registration.

30, 36,000 Registrations coming in. A thousand people on the registration form. 100 Submissions per second. Yes. A lot of fun. So.

So one of the critical things there, and that's not a malicious scenario, but there are lots of malicious scenarios I could come up with where somebody's gone out and bought a random tool, you know, and that. That can spit submissions at a form.

Yeah.

And take the whole form down. And if Salesforce is behind the scenes and it is not architected. Right. It absolutely will just take the whole, whole system.

At least take your inbound down. So. So like that's one of the pieces where you. Where I think you have to be uniquely careful. And it's a place where scale matters.

You know, we're talking to a smaller nonprofit. Like it's fine. Like if you don't imagine the next 10 years, you're going to be enormous.

It's okay to have a, to have a model where maybe that there's, there's, you know, a less durable architecture.

And the other thing that's out there that is really interesting and this goes way back to one of my first experiences with Salesforce was integrating Drupal and Salesforce. And we had a Drupal based website.

I was the web director and I went In I wanted to synchronize Salesforce contacts with users so we could have a Drupal based portal. So I went ahead and kicked off a sync that was going to pull down all the contacts from our org and put them into into the Drupal database as users.

Great. I took our website down.

Because whatever.

Resources we have behind that website are nothing compared to the resources behind the Salesforce instance. And Salesforce was perfectly happy to spit data at our website so fast to take the site down.

Yeah.

So there's like that like I think.

There is a unique over.

It's not. It's obviously it's a problem that is going to seem familiar but the, the way it manifests in the ecosystem is, is a bit unique.

And you, you really have to be intentional from an architecture point of view to be sure you're architecting for scale if you, if you're going to ever imagine scale will occur.

But your Drupal example is a very good one at that. Right. Because I see a lot of people that make sure that they're architecting for scale of their Salesforce instance.

But what are all the other mechanisms that are going to be affected?

Exactly.

How fast is that thing generating log logs? How fast is it spitting those logs out? How fast is it sending them to.

The sim when you have storage limits?

Exactly.

And also like how does it fail? What's the fail condition? Like is it going to just is going to come down? Is it going to stop logging?

Is it going to take down your entire integration stack? Let's model that out and be intentional about it. Like have a modern enterprise architecture as part of this whole solution.

Absolutely. And I mean the interesting thing is in your particular situation in that Drupal example, that is a DDoS. Yeah, absolutely. 110 We did.

I was just literally having this conversation with our devs yesterday. I was like that is a DDoS. It just doesn't happen to be malicious. Right.

And security incidents can arise from non malicious insider type things activities completely doing what they're supposed to be doing. Right.

Because when we think on the security side of the house, when we think about security incidents and I had a former chief product officer that reminded me of this a couple of years ago. You look at the CIA triad, confidentiality, integrity and availability. Right.

Well your Drupal website is not available, therefore it is a security incident. So no, that's a really interesting component because like security teams aren't necessarily involved in that step of.

I mean they should be of like hey, what can the Website handle and what can it not handle but it's not thinking about it of like how do I make these things work at the same level? So we need to give the website way more resources than it has right now. That's an architecture standpoint.

But they should be thinking about those connections and what do those connections look like. So that's where, that's where rubber meets the road, right?

Yeah. And the critical thing with that as well is that like if I could do that internally by making a mistake.

Now thankfully it was a dev environment, you know, all these other fun, fun, fun protections in depth. But if I can make a mistake and do that somebody malicious can do it intentionally. Absolutely. That's the like, that's, that's the critical piece.

And anywhere, anywhere you've got, got that, that scale related challenges.

And so you know, in that particular case we decided we, you know, we implemented an inbound queue that we processed the queue as fast as the website could process because day to day operations didn't need more. If somebody wanted to hit it really hard, you know, the queue filled up and the queue, you know, we could, the queue capacity was enormous.

You know, it was so, you know, it wasn't a big deal.

We just had had slower sync and, and that was the, that was the business risk that the organization signed off on to be able to handle, handle that whole situation gracefully and keep, keep available.

Yeah.

And I think that that kind of brings back to the like that's a good summation for, for this particular episode of the podcast, like architecting mission critical Salesforce organizations. Right.

So like you're looking at it and Salesforce may be the hub in a hub and spoke type situation, but it could be feeding or pulling from all of these different spokes and all of those different spokes may not have the resources that are required for Salesforce to interact with it in a good way.

So it's exactly, it's thinking about Salesforce but then it's thinking about all of these other aspects and all of like the website or a sim or your log aggregator or you know, a ticketing queue, any of those things. Let's assume you're not using service cloud for a second.

All of those things are subject to failure points where Salesforce you, you've given Salesforce more than enough resources, but you haven't given everything else more than enough resources. So you have to think about all of those secondary and tertiary things.

So I think that, that's a really interesting point and I think it's really like that is a we are not seeing architecture. Think about it in that terms. That's my guess. You at attain are probably thinking about all of that.

Like you go in thinking about hey, where are the connection points? How is this all happening? You know, are we doing this over 443, are we doing over 80?

Like those types of questions are probably being asked as you're onboarding customers and things of that nature. But my guess is that most internal teams don't think about that and it's because it's siloed. Yeah, yeah. And that's where it scares me.

Because one of the one things that scares me the most is that I see Salesforce teams operating in their own little bubble of like it's Salesforce, don't anybody worry about it.

Security team is focused on the website and on you know, the ERP system or whatever else and. Yeah, exactly, exactly.

And, and then on top of that like the fact that even the most, well, many meaning experienced Salesforce administration in like three or four clicks can do something really bad from a security point of view.

And you know, like that, like that's a pretty unique risk profile because in a lot of cases like traditional AppSec World, you know, you've got code reviews, you've got like who's reviewing that click and what's the process to ensure that that configuration.

Obviously you know there are tools, there are processes like pure Auto Rabbit offers some things in this area but like making sure that like that you've got a mature deployment pipeline that has the appropriate checks that that are that are happening in, in you know, with the right background knowledge to understand the nature of the change.

And that's one of the things that as I've gotten further and further in my understanding of Salesforce and how people have it deployed throughout the organization and things of that nature. I'm a major component of Salesforce mapping into an enterprise risk management framework.

Most medium to large size organizations have an approval board or a CCB board or whatever you want to call it where they convene and they assess the risk to the organization.

So that admin that's making that change, they would have to input ticket and then it have to be assessed for risk and it's being assessed by people like it like security, like Salesforce. So they get a seat at the table and they can give the information and the context behind it so that good decisions can be made. Right.

And as we grow and build that and mature that process, next thing you know it's, it's the very similar Situation of it saying security doesn't know what they're talking about and security saying it just wants to allow everything all the time, everywhere. And we came together and we kind of figured the thing out.

So bringing Salesforce to that exact same table, giving them the seat at the table, whether that be the head of Salesforce development or whatever the case may be, to make sure that that context awareness can be pulled in and then building processes around that. I think that that's where, evolutionarily speaking, I think that that's the next step. Right? Yeah.

And I think once you get to that realm, I think there's a fear, it's a guess, it's a whole like hypothesis. Sure, sure.

I think there's a fear on the Salesforce side that oh, we're not going to be able to do the things that we've always been able to do and be able to be agile and be able to just push product and push things that we need to as quickly as possible because security likes to slow things way down and it is going to make us do this or do that.

Where they've been in this bubble and they've just been able to operate as necessary and the only thing that they had to worry about is hey, we've got a new dev, we've got a new engineer, we've got a new admin, add them to SSO tiles to the IT team, like that's the extent of what they had to worry about.

In all honesty, the way that I actually see this playing out is the initial onboarding into an enterprise risk management framework and team is going to slow everything down a little bit initially until everybody gets up to speed. Give it three months, give it six months, something like that.

And then all of a sudden like you're just going to see things move at a much more rapid clip. And the reason why is because now people understand and they're like, oh yeah, yeah, that makes sense.

And the risk is mitigated by X, Y and Z and we have an understanding of the environment. Yeah,.

It's like learning to ride a bike and operating within a risk framework. But there's also a piece about making sure that the risk framework is properly sort of Salesforce informed.

So like, so that, I mean ideally you've got a certain category of changes that are just like auto approve and log.

Yeah.

Because like they're, you know, there's adding a field that is accessible to a small, you know, that non sensitive data, no PII, et cetera, great at it.

You know, let's we need to know the fact that we did it, make sure there's a proper JIRA ticket, it's properly logged and, and like that, there's no additional, you know, once the processes are well established, there's no additional friction. But, you know, changing permission sets, changing profiles, doing anything with the guest user, like, let's get five or six eyes on that.

Yeah, yeah. What's the cascading of a profile? Right?

Like, who else is accessing that profile and what are you now giving them additional access to that you didn't, you didn't think about, you didn't realize.

And mapping that, graphing that out to understand, like this profile is being used by these seven different applications that you didn't know existed as a developer. And it gives access to 89.3% of the data in the Salesforce ecosystem and you adding it to the app gives 100%. So let's not do that.

And with that, like, there's the, you know, applying this same framework to inbound changes from managed packages is critical because I have, I've run into more than once where a managed package is pushing a change to a profile, to a permission set that's opening it up in a meaningful way. And like, you know, it's very easy to just be like, okay, we, critical path, you know, we checked critical path, we installed the update.

It all works. We're good.

Yeah.

And, you know, which means you, because these auto updates get pushed from the App Exchange, you have to have the proper review process that's synced with the App Exchange package and, you know, and the ability to throw a flag and file a ticket with the vendor if in fact changes are, will have a substantial negative impact on your security.

Absolutely. That's why I like, put it in a lower environment and tell me what the differences are.

Yes, put it in a lower environment and tell me what the differences are. That's what I want to know. I want to know. Oh, okay. We're updating all these profiles. Okay.

Are we, are we giving more access or are we restricting access with this update? Oh, we're giving more. Show me the differences. That's where I kind of live and that's where I sit.

So I think we've had a pretty good conversation, even get to my last question, but it's completely fine. I think conversation was going really well and I think that we covered a couple of really interesting topics.

I think I'm always going to advocate for this.

Get security in often and early in the conversation and I think especially in a Lot of the things that you're doing, like tailoring those solutions and building out solutions and architecting, that's going to be very, very important to have early and often think about the secondary and tertiary items and, and affected assets. Right. Because this is a, this is a very much waterfall type situ situation and scenario. So you want to make sure that you're doing that as well.

And then also ask the question, right? Like it doesn't have to be of Justin, it doesn't have to be of Chris, but ask the question of somebody just to get an outside perspective.

I can tell you one thing that I've learned in my career is I don't know everything.

I generally start every, every conversation with I'm the dumb guy in the room so that I can make sure that I'm understanding where everybody's coming from.

And if I go into that perspective with that perspective, it opens it up for the rest of everybody to give me their perspective so that I can understand where we may have friction points as well as we may have a misunderstanding or lack of guidance. I don't go into any room going, I'm the, I'm the top security guy. I know everything. I don't know everything.

Got a C in my title, therefore I win.

Yeah, exactly, exactly. No, I know that's. I think a little bit of humility goes a very, very long way.

I was sitting with a lot of Salesforce people yesterday and I was like, I'm the dumb guy in the room. I don't know Salesforce as like, we had cumulative, something like 150 years of experience in Salesforce in the room.

I've been in a company that deals with Salesforce for 16 months. I'm dumb by comparative. Right? So, yeah, yeah. Chris, I want to, I want to thank you for such a lively conversation.

I'm looking forward to partnering with you more in the future and having conversations and you being a part of my network now. Like, and I'm going to reach out to you and be like, hey, what would you do in this situation? So this has been another episode of From Code to Cloud.

We will be releasing more of these informative conversations, diving deeper into different topics, looking at different scenarios in the Salesforce ecosystem.

Make sure that you download this wherever you get your podcasts, you can Visit us@autorabbit.com for show notes, helpful links, access to every episode as they're released. And what about Attain, where they, where can they reach you?

You can check us out@attainpartners.com and feel free to reach out to me on LinkedIn. I'm happy to connect and spread the network.

Perfect. Stay safe out there, and we'll see you next time.

Thank you.