EP33 Cloud Migrations: Security Perspectives from The Field

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 in 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 enjoy our content and want it delivered to you piping hot every Monday afternoon, please do hit that subscribe button on your podcasting app of choice. You can follow the show and argue with your hosts on Twitter as well, twitter.com/cloudsecpodcast. We've got a super fun episode today, Anton, on a deep dive with somebody who's clearly been doing cloud migrations a very long time. Which is kind of a weird thing to say, given how new cloud is.

To me, the fun part about the episode today is that it's not a CISO 100,000-foot view from the top on cloud migration. It's not a CIO view, not an organizational leader view, but it's a view of somebody who just has to be there with a shovel to shovel cloud. Is it a bad metaphor?

I like the idea of shoveling cloud. I'm pretty sure Elliot has in his life literally had his boots on the ground. But he's definitely a perspective from the ground today.

Sure.

Or whatever the cloud deck is.

He is that. But at the same time, it's interesting how some of the things he highlighted with challenges, like for example about identity and about perimeter, are kind of the angle of the same stuff we've heard from the CISOs.

Yes.

Many levels down view on largely the same problems. To me, this is fascinating. So whoever is listening to the episode that we are airing today should probably go and check out the CISO panel episodes.

Yeah, there's like a fractal symmetry between them, isn't there?

That's a very fancy way of saying it. Maybe not too philosophical, but yes, ultimately you're exactly right. It's the identity from the CISO or identity from an engineer who is, well, shoveling cloud. It's still identity, but it's a very different thing.

I can't with the shoveling cloud. That's too good.

I'm sorry. I just can't stop with shoveling cloud.

What I mean by fractal similarity is it's the same problem experienced at a very different scale. But even at different scales, it looks very similar.

Correct. That's what the fractal is. And ultimately, that's what it feels like.

That's what a fractal is. And I want the audience to understand that I know what a fractal is. I'm not just a PM. I'm somebody with a good background. And with that, delighted to introduce today's guest, Elliot Abraham. A very boring title today, guests. Elliot is a security and compliance specialist here at Google Cloud. But don't let the title fool you. Elliot is one of my favorite Googlers to work with. So Anton, I think first question out of you today.

It's because it mentions lift and shift. That's the part that I tend to, over the years, over the months, I've been pouring some scorn on the term. So let's talk about it more seriously given Elliot's field experience. So we talk about lift and shift versus cloud native. Would you care to give us a bit of a security angle on the definitions? I'm sure you've seen companies go the lift and shift route to cloud or some go cloud native. What are these and what are the security implications?

Very good question. But first of all, thank you, everybody. I'm so happy to join Anton and Tim here today. For those of you keeping score at home, I'm Elliot with 2 L's and 2 T's. Lift and shift versus cloud native is a topic that really, really comes up a lot when we meet, especially with enterprise customers, because most of the time they're trying to figure out, we want to move to the cloud, but there is still this inertia of wanting things to stay the same. With lift and shift, and with cloud migration writ large, you have to figure out what is the best strategy to move to the cloud? Am I going to rehost, which is what lift and shift is? Am I going to have to replatform, which is once I'm in the cloud, I can move it over to a different platform that gives me a little better fit? Or am I going to have to do some form of refactoring? But focusing in on your question about lift and shift versus cloud native, it really all depends on the application, and what the customer is going to do. And the security implications really depends on how data-centric the applications are. Most people tend to think in a very, very legacy mindset. What you see is that if there's a bad habit that is on-prem or off-cloud, they tend to want to bring those same types of bad habits into the cloud world.

Hmm.

And so a flat network on-prem tries to become flat in the cloud. For example, a LAMP stack, which is a novel idea and great for developers to get their feet wet and learn how to do stuff. It is a terrible idea when you're trying to move that same type of application to the cloud. Because now what do you have with something like LAMP? You have Linux, you have Apache, you have MySQL, you have PHP, you have your application server, you have your database server, all centralized in one platform. So when we move to the cloud, the security implications are that we first have to coach our customers and explain to our customers the ramifications of bringing some of these bad habits with them into the cloud. You want to make sure that you're developing a 3-tier architecture. And one of the things that you have to do when you're considering lift and shift or rehosting versus cloud native is that when you go cloud native, Most of what we're dealing with, and Tim understands this very well, is you're dealing with APIs. So you're going to be dealing with APIs. And so the security gates are going to be a little different. When we start to lift and shift, and we move servers into the cloud, we're still thinking of our legacy mindset, my firewall rules, my ACLs, and all of these things, the Gazentas and the Gazaldas, if you will. But when you're talking about cloud native, we got API calls, and we got API gateways, and we got identities that we have to make sure that we protect. We got encryption keys. Are we going to provide long-lived encryption keys or short-term security tokens? So cloud natively, we want to focus on the identity. We want to disabuse our customers of the notion that what we did in the past is going to serve us well when we move into the cloud. Long-winded answer, but I hope that gets us going in the right direction.

It does, but let me ask you this. Is lift and shift always, quote unquote, bad for security? Just like, I know it's a judgment question, so maybe you're not really up to judging customers. I get that. But we cast lift and shift in a negative light usually, especially for security. So is that actually true? Is that a good statement to make?

Feel free to tell Anton, judge not lest ye be judged. But I think it is an interesting question.

That is absolutely true. Judge not, Anton. But it really is not a one-size-fits-all proposition. When we work with our customers, it is developing a solution. You have to listen to the voice of the customer and consider each individual use case. Now, there are some best practices that one should consider. But by and large, we want to consider the customer's situation. And then we want to make sure that we're giving them a strategy. If lift and shift is the choice, let's provide a proper strategy for them So that they can get some early wins. We want to get some wins under our belt. When a prize fighter first starts fighting, you leave the amateurs, you're going to fight what they call tomato cans at first. In other words, we want to juice up that record. We want to get some wins. How do we do that with lift and shift? We look at what's called first movers. We do a good thorough assessment. We look at applications that are going to have minimal backend or external database calls. So that's going to give us less that we have to worry about.

Mm-hmm.

securing on that end. These are going to be applications that have minimal business criticality. These are going to be applications that are going to be easier to pick up and move to the cloud because if something goes south, then you haven't bought the farm, so to speak.

I'm hearing echoes of John Kindervag on that one, Anton. What do you think? This is the same story about don't migrate the production web app, migrate the vacation time-off tool first.

Correct. Sure. That sounded like that. Like the cloud-native journey for the traditional companies wouldn't be like, ah, just get a bulldozer and shove it all to GCP and we're done, right? We are cloud-native. Well, no, maybe you can shove some of the stuff in a lift and shift and then do cloud-native for some apps. I mean, I think that makes sense.

I'm also hearing echoes of the whole solution strategy thing that we were talking about yesterday in a recording, rather than just products, really a customer-centric approach here. I like that.

I feel my analyst hat from the previous 8 years of my life on my head a little bit because I feel like the voice of a customer is a tricky one. I remember a blog post which I wrote, do we go with the customer if he's clearly going off the cliff and do we help them go get there efficiently? Or do we tell them, please stop, you're going off the cliff? And it was a big kind of almost ethical decision for the technology analyst like I was for 8 years. Do we tell them, Yeah, firewall appliances in the cloud are okay, and here's how you do it better. Or we tell them, no, you just bought $10 million of firewall appliances. Toss it in the trash. You don't need them in the cloud. These are both risky if you're an advisor.

As an advisor, we have to make sure that we have what's called technical integrity. We want to make sure that we're maintaining technical integrity with our customer. It's a balancing act, because we're in sales, not sales prevention. But we're also in the business of making sure that we advise our customers the right way. And I don't think that it's going to be a solution. I don't think that anything that we're doing is antithetical to good technical integrity. If we tell our customers, no, your desire to move your entire production web application system lift and shifted from on-prem into the cloud right now in phase 1 with no MVP in between, just lift and shift and boom, now you're in production. I don't think we're doing a disservice to either ourselves or the customer if we tell them, no, here is a preferred way to go. The better way is to let's get into the cloud, let's move some things into the cloud. And let's begin to learn because one of the things that the customers are going to have to learn especially from a security standpoint, is where are my signals going to come from now?

Hmm.

I'm on-prem, I know what I'm looking at, I know where my log sources are on-prem. But in the cloud, where are these log sources going to come from? And so until we get them comfortable and familiar and understanding what the TTPs are in the cloud versus on-prem, then we have to allow them to take baby steps. I think that's our job as security advisors.

That makes a lot of sense. So on that note, and on Anton's note, what would you do if a customer came to you and said, no, I really need my hardware firewalls in cloud? How do you have that conversation? What happens?

That is a real question. Because what happens is you have a CISO, for example, I've made my living on name your next-gen firewall of choice. And this has to work in the cloud. What we have to do is get them to take a half a step back, if you will, and find out what is the overall business driver? What's the business use case? What is the business concern that we have to adhere to? If the business concern is that we need to protect X from Y, then a preferred approach would maybe to use cloud-native security solutions and supported by third-party solutions. But ultimately, you need to find out where the gaps are. Because in the early days of cloud, we didn't have things such as packet mirroring. So there were no SPAN ports, and the CISO may have said that I'm going to lose my ability to inspect my encrypted traffic when I go to the cloud. So I have to move my Palo Alto Networks, I have to move my Check Point, I have to use my Fortinet into move to the cloud, because I got to see this encrypted traffic. But what we have to do is we have to spend more time on the front end, doing some real, real presales work with workshops, and trainings and these types of things, showing them the cloud native capabilities.

Hmm.

Because what my customers have found is, oh, I didn't know, I didn't know that if I use a shared VPC, I can actually control how the IP address space and the network stack is allocated when projects are spun up. Education on our part is critical. So we can educate them and let them know what is actually on the truck from a GCP security standpoint, and how it mirrors and parallels what they have and what they're accustomed to on-prem.

So Elliot, what are some of the fundamentals to cover with security during cloud migration? I guess you may have to give us 2 answers for lift and shift and cloud native, but feel free to structure it in a way that people can use it, maybe in priority order. Maybe you give us the top 3. What are the fundamentals to do right with security during migration?

Great question. We mentioned earlier, and it kind of flows here, is that we want to consider, you have to do an application readiness assessment to find out what apps that you have out there, and which applications are candidates to be moved to the cloud. Obviously, we want to move the applications first that we would identify as first movers, those that have less external database connectivity. That means it's going to have less of a business impact and criticality. And these are going to be applications that are going to be easy to pick up and move. But as we get deeper into the migration path, this same type of thought process holds true whether you're cloud native, or whether you're going to do a lift and shift. Where are your identities? Because when you move to the cloud, the concept of your perimeter is obliterated, your concept of your perimeter is done away with. And so the identity and the context around That identity is critical. So the sooner we unify our identity in our journey, that's going to be critical in our having success down the road. We want to make sure, because right now you have an identity store somewhere, it's either on-prem or it's in another cloud. We need to make sure as we begin this journey, ultimately, when we complete this particular phase of the migration, where's that identity store going to be? Are we going to build a new one? And now we got an identity here on cloud and identity on-prem? Or are we going to unify on one identity? We're going to make sure that we're thinking about the principle of least privilege. Because when you move to the cloud, we don't want to bring bad habits from on-prem with us into the cloud. We want to make sure that we're thinking about the principle of least privilege when we move these applications into the cloud. And then data. The data is critical because we're living in a world of the hybrid cloud. Each cloud service provider, we love to think that in a perfect world, everybody is going to flock to Google, as my good friend James Snow used to love to say, and then Bob's your uncle. I never knew what James meant by that. The reality is, we're going to live in a hybrid world for the foreseeable future, where the data will tell the story. We want to make sure because our customers are concerned about vendor lock-in. So we want to make sure that we introduce solutions to them, that's going to be more accessible in a hybrid manner. So we want to think more data lake, less data warehouse.

Hmm.

Because when you start to move the data, especially massive amounts of data, there's this concept called data gravity. Data gravity, where you have large datasets that are going to attract and pull smaller datasets. And those are also pulling the applications. So as we begin to think about our migration, we need to figure out what are we going to do with our largest datasets, because that may influence our strategy overall, because it's not going to be an overnight thing to move a massive Hadoop cluster. Do we even want to? So those are some of the things that we need to make sure we're thinking about when we move into the cloud? And from a security standpoint, make sure that we understand where the identities are so we can protect those identities, where the secrets are, where they are and what they are, so that we can protect those as well. Are we using tokens? Are we using keys? How are we protecting these from being exported out into the world?

I always say in cloud, it all comes back to identity. And Anton even makes fun of me for that at this point, I think.

It all comes back to identity. If we get identity wrong on-prem, I can almost guarantee you 100% that we are going to get it wrong in the cloud. It's going to be worse.

Some people who we interviewed on the podcast on this topic implied that perimeter is kaput. It's gone. It's dead. Some people implied that it morphed. Some people implied that it still matters. So it's interesting how everybody signals that identity is hugely important, but some people have various opinions on the perimeter fate. So this is rather peculiar. Maybe we should like park it somewhere as a future exploration idea.

I agree with you on that.

I agree with the concept of morphing. There is still a perimeter, and the perimeter being there's still a line of demarcation between where your business ends and where the wild begins, so to speak, or some combination thereof. The thought process here is that the perimeter used to be clearly defined, with a big, beefy next-gen firewall parked somewhere in a wiring closet or in a data center. But now it is wherever your furthest remote worker happens to be able to log into a kiosk somewhere and get access to.

I want to shift gears slightly. Another theme on the podcast is that so often it seems a CISO really needs a couples counselor more than they need more security tech. What's your advice to a security team about to begin a cloud migration? What would you tell them to make them successful?

That's a very good question. So one of the things that we have to do is you got to understand that it is a marathon, not a sprint.

Hmm.

The initial thought is, I need to show something. And so let's just go ahead and just start spinning up applications. Hey, voilà, now we're cloud. I think that's where some of the earliest adopters of cloud fell into. Everybody swiped the credit card and they moved to the cloud. But understand that it is a marathon, not a sprint. Plan, plan, plan, map everything out, identify where your applications are. Because right now, if you don't know where everything is on-prem, then if you were to just wave a magic wand and move it into the cloud, you're going to be in bad shape.

But you certainly can't move things that you don't know exist.

You certainly can't secure what you can't see.

Yes.

So we need to know where everything is when we move to the cloud. We have to make sure that we build out our protective controls first, then our detective controls. And we're building these things in layers so that once applications are moved in, we already have the scaffolding in place to support the structure that we're trying to lay in here. We can't just start moving in stuff without having the foundational things done. And security is a foundation. Understand this is a marathon, not a sprint. Plan and make sure security is seated at the table from day one. Security, you must have a seat at that table from day one.

Elliot, you sound like a man that has been doing this for a long time. We have just 2 more questions for you, I think. Anton?

My favorite question that I sometimes ask is kind of about threat models because I feel like when people plan controls, in the cloud, they don't always account for the fact that threats have changed. Certain things that used to be a high priority, like, I don't know, a hard drive theft. I don't think it's a high priority as such, but this threat disappears in the cloud, and certain other threats become more important. So, how do you advise clients about accounting for threat differences in the cloud, threat model differences? We had an episode with somebody here, and he really highlighted his thinking about threat models. episode. But I'd love to hear you from your field experience.

This is where we actually differentiate ourselves. And I think Tim is doing great work with the team that he leads in developing products that really focus on proper threat models. One of the things that we do is we want to make sure that when we sit and talk to our customers, we talk to the CISO to let them know that we're just not making this stuff up out of whole cloth. These are industry standard things that we're talking about. And one of the biggest things that I've personally steer my customers to is, you have to understand where the actual threats are coming from. And so we use the MITRE ATT&CK framework to great effect. Tim uses that to great effect, and it's built into our amazing product called Event Threat Detection. When you look into the details of ETD, that you can find the breadcrumbs that point you back to where this threat was, or this actual TTP In the MITRE ATT&CK framework, adversarial tactics, techniques, and common knowledge. From a threat modeling standpoint, MITRE has done an amazing job of going across cloud service providers across the industry and looking at historically, what would a threat actor really need to do in order to compromise this? Using something like the MITRE ATT&CK framework, it completely takes us away from looking at legacy attack trees and threat models that have no bearing in the cloud. We don't need to worry about removable media, if you will, in the cloud. We don't need to worry about things such as fax machines in the cloud. And if that's still on your attack tree or your threat model, then I strongly encourage you to give us a call. Let us help you out, because your threat model circa 1992 needs a facelift. It probably could do for a lift and shift.

So with that, and with apologies to 1992, I think we want to wrap up with our standard closing questions. We hate to leave our readers empty-handed. So do you have both a thing that you would recommend our audience read and one practical thing they can do to get ready for their cloud migration journey?

I would recommend a few things because you need to understand structurally and foundationally where security fits and how a proper security architecture looks, I would recommend that you go to our website and download our Google Foundations and Blueprint if you're considering moving to Google. So you can understand how the engineers at Google think about security structurally from a foundational standpoint. And number 2, no cloud migration is going to be successful without an understanding of DevOps.

Hmm.

One of the books that I would recommend everyone read is The Phoenix Project. It's kind of like a novel. And it's an old book. But it really talks about the challenges that companies will face when you're dealing with these various silos of operations, and developers and security, and how to marry the 3 together to achieve a real business goal of building a secure, scalable and self-healing environment that should be the outcome of a successful cloud migration. So, I highly recommend the Phoenix Project so DevOps can be rightly understood and where security fits into that whole process.

Well, I think Anton has something to read so that he gets to make less fun of DevSecOps next time it comes up with one of our guests.

I'm not so sure that's happening, but okay, I'll take your point.

Elliot, thank you so much for joining us today. This was a Terrifically fun conversation.

Absolutely. Thank you, guys. I thank you for the invitation, and I'm looking forward to listening to it when it comes out.

Fantastic.

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. Am I doing pauses right? Or wherever you get your podcasts. Also, you can find us at our website, cloud.withgoogle.com/cloudsecurity/podcast. By the way, we are not doing any more jokes about the website. It's a very serious We have many, many episodes there already.

I heard from a listener today who wanted to find out whether we had finally launched the website because she started at the start of the show. So our jokes persist to this day.

Okay. So we need more website jokes. I got it. So cloud.withgoogle.com/cloudsecurity/podcast. Please subscribe so that you don't miss episodes. You can follow us on Twitter, twitter.com/cloudsecpodcast. And of course, your hosts, That's me and Tim, or Tim and me, whatever, are on Twitter as well. Anton_Chuvakin and _TimPeacock. We're going to debate the underscore later. 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.

Thank you, Roni.