Welcome to the KuppingerCole Analyst Chat. I'm your host. My name is Matthias Reinwarth, I'm the director of the Practice Identity and Access Management here at KuppingerCole Analysts. My guest today is Alexei Balaganksi. He's a Lead Analyst with KuppingerCole covering cybersecurity. Hi, Alexei.
Hello, Matthias. Thanks for having me again.
As always, great to have you. And we want to continue a discussion that we started with Warwick Ashford two weeks ago where we talked about how to protect data. What are the key elements, the top five measures to protect data? And we came up with some very basic but very strong recommendations when it comes to protecting data from the ground up. So really the basics when it comes to encryption, to access control, to training and to data leakage protection or prevention. Alexei, you've been working on the topic of data security for quite a while, and from your perspective, if we continue that discussion, what is data security in your definition?
Well, that's actually a great question, Matthias. I would rather say this is the greatest question of modern cybersecurity, because whatever we actually do and what our vendors are doing to protect us from various threats and risks, it all boils down to securing our data, because the data is, as we discussed earlier, is the new oil, the new gold, the new printer ink or the new toxic and extremely dangerous substance, depending on what your opinion on that would be. But data is sensitive, data is explosive. Data has to be secured. This is the whole goal of cybersecurity nowadays, basically. And every time we bring up the term data security or data protection or information protection, it reminds me of this old parable of the blind men and an elephant. You probably know that story. Well, a few blind men discover an elephant, and they try to find out what it actually feels like for a blind man. And one feels the elephant's trunk and says, this animal looks like a fake snake. The other one grabs his leg, and says, no, no that elephant looks actually like a tree. The third one says, no, it actually feels like a huge sheet of leather because he's grabbed its ear. And so on. And this is basically what data security means for us analysts nowadays. As you mentioned, Warwick has worked on the topic of data leak prevention, and this of course is data security. And our other colleague, Paul Fisher, worked on his corner of data security, which is data governance, dealing with unstructured data protection, for example. And my focus this time was primarily on structured and semi-structured data security, databases, cloud storages and so on. And all of this is data security. And the problem is how to unify all those distinct definitions into a single umbrella, if you will. And yet not to make it trivial or not to make it too complicated, too complex. Because if there is one finding of all of our collective research, it’s that data security is extremely complicated and complex.
So it depends on what challenge you want to face, which problem you want to solve. And that also describes the market segment or the technologies to apply?
Well, on one hand, again, kind of people would argue that protecting your data is the goal all the time. Some people would even bring up definitions like data centric security, which was a pretty popular buzzword a few years ago, now somewhat forgotten, unfortunately. And the idea was basically that in an ideal world, data as an object, as a piece of sensitive information, should be able to protect itself. Sounds like science fiction today, probably even tomorrow. But there are some interesting developments in that direction, and I would primarily see it more like zero trust or other abstract ideas which actually just help you to narrow down your tool selection, if you will. But basically, the overall goal is to protect your data, obviously, it's in the name, but the data is different. This is the biggest problem nowadays that people eventually stopped thinking about data in various technological perspectives. Like ten years ago, everyone was talking about big data. Now there is nothing special about having lots of data. You just need more storage for it basically. And people were talking about cloud data versus on-prem data. And nowadays basically everyone has feature parity. And the only reason why you would even want to go to the cloud is just to get more, again, more storage, more computing power, more machine learning to do something useful with your data. But in reality, of course, all those approaches, all those use cases still require completely different technology stacks. Your data in the cloud is probably stored in a totally different type of database or some other object storage than your on-prem MySQL database. Or Oracle database or your data stored on the file server should be protected like completely differently, with different tools and so on, than something you have to share with your clients, for example, and so on and so forth. So yes, this is the complication. This is the divide between the customers point of view, the basically, “Data is data. I don't care about the details. Just make sure that it's protected.”, and the actual challenges the vendors have to deal because they know that data is still different. Structured, unstructured, semi-structured, cloud, on-prem, big or small. The data is really different.
You've hinted at that before, that this is difficult to describe, to get to a common definition or to get to a common language when it comes to solving this issue. But that, I assume, makes your work when you're doing the research on that topic, quite difficult to structure that market and to correlate the products and the services with each other. How do you approach that and how do vendors do approach that?
Well, we as analysts have to face this challenge every time because on one hand, we want to promote our own view on how the market should work, if you will. Because we are looking at it from a strategic long term perspective. And then, of course, we have customers who are pushing their own agenda because they want a solution now and they want it cheap and easy to deploy. And then of course, we have vendors which have their own problems. For example, a vendor might be doing something for 30 years and then suddenly facing the idea that their technology is no longer relevant. So they are, of course sometimes interested in just inventing a new buzzwordy name for that and continue selling the old proven technology with the new label. And we all have to somehow unify all those viewpoints and boil them down to a sensible and yet not too restrictive taxonomy. And even the name is really a big challenge. For example, my Leadership Compass is a fourth edition of the same subject, but it already did undergo two name changes. We used to call it “Database and Big Data Security”, then we agreed that big data is no longer something special, so now it was “Database Security” and now we just call it “Data Security Platforms” because this is what vendors are calling their solutions now. So on one hand, this is great because vendors are starting to recognize that data is not just limited to databases. You have to think about object storage services, or unstructured data, sources, file shares, and so on. On the other hand, they are not yet delivering on the promise yet, but it will take time before vendors which have been doing database security for 30 years also incorporate, for example, unstructured data protection into their products. So it takes time to balance between those extremes. But we are working on it, and this is actually why we are talking about today.
If we're talking about it today, you say they have come to the same term data security platforms. Do vendors mean the same when they say data security platforms, or are there differences in the interpretation of that term?
Now, this is the question that every potential customer has to ask themselves, and then the vendors, of course. No, vendors are absolutely not meaning the same thing. Again, to put it bluntly, the primary goal for a vendor is to sell as many products as possible, and to do that, they have to invent various marketing strategies. And of course, they obviously have to add real capabilities, but it's not always reflected in the name. So data security platform is a great term. I absolutely endorse it on all levels, but we have to understand that as soon as we go from a term like database, or whatever, data store or anything. So just data, we assume implicitly that we are talking about all kinds of data. Again, structured, semi-structured, unstructured, databases, file shares, streaming documents, JSON files, or cloud native services that store objects instead of documents and so on. That would be like a trivial expectation for a customer when they hear the name data security platform. Unfortunately it does not yet fully translate into capabilities. So most of those data security platforms are still primarily focusing on structured data, on databases. A lot of vendors, a lot of leaders in our Leadership Compass kind of branch into a semi-structured cloud native. Some collaborate with third party technologies to incorporate what we used to call data governance and deal key capabilities into their platforms as well. But it's still an ongoing process.
So if I understand it correctly, reading your Leadership Compass on that topic data security platforms, also has to start with a kind of educational part to understand what it actually means, what could be included, what are the capabilities, and then to map that to the individual services / products by the vendors and to understand what is really what I need. So it's an active learning plus detection process, right?
Right, right. So again, we’re having this elephant in the room, the data security elephant. And we as analysts are trying to a feel different body parts and explain, how they are even supposed to work or at least what other blind men are supposed to expect from the elephant, if you will. But on the other hand, we do not imply that every customer needs the entire elephant, not every potential organization in the world can actually afford buying the whole elephant. And they probably don't need a whole one, at least not in one portion, if you will. Most companies actually have very tangible, relatively small burning problems with regards to data protection, for some, it's obviously compliance like GDPR, for others it's cloud migration, they already have the data, they want to be like, for example, analyzed in the cloud, or use it for training machine learning in the cloud. But they have to ensure that it's secure. For others, still, it could be completely different. A bank probably would have completely different requirements, it would not even think about going to the cloud, at least not in the near future. So yes, you do not need the entire elephant, but you still need to understand the relationship between the elephant’s legs and ears. And you have to look behind the labels because, yes, a company could call their solution a “unified zero trust data security platform”, but is it really, what does it mean? What capabilities does it really offer on the promise? That's for you, a customer to find out. And this is what we are helping with.
Okay, I get the point. So it's an evolving market. It's a changing market. You've mentioned the changing, even in the name of the document that you produced over time. So the latest edition is the Leadership Compass on data security platforms. It is out, it is published, it is available. When you say, okay, what should the audience focus on in the first place? First, are there common denominators across these products and should be more focus on identifying the specific characteristics, specific capabilities to choose the right thing from your Leadership Compass?
Well, I would say that again, kind of the first common denominator is that data is just data. There is no longer a meaningful distinction between the various kinds of data because in reality, any kind of IT project or software development or even just existing business thing will always deal with more than one kind of data, with more than one kind of database engine, structured, unstructured, whatever. So you have to keep that in mind all the time as a strategic basis for your tool selection, if you will. On the other hand, the entire market is now so mind-bogglingly complicated and broad that you will probably never find a solution that can do everything. And this is why, by the way, because of independently from this Leadership Compass, KuppingerCole has been pushing this notion of a security fabric, because basically a fabric is something which you cannot yet buy from a single hand from a single vendor, but you can design yourself. Basically, it's like building a set of tools which are independent but easily integrateable and basically all speak the same language. So when you combine those tools together without overlap, without unnecessary spending and with tight integration and visibility and so on, you will get a security fabric. And there are some vendors who already even recognize this terminology as well. But not everyone is talking the same language. So you as a customer have to learn to speak those languages as well.
Right. So it's a challenge, but you provide the tool kit in form of the Leadership Compass for our audience, our readers to understand the market, to assess the individual products, to whether they fulfill the requirements that they actually have. And if there's not only one single solution that might lead to the outcome that you have a combination of products, then creating the fabric, the cybersecurity fabric, as you've mentioned, which reminds me a bit of what Paul Fisher recently said in another episode of this podcast, when he said, okay, PAM is changing so much that many organizations have various PAM solutions. He even called it PAMocracy, which is a nice term. Maybe we can find something like that also for the for database or the data security platform market. So if you say, okay, there's more than one and they need to co-exist and maybe to integrate, but in the end you need to find a solution that really assaults your problem and not just the upper right corner, as usual, of the Leadership Compass, right?
Right, right. Well, I wish I could come up with such a funny term as PAMocracy. Well, unfortunately, we probably have to stick to data security fabric. Much less funny, but more descriptive. But what I want to stress is that, first of all, some of the companies already recognize this trend and they already kind of take some of the stress and load from the customer because they already pre-integrate some of the third party technologies into their offering already. So you don't have to build it yourself. You can have it prebuilt from a single vendor. On the other hand, and I think we could probably just go through a few leaders in my Leadership Compass, and I won't explain why and the approaches are so widely different and yet they’re all right, they’re all relevant. So basically we have 15 companies analyzed in total, but I would only focus on like three or four leading ones. And three of them are the usual suspects, which have been among the leaders in previous editions as well, namely Oracle, IBM and Imperva. And it's really interesting how all three kind of like really pursue a completely different direction. Oracle is obviously known to be as primarily a database vendor, which is basically saying, use our database. It can do everything and your data will never leave it, so it will always remain in the protected container, if you will, and they will give you a selection of tools, automated or manual, which will ensure that your data is always safe inside that database and you will never actually need to pull it out of the Oracle database to send it somewhere else. This is a really neat approach because if you can do everything in one place, you don't have to face any migration processes or ETLs, stuff like that. So your data is never actually exposed to external risks. Yes, one would argue that this is not true security in a way that Oracle, it's not a security vendor. It's just a database vendor, but you get a secure database. That's one approach. And it's, again, it's completely valid for a lot of use cases, but it's not the only one.
The obvious alternative is the way of IBM, their solution basically is, we know that if you have a sufficiently complicated, complex project, you will never be content with one database. So we will have to face a multitude, a zoo of database engines as well as other storage areas. So we will cover everything in one platform and where we don't have our internal capabilities, we will basically bring in the partners. But you don't have to care about it, we just have one single console, one single set of APIs, one storage place to keep all the findings and so on. We will do everything for you. Again, this is a completely valid approach, probably the favorite one for large enterprises who want to be in control of everything and really actually face those data zoos, if you will. But of course it has an obvious disadvantage, complexity and cost.
And then we have Imperva, who again is not really known to be a data security vendor, at least not in the popular consciousness, their motto is basically, protecting your data and all paths of it. They would say, Yeah, you have a database, but your data never resides in the database all the time. Sometimes it has to flow to an application, to an API, even to a third party, and all those flows have to be protected as well. So we have to at least stay on top of your, application security, API security, network monitoring, network security, so that it's all theoretically also a part of data protection. You can have this data security fabric from Imperva to solve that.
So all three are completely valid, fairly comprehensive, although they are probably like completely opposite in terms of their relationship to each other. Can one approach solve all potential customer problems? No. But like, do you need two to solve all your problems? Probably no as well. It's up to you to understand which risks you value the most, which data types which application models and architectures you have to protect first and so on. Or you can look even further and say, okay, I actually have a fairly small problem, so maybe I'll be content deploying the early lean and mean and fast solution, which only solves one problem exceptionally well and I can give you an example of that as well. We have a newcomer, a startup called Titaniam, which are basically offering you data encryption in-use. They’re only doing just one thing. They ensure that your data always remains encrypted, even when you are doing analytics or machine learning training or some just common operations on your data, you don't have to decrypt it for that. It's kind of a poor man’s alternative for homomorphic encryption. And if you remember maybe, we discussed it earlier as well, homomorphic encryption has a lot of academic level research, but it will probably take years to be converted into a usable product. Well, Titaniam offers you an alternative today. It doesn't do classification, compliance, monitoring and reporting, and so on. You just encrypted data all the time, but it does it exceptionally well. Maybe that's exactly what you're looking for. Or again, we have about ten other vendors covered, and probably 20 vendors to watch just to whet your appetite for data security solutions. So, have a look at our website.
Absolutely. So and it really boils down also to this old saying that a tool is just not enough. You need to apply a proper requirements analysis. You need to understand what you really want to protect. You have to have a risk based approach to say what is really important and what can come later when choosing such a product or service. So it's really much more than just a tool selection. It's really understanding your own architecture, taking the right steps and moving towards the proper data security platform or fabric for your own organization. So this is really important to understand again and again when it comes to Leadership Compasses, it's really reading between the lines and reading the lines to understand what the products can do and what they cannot do and where they're good at, where they have omissions or just missing capabilities. So I highly recommend to go to kuppingercole.com and have a look at your Leadership Compass Data Security Platforms, which is out right now, has been published. And it really shows that there are the basics available, but there's also very new capabilities being more and more deployed in modern products, just as you described with encryption and during processing, which is really something new and might also solve some urgent issues within organizations.
Thank you, Alexei, for being my guest today, for doing that great work. I know that this is a lot of work to put such a Leadership Compass together, so everyone who's interested in it, the source is there, go to kuppingercole.com and get the document there with a first free four week subscription or just with a subscription, which is really affordable and more than worth it to get access to our research. Thanks again, Alexei.
Thanks, Matthias. It was a pleasure talking to you again.
Absolutely looking forward to seeing you again for a further episode. And of course, I cannot leave without hinting at EIC taking place in Berlin in May. And then there's also a chance to talk to people in person, looking forward to that as well. So thanks again, Alexei. Bye bye.
