Do you have something cool to share? Some questions? Let us know:
ANTON: 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 the Subscribe To This Podcast or whatever podcast [INAUDIBLE] and distribute 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.
TIMOTHY: 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?
ANTON: Yes, how do you find the good one that actually gets Cloud. Because you may find somebody who is good with your old environment, but can they really spell GCP? Do they know Cloud? Do they know what's the function or--
TIMOTHY: What's a Pub/Sub?
ANTON: Yeah, what's the 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.
TIMOTHY: 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 other problem, which is Cloud response. So I really enjoyed this conversation and felt 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 "Merk" Merkle, the CEO at Expel and Peter Silberman, 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 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 let's consider the whole Cloud range from IaaS to SaaS.
DAVID: Sure. Pete's the brains of this operation, but probably, the first thing is, are they actually a Cloud native business? 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 enough a CEO could ask the question and understand the answer. You're kind of litmus test is, are they Cloud native, are they SaaS first, or is it something different? Pete, you probably got a lot of other thoughts on this.
PETER: Yeah. I think to amplify what Merk 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'd expect 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. 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 what does it mean to operate as a Cloud company, well, are they in the Cloud?
As Merk said, 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 a data sub-processor page, things like that.
It just all goes to 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 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 this because they're going through some of those challenges themselves, setting things up, setting integrations.
You want to make sure that when you think about those things, you want to hear that and what you're talking about, everything from how you onboard other options to onboarding, 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.
ANTON: So it's interesting, to quickly interject, I wanted to say that it sounds like there are almost like these little signs that indicate that you get Cloud that maybe other people can see. 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 think about it like ever document it, then 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 under thinking it?
DAVID: 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've 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.
ANTON: 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 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 the data center or securing [INAUDIBLE] How can you trust them in the Cloud?
So what are the questions clients can ask to figure out the right MDR for the Cloud environments, so what are the key challenges here?
PETER: Anton, one 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, then you work backward to really understand how it happens so that you can kind of mitigate all risk, it usually has 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 people who may have responded to an on-prem incident is much larger at this point in security, which is totally fine. But I think that creates this challenge of what questions do you ask, how do you evaluate. And I think one of the things I call out is, if you're asking questions based on-prem past experience and getting on-prem answers, that's a shift and lift Cloud MDR provider, and you 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 that are just questions you could ask. Does the vendor monitor themselves, is a great question. I hadn't thought of that. I like that one. But some of the other things I think to think about are, 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 around, which means there's a set of alerts, classes of alerts, classes of detection and response. They're not going to do it 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? OK, this activity is normal. We won't report it again. 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 that's going to pull off that veneer a little bit. What staff 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 MVR 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 OK. But I think it's important to set the table so that you can grow with the provider.
ANTON: By the way, you point, yeah, these are hugely useful at least to me. I almost see Gartner should have written a paper on this at some point. But I sense that you mentioned the one thing, who does what, your staff or their staff? But it's a three-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. I make it sounds like a tail.
TIMOTHY: I'm agreeing. It's a very agreeing finger.
ANTON: This has been bugging me quite a bit because people don't get that two party share responsibility in the model sometimes. But here, we have a very crisp three-party responsibility model.
DAVID: 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'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 it application level stuff. That's all your problem.
And so that's probably the most common misconception we'll run into even today, and 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, OK, well, what do you look for in a potential partner provider? One that actually understands it's a three party conversation, not a two-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, OK, do these people actually know what the heck they're talking about?
TIMOTHY: And for CEOs listening to this, it was the CEO who was ripping on CEOs, just to be clear.
DAVID: Yes, that's correct.
PETER: So there's kind of another party involved. So I want to throw a wrench in--
TIMOTHY: A fourth, the attacker?
PETER: No. I mean, they're in there, but I think about the stakeholders, especially in the Cloud. Security is working on behalf of a set of stakeholders to enable the business and 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 IM team that is managing policy and access. You may be working with engineering or DevOps, so 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.
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 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 can't have it for a couple of months.
So you can go get technology to help with on demand to temporal access to instances or something so you stop breaking glass and logging without MFA or something. That's OK. Accepting and understanding and knowing where your risks 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 fourth 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 embrace and be intentional about playing that role.
TIMOTHY: 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 pick out 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?
DAVID: Yeah. One thing I know that is a little different-- well, I'd 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 the lift and shift. And it's really just a bunch of VMs in the Cloud that you named all the same thing, and they are your pets.
But more often than that, what 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.
PETER: 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 the environment, they want to know. And I think matters is a key word because 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 than 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. And it's really exciting, 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 the experience and expertise, and I think that's an area where security can help.
ANTON: So basically, at some level, the 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 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 text 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?
PETER: 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 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 understanding the semantics of the data you're looking at. 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 [INAUDIBLE] 365.
Because certain events indicate certain things, and then in combination or in sequence, they mean a whole lot of activity or are a risk, potentially. And so there's definitely a capability, and it's maybe less tech, 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 three 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.
TIMOTHY: You know what I call that? I call that the Anna Karenina principle of clouds. Because that book opens with all happy families, they're are alike. All unhappy families are different in their own different way. Every Cloud is different in its own different way.
PETER: Yes, I would definitely agree with that. And every application is very different in very different ways, so it's quite a thing. And so 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 what you're looking for, how you're talking to the customer, where the work starts and stops, how you enable analysts, and that's where you'll see some of the differences in technology.
DAVID: Yeah, the biggest difference I see is you're just not going to see the same stack of third-party security products being applied.
ANTON: Why not, though? People do come with their frigging IDSs in the Cloud, frigging firewall appliances. Come on!
TIMOTHY: Virtual physical firewall appliances.
ANTON: Virtual physical firewall appliances. It's sounds so sad.
TIMOTHY: It is.
DAVID: 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, it's got to 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. The richness of a Cloud platform event does not rise to the level of say, a CrowdStrike alert. It just doesn't. So that deeper understanding is key to being able to actually formulate an effective detection strategy on top of 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 and the knowledge is necessary because it's that depth of knowledge that will actually lead to an effective strategy applied to your environment.
TIMOTHY: OK. 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 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?
PETER: Just to make sure I'm tracking the questions 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. So a lot of the conversation comes to at this point, when you think about privilege escalation or 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.
And 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.
TIMOTHY: Why is that?
PETER: 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.
TIMOTHY: Yeah, it can.
PETER: 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, 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.
TIMOTHY: 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 agent list 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 the same-- it's there.
PETER: Yeah, and 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 [INAUDIBLE] so we think about enabling our customer security teams to enable their stakeholders. We talk about that.
We want them to go talk to engineering about deploying it. 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 minimum 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.
TIMOTHY: See, I agree with all of that.
ANTON: It's also very cloudy.
PETER: It is very cloudy.
TIMOTHY: 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?
ANTON: Yeah, but wait, this is a separate episode, which we're going to record.
TIMOTHY: This is a totally separate episode. We're going down a bad path.
ANTON: But I wanted to have a quick but harsh comment about agents that like I guess argues with both of your positions.
TIMOTHY: Are you going to be weakened horse?
ANTON: I think agents imply that Cloud is just a bunch of VMs.
TIMOTHY: Yes.
ANTON: 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.
TIMOTHY: You don't necessarily have to lift and shift, end up with a bunch of VMs. There are valid reasons to have VM.
ANTON: Yeah, OK. Fair. Fine. Switching topics.
PETER: I do think when you think about 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 ensuring you have some visibility there is kind of key.
ANTON: Which reminds me I've been meaning to ask my favorite question and have been asking that question to everybody who deals with Cloud security and have been getting 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?
DAVID: I get the easy answer.
ANTON: OK, go.
DAVID: The easy answer is their first greatest risk is themselves. The self own is probably one of the greatest ones, but Pete, go ahead because I know--
PETER: We put that at the two 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, the AWS, or what have you.
We've seen that, but it's also 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-- it's just been taken, whether it was socially engineered, an accident which I would put it the cell phone like the, hey, I checked something in it inadvertently.
And the next one is the misconfiguration that, 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 where does the work start and stop in 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 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 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 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 Merk's point, it is one that we see a lot. And then we're seeing more and more 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 is at risk.
And we put that of the things we deal with most frequently. It's at the bottom, but I think it's growing.
ANTON: I love it, and I think I love the whole own goal a.k.a. configuration/posture mistakes. I mean, they built this whole market-- CPMs, CWBPs, a bunch of other four-letter acronyms from my former friends at Gartner, well, my current friends, former employer, a 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 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 contact mistakes. But then the list unravels, so I'd love your answer.
So we have a 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 the easiest for MDR to protect? 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?
DAVID: I think the way that-- well, I'll answer this question 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 are some things they want to think about when they're looking at providers.
Because at this point, those three that you mentioned are all equally awesome, from our perspective, and they provide unique functionality. There are some places where they're unique, and you want to 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 SIM or a log data, I might have to go do some additional enrichment, or my provider will have to know how to do that.
That's the thing. It might be certain audit classes do that. It might be none of them do that. It could not be a problem at all. That's a thing to go look at. When you're looking at the security portfolios of your options, look at what services you're using, look at the alerts and classes of alerts. I will say that they're all really good at documenting what they alert on, and that's been an increasing thing.
They've been ramping that up, so you can see, hey, these situations, they appear to alert. That's good to know. These are things that I might find myself 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 high value? So hey, do they do anything with Key Vault, as an example, or databases? 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 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 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 it's just interesting to Merk's point about users making mistakes.
If you're looking at how confusing is the authorization or authentication model, it looks like someone threw spaghetti on a whiteboard--
TIMOTHY: No.
ANTON: You stepped on this one. Oh, gosh.
DAVID: It's something to think about. Because that's where people make mistakes that really can burn you down, is you granted the wrong thing at the wrong level, and it got inherent. And those are really hard, and they've been hard for decades. 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 to, I think, about. And Cloud providers do things a little differently, and they've optimized for these in different places, and it's up to the customer to figure out what makes sense for them versus the provider. A provider should operate across all three and be effective across all three.
And the customer should pick the one that increases their security posture the best for their organization and their environment.
ANTON: OK, 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 region 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?
Or you can say by Expel. It's perfectly fine. I mean, I'm serious. We're not to hold it against you. This is like your friends.
DAVID: I do think we are the cloudiest of the cloudy MDRs, but 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 would give you the greatest depth and the most insight in the shortest period.
ANTON: Perfect. So any further reading for the audience? Here, I have some fun blogs.
DAVID: 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 there are 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.
ANTON: Perfect. Thank you very much. Really appreciate you being on the podcast. This was hugely insightful. Again, Dave and Peter, thank you.
DAVID: Awesome. Thanks, Anton.
PETER: Thank you.
ANTON: 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_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.
