Bridging the Gap in SaaS Security

Acora and AppOmni team up to explore SaaS security; one of the most overlooked threats in the enterprise.  

Listen as we delve into topics around the growing attack surface, high-risk misconfigurations that we are seeing in the wild, 3rd party risks, and how to adopt and implement reliable SaaS tools and #automation.

Interested in finding out more about Acora? Visit our website here.  

Acora is a progressive technology services provider that is leading the industry with its Experience-Led Approach™. Its mission is to unleash people's potential through outstanding IT experiences, striking the right balance between frictionless user experience and best-in-class security. Acora continually invests in the right people, processes, and platforms that enable businesses to excel and reach their full potential.

Discover all of our IT and Cyber Security services here: Our Services - Acora

Transcript

Hello, and welcome to our podcast. Today. We are joined by scrutiny's director of technology, Adrian Taylor, and AppOmni’s VP, EMEA, Brandon Romisher. Listen as they discuss topics around SaaS security. One of the most overlooked threats in the enterprise. 

Thanks for the introduction. I’m Adrian Taylor and we’re joined by Brandon Romisher. Hi, Brandon. Hello. You're very welcome. So let's talk about the risks associated with this huge attack surface, which is becoming more and more prevalent in recent years. And I'm talking about infrastructure as a service and software as a service.

And I know we've chatted about it a bit before on how difficult it is to see into some of these kinds of environments and the risks associated with so many different people having so many powerful tools now to deploy this infrastructure. 

What are the risks and what can we do about it? I think in general, we're seeing a lot from security teams, the concept of cloud security and for whatever reason, the concept of cloud security, encompassing infrastructure as a service and platform as a service and the developer pipelines that come along with that.

And a lot of the time business applications that are delivered as SAS workloads are left out of that for whatever reason, right? You know, SAS applications or cloud-delivered endpoints that store highly sensitive data. They are extremely abstract and fluid. So, you typically have large teams of developers, architects, and administrators.

That's been, you know, months, quarters, sometimes years designing and implementing these systems. And then there's a continuous process. You know, adjusting these systems and configuring these systems in a way that delivers business value to the organization. I think I think there's this misnomer out there that SAS applications are somehow magically secure because you're not, you know, you don't have access to the bare metal underneath them.

You don't have access to the infrastructure layer to meet. Because you can't stick an agent on that underlying infrastructure and monitor in that way, then you traditionally, when your other applications that look at your data centre, your VPC, that for some reason it's magically secure. And I think that's, that's obviously not the case.

There's just a different way that you need to approach monitoring these systems because, because of the way that they're so abstract there's the concept of, of system hardening, right? Within any large SAS platform, there are hundreds of thousands of different configurations. Security native settings that are going to impact the way that an instance of an application is running.

You know, in Salesforce, for example, there's around 75 to a hundred of those settings that are relevant to security and heart in that instance, just security alone. Just that, just, just, just that. Right. And wow. You know, when you think about those, right? Yeah, exactly. Right. And they change often, right.

They change often and they're typically managed by. The it administrators, right, who are doing a great job of trying to deliver value to the business, but they're not security professionals. They might not know what the impact is of, of turning on or turning off a security relevant switch. And then, then it gets, it gets sort of compounds from there.

Right? You think about the concept of role-based access controls and access provisioning and these big SAS systems. There's the concept of, of roles and 365. There's the concept of profiles in salesforce. How you're provisioning a wide range of permissions to users that you're granting access to these systems.

You know, again, when you look at you know, 365, there's upwards of 40 to 50 different permissions, that should be monitored to make sure. You know standard users can't you know, manage things like IP restrictions and manage certificates and managing coaching capabilities. So these are all different sort of system-level settings that can be configured within a large SAS platform that really need to be monitored and maintained.

It's interesting. Isn't it? Because the other thing you said, you said a thing there about, you know, there is an assumption that. If you buy infrastructure or software as a service from one of the, from anyone, but particularly from one of the big name players that and it's getting less prevalent, but I do still see, I still come across this kind of approach that this attitude that it's more secure than you could make it right.

If you hosted it yourself, if Google is doing it or Amazon's doing it, or whoever's doing. It's their security is going to be better than you also did in many cases that that's true because, you know, they're, they, they have more developers, they have more money, they have bigger unit that they're just it's their business.

Right. But It's your data, right? It really remains your data. And actually that's not their concern. The security of your data is, is, is not their concern. The security of their platform is there because they're concerned. And this opaqueness, you know, this inability to see beyond what the provider of the platform reveals to you via an API.

It makes it really difficult to answer. The question is, is that data in that platform? What is that application secure? Not, not from a, okay. Google, a secure point of view. Is my data in that platform secure. Right. That's I think that's a really hard question for information security managers let alone, you know, technical people to, to, to answer.

Yeah. And I think I think, you know, touching on that and sort of touching on the last comment that I made is. The abstractness of SAS applications is, is ultimately a good thing for a lot of organizations, right? You're not, you're not managing the infrastructure you're delivering. You're getting a managed application.

You're not worrying about patching a system that's ultimately going to be managed by service now or from Workday or M 365, whoever it is. But, but again from a shared responsibility model, what end customers need to be aware of is once they purchase. That instance of a SAS application. That's theirs.

They're not, they're not buying that and just, and just turning it on on day one, they're going through a heavy duty design and implementation process. And that process continues to my prior point. Right. And so it's understanding your responsibilities as part of the shared responsibility model.

Again, the big cloud providers do a fantastic job of delivering world-class security of their own data centers of their own physical perimeters of their own applications. Yeah. Where, where the, the responsibility transitions is once that customer takes that application, it makes it theirs starts adding users and adding data.

Whatever happens with that from a configuration perspective is the responsibility of the customer. Now, of course, the big SAS vendors are going to be concerned if their end customers are having challenges securing that data, or if it's constantly being exposed and we're, we're seeing a decent amount.

They don't want to see that happen. It's not good for business, but at the end of the day, it's not their liability. Right. It's, it's the end customers of those applications that are liable for how they configure these. Yeah. I mean, th and there's even like a catchphrase isn't there that the leaky buckets syndrome, which, which actually I've always thought it was a bit unfair on, on Amazon because, you know, they're not leaky buckets, they're misconfigured, right.

The, the, the, there's nothing wrong with the buckets. It's just how the, that they're being used, but that, you know, there's so many, you know, that's, that's a thing, right. But hunting for leaky, that there is software out there, but hunts for misconduct. Had lots of software out there that misconfigured data buckets.

Right. And, and I think he just, I think he just touched, you just hit the nail on the head there, right? Like the way that I think of these big, these big SaaS systems as they are, they're they're cloud-based business operating systems. Right. They will do exactly what you tell them to do. However you configure them to operate is how they're going to operate.

They're not going to sit there and say, oh, you know, you messed up this data access model. And now we're going to expose the sensitive information to the. Through through through a community portal that we're using. And one of these systems that we use for, you know, customer support, right? If, again, you know, these, these are highly complex systems and they will do whatever you tell them to do.

Yeah. Yeah. I mean, does it, does it I mean, I think it's. It's just the, to me you know, I'm very old firstly, in this kind of come around before, it's the latest, it's the latest example or one of the later examples of innovation in technology provision, outpacing security. Right? Cause I mean, I mean, even, I suppose 10 years ago, the number of people who were interesting or enterprise that you know, that their, their crown jewel data and their enterprise.

Assets and applications to cloud providers was, was, was minimal, right? It just, it, it, it didn't happen. And, and then it happened very slowly. And then as capability grew and the, the, the cost benefits in particular group, everyone does it. Right. It's just, it is just normal. Now we don't come across a customer who has no presence in SAS or, or platform as a service, you know?

Absolutely. Everybody does. And that is. You know, probably five years ago, we started seeing customers with cloud-first policies internally that, you know, that became a thing. And, and now I think most customers will do it will take a long, it takes a lot for customers to consider doing something in-house on-premise right on their own tin in their own application, in their own data center.

It just, it just doesn't happen. And security really. I think security practice and technologies haven't just, just are lacking. It's kind of a view for what I see. Yeah. I I used to work for red lock, which was one of the first players in the CSBM space. There's always, there's always this messaging that I had, which was the cloud security maturity gap.

Right. And it was the concept that at the time, early days of, of AWS and Azure is a lot of swiping credit cards, right. It was developers and dev ops folks, you know, looking to deliver the value to the business as quickly as possible. And swiping credit cards. And by the time the security organization caught up to understand what was going on.

You know, some of these deployments were mature and multiple years in, and they didn't have any proper, any real, proper security oversight. Exactly. And it's, and, you know, I think, I think it's more profound than SAS, right? Because concess has been around for 20 years at this point. Right. And if you look at the size of the market it's the S the B2B SAS market, according to gardener, Is significantly larger than the infrastructure as a service market.

Right. I think looking at the statistics, I think Gartner's predicting the SAS B2B market to be a $208 billion market by the end of 2023. Whereas infrastructure as a service is going to be about 155 billion. So you're talking about still a 50 billion per year revenue difference between, you know, enterprise SAS workloads versus.

The use of infrastructure and service, just to give you a size of an understanding of the scale of this of this, of this industry. And so we're seeing the same thing, except it's with line of business organizations or platform owners, or it teams that are deciding we are going to you know, find a more efficient and effective way to deploy.

You know, business applications that used to be delivered through the data center, through applications, traditional applications, and again, same exact concept. It's just a different team that is deploying these systems. And what we're seeing is that security teams and risk teams will get involved.

Maybe at the time of procurement, they might do a vendor risk assessment on one of the big SAS vendors. Right. They might say, okay, well, how are they securing their own environment? You know, where are there. You know, policies on how they hire people. Are they doing background checks? It's a lot of questionnaires and it doesn't, again, it doesn't do anything to address the end customers shared responsibility model or their, their, their, their piece of it.

And what we need to say is that we need to see security teams getting more involved and, you know, understanding that you know, it's very easy to misconfigure these systems and there are, there are tooling there's tooling out there. That allows them to get that same level of security visibility into these systems and the same sort of controls that they would try to apply to a traditional application, but then they can apply to SAS workloads like the tooling.

Yeah. And is that the tooling presumably has just taken a while to catch up right. To, to that, to that world, because it's so much you. So, you know, if you take, you know, say the secure by design principles, which I think, you know, everybody agrees with, if you will designing or implementing a new infrastructure, new application, the idea is that security is involved, you know, from the word go right.

The first time you put that project definition together, you have security representation. And the whole thing is built. Code to platform with security in mind. Now that was difficult to do when the data was in a big room under your feet. Right. But now it's in somebody else's opaque infrastructure that kind of a security at every step of the design and implementation.

I think he's technically hard. Right? And also, like you just said, if you've got line of business saying, well, actually this is the best application for the business, you know, for very good reasons for use case reasons, for commercial reasons, whatever it is, you know, we are deploying this application.

That's, that's a juggernaut, which is really hard to, to control, right? If you're a security person, that's, that's really hard to get in front of. So. Hang on a second. You know, we, we want to have a closer look at Salesforce, for example, right. It's, it's, it's difficult right at that stage to, to do that. So what you have to do, I guess, is control it.

Use, use the tools that you're talking about to to manage it almost after the fact, right? Yeah, it needs to be done continuously. Right? Just as you would secure your, your applications through you know, continuous monitoring, it needs to be the same way with, with SAS right there. You know, they're within a, within a typical security organization, there's not, there's not really any, you know, Salesforce subject matter experts or service now, subject matter experts or Workday subject matter experts.

Right. So even if they had the resources and they would say, we're going to train some of our resources up to be experts in these. You know, w what do they actually do at that point? Do they go log into the administrator portal of their Workday deployment and start manually crawling through hundreds and thousands of different systems settings across a very large product that can have upwards of 15 different models.

Right. So nothing there. So there's like a hundred settings just for Salesforce relates to security, security relevant just for security often. I mean, if you go into, if you look at the, you know, if you look at, go to the work, that website, you look at their product page, there's 15 different modules. If you look at, you know, if you look at a service now platform, they have, you know, they offer modules for it, service management, it, you know, ITBM it ops customer service management, HR legal SecOps.

Yeah, they build themselves as the platform of platforms. It's a fantastic technology delivers value to so many different organizations around the world. But again, for security teams to think that this is sort of sort of a simple application, that's somehow just secure by default, you know, is obviously incorrect.

And they're not going to have the resources. To to sort of spin up subject matter experts for the most part in these systems. And they're not going to have the tool and that's needed in order to get deep visibility into the configuration state. But, but then to more importantly, continuously scan and continuously monitor the application to ensure that it maintains a configuration best practice state.

You know, that's really what SSPM tooling does. SAS security posture, management. Tooling connects into these systems via via API and OAuth connections. And then it continuously scans it continuously assesses and it identifies critical and high risk misconfigurations that need to be assessed. Yeah, because that, so yeah, I mean the, the, if you were to try and scale up to do that with, with, with experts, right.

With people like, like you alluded to, I mean, that just completely negates the point of going through that model in the first place. Right. Because you're, you're, you're back to having to have massive teams of people supporting an application. Which you don't own right. Only bought. So you didn't have to own, you bought in that multiple because you didn't have to vote.

Yeah. I mean, even to your point, right? Like, you know what, say that. You know, say you had a bunch of resources and a security organization that were free to do this, which I think we all know doesn't exist. And 99 out of a hundred customers that we speak to, right. Did the resources aren't there for that again?

What are they going to do? Are they going to get an administrator login? Are they going to actually log in to one of these biz, big business, critical applications where and start making configuration changes? The fact of the matter is, is that you know, the whole concept of SAS security posture management in an effective operational model is to align.

Security and platform teams to jointly monitor the application to put controls and governance guardrails in place so that so that application teams are aware that when they misconfigure something. They know that they need to go fix it and that there's and that there's an actual audit trail that, you know, these things are taking place and that they're being remediated enough in a proper way until you think there's room for delivery, or do you see, you know, delivery partners?

Cause obviously all of the big SAS platforms have specialists delivery partners who do the onboarding and the enablement for the customer, you know, Salesforce partners or ServiceNow, whatever. Is this is SSPM it sounds like it would be an incredibly useful thing for them to have whilst actually building that configuration and deploying.

Do you, do you, do you have conversations with those people or do you see that sort of thing that absolutely. Whenever possible we want, we want customers to think about implementing security best practice from the beginning and understanding that these systems are going to. Morph considerably on a, on a weekly, monthly annual basis.

You can't do this point in time. You can't do it. You can't do it every once in a while. It needs to be a continuous process. And ideally one you implement early on. It's not the end of the world. If you haven't, you know, you can go ahead and work with work with security partners, work with MSPs, work with whoever it is that you align with that have subject matter expertise and helping you understand how, you know, your systems are currently.

Take remediation actions where necessary to get them into a correct state compliance state, a secure state, and then again, implement baseline policies. Every application is different for every customer. They all have different use cases. So when you think about implementing SSPM tooling, it's really important that there's a, there's a policy engine that allows you to write your own custom baselines.

Serve as guardrails around these applications, allow the application teams to know that they can move. They can, they can promote changes into these systems as fast as they want, as often as they want, as long as they're not bumping up against those guard rails that the business and the security organization have put in place to say, this is how the application must stay configure.

So, so almost there's a, there's a use case for, for, for, for SSPM tools that the, you know, the implementation partner uses them, sets up the guard rails as you call them. And then. Leaves that functionality that ongoing continual functionality of the SSPM with the customer would seem to be the kind of responsible thing to be doing.

That's absolutely one model. We see our security church, traditional security partners and cloud security partners, delivering these services to our customers as well in the form of risk assessments, remediation work you know, managed services, right? Where, you know, the application is obviously going to be monitored or be maintained probably by the application.

But from a, from a security perspective, making sure that, you know, remediations are taking place that events that you're detecting in your SAS, LOBs are being are being you know, triaged properly know that's absolutely a market where we see our security partners delivering valuable services to our customers.

Cool. Well, look, Brandon, I think we're just about out of time, but that's been incredibly useful, so thank you very much for joining me. 
 
It's a pleasure. Thank you so much for having me.