Backing Up SaaS Data – Francois Lopitaux, Odaseva
Francois Lopitaux, chief product officer for Odaseva, explains what makes backing up data stored in software-as-a-service (SaaS) applications so challenging.
Transcript
This is Textron TV. Hey guys. Thanks from the throw.
We're here with Francois lapido who is Chief product officer for odessiva and they are in the business of backing up SAS applications, which turns out to be a little more challenging than most people realize friends while welcome to the show. Thank you very much. So we have seen this massive perforation of SAS platforms.
And I think a lot of people just assume some are that magically that data will be protected. But once you get into the notion that you do need to protect that data, it's a little more challenging than people realize maybe walk us through a little bit. If you would once required to protect data in these ass platforms, and where are the conscious?
Sure, no, definitely and so just some words about odessiva. So we have been in the business for 10 years now and we are our mission right is to protect and secure such application and more specifically Salesforce. So this is where we are really focusing on and this is coming exactly from what you say, right we early on at got customers.
Let's move from on-premise world to assess application and the presume that actually, you know, everything was magic and that the SAS provider will protect him against any issues even like their own mistakes, but unfortunately, it's not the case right and that's why we are speaking a lot about shared. Responsibility concept where the SAS provider is responsible for the data and if the SAS provider is doing mistake or if having some troubles is responsible for the protection of these data. But on the on the other side, if as a user as a customer of the SAS provider.
I'm doing mistake. I have a system. That's a wrong integration and going to delete information into the SAS providers.
I'm responsible for that. And that's where we call it the share responsibility and I think that now more and more people take understand this Concepts and take decision to invest in the backup solution for the SAS providers. But for a very long time this hasn't been the case and the second point with the SAS, I think and this is why you know, we spoke about the API is in the on-premise world.
There's a backup was actually great and simple, you know, you add your hard drive. It was in your infrastructures. It was a database.
It was a five system you were able to simply just take a copy of that put it somewhere and in case of incident you just restore it, right? But with the SAS application is a completely different story because you not have access directly to to the system. You don't you cannot like do a straight backup dump of your Oracle database, right?
That's where you have to to play with the API. You have to play with the API provided by the size application to be able to run this this backup. And also you see the restoration because you know, the value of the or of that is ready to be able to protect and be able to restore what you have.
Change and so the fact that you don't have access to the DB you have to go through the API and this API. Of constraints right? So the first one is usually because we are speaking about SAS applications.
We are speaking about the fact that you are sharing in fractures with other customers, right? It's a concept of multitudinals, which means that every SAS providers are put in place some limitations to be sure that one one person is not going to eat the resources of the other person in the same environment. And so that's the first aspect of it you need to be able to you to be aware of this limitation.
And when you are running Mass operation on your data to be able to protect them you need to be of cautiousness of these limit and then you need to create a system that respect this limit and understand this limit the second one I think also is the fact that this API is that you got are not Unlimited in terms of resources. It means that you may have different API for different needs. and so if you want to optimize your processes to be able to have the best restore point objective and the best restore time objective is really to be able to optimize the speed and for that again, you need to be sure that you are leveraging the right API to have the fastest process to be able to parallelize the right API and finally Once you get all your data in the right way, you need to be able to store it and restoration again, it's not like simply adding records inside the database right?
You have constraints. Then you need to take an account which means your restoration process need to be pretty smart actually to be able to end all the different neurons of your SAS applications. How often does this happen?
I mean people perceive that the SAS applications are always available. But is it more common people think when there's an issue around a crash or something becoming unavailable? Yeah, I mean the actually you will be surprised you will be surprised.
You know, it's all the time. You think that is never going to happen to you. Right?
It's somebody else's shoes. But actually, you know, we have a lot of customers and it's it happened. Right?
It happened more than you think. It happened for multiple reason, right? The first one is you have a lot of Integrations right that you connect to your first applications.
Usually, you know company may have like Android one of 20 application on the SAS that they are using every day. So they need to connect them to each other and then each integration can actually go sideway. Yeah, you know go a little bit, you know in the wrong direction and then correct the data so you need to you need to restore so other issue is just people right people wax as a system who may like do have wrong things delete the files modify wrong files.
And again, it's happening or like a developers that is just running a process. On the data and it was thinking that he may run this on the development environment, but actually by mistake you use a production URL and you run it on Productions. So it's actually happened all the time.
And that's why we are here for our customers to be sure that when it happened they can go back on their step pretty fast. There's a premium too now on recovery because usually if there's an issue, sometimes it involves ransomware or something of that elk and a lot of organizations you're trying to get that data back as quickly as you can but do they realize that those apis may be throttled and that becomes an issue because I guess my question is is how long does it take to recover? Yeah, no, it's it's a great point.
And I think that even you know, even with speaking about the time to recover, I think one notion that people really need to be aware of is. How how much data are you ready to lose? Because for example when you do a backup, right you all the time have a frequency of backup which makes sense.
So let's set you are doing a daily backup daily backup means that even if you have an incident you very much are ready to lose one day of that. And you know sometimes one day of data for certain customers, maybe okay for some others if you think about customer service support, right? If you are losing one day of interaction with your customers, this is not really acceptable.
If you are if you are using one day of leads that come up to your applications AS application. This is not acceptable. So I think the first step before to think about the speed of restoration.
It's really about to think about how much data are you ready to to lose and then based on that you will specify your backup frequency. So, you know, you can daily for hours one hour. So for example in our case with our customers, we offer down to 15 minutes, which means that the maximum of data you are going to lose is 15 minutes, but then obviously back to your questions about the restoration the speed of restoration is obviously a key requirement and we we run some servants 74% of people in general and not our customers but survey of the South application 74 take more than one day.
And again, it's all based on your business, right? How long can you wait to be able to restore this information? But also I think you leverage and you highlight but to run somewhere right?
We're on somewhere. So we ran a survey pretty recently and so we find out that actually 51% of the ransomware targets as applications. Which is actually pretty pretty high and so the worst number actually is 52% of these attacks are successful, which means that people using SAS applications.
They may likely be eat by ransomware. So this is where obviously a backup application is very very important. And you know what?
We saw also on this survey is actually 50% of of these people do not recover this as application if they don't have a right protections, so I think it's a really thread there that again I think that a lot of companies are starting to really be aware and take action on that. But I think for business it's really really important. How do I know that the malware that attacked me in the first place isn't in my backup copy as well.
And so how do I kind of Ensure the Integrity of the backup? Yeah, I think it's a it's a great question. And I think that there is to answer to that.
The first one is you should separate the two systems that's not of use but it's really important which means like your backup system and your SAS application. Should not be on the same platform should not be provided by the same person because obviously you are increasing the risk that if the person is able to attack your main SAS application and get access to your SAS applications. They will be able to access in the backup because it will be on the same system.
So I think rolls words number one is really about be able to separate your backup from your life system. Rules number two is and this is what we have put in place is to be able to have your irreversibility into your system, which means that once you create a backup that even if the person access the backup information that they cannot alterate this backup. So even if the malware integrate your life system cores the data that your backup system you cannot change the backup that has been done in the past and this is what we have implemented into December to ensure that your backup system cannot be corrupted by malware and the second point that also on this area that is really important I think is it's about and encryption of the data.
So the fact that when you are doing a backup system, obviously you are taking over all your information from one system to another system. So you are going to move from your sales provider to your Banker provider, which means that you need to have exactly the same level of security on both sides because they are going to contain the members the same data, but also when you move on your backup system, it's really important to separate the person who have access to control the backup. And the person who have access to be able to see the data.
So to be able to do that, I do that save up. For example, what we have done is we are encrypting our backup with a key a key on only by the customers. and this separation of of responsibility is always people who have access to the backup system.
To not be able to read the data because it do not own encryption key. So it's like a third layer of security if that makes it. Good, um who's in charge of backup these days given ransomware.
Is it the typical administrator for the SAS platform or the security people getting involved? I think that this has been actually one of the reasons why people were thinking that SAS, you know were doing this capabilities is For very long time status as being more like, you know owned by the ghost it of the company like the business unit have a need they don't necessarily how on top of the list of the IT department. So they may start to use a product and obviously these are not experts in it, right so they are not experts in the fact that they need to backup the system because our primary business users maybe a customer service or sales or marketing, right?
And so the fact that this has initially speaking has been more owned by the position. It was a reason why the issue but backup came but now more and more these days. Obviously the IT department is more owning globally is a test application of the Enterprise.
So I think the it's really moving these days from before being really owned by the business unit in in the companies moving more like to centralize IT department, whereas now, you know, more control and holistic view of all the system and I think that one thing We see with our largest customers is usually they have created also some kind of Accenture of Excellence. So even if it's owned by the business is that quickly the center of excellence that kind of like bring is bringing like it skills into the mix to be sure that there is governance around all this applications. So it's part of that movement towards what we call sasops.
But how hard is it to set up the data protection for all these different applications that are out there. I mean do I have to be a rocket scientist or can I be a mere mortal? Yeah, I mean, I think it's all depends.
What solution you are you are going for right what we can see with our customers is some customers. I'll deciding that so some customers are deciding that I'm going to do my own system. I'm going to leverage API myself directly.
And usually this is not really handing really well because again based to the fact that the SAS API are really complex that they have hardly meet that you need to manage a speed that you need to understand how you are going to restore and you know, the Nitty Gritty about that the do so the build yourself kind of approach is not really working then if you go for a SAS backup vendors, then usually it's it's really straightforward to be able to implement now. I think that what people underestimate is the fact that I think a backup in place. Is is really important of you see but being ready when you need to do restore is also extremely important.
And so that's why we are for example on our side. We are training our customers to be able to really with the restoration to be able to run some auditing tools to be able to inspect their sense application to be able to be sure that they are going to remove every safeguard that are going to block them to be able to restore. Francois thanks for the insights.
I think a lot of people probably thought this was a lot simpler than it is and maybe somebody else was gonna do it on their behalf. But as always has worked to be done. We hope to have you back in the show again one of these days soon.
Thank you very much. All right back to you guys in the studio.