Transcript
by Terry Ray, who is the Vice President of Product Strategy at Baroness. Really good to see you, Terry. Good to see you too, Anna. Thanks for having me. Absolutely. So let's talk about structured and unstructured data security, because for years enterprises have tried to bring them together, but it's been quite a challenge. And why do you think that is? For years, I think it's been really the vendor's fault. I mean, the vendors have not had the technology or the capacity to bring that volume of data, both structured data from databases and unstructured data from everywhere else where you have a file together into one place. And over the last decade or more, the cloud and the efficiencies of the cloud and the scale of cloud technology has allowed the vendors to catch up, quite frankly, with the needs of the business. So what that really means is now businesses can take advantage of, I would say, modernized vendors that are taking advantage of things like the cloud and that scale to say, I can absorb structured and unstructured data and bring that together. But that's been the barrier. I can't put that blame on customers. I have to put that blame on vendors just not having the scale to do it. And that's not a problem anymore. So when they remain siloed, what are the issues that arise or the blind spots that come up for organizations? Well, I mean, consider, right. So in a given day, most of us don't spend a lot of time in a database. So we don't know we spend a lot of time in a database. We know that we interact with OneDrive and Google Drive and all of these different drives that we have and our files and all of this. We do that every single day. But all of the applications that we go to, whether it's an internal application, whether it's an external application, they're back ended by structured data. We may not know we're going to a database, but we really are. The reality is, is when someone asks whether that someone is a regulator, whether that someone is an auditor inside your own organization, or maybe it's just a bad actor. Fact is, is they're looking for you to answer a simple question. What did Terry do in your environment? They didn't ask, what did he do in your databases? What did he do in a file server? They just said, what did he do? And the expectation is that you have an answer, which is Terry accessed all of this and all of that. And in one place, I need to be able to answer that question. And previously, when there was no capacity to bring those together, it meant two or three different products and two or three different qualities of answers. Sometimes I don't know the answer. Sometimes I do. And that's really the gap that happens. There's just an inconsistency of being able to answer what should have been a really easy question. I want to ask you about agentless tools, because they promise less overhead without compromising security. How does that actually work in practice? Yeah, so agents, we're talking about databases here, right? So when we think about putting an agent on a database, agents on databases, they do get good information because they're right there on the database. They can do all of that. And at the end of the day, agents are an easy thing to install on a database. The downside of the agents are the fact that they're on the database. So if something happens to the agent, something can happen to your database. Sometimes even if you want to call a database vendor for support, they're going to say, call us back when you remove your agent, because that's not supported on my database. The biggest factor is when you have one database, one agent is fine to manage. When you're a massive bank, and there's a lot of them here in London, when there's a massive bank and you've got tens of thousands of databases and now tens of thousands of agents and your vendor says, it's time to upgrade. How long is that going to take for you to upgrade 10,000 agents, 20,000 agents? The reality is, is agents are really easy and nice to get installed on day one and end and done. But that's the problem with software is you always have to update it. You always have to upgrade it, which means you're never actually done. It's a recurring issue that you have to deal with. The more agents you get, the longer that tail of technology is. So you really just wind up creating more and more work for yourself, the more agents you put in. And that's what, I mean, at the end of the day, that's why organizations are moving away from agents now and moving toward network analysis, even proxy analysis and other kinds of ways to collect the same volume and quality of data without having to be on the database. So you see that organizations are embracing these tools. Are they raising concerns? Any misconceptions you want to address as well? Yeah, I mean, I think anything new is always going to be a conversation piece, right? And so I would say in the history of database security, in fact, agents were not the first way database security was done. If you rewind even further back, database security was originally done by monitoring database traffic on the network. Wasn't a proxy, but it was monitoring on the network. Most users today don't remember those days. I sadly have gray hair and I do, but the fact is, is agents were in the middle of that phase. And I would say now we're in this next phase saying, okay, we tried agents, tried it for about a decade and a half. Now we understand the challenges of it, the benefits, but the challenges of it. Now we can go back to this network model. The network model was efficient because in the network model, you can say, I have a hundred databases. Great. I'll put one thing in your network and I'll monitor all 100 databases. That's efficiency. That's easy. It does mean that you now have to have a conversation with a networking team that you didn't have to talk to before. So there are some net new things that happened, happened that you didn't do before. But you know, I plugged my car in today and I didn't do that before. So the reality is, is I'm willing to try something new if I can get greater efficiency from it. So speaking of monitoring, many organizations simply monitor their most critical assets. What is the downside of that partial coverage strategy? What, what are the, what falls through the slit, the cracks rather? Well, to me, I take a step even back from that. Why do they only monitor a portion of their environment? And this goes back to that agent scenario. If I know that I start to install agents in an environment and it gets to a point where I'm having to manage agents and I get to my 200th agent and I say, this is already a lot of work. And I know I've got 800 agents to go. Do I continue to put agents in my environment knowing it's increasing my workload? Or do I say, maybe I reposition my requirements and I decide what I'm going to really focus on are just these priority databases and I'm going to ignore everything else. And the reality is, is that's the why that's the why organizations just don't get there is because the overhead, the burden of trying to deal with the way database security has been done for quite some time now, it's just so difficult. You just can't cover everything. And so that's the big gap that really happens here is the, the, the outcome of that is that you wind up being able to say, I know what's happening on this subset of my environment and I'm completely blind to everything else. And I'll, I'll take 15 more seconds and say, you know, at the end of the day, when you look at this, most organizations do at least that, the smart thing, and they'll say, I'm going to focus on my production databases. That's my critical really use data. But for my development, my test, my user acceptability testing, these systems that just aren't hit every single day, I'm going to ignore them. And what they forget about is usually in that development testing environment, most organizations use production data, real data, and move it to dev and test, because how can you dev, how can you test without real quality data? It's kind of like saying, I want to test a login, but I'm not going to, I'm only going to test Terry and Joan and Mike. I'm not going to test O'Donnell and O'Shaughnessy and the apostrophes and the, I got to get real data inside there. So when, even though you don't, you ignore the dev development and test environments, it's important to realize they have the same quality, the same monetizable data that your production does. And a lot of bad actors will know that, and they won't even touch your production. They'll focus on their dev environment because they know that's good data too. So it's a big gap that organizations leave open for themselves. Now, of course, the regulators and even the attackers don't care whether data is structured or unstructured. How is compliance really driving this unified monitoring? You know that you hit the nail on the head, right? Regulators don't care. They, there's not a regulation I'm aware of that says, I only need you to monitor your private data in a database or in a file server in OneDrive. They just say, I need you to monitor all access to, and the regulation is BCI, credit card data, track data, GDPR, PII, whatever the regulation is, that's what I need you to monitor. I don't care where it is. In fact, anywhere where it is, the regulation is saying you better be monitoring it. If the data was important enough to you to grab from your users and it's regulated data, you are responsible for protecting that data wherever you or your employees or your applications or your AI has put that data. And so it's your responsibility to go get it. So this consolidation of bringing this together now means that you can answer that question. Where do I have PCI data? Just picking on PCI. I have it in OneDrive, 365, Salesforce.com, GitHub, ServiceNow. These are all places where people get surprised that they have data, but when you go looking for it, you find it. Final question, how does CSIS take this to the board without getting bogged down in the sort of minutiae, the technical detail, and really get the resources that they need? So the board, the executive staff, at the end of the day, it can't be technical, right? So it has to be something that we can bring it back home to them. And I think the easiest way for boards and leadership is really some level of quantifiable metric, right? Being able to say, yesterday we were a seven, today we're a six. Our peers are six and a half and sevens, we're doing better than our peers. And there's a whole market that's kind of bubbled up behind data security called data security posture management, which kind of fits into that model. It's the whole model of it is around being able to answer simple questions and ultimately result in a score for the organization and say, how well are we doing around protecting our data? How well are we doing around regulating our data? And I will tell you, there was a time I was sitting in the executive staff and our CISO came to us, not at Veronas, but at a prior company. Our CISO came to us and he said, hey guys, we're a seven. And that means nothing without context. And you have to have that context to be able to say historically over time, today we're a seven, tomorrow over the course of the next three months, I want to do five specific things that I've been told by my technology. If I do, I will lower my risk in these ways. And I expect for a quarter from now, we're going to be a four instead of a seven. That's a metric that your board can get behind, your executive staff can get behind, and it can give you direction to be able to say, if you do these things, you will lower your risk. And so to me, that's that quantifiable metric is what a board or what an executive staff can understand, what they can stand behind. And at the end of the day, what they can take to the bank and say, all right, this is going to make us better than us and even our peers. Excellent. Well, I've really enjoyed this. Terry, thanks so much for all the advice you shared today. Thanks for your time. I appreciate it. Thank you. I've been speaking with Terry Ray of Veronas and for ISNG, I'm Anna Delaley. Thank you so much for watching.
