what is the difference between in-house and outsourced approaches
I was lucky to gain experience working with SOAR from completely different sides: to be on the side of the Customer, who is just implementing SOAR and learning to use it in daily tasks, and on the side of the integrator company with extensive experience in implementing information security automation solutions. I will tell you about overcoming the difficulties that I had to face, about finding unique solutions for successful SOAR integration, and also about how these trials transformed my vision and approach to work. Having been in each of the two roles, I was convinced in practice how important it is to adapt SOAR implementation approaches to the unique requirements of each organization and how useful it is to exchange experience in implementing different projects.
I would like to share not only my personal experience, but also give practical recommendations to specialists who are on the threshold of implementing SOAR in their organizations. I hope that this article will help to avoid typical mistakes and increase the efficiency of implementing new solutions.
In-house approach, or my experience as an in-house performer
Why is SOAR needed and what tasks does it solve in a company?
SOAR (Security Orchestration, Automation and Response) is an advanced technology designed to automate and orchestrate information security processes, as well as to quickly respond to security incidents. Implementing SOAR allows organizations to significantly improve their security, minimize information security risks and optimize the work of security specialists.
The implementation of the SOAR system in our banking organization solved several problems simultaneously. Firstly, we needed an effective and automated tool for responding to cyberattacks and security incidents. Secondly, we wanted to ensure reliable protection of clients and their financial data. To do this, it was important to combine information about incidents from various systems in one convenient window, and to conduct an inventory of assets safely and effectively.
What implementation challenges did you encounter?
There were several challenges when deploying SOAR in our organization, primarily related to adapting the system to existing information security processes. We faced the need to integrate with a SIEM system. We did not have licenses for ready-made integrations, and we did not contact the vendor for the necessary support.
After discussing everything with colleagues and management, we decided to do the SOAR integration setup ourselves for three reasons:
growth of expertise within the team. Developing our own solution allowed us to dive deep into the details of the SOAR technology and adapt it to the unique needs and processes of our bank;
process and cost control. We wanted to be fully in control of the implementation and configuration process, not dependent on the supplier, and to accurately understand and optimize our costs;
flexibility of project management. It was important for us to independently plan the deadlines and stages of work, as well as promptly make the necessary adjustments.
Our team consisted of two people: I was engaged in the integration of various systems, and my colleague was setting up incident cards for employees. The key difficulty was the need to independently solve all emerging problems without the ability to share experience or get help from others.
By studying the technology, attending conferences, and sharing experiences with colleagues from other organizations, we found that most professionals in companies had not reached a level of sophistication in working with SOAR that was comparable to ours. In many cases, SOAR use was limited to meeting minimum regulatory requirements, without developing and implementing full-fledged incident handling processes.
How we tried to “make friends” between SOAR and SIEM
The SOAR system we used did not provide the ability to run custom scripts at the implementation stage. Therefore, we configured scripts within the existing SIEM system. Our goal was to set up an integration that would allow SIEM to transfer incidents to SOAR and update their status if it changed in either system.
The SIEM system used the concept of cases describing certain events and incidents. When such cases were created, internal SIEM events were generated, from which it was possible to transfer data to scripts launched in the system. Yes, the SIEM system itself has a built-in mechanism for launching scripts.
Although we were able to implement the integration, we encountered a number of problems. When either system was significantly loaded, incidents might not be transferred from one to the other, which led to the need to manually check the statuses and the presence of incidents in both systems. We provided notifications in scripts that helped detect problems, but this was not enough, we had to perform a lot of manual actions.
During the integration process via API, we encountered another problem. The SOAR documentation did not describe the necessary methods for transferring asset information to the incident card. We conducted research and found a hidden or implicit API that allows you to establish a connection between an asset and an incident, including transferring the IP address of the host where the incident occurred.
Problems and solutions: asset inventory, antivirus, system performance
Inventory. As part of our work, it was necessary to implement an inventory of assets in SOAR. Initially, we tried to do this using SIEM, using events received from various sources. The plan was to receive events from Firewall, DNS and other devices in the network, then write them to sheets in SIEM and transfer data from them to SOAR. However, we abandoned this idea, since working with sheets in SIEM did not allow us to always maintain the current state of hosts. Instead, we found ways to organize inventory through SOAR, which already had built-in network scanning mechanisms.
In addition, we used the tag model to achieve the same segmentation as in SIEM. For example, asset ARM01 could have the following tags: PCI DSS, Critical, ARM, Antivirus, DLP. Each tag described a specific characteristic: PCI DSS — belonging to the PCI DSS segment, Critical — criticality of the host, ARM — automated workstation, Antivirus — the presence of antivirus on this host, DLP — the need for DLP on the host.
Using the tag model, we organized an efficient automation of the asset inventory process. The rules for assigning tags were determined by pre-defined policies. For example, when a network is identified with the address 10.1.0.0/24, we automatically assign it a PCI DSS tag. This network is initially classified as PCI DSS compliant, which makes it an obvious choice to assign the appropriate tag. Thus, the presence of this tag indicates that the network falls under certain data security requirements set by the PCI DSS standard and specific protection measures and security policies are applied to it. Then we assigned other tags, such as DLP and Antivirus. When tags were assigned, an event was generated containing information about the tag and the host on which it was installed. This event was sent to the SIEM, which already had lists of IP addresses and statuses, such as the presence of antivirus or not. The mechanisms for checking the availability of information protection tools on the hosts were set up long in advance, as this process was very important to us. Each information protection tool was checked differently. For example, in the antivirus, we had integration with the database set up. From there, the SIEM took the IP addresses of the hosts and the agent status on them.
Antivirus. We set up a rule that checked for antivirus on the host received from SOAR. If antivirus was missing, SIEM sent a new Unactive Antivirus tag to SOAR and created an incident about its absence. Thus, we implemented an automated process for checking for information security systems on hosts in our company.
Performance. Although the SIEM has the ability to run scripts, using this feature has a negative impact on the system's performance. When we had a license that did not allow updating the SIEM and the system was hosted on physical servers, we encountered performance issues. There were cases when the SIEM was unavailable for about two hours. Then we were able to restore it without losing data, since the connectors saved events until the SIEM was available again. Obviously, the problems were caused not only by running scripts, but also by a large number of unused or outdated rules.
In addition, we made mistakes in the SIEM rules settings and received a thousand events in SOAR within one minute. The accumulation of a large number of unnecessary events in SOAR negatively affected the system performance and made it difficult for users to work with incidents. Since it is impossible to delete the created events, we solved this problem by increasing SOAR resources and optimizing the PostgreSQL database by changing the standard configuration.
What I learned from this project is that effective incident and asset management requires careful planning up front, keeping in mind that each organization may have its own unique needs and requirements for these processes.
Outsourced approach, or my experience working in a system integrator company
New experiences, new challenges, new opportunities
My first project as an engineer at an integrator company was to implement a SOAR system at a research institute. Here, everything was completely different. The low-code SOAR platform being implemented allowed us to describe any process in the field of information security — something I was missing at my previous job. This project also required setting up a centralized process for handling incidents and managing assets. The approach to integration in this case was significantly different from the one I used in the banking environment. Here, we had ready-made connectors and pre-configured security processes. It would seem, what problems could arise during implementation in this case?
In this project, our task was to create an asset inventory process through integration with related systems. We needed to set up integration with a vulnerability scanner and DLP systems. Information about assets had to be uploaded daily and updated if changes occurred. An important condition was the presence of a unique field for each asset, by which SOAR could determine statuses and update data. However, certain difficulties arose related to the naming of network nodes, where both an IP address and a DNS name could be specified in the name field. This led to duplication of assets and possible double entries. In addition, it was necessary to take into account that not all related systems could specify assets, since some network nodes could never be scanned or did not have DLP.
To solve this problem, we used a new solution — universal playbooks in SOAR. We decided to scan the networks where the assets were located and automatically add the missing data to SOAR. This allowed us to solve two problems at once. First, we guaranteed the relevance of the information about the assets. If the host was unavailable for more than 7 weeks, we removed it from SOAR. Second, we were able to fill in the gaps in the information about the hosts that were missing from adjacent systems for various reasons.
When taking an inventory of assets in a bank, I used the approach of scanning known networks obtained from SIEM. When implementing SOAR in a research institute, I faced another problem — a huge volume of data on assets. If we collected data from a vulnerability scanner, then the number of records on the presence of software, for example, different versions of 7-zip, in the organization became huge. A little later, I got acquainted with the concept of pagination and solved this problem. We changed the integration process, uploading 500 records per iteration. We also decided not to upload the same records every day. We organized data processing in SOAR itself, where the software was “collapsed” into the most current version, and only those records that were updated recently were uploaded.
The benefits of a holistic view
I am glad that I had practical experience of working from different sides: both from the Customer's side and from the integrator's side. Now, working in an integrator company, I understand the Customer's tasks and can quickly help solve the problems that I encountered myself.
The path I took helped me understand that it is important not only to quickly dive into unknown processes and understand new software, but also the composition of the team and its expertise, the overall level of expertise in the market. I wrote that we attended specialized conferences, but could not find answers to all the questions. Small teams have limited opportunities to exchange experiences and study the best practices of other organizations. All this slows down the implementation process and increases the labor intensity of the work on adapting the system to the specific needs of the organization.
External integrators, on the contrary, have access to a wide range of projects and solutions. This allows them not only to learn from the experience of others, but also to adapt successful practices to solve problems in new contexts. This approach significantly simplifies the process of solving specific problems and contributes to more effective implementation of the SOAR system.
The example of building an automated asset inventory described in the article highlights the diversity of approaches that can be applied depending on the customer's network architecture and infrastructure. We are talking about scanning known networks and integrating with adjacent systems. But if the organization has a so-called “network throat” through which all traffic passes, this opens up opportunities for using traffic mirroring systems, allows you to get a complete picture of all assets in the infrastructure, simplifying the inventory process and increasing the efficiency of asset management.
Thus, the experience of working both in-house and outsourced in implementing SOAR demonstrates that flexibility of approaches and openness to sharing experience are key factors for success in the field of cybersecurity. This not only contributes to more effective implementation and adaptation of security systems, but also enriches the professional community with valuable knowledge and experience.
Author: Sergey Marchenko, Leading Engineer, Information Security Automation, UCSB
