Do you have something cool to share? Some questions? Let us know:
Timothy: 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 perennial topic of ours today, cloud migrations and the security challenges therein.
Anton: 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 the cloud as opposed to thinking about on-premise is increasing.
Timothy: Really?
Anton: We're going to have people do cloudy stuff in the cloud rather than just copy VMs. How magical is that?
Timothy: Do you think we're helping? Do you think our show is helping people think with cloud?
Anton: I suspect so, yes, because I feel like our constant jabs at the lift and shifters and constant pointers that these are some of the verse security mistakes you can make is when you copy on-premise technologies, on-premise ideas, on-premise practices, on-premise mistakes to the cloud, that's where the bad stuff happens.
Timothy: 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.
Anton: That should seem like it is.*
Timothy: And with that listeners, I am delighted to introduce today's guests. We're joined today by Brandie Anderson, a global security practice lead here at Google Cloud and Renzo Cuadros, a regional security practice lead also at Google Cloud. Renzo, I want to kick it off with you today. I want to story about some of the big hits or near misses in your cloud migrations from a security standpoint.
Renzo: So we have an interesting kind of task over here with the group I'm on. It's a combination of helping people move securely into the cloud and helping them get onto Google and understand how to use this more effectively. So we have this twin thing of, 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 the next couple of months." It's a high-stress process for them. What we do is we lay it out. We say, "Hey, look, this is it. We can do a couple of months. You follow a process. You have to work with us."
And then once we start doing that and we get them to understand like, "Hey, there's a process or a method to the madness." And we say, "Here's what's going to happen. Here are the questions you're going to have at each point." And we show them that we have control of this process. It makes things a lot easier for them. So that puts them at ease up 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 shift your thinking from your traditional on-premise mindset around security into how that changes in the cloud. So for us, usually what works really well for us is when we're starting off and we're getting into understanding the cloud, we want them in the same language as us and understand our thinking.
Honestly, one of the best things I've found is we have a white paper or a document called best practices around enterprise architecture, by far our best documentation around how to build an enterprise environment in the cloud. So if you start from there, It just walks you through the whole process of why you start with hierarchy or policies, IDM, 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 two different things. First of all, if you're going to build an environment in the cloud, people are going to be a little curious about it. So you're going to want to point and say, "Hey, there is a structure to how you secure it." The two places we point them to, depending on the type of company, is our security blueprints, so that well now there are definitely security page. Or the other, what we say is, "Read that 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, [inaudible] 800-53, CSF. All of those are great ways to get that initial footprint to get them going.
The other big ones we've noticed is this, once we get them building and we build things out, people get really, really excited about cloud and they start getting in there really fast. You get that excitement and people are like, "Hey, I want to get something spun up in Kubernetes. Or I want to spend something in GCE and I want to tie it into Big Query, or I want to tie it into our AIML products." And people get really excited, jumping really fast.
What we've noticed is three years ago, four years when we started, we'd say, "Hey, you have to wait a few months until we get there." And that would drive people nuts because this is cloud. You can spin it up and have a public IP on something under a minute.
Timothy: Yeah, I've done that. And if you're not careful and have something vulnerable in that public IP, you can get honed in a minute too. It's awesome.
Renzo: There you go. That's why it's people's risky part. So the change now is you get on, we [inaudible] the whole process and as we're building out your entire environment, we will stand up a sandbox inviting and we'll secure it right off the bat. Instead of having to wait a few months, now you're up. And three 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 they see that you're letting people play in the environment, get them excited. And you're using an IDM. You're using our VPC service controls, our firewalls, our logging monitoring, our security command centers.
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 are excited. And the really cool thing is they haven't even noticed that we've secured the entire 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. And that's just such a quick way for--usually the cloud sponsor and other people are like, "Oh wow, they got into the cloud three weeks in, they're playing with something. They're building the environment in parallel." It's just really awesome stuff.
Timothy: That's awesome.
Anton: So Brandie, anything to add on other lessons from clients?
Brandie: 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 with 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 and 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 attack framework. 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 offer some capture the flags and some things like that.
They give them practical security experience in Google Cloud and how they would use it in their environment, pop subs into whatever their third-party SIM is, 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 expensive at some point. Oh, it can. So we talk about here 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.
Anton: Of course, that's our favorite subject on the podcast, well, one of, and I mean both Tim's and mine naturally. So I want to just 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 [inaudible], with others is that they 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 can do it, Renzo.
Renzo: Here's the great part. If you ask me a few years ago, what kind of problems we're running into, you'd run through 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.
So one of the issues we're still seeing are, [inaudible] an example, things we used to see years ago would be people over-relying on their firewalls and not spending time on INM. INM 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 we're seeing a lot of that.
I want to say some of the things we're 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. INM is still there to help. Coming from an on-prem world, I still like to know where my network connects to the public Internet, so I'd say more control around that.
I want to say those are some of the bigger ones under logging and monitoring.
Also, the part that I really enjoy, Google has your admin accounts. That's all locus there right off the bat. What people fail to turn on are their data access logs. That is a favorite of mine to understand.
Anton: 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, then they can write lots of papers saying, "Hey, please do it. Customers just didn't do it because they are afraid of the volume."
Renzo: You're spot on.
Anton: So I can kind of relate to that.
Renzo: Definitely heard that. And what we've pushed to now, instead of capturing all of it, we basically write filters that say, "Hey, you're going to actually have the data feed and the ones we want you to pull out or anything that's not the approved service account for the approved user." So if you see things of that nature, then capture that log and let us know about it. We're spot on. If you turn it 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 three things that I'm seeing now.
I will say the ones that I'm 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 [inaudible] firewall rules, just like, man, it just helps secure your environment. It's such a massive winsome. I'm excited with the way things are trending.
Anton: Perfect. Brandie, any of your favorite mistakes?
Brandie: I think Renzo 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 they don't know where to go from there. 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.
Anton: Perfect. That does make sense.
Timothy: It's great that we've started talking people out of lift and shift. It's great that people are adopting VPCs as seen and understanding the importance of IM. Do people really understand that their threat models are different in the cloud as well?
Renzo: I'll take that one. I want to say two things. I'm hearing threat models more this year. This is something the last say six months I've been hearing from our clients, "Hey, we'd like to see your threat model." And there's two 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 a part of, it goes with the actionable like, how do I basically educate them on how to use this? So there's a lot of education about 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 you just still taking it from an on-prem native approach?
Anton: Thank you. Let's just 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 about 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 an edit a document to like cloudify. That's roughly the idea.
Renzo: 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 take it and run with it. Those were the exciting ones.
Every here and there, you see that 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." We work with you so you understand why cloud is different, why like INM is king in the cloud, things of that nature. So it's definitely something educational.
Brandie: We've spent a fair amount of time also building out threat modeling around our services. We internally at cloud 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?" 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. So we've given you this basic baseline threat modeling. Now, how does your application plug in and where do we go from there?
Anton: But do they also approach it as changes to priorities as a threat? 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 re-rank the threats they have in mind?
Brandie: I'd say no, but not because we don't have an opinion, but more because it's with each customer. So as we work with each customer, I heard an example the other day of a denial of service attack for services against the 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 patients 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 this conversation.
Timothy: That's so interesting because you think about extortion attacks and 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.
Brandie: Right.
Anton: 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, it's 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 warms question, but just give me some highlights, Renzo and Randie.
Renzo: Actually, I see two things here. So when I hear about this kind of question from clients, they talk about three things. The first one is clients usually start off and say, "Hey, can you tell me about Big Query or whatnot or any point of our project? Can you tell us what complaints do they be? What are they accredited with?" I'm not going to downplay. It's definitely important. We hear that and we have, all of our products are built to a certain standard. We provide that documentation clients start off, 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 building all the proper security controls. An example I give is just because it's a Big Query, the way we built it meets whatever compliance [inaudible] you want goals. If someone goes out and deploy Big Query, it puts very open INM controls or makes the data set available to whomever. Great. If you took something, it could be secure or insecure, or not secure.
So like, what we talk about is when we're building your environment, we're going to take your compliance requirements and we're going to map them to your environment, your services. We're going to show that full traceability. And then here's actually where the exciting part kicks in. As clients get there, 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 going to Terraform it here." And then in order for you to show your auditors or your own internal compliance that you're secure, we're going to do a couple of things. We're going to do some policy-as-code framework at the front. And these would be things like a 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, /24 Subnet, when you go to create a Terraform rule that says that, your policy is going to check that and say, "You know what? This is not in compliance." And it'll block that change alert on it It'll give you some sort of action. That little one additional step, but you now automate what used to be a manual process and you prevent it from occurring, get the clients really excited.
And then later on to keep it going, we'll also build in, we'll use our cloud logging within cloud functions to periodically scan your environment and say, "Hey, you are still in compliance or will you security command center was security health analytics to do the same thing." That starts getting clients really excited to say, not only are we preventing bad changes from getting into the environment, if we do 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've 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 [inaudible] becoming is really excited about it.
Anton: 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?
Brandie: The problem with regulations that all IT folks know is that they're this set of standards and 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, and I was talking to a bank CISO, and I said, "If we came in and talked to you about FFIC 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. I have PCI, I have every privacy regulation. I have--you name a state that has some regulation I have to comply with it."
It's that view that we look at saying, "All right, how can we hit the most with our GCP controls and do the most good?" It's maybe 80% of the compliance requirements and then we just work on the delta. 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.
Anton: 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 that are sometimes conflicting and overlapping requirements, that to me, sounds like the number one challenge. So that makes sense. I wanted to start to close in. And one of the questions I want to ask is a bit more philosophical. Some of the people predict a future where we will stop migrating systems to the cloud, because most of the systems, most of the businesses 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 cloud native in the majority? Is this coming or not?
Brandie: I think as new businesses continue to grow, because we see a lot of digital natives coming out of startups. Then for 10 years, as you said, 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*** companies are looking for.
Anton: 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 two 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 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.
Brandie: I really liked the security SRE book that was released by the internal Google team. It gives a nice view of securing your environment in the cloud.
Anton: Perfect. What about any advice? What's the number one bit of advice to securely migrate to cloud?
Renzo: Whenever you hear secure device, 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? An 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 of 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 policies code like the [inaudible] at super important. But if the content that's being checked, is it really valuable? Then you're not really gaining very much out of it.
Anton: So the advice then is don't always jump to do things faster or is it to balance? How do you structure it?
Renzo: 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. You don't have application security or is it, you have the 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 is built into it." And then their engineers are 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. And 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'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 or like your biggest problem is you're not even implementing the security you have right now." So it's little things like that like, do you have a solution or do you have the proper execution pipeline?
Anton: That does make sense. And I think that it's a perfect ending for the episode. Thank you very much for being here and we very much appreciate your advice, and of course, your time. Thank you, Brandie and Renzo.
Brandie: Thanks, Anton.
Anton: And now we are at time. Thank you very much for listening in 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 @anto_chuvakin and @_TimPeacock. 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.
