Max Feldman: [00:00:00] I do hope as the industry progresses and like the SSPM space progresses, that there's more open content and more and more collaborative elements. There's some ISAC meetings that'll talk about SSPM. There's some conferences where it gets brought up or touched on a little bit, but it's still a young space.

So it can be hard to grasp the full complexity of it. Everywhere I've worked has had gaps in. Onboarding and offboarding process because it is hard to track what users have accounts where and like some places you use your personal github account. And so it's part of the off boarding checklist, but some other system part of that, or what if there was a test instance and it's like technically connected, but it's not part of the XSO framework.

Ashish Rajan: Are you one of those organizations that does not use VPN because you trust the fact that you have a SaaS service that is on single sign on? If you have gone down that path, you probably are also aware of the blind spot you have, if you're not looking at SaaS applications from a [00:01:00] security lens.

Usually this is because SaaS services like your Salesforce Workday or any other SaaS service out there is usually not managed by the security team. It's managed by corporate IT or it's managed by company employees who have nothing to do with security. So maybe if you have read the Okta breach or other breaches that have happened in terms of supply chain, you probably would find out that each industry has its own challenges with it's own unique type of SaaS services for this episode, we had Max Feldman from AppOmni. He has been Salesforce as a prod sec person and has been the prod sec space for a long time. And as someone who came from the SaaS field into this, we spoke about what is something called SSPM by Gartner. And what does it mean?

What does SaaS security really means in terms of what are some of the attack vectors that people can look out for? How can they even start thinking about a SaaS security program for their organization if they were to go down that path? And what are some of the challenges you might come across?

So all that and a lot more in this episode. If you are watching or listening to this episode for the second or third time, we would really appreciate if you take a few moments to just drop us [00:02:00] a review or rating on Apple iTunes or Spotify if that's where you're listening to this. Or if you're watching this on YouTube or LinkedIn, feel free to give us a follow subscribe.

It really means a lot when you ask us questions on the comment section or send us emails with your questions. So it helps us grow and helps more people find out about what Cloud Security Podcast does. And by the way, thank you for the 1. 5 million downloads that we hit yesterday. It has been the most humbling moment for Shilpi and myself. And we started this four years ago and it would not have been possible without all of you sharing episodes that you found valuable with other people and letting other people know that, Hey, by the way, there's something with Cloud Security Podcast you can use as a resource for knowing everything about cloud and cloud security.

We also recently released a custom AI agent. I know. Everyone has been talking about ChatGPT, but I don't know how many people have been talking about custom ChatGPT agents. We made one called cloud guardians specifically for cloud security, which should help you learn cloud security, do your cloud security job better.

But we're not opening up for everyone. We are starting with a beta release for it. It's still a free custom agent that people can use, but we want to [00:03:00] make sure. that even though we have trained the data based on all the interviews that we have run on cloud security for podcasts so far, and we'll keep adding all episodes, including the one that you look about to listen to right now, we just want to understand how do we trust this?

And we don't want to trust it ourselves and not just give it a certification. So just like any other security person would do for a certification, we would like your help to understand if we have trained the model the right way, where do you find it to be problematic? If you do decide to help us. And we would really appreciate if you do, we would like to say a special thank you by giving you a special sticker of our mascot called Cloudie and I look forward to hearing from you either in the comment section on the YouTube video, or just send us an email. If you want to spend some time and get involved in helping the community, drop in a comment as Cloudie, C L O U D I E, or send us an email with Cloudie to info at cloudsecuritypodcast. tv.

That's what I wanted to share about the episode. And finally, we will be at AWS reInvent. And if you are there, definitely come and say hello. It is the biggest AWS event of the year. So we're expecting a lot of announcements, specifically AI announcements is one more thing, [00:04:00] but I would let the announcement be the judge of it.

If you're there, definitely say hello. And we would love to say hello and give you a hug in person as well. And include you in our videos that we do, but I just want to say, thank you. I hope you enjoyed this episode as the previous episode that you enjoyed, and I will see you next episode. All right. Enjoy.

Peace. Hey Max, thanks for coming on the show, man. Really appreciate you coming in.

Max Feldman: Yeah. Thanks for having me.

Ashish Rajan: Not a problem. Could share about yourself, maybe that's a good place to start.

Max Feldman: Yeah. Yeah. So my name is Max Feldman. I'm the director of security engineering at AppOmni.

Worked in SaaS and SaaS security for a while now. I started at Salesforce on the product security team, and then I worked at Slack also on the product security team, moved around. And then. Yeah, I went to AppOmni working on SSPM, SaaS Security Posture Management. So pretty much my whole career has been cloud and SaaS security.

Yeah.

Ashish Rajan: Awesome. I'm glad you came from the Prodsec team as well so you understand the technical nuance of the security aspects as well, but sometimes people may be confused with SaaS, like a lot of people think cloud is SaaS as well, AWS is [00:05:00] SaaS as well. In this particular context, when you say SaaS, so we can level the playing field for the conversation and have everyone in the same playing field.

What do you mean by SaaS application when you say security of SaaS application?

Max Feldman: Yeah. So I would differentiate it from like infrastructure platform as a service. And then just to give a really easy example, Salesforce Slack, ServiceNow, Workday, things like that. There are a couple applications where it starts to get a little blurred.

So you've got like Microsoft, which has SaaS components, but then it's also linked to Azure and Azure AD. So some of them blend a little bit, but I'd say more of the business processes and the, Software that's running that for enterprises, but also GitHub, GitLab, things that are running in the cloud, but they may relate to code.

They may relate to infrastructure, but they're not literally the infrastructure of it.

Ashish Rajan: And would you say I guess talking about security for these as well, because I think we're talking about SaaS security here, because I haven't really heard a lot of conversations about SaaS security. It comes up here and there in conversations.

Now there's a whole SSPM space that you refer to as well. [00:06:00] What is SSPM and why was it not being considered so far for security perspective?

Max Feldman: Yeah, so it stands for SaaS security posture management. It's analogous to CSPM, but for these SaaS applications, and it's a little more niche and specific to SaaS apps, I'd say a maturity and understanding.

And there's. There's other unique issues in the SaaS space that make it a little bit harder to maybe understand at a glance. So I think like with infrastructure, with that cloud services, it can be fairly straightforward to say Oh, our servers are out of date, or there's some vulnerability and we need to patch it or all of our infrastructure runs in the cloud.

We need to secure it. SaaS can suffer a little from visibility and different stakeholders. So you may have, let's say you're a large organization, you have Salesforce Workday, ServiceNow, Slack, GitHub. You have probably different admins for each of those, and then a security team that's completely separate from it.

So you end up with [00:07:00] some maybe confusion or lack of visibility, lack of awareness, and the folks who manage. The Salesforce instance may be interested in security, but aren't necessarily the experts that we would expect on the security team proper, but then the security team proper doesn't know anything about Salesforce.

And if they do, then they probably also don't know things about ServiceNow and Workday. It's all these services are so complex. It's hard enough. You can be an expert in one. There are like courses and certifications for just Salesforce and just Workday. On top of that, to be a security expert, it's complex.

And then I think it lags a little because there haven't been as many breaches either. So it's catching up slowly and it's getting more attention, but there's more and more attention to the data actually stored in these services versus like clouds. Its obvious, everything's there, it's a worthwhile target, attackers are going to try and disrupt your service or [00:08:00] run crypto miners on your infrastructure.

It's a little more subtle sometimes with that.

Ashish Rajan: So what is the Gartner SSPM then? Is that the same?

Max Feldman: I believe so. Yeah, and they have like players in the space and the quadrant for SSPM.

Ashish Rajan: They've basically gone full gamut with it as well. The reason I ask that question is because a lot of people, from an organization perspective, there will be large organizations that actually have people who solely rely on Gartner. If it's on a Gartner category, I don't really care about it because it's not important enough for me.

And I'm not saying all enterprises are like that, but definitely there are some that trust that if there's no Gartner category for SSPM, then there is no need for me to consider it because, clearly it's not a pattern. So it's a Gartner SSPM. And the SSPM that you just mentioned, the same, both of the same thing.

Max Feldman: Yeah, exactly the same concept. It's an evolution of like, how do you apply security to these SaaS applications in general? And then there are specific ways to do that, but yeah. Versus like CSPM you're looking at, even without a category, I think can be a little more obvious. Oh, [00:09:00] here's where everything's running.

Like here's all our sensitive data. So whatever level of the company you're in, you think yeah. Obviously, we want to secure that if you're looking at SaaS, it can be trickier. So that category, I think, makes it a little more clear. And it's recent too. Just as time goes on, there's like more adoption of cloud services.

And then there's more adoption of SaaS services. And then there's more attention paid to like SaaS security. And also all these SaaS applications grow in complexity. But yeah, I think it's the natural evolution of security attention over time. It's on prem, and then it's the cloud, and then it's,

Ashish Rajan: yeah. Yeah. And would you say, at what point would people start considering an SSPM? Should a startup today consider it? Cause I imagine a lot of startups out there have a lot of SaaS services. And I think I was reading a survey somewhere, an average organization these days has about something 300 odd SaaS services or something like at what point should someone consider seriously thinking about SaaS security?

Max Feldman: I would say at any point it's worth [00:10:00] considering. It's good to be thinking about security in general from the get go and it's easier. So it's much easier to be thinking securely to begin with than to go and build an organization or build a company. And then look back and say oh, we should have done this more securely and then start trying to fix these things and fix this debt that's accumulated.

So I'd say like short answer immediately from the get go. It's good to be thinking about security. It's in practice can be a little more difficult if You've got a couple people or let's say a handful of people and everyone's jack of all trades and they're working in these different applications and you won't necessarily have the expertise or know, like, how do you configure this securely?

How do you make use of this securely? So when you go for an actual solution might differ from when you should start thinking about it. And I think that's pretty general too. Like when you're small, you should still think about the security of your code. But it's later on that you start purchasing more like security products.

I'd say that it's very important from [00:11:00] the get go to be thinking about like inventory and where data is and visibility, because that helps paint a clearer picture of like when and where to invest. Because if you start and you have a couple of products, or let's say you have even a few hundreds of products.

But there's a long tail without a lot of information in them. It still lets you focus on the most important and largest applications. That also generalizes as you get to a huge organization with thousands of SaaS applications. Some of them won't have as sensitive data. And with finite time, finite resources, you do have to play this prioritization game.

But there are some apps that'll have. all of your employees healthcare information and salaries and all this PII. There are some that'll have trade secrets. There are some applications that'll have like financials, all this other information. So those are probably worth more attention. So yeah, like your mileage may vary depending on how you're deploying things, but it's important to know where you're putting your sensitive data and then be thinking about are you following the best [00:12:00] practices that they recommend the provider?

Ashish Rajan: And you've touched on a very interesting point, man, because a lot of people may be even confused about when we say SaaS security, what kind of threats or what kind of risk are we really talking about? And I love the example of HR data. It's like small company, large company, all of us have employee information for their home addresses, social security number.

There's a lot of information that your emergency contact, like you can keep going on. And it's also important to understand the SaaS security risk. It's not just from a perspective of, Hey, I want to make sure that Ashish has the right amount of access on the SaaS service. It's also about the fact that the system that have data that I cared about, if it was to go out.

And I obviously don't want to use the breach as a way to talk about this thing. But I would say that if it would concern you that if the system was exposed to the internet. Then I think it's definitely higher in that priority list for it has sensitive information for me to actually consider this seriously.

Max Feldman: Yeah, absolutely. And sometimes that's the case. Like it is [00:13:00] actually information exposed to the public internet. Like sometimes it's exposed within the organization. So it might be easy to think Oh, we're all at the same company. It's not the biggest deal, but if you get to a company, an organization that has like tens of thousands or hundreds of thousands of people, and that HR information is exposed or information about like company financials are exposed, that's additional vectors for an eventual leak to the external world.

One could imagine, oh, if you could see all the salaries of your coworkers, or you could see information about them or their performance reviews or things like that, creating a kind of worse work environment. And then if it's exposed to the internet, it's even worse that can happen depending on like some applications are just so complex and have so much data in them.

It could be okay. Over permission for internal users, for certain types of users, for external users, maybe there's a customer success venue, and that is open to all customers, but maybe that's also open to the world in general. So you might have a case [00:14:00] where, Oh, you think it's locked down and it is via the UI, but it's not via the API.

We've seen like all sorts of different edge cases and cases of just like information exposure, and then you could imagine, okay, what if it's like an HR system, or it's a company that's tracking all of its customers in a CRM solution. And then they leak their customer information, like customers aren't going to be happy about that.

So yeah, I would differentiate the SSPM and SaaS security. It's like the security of the platform itself and that's managed by the provider. Like I used to work on those teams, they're big and they're very invested in making sure that these SaaS providers are secure. So making sure things are patched, like running a bug bounty, following best practices.

But the complexity is where it starts to be the responsibility of the implementers and the deployers and the users of these systems. And with so much complexity, it's possible to shoot yourself in the foot sometimes. We're not necessarily realized like the scope or the [00:15:00] importance or not realize how the future users are going to be using it.

So maybe you set up some like Salesforce or something, and then future users think Oh, this would be an awesome use case for Salesforce. It's super powerful. We can write our own custom apps. And then they're not as familiar with Apex and Visualforce and the security to use there, and they've created this cool app, but there's so many unforeseen paths that the SaaS deployment can take.

And even if you're, you start off, sorry, that was a bit of a tangent, but you've got your security provided by the provider. And then that's complexity where things can go wrong.

Ashish Rajan: Quote unquote shared responsibility. The cloud model is also applicable for SaaS services as well.

Max Feldman: Yeah, exactly.

And I think there are a lot of analogs between cloud and SaaS, CSPM, SSPM, the things to be considering and that everything has nuances, but I think at a high level, there are a lot of similarities. And we also see one other thing about awareness is. Over time, the cloud became more and more [00:16:00] poked at by pen testers and attackers and security professionals.

And so early on in the days of AWS, you have S3 buckets exposed all the time. And then there are tools, there's automation, it gets a lot of attention. You don't really hear about it as much anymore. It's still possible, but it received a lot of attention. I think SaaS is trending in that direction, but hasn't fully hit it yet.

It's more and more people are putting eyes on these and more and more people are like finding automated tools for checking for SaaS misconfigurations, but it hasn't quite hit the same state where it's like. Oh, if you haven't exposed that S3 bucket, ten people are contacted stealing the data immediately because everyone's running a scanner.

Ashish Rajan: Yeah, and would you say, wasn't there like an Okta breach that happened recently? Would that be an example of a scenario where it's not that... It has never happened. It has happened in terms of a third party or a SaaS service actually being breached.

Max Feldman: Yeah. Yeah. There's that we've seen it in organizations where SaaS was a pivot point or an [00:17:00] entry point, or it was the SaaS application that was.

It's breached and then data was exfiltrated from there. So that's not the first, won't be the last. And there's so much complexity in it. If you could get into, let's say an IDP and then pivot from there, you might be able to reach other parts of a company or internally. Let's say you get into Slack and you compromise a Slack account. You start messaging people to Hey, click this. Then you pivot pivot. You try and get access in other ways. And there are like defenses against that, but they're all complex and like different entry points and pivot points. And it's hard to be mindful of all of them because you have your IDP, okay, that grants access to everything.

So watch out for that. But also. Slack for social engineering and for getting access to other accounts. And also maybe like Google Docs or Microsoft, you start circulating something and internally within a company and it has happened before. And sometimes it affects like the company itself. Sometimes it affects like the user or [00:18:00] just a specific company because of the way they Implemented things that granted access to attackers and then they established persistence.

If you can pivot from one account to another, maybe you pivot to an account that has code ownership, and then maybe you establish persistence on the servers themselves and you have access to everything, but your starting point was something simple. So it exposes this entirely new. attack surface and then every application can be another attack surface.

And some of the SaaS applications are going to have if it's an IDP, it's every employee. Literally everyone is in there. If it's Salesforce, maybe fewer, but still a big chunk of the org. If its GitHub, it'll be like an engineering section of an organization, but Slack will be everyone or Microsoft Teams would be everyone.

And so having all of these running simultaneously, you're no longer thinking okay, don't let someone's endpoint get breached or don't let someone's let's watch our emails and look for suspicious attachments. You're looking for anything and you have to [00:19:00] have the protections on all of them because if let's say you disable like SSL and MFA on one app, then maybe that's used as a pivot.

Ashish Rajan: yeah, a lot of people assume that the safety is in the fact that there is single sign on all SaaS applications. So the day Ashish leaves, his access is being removed, but how many SaaS applications out there support SSO? And how many of them support SSO without any extra charge for SSO?

Max Feldman: Yeah, the SSO tax or the...

Ashish Rajan: Yeah. Basically, yeah, that's the SSO tax that people talk about as well, because there are SaaS applications that, yes, you want to have single sign on and have a MFA. But someone has to pay for it from the SaaS providers perspective. And that's where it becomes a conversation for, let's talk about it in the next financial year or whatever.

One thing that you touched on before we spoke about the types of attack was the similarities between CASB, CSPMs as well. What is the difference between a CASB and a SSPM?

Max Feldman: Yeah, sits in the network and is looking at where your employees are going. [00:20:00] And it's brokering access to your cloud services and it can sit between so let's say I'm on the VPN.

It's monitoring my connections and looking at what's going back and forth between me and some SaaS application. They can lose a lot of information. SaaS complexity and just the use of it has exploded. So let's say, yeah, we've got a VPN, but you've connected hundreds of additional apps. To your SaaS providers.

So like Slack, Salesforce, Microsoft, GitHub, all of these things can have third party applications. So CASB won't catch those. It won't necessarily see a lot of other interactions that are going on. And then also there are a lot of companies that don't use VPNs anymore or have different setups and there are more VPN lists.

Ashish Rajan: Oh, like the SASE, like the S A S E, the service on edge or whatever it's called.

Max Feldman: Not even that, where it's just like everyone gets a login, it's SSO, and there's no monitoring. Or you have an endpoint on, endpoint monitoring on your [00:21:00] laptop, for example, but then is it on your phone? Do you have a personal work device?

And you might be, F all of these SaaS providers also have mobile devices, so the phone would need to connect to the VPN, and I've worked at multiple places where, You don't need to do that. And I think it's growing in popularity because it's just easier and faster. And then you count on these applications to just use SSO.

So you've pushed a little bit of your planning for access just over to an identity provider. And I like the places where I don't have to get on a VPN a lot, log in. But I am on Slack on my phone. I'm on Gmail on my phone using like G Suite. And GitHub and so all these things and if you, for CASB, it has to have all that visibility and it would still miss the connections from the SaaS provider to other applications.

So let's say you install in Salesforce, you can install applications that are third parties and they're accessing your Salesforce data via API. CASB wouldn't catch that and one of those could be [00:22:00] breached. So you could have some third party application that's possibly not even in your list of approved vendors because a lot of SaaS providers have.

They have rich ecosystems for apps and it's easy to install. So someone might say Hey, I want this helper for something, or there are so many Slack integrations, or it's yeah, like Slack and Jira, Slack and GitHub, you probably know that you're using GitHub and Jira, but there can also be other apps where it's like, Oh yeah, like this is something more fun, or this is a note taking app and one or two people in the company wanted it, but they had permissions to install it, or it was requested and just someone clicked approve.

But then it has access to all of the data in there. So CASB is not going to stop that necessarily. So like I would say a lot of the SSPM specific and SaaS specific solutions are integrating directly with the SaaS applications, like via API, and also tracking. One of the other things you miss with the CASB is like configuration drift and configuration changes and updates on the SaaS [00:23:00] provider.

And you could see, okay, who has gone into the system, who has accessed what. But there are cases where that doesn't matter if an admin has made a configuration change or an admin has said Hey. I want to turn on this new feature tied to AI, for example, there are a lot of AI integrations. And so companies are thinking like, wait, do we want all of our text exposed with the third party. We need to vet that. But if there's just a button to push, it's not a breach. It's not a theft of information. It's not immediately concerning, but I think like a good solution would monitor that and like a mature program isn't necessarily looking at just, okay. What users have done what. But they are at, or like preventing access to certain things, they're looking at the system itself, like plugged in directly and saying Oh did these settings change? Did this configuration change? Was additional access granted and work natively with the SaaS application instead of sitting in the middle.

So that's say like a couple of the differences between some of the [00:24:00] others.

Ashish Rajan: Would you say ChatGPT is a SaaS application as well? Cause you technically don't install anything. You just go to a browser, you log in.

Max Feldman: I'd say depending on how you use it. Yeah, it's running in the cloud and you're paying per usage.

So I think it fits that definition pretty well. You could run ChatGPT specifically, I think, as a SaaS application. You could do like local LLMs and set up your own machine learning AI infrastructure. So it's all entirely contained. But if you're using an external service, that's like learning off of your data and processing data.

Yes. Even if someone goes in and asks a question Hey what do we think about this deal coming through the pipeline that it's technically that's corporate data that's been sent off. But if you're training it on all this data or like making use of the API, I think it fits that pretty well.

It can start to have like sensitive data that it's storing or trained on.

Ashish Rajan: Because it goes back to what you were saying earlier about, every SaaS application and also the example that you gave for what kind of incident can happen in a SaaS scenario. [00:25:00] Prioritization for, or at least having an inventory of what SaaS applications you have and then picking which is a priority based on the kind of data it's consuming.

And I would imagine because people might think that there's a lot of similarity between what a CSPM does or a CNAPP does these days and a SSPM as well. If I have a CSPM or a CNAPP do I still need an SSPM?

Max Feldman: Yes. Yeah, I think they're analogous, but they don't cover the same things. Those solutions might cover like Azure or GCP or AWS or certain other cloud platforms and infrastructure, but they're not connecting directly to SaaS applications.

And if you're a technology company , I think a lot of companies are using cloud services now. So any company you might be using AWS you'll still have Salesforce and they're completely separate. There's no connection, nothing covering AWS will by default cover Salesforce. It needs completely different connections.

It needs completely different things to be built. A lot of like security principles still apply, like least privilege and configuring things properly, [00:26:00] looking at what data is going where the foundations of security, I think are universal, but then the specifics are wildly different. So you have this huge attack surface and all these things going on and Salesforce too, but in different ways, like you can have all sorts of data.

Like I used to review some of the apps on the app exchange and it's. such a rich ecosystem, but there are so many use cases, like things I'd never thought of things specific to industries that I had never worked in. So you have specific solutions for Oh, like CRM. Great. Okay. You're tracking your customers, but what about healthcare?

What about like oil and gas? And you have all these other verticals that have specific solutions and specific types of data in there. And it's all critical business, critical, sensitive. And it varies wildly. And then there are custom apps for it. You can customize Salesforce to hold all of this information.

And it has, I would say in similarly like unlimited potential use cases to AWS, just in a little bit different of a way. So you may not always be like [00:27:00] writing code and building things from scratch, but you're still configuring things and you're still setting yourself up for complex use cases. So there is while they're not the same and like the specifics and like the solutions are going to differ. It's also a lot of complexity and same with other applications. You can like there's some tasks applications were pretty much limitless potential build whatever you want, which is awesome and useful. And also then what data is going in there and how is it actually built and who maintains it?

So there's so much complexity. Oh. And you'd also ask about offboarding and SSO, if that's a solution. So it's a lot of SaaS applications do offer SSO. A lot of them charge for it and also not all of them. And also you may not know, if someone at your company can just swipe their own credit card or get a free trial of something and then they're using, okay, here's something for brainstorming or here's something for like our roadmap and it's a fun tool they set it up with their own personal account and it's not SSO like everywhere I've worked has [00:28:00] had gaps in onboarding and offboarding process because it is hard to track what users have accounts where and like some places you use your personal github account and so it's part of the offboarding checklist but some other system part of that or like what if there was a test instance and it's like technically connected, but it's not part of the SSO framework.

So an SSPM solution can offer more insight into that because you're tracking every app you're pulling straight from the API, you see the users and then you have a central place. So you could connect to HR and say okay, or your HR system and say okay, this person's off boarded. Here's all of their accounts.

Wouldn't necessarily catch everything still. If I go and sign up for a free trial of something. And then I just start typing and saying here's everything I think about our roadmap and our corporate secrets. That's hard to track like kind of shadow IT, but if I'm doing that and there's an SSPM [00:29:00] solution connected, then there's awareness.

Yeah. So if that process is followed, it's a hard problem to stop people from just like typing things into wherever, but when they're like a SaaS solution that's being used and like officially supported, at least you can handle that offboarding a bit better, even without SSO, because you have something that's really got visibility into all your nooks and crannies of your SaaS.

Ashish Rajan: Yeah. Would you say like the whole phishing campaigns where all we are trying to do is not make the person click the link the same way, at least having awareness of the fact that. Hey, by the way, if you use Salesforce or any of the SaaS application, please make sure you don't use your corporate data in there for whatever reason, unless it's an application that we are all aware of as an organization that we are paying money for or signed up with a free trial, like that kind of awareness.

I guess just to extend that example a bit more for people who may be thinking about doing a SaaS security program in their organization. What's the starting point? I feel like we're starting a phishing campaign now, but what's a good place to start for someone who's [00:30:00] listening to this and maybe considering having a SaaS security program start in 2024.

Max Feldman: Yeah. So there are a lot of good places to start. I think the first place for any security program is to be thinking about like your goals and the risks and like what data is at risk and like an understanding that it's really everything and then one. I'll offer some like kind of general thoughts and then maybe more specific like resources for starting points But like one thing in security like I found this in ProdSec I think it applies everywhere.

It's like investing in a happy path for people. So if you're writing code make the secure choice, the easiest one. So make sure that your security review process is easy and it's accessible and pleasant. And then it's the same with signing up for SaaS applications or like vendor risk and review process.

If someone wants an app, make it. enticing for them to do it so that people don't try and circumvent the process because the process is easy and it's designed with people in mind. So maybe someone wants some solution for like note taking and there's one that's [00:31:00] supported, there's one that's not. It should be easy to request the new one and it should also be easy to say hey we have this supported solution but if everyone involved has at least a little empathy then you're thinking like okay why do they need this solution?

Is what we have enough or not? And then how do we do a review process that's quick at least and so having the secure path be the happy path be the easiest thing that means people will be forthcoming and it ties into other aspects as well they'll report phishing emails because it's easy.

There's a channel to do it and their work is acknowledged and thanked. And so same with doing a vendor review or asking for permission, make it enticing to ask for permission instead of to just go do whatever and try and deal with the consequences after the fact. I think the starting point is empathy and thinking about what are the consequences and the benefits and then thinking about like the human aspects of everything that you're doing, then like more specifically, there are various like SSPM solutions, some are more suited for small [00:32:00] companies.

Some are more suited for larger companies. Sometimes it's hard. If you're a small group, you don't want to spend extra money on security. You're really trying to get out like an MVP. You're trying to get your work done. And so then that could be a little tricky, like how to start with no resources allocated, and I think it's important to consider the downside and the consequences otherwise, because you may be able to put off security a little, but as you accrue debt you set yourself up for a disaster that's going to eat away at a time and resources in the future.

By actually doing it, and at least investing some time early on, you save a lot of pain down the road. And then investing some money early on, I think, is also important for a security program in general. Maybe it's SSPM my personal opinion, SSPM is super important. Everyone's using SaaS applications, so you should be mindful of that.

But perhaps your first step is purchasing like an IDP. So at least everyone's is logging in from a central place. And then maybe it's some lightweight security software that helps a little, or maybe it's a bug bounty. Maybe you're releasing [00:33:00] something and you think okay we don't know everything that's going on.

At least we can reward researchers a little bit for starting specifically with SSPM. There are, like Gartner has some resources. It's interesting and tying it back to the maturity of the space. If you Google SSPM, all the results are vendors. So as opposed to if you Google. Like web application security, you're going to get OWASP and there are talks and there are like open source communities and resources and tools.

And then the SSPM space, I don't think has hit the same level and same maturity and it's a little more niche, but it's still a huge space. There are so many SaaS applications and so much data and all of them, but right now, a lot of the information tends to be provided by vendors. And AppOmni where I work, we have a prediction SaaS and SSPM predictions coming for the coming year.

And I think that would be a good starting point. And there are also other vendors that have similar content, but it is interesting to contrast like the available [00:34:00] resources now versus if you're getting into web app tech, or if you're getting into just like security in general, you've got a ton of places, a ton of tools, you've got like all these websites you can hack. You have bug bounties. You have bug bounty providers who have like courses and talks and this wealth of information on how to get into it how to learn more for all audiences, too It's oh you're a pen tester. You can start here. Oh, like you're running your own security program Here's a great place to start.

SSPM is a little newer. It doesn't quite have all of that There are some researchers in this space who published blogs. There are some bug bounties that cover it specifically, but it hasn't quite hit the same level of maturity. All right. That's a long answer. I think like the summary or the short answer is like, as with all security programs, like start with empathy and keeping in mind what are your risks and who, Is actually involved in the process, like the human element.

And then right now, a lot of the information is Gartner and vendors, and maybe it's helpful to read like [00:35:00] multiple perspectives and distill that I do hope as the industry progresses and like the SSPM space progresses that there's more open content and more and more collaborative elements.

There's some ISAC meetings that'll talk about SSPM. There's some conferences where it gets brought up or touched on a little bit, but it's still a young space. So it can be hard to grasp the full complexity of it. I think a good starting point is at an decent enough size when it's possible to invest in a solution.

I do think that's a reasonable way to go because it is hard enough to be an expert in one SaaS application. And then it's way harder to be an expert in five. And it's impossible to be an expert in 100 or 200 or 300. And then before then keeping in mind inventory and keeping people like forthcoming and mindful of where the data is going.

And SaaS providers themselves also offer information. So like Salesforce has Trailhead modules on security. I think every major SaaS [00:36:00] provider has documentation on how to most securely deploy, and that can be a little tedious, but it's necessary. I would say it's not something to skip. So if you're rolling out Microsoft, it's worth reading the documentation and following their best practices.

If you're rolling out Salesforce. It's worth reading the documentation and following the best practices and making sure you can figure things securely, like principle of least privilege, requiring MFA SSO. Those are the top three really concrete things that make it greatly increase the security of your SaaS applications.

Yeah, there's like general approaches and then specifically MFA, SSO, least privilege. Make people use a password manager. Those are all going to be like such a baseline. Let your program flourish for a little while you mature.

Ashish Rajan: Oh, fair enough. Actually, that's a good point because sometimes you just don't have to go through the extra mile of buying a SSPM, but as long as you're doing basic hygiene, you should be comfortable with it.

For people who might go down that path of doing [00:37:00] this, I think you mentioned this in the beginning of our interview as well. where sometimes it's corporate IT that owns SaaS applications. They might have a Salesforce expert in the organization. They might be a workday expert, maybe think there might be a few challenges along the way that when they are thinking of building a SaaS security program or even thinking about working on this.

Can you give us a few examples of what kind of challenges people can expect as they work on this?

Max Feldman: Yeah, and I think some are going to be relationships and if you have a big enough company you have teams that are just really divergent and maybe not necessarily working well together and I think like empathy plays a big role in that if you're IT admins and your security team I think this is a huge responsibility of any security team is be an enabler and for security, but don't always say no.

This was a lot of the work we did at Slack on prodsec wasn't necessarily like technical security stuff. It was like, how do we build better relationships with the company? How do we make processes that encourage people to [00:38:00] come to us and be forthcoming? And how do we? Enable people to move quickly and securely, like it doesn't have to be one or the other.

It doesn't have to be a trade off. And I think it's important for security teams to realize that. And when you have that foundation of a better relationship, it's easy for the IT team to say Hey, we're thinking of enabling this, or we want to make these changes. What are your thoughts? But if you have a contentious relationship, that's going to be a challenge.

If security is viewed as a blocker. IT and administrators of the SaaS system want to get things done, they won't go to security. As with anyone, like if you're a software engineer and you think, okay, I want to ship this and security will slow me down, you would avoid it if possible. Maybe, like maybe not, but it's easy to say I have pressure to do my job quickly.

Yeah. Do it well, and security may not be part of that. I think it should be, but it may not be the pressure that you're receiving as an individual. So maintaining that good relationship, I think that's the fix for that. But that's one of the challenges. One of [00:39:00] the other challenges is that might be faced with like how much debt there is in terms of configuration.

If you started using some of these applications 10, 20 years ago. They've evolved in the meantime and become more secure over time and become easier to configure over time. But there may be like legacy features. You'll see like legacy in some providers or like legacy features that are dangerous, but still supported for now.

And so that can be a challenge to say okay, how do we change this without breaking our process? Or, I've seen this before where some process or some feature relied on a bug that needed to be changed and needed to be fixed. So okay, how do you work with a team to find a new solution?

And that takes, I think the solution for that is also empathy and patience, like so that a security team can help be an enabler of the functionality that was already there while moving to a more secure state, but that's definitely. The longer you've been on SaaS application, the [00:40:00] more perhaps like bad practices that happen, or if security wasn't a priority in the rollout, like same with coding, same with anything, if you, the longer you wait to be secure, the harder it is to get there.

So I'd say those are some of the problems. Some of the others are just the knowledge gap like security experts know a lot about security and not so much about the SaaS platforms and providers and the SaaS experts aren't necessarily security experts like a lot of people i've interacted with are great at security and are interested in it, but it's two different spaces with two different incentives.

And so some organizational alignment and investment from everyone at all levels and acceptance that security is important and it doesn't have to be a blocker that can help there with the knowledge transfer or the trust that you can build between each other. It's nice if they know why to make some changes, it's nice to be invested in on board.

But if they also trust Hey, the security team, says we should do this. It can be easy. It can be a [00:41:00] quick okay, yeah, we'll do it. We don't have to question and same with the security team. If they say why do you need this process? Maybe they don't have to ask why maybe you can say okay, great.

Yeah. Like you need that process. Okay. How do we do it secure? And it's good to have you can have healthy conflict between teams, like openness and transparency. But I think maybe other people would disagree but I think a lot of like challenges and solutions end up being relationships and collaboration as opposed to oh how do we solve this really hard technical challenge like most of what I've seen hasn't been like okay we need The best like crypto geniuses in the world working on this.

It's more okay, how do we get aligned and how do we have a nice working relationship so that we can solve it?

Ashish Rajan: Yeah. Awesome. No, thank you for sharing that as well. I was going to ask what resources, but you've already shared the resources as well. So I won't go into it, but that's most of the technical questions I had.

If people want to know more about the SSPM space or just the SaaS space as well, how can they reach out to you? Where can they find you on socials?

Max Feldman: My email is max at [00:42:00] appomni. com. That's probably the best one. I'm on LinkedIn, Max Feldman and AppOmni if you find other Max Feldmans on LinkedIn. I have a Twitter, I don't use it too much anymore.

It's MrsBufferWorks. It's yeah, thank you. Yeah. I don't use that as much as LinkedIn and email. So yeah, I'd say those are the best.

Ashish Rajan: Awesome. I would put them in the show notes as well, but dude, thanks so much for doing this and thank you for shedding light on the whole SaaS security space and how can people even start working on this space as well.

Thank you so much for your time and definitely looking forward to at least seeing where the young field of SaaS security kind of matures onto as well. And maybe having another conversation, but thanks so much for your time. And for everyone else who's watching, thank you so much for your time for. Listen to us, watching us as well.

We'll see you in the next episode. Thank you. Yeah.

Max Feldman: Thank you.

‍