Well, good afternoon, ladies and gentlemen, or good morning, good evening. Independent on where in the world you're currently located. Welcome to another copy call webinar. And our topic for today is cloud data protection done, right? When bringing your own key, just isn't enough. My name's Alexei Alexei Balaganski. I am the lead Analyst Analyst at call. And today I am joined by Mr. Elmar Beck CEO, founder of a Perry, and this webinar is supported by his company. Okay. So before we begin just a minute to talk about Cooper, a call who we are actually are, we are an independent Analyst Analyst, Analyst company, headquarted in Germany, but having quite a global outreach from us to UK and Europe, of course, all the way to Singapore and Australia, we were founded 14 years ago and S then we were focusing so on various aspects of information, security, identity management, governance, risk management, and compliance.
And of course we can offer you neutral advice and expertise in all areas concerning the digital transformation. And in our job, we are supporting both end users. This companies, corporations, system integrators, and of course, software manufacturers, our business areas are, can be divided into three merger pillars. We are doing Analyst research that is, we are studying the market trends and we are writing and publishing various types of vendor, neutral reports and advisory papers. We are doing events ranging from free online webinars like this one today, all the way to major international conferences, what kind physical events, which attract hundreds of participants from all around the world. And of course we provide advisory projects for specific companies, helping them to achieve success in their it related projects. Speaking of events, or I would like to draw your attention to three of major events. We are planning for this year and studying of course, with the EAC, the European identity conference identity and cloud conference, of course, which will be held this may in Munich for the 12th time already.
This is our largest and most well known event we expect in over 800 participants this year. Then of course, we have a series of smaller events or kind of focusing on a consumer identity, very important topic for now the will be held in USA in Europe and APAC at different locations and dates. And for the first time we are planning a pure cybersecurity oriented event called it. We call it leadership summit to be held in Berlin in November. So, yeah, Europe definitely find more information on our website. If you guidelines, yes, you are all muted central. So we don't have to worry about your microphone. We will record this webinar and we'll publish it, the recording on our website tomorrow, and we'll send each attain the link to access it directly. We will have a Q and a session it's end of this webinar, but I encourage you to start entering your questions as soon as you have them during the course of the webinar.
And you can use the questions box on the go to webinar control panel on the right with your screen. As usual, our gender is split into three parts. First, I will start with a general neutral introduction of the challenges companies are now facing when they move their data in the cloud. And they have to secure data for various obvious business compliance and it reasons. And then I will give stage tool, Mr. Elmar Beck from a API who will be talking about more technical details and best practices in case studies around the transparent data encryption for the cloud. And he will reduce the concept of the transparent encryption gateway and talk about the advantages and challenges the solution have. And as I mentioned earlier, we will have a Q and a session at the end. So let's start directly with my favorite slide, which I try to use in nearly any of my webinars.
This is how a typical corporate infrastructure looks nowadays because the older people still fondly remember the times 20 years ago when the it infrastructure was all behind the heavy and penetra network perimeter. But unfortunately those days are lost now and both the users and the devices, and whereas other types of smart and not so smart things which logically belong to your corporate infrastructure are no longer behind the perimeter. They are anywhere in the world, in the cloud, in your manufacturing plant, it's your partner's office, or maybe just somewhere in the Starbucks, somewhere in China who knows. And all this data flowing between those locations still has to be protected. Still has to be monitored somehow, and ensure that it's not compromised or leaked or lost in any way. So here your data, especially if you are adopting this hugely popular cloud source strategy is no longer going to your control.
And yet, yeah, well, some people think some companies think that the benefits outweigh the risks and they probably right, but you also have to remember that those risks are very, very numerous. So I'm not going to go into much of the details in the about this slide. Actually, if you are interested in learning more about cloud specific risk, you should watch the recording of a webinar. Excellent webinar. My colleague Mike Small has done recently. You'll find it on our website. This is just a summary of risk search companies around the world. Typically recognize as being directly caused by adopting the cloud as a strategy. And in red, I decided to mark those which have, which are directly related to, to the data, your information you have to protect.
And of course you have to remember that cloud provider will not take care of all those risks for you, any cloud infrastructure, any cloud provider, no matter where in the world they are, they operate on the same shelter. Responsibility model cloud provider is responsible for security of the cloud. And the customer is generally responsible for security in the cloud. And you can see that four different cloud models, the responsibility is shared slightly differently, but in any model, you as a customer, always responsible for protecting your data. And although GDPR is not actually today's webinar topic, but always just over months left was a dreaded deadline. The March 20 piece, everyone is talking about GDPR. And on this slide again, I am not going to talk a lot about the GDPR. We have a lot of webinars. We have a lot of webinars in the past, and you will find all the recordings, either just a summary of what actions you actually have to perform to try and reach the GDP compliance.
If you notice of these six action areas, at least five are directly related to protecting your data. Yeah, sure. Your personal, rather personal data of your employees or customers or whatever, but quite frankly, GDPR is a great best practice to start thinking about all of your data sensitive. If you want to be compliant in future, future proofing, your compliance just have to be a little bit more flexible with classifying your data. All right? So let's have a quick look at what technology is actually available for keeping your data protected in the cloud. As you can see, there is quite a lot, our data protection in the cloud and especially in the hybrid cloud environments is extremely complex. And it's involves a lot of functional areas, which are although slightly overlap, but usually kind of addressed with a totally different products or even totally different technologies. So you can see that, or yes, you definitely have to keep your data safe in the sense that it should not be accessible to.
It has to be it's integrity has to be protected, but it's definitely not enough. You need some solutions to ensure that only people who are authorized to see the data actually access can access it. And that unauthorized leakage are prevented and that your privileged accounts cannot be abused and that your human but privileged accounts like your CFO is not somehow silently fallen the victim to, or a C fraud scheme. And of course you have to protect your data against lots of different threats, be software vulnerabilities or malware or web related threats or anything else. You have to kind of keep track of all these technologies. And of course, to do that, you actually need to keep track of all your data. First, you have to discover it. You have to classify it. Somehow you have to constantly monitor its huge, and you have to prevent employees from abusing unauthorize cloud services.
And finally the plus, but not least you have to stay compliant, especially when you think about GDPR fines being up to 4% of your annual income at non-compliance quickly become extremely costly. So yeah, there's a lot of technologies are, but today we are talking about encryption. I kind of tried to mark those encryption technology, right? And tokenization of course is related to encryption as well, and probably masking to integrity protection, but still, or today we are talking about encryption. And as a side note, I'd like to say that many users seem to confused or they seem to not to understand the difference between those hugely popular case B solutions, the cloud security brokers. Yeah. They, they totally deserve the huge popularity. And I actually tried to mark the functional areas, this shade of green, as you can see, there are totally different boxes. We have no function overlap with encryption solutions.
So you need both and you actually have to think about solutions that can play well together. But let's talk about it in detail somewhat later. Again, let's talk about encryption. Usually three different functional areas are, are identified when we're talking about encryption. The first thing, the easiest one is encryption of data in transit. Many people just say, well, we use SSL everywhere. So we, we are probably safe, right? Or not exactly. First of all, I would like to mention that SSL is actually an outdated duplicated protocol. And if you are talking about encrypting your data on the network, you should actually start thinking about TLS, which is a new generation of transport layer security protocols. And of course you always have to remember are the risks of implementation error, not all TLS or solutions are created safe. And sure you could think about using the free open source, open cell library, but you remember the hard bleed problem, which played us a couple of years ago, which caused huge headaches for it.
Administrators around the world. It actually still not completely addressed. And of course you have to remember that. Not everything, not every data you keeping the cloud is accessed or HTS. Sometimes you have to use other protocols as well. And lots of them like FTP will tell it are totally unsecured. So you have to culturally replace them with secure counterpart. And again, most simple example, when you send, when you send an email, it won't be encrypted to be Taylor or whatever. So you have to think about application level encryption whenever possible, as well as a huge part of the data encryption and transit. And of course you have to enforce encryption by explicitly disallowing UN encrypted on your firewalls. The next area is encryption at risk. This is probably the biggest one and the most complicated one in terms of, or rather the most complex one.
So here, many people think that, okay, every cloud provider says they have transparent disc encryption. So we are covered. We are safe again, not really since that this description only prevents data loss. When someone breaks into your cloud provider's data center steals the hard desks. It's not really a security solution, small like a compliance measure for your cloud security provider. And of course, whenever you are using encryption, you have to, again, remember of the risks of implementation errors of big CERs of back doors, whether they are mandated by government or sneaked in by hackers or, and probably my biggest message for you in this area would be never, ever trust proprietary in homeit encryption methods. Encryption is difficult. Encryption is extremely difficult to person, kind of spent, spent over six years learning mathematics in the university. Let me tell you that coming up with a decent encryption method on your own is a huge undertaking, which is something which no single person could probably ever rich and validating that, that your encryption method would work as well as a standard one.
It's even more difficult. And of course you have to remember that different types of data are encrypted differently. At least when you're talking about structured data like databases and unstructured data, like your file stored somewhere on file server or online storage services, they require totally different approaches. And of course, application encryption is even a one step higher in, in the cost and difficulty of implementing it. But again, with all the, with each step kind of along this graph, you getting more threats, covered more threat factors and finally encryption in use. This is probably the least understood area of encryption. It kind of rotates around the notion of working with your data without encrypting it and really for layman. And even for some it, especially, it really sounds like some kind of magic because yeah, I mean, ideally there is a thing which called, which is called homomorphic encryption, which is exactly how it's supposed to work on theory.
You have two encrypted pieces of data. You apply some calculations to those pieces of data and you get the result, which is also encrypted great idea, lots of academic research, almost no practical implementations yet another area which kind of tries to position it as a encryption use solution is secure and or trust computing or however you can call it confidential computing. Sometimes this is a approach when you, you still have Toree your data, but you only do it inside a especially protected execution environment with additional kind of hardware in software based methods, ensuring that nobody on authorize can actually peek into that secure container. Again, it's, it's a great idea. And it's currently being rolled out by several large cloud providers, but it's definitely not yet ready for on the different cloud models, especially not for software as a service model. And finally, probably the most popular one.
And the most marketable approach is so-called format preserved encryption. This is an notion of, of encrypting individual fields in your data like columns in your database or form fields in your SAS application, encrypting it by still trying to maintain the original format. So a number would be encrypted into a different number. A text string will be encrypted into a string of the same length. For example, the credit card number will still look like a credit card number only with differents. Again, this is probably the easiest method to implement, and this is probably will be the solution of most providers will try to sell you, but it has multiple significant problems. It's obviously weaker than traditional blockers because a lot of compromises have to be made to maintain this format preservation. And although it kind of, it preserves some application functions like you can still search by search sort might be, or, or, or validate credit card number, even if it's, but it's still, but it'll break other functionality.
And, or more often than not, vendors have to incorporate additional weaknesses to address some compatibility issues with popular online services. And of course, otherwise they only support a very limited number of those services. And of course you have to remember that your data, your encrypted data is only as secure as the keys, which we use to encrypt it. And here we come to probably the biggest source of snake oil being pedaled around the cloud. Now they bring your own key concept. So on this graph, you would, you can see several steps or from the least secure to the most secure one, several methods of handling your encryption keys. Obviously the low, the lowest, the least secure one is when your keys are managed by the cloud cloud service provider. In some software, whenever your keys are managed by your cloud service provider, it's essentially as having no encryption at all because your keys are exposed to third party.
And that third party can, for example, be hacked and it can be a subpoena to give, to handle your keys to government agency. And when that agency slips a get order on top of that subpoena, you will even never know that your data has been leaked somewhere. The next step, which was kind of a popular product few years ago, and still is sometimes is putting your keys into CSP managed hardware security model. Yes, your keys are much safer in that module, or you have a better compliance. You have a fully full audit trail of all accesses to your key, allegedly, but then again, you're still handling a copy of your keys to a third party. So you're not really much secure than that.
Actually, you don't even have your keys. I mean, your keys are handed by your provider completely. The next step in this, bring your own key idea that if you create your own key, you, you keep your original key safe in your, your own hardware security model on the premises and only give a copy to your cloud with provider. Then somehow you are supposed to be secure. And again, if you think about it, as soon as you give a copy of your encryption key to anybody, you lose control over it. You never, you can never be sure what happens to your data or when your key is given to someone else. And you only, oh, basically you only have to trust your CSP. There is no other way. Finally, recently, for example, companies like Microsoft has introduced a step above, bring your own key, which is hold your own key.
And until it sounds great, you keep your original key or in hardware security module on premises. And you don't give a copy to your cloud service provider, but anytime you CSP wants to decre some data for you, they actually call you over secure line and unlock your key and use it to decrypt. The data sounds great in theory, then again, although it does address certain compliance requirements and maybe a couple of a not of over of security, you are still not in full control or of your keys. The only way to maintain the full control of your keys is stick to the zero knowledge approach. Zero knowledge mean that nobody else, no third party, including your cloud service Porwal ever has a copy of your encryption key. And on the next slide, I will try to explain the advantages and disadvantages of this approach. So the advantage is obvious with an end, with a truly end to end encryption, the plain text data actually never leaves your on premise network.
You encrypted yourself and only then you upload it to the cloud. You are the only person having the only copy of your encryption keys. So with that, you actually automatically address most of the GDPR requirements because again, so nobody besides you can ever get advantage of the data, even if it's stolen from the cloud, because it's, it, it never left it. It never came to the cloud in an encrypted form. And of course it it's the ultimate defense against, or government surveillance and legal challenges. As I mentioned earlier, unfortunately, this approach does have a couple of major disadvantages. First of all, of course, if you lose your key, you lose your data. So you have to be especially careful about keeping it safe and, or of course, or if the data in the cloud is always encrypted and the cloud service provider has no way to decrypted SAS application just won't work anymore.
So obviously full and full enter encryption is can never be made format preserving at least in its traditional form. And only you keep your, your keys and on encrypt data and home that the logic of the cloud will somehow sort it out that unfortunately doesn't work. This is why for years to encryption was, was mostly used for keeping a static data in the cloud, for example, for backup. However, there is hope there is this technology, which called transparent encryption gateway. This is basically, ideally, I'm not saying yet, yet it already works like that. You will have to of find proof for that from the vendor, but ideally such a gateway could combine the strength of end-to-end encryption, the convenience of transparent encryption solution and the compatibility of a format in one. So in a way, it'll be something like this to mythical creatures, iron, or the egg lane woo, and milk producing pig. The only question is do such creatures actually exist. Let's find out and that I will know what to Elmar Beck for his part of the presentation.
So thank you very much, Alexei a for this great introduction into cloud data protection. So first of all, I won welcome to everyone in this webinar from my side. My name is Emma peri Beck, I'm founder and CEO of a Perry. This is a German it security software company that is mainly focused on cloud data protection solutions. Our software, the repair gateway is a zero trust security solution. As Alexei Alexei say mentioned that before for databases, for files and also for applications, especially in the cloud. So fundamental to our approach is that the principle that everything in the cloud is accessible by everyone and could be compromised at any time. And only encryption can from our point of view, preserve someone from using, using this stolen data. And that's exactly what our solution does. It's encrypting and tokenizing data with the highest degree of security without the need of change for clients or servers. So your infrastructure stays completely seamless. And also the user has a complete seamless user experience.
And additionally, our customer use our platform for meeting the GDPR compliance requirements, regulatory compliance requirements, and at least protecting sensitive data. For example, PII data, personal identify data. So I would like to structure the next 20 minutes in a way, like, first of all, I would like to highlight the two, perhaps two key takeaways from the presentation of Alexei a then with three slides, I would like to have a short introduction to the gateway that, you know, what is this great, how yeah. Echoing Mishal stuff that we are providing and at least, and this is will be the focus for the next 20 minutes, introduce some customers and best practices we are focusing on. So, first of all, one key takeaway the one who has access to the, your cryptographic keys, that's the one who has potentially access to data. This is exactly the permit that has been shown from Alexei a before and highlights it.
And, and this simple sentence, you always should keep that in mind because it's very important that this simple sentence is very true. And you can map that again, everything someone is telling you. The second key takeaway is that no one is really able to prevent data theft, but the per gateway is able to prevent the usage of the stolen data. So if you read the newspapers day by day, there are new makeup breaches. There are new things happening. We, we read every time about data that is stolen, where highest security degree of security is provided from these companies. But nevertheless, data is stolen that's effect of life. So how are we dealing with this? How are we working with this? The per gateway acts as a single point of control for data protection and encryption management behind your firewalls on the left side, the user internal external users, then the per gateway sitting asset behind the firewall in your parameter.
On-prem, it's a software solution. So it also can resist in the cloud. It also can be hosted by a cloud provider. So partners, for example, are offering this as a hosted solution and then data is transferred into the cloud and back, how is this happening in detail? So first of all, you call vanity URL because the, a API gateway acts as a proxy, transparent proxy. In fact, it's a reverse proxy forward proxy, like your configure it API proxy. And then this data is intercepted by the per gateway. Data gets encrypted and tokenized. There is a token database, a token vault encryption key management could also be an HSM of course, where keys are management a secure way. And then this data is transferred to the application. For example, Salesforce or whatever, and indifference to SSL, where SSL as a transport encryption would open up the data stream and decrypt everything.
The data itself stays encrypted on the cloud provider side. And even if there are backups, even if there is unrestricted access from a hacker, or if there is unrestricted access from the cloud provider itself, he's not able to see any kind of data because the data itself is encrypted or tokenized. And the way bank is just in the same way, data is transferred to the encryption gateway to the API gateway and then transferred to the user and the user receives these data seamlessly. So he has access like before, and this ensures that data controller has the sole control over the encryption and the tokenization process. And it acts really like a transparent layer. So you don't have to change anything in on the client side. You don't have to install there anything. And even on the server side, no need to install anything, no need to change there, anything.
And this is important because our zero footprint in the cloud helps us to really have a, a wide spread support of different applications. And it offers a seamless user experience to the client because encryption itself, you can make many mistakes as Alexei a mentioned, definitely, but it's much more than encrypting the data because then you would lose a lot of functionality from the cloud side. What is important from our side is that you really have the ability to get different or to preserve the most important functionalities from the cloud application, because that's why you want to use that application. So, for example, let me give you one example, handling search. If you encrypt data, of course the cloud application is unable to search anymore because instead of the name back, for example, you just have an encrypted string like X, Y, Z. So the cloud application will never ever find Beck or something like Beck.
And what we do is the API gateway. The software keeps the, the data, an internal index. So everything goes through the API gateway as mentioned as a transparent layer. And so does the search query. So the user enters the search query like before the app API gateway gets the result, identified from the index, sends that to the cloud provider or to the cloud in encrypted manner. An encrypted format gets back the results set decrypted and shows it to the user. And that means, for example, in office 365 asset, it's a seamless user experience you have, for example, in outlook, in the right above corner, you have your field to enter your search term. You use that like before, and you get the results set like before, without any difference, because logic is provided by the per gateway and all the logic that is normally provided by the cloud providers would be broken because of the encryption that is provided by the per gateway.
So it really preserves all major important function that is, and additionally, and this is the last slide to the product is about the widest support in technologies, because it's not only to encrypt one Salesforce instance, it's not about encrypting one of a 365. If customers decide to go to the cloud, they really do this with their complete software stack, perhaps, and perhaps with a couple of more product. So what we do provide what the per gateway provides is support for databases. So relational databases like SQL server, Oracle, IBM DB two IDB. It provides support for cloud applications like office 365, Salesforce exchange SharePoint a lot more and even custom applications, custom web applications, and also file level support. So F three OneDrive, web dev shares, you name it. All of these technologies are supported, and this is something where you can rely on, on the technology.
And I would like to now dig into our customer base some of these, and also on best practices. First of all, customers, when we talk about different customers, we have, it's not only a focus on healthcare or banking or public sector or industry. It's just a set of functionalities we would like to provide here. So from the healthcare sector, for example, SIM this is a Europeans leading company for laboratory services. They are around the globe with around about 10,000 employees right now. And they are, they have a high security data center protecting their solution or a data center with our solution. Provin made aviation doctor company, Raj. We have Doche bank, for example, where they encrypting their Salesforce instances. We have UUs bear. We have bank for which are just given a slide overview in the public sector. Also federal police of Germany who are using our solution to protect their data.
We have with ETAs, a company from the public sector using office 365. Why are they allowed to use it just because of our solution? Because all emails, entries, tasks are encrypted prior sending it to office 365. So an offer 365, everything is encrypted. Additionally companies like Ivan since one, about 11 years now, Deutsche Telekom uses us very, very spread broad across their environment for a lot of different things, for example, Salesforce, but also for customer applications. And, and, and so there are a lot of companies, and this is just a set small subset of all of our customers. That to give you an impression on where we are located, we are focusing on enterprise customers, mainly that's the area we are dealing with. So let me now get into the best practices. What are we doing? One of the best practices is telecommunication from the telecommunication sector.
It's a company with one of the biggest Salesforce installation in Europe. So they had the problem that they wanted to go to Salesforce. And it was a line of business, selecting Salesforce as their provi, their major tool to use for their CRM and the CSO. And the management literally stopped that go live just because of cloud security. They had a lot of concerns because of corporate data security and how our data really secured inside the cloud environment. And they are, are quite special because of paragraph 203 criminal code. So they were not allowed by law by compliance and by their it security team to really use the cloud. And that is a scheme we see in a lot of different areas. So nowadays a lot of it systems are only available as cloud server. So for example, think about recruitment management software. There is more or less no software that you can use on-prem so there is no alternative or Salesforce, it's a cloud only solution.
So in this case, what we did is that our solution was installed as a proxy as always for all users and centralized data protection policies for encryption tokenization of sensitive data was applied. So Salesforce function was not impacted. They were able to use really everything they wanted to use without having to install as said anything on the Salesforce side, anything on the cloud client side, the customer side, and in this case, for example, and this also perhaps important to know, and because it's, it reflects a best practice. Most of our customers to have, they do have run about one to 10% of data that is really encrypted. So most of the data, 90% and more is kept completely unencrypted because it's not sensitive. So for example, in this case, we had all the PII data, personal identifiable data. These data should be protected wherever it is.
And these were run about 10% of all the data that were in there. Then another best correct is from the public sector. Public sector likes of course cloud services because it's not their major business. And they would like to use much more of the cloud businesses, but they're not allowed to. And in this case, we offered organizations, Microsoft office 365 in the cloud. So they were able to use the standard Microsoft office 365 that is provided from more or less all over the world. And that concern were really who has access to my data, who would be able to see that data in case of a compromisation or also if someone forces Microsoft to hand over data. And what we did is that again, our solution was installed on their local governmental office are also non-prem installation from the apparel gateway and all emails, all Calandra entries, all tasks were encrypted prior, sending it out of the power meter and sending it to Microsoft office 365.
So in this case, even if someone, or even if Microsoft would be forced to hand out data, this data would've been encrypted and unreadable for someone and in the future, they will even use much more function from our solution. So for example, SharePoint, they can also define on which level, level of a site collection, which data is encrypted or OneDrive, for example, that shows clearly which folders contain sensitive data. So also don't have to encrypt everything. You, you can have a real selective encryption also on a mobile box level, whatever to show which data is encrypted in which space unencrypted, then another topic automotive also very common and very typical scenario from our customer base. This was a worldwide forecasting application from this customer, and they're working around about 100,000 users with this application for the global forecasting. And it's running a dedicated data center on-prem and Microsoft said, well, we, if you would use that application with the power of the cloud and inside Microsoft Azure, you could really get down to smaller amounts because as of today, they need 18 hours for their forecasting application to do the calculations, and they did the POC, they tested it and they got down to one hour.
So this is near close to reality. Tremendous. So the business side was really attracted from that solution. And guess what the CSO said, well, sorry, I can't sign that off because you are not allowed to start this amount of critical data inside a cloud platform where we are not in control of everything. So what we did is our solution, again, install OnPrem, encrypts, all the sensitive data. And only with this solution, the customer has the full control of the security, meaning the cryptographic keys only the customer has access to the cryptographic keys. Only the press customer controls the encryption process. The customer is able to define the sensitive data, what should be encrypted and how, and all needs it systems. You can think about a really broad area and that needs to be supported for these it systems. And we were able with our solution to import, to really support all these systems, another best practice, what customers are doing banking area again.
So what we have is a financial service provider. Who's issuing credit cards and testing data is always a hassle for them because credit card data, for example, is not just a 16 digit random number. There are specific codes inside there. You have to take care how to generate these credit card numbers. So-called loan algorithms that is used there. And so there were not able to have real test data as they wanted to have. But on the other hand, they have very strict legal requirements. For example, P C I DSS how to work with credit data. So they were not only allowed to use real data inside their test environment. And for them test data generation from original data, there needs to be a real flexible encryption and tokenization method. And that is exactly what we're providing. We have a template system, so more or less XML files where you can define what in the data stream should be encrypted and how or tokenized and how with regular expressions, for example, you can define what are the different token tokens that are generated.
And we additionally have people inside. So business process, execution, language, something like a workflow definition, how these data should be generated. And at least you even can insert Java code and say, well, please execute that Java code during a runtime to generate these credit card data or these kind of PII data, or this kind of special numbers or whatever you do have this kind of flexibility was needed. And additionally, they don't only have a database or a file. It needs to be comparable. And that is what our solution provides as mentioned for web applications, databases on a file level soap and many other external data sources. So literally any external data source, they need it. And they also have host environments DB two on a host running and whatever. So a lot of special things we said, yeah, no problem. And we have, we're able to prove that our solution was the only one.
And they were looking for two years for a solution really that is able to handle these strong requirements also because our solution meets the PCI DSS requirements for tokenization solution. So there they're allowed to use that. And again, the customer, this customer, and all other customers are able to really individual configure, configure the data and how to encrypt these data. And at least, and last one, one example coming from the industry sector IOT, one of the leading producers of E cars with around about 180,000 employees, they wanted to move onto Europe with their car, but the car is sending tons of data into a cloud environment. And of course these are PII data on the one side and also data that is very, very sensitive. So it was one of the requirements from the government to get the allowance, to have that car in Europe, to really encrypt, reliable, encrypt all the data before sending it into the cloud or more or less before it is started in the cloud.
This was a project done also with the Microsoft Cloudland. And what we did is all the data were encrypted prior, sending it to the cloud provider. And that was fully compliant with all data protection laws that existed, that were needed to get the approval, to have that car there. So that was, first of all, my best practices I would like to, I wanted to share with you, and then just two remarks. One thing has been mentioned before GDPR, you hear a lot of stuff around GDPR, and I have the feeling that literally anyone who has something to do with it, security now says you need our solution because of GDPR. So it seems to be a very good buzzwords these days. Nevertheless, what we do is we have requirements with GDPR that we, as a par and the Perry gateway fulfills it's centralization, it's privacy by design it's ization of PII and sensitive data.
And this is exactly where we would like, or we can show you on concrete examples, how our customers are using that to fulfill the GDPR requirements they have today, because not fulfilling this, this non being non-compliance means you have to hand run about 4% of your worldwide annual turnover or 20 million, whatever is higher. That could be your penalties. You have to pay if you don't fulfill it. And also one remark, it's not only about German or European companies, GDPR affects all organizations that are processing data of you citizens. So that's, first of all, what I would like to share you with you, what I wanted to share with you, and I'm now happy to catch up questions to answer them. And I think Alexei say you will manage that process. Right?
Right. Yeah. Well, thanks a lot. It's very nice to see that mythical creatures actually not just exist. They actually are herds of them Rome in across Germany and probably also outside as well. Yeah. We have quite a few questions and interesting ones as well, but let me start with one, which is probably you probably get a lot just to kind of get it off the table. So how is your security measure? Is your security solution different or better than those, which some companies already offer like Salesforce shield, for example.
Yeah. So you, you mentioned it before in, in your introduction, it's all about who has access to do keys. And when it's about solutions provided by the cloud provider, they have a different focus. They make sure that data on rest is encrypted. That's for sure a very good solution and very important, but they are not able to have an on-prem solution and they don't have an on-prem solution where the customer is in. So control of the encryption process and the keys. However, for example, concrete field, because it's questioned, they have a lot more functionality. So a lot of our customers, for example, Dr. Bank, they are using both, they are using on the one hand shield because it offers also user tracking. It offers a lot of more security solutions than only encrypting. And they have a, in your mind, you can have a pyramid of the data of sensitive data.
So there is, for example, 1% of the data that is really, really critical. You should encrypt it with the highest degree of security. So customers are using our solution. Then there is run about 10% of data, perhaps 9% of data that is also very critical and this critical data should be also encrypted with the highest degree of security. Then you have run about 50% of data that is at least not that critical, but you wanna protect it. And that is where these cloud provider security solutions step in, where you can use these kind of security solutions, additionally, and then you have perhaps 30% of solution or of data that is completely unimportant for attackers. So you can leave them UN encrypted, and then something also, you mentioned the encryption algorithm. My last point on that take, because that means the highest degree of security, no form preserving stuff are things where you really, really lower the, the encryption and at least you need the highest degree of security.
Okay. And I guess, or kind of follow in or upon that with actually the next question we have, so a per security functionality can be used or in parallel the cloud provider, offroad security measures. They do not conflict. They can be used because without any problems. Right. Absolutely. Okay. Okay. Great then. Well, we have a long list already. Okay. Very interesting question. I have to admit, I have never thought about it myself. So let's find out. So let assume or a customer uses your solution for a few years has lots of encrypted data in a certain SAS function, and now they want to move on to a different one. Do they have to decrypt the data first in order to kind of export it and input it back into different cloud application or it's a safer way to do it? So
First of all, yeah, very good question. And the question of, how can we get rid of APA if we need to, is something every customers asking because APA is not a randomware we gives the customer has access through keys. So the customer is always able to decrypt it and we just gave go one step further. The basis of our solution is provided as open source on our website because we don't have to hide anything about encryption and how we do it. So the customer is always able to decrypt the data he has. First of all said that the question here in this particular case is quite also very good. We use only standard algorithms like AEs, like RSA or tokenization is also something where we rely on standards. That's very important for P C I DS for PCI DSS, for example, and other standards, you have to keep these standards. And if the other security solution you would like to use are a custom made solution or whatever you do find also supports these standards. Then of course you can seamless switch without the need of decrypting and encrypting it again.
No, I guess what the question actually was about it. Like, suppose you want to move from Salesforce to a different CRM solution and you into different CRM solution without actually decrypting it in the cloud first. Is it possible?
Ah, okay. Yeah. Also good question. Yes. Yes, it is absolutely. That's how customers are using our solution. So for example, a scenario where you have Salesforce on the one hand with encrypted data, then you have a marketing cloud also with encrypted data and offer 365, for example, for sending out or receiving emails, no need to decrypt any email or any content in between only on the customer side where the authorized person is sitting there, you have to decrypt the data. So you can send the data. For example, onto office 365, it stays encrypted through marketing cloud, through Salesforce, through whatever. And if you then download the data with a report, for example, from Salesforce then, and only then it gets decrypted.
Okay. So yeah, the answer is yes, it's possible. Great.
Yes. And also through databases, that is where, why I showed this example with test data generation, the same algorithms, the same keys, tokens are used in databases, applications, and files. So it's completely seamless over all of the needed technologies.
Yeah. The kind of, kind of follow up nicely to the next question. So what are the requirements for the cloud website to implement your solution? I guess there are no requirements.
There are no special requirements. It must be a protocol that is based on HTTP for example, or an open protocol. So if it is a protocol where we don't know, because we are sitting in the data stream and the per gateway identifies data encrypts that data decrypts that data. So the data traffic must be analyzable, but nowadays we, we have always standards that are used there. And also if not, most of the things like, for example, if we talk about SAP, they have a lot of custom protocols like eye docs, Bies and whatever. And even these kind of special protocols are supported by the APA gateway. So you can, we can support there literally anything where we know the format or the customer knows the format. So there's no need only for APA to know it. Even the customer can work with the APA gateway and defined what should be encrypted in the data stream because in some cases, remember custom apps, custom web applications, for example, only the customer really knows how the protocol is spoken between the system.
Right? So again, that kind of follows nicely to the another question. So is it possible to use it with the customer applications developed by the customer himself though? Not to standard up? So yes, it's possible. And I guess something which you probably have not mentioned kind of explicitly enough. So the whole point of this universal gateway that customers themselves can create those XML templates to support any application and
Right.
Maybe not, it may not kind of alignment task, but it's definitely possible or I've seen Aion so we,
Right. Yeah. Yeah. That is a very big difference to competitors. For example, we don't have a monolithic software and if there is a change on the cloud side or wherever, then they need to re we need to reprogram it. We separated the definition of what should be encrypted and how that should be encrypted completely from the software of the API gateway. So this is in these so-called templates, resisting on Excel files, resisting or being part of people, Java, whatever, and the customer partners of APA, for example, IBM T systems and others. And also the customer itself is able to maintain these,
Right. And by the way, kind of shameless blog. So if you're wondering where have I seen a connection that because I had to write a report about the product and you will find it on our website, along with some other related Analyst Analyst research for cloud security and beyond. So please have a look on our website. Okay, next question. We still have some time left. Where are those template files actually stored and who can access to them?
So these template files, if the customer has a solution running OnPrem, then they are running OnPrem. If the customer uses our gateway in the cloud, then they are on the cloud. But the most important thing is that these templates are on the critical data inside. These templates are also codesign. So it's not a easy, or it's not possible to really change these templates. For example, to make a definition like everything should be unencrypted. So it's in a secure environment and in this secure environment of the gateway where these templates are stored with a signed format there.
Okay. Right. Next question. Is, does your solution work with other security tools? Like for example, Cisco web security?
Yes. So you have on your slide currently, something like cloud access security broker, we name our solution, a cloud data protection solution because it is only a part of this cloud access security broker stuff, meaning a cloud access security broker. Normally you have a different focus like the per gateway. It is more or less for, or for an environment where you don't have the control on what should be encrypted and how that should be encrypted. So we work with a lot of cloud access, security brokers together. We work together with HSMs. If you have an active directory and all of these security subsets, you always can work with the per gateway. There's no need to have everything inside the per gateway. You don't need additional security solutions, but if you do have these, then you can work with them together. And most of our customers use them in combination with DLP solutions with yeah. All kind of different solutions.
Okay, great. And we have our final question for today's webinar. So all those best practices you've shown earlier, they're all like huge enterprises, but are smaller companies out of luck or can they still afford your solution? Yeah.
Yes, of course. They also are welcome. Most of them work with partners together and perhaps they even don't know that they use the per gate page. So for example, Doche Taylor systems, they are hosting our solution. So they even don't need to install anything OnPrem. They can use it via this angle and partners are providing the service there. So yes, they are also welcome. However, most of our companies are enterprise customers because they have this strong need for our technology.
Okay. Well thanks a lot. Or I think we don't have any, okay. We actually have a couple of questions left, but I'm afraid we are running out of time. So anyone who has more specific technical questions, please contact either myself or Mr. Beck, our contacts will be available in the presentation. So again, thanks a lot for taking part in another call webinar. Thank you, Mr. Beck, for very interesting presentation and have a nice day.
Thank you very much for attending. Bye.
Goodbye.
