EP53 Seven Years of SOAR: What's Next?

Timothy: 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, tamed, much nicer analyst now and esteemed member of the 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 on your app of choice. You can follow the show and argue with us on Twitter as well. twitter.com/cloudsecpodcast. Anton, we are talking about SOAR, which is a topic you've had opinions on in the past, and I'm sure will in the future as well, but we're also excited to share that we have our cloud security talks coming up very soon. Why don't you tell us what the talk and then tell us about SOAR?

Anton: Actually cloud security talks this time would be largely connected to security, operations, threat detection response, SIEM, SOAR, cloud threat detection. So it's not just one of our quarterly talks. It's actually focused on an area I'm very passionate about and of course, super excited about. So that would be fun.

Timothy: I'm excited and passionate about too. I recorded my session yesterday where I'm talking about virtual machine threat detection and a lot of the excitement we're doing with that. Have you heard what we're doing there?

Anton: Of course, with the MTD, that's quite magical. Here's the funny story about that.

Timothy: Please.

Anton: Somebody reached out to me who was trying to run honeypots in Google Cloud, and they said, "Somebody is killing my crypto miners that infect my honeypots." I kinda had to hold my tongue and say, "Ah, I can tell you, but..."

Timothy: Oh, that's hilarious. He should get in contact with his account team and we can get his projects allow listed.

Anton: We would allow him to run malicious crypto miners who malicious hackers would put on his instances. That makes sense, I guess. Right?

Timothy: Yeah. That makes sense. That's how life goes.

Anton: Research.

Timothy: So today's topic though is SOAR. What is SOAR? Are we going like paragliding, what's the story?

Anton: I can tell you a funny story about SOAR as well. SOAR is one of the few Gartner terms where the acronym was coined before the meaning.

Timothy: No way. I thought they all worked that way.

Anton: No, no. Of course. Well, when EDR, or SIEM, or others were created there was sort of a concept to build first and then a suitable acronym was found. For SOAR, suitable acronym was found first, and then the term appeared. Which is in fact really interesting because the first time SOAR meant something else. It did not mean security orchestration automation response.

Timothy: What did it mean?

Anton: Actually, I forgot the old one. The 2015 SOAR had something else, but then it became the current SOAR and then it soared. So finally we analysts, well, at the time we found the right meaningfully.

Timothy: That's amazing.

Anton: Today, it's an exciting technology. It's a technology that's getting wider and wider deployments. And to me, this is definitely fascinating because we see SOAR sort of get to cross the CASM* maybe, maybe it's crossing the CASM already.

Timothy: Got it. And with that, I'm delighted to introduce today's guest Amos Stern, CEO of Siemplify, now part of Google Cloud. Amos, we've got SOAR in the news again. So what can we say about the state of SOAR in 2022? I've been hearing about SOAR, it feels like a long time now, where is it in its journey?

Amos: Great to be here. Thanks, Timothy and Anton. I've been chasing Anton for quite some time, so happy to finally get on the Cloud Podcast and have some time to debate and shoot some arrows at each other, hopefully in the same direction.

Timothy: Hopefully not at me though.

Amos: No. You can be neutral.

Timothy: No. Perfect.

Amos: Yeah. So I've been in the news recently. Of course, the first thing that probably we can address the elephant in the room and talk about some of the consolidation. I think a lot of the companies that are building more security kind of platforms are realizing how so is maybe more key component, you know, in bringing all of these different disparate pieces of the puzzle together.

There are many different security systems. They're all focused on some other elements of security, but they're not really working together. Especially for the platform players that are building multiple capabilities, this ties everything together. So it makes a lot of sense and it really is a central place for the security operations, which I think is when you look at the real estate or the eyeball real estate, this is really a place where the security operations and the, you know, the security team is coming to.

So I think it's a key component in your security strategy. And maybe another part of the changes in the landscape is the transition to more cloud native approaches. I think traditionally also, SOAR were very like focused both on delivery on-prem but also solving on-prem use cases. And as in the last, maybe seven years, the transition to the cloud accelerated significantly. Also the source systems adjusted to be both consumed from the cloud, but also to protect the cloud more.

Timothy: So like everything we're seeing a shift to the cloud that makes a ton of sense. Cloud feels like such an obvious place for SOAR given that the whole thing is API-driven in the first place.

Amos: It's true, but just a lot of organizations had huge footprint on-prem and many different security systems. And you have this kind of hybrid solution situation where you have some of your infrastructure on-prem, and some of your security systems on-prem. At the same time, you have some of your infrastructure in the cloud and some of your security systems in the cloud. How do you bridge that gap and provide visibility and consistent workflows?

And also another change maybe is that, especially in the last two years, is the acceleration of kind of remote distributed workforces, you know, driven by work from home. If SOAR originally was, and you know, Anton talked about this a lot, was more like centralized, you know, people sitting in the room 24/7 in dark rooms with screens lining their eyes. It's not really the case so much, you know.

It's very distributed, very geographically spread and also needs to include not just the local teams and the remote teams, but also service providers that can collaborate, you know, together with security operation teams.

Anton: That makes sense. And I think to me, this is definitely to show in the evolution of the technology over some number of years. Which kind of reminds me of my analyst days, right? When I was writing the, I think when they first got the papers on SOAR, I did say quote that adoption somewhat faces headwinds.

Because I've seen organizations that struggled with processes. So they couldn't automate what they didn't have and there were other challenges. You've lived through all this building, creating, developing market and selling the SOAR tool. So what have we learned trying to get SOAR adopted in your history? And the history, I think goes from 2015 to, well, today. So seven years of trying to SOAR, how did it work out? What did you learn?

Amos: I see what you did there. Good question. I think first of all is, the platforms themselves obviously evolved. And this is a new technology. As always, as you go to enterprise, it goes through some process where you need to get used to it, have defined projects for it, assign resources for it, just get more experience with the platform.

But really, as we kind of went through building the system itself and the product, we did notice that it's more difficult of course, to deploy at the beginning and to get things operational. And we spent, I would say years in figuring out how to accelerate what we call time to value. Which basically materializes in many areas of the product.

It's the ease of pulling the data in, it's the ease of using the integrations, it's the ease of building the playbooks and the workflows. It's essentially getting the system integrated and starting to see value from it and starting to run different use cases as fast as possible, where you don't necessarily need to rely on only engineers. And you can slowly really at first at the beginning source. And I think this is also why there was more headwinds, these were new systems.

They were of course, designed first to help engineer the process and then slowly add more and more capabilities to simplify, pun intended, the process of implementing this. Because really the security operations, I think through the journey that it walked with SOAR moved from like being really clunky and every organization would vendor their own will, processes were broken, there was no automation.

So you didn't just have to implement a platform, you also have to implement a process for the operation. I think this was one of the things that was also making it more complicated. And as SOAR systems evolved, even services with source evolved, it helped organizations implement these security operations processes. And you really think about it like sales, for example. When you deploy a system like Salesforce, usually you don't invent the wheel on how to run a sales operation, like you have a sense, these are the stages of an opportunity.

This is a data that you need to capture, this is the KPIs that you measure. Imagine having to deploy Salesforce in a large enterprise having no idea of how to run the sales operation. That will make it much more difficult. So I think it's another thing that evolved. Of course, features in the SOARs systems improve themselves, you know, adding things like abstraction that you don't have to like parse everything or like nesting of playbooks or adding things like simulation modes, where you can quickly test things.

And it takes significantly less time to build content. And then adding more, I call it enterprise grade capabilities like monitoring playbooks. Where do actions fall, where do you need to focus to improve, curated communities and content, so you don't have to build everything from scratch? SaaS is also something that change that you can really quickly access a platform, deploy it, start using it literally in minutes. And I think all of those things are significantly reducing the headwinds and we see deployments happening much faster these days.

Anton: But it sounds like customers growing up is a sizable chunk of that, right? Like the fact that whoever was trying to deal with SOAR in 2014 faced either a tiny sliver of elite customers who can code everything or customers who were incredibly mature in their security operations. And frankly, nobody else. Today, we have customers who kind of grew up. So the technology improved, but customers also improved. Is that fair?

Amos: I think it's fair, but it's a combination. It's customers matured. You reach a larger chunk of the audience because they matured. But also the technology lowered the barrier of entry a little bit downstream so that some organizations, and we see it a lot that much smaller, you know, even like startups or tech organizations that are more savvy that not necessarily like large organizations can access SOAR with SaaS and out of the box content much more easily use it, even if they don't have huge teams.

Timothy: On the topic of migrating to SOAR and adopting SOAR and why that's getting easier for organizations, I'm curious because, you know, we've had a lot of conversations about migration on this podcast. Some about to the cloud, some about to zero trust. And people have said, you know, start with something critical or start with something that nobody will notice. When it comes to like your first SOAR playbook, what's my hello world of SOAR-ing. How do I start on the right foot?

Anton: And don't quote from my Gartner white paper on this, because this would be cheating. I had a list of top three use cases back in 2019.

Amos: It's a good question because everyone's fear with automation is to, you know, break something, you know, in the operation and like business critical. So where you need to start is also where you can start building more confidence in the process. And that's really simple things like codifying the processes, even if you don't automate them at first, at least the main ones, just so you have consistency and you can be confident in, you know, these are the steps and these are the stages that you want to happen for particular types of alerts.

But then the next thing after that is things like enrichment, triage of different alerts, validation to kind of weed out false positives and not necessarily block anything or, you know, delete anything or take down any machine automatically, but add confidence and prioritize threats rather than mitigate them. Slowly, this helps you weed out all the false positives, there's a lot of noise.

Just focus maybe on the things that are first, most noisy types of alerts that you know that there's a lot of manual operation to investigate them. Automate as much as you can from that, that would typically be like 80% of the alerts so that the team can then spend their time doing more high level work and, you know, investigational rather than chasing different enrichment sources to validate a particularly alert.

So I'd say start with triage, as you get confidence, you can add manual approval steps for more critical decision points, you know, and do them manually. And if you feel confident after some time that this is the right decision path, and this is something that the machine can do, then you can add that as well. Or offload it to an end user and even do things like send a slack message or a text message and have the user respond. And based on that, continue the automation

Timothy: That makes ton of sense.

Anton: That makes sense. And to me, this is kind of interesting that the more, I guess, make sure they stay passive, but kind of more enrichment and more advising humans, playbooks rather than full auto. That's pretty much what we've observed back in the day. So you had some easy questions, but here's a tricky one.

Amos: I'd like to say that the story to catch you there, Anton, on that, when you identify some of the more noisy kind of alerts, things that you can't stop sending to your SIEM or wherever you're managing your SOAR but you need to weed out the false positives and triage. But we actually have customers that fully automate something like 90%,

Anton: Right. But not as first playbook. Correct?

Amos: What do you mean?

Anton: Not as their first playbook, that was their seventh playbook rather than their first, right?

Am Of course.

Timothy: I'm surprised it only gets to size 90%. I would guess with like a parade or distribution of findings and events, you would end up well beyond 90%.

Amos: It's true. I'm conservative a little bit. We have actually some customers that's like 98%...

Timothy: That makes sense.

Amos: …fully automated. So essentially, like, you don't really have like a tier one job to go through and triage individual alerts. It just goes straight to a person to evaluate, you know, in a case where once the alert is getting to be seen by a person, you already did whatever you can do. Either you close it or you enrich it with everything so that you can make a decision and not go and collect data.

Timothy: Yeah. Amos, I don't know if you've hung out much with Google's internal security folk yet, but our internal team, they won't look at things unless they've been automated. Like the bar for an analyst at Google looks at an event to investigate is it was first touched by automation. They won't consume it without automation.

Amos: I think that has to be the end goal. That has to be the mindset. If you need to do something repetitively or manually before you look at it, like...

Anton: You're doing it wrong. That's pretty clear. That's exactly right. So we ask you some easy questions, but here's the really tricky one. And the reason I'm asking this question is that while I was at Gartner, I tried to figure out an answer to this question and I couldn't. So why don't I just ask you with this?

When I was an analyst, I've explored the links between SOAR as a security automation and all those general IT automation platforms that are common in DevOps, all those chats and puppets and whatever else is common nowadays, I'm not super current in this. And we never quite figured out why security had to create its own automation. It made sense to me as a security guy, no debate here.

But there are some people who kind of tested it and said, "No, no, no, no, no, SOAR shouldn't exist, IT automation tools should do security." Is this silly? Intuitively it feels silly because many other IT tools just couldn't work in security and security had to invent SIEM rather than, you know, network management and many other things. So what's your take on this whole IT automation versus security automation?

Amos: This is a very interesting question. And it's not fair that you haven't solved it and you're throwing it at me. But...

Anton: A little bit. Yes.

Amos: I have some strong opinions about this. First, I think that you can automate some processes, right, with general purpose IT automation tools, but there are major gaps that I think is the reason why eventually your organization didn't go and do that. One is that I believe personally, that SOAR is a little bit broader than just the automation itself.

You know, many SOAR systems have different DNAs. Some of them are more, you know, let's just focus on the automation and automate some processes. Some of them are more, you know, case management or workflows. Some of them are more coming from a threat Intel perspective. I think that SOAR needs to be a broader operations platform that you manage your operation in.

And if you use a general purpose IT automation, you're really automating, like, what I call out of band automations. You send things outside, you automate something and you get a response and you manage it I don't know where, somewhere. And it's not really like your main place that you manage the operation. I think that first of all, SOARs needs to be, and one of the reasons why they're more successful is because they're a full operations platform and not just an automation tool that's is used to automate a certain out-of-band process, it's in-band.

Some of the processes you can't fully automate, like we said before, so you need to have it in a place where you can then present the data in a way that's easy for an analyst to consume and to make a decision. And so if it's just some outside system that just sends me some JSON back and you know, some data back, what do I do with it, how do I present it, how do I tie it into the automation?

And then add to that, that it's typically some other person in some other group in the organization, you know, and it's large enterprises. And so, you know, you need to rely on some different group, probably reporting to a different structure that maybe will create some automation for you. How will they maintain it? Do they even understand security? You know, that's another problem.

Timothy: So this gets back to what I'm always saying about security teams needing a therapist, not another piece of technology.

Amos: Well, don't we all?

Timothy: For sure.

Anton: Something positive, please. Consolidation, future of SIEM. Let's go for something optimistic.

Amos: It's all positive optimism. Yes.

Timothy: I want to pick on SOAR a little bit here because Anton just did it and it looked fun. We've seen a lot of consolidation in this market. And a long time ago, I worked at a company where people said, what we're building, actually it was a Gartner analyst who told us this, told us what we're building is a feature, not a product. Does the level of consolidation here and getting gobbled into SIEMs mean that SOAR isn't really a product in its own right and it's just a feature. What's your take on whether SOAR is a product or a feature?

Amos: Let's start with the fact that I think there are multiple types of SOARS. We used to be using this broad term to kind of capture a lot, it's a wide net, but I see a few, maybe we can even categorize them in like three general kind of categories. One is like a SOAR feature, maybe more similar to what you said. Some basic automation capabilities that you receive out of a larger tool.

Maybe a certain tool that's focusing on a particular endpoint security, or network security, or cloud security, or whatever that has inherent automation capabilities. Because obviously customers are asking for certain automations for detections that you have. So you build them in, into the tool. But they're focused on a specific use case.

Then you have what I call the full SOAR platforms like I mentioned before, a comprehensive platform that can run the entire operation, enterprise, and MSSP grade by the way, with like multi-tendency and so on, case management, workflows, collaboration, playbooks, versioning, monitoring of playbooks, library of content, diverse set of integrations, which is by the way one of the things, Anton, your previous question.

Also, if it's a general IT, like how broad and how deep are the security integrations that you need, or would you start building them yourselves? So I think these are like actual full SOAR platforms. And then of course, some of them are more general IT, but also like general purpose IT automation workflow builders that some of them have more security focus.

More generic, typically not security focus, but really looking at pure automation. And that's what I called before like an out-of-band automation tool. So to your question, if it's going to all consolidate, there's still going to be these different tools that are just going to be owned by different providers.

And I think one of the things that Google is a good fit because first of all, it ties well to cloud. It's still a full platform, so it provides everything that the security operation needs from end to end. And it can tie to the detections, you know, from Chronicle, SCC, and really take you all the way from the detection to their response.

Timothy: That makes a ton of sense. And I think that's actually a very nice nuanced answer around the different kinds of automation platforms. And, you know, thinking about internal security again, they actually have more than one automation tool for the same team.

So I can totally see how in user's minds those different distinctions end up being super valid. We're just about at time. I want to ask you our traditional closing questions. We hate to leave our listeners empty handed. Do you have recommended reading for our users? And you have like one weird tip to improve their SOAR experience?

Amos: Recommended reading?

Timothy: Yeah. A blog, a white paper, a book could be, you know, an incline* for the range of discussion we get on the show.

Amos: Well, I haven't prepared with that.

Anton: Siemplify blog is decent region, I think at some point it'll become Google Cloud blog and you know, may or may not continue to be decent region, but that's a separate story. So what about the tip? What about one practical thing to improve a SOAR experience?

Amos: One practical thing to start your SOAR experience in SOAR journey, I think like I mentioned before is start first with the quick wins. I would say, you know, find what are the things that you do manually the most, and that are the most noisy in your organization. And you can show the value really quickly to the security organization if you focus on those and then slowly build your confidence in.

Anton: Perfect. Thank you very much. Quick wins was my favorite advice for SIEM deployment and then it sounds like SOAR follows the same pattern here. So Amos, thank you very much for being on the podcast. We would really appreciate it. It was fun, would be useful for the audience too. Thank you.

Timothy: And I suspect we have enough to talk about that. We'll bring you back in the future.

Amos: Very happy too. Been a pleasure guys.

Timothy: Awesome. Thank you.

Anton: And now we are time. Thank you very much for listening. And of course, for subscribing. We hope to see you at our next Cloud Security Talks. The link we will be in the episode resources. You can find this podcast at Google Podcast, Apple Podcast, Spotify, or whatever else you get your podcasts. Also, you can find us on our website, cloud.withgoogle.com/cloudsecurity/podcast.

Please subscribe so that you don't miss episodes. You can follow us on Twitter as well, twitter.com/cloudsecpodcast. And your hosts are also on Twitter @anton_chuvakin, and @_timpeacock. 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 Talks, our virtual event and of course on our next cloud security podcast episode. You can find the link to the Cloud Security Talks in resources.