Modern Data Security Approaches: Is Cloud More Secure?

Security.

Hi there. Welcome to the Cloud Security Podcast by Google. Thanks so much for joining us today. Your hosts here are myself, Tim Peacock, the product manager for threat detection here in Google Cloud, and Anton Chuvakin, a reformed analyst and esteemed member of the cloud security team here at Google. You can find this podcast wherever podcasts are distributed and at our website. If you like our content, please do consider hitting that subscribe button. You can follow the show and argue with your hosts on Twitter as well, twitter.com/TheCloudSecPodcast. Anton, we've got an exciting topic today. What is it?

Well, we're going to talk about data security in the cloud again, and we're going to look at it from a somewhat different angle compared to our notorious episode 2, when we highlighted the white paper we wrote about data security strategy. This time, it's focused on just us looking at the evolution of data security in the cloud, and of course, celebrating Google's win in the Forrester comparison of vendors. Forrester named Google Cloud the leader in unstructured data security platforms report. Think about it.

Wow.

Unstructured data security. That sounds really hard, right?

Is Forrester calling us unstructured or saying we're good at dealing with unstructured data?

Yeah, I'm not really sure I want to make this joke, frankly. But, but, but, but— It is about dealing with unstructured data in the cloud because we have what we call Cloud DLP, which is frankly, and as a former analyst, I can tell you that it's an amazing bit of technology that can really help clients, help organizations deal with data sprawl in the cloud.

Mm-hmm.

Personal data, privacy-relevant data, regulated data, sensitive data, it can find it, it can tag it, it can do other things, it can even modify it if you want to. So there's a lot of magic that frankly, we sometimes undermarket. And this is a bad joke on me because I was involved with marketing of this product for a while. But the point is that we have a lot of really interesting data security innovations that people sometimes don't know about. So Forrester went pretty in-depth to kind of look at what we have, looking at encryption, other type of data protection, and of course, the data discovery in the cloud.

I was a part of those demos. We put together a live demo of how we detect data exfil for them as well. That was actually a ton of fun to work on.

Yep, yep. I mean, they really did go in depth. The demos, you know, they took a lot of time by a lot of smart people to prepare, and they had to look real. They had to use the technology to the max, and they have to impress. So to me, this is a lot of work that went into this report, and I'm very happy we scored well.

I'm delighted about the score, and I'm delighted about our guest. So perhaps with that, why don't we welcome today's guest, Tim Derks, official title, Engineering Director, Data Protection. here at Google Cloud. Tim, thank you so much for joining us today. I wanna start off by asking what's hopefully a softball question for a man of your prestige and famous stature here at Google. What are the key components of a data security strategy in public cloud today?

And I don't know about prestige or whatnot, but, you know, data security in the cloud is so important. And I think that, you know, the opportunity in cloud is that we can really help a lot of companies and individuals. Security has been such a challenge. But by building an extremely secure cloud and offloading a lot of the operational details of what it takes to be secure, we can help you be far more secure in the cloud than is really achievable, I think, for a lot of businesses and a lot of individuals in running their own stuff.

Mm-hmm.

So in terms of the stuff that we should think about in what does it take to be secure in the cloud, a few things that come to mind are, you know, you've got to really trust the platform. It's got to be secure. And we work super hard on it, and there's a lot of reasons to believe that we're good at that, but it's critical for people. How do you trust the platform? What are the controls, you know, and how do you validate that? You've got to understand the shared responsibility model. We can't secure everything for you. We'd love to be able to do that, but you've got to set some stuff up yourself. You've got to configure some things. You've got to make sure that the ACLs are right. So you've got to understand which of the things that are the customer's responsibility, which are the things that— Google or your cloud providers, like what are they gonna take care of? And then where are the things where it's a little bit in between and it's a shared responsibility? For example, something that you have to get right, but we're gonna give you the tools to help validate that you've gotten it right and give you warnings when it isn't true. I think understanding those 3 areas, so you're confident both what do you have to get right and then where do you have tools to validate that you're getting it right is really, really critical.

Hmm.

And then getting into that end is the observability and the monitoring. Then tracking how it actually all fits together, how it's being used, Having, you know, a lot of the tools that we give you are things like audit logs and monitoring and our Security Command Center that will give you specific alerts. The ability to use all those different kinds of things to validate that things are really secure creates, I think, a complete package, a very secure cloud, secures your workloads on the cloud. You know, our goal is to help you leverage all of the amazing security engineers that we've got and the amount of time that we work on this, put that to work for you. So that you don't need to have as much investment in having to build it all yourself. It's deeply partnered, and you have the ability to really leverage our expertise and our investment.

That does make sense to me. And I think the shared responsibility model, which we are trying to evolve into shared fate, which is kind of a slightly different version of that, the more modern version, I would say, is kind of critical. But let me try to look at the other angle, kind of a slightly broader story. Sometimes we have people talk about Cybersecurity, information security, and then here we are talking about data security. So do you think the companies should have the kind of more narrow focus on securing data in the cloud, or is their cybersecurity information security program just okay?

You know, I don't think I always understand exactly what everybody means by all those terms. So some of it depends upon that. Cybersecurity sounds like an outcome. Listen, everybody now, doesn't matter what industry, you're a technology company because everybody needs technology. They need software, they need complicated systems to actually manage the information that modern enterprises need to be successful. So it doesn't matter whether you are in anything from the gravel business on up, you know, you are to some extent also a technology company. And so cybersecurity to me implies just that really broad facet of no matter what kind of company you've got, technology operations are an important component of it. And how are you confident that those are secure? If I were to identify anything, that would be cybersecurity. So then the specific questions of, hey, we have data assets, we have resources, they have sensitivity, how can we be confident that we have control under those, that they're not leaking, that they haven't been modified or anything else like that? That's one component of your overall cybersecurity strategy.

Mm-hmm.

A pretty important one, but, you know, maybe some businesses might say, you know, not as important. Other areas, it's super critical. I think we offer a lot of different tools to accomplish your goals.

So speaking of the controls that we offer and speaking the difference between, say, a gravel company and somebody who's running national security workloads or other kinds of really secret things, do you think cloud has the right controls for the most sensitive workloads?

Oh golly, do I think cloud is secure enough for people to use? Why, yes, Tim.

Yes, I do. That's not quite what I asked. But no, are we there yet?

I think a lot of different companies have lots of different kinds of data and there's a lot of different kinds of controls. A bunch of people have things which they wanna keep very much on a machine that they keep under their bed and have that level of certainty about where it is. So I don't wanna say, hey, yeah, cloud is perfect, offers as much security as you could possibly want no matter who you are and no matter what your concerns are or what your controls are. Obviously the world is more complicated than that. I think that we're in a spot right now where a well-managed cloud ecosystem is more secure around many different axes than even a tightly controlled internal system. There's loads and loads of attacks where you can't wish them away by saying, well, we're not in the cloud, it's all in a data center that we own or anything else like that. People attack and exfiltrate data from those kinds of environments all the time. And while there's certain kinds of controls that things like governments or military entities or very highly secure environments use to Mitigate that and to achieve a level of control that may be inconsistent with some cloud environments right now. They invest huge sums of money and lots and lots of people to accomplish those things. And so while they might make use of a tool like, well, we built our own data center and thus we control everything about it, that's not really a viable strategy for 99% of the customers out there. So the question is not, is cloud secure enough for everybody? The question really is, is like, is cloud and the kind of cloud deployment that a customer, an enterprise can actually make use of a secure solution when compared with what their alternative would be. You know, the technology of actually managing, you know, hundreds of vendors and loads of operating systems and lots of people and physical stuff, the amount of stuff that one has to do is just huge. And I think the question is, is really is like, can you do it yourself better than, you know, asking a cloud to participate in partnership with you? And I think for the vast majority of customers, we are at least as secure as the alternative. Now it's a little bit different. Sometimes the risks and models are a little bit different. Different things go wrong in cloud than they go wrong with on-prem solutions. And so you've gotta understand that. And that gets back to that shared responsibility model that we've got. If you build a data center yourself and you just have a firewall and you've got everything locked off inside, then you're unlikely to have a problem with accidentally leaving a bucket ACL to world readable and leaking your data that way because the platforms are different. That doesn't mean that cloud is necessarily riskier, Because cloud is gonna protect you against a huge number of things about like, oh, forgot to patch the kernel or wasn't adequately managing sort of base firewall rules in terms of things or the physical security of the environment. We're gonna take care of all those things and I think better than almost any enterprise customer would. So I think net, yeah, absolutely. I think the cloud is super secure and we have loads and loads of customers who trust our controls and entrust us with a lot of different data that demonstrates that.

I love that answer.

We sort of avoided the question, is cloud secure for all clients, but do we have enough control to process the workloads? Because to me, the intent is we may be more secure, but they still don't feel good about some of the stuff. Like the word Tim mentioned was trust. Like, do they trust us? And to me, this is not always the function of do we have enough controls to be secure, but can they validate that we have controls built in such a way that they can trust us? Is this still cloud is secure or is this different? I feel like it's different.

It is different and it's hard. It's really complicated because cloud is a different way of doing things and it requires businesses to trust us in a lot of different ways. Now, people have always had to have a lot of trust, right? You buy software, you install it, right? You know, if we look at something like the SolarWinds attack or something else like that, that exposes you to sort of a bunch of implicit trust in how it gets updated. Is that sufficiently locked down? You know, the level of trust goes very, very deep. And regardless of whether you have a cloud or an on-prem or any other sort of environment, you're trusting a lot of different entities. One of the things that's different about cloud is that it is just different in a certain way, right? You can't go into the data center and sort of look at it yourself. You don't necessarily able to name everybody who's employed and has physical access to the machines and things. And so that means it has to be evaluated differently. I think a lot of the trust has been having the whole community, the customers, the technical environment Go through that transition and have a better understanding of what does cloud mean and how should we think about it? What things do we trust? Where are our concerns? I've been working on Google Cloud for 7 years, something along those lines. So since it was, you know, quite early in its lifecycle and growing as an enterprise cloud. And of course, very early on, we had a lot of customers who had real concerns, needed to understand things. We went to a lot of lengths to demonstrate. and make them confident about the quality of a bunch of our controls, a lot of those concerns have gotten not nearly as worried about it anymore. And some of that is because we've built stuff and some of it's because we describe stuff, but a lot of it is just because people have just generally gotten more comfortable with a lot of what does it mean to do cloud, and they've made that sort of general transition.

That makes sense. And I mean, to me, this journey is visible, how the attitudes shift, not just how we build controls, but how people thinking changes. So one thing that I've encountered in my past analyst life and also here at Google Cloud is that enough clients, enough organizations who start using cloud aren't always sure where and what type of sensitive, regulated, critical data exists in their cloud environments. So in the recent Forrester report, I felt like our attention to this aspect by means of a product we call DLP was really highlighted. But to me, the fact that these customers move sensitive data to the cloud and then don't know what data moved or what data it is, is kind of a little freaky. Like, how come? It's your regulated data. How can you not know? So how do you think this would be fixed in the future? Like, is cloud providers would fix it, or is customers going to fix it? So how will this be addressed, if you know?

I have so much empathy for this because in my role as sort of helping to protect the data protection of Google as a whole, I recognize that the challenge of cataloging data, understanding what data you've got, expressing kind of what controls it needs to have on it and sort of just really managing that is in fact a very, very deep challenge for big enterprises. Like, so this is a really substantial question, a substantial concern. And I think it's another area again in which if you have a very simple deployment where you're like, hey, we have a standalone data center, it's a big box. Historically that might have made it easy to reason about, oh, I don't really have to worry about all the different data. I just put it all in my big secure box. And while cloud might make that different, I think we can emulate that deployment in cloud, right? You can come to GCP and build a single deployment with a bunch of VMs and VPC service controls and virtual private cloud network and sort of treat it all as a big box. And you've got all your data in that box and you don't have to really worry about the sensitivity of different classes of data. The problem is not cloud versus on-prem there. The problem though is that that doesn't really respond to the transformative nature of data and the need for businesses to really make sophisticated use of data. And when they wanna make sophisticated use of data, they wanna be able to use that data in different contexts. They wanna have a lot of different applications where they expose different ones to different data. And then you've got different teams, you've got different technologies. And so you've gotta really reason about what's the sensitivity, where is the really private data, what things are controlled by regulatory environments like GDPR, how do I make sure all those things are handled correctly? You have to get into all that nuance because you no longer have the simplicity of I've got one big secure box and I just sort pour all my data into that. And so then for that, I think that, yeah, like some of the stuff that we're doing around data catalog, DLP for doing data classification and helping you find out, oh golly, I've got all this data, but what's in there really? I think those are very powerful tools where, again, it's about some of this shared responsibility model. We can't impose and just magically identify the sensitivity criteria of data, but what we can do is partner with customers to help make use of tools So that they can go on that journey and identify and really manage that, think it through, and then have really high confidence that their data is appropriately protected while being able to make use of it for the sort of transformative analysis that's powering modern business.

I love that answer, especially the stuff around data catalog and helping users use the tools we provide to understand what's out there. I want to shift gears a little bit and talk about your life in encryption and key management. When users come to us with these different concepts on encryption, and when you think about encryption broadly in the future of cloud security, Are users doing fancy encryption things for security or are they doing it for compliance? And is there a tension there?

Key management and encryption is a tool, right? It's a hammer, it's a circular saw. I may have to think a little harder on the analogy for exactly what kind of tool it is. It's a very general purpose tool that can solve a lot of problems, right? But it needs to be used with a real intent as to what the outcome is, right? So, you know, it's like, okay, great. Encryption turns the problem of managing a big body of data How am I going to keep that stuff really secret? How do I make sure nobody changes it? Into the simpler problem of now I've got a small key and I can store the key in a single service. I can store it in an HSM or something else like that. Now I just have to manage the key and I've got all this leverage to manage the security of all the data. So it's a powerful tool. It's not always well understood. It creates complexity. Now you've got to reason about the management of the key. And a lot of the problems around that are not actually simpler than thinking about the management of the data. You've got a powerful tool, but you still have to think carefully about what you want to do with it. In the past, I've seen things where customers say, oh, the data is all encrypted at rest, and they treat that like as a magic blessing that's sort of going to keep everything secure. But of course, having disks that encrypt data at rest isn't going to protect you against attacks on your active infrastructure that's making use of that data all the time. The keys are available, things like that. So yeah, encrypting your disks isn't going to protect you against a SQL injection attack or a malicious attacker who gets root on your server or something else along those lines. It'll protect you against the server being stolen. And if you take some of these disks offline, then they're protected against those things. But if you're using the data all the time, it's hard to protect it with encryption at rest. That said, encryption is a super powerful capacity. And loads and loads of these things are written into controls. As you said, compliance requires a lot of things. So I think some of the encryption controls that we provide are part of a complete set of solutions for the threat landscape and a defense in depth. Your data is physically protected at Google Cloud. Very well. Our data centers are tightly locked down. We have all these layers of security and things along those lines. So the likelihood that somebody is going to get your data by physically breaking into a data center and stealing a drive is quite low. But if anything like that were to ever happen, we also have all the data encrypted at rest. And so that's an additional control and gives you protection in depth. You know, some might look at that and say, well, the encryption doesn't add a lot of value because we've got this other control. Like, you know, why are you encrypting all the data at rest if the data centers are secure? And our approach is more to say, no, actually, you know, it is a valuable thing. It gives us more confidence. We've got defense in depth. We've invested a lot in sophisticated technology to make this tractable and easy and available by default for customers. All those things are something we're very proud of. And sure, you know, you might step back and say some things are just for compliance, some things solve real security problems, but I think it is all part of a portfolio of solutions and defense in depth.

And I don't mean to be demeaning about it and just call it for compliance. I actually think what we've accomplished in the encryption world is frankly mind-boggling.

I think it is easy for some to see it as, oh, it's just for compliance, and oh, as if that's a negative thing. But compliance and compliance regimes are an embodiment of a set of rules that give folks confidence that stuff is sufficiently secure. And they exist. I mean, look, food safety is compliance, right? Building codes are compliance, right? Fire codes and all sorts of different things are compliance in this world. And yet I certainly wouldn't want to live in a modern world without food safety and building codes and things like that. I think that would be a disaster.

Sure.

You might be able to say, oh, I've got a house that was built by somebody that was from way before building codes, but it was built well and I can evaluate all the craftsmanship. But I depend on loads and loads of stuff every day where I don't have a chance to actually evaluate exactly how it was built or anything else like that. You get in a car with an Uber driver, you fly on a plane, you don't have a chance to actually go and see, hey, did they maintain the engines well? Are the brakes set up? Is this car built safety or anything else like that? So I think we have to recognize one of the really important aspects of compliance is the fact that we have a really highly interconnected society in which there's loads and loads of dependencies in which we're all relying on the security of a bunch of other things like that. And the reason we have these compliance standards and people ask for us to demonstrate controls is because they're trying to reduce how do I assess if it's safe down to a set of rules so you can provide those statements to other parties and everybody can validate that. And sure, sometimes that means that some of those controls are a little bureaucratic, Or they are grounded in designs from when they were minted 20 years ago or something else like that. They're important parts of how we're really confident in the security of systems and the stability of things. In the same way with building codes, I don't want every new car manufacturer coming in and saying, I've got a totally new way to think about car safety, so I totally don't comply with any of those historic rules because they're crazy and old. I do something new and different.

You're saying you don't drive a Tesla.

I live in New York City. I drive a subway train. You know, it's got a lot of mass. If it hits things, that thing has a problem. I can understand when people emotionally kind of feel like, oh, compliance is something that slows us down and has a lot of requirements. But I think we really have to recognize that a lot of people very reasonably rely on being asked this question of, are you compliant, as a way for attesting that you meet a set of standards that demonstrate safety. And that's part of what powers all of this. That's at least what I tell all the engineers that I ask to work on compliance programs is that this is part of how we build trust with customers.

So this is the positivest view of compliance I've heard in maybe 2, 3 years, I would say. So this is pretty awesome. I love it. I want it on record.

We have it on record. This is a podcast.

Yes.

Well, there's that, yes. To kind of continue on that theme, if I may, one particular innovation that I know you dealt with is, of course, the approach that allows clients to keep their own keys wherever they want, sort of hold your own key approach, which we implement by means of a cloud EKM technology. So I wanted to maybe very brief value statement about this. Like, why does it matter? To me, I've written about it myself, we've written a white paper, but why is this magic? To me, EKM is magic. So why do you think this is magical for clients?

It's all part of the same portfolio. It's about how do you trust the platform? How do you really validate your certainty? What sort of sets of risks and things like that should be controlled about? What enables you to make use of cloud with just real confidence that you're in control? And that's our goal. And we said, you know, some years ago, look, we look at this and we say, If we do the key management, in the end, how can customers really be sure that things are being managed well? And that if they say, you know what, I don't want you accessing my data anymore, that they would have the ability to turn that off. And so we started off by just building the ability for customers to have customer-managed encryption keys where they could turn off the encryption key at a central KMS and using that, get the same leverage we talked about in the past of like, you might have terabytes of data encrypted in cloud storage, but you can with high confidence turn off access to it by turning off the key in KMS. But of course, like that's just a key that's in our infrastructure. It's managed in software. Can we make it better? And we said, sure. So then we went and built the same idea of storing the keys in HSMs. So now you have confidence that the keys can only be created in HSMs. They've got real physical security. There's no way for somebody to steal the encrypted key material, take it offsite and do the decryption because the HSMs offer you a physical security layer and bind it to that specific location. And so then we said, well, that's great and all, but like, you know, there's still, there are HSMs HSMs, they're there. If you said you wanted to turn off access to the keys, but, you know, we didn't do it or we were attacked or owned in some way, how would you be sure? And we said, well, there's only one way to really be confident. And that's to give customers this ability to store the keys offsite, have them under their own physical control or in a vendor that's as separate from Google as they can be. The leverage that encryption gives you is you've got this little tiny key that can protect lots and lots of data. So now we've created that same leverage. You don't want to operate an entire cloud in your own environment. You don't want to buy all those machines. You don't want to figure all that out. We figured out how to use this external key manager and the use of a vendor or yourself to keep the key under your own control. But then that magical leverage that encryption gives you, where just by managing the key, you manage access to as much data as you want. And through that, giving you the same control as if it was in your own data center, but without you actually having to embark on all those costs or anything else like that.

To me, this is magic, the fact that you use cloud, but you don't trust cloud, but you use cloud.

That's right.

But you don't fully trust it. I have a key under my bed, or as one client mentioned, under a particular mountain in Switzerland, but they use cloud as if they're cloud native. So to me, this is magic.

This is a surprisingly gushy episode. Feel the love. So we're coming towards the end of the episode, and I want to return us to planet Earth after how gushingly excited we all were this episode about different technology. Do you have something practical that our listeners can do, like top tip to improve their data security in cloud?

Well, move to Google.

Haha.

You know, I think the thing is, I would say that the most important thing you can do is be really confident about your own configuration and security and an understanding of what you're deploying and how it's controlled. So like really leaning into that shared responsibility model, understanding what things you can just trust the cloud provider to take control of, and then paying close attention to the things that you can't and sort of how to make use of those monitoring tools and things like that. As we've seen, a huge number of data breaches are due to misconfiguration by customers of customer ACLs that, you know, really we're not— I'm not trying to transfer the blame or anything else like that, but an open bucket ACL is not clearly the responsibility of the cloud provider. And so we absolutely want to partner with every customer on how to get these things right. But so often we get into situations in which, you know, somebody deploys it in wide open, the developer can't figure out exactly how to get the ACLs working quite right on day one. You know, they're just building a prototype and then, you know, whatever, 6 months later it ships to production with that same setting and then it's a giant risk. So figuring out how to assess what you've got, how it's locked down, take a look at those things and validate those external-facing controls. I think that's the number one thing that people can really do to improve security. I would say that questions about exactly how much do I trust my provider or insider risk controls or things like that are way down the list compared to those meat and potato deployment sorts of questions.

This is where the real breaches are today. And so to me, that answer makes total sense. Thank you very much for providing it. So one last question, any follow-up reading? Of course, I want to mention the Forrester report, which highlights Google data security features and their comparison to others, but any other follow-up reading from you, Tim?

You know, the thing that I would refer people to, obviously there's a huge number of resources and other things like that, but I think a work that we're very proud of and that I don't know how aware people are of is that we wrote a book on sort of how to secure workloads and how to secure cloud environments and how to secure production. It's a It's available for free. I mean, obviously it's something that I and a bunch of our colleagues sort of worked on. It came out of Google, but I actually think that similar to the SRE book that preceded it, it's not a marketing pitch. It's not just set everything up on Google Cloud. We really tried to capture a lot of the insights that we've had in running Google for the last couple of decades and keeping it secure and what we've tried to do and how to do that in production, how to reason about it, how to solve the organizational challenges. And I actually really do think it's a very valuable artifact. So that's the one I'd recommend.

Okay. This book would be featured on the podcast for the 4th time, I think. So this is a very popular recommendation.

Everybody agrees.

Yes. Thank you very much for being here and very much appreciate the answers and of course the insights.

Thank you so much. It's been a real pleasure.

And folks, we're, we're at time with that. Thank you so much for joining us today. Like I said at the beginning, you can find this podcast at Google Podcasts, Apple Podcasts, Spotify, or wherever you get your podcasts. Please subscribe so you don't miss our future episodes. Check us out at our website, and you can follow us on Twitter as well, twitter.com/TheCloudSecPodcasts. Your hosts are @Anton_Chuvakin and myself, @TimPeacock. Tweet at us, email us, argue with us. If we like or hate what we hear, we might even invite you on the next episode. And with that, we'll see you on the next Cloud Security Podcast.