Securing the SaaS Revolution: Protecting Your Data in the Cloud

Thanks for joining, And I hope that will be interesting for you. The next 20 minutes, I just, or do I have a clock here? Perfect.

So yeah, we are leaving the network, we are going into the sales world, right? So, and we look into this from a security perspective and especially when it comes to how are these sars applications are being configured in terms of system settings, which users have access to which data while other SARS applications are being connected. Because if you think about these SARS applications, they are being used now and they are supporting core activities in every line of, in our organization, right? And for us as users, I mean, we live in these applications, it's almost invisible. They are convenient.

But when you think about that from a security perspective, that also brings actually a paradox. Because if you think about any, any measures like data sensitivity, data integrity requirements, criticality, the SaaS applications actually are part of the critical it IT infrastructure. And this is something where when we look into that, and if you ask yourself, normally SAS is not really considered or you don't spend a lot of time compared to on-premise security controls or infrastructure as a service.

So that is something what we help with on one hand to bring you a visibility and also that you govern access to these applications. But I show you once we do that, and one important thing is if we talk about data breaches, that is most of the time either because of misconfigurations or there are settings or databases which are being accessible from the outside. So there are data exposure or there are third party applications being connected, which is done by US users, not it, it is controlling that. And then there's an OSS token, and that one is valid until it's revoked.

It's never get revoked, and then it's there and someone can get it and break into that. So that is something which is where we help to bring not just visibility, but also automate the process and do that continuously. But if you look at that, and that is what I always find when, when we talk to customers, what is my responsibility when it comes to sars and what most people don't really recognize or they believe SARS is by magic secure. It is from an infrastructure level, right?

But it's your responsibility to make sure that the data you uploading there and you provide access to users, internal and external users, that you need to make sure that these permissions are correctly configured. That that system settings are configured correctly. If you go to the Salesforce big events, they say that now pretty, although they are not talking about security at all, most of the time they make it pretty clear it's your responsibility. The same for ServiceNow. So that is pretty important to understand that this is your domain you have to, to care about.

So if you think about that from a security perspective, right? So our experience is on one hand, of course, it's business critical, and I, I touched that briefly. Sometimes it is the business process, right? If you think about Workday is the HR process, or if you think about, I don't know, Salesforce is helping you in so many, so many areas these days. So this is business critical. It is complex, complex in in many, in many aspects.

I, I, I will show you that. But if you think about alone, about the con, the capabilities Salesforce or ServiceNow are providing these days, it is huge. And then they do that also for, for, for vertical. So these are complex environments with thousands of, of possible configurations. And then you have teams, so developers, architects behind who are constantly changing or adapting these applications to your business needs. So that is, that is continuously changing.

And most of the time when we talk to security people, they say, we have no visibility into these applications because we are not experts. We don't know these applications, we don't have an account in these applications. And that is something what needs to be changed or can be changed with us though. If I think back 20 years ago when I started in the industry, I used Salesforce as a standard user, right? So it was a simple web application, it was ACRM, I logged in, I did my stuff. Then casbs have been developed to actually be the proxy inwe the users and the SAR applications.

These days, especially when we think about these big applications, they are rather transformed to, to like an operational system. So you have so many access points. So I actually mentioned a few already. I said the third party apps, external users, especially when you think about sales for service. Now you open up these applications for your suppliers, for external users, for whoever, as you have these communities, which makes it pretty easy to interact with them. But think about what kind of permissions you give them to access your data.

I show have one example, which shows how that can be configured incorrectly. So that means when we think about SARS from most of the people, no, Moses may be wrong, but a lot of people we are talking to, it's like, yeah, sars, it's secure by nature, but it's just an abstraction layer, right? So if you think about what's inside sars, when we come to the complexity itself and you compare that, for example, with your operational system, your standard operation system, you have a lot of similarities. And I don't think that when it comes to NOS or the applications who are running there, right?

If you think about your endpoint, we have lots of security controls, which we have run there. Ask yourself what you do for SaaS right?

Now, pretty often what we hear is from a security perspective, if we are lucky, we are involved in the procurement process and we do the vendor risk assessment. Everyone of course checks the checks, the requirements, and then it goes over to the line of business. The application owners, they upload the data, they, they give access to, to people, and security is actually not involved in that anymore. Sometimes then they bring in third parties who do an audit once a year. It's nice to get a nice score.

But to be honest, these applications, especially the big ones, they are so, so dynamic that it's pretty, I wouldn't say it's, it's useless, but every day there are changes in these applications and you need to stay on top of that to see if everything stays in line, what the security sees as a, as a baseline and a secure, secure one. And what makes it even more difficult is if you understand one application, of course you can build that, that knowledge in-house, right?

But if you know how, how one application is has to be configured from a, from a security perspective, every other app is completely different. So that means it's almost impossible to build that in-house. So that's why we believe it's, it's a good idea to have a solution which automates that process.

Who is, so what we do is, so you actually connect us with these applications by yourself, and then you look through the security lens into these applications without disrupting the work of the application teams. But you get an understanding what, what other system settings, what kind of users do we have in there? And you then define the, the policies to the good state and then continuously check against what these teams are doing and get informed as soon as there's changing something which is not in line with your expectations. Just examples, right?

We see on the, on the org level, for example, at Salesforce, MFA is enabled, but then you see specifically for 20 admins, this MFA is disabled and they have good reasons for that. These guys don't think always security, right? It's not top of their mind. They have the business case which they need to provide, and then they do their work. But on the other hand, no one is really checking from, from a security or compliance perspective. And that is actually where we help you with what makes it even more complex is than what I always said, these attached or connected third party apps.

So these SaaS applications, I don't think that you know all of these, but we, we find lots of applications who are being connected to each SaaS app. So these interconnection makes it pretty easy, right? It's easy for me to connect my Zoom with my Slack or with my Google workspace. We as a security professionals, we think we might check what kind of permissions do I give that third party app, but most of the people don't. So sometimes then you see that they, these applications have admin like permissions, which normally you don't want to have.

And I said, if you compare that on the right side to what you do right now for SAS and in terms of security and compare that with all the other enterprise part, I can tell you that the, the need and, and a lot of companies are starting that already. They see SARS as one of the core elements like endpoints, like server security, like, like the network security to have that as part of your overall cybersecurity program. And that is where we, where we help you with. So I have one, one example when it comes to, or what can we go wrong, right?

So there's a support Porwal, standard support Porwal is a SaaS behind that, and it's there so that I as a user can actually create a ticket check, actually the, the status of of my cases a pretty simple one. And that's a UI where I can log into if we, if we look at that from the, from the access per or from the permissions.

So it's, it has been set up correctly. So the, the agents they have of course all the possibilities and, and permissions they need to have. And me as an external user, I can create my ticket, I can check and can update, but it's pretty, pretty clearly defined. If we then click on that, double click on that one and check what what actually is behind the switch here.

So, and, and run the, the source code and check that. So then we see there's a JavaScript running, and if I want to check for example, my case number, and in this case the number is 1 0 0 6 a two in the background, then this one checks the database so that it's providing me the information I'm looking for, right? So it's my, it's my, my use case or my, my ticket.

But what if you, if you then do a valid API query and just check the other use cases as well, and that's a real world example here from, from where we have attached to, you could actually get all the other support tickets as well because the API was not correctly configured. And what you can maybe see already is not just that there's a case id, but there's also the user id. So if you then run that API and, and check for the, for this, sorry, then you get also the, the user information. So PII information which have been exposed in that case.

So that's, I said that's just one example where you open your, your platform for external users for good reasons, but what can go wrong when you think about configuration and which is not overlooked by security and completely kept in the hands of the, of the developers. So this is what actually I should see as an external user that is then what we could see from the inside. So in this case, you can see what the numbers are, we could see everything. So via the API permissions, I had access to everything in, in that, in that database in this case.

So just to summarize that one right set up, what what was set up correctly, just a small part of the SARS app was exposed to the external world, dedicated roles have been created and there was no access beyond just that Porwal. So that was all good. But what went wrong was that there was a, a confusion about access control and UI visibility. So that is what I just showed you, right? So problem was there was no security change management. So that was not overlooked by security. And one of the reasons, of course was that security team didn't have the, the expertise actually to do that.

And that is what, what we provide with our, with our platform. So what was needed is, of course, first of all, you need to have your configurations done out. So what does look good, good look like? And then continuously check against that. And that is something which is when I talk about a cyber security program and what we help, what we help our customers. So when you think about that adding SARS or these big SARS applications into your cybersecurity program, what does that really mean? So first of all, of course you need to know what you have, right?

And we are talking most of the time, think about an 80, 80 20 approach. Your big SARS applications is what you should start with because that is where you invest a lot of money. That's where your sensitive data is. That is business critical. So have understand that, identify the persons who are responsible for that, right? There are always people in security, but of course there are always the application teams.

So we are building the bridge between these two groups, helps the application teams to transparently actually check what they do on a daily basis and make sure that from a security perspective, there are no misconfigurations or permissions being given, which should not be the case. So that is something what we do automatically. Then the sec, the next thing of course is have a good or know your, know your controls and know how they should look like.

That's also something where lots of customers, especially when we look outside of MC 65 struggle with because they don't even know what are critical security configurations in, in these big apps. So we help with that. We come with, with baselines, with best practices. So that comes out of the box so that you can immediately install that and use that. So that is something what you have to have because otherwise you struggle with that. Some mature customers, we see that in banks for example, they have defined their MC 65 critical controls and how they should look like.

But then the next thing is they struggle with continuously check them because then it's a question is how do you do that? Build your own scripts, how you ever want to do that with us? You can just do that automatically and continuously up to an, an hourly level so that you can constantly check these.

We are, we are our tool, sorry, as I said, collaborate with the, with the on one end with the application teams to, to make sure that the applications are configured correctly again. Then there's a second thing, which is the zas audit logs, which you could look at, of course, I mean we are used in the networks, we are used to that, right? So that we try to see behavior, bad behavior from, from attackers and then try to contain them and remediate as soon as possible.

Unfortunately, that approach doesn't really work for sars because you cannot install your sensor source as you do it in the network environment, in the SaaS application. So you are dependent on what the SaaS providers are providing to you in terms of locks. And I can tell you that was new to me as well. They're not in real time, they're always late, sometimes just one a day, once a day or you need to pay extra to get meaningful locks, but it's still a valid approach to check for activity. And that is then something which goes into your sock.

So you actually have different streams where to then feed this information into, to remediate. And then as said, the most important pieces, continuously monitor for drift and continuously really means check constantly. What are the system settings? How are they configured? Are they deviate? Is is there someone in these application teams just changing a certain, a certain setting?

And then you want to get to know about that immediately Or are there any, any users, for example, there could be a, a policy like inform me as soon as someone gets the permission in Salesforce, modify all data or if he has the ability to change or to look into one specific field or in Slack or in teams, right? If you want to get informed, let's say you have your executive group, they are using teams for internal communication, but there are just, I dunno, five or 10 people allowed to be in there.

And you want to get immediately announced about if someone else gets attached to that, to that group or as, as part of that group. So that then the, the depth of of possibilities you can actually look for continuously. So from a broken Oh yeah. Thank you. So if you think, think about our platform.

So it's, it's a, it's a SaaS application itself. So what you do first is you connect us with your sales application. So it's normally an OS connection. So we are then scanning the APIs, it goes pretty deep for, for these applications. And then we are providing you with an overview, first of all, how is it configured right now? What are the users in these, in these applications? What kind of permissions do they have? What roads are they part of? And so on. They hold third party applications who are connected. So that is the first thing. Then we help you really to build the baselines.

So how should my good configuration look like? And then you continuously check for drift. But if you want to learn more about that, we are have a boost here, right behind this wall.

No, maybe on the other side. But I have one minute left, but I want to leave it for questions and I thank you for, for listening.