EP47 Megatrends, Macro-changes, Microservices, Oh My! Changes in 2022 and Beyond in Cloud Security

- Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here are myself Timothy Peacock, the product manager for threat detection here at Google Cloud and Anton Chuvakin, a reformed analyst and esteemed member of the Cloud Security team here at Google. You can find and subscribe to this podcast wherever you get your podcasts, as well as at our website cloud.withgoogle.com/cloudsecurity/podcast.

If you like our content and want it delivered to you piping hot every Monday, please do hit that subscribe button. You can follow the show, subscribe to our updates and argue with your hosts on Twitter as well, twitter.com/CloudSecPodcast. Finally, while it pains me every time I say this, Anton and I are now on a brief break for the rest of December and early January, but don't worry, new episodes will be coming out.

Some of them are even already recorded, so stay tuned and see you again in the New Year. We have a very special episode today. We are co-hosting, co recording, co distributing, with Carter from the GCP podcast. We are co-mingling and co-operating, and this is appropriate because today's episode is also co-opting content from a coordinated co rerelease blog post by Phil Venables. So with a mega run of co-branding, Anton, what exactly are cloud security mega trends?

- So Phil had this amazing, super structured, super well organized set of thoughts, which he's put into paper and of course, to audio in this podcast and GCP podcast about kind of like a massive trends that drive cloud security. Of course, things like economies of scale, shared faith, competition that leads to the race to the top in security are some of them, and you'd see them in the episode.

But to me, some of this more interesting things, is it kind of again reinforces how much security magic is possible in the cloud. How much cloud security is really different`. So, to me, this is like the meta thought over the mega trends, maybe.

- That possibility of difference is why I came to Google. I came here because I honestly believe that with the shift to cloud compute, we have this generational opportunity to change security outcomes. And already, I think we're seeing how that's starting to play out.

- That's definitely one theme. And of course, as you'd see me ask this question in the episode, are there other constructs that are quite different? Again, the whole shared faith thing. It did confuse some people, but I think Phil has the clearest explanation for shared faith in the coming episode. And I'm not gonna do any spoilers, but it's gonna be really useful.

- Well with that listeners, let's turn it over to today's episode with our guests, Carter and Phil.

- Hi, Phil. Nice to meet you. I'm excited about this and I'm hoping you can explain this whole cloud security mega trend. What do people need to know about it? And even better, maybe we can explain is cloud security actually more secure than just having security on your data center?

- So one of the motivations for thinking about these cloud security mega trends is we get asked a lot, is cloud more secure than on-premise? And you know, it's hard to give a general answer, but what we're seeing more and more is the security features in the cloud are typically more secure than most on-premise environments.

You could obviously find very particular cases that there may be an exception to that. But generally as each year ticks by we're seeing what you can implement in the cloud, whether it's default levels of encryption, high degrees of security on hardware, trust, improved management of software, supply chain risk, and many other risks is preceding a head of what organizations are typically implementing or sustaining on-premise.

And at one level, you know, when we get asked about that, you know, why is that the case? Is it because we invest a lot more in security, is it because we have large numbers of really great security engineers? And, you know, the answer to that is yes. But there's something deeper at play that we observed.

And when we sat back and thought about it, we realized there's a bunch of what kind of people call mega trends in various other fields. But, you know, mega trends for cloud security are really at play here. And these are things like economy of scale. So as Google Cloud, and in fact, all of the hyper-scale cloud providers get bigger, and bigger, and bigger, the unique cost of security goes down.

So trivial things, for example, what we just deploy by default security chips in our servers that do boot security and firmware validation and many other things, the unit cost of that at the scale we operate is a lot lower than the unit cost than organizations can implement on-premise in a smaller scale environment, just to pick on one example. And so that economy of scale drives a higher level of baseline security in the cloud. You know, we talk about shared faith, so we move from shared responsibility to shared faith.

The cloud providers have much more intrinsic motivation to drive security higher than your typical enterprise software providers in an on-premise environment. There's high degrees of competition between the cloud providers. So again, I think for the first time, at least in, you know, in my memory, you've got some very big technology companies competing every day to increase the levels of security in their offerings.

We also can think of cloud as this digital immune system where many customers can kinda sit back and take every update the cloud provider gives, and the cloud provider's getting the rationale for those security updates from vulnerability and threat research from inputs from other customers. And so this collective network effect drives up the security of the cloud in a way that's not typically been seen in on-premise enterprise software. As well, it's a software defined infrastructure.

So it's more naturally driven to be more continuously control assured. It's actually, despite what some people say, it's a simpler environment with less complexity to manage and over time it's becoming more simpler and more automated and autonomic to manage. Cloud is more prone to having increased deployment velocity, not just for the cloud providers themselves, but that pattern of increased and smoother CICD pipelines to promote increased velocity of featured deployment translates through to what customers can do on it.

Again, quite differentiated from some of the natural dynamics in historical on-premise environments. And then finally, it's both sovereign and sustainable. The sheer geographic presence and scale of the cloud means that people have a lot more options to explicitly choose the locations of deployment. And some of those locations of deployment may be aligned around what their kind of sustainability goals are as well.

And this is again where we see a mega trend of sustainability, security, and resilience coming together in the same way. So net-net, you know, those mega trends are gonna keep driving forward the improvement of cloud security, but also those mega trends work in the opposite direction to the shrinking scale of some on-premise environments.

- That's all very interesting. And I agree with you that cloud has all of these natural properties that make it more secure. One of the conversations I end up in more often than I would've hoped given how I would hope my life to go, is I end up talking to CISOs who have this, you know, long list of requirements and we're missing two of them or we're slightly a skew on two of them. How do you get people out of that tree? And how do you get people to look at the holistic advantage rather than these one or two nets that they get stuck on?

- You know, this is an interesting comparison, because we take this very, very seriously when customers have feature requests that drive control improvement and drive how we improve controls in the platform to serve their, it could be their compliance needs, their own control needs their own securities. The interesting thing sometimes when you look at this is what happens a lot.

And this is a great dynamic is when customers are looking to move from on-premise to the cloud, they're using that as an opportunity to significantly upgrade their security. And so they set the bar quite high for the cloud, which I think is appropriate and is healthy for the industry. But often in many cases, those controls may not actually be already implemented in their on-premise environments.

And so there's an interesting dynamic at play where sometimes certain cloud products can be deemed to need security and control improvement, but it's not because they're necessarily weaker than the on-premise environment. It's just that customers are appropriately realizing as part of the move to the cloud, they can modernize their environment, they can upgrade all their controls and they can aim to hit the controls they've always wanted to implement, but have not been able to do.

And again, that dynamic comes back into this digital immune system concept is, you know, we welcome those feature requests because they drive improvements in the platform which benefits everybody, which makes it more likely that more customers will want to trust their workloads on the cloud.

And so I think that's a good dynamic, but it's sometimes not a great direct comparison of the on-premise environment versus the cloud environment because those customers are taking the opportunity to upgrade controls significantly as part of moving to the cloud.

- Well, that makes sense. And to me, the whole race to the top and immune system is worth more of a discussion. But one thing that you mentioned in your answer, and of course in your article is that there is concept of shared faith. And I've met enough people who are frankly quite confused about it.

Like usually when I hear shared faith, I think that it must involve insurance. But then again, I think insurance, and if I might insurance my house, my house burns down, the insurance guys house didn't burn down. So I don't see shared faith. So could you give a crisp practitioner level, maybe leadership level explanation of shared faith one more time?

- It's interesting because you know, we have communicated shared faith in the context of our risk protection programming. You know, where we partner with insurers, you know, specifically Allianz, Munich Re to give, you know, the access to insurance based on customers being on our platform and having transparency into how they're configured that those customers provide to the insurance.

And collectively that is a shared faith because we stand behind in our partnership with the insurers based on how the insurers have looked to our platform. And so there's definitely a shared faith. But it's a good question because the way I kind of think about this, and, you know, there's a lot of people do here at Google cloud, it's a lot more broadly.

And so I think the shared responsibility model is obviously kind of contractually correct and the cloud provider runs a secure infrastructure and then the customer is responsible for configuring themselves securely in the cloud. And so there's clearly a delineation encoded in the shared responsibility model that I think is quite well accepted.

The problem is when that shared responsibility model becomes in some sense, thought of as a shield to separate whether the cloud provider should provide significant degrees of help to customers in helping them run securely in the cloud. So when I kind of think about shared faith, it's about how do we reach across that line of shared responsibility and partner with customers to help them run securely in the cloud.

And in practical terms, this is things like really looking hard at our secure defaults and questioning are we doing enough to ship with full safeties on, so that customers may then ratchet down the security, but they don't necessarily have to quickly ratchet up the configuration of controls. And I don't think any cloud provider is perfect on this. I think everybody's working hard to look at those secured defaults.

Then again, we also have to think about shipping blueprints, and landing zones, and all of the other configurations and recommended configurations that come with configuration code. And then also thinking about consistency of how the products work together. So if you set a policy at one layer in the stack, you shouldn't also have to replicate those policy settings further down the stack.

So there's a whole array of things where we can improve that feedback loop. If customers are having difficulty sustaining security in the cloud, well, it may be on their side of the shared responsibility line.

When you think of it through a shared faith lens, we want to internalize and then say, could we be doing more in the products in the configuration, in the guidance, in the training, in the whole environment to make it easier for them to run securely. And so I think ultimately shared faith's not necessarily a specific thing. It's more of a philosophy of how we partner with customers to improve security.

- I would think that shared faith requires shared incentives. Do you see us shifting the incentives to invest in security? You know, tooling process, people with orgs that are migrating to cloud, how do we help organizations be correctly incentivized here?

- We could probably have a debate on that as to whether it truly does drive you to shared incentives. I mean, I think ultimately the shared incentive is if customers feel they can run more easily at higher levels of security without a significant overhead of sustaining that control.

Then they're more likely to bring more workloads and more data to the cloud, which is obviously of commercial value to the cloud provider. And therefore you can imagine some kind of flywheel effect is the more you improve default security, the more you raise trust levels, the more customers are willing to bring more workloads to those environments. Which attract more workloads and more improvements in security.

So I think the incentives are that the shared faith model drives a closer partnership between the customer and the cloud provider to make sure that they're more able to bring more workloads to the cloud.

- Thank you. That helps clear up the shared faith model for me. But there's something else you brought up a few times already that I'd really like to dig deeper into. You said seeing the cloud is a digital immune system.

When I hear that, I think of maybe a self-healing system or a system that can update. What is it and how does this relate to like the typical practitioner, like someone that's doing security or someone that is a developer?

- So again, it is a bit like I was saying at the beginning. So, you know, when you think about just picking on Google Cloud, because that's what we know. Every month we're shipping new security features, not just in our cloud security product set, but new security compliance, privacy, resilience, and other control features across the product set, you know, in all of the products.

And then we're also shipping upgrades, upgrades to defense in depth, upgrades to close potential vulnerabilities that may have been hypothesized or may have been notified to us, hundreds and hundreds of upgrades each month. And the sources of these, you know, they come from our own vulnerability research, our own threat research, you know, feature requests will come in from ourselves about what we believe we need to build into the platform.

The feature requests may come in from customers, security teams that are driving the improvements in the platform as we talked about earlier. So collectively, there's this massive inbound flow of drivers to keep adding security features, security capabilities, defense in depth, to close out potential vulnerabilities, to reduce exposure to whole classes of potential future attack.

And generally what this means is if you as a customer, and this could be not just a small, medium size customer, it could be large customers, not all organizations have huge and sophisticated security teams. In many respects, if you just sit back and take every update, you're gonna get the benefit of that entire ecosystem of driving improvements in security.

I can't remember a time when we've, you know, in any of the more traditional on-premise software enterprise, where that dynamic has existed to create that perpetual feedback loop for driving up security. Now, of course, the big thing everybody has to do is to take the updates within some kind of reasonable risk managed way. You only get the benefit if you're tapped into the system, as it were

- One of the interesting things about this, you know, bringing together of security outcomes, and security products, and security fundamentals is you have sort of aggregated risk in all of your eggs in one basket when you rely on your cloud services provider for security.

Now this is, you know, near and dear to my heart because I'm personally a security product creator here at Google. So what do you think about the argument that maybe you shouldn't rely on your cloud provider for all of the end to end security and you should instead diversify?

- And this comes up a lot in discussions by the way, on social media, in the industry when people say, "Yeah, I trust Google has the best security, but I don't trust one company to provide security for me. So I will buy third party stuff." Again for the questions here. So I'd love to hear your perspectives.

- You know, as many of you know, I've spent most of my career on the enterprise side of the fence trying to deal with a large on-premise environment and integrating multiple cloud providers. There's a few ways of looking at this. Which is to say, I think you should be able to trust your cloud provider with implementing the controls they offer in terms of the basic levels of control.

Like for example, you know, by default we encrypt all storage by default, we encrypt all communications. I find it hard to imagine there'd be a desire to inside a cloud environment, additionally, implement other layers of extra control on top of what the encryption claims are that are provided by the cloud provider.

Now then, you know, there may be edge cases to that. There may be requirements for layering in different algorithms. There may be other requirements for other controls. But generally speaking, I think people are willing to trust because of the transparency we provide the basic implementations of the controls in the cloud platform itself.

As you start moving up the stack, you know, you start to see a lot of customers willing to consume the security features further up the stack, where they have more easy choices of layering in third party products. Now, the way I kind of differentiate this is really depends on whether you view this as a primary control or a check and balance.

Now, the way I kinda look at this is I think you see a lot of customers are quite happy to rely on the security features at least of Google Cloud, but what they then do is they will procure a third party product or service that acts as a check and balance on the configuration they're running in the cloud. It's not an independent level of control implementation, it's an independent level of validation of the control configuration.

And again, that also has the advantage in some respects that can work across multi-cloud, you know, and in some cases, some on-premise environments. I think it's one of those things, it's more about not additional duplication of control versus what the cloud provider has. It's more about the check and balance of assessing that the claimed configuration that they think they have in the cloud is actually running configured in the right way.

- Thank you. And while I have you here, I wanna ask something a little bit different. This industry, it has so much venture money coming in where it seems like there's people that feel like it's gonna be a good return on investment.

What are ways that someone like me who's not necessarily steeped in all the security knowledge, what should I look for to understand the market and where it's going? Could you may be quickly just explain some key signifiers?

- I don't have the data in front of me, but you know, there's a huge amount of venture investment going in the cyber security. And so I think all of the listeners today are probably kind of overwhelmed by the number of new startup companies across the whole spectrum of not just cyber security, but information protection, technology risk in general.

And I think the other aspect of that is there's many products that are out there that you look at them and you just think, "Well, look, that's just a future feature in a cloud platform." And that's probably true for a number of the products, but there's some other products that may actually end up being truly differentiated because they add that check and balance component I was talking about before, or they add some feature that is available in the cloud, but they want to be able to run and bridge it across multiple clouds and into an on-premise environment.

It's good that there's a continued diverse ecosystem of venture funding and venture funded startups in this space. And, you know, we partner with a lot of them. There's a lot of them in the cloud marketplace, you know. We're working with of them in terms of making sure that the platform is friendly to those products. But, you know, I think it's gonna continue to evolve, but if we're totally candid, at least some of those are really just features waiting to be implemented by cloud providers.

- To me, it definitely makes sense as an argument. But one other thing to mention, as we're discussing this is much of this may affect bigger parts of the world. It's about buying things to secure a business. There are elements of like country sovereignty, geopolitics that come in.

So that's softer sovereignty and other things that you mentioned in the answers also matter, like why is cloud better for it? Why can't I just write my own software, do things on-prem for my own use? How do we combine this type of innovation with being able to address the needs of sovereign customers?

- Software sovereignty, in other words, the concept of when you're kind of in the cloud, you're not locked into cloud, is a thing that we spend a lot of time thinking about. And which is one of the reasons why overall we're very focused on open standards, open source, and again, our investments in multi-cloud solutions.

I work on Kubernetes and ethos and the container based environment have been very much kind of driven around that ability to give customers a lot of flexibility. But I think if we're all honest with ourselves, as you start moving up the stack with some unique, competitive advantages on some of our solutions, then you get beyond that portability and think ultimately it becomes a customer choice.

And also, there is depending where you are in the stack. So if you're running open source, open standards based container type environments, you've got a lot more portability than you would have if you were using a very specific feature in a very specific solution from a particular cloud provider. So I think it just depends.

And ultimately, I mean, I think our goal and it should be everybody's goal is to support customer's choice in this respect. And I think, you know, we'll continue to partner with customers on the whole concept of not just software sovereignty, but the broader topic of digital sovereignty.

- That makes sense. I mean, that's a tough area and I expected in a few years, we'll still be dealing with this. And from this area, I wanna lead to our final question. When I read some of the stuff, when I hear about the security pillars, sovereignty, I always think that it's not about just reducing risk, just security, but it kind of attacks trust.

I've also seen examples of solutions that we build, that were very secure from the objective point of view, but customers just did not trust them. So could you quickly give us sort of some hope, some positiveness. Hey, it's a security podcast or at least our part. Why in the few sure this would increase trust and not just security?

- I can't remember who in cloud said this, whether it was one of you guys. But that whole notion of you get to trust things more if you don't have to trust them. What I mean by that is if you are keeping under control, for example, even like the technical level with our kind of external key management solution and our encryption solutions.

If a customer is managing the encryption keys and the cloud provider has to come to the customer for approval to access things. And the customer releases those keys in support of a key access justification as we support on many of our products. That's an ability where the customer then doesn't have to deeply trust the cloud provider because they retain a sense of control while still getting the benefit of the whole cloud platform.

And so that's one specific technical example. Another example would be the work that we do to bring transparency to what's going on in the cloud, not just from a technical access log, access, transparency perspective, but all the way up through to our compliance frameworks, the attestations, the certifications, the partnership with customers on going through how our controls work, the documentation we put out on our websites, all of the blueprints, and the white papers, and everything else.

So again, I think transparency and an explanation of how our control frameworks work, the defense in depth, not just against attack, but defense in depth from configuration errors. All of this collectively gives customers a degree of trust, either based on the fact that they retain some control for certain aspects.

And then for the rest of it, that they have a high degree of transparency backed by independent attestations of the controls that we're claiming through our compliance frameworks. I think together that promotes a degree of trust, but ultimately it's fundamentally all about the partnership with customers and engendering that trust through supporting their security goals and their risk management goals.

- Perfect. Thank you very much, Phil. This was as always quite amazing. And thank you very much for enlightening both of our podcast audiences with some of the stuff. I can see how security practitioners, IT practitioners, developers will find something to think about and something to do. Thank you very much for this.

- Yeah. Always a pleasure. Thanks guys.

- Wow. I learned so much. Thank you, Phil, Anton, everyone.

- 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 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 @CloudSecPodcast.

And of course your hosts are also on Twitter @anton_chuvakin and @_TimPeacock. Of course, we'll try to keep you entertained on Twitter while we are on a break. We are on a break until January 2022. 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. Or we can argue with you on Twitter before the next episode airs. See you on the next cloud security podcast episode, and of course on social media as well.