EP72 What Does Good Detection and Response Look Like in the Cloud? Insights from Expel MDR

Security warning.

Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here are Tim Peacock, the product manager for threat detection here in Cloud, and myself, Anton Chuvakin, a reformed— mind you, reformed— analyst and member of Cloud Security team here at Google. You can find and subscribe to this podcast wherever podcasts are sold and distributed, As well as on our website, cloud.withgoogle.com/cloudsecurity/podcast. If you enjoy our content and want it delivered to you piping hot every Monday, please subscribe using your favorite app. You can follow the show and argue with us on Twitter, twitter.com/cloudsecpodcast. So the episode today is going to be really fun because it's for the topic that I never quite figured out while at Gartner, namely, if I am a heavy cloud user, maybe I'm cloud native, maybe I'm fully migrated, And I want to get some help with security. I want to get an MSSP or an MDR. How do I go and find an MSSP or an MDR who actually gets cloud? The answer is very hard.

Ah, see, that's the critical part because you can just find one using Google or your other favorite search engine. The question we address is, how do you find a good one?

Yes. How do you find a good one that actually gets cloud? Because you may find somebody who's good with your old environment, but can they really spell GCP? Like, do they know cloud? Do they know what's a— function or—

What's a Pub/Sub?

Yeah, what's a Pub/Sub? Or how to deal with APIs or what's Cloud Audit Trail from whatever provider? And so to me, this is peculiar because even the intricacies of, say, identity management would affect your SOC operation quite a bit. So if you want a good MDR for your cloud environment, that's a really hard challenge.

I agree. And what I love about this episode is that they have the problem that I have in my day-to-day life outside of the podcast, which is, Cloud detection, and then they have a whole nother problem, which is cloud response. So I really enjoyed this conversation and felt sort of kindred spirits in these guys that I don't always feel in our guests. And so perhaps with that feeling of really delighted to see my own problems in other people, let's welcome today's guests. We are joined today by David Merkle, the CEO at Expel, and Peter Silverman, the CTO at Expel. So we've got a whole C-suite in the building today. Today's episode, super fun talking about MDR. I see a lot of MDR providers who claim to be, you know, security from the cloud or a cloud SOC, but they don't actually know a whole lot about cloud security. So what does good look like for an MDR securing a cloud rather than securing, say, from a cloud? And, you know, let's consider the whole cloud range from IaaS to SaaS.

Sure. Pete's the brains of this operation, but probably the first thing is, are they actually a cloud-native business? Like, how can you actually be any good at this if that's not where you were born. And so that's an interesting sort of simple, simple enough a CEO could ask the question and understand the answer. Your kind of litmus test is, are they cloud native? Are they SaaS first? Or is it something different? Pete, you've probably got a lot of other thoughts on this.

Yeah, I think to amplify what Murk was saying, the kind of look and feel of a company tells you a lot about them. When you think about look and you think about cloud, you You'd expect like a status page. What's their uptime? Just basic things that you'd expect from any cloud vendor. You'd want to see that with someone who's understanding cloud. API documentation, that's again a look, right? Like, hey, are they available? What happens when you Google that type of stuff? Those are really important, I think, to just get a sense of the look. When you think about like, what does it mean to like operate as a cloud company? Well, like, are they in the cloud? As Murk said, like, that's a decent question. What are you running in the cloud? What other cloud applications are you as the provider using to enable your service? That might be on like a data subprocessor page, things like that. It just all goes to kind of helping understand what they know about the cloud, because there are some differences, I think, as we talk today that we'll hammer on and discuss. And I think the last one is kind of how they communicate about the cloud. The cloud is awesome because of the optionality, the configuration, the extensibility, the integrations, all those things that you can use. And you want to know that the provider you're using understands that because there's some implications there. There's a need to personalize response or detection or things like that based on the choices you as a customer or prospect has made. And you want to hear that your provider understands those because they're going through some of those challenges themselves, setting things up, setting integrations. You really want to make sure that when you think about those things, you want to hear that in what you're talking about. Everything from how you onboard, are there options to onboard, like different ways to onboard, to start with the provider, to the ways they do detections, the types of detections. That's all the kind of optionality configuration you're going to want to look for when you think about someone who really understands the cloud.

So it's interesting, like, to quickly interject, I wanted to say that it sounds like there are almost like these little signs that indicate that you kind of get cloud that maybe other people can see. Like, for example, public standard documentation, sure, everybody can do it. But cloud-native businesses tend to do it by default as part of their DNA, and others have to kind of think about it, like, did we ever document it and do it? So it's almost like there are little subtle clues that you have to be able to see, like, hey, you sound like a cloud-native business, you get cloud. Am I overthinking it or underthinking it?

That sounds right. The thing to watch for is that sense of a veneer. If it only goes just a little bit deep, and then all of a sudden, some stuff, if you poke hard enough, doesn't align and doesn't make any sense. I thought of another interesting litmus test question. If they are truly a cloud-native business and they are a cloud MDR provider, do they use themselves to protect themselves? Would be an interesting conversation to get into. And if you got into that, I think, Anton, to your point, that would be a way to get pretty deep pretty fast in the conversation, and you would be able to find that misalignment. You'd crack the veneer pretty quickly. if in fact they are not truly born in the cloud, understand it, and understand what it means to try and provide effective security operations in that environment.

So this reminds me, during my analyst days, a lot of clients would call us and say, we do want the MDR to cover our on-premise, our cloud. And it was really difficult for clients to kind of understand this. Now we are discussing some of the clues, but what are the challenges for clients picking an MDR for their cloud? I've met, for example, one organization that basically always picked whatever current MDR they had, and they had a lot of challenges because, sure, you would have the unified provider for cloud and on-prem, but what if their expertise is mostly about securing a data center or securing DMZ? How can you trust them in the cloud? So what are the questions clients can ask to figure out the right MDR for their cloud environments? What are the key challenges here?

Anton, the first thing I'd just call out is one of the challenges is just how many people have done full response in the cloud? Because when you're responding to cloud, if you start with an infrastructure as a service provider and you get an alert and then you work backward to root cause to really understand how it happens so that you can kind of mitigate all risk, it usually has you navigating across multiple cloud estates, possibly back to on-prem. And the number of people who've done that is pretty limited, whereas the number of people who may have responded to an on-prem incident is much larger at this point in security, which is totally fine. I think that creates this challenge of what questions do you ask, how do you evaluate? And I think one of the things I'd call out is, if you're asking questions based on on-prem past experience and getting on-prem answers, that's a shift-and-lift cloud MDR provider. And you'll probably want to do some of your own research to educate yourself on the types of things to ask before you go in. And that's, I think, one of the things we can help with here, just questions you could ask, right? Does the vendor monitor themselves is a great question. I hadn't thought of that one. I like that one. But some of the other things I think to think about are like, where does the provider's work stop and where does the customer's work begin? And if the answer is no, that means they're either going to run everything to ground, which means there's a set of alerts, classes of alerts, classes of detection and response they're not going to do because they're more risk-based. They require investigation, and they may require engaging the customer to understand, hey, do you have users in the area? You do? Okay, this activity's normal. We won't report it again.

Right.

You don't? Oh, it's an incident. There's an engagement model that has to exist with the cloud. And if you ask a question like, hey, where does your work stop and where does mine as the customer begin? That's a great question. How they see the differences between investigation on-prem versus cloud is another one that you want to look at that's going to pull off that veneer a little bit. What staff you have to have on hand. You're going with a vendor. Are they going to do everything? Or I think one of the things you can look out for is a lot of cloud MDR providers may not do full remediation in cloud infrastructure because you can take out production infrastructure if you go ahead and start nuking boxes, isolating, what have you. How do they talk about that? What are you hearing? Do they understand the risks there? Do they have optionality? configurability in what they do. Those are all really good indicators that they are thinking about the differences of the cloud. And then knowing just basic stuff like how will you measure success with the cloud provider versus on-prem? Because I think there are different metrics you may use, especially if you don't have the visibility in the cloud, you may be starting further behind. And that's totally okay. But I think it's important to set the table so that you can kind of grow with the provider.

But wait, by the way, your point, yeah, I want to kind of— these are hugely useful, at least to me. I almost see like Gartner should have written a paper on this at some point. But I I sense that you mentioned one thing. Who does what? Your stuff or their stuff? But it's a 3-party conversation, though. What does the client do? What does the MDR do? What does the CSP do? Tim is waving his finger, wagging maybe. I don't know. Wagging sounds like a tail, right?

I'm agreeing. It's a very agreeing finger.

This has been bugging me quite a bit because people don't get a 2-party shared responsibility model sometimes. But here, we have a very crisp 3-party. Yeah.

And there's often misconceptions because there is a third party and an overestimation of what the cloud platform provider actually brings to the table, and not realizing that, cool, you know, you're not running data centers, you're not worried about physical security, you're not worried about ID checks at the turnstile to get into the data center, but you do own everything from, if we're talking virtual machines, operating system on up, or however you've implemented application-level stuff, like, that's all your problem. And so that's probably the most common misconception we'll run into even today. It's 2022. I mean, hello. But yeah, we'll still get a little bit of that confusion. And I think teasing that out is actually important in the conversation. And to the point of the question that got us here, which is, okay, well, what do you look for in a potential partner provider? One that actually understands it's a 3-party conversation, not a 2-party conversation to start with. That would be another one of those simple enough a CEO can understand it litmus test questions to tell you, okay, do these people actually know what the heck they're talking about?

And for CEOs listening to this, it was the CEO who was ripping on CEOs, just to be clear.

Yes, that's correct.

Although there's like kind of another party involved, so I don't want to throw a wrench in the—

A 4th? The attacker?

No, I mean, they're in there, but I think about the stakeholders, right? Especially in the cloud, security is working on behalf of a set of stakeholders to enable the business. And, you know, previously on-prem, you'd have an EDR, you could push policy, you could push a lot of things through that. And with the cloud, you may be working with IT or an IAM team that is managing policy and access. You may be working with engineering or DevOps or SRE. There's a set of stakeholders you have to engage in making sure that you have a provider who's going to set you up for success to engage those teams with details and conversations and observations.

Mm-hmm.

So you can go in and learn so that if you think about the security function as, hey, maybe there's something happening that you didn't know about, it's activity that's risky, but there's a reason it's happening, that's kind of like debt, tech debt if you will, and you want to think about how to enable them to change that behavior. It might be a budget conversation you needed to have, but you know you can't have it for a couple months, so you can go get technology to help with like on-demand temporal access to instances or something so you stop breaking glass and logging without MFA or something. That's okay. Accepting and understanding and knowing where your risks are are great, and having a provider that can amplify signal in areas of risk, especially in the cloud, and then as you mature as the customer, change that and adapt and also provide you the data and the observations so that you can help the company understand why a change has to occur and help the company adopt that change. I think that's a pretty big difference in the cloud, and it's a 4th stakeholder or participant in the conversation. And I think it gets left out. It's kind of like, hey, security team, go deal with this now. And when you think about customers wanting to get better, they can only get better if they can enable the rest of the organizations around them. And I think security can play a role in that, but they have to kind of embrace and be intentional about playing that role.

I think that's a really good nuanced understanding of how organizations actually operate in the cloud. And that level of nuance is probably what you want to look for in your MSSP or MDR for cloud. So we've probably highlighted a lot of things you could look for. I'm curious to kind of pick at when it comes to MDR and cloud, do people want the same security outcomes? We released an episode just today, actually, So listeners can work out what our latency is on recording to release based on this comment. But we released an episode today talking about how distributed, immutable, and ephemeral changes some of your security needs in cloud. So do people want the same security outcomes in cloud? Does that shift? What changes there?

Yeah, one thing I know that is a little different— well, I say a little different, on-prem attitudes on this are changing as well— but in a cloud environment, your infrastructure is cattle, not pets. Unless you've done lift and shift and it's really just a bunch of VMs in the cloud that you named all the same thing, then they are your pets. But more often than that, we see it's cattle, not pets. And so, the tolerance or willingness to explore things like automated rapid remediation, things of that nature, I think there's a greater tolerance there. So, hey, get me to still operating much faster, just handle it, is, I think, we've seen customers go much faster there. Now, I made the comment on-prem, we see it too. In the age of ransomware, we see increased appetites for that same kind of behavior on-prem, but I think just the time for the market to evolve to, yeah, just handle it has been much faster for cloud-based assets. Pete, I know you've got a bunch of others too that you see on a regular basis.

I think at a high level, customers do want the same things. They want to know about what matters in their environment. It doesn't matter where in their environment they want to know. And I think matters is a key word because it's not like it's broader than the threaty threats. It's risky behaviors, activity that puts the customer at risk that they didn't know about. So they want to know what matters and they want to get measurably better over time. They want to be having conversations about how they can improve, which is kind of like we've been talking about for a while, but they want it and they still want it. And it's on providers, I think, to move more towards helping them get there with that data and those conversations. I think one of the interesting places with cloud is there's a lot of opportunity to learn from others and enable best practices. On-prem has been around for a lot more. There's a lot more scale of knowledge on best practices when it comes to on-prem and management there. And I think cloud is still growing and there's new vendors and new SaaS applications and new ways to do infrastructure. But there's a lot of opportunity to learn about best practices. And I think if I had to pick where I think they break a little bit, it's there because it's still new enough where not everyone knows, not everyone has that experience and expertise. And I think that's an area where security can help.

So basically, at some level, outcomes are the same. But if you dwell into the details and you start to slice a little bit into the operational practices and what the outcome even looks like, hey, detecting threats. Yeah, I want threats detected. Sure, I want them handled. But like what it means in the cloud is different, but this high-level position is kind of the same. That's roughly what I'm hearing. And does it mean that the capabilities an MDR should have are different? So what I'm thinking is, are we talking about the same tech stack for cloud DNR or a different tech technology stack? What about other capabilities to have good coverage of the cloud? Are we more in the different or are we more in the same territory or some nuanced mixture of both?

I think because the outcomes are similar, a lot of the capabilities end up being the same, but there are differences. And I think the differences fall out in the kind of questions in some of the earlier conversation. You do need the ability to really understand. You need ingest signal, do some stuff with the signal, produce things to go look at, and then have a response plan or like a platform to do response. The response in the cloud is harder, in my opinion, because it's just less well understood. I think one of the interesting things that also comes out as a capability is, Hmm. It's not enough to just regex or string search a CloudTrail event looking for a thing. You really want to understand what it means in the context of the environment or what an event means in the context of O365, because certain events indicate certain things, and then in combination or in sequence, they mean a whole lot of activity or risk potentially. And so there's definitely a capability, and it's maybe less tech than it is a mindset shift. But it's definitely tech research or skill experience, all those things rolled up, that is understanding the semantics of the application. And there's a lot of nuance between just the 3 major cloud providers in what their logs mean that you really need to understand. You can't just take one and apply it to the other necessarily.

You know what I call that? I call that the Anna Karenina principle of clouds, because that book opens with, all happy families are alike, all unhappy families are different in their own different way. Every cloud is different in its own different way.

Yes, I will definitely agree with that. And every application is very different in its very different ways. So it's quite a thing. I think, Anton, to bring it back, there's a lot of similarities in the capabilities because we believe the outcomes are the same, but how you go about getting to the outcomes is a little different. And so the capabilities end up having some nuance in what they require. And a lot of it comes back to like what you're looking for, how you're talking to the customer, where the work starts and stops, how you enable analysts. That's where you'll see some of the differences in technology.

Yeah. The biggest difference I see is you're just not going to see the same stack of third-party security products.

Why not though? People do come with their freaking IDSs in the cloud, freaking firewall appliances. Come on.

Virtual physical firewall appliances.

Virtual physical firewall appliances.

Yeah.

It sounds so sad. It is.

It happens, but not if you've got a cloud MDR provider that's relying on those things, you're probably in a little bit of trouble.

Understatement.

The depth of knowledge you need to have of the actual control plane, which is probably the first place to start monitoring and paying attention to things, has gotta be pretty deep to be effective. And also, you have to bring— because, I mean, all props to the major cloud platform providers, but when you're transacting on the stuff that they generate, you're transacting on events, not really alerts. Like, the richness of a cloud platform event does not rise to the level of, say, a CrowdStrike alert. It just doesn't. So, there's that Deeper understanding is key to being able to actually formulate an effective detection strategy on top of, pick your platform. And I think we'll go all the way back to the beginning that got us started in the conversation. That's why poking at the provider to find the depth in the knowledge is necessary, because it's that depth of knowledge that will actually lead to an effective strategy applied to your environment.

Okay. So I want to pick at something here, which is the cloud layer detection, because you're getting at this with talking about the different cloud application logs and the cloud provider detections. How do you talk to your clients about that? How do you tell a client, hey, listen, buddy, you don't just need protection for your VMs, you need protection for your cloud as a cloud? How do you describe that to people?

Just to make sure I'm tracking the question so that I answer it directly, is basically how do we talk about the importance of monitoring not just the running of what's happening inside the environment, but also the changes and all the things we see around?

Yeah.

So a lot of the conversation comes to at this point when you think about privilege escalation or any of the A lot of the techniques that you would see on-prem, they manifest themselves in the control plane as well. An attacker bouncing around trying to guess what permissions they have because they took over an EC2 instance and are trying to figure out what credentials granted them is going to create a lot of noise, and that noise is really evident sequences of denies in the CloudTrail. That's where you can pick it up quickly. The other thing is a significant chunk of customers we interact with don't have or have decided to not deploy EDR to everything in the cloud.

Why is that?

Late performance concerns, customers with performance concerns around the CPU cycle times, things like that. Some of it is risk in, hey, this is a revenue-generating environment and sometimes these things crash. The software can cause crashes and sometimes it's invasive.

It can.

And so for all those reasons, they're making choices around their security profile. Another reason is organizational structure. It could be the team can't convince the engineering team or the SRE team to deploy it without having to do a bunch of acceptance testing, which might be the right thing to do, but might take cycles away from the security team. So they're like, Hey, we need another option. And a very good, a great option in our opinion, and I think in a lot of people's opinion, is the richness and the completeness of the control plane that the cloud provides you. You have very similar analogies to what you would get in some cases from telemetry from endpoint or other more traditional security software. And so when you combine the two, you're in a great place, but you can be in a great place from a security posture perspective with a lot of prevention and monitoring of the control plane.

Peter, what I love about that answer is that it not only mirrors in content, but also in structure, a slide that I have in a deck I use when presenting my agentless approach to runtime security with something we call Virtual Machine Threat Detection. I don't know if you guys saw what we launched there, but what you described about agents, exactly what I tell customers. It's cool to see like the same, it's there.

Yeah. And it's, I think it's, I think customers that don't have agents will likely deploy them over time, but they also want to be secure now and rest easy. And I think that this is a really Good frictionless way. And again, we think about at XSOAR, we think about enabling our customers' security teams to enable their stakeholders. We talk about that. We want them to go talk to engineering about deploying that. We want to understand what the challenges are so we can help, because the more security signal we get, the better we'll be at protecting them and the better they'll feel about their security posture overall. So it's a place a lot of people want to go, but it's often they start with the control plane because it's there. It's something they can access with minimal privileges. They can provide us access in a secure way to that data stream. We can do a lot with it. It's highly rich, it's consistent. It's all the things that sometimes other sources might not be.

See, I agree with all of that.

It's also very cloudy.

It is very cloudy.

I agree with all of that except the assertion that people are going to move to agents over time. I think people are going to move away from agents over time and cloud 10 years from now will be like, agents?

What was that?

Yeah, but wait, wait, wait. This is a separate episode which we're going to record.

This is a totally separate episode. We're going down a bad path.

But I wanted to have a quick but harsh comment about agents that sort of like, I guess, argues with both of your positions.

Are you going to beat a weakened horse?

I think agents imply that cloud is just a bunch of VMs.

Yes.

So to me, it sounds like agents already implies your cloud is a bunch of VMs, which means you lift and shift it, which means you live in the past.

You don't necessarily have to lift and shift to end up with a bunch of VMs. There are valid reasons to have VMs.

Okay, fair.

Fine. Switching topics.

I do think when you think about like databases as representing crown jewels and sensitive information, just relying on one source of signal or one technology to get you the visibility you need is a failing proposition there because it's not going to provide it. And so the breadth and depth that logging, audit trail, control plane, whatever word you want to use there, gets you, especially around some of these crown jewels, I think is imperative. We've run incidents based on telemetry off of databases from CloudTrail as the lead alert. So it's important and it's something like, that's the crown jewel. So like ensuring you have some visibility there is kind of key.

Which reminds me, I've been meaning to ask my favorite question. and I've been asking that question to everybody who deals with cloud security, and I've been getting kind of very fuzzy answers. So this is a very trivial question. What are the top threats against clients' cloud environments you're observing? You guys deal with this on a daily basis for years, so you must have your own little top 10, top 5 threats that you see. You don't have to conceptualize about cloud threats. You see them. So care to provide some insight? What are the realistic top threats?

I get the easy answer.

Okay, go.

The easy answer is their first greatest risk is themselves. That's the self-own is probably one of the greatest ones. But Pete, go ahead because I know—

We put that at the 2 spot. I think there's one more that we see more commonly across the data we have, and that's compromised credentials. The issue there is we're talking about everything from GitHub, someone checked in credentials to GitHub and the repo is public and it was picked up in seconds. And essentially we saw the activity exploit EC2, AWS or what have you. We've seen that, but it's also like, hey, phishing is still a thing. So looking not just cloud infrastructure, but cloud applications, when you look across that estate, it's compromised credentials is the one seed. And that can also be like API keys that have been stolen. We've seen a bunch of that. It's anything that grants you access as the, like, it's just been taken, whether it was socially engineered, an accident, which I would put at the cell phone, like the, hey, I checked something inadvertently. And the next one is the misconfiguration that like, hey, We changed the security group policy in a way that we didn't intend. And that's where there's that gray area of like, where does the work start and stop? And asking a question like, hey, what do you do when you see changes to security group policies to a potential provider? The answer might be like, we haven't seen this before and it doesn't look normal. We're going to ask you about it. We're not going to put it on the ground. We're not going to close it. We're not going to not look at it. We're going to need your help, though. And then if you tell us it's not a thing that was authorized and not expected, we're going to treat it as an incident and we're going to— it's going to be go time. And that's where that work starts and stops. And so misconfiguration, that's also, hey, these things happened in this cloud application. That's a misconfiguration as well. It's not just the standard S3 bucket being made public. There's so many ways to shoot yourself in the foot, to Merck's point, that it is one that we see a lot. And then we're seeing more and more like exploitation of trust relationships, going from a partner or going from on-prem through into cloud, pivoting through based on where they get initial foothold. That's ramping up. And then the one that has been in the news and we don't want to harp on it is the supply side. Hey, they pop this thing and now everyone's at risk. And we put that at— of the things we deal with most frequently, it's at the bottom, but I think it's growing.

I love it. And I think I love the whole own goal, aka configuration/posture mistakes. I mean, they built this whole market, CSPM, CWPP, a bunch of other full acronyms from my former friends at Gartner. Well, My current friend's former employer are kind of highlighting this. And I think that's pretty much every research and survey highlights this, that people do still screw up configurations, and then they screw up identities, as you pointed out. So I love it. And I think that I wish you had a report that says this, because to me, this is kind of information that's missing in a lot of people's minds. Like, what are the top realistic threats? It's been kind of like top one, sure, everybody highlights the config mistakes. But then the list kind of unravels. So I'd love your answer. So before we wrap, I want to ask one more question and then our traditional closing question. So you deal with a lot of clouds— Microsoft Azure, Amazon, of course us. So which clouds are kind of the easiest for MDR to protect? I know I don't want you to say bad things about clouds. Cloud is a great thing. But are there any criteria or ideas as to what makes a cloud environment to be more friendly for MDR coverage?

I think the way that we'll answer this question is mostly from the perspective of the customer. The customer knows their security posture, and they know their organization, they know the structure, they know all these things about their environment. And so there's some things they want to think about when they're looking at providers, because at this point, those 3 that you mentioned are all equally awesome from our perspective, and they provide unique functionality. There's some places where they're unique, And you want to kind of know where to look. And so one is, hey, look at some of the audit logs that you think your application or your environment would produce. Look at the fields. Are the fields you need there? If they're not, are there subsequent API calls you have to make to get those fields? That can tell you, hey, if I put this in through a SIEM or a log data lake, I might have to go do some additional enrichment, or my provider will have to know how to do that. Okay, that's the thing. It might be certain audit classes do that. It might be none of them do that. could not be a problem at all. It's just that's a thing to go look at when you're looking at the security portfolios of your options. You know, look at what services you're using, look at the alerts and classes of alerts. I will say that they, they're all really good at documenting what they alert on, and that's been an increasing thing. Like, they've been ramping that up so you can kind of see like, hey, these situations, they appear to alert. That's good to know. These are things that I might find myself like risky behavior. These are things that I might find myself needing. Do they have specific security products around specific services you're using that are like high value? So like, hey, do they do anything with Key Vault? As a hot, like an example, or databases, right? Like, are there specific security things they offer or features they offer? And then also look at the prevention side. Cloud is awesome because you can push things down and you can normalize and set policy at a, you know, at the push of a button sometimes. How configurable the policy, how configurable are the preventions? Those types of things are good questions to look at, especially if you understand if you're either entering the cloud for the first time, you have the ability to set the stage, or if you're kind of fixing things as you go. That would be a different set of questions like, hey, we're going to do a shift and lift. Well, think about the state you want to be in. Think about the preventions and issues you've had in the past. How would they help you make sure that doesn't happen again from the data center to the cloud, if you will? And then I think there's just interesting, to Murk's point about like users making mistakes. If you're looking at like how confusing is the authorization or authentication model, and it looks like someone threw spaghetti on a whiteboard, like—

Oh no, you stepped on this one. Oh God.

It's something to think about. Because that's where people make mistakes that really can burn you down, is like you granted the wrong thing at the wrong level and it got inherited. Like, and those are really hard, and they've been hard for decades, right?

Yeah.

This isn't a new— like, these, these aren't easy problems or they would be solved because there's a lot of people looking to solve them. But these are all things that I think, think about. And cloud providers do things a little differently, and they've optimized for ease in different places. And it's up to the customer to kind of figure out what makes sense for them versus the provider. A provider should operate across all 3, and be effective across all 3. And the customer should pick the one that increases their security posture the best for their organization and their environment.

Okay. No, that's actually hugely useful. Thank you very much for this. So our final question is kind of one tip on using MDR for security and maybe some further reading resources, links. We'll add them to the episode materials. If you can only give one tip to a potential client on using MDR for cloud, what would it be?

I think that—

Or you can say, buy Expel. It's perfectly fine. I mean, I'm serious. We're not going to hold it against you. This is like your friends.

I do think we are the cloudiest of the cloudy MDRs, but, you know, whatever. Of course I say that. I'm the CEO. I have to. My CMO would have words with me if I didn't. I'm going to come back to what we started with, which is, are they native? Ask that question. And do they use their own service to protect themselves? Because that will tell you a whole metric ton of stuff about that situation. Because if they're not native, check for veneer. And if they're not using themselves to protect themselves, What does that say? So I think sometimes those simplest questions will give you the greatest depth and the most insight in the shortest period of time.

Perfect. So any further reading for the audience? I hear you have some fun blogs.

We do.

I think all of our blogs are fun and we've got a bunch on cloud. We've done ones on AWS Decision Support and other ways to help make our analysts effective. We've done studies using our data and our telemetry from our platform on performance and efficiencies. And so I think our blog is a great resource and we've got some really cool stuff coming too.

Perfect. Thank you very much. Really appreciate you being on the podcast. This was hugely insightful. Again, Dave and Peter, thank you.

Awesome. Thanks, Anton.

Thank you. 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 at Anton_Chuvaikin and Tim Pico. 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.