More Cloud Migration Security Lessons

Security.

Hi there. Welcome to the Cloud Security Podcast by Google. Thanks so much for joining us today. Your hosts here are myself, Tim Peacock, the product manager for threat detection here in Google Cloud, and Anton Chuvakin, a reformed analyst and member of the cloud security team. Here at Google. You can find this podcast wherever podcasts are distributed, as well as at our website. We've actually launched it now. It's at cloud.withgoogle.com/cloudsecurity/podcast. If you like our content, please do consider hitting that subscribe button. You can follow the show and argue with your hosts on Twitter as well, twitter.com/cloudsecpodcast. Our episode today is really a fun one, Anton. We've got a wide-ranging set of topics, but I think what we kept orbiting around is this concept of the cloud So first off, what's a cloud migration anyway?

So this is a fun one because it's a topic that came up, I think, 4 times. And it's kind of about a journey for a company from their existing state to some kind of a better future state in the cloud. And of course, for some of the organizations, we do see them approaching cloud as just a rented data center. So they end up in an extreme lift and shift scenario. They sort of just take their systems, make them into virtual machines, and then copy virtual machines in the cloud. Now, we can make all the jokes we want about this, but people actually do it and people It breaks my heart. It does a little bit because ultimately they don't use some of the cloud advantages. In fact, many cloud advantages, including many security advantages, right?

Yeah. I think that, you know, one of the things I love about cloud is this homogeneous access control layer, homogeneous API layer, as well as homogeneous logging layers for all of your infrastructure management. And if you're not approaching it as this programmable infrastructure, I really feel like users are missing out on so much opportunity. And that's to say nothing of things like BigQuery or its equivalents in the other clouds and all of the other amazing services offered on top of the infrastructure offerings.

And also they bring some of their security mistakes with them in the cloud where their blast radius can be higher. You can have a host security mistake on a server deep behind many firewalls, but if this server becomes a VM and all the vulnerabilities, all the mistakenly open ports, all the other stuff, just magically happens to repeat in the cloud, but then it's one control away from being open to the internet. It's one X control rule away. So, if you're doing it the cloud-native way, it won't happen. But if you're doing it the on-premise way, copying to the cloud, keeping all your mistakes and all your baggage, the chance of that mistake is just higher. That's a fact.

I think I have to agree with you there. It is really interesting to see, as we talk with different guests, how people approach this problem of You know, the security garlic versus the security onion, and how with cloud you have both more controls, but also more ways to get it wrong. So with that, why don't we turn it over to our guests today? Jane Cheung, a Vice President of Cloud at Palo Alto, and returning guest Joe Crawford, a Director of Strategic Technology Partnerships for Google at Palo Alto. Those titles are like varying degrees of mouthful. One is very small and one is very large.

Yeah.

But I'm delighted to have both of you on the show today. Anton, I think the first question is coming from you today.

Indeed, indeed. And I think that I wanted to kind of focus our guests and, of course, enlighten our audience about the topic that we visited a few times on the podcast, and that's cloud migration, how people actually journey to the cloud. By the way, as a funny aside, I got into a Twitter fight today over the question of lift and shift. I was always brought up with a concept that lift and shift is kind of a pejorative term that indicates going to the cloud using the on-premise playbook. and kind of avoiding the cloudy things in the cloud. But it turns out I see more people who use lift and shift as essentially a strategy. They say, we're going to lift and shift the applications. So it turns out the concept of migration to the cloud is still very tricky, including for security professionals. So Jane and Joe, we have a few fun questions for you. One is, what are the top security mistakes you've seen during cloud migrations?

I think that the number one mistake that I see is probably trying to fit on-prem in the cloud. Hopefully we won't have a Twitter fight about it, but the reality is you can't move on-prem to the cloud because you lose to a certain degree the physical access to a data center. You lose the bare metal machines. So there is some idea shifting that needs to happen in order to go to the cloud from a security perspective. I think the next thing I see is that organizations are just not prepared for the additional logs, the security event details, and the education and the training that needs to go into their security teams to handle the cloud and be able to threat hunt in the cloud. And I think finally would be not understanding the differences between clouds. I remember when I first got into cloud, I was at an organization that was trying to adopt 3 clouds all at once.

Whoa.

And they said all of the cloud should look alike. Going to the cloud should look the same in every cloud. And it's just not possible because Google Cloud is not AWS and AWS is not Azure. They all have different quirks. They all have different services. So I think lift and shift is maybe not the term that I would use, but definitely trying to move on-prem into the cloud is top.

Joe, what's an appropriate analogy to help people understand the degree of difference between the clouds and how that impacts their security strategy? How would you help someone wrap their mind around that?

I would say, depending on what you're trying to do in the cloud, I've always described Google Cloud as a very developer-friendly cloud. Where AWS is very much more of the traditional infrastructure type networking and data center, where Google is very much more easier to understand, and it's friendly for developers, and you don't have to do so much button flipping to create.

So what I'll give you some examples, we have a client that actually has a very large Kubernetes deployment on-prem. And when they decided to go to multi-cloud. One is Google Cloud. What they did not understand is all the security posture that was possible in on-prem, using the firewall to block a lot of bad things from coming in, and then using all the forensics tools that was for on-prem if they find some anomalies or issues. Now, when they actually moved over to the Google Cloud, GKE services, and then Kubernetes services. What they did not realize, because Google Cloud is a developer-friendly environment, it has public IP address as a default just showing up. And it takes, you know, 60 to 90 seconds for them to get hijacked and ransomwared or being used for the Bitcoin mining, a lot of other unpleasant things. After the third incident, Finally, we got the developers' leadership's attention to put appropriate cybersecurity protection, and then also policies and guardrails so that such events that's so unpleasant for our security environment to mitigate certain things happen. And it requires training because Google does offer very robust SRE-led trainings And what we found that for this particular client, they were not even taking a look at the best practice guide, and they're not even looking at the training guide. So, net-net, toward the end, taking a certain number of courses from Coursera, protecting their Kubernetes and GKE environment became a mandatory requirement before they start writing their application onto the cloud.

That actually makes sense. And by the way, Tim, remember during another podcast, we kind of had a line from somebody who said, In the cloud, you may be one network security mistake away from compromise, or you may be one identity mistake away from compromise. Like on-premise, you may have a system that's protected by a firewall, and you make an identity mistake, you're still behind the firewall. In the cloud, if you make an identity mistake or one permission mistake, you're exposing an IP address. So it's kind of about the peculiarity of security posture. If you expose an IP, somebody can probe it, right? But it's one action that exposes the IP. So there's less layered defense in this regard.

In that regard. But we also had the security onion versus security garlic metaphor from Seth on a different episode. And I think he made an interesting case about the way that cloud gives you, in some cases, more layers of defense. So I think our debate on that one is going to continue to go back and forth, but it's an interesting area to be sure. Jane and Joe, what's your advice to security leaders who want to go to the cloud using the, you know, listeners can't see it, but I'm doing air quotes right now, the on-premises playbook?

Oh, don't?

Don't.

Yeah, but like we all say don't. I think we use the same joke a few times and you said don't on your own episodes. And you're talking to somebody who is much more senior, who controls a $100 million budget, and he plans to lift and shift. He plans to go to the cloud as if it were a rented data center. What do you tell him?

I say use cloud adoption as an opportunity to renew your playbook. Not rewrite, because a lot of your governance and your regulatory, you know, all of that stuff is going to be very similar. It's probably going to be the same. So, you don't have to rewrite it, you just have to renew it. And some of the stuff you need to understand right out the gate is what the go/no-go line in the sand is. You know, if you have a specific application and you have some sort of in-house security control that for whatever reason you don't think can make it in the cloud, I would argue that, but— That being what it is, you need to make the no-go call on that early because getting that analysis paralysis is in fact a security issue in the cloud. You don't want to have a bunch of half-built applications out there. And then I think the other thing is you have to understand the cloud models, right? So IaaS, PaaS, SaaS, and look to the third-party providers for security solutions.

Mm-hmm.

Many of the same vendors you have used internally for years are now in the cloud. And they're doing a really great job of making sure to close the security gaps and bring things to an enterprise state in the cloud. So I just think that it's an opportunity to renew.

I like that answer a lot, that your goals of a security program aren't changing. The things you're beholden to are maybe not changing, but how you get there is an opportunity for renewal. That's, that's a good answer.

And I want to share with you some examples of why this playbook has to be renewed. So for example, I think there is a lot of misconception or misunderstanding on how the cybersecurity works in the cloud. We have a traditional way to develop our software, and that might just require a lot of firewall on on-prem and forensics if needed. The tools that's being used in on-prem is no longer viable in the cloud. The on-premises security perimeter is now in the cloud base, and there's many different ways for our adversaries to attack that workload or that application effort or that VPC or projects, what have you. So, you want to adopt a new cybersecurity posture that's going to address your growing areas. That's why I really support what Joe said. You need to renew your playbook.

By the way, in the same Twitter discussion I mentioned, somebody said, don't do lift and shift, do move and improve. And it's kind of stuck in my head a little bit that if you want to move, but you're not prepared to re-architect everything, rebuild everything the cloud way, you can at least improve the playbook. So there may be incremental steps that are different from just copying your infrastructure over.

I like that.

Move and improve. That sounds like the advertising slogan for gym memberships too.

So now we need to have a link to that tweet. Otherwise somebody will say, oh, you stole my idea.

Yeah, no plagiarizing Twitter.

So by the way, another thing to poke into from what Jane said is that clients she mentioned may have used the forensic tools that they were built for on-premise environment, and there were other products that were used or attempted to be used for the cloud. So I'm realizing that I'm talking to a security vendor, Palo Alto Networks. So if I would say something like, surely some technologies won't be needed anymore in the cloud. So which products or which types of technologies are maybe not needed? Which ones are transformed by the cloud? And which ones are, well, still needed?

Some of this relates to the type of deployment you have, how you use your compute, for example, whether you're keeping pets or using them as cattle. I think you have an argument to be made that maybe endpoint security is going to be impacted. If you have workloads that are tearing down and then spinning up new instances every 24 hours, is it really worth your time, money, and effort to maintain endpoint security on those? I think that's something that each organization is going to have to make as they move into the future. For transformation, I think network security has changed immensely. So I think that COVID really sped that up too. So when we sent everybody home and everybody was suddenly a remote employee, traditional network security was not going to be the solution that we needed. So I think the Secure Access Service Edge, SASE, that's really going to be the firewall of the future. I think that we're evolving past the traditional stateful, stateless firewalls of the past. More workload protection is probably going to move towards behavioral analytics as opposed to what we've known it traditionally to be. So I think there's a lot of transformation. If I had to guess which one is going to become less relevant in the cloud, I would say traditional firewall will evolve into more SASE products.

Joe, were you the guest who suggested that we, uh, let our firewalls out to pasture?

I was, I think we agreed we were gonna throw them in the buckets.

That's right, we put 'em in buckets.

Are you guys really saying this? Like you really do work for Palo Alto, right?

They don't make firewalls, they make next generation firewalls.

That's right, next generation. Another aspect of what's transformed by cloud is how we are inspecting if incident does happen, right? All the logs sitting in the cloud and you need to put a right type of forensics tool to analyze. But a lot of things that this particular customer painfully experienced was because of the earlier mistake for ransomware and hijacking of network, many other mistakes that they made. Cloud is just so scalable and it's just so fast, right? The speed and agility that cloud provides, what makes cloud so special. And they automatically assumed that fairy is going to show up and turn on the logs for the Kubernetes. So, when they get these incidents, if you don't turn on the logs for forensics to kick in, we can't do anything because often the developers delete those Kubernetes instances, and there's no way to find out what happened to that incident. So, awareness and training is very important as you're moving your developers over to the cloud. Because a lot of things move very fast, and development could enhance. However, you do need to have some best practice guide how to behave in the cloud. So, Joe and I were talking about it earlier, what are some of the crucial things that we could do to bring that security awareness to developers?

Yeah, I think the, the main thing is to make sure that they understand the cloud itself, you need to make sure that your developers are ready to go to the cloud before they actually head to the cloud, because the development in the cloud is going to be very different. And I think you do more of a shift-left mentality. You need to drive this from security, from the point of infrastructure as code to the point where it meets a production environment. And you have to automate. And not to put a shameless plug out there, but look up Automate or Die. It's a fantastic episode. You have to automate security because there's There's no way at the scale that we're moving with cloud that you can manually audit everything. It's just not going to happen.

So, a couple of things in there that I think are super interesting. On the logging front, one of the things I love— I obviously look after a product that processes logs— I love that so many things in Google Cloud are logged by default. The Cloud Audit admin activity logs are just a phenomenal source of insight for people. But you're right that there are risks of logs not ending up off of instances and things being hard to find once they get deleted. On the front of shift left and the speed of cloud versus the speed of on-prem, we have this meme, and I think we as an industry and a group of professionals have done ourselves no favors over the years. We've created a perception that security slows things down. The point of the cloud is to be fast. How do we help people have secure outcomes without slowing them down like we've been doing for 30 years?

Much of what I would put into answering this question would be that we need to Have security ingrained into the organization through training. The DevSecOps mentality is a huge part of that. But having granular security from the time that it's just code all the way to the time that it's production, that's where you're going to get your agility.

Hmm.

Automating that and then being able to go back and audit the security controls themselves, as opposed to auditing every single aspect of an environment. I think the second thing I would add there is make sure that your security leads Understand the cloud, not just as a concept, but as a specialty. I know a lot of things about AWS and Azure, but I specialize in GCP. And so when I go to talk to an employer, for whatever reason, I go specifically to talk about Google Cloud. I know the Google Cloud APIs. I know what they do. I know the underlying services that they talk to, and I can build based on that. If I was to go and do this for AWS or another cloud provider, It's not impossible, but it would take time to develop. So I think making sure that you're very specific with your security leads is also going to be important.

To double-click that statement, Joe, you hear CI/CD pipeline, which is continuous integration, continuous development. I think we need to add continuous testing for security on the part of the pipeline process, because if you are already checking vulnerability on your code at toward the end of your journey, to promote that workload to production, it's too late. It's going to cost a lot of time, and it's going to cost a lot of effort to fix those. So, that continuous testing for the security and making sure your code is not vulnerable, I believe, is very important.

And that can be done without slowing things down if security is tied with the modern processes, as opposed to they try to push the, you know, quarterly review for a week, and the development process works in a matter of hours. I've seen these things really blow up quite badly because just a complete culture clash. I don't think coining longer acronyms like DevSecOps is the answer. I think the answer is working together.

Anton, you must really have graduated from your Gartner days if you don't think new acronyms is the answer.

Surrender. Yeah, you're right. We should really have an acronym. So to kind of further follow on that theme, I've also noticed that some clients assume that they would go to just one cloud, and so they would go and ask that provider for security, but others go and stay hybrid, meaning there's significant presence on-premise and in the cloud. Some are multi-cloud, and of course, some are multi-cloud with on-premise. So, how, in your opinion, security needs change based on the cloud adoption architecture? And again, I suspect that you'd have clients who are very cloud-native, who were just born and live in the cloud, and you have clients who are very much on-premise companies slowly migrating. What's your take on How security needs change in regards to adoption architecture?

Yeah, I think a lot of that is kind of dependent on how you're going to operate as well, what your workloads are going to look like. I know we kind of keep beating that drum, but it makes sense. So, you know, if you're going to run a hybridized solution, are you just using it for storage? Is it going to be for backup and failover? You need to worry about reliability, you need to worry about data backups, access control, and of course, access to your assets. And network security, perimeter security. The same is true of multi-cloud. What is the access solution and/or methodology? How are you ensuring a secure perimeter engulfs your workloads at all times? And of course, how do you maintain visibility across clouds and access to all environments? I mean, how are you actually making sure that your cloud looks like it's supposed to look? And how do you help your threat hunting team be able to move through those and separate the on-prem from one cloud to the other cloud? There's a lot to this. I think that you could probably go down a rabbit hole pretty easily here, but I think also you have to avoid overthinking it so you don't end up without the agility that you're trying to get. So, I'll just say there's a lot to it, and the model that you choose is going to impact your security practices significantly.

And Joe, just to double-click on the visibility, that is probably the key for anybody who's thinking about having a multi-cloud or hybrid cloud. Because if you can't see what you're trying to protect, and if you don't understand what you have, it's going to be a very difficult journey to the cloud. So highly recommend for all our clients and customers out there that you understand what your assets are, make sure you keep that inventory, make sure they're secure before you are transitioning to the cloud.

That concept of inventories gets back to something that John was talking about with protect surface and really understanding what your organization is up to before you undertake any kind of migration. I want to go back to the lift and shift thing and spend just a little more time there because we see so many people engaging in lift and shift. From a security perspective, is there really such a thing as lift and shift? I see products getting built really aimed at this market, and I'm wondering Are we leading people down a bad path here by trying to enable what is kind of an anti-pattern? Is there a good thing here?

I'm not sure that it exists as a 100% solution. I think that lift and shift can exist on a subjective basis. Maybe one application or one process exists similarly in the cloud that it does on-prem. But I would say that most of the time, no. And the main reason I say that is because no matter how large your organization is, if you have a data center that connects to 2 other data centers, you always know your attack surface and you know the geography. The minute you enter cloud, you have a global data center. And so that changes dramatically everything that you've worked to secure in the past. So I think that alone, the fact that you go from a smaller attack surface to a much larger attack surface changes things to the point where you can't just say, well, I'm lifting and shifting from a security standpoint. I think that it becomes much larger and your first order of business to kind of shrink that attack surface.

Joe is absolutely right. I don't think there's such thing as a pure lift and shift because I was sharing with you the earlier example of this particular customer that are heavy user of Kubernetes. When their solution moved over to the Google Cloud, a lot of attack surface changed, awareness changed, and they needed to do some fundamental hygiene when it comes to DevOps cybersecurity. So, it is very important to renew your playbook and understand it's a completely different infrastructure. You have to adapt and transform your application accordingly, so you could take advantage of the speed and agility and flexibility that it gives you. So, I always use this analogy, said, hey, I was driving a Mustang, then now I'm going to cloud. I think it's something like Formula 1 drivers are using. So, you have to know how to drive those kinds of cars, and you have to have the right type of security posture to deal with the pressure, or what I call it, like, G-force, right?

Yeah.

It's a whole different world out there.

I think it's more of an evolution from, say, Mustang to Texas T-6. Like, you're moving in different dimensions when you're moving to cloud. It's not just faster. You're moving in 3 dimensions instead of stuck on the ground. Not to say clouds and airplanes, but that was the closest analogy I could come up with there.

That's excellent.

For our audience, I think that they should really pay attention to what Jane and Joe are saying because here's why. Generally speaking, traditional security vendors sort of benefit from people doing it the old-fashioned way and bringing more firewalls with them in the cloud. So the fact that they are giving us advice to actually not do naive lift and shift and keep all the security stuff they already purchased, to me, that adds a lot of credibility to their advice. I mean, this matters to me because as an analyst, I've seen people give a lot of self-centered advice. if people would show up and say, yeah, you absolutely have to have a firewall appliance even if you're in the cloud.

Mm.

Mm, okay. What else do you have to say? But to me, the fact that you have to transform and evolve is a must, and it's really good advice. So to continue with our flow, I still want to revisit that theme from a somewhat different angle, the theme of teaching people who grew up on prem/cloud. Jane mentioned courses. Joe mentioned other things to learn, reading guides, best practices. But what about the leaders? What about people who sit at the very top, And kind of don't get cloud. Imagine somebody who's a CIO or a CTO, or maybe even a CISO, whose career maybe started in the, I don't know, '80s, '90s, and his formative years were very much before the cloud. How do we teach cloud to security leaders who grew up on-premise and whose entire career was formed before the cloud era? How do we get them to evolve?

I think that you have to start with What the goal of the cloud is. I think you have to teach them more about what you're trying to achieve from a technology perspective as it pertains to the cloud, the rapid deployment, the ability to meet the needs and the demands of traffic. I think that's where you start. And I think that's where your foundation is just on, here's where we want to get and cloud can take us there. Give them some basic examples of how you can go there and then Fill them in from there by building examples. So put an application out there, put a simple application out there, secure it, and show them how it works. And then do a comparative analysis to the way things used to be done. Anybody who came from the old world when internal cloud became a thing, it was like, well, this solves all of our problems. Developers are no longer going to be sitting around waiting for servers to develop on, right? Nope. Wrong. Didn't happen. Now we're solving that problem. And so we have these pictures that we can look back to, like your grandma breaking out her photo album. You can look back, see where you came from and where you are now, and show them that not only are we doing it more securely, but here's how we're doing it. You know, the controls are more automated, we're looking at things as code, from code to production, and it's a controlled process, XYZ. So, you have to really give them some sort of value statement to go along with why cloud is. And then explain the security controls from there.

And we had clients, they are mandated by their executive CIOs to have an approach that's cloud-first. But sometimes in the middle of the cloud journey, they might not even understand why they even decided to support that whole concept. I think, Anton, you know what I'm talking about here. You can't just say, hey, the world is moving toward the cloud, so you must adhere to that direction. It's really that what was your expected outcome? That's business agility and flexibility to get to the market. You do have a competition who's taking even more aggressive approach to it right now. Transformation requires innovation. Innovative thought leaders are going to help us to get to the next steps. That reminder is probably very important because it is very painful for a lot of our enterprise customers moving from on-premises to the cloud, because everything that they used to control are not the same. All the knobs different, visibility might be not there. So, we have to continue this whole process of training and enablement and awareness for our executives and our developers as well, because things in cloud change so fast.

I agree with all of that. The challenge of, you know, getting people to think with cloud is one I face every day. And it's like thinking with portals, if you remember the game Portal, but it's different. You know, the world really is quite different in cloud. So I want to wrap up with 2 questions and you 2 can divide them how you will. The first question is a traditional question for us. And the second one is also a traditional question for us. The first question is, do you have a practical single tip to improve people's cloud migrations? And the second question is, do you have further reading? We hate to leave our listeners empty-handed at the end of a show.

I would say learn from others, read the trials and errors that other organizations have had, and look to your third-party vendors. They really are out there solving real-world problems. The book that I read most recently was The Perfect Weapon. Interesting book in case anybody wants to read about cybersecurity and how it can play a role in our real-world security, our national security. So interesting stuff.

Jane, same questions for you. Practical tip and further reading.

Practical practice is that I actually listen to a lot of podcasts that's done by cybersecurity leaders, especially around Kubernetes. There are many cybersecurity podcasts, including yours. I listen to it very often. Joe knows I'm on the path of getting my PhD, so I read really boring stuff like a NIST framework, CIS benchmark. CCM, CSA, but it does have a lot of knowledge in it and it gives you best practice what you should be doing, especially for the cybersecurity in the cloud.

One guest pitches something called Perfect Weapon, which sounds really exciting, and the other guest pitches NIST frameworks. So a very divergent end to the episode, but I want to thank both of you, Joe and Jane, for joining us today. I hope, Jane, when you come back, we get to call you Dr. Jane. And Joe, when you come back, you get to be our first third-time guest. Listeners, thank you so much for joining us today.

Awesome.

Awesome.

And now we are at time. Thank you very much for listening. We will post links to the materials we discussed at the podcast site. You can find this episode in Google Podcasts or wherever else you get your podcasts. Also, now you can find it at our website, cloud.withgoogle.com/cloudsecurity/podcast. Yes, we really do have a website. So all the tension, all the suspense that we're going to have a website, is gone. Instead, we have a website.

Please do consider subscribing if you like our content. That way you'll always get the latest and greatest as soon as we drop it. You can follow the show on Twitter, twitter.com/cloudsecpodcast. My co-host @Anton_Chuvakin and myself @TimPeacock. Do tweet at us, email us, argue with us. If we like or especially hate what we hear, we'd love to invite you onto the next episode. And so with that, We will see you next time on the Cloud Security Podcast by Google.

Security.