SOAR Technology – What Problems Are We Trying To Solve?

Increasing Adoption of SOAR Solutions

Over the past several years, Security Orchestration, Automation and Response (SOAR) has gone from being viewed as a niche product to one gaining traction across almost all industry verticals. Today, more and more private organizations, MSSPs and governments are turning to SOAR Technology to address previously unsolved problems in their security programs. SOAR is about taking action: “Automate. Orchestrate. Measure”. Organizations are implementing a SOAR solution to improve their incident response efficiency and effectiveness by orchestrating and automating their security operations processes. Gartner estimates that by 2019, 30% of mid to large-sized enterprises will leverage a SOAR technology, up from an estimated 5% in 2015.

In this three-part blog, we will discuss the key drivers for SOAR adoption and what problems a SOAR solution can help solve.  In the next blog, the second part of this three-part blog, we will discuss the three pillars of Security Orchestration, Automation and Response (SOAR). Finally, we will round out the series by discussing the critical components and functionality that a SOAR solution should contain.

Five Key Problems SOAR Technology Helps to Solve

Like many new product categories, Security Orchestration, Automation and Response (SOAR) technology was born from problems without solutions (or perhaps more accurately, problems which had grown beyond the point that they could be adequately solved with existing solutions). To define the product category more accurately, it is crucial to first understand what problems drove its creation. There are five key problems the SOAR market space has evolved to address.

  • Increased workload combined with budget constraints and competition for skilled analysts means that organizations are being forced to do more with less

As the number and sophistication of threats has grown over the past decade, there has been an explosion in the number of security applications in the enterprise. Security analysts are being forced to work within multiple platforms, manually gathering desperate data from each source, then manually enriching and correlating that data. Although it may not be as difficult to find security analysts as it once was, a truly skilled security analyst is still somewhat of a rare breed.  Intense competition for these skill analysts means that organizations must often choose between hiring one highly skilled analyst, or several more junior analysts.

  • Valuable analyst time is being consumed sorting through a plethora of alerts and performing mundane tasks to triage and determine the veracity of the alerts

Even when alerts are centrally managed and correlated through a SIEM, the number of alerts is often overwhelming for security teams.  Each one of these alerts must be manually verified and triaged by an analyst.  Alerts which are determined to be valid then require additional manual research and enrichment before any real action can be taken to address the potential threat. While these manual processes are taking place, other alerts sit unresolved in the queue and additional alerts continue to roll in.

  • Security incidents are becoming more costly, meaning that organizations must find new ways to further reduce the mean time to detection and the mean time to resolution

The cost of the average incident has increased steadily year on year. The immediate cost of an incident due to lost sales, employee time spent, consulting hours, legal fees and lawsuits is relatively easy to quantify. The financial loss due to reputational damage, however, can be much more difficult to accurately measure. Reducing the time to detect and resolve potential security incidents must be an absolute priority. Each hour that a security incident persists is effectively money out of the door.

  • Tribal knowledge is inherently difficult to codify, and often leaves the organization with personnel changes

Employee retention is an issue faced by almost every security team. Highly skilled analysts are an extremely valuable resource for which competition is always high. Each time an organization loses a seasoned analyst, some tribal knowledge is lost with them and they are replaced with an analyst who, even if they possess the same technical skills, will lack this tribal knowledge for at least a period of time. Training new analysts takes time, especially when processes are manual and complex.  Documenting security processes is a complex, but critical task for all security teams.

  • Security operations are inherently difficult to measure and manage effectively

Unlike other business units which may have more concrete methods for measuring the success or failure of a program, security metrics are often much more abstract and subjective. Traditional approaches to measuring return on investment are often not appropriate for security projects and can lead to inaccurate or misleading results. Properly measuring the effectiveness and efficiency of a security product or program requires a measurement process specially designed to meet these unique requirements.

About DFLabs IncMan SOAR

DFLabs is an award-winning and recognized global leader in Security Orchestration, Automation and Response (SOAR) technology. Its pioneering purpose-built platform, IncMan SOAR, enables SOCs, CSIRTs, and MSSPs to automate, orchestrate and measure security operations and incident response processes and tasks. IncMan SOAR drives intelligence-driven command and control of security operations, by orchestrating the full incident response and investigation lifecycle and empowers security analysts, forensic investigators and incident responders to respond to, track, predict and visualize cyber security incidents.  As its flagship product, IncMan SOAR has been adopted by Fortune 500 and Global 2000 organizations worldwide.

Schedule a live demo with one of our cyber security specialists here and see DFLabs IncMan SOAR platform in action. For more information on any of these topics, please check out our new whitepaper titled “Security Orchestration, Automation, and Response (SOAR) Technology” here.

Stay tuned for our next blog in this series, where we will discuss the three pillars of SOAR technology.  

Attackers Are Embracing Automation, Why Aren’t We?

Attackers have long embraced the concept of automation. Although attackers were likely automating their attacks prior to the Morris worm, in 1988 the Morris worm brought attack automation to the attention of the security industry when it brought down a large portion of the Internet. Since then, the sophistication of attack automation has increased exponentially. Frameworks such as the Metasploit Framework allow attackers to script the entire attack process, from information gathering to exploitation, to post-exploitation and data exfiltration. This sort of automation has allowed the attackers to exploit systems with much greater efficiency.

According to the 2017 SANS Incident Response Survey, almost 50% of organizations who responded reported average detection to containment times of greater than 24 hours. Put another way, almost half of these organizations are allowing attackers to remain in their networks for more than a day after they have first been detected, and that does not even include the time that elapses from compromise to detection. Even an unskilled attacker can cause catastrophic damage to an organization with 24 hours of uninterrupted exploitation time. A skilled attacker automating network reconnaissance, establishing persistence on additional hosts and performing data exfiltration, can cause damage in 24 hours that it will take an organization months to fully discover and recover from.

Three decades later, why have we as a security industry been so slow to adopt the same methods of automation? Sure, we have long automated portions of the incident response process, such as automatically removing detected malicious files or automatically quarantining suspicious emails, but we have yet to achieve the sort of automation efficiency that has been being used by attackers for decades. Even for commodity attacks, this level of automation is often ineffective as attackers have adapted to include multiple mechanisms to maintain persistence when a single file or registry key is deleted. To a skilled and determined attacker, this level of automated prevention is trivial to bypass in most instances.

Attackers have learned that automating large portions of the steps along the Cyber Kill Chain allow them to more quickly infiltrate a single target, as well as more efficiently attack multiple targets. Why then has the security industry yet to follow suit and automate larger portions of the incident response lifecycle? The two most commonly encounter objections are that is it not possible or too risky to automate larger portions of the incident response lifecycle.  The answer to the first objection is easy; it is certainly possible. The emergence of Security Orchestration, Automation and Response (SOAR) platforms, such as DFLabs IncMan, have made automation of a large part of the incident response lifecycle possible.

The answer to the second objection to automation is a little more complicated. There is certainly reason for a cautious approach to automating more of the incident response lifecycle, especially when we consider automating containment, eradication, and recovery.  After all, there is little risk to the attackers when their automation fails; they may be detected or they may not successfully exploit the target. In either case, the attacker can simply try another method, or move on to the next target.  The potential risk is much greater for organizations automating the incident response process. Automatically containing a business-critical system because of a malware detection or automatically blocking business-critical IP address because it was erroneously flagged as malicious, could cost an organization millions of dollars.

While these risks can never be completely eliminated, automation processes and technology have reached a level at which failing to embrace greater levels of automation carries with it significantly more risk than implementing automation in a well-planned, controlled manner. Appropriate automation pre-planning, identifying the repeatable processes which can most safely and easily be automated and carry the greatest risk/reward benefit, maximizes the benefit of increased automation. Proper use of both internal and external sources of enrichment information, such as threat intelligence and internal databases, to inform the automation containment decision process can greatly reduce the risk of containment actions which could negatively impact the organization.  In addition, many SOAR platforms have incorporated the ability to include human input during critical decision points in the automation process. For example, IncMan’s Dual-Mode Orchestration allows users to switch between automated actions and human intervention at critical junctures in the response process, allowing the majority of the process to be automated while still permitting human input and reducing the risks posed by pure automation in some critical processes.

Although we are likely still decades away from the proverbial incident response “easy button”, or being able to say “Alexa, remediate that threat”, the current threat landscape is also demanding that we do more with less and respond faster, and that means automation. SOAR platforms are no longer just “nice to have” technologies, they are becoming a requirement for organizations to remain one step ahead of the onslaught of attacks. As an industry, we must continue to learn from our adversaries and continue to embrace increasing levels of automation.

For more information about using automation check out our resources created in conjunction with the SANS Institute, including the white paper entitled “SOC Automation – Deliverance or Disaster”  and webinar “Myths and Best Practices Surrounding SOC Automation”.

When is Security Automation and Orchestration a Must-Have Technology? – Addressing Gartner’s SOAR Question

Last week, Anton Chuvakin from Gartner announced that Augusto Barros and himself are planning to conduct research in Q4 2017 on the topic of Security Orchestration, Automation and Response (SOAR), or Security Automation and Orchestration, depending on which analyst firms’ market designation you follow. At DFLabs we are very excited that Gartner is finally showing our market space some love and will be helping end users to better assess and differentiate SAO offerings.

Anton provided many questions that he wanted SAO vendors to prepare for. The questions immediately piqued our interest, with one question, in particular, standing out to us.

1.When is SOAR a MUST have technology? What has to be true about the organization to truly require SOAR? Why your best customer acquired the tools?

Anton also said that he had one main problem with Security Automation and Orchestration. In his own words, “For now, my main problem with SOAR (however you call those security orchestration and automation tools…if you say SOAPA or SAO we won’t hate you much) is that I have never (NEVER!) met anybody who thought “my SOAR is a MUST HAVE.”

The question is not entirely unwarranted. During my own time at Gartner covering the SOAR space, I spoke to many clients who were seeking an SAO solution without knowing that they were. Typical comments were, “I have too many alerts and false positives to be able to deal with them all”, or “We are struggling to hire enough skilled people to be able to respond to all of the incidents that we have to manage”. Another common comment was, “I am struggling to report operational performance to my executives?”. Often, these comments were followed by the question, “Do you know of any technology that can help?”.

Typically, these organizations had a mature security monitoring program, usually built around a SIEM. They often had critical drivers, such as regulatory requirements, or held sensitive customer data. We hear the same buying drivers from our own customer base.

To sum up the most common drivers for someone asking about Security Automation and Orchestration:

  1.  A high volume of alerts and incidents and the challenge in managing them
  2.  A large portfolio of diverse 3rd party security detection products resulting in a large volume of alerts
  3.  Regulatory mandates for incident response and breach notification
  4.  An overstretched security operations team
  5.  Reporting risk and the operational performance of the CSIRT and SOC to an executive audience

One interesting thing is that when there is no external driver like regulatory compliance, deploying a Security Automation and Orchestration solution is often determined by maturity. Most organizations don’t realize that they will be unable to cope with the volume of alerts and the resulting alert fatigue until they have deployed a SIEM and a full advanced threat detection architecture.

The common misconception is that the SIEM can help to reduce the number of incoming alerts by applying correlation rules. This not entirely untrue, but correlation rules will only reduce a small percentage. They are essentially signature based. You need to know in advance what you want to correlate, and adding a correlation rule to cover all and every incoming alert is not a trivial task. Even with correlation rules, additional work will be required to qualify an incident. Gathering additional IoC’s, incident observables and context is still a very manual process. Lastly, detection is only one part of the entire incident response process – notifying stakeholders, gathering forensic evidence and threat containment will also have to be done manually. These are the areas where SAO solutions provide the greatest ROI – as a force multiplier.