THANK YOU FOR SUBSCRIBING
One of the next phases in the evolution of Cyber Defense Centers (CDC) is the realm of security orchestration, automation and response or SOAR. This is the new “glue” to bind together the disparate pieces of knowledge we need to manage the information overload and it may be a path to making teams more efficient. With that said, there are more than a few areas to consider before you head down this path.
Let us start with what SOAR is and how the products have generally evolved. SOAR capabilities tend to fall into two buckets, frictionless and active. Active SOAR playbooks take an automated action based on defined criteria. These are the ones that sound sexy but are less likely to be implemented when you consider the potential unintended consequences of the action. For instance, you could create a playbook that automatically blocks an IP address scanning your external facing assets. However, what happens when someone spoofs the scanning address from one of your key partners or customers? Does the event data that the SOAR product is using show if it is valid traffic? (SYN or Reset packets versus ACK packets.) If not, you could inadvertently disrupt your business operations and this is not a time-saver, obviously.
Frictionless playbooks are often tasks that an analyst would perform, which do not require an active action. As an example, an email with a PDF attachment could kick off multiple playbooks. First, lookup the sending domain on any blacklists and the appropriate mail exchanger (MX) records to compare them with the IP address of the sender of the message. Another playbook can collect or create a hash value for the attachment, then check the filename, and hash value against threat intelligence sources to see if there is a match to raise the riskiness of the message. Neither of these playbooks will block an email or a sender but they do provide context for the security analyst to make an assessment.
“SOAR is the new ‘glue’ to bind together the disparate pieces of knowledge we need to manage the information overload and it may be a path to making teams more efficient”
How the product is deployed is the next element in the product landscape and there are again two general buckets, “built-in” or “added on.” “Built-in” SOAR capabilities are the portion of a product that executes the playbooks. This requires that the base product – often a SIEM, UEBA, or log aggregation product – builds out the capabilities to leverage the APIs of either security products (“active” playbooks) or information sources (”frictionless” playbooks). This is a complex task to add on to a product in addition to the core functionality.
“Add on” SOAR products focus on the integrations with products and information sources solely. However, the “add on” products need to ensure they can be tightly integrated with all the products. While the API integrations are challenging for both “built-in” and “add on” products, the latter has the greatest dependence on API accessibility as without it the product can be deprecated. And while the jury may still be out on the final decision, it seems that “built-in” products are taking the lead as some have been acquired and integrated into core products.
Is now the time for SOAR soup?
This is a complex question for most organizations. A few key items to consider are readiness, environment and staffing. However, now that there are fewer organizations that will implement active playbooks, there is a significant overlap on the approach to “frictionless” decision points.
The first question is obvious but often overlooked. Do you have documented actions that can be automated? As simple as that sounds it is often overlooked in the rush to try to “get the most from the staff” by buying a product. Writing down the actions to be automated and the required sources or APIs needed is a great first step and a way to bring new staff into the security team. It is a rare person who likes to do this documentation and they are worth their weight in gold as part of the team. This allows you to discuss tactical approaches with the SOAR vendor and not get swept away in the far-reaching generalities.
Your environment is also a cornerstone in this structure. Do you have a core vendor that has a “built in” SOAR capability? Correlating their capabilities against your (now) documented goal playbooks leads to better-informed decision making. If not, is there an “add on” product that integrates your core products and information sources. While this is also a simple and logical approach, you would be surprised how often it is overlooked.
Staffing as it relates to SOAR has its own two subdivisions. Can your analysts use the information provided by automation to reduce repetitive tasks and implement a simple form of Robotic Process Automation (RPA)? Most likely, the answer to this question is “yes” but they may already have some degree of this in place already. Just as important though, is the question of having staff ready to support this new tool properly. Skills ranging from python, other programming languages, network access controls and system administration all can come into play. Vendors will often update their APIs or other access methods with little or no notice, thereby breaking your custom integrations, which require engineers to fix it.
In conclusion, SOAR products offer time savings for cyber-defense centers that have documented processes. Frictionless playbooks can make your staff more efficient and remove some drudgery from the plate of an incident handler. It is not likely to see these products as a way to decrease overall headcount though, as the human factor is still a key component of incident management. Whether you choose a “built-in” or “add on” SOAR product, you must make sure you have staff with the skills needed, ready to manage and tune the playbooks. Integrations will change rapidly and without notice – and hoping that the vendor will fix your custom playbook is not a plan for success.