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.

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

Understanding the Noise Using Security Orchestration, Automation and Response

“Noise” is a prevalent term in the cyber security industry. Here at DFLabs – Security Orchestration, Automation and Response Platform, we consistently receive feedback from vendor partners and clients that one of the major issues they face on daily basis is the ability to sift through the noise in order to understand and differentiate an actual critical problem from a lost cause.

What is “noise”?

Noise is a vast amount of information passed from security products that can have little or no meaning to the person receiving the information. Typically, lots of products are not tuned or adapted for certain environments and therefore would present more information than needed or required.

Noise is a problem to all of us in the cyber security industry, as there are meanings within these messages that are on many occasions simply ignored or passed over for higher priorities. For example, having policies and procedures that are incorrectly identified or adapted, or a product is not properly aligned within the network topology.

There is not one security product that can deal with every attack vector that organizations experience today. What’s more disturbing about this paradigm is that most of the tools and technologies within the security infrastructure do not talk to each other natively, yet all them have intelligence data that can overlay to enrich security operations and incident response teams.

Understanding the Noise Using Security Orchestration, Automation and Response

Cyber incident investigative teams spend a vast number of hours carrying out simple administrative tasks that could easily be relieved by introducing an effective security orchestration, automation and response  (SOAR) solution. Given the sheer volume of alerts, we can see from SIEM products on a day to day basis, a Security Orchestration Automation and Response SOAR tool can be used in conjunction to execute most, if not all of the human to machine actions, following best practice per type of incident and company guidelines, all through automated playbooks.

Re-thinking what information is being presented and how we deal with it is the biggest question. There are several ways to manage this:

  • Fully automating the noise worthy tasks.
    If these are consistently coming into your Security Operations Center (SOC) causing you to spend more time on administration than investigation, it may be prudent to schedule the tasks in this manner.
  • Semi-automation of tasks can give your SOC teams more control over how to deal with huge numbers.
    Automating 95% of these tasks and then having an analyst to provide the last sign off via manual look over, can heavily reduce time if your organization is against fully automating the process.
  • Leverage all of your existing products to provide better insight into the incident.
    For example, leverage an existing Active Directory to lock out or suspend a user account if they log in outside of normal business hours. Additionally, it’s possible to sandbox and snapshot that machine to understand what is happening. A key consideration here is to make sure not to disrupt work at every opportunity. It really is a balancing act, however, depending on their privilege you may want to act faster for some users compared to others depending on their role and responsibilities.

During the second half of 2018, the readiness and capability to respond to a variety of cyber incidents will continue to be at the top of every C-level agenda. By leveraging the security orchestration automation and response capabilities offered by DFLabs’ IncMan SOAR platform, stakeholders can provide 360-degree visibility during each stage of the incident response lifecycle. This provides not only consistency across investigations for personnel but encourages the implementation of Supervised Active Intelligence across the entire incident response spectrum.

At DFLabs we showcase our capacity to reduce the investigative time and incident dwell time, all while increasing incident handling consistency and reducing liability. Arming your SOC teams with information prior to the start of their incident investigation will help to drive focus purely on the incidents that need attention rather than the noise.

Please contact us to discuss how we can work together to grow your incident response capabilities or schedule a demonstration of how we can utilize what you already have and make it more effective and efficient.

Transitioning Your SOC Analysts from Data Gatherers to Threat Hunters

Threat hunting is defined as an iterative and focused approach to searching, understanding and identifying internal adversaries that are found in the defender’s network. It’s been shown that incident response automation tools can provide Security Operations Center (SOC) team members with additional time that can be leveraged in a more focused, threat hunting role within the SOC environment.

The SOC staff members should have some understanding of how they can use this additional time provided by incident response automation to enable them to hunt for threats, rather than spending valuable time and resources gathering threat information which could otherwise be done in an automated fashion.  It’s long been established as we make the migration from threat prevention to threat discovery that malicious actors and processes are frequently well-hidden within the organizations infrastructure and in order to effectively locate and investigate them we must start by asking the 5 W’s, who, what where, when, why and perhaps most importantly, how.

SOC team members must first understand what threat hunting is to be truly effective. The staff members should channel their question on the three tenets that make up the threat triangle; capability, intent, and the opportunity. By focusing on these three tenets, threat hunters can leverage orchestration to accomplish not only the system monitoring but the automated data gathering to support this expanded role without adding additional infrastructure. Additionally, team members must understand that the threats can be human and not just, for example, malware that is directed at them. This, coupled with an understanding of the affected systems function, will help provide the insight into possible contributing factors to the incident.

As the level of automation scales upward, we’ve seen a corresponding scaling of the transition from simple incident data gatherers to data hunters. Additional time and resources will become available to teams that leverage incident automation, permitting them to forego the traditional gatherer role and begin to embrace a more proactive hunter role. The good news is both of these roles can be supported within the SOC and also within the same Security Orchestration, Automation and Response (SOAR) platform. IncMan SOAR from DFLabs provides the necessary combination of force multiplication and machine learning to ensure that not only are incidents capable of being prioritized automatically, but the necessary actions for successful resolution are available at incident inception.

If you would like to see how a SOAR platform can give your incident response team the necessary tools to make the migration from simple data gatherers to threat hunters, reach out to us for a free, no obligation demo.

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”.

Leverage Your Existing SIEM with SOAR Technology

With a vast range of security technologies, tools and platforms now widely available in the market for security teams, it is ever more complex to decide which tools are best to deploy to suitably defend the organization’s infrastructure.

Within security structures of larger organizations, it is common to have a security information and event management (SIEM) tool in place, alongside or sitting on top of several other systems, but how can it benefit from implementing a Security Orchestration, Automation and Response (SOAR) solution on top of its existing SIEM infrastructure to further manage its security operations and incident response processes and tasks?  Let’s find out.

The Differences Between a SIEM and SOAR Solution

In simple terms, a SIEM collates and analyses the information generated from various sources, identifying issues and raising the initial security alerts. Alert triage is then often carried out by security analysts in a very manual and non-methodical way and subject to mistakes and errors due to the sheer volumes and number of repetitive and mundane actions required, often not being able to fulfill all of them. One of the original core drivers for SIEM technology was to ingest and process large volumes of security events; a function which SIEMs continue to excel at today. However, although some advanced SIEMs have incorporated additional features, such as integration with threat intelligence and other third-party solutions, many SIEMs are still largely focused on data ingestion and presentation.

Another fundamental limitation of many SIEM solutions is that the communication between the SIEM and other third-party products is unidirectional.  SIEMs were designed to ingest information, however, support for two-way communication with third-party tools is often limited at best. In most cases, this severely limits a SIEM’s ability to carry out actions beyond the initial alert; this is where a SOAR solution can add significant additional value.

A SOAR solution, on the other hand, is often used in conjunction with a SIEM, however, it is not dependent on having a SIEM in place. A SOAR solution is not intended to be a SIEM replacement, instead, when used in conjunction with a SIEM it is intended to be utilized to help security teams automate and orchestrate actions across their entire portfolio of security products in a bidirectional manner to reduce analyst workload, alert fatigue, time to respond and remediate and reduce overall risk.

Sitting on top of the SIEM, the SOAR solution would orchestrate and automate multiple third-party tools from different vendors, whereas the SIEM would be used to collate and analyze data and generate the alert, which is just the first step of a multistep process. SOAR technology would then be leveraged once the initial security threat had been detected and the security alert generated by the SIEM.

When to Implement a SOAR Solution?

The amount of security events that cybersecurity professionals deal with on a day to day basis can be overwhelming and analysts often have to delve through a deluge of data to find what they are looking for, ultimately preventing them from tackling incidents more efficiently. SIEM tools collect large amounts of information from different areas of the IT framework, but too much information sometimes is just as crippling as not enough information.

A SIEM used in isolation helps to centralize information gathered from various other security tools being used, but it can often lead to an overwhelming amount of information, that then needs to be filtered and correlated to eliminate the false positives to leave only the critical events that need to be acted upon. It can produce a vast quantity of security alerts, leaving security analysts inundated, not knowing which alerts should take priority and be tackled first. This will have a negative impact on the security team, with what is already considered a scarce resource.

Most security teams do not realize the sheer number of alerts that will be received and the resulting alert fatigue until they have deployed a SIEM and a full advanced threat detection architecture. There is a common misconception that a SIEM will reduce the number of incoming alerts by applying correlation rules.  However, this is not always the case and correlation rules may only reduce a small percentage of the total number of alerts.  Most enterprises will see a clear business need for implementing a SOAR solution to help reduce alert fatigue, orchestrate the organization’s different security tools and automate menial tasks.

The Benefits

Integrating a SIEM with a SOAR solution combines the power of each to create a more robust, efficient and responsive security program. Taking advantage of the SIEM’s ability to ingest large volumes of data and generate alerts, the SOAR solution can be layered on top of the SIEM to manage the incident response process to each alert, automating and orchestrating a number of mundane and repetitive tasks that would take many manual man hours to complete.

SOAR solutions such as IncMan from DFLabs support SIEM integrations and present a comprehensive solution for all organizations that are trying to create a successful and affordable security program, by effectively reducing the noise generated by a high number of alerts and sometimes less than reliable threat intelligence. This can ultimately enable security teams to minimize incident resolution time, maximize analyst efficiency and overall increase handled incidents.

The combined power of a SOAR solution working alongside a SIEM is crucial to ensure that alerts do not go untouched or ignored. More importantly, it ensures all alerts are dealt with in a timely manner and are acted upon following a standard set of consistent and repeatable practices and procedures.

Final Thoughts

A SIEM is a crucial tool within any security infrastructure, amongst other tools. However, it is critical to keep in mind what a SIEM is designed to achieve, and what gaps may still exist within the security program. The combination of a SIEM and a SOAR solution can transform the security operations and incident response capability and take it from one level to the next, in an intelligent and predetermined manner, so why wait? To learn more about the topic read our new whitepaper “How to Leverage Your Existing SIEM Tool with SOAR Technology

CISO Challenges and the Best Way to Manage Them

Faced with a growing threat landscape, a shortage of skilled cyber security professionals, and non-technical employees who lack awareness of cyber security best practices, to name a few, CISOs are continuously confronted with a number of existing and new challenges. To mitigate some of these challenges by eliminating security threats and minimizing security gaps, they must make some critical strategic decisions within their organizations.

Even though we are only at the beginning of April, 2018 is already proving to be a year of increasing cyber incidents, with security threats spanning across a range of industry sectors, impacting both the private and public sectors alike. We have seen many data breaches including Uber, Facebook and Experian that have made it clear that no organization, not even the corporate giants, are safe from these cyber threats and attacks.  We are now also seeing newly evolving threats affecting the popular and latest smart devices including products such as Alexa and Goоgle Home. New technology not fully tested, or security vulnerabilities from IoT devices being brought into the workplace, now bring additional concerns for CISOs and their security teams, as they try to proactively defend and protect their corporate networks.

This problem seems quite simple to identify in that corporate policies are not being updated fast enough to keep up with dynamic changes and advancements in technology, as well as to cope with the increasing sophistication of advancing threats, but managing this problem is seemingly more difficult. This generates an additional set of challenges for CISOs to enforce policies that still need to be written, while conquering internal corporate bureaucracy to get them created, modified or updated. This is just one challenge. Let’s now discuss a few more and some suggested actions to manage them.

How CISOs Can Overcome Their Challenges

CISOs in international corporations need to focus on global compliance and regulations to abide with a range of privacy laws, including the upcoming European Union’s General Data Protection Regulation (GDPR). This new regulation due to come into force on May 25th, 2018 has set the stage for protection of consumer data privacy and in time we expect to see other regulations closely follow suite. International companies that hold EU personal identifiable information inside or outside of the EU will need to abide by the regulation and establish a formalized incident response procedure, implement an internal breach notification process, communicate the personal data breach to the data subject without delay, as well as notify the Supervisory Authority within 72 hours, regardless of where the breach occurred. Organizations need to report all breaches and inform their affected customers, or face fines of up to 20 million Euros or four percent of annual turnover (whichever is higher). A new law called the Data Security and Breach Notification Act is also being worked on presently by the U.S. Senate to promote this protection for customers affected.  This new legislation will impose up to a five year prison sentence on any individual that conceals a new data breach, without notifying the customers that had been impacted.

So how can CISOs proactively stay ahead of the growing number of cyber security threats, notify affected customers as soon as possible and respond within 72 hrs of a breach? The key is to carry out security risk assessments, implement the necessary procedures, as well as utilize tools that can help facilitate Security Orchestration, Automation and Response (SOAR), such as the IncMan SOAR platform from DLFabs. IncMan has capabilities to automate and prioritize incident response and related enrichment and containment tasks, distribute appropriate notifications and implement an incident response plan in case of a potential data breach.  IncMan handles different stages of the incident response and breach notification process including providing advanced reporting capabilities with appropriate metrics and the ability to gather or share intelligence with 3rd parties. This timely collection of enriched threat intelligence helps expedite the incident response time and contribute to better management of the corporate landscape.

The Need to Harden New Technology Policies

Endpoint protection has also become a heightened concern for security departments in recent months, with an increasing number of organizations facing multiple ransomware and zero days attacks. New technologies used by employees within the organization, not covered by corporate policies, such as Bring Your Own Device (BYOD) and the Internet of things (IoT) have brought new challenges to the CISOs threat landscape. One example as we mentioned earlier are gadgets such as Alexa or Google Home, where users bring them into the office and connect them to the corporate WIFI or network without prior approval. When connected to the network, they can immediately introduce vulnerabilities and access gaps in the security network that can be easily exploited by hackers.

Devices that are not managed under corporate policies need to be restricted to a guest network that cannot exploit vulnerabilities and should not be allowed to use Wi-Fi Protected Access (WPA).  CISOs need to ensure that stricter corporate policies are implemented to restrict and manage new technologies, as well as utilizing tools such as an Endpoint Protection Product (EPP) or Next-Generation Anti Virus (NGAV) solution to help prevent malware from executing when found on a user machine. NAGV tools can learn the behaviors of the endpoint devices and query a signature database of vaccines for exploits and other malware on real time to help expedite containment and remediation to minimize threats.

Maximizing Resources With Technology as a Solution

With the significant increase in the number of and advancing sophistication of potential cyber security threats and security alerts, combined with a shortage of cyber security staff with the required skill set and knowledge, CISOs are under even more pressure to protect their organizations and ask themselves questions such as: How do I effectively investigate incidents coming in from so many data points? How can I quickly prioritize incidents that present the greatest threat to my organization? How can I reduce the amount of time necessary to resolve an incident and give staff more time hunting emerging threats?

They will need to assess their current organization security landscape and available resources, while assessing their skill level and maturity.  Based on the company size it may even make business sense to outsource some aspects, for example by hiring a Managed Security Service Provider (MSSP) to manage alert monitoring, threat detection and incident response. CISOs should also evaluate the range of tools available to them and make the decision whether they can benefit from utilizing Security Orchestration, Automation and Response (SOAR) technology to increase their security program efficiency and effectiveness within their current structure.

Security Infrastructure and Employee Training Are Paramount

In summary, CISOs will be faced with more advancing challenges and increasing threats and these are only set to continue over the coming months. They should ensure that their security infrastructures follow sufficient frameworks such as NIST, ISO, SANS, PCI/DSS, as well as best practices for application security, cloud computing and encryption.   

They should prepare to resource their security teams with adequate technology and tools to respond to threats and alerts and to minimize the impact as much as feasibly possible, with set policies and procedures in place. To enforce security best practices across all departments of the company, it is important that security decisions are fully understood and supported by the leadership team as well as human resources, with a range of corporate policies to meet the challenges of ever changing technologies.

CISOs need to promote security best practices and corporate policies, industry laws regulations and compliance by educating and training relevant stakeholders, starting with employees. The use of workshops, seminars, websites, banners, posters and training in all areas of the company will heighten people’s awareness to threats and exploits, increasing their knowledge, while also teaching them the best way to respond or to raise the alarm if there is a potential threat. The initial investment in education and training may be a burden on time and resources but in the long run will prove beneficial and could potentially prevent the company from experiencing a serious threat or penalty from non-compliance.

Completing a full analysis of current resources, skill sets and security tools and platforms will all play a part when deciding whether in-house or outsourced security operations is the best approach, but the benefits of using SOAR technology to leverage existing security products to dramatically reduce the response and remediation gap caused by limited resources and the increasing volume of threats and incidents, as well as to assist with important breach notification requirements, should not be overlooked.

How DFLabs IncMan Tackles Meltdown and Spectre Vulnerabilities

Following on from my recent blog post entitled “Meltdown and Spectre – What They Mean to the Enterprise” published in January, I wanted to take a closer look at how these types of hardware vulnerabilities could (and should) easily be detected, managed and mitigated using Security Orchestration, Automation and Response (SOAR) technology, for example with a platform such as IncMan from DFLabs.

Using Meltdown and Spectre as a use case, I wanted to enlighten you about the automated processes an organization can undertake.  There are many pros and cons for using automation, but if used in the correct way it can significantly improve Security Operations Center (SOC) efficiencies, saving security analyst many man hours of mundane tasks.  Alerts can also potentially be responded to and contained before an analyst has even been notified.  Using IncMan’s integrations and R3 Rapid Response Runbooks, SOCs can quickly respond to such an alert when a vulnerability is detected.  The overall goals would be as follows, in order to reduce the risk these vulnerabilities present to the organization.

1)  Automatically receive alerts for the host which have been identified as being vulnerable to Meltdown or Spectre.

2) Create an Incident and perform automated Notification, Enrichment and Containment tasks.

Implementation

Let’s move on to the implementation stages.  Where should you start? For ease I will break it down into 3 simple sections, creating a runbook, utilizing the rebook and seeing the runbook in action.  So, let’s begin…

Creating an R3 Rapid Response Runbook

The first step in reducing the risk from the Meltdown and Spectre vulnerabilities is to create a runbook to handle alerts for newly detected vulnerable hosts.  In this use case, we will use integrations with Jira, McAfee ePO, McAfee Web Gateway, MSSQL Server and QRadar to perform Notification, Enrichment and Containment actions; however, this can easily be adapted to include any other technology integrations as well.

 

Meltdown and Spectre Vulnerabilities

 

Using a Jira Notification action, a new Jira issue is created.  This Notification action should notify the IT or Infrastructure teams and initiate the organizations’ normal vulnerability management process.

Next, an MSSQL Server Enrichment action is used to query an IT asset inventory for the host name of the vulnerable host, which is passed to the runbook automatically when the incident is created.  This asset information is then available to the analyst for further review.

Once the IT asset information is retrieved, a decision point is reached.  If the IT asset information indicates that the host is a server, one path (the top path) is taken.  If the IT asset information indicates that the host is not a server, another path (the bottom path) is taken.

If the asset is determined to be a server the Jira Enrichment action is used to update the Jira issue, informing the appropriate parties that the host has been determined to be a server and should be treated as a higher priority.  Next, two McAfee ePO Enrichment actions are performed.  The first Enrichment action queries McAfee ePO for the system information of the given host name, providing the analyst with additional information.  The second Enrichment action uses McAfee ePO to tag the host with the appropriate tag.  Finally, a Task is added to IncMan reminding the analyst to follow up with the appropriate teams to ensure that the vulnerability has been appropriately mitigated.

If the asset is determined not to be a server, the two previously mentioned McAfee ePO Enrichment actions are immediately be run (System Info and TAG).  Following these two Enrichment actions, a McAfee Web Gateway Containment action is used to block the host from communicating outside of the network.  This Containment step is completely optional but is performed here on non-servers only to minimize the Containment action’s potential impact on critical systems.

Utilizing the R3 Rapid Response Runbook

Once the new runbook is created, IncMan must be told how and when to automate the use of this runbook.  This is achieved by creating an Incident Template, which will be used any time an incident is generated for a Meltdown or Spectre vulnerability.  Through this incident template, critical pieces of information such as Type, Summary, Category can be automatically applied to the newly created incident.

 

Meltdown and Spectre Vulnerabilities 1

 

From the Runbook tab of the Incident Template wizard, the previously created Meltdown and Spectre runbook is selected and set to autorun.  Each time this template is used to generate an incident, the appropriate information such as host name and host IP address will be used as inputs to the runbook and the runbook will be automatically executed.

 

Meltdown and Spectre Vulnerabilities 2

 

In this use case, alerts from QRadar are utilized to initiate automatic incident creation within IncMan.  However, another SIEM integration, syslog or email could also be utilized to achieve the same outcome.  A new QRadar Incoming Event Automation rule is added and the defined action is to generate a new incident from the previously created Meltdown and Spectre Incident Template.

 

Meltdown and Spectre Vulnerabilities

 

Solution in Action

When a QRadar Alert is generated matching the criteria defined for a Meltdown or Spectre vulnerability detection, IncMan will automatically generate a new incident based on the Meltdown and Spectre Incident Template.

 

Meltdown and Spectre Vulnerabilities

 

Without requiring any action on the part of an analyst, the Meltdown and Spectre runbook is automatically initiated, performing the defined Notification, Enrichment and Containment actions.(In the example shown here, the ‘server’ path is taken).

 

Meltdown and Spectre Vulnerabilities 5

 

Conclusion

How easy was that?  The entire process has taken place in a matter of minutes, likely before anyone has even had time to acknowledge the alert.  As an analyst begins to manually examine the alert, many of the mundane tasks have already been completed, allowing the analyst to focus on the tasks which require human intervention and reducing the time required to remediate this issue, ultimately reducing risk to the organization.

IncMan has over 100 customizable playbooks for similar use cases like this.  If you would like to see IncMan in action, please do feel free to request a demo.

DFLabs 3rd Party Integrations vs the Market

A consistent feedback point we receive from our users is that their security technology stack is rapidly growing to keep pace with the evolving threat landscape. The days where it was sufficient to deploy a firewall, an intrusion prevention system, antivirus and an identity access management system are long gone. Enterprises are literally spoilt when it comes to selecting a wide variety of different security technologies – User Entity Behaviour Analytics (UEBA), Network Traffic Analysis (NTA), Endpoint Detection and Response (EDR), Breach and Attack Simulation (BAS), are just a few of the emerging technologies available to security teams, and this list does not even include mobile, cloud and IoT offerings that are required to secure the expanding attack surface. This can seem daunting to many organizations, not just the budgetary impact, but also the fact that every one of these technologies requires the expertise and knowledge to effectively operate them.

As a vendor offering a Security Orchestration, Automation, and Response platform that is designed to integrate with, and orchestrate these different solutions, we often have to make difficult choices as to what we integrate with, and how deeply we integrate. Our focus is on market-leading security technologies, technologies we identify as emerging but of growing importance and effectiveness, and of course also based on what our customers have deployed and ask us to integrate.

There is a trend in our market to exaggerate the amount of 3rd party integrations. Marketing collateral often cites hundreds of different 3rd party tools, yet rarely differentiates between the depth of the integration, whether these are truly bidirectional and whether they certified by the 3rd party. As an example, any solution that supports Syslog can claim to support hundreds of 3rd party technologies. It’s an open standard and many solutions can forward syslog message to a syslog collector. But that does not necessarily mean that the solution also has out of the box parsers to normalize the messages, or that there are automation actions, playbooks or report templates available that can parse and use their content.

Reducing this to a pure quantitative marketing message also entirely misses the point. Organization only really care about the technologies they have deployed, or are planning to acquire. The quantity here is entirely misleading. More importantly, users are not stupid. They will see through this charade at the latest when conducting a proof of concept. And at that point any vendor following this approach has some uncomfortable explaining to do. No relationship, personal or business, gets off to a good start based on fudging the truth.

I have rarely seen an RFP that was based purely on a quantitative measure of supported 3rd party integrations, so it is baffling why marketers believe this to have any impact.

At DFLabs we have decided to go a different way. We want to clearly state which of our integrations are bidirectional as opposed to only based on data ingestion, and which integrations are certified, or compatibility tested by our integration partners.

While at first glance this appears to put as at a disadvantage, we trust in the intelligence of our customers. We hope that it will help them to make better-informed decisions and they give us credit for being honest and realistic.

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.

The Power of New-Age Playbooks in Incident Response

I have often talked about the benefits of employing flexible playbooks to deal with evolving cyber incidents and unique threat scenarios, and in these series of blogs, I am going to explore some of the points of emphasis when creating a new playbook.

The advantage to Security Orchestration, Automation and Response (SOAR) platforms, and in particular our IncMan platform, is the ability it provides to tailor playbooks or runbooks to deal with all manner of cyber incidents. These Playbooks are defined by three key factors:

1.Phases: Determine the number of phases for the response process based on the incident scenario. The phases are really a placeholder for what you are trying to achieve in your response.

2.Automation: How much automation will benefit the given scenario without hindering or otherwise adversely impacting your business.

3.Actions: What actions apply to each phase and what is the benefit to each action.

Wash, Rinse, Re-playbook.

Play books, or runbooks, should never be static and hard-coded for a fixed set of events. Ultimately, incidents will differ and you should always remain in control, ready to adapt and adjust the response workflow. This flexibility is vital should a Plan B need to be executed. The approach of IncMan to security playbooks & runbooks support both mature and emerging SOC teams by providing multi-flow advanced runbooks to the former, and for the less mature, a simplified playbook containing a dual mode where automation and manual actions can co-exist.

In talking with CSIRT/SOC managers, I have learned that they have typically aligned themselves with a particular standard. Most organizations follow the likes of ISO for Incident Response, NIST
800-62 or alternatives along the lines of CREST or NISA. Structured incident handling processes based on these standards are a great baseline, but how about also having actions and reactions pre-prepared and ready to respond immediately according to the threat you face? Can you see the instant advantage in having smaller, simpler playbooks and runbooks specific to an adversary or threat scenario?

Dealing with incidents with tailored playbooks will ultimately provide better threat coverage as each has enrichment and containment actions that are concentrated on the tasks specific to a given scenario. Additionally, allowing your SOAR product to tie the dots to bring enrichment to the observables and the indicators encountered in incidents will bring measurable value to the increased speed of the incident response process. Allowing analysts dynamic interaction at all phases of the workflow will help also help your reactions become more efficient. This mix of structured playbooks and dynamic response capability can also help push the CSIRT teams into a more pro-active mindset, allowing system and network-level security policy and infrastructure configuration changes to be handled on the fly while leveraging current and accurate information, and all from a single response console.