EP55 The Magic of Cloud Migration: Learn Security Lessons from the Field

Security. Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here, as ever, are myself, Timothy Peacock, the product manager for threat detection here at Google Cloud, as well as Anton Chuvakin, a reformed analyst and 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 like our content and want it delivered to you piping hot every Monday Pacific time, please do hit that subscribe button. Finally, you can follow the show and argue with your hosts on Twitter, twitter.com/cloudsecpodcast. Anton, we're talking about a perennial topic of ours today, cloud migrations and the security challenges therein.

Yes, indeed. And I think that the fun part today specifically will be the fact that It turns out the wave of people who approach cloud while thinking about cloud, as opposed to thinking about on-premise, is increasing.

Really?

Like, we're going to have people do cloudy stuff in the cloud rather than just copy VMs. How magical is that?

Do you think we're helping? Do you think our show is helping people think with cloud?

I suspect so, yes, because I feel like our constant jabs at the lift and shifters and constant pointers that these Some of the worst security mistakes you can make is when you copy on-premise technologies, on-premise ideas, on-premise practices, on-premise mistakes to the cloud.

Yeah.

That's when the bad stuff happens.

That is when the bad stuff happens. And organizations, when they're beginning their cloud journey, they have an awesome opportunity to get it right from the start. And it's really wonderful to hear that people are starting to actually make the most of that opportunity.

That sure seems like it.

And with that, listeners, I am delighted to introduce today's guests. We're joined today by Brandy Anderson, a Global Security Practice Lead here at Google Cloud, and Renzo Quadros, a Regional Security Practice Lead, also at Google Cloud. Renzo, I want to kick it off with you today. I want a story about some of the big hits or near misses in your cloud migrations from a security standpoint.

So we have an interesting kind of task over here with the group I'm on. It's kind of a combination of helping people move securely into the cloud and helping them kind of get onto Google and understand how to use this more effectively. So we kind of have this twin thing of when we meet a client, we go, hey, we're going to move your on-premise environment that you've built over the last 20 years into Google in the next couple of months. It's a high-stress process for them. But what we do is we lay it out. We say, hey, look, this is something that we can do in a couple of months. You just have to follow a process. You have to work with us. And then once we start doing that and we kind of get them to understand, like, hey, there's a process or a method to the madness, and we start saying, here's what's gonna happen, here are the questions you're gonna have at each point, and we kind of show them that we have control of this process, it makes things a lot easier for them. So that kind of puts them at ease about moving into cloud. And then once we have that, one of the big things we like to do is we start talking about how you have to kind of shift your thinking from your traditional on-premise mindset around security into how that kind of changes in the cloud. So for us, usually what works really well for us is when we're starting off and we're kind of getting them to understand the cloud, we want them in the same language as us and understand our thinking. Honestly, one of the best things I found is we have a white paper or document called Best Practices Around Enterprise Architecture. By far our best documentation around how to build an enterprise environment in the cloud.

Mm-hmm.

So if you start from there, it just kind of walks you through the whole process of why you start with org hierarchy, org policies, IAM, and so forth. Once you get that, they understand the whole process. That's huge. After we get that, we like to talk to them about 2 different things. First of all, if you're gonna build an environment in the cloud, people are gonna be a little curious about it. So you're gonna wanna point and say, hey, there is a structure to how you secure it. The 2 places we point them to, depending on the type of company, is our security blueprints. So that's well known. They're definitely on our security page. Or the other one we kind of say is read that, or if you want something more structured, this is a great time to effectively build out your cloud security requirements. And you can start with places like the CSA, NIST 800-53, the CSF. All those are great ways to kind of get that like initial like footprint to get them going.

Mm-hmm.

The other big ones we've kind of noticed is this. Once we get them building, we're building things out, people get really, really excited about cloud, and they start getting in there really fast. You get that excitement where people are like, hey, I want to get something spun up in Kubernetes, or I want to spin something in GCE, and I want to tie it into BigQuery, or I want to tie it into our AI/ML products. People get really excited and jumping really fast. Well, we've noticed this. 3 years ago, 4 years ago when we started, we'd say, hey, you have to wait a few months till we get there. And that would kind of drive people nuts because this is cloud. You can spin it up and have a public IP on something under a minute.

Yeah, I've done that. And if you're not careful and have something vulnerable on that public IP, you can get owned in a minute too. It's awesome.

There you go. That's always kind of people's risky part. So we've changed now is you get on, we kind of show you the whole process, and as we're building out your entire environment, we will stand up a sandbox environment and we'll secure it right off the bat. Instead of having to wait a few months, now you're up and 3 weeks later you have your sandbox environment. It's secure, it's locked down. You can play your heart's desires with everything you want. And now basically you're letting people play in the environment, get them excited, and you're using our IAM, you're using our VPC service controls, our firewalls, our logging and monitoring, our security command centers enabled. And this is just a quick sandbox. It's just fantastic. If you hold this full process, you get them Here's the process. They learn our language. Here's how we do security. Here's a chance to build out your cloud security requirements with us. And then by the way, to keep you guys building stuff securely, we're going to build this sandbox. And then people start to realize they're in the environment, they're playing with things, they're excited. And the really cool thing is they haven't even noticed that we've secured the entire environment and they're still accessing it. And they don't even notice they're behind multiple layers of security. They're just playing with it. And they're secure. That's just such a quick win for, you know, usually the cloud sponsor and other people are like, oh, wow, they got in the cloud 3 weeks in, they're playing with something, they're building the environment in parallel. It's just really awesome stuff.

That's awesome.

So, Brandi, anything to add on other lessons from clients?

As we've worked with security teams, one of the things that we find is that cloud is a different journey for security teams than it is for the development teams. It's been our experience at several customers that we need to come in and we need to provide that assistance and that kind of baselining. So, we have several times where we've gone into customers and we've taught them Linux, we've taught them Python, we've taught them how to write policy as code. And that's one of our offerings that we offer customers is to get in and really take your security team, and explain how Google Cloud works and how the cloud in general is going to be in your organization and how you can provide security in that space. And so, we've had a lot of success with that in, you know, customers love it, customers get a chance to try it. We also have the chance to come in and talk to them about logging and monitoring and some of the regular security concerns that they have and say, all right, these are the MITRE ATT&CK frameworks, these are the logs that play in this space. This is what you want to look for. These are the tools you can use and, you know, offer some capture the flags and some things like that that give them practical security experience in Google Cloud and how they would use it in their environment, Pub/Subs into whatever their third-party SIEM is, you know, and really discuss how you break that down, including even billing, because we'd love to have all the data. But all the data becomes kind of expensive at some point, or it can. So, we talk about, you know, how you work on billing and really pick and choose to make sure you're getting the most bang for your buck in your logging and monitoring.

Of course, that's our favorite subject on the podcast. Well, one of, and both Tim's and mine, naturally. So, I wanted to sort of start turning from this fun starter to one of the questions I always love to ask, and that's mistakes. I know in particular from other podcast episodes we've done with security leaders, with Phil Venables, with others, is that they kind of point out that sometimes people go to the cloud with a lot of on-premise mindset and on-premise ideas. So we tend to think that if people approach cloud as a rented data center, it's a mistake. But what are other common cloud security mistakes you encountered? Of course, you don't have to name clients. In fact, it's better if you don't. But some of the general— Likely incorrect, erroneous practices you've encountered, and possibly tricks to mitigate them if you can do it, Renzo.

Here's the great part. If you asked me a few years ago what kind of problems we're running into, you'd run into really basic stuff. Luckily, it's been a few years now. People have actually learned more about cloud security. So in general, we're moving away from the old-school mindset of on-premise, and we're going more towards cloud-native, which is fantastic. Some of the issues we're kind of still seeing are— I'm just going to say an example. Things we used to see years ago would be People over-relying on their firewalls and not spending time on IAM. IAM inside cloud is such a huge thing. An example would have been like people years ago were using our primitive roles. They've now moved away from that into more of our predefined and custom roles, which is fantastic. So you're seeing a lot of that. I wanna say some of the things we're kind of seeing these days are, I'd like to see a little more control of public IPs. So I'm seeing people put public IPs where they really shouldn't. I'm seeing people not control their edges, like their network endpoints. You know, IAM still is there to help you. Being coming from an on-prem world, I still like to know where my network connects to the public internet. So I'd still want more control around that. I want to say those are some of the bigger ones. Under logging and monitoring, also another part I really enjoy. Google has your admin accounts, you know, that's all logged, that's there right off the bat. What people kind of fail to turn on are their data access logs. That is a favorite of mine to understand.

Hmm.

But these are very chatty. So people who are afraid of them probably copy their on-premise thinking. Imagine a traditional database where you record every select statement. I mean, a vendor can write lots of papers saying, hey, please do it. Customers just didn't do it because they're afraid of the volume.

Oh, you're spot on.

So I can kind of relate to that.

Definitely heard that. And what we've kind of pushed to now, instead of capturing all of it, we basically write filters that say, hey, you're going to actually get the data feed. And the ones we want you to pull out are anything that's not the approved service account or the approved user. So if you see things of that nature, then capture that log and let us know about it. But you're spot on. If you turn on something on a database or public-facing bucket, you're in for a world of logs, but you can definitely get around that. But those are probably the big 3 things that I'm kind of seeing now. I will say the ones I'm kind of really excited about are I'm seeing VPC service controls being turned on a lot more. If you're a security person and you understand how that works and protects your APIs, when you mix that in with, say, our hierarchical firewall rules, just like, man, it just helps secure your environment. It's such a massive win. So I'm excited with the way things are trending.

Perfect. Brandi, any of your favorite mistakes?

I think Rinzo did a really good job of covering most of the mistakes. I will say that the exciting part is, to his point, how customers are starting to take it up a notch so that Next level of the cloud-native thinking. Some of the security questions become more around, what do we do in incidents? How do we prepare for incidents? So, we're getting a lot more of the real questions of how to deal with cloud, as opposed to, ah, cloud is coming, and I don't know where to go from there, right? So, it's nice to see that level up of customers, and we are seeing that a lot in most of our customers in most of our spaces.

Perfect. That does make sense.

It's great that we've started talking people out of lift and shift. It's great that people are adopting VPC-SC and understanding the importance of IAM. Do people really understand that their threat models are different in the cloud as well?

I'll take that one. I want to say 2 things. I'm hearing threat models more this year. Like, this is something the last, say, 6 months I've been hearing from our clients, hey, we'd like to see your threat model. And there's 2 things at play here. One, I think in general, people understand that threat models are important. They're just still not 100% sure what to do with them or how to consume them and make them actionable. So I'm seeing that. I like that. I appreciate that. So when I hear this, there's part of it kind of goes with the actionable, like, how do I basically educate them on how to use this? So there's a lot of education about, you know, how to take a threat model, make sure you translate that into either requirements or solutions for your environment. By and large, I think people, if they know threat models, are usually still taking it from an on-prem native approach.

Thank you. Let's just, like, pause for a second and, like, meditate on this. This is very true, and this is amazing to me that cloud has been around for, what, 10 years? And your point is exactly what I've observed. People approach cloud threat modeling by copying their on-premise thinking and then trying to do a diff or do a slight modification or do a, like, edit a document to like cloudify it, right? That's roughly the idea.

Spot on. And it really, really is that. But actually, here's the good part. It's nice that they've thought about it. And usually when they kind of provide that, they'll acknowledge where they're at and they'll say, Google, can you help me turn this into cloud? And it's that moment where they at least acknowledge they've had it and they're excited to kind of take it and run with it. Those are the exciting ones. Every here and there you see the people are like, hey, here's my on-prem approach. Let's apply it to the cloud. And in our case, usually we have to spend a little more time being like, hey, let's talk about this. Let me work with you so you understand why cloud is different, why like IAM is king in the cloud, things of that nature. So it's definitely something educational.

We've spent a fair amount of time also building out threat modeling around our services. We internally at Professional Services have taken a bunch of services and said, what is the attack surface? If we were threat modeling this and we were relating it back to MITRE and some of the attacks, what does that look like? And then what are the mitigations? And we've done that so we can provide our customers some of that work in advance, and then they can go from that to what their application is going to do, right? So we've given you this basic baseline threat modeling. Now, how does your application plug in and where do we go from there?

But do they also approach it as changes to priorities of threats? Because admittedly, you can threat model the fact that somebody can steal a hard drive from a cloud provider data center. But on my list, it would be like number million gazillion. It's probably like the bottom number one threat I would cover for. But some people have encrypted hard drives in their on-premise data centers thinking of that. So clearly, the ranking is different. So do we have any kind of advice to clients about how to sort of re-rank the threats they have in mind?

I'd say no, but not because we don't have an opinion, but more because it's with each customer, right? So as we work with each customer, I heard an example the other day of a denial-of-service attack for services against a hospital is much different than a denial-of-service against a mental health clinic. Those are very different things because you have something that could cause patient harm if they lose services versus maybe they lose records or something like that. So you always have to take the individual customer and what their concerns are to bear. You have to look at that when you're in these conversations.

That's so interesting because you think about extortion attacks, an extortion attack on an orthopedic institute, way less damaging than say an extortion attack against a mental health clinic. So you're right that when you're moving to the cloud, you really do need to keep your application and your business context in mind. There's not a one-size-fits-all, oh, you're in the cloud now, this is your threat model.

Right.

I want to switch from the exciting world of threat models to the potentially somewhat boring world of compliance. So I still see customers, whether they're in Europe or here in the US or in different countries, that sort of still start their security thinking from regulations. What do the regulators require? So how clients typically handle compliance in the cloud in your experience? I know it's a bit of a can of worms question, but just give me some highlights, Renzo and Randy.

Actually, I see 2 things here. When I hear about this kind of like question from clients, we talk about 3 things. The first one is clients usually start off and say, hey, can you tell me about BigQuery or whatnot, or any kind of our product? Can you tell us like, you know, what compliance frameworks do they meet? What are they accredited with? I'm not going to downplay it. It's definitely important. You know, we hear that and we have All of our products are built to a certain standard. We provide that documentation. Clients start off, you know, they're like, check. The next question I get is if we're migrating them into the cloud or building a solution, they want to make sure that whatever we're building for them is also still compliant. So we're still kind of building all the proper security controls. An example I give is just because, say, BigQuery, the way we built it, meets whatever compliance framework you want's goals, If someone goes out and deploys BigQuery and puts very open IAM controls or makes the dataset available to whomever, great. You took something that could be secure and made it insecure or not secure. So like what we talk about is when we're building your environment, we're gonna take your compliance requirements and we're gonna map them to your environment, your services. We're gonna show that full traceability. And then here's actually where the exciting part kind of kicks in, 'cause clients get that, that's been there. But with cloud, what makes it more exciting is since everything is built with Terraform, we can say, hey, we're gonna put Terraform in here. And then in order for you to show your auditors or your own internal compliance team that you're secure, we're gonna do a couple things. We're gonna do some sort of policy as code framework at the front. And this would be things like Terraform Validator or HashiCorp Sentinel. And what this does is say your rules say that you don't allow firewall rules for anything other than, say, a /24 subnet. When you go to create a Terraform rule that says that, your policy is good, we'll check that and say, you know what, this is not in compliance, and it'll block that change, alert on it, or give you some sort of action. That little one additional step about how you now automated what used to be a manual process and you prevented it from occurring gets clients really excited. And then later on, to keep it going, we'll also build in— we'll use our cloud logging with our cloud functions to periodically scan your environment and say, hey, you are still in compliance, or we'll use Security Command Center with Security Health Analytics to do the same thing. That starts getting clients really excited, saying, not only are we preventing bad changes from getting into the environment, if we do, we still have multiple layers of security with these other layers. That gets them really excited. We're also building on top of that, and this is more in that early stage, is auditors love documentation. We have all of these things being caught. Everything's being caught in our logs. It's very easy for us to take those logs out and then put them into basic automate and have it written into a document. So every night you want to send them a report saying, hey, we ran checks at this time, this time, this time, this time. Here's all the tests we ran. It's all automated. When you start talking to auditors or banks compliance people about that capability, it's just such a game-changing. experience for them. Compliance is usually really not exciting, but when you start thinking about how you could automate this and open up hours of time for people a week, the nerd in me kind of gets really excited about it.

That makes sense. But I think despite this, aren't there regulations that were born in the 1990s or perhaps in the early 2000s? So when both of you think back to your experiences, can you name one or two regulations that just seem to be the hardest for the clients in the cloud?

Oof. You know, the problem with regulations that all IT folks know is that they're this set of standards that say, don't do bad things. They're not very specific on what the bad things are. And so it becomes so much subjective that it makes all regulations difficult. But you also find that when you're talking to a customer, you know, I was talking to a bank CISO and I said, if we came in and talked to you about FFIEC and some of the regulations you have to meet in the US and built a program specifically around that, how helpful would that be? And he said, not very. He said, because it's not just one regulation, I have to apply to all of them, right? I have PCI, I have every privacy regulation I have, you know, you name a state that has some regulation, I have to comply with it. It's that view that we kind of look at saying, all right, how can we hit the most with our GCP controls and do the most good that it's maybe 80% of the compliance requirements? And then we just work on the delta, right? What is the little tweaks and differentiations between the different regulations in Australia and the new privacy law in China and the new privacy law in Brazil that are going to potentially cause additional control issues down the road for our customers?

Perfect. No, that does make sense. And I think that the fact that it's not just one, not just two, but possibly 50 regulations with sometimes conflicting and overlapping requirements, that to me sounds like the number one challenge. So that makes sense. I wanted to start closing, and one of the questions I want to ask is kind of a bit more philosophical. Some of the people predict a future where we would stop migrating systems to the cloud because most of the systems, most of the business data would actually be born in the cloud. Do you see any signs of the future where we are not migrating anymore because we are sort of cloud-native in the majority? Like, is this coming or not?

I think as New businesses continue to grow because we see a lot of digital natives coming out of startups. Then for the last 10 years, as you say, cloud is this old, it was the quickest way startups could get in, get built. They didn't have to invest in the infrastructure. It was a fast, quick way to build your business. We're always going to have some of these legacy corporations that are going to slowly move to the cloud. Frankly, I've heard stories of companies that have moved entire data centers Intact because they couldn't replicate what that application did in the cloud or anywhere else. So, when it came time, they just packed it up all in one and moved it to a new location. I think there's always some of that that happens until folks get more comfortable and developers can develop for the cloud-native environment to hit what end companies are looking for.

Okay. That does make sense. And I agree with you. I think in 10 years, we would still be talking cloud migration for many organizations. So typically, we close with 2 questions, and these are, please recommend some reading materials to the audience. And the other question is, please give one— and I really mean it this time— one bit of advice to securely migrate to the cloud that's kind of defined by your experience. Renzo already mentioned some reading materials, like enterprise architecture white paper. Happy to take more, and then one bit of advice, hopefully from both of you.

You know, I really like the Security SRE book that was released by the internal Google team. It gives a nice view of securing your environment in the cloud.

Perfect. What about any advice? Like, what's the number one bit of advice to securely migrate to cloud?

Whenever you hear security advice, very quickly, the first step you should do is divide it up and say, will this make us deploy faster, or will this make us more secure? And the example I give is this, is if I take a poor security configuration, and I put it into Terraform, all I've done is I can now push a bad security configuration into the environment quickly. Right now, inside a cloud, you're seeing a lot of advice around how to do something faster. There's so many tools out there around Terraform this, or the ability to do some sort of policy as code. That's super important. But if the content that's being checked isn't really valuable, then you're not really gaining very much out of it.

So the advice then is don't always jump to do things faster, or is it to balance? Like, how do you sort of structure it?

Yep. The advice is when you have a problem, people will start giving you advice. Figure out what the problem is. Is the problem more, hey, you have a gaping hole in your environment, like you don't have application security? Or is it you have application security, but your pipeline to get those controls into all the applications is not very good? The example is this. I was talking to a client a while ago, and they basically said, hey, we have this great pipeline. Security's built into it. And then their engineer's like, yeah, it's a great pipeline, but it's optional to go through it. So all of a sudden, you have these great security controls. And I'm like, how much of your environment goes through this? He's like, maybe 50%. So now suddenly you have these controls, but the execution is broken. At that point, the biggest bang for their buck for them was to force all clients to go through the pipeline. To hear that, like, and I find I'm talking to a client in a similar position and they're like, we want to make ourselves more secure, let's have more automation. And I'm like, your biggest problem is you're not even implementing the security you have right now. So it's little things like that, which is that, do you have a solution or do you have the proper execution pipeline?

That does make sense. And I think that it's a perfect ending for the episode. Thank you very much for being here and very much appreciate your advice and, of course, your time. Thank you, Brandy and Renzo.

Thanks.

Thanks, Anton.

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

Security.