SOAR to Success: Five Reasons to Not Rush Auto-Remediation
Here’s why you need to hit the brakes before shifting gears into auto-remediation.
Corrective auto-remediation, or security orchestration & automated response (SOAR), has been a more frequently heard term in the cloud security space. SOAR offers the ability for organizations to automatically execute actions in response to security incidents or vulnerabilities. While in theory automating functions in the security sphere can indeed improve efficiency, Jonathan Rau, CISO of Lightspin, cautions that if not applied correctly and continually tuned to meet your specific organizational requirements, it may cause increased outages and more headaches for your teams.
SOAR is not a one size fits all approach, nor is it simply an “auto-fixer” for the variety of issues that can and will arise daily. This is particularly true when it comes to asset management, governance, and perimeter security tooling build-out.
Five Key Points To Consider for SOAR Application
As organizations look to streamline their security operations, they should keep the following issues in mind as they approach broad SOAR applications:
1. Lack of security depth: Infrastructure-level posture fixes may not meaningfully improve the total security of a specific product or service. Security is more than just ensuring S3 buckets are encrypted and that logging is enabled – SOAR can give a false sense of true security, especially if the application itself contains Application Security issues or unfixed & publicly exploitable vulnerabilities.
2. Overcomplication for difficult use cases: AppSec and vulnerability management typically pay bigger dividends for product security over configuration-level fixes; if you attempted to auto-remediate unpatched vulnerabilities or AppSec issues found by Static Application Security Testing (SAST) & Dynamic Application Security Testing (DAST) tools you may be unable to cover all use cases, may break code/binaries, or break a product by upgrading a dependency that needed to be pinned to a certain version. SOAR can be a viable option for less complicated and smaller use cases, but an application of automated patching will inevitably lead to unintended application-level side effects, like outages.
3. Lack of oversight or governance and conflict between teams: If a Security team unilaterally decides to rollout auto-remediation, it can directly conflict with product teams by overriding configurations that are deployed via infrastructure as code (IaC). This will result in artificial drift, or it can counteract existing security remediation efforts made by product teams. This can lead to increased friction and conflict between security and DevOps teams which need to be able to work in concert with one another to ensure that builds are secure from the start.
4. Longer term maintenance or ops burden: This is more for self-managed SOAR workloads where teams are writing event-driven architectures & remediation code – and it goes up exponentially in multi-regional/multi-account environments, but it can also impact commercial SOAR. Leaders need to weigh long-term human capital costs (hours per incident, for instance) saved over pushing responsibilities down to product teams as you must spend time updating and maintaining what you have, plus rolling back changes.
5. Bad data exposure: This is more for traditional SOAR use cases used by security operation centers (SOCs) for Incident response – if you’re pulling data into an incident and the data is bad due to schema misalignment/corruption, inaccessible or “stale” then you can drive up your mean time to remediation (MTTR) and mean time to discover (MTTD) artificially or deploy SOC resources towards issues that may not exist. Leaders need to ensure high data quality, availability, and proper data governance is in place. This can affect auto-remediation as well if you’re indexing off a cloud security posture management (CSPM) tool, which may be delayed in its own collection and collation.
See More: 5 Ways SOAR Helps Protect Remote Workers from Emerging Cyber Threats
5 Strategies To Ensure Optimal SOAR Deployment
If you are set on using SOAR in your organization, here are some things that will ensure it is optimally deployed for the greatest chance of success.
1. Communication, communication, communication: Perhaps the most essential rule of thumb for security in general. For organizations of any size, it is essential that teams overcommunicate and do so ahead of time – meaning that there should be clear communication of:
- What are we building?
- Why are we building this?
- What are the benefits?
- What may it impact?
For more mature organizations, these conversations may be held in more formal change advisory board (CAB) settings, but whether informal or otherwise, it is essential that there is a clear understanding from all parties involved across security and dev teams what is being considered and how it may ultimately impact the current environment and the business outcomes.
2. Start with small and harder use cases: SOAR is a tool best served in smaller or highly specific use cases where the number of dependencies will be minimal. A controlled approach can make the application of an automated remedy more effective and minimize the risk of it breaking something else in the environment.
3. De-conflict from IaC & other auto-remediation: SOAR can be integrated with IaC tools to provide automated incident response workflows that are triggered by IaC events. This integration can help to ensure that SOAR and IaC are working in harmony. However, it is important to ensure that SOAR does not overwrite any changes made to the cloud environment by IaC. This can be achieved by carefully configuring SOAR workflows to avoid conflicts with IaC.
4. Use minimum necessary changes & deployments: Additionally, rather than deploying SOAR across your entire cloud environment at once, teams can consider implementing a phased approach to deployment. This will allow for monitoring of the impact of SOAR on the cloud environment and the ability to make any necessary adjustments.
5. Consider “dry runs”: Instead of simply diving head-first into SOAR, teams can start by sending alerts to application owners for a grace period before the changes are made. It is smarter to perform several dry-runs with notifications only and to verify that the reported results are congruent with what the team was expecting. If not, this provides a buffer for teams to make changes and agilely update the necessary areas. It also allows teams to test edge cases if desired without breaking anything.
SOARs can be extremely useful, but how they are used still needs to be carefully curated by manual touches. Automation, as it is applied to any discipline, is meant to improve efficiency and efficacy. However, it is important to consider, especially as it pertains to security – that there are always new risks and vulnerabilities that can arise quickly. These can only be mitigated through fine curation of SOAR tools in conjunction with the expert human eye.
What SOAR tools and strategies are you employing? Share your experience with us on Facebook, Twitter, and LinkedIn. We’d love to hear from you!
Image Source: Shutterstock
MORE ON SOAR (SECURITY ORCHESTRATION & AUTOMATED RESPONSE)
