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.