As per Gartner, SOAR refers to technologies that enable organizations to collect inputs monitored by the security operations team, such as alerts from SIEM and other security technologies, where incident analysis and triage can be performed by leveraging a combination of human and machine power — to help define, prioritize and drive standardized incident response activities. SOAR tools allow an organization to define incident analysis and response procedures in a digital workflow format
Security Orchestration, Automation and Response platforms are increasingly becoming a very important component in most cybersecurity operations center. Though some organizations have deployed SOAR, a lot of them still struggle to find value in the platform. So here are some of the don’ts when it comes to SOAR deployment
1) DO NOT aim for SOAR playbooks for rarely used runbooks
Whenever you plan to deploy SOAR, start with building automation playbooks that are most commonly used by analysts or are critical for them to perform for SOC operations. Involve your analysts to check their day to day tasks that consume the most time. Prioritize by building them first instead of focusing on non-critical / rarely used playbooks.
2) DO NOT aim for complex decision making in a single playbook until you have tested smaller playbooks
Lot of customers want to target complex automation use cases in the first phase itself. Its recommended to start with simple use case with less than 5-6 automation/tasks to check rather than use case that has over 20 tasks. Begin with targeting smaller use cases followed by use case that have more automation/tasks. Tested each of the decisions through smaller playbooks in a production environment before implementing complex playbooks. Once you are comfortable with the performance of these then you can keep adding more complicated use cases.
3) DO NOT lift and shift SOAR playbooks from OEMs ‘as is’
All OEMs provide content packs that have playbooks for most commonly used products as well as use cases like data enrichment. Make sure you review and test them before deploying them in production. Ex- there might be a native enrichment feature in the SOAR product that you are using. Enabling a data enrichment in such scenarios might lead to redundant tasks and overconsumption of third party products. Some of these products even charge based on API’s consumed.
4) DO NOT aim for SOAR playbooks involving devices with less matured API interfaces
Some OEMs are still developing APIs for common use cases. Certain SIEM platforms allow reading alert data, however, they don’t expose API’ to change the alert status using API. Some older product deployments don’t even have APIs for automation. However, as product roadmaps evolve, other use cases will be covered. Make sure you are clear on API support for the use cases that need to be automated.
5) DO NOT aim SOAR playbooks for devices that have a smaller number of instances
Always focus to implement SOAR for use cases as well as have a high number of instances as well as high automation value. A use case covering firewalls and server provides much higher value instead of ones on the load balancer
6) DO NOT implement a SOAR unless you have documented runbooks
A lot of customers ask us for automating the process without having defined runbooks. We and our partners can definitely consult on the same. However, it shows that customer desire for automation without defined process, would result in . A better approach would be build and identify SOC processes based on Infra / use cases / Threat categories and then using the SOAR platform to automate these use cases.
7) DO NOT aim to automate L2 / L3 tasks initially
As you deploy SOAR platform look for the most common use cases that are documented and are needed by L1 analysts. Once they are automated, make sure you use the platform for first few months without covering complex use cases used by L2/L3 analysts. Track improvement in various metrics like response time. Only when the analyst team is satisfied with performance, you should move to other complex use cases.
8) Do Not Integrate every tool without an automation use case
We have seen customers asking us to integrate SOAR platform with all the possible technologies that they own. They want to integrate all the products that they have integrated with their SIEM systems. Some of these technologies don’t even have any automation target or out of scope for SOC analysts. Ex- A good way would be talk to SOC analysts to find any manual processes that they are doing and then implementing it on SOAR for automation.
For understanding best practices for deploying your SOAR product, refer to the following link – https://www.securaa.io/best-practices-for-deploying-security-orchestration/
For more details contact us at info@securaa.io