EP160 Don't Cloud Your Judgement: Security and Cloud Migration, Again!

Security running. Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here are myself, Tim Peacock, the Senior PM for Threat Detection in Cloud in Chronicle, and Anton Chuvakin, a reformed analyst and senior staff in Google Cloud's Office of the CISO. You can find and subscribe to this podcast wherever you get your podcasts, as well as at our website, cloud.google.com/podcasts. Today was a special episode. It was livestreamed on LinkedIn. And so if you want to catch future LinkedIn livestream episodes, follow our page on LinkedIn. If you enjoy our content and want it delivered to your, uh, podcasting app every Monday, please do hit that subscribe button. You can follow the show, argue with us and the rest of our listeners on our community page as well. Anton, what are we talking about today? We're talking about the essence of cloud security. Uh, I think you and I were battling to see who could ask the most difficult abstract cloud security question possible today.

You know, it makes us sound like we are, what's the polite term for it?

Grilling?

No, no, no. Grilling, yeah. We're not doing detectionist cooking. We are doing more like—

That was a whole different episode.

We are bastards.

No, I wouldn't go that far. I would say that we had a very interesting conversation with a very smart guest. Who left me at times scratching my head thinking, oh God, I have to keep up with this guest now. This is bad.

Yeah, I had the same exact vibe at the very end when I asked the question about the essence of cloud-native security. So it was sort of a— Modularity. It's an example of— You saw that coming. Modularity I did not see coming, but you did see composability, which I think is a close second. But the thing is that it's one of those episodes when we aim really high, but the guest overshoots it.

Yes, yes, which is wonderful.

I'm sorry, but that's what happened.

We got surprised here, listeners. And so join us in our surprise. Let's turn things over to today's guest. We are delighted to be joined today by Merritt Baer, the Lacework Field CISO. We are so happy you joined us. We've been working on putting this episode together for some time. I want to just kick things off. So first question, very high level, what do you think is the best way that organizations can ensure that as they move to cloud, their security posture doesn't get worse, And hopefully improves.

Yeah. Well, thanks for having me. Hi folks, thanks for tuning in. I am Merritt Baer, as mentioned. I'm a field CISO at Lacework and also advise young companies. I am in Miami today, so coming to you from Tequesta, Miccosukee, and Creekland, among others. You know, if it were up to me, I would want folks to move to the cloud for security, but often, obviously, it is the business driving that decision, which makes sense. You know, folks are moving because they wanna be able to do compressed R&D cycles, or because they wanna be able to tolerate, you know, higher volume requests, or they wanna be able to do, you know, whatever their core business is. So, I think security then becomes part of the, okay, we're, you know, the business saying, we're gonna do this migration, get on board. You know, so I do think that it's a conversation. I've, you know, I came from 5 and a half years at AWS in the office of the CISO there as which is, like, their deputy CISO team. And folks are, you know, trying to wrap their heads around security as they do what is really a business transformation. And I think that ideally, so, the short answer is, I absolutely think that moving to cloud gives you security benefits. And some of those are sort of inherited, like the investments that Google and other folks make in their hardware takes a whole, and other things like that, takes a whole category of security stuff that you don't have to worry about. I mean, literally, the premise of cloud is that you're not maintaining those racks, you're not doing the HVAC, and, you know, you don't have to do physical security on your data center anymore.

There's a lot of upside.

It is a laborious investment for the cloud providers that, you know, that they are taking off your plate from logistical but also a security standpoint. But also, and similarly, you're able now to do abstracted computing, right? So, like, Instead of having your— I've seen folks where their asset inventory is, like, a list on a person's desk. And now, I mean, like, you can have that list if you want, but you can also, like, put out API. You can do an EC2 describe call, and now you know which EC2 instances you have. You can build using, you know, the benefits of these abstractions, but you also can validate, can enforce actions. You know, like, if you believe in math, it's a really beautiful way to be able to do security, especially for, you know, folks who, 10 years ago, it might've been someone's job to go around and check whether VMs were plugged in. So, it's a lot of change in what you have to focus on. And I think that's a real benefit from a security perspective.

So, I agree with all of that, but there's a ton of people out there who think that moving to the cloud is super risky. And so, how do we incorporate that perspective?

Where are they coming from? Point a calendar and say that 2012 is over?

No, no, no. We have to meet them where they are. Why are they still thinking that? And how do we help them with it?

I think that, well, first of all, most folks are moving or are in cloud. So, you're just gonna see more security headlines that somehow involve cloud because that's where the action is.

Hmm.

But also, you know, in cloud, it doesn't mean that you don't have to do anything. Obviously, your cloud provider doesn't do everything for you. There's sort of levels of managedness in the level of the management of the service, and there's always some piece of it that's on your side as the user. And I think the, Biggest issue here is just credential compromise. So no matter how good your cloud provider is at building hardware, no matter how good your identity provider is at making sure that, like, you know, you can't just make up a key to get in, like, they're using just regular keys that you, the end user— I mean, not to blame victims here, but like, that you, the end user, are not protecting in meaningful ways.

Now, occasionally, occasionally it is the case that they use the wrong kind of key very sneakily. But we'll leave that aside for now.

You know, there are all sorts of flavors of security, you know, threats. And of course, we see that. And you can also just, like, bring down an enterprise by doing a, you know, denial of service attack or something. You know, like, there's different flavors of security compromises. But generally speaking, the ones that you see most prominently in cloud infrastructure that I think folks are scared of, or, like, they get the sense that they should be scared about security, is in credential management. And it's because folks are just using, you know, the front door. You know, these aren't zero-days.

Totally.

They're using legitimate credentials. And I guess this also speaks to part of that cloudiness of your approach, where it feels uncomfortable if you're not used to having this much data. Like, you might have hundreds of thousands of calls that you're now, you know, they're logged, but how do you know what's anomalous? And of course, like, refining permissions down is, like, an ongoing journey. We talk about least privilege as if it's, like, Some end state, you know, when actually you need stuff to work, stuff has to go through, you know.

But I mean, credentials, of course, come up pretty much in every conversation. So, it's not exactly surprising, but of course, a very, very accurate thing. But are there some things that surprised you in terms of the migration challenges? Like, to me, credentials wouldn't be a surprising security challenge, just the most popular one. But what are some of the migration security Surprises that you've seen? I'm curious.

It's a good question.

Oh, thank you.

Yeah. I think that a lot of it revolves around a willingness to, like, lean into cloudiness. So, when folks, you know, basically, some folks just lift and shift, and that is fine. You know, that is an approach that—

It's fine or fine for now?

Although it is not the one I condone, it is a reasonable approach that some folks take that says, let me just get my stuff over into this new environment, and then I'll re-architect and make it look more cloud-native, or—

Do they ever do that?

You know, it depends. It depends. They should, because from, like, just a cost and usage standpoint, they should. But also just because cloud environments aren't exactly the same. They don't track exactly, even between clouds, let alone from on-prem to cloud.

Can we pick on that for a second?

Yeah.

What are some of the ways that you see that playing out in a bad way for people? What are some of the, like, cross-cloud gotchas that trip people up?

You know, I think, to be honest, small and medium enterprises that have a lot of multi-environment are just doing themselves a disservice, because it's gonna be hard to manage. I mean, just the fact of being in a, you know, 4-spread-out...

Oh, just the 3 environments existing at all is the gotcha.

Yeah.

That's the problem.

Yeah, okay. Because essentially, they're gonna end up playing to the lowest common denominator. They're gonna have a harder time templatizing. When they want to do infrastructure as code, they're gonna have to refactor it every time. Remember that even folks like Terraform, that can be used in different environments, you know, Terraform being an infrastructure as code tool for folks from HashiCorp. But, like, you still have to refactor it because the clouds don't have the same services. They don't have the, you know, like, you have to.

Totally.

And so, as a result, like, your visibility now is all over the place, your ability to put actions on. It's hard enough to do in 1 or 2 environments. And when you're a small enterprise that has a security shop that might be, like, You know, one or a few people, you're now putting a huge toll on your security team. And this happens frequently just because devs kind of run in different directions, or there's M&A that results in different pieces. So, I'm empathetic to it, but it is, I think it's, folks waste all these cycles just trying to get their arms around it and not actually making it run like a well-oiled machine. Yeah.

And by the way, I was about to make some kind of snide remark is that—

Never.

Meredith sounds like she works for Amazon, but it's actually very good advice Wherever you work. It's almost like, no, well, first thing, it doesn't work for Amazon yet, but—

Yeah. Oh, I don't care which cloud you pick. They're all reasonably good.

They're all reasonably good. That's the nicest thing I've heard said about clouds in a while.

Aww.

They're all reasonably good and definitely better than your on-prem. There will always be limitations, or at least for the foreseeable future, there will be limitations to what you can put in the cloud because there are some OT systems and other things that you can't. So, many folks are gonna be multi-environment for the foreseeable future. But for what you can put into the cloud, if you can streamline it to, you know, one or at most 2 clouds and not just have things all over the place, you'll get better bang for your buck from a pricing perspective. But you'll also just, your engineers will understand it better. As a security team, you'll know when to, like, your trouble ticketing system will be much more seamless with, like, what prompts a trouble ticket. Sophisticated security teams, like, still work at this stuff, but at least, like, you've got those... muscle groups in place, you're not just, like, herding proverbial cats all the time.

I think that the other thing you said about lowest common denominator rings really true for me. I see teams, oh, we wanna be multi-cloud, we have to only use infrastructure, we can't use the services, we have to run instances that run SQL, we can't use Cloud SQL.

And that deprives people of so much benefit of cloud. That's a scary security counter-correlation.

It is, it is, it is. And it then forces other bad things, like instead of using cloud-native detection, I'm gonna deploy an IDS because I can run the same IDS everywhere. That's such a good observation that the multi-cloud gotcha is being multi-cloud at all in many cases.

Yeah, essentially. And especially for folks who don't have the resources to do a lot of, you know, sophisticated correlation between them. But I also just think that generally speaking, even if you are a sophisticated shop and you have the resources to do it, over time, it benefits you if you can get into one or, or at most 2 clouds so that you just can focus on refining those muscle groups. You'll still get to the point, you know, like, are your trouble tickets getting increasingly resolved by robots? It's something that folks still work at, even in sophisticated jobs, but it's gonna be a whole lot easier if you're seeing behavior, like, if you're able to write those automations for, you know, one or maybe 2 environments. And even better, as you point out, Tim, if you can be using managed services where... Your cloud provider is going up those layers of the stack for you. You know, like, you're not having to do all of the managedness of it, which is just more— it's more work, and it's more, like, undifferentiated work. It's not—

Undifferentiated work.

It's not the fun, interesting stuff that your enterprise cares about. You know, it's not the pharma part of pharma, or the retail part of retail. It's just, like, the manual stuff that you're trying to get away from.

So, this makes sense. And I think I still wanna go back to the depressing take of people who lift and shift. kind of blindly. So, occasionally, I do see security leaders who kind of Ctrl+C, Ctrl+V all the controls they have on-premise, kind of copy the controls to the cloud. And while we always tell them, yeah, that's fine, as long as you evolve from that. But, like, what's, you know, Merit's best advice for people who pretty much just insist on copying everything they have in data centers, stacks, technology, decisions, practices? to the cloud? Like, what do you tell them?

Wait, can I give my advice first?

Yeah.

No.

Oh.

She's a guest.

Oh, sorry. You're the guest.

No, do it.

Please go first.

Go, go.

Okay. Now she wants to do it.

Oh, my advice would be retire, but I'm curious what yours is.

Yeah, I guess, well, I was gonna say something to the effect of, like, I would ask who's driving that decision, right? And then what do they care about? So, if it's your CIO, what is it about that plan that they are attached to? Is it just the idea that they've told the board that they're gonna be in cloud next year?

So, therapy. She recommended therapy, which is good.

That's my— I often recommend that too.

Sometimes. I do too, unrelatedly, but, or maybe relatedly, but—

2024.

You know, there you go. Happy New Year, everyone. Yeah, like, who's driving that decision? And if it is your security shop, like, you should question yourselves. But often, it's a different part of the business that has said, like, well, we made a promise that we were gonna move, and then, you know, the next year. And so, we're just gonna do it this way because it's faster. In which case, you now know how to push back on that because you can say, for folks in the business, you can say, it's gonna make it more expensive, because it will. If you haven't made things more cloud-native, you're going to be clunkier, you're gonna be, you know, you won't have right-sized things, but you also won't have the flexibility of a lot of the native capabilities to do security as, like, just part of what you're seeing when you're in cloud, or templatization as part of just how you create new, you know, Bending new environments rather than having them, like, stamped by your previous.

So, I want to pick on that, actually. I think that's a great segue into the next thing I want to talk about, which is how do we help teams, engineering teams, security teams, compliance teams, this kind of triad, work together on landing zones and blueprints and doing it right from the start, rather than trying to have engineers run ahead, screw it up, get cleaned up, have to fix bugs? How do we shift left in this area?

That's a hard question, Tim, though.

She's a good guest.

Yes, she is good.

Well, thanks. I'll try to hold the mantle up here. Yeah, I think your question even, like, belies a first belief, which is true, which is that you should be templatizing. Like, take advantage of the ephemerality and the mutability of cloud. You know, like, you should have forced escalations, you should have forced lifecycle policies, you should have— and that just makes it so that good intentions are not what you're relying on as a team. But for the devs, actually having an overarching governance that is not just, like, on the boss's wall, but is actually enforced through your policies, you know, like, that is reflected in the technical ways that you've implemented your identity permissions and other things, allows you— and of course, you can do this in cloud in increasingly kind of managed and seamless ways. But doing those as just, like, how you do business actually does make your devs happier because they get to just, like, bend themselves new environments without having to either go off the rails and risk you killing it because they've made some non-acceptable environment that they're playing in, or without having to, like, even build it themselves. They can just say, you can say, like, you know, these are what we think R&D teams will need access to and the kinds of environments that they might wanna play around in and the ability, like, it's such a— luxury for devs to also get, you know, R&D in a way that is both cheap and, I mean, like, cheap literally, and also cheap energy-wise, that they can just have playgrounds. So, I think, but doing that, like, to be able to do that from a security perspective, you have to be doing these in automated ways, vending environments for them, and vending identities that are associated with those environments. And then you can kill them, right? But of course, like, your web server gets popped and you kill it and spin up a new one, you haven't solved your problem. So, like, the way that you are vending these environments themselves is related but different from the ways that you'll embrace ephemerality as just, like, part of how you do business in the cloud as a security team.

You're giving me major Sunil Yu vibes right now.

Yeah, the ephemerality argument is definitely— I was just about to add his episode to the resources. Yeah, because of that exact comment. So, Tim is trying to mind-read me and I'm trying to mind-read him, I guess. So, let me— this actually, I think she gave a really good answer to this really tough question. Like, I mean it, like, in the sense that—

I agree.

Yeah.

I mean, it's a great answer.

Yeah.

So, let me try something more philosophical. And I think that it's something that I've dealt with this. It's almost like I'm trying to outsource my job to Mary. That's a bad idea.

That's a bad idea.

Yeah, it's a bad idea. Okay. Okay. So, the setup is like this. We do occasionally get people who practice lift and shift, and we tell them, yeah, okay, fine. It's a choice, but like, don't do it. And we tell them, you should practice a more cloud-native approach to security. To which some of those security leaders look back at us and say, how? And I realized that I don't have a crisp answer to what is the essence, what is the DNA for a cloud-native approach to security. Sure, you can say automation, using APIs, using cloud-native services, but it all feels kind of not quite it. So, maybe if somebody wakes you up at 3 AM and says—

It's the 3 AM test, listeners. We get it.

Meredith, what's the essence of cloud-native approach to security? What would you say? Okay, 3 AM was not unnecessary. It was unnecessary here. You're right.

I think it is related to what we've been talking about today with the infrastructure as code and ephemerality. I also think it is basically the modularization of building.

Oh.

So, and we see this with, you know, so as you modularize your code libraries, and you're checking in and out, and you're able to, you know, like, we also see this with security work tracking along with it. And so, for every shift-left effort that you have that's doing infrastructure as code and inspecting that code, you also have a shift-right that's like, stuff is gonna happen. And now you need to be able to do threat detection, but, like, at the API level, or at the, you know, like, these are, you're getting into the world of abstractions. And so, what you're going to be interacting with are sets of other abstractions. And I think that ultimately, you know, some of those happen at different layers. You know, some of these will be looking at whether this call is authorized, some of these will be... looking at traffic at the edge or other things, but some of them will be getting into the content of what you're building throughout the code. So, I think there's, basically, I think it's that luxury and, like, the beauty and the horror of abstraction. I think that's the, at least to me, that's the distinction.

That's a very interesting thought-provoking answer.

I'm actually getting a Phil Venables vibe in this. Because Phil likes to highlight the abstraction machine nature of cloud, as an argument for cloud being more secure. So, that's actually really good. I think that it is not something where my mind would go, like modularization, but I think it's a hugely useful direction. I think that ultimately, you can't automate until you modularize and do abstractions. Automation would be snowflake automation, wouldn't work.

As you mentioned, this is on some level philosophical, but on others, literal, you know, like, which I think brings us back, like, even I'm gonna go back to the godmother of computing, Ada Lovelace, who was one of the first few who said, like, computers aren't just, like, giant calculators.

Mm-hmm.

There can be, you know, reasoning. There can be— and of course, she was Lord Byron's daughter, so a poet's daughter. You know what I mean? Like, there are ways in which you can conceptualize and also reimagine what computers can process. And then, on the other hand, they're only gonna do— execute on commands that humans write. So, I think it's, again, it's like this really fine-edged sword of the power that's there, and then also the limitations, or at least the dangers of, once you get into that world, doesn't mean that you don't have to put the work in. The work will just look different.

Listeners, I did not expect an episode today to touch on Ada Lovelace, Lord Byron, and modularity and composability as the hallmarks of software engineering.

She did not say composability.

I added that one.

Oh, okay, fine.

I like it.

I wanna ask one more question before we wrap up, because this is, like, a lot happening in my brain right now. How do we help people scale this? Because what you're describing is hard.

But it's automatically scalable because it's done in a cloud-native way, dude.

Is that right?

Yeah. The beauty of it is actually, I mean, of course, it's easier for me to say sitting here than it is, you know, like, in practice, it takes work to get your mechanisms in place. But once you have them in place, there is an element of scalability that comes with all of this. If you are, you know, doing infrastructure as code, and you're vending environments, and you're, you know, pruning your permissions. You can be using cloud-native tooling, you can be using other tools. You know, Lacework does an infrastructure as code alert and, like, attack path analysis that says, this looks overprovisioned. Like, the beauty of having these permissions be something that you can reason about is that, and I mean that in the, like, formal reasoning sense, is that you can also prune them down. So, this, Gives you an ability to then, rather than each time an employee comes in, you, like, ask them what they would like access to, and you give them— it's like, you delegate the ability for them to vend the apps that make sense for their role, you prune those. There are ways that folks take the templatization that kind of comes with that, but also turn it into a security mechanism, because if you see someone— Or some team running into guardrails all the time, either you have, you know, made those guardrails too tight, or they're going off the rails. You know, there's a lot of ways in which you're getting information too, by giving folks the freedom to, like, making those paved roads is hard, but it also makes the secure thing to do the easy thing to do.

Don't we have the well-lighted path, and she has paved roads? I kind of like the I actually like hers better. I think the paved road is better than a well-lighted path.

That was—

you can still trip and fall on a well-lighted path.

I don't know. I think, I think those are evolutions. I think those are evolutions. You start out with a path and then it's lit and then it's paved.

When you're paving the road, it's a bit of work.

Oh yeah.

But then all of a sudden everyone can go faster and at some point it'll degrade and you need to like, or you should question whether that's the right road. Like you'll still do continuous improvements on these. There's always new services coming up, but there also may be other approaches. One of the beauties of cloud is that, like, every time that you get cloud geeks together in a room, they'll be like, so, what are you doing for whatever it is? And people have different— and sometimes they'll say, yeah, yeah, I'm doing that too. And other times they'll say, really? So, for your infrastructure as code, like, protections, you're using, you know, and it's— or your, you know, IoT, you, you know, are using these sensors in your factory to be able to take quick pictures and not have human oversight. Like, both things use cases in the real world and on the infrastructure side are constantly, like, there's no right— well, there are more right ways to do it, but there's no, like—

Yeah, more right ways to do it.

No one road to get there. There's, you know, many. So, it's also a really creative field. And I think it, like I said, ultimately, I don't know how many shops move to cloud for security, even though I wish they would. But one of the beauties of having the secure thing be something they can have confidence in, is that now they get to take it to their business and say, look how much more you can do.

Merritt, I hate to do it, I have to ask our closing questions.

Okay.

One, do you have a tip to help people improve their cloud security, which I think we've talked about 20? And 2, do you have recommended reading, other than maybe Lord Byron?

No personal attachment, although a big fan of poetry. Tip, I would say, for folks who are at the enterprise level, make sure that you have some way that you can alert on credential compromise. We're seeing this with social engineering. We're seeing it with credentials getting compromised in technical ways. But just, like, remember that the front door is usually where they're coming in. You can have all the alarming you want on the windows, and folks do. And those can be really powerful attacks because they resemble normal behavior. And of course, like, no one wants to get ransomwared. It happens because it's hard to defend, you know? But at the end of the day, like, getting your house in order is the best way to do it. And it's One of the best bangs for your buck is credential management, and on the individual layer, you know, MFA and password managers. I am a big podcast person, and I've been listening to Jack Reisheiter's Darknet Diaries lately. So, that's a fun one for folks in industry. I'm also big into Serial and some of the, like, sort of storytelling around common things that we see in the world that That make sense but don't make sense. So anyway.

Well, Merritt, I think with that, a mind at peace with all below, a heart whose love is innocent, I think we have to wrap things up today. And Anton and I will figure out, listeners, how to get all of the technology problems working a little bit better next time.

All good.

Thanks, Merritt.

Thanks. And thanks for having me.

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, or wherever else 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, twitter.com/cloudsecpodcast. Your hosts are also on Twitter @anton_chuvakin and _timpeagle. 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.