Top 3 Barriers to Effective Security Orchestration

14 Mar Top 3 Barriers to Effective Security Orchestration

By Tom Young, Executive Vice President of Worldwide Sales

Security Operations orchestration is very top-of-mind for CISOs and their SOC leadership thanks to the ever-increasing complexity and speed of the threat landscape, Splunk’s recent acquisition of Phantom Cyber and Gartner’s formalization of the Security Orchestration, Automation & Response (SOAR) market.

According to Gartner, SOAR is the process of capturing security event triage and IR processes, automating incident response workflows and orchestrating containment and remediation actions across multiple, disparate IT and Security systems.

SOAR use cases are wide ranging and cut across many categories of security simply because security events are not limited only to threats that have been escalated as a result of SIEM or MSSP log analysis, correlation and machine learning rationalization. Examples of SOAR uses cases include:

  1. Vulnerability Management: Discovering new instances of known vulnerabilities on active, externally facing servers that requires expedited patching
  2. Threat Intelligence: Investigating network logs for Indicators of Compromise (IOCs) to determine if the network has been compromised or data has been extracted
  3. DevSecOps: Monitoring the status of network devices in an MSSP environment to track the status of the box and the effectiveness of security measures
  4. Physical Security: Triggering a security alert to dispatch a security guard to investigate an exit door that was left open for a defined period of time

As you can see, SOAR platforms have the ability to create efficiencies for security operations teams, regardless of which type of security event triggers the alert triage and incident response process to begin taking corrective actions.

Take a Guided Tour

Complete the form to schedule a demo of Syncurity’s award-winning IR Flow Security Operations and Incident Response Platform.

However, there are a few barriers that must be addressed before SOCs can fully shift their operations to the world of security orchestration and automation.

And although some technical barriers exist, such as vendor compatibility, API availability and platform scalability, the Top 3 Barriers to Effective Security Orchestration are actually non-technical, which consist of 1.) Change Control, 2.) Business Risk Management and 3.) Technical Debt Awareness.

1. Change Control:

Most, if not all organizations have an approved process for implementing IT changes, which include reviews and approvals, as well as synchronizing response timing to minimize impact to the business. Although this staged process is considered best practice, supported by frameworks like ITIL and enforced through compliance regulations in some industries, this is the process most people love to hate. Its why a simple firewall rule change can take days to implement because its buried under layers of approvals, sandboxing, troubleshooting and testing to minimize disruption and unintended consequences.

In order to change the status quo, security organizations looking to adopt the SOAR approach must first prove the value of these platforms by demonstrating their ability to dramatically reduce the time it takes to find and contain serious business risks. By accelerating the triage stage to automatically weed out false positives — as well as true positives that are already blocked/stopped — security can significantly reduce risk exposure to the business by focusing analyst resources on investigating unknown threats.

Security teams can use orchestration to facilitate IT’s response through the existing IT Change Control process by generating tickets, monitoring the status of the existing IT management environment and capturing the metrics that demonstrate improvement (e.g., Time-to-Detect, Contain and Remediate). Armed with concrete evidence that significant value has been delivered, security teams are in a better position to talk with business and IT leadership about which circumstances could be automated to bypass the manual IT Change Control process. For example, when does it make sense to leverage direct API-based integrations to the IT and Security infrastructure (e.g., FW, IDS, EDR, etc.) to automatically generate tickets that will be tracked in the manual IT management environment.

2. Business Risk Management:

Business risk management is as much a business decision as it is a technical decision. Security, IT and the business must agree on the right risk/reward balance when enabling incident response orchestration to make changes that directly and immediately impact the business.
The most likely result is a mix of conditions where the security team is confident responding to urgent, high-risk threats, while less-urgent risks are contained and remediated through the approved Change Control regimen. Firms should establish a steering committee (if one has not already been formulated) to broker decisions about creating or updating processes and procedures for addressing various types and levels of risk, exceptions and exemptions and how these are documented and controlled for audit purposes.

3. Technical Debt Awareness:

Its also important for organizations to take stock of their technical debt before orchestrating and automating incident response. The practical impact of implementing direct, system-level API integrations to automate hundreds of rule changes on a daily basis can be overwhelming. For example, if a workflow was accidentally setup to automate 400 firewall rule changes every day, that would generate over 100,000 new rules after a year. Which would not only pose a risk to the efficiency of the device itself, but create unnecessary management headaches and migration nightmares should the firm decide to eventually switch vendors. “Just because you can, doesn’t mean you should,” as the saying goes, so security teams should do their best to engage the business and IT to develop a framework for determining which risks warrant direct, automated system-to-system IR orchestration vs. those which follow the existing approved Change Control process.

And while our experience has shown that most firms are ready, able and willing to accelerate the triage and investigation stages of SOAR using workflow, automation and direct system integrations via API, it appears that managing the Change Control process with business and IT stakeholders is the biggest barrier to implementing SOAR platforms for now. Those organizations that are prepared to work with their business and IT colleagues to update their Change Control processes will have the most success in orchestrating and automating incident response to combat alert overload, incident dwell time and breach detection in the months and years ahead.

Where does your organization fit on a scale of 1 to 5, where 1 means you’re not able to make any changes outside the established Change Control protocols, and 5 means you’re able to turn on Skynet?

Join the discussion on Twitter, LinkedIn, Facebook, and Peerlyst.

No Comments

Post A Comment