Securing Multi-Cloud from a CISO Perspective, Part 3

Security.

Hi there. Welcome to the Cloud Security Podcast by Google. Thanks so much 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, friendly, tamed, really nice guy, former analyst. and member of the cloud security team here at Google. You can find this podcast wherever podcasts are sold, as well as at our website, which we finally do have, cloud.withgoogle.com/cloudsecurity/podcast. If you like our content, please hit that subscribe button in your podcasting app of choice. You can also subscribe and follow the show and argue with us on Twitter, twitter.com/cloudsecpodcast. Anton, great episode today. We've got our CISO panelists back in the studio with us. What are we talking about?

So this one's going to be tough because it's going to be about multi-cloud. And frankly—

Multi-cloud?

Yeah. People stumble even at the very definition of that. Like, to me, the problems with multi-cloud start with defining multi-cloud, and then they kind of go downhill from there.

Isn't almost everybody to some degree hybrid? You're always going to have your corporate fleet of laptops and workstations. You're always going to have SaaS apps. You're always going to have at least one cloud.

I think you just showed what I was talking about because you just confused hybrid cloud with multi-cloud.

Ah, why should we think of those as different problems? I think this is just the nature of the world we're about to live in.

Yeah, there is that. But it sounds like the term multi-cloud still morphs and kind of evolves. Like, I used to think of it as very precise. If you use more than one IaaS provider, like say GCP and, well, one of the other guys. But now people say, what if I have GCP and 50 SaaS applications? Am I multi-cloud?

I'd say so.

Yeah, I think so too.

Yeah.

But on-prem, I don't know. To me, on-prem is different. If you're on-prem and cloud, then you're hybrid cloud. I don't think that's multi-cloud.

Isn't everybody that? a different word for just what everybody is going to be. I mean, everybody's going to have office equipment, everybody's got a printer somewhere.

So this means everybody is hybrid cloud, but it also means everybody is multi-cloud, right? Because everybody has at least one SaaS app, and maybe not everybody has large involvements with more than one IaaS provider, but even that is very popular on the enterprise side, correct?

Yeah, absolutely. I think that the fundamental problem of multi-cloud or hybrid cloud is you have to wrap your head around multiple security models. And I think that that is a topic we will get into with our guests today. And so we're delighted to introduce once again to the show Phil and Dave for part 3 of our conversations with CISOs. Anton, first question is for you today, buddy.

So we want to start in a somewhat unusual way. Instead of saying, hey, things were picked for you, dear CISO, what would you do? We wanted to change this around and say, okay, as a security leader, Would you ever decide to use multiple clouds if it were in your hands? So for example, would you think, hey, I'd rather have all eggs in my basket but watch the basket, or I'd rather have one partner? So however you think about it, would you ever choose multiple clouds if it were in your hands for security purposes?

Yeah, I mean, so like, of course, I've got to say, like, you know, multi-cloud, why would you do that when the only cloud you'll ever need or want is Google Cloud? But in reality, we do recognize that multi-cloud is there. You know, before directly answering the question, I just kind of remind everybody that the fact that most organizations that are multi-cloud haven't deliberately chosen to be multi-cloud, you know, they've ended up there because they chose one provider for, say, infrastructure as a service, and then felt limited, and then chose a different provider for platform as a service or other services like data or AI capabilities, or they introduced another cloud provider to provide some competition on commodity services to their incumbent And then sometimes organizations have multiple cloud providers because they've moved some of their on-premise pain out to that particular vendor's own cloud. And maybe sometimes they've also inherited multiple clouds through companies that they've acquired. So I think for most organizations, multi-cloud has mostly kind of grown in an evolutionary way rather than a pre-planned way. But just to the direct question, I think when CISOs, or in fact CIOs and CTOs and others, think about the need for multi-cloud, Ultimately, it's all about making sure that you can manage concentration risk. And I think to do that though, is you've got to really think about application portability in a container-like way. So I think the only way I could imagine, at least from my perspective, that multi-cloud is a great desire of a CISO is to really act as a mitigant for concentration risk. But that's not just simply using multiple clouds. You've got to actually take some application architecture steps to do that as well.

This is actually a really good answer, concentration of risk in one cloud provider. To me, that's a legit solid security argument. That's not sort of like vague stuff. That's a solid risk that we are mitigating by doing multiple clouds. So I just wanted to highlight the fact that it's kind of an awesome answer. Dave, anything to add?

Well, now the pressure's on. I have to come up with a more awesome answer. Look, I think it's a super, super interesting question. I would just add to Phil's point that not only are some organizations not intentionally doing it, but others, I mean, they really are. Because if you think about cloud, a lot of security toolsets That are run on the cloud, right? And so you're consuming them there, and you're seeing HR systems and the likes. And so it really is happening. So if you take a step back and just accept it's happening, then you can really start to think about what are the decisions that you're going to need to make in regards there. Firm believer that once you accept it, then you can drive some higher-level principles when it comes to adoption. But the specific question, if I am an advocate of multiple CSPs, I think it's a business answer is what I would choose in that regard. And it's yes, if we need to, right? And I think you have to spend time, do you really need to? And perhaps some organizations have an opportunity to do a little bit more diligence around that. And then concentration risk, it's a super important point and it's complicated because if you like pull back even further, a lot of what I talked about earlier, your HR services and your security vendors, they're also running on potentially the same cloud or CSPs that you're choosing and the likes too, right? So it's really complicated web.

Lots of interesting stuff in there. Phil, I want to ask, when companies are doing their planning for going multi-cloud, how do they factor in security to that? What does that process look like when people are doing it right?

Yeah, I think the issue with this is, I mean, companies have kind of grown out of doing one cloud first and building their capability for that, and then extend to multi-cloud. But in my experience, there are generally 3 types of organizations with respect to cloud, and then generalizing that to multi-cloud. First, there's the organization where the application development or the DevOps teams run everything directly on the cloud, and every business unit is doing their own thing. And the security team sets some background policy and runs config checks to highlight and fix issues in individual business units that are doing their own thing. The second kind of type of team or the evolution from that is, there's a central infrastructure team that provides guardrails orchestration, and partners with security to make sure that those guardrails encode the right security policy. And then they produce that as an interface to each different cloud provider so that the development teams get to work through that kind of common orchestration layer. And then finally, kind of almost like the third level of evolution is there's a central infrastructure team that drives an even more integrated set of policy, identity and other security layers with the oversight of the security team on top of that. There's trade-offs in each one of those cases in terms of flexibility of how you onboard new services from each of the cloud providers that are in your multi-cloud environment. And there's probably kind of multiple flavors of each of those 3 things. I think ultimately though, everybody gets to the third eventually. It's a journey along that way. And in fact, it's going to be helpful to many organizations if all the cloud providers, if we all start at least converging on some common principles principles for how these things are operated. And, you know, there's the beginnings of that, but I don't think anybody's there yet.

On the principle level, we have to agree. Otherwise, I can see how some would treat multi-cloud as kind of a mistake or something they just inherited and they kind of hate versus chose consciously. So to me, I like that. I like that line of thinking. So to sort of drill down a little bit into this, when you are a CISO and you happen to be in possession of multiple clouds that you have to secure, what would be your principal approach to securing multiple cloud environments? For example, you have to get skills, you have to get people who know Google, who know other cloud providers.

You know, a couple of steps. I think the first is really being intentional. Start with a security strategy and a framework. I think this lays the groundwork for your policies and like what you can really focus on from an automation perspective. The more you can abstract and automate, the better, but it's hard, right? I don't want to underestimate how hard it is to abstract simply because all the providers are different, right? So an abstraction layer is going to be very complicated. the more that you have to learn in order to do that. And hopefully you can potentially rely on a third party or try to do it yourself. I think the second thing is, you know, application security. The truth is, as you move to cloud and multiple, you just got to be good at development because that's in essence what you're going to be doing. And you got to get really, really good on it, focusing on the apps as well as the environment, right? Everything from development to deployment, you need to spend a lot of time on that because that's what you're doing.

Is your advice there on AppSec just get good?

Yeah, I've heard that.

And it's really meant to be like that high level because you got to spend more time at it and you're gonna have to really challenge yourself to truly, truly get in there. And it's not just reviews and the likes, it's from development to deployment. You've got to understand how all of that really happens and it's all code related.

But, but, Tammy, you've got to go from get good level 1 to get good level 5 quickly as well.

Yeah, I think that's right. And the concept on the app security front gets back to another topic we've had bubble up through a lot of episodes, which is the relationship between— in cloud, we have a strong coupling between app security and infrastructure security, whereas on-prem, we had more of a separation between those 2.

Yeah, that's a good point. So then the third is like IAM, right? That's, that's pretty much security in cloud. So it's the key for pretty much all cloud providers. And again, they all do it differently. So really dig in and understand it, right? I mean, it's a super high-level thing to say, but I'm really serious about it. You've got to understand the nuances there. And especially the differences, because what will happen is you'll have a potential to conflate definitions even, and it can really complicate discussions as you're building stuff out. You're going to laugh at this one too. Understand what you actually implemented.

Mm.

And I say that jokingly, but it's true, because sometimes what we intended and what we implement don't equate. And so you've got to spend time on that and make sure you do it. And that means network security is really important. And I'm going to say it, but your compliance reports are also really, really important. Right, as you're trying to work with your internal teams, and if you're regulated, your regulators and the likes there too. And then encrypt, but it's different. And then I think you've got to build a really good, robust monitoring capability. And you also got to validate and educate and really be forceful on eradicating violators of what you have put in place out there and just do it quicker. That's a high level to your question, Anton.

No, that makes sense. And I think get good at IAM may involve figuring out what get good even means with IAM in the cloud. Because like, get good at AppSec, I sort of get. But get good at cloud IAM is a lot trickier because you need to know like, how does it look like? I mean, I made a mistake of reading a Gartner paper on comparing IAM in Amazon, Google, and Azure. And now my head is full of terms that 3 providers use differently. And some concepts are different and some relations between the concepts are different. I can have a brain explosion from trying to understand what does get good at IAM means at each of the 3. So to me, multi-cloud is tricky.

This is what I call with users my Anna Karenina principle for clouds. All happy clouds are the same, but we have 3 unhappy clouds and they're all different in their own way. So Phil, aside from IAM, or maybe in particular IAM, what are the top practical challenges? Is it different controls? Is it IAM? Is it the lack of tools? Is it skills on the team you can hire? What's really driving the difficulty here for people?

It's actually, you know, building on that IAM point in general, and not just IAM, but the control plane and the entire control construct. So, you know, one of the things I like about GCP, for example, based on my prior experience of using multiple clouds, is the fact that everything hangs under, you know, one organization, and you can set policy, and you can apply policy in an inherited way across folders and projects versus having to kind of manage things across multiple accounts. And so understanding the different control planes and organizational structures across all of your multiple clouds, and then being able to map that, as Dave was saying, into your kind of control policies and your compliance approach is really, really important. The other thing as well is recognizing, as we've talked about on kind of previous episodes, is one of the great things about cloud or cloud-like on-premise infrastructure is the ability to declaratively specify your intent, and then have high assurance mechanisms of mapping reality to that intent to look for discrepancies. Whether you're multi-cloud or single cloud, you can still do that at scale. The only challenge is going to be integrating the different policy intent, how it's expressed in different control planes. But you can certainly do a lot of that mapping. And even when you look at using some baseline standards like Center for Internet Security Standards and other similar standards, you get some degree of commonality across the clouds, but there's still a lot of work to be done to bridge the policy intent.

No, I've noticed it as well. So why don't we shift gear a little bit? Some people's, some security leaders' favorite topic, buying stuff from vendors. So one thing that bothered me back in my analyst days is that when I had clients come to me and say, hey, I have a choice of using security controls, whether free or for money, from my cloud provider versus going to a separate security vendor, whether a classic vendor or a new vendor who covers more than one cloud. So it's always been a bit of a battle in many minds. Should I go to my big 3 for most of security, or should I go to a third-party provider? Now, here for this conversation, the context is multi-cloud. So typically people assume that if you are intentionally or factually multi-cloud, you have to use third-party tools. Is this the truth? How would you think about purchasing tools or deploying tools from your CSP versus third-party security vendors? What's a harmonious approach to this?

And I want to remind listeners that Dave and I first met in the context of me being a tool vendor for a cloud trying to sell Dave a tool. So, Dave, no pressure on your answer here.

Okay. I'm cracking up on that. I do remember the conversation. So, um, look, I think we have to make note that today we're seeing CSPs, right, starting to build security tools that work across providers, right? We're doing that. That's something we should probably talk more about as a company. It might not be as clear as it could be. Everybody realizes that, you know, hybrid cloud is a reality and everybody wants to really solve that problem that we're talking about, which is how do you make it easier? And how do you bring like a single pane of glass if you can? I think it really, it's about the decision of the third-party tools versus, you know, what you have. And like one, one point to always think about is third-party tools always have a disadvantage, right? And their disadvantage when in the cloud is they have to go through the API. The CSPs have an advantage because, you know, they can go and operate, you know, underneath that layer and they don't have, you know, the controls that are meant to keep things reliable and they can then, you know, work faster. Now the alternative is, They just might not be good. So just because a CSP has different access or has an ability to do something doesn't necessarily mean they're going to be a great tool builder and are going to build tools that are consumable in the way that security professionals need them on a day-to-day. It's a trade-off that you're going to have. You have to spend time. I don't think you can just make an assumption third-party tools are better or that CSP tools are better.

But third-party tools, there's one. Each CSP tool is 3. If you're in 3 clouds. So if they're comparable quality, you're learning one and you're covering all 3 clouds, right? So that to me is kind of still not quite logical.

Then you're beholden to how quickly that tool provider can stay up with changes on APIs and the likes there too, right? So it sounds great on the top layer, and it could be from an implementation perspective, but you just don't know, right? And I think you've got to really spend time and dig in there and really understand what that difference is from when things change into what you realize them. I mean, you can go through many scenarios that if something changed on the API and all of a sudden, you know, let's pretend you're using a vulnerability scanner and all of a sudden you're like, oh, we're doing really well, and then you come to find out, well, you're not doing really well, it was false reporting because something changed and your data quality wasn't really there, right? So there's trade-offs all over the place, and I think, you know, a good way to think about it is what are the things that matter the most, and really interrogate those third-party tools and the CSPs and see what gives you the best.

You know, Phil, is there anything to add that's sort of a delta there when it comes to cross-cloud compliance versus, say, cross-cloud vulnerability and threat detection?

No, I mean, the reality about compliance in, I think, most of the large cloud providers is each of the cloud providers has got all of their compliance certifications, probably more than any one company will actually need. And for example, at Google Cloud, we obviously have some very specific compliance certifications and then some blueprint constructs that help customers get and sustain compliance in their own context with a lot less toil than they would typically do in an on-premise environment. So I don't think having multiple clouds, in my view, doesn't affect your compliance burden. And in fact, if anything, if you were going to trade your on-premise environment to go to multiple clouds, you're probably going to reduce your compliance burden given your on-premise environment, you're subject to running all the compliance checks and audits and certifications on your own in a likely very complex and disparate environment. So I think Multiple clouds, in my view, doesn't add a compliance tax. It's still net less than what you would have to sustain in your on-premise environment anyway.

Hmm. I kind of want to argue with Phil for some reason, but I can see how it can become logical. I feel a desire to validate it operationally for some reason. I don't know. I'm not not trusting you, but it just sounds so contrary to my intuition. Maybe that's the right answer, is that my intuition was the opposite.

So, if you're adding multiple clouds and not reducing your on-premise environment, then it's a net add. If you're trading your on-premise environment and safely migrating to even multiple clouds, I think you net reduce your compliance burden, maybe not in the spike of the transition, but in the subsequent steady state, I would think you're going to be better off.

Yes. And you know what? I am converted. Here's why I'm converted. Because if you reduce your on-prem workloads, and you increase cloud workloads, the amount of compliance burden that falls on CSP shoulders increases. And where does it come off? Your shoulders. So in that sense, it does decrease because if you reduce data centers, you reduce PCI scope, you reduce other stuff. So to me, okay, now I buy that. Fine. We're safe.

So it might be a conservation of compliance energy. You don't reduce it, you just move it to a different place and we get to take care of it with economy of scale.

Is there also some, you know, relativity tie-in with compliance where as you Add compliance requirements, you become heavier and therefore accelerate more slowly.

It could be as well also, you know, are you compliant until you look or only after you look? So, you know, we could get really into physics on this one.

Yep, I believe that.

We managed to make compliance fun. That's a big achievement. But we have one more cloudy topic before we start going into closing remarks. And the cloudy topic we have is this whole proliferation of SaaS. Now, a company may use at most 3 or maybe 4 cloud providers for IaaS, But I've seen clients who use 30, 50, 70 SaaS providers, occasionally even more. So what's a poor CISO to do if he's in charge of securing dozens, if not hundreds, of SaaS services? Is buying CASB still good advice, or is there more to it?

I think a common identity layer is critical. Whether you deliver that through an identity federation layer or you use your CASB for that is probably just an implementation detail. But a common identity layer so you can manage all of the normal basic access and leavers, joiners, role changes, you know, linking that to how you're thinking about role-based access control consistently. The authorization federation beyond the identity and authentication federation is obviously way more complex. There's a number of third-party tools that help people do that. That's, I think, the minimum level of what you've got to do. The other aspect of SaaS is, I mean, this may be a statement of the obvious, but it's really important to actually verify some of the SaaS vendors' claims about their security and making sure that access controls are present in their environment, that the right level of encryption is done, that the right level of tenant separation in their environment is done. So, you know, I wouldn't give up on any of the necessary vendor assessments for SaaS providers, but at a minimum, it's critical to have that common federated identity and authentication layer, and then ideally a layer of authorization federation and control on top of that as well.

Okay, perfect. That makes sense. So, we are kind of close to time. So, I want to hit you guys with our typical closing questions, namely, any further reading on the topic of securing multi-cloud? And the other one is, one practical advice for the audience for securing multi-cloud?

If we're really talking multi-cloud, as we hinted at a few segments of the discussion, you've really got to think about application modernization, which is typically a containerization approach. So, kind of Further reading on that, particularly around, especially if you're on Google Cloud, reading around kind of Anthos and what we do on application modernization there is going to be good. And then practical thing for multi-cloud, I think we've hammered this to death, is really work the identity layer and at least get some minimum baseline controls declaratively modeled and deployed and consistently monitored across all of the clouds.

I think SANS actually has some really good literature on multi-cloud and the likes and some practical advice. And then my one practical So that's the practical thing for secure multi-cloud is validate everything.

Okay. Well, I guess this is not about, yeah, just trust them. The big cloud providers know everything. I think that's good. Well, we do. We are Google, but the other guys maybe not.

I would say that's like PM life, but Akshay beat me here. So I don't actually get to take the easy way out on that one.

So thank you very much for this. This was really useful. And I feel like the audience would get their brains around this painful problem to some, at least that's my impression. Thank you very much for being here.

Thanks for having us.

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

Security.