EP79 Modernize Data Security with Autonomic Data Security Approach

Security. Hi there. Welcome to the Cloud Security Podcast by Google. Thank you for joining us today. Your hosts today are Tim Peacock, the product manager— mind you, the product manager— for threat detection here in the cloud, and myself, Anton Chuvakin, a reformed analyst and a member of cloud security team here at Google. You can find and subscribe to this podcast wherever podcasts are sold and distributed, as well as at our website, cloud.withgoogle.com/cloudsecurity/podcast. If you enjoy our content, and you really should enjoy our content, and want it delivered to you piping hot every Monday, please do hit that subscribe button. You can follow the show and argue with us on Twitter as well, twitter.com/cloudsecpodcast. So this episode will introduce yet another thing from us that is autonomic. Does it scare you, Tim?

I don't know what it means.

Well, this would come to that. I think you would corner one of the people on the podcast, I wouldn't reveal the truth yet, and ask them, give me the crisp definition. Would you really do such a thing?

I absolutely would do such a thing.

Yeah, you would.

And I think that person might even go back and read it from a paper, but I'm still not sure it was crisp enough. Like, I wasn't part of writing this paper, and if I had been, I think I would have spent some more time banging that on the anvil of definition. But it is, it is a really interesting area. And I know during the episode I get a little trivializing, I think you called it, but it is actually a really interesting set of things. And I think a lot of organizations do struggle with how do I improve iteratively towards a goal that I have in mind.

Correct. And also the other theme connected to data security in many minds would make an appearance, namely that it's hard to even draw a strict line around data security. You and me deal with threat detection and response a lot, security operations. If somebody wakes you up at 3:00 AM, it'll be very clear where detection ends. I mean, sure, there's detection response, but you would never confuse detection with encryption, or you never confuse detection with hygiene. DataSec though veers into many areas.

It does.

From detection, DLP, to governance, to P word. Can we say the P word?

You can say it.

To privacy.

Yeah.

Even.

Sometimes compliance.

Compliance, yeah.

Sometimes sovereignty.

Sovereignty as well, yeah. So it's a very fuzzy area where some people— I used to troll people on Twitter by saying, give me a definition of data security. And I've gotten a lot of hilarious responses, frankly, over the years.

Is it fuzzy or just cross-cutting? Is this one of those topics that's hard for people because it doesn't fit our usual notion of what a discipline is, but Like all good interdisciplinary things, that is itself opportunity for people to innovate and provide useful definition.

Well, all of the above. I think in data security, the answer would very often be all of the above, except for possibly, is firewalls data security? No.

No. And we've agreed since episode 3 that firewalls belong in a bucket left out to relax at this point. So with that, listeners, let's welcome returning guest, I'm delighted to welcome once again to the show John Stone, our chaos coordinator at our Google Cloud Office of the CISO. John, we would like you to start out with an easy question today. Could you please define autonomic data security? And pro tip, I've yet to hear a good definition for data security. So autonomic data security, that'll make this an easier problem, right?

Well, I think you just mentioned it, Tim. So autonomic data security solves the definition of data security.

Oh, please say more.

Joking aside, I think you probably picked on one of the harder parts around this. So, Anton and myself are working on some material around this thing, and it's been a really difficult thing to put together. The joke I make around it is if you ask 10 people their opinion about what data security is, you'll probably get 11 opinions. And that's because it's really hard to nail down from that perspective. So, I would say, autonomic data security is— this is going to sound a little bit guru spiritualized, but it's actually a mindset, right? It's a way of thinking and challenging the perceptions that you had. Because the traditional challenge with some of data security, or whichever way you define it, is people think of it as a database or a thing that's locked in an area somewhere. But data gets created on my mobile phone, it gets consumed on my mobile phone, on my watch, on many different things that didn't exist before. And autonomic is more of a mindset around, like, data is now a lot more dispersed. How do we bring things up to speed with that? So, it's also a way of thinking. It's not just, here's a shiny new tool or a solution to do this. But it's actually a whole mind shift that needs to change, just like we had the whole kind of shifting left scenario. And I still say it's shifting to the middle because if you're all the way to the left, you fall over. It's just balance. So, it's finding that middle ground. So, shifting to the middle, there's no shift left, but it's that kind of thing. So, I wouldn't say it's one specific thing, and that sounds a little bit like a cop-out answer.

It is.

But it's literally, you've got to think about it from a mindset like, Challenge the perception of what it is. And we've actually defined some pillars, what we think would be in there.

Okay, so hang on. Let me make sure I understand this. First, you say autonomic security is a mindset, and then you tell me I need to seek balance instead of shifting left. So I'm excited to hear what the pillars are because I'm expecting one of those pillars to be like the sound of one hand clapping.

Before we get to that, though, we already did this once, and so it's not as mysterious. It is pretty mysterious, though. So, Tim's right.

It's sounding mysterious.

It is mysterious. But everybody, of course, knows that autonomous security operations, when we started this kind of movement, philosophy, mindset, was kind of largely started in the same way, right? We didn't say, here, you need to throw away your tools and buy our tools, and then you're going to get ASO. That's completely false. The point was almost the opposite. We said, hey, using Google lessons in practicing security operations, using other companies' lessons, we built this. kind of vision/mindset change that you can journey. So there's also another possibly a little bit Buddhist concept, right? You have to journey to get there, right? So to me, data— autonomous data security is only slightly more mysterious than autonomous security operations.

And I would agree with Anton. I think maybe my mystery is just to clickbait listeners into listening longer to this podcast. But I think also one of the things around the autonomous data security, it's obviously that mindset that Anton was already saying. But some of the things are actually things we thought of in the past but were never possible because technology wasn't there or we weren't thinking in that way. So, I'd say that's one aspect of it as well. And the way that we've kind of framed it and like kind of joked about is oot versus too. And too is, say, you take T-O-O and you take the— flip that around and you get oot and it sounds like an owl sound. Owls apparently are wise mythical creatures, so we're going down this mythic route with it. And the way that you think about that is it normally fails when we do the 2-thing because that starts with the technology first, and then we do operations, and then organizations. But your organizational capability and your operational capability will never catch up to technology if that's the first thing you start with because, you know, in a year or 2's time, you've got new technology and that swaps out. But if you flip it around, you start with organizationally, like your organization's culture around these things. I mean, the first question I would ask with data security, what's my company using the data for right now? Are we still doing the same thing? I've heard CEOs of banks saying they don't want to be a bank anymore. They want to be a software company with a banking license. That flips completely the way that you use data. So, that's already a shift. So, if you approach it that whole OOD thing, we're organizationally, what are we doing? Okay, operationally, can we support that? And then you get to the last stretch of what tool do we put in?

I mean, it will get to technology at some point, right? So, in that sense, there will be tools you would use because we are not trying to say shift the mindset and you're good. Like, sit at home, concentrate, focus really hard, Change your mindset and suddenly you have this new data security thing going. I don't think that's too far into the mindset. There will be changes to practices and technologies, right?

Exactly. And the technology, I think, is the thing that will constantly change a lot of things. But if you've got a good organizational culture around it, good operational processes can adapt, then the technology can get swapped out to what you need. Today we're doing a very closed-off hosted database and there's no PII data in it. Well, tomorrow we're doing a distributed database and there's lots of PII. The tooling to protect it is gonna change, but operationally, our capabilities should already be there to do that. If we have to stand up a new team, well, we've got a serious problem to do that.

So, I wanted to— you mentioned serious problems, and of course, data security is all about serious problems. So, when I've looked at this space back in my analyst days, I recalled the range of kind of data security mistakes from obviously exposing data to where it shouldn't go, excessively tight permissions that are hard to manage. So, before we go and kind of revolutionize data security with our autonomous data security vision, what are some of the notorious data security issues we see today? And please don't say data breaches. I know John is better than that, but just something a bit more specific, maybe common mistakes that CISOs and security technologists commit in the area of data security. Just give us a lay of the land of badness.

Yeah.

So, before I get into badness, I wanna get into potentially, I think, an accelerant to the fire of badness in the sense of there's this promise of if we store all the data, we'll unlock new value out of the data. But sometimes the data is just bad and we don't have good data hygiene, and there's not a lot of worth in some of the data that we're storing. But there is publicity damage, PR damage, and all those kinds of things if the data does get out.

Yeah.

In a breach. So the first thing I would say is just understanding the data usage, right? So before we even get into bad things that happen to data is a lot of times we don't actually understand the value of the data and what the data is being used for, and should we even keep it? It's that whole thing, we'll just keep it for forever, and then you get records that are breached and they're super old, and now you're in trouble that you should have just deleted those things. So, I'd say, like, that's the first thing is that whole lifecycle management around it is a big thing. In terms of the big challenges with this, I think the first part is that mindset shift, like, around it. Because we don't know inherently what the data's value is and where it is, well, it's already a hard problem to secure. If the data could be everywhere, there's lots of things that could go wrong with it. So I'd say that's one part of it. And then the other part of it is, and as much as nobody really wants to say this, a lot of the things that happen are misconfigurations, exposing things that we shouldn't. And if you look at, like, even just some of the stuff we've put out in our threat intel reports, and also which other organizations have put out that have done research, a lot of this is just Basic misconfigurations, things that if we had maybe an autonomic approach, we would catch already in the pipeline. But we're still manually churning through these things, and at a certain point, humans are going to make a mistake, you know. So I'd say that's like a big one, is just the misconfigurations and also not knowing what you have, where it is, and what the value is. I'd say those 4 are— Without obviously going into the classical breach scenario.

So, on this theme of things we know don't work, like expecting humans not to make mistakes, what else has historically not worked in the field of protecting data security?

I think limiting it to databases.

Say more.

Well, we think it's just databases, but it's not just databases. Like, for your data to get from An end client to an actual—

I think Jon is just saying that reducing the entire data sec problem space to database security is what you're saying, right?

Correct. And that's like a, you know, we think it's this small thing, but it's actually— let me make a controversial comment. So that's cool that you have amazing technology, you have all these things. But if you don't have data, you don't have anything, because at some point, a machine is processing data, right? So, for us to think that the data just sits in a database and, you know, plays tic-tac-toe by itself, that's a very naive thing if we boil it down to that. So, I'd say that's an approach that hasn't worked. And we kind of joke about this in our paper a little bit. Like, you have the castle analogy, our data is behind our castle walls and all those things. And then people realize, hey, we need to start using this data. And then it's like, let's open this port. And now we open another port. And then your castle starts to look a bit like Swiss cheese because of all those interactions. I think those kind of ways of looking at it is one. And then another one I'd say is from a security, like, professional side of things. I think the hard part is we've looked at what's the risk and how do we mitigate the risks around the data itself. But we haven't always fully understood, but what's the business value of this data? Why is the business wanting to do these things with that? There's been that kind of disconnect kind of thing. I mean, there's the traditional funny joke of, hey, I want to open up like a port on the firewall. No, you can't do that. But with data security, it's like, hey, I want to do this cool new product and launch these new things. What data is it? Oh, it's confidential. No, you can't ever do it. Never.

So you're still not naming my favorite control that never worked, namely having users just classify all data. So I'm just curious, is there any kind of psychological reason for this or do you disagree or?

No, I don't disagree.

I mean, to me, this is my favorite control that never worked, manual data classification.

But the reason why it didn't work is not because of a tooling problem. The tooling— there's been lots of tooling, and the tooling's been great on these things. I've done quite a few projects in a previous life on this stuff, and we always got stuck with, okay, Anton, can you tell me, is this data— what's the value of this? And Anton will give me a definition, and then I'll go to Tim, and Tim will give me another definition of it. We once had it with a company that manufactures very luxurious wristwatches. And we were trying to figure out their disaster recovery strategy, not data classification. And we went to them and we said to the factory guys, what happens if this factory goes pop? They're like, our business will die tomorrow. Then we went to the board of executives and they were like, actually, no, we've got spares in this other warehouse. We can run for another 18 months without having a factory. And that same problem plays into the data classification, you know, and that's probably one of the first things. And the reason why that is an issue is not— there's no contextual awareness of it. Whereas from an autonomic approach, there is a possibility to get contextual awareness because you're standing up a workload to do something with the data. Now, that thing that you're doing with the data is indicating the derivative value of the data. So, I can classify the data because I know what that workload's supposed to do. And I can also change the classification if that data gets enhanced and becomes another thing in another workload. That solves the human element out of this already. That's probably, like, a good definition of autonomic around that.

Yeah.

And by the way, that's a useful reminder that when we say autonomic, we don't mean automatic slash without humans. And we fought this war over the ASO, Autonomous Security Operations, because a whole bunch of people showed up out of the woodwork and they said, oh, you're wrong. You're suggesting a SOC without people. And we told them, read the freaking paper. We never said it's without people. It's about the cycle of improvement and people and machines working together. But this debate would continue. So I'm pretty sure we'll have to deal with these objections. Oh, you're planning to remove people from data security. And it's like, no, we are not planning to remove people from data security, but we do plan to remove people from tasks that aren't meant for people, like data classification.

Anton, could you maybe give a crisp definition of autonomic?

So yes, this question came up when we were publishing the Autonomic Security Operations paper. Like, what do you mean by autonomic? Do you mean automatic? And the best definition is, in fact, is in our Autonomic Security Operations paper. And the concept of autonomous is the same here in data security. And we do say that it's kind of a combination of practices, tools, and blah, blah, blah, but that improves organizational ability to withstand attacks through an adaptive, agile, and highly automated approach. So to me, the tricky part is that we say we're going to adapt, we're going to be agile, and we're going to use automation for where relevant. And ultimately, this definition is still missing one small angle, namely that autonomic kind of means that it runs in a self-improvement loop, and it's a pretty tight loop. We probably should add it to a definition in the paper because ultimately we say that things get better and we are able to scale faster than the threats, faster than the business. Is it still too woo-woo, Tim, or not? Is it better?

It's not the crispest thing in the world to me, what makes something autonomic. I mean, if it boils down to you try to improve your processes and you use automation where it's relevant.

That's still a little woo-woo.

I'm surprised that needs a label.

Right. No, but the tight loop is what matters, is that you are not just improving things gradually over time.

Oh, you're improving quickly.

You're improving quickly through— well, yeah, you're kind of trivializing this a little bit.

I don't know if I am.

It's the loop that matters. A little bit. The concept of autonomic here kind of means that humans and machines work together to enable this tight loop of improvement. Okay, fine. I managed. How about that?

So, John, in light of all of this, what advice do you have for organizations when it comes to securing the data that they've started moving to the cloud or that was even created in the cloud? Because now we've got, you know, cloud data that never was from on-prem. So, what should people actually do to lock that down?

Well, that's the first question. Should you lock it down?

Ah, should you?

Should you? Because maybe it's data that everybody needs to access and you shouldn't lock it down, you know. So, my first level of advice there, what is the risk to the thing that you're trying to solve? So, solve for the solving. So, I'm going to say something that maybe some people get upset about this. So, there's this concept, I don't know if you've seen these silicone rings, which are kind of safety rings and People use it because they want to show that they're in some form of a relationship, or for some reason they have that on. And with the traditional ring, very bad things can happen. There's some very horror stories of people going to gym and getting their fingers ripped off.

And yeah, degloving is not something you want to Google.

Yeah, so there's a whole bunch of stuff, bad stuff that happens with that. So in comes the silicone ring, and worst thing that happens, it rips, right? But I can solve that problem for you now. And for the listeners on the podcast, if I had a ring on right now, I would just go like this, and I would take it off, and I solved the problem. That's the first thing is, what are we trying to solve? Like, this data that we're using, what's it trying to do? What are the risks to that data? And what's the appropriate measures that we need to put in from a security perspective to do that? We so easily want to jump to, oh, here's a code template that we could use, or here's a tool that will do this thing without understanding what that does. That would be the first thing I would do, and that would inform all the rest of my decisions. So I'd say that's number one. I wouldn't even offer anything else because if you start with that point, the rest of the stuff is going to fall into place.

Mm-hmm.

Yeah.

I like it when the recommendation comes in sets of 1. I think it's way better than some people who recommend in sets of 17 or something. So 1 thing is easy to remember.

Hey, don't—

I mean, we could go for a list of 500 controls.

That's right.

Don't be mean. John Kindervogt had a very sensible list of 9 steps to implement zero trust.

That's exactly right. Yeah, that's a fair point. And it worked well.

Did it?

So I want to start wrapping this, and I want to ask one more question before we go. to our traditional classic ending question. So there's a lot of debate. Many of the legacy kind of traditional organizations' CISOs still deep in their hearts believe that data security on-premise is better for them. And we can argue with them and all that stuff. But of course, our CISO Phil Venables has published a pretty amazing piece of writing, 8 Megatrends. And in the 8 Megatrends piece, he kind of highlights the fact that generally speaking, cloud security gets better over time. So there is another virtuous circle of improvements. Even if you do essentially nothing, security around you would improve. So do we truly believe, and I think Jon and me at least do, that security in the cloud can in fact be better or maybe is already better than security on-premise? But can you add anything to this, Jon? I think I answered my own question, but okay.

I think you did, Anton.

Sorry.

So we should have actually asked Tim that question because he gets to see all the badness from the event threat detection side of things. But I think what I would add to that is the short answer is yes, it can be better in the cloud because if you truly understand cloud for what it is and not a hosted data center, there's a double-edged sword. So, let me walk this back because I'm going to walk myself into a corner with this one as well. There's a lot of technology things that you can go and do in the cloud that is very hard to do from an on-premise perspective. where you just don't have the ability there. So, from a security perspective, there's a lot of problems you can go and fix also in the cloud very, very easily and in a different way that you never did before. So, all this promise of automation and all those things are much stronger in the cloud. The investments that the CSPs make in general for the underlying stack, it's way more money than you're ever going to spend in your own data center, if everybody's very honest with that. So, that scale's already there. And like, as Phil mentioned, the megatrends, you know, the cloud providers competing with each other, that's great for the end user because we are pushing each other into better levels of security. But that last mile is the important one where you are working on your data, standing up your workloads, and all those kind of things. The tools are there for you. You still have to use them. But in that sense, it's better because there's a lot more things that you can do. The flip side of it, I've also seen it go wrong, where it goes back to that solve for what you're solving. I can put in a whole bunch of automated pipelines and do drift detection and a whole bunch of crazy stuff sometimes, but sometimes it's just I want one machine to talk to another machine, and a simple access control list just saying this machine talks to that machine is good enough. I don't need a whole automation pipeline to do that. So, that's the flip side of it. But in general, I would say there's a lot more things you could do from a security perspective in cloud that actually moves the needle in the right direction. But you still sometimes have to ask yourself, is this one of those where I need to move the needle?

Well, I find myself in very strong agreement with you on all of that. And I particularly appreciate the economic benefits of the cloud providers racing on security against each other. somebody involved in that race, it's really a wonderful thing to see. So, it's time for our traditional closing questions. Do you have one recommended tip for improving your autonomic data security? And 2, do you have recommended reading?

And, of course, we would mention the paper that we finished on autonomic data security. So, I'm gonna jump ahead.

What paper is that, Anton? John, what paper is that? Please tell the listeners.

Apparently, there's a paper coming out.

There is.

And very coincidentally, This was written before Phil wrote about megatrends, and he had 8 megatrends. We also have 8 pillars. That's just pure coincidence. So, I would say go and read that, number one. In terms of making your autonomic data security better, I'd say be a 3-year-old and take the 7 Why approach. So, just go why, why, why, and if you ask 7 times why, you'd normally get to why are we doing a certain thing. And that'll help inform that. Like, if you tell a 3-year-old, you need to go to bed now, it's like, why do I need to go to bed now? Till eventually they ask you so much, you say, because I said so, and you're going to bed right now. And that helps inform those things. I mean, I know everybody wants to look at technology, but it's much simpler than that. Figure that part out. And then one thing that helps shape some of my perception, I'm going to go to a very big classic on that. And I'm going to say Ken Thompson, Reflections on Reflecting Trust. So, trusting trust, essentially. So, that's a really good one because it poses, like, two sides of the argument and makes you, like, kind of think, whoa, okay, I should actually think about this more in depth.

John Stone, Chaos Coordinator, Office of the CISO, thank you so much for joining us on the show once again. Listeners, I hope you found this enjoyable. I'm pretty sure I know what autonomic means in the context of security operations.

And now we are at time. Thank you very much for listening, and of course, for subscribing. You can find this podcast at Google Podcasts, Apple Podcasts, Spotify, or wherever else you get your podcasts. Also, you can find us at our website, cloud.withgoogle.com/cloudsecurity/podcast. Please subscribe so that you don't miss episodes. You can follow us on Twitter, twitter.com/cloudsecpodcast. Your hosts are also on Twitter at Anton_Chuvakin and Tim_Pico. Tweet at us, email us, argue with us, and if you like or hate what we hear, we can invite you to the next episode. See you on the next Cloud Security Podcast episode.