The state of SOAR solutions – an exciting discussion

As most of you probably know, the 2021 Virtual Security Operation Center Summit Budapest took place between March 18 and 19 in the digital space with participants from all around the world joining in from the comfort of their homes. As unusual as the set-up was, the two-day virtual event proved to be a great success giving a platform for several exciting and extremely informative discussions. SOCWISE, being the event’s golden sponsor and provider in SOC services in the EMEA region, closely followed the 2-day event to stay on top of what’s new in the world of cybersecurity.

In this article, we’ll give a detailed account of what the participants of the roundtable discussion titled ‘The state of SOAR solutions’ talked about during their 1-hour session. We previously covered another inspiring discussion on XDR, if you’d like to read about that topic as well, click here.

The state of SOAR solutions

One of the most exciting sessions of the summit was about SOAR solutions. Due to the complexity of the topic, the organizers decided to pass on the usual lecture-style presentation and deal with it in the form of a roundtable discussion, where multiple experts had the chance to talk about their views and opinions and learn about others’. The roundtable featured Harri Ruuttila from Palo Alto Networks, Balázs Csendes from IBM, and Prashant Mishra from RSA Security, and was moderated by Péter Sajó, the head of EURO ONE’s IT Security Division. With a combined experience of 55+ years in cybersecurity, the four gentlemen touched on multiple aspects of SOAR solutions including advantages and disadvantages, the difference between SOAR and SIEM, use cases, the role of automation, and more.

The biggest challenge of SOAR solutions

The discussion started with a question that could have easily divided the participants: what is the biggest challenge of SOAR solutions? However, as it turned out, Prashant, Harri and Balázs were all in complete agreement about the answer both to the question and to the challenge: staff shortage and automation.

First, Prashant argued that SOC investigations take up a lot of time by default, but due to changes in IT infrastructures and going to cloud, the amount of data, apps, and alerts is increasing at high rate, the handling of which poses a great challenge. Automation, however, could simply solve this problem. Hari added that this can be observed even in large companies that have an in-house SOC or an MSSP. Even if they have enough people, automation can help decrease the boring, day-to-day tasks experts need to do all the time, so they can be better utilized for more meaningful tasks. At the end of the day, he adds, this is beneficial for both parties, as these resources will find their jobs more meaningful, which means they’ll be less likely to change jobs forcing the company to hire and train new employees. Balázs agreed that burning out is a quite common phenomenon in SOCs, and highlighted the importance of automation for another, strongly-related reason: it’s crucial to have consistency within a company, and automation can help set up processes that will work tomorrow the same way they worked today, even despite employee turnover.

SOAR vs. SIEM

Next, Péter raised an interesting pattern he noticed about customers who frequently ask about the relationship between SOAR and SIEM and whether they need both or one can work without the other.

Prashant quickly stepped in to distinguish between the two toolsets, explaining that SIEM can only do the detection part of the story. Response, however, is a time-consuming activity that’s greatly affected by the complexity of the case and the skills of the analysts. For example, in case of a potential phishing e-mail, an investigation might include 20-25 steps which can take from 20 minutes up to several hours depending on the analysts’ level of experience. According to Prashant, this is where SOAR can help by automating the most common tasks. However, it can’t replace SIEM, as they complement each other as they do in XDR solutions, which is basically the future – all the technologies combined together without having to log in to multiple consoles, use various databases, or train people for different activities.

Building on that, Balázs explained that IBM did exactly that last year: it merged its SIEM and SOAR technologies into one hybrid cloud platform called IBM Cloud Pak, as they believe the next decade will be about hybrid cloud environments. In his opinion, the situation is similar to what went down with the shift from on-premise to cloud solutions a few years ago – no one thought cloud readiness would be a must back then and yet here we are.

On the other hand, Harri argued that a lot of small companies don’t have SIEM and get their use cases from different sources. In his view, SIEM is not mandatory, and SOAR is actually more beneficial even for small companies. He acknowledged that SOAR solutions are expensive and that it would be logical to think it’s mainly for big companies, but as its automation capabilities can save a lot of money by eliminating hours of manual labor, it could also be beneficial for small businesses in the long run. In addition, he added, there are open source SOAR solutions for those who don’t have the budget to deploy a commercial one, so what really matters is that the company must be cyber-aware, understand its risk posture, and know how to handle it.

Finally, Prashant added that it’s also important to know where you are on your cybersecurity maturity journey and to have standardized procedures. In other words, first you need to standardize your detection and response procedures so they can be managed even if some of your developers leave, and when you have that figured out, then you’re ready to automate with a SOAR solution.

SOAR is not a project, it’s a way of life

The next question from Péter was about the beginnings of implementing a SOAR solution – what the prerequisites are, where to start, and how to move forward. This time, there was a complete agreement among the participants: a SOAR solution should always build on existing, well-defined processes, and it should always focus on processes that are easier to automate first.

According to Balázs, IBM doesn’t look at SOAR as a ‘silver bullet’ – they know exactly that if a company doesn’t have clearly defined processes in place, a SOAR and automation will not solve any problems. As he said, there are a couple of things that need to take care of, and a lot of pitfalls to avoid within an organization before implementing a SOAR solution, and even then, companies should first focus on quick wins – things they can automate most easily – and get to the more complicated processes after.

As for Palo Alto, Hari says they have a great methodology for starting SOAR projects, and a straight-forward platform with a GUI which is easy to utilize even for security professionals who aren’t skilled at scripting. Still, he fully agrees with Balázs that processes need to be in place prior to SOAR implementation, because it’s a must that they know how to handle different incidents. Thus, they always start their projects by mapping out their customers’ processes and identifying situations where they can automate the majority of the incident handling with the least effort, giving them the most bang for their bucks. As Harri put it, SOAR is not a project, it’s a way of life – meaning you can always improve it, add new use cases, and fine-tune the existing ones. So it’s important to draw a line and know what’s worth the effort to automate and what’s not.

Prashant also added that it’s important to set up priorities and brought up one of his customers who wanted to implement a phishing analysis use case on day 1, even though they didn’t often have spear-phishing attacks. As he said, there has to be a transformation journey, and it’s best to target the low-hanging fruit first, then work your way up to the more complicated use cases.

Pre-defined processes or ready-made playbooks?

As we learned, when it comes to utilizing pre-defined processes or implementing ready-made playbooks, there’s not a firm line between the two.

For example, Balázs said IBM follows a hybrid approach where they merge their templates with their customers’ existing processes into one and proceed with that. As he said, it’s good to have templates but everything ends up custom-made in the end anyway. However, there are a few pitfalls that should be avoided in both cases, such as trying to automate everything, as some things may be just too expensive or don’t make much sense to automate. In addition, even with today’s GUIs, API calls and system integrations, deeper knowledge of Python, JavaScript or any other language in house could be beneficial to customize those calls, otherwise it could become an issue at a later stage. Even IBM, who has pre-built connectors for hundreds of systems, comes across 1-2 every once in a while, he added.

Harri agreed that those situations should be avoided, describing one of them as ‘rabbit holes’. He said the biggest mistake customers are prone to make is excessively fine-tuning a playbook to the point where it’s not beneficial anymore, so it’s important to know when to stop. In his experience, the people who work on these developments in bigger organizations are usually the architects, who might not even know what really benefits analysts and what doesn’t. For this reason, architects and analysts should work together to make sure that nothing is developed for countless hours without having an actual impact.

As for how many days it’s worth investing in a use case, Harri said it strongly depends on the use case itself, as some might be a lot more complex than others, and whether something is ‘good enough’ is also completely subjective. For example, building a phishing use case might take just one day for company, but a whole week for another – a lot depends on their internal sources of information, their processes, and whether they’re using a ready-made playbook as a template or implementing their current workflow into it, or even a mixture of both. As he said it, it’s hard to define it, but that’s exactly why it’s important to work out the priorities in the beginning – so you don’t spend too much time – and thus money – on something that you don’t even benefit a lot from.

Automation with moderation

Now, we’ve already learned from Harri that a SOAR project is a never-ending story, but still, setting milestones for a project is necessary. Péter’s next question aimed to find out how many uses cases are enough use cases in the first phase of a project, and although there was no clear consensus among all three experts, their opinions definitely overlapped.

According to Prashant, if you use SIEM as your detection source, you should aim for 15-20 use cases. He added that this could be different for an MSSP, but for more enterprises, having 20 detection rules and 20 corresponding response procedures is more than enough. In his view, the more automation the better, but it’s best to start small and work your way up. Although Harri completely shared Prashant’s views on the more the better front, he said he’d prefer 10-15 automations to start with, and he also highlighted that in some rare cases, automation may not even be the best answer. Finally, Balázs added that most of the time, IBM has 15-20 use cases as well.

Integrating external solutions with SOAR

At this point, a question arrived from the audience inquiring about how many external solutions are usually integrated during a SOAR project. All participants agreed that its fully up to the use case, but Prashant also added a lot depends on the analyst and the processes as well. As an example, he brought up one of the most common tasks of analysts: reputation checking in a threat intelligence system. As Prashant said, if the company doesn’t pay for a commercial threat intel tool, they might need validation from 20 different sources, which means automating 20 different tasks. In contrast, if they have a commercial product, then it becomes a single task, that is a single integration. Thus, it mainly depends on the company’s processes and the number of tools the analyst can handle. But most commonly, he added, it’s 5-10 integrations per project, which could be a firewall or proxy for prevention, a SIEM for detection and the like.

SOAR and the organization

The next question investigated the relationship between a SOAR solution and the organization itself: who should lead the SOAR project and how it will affect the company going forward. One thing Balázs and Harri completely agreed on is it definitely reaches outside the security department of the company. As Balázs said, especially in the EU where GDPR is in place, everyone needs to be involved from the CEO and upper management through the legal and HR department to every single employee who has a role in the process. According to him, ownership also raises interesting questions from time to time, as it usually goes beyond the security team if you implement the solution fully. In his opinion, a member of the upper management should be involved in the project at least as a project sponsor, if not a project manager.

Building on that, Harri added that he had customers who were basically the HR department of a company using a SOAR solution for employee onboarding and offboarding, which is IT-related but definitely not a SOC operation. He also added that he’d seen people being hired or transitioned to be SOAR architects as it requires a certain skillset including understanding how analysts think, how SOAR works and they also need to know some programming, so SOAR projects can also create positions within an organization.

The future of SOAR solutions

So far we’ve learned that usually SOAR enters a company’s life as a SOC-related project, but then as the solution evolves, it can spread to other parts of the company. Péter’s last question aimed to find out whether SOAR can be used to automate a whole organization in the end, or it will always stay focused on security and just occasionally affect other departments. Interestingly, Prashant, Balázs and Harri all had different views on the subject.

In Prashant’s opinion, although it could happen in smaller businesses, implementing a SOAR solution company-wide could pose a problem to larger enterprises, as he thinks IT uses cases and security use cases are substantially different. He does see evolvement in SOAR solutions, such as the addition of intelligence management, and he also expects attack surface visibility getting merged into it, but he believes that no matter how unified, SOAR solutions will always remain tied to SOCs.

According to Balázs, based on what IBM and other companies have been doing, SIEM and SOAR will be merged into one platform which will eventually become a cloud-based, SaaS solution. He sees IBM, RSA and Palo Alto’s decision to merge threat intelligence into SOAR as a sign of that as well. Nevertheless, Balázs believes that this hybrid platform will still be different from what IT departments will be using for their activities, and he thinks it’s good news as the two will continue to have some control over the other. In addition, he strongly believes that similarly to IBM, more and more companies will enhance their solutions with technologies like AI and machine learning to make response times shorter, and he’s convinced even the smallest businesses will be able to afford SOAR in 10 years.

In contrast, Harri had a completely different vision on SOAR: in his opinion, sooner or later it will stop being SOAR and become a general orchestration, automation, response solution that will not be necessarily related to security anymore. He says the he’s already seen signs of it happening, such as the abovementioned HR use case, where the department was using SOAR without even knowing what it was – for them, it was just creating a ticket to bring someone onboard and having the whole thing automatically provisioned for them. He argues that it will remain behind the scenes, as people will be using the same UI they’re used to, only it will provide them with a better and faster service.

As a final remark, Prashant argued that taking into consideration the business aspects, if a choice has to be made between sales application server enhancement and cybersecurity use case automation, budget allocation will most likely always favor business-related IT implementations.

Conclusion

As sad as that sounds – even Péter said that although he was sorry to hear that, it made sense – we don’t think SOAR has such a thankless future ahead. Thanks to its automation capabilities, incident response management has come leaps and bounds in the past few years and, as we heard during the roundtable discussion, it’s still far from its full potential. We at SOCWISE thought the discussion was inspiring, and we’re grateful to Péter, Balázs, Prashant and Harri for taking the time to share their thoughts with us on The state of SOAR.

Get an idea from SOCWISE to build or develop your SOC!

Some CISOs have built their SOCs over time with a mix of internal and external resources. But, given the ongoing evolution of cybersecurity techniques and the need to constantly adopt new skills and tools, managing this mix is becoming increasingly complicated.

Benchmarking : The Key to Creating an Efficient Security Operations Center (SOC)

See how we built it, how it works, and what technologies we use!