Protect Your SOAR

Published 9/28/2021, 9:00am

You finally got your SOAR (Security Orchestration, Automation and Response) system in place. Automation is happening, and security operations are moving at the speed of code. But what about protecting the system itself? Here are some suggestions to ensure you have taken steps to secure the system prior to automation and orchestration.  

In this blog on SOAR, we look at attacks your SOAR may be vulnerable to and recommend some ways to mitigate these risks. 

Playbook/Runbook repository

The playbooks and runbooks stored in the SOAR typically reside on a github repo or equivalent. If an attacker gains even read access, they will have a complete picture of your security detections and responses, and this information can be used to bypass security controls. Furthermore, if write access is achieved, the damage can be much more severe. At minimum, the data in the repo should be encrypted at rest and support MFA for interactive access. 

API keys 

The API keys in a SOAR require a significant amount of protection because these API keys have access to almost all of the security tools in an organization. If an attacker obtains access to these keys, they will have a high level of access to many critical components such as firewalls, antiviruses, and syslog. Due to the nature in which automation is created, an attacker can modify account access, ports and detection signatures. For additional information on protecting your API keys, reference T1056 on the MITRE ATT&CK framework.   

Keep the SOAR integrations updated 

Your SOAR will have various API integrations with many of the security tools throughout your organization. When new releases of these tools are developed, the team should review the release notes for security and functional enhancements. If the upgrade meets a need, test the upgraded integration in a development environment prior to installation. Once installed, disable the legacy integration.  

Two-person Integrity with Playbook development 

SOAR platforms have a high level of access to key security tools, so one person should not be allowed to create all the playbooks without a second check. An organization should utilize its change management process to incorporate a system where the code is reviewed prior to deployment.

Performance Monitoring

Monitor your SOAR solution’s performance. Continuous monitoring of the system’s performance is a good indicator of anomalies that might affect the solution. For example, sudden spikes in CPU, network, or memory should be investigated. This can be done with holistic monitoring solutions like Splunk ITSI, Nagios, or SolarWinds just to name a few or native cloud tools already in place in your environment.  

Work with a Red Team

As an organization, work with your red team and gather ideas on how they would exploit the SOAR systems, and what IOCs you should look for as an organization. Since they have intimate knowledge of the organization’s systems, they can provide valuable insight into how an adversary would exploit the SOAR. This can be accomplished as a table talk exercise or vulnerability assessment.  How you conduct this process is not as important as ensuring that the security operations team is aware of the risks your SOAR system faces. Collaborating with the red team will result in a comprehensive list of items to look for specific to your environment.  

Final Step Audit

The items above are things you should be doing as security professionals to protect your SOAR. Your final step should be to build a plan to assess that the security controls are proactively being enforced. A combination of quarterly and random audits is recommended.