EP157 Decoding CDR & CIRA: What Happens When SecOps Meets Cloud

Security warning.

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, now at 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. If you enjoy our content and want it delivered to you piping hot every Monday, please do hit that subscribe button. You can follow the show, argue with us and the rest of our listeners on the Google Cloud Security Community page. You can find the link to that in our show notes, on the Twitter, on our LinkedIn, everywhere you find the show. Anton, today is a special episode for me again because we had what felt like a kindred spirit for me on the show.

Sure, but it's also my obsession that led us there because ultimately, I wanted to explore how people are building tools that are labeled CDR, whether we need CDR, what is CDR. And of course, by CDR, we mean cloud detection and response. So, it's sort of like Tim's excitement, but my obsession to define CDR crisply, going back to my analyst days, is what led us here.

But the evidence is fun. What's CDR?

What's cloud? Can we define cloud crisply yet?

Oh, we have an episode where we fell into the discussion of defining cloud and we almost did.

So we'll link to that episode.

We almost did.

We'll link to that episode. Okay. So if we can define cloud, can we define cloud detection and response?

We'll just use the duct tape and we'll duct tape 2 definitions together and like then paint them with the same color, probably blue because cloud.

Of course.

And that's the thing.

Okay.

Well, listeners, with that, let's turn things over. No duct tape involved. To today's guest. Today we are joined by longtime listener, apparently first-time caller, Ari Zilberstein, CEO and co-founder at Gem Security. Ari, I'm so excited to talk about this episode because it's a topic that, well, you must know and listeners must know, very near and dear to my heart— cloud detection and response. It's to me such an interesting place to be on the frontier, and it's really fun to meet another person who's out here on the frontier. So first of all, thank you for joining me or letting me join you out in this interesting problem space. Maybe for people that aren't as familiar with the space as we are, what makes it different? Why do you and I have this opinion that I think you would share that it's its own thing? Why is cloud detection different?

That's a great question. If you think about detection and response and even the broader definition of threat detection, investigation, response, I think the challenges are really coming from each one of these capacities of a solution. And I think it all starts with the visibility, because if you want to have detection response, you need to have some visibility. And one thing that I, you know, in my perspective, really describes the problem best in the cloud era is that the volume of the logs and telemetry is just a different scale, meaning that if you wouldn't want to use traditional solutions, it might work, but it is one different scale that I think that really invites different challenges in detection response in the cloud. So, one thing, is about the volume of logs and telemetry. Second part is really about the detection, which is next to visibility, and it's not fundamentally different. And what's different is really the techniques that are different. You know, it's different attack techniques. Attackers are doing things that are different because the perimeter, the technology is different. So different techniques, and you need to have a different set of knowledge, of experience to how to deal with these types of techniques attackers are using in the cloud. And I think the last part is, In my perspective, even, you know, the most complex part and different in the cloud is that the environment is quite complex, right? Because endpoints is complex, but then you do have solutions to simplify that and to make sure that it's good. But cloud, in my perspective, is far more complex if you want to comprehend, like, for example, an activity like anomalous behavior in the cloud. That means that you need to understand what's going on in there.

Yes.

I think that is one part that is quite more complex.

Yeah, I think cloud is so interesting for that because cloud environments are so often dev environments, they're scaled environments, they're ephemeral environments. And so you get this horrible multiplicative complexity of developers doing developer stuff at scale with ephemerality.

100% agree with you. And actually, ephemerality is one of the reasons I also think cloud detection and response is different, because if you want to detect and respond to attack on an asset that's existing right now but wouldn't be existing in 5 minutes, then how do you do that? How do you collect evidence? How do you think about that? So I think ephemerality is part of the challenges that are in the space of cloud detection response.

It's not like you can go grab the hard disk.

But is it? I still feel like I want to push back on this, maybe by charter of me reporting to Phil Venables, who wrote this great blog about megatrends. And one of them was actually the cloud is simpler than on-prem. Initially, I wanted to argue with this, but the logic that we usually use to justify this argument is that when you think of on-prem, you should think of server procurement, data center space, configuring hardware, wiring things. So, in that sense, cloud is simpler than the entire stack of the on-prem data center equipment and risks and threats and everything. So, in that sense, Cloud is hard compared to a single Windows machine, sure. But is cloud really more complex than the typical data center environment with wireless access points hidden in closets and stuff like that? Does complexity argument hold if you consider the entirety of IT on-premise?

I think actually that's a good point because maybe I was saying complexity, but I think that eventually it wouldn't be as complex because we'll know that that would be the present and we'll learn that. I think the right word maybe to use, you know, in our discussion is different. It is fundamentally different. And I think that this difference these days would lead to the complexity because we don't know and we need to build different stuff. But it is fundamentally different. And if I may kind of add one more point, what you said is another fundamental difference. One is the ephemerality. Another one is really between on-premises servers, physical things to a control plane. structure where you have different layers, identity, network, compute, all of that, data as well, by the way, coming together with a control plane that you didn't have in the on-premise that is able to control all of these assets, all of these resources. And by the way, with that, I'll give you one example here. I say that getting access to the control plane of the cloud is far more dangerous in the outcomes than getting just access to administrative access to a domain controller, because it's not only getting access to to control the terrain, you can actually change it. You can add resources, you can limit resources. And that's really a different kind of how to think about what the level of access you can get out of the control plane in the cloud.

It's kind of cloud admin is more admin. Like cloud admin is admin superpowers are more bigger superpowers. Like that's roughly what I'm hearing, right?

Yeah, I use actually, you know, for getting administrator in on-premises, I would say it's getting keys to the kingdom. I think getting administrative access to control plane getting keys to the keys to the kingdom, you can actually not only control, but you can really, really change the terrain and how the environment is built.

Yes.

Love it.

I joke that no matter how good your phishing campaign is, you're probably not going to get access to spin up 5,000 new instances in the on-prem data center like that.

I agree with you 100%. Exactly.

Yeah.

So, I think that it's kind of this unfamiliarity and difference rather than complexity. I think that's— again, I'm not trying to pursue the same point indefinitely, but I think it's also unfamiliarity that really trips people. Like, when I think about all the lift-and-shifters who go to cloud with on-premise mindsets. So, the next question I wanted to touch is sort of, we do see organizations that move servers to the cloud, and they move their thinking because they say it's kind of hard to figure out who to hire, how this whole cloud-native, cloud-born stuff works. So what's your advice for a team that does know how to detect and respond to incidents, whether it's a SOC or a CERT, but they're ultimately on-premise trained? How do you explain or teach cloud DNR to on-premise DNR folks, if it makes sense?

Yeah, absolutely. And actually, I want to ask a question to this group, as well. Like, what would be more important? Would it be the mindset of detection and response, or the knowledge of the cloud to be able to detect and respond to threats in the cloud? Is it the cloud or the detection-response mindset? I have my answer, but I'm curious what you guys think.

You know, wait, wait, wait. Before Tim answers, this is like really kind of surreal cosmic significance because just yesterday we were recording a podcast episode with somebody who does— we can probably share it— who does cloud forensics at Google. And we wanted to know that exact thing that you just asked us. And we asked him that question. So now my mind is like scrambled a little bit because we have my perception, we have his answer, and we have you asking us the question. So I'm going to just delegate it to Tim.

Thank you. I think honestly, you can buy detection content, you can hire your company, you can hire my product, but you can't buy cloud mindset in people. You can't pay money to make somebody think about the world the cloud way. And so, I would rather look for somebody that has cloud mindset than look for somebody that has detection content experience. That's my answer.

Interesting.

What's yours?

I don't like that answer.

I'm sorry.

Because I feel like you can teach cloud by giving somebody a class, but if you are not naturally a threat thinker, not naturally the cat and mouse, bad guys and good guys—

Oh, I assumed we had a threat person who either had cloud experience or this, not no threat at all. I agree that it's really hard to teach the detective mindset.

Yeah, exactly. And I would agree with that. And I think to Anton's point, I think that the mentality of a detection threat investigator, like knowing what questions to ask, in my perspective, is even harder than knowing the technology that you're asking about. You need to have the mentality, the investigative mindset. And I think cloud and, you know, what's identity role in IAM, And that could be taught. But having this investigative mindset, threat MITRE, you know, even mindset, this is something that you need to really be in that mindset to be someone, you know, from the SOC to incident response, a threat hunter. And that is, I think, better to have, first of all, the mentality. And on top of that, to Anton's original question, we can learn cloud. We can learn what it means, you know, what logs, what entities, how does it look like. But the mentality is the fundamental piece that I would prioritize.

I think that's super reasonable. Yeah. So Anton's friends at Gartner have done what they do and invented yet another acronym, this time CIRA. CIRA sounds like a character from Death Note.

You know, I don't actually know how to pronounce it. I think Ari might know because he probably talked to Gartner about it, because I honestly don't know if it's a CIRA or a CIRA.

So it's CIRA, the way I understand that.

CIRA.

Okay.

Okay. Even though when we start But KIM with that same C for that same value, it becomes KIM.

You know, I wouldn't like to commit on that. It might be a bit tricky, but that's a good point now.

All right. Well, apparently it stands for, listeners, Cloud Investigation and Response Automation. This kind of sounds like we took CDR and married it to a SOAR and then called it a new acronym. Is that what it is? What is it? Why did Gartner do this other than this is what Gartner does? Of course, the scorpion stings you.

Ah, Tim, that stung.

Appropriately.

I'll tell you that I do think that Gartner, in that case, is pretty spot on in understanding that there's a new emerging space that defines how to do cloud investigations and how to automate response in the cloud. They say, you know, it's not quite the same as we would've done that with previous technologies. You know, like, by the way, EnCase for running forensics or other ways of collecting forensic evidence and running response, which I think He's right. And CIRA is really about the forensic, about the acquisition, about the automation of how you really do that at scale and the scale of the cloud. I think, by the way, you know, because you touched on that, CDR is a broader vision or space where it tackles, you know, from the continuous side on how to gain continuous visibility, ongoing visibility, continuous detection. And then ultimately, for sure, you also have the response and the automation of how you can do with that. So like EDRs, by the way, as an example, maybe 5 years ago they didn't have that, but EDRs today are really responsible for, you know, from visibility to detection, response, and forensics too. You would take your EDR, get forensic evidence, et cetera. CDR would eventually evolve to include SIERRA capabilities, which have the forensic capabilities acquisition and all of that. So I think CDR is broader, where SIERRA is a subset of more the forensic side of the house.

You know, it's funny when we think about forensics in the cloud, there are so many opportunities to have that be driven by API, automatically done, automatically stored in ways that are robust and capable. I think actually that's an area where it'll be a lot easier in cloud than it was on-prem. We don't have to send someone to the data center and yank a hard drive. We just hit the snapshot API and we're good.

I agree 100%. I actually, you know, we're only talking about the challenges, but we should actually speak about the opportunities.

Yes. Talk about what gets better, please.

Yes, please.

And I think that there are opportunities for the cloud cloud, like, response to make our life easier. And eventually, I do. I'm very optimistic, and I think that cloud could be even more secure than on-premises.

Yes.

Because on the one hand, we talk about telemetry and how bad it is and how massive it is. But actually, many years ago, we used to carve our endpoints to get evidence. In the cloud, we need to just do a few clicks and get a bunch of data, can enrich data to find answers that we didn't have. So, you know, this is one opportunity. And to your point about the forensics, Right. It's about APIs that could get you the data that you need, as opposed to really carving and digging really, really hard to get maybe evidence that will tell you what really happened there. And these are, you know, part of the opportunities in the cloud. And maybe the last opportunity, which is embedded in CIRA, is the automation, right?

Yeah.

Because everything in the cloud is programmed, you know, could be programmatically automated from application. And why not take the automated approach of how you run application in the cloud to the response side and how to run detection? So I, It's maybe a way to say that it's not only about challenges and complexities. These things can also invite us innovation and opportunities to be better and to build things better in the future, in the cloud era.

That optimistic cloud can be more secure, literally the pitch that got me to join Google. Like a director here, Jess, years ago said to me, Tim, cloud fundamental shift in how we think about compute, opportunity to glue security into the foundations rather than bolt it on afterwards. Come join my team. And that's what got me to leave Stripe and come do this crazy adventure. So from my first moment at Google, I couldn't agree more with you there.

Very cool.

I mean, I obviously agree with that because ultimately, that's part of our charter. And then, I mean, many of us— and Phil Venables gets asked the same question. When he wrote the Megatrends blog about cloud being more secure, people said, well, of course you'd say that because you're a CISO at the cloud. But he said, wait a second. The only reason I became a CISO at cloud, because I believe in these things before. And to me, that's a very clear and very crisp point to make. But at the same time, to go down to a more tactical level, should this stuff like CIRA exist as a category? Because even CDR is kind of frankly debated whether it's a good market category. Some people would say, I'm just going to use SIEM for that. I'm going to load up all these cloud audit logs and endpoint logs into my SIEM, and this is my— My CDR and my SIEM is my name your SIEM du jour. So what is wrong with that thinking, if anything?

Nothing wrong. First of all, I think it's possible. And, you know, if you think about that hypothetically, exactly what you're saying is possible, right? You know, it's only logs and it's only rules and it's only, you know, response. And we can build all of that with a SIEM solution that is, you know, is not a bad solution in most ways. So hypothetically, you can take logs, take it into a SIEM log aggregator and build logic, automation and all that. And you have that. However, you know, it's very costly, you know, given traditional solutions and how you can, you know, how they solve that. It's costly not only in terms of how much does it cost to ingest data, it's costly in terms of how much you need to invest in building that brain of running detection analytics, even behavioral analytics on the different entity space of the cloud.

Oh yeah.

And then automating the response. And an analogy that might help us think about that is the EDR space, right? 10 years ago, how did we do endpoint detection response to some extent? We installed Sysmon on endpoints, but, you know, had a bunch of telemetry coming from process execution, et cetera, send it into a SIEM solution and roll detection. Today, nobody does that because you have something that is actually in a box, out of the box, running the visibility in an automated fashion that automates the entire detection response for the endpoint. And the same thing, in my vision, would actually happen for the cloud, as well, Mm-hmm. where the brain would be, not in the SIEM, because there are so many responsibilities we anyway want the SIEM to take into account. And that part, I think, is just too much to ask for. And we need to have a friend of the SIEM that would deal with that only.

So where this is going is one of the things that I think is really interesting about our space, which is its kind of fractal nature. And what I mean by that is I have these conversations internally every week. Oh, I'm the this team. I want to build detection. I say, great, great. Let's work together on that because detection for your thing, as important as it is, doesn't stand on its own. You can't understand the context of an actor just looking at your service. You need to have that integrated with the whole of what's going on in Google Cloud. At the same time, people say to me, Tim, that's really nice, but cloud is not the whole story. There's my upstream IDP, there's my on-prem systems. And so at every level of this problem, we have your thing is not the whole story. And so when we think about CDR and think about the output of our systems and the results of our detection and the analytics and the context, how do we appropriately contextualize that in an overall organization story?

I think it's a challenge, and I think no one answer fits everyone.

It's a good answer.

Yeah, it's hard.

No, reality is that it is a complex issue to solve. I've seen many organizations solving that in a different way, but I do think that there is room for technology or for a piece that would solve and give depth to the complexity and to the difference in how that technology is being served, as well as other types of things that would take different outcomes and signals and bring them together to a broader context of what's happening in the organization. So, I think that there is— the answer for me is that you need to have both. You need to have a specific solution, a DEF, that would bring confidence around the cloud, but that should be integrated and well integrated in the entire security operation workflow that really sees the bigger picture. And that is how I think eventually people want consolidated workflow. So it doesn't mean that they want one product to do everything. It means that they want products to work nicely together to provide them a consolidated workflow and consolidated response. I think that if products can play nicely together to achieve that, That is the holy grail.

So that question of getting things to work nicely together kind of brings up again the question of getting people to work nicely together. When you're out there getting your product into people's hands, who ends up being hands-on with it? Is it a traditional SOC team? Is it a cloud center of excellence? Who ends up using it?

That's an interesting question because we've seen evolution in that, and we've also seen some outcomes of making people work.

Aren't you guys just 2 years old?

We are, but, you know, the world is, you know, aren't you saying that cloud is very fast?

Yes, it is. It is.

This is how it is evolving. But to your question, our user is eventually the SOC, you know, starting from the training question. We want to have people with a threat mindset. They would be the ones who are using CDR, cloud detection response. They would care about detections. They would understand what detection is, understand what response is. So they would be the users.

However, what— So wait, sorry for interrupting at the most exciting spot. Sorry for interrupting, but like, Ultimately, your toolset really helps the SOC to get cloud rather than it helps cloud to get detection.

100%. Exactly.

Okay, awesome. Thank you. This is good. This is really good.

No, exactly. That is the point. I think that this is, you know, bringing cloud into the SOC. It's something that not a lot of products have done before because many cloud security are doing cloud for cloud, for cloud architects, engineers, but they are not with the threat Mindset. Exactly. So what we see first is that the threat, you know, the SOC and the incident response, security operation threat hunters, they would be using Jamf. They would be using CDR. But then you'd see that the DevSecOps and the cloud engineers would like to get access as well because they are the users in question. They would be doing some of the activities. And then we see evolution where the first user, the responder, is a responder, right? But then you see evolution of collaboration being driven by that kind of solution that, first of all, you have the threat responders, but then you also have the context from the application engineers, developers that also want to understand what's going on in the environment. But this is how it usually works. And that is the evolution that we've seen first being introduced to the SOC, but then others want access as well.

That's a good model. I like that. I like that answer a lot.

But access, does it mean that you need to connect? Yeah, I like the model a lot, but you would need to talk to IT automation tools. And to security tools. So, there's a bit of an integration. It sounds like there's a bit of an integration challenge here as well, because you would need to talk to cloud infrastructure, you would need to talk to existing security tooling like SIEM, SIEM, SOAR maybe, and probably to some DevOps automation stack. This integration is a mess. How do you deal with that?

So, it's a challenge, yet an opportunity. It's a challenge because, as you said, it's hard. And it's hard, period. I agree with that. But if we, if a solution gets it right, think about the opportunity that it can bring to the game, the ability to speak SecOps, as well as bring the language of the cloud and to translate that into the SecOps perspective. So the opportunity is massive. And I think that we want to focus on the opportunity. And I do acknowledge the challenges. So I agree, it's challenging. And there's a lot to integrate. And if you think about the deployment, so for sure, It's mainly a tool for the SOC, but then you would need to have the integration for the cloud and have the cloud engineers on board, et cetera. But it is a solution that would be facing the SOC, integrating with this array and suite of tools from left to right.

Well, Ari, I have the feeling that you and I could talk about this stuff for many hours. And perhaps this is one of those times where listeners— people have said lately, hey, could you do longer episodes? I wish we were doing a longer episode today. I have to ask our traditional closing questions. And it breaks my heart. One, do you have recommended reading for our audience? And 2, aside from purchase your product, do you have a recommended tip to help people improve their cloud DNR?

I'll do the obvious and say, I did myself enjoy listening to many, many of the episodes here, even in the beginning of the journey of building the company. And I found the perspective to bring on board in this show very, very good for us. So, I think that whoever is listening right now would probably have this recommendation already in place, but that's what we want. Not so traditional answer, maybe. And the second part is, you know, I think that it's important for people who are in this space or evolving this space is really be informed, read, and more consume, you know, things that happen in reality, attacks that are happening. How did it happen? And actually, I do want to refer one resource, which is a few people in the community of cloud security actually published a list of attacks in the wild in the cloud. that they are, you know, it's what you can find open source. And these listening attacks, you have really, you know, the reason how did it happen, as much information as possible available. And I think sticking to that as reading materials and as an evolution, if you want to be good in this space, would be a good resource. And I can provide the link to share in the comments.

Awesome.

But that would be my recommendation for listeners.

I love that recommendation. Nothing like telling people to stick with reality. Ari, thank you so much for joining us today.

Thank you for having me. I really, really appreciate that.

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 @DavidMalan and @AntonChuvakin.

Anton_Chuvakin and _TimPico.

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.