11 Feb 2021 · 20 min
Anton Chuvakin, Tim Peacock, and Andrew Lance discuss why organizations struggle moving data security to the cloud. They outline four core pillars: identity-based access control, policy management with automation, comprehensive visibility of data access, and encryption with key management. Success requires integrating security teams with business, legal, and privacy stakeholders.
Chapters
Hello, this is Anton and Tim from a new Cloud Security Podcast by Google. I'm Anton. I'm involved with security product and solution strategy at Google Cloud. You can find me on Twitter as Anton_Chuvakin. Tim?
Hey folks, my name is Tim Peacock. I'm one of the product managers here at Google Cloud. I look after our threat detection suite of products. You can find me on Twitter @TimPeacock. We're joined today by a special guest who's here to talk to us about data security in the cloud. Andrew, would you be so kind as to introduce yourself for our friendly listeners?
Sure thing, Tim. My name is Andrew Lance. I'm the founder and principal at Sidechain. We are a data security-focused consulting and services firm. You can find more about us at sidechainsecurity.com. Yeah.
So we're going to be talking about data security today, which is kind of an abstract, broad set of topics. I was wondering if you two could just real quick give us a piece of your background in data security and why you two are, you know, interesting folks to listen to about data security. Sure.
So this is kind of a weird episode because this time I am actually a guest on our own podcast. So Andrew and me wrote a white paper or a report perhaps covering data security strategy for GCP. And so this is kind of the cause for this episode. Now, my background in data security kind of comes from my— mostly from my Gartner years when I covered DLP, a little bit of encryption, and some other data security areas at Gartner. I also dealt with data security before when I was at other vendors. Here at Google, as I mentioned, I deal with some of the data security product marketing and, of course, with product influence as well.
Where I got started with data security is in the file integrity monitoring space way back in the day. So we started doing that and did a lot of work in the federal space, as well as with large financial institutions in file integrity monitoring. That kind of morphed about, I don't know, 10, 12 years ago into the cryptographic space. So since then, I've been mostly focused on cryptographic technologies around data protection, cryptography, encryption, key management, HSMs, PKI, that whole world.
Awesome. So you two have enough background in this that this isn't an inappropriate set of topics. Given how long you two have been in security and the number of papers that you've probably seen over the years, Anton, I gotta ask, why do you think this paper is gonna make a difference in security?
So this paper was born out of an idea that people who move to the cloud occasionally get a little bit lost as far as how to do data security in this new reality. So sometimes people don't know how to actually move their data security program, data security effort to the cloud computing environment. In other cases, company maybe started in the cloud and they're literally starting launching their data security effort as they start their operations. So to me, I noticed a lot of confusion, uncertainty. And so the paper is kind of an attempt to answer this very question. Of course, we use examples from Google Cloud, but the idea is to help people set their minds to the right frame when they do data security in the cloud. I'm sure Andrew has more fun things to say.
Funny you mentioned that because when we started cooking this idea up and you were kind of sharing your vision with me around this, it mirrored exactly what we're seeing with the clients that we help move to GCP and other cloud platforms. You know, oftentimes the business is moving to the cloud. That's a given. That's well in motion. The security team is running, trying to maintain adequate security standards as the business moves forward. And in a lot of cases, I mean, there's, some struggle and challenge there. I'm sure we'll talk about, you know, these different things that come up, but, you know, things like, what do I have to do different for the cloud than I had to do on-prem? What's the tooling look like for cloud data protection that I may or may not have had on-prem? You know, all these kind of decisions have to be made sometimes in real time as the organization's already moving there. So yeah, I mean, there's some significant challenge there, and we are hoping that the output of this paper gives some guidance in that area.
So this is really for security teams kind of a case from going from visual flight rules into instrument flight rules while they're moving with their data. So given all that, what, what exactly is different about the cloud, Andrew? What are the big salient differences security teams should be looking out for?
Yeah, well, as we were developing that, one of the big ideas I think that came up here is a realization that identity is core to data protection in the cloud in a way that it isn't so much on-prem. You know, with on-prem and kind of your traditional way of thinking about data protection, of course, you have these fundamental things like, well, I need to classify my data and I need to be thinking about my data in terms of its overall lifecycle. And then I have to apply appropriate security controls and technologies to protecting it, but I'm protecting it in the context of my infrastructure, my firewalls, my data centers, and so on. As we shift to the cloud, the paradigm changes. And in public cloud, what Anton and I developed were these pillars. These are core fundamental things that have to be addressed in the cloud that are unique to the cloud. And so you have these ideas where identity is absolutely central. Managing policy is critical in a cloud infrastructure in a way that it normally isn't in on-prem and things like that.
I would say that this is obviously all valuable, but to me, a lot of the confusion, a lot of problems is people still map their mental models from the data center to the cloud. So certain elements, data classification, again, we don't really lose relevance. I mean, data classification existed on-premise, and of course it's used in the cloud, but reliance on network controls have transformed. The expectation that there would be many, many firewalls between your sensitive data and the Quote unquote hostile internet have changed. As Andrew mentioned, the role of identity shifted from oh yeah there's a role to like sometimes that's the only barrier between attackers and your sensitive data and possibly regulated data. These are kind of maybe highlights to the same, but I wouldn't say that some criteria and some factors disappeared. Well, maybe physical security. If you are in the public cloud, physical security is taken care of by Google, so there's no need to. worry about it, but there are certain things that escalated in importance. Again, identity, visibility factors, that type of stuff.
Yeah. I've certainly seen security teams preparing for a transition to cloud and working really hard to tie themselves into knots trying to bring traditional network-centric security thinking to cloud security. It's a hard habit to get out of. So what guidance would you have for a security team or a data owner working with a security team to help them feel comfortable in a world where their security is not predicated on the firewall? How do you get them to make that leap from firewall thinking to identity thinking?
That is a tough one. You know, notice we are both silent for a second because this is a genuinely tough question. So let me try to give a few things we highlighted in the paper and a few things that we perhaps think about. So one is we're never going to say that network security is irrelevant in the cloud. We are just saying that sometimes identity is what you reach for and kind of training you to trust the identity-based controls over just network-based controls is kind of something that will happen in parallel with your journey to the cloud. If you expect 5 firewalls between your database and the internet, you're not going to have it in the cloud. However, to me, that testing and trusting the separation that top-tier cloud providers like Google have built for securing the data is perhaps where I would spend my time. I would spend time thinking, okay, so if I do strong authentication, if I do other things, can this data ever fall into attackers' hands? Frankly, sometimes the answer is no. Sometimes the answer is yes because somebody made a mistake. But to me, there's a little bit of a mental translation from what I have on-premise to the cloud. And that's where I spend my energy, kind of absorbing this and realizing that I'm okay without 3 layers of firewalls, But I am perhaps even more secure.
Well, I think Anton's right. You know, when you're in your own environment, you're on-premise, that kind of thing, you know, you're having to create this kind of holistic security model, which in many ways is kind of a race all the way down the stack. And you keep kind of digging down, down, down, and then rebuilding your security from the ground up. Well, that's not the case in a cloud like Google because Google's bringing an immense amount of security to the table from which then you are building on. And so I feel like another kind of shift in mentality with security in the cloud is it is a shared responsibility, and the whole burden is not on you anymore. And so realizing, you know, what the platform is providing and then building from there, leveraging the service capability and the tooling capability and, you know, the policy capability, visibility, logging, all these things at your disposal. Yeah. When you craft your security program around the availability of those things, it becomes much different. And quite frankly, it becomes very powerful because all of these services available to you, especially in a platform like GCP, they're for the most part intuitive. And even modest security teams can really take these things a long ways in a way that just couldn't be done with a legacy infrastructure on-prem. That's how I'd kind of capture that.
That all makes a ton of sense. And you mentioned 2 things I want to pick on. One is this notion of things being intuitive, and the other is the notion of going all the way down the stack. People ask a lot of questions about key management, and there's a lot of key management options. What advice would you give a security team or a data owner thinking through their key management options?
Key management is always a challenge in some ways, and there's a lot of different ways of thinking about it. For example, A lot of key management has to do with kind of compliance-related activities. And so if that's how you're approaching key management, you're thinking, well, I have to do certain things with my encryption keys because of these kind of compliance mandates or regulations that I'm trying to meet. Well, that's going to drive a certain set of behaviors, as opposed to maybe you're having to do key management from an operational standpoint. You're generating keys, you're managing keys, you've got a lifecycle around it because you have to protect data and you've got a lot of lifecycle around the protection of that data. So that will drive a different kind of behavior. Then of course there could be, you know, a combination of those 2, which there commonly is. So you take that whole landscape and I think that at least when we're working with clients to get their arms around how to do key management, you really have to Take all those things into consideration, understand what the drivers are, you know, and different behaviors are for your different goals around why you're using keys, how you're using keys, and how you're managing the lifecycle of them. And then, of course, a platform like GCP offers a tremendous amount of capability and flexibility with how you're actually going to do that.
And I would also add kind of a fun fact that when we were working on the paper, we initially thought that encryption and key management would be a separate pillar because it's so central for the cloud. But then we realized, actually, it's even bigger than the pillars. It's sort of an enforcement mechanism for pretty much everything in every pillar. We encrypt passwords, we encrypt credentials, we encrypt secrets, we have key management for various types of data, we enforce access controls. It sort of helps visibility by doing a few other things. So to me, encryption and key management ended up being a layer under the pillars, if that makes sense. But I also want to say that some of the key management complexity apart from the compliance angle also maps to challenges like trusting the cloud provider, trusting their processes, trusting the maybe environment around them. So in other news, we've been dealing with a Google product called External Key Manager, where a client has to own the keys and manage them. And the product aimed at solving the problem of client not quite trusting either Google or the environment around Google with the keys. So now we have a choice. You don't like us to have the keys? You have the keys. That's perfectly fine. And to me, this adds to the menu. And there are certain scenarios and use cases where certain menu options are the right answer. So to me, there's a little bit of complexity, but there's also a wide spectrum of cases where they have to cover.
One of the things I love about External Key Manager is the key access justifications feature that they shipped with that. where Google tells you, why are we asking for this key? And we give you, the user, the ability to say, you know what? I don't like that reason. No key for you. I think that's just so great that we're able to be transparent about that. And that's really just, like, baked into the core of how the system works. So speaking of detective controls and visibility, how do you think about wrapping your minds around a monitoring program for the data you've put in the cloud? Because it's one thing to, you know, say you got rid of your firewall, you switched to Identity, You've got your key management in place. How do you know your data's still there? How do you know it hasn't gone anywhere?
So first, I wanted to touch on the fact that you do need either increased or at least equal tracking for data access in the cloud. Because ultimately, if we did just talk about the identity, how it's central, that means there are usernames, there are accounts. So which account, which username is accessing the data with what frequency, what type of data, what they do with it? All implies a deeper level of monitoring at that type of a data level. And in the old world, we would say you need DLP. Today, you may need other controls. You may need types of log analysis. You would need data awareness provided by DLP. But you also need a way to analyze where the data is moving, what type of data is moving, who owns the data. So to me, the monitoring detection angle, the visibility angle, the overall pillar is visibility. is quite central to that type of operation in the cloud.
Yeah, I think another trend to build on that is absolutely critical. Its core is around the world of kind of DevSecOps and implementing security policy in code and with a high level of automation. That simply cannot be done unless you have visibility and you have the ability to grab what's happening and then make policy decisions based on it, ideally through automation. So it's just another reason why cloud platforms like GCP that provide a lot of visibility, a lot of opportunity to see what's happening and then make decisions and automation around that, it's very powerful.
As a person who owns some of these tools, I'm super excited about the ability to go from detective reactive situations into preventative policy as code sort of situations where you can help a security team find the rough edges in their posture and then straighten that out for the future so that those mistakes don't happen twice. It's okay to make mistakes, but you got to learn from them. And ideally, you learn from them in a preventive, enforcive way going forward.
As a funny side comment, you can also overdo it because some of the detective controls are really meant to give you a possible indication of an anomaly, like this type of access increased from a user. It doesn't mean that you can automatically say, ah, that's too much access. We'll just cut you off. It does involve a human in a SOC or in some other facility looking at this and kind of thinking about it. So to me, detection to prevention journey is a useful journey, but also it occasionally blindsides people when they start thinking, I want to convert every detection control into preventative control. And then machine learning, the Yuba stuff shows up and it's like, wait a second, it's a lot more nuanced. So you can't really just jump straight into, ah, we're going to block.
There's definitely an Uncle Ben principle at play there of great power comes great responsibility for security teams to be a partner in keeping orgs productive, not an impediment to moving things forward. So speaking of partnership and who security teams and data teams work with, when an org is planning this kind of data migration, who are the people that they need to have in the room to make this succeed at an organization?
What we're seeing when we are working with clients in this area is, like I said, kind of at the beginning of this, oftentimes the realities is that the, you know, lines of business and other parts of the organization They have already started their migration and adoption of the cloud, sometimes very heavily. And so, when that's the case, security teams obviously need to be working hand in hand, and lines of business need to be working with security teams to make sure that the migration of workloads, of data that's going along with that, sometimes, you know, can be very sensitive data and sensitive workloads. As all of that is migrating to the cloud, yes, there's business objectives that have to be accomplished there. There's economies of scale. There's efficiencies to be driven, you know, all the great benefits of moving to public cloud, but all of that will be for naught if it isn't grounded in a security posture that adequately protects those workloads. And so, as teams are working together and security is trying to inject what it needs to, to adequately protect those things and implement the right security controls, you know, it very much is a team effort. And that's the outcome really that you want to see. It is a collaboration. That's the success factor, at least that we see.
That ends up being a lot more nuanced because frankly, security team alone cannot do it, but security team also cannot sometimes accommodate too many stakeholders. And we also have the other possible curveball, privacy requirements, which we sort of did not touch in the paper by nicely and cleanly pushing them to the side and saying they're important, just not the focus now. But it does imply that a big program that covers data protection would include security compliance and privacy. And that even further increases the number of people you need to engage from data owners sideways to legal and to other teams that may have to do with other types of challenges. This is hard, and this is why you're not going to lift and shift or copy your program. You cannot just say, here's my data security effort, I'm just going to stick the word cloud to it and it's going to work. It really won't. And that's a big part of the paper.
You can't just put the word cloud in front of your existing thing and hope it works.
It's a different ballgame and it requires Just so listeners are aware, in the paper, we both addressed, you know, look, if you have a legacy program and you're looking to shift that to the cloud, there's a section that's a checklist of questions to be asking, things you need to be considering that you can use to, you know, kind of pivot your program out to the cloud. And we also touch on, look, if you're starting from the ground up and you're cloud native from scratch, Here are the things you need to be considering as well. So we try and kind of capture, you know, where a customer might be at in terms of their migration and adoption.
Well, this has been a much more fascinating dive into the topic of data security than I expected. Certainly more interesting than the dryness of data security might suggest. And Anton, Andrew, this was just fascinating for me. So thank you both so much for appearing on the show. We're going to post links to these podcast episodes. They're available everywhere that you can get your podcasts. You can find Anton and myself on Twitter. We're also on our podcast website with the URL to be inserted. Going to post a link to the paper so that you can download it and tweet at us or email us your thoughts. And if you're clever enough with your thoughts, we'll invite you on the program to tell us why everything we said today was wrong.
Thank you very much. Thank you both.
Thanks, folks. Security.
More from Anton


EP289 Software Engineering vs. Software Craft: How Google Scalably Eliminates Classes of Vulnerabilities


EP288 CISO Tested, Board Approved: Cloud Resilience with General Mills CISO Noah Korba


EP287: Creating Trust at Global Scale with Local AI: Reken-ing with Shuman Ghosemajumder


EP286 Building an AI-pilled, solo vibe-coded, Clickhouse-based SIEM with Dan Lussier


EP285 Scaling Lessons from Leading the NSA to Defending the World with Morgan Adamski


EP284 Closest Alligator to the Canoe: How Transforming SOC Became P0 for Lloyds Bank


EP283: How Google Cloud CISO Chris Betz Uses LLMs to Defend Billions of Users from Vulnerablities


EP282: Debating Coupled or Decoupled SIEM with Alex Hurtado and Christopher Witter


EP280 Hyperscaling Cloud Security: Wiz Joins the Cloud Security Podcast by Google