A Unified Approach to Modern Data Protection

But before we begin just one slide with some shameless advertising for KuppingerCole because we have some really interesting upcoming life events for you to attend, which are focusing on different aspects of identity management or cyber security, which are totally free for anyone to participate, or you only need your web browser basically to be a part of it. And some information can be found on the slide MTO finally, with more details at KuppingerCole dot com. Our accept, if you would, for housekeeping rules or you are on mute at some sort of, you don't have to worry about it.

We are recording today's webinars and accordingly will be published on our website and everyone, even those who could not have attended today live you'll receive an email with a link. We'll also upload the slide deck with the webinar for your future reference.

As usual, we will have a Q and a session in the end of this webinar, but please feel free to submit your questions at any time you can use the questions box on the GoToWebinar control panel. Normally located on the right side of your screen. The agenda for today is somewhat different.

Unlike our most webinars, we will not have two different presentations where we'll be just talking, interacting, and discussing all the challenges and trials in data protection and explain what no longer works, what works, what kind of practical difficulties you might face when you want to apply some of the modern concepts and so on, that will occupy the most part of today's a one hour time slot. And as I mentioned in the intro Heroku, our next session, let me just start with a really nice visual flight.

I took it from a, what are you useful website, which is called information with beautiful in the chores, the scale and the number of the you recent publicized data breaches. If you can see are a lot has happened every year. We have some really messy riches, which week millions or hundreds of millions of data records and lots of smaller ones. And let this picture not fool you. It looks like it's business as usual, but in fact, in January of this year alone, we had more data leaked when it was Bridgette the whole year of 2017, for example.

So the situation is actually on a steep decline, the scale, and the number of the temperatures are rising. And the whole idea for us to meet and discuss today is like, what can we do against it? And I guess we have to start with planning, like why what's going on? What has led to this? And I would say, go to this is the reason for all this is this tiny insignificant thing. We call the digital transformation, right? Or for quite a few decades, we were promised that computers, internet and the cloud basically often digital will solve our problems. We'll increase our productivity.

We'll make it so much easier. And as you probably know, like data is the new oil or it's life, if digital and they're working, that's great, unfortunately, or you're still might call that data, the new oil, but you have to understand that you live in a world where you don't own the pipelines. And so there's a war outside and there are some crazy political factions fighting over your data risk of everyone outside is against you, or you have to protect your data in a very secure world. And these are just some of the major challenges we will be discussing today. Yeah.

And I think, I think Alexei, it's also, you know, it's, whenever there's changes, changes, create complexity, changes, create new things. And, and I think that's, what's going on.

I mean, what over time, our architectures and, and the technologies that we use to build systems and to store data there, they're evolving very, very quickly. And because they're evolving so quickly, there are new to a lot of people and therefore how to protect them is new to a lot of people. And the skill sets that we've accumulated over time may not be exactly relevant.

They're, they're similar, but they're not identical. And so this thing that you have here as cloud is the new normal is, is absolutely wonderful.

And it, it actually in the long term, in my opinion, will create a more secure environment. But in this transition period, when everything is new and we're moving from a data center that looks like X to a data center that looks like Y it creates a lot of challenges. Great. And by the way, what will you let, what seal this opportunity to kind of step back for a second and tell you like who we are, what we are, because I know that you are like a veteran developer of specifically specific security tools for information protection, right?

So you have this tremendous experience, but you have this kind of a very specific view. The whole thing with data security, I work as an analyst at KuppingerCole here, thought I am focusing on cyber security. I've been doing it for quite some time, right. As well. But I have a slightly different kind of angle looking at the things like we do not disagree on anything. Hopefully we'll find out later today, but we are, have to deal with different people. Like you said, everything you said about the cloud and is correct.

It will makes us, it will make us more secure, but only if, like, if we know what we are doing, unfortunately, even like 30, 40 years after it all started, there are still people out there who do not have no idea what they're doing and they need some basic, well, I wouldn't call it education, but like nudging to understand that the problem is actually much bigger than they might think it is. That's exactly why we are talking today about everything from the high level concepts to how we actually translate those concepts into technology and tools. Right?

Well, here we are living in a extremely insecure world and we have to deal some stuff with it. But as I mentioned, some people just don't know, I I've heard this question about like, why there are so many breaches, what are we doing wrong? So I guess the first answer to this is simply because you have too much data and you have this data anywhere inside your previously existing security parameter, maybe outside in the cloud might be in your manufacturing floor, gives your contractors and partners with your uterus working from home because they are sick.

Basically you have your data everywhere, and you might even have no idea that you have so much data. And obviously if you don't know where your data is, you cannot start protecting properly. Right. You have no idea like, and he will probably only find out about the data when somebody will call you and tell you that the data was stolen. Yeah.

I think, I think, I think you're right, that, that, you know, data is growing exponentially. It doesn't actually mean that it shouldn't okay. It just means that unless we do a better job at protecting it, then, you know, naturally if we triple the amount of data and we don't do a better job than we're going to triple the number of incidents, okay. That that's just a simple math.

And so, and so from a business perspective, from a, from a functionality perspective, from, from the way we're changing the world, we do have more data and it's good. We enable more things, but at the same time, if we don't want a triple and quadruple and 10 times the number of breaches and incidents, then we also need to grow the data, you know, in a way where we also grow the controls and we grow the protection layers that we put around this data. Otherwise it's really gonna create a mess exactly On the point here. But then of course there is another thing to consider.

Like, do you talk about information is all about data and data does not exist in a vacuum. It's always moving. It's always being transformed.

I mean, this, a picture on the flight, or just one example of how your might be moving around your enterprise, being stored, ingested, processed, or used for some machine learning for business analytics, for reporting, it has to flow between totally different it infrastructures, systems, technology stacks through API APIs, or like database interfaces, or sometimes just all our legacy and secure protocols like FTP, for example, at Emory way, it has to be, it still has to be protected.

The problem was that to you, if you cannot use the same tool to protect the data in a database, or when it's being transferred through an FTP connection, or when it's already somewhere in the cloud used for whatever deep learning, let's train six to use this month. And this is a executive, the problem of tremendous complex.

Like you have to think about each of these colored boxes and each of these technologies has its totally different security controls, access management models, maybe even the right, I mean on a totally different platform on which you have no direction control of like in the cloud. For example, when your data is not point in time event, data is life basically. And of course there are, we have to address the elephant in the room, which is compliance. Usually people talk about GDPR. I would say GDPR is yesterday. It's been like three years now after it was introduced.

And now there've been some really interesting in really large fines, but kind of, I would say that at least here in Europe, one is not talking about the second, the other kind of the next Elefant, which is so-called strengths too, which was the protocol, the recent, I think it was last year, a decision of the European high court, which basically ended in this whole U S U or safe Harbor framework. And now whenever well, a European company wants to use a cloud service or software framework, we'll just say, no, there was IEPs, alternate forms, data it's no longer legal.

If it's PII or high sensitive data, basically a European company can no longer trust the company like in Porwal or let's say a company where KWS data without additional great technical controls, which would ensure that nobody from Imperva or nobody from AWS, or let's say Oracle or microphone can access that data, unless this is guaranteed and not just legally through a contract, but also technically through controls like encryption, for example, you are in big and the troubles and you are not compliant anymore.

And I will say that this is probably like the biggest challenge European companies are now facing, but of course it directly affects all the American companies who want to deal with Europe as well. So compliance is a major inhibitor to this. And of course it's a major driver for companies around the world to adopt, to start finding the stock, not the proper way to protect their data. Do you want to add something?

I think, you know, I th I think a general, you said compliance is an inhibitor. It is an inhibitor, but like, how do I say it? Like the regulators mean, well, right. The regulators are, are looking at things and are saying, okay, we have a safety issue. Okay. We have a safety issue. How do we influence companies to do the right thing?

Like, it would be great if we all woke up in the morning and we said, oh, we really need to secure the data. Privacy is so important, but we don't. Okay. We don't because we, you know, we're driven by profits. We're driven by, you know, w we're driven by kind of the, let's call it the top line, the growth, the functionality, what we give to consumers, the notion of safety and protections is something that we should put right at the forefront. We don't always, the regulators kind of force us to do this by putting these compliance requirements.

So it is an inhibitor, but, but in a way it's always been the way that forces things to be done. Okay. That forces people to look at, you know, how to protect it.

So, I mean, you know, whether you agree specifically around this particular issue on, okay, I, I need to have very good controls over my cloud provider and what the admins of the cloud provider can do with the data, you know, is this is a secondary issue. I think what's important is that, you know, all of these compliance mandates are important. Okay. Because they do force us to invest in, in controls, in, in audit trails, in, in, in analytics that, that, that allow us to reduce the breach because otherwise, you know, we're human so left to our own devices. We will always leave that for last.

So I don't do this as a negative thing. I view this as a, as a, as a way to ensure that we make the right investments. And again, you're absolutely right. And I would never disagree with that statement. It's absolutely true.

But again, kind of when I am trying to put on our customer's shoes, I see they are, I mean, they don't have this kind of understanding that compliance regulations are written in blogs or north who failed them before. Right. And I've seen that some companies would rather just kind of stop and cancel their cloud migration product projects completely then throwing all these compliance regulations because they just don't know where to start. And this is exactly our job is to show how those legalees.

And sometimes the overly complicated regulations actually translate into tangible technology, future congest by the floor. And hopefully not forget, but at least enjoy some kind of assurance that they work. Yeah. I agree. And I think, I think it's like your job and my job are similar in that sense, because all of this creates complexity. People don't always know what to do. So your job, you mentioned before that your job is to educate people and to take all of these things and bubble it down into something that perhaps is a little bit prescriptive.

It says, okay, do something like this. My job is similar. My job is to take all this complexity and create a set of products that embed with that blueprint or that, that PA those patterns that then give you something that adheres to all of these very complex requirements, which by the way, sometimes even contradict each other, even an illegal level. Like for example, you know, I could have one legal requirement that says that I need to delete data, which may be, which may have some, you know, which, which has PII elements in it.

But I could, I could have another compliance requirements that said that I need to retain logs for a certain period of time. Now the logs themselves could have PII in them. So now the question is which one of these conflicting legal requirements like, like how do I even reconcile? So I think both of our jobs is to take a lot of this complexity and bubble it down into, you know, education, blueprints, product, things that just make people's life a little bit easier. Right. Right. And this kind of leads into my next slide.

You can ignore the actual names just to illustrate that data protection is crazily complicated. No company could ever manage to store all of their data in a single database, like a single type of database, some claim that they do. And you probably know some vendors that they claim that they can address all of their customer's data build requirements. But the reality show that it doesn't work that way. And some other windows even pride themselves, that they can offer you 15 different database engines.

And of course, each of has totally different role models, security, controls, audits, log formats, and so on and so forth. Basically again, data protection is complicated. So many different data types and formats. They are distributed everywhere on prem in the cloud, on the move. What about, but most importantly, your data is probably still siloed. So data is different. Not all data created the same, and you simply cannot apply the same tool, the same technologies to all your data, how strong your desire to do that, or maybe you can, but you have to consider a totally different approach.

So instead of focusing on infrastructure protection, that's it, for example, the set of tools, tools, secure your network, some other tools to secure your cloud instances, other even other tools to protect each of your databases. What if you could just protect the data itself? There was a guy named rich mogul who introduced this, where it's simple principles from data centric security back in 2014.

And again, because of only if they're face value, our simple data must be self describing and defining bolus different controls. You apply to effective data must account for business context. What they're waiting for these costs later, data must be protected moving between different systems totally makes sense. And those politics I've worked consistently again, no matter where your data is located, it's being processed. Great. Where can I buy something like that? Like shut up and take my money, unfortunately, unless your data is somehow like the gains, the mind do its own like Skynet, right?

Because if your data is stored in a file, how can you possibly expect the file to be so defining some other data is stored in a cloud-based database, which is only accessible through a rest API. How can you possibly expect the security point of view to apply the same way we'll have applied to the file or something just kind of doesn't connect here. Right? And we have to really, or come up with an idea of how to translate to this interesting enticing and intellectual kind of something more tangible and understandable and achievable with today's technologies.

And I believe that we have to start with discovering the data. Again, you have to understand what data do we even have on where, which data has more important, which they more sensitive, like how exactly that sensitive, because it's a valuable IP. If it's a personal, personal identifiable data, which is regulated, if it's financial data, which nobody, including the text men through their C muscular, like you, you have to decide, you have to create your own politics. And those are exactly that business context we are talking about.

And finally, you have to know how your data leaves and moves and evolve throughout your enterprise only then can you start applying the appropriate protection measures, right. Yeah. And I think, I think you're right that like the, the, the principles are correct, but you know, we, we, we do live in a very, like, we have to be realistic. Okay. It's not like we can just delete everything we've done until now and start from scratch. Okay.

And say, Hey, okay, let's come up with a different model. That's how the data itself, you know, for example, let's break up the data into pieces so that unless you have the second piece, you can't even read the first piece.

I mean, there are things like this, but, but, but, but many of of these approaches might mean that we have to start from scratch and no business can start from scratch. Everything has to be kind of somewhat of an evolution. Okay. And therefore on the one side, we need to be practical, but we do need to move slowly into those principles. So for example, you know, if you look at the left-hand side, two things, talk about policies and policies and controls are very much the key.

And, and, and, and you can start looking at things like, okay, you have the complexity of data living in all kinds of places and, and, and the different places have their own policy layers, but maybe you can create kind of an Uber policy. Okay. And the Uber policy can be translated into the individual policy layers. So that for you, the data owner or you, the application owner, you, you, you can suddenly start defining the, the notion of who is allowed to access data in a single way. And that gets translated into the different layers of where the data lives.

And if today, the data lives in one enterprise data warehouse, and tomorrow it goes into a cloud-based big data system that can happen almost seamlessly if you have those translation layers okay. Or, or, or a similar, a similar thing that I think is so important.

And, and, and, and people sometimes overlook, you know, you talk about, you know, things like policy, everybody about our back, right. Role-based access control, but there are other ways to describe things which are more attribute based access control. Okay. I would argue with some people just kind of misunderstand the whole notion of policy. Let's say policy the mean rule or combination of problem, because they're not that kind of policy is very interesting in what we are looking for are, first of all, they have to be declarative, but you cannot, you cannot call something a policy.

If it starts with the word, if right, if something, then something or else, whatever, that's not the policy opponents, they, for example, any data within our enterprise has to be encrypted.

That's the policy, that's the kind of policy we are talking about when you're talking about data centric security, and then we would have to find a way of running it like a modern one way, how to translate that declarative policy into actual technologies like correctly set up, or like, if you have like an Oracle database, it's already can encrypt data lately, but there must be some kind of control in place that actually enforces this encryption. And then periodically validates if it's still on, if not at least three of them alarm, right.

Well, this is with other policies. We are talking about policy for an Oracle database, but when you don't have a pool, Right.

And I, and I, and I would say that to be truly a data centric, you also, those policies have to be attribute based. They can say something like, okay, it's these tables in the database. It has to be any data of this nature. Okay. Any data that has these attributes need to behave like this. So it needs to be declarative and it has to be attributes. And this Is exactly where we come back to the question of classification, but you have to know what kinds of data you have. And then you can kind of include the knowledge into your policy. Exactly.

Things are so connected that you can't really look at them as like separate projects. Okay. Because if you didn't do your codification, how are you going to do the protection? Right? And another, like probably the last theoretical concept I would like to discuss today is what leads to what we are at. KuppingerCole call the information protection life cycle.

And again, it goes back to that notion that data has not just pop into existence. And the three of us in time, it always evolves. You always start by acquiring data. Maybe you bought it or you received it from an IOT device or whatever it came to be. And you have to start, we have to understand what it does, what kind of data they have, what attributes it has, you have to classify it and then sort of this whole active life. And so data is being moved around, transformed, processed, masked, or unmasked sold, maybe one, it has to be consistently protected, know different layers of controls.

And finally, this should happen consistently until the data is disposed of what's actually deleted or might be archived or some legal purposes, but there should know, shouldn't it be any moment in time where data is left unprotected. Again, we cannot trust the data to have to be self defending. We have to do it boring, and we have to do it consistently.

So this whole life cycle and on the other, from the right side of the slide, I've listed some common security, excess management analytics solutions, which you would definitely need to be nice to have like a distributed deception technologist, or there are some more machine learning, but there are, but you need them all. When you, at least you need a reliable combination of multiple controls to actually ensure that the data stays safe all the time. Yep. Okay. And I think, or maybe we can just talk a little bit more in detail about those kind of things we just do through the years. Yeah.

I mean, I mean, you know, going back to your slide where you talked about the complexity, I mean, one element of the complexity just comes from innovation. So, you know, I remember like three or four jobs ago, I primarily did Cybase and Oracle security. Okay.

Because, you know, 20 years ago, that's what we had. We had the, you know, a few database types and today the amount of innovation that exists in the data world is, is just phenomenal. And it's good.

It's not, it's not a bad thing because like you say, it's not, you know, even, even, even though some vendors would, would assert that you can do everything inside there, a database engine, we all know that if you get things that are optimized for certain things, they work really, really well. And so, and so today, you know, for example, DB engines tracks 350 mainstream data engines, okay. Databases are repositories and, you know, some things work better in relational. Some things work better in key value stores. Some things work better in, in text indexes.

And you know, the fact that we have all this technology available to us is great, but you know, for security practitioner, I think I would say it's impossible for them to understand all of the nuances and differences between, between, you know, what is different between a relational store and the four different types of no SQL stores. And, but, but, but it shouldn't matter, right? It shouldn't matter because they need to provide similar controls. Now it's gonna, the implementation is going to be different, but this is what creates some of this complexity.

So, you know, again, going back to what, what is my job? What is your job? My job is to make sure that if a security practitioner needs to go and secure 50 different types of, of, of stores for data, they don't have a problem that is 50 times harder than if it was one. Okay.

And, and, and providing those, you know, protections of the layers that you described, whether it's classification, whether it's policy, whether it's discovery, whether it's automation of insider threat detection needs to be the same across a very large, a very large footprint. And it's not just, it's not just the stores. Like if you go to the next slide, it's not just the store is it's, it's the entire fabric of our, of our data. Okay.

It's yeah, go ahead. This is exactly kind of a thing, which I would say probably like different shapes, like your customers and my customers and an analyst, because if somebody would come to me with a question, like, how do I protect my 50 types of databases? I would say, well, that's, that's not the right question.

This is, you're doing something completely wrong. Like, can we even consider that maybe you also have to protect the API interfaces between those databases.

Like, if you have 50 or a data type, there's always types, you probably run in like a microservice based cloud application and the micro service. Isn't just talking to a database, it's talking to other microservices to API APIs. So we actually have much more, many more additional problems to think about and just database security. Right. This is exactly the point where you get back and say, if you are still thinking about the infrastructure protection, you are thinking wrong. Yeah.

I, I, you know, I, I think, I think, I think, I think you're right, but, but, but, but again, it's people, you know, my wife says that people's minds evolve very slowly because it's evolution and it, I don't think it's feasible. I mean, we, we do need to go back to you. You can't rewire people immediately. Okay. What would you need us to help them?

And, and you're right. You can't just look at the store. And this is kind of what this slide is all about is that those layers of protection need to apply to every way that data is being used. Okay. It's not. So it does not protect the infrastructure, but it is there, there are still components. And people think in terms of components, they think of data repositories. They think of API servers. They think of, they think of applications. And so you need to apply those controls and policy and, and, and compliance reporting to all of these layers.

And you need to address complexity and, and, you know, you you're, you can, you can educate people from my perspective, what I am trying to do, or what improv is trying to do is provide as much as possible out of the box. So that if in the past, this architecture was simple, right? There was one application server to one database, but now it's no longer true. The data is spread around a lot of places. And the access paths to it are sometimes direct and sometimes indirect, but there's not a one-to-one relationship anymore, right?

There's these microservices which come up in down and the SAS components and, and, and so securing that very dynamic environment needs to be simple, needs to be simplified, needs to be something that the system that this, the security around this has out of the box versus like you say, go and figure out and do things at the infrastructure level.

And that's, and that's exactly what, what, what we're doing at Imperva is kind of SU you know, the tagline for Imperva, by the way, is securing data and all paths to it, not securing data, but securing the paths to access the data, because really that's what it's all about. Well, I guess that's something definitely where we kind of, well, the theory collides with practice, right?

I mean, the theory of, of the data should be self-protecting in reality while we are not there yet. So we have to reuse existing tools, but we have to use them in a smart way, because they'll just end more and more and more security layers without any just, or we all drown in basically in the end. Yes. We have to think strategically. Yeah.

So, I mean, so that's one level of complexity is just the innovation and, and, and how dynamic these things are. And if you go to the next slide, that's the second level of, of complexity is that when you look at what information production means, it means a lot of things, right? You add discovery, add codification. Each of these things break down into a lot of elements. None of these are very foreign to, to, you know, to, to what we need to do.

But, but, but it's just a lot of details. And if you, if you try to do each one of them in the different repositories and API layers, et cetera, then of course, you're going to drown in complexity, right? Because you're going to get, I don't know how many things are here, let's say a hundred. And then you have 50 stores, you know, you're never going to do 5,000 different things.

So that, that, that, that uniformity, that, that, that, that let's call it a virtual layer of how you implement policy, how you implement security, controls, how you implement classification, and then have it automatically translated down into kind of your data fabric is, is, is kind of the only way I think, to make it feasible. Right. Ideally of course, kind of the best way to reduce complexity is just kind of to throw away the unnecessary stuff. Right. The problem is that sometimes we just don't know which stuff is unnecessary. Yeah. The second worst way is virtualization.

Exactly the way it worked wonders. For example, for computing in the, in the whole notion of cloud is basically a virtualization resources because it hides complexity either some automation or maybe just by kind of delegating it to different company or person, but it still helps. And this is exactly the right way here. Automation, if automation possible and some kind of orchestration, automated policy translation with color, but was also a smile the staff needed here. But the only way, it's the way there are a lot of complexity. Yes.

And as much as we can have it out of the box, where, like you say, virtualization is similar to saying that we create a different abstraction layer and abstraction layer that we, you know, we, we can like, like you said, okay, a policy, it should be all data, all such data should be encrypted is really a statement in a very high abstraction layer. Okay.

If we can, if we can hit create those abstraction layers, then translate them down automatically, you know, then, then we can deal with complexity. Then we can, then we can allow complexity to happen for innovation sake without throwing away safety. And I think this is what it's all about. Yeah.

So, so, so really that's what, that's, what it's, that, that, that, that's what kind of the imperfect system is trying to do. We also have learned, like, if you go to the next slide, you know, this isn't new to us, we've been doing this for 20 years. What we've learned is that, you know, if you go back to your comments about compliance, you know, the, the, the problem is that in the first date orations of a lot of these things, people just did things for compliance sake. Okay.

And when they did things for compliance sake, they, you know, they just did the basic minimum with no interpretation, no understanding. And it really was a lot of noise.

And, and, and I don't think it was, it's surprising that it, the early iterations of a lot of these things, like 20 years ago, or 10 years ago, you know, there was a lot of investment and all it created with a lot of noise because it, you know, it's, if you just say, oh, let me just monitor all access to sensitive data. You know, that, that that's kind of a meaningless that like, there's, there's not enough compute power in the world to, to, or people in the world to go and review all these things.

And so, you know, what, what we really learned is it's not enough to just look at the compliance, mandated and deal with it. What we need to do is provide like real value from all of these things provide, you know, you mentioned automation orchestration, you've mentioned machine learning. You mentioned kind of be able to create actionable insights from all these things.

You know, that's what the system is all about is not just, you know, comply with something by creating a lot of noise, but creating something that can K K can actually reduce the risk can actually give you real safety. This reminds me of one company, which basically they told us, okay, we have this requirements from the industry later to kind of find all, all the vulnerabilities in our it infrastructure was they went where the best vulnerabilities kind of invested lots of effort and money in deployment. And now they have a, a PDF file is 5 million vulnerabilities.

Okay, fine. Like where do you start? Because the north point visibility only makes sense when it could have been combined with at least some kind of a risk model. Yes. Or you can always out of 5 million, you could always choose like the top hundred once where you have to deal with today. If you cannot do it, then the whole visibility makes no sense. Yeah. And it goes back to your slide where you had a visibility classification protection, where the things are so connected to each other, because, you know, classification allows you to prioritize something.

If you know that this is, you know, you said not all data is created equal. If one, if one data set is more important than another, and you have vulnerabilities around where that data is stored, then yeah. You prioritize, you start there. And so this, this is why kind of a single, a single approach is, is one that works much better than trying to do. Okay. Let's do vulnerability scans, two classifications, let's figure out policies, figure out entitlements. These things have to come together. This is what it means to me to be data-centric okay.

Unfortunately, if we can't make the data self defending exactly right now, what we could do is create a data centric approach by bringing all these things together to the data itself. I think I smell this was the right time to move to Florida. Yeah. Yeah.

I mean, yeah. The next slide, just kind of, you know, all these things tied together to the data is exactly what Imperva data security is about.

It's not looking at each one of these elements separately and looking at each one of these data repositories and API layer separately, but looking at all into context of a single data model and having as much of this out of the box so that it takes away the guesswork, it takes away this interpretation and, and just allows, allows people to go much faster in reducing the risk around the data and providing the right safety when they move, for example, into the cloud, this is really what it's all about. Okay, great. Do you want me to elaborate a little bit on this open claim? Sure. Yeah.

Yeah. It's a, I mean, it, it, again, it goes back to kind of what we've learned, like, like these systems at Imperva have been around for about 20 years, and of course, therefore, they went through many iterations, you know, in, in the past that the concept was that this is just a security tool. Okay. But you know, when you have things like security and you have things like compliance and you have things like privacy, suddenly you get a lot of different people with different requirements, right?

If you look at the, the chief privacy officer or you look at the DPO, they're going to have a different set of needs, th all, all related to the data, but, but they have a different set of needs than for example, people in the SOC, what, why, what are their needs, or what are the needs of the application owners? And so over time we learned that it's not enough to just have all these things out of the box, but we, we, we, we also have to address it in the language, in the tools, in the interfaces that all of his different people need.

And that's why, you know, we created a platform that is very open because it allows people to use their own tools, their own processes allows them to get a different risk view of the world and just, and just manage things much better rather than like, what we don't want to do is get to a point where the same fundamental functionality gets implemented three times, because once it's for security, once it's for privacy, once for that makes no sense whatsoever. Right. Right. Okay.

Here, I would like to talk again, Mike Small block for my own white paper, which I just published yesterday about data centric security, where I explained basically the same thing, which we'll discuss today, maybe in a little bit more kind of story-driven manner. And on this slide, I just wanted to include this illustration. One of the pictures from the white paper to show that, yeah, the key to data centric security today is this layer, the approach, but you have to be very careful or choosing north layer.

So if you just going to include every tool you have, you will end up with a huge Annie on with lots of players, which complicate the functionality of the brings, nothing new for security on the generate more noise. So you have to be careful because the innermost layer you are fixed when you have it fixed for you because of the problem, like the database control. So native controls, which are already in there in the core or the database around your data.

And usually you would want to have the outermost layer, very important, a tool, a platform, very focused on incident response, because this is actually what you all will have to do when you have a data breach, right? Ideally even before you have one, you have to deal with it as quickly as possible. And you need some tools to, to make it happen as smoothly as possible. What do you have in the, in between those two layers, it's up to you. And on this picture, I just saw one possible combination.

And I explain like why we have selected this particular ones in the white paper, in a tool, be linked somewhere in the later slides. And we'll probably get a link after the webinar as well, particularly you, or you have some freedom of choice, but again, this has to be very careful, carefully, strategic and implant choice. It will work regardless, but if you want to hire it, work of the most optimal way. Yeah.

You need a strategy or you need to look around just mentioned for a solution, which at promises to do, to deliver this out of the box, then again, they would trust the vendor just kind of faced where you learn more about the capabilities, ask three questions, or refer like a neutral third party, like KuppingerCole for example, for additional advice. Yeah.

And this and this and this last slide, kind of a, it goes back to what you said before, where, you know, you can't just look at the repository and where the data lives because you have API APIs and you have, you kind of have everything coming in all the way from the edge, through the different layers, into the data.

And, and, and so I, you know, I, for example, I'm responsible for the blue side in this slide for all of the data protections, but I can tell you that the whole reason for Imperva's existence is to provide a single platform that covers everything that covers all the access to the data.

And so when you look at our investment in, in, in API security, okay, w we just acquired a company that does very advanced API security because, you know, the, the modernization and the, and the, and the transformation everybody's going through, what it's doing is it's, it's, it's creating, you know, more opportunities for, for attacks, more opportunities for leaks, because the paths are getting more complex. And so providing everything on one platform, you know, allows us, for example, to understand how the data is being used across a very diverse stack. Okay.

Because if we, if we have controls at the API layer, if we have controls at the application layer, and we have controls at the data repository layer, and they're connected to each other, then the context is very valuable, right? You can, you, you can't know how data is being used at the API layer, unless you understand where this data came from, what the lineage of this data, what is the classification labels around this? So having this all in one platform is, is what makes this journey into cloud and digital transformation, just so much safer.

And, and really that's the, that's the Imperva platform. Yeah. That's a really kind of interesting because I mean, most people knowing Porwal basically for the green stuff, right. Cause this is where it has started a little bit, fewer people know the purpose of application security, but basically it all works toward the same goal. Right.

I mean, PPI, but like both protection, but what about the application for what had nothing to do with the data or they do, that's exactly why you need to protect all the parts with the data, right? The essence of data centric, security. Exactly. Exactly. Okay. And that's just, actually, I think our last slide for today, we can now take questions. And as I mentioned, there are some useful reports which are, couldn't look up on our website, plus that KuppingerCole dot com including that white paper I mentioned, and please feel free to ask questions within the tool.

And in the meantime, I'll just kind of scroll through some additional slides in the, my ground to address the very first question. Yes. The slides will be published on our website or the same page where you have registered for the webinar. Hopefully they're already there, if not, maybe like in half an hour or something, so it will be available on the second question is, do you think there is a common theme in the data breaches or the most common course, or one of the most common cause for data breaches?

But it's an interesting question because I would argue that the common theme of any cyber attack, like almost 80 and probably like 99% of cyber attacks is to some money from you. Right.

As a, as a victim, there are only like basically two ways to do that. Either just to take your money directly from you like ransomware or maybe a financial fraud, or to seal your variable data, almost clear, like, yeah. The common theme of that, the data breach happens because someone wants to earn money from you. And of course now there's a, your losses will always be higher than the actual money you lose on the data breach. So it's no longer a zero sum game. It's always a negative sum for you.

The more reasons to actually invest a little bit more into proper data protection, because no matter like how and who steals your data, all the blame, all the losses, all the reputational damage falls upon you. Nobody will abort. You are not, not the cloud service provider on the database vendor. Then you'll never be held responsible. It's all up to you to be responsible for your data. That's probably not a very positive answer, but I don't have any other, okay. Next question. Do you see any risks or issues with open database connectivity, ODBC? I could probably more technical for you wrong.

Yeah. I, you know, DBC is just a connection method.

The, you know, the, the libraries themselves are, are very mature. They're very secure. I don't see it an issue with, with that as, as, as a conductivity method, I do think that there are more and more advanced authentication capabilities. So for example, you know, the more advanced companies, don't almost never use username and password anymore in order to connect to databases, they use things like, like Kerberos or OAuth two or things like that.

I think, I think that's an important area to go into. I think that the notion of policy is important. Okay. Is like who, who is responsible for defining the access policy inside the layers I think is important to, to revisit and look at, but I don't think it's the connectivity method. That's really that important. And of course the one, the one thing that I forgot is that the notion of encryption of the connection itself is also something that's very, very popular. Now it used to be that the connection itself would not be encrypted. I think everybody is encrypting the connections right now.

Right, Right. But then again, I just want you to end that kind of connectivity is basically infrastructure. Right. And our was saying that infrastructure is still important, but less so than the actual data centric protection, of course, you still have to encrypt your database connection. You have to implement some fine-grain Texas management. It all has to be kind of bleeding toward the same goal, but we should never take it a separate issue and try to only fix the ODBC issues. Not considering. Right. Okay. Next question.

You said folks can start over, but how often do they try and what is the rate of success of greenfielding that's interesting. Yeah. I think we said that people don't start over.

You don't, they don't delete everything and start from scratch. I don't think that's really doable. Even those people who think that they have successfully started over probably forgotten about them, dust the car with mainframe in the cellar or something like that. I don't believe you can just cut them, get rid of all your technical debt and say, okay, but I'll start from scratch now today. Yeah. I think People do create incentives to go to a different approach.

So I'd like, for example, everybody is now building kind of their hybrid cloud approach where they have, they could have like an old infrastructure and a newer infrastructure. And the newer infrastructure is all, I dunno, Kubernetes based. And as all the cloud cloud centric attributes, even if it's, if it's on their own infrastructure, I think that it's still not exactly green field.

It's, it's kind of like maybe a new application will go into this infrastructure instead of this infrastructure or you, you start pointing like, like I, I have customers who say, okay, we will migrate a thousand applications in the course of a thousand days into the cloud, whether it's a public cloud or a private cloud. So yeah.

I mean, you could look at that as Greenfield, but it's not, it's, you're, you're taking something in, you're moving it over and when you're moving it over, you need to make sure that you're also moving all of your security controls that you built around it. It's not like you can ignore and start from scratch. Yeah. Right. Okay. Next question. Why is it so small? So what if I already have a multi-layered security stack? Let's say from AWS, why would they need anything else?

Well, it depends on, you know, AWS multi-layer security protect the infrastructure that AWS hats. Okay. But AWS has always been very clear, right? If you read kind of the security model through AWS, they say, this is our responsibility, and this is your responsibility.

And, and, and at the end of the day, they're not responsible for your data. Okay. So they give you controls around things like security groups and I am, and things like that, but it is your responsibility to protect the data and secure the data.

And, and again, you're not securing infrastructure. You're securing the way that you're managing the data.

And it's, it's very clear what your responsibility stays with AWS. I guess they gave you a great set of tools. And if you know how to use them, you'll be fine. Probably. But most people don't really, I mean, or at least they slightly overestimate the tools. This is why we have so many data breaches involving the S3 buckets, for example. Yeah. The great service that we want.

It's been, I mean, the challenge with the excess controls has been solved like five years ago, people still leak data. Yeah. They just don't know that they have to enable a feature or configure a policy or something like that. If security is not always on, if your security is something that you can disable accidentally, it's not working. Yeah. Or if you don't understand, I mean, a lot of this is so new and so different than what we used to have before.

Not everybody understands all the details, not everybody understands, for example, that S3 access control can be defined in three different and, and, and which ones you use when those, that that's all about the blueprints. Right. Okay.

Well, thank you very much. I believe you have reached the end of our allocated time.

If, I mean, I see that there is a couple of questions left unanswered, so we will get back to those people directly or email, otherwise, thank you very much for all the attendees. And of course, to all our future viewers of the recording, it was great to have you today on webinars like your home. Let's hope it slopes our last meeting only platform when I say Thanks. Bye bye-bye.