EP145 Cloud Security: Shared Responsibility, Shared Fate, Shared Faith?

Security.

This is the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here are myself, Tim Peacock, the Senior PM for Threat Detection here at Google Cloud, and Anton Chuvakin, a reformed analyst and senior staff in Google Cloud's Office of the CISO. You can find and subscribe to this podcast wherever you get your podcasts, as well as at our websites, cloud.google.com, If you enjoy our content and want it delivered to you piping hot every Monday, please do hit that subscribe button. You can follow the show, argue with your hosts and the rest of the listeners all on LinkedIn. Anton, what are we talking about today? This is a bit of a mind-bending episode, right?

This is going to be very mind-bending. So if you are listening, should we say don't operate heavy machinery if you're listening?

I don't know.

That's a little pushing it.

I don't think we can tell our listeners to sit down. Everybody's like, I listen while walking the dog.

Listener, you must sit down, otherwise expect shock. I don't think we are quite in that territory.

But maybe don't open your backhoes, which open gateways to hell during this episode.

That's right. Just basically put it on pause.

Got it. Okay. So what are we talking about? What's this all about?

Well, if somebody wakes me up at 3:00 AM and says, Anton, summarize this episode, I would say that it's about the shared nature of cloud security. But I think we got to a very profound depth of that topic.

Is this the episode where I don't know what cloud is?

I fear that you're right, Tim.

Yes.

It is the episode where we question the very meaning of the fabric of the cloud. Sorry, I'm trying to sound ominous, but I sound clownish instead.

Yes.

Well, listeners, ominous versus clownish. Maybe with that stunning revelation that we don't know what cloud is after 3 years of hosting a cloud security show, let's turn things over. With that, listeners, I am delighted to introduce today's guest. Today, we are joined by longtime listener, first-time caller, Jay Thoden-Van Velvissen, Strategic Advisor to the Chief Security Officer at SAP. Jay, delighted to have you joining us today. Thank you so much for making the time.

Likewise.

I want to kick off with maybe a high-level question, which is appropriate for somebody with a title like yours. Shared responsibility is this somewhat fuzzy thing. What is shared responsibility? And when it comes to thinking about that, what are some of the challenges we see people running into?

Shared responsibility is this idea that makes it seem as if we're doing things together, but actually we don't.

That's brilliant. I'm sorry for interrupting, but it's actually a really good summary of many of the problems we've encountered.

It reminds me of a problem in political science where we have these power-sharing agreements between factions in countries, and they often end up not being power-sharing, but just like Power fighting agreements. So Jay, could you elaborate on what the actual problem is? Because Anton and I both agree violently.

Absolutely. I prefer actually separated responsibilities. And cloud providers have these nice diagrams. Some are clearer than others. Some suggest that there's collaboration where there's not. The idea is essentially that the cloud provider takes care of some aspects of security, whereas the user of the cloud system takes care of others. The practical reality is that in the mind of the consumer, that suggests that you're doing a lot more for us than you actually do. That's not to say that you're not doing really important things like secure physical data centers, make sure that services exist, that the cloud API works and doesn't get hammered. But it does mean that as a customer of cloud infrastructure providers like yourselves, we are responsible for everything that we create in the cloud landscape. I think I've heard somebody describe it as you're responsible for everything that you configure. Like, you get this empty virtual data center that you get the keys to, but aside from a default VPC, there's nothing there until you create it. And everything that you create, you have to actually secure. And I think that's quite often misunderstood.

Everything the config touches is your kingdom.

That's right.

But also everything that you create, you're responsible for it. Actually, that's a much clearer take than you hear from some cloud providers sometimes. Because what we encounter is usually people quote very easy examples. Like they say, hey, I am the cloud provider. I do hardware and physical. You are the client. You do the apps. And everybody nods violently and everybody says, yep, yep, yep, very clear. And then I say, threat detection. And then it's like, well, wait a second. To quote you from a minute ago, this separated responsibility cannot really be separated. In this case, it is very joint. Hardware, separated. Application you just wrote, separated. Threat detection, eh, not separated. So how do you deal with that?

You don't even have to go that far, right? The 3 common sources of security incidents are cloud misconfigurations, vulnerabilities, and leaked IAM overprivileged stuff. Like, it's been like that for 5 years. It hasn't moved at all.

The first CSPM, 2013, so 10 years.

There you go. But all of those are things that the user of the cloud services is responsible for, right? Like, in a way, it's happy for our customers that we sit in between so that we essentially become, to joke, a giant platform engineering team that then provides applications so that the customer doesn't have to take care of infrastructure and key management. Network configuration, and so on.

So, I guess the good tactical question would be, so, for the areas where the separation is unachievable, how do you think about shared responsibility? If you think, you're right, the top areas like identity, like configurations, are largely inseparable, unlike hardware and the app you just wrote, to an extent. But how do you work with this? Like, are there other models we can invent? Of course, we can put our marketing hats on and start talking about shared fate, but—

I was actually gonna go there myself.

Okay.

The shared fate is different cloud providers have different levels of secure defaults in their landscape. There's some cloud providers where it's easier to get it wrong. Like when we first started with our cloud security programs, we had a bunch of 'em in the same room. One of 'em admitted that the defaults were set for ease of onboarding because we'd like everybody to use our services. Totally understandable from an economic perspective, but there comes a point where you start thinking, like, do we not have a slightly broader responsibility to help our customers to run more security in the cloud?

And so, to me, this is, again, shared fate was born ultimately out of frustrations with shared responsibility, where we say, hey, you have stuff that, in theory, exists on the other end of the line, but ultimately, we know enough about how it's built, how it runs, and ultimately it's our cloud. So we would share rather than separate. So to me, maybe if there's a continuum from separated responsibility to more jointly doing things, shared fate is that model. So is this coherent or not? We don't say it on our shared fate webpage, if anybody cares to hear.

It is, but like, think of it, there was a really good sentiment in the US White House National Cybersecurity Strategy.

There was?

You may not agree, but like one of the things is that we are better equipped that most of the users for our landscapes to secure the landscapes, and they are, right? Like, there's history behind this that specifically in SAP landscapes, these are the systems that nobody wants to shut down, so there's never really time to patch. So these things accumulate, and you get these CISA announcements every so often, like, please patch a 5-year-old vulnerability in your landscape because we see it in the wild or something like that, right? There are reasons for us to help customers be more secure in the cloud by keeping applications updated for them rather than requiring them to do it, provide secure defaults, provide templates, and so on. We've done that already in the ERP world on-premise for some time. And in the cloud, that only becomes more important.

So Tim, actually, as a funny aside, remember our discussion about on-premise thinking versus cloud thinking?

Yes.

that is used to building more things for customers inside their environments, it kind of becomes almost more cloud-aligned, even though it was born on-premise. Maybe I'm rambling, but what I'm trying to say is that if you are a large, complicated software vendor, like the one that Jay works for, right, you almost have to play a little bit with things that customers have in their environment. They think of them as their own configuration, all that stuff. If you just say, here's some complexity, you do it securely, It's not going to end well. No, that's not how it works. So, in that lens, it has to be— it's almost like your shared fate. You have to live with that. Otherwise, you would have constant problems with customers.

In many ways, SAP has been a cloud provider longer than we have when you think about how complicated their stuff is and how that interactive thing works. Anton and I were actually arguing at lunch today about what is cloud. Jay, maybe as an aside—

What would our audience say? 2-plus-year Cloud Security Podcast hosts met up for lunch and said, what is cloud anyway?

What is cloud?

And I'm like, I don't know, but do you know?

We actually didn't know though, listeners. And so, Jay, while Anton and I are over here eating crayons for lunch, do you know what cloud is?

No, it's a really fair question because it depends entirely what your perspective is. It's not even the same for me as it is for the lines of businesses that deploy solutions in the cloud. Like, I have a very broad perspective and Think in terms of both cloud infrastructure security and threat detection across that landscape, and do we have enough tooling and deploy all those sort of language that you guys understand? But once it gets into the actual nuts and bolts of deploying all these landscapes, integrating the applications together, working with the customer to get all the RBAC right within those things, and it's all the more important because those. downstream effects from it. You get it wrong, somebody doesn't get paid in payroll, right? If you get it wrong, some manufacturing floor shuts down or suppliers don't get—

So wait, but what is cloud? What makes something cloud? Yeah, see, it's a hard question.

No, no, no, it's a good point. It's a really hard one because now you get into cloud mindset stuff, which is unfortunately where I feel like you have to kind of convince every individual For somebody, it's like seeing a CIA TV.

That's not very scalable and not very cloudy.

No, it's horrible. It's horrible. I have a book tip at the end that might help with this.

So, cats, cattle, and humans, there's a third category. You have to convince—

No, absolutely. I completely agree with that. Unfortunately, and I think it happens despite cloud having taken 10 years, at least, for some it's 5, for some it's shorter than that. Is the practices of doing it right, actually doing it right, not like thinking about doing it right, or 5 key things to do is like fix your asset management. Yes, that's a 3-year program potentially, right? So actually doing it right, we're only really starting to have these debates more publicly.

Mm-hmm.

It's very hard to get these topics into security conferences. They're on like cloud conferences or CI/CD or DevOps conferences. I think the amount of attention to sort of cloud stuff that you see in the more traditional ones, still very hard. Like simple things like cloud ransomware, right? Like the SANS Institute is now talking about that. We've been talking about that for a while. It's like all of that is cloud API stuff, and all your prior detections are looking for things that the attacker don't even care about.

Yeah, who cares about malware when you can delete all the crypto keys?

So, we have to think very differently. Yeah.

Still, we don't know what cloud is, though.

Can I please hide under my table, under our table here, and avoid this question? Because otherwise, we're going to paint ourselves into a corner and get very philosophical. And the worst thing, we may end up at the whole somebody else's computer thing, which we're not going to go there.

In light of that, Anton, please ask the next question.

Okay. So, the next question is, you, Jay, wrote this actually, a very insightful article, and Tim can make fun of me for saying actually very insightful, which contrasts not just 2 models for shared responsibility and shared fate, but it also introduces the 3rd one, shared faith. And that is now stuck in my brain very firmly. And can you, the author of that, explain this to us?

Yes. So, it actually came out of a couple of customer meetings, all customers that have told me things like the CISOs and CSOs told me things they were worried about that weren't directly cyber things. I had one of them tell me like, Jay, if SAP doesn't work in the cloud, we might have an environmental disaster on our hand. And I had the same reaction because you don't realize like how you get to that step. And he talked me through that. And this was a dairy cooperative in New Zealand with thousands of farmers and cows. And if the SAP system doesn't work, they can't process milk. What are you going to do? Are you going to tell the cows to stop making milk for a day? So after a couple of days, all the storage is full or however short that period is, and it goes into rivers and streams and across the fields because you have to get rid of it somehow. That's the kind of downstream effects that you get when you Mess with an SAP system.

Literally downstream.

Right. Global supply chains might screw up. Doesn't know, you're in a harbor trying to get a particular container onto a ship and you scan the barcode and nothing comes back. So which ship does it have to go on? That's the risks that our customers are dealing with and our customers' CISOs and security executives are worried about. So what that ends up doing is that they, of course, while they're happy to have us take the responsibility of a whole bunch of operational security, and probably individually quite convinced that we do a better job at them. That doesn't stop them from needing to do their threat modeling, their risk assessments, like where does that data live? What's gonna happen? Are you really as resilient as you say you are? It's basically a reaction to customer demand for more and more transparency and insight. And, you know, I'm certainly not suggesting that we're there yet. Frankly, you guys spill over, I think, in the shared faith area when you talk yourselves or you bring guests on of like how does Google themselves run a particular security operation. And that's just, I think, what we have to do to gain the trust of our customers that we really can handle this responsibility beyond an audit report or a set of nice documentation. We have to provide more insight. Especially once these workloads get more and more serious.

And it also differs presumably by the type of cloud, whether it's software as a service, where it's a lot more of the stuff is in provider hands.

You're exactly right.

Yeah. Would there be some kind of an overlapping orthogonal model that connects how shared stuff is with that? It's not just a matter of degree because like these people assume that it's like, oh, for SaaS, provider owns the application stack. You just have the identity. But that's another gross oversimplification of how reality Actually works, right?

Well, plus you may have to make choices of how resilient do you want the application to be. When you yourself get to make architectural choices or can even intervene in case something goes wrong, when your choices essentially become a set of contractual choices that you signed up for, when you have an incident, you're essentially just waiting, right? I don't wanna scare people because obviously you have a whole bunch of folks looking after that stuff, but like if you put it in the position of a customer, There is a certain psychological effect simply by digging through logs to get the feeling that you're doing something.

You are doing something.

If you're literally waiting for your enterprise application cloud provider to give you an update, I can certainly understand that that's a very nervous situation.

You are almost inducing a fear of SaaS in my mind. And I love SaaS. I use a lot of applications that are software as a service. And I do occasionally think about this, but ultimately, you are right. In many cases, For software as a service, most of the things you can do is either contractual or monitoring if they expose logs, and maybe a paper posture assessment.

Yeah, but look, it is a question of control and perceived control. We're still talking about, is the provider better equipped to keep a system up to date and even sometimes remind you, like, look, we see what the state of the landscape is, we need you to do something, versus—

Right.

Customers that have struggled to keep these landscapes patched, secured, coordinated together. So there's definite benefits in making that move and having several thousand people look after stuff rather than a smaller set of people. But that doesn't mean that you suddenly go, okay, I'm done and I'm comfortable by just signing this contract.

That's really interesting. I have compassion for many more CISOs right now.

Yeah.

We also have to understand who makes decisions. Basically, every CXO in the organization may be in full support. They say, yeah, I want the functionality of this. This will accelerate my business. But the poor CISO sits there going like, you know, everybody wants to move that way, but I would still like to do my risk management things. Right. So, that's really what we're talking about, loss of control that comes with having somebody else take care of it. It's probably not that different from, you know, an MSP situation where you can't just say, Okay, I'm done. They're there, right? You still need to have an ability to get them in touch with the person to respond to an actual active incident.

So, Jay, we're at the point, sadly, where I have to ask you our traditional closing questions. Do you have maybe a tip for helping people, since you've talked so much about risk and resiliency, a tip for helping people improve that? And then 2, you mentioned some recommended reading. What should people be reading to understand all this better?

I'm just going to combine the 2.

Sure.

I'm an absolute fanboy of Kelly Shortridge. You guys have had her on as well. Security Chaos Engineering is one of these books that you read and go, like, half the page is like, oh my God, that's what it's called, what we've been doing, right? And the other half is, like, good stuff that you hope that you soon might be able to adopt. Like, I think she's been able to put a sort of book together so that we get out of these, just adopt the cloud mindset, man.

Yes.

Now, read Kelly's book. And then after that, we'll have a conversation, and at least we're on the same page.

Amazing. So, we'll read Kelly's book. We'll listen to the episode with Kelly. This is great. Jay, thank you so much for joining us today.

Thank you so much. This was great fun.

Perfect. Thank you.

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_Chuvaikin and _TimPico. 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.

Security. Security.