Bringing Data Back Under Control

Good morning, good evening, or good afternoon, depending upon where you are, and welcome to this webinar, Bringing Data Back Under Control. My name is Mike Small, and I'm a senior analyst with KuppingerCole, and I'm joined in this webinar today with my colleagues from ShardSecure, Pascal Cronauer, who is head of EMA, and Julian Weinberger, who's the field chief technical officer.

So, as regards this webinar, you are muted centrally, and we're controlling this. You don't need to mute or unmute yourself. We will be running some polls during the webinar, and we can discuss the results during the Q&A. The Q&A will be left until the end, but there is a question panel in the GoToWebinar panel, and you can ask questions at any time using that. And the webinar is being recorded, and both the recording and the presentation slides will be made available for you to download in the next few days.

So, we're going to start off with a poll question. So, how would you best describe where your organization's data is held and processed? Is it mostly in your organization's own systems and data center? Is it evenly split between your own data centers and public cloud services? Is it mostly in public cloud?

So, we should be running the poll. Okay, so, the poll is now completed, and we can discuss the answers to this as we come to the end of the webinar.

So, in this webinar, basically, we're going to start off with me talking about why it is that, why you need to bring your data back under control, why you need to bring your data back under control, and then my colleagues from Shard Secure will describe their cost-effective approach to data security. And then finally, we'll have some questions and answers.

So, what's behind this problem? Well, the problem really comes from digital transformation, that as we have got more and more powerful computers, as we have got greater and greater connectivity, it's become easier and easier for organizations to collect and exploit data. And to do that, in fact, what happened was that we needed to use some new approaches to it.

The traditional IT system was very slow and difficult to change, whereas cloud services were agile and allowed you to quickly implement business-led change, that the DevOps approach that has typically been involved in cloud is very flexible and easily adapts to business needs, and it's very responsive, that if your idea, if your application, if your new business model takes off, because of the just-in-time nature of the cloud, everything can be expanded quickly.

And this compares with what it was like with on-premises systems, where you would have lead times and massive capital expenditure to deal with. So if we look at this, this is great, but in fact, it has led to three major concerns that organizations have, and these must be managed. Top of mind for many of the organizations is failure to comply. And we will talk about an example of how that has happened, but I think all of you have come across examples.

The second thing is that compliance failure often follows a data breach, and the more you have put your business-critical data in your cloud and hybrid systems, the more damage it does if you lose it, and the more likely it is to be data that is either intellectual property or personal data or some kind of regulated data.

And finally, you're more exposed through this, since digital transformation tends to have done away with many of the basic processes and manual systems and paper systems that you have, so that if you can't get at your IT systems, for example, through ransomware, then you find that your business has closed down, which is not good. So a lot of people believe that if they encrypt their data, then they're done, that encrypting your data is in fact going to protect you.

And I think the Capital One Data Breach, which many of you may be aware of, illustrated how this just isn't true, that encrypting data protects against certain risks, but not protect your data completely. For example, what happened in the Capital One Data Breach, which was running in one of the major hyperscale cloud providers, that a misconfigured web access, web access firewall allowed the wrong kind of traffic through to the backend, where it should not have been able to get from the internet, which allowed command and control.

And command and control was then able to exploit the excessive privileges that were assigned to a VM, which allowed that VM to access an encrypted S3 bucket, which contained the data. And the result of that was compliance failure and a large fine. So that was encrypted data. And there are many different scenarios that allow you to get that encrypted data. And typically, that is why many of the attack vectors now involve theft of credentials, because once you get credentials, that tends to allow you to simply overcome encryption.

So we've all now got data protection paranoia, because data and protecting that data is actually fundamental to securing your enterprise and complying with rules and regulations. Now, it's interesting that one of the other aspects of cloud is that compliance can, in fact, or failure to comply can deny you access to the data that you hold. And this has all been crystallized through this Shrems 2 judgment, which came from this gentleman Maximilian Shrems, who was an Austrian legal student, who didn't like his data being shared in the US by Facebook.

Now, basically what this elucidated is that, that in order to comply, it is not sufficient to simply say you have a strong contract with the provider, because local laws can override contracts. And you need to take technical measures to deal with it. And as an example of the draconian nature of this, a European census agency, the Portuguese one, was given 12 hours notice by the local data protection people that they had to desist using a cloud service, which was based in the US, which is not good for your business.

Now, if you look at this, why should you just be concerned about the personal data? Because if you think about it, your business depends upon data. And is protecting the personal data sufficient, or do you also need to protect your business data?

Now, there are not many examples that you can produce specific references to, but here is a court indictment in the US alleging that the Chinese People's Republic Army were in fact trying to hack business data from the US. Another concrete example of that was some years ago, RSA, the security company, were hacked. And the result of that was the secrets for their security companies, or their secure token system, were stolen. And it is reckoned that this cost them $70 million in order to rectify. So business data is also critical. So what is needed is zero trust data protection.

Now, zero trust has become one of these words, but it's a good word, because it basically means that you really have to make sure that you are taking care of your data everywhere, whether it's in transit, whether it's at rest, or whether it's being processed. And all of those areas need to be protected. And it's up to you to ensure you can't simply trust that your cloud provider, your data processor is looking after it. So as soon as you hand your data over to a third party, it's potentially at risk. So what are the solutions to that?

Well, you can actually look at the recommendations from the European Data Protection Board in response to the Shrems 2 judgment. And these apply not only to personal data, but they're good advice for everything. So if you're going to process your data out of your control or hold it out of your direct control, you can use encryption. But encryption is only good providing you look after the keys and you hold them and keep them secret from the exporter, from the system to which you export it. Pseudonymization is another way of dealing with this.

That is another form of encryption, which potentially allows processing once encrypted. And finally, there is this other thing called split processing, which we're going to talk about in more depth in a moment. So let's just look at encryption. So encryption is really good providing you manage the keys. And the first thing that will happen is that your cloud service provider will say, hey, we look after your data because we automatically encrypt it.

But that fails the test because you don't have control of those keys and either somebody could steal them from the service provider or the service provider could be forced by local laws to hand over the data through giving away the keys. So what you need to do is to make sure that you still control the keys and that if you're going to do this efficiently, it means you're going to store your keys in a hardware security module, which gives you tamper-proof security. But managing those keys remains a risk, as does processing.

So unless you process the data in a trusted execution environment, then there is a small chance that it could be stolen because there are RAM snapshot tools that will be able to seize data while it is being processed. The second approach is pseudonymization.

Now, pseudonymization is another form of encryption where the data is transformed into a form that looks processable, but supposedly cannot be reconstituted. And that's good because if you do it correctly, you can actually do it in a way that will be processed. But on the other hand, there are lots of weak ways of pseudonymizing data and lots of tools out there that claim to do it, but can easily be thwarted by having some kind of extra information. So pseudonymization is another approach. And the final approach is fragmentation and dispersal.

And this is an interesting approach, and I'm going to ask you to look carefully at the graphic. So the first thing that happens is we have a little piece of data, and what we're going to do is we're going to divide that data up into lots and lots of fragments.

Now, I've put colors to show the fragments. Now, clearly, in the real world, we wouldn't divide them up into words. We could even divide them up into sub-byte elements. But this is to illustrate the idea. So now we've got those fragments. What we can now do with the fragments is we can send those fragments, different groups of fragments, to different places so that in any one storage system, you don't have the complete set of data. And you can do this in various clever ways, which means that you can recover that data providing you have enough of the different copies.

So it gives an added element of resilience to this. It also has another remarkable side effect, which is it is incredibly difficult to crack. Whilst there are various algorithms that have been known to attack encryption algorithms, actually being able to unfragment data is very, very difficult. So when you look at what this means, you can see that cloud service encryption is never sufficient for what your data is in the cloud. Customer-controlled encryption gives you, is okay, basically, for cloud storage.

And it only works with software as a service providing you are able to bring the data back in order to process it if you've got control of it. Pseudonymization supposedly deals with everything, but in fact, there are few strong pseudonymization processes and they tend to be expensive. But encryption plus data dispersal gives you the best of all worlds for all of the use cases except software as a service where it may or may not be useful. So encryption plus data dispersal is a technique that you really need to think about. Another consideration is what's known as perfect forward secrecy.

Now, this is the idea that if somebody steals a copy of your data today, then would they be able to decrypt it using a much more powerful computer in the future, or if they could get hold of some more information?

And with the advent of quantum cryptography, quantum computing, this is becoming a thing that everyone needs to consider because quantum computing is proven to be able to decrypt certain kinds of algorithms such as the RSA algorithm, which is based on being able to factorize large prime numbers and to do that in very short periods of time, which with conventional computing would have taken millions of years. So everyone in this potentially post-quantum world needs to think about what data do you have and how long do you need to retain it?

How are you going to be able to meet your regulatory requirements in this post-quantum world and start to build yourself a plan? And this has a post-quantum cryptography project, but it's interesting to note that distressed and fragmented data is not considered to be at risk from quantum computing because it is not fragmented according to an algorithm that is easily decrypted using a quantum computer.

So with that, the summary of the challenge that we're meeting here is that organizations have gone through a process of digitalization, which is increasing cyber risk, business continuity, data breaches, and compliance failures. That businesses depend upon this data in order to function and the consequences of data breaches or other forms of attack are essential. That you need to respond to this by taking a zero trust approach to data protection, never trust and always ensure that your data is protected everywhere.

And the new game in town that we've been talking about here is data fragmentation and dispersal, which provides a uniquely flexible solution to the problems that I've set out. Now, we've got a second poll here and perhaps Oscar can start the poll off so this poll is, what tools and techniques does your organization use to protect its business critical data? And you can select multiple answers to this. So do you use encryption where your organization holds and manages the encryption keys? Or do you rely on service providers encryption? Are you using pseudonymization or anonymization?

Or are you using some other form of protection? So thank you everyone for voting. The more that vote, the more we will be able to tell you at the end. So thank you very much for that. I'm now going to hand over to my colleagues from Shard Secure. So thank you. My name is Julian Weinberger, I'm field CTO and I'm in the field every day and we see the challenges Mike has mentioned.

On data, we've seen that data is really the center of the attention nowadays and therefore you have different stakeholders with the data and they have different pain points, right? Like Mike said, a lot of the data pain points are actually around security. Like how do I make sure that my data is protected no matter where it's reside or it's computed or where I really deal with it. But there's also a decent amount of stakeholders for example, in the infrastructure team, right?

They wanna make sure that the data is accessible, the data is there when you need it, the data is backed up, there's ransomware coming along, all of those issues. But then you also have other stakeholders which are seeing data as a benefit like machine learning professionals, right? Business intelligence, the more data you have, the better. So they got a lot of data and see information from it which creates another issue one way or another. All of those data in the end also needs to be stored somewhere. We are seeing data retention policies go up, right?

You need more data, we're processing more data. So we've seen that a lot of those different things kind of get out of control and people are trying to get ahold of it. And obviously if you throw compliance and regulation frameworks in it, everything becomes even more complex in that specific scenario. I would love to get in what Shards Secure does to really address those challenges pointed out by Mike and how we can help you to actually do that. So let me click ahead. So I wanna dip down on what Shards Secure does to really protect the data and how we can help it.

So Shards Secure has a very easy way of implementing data protection. I think a lot of the mechanism Mike has said have been around for a while. Fragmentation has been around, pseudonymization has been around, encryption has been around forever, right? But it can be extremely tricky to implement. And sometimes we as an industry, we implement stuff and it becomes another pain point. And we are really in the business of not, we're solving a pain point, not introducing a new pain point. So we make sure that the data protection is really easy. It's easy to implement.

It's transparent to anyone who uses data. It's very important because if your users or your applications don't work, you don't get business out of it. You still need to work. We do have an agentless approach. That means in the past, a lot of data protection was like you need to install an agent on your end device. And then you all of a sudden end up with the pain point of managing that agent on the end device and then capabilities and all of those things. So we make it very, very easy to do that with basically an abstraction layer approach. I'll show you in a bit.

And that opens up a lot of opportunities to really easily adopt data protection. But really the main focus is keep the trust of the data. You as a data custodian, as a data owner, as a company, it's your data. You should be in control no matter where it lies. That's especially important if we talk about data in a third party or hosted in a third party, like it is in the cloud, right? So if you currently have, for example, a file server on-prem, it's fairly easy. It's your file server, it's your admin doing it, right? You pay them.

All of that is basically under one umbrella and you can usually have a higher level of trust. If you move this out to a third party, if it's a cloud provider, if it's a service, whatever it is, this trust becomes very tricky.

And also, as Mike mentioned, there are some compliances which really actually does not allow that. TREMS 2 would be one of them, for example, which gives you a lot of headache if you put European data into an American cloud provider, right, that needs to be attacked and we can fairly easily do that. When we protect the data, we don't see it only as encrypted pseudonymize it. We also wanna introduce very basics of the integrity and availability. No matter which security event you've ever gone through, you've heard about confidentiality, integrity, availability, and it should be there, right?

Your data should basically protect itself to a certain level and that's what ShardSecure does. I'll show you that in a bit and how exactly we do that so it becomes a little bit more easy to understand. So ShardSecure for organizations is basically an abstraction layer which sits in between your applications, your servers, your endpoints, basically whatever reads and writes data and wherever your data is stored.

So a lot of the difficulties with the basics of data security or data protection comes in exactly on like, how do I protect the data before it gets stored there and when it's stored, how do I protect it there? So this approach makes it very, very easy to implement because neither your things on the left side nor the things on the right side need to be aware of it. It's all transparent, right? So it looks the same for them. They all can do their regular tasks, but the data is protected.

So when data is created or written on the left side from a server application or whatever it is and then stored, we introduce basically data security. So we fragment the data as Mike explained, we can actually fragment that into multiple locations and we protect the data before it even gets there. It means it will always be encrypted before it even gets to the storage location. That's very, very important as soon as we talk about the cloud, right? You wanna make sure that none of your data is necessarily in clear text exposed to any of a third party.

I think one of the main benefits of cloud secure has always been that this is a very easy approach, but it's very tricky to make it performant and we have basically little to no performance drawback on this. So if data flows through from left to right, right to left, right to read and write, we introduce almost no performance drawback or none. In our production customers, none of them actually experienced any performance drawbacks, which is great because you have a security algorithm which introduces data security you need nowadays. It's easy to implement.

So no one knows that it's there and from a performance, it doesn't introduce a hit. So you're pretty much in great shape on what it really is. Very important here, since we tackle the data before it even gets to storage, that really helps with all those issues you have around cloud adoption and where do I put my sensitive data if it's in a third provider, a third party provider like it is with Shrems2 and GDPR, as Mike mentioned. So I mentioned initially that we don't only protect the data from reading, so that's basically one. We introduce integrity and availability.

So long story short, we sit in between, therefore we know what the original data is and we also know after we fragment data up where the data is gonna be. So basically it means we have complete control and can introduce all those mechanisms to the data for you as a customer, right? So if there's any kind of unhealthy data residing in your storage, that could be, for example, a ransomware attack hit you. That could be someone accidentally delete something that happens probably the most to all of us. It could be because you have someone there's data tampering going on, right?

All of those issues which are more related to not the confidentiality of data, but more to really, is it the real data? Is it what I need? We detect it and then we self-heal. So what does the self-healing mean? It is basically a mechanism which pre-assembles the data when you read the data. So an application server or an endpoint would read the data and wouldn't even know that you got affected with an attack.

Obviously, we're gonna let you know there's notifications spilled in that there was an attack and that we recovered from the attack, but it really gives you that easy way of implementing data security, even from an integrity and availability point of view. Another thing we have seen is that there's outages. So as soon as you rely on a third party, well, there have been outages on-prem for a long time.

Obviously, we all have been through it, but if you rely on a third party, their outages become your problem one way or another, right? A lot of times it's a shared responsibility model, but it's not a shared accountability model. So if you have an outage, it's still your problem. And we also help with that. So in case we obviously spread the data around, as Mike said, we fragment the data and disperse it.

And that really helps in case there's an outage in a certain provider or a certain location, because we have data spread out and we can actually make sure that we can pull data from any of the healthy source locations, if that's the case. Obviously, and I wanna point this out again, it's all in real time. So your applications, so your servers, so your endpoints would not notice anything about it. It's a very straightforward approach. If we look on how this really works and how it's integrated, it's fairly easy to understand.

So all of, on the top here, you can see, I would call them data consumers or data creators. So you have like processes that read and write data, virtual machines read and write data applications to it, microservices and containers or Lambda function, depending on where you are and which process of utilization, like one or the other, you're pretty familiar with. But they all use different storage services. And that's kind of where the tricky part comes in. So a virtual machine uses a different storage service than usually a Lambda function, for example.

So we at Shard Secure make sure we provide these interfaces to those different data consumers and then introduce the actual data security. One very positive side effect of that is that we can actually get the data and then store it in the most cost-effective way. If you've ever moved to the cloud with a lift and shift, you know that it's not as cheap as they promised initially. And one of the reasons is that you usually don't adopt native services of the cloud, which gets you a cheaper way.

So this is one of the things where we can also help you with getting a more cost-effective approach to your data and the data storage. So, as I mentioned initially, we at Shard Secure, we've looked at data and the problems it creates and really tried to cater to each of the stakeholders of data to resolve those problems. So feel free to reach out if there's any questions. So one thing we've actually noticed, a lot of times data responsibility or concern around data was up to the data custodian or basically use a company to resolve.

But then we noticed that more and more, this responsibility is passed on to whoever develops the applications, right? So we see a lot of SaaS service pop up, which are applications, which is a very tricky way to do it. And if you're a SaaS provider or you're developing applications to customers and your customers have data concerns, right? You are now responsible to addressing those concerns. And there's a lot of market drivers in there. There's like a lot of them, actually were mentioned by Mike too.

It's like, how do I actually provide things like customer managed keys or encryption rest, tenant separation, right? If you have a gun in a SaaS, that's very important. And then there's the constant change of just maintaining that, but also the security landscape. We're seeing more regulations popping up basically every month now. I'm residing in the US. I think 49 out of 50 states are gonna adopt a new compliance framework.

So you can see that you need to be very, very agile to get the same and basically make sure that whatever you build and whatever you provide to your customers is agile to adopt what comes out. Long story short, if you run an application team and you need to introduce data security to your application, it just takes basically work cycles, right? It's time and money you spend on implementing that.

So we've seen that not data security is not only a pain point for our usually security professionals who take care of infrastructures and where data resides in applications, but also the people who actually create the applications. Very, very, very important there. So if we look, why is it so complex to put in an application? That's a very simple abstraction of just creating an encryption of a piece of data. So as Mike mentioned, there's something called the hardware security module and key management. So you need to implement that.

Then every time you write or read data, you need to get a key, encrypt the data and then work the data or the other way around. So your one step becomes three steps. And then if you implement encryption, you have problems with key rotation. Key rotation is basically necessary because a key can be broken after a while. So you need to refresh the key. One of the problem with the key rotation is that if you refresh the key, you need to like get all the data and re-encrypt it or create something like a key hierarchy. So all of that becomes quite a bit of workload.

If you work in an application team, it's not easy to provide data security in your application. It's a lot of processes. And we've seen that we as ShardSecure can actually offload that fairly easy. So we take care of all the data security you need to do. Basically the key stuff, how do you provide resilience to it? How do you provide data sovereignty even? Everything which is data security. And the application team just needs to take care of reading and writing the data.

So you see, we come from like 20 point of a laundry list to literally just read and write data, which is very, very convenient for application teams to really introduce data security to their homegrown applications or if you provide them to a customer. In the end of the day, what it really does is it gets you on a higher level of security in your posture, but it also provides it to your customer and have the functionality customer wants from an enterprise level point of view. Very important here, we can also do the data fragmentation and disperse of data in there.

So all of that obviously work, but the work goes away from your software engineers, application engineers, and you just offload it to a solution, which is just basically a drag and drop and you're ready to go. So it's fairly, fairly easy. So there's two different things I wanna mention. One of them is obviously, if you're a data owner and you're concerned, we can definitely introduce that to your infrastructure. And if you have an application team, we can also introduce that to your applications. So let us know if you need any help. I'm gonna introduce it to my colleague, Pascal now.

Pascal is gonna take us home and then we're more than happy for a Q&A to answer some questions. Yeah, hello everyone. I'm Pascal, I'm the head of EMEA and I'm coming to the summary to the end for the call today and I wanna give you some highlights here and that is on the next slide.

Thank you, Julian. So we have many use cases that we support basically and that is keeping your data under control, your data safe and your data serenity. And today we've heard a lot from Julian about a special use case, file level protection about the resiliency and cost optimization. But there's many more if you're interested, you can every time, you can reach out to us.

So I wanna summarize quickly on the data resiliency part that we helping you with the cloud ransomware, even with mitigating ransomware from internally, we keep your data safe during outages you have, during deletions and being able to reconstruct the data, whatever happens there. And on cost optimization, as you heard, we can do an easy data migration, we help you with your secure cold storage migration to go into the cloud with less cost to be able to use less cost effective storage systems. And this is how we try to make your life easier and save money to make money basically.

And that brings me also to the next slide. So we are in it together. What we are trying to do is to help you with very complex subjects, but we want to support you with that, with our experience of over a hundred years in data security and data protection in our team. And also there's so many compliance requirements out there where the CISOs or the CAO from today, we knowing them, we knowing a lot of them, they're struggling right now with all that compliance things.

I mean, Doha is there, there's ISO 2701, there's GDPR, there's all, and there's many, many more where makes their lives really, really complex. And we have to reduce the complexity by that, by minimizing the compliance to their infrastructure basically, and don't have to handle anything outside their organizations. And number three, there is, cloud makes the data protection subject more difficult, of course, but we have the experience to support you, showing you how European companies adopt cloud providers more easily and faster and more secure.

And then number four is go to the cloud, easier and safer with new technology, cloud secure and keep your data under control. That is something where we are happy to help you with our experience as mentioned. So thank you very much for your time today. And I'm heading now over to ramping up. We now have the opportunity for some questions. I don't see any questions yet from the audience. And so I'm going to ask some questions myself.

Now, one of the interesting things is that Julian was mentioning that it's very efficient. Now, one of the concerns about encryption, pseudonymization, is that not only is it very computer intensive, it also increases size and various other things like this. So can you give us an idea of what the relative performance of your system is in comparison to, say, encryption and pseudonymization?

Yeah, I think it's fairly easy. I mean, it all depends. There are a lot of factors in performance. But I would always like to perform or compare how fast is it without encryption and how fast is it with, right? So if you'd look, for example, for, let's say you want to just encrypt the file, right? And a lot of times you see that traditional encryption introduces a head over from like 10 to 30 to 40%, depending on the file and how it's read. But you will always feel a performance drawback.

In our setting, we have a little performance hit on a write level, but a performance increase on a read level, which means it actually makes up for itself. So in production, you don't really see a performance hit. But really what one of the issues of encryption has always been, if I introduce it, how are my databases reacting? How are my files reacting? How are my customers or users reacting? And we don't really have the performance hit nor the requirement of rework any workflows, because that's another problem of pseudonymization, for example. You need to rework some of your workflows, right?

So if data all of a sudden is encrypted where applications think they can just read it, you need to let applications know. So there is neither a performance hit really, nor a large involvement in the way data flows. So it's very, very easy to implement and run.

Yeah, it's certainly true that one of the weak points of, for example, database encryption, is that there is always a master account with a master password that has the encryption keys and everything gets encrypted in that way. Is there anything like that with Shard Secure? So we're having a keyless approach, which means there's not really the concept of encryption keys to data. That means that you don't necessarily need that master key again.

So a lot of problems in encryption come with that master key and the way you protect it, like as you mentioned, Mike, that the master key needs to be in a hardware security module. That really is something we don't have. We use something called cryptographic permutation, which is basically a keyless way of protecting the data. So all of the head over with key management and the master key and all of that basically goes away.

Yeah, good. So how do you protect against if somebody else buys Shard Secure, that their data isn't readable by you or your data is readable by them? So our product is deployed within the customer control, means it's either deployed in their on-prem or on their cloud. We do not have access in the third party. We do not have access, right? So all of it is in there. We do have tenant separation built into this. None of the privileged admins within the actual application can read data. That's not a performant way. You define which basically process read data, only those process can read data.

So the first step is always provide the control completely to the customer. So we don't even have theoretical access to it. So that helps a lot.

Yeah, okay. So it isn't just something that does the same thing to everybody's data, but there is something different in the way it treats each individual customer's data.

Oh yeah, yeah. I mean, even if the customer would say, you would use Shard Secure and it's the first same source data, same file, same content, same day, even that would be different. There's also, there's this randomizing processes in there which really make sure that this is happening. So you cannot replace one basically protected data and just put it in a different cluster and it comes back.

No, no, no, that obviously doesn't work. Yeah, okay. So you were talking earlier on about the challenges of adapting applications. And this is true.

I mean, a lot of people sort of write an application first and then somebody comes along and says, you need to deal with encryption. So they then hack stuff on. And I mean, there are terrible things that people do like actually embedding the keys into the code. So there's potentially a lot of work involved in adapting applications to this. So just remind us how easy it is for somebody to use Shard Secure with their applications without changing them.

Yeah, I think one of the struggle that is created is that we just roll the entire duty of data security onto the application team, but we as data security professionals should guide them. And the other problem is just every time you develop something, if you've ever been part of a company developing, every process takes just time and therefore money, right? Time to get to market, time to test, evaluate. So we make sure if you have an application which reads and write data, which is every application in the world basically, we can hook in transparently to that.

So you as an application team don't need to rewrite any of your code. It just hooks in and provides those level of security. That's way easier than implementing it by yourself and then maintaining it by yourself. And I think one of the problem that we've seen now is that companies have implemented it, right? Companies have implemented encryption over the years and now with new regulations coming on, they need a new way to implement it. There's pseudonymization, human fragmentation. So now they need to reinvent the wheel again.

All of that with our solutions offloaded so the application team doesn't need to worry. And within our solution, it's just a policy driven approach of what you really want to make the data secure.

So way, way easier, takes a lot of work of the application engineers. And the end of the day makes a better product, makes a better code and makes customers happy too. Yeah. So you talk about using this to help with different providers. So can you just go over how you deploy it again? Yeah. Our deployment model is Shard Secure is run as virtual appliances in a cluster. And this cluster can reside on-prem or in a certain cloud provider or in a basically a hybrid environment where the cluster spans across multiple cloud providers and your on-prem, both of that is possible.

So all of that is still under the customer's control, right? We do not have any access no matter where it is. So the virtual appliance of course is highly secure because we're dealing with data security, but it spans across multiple ones. The benefit of that is even if you move data from one to the other, you can easily adopt it. It means like if you have currently on-prem data and you wanna move it to the cloud, you can do that as well. But it's basically virtual appliances which can be installed on-prem or in a hybrid scenario.

And does it depend upon certain virtualization environment or is it open? It's open. We can currently deploy as virtual appliances which means you need a hypervisor for virtual machine one way or another, or we can also actually run in Kubernetes.

Oh, right. So you actually run in a container-based environment. That's interesting, yes. So does it pose any specific problems if you have a containerized application?

No, I don't think it proves some problems. It proves benefits because the scaling is way easier, right? The scaling, the rollout is easier than VMs become. So it becomes a more easier rollout for your infrastructure team.

Yeah, okay. Okay. And we do provide scripts to do that automatic rollout as you would imagine it in the containerized world, yeah.

Yeah, now, so it was interesting looking at your architecture because you effectively sit, as you put it, an intermediate layer that effectively mimics the different storage systems. That's correct.

Now, what are the limits of that? I mean, you've got everything from network file systems through databases right down to sort of the data lakes that you have. Is there any limitation or does it cover everything? So it doesn't have limitations in scale, right? So that's one of the benefit because we can just put the data wherever we want and we are that abstraction layer. There's benefits, especially if we talk about any kind of replacement or anywhere where data is stored on a network storage. And that could be anything from an S3 bucket in Amazon or blob storage to a file storage.

They're all network storages in the end. So all of them are fairly easy because the concept of communicating over the network is already there. And then the only one which was tricky, especially to do that performant was locally attached storage. So what if you currently have a virtual machine which writes on the disk on the same machine? So we even came up there where we can hook in and basically display ourselves as a virtual disk and therefore easily do that and still have a performant way of doing it.

So yes, there are limitations sometimes, it depends. I mean, there's always an exception to the rule. So I would like to say it and I'm very realistic on that, but in 99% of the cases, there's no limitation on where it fits in. Databases need very fast in and output, very frequent, right? Compared to a file storage, it's like larger data sets in a less frequent way, but we tackle both of them and we're quite aware of it. So you can actually interwork with the big relational databases then?

Yes, yes. I mean, a lot of our customers have, SQL Server have, Oracle, right? All of those are day-to-day work for us, yeah.

Yeah, that's good. It's interesting because increasingly people want to use S3. It's one of the modern ways of doing it because you have all this unstructured, but not Word documents. It's sort of images and all kinds of stuff. So you work happily with S3 is one of the key things.

Yeah, yeah. So in the end of the day, we make sure we get the most cost efficient storage in it and without compromising performance, obviously. But S3 or what's known as object storage, right? It's usually the best offering within cloud providers. It is basically your best bang for the buck if you see performance versus cost. It gets you very nice performance where you don't experience a hit. And the reason why people have an issue adopting to it is because it is not a file system or it's not a local attached disk. It's a certain API. So we can also act as a translation layer for that, right?

So what if your current solution doesn't support S3 as you mentioned? We can act as a translation layer in between because we sit in between and can route the data basically wherever you want it to route to. So it's basically pretty easy for us.

Okay, well, we're sort of coming towards the end, but one really interesting question that I'm sure the audience would like to hear is that an example of a customer that has used it. Yeah, one of our customers, one of our customers is one of the largest banks in the world. They're using it for multiple reasons. One of them is protecting the data before it goes in the cloud. That was very important for them. They could not have any data in the cloud. Any clear text data cannot even hit the cloud. So that was one of the restrictions.

The other one, which was a big factor for them is protecting them. So once the confidentiality is protected, protected them from actual cloud outages. They were burned by outages which some of the cloud providers had and actually affected their business. And they want to have a transparent way of moving between cloud providers. We're basically doing that for their underlying storage wherever the data is secure. The number one use case I've seen so far in those kinds of settings are what's early adopted to the cloud is for example, machine learning data sets, right?

So you have machine learning data sets laying in the cloud which a data set by itself does not have PII, but it's a very confidential piece because it has intelligence in it. So they're protecting it to do that. And then a very common is also protecting your local file servers. So we have multiple sets of customers which basically want to prevent the file server admin from reading confidential data. And it's not only about personal data but it's also about data like IP rights or engineering plans, all of those, right? How do I prevent that? And that's another way we do it.

We basically inject ourselves between the endpoint and the file server and protect the data before it hits the file server. Yeah, that's interesting. And I think I tried to make that point that although people have become obsessed with personal data, personal data is not the whole problem. There is a lot more business data that is not PII. You talked about intellectual property, artificial intelligence, learning data sets and the whole host of industrial data that is proprietary and fundamental. With your feed, as we're talking right now we're seeing into each other's houses, right?

That's not what I'm saying. Yeah, yeah.

Yeah, it definitely, I think the world has moved on from focusing on what's considered sensitive from a compliance point of view and see what's actually business critical, right? What's business critical. Business critical is the key thing. So I think we're just about coming up to the end now. So could I ask you, if you both wanted to say some final words?

Thank you, Simon. Yeah, I'll go.

Go ahead, Pascal, you bring us home. I just wanna say thank you to everyone joining here. Otherwise it doesn't make it not possible to be here as well. And of course, I'm glad if you get in touch and we can look even more deeply into your environment and how we can help you.

Okay, thank you, Julian. Yeah, thank you so much for inviting us and Mike basically doing it with us. And I think one thing we learned and especially from you, Mike, is data security and protection is still complex. So if you need help with it, reach out. We're more than welcome to just have a quick introduction call and give you advice. Sometimes that's all you really need. And we've been through it a lot of times so we can definitely help you. So feel free to reach out if you have any questions around data security or data protection.

Okay, well, thank you very much, Julian Weinberger and Pascal Cronel of Shard Secure. And thank you to all the audience for joining and paying attention through this. Thank you. Good evening.

Thank you, bye. Thank you.