EP77 Operational Realities of SOAR: Automate and/or Enrich, Playbooks, Magic

Security.

Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here, as ever, 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. Finally, you can follow the show and argue with your hosts on Twitter as well, twitter.com/cloudsecpodcast. Anton, we've got another high-flying episode about our perennial favorite, SOR today. What are we saying today?

Indeed. And in this case, it wouldn't be a SOR vendor like last time. Of course, it's a vendor we happen to own now, last time. But the idea is that SOAR is exciting. SOAR is fun. But when people implement it, there are all sorts of challenges. There are all sorts of promises, sometimes by the vendors, that you can SOAR without coding and automation will just magically work. And in general, SOAR is kind of fun because it rides on a theme of automation in security operations. Yet it's the challenging domain for many SOCs, at least in my experience.

I think that sounds right. I mean, it's the interesting question of how do we do toil reduction without creating new different kinds of toil? I also really love this episode because we engage once again with one of our favorite deep questions about SOCs, which is, do SOC people need to know how to code?

To succeed, correct. That came up quite a few times. Yes. And, and of course, the answer is it depends, but there will be more fun than that during the episode.

So perhaps with that, it depends. Let's welcome today's guest. I'm delighted to introduce today's guest. We're joined today by Cyrus Robinson, SOC Director and Incident Response Team Lead at Ingalls Information Security. Cyrus, I want to talk about SOAR today, and I understand you've been using SOAR tools for years. So what do you think about SOAR?

Love what SOAR brings to the table for SOC teams. I think that some of the challenges that most SOCs probably face, especially as they begin to scale their operations, is with increased complexity and noise within their tool stacks and log sources. I also think that this is where the capabilities of SOAR technologies really come to bear. And as SecOps teams begin to build out their cyber resiliency, SOAR is the game changer for noise reduction, equipping analysts to understand and respond to security events, and improving visibility across the growing tool stack, all, you know, while working together to reduce human error.

By the way, as a funny aside, we never explained what SOAR is because we sort of assumed.

Yeah. What's SOAR?

It's a useful reminder. A useful reminder. Security orchestration automation. Yeah, but what does that mean in practice?

What is it actually? I know what it stands for. What is it actually, Cyrus?

You know, I think that what it is is a way to improve visibility across a lot of different sources of alerts and information and logs and to automate the processes involved in responding to and analyzing those. It's kind of there in the acronym, but I think really it's about creating efficient processes for security teams?

So this is actually a good one because one topic that came up back in my analyst years is that there was a whole chicken and egg about SOAR. You have processes, then you buy SOAR and you automate them, or maybe you don't have good processes, you buy SOAR, and you try to create processes in parallel with SOAR adoption. Do you have a particular preference, or do you think both can work?

Yeah, so I think that it depends on the organization and their capabilities and their maturity, right? And so I think that for a lot of organizations, having some processes in place already is where you're going to start at. And then you add capabilities and tools, including things like SOAR, to your tool stack as you begin to mature as an organization.

So wait, so that means that you can start with very immature processes, deploy a SOAR tool, and then Kind of grow the processes, right?

Right, absolutely. Security operations doesn't require SOAR, you know, every single context or organization. It's a tool that can be leveraged to improve your capabilities in existing processes.

I think that's a compelling answer right there, is it's not really a chicken and egg problem because we've had chickens for decades before we started selling eggs.

Yeah. Okay.

We had security operations centers maturing their process for a long time before we had SOAR tools.

Now, what you're doing in the SOAR platforms, I think that those processes can exist already with, you know, before you implement SOAR. It's just going to be a lot more work, a lot more noise to try to work through. And that's, again, where these capabilities help SOCs improve efficiency.

That makes sense. I think we pursued the chicken and egg metaphor far enough, but I think I agree with Cyrus's take is that I've seen people succeed down both paths. Deep in my heart, I prefer people to have robust processes before they implement SOAR, but I've also seen examples where they did not have robust processes in their SOC, and they grew them alongside the SOAR tool. So I think I'll go with that. So going back to my experience as a technology analyst, when I first heard of SOAR, and of course the acronym was created inside Gartner a good number of years ago, I kind of thought, Wait a second, we could have had this technology years ago, but ultimately, SOAR was only born, let's say, 5, 7 years ago, and the large-scale adoption of SOAR is ongoing today. So, I want to explore and ask Cyrus, like, what's driving SOAR adoption today? And perhaps there are still inhibitors to that, right? And not everybody has acquired a SOAR. So, what's driving and what's slowing down SOAR, in your opinion?

You know, I think that as organizations do begin to mature and improve their security operations capabilities, they generally begin to deploy more and more security tools. The purpose here is to provide additional layers of protection or visibility. And, you know, one of the aspects of these efforts that is often overlooked is that even with the best security tools available, they're only going to be as effective as the people and processes that are interpreting the output from these tools. And so as more and more layers get added to the tool stack, the complexity and expertise required to maintain and use all of these tools increases, and so do the number of logs. And so I think that what drives SOAR adoption is finding solutions that enable organizations to reduce their analyst workload, to standardize how they do their analysis, to reduce false positives, basically to automate as much of the process of analysis as possible, and to do all of this while they're improving their visibility across the enterprise with more and more tools and data sources.

There's an interesting theme emerging in these answers around reducing toil, and it makes a lot of sense to start with reducing toil because then you have more cycles available to go make everything else better. So when it comes to making it Hard to operationalize SOAR. What things get in the way of initial efforts at reducing toil? Is it just complicated technically? Like, what makes this hard at a typical company to get right?

By the way, Tim, sorry for interrupting. Like, I wrote this question, but I'm now realizing the question assumes that SOAR is hard.

Oh, is it hard?

It's my brain bias, I think, went into this. So maybe I now suddenly feel like asking a more open-ended question. in place of that question that we wrote. So how easy is SOAR to operationalize at a typical company?

All right, so how easy is it to operationalize?

How easy, hard? Hard, easy?

Sure.

How is it?

So I think that it depends a lot on the organization, right? So SOAR, it's a tool that security teams, enterprises, and service providers that they can use to help prioritize and respond to what matters, right? But honestly, this assumes a basic level of maturity for that organization. I would say that it is definitely challenging to implement any new technology, and that's true for SOAR as well. You know, I've been involved in, you know, a few different types of SOAR deployments and transitions. And I can say that, you know, with my most recent SOAR platform transition, you know, we implemented SimpliFi a few years ago. This was the first one that I was a part of from the very beginning of the process. And basically my SOC engineers worked with SimpliFi's team and got everything stood up and got everything ready and then handed me the keys and said, okay, go. And I was like, well, what do I do with this? And we didn't have the playbooks moved over yet and built there. We didn't have the use cases well-defined there. And so it was intimidating at first. But I'll say that, you know, basically what I did was I dove into it and I was surprised at how easy it was to, you know, build the integrations and the playbooks and the use cases from scratch.

That's kind of surprising to me to hear that it was easy. I would've guessed that this was hard and I didn't question Anton's assumption baked into his question, which, you know, shame on me.

I wouldn't say it's easier or easy. I would say that it's easier than I thought it would be, right? So the challenges here, You know, again, there's a certain maturity level that is required to truly operationalize SOAR, right? In order to succeed with SOAR, you have to have the right people and processes and tools that are required to support the platform just to get started, right? And so, you know, I have a great engineering team that was able to help me with, you know, all of my questions and figuring things out, but you have to have The people who are responsible for supporting your networks, servers, infrastructure. You have to have someone like a SOC engineer who is responsible for integrating and tuning the security tools, the log sources, the playbooks in the SOAR platform itself. You have to have the people that will be using the SOAR platform, your SOC analyst. And then you have to have the tools, right? You have to have the security tools that are going to be sending alerts to the platform in the first place. And the ability to respond to those alerts. And so there are some challenges here. And again, I wouldn't say it's easy. I'm just saying that it was much easier than I expected it to be walking into it.

And I think I'll go with that. And I think this is actually kind of— I'm happy that we tweaked the question a little bit because I think the whole how hard just sends people down the challenges path. And in this case, Cyrus really revealed some of the insights from his experiences. I kind of liked that. I felt like it was a good use of our Good use of our time to rephrase it. So I want to go to a few more practical things. And again, referring back to my former analyst career, we tried to identify favorite SOAR playbooks to start. And of course, phishing was, of course, many vendors' and many end users' favorite playbook type. So Cyrus, in your experience with SOAR in the field, what are your favorite playbooks to start with if you're starting a client?

So my favorite Playbook to start with is a malware quarantine playbook. I think it's a great, easy place to start. I actually just today shared with my analysts just kind of a challenge for them to begin thinking through how playbooks are developed and how we can improve our processes and challenge my analysts to say, okay, I want you all to start with a quarantine using, you know, one of our security tools, one of our AV platforms. And I want you to walk through your best-case scenario, a playbook for how you think that that should be analyzed and responded to. And, you know, don't just follow the playbooks that we have. You know, make this your dream playbook. What tools or integrations do you want to have in there? I think it's a lot of fun. It's a good place to start. But the way that we kind of break our playbooks down is we have playbooks that are more general that come first. And so what I mean by that is, Almost every single one of my playbooks, whether it's an IDS alert or, you know, phishing email or malware quarantine, every single one of them begins with noise reduction and tuning. And so honestly, our noise reduction and tuning playbooks, I think that those are probably the most important playbooks to begin with building out a SOAR playbook.

So wait a second. So noise reduction implies that once you reduce the noise, you hand it to a human. So you are not in the starter playbooks, you are not looking to resolve an issue. You're looking to reduce the noise so a human can make the right call. Am I right about it?

Eventually, yes. So we have a lot of playbooks that don't actually require human interaction for them. But even for those, those are kind of filtered out in the noise reduction, as well, right? So we do have SOC analysts who are working through playbooks. And so we're not, you know, 100% automated on every single thing. A human in the loop, so to speak. But, you know, before any playbook reaches any of my analysts, it's going to go through the noise reduction first to eliminate, you know, duplicate alerts. It's going to go through the playbooks to look and see, okay, is this something that we've already made a determination that this is malicious or a false positive? And so I know that my analysts don't need to see it, things like that, to basically reduce their workload.

That makes sense. And I think to me, this is a good answer because I've met enough kind of people with the excessive amount of excitement that SOAR would basically automatically fix their issues. And I've seen it happen for a certain sliver of issues, but I don't think it's a good overall goal that your SOC would not have any people in 5 years because you have SOAR. I think that's a crazy goal.

So speaking of people, I want to spend some time picking at the people that make a SOAR successful. And in particular, Cyrus, I don't know if you listen to the show or not, but I want to warn you that this question has gotten different answers over the episodes. Do the people who work on the SOAR and in your SOC need to be able to code in order to be successful?

So I'm going to try to break this question down a little bit into 2 different groups, the SOC analysts and SOC engineers. And for SOC analysts, I would say actually they don't really need to know how to code to succeed.

Hmm.

When, when it comes to using SOAR platforms and, and working in them, you know, the, the ability to critically think is, you know, absolutely a fundamental necessity and, and has a lot of parallels with being able to code. And coding experience I think is useful for plenty of SOC roles and including some analyst roles. And, but it's, it's not actually usually a critical capability for most SOC analysts working within SOAR. And now that might not be super surprising. But surprisingly for SOC engineers, even, I think that for SOAR coding is not as important as people might think that it is, which you'd think, well, they're engineers, so of course they need to know how to code. And obviously there are aspects of that role that do involve coding. But this is another area where I feel like many SOAR platforms and especially from our experience with Simplify, where SOAR platforms really shine. Generally speaking, a robust SOAR platform, it's going to minimize the amount of coding that's required, at least for hitting the ground running, you know, getting the basic functionality and use cases in place. So for many SOAR platforms, you know, building a playbook, for instance, it relies on, you know, implementing integrations that have already been built, you know, either by the company or by the community. And that leaves honestly very little room for coding required for a SOAR SOC engineer for the basic use cases. And so, you know, instead of a SOC engineer sitting down and writing lines of code to build playbooks or to tune things or to, you know, implement integrations, it usually involves arranging a group of actions or steps that you sort of drag and drop in a way that makes sense for your process. And so it's definitely an exercise in critical thinking and problem solving. And it's almost a graphical, you know, pseudocode type of language. But, you know, most SOAR platforms don't actually require, you know, actual programming language expertise to build the playbooks or to get the basic initial functionality.

To build some playbooks, right? To build some playbooks, presumably some other playbooks you do need to get out to the Python and to To the what's under the hood, right?

And so that is also where, where like things like custom integrations and working with the IDE and things like that really come in handy. And so, yeah, once you get to that level, yeah, there is definitely a need for the ability to code and understand APIs. You know, Python is usually the backend of most of these tools. And so there is some programming expertise that's needed once you get past the initial use cases. Okay.

Perfect. No, that makes sense. And I think that— I don't think you kind of fudged the answer, but I think that you gave us a nuanced answer about if you're just looking at the screen and maybe tweaking playbooks and using SOAR as an analyst, you don't need to code. It's obviously not required. But if you are trying to build fairly elaborate playbooks that go beyond what the vendor shipped, it would probably be helpful, right? That's your answer.

Right. Now, I mean, honestly, a SOC engineer needs to know how to code. But it's not as much as you might think that it would be to implement and use the tools.

Correct. Correct. Yeah.

I think that's a great answer. And I actually think our guests who've disagreed about the point of do you need to know how to code in a SOC would agree with you both.

That's fair. Yeah, I think so. So I wanted to switch gears a little bit and kind of think about this SOAR adoption journey in a client. So we wanted to ask about sort of like an implementation road from start into scaling, but I want to rephrase it a little bit in the form of a maturity journey. I am a bit of a nut in terms of the maturity models. I feel like if there's no maturity model for something, then there's a gap.

Mm-hmm.

And so for SOAR, people just acquire a tool, do simple playbooks, maybe do some enrichment. And I almost feel like there's some kind of a natural adoption curve for many clients. So what's your opinion on this? That's question one. And together, maybe just walk us through a typical SOAR journey at the client from the very start Sure.

So I'm a big fan of maturity models as well. I think that they are a great way for an organization to have an honest look at what their capabilities are, where their gaps are, and to find ways to fix those. I'm not aware of any SOAR-specific maturity models that exist, but I think that there is definitely a lot of room for that in the security operations field. I think that we can have a lot of value from understanding like, here's where an organization can start and here are, you know, some of their gaps, places where they need to improve. Basically, you know, something similar to like the, you know, a SOC cyber maturity model and NIST CSF, right? Yeah. Having, having it applied to a specific tool or capability platform. And then as far as, you know, implementing SOAR, what that journey looks like, you know, I think that there's a lot of value and this kind of speaks to, you know, having a maturity model and working your way up, but basically in having easily digestible chunks and then making iterative improvements from there. So, you know, for starters, what this looks like in practice is the organization needs to do their homework before they implement anything. They need to spend time, you know, test driving demos or looking at what those look like before, you know, making a decision on which platform they want to go with or how they want to deploy it. So for example, with Simplify before going out and purchasing an entire SOAR platform. You can use the community version for free as a proof of concept. In fact, they, I saw that they just released their cloud-hosted community version yesterday, and I shared that with my analysts and engineers as well. But yeah, spend some time digging into the product, making sure that it fits your use case, and then begin by ensuring that you have the infrastructure in place and that you have the capacity to scale as your organization grows or as your client base grows. And so, you know, this includes obviously having the infrastructure to support not only your SOAR platform, whether it's cloud-hosted or self-hosted, but also the infrastructure for your tools and your log collection infrastructure. You know, if you have a fairly static footprint, this can probably be accomplished internally, self-hosted, but As soon as your requirements begin to include the ability to quickly and easily add capacity, honestly, this just becomes much easier to accomplish using cloud-hosted resources. And then obviously having redundancy and basic business continuity practices are important here as well. And so then once you've done your homework, you've determined your use cases that can be supported, you've verified that your infrastructure is capable of sustaining your operations and your projected growth, then you can begin with the deployment of actually, you know, codifying some simple use cases to get started. And then from there, making iterative improvements as your team and your processes mature.

Well, that makes a ton of sense to me, especially on the scalability of cloud resources front. I want to wrap up with our usual 2 closing questions. First, We hate to leave audiences empty-handed. So do you have recommended reading for people to learn more about SOAR? And then 2, do you have one tip to help people get more out of their SOAR?

And hopefully it's not buy a tip because I think SOAR is enough for now. Sure, sure.

So I hate to be the teacher's pet here, but I think that probably a really interesting place to start for looking into SOAR and maybe some other security tools and how they relate to one another is look at Anton's Medium blogs on And some of the ones that I thought were the most entertaining were the SOAR and XDR blogs.

You know, we've been meaning to ask you a question about relationship between SOAR and XDR, but we skipped it. Maybe that was our mistake.

So you're asking about the relationship between those 2?

Yeah, between SOAR and XDR. Yeah.

Well, I think that, you know, XDR is largely a marketing buzzword at this point. There's not unanimous consent about what it actually is. However, I don't think that that means that products which label themselves as XDR are bad products, right? In fact, I think that there's tremendous potential to improve security operations by enhancing and expanding capabilities, visibility, and feature sets of existing platforms and EDR. And so I do think that the conversation about whether this or that XDR platform is going to replace this or that SOAR or SIEM platform. For me, I tend to think that these tools, they serve unique functions and that instead of being competing technologies, that we should see them as complementary technologies, XDR or EDR with additional capabilities, whether that's native or via integrations or however that's accomplished. It's a great opportunity, right, for security teams to improve their capabilities, but SIEM is important for meeting requirements to collect logs from various sources, and SOAR basically helps you build your processes and workflows and to automate as much of that as possible around it.

That makes sense. And I think we did cover the recommended ingredients. So any one tip on how to succeed with SOAR quickly?

Dive into it, have fun. I recommend using the simplified community version to see what it looks like yourself before implementing something like this.

Perfect. Thank you very much for answering the questions. I appreciate, of course, appreciate the links, pointer to the Medium and all that, but also mostly appreciate your advice and experiences with growing SORA in the field. So, thank you very much for being on the podcast.

Thank you guys so much. Appreciate it.

And now we are at time. Thank you very much for listening and, of course, for subscribing. You can find this podcast at Google Podcasts, Apple Podcasts, Spotify, or wherever else you get your podcasts. Also, you can find us at our website, cloud.withgoogle.com/cloudsecurity/podcast. Please subscribe so that you don't miss episodes. You can follow us on Twitter, twitter.com/cloudsecpodcast. Your hosts are also on Twitter at Anton_Chuvaikin and _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.

Secure running. Secure running.