Preparing for Cloud Migrations from a CISO Perspective, Part 2

Security.

Hi there. Welcome to the Cloud Security Podcast. Thanks for joining us today. Your host today is just me, Anton Chuvakin, a reformed analyst and a member of cloud security team here at Google. You can find this podcast wherever podcasts are distributed, and of course at our website whenever we finally launch it. You can follow us on Twitter as well, twitter.com/cloudsecpodcasts. Our guests today are again Phil Venables, Vice President and Chief Information Security Officer for Google Cloud, and Dave Hannigan, Director of Financial Services Security and Compliance at Google Cloud. Welcome to the show and welcome again, Phil.

Thank you.

Thanks, Anton. Good to be here.

So we're going to continue the conversation from our part 1 discussion about cloud security for CISOs, for kind of on-prem born and raised CISOs. So to continue on that theme, how do you even define cloud-native thinking? Is cloud-native about security tools? Is it about systems? Is it about architecture? So for example, I'm thinking if I use servers, I am on-prem type of style architecture and thinking, and if I use services, I'm in the cloud. I don't know. What does it even mean doing security the cloud-native way? So please explain if possible.

Good question. And I think it's one that's sadly still debatable amongst folks out there. So I've always found it helpful to First, maybe we come to a consensus on just a definition. For me, personally, thinking through what does cloud native actually mean, for me, it's architecture that fully takes advantage of distributed, scalable, flexible nature of the public cloud, in this instance, right? It really maximizes your focus on writing code, creating business value, and keeping customers happy. If you accept that definition, going cloud native means Abstracting away, like, many layers of infrastructure, whether it's network servers, operating systems, etc., right? So, another way to think about that is, you worry less about all of those, because you're really going to build code on top of that, to help you go quicker. And in addition, it's also a way to operate, if you think about being cloud native. If you now relieve companies of all of that work that happens to provision any hardware, and the likes, well, they can move quicker. And so, companies then start to adjust and adapt to pushing out potentially more code, and learning from that, etc., and just being able to quickly learn to get the product out and then worry about fine-tuning it. So then if we extend that to cloud-native security, and by the way, I'm gonna give you multiple definitions here because it's not as straightforward, but I'd say those security tools that also take advantage of cloud-native architecture and help secure what's built and launched in the cloud. And there's kind of 2 flavors around that. You'll see like what you can use natively to secure the CSPs themselves, and then you're going to see security tools that actually operate themselves in cloud and deliver their services, right? So security as a service, as an example, also there. And it's about also having that speed and ability, but there's some nuance in it. So I'll give you some specifics because you asked about some differences, right? So let's take as an example, like an IPS, right? So if we think about what an intrusion prevention system is, some folks would immediately go to, well, how do I do that? How do I put one in the cloud and how do I operate? But I'd argue that's really thinking really tactically about it, and that you're really talking about a specific tool for what I think is the key thing, an outcome, or a risk that you're trying to prevent. In this case, it's unauthorized access. IPSs are designed to really detect that, prevent it. So if you think about what you're trying to accomplish, or those outcomes, I can do a good job of explaining the differences. So an IPS generally is not native to cloud. That toolset isn't really native there. It's not going to grow. You can lift and shift and try to put one in, but it's really not going to scale with you. You're going to run into issues on throughput, visibility, all sorts of things that just kind of don't make sense at that side. But if you think about the outcome, to detect and prevent unauthorized access, then what you'll see is there are native tools, in this case, in the CSP, that help you do that. And amongst those, not all of them, are like logging that you get for free, identity and access management, right? Because in identity access management, there's kind of a different context in cloud. Every person and service, you know, has its own identity, and you can control access to it and the likes, and then access control lists. So if you think about it like that, then the question when you're doing something native is you wouldn't put an IPS in. You would figure out the way to consume all of these disparate systems in a way that works for your organization to prevent unauthorized access.

So the logic would be somewhat you jump from a tool to an outcome. What's the IPS outcome? You jump from an on-prem tool you have to outcome, and then you jump from outcome back to a tool that is cloud native. So kind of a zigzag pattern. Yeah, I got a tool. What does it do? This. What does that in the cloud? This. So this is what I'm going to use. Kind of like roughly my summary of that, right?

What's interesting there is then it's going to force you to think about how you operate too, right? So, you know, it's easy when you put an IPS in, it's pretty clear security is going to kind of run and manage that. When you have these different native capabilities, you still have to ask yourself different questions like who's best to take the first alert for unauthorized access? Is that actually security or is it actually the owners of the apps who really know who should have access, what's normal, what's not normal? So while that gives you a definition, it also highlights how you have to think differently about how your I don't want to forget about what I said earlier, and then you also have the ability where there are companies that sell security products that are cloud native, right? Think of a CASB, and they're going to be designed to take advantage of the cloud in how they deliver services and how people consume services. The alternative, or the older way of doing it on-prem, is proxies, right? Those were there, and you had to then build it, you had to do capacity planning, and you had to make sure that you could basically service all of your folks out there. A lot of that's abstracted away, and you basically are able to just worry about configuration as opposed to the management of the hardware, et cetera.

Yeah, that makes sense. To me, this is a good story that makes it come to life. Phil, got anything to add to this one? It sounds like a big topic.

Yeah, I mean, building on what Dave was saying, I think for me, it comes down to 2 things. One fundamental distinction in the cloud is you have to and you get to think declaratively. In other words, you can think of your environment as something you specify and the cloud orchestration system provisions and sustains that. This is what we've always wanted to make life easier, but it's been very, very hard to do with all of the layers of on-premise technology built up over the years. But in the cloud, you can absolutely do that and then run policy checks against your specification, as opposed to only doing that against deployed reality. Now, again, as CISOs and security leaders, everybody has to still be appropriately paranoid, and you're likely going to want to have additional checks to make sure that what your cloud orchestration layer is appropriately orchestrating that declared policy and configuration established in the cloud. But generally speaking, that declarative approach is tremendously valuable. The second thing, and this is kind of building on what Dave was saying, is the fact that your entire environment in the cloud is programmable. In other words, it's software defined. You have a software defined network, you have software defined compute, storage, application environment. And so you can do things that you could never do with a fixed hardware on-premise environment, except organizations that have almost implemented the same cloud technologies on-premise. And as a result, you can have distributed firewalls, fine-grained application segmentation, more pervasive and continuous identity and access management. And all of this gives you immense leverage. So that kind of declarative approach, plus the software-defined environment, for me, those are the 2 transformational concepts that you get to do in the cloud.

Yeah.

So basically, if you are used to different approaches when you have to install servers, install appliances. It's sometimes very hard to switch the brain to this declarative thinking and to this time runtime world. So to me, this is kind of maybe the journey. Then my next question is, how do we actually help CISOs speak cloud? So some CISOs may not get this declarative point. They may get it in the abstract, but practically they would not live the lives. So how do we help or maybe teach CISOs speak cloud?

What's fascinating about this whole question is, and maybe it's only some of us of a certain generation that remember this, but if you go back long enough, when we look at the founding set of information security or information assurance principles that we've always wanted to implement for decades, whether it's least privilege, role and attribute-based access control, fine-grained segmentation, a whole array of other foundational security principles that we've wanted to implement But in an on-premise environment, we've learned to get used to the fact that we can't fully implement those things, and we've skirted around the edge, and we've implemented various different layers of controls. But in a cloud environment, that's exactly how cloud is architected to be able to implement those foundational security principles. And so, the interesting thing is, you know, when we talk about helping people kind of, quote, speak cloud, it's actually just going back to the first principles. And we've almost got to go back to what we used to talk about before we learned not to be able to do it in an on-premise environment.

So this gave me a profound idea, actually, because I feel like we always assume that there is policy and reality and there's a gap. If policy as code in the cloud exists and everything functions, then that gap would go. It would vanish. So if I think operational realities at most companies, they have policy and they have what's deployed and they never, ever, ever, ever completely match, right? But in the cloud, actually, we have a chance of them matching as a matter of routine. And that's awesome.

All those things that were hard or super expensive, like on-prem, you now have an opportunity to rethink, what were you trying to accomplish, and get data to really hold yourselves accountable and your teams accountable. Are you actually getting the outcomes that you want? In other words, as you go on in the cloud, it's way easier to measure the impact, and you can adjust. The same thing for agility in cloud, you should be thinking that way in security too. You're not going to get it right the first time. It's the same principles of learning, rinse and repeat, and the likes, and making adjustments. I think you have that huge opportunity as you move into the cloud because certain things just come for free, like logging, right, within the environment.

That makes sense, and thank you for that. So, what if I'm thinking of a first step? Like, if somebody is just at the beginning of their journey to the cloud, and he is in charge of security, and he is kind of what I called an on-premise CISO, a person who was born and raised in the on-prem environment. So, what are the first steps to start thinking cloud? I mean, we shared a lot of stuff here, and it's all good, but like, What is the first? What's number one?

Yeah, you know, like, I'd go back to what Phil just highlighted and just say it slightly different. Just go back and take the opportunity to really think about the outcomes that you want. Oftentimes when you're in it, you kind of forget the reason for being or the reason for certain things that are done. And I think you have a great opportunity to do that. You know, when you do, you'll have an opportunity for change and to get more efficient, right? And, and here's what I mean by that. I'll give you like a good example. Been in lots of organizations, done a lot of security programs and the likes. I very rarely— I don't want to say never because I think I can think of one instance, but the controls that you put in at a company, how many controls do you put in? And then how many do you actually take away? Everybody is scared to death to take away a control. And the root cause of that when you dig in is because some people can't even remember why the control was there anymore, yet there's still this fear of removing it. As you're going into a new environment, you have an opportunity to free yourself from all of those unknowns. And to really start to think about how do you do things cleaner and the likes. And I don't think you can do that without spending a little time focusing on the outcomes that you're trying to manage as you move about. And I think that will just naturally, you know, adding on to what Phil said earlier, get you to think about more creative ways to get the outcomes that you need.

Okay. So, to summarize it, the first step would then be extract control outcomes if you don't have them extracted already, because otherwise you cannot find the cloud ways to do that because you don't know what that is. If you have a control that does something, you need to know that something before you can find the cloud way to do the same, right? But if you don't know what something is, then you have to find it.

Yeah. Like, to say it another way, it's just really knowing what you don't want to happen and what you're trying to prevent, right? And then challenge all the ways that you are doing it today. I think it's a good exercise. And then, of course, you'll have to balance, to our points in the whole conversation, is what's the language in cloud versus what you know? But if you're focused on the outcomes, you'll figure that out pretty easily.

And by the way, there are lots of great CISOs that are she's as well as he's. I would say, remember that you can go back to first principles and feel liberated that you can now actually achieve them.

That actually does make sense. And deploying controls without, like we all say risk-based, risk-based, and then people deploy controls and it's like, what risk are you mitigating or controlling? And they're like, compliance. And then the whole thing unravels. What about if I'm a CISO and I want to start on a journey, I got the first steps, So are there any areas of security where it's easier to become cloud native? So cloud native beachhead of sorts, where adjusting the thinking, adjusting the practices is easier. Some people would say it's a SOC, some people would argue violently. So any suggested areas, Phil?

I don't think there's any one space. I mean, I would rather kind of think of this as the things you can get to do more cleanly and take advantage of in your first deployment. So for example, if you're going down a path of a set of infrastructure as a service deployments, replacing some on-premises premise with a set of VMs in the cloud, then in doing that, you've then got the tremendous opportunity to have continuous updates and patching, distributed firewalling, setting more explicit policies. So I think establishing that migration and then locking in a whole new set of more continuous and autonomic security controls as part of that is an opportunity. And Dave mentioned this earlier in terms of logging and observability. Again, making sure that as you're moving or creating some new applications, maybe in a platform as a service environment, you're taking advantage of the increased innate observability and feeding that into your monitoring environment. The other thing as well, which is another constant theme, is taking advantage of the more consistent identity and access management approach and taking advantage of the role-based access control opportunities that you get from that. And so, there'll, again, many on-premise application environments and many plans for new builds The risk that you run is assuming that you're constrained by your traditional approach to doing identity and access management and making sure that as a beachhead, you get to take advantage of that in your PaaS as well as potentially your serverless deployments as well.

That does make sense. So, it's not like there's one or two areas where you travel there and suddenly you're cloud native. Like, there's no island for cloud natives.

It is interesting because you don't have to take advantage of all of the most advanced possibilities of a cloud service to get a significant uptick in what you're able to do with maybe some of your more traditional on-premise environments. So there may be some basic things that you're able to do in more consistent and performant ways than you could do with your on-premise environment. And that's probably just as much of a win as something that's more advanced.

Kind of a good but practical way to think about it. So that makes sense. So we sort of talked about the first steps and the easiest areas. I know we have a great paper about transformation, transforming the security practice for cloud, but can you outline the type of journey that in your experience a CISO would go through kind of growing to be more cloud native? And I think both of you guys worked for very non-cloud companies and now suddenly you're like thrust in the cloud provider, right? So what are the example journeys for somebody who's adjusting from securing data centers to securing cloud?

Again, I would say don't be ashamed or afraid of applying a lot of rigor in terms of setting standards. Now, in many respects, the A lot of those standards can come from the cloud provider. Like, for example, on the Google Cloud, we have a lot of the secure blueprints and landing zones that come with all the configuration code to establish them. It's good, obviously, to establish that initial baseline of rigor around what standards exist for which the development and other engineering teams can operate within. While that might seem in some environments a little bit heavyweight and essentially kind of anti-innovation, I think establishing the broad environment and the guardrails in which innovation and development agility can occur is important because it may be difficult then to retro-control things if you've let things run out of control initially. And I think all of the cloud providers, and there's, you know, we've focused heavily on this, providing these landing zones and blueprints and all of the appropriate control technology to ensure you stay in conformance with those blueprints. That's an increasingly strong foundation. I think the other thing as well that we've spoken about in many of the blog posts and papers is keep educating your stakeholders, whether it's your board, your risk team, your compliance team, the legal team, regulators, depending which industry you're in, and making sure that they understand the overall framework for risk management you're adopting. Because ultimately the goal you want to get to is that you're not going through a unique bespoke approval process for every dataset and every workload that transitions to the cloud. You want to be able to get risk-managed approval and standards for whole categories of data and workload such that that can smoothly transition to support the business objectives.

That does make sense. Not every CISO can immediately practice it, but at least they can see the direction where they can go to practice it. That does make sense to me. Dave, any other comments to this one?

If you're going on it, just educate yourself, right? Make sure that you take the appropriate time to learn. That's totally fine. There's lots of resources out there and partners. I think too, I've always found it helpful to have a problem you're trying to solve as you're learning through it, right? So even with your teams, just pick one thing. I'm a contrarian. I like to do the hardest one first as opposed to the easiest one because I think there's more learnings inside of that. And if you solve the hard first, things tend to go a little bit quicker, but everybody has their own way. When you focus on solving a particular problem, it's a forcing function to really, you know, work through all of that, and then learn from it, right? You're not going to get it right the first time. The beauty of cloud is you get to go quicker, which means you can spot issues faster, which means hopefully then you're able to correct them, and then more importantly, learn as quickly, to codify like all of your learnings and make sure that you're not going to make those mistakes again. And I think Phil's point is super important is don't forget to bring along the other parts of security with you, right? In some organizations, whether it's your compliance functions, your audit teams, right? All these, or your regulators, they all have a stake in how you're managing security, and they need to come around with you, not force themselves. You got to make them part of that journey.

So we are kind of closing on time, but let me ask you a quick question, hopefully one of you, because it's been coming up a lot. In one of the previous episodes, there was a discussion about Do you look for cloud providers for controls, or do you look for third parties for controls? I know the answer is both, but how would you think about it? Where would you go buy things? Where would you bring your legacy stuff with you? Where are you going to hit your CSP for stuff?

It depends. But I think there are factors, right? Because really, the factors are, what is your strategy? Because if you're going to be a multi-cloud, as an example, it's probably going to be hard. You're probably going to need an abstraction tool or a third-party tool that can operate in both of your clouds. That probably makes more sense than trying to build the capabilities yourself across 2 different clouds, right? Unless you have a lot of resources that can operate in both. So that's probably one area for a decision. And I think the second is just, what's the status of your teams? Do you have the engineering resources yourself to really build out some of this stuff, right? As I described earlier, when you go native, it takes a little bit of work on your end, not a ton, but just to really understand what you're going to do with it. So I think those are 2 areas that can help you decide which route is best for you.

That might change in the future a little bit as more of us get more multi-platform in the tools we provide. But I certainly agree today, that's the tactical balance is it's often a mix for many customers.

Thank you very much, Phil and Dave. This was really fascinating. And hopefully we'll meet each other again at part 3 when we talk multi-cloud.

Thanks.

Thank you.

And now we are at time. Thank you very much for listening. You can find this podcast at Google Podcasts or wherever you get your podcasts. You can follow us on Twitter as well, twitter.com/cloudsecpodcasts. Your host separately, twitter.com/anton_chuvakin. Twitter.com underscore Team Peacock. Tweet at us, email us, argue with us, and we like or hate what we hear. We can invite you to the next episode. See you on the next episode of Cloud Security Podcast.

Security.