EP78 Classic SOC Meets Cloud: What Changes? What Stays the Same?

Security.

Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here are myself, Timothy Peacock, the product manager for threat detection here at Google Cloud, and Anton Chuvakin, a reformed analyst and esteemed member of our cloud security team here at Google. You can find and subscribe to this podcast wherever you get your podcasts. as well as at our website, cloud.withgoogle.com/cloudsecurity/podcast. If you like our content and want it delivered to you piping hot every Monday afternoon Pacific time, please do hit that subscribe button. You can follow the show and argue with your hosts on Twitter as well, twitter.com/cloudsecpodcast. Anton, we're having a conversation today about, well, all kinds of stuff, SIEMs in the cloud, but also AI.

Yeah, AI makes an appearance, and I think that the conversation nicely devolves into a pillow fight at the very end. A very gentle pillow fight. A very Gentle pillow fight with really small pillows at the end. But I think that's why this episode is definitely worth listening all the way to the end. But on a more serious note, we keep exploring, struggling, being on a quest for this whole threat detection SOC plus cloud equals what?

Hmm.

How do we do it right? And we look at it from the technical angles, more like detection of threats, more like high-level angle. How do you organize your SOC for the cloud? how you transcend your SOC to be better in the cloud. And this is part of the same conversation to me.

Yes, we've even had the philosophical conversation about what Karl Popper has to say about threat detection in the cloud, but that's not what we're doing today.

And so perhaps with that, let's welcome today's guest, Gorka Sadowski, Chief Strategy Officer at Exabeam. Uh, Gorka, you get to claim a first. You are the first Chief Strategy Officer here on the podcast. You'd think something like a podcast would attract more Chief strategy officers, but I don't know if that says more mean things about podcasts or chief strategy officers.

There you go. Happy to be the first one here. Thank you for having me today, guys.

Delighted to have you. So I want to talk about an issue that occupies a lot of my time and increasingly some of Anton's time, and I bet a lot of your time, which is how do we get a legacy SOC to think about a public cloud?

So that's a great question and we could spend 3 hours or more just on this one topic.

Listeners, we're not going to spend 3 hours on it. Just 30 minutes today.

Warning.

Yeah. Yeah. Let's go with 3 minutes. And I think it's a very difficult question just by the sheer number of parameters and dimensions that are hiding in this question. So it's about, you know, the new vectors, the adversary behavior, the visibility constraints that could impact these, the capabilities for the response, the contract limitation that could impede some of the cooperation. And there's a lot of different topics, the federated multi-team response. The living with both on-prem and cloud and the hybrid infrastructures and documented dependencies. I mean, we could go on and on and on about, you know, almost like a list of topics that are in scope for answering this. I think maybe a better way to look at that, and that's maybe the ex-analyst, the recovering analyst in me, you know, speaking, but is to take a framework to think about that. And one of the frameworks of reference that I think is interesting is the PPT. People, process, technology. And when you look at that, and maybe starting with the process, I think it's very helpful because the process is really very, very similar, if not the same, right? It's about threat detection, investigation, and response. That's what the SOC needs to do. The SOC in the cloud for the cloud needs to do. And I think it's something that we can fall back on because that's what the SOC has been traditionally doing. So it's about taking that same process, right? The TDIR. So it's about data collection, detection, triage, investigation, and response. And for each of these phases, then let's look at what the cloud is bringing in terms of your people and your technologies. In terms of your people, as in, you know, do I have the right skill set in my organization or in my SOC? Do I need to give training to my people? Do they need to work in a different way? So maybe take that TDIR process. and think about what that means for your people. And the same for the technology, right? So just starting with data collection, do I have the right technologies that are deployed to get the right context, the right information for me to solve the right use cases that are in scope for me? Do I need different collection technologies? What do I store them? What do I do for detection and triage? And the same. So I think that, you know, again, to think about the cloud SOC is very, very large. And taking a framework— so people, process, technology works. There might be other frameworks that your organization may be adopting. Take that as a structured method to think about that and systematically solve all of these and look at what that means for your people and for your tools.

Okay.

So maybe it would be fun to go a level deeper on one of those areas because that was a lot of areas.

Yep.

Let's, just for the sake of fun, let's talk about maybe, if we could, another 3 minutes, what needs to be different about detection technology in cloud? Let's just start there.

Yeah. Let me actually bring it one level back. Let's think about detection before we think about detection technologies. Because again, I think, you know, the tendency for the cyber people is to think technology first. In fact, technology should be nothing but a support for the process. So let's look at the detection as a process. And specifically, what are we trying to detect, and how are we going to detect that? And once we have figured those things out, then we'll be in a better position to select what is the technology or technologies that need to be brought to bear for that.

So I think you're about to be the second guest in as many days who helped me and Anton settle an argument. What do we need to detect in cloud that's different than we needed to detect on-prem, if there's anything?

Yeah. Yeah. And look, that's a very fundamental question and that's probably a good way to start this. I think one thing that I would like to avoid is kind of the IOC rabbit hole. And there's essentially 2 ways to think about that. And I'll bring not the PPT, people, process, technology, but the TTP, the techniques, tactics, and procedures, which is another way of looking at this and saying, okay, well, in the cloud, a lot of the procedures could be very, very different. A lot of the tactics could be very, very different. However, what is likely very similar are the techniques, right? And something along the lines of a kill chain or what the MITRE ATT&CK framework is laying down is actually a good way to think about that. I think if we focus on what are the IOCs that are different, what are the procedures and the attack vectors, and what are the minute details between detection on-prem and detection in the cloud, It's a never-ending story. However, let's maybe step back 1 or 2 steps and think about what are the commonalities, what are the things that are still the same, because that we know we have a set of best practices on how to solve those. So, what are the use cases? They're the same. They're about external attacks. They're about compromised insiders. They're about malicious insiders, data exfiltration. I mean, look, that's the use cases and what the bad people want to do are very, very much similar and very much the same. The way they go about building that attack chain is very similar. Now, the attack vectors and how to get there are different, but maybe one thing that is very, very common is the fact that a lot of those, at one point, will leverage credentials. It's about credential misuse. It's about persistence. And, you know, sometimes on-prem, you would get malware via, you know, via email. And in this case, you may get malware in a different way. It could be a buffer overflow, could be something else. But at one point, the attacker will likely want to establish persistence using stolen credentials. And that's kind of the weak link that has existed on-prem and that still exists in the cloud because you can, once those credentials are misused in that they're coming from you know, name your favorite enemy country, or they're coming at odd hours from odd places. That's kind of the Achilles heel for a lot of those attacks. And very often, all of these use cases will land at one point on persistence that's leveraging credential misuse. That's a good way to start looking at the problem and solving many families of issues using a common approach.

So, wait a second. So, to try to expand this framework, kind of go back up a little bit, like, if you think about what's different in cloud versus data center from the threat detection lens versus what's the same, to me, what I've heard is the broad use cases are mostly the same. The role of identity to me, there is— that has the same and different. Like, identity in the cloud is more important, but identity is also important on-premise. But what about the environment? What about the pieces of tech stack? These are different. You're not protecting servers. Well, you are protecting servers, but not just servers. You may be protecting microservices or SaaS. So what about the environment? Is this different in your mind or not?

Yes, yes, it's very much different. And as an example, you know, the container and the library problems that you may have in the cloud are different than, you know, the situation you may encounter on-prem. I think in the cloud is also, you know, the supply chain and the dependencies between The different elements in your technology stack are also very much very different, and they can be sometimes nebulous in terms of what is hiding behind. And when I say hiding, it's really hiding. What is hiding behind my supplier, my CSP? What are the different technologies that are on the backend of that? You have leaky bucket situations that may occur that might be different from the same on-prem. There's a bunch of issues around internet-facing systems that you may not have when you're dealing, you know, with your network and the trusted zone. So there are a number of technology issues that are very different. But again, I think that if you start listing those, and it's probably interesting to list those as different attack vectors, you are going into kind of an IOC type of approach where things now start becoming very complex. Whereas if you start, when you think about the different techniques that an attacker is taking, I think those are higher level. Maybe it's the difference between an AV that has a bunch of signatures, and the signatures change all the time. And this is the same. You know, the IoCs may need to change all the time. However, the method of infection that malware may have on your endpoint are essentially the same. So rather than dealing with the signature, the IoC, or the technology aspect of that, let's look at the lifecycle of an attack. And what you can do to detect those.

So Gorka, are you saying that there would be some TTPs that are the same and some are different? So what should we bring with us to the cloud when we move? Like, what type of detection logic stays? What type of detection logic comes with us? Is it a useful question?

Yeah, I think it's a very useful question. And I think there are detection technologies that should be the same, and we know what those are, right? It's still very important to do IOC and pattern matching. It's still very important to do behavior baselining on that. It's still very interesting to do correlation. It's still very interesting to do anomaly detection. And those are very interesting detection technologies that can be applied to a lot of these. So as an example, an S3 bucket that may or may not be open, who's accessing those? How often? From where, what are the characteristics of the usage of those are also very, very important for us to detect a misuse of some of these buckets or the way a pattern is using. And that behavior understanding and understanding of the normal behavior and the abnormal behavior is interesting not only for your identities and the people and the users, but also machine-to-machine communication. And those are also very interesting, those understanding of the behaviors of normal and abnormal, also very interesting for the assets. So if you have assets that now starts behaving very differently, that's something that you may want to look at. And I don't think it should be an either/or. It is really a combination of these different detection engines running in parallel. Each of them has applicability that is very interesting. And all of those working in conjunction should be able to tell you that something is for sure an attack, something is for sure a vulnerability, something is for sure not normal behavior. And when you put all of those together, that now you can start raising your confidence level that it is something that requires your attention, either with an identity or user or an entity in your organization.

Okay.

Makes sense.

So it really comes back, in your mind, in cloud, to detecting cases where we can profile rather than say know a pattern or a TTP. I'm curious, in your mind, where do you draw the line between TTP and IOC? Because I've heard you use IOC to describe things that kind of sound like TTPs in my mind. And I'm wondering if you think there's a valid distinction there or not.

I think there is. An IOC, an indicator of compromise, is— it doesn't mean that for sure you know that you are compromised, but it could be an indication that you might be compromised. Right? An indicator of compromise. And sometimes those come with false positives. But there is, you know, in a Venn diagram, there is kind of an intersection between your TTPs and your IoCs. But again, I think of an IoC, at least in my mind, and everybody has a different, you know, semantics around that.

Which is like already pretty broken, right?

Seriously.

If we can't agree as an industry what's an IoC, we're kind of screwed in many ways.

Yeah, yeah, yeah. Well, so that goes back to we need a common nomenclature for a lot of these. And I think in the cloud, it's going to be more important than ever. And we have an opportunity because a lot of this is new. We have an opportunity to almost kind of start from scratch, not only for these different acronyms, but also different acronyms for technologies. And so I hope, you know, we, and that's the collective we in the cybersecurity space, we take this opportunity to really look at a clear definition for what those are. But again, in my mind, I think IoCs are more discrete things that you can do matching on, even though technically an IoC could be something much more fluffy and higher level. I'm not sure I like IoC as much as I like TTP because TTP introduces a hierarchy around the different levels of understanding and intelligence that you have around an attacker's behavior. IoCs are more flat and represent different dimensions. TTPs is a better choice of word, I think, for that.

And I've seen some decent blogs. I'm actually checking one because people are still debating this because they probably assume in most cases that the IoC, they assume to be like a bad IP or bad hash. But TTP is kind of more of a hierarchical story of things.

Yep.

I'd rather avoid this debate. So let's kind of try to nail it a little closer to the cloud. And so if we do go back to tools and I'm thinking, hey, I'm going to get my SIEM, which I've been using for the previous 20 years, Versus I'm going to talk to some kind of vendor startup that promises CDR or CXDR or C-something-else-DR.

Yeah.

Do content— well, rules, algorithms, and engine need to be different for the cloud, or can it be the same? Like, to me, this is kind of binary. I don't think it's a nuanced question.

So if you've been using your SIEM for 20 years, chances are it will not be appropriate for the cloud.

Okay.

Because 20 years ago, things were on-prem. The analytics were very crude. There was no context of full lifecycle of TDIR and operationalization of your tool in order to generate insight.

But those don't sound like they're cloud differences. Those just sound like the industry's evolved.

Old, yeah, old versus new kind of thing.

TDIR is just as valid on-prem as it is in cloud. So what's different about cloud that means you need new tooling?

Well, so legacy systems were not about TDIR. Legacy systems have been over-pivoting on detection and then detection and response. Right? It's only lately that we realized that the big Pandora's box in a SOC is not the detection or the response. It's actually the triage and the investigation. And legacy SIEM tools were not geared to solving that triage and investigation problem. It was about detection. It was about minimizing the false positive and detection coverage. Later on, they slapped a SOAR in order to do the response. But I think a new tool— the new tools have an opportunity to say, Okay, we learned from the mistake of the past. We know that the goal is not detection. The goal is not response. The goal is to generate insight and really have a use-case-first approach. And in order to do that, we need to deliver on the whole TD-IR workflow and lifecycle across all of these phases. So, it's a little bit different.

So, I agree that we've gotten better at understanding a day in the life of the analyst and building tools to support them at each stage of the journey.

Yep.

But how is that different in cloud?

So in the cloud, what does that mean? Again, when you go back to the data collection, you likely need a different collection mechanism. On-prem, it's about getting syslog, opening that, and you just receive syslog. In the cloud, it's much more based on APIs. So how do you collect the data? Then, what are the detection mechanisms? And we talked a little bit about detection. What are the detection mechanisms you apply in the cloud? based on the latest TTPs that are happening in the cloud. Again, the engines are very similar. It's about pattern matching. It's about correlation. It's about UEBA. Then, the triage and investigation also could be different in the cloud.

Because the context is different. The context is different. There's no more who owns this IP.

Exactly.

It's more about accounts and projects. Yeah, triage would be different.

Exactly. Especially in a multicloud environment, the triage and investigation could be vastly more complex than if you own the whole infrastructure, you know, in your own data center. And then finally, also the response. So the response, you can say, okay, well, I have APIs available, I just invoke those and do what the response needs to be. But there's a bunch of contractual possibilities or limitations around that, right? Now you want to start touching things that may be outside of your control. So the Cloud SOC is going to require cloud SIEM. And I think because the data is in the cloud and the workloads are in the cloud, you want a solution that is in the cloud for the cloud. So your SIEM should be cloud-hosted, cloud-native, should be in the cloud for the cloud.

Wait, why do we need to be in the cloud to do the cloud?

Well, scale probably, right?

There are scale issues. There are data back and forth issues. If all of your data is in cloud and your SIEM is on-prem, You likely will be paying a very heavy tax to get all of the data from the cloud to your on-prem SIEM. And then if you need to do things then back, that means you need to do a bunch of things from the SIEM back to the cloud.

What if you have multiple clouds? Do you want to do cross-cloud or per-cloud?

Those are 2 different models. And that goes back to a paper that we did over at Gartner, which is, do you have one per cloud? You have one SOC per cloud, and then you have a federated SOC that looks at all of that. Or do you get all of the data from each of the clouds to a central cloud? There's no magic approach in here. Each of them has pros and cons. You know that answer, it depends. It will depend on what you have, on the clouds you have. It will depend on the structure of the people that you have. One thing is for sure is that the cloud, more and more in the SOC, more and more in the cloud, will not be a physical center with a bunch of screens, but it'll be a bunch of people working remotely, likely at home or working wherever they are. And it'd be a virtual SOC more than anything. So that opens up the door for looking at either a per-cloud SOC and then have a command SOC on top of that, or having a command SOC directly based on all the different multi-cloud assets and workloads that you have.

Okay, so we're getting towards the end of time, but I want to ask one more potentially leading question. ML. Do you need ML to do cloud threat detection, or is that just like a totally distracting side topic? Because you've alluded to a lot of profiling, and that's often a byword for ML.

Yeah, yeah, yeah. I think if you don't have advanced analytics in the cloud, you're going to have a tough time keeping the upper hand on your detection approach. And what we have observed, and I actually wrote a series of blogs more than 10 years ago on that, that correlation is not enough. Correlation looks like a really good idea, but it's not enough. And you need advanced analytics in addition to correlation. It's not an either/or proposition, but correlation and below, right? In terms of sophistication of your analytics, pattern matching, greater or smaller than, and correlation are not enough. You likely need some type of ML. in order to help you with the understanding of the behavior. ML by itself is not enough. ML is not a silver bullet that solves all of your problems. At the same time, it is a very, very important detection engine in almost like detection in depth, which is a bunch of engines working in parallel in order to get you the best coverage that you need in the cloud.

So I do behavior detection in my products without using any ML. Do we need ML for behavior-based detection?

So if you don't use ML, chances are you are reinventing part of the ML basic techniques in order to do understanding of your behavior, in the sense that to understand behavior, you need to map all of these behaviors and understand what is normal and what is not normal. And when you do this type of learning over time, you are replicating essentially some of the functions that an ML engine But wait a second, before we go there, it still is kind of rules versus algorithms.

To me, this is like a bit of a hairsplitting debate. Is this ML or is this statistics? Because of course, we've seen all these jokes online about people who think that linear regression is a machine learning technique, right? So why can't we refocus back on does it use rules? Does it use models, algorithms, statistics, right? Why is there ML, not ML?

Well, see, I still think that's the wrong question.

Really? Okay, why not?

Well, see, this— I'm going to get on my soapbox for a second. For one second, say, I think you answered my question and validated my question, and that was the mistake. My question was a nonsense question. My question was equivalent to saying, do you use wrenches in your car factory?

Who cares?

It shouldn't matter that my factory uses wrenches. What matters is that it puts out cars that are safe to drive.

Yeah, no, I'm not sure I understand the analogy there.

ML is a particular set of techniques and it shouldn't matter how you get the job done as long as you get it done.

No, I agree. Fundamentally agree. However, at one point you do again need all of these detection engines that are working in collaboration, in conjunction, in order to get you the best coverage that you need for your detection.

See, that's where I disagree. I think how you get there doesn't matter. You just need the detection. And so I think ML is the pixie dust of security marketing. Still to this day.

I'm not sure you agree, Tim.

But, but, but, but we're getting towards time and I think Anton wants to ask the closing question.

I think this is kind of one of those defining discussions for our time. And I think that's why I tend to chicken out and say rule-based algorithmic. And I kind of avoid this debate. But I think Tim has a point is that there is a matter of like, is it really ML? Is it not really ML? And it becomes a rat hole pretty quickly as it just did, I think. So, our favorite closing question: one tip for detection response in the cloud and any recommended reading. By the way, Gorka, you can be as self-serving as you want. You can suggest, you know, 15 XebiaBIM blogs, and we are going to happily post them all on the blog. So this is kind of the recommended reading, ideally should be useful, but if it's what you want to have is what you want to have. That's our rules.

Yeah.

And so let me maybe bring this back to the tools are here only to support the processes and help the people that you have. People, process, technology. Now, this being said, there needs to be some pragmatic angle to the technology, and that technology needs to be cloud, in the cloud, for the cloud, be able to scale, have massive levels of bandwidth in order to absorb all the data that it needs. And then it needs to really think about the operationalization of the full TDRL lifecycle, right? It's about data collection, detection, triage, investigation, and response. And back to the detection, I think that the industry has over-pivoted on detection and response. That's kind of, you know, everybody likes to talk about detection and, yep, the methods and the algorithms and all of those and talk about the response. Let's not forget about the triage, and especially let's not forget about the investigation. That's really kind of where the SOC is spending a lot, if not the bulk of the time. It's on triage and investigation. So let's look at all of these and what's the best way to generate those insights. And yes, of course you need ML. Of course you need the UEBA and understand, you know, normal and abnormal behaviors. Of course you need to keep an eye on your credentials, your identities. And then the reading. Yes, in fact, MITRE just came out with a revised version of their SOC Bible, for lack of better terms. It's 400 really, really solid pages on how to build a SOC, how to operate a SOC, has a bunch of really cool nuggets on Cloud SOC, the team, the people, the technologies, the processes. And Anton, it reminds me a little bit the paper that you did at Gartner on how to build a SOC, and that they Really spent a lot of time expanding on all of these topics. It's very, very good reading. The latest version came last week or a couple of weeks ago. Highly recommend that reading.

Amazing.

Perfect.

Thank you very much.

And I think we should have a separate ML pillow fight next time because I think it's too much fun.

That works. Count me in.

Awesome.

Very cool.

Gorka, thank you for joining us. Really appreciate it.

Thank you for having me. Love your blog.

And now we are at time. Thank you very much for listening and of course for subscribing. You can find this podcast at Google Podcasts, Apple Podcasts, Spotify, or wherever else you get your podcasts. Also, you can find us at our website, cloud.withgoogle.com/cloudsecurity/podcast. Please subscribe so that you don't miss episodes. You can follow us on Twitter, twitter.com/cloudsecpodcast. Your hosts are also on Twitter @anton_chuvakin and @_timpego. Tweet at us, email us, argue with us, and if you like or hate what you hear, We can invite you to the next episode. See you on the next Cloud Security Podcast episode. Security.