EP53 Seven Years of SOAR: What's Next?

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, tamed, much nicer analyst now, an esteemed member of the cloud security team here at Google. 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 a 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 talks are and then tell us about SOAR?

Actually, Cloud Security Talks this time would be largely connected to security operations, threat detection and 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.

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

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

Please.

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 kind of had to hold my tongue and say, Ah, I can tell you, but—

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

We would allow him to run malicious cryptominers who malicious hackers would put on his instances. That makes sense, I guess, right?

Yeah, it makes sense. That's how life goes.

Research.

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

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.

No way. I thought they all worked that way.

No, no, of course. Well, when EDR or SIEM or others were created, it was sort of a concept built 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, and response.

What did it mean?

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 meaning for it.

That's amazing.

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 chasm. Maybe, maybe it's crossing the chasm already.

Got it. And with that, I'm delighted to introduce today's guest, Amos Stern, CEO of Simplify, 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?

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 the same direction.

Hopefully not at me though.

No, you can be neutral.

Oh, perfect.

Yeah, so it's 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 Realizing how SOAR is maybe a 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, so the eyeball real estate, This is really a place where the security operations and the SecOps, 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 7 years, the transition to the cloud accelerated significantly, Also, the SOAR systems adjusted to be both consumed from the cloud, but also to protect the cloud more.

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.

It's true, but just a lot of organizations had huge footprint on-prem and many different security systems. 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 2 years, is the acceleration of kind of remote distributed workforces driven by work from home.

Yeah.

If SOC originally was, and Anton talked about this a lot, was more like centralized, people sitting in a room 24/7 in dark rooms with screens, screens blinding 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 the security operation teams.

That makes sense. And I think to me, this is definitely showing 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 one of the first Gartner 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, marketing, selling this 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 7 years of trying to SOAR How did it work out? What did you learn?

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, assigned resources for it, just get more experience with the platform. But really, as we kind of went through building the system itself and 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 putting the data in. It's the ease of using the integrations. It's the ease of building the playbooks and the workflows. And 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 added more and more capabilities to 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 invent their own wheel, 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.

Yeah.

I think this was one of the things that was also making it more complicated. And as SOAR systems evolved, even services with SOAR evolved, it helped organizations implement the security operations processes. And 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 the 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 would make it much more difficult. So I think that's another thing that's evolved. Of course, features in the SOAR systems improve themselves, adding things like abstraction that you don't have to parse everything or 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 changed 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.

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 are 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?

I think it's fair, but it's a combination. It's customers matured. You reach a larger chunk of the audience because they mature, but also the technology lowered the barrier of entry a little bit downstream so that some organizations, and we see it a lot, that are much smaller, even like startups or tech organizations that are more savvy, 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.

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 SOARing? How do I start on the right foot?

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

It's a good question because everyone's fear with automation is to break something in the operation and 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 a lot of false positives, a lot of noise. Just focus maybe on the things that are first the 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, investigation rather than chasing different enrichment sources to validate a particular alert. So I'd say start with triage. As you gain 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.

That makes a ton of sense.

That makes sense. And to me, this is kind of interesting that the more— I guess I shouldn't say 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. You had some easy questions, but here's a tricky one.

I do have to say, sorry to cut you there, Anton, 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%. Right.

But not as first playbook, correct?

What do you mean?

Not as their first playbook. That was their 7th playbook rather than their first, right?

Of course. I'm surprised it only gets as high as 90%. I would guess with like a Pareto distribution of findings and events, you would end up well beyond 90%.

It's true. I'm conservative a little bit. We have actually some customers that's like 98%. That makes sense. Can be fully automated. So essentially, like, you don't really have like a tier 1 job to go through and triage individual alerts. They just go 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 enriched it with everything so that you can make a decision and not go and collect data.

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.

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

You're doing it wrong. That's pretty clear.

Yep.

That's exactly right. So we asked 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 task 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 Chefs and Puppets and whatever else is common nowadays. I'm not super current on 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 contested this 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 network management and many other things. So what's your take on this whole IT automation versus security automation?

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

A little bit, yes.

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 organizations 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 the SOAR needs to be a broader operations platform that you manage your operation in. And if you use a general-purpose IT automation tool, 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, SaaS 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 is used to automate a certain out-of-band process. It's in-band. Some of the process 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.

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

Well, don't we all?

For sure.

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

It's all positive optimism. Yes.

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?

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 3 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.

Yeah.

into the tool.

Mm-hmm.

But they're focused on a specific use case. Then you have what I call the full store platforms, like I mentioned before, comprehensive platforms that can run the entire operation, enterprise and MSSP grade, by the way, with like multi-tenancy 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, to 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-stack platforms. And 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. Mm-hmm.

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 the cloud.

Mm-hmm.

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 the response.

That makes a ton of sense. And I think that's actually a very nice nuanced answer on 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 users' 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 do you have like one weird tip to improve their SURE experience?

Recommended reading?

Yeah, a blog, a white paper, a book. Could be, you know, Anna Karenina for the range of discussion we get on this show.

Well, I haven't prepared with that.

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

One practical thing to start your SOAR experience and 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 Perfect.

Thank you very much. Quick wins was my favorite advice for SIEM deployments, and 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. It would be useful for the audience too. Thank you.

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

Very happy to. It's been a pleasure, guys.

Awesome.

Thank you.

And now we are at 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 will be in the episode resources. You can find this podcast at Google Podcasts, Apple Podcasts, Spotify, or wherever 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 we 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.

Security.